Posts

Showing posts from May, 2006

Sandboxes everywhere

Jon Udell's most recent InfoWorld column talks about "Easing app deployment with an open source sandbox". The article talks about a hosting service which offers an automated sandbox installer and thus considerably eases the deployment and testing of packages. This resonates with one of the main goals of the Cheesecake Summer of Code project: to offer a sandbox environment where Python packages can be uploaded and inspected dynamically, by running their unit tests, getting code coverage numbers, etc.

To me, 2006 seems to be the year of the virtual machine. Here's the equation:

commodity hardware+solid open-source virtualization technologies such as Xen= great opportunities for testers

Many companies have already started to capitalize on this equation (Autoriginate/HostedQA is just one example). The beauty of Open Source however makes this opportunity available to anybody who possesses a medium-to-high amount of Linux hacking skillz :-).

I'll post more about this topic…

Michael Feathers on refactoring and continuous integration

From the author of "Working effectively with legacy code", Michael Feathers, a blog post on "Refactoring needs more than tests". Interesting point of view: sometimes unit tests are not enough when it comes to refactoring.

M.F. disusses the situation of a project with a large code base, where several teams work on different releases/branches of the code at the same time. How do you refactor with confidence in this case? Another scenario discussed in the post is a project with dependencies on 3rd party code. How do you refactor with confidence, when you know that the 3rd party code keeps changing and needs to be patched everytime it gets updated?

Michael's answer is: integrate frequently. I say: buildbottotherescue! :-)

Cheesecake and the Summer of Code

Image
I'm very pleased to announce that Michał Kwiatkowski's project "Cheesecake enhancements and its integration with PyPI" was accepted as a Google Summer of Code project under the Python Software Foundation umbrella. Here's a summary of Michał's application:
Cheesecake is an application designed to evaluate and estimate the overall quality (or so called 'kwalitee') of a given software package written in Python. It emphasizes a need for well-written documentation and unit tests, encouraging good programming practices and penalizing sloppy design and careless distribution. Using Cheesecake to check your code gives you confidence that your software doesn't merely run, but is usable and easy to test and modify as well. Because Python is very easy to learn and use there exists a vast variety of software written in it, most of which was scattered until PyPI was created. Now, when new packages are being indexed on Cheese Shop every day, an effort can be made…

Dynamically updating buildbot status text

Let's assume you want to update the build step status text displayed in the buildbot HTML status page, based on some information that only the build slave knows -- such as a version number that is computed by the slave during the build step for example.

Note that if you just want to customize the build step status with some text that is known in advance by the master (e.g. "client install" or "twill functional tests"), all you need to do is to subclass from ShellCommand and set the descriptionDone class variable to the desired custom text. See this post for more details on how to do this.

For dynamically updating the status text, the solution I found was to override some of the methods in the ShellCommand class.

My particular scenario is this: the build slave installs some package and identifies its version number. I want to be able to display that version number in the status for that build step.

I defined the following subclass of ShellCommand:

class ClientInstall…

SSH tunnelling with Putty

Courtesy of David Hancock, here's a mini-howto on configuring Putty for SSH tunnelling. Let's say you have an account on a Linux box (with an IP address of 192.168.2.100) that you can SSH into. Let's say you want to connect to a Trac instance running on port 8000 on a different box (with IP 192.168.2.200), and you can't get directly to port 8000 on the second IP. You can still use your account on the first box and create an ssh tunnel that will allow you to get to port 8000 on IP #2.

Here's David's howto, almost verbatim:

What we'll do is forward port 9080 on the PC to 8000 on 192.168.2.200 (the host/port for Trac). I'm using Putty version 0.54.

1. Start Putty (so you're looking at the PuTTY Configuration screen.)
2. Enter 192.168.2.100 (the IP of the box you can ssh into) in the Host name / IP address box.
3. Check SSH as the protocol (port number should change to 22.)
4. Enter 'trac-tunnel' as the Saved Sessions name, and click Save.
5. Open the …

Zen of Unicode

I attended David Goodger's Unicode talk at PyCon earlier this year and I thought I'm well on my way to Unicode enlightenment. It turns out I still need to chop a lot of wood, carry a lot of water before I attain this particular Zen...In the hope that other people will find it useful, here's a mini-tutorial on Unicode in the form of an email message from David, who responded in excruciating detail to some Unicode-related questions I sent him. I tried to copy and paste the text into the Blogger editor, only to get all sorts of markup-related errors, so I just put it on a Trac wiki. Hopefully David will soon publish his Unicode tutorial on the Web. Until then, happy Unicode hacking!