Various things for the new year

Trying to catch up on things. It's easy to get swept up in the busy day-to-day activities so much that you get behind on the things you want to get to.

Last year, I became involved in the NAnt development and things were moving along nicely to the point that we were able to get NAnt to version 0.90. Since then, we tried to get going on 0.91 to support .NET 4.0 but that ran into a snag. A security exception began popping up with random users trying to use the latest alpha release. What's worse, I have been unable to reproduce these issues on any of my test systems. I have received help from a few users who have been kind enough to provide debugging details and I do have a couple of ideas on how to approach the issues but it's been put on the back burner due to higher priorities at the moment. I hope to get to it soon.

I just started using syntaxhighlighter in my blog to help format some of the code that I have posted in the past. I must say that it is pretty cool. Some directions that I used can be found here. So I may be going back and updating some of the posts to better format the code that I post.

The Iron(Python|Ruby) projects have been turned over to the Iron* communities which is a good thing. It seems that Microsoft is letting these projects fly on their own with people who are experienced and dedicated with these kinds of projects and are actively working on them. I am happy that Microsoft made this move rather than let these languages go stale.

Now that IronPython is in capable hands, I am wondering when the Django project will try to support it. I mean, why not, Django supports Jython. I can understand that it may be an undertaking but it would be very nice for Django to run on IronPython out of the box rather than applying patches.

I'm hoping to write more in the near future.

What will be the future of IronPython?

Long time, I know. I'm trying to get back into the swing things. Slowly but surely.

I've been reading about the latest progress regarding the Microsoft Irons (python, ruby, etc) and it has me a bit concerned. I started using IronPython at work awhile back to help me out with various tasks and it works pretty good. So I have some scripts that help me out that I now use often. A few weeks ago, Microsoft changed the license for both IronPython and IronRuby to the Apache Software Foundation License version 2.0. I thought that was a cool and inviting change to the open source community. Hell, when I heard that, I started planning on converting more projects to IronPython. That was until I read this article over at The Register. While the article targets IronRuby, it seems to hint that IronPython is not far behind. If Microsoft ends up dumping these dynamic languages, I really hope that they completely open up the source code for these languages. This includes allowing people outside of Microsoft to contribute code to the project. The ASF license is a good step forward but they need to open it all the way or these languages could fizzle out. And just when I started finding uses for ipy.

In the meantime, I'll keep my stuff as is while I watch the outcome of this as it unfolds.

I can't wait until Dec 17th

It came from here.

Testing with IronPython

We all know that unit testing is important with software development. But the tests themselves are not always so black and white. IDEs like SharpDevelop or MonoDevelop have things like NUnit to help test a wide range of things like equality, identity, collection, and etc. These are great tools, but what happens when you don't know what the data being gathered/generated should be? How can we assert something when we don't know what it should be?

My situation was this, I wrote a C# library for work to pull customer information and create reports based on the customer's monthly fees. Since the fees vary between customers, it was difficult to make sure that the data being pulled was accurate. Since I have been losing time with this portion of the project, I decided it would be a good time to test the abilities of Iron Python.

Why use Iron Python? Couple of reasons. First, since this is a .NET project, Iron Python can load the library through the clr.AddReferenceToFile command. Second, it can be ran as a script rather than compiling a new C# project. This means that I can alter/update the script and rerun it when I need to. Nice convenience.

What I did was write a script to pull in the .dll library and call the various objects to display the information stored in them in an organized way. Like so...

import sys,clr

clr.AddReference("System")
from System import *

if __name__ == '__main__':

    dllPath = Environment.CurrentDirectory.ToString() + r'\bin\Debug'

    sys.path.append(dllPath)
    clr.AddReferenceToFile('nameOf.dll')

    from nameOfNamespace import *

    print "Start going through the objects..."

From here, I can create test objects from the dll and see if what data is being pulled and confirm it with external sources to make sure it is accurate. The first time I ran it, I found (and corrected) a few missteps on my part. Within the first 30 minutes of running it, I was able to fix problems that would have taken me much longer in the final product. Pretty cool.

Troubleshooting Hardware can be a pain in the a$$ (note the dollar signs)

Ever since I have tinkered with computers and machines from one type or another, hardware has always been my achilles heel. Not only is it difficult to troubleshoot but it can be expensive as well. There was this one time along time ago where I had a 500+mhz Pentium 3 machine that would lock up at random times and when I would escape to the BIOS, the BIOS would lock up also. How do you troubleshoot something like that? I remember calling up my dad to take a look at it and when he saw the BIOS freeze, he was as stumped as I was. I ended up replacing almost everything in that computer and it still ran like crap. To this day, I don't know the exact cause(s) of that machine's problem but that was years ago.

So what brought this on? About a week or two ago, my OpenBSD machine started displaying hard drive errors out of the blue. What was nice was the error message displayed was pretty specific which was easier to figure out but it meant that I would have to buy another hard drive. However, awhile after I removed the offending drive the error started appearing more frequently at different times for different drives. At that point I started thinking it may have a bad hd controller on the board. The board is an older DFI board that has been holding up for about 4+ years so it was plausible that the board was the issue. I was about to look into new mother boards when I thought about trying a new harddrive cable. So I pulled out an old hard drive ribbon cable and gave it a go and everything started working. I almost spent money on a new hard drive and motherboard when all I needed was a new hard drive cable. I should have known based on how that cable looked. I'm surprised it lasted as long as it did...

So learn something from this kids. Hard drive failures could be just bad cables.

Mono for all

Everytime I think about this post, I'm usually away from my machine to make it. I finally thought about it near my machine...

Ever since I heard of the Mono Project, I was always intrigued. I always thought the Mono project had a good purpose behind it. When Microsoft comes out with new software, 90%+ of the time the new software only works on Windows (with the few exceptions like Office which they port to Mac). And what's worse is that these new become popular within the workplace for whatever reason. Projects like Mono make it possible for people like me to develop .NET software on non-Microsoft platforms. One would think that projects like this would not be as good as the real thing. That person would be surprised.

A few years ago, when Mono was still in the 1.x range, I gave it a shot to see how it would look and run. If I remember correctly, they were still trying to tighten down their version of WinForms during that time which make sense because when my sample project opened, it didn't look quite right. It didn't look awful by a long shot. The fact that it opened at all was a nice surprise. It just didn't look as polished as it did on Microsoft.NET. So a few weeks ago, I decided to try out another old .NET project I had laying around on Mono to see how it would look. This time it was on Mono 2.4. This time the project came up and looked SOOOOO much better than it use to. There were still minor oddities (like text on a tab didn't show up all the way) but there was nothing that would have prevented me from distributing the project on Mono if it was still actively being developed. The functionality that I did test on my project worked just fine too. I don't use p/invoke or anything else in my projects that would tie it to a Windows machine so I don't think that much else would be broken.

These guys on this project have busted their asses these past couple years to bring .NET to non-Windows machines and their work is really shining through. If they keep it up, I wouldn't be surprised if Mono usage would rise drastically. If you haven't already, give it a try.....

Django 1.1 imported to OpenBSD Current

It is kinda old news now but it was nice of the powers that be to update the ports tree to the most current version of Django. Even though it wasn't committed in time for 4.6 (timing was off between the Django release and ports lock), it should be in for 4.7. I'm just happy that the 4.6 release will have something greater than the 0.96 version of Django.

Go ahead and preorder your copy of OpenBSD 4.6 today!!!