Groggy mentions trying to draw sequence diagrams with pic. I recommend using Spinellis excellent UMLGraph toolset that he developed while writing Code Reading. That book was wonderfully inspiring to me, and helped cement my desire to work on open source software.

From what I remember, the sequence diagram stuff was a clever set of pic macros, so that you could just describe a sequence diagram and then generate the picture. I love having pictures to use during a discussion because they help avoid confusion, but I absolutely hate drawing pictures or using drawing tools - I prefer to keep the diagrams in plain-text, source code, in a revision control system. Using pic for the sequence diagrams fits the bill perfectly. Code is …

I’ve never been much of a video game player, but I do remember Quake having this really excellent console for entering commands.

As a programmer, I find myself flipping back and forth between iTerm and applications like email and web browser very frequently. On linux, I use multiple desktops to accomplish this, on OS X I just use quicksilver and try to not be irritated that I have to readjust my windows all the time.

Hosted on the same site as the excellent quicksilver is an incredible application named visor which lets you assign a hotkey to make a terminal window appear out of nowhere, and then disappear again when you hit the hotkey. Best of all, it even maintains context. I can even run screen to get multiple windows, so bye bye iTerm.

This is going to make coding on MySQL on the mac so much easier!
Here is the link for visor:
…

While at the MySQL developers meeting in Sorrento, Italy, we are getting the chance to take the MySQL 5.0 certification exams, which are currently in beta. We are proud that we make the exams fair but very challenging - it will be interesting to see if any of the developers who helped write MySQL 5.0 fail the exam! I’m glad that MySQL makes these exams available to internal developers, as it would otherwise be far to easy to focus on your own particular area of specialization. Studying for the exam is a good reminder of the different ways that it is possible to use MySQL.

The beta exams are also available to the public, and while the exams are in beta you get the benefit of extra time.

I’m in Sorrento for the annual MySQL internal developers meeting, and had some really excellent espresso after dinner tonight. The result is that it’s 2AM and I’m pulling code out of bitkeeper and looking at bugs rather than sleeping, even though I am supposed to get up at 6AM to go have breakfast.

I did Windows development for many years, but these last few months I’ve spent most of my time on Linux and OSX, mostly because Ubuntu just works so well on my laptop, especially now that I’ve got Tomboy and NetworkManager. I switched back to Windows during meetings last week in order to spend some time working on reproducing BUG#17719, delete of binlog fails on windows, and I’ve been forced to acknowledge that running the MySQL test suite on Windows isn’t nearly as smooth as it should be. Fortunately, Reggie has done some great stuff with CMake, and Magnus fixed …

One of my favorite things about working at MySQL is that we are a distributed company. We have developers spread across dozens of countries, and most of them work from home offices. Before joining MySQL, I spent many years working for companies which forced the developers to work in centralized “development centers”, big office buildings located in various parts of the world. My one-year anniversary of working at MySQL is coming up in a couple of months, and I’m still amazed at how much better the communication is here than it was at those big companies with all the developers jammed into the same building.

At any time of day, I can log onto the internal MySQL IRC channels and discuss an idea or a problem with a MySQL core developer in some part of the world - in real time! We also make extensive use of VoIP technology, and so I end up communicating with my colleagues at MySQL much more regularly and efficiently than I ever imagined …

The title of this post come from a phrase I heard used by one of the AIX kernel developers when discussing techniques for debugging system crashes or bugs without having to ask the customer to reproduce a problem that occurred on a production. Even though it would be totally unacceptable to take a customers car and try to make the brakes fail “with a debug build”, developers often ask similar things of customers running software in production systems. At the time I heard this quote, I felt frustrated as a developer because there was not much that we could change in the software project I was building to avoid ever having to ask a customer to “re-crash the car”. The best thing that was offered up was coming up with some kind of unified set of error messages in the code base. A good idea, but far from actually solving the problem. At that time, the best system available was Windows crashdumps - but they only helped to find crashes, not with …

As I mentioned in a previous post, developing MySQL requires a fairly lengthy build and regression test process. While tests are running, it is normal to switch to another virtual or physical desktop and continue programming, discussing things with colleagues on IRC, or answering email. While working on my Mac, I got very used to writing a line like
make; say build is done; make test; say tests are done
. This kind of ad-hoc scripting is useful in a surprising number of situations.

The built in ’say’ command would use TTS (text-to-speech) to announce when the build was done and when the tests were done, which was nice because I would be notified when it was time to go check the test results, even if I was on the other side of my office working on a different machine.

I wanted something similar for linux, and my colleagues informed me that most distributions the festival speech synthesis package, but …

If you ever find yourself compiling MySQL (or any other large project) from source, no doubt you are interested in finding ways to speed up the process. For every single bug that is fixed, MySQL has to be compiled at least twice, and tested at least twice. So speeding up the process has a huge impact on how much capacity a single person has for fixing bugs (discounting the time it takes to figure out the fix, many bugs are easy to fix).

MySQL is build on *nix with Autotools (I’ll save that rant for another day). The generated makefiles have built in support for using the excellent ccache, which is a caching pre-processor for C/C++ compilations. The basic idea is that by taking a hash of the preprocessed source code, you can easily create an object cache using the hash as a key. When you get a cache hit, you simply yank the already-compiled object file out of the cache rather than …

I’ve just finished a tour through silicon valley (got to be up at 4:30 AM to catch a flight - yuck) for some meetings at the MySQL offices and had the opportunity to visit several customers (including our own internal webmaster!) to get some feedback on replication and backup features. I visited a good range of sites, from startups to very large established ISVs. The thing that impressed me most of all was just how smart the MySQL customers are.

When I’ve evangelised open source in the past I’ve often heard snide comments made by folks trying to understand open source, like “yeah, but does anyone actually look at the source?”. Yes, people actually look at the source. See, there are a whole lot of people in the IT/computer industry that actually care about being efficient (in terms of both human and computer resources), making things work right, and making sure that people don’t lose data. People look at the source code for MySQL …

This book arrived at my office yesterday, and I am quite impressed. I’ve bought a number of software security titles in the past, and usually find them quite difficult reading. While I’ve only skimmed the book so far, it is laid out in a way that is incredibly useful for a busy developer, and is quite respectful of how precious your time is.

For example, in the introduction, it says “Everyone should read Sins 6, 12, and 13 … if you are creating an application to query database engines, such as Oracle, MySQL, DB2, or SQL Server, you should read Sin 4…”

It gets even better when you discover how each “Security Sin” is discussed. Each chapter is broken up into small sections:

• Overview
• The Sin Explained
• Sinful Programming Languages (languages affected)
• Sample Code …