Setting your gnome window manager in Breezy


Edit or create ~/.gnomerc and add "export WINDOW_MANAGER=sawfish" (or whatever) to it.



Apparently Gnome 2.12 (and hence Ubuntu Breezy) decided to stop supporting the /desktop/gnome/applications/window_manager entry in gconf. The key says "This key has been deprecated since GNOME 2.12", but what they mean is "broken", not "deprecated" (from what I can tell).



It took me a while to figure this out, so I'm posting it with the intention that google will pick up on it and help other hapless non-metacity users.



Liebot, what is the saddest thing?


Instead of writing my OSDC paper last night, I watched Grave of the Fireflies. I picked it up a few days ago to expand my collection of Studio Ghibli films. It's about two Japanese children during WWII.



It's a great movie, as I have come to expect from anything out of Studio Ghibli. The animation is fantastic, but you can see it come out in a different way in this one as opposed to the other greats like Princess Mononoke and Spirited Away; there's no magic or fantasy, so a lot of the mundane things get more attention. For example, the way a 4-year old girl cries about the death of loved ones.



It's literally the saddest movie I've ever seen. Similar to JML's hesitance to recommend Requiem for a Dream, I hesitate to recommend it to many: not because it's full of foul imagery and themes (although it does have its share of morbid stuff), but simply because the story is incredibly depressing. I was pretty well incapacitated after watching it, so I didn't finish up my OSDC paper. Even remembering some of its scenes is still now bringing a lump to my throat.



A good thing about its sadness is that it isn't purely about how some external force (e.g. drugs, war) causes strife for the protagonists, but also about their sometimes silly pride, bad decisions, or even bad timing. Oh well, I don't want to give anything away.



I guess I think everyone in the world should see it, but just make sure you're expecting some soul-crushing despair.





(This is not the saddest thing, but it is pretty sad)



muse ick


I had US$65 or so lying around in a US debit card and decided to spend it all on music from the Apple Music Store. Here's what I got.



1. Jamie Cullum is my new Teen Idol. I got Twentysomething, which has a song, Twentysomething, which is the best "twentysomething"-type song I've ever heard. I guess that's kind of self-fulfilling, there.



2. Black Mages II, the second mostly-hard-kinda-symphonic-rock (what the hell is that stuff called?) arranged soundtrack music from various Final Fantasy games, is at least as good as the first. It also has _vocals_, and they're in _English_, which threw me off for a bit.



3. Shpongle (Are you Shpongled?) was recommended by Andy Gayton. That was weird, and cool, with a couple *really* good ones. There was one song that sounded like it was made up mostly of the sound of a coke addict trying to clear his sinuses of bloody, cocaine-laced mucous.



4. Milt Jackson is (was) probably Jazz's greatest vibraphonist, or at least very close. I got "At the Kosei Nenkin".



5. Eels - Oh What a Beautiful Morning. I haven't listened to this one yet. I haven't heard any Eels albums since Beautiful Freak, which I fell in love with, and only a few random songs between then and now. It appears they have put out about 7 albums behind my back.



Branch Management, Development, and Releasage


I just came up with a new development/release process for a particular product at work. It's specifically aimed at a product that has only one live deployment and one test deployment (a web app we developed for a customer). So far, deployment has been a pretty big pain because the customer will have us implement a feature, and we'll finish the feature to the point of being Bug Free(TM) and merge it into trunk, but then when it comes time to deploy, the customer will tell us to deploy feature A and B but not *this* feature (for various reasons outside the scope of this post :). So far this has been done by updating the live code to the latest version and then commenting out individual bits with new features. So far, this has been tedious and error-prone, so I've been trying to think of a better way.



This is what I'm going to start trying to do:



In SVN, we will have "trunk" and "deployment". All development is done in individual, short-lived branches (which we've done to some degree so far, and I have seen others do with fairly good results). When we want to put it on the testing machine, we merge to trunk. When we want to put it on the live site, a well-defined deployment-manager merges the branch with the deployment tree (important to note is that the changes _don't_ come from trunk, but from the individual branches).



This way, when we need to deploy feature A and B but not C, DeploymentManager simply merges A and B and restarts the server.



This is all fine and dandy and, assuming that 100%-branch-development works, doesn't appear to have any flaws (apart from having a fairly high overhead, but that's OK for our situation).



One thing I'm still worried about is the 100%-branch-development methodology, though. I can see the following situation arising occasionally:



A new feature is developed in branch A, but that feature requires some new framework-features as well (or a refactoring, or just a new utility function), so the new framework-feature is committed to branch A. Another developer starts branch B before that first branch is merged. The second developer decides that Branch B would benefit from the framework-feature in branch A. What does he do?



* Simply wait for branch A. Hopefully it will be merged soon enough, and branch B can be copied from trunk after that merge.

* Developer A can be asked to merge his framework-feature into trunk but keep his user-feature in the branch. This would be tedious and be pretty high-overhead, but I suppose it's acceptable if it's urgent enough or branch A's feature keeps having its requirements changed.



Other ideas, like merging branch A to branch B, or branching B *from* A, somewhat conflict with the merging process laid out for trunk/deployment.



Anyway, that was nice, long, and boring. I'm going to just run with this idea for a few weeks and see how things go. Maybe I won't run into any of the nasty situations that I'm thinking of, or they'll be so rare that they're not too much of a pain to work around. If anyone has any thoughts about the second half of this post, I'd love to hear them.



Now, I need to get around to writing that bloody OSDC proposal.



Law is forever the champion