After Amazon, Google App Engine is the next big contender for mainstream cloud computing. The power of Google’s infrastructure will spin up as many instances of your app as needed, and they’ve provided a simple Python framework with Django templates for development, with additional languages to come. Basic accounts will always be free, and after the current preview ends, a la carte pricing wil be similar to Amazon’s services.
I consider myself a good listener, but really missed the mark last week. One of the cloud computing talks was being given by Joe Gregorio from Google, who I chatted with beforehand. He mentioned working on the Atom protocol, which I immediately took as an opportunity to ramble off about using it as the API for a previous project.
I looked him up afterward, and found out that he actually wrote the spec! For as many times as I read the thing, you’d think I would’ve noticed the name, or at least picked up what he was telling me before launching into my own story. Of course, being a good listener himself, he indulged me before getting into his talk on Google’s App Engine.
The second cloud computing track was on massive data processing in clusters and 15clouds, including a presentation by Facebook on their use of Hadoop and custom development of Hive to facilitate their own operations.
Data mining the 180 TB of Facebook data, which grows at 2 TB a day is no small task, so the team uses a cluster of 350 8-core machines to crunch data and figure out which popular features deserve further investment, demographics, and whatever else they can fish out of the sea of personal information users provide.
Another cloud computing talk introduced Google Docs and showed a few cool ways to collaboratively use spreadsheets “in the cloud”:
I attended a few talks on cloud computing last week, including an overview of Amazon Web Services. My previous view of Amazon’s mission was that they’re out to commoditize everything, from books to products to computing. In fact, they actually do have 3 lines of business:
The extent of their web services is testimony to it’s standing as a main pier of the company: it includes a variety of inexpensive a la carte services for data storage, messaging, and raw computing power. Web service traffic actually surpasses that of the retail site. Of course, the real proof comes in some of their success stories:
I’m going to be recapping some recent talks I participated in on cloud computing, so by way of introduction, here’s a post from Marc Andreesen detailing the three kinds of platforms you meet on the Internet (cloud computing being Level 3):
A Level 1 platform’s apps run elsewhere, and call into the platform via a web services API to draw on data and services — this is how Flickr does it.
A Level 2 platform’s apps run elsewhere, but inject functionality into the platform via a plug-in API — this is how Facebook does it. Most likely, a Level 2 platform’s apps also call into the platform via a web services API to draw on data and services.
A Level 3 platform’s apps run inside the platform itself — the platform provides the “runtime environment” within which the app’s code runs.
Mock objects are another one of those software concepts that are interesting but useless until you see how they can make life easier. A few of the talks at Code Camp helped me turn that corner and see that they’re quite useful for unit testing. Namely, they allow you to unit test a class while mocking its dependencies, which frees you to focus on the class being tested instead of dealing with the overhead of a real database or web service.
For an initial hands-on experience, I refactored some unit tests I wrote last week for a business class that called a web service. All that really needed to be tested was the handling of various data and exceptions from the web service, which were one-liners once I figured out the syntax of Moq. Writing tests this way also exposed some areas where code was overly coupled; my business class was doing a lot to manage the external service.
The tests are now quicker, the code feels a bit more solid, and I’ve got at least a foothold in understanding mocks for testing and their impact on software architecture.
One of the recommended links from the Code Camp was the Foundations of Programming Ebook by Karl Seguin. It’s a good read with straight-forward explanations of modern software development ideas; here are a few quotes and comments:
Maintainability is the cornerstone of enterprise development.
Much agreed, and perhaps one of the things that sets enterprise development apart from projects with less longevity. Often, though, this mandate is overlooked as schedule becomes the main driver.
YAGNI - You Aren’t Going to Need It is an Extreme Programming belief that you shouldn’t build something now because you think you’re going to need it in the future.
This is a powerful idea from agile and one that really helps you get to having something “done” and ready for the customer faster. And given how often things change, it likely saves you the pain and waste of changing or discarding something built too early.
I’ve been doing a bit of pair programming recently, and getting a different perspective from it. For one, it is nice to take a break from the usual solitary keyboard banging. Having two people makes bug hunting a little easier, and forces you to really think about what you’re doing - and why - so that you can explain it to someone else.
It’s also an interesting study in personal efficiency and style; I’ve been able to share a few time-sharing shortcuts and preached a bit of test-driven development by example. I’ve learned a bit, too, finding some better ways to rework code I previously wrote.
I went to my first code camp with Philly.NET this weekend, and was impressed with the variety of speakers and overall attendance. For as many great online resources as there are today, sometimes it’s much more effective to see new technologies and methods explained in person.
The quality and polish of the presentations varied, but were overall pretty good. Being a code camp, most quickly moved from slides to live code, writing and debugging on the fly while taking questions from the audience. As always, it was enlightening to see how other people write software, both in terms of style and the tools they choose to write better code faster.
del.icio.us/mbotos