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 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 at 5: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 at 1: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 at 4: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 at 4:46 AM | Permalink | Comments (17)