Friday, March 17, 2006

Random Netflix Musings

Well, the numbers are in for 2005. We watched 116 Netflix movies last year. That's an average of 9.6 movies per month at $1.88 each. Netflix doesn't exactly make it easy to figure this out - except that they send emails that can be collected. Maybe there's some sort of Long Tail or Web 2.0-ish opportunity here...

I wonder how many Netflix disks were lost because of Hurricane Katrina?

Saturday, March 04, 2006

The Economics of Expertise

Kathy Sierra, contributing author to O'Reilly's Head First series, Sun's Java certification exams, and Creating Passionate Users makes some interesting points in "How to be an expert". It's another great post embodying the unifying theme of how to kick ass.

In my opinion, there are some very real economic decisions made when evaluating how far down the expert road you want to get. I tend to agree that we practice the things we're already good at. I also agree to an extent that we avoid things we suck at, but I'm not sure it's because we make a decision to be mediocre. I think it has as much to do with the value of our time, or an organization's time, as much as anything.

The point was made, "Yet the research says that if we were willing to put in more hours, and to use those hours to practice the things that aren't so fun, we could become good." I totally understand the point of this sentence. From a pragmatic standpoint, this could describe more time in test-driven development, or an extra evening at a user's group meeting, or really digging into SOAP with that next web service. But I only have 24 hours in a day and I need to sleep for
some of that time! So those other 17-ish hours of my day have some real economic value to me, my family, and possibly other people.

It seems the value of becoming an expert sometime in the future is constantly weighed against the near-term value of that time. And the distance into the future seems to be significant as well. For example, O'Reilly's home page currently displays a heading: "Technology Doesn't Wait-- Neither Should You". In other words, we have a relatively short amount of time to maximize our expertise in a technology. Entity beans? Stateless session beans is the way to go. EJB? Why? Don't you know that Hibernate with Spring probably solves the same problem? Struts? You should consider Ajax with JSF. JavaScript and JSP? Why not a C# .NET smart client..? And on and on for eternity. Sure, I can still put in more hours and become an expert in C or SmallTalk. And yes, being an expert in anything at any time is worthy of some merit. But what it comes down to is this: is the payoff at the end of the expert road worth the time that I missed on other things, particularly, playing with my kids? In technology, that value is diminished with every passing day.

So this is probably the reason why I still have not actually changed the oil in my car myself. There are experts out there that can do it for me. And in the end, I guess I'll live with mediocrity in investing, remodeling my house, or playing that saxophone that's in my basement. But that's because I am trying as a software engineer. And frankly, I'm able to convince my employer to pick up a portion of the economic cost of traveling down that road. But most importantly, I'm well on my way to becoming an expert at being a dad. And I think the economic benefits of that to our world will probably outweigh my contributions as an engineer.


Wednesday, March 01, 2006

Open AJAX Consortium Looks to Ease Development

One of the interesting points that Laszlo Systems CTO David Temkin makes in this interview is the relative lack of good UI developers out there, specifically in the J2EE realm. I think he's correct in stating that a good J2EE developer tends to be proficient more on the server side than on the client. And maybe that's because there's relatively much less Java code actually involved in the display when you're talking about a web application - witness the rise of Ajax. Also, a good UI developer has to be so much more than just a software engineer. A good UI developer needs to be part psychologist, part designer in the pure sense, part artist, part engineer, a users' advocate (gasp), and extremely detail-oriented. On top of that, a good J2EE UI developer probably needs to work well in other technologies such as HTML, JavaScript, CSS, XML/XSL, and even Flash. True, these are not so much of a technical stretch compared with J2EE technologies, but it is a bit of a stretch to expect the same person to be truly exceptional in all of the technologies (jack of all trades, master of none).

The one thing that catches my attention most about Ajax splashed across java.sun.com, developerWorks, and TheServerSide is that these same people were touting XP not very long ago. And granted, I understand that these folks must live on the edge. But I find it so interesting that we've shifted from test driven development and best-practices to getting something out the door quickly. And a "something" which isn't based on a standard framework (as this article points to), can't easily be unit tested, has very little tool support, and actually isn't even grounded in Java!

I'm excited about these developments but I'm also interested in watching how they play out with Windows Vista and XAML lurking around the corner.



Thursday, February 23, 2006

BITS problem solved

The server does not support the necessary HTTP protocol. Background Intelligent Transfer Service (BITS) requires that the server support the Range protocol header.

The latest application that I've worked on is a C# WinForms application that incorporates the
Microsoft Updater Application Block to handle automatic updates. For Java developers, this is basically the equivalent of Java Web Start. Under the covers, the Updater Application Block uses BITS (Background Intelligent Transfer System) technology; the same technology that's running when you install a security patch from Microsoft. We encountered the above error with a single client site and it took an incredible amount of time to figure it out, and there was only a smattering of clues published on the web.

The error message may lead you to believe that the problem stems from a misconfiguration on our server. The following is a snippet from BITS documentation:

HTTP Requirements for BITS Downloads

BITS supports HTTP and HTTPS downloads and uploads and requires that the server supports the HTTP/1.1 protocol. For downloads, the HTTP server's Head method must return the file size and its Get method must support the Content-Range and Content-Length headers. As a result, BITS only transfers static file content and generates an error if you try to transfer dynamic content, unless the ASP, ISAPI, or CGI script supports the Content-Range and Content-Length headers.

BITS can use an HTTP/1.0 server as long as it meets the Head and Get method requirements.

To support downloading ranges of a file, the server must support the following requirements:
  • Allow MIME headers to include the standard Content-Range and Content-Type headers, plus a maximum of 180 bytes of other headers.
  • Allow a maximum of two CR/LFs between the HTTP headers and the first boundary string.

But the actual cause in this case was our client's firewall configuration. The firewall (SonicWall pro 5060) was interfering with the response from our server. The solution: our client opened our IP range on their CFS Exclusion List, Gateway AV Exclusion List, IPS Exclusion List, and Anti-Spyware Exclusion List.

Hope this helps someone else out there!

Sunday, February 19, 2006

Lessons in SOA

Although I agree with the comments of George Carey about this article, I wanted to add a little personal experience to the underlying theme of the article that a SOA needs to be based on a loosely coupled abstraction layer. This is absolutely critical. Why? Because services can easily turn into a maintenance headache that is, "write once, maintain forever."

Coming from EJB/JSP-land, it's not initially apparent that point-to-point services are bad. Both Microsoft and Sun are selling how easy it is to produce and consume web services. But it becomes obvious over time that you're actually writing a public API rather than remote procedure calls. This is a significant shift in thinking and practice and shouldn't be underestimated. Under the basic constraints of API development, service signatures cannot change and contracts can't be broken. This can lead to versions of methods like getDocument(int) and then getDocument2(int, boolean), etc. Then in the future when a bug is found, you may end up maintaining getDocument() and getDocument2(). Of course we strive for proper encapsulation, but sometimes even good encapsulation cannot prevent the possibility of breaking a contract. So then you may even wind up maintaining different versions of compositions that basically perform the same task. Or, in the unlikely event that a database primary key changes, it may reverberate all the way through the system unavoidably breaking a contract. And even in a system with relatively few web services, this amount of maintenance can quickly become unacceptable.

My point is that in order to be successful with a SOA, you probably need to put even more work up front in design and more forethought in policies such as managing deprecation. And I understand that implementing a SOA is different than implementing a few web services. But as this article points out, this fundamental understanding needs to get to the core of an organization before the "if you build it, they will come" mentality.

Thursday, January 19, 2006

Indiana Jones and the...

I rely on my brother to filter only the most important Ain't It Cool News. Thank you Steve. And thank you to all the creative folks out there suggesting titles (readers talkback) for Harrison Ford's swan song as Indiana Jones.

Saturday, January 14, 2006

Remote Prosperites

Last month, I was fortunate enough to spend some time with Cyd in London (Camden Town). It was a short but incredible trip; made more comfortable by the fact that I flew business class both ways. It's disgusting how they treat you in business class. I highly recommend it.

Day 1 involved:
1. Making it onto the correct tube train and realizing I'm sitting in the absolute middle of the train, with my luggage, 8am on a week day (packed), I'll need to navigate off the train soon with my luggage, and I'm American. DOH!

2. Trying to decipher Cyd's directions out of the Underground station. "Go straight out of the station" can be interpreted in many ways when you're faced with a 6 point intersection, cars driving on the other side of the road, and no street signs (street signs are on the buildings - I didn't know that until day 2). In fact, it took 3 tries to head in the right direction. Have a look for yourself... which way would you have gone?!

3. Trying not to succumb to spontaneous REM sleep. In the famous words of Evan Dando, "I know what it feels like to be MAARK today." (paraphrased)

My prescription for shaking off GMT-0700 was spending some quality time with myself in the crisp air of Regents Park.

And then a few more hours exploring the catacombs of Camden Market. I think I probably heard at least 20 different languages while wandering through.

4. And later after a short nap, wandering to a tiny little back-alley with a couple boutique stores, drinking hot sangria, and helping Cyd find a bobble (Christmas tree ornament).

Day 1 conclusion: Absolutely amazing.

Day 2 involved:
1. Waking up at 6am. That's the time my son usually wanders into our bedroom every morning. This strikes me as completely bizarre as it's 6am London time.

2. Knocking out the things I absolutely had to see: Sir Isaac Newton's sarcophagus in Westminster Abbey and John Harrison's clocks that won the Longitude prize. Along the way, I got to see the rest of London via the Thames and Greenwich. Very satisfying.


















3. Listening to some very bad karaoke in a local pub.


4. Loading up the jukebox at the Camden Castle, birthplace of Blur, and partaking in an obligatory G.W. discussion with a young Londoner currently residing in Barcelona.

Day 2 conclusion: Absolutely amazing.

Day 3 involved:
1. Waking up at 6am again.

2. Wandering to and then through the Tate Modern gallery. Rodin, Picasso, great views of Saint Paul's, etc.








3. Wandering through Picadilly Circus and the theater district to find some amazing Indian food.

4. Eating amazing Indian food.

3. Spending some quality time at a local pub with Cyd's international mates over a few bottles of wine.






Day 3 conclusion: Absolutely amazing.



So Cyd asked what the best part of the trip was. The best part of the trip was the conversation with Cyd about life and actually spending time with Cyd's mates. It was just being there.


By the way, I just saw King Kong the other night and the commercial they played before the movie had Kate Winslet walking here.

Hey Cyd, take a close look at the Camden Lock... you'll see some of Banksy's work (hanging painters). My brother picked up on it in this photo that I took.


Cheers!