Learning Python Using IronPython

Not too long ago when browsing the Coursera courses I found an interesting one about learning to program using the Python programming language. Once I saw this I jumped right on it and installed IronPython, a .NET library that lets you use Python to interact with .NET applications. Unfortunately, I never really finished all the assignments. I got a bit stuck with converting a .NET List object to a Python List object. I believe I finally got the program to actually do the conversion, but my test would still fail for some reason (any insights on this would be awesome).

The code for IronPython that really does the work in my project is in the PythonEngine class.

As you can see, it’s taking in a parameter for the location of the Python script file for it to execute. From there the engine compiles the file and executes it. I get the variable (or method in this case) by the name and then I send it the list of parameters and invoke it getting back the results that are returned as a dynamic type.

One of the cool things you can do with IronPython and using the dynamic keyword is that, if your app has a different set of rules, you can create the rules within the Python script and use the C# to invoke them. This way only the Python script will need to be updated for the logic of the rules and no compiling of the C# is needed to execute the new rule set.

This course was a fairly easy introduction to the Python language and I believe it’ll be offered again fairly soon on the Coursera site, if you’re interested in taking it. Using it with IronPython also shows how powerful it can be in enterprise applications as well as how much power using the dynamic keyword can be.

Current Project Queue

Like any developer, (who actually likes doing development, anyway) I tend to have some projects outside of work going. Of course, more often than not, they don't always get completed. Some don't even get started! I'd like to change that. This blog (and hopefully all two of you readers) can help keep me accountable. So here are the projects I currently have an idea on doing and what I plan on learning. Don't worry, I'll release the source for this stuff as they get completed.

• Web app to use the Jamendo API - Wanted to play with the API (which helps me learn to consume JSON) for some time now. Plan on creating an ASP.NET MVC web application and use Angular.JS for the two-way data-binding (of course, mess with the testing and IoC within Angular.JS).
• Learn more design patterns - I've stayed away from learning design patterns but no longer! I think it's time to learn these and I'll be using PluralSight's Design Pattern Library course to help me out.
• Something with the Kinect - Not exactly sure what to do with the Kinect just yet, but I wanted to develop an app to interact with some hardware and this seems like a simple yet fun way to do so.
• More JavaScript - This is the number one thing I need to learn more of, currently. When JavaScript is considered the most dominant language now, it's a good time to learn more of it.

This is just a list of the more important stuff I wanted to do. I'm sure more stuff will definitely be to come.

Using PowerShell to Help Debug Third Party Dependencies

I hate when an application has a third party dependency (web service, url, ftp, etc.) mainly because it’s hard to test or even see what data you’re getting back. However, this is one awesome reason to love PowerShell. PowerShell can be used to make those calls manually so you can see what comes back and, if needed, use that data further while doing tests. For example, you have a call that gives XML has a response and use PowerShell to traverse the response using the new Invoke-WebRequest cmdlet in PowerShell v3. I’ll use the MSDN blog RSS feed as a small example here.

However, PowerShell makes it easier for us to traverse the XML by putting all the nodes into properties. For that, we need to put the results into an XML typed variable.

And with the above we get these results:

image

And from there you can use the results anyway you need to to help test and/or debug that part of your application. This recently just helped me out of a bit of a bind.

A Thought on Legacy Code

I’m quite sure that during one’s career as a software developer they may have the pleasure of maintaining legacy code. Of course, I personally define legacy code as a project that has absolutely no tests. Most of the time, though, this may be a fairly old project. If that developer has been in the career at least a couple of years, then one of the first things they may say to themselves about this type of project is how bad the code and/or the design is. I, myself, have also done this quite a few times.

However, something has occurred to me while I was updating, not one, but three of these types of projects. Indeed, there’s code in these that I still wonder who in their right mind would have written. At this point I had a sort of an epiphany: this wasn’t a bad thing, this is what helps to make me a better developer. The main reason I believe this is that, since I actually enjoy writing unit tests, I concentrate on making the code testable and write as many tests as I can. Only then will I proceed to make the requested enhancement or fix. The project is actually better for that and you just did something that someone else deemed or was just flat out told that they didn’t have time or the energy to do.

In conclusion to this small rant, don’t always hate on having to update legacy code. It can be to your best benefit as a developer and what you learn from that can last quite a while in your development career.

Debugger Display using ToString()

One of the things as a .NET developer that I tend to do most while debugging is to traverse through objects and their properties to see what values they have. Of course, the Base Class Library has something to help us do this even faster and more efficient – DebuggerDisplay attribute. Let’s say you’re tasked to help an insurance company write an updated application to determine the rate based off certain attributes on the car, such as age and number of collisions. It may look something like the following:

View fullsize

Showing regular object debugging.

And while debugging you want to see the properties, Visual Studio will show you something similar to the below.  Not bad, but we can do a bit better with the DebuggerDisplay attribute. Let’s see how this gets used. With the same class definition that we had earlier, we just add the DebuggerDisplay attribute to the class. To access any of the properties, just enclose them in “{ }”.

And our result is the below. Note that you can still expand out the object for other properties as well.

View fullsize

Debugging the object with DebuggerDisplay

Now, this alone can help out, but we can also run methods in the DebuggerDisplay attribute. Let’s override our ToString method of our class and use that. Note that the “nq” in the attribute is for “no quote” which will remove the quotes from the resulting string.

And, as you can see, we get the ToString() result in our debugger tool tip.

View fullsize

Debugging object using DebuggerDisplay with ToString()

Of course, there are other reasons why you would want to override the ToString method in your own classes, but hopefully now you know just one more way you can use it. Have fun debugging, everyone!

On Better Developer Testing

I read an interesting post by Phil Haack a little while ago on having developers do better testing themselves instead of relying solely on their QA team to test. While it’s definitely a great read in itself, I felt I had to add my opinion to it.

Don’t get me wrong with this, though. I think the more experience and skill a developer has on testing their own code, the more valuable they actually are. Also, it’ll mean their code is that much more reliable and stable upon initial release all the way through to production. No developer wants to find that their code somehow broke in production the morning after it was deployed and spend that whole day fixing it.

While I definitely agree with Phil on most of his arguments, there was one thought about the whole thing that kept coming to mind about myself, personally, when testing stuff that I’ve written. I know I don’t have the experience to think of a good amount of scenarios the code will be hit at. Now, this may not be an issue for the more experienced developers out there, but I know it’s a weak point of mine. I’ve definitely been bit by not doing more of this in the past and, indeed, it wasn’t fun admitting it was my fault when the manager is asking what happened. In fact, when this happened to me it gave me a very real benefit of using unit tests. Of course, unit tests can’t test everything that a user would do as input or processes on a screen. While Phil notes that Test Driven Design is mainly for the initial design of the code we’re ultimately testing, it definitely helps to make sure any refactorings for readability, maintainability, performance, etc. didn’t break anything we’ve already shown and trust to be correct.