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.

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.

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.

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.

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.

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. :-)

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…)

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?)

While I'm passing on Apollo links, here are a couple of shorter articles I also liked:

• Richard McManus and John Milan argue about online desktop apps vs. offline web apps. I don't really agree with either side, but its a good read.
• Pasz.com has an article on things to like about Apollo from a day-to-day development point of view.
  

Actually, I had trouble imagining how it might be true even within limited domains. Though I’ve principally used Java for the last 10 years or so, and C/C++ for five years preceding that, I have a basic familiarity with Python, having written a few utilities here and there with it. Reflecting on those experiences I could see no basis for such a startling claim to code brevity.

In other words, “I can’t imagine it and haven’t experienced it, therefore it must be false…”

Can dynamic typing result in a reduction in code volume of 80 to 90 percent? It seems highly improbable to me. Suppose I had a piece of Java code and went through it removing all the type qualifications. Would that reduce the code volume by 80 to 90 percent? No, I don’t think so. Maybe there are other omissions that dynamic typing would make possible, such as obviating adapter-style classes and some interfaces. But even including such omissions, claiming an 80 to 90 percent code saving seems a bit rich.

He dismisses actual studies where people have compared static and dynamic languages as being overly biased, then does a “mental exercise” to prove his own side of the argument.

On the whole, no matter how hard I tried, I simply could not convince myself that dynamic typing and runtime code modification, either individually or in concert, could produce a code base that was “10 to 20 percent” the size of its static equivalent. Either the quote was inaccurate, had been taken out of context, or Deibel was engaging in some fairly outrageous marketing hyperbolae.

Again, “I can’t imagine it and haven’t experienced it, therefore it must be false…”

I recall doing maintenance and extension work on a system written in C containing approximately one million lines of code. To build that entire system from scratch took several hours. But that didn’t mean that every test/debug cycle we performed was punctuated by that same delay. There were large parts of the code base that we were not involved in changing, and they were built into libraries once at the beginning of the project, and thereafter we just linked against them. The net result was that in each test/debug cycle we were compiling only a small fraction of the code base, then linking against the pre-built libraries. This took seconds, not hours. It’s part of basic build management when working with a static language that you only recompile what you have to. The DL weenies would like you to believe that a burdensome compile/link time is an unavoidable downside of using static languages when in fact, it is not.

“This wasn’t true on one system I worked on, therefore it is universally untrue”

I could go on, but you get the idea. So here’s my challenge to hacknot: you seem awfully certain about things. Why don’t you back up your side of the argument with some hard and fast empirical data of your own?

I should warn people that the ActiveX control’s UI wasn’t designed to work with small amounts of screen real estate, so those with smallish laptops might want to wait for a better solution to come along…

OMG, Microsoft is keeping cats in cages and doing experiments on them! I always knew they were evil but this is beyond the pale!

Turns out this is really something much more innocuous and rather cool: the Assira CAPTCHA solution.

Not only is it a clever idea, but it actually helps find homes for pets via a partnership with petfinder.com. Nicely done!

When I read the book, I immediately remarked on the structure and wondered several times while reading it whether or not it made sense the way he did it. I found his article very helpful in explaining why:

The more I explored XAML on my own, the less I seemed to know. How do panels work? Why were some properties bindable but others were not? Why were some properties animatable but others were not? Why do those properties called “attached properties” seem to be in the wrong place? Why can you specify an event handler for children in a parent’s tag? What happens when modifying an existing control with a template isn’t enough and you need to write a custom control with keyboard and mouse handling and drawing?

Of course, answering these questions for myself required a lot of exploration. XAML is not as simple as it first seems. XAML required a whole intrastructure in WPF that involves layout mechanisms, dependency properties, routed events, and other features. It became quite obvious that most WPF programmers would want a familiarity with this infrastructure. Most WPF programmers would also want to gain a facility for working with this infrastructure. This can only be achieved in code.

Just one example: If you see an attached property in XAML — such as Grid.Row=”2” — it really doesn’t make a lot of sense. You’re specifying a property of the Grid panel within a child element of the Grid. If you look at the syntax in code, however, and you’re given an explanation of what’s going on behind the scenes in the context of alternative syntax, then attached properties make perfect sense.

I made a decision to tackle a lot of the WPF infrastructure very early in the book. I have an early chapter on dependency properties and a chapter on routed input events. I show how to write custom elements and custom panels comparatively early in the book. Many of my sample programs contain Window constructors that create and intialize elements and controls, which is a job that is eventually taken over by XAML, but doing it in code is something that every WPF programmer should know. Some stuff — such as defining a template — is incredibly painful in C#, but my book shows examples of that as well, and I hope the reader later comes to appreciate the relative simplicity of doing it in XAML.

He also gives a hint at a WPF feature that never saw the light of day:

I kept a close eye on one very special feature: the ability to embed C# code in a stand-alone XAML file and have it run in the browser. Although this feature was hinted at a bit, it never became real. If it had become real, I might have gone this route — or at least seriously considered it.

Is this where the WPF/E mini-CLR comes in?

I’m a little mystified by the argument, at least as presented by Om (I haven’t seen an actual transcript or slides for the actual talk):

1. Real Time with IM:
   Real time communication and collaboration are great, no doubt about it. But who says you need to be in a desktop application to achieve those things? Is there some special magic in XMPP, SIP, and Jabber protocols that makes them unimplementable in a VM environment? Of course not, and here is the proof: Adobe Acrobat Connect lets you chat, do VOIP, and more all within a web browser, using Flash. Jive’s own products implement these protocols in Java, which was also a VM environment last time I checked.
2. And then there is the familiar user interface!:
   Again, Flash-based user interfaces are incredibly rich. AJAX-based experiences have come a long way as well. What exactly is the special sauce in desktop IM programs that makes their UI unamenable to the RIA experience? As Om himself points out earlier in his article, if you can do Buzzword or Adobe Remix that way, surely the IM experience can be handled in the same manner…
3. Future full of features:
   Again, what is it about IM as a desktop application that makes it more amenable to new features than an RIA implementation or an AJAX one? Many people think that RIA environments are more productive places to program than the old Win32/Apple worlds. They certainly aren’t less productive.
4. Mobile goes the IM:
   This is a non-sequitir. How mobile IM clients are written will have little or no effect on whether desktop IM applications survive. Besides, mobile platforms could offer IM services based on Flash Lite or J2ME.

I suspect that David Hersh’s argument may actually be a lot simpler than presented by Om. He may just be saying that IM applications won’t ever be predominantly browser-based. But if that is what he’s saying, then my answer is: so what? If the future of IM is as an Apollo app, a Widget/Gadget, or some other such technology, why does it matter how those applications get onto the desktop? They are still going to be built on Web technologies, not on traditional “desktop” APIs.