Monthly Archive for January, 2006

Atomic Commits to Version Control

Published
by
barneyb
on January 27, 2006
in development
. 1 Comment

As many know, I'm a strong (tee-hee) advocate of version control.  For everything.  Code, of course, configuration files, my GNUCash datafile, etc.  Basically, if it's important, and it's not several gigs of photos, music, or video, it's in version control.  Seems like overkill for a lot of things, but at the very least, it allows me to back up my repository and get all my important data in one fell swoop.

One thing that I try very hard to be diligent about is the 'atomic commit'.  That is to say, when you commit, you're committing exactly one change.  It might be across a bunch of files, but it's one change.  The reason is that if you later realize it was a bad choice for whatever reason, you need only do a reverse merge (merge -rN:N-1) to undo it.  If you don't have an atomic commit, and you only want to undo part of what you committed, then you're stuck with doing that merge, but then undoing part of the merge, which gets really dicey if you've got some mods in a file that you want, and some mods that you don't.  Ick.

I mention this because I wasn't diligent about this on two commits about 3 weeks ago.  And of course, part of one of those commits needed to be rolled back yesterday, and it took the better part of 3 hours to do, instead of the expected 10-15 minutes.  Version control is far too powerful of a tool to squander it's capabilities by being lazy when it comes time to check in.

Bonus points to anyone who got the joke I "laughed" about in the first sentence. ; )

Persistance CFC Generators

Published
by
barneyb
on January 17, 2006
in cfml
. 7 Comments

Last week a couple friends (Sim and Chris) and I were taking about persistence mechanisms and the benefits of each.  Obviously there's the inline SQL route, which is the more performant, and the most cumbersome to maintain.  At the other end are abstract persistence frameworks such as Arf! or Reactor which are designed for ease of use and maintenance, but not necessarily for speed or complex operations.  In the middle is the concept of ra static generator, which is basically a tool that'll write all your persistence code for you, based on your DB schema, but once written, it performs no management.  You have to write the generator to begin with, of course, but you can also customize the generaated code to match your application.

The question was what's the right solution.  Between the three of us, we decided that all three were.  The main app I work on uses a generator because performance is important.   Sim, on the other hand, did some prototyping with Arf! and decided that he'd just keep the backend for the production app, since it was performant enough.

It's an interesting puzzle, because the maintainability of a managed persistence layer is very attractive, but balancing that against performance can be difficult.  But there's a way to make the static generator method a lot friendlier that I wanted to discuss, because it's a little "weird", and can easily be overlooked (as I did for over a year).

Basically, what you do is use your generators as if they're a third party code source, and generate your CFCs into a vendor branch in your version control system.  Then you can easily maintain custom modifications to the generated CFCs (as almost invariably needs to happen), without it getting in the way of regenerating at a later time.  A good example is adding a field to an entity.  Add the field to the schema, regenerate to the vendor branch, and then merge the mods into your real codebase.

With a setup like that, the gap between a generator and a persistence framework is narrowed considerably, because you can effectively regenerate as often as you like (though it still requires a manual step).  But you needn't pay the run time cost of a framework, which can be important for heavily loaded applications.

Just wanted to throw that all out there as an idea to consider, and as another reason to make sure you're using some kind of version control for all your apps.

Firefox 1.5 Setup

Published
by
barneyb
on January 12, 2006
in development
. 1 Comment

I like Firefox.  A lot.  Enough to want to run three
copies concurrently, each with different options and different
purposes.  One for work, one for my personal stuff, and one for
some monitoring apps.  Main differences include two different
GMail sessions, some different prefs for auto find, and completely
different bookmarks, of course.

With 1.0.7, the setup was simple.  Just create three different profiles, and set it to not load the default profile in profiles.ini.  However with 1.5, that no longer works.  On Linux, at least, you need to pass in a MOZ_NO_REMOTE=1
environment variable.  From reading around, this seems to be the
case for Windows and OSX as well, but I haven't tested.  You also
to need to explicitly pass the -ProfileManager argument
on the command line.  Once that's done, you'll get a prompt for
which profile to launch any time you run your shortcut.  New
windows launched from other apps (by clicking links) will load in the
most recent active browser window, regardless of profile.

This
took the better part of a afternoon to get all figured out. 
Definitely a step backwards over 1.0.x, but whatever.  Note that
the profiles themselves upgraded without a hitch.

One problem this leaves you with is no way of telling what
window is from what profile.  You can usually tell by the
contents, but a more definitive identifier would be nice, and I found
it with the Firesomething
plugin.  The plugin is designed to change the "Mozilla Firefox"
tag in the titlebar to something humorous, like "Mozilla Thunderpanda,"
or whatever.  It has randomization, also, so it'll pick a
different name each time.  That's cool and all, but if you set the
option list to just be a single thing, you can use it to tag a
profile's windows with an in-titlebar label.  Since each profile
has it's own prefs, you can make them all unique.  Very
nice.  Only problem is it doesn't run on 1.5 out of the box. 
You have to unzip the .xpi file, edit index.rdf to change the maxVersion to 1.6+,
rezip, and then install.  But it's a small price to pay. 
Note this is obviously an unsupported hack, but it seems to work just
dandy.

Rounding out my extensions, just for reference, are
Adblock, Tab Mix Plus, and the fantastic Web Developer.  And if I
were on Windows, I'd have IETab in there too.   Since most of
you who read this are developers, use your version control system for
your Adblock rule list.  Makes it a lot easier to maintain,
especially across multiple profiles and/or machines.

I'm Back!

Published
by
barneyb
on January 12, 2006
in personal
. 0 Comments

The move is over, I've got an internet connection again, and life is
returning to normal.  All in all, the move went pretty well, and
we've pretty much got the house unpacked.  There's some boxes
still lingering, but most of them are stuff that we don't really need
(Christmas decorations, LEGOs, etc.).

I'll eventually fall back
into a routine, hopefully blogging more often, and at least joining in
on the mailing lists again.  But for now, it's playing catch up
for a week and a half of being disconnected from the office.