Learn More About PHP And The Web Platform!

Struggling with your web server, or to scale your PHP application to meet growing demand?

Whether you're running one server or a whole server farm; whether you're hosting on Windows Server or on Linux.

Learn from Stuart's experience with system design, delivery, support and management to help you do a better job and have an easier time.

Beneath Whitby breakwater

Storyplayer 1.5 Released

Posted by Stuart Herbert on January 7th, 2014 in Storyplayer.

Storyplayer v1.5 has been released.

The major feature of this release is a complete overhaul of how test devices (such as web browsers) are managed inside Storyplayer, and integration with Sauce Labs for cross-browser testing. It also comes with the usual upgrades to support the latest Selenium Webdriver, Chrome, Chromedriver and Browsermob-Proxy releases. (full changelog)

I’ve also (finally!) completed the manual which covers:

You can add Storyplayer to your projects using Composer – you’ll find the package as datasift/storyplayer – or download as an experimental PHAR. (Please make sure you’ve installed the necessary dependencies first!)

Any problems, please let me know.

Storyplayer is the open-source test automation tool built by DataSift. Use it to bring your user stories to life using plain old PHP #noDSL. Create test environments; deploy code; test with real browsers, shell commands, and any PHP code; and clean up afterwards – all from your tests. Write your tests once, and run them against your dev, test, staging and production environments. Storyplayer ships with 20 modules, including support for Vagrant, Amazon EC2, and ZeroMQ, and can easily be extended with your own plugins.

Be the first to leave a comment »

Storyplayer is DataSift’s test tool for functional and non-functional testing of software and services, built to test at the firehose scale. It sits nicely between PHPUnit for unit testing by developers, and Behat for acceptance testing by product managers.

Earlier this month, I spoke to a packed audience at the PHP London user group meetup about Storyplayer, a test tool that we’ve open-sourced here at DataSift.

Here are the slides from that talk, for everyone who hasn’t yet seen them via Twitter:


If you can’t see the embedded slides in this blog post, they’re available over on SlideShare.

Right now, I’m focused on completing the online documentation (which is very much a work in progress), and preparing v1.1.0 with further improvements.

Comments Off on Storyplayer Slides From PHP London Talk

Phix 0.16.0 Released

Posted by Stuart Herbert on May 23rd, 2013 in phix.

Phix is a tool for creating and managing PHP components and tools and releasing them as PEAR packages.

I’ve pushed out Phix 0.16.0 this evening, with the following changes:

  • phing build-vendor now removes the component’s own code from the vendor/ folder. (We build the vendor/ folder using PEAR, which installs the component into the vendor/ folder … sigh)
  • An update to Phing changed the default behaviour of the <fileset> tag, breaking backwards-compatibility. I’ve updated our build.xml file to make the <fileset> tag revert back to its original behaviour.

To update your copy of Phix, please run:

pear upgrade phix/phix4componentdev

Any problems, please let me know.

Be the first to leave a comment »

PHP is the world’s #1 programming language for creating websites. But it’s capable of so much more. How about real-time processing the social firehose? 🙂

More Than Websites: PHP And The Firehose @DataSift (2013) from Stuart Herbert

Thanks to Brighton PHP for hosting this talk last month.

Be the first to leave a comment »

HubFlow 1.5.1 Released

Posted by Stuart Herbert on March 25th, 2013 in Toolbox.

Over the weekend, I released v1.5.1 of HubFlow – a Git extension that brings the gitflow workflow to GitHub.

The key new features are:

  • New ‘git hf push’ and ‘git hf pull’ commands, which do the right thing no matter which kind of branch you’re working in at the time.
  • No more manual ‘git remote update’ before running HubFlow commands.

There’s also a long list of smaller changes and fixes too – many thanks to everyone who sent in a pull request or logged an issue.

The full ChangeLog is available.

I’m starting to get requests for documentation and portability fixes for Windows users. I don’t run Windows on any of my computers, so if there’s anyone out there who’d be interested in helping out, please let me know!

Be the first to leave a comment »

I’ve mixed feelings about the PSR standards to date.

  • PSR-0 has standardised autoloading in a practical way. Sure, it does have an evil design flaw (different classes can map to the same file on disk), but in practice it’s not a problem that happens.
  • I’d have personally liked to have seen PSR-1 go further, and address method naming in more detail (in particular, that method names should start with a verb), and also address getters/setters and protected vs private.
  • I’ve no personal interest in PSR-2, and am philosophically against “layout” coding standards like this.

… so I wasn’t sure what to expect when I decided to add PSR-3 support to a private framework I use to build test tools at DataSift.

What Is PSR-3?

PSR-3 is a proposed standard (voting has finished, it should appear as an accepted standard when the PSR folks recover from too much Christmas turkey) describing a common logging interface for PHP frameworks.

It’s based on a small subsection of RFC 5424, which describes the Syslog standard, which is a very sensible choice. Sysadmins think in terms of Syslog levels, and they utterly hate dealing with loggers that don’t map cleanly onto Syslog.

What Does The Interface Look Like?

To support PSR-3, you’re required to implement the following methods:

  • emergency($message, $context = array())
  • alert($message, $context = array())
  • critical($message, $context = array())
  • error($message, $context = array())
  • warning($message, $context = array())
  • notice($message, $context = array())
  • info($message, $context = array())
  • debug($message, $context = array())
  • log($logLevel, $message, $context = array())

You can see the proposed interface in full here, including the constants for $logLevel.

The $context is a list of named parameters to substitute into the $message. The special parameter ‘exception’ is reserved for an exception that needs to be added to the logs.

A Critique of PSR-3

PSR-3 is built on a good idea, but there’s three areas where I think PSR-3 could have been better:

  • the method names in the LoggerInterface
  • the handling of the exception parameter
  • the LogLevel constants

I’d have also liked to have seen trace level logging supported, although I can understand why most PHP developers won’t be aware of that practice.

Better Method Names

It’s perhaps a small thing, but I’m a big fan of making code more readable by having all method names start with a verb. I find that it makes code more self-descriptive, and that it’s much easier for casual contributors to grok.

So, instead of this:

  • $logger->emergency(“Captain, she canna take no more”);

we could instead have had:

  • $logger->logEmergency(“Captain, she canna take no more”);

Like I say, a small thing, but in my experience it’s improving all of the small things that leads to big successes, especially in larger code bases.

Handling The Exception Parameter Properly

To paraphrase, the PSR-3 standard says this about the $context parameter: “here’s a list of key/value parameters, but one is special”. That “but” is a code smell!

Not being able to treat all of the key/value parameters equally (slightly) increases the complexity of handling $context, increases the performance cost of logging, and forces the Logger implementation to do things that PHP could handle for us.

A better solution would be to move the exception out of the $context and make it a separate parameter like this:

  • logEmergency($message, $context = array(), Exception $cause = null)

This would allow PHP to make sure that only a genuine Exception was passed into the log method, and would allow the implementation to treat all of the key/value pairs in $context equally. This is a cleaner interface to implement.

Log-Level Constants

RFC 5424 defines the log levels as an ordered set of integers. This is deliberate, as it makes it trivial to say “only log warnings and above”. Unfortunately, because it was difficult to crowbar this into Monolog, the decision was taken to go with strings for the log-level constants. This regrettably increases the complexity of all other loggers.

If you look at pull-request to add PSR-3 to Monolog, you’ll notice that Monolog is explicitly relying on the value of the PSR-3 constants to map them directly onto Monolog class constants:

375	+    public function log($level, $message, array $context = array())
376	+    {
377	+        if (is_string($level) && defined(__CLASS__.'::'.strtoupper($level))) {
378	+            $level = constant(__CLASS__.'::'.strtoupper($level));
379	+        }
380	+
381	+        return $this->addRecord($level, $message, $context);
382	+    }

This is done because (ironically) Monolog already uses numerical log levels internally, with the debug level having a value of 100, and the emergency level having the value of 600. There was obviously the risk of Monolog log level constants being passed in instead of the PSR-3 constants, where it would have been impossible to tell them apart if they were both numeric. I’m sure other existing loggers probably face similar issues.

It’s a tricky issue, but on balance I think the wrong decision was made here for the wrong reason, and the community would have been better served longer-term if PSR-3 had supported the RFC 5424 values for the log level constants.

Final Thoughts

PSR-3 isn’t objectionable … it’s just that it could have been a bit better than it is.

I’ve added both PSR-3 support and the revised methods from this blog post to my internal LogLib. PSR-3 will allow me to inject LogLib into third-party components that support it. My own code will be using the revised methods I’ve proposed here, for the reasons mentioned above.

Comments Off on Personal Thoughts On The PSR-3 Log Proposal

Free Ebook: Getting Hired

Posted by Stuart Herbert on November 12th, 2012 in 1 - Beginner, Toolbox, Training.

From the Introduction:

“This e-book will hopefully show you how to put yourself across to a prospective employer in a way that makes it easy for them to spot what you have to offer them, to increases your chances of successfully finding a job in the United Kingdom’s computing industry.

“Recruitment processes vary from employer to employer. I’ll take you through the most likely steps that you need to get through. I’ll explain the process from the employer’s perspective first, and then from your point of view as someone applying for a job. A better understanding of what the recruitment process is, and why, will help you avoid the common pitfalls along the way.

“The second part of the book is more about you, about what you need to do to be prepared for when you join the industry, either during an industrial placement year or when you graduate and leave academia. Ours is a multi-disciplined industry where things change rapidly, so to help you prepare, I’ve finished off the book with some lists of the fundamental skills that industry expects you to have before you start your first job.”

Getting Hired is a free ebook released under a Creative Commons licence. I hope you find it useful.

2 comments »

Last weekend saw the PHP NorthWest user group run their fifth conference. Spread over three days, it gave over 400 folks who attended great talks on a wide variety of topics from speakers both established and new. Once again, Jeremy, Rick et al ran an excellent conference, and I’m already looking forward to next year’s event.

0I0B1694.JPG

See more of my photos from the PHPNW12 conference on Flickr.

Be the first to leave a comment »

I’ve just published v1.4 of DataSift’s HubFlow Git extension. HubFlow is a branching strategy for Git and GitHub, based on Vincent Driessen’s original GitFlow model.

Changes In This Release

The main change in this release is that you now must merge your feature into the develop branch via a pull-request before using the git hf feature finish command. (You can override this behaviour, and get feature finish to do the merge for you, by using the -f flag).

The full changelog is available on our GitHub pages.

Upgrading From An Older Release

To upgrade to this release, please run:

sudo git hf upgrade

If that doesn’t work (because you’re on an older version of HubFlow that doesn’t have the upgrade command), please re-install:

git clone https://github.com/datasift/gitflow
cd gitflow
sudo ./install.sh
Be the first to leave a comment »

I haven’t really talked much about my upcoming tutorial session at #phpnw12 next month before now, but I hope there’s still time to convince you to come along and learn how to use Git as your team grows in size.

That’s what I’m teaching: a strategy, plus supporting tools for Git called HubFlow, that will help you stay sane – and more importantly help you keep delivering – as your team starts to collaborate on your product.

It isn’t my strategy: the credit must go to Vincent Driessen, who first blogged about GitFlow at the start of 2010. And they aren’t my tools: again, they originally come from Vincent. All I’ve done is adapt them for working against GitHub – hence the name “HubFlow”; but if BitBucket is more to your taste (or wallet) then rest assured that both tools and strategy work can be adapted for there too.

Maybe you don’t need this strategy. If you’re working on one-off consulting gigs for clients, where you can get in quick and get out quick, then HubFlow might not be necessary. But if you’re working on any sort of product or service, either commercially or open-source, then I can strongly recommend HubFlow to you – even if you’re just at the one-man startup stage. And the benefits of adopting HubFlow only increase as your team grows in size.

I’ve already put a lot of effort into documenting HubFlow, and if you’ve previously read the docs, you might be feeling confident enough to adopt it by yourself. If you do, I think that’s awesome, and you should go for it without delay. Please do email me if I can help in any way. I’m passionate about everyone adopting the fundamentals of software engineering, and few things are more fundamental than good source control.

But if you’re still reading at this point, I hope that I can convince you to buy one of the remaining tickets for my tutorial session at #phpnw12. I don’t personally profit by it – all of us teaching at #phpnw12 are volunteers – but maybe you will.

What I’m teaching is the approach that I’ve introduced to DataSift. You might not have heard of us yet; we provide a platform for filtering social data in real time, handling terabytes of data a day at full firehose-scale, and many thousands of incoming data every second. And every piece of that data goes through code written in PHP.

Although we’re a young startup, we’ve already grown beyond 20 developers, and with that many people collaborating to build that platform, with every team working at their own pace, we needed to adopt a common way of working together with Git and GitHub so that the company continued to scale well.

  • It had to be a way that allowed every developer to take full advantage of Git, especially when it comes to committing their work early and often.
  • It had to allow developers to form ad-hoc teams that worked at their own pace.
  • Remote working is a fact of life these days, and it had to work just as well whether everyone is in the office or working from somewhere else.
  • It also had to ensure that only work that had been finished made its way into any of our releases.
  • We wanted to make sure that there was an opportunity to review every change before it went into a release. Code reviews play an important part in delivering high-quality work time after time after time.
  • We didn’t want pending releases to hold up new development, ever.
  • And if something did screw up in production, we needed a way to go back to our last known good version, fix it, and release *that* – all without disrupting any pending releases or existing ad-hoc teams.
  • Finally, it had to be easy to teach to people who are new to Git and GitHub, preferably by wrapping complicated Git operations up inside a single command each time.

Those are the benefits that HubFlow gives us. And at #phpnw12, I’ll be teaching everyone who attends my tutorial session how to get those benefits too.

What makes me qualified to teach this topic? And what makes me qualified to be teaching at all?

I’ve got 18 years of experience setting up and/or running software configuration management, taking in systems as diverse as RCS, CVS, Perforce, Continuus, Clearcase, Subversion, Mercurial, and Git. I’ve done this with, and for, organisations as small as a one-man team all the way through to large international corporates. I’ve even built a version control system for one company in the past. (Git is much better! 🙂 And I was around long enough to see (and learn from) the failures as well as the successes. (I’m a big believer that success teaches you a bit, but failure teaches you more). Plus, I’m the author of the HubFlow strategy, and the maintainer of the HubFlow extension for Git.

It simply isn’t possible for me to distill all of that rich and lengthy experience down into the documentation that I’ve written for HubFlow. I think the documentation is good – I wouldn’t have put my name to it otherwise – but I think you can learn even more from me in person.

I’m a qualified teacher of adults. I’m trained how to teach, and I’ve had a lot of practice doing so. My first PHP conference appearance was back in 2004 on Marco’s php|cruise, and since then I’ve spoken at the PHP NorthWest and PHP UK conferences several times. I co-wrote the Zend Certification Study Guide for PHP4. Once a year, I teach at the University of Aberystwyth, helping their Comp Sci students prepare for applying for jobs for their year in industry. Plus I’ve done a substantial amount of teaching and mentoring as part of my job and open-source work over many years. And away from computers, I’ve been teaching martial arts for over 12 years.

If you need the benefits that HubFlow brings, then I’d love to teach you in person. You can buy a ticket for my tutorial day on the #phpnw12 website. I hope to see you there.

Be the first to leave a comment »
Page 2 of 1812345...10...Last »

This Month

June 2017
M T W T F S S
« Jul    
 1234
567891011
12131415161718
19202122232425
2627282930