The Bug

1. Set a Javascript string variable containing CSS styles (<style> or <link>) followed by some HTML content, such as a <p> tag (in my application this happened via JSONP).
2. Add a <div> node to the DOM
3. Insert the content from #1 into the .innerHTML property of the <div>
4. The content gets inserted, devoid of CSS styles.

<!-- these styles are ignored when inserted via innerHTML -->
<style>
  p { color: blue; }
</style>
<p>Hello, how are you!</p>

The Solution

The simple solution was to put the other markup before the <style> or <link> tag. Bizarre.

<p>Hello, how are you!</p>
<!-- these styles are applied when inserted via innerHTML -->
<style>
 p { color: blue; }
</style>

Because IE needs something that affects the layout before it will apply CSS styles in an innerHTML property, these will not work as style triggers:

• <!-- a comment -->
• <p></p> (or any other empty block-level HTML tag)

What follows are some best practices that I have learned over the past several years from the school of hard knocks.

Use revision control

• Version control all schema documentation and setup files, right alongside your code. This could be in the form of a MySQL Workbench file (.mwb), SQL, plaintext, PHP, or HTML files.
• Version control your database schema. I personally prefer to use individual SQL files for this purpose, one file per revision (each revision file could contain multiple SQL statements). Include INSERTs for tables that need to be pre-populated for your application to work properly, such as role or permission options, country or state data, and categories.
• Correlate code revisions and database schema revisions. For each codebase revision, there should be a way to re-create the corresponding database schema. An effective way to do this is to name individual SQL revision files after the codebase revision in which they were created (e.g. r389.sql).
• Store the database version in the database. You should be able to tell what database schema version you are running, and the codebase version that goes with it.

Rules of engagement

• Write readable SQL. Proper indentation, newlines, and comments are as important in your SQL as they are in other types of code. See my MySQL Style Guide for a suggested way to do it.
• Terminate each SQL statement with the proper delimiter. Usually, this will be a semicolon. This is recommended even if there is only a single SQL statement in the migration to prevent query syntax errors when running multiple migrations.
• Migrate forwards and backwards. When writing a database migration, include a way to roll back to the previous revision after the migration is already applied. Your version control system provides this for your code, but you’ll be limited if you can’t roll back your database too. You can do this by creating pairs of migration files for each revision, one to make a change, and one to undo it.
• Always test your migrations, no excuses. Don’t change your database schema with a GUI tool and then write a migration script as an afterthought. Write your migration, and run it on your own database before committing it to the codebase.
• Never change a migration file, unless you are certain that no one else has run the migration yet. If you test, you shouldn’t ever need to anyway.

Write bulletproof migrations

• Consider index speed. For large tables, re-indexing can take a while. Consider dropping an index and re-adding it after altering indexed columns or running an UPDATE query.
• Omit column order clauses such as ADD COLUMN `column_b` VARCHAR(50) AFTER `column_a`. Unless a very specific column order is required, this is unnecessary and can introduce errors if a database happens to lack `column_a` during migration.
• Preface CREATE TABLE statements with DROP TABLE IF EXISTS. Likewise, use DROP TABLE IF EXISTS when removing a table.
• Avoid key conflicts by running a DELETE or TRUNCATE before INSERT, or use REPLACE instead.
• Set character set and collation settings at the database level, and remove references to specific character sets or collations at the table or column level. MySQL Workbench is notorious for adding these when changing or creating VARCHAR() or TEXT columns, which can cause display or foreign key problems if a mismatch occurs.
• Beware of losing or corrupting data. Data loss may be insignificant during development, but consider the impact your migration will have on a production database.
  • Altering a column is generally preferable to dropping and re-adding a column.
  • When changing between incompatible datatypes (such as changing from VARCHAR() to DATE), you should use this sequence:
    1. Rename the old column or table,
    2. Add the new column or table,
    3. Run an UPDATE query to reformat and copy the data from the old location to the new one, and then
    4. Drop the old column or table.
• Be aware of index name length limits. MySQL silently truncates really long index names, and if you try to add a similar (long) index name, it could inexplicably clash with the other index.

Play nice with InnoDB

MySQL’s InnoDB storage engine, now the default in MySQL 5.5, is very strict and often obscure in its error messages. These rules will save you lots of grief when applying migrations that affect InnoDB tables, especially when it involves foreign key constraints.

• Avoid suppressing InnoDB foreign key checks with FOREIGN_KEY_CHECKS=0, unless you know what you are doing and have a very good reason.
• Match foreign keys exactly. Type, length, attributes (signed/unsigned, nullable, etc), character set, collation, and storage engine must all match identically.
• Drop foreign key constraints before altering primary or foreign keys. You’ll need to use separate ALTER TABLE statements for this, one to remove the constraint and change the column, and one to re-add the constraint.
• Drop the primary key index before changing a primary key column. Much like the previous point, but you’ll need to run DROP PRIMARY KEY, make your change, and then ADD PRIMARY KEY (`column`) afterwards.
• Remove references to specific databases. Your foreign keys should not depend on the presence of another specific database, and should work regardless of the database name. MySQL Workbench is notorious for adding schema prefixes to table names when creating foreign key constraints.
• Be aware of foreign key constraint name length limits. See the point “Be aware of index name length limits” above.

Smooth the migration process

• Apply all the statements for a single revision inside a transaction, so that whenever it fails, your database is not left in an unstable state. This way, you can fix the error and re-run the entire migration.
  
• Automate schema migrations. Don’t make your co-workers apply schema revisions by hand; script it.
  
• Take a backup first.* On production databases, this is just raw common sense. Take precautions against Murphy’s law.
• Test on a backup copy.* Some bugs can lurk in production databases that might not be present in your development database due to data differences. Know that your migration will work on the production database, before you apply it.

* Specific to production databases.

function is_mobile() {
	var agents = ['android', 'webos', 'iphone', 'ipad', 'blackberry'];
	for(i in agents) {
		if(navigator.userAgent.match('/'+agents[i]+'/i')) {
			return true;
		}
	}
	return false;
}

This version is fast and easy to extend to detect additional browsers by changing the agents array. Here’s a much more thorough version, modified from detectmobilebrowsers.com:

function is_mobile() {
	return /android.+mobile|avantgo|bada\/|blackberry|blazer|compal|elaine|fennec|hiptop|iemobile|ip(hone|od)|iris|kindle|lge |maemo|midp|mmp|opera m(ob|in)i|palm( os)?|phone|p(ixi|re)\/|plucker|pocket|psp|symbian|treo|up\.(browser|link)|vodafone|wap|windows (ce|phone)|xda|xiino/i.test(a)||/1207|6310|6590|3gso|4thp|50[1-6]i|770s|802s|a wa|abac|ac(er|oo|s\-)|ai(ko|rn)|al(av|ca|co)|amoi|an(ex|ny|yw)|aptu|ar(ch|go)|as(te|us)|attw|au(di|\-m|r |s )|avan|be(ck|ll|nq)|bi(lb|rd)|bl(ac|az)|br(e|v)w|bumb|bw\-(n|u)|c55\/|capi|ccwa|cdm\-|cell|chtm|cldc|cmd\-|co(mp|nd)|craw|da(it|ll|ng)|dbte|dc\-s|devi|dica|dmob|do(c|p)o|ds(12|\-d)|el(49|ai)|em(l2|ul)|er(ic|k0)|esl8|ez([4-7]0|os|wa|ze)|fetc|fly(\-|_)|g1 u|g560|gene|gf\-5|g\-mo|go(\.w|od)|gr(ad|un)|haie|hcit|hd\-(m|p|t)|hei\-|hi(pt|ta)|hp( i|ip)|hs\-c|ht(c(\-| |_|a|g|p|s|t)|tp)|hu(aw|tc)|i\-(20|go|ma)|i230|iac( |\-|\/)|ibro|idea|ig01|ikom|im1k|inno|ipaq|iris|ja(t|v)a|jbro|jemu|jigs|kddi|keji|kgt( |\/)|klon|kpt |kwc\-|kyo(c|k)|le(no|xi)|lg( g|\/(k|l|u)|50|54|e\-|e\/|\-[a-w])|libw|lynx|m1\-w|m3ga|m50\/|ma(te|ui|xo)|mc(01|21|ca)|m\-cr|me(di|rc|ri)|mi(o8|oa|ts)|mmef|mo(01|02|bi|de|do|t(\-| |o|v)|zz)|mt(50|p1|v )|mwbp|mywa|n10[0-2]|n20[2-3]|n30(0|2)|n50(0|2|5)|n7(0(0|1)|10)|ne((c|m)\-|on|tf|wf|wg|wt)|nok(6|i)|nzph|o2im|op(ti|wv)|oran|owg1|p800|pan(a|d|t)|pdxg|pg(13|\-([1-8]|c))|phil|pire|pl(ay|uc)|pn\-2|po(ck|rt|se)|prox|psio|pt\-g|qa\-a|qc(07|12|21|32|60|\-[2-7]|i\-)|qtek|r380|r600|raks|rim9|ro(ve|zo)|s55\/|sa(ge|ma|mm|ms|ny|va)|sc(01|h\-|oo|p\-)|sdk\/|se(c(\-|0|1)|47|mc|nd|ri)|sgh\-|shar|sie(\-|m)|sk\-0|sl(45|id)|sm(al|ar|b3|it|t5)|so(ft|ny)|sp(01|h\-|v\-|v )|sy(01|mb)|t2(18|50)|t6(00|10|18)|ta(gt|lk)|tcl\-|tdg\-|tel(i|m)|tim\-|t\-mo|to(pl|sh)|ts(70|m\-|m3|m5)|tx\-9|up(\.b|g1|si)|utst|v400|v750|veri|vi(rg|te)|vk(40|5[0-3]|\-v)|vm40|voda|vulc|vx(52|53|60|61|70|80|81|83|85|98)|w3c(\-| )|webc|whit|wi(g |nc|nw)|wmlb|wonu|x700|xda(\-|2|g)|yas\-|your|zeto|zte\-/i.test(navigator.userAgent.substr(0,4));
}

Since this is a single gigantic regex, I suspect that it would run more slowly than the previous version, and is also more challenging to modify.

Instead of browser user-agent sniffing, you might want to consider using browser feature detection instead to tailor your application to the capabilities of the browser, rather than relying on the userAgent string (which can be customized in most browsers).

Enjoy!

Supposedly, the BCM4328 (rev 02) wireless chipset is supported on Linux, but as of Ubuntu Desktop 11.04 and Linux Mint 11, it doesn’t work reliably. So I turned to the old tried-and-true ndiswrapper to run the BCM4328 Windows driver under Linux.

ndiswrapper conflicts

The process was nowhere near as straightforward as I expected. Ubuntu users since 6.04 have experienced with ndiswrapper conflicts with any of the following kernel modules:

• bcm43xx
• b43
• b43legacy
• ssb
• b44

Resolution

1. Blacklist the conflicting modules:

   echo -e "blacklist bcm43xx\nblacklist b43\nblacklist b43legacy\nblacklist ssb\nblacklist b44" | sudo tee -a /etc/modprobe.d/blacklist.conf

2. Install the Windows driver into ndiswrapper:

   sudo ndiswrapper -i ~/drivers/bcmwl5.inf
   sudo ndiswrapper -l
   sudo ndiswrapper -m
   sudo depmod -a
   sudo modprobe ndiswrapper

3. Configure nm-applet to load ndiswrapper:

   echo -e "\nndiswrapper\n" | sudo tee -a /etc/modules

4. Create a boot script to unload and re-load the conflicting kernel modules in the right order (thanks to levmatta):
   1. Create a file in /etc/init.d/ndiswrapper with this text:

      #! /bin/sh
      ### BEGIN INIT INFO
      # Provides: ndiswrapper
      # Required-Start:
      # Required-Stop:
      # Default-Start: S
      # Default-Stop:
      # Short-Description: enable to load ndiswrapper
      # Description: enable to load ndiswrapper
      ### END INIT INFO
      
      rmmod b44
      rmmod ohci_hcd
      rmmod ssb
      rmmod ndiswrapper
      modprobe ndiswrapper
      modprobe ssb
      modprobe ohci_hcd
      modprobe b44
      
      ############# end file ############

   2. Set the file access permissions:

      sudo chmod 755 /etc/init.d/ndiswrapper

   3. Set this script to run at startup:

      sudo ln -s /etc/ndiswrapper /etc/rc2.d/S99ndiswrapper

5. Reboot.

This worked for me on Linux Mint 11, which is based on Ubuntu 11.04. Your mileage may vary.

References

• Ubuntu ndiswrapper community documentation
• Ubuntu forum topic “Broadcom Wireless Setup for Hardy Ubuntu“
• Fedora forum topic “Network controller: Broadcom Corporation BCM4328 802.11a/b/g/n“
• Ubuntu bug #214917 “Module b44 interfering with ndiswrapper upon startup“
• Ubuntu bug #197558 “ssb module breaks BCM4328 with ndiswrapper (regression from 2.6.24-10)“

The workaround is easy, just set values that should be intentionally empty to boolean FALSE, integer 0, or an empty string.

Primary Key Collision

…happens when records are added on two different servers to the same table and get the same AUTO_INCREMENT value. Fortunately, there is a trivially easy way to prevent this from happening.

auto-increment-increment=N

Adding this to your my.cnf or my.ini file will make AUTO_INCREMENT increment by N rather than by 1. N is the number of replicated servers that are masters.

Combine this setting with…

auto-increment-offset=N

…to ensure that each replicated master uses unique AUTO_INCREMENT values. N should match the server-id setting.

With these two settings in place, your primary keys will never collide.

Example

Let’s suppose you have three replicated master MySQL servers, each with a `comments` table with a last id of 1000. Your servers are configured as follows:

Server 1:

server-id = 1
auto-increment-increment = 3
auto-increment-offset = 1

Server 1 will generate AUTO_INCREMENT values of the form 1 + 3N (4, 7, 10, 13…), where N is a sequential positive integer.

Server 2:

server-id = 2
auto-increment-increment = 3
auto-increment-offset = 2

Server 2 will generate AUTO_INCREMENT values of the form 2 + 3N (5, 8, 11, 14…), where N is a sequential positive integer.

Server 3:

server-id = 3
auto-increment-increment = 3
auto-increment-offset = 3

Server 3 will generate AUTO_INCREMENT values of the form 3 + 3N (6, 9, 12, 15…), where N is a sequential positive integer.

At the same instant, three different visitors to your web application comment. Here’s what happens to the `comments` table:

• Server 1: AUTO_INCREMENT = 1003 (1 + 334 * 3)
• Server 2: AUTO_INCREMENT = 1004 (2 + 334 * 3)
• Server 3: AUTO_INCREMENT = 1005 (3 + 334 * 3)

Let’s suppose that replication stopped before these three new rows could be replicated on the other two servers, and three more visitors leave comments. What IDs will be assigned?

• Server 1: AUTO_INCREMENT = 1006 (1 + 335 * 3)
• Server 2: AUTO_INCREMENT = 1007 (2 + 335 * 3)
• Server 3: AUTO_INCREMENT = 1008 (2 + 335 * 3)

Beautiful!

Heartbeat logging is something that I originally added for Rainmaker, and I finally got around to contributing those modifications, which you can see here on GitHub.

Why log heartbeats in Phirehose?

• To gain assurance that Phirehose is still alive, and actually functioning. In our case, missing tweets means lost money and unhappy clients. We needed to monitor this very closely.
• To enable automatically detecting connection drops and rewinding the count parameter to pick up those tweets, or backfilling them in using the Twitter Search API.
• To collect usage data for reporting purposes.

Usage

To use this, simply declare a heartbeat(array $data) method in your Phirehose child class.

Here is an example:

<?php

// USAGE:
//
//   require_once 'phirehose.php';
//   $dbh = mysql_connect($host, $username, $password);
//   PhirehoseConsumer::Initialize($dbh);
//   PhirehoseConsumer::start();

class PhirehoseConsumer extends Phirehose {

	private static $instance;
	private static $dbh;

	protected $consumer_start_time = 0;
	protected $consumer_uptime = 0;

	public static function Initialize($dbh) {
		if (! self::$instance instanceof self) {
			self::$dbh = $dbh;
			self::$instance = new self ( TWITTER_API_USERNAME, TWITTER_API_PASSWORD, Phirehose::METHOD_FILTER );
		}
	}

	protected static function get_last_heartbeat() {
		$sql = 'SELECT time_stamp FROM stream_log ORDER BY time_stamp DESC LIMIT 1';
		$result = mysql_query ( self::$dbh, $sql );
		$last_heartbeat_ts = mysql_result ( $result, 0, 'time_stamp' );
		if (strtotime ( $last_heartbeat_ts ) === FALSE)
			$last_heartbeat_ts = date ( 'Y-m-d H:i:s' ); // default to now
		return $last_heartbeat_ts;
	}

	protected static function get_missed_count() {

		// get timestamp of the most recent intake script heartbeat
		$last_heartbeat_ts = self::get_last_heartbeat ();

		// how long since we were last running?
		$downtime = ( int ) (time () - strtotime ( $last_heartbeat_ts ));

		// Based on the past average, how many tweets did we probably miss?
		//
		// This calculation is based on the statusRate averaged over a period of
		// time not greater than $downtime, and multiplied by a 1.5x fudge factor.
		$sql = <<<SQL
SELECT CEIL(1.5 * AVG(statusRate) * $downtime) AS count
FROM stream_log WHERE
    (UNIX_TIMESTAMP('$last_heartbeat_ts') - UNIX_TIMESTAMP(time_stamp) > 0) AND
    (UNIX_TIMESTAMP('$last_heartbeat_ts') - UNIX_TIMESTAMP(time_stamp) > 0) <= $downtime
SQL;
		$result = mysql_query ( self::$dbh, $sql );
		$count = mysql_result ( $result, 0, 'count' );

		return ($count === FALSE) ? 0 : ( int ) $count;
	}

	public static function start() {
		// get timestamp of the most recent heartbeat
		$last_heartbeat_ts = self::get_last_heartbeat ();

		// Estimate how many tweets were missed, and rewind.
		//
		// Note that if you're using the filter streaming method, this will fail with the following error:
		//   "The Streaming API count parameter is not allowed in role statusDefaultFiltered."
		$count = self::get_missed_count ();
		if ($count) {
			self::$instance->log ( "Using count: $count" );
			self::$instance->setCount ( $count );
		}

		// run backfill script in background - uses Twitter Search API
		self::$instance->log ( "Backfilling from $last_heartbeat_ts" );
		passthru ( "backfill.php '$last_heartbeat_ts' >/dev/null &" );

		self::$instance->checkFilterPredicates ();
		self::$instance->consume ();
	}

	public function enqueueStatus($status) {
		// do something with your tweet
		return TRUE;
	}

	public function heartbeat(array $data) {
		$sql = <<<SQL
INSERT INTO stream_log SET
    time_stamp = CURRENT_TIMESTAMP,
    elapsed = $data[elapsed],
    statusRate = $data[statusRate],
    statusCount = $data[statusCount],
    enqueueSpent = $data[enqueueSpent],
    enqueueSpentAvg = $data[enqueueSpentAvg],
    filterCheckCount = $data[filterCheckCount],
    filterCheckSpent = $data[filterCheckSpent],
    idlePeriod = $data[idlePeriod],
    maxIdlePeriod = $data[maxIdlePeriod]
SQL;
		mysql_query ( $dbh, $sql );
	}

	protected function checkFilterPredicates() {
		// useful for debugging
		$this->consumer_uptime = time () - $this->consumer_start_time;
		$this->log ( sprintf ( 'Uptime: %s, memory usage: %skb', $this->consumer_uptime, number_format ( memory_get_usage () / 1024, 0 ) ) );

		// update filter predicates...
	}

	protected function connect() {
		$this->consumer_start_time = time ();
		parent::connect ();
	}

}

I have spent the last 8 hours trying to figure out why Microsoft’s signtool.exe code signing utility refuses to work when called from PHP’s system() or shell_exec() functions on my WAMP server:

C:\build> "C:\Program Files\InstallMate 7\Tools\signtool.exe" sign /v /f codesignedcert.pfx Setup.exe 2>&1

The following certificate was selected:
    Issued to: <redacted>.
    Issued by: UTN-USERFirst-Object
    Expires:   5/12/2012 6:59:59 PM
    SHA1 hash: <redacted>

Done Adding Additional Store

Attempting to sign: C:\build\Setup.exe

Number of files successfully Signed: 0
Number of warnings: 0
Number of errors: 1

SignTool Error: ISignedCode::Sign returned error: 0x80090010

	Access denied.

SignTool Error: An error occurred while attempting to sign: C:\build\Setup.exe

Note: the 2>&1 at the end of the signtool call is essential if you want to capture error messages which are emitted to STDERR instead of STDOUT. Yes, I lost an hour or two just on that.

Dead ends

• Windows 7 apparently sets the read-only attribute on all files, and it isn’t easy to turn that attribute off. But since other file operations worked from PHP, this wasn’t the issue.
• Prefacing the signtool call with CMD /C didn’t help.
• Setting full control file permissions on the C:\build folder for Guest, SYSTEM, and any other user account I could think of didn’t help either.
• Wrapping signtool in a batch file was an exercise in futility.

The maddeningly frustrating thing was that signtool worked great when called from the command line — just not from PHP!

An aha! moment

The issue turned out to be pretty stupid, as they usually do. I merely had to change the account that Apache was running as to that of a normal user, instead of the default local system account.

Size, Time, and Memory

There are three types of limits that affect file uploads, and the weakest link in the chain is your effective limit.

If your size limit is set to 3gb, but your time limit does not allow for the time required to upload that much data, you’ll still be unable to upload those large files. Likewise, the ability to upload does no good if you do not have enough memory to process the file that was uploaded.

Assumptions

This post assumes an 8MB upload limit (8mb x 1024kb x 1024 bytes = 8388608). You will want to adjust this number up or down according to your needs.

Oddly, although 8mb is the default value for PHP’s upload_max_filesize setting, some of the other default settings are much lower (2mb, or in some cases, only 100k).

PHP limits

upload_max_filesize = 8388608
post_max_size = 8388608
max_input_time = 60

Depending on what you’re doing with the uploaded files, you may also need to increase your memory limit:

memory_limit = 64MB

Apache limits

If LimitRequestBody is set to something non-zero, you may need to increase its value in your Apache httpd.conf file or .htaccess file:

LimitRequestBody 8388608

If you are using mod_fcgid (required to run the latest PHP 5.3 VC9 NTS build for Windows), then you need to set the value of FcgidMaxRequestLen, which defaults to 100k if it is not set. (Note that some systems may put mod_fcgid settings in a file separate from the main httpd.conf file).

FcgidMaxRequestLen 8388608
FcgidIOTimeout 60

Happy uploading!

Every now and then, a message comes through that relates to my personal experience or knowledge which has not yet been answered, and I will answer it.

When you contribute to an open-source community, it does two things: it builds your reputation within the community, and it increases the likelihood of getting quality help yourself when you need it. There’s also the bonus of promoting your company if you use an email signature. This has SEO value since most of the time these messages wind up in search engines.

Besides chromium-extensions, I am also subscribed to phirehose-users (my participation here earned commit access as an official contributor), twitter-development-talk, and some local PHP user groups lists.

I wish this kind of plugged-in-and-giving-back mentality were more prevalent. If you use an open-source project or technology, subscribe to the mailing list (or forum), and don’t just lurk. Answer questions, and where appropriate, share your code or your experiences.

Day two at PHPCon in Nashville, TN was packed with lots of information that frankly, I’m still digesting. It was well worth the trip and ended much too quickly!

Download my notes (PDF)

Morning Keynote

In his “brain dump,” Rasmus Lerdorf shared a collection of unrelated but very useful tips and observations about PHP.

• PHP is the bottleneck, there is no significant difference between nginx/lighthttpd/apache
• Error handling is not optimized in PHP because it should be an infrequent event. Set error_reporting = -1
• Insufficient realpath_cache_size in PHP 5.2 can cause excessive filesystem STATs
• Use gearman for out-of-band processing. Threads aren’t needed in PHP.
• Don’t overload apache (8 core CPU = 25-30 apache clients; never more than 50)
• Deploy processes should be atomic and robust (can use Capistrano or Rasmus’ own weploy script)
• Node.js-style event programming is fast and easy (see http://php.net/libevent)

Slides: http://talks.php.net/show/phpcon2011 (ya gotta love the homegrown web-based presentation system!)

The Original Hypertext Preprocessor

Drew McLellan‘s presentation was particularly relevant for me in my role as CTO at Company52, and I consider it one of the best presentations at PHPCon. Drew’s goal was not to market Perch (although he did an awesome job of it without even trying), but rather to share his philosophy of what really great client support is all about, and how it has impacted his work.

• Throwing new features at a problem often doesn’t solve it. Functionality is not enough.
• Find ways to reduce support requests.
• Every support request should be unique (no FAQs).
• Fix areas of confusion rapidly.
• Support your own software – programmers should see issues firsthand.
• It’s OK to be opinionated (“WYSIWYG is evil”), but don’t be dictatorial. It’s not our place to tell people how to work.
• Help customers look good in front of their clients.
• Accept when users are having problems.
• Really great developers solve problems. Excuses simply are not helpful.

The WonderProxy story

Paul Reinheimer shared the story of how he built (and self-funded) WonderProxy, born out of a personal need to test applications that use IP-based geolocation.

• Mistakes – “crouch and hope you don’t get hit”
  • No account de-activation
  • NIH – wrote paypal IPN code instead of re-using own code
  • Mixing Linux distros
  • Server account renewals
  • Afraid to look at profitability numbers
• Old strategy: blog about problems we encounter – competitors find posts
• New strategy: blog about problems customers have – bring customers instead of competitors

Is it Handmade Code If You Use Power Tools?

Laura Beth Denker of Etsy shared an overview of their continuous integration processes, and how it has greatly improved both confidence and deployment speed. True to Etsy style, Laura came dressed in a handmade outfit from a Nashville-based Etsy vendor, earning a “too much swag” tweet from one listener!

• NEED CONFIDENCE in your code
• Effective testing strategies include functional (human) testing, integration testing (database), and unit testing (foundation)
• Don’t use random data in unit tests
• Test each case in control structures
• Use DBUnit for testing database interaction
• Tests should run rapidly
• Group unit tests and target test groups to run
  • caches
  • databases
  • network tests (third-party APIs)
  • sleep
  • time
  • smoke, curl, regex
  • flaky

What happened to Unicode in PHP

Andrei Zmievski’s talk was a frank de-briefing of the failed attempt to bring native Unicode support to PHP6. Although this story is a rather personal one for Andrei, he was honest and incorporated a few surprisingly hilarious bits of humor. The conclusion: native Unicode support will only come to PHP if and when the community wants it — and is willing to put noses to the grindstone. The task is simply too big for his elite band of 10 (including Rasmus himself). Most of the content was historical in nature, but there were a few nice tidbits of information.

• Complete I18N is more than language stuff:
  • Character set
  • Date/time formats
  • Currency formats
  • Collation (sorting, contractions – thanks to Andrei for finally helping me to understand what a “collation” is)
• pecl/intl has some useful classes left over from the PHP6 unicode project (Collator, NumberFormatter, MessageFormatter)

Closing Keynote

Terry Chay’s closing keynote wove a common thread through all of the presentations given at PHPCon, along with a heaping helping of humor (seedy at times). My favorite part were the Chayisms: http://phpdoc.info/chayism/

Download my notes (PDF)

Web Services

This talk was given by Lorna Jane Mitchell, whose totally awesome British accent I could listen to all day. I consider myself no novice on consuming web services, but being a relative newcomer to building web services, I got a real education on how to do it right.

Key takeaways:

• Use curl, it eliminates points of failure for more accurate testing. Lorna rejects any bug ticket that does not come with a curl test case, which reduced support requests by 50%!
• Every web service should have a heartbeat method that echos the variables you pass to it.
• Every web service should have documentation, (real) examples, and a support mechanism. If you’re not going to do this, don’t bother building a web service, ’cause nobody’s gonna use it.
• Utilize the HTTP protocol as fully as possible, including HTTP headers (Accept, Content-Type, User-Agent), verbs (GET [read], POST [create], PUT [update], DELETE [delete]), and status codes (HTTP 200, 201, 301, 302, 400, 401, 403, 404, and 500).
• Give consumers a choice of formats. text/html is useful for debugging purposes.
• Parse the Http-Accept header and deliver content in first format listed that you support.
• Don’t confuse HTTP 401 with HTTP 403 (“I don’t know who you are, so I’m denying access” vs “I know who you are, and you don’t have permission”).
• pecl_http is an easier way to access web services than curl.
• Error handling defines API quality. Provide complete, useful, and consistent error messages in the expected response format.

Link bundle: http://bit.ly/bundles/lornajane/2

Frontend Caching

This talk was given by Helgi Þorbjörnsson (I will not even attempt his Icelandic surname). Helgi is a long-time PEAR contributor and experienced front-end developer. Key takeaways:

• 80% of response time is spent downloading resources.
• Don’t abuse cookies. Large cookies hurt performance because of slow upload speeds, and because they are sent with every request. When you use cookies, be sure to set an expiration date and limit them to only the domains they are needed on.
• Browsers have per-domain concurrent download limits. You can spread static assets across 3-4 multiple subdomains as a workaround.
• Combine files judiciously. Be aware of the trade-off between fewer server requests and larger file size.
• Load above the fold first.
• Minify Javascript and CSS, preferably at build time.
• Use gzip compressiononly for text-based content.
• Save HTTP 404 bandwidth by ensuring that you have a robots.txt file and a favicon.
• Compress images more (Photoshop doesn’t cut it; better alternatives include pngcrush and jpegtran).
• Test with slower connections (tread the user’s path).

Being a non-standard event originally invented by Microsoft back in the IE4 days, window.onbeforeunload has some real quirks, although thankfully every major modern browser does support it.

jQuery Doesn’t Help

Prior to jQuery 4, you couldn’t even bind to $(window).bind('beforeunload') due to a bug that has been fixed.

However, this isn’t your average Javascript event. window.onbeforeunload pops up a native dialog box that provides very little opportunity for customization beyond the text that is displayed to the user. There is no known way to disable this native dialog box and prevent normal behavior.

Tapping into jQuery’s $(window).unload() event doesn’t allow you to prevent the page from being unloaded, and I couldn’t get $(window).bind('beforeunload') to work at all in Firefox 3.6.

The Right Way

The right way turned out to be quite easy using native Javascript code (thanks to the Mozilla Doc Center for the working solution).

For IE and FF < 4, set window.event.returnValue to the string you wish to display, and then return it for Safari (use null instead to allow normal behavior):

window.onbeforeunload = function (e) {
    var e = e || window.event;

    // For IE and Firefox prior to version 4
    if (e) {
        e.returnValue = 'Any string';
    }

    // For Safari
    return 'Any string';
};

If all you want to do is see if you are running PHP 5.3+, then just check for the existence of the array_replace() function, which was added in PHP 5.3:

<?php
if(function_exists('array_replace')) {
    // running PHP 5.3+
} else {
    // running something prior to PHP 5.3
}
?>

The “right way”

The version_compare() method can be used in conjunction with the PHP_VERSION constant to compare standardized PHP version strings. It also makes for more readable code:

if(version_compare(PHP_VERSION, '5.3.0') >= 0) {
    echo 'I am at least PHP version 5.3.0, my version: ' . PHP_VERSION . "\n";
}

Version constants

If you need to get down to the nitty gritty specifics of the PHP version you are running, use the PHP_VERSION_ID, PHP_MAJOR_VERSION, PHP_MINOR_VERSION, and PHP_RELEASE_VERSION constants, which were added in PHP 5.2.7. To ensure backward compatibility, the following code snippet from php.net will define these constants if they are undefined in your PHP version:

<?php
// PHP_VERSION_ID is available as of PHP 5.2.7, if our
// version is lower than that, then emulate it
if (!defined('PHP_VERSION_ID')) {
    $version = explode('.', PHP_VERSION);
    define('PHP_VERSION_ID', ($version[0] * 10000 + $version[1] * 100 + $version[2]));
}

// PHP_VERSION_ID is defined as a number, where the higher the number
// is, the newer a PHP version is used. It's defined as used in the above
// expression:
//
// $version_id = $major_version * 10000 + $minor_version * 100 + $release_version;
//
// Now with PHP_VERSION_ID we can check for features this PHP version
// may have, this doesn't require to use version_compare() everytime
// you check if the current PHP version may not support a feature.
//
// For example, we may here define the PHP_VERSION_* constants thats
// not available in versions prior to 5.2.7

if (PHP_VERSION_ID < 50207) {
    define('PHP_MAJOR_VERSION',   $version[0]);
    define('PHP_MINOR_VERSION',   $version[1]);
    define('PHP_RELEASE_VERSION', $version[2]);
    // and so on, ...
}
?>

Summary

1. Make sure the computer sending the email has a Reverse PTR record. Your ISP has to do it, not your DNS provider or web host.
2. Sign your messages using DomainKeys Identified Mail. Requires DNS and code changes.
3. Set up a SenderID DNS record. Far less critical than the first two, but still nice to have.

Did it work?

1. Send a message to a GMail account–they provide excellent diagnostic headers. Look for Received-SPF and Authentication-Results.
2. Use the Port25 diagnostic service (check-auth@verifier.port25.com). You can ignore a DomainKeys check fail if the DKIM check passes.