April 8, 2008
Note: The Pages o’ Peat have moved to http://peat.org/ — please update your bookmarks and references accordingly. Thank you!
Every now and then a set of technologies gets twisted together by a small group of dedicated people, and a new industry is born — a watershed event that demonstrates a new way of thinking about things, and throws out a lot of old rules.
There are a three that are coming together to trigger another watershed.
The first is open, popular, mobile Internet devices. Think Blackberry, iPhone, or the slew of new MIDs that Intel showed off a few days ago in Shanghai. These are built around the assumption of ubiquitous access to the Internet, high resolution displays, multimedia capabilities, and a bit of horsepower under the hood. Any college student can get their hands on the Android or iPhone or Windows Mobile SDKs and build a hot little application in their spare time.
The second is web services. It doesn’t matter if it’s WS* or REST or XML or JSON — the point is being able to query and manipulate data at a distance, with open protocols across public and private networks. Pick your web framework of choice … building a web service is almost a drag and drop process today.
The third and final piece is cheap and scalable cloud computing. The physical infrastructure capable of serving billions of transactions is available to anyone with a credit card and a little spare time on the weekend. Amazon’s Web Services, Google’s App Engine, and a slew of smaller providers sell scalable computing and bandwidth by the hour and gigabyte.
These three fit together to form a fundamentally different picture of mobile computing: light weight applications that fit in your pocket that take advantage of the local hardware, but seamlessly tap into “Internet scale” computing power and storage.
I’ve talked with a dozen entrepreneurs in as many months who are exploring these waters. Streaming media (push and pull), information discovery and analysis, mobile social interactions, and location aware applications all depend on this trinity of capabilities. I’m just one guy in a groundswell of people who are looking at the landscape and thinking “hot damn!”
What makes this so exciting is how easy it is to do today. You don’t need a dozen engineers and a multi-million dollar budget. You don’t need to negotiate with a corporate gatekeeper. You don’t need to pitch to VCs. You don’t need to wait.
2009 is going to bring a wave of media rich, location aware, always connected mobile applications to hundreds of millions of people. I’m confident we’ll see a real forehead slapper by the end of 2008 — a tool or service that is painfully obvious, but fundamentally changes how we think about a day to day task. It’ll make a millionaire or two, at the very least.
This will be fun. :)
April 2, 2007
Handy link of the day: http://gotapi.com/
All your favorite APIs in one place, with very friendly searching.
October 20, 2006
April 21, 2006
No doubt about it, I am up to my eyeballs in Ruby on Rails projects. It’s exciting to see what people want us to build—everything from niche content management tools, to workflow management apps, to massive social networking projects. Proposals come in from companies ranging from basement startups to tier one financial institutions. Rails is certainly not a secret anymore; it’s a genuine phenomenon, and it’s attracting a lot of attention.
That said, there’s a big difference between attracting clients and signing contracts. Somewhere along the line, a decision is made to start writing checks, and if you’re in the business of writing software, it’s extremely important to understand why that decision is made.
So, here’s the stunner for a lot of us geeks: that decision has little to do with Rails.
“OMG,” you gasp. “WTF. Heretic!”
I know, I know. I’ll go back to drinking the Kool-Aid in a bit … But hear me out!
Rails won’t make your product a better product. Rails won’t give you the features that your customers want. Rails won’t manage your project and make everything run smoother. Rails won’t cook you breakfast, mend your pants, walk your dog, or print bumper stickers1.
People write code. People design and manage infrastructure. People answer the phone and fix problems. People create attractive designs and optimize interactions. And, thankfully, people also cook breakfast, mend pants, and walk dogs.
Those who are willing to invest a significant amount of money in a web application want confidence in the people who build it for them. They know technologies don’t guarantee anything, and they know buzzwords don’t make the product. They want developers who produce efficient and high quality code, designers with good taste and excellent CSS skills, and managers who return their calls and take a personal interest in their projects.
Quality people can produce excellent products with whatever platforms or languages they’ve honed their skills on. Java? Sure. PHP? Why not? C#? Yup!
So, why do we exclusively develop with Ruby on Rails? Because we’ve used Java, PHP, C#, Python, Perl, and a shocking array of slightly obscure languages. We’ve seen how language affects architecture, run the gauntlet of application servers, and rescued projects from spaghetti code hell. We’ve started our own companies, created our own products, and in the end, we recognize that Ruby on Rails works well for us, and how we build web applications.
In short, the magic happens when the right people people get their hands on the right tools for the job.
Sell the whole package: your people, your resources, your experience .. not just the technology.
1 Actually, this is a lie—Rails does print bumper stickers. One of our clients uses Rails to manage the printing of custom calendars, photo mugs, and all sorts of other photo paraphernalia.
2 Taking the Delicatessen analogy a bit further: Technology may be the buttery creamy icing, but people are the delicious fudgy cake; technology might catch a client’s attention, but nothing satisfies the appetite like good people.
April 18, 2006
… in the development room:
TDD makes writing code super easy. All the hard thinking happens when you’re writing the tests and designing the API, and then it’s just red light / green light when you’re writing the implementation.
It seems that writing your tests first helps enforce the idea that you need to understand a problem before you can solve it. Particularly with large projects, building a comprehensive test harness is a fairly cheap way to explore architectural issues without committing to a particular implementation.