What if the vendor can’t get the bug fix in time? It may not be vital early on, but the thought process behind an exit strategy should exist, and simply become more refined the closer we come to the risk event, instead of scrambling to make one appear when it is clear we aren’t going to make it.

We’ve all been there. You work your butt off and you know your code is good, but you don’t know much about the database or the stability of the enterprise library you have to call. The app architects keep saying the interfaces aren’t going to change but … they’ve done nothing but change in the 4 weeks leading up to your launch. What is your exit strategy? It could be that your backup plan is to present a nice error message to the user rather than an ugly stack trace. Maybe you just disable that component or inform the user that the data is read-only for now.

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.

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.

Instead of this:

Do This:

His reasoning is as follows:

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.

Of course, you wouldn't write jQuery code like that and call the css method multiple times. Ideally, you would just set a class or at the very least pass in a set of properties in an object.

3) Comment your code.

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

Take an instance where you are retrieving items from a web service in your controller. Let's say that you get a 404 error and your service will throw an exception telling you that the service can't be found. Take a look at this controller action

As it stands this action is pretty thin, but if an exception is thrown the user will be presented with either whatever custom error page you have defined in your web.config or the dreaded Yellow Screen of Death.(YSOD). You can wrap the call in a try-catch block and catch the exception. But rather than creating a generic errors page that will display any raw exception message, it's a much better idea to return an error specific view to your user with a friendly error message.

This leads to a much "dumber" view and is a much better idea than modifying the "Item" view to display errors if something isn't right with the model or passing in special error parameters to the view. Let the view deal with the data it is meant to display and nothing else.

(1)

There are two reasons to do this:

1) It makes your controllers less complicated and easier to maintain. - You don't want to have to do a lot of debugging in your controllers. Chances are, if you have a lot of complicated logic in your controller actions, you are probably mixing concerns. Make sure that your controllers are only responsible for getting data from your models and figuring out what view to send to the client.

2) It makes testing easier. If all you are doing is getting a model and passing that model to a view, what do you really need to test? Maybe that the correct view is being returned.

(1) Of course I use more descriptive names than "myKey".