An Early iPad Review

I’ve been using the iPad heavily for 2 days now. There is an awful lot of potential in this device, ands there is no doubt that the best is yet to come.

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.

Lightning Quick Summary of the Houston Auto Show

New BMW 5-series Gran Turismo = stunner, inside & out. Was happy to see roof-rack slots are back for the 5-series (presumably the new sedan out later this year will have them as well).

BMW 7-series = nicer than the previous generation, also quite surprised to see roof-rack slots in for this model.

All Audis = beautiful design on the exterior, meh on the inside. You can do better, Audi… make me feel like I’m giving up something if I go buy a BMW.

Cadillac CTS, CTS-V and CTS SportWagon = much nicer than I expected. Exterior is sharp, interior is nicely done and about on par with the BMW 3-series as it should be. CTS-V is slightly nicer on the inside.

New Camaro = too bad they kept the name, because eventually this car will be in every trailer park making the new ones look horrible. Extremely well done car, inside & out. Back-seat only for midgets and a large trunk with one of the smallest hatches I’ve ever seen on a car. Totally not practical, but totally awesome. Even the V6 version looks good.

New Grand Sport version of the Corvette = much, much sharper looking in person than I expected. Tempting, tempting…

New Mercedes-Benz E-Class sedan & coupe = absolutely gorgeous on the outside and a total letdown on the inside. Not even as nice as a BMW 3-series, let alone a 5-series. These were the E-350 versions, so hopefully the V8 and AMG versions will remedy some of that. Having a total display floor size of an average size guest bedroom doesn’t help showing off the cars.

All Acuras = couldn’t be more boring if they tried. Interiors remind me of cheap GM cars from the early 90s. Exteriors only a boy racer wanna-be could love. The new ZDX was interesting but had rear-doors that would make you yearn for the spaciousness of a Camaro.

A Year of Motion

The end of the year is always a good time for reflection. One of the things I always do is look at how much time and distance I’ve spent in a car or on a bicycle.

2009 was a record year for riding in a cars at just over 21,000 miles, just over my previous record driving year of 2008 which was around 19,000 miles.

On the bicycles, I only managed 2,000 miles, significantly less than my 2008 peak of 2,700 miles.

My Zenoss Development Environment – Part 3

In Part 1 of this series we discussed getting an initial Zenoss environment checked out and running on a Mac OS X or Ubuntu system. In Part 2 we discussed how to configure Eclipse to use the Zenoss source. In this part, we’ll discuss how to handle day-to-day operations such as branch management and working with multiple versions.

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.
    svn switch

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.

My Zenoss Development Environment – Part 2

In Part 1 of this series we discussed getting an initial Zenoss environment checked out and running on a Mac OS X or Ubuntu system. In this part, we’ll discuss configuring Eclipse to use this environment.

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.eclipse-workspace
  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.PyDev
    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.

    PyDev

  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.Subclipse
  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.svn checkout
  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.
      4. Picture 13After 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.Picture 2
      2. In the External Libraries tab choose the Add source folder button and choose the $ZENHOME/lib/python directory.Picture 3

    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.