« November 2007 | Main | January 2008 »
December 26, 2007
50 Blog Posts I'd Like to See in 2008
A while back, noted social media commentator Chris Brogan published a list of 100 blog posts he'd like to see other people write. The list was meant as a spur in the backside of readers who suffer from Blogger's Block, a final blow to the excuse that they can't think of anything to write about. While Brogan's actual topics were too focused on the incestuously insider world of social media for my taste ("44. The Difference Between Fark and Truemors"), the format was inspiring; I immediately started putting together my own list of posts I'd like to see.
Inevitably, my list reflects my interests and bias just as Brogan's does his. The posts I'd like to see are largely aimed at people like me: people who picked up Ruby in the last couple of years because of Rails and have got the language and framework pretty handily under control but lack the deep rooting in technical fundamentals and culture that comes from having gone to school for this stuff or having had a long career in it.
The theme is: "I know Ruby. Now what?"
Like Brogan, I'll ask that if you write on one of these topics link back here or come back to comment so I can find your post and gradually turn this list into something of a directory of this kind of info. Now, without further ado, here's my list:
- My First C Extension
- A Set Theory Primer for Relational Database Users
- What I Get Out of My Local Ruby Users' Group
- All About Postgres Indexes
- Ruby Was My First Language, Here's My Second
- The Five Most Useful Things I Learned in Computer Science
- My First Contribution to an Open Source Project
- Participating Actively on Mailing Lists
- Participating Actively on IRC
- Understanding and Using Threads
- Keeping Up to Date with New Developments to the Libraries You Care About
- How to Write Good API Documentation
- An Intro to Code Research, Or: Is There A Library for That?
- An Intro to Queues, Pools, Runners, and Inter-Process Communication
- Unicode Once and for All
- Timezones Once and for All
- How Do Migrations Actually Work?
- Basic System Administration for Developers
- Domain-based Programming in Javascript
- Instrumenting My Rails App
- Approaches to Processing Large Data Sets
- A Developer's Guide to Deployment
- Bootstrapping Rails Development for the Absolute Beginner
- Hey Look, I Did Something Useful with LISP!
- Approaching Your Idols: How to Start Conversations with Gray Beards and Gurus
- My Painless Gem Integration System
- Using Your Own Documentation
- Building a Rails App from Someone Else's Excel Spreadsheet
- Useful Ruby Outside of Rails
- Ruby as PHP Replacement
- Writing Simple CGI Scripts with Ruby
- Finding and Fixing Memory Leaks in Rails, Or: Why Are My Mongrels So Big?
- Writing and Managing Long-Running Processes
- SMS Integration in Rails
- What I Learned from Working with Statically Typed Languages
- My First Profiling Session
- Big Team Tools and Small Teams, Or: Why Is My Trac Empty?
- Rules of Thumb for Performant Ruby Code
- A Survey of Persistence Strategies Beyond Relational Databases
- Living with a Large Schema
- My First Cocoa Program
- Writing and Distributing Rails Apps for Desktop Installation
- Domain Registration and Hosting for Rails Apps
- Setting Up Subdomains and Pointing Them at Rails Apps
- My First Apache Configuration
- My First Nginx Configuration
- Is It Worth Releasing?: When to Open Source Your Work
- An Introduction to GUI Programming
- Lessons from Java for Someone Who's Never Written Any
- Practical Tips for Learning Protocols and Reading Specs
Posted by Greg at 1:18 PM | Comments (3)
December 17, 2007
What Happens When Web-Scale Computing Becomes a Commodity?
With the announcement of Amazon's much-anticipated SimpleDB service this week, we now officially live in a world where the kind of enormous systems run by Google, Yahoo, Ebay, et al — systems that power huge portions of the web (where 500+ million users is totally mundane) — are available on demand in small doses and at reasonable prices to anyone who needs them. Amazon Web Services now provides all the necessary infrastructure to run applications that host millions of files for download, persist hundreds of millions of database records, and run thousands of processes, all without building or maintaining any physical infrastructure.
On this infrastructure, the only real difference between running a small application (a custom CMS for a medium-sized non-profit, for example) and a large one (say, Digg) is the size of your monthly bill. And as other companies besides Amazon enter this market as a relatively simple way to monetize their huge existing infrastructure costs the size of that bill will fall as well.So, what are we talking about here? Within a few years, a scale of computation that is currently only available to a handful of multi-billion dollar companies will be available to any pair of dorm room-bound hacker kids with $30/mo. and a pair of MacBooks.
Just as the rise of commodity server hardware and open source software revolutionized the web over the last ten years, it would be reasonable to expect changes of similarly breathtaking scope as we undergo the commoditization of web-scale computing over the next ten.
For a few clues as to what happens when the current, if obscure, state of the art becomes an industry-standard lowest common denominator, it helps to look at some history. This has happened at least twice in the last thirty years: once when industry standardization around x86 hardware lead to the collapse in prices for DOS- and then Windows-compatible PCs that made them ubiquitous around the world; and again when these same PCs reached a level of power and the open source software written to run on them reached a level of affordability and reliability that, together, they displaced the expensive and proprietary server systems and radically lowered the barrier to entry for web-development leading, as Tim O'Reilly has clearly outlined, to Web 2.0.
Each of these transitions had the same two high level effects: they made it cheaper to produce professional caliber work and they increased the value of openness.
The rise of the ubiquitous, cheap, and powerful PC has created near-universal access to the best digital tools available. Professional accountants, graphic designers, record producers, photographers, and countless others do their work on exactly the same relatively cheap hardware available to the average consumer playing games and writing email.
Similarly, the precipitous pricing drop in web application development and deployment environments caused by the birth of the LAMP stack and the commodity servers on which it runs made it possible for startups like del.icio.us and Flickr without first raising millions of dollars in venture funding to buy Sun Workstations. (And this doesn't even take into account the second order revolution in the content industry caused by the cheap-to-free hosting publishing tools created by these very startups and run on commodity web hosting.)
The openness story is, if anything, even more shocking. Like fruit flies spontaneously generating out of garbage, Linux grew out of the universally available commodity PCs with their high levels of hardware compatibility. The same process that filled the PC landscape with identical gray boxes running Windows made it possible for a few OS geeks from obscure countries to build, in their spare time, an operating system that could feasibly run, for free, on all of them.
Similarly, the commoditization provided by the triumph of the LAMP stack made it possible for a handful of people to build non-profit web applications like Wikipedia and Craig's List whose only mission is to make useful information universally available to anyone who wants it.
Now. What form will these two kinds of changes take with the use of web-scale computing?
Let's start out with the ability to produce professional caliber work more cheaply. Currently now, it was only feasibly to build web-scale applications if the market for them was also web-scale. That is, you only got to use resource intensive technologies like full web spidering or massive file caching if you were building a mainstream service with a potential audience of 500+ million daily users. This meant the basics: search, ads, maybe games.
But, when doing these things only costs a couple hundred bucks a month, a great many smaller markets suddenly become lucrative. Could you build value on top of a dynamically updated list of every mention made of every stock ticker symbol anywhere on the web? How about every mention of every trademark? Or every mention of every mp3? Since the overhead for extracting that value no longer includes building and maintaining enormous data centers it might actually become feasible to build service with such requirements.
(As a side note, it's worth noting that one of the corollary effects of such a change is that it's no longer necessary to take tens of millions of dollars in venture funding in order to run a business that requires web-scale computing. This means even more leverage for startups when negotiating for what little funding they do need and even shakier times ahead for the VCs out there looking to invest their billions in only a small handful of huge deals.)
And what about openness? What new prospects for collaborative networked volunteer-driven world-improving projects might we see?
How about a Web OS that runs on top of a peer-to-peer network of commodity machines that's available to anyone who contributes some spare cycles to the cause — like a Google-scale Linux install running on top of SETI-at-home? Or what about a world-wide effort to federate the tracking of all manufactured objects via their RFID tags in order to maximize the efficiency of their recycling, discover any of their toxic effects, and rollback global warming?
These ideas may seem silly or grandiose, but so did Google when Larry and Sergei were still students or Linux when it was just an excuse for mailing list flame wars. This is one of those times. A lot of new things just became possible.
Tagged: simpledb, amazon, google, web-scale, computing, linuxPosted by Greg at 8:08 PM | Comments (7)
December 9, 2007
Steve Albini and Avi Bryant: Separated at Birth?
Avi Bryant is the Steve Albini of web development. Or maybe it's the other way around. Bryant is a Smalltalk programmer famous for creating Seaside, a web development framework that reverses a lot of the common assumptions shared by its peers and competitors; Albini is a musician and record producer famous for his uncompromising focus on making recordings that serve as authentic documents of bands' natural sounds.
Albini and Bryant share a singular style of self-presentation that combines a penchant for no-punches-pulled expression with a kind of gregarious grouchiness to build a strong sense of their own authenticity and authority. This style lets them reject much of the common wisdom in their respective fields — making everyone else seem simple minded (and possibly evil) for not doing so — while retaining a measure of folksy charm.
They even sound and look a little alike (if you can make your mind's eye bridge the beard/glasses divide).
Tagged: albini, bryant, seaside, electrical, chicago, convergence
Posted by Greg at 3:18 PM | Comments (0)
December 5, 2007
Why Don't Social Networks Provide RSS Feeds?
The total lack of RSS feeds on many of the most popular social networks seems shocking. More and more, across the net, RSS feeds have become the standard way to make important oft-updated information universally and easily accessible. In addition to increasing user convenience, feeds allow sites to participate in a whole galaxy of mash-ups, pipes, and remixes. Meanwhile, social networks are like black holes: they suck in your data and attention while emitting nothing in return. Facebook's failure to offer one for your "News Feed" (it's most prominent UI feature) glares especially darkly in this regard since they explicitly describe this information as a feed without offering it to you as one.
I can think of three reasons why social networks might not offer feeds, none of them especially flattering:
- Lack of Demand, Part 1. It's possible that the average Facebook user is so technically unsophisticated that the company's UI designers made a conscious, informed choice, based on real research, and decided that explaining and implementing the feature to their high standard of clarity and usability was just too challenging a prospect. Possible, but unlikely. No less populist a site than Blogger managed to explain not only the process RSS subscription to their audience, but also a whole series of RSS publishing options — a much more complicated topic.
- Lack of Demand, Part 2. It's also possible that, when it comes down to it, people don't actually have an urgent need to know what's going on in their social networks; the updates to their News Feed — the fact that "Cameron Hill added the Vampires application" or that "Marcus Estes removed 'hidden telecommunications'" from his interests" or that "Jamie Freedman added the Optical Illusions Challenge application" — may just not be all that vital. Oh, how I wish I believed this was true. In reality, though, the number of hours clocked on the site itself by each of Facebook's 50 million users seems to debunk it pretty thoroughly. I mean, the mere existence of the word Facecrack on its own seems to end the "Lack of Demand" conversation pretty conclusively, doesn't it?
- Greed. With Lack of Demand shot down, we're pretty much left looking greed unavoidably in the eye. As Cory Doctorow recently righteously griped — and as the growing Facebook Beacon scandal confirms — nearly every technical decision Facebook makes is designed with a sole mission in mind: generating more ad impressions. Why don't Facebook notification emails contain the message's actual content? So you'll click through to the site and view more ads, of course! Not that you can't put ads in feed items (or even emails), but I'm sure the average trip to Facebook generates more than a single page view, which amplifies impressions, and removes a modal change, which improves click-throughs and conversions.
There are, of course, exceptions to this logic. Digg, Twitter, and a few other sites, mostly with more technically savvy audiences, generate feeds galore (and, in the case of Twitter, actually push their content out to a variety of messaging platforms most of which present major obstacles to advertising), but the general story remains: Facebook and MySpace, the mainstream social networks, don't generate feeds.
And I think this is an opportunity for someone.
What would you do with an RSS feed from your social network of choice? What could you mash it up or remix it with? Would having access to a feed change how you operate your account? How would a highly feed-oriented social network that emanated data and activity in all directions be different from today's black holes? Would it be better?
Tagged: social network, feed, rss, greedfacebookPosted by Greg at 2:11 AM | Comments (3)
