I’ve posted exactly zero times in the last two months because I’m head-down like a mad man, working with my team to get our very first iPhone app ready for shipping. Fingers are crossed that this will happen in about a month or so, and I have to say that so far 2010 has been a whirlwind education in the creation of iPhone software and the server backends who love it. That means that so far I’ve had no time to learn about the wonders of Rails 3, or to pontificate at length on the healthcare bill, or to beat Mass Effect 2.

But I have had time to be impressed, once again, at the awesome power of open source and the game-changing nature of Amazon Web Services.

Open Source — HTTPriot and delayed_job

Without going into too much detail, the iPhone app I’m working on (codenamed “Pedro”) records audio files and uploads them to a server. Naturally I’m using Rails for the backend, so I needed something to help me communicate easily with the server. After trying both an ASIHTTPrequest with TinyXML solution and Objective Resource, I eventually settled on HTTPriot. HTTPriot is a Goldilocks solution. ASI/Tiny are just too cumbersome since you end up having to write parsing methods yourself (and really, who the hell wants to do that when the entire point of structured serialization formats is that something should be able to turn them into native data structures (hashes/dictionaries) for you?), and ObjectiveResource seemed to do just a little too much and to rely on Objective-C categories a bit much for my comfort.

HTTPriot sits right between these solutions and is just right (had to complete the Goldilocks thought) for talking to REST services IMO. You serialize something out as an NSDictionary and POST or PUT it to the server, and you get back a response you can treat as a dictionary. GET requests are a one-liner (though to do it right you need a few methods so you can have a ViewController delegate handle the eventual response). The only drawback I’ve found so far to HTTPriot is that it requires you to cram all your processing logic for any given resource into a single method, as one and only one delegate method handles a successful server response. But that’s a small gripe. Using this excellent library, I was able to re-write the entire ASI/Tiny solution in a few hours. That’s versus a few days getting it set up in the first place. If you need to talk to a REST service with an iPhone, I highly recommend HTTPriot. As a bonus, the inimitable Geoffrey Grossenbach (@topfunky) uses it in one of Peepcode’s iPhone screencasts, enabling you to get both a step-by-step tutorial on creating a non-trivial working application with HTTPriot, and a good bit of explanation on how the library ought to be used.

When HTTPriot is done pushing an audio file to my app server, a Ruby library called delayed_job does the background processing required to send it to Amazon S3, where it will live and respond to GET requests via Amazon Cloudfront. delayed_job was created by the redoubtable Rubyists behind Shopify, the coolest turnkey e-commerce solution I’ve found so far. I’ve made a site or two for clients using Shopify, so I was excited to discover that they’d opened up the library they wrote to do background processing. delayed_job is a database-backed persistent job queue that runs in its own process and makes backgrounding a task dead simple. You can do all sorts of fancy things with prioritization and whatnot, but the thing that made me fall in love (even though my use cases eventually got a bit too complex to use it very much) is the fact that you can run any method with send_later — as in:

That one-liner will bop it into the queue, and delayed_job will handle it as it can. It’s really that easy. I’m using dj for sending emails and pushing binary files to Amazon, but I might start using it for other things as well. EngineYard (where we’re hosting this opus) supports it for production, and for development, you get a nice Rake task to help you manage it and keep an eye on the tasks as they happen.

The point of all this exposition is to say that I feel fortunate to have come up as a code dunce during a time in which open source software is mature enough to be able to provide even a relative n00b like me with documented, real-world-tested, helpful stuff that does exactly what I need it to — whether on the server side or on the client side. It’s worth mentioning as well that both of these things are arguably direct offshoots of the Rails community (delayed_job is in Ruby and was built to serve a Rails app, and HTTPriot was built with REST interactions in mind, which Rails has done a lot to help popularize), which continues to astound me in its breadth, creativity, and helpfulness.

AWS – cheaper than dirt, more valuable than gold

Have you ever seen anything as cheap as the stuff offered by Amazon Web Services? I don’t think I have. Or to put it more directly, AWS are the cheapest things I’ve ever seen someone try to put a price tag on:

- S3, Amazon’s storage service, charges $.015 per GB for the first 10 TB of transfer bandwidth you use in a month. And the prices go down from there. Get out your calculator and do the math to see how much data you have to be moving around before this starts to cost you more than you have in your change jar, and you’ll likely spend 20 minutes or so cackling to yourself about just how inexpensive mind-blowing web power is these days.

- Cloudfront, Amazon’s CDN charges $.01 for every 10,000 GET requests. Do the calculator thing on that one (realizing that it’s basically an add-on to the above), and you’ll be laughing even longer.

- We buy EC2, Amazon’s scalable-on-demand computing service, through a reseller (EngineYard) who really doesn’t add all that much to the $0.085/hour cost that Amazon themselves charge. EngineYard is able to offer hosting solutions optimized for Rails based on EC2, along with monitoring and Rails-oriented deployment and management tools, for so little extra on top of what Amazon themselves charge that for the first few weeks you’ll feel like you’re getting away with a crime.

Without the open source libraries I mentioned above, Pedro would take much, much longer to build and would be necessarily a bit less stable, simply because my team and I would be building everything from scratch. But without Amazon Web Services, there’s no way we could even entertain the notion of making this app. Pedro is a game: a funny, 99-cent App Store novelty that we hope will go viral and make us some cash. Apple gives us a great way to distribute the app, but without Amazon, we’d have show-stopping cost barriers to actually building a backend capable of meeting rapid, viral demand. A few years ago, just standing up unused production infrastructure to handle these use cases would’ve cost us thousands of dollars a month in rents, to say nothing of what it would cost in time and/or people-hours to have a qualified sysadmin lurking on our payroll. Now because of Amazon, those barriers are gone — replaced by a giggle-inducing cost structure for computing resources that back one of the most powerful retailer/supply chains on Earth.

With the preponderance of open source libraries and the rise of commoditized enterprise-scale computing, the utopia really is now — the only things holding anyone back are time, creativity, and will.

Speaking of which, I need to dive back down my code hole. See you in a month or so.

OK so I’m really glad that I’m not a professional technology pundit, since all the predictions from my last post turned out to be wrong. Even the name! What the hell? I’m pretty sure that I’m going to be there in line for the thing on the first day, but “iPad”? It sounds like something that the menstrual product industry would market for “young lady’s first period.” “iSlate” was so much better.

I’d still love to see the iPad enable some cool peripheral needs. I understand why they didn’t showcase that as a major use of this thing, but I’m hoping that the SDK will let programmers create apps that enable the iPad to be used as an input device — the 1000-sensor multitouch screen would make it pretty compelling for that. I mean if you watch the Brushes app demo, you’ll get an idea of what you could do with this in something like Photoshop or Illustrator.

John Gruber got to play with one a bunch and said that the main thing that he (and it seemed everyone else there) noticed about the experience is how fast it is. And it’s Apple’s own chip in this beast — a 1 Ghz Apple A4 chip. This is going to drive Apple’s bid toward dominance as the “largest mobile device maker in the world”

Apple now owns and controls their own mobile CPUs. There aren’t many companies in the world that can say that. And from what I saw today, Apple doesn’t just own and control a mobile CPU, they own and control the hands-down best mobile CPU in the world. Software aside (which is a huge thing to put aside), it may well be that no other company could make a device today matching the price, size, and performance of the iPad. They’re not getting into the CPU business for kicks, they’re getting into it to kick ass.

It seems inevitable that they’ll try to put one of these babies into a new version of the iPhone, and then, well holy crap. They’ll need to call it the 3GS^2

Peripheral

I wish I’d been right about the magnetic induction stand, because I think that would’ve been a lot cooler than the flip-around carrying case thing that they’re going to ship this with, but it makes sense that they’re going to have the same 30-pin power/data connection that the iPhone/iPod have. Apple has a history (that they seem to have abandoned) of just drastically changing what’s available in the way of interfaces or peripherals on new devices. Remember how aghast people were that the iMac had no 3.5″ floppy drive? Earlier than that, I think there was a big stink when they did SCSI instead of parallel ports on their boxes. Given this history, it made sense to me that they might want to make the sync interactions of the device entirely wireless. But given the existing commitment to 30-pin connectors, it feels a little more “new Apple” that they kept this tech in the device.

I’ll leave the public predictions to people who know a lot more about the history and industry on these things, but it was fun to speculate. I can’t wait to download the SDK for iPad — I should have it later today — and I’m of course hyper-excited to get one in 60 days. Still trying to decide though whether I care about the 3G access. At this point, hearing that AT&T is willing to sell me an unlimited 3G data plan for $29.95 is sort of like hearing that shit sandwiches are 75% off.

With no pundit reputation to screw up, I stand here unashamed and ready to be proven wrong. Here are my predictions for what the mythical Apple tablet computer will be all about.

It will be called the ‘iSlate’

Cool name. NYTimes editor Bill Keller called it a version of that name (”the new Apple slate”) at one point awhile back, and it just fits nicely. Also Apple owns islate.com.

There will be an awesome accessory

The iPhone comes with an accessory that manages to actually up the cool factor — its headphones. The iSlate will have one if its own: a sleek cradle that will fulfill the functionalities of a stand (allowing the iSlate to sit upright for easy seated viewing), and a charging station, using magnetic induction as its power delivery mechanism, and enabling Apple’s designers to avoid placing a power port on the device itself. I’m also predicting as part of this that it will support over-the-air sync only.

Part of the pitch will be for use as an accessory

Not a big part, mind you, but I think there will be significant emphasis on using this as a secondary input device for an existing computer — as a drawing tablet or a multi-function “hotkeys” device or something. This could just be wishful thinking on my part, but I just can’t get past the idea that Apple wants people to view this as a computing device whose primary attraction is that it lends itself to a paradigm-shifting generality of use. That means fulfilling the roles of computer, television, magazine, and yeah, Wacom tablet.

More importantly will be the idea that the iSlate fits into your life in a certain way — as your “on-the-go” device; even more so than the iPhone, this is the thing you take to meetings, take on short trips, etc. Auto-syncing important documents and whatnot over the air will be a big deal.

It will run something beefier than iPhone OS

Maybe not full-on OS X, but I agree with John Gruber that they’re not going to just spooge the iPhone OS onto the device:

in the same way that it made no sense for Apple to design the iPhone OS to run Mac software, it makes little sense for a device with a 7-inch (let alone larger) display to run software designed for a 3.5-inch display.

I also don’t think that the file system will be completely hidden away a la the iPhone and that the only way you’ll be able to interact with the device is through apps. If this is to try and be a general-purpose computing device, there has to be some kind of file system access, even if it’s severely limited. Another piece of evidence for it being something somewhere between iPhone OS and full-on OS X is the WWAN (as in 3G) network information reporting in Snow Leopard.

OK — that seems like prognostication enough for now. Can’t wait for January 26th/27th.

I like this Macalope column from Macworld, reminding us all how wrong all the pundits were in advance of the iPhone (and quite a bit of the dumb stuff that’s been said lately about the rumored Apple tablet). The best part though is his insight that the reason Apple has succeeded with the iPod and iPhone is because those two technologies each had a killer differentiating feature that made them able to disrupt an existing market.

if and when it appears, will have some differentiator that makes it a compelling purchase. The iPod replaced your CD collection, the Apple TV would like to replace your DVD collection (but you won’t buy one), and the iPhone, obviously, replaced your cell phone. The tablet (insert caveat about its existential dilemma) will turn another industry on its head. The problem with the JooJoo is that it has no hook, no ecosystem. It doesn’t act as a compelling replacement for anything you have.

One thing that I’m hoping for (but that I think there’s very little possibility of due to the likelihood that they’re going to base it on iPhone OS) is some kind of personal diagramming application. I’d love to be able to add some programmatic heft behind the diagrams I draw of data models, applications, etc. I’d love to be able to put data behind some stuff, or draw things that can go right into a program like OmniGraffle

If my own little personal BS grammar of pseudo UML could get programmed out pop-n-fresh automatically into some ActiveRecord models right after I drew it freehand, I’d be one step closer to some right-brain techie Nirvana.

There are more black people than white people on Twitter, and this is only recently becoming obvious to people because of new Twitter stuff like Trending Topics:

But seriously—talk about being in a bubble!—demographically, there is a greater proportion of black people than white people among the Internet-using population on Twitter: according to Pew, 26% of African-Americans online use Twitter; only 19% of white Internet people use Twitter. So really the question is: why does Twitter get so white and boring during the day? Don’t white people do anything at work?

So many data at play in this that I don’t want to say anything, but this is really interesting for what it says about Twitter’s power as a general communication medium with high availability outside the socioeconoomic ranks of affluent suburban office workers.