Indexing Google's Source Code

I couldn't talk about this before, but now that Wired magazine has disclosed the size of Google's code base (2 billion lines), I can discuss my authorship of gtags and what it did for Google, as well as some funny stories arising from that.

I wrote the first version of gtags in 1991 (yes, gtags is older than Google!), when I was at Geoworks. GEOS was several million lines of assembly, including every freaking app written for that OS. Since every object could potentially call any other object, the entire code base was relevant. Needing to get my head around that code base, I tried to build a TAGS database and that immediately caused my Emacs to start swapping. The performance was unacceptable.

The core insight was this: there's no reason to use a disk based search on a TAGS database. Stick the entire database into RAM, and use a hash-table to lookup your keywords, and search performance would go from multiple seconds (half a minute in some cases) to sub-second response time. So one weekend I coded up the hash-table, wrote code to load up a TAGS database into memory, and implemented a simple UI that let me browse code in Emacs. Soon, I enjoyed sub-second search times and could grok code that would have been impossible to do any other way.

If I ever needed validation that the tool-building approach to coping with large-scale software was the right approach, this was it. Once the senior engineers (remember, I was an intern at Geoworks then) got hold of the tool, I saw even loyal-vi users switch over to Emacs just to get their hands on the code browsing functionality (going from half a minute per search to sub-seconds was critical).

After I left Geoworks, most of my code was in C, C++, or other high level languages. Computers got so fast, and IDEs so sophisticated that I never dealt with a code base that couldn't be loaded into the IDE. It seemed to me that the need for such functionality had been obviated by ever more powerful machines.

That was, until I joined Google in 2003. By then, Google's code based was already approaching 1 billion lines, but in multiple languages. I needed to wrap my head around that code base in a hurry. Various teams were using random tricks to subset Google's code base into their IDEs, which I thought was a kludgy and unsatisfactory way to work. So in my 20% time, I rewrote my old tool using Google infrastructure (thanks to Craig Silverstein, who was the only person who believed in my code enough to waste precious time code reviewing it --- even then he was skeptical that my tool would be widely used or even substantially useful, given the huge amount of effort people had put into subsetting the codebase). I coded up the UI again in Emacs Lisp. I actually had to put some effort into the UI this time, given that C++ (and Java) overloading meant you had multiple search results for any given search term. Thankfully, Arthur Gleckler came in to lend a hand. Reading Arthur's Lisp code was like reading poetry: you can't believe the succinctness and elegance that can be expressed in so little space. It's worth your time to learn Emacs Lisp just so you can read Arthur's code.

Just as I expected, gtags took off in a huge way inside Google's engineering team. (By the time I left, 2500 daily active users was the metric, or about 25% of Google's engineering workforce. The internal tools team did a survey once and discovered that nearly every engineering workstation had a copy of Stephen Chen's gtags-mixer running on it) There wasn't a whole scale conversion from vi to Emacs though: Laurence Gonsalves stepped in and wrote a vim script that emulated the Emacs code. I don't even remember how I managed to do the code review for that checkin, but anything to help gtags, so I must have just gritted my teeth and done the code review or asked Laurence to find someone competent to review it.

But I wasn't nearly even close to done. Because of the huge amount of ambiguity and overloading involved in C++ and Java, I wanted gtags to do a better job of ranking the results of any given search. Phil Sung took a first crack at it, introducing Sung-ranking and later on, an include-rank that mirrored page-rank, except for code. Stephen Chen solved the problem of how to intermix protocol buffer files into the search results. Matei Zaharia (now a professor at MIT) spent a summer integrating a parser into the indexer for gtags, so that it was no longer a dumb lexical scanner but a full-on type-comprehension system for both C++ and Java. He also designed and implemented incremental indexing on Google's code base, no mean feat. Leandro Groisman and Nigel D'Souza both also made major contributions to gtags.

For several years, I had the entire Google source repository downloaded and checked out on a dedicated gtags indexing machine sitting under my desk. It was a standard underpowered workstation of that era: dual core, 2GB of RAM, and 500GB of disk: it had a special p4 client that eliminated the need to download any binary assets, since it was only interested in code! It was probably a major security hole, but I figured since Bill Coughran knew about it, I wasn't violating any corporate policies.

This illustrates a very important point: 2 billion lines of code sounds like a lot of code, but if you do the math (assuming 50 characters per line) you'll get only about 100GB of data (uncompressed). After dropping comments, white space, and lines that don't perform any declarations, your index is going to be pretty tiny, and you need to split that code base into several corpora (C++, Java, protocol buffer declarations, python), so each individual server could easily handle its entire corpus in RAM without any fancy sharding. Too many people get caught up in trying to apply fancy Google techniques required to manage terabytes of data when they're dealing with tiny amounts of data that fit into RAM and can be managed by traditional programming techniques.

In any case, gtags was a very hardware light project: it never took more than one machine to index all of Google's code base (and we never had to apply any fancy MapReduce techniques), nor did the serving cluster ever exceed more than about 10 machines. We came close to maxing out the RAM available on 32-bit machines for a while, but between Phil's string table optimization reducing memory use by 75% and the switch to a 64-bit architecture we never ever had to split indexes for any given language (there was a server for each language) across multiple servers. Those servers were under-utilized of course (they could probably have served 25,000 or 250,000 users at once), but on the flip side, you always got sub 10ms response times out of gtags. We switched from dedicated gtags server desktops sitting under people's desks to Google's cloud internally fairly early on, with Ken Ashcraft doing much of the work of converting gtags into a borg-ready service.

This came to a head when Google added the China office sometime in 2005 or so. After that, the powers that be decided that high intellectual property (HIP) code needed special permissions to access. Since I wasn't HIP enough, I simply stopped indexing that code. This burdened the HIP people so much that eventually some of them (including Sandor Dornbush) contributed to gtags. A HIP guy would take on the burden of downloading HIP code and indexing it using our indexer, and then put up the gtags server with that code behind a HIP firewall. The gtags-mixer would then be configured to talk to the HIP server and mix-in the result if you were HIP enough.

One of my prouder moments at Google was when Rob "Commander" Pike came to me and asked me how gtags worked. It turned out that he didn't want to talk to the gtags mixer or the gtags server, but just wanted his programming environment/editor to directly grok the output of the indexer. I was happy to give him access to the index for him to do whatever he wanted with it. I forget the mechanism by which this happened: he might have simply scp'd the index over to his machine, or I might have had the indexer push the index to his machine whenever it was done. This was great, because Rob became one of the folks who would notice whenever the indexer was broken because the file wouldn't get updated!

In any case, as with many things at Google, after I left gtags got replaced by some cloud solution that took way more resources than me, Arthur, and a bunch of interns, and I'm sure everything I wrote has been long retired by now, with the possible exception of the Emacs Lisp front-end.

Even after I left Google, gtags paid me back. Soon after I met my wife, she talked to some of her friends at Google about who she was dating. One of them did a p4 lookup on my changes, and said to her, "Hey wow, this guy has code commited everywhere, even the protocol-compiler." So I guess that worked out as far as a back-door reference check was concerned. (That change in the protocol-compiler was necessitated because I wanted to inject a clue in its output: that clue enabled the gtags indexer to map a generated C++ source file back to its original .proto form --- it was far easier to do that by having the protocol compile emit the clue than to try to guess --- it was a trivial change and Sanjay approved it in seconds)

If it seemed unbelievable to you that during that period of time I had such an illustrious group of people on a tiny 20% project, it should be. But I maintain that the test of a high quality engineering organization is whether or not that organization is able and willing to invest time, money, and effort into building tools that enable that organization to move faster and produce higher quality code. Google met that test and passed with flying colors.

Review: Robot Turtles

I was a kickstarter backer of the Robot Turtles board game way back when. I did it mostly to support a Googler, but also partly because the kickstarter promised to teach my toddler how to program. My understanding of toddler hood is that it's somewhere between 1 and 3. I'm guessing that Dan Shapiro's toddlers must have been very advanced,  because even at 2 years of age, Bowen didn't want to do much with the board game except spew the counters all over the floor. I gave up and put it away.

At age 3.5, Bowen now understands the concepts of games, and taking turns. The second time I presented it to him, he finally understood the game, and the idea that playing cards lets you move turtles. He also understands the goal is to move the turtles to a jewel. It took him a while to figure out that the turn left, turn right, and straight ahead cards are turtle-relative, rather than him relative. And he delights in crying out "BUG!".

In just a few days, he's gone from being challenged in getting the turtle to its destination on an empty board, to being able to negotiate a maze, deal with moving crates, and lasering ice walls. I don't go a day without him asking to play Robot Turtles with me, and he loves screaming "BUG!" to reverse a bad move.

I haven't managed to get him into the planning stage of the game, where you play 3 moves at once, and of course, that's necessary in order to get to the part of the game where you build subroutines. But given the amount of play Bowen's gotten out of it, suffice to say that it's been worth the $25 kickstarter price or the current $21 Amazon price.

The nit-picks are that the instructions refer to an online video to teach you how to play the game. That video is non-existent (Shapiro probably got bored trying to make it). It would be nice if the game came with sample mazes, etc. It's not a big deal that such refinements aren't there, but they're so obviously that it's disappointing that they're not.

Nevertheless, the game comes recommended.

Review: Android Studio

Since helping my wife with her Nutrition Tracker App, I'd had a chance to try both Eclipse and Android Studio for android app development. Both of them run on Windows, my preferred platform, but it didn't take 3 days with Eclipse before I got frustrated with frequent crashing, features not working, and a lousy layout tool. I found Android Studio and downloaded it and soon persuaded my wife to switch to it.

Android Studio is based on IntelliJ IDEA. Back at Google when I was doing Java work, I avoided it like the plague, preferring to stick with Emacs and gtags. That's because Google's Java source base was so big you couldn't possibly load it into IntelliJ on the puny workstations of that time (yes, Google only supplied machines with 2GB of RAM in 2003), and even if it had been possible, those machines would have slowed to a crawl under the load of processing that much code. IntelliJ/Eclipse die-hards were resorting to wacko tricks like subsetting Google's code base so it could load into IntelliJ and then writing plugins into gtags for accessing the rest of the source code. I have no idea what Googlers do today, but my suspicion is that things haven't gotten much better.

For small Android projects like Nutrition Tracker, however, an IntelliJ is just about right. If you're unfamiliar with the Android API, it would supply you with method name completion, tell you which arguments to supply in which order, automagically add imports, allow for automatic refactoring tricks such as moving methods, renaming variables safely, and moving inner classes out of their outer classes, shifting classes between packages, etc. The layout tool helps you avoid having to learn the lame layout XML language, so you can actually try to make things work (as opposed to making things look pretty and usable --- I think Emacs is a great UI, so I have no expertise on those topics).

Android Studio is slow. It's slow to startup, it's slow to compile, and it's slow to run the debugger. A typical edit-compile-debug cycle would take around 10-20 seconds in order to build a tiny app. Note that I'm not complaining about Android Studio's massive use of resources while I'm editing. I think that's entirely appropriate. I want all my 4 cores/8 threads to be utilized in order to make my coding experience faster and more pleasant. I don't even mind the startup, since it doesn't need to happen that frequently, and it's a one time cost. But the Gradle build system is not only a resource hog, but it introduces additional latency into my think-time, so I begrudge every second it's spending traversing dependency graphs instead of actually compiling code. I have no idea why the Android Studio engineers chose a clunky system like Gradle, as opposed to rolling their own and integrating it fully into the IDE. I never want to edit the gradle build files manually, but the system forces me to. What's more, the syntax is really obscure and the documentation is inadequate.

For instance, when doing an android release, the documentation only covers Eclipse. Worse, the documentation lies to you. It tells you to modify your Manifest file, and I did. Until I kept scratching my head as to why that never worked. It turned out that you had to modify the Gradle config, since the Android Manifest XML file was ignored in the presence of Android Studio. Well, that took so much googling around that I can't remember what search term I used to uncover the Stack Overflow answer any more.

The source control integration is also funky. It supports Git, Mercury, and Subversion, but not Perforce. Given that Google uses Perforce internally, I surmise that Google's internal projects do not use Android Studio. This does not bode well, since that will mean that Android Studio's most serious problems (build performance) will most likely never get addressed because its non-existent internal customers will not feel the pain.

For quick and dirty Android projects, Android Studio is probably the best there is. If you're serious about building an Android app, however, my suggestion is that you use Emacs and roll your own build system that's decently fast. Otherwise, the benefits from using an IDE will be swamped by inordinately long compile/edit/debug cycle times. Note that though my machine is old, it's still decently powerful compared to even the fastest rig today, let alone the kind of laptops most "hip" developers favor, so it's unlikely you can solve Android Studio's problems by throwing more hardware at it.

Recommended only for non serious Android projects. It's a great tool for getting started quickly though, so use it to bootstrap yourself into doing Android development if that's one of your goals.

Why it now makes sense to build your own PC

I've always been tempted to build my own PC. I'm no stranger to the tools, since my internship at Geoworks effectively required me to take apart and put together the machine I was given at work. But until recently it made no sense. Machines were increasing in performance significantly, so every 2-3 years it made sense to get a new machine. When you're getting new machines that frequently, it doesn't make sense to build your own, since the beige box vendors can get you much lower prices, and the cost of your time to swap motherboards, CPU sockets, etc., in and out would swamp the ability to bring over your hard drives, etc. Given Moore's law, every 2-3 years you'd have to buy all new hardware anyway!

I recently took a look to see if it was worth replacing my 5 year old desktop. To my surprise, the answer was "no." Looking at the CPU benchmarks, it looks like a "modern" i7-4770 would clock in at less than twice the performance of my 5 year old i7-920. In the old days, 5 years would have been enough to get at least a quadrupling of performance. Not even getting a doubling in 5 years would have been unthinkable. Part of it is that Intel's no longer getting any competition from AMD. Part of it is because getting up past about 4GHz would overheat a PC, so the easy way out of just merely increasing clock speed is out. Increasing the number of cores have already hit diminishing returns as far as most PC users are concerned (I'm an exception: I regularly process video).

The flip side of this is that the base operating system hasn't been using more hardware resources recently. Windows 8 is actually less resource hungry than Windows 7, which would have been unthinkable in the old days. Thanks to Microsoft's desire to compete in the tablets space with Apple and Google, Windows 8 actually runs decently on a tablet with just 2GB of RAM. This gave me the courage to replace my wife's 4-year old X201 with a Microsoft Surface Pro with half the RAM. My wife didn't even notice the missing RAM, despite running the resource hungry Android Studio, which is enough to spin my desktop PC's fan up.

This has several implications for users and developers:

1. Rather than buy a mid-range machine and planning to replace it every few years, it might be cheaper to build a high end machine and upgrade components. Given that CPUs and motherboards are no longer going to have to be trashed every few years, you might as well get a chassis that supports easy hard drive and SSD replacements/expansions, and GPU upgrades, if you will run GPU-intensive activities.
2. I/O standards do make a big difference, but any PC with a free slot will let you upgrade to USB 3 and other standards, so again, expand-ability might be more important than "planning to throw it away."
3. An adequately high end machine will probably last a good 10 years in this environment (i.e., a i7 4770k wouldn't be obsolete for 10 years), which means that it makes sense to put money into a high quality power supply, since the higher quality power supply would provide cost savings when you plan to run a machine for that long. This is in contrast to the "buy-and-replace" strategy, where spending $20 more on a better power supply wouldn't pay for itself in power savings.
4. This also seems to be applying to laptops, though laptops do benefit from the power efficiency gains of the latest processors, so if battery life matters to you, an upgrade every 4-5 years might make sense. The way most people seem to use laptops (constantly plugged in and never actually used as a mobile device), I think most people should replace laptops every 10 years, getting new batteries every 3-4 years or so, assuming that their device supports it.

I never thought I'd see the day when PCs would be expected to last as long as cars, but then again, I never thought I'd see the day when Microsoft would roll out huge new products and initiatives and everybody would just yawn. But yeah, my next PC is going to be something I build from the case in, and I'd be planning for it to last a good 10 years, something I did not expect when buying my previous desktop. I would have taken a completely different approach otherwise.

First Impressions: Microsoft Surface Pro

Our trusty X201 had been getting long in the tooth, and Xiaoqin decided to try some Android development. If you've ever tried Android Studio, you'll know that it's a CPU intensive process since it's based on IDEA IntelliJ. The build system associated with Android Studio, Gradle, is also a massive CPU hog, and introduces no small amount of latency to the process. I never thought I'd miss the days of Visual Studio, but it's quite clear that compared to Microsoft's tool set for development, Android is quite a bit behind, and extremely unstable. Of course, in terms of market share, the positions are exactly reversed.

After trying out a Surface Pro in the store a year or so back, I vowed never to buy a conventional laptop again if I could buy a Surface Pro-type device. Fortunately, Microsoft was having a sale on refurbished Surface Pros, so I was able to pick up a 128GB model for $450. You can find them for about $500 if you're willing to put up with a 64GB model. With USB 3 and a microSD card slot, it's probably no big deal if you can't find the 128GB model.

As a laptop, it's quite impressive. It's about 50% faster than the older X201, and 3X faster on boot up, hibernation, and recovery from hibernation, with boot times going from 30s to 10s. And yes, this is with the X201 upgraded to an SSD. There are a few strange fit and finish issues, such as the mini display port slot not being very deep, so when inserting a standard cable there's a little bit of chrome sticking out. The tablet comes with a pen, but there's no place to put it except in the magnetic charging port, and the magnetic charging port isn't strong enough to retain the stylus without loss if there's any pressure whatsoever on it. Since this is an expensive Watcom digitizer stylus, you really do want to keep track of it!

Running Lightroom is fast as you might expect, with no hitches and the Surface Pro had no problem driving the 27" HP monitor with a 2560x1440 display. One nice mode you can run is to have the touch screen run the Start screen, while the big display runs the desktop. This gives you a nice touch UI for the touch part, while having the desktop to do real work. Of course, Microsoft had to glitch this up---in this mode, desktop apps still launch onto the small screen instead of automatically selecting the big screen. It's this kind of inattention to detail that gives Apple its edge over Microsoft, though I've found Macs to have their share of problems when using multiple screens.

The device has a fixed, 4GB of RAM, but surprisingly, until I told Xiaoqin about it, she didn't even notice it didn't have as much RAM as her old device. At least part of the reason is that Windows 8 Pro actually consumes fewer hardware resources that Windows 7 did. The other part of it is that in recent years, software developers just haven't been able to assume more than 4GB of RAM anyway, so as long as you're single tasking or running just one web browser and an application, you're generally OK.

As a tablet, the Surface Pro is quite hefty, though not as hefty as the X201. It makes up for that, however, with power. I'd already written about how much faster the Dell Venue 8 Pro is than my Nexus 7. Using the Surface Pro is instantaneous. The Type Cover is also a joy to use, giving you keyboarding performance akin to what I'm used to with the X201.

The real revelation, however, is the stylus. I'd never tried any of the previous PCs in tablet mode, other than my use of the Wacom Bamboo tablet for producing Independent Cycle Touring. But while I hadn't noticed, Windows' handwriting recognition has become nothing short of amazing. My handwriting can compete with any doctors' for sheer inscrutability, but the Surface Pro handled my cursive with aplomb, as long as I was writing common English words. Write something not in the dictionary, and just like any other machine translation program, and you end up with gibberish. There was no training period, however, and I could pick it up and use it. You could even turn on Chinese handwriting recognition, though Xiaoqin pointed out that Pinyin is faster and much easier to use with a real keyboard. Unfortunately, having multiple languages on the machine is problematic if you use a keyboard, since Microsoft used Windows-Space to switch between languages, and Xiaoqin found it far too easy to hit that combination by mistake. In past versions of windows we tried to change the language key bindings but to no avail, so we gave up and uninstalled the language pack instead.

All tablets are compromises. The Surface Pro does not have great battery life. 3-4 hours with Android Studio and that's it for the battery. When fully powering Android Studio, the device also gets hot enough to turn on its fan, which sounds like a low hissing noise. It's quieter than the X201, but still noticeable if the room is otherwise quiet. Next to my Core i7 920 box going full bore, of course, it might as well not make any noise. At no point would you burn your hand grabbing the Surface Pro, however, so there aren't any safety issues.

Long term, the biggest concern about the Surface Pro is the battery. With the machine running hot, and the battery fully charged most of the time in desktop mode, I would be surprised to see more than 3 hours of battery run time after the first year, and 2 after the second year. Most laptop batteries get abused this way as well, but the Surface Pro has a non user-serviceable battery, with the only option being the $200 power type cover. Fortunately, for the price (which is much less than what I paid for the X201 way back when), we can treat the Surface Pro as a disposable computing device. This is much more of a concern nowadays, however, than it would have been 10 years ago. 10 years ago, you'd expect to replace a machine every 3 years. Now, an adequate machine (which the Surface Pro most definitely is) could have a potential life time of 5-6 years. At the rate Intel is improving (or not improving) CPU performance, I'm likely to keep my desktop for another 2-3 years at least!

There are a few accessories that I would recommend for the Surface Pro. The first is a Type Cover. We tried both the Touch Cover and the Type Cover in the store, and the Type Cover was hands down the winner. Secondly, you need a USB 3.0 hub if you're going to attach a debugging phone as well as a wireless transmitter for wireless keyboard and mouse. The Surface Pro comes with bluetooth, but it was easier to just use the existing Logitech mouse and keyboard than to shop for new ones. USB hubs can be powered or unpowered, and we got an unpowered one for convenience when traveling. It'll make the device drain that much faster, but having one less power adapter to carry will be essential.

In any case, so far, I'm liking the Surface Pro far more than I expect, and Xiaoqin hasn't asked for the older X201 back. I'm expecting not to send this back to Microsoft after the 30 day return period.

Internships

The conventional wisdom on interns is that you cannot expect to get significant work done by interns: they take time to train, and by the time they leave your company, you can't possibly have trained them to the point where they're productive and pay for themselves in terms of work done.

I've led internship programs at Mpath and Google, and each time I've defied conventional wisdom. Mike Danylchuk, Alex Murkes and Carolynne Surfleet all interned for me at Mpath, and they did tremendous amounts of work. Both Alex and Mike converted to become full time employees, and were immensely productive.

At Google, Stephen Chen, Phil Sung, Matei Zaharia, and Nikola Postolov all interned for me at Google. All 4 were immensely productive, and Stephen and Phil eventually became Google employees. All these engineers made huge contributions to their projects, and more than paid for their training time.

I attribute my past successes at hiring interns and managing them to two factors:

1. I don't lower my standards when hiring interns. I interview and apply the same metrics to interns as I do to full time employees. You can do this if you focus on fundamental computer science and coding problems during your interviews.
2. I don't give interns "make work" or insignificant work. I put them on high risk projects with complete ownership of a project from end-to-end. They do the design, they code, they test, and they deploy. The sense of ownership and satisfaction with the end result gives them a hugely positive experience. This doesn't mean I just let them do their thing --- I provide design reviews and code reviews, and I provide suggestions as to which projects would be good uses of their time and talents, but providing autonomy is the key to engineering happiness.

I used to think that this modus operandi was par for the course in the tech industry, but one day I sat on a hiring committee for interns who wanted to convert into full-time employees. My jaw dropped constantly in horror at what some of my colleagues were doing to their interns:

• Putting interns on demoware, code that effectively would have to be thrown away if the data input ever had to change.
• Having interns pair program with each other, relieving the mentor of the need to code review or provide feedback to the interns. Unfortunately, this also meant the intern supervisor had no clue how his interns were doing, and whether they would be a worthy hire.
• Writing glowing reviews for an intern who did very little or next to no work (had no checkins into the source control system).

Well, here at Quark Games, we're kicking off our summer internship program next week with visits to both the Berkeley and Stanford Career fairs (we'll also consider full time applicants). I guarantee we won't' do any of the crazy things described above, and my aim is to have fully productive interns all summer. While we're only visiting these two schools because they're easily within driving distance, we'll accept applicants from any school. Feel free to send me e-mail or apply through Quark Game's site if you're interested.

Casual Programming in Windows

The EEE PC makes a perfect nightstand computer, a more fully functional Chumby, if you will. Lisa wanted an alarm clock application. Here are her requirements:

• "Gentle wake". Slowly increasing volume until she wakes up.
  
• Music player --- plays any MP3 in our collection (stored on our RAID NAS server)
  

One would think that someone has already written an alarm clock application for Windows already, but none of the ones we tried had "Gentle wake", and one of them simply crashed. What crappy software.

Well, I program computers for a living, so I started working on one a couple of nights ago. It had been 4 years since I programmed windows, but since this isn't a full-featured application, I could take short cuts I'd never do professionally. For casual programming, one of the best languages around is Python. The python port to windows is robust and small, and even more important, there's a windows layer readily available. Of course, using the raw windows API to decode MP3s is a pain, so I searched for a python media library and got pointed to Pymedia, which astonishingly came with an example to decode an MP3 and play it.

I dug around for a volume control API for windows, found it, and hooked up the whole thing, and then I was done. The code is only 126 lines. Of course, there were weird things along the way, like finding a version of pymedia compatible with Python 2.5, so I had to uninstall and reinstall various different versions of Python and pymedia, but all in all it was pretty painless --- programming by googling for code snippets you want and then copy and pasting and debugging is pretty easy.

Of course, I didn't even attempt the time consuming stuff, such as putting in a fancy GUI or even having a UI at all. I start my alarm clock by typing ".\alarmwaveout.py 22:30". I'm a software engineer, so command-lines feel easier to use than GUIs anyway. If you could talk to a computer, you'd want to say, "Wake me up at 7:30am", and clicking around on spin controls and clicking check boxes just doesn't feel natural compared to that, while the command-line would seem to be quite a bit closer. There are no snooze features, and you hit control-C to stop the music. Hey, the goal is to get you to wake up.

All this ease of programming reminds me, however, that this is why there are many people who think that they are great software engineers just because they can program a computer to do stuff. Being able to code a simple application like this in no way qualifies you to be a software engineer, and unfortunately, all too often I interview candidates who are confused about that difference. But that's another topic for another day. In the mean time, Lisa's satisfied with the app, and that's all I care about.

gtags 1.0 released

And there's even the official blog post written by me. Most of the work, however, was done by my intern, Stephen Chen, so thanks, Stephen! I have been fortunate in finding such amazingly good interns.