Putting your old code to use in a new project

Hey everyone,

For the past few days I've been working on a chemical structure drawing tool, and even though I don't have that much time to work on it this week I've still been making progress. Now, I'm a really lazy programmer, so naturally any code from other projects that I can incorporate shall be incorporated. So it was a really tempting idea to borrow the structure rendering code I wrote for my chemical database program. (Aside: I wrote it last summer and I think the code is terrible ... how things change)

It was a nice setup at the time, there is a Renderer class which handles the actual drawing (via GDI), and a CompoundViewer class which updates the renderer, handles support for more than one compound, allows selection, deletion, etc., and more useful things. 

However, there are several problems that were keeping me from just dropping it in:

• CompoundViewer uses different representations of structures than I'm using now (the old approach was comparatively sloppier) 
• Chemical bonds store the index of the atoms they are bonded to instead of pointers (as they do now) 
• A lot of methods in the old implementation of Compound are absent from the new implementation

 Still, it seems a shame to have to rewrite something that works well. Plus, the code has had numerous fixes for odd issues that I would probably overlook when rewriting. So instead of rewriting the rendering code, I kept it and scrapped the rest. The reasoning? CompoundViewer contains a lot of functionality that is heavily coupled to the old implementation of Compound, and refactoring it would probably be more trouble than it was worth.

To salvage the Renderer class, I added three new interfaces (ICompound, IBond, and IAtom), and the new versions of these classes implemented them. The required methods/properties that went into the interfaces came directly from what the Renderer class used. The good news is that this turned out to be very painless, and each interface only contains a few methods/properties. I was able to get a test up and running that rendered a simple compound correctly.

When I begin on the GUI side of this project, I won't have to rewrite the important code that actually draws the compounds. As a bonus, the Renderer class maintains compatibility with the old versions since they implement the interfaces already. It's like you win twice!

Chemical structure drawing with C#/VB.NET and TDD

So a little fact about me: I picked up chemistry back in 2007 and I really enjoy the subject*. Naturally I like to apply software development to chemistry-related problems (see my chemical database for an example).

I figured "hey Chris, you haven't made your own structure drawing tool yet," and it would be a good fun learning experience. Right now I'm using a C# back-end for all of the logic and plan on using a VB .NET UI front-end just to pick up the language. Also, I've really been trying to get more out of TDD and practice it more. I've tried to stick to it and so far it's going pretty well, although there is room for improvement.

I also finally decided to pick up AnkhSVN, which provides integration of Subversion into Visual Studio. So far it's working pretty well.

Anyway, here's some of the things I hope to implement:

• Basic editing: adding/deleting of atoms and bonds
• Support for adding fragments at once instead of having to create them each time
• Saving/loading of structures in some common formats
• (possible) integration into my chemical database program since it currently relies on an external editor

We'll see how far that goes, hopefully I'll have some screenshots too. Unfortunately it will probably be slow progress since I'm being bombarded with assignments this week (chemistry professors here seem to like homework as opposed to projects, which CS professors and I prefer...)


*My favorite experiment was distilling liquid bromine from KBr/H2SO4/H2O2 solution ... good times. One of  my general chemistry professors even helped me improve the process

LogMeIn: A remote desktop program to solve all your problems.

I'm going to tell you a sad, sad story. But it has a happy ending.

Once upon a time there was a college student who had a laptop. He doesn't have a desktop, just a laptop that's used for everything. Now he carried this laptop around for about ~6 months. During this time period, the AC adapter started to do funny things. You had to move it around in weird places to make it charge, pray over it, and hope for the right phase of the moon for it to work. Other compatible AC adapters worked fine (it's good to have computer science friends), so it was definitely the culprit.

So he got another one. This one came with a light, so he could know if the AC adapter was working. And everything was good for another few months. But then funny things happened again, only this time it wasn't the AC adapter. It was the connection between the laptop and the AC adapter this time, and that wasn't a very nice thing. You had to wiggle it around to make it work, so he looked very foolish when having to work with his computer science peers...

One day, after acquiring a second monitor, he decided to permanently ground the laptop. Stuck it on a desk, hooked everything up, and just leave it in one place. So now it's a desktop. A really bad desktop.

A problem remained: How to do programming related work when all of the cool tools (Visual Studio, eclipse, source control, various libraries etc.) were on the laptop?

His solution: remote desktop (but not the Windows remote desktop program, since you can't remotely connect to a computer running Vista home).

So there are a lot of remote desktop programs out there, and I'm going to share my experiences using LogMeIn, an RDP that's very convenient (and includes a free version).

I've been using this program for several months now, and here are the highlights of it:

• Easy to use UI -- a nice thing to have
• Plugins for IE/FireFox on Windows and Macs -- Convenient, since there are plenty of those systems on campus.
• Java front-end -- A big plus when you can't install plug-ins, I've used it on RedHat Linux, Windows, and Macs. No installation of any components necessary.
• Seamless -- supports clipboard transferring, audio, file transfer, etc. 
• Multiple monitor support -- You can switch between them
• Free -- with restrictions, but adequate for general use

 I've used this program a lot for working on projects through Visual Studio and Eclipse, and the experience is very nice.So if you're looking for a good RDP, go ahead and check out LogMeIn.



Disclaimer: I was not paid by anyone to write this up, I just really like the software!

Code review, refactoring, and more...

Today I want to tell you about ensuring that code is maintainable.

Now, in our project we have a Servlet that reads in requests for graph plotting using jqPlot, and it sends these requests off to a GraphsManager which is responsible for making the data into a nice jqPlot-compatible object that can be JSON serialized and sent off to the client.

The code in GraphsManager is a little hairy -- this is because it makes heavy use of generics and some reflection to ensure that it's very general and can work with many different data sets.

Even though our code base is small right now, it still has the ability to become unmaintainable to anyone who didn't write a particular piece of code. So we want to avoid that by having regular code reviews where we share the pieces of code we've written, go through what it's doing (and why), and refactor it to make it more readable and maintainable.

In going through GraphsManager, even simple changes like replacing confusing if conditions with a helper method that has a very clear name, we can make the code a lot more readable for someone that didn't write it. We also discuss why the particular approach was taken, its pros/cons, and possible alternative solutions.

Anyway, we did this at our meeting the other day and I felt it was really constructive. In fact, I'm thinking about refactoring it soon using an entirely different approach that will make it a lot nicer. It also helps that GraphsManager has an extensive series of test cases that will ensure we don't break anything.

So the moral of this story is: Code review is good, and going through your code with someone will reveal its flaws and possible improvements you can make to it.

Hosted issue tracking with Eclipse integration

Alright.

Since the project we're working on is a good size, we've decided to go with an issue tracking solution instead of trying to remember everything. Since neither of us can guarantee uptime on a private server with an issue tracker (such as Bugzilla) installed, we resort to hosted solutions.

And since we're just starting out, working on a free project (for fun), and have limited funds, we would like a very low (== free) cost solution as well.

And finally, we've gotten into really making our IDE integrated. We have our source control plugin (MercurialEclipse), Ant (automated deployment), and it seems natural to have an integrated issue tracking solution as well. Luckily, Eclipse comes with Mylyn, which provides an interface for issue tracking inside Eclipse. So all we need is an issue tracker that:

• Is free for 2 people
• Is hosted
• Has a Mylyn connector for Eclipse

We would also like it to integrate with Mercurial. But you can't have everything.

After looking around and almost giving up, the solution I found was Unfuddled.

Let's take a look at what they offer compared to our requirements

• Free for 2 people? Yes, <= 2 people get the issue tracking for free
• Hosted? Yes
• Mylyn connector? Yes, and it's stable and has good documentation. 
• (just for fun) Source control integration? Git and Subversion. So no Mercurial. But it's hard enough finding a solution that fits the first three!

So far I'm pretty excited about using it, it seems very useful and what we're after. But let's see if I think the same thing 3 months in the future... 

Implementing interaction between jQplot and java servlets

Today I'm going to share my experiences developing a way to let users plot graphs of certain interesting data.


Way back when, we originally were going with the Google chart API to accomplish this. It's simple and it looks good. However, we decided instead to take a jQuery approach (for learning and to avoid making a call to a second server) with jqPlot. jqPlot is a free graphing library which generates the graph on the client side and accepts data in a convenient format.

After playing around with it, we were able to develop a nice implementation:

Now aside from a few things that need to be worked out (such as fractional years), it looks good and was very simple to implement. Our approach to this using java servlets was:

• Client sends an AJAX graph query to the GraphsController class with a parameter ("getgraph") set to true to signify a graph request
• Servlet gets request, builds a GraphRequestBean and validates it. If validation fails the server sends back an error object using the JSON library for Java called google-gson. 
• Servlet sends request to a GraphsManager, which generates the Graph by interacting with the data layer. 
• Graph is sent as a JSON object and is read by the javascript, where a call to the plotting library is made. 
• User gets nice looking graph

 We also added some error handling and the ability for users to regenerate the graph through a link. I'm pretty excited about this implementation (and jQuery in general...) because it worked very well. And also I have even more respect for unit tests because they saved a lot of time debugging, since I was constantly changing code around while developing.

Version Control: MercurialEclipse and ... Eclipse

Alright. I love Mercurial. I admit, I was an advocate of Subversion on solo projects (and actually, it's still good for solo projects) but when I started working with a team, I ditched SVN in favor of Mercurial.

Now I'm not trying to just blindly jump on the DVCS bandwagon here, and I'm not going to try and convince anyone. However, having used both SVN and Mercurial on a Windows system, I prefer Mercurial. So naturally on my latest collaborative project we decided to go with Mercurial. Since we're developing in eclipse, we decided to use the MercurialEclipse plugin.

For the most part, it's working quite nice. We've come up with this structure where we each have our own development branches, and then a test and production branch. We try and interact only through the Test branch so we can have our own changes going on in other branches. And it works most of the time.

Unfortunately, it's that other 10% of the time that causes us 80% of the headaches. Now we're probably doing something wrong, but early on in the project an Eclipse .classpath file got committed into the repository and has caused us our share of pain. The .classpath file contains all of the included libraries for each project. So here are the things we've experienced:

• conflicting .classpath files get committed since we have different workspaces
• attempting to ignore/delete the .classpath file from the repository results in its deletion  from the file system. Oops. 
• switching branches sometimes results in .classpath problems. 

Actually, these problems are a function of our workspaces being different. So we changed that:

• Our workspaces are now the same
• We use relative file paths for including *.jars 
• We once again commit the .classpath file to the repository

The difference now is that the .classpath file is the same for everyone, so we no longer experience headaches caused by having different paths. 

Design issues: Keeping it simple and practical

On the project I'm collaborating on with a former classmate, we are really trying to make some good design decisions. Stuff like:

• Code reuse
• Decoupled design (ie. data separate from domain) 
• Testability (programming to interfaces) 

At the same time, we want to keep the design simple and easy to follow. One of the things we were trying to solve was handling very dynamic queries in an elegant way. And we came up with a solution. And it was elegant. It had everything based on some common interfaces, used generics to handle them, and even reflection sprinkled in.

And then we got rid of it in favor of a simple, more practical solution. 

Actually, he proposed the simpler solution. His solution was based on his practical experience developing applications. Although our elegant method would have been pretty cool, it would be less maintainable and take longer. And remember that in the end, your users don't care about your elegant solutions. They just want your stuff to work.

Interesting observations when putting your software up for download

I've had a few programs up for download as freeware on popular download sites (such as download.com). In fact, my latest program (HTML Combiner) is up there now as well. On my website, I also employ the free statistics tracking software called statcounter.com (a great service).

I'm always amazed by the diversity of people visiting my website. A look at the stats reveals people from across the world, using different OS versions, and especially the site linking to them. A couple interesting observations:

• Most people (> 50%) of my visitors are using Windows Vista/Windows 7
• Although the majority (60%) are from the US, that leaves a significant portion from other countries
• The referring links come from websites that are hosting my software when I haven't submitted it to them. 

I thought the last point was really interesting. There are a lot of software download websites that seem to just pick up the programs and host them without notifying me. Now I'm not giving any specifics because to be honest, I don't mind the traffic and my programs are free anyway. But if they weren't free, I might be more interested in this observation.

This is recurring for each program I've put up for download (3 of them...) and interestingly I find them also posted on warez websites (by a google search) even though my programs are totally free!