At first glance, you look at those and think they are silly because all they are doing is testing that the test framework is working correctly. But Bobby has a different reason for including them.

So when I am setting up my basic project structure and automation, I like to have at least one unit test ready to run. This allows me to test the automation script and ensure failures in tests cause failures in builds. In .NET I want to confirm that the compilation step fails properly and the unit tests fail properly. In node.js, I want to ensure that linting errors fail as well as unit tests.

That’s a valid point, however this is more of a configuration test of your infrastructure. I personally wouldn’t write a test like this, I’d want the test to have some value before I committed it to the main repository or build/CI server. I strongly feel that developers should use the same build procedure on their desktops to build the application as they do on their CI server. IDE’s like Visual Studio abstract away the building of the application, so we often have to write scripts, rakefiles, psake files, whatever to do all the things that Visual Studio doesn’t do when it builds your application. Things like running the tests and reporting the results, building an installers or setting test/staging/production values in config files. I like to have a repeatable build system setup for projects I’m working on so I tend to re-use scripts or keep it really simple. Which means that I have confidence that I have configured the build script correctly so that it will work properly when I put it in my CI server. Which allows me to start focusing on the design of my application sooner.

Erich Gamma: Yes, and it is funny that you mention the iPhone. The iPhone SDK is based on the NeXTStep object-oriented frameworks like the AppKit. It already existed when we wrote Design Patterns15 years ago and was one source of inspiration. We actually refer to this framework in several of our patterns: Adapter, Bridge, Proxy, and Chain of Responsibility.

Richard:Which is a great example of the enduring nature of good design, and how it survives different technical manifestations.

Emphasis mine.

In the Microsoft developer community, we are just now getting around to implementing patterns like MVC, Adapter, and Observer. People still argue over whether or not the MVC pattern is “necessary” to build a “working application”.

I guess it depends on whether or not you like good design?

Share this:

I dislike using mocks I dislike using dynamic mocking/stubbing frameworks. because it means my tests have an extra dependency beyond just the SUT (System Under Test). I often find myself spending more time getting the mock to work correctly rather than my app code. The lambada + generics based Mock suites (Moq, RhinoMocks, etc), IMO, complicate the test and make them unreadable in some situations.

Compare the two examples in this post. One uses RhinoMocks to create a stub of IDataReader and the other uses the DataTableReader to create a stub for the test. Which example is simpler and has less chance to fail due to the stub?

Stubs/Fakes allow me more control over HOW the test fails and results in a test/fixture that is easier to read. I’m not saying that mocks aren’t useful in certain situations, but I would favor a stub over a mock IMO, your test should only fail because of the code it is testing, not because of a mock.

update to the update: Jeremy Miller and Nikola Malovic both pointed out that I’m using the terminology incorrectly. It turns out I don’t specifically hate mocks themselves, I dislike use dynamic mocking/stubbing frameworks due to the extra dependency they introduce into my tests. Thanks for the corrections. Back to reading Fowler for me!

Both Jimmy and roy have great posts discussing JavaScript. Roy is looking at it as a C# developer lured by the many, many articles about how jQuery is the only thing that makes JavaScript worth using and using Script# to abstract away some of the messiness and pain usually associated with writing JavaScript. Jimmy discusses the merits of JavaScript itself and how it has changed how he approaches writing C# code.

One thing I like to point to is a great quote I heard on Twitter

Java is to JavaScript as ham is to hamster

JavaScript actually has more in common with Scheme or Lisp than it does Java or C#. I first realized this when I saw that Douglas Crockford had re-written all of the examples in The Little Schemer
in JavaScript. It’s easy to miss that fact when you see all of the pseudo OOP noise like “var foo = new Foo();”. But when you see how trvial it is to implement something like a map method in JavaScript, you realize how powerful the language can be. Most of the hatred for JavaScript comes from two things I’ve found:

Broken DOM implementations – every browsers implementation of the DOM is broken in one respect or another.

Roy has a great point about the lack of good tooling surrounding JavaScript. There are excellent libraries like jQuery and PrototypeJS, but the usual tool support, intellisense, re-factoring, profiling, is a little more difficult to come by. I’ll address this in another post as I feel a lot of people are new to JavaScript and are struggling along with some substandard tools.

Share this:

I’ve always wanted to use Python more but it’s difficult because the .NET Framework is such a walled garden in terms of interoperability with other programming languages. Mostly I use it to write little one off scripts when I want to move a bunch of files around or parse some text. I was really excited when Manning asked to to review IronPython in Action because I wanted to dive a little deeper into Python and possibly use it in some web applications. “IronPython in Action” makes it easy to get started using IronPython right away.

The book starts out with an introduction to Python itself and continues with a general description of how IronPython can use .NET types. It starts off by showing how to build a Winforms app using IronPython. If anything exposes the cruel, unnecessary complexity of .NET, it’s got to be a Winforms app. The IronPython examples are easy to follow and it’s always fun to create and manipulate a Winforms app using the IronPython console.

Chapter 4 talks about using Design patterns in IronPython. This is a refreshing change from most language books where patterns aren’t mentioned at all. The chapter builds an IronPython application and uses the MVC pattern for the overall architecture and the command pattern for the implementation of the menu bar events.

Chapter 7 discusses agile testing and unit testing using IronPython. I almost dropped the book in amazement. Unit testing is almost never mentioned in any language book and is relegated to a niche or advanced topic. Find a book about any other .NET language that mentions unit testing that doesn’t have the word “testing” in the title. This alone sets the quality of this book far above other language books I have read. It’s not just enough, in my opinion, to discuss the syntax of the language. You have to teach the reader how to use the language in your everyday work.

The next section, section3, deals with a few core UI frameworks commonly used during .NET development, WPF, Silverlight, and ASP.NET, as well as showing how you can use IronPython to administer your system. Performing tedious tasks is my most common use of IronPython. I use it to automate moving files that fit a specific pattern out of my “downloads” directory to their proper places. It was great to learn a few new techniques for using IronPython in Powershell.

The last section talks about extending IronPython using C#, something which it sounds like should be avoided unless you just can’t achieve decent performance with the equivalent IronPython code, and using IronPython as an embedde scripting engine. Python is used a lot in game programming because it’s easy to embed. The nuts and bolts of the game engine will be written in low-level C/Assembly while the game logic and story is written in Python. I love the idea of having an embedded scripting engine in my application that will allow me to quickly extend my application at runtime. The user need to perform a new calculation on some data? Just send them an IronPython script and have them put it in a directory. It’s a great idea and the book describes exactly how to do just that, even if it does use a little too much jargon at times. These are advanced topics and you probably shouldn’t undertake them unless you have a good understanding of the basics in any case.

My overall feeling about this book is that it’s a great book. The authors use the same humor and dry wit that Python is known for to great effect. Making the digestion of a very different language easier. I’m sure that as I continue to experiment with IronPython that I’ll keep this book close at hand.

Share this:

In this post, Steve Wellens tries to make the case for two common patterns your run across when using jQuery as “worst practices”. Practices that are either superfluous or harmful to your code.

1) Wiring up events using unobtrusive JavaScript.

Instead of wiring up your elements events using jQuery, instead you should set the OnClientClick property of the ASP.NET Web Control in question and call whatever JavaScript you want to handle the event.

You might want to change event handlers dynamically depending on some condition in the page. If you need to assign a common event handler to several objects on a page, it makes sense to do it in one place. As a matter of fact, that’s the beauty of jQuery. But for a single event on a single control….NO.

On can debate whether or not a worst practice can really be applied to a single, specific , one-time event or not. But there are other reasons why you might want to hook up events to a single element using jQuery. one being that you can’t hook up multiple event handlers using OnClientClick or HTML’s OnClick event, only a single event handler can be assigned. If you are using the observer pattern in your JavaScript, you may have multiple observers that want to subscribe to your buttons click event. But a really strong argument could be made for using the OnClientClick property simply due to ASP.NET’s suck-ass way of handling client IDs.

2) Chaining can lead to unreadable code.

In a badly written example, he states that chaining calls to jQuery makes the code unreadable. I’d suggest re-formatting the code in this manner to make it legible and allow for a tighter minimization.

// get all the Divs with the highlight class and
// format them and set their width
var Divs = $("div.highlight");
Divs.css("color", "yellow");
Divs.css("background-color", "black");
Divs.css("width", "30px");

I like this explanation by Jeff Atwood best. If you need comments to explain WHAT your code is doing, you need to use better names and/or write better code. Comments are best when used sparingly and explain the WHY of the code. Why did you choose to use a particular algorithm