Entertainer Media Center

I have four friends now all using the dvorak keyboard layout. I decided I would take the plunge and try it out for six months or so and see how it goes. So far it's slow going. Because I was interested in dvorak conversion stories, I figured I ... [More] would share my story. I'm sure that I won't get this under my belt overnight, and that I'll have to be patient with myself. I haven't written much code (or much of anything for that matter), but many of the common characters I use are better available to me. I can see the potential, if I can learn to make it work. If you're considering the switch, be prepared to type similar to your grandma when she first got a computer. One caveat I would point out is that I couldn't quite get the Gnome tools at System->Preferences->Keyboard to work properly. It may have been a PEBCAK problem, but if it was, there's a usability bug that needs to be looked at. I eventually broke down and fixed it the old skool way by editing xorg.conf Granted, changing keyboard layout isn't something lots of users do, so maybe it could just use a bit more polish. Any pointers are appreciated. Update: Quick tip for ubuntu dvorak converts: apt-get install dvorak7min It's a typing tutor similar to the ones I used on the old Apple IIe's at school. [Less]

My wife and I are buying a house. It's not far from where we live, so I'm constantly riding my bike over there to look at the house and think about living there (we close on the 15th of the July). Every time I'm over there, I want to take notes ... [More] , and even though I have a qwerty keyboard on my phone, it sucks greatly. I also wanted to analyze the wireless networks in the neighborhood to see if the upgrade to 5MHz is required yet. I have a Nokia 770 tablet that's been collecting dust for a bit. I flashed the latest release of OS2007 Hacker Edition onto it, installed kismet, btscanner and aircrack onto it and tested it out. The only problem is that I can't always ride with no hands (one hand to hold it, one to use the stylus). With some Gorilla Glue and a modified reflector holder, I mounted the 770 to my bike. I just got back from a ride, and while a custom interface specific to my needs would be helpful, I was able to analyze the area enough to see that the neighborhood will welcome my open wireless network (that complements my private one). Apparently my neighborhood is mostly Amish... Now if only I could figure out how to hook a generator up so I can charge it while I'm riding... And maybe power my GPS so that I can really warbike. More photos here. [Less]

I started writing this post last night after my wife fell asleep (a common occurrence). It was about Twitter, and why I twittered. The basic idea was that I enjoyed the micro-blogging because it was closer to a a real conversation than reading ... [More] someone's blog and posting comments. It's more of a round table where you select who sits at your table. It was personal, and I enjoy that. I've strengthened already existing acquaintances, and created new ones. For something that initially seemed like such a novelty, it's become a great tool. Then, this afternoon, after a 2 hour outage of Twitter, a few friends/coworkers pointed me at Identi.ca, which is a fully open source micro-blogging site. I usually just ignored the Twitter clones, because no one I knew had switched. However, it seemed that a few people I was quite interested in "following" had moved to Identi.ca and, as mindless as it sounds, I tweeted because of those around me. So I naturally I got an Identi.ca account. As I've been using Identi.ca, I've found a problem with it. It has no public facing API. This is absolutely tragic, as that's the only way I use Twitter. I have a little app called gTwitter that keeps me up to date. It crashes often, and I'm not fond of the Mono backend, but it did the job, and stayed out of my way. While Identi.ca apparently allows updating through a Jabber client, I can't get it to work. It has, however, been sending me updates from those I'm subscribed to, through IM. I hate that though, because it's an interruption I don't need. In defense of Identi.ca, these features ARE planned. It is also an open source app, so any user (including myself) could build these features, and the sky is the limit at that point. You certainly can't say that about Twitter. I just won't jump ship completely until after the features are there. I've got a little side project I've been putting 5-10 hours a week into (and less recently, as we're moving), but one of the high priorities I've been been working on is a public facing API. As far as I'm concerned, your web site is stuck in 1.0 world unless a user can easily write an external CRUD app with your database as its backend. It doesn't have to be fancy, maybe just a simple REST interface. The new internet is about mashups and using data in creative ways. A public API is THE secret sauce to successful web sites today. [Less]

Elliot Murphy and John Arbash Meinel were kind enough to invite me to co-write This Week in Bazaar. This week covers using bazaar in your build process. It was quite fun, and quite informative to chat with Elliot and John. Thanks to both of them Go read it!

At Bazcamp this weekend, I had many interesting conversations with a few Bazcampers about Launchpad and Bazaar. The original reason was that I was brainstorming stories for next month's NCLUG talk about Launchpad and Bazaar. As I talked about ... [More] workflows and processes, I started wondering how many other Launchpad and/or Bazaar success stories there were from the community, and how many utter fails have you had (and how can they be fixed). So, lazyweb, send me your success stories, your gripes, your flames and other adventures with Launchpad and Bazaar. If the stories are too long to leave in comments, send me your emails at paul at eventuallyanyway dot com. [Less]

Mark Shuttleworth announced at OSCON 2008 that Launchpad will be open source within 12 months. This is good news. A lot of people have whinged about Launchpad's lack of open source status as the reason they don't use Launchpad for their project ... [More] hosting (although it does seem that they are quite alright posting projects to Google Code). What people don't realize is that many of Launchpad's elements are already open source. Recently, Canonical helped the Gnome community set up a "Bazaar Playground," a server which contains Bazaar branches created from the trunk and branches of Gnome's various Subversion repositories. This allows all the Gnome hackers to give Bazaar a test run and find out how wonderful their workflow can become using Bazaar. Everything from this project is available as open source software. I thought I'd post about the software used in the playground, as well as other software that can be used tho achieve similar functionality of Launchpad. Bazaar and Friends (Plugins) Obviously, Bazaar is the big part of this mix. If you're setting up a bazaar playground, it makes sense to that you'd need Bazaar. However, one of the great strengths of Bazaar is in its plugins. In this case, the bzr-svn plugin that will allow you to create bzr branches from an svn repository and push and pull from it just like you would any bzr parent branch. It's an excellent starting point for getting comfortable with bazaar without completely dumping subversion. It was a good transition for me as well, because I wasn't quite willing to commit (no pun intended) to bazaar when I first tried it out. Without bzr-svn, I wouldn't have been able to give bazaar a fair chance in working with my stable projects. Loggerhead I've never liked the Loggerhead name, but it's a great little piece of software. Loggerhead is a web viewer for bzr branches. A good example of what loggerhead looks like can be found here. It's always helpful to be able post a url for a specific revision, a diff between revisions, etc. The Gnome theme for Loggerhead took more work than expected, and so work is planned for making Loggerhead more easily themable in the future. Patch Queue Manager PQM has seriously changed the way that I feel about merge management. Just like Ian Clatworthy points out in his paper "Community-Agile Software Guidance", trunk should be release quality all the time. PQM makes it IMPOSSIBLE to break trunk, so trunk is always reliable. The basic idea of PQM is to take the whole queue of approved branches and merge them automatically if they pass all the tests. This leaves out the human error of merging, and keeps the quality of trunk up, so that development time isn't wasted trying to figure out who broke trunk, why, and how to fix it. Bundle Buggy The more I see and use Bundle Buggy, the more impressed I am with it. The code review voting is a new feature in Launchpad, but the Bazaar developers have been tracking code reviews and votes on the mailing list for quite some time. Bundle Buggy detects emails prefixed with [MERGE] (usually sent from bzr send), and tracks the comments made about the patch, until it has received the right amount of votes from the right people. All of this can be managed from the mailing list, so it doesn't require too much interaction for the review and merge process. The last thing that I would like to point out is that, while you can still build an infrastructure close to that of Launchpad, you still can't just up and build a community around your project. While I've blogged about this before, Launchpad is about building communities of people around open source. So sure, you can use tools that work together similar to Launchpad, but do you really want to put your project in a corner of the internet where not many people will find it? [Less]

I am now convinced that the only (decent) way to get better at writing code is to get the code you've already written reviewed by someone else, and to review someone else's code. I've seen enough code reviews from both sides to realize the amazing ... [More] investment in a developer by participating in a code review with them. Many eyes make all bugs shallow. -Linus' Law Let me 'splain. No. Let Me Sum Up First of all, if your code review ever results in the following, you're doing it wrong: shouting matches, gunshot wounds, spitwads, homocide, suicide, genocide, or insecticide. Before doing a code review, take a gander at the Ubuntu Code of Conduct". It's a great guideline for open source development in general, and it's best to adhere to these guidelines in code reviews specifically. The purpose of the code review is the betterment of code, reviewer, and reviewee. It's been almost a year since I first started hacking on Entertainer. It started as a hobby toy application, with a few young developers. In that time, we have implemented various procedures and code standards. Only recently did I submit some code for review that I realized how insightful these same developers have become, all from code reviews. Why Review Code? As I've started reviewing code from other Launchpad developers, and talking with experienced code reviewers, I have seen a few schools of thought on the "why" of code reviews. The first reason to review code is to check for potential bugs. What's great about this is that if you're following TDD, or any test-driven methodology, checking the quality of the tests is a great indicator to see the functionality of the cade you're reviewing. Another reason for code reviews are to doublecheck implementation details. This is helpful when reviewing an area of the code that you're not familiar with. Ask the reviewee plenty of questions. Often, in answering these questions, a reviewee might see issues in their own code. When introducing mandatory code reviews, the process is a little awkward at first. Why wouldn't it be. You're probably used to just writing code and committing it. Introducing code reviews means many more steps required to get your code into the mainline. But how confident are you in the code your fellow developer is? What happens when you have to work on their code? If you've reviewed that code, you'll probably understand the code in at least some capacity. [Less]

I've been working, in my spare time, on a really fun Django project. It's allowed me to play with some of the Django toys that I haven't really gotten around to playing with recently. One of the things I've been doing is building my app with good ... [More] tools, and one of things I've been doing in building my tools is using custom django management commands. Out of this process came a tool that I thought might be beneficial to share with others: django-fabric. Fabric is a command line tool similar to the popular development tool Capistrano. However, it's more lightweight, uses python, and doesn't assume anything about your environment (language, vcs, etc.). I've been using it so much recently that I built a django command for it. To use it, download, install, and add to your INSTALLED_APPS. Create a fabfile, which is just a python file with your deployment instructions in them. You'll need to add that file (by name) as settings.FABFILE. Then, manage.py fab <command>. For more information, see the Fabric documentation. For Ubuntu users, Fabric can be installed by adding my PPA repository and installing from there. I'll be adding the django-fabric packange there too, once I get it to a stable point. [Less]

I've moved this site over to its new home. If you're seeing this message (and links to allow comments), you're on the right server. I'll be shutting down the old system at the end of the week. A side effect, however, was that I seemed to have spammed the various planets that my blog is attached to. Sorry for the noise. ! :)

I use bzr everyday. Seriously, every day. It's become a tool that I honestly can't live without, and, while I'm not really a "fanboy" per se, I feel let down whenever I need to use another VCS. One of the greatest things about bzr is its ... [More] ability to have plugins. People talk about how many "commands" other VCSes use, but they aren't plugins, so they are limited to what can be done. I think there's a real value in being able to use an established API to work with repositories, trees, and branches. Because I use bzr frequently, I've come to love a few plugins that I can no longer live without, which I've compiled for your reading pleasure. Bzrtools Aaron Bentley compiled a set of various tools and made bzrtools. If you're using the bzr PPA, chances are that bzrtools gets upgraded with bzr. It took me a while before I realized that tools like shelve, cbranch, and patch were from bzrtools. shelve allows you to take a specific change and "put it on the shelf" for a bit. For instance, say that you find a bug while working on a feature. You can shelve the changes for your feature. This will allow you to specify what goes on the shelf. If you shelve it all, the tree will look like you did no work at all. Then you can fix your bug and commit, and then unshelve your changes using unshelve. To see what's on the shelf, use shelf. cbranch is a feature I don't think many will use, but those who will use it will soon learn they can't live without it. I like to keep my trees and and my branches/repositories separate. I keep the branches in a repo, and then do lightweight checkouts into an area where I can work. cbranch will, in one fell swoop, branch from a location into my shared repository, and then create a lightweight checkout in the place where I do my work. THAT is the very definition of efficiency. bzrtools provides all sorts of other commands, such as pushing over rsync (rspush), pulling of many branches at once (multi-pull), importing from a tarball (import), and the ability to kill unknown files in a working tree (clean-tree). bzr-loom bzr-loom is the bazaar version of quilt, mercurial-queues, etc. The basic idea is that you have a few branches that are all built on top of each other, but are separate in versioning. Start with one "thread," work on it. Create another thread that is dependent on the first, work on it. Create another thread, but find a bug in the implementation of the first thread's feature, so go down to that thread and fix the bug, and move back up. I think my best use case is when dealing with reviews. No one really wants to get a 15K line patch for the next big feature of an application. I use threads in a loom in this situation. I can work on the first thread, and submit that for review. I can then create another thread, hack on it, and submit it for review. If, during the review of the first branch, I can easily hop down to that thread, fix changes, and those changes will be available in all the upper threads. This allows me to concurrently work on a branch, so I'm not blocked on reviews because someone hasn't gotten around to actually reviewing them yet (which I am guilty of doing). The great thing about this is, if I can land the first branch after review, and it won't break trunk. I can land that branch, and continue on. When that branch lands, I just combine-thread and keeping hacking on the upper threads. It's even more flexibility in an already Agile system. bzr-upload bzr-upload is just a small plugin, but it's infinitely better than the alternative. bzr-upload allows you to sftp a branch's working tree to a system that doesn't have bzr installed. This was especially helpful when I was on a shared server account. The great thing is that I can easily push a version of the working tree that's not the current revision. So, if I had bzr uploaded a bad version of something, I could revert easily with a bzr upload of a previous revision. Bazaar External Merge I've liked meld since the beginning of my days using mercurial. When I first was using it, I was manually syncing a Mercurial repo to an svn clone (before there were good tools). bzr ext-merge allows me to bring meld in when I need to get my eyes on the diff itself to figure out how to resolve conflicts. I don't use this tool a lot, but it's still one I couldn't live without, because when I need it, I really need it. Bzr Gtk Once again, a plugin I don't use every day, but would be upset if I didn't have it. Out of the various options, I find I use bzr viz the most, to view the history of the branch. It can be rather slow in cases where the branch is large, but the visualization of branch data is great. I can see just how the merges came together in various branches, etc. I also find that every once in a while, I use bzr gannotate to see the visual annotations of a given file. Being able to visualize that data is helpful in that I can see who modified what, and when they did it. This isn't a particularly stellar feature, but it's one that would make life hard to be without. Of notable mention of other cool bzr plugins (but those that I don't really need per se) are: bzr-diffstat, bzr-builddeb, bzr-vimdiff, and bzr-svn. [Less]