interfacelab

Blippy Clone in 2 Seconds and 3 Lines of PHP

Jon Gilkison — Wed, 03 Feb 2010 23:45:08 +0000

Since LoC wanking seems to be the rage this week, I decided to take a stab at cloning the hottest new thing to hit the internets since twitter: Blippy!

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.

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

My Mom is Going to Love the iPad

Jon Gilkison — Fri, 29 Jan 2010 08:24:18 +0000

My mom is totally going to love the shit out of this thing. Off the top of my head:

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.

Patch for HD plugin for JW Player

Jon Gilkison — Sun, 07 Jun 2009 08:24:28 +0000

If you are using JW Player and the HD plugin, you’ll notice the latest version of the plugin does bandwidth detection and automatically flips to the HD version of the file if the player has detected the user’s bandwidth can support it.

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:


	Please Upgrade your Flash Player to view this content

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.

Slicehost API Notes for the Non-Rails Posse

Jon Gilkison — Sat, 09 May 2009 06:38:23 +0000

I just want to start out by stating that I, in fact, am a big fan of Slicehost and constantly recommend them to friends setting up anything more serious than blogs. They have a truly great offering and their customer service has only been rivaled, in my experience, by the support team from DataPipe – whom I whole heartedly recommend for any colo or managed hosting.

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:



	
		slicename
		active
		
			XXX.XXX.XXX.XXX
			XXX.XXX.XXX.XXX
		
		666
		100
		0.0
		0.0
		10
		XXX.XXX.XXX.XXX
		2

The one issue I have with this is that the

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 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:


	
		CentOS 5.2
		2
	
	
		Gentoo 2008.0
		3
	
	
		Debian 5.0 (lenny)
		4
	
	{ .. and so on .. }

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:


	
		1
		256 slice
		2000
		256
	
	
		2
		512 slice
		3800
		512
	
	
		3
		1GB slice
		7000
		1024
	
	{ ... and so on ... }

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:


	NAME OF YOUR SLICE
	1
	2

The 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 .

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:


	build
	SLICE NAME
	
		XXX.XXX.XXX.XXX
		XXX.XXX.XXX.XXX
	
	666
	ROOT PASSWORD
	0
	0.0
	0.0
	2
	XXX.XXX.XXX.XXX
	1

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):


	
		3-666
		666
		daily
		Sat May 09 04:15:05 UTC 2009
	
	
		3-667
		666
		webserver_snapshot
		Sat May 09 04:15:05 UTC 2009

And, then, in the XML document you POST:


	NAME OF YOUR SLICE
	1
	3-666

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:


	666
	NAME OF YOUR SLICE

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

Deleting a Slice

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

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.

Bootstrapping Technology For Eight Bucks a Day

Jon Gilkison — Wed, 29 Apr 2009 03:50:51 +0000

In the following article, I’m going to attempt to describe how one might bootstrap the technical components of their startup as cheaply as humanly possible, while still giving you room to easily scale. A lot of this is based on what I’ve learned in the last 2+ years as the CTO of massify.com, an online networking site for film makers. Your mileage may vary, of course, and I’m sure there are a variety of alternatives to some of the things I’ll be recommending. I welcome all commenters to pitch in with their own experiences in hopes that we can grow this post into a useful resource for up and coming entrepreneurs.

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:

DNS	$0.08
Email	$0.00
Collaboration	$0.78
Hosting	$5.20
CDN	$2.63

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!

NGINX + PHP-FPM + APC = Awesome

Jon Gilkison — Fri, 24 Apr 2009 04:42:15 +0000

The following guide will walk you through setting up possibly the fastest way to serve PHP known to man. If there is a faster way, I’ve not yet found it climbing through zillions of blog posts out there on the subject. In this article, we’ll be installing nginx http server, PHP with the PHP-FPM patches, as well as APC. The end result? Pure awesome.

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:

www-data
www-data
www-data
www-data

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

…

Filmmakers Finding New Action Online

Jon Gilkison — Wed, 02 Jul 2008 18:04:39 +0000

Filmmakers finding new action online | Web Scout | Los Angeles Times

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

Wordle

Jon Gilkison — Mon, 23 Jun 2008 17:31:19 +0000

Found this awesome toy today.

Ciarán Walsh’s Blog » TextMate Tip – Using PHP for Commands

Jon Gilkison — Mon, 23 Jun 2008 17:29:18 +0000

Ciarán Walsh’s Blog » TextMate Tip – Using PHP for Commands

A must read for anyone doing php development with TextMate. I’m about 50/50 between TM and Eclipse, trying to wean myself over slowly.

Feedburner WP Plugin Category Fix

Jon Gilkison — Wed, 18 Jun 2008 07:07:30 +0000

I’ve patched the current Feedburner 2.3 plugin to support feedburner feeds for categories.

When you install the plugin and activate it, navigate to Settings -> Feedburner.

You should now see options for adding in URL’s for all of your category rss feeds.

Download here.

Note: The url for your feeds by category should be by name, eg:

http://interfacelab.com/feed?category_name=php