techno.blog("Dion")

I had a really nice chat with David Orchard, Kevin Marks, Brad Neuberg, Chris Schalk, and Dick Wall (all but David are fellow Googlers) and it was funny to see how the world of HTML / XML and Java planning sounded familiar.

On the XML and HTML side you have the tag soup HTML folk who want to be practical and just SVG and MathML going, so put the darn stuff in there. On the other side you have the XML camp thinking about how to be smart and auto include namespaces, and relax requirements such as “When you see the first error, DIE DIE DIE” which makes XML impossible on the Web.

Then you look at Java, and see the growing pains there, and the desires for Java 7. The Java language folks are keen to keep incrementing the language with all of the cool stuff people are enjoying else where (Closures and the like). Then there are the Java platform folk who think that we should keep Java simple, and that adding all of the cruft does the opposite. Their solution is to use Java as a platform and use JRuby, Groovy, Scala, and any other language to develop functionality.

What camps are you in? I am in the HTML 5 and Java platform camp, as you could probably guess.

The new rage seems to be piping this to your blog:

history | awk '{a[$2]++}END{for(i in a){print a[i] " " i}}' | sort -rn | head

It reminds me of history class at school. Always painfully boring, which is such a crying shame, as history itself is fascinating. How school managed to take the subject that could be so enjoyable, and such a tie in to all other subjects, and instead make it incredibly boring is a crying shame.

The only thing that could put me to sleep faster would be:

148 ls
83 cd
29 download_saucy_mare_pictures
28 vi
24 ping
24 git
16 whois
15 wget
13 sudo
12 rm

I was talking to a friend that does a lot of work in the realm of Open Source Java. He is someone who talks to people high up in the chain, and discussed how a lot of the CIO folks are getting a bit confused with the offerings. They had gotten used to JBoss. And, now they get Spring. But, they keep getting bombarded with more things. Next they had Mule, and Groovy.

Get some of these guys in a discussion about Mule vs. ServiceMix and they froth. Spring did something smart via Spring Integration, but maybe it is time for some consolidation? SpringSource + MuleSource + G2One? SpringyMule?

It was quite fun to see, right after Tim O’Reilly pondered the lock in strategy for App Engine, that Chris Anderson posted that he had ported the SDK to App Drop.

Now, there are some concerns here as the SDK itself isn’t built for performance, security, etc…. but this is a great start in a very short period of time, and it shows where people can take it.

Waxy has a good write up:

This proof-of-concept was built in only four days and can be deployed in virtually any Linux/Unix hosting environment, showing that moving applications off Google’s servers isn’t as hard as everyone thought.

How does it work? Behind the scenes, AppDrop is simply a remote installation of the App Engine SDK, with the user authentication and identification modified to use a local silo instead of Google Accounts. As a result, any application that works with the App Engine SDK should work flawlessly on AppDrop. For example, here’s Anderson’s Fug This application running on Google App Engine and the identical code running on EC2 at AppDrop.

Of course, this simple portability comes at the cost of scalability. The App Engine SDK doesn’t use BigTable for its datastore, instead relying on a simple flat file on a single server. This means issues with performance and no scalabity to speak of, but for apps with limited resource needs, something as simple as AppDrop would work fine.

Chris said: “It wouldn’t be hard for a competent hacker to add real database support. It wouldn’t be that hard to write a Python adapter to MySQL that would preserve the BigTable API. And while that wouldn’t be quite as scalable as BigTable, we’ve all seen that MySQL can take you pretty far. On top of that, you could add multiple application machines connecting to the central database, and load-balancing, and all that rigamarole.”

And for data, you can write built-in services that export your data from the store.

I have to admit, that as someone on the inside it is nice to see the Google App Engine out there as a way to show some of the way in which we do things, especially scale.

One big difference you will see is the lack of a RDBMS, and instead with Bigtable, you build models that you can do cool things with such as Expando. Being able to add data elements as you iterate is very nice indeed, and beats SQL land, even with migrations and such.

Now when a new engineer comes to Google, they won’t have to entirely swallow a big red pill, as they may have gobbled a little of it already.

Since I am still in London, my sarcasm quotient extends just a little more than usual (it’s pretty high in the US to start with, even if it is the “lowest form of humour”).

I had a fair amount of email from people, and saw some blogs, complaining about the fact that Google App Engine currently supports Python only. On the video, and in the docs, it is frequently mentioned that other languages are to come, and that the infrastructure itself is language neutral. We have to start somewhere!

I personally have a slight Ruby preference, but there is a funny thing about Python. Hardly anyone really hates it. It may not be the language of choice for many people, but a lot of people are telling me:

• Ah, was hoping to try more Python
• I was looking for an excuse to code a Django app
• I can deal with that. Thank god you didn’t force Java

This is a little like the iPhone SDK being Objective-C. People are picking it up. I think this happens then your desire to play with the new toy is greater than your religion!

I am very excited to see more languages and features on Google App Engine, but I know that I just have to be a bit patient, and in the meantime, I had been looking for an excuse to code a Django app.

It is fun to see the wheel turn around again. I remember when EJB containers were the cats meow, and now when I hear someone say “container” in a meeting it is a social one.

I am happy to see some innovation from the Orkut folks. I have often been frustrated when I have clicked through something and been asked to install an application when I just wanted to see something simple. It makes me so mad that I never say no!

With OpenSocial, it’s possible to create environments where applications can spread because they provide great user experiences. The metric for success would be not the number of installs an application receives, but user engagement and happiness. Environments that focus on more than viral growth cultivate healthy, organic growth and usage. This contributes to the long-term sustainability of social platforms for both users and developers.

To that end, you’ll notice there are a number of functions in the OpenSocial API starting with “request” (e.g. requestShareApp, requestSendMessage). These functions define an agreement between the applications developer and the host container that allows the container to optionally prompt the user for more input, or simply deny the request. While each container will be able to define its own policy, we encourage apps developers and containers to take advantage of these functions to create an “install-free” user experience.

This was my first SXSW. I have always wanted to check it out, and it has certainly been a very different conference. The best part about it is the fact that everyone in the valley seems to meet down in Austin, and they are ready for a good time.

The content itself is also very different. Having a conference which is all panels is a strange choice, as it is bloody hard to do a good panel. The first thing that you have to do is have confrontation. The panelists should realise that this is entertainment and almost make it a game. Be contrary. Argue. Just don’t take it personal. Sitting and listening to “I agree with you Bob. I also think you should….” is a touch painful.

The “browser wars” panel had some spirit. Brendan and Chris weren’t going at it like, but they were having some fun up there.

Something Chris said (on the Web Standards panel) resonated:

“Make this a good decision for Microsoft”

I want to support Chris, and the other proponents in the IE team that I do believe are trying to do the right thing. I think that it is our responsibility to pump them up when they do good things just as much as we have to hold their feet to the fire when they do the opposite.

We need to do our work so any skeptics internal at Microsoft see that this has been the right move, and that they should open up more. We need to help IE 8 team beat the Silverlight team. The Web needs to win.

We also need to continue to push for even more transparency. I want Microsoft to take the good will that they have gotten and build on it. Don’t go dark on us until another beta. Open up a digg style database that lets people vote on features that they want to see. There are missing features that, without conversation, don’t make sense. Why didn’t they rev the DOM events? Have some town hall meetings. Invite the community up to Redmond, but if you do this, you have to actually listen and work with us. If done right, IE 8 will become a fantastic browser with the support of the development world.

How about that for a quick turn around?

Talking with code is powerful. Miguel posted screenshots of Mono running on the iPhone whereas Sun talked about Java running on it.

I always feel like I would like a reason to get into Mono, but never find one.

I believe that 2008 and beyond will be huge for mashups and APIs. We are going to move beyond the world of “Look, I took some data and put it together with a Google Map and Calendar” and have full featured read/write in browser APIs thanks in part to the slew of cross domain friendly features that are coming from browsers, Gears, and developer hacks.

I have talked about the blog.gears example, that shows how you can use Blogger as a back-end for a blog system. It seems quite obvious to me that if you are building a Web application that isn’t the Next Blog Thing, why would you want to spend any time building a blog system to get that functionality in the product. You have a couple of choices beyond writing it yourself. You could grab an open source blogging engine (there are many great ones), you could use a service and have blog.* CNAME over, or if you want tight integration you could do what blog.gears does, and use a JavaScript API to access blogger as the store and have it hidden from the user.

I got to thinking, how will the fact that it is easier to integrate with sites through richer APIs affect M & A?

An example that got me thinking about this is Dopplr and TripIt. Dopplr is a phenomenal service that seems to nail usability and the art of doing one thing, and doing it really well. It is clean. It has subtle touches that I love (the personal colors in the header icon and favicon even).

Them came along TripIt. The killer feature that it has is the ability to email your itineraries that you got from online sites and airlines to the system, and it groks a bunch of the formats and can thus suck them in automatically. Once you hit Apple-F, you are done, and you see the new information appear in your TripIt iCal.

Compare this to Dopplr. For a long time you would manually input your travel information in some shape or form. At the London Future of Web Apps I met Matt Biddulph, who not only was a fantastic, nice, fun guy, who gave the best talk at the event, but also was able to flip a bit which enabled Dopplr to read one of my Google Calendars. This feature is now in the wild for all. That was a great improvement, as I could setup a “Travel” calendar that Dopplr reads from.

I still had to keep that calendar going through. When TripIt came out, I heard cries of Dopplr fans that they should buy TripIt, or merge, or just copy the functionality. That isn’t the way with 2008. Instead, Matt was able to integrate with TripIt in a very simple way.

TripIt produces an iCal calendar from it’s data, and you can simply tie Dopplr to that calendar… and ta da!

I have been in quite a few meetings recently where the topic of buy has changed to be integrate through APIs. This enables each piece to grow, and to have people work on one small thing and make it the best it can be.

Of course, there is a time and a place for buyouts and mergers, but I wonder if they will be a little less frequent now. Then the game changes to being the platform, and being able to monetise it (a.k.a. make money to feed your family!)

Fixing calendars

As an aside, I still find a lot of pain with calendar systems. The main problem that I have is that I want events to cross various calendars, but collapse them in my view. For example, if I am going on a trip, I want my wife to see it, as well as my work colleagues. I don’t want to have to duplicate the entry in multiple calendars and then see the same darn thing repeatedly.