What's That Noise?! [Ian Kallen's Weblog]

All | LAMP | Music | Java | Ruby | The Agilist | Musings | Commute | Ball
Main | Next month (Sep 2006) »

20060830 Wednesday August 30, 2006

Eclipse Aviation

Last week I was in Albuquerque for some family time and relaxation. It was truly wonderful to see the desert in full bloom; the monsoonal flow of weather coming up from the Gulf of Mexico this time of year has brushed the whole landscape with lovely shades of green. The weather was mild, the raspberries lucious and abundant and, though the trout weren't biting, the rivers roared beautifully; it was really great. No, I didn't accept payola from the New Mexico visitors bureau, really, my gushing is legit.

Anyway, I also took the opportunity to do some geeky oogling at the Eclipse Aviation facility in Albuquerque. I'm not normally an airplane nerd but last Friday, I was. What interested me about this company is that they are producing a truly disruptive technology. Commercial aviation and metropolitan airports are high ceremony affairs; security lines, taking off your shoes and taking out your laptop, finding the right carousel to get your luggage... and praying that it shows up there in tact. The Eclipse jets will commoditize high altitude cruising in a pressurized cabin at speeds that aren't too far behind the big boys (and twice the speed of propeller planes) and do so at a price point on par with the cost of many single family homes in the San Francisco Bay Area. What will that mean for you? What would it mean to you if 2 to 3 hour rides up and down the west coast of the United States are cheap and abundant? If a two day drive or commercial jetliner and airport rigamarole can be replaced with fast, low ceremony travel, then the world gets a lot smaller again. That would mean a lot to me! Welcome to reality, the smaller world where commodization is good.

Eclipse is a newcomer, a startup (I know bit about disruptive startups) in the aviation industry. As you'd expect, they're doing things differently. Which isn't a surprise given founder Vern Raburn's pedigree. Raburn is an early Microsoft and Lotus guy, has been a pilot since he was teenager and has a passion for innovation (along with some cash to throw behind it). Eclipse's friction stir welding process for joining the aluminum shell results in a light but strong hull (without relying on composites); most planes are pieced together with rivets. Eclipse has extensive IT infrastructure that provides flight plans, collects metrics on the planes while they're in flight, detecting component failures and poised to assist from a state-of-the-art operations center. The avionics are displayed on redundant touch screens and the controls are vastly simplified over what you find in traditional aircraft. Here are some specs on the Eclipse 500:

So, do the math and this works out a lot cheaper than flying most piston engine planes (costs per hour may be lower but you're in the air twice as long with those). OK, I admit I don't have one and half mill to drop for one of these babies (however, I have aspirations to be a "qualified buyer") but still, the potential to bring this kind of travel within easy reach is at hand. Even if you don't buy one of them, using one like you'd use a cab seems like huge improvement over current modes of air travel. On your next trip, as you endure the TSA confiscating that toothpaste you forgot was in our carry-on luggage, imagine jet travel that operates more like a car service, like a cab. DayJet is going to provide exactly that using fleets of Eclipse jets. On the factory floor, I saw a few DayJet-logo'd planes getting prepped for delivery. Apparently a gaggle of "air taxi" services similar to DayJet are in the works, they'll also be powered by fleets of Eclipse 500's. We'll embark on the era of very light jets (VLJ), when the first customers start taking delivery of their aircraft within the next month. This may not be Kitty Hawk but I do think this will be rank high in the list of significant aviation events.

         

( Aug 30 2006, 09:09:06 PM PDT ) Permalink


20060829 Tuesday August 29, 2006

Scammed By Kleptotorial

In this corner: Doc is going to attack kleptotorial splogs by employing cleaner living through better licensing (a creative commons flavor). And in this corner: Elliott Back says he is a victim. He has been slammed by Scoble (and Scoble was gracious enough to apologize). I have no sympathy for Elliott Back. Sure, he's just the gun maker, not the shooter. But weapon makers producing wares without safeties get sued for negligence. Basically, any tool that programmatically harvests and posts other people's feeds should at least have the common decency to not ping. If you re-inject something into the update stream that you've appropriated from someone else, you're scamming the update stream. This isn't about quoting or citing, this is about fraudulent pings, "I've updated my blog (nevermind the fact it's with OPP)" -- keep your feed harvesting to yourself, please.

( Aug 29 2006, 09:51:57 AM PDT ) Permalink


20060828 Monday August 28, 2006

Memcached In MySQL

The MySQL query cache has rarely been of much use to me since it's a pretty much just an optimization for read-heavy data. Furthermore, if you have a pool of query hosts (e.g. you're using MySQL replication to provide a pool of slaves to select from), each with its own query cache in a local silo, there's no "network effect" of benefitting from a shared cache. MySQL's heap tables are a neat trick for keeping tabular data in RAM but they don't work well for large data sets and suffer from the same siloization as the query cache. The standard solution for this case is to use memcached as an object cache. The elevator pitch for memcached: it's a thin distributed hash table in local RAM stores accessible by a very lightweight network protocol and bereft of the featuritus that might make it slow; response times for reads ands writes to memcached data stores typical clock in at single digits of milliseconds.

RDBMS-based caches are often a glorified hash table; a primary key'd column and value column. Using an RDBMS as a cache works but it's kinda overkill; you're not using the "R" in RDBMS. Anyway, transacting with a disk based storage engine that's concerned with ACID bookkeeping isn't an efficient cache. MySQL has the peculiar property of supporting pluggable storage backends. MyISAM, InnoDB and HEAP backends are the most commonly used ones. Today, Brian Aker (of Slashdot and MySQL AB fame) announced his first cut release of his memcache_engine backend.

Here's Brian's example usage: 

mysql>  INSTALL PLUGIN memcache SONAME 'libmemcache_engine.so' ; create table foo1 (k varchar(128) NOT NULL, val blob, primary key(k)) ENGINE=memcache CONNECTION='localhost:6666';

mysql> insert into foo1 VALUES ("mine", "This is my dog");
Query OK, 1 row affected (0.01 sec)

mysql> select * from foo1 WHERE k="mine";
+------+----------------+
| k    | val            |
+------+----------------+
| mine | This is my dog |
+------+----------------+
1 row in set (0.01 sec)

mysql> delete  from foo1 WHERE k="mine";
Query OK, 1 row affected (0.00 sec)

mysql> select * from foo1 WHERE k="mine";
Empty set (0.01 sec)

Brian's release is labelled a pre-alpha, some limitations apply, your milage my vary, prices do not include taxes, customs or agriculture inspection fees.

What works
  • SELECT, UPDATE, DELETE, INSERT
  • INSERT into foo SELECT ...
What doesn't work
  • Probably ORDER BY operations
  • REPLACE (I think)
  • IN ()
  • NULL
  • multiple memcache servers (this would be cake though to add)
  • table namespace, right now it treats the entire server as one big namespace
The memcached storage plugin runs against the bleeding edge MySQL (Brian sez, "You will want to use the latest 5.1 tree"). What's most exciting about this is using it in combination with MySQL 5.x's support for triggers. A cache entry stored from a query result can be invalidated by a trigger on the row that provides the cache entry data. AFAIK, that's exactly how folks have been using pgmemcache in PostgreSQL but I haven't had a chance to mess with that yet. Anyway, check out Brian's list announcement and post about it, kudos to him for hacking on this, I imagine this will add a lot of value to the MySQL user community.

     

( Aug 28 2006, 07:18:13 AM PDT ) Permalink


20060827 Sunday August 27, 2006

Stupid Object Tricks

When I wrote about OSCON last month, I mentioned Perrin Harkins's session on Low Maintenance Perl, which was a nice review of the do's and don'ts of programming with Perl, I really didn't dig into the substance of his session. Citing Andy Hunt (from Practices of an Agile Developer):

When developing code you should always choose readability over convenience. Code will be read many, many more times than it is written. (see book site)
Perrin enumerated a lot of the basic rules of engagement for coding Perl that doesn't suck. Some of the do's and don'ts highlights:
Do's
  • use strict
  • use warnings
  • use source control
  • test early and often, specifically recommending Test::Class and smolder
  • follow conventions when you can
...mostly no brainers and yet a lot of Perl programmers are oblivious to basic best practices.
Don'ts
  • don't use formats (use sprintf!)
  • don't mess with UNIVERSAL (it's the space-time continuum of Perl objects)
  • don't define objects that aren't hashes ('cept inside outs)
  • don't rebless an existing object into a different package (if you describe that as polymorphism in a job interview, expect to be shown the door real quick)
And so on.
The sad fact is that there are many ways to write bad Perl. I was amused to see Damian Conway and Larry Wall sitting in the second row as Perrin read off the indictments that so many Perl programmers are guilty of. On that last point, I can't even figure out why anyone would ever want to do that or why Perl supports it at all. This is ridiculous: 
package Foo;

sub new {
  my $class = shift;
  my $data = shift || {};
  return bless $data, $class;
}

package main;

my $foo = Foo->new;
print ref $foo, "\n";
bless $foo, 'Bar';
print ref $foo, "\n";
For the non-Perl readers, create an instance of Foo ($foo), then change it to an instance of Bar, printing out the class names as you go. The output is: 
Foo
Bar
Anyone caught doing this will certainly come back as a two headed cyclops in the next life.

I've been trying to increase my python craftiness lately. I first used python about 10 years ago (1996) at GameSpot, we used it for our homebrewed ad rotation system. I fiddled with python some more at Salon as part of the maintenance of our ultraseek search system. But basically, python has always looked weird to me and I've avoided doing anything substantial with it. Well, my interest in it is renewed because there is a substantial amount of legacy code that I'm presently eyeballing and, anyway, I'm very intrigued by JVM scripting languages such as Jython (and JRuby). I'm looking for a best-of-both-worlds environment, things-are-what-you-expect static typing and compile time checking on the one hand and rapid development on the other. I was really astonished to learn that chameleon class assignment like Perl's is supported by Python. Python is strongly typed in that you have to explicitly cast and coerce to change types (very unlike Perl's squishy contextual operators which does a lot of implicit magic). But Python is also dynamically typed, an object's type is a runtime assignment. This is gross: 

class Foo:

  def print_type(self):
    print self.__class__

class Bar:

  def print_type(self):
    print self.__class__

if __name__ == "__main__":
  foo = Foo();
  foo.print_type();
  foo.__class__ = Bar
  foo.print_type();
In English, create an instance of Foo (foo), then change it to an instance of Bar, printing out the class names as you go. The output is: 
__main__.Foo
__main__.Bar
(Python prefices the class name with the current namespace, __main__) Anyone caught doing this will certainly come back as a reptilian jackalope in the next life.

Of course, Java doesn't tolerate any of these shenanigans. Compile time complaints of "what, are you crazy?!" would surely come hither from javac. There's no setClass(Class):void method in java.lang.Object, thank goodness, even though there is getClass():Class. One of the key characteristics of a language's usefulness for agile development has to be its minimalization of astonishing results, quirky idioms and here-have-some-more-rope-to-hang-yourself behaviors. If you can't read your own code from last month without puzzling over it, how the hell are you going to refactor it quickly and easily next month? Will your collaborators have an easier time with it? Perl has rightly acquired the reputation of a "write once, puzzle forevermore" language. I haven't dug into whether Ruby permits runtime object type changing (that would be really disappointing). I'll dig into that next, clearly the rails developers emphasis on convention and configuration over code is aimed at reducing the surprises that coders can cook up. But that doesn't necessarily carry back to Ruby itself.

                   

( Aug 27 2006, 08:51:11 AM PDT ) Permalink


20060802 Wednesday August 02, 2006

I would pay Muni 10x the fare if...

...just once when a passenger wearing too much perfume or cologne boards the metro, it would prompt the driver (who would be Samuel L. Jackson) to stand up, turn to the passengers and demand, "Get those mother effin' stinks off this mother effin' train!"

Perhaps for once I'd get my money's worth from Muni.

       

( Aug 02 2006, 09:46:20 AM PDT ) Permalink


The 5-year forecast

Sam Ruby's Teenagers on the go slide deck is an interesting prognosis on the future impact of the protocols, formats and form factors in our midst on publishing, sharing and participating on the web.

( Aug 02 2006, 07:13:37 AM PDT ) Permalink