Here lies the last 25 entries in my weblog. Follow the yearly archives
to the right for more.
Check Out The Raid Documentary
This weekend I watched The Raid. It's a documentary about a raid group in World of Warcraft. Now for some, this alone is enough to draw you in. I can see some of you, though, need more convincing.
First, this is fascinating to watch if you play MMOs or other online games or if you work in any form of online community. The premise is that this video follows this raid group along as they work toward defeating the Lich King. There's certainly a good bit of just that -- players talking about raiding, raid mechanics, different bosses, and so on. But there's also a lot of analysis from people who study games and gamer communities. They try to tackle questions like -- why do people spend so much time in games? Why is this fun? Is it good or bad to do this? What are these people like?
I am serious; this is a good film! It's well made and is beautifully cut together with game footage. I'm embedding it below for as long as it's up. You'll need to skip to about 25 minutes into the video to see the film itself. I highly recommend this for people who enjoying gaming, working together on the Internet, or both.
I spent last week at O'Reilly's Velocity Conference. This was my first year to attend Velocity, and I was there as part of a group of us from Canonical's Core Dev Ops group. The conference is about all things web performance and web operations and since the Core Dev Ops group at Canonical deals in these areas, it made sense for some of us to attend. Also, we on the Launchpad team have been doing a lot of work to bring Launchpad development forward in terms of performance and operations -- making Launchpad faster, continuous deployment, etc. -- so I was curious about how the work we're doing fits into the larger performance/ops culture.
Rather than go talk by talk through the highlights of the conference, I'll mention the things that consistently struck me as I sat through all the plenaries and sessions, as I got to know other attendees over lunch and after hours.
Launchpad and Velocity Culture
First off, I was really encouraged about the things we're doing on Launchpad and how we fit in well with many of the speakers and companies presenting at Velocity. I certainly felt pushed to do more than we're doing and came away with a renewed interest in certain areas -- data-driven development being one -- but many of the issues that were hammered on were ones that we're already focused on with Launchpad, e.g.
track performance metrics (esp. 99th percentile) and iterate to improve
embrace change and make recovery easy (e.g. have a rollback/forward process)
Spread responsibilities across dev and ops, rather than splitting between the two
Again, I felt really encouraged. Sometimes we can be our own worst critics, and since most of us in Canonical are aggressive about moving forward and following current development trends, it can sometimes feel that we're playing catch up, especially on Launchpad. But I felt quite the opposite of this at the conference. What we're doing on Launchpad is on par with the topics covered at the conference. Many of the people I met over lunch were all new to the topics, and I felt I was right with the speaker at nearly every session. We should definitely see about some of us from Canonical proposing talks for next year's Velocity.
Of course, I felt challenged, too. I have some areas I'd like to focus on myself and see us to do better at during the rest of this year.
Data-driven Development
As I mentioned above, I feel really motivated to embrace metrics as part of our development process. We do a pretty good job of this now on Launchpad, I think, but I'm talking about really pushing at this. Tracking everything. Especially around what users are actually doing on our site.
John Rauser's talk "Look At Your Data" and Kellan Elliott-McCrea's "Metrics-driven Engineering at Etsy" stand out as stellar talks that sold me on the value of this. We already track a lot of metrics about the data we have -- how many bugs are filed, what sort of users is working on Launchpad, and so on -- but I'd like us to do more of the correlation between data sets these guys advocated. As well as seeing us have data to back our decision making, rather than assumptions at any point.
Browser Testing
Finally, and perhaps one of the nicest outcomes of my time at Velocity, is that I settled the issue of how to approach browser testing on Launchpad. We've been using Windmill but it has never been very stable. After sitting through the Tuesday workshop on "Automated Web Performance Testing" I finally had an a-ha moment about why this is. As Sidnei phrased it on Twitter after my a-ha moment, it's a matter of "JS fighting with itself for control." Selenium 2 is better by far, since it's based on WebDriver, using each browser's native mechanism for driving browser tests.
Not only do I want to see this testing story solved, I'd also like to do more cross-browser testing and reporting with Selenium 2 than we currently do. Up until now, our testing has been more integration testing, especially around XHR integration. I'd love to see us actually test multiple browsers and get data back about how we're doing across all the browsers we support. This was another of the themes at Velocity related to front-end engineering, and I'd love to see us embrace this on Launchpad.
I have a branch going to show how nice the Python bindings for this are and hope to find some lp devs to work with me to finish this off at the Launchpad Thunderdome (our bi-annual all-hands sprint) in Dublin next week.
And with that, I need to get back to prepping for that sprint in Dublin next week. Velocity was time well spent, and I look forward to see what comes of these ideas (and others) next week in Dublin.
I just finished a call with Curtis to figure out how to fix these pesky ShortListTooBig errors that crop up from time to time (like bug 680131). When I finished the call, I had that "a ha!" moment where I thought, "yes! this is why I like the new squad system in Launchpad!"
The problem here is that we use a snapshot mechanism in Launchpad to be able to check the state of an object prior to a given operation on that object. This falls over with large collection objects on Launchpad and we occassionally get the bug like above, which requires us to add a doNotSnapshot call to collection fields. It's stupidly simple to fix, but I wondered why we just didn't quit snapshotting collections anyway. After my call with Curtis, I now understand why we once needed this behavior -- it's to do with needing a reference to the last known comment on a bug or question -- and I now have a plan how to fix up the event object properly and will remove this for all collections after that.
The bug fix is really not that interesting or important, though. That's the background for all this. The interesring bit was Curtis and I talking about Launchpad as an entire application, and how this could be fixed, and how it was relevant for bugs and questions alike and maybe merge proposals. And it just really felt good to be thinking about how to fix Launchpad and not just some small part of it. Previously, I would have likely been thinking about the impact to the bugs part of Launchpad and looking over the simpleness of the proper fix.
Sure, I always had freedom to fix Launchpad however I wanted, but not thinking like a bugs developer makes it easier to spot the obvious fix better.
This mainteance rotation has generally been useful, fun, and interesting like this the whole way. My squad has been on maintenance work 3 or 4 weeks now. The "maintenance rotation," as we call it, is part of how Launchpad manages assigning developers to feature or bug work. Each squad gets a turn at a feature, then a turn at maintenance. Francis has some nice posts on the Launchpad blog for how we decide what to work on next and how we pick feature work.
So I'm working on this sort of bug, making Launchpad itself incrementally better every day. Abel has been burning down timeouts like there's no tomorrow. Aaron has been doing a nice mix of large and small fixes, and Henning's been working on some security issues. Basically, we're really focused on trying to burn down the list of critical bugs by our next Launchpad team sprint in June.
I got my first Windmill hang using the for loop test runs I mentioned yesterday. I also managed to get another one this morning. Both seem to indicate the same thing -- we're getting stuck waiting inside client.open calls. Looks to be something smelly in Windmill's JSONRPCTransport.request call. (btw, doesn't that class name frighten you! It should!)
I'm still trying to get my head around why this is happening, but at least I know what is happening now. I've learned more about Windmill as result, which is always good. But I've also discovered scray things -- like calls to time.sleep inside while loops. I literally had crazy dreams last night, that I attribute to this frightening fact. My confidence with Windmill is erroding again, but I'd like to fix this issue without letting that color the experience for me.
Anyway, it's a brief update, but that's where I'm at. I'll likely think on this and poke at it through the weekend and decide a course of action by the time I start work again on Monday. Until then.....!
I've been making slow progress on getting our Windmill tests re-enabled on Launchpad. We've got a lot of people digging into JavaScript on Launchpad now, which is nice, but we have relatively few JavaScript experts on Launchpad, so I've been fielding a fair amount of questions lately on good JavaScript patterns, YUI 3, testing, and especially on how to divide testing between YUI tests and Windmill. I'm thrilled about these interruptions, don't get me wrong. It means more of us are becoming proficient with JavaScript hacking in Launchpad. We're also getting close to finishing our first feature on my squad. So yesterday was largely voice calls and IRC chats. The queue to speak to me was longer than than the PvP arena queue in DC Universe Online.
Ok, so I can't take any credit for this. It was a fix from Ian Booth, which landed in devel and got the broken test going again. In the end, the test was correct and required code changes to fix the overlay.
The couple hours I spent on Windmill yesterday, I spent running the dev server for Launchpad and poking at recipe pages. I had sprinkled some Y.log statements around the disable_existing_builds function in lib/lp/code/javascript/requestbuild_overlay.js and was trying to work out what the various variables were about. I was toggling back and forth between the dev server and the Jenkins page for Windmill, trying to work out where this was failing, when I realized the build was passing again. So I ran the test in my copy of devel, realized it was passing now, and looked through the logs for the revision to be sure of what had happened.
After that, I was near my end of day so I fired off the branch to ec2 test, to see if I could get a hang. My first test run passed, so I fired off another before bed, which also passed. This is part of the frustration of Windmill. It's passing in ec2 for me. It's passing in Jenkins now. But I know that as soon as I turn it back on for our runs in buildbot, it will start failing for someone. If I didn't have team lead responsibilities and knew I could babysit this properly, I would turn it on and chase failures directly as they appear.
My plan today is to do something like the following, in the hopes that I get a hang:
for i in `seq 10`;do ./bin/test -cvv --layer=WindmillLayer;done
If I do, then I'll attach with gdb and get a backtrace to see if I can work out what is causing the hang.
This week I've started work on getting our Windmill tests re-enabled. William Grant had to disable them in our automatic runs, since they were failing spuriously too often. William pushed them off to a non-blocking Jenkins run, which is good for those of us curious about them, but as Björn noted way back, you have to block on test failures or tests will bit rot and be useless. So this week, I've set myself the task of getting these tests going again.
For those who don't know, Windmill is what we use on Launchpad for browser XHR integration testing and to run our suite of YUI tests. Windmill is like Selenium, for those who know that tool. I have a love/hate relationship with Windmill. I love what it promises to offer and hate it when it doesn't live up, which can be frequently.
I've spent a lot of time getting to know how Windmill works in an attempt to make it stable for our use. Failures in Launchpad usually come in two forms:
Windmill not playing well within our Zope test runner
People not knowing how to write good Windmill tests
We've made signicant progress on writing better tests, though some weak tests still exist and people make innocent mistakes. The main pain lately has been that Windmill is not playing well with our test runner -- i.e. hanging test runs or tests that fail for non-obvious reasons. My task this week is to sort out why this is happening so regularly now and craft some fixes. In order to share knowledge (and hopefully get someone on Launchpad working on Windmill along with me) I'll blog everyday this week about my progress.
Yesterday was not too fruitful. I spent most of the day working on the first of the tests that has rotted. I have to have a good test suite before I can suss out the other behavior. This test is failing due to string comparisons that now fail due to recent recipe page changes. I'll go into greater detail in a subsequent post about how to fix this test -- once I know! :-) -- but for now, I'm trying to work out if the test is broken and should be changed or if the behavior is broken and should be fixed.
My gut says it's the test that's wrong, but I should know for sure here shortly.
I've been enjoying reading posts from my colleaques at Canonical this week about the work they do and how they feel that work contributes positively to Free Software. Even before this blogging meme started, I've always felt good about what we do at Canonical. How lucky am I that I get to wake up every day and work on, with, and for free and open source software?
I've blogged about my love for this work more than once, but I can't let the current meme pass without contributing. So here are my thoughts on what I do every day and how that helps Free Software.
Launchpad
I work on Launchpad. Launchpad is itself free software. That alone is a win for me.
Then there is the fact that:
All of us working on Launchpad are free software hackers
Launchpad's expressed reason for being is to enable development between and across free software project boundaries
Ubuntu is built in the open on Launchpad
Many free/open source software projects use Launchpad (19,521 at this writing)
And then there's all the individual pieces itself that are interesting and useful -- Bazaar integration, code hosting, translations, and on and on.
I'm saying all this to say, there's nothing else like Launchpad -- nothing else that exists to enable cross-project development, has deep ties into a distribution as popular as Ubuntu, is actively being developed by people who love and contribute to free software, and is itself free software!
Seriously, I'm lucky to be part of this.
And then there's my little corner of the Launchpad world.
The Bugs Team
I work as part of the team that works on the bug tracking app in Launchpad. I manage this team, so the majority of my time is spent doing lots of work to coordinate between bugs team developers, the work we have to do, and the people using Launchpad. These users could be any user of Launchpad, both users inside Canonical and in the wider free software community.
Any time I have left is spent in code, which falls largely into bug fixing, doing code reviews, or working on questions of UI or code design. The work I do land feels as rewarding as any other FOSS project I've worked on. I've contributed to Samba and Django, among a host of other smaller or personal projects, and landing something on launchpad.net feels immensly rewarding for its double impact -- the code itself is free and the site is used by so many free/open source projects.
Then, because of my role on the team, I think a lot about bug tracking across all the communities that make up free software. I think about Ubuntu's needs. Ubuntu has a lot of users (some of them highly technical, some of them not) and all of them report bugs in Launchpad. A lot of bugs actually! I also think about the needs of upstream projects. Some use Launchpad, some use their own bug trackers, and some use both.
And my favorite thing about this work is that my team is not complacent about our work. It's difficult trying to get a bugs system that works equally well for a large distro and also for individual projects. I don't think we've really even succeed at this goal. But we're passionate about the problem, and excited by the challenges. We continue to make improvements to Launchpad and are constantly thinking about the issues around trying to share bugs across free software projects.
Beyond Bugs
Beyond all this regular day to day work, we are active in other free software projects, too. I mentioned some of the projects I've contibuted to in the past. I'm currently working on some of my own smaller projects outside work. Devs on my team provide patches to Zope, Storm, and other tools we use on Launchpad. We also have worked with upstreams to get their bug trackers in shape for syncing with Launchpad. Canonical even provided support to upgrade Gnome's Bugzilla install and some of that work made its way into upstream Bugzilla as Bugzilla API improvements.
I could go on and on, but this has gotten long enough I think. I'm grateful for the chance to do what I do, and I wanted to share why I think the work is important.
Link | Posted by deryck on September 16, 2010 | 0 comments
Help with Launchpad Bug Import Script
I and my fellow Launchpad bugs hackers have always helped people migrate to Launchpad by doing bug imports for people running other bug trackers. This has increasingly taken more and more of our time, and we've gotten worse at doing it in a timely manner for people. This is mostly because we really want to get fixes and improvements to the bug tracker itself landed. And really there's no need for us to do all this. Anyone can import their bugs into Launchpad using a Launchpad API script. So here's where I come to you, dear reader, asking for help....
Does anyone have an existing API script to import bugs into Launchpad they would be willing to open source? Or would anyone be willing to take our existing Launchpad import script and convert it to use the API? Ping me in the comments on this blog or via email if you're interested. Or catch me on IRC on the Freenode network (nick is deryck).
Link | Posted by deryck on September 1, 2010 | 3 comments
Playing Champions Online on Ubuntu
I've been playing Champions Online for a little over a month now, and I've been playing it on Linux, running on Ubuntu 10.04. I searched online for help and had to piece a few things together to get the game running smoothly under wine in Ubuntu, so I thought I would do a quick post here detailing the steps I took.
The quick start guide is this:
Create a new wineprefix
Install ie6 and gecko with winetricks
Create script to export WINEPREFIX, cd to prefix, and use renderthread argument
Disable mmdevapi via winecfg
Add -softwarecursor and -ignorex64check at launcher options
For further details, see my comments below.
Create a new wine prefix
For some reason Champions Online plays better if it doesn't share the wineprefix with any other games or the wine prefix is not otherwise heavily customized. In fact, I've since found that having each of my MMOs in its own wineprefix has made each play better. This is a bit of a disk space hog, so I would love to know if there's a way to better share the wineprefix without causing problems for each game. But for now, this works well.
The wineprefix is the directory where wine stores its data. If you don't specify the wineprefix by exporting the WINEPREFIX environment variable, then $HOME/.wine is used. I did something like this:
wineprefixcreate --prefix ~/.champions
Install ie6 and gecko with winetricks
winetricks makes installing windows software via wine easy. IE6 and gecko are required for the Champions launcher to run. So this is as easy as:
At this point, you should be able to install the game. Download the game, and run:
$ wine $PATH-TO-GAME-DOWNLOAD/setup.exe
Don't worry if the installer hangs. Kill it and start the launcher, which will patch the game and finish installing everything.
Create script to export WINEPREFIX, cd to prefix, and use renderthread argument
There are a couple of tricks to getting Champions to run now, so I make this easier by using a script to run the game. Basically, we want to export WINEPREFIX to point to the right place for the game, cd into the directory where the game is installed, and pass in a renderthread argument. This renderthread argument prevents the game crashing at startup.
I cd to the directory for the game because sometimes the game leaves behind log files, and I don't want them littered wherever I happen to start the command from.
Disable mmdevapi via winecfg
Sound was a bit of a pain to get running, but I discovered a simple trick to make this happen.
$ export WINEPREFIX=$HOME/.champions
$ winecfg
And then click the "Libraries" tab. Then click "Add". Then create an entry for mmdevapi, and set it to disabled.
Presto. Sound!
Add -softwarecursor and -ignorex64check at launcher options
Finally, I had to add a couple options in the game launcher. The first is to get the cursor working in game well.
Once the launcher appears, click "Options" in the menu items at the top. Under "Advanced command line" add:
-softwarecursor
(Note the leading dash.)
Then, to make sound a bit more stable add:
-ignorex64check
Again, the leading dash. This last option could be because of my system and may not be neccessary for everyone. I'm running Ubuntu on Mac hardware
Now the game runs well. Enjoy! I know I have. And for those cursious about the difference between this and City of Heroes, I'll try to do a post on that later.
I love watching this graph lately. It's the percentage of bugs that status flap marked opinion (green) and marked invalid (red). By status flap, I mean that the bug was set to the opinion or invalid status once, and has had any number of status changes since then.
People are still trying to get their heads around the opinion status on Launchpad bugs, I think.
I discovered today that Facebook allows third party sites to make use of something called "Facebook Social Plugins" which can make it appear as if you are logged into other sites through Facebook. You are not able to opt out of this.
For my non-tech friends who wander by here, this uses what's called an "iframe." There are some protections built in because of your web browser's security policies, but this is open to abuse easily. Facebook could snoop on what sites you visit that use these plugins. Facebook could list what you've visited on your profile. The only thing preventing abuse is trust. You have no way to turn this off in Facebook settings currently. Please see FAQ items linked above to confirm this.
You should log out of Facebook after every use or use a browser plugin that does this for you to prevent abuse until Facebook changes its policy on this. I have to admit this is so shady and open to abuse and coupled with the fact that it was not announced widly that I am now seriously considering abandoning Facebook altogether, despite the great personal value I get from connections with people on the site.
It's Friday of UDS-M. I'm writing this from home, waiting on my electricity to be restored. I'm anxious to get to work today, to put in place plans to act on some of the ideas for Launchpad Bugs that came out of UDS-M.
With timezone differences between Alabama and Brussels, the day is half done at UDS, while the sun isn't yet up here. I came home Wednesday, but due to 5 hours of delay at the Brussels airport and 2 hours of delay getting through customs in Atlanta, I didn't get home until early AM yesterday, finishing at a better than twenty-two hour travel day. I was exhausted, and spent most of Thursday in bed. I can begin to imagine how my New Zealand and Australian friends feel every time they travel, and I wonder how they can even function afterwards.
I really only spent two full days at UDS. Monday was mostly about Launchpad Bugs for me. I went into a couple QA-related sessions. Jorge put together a couple sessions around patches and bugs that I attended. There was also the developer workflow sessions on both Monday and Tuesday. Certain themes came up frequently -- converting patches to branches and dealing with loads of bugs were mentioned often. Tuesday I had some time for a couple sessions of interest to me personally, mostly to do with the desktop track and application development on Ubuntu. Quickly and Ground Control are amazing, and you should be using these if you're not already.
I even found small bits of time for hacking next to friends on the Landscape and Bazaar teams who were sprinting at UDS. I contributed a tiny patch to Ground Control, and between these two days at UDS and hacking nights at the SomeHands meeting we had for work the week before, finished off 3 Launchpad branches and got some serious work done on lazr-js/Launchpad branches exploring ways to clean up all the icons on the bug page. I also did a bit of mockup hacking, to get the ideas from these branches in a form easy to show and talk about. We've made some progress in the last six months making the bugs home page for a project really nice, and I hope we can do something similar for the bug page over the next six months.
Our plans currently include making subscriptions and notifications better for Launchpad bugs. The rest of our 6 month cycle is yet to be planned, though we have certain themes we know we will be exploring. Everyone at UDS had ideas about what we could be doing to make Launchpad better. We're all software engineers, so opinions are easy to come by. Now we have to find a way to schedule the fixes that make sense, while also thinking of clever ways to address the larger problems, and all of this has to be done in the themes we've set for the coming development cycle for Launchpad.
There's lots to do, definitely. Now if my power would just come back up, I could get started working on some of this.
I've spent the last couple days catching up on bug traige. Triage often leads to one of those moments where I think, "I know I've seen this bug before." I could go through the normal search page on Launchpad, looking for recently changed or newest bugs, but I usually don't do this. The search form feels slow and heavyweight when I just want something to nudge my brain about a bug I know I've seen before.
The "Report a bug" page for a project on Launchpad features a duplicate search before allowing you to a file a bug. Take the filebug page for malone, the project I work on, for example. This page loads fast for me and has just the "Summary" form input. I usally type a couple words in this "Summary" field and hit enter. Something like "ubuntu bug timeout." The dupe search gives me ten hits quickly, and the bug I'm trying to remember is almost always listed here. I often use the filebug page dupe search for these quick and easy search queries, rather than the normal search page.
I've heard from others that do this, too, but I'm not sure how widely this is known. The filebug page makes a great quick search page. Give it a try if you haven't yet.
Why No One Is Happy Today (and what that means for web developers)
I read mdz's post on "Breadth and depth" today and found it contained many, many interesting links. Take this video of Barry Schwartz's 2005 Ted talk.
I had heard of Schwartz's research before but this is the first time I sat through a talk from him. His arguments are compelling, and I find myself fully convinced. We have too much choice and it's killing us. For those who don't know him or don't have time to sit through the video, his main point is that despite all the choice and opportunity we have in affluent, western societies, we find ourselves more unhappy than ever.
There is a lesson here for makers of web sites and web apps, too. More choice is clearly not a good thing. We know that sites that focus on a smaller set of tools are often more popular than fuller-featured counter parts. Now we know why.
I'm doing a release manager rotation for Launchpad this week, helping see us to the rollout of Launchpad 10.03. It's been a nice experience, and I've learned a lot about various aspects of Launchpad and our releases that I would not have learned otherwise. I'm still amazed at how much time we invest in a release as compared to development time when we only have 4 week development cycles.
Here's a comment I wrote on Facebook after co-workers commented on a status update where I wrote something similar to the above.
Think about all the wasted dev time we have around release, and with short cycles anyway.
I lose a week on a release manager rotation. Devs on our teams lose 3-5 days depending on what is going on. Continual deployment would keep us moving forward much faster. There are some technical issues for Launchpad to do this, and also, there is some progress being made towards a form of this.
But still, I want to think about coding and quality of features not release semantics. :-)
I've written before that release is a word give too much weight in web development. Having done a rotation as an actual release manager now, I still feel the same. Again, I'm hopeful this is changing, at least somewhat, for Launchpad, but I want to continue to talk about how we can move to continual deployments. I see nothing but positives to be gained from this, assuming the blocking technical issues can be overcome.
This book on his life and writing is good, though not as good as other books I've read like this. I enjoyed the personal passages about his life, more than the thoughts on his craft. The chapter written on his father's death stands out as a moving essay.
I have always been a fan of Graham Swift's fiction, so as a fan, I enjoyed this book. It's not as good as others like this I've read. Art Objects by Jeanette Winterson is better by a contemporary British author, and Mystery and Manners by Flannery O'Connor is a great example by an American author. Still, fans of Swift and other writers might enjoy this.
Every time I read a book like this, I wish for more books like this in my field (computer programming, for those who don't know me). I would love to read from great hackers on how they became the person they are, how life has affected craft, and so on.
I've got to lose weight. Working from home and the sweeties that line the red bar in the kitchen 6 feet from my desk are killing me. I can't do diets. So here are my simple principals for de-fatting myself that I plan to stick to for the next 3 months to see if it makes a difference.
No snacks between meals (at all!)
No desserts
Evening meal must be the smallest meal of the day
Drink lots of water
I'm going with the keep-it-simple path to see if just controlling my food consumption is enough. I'll let you all know how it's going in a few days.
Link | Posted by deryck on February 17, 2010 | 0 comments
Websites Don't Release Anything
A couple weeks ago I was in London for a Launchpad team leads sprint.
There were lots of cool discussions, focused mostly on processes within
Launchpad. Because of all this process talk, we ended up talking
about our release process a fair amount. I had some ideas forming
before this, but a week's worth of discussion helped cement my thinking
about "releases" for websites. Now some two weeks later, I'm still
thinking about this, so here's a quick sketch of what's on my mind.
First, websites don't "release" anything. It's a metaphor, and a
poor one at that. We update the site with some version of our code.
Different sites do this differently. With regular updates to
edge (our beta site which many of
our users use anyway) Launchpad has many levels of release -- code
updates to edge regularly, db updates to staging regularly, and roll
outs of both to the main site monthly. Other sites just continually do the
equivalent of svn up on trunk on their site and apply DB
updates as needed.
Using the term "release" so casually also makes you feel like you have
to build in artificial barriers to make the false release feel more
like a traditional software release. Version numbers are a prime
example of this. We give a version number to each month's "release"
on Launchpad, and I think the only purpose this serves is to confuse
developers and users about the meaning of the number. If I download
Django 1.1 and hate it, I can choose to download Django 1.0 and use
that instead. If you hate Launchpad 10.01, there's nothing you can do
about it. If we bork something in 10.01, it's not like we're rolling
back to December's release (whatever it was numbered). We will continue
moving forward, adding a new branch that removes the busted feature or
fixes the newly introduced bug, or what have you.
And it's this very act -- the act of continually moving forward -- that
makes me hate talking about website releases all the more. What
everyone who works on websites wants to do is move forward as quickly
as possible, constantly adding new features and bug fixes to a site.
The moment you place some arbitrary stopping point on the process and
name it a release, you slow down forward progress.
I realize some would argue this a good thing, that stopping causes you
to assess or do QA or ensure some other permanent quality is in the
"release." But there's nothing permanent on the web. I would argue
that rather than faking something permanent, your time would be better
spent getting features and fixes to your users more quickly. I know
I'm not alone in this, but still this word "release" hangs on, even in
web development.
I'm excited, then, to see some of the changes we're proposing to our
"release" process for Launchpad. Björn has proposed a way to
release
features when they are done which will require a new
merge workflow
for our work on Launchpad. These are all good things, even if the
specifics may change as we discuss this among LP developers. The only
thing that would make this better is to drop the word "release" from
any discussions of these new proposals. But old habits die hard, as
the saying goes.
Link | Posted by deryck on February 16, 2010 | 2 comments
Life Through the Lens of a Machine
Last night I watched
Surrogates,
which was a fun movie. (Yes, I have kids and watch every
movie later than the rest of the movie-going world.) I've also been
watching Caprica.
Then there's this little film called
Avatar, which it
seems the entire world has seen. As I finished watching Surrogates last night, I was struck by how much I'm seeing similar themes in sci-fi films and tv shows lately. These stories deal with people living their lives virtually through some intermediary -- an avatar in a virtual world, a robot, or a life-like robotic avatar, and so on. I suspect this will become even more common as time passes.
This suggests to me that there is a deep-seated sense among artists that such a future (or present) is immanent. People have been doing the machines-take-over-from-humans meme forever, but this is slightly different. This is humans-live-through-machines. Surrogates starts with a 10 year timeline that maps from creation of the first surrogate unit to world-wide adoption, which is realistic for how quickly technology can cause a paradigm shift. I think some form of this experience is very close to being a reality.
I say this as someone who views every activity of life through the "lens" of a computer screen. I'm not alone in this. Everyone I know might as well have a computer or smart phone attached to the body permanently.
I started reading The Singularity is Near some time last year. I've read bits and pieces but haven't committed to finishing it yet. I just recently moved this from "reading" to "to-read" on Goodreads because of this. I mention the book here because it deals with similar ideas -- this notion of a convergence of machine and humanity as we human beings push forward our own evolution. This can sound fantastic in the abstract, until you read the book, take an honest look at our computer-connected lives, or see a few stories like Surrogates, Caprica, or Avatar that make some version of this concept seem possible.
I'm not a technophobe, nor do I work in an area of software development that directly touches this kind of work. I do think, however, that inevitably I'll be connected to this kind of work, if I'm not already. "Everything that rises must converge" is not only a great Flannery O'Connor story, but also a great principal of life and technology. No one really knows what this future will look like, or what parts of it will be good or bad for us. It's nice to see artists wrestling with these questions, though. I'm sure the increase in stories like these only confirms how near such a future really is.
Link | Posted by deryck on February 12, 2010 | 0 comments
Anyone doing a lot of JavaScript development would benefit from reading this book. I feel very comfortable in the depth of my JavaScript knowledge, and I work with JavaScript on a weekly, if not daily, basis. I still learned things from this book. In many cases, I already knew about the particular peculiarity of JavaScript being outlined, but I learned a bit more about why a particular wart exists in the language.
Link | Posted by deryck on February 8, 2010 | 0 comments
2010 is here, now what?
With it being the new year, I feel compelled to do one of those predictions or new-year-resolutions posts. I'm not big on either so here's a bit about where I've been and where I'm going.
2009 saw me take a job with Canonical. I started working on the bugs app in Launchpad in April and have since been promoted to team lead for the bugs app team. It's been an amazing few months. Working for Canonical has been a wonderful experience for me. I went from working in companies as the lone telecommuter to a company filled with remote workers. It's wonderful and in the process I've learned a lot about being an effective telecommuter and managing a team remotely. I'll probably put these thoughts into a post sometime in the next couple months.
I'm also working with Zope more these days than Django. From 2005 until 2009, I was doing Django development heavily. There are days I miss Django, but I dip my hand in where I can, mostly with code that runs this site and a couple little toy projects I occasionally hack on. Launchpad is a Zope application, so since April, I've really tried to learn Zope as well as I can. I'm surrounded by great Zope developers on Launchpad, so like working with the Samba team, learning is made easier by absorbing from colleagues. I do like Zope, which may seem weird for a Django guy to say. I'm not a framework zealot, though, and I think Launchpad is a unique Zope app, so I should say, I like Launchpad's use of Zope. I need to do a simple Zope app at some point to get that perspective.
(I still don't love zcml, I have to be honest. The template language is growing on me, and I see it's power. Zope component architecture has won me over completely, though.)
Personally, I feel quite happy about where I'm at with balancing work and life as 2010 begins. I'm as productive as I ever been as both a manager and a coder, and I still have plenty of time with my kids and wife. Some of this is due to time shifting my day to better match European colleagues, but some of it is due to Canonical's focus on project management and communication in a distributed environment, which help to make work time very productive.
Some of my pet projects and hobbies languished a bit in 2009. Anytime you take a new job, this is to be expected. I didn't get the number of books read that I would have liked. I also didn't spend much time in world in Second Life, due to older hardware issues making the experience not so nice. So I want to read more and spend more time in world in Second Life. Discipline will help with the first, and the new laptop I got at Christmas will help with the second. I want to do some personal hacking a bit more, which is what I've always used Second Life for, honestly -- a bit of in world scripting to work on 3D math and similar concepts, viewer hacking to work on my C/C++ skills. I'm planning to work on being disciplined in releasing more of my personal, social-site hacking stuff, too, which is all Python and Django. I've swallowed the lean kool-aid, and I'm on a war against leaving work in progress. In everything personal and professional, I'm taking a task and seeing it through to completion before moving on to something new.
I guess that's my new year's resolution, if I have one -- no unfinished work in progress in 2010! With any luck, I won't wait until 2011 to post here again about how that's working out for me.
Link | Posted by deryck on January 10, 2010 | 0 comments
Kindle Crapped with Black Lines but Amazon Customer Service Rocks
I woke up Saturday morning and reached for my Kindle only to find the screen went boom when I slid the power switch to wake the device. Black lines filled the screen and the device was unusable.
This is what it looked like:
I have no idea what caused the screen to do this. I didn't use the device for about a week. It was sitting on my desk on top of a stack of paper books. Nothing was on top of the device and nothing around it.
Today my replacement Kindle arrived via FedEx. I only found time to call Amazon about the problem yesterday. Amazon's customer service rocks. I waited so long because I thought this was going to be a pain to deal with. The Kindle support site was nicely setup. It guided me through a form to submit a support ticket, and then the follow up email walked me through making a call to Amazon. A five minute phone call later, I had a new Kindle en-route, I assume covered by the warranty.
So while it was a bummer to have this happen, Amazon really is to be commended for making it better quickly.
Link | Posted by deryck on December 15, 2009 | 2 comments
The resemblance is uncanny. Except that my dog, Macy, has about 50 pounds on Gaiman's dog. I don't have any current pics of Macy but I'll try to snap a couple today.
I would include the pics, but can't. Go to his site and see for yourself.
This confirms my impeccable tastes, btw.
Link | Posted by deryck on December 11, 2009 | 0 comments
Book review: Web Component Development with Zope 3
This is a good introduction to Zope 3. I've been reading it off and on since I started working on Launchpad, which uses Zope. The book was good for helping me get the terms and conventions of Zope development, but Launchpad has a very particular use of Zope 3. Some of the more general web dev uses of Zope 3 covered in the book don't apply, for that reason.
But still, this is a good overview of web development using Zope 3. I would recommend the book if you're trying to get up to speed with Zope.
Link | Posted by deryck on November 28, 2009 | 0 comments
5 Years of Ubuntu
Yesterday was 5 years to the day from the first Ubuntu release,
Warty Warthog. 8 days from now we will have the eleventh release, Karmic Koala. I say "we" because
I work for Canonical now. While I don't have the historical
context that those who have been working on Ubuntu from the beginning have, I do share a sense of
wonder at what the last 5 years have been for Ubuntu.
I don't work on Ubuntu at Canonical; I work on Launchpad. But
I still feel very much a part of the development process of Ubuntu, just because Ubuntu is so tightly bound to
Launchpad. I have to say, too, that Canonical is unlike any company I have ever worked for. Everyone I work
with -- literally everyone -- is smart, kind, generous, motivated, and generally a pleasure
to work with. To me, this speaks to the heart of what Ubuntu is and what it means to me. Community,
collaboration, and a more human computing experience are not just concepts weaved into Ubuntu, but literally,
it's the ethos of the people involved in the project and in Canonical.
So my day to day experience of using Ubuntu and hacking on code that contributes to shipping an
Ubuntu release is an experience of the best parts of humanity and software development. And I'm quite
glad for the opportunity.
Here's to the last 5 years of Ubuntu! I hope I can keep this front-row seat for the next 5, and beyond.
Link | Posted by deryck on October 21, 2009 | 0 comments
