Saturday, February 18, 2012

Not bad for a birthday party.

Lisa's birthday party featuring Virgin Mary, fire-spinners and a lot of drunk physicists. Thanks to everyone who showed up! Many thanks to all the performers!

Happy birthday sweetheart! 

Monday, February 13, 2012

i915 finally (mostly) stable

Its been two months since I got my UX31 zenbook, and nearly a year since the sandy bridge CPU/GPU combo chips hit the market. Initially the linux support was very much lacking: with the rc6 powersaving enabled I was getting random graphics glitches and reboots, without the power-saving options I was getting 2.5 hours of battery life plagued by less frequent reboots.
This all changed with the a string of commits by Daniel Vetter to the 3.2.6 kernel tree. Having compiled this kernel I did not experience any more crashes, graphics glitches, and the battery life is now solid 7 hours.
I would like to send a warm thank you to Mr. Vetter for making my laptop usable for software development.

Sunday, February 12, 2012

Laptop Ants

I turned on my shiny new ASUS zenbook this morning only to find that it got very buggy. Around 50 very tiny ants spilled out of the cooling vents instantly, followed by a steady stream of about 10 a minute. One might make an argument that the are doing me a favor by cleaning out the dead skin sells and microscopic bits of food which get trapped in the keyboard, however spilling a cup full of ants during say a meeting with my PI might look a bit unprofessional....
In order to remedy the situation I am going to try to run the cpu/gpu at full speed and frequency until its toasty 89C. Hopefully ants will get the hint and decide to abandon their new found home. Wish me luck.

Sunday, January 29, 2012


Clock distribution for ADCs is hard. Especially so if your design requirements include less then 20ps jitter and more then 10 channels. Luckily IC engineers at TI came up with pretty awesome of the shelf solution. CDCE62005 is a 5 channel LVDS compatible clock generator/cleaner, which promises1ps jitter, and up to 1.175 Ghz operation, and easy SPI control. Furthermore at 20$ a piece it wont break your budget.
Cajipci parts are mostly picked out, as long as the specification review goes well, we will finish schematic capture and move to layout in a couple weeks.

Thursday, January 19, 2012


 Another semester, another set of responsibilities. This time I along am tasked with developing a CPCI circuit board with capable of programming, distributing a clock to and possibly triggering a neutrino detector.
I have written PCI drivers and firmware in the past, however this is my first attempt at creating a circuit board. You can follow my progress at:
The board name is CAJIPCI which stands for Clock And JTAG In PCI. I tried very hard to come up with a witty acronym, but this is the best I can do.
So far all I have been trying to figure out the circuit board CAD software called PADS. PADS is a very nice and complete design suit, however I have a couple gripes with it:

  • Only runs under windows. It would be nice to use eagle, but we don't have the license for it.
  • As with all design software stability leaves much to be desired.
Hopefully if this goes well our group will have a working detector by the end of summer. Wish me luck, and till next time.

Wednesday, December 14, 2011

Lessons learned from continuous integration.

I spent a better part of my semester studying continuous integration. I started by participating in a team exercise to build client software to communicate with a Wattdepot server. Then each teams switched and reviewed each others work based on the documentation, issue tracker, build server statistics, and of course the quality of code itself. Finally we extended the other teams code base by adding additional functionality.
Original code was completely synchronous: once user entered a command he was presented with the output and redirected back to the prompt. The new functionality however had an asynchronous component. We implemented the following additional commands:

  • monitor-goal : Monitors power consumption and output whether it exceed the baseline value. 
  • set-baseline : Allows user to set the baseline for monitor-baseline.
  • monitor-power : Monitors power consumption and outputs it to the screen with a time-stamp.
Monitor command executed in a loop at a given interval, waiting for user to hit the return key, while set-baseline returns immediately after the baseline is set.
I found this portion of the exercise to be my favorite. Not only was I working on top of a well build system, but the problems at hand were no longer trivial.(In fact I think we might have over-complicated the implementation.) There were two main challenges in this project:

  1. set-baseline and monitor-goal need to communicate the baseline values.
  2. monitor commands need to run asynchronously and at a given interval, while waiting for user input.
We solved the first problem by implementing a singleton class which maintained a map of baselines for various location we were able to monitor. The second problem was solved using threads. Once the input to the command was processed, main thread would start a worker thread and then sleep and periodically while checking for user input. The worker thread on the other hand would sleep for a specified interval, perform its task and then go back to sleep.
I found the other teams code base well documented and easy to understand. In order to make my new command available to the system all I had to do was change one line! Makes me feel foolish for implementing internal reflection in our code. The only complaint I have with the code-base, was the command unit testing. All tests for commands were inside a single class. This works well, if there is only one person working on the commands, however with a team of three people editing a single file we were bound to have version control nightmares, so the tests were refactored.
I mentioned the three pillars of software engineering on this site before, and I will mention them again. The first two are fairly easy to test: all you need to do is try to use the software. The last one however requires some work. In order to check if a software project is developer friendly one must dive into the code and documentation, and piece together what the original developer was thinking. This can teach you quite a bit about software development, or make you long for a new career.
Working with third party code is always an adventure. While most open source projects come with a well groomed code-base and excellent documentation, some of the more obscure projects will make you wish you implemented them from scratch. Luckily this time developers put a lot of work into the project, and it shows by how easy it was for our team to make it even better.

Thursday, December 1, 2011

Three pillars and the quest for intelligent group software development

I mentioned three pillars on this blog before. They provide a very simple methodology for judging quality of a software project. My software engineering class is currently covering continuous integration so my hale-aloha team decided to apply the three pillars along with some concepts of continuous integration to our software projects. I attempted to analyze a wattdepot project located here. This software project had the same specifications as my wattdepot-cli, however the implementation is entirely unique.

Does the system accomplish a useful task?

I was able to install the software by downloading the distribution package from the projects download page and running the provided jar file. On execution I was greeted by a friendly message:
Connected to the Hale Aloha WattDepot server.
Type help for a list of possible commands.
cli >
The help command provided a nicely formatted help message describing each available command. I was able to execute all of the command, and the data returned was in the ballpark of what it should be. The only problem I encountered with valid input was that the daily-energy, energy-since, and rank-towers commands did not support current date as the argument.
On the other hand I found that the error checking on the input could use a bit more work. Using Wireshark I found that the program still made a request to the server even if I pass an argument to the future(2034-11-30), or an argument which matches the regex but makes no sense as a time stamp(2011-11-88). Instead of validating the dates on the client side, this project uses the server as the error checking mechanism. On the bright side if a wrong number of arguments was passed to the program, it behaved as it should, by printing the associated help message.
Overall I think this software project produced a nice and usable program. Unfortunately the time constrains associated with the development resulted in a couple rough edges.

Can an external user can successfully install and use the system?

As described in the first question I was able to download the distribution archive from the downloads page. The user guide included installation instruction and the software requirements for the package. With Java build once run anywhere model I was able to get the code up and running with minimal hassle.
Furthermore the version number of the build was attached to the jar file for easy identification.

Can an external developer successfully understand and enhance the system?

Developer guide is packed with helpful info. It provides guidelines for submitting code, supplied a links to a build server, as well as requirements for code submissions. Furthermore developer guide provided instructions to build Javadoc documentation.
Documentation build without a hitch and it looked complete and thorough. In fact it was so clear I was able to understand the inner-working of the program just by looking at the generated documentation. All of the class names indicate their purpose. Furthermore a standard command interface provides a very easy to implement additional commands.
Software is complimented by a large array of tests which provide 83% test coverage according to Jacoco. Tests covered all of the relevant functions and were almost always well partitioned. However the test for the current date are missing from the source, which I imagine is the cause of the errors I was reciving in question 1. It seems that while the test coverage is almost perfect, however it may be beneficial to re-partition the test cases.
After examining documentation I build the system from source via the directions provided in the developer manual. It build without a hitch and ran just as the provided jar. Furthermore the system verified successfully using the ant verify directive described in the documentation.
At that point I finally dove into the code. I found that the code base was well commented and followed the required guidelines. Methods and local variable names were well selected, and descriptive. There were no god classes, and no dead code.
Next I examined the issue page. I found between the two developers the work was divided evenly, with one developer working on the commands and the other working on the command interface and command processor. I would think that a novice contributor could use the Issues page to determine which developer would be the best person to communicate with on a specific topic.
Finally I checked the continuous integration server. I found that all but one of the commits to the source were done for a specific issue, which goes with the main methodology of the continuous integration. While there were several days(Nov 23 – Nov 25) where the build was broken, it can be attributed to a hale-aloha server crash.
I think that the developers put together a well build ecosystem for software development, and set an excellent example for new developers. I don't consider myself a strong Java developer, non the less I was able to follow the development flow, and software design that my classmates put forward.