Fixing “peer closed connection” error with InstantSSL / Comodo certificates on nginx

If you are setting this error in your nginx logs after installing a InstantSSL / Comodo SSL certificate:

“peer closed connection in SSL handshake while SSL handshaking”

here is the fix:

concatenate the .bundle file Comodo sends you with your site cert, with the bundle coming *after* the site crt file into a new file and use that new file in your nginx conf file. The command line should look like this:

cat crt_file_from_comodo.crt bundle_file_from_comodo.bundle > site.crt

I had concatenated them, but in the wrong order and got the cyptic message above. I hope this helps if you have the same problem.

Notepad++ plus XDebug plus Chrome equals happiness

I posted this over at TechZingLive but I thought I’d repost it here in case anyone else needs the info:

You can setup Notepad++ with PHP debugging in a few minutes:

1) Install the XDebug extension –

2) Set the xdebug options in your php.ini file (with the two path changes made) and restart Apache

xdebug.profiler_enable = off
xdebug.profiler_enable_trigger = on
xdebug.profiler_output_name = cachegrind.out.%t.%p
xdebug.profiler_output_dir = “c:/wamp/tmp” <– change this path

xdebug.remote_enable = on
xdebug.remote_log=”c:/wamp/tmp/xdebug/xdebug_remot.log” <– change this page

3) Install the Notepad++ DGBp plugin (via Notepad++ Plugins -> Plugin Manager dialog)

4) Config DBGp (via Plugins -> DBBp -> Config) and add a remote server at using “xdebug” as the IDE KEY (or whatever value you choose for “xdebug.idekey” in php.ini). You can ignore the remote and local path options – just enter the path to your local code if you can.

5) Install the Xdebug Chrome helper –

6) Config Xdebug Chrome helper via Tools -> Extentions -> XDebug helper -> Options link. You need to enter your local dev domain in the “Domains” list. The helper uses this list to know when to show its little bug icon in the url bar.

To debug PHP you would then do the following:

1) In Notepad++ choose Plugins -> DGBp -> Debugger

2) Browse to where you want to set a breakpoint, put your cursor there and click on the red stop sign looking icon in the DGBp panel. Make sure the “Turn OFF” button is shown in the panel (bad UI).

3) In Chrome browser go to your local site and you should see a black and white bug on the far right of your url. You can click on that bug to toggle between debug, profile and off. Toggle to the green bug (debug) and reload the page. You’ll break at the breakpoint.

Note – you can also profile pages this way – it generates a file that webcachegrind can read:

knockout.js binding utility module

Here is a short module to remove some of the boilerplate when creating Knockout.js bindings:

function KOBindingUtils() {

	return {
		createInitOnlyBinding: createInitOnlyBinding,
		createUpdateOnlyBinding: createUpdateOnlyBinding,
		createBinding: createBinding

	function createInitOnlyBinding(callback) {
		return {
			init: createBindingFunction(callback)
	function createUpdateOnlyBinding(callback) {
		return {
			update: createBindingFunction(callback)
	function createBinding(initCallback, updateCallback) {
		return {
			init: createBindingFunction(initCallback),
			update: createBindingFunction(updateCallback)
	function createBindingFunction(callback) {
		return function(element, valueAccessor, allBindingsAccessor, context) {
			var value = valueAccessor(),
				valueUnwrapped = ko.utils.unwrapObservable(value),
				allBindings = allBindingsAccessor(),
				$element = $(element);
			callback($element, valueUnwrapped, allBindings, context);

Here is how to use it to create a simple binding to show an alert dialog:

ko.bindingHandlers.alert = koBindingUtils.createInitOnlyBinding(function ($element, valueUnwrapped, allBindings, context) {
	$element.css("cursor", "pointer").click(function () {

<span data-bind="alert: 'Hello, world!'">Click here to test ...</span>

NOTE: In case it isn’t obvious you also have to have jQuery loaded. If you don’t use jQuery just remove the “$element = $(element);” line in createBindingFunction() and pass the raw dom element to the callback.

Using knockout.js with the module pattern

The tutorials at are awesome but the object literal style they are written in brings me back to nightmares of large Javascript applications I wrote before I read Douglas Crockfords book, Javascript: The Good Parts, and became a convert to the module pattern that he espouses in the book.

Part of my conversion to the module pattern was that allows for information hiding but probably a bigger part was just the style of the code. Over the years I learned to hate the multiple hundred line object definitions that were brittle because I left out a comma after a function definition or were crufty because I couldn’t reference the enclosing object. If you have been there you know what I’m talking about.

As I went through the tutorials I started hoping beyond hope that I could get the awesomeness of knockout.js but lose the horror of object literal functions. Once I was through all of them I started playing around and decided to rewrite the end result of the first tutorial using the module pattern. In case you haven’t gone through the tutorial first (you really should) here is the final template from the first tutorial:

Final template

<p>First name: <span data-bind="text: firstName"></span></p>
<p>Last name: <span data-bind="text: lastName"></span></p>

<p>First name: <input data-bind="value: firstName" /></p>
<p>Last name: <input data-bind="value: lastName" /></p>

<p>Full name: <span data-bind="text: fullName"></span></p>

<button data-bind="click: capitalizeLastName">Go caps</button>

and here is the final code using their object literal style:

Final code using an object literal style

var viewModel = {
    firstName: ko.observable("Bert"),
    lastName: ko.observable("Bertington"), 

    capitalizeLastName: function() {
        var currentVal = this.lastName();

viewModel.fullName = ko.dependentObservable(function() {
    return this.firstName() + " " + this.lastName();
}, viewModel);


Maybe its just a matter of style, and you might not have a problem with the above code, but having to define the dependent observer outside of the object literal because it can’t reference the object bugs me, as does having to expend mental energy to make sure this is really the viewModel object because its being passed as the second parameter in the ko.dependentObservable function call.

Converting the code to the module pattern lets me define both the observables and the dependent observables in the same function and use a private function to implement behaviors of the view module. It also allows me to encapsulate the view model into a function so I can move it to an external include file and call it against an arbitrary person object. For a simple example like this it seems like overkill but when you start building large single page Javascript applications encapsulating data and methods is a guard against insanity. With all that in mind here is the code converted to the module pattern:

Final code using the Module Pattern

var PersonViewModel = function (person) {
	var firstName = ko.observable(person.firstName || ""), 
		lastName = ko.observable(person.lastName || ""),
		fullName = ko.dependentObservable(getFullName);

	return {
		firstName: firstName,
		lastName: lastName,
		fullName: fullName,
		capitalizeLastName: capitalizeLastName
	function getFullName() {
		return firstName() + " " + lastName()
	function capitalizeLastName() {

ko.applyBindings(PersonViewModel({"firstName": "Doug", "lastName": "Martin"}));

TL/DR: knockout.js is awesome. Doug doesn’t like object literal function construction. The module pattern works fine with knockout.js.

Using a Git pre-commit hook to do PHP syntax checking

Want to make sure you never check in code with PHP syntax errors? I know that you never make mistakes but I do and the Git pre-commit script shown below is a great way to guard against you wearing the “I broke the site” hat for the rest of the day.

First, a bit of background. Git runs a series of external hook scripts during the commit process. The first script is the “pre-commit” hook which can terminate the commit process by returning a non-zero return code. The output of the script is then shown to the user so they can take the necessary steps to allow the pre-commit script to return that its ok to continue. We are going to use this hook to run a syntax check over all the code using PHP’s built-in command line lint command.

Here is the pre-commit script:

# NOTE: change the path above to point to your PHP executable
# in *nix its usually /usr/bin/php

$output = array();
exec("find {$path} -name '*.php' | xargs -n1 php -l | grep -v 'No syntax errors detected'", $output);
exit(count($output) > 0 ? 1 : 0);

And here is how you use it:

  1. Save the script above in your .git/hooks/ directory with the filename of “pre-commit” (no extension) with the $path variable set to the root directory of your PHP files (if you are hosting Git under *nix you should set the permissions on the script so that you can execute it).
  2. Make a trivial breaking change to your code (like removing a semi-colon somewhere).
  3. Using the command line or your favorite Git gui commit the change.
  4. Wait a bit while the files are linted. You should see a message telling you which file and line contains the error you just introduced and the commit should fail.
  5. Fix your trivial breaking change and try the commit again. It should work this time.

One note: if you have a HUGE codebase you should switch to using this script which only performs the lint check on the files that are changing in the commit. I do most of my PHP development on a Window’s PC using a combination of Wamp and msysGit and that script caused a cascade of opening and closing cmd.exe windows to pop up which I found rather annoying. The script above only causes a single cmd.exe window to pop up during the lint check.

A simple socket logger using PHP & Python

I’m working on a project now that uses dynamically generated Javascript created on the backend in PHP. One of the challenges is how to easily add debug statements in the backend without corrupting the generated Javascript that is returned. The answer: log the debug statements to a special debug server via a socket.

To keep things simple I built the debug server itself in Python. While the same server could be built in PHP, Python’s SocketServer module is pretty hard to beat for creating simple servers as you can see from the code below.

Here is the PHP logging class:

class SocketLogger {

	const HOST = "";
	const PORT = 10371;
	const TIMEOUT = 1;
	const FORCE = true;

	public static $enabled = true;
	private static $abortConnect = false;
	private static $socket = null;
	public static function Log($html, $force=false) {
		// skip if disabled and not forced (return true as logging didn't fail)
		if (!self::$enabled && !$force)
			return true;
		// connect on demand to the html socket server
		if (!self::$socket) {
			// see if we have failed on previous connects
			if (self::$abortConnect) {
				return false;
			// open the socket 
			self::$socket = @fsockopen(self::HOST, self::PORT, $errno, $errstr, self::TIMEOUT);
			if (!self::$socket) {
				self::$abortConnect = true;
				return false;
		// send the html
		$bytesWritten = fwrite(self::$socket, $html);
		return $bytesWritten == strlen($html);

and here is the server in Python:

import SocketServer

HOST = ""
PORT = 10371

class SocketLoggerRequestHandler(SocketServer.BaseRequestHandler):

	# echo out all the data we receive to the console
    def handle(self):
		while 1:
			data = self.request.recv(1024)
			print data
			if len(data) == 0:

# start the server		
if __name__ == '__main__':
    address = (HOST, PORT)
    server = SocketServer.TCPServer(address, SocketLoggerRequestHandler)

To use it just run the python script and with the PHP logging class included call it using:

SocketLogger::Log("Text to log");

You can then keep the logging calls in place and later globally disable them using:

SocketLogger::$enabled = false;

and if you do disable logging globally you can force the logging to happen by passing FORCE to Log():

SocketLogger::Log("Text to log", SocketLogger::FORCE);

Building a DSL in PHP, Part 2: DSL Syntax

In the first post I outlined the steps to build a multiple choice test DSL in PHP. In this post I’ll describe the syntax for it.

Design for the end users

For the purposes of this series lets pretend we are building this DSL for a web based multiple choice test management system. The end users of the DSL are overwhelmingly are non-technical people. With this in mind we need to create a DSL syntax that reads “naturally” and avoid “programmery” things like statement terminators, keywords and special operators.

Our DSL needs to allow users to create a series of questions with multiple choice answers attached to each question, with one or more of the answers marked as the correct answer. The goal of the DSL is to read naturally so it will be flexible in what input it accepts and use the end of line as a statement terminator instead of something like a semi-colon. Since textboxes in web forms handle text wrapping well we don’t need to add a confusing line continuation operator and we’ll ignore empty lines and automatically trim spaces from non-empty lines so that the end-user can format the questions as they see fit without worrying about how the text flows when used.

Sample Input

Let’s jump in and create some sample input. It will form the nucleus of our test suite as we build out the steps in the pipeline in future posts.

What is 2+2?
  1. 2
  *2. 4
  3. 6
Is the circumference of a circle always greater than its diameter?
#* yes
# no

Which of the following is not a color?
 a: Red
 b. Green
 c) Blue
 d*] Duck
 e> Burnt Umber
 f: Cyan
Can a woodchuck chuck wood?
- yes
*- no

Looks pretty natural right? Questions are on their own line without a preceding label and answers are labelled with either a hash, dash or number or letter followed by one of delimiter keys that might make sense to the end-user. The correct answer is marked with an asterix somewhere in its label and you can intermix label delimiters if you want to (although it does look a bit ugly doesn’t it?). Finally you’ll also notice that while the user can use empty lines to separate questions none are actually needed.

From Sample Input to a Formal Grammar

Let’s take the sample input above and build a more formal grammar in a half EBNF, half regex format. We don’t have to be too formal about it since we will be using it as a guide and not as formal input into a compiler generator.

First, a test must have at least one question with answers. We read this as “tests produce one or more question and answer productions”:

<test> => <question_and_answers>+

Second, each question should have at least two answers and we should ignore empty lines before questions and before and between answers:

<question_and_answers> => <empty_line>*<question>(<empty_line>*<answer>){2,}

Third, empty lines are zero or more spaces or tabs followed by the end of line character or end of file marker:

<empty_line> => s*(<EOL>|<EOF>)

Fourth, questions are the full text of a line, trimmed:

<question> => s*<question_text>s*<EOL>

And fifth, answers are trimmed and start with a hash, minus, plus or number or letter followed by a delimiter with the asterix marker for the correct answer appearing before, within or directly after the label.

<answer> => s*"*"?s*((d+|[a-zA-Z])"*"?[":"|"."|")"|"]"|">"|" "]|"#"|"-"|"+")s*"*"?<answer_text>s*(<EOL>|<EOF>)

Here is full grammar:

<test> => <question_and_answers>+
<question_and_answers> => <empty_line>*<question>(<empty_line>*<answer>){2,}
<empty_line> => s*(<EOL>|<EOF>)
<question> => s*<question_text>s*<EOL>
<answer> => s*"*"?s*((d+|[a-zA-Z])"*"?[":"|"."|")"|"]"|">"|" "]|"#"|"-"|"+")s*"*"?<answer_text>s*(<EOL>|<EOF>)

In the future parsing post we’ll translate this grammar directly to PHP using a recursive descent parser. But first we’ll need to tokenize it for the parser.

Next: Part 2 – Tokenizing the DSL (coming soon).

Adding usernames to your Apache access log with PHP using apache_note()

Here is a quick little tip that allows you to embed usernames from your webapp into your Apache access log using the little known apache_note() function. This will allow you to easily see who is requesting php files on your server using your webapp’s user database. Since it requires PHP to run during the request it won’t work for non-php resources like images or javascript files.

Apache Config Changes

The common log format already provides a place for usernames, but it’s meant for usernames in the authentication header sent after you login via your browser’s basic authentication mechanism (usually a username/password dialog popup). We will use that same spot in the log for the usernames from our webapp so that any existing log parser you have operating on your logs won’t need any changes.

First you need to either edit or create a new named log format in Apache. I’d be safe and just create a new one instead of editing the existing “common” log format. To do that open your http.conf file and search for a line that looks like this:

LogFormat "%h %l %u %t "%r" %>s %b" common

and then copy this next line and place it after the common format:

LogFormat "%h %l %{username}n %t "%r" %>s %b" withusername

Once that is done search for your most local CustomLog directive. The default Apache config places this within the check for the log_config_module in the server config but it is also available as an option in the virtual host so its best to double check to make sure it is not being overridden in the virtual host.

Once you have found the most local CustomLog directive either comment it out and replace it with the following or use the following and pick a seperate log path. If you keep both CustomLogs in the config you’ll double the space used for logging but in today’s cheap disk space world that shouldn’t be a problem.

Here is the line to replace or add:

CustomLog "/path/to/your/logfile.log" withusername

Code to add to your PHP webapp

With the Apache config changes in place and saved add the following code after you have authenticated the user in the request (assuming $user contains your user object):

apache_note("username", $user->username);

That’s it! The apache_note() function allows you to access the internal table that Apache uses for modules to communicate with each other. We are adding our own note named “username” and then the log module is looking it up using the %{username}n format directive.

Using it

Restart Apache and then load a page in your webapp. If you are logged in you should see your username now in the logs, but if not, and the username note doesn’t exist, the log module will output “-” in its place, as it does when the username from the basic authentication header is missing.

Here is an example of a request without a username: - - [21/Oct/2010:07:02:42 -0400] "GET /" 200 1337	

and here is what a request would look like if you are logged in as randomuser: - randomuser [21/Oct/2010:07:02:44 -0400] "GET /" 200 1337