Get off my lawn.

Tuesday, September 26, 2006

Scoble and the name-drop

I have Robert Scoble's blog in my collection of RSS feeds, because, you know, he's a big-time A-list blogger. (Notice the subtlety with which I dropped a name. Direct and hard to miss, but not gratuitous.)
I'm trying to figure out what makes his brand of A-list blogging so special. I get something like 150 new posts from him per week, and they all read something like this:

Today, me and Jonathan Schwartz (CEO of Sun) were hanging out being cool, when Bill Gates (from Microsoft) stopped by to see me. "Robert", he said, "You are my best friend". Then Cameron Diaz (famous starlet) came up and asked for my autograph. I didn't do it though, because Monica Belluci (famous Italian) was sitting on my lap talking to me, so I didn't hear Cameron's request (Sorry Cameron!). Plus, I couldn't have signed anything anyway, since both of my hands were busy while I was shaking hands with:

  • God
  • The Pope
  • Thomas Edison
  • Trey and Matt
  • Weird Al
  • The guy who wrote the VB Setup Wizard at Microsoft back in '97
  • The inventor of Perl

Check out this video of me dancing.

PS: RSS is hella cool.

I must be a simpleton, because I can't understand what's so compelling about this. Someone help me out here, please.

Sunday, September 17, 2006

PNSS, Final Day

Whew, I'm beat. I was sitting in the last session, it was hot, and I suddenly got sleepy. It's been a long
weekend, but it went by really fast. I think this conference is about the right length. I've enjoyed it,
but at the last session I thought "you know, if I had to do this for another day, I'd be sick of it."

Here's the run-down of today:

There were two sessions on Agile Development, given by a guy named Dave. He was a very laid-back guy who had a pretty good approach to bringing the Agile development style into an organization. In short: Be really diplomatic, start slow, and be prepared to lose some battles.

He said something else that I liked: My buddy Dale Cooper and I occasionally talk about what the software development process is like. Cooper likes his analogies, and uses them often. In these conversations, software development has been compared to everything from factory work to home and golf course construction, to interstellar travel in a canoe. At one point, I compared the process to record production, movie making, or the recording of an artistic work. As a musician with a small amount of experience in a studio and various band situations, and it makes sense to me. In both cases, you have a group of creative people who share a desire to create something (and make a name for themselves), you have a budget, you have a collaborative situation where the creative types interface with one another and try to come up with something that doesn't suck, and you typically have a "producer" who "owns" the project and whose function it is to remove obstacles and motivate the creative types to do their best. In all cases, you also have suits sitting around bitching about the creative types who expect to be treated like rock stars, even if they're not.

You also see a lot of situations where someone with a good dose of talent and motivation will do something on their own, create a buzz, get famous, and actually turn into a rock star. They'll have fame and job security until their particular brand of stuff goes out of style or they go West in a pool of their own vomit. So the analogy fits, in my opinion. Cooper didn't seem to care much for it. I'm guessing it's because it places gives too much credit to the creative types, and not enough to "leadership". Which, in his case, is probably a justifiable position to take. In the environment where he's been for the past 200 years, the "creative types" I mention actually are more like factory workers, or they're old tuba players who've found themselves in a prog-metal band and can't riff their way out of a wet paper bag.

Anyway, this guy Dave compared the software development process to the creative process and collaboration that takes place when a band and a producer gets together. That's spot on, Dave.

The next two sessions were kind of interesting. One of them was called "Applied REST", and it talked about RESTful web services. Amazon, Ebay, and several other big companies provide web services of both types, SOAP/RPC and REST. They say that 85% of their web service clients use the RESTful services, leaving a paltry 15% which use SOAP. The reason? According to this guy, SOAP is too complex, heavy, and a pain in the butt to use. REST, by contrast, uses a simple approach that accomodates change, performs well, and follows an easy-to-understand pattern. The summary: REST good, SOAP bad. My own take: REST is, in fact, a heck of a lot more practical for 9 out of 10 applications than the enterprisey overkill that is SOAP.

The second of those sessions was called "Pragmatic XML", and also focussed on web services. The summary there: REST bad, SOAP good. Why? Because SOAP came first. (I guess.. He didn't really say why).

More specifically (and accurately), he went into great detail explaining the folly of trying to use XML to serialize objects, whether you're RESTful or SOAPy. Doing so is an extremely problematic thing to do, especially when you're trying to provide a web service that's consumed by disparate clients (Java, .NET, Perl, Ruby, or anything else that can handle XML).

Normally, I scoff at most of what Microsoft does, since it seems to be motivated by their desire to lock people into using their products, and paying their stupid tax. However, one thing I remember reading in a Microsoft-sourced article about web services made a lot of sense: Quit trying to pretend that live program objects can be flattened into a sequence of bytes, sent somewhere else in the world, and rehydrated into something "live" on the other side. The approach has always worked, but has never worked very well. The older binary protocols (CORBA, etc.) were extremely brittle, and so is machine-generated/machine-parsed XML. A SOAP envelope, a REST document, or a JSON string is a document that describes an object, but is NOT an object. The smart approach is to quit pretending, and acknowledge it for what it is. If you want to serialize XML across the wire, that's great. It works fine, just count on doing something on the receiving end to parse it into what you need. XML isn't the silver bullet to solve the problem.

I'm getting sleepy again.

Test Drive! Chevy Malibu

I drove a rental car today, a Chevy Malibu. Being into cars and stuff, I couldn't help but notice some aspects of the car. Here's my impression:

It's been awhile since I've driven an GM car. I found it really puzzling. The Malibu is a pretty new model, no doubt released some time after GM realized they weren't selling many cars. So you would expect GM to at least try to make a car that had some kind of appeal to... someone. But I've never seen a car more anonymous, more devoid of personality, more joyless, or as boring at this one, except maybe a Yugo. If this car were ice cream, it wouldn't be vanilla. Vanilla at least has a flavor. If someone managed to make vanilla ice cream and left out the vanilla, that might be more like it.

The interior is fairly, I don't know... A place to sit. That's about the best thing I can say about it. The gear selector sticks up about 14 inches, and looks like it was made out of a recycled curtain rod. The dash appears to be made out of rubber. The seats are covered in some kind of magic fabric that makes you feel sad the instant you touch it. The seats themselves are kind of like some lawn chairs I've sat in. They're seemingly made of fabric suspended between two poles. Most seats have some kind of discernable shape in the back area, but not these. It's just cloth back there. It's not necessarily uncomfortable, but it does feel cheap, and different enough from a normal seat to create a bad impression.

Appearance-wise, this car is so anonymous that I actually walked right up to it, fully aware that I was in the exact spot where I had parked it, and then looked around for it, wondering where the heck it was.

One doesn't typically expect a car like this to be a speed demon, and the Malibu doesn't disappoint. It's not. Acceleration is one of those things you have to really want, in order to get it. A slight push on the gas pedal yields no effect at all. A little more urgency on the pedal causes a slight increase in noise, but no speed increase. You basically have to go to the carpet with it, which results in a slight increase in speed. Some seconds later, you glance at the speedometer, expecting to see something alarming. It says "40". Lame!

Interestingly, the only time you can hear the engine is when you're really punching it in an effort to keep up with, say, a pedestrian walking on the sidewalk beside you. Ordinarily, it makes no sound, which is good, because the sound it does make is unpleasant. Describing sounds in text is difficult, but you can produce the sound of this engine at home, using a few ordinary items and a simple technique. Take the following items:

1. One adult male human
2. A golf ball
3. Duct tape
4. A campfire
5. A metal rod
6. A length of rope

Lay the metal rod in the campfire. Hog-tie the man with the rope. Put the golf ball in his mouth, and tape his mouth shut. When the rod has gotten red-hot, poke the man in the forehead with it. The muffled grunting and pained wheezing you'll hear is similar to the sound of the Malibu's engine.

At some point, you'd think someone at GM would look around and say "Hey, other companies make cars, and people occasionally buy them. Let's buy one too, and see what makes it tick." The general idea is that they might take some of the features they find, and incorporate them into their own cars. Oddly, this car seems like a deliberate attempt to do the opposite. It's as if someone said "Toyota Camry? Let's make the 'UN-Camry'! Everything it is, let's be the opposite! Except the blandness. We should really play that up."

On the plus side, the brakes worked. The power windows were a nice touch. Best of all, the driver's door opened smoothly, and I was able to get out.

PNSS, Day 2

Day Two at PNSS was good. It went by in what seemed like 20 minutes. I went to a session on Ajax architecture, given by an energetic and animated guy.

The next session I went to was about SOA. True to form, the speaker gave a realistic view of it, instead of the usual claptrap about SOA being the future of all computing, the end of all applications, and the beginning of a new era.

The basic story with SOA is that it, like other "plumbing"-related efforts before it (RPC, COM, COM+, DCOM, .NET Remoting, RMI, etc.) is about connecting applications with services. The difference is that this time around, SOA's definition is a lot more high-level (vague) and "business-y" (consumable by managerial types on the technical periphery), so it has buy-in from higher-ups in corporations, rather than being just something needed by developers of distributed systems. The speaker at the conference said he thought that the term "SOA" probably first appeared in an in-flight magazine. It was read by a CEO on his way to a business meeting, who then said "Yeah. SOA. I got to have me some of that", which is what got the ball rolling WRT SOA.

Unlike its predecessors, SOA isn't a specification that dictates the mechanics of communication between services and consumers. The thinking is that most communication should be done via XML, in a SOAP or REST web service-type setting, although that's not a formal requirement. However, communicating across machine boundaries in a transparent text-based format is vastly preferable to the previous attempts, which were usually binary protocols that broke easily and were hard to build, test, and debug.

The problem with SOA is that you can ask 10 different people what it is, and you'll get 10 different answers.
There's no specification I know of, and the description is so high-level that it leaves a lot of room for interpretation and agenda-pushing. Some people think it automatically means "web services" (it doesn't), others think it means "XML" (nope), others think it means "SOAP" (wrong again), while others, amazingly, think it means software will no longer require testing. Still others have said it means user interfaces will be built in the future using point-and-click with no code, all because of SOA. WTF?

Actually, the basic idea is this: Various business-specific functions are defined as "services" running in various locations. The "services" are software systems that sit idle until a "consumer" makes a request to them. So, instead of defining an application that provides its own security, authorization, business rules, etc., an application is defined so it communicates with one or more coarse-grained encapsulated business services through discoverable, negotiable interfaces. (Wow... I just described SOA in the plainest terms I could think of, and it sounded like a product brochure!) Anyway, it's a worthy goal. A full SOA implementation in a company would mean that no "applications" exist in the traditional sense; Instead, there would be an enterprise service bus (ESB) that everything hooks to, and provides access to everything else (think of it as a big pipe). A "Customer" service would provide access to customer data, a "Security" service would provide authenication, a "Rules Engine" would provide business rules, and so on. "Applications" would consume these services from the ESB instead of having "baked-in" dependencies on them. Services could be swapped out in favor of other services, or upgraded, without causing their consumers to break (as long as the services' interfaces don't change, of course, unless I'm missing something big).

Granularity of these services is a big issue, and probably the most important aspect to make sure you get right. Providing a consumable "Customer" service is one thing, but providing a consumable "Database" service is an idiotic idea. Given the hype surrounding SOA, I'm sure someone's going to insist on a consumable "Database" service eventually. Unsuprisingly, it will result in the slowest software ever created, and suprisingly, the person who insists on it won't be the one who gets fired. It'll be interesting to see how SOA turns out.

The final two sessions were about Hibernate. I've been a big fan of Hibernate for 3 years. It's simple to use,
efficient, lightweight, places no artificial constraints on the objects being persisted, and is, frankly, the best way I've found for mapping between objects in a java program, and data in a relational database.

One more day to go. This is a cool conference. I talked to the organizer of it today in the hall, and told him I liked how there was so much more "meat" to it than something like the neckties-and-cheerleadin' JavaOne-type conferences. He said "Yeah, we basically look at those conferences to see what they do, and then we do the opposite." Well, it's working.

Saturday, September 16, 2006

March of the PNSS

Something weird I noticed just now, while sitting in a Hibernate session at PNSS: A lot of people here have really high voices. They're guys, but their voices are high, like girls. Other than that, nothing unusual is going on.

PNSS, Day 1

I'm in Seattle this weekend from Friday until Monday, at the Pacific Northwest Software Symposium. It's an action-packed affair put on by an organization called "No Fluff Just Stuff".

Unfortunate about the name. Most conferences of this type have a catchy name that's easy to say, or at least abbreviate, for example "Comdex", "LinuxWorld", "JavaOne", etc. "Pacific Northwest Software Symposium" doesn't really roll off the toungue the same way. You can't really abbreviate it either. At least not if you plan on saying "PNSS" out loud.

The conference itself has been pretty cool. It's a lot different than some others I've been to. JavaOne, for example, is a big gathering of major vendors of Java-based tools and infrastructure software. A trip to JavaOne is a walk-on part in a big commercial. You get a lot of free stuff (pens, keychains, t-shirts, etc.), but not a lot of useful information. There are keynote speeches, educational sessions, and more, but they're all cheerleading, and not very useful if what you're looking for is real information about something.

As I mentioned, this is different. In terms of swag, I got a t-shirt. That's about all. The speeches and sessions are given by normal-looking "functional" types in t-shirts and jeans, and they seem to have no qualms about mentioning the not-so-great parts of a given product, framework, or process. There's no cheerleading going on, just honest information from people who know what they're talking about. Here's an example: In a JavaScript session I heard today, the guy said (in effect) "Javascript has a lot of really stupid features which have no apparent justification. Still, it's a handy language. Learn to like it." (He's right, too.)

It's a refreshing change from the boring/useless noise I spend most weeks listening to at my job in the IT department of an insurance company.

The hotel room is great. Seattle (actually Redmond) is pretty cool. Tomorrow or Sunday, I'm going to go sightseeing, maybe over to the Microsoft campus.