NSmith Code Stuff @nsmithcode-blog-blog - Tumblr Blog

Including Facebook's PHP SDK (and other such things) within Zend Framework 2

In ZF1 I would generally include 3rd party API wrappers (Facebook, MailChimp, Google, etc) in Bootstrap.php using something like:

protected function _initIncludes(){ include_once( 'MobileDetect/Mobile-Detect-2.php' ); include_once( 'Facebook/php-sdk-v3.1.1-27/src/facebook.php' ); include_once( 'Google/google-api-php-client-0.5.0/src/apiClient.php' ); include_once( 'MailChimp/MCAPI-1.3.class.php' ); } //_initIncludes

However there isn't really anywhere appropriate to 'include' things this way in ZF2. Ideally we want to include the 3rd party class in the (/all) module(s) that actually use it, but without trying to include it more than once.

The best way I've found of doing this is to add the 3rd party class into Zend's Class Map Autoloader like this:

public function getAutoloaderConfig() { return array( 'Zend\Loader\ClassMapAutoloader' => array( __DIR__ . '/autoload_classmap.php', array( 'Facebook' => 'vendor/facebook/php-sdk/src/facebook.php', ), ), 'Zend\Loader\StandardAutoloader' => array( 'namespaces' => array( __NAMESPACE__ => __DIR__ . '/src/' . __NAMESPACE__, ), ), ); }

This shows how I'm including the 'Facebook' class. Remember that ZF2 chdir()'s to the application's root directory, so the path is relative to that. I can then just create a Facebook instance with:

$facebook = new \Facebook(array( 'appId' => 'xxx', 'secret' => 'xxx', ));

Adding things via this method has a few advantages:

The class is included lazily.

The same entry can be included in multiple modules without there being a risk of conflict.

Zend's Class Map Autoloader is very, very, very fast.

#php #Zend Framework 2 #zf2

Adding my "3rd party" module into /vendor in Zend Framework 2

This wasn't initially obvious to me, but when creating a generic module to use across multiple ZF2 projects (thus putting it in /vendor) you can include a Module.php file in the root of the module's directory to make registering the namespace with Zend's StandardAutoloader simple. (I had assumed this was just how it worked under the /module directory).

So for example - I have a module with the namespace 'Nas', so I store it under: /zf2/vendor/Nas

And then I have Module.php here: /zf2/vendor/Nas/Module.php containing...

namespace Nas; class Module { public function getAutoloaderConfig() { return array( 'Zend\Loader\StandardAutoloader' => array( 'namespaces' => array( __NAMESPACE__ => __DIR__, ), ), ); } }

Finally I needed to add the module into /zf2/config/application.config.php:

'modules' => array( 'Application', 'Album', 'Nas', ),

And that's it. After that I can start accessing classes under my 'Nas' namespace from anywhere within my ZF2 app.

#Zend Framework 2 #zf2 #php

Router for use with single module in Zend Framework 2

As you probably know, Zend Framework 2 basically forces you to use a module structure. This is fine, but for small projects it seems overkill and I'd rather just use a single - more ZF1 like - module that contains my whole application. This is actually quite easy to do. If you base your application on Zend's ZendSkeletonApplication, then you can build everything under the included 'Application' module. The only thing I changed was the router so that it acted as per the default router in ZF1. i.e. /:controller/:action

To do this you just need to amend the 'router' entry in Application/config/module.config.php so that it read as follows:

'router' => array( 'routes' => array( 'home' => array( 'type' => 'Segment', 'options' => array( 'route' => '/[:controller[/:action]]', 'constraints' => array( 'controller' => '[a-zA-Z][a-zA-Z0-9_-]*', 'action' => '[a-zA-Z][a-zA-Z0-9_-]*', ), 'defaults' => array( '__NAMESPACE__' => 'Application\Controller', 'controller' => 'Index', 'action' => 'index', ), ), ), ), ),

This basically just extends the supplied 'home' router so that it allows a controller and action to be passed, which will be accessed under the 'Application\Controller' namespace.

#php #Zend Framework 2 #one router

Latency between Amazon Web Services' Regions

Recently I've had to spend quite a bit of time working out which of the 5 Amazon regions is best positioned for various services I've been setting up. As part of this I measured the latency between each of the Amazon regions. For anyone who's interested - here are the results.

Note: For ease of reading I've including all measurements under each region. Half of the data will therefore be duplicated as I've assumed (rightly or wrongly) that EU-West -> US-East is the same as US-East -> EU-West (for example).

From US-West to...

US-East: 82 ms

AP-North: 130 ms

EU-West: 155 ms

AP-South: 185 ms

From US-East to...

US-West: 82 ms

EU-West: 101 ms

AP-North: 199 ms

AP-South: 256 ms

From EU-West to...

US-East: 101 ms

US-West: 155 ms

AP-North: 282 ms

AP-South: 292 ms

From AP-North to...

AP-South: 84 ms

US-West: 130 ms

US-East: 199 ms

EU-West: 282 ms

From AP-South to...

AP-North: 84 ms

US-West: 185 ms

US-East: 256 ms

EU-West: 292 ms

These numbers represent the rounded average ping time over 30 measurements between two EC2 instances, one in each region. They were all performed on the 8th June 2011.

I've put them here for curiosity value only. I strongly recommend you perform your own tests if you plan on making any decisions based on the outcome.

Amazon EC2 vs Rackspace Cloud Servers with Nginx and PHP-FPM

Having recently made the decision to use Nginx rather than Apache for new projects, I decided to do a few benchmarks to test performance on both Amazon EC2 and Rackspace Cloud Servers. What I found was quite surprising.

The setup was Ubuntu 10.10, with Nginx and php5-fpm installed from Ubuntu's package manager.

Then in /etc/php5/fpm/pool.d/www.conf, I changed the following:

pm.max_children = 30 pm.max_spare_servers = 15 pm.max_requests = 500

and in /etc/nginx/nginx.conf, I changed:

keepalive_timeout 2;

all other settings were left at their default values.

The page I was requesting was the index page from a newly installed Zend Framework project. Using the Siege load tester, I ran tests with 10, 50, 100 and 200 concurrent connections.

All this was assessed on the following instance types:

Amazon EC2 Micro 64-bit

Amazon EC2 Micro 32-bit

Amazon EC2 Small 32-bit

Amazon EC2 High-CPU Medium 32-bit

Rackspace 256MB 64-bit

And here are the results...

Amazon EC2 Micro 64-bit

10 concurrent connections: 9.3 requests per seconds

50 concurrent connections: 9.2 requests per seconds

100 concurrent connections: 7.4 requests per seconds

200 concurrent connections: 12.4 requests per seconds

Amazon EC2 Micro 32-bit

10 concurrent connections: 13.7 requests per seconds

50 concurrent connections: 8.6 requests per seconds

100 concurrent connections: 11.4 requests per seconds

200 concurrent connections: 7.2 requests per seconds

Amazon EC2 Small 32-bit

10 concurrent connections: 11.9 requests per seconds

50 concurrent connections: 13.2 requests per seconds

100 concurrent connections: 13.2 requests per seconds

200 concurrent connections: 12.9 requests per seconds

Amazon EC2 High-CPU Medium 32-bit

10 concurrent connections: 13.6 requests per seconds

50 concurrent connections: 56.4 requests per seconds

100 concurrent connections: 60.5 requests per seconds

200 concurrent connections: 60.5 requests per seconds

Rackspace 256MB 64-bit

10 concurrent connections: 14.5 requests per seconds

50 concurrent connections: 70.7 requests per seconds

100 concurrent connections: 120.8 requests per seconds

200 concurrent connections: 125.0 requests per seconds

So Rackspace is quite clearly the winner, being able to serve over twice the number of requests per second than Amazon's top performer. The really interesting point here is that the Rackspace 256MB 64-bit server is about $11 per month, making it also by far the cheapest.

In all tests the amount of RAM the server had was never the bottleneck (even with just 256MB!), instead it was always available CPU that decided performance - specifically the number of (virtual) CPU cores available to the OS. The reason Rackspace did so well (I think) is that all of their machines come with 4 virtual cores, whereas most of the lower end Amazon machines only have 1.

Based on this I think I'll be sticking with Rackspace for now. Unless, of course, anyone can suggest some settings that I can tweak to improve performance on Amazon?

Don't worry about scalability, we'll just use Amazon

For most of this morning the governments new 'Street-level crime maps' website (http://www.police.uk/) has been down. As today appears to be its official launch I can only assume that it was due to heavy load (now confirmed here: http://bbc.in/fB5ZKm).

Due to my compulsive need to know where every website in the world is hosted, a quick traceroute shows that the police have gone with Amazon's EC2 platform in Ireland.

Now this seems like is a very sensible idea as "Amazon can scale" - right? But as Ewan Leith pointed out, this is true "only if the people have coded it to scale"; which in this case we can only assume they didn't.

The reason I'm going on about this is that there seems to be an increasing number of people who, when talking about scalability, say "we don't need to worry about that, we're going to host it on Amazon". And as Police site proves, this is clearly not the case.

Whilst the Amazon Web Services are a very powerful set of tools for dealing with scalability, they are not in themselves the solution. Without the correct software architecture, Amazon is basically just another virtual box.

#Amazon #Hosting #Cloud

Returning a list of array keys in MongoDB

Here's how I return a list of keys from an associative array (i.e. an embedded document) without also returning their value.

The data structure I have is shown below. It's made up of an associative array [friends], which contains a set of keys (Twitter usernames) and values (details about the user). My aim was to return a list of the Twitter usernames, without all of the details associated to them which - in some cases - could be quite a large amount of data.

[friends] => Array ( [RockSugarBand] => Array ( [realName] => Rock Sugar ... ) [twitterapi] => Array ( [realName] => Twitter API ... ) [biz] => Array ( [realName] => Biz Stone ... ) )

I solved this using MongoDB's 'Group' function. The JavaScript command is:

db.users.group( { cond: {_id:ObjectId('4c3c32c24b065884c53f35bb')}, initial: { results: [] }, reduce: function(obj,prev) { for(var key in obj.friends) { prev.results.push(key); } } } );

What this essentially does is:

Line 3 - Here I specify the document I want to apply the group function to. In my case I just want to return a list of keys from a specific document, thus I identify it using its document id.

Line 4 - I create an empty array - results - into which the keys are added.

Line 5 - Here I start to define the reduce function. It takes two arguments.

obj - The current document (In my case there is only one).

prev - This object contains all the variables defined on Line 4. In this case that's just results.

Line 7 - Here I iterate over all the keys in the [friends] array. Note that in JavaScript the <var foo> in <array bar> structure results in foo containing the key.

Line 8 - I simply push the key - key - onto the results array.

...and that's it! The result looks like:

Array ( [results] => Array ( "RockSugarBand", "twitterapi", "biz" ) )

The reason that results is wrapped in an array is that the function will return one results array per Document iterated over. In my case that's just one, but had I used a condition that returned more documents, they would all be included within this wrapping array.

Doing this in PHP

// Use all fields $keys = array(); // Set initial values $initial = array("results" => array()); // JavaScript function to perform $reduce = new MongoCode('function(obj,prev) { for(var key in obj.friends) { prev.results.push(key); } }'); // The condition on which a document must match in order to be processed $condition = array('_id' => $userDocId); // Execute the query $result = $collection->group($keys, $initial, $reduce, $condition);

Things to note:

According to the MongoDB documentation, the group function does not work in a sharded environment.

This query can't use any indexes, with the exception of finding the document set to iterate over, i.e. the query defined under "cond". For my problem this isn't likely to ever become an issue, but it might if you start iterating over a large number of documents.

This is just how I solved it. There may well be better solutions. If you know of one, please feel free to share it with us all. :-)

#MongoDB #PHP #NoSQL

Field names within a MongoDB Schema

In traditional RDBM systems it was quite common to use two (or three or four) word field names. For example university-name or facebook-id. This of course also works in MongoDB.

However I've noticed that when I'm in a situation whereby I cannot think of an obvious single word field name for something in MongoDB, it's often best to model the data as embedded documents.

For example rather than having:

{"facebook-id":"123456"}

it's better to go with:

{"facebook":{"id":"123456"}}

This means that when, later down the line, you decide that you now also want to start storing other information, for example the user's Facebook name, this can be added using:

{"facebook":{"name":"Bob Sanders"}}

which just feels more semantically correct to me than having to add:

{"facebook-name":"Bob Sanders"}

As MongoDB understands document structure, doing this makes it no harder to index or query the data. In fact I've found it makes it easier to query as you can still request a single field using:

{"facebook.id":1 }

Or you can request all information about a Facebook account using:

{"facebook":1}

Otherwise you would have to request the two fields separately.

#mongodb #PHP

Links to some old articles

Finding your Unique Device ID (UDID) for an iPhone/iPod Touch

How to install a beta version of an Aaron's App onto your iPhone using Mac OS X

How to install a beta version of an Aaron's App onto your iPhone using Microsoft Windows

Applying default styles to a <ul> list when using the Yahoo CSS Reset

I quite often use the YUI 3 CSS Reset from Yahoo when I start styling a page. As part of the reset, HTML lists - both <ul> and <li> - have most of their styling removed, which is great! Exactly what we want... most of the time.

However I recently wanted to "undo" the reset for a specific list so that it displays using the browser default formatting. This is really easy to do, if of course you know to add the margin... which I didn't.

li { list-style-type: disc; margin-left: 30px; }

So the CSS I spent a moderate amount of time trying to find was Line 3. As I said, simple if you know!

#CSS

Trending Blogs

Recently Viewed Blogs

NSmith Code Stuff