Shebanation

Administration and spam handling of this blog was taking up too much of my time, so I’ve moved over to a blog hosted at wordpress.com. The transition was very smooth, since both MovableType and WordPress have excellent import/export functionality. All comments have moved as well.

The new URL is http://shebanation.com

You can subscribe to my RSS feed at:

Full RSS Feed

Also, as a bonus of moving to wordpress, you can subscribe to my comments feed:

Comments Feed

I’ve turned off commenting on all existing posts on this blog, and will not be updating this blog any further.

Posted by Andrew Shebanow at 11:44 AM | Permalink

So the folks over at Joyent have announced that Slingshot will be released under a dual licensing model: GPL and a commercial paid license. The surprising thing about their announcement is that they went out of their way to call me out over the licensing issues:

When we announced Slingshot, Andrew Shebanow at Adobe posted about Apollo, Competition, and Openness.

Next is SlingShot from Joyent and Magnetk. I love Ruby on Rails, so this product is very interesting to me. They basically have taken the all-in-one desktop server approach of Locomotive and turned it into an application runtime. Its a great idea, and one that opens up a lot more power to the local application than Apollo. Downsides are a lot of potential security issues (no sandbox?), the fact that the entire source of your application is distributed to the world whether you like it or not, and the fact that it is limited to Ruby on Rails applications. More disturbing, though, is that it sounds like Joyent will be charging a royalty for distributing applications based on their runtime unless you are a customer for their hosting service. Maybe they just plan on charging a flat fee for the SDK. Either way, this is much less open than the Apollo model where the SDK and runtime are both free of charge.

We are charging a license fee to people using Slingshot for commercial purposes. I believe Adobe does this for content producing tools, too. Joyent would like to invite Adobe to open source Apollo and the ecosystem around it (Flex, Flash). Don’t just make it free, free it.

And by way of response. Sandbox? What’s the sandbox Adobe Photoshop runs in? Entire source? More on that, later. Limited to Rails? Yes. Focus.

I have to admit that I’m a little mystified by their hostility. I thought I was pretty evenhanded and positive about their product. David Young, the CEO of Joyent did respond to the post accusing me of FUD, we had some back and forth on it, and I thought it was resolved. Heck, when I posted a while later about DHH’s post, David commented again to thank me. Why the change in attitude now? Beats me.

Anyhow, I tried to respond to the post on Joyent’s blog, but my post disappeared shortly after I submitted it. I thought it might have been a glitch so I posted the comment again. Again it disappeared. This might be a server problem on their end, but it also might be outright censorship, and it feels more like the latter to me since other people’s comments show up. In any event, the net has a way of routing around that sort of thing. Here’s my comment as I wrote it in their blog, unedited. I think my comments were critical but not inflammatory so I’m again at a loss to explain why they’d delete what I said, if that is in fact what happened. Are they really that incapable of dealing with criticism? I hope not.

Wow, holding a grudge, are we?

I addressed your sandbox comment on my original post, but you clearly don’t appreciate the trust model differences between small apps that are downloaded from the internet and large-scale traditional desktop applications. Or maybe you do appreciate the difference but are only targeting the latter. Or you just don’t care. I personally think you are making a big mistake ignoring the security issue but its certainly your right to do so.

I’m happy you’re releasing source under GPL. Duel licensing is an interesting choice, and I look forward to seeing how it works out for you business-wise. There is no question that monetizing a runtime framework is a tricky business.

Can’t really speak to the whole “free vs. free” thing. I’d certainly welcome such a thing but it isn’t something I have any control over. I do want to point out that even though Apollo isn’t fully open source, pieces of it are, like WebKit and Tamarin. That obviously won’t be enough to satisfy everyone, but we expect great things.

Bottom line is I wish you all the success in the world, and I hope you get over your hard feelings.

Posted by Andrew Shebanow at 05:11 PM | Permalink | Comments (2)

So TechMeme is chock full of news about SilverLight, including the patented Microsoft astro-turf announcement technique, where all the Microsoft WPF/Expression employees post the same links to their blog without actually saying anything new and substantive. The best post is the real announcement from Tim Sneath. The other post worth reading is this one from Loke Uei where he has a handy comparison chart listing Silverlight vs. WPF vs. Flash/Flex. Too bad the column on the Flash/Flex stuff is almost completely incorrect. Every other post from Microsoft’s folks is pretty much worthless.

But what did they actually annnounce at NAB? A decent new name (by Microsoft standards it is excellent since it only has one compound word) and a really boring new logo. The runtime downloads have been renamed but the bits themselves are the same pre-alpha stuff from a couple of months ago. No news on actual Expression support for Silverlight either. Some teasing about the miniCLR “surprise feature”. Guess they want to save all the real news for MIX. All that’s left for NAB is hype, hype, hype. The wow is back!

Meanwhile Apple and Adobe actually had new never-before-seen products to talk about, not just new product names.

Posted by Andrew Shebanow at 01:27 PM | Permalink | Comments (6)

I’ve been thinking quite a bit lately about solving problems at web scale, so I’ve been following the story of Twitter with quite a bit of interest. There was a bit of a flap recently when Josh Kenzer interviewed Twitter’s Alex Payne. Alex made some statements about the pain of doing very large scale scaling with Ruby on Rails that caused a bit of controversy:

Running on Rails has forced us to deal with scaling issues - issues that any growing site eventually contends with - far sooner than I think we would on another framework.

and:

None of these scaling approaches are as fun and easy as developing for Rails. All the convenience methods and syntactical sugar that makes Rails such a pleasure for coders ends up being absolutely punishing, performance-wise. Once you hit a certain threshold of traffic, either you need to strip out all the costly neat stuff that Rails does for you (RJS, ActiveRecord, ActiveSupport, etc.) or move the slow parts of your application out of Rails, or both.

and:

If you’re looking to deploy a big web application and you’re language-agnostic, realize that the same operation in Ruby will take less time in Python. All of us working on Twitter are big Ruby fans, but I think it’s worth being frank that this isn’t one of those relativistic language issues. Ruby is slow.

That is what I’d call “tough love”. Ruby on Rails fans may not want to hear about these things, but that doesn’t mean they aren’t real problems when you try to scale at a massive level like Twitter is doing.

Unfortunately but not too surprisedly, the initial reaction to these statements was pretty defensive. Since then, though, there has been a lot of good discussion of what it means to scale in Rails. The best discussion, though, has been from Ryan Tomayko, who says:

I picked up a word from Joe a few years back and find myself using it a lot: “friction.” When referring to framework and tooling, “friction” is a (subjective) measure of how much the tooling gets in your way when trying to solve a specific-case problem. I’ve come to evaluate frameworks based on two rough metrics: how far the framework goes in solving the general case problem out of the box and how little friction the framework creates when you have to solve the specific-case problem yourself. When a framework finds a balance between these two areas, we call it “well designed.”

Measured along these lines, there are portions of Rails that have a less than perfect balance but I don’t think multi-database connectivity is one of them. It seems to me that moving too far in one direction on this would cause lots of friction for moving in other directions. There just doesn’t seem like there’s a lot of general case to solve here when you dig into the details.

I love that quote on friction: it really captures the thing I like best about Rails. His entire article is well worth a read, both for the insights into good framework design and for the specific extensions he and his cohorts made to Rails to make it work for what they were doing. Great stuff and I hope the public conversation continues like this.

Posted by Andrew Shebanow at 04:09 AM | Permalink

Yesterday, John Gruber posted a gripe about the new CS3 panels and palettes and how horrible it is that Adobe put the close box on the right side. To John, this seemed horribly un-Mac-like, and in trademark style he concludes his gripe with an elitist and unsubstantiated slap at Windows users (but hey, at least it was funny):

Ends up the title bar controls for palette windows in CS3 are on the right side, Windows-style. “X” for close, “_” for collapse. God, that just looks so wrong – how did this ever get approved? If Adobe really wanted to put these controls in the same location on both platforms, why not do it the Mac way? If Windows users cared about consistency, they wouldn’t be using Windows.

I wrote him an email where I explained what I thought the actual motivation for the close box on the right decision was: the desire to save vertical space by putting the close box to the right of the palette tab panel interface.

But thinking about it some more, I realized that this answer didn’t really satisfy me. First of all, even though putting the close box on the right does make sense from an overall design point of view, the fact remains that the close box doesn’t look like a Mac-style close box when you run CS3 on a Mac. It doesn’t really look like a Windows close box, either. Instead, it looks like an “Adobe close box”, just as the palettes themselves don’t really look like those of other, non-Adobe applications. But then I had to think about it some more, because despite this realization I still am not bothered by the problem whatsoever when I actually use CS3, and I like to think I have a pretty well tuned design aesthetic (for an engineer).

The reason, I think, is that the goal of a single, consistent platform look and feel, as espoused by John in the quote above, is dead. Long gone. Apple never really achieved this even in the good old days (remember HyperCard? FileMaker?). And looking at Apple’s own applications that ship with a new Mac shows that things have only gotten worse. Its always been a case of “do as I say, not as I do”, and never more so than today.

But I don’t blame Apple or Adobe for the death of the goal. What really killed that goal once and for all was the web. Where once there were only a few popular Mac applications that broke with convention, on the web look and feel consistency isn’t even on the list of things to worry about. YouTube and flickr look and work completely differently. Users today have been trained to expect a different set of UI conventions from every web application they use, and they aren’t complaining about it.

The trend towards Rich Internet Applications using Apollo and its ilk will further cement this trend, as web applications come down to the desktop with their web UI conventions intact. To me, this is a good thing.

[Update 10:36AM] Wow, this is getting a lot of traffic and a lot of comments, especially for something I wrote at 4am when I couldn’t sleep. I want to make a few things clear to people about my intent.

The real thrust of my article isn’t as a defense of putting the close box on the right vs. the left, or about what the ‘x’ looks like. I personally don’t think that discussion is all that important, although there are clearly a number of commenters who disagree.

What I’m really talking about here is how the goal of complete UI consistency is a quest for the grail, a quest for a goal that can never be reached. The fact that you call it a holy grail may make the quest seem more noble, but it doesn’t make the grail any more achievable.

At the end of the article, I talked about how RIAs bringing web conventions to the desktop was a good thing, but I didn’t explain why (I blame lack of sleep). The reason I think this is that it lets us move the conversation away from the discussion of conformance with a mythical ideal and towards a discussion of what a usable UI should be. I really appreciate the comments from folks pointing out places where Adobe’s UI isn’t as usable as it could and should be - they’re the folks who really understand what I’m trying to talk about here.

Finally, I want to point out for those who may have missed it that this is my personal blog and that these are my personal opinions. I am an engineer, not a PR mouthpiece or an evangelist (at least not professionally). Furthermore, I don’t work on CS3, so my opinion shouldn’t be taken as that of the CS3 team or of Adobe as a whole. I never cease to be amazed at how many people seem to confuse this issue.

Posted by Andrew Shebanow at 04:46 AM | Permalink | Comments (17)

Ray Ozzie has done an interview with the always excellent Knowledge@Wharton folks, and its a great read. Its nice that Ozzie is coming out of hiding a bit. In the article, he talks quite a bit about Adobe. Not surprisingly, Dan Farber and Ryan Stewart are talking about it.

I think Dan pullled the most interesting quote out of the article, though he didn’t include the whole thing. Here it is:

Well let me just start by saying that, in my view, we only have one shared future as a software industry. And that is centrally deployed code that has a different lifetime associated with it on the device it’s deployed to.

So, what is HTML or DHTML? Most web pages have JavaScript in them. That’s code that is delivered to the client and it has the lifetime of the browser instance you’re using. Flash — what is that? Well, it involves enhancing the browser runtime by downloading code. But it tethers those enhancements to the service and the lifetime of those things is still within the browser. With Apollo, maybe you can make the lifetime that of the user on that device. They have increased the lifetime from the browser instance to the PC.

All apps — whether Win32 code, Flash code, managed WPF [Windows Presentation Foundation] code — are going to have those lifetime choices and will all be centrally deployed, whether that central deployment is from an enterprise or from a service provider on the web. The concept of CD-based installs, floppy-based installs or USB stick installs are artifacts of a time when we were not fully connected.

I don’t see radical differences in the approaches that Adobe might be taking, that we’re taking, or that the web industry in general is taking. The languages and run-times may be different. And we come at it from a history of the desktop coming up to the web. They are coming from a history of being on the web and going down to the desktop, but the endpoint is the same.

Cool. Ray Ozzie gets the key benefit of Apollo - bringing the web down to the desktop. His key message here is that bits is bits, and that it doesn’t really matter whether its .NET code or Flash or HTML/Javascript that gets deployed on the web - they all end up just being code that runs on the local machine. There is truth to that, but I think he is either being a bit disingenuous or missing the larger point - it isn’t just about the bits, its also about the APIs and tools used to create those bits. Does Ozzie really believe these things are irrelevant? I doubt it.

I’ve written about how I see our vision differing from Microsoft’s in this key area previously, but instead of repeating myself, I’ll instead point to the work of Peter Fisk. He is working on an amazing project to create a complete Smalltalk environment from the ground up, built on a lisp base. Now this is a pretty ambitious project, you have to admit. He started off using .NET and WPF, back in July 2006. After making steady progress for six months, he heard about Flex 2.0 at the end of January 2007. Two days later he had posted his first proof-of-concept tests of lisp implemented in Flex. Within a month, he had significant functionality in place. A month later, he had animation working in Smalltalk. He’s made incredible progress in the last two months, way more than he did in six months with WPF, and I’ve had a blast watching his progress. Now he has had a chance to reflect on the two worlds, and I love what he has to say. Here it is in its entirety:

I have been coding almost exclusively in ActionScript for the past two months, and I am beginning to like it.

The entire Adobe way of doing things is a lot simpler than Microsoft and it seems to produce results that are just as good. So far, I haven’t found anything that I could do in C#/.Net that I can’t do in ActionScript/Flash - in fact, I am finding some capabilities in Flash that aren’t available in .Net.

Here is a car analogy:

Microsoft has built a sports car and Adobe has built a Volkswagen (a real Volkswagen, not the new imitation ones).

So while Microsoft is preparing their latest rocket-powered turbocharger which will be available “real soon now”, you can actually build and deploy stuff in Flash.

A Volkswagen on the road goes a lot faster than a sports car in the repair shop.

Now, a lesser man could take that analogy and run it into a telephone pole, but I won’t go there. :-)

Posted by Andrew Shebanow at 05:35 PM | Permalink | Comments (1)

A couple of months ago, Steve Jobs posted his open letter on DRM to the web and I posted Jobs on DRM: The Elephant in the Room in response. It got me my very first set of Apple fanboy comments, which was exciting. Today, of course, Apple and EMI announced that they would start selling DRM-free tracks at a 30% markup. I want to congratulate Apple and EMI for taking this step. As someone who has purchased a fair amount of music through the iTunes Store, I’m happy to get the DRM-free tracks and the higher resolution, and I will undoubtedly be upgrading my existing purchases to the new format.

Going back and rereading my post, I’m really glad I focused on the video issue. Otherwise I too might have gotten hit with the dreaded John Gruber “Jackass of the Week” title. I thought it worth noting that Jobs did in fact address the video DRM issue at the announcement, and his point of view won’t please the anti-DRM forces in the world. Here’s one choice quote from Jobs:

Video is pretty different from music right now because the video industry does not distribute 90 percent of their content DRM free. Never has. So I think they are in a pretty different situation, and I wouldn’t hold it to a parallel at all.

He is basically saying that video DRM is OK because people are used to from DVDs. Not a very compelling argument, as it completely ignores all the questions about fair use.

Finally for the conspiracy theorists out there, could the timing of the Apple/EMI announcement be related to this news that came out the same day and got buried? (Tip of the hat to Paul for sending me the link…)

Posted by Andrew Shebanow at 06:57 PM | Permalink

DHH of Rails fame recently posted to the 37signals blog about not getting the need for “offline web applications”. Although he didn’t mention any one such framework specifically, it seems likely he was talking about Apollo, Slingshot, Firefox 3.0’s offline capabilities, and so forth. The gist of his argument is laid out in his first paragraph:

The idea of offline web applications is getting an undue amount of attention. Which is bizarre when you look at how availability of connectivity is ever increasing. EVDO cards, city-wide wifis, iPhones, Blackberry’s. There are so many ways to get online these days that the excitement for offline is truly puzzling. Until you consider the one place that is still largely an island of missing connectivity: The plane!

Now I have a lot of respect for David and for the products that 37signals has created, but it seems to me like he has made a couple of glaring errors in his analysis.

The first error is his supposition that the plane is the only place where people aren’t connected these days. I can understand how someone who lives and travels in high tech urban areas could make that mistake, but as many commenters on his blog have pointed out, we are far from universal connectivity in the industrialized world, and much of the world is even farther behind. And even where there is connectivity, hills, tunnels, concrete walls, and interference can wreak havoc on reliability and performance. I have no doubt that the trend worldwide is to more and more wireless access, and someday we may get to the point that David thinks is already here. But I don’t believe that we’ll be at the point where we have ubiquitous, reliable access for a long, long time.

The second is the supposition that Apollo, Slingshot, and so forth are all about offline web applications. I don’t think supporting purely offline applications is something most people are all that interested in. The benefits of the offline support are really about making applications that work in occasionally disconnected mode. The disconnect could be because you are on a plane, but it is more likely because your wireless disconnected for a while do to some sort of reliability glitch.

Furthermore, as David Young of Joyent points out, the benefits of RIA frameworks like Apollo and Slingshot aren’t just about being “offline”. They are really about bringing the benefits of web application programming to the desktop. David captures those benefits quite well, though of course his post is very Slingshot-centric. Although there are some huge differences between SlingShot and Apollo, most of what David writes applies equally well to Apollo. (See how I’m FUDing you again, David?)

Posted by Andrew Shebanow at 09:59 AM | Permalink | Comments (1)