Transcendental Generalization

On the way to the test-drive, another test driver passed me in the opposite direction. I was immediately impressed by the gaping grill, eyeliner LED headlights, muscular curves of the front end, and the apparent length of this vehicle that is the epitome of “low-slung.”

While checking in, a white Karma arrived from behind me, making a noise straight out of Star Wars. My wife and I were told that this is a synthetic sound to reduce risk to pedestrians.

On display were the two charging options for the car, one 110-volt and one 220-volt. One of the polite and knowledgable salespeople informed us that Henrik Fisker, the CEO of the company, was the designer behind the Aston Martin DB9, Aston Martin V8 Vantage and BMW Z8. Solar cells in the roof add visual interest and help to power interior features. The 22-inch rear wheels are driven by an electric motor, but the battery may be recharged by a gasoline engine.

Watching the white Karma depart, I was puzzled by what looked vaguely like chrome tailpipes. They are merely faux fixtures, apparently to complete the look of the rear end of a traditional sports car.

The door latch was a downward-facing rubber-covered button similar to those found on trunk latches. Not the classiest feel, but it definitely said, “electric.” The doors were light and frameless windows clattered a bit when closed. Not what I would expect from fine German automotive engineering.

The driver’s seat at its highest was too low for my tastes. The view through the windshield was excellent, anchored in the corners by the rises in the hood above the wheel wells. The long hood reminded me of a Corvette I once drove. Side view is also excellent as this sedan has four doors and four side windows. The minimally-sloped rear windshield yields an unfortunately narrow rear view, about a third as tall as you would expect.

The interior was free of clutter and dominated by a bright instrument cluster. This is a digital display pretending to be analog, but it has high enough resolution to pull it off successfully. In the center of the dashboard was a touch-screen display for dual-zone environmental controls and audio. Where console storage would be expected, there was merely a clear case containing colored lights.

The car has three drive modes: stealth, hill, and sport. While I would expect these to be controlled by buttons or a dial on the console, they are actually controlled by levers placed where paddle shifters are expected, which is totally counterintuitive.

We started out in stealth mode with zero engine noise. Hauling a driver and two passengers, the car did not feel as sprightly as I am accustomed to, but was certainly faster than a Prius. The suspension was stiff to the point of being uncomfortable. As soon as we got on the road, there was significant road noise.

We then switched to sport mode, and the engine revved up. Despite the salesperson’s warnings, it was thoroughly unnerving to find that the throttle was disconnected from the engine. The engine revved up or down based on the needs of the battery, and the throttle controlled the (silent) flow of power from the battery to the wheels.

We stopped briefly to take a photograph, and I sat in the rear passenger seat on the way back. The interior door latch was a simple metal button. My elbows rested high on the door handle and console, and there was minimal headroom. We switched to hill mode, which is supposed to feel more sluggish but optimized for regeneration of the battery.

Upon return, we popped the trunk to find a storage space sufficient for “a set of golf clubs.” The engine cover is hinged in the front for a sporty look.

Conclusion

This car is very strong on exterior looks and green/electric features. It has the suspension and spartan interior of a sports car, but falls short on agility. It has the four seats and doors of a sedan, but with minimal rear seating and storage space, falls short on practicality or comfort. With an $80K+ price point, I predict few of these cars will sell.

In his interview with Lynn Neary of NPR, Bill Frezza presents several bitter truths. His perspective is myopic. His choice of words is blunt. The interview was placed immediately after coverage of the Occupy Wall Street movement. This all serves only to polarize the audience between rich and poor, liberal and conservative.

Use of the “cart and horse” analogy incorrectly assumes that either employment drives growth or growth drives employment. The reality, as usual, lies somewhere in between. “Chicken and egg” is the more appropriate analogy.

It is true, as Frezza says, that businesses hire not as a public service, but to serve growing demands from customers. It is true that they are likely to put off hiring during times of economic uncertainty. The truths that Frezza seems to ignore are that customers’ demand for many products disappears when their incomes are spent on food, clothing, shelter, education, transportation and medical care. Employee productivity is also diminished if these basic needs are at risk.

So, though businesses may not have a responsibility directly to feed, clothe, shelter and cure their customers and employees, it is in their best interests to have and show concern for those needs being met.

In a truly free market, businesses that treat people as nothing more than actual or potential revenue sources are at a competitive disadvantage to those that deeply understand customer needs. And by deeply understand, I mean identify their human problems and potential, and incorporate solutions and opportunities into products and services that provide increasing value. Of course, in a free market, businesses are welcome to demand higher prices for that value, based on the law of supply and demand. Similarly, businesses that deeply understand and adapt to employee needs have access to the most productive talent, retain that talent during down times, and avoid switching costs (replacement, training and reduced productivity) from attrition.

Many businesses would actually do better to treat employees like “inputs,” but only because they currently treat employees worse than other inputs. They invest heavily in maintaining, upgrading, adapting, and even responsibly disposing of facilities and equipment. Yet, they expect continually increasing levels of productivity from employees and the right to terminate employment, all at no cost.

Mr. Frezza, I’m sorry you feel like a “whipping boy.” Earning over $250,000 a year doesn’t justify being vilified by politicians or the press. I hope you mean to say that the legitimate businessman has become a whipping boy for financial criminals. I hope you are not comparing your disparagement to the real suffering of people who have been laid off, evicted, or forced to make financial choices between basic necessities.

By covering the occupation of Wall Street and then giving voice to broadcasting the blunt words of Frezza, the media is contributing to a dangerous polarization in our society. The fact is, responsible, enlightened capitalism has worked well for our society, creating enormous wealth and high standards of living. The revolutionary sentiments of the occupiers of Wall Street should be rejected along with the myopic vision of American business presented in this interview.

While attempting to install iOS 5 Beta 7 on an iPad, I encountered an “Unknown Error” several times. After installing iTunes 10.5 Beta 7 I encountered the error again, but after unplugging the device, restarting iTunes, and trying again, it worked.

I’m a big believer in Test-Driven Development. Chris Brooks turned me on to Ruby on Rails at least six years ago, and I embraced it immediately, largely because TDD was well-supported. More recently, Chris pointed me to RSpec and Cucumber for test-driven development.

At first glance, I didn’t really see the point or the incremental benefit over Test::Unit as built into Ruby on Rails. Using RSpec involves the chore of managing additional gems, and it just doesn’t feel right to ignore the perfectly useful test/ directory and associated Rake tasks generated by every Rails project. RSpec syntax is more like English, but this seemed to promise capabilities over Test::Unit that I couldn’t see being delivered. I found the religious debate entertaining, and came down on DHH’s side. However, given Ryan Bates’s recommendation, on top of Chris’s, I kept an open mind.

Having written several RSpec specs for Rails 2.3.5 and Rails 3.0 projects, I must say, it is growing on me. Here’s why…

• Syntax: Much of the benefit I derive from RSpec is from its syntax. I am surprised that syntactic sugar could be so sweet. The describe-it-should syntax keeps reminding me that my code is meant to solve a customer problem. When I write RSpec specs, I feel I am writing an executable specification of my software. I feel I can easily and smoothly translate customer needs into RSpec specs. Traceability between test cases on the one hand and requirements (including defect resolutions) is important, and RSpec seems to provide the right amount of syntactic sugar to facilitate it. I’ve come to believe that the most important quality of code is its ability to express intent clearly and concisely. The RSpec syntax seems to support communication of intent beyond the limits of the code under test.

  The assertions of Test::Unit seem to assume lines of code did what I intended them to do. test-assert makes me focus on return values and types.

  It is a difference of orientation, like the difference between asking “Will this make my customer successful?” and asking “Did this code do what I hoped it did?”

  I know it is just syntactic sugar, but based on my background, I find the former question more productive and profitable, and the RSpec syntax orients me toward it.

  It is a bit surprising that the Rails framework generates “unit,” “functional,” and “integration” directories, while RSpec documentation recommends “model,” “controller,” “view,” and “spec” directories. Given the difference in syntax orientation, one would expect the opposite. However, the RSpec approach definitely feels comfortable.

• Mock objects: RSpec’s incremental benefit over Test::Unit is its inclusion of mock objects. Test::Unit can easily use mock objects, but they are not built in (I think). To be honest, I never really understood mock objects until I found them in RSpec and tried using them in my specs. Now, they seem indispensable, well worth the management of additional gems.

The jury is still out on Cucumber. When I gave it a solid try, I found it hard to start. Should I specify high-level, non-technical features and capabilities or low-level, technical expectations? Both are important, so how and where should they live? Perhaps I should start a new development project with Cucumber tests, rather than trying to add them to an existing project.

This is on Mac OS X Snow Leopard.

I discovered this morning that a couple of my VirtualBox virtual machines would not start. Double clicking on the name did not work, and the “Start” button remained dim when they were selected.

I ran Disk Utility, selected the hard drive where my VMs were stored, and clicked “Repair Disk Permissions”. After a few minutes of repair work, the virtual machines were unlocked and worked fine.

I just got Chromium OS running on a VirtualBox on a Mac OS X Snow Leopard (10.6.7).

I downloaded Ubuntu Linux 10.4 64-bit and got it running on the VirtualBox. I had to allocate a 50 GB disk for this virtual machine–20-25 GB was insufficient.

Following the instructions for building Chromium OS here, I successfully reached the execution of ./image_to_vm.sh --format=virtualbox. This particular script failed at the very end because it expected VBoxManage to be installed locally (which it wasn’t).

I transferred the 3.22 GB vm_temp_image.bin to the host Mac using SFTP, then ran
VBoxManage convertfromraw vm_temp_image.bin vm_temp_image.vdi --format VDI

Then, I created a new VirtualBox VM. For Operating System, I selected “Linux” and for Version, I selected “Ubuntu”. For Base Memory, I selected 1024 MB. For Virtual Hard Disk, I selected the existing hard disk vm_temp_image.vdi I had just generated.

IMPORTANT: I then had to fix the network settings. I selected Adapter 1, Attached to: Bridged Adapter, Name: en0: Ethernet. Under Advanced, I selected Adapter Type: “Intel PRO/1000 MT Desktop (8254OEM).

Ten seconds after clicking Start on the virtual machine, I got the initial setup prompts!

For a work project, we needed the locations of all US Apple Stores. I couldn’t find a list, so I decided to “scrape” Apple’s site for the addresses. Less than 20 lines of Ruby did the trick:

#! /usr/bin/ruby

require 'open-uri'

open("http://www.apple.com/retail/storelist") do |file|
  file.read
end.split("<a href=").map do |seg|
  (match = seg.match(/"\/retail\/([a-z0-9]+)/)) ? match[1] : nil
end.compact.each do |loc|
  contents = open("http://www.apple.com/retail/#{loc}/") do |file|
    file.read
  end
  puts [
    /\<span class="street-address"\>(.*)\<\/span\>/,
    /\<span class="locality"\>(.*)\<\/span\>,/,
    /\<span class="region"\>(.*)\<\/span\> /,
    /\<span class="postal-code"\>(.*)\<\/span\>/
  ].map { |pat| contents.match(pat)[1] }.join(", ")
end

I’m always wary of using temporary variables (in this case, match and contents) but I couldn’t figure out a way to avoid them.

I recently worked on a web site which let users set up a personalized web page, including a Facebook Like button and a Twitter Tweet button.

We needed to determine how many likes and how many tweets each personalized web page got—without visiting each site and noting the count by hand.

This site had the solution for Facebook likes. Let’s say your page, containing like and tweet buttons is at http://the.url.com. Simply type the following at the command line:

curl "https://api.facebook.com/method/fql.query?query=select%20%20like_count%20from%20link_stat%20where%20url=%22http://the.url.com%22"

You’ll get back an XML document containing the like count.

For Twitter, I had to reverse-engineer their button code. Simply type the following at the command line:

curl "http://urls.api.twitter.com/1/urls/count.json?url=http://the.url.com"

You’ll get back a JSON document containing the tweet count.

I’ve been enjoying the services of Heroku recently. Heroku exemplifies cloud computing for developers, with simple tools to deploy your Ruby on Rails application.

While uploading a development database to Heroku, I encountered the following error:

75% |================================== | ETA: 00:00:06
Saving session to push_201102111450.dat..
!!! Caught Server Exception
HTTP CODE: 500
Taps Server Error: PGError: ERROR: invalid byte sequence for encoding "UTF8": 0xae
HINT: This error can also happen if the byte sequence does not match the encoding expected by the server, which is controlled by "client_encoding".


Google searches failed to discover an easy fix.

To elaborate on the error a bit, my database contained a byte sequence that Heroku’s Taps Server did not allow under UTF-8 encoding. I’m not sure how this byte sequence got in. My SQLite database also used UTF-8 encoding, but apparently SQLite had been more tolerant of byte sequences when I imported the data.

In any case, it was worth noting that I had a progress indicator (“75%” above) on the specific table that contained the bad byte sequence.

When I viewed the table in a web page and scrolled down approximately 75% of the way down, I found some strange characters. When I edited the offending characters out of the table, the database push worked.

Of course, the web page view had to use the default ordering of the data. I was lucky that the run-time ordering of the data (used in my web page view) was the same as the push-time ordering of the data.

At my new job, I got a very nice new MacBook Pro 2.66 GHz Intel Core i7 with Snow Leopard (OS X 10.6.3) preinstalled. In order to support a legacy app, I needed to install Rails 2.3.3. Needless to say, it was problematic…

OS X

A standard Apple Menu → Software Update upgraded the OS to 10.6.6.

Ruby and Rubygems

These were both preinstalled as confirmed by the following:

$ ruby -v
ruby 1.8.7 (2009-06-12 patchlevel 174) [universal-darwin10.0]
$ gem -v
1.3.5


MySQL

I downloaded mysql-5.5.8-osx10.6-x86_64.dmg from here and installed it. There were two problems. First, on login, I saw a dialog box as follows:

The solution was here:

$ sudo chown -R root:wheel /Library/StartupItems/MySQLCOM

Second, starting MySQL from the system preferences pane had no effect. The Console revealed the following error:

2/2/11 8:49:49 AM [0x0-0x16016].com.apple.systempreferences[179] /usr/local/mysql/support-files/mysql.server: line 256: my_print_defaults: command not found


The solution was here:

Rails

This was easy:
$ sudo gem install rails --version 2.3.3
Successfully installed rails-2.3.3
1 gem installed
Installing ri documentation for rails-2.3.3...
Installing RDoc documentation for rails-2.3.3...

MySQL Gem

This was the tough part.

First, I had to download and install XCode to get the required header files. The latest version was xcode_3.2.5_and_ios_sdk_4.2_final.dmg which requires OS X 10.6.4. It’s faster if you can install it off your system DVD.

After that, the following command worked for me:

export ARCHFLAGS="-arch x86_64" ; sudo gem install --no-rdoc --no-ri mysql -v 2.7 -- --with-mysql-dir=/usr/local --with-mysql-config=/usr/local/mysql/bin/mysql_config

The ARCHFLAGS reflected the 64-bit Ruby and MySQL I am running. The –no-rdoc and –no-ri served to suppress several warnings. The 2.7 version was (apparently) required for the 2.3.3 version of rails.

IMPORTANT

This was still resulting in errors, but then I found this post. The following command needed to go into my ~/.profile file to run every time I fired up a terminal:

export DYLD_LIBRARY_PATH=/usr/local/mysql/lib/

Now, I am able to run rake tasks and script/server.