blog.s11n.net

OMFG: i am on the cover of Dr. Dobb’s Journal #416 (Feb 2009)!

Back in October i briefly met Mr. Jonathan Erickson, editor of Dr. Dobb’s Journal, and spoke to him a bit about the presentation he had made at the Qt Developer Days conference in Munich, Germany (primarily about concurrency). After he returned to the States we shared a few emails and then went around our business. He had, in one email exchange, asked if i would fill out a short questionnaire for a column DDJ does now and then to briefly present random programmers they meet. Not one to miss a good opportunity to write, i of course answered. That was, incidentally, on October 30th (my father’s birthday and the two year anniversary of my cancer diagnosis), and i hadn’t given it any thought since then. But i just learned that all that time, Jon was busy plotting…

A couple hours ago my mother called me to tell me that (A) she loved me, (B) the latest edition of DDJ had arrived (my subscription is sent to her to save the overseas shipping costs), and (C) that i was on the cover.

What? i beg your pardon? i seem to have a small mammal in my ears, interfering with my hearing. i thought you just said that i’m on the cover of DDJ. The DDJ.

No, seriously. The cover is my face. It’s the same picture from my home page. Only a lot bigger. Huge, one might say. (For the curious, the picture was taken in Sylt, Germany, in August of 2006, by my girlfriend, Simone.)

The articles mentioned on the cover have absolutely nothing to do with me (nor i with them) except for the little blurb on the bottom/right:

Freelance Programmer Stephan Beal, see page 12

No, seriously.

My mugshot certainly isn’t going to help them sell copies, so why that picture for the cover, of all the lovely and beautiful images they could have used? Your guess is as good as mine. My only theory at the moment is the visual association of a cloudy sky (which is mostly cropped out of that copy of the image) with the headline article, entitled “Computing in the Clouds” (but, again, i’m not associated with that article). Well, and maybe because my clothes match the overall color scheme pretty well. No idea, really.

Unfortunately, the February edition of DDJ isn’t online yet, so i can prove to you not one word of what i just wrote. i can’t post the scanned copy my mother sent (for copyright reasons). So it’s my word against… well, against someone’s, certainly.

So here’s how we can settle this: if you’ll go to your favourite I.T. news stand right now, you might just find me waiting for you! If you’re a DDJ subscriber, i’m already there.

Happy hacking!

PS: Thanks again, Jon! That really made my day!

Four reasons to take a closer look at the Fossil SCM

This post was originally made to the mailing list of the Fossil source control system on January 11th, 2009, with the subject line “A letter to the new or unconverted fossil user”. After reading it over again, i figured i could recycle it as a blog post to evangelize Fossil a bit. It might also make good food for the 200+ spambot suscribers to this blog from @mail.ru.

…

This is addressed those of you who are new to fossil and those who have used it for a while but just aren’t quite sure whether they like it or not…

Sometime in late 2007 i came across a link to fossil on sqlite.org. It was a good thing i bookmarked it, because i was never able to find the link again (it might have been in a bug report or something). The reasons i first took a close look at it were (A) it stemmed from the sqlite project, which i’ve held in high regards for years (e.g. i wrote JavaScript bindings for it: http://spiderape.sourceforge.net/plugins/sqlite/), and (B) it could run as a CGI. That second point might seem a bit archaic, but in practice CGI is the only way most hosted sites can set up a shared source repository with multiple user IDs. (i’m not about to give out my only account password or SSH key for my hosted sites, no matter how much i trust the other developers, and none of my hosters allow me to run standalone servers or add Apache modules.)

So i tried it out. The thing which bugged me most about it was having to type “commit” or “com” instead of “ci” for checking in (as is custom in all other systems i’ve used), despite the fact that fossil uses “ci” as a filter in things like the timeline view. Looking back now, i have used fossil for about about 95% of my work in the past year (http://blog.s11n.net/?p=71), in over 15 source trees, and i now get tripped up when i have to use svn or cvs.

So, having got over typing “fossil com -m …”, here’s why i love fossil so much…

Point #1: CGI

Again, this sounds archaic, but fossil has allowed me to share source trees which i cannot justifiably host in other projects i work on (they don’t belong to those projects), which i cannot host in Google Code (because google code doesn’t allow/recognize Public Domain as a license, and i refuse to relicense just to accommodate them), and for which SourceForge is overkill (and way too slow). With fossil i can create a new repo, have it installed on my hoster (http://fossil.wanderinghorse.net), and be commiting code to it within 5 minutes.

Point #2: Wiki

i hate wikis. i really do. Always have. They all have a different syntax and the content tends to get really disorganized really quickly. Their nature makes it difficult to reorganize them without replacing old pages with lots of “has been moved to [TheNewPage]” links. i’m one of those “code for tomorrow” coders (i.e., code such that it’ll be easy to reorganize/refactor later). i like to document the same way, and wikis make that problematic. Then again, no documentation system is really good in that regard.

That said, fossil has made me love having a centralized, common documentation platform. Whereas i used to document everything in the API docs (header files) and often include an ODT file for a library manual, fossil has become my preferred platform for non-API documentation because it’s just so easy to do. No matter where i am, i can log in and write (i write a lot). The added ability to export my wiki pages, edit them in xemacs, and re-import them just makes it nicer, as i can tweak as much as i want without ending up with 10 “updated wiki page SoAndSo” messages in the commit log.

Point #3: running a server locally

Fossil runs not only as a CGI, but as a server. i don’t WANT to host my own server (and don’t have the rights to on my hosters). i hate server-side maintenance (a hate born from years of administering systems). But the server has other uses. When working on the wiki, bug reports, etc., the local server is the way to do it. It’s blazingly fast and much more productive. When you’re done, just run “fossil push” and everything’s synced.

Point #4: the single-file repository

Having all controlled content inside a single container file has been a godsend when it comes to backups and copying/moving a repository. There are no access or file ownership issues, which are often problematic with other server-side systems (at least on the initial install). For about 5 years i administered a CVS repo for a company for, and every time someone added a directory to the (huge and dynamic) source tree i had to log in and “chmod 4775″ the directory before others could commit to it. Fossil’s model inherently eliminates that type of problem, and i’m a *huge* fan of solutions which inherently (that is, due to their very nature) avoid certain foreseeable problems. The single-file repository model’s flexibility would seem to become more problematic for massive repositories (a few hundred MB+) with many users with differing levels of access (e.g. OpenOffice, Firefox, or the Linux Kernel), but 99.9% of projects never reach anywhere near that size or complexity. (For that level of project, it would seem the world is quickly migrating to git.)

In summary:

i remember my first reaction to fossil being, “this will be an excellent solution for small projects [like the dozens we've all got sitting on our hard drives but which don't justify the hassle of version control].” A year of daily use in over 15 source trees has confirmed that, and i continue to heartily recommend fossil to other developers i know who also have their own collection of “unhosted” pet projects.

Even if fossil stagnates today, never adds another feature, and never gets another bug fix (what bugs?), this is a tool i see myself using for many years to come. (No, honestly, i don’t know what bugs you’re talking about.)

Happy hacking!