One way Netflix has tested their ability to survive failure is to constantly force failure within their system. They built a system component named ChaosMonkey that randomly kills part of their architecture to ensure that the rest of it can survive and continuing offering service to customers. I love this approach. Not only does it show a lot of maturity within the Netflix engineering team about what systems failure really means, but also shows that they understand the importance of constantly ensuring that failures are expected and recoverable; I still see too many enterprises today that have yet to learn that important lesson.

ChaosMonkey reminds me greatly of what I used to do, albeit manually, when I was in charge of systems architecture at a company in the early a part of my career. We had a wonderfully horizontally scalable system architecture, back in an era when most enterprises would only use mainframes for systems of such size and importance. It was a critical part of our ability to provide high levels of service and performance at a relatively low cost. We did a good job of giving our operations team plenty of opportunity to test system failure and ensure that we could survive catastrophic failure, but I found it was never quite enough as the system grew more complex.

About the time we began implementing RAID drive subsystems for our database nodes, I began a systematic approach to destroy parts of our architecture on a regular basis. At first, it was a way to make sure the RAID subsystem would act appropriately in a degraded state – and they did, but we had plenty of software modifications to make to allow our systems to perform better in such a state. My experiments quickly became a little more aggressive… a few times a week, I would randomly pull drives out of their carriers, or kill processes on production nodes, or even cause an entire system crash.

Remarkably, it was rare when any of this activity would even be noticed. Our architecture was so good at surviving single points of failure that the operations team would often not even notice that anything at all had happened. When they did, it was usually a sign of a weak-point in our architecture that needed to be fixed. Occasionally, hardware actually failed from my little experiments, and I always felt bad about that, but the reality is that same hardware would have failed at a much more inconvenient time.

Alas, once our company was purchased by a publicly-traded company, development was no longer allowed access to the data center. For the most part, this was a very positive thing, but it also prevented people like myself from twiddling with the system to make sure it would work well. Our operations staff was good however, and many of the lessons development learned over the years were picked up by them. Today’s trend of dev-ops is a welcome return to some of that way of thinking, as it really does show that you need developer mindsets when running your operations.

I can distill my experiences doing dev-ops work in the past into some key points:

1. Build your systems with the assumption that failure happens, and happens regularly.
2. You must test your ability to fail and recover, and do it constantly.
3. Hardware & software solutions for vertical scaling are inherently inflexible and likely much more expensive in the long run. This was true in the 1980s, and even more true today now that more shops understand the nature of horizontal scalability.
4. Beware of the mindset that wants high uptime for individual systems. It’s cool for your server at home, but in an operations scenario that system represents one that might not startup properly if it does fail. Inability for a system to startup properly was, and remains, a hugely common problem. Reboot all of your systems regularly.

I’ve been a voracious consumer of information since I was a kid. As part of the first home computing generation, I grew up with the assumption that I had access to information on-line without much effort. In the first few years it was just the traditional dial-up bulletin board model, but quickly that gave way to the predecessor of the Internet available through the local universities and proto-ISPs. The amount of information and news we had available then was simply amazing, and it has only continued to grow since then.

It wasn’t difficult to imagine that we’d have access to this much information back then – science fiction authors and nerds have been thinking along those lines for much longer than I’ve been around, but to actually witness coming to fruition was wonderful – and so easy to take for granted.

The bottom-line is that many of us, and especially me, are addicted to information. News is no longer fed to us in an hour long program on television very night; there are plenty of young adults now who never lived when there were no 24/7 news channels. We all have the expectation that news and information is freely available anytime, and all the time, wherever we are.

As technology continued to advance, so did our ease of accessing this wealth of information. We could get all of our news via the web, and could skip the cable networks if we wanted. Eventually, we could watch the cable networks live over the Internet at the office, or wherever we might be. A plethora of applications let us aggregate and present all of this information in one place for our consumption, in real-time. The upshot being that there is ample opportunity to be distracted by information at any time – there’s no waiting any more.

We certainly don’t need 24/7 news and the Internet to procrastinate, but they both sure make it easy for anyone who works with a computer. As mobile computing devices become more common place, I believe we’ll start to see procrastination in the hands of everyone. Just wait until the clerk at Taco Bell is too busy checking Facebook instead of taking your order! Oh wait, you mean that’s already happened?

When I decided to take a month off from information I did so deliberately with the intent to break the procrastination habit. I was taking several months off of work, and without the deadlines imposed by business needs, I knew I would have a tendency to slow down a bit and find ways to kill time. That was great, for a few weeks, but quickly I wanted to get back down to work and focus on some big personal projects. Stopping the information habit was one tool I had planned to use to make sure I’d focus on what I needed to, not just what was at hand.

Breaking the habit turned out to be surprisingly easy. There were a few days of the expected psychological addiction withdrawal symptoms to contend with, but they were blessedly minor. The bigger hurdle to overcome was the feeling that I was missing out on STUFF! THINGS were happening and I wasn’t keeping up! Naturally, none of it really mattered in the end.

In fact, looking back on what actually occurred in the news during January and early February, it is remarkable how little actually occurred that was worth paying attention to. The big stories during this time period? The shootings in Arizona, the crisis in Egypt, and if you enjoy sensationalized stories, the massive bird kill in Arkansas or wherever.

All of these stories were impossible not to hear about, even without the news. All I had to do was visit the local coffee shop or interact with another human and these invariably would come up in conversation, direct or overheard.

The shooting story seemed to cause the most emotional reaction from the people I saw discussing it, as is the tendency for that sort of tragedy.

The crisis in Egypt had the appeal of seeing something positive possibly occur, in a region of the world where it is so desperately needed, and it’s incredibly appealing to human nature to feel like you are a part of history as it happens.

The bird kill story, well, that’s just a classic example of sensationalism that’s exacerbated by the existence of the 24/7 news & information society. Would it have really had such a strong headline impact if there had been a day or two to gather more information before the panic-like headlines appeared? Perhaps…

The reality is that not one of these stories had any impact on my life – or on most of humanity’s life for that matter. The simple existence of quick and efficient information delivery creates an artificial feeling that this stuff is really important, and that it is important RIGHT NOW! But in reality, you could read a synopsis of world and local events once a month, or even once a year, and probably be better informed about the world than you are right now. You’d simply have less noise to sift through before getting to what really matters.

I didn’t miss world and local news one bit during my hiatus – in fact, I haven’t picked up the habit of checking it again. I’m finding it much more effective to discuss events with other people rather than constantly reading or watching about the latest events. If I need to dive into a story, I can do that after I determine if it’s worth spending time on.

I do have a bit of consternation on the news and happenings that are technology related, as it affects my career more directly than traditional world events. But here, too, I think I’m finding that a low-information diet is actually more efficient than trying to constantly keep up with the never-ending surge of what’s available. That sounds like a key to success to me – pay more attention to what really matters, and ignore what doesn’t. Life is ultimately an equation of time, and the more of that we can make use of, the more effective, productive, and happier our lives will be.

Now, if you excuse me, I have to go post a picture of the beer I’m drinking on Facebook.

Garmin Edge 500, Garmin ForeRunner 310XT and CycleOps PowerTap CPU

Starting in February, 2010, I added a power meter to my cycling gadget list, and the ForeRunner proved a great partner to cycling with power, especially when compared to the PowerTap CPU unit that came with the power meter. I found the ForeRunner easy to use, accurate, and the integration with both Garmin Connect and the software solutions from TrainingPeaks more useful and easier to use than the other options.

In June, 2010, I rode the wonderful Ride the Rockies event in Colorado and used the ForeRunner 310XT to track the entire week of riding. One problem I discovered in an event like this is that the ForeRunner did not have enough onboard memory to store the entire week’s worth of riding. I discovered this before the trip and so I lugged a small netbook around with my camping gear just so I could download data after the rides. Not quite the best way to unplug on a holiday.

When Garmin announced the Garmin Edge 500 Cycling GPS
it looked like a great solution for use on my bike. Since it was cycling specific, it had a few more features designed for cycling, whereas the ForeRunner 310XT was definitely intended to be used for multi-sport activities. Since I’m always in need of a new gadget to play with, I went ahead and bought one and started using it for cycling in August, 2010.

I’ve found it to be as good as promised, but there still are times when the ForeRunner 310XT is a better choice. In the rest of this post, I’ll show you the various differences between the two devices and how one might be better than the other depending upon your circumstances.

Memory Capacity

As the memory limitation of the ForeRunner 310XT was the first thing that made me interested in the Edge 500, it’s good to start here. In my use, I’ve found the ForeRunner only has enough onboard memory to store between 24 and 36 hours of workouts – certainly not enough for a week long cycling tour. Garmin doesn’t provide specifications on how much actually memory is installed on this device, so it is a bit of a mystery to the actual capacity.

Meanwhile, the Edge 500 has 56.4 MB of flash based storage, at least according to my Mac’s view of it. I’ve got every cycling workout since I started using the Edge still stored on it – about 50 hours worth so far – and the device still has 48.7 MB of storage free! This is an amazing amount of usable storage and means even the most active cyclists will find they have room for months of data without issue. No need to take a laptop with you on holiday!

Advantage: Edge 500, handily.

Data Transfer

The data transfer mechanism is very different in the two devices. The ForeRunner 310XT uses a wireless ANT+ based data transfer mechanism, while the Edge 500 appears as a simple USB flash drive to your computer.

To exchange data between your computer and your ForeRunner 310XT you have to use a ANT+ dongle provided by Garmin that connects to your computer’s USB port along with a software application that provides drivers for the dongle. It works, and depending upon your computer configuration it is easily a setup-once-and-forget operation. You don’t need to plug in any more wires, and you just bring your ForeRunner 310XT within a few feet of the dongle and you are good to go.

In practice, though, this approach was not perfect. I found during my cycling holiday that a cheap netbook did not have enough CPU performance to reliably handle the data transfer job if it was not plugged into A/C power. That was a surprise and made downloading data from the ForeRunner a hassle during my trip, since I did not frequently have access to A/C power while camping out.

By comparison, the Edge 500 requires you to use a USB cable to physically plug the Edge 500 unit directly to a USB port on your computer. The Edge then shows up as USB flash disk, so once you are done you have to eject the device to prevent your computer from complaining.

Because the Edge 500 uses a direct USB connection, it is much more reliable and faster to do any data transfer than the ForeRunner 310XT. The USB cable is not really any more or less hassle than the ANT+ dongle, so you aren’t gaining a lot of advantage by having a wireless based data transfer mechanism.

Advantage: Edge 500, but just so.

Charging

Directly related to the data transfer mechanism is how the devices are charged. Both devices can be charged via a USB connection to a computer, or using a USB to A/C adaptor, which Garmin provides.

The primary difference here is that the ForeRunner 310XT requires a large binder-like clip that grabs onto the unit and touches two electrical connectors on the rear of the unit. Meanwhile, the Edge 500 simply uses the same USB connection for data transfer. This means a lot less bulk when traveling.

Garmin provides an excellent A/C adaptor system that includes several international wall-plug adaptors as part of their standard kit for both devices, so you’re set for all kinds of power scenarios.

Advantage: Edge 500.

Battery Life

How about battery life? Garmin says the ForeRunner 310XT’s battery life is up to 20 hours, and the Edge 500’s is up to 18 hours. In my experience these estimates are spot on. Both units battery life means you can get a few days worth of use before you need to recharge, but if you are traveling you should plan on bringing a charging solution with you.

The Edge 500 clearly consumes more power than the ForeRunner 310XT, and given that, Garmin provided more software features to help. The Edge 500 is very quick to auto power-off if it is not receiving any data, and this helps avoid unnecessary battery consumption if you’ve stopped to take a long break or after finishing a ride.

Advantage: ForeRunner 310XT, but just so.

Display

The display on each device is similar, but there are numerous small differences.

The ForeRunner’s display is covered in glass – which I dropped and broke once, resulting in an expensive repair bill – while the Edge’s display feels like a type of plastic, but I’m not 100% positive on that.

Display Comparison of Edge 500 and ForeRunner 310XT

Both units provide a high-contrast, easy to read display, with an optional backlight. Both units are exceptionally easy to see in outdoor light, although they are both prone to glare if the sun hits them at just the right angle – just like every other cycling computer I’ve ever used.

Each unit provides multiple pages of data, and multiple data items per page. The ForeRunner limits you to 4 data fields maximum per page, with 4 total pages, plus a workout specific page. Since the ForeRunner 310XT is a multi-sport device, each sport setting has its own independent set of customizable pages and data fields.

The Edge 500’s display is slightly taller than the ForeRunner’s, and as such you can have up to 8 data fields per page. This also means that for those pages with few fields, you can make certain key data items very large and easy to read. The Edge 500 limits you to 3 pages of data, with one additional page for workouts.

Advantage: neither. Both devices are champs with slight benefits to their intended audience.

Workouts

Another software feature that is different between the two units is the Workouts feature. Both units have the ability to program complex workouts with a variety of steps, targets, repeats, etc. Both let you create courses to follow, and set alerts for time, distance, calories, or heart rate; the Edge 500 also adds support for cadence and power alerts.

The ForeRunner 310XT, however, has a great shortcut for creating interval workouts. With a quick, easy-to-use 2-page setting wizard, you can select intervals that are time or distance based, along with recoveries, and then choose the number of repetitions and if you want warm-up and cool-down intervals added. For a lot of workouts, this is all you need.

Programming the more advanced workouts in either device is not very difficult, but it’s enough steps that many people will just avoid doing it altogether. Programming these workouts is easier if you use Garmin Training Center and then download the workout to the device, but this software isn’t the best quality itself and I find myself just programming the workouts directly on the devices.

Advantage: ForeRunner 310XT.

Mounting Options

The ForeRunner 310XT is a sports watch, but there are a few different bike mounting options available as well. I’ve found when doing multi-sport activities it’s better to just leave it on your wrist, but when primarily biking, having it mounted on the bike was a better option.

ForeRunner 310XT Quick Release Kit

The bike mount option I used for the ForRunner 310XT is the Garmin Quick Release Kit. This kit replaces the watch strap of the ForeRunner with one that includes a mounting bracket that then snaps into place on an adaptor that mounts directly to your bike with twist-ties. The replacement watch strap wasn’t as comfortable as the original strap that came with the ForeRunner, and it increased the width of the device slightly, but overall this is a very good mounting solution.

Garmin also sells a Forerunner Bicycle Mount Kitfor ForeRunner devices that lets strap the device to the mount directly. I haven’t used this option, but it’s a convenient way of solving the mounting problem as well.

Edge 500 with Quarter Turn Mounting Kit

The mounting solution for the Edge 500 is similar to the Quick Release Kit option for the ForeRunner, but attaches to the bike in a very different way. The mounting bracket itself uses high-quality bands (ethylene propylene diene monomer, a synthetic rubber!) of various sizes to secure the mounting bracket to the bike. The Edge 500 comes with a handful of different size bands and two mounting brackets, so you can easily attach it to multiple bikes. Moving a bracket to a different bike takes just seconds, but you can always buy another quarter turn bike mount kitif two mounts are not enough.

Edge 500 Bike Mount

The design of this mounting system is simple and elegant. The bands are extremely strong and pliable enough that stretching them to secure the mounting bracket is trivial. The back of the mounting bracket rests on either your bicycle stem or handlebars using a rubber piece that keeps it from moving. Once it’s attached with the bands, the mount just isn’t going to go anywhere.  The Edge 500 slides into the bracket quickly and once its turned, it also isn’t going to fly off, even on the bumpiest of routes.

Edge 500 Bike Mount using the ForeRunner 310XT's Mount

One nice surprise is that the quarter-turn mounting bracket design is the same between the ForeRunner 310XT’s Quick Release Kit and the Edge 500′s mounting brackets. On my road bike, I’m actually using the bracket that came with the ForeRunner’s kit instead of the Edge 500′s rubber band brackets – but only because it was already attached. There is a small screw in this mounting bracket that lets you change the orientation of the attached device, and this is one difference between the two different devices. It only takes a couple of seconds to change this, and chances are good you won’t be going back and forth between the two devices if you happen to have both (I only use the ForeRunner 310XT with its original wrist strap after buying the Edge 500).

ForeRunner 310XT Bicycle Mount

The quarter-turn quick release mounting design is a great solution for putting either of these devices on your bike. It allows them to be installed and removed in about a second without having to fuss with any tools. I especially like to take off the devices whenever at a rest stop – a $200+ bike gadget that’s so easily pocketed is going to be tempting for the unscrupulous out there.

Advantage: neither, both have excellent, and compatible, options.

Training with Power

Both devices have great support for receiving data from any ANT+ enabled power meter. Over time, the firmware has been updated on both and support for showing more power data has been added. As of version 3.00 on the ForeRunner 310XT, and 2.40 on the Edge 500, the following power-related data fields are available:

• Power (current power measurement)
• Power – % FTP
• Power – 30s Avg
• Power – 3s Avg (my personal favorite)
• Power – Avg
• Power – kilojoules
• Power – Lap
• Power – Max
• Power Zone (current power measurement)

I tend to ride with my display set to show the 3-second average power, the cadence and the current lap time. This keeps me focused on what matters most during training, but hides all the other data that might be distracting, but it ultimately depends upon what kind of ride I am doing at the time.

If you are interested in training with power, but don’t yet know much about it, start by reading Training and Racing with a Power Meter. Training with power is great fun, but the bottom line is that you either need to be analytical (okay, a bit of a geek), or have a coach that uses your power data to keep track of your progress. Otherwise, you aren’t likely to realize the benefits of the tool.

Advantage: both devices are equally capable.

Bottom Line

Both devices are excellent at what they do, and either is a powerful training companion. If you are just a bicyclist, and do no multi-sport activities, then the Edge 500 is the right choice for you. If you are into multi-sport, the ForeRunner 310XT is all that you will need, but the Edge 500 does have a few advantages, such as the large memory capacity.

The Edge 500 is also a little bit cheaper than the ForeRunner 310XT, especially if you already own a compatible heart-rate monitor or power meter.

Garmin Connect screen shot

A lot of folks are buying Garmin sports devices these days so that they can upload and share their data using Garmin’s excellent Connect website. If you haven’t tried Garmin Connect, go there and give it a shot. It’s worth the price of admission and continues to get better as Garmin adds features, albeit rather slowly.

Many times, however, Flash isn’t an appropriate technology to use. If you’re an open-source product like Zenoss, Flash presents a licensing issue. If you’re targeting mobile platforms like the iPhone, Flash isn’t available. And, sometimes, you may just not like Flash; it does have it’s own security problems and overhead, for example. What’s a web developer to do? Enter HTML5 to the rescue…

HTML5 is not yet an approved standard, but it’s well on its way and surprisingly well-supported by the browser community already. One of the nice new features provided in HTML5 is the canvas element which allows for two-dimensional drawing functionality. Between this new feature and JavaScript, we should be able to create a rich graph display.

If you are already an iPhone user, the iPad will simultaneously feel familiar but also so incredibly rich and powerful compared to it’s little brother. The extra screen real estate is in itself nice, but more importantly is how the iPhone OS’s approach to user interaction makes use of this extra room.

For example, the Mail app shows each message in full screen glory, but with a fast overlay window to show message and folder navigation. The usability effect is wonderful. Using Safari is now like browsing on a regular computer, except with a multi-touch interface.

I don’t play very many games on the iPhone or iPad, but the Words With Friends game (think Scrabble) is almost worth getting an iPad for just to play it. I suspect the casual gaming crowd I’ll a have a lot to look forward to with their new toy.

Battery life on the iPad has been better than I expected. A little over 48 hour into ownership and I’m down to 10% battery life. I’ve used it a lot, including a lot of reading, so it seems to hold up well there. While it does not compare to the extra long battery life of a Kindle, the device does so much more it seems like a good trade-off.

As far as being an e-reader, I like the iPad better than the Kindle DX (that I normally read from), but not as much as the regular Kindle 2. That device is sized so well, and the battery life is so good, it’s easy to see it remaining the king of its segment for a while. That said, I am a guy, so i like big screens, and here the iPad wins over the DX. The iPad is a touch heavier, but it still feels natural to hold. A minor, but very nice feature in the iPad is the physical orientation lock button, something which the DX has as a software feature that is hard to use.

I plan on using my iPad as a replacement for my laptop for casual computing. It seems like it is going to do that job well. They keyboard is easy enough to use even for this blog entry, and the heavy writers out there may find the keyboard dock option even better than lugging around a laptop.

Branch-Based Development

At Zenoss we do all development, including bug fixes and small maintenance tasks, in a private development branch within the subversion repository. This allows us to independently work-on changes, check-them into the repository for safe-keeping, and then perform code reviews with team members without having to share files or using pastebin style tools (even though we do both at times).

1. Create a branch within your user’s sandbox. In this example, I’ve decided to name the sandbox new-widget to identify what I’m working on. If I were fixing a defect, I’d use the defect number from the defect tracking system. Create the branch by copying the trunk folder to the sandbox branch. In Subversion this is a low-overhead operation and doesn’t actually copy files.
svn copy http://dev.zenoss.org/svn/trunk http://dev.zenoss.org/svn/sandboxen/cgibbons/new-widget -m " * Copying trunk to sandbox branch."

2. Switch your working directory to use the new sandbox branch. You can do this either from the command-line or using Eclipse. From the command line, you’d do the following:
cd $HOME/zenoss/core
svn switch http://dev.zenoss.org/svn/sandboxen/cgibbons/new-widget
From within Eclipse, secondary-click on the core project and choose Switch to Another Branch/Tag/Revision… option from the Team menu. On the dialog that appears, enter in the sandbox URL. After switching, your Eclipse will show the new location next to the core project item.
   

Once your development environment has been switched, you can make changes and commit to the Subversion repository as desired. If you’re unsure if you are in the right branch, you can always use the svn info command to see which directory is being used.

Merging Branches

Once you have completed changes in a branch and have had them reviewed by a peer, it is time to merge them into trunk (or another branch, if using a maintenance release). Merging can be tricky, but a consistent process can make it much easier to handle.

1. Change your working directory to a checked-out and clean version of the branch you want to merge into. For example, I keep a $HOME/zenoss/clean-trunk directory that I never make changes to, except for merging.
2. Determine the base working revision of your working branch. There are a variety of ways to do this, but one of the best is to view the revision log graph within the Trac system directly. For example, for the branch discussed above we can browse to http://dev.zenoss.org/trac/log/sandboxen/cgibbons/new-widget/ and see that revision 15513 is the base.
3. Perform a dry-run on the merge to get a general idea of what the changes into the branch will be. You should see your expected changes, plus any conflicts from changes to the other branch while you have been working in the sandbox branch.
svn merge --dry-run --revision 15513:HEAD http://dev.zenoss.org/svn/sandboxen/cgibbons/new-widget .

4. If the merge results look satisfactory, rerun the command without the dry-run argument.
5. Look at the final merge results using svn status and svn diff, and once you’re ready, issue an svn commit.

Multiple Branches and Zenoss Configuration

As you switch between branches you will often render your Zenoss configuration useless.  Resetting your database after each branch switch is usually a good practice, and being able to quickly recreate any test data you may need makes this process less painful.

After switching a branch, my process is usually the following:

1. Shutdown zenoss and restart only zeo.
zenoss stop
zeoctl start
2. Run the zenwipe script from the inst source directory.
$HOME/zenoss/inst/zenwipe.sh --no-prompt
3. Run zenmigrate to install any database changes available within the current branch.

Depending upon the task at hand, I may install additional ZenPacks and add new devices through the command-line if those are needed. Helper scripts, such as install-windows.sh to install of the Windows ZenPacks and create several local test devices in the instance, are useful tools to have for your typical configurations.

Mac OS X Prerequisites

1. Install Eclipse Classic 3.5.x Mac Cocoa 32-bit.

Ubuntu Prerequisites

1. Install the Sun Java JDK. Why? Eclipse is a Java application and requires a full-fledged Java environment to run properly.
sudo apt-get -y install sun-java6-jdk

2. Install Eclipse Classic 3.5.x Linux 32-bit.

Eclipse Configuration

1. In part one, we created a Zenoss root project directory of $HOME/zenoss – use that directory, or the one you created, for the rest of these steps.
2. Launch Eclipse and configure it to use the Zenoss root project directory. Why? Eclipse needs a workspace directory to keep track of configuration settings for a group of related projects. By placing the workspace directory inside of the Zenoss root workspace, we can separate the requirements for a Zenoss workspace from other projects you may be using.
3. Install the PyDev plug-in for Eclipse. Why? PyDev provides Python language support to Eclipse.
   1. Go to the Help Menu and choose Install New Software.
   2. In the Available Software dialog, choose Add and enter in http://pydev.org/updates/ as the Location and close the dialog. Eclipse will return to the Available Software dialog.
   3. Software matching PyDev will appear in the dialog; pick the PyDev option but do not pick PyDev Mylyn Integration. Click Next and install the plug-in.

   

4. Install the Subclipse plug-in. Why? Subclipse allows you to work with the Subversion version control system directly from within Eclipse.
   1. In the Available Software dialog add the Subclipse plug-in update site:

      http://subclipse.tigris.org/update_1.6.x

   2. In the Available Software dialog, choose the Subclipse, Subversion Client Adapter, Subversion JavaHL Native Library Adapter and the Subversion Revision Graph items.
5. Go to the Window menu, choose Open Perspective and then SVN Repository Exploring (you may have to choose Other… to see this option).
6. Choose the New Repository Location button in the SVN Repositories panel. Add the Zenoss SVN site at http://dev.zenoss.org/svn
7. Open the SVN repository and select the trunk folder. Secondary-click the folder and choose the Checkout… option. Be sure to change the Depth option to be Only this item so that we don’t check out any of the sub-folders of trunk just yet (many of the folders within trunk are not needed for development, but we want to keep the directory structure). In the next dialog you will be asked to choose a Project Wizard. Open the Pydev tree item and select the Pydev Project option.
8. Create the project in the Pydev Project dialog:
   1. Use core as the project name and use the default location. This should create a core project at $HOME/zenoss/core.
   2. Make sure the Python project type is selected.
   3. Select 2.4 as the Python Grammar version.
   4. Uncheck the Create default ‘src’ folder... option.
   5. Click the Click here to configure an interpreter not listed… option in order to add the python interpreter built by the Zenoss installation scripts.
      1. In the Preferences Dialog, choose the Interpreter – Python item underneath Pydev and select the New… button to add a new Python interpreter.
      2. Browse to the $ZENHOME/bin directory and choose the python2.4 executable from that directory.
      3. Name the interpreter python-2.4, zenoss-python or some other variant.

      After the new Python interpreter has been added, return to the Pydev Project dialog and choose that interpreter from the list and then click Finish to create the project.

   6. Update the core folder from the command-line SVN client so you can selectively pull the sub-folders of the core project and not all of them:
cd $HOME/zenoss/core
svn update Products

   7. Move the Products directory the installation checked out and create a symbolic link to the one updated above. Why? This allows the Products source tree to be worked on from Eclipse and then also used by the Zenoss run-time.
cd $ZENHOME
mv Products Products.old
ln -s $HOME/zenoss/core/Products Products
   8. Return to Eclipse and choose the Refresh option from the File menu so that Eclipse notices the updated directory and builds necessary dependencies.
   9. Secondary-click on the core project folder in Eclipse and choose Properties. Choose the PyDev – PYTHONPATH item and add source folders so PyDev can reference the project from within itself.
      1. In the Source Folders tab choose the Add source folder button and pick the root core folder from the provided list.
      2. In the External Libraries tab choose the Add source folder button and choose the $ZENHOME/lib/python directory.

   At this point, your Eclipse project should allow you to navigate between dependencies within the Zenoss project. You can also simultaneously switch between using the Team feature within Eclipse to update and manage Subversion or do so using the command-line svn client.

   Next…

   In Part 3 of this series, we’ll discuss how to manage day-to-day activities such as creating sandbox branches for changes and dealing with multiple versions are done from within the same environment.

I develop Zenoss primarily on Mac OS X, with some work done on Ubuntu when necessary. I normally use Eclipse as my development editor, although I’ll often just use vim when doing quick changes or bug fixes. In either case, careful setup of the Zenoss environment is key to being able to productively work with both the new development version and with the shipping versions that require maintenance.

The environment you get by default when you check out the source version of Zenoss from the source repository, or from a source tarball, is not necessarily setup in the best way to develop productively using tools like Eclipse.

The rest of this post will document how both my Mac OS X and Ubuntu environments are initially configured so that a working source Zenoss installation is realized.

Mac OS X Prerequisites

These prerequisite instructions assume Mac OS X 10.5 Leopard; 10.6 Snow Leopard will not be able to compile Zenoss’s third-party dependencies, so an additional work-around is required for that platform until Zenoss moves to Python 2.6.

1. Install Xcode. Why? Installs the GNU C/C++ compiler and other command-line development tools needed to build dependencies used by Zenoss.
2. Install Universal Subversion 1.6.x from CollabNet Community.Why? Leopard only comes with Subversion 1.4.x. This version is not compatible with the Subclipse plug-in for Eclipse that will be used later. In order to be able to use both the command-line and Eclipse Subversion versions simultaneously on the same checked our source, the release of subversion should match. This installation will place the Subversion binaries in /opt/subversion and should automatically add it to your PATH.
3. Install MySQL Community Edition 5.1 32-bit. Why? Zenoss needs MySQL for storage of event data.

Ubuntu Prerequisites

These prerequisite instructions assume Ubuntu 9.04 32-bit Desktop Edition. Installing the server edition or one with different options may require additional prerequisites to be installed.

1. Install Subversion. Why? Working with the Zenoss product in source form requires Subversion to access the source repositories (it is also possible to build directly from a source tarball, but this is not discussed here).
   sudo apt-get -y install subversion

2. Install MySQL. Why? Zenoss needs MySQL for storage of event data.
   sudo apt-get -y install mysql-client mysql-server libmysqlclient15-dev

3. Install additional development environment tools. Why? Zenoss third-party dependencies require several binaries to be built from source.
   sudo apt-get -y install patch make vim gcc g++ autoconf
4. Install SNMP support. Why? Zenoss requires SNMP libraries for monitoring, and having a local SNMP agent is useful for testing.
sudo apt-get -y install libsnmp-base snmp snmpd
5. Install Liberation TrueType fonts. Why? Graphs generated by RRDtool will not contain the correct glyphs without this font package.
sudo apt-get -y install ttf-liberation

Environment Configuration

Configuring Eclipse will require determining where you want to work with your Zenoss installation, and installing Eclipse plug-ins to provide the features required for Python and Subversion support.

1. Create your Zenoss root directory:
mkdir $HOME/zenoss

2. Create and run a setup.sh script that will configure needed environment variables for zenoss. This script can be started from your log in profile if desired.
cd $HOME/zenoss
cat > zenoss-config.sh <<EOF
ZENHOME=$HOME/zenoss/zenhome
PYTHONPATH=$ZENHOME/lib/python
PATH=\$ZENHOME/bin:\$PATH
export ZENHOME PYTHONPATH PATH
EOF
chmod +x zenoss-config.sh
. zenoss-config.sh
mkdir $ZENHOME

3. Checkout the Zenoss source installation tree. Why? This tree is used to bootstrap the installation from the source repository and create a running Zenoss installation. We’ll need this before we modify it to fit the needs of our development environment.
svn co http://dev.zenoss.org/svn/trunk/inst inst

4. Run the installation script to checkout, compile, and configure a zenoss environment. If you need to customize your MySQL configuration at all do not use the --no-prompt argument.
cd inst
./install.sh --no-prompt

5. Modify the zensocket file to be setuid root. Why? Some of the Zenoss daemons use a privileged port and making the file owned by root and accessible by the Zenoss user allows the daemons to be run as a non-priviledged user but still use the privileged port.
sudo chown root:`id -g` $ZENHOME/bin/zensocket
sudo chmod 04750 $ZENHOME/bin/zensocket


At this point, you should have running zeo and zope processes and be able to log on to the local Zenoss instance. Your Zenoss root directory should look similar to the following:

Next…

In Part 2 of this series, we’ll download and configure the Eclipse IDE.

I travel quite a bit between Houston and Austin and there are really only three reasonable ways to go: US-290; I-10 & TX-71; or I-10 & TX-183. Over the years my preference has moved from US-290 to I-10 & TX-71 as traffic along US-290 has increased on the eastern fridges of the Austin area, but the distance and time between the two is very similar and really it depends upon where in Austin you might be headed.

The GPS systems in my cars have three route options when you pick a destination: fastest, shortest and other. In both cars, the route displayed is none of the above three, but instead a long, out-of-the-way route of I-10 to Seguin before heading north on TX-123 to San Marcos, and then heading into Austin on I-35. This option is a whopping 222 miles with an estimated travel time of 3 hours and 39 minutes.

Now, the fastest route is usually not the shortest. Route calculations are supposed to take into account the actual speeds of the road segments involved, and since interstate highways are almost always faster than anything else, there is a natural preference to these roads. In this case, however, the calculation is way off. Taking I-10 to US-71 (via US-59 & TX-8 inside of Houston for those familiar with the area) is only 166 miles and estimated to take 3 hours 29 minutes according to Google. Likewise, taking US-290 is only 168 miles and estimated to take 3 hours 22 minutes.

Of course these time estimates are usually worst case scenario. Driving a few miles per hour over the speed limit I often make my trip in 2 hours and 30 minutes; worst case has been 3 hours and 10 minutes when driving 55 as an experiment (a painful one at that).

What about the shortest route option in the GPS system? That does actually route you onto I-10 & US-71 in this example, but the shortest route calculations are always incredibly stupid, too. They will often take you onto side streets for half a mile or less just to maintain the shortest possible distance. Once, when driving through Memphis, TN, the GM GPS took us on and off the interstate highway three times when driving through town, often for just a couple of blocks, just to maintain the shortest distance. Granted this is a clear example of a GPS system not being there to replace your own intelligence, but if you don’t know the town…

In the early days of consumer-level GPS systems, one of the common problems was having accurate speed data for different road segments. In western states especially, secondary highways often have the same speed limits as interstate highways. In Texas, the past 20 years has seen many of these highways improved so they route around the smaller towns, rather than going through them and stopping at every light. Consequently it is often better to take these roads than the interstates whenever possible. If the GM GPS systems do not have accurate speed data then it can account for some of this behavior, but not all.

On my normal route, once you finally hit TX-71 and the GPS decides you mean it, suddenly the estimated arrival time drops dramatically along with the distance. Is it computing this arrival time based upon your actual speed so far, or based upon the speed data of the road?

Over the years I’ve gone from absolutely wanting a satnav system in the car to wishing mine didn’t. I get much better results using a smart phone with Google Maps to get a general idea of the route to take and then consulting with it now and then if things get tricky. But for the most part, they seem poorly done enough that they just get in the way rather than help. Will the newer generations out now that provide real-time traffic data and have hard-disk based data improve their logic and performance enough that these problems are solved?

One final note for embedded systems developers: you don’t get to break the interactive response time rule of 250ms just because you are writing code for an embedded system.

I’m looking for a maintainer that will take the reins of the project from me and give the project some much needed love as time and platforms march on. If interested, drop a comment on this post and we can discuss the possibility.