Below is the presentation I gave to the Austin MongoDB Day on 3/27/2010. I talked about the design decisions one needs to make when determining whether to introduce a document database like MongoDB into an existing application built on a relational database. I give a few examples of how we’ve made MongoDB and our MySQL database live together in harmony inside CheapTweet.
I attended the Lone Star Ruby Conference (LSRC), held here in Austin over the past two days. As this was my first conference on the topic, I thought I would share some observations. First, a vigorous caveat emptor… I’m a former Java guy still relatively new to the Ruby world. At the very least I hope to provide the humble perspective of a transplant from the crowded streets of Javaopolis to the rolling hills of Ruby country. So here goes…
Rubyists aren’t afraid of change (and some churn)
I’ve long been an interested outsider to Ruby and Rails – following along on the fringes for a couple years now by reading articles, running irb occasionally and generating some scaffolds. At that distance, you basically see Ruby and Rails. What you don’t see is the constant churn of open source projects, plugins, development tools, GUI toolkits, ideologies and best practices. Gregg Pollack and Jason Seifer’s talk on innovations in the last year and Evan Phoenix‘s keynote about Ruby memes made the currents of change pretty clear. Java experienced a lot of change during my 8 years but it definitely seemed to be at a more staid pace. There were a few bigger, more corporate, entities driving it (Sun, Apache, IBM) and fewer mythologized personalities like why. In the Ruby community, a lot of energy seems to be expended reinventing various wheels (as Evan pointed out with his list of ARGV processors). There’s a fine distinction between a healthy competition of ideas and a naval-gazing, ego-stroking churn that wastes time. That said, I would never stand in the way of the free market of ideas. So, by all means, (with no apologies to Mao) let 1000 ARGV processors bloom and let’s see which stick.
There are some surprising technology holes – but they’re being filled
As a former Java programmer who worked deeply with concurrency, Ruby’s after-thought of a concurrency model frightened me a bit. Java, though described by Dave Thomas on the last night’s panel as “a blunt tool”, has a basement filled with extremely sharp swords known as threads and a well-defined concurrency model. But, you say, Ruby has Threads. Yes, it does, but it’s a shadow of what’s available in Java. There, you can wield the sharp tools of concurrency with great effect on difficult problems but you can certainly stab yourself without understanding memory consistency effects, atomicity concerns and everything else.
Until recently, it seems the Rubyist approach to most of these issues has been to ignore them by slapping in a Big Fat Mutex. As someone who’s dealt with connection thread pools for RDBMs access for a long time, I was surprised to learn how innovative the non-blocking MySQL connector being worked on by espace as part of NeverBlock was considered. Fibers, mentioned by both Matz and Bruce Williams in discussing Ruby 1.9, offer a light-weight cooperative approach to something resembling concurrency. It was also heartening to hear Matz talk about how scalability is a big concern for the future of Ruby. Of course, no mention of these issues in Ruby is complete without noting that Ruby (and Rails) has been able to achieve a great deal in this area by using processes. This is usually a pretty simple and straightforward approach but it’s fairly large-grained and could certainly stand to be augmented with more sophisticated fine-grained capabilities that live inside the Interpreter.
Despite the above grumbling about concurrency, Ruby as a language is a beautiful thing. It really is damn pleasant to write Ruby code. I think this is a direct extension of Matz’s personality and concerns. In his keynote, he spoke powerfully on the need to see a prgramming language as part of the human interface to computers and the need to make that interface as joyful as possible to use. I don’t think I’ve once read “Joy” as a chief requirement in a JSR submitted to the Java Community Process for inclusion into Sun’s Java spec. That alone is probably enough reason to switch to Ruby. I do wonder how Matz’s vision of a humane language will hold up under the predicted onslaught of mindless Java-drones such as me that will create the 3 million new Ruby programmers expected over the next few years. As for that…
Don’t fear the hordes
We’re not all mindless and we’re not all drones. The unspoken sentiment when talking about the future growth of Ruby was “things are ok now because we’re all smart and dedicated craftsmen, unlike people who are using Java but will eventually invade beautiful ruby-land and make it ‘enterprisey’”. Growth is stressful for any group, especially one that gleefully defines itself as a minority in opposition to the mainstream as I believe Rubyists do. However, I think it benefits no one to assume that new Rubyists who may come to it later than you did are any less smart, dedicated or concerned about their work than you are. A community that doesn’t grow is bound to become introverted and ultimately stagnant. It would be a great loss if the Ruby community did that. The good news is I don’t think it will. Personally, I’ve felt welcomed by the Austin Rails community and I’ve also found plenty of resources elsewhere to help me learn. The best thing thing for Ruby’s future is to continue to embrace the hordes and show them what they’ve been missing.
And, In conclusion…
There are an incredible number of smart people that truly seem to love Ruby and want to see it succeed. Though there are ideologies, squabbles and disagreements, the part of the community assembled at LSRC was as close to a meritocracy as I’ve personally seen. The power in Ruby seems to lie with those that have most demonstrated their technical abilities and not with those that have the right corporate affiliations. This focus on merit leads to the sometimes duplicative and anarchic approach to developing new technology as people compete with their ideas. Ultimately, though, this is probably Ruby’s greatest strength and will serve it well in the future. I’m looking forward to being a part of it.
By the way, thanks to the Lone Star Ruby Foundation for putting on the conference. Great job. See you all at LSRC 2009.
Neil McAllister at Fatal Exception, inspired by the recent announcement that some flash data will be exposed to search engines asks the very intriguing question, “Is the Web still the Web?” The reason for asking is the proliferation of Rich Internet Application (RIA) technologies such as the aforementioned Flash, Silverlight, Google Web Toolkit, and AJAX (sort of). As background, he invokes a history in which Tim Berners-Lee granted us simple text-only documents encoded in HTML. This is, apparently, The Way The Web Is Supposed To Be. He then draws the distinction between RIAs and HTML and asks:
Is it still the Web if it’s not really hypertext? Is it still the Web if you can’t navigate directly to specific content? Is it still the Web if the content can’t be indexed and searched? Is it still the Web if you can only view the application on certain clients or devices? Is it still the Web if you can’t view source?
My answer on all these counts: “Yes”. I’m pretty sure you could replace the term “RIAs” with “images” or “videos” in his argument at various points during the evolution of the web from nicely marked up physics documents all the way to YouTube. Point being that HTTP (as one of the key technologies which underpins the web) only asks that we be able to reference a resource via a URI but makes no claims to the representation of that resource. It’s a testament to the foresight of the original designers of web technologies that HTTP describes only how we locate, modify and de-reference resources and doesn’t come with a dependency on representing those resources in HTML. Neil seems to confuse “resource” with “HTML document”. They need not be the same thing. That would be poor design.
Text-based indexing and search as well as “view source” are (incredibly useful) byproducts of the fact that so many of the resources on the web are represented as HTML. Though it’s hard to remember a time before Google roamed the earth, it hasn’t been that long ago that text-based indexing and search didn’t really work either. In time these other representations of resources will be mined, indexed and made searchable. There’s a lot of money and a lot of smart people trying to make that happen.
As for whether or not it’s still the web if you can only view it on certain clients? Well, as anyone who’s ever tried to develop a standards compliant site that also works in IE6 can attest, even relatively simple HTML web resources have client-specific dependencies. As today’s limited devices get more powerful and as browsers (hopefully) converge towards a reasonable baseline of standards these issues, too, shall pass.
This leaves the hypertext question. The reason we call it the “web” is due to the web-like nature of the links going from one resource to another. HTML does a fantastic job of providing this web of links (the hyptertext) with that simple <a> tag we know and love. If these new technologies don’t encourage connections between resources then they’re not contributing to the “web-ness” of the web. There are two parts to this: linking to other resources and allowing themselves to be linked to. Just because they’re not HTML doesn’t mean you can’t do these things. You can create links to other resources with these technologies and you can create URIs that can point to resources “within” a resource represented by these technologies. That’s not to say you can’t create a Flash site with no outgoing links and no URIs to hook into for incoming links. Of course you can just as easily create a dead-end HTML page with no anchors.
So yes, in my opinion, the web is still the web. Because of the great separation of concerns in the design of the web’s technologies, people have been able to extend it far beyond the original vision as a document sharing mechanism. It’s the greatest platform for experimentation in all the ways we can connect and deliver information yet conceived. Because of this, there will always be innovations that push the boundaries of how we’ve experienced it in the past. RIAs are just another part of the web and its continued evolution.
Inspired by conversations with some smart people at a recent Semantic Web Austin event, I’ve undertaken to restart my education on semantic web technologies like RDF, RDFa, Microformats, etc. When I wear my web developer hat, I’m definitely an advocate of clean semantic markup that correctly describes the structure of the data on the page. These technologies take that approach further (in some cases much, much further). In general, that seems like an unquestionably good idea. More semantic structure means more data portability and data discovery and therefore a more powerful web. It’s probably even a necessary step towards a WebOS.
However, in my limited research to this point, it seems there’s an elephant in the room in all this advocacy. Inevitably discussions of semantic technologies include “better search” as a chief raison d’etre for their use. We’ll have search engines that “understand” the machine readable data on our pages or RDF descriptions which can then draw logical inferences from the relationships among the universe of web resources. But, what if the semantic data is incorrect or just downright dishonest? Over-reliance on easily spammed meta tags gave us garbage in and garbage out in Altavista and Excite back in the 90s. It would be trivial to take my RDFa structured blog post, move it to a spam blog, find the semantically marked-up creator element, change it to someone else and republish. Poof! My finely crafted blog post on the semantic web is now selling ads for herbal remedies to unsuspecting web users with poor search skills. Of course, it’s also easy to just out and out lie when describing content. Maybe I’m not really Angelina Jolie‘s spouse or Bill Gates‘ neighbor even though I swear I am in my XFN standard rel attributes.
I would imagine that one thing that sets these approaches apart from 90s meta tags is the fact that many of these are used to specify relationships between resources which must be symmetric. Angelina’s resource dereferenced from her URI must indicate that I’m her spouse as well for that XFN relationship to be “believed” by a semantic web search that understands XFN. (How Angelina or any of us feel about being boiled down to an authoritative web resource identified by a URI is another issue.) Of course some people will try to game any system but I’m sure the vast majority of web users (or publishing tools) will include this structured data for legitimate purposes. But all this does make me wonder how much search engines will ultimately be able to rely on semantic data for drawing the intelligent inferences we hope to see from them. Can any of you out there that know more about these technologies help me better understand how we can ensure semantic data isn’t telling lies? If so, leave a comment; I’d love to know more.
I started playing with Erlang last year. Mostly that meant reading the Joe Armstrong book, looking at ejabberd and writing a little code. Sadly, I’ve not had the chance to go much beyond the “playing” stage. Anyway, I’ve got a soft spot for functional languages like Erlang since my Programming Language Theory class in undergrad where we used ML. I especially like the way Joe and the rest of the people behind Erlang have built it for concurrency via tiny processes that share nothing and have provided a framework for building apps that know how to operate correctly in soft-realtime. It’s a very different way of thinking about building systems and seems to be remarkably effective.
The Erlang guys have to be feeling pretty good to hear that Facebook has used Erlang as a core component of their new chat service. (High Scalability also has a good writeup.) As Facebook engineer Eugene Letuchy describes it, their implementation uses XHR long polling which means tons of open HTTP connections. Spread this out over 70 million potential users and it’s not hard to see that Apache would break down pretty quickly. Basically it sounds like they have tons of Erlang processes servicing these connections and holding messages and presence events for users in memory if there’s not an open connection to the client.
Eugene mentions the challenge of delivering presence information as being more difficult than real-time messaging. (Something I thought a lot about when building Effusia.) He lays out the issues inherent in broadcasting presence on every state change in the form of a nasty worst-case asymptotic complexity:
The naive implementation of sending a notification to all friends whenever a user comes online or goes offline has a worst case cost of O(average friendlist size * peak users * churn rate) messages/second, where churn rate is the frequency with which users come online and go offline, in events/second.
However, he doesn’t really go into any detail on how they solved this problem. I can only assume they used some form of periodic polling on a need-to-know basis and/or coalescing friend presence updates in such a way that they’re only occasionally sent to a user.
A few other interesting notes… Apparently they used C++ to do the chat logs as Erlang is not that great at raw I/O. They also apparently use Thrift to glue everything together. (Reminds me I need to look into Thrift in more detail.)
Cesar Torres analyzed the new Facebook profile design yesterday as did TechCrunch. Both come to the same conclusion: Facebook is trying to become a web operating system. Both cite the use of a Mac OSX-style menu design (a weak indicator of an “OS” in my opinion) but Cesar goes farther to mention Facebook’s application platform, chat client and data portability developments. So, does an app platform plus a menu bar plus chat an OS make? Even a nascent OS? My answer to that is that Facebook, while acting more and more like a web-based OS is just a part of the Web OS.
What is an OS?
The whole concept of what makes an OS is a bit hard to pin down. At this point, I’d love to offer up the definition of an OS from my undergrad operating systems book but it appears to be missing chapter one. Suffice it to say it would have said something about CPU management, process management and probably something about batch jobs (it was really old when I got to it in 2000). Instead I’ll quote Wikipedia’s article on the topic:
An operating system is the software component of a computer system that is responsible for the management and coordination of activities and the sharing of the resources of the computer. The operating system (OS) acts as a host for application programs that are run on the machine. As a host, one of the purposes of an operating system is to handle the details of the operation of the hardware. This relieves application programs from having to manage these details and makes it easier to write applications.
If you’re a programmer and you see something that promises to relieve you from the details of something, you know you’re seeing an abstraction. Programmers love abstractions. In the name of simplification, we layer abstraction after abstraction on top of each other until we feel like we’ve got something easy enough to be productive. (And then we write something on top of that.) We write an OS to hide the hardware, we write programming languages that hide the details of the OS, we write APIs to make tasks easier in the programming languages and on and on and on. Fundamentally, an OS is just an abstraction over the bare metal.
This definition of the OS as an abstraction layer for application development is, of course, pretty technical. I would say that most people consider an OS (if they were to consider it) as the thing that lets them run their email app, their word processor or their web browser. In general, it should fade into the background and let people get on with what they want to get done using their actual apps. If it does bring itself into the foreground it should be by providing shiny eye candy and not with shiny blue screens.
Here’s the kicker though… Beyond just running our apps, we also expect our OS to allow them to share data. As OSes have evolved, we’ve come to think of them less as a resource management tool and more of a collection of useful apps that can all work reasonably well together when facilitated by the OS environment. This goes back at least to the Unix concept of small programs that take an input, perform a useful function and provide an output. This allows for all sorts of nifty command line piping and chaining of outputs to inputs; all facilitated by the operating system. I believe you could say this pattern is the precedent for today’s mashups.
So here’s a working definition. An OS is the thing that manages the hard low-level stuff so people can write apps so we can get things done by using and combining those apps. So does a web OS do this but just on the web?
Are we there yet?
I think we do have a nascent Web OS but it’s not one that’s provided by a single entity. It’s not Facebook or Google. It goes across the web as a whole. Each of these services provides a component of the overall experience much in the same way that Unix utilities do. Though Facebook search reminds us of OSX Spotlight; search on the web OS is located at google.com (for now).
Of course, the Web OS is being built beyond just our user experience interacting with web sites through our browser. The data sharing of the Web OS is being enabled by a host of technologies available to application developers. At the lowest level, we have the fundamental architecture of the web itself, HTTP, which allows for any kind of resource to be located and accessed. We can use HTTP to access any sort of data, but the critical types of data to the web OS are the meta ones that we can use to actually describe data: XML, JSON and even HTML. These form the basis for all the APIs we’ve come to know and love from all the web applications out there that have our data. Over the past few years we’ve begun to scratch the surface of what we can do when we can pipe information from one app to another via the environment provided us by this Web OS. From Google Maps mashups to the nearly infinite number of Twitter apps, we’re beginning to leverage these services in all kinds of ways. Once application developers can begin to rely on these services to abstract away the complexity of performing certain tasks whether that’s raw data storage, identity, search, messaging or the social graph then we’ll have a true Web OS.
Right now, there are still too many barriers. Many (maybe most) apps don’t allow data to move from place to place or put up walled gardens around what APIs and platforms they do offer. With data portability, we’re moving in the right direction (primarily with social data at least), but we’re not there yet. And, of course, there are still tons of applications that don’t (and may never) live in the cloud and so can’t participate fully in the emerging OS.
If we’re not there yet, where are we going?
We’ve still got a long way to go yet with the Web OS, but the pieces are emerging. Applications are moving into the cloud and we’re in the early days of programmatic communication between our various web utilities. We’re progressively abstracting away the hard parts of building really complex and powerful systems. That’s why programmers obsess about abstractions; they make hard things simple. And when hard things become simple, you’ve just taken a step to making even harder things possible. Ultimately the Web OS goes way beyond the placement of menus in Facebook, it will provide us the platform to make the previously impossible possible.