Recently in Programming Category

Back in the day, there used to be a TV game show called, "Name that tune".  The premise behind the show was the contestants would state how many notes of a song they needed to identify it.  It was interesting to see people do that with one note, talk about luck. 

So fast forward to present day, a lot of times we are asked to solve a problem by programming solution.  Based on the type of problem and its solution, you may try to play the same game with a programming language.  I can solve that problem in 2 lines of Perl or 30 lines of "C", which is better?  Well it depends on the type of problem you are trying to solve, of course.  Over my twenty-some years of programming, I have used the following languages: Ada, "C", C++, Java, Perl, Lisp, Prolog, Pascal, Visual Basic, and so on.  All of these languages have their distinct advantages and disadvantages.   I think the most important part is when you try to name that tune, you are thinking about things like:

1. Will my selected language scale to the user base (current and future)?
2. Do I need to worry about any special security concerns?
3. If I pick a language like Ada, will someone be around to maintain it and/or cover for me when I am out?

You get idea, these are very important questions to ask.  Just because you can name that solution in 3 lines of Perl, does not really make it the correct solution for the problem.

Hello, its sure been a while since I have had a chance to blog about anything.  This summer sure has gone fast, with migration after another.  Personally, I'm sure glad the semester has started, so I can get caught up on other things.  Today's topic is maintenance programming, that is art of developing software to maintain existing applications and/or services.  At my previous job at Raytheon, that used to be the kiss of death.  Comments like, "Oh he is doing maintenance, well that's it for him" used to be commonplace.  Reality is, I have a friend who is doing maintenance on the same software application that I worked on 12 years ago.  My friend knows its a real killer, but he has all of the experience so his skill is needed.

As of the last two years, I am finding myself in the same boat, just doing maintenance programming.  Needless to say, I know how important it is, but in a word it can be just boring.  How do you make it exciting, other than the obivious resigning?  Well what I try to do is see if I can apply a new technology or programming language in a way that will enhance the functionality of the application.  Of course you do not want to do technology for technology's sake. 

Here is an example of where some new technology could make things better.  We have some applications that provide APIs that when called returned XML documents.  Back in the day, when I developed them, frameworks, SOAP, Web Services and so on were just in their infancy.  So doing things with a simple HTTPS POST and rolling your XML was pretty much the solution.  Now today, we have things like Web Services, and REST.  So for some of the newer enhancements, I will be looking at those technologies.  Hopefully that will make maintanance programming more exciting.

A while back I heard about SQLite from the App Engine folks in my group.  They were using it to provide database service to people, since load balancing database software is a real black art.  Anyways, for those not in the no, SQLite is a small C library that implements a self-contained, embeddable, zero-configuration SQL database engine.  More information about SQLite can be found at their home page.  The nice thing about it is the database is one self-contained file.  In addition, it has most of the features you would expect from a database like DB2 or Oracle.  So where I am using it?  Well, I needed a data store for the index information for the WebMail project.  If you remember from a previous post, I mentioned that I am writing a searching library for WebMail and was using inverted indexing.  I needed a place to store that information and had a number of options:

• flat file
• dbm and/or DB file
• SQLite

After usability and timing tests, SQLite proved to be the clear winner.  Of course that is in a debug mode.  In the real world I'm not sure.  I may have to re-adjust my implementation based on the results of further testing.  Back to SQLite, if you app needs a self-contained database, give SQLite a try. 

This morning I am going to chat a bit on the concept of portability as it relates to Web-based applications.  I have always been a big supporter of this concept.  You do not want to disenfranchise your user community by telling them, your application only runs on Windows.  As most of all you know, I was married on 5/5/2007.  On Sunday my DJ sent me a link to a site that had photos and some of the music from the reception.  I thought to myself, this is a pretty good idea.  Well I went to visit the site, and it told me I needed a plug-in.  So far, I was still OK, I realize there are things out there that need the advanced features of a plug-in.  I attempted to download it and then I became frustrated.  The plug-in only works on Windows.  At home right now, I have anywhere from 2-3 Macs depending on the day of the week and a Linux box.  As a user, I was totally frustrated.  I really wanted to view this video.  Why would the vendor do something like this?  That is a question I will not be able to answer (they have not responded to my question).  Anyways, when it comes to developing applications around keep a keen eye to portability. 

Back in the day at Raytheon, we did most of our development on Solaris and then ran some porting back to get a Windows version of our application.  That sounded like a good solution until I heard about the cost.  It was upwards of $10,000.00.  Now at the time that was the best thing out there.  Then came Java 0.1, yes I started my developed with the zero dot versions.  I developed a little hello world program on Windows and took the class file to Solaris and it just ran.  No re-compilation,  no nothing.  Now I do not plan on starting flame wars about just how portable Java is, because I know others feel differently.  But I do have a few example of software I developed here at Penn State that is still running and very portable.  The Accounts Interface is one really big Java Applet, that runs on Windows, Solaris, Linux, and others flavors of UNIX just fine.  The signature stations are an another example.  They are currently running on OSX.  My Boss and others want to move them to Linux and they are concerned about whether they will run there.  As it turns out, the signature stations started out on Linux.  My code from my Mac runs just fine on Linux. 

Of course, I just provided you with a couple of simple examples.  The same things apply to Web Applications, do not select technologies that are browser-specific.  In the long run, you will really pay for it.  My advice, is always remember your customer, because there is one of them out there probably still running Windows 3.1 or even Windows Me.  You do not want to exclude them because they are just as important as the user running the latest version of Vista.  So always be sensitive to the portability of your application.  This whole area should be addressed in your requirements and your test plans and procedures. 

The topic for this entry expresses a pretty bold statement, however its very true.  More and more these days when reviewing code that was written for various projects that I'm involved with in some fashion, I noticing a complete and utter lack of error handling.  I was talking with one of my employees and he was the one who came up with the quote, Error Handling - Its just dang inconvenient.  In reality there are two parts to this problem:

• Programmers who total ignore error handling.  This is the most dangerous of the problems.  Who cares if you cannot write a preferences file?  The operating system will handle it for me.   And my favorite, Don't worry about the memory management, it just will be handled.  Attitudes really like this create software that in some cases kill people.  There was a case a while back where a piece of software controlling an X-Ray machine emitted too much radiation and people died.  All of this was traced back to flawed software.  Ignoring error handling is mainly the root cause of a number of problems like this.  Architects of programming languages developed error returns for their functions/APIs because bad things can happen.  They are not to be ignored.  The damage that can be done by doing this could be as simple as file not be written or at the other end of the spectrum killing someone.  I cannot stress just how important it is to check all error returns and then do something about them.
• The second part of this little story is you have a good programmer checking error returns and just not doing anything about them.  Again things are throwing errors for a reason, you need to do something about the error.  If you are writing a web-based application, you need to provide your user with some sort of feedback to let them know that something has happened.  Do not and I cannot stress how important this is, display the error message from the call to the user.  Error 52 - unable to write data, is not going to mean a thing to your user.  Its also recommended that you give your user some sort of contact information so that they can report the error to you.

Now there are a number of good programming languages out there that help you handle errors.  Exception handling in Java is far superior to anything you will find in "C".  Again if you are writing a web-based application, always remember to do something to convey the problem to your user, otherwise they will receive the dreaded Internal Server Error. 

You know you are having a great day when your boss stops by and gives you a gift of a huge hunk of legacy code.  Not only do you have to maintain it, but you also have to fix all of the bugs.  This is becoming an increasing trend these days.  So how do you deal with this situation?  Well, it depends on your shop's software development environment (yes, process again).  If you are fortunate to be part of a shop that has a process, then the legacy code should be something trivial to maintain.  Why?  Well the code should have supporting documentation, it would have been reviewed, should have comments and test procedures.  Now that's the nirvana, but what's the reality?  Reality is, at the rate code is developed these days, all of these parts of the process take time, time that people do not want to spend.  Everything has to be at market faster.

So how do you handle the legacy code?  Here are some of the things that I have done in the past when I was dumped on (I mean given the privilege to maintain legacy code):

• Get the code in shape - run it though a beautifier program.  If you are programming in "C", you can use cb (the "C" beautifier).  It does a pretty code job of re-formatting the code into something that you can real at least.  Beautifiers exist for most modern programming languages.
• If its commented, then you are really ahead of the curve.  Reality is, the code isn't.  So as you are reviewing the code, add your own comments when you find out what things are doing.  Not only will that help you, but also the person who follows you.
• Adding lots of debug will hopefully help you find where those problem areas are.  However in some languages ("C" for example), add print statements can sometimes help mask where problems really are. 
  
• Rewrite problem areas - why would you do that?  Well if you know what the code is supposed to be doing and whatever there is too complex or not even close, then spending the time to rewrite the code will save you time in the long run.  I did this for a section of one of our applications last year.  The code kept randomly seg faulting, so once I figured out what is was supposed to do, I just rewrote it.
• Along with rewriting code, develop some test drivers.  Test drivers are basically tiny little applications that exercise parts of the overall application.  That way you can test your new code in isolation.  Again this is something that I do a lot when dealing with legacy code.

These are some of the things that have worked for me over the years.  Right now I'm dealing with some legacy code, porting it to another platform.  Right now things are going OK, mainly because I wrote the bulk of the code, however I did have a junior programmer working on the project.  We did have code reviews and coding standards, which helped with parts of the application.  However, over time he got sloppy and I did not have as much time to review the code.  So I ended up with what I have now, a legacy mess, which I must have ported to the new platform by the middle of June.  What am I going to do?  Keep posted as I will update the status of this project in future posts.

A while back my manager asked me to pick a programming language for our group to use for all of our projects.  He wanted something that was scalable, easy to use and perfect for rapid development.  In the past nine or so years since I have been there, I have used Perl, C, and Java for a variety of applications.  These days we have been settling in on "C".  C of course has many benefits:

• Compiler generated "machine code" as opposed to interpreted code.  In simpler terms the code is faster than something developed in Visual Basic for example.
• C is extremely extensible with all of the add-on libraries that are either free or can be purchased.
• And there are many more reasons, heck you can add your own in the comments.

Of course there is a bad side to all of this:

• Programming in "C" its easy to shoot yourself in the foot.  For example, you as the developer must do all of the memory management yourself.
• C really isn't a strongly typed language. 
  
• Prototypes, #defines, constants and the list goes on...
• And finally, just like above you can add your own reason in the comments.

So now what?  What language do you pick?  That's a really open ended question.  I did a lot of work in Java in the past and found it really robust.  Of course there are issues with platform support.  I see great reviews of Ruby and Rails.  In the past, I have used Pascal, FORTRAN, C++, Ada, Perl, and many others.  All of these languages really worked well for the situations they were being used in.  

Reality is, I'm not sure there is an answer to my boss's question, other than you have to pick the language based on the task at hand.  But hey I consider this to be an open forum, what do you think? 

The focus of this entry is going to be about how your code looks. What do I mean by this? Well, using meaningful variable names and formatting really help with making code look nice. Many times I have seen code written by others that just look terrible. As an engineer/programmer, you should be proud of your code. Painters work in oils to make beautiful pieces of art. People in our industry do the same thing with code. Let's looks at something simple as an if statement for example.

if (blah) printf("hi"); else printf("there");

This is perfectly legal "C" code, basically if blah is non-zero then hi is outputted, otherwise there is. Again this code is pretty simple, however it doesn't look all that nice does it? Here is my version of the same thing:

if (blah) {

      printf("hi");

}

else {

     printf("there");

}

Now both versions do exactly the same thing, however I am pretty proud of my version. Here is why:

1. The code is pretty easy to read.
2. By using braces its pretty easy to add additional code.  Remember the code that is executed by part of the if statement must be a single statement.
3. I will not get into a flame war about bracing style.  I use the above style because that is what I have done over the last 20 years.

By spending the time up front not only will your code be self-documenting by when you look at it 5-10 years later it will be easy to understand.  And if someone else has to look at your code, they will really thank you for spending that effort to make it look good.  Remember code is our oil for creating our art.  So be proud of your code and create some beautiful art!

OK, my blog is now published on the University's web server. Needless to say this was no small feat. I have been using blogger for a while now and its been pretty simple to use. But, the problem here at Penn State was, how do we provide a blog for everybody? My gut reaction was that we needed to just sit down and write something and reality is, I'm really good at doing that. However, in this case I didn't do that. There are a number of Open Source blogging tools out there today in case you did already notice. So, the task was to take one and form-fit it into our existing infrastructure. We looked at two of them, MoveableType and WordPress. MoveableType is written in Perl and WordPress uses PHP. WordPress is only beta with multiple-user support and its performance was less than stellar. So, I ended up using MoveableType. The nice part about all of this, if you receive the source code with the product. Nowadays, if you have source you can pretty much make it do anything you want. And in this case, the proof is in this blog. I'm writing it now in MoveableType with code that I ended up writing to make it work with our Authentication and File Systems. This is pretty cool, because I only had to concentrate on the infrastructure and forgo anything related to the interface. So, when you approach a software project, take a look and see what's out there. You may be pleasantly surprised in what you find. With a little time and effort, you can obtain something that will work i your environment too.