Full disclosure: I have no apps on the App Store, though I intend to push my first one in the coming months.  I do however do a lot of iPhone and iPad development, mostly for internal use by my company.

In Jonathan’s “brilliant” post, he asks his readers if they really want to give up 30% of their profits, learn Objective-C, endure approval delays and navigate code signing just to put their iPhone/iPad apps on Apple’s App Store.  He further goes on to say that you should instead develop a mobile web application instead, because it’ll work on all mobile devices and gets you around the bullet points (the 30%, the Objective-C, etc).

Great advice, if it were complete.  What he leaves out is how exactly you’d monetize that application, which as we all well know, is the conundrum of Web 2.0.

Which is the Bigger Crap Shoot?  App Store or Web?

I would actually contend that the Web is a bigger crap shoot than the App Store.  While there are a variety of ways to monetize the App Store, doing the same with a mobile web application is a far more involved task.  With the App Store, you can charge up front, you can opt for advertising, subscriptions are another path and – finally – you can even do micro-transactions within your app.  For web apps, your best option is advertising, and as big as the mobile market is, it’s still not at a tipping point where relying on advertising is going to keep you flush with green, specifically at web rates versus mobile app rates.  Upfront fee … I can’t even think of one web app that does that, though I imagine someone is working on it.  Subscription based?  That’s a hard sell unless you are doing pornography – but even that market is sagging (no pun intended).  Micro-transactions are working for Zynga, but nobody else really.

The App Store makes all of this trivial to implement and part of that 30% you pay to Apple is for all that infrastructure to support it.  Let’s imagine that you’ve decided to blaze a trail and charge an upfront fee for the use of your mobile web application.  You’ve decided to use PayPal as your merchant – right there you are paying 3-4%.  You’ve also just narrowed your market – where everyone with an iPhone and an iPad has an App Store account, not everybody has a PayPal account.  Add on top of that the effort to implement the back and forth with PayPal, the time spent with customer service, the maintenance of it all – don’t even get me started on the user experience – and, well, the 30% makes life pretty convenient.  Even more so if you are doing something subscription based.

LOL

He further goes on to state that the App Store is an out-dated business model – yet he has not spent any part of the post recommending another.  I’m not sure how $1 Billion in revenue is out-dated.  Apparently, that shit works.  When he has generated $1 Billion of revenue for himself, well shit – I’ll be the first to sign up for his classes.  Until then, can the hyperbole until you can offer up an attractive alternative.

PS. He’s an Android developer if that tells you anything.

However, what strikes me most about the Wired app is how amazingly similar it is to a multimedia CD-ROM from the 1990′s. This is not a compliment and actually turns out to be a fairly large problem…

1990′s Here We Come … Again

The only real differentiation between the Wired application and a multimedia CD-ROM is the delivery mechanism: you download it via the App Store versus buying a CD-ROM at the now defunct Egg Head store at your local strip mall. And I really mean that comparison. For all of the interactivity that was touted in the Flash prototype, what we’ve really ended up with is a glorified slide show. Instead of the “Next” and “Previous” buttons you might have been used to on those old CD-ROMs of yore, you instead swipe left and right to change pages (well *cough* images of pages).

There are certain interactive elements to the articles, but – and I apologize to all of the people who put in a lot of back breaking work into this – they’re pretty lame. Tapping on a button-looking element switches out part of the page with another image. You can drag your finger across certain images to make them sort of animate like a flipbook (and in truth, that’s what it is – a series of PNG or JPEG images). There are videos you can tap on to view fullscreen. There are audio clips that you can play. The interactivity in the Wired application is very 1990′s. I am not trying to be insulting either, it’s simply the truth. The Wired application has pretty much brought back image rollovers.

And that’s about the extent of the interactivity. Which makes me wonder if that should be the extent of it or should we be wanting more? I don’t have an answer to that, though my gut feeling is that there is a massive opportunity to reinvent the concept of a magazine – yet we end up with something akin to what the web was like in the mid to late 90′s. This basically boils down to a print designer’s vision of what the web should be like – but in this case it’s a print magazine person’s vision of what an interactive magazine should be like.

If you can think back that far, and you were doing web development during that time, you will glumly remember the frustration of web development driven by print design, where pages were essentially huge images cut and sliced and then reconstituted back into insane table structures for pixel perfect layouts. That’s what we’ve essentially gotten with the Wired app: a giant step backwards and a complete dismissal of the lessons we learned from that dark period of interaction design and development.

Holy Shit, That’s Big

With the Wired app weighing in at a whopping 500 megabytes – just 100 shy of a full CD-ROM – how do they intend to maintain new editions of the magazine? 500 MB is too large for a 3G download (no help from AT&T’s less than spectacular network performance) and for those with iPad’s with the smaller storage, each issue will take a significant chunk of space on the device. With no apparent means for managing which issues you keep on your device, this will become huge issue for a lot of people. Obviously they will fix this with updates to the application, but I’m still wondering what they were thinking to begin with. I’m hoping there were voices of dissent that pointed out the end product was not worth it’s weight in megabytes. A PDF version would have been a tenth of the size, though without the interactivity. But is the interactivity worth the 500MB price? I personally don’t think so.

Why is the magazine so large? Being the intrepid hacker that I am (*wink*) I mounted my jail broken iPad via AppleTalk and quickly tore into the app itself to see how it was constructed. Similar to the PopSci+ magazine application, each Wired issue is actually a bunch of XML files that lay out a bunch of images. And by “a bunch of images” I mean 4,109 images weighing in at 397MB.

Each full page is a giant image – there are actually two images for each page: one for landscape and one for portrait mode. Yes, I’m laughing on the inside too. There is no text or HTML, just one gigantic image. The “interactive” pieces where you can slide your finger to animate it are just a series of JPG files. When you press play on the audio file and see the progress meter animate? A series of PNG files.

Something is wrong with this picture. Something wrong and something very lazy and/or desperate.

Over Architect Much? (or How Desperation Ruins Good Ideas)

I have no inside knowledge on how the Wired app was produced, so the following is all conjecture on my part. That said, my guess is that Adobe sold Conde Nast on doing the thing in Flash. Or if Adobe didn’t do the selling, some Flash loving technologist at Conde Nast sold them on it. Either way, since Flash CS5 was going to be able to target the iPhone/iPad, they’d be able to publish the thing as it had been shown to the press. But then Steve Jobs came along and threw section 3.1.3 into the iPhone licensing terms and … well … Adobe and Conde Nast were pretty much fucked. So fast forward to this moment in time and the best short term solution they could come up with was some jury rigged XML based layout framework and an epic shit ton of images.

The Wired app isn’t alone in this weird architectural choice either. The PopSci+ magazine is based on a very similar architecture. There are also other magazines that work along the same lines, or simply go the route of PDFs with a customized PDF viewer application.

The problem with these XML + images architectures is that they are essentially reinventing HTML with no added benefit. When I showed the Wired app to a colleague of mine, someone I consider to be one of the top HTML/Javascript developers in NYC, his assessment was the same: Why the heck didn’t they use HTML5? We stepped through each “page” of the Wired application, looked at each interactive piece – but failed to find anything that ruled out the use of HTML and JavaScript.

The argument might be that it needs to be cross platform – the very thing Adobe and Conde Nast were banking on by going with Flash – but guess what? For all of the tablets about to fall on the heads of consumers in the coming years, each one of them uses WebKit. If anything was built for this type of application, it most certainly is WebKit. And even for harder interactivity puzzles – in terms of how do we do X and Y – one can easily hook into WebKit to enable that stuff that might otherwise be more difficult to do in straight HTML + CSS + JavaScript. I have yet to see anything in any magazine application on the iPad that would really require this though.

So why didn’t they choose HTML5 and build a custom viewer application around WebKit? It comes down to either a sense of desperation, a sense of Adobe overselling a bad idea or simply a dumb technology decision. Possibly all three. It certainly isn’t a development challenge and it certainly isn’t because WebKit isn’t capable. I had a thought that perhaps memory management was an issue, but by going with HTML5/WebKit, you wouldn’t be showing pages and pages of huge images – you’d actually be able to build those pages the right way. And doing it this way, in my professional opinion, the magazine itself would be slashed dramatically in size, as well as acting and reacting in ways familiar to people who’ve been browsing the web for the last 15+ years. Furthermore, the cost savings from a production standpoint would be drastically lower as Wired already maintains a staff of web developers. There wouldn’t be an impetus for Adobe to create some “solution” at Conde Nast’s expense and a lot of the great interactivity you saw in the YouTube videos of their prototype could very easily come to life.

But as it stands now, the Wired iPad app is even far behind their own website. That’s embarrassing. Did anyone at Conde Nast look at this and wonder why someone would choose to use this over their very own website? That iPad – unless you are in a subway – is constantly connected to the intertubehighway. That fact alone makes one wonder what the point of the whole thing is. Specifically since they’ve not done any sort of interactivity or visual presentation that I think anyone can say is amazing. Sure, it’s a print designers wet dream – but it really should be a consumer’s wet dream. And it most certainly is not that.

So, from a technical perspective, I think what we are looking at is the result of equal parts desperation and ignorance. Desperation on the part of Adobe to carry forward their relationship with Conde Nast in this new publishing market and ignorance on the part of their development team for ignoring the best solution to their “No Flash Allowed” problem: HTML5.

Is This The Future For Magazine Publishing?

I hope not.

I actually think it’s a huge step backwards and I think the wrong people are working on the problem – just like the wrong people were working on the web problem back in the day. Sure, we corrected course and we’re seeing the web done correctly more and more these days – but can the magazine publishing industry afford to get this wrong for any amount of time? Once could argue that the internet is quickly making their industry irrelevant. By the time an article is published in Time, I’ve read six or seven different takes on the same story on the web well before it hits the newsstands. I don’t think that’s a unique or new insight. But now you want me to download 500MB a month just so some print designer can have pixel perfect layouts with custom fonts?

Unfortunately, as long as Conde Nast allows Adobe to dupe them into believing Adobe has a solution, it’s going to fail. They need to go outside the box to get this right, and all the technology to do it is sitting right there in front of them. And they’ve been using it very well … until now when they’ve chosen not to even use it all.

Update

People have been mentioning that you can’t do application specific fonts with the WebKit browser. Not sure why.

Here is a simple iPad app that loads up a custom open type font, and then displays an html file in a UIWebView with that custom font: http://github.com/jawngee/iPadFontExample

So it can be done. Enjoy.

Yes, believe it! You can now twitter your soul crushing acts of consumerism to your uninterested friends so that they too can be involved in the banal minutiae of your life! The IRS is going to love this one.

<?
// what a stupid f'ing idea
?>

And there you have it. All the functionality in way less code.

• She can read her books in the dark.
• She can use it in the kitchen to look up recipes and watch cooking videos.
• She can use the GPS to help my dad drive their RV around the country.
• She can be better connected to her iPhone wielding grandchildren.
• She can play Words with Friends on a bigger screen.
• She can  browse the web on a readable screen.  While in the RV.
• Watch all of her NFL games while sitting on the porch.

And that’s just to start.  Later down the road, maybe after revision 2, she’ll also be able to:

• Draw her knitting patterns and sync it with her knitting machine via Bonjour over WiFi.
• Have video chats with the kids.
• Augmented reality tour guides for the new places they travel to.
• Telemedical (god forbid) monitoring to save trips to the doctor.
• Control surface for manipulating certain controls of the RV.

The best part?  I won’t have to show her how to do those things, not most of them anyway.  So to do 80% of what she uses her laptop for, she can do all of those things without having to lug the thing out, plug it in, hook up the mouse, etc.  She’ll be able to take the information she is looking for to the place where she needs it to be: the kitchen, the sewing room, the co-pilot’s seat.

So thinking about my mother using it, and loving it, I started to think how I would use it.  My list is almost equally as long.

• Control Boxee.
• Use it as a control surface for Final Cut or Ableton Live or Traktor via Bluetooth or WiFi.
• Home automation.
• The ultimate universal remote (extra hardware required)
• Pornography
• Better in-flight DVD viewing experience

There are so many more integration points the iPad can make with day to day living and day to day information needs.  The key aspect of it all is mobility and portability, having the information you need not only when you need it, but where you need it.

I understand the let down from the perspective of people who were wishing for a multi-touch Mac Book.  But I think they are thinking about it wrong.  People are thinking about it as if it’s a computer, but it isn’t just a computer, it’s a whole new category of device, a whole new definition of what a computer is.

I also agree with most that the lock down to the App Store is a let down, though you don’t have to think too hard about it to understand it’s a necessary evil.  It reduces any potential confusion on how to make the thing do something new.  My Mom and I were playing Words with Friends without me having to walk her through how to install it and get it running.  Now compare that with what it was like to show her how to do something similar on her Windows laptop … yeah no thanks, I’ll take the App Store.  Not to mention not having to run that crappy antivirus and anti-spyware junk – the stuff that sucks the performance out of her laptop and yields endless complaints about how slow everything is.  Perhaps it’s a false sense of security, but I can live with that.

Some of the complaints about usability and related things are complete nonsense and even defy logic.  I’m pretty sure Apple did some usability testing on this thing … but maybe that’s just wild speculation on my part.

I think Apple is definitely onto something, maybe it’s not quite there yet, but they’ve definitely accomplished more than bringing an oversized iPhone to market.  But only time will tell.

And, yes, she does kick my ass in Words with Friends.  She hit me with two 70+ pointers yesterday.

This is undesirable for a bunch of different reasons. Here’s a patch to solve the problem, while still keeping that functionality should you need it.

You can grab the patched version from my github repo:

git clone git://github.com/jawngee/JW-Player-HD-Plugin.git

Drop the hd.swf in with your player and you can load it like so:

<div id="video" class="player">
	<p>Please <a href="http://get.adobe.com/flashplayer/" target="_blank">Upgrade your Flash Player</a> to view this content</p>
</div>
<script type="text/javascript">
	var s1 = new SWFObject("/swf/jw/player.swf","ply","640","480","9","#000000");
	s1.addParam("allowfullscreen","true");
	s1.addParam("allowscriptaccess","always");
	s1.addVariable("plugins","/swf/jw/hd.swf");
	s1.addVariable("hd.state",false);
	s1.addVariable("hd.autoswitch",false);
	s1.addVariable("hd.bandwidth",3200);
	s1.addVariable("hd.file","http://video.com/hd.flv");
	s1.addVariable("file","http://video.com/flv.flv");
	s1.write("video");
</script>

This patch adds two new config options:

hd.autoswitch – true/false, determines if the hd plugin should switch based on user’s bandwidth, default is true.
hd.bandwidth – The bandwidth threshold for performing the switch, default is 1500.

Enjoy.

One thing that is truly great about Slicehost is that they offer an awesome API that allows you to do most everything you can do in their management console, but instead through web services. You can create new slices, reboot them, change and add DNS, as well as rebuild or destroy slices.

The only problem is that the API follows a “standard ActiveResource pattern” that comes straight from the bowels of Rails and is way too convoluted for something this simple.

My biggest complaint is that instead of POSTing standard post variables, you POST XML, but none of the data being posted approaches any kind of structural complexity that warrants it’s usage. It just a layer of crap that doesn’t need to be there. Every modern language has some sort of HTTP request mechanism that handles all this stuff without some arbitrary object model forced on top of it.

Curiously, there appears to be another way where you can POST regular form data, but the variable names are in the form “resource[field]” which, again, seems completely unnecessary. I also couldn’t get it to work reliably.

As a point of reference, I was able to implement S3, EC2 and SQS API’s from amazon in just under 6 hours. It took me two days to figure out the Slicehost API. The ActiveResource pattern is a failure in my estimation.

The following are my notes on implementing the slicehost API. Hope you find it useful.

NOTE: This post doesn’t cover their DNS API as I don’t have a particular need for it. I will be posting the PHP library I wrote for the Slicehost API to github over the weekend. Perhaps someone can build on top of that…

Authentication

I actually had a bit of a bitch with this. The docs and ruby samples specify that you put your API key in the url, like this:

https://APIKEY@api.slicehost.com

Problem is that I just could not get it to work. Even the ruby samples in their docs didn’t run without authentication errors. Copying and pasting the URLs into Safari didn’t work either (simply pasting your API key into the user input when the Basic Authentication popup shows does work though).

So, make sure you always set the USER part of Basic Auth with your API key. In PHP it looks like this (using PEAR’s HTTP_Request object):

$request->basic_auth(YOUR_API_KEY,’’);

Dealing With Slices

This is the part that drove me nuts. I ended up having to debug their ruby examples through Charles, after patching activeresource.rb to support proxies. And even then, their examples didn’t work due to a typo and another error I couldn’t sort out.

Listing Slices

This is easy as pie. Simply make a GET request to:

https://api.slicehost.com/slices.xml

You will get back an XML document as a response:

<?xml version="1.0" encoding="UTF-8"?>
<slices type="array">
	<slice>
		<name>slicename</name>
		<status>active</status>
		<addresses type="array">
			<address>XXX.XXX.XXX.XXX</address>
			<address>XXX.XXX.XXX.XXX</address>
		</addresses>
		<id type="integer">666</id>
		<progress type="integer">100</progress>
		<bw-out type="float">0.0</bw-out>
		<bw-in type="float">0.0</bw-in>
		<image-id type="integer">10</image-id>
		<ip-address>XXX.XXX.XXX.XXX</ip-address>
		<flavor-id type="integer">2</flavor-id>
	</slice>
</slices>

The one issue I have with this is that the <address> element doesn’t specify if the address is internal or external. Right now, you can only make the assumption that the first address is external and the second one is internal. Not a big deal though.

Also, note the .xml extension. I believe this is arbitrary, but it would be dope if you could specify .json or .yaml or some other format. Again, not a big deal.

Getting Slice Info

This is equally as simple:

https://api.slicehost.com/slices/666.xml

Where 666 is the ID of the slice you want to get info about. You get another XML document in return containing a <slice> element as above.

Creating a Slice From an Image

This is relatively simple, but there are a couple of steps to it.

First you need a list of the images that Slicehost offers. Easy enough. GET request to :

https://api.slicehost.com/images

Will return an XML document that looks like this:

<images type="array">
	<image>
		<name>CentOS 5.2</name>
		<id type="integer">2</id>
	</image>
	<image>
		<name>Gentoo 2008.0</name>
		<id type="integer">3</id>
	</image>
	<image>
		<name>Debian 5.0 (lenny)</name>
		<id type="integer">4</id>
	</image>
	{ .. and so on .. }
</images>

Once you have this list, you’ll have need to figure out what flavors of slices you can create. Do this by sending another GET request to:

https://api.slicehost.com/flavors

Again, you’ll get another list that looks like this:

<flavors type="array">
	<flavor>
		<id type="integer">1</id>
		<name>256 slice</name>
		<price type="integer">2000</price>
		<ram type="integer">256</ram>
	</flavor>
	<flavor>
		<id type="integer">2</id>
		<name>512 slice</name>
		<price type="integer">3800</price>
		<ram type="integer">512</ram>
	</flavor>
	<flavor>
		<id type="integer">3</id>
		<name>1GB slice</name>
		<price type="integer">7000</price>
		<ram type="integer">1024</ram>
	</flavor>
	{ ... and so on ... }
</flavors>

So now we know the ID for the image and the ID for flavor of slice. Let’s keep going!

This next bit took me awhile to get going. When I tried to go through the method of posting good old post data, I would get back really obscure errors. So debugging the HTTP traffic of the ruby examples, I unearthed the secret sauce.

To create the slice with the image of your choosing, POST an XML document to:

https://api.slicehost.com/slices/

But, make absolutely sure that you have set the “Content-Type” of your request to “text/xml” otherwise it no worky. Your XML document will look like:

<slice>
	<name>NAME OF YOUR SLICE</name>
	<flavor-id type="integer">1</flavor-id>
	<image-id type="integer">2</image-id>
</slice>

The <image-id> must be a valid ID from the list above, of course. Their API docs have a typo where the sample code to create a slice uses an ID of 1, which doesn’t exist. A little hair pulling on that one, even though the bug was so obvious. The same thing goes for the <flavor-id>.

The response you receive will be information about you slice, including the root password. You only get this root password once, so make sure you take note of it. The response looks like:

<slice>
	<status>build</status>
	<name>SLICE NAME</name>
	<addresses type="array">
		<address>XXX.XXX.XXX.XXX</address>
		<address>XXX.XXX.XXX.XXX</address>
	</addresses>
	<id type="integer">666</id>
	<root-password>ROOT PASSWORD</root-password>
	<progress type="integer">0</progress>
	<bw-out type="float">0.0</bw-out>
	<bw-in type="float">0.0</bw-in>
	<image-id type="integer">2</image-id>
	<ip-address>XXX.XXX.XXX.XXX</ip-address>
	<flavor-id type="integer">1</flavor-id>
</slice>

And that’s it, you’ve created your slice!

Creating a Slice From a Backup

This is nearly the same as creating from an image, but this time we’ll need a list of available backups. Backups are things you create through the Slicehost management interface. What I like to do is build a base system and then take a snapshot. With that snapshot I can create new slices based on it.

To grab a list of backups, send a GET request to:

https://api.slicehost.com/backups

You will receive a list (if you have any backups):

<backups type="array">
	<backup>
		<id>3-666</id>
		<slice_id>666</slice_id>
		<name>daily</name>
		<date>Sat May 09 04:15:05 UTC 2009</date>
	</backup>
	<backup>
		<id>3-667</id>
		<slice_id>666</slice_id>
		<name>webserver_snapshot</name>
		<date>Sat May 09 04:15:05 UTC 2009</date>
	</backup>
</backups>

And, then, in the XML document you POST:

<slice>
	<name>NAME OF YOUR SLICE</name>
	<flavor-id type="integer">1</flavor-id>
	<backup-id type="integer">3-666</backup-id>
</slice>

Everything else is the same as creating a slice from an image.

Updating a Slice

The only thing you can update with your slice is it’s name. This is accomplished by PUTing an XML document to:

https://api.slicehost.com/slices

The XML doc looks like:

<slice>
	<id type="integer">666</id>
	<name>NAME OF YOUR SLICE</name>
</slice>

All you need is the ID of the slice and it’s new name. The response will be an XML document with a <slice> node.

Deleting a Slice

Delete a slice by sending an XML document using the DELETE HTTP verb:

<slice>
	<id type="integer">666</id>
</slice>

NOTE: You will have to have this option enabled in the API settings on your account. You can edit those settings at: https://manage.slicehost.com/api/

Rebooting Your Slices

To reboot your slice with a hard reset, send a PUT request to:

https://api.slicehost.com/slices/YOUR SLICE ID/hard_reboot.xml

To do a soft reboot, a PUT request to:

https://api.slicehost.com/slices/YOUR SLICE ID/reboot.xml

Rebuilding Your Slices

To rebuild your slice, you’ll need to use an image ID or a backup ID. Once you’ve picked one, send a PUT request to:

https://api.slicehost.com/slices/YOUR SLICE ID/rebuild.xml?image_id=X

or:

https://api.slicehost.com/slices/YOUR SLICE ID/rebuild.xml?backup_id=X

Conclusion

So that’s all I know. As you can see the API is pretty simple, but not as simple as it could be, nor are the documents even remotely near as useful as they should be. But, it’s awesome they have this API in the first place so I’ll stop bitching now!

Again, thanks to Slicehost for making awesome. The world sure does need it.

There are some caveats.  You will need to be mildly technical to pull this off, but Google is there to hold your hand through some of the tough stuff which, honestly, isn’t that tough.  And while some of the concepts might fit Microsoft developers, this article is Linux/BSD/Unix focused.  I will tell you, though, from years of being a .NET consultant, trying to bootstrap a Microsoft centric solution is futile if you’re trying to sell your ideas as cheaply as possible.  I’m not trying to start a flame war, I’m just sayin’.

Register Your Domain

Let’s start at the top.  You’ve got a great idea for a website.  You’ve done the leg work, written up your business plan and are eager to get going on actually building out the product and the supporting internals for the company. The first thing we’re going to need to do is register a domain.

You have a variety of options here, and depending on the domain and it’s TLD, you’ll have various pricing levels to work with.  For the sake of the argument, let’s assume you are going to register a .COM instead of the more expensive .TV, .ME, .JOBS and others.  Any one of these is a fine registrar:

• namecheap.com - $9.68
• godaddy.com – $9.99
• powerpipe.com – $10

I also prefer to do private domain registration, which can add $15 to the purchase.  This is entirely optional but it’s a good way to protect your private information.  If you are registering a .US domain, though, you can’t do private registrations.  Also, some places protect the privacy of your registration differently, so do some research if this is important to you. Namecheap has free private domain registration.  Godaddy charges extra and I’m not sure about PowerPipe.

Startup cost: $10

DNS Made Easier

This part is entirely optional, but after the register.com fiasco, it’s worth the peace of mind to run your DNS through a third party.  I love DNSMadeEasy for a variety of reasons, chiefly DNS changes are live nearly instantly, but they also scale incredibly well, providing options for doing round robin DNS to balance DNS requests between load balancers, as well as fail over monitoring.  They also have an API which you can use in your applications for all kinds of neat stuff.

Best part?  Cheap.

Run Rate: $0.08 a day

The Nuts and Bolts

So we have a domain now.  The next thing we’ll need to do is setup some infrastructure so our team can communicate and collaborate as we start building this mother out.

I will confess that I made a very dumb move when we were getting Massify going.  Having spent the prior 7 years as a .NET consultant, all I really knew was Windows and the host of enterprisey things you find on Windows.  Having done some SharePoint consulting, I decided SharePoint was the way to go.  An avid Outlook and Blackberry user, the only option I could see through my rose tinted glasses was Microsoft Exchange.  So we hooked up Microsoft Exchange with BES for my blackberry addiction and off we went to focus on bigger and better things. Fast forward a year and a half and the company has grown to 14+ people and our monthly hosted Exchange bill was close to $450 a month.  The worst part?  Massify is an entirely Apple OS X shop.  The only Windows machines we own are the ones we run in virtualization software.  So while we were running Exchange (and have all moved on from Blackberries to iPhones) we were not reaping any of its benefits.  No calendaring, contact sharing, none of that.  Had we been on Exchange 2007, we might have been able to capitalize on some of those basic things, but we were stuck on Exchange 2003 which doesn’t work with any OS X productivity apps without some spendy third party utilities that only sometimes work.

So, yeah, dumb move Gilkison!

Well I am here to tell you that you can get NEARLY all the benefits of Exchange for FREE.  Yes, you read right:  FREE.  My friends, I would like to introduce you to Google Apps for Business.

Shared calendaring?  Check.  Contact syncing?  Check.  Kick ass web interface for reading/writing mail?  Check.  IMAP support for desktop and handheld clients?  Check.  Push email?  Negative.

I did say NEARLY.

And the best part, beyond the awesome price tag?  I don’t have to install/maintain shit. I’ve been test driving Google Apps for Business for awhile for my personal stuff, to make sure that it has legs, and I couldn’t be happier.  So we transitioned off Exchange and we are all now much happier individuals.

Run Rate: FREE

Working Together

There are a ton of collaborative apps out there and they’re all like gloves.  Each has their own utility and fits its wearers in different ways.

The most popular, of course, is BaseCamp from 37Signals.  I won’t get into what I think of 37Signals, but suffice to say a lot of people have a huge app crush on BaseCamp.  I personally, and this is just my opinion, don’t particularly care for it.  Everything starts out well, but once you get into the thick of big projects it becomes a bit of a mess.  But, like I said, different strokes for different folks.  Nothing I’m preaching here is gospel, so find out what works best for you.

Now you get a variety of collaborative tools with the Google thing, in addition to the email.  Google docs is great for document sharing, but the other apps we’re not so keen on.  We’ve found a nice balance between PivotalTracker and PBWiki.  Both apps cost money and there are a lot of free, open source alternatives.  In fact, we use Deki Wiki from Mindtouch for our development wiki.  For agile development, there are quite a few free backlog management apps, but Pivotal is easy enough for everyone to use, so that’s what we went with.

However, the goal of this article is to do things cheaply, but functionally.  There is no open source equivalent of BaseCamp, so let’s price with BaseCamp in mind.

Run Rate: $0.78

Let’s Talk Hosting

The following is based on the assumption that you’re planning to build a web app based on today’s standards.  This means you’ll be using some kind of framework like Rails, or a language like PHP, with a database backend like PostgreSQL.  Yeah I could have said MySQL, but why when PostgreSQL exists?

I imagine this will be the most “controversial” aspect of this article because every techie has their own vision of the right way of setting things up.  I also want to talk to you about planning for scale.

“Premature optimization is the root of all evil” is a phrase people like to bandy about when people approach the topic of planning for scale before the need for it.  Well, first things first, the phrase is often taken way out of the context in which it was used.  Obviously you don’t need to unroll your loops in PHP, because listen, you’re using PHP and optimizing it’s performance doesn’t have a substantial effort/reward ratio.  Same goes with Rails/Ruby and Django/Python. But, it doesn’t mean that you can’t plan to be successful and get things in the right position for when you do need to scale.  There are some easy things you can do to make sure when the need comes at you full bore, you’ll be ready for it.

So let’s talk about hosting.  The Web 1.0 way was to colocate racks of metal in a datacenter somewhere or to pay for managed hosting through someone like RackSpace.  But that is a crazy thing to do now, it only makes sense when your site hits a certain threshold of scale.  If you’re at that scale now, what are you doing reading this article?

We’re working under the pretense that your business idea has to prove itself in the marketplace and that you need to get it into the marketplace as cheaply as possible.  So what options do we have? You can sign up for a VPS like dreamhost, but you’ll be cursing yourself when your site hits the front page of Digg or Reddit and the social news monkeys are kicking the shit out of your application.  A day is forever in internet time, so what are you going to do when you need to take your site down for a couple of days to migrate it to something else?

The next step up, then, is this “cloud” thing everyone is talking about.  And it’s the right step.  However, a number of people instantly assume we are talking about Amazon’s EC2 offering, and that is the wrong way to go.  Bandwidth on Amazon is not the cheapest thing around and I’m of the fundamental belief that EC2′s best purpose is for bursts of additional computing resources.  For instance, on Massify, we use EC2 to do parallel processing of media.  We can scale it up and down at will, taking it entirely off-line if we need to.  Having priced out hosting our site on EC2, the end costs were not that far off of managed hosting. So where does that leave us?  I heartily recommend SliceHost.  And I recommend the following starting setup:

Obviously, this isn’t the absolute cheapest way to start out, but it prepares you for growth.  If you develop with a share nothing architecture, you can easily slot in more application servers as needed, and take them down as needed, until such a point as your database becomes a bottleneck.  But that shouldn’t happen for awhile and the total cost for this rig on Slicehost?  $160 a month.  If you were to stuff it all into a single slice, you’d go for their 4GB or 8GB slices which run $250 and $450 respectively.

Run Rate: $5.20

Spread The Love Around

Like the DNS management, this step is entirely optional, but if you’re serving a ton of static content or media, I can’t imagine going without for very long.  The advantage of serving all your static content (this includes static html pages, javascript, css, images, media) is that it’s way cheaper than serving off even Slicehost and it takes a ton of load off.

Good news for you is that CDN’s are getting cheaper and cheaper.  We use Panther Express at Massify and our monthly bill is amazingly low.  I can’t really publish those numbers, so let’s talk about Amazon’s S3 and CloudFront pricing to get a rough number.  The basic way this works is that all of your static content gets pushed to S3 and then served up to your users via CloudFront.  CloudFront has a lot of nice features, though if you’re planning on doing video through it, you might look elsewhere as they don’t support HTTP chunking – which is the poor man’s way of doing video streaming and seeking.  Panther Express does support this, though BitGravity has some awesome looking capability as well.

Anyways, assuming we’re going to transfer 250 GB of data via our CDN, the numbers will surprise you:

S3 Storage and Transfer: $37.50 for 250GB

CloudFront delivery: $42.50 for 250GB

Combined, you would be paying roughly $80 a month for 250GB of data transfer.  For most sites that’s overestimating, but if you’re doing a user content generated site, you should probably aim higher.  I’m not at liberty to divulge how much we transfer per month, but it’s significant.  And despite that our CDN bills are shockingly low.

Run Rate:  $2.63

Total It Up

So we’ve covered everything from domain registration to company infrastructure to hosting and content distribution.  Here’s how the costs breakdown:

For a grand total of: $8.69 a day. Not too shabby.

So those are my tips based on my experience for the last two plus years.  Would love to hear comments and tips from others!

Some Background

For the last 2+ years, we’ve been running Apache with mod_php at Massify. And, for the most part, it’s been painless and hassle free. But as traffic increases, we’ve noticed Apache struggling to keep up. It chews up memory like crazy and don’t even get me started about CPU. Add in the fact that we are currently moving the site from co-located metal to hosting on the cloud, we’ve needed to find a faster way to serve up these pages on machines that are a quarter of the spec we had with the metal.

It’s a pretty well know fact by now that Nginx (pronounced engine-x, though I call it n-jinx) in typical scenarios outpaces Apache on all kinds of fronts: i/o, cpu, memory, reqs/sec. Feel free to google around for more comparitive information. I can tell you from my own informal load testing on both setups of Massify that I’ve seen a pronounced difference between the two, specifically in the configuration I’ll be writing about in this post. I won’t be posting numbers, because my testing wasn’t scientific and it’s not really the focus of this article, but I am more than confident that we’ll be getting a level of performance a few steps above Apache. (Please don’t write me telling me I can recompile and reconfigure Apache to approach Nginx’s performance. I’m certain you are correct, but I don’t really care at this point.)

PHP-FPM?

The typical nginx configuration involves using spawn-fcgi from the LightTPD project to get nginx serving up PHP. There are a few issues with spawn-fcgi that are covered on more in-depth posts across the interwebs, so I won’t rehash them here. Suffice to say, it can lead to major headaches, so we want to do what we can to avoid those headaches.

Enter PHP-FPM, which stands for PHP FastCGI Process Manager. It is actually a set of patches for the PHP source that bake in FastCGI process management into your PHP binaries.

Note: Even if you are sticking with Apache, there are a variety of reasons to skip mod_php and go straight for PHP via FastCGI. For starters, with mod_php, each request that Apache handles loads PHP – and all of it’s libraries. That’s an epic shit ton of overhead. With FastCGI, PHP acts more akin to an application server. PHP-FPM, as well as spawn-fcgi, manage this; loading and killing PHP instances as needed. This has a lot of benefits, not the least of which is reduced memory overhead.

Let’s Get Rocking

We’re using a fresh install of Ubuntu 8.10 Intrepid. With a little tooling, this can work equally well on other linux distros. I’ve deployed this on CentOS, with minor changes, just fine.

First things first, we’re going to have to install all the dependencies for building everything:

sudo apt-get install make bison flex gcc patch autoconf subversion locate
sudo apt-get install libxml2-dev libbz2-dev libpcre3-dev libssl-dev zlib1g-dev libmcrypt-dev libmhash-dev libmhash2 libcurl4-openssl-dev libpq-dev libpq5 libsyck0-dev

Now that we have everything we need, now it’s time to …

Compile PHP

We’re going to download the source for PHP 5.2.8, as well as the matching patches for PHP-FPM. We’ll then apply the patches and get compling.

cd /usr/local/src/
sudo wget http://us.php.net/get/php-5.2.8.tar.gz/from/this/mirror
sudo tar zvxf php-5.2.8.tar.gz
sudo wget http://php-fpm.anight.org/downloads/head/php-5.2.8-fpm-0.5.10.diff.gz
sudo gzip -cd php-5.2.8-fpm-0.5.10.diff.gz | sudo patch -d php-5.2.8 -p1
cd php-5.2.8
sudo ./configure --enable-fastcgi --enable-fpm --with-mcrypt --with-zlib --enable-mbstring --disable-pdo --with-pgsql --with-curl --disable-debug --enable-pic --disable-rpath --enable-inline-optimization --with-bz2 --with-xml --with-zlib --enable-sockets --enable-sysvsem --enable-sysvshm --enable-pcntl --enable-mbregex --with-mhash --enable-xslt --enable-memcache --enable-zip --with-pcre-regex
sudo  make all install
sudo  strip /usr/local/bin/php-cgi

The above should have been completely auto-pilot. If you run into any errors, more than likely you don’t have some of the dependencies installed. Note: Make sure you enable and disable whatever PHP configuration options you need for your particular setup. The above are what we use at Massify, more or less. (We actually apply a couple of other custom patches, but that’s another post for another day).

While we are at it, let’s install some of the modules we’re going to need via PECL:

sudo pecl install memcache
sudo pecl install apc
sudo pecl install syck-beta

Now, when you build the APC extension, make sure you turn off the option to compile for apache. It will prompt you to make this change.

Let’s copy the stock php.ini:

sudo cp /usr/local/src/php-5.2.8/php.ini-recommended /usr/local/lib/php.ini

Finally, let’s setup symbolic links to make things easier to find:

sudo mkdir /etc/php/
sudo ln -s /usr/local/lib/php.ini /etc/php/php.ini
sudo ln -s /usr/local/etc/php-fpm.conf /etc/php/php-fpm.conf

That’s it for compiling PHP. The only thing we have left to do is change some setting in the php-fpm conf. Open up /etc/php/php-fpm.conf in your editor of choice. Do some searching and change the users who own the processes to www-data. The file is too big to post in here, but the values we want to change are on lines 51, 52, 63 and 66. Should look something like:

<value name="owner">www-data</value>
<value name="group">www-data</value>
<value name="user">www-data</value>
<value name="group">www-data</value>

Done!

NGINX

This is just as easy as compiling PHP was:

cd ..
sudo wget http://sysoev.ru/nginx/nginx-0.6.35.tar.gz
sudo tar zxvf nginx-0.6.35.tar.gz
sudo rm -f nginx-0.6.35.tar.gz
cd nginx-0.6.35
sudo ./configure --sbin-path=/usr/local/sbin --with-http_ssl_module --without-mail_pop3_module --without-mail_imap_module --without-mail_smtp_module --with-http_stub_status_module
sudo make && sudo make install

Let’s set up some links:

sudo ln -s /usr/local/nginx/conf /etc/nginx

Now the next step is optional, but this is what I’ve been using so far. Let’s open up /etc/nginx/nginx.conf in our editor and go to town. Salt and pepper to taste:

user  www-data;
worker_processes  6;

events {
    worker_connections  1024;
}

http {
    include       mime.types;
    default_type  application/octet-stream;
    sendfile        on;
    keepalive_timeout  10 10;

    gzip  on;
    gzip_comp_level 1;
    gzip_proxied any;
    gzip_types text/plain text/html text/css application/x-javascript text/xml application/xml application/xml+rss text/javascript;

        log_format main '$remote_addr - $remote_user [$time_local] '
                  '"$request" $status  $body_bytes_sent "$http_referer" '
                  '"$http_user_agent" "$http_x_forwarded_for"';

        access_log  /var/log/nginx_access.log  main;

        error_log  /var/log/nginx_error.log debug;

        include /usr/local/nginx/sites-enabled/*;
}

We’re also going to have to set up some FastCGI parameters so that PHP doesn’t choke and you’ll avoid random 503 errors from nginx. Open up /etc/nginx/fastcgi_params and add the following:

fastcgi_connect_timeout 60;
fastcgi_send_timeout 180;
fastcgi_read_timeout 180;
fastcgi_buffer_size 128k;
fastcgi_buffers 4 256k;
fastcgi_busy_buffers_size 256k;
fastcgi_temp_file_write_size 256k;
fastcgi_intercept_errors on;

Finally, let’s create a SystemV style init script and store it in /etc/init.d/nginx. This script was lifted from here.

#! /bin/sh

### BEGIN INIT INFO
# Provides:          nginx
# Required-Start:    $all
# Required-Stop:     $all
# Default-Start:     2 3 4 5
# Default-Stop:      0 1 6
# Short-Description: starts the nginx web server
# Description:       starts nginx using start-stop-daemon
### END INIT INFO

PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
DAEMON=/usr/local/sbin/nginx
NAME=nginx
DESC=nginx

test -x $DAEMON || exit 0

# Include nginx defaults if available
if [ -f /etc/default/nginx ] ; then
        . /etc/default/nginx
fi

set -e

case "$1" in
  start)
        echo -n "Starting $DESC: "
        start-stop-daemon --start --quiet --pidfile /usr/local/nginx/logs/$NAME.pid \
                --exec $DAEMON -- $DAEMON_OPTS
        echo "$NAME."
        ;;
  stop)
        echo -n "Stopping $DESC: "
        start-stop-daemon --stop --quiet --pidfile /usr/local/nginx/logs/$NAME.pid \
                --exec $DAEMON
        echo "$NAME."
        ;;
  restart|force-reload)
        echo -n "Restarting $DESC: "
        start-stop-daemon --stop --quiet --pidfile \
                /usr/local/nginx/logs/$NAME.pid --exec $DAEMON
        sleep 1
        start-stop-daemon --start --quiet --pidfile \
                /usr/local/nginx/logs/$NAME.pid --exec $DAEMON -- $DAEMON_OPTS
        echo "$NAME."
        ;;
  reload)
      echo -n "Reloading $DESC configuration: "
      start-stop-daemon --stop --signal HUP --quiet --pidfile /usr/local/nginx/logs/$NAME.pid \
          --exec $DAEMON
      echo "$NAME."
      ;;
  *)
        N=/etc/init.d/$NAME
        echo "Usage: $N {start|stop|restart|force-reload}" >&2
        exit 1
        ;;
esac

exit 0

Don’t forget to set executable permissions on it!

Set Up Your Site

This part you’ll have to tool yourself, but here’s a rough guide.

First we’ll have to create a directory to store our site(s) conf files:

sudo mkdir /usr/local/nginx/sites-enabled
sudo ln -s /usr/local/nginx/sites-enabled /etc/sites

And now let’s add a conf file for our default site at /etc/sites/default.conf. The contents:

server {
        listen *:80;

        location / {
                root   /var/www/default/pub;
                index index.php;

                # if file exists return it right away
                if (-f $request_filename) {
                        break;
                }

                # otherwise rewrite the fucker
                if (!-e $request_filename) {
                        rewrite ^(.+)$ /index.php$1 last;
                        break;
                }

        }

        # if the request starts with our frontcontroller, pass it on to fastcgi
        location ~ ^/index.php
        {
                fastcgi_pass 127.0.0.1:9000;
                fastcgi_param SCRIPT_FILENAME /var/www/default/pub$fastcgi_script_name;
                fastcgi_param PATH_INFO $fastcgi_script_name;
                include /usr/local/nginx/conf/fastcgi_params;
        }
}

The conf file above is for front controller style sites, which include wordpress, cake, etc. It also takes care of serving up static content without going through FastCGI. Note: You will need to change /var/www/default to wherever the files for your site reside.

Start It Up

Now all we have to do to get it rocking:

sudo php-fm start
sudo /etc/init.d/nginx start

You should be able to test your site out and see it working. Any questions, feel free to ask.

Reference

• Nginx
• Nginx vs Apache Death Match
• 10,000 req/s with Nginx
• Replacing Apache With Nginx For Static File Serving
• PHP-FPM
• How to Install PHP-FPM
• PHP-FPM, A Smoother PHP FastCGI Process Manager

…

Got great coverage about Massify in the LA times.  Go Massify!