Yahoo! 360° News | Beta Feedback
Start your own Yahoo! 360° page

Mark Waite

Top Page  |  Feeds  |  Friends  |  Lists  |  Groups

  • Work: Parametric Technology Corporation
  • School: Utah State University

Add

Mark Waite is not connected to you in Yahoo! 360°.

Last updated Mon Sep 01, 2008 Member since November 2005

Made the release date, and its been a wonderful Christmas break.

1 - 5 of 227 First | < Prev | Next > | Last

Mark Waite's Blog Full Post View | List View

Agile software development, software testing, cycling, children, and family are my interests

Assembling Christmas

Coleen gave me $500 for Christmas so I could buy parts and assemble my own computer. It has been great fun so far!

Choosing the components within the budget was great fun. I spent several enjoyable hours wandering through newgg.com to choose the right mix of components for my expectations.

UPS Slows The Day

After choosing the components, I placed the order the day after Christmas. The newegg site said it would be "3 day shipping". I hoped that included the weekend so the box would arrive 29 Dec while I was still off work, relaxing. No such luck. The complete set of parts finally all arrived about 6:00 PM January 5, 2009, a week after I had hoped to receive the parts. No problem, but it meant I had to assemble the computer after work, and amidst the hustle and bustle of a regular school and family schedule.

Power Supply Ignorance

I learned that the ATX power supply will not "switch on" unless it is connected to a motherboard or has two of its pins shorted. I also learned that I am quite capable of failing to assemble something which the manual calls "foolproof". Apparently I'm more of a fool than its proofing.

The first assembly steps put all the parts into the case, connected the power, and "nothing". No response. No noise. No spinning, whirring, or chattering.

I read online about the requirement for ATX power supplies to have two pins connected before they will deliver power. So, I disconnected everything, laid it out carefully, then reconnected everything, checking the power supply during early stages of the connections. This time it worked.

Mistakes I Made

I assumed that if a connector fits a "fail safe" 12v 4 pin power connector, it must be the right connector. I was wrong. The correct connector has a spring clip retainer which my incorrect connector does not.

I also installed Windows Vista Ultimate x64 Edition (from the license I bought at Microsoft several years ago). The network card had no drivers in the standard Vista media, so I had to use the vendor disc to get the network card running. I hope OpenSUSE and other operating systems are able to identify the LAN card...

More fun is coming...

Thursday January 8, 2009 - 11:34pm (MST) Permanent Link
Ode to Randomization
I've been using more randomization in the automated tests I write. There are several papers which describes test randomization (like "fuzzing") on large projects (like C compiler testing, operating system robustness, and security tests), and I wanted to apply the same ideas to the small tests I write in my spare time.

Instead of always allocating an array of exactly the same size in my test, I decided to select random values within what I thought were the known system limits for that array. The tests ran happily for an extended period. Recently, a test failed. The upper limit I thought was a correct upper limit was a little too large. The test had taught me about an upper limit without requiring that I research every single limit in the system...

There are pitfalls in this form of randomization, like
  • Problems are only discovered when the random values are chosen which exercise the problem, and that may be infrequent (or never). A random value test is a weak approximation for a test which is explicitly exploring boundaries
  • Random values require that all failures must be checked in every test run. Since I like continuous integration (currently using Hudson), that is not a problem for me, but if you have a suite of tests which do not run reliably, the investigation time may be expensive
  • Writing randomized tests is more work than writing fixed value tests since I have to learn how to randomize values and still be sensible
  • Good failure messages are especially important in random value tests because the failure needs to report the actual values used in that specific test run
Thanks again to all those who share their testing experiences!
Wednesday January 7, 2009 - 08:37am (MST) Permanent Link
Hudson Xvnc surprise
Hudson Xvnc surprise magnify
My Hudson experiments have been very interesting. I was delighted to find an OpenSUSE ready installation package for Hudson on the OpenSUSE Build Service. I added the repository http://download.opensuse.org/repositories/devel:/tools:/building/openSUSE_11.0/ as an OpenSUSE repository, then installed the hudson RPM. I configured two projects with the web interface, one a trivial Java junit experiment (as a baseline) and the other the real program I'm using for the experiment.

The trivial Java experiment lets me see how Hudson presents test results in its default environment, and how Hudson is configured in its default environment. I can watch Hudson checkout from the git repository which hosts the simple case, and see the results in a few seconds on the Hudson web interface.

The second project is more complicated because it starts with 100k lines of C code and 250k lines of Java code. The C code was once ported to Linux, and behaves reasonably well on Linux. Unfortunately, the port was done(and abandoned) before we decided that writing automated tests was important.

When I started adding some simple automated tests, I needed an X server to use during the tests. Hudson has an Xvnc plugin that I installed (installing plugins is so easy in Hudson, it was a few clicks on the web interface and I was done). However, the Xvnc plugin did not run...

I finally tracked what I believe is the root problem. The Hudson call to Xvnc seems to need the HOME variable set correctly, and for some reason the environment I was using had set HOME to /root instead of setting it to the home directory of the hudson user.

I added a setting to /etc/sysconfig/hudson:

HOME=~hudson
USER=hudson

I suspect that is not the correct way to solve the problem. Eventually I'll have a conversation on the hudson mailing list to understand how they typically run hudson on Linux.

After restarting the server, Xvnc now runs and the tests now have a dedicated VNC server for tests. Thanks again to the Hudson team!
Monday December 29, 2008 - 12:15pm (MST) Permanent Link
OpenSUSE 11.1 Upgrade Progress
I had been running OpenSUSE 10.3 on my first home-assembled computer. It uses a 1.5GHz VIA processor (slow), 1 GB of memory, a DVD drive, and a pair of hard discs. It performs surprisingly well considering that all those components would probably be considered outmoded in this modern era.

Upgrade Time


I had been running OpenSUSE 11.0 on another computer. It is a very comfortable development environment. I learned how to install and run hudson (open source continuous integration server) and ran various experiments with components.

OpenSUSE 11.1 just released, and if I was going to have to "pay the price" to upgrade, I wanted to upgrade to the current version.

LiveCD Upgrade


I downloaded, burned, and booted from a LiveCD of OpenSUSE 11.1. It recognized all the hardware I expected, and placed an icon on the desktop to run the LiveCD installer. That was straightforward...

Several screens into that installer, I realized that it was determined to format both the root partition (/) and the home partition (/home) no matter what settings I tried. Thankfully, with the second disc in the system, I was able to copy the entire contents of the first disc to the second disc, then let the LiveCD installer do its damage.

Once installed, I added a number of packages (large chunks of development tools, including C, Python, and Java). That went well.

I had seen mention in the Hudson blog that there was an rpm available for hudson. I went searching and found that a Hudson rpm is now hosted on the "building" portion of the OpenSUSE Build Service. They weren't yet building for 11.1, so I connected to the 11.0 build service. The installation went great.

The rpm from the OpenSUSE Build Service placed Hudson into the standard locations. That meant I could use the OpenSUSE administrator interface (YaST) to configure the Hudson service to start every time the computer boots. Simple, direct, and easy administration (and its free too).

Managing Hudson Plugins


I learned yet another new thing about Hudson. Configuring plugins for Hudson is trivial... I previously had done the work of downloading the plugins I needed, then copied them to the plugins directory and restarted the Hudson server. While that seems simple enough, I found a reference that makes it even simpler.

The Hudson server has a "Manage Hudson" link which will includes "Manage Plugins" as one of its choices. That link took me to a page with many plugins. I chose the plugins I wanted, and saved the page. Hudson downloaded and installed the plugins.

I had to restart the Hudson server to activate all the new plugins, but once I had done that, they were ready to use.

All in all, I continue to be amazed at the number of interesting and cool things I can do with open source software. Thanks!
Tags: hudson, continuousintegration, opensuse, plugins
Tuesday December 23, 2008 - 10:40am (MST) Permanent Link
Distributed Version Control and Continuous Integration for One
I've let a personal "git education" project languish for a month or more. Recently I became energized for the project again and wanted to perform some more experiments.

Hudson - Continuous Integration

One of the things that energized me was the realization that a personal project has much in common with work projects. I want to know all the time that it is in good condition, and I want to know as soon as possible if it is not in good condition. For me, that meant I wanted a continuous integration setup, one that would compile and test the code every time I made a change.

At work we organically grew our own continuous integration setup over the course of five years. It met our needs, and didn't have too many features we didn't need.

During those same five years, the open source community has been creating interesting software in the same space. CruiseControl (from ThoughtWorks) and Hudson (from Sun) are two open souce continuous integration projects that I had seen. CruiseControl is used on a new project at work. I wanted to try something different, so I started an experiment with Hudson.

Hudson was simple to install on my Linux computer, simple to configure from a web browser interface, and seemed to work well in my environment. I watched the first compilation run pass, and thought things had worked brilliantly.

Null Pointer Exception in Git SCM Plugin

Unfortunately, the second time I tried to start a continuous integration run from Hudson, there had been no intervening changes to the git repository. That exercised a bug in the Git plugin and I was left with an ugly message about a null pointer exception on line 43 of the Git plugin.

Another Excuse to Learn

I wanted to learn more about Hudson, and I thought it would be cool to contribute a bug fix back to the community for that null pointer exception. It couldn't be that hard...

I read the instructions for building Hudson, installed Apache Maven 2 (as required by Hudson), downloaded the Hudson source code, and compiled it. Unfortunately, the Hudson compilation did not compile the Git plugin. As I read the plugin source code, the line which had the null pointer exception was a blank line. That meant the source had advanced beyond the code which was compiled in the git plugin I was using. Maybe the bug was already fixed...

A little searching on the web suggested that I might be able to build the plugin by changing to the plugins/git directory in the souce tree and running Maven ("mvn"). That worked. I copied the new Git plugin into my ~/.hudson/plugins directory, and restarted Hudson.

The new Git plugin worked great, with no null pointer exception.

More Progress, More Fun

I've now watched the Hudson system run 8 builds since I installed it less than 2 days ago. It runs the builds after it detects a checkin, without requiring any thought from me. The results are easily seen in a web page, the configuration is done through web pages, and the whole process felt seamless and elegant.

All that, and the software is free...

Next Steps

I have a whole bunch of other ideas to improve my little development environment. I'll add test execution in the Hudson environment, and move the Hudson environment to another machine, and make Hudson run all the time, and have all sorts of fun watching it.

I've already configured a second Hudson job on my little machine. The second job monitors my copy of the git source code. If there is a change to that source (usually because I did a "git pull" from the master sources), then the new code is built and the results of the build are available as summaries and as details.
Sunday December 14, 2008 - 06:45pm (MST) Permanent Link

Add Mark Waite's Blog to your personalized My Yahoo! page:

Add to My Yahoo!RSS About My Yahoo! & RSS
1 - 5 of 227 First | < Prev | Next > | Last