The Seven Secrets of Successful Programmers article was on reddit today. I found it to be simplistic enough to be inane. Also not particularly good advice in all parts. For example, the article says that "[m]ost compilers will strip the comments from the executable program". Strictly speakig this is true: there is probably one or two compilers out there that retain comments in the binary code they put out. They're so rare, though, that it is quite utterly pointless to say anything about it. Anyone who needs to be told that comments don't impact performance or executable code size needs a course in basic programming, not secrets about being successful. "A good indication that you have got the level of comment right: could someone understand what your program does if all but the comments were removed?" I disagree with this: better advice would be "could someone understand the code if you remove all the comments?" It's the code that gets executed and so it is the code that should be used to communicate and not comments, except when code can't be made clear enough. For example: if you write a wrapper around malloc to check that it succeeds, a comment explaining why it is acceptable to just kill the application on failure would be good, and very hard to express with code. "In particular any code branch (an IF..THEN...ELSE construction) and any code repetition (a WHILE...END WHILE construction) should be indented so that it is easy to see where they start and end." Gee, that surely is a big secret that only successful programmers know about. "Expect the unexpected and deal with it. Before you open a file, make sure that the file is present." That's not a good way to deal with it. It's a race condition just waiting to blow in your face. The correct way is to attempt opening a file and then deal with an error if it failed. "Name your variables to aid readability. - - - The key is to be consistent and to be as informative as possible." Packing as much information as possible into a variable name can be a hindrance to readability. Too many people read advice like this given in well-meaning but misguided articles and then go on to name loop variables nElementIndex. The loop gets more readable if you name your loop variable just plain i. The loop variable is not significant enough to warrant all the attention from a reader that a long name requires. A short name in this context makes it much faster and easier to glance at the loop and see what it is doing. Obviously names with scopes longer than a (fairly short) loop need to be more descriptive. Here's my seven secrets of being a successful programmer.

1. Learn to worship the goddess of simplicity. KISS a lot. This is much harder than it seems: it's more difficult to be simple and good than to be complicated and adequate. Simplicity starts with the specification of the program or system, and needs to permeate the design, and the implementation, at every step.
2. Pick good tools, and learn them well. You need to know many tools, and know them well, or you'll waste time on doing unecessary things. Tools include software programs, books, algorithms, data structures, and mental models. Learn editors, programming languages, Unix command line tools, and so on. Learn at least three different paradigms for programming.
3. Learn how to learn and keep on learning. New stuff is invented daily, and you need to keep up with it, or you'll end up as useless as a COBOL programmer doing a web shop.
4. Develop debugging muscles. This is perhaps the hardest thing to learn, since no-body seems to be teaching it. You'll be spending most of your time doing it.
5. Learn how to do testing well. Unit tests, test driven development, black-box testing, integration testing, regression testing, test automation, ... There's lots of ways of reducing the likelyhood that code escapes your hands with bugs still in it. It will inevitably happen, but if you know what you do, you can be better than most everyone else. The industry standard for commercial, proprietary code seems to be around 20 to 30 bugs per thousand lines of code; the Linux kernel has less than 1, and is known as a cesspool of bug-infested muck, so surely you can do better?
6. Learn to write prose well. Then write a lot. If you can't write a README, a manual page, or the specification for your next work project, who's going to know about your great programming?
7. Oh, you need to learn how to program well as well, and that isn't so easy either. Knowing how to program well merely isn't enough to be a successful programmer.

Yeah, I did some local mail-server “tweaking” this past weekend and, uh, broke my smtp mail in process, apparently. So while I’ve been getting mail just fine, mails that I’ve sent have quietly turned into an oblivion of lost bits. All the while, I’ve been cursing people for ignoring me when I send them mails. I’m sure the opposite is true, however. So if you’ve sent me something expecting a reply in the past couple days, hold onto your horses as I re-send things…

It’s official: I’ve joined the Free Standards Group as Chief Technology Officer and chair of the FSG’s Linux Standard Base (LSB) workgroup. (The FSG made some great additions to its board too.) This promises to be a breakout year for the LSB and for free standards in general, and I’m excited to be a part of it. Some of the things on tap for the coming year are:

• The LSB 3.1 release (which adds Desktop functionality to the ISO standard LSB Core, among other things)
• A crisp, well defined roadmap for LSB 4.0 and beyond, with increased emphasis on synchronicity with the major distros and stability, predictability and consistency of the LSB ABIs/APIs over time
• A renewed emphasis on increasing direct involvement of distros, ISVs, and upstreams in the LSB development process
• A developer outreach program that will make it easier than ever for software developers to target the Linux platform in a portable way (hint: ever wish there was a Linux Developer Network?)
• A franchised certification program that will allow third parties to integrate LSB certification into their own value-added certification offerings (our recent announcement that we’ve teamed up on a certification center in China is a hint of things to come here)

As with most major life changes, this one’s bittersweet in some ways, as in the process of embracing this exciting project, I’ve had to step away from another, namely Progeny, the company I co-founded way back in 1999 (!). It’s always hard to move on from something that’s been a big part of your life for such a long time, and it’s particularly hard when you don’t feel like you’re “done” yet. On the positive side, I leave Progeny in excellent hands, and I’m able to remain involved in that wonderful position called “advisor”. Speaking of Progeny, I’m exceedingly proud of all we accomplished over the years. Not only did we survive the .com bust, but we successfully reinvented ourselves in the midst of it all. Furthermore, we not only survived, we pioneered: we were among the first (if not the first) to build a business model around the customization and integration of open source code, a model that’s been adopted by some of the hottest open source startups of the past few years. I’m also immensely proud of the DCC Alliance—indeed, my new role with the FSG is, in a lot of ways, a natural progression from that latest waypoint in a string of projects that date back to 1993. That’s it for now. Watch this space for additional news about the LSB as it continues to unfold. Better yet, get involved and help make it all happen!

I’m in Korea. Lots to do:

• Figure out how to get Korean “Hangul” characters to show up in X
• Figure out how to change my date/time to Korean
• Get my locale setup for Korea
• Figure out how to input Hangul characters

I have Internet at home at long last. (I couldn’t get Internet in Australia without signing up for an annual contract!) 200kb/sec to Dreamhost. I also seem to have my own IP without a firewall. I’ll have to cook something up with iptables quickly. I am looking forward to going to Seoul’s “Electronic Market” and getting some bits and pieces. One of those new Seagate hard drives for my laptop I’m hoping. Perhaps an MP3 player too. Btw, upgraded to Wordpress 2.0. Notice any problems? Let me know…

Long time no blog I guess. Things haven't been that exciting on the Debian front for me. Many of you may have noticed the Xorg -8 packages just hit unstable, complete with minor annoying debconf bug (fixed in svn now). That work was almost all packaging bugs, most of which are now taken care of. All those changes apply to the 6.9 packages too, so it's like I'm getting a two for one. This means that the 6.9 packages will be pretty well cleaned up on the Debian side of things when they actually ship. Thanks to Sven Luther, Julien Cristau, and Ari Pollak we can build 6.9 for powerpc, sparc, and amd64 (although there's currently an unrelated bug on amd64 stopping us from building any X packages there). Hopefully we can get the remainder of the arches ready to go so that we can drop 6.9 in to unstable as soon after it's released as possible.

One of the very cool changes that's come about lately is that David Mart nez Moreno has taken up the torch for xterm and produced a package for experimental. xterm never really lived at X.Org, and now we're getting it from the real upstream source. So thanks to David we'll have an up to date xterm ready to go with 6.9. It's sort of a little taste of the modular tree: if you need to get an xterm update for some reason, then you don't have to update all of X in the process.

Terrifyingly, I've reached a point where I can start working on the modular packages the moment I sit down to do Debian work next time. I'm going to repeat what I did with 6.8 and start with the Ubuntu packages and work from there. Now that I know a little more about how the whole thing is laid out I feel a lot more confident in what I'm doing. Last time it was really by the seat of my pants. The scariest thing for me is that I finally have to break down and learn the autotools, which is something I've managed to avoid until now. That should be the biggest hurdle for me in moving the modular packages forward. I have no idea how long it'll take, although history has shown that my time estimates are about 1/3 of the time that it actually takes to do a thing :-) The first third of what I set out to do (get Xorg in to Debian) is finished. The second third will be when 6.9 is in testing. The final third is when the modular packages that I'm happy with land in testing. It may take the entire etch release cycle to run this marathon, but I feel like I've reached the halfway point around now, with 6.9 stabilizing.

I've started talking with people about where to go after all that. Once the Debian packaging work is done, I want to start working on the Xorg codebase itself, preferrably on making the xserver a little nicer on the user. I have a project or two in mind, but I don't want to start on them until Debian's X packages are well in hand for the forseeable future.

I didn't make it in time for dinstall today, but I uploaded xorg-6.8.2.dfsg.1-6 to unstable a few minutes ago. Most of the fixes aren't that exciting to the average user, but we did clear out a few developer-related bugs that are holding Xorg out of testing. The big thing is that David Mart nez Moreno kicked some serious ass and not only fixed a lot of those RC bugs, but he even backported the savage driver from CVS HEAD! So savage users, you've now got the latest stuff around.

Meanwhile I've been whittling away at 6.9rc0. I've finally managed to produce packages and run the thing, so the majority of it is good to go. Once I got the basic build issues worked out, Michel D nzer suggested that we switch the way our xserver-xorg-dbg package was built. In the past, the code that loads the individual drivers and other modules in to the X server was a source of serious problems, and because of that the debugging server was built entirely staticly linked, with every driver and module built in to the thing no matter what video card you had. For 6.9 the default loader has been switched to a much better one, so Michel suggested we make a more normal -dbg package. This sounded like a good idea to me, so I spent a few days working that out, and it seems to be finished. There are 100 files that I was able to remove from the debian packaging dir (a lot less to keep track of!) and the -dbg packages for all the libraries in addition to the xserver have shrunk considerably. As such, these packages should take up less space on your hard drive, should you ever need to install them.

With that out of the way, we have a few more things before I can actually upload 6.9rc0 to experimental. Upstream has split out xterm and we'll be doing the same. xterm has lived at Thomas Dickey's website for a long time now, and we're finally going to start using that as our primary upstream for the program. David Mart nez Moreno has volunteered to take this on, and he already has the work done, it's just waiting for an svn repo creation. I also need to update both the render and xrender packages in experimental, since Xorg requires both to build. Once these things are done, 6.9rc0 will hit experimental, hopefully beating rc1 out of the gate. From there, some basic tuning on 6.9 will be ongoing while we work on getting the 7.0 packages moving. Things are happening, and while they might not be as fast as I'd hoped, I'm pretty happy with how they're progressing.

After seeing everyone shill for their favorite scm lately, with most of the predictable ones getting the attention, I thought I'd throw my choice out there, just to see it represented.

I primarily use svn with my work on X in Debian, and it's a wonderful system. Fortunately though, I don't have to maintain the repos, and when something goes wrong I can cry to our beloved DPL to get his admin on, and he fixes things up. This works out fairly well for me as a basic user, but I don't want to be dealing with these sorts of hassles for smaller projects. The distributed scm thing appealed to me in this sense, so when arch started to become a serious buzzword in the Debian crowd I had a look.

Well, more than a look. I fought for over a month with tla and baz and found that they were both so unuseable and poorly documented that I couldn't do more than scream and cry. bzr looked cool, but it wasn't ready (I sorta tried to manage one of the X.Org releases in Debian with it and failed miserably). Darcs was slow and in a minority language, which was a major turnoff for me. And I don't have a ton of diskspace, so git was out. Svk struck me as a hack (it still does) so I didn't want to go with that. Monotone was ok, but not good enough, so I sighed, gave up, and went back to svn thinking that this was as good as it could get. Indeed, we added a quilt-based patch system to the Xorg packages, so now I have a mini-scm (quilt) inside an scm (svn) and it works amazingly well.

But one of my friends just got hired by the people who make Xen, and he mentioned that they used mercurial, and asked if I had tried it yet. I scoffed and said no, and that all scm's suck harder than anything has ever sucked before, but I had a lot of time to kill while I was waiting on an X build, so I gave it a look.

Mama, I'm home. I was stunned that I was able to pick up mercurial in about half an hour after tearing my hair out for over a month with arch.

The UI is apparently very darcs-like (by accident, according to the mercurial author) which is known to be fantastic. Branching, merging, etc is simple as can be so far, although upstream is still working out better methods to deal with merging.

It's very fast, built for large trees (i.e. the kernel) so it will be suitable for managing X with (although I haven't tried this yet, but I plan to). For X, I'll need something fast to keep my sanity. This rules out darcs and baz (which has somehow managed to get amazingly slow in addition to being difficult as of late).

Unlike git, it keeps changesets in xdelta format rather than storing whole files, so it doesn't eat my hard drive.

It's written in python, so it's something I could hack on if I want to.

It supports an easy server setup with apache, and you can push your repos and serve them via static http if you don't have a server, like me.

Like monotone, it exposes hashes to the user, but unlike monotone it also provides a local revision number to make sure you don't spend all your time copying and pasting hashes, which is what put me off from monotone.

It has a fairly small command set, with 39 commands in the current tip (i.e. HEAD) as opposed to the > 150 in baz which made me weep.

It feels like using bzr, except it's here now and ready for production. Indeed, it's already used in production in making Xen.

There's a bunch more that I won't talk about, mainly because these are the things that have grabbed me. A note of caution is that I've only been hacking on local projects by myself (mainly configure-debian) with it, so I don't have the tons of real world experience with multiple trees that the thing is built for yet. I'm thinking about putting up a parallel mercurial tree to the XSF tree just for fun (the svn repo would remain the canonical one) if people are interested and I can find a server. I hope though, that all the people out there who, like me, were bouncing around trying out scm after scm and never being quite happy with any of them at least give mercurial a fair chance. I'm still amazed at how much I like it, and I think some others might feel the same.

I wish I could say that the subject says it all, but that's not quite true.

First off: it's true that X.Org has been uploaded to unstable. Steve Langasek talked with the gcc maintainers and they decided that X.Org wouldn't block gcc4, so I got the approval to upload. Steve, as ever, is awesome.

Then Daniel Stone noticed that the packages are missing updated MANIFEST files for many of the ports. These files were put in place in the X build system long ago so as to manage to complexity of new upstream revisions. Because there's just so much stuff in the X source tree, there had to be an automated way to deal with making sure everything was present and accounted for. The end result of this is that if a MANIFEST that we have doesn't match up with the one generated while building the package, the build will fail. So what's going to happen is that with this upload, some architectures will get the X.Org packages, and others will not due to build failures. I uploaded i386 packages, so that will definitely go through right away, and ppc, sparc, amd64, and I believe mips should all go through as well.

The reason we went with this plan is that when the builds fail, the build logs will give us a diff for the MANIFEST for each arch. So what I can do is use those to fix the MANIFEST files tomorrow, rebuild as fast as my laptop can manage, and upload the -2 revision which has correct MANIFEST files. Steve, Daniel, and Ryan Murray all directed me in deciding on this plan, and I owe them a ton for all their help.

Already we've hit a build error in s390 that we're working through, but hopefully we can get all the ports in line ASAP so that this can transition to etch. But here it is. After a long wait and lots of work by lots of people, X.Org is finally entering Debian.

I think I need a glass of scotch.

My keyboard has been getting progressively more awkward to type on, especially the A key (used extensively for screen). I had a spare, so I swapped it in today. Except it didn't feel right. My old keyboard was a Dell that's about 15 years old now; I think I picked it up for about £3 from Bull Electrical. The new one was an el cheapo eBuyer. So I decided to give the Dell another chance, and set about dismantling it. Very mucky. I shoved all the keys in the washing up bowl and dusted the rest of the mechanism as best I could. A few hours later, the keys are dry and the keyboard is back in action. I think I'll need to do some investigating of a better spare however.

I wonder how often things like this (“Dear Sir, calling StarForce ‘Anti-copying malware’ is a good enough cause to press charges and that is what our corporate lawyer is busy doing right now”) actually have their desired effect. I suppose it might work in cases where the recipient is actually dumber than the writer. On the plus side, that sort of letter could certainly create declaratory judgment jurisdiction; the recipient could turn around and sue the sender for a declaration that they have done nothing unlawful. I also wonder whether companies like StarForce actually have a “corporate lawyer,” and if that person is aware of these emails. I sure hope not. Update: Apparently this story has been slashdotted. I try not to post about things that also appear on slashdot, on the theory that most people will have seen the story somewhere else at that point, but this entry went up before the slashdot article. A commenter makes a good point, though, that Cory Doctorow (the recipient of the abovementioned threat) is Canadian and lives in London—something the writer of the threat seems to have no clue about.

Many have tried to solve spam problem, even Micrsoft (with a quite strange solution ;-), but except personal solutions like well working and well-kept spam filters, no well-working general technical solution has been found yet. Although I really would like to see a technical solution and often think about this problem, I currently believe that this primarily is a social problem which cannot be solved solely with technic. UserFriendly’s Erwin seems to see it the same way and proposed today a quite drastical solution. There are good ideas out there (e.g. SPF, RBL, Greylisting and Teergrubing), but all seem to have their problems, too. Especially RBL often have administrative problems, i.e. if an entry is justified or not. Greylisting simply can be bypassed by being SMTP conform and trying again, so it’s usefulness will decrease permanently. And against Lutz Donnerhacke’s teergrubing, spammers seem to have found workarounds quite quickly. Haven’t heard much about it in the last years. (I just can’t remember what the drawback of SPF was.) For myself I’ve solved the spam problem with a learning SpamAssassin and sorting mail by spam-level into several mailboxes. The higher the spam-level of such an inbox, the more seldom I look into it. Works fine. For me. No general solution though, since the SpamAssassin needs to be fed with fresh spam regularly.

In a little while I’ll be packing my things: clothes (with a few formal attires), a couple of (C/data structures) books, some snacks (Nerds!) and spare change (no bills). I’ve yet to see all of them fit in my backpack, so I’ll probably bring a couple of bags. Tomorrow, I will be bound for Manila yet again, much earlier than usual, for the AsiaBusinessTour on Thursday. And on the 16th, there will be the Bicol Open Source Forum in Legazpi City. Joseph Davidton Cadag invited me to be a speaker; I’ve yet to accept, but I’m leaning to it, especially since this would be a great opportunity to speak more about FOSS to my fellow Bikolanos. Also, its a nice time to meet up with Irvin Piraman who will be giving some Ubuntu CDs in the Forum too. I just hope I can finish my (re)packaging of ecb which I ITA‘d since last August. There is a package of the new upstream version already, but there seems to be a lack of Debian sponsors who can look into Emacs-related packages. sigh

Beagle 0.2.1 is out. Beagle is a very useful desktop search engine for GNOME (but you can use it with KDE, too, or even without any desktop environment like I do). Despite the low version number it is already quite stable and usable, and has lots of features. It can index all kinds of files and information on your computer (txt, pdf, doc, emails, IM logs, IRC logs, source code, images, music, and whatnot) and provides a very nice (new) search interface (see screenshot). Yes, Google Desktop Search and Spotlight do the same thing, but neither is available for Linux, and neither of them is Free Software. They can "phone home" without telling you and do other funny things. With Beagle you can easily check what it does (use the source, Luke!). Oh, and Beagle can now also parse Ruby files, a simple filter I had written and submitted has been included in the latest release (well, actually it was there in 0.2.0 already, but I didn't tell anybody ;-)).

I finally got out to Barnes and Noble today to spend the last of my Christmas/birthday gift certificates. Bought the last two books in Robin Hobb’s Farseer Trilogy as I have the first book but haven’t read it yet, as well as the third book in Robert Jordan’s Wheel of Time series. Incidentally, I was told by a friend that it’s only worth reading the first three books of the Wheel of Time, as it goes on forever and ever with little development. Please correct me if I’m wrong. I was tempted to buy The Atlas of Middle-earth but was swayed by my OCD at having unfinishes series (what on earth is the plural of that word? serieses? I want to say it doesn’t change, but that sounds funny) in my bookshelf. I’m still not sure when I’m actually going to read all these books, but, uh, I’ll figure that out eventually.

This morning before work I hacked up a few Pyblosxom plugins to do word blacklisting and a basic Turing test on comment posters. The blacklist currently only contains 'phentermine', 'poker', 'xanax', and 'viagra', but that should filter out 90% of the comment spam. For the rest, the Turing test asks the poster to add together two small numbers. The lazy bit is that these numbers are hard-coded at the moment, I'll add that later... Hopefully I haven't broken something and if people pass these tests then comments actually work, if not the please email me. I'll release the plugins later this week when I've added documentation and ensured they work. NP: In Between Dreams, Jack Johnson

Everyone would like to be more interesting. While this seems like a broad statement which can't possibly be true for all people, I am confident that it is true for most. Even if you aren't a person who is driven by social interaction, if asked "would you like to lead a more interesting life?" most people would answer with a yes (ninjas and pirates need not apply, I think). There are very easy ways to make your life more interesting - you can volunteer somewhere, change your habits, or go out and party all the time. Unfortunately, some of these things aren't interesting to you, and they may be downright boring. So an ideal way to make your life more interesting would catch not only other people's interests, but yours as well, raising the whole world's interest level. The device today which garners the most attention is, arguably, the TV. It sits ensconced in the middle of almost every living room in America. We watch TV so much that there's a considerable market for devices which make it easier to watch, either by time shifting or space shifting . If we're guaging the interest of people just by what gets the most eyeballs, the TV wins hands down. So if you want to be more interesting, and whatever's on the TV is the most interesting thing around, it stands to reason that you should emulate what you're watching. I'm not saying you bust into a hospital and start performing surgery just because you like ER, or start having saucy affairs with the other families on your own personal wysteria lane, but people can make small decisions which make things more interesting. This is all a long-winded and round-about way of coming to my point, however. In most TV shows, the TV plays a very small role, if any at all. How many times do you ever see a TV screen on a sitcom? Almost never. They are always off screen, obviously not interesting enough to put on camera. There's no "watching the tube" show, in which everyone watches the TV. It's because that's boring. This suggests that if people want to be more interesting, they should just reduce the amount of TV watching they do. In most shows on the tube, the only reason they watch TV is because of some specific purpose relating to the other, non-TV-watching. things which they are doing. Also there are very few if any big screen TVs on TV - I would bet someone that I've never seen even a 35 inch screen ever on TV. Smaller TVs and a minimal amount of TV watching make for more interesting lives.