For gridtastic designs, this new technique appears to be the best answer CSS has to offer yet. The benefits of absolute positioning, but using relative positioning + negative margins so as not to break the layout. I plan to try this out on future sites I work on, so I withhold final judgment, but as things look right now, Eric Sol will end up as my new CSS rockstar hero.

Criticizing Twitter and crucifying a departing Twitter engineer are two entirely different things. Taking one of his presentation slides out of context, conjecture, supposition, lack of any credible witnesses or evidence… This isn’t news, it’s a snipe at a guy who knows a hell of a lot more about his job than you and your 2 Rails buddies. What do you have to gain from attempting to soil Blaine’s reputation?

“Sitting next to” Rails developers does not equate to knowledge about scaling the highest-traffic Rails app there has ever been, any more than my having John Resig’s JavaScript book sitting on my shelf makes me a JS ninja.

This story is a blatant smear job, nothing more. We’ll see who looks a little dumb when Twitter’s problems - which you don’t understand - continue long after Blaine’s departure.

I particularly liked Jeremy McAnally’s well-worded responses in the comments. They sum up everything that is wrong with Arrington’s post:

Wow, this is the most unnecessarily vitriolic articles I’ve ever seen. Twitter and Blaine took Rails to places it hadn’t been before in terms of scale and traffic (just as other sites did with PHP, Java, ColdFusion, and so on), and so acting as if he’s some unskilled hippie that didn’t know what he was doing just makes you look like an idiot. Sure, they had some bumps along the way, but no one else had even gotten on the same road as them to encounter the bumps. Being forced to figure out things along the way because no one has done them before doesn’t make you an “amateur.”

Even further, what the heck qualifies you to criticize someone’s ability to scale a website or doing anything remotely technical for that matter? You’re out of your league. Please stick to talking about business or whining about someone not giving you ad money.

and later:

If you think your Rails guys or gals have their “fingers on the pulse of the Rails community” and they think that Blaine is Twitter’s problem, then they’re lying to you. People who, like, actually know Blaine and other Twitterers can offer you much better information rather than baseless, ad money driven drivel. I can put you in contact with them if you drop me an e-mail (or I’m sure that Coda would be very happy to offer you any details you want).

Of course, investigation probably isn’t your thing since you don’t know much about journalism.

Indeed, it’s totally unacceptable that this kind of tripe passes for responsible journalism. Oh wait – it doesn’t. Perhaps people like Michael Arrington are part of the reason more legitimate blogs don’t get their journalistic kudos.

I don’t subscribe to TechCrunch, and frankly, after this display, I’m not about to. There are plenty of people Arrington could have asked to get the straight scoop, like, you know, a real journalist would have.

Some would say that exaggeration and overstatement is necessary to make an impact. Perhaps, but at what cost? A person’s reputation? For what purpose? To infuriate conscientious geeks? To generate a few hundred extra click-throughs? To wield power great and terrible?

Do your homework, don’t stomp on people who don’t deserve it, and the blogosphere will be a much more civil and harmonious place.

No more than a day later, Digital Web responded with an Introduction to Django. I just find it interesting that we have all of this in the same week.

Ruby on Rails and Django are competing web application frameworks that follow the MVC pattern. Rails is built on the Ruby programming language, while Django uses Python. It’s friendly competition, of course… it all boils down to whether you’re a Pythonista or a Rubyist.

I am a huge fan of Rails, but I’d also like to learn more about Django… that is, if I can overcome my own Ruby vs. Python bias. One of my fondest memories of SXSW this year was hearing Michael Lopp ask from the stage, “What’s wrong with this Python code?” and someone in the audience called out, “It’s not Ruby!”

Oooh, snap!

Somehow, deep down, I always knew I was a Cylon.

Update: I am having a bear of a time with the launchd plist for starting up the PHP FastCGI daemon. I can’t find the reason why this plist, after loading successfully with the launchctl utility, doesn’t load at all upon the next startup. Meanwhile, plenty of other launchd plists have no problem loading on startup. Baffled for the moment, and hating plists right now. Why couldn’t Apple have just gone with more conventional init scripts for spawning daemon processes at startup? </whine>

Many thanks to Dan Benjamin and Robby Russell, whose articles on similar subjects have helped me numerous times in the past, and inspired me to attempt a walk-through of my own.

Most importantly, I must stress that the contents of this article are provided as is, I do not claim to be an expert in any of the material I cover here, and I will be unable to provide technical support for these solutions. Feel free to leave a comment, of course, and I’ll do my best to correct any errata! I am not underwritten or funded by any professional organization, and everything I am writing is, to the best of my knowledge, as accurate as I can make it. This is the fruit of my own personal trial and error, and is also based on various sources I found on the Web. At the bottom, I’ve given attribution to these sources as I can recall.

Preamble

What you’re thinking is absolutely true. You do have to be a dyed-in-the-wool geek to even come close to caring about what I am about to say. This is not terribly hard material if you have a little experience with web development — indeed, for some of you, this is probably old news, although I haven’t found very many resources on this exact topic. For most of the rest of the populace, however, this may all be greek to you. You have my reprieve if you want to stop reading now and go update your Facebook profile. No worries.

In this article, there will be some Command-Line Fu. You’ve been warned. Get Mr. Terminal out and dust him off. You will need him.

Unlike some people, I personally don’t mind relying on MacPorts. I don’t often find myself in desperate need of the latest and greatest versions of open-source software, and being a rather disorganized person, I find any package manager that handles dependencies for me to be a Godsend. For my purposes, MacPorts is just such a package manager. Of course, when I have to, I’ll compile from source manually in true haXor fashion. 99% of the time, however, MacPorts gets it done for me.

Before you even get to install MacPorts, though, you need to have Apple’s humongous XCode tools installed. Robby Russell of PLANET ARGON wrote up a great summary of getting your development environment in order in the first part of his latest article on installing Rails and PostgreSQL on Mac OS X. Read and follow Phase One of that article, which covers XCode and MacPorts, and you’ll be all set to get started here with nginx and FastCGI. If you already have XCode and MacPorts set up and working, skip ahead.

As an aside, you might even want to go all the way through Robby’s tutorial and install Ruby on Rails too - if you’re a web developer and you haven’t yet checked out this awesome web application framework, you owe it to yourself. It could very well change your life. You can pick up back here when you’re done.

Installing nginx

According to the nginx English wiki:

Nginx was written by Igor Sysoev for rambler.ru, Russia’s second-most visited website, where it has been running in production for over two and a half years. Igor has released the source code under a BSD-like license. Although still in beta, Nginx is known for its stability, rich feature set, simple configuration, and low resource consumption.

Are you ready to give it a spin? Assuming that you’re up and running with MacPorts, you are now ready to install the mighty nginx web server on your Mac. This really is the easy part of the process. Open up Terminal if it’s not already running, and type the following command at the prompt:

sudo port install nginx

This will instruct MacPorts to download the nginx source, compile it, and install it in /opt/local. When it is nearly finished, the script should inform you that there is a property list you need to load via launchctl that will enable nginx to start on system reboot:

###########################################################
# A startup item has been generated that will aid in
# starting nginx with launchd. It is disabled
# by default. Execute the following command to start it,
# and to cause it to launch at startup:
#
# sudo launchctl load -w /Library/LaunchDaemons/org.macports.nginx.plist
###########################################################

If you want nginx to launch at startup, execute that command once the installation completes:

sudo launchctl load -w /Library/LaunchDaemons/org.macports.nginx.plist

Otherwise, you can run the nginx daemon manually (but wait a moment before doing so):

sudo /opt/local/sbin/nginx

Finally, before you can run nginx, you need to create a working default nginx configuration file, thusly:

sudo cp /opt/local/etc/nginx/nginx.conf.default \
        /opt/local/etc/nginx/nginx.conf

This file as is should be sufficient to get you started. There are a number of resources available for tailoring the nginx configuration to your needs. I’ve listed a few of them at the end of this tutorial, but as I’m not an expert on nginx configuration, I’ll let them do the explaining, and just mumble something like, “that’s outside the scope of this article,” or some-such. Gotta fight that scope creep!

Just kidding. I’ll list some example config files at the end of this article, after I cover how to install PHP. That’s next.

Installing PHP with FastCGI

PHP, the way we have to run it, is a bit tricky to install. We have to run PHP as a CGI daemon independently of nginx, because unlike Apache, nginx doesn’t have anything like a mod_php that we can simply plug in. Despite that complication, the performance benefits of nginx still outstrip the many conveniences of bloated Apache, at least in my view.

If you’re running Leopard, you technically already have PHP installed (This could also be the case with Mac OS X 10.4, or Tiger). However, just so we can know exactly (well, roughly) what we’re getting, we can just install a separate instance of PHP with MacPorts. Because MacPorts installs everything into /opt/local, and the existing PHP is installed in /usr/bin, never the twain shall meet. They’ll never know about each other. No marital infidelity jokes, now. Run this:

sudo port install php5 +fastcgi fcgi

MacPorts will again run off and download/compile/install a whole slew of dependencies, eventually getting around to PHP with FastCGI. If we’d compiled from source, I probably would have forgotten to tell you about one or two of them, and you’d be screwed. I like MacPorts because I am lazy and forgetful.

The installation script of PHP doesn’t provide you with a property list to load via launchctl, so we’ll have to roll our own. Create a new text file somewhere, name it whatever you like (I called mine com.tudorstudio.php-fastcgi.plist), and copy this in:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
  <key>Debug</key>
  <false/>
  <key>EnvironmentVariables</key>
  <dict>
    <key>PHP_FCGI_CHILDREN</key>
    <string>2</string>
    <key>PHP_FCGI_MAX_REQUESTS</key>
    <string>1000</string>
  </dict>
  <key>Label</key>
  <string>com.tudorstudio.phpfcgi</string>
  <key>OnDemand</key>
  <false/>
  <key>ProgramArguments</key>
  <array>
    <string>/opt/local/bin/php-cgi</string>
    <string>-b 127.0.0.1:9000</string>
    <string>-q</string>
  </array>
  <key>RunAtLoad</key>
  <false/>
</dict>
</plist>

As configured above, the daemon will run on port 9000, and spawn 2 child processes. Feel free to change those values to fit your needs. Notice that the filename (com.tudorstudio.phpfcgi in the above example) is referenced on about line 15; I’d recommend that you change that to whatever you named your own PLIST. You are free to use my filename if you like.

Now, in the same directory as your newly created property list, run the command to load it into your launchd configuration, like so (again, changing the filename to match your file):

sudo launchctl load -w com.tudorstudio.php-fastcgi.plist

This tells launchd to launch our FastCGI daemon process at system startup. If you wish, you can run this daemon manually:

sudo /opt/local/bin/php-cgi -q -b 127.0.0.1:9000

There is also a shell script that can simplify the command for you - it’s listed at the bottom.

Config Files

As promised, here are some example configuration files for nginx on the Mac. These are pretty close to what I’m currently using, but I don’t claim to be very knowledgeable in this area - it’s just what works for me, and I’m sure I’m just barely scratching the surface. All three of these config files are located in /opt/local/etc/nginx.

nginx.conf

# user nobody;
worker_processes  1;

error_log  /opt/local/var/log/nginx/error.log;
pid        /opt/local/var/run/nginx.pid;

events {
    worker_connections  1024;
}

http {
    include       /opt/local/etc/nginx/mime.types;
    default_type  application/octet-stream;

    access_log  /opt/local/var/log/nginx/access.log;

    sendfile        on;
    #tcp_nopush     on;

    #keepalive_timeout  0;
    keepalive_timeout  65;
    tcp_nodelay        on;

    gzip  on;

    include /opt/local/etc/nginx/sites.conf;
}

sites.conf

# You may add here your
# server {
#       ...
# }
# statements for each of your virtual hosts

server {
    listen 80;
    server_name localhost;
    # server_name example.com;

    access_log  /opt/local/var/log/nginx/localhost.access.log;

    location / {
        root   /opt/local/share/nginx/html;
        index  index.php index.html index.htm;
    }

    #error_page  404  /404.html;

    # redirect server error pages to the static page /50x.html
    error_page   500 502 503 504  /50x.html;
    location = /50x.html {
        root   /opt/local/share/nginx/html;
    }

    # pass the PHP scripts to FastCGI server listening on 127.0.0.1:9000
    location ~ \.php$ {
        fastcgi_pass  127.0.0.1:9000;
        fastcgi_index index.php;
        fastcgi_param SCRIPT_FILENAME /opt/local/share/nginx/html$fastcgi_script_name;
        include       /opt/local/etc/nginx/fastcgi.conf;
    }
}

fastcgi.conf

fastcgi_param  QUERY_STRING       $query_string;
fastcgi_param  REQUEST_METHOD     $request_method;
fastcgi_param  CONTENT_TYPE       $content_type;
fastcgi_param  CONTENT_LENGTH     $content_length;

fastcgi_param  SCRIPT_NAME        $fastcgi_script_name;
fastcgi_param  REQUEST_URI        $request_uri;
fastcgi_param  DOCUMENT_URI       $document_uri;
fastcgi_param  DOCUMENT_ROOT      $document_root;
fastcgi_param  SERVER_PROTOCOL    $server_protocol;

fastcgi_param  GATEWAY_INTERFACE  CGI/1.1;
fastcgi_param  SERVER_SOFTWARE    nginx;

fastcgi_param  REMOTE_ADDR        $remote_addr;
fastcgi_param  REMOTE_PORT        $remote_port;
fastcgi_param  SERVER_ADDR        $server_addr;
fastcgi_param  SERVER_PORT        $server_port;
fastcgi_param  SERVER_NAME        $server_name;

# PHP only, required if PHP was built with --enable-force-cgi-redirect
fastcgi_param  REDIRECT_STATUS    200;

php_fastcgi.sh

As promised, here is an example of a bash script that can be used to simplify the spawning of the PHP-CGI daemon. Please use responsibly, and alter it as you see fit.

#!/bin/bash
# From http://blog.kovyrin.net/2006/05/30/nginx-php-fastcgi-howto/
# Modified per http://henrik.nyh.se/2008/02/php-in-nginx-on-os-x.
# Further modified by Stephen Tudor for private use.

## ABSOLUTE path to the PHP binary
PHPFCGI="/opt/local/bin/php-cgi"

## tcp-port to bind on
FCGIPORT="9000"

## IP to bind on
FCGIADDR="127.0.0.1"

## number of PHP children to spawn
PHP_FCGI_CHILDREN=2

## number of request before php-process will be restarted
PHP_FCGI_MAX_REQUESTS=1000

# allowed environment variables sperated by spaces
ALLOWED_ENV="PATH USER"

## if this script is run as root switch to the following user
USERID=nobody

################## no config below this line

ALLOWED_ENV="$ALLOWED_ENV PHP_FCGI_CHILDREN"
ALLOWED_ENV="$ALLOWED_ENV PHP_FCGI_MAX_REQUESTS"
ALLOWED_ENV="$ALLOWED_ENV FCGI_WEB_SERVER_ADDRS"

if test x$UID = x0; then
  EX="/usr/bin/sudo -u $USERID $PHPFCGI -q -b \"$FCGIADDR:$FCGIPORT\"" 
else
  EX="$PHPFCGI -b $FCGIADDR:$FCGIPORT"
fi

echo $EX

# copy the allowed environment variables
E=

for i in $ALLOWED_ENV; do
  E="$E $i=${!i}"
done

# clean environment and set up a new one
nohup env - $E sh -c "$EX" &> /dev/null &

Conclusion

I hope that you found this article useful in getting you on your way with nginx and PHP with FastCGI on Mac OS X. I have no reason to believe this wouldn’t work just as well with Tiger as it does Leopard, but since Leopard is what I’ve got to work with, YMMV.

Attribution

For the most authoritative, albeit terse, information on nginx in English, head on over to the nginx English wiki and drink in as much as you can.

For the majority of what I included here in this little exercise, I owe beer to:

• Henrik Nyh, who wrote one of the only Mac/nginx/php articles I could find, and put up a pastie of an example FCGI shell script.
• Matthew King, who posted the original snippet of an example launchd property list for PHP with FCGI.
• Chu Yeow, who listed some awesome nginx config file examples.
• Alexei Kovyrin, who posted a nice nginx/PHP/FCGI howto.

Thanks, guys, for being awesome.

Adactio has the full scoop on the April Fool’s pranks that went down on the Web in 2008. My personal favorite of the day was John Resig’s “release” of Classy Query, but then, as Jeremy intimates, I’m obviously a code nerd. I particularly enjoyed Gordon’s comment on that post, quoted here:

I’m glad that you’ve seen the light. Us old guys don’t want none of your fandangled duck-type magic fancypants crap.

The old ways are the best ways!

This is a reminder that there will be a meeting called tonight for the BSG-SS (Battlestar Galactica Secret Society) at ADDRESS DELETED. It is imperative that all attend, as there is limited time in which to watch Season 3 before the premier episode of Season 4 next week. We at the BSG-SS do not take this lightly.

There will be popcorn, soda and a festive atmosphere.

BSG Forever \\  //

Apparently, I am a cloak-wearing member of this group, and I may have been participating in some Season 3 episode-cramming this week. But only if it’s strictly off the record. After all, who would openly admit to liking a show called Battlestar Galactica?

Those well-crafted turns of phrase? Gone. Those painstakingly sly aphorisms? They’re in the Internet’s ever-expanding /dev/null receptacle. As Murphy’s Law dictates, these sorts of situations tend to happen not just at the most inopportune moments you can imagine, but especially the ones you can’t.

Online blog editing was the whole of my blogging experience until today. Sure, I knew it wasn’t ideal, and I got bitten a few times by dropped sessions while editing a post, but that never prompted me to change my behavior or investigate any solutions to the issue. You win some, you lose some. It was good enough, I thought. I had heard from a many people in my lifetime that the best way to write is to write drafts. A crappy, yet uncensored, first draft to capture the energy of thought, followed by subsequent revisions to harness that energy and make it actually intelligible.

I’m not saying I’ll ever be a great (or even good) writer by starting to write drafts of blog posts, but I think it’s a step in the right direction. One critical component of my blogging process has to change, though: I have to abandon the online blog editor. Blogging through an online form just seems wrong anymore, not just for reliability’s sake, but for posterity’s sake too.

I’ve been a proponent of plain text for a couple of years, thanks mainly to Merlin Mann’s pontifications on the subject. Plain text is the best data format. It’s ubiquitous, and very nearly infinitely backwards- and forwards-compatible (aside from the difference in Windows/Unix newline characters). A ton of other data formats are built on top of plain text: HTML, XML, YAML, CSS, CSV, JSON… but plain text is the key. You can pretty much rest assured that your data will be accessible 50 years from now if you store it in plain text.

When it comes to editing plain text on the Mac environment (my platform of choice), TextMate sits on the top of the heap. For me, it’s a Swiss Army knife of editing anything. TextMate’s awesome bundle API makes it totally extensible. I do nearly all my web development work on TextMate (in combination with Terminal and Firefox/Firebug), so why not blogging too? TextMate does have a Blogging bundle.

After configuring it with this blog’s XML-RPC script, I was able to post new articles and edit existing blog posts in TextMate. On top of that, I can keep and maintain a local record of all of my drafts for future blog posts in plain text! This post was, in fact, written in and posted via XML-RPC with TextMate. Too easy.

I’m never going back if I can help it.

I won’t pretend to believe that very many people even knew about me, or missed me, but to those who did, thanks.

Now that that’s out of the way, I’d like to share one of my finest memories from Austin this year. My wife, Sarah, and I went to South by Southwest, she to the film festival and I to the interactive web nerd-athon. What made my week wasn’t the weather, which was downright frigid and damp at times. It wasn’t the food, which started out as this amazing novelty, but after a week of Tex-Mex and chicken-fried steak, I just wanted a good old PBJ. No, the highlights for me were, not surprisingly, the people I met (and almost-met), and the incredible panels I was fortunate enough to attend. OK, and maybe a party or two!

Some of the panels actually made some brave incursions into niche comedy, defying their very panel-ness. In particular, Merlin Mann’s pitch for the Worst Website Ever un-panel had a room packed with geeks eating out of his hand. Warning: If you’re not a web geek, you may not find this very funny. But if so… enjoy. You’ve probably seen this already, though.