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!!!

It's amazing what's floating out there

Since initially toying with Lighttpd last month, I decided to set it up on my home machine to see how it can handle a simple django site. After some tinkering and some development with a site, I got it up and running. It was pretty cool. I let it go for a couple of days before deciding on checking the logs to see how they were setup. The first few lines were from me doing tests but the rest of the lines were interesting. There were many lines that looked like someone was scanning for phpmyadmin and other people looking for ecommerce components, AppServ vulnerabilities, and someone referencing a site called www.wantsfly.com. These kinds of attacks seemed pretty consistent until a few days ago when the entries stopped. The bottom line is that one must protect themselves regardless of the type of website. I was hosting at home with no advertising of any kind and I was hit with these attacks. Luckily, I don't use phpmyadmin, AppServ or any kind of ecommerce software for my site.

So read your logs boys and girls. Learn about the kinds of attacks that are out there and protect yourself from them...

Hello Lighttpd, nice to meet you

Since I've been trying to wrap my brain around web server configs for the past couple of weeks, I thought that I would give Lighttpd a try since I've read quite a bit of positive reviews of it. I must say, I wish I went this route the first time. As a test, I thought I would setup django 1.1 on OpenBSD using Lighttpd instead of the native httpd that comes with OpenBSD out of the box. I was able to get it going in about 10-15 minutes after setting up the configure files using the how-to guides on Django's site. It was nice to see that good admin login screen after little tinkering. The only draw back that took me longer than I wanted was that Lighttpd was adding unwanted items to the url that prevented me from logging in completely. However, this was easily rectified by adding the following line to the settings.py file:

FORCE_SCRIPT_NAME=""

This may be the route to take with django on OpenBSD systems from now on because of the easy to use settings. Just remember to install flup...

mod_wsgi on OpenBSD - take 2

Before we get going, I would like to point out that this information is provided to you at your own risk. You should know how to modify configuration files and rebuild programs before you attempt to perform the steps above. I am not responsible for any damage, loss of data, or loss of use if you attempt to use any of this information on your own systems.

Sorry, I have to cover my a$$. :)

Let's get this thing rolling, shall we?

As I stated in my previous post, the only ways to get mod_wsgi working with the version of apache that comes stock with OpenBSD are:

1. Recompile apache with the pthread lib -or-
2. Use the LD_PRELOAD trick to preload the pthread library before running httpd

If you are squeemish on recompiling, go ahead and use the LD_PRELOAD trick. Please keep in mind though that you need the exact path and version number of pthread for it to work. This means that you also need to keep track of the version number of pthread whenever a new version of OpenBSD is released. Example:

LD_PRELOAD=/usr/lib/libpthread.so.11.0 apachectl start

To be honest, recompiling apache is a bit easier and less of a hand cramp. Per James Turner's post, you just need to add one line to the configure file: /usr/src/usr.sbin/httpd/src/Configure. At line 519 of the configure file, just add LIBS="$LIBS -pthread". So the section will go from this:

*-openbsd*)
OS='OpenBSD'
DBM_LIB=""
DB_LIB=""
DEF_WANTHSREGEX=no
;;

to this:

*-openbsd*)
OS='OpenBSD'
DBM_LIB=""
DB_LIB=""
DEF_WANTHSREGEX=no
LIBS="$LIBS -pthread" # Add pthread library
;;

Then rebuild httpd using the following commands. This is where I had problems last week. I wasn't rebuilding this correctly...

apachectl stop
cd /usr/src/usr.sbin/httpd
make -f Makefile.bsd-wrapper obj
make -f Makefile.bsd-wrapper cleandir
make -f Makefile.bsd-wrapper depend
make -f Makefile.bsd-wrapper
make -f Makefile.bsd-wrapper install

Then restart apache. Do this every time you install a new version of OpenBSD and you'll be able to use mod_wsgi.

Afer some more tweeking of the settings, I was able to get a sample django project to run under mod_wsgi. However, it wasn't without its quarks...

When I was testing the admin site under wsgi, I noticed that none of the css or other media files where showing up. I know it wasn't the project because it looked fine when using the fcgi method. I spent the better part of a day picking the site apart to try to understand why the media information wasn't displaying. I was using alias left and right and everything in between but nothing was working. After googling for a few minutes, I landed back on mod_wsgi's site on the configuration guidelines under the hosting static files anchor. The link to the actual spot is here. Well it turns out that the only time the Alias module takes precedence over WSGIScriptAlias on Apache 1.3 is when mod_wsgi is loaded before the mod_alias module. Ok, so I shoot over to the httpd.conf file to set mod_wsgi to load first when I notice that mod_alias isn't even listed in the conf file. Wait a minute, so that mean... ahh crap. mod_alias is statically compiled into OpenBSD's apache. So in order for alias to work with wsgi is to recompile apache again....shit....

Nope, ain't gonna do it just for the media files. That's just too much work for something this small. An easier, and the recommended way per the django folks, is to just setup another site or virtual host just to host these files and point to that site in the settings.py file in the project. Like so:

ADMIN_MEDIA_PREFIX='http://localhost:8180/media/'

You can set the alias with the virtual host like you would normally, just make sure you point it to the correct chroot path where the django files are kept. On OpenBSD, this should be:

/usr/local/lib/python2.5/site-packages/django/contrib/admin/media

This would probably be a better setup anyway because you don't have to worry about aliasing the media files for every django project you do. But going the mod_wsgi route on OpenBSD, it's really the only way.

With this being said, this may be the way to go in the future. However, since mod_wsgi is not in ports (yet) and considering the recompiling needed in order for it to work, you probably won't get much support as you would the fastcgi method of setting up django on Openbsd's chroot apache server. But at least the options are starting to grow...