Charles Engelke's Blog

Well, they saved the best for last.  In general I found this year’s OSCON to be pretty weak in content, but today has been great.  In particular, Simon Wardley’s keynote was excellent (and clearly much longer than it was expected to be, but well worth the time), and Tim Bray’s talk on Practical Concurrency was the best of the conference.

We will close out with what is sure to be an entertaining talk on the world’s worst inventions from Paul Fenwick, and then be on our own for the rest of the day until our red-eye flight home late tonight.

Tom Hughes-Croucher is going to tell us about Node.js, a JavaScript web server.  He starts by offering a doughnut to anyone asking non-awful questions.

Why server-side JavaScript?  Well, first there are a lot of JavaScript programmers.  Pretty much all web programmers use it, because that’s all they have available on the client.  So why not use it on the server, too?  And why write things twice, separately for the server and client sides?  And progressive enhancement is free (close enough to free).

JavaScript runtimes include V8 (Google) in C++, Spider Monkey (Mozilla) in C++, Rhino (Mozilla) in Java, JavaScript Core (Apple) in C++.  V8 is significantly faster than Spider Monkey (at the moment), but Mozilla is coming back with Trace Monkey.  Google’s success with V8 has sparked a speed war among JavaScript and browser builders.

Node.js is a server-side JavaScript process that uses V8.  It runs on anything POSIX-enough. (May be okay on Cygwin on Windows.)  It’s non-blocking and event driven.  It uses the CommonJS module format (we’ll find out soon what that means).  Node is very fast.  It’s almost as fast as nginx, which is all native C and highly optimized.

Here’s some code (I think I got it down right):

var http = require('http');
http.createServer(function (req, res) {
   res.writeHead(200, {'Content-Type': 'text/plain'});
   res.end('Hello, World\n');
}).listen(8124, '127.0.0.1');
console.log('Server started.\n');

There are plenty of packages available for Node.js, which can be installed with NPM, the Node Package Manager.  Which is itself written in JavaScript.

He shows more examples, and explains how to use things.  A very good session.

I’m starting day 2 here with session on JavaScript.  First up is Programming Web Sockets by Sean Sullivan, to be followed by a talk on jQuery UI by Mike Hostetler and Jonathan Sharp.

Web sockets are a lightweight way for web servers and clients to communicate instead of using full HTTP.  Think of it as a push technology.  We start with an example of a multi-player game.  There are two specs to learn: the API and the protocol.  As a programmer, we care more about the API, which is how we use the facility.  He gives it all on one slide, which I don’t have time to show here.  Basically, instantiate a new WebSocket object, set some handlers for various events on it (like receiving and handling data: onopen, onmessage, onerror, onclose), and put data into it with a send method.  Eventually, call the close method to stop using the web socket.  It does look quite simple.

But how do I program the server-side?  That’s more fluid right now; the protocol specification is changing in incompatible ways.  On the browser side, we have support in Chrome 4.0.249.0 and later, Safari 5.0, Firefox 4.0.  IE 9?  Still not known.  Apparently (per a tweet from yesterday) Apple used to support web sockets in iOS, but now no longer does.  On the server side, there’s an enhancement request in for Apache httpd.  There’s a Python extension called pywebsocket available, though.  Django supports web sockets, and maybe some Ruby stuff, too.  Jetty has it.

No actual coding examples, which is a disappointment to me.  We’re finishing early, and have a long gap until the jQuery UI talk (which I think may be pretty full).

It is pretty full, but not standing-room only.

We start with effects, which are pretty ways to show changes on elements.  There’s not much meat here.  Now we move on to interactions, which are more functional.  For example, make an element draggable and attach handlers to various events related to that.  There’s also making a list sortable.

This is all great stuff, but I think I see why I have a hard time getting into it.  There isn’t a grand core idea here, but instead an enormous number of small, focused helper tools.  So a talk like this touches on one and then moves on right away.  Forty minutes of that is hard to stay focused on.  But now we’re getting a more complete coding example.  I don’t know; I like the functionality and appearance, but the necessary coding seems very complex for the examples.

It’s convinced me to use it, anyway.

The wi-fi is working great today.  (Maybe it wasn’t offered as wireless-N yesterday?  The access point was just called OSCONBG.)  But now the air conditioning is no good.  For the first time I’m uncomfortable.  It must be over 80.  The temperature isn’t so bad, but the air is completely stagnant.

Or is is DevOps?  Regardless, it still looks like an ugly name to me.  I’ve been hearing this word for two days now, and nobody ever bothers to define it, nor give the derivation of the word.  From context, the word is clearly combined from Development and Operations, and seems to refer to managing operations for applications deployed in the cloud.

It seems like a good idea to me.  I know I have long found that developers with some operations experience, or at least perspective, really bring a lot to the creation of easily deployed and managed systems.

This morning’s talk by Jonathan Stark was excellent.  In particular, I’m definitely going to be using jQTouch, and probably will use PhoneGap.  In fact, I think I’d like a version of PhoneGap for Windows – let me deploy a web application inside a native wrapper, with extensions that let me manipulate the machine via JavaScript.

Yesterday’s Cloud Summit was pretty good.  I didn’t get a lot of detailed, concrete information, but acquired a good overview of what’s going on and how the pieces all need to connect.  But today, the real conference begins.

The morning began with “keynotes”.  I put that in quotes, because they were more like lightning talks.  But since the speakers were mostly executives instead of technical staff, they each needed ten minutes to make their points, not just the five usually allocated to a lightning talk.  The talks were okay, and whenever one dragged it was over soon, but they didn’t add much.  If they just skipped them, and had one or two real, deeply interesting keynotes, for the entire conference, that would be a lot better.  As it is, the conference itself doesn’t get started until nearly 11:00 AM.

For the rest of the morning (actually, the middle of the day) I’m going to attend sessions on programming for mobile devices.  First up is Android, the Whats & Wherefores by Dan Morrill of Google.  I’m already somewhat familiar with Android, so may not see much new.  But the second half the session is about Building Mobile Apps with HTML, CSS, and JavaScript, by Jonathan Stark, and I am very deeply interested in that topic.  I like all mobile platforms, but I don’t want to have to master lots of different technologies.  I think web technologies are mature enough to meet my development needs.

Let’s see if things go better this afternoon.  We’re going to have a few debates in the afternoon, starting with one about the importance of open standards for cloud computing.  Sam Johnston of Google (his blog is here) starts the debate, speaking in favor of the importance of open standards.  After he’s had 15 minutes to present his case, Benjamin Black will have 15 minutes to make the opposite case.  Then there will be 15 minutes of back and forth, between the speakers and with a “jury” and audience members.

The “for” argument isn’t very interesting to me, because I already agree with what he’s saying.  I need to hear some contrary information when the opposition comes on.  Which is now starting.  Black starts by pointing to the dysfunctional processes often behind defining and agreeing to standards with a Monty Python video (the fish-slapping dance).  Then: what’s important?  Utility.  If it doesn’t solve my problem, I don’t care about standards.  Then interoperability.  Then being free of vendor lock-in (independence).  Those three aren’t all equal.

Some problems don’t need go past utility.  For example, SQL (in reality, not in theory).  His point seems to be that there is no meaningful interoperability between SQL implementations, yet we still use SQL.  Well, I don’t think I agree with the premise there.  A lack of perfect interoperability doesn’t mean that there isn’t any interoperability!

Suppose something new comes out with massive utility and a lot of imperfection.  People will adopt it rapidly.  Then you get lots of competition and exploration, and lots of “standards” that are all different from each other (think networking in the early days).  Eventually, the different islands begin to interoperate with each other as demanded by their users.  That’s where the cloud is now.  So it’s too early to define what the correct standards should be.

That happens in the next stage: maturation.  That’s where we worry about independence, not earlier.  Successful standards formalize what is already true.  “Standards are side effects of successful technology.” “All successful standards are de facto standards.”

All good points.  But is there nothing in cloud computing ready to benefit from the independence?  His next point is that, even if so, it’s too early.  Because as things become more standardized, the rate of innovation has to drop, and we aren’t ready for that to happen in the cloud.  Very good quote: Standardize too soon, and you lock in to the wrong thing.

Excellent speaker, and I agree with his points.  But not necessarily all his conclusions.  Mainly, I think some cloud issues are more mature that he seems to be saying, and are ready to improve interoperability, and perhaps even independence.  But he makes a great case.

There’s some back and forth and questions next.  It seems that they favor the “against” position.  But it seems that the question has changed a bit over the talk.  Now people are agreeing that a priori standards are bad.  But the question was about whether any standards were needed.

The next debate is on whether Open APIs are enough to prevent vendor lock-in.  George Reese will argue that they are; James Duncan will say that they aren’t.  Of course, the question starts with trying to determine just what would make an API “open”.  But that’s dismissed early on as not the core question.  It seems that the “pro” advocate is arguing against it: even if the APIs are open, if the platform itself isn’t, then you can’t take your top layer and move it elsewhere.

I don’t find this debate very interesting, though.  Nothing really new or useful for me.  But the first debate was excellent.  It’s a good format.

On the plus side, the conference Wi-fi is kind of working now.  It’s not great, but not dead, either.  I notice a lot of non-conference access points are now gone; I wonder if interference, rather than bandwidth, was the major problem.

I’ve had to switch to my phone because wifi is unusable. They say they have 60Mb/s, which sounds like a lot until you divide it by a few thousand users.

Swype on android is great, but requires too much attention while trying to listen.

It’s my first day at OSCON, and I’m starting off with the Cloud Summit.  This post isn’t going to be real reporting or notes on the entire session.  Much of the material isn’t new to me, so I’m just going to record things new to me that I want to be able to remember and find more about later.

The introduction is by Simon Wardley, giving background and introducing the speakers and topics we’ll see the rest of the day.  He compares Cloud Computing to the evolution of electricity as a utility, and references Douglas Parkhill’s 1966 book The Challenge of the Computer Utility.

Mark Masterson is talking about cloud computing and the enterprise.  Risk is the likelihood of failure times the cost of failure.  Business has almost totally focused on the first term in the equation, trying to reduce the likelihood of failure, because they viewed the cost of failure is more or less a fixed amount.  But it’s not, and cloud computing is one thing that can reduce that cost.  If you focus on reducing the odds of failure, you have to lock in your decisions very early, and can’t explore some options.  If instead you accept a higher chance of failure, and pursue options that have a low cost of failure instead, you give yourself more options.  And you manage your risk just as well as the other way.  (This sounds a lot like agile development methodologies to me; don’t try so hard to not fail, instead fail early and cheaply and correct your path as you go.)

Subar Kumaraswamy of eBay is talking next, about Security and Identity in Cloud.  He starts with a slide showing a frightened manager, surrounded by scary orange dangers of using cloud computing: Compliance, Rogue Administrator, Governance, and many others.  But this is followed by a slide of a focused and contented developer, surrounded by soothing green virtues of cloud computing: iterative in hours, self service, empowered developers, and more.  The rest of his talk is focused on one key area: identity management.

On to John Willis.  “Cloudy Operations.”  In a cloudy world, the prime constraint should be the time it takes to restore your data.  Because you can rebuild all the infrastructure on demand, even in case of a disaster.  But you can’t be up and running until your instance data is live.

“Cloud Myths, Schemes and Dirty Little Secrets” by Patrick Kerpan up next.  Focus has been on making the physical virtual – Citrix on the desktop, VMWare on the server or Amazon EC2.  Dirty little secrets.  Ephemeral versus persistent images.  Ephemeral images disappear, but persistent ones too easy to treat like metal, errors accumulate, history of changes lost.  If you have a lot of data in the cloud, you can’t get it out quickly.  State is the monster (sounds like the last talk).

What is generally happening around us now is the beginning of the long, slow migration of the traditional enterprise to agile infrastructure; whether public, private or hybrid cloud.

The last talk before the break is called “Curing Addiction is Easier” by Stephen O’Grady.  Everybody has an API, but what about interoperability?  He mentioned Delta Cloud initiative (or maybe that’s δ-cloud), which is a layer on top of the API, for that reason.  No one has portability, but it’s not really a problem.  Most businesses want a solution now, and will defer worrying about tomorrow if they can solve their problem today.

That concludes the Cloud Scene theme for the day.  Not a lot of new stuff for me, but it’s supposed to set the scene and get us all on the same level.  Between the break and lunch we’ll see some Future Thinking.