Factor Talk at the Lambda Lounge

Last night (April 2, 2009) at the St. Louis Lambda Lounge I gave a 45-minute talk on the Factor programming language. I’ve uploaded the handout and example code here. I apologize in advance to anyone in the Factor community who reads it and laughs at my “newbie” mistakes and misstatements.

Appistry again provided space and pizza – thanks guys! (Appistry is our locally-grown but widely-known cloud infrastructure software maker – they’d been cloudy for years before the term entered wide use.)

The talk appeared to go over well. There were many important things about factor that I’d love to talk about but didn’t have time. Nonetheless, I think 45 minutes is a good talk length, and I think the format (short talks) is a key part to the Lambda Lounge’s success so far.

Speaking of the Lambda Lounge,  next month there is a “language shootout” – if you want to participate, be sure to join the mailing list and look over the participants. (You need to join the list, to be able to get to the wiki with that page.) I might submit an entry myself, using Factor or another language.

Git Talk at the STL JUG

Yesterday (Oct. 9, 2008), I gave a talk on Git at the St. Louis Java User Group. Rather than a typical “intro” talk, instead I showed a dozen or so common usage scenarios, then answered questions with additional ad-hoc demos. As with some other recent talks, I eschewed PowerPoint in favor of a printed handout. The text of the handout follows below, or you can download the PDF. I also recorded the audio of the talk, but without video, so the general discussion portions are worthwhile but the demo portions are not.
Continue reading “Git Talk at the STL JUG”

A Brief Introduction to Distributed Version Control

Last night at SLUUG, I have a talk on distributed source control tools. It was quite introductory, but the notes (below) may still be helpful. These notes were on a handout at the talk, as usual I didn’t use slides.

Unfortunately I didn’t get an audio recording of this talk, so no transcript either.

About 30 people were in attendance. Nearly 100% were familiar with CVS and SVN, and perhaps 20% with other tools (ClearCase, SourceSafe, and others). Only 4 had ever used branch/merge in any project or tool!

A Brief Introduction to Distributed Version Control

You Branch and Merge.

A fundamental truth: every time you edit a file you are branching, and every time you reconcile with another developer you are merging. In most tools you get one easy branch and merge locus: your local working directory. All other branching is a Big Deal.

It does not have to be this way.

A Short Tour of 3 tools

bzr: http://bazaar-vcs.org/

hg: http://www.selenic.com/mercurial/

git: http://git.or.cz/

Also, check your distro’s package system.

(At this point in the talk I demonstrated the basic features of each)

What is a DVCS? Why Use a DVCS?

Peer-to-peer design

Everyone gets all the features, rather than the interesting features limited to a high priest class.

Make use of the massive CPU and disk capacity on dev machines.

No central server needed, though many projects nominate a machine for this purpose.

Use a “dumb” storage location for a repository, if desired. Or a “smart server” for performance and security.

Work offline, with full history, branches, merges.

No central administrator is needed, potentially a cost savings.

Very cheap branching, in some cases immediate, even for large projects.

Very good merging, because you merge all the time.

Commit-then-merge, not merge-then-commit.

Repeated merge without havoc.

Merge keeps both sides of history, which is important because you merge a lot. This varies by tools, for example apparently bzr keeps this history less effectively than some others.

Depending on what you are coming from and which tool you choose, the speed gain can be so remarkable that it help every developer every day.

Some SVN Nitpicks

It is easy and tempting to pick on SVN. Linus does so vigorously in his online talk. I don’t hate it as much as he does but, these things bother me:

SVN is slow for large projects.

Branching in SVN sounds clever as you read its cheap copy story. It’s a great story. But actually using it is ridiculous; both in the URL-crazy syntax and utter lack of merge history.

We don’t need a better CVS, we need something much better than CVS.

.svn directories scattered all over are a pointless pain.

.svn directories are enormous, sometimes larger than the entire project history in git or hg!


Security is a weak area in terms of out-of-the-box features and tutorials, because these tools come from the open source world where the default is for everyone to be able to see all code. However, with a little effort you can set up whatever security you like:

If you’re serving over HTTP, you can use Apache mod_whatever to control access.

Tunnel over SSH (in the box, in most cases) to avoid ever sending code in the clear.

Even a “dumb” storage location can be secured with SFTP.

Scripts can be used for per-branch and other fine grained access control, akin to what you can do with svn-access.conf. There are examples online.

I Can’t Use a DVCS Because:

SOX/HIPPA/CMM/etc. requires a centralized tool.

SOX/HIPPA/CMM/etc, is the standard reason why anyone can’t do anything. Some of these tools facilitate much stronger guarantees about the provenance of the source code than you get from a centralized tool, because they have credible and straightforward ways to verify that centralized store has not been compromized.

We are all in one place, therefore a DVCS makes no sense.

Actually many of the features in these tools are as useful in the same building as in a worldwide team.

Tool ZZZ is our corporate standard.

Then you should use it, don’t get fired. However, many people are using a DVCS in front of their corporate standard tool.


Many DVCS tools treat each repo/workspace as a branch and vice versa, so if you use many branches you will have many workspaces.

bzr can use shared files to reduce the bloat from this.

git handles many branches much better, with arbitrarily many per repo/workspace.

My feeling is that hg and git are more mature than bzr.

git does not work well on windows yet.

Other DVCS to Consider

Monotone – has some slick features, but does not appear to scale well to large projects. It stores information in a SQLite DB. Monotone, unlike any others I’ve seen, replicates all branches by default, which is nice.

An aside — there are fascinating thoughts on how to a data synchronization system can work, in the Monotone docs / presentations.

arch / tla — one of the early DVCSs that started all this. I have heard it is mystifying to use.

darcs — everyone loves its “cherry picking”, but I have not triedit.

SVK — optimized for being a better svn client, with offline history and merging that works. Stores merge history in SVN attribute.

More git Merging

Depending on time, I will show more of the branch / merge facilities in git, as well as its gitk GUI.

Other Resources



Update: the following appeared a few days after my talk, it is very good, aside from slightly bogus listings in the “disadvantages” section:

Selling your Software as a Service: Notes and Audio

At the St. Louis Code Camp on May 5, 2007, I gave a talk on Selling Your Software as a Service, in which I discussed our experiences selling a complex (Java) “enterprise” application in that manner. The room was much more crowded than I expected, it was exciting to have an eager group. As with all my recent talks, I used a handout instead of slides. You can download a PDF of the handout (one page, one side), or read the contents below.

The 1 hour audio recording (Olympus WS-100 digital voice recorder, Audacity cleanup) is available here: SAASTalk.mp3

A transcript of the talk is available. In the talk I mentioned Paul Graham’s The Other Road Ahead, which is shorter and easier to read the my talk transcript.

A couple of people at Code Camp asked if I could come give a similar talk in-house at their firms. Yes – please contact me with the contact form to arrange a date.

The handout contents follow.

Continue reading “Selling your Software as a Service: Notes and Audio”

St. Louis Code Camp, May 5 2007

It’s time for the second (annual) St. Lous Code Camp on May 5, 2007. There’s no actual camping (unlike some other ___ camps out there), just one day of sessions. Think of it as a mini-conference. See Brian’s announcement for more details. If you’ve been thinking of giving user group talks and never gotten around to it, Code Camp is a great place to start.

I’m in for two sessions this year, assuming enough slots are available for both:

Flying Boxes

It’s surprisingly easy, with Java and Swing, to build animated drag-and-drop “direct manipulation” user interfaces. I covered the overall topic in a talk at the Java User Group, and found that my “flying boxes” demo and code walk-through were by far the most interesting part. I’ll repeat that demo and explanation here, with more careful (and thus helpful) coverage of the issues involved in getting good results. As “filthy rich” GUIs become more popular, the ability to build such interfaces has become important in commercial business applications, not only in demos and games. The code can be downloaded from my web site.

Selling your Software as a Hosted Service

For the last few years my (other) firm has been selling an application as an Application Service Provider, charging a monthly fee for use of software that we develop, host, and support. (This is sometimes called the “Salesforce.com” model, but it predates them by decades.) Of course we have much still to learn, but in this talk I’ll share some experiences, tips, and advice on how (and whether) to use this business model for your own ventures. The last portion of the session will be a roundtable discussion, I’d like to learn from you too.

Ruby GUI Toolkit Talk: Notes and Audio

On March 27th I gave a talk at the St. Louis Ruby User Group about Ruby GUI Toolkits. As with my last few talks, there were no slides, but rather a handout. The original handout fit tightly on a single, two-sided printed page; I’ve expanded the materials slightly and pasted them here.

I also recorded audio of the talk with my Olympus WS-100 digital voice recorder, then used Audacity to clean it up; Audacity’s “Remove Noise” feature worked surprisingly well. The recording lasts 1 hour 23 minutes, is 49 MB in size: RubyGUIToolkitTalk.mp3

A transcript of the talk is also available.

In the audio I mention screen shots and demos; you can find those at the respective toolkits’ web sites (linked below). I also briefly discuss and demo some code from a 2005 talk about Swing.

The handout contents follow below.

Continue reading “Ruby GUI Toolkit Talk: Notes and Audio”