After a long hiatus, I finally got my blog back online. I’ve been looking into quite a few new technologies the past few months and will certainly start writing about them this week.

The other day I had a nice chat with a colleague about the benefits and pitfalls of using an open source platform. I know this subject has been discussed deeply on various forums articles and blogs. I’ve personally done research for Alcatel-Lucent and the University of Texas at Dallas on the subject. For businesses, the bottom line is cost. Their are certain scenarios in a business where switching platforms, whether its open source or not, does not make sense. The scenario I discussed with my colleague revolved around the cost of switching from a Microsoft platform to a Linux platform for its custom server applications.

My colleague’s business faces two main hurdles before considering a migration: the time it will take to migrate custom applications and the expenses incurred during the migration. If the current system is meeting customer needs and does not need further changes, then migrating over to an open source platform may not be the best choice, especially if the lifetime of the system is not close to expiring. Open source software is best used when continuous scaling is demanded. Because of the licensing fees incurred when scaling can become astronomical, development of the system needs to consider the benefits given to a proprietary solution over a open source solution. For example, Microsoft’s Visual Studio has excellent tools for building .NET applications. If the time saved from developing on this platform is justifiable and the scaling needs do not supercede the cost  saved using an open source platform, then using a Microsoft solution may be warranted.

Despite my overall excellent experience developing on the Microsoft platform, I still have a hard time recommending it as the platform of choice, mainly because of cost and time savings. These savings are not obvious to people who have not used an open platform before. One way to explain the cost and time savings incurred is the notion of barriers or hurdles towards completing a goal. When developing or deploying a system, one of the hurdles towards completion is paying for licenses, which incurs some amount of expense in time and money. If the entire application stack is free, then you eliminate that expense altogether for the rest of the system’s lifetime. This allows the complete application stack to be cloned or deployed multitudes of times, whether in a test system, developer system, or production system, without incurring the expense of time and money you would encounter in a purchased product. Removing this hurdle has changed the way entire systems are deployed and general deployment of systems in both open source and commercial projects. One simple example is Debian’s software distribution, ‘apt’. A user can script out the default software configuration for a server with one command line. For example, installing a web server, office suite, browser, a couple of games, a couple of compilers, and a IDE with one shell command. Removing the purchasing barrier also paves the way towards completely automating the scaling of a system’s infrastructure. For the small software vendor, you just can’t do that on a Windows platform.

After sitting down and creating a javascript client, I have to say – this really sucks. I guess moving to a heavier client tier is a natural progression of web development. Back in 1996 or so when I was still in grade school, I started messing around with HTML and basic CGI scripts for creating dynamic web pages. About 2 years later, MySQL became really popular and the first database generated web sites started to appear. The big argument back then was whether application logic should be done in the database end or in the application tier. The languages and platforms I was aware of in the open source world were Perl and PHP3 – both were equally terrible web development tools. These weren’t the only open source tools out there at the time, rather quite the opposite. There was a huge plethora of different web platforms out there. Some still exist but still obscure – others just obscure. Let’s just say things were weird because everyone was still trying to figure out the best way to develop web front ends. For example, it wasn’t unheard of to hear SQL being used to generate HTML.

After PHP4 came out, there was an explosion in web development around the PHP, MySQL, and Apache application stack. About this time, most of the dynamic page generation got moved to the application tier.  Fast forward about 6 years later to the present, we’re seeing more of the page generation executed in the web browser using Javascript or some other platform built into the browser. There are numerous advantages that can be gained by moving page generation to the client: lower load on the servers, improved visual enhancements, and faster execution speed. However, developing interfaces in javascript still feels immature. To me, client side development in javascript is about equivalent to what PHP4 was back in 2001 – it does the job but has a lot of room for improvement.

This doesn’t mean the javascript engines found in IE and Firefox aren’t mature, its actually quite the opposite. Since Javascript has been incorporated in the browser since the 1990s, the engine is very mature and stable. It’s just new requirements and forms of usage for javascript has changed since its original inception, hence why I think the current implementation seems incomplete. By incomplete, I mean issues such as browser compatibility, the occasional memory leak, and I still think development tools have room for improvement, like code completion and debugging.

The current application I’m working on uses the ExtJs framework for generating the Admin UI and Django as the middle tier for parsing requests between the client and the database. So far, the combination is working well.

The other day somebody in the neighborhood dribbled touch up paint all over my car. Judging from a bottle of paint that was left near the crime scene, I think it’s lacquer-based. After pondering what to do, I consulted Google and ran into this post. It explained that I should use something called Goof-Off for removing the offending paint. This stuff really does work, however, it takes quite a bit of elbow grease to get the paint off.

At first I used Q-tips to remove the splotches of paint, but I found that it was easier to just use a soft paper towel. It took about 2.5 hours to remove all the dribbles and spots. The only word of caution I can offer to anyone out there when using ‘Goof-off’ is to take it easy on the pin stripes. This stuff is powerful enough to take the stripes off (which is bad), but not powerful enough to get through the clear coat (which is good).

After 2.5 hours of rubbing and cleaning, the paint was taken off without any problems.

I finally deployed a Django application to a public facing Linux server. You can read all about it in a write up below. For those of you who don’t know what I’m talking about, Django is another ‘rapid application development’ web framework that comes with all sorts of useful tools to help web application developers get their software finished faster. Some of these time saving features include an auto generated administration tool, an ORM object mapper, and a template engine.

So how does developing on Django compare with development on ASP.NET? Well, for non-MS Office related development I would say it is faster and more suitable for custom applications. Alot of this has to do with the object relational mapper, which accomplishes the same things as Microsoft’s Dlinq, and the generated admin tool. These two features alone completely remove a large amount of coding that usually has to be done when creating an ASP.NET application.

I highly recommend anyone out there give Django a try. Check out this tutorial for a quick introduction.

New Article

• Python: How to Setup a Django Application on Apache 2.0 with mod_python on Ubuntu Server 7.04 Fiesty

In any engineering project, finding the cause of a problem can be just as hard as fixing the actual problem. Today our garage door broke, so my roommates and I tried to fix it. At first we thought the problem was caused by a broken axle on one of the track wheels. After inspecting the plate, we quickly found out that the axle was just fine.

Then we decided to inspect one of the guide wire wheels. The guide wires were definitely incorrectly configured. We found that the wire had not re-wrapped itself properly, causing the motor to push harder on the garage door when closing.

This still didn’t explain why the door wouldn’t close though. Stepping back to look at the garage door, we quickly realized that the two sides were not falling down at the same rate, causing one side to close faster than the other – warping one of the guide rails.

After examining the brackets that secure the track wheels to the door, we found one of the brackets had cracked. This created a harder ‘push’ on one side than the other when closing.

The end result is this:

At this point, we decided to call the repairman.

New Articles

• Review: Shreveport, LA – Eldorado Casino and Horseshoe Bossier City (Shreveport), LA
• Apache 2.0: Setting up a Virtual Host or How to Setup Apache to Host Multiple Websites on a Single Server

Back in the day, I use to sling code in 2-3 hour blocks, taking nice long breaks in between sessions. This allowed my brain to think about problems deeper and come up with more elegant solutions. One of the reasons is that the house I am in turns into a noise making, hard rocking, garage band around 5 PM when all my roommates come home. Homes with children experience a similar event. In any case, I code late at night or in the mornings when no one is home. In fact, I try and code for as long as I can because I know these periods of peace and quiet don’t last. I guess the 2-3 hour programming sessions will be on ice until ‘quiet time’ becomes the norm again.

New Article

• Getting Around Linux: PostgreSQL’s ‘COPY FROM’ and Permissions in the Home Directory

Software developers are notorious for having different levels of skill. Along with that are the various types of software developers, stereotypes, preferences for work environments and unfamiliar skill sets. These factors can put any recruiter or HR representative into a conundrum.

A good parallel for recruiting software developers is the NBA draft. The only people who can really tell you which potential draft candidates fit the team and will perform well are either other players who have played with the draft candidates, coaches and scouts who have watched some of these players like hawks for the past months, and to a lesser extent, religious fans who follow the games. When interviewing for a software development position, most interviewers have never even seen a single line of code. Even worse, some interviewers are terrible developers themselves. I say this is worse because bad software developers are like bad basketball players. No one wants them on their team for a reason. Either because they believe in some terrible methods in developing software or their understanding of software development is just plain wrong. (Imagine a guy who thinks the wrong answers are right to all his questions.)

So how do you tell if a software developer is good at all? The same way players make it to the NBA draft. Getting really good at what they do and having something to show for it. Decent developers will have a track record that can be confirmed by third parties such as co-workers, actual working products, and satisfied users. Other software developers can look at a peer’s work and can immediately tell you if their work is poor, decent, excellent, or phenomenal. A comparison can be made between plays made by Michael Jordan and the plays made by the star high school basketball player. Both look pretty good depending on the context, but you need someone who knows what they’re talking about in order to even know the difference between phenomenal and decent in both areas.

I draw a comparison between professional sports players and developers because I believe the skill and talent levels between great players and good players are just as huge in both worlds. A basketball player on a NBA team is pretty damn good compared to 95% of all basketball players in the entire world. A software developer who is of certain (genius? excellent? hacker? I’m not even sure what they call these types.) caliber will produce programs and solve technical problems 95% of software developer can’t even comprehend. People recognize Michael Jordan for his talent and skill because he was much better at basketball then everyone else. People recognize legendary software developers for their similar prowess and skill. Some of these skills are just as publicized in the media. Here’s a few examples:

• Napster was created by one guy in college because he wanted to share music. Not a whole lot of people can create a peer to peer network single handedly back in the 90’s. The idea was new and the ability to share music as freely and with quality has never been the same.
• Copying DVDs. This was done thanks to the work of a few guys, even so, it still takes talent to understand how to reverse engineer anti-pirating security schemas. Even though, these guys argue that the protection scheme was pretty weak.
• On a related note, one guy did crack the HD-DVD encryption scheme himself. Why are either of these last two accomplishments important? It has allowed pirates to copy movies at will. Something that hasn’t been accomplished since the invention of VHS recording but now with higher quality and larger distribution channels.
• Bit torrent. This took some thinking and understanding of networks in order to implement and was implemented by one person. I’m willing to bet most software developers don’t have a clue how this thing even works.

So what’s the big deal if a person can reverse engineer a multi-million dollar anti-pirating countermeasure or give people the ability to distribute millions of files at a time? These last two inventions have allowed people to enjoy and use their computers in ways that weren’t possible before. Business types call these things innovations which can have the potential to bring in millions of dollars, just like an NBA basketball team that wins a championship equates to millions of more dollars for the owners. This is why recruiting software developers is a big deal, even if most companies don’t know it. Because in the end, you can’t have a great company without great people.

Last week was pretty dull. As you can tell from my posts, its been dominated with the migration over to Linux. Eventually, I want to port this blog over to an open source platform. I’ve looked at a few and some of them have been fairly impressive. WordPress, Snurf, and b2Evolution are some of the candidates I’ve been considering.

On Saturday, I decided to visit some friends in downtown. I ended up at a bar called Petrus. You can check out what I thought about the place here.

Sunday I decided to take a break off of O.S.S. programming and look at some good old fashion .NET programming. The problem I was contending with that day was a lack of a Windows Client for Amazon’s S3 Storage Service. After doing a quick scan through Google, Codeplex, and Sourceforge, I did not find any free programs for interacting with this service. In response, I decided to whip up an interface. Admittedly, the interface is in rough shape right now. I just wanted to get something up quick and working. Before I release it into the wild, I’m going to clean up the interface a little bit. By clean, I mean move a few labels around. (what’d you expect? Its free.) This will be released by the end of the week – source code and the installer.

On a different note, today I had to learn about arrays in PostgreSQL. I needed to figure out how to do batch updates without the use of delimited strings. An article has been posted about this topic.

New Articles

• Review: Petrus Lounge – Dallas, TX
• PostgreSQL: PL/PGSQL, Arrays, and Batches

*Update* 5/29/07

Source and Installer for the Windows Client has been uploaded. Please refer to the links below:

• Installer  – EasyUpload for AmazonS3 – (Recommended) If you don’t know what ‘Source Code’ means or don’t need it, use this link – not the one below.
• Source Code – EasyUpload for Amazon S3