SQLite 3 and Ruby finally working on OS X

I’ve been trying to get Typo working with SQLite 3 on my Mac off and on for MONTHS with no success. The root problem was simple:

  a = Article.new
  a.title = 'Testing'

  a.save => true
  a.id => 0

Somehow, the ID wasn’t being updated whenever new ActiveRecord objects were created. They’d end up in the DB just fine, but the new ID wasn’t visible from Ruby. Since this is a really basic feature of any ORM, I was really amazed that it didn’t work. A bit of research shows that SQLite and Rails work fine for most users, but I’m not alone with this problem–there are a few reports of similar problems on the Rails wiki.

For the fun of it, I installed SQLite on one of my Linux boxes, and everything worked fine there. So I tried installing a newer SQLite via DarwinPorts, with no improvement. I spent a couple hours uninstalling and reinstalling things, and nothing changed anything. Digging deeper, the bug was clearly deep inside of sqlite3-ruby–it was telling Rails that the ID number for the latest insert was 0.

I finally figured out the problem here at Gnomedex today while watching to the Gillmor Gang record their latest podcast. It’s simple:

The SQLite bindings for Ruby require SWIG. If SWIG isn’t installed, then they’ll still work, sort of, but they fail to fetch the ID from SQLite.

So, to fix the problem, I just ran port install swig, then gem uninstall sqlite3-ruby and gem install sqlite3-ruby.

There’s probably a endian problem in the non-SWIG SQLite Ruby code, but it’s easier (and probably faster) to just install SWIG.

Posted by Scott Laird Sat, 01 Jul 2006 21:26:23 GMT

Consulting and Billing on OS X

One of the problems with working for yourself is that you need to do all of your own bookkeeping. I’m approaching the end of my first month in business and it’s time to send out the first batch of invoices, so I spent yesterday looking over all of the reasonably-priced accounting and/or time-tracking applications for OS X. Those are really two separate needs, but they tie so closely together that I’d love to find one package that can handle both tasks, so I don’t need to manually copy time records from the tracking program over to the accounting program. I’m not convinced that this is actually possible, but it’s a worthy goal.

I’m currently evaluating 4 different packages.

The first was Project Timer Pro. I’ve been test-driving it for the past couple weeks, but I don’t think I’m going to end up buying it. It’s a nice, basic project tracker–you define customers and then create timers that count up how much time you’ve spent working on each job. It’ll generate invoices at the end of the month, but it doesn’t do any expense tracking, so at the very least I’d have to carry a big Excel worksheet around to track my expenses. It has a few nice things going for it, but the interface feels clunky and I’ve had a hard time actually getting it to do what I want. I’ve had a particularly hard time getting decent invoices out of it, and even extracting a detailed time sheet wasn’t as easy as I would have wanted. Project Timer comes in two versions, Pro ($50) and Lite ($20). Their website doesn’t do a good job of explaining the difference between the two, but Pro mostly seems to add more invoice-tracking options.

Since Project Timer Pro clearly doesn’t replace the need for an accounting program, I spent a couple hours looking over the options for small-business accounting on OS X. There seem to be three main choices: QuickBooks Pro ($180 from Amazon), MYOB AccountEdge ($290), and MYOB FirstEdge ($100). Reading Amazon’s reviews, people seem to hate all three fairly equally, but that’s pretty typical in my experience–accounting software has always came in two flavors:

  1. Built by accountants. Does a great job on the books, but it’s unusable by normal people and typically has corruption and crashing problems because accountants make lousy programmers (and utterly horrific UI designers).
  2. Built by programmers. Whiz-bang UI, fairly stable, gladly produces unreconcilable accounts. Usually lacks one or two utterly critical features. Your accountant looks at you funny when you try to hand him the output from your alleged accounting program at the end of the year.

Since all accounting software sucks, I wasn’t surprised to find a mix of 5-star and 1-star reviews for all three packages. So I decided to mostly ignore the reviews from Amazon and do my own footwork.

I started by eliminating QuickBooks: I’ve never liked Quicken, and QuickBooks for the Mac seems to be more expensive then the Windows version while lacking a number of useful features. Most magazine reviews hedged their reviews by saying that it was great if you were familiar with the Windows version, but that there were better options on the Mac. So I decided to try ouy MYOB’s options. I downloaded a free trial of FirstEdge, and it seems decent enough for what I need. It took me about an hour to set it up and spit out my first invoice, which isn’t too bad. Since I’m just one guy with no employees and only a couple dozen transactions per month (at worst), FirstEdge looks good enough for me. Since it’s the cheapest package in the linuep, I’ll probably stick with it, unless I decide that I can get by with a souped-up time+expense tracker application.

On the time-tracker front, I’m looking at two programs: iBiz ($29) and Studiometry ($99). iBiz has the same basic features as Project Timer Pro, but it’s a bit cheaper and more Mac-like. I haven’t played with it enough to really get a feel for it, but it looks like a nice, simple time-tracker.

I’m more interested in Studiometry, even though it’s more expensive. It includes a number of extra features:

  • Light-weight customer-tracking tools (call log, etc).
  • Basic bookkeeping (expense tracking, tax reports).
  • A to-do list that’s tied to specific jobs, with alarms.
  • The ability to manage quotes and compare estimates to actual progress.
  • A light-weight project manager tool.

Even though it’s more complex, it seems to fit together well enough that it doesn’t seem bloated to me. I’m not convinced that it’ll do everything that I want, but frankly I could buy all of these apps for what it’s cost me to evaluate them so far, so I’ll probably end up buying it and getting on with my life. I’m less sure about FirstEdge–I suspect that I’d be better-served by simply entering all of my expenses into Studiometry (or even Excel) and then handing the whole list off to an accountant every now and then. The evaluation period for both products goes on for at least another week, so I’ll probably run off a couple more invoices and see how they both do; then I’ll decide if I need FirstEdge.

Posted by Scott Laird Thu, 29 Sep 2005 17:31:22 GMT

Farewell, sweet XEmacs

I can’t believe I’ve finally done it. I’ve quit using Emacs.

Over the past month, I’ve switched to using TextMate as my day-to-day programming editor. Since I live in my editor 4-12 hours per day, this is a huge change for me. I’ve been using one form of Emacs or another since late 1990 or early 1991; that’s a huge amount of inertia to overcome. It’s been a lot easier then I expected, and I’m starting to really enjoy a lot of TextMate’s features.

Here are a few of the advantages that I’ve seen with TextMate. Some of these are quirks of my setup, but others are fundamental things that TextMate gets right that Emacs couldn’t do without a 6-month flamewar and a couple forks:

  • TextMate’s Rails support is better then XEmacs’s. XEmacs’s Ruby mode has a few quirks that frequently broke indenting, and it completely failed to understand .rhtml files. I’m sure that I could have fixed this, but after 14 years of using Emacs, I still hadn’t bothered to learn more then a few bits of elisp. Frankly, I really only used 1-2% of what Emacs could do, partially because most of the rest of it was such a pain to learn about.

  • For some reason, cut-and-paste between X11 and native Mac apps broke during my Tiger upgrade, and I was never able to get it fixed. It wasn’t usually a big deal for me when I was working on code for Network Clarity because I rarely ended up pasting things into Emacs, but it was a huge pain when I was working on Typo.

  • TextMate is actually better at handling tons of open files then XEmacs is. This surprised me, but the interface for switching files from the keyboard is way better in TextMate. Just press Command-T and start typing pieces of the filename. TextMate starts searching for filenames that match the name you typed using the same algorithm that QuickSilver uses. So, if you want to find articles_controller_test, TextMate will let you type something short like artcontest while narrowing the field of files down with each extra character that you press. XEmacs expects you to type the filename starting at the beginning, using tab for completion. So finding the same file with most of Typo’s source open would be something like ar<tab>s_c<tab>_t<tab>, which is more of a pain. Plus, when you have multiple files with the same name, Command-T will let you use the arrow keys to scroll through them, seeing the full path for each. XEmacs seems to prefer that you remember which of the half-dozen content.rhtml files in Typo is content.rhtml<4>. Finally, when you’re in project mode, Command-T will actually search through all files in the project directory, not just open files. So Command-T artrb will show you articles.rb. That’s much nicer the C-x C-f ../../../app/models/ar<tab> that Emacs needed. I’m sure that there’s some way to make XEmacs friendlier on this front, but that really means very little–there are ways to make Emacs solve Towers of Hanoi problems, read your mail, act as a web browser, play inline movies, and quote Zippy the Pinhead quotes to Eliza, too. Just because it can do it doesn’t mean that I’m willing to spend two hours figuring it out for each and every feature that I’m interested in.

  • TextMate is better at pasting text. It automatically re-indents the pasted text, so you don’t have to go line-by-line fixing the indentation.

  • TextMate supports most of the basic Emacs editing keystokes – C-f, C-b, C-n, C-p, C-d, C-k, C-y, and C-s all work like I’d expect (although C-y was missing for a while), so I haven’t really had to reprogram my fingers.

  • Finally, it’s a native Mac app, so it works like all of the rest of the apps on my system. While it’s nice that you can run X11 apps in OS X, there are a number of quirky things that they do that makes them feel weird after three years on the Mac. They don’t hide right, they don’t act right when you change the focus, and they just generally look weird.

So I bought it. TextMate is €39, which is kind of a shock when you’re used to free editors, but it’s not a bad value at all. It’s dirt cheap compared to BBEdit, which I’ve tried a few times and never really understood why anyone would pay almost $200 for it. All in all, I’m really happy with TextMate, and I feel like I’m substantially more productive when working on Rails apps with it because I don’t have to keep working around Emacs foibles. So far, it Just Works.

Posted by Scott Laird Sat, 10 Sep 2005 03:47:48 GMT

I need a new keyboard and mouse

I need for a new keyboard and mouse to use with my Mac, and I'm looking for recommendations. Right now my PowerBook is spending most of its life on my desk at home, plugged into an external monitor, drives, and network, and I'd like to throw a real keyboard into the mix. My PowerBook keyboard is getting old (over 3.5 years now), the down-arrow key is starting to stick, and it makes weird clicking noises sometimes. I'd like to replace the PowerBook soon, but for now I'm more interested in having a keyboard that I can be productive with without accruing a couple grand in debt.

I spent a few minutes at the store yesterday and found three things:

  • I don't really like the the feel of Apple's current keyboards.
  • Microsoft's Optical Desktop Elite has a decent-feeling keyboard, and I like the idea of having a scrollwheel on the keyboard. I have no idea if I'd ever actually use it, though.
  • Logitech's LX500 package has a okay keyboard, and it's around $25 for a keyboard and mouse after rebates.

All of the other keyboards that they had on display sucked. Most keyboards are too mushy for me. My personal favorite is from NMB--they used to make a really nice keyboard with real keyswitches that clicked a bit while typing, but not as bad as the beasts that IBM used to make. Unfortunately, I can't find anything like that on the market anymore. Apparently mushy is cheaper, so no one stocks non-mushy keyboards anymore.

So, I'm basically looking for three things:

  1. Has anyone used either of the keyboards that I listed with a Mac? Did they work okay, or do they need some nasty driver before anything works right?
  2. Does anyone know where I could find a modern USB keyboard (ideally with a Mac option key instead of a Windows key) that uses real springs instead of a membrane?
  3. Does anyone have any other keyboards that work well that they'd recommend?

Posted by Scott Laird Fri, 09 Sep 2005 17:26:30 GMT

Tiger supports NTFS

According to Mac OS X Hints, Tiger has NTFS support, so it can finally read hard drives formatted for modern versions of Windows. I’ve wished that I had this several times over the past three years; it’s nice to know that it’s now there when I need it.

Posted by Scott Laird Thu, 04 Aug 2005 21:46:28 GMT

Apple Universal Binary Question

So, with Apple’s new “Universal” binary format, where Xcode creates programs that will run natively on both PPC and x86 chips, is there actually a single Mach-O file that contains code sections for both processor types, or are there two different executable files hiding inside of an application bundle?

Apple’s documentation kind of implies that the two architectures are stuffed into a single binary:

You can force a command line tool to run translated by entering the following in Terminal:

ditto -arch ppc tool /tmp/<toolname> 

There only other statement that I see in the documentation that gives any details is this little gem:

Note: Xcode has per-architecure SDK support. For example, you can target Mac OS X v10.3 for PowerPC while also targeting Mac OS X v10.4.1 for Intel.

Between the two statements, it seems pretty likely that the PPC and x86 binaries are crammed into the same file, but probably don’t share static strings or any of the other parts of the executable file. They’re really just two distinct program files combined into a single physical file.

Are any other details on the universal binary process public yet?

Posted by Scott Laird Wed, 08 Jun 2005 17:05:00 GMT

Apple's move to x86: will it run on non-Apple PCs

After reading the transcripts of this morning’s WWDC keynote, I’m now feeling pretty good about Apple’s path. They’re going to have sales problems in mid 2006, but for now, there’s no reason for Mac users to avoid buying new systems. I’m still planning on going PowerBook shopping in a few months, and I suspect that most existing Mac users won’t see a problem with buying PPC-based Macs, at least until the x86 ones start appearing on the horizon. I can see waiting 2-3 months for new systems, but waiting for 18 months because something better is coming is just dumb.

The big question on a lot of minds (mine and my co-workers, at least) is whether Apple will sell OS X for non-Apple x86 systems. After today’s announcements, it’s clear that they’ll be technically able to do it in mid 2006. The only real difference between OS X for x86 Macs and OS X for x86 PCs is driver support (er, and bootloader, BIOS, installer, ACPI, and disk partitioning), and I’d bet any amount of money that Apple has people in-house expanding their driver support to allow them to run on generic PCs.

But, just because they can sell OS X for PCs doesn’t mean that they will. Sometime in early 2006, Apple will have to make a decision–are they going to try to take on Microsoft on their home turf, or are they going to stick to their usual niche and try to sell more Mac hardware. With most companies, it’d be a purely financial decision, but with Apple it’ll probably be more of a “where does Steve want to go today” sort of thing. And there’s only one person who can answer that.

Even if Apple decides against selling OS X for generic PCs, though, it isn’t going to stop people from doing it themselves. Unless Apple goes to great lengths, we’re going to see people taking bits of Darwin and grafting them onto the OS X for x86 install DVD and building their own OS X for PC systems. It’ll be just like XPostFacto all over again. It’ll be uglier then OS X on x86 Macs, and the bootloader will be downright strange, but it’ll happen. Or, alternately, someone could graft most of the bootloader and some of the hardware emulation into something like Xen; when running on a PC with either of the new virtualization technologies, that’d be a great way to get both OS X and Linux running on the same physical hardware.

It’s going to happen. Personally, I think it’ll take about two months after production x86 Macs start shipping before you see packaged instructions and tools for building a OS X PC. One of my co-workers thinks that the clock is going to start running as soon as Apple’s P4 development systems start shipping, but I doubt that we’ll see leaks this early–Apple sued people who leaked early Tiger images, and it’d be foolhardy to assume that Apple will ship complete x86 development systems without embedding serial numbers and identifying information all over the place.

Either way, though, there will be small numbers of non-Apple OS X PCs by late 2006. I wonder how Apple will respond.

Update: The rumors start.

Posted by Scott Laird Tue, 07 Jun 2005 01:00:51 GMT

Tiger: Safari saves extra spotlight metadata

According to a post on 0xDECAFBAD, Safari records a bit of extra metadata onto every file that you download:

$ mdls QS.2AD4.dmg 
QS.2AD4.dmg -------------
kMDItemAttributeChangeDate     = 2005-05-06 12:40:37 -0700
kMDItemWhereFroms              = (

Notice the kMDItemWhereFroms entry–that’s Safari tagging the file to remind you where it came from. I didn’t think that was possible in Tiger–Safari just downloaded the file, it doesn’t own it, and it doesn’t provide a Spotlight indexing driver for the file. Somehow, it still managed to add extra metadata of its own onto the file; I though we were going to have to wait for 10.5 before we could do this.

Unfortunately, the extra tags are fragile. I made two copies (one using the Finder, one using cp), and neither copy has a kMDItemWhereFroms field. That’s what you’d expect if Safari cheated and stuck an extra field into Spotlight’s DB, but it’s not how a “real” metadata system would behave. Hopefully 10.5 will allow metadata to belong to the file itself, not just the Spotlight index, so that copying it will preserve the extra metadata.

Posted by Scott Laird Sat, 07 May 2005 03:12:22 GMT

Tiger adoption rate

This is certainly a skewed sample, but I just ran a quick test, and it looks like over half of the Safari users that have visited this site today are using Safari 2.0. Most the the rest are using Safari 1.3. Considering that Safari 2.0 is only available on Tiger, and Safari 1.3 arrived about two weeks ago as part of the 10.3.9 upgrade, it looks like most of my readers are quick upgraders.

If time permits, I’ll build a little graph later showing the version percentage by day; that should be entertaining.

Posted by Scott Laird Tue, 03 May 2005 02:11:04 GMT

Tiger: what's next?

I’ve been thinking a bit about what Apple’s going to do as a followup for Tiger. Assuming that Apple sticks with an 18-month cycle for 10.5 (“Lion”?), then we’ll be getting our hands on it slightly before Longhorn’s release date. Given that, it’s pretty clear that Apple is already thinking about what they want in 10.5 so they can trump Microsoft’s Longhorn offerings in the media. More then any previous release of OS X, I expect this one to be flashy; if Tiger was really an attempt to revamp the developer core of OS X, then I expect 10.5 to focus on the user experience.

A few things that I expect to see:

  • Improved metadata support. Just like Jon Siracusa has been saying, metadata is important. With Spotlight, we now have a framework for searching and storing file metadata. With 10.5, I expect to see the ability to tag files with specific metadata tags, like project name, priority, status, and so on. This is a feature that was pulled from Longhorn because of time constraints; Apple should be able to jump way ahead of Windows without a lot of work in this area.

  • Networkable Spotlight. Right now, Spotlight only works on local filesystems. Adding network support for Spotlight searching (and all of the other metadata that goes with it) will finally give people a decent reason to buy OS X servers.

  • A Finder replacement. Once we have the new metadata engine, we’re going to need a UI for managing it. I’m not sure if Apple will simply provide us with “Finder 2.0,” or if they’ll produce a radical new file manager and then provide users with the ability to revert to the old finder if they don’t want to upgrade. Either way, if Apple finishes their metadata back-end, then the Finder really needs to be updated to match. Since Apple hasn’t really put much work into the Finder since 10.0, and there are boatloads of customer complaints about the current Finder, I think it’s time for it to get re-written from the ground up, with the new version centered around metadata and searching.

  • More syncing and disconnected support. Windows has supported disconnected operation on network shares for years. That way, you can have a network share for some project, but have Windows maintain a local cache so you can still edit documents while you’re on a plane or otherwise unable to connect to the network. It’s a great feature, and Apple doesn’t have anything even vaguely like this right now.

  • Full 64-bit support. With Tiger, Apple has some support building 64-bit applications, but you can’t use any of the UI frameworks from 64-bit apps. I fully expect 10.5 to provide equal support for all current APIs from 32- or 64-bit code, and I expect that Xcode will have simple support for building “fat” 32/64 applications. If Apple leaves 64-bit apps out in the cold, then they’re giving Microsoft a big opening, and we’ll see claims that OS X isn’t “a real 64-bit operating system.” By 2007, at least 80% of new PCs and Macs will come with 64-bit CPUs; even if most apps won’t need to support 64-bit address spaces, it’d be a major mistake not to give developers the tools that they need to build 64-bit apps.

  • Resolution-independant displays. Right now, most UI elements are sized in pixels; that works great when all monitors have roughly the same DPI, but it falls down horribly when displays range from 72 to 300 DPI. Switching from a 100 DPI display to a 200 DPI display currently means that all of your UI elements (menu bar, window decorations, icons) shrink to half of their current size. Tiger has the ability to change this hidden inside the developer tools, but most apps have a hard time dealing with it right now; by the time 10.5 rolls around, I expect the OS to automatically adjust the UI size based on the DPI of the output device; this will let us have HD-resolution displays on 15-inch PowerBooks without needing to ship a magnifying glass with every new laptop.

Posted by Scott Laird Mon, 02 May 2005 20:22:43 GMT