August 28, 2006

How easy is it to create your own online bookstore?

Very, very easy. You just have to be an Amazon Associate to do it, and be willing to only sell Amazon’s products.

Amazon’s service is called aStore, which lets you create … a store! It’s still in beta, but it only took me about 5 minutes to build a simple shop with only nine products: Peat’s Web App Books of Hotness, which probably gives you a good idea of what you’ll find there.

Beyond my simplistic demonstration, you can add pretty much anything in the Amazon catalog (not just books), lots of sidebar goodies for people to oogle while browsing, and a reasonable amount of customization. Good stuff.

August 25, 2006

John Battelle noticed that Google has … a lot of money. $10 billion and growing. Cash in the bank. Wow. They’re experts at storing, searching, and otherwise wrangling massive amounts of data. They’re investing heavily in wireless networks, data centers, and bandwidth.

I appreciate their acquisitions and efforts towards building and acquiring web-based productivity apps, but what the computing world needs more than Yet Another Office Suite is a cheap, persistent, and ubiquitous utility for storing and crunching data. Amazon is definitely on the right path with their Simple Storage Service and Elastic Compute Cloud services, but Google has the monster infrastructure required to make it truly pervasive.

What happens when metered computing and storage is accessible from anywhere? It removes the long-term commitment to a hardware investment, and becomes cheap enough to put in the hands of the little guys: A high school’s computer club can build and learn about clusters of virtualized machines for a few bucks a day; digital artists and film makers can batch process and distribute their projects for pennies on the dollar; universities in developing nations can quite literally build ad-hoc supercomputers. And that’s just what’s possible now with Amazon’s services.

So, I’d like to see Google step up to the plate with a little competition for Amazon. Utility computing is an emerging market, and Google has the mindshare to bust it open. They also have some of the brightest people in the business, one of the most capable computing infrastructures in existence … and money to burn. How about opening those resources up to the public? I know I’d pay for it.

August 24, 2006

Deploys in minutes. Upload an “Amazon Machine Image” (basically a Linux file system tar ball, kernel and all), use a web service call to turn it on … and you’re rockin’.

Reasonable hardware, hot bandwidth. From the beta description: “Each instance predictably provides the equivalent of a system with a 1.7Ghz Xeon CPU, 1.75GB of RAM, 160GB of local disk, and 250Mb/s of network bandwidth.”

What does that all mean? Well, you’re looking at well equipped web server using 20GB of storage and 50GB of transfer per month for $85. More or less instantly available. HOT DAMN. That’s something that makes me want to throw my arms in the air and do a lot of dancing.

This is one of the most interesting things I’ve seen this year — something that could be quite disruptive in the hosting industry. I’m chomping at the bit to get my beta invite.

Now, the next big issues: load balancing and network topology. It’s Linux, so LVS would work alright. Tunnelling can provide a private network. Hmm. Food for thought, anyway.

—

Updates:

The fine folks at Amazon have confirmed that these are Xen virtual machines.

August 16, 2006

The Ruby user group of Pune, India has a blog and is collecting interviews with people about how they discovered Ruby. It’s pretty similar to the “How I Learned Ruby” chain letter that’s making the rounds, and I’m looking forward to seeing what other people have to say. It piqued my curiosity about Ruby in India. I’d love to hear more about how (if?) the language is catching on down there.

So far, interviews with Bruce Tate and myself have been posted — and I’m sure there are more to come!

August 14, 2006

Alex Bunardzic responded to my previous post, so it looks like we have a genuine discussion brewing here. Blog to blog isn’t particularly efficient, but efficiency isn’t the point of these sorts of things, is it? So, here’s Alex’s original post, my response is here, his response, and now … here we are.

Alex is correct, that this is an issue of common sense verses counter intuitive methodology. Well, mostly correct — good methodology doesn’t have to be counter intuitive. But that’s just nit picking. Perhaps a more accurate statement is that this is an issue of naive verses educated intuition. Rephrased, I think we’re both headed in the same direction .. if from different angles.

Alex’s example of the intuitive (but poorly educated) stock trader is a perfect example. Naive, eager, and ready to commit to whatever catches his fancy — a recipe for disaster, no doubt. Of course, given extensive training and having worked with successful mentors, the trader’s intuition matures and becomes an incredible asset. The book “Blink” examines the power of intuition in both naive and trained forms; Kathy Sierra and Dan Russell have written about it several times. Intuition (or first impression, or whatever you’d like to call it) can be a very valuable tool, no doubt about it … but it has to be challenged and defended and honed over time to become so.

I guess I just have a hard time trusting plain ol’ common sense as a good justification for action. When someone says “Peat, I think we should take this approach” my first question is … why? “It just seems right” isn’t a good answer, even if that person has informed opinions and a good track record of making correct decisions. Is it an issue of trust? No. It’s simply taking the appropriate time to make sure that we’re doing the right thing.

The key, of course, is appropriate.

Alex goes on to say:

“I’ve seen too many people being enthusiastic about the counter-intuitive, bureaucratic ways of developing software. That approach is almost always amazingly catastrophic.”

And he’s perfectly, 100%, absolutely, correct. Heavy handed practices are largely professed by people who don’t know enough about their responsibilities, or don’t trust the advice of people who do. In trying to cover their asses, they suffocate the creativity and passion required to make good software … and kill the effectiveness of their people and product.

On the other hand, if I simply ask “why?” and challenge the technique in question, two things happen: it becomes a question, and therefore a conversation; and the people who make a decision together feel responsible for it. “Why” breaks the intuitive cycle, but not in a fashion that cripples the process of building software. “Why” builds better software, and better developers. Sometimes asking “why” requires a team to throw out heavy processes … or take them on.

I guess it’s important to frame the conversation within the context of what’s important. As Alex said,

“It’s all relative, you see. The only thing I truly care about is the best results for the end user — a human being paying to use the software.“

Sometimes, that person’s life depends on the software, and consequently a remarkable amount of time and energy should be spent on making the system as robust as possible. Sometimes, it’s just a cute little web app. Regardless — good software is always about the end user.

Anyhow, intuition is just another tool in the box, but it’s the first one we pull out of it. It’s worth investing in a good one, but foolish to depend on it for everything.

August 14, 2006

I completely agree that it takes great developers to produce great code regardless of methodology, and that crap developers produce crap software, even with the best intent.

However, there is a part of Alex’s post that bugs me. He states:

“… no amount of clever gimmickry and prescribed methodologies is going to help us. Only plenty of experience and plenty of common-sense can lead us out of that conundrum.”

Maybe I’m taking this the wrong way, but I don’t think this provides a better answer than the concepts he takes issue with: there are plenty of developers who have plenty of experience, and depend on common sense and intuition to really foul up their projects. “Common sense” is what makes gimmicks and methodologies so appealing!

So, instead of experience and common sense, I think a great developer (or manager) is one who thinks critically about a given scenario, and applies the appropriate techniques to complete it successfully. The solution comes out of critical thought and a large toolbox of techniques, developed through experience and analysis — applying methodologies and determining why they succeeded or failed. Were they incompatible to begin with? Were they a good fit for the development team? What indicators can I look for in my future projects and interactions?

The critical approach takes a lot more work and is decidedly less sexy than appealing to common sense, but it reliably produces the best results, and that’s what we’re shooting for. Right?