Apache Config Files and Installing PHP extensions in OSX Mavericks

If you've just upgraded to Mavericks and found your local web stack doesn't work any more it's probably because all of your apache conf files have been moved during the upgrade.

The best option here is to copy the changes you made to the original conf files to the new ones. This goes for any conf files you had modified e.g. /etc/apache2/extra/httpd-vhosts.conf or httpd-ssl.conf.

You could just replace the new ones with the originals, but as I'm not sure if Apple have changed the versions of extensions etc it's probably safer just to copy the options over that you need.

You'll also see that Mavericks comes with an updated version of PHP.

php-config --version
5.4.17

If you were using the default installed version previously any additional extensions you had installed will need to be re-installed. For example I was missing the PhpRedis and igbinary extensions.

When I first tried to install the extensions I got the error message:

php.h not found

After doing some searching on this problem I found that Mavericks does not have the /usr/include folder anymore. There were a few sources suggesting creating a symbolic link to the include folder in the XCode Library folder (assuming Xcode was installed), but the actual solution that worked for me was to run the following command at the terminal:

xcode-select --install

More info on xcode-select can be found by typing "man xcode-select" in the terminal or on the Apple developer website - which I found on stackoverflow.

After running this command the two extensions installed without a problem. Job done!

Just in case this helps someone, here's the info on a stupid mistake I made; After running the above I was still having problems getting Redis to load, the follow error was thrown on Apache startup.

PHP Startup: redis: Unable to initialise module\nModule compiled with module API=20090626\nPHP compiled with module API=20100525\nThese options need to match\n in Unknown on line 0

I thought perhaps I'd used the previous version of phpize, but when I checked this was not the case:

phpize -v
PHP Api Version:         20100412
Zend Module Api No:      20100525
Zend Extension Api No:   220100525

Annoyingly this turned out to be my mistake. I re-downloaded the extensions, but neglected to notice my Downloads folder still contained the older versions from when I installed them the first time.

I'm assuming that if you run phpize on a directory for which it has already been ran, nothing will be changed because when I ran make && make install I installed the extensions compiled for the previous version of PHP.

Hopefully this helps someone waste less time than I just have....

Loose Coupling Between Node.js modules - Communicating Between Modules

TL;DR

Here is how you can use the EventEmitter class in Node as a shared message bus to allow for loose coupling between modules.

Shared Event Emitter to be used as message bus - sharedEventEmitter.js

var events = require('events');
var eventEmitter = new events.EventEmitter();
module.exports = eventEmitter; 
//The eventEmitter will be used as a singleton

Module to publish events - publisher.js

var sharedEvents = require('../sharedEventEmitter.js'); 

var worker = function() {
 var doWork = function() {
  var result = ...
  sharedEvents.emit('work done', result);
 };
};

module.exports = worker; 

Module to listen for events - listener.js

var sharedEvents = require('../sharedEventEmitter.js'); 

sharedEvents.on('work done', result) {
 //do stuff with result
}

Module to tie everything together

var listener = require('../listener.js'); 
var publisher = require('../publisher.js'); 

publisher.doWork();

Why would you want to do this?

If you are working on a big app or communicating between Node processes this solution won't scale very well. If you need more flexibility look into something like AMQP or the available Node.js modules for message queuing.

Having said that, for a lot of projects that is overkill. Maybe you're working on a small app, but you still want to write loosely coupled easy to test code. I'll use a fairly contrived example to show a situation where this could be used.

Consider a basic online store and imagine that two related modules exist.

One module parses a data feed of product data from a supplier. This module updates the database with stock levels etc.

Another module alerts a user when a product they have ordered becomes available.

The module that parses the data should not have knowledge of user accounts. This module has one purpose, parsing the feed. And the module that handles alerting users should not interact with the parsing code.

When I say "should not" I'm referring to best practices, obviously you can, but you'll end up with code that is hard to test and maintain. For example if we were to call a method from the parsing code, something like updateUsersNowThatProductsInStock we are tying the functionality of the parsing code to the user alerting code. If we then want to use that parsing code somewhere else we'll more than likely have to delete the user alerting section of code. Also testing the parsing code would require mocking or stubbing out that method - it's just more work.

So how do we know when to send alerts? We don't want to have to poll the database as that uses unnecessary resources - which is definitely a concern if you pay for computing resources on something like heroku.

One way to achieve this is to use the EventEmitter class in Node.js as a message bus.

First create a module that exports an instance of an EventEmitter. We will use this as a singleton. Each module will 'require' the shared EventEmitter.

It Node.js the idiomatic way to implement an EventEmitter is for the object emitting events to subclass the EventEmitter. In this case we don't want to do that as the module listening for those events would then have a direct dependency on the Emitter, which is exactly what we're trying to avoid.

We are essentially implementing a very basic version of the Publish Subscribe paradigm, but just between modules.

Once your modules are using the shared event emitter you can then interact with them via a third module.

You should bear in mind that the module publishing the events does not emit any events until a function is explicitly called. This is important because you need to ensure that your event listener is attached before you fire your event. In the example above the event listener is attached within the root module scope, so just 'requiring' this module will set up the listener.

If you wanted to do some work whenever your publisher module was imported you would need to make sure that you 'required' the modules in a specific order, listener then publisher.

You may question how this is any different to just "requiring" the two modules within the App.js/Server.js file, why the third module? In this case it is solely to be explicit about the interaction between the two modules, which would likely get obscured among the many other modules you'd be 'requiring' in the main app file. It basically allows anyone looking at the code to easily see that the modules interact in some way.

Each module carries out a completely separate task, but at a higher level of abstraction they could be seen as one logical unit. Creating a third module makes the code easier to understand and doesn't affect the testability as each module can still be tested independently.

NOTE This approach will not work easily if the events need to go in both directions as you'd need to be very careful about the order of declaring emitters and listeners, which is not ideal between two files. If you have that requirement look into message queuing.