Acme Sprockets

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.

Though there is no single command to drop all of the tables in a MySQL database, it is pretty easy to do with a simple script.

My approach to the User Experience (UX) design is that form should follow function. I much prefer well-organized and easy to understand content over “pretty” graphics that some web designers will use in an attempt to wow us all with their artistic skills. That is not to say that sites have to be as plain as Craigslist (which is quite functional), but navigation and consumption of content should intuitive.

I was recently asked about backing up a MySQL database for a remotely hosted Drupal site. Assuming you have SSH access to the hosting account, this is trivial to do from a Linux machine.

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.

Randall has once again crafted a superb data visualization. His Radiation Dose Chart simply and effectively conveys a lot of information that is unfortunately very useful. I highly recommend that you take a look for the content, and for a great example of how to concisely and clearly represent comparative data.

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).

Linux provides a robust operating system and rich environment. While I use a Windoze XP-based laptop at the office, and a MacBook Pro for iOS development, my primary home system runs Linux (Ubuntu 10.04 at the moment). It has everything I need including office applications (OpenOffice), software development tools (Java, Eclipse, PHP, Ruby, C/C++, Perl, etc.), databases (Oracle, MySQL, and PostgreSQL), home finances (Gnucash), photo management tools (Digikam, Gimp), etc.