The dreaded binary error has bitten me…

“The binary you uploaded was invalid. The signature was invalid, or it was not signed with an Apple submission certificate.”

Okay, in one case, it was actually valid, as I had been using an icon file that wasn’t named Icon.png and wasn’t 57×57.  Thanks to Sean for helping me with that.

But today, it was totally bogus.  I made a trivial change for a resubmit of my PrivateWeb app, and the binary was rejected.  Clean the project & rebuild, still hosed.  Restart XCode, still hosed.  Go to the finder and remove every folder from my project’s build directory and then build again – and it WORKED???  WTF?!

Ahem.  I’m glad it worked, but seriously…  There’s something buggy in XCode land.

It saddens me to say, but after a year of fiddling with Apache Derby, working around its quirks, making a custom statement cache so that it’s not so frickin’ slow, that it’s finally time to call it quits and move on to something else.

Data corruption… Over the past year, I have been using Derby as an embedded database inside of Fubario. I’ve been running it on Windows2000, WindowsXP, and OSX 10.4. On all of these OSes, some are laptops, some are desktop machines on all the time, I’ve had varied data corruption scenarios occur, even under relatively little load.

I will admit, I haven’t done a good job keeping records of each kind of data corruption, probably because of foolish optimism that when a big point release of Derby came out it would have solved the problems with the prior version. But alas, every release has had various things go wrong. I’ve had entire databases corrupt so that Derby would refuse to startup, or even an interesting “poison table” corruption where everything was fine until I issue a query against a particular table that was corrupt, at which point Derby went out to lunch.

And when I say little load, I mean pretty much the databases were idling 24×7, with maybe a few thousand rows in them. And to think that I switched to Derby specifically to get more reliability than I had been having with hsqldb or its shiny new cousin h2…

So where am I now? I’ve built a custom flat-file store for Fubario for storing encrypted backup files. It’s pretty simple, really, with a few key characteristics of secret sauce that make it perfect for Fubario and it’s really tiny in terms of amount of code, because it doesn’t have to do very much at all. I’m also using h2 again for storing maybe tens of properties or something like that, miniscule really, probably could use properties in a flat file, but I’m just reusing the sql-driven classes that had been talking to Derby.

I’m done with the 20 second startup and shutdown times.

I’m done with these random and varied and all peculiar data corruption scenarios.

I’m done with foolish optimism? Maybe.

The electronic catalogs for my nearby public libraries are pretty basic. They are the same boring Horizon Information Portal websites that provide the basics but sifting through the results is clumsy. And searching another library at the same time? Forget it.

Enter WorldCat. Searching a library is, dare I say it, fun again! Everyone can add reviews to library items ala Amazon, it automatically shows you nearby libraries that have the item using guesstimated location based on your IP, and they make money by providing links to Amazon if you’re too lazy to go get the book from a library yourself. Very well done… I’m jealous.

I still wish I could find my library search engine that I made back at UIUC in 1994. It was the capstone project for, of all things, CS411 Database Systems. The professor was dating/engaged/married to Eric Bina who was the co-creator of Mosaic with Marc Andreessen. And so apparently she liked the idea of making her databases class build a web application. I was fine with it, really, because Mosaic was pretty cool, although I found myself always keeping 2 windows open and dragging links from one to the other so I wouldn’t lose my place while I wandered about. Kind of a kludgy coping mechanism before the era of tabbed browsing.

I came up with the idea for my team of 3 to build a web interface to the UIUC library system, which was a mainframe beast, maybe 3270 but I’m not sure. Luckily one of the guys on my team had build the TCPSETUP program for Doom, so he was good at making socket programs and so he built a library for talking to the mainframe. I built out the perl-based webapp which took care of sessions, form-processing, calling the library to talk to the mainframe, rendering the search results, etc. The other guy, um, didn’t do anything.

Even though I didn’t have a name for it (usability) I worked hard to make the webapp easy, even fun, to use. You typed in a search by author or title and would get back a list of results all nicely lined up with information about each match. Click on a book to see more details, and best of all, get a form where you could put in your school ID and the library would send the book to your dorm room! For real!

Every team presented their final projects during the last week of class. Other teams had built basically useless apps, all were clunky, didn’t make sense, whatever. We presented ours to applause, actually, but apparently our professor was not impressed. “It looks too easy”, she said. That was the goddamn point! The back-end work to screenscrape multiple greenscreens for every page view was nutso stuff, and yes, the front end looked smooth & clean. She gave us a B. And that was when I knew that all those people who had told me that “grad school was when you start doing real work, no more theory crap like undergrad classes” were out of their minds. I had worked my ass off to build something real, and got a frakkin’ B for my troubles.

Postscript – a few weeks after this class ended, the webmaster for UIUC heard about my library webapp and asked if she could install it on the library website. It became the official library web search engine running at UIUC for the next several years. Yeah, that sounds like B-level work to me… Adios, grad school!

A week or so ago, I read Tim Bray’s post about X-Me on Facebook being a virus, and I had to respond, being one of the “little guys” that has low usage numbers. A friendly Google tech recruiter read my post, found this dusty blog, wandered over to CLG where I work, and emailed me to ask if I had any interest in working for Google.

At first glance, seems kind of cool. But I’m not moving to California, as I’ve got all my family and extended family in the Chicago area. The recruiter kindly mentions that they have a Chicago office. Nice! Let me google them up…

*stomach lurches*

It appears that the Chicago office for Google is essentially an ad sales office (fine) with 3 developers who work in a corner. The developers are (mostly) the people behind subversion, which is one of my least favorite technologies that exists right now. I am struggling to understand why so many people are in love with it, apache/jakarta is switching their projects to it, and yet CVS works just fine, barring some warts. Eclipse covers up most of those warts, and since I breathe Eclipse 24×7, I’m fine with it.

But subversion… Well, I am one of the few non-believers, apparently. It was forced on me at CLG (long story), and turned out to be slooooooooow, taking 5 minutes to sync our projects, vs maybe a minute or less with CVS. It must take extra time to not do keyword substitution (j/k) which okay, I don’t like that CVS does, but whatever.

The big one for me is that subversion crapped out on me. Our repo server died, and I had a backup on another box, but apparently one of the files had some kind of strangeness in it, such that svn couldn’t read it. Um, okay, well that’ll just break one file, right? Nope. Entire repo, dead. WTF? You gotta be kidding me. An error in a single file kills my entire 6-year commit history??? And the error was caused by svn’s file handling, as far as I can tell, as I googled for it and a few other people had the same problem. When they asked the developers about it and showed them the corrupt file(s), the developers’ answer was, “that can’t happen” (paraphrasing). Um, except it did. To him. And me too. To be fair, the developers went on to try and fix the problem(s). But problems that are this varied, complex, and almost impossible to reproduce on demand are unlikely to be completely resolved. The bottom line is, the svn guys have made their own database thang for storage, and it sometimes blows up, taking your entire repo down with it. Not cool.

Don’t tell me I should have had more backups going further back in time – that’s a cop out. I had backups, but they were useless because one file in the middle was busted. Unacceptable.

No subversion for you! Er, me. I’m sticking with good ol’ CVS, which sucks a little, but it’s a devil I know, with warts I know, and if I back up the files for it, then I know goddamn well that I’ve got a reasonably good backup of my repository even if there’s a twiddled bit in there somewhere due to disk failure or whatever.

So I was compelled to mention my anti-svn feelings to the recruiter, in as friendly and upbeat a way as I possibly could, and I asked about working on other projects or remotely for another office, and haven’t heard back. So methinks, no interview for me. Could have been an interesting experience, but seeing as I hate goofy interview questions/riddles about manhole covers, numbers of gas stations, and any of those moving Mt Fujiisms, it might be for the best.