Acme Sprockets

I've been wanting a battery-powered headphone amp for practicing guitar, so... Yesterday I decided to put one together from a few components I had around and an empty sardine can. Based on a cheap LM386-1, I think it came out pretty well. The sound is decent, but nothing like my tube amp, of course. Snazzy case, though.

This weekend I tried my new Hakko FX-888 soldering station. What an improvement over my Weller! The quality construction, small footprint, and controllable power make it a pleasure to use. This one is a keeper.

I soldered up a prototype Arduino board I'm working on in no time at all (more on that later). The joints were perfect and beautiful.

I recently wrote a program to score two different race series for my running club. Of course Ruby was a natural fit because it makes processing the textual data and arrays of scores so easy. I love it!

During a recent install of Oracle Grid Infrastructure 11.2.0.2 on Linux x64, the installer found the LUNs as candidate disks, then later erroneously reported that the storage devices were not available on all nodes while running the final checks before the actual installation/configuration. Here are the steps I followed to ensure that Oracle/ASMLIB could in fact access the devices from all nodes. This allowed me to (mostly) confidently ignore the installer "error" and proceed with the installation which then succeeded.

Sometimes it is easier to analyze data in Ruby than pulling it into Excel or OpenOffice (poor tools for statistical analysis) or the very robust R.

Original version Sun, 2007-11-04 17:21 How often an Oracle database switches the online redo logs can have a large impact on database performance. Each log switch is a synchronization point in the database and also initiates a checkpoint operation whereby the buffer cache is flushed to the data files. Oracle tends to recommend log switches of not more than every 15 minutes during peak activity periods. Realistically, high transaction volume databases may switch more often, but I don't like to see anything more frequent than 5-10 minutes.

Sometimes the simple way really is the best...

Recently I looked at a custom SQL script running during a client's batch processing. They needed to update one column on approximately 300,000 rows out of 9,000,000 on a base table. The new values were coming from another staging table that had the same primary key as the base table. Best-case, the SQL was running for several minutes; worst case (like on the Saturday I took a quick look), it was over 30 minutes. The extra long run was due to bad stats, but the SQL was an overly complex update statement with subqueries, joins, update by rowid, etc -- too complex and definitely inefficient. Setting aside the question about why a staging table at all, I suggested using an update to an Oracle inline, key preserved, view.

By using this approach, what used to run in 5-30 minutes on a large AIX server and SAN became less than a minute on my much smaller two-core Linux test server running 11gR2 (with the database on a single SATA drive).