The New York Post posted an article today on what it means to be part of the Fat Pack. If you’re thinking that this is another common newsbite on the life of unhealthy, over-weight Americans who love McDonalds, you would be quite mistaken. At least about the McDonalds part.

The Fat Pack is actually a reference to the army of taste testing gluttons making up the food writing, culinary and review industry. It’s an exclusive club of sorts that meets at fine dining establishments, espouses secretive French lingo and gushes over the wonderful qualities of… fat.

The journalists, bloggers, chefs and others who make up the Fat Pack combine an epicure’s appreciation for skillful cooking with a glutton’s bottomless-pit approach. Cramming more than three meals into a day, once the last resort of a food critic on deadline, has become a way of life. If the meals center on meat, so much the better.

Even to those who have been in the game long enough to have seen more than a few cycles of food and diet fads, the Fat Pack culture is a shock.

“Most of us who are in this profession are here as an excuse to eat,” said Mimi Sheraton, the food writer and former New York Times restaurant critic who has chronicled her own battle with weight loss. Still, she said, “I’ve never seen such an outward, in-your-face celebration of eating fat.”

Research has shown that Americans generally take a dim view on their obese counterparts. The overweight are paid less, make negative first impressions and denied more services when compared to their thinner counterparts. Yet in the food industry, being fat is almost looked on as proof of one’s passion of eating. Portly bellies proudly attest to years in the gladiatorial arena of silver forks and spoons. Looking in the mirror each morning, I can attest to the fact that my own body is slowly working it’s way toward the uniquely dubious honor. Ironically, I mention this all the while chewing away at a coconut pastry passed my way (bit firm, too much coconut flakes on the outside, not enough taste infused into the actual bread).

I’ve said it multiple times and I’ll say it again: it’s actually not that fun eating for a living. Don’t get me wrong, I love food. This job would be a living hell if I didn’t like food. Not to mention, I wouldn’t ever hear the end of it from the throngs of would-be critics. After all, who wouldn’t be jealous at a life of gluttony when compared to a life of bland prix fixe: the hour commute appetizer, eight to five entree and casual Friday desert. Like any fantasy however, the illusion disappears when the wizard yanks away the curtain.

For a food critic, the magical revelations come in the form of jeans that no longer fit, uncomfortably tight shirts, a rise in cholesterol and increases in blood pressure. Then there’s the sudden aversion to any restaurant we have already sampled (it’s our version of repeating work). However, the true icing on the cake rears it’s mouthful of glory when we’re in our prime environment- a new, virgin restaurant. Prior to peeking at the menu, comes the fore knowledge that no less than three plates are sure to grace the table for consumption. Damn if those overstuffed, caloric soaked stomachs plead to the contrary. Just like you wouldn’t miss out on pizza in Chicago, we’re not about to pass up the tour du jour of antipasto, primi, secondi and dolce.

As if motivations for over-eating aren’t around each corner, there’s a never ending list of restaurant recommendations. We certainly appreciate suggestions, though it has become an impossibly long list. Imagine yourself a cook walking through Costco, only to have every customer shove a cart full of food for you to prepare. That’s about the gist of our interactions. The definition of awkward occurs when we do take someone up on a recommendation, only to find that the food is quite awful to our palettes. As politically correct as I can spin the tale of different tastes for different people, I’m still don’t find myself above lying to avoid a few embarrassing situations.

Yes, I know, I’m bad. But please, don’t stop sending recommendations. I swear, I totally love those sweet and sour pork globs at the karaoke bar down the street. Honest :)

Another quick post regarding Roundcube, a relatively new webmail platform and garbled text issues.

I was attempting to put a Roundcube installation up yesterday and initially ran into a weird issue where the page was spilling out unreadable text that was garbled up. Obviously, something was being served up while there were no errors being spit out, so I immediately thought it might be some strange charset issue of some kind.

Looking at the settings, everything looked fine and it Roundcube was using UTF-8. No bizzareness there. Scratching my head, I started putting in debug points to see where things were failing. Turns out, it was a compression issue. Guess that should have been apparent sooner, but I am new to such things. Anyhow, I turned off compression in PHP and everything worked like a charm afterward. On the other hand, if you don’t want to turn off PHP compression, you can also comment out the z-lib compression lines in Roundcube’s index.php file for the same effect.

Alert: Total geek post.

Thought I would do a favor to anyone Googling for answers out there that might experience what I’ve run into the last day. Lighttpd is a relatively new webserver that I’ve picked over Apache, simply due to speed. Light does not handle .htaccess files however, which can post a major problem to developers familiar with the already arcane mod_rewrite, RewriteCond and RewriteRule voodoo that already goes on.

Many off-the-shell CMS packages like Joomla, Wordpress and Drupal use URL friendly filenames to help with SEO. It turns URLS that look like:
http://www.coffee.net/index.php?id=52&page=2&content=article

Into the more readable:
http://www.coffee.net/article/51/2.html

This is most often achieved with the very simple .htaccess command of:

RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule (.*) index.php


As mentioned earlier, lighttpd does not support .htaccess files or this mod_rewrite syntax. It uses url.rewrite and url.redirect instead for various common redirection and rewriting tasks.

Searching on Google, I came across various posts on how to achieve the same effect, some using mod_magnet with a combination and others simply having their error 404 handler take care of things. I didn’t want to do either of these, because:
1) Having gone the error handler route, the server will DROP (yes, drop) any GET requests sent. I’ve tested this in Apache initially as a shortcut to save some cpu cycles thinking that Apache’s error handler would be faster than mod_write examining the disk. It worked great until my entire CMS system failed completely and left me debugging the hell out of the system until I realized the GET vars were just being dropped. (For the curious, light works in the same way)
2) Mod_magnet and lua, while I’m sure work fine, look like more overhead on top of mod_rewrite already. I hate overhead. Like, a lot.

So, Googling around more, I found some nice clues. First was lighttpd’s very own configuration docs that mention two servers variables: $PHYSICAL["existing-path"] and $PHYSICAL["path"], both of which seemed to be promising as variables to indicate whether a URL requested is a file that exists on the system. Paydirt. Then I realized it requires light 1.5.0 and that I don’t yet have that installed. Poop. (Yes, I could simply upgrade, but having just got things working, I don’t want to risk destroying anything until AFTER I get everything solidified. Looks like we’ll have to do things the hard way.

Here’s the eventual code that I came up with do perform the similar feature:

url.rewrite = (
"^/reserved/(.*)$" => "$0",
"^/static.html" => "$0",
"^/.+\.(html)$" => "/index.php",
"^/(.+)/$" => "/index.php"
)


It’s short, sweet and leaves many lovely CPU cycles untouched vs some big regex monsters. Obviously, this specific code is made for Coffee.net’s own CMS, but it’s not hard to tweak it to your own desire. The first and second line is to set aside any special directories or filenames that you don’t want rewrite to process. The rest looks for .html or directory requests- which should be what your webserver is receiving if you’re using friendly URLs.

Of course, I’d prefer -f and -d anyday given it’s probably faster, but this will do for now (at least until I upgrade lighty to 1.5 and see if I can get the $PHYSICAL var to do some magic).

Six hours.

That’s the amount of time between downloading WordPress and having it (almost) seamlessly integrated into the website. Normally when I download any development packages, I try to budget a good deal of time to simply ramp up on new code, architecture and design. Even for a popular package like WordPress, it’s hard not to have some type of painful anticipation on how well things are going to go when you delve under the hood. My guess is that it’s somewhat akin to a Toyota mechanic who is getting their first shot looking at a new Prius- beautiful, with a possibility of electrocution.

Needless to say, rather than easing my way into WordPress, I immediately slapped in four plugins and pulled an Edward Scissorhands on the default template. The plug-ins didn’t crash in horrific fashion or throw exceptions, which is always a good sign of a mature application. At the same time, the PHP templates were pleasantly easy to modify due to the intuitive organization and readability of code. No electrocution after all - most excellent.

The only misstep was Akismet, which was temporarily giving problems about not having an API key even after I created an account. Apparently, it was just an issue of waiting for the key to propagate on the server, as the key worked fine an hour later.

So, for any coders or business types out there that are looking for blogging software or a blog platform to use- for what it’s worth, WordPress has my vote.

It’s a good news day, as the Coffee.net servers have been upgraded! Previously operating on the equivalent of a tall decaf, we are now jittering at double-shot venti levels with dedicated web, database and firewall servers. Combined with our improved back-end and front-end coding, our site should be rockin’ fast now.

For those web developers who wonder about the effect of load times, studies show [akamai.com] that the average visitor will leave a retail website if it doesn’t load in under four seconds. That’s quite a harsh penalty in absolute terms, but in the context of the web three seconds is an eternity. The good news is that most web pages do meet the three second rule. The bad news is that four seconds is the absolute pain threshold and that web developers can always do better.

So, for the casual webmaster out there, here’s a few quick PHP and mysql tips from the development side of Coffee.net on how to help beat that four second (and hopefully one second) rule:

1. In your scripts, try to either stay in PHP or stay out of PHP for as long as possible. Constantly jumping in and out of PHP is inefficient and will cause forking unless you use a module like FastCGI.

   Good: echo ‘[html][h1]‘.$header.’[/h1][/html]‘;

   Bad: [html][h1][?php echo $header; ?][/h1][/html]

2. Use single quotes instead of double quotes in your echo statements. Double quotes are processed for variables while single quotes are not. It adds a little time to your coding, but leads to cleaner and faster code

   Good: echo ‘You are visitor’. $visitor;

   Bad: echo “You are visitor $visitor”;

3. When hitting your database, try to combine queries if possible, rather than constantly going back. Your sql server does not take kindly to taking request after request in a row and performs much better when given a giant query over a multiple small ones.

   Good: $result = mysql_query(’SELECT `firstname` FROM tblPayroll WHERE `lastname` = \’clinton\’ OR `lastname` = \’obama’\ OR `lastname` = \’mccain\’ OR …’)

   Bad: foreach ($candidates as $foo) { $result = mysql_query(’SELECT `firstname` FROM tblPayroll WHERE `lastname` = \”.$foo.’\'); }

4. Use mysql_fetch_row or mysql_fetch_assoc rather than mysql_result. The speed is quite superior in large datasets, as it fetches an index and then moves the key up, rather than n-searching for a row number.

   Good: while ($vars = mysql_fetch_assoc($result)) { echo $vars['firstname']; }

   Bad: for ($i = 0; $i < mysql_num_rows($result); $i++) { echo mysql_query($result, $i, ‘firstname’); }

5. Set proper indexes on your sql tables. Indexes help your database determine where a row is located in your table, rather than iterating over every single row looking for that specific item. S you have column ‘lastname’ and it has the values ‘clinton’, ‘obama’, ‘mccain’, ‘paul’ and ‘romney’ in that order. If you want to lookup ‘paul’, your database will first match against ‘clinton’, then ‘obama’, then ‘mccain’ and finally find ‘paul’ at the 4th row. Not horrible, until your database grows to a thousands of rows and now you’ve got 4,000 rows to search before finding your guy. By indexing the column, your database will sort the names alphabetically and assign values to each rows, such as 1-clinton, 2-mccain, 3-obama, 4-paul, 5-romney. Now when it looks for ‘paul’, it simply jumps to row 4 directly and bam, you’re done.

These are just a few quick tips on coding that address some of the major bottlenecks that most coders will encounter. Obviously, there are other ways to seriously beef up your load speed like (duh) upgrading to a dedicated server, caching, pre-compiling your php scripts, using compression and using heap (memory) tables for read-only operations. But if you know about these, then you probably already know all the basic tips anyways :)

Before we go, we want to thank the guys at Wowrack.com (Ed, Budi) for helping with our server setup. Wowrack is based out of the Westin Building, smack in the center of Seattle. We originally hosted our site with a very reputable facility on the East coast, but it made a lot more sense once we were out of the development cycle to bring our servers closer to home. After all, it just doesn’t make a lot of sense for internet traffic to travel 3,000 miles to access a website about the city you live in, right?

Cheers to our new servers!