Local Mercurial repositories on top of other SCM systems

Hi everyone,

Big fan of Mercurial here. Enough that going to other SCM systems is seen as an unfortunate experience. For example, where I worked as an intern we use TFS. Now TFS is much more than source control but I personally don't like its approach to the source control aspect (also: I'm starting to dislike source control plugins to the IDE, but that's another day).

One of the policies is that every commit must have a separate code reviewer. That's fine, but for me made commits a hassle, especially since I started working outside normal hours (and was given limited commit access in the beginning as an intern).

Anyway, the solution is simple: I create a local Hg repository in the directory the project's checked out in and commit to that instead. Also be sure to clone it to a not-your-desktop-which-could-randomly-explode location.

The good news is that this is a very simple process. The bad news is that you of course don't gain the advantage of keeping the Hg commit history like you would with a more complex tool for this like hg-svn or something. Of course in my situation that would get the same problem of requiring reviewers.

The main use for this was to be able to commit frequently and have snapshots of the progress instead of having to, for example, shelve it in TFS. As long as you make sure to clone it somewhere that's not your local machine as well, you should be good to go.

Another time this makes sense is where the rest of your team is used to SVN and the learning curve of another source control system is too much of a pain right now.

Finally getting around to more JavaScript

Hello everyone,

Well, as part of my senior design class for computer science, we are assigned teams of four and each team gets a different project. Our project looks like it will involve a lot of JavaScript. This is good, because I am a fan of JavaScript and don't know it nearly as much as I would like. Also, I'm sick of every class project being in Java (not because I hate Java, just because I'd like to see some variety). Anyway, we're going to be doing a few small web applications that will be using a Java backend (!). Luckily, most of the interesting stuff will be client side.

I took it upon myself to set up everyone's favorite tools like Jenkins. I also had to search out a bug tracker to install. I haven't installed a bug tracker before and I have to say, some of them are a real pain to install and have a lot of dependencies. So after trying out some popular ones and disliking the setup process, I went with one called YouTrack.

I like YouTrack because installing it consists of me deploying it on Tomcat (after the install program), and I'm a big fan of doing as little as possible. I haven't worked with it that much yet but so far it seems simple enough. So if you're looking for a bug tracker with a simple setup and running a windows server, go ahead and give it a try.

(disclaimer: I don't work for them!)

See you next time.

Let's use hudson as our CI server on Amazon EC2

Hey everyone,

Since we're both lazy, we don't want to build our project manually. So we've been using Hudson as our CI server. Over the past few weeks we've been working on the build process and it's coming along pretty nicely. Here's our situation:

• 2 person "distributed" team
• Can't setup a physical server ourselves (lack of equipment and connection guarantees)
• Need remote access so we can both use it

Well, after searching around we decided to settle on an Amazon EC2 instance. The biggest reason is that you can try a micro instance free* for a year. That allows us to see how it performs in the meantime.

So we've set it up, and it's pretty decent so far. We have a ubuntu instance deployed running Hudson, with our jobs polling Mercurial for changes and building the project.

A couple things I've run into:

• Don't install ant via apt-get. Don't ask me why (maybe I'm doing something wrong), but when I install via the package manager it doesn't get all the required libraries -- it seems to be missing some tasks.
• CPU Usage - During the running of our unit tests CPU usage occasionally goes 'past' 100%. This really slows down the tests some times. Our tests that hit the db take about 2 minutes normally but took 14 minutes at one point.

I guess the problem might be solved by upgrading the instance, but it's not a big problem for us. Since the db tests only run on production builds (which run nightly) speed isn't vital for them. Our regular unit tests which run when the Test branch is changed run pretty fast.

And finally, I'd like to give a shout out to this hudson tray tracker application. It puts an icon on your system tray that shows the status of your hudson jobs. You can also bring up a window to run builds or view the output.


Hudson Tray Tracker.

 It's pretty convenient, although I wish it had TFS style build notifications where you get a pop up when every a build is started or completed. Overall though I can't complain.

Next time I will share the shell script we use to set up hudson on our instance -- this includes installing ant, tomcat, mysql, mercurial, and a couple other things. But we really want that process automated.







* actually, it seems I currently owe $0.31 for I/O requests. I still think it's worth it...

Code coverage, Hibernate integration, and other fun things.

Hello everyone,

Lately our project has been progressing very nicely. My colleague had written a small program to parse raw data into an SQL-friendly form, so we are not restricted to test data anymore. This has the nice side-effect of boosting motivation because we are dealing with the Real Thing now.

My focus lately has been on adding a comments section to the web app. In our schema, we have a few different comment tables for different types objects. Luckily in the Java code we can just make all of them derive from a BasicCommentBean so we can be lazy. I've made the comments section as generic as possible and self-contained.

With this setup, you can reference comments.jsp and set the required attributes (a comment data source namely) and everything else is handled for Free by CommentController. We also perform server-side validation on the user input and sanitize it via the apache.commons.lang library to prevent malicious code execution on the client. Oh and we have some nice ajax and animation going on courtesy of jQuery...

Now that we're using real data, we've integrated Hibernate. Oddly enough, the process was surprisingly painless, but I wouldn't be care-free just yet... I don't have a ton of experience with Hibernate, but so far it's pretty straightforward once the mappings are working correctly.

One last think: I've been experimenting with code coverage via the EclEmma plugin for eclipse. It's nicely integrated and I've used it to see how much code coverage our unit tests are providing (63% ... looks like room to improve). Over the next few days/weeks/etc. I hope to use it more extensively to improve our tests and coverage of the important parts of the project.

Multiple heads of the same branch using Mercurial

(No progress on the chemical structure tool -- I've been working on my Other Project)

Anyway, today I'd like to tell you about one of our recent problems that we had to overcome using Mercurial. Mostly for reference purposes so I don't forget about the solution, but if you find it useful that's great.

So, we've been using Mercurial for a few months now, and I personally like it a lot. However, that doesn't mean we've been without our share of "learning experiences." Recently we discovered how important it was to pull before pushing changes on a commonly worked on branch (in this case, it's our Test branch).

Since this branch gets merges from our development branches quite often, there's no guarantee that you have the most up-to-date version when you're merging with it. So one of our philosophies is to just always pull before merging anything.

Now what happens when you don't do this? Well, let's look at our scenario:

• Changes are merged into Test and pushed to the remote repository from machine A. Everything's OK 
• Machine B also merges changes into Test but does not see machine A's changes on Test.
• Machine B attempts to push, Mercurial warns that there will be two heads on the Test branch. Otherwise it would have to decide whose changes are the "official" ones, and that's not it's problem. 
• Machine B then pulls and observes multiple heads on the Test branch. 

Oops. Now, back when we were working on a group project for school, we had this problem but I didn't understand it enough to fix it. This time however, we fixed it and now it's just an inconvenience. We pull the changes on machine B so we see the multiple heads, and just merge one head into the other. Problem solved!

And everyone's happy!

Now, I'm sure some of you are thinking "duh, Chris, what's so hard about that?" Sorry guys, I'm still working on a complete understanding of Mercurial. But that's one less step we have to deal with now!

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!