Does OpenOffice Base suck?

Is it just me, or does OpenOffice Base (the database tool in their suite) suck? Or maybe it just sucks on the Mac? Honestly, I'm not throwing bombs just to be a tool. If I'm doing something wrong, please tell me.

For some time I've been looking for a database tool along the lines of Access, but which runs on the Mac and possibly other platforms. It's not that I'm a big Access fan - I've only used it a time or two, but every now and then, I have a task that cries out to be implemented with a database. Creating a desktop application from scratch using something like Swing and JavaDB/Derby seems like overkill (not too mention, way too much work), but I've always thought that there should be a database tool that's based on Java (cross-platform) and some open-source database (e.g., Derby or SQLite).

On paper, Base is just that tool. I heard somewhere that it's written in Java, and I know that it uses HSQLDB, but can use any JDBC database. Looking through the interface it's got tables, forms, and reports. And OpenOffice runs on Macs, Windows, and Linux. Sounds perfect.

Here's just a short list of the issues I've had:

• The first time I ran it, it crashed before I'd even defined any tables. D'oh!
  
• Once, the UI locked up (no visible updates but the mouse still worked) while I was trying to add a List Box. I kept trying until it crashed. When it came back, I had a zillion List Boxes in the spot where I was adding them.
• After removing the List Boxes, it crashed again. After restarting, the recovery process restored all those list boxes. I removed them all again, it crashed again, and they were all restored again.
• Eventually, I removed the List Boxes, saved and quit. After restarting, the boxes were finally gone. This marked a new work pattern - save and quit every ~5 minutes. Sometimes, saving alone wasn't enough to prevent work from being lost.
• The replace form control function crashed consistently enough for me to realize it doesn't work. This is a shame because the form wizard creates text boxes by default, which need to be converted. I had to add new controls, wire them up, remove the original text box, and move the new control into place - all while saving frequently.
• It took me forever to get a List Box that wasn't tied to a database table or query - e.g., Gender can only be Male or Female (or Gelded on our farm). To do that, you have to turn off wizard mode.
• There are various UI boogers on the Mac - e.g., list boxes are sometimes not quite tall enough so the text in the box is chopped when the list is not dropped down.
• The documentation that I could find was minimal, at best. I realize that's a common complaint about open-source projects, but for something as big as OpenOffice, I expected more.
  

Anyway, it's so unusable, I don't think I can use it for my own personal purposes, let alone recommend it to clients. Quite a shame. I'm thinking to checking out FileMaker. It runs on both PCs and Macs, and it has a free 30 day trial.


Charles.

Talk: How To Protect Yourself and Your Computer Online

This is a talk I recently gave at the Monmouth Senior Center. Nothing earth-shattering for techies, but useful information for the non-techies in town.

How To Protect Yourself and Your Computer Online

View more presentations from Charles Anderson. (tags: securityonline fraud)

Cell Phone (EVDO) for Rural Internet Access

The name Western Skies (name of this blog and my consulting company) comes from song "Western Skies" by the late Chris LeDoux where he talks about living out west (Wyoming) rather than in Nashville. Similarly, I choose to live out in the country in Oregon instead of Silicon Valley. On the plus side, I have "watch(ed) an eagle fly" (in town, no less) and listened to "the coyotes call at night." On the minus side, there is no broadband Internet access out here. I've recently switched to Verizon EVDO service, and it's mostly working. This is the first of a series of posts on the subject of using EVDO for our sole Internet service.

Previously, I was using 128Kbit (16 Kbyte) per second ISDN. It cost $85/month, which means it was slow and expensive, but the data amount was unlimited. Also, it was a business service from Qwest, which meant when it went out, they were Johnny on the spot to fix it - they even asked at 9pm if it was OK if they didn't roll a truck until morning or if I needed it fixed that night.

I had been thinking of switching for some time, but Qwest forced my hand when they notified me that they would no longer serve as an ISP for the ISDN line. They still provide ISDN service, but their ISP (Qwest.net) no longer accepts ISDN calls. To add insult to injury, they suggested that I see if DSL was available - if it were, there's no way I'd suffer the indignity of ISDN! I could have changed ISPs, but the ones I found all charged more and/or had usage limits expressed in hours per month (not MB/GB, just hours of connect time).

Since there's no DSL or Cable, the only other contender would be satellite. However, at times, I do a lot of work at the command line via ssh, and the latency of satellite would have been completely impractical. A neighbor of ours has it, and she says she can't even run IM over it very well.

When we first moved out here, there wasn't hardly any cell phone coverage. Mostly our phones just spent their batteries looking for signal. Then, Verizon put up a tower that we can see from our driveway - a pretty clear line-of-sight. Our Sprint cell phones get 4 bars of (roaming) signal, except when they catch wind of 1 bar of Sprint, which they'll chase blindly.

After checking out Verizon's offerings online and talking to a sales rep, I signed up for service and "bought" a UM 175 EVDO modem (free with 2 year contract) at Costco (to save on the activation fee). Verizon offers a 30 day trial, which I figured I'd use to test things out before cancelling the ISDN line. Even though our phones got a strong signal, I wasn't certain that the data signal would work. Of course, you'd think that if a telco bothered to put up a tower (or an antenna on someone's leased tower), they'd provision it with all the latest features (e.g., EVDO), but then again telcos don't always behave rationally.

To make a long story short, it really does seem to work. The bandwidth is much better - I see anywhere from 100KB/sec to 800KBps with 100-300 KBps being common. Not great compared to the fiber in town, but much better than 16KBps. Ping shows the latency being pretty large (150-250ms), but it seemed alright when I tried it over ssh. (I'm no longer working for the client where I was using ssh full-time, so I haven't really put it to a real test.)

However, and this could be huge, the 5GB/month cap is problematic. In theory, our regular email and web surfing fits well within that limit, however that doesn't leave much room for podcasts or video (which I never got into on ISDN, anyway.) The cap works out to ~170MB per day, and many podcast episodes are ~50MB. So, I'm still trying to figure out how to live with the cap - giving up podcasts is not an option.

At some point, I'll post about my experiences setting up the Verizon UM 175 USB modem on a couple of Macs, as well as my new found hobby: Podcast Mule - downloading podcasts (and OS updates) from WiFi access points in town and bringing them home on my laptop.

Charles.

Speaking on Groovy again

I'll be repeating my talk on Groovy at noon on February 3rd at noon in Salem, Oregon. From the email notice:

This presentation will be in Information Systems Division conference room on the first floor, suite 103, of the State Public Service Building. Here is a Google Map link for the location.

Parking on Court and Capitol streets is the closest to the Public Service Building. The spots are metered.

Maybe I'll see you there,
Charles.

P.S. My slide deck will be almost identical to the last Groovy talk, so I won't be posting a new one.

Converting a WordPress blog to a 'One-Click Install' on DreamHost

We set up a WordPress blog on DreamHost a while ago for a client. It was a custom install due to a bunch of craziness related to him getting booted from his old hosting setup. It all worked fine, and then DreamHost sent me a "nag email" (their term) asking me to upgrade because the old version had security issues. Fair enough.

I had another site to upgrade, but it had been installed as a one-click install. The upgrade for that was one click (plus some backing up). I could have manually upgraded this custom install, but if I did that, I knew I'd have to continue doing manual upgrades. Therefore, I wanted to convert this custom WP install to a one-click install.

DreamHost didn't seem to have any instructions, but how hard could it be? Basically, the procedure was pretty similar to what you'd go through to move a WP from one server to another.

1. Backup the database and the old site: I backed up the old DB using mysqldump, and I tarred up the old site.
   
2. Export the old site: from the WP admin page, select Export and dump all authors.
   
3. Create a new database in the DreamHost control panel. In theory, you could drop all the tables in the old DB and re-use it, but I was being paranoid, which paided off later.
   
4. Move old site out of the way: just move the old site directory to a new name - e.g., mv site.com save.site.com.
   
5. Create a new 'One-Click Install' WordPress site using Advanced Mode, since we had a custom theme and a bunch of other content (pictures). This was put in the new database. After DreamHost emailed me to tell me that was done, I logged in and changed the admin password.
   
6. Import the old content from the Admin Import function. Actually, DreamHost's email included the URL for that page. One issue I ran into was the "user name" for the old posts: WP thought the old posts by admin were from some other user because in the old blog, the admin user had a different display name.
   
7. Copy in the custom theme and other content from the old saved directory into the new blog site. Enable the theme. Set up Akismet - this is where having the old DB around was useful; I just looked in the wp_options table to find the API key instead of having to dig around for it.

enjoy,
Charles.

Jython talk at SJUG

Here are the slides of a talk I gave last February at the Salem Java Users Group - SJUG. Although it looks like it's primarily about Python and Jython, my bigger emphasis was on extension programming - scripting existing Java code. In other words, a form of polyglot programming.

Jython: Integrating Python and Java

View more presentations or upload your own. (tags: jython python)

Enjoy,
Charles.

Book: Java Power Tools

Java Power Tools by John Ferguson Smart
ISBN: 978-0-596-52793-8

Java Power Tools provides a fairly detailed introduction to a number of tools for Java programmers. It fits nicely between the O'Reilly Hacks series and having a dozen books like Ant: The Definitive Guide, 2nd Edition. Like the Hacks books, Java Power Tools provides an introduction to a bunch of tools. The Hacks books are great for answering the question "I've heard of that tool, but where does it fit?" But whereas the Hacks books provide just an appetizer, this book provides a main course, enough to get seriously started with the tool being discussed. And then, if you want all the gory details, a Definitive Guide could provide the full five-course meal.

The selection of tools presented was really good, at least for me. For example, I know about continuous integrations servers, but I haven't set one up. At one client site, they were using Hudson, which I had some exposure to, but didn't know much about the others like Cruise Control, Continuum, and LuntBuild. Similarly, I've been using JUnit 3.x for years, but I didn't really know what was different in JUnit 4 or how that compares to TestNG. This book provided me with a great overview of these and other tools. Java Power Tools provides a great way to get up to speed with a general area of tooling (e.g., continuous integration servers) or a good cross-section of the majority of the Java tools in use today.

If I had to pick something to complain about, it would be Part II - Version Control Tools. These aren't really Java tools, although every programmer (Java or otherwise) should be using them. Or given the decision to include version control tools, I'd suggest excluding CVS because it's old and including at least one distributed version control tool like Mercurial (used by the Open JDK project and NetBeans) or git (used by the Linux kernel).

So, in conclusion, unless you have no free will about tool selection or you already know all of these tools backwards and forwards, I highly recommend this book to almost any Java programmer.

enjoy,
Charles.

Groovy at SJUG

On January 6th, I spoke at the Salem Java Users Group on Groovy. The premise was not to replace Java, but rather to show how it can be used in addition to Java. Here are the slides.

Groovy a Scripting Language for Java

View more presentations or upload your own. (tags: java. groovy)

Enjoy,
Charles.

Book: The Productive Programmer

The Productive Programmer by Neil Ford
ISBN: 978-0-596-51978-0

I've always had a more-than-passing interest in productivity porn, as Merlin Mann calls it. I'm not obsessive about seeking out productivity books (I can quit any time), but I've read more than a few such books in my day, and I do keep my tasks organized with OmniFocus. When I saw The Productive Programmer at the Powell's table at OSCON 2008, I confess I got pretty tingly, kinda like "when we used to climb the rope in gym class." Here was a book talking about productivity aimed specifically at what I do every day - programming, not management, not sales, not coaching a football team, but programming. In the words of Cartman, "sweet."

That said, I wouldn't classify this book as hard-core productivity porn. It doesn't lay out a dogmatic formula, nor does it suggest or require specific tools or techniques. And that's probably a good thing; in my experience, programmers can be some of the most opinionated people I've known, especially when it comes to their craft (e.g., editor wars). If the author had attempted to prescribe a specific set of practices, I think almost every programmer would have found something to hate about the book, and what's the point of that - we could just as easily go back to ragging on emacs, Windows, or Steve Jobs.

Instead, Mr. Ford offers a number of possible suggestions that one can take or leave. These are organized into two parts: mechanics (the productivity principles) and practice (philosphy), or what I would call tactical (little picture) and strategic (big picture) techniques. Mechanics includes things like controlling interruptions from things like email and using tools like Quicksilver (which I finally started using after reading this book). Philosophy includes things like test-driven development/design (TDD) and using things like static analysis tools.

The various suggestions were all very well and good, but what I liked most about this book is that it made me thing about mom-and-apple-pie topics like TDD (of course, we all write unit tests, right?) from a totally different angle - productivity. Of course, that what the agile folks have been saying all along, but somehow this book shed a whole new light on it and helps drive it even deeper. And the whole book got me thinking about the bigger question - "how can I be more productive and effective in my programming?"

Like I said, this isn't hard-core productivity porn, but it's a very useful and approachable guide to productivity by a programmer for programmers. Maybe that makes it productivity literary erotica?

enjoy,
Charles.

In Praise of TDD and Mocking

As noted elsewhere in the blog, I've been doing a bunch of work to script ESXi using Vmware's (sometimes troublesome) RCLI tools. I'm developing a higher-level set of code written in Python. (In theory, using Vmware's Perl toolkit would be cleaner, and I wouldn't have to bitch about the RCLI tools, but I've done enough Perl for one lifetime.) In addition to the mom-and-apple-pie goodness of TDD, I'm also getting a huge productivity boost by employing TDD via mocking.

In the code I'm writing, each method typically makes one or more RCLI calls. Each RCLI call takes 3-5 seconds. I structured the code so that the RCLI invocations all funnel through one point in the code which can easily be monkey-patched to go through a mock function. (More details on that in a later post.) After mocking, the result is that I can execute 20 tests with dozens of mocked RCLI calls in less than a tenth of second. After the unit tests pass, I can push the code out to a real host and run real RCLI comannds, and for the most part, "it just works."

When I started, I figured mocking was the only way to unit test this code, and it was more convenient to develop the code on a machine where I don't have the RCLI installed. The performance boost was unexpected but by far the most significant benefit of the unit tests. And when I needed to perform a couple of refactorings during the development, I got to enjoy wicked fast speed plus safety - two great tastes that taste great together.

Charles.