How I Fixed: unresolved variable or type await

Ok, super easy one here, but as a newbie to  async /  await this did catch me out.

Let’s pretend we have a function:

This will present an error in WebStorm, and Googling came up only with a bug report from 2015.

In my case, WebStorm would give two different error messages:



Ready to kick yourself?

This I tell you brother, you can’t have one without the other 🙂


Using async / await with React

I’m currently toying with thunks vs Sagas.

The idea of re-writing a significant portion of my app’s API connectivity (from thunk, to saga) is not entirely thrilling. However, sagas do appear to be the better solution given what I currently know, and would choose them if starting again from scratch.

The gist of my problem is that thunks have added in a layer of complexity – but they work.

For any API call that should be authenticated, I need to catch the call using a middleware and then add the necessary token, and so on.

Combine this with Redux Form, however, and I am left with a bit of a head-scratcher. This middleware is generic. If certain calls fail, I need to map the response (containing error messages) to an object that Redux Form understands, then stopSubmit');">dispatch the [crayon-580c8442e9785998641616-i/] action.

Anyway, enough about my problem.

Before making the switch I found a potential solution that involves using  async /  await. Being a sucker for new and shiny, I wanted to get it into my project.

Simply trying to use  async /  await resulted in an error for me:


To fix this, I needed to import the babel-polyfill. However, a thing I found out is that you can import this dependency once in one of your top level components, rather than per file.

For example, in my project I have an  App component which contains a container which all other components in the app render into.

I added the single line:

as the first line in the file, and now async /  await works just fine.

These other two files may help in setting up:



7 things I learned adding Jest to my existing JavaScript boilerplate

Here are 7 things that I encountered when trying to add Facebook’s Jest to my existing React JS project.

This project was initially based on Corey House’s boilerplate – React Slingshot. There was nothing wrong with the test setup the boilerplate provided. I just wanted an excuse to try Jest.

1. Jest doesn’t play well with importing stylesheets

Here was the code I was using:

And the associated Jest output:

To be fair, the output looks a bit nicer in the terminal.

Removing the stylesheet line:

Now commented out, all passing:

2. Tests live in the  __tests__ directory

The tutorial link doesn’t make it immediately obvious that the location and naming of your test files has an assumptive default config:

The boiler plate I am using has the test files in the same directory as the component itself. I followed the boiler plate pattern first, and it didn’t work.

I was confused why my tests wouldn’t run:

Tests need to go in a  __tests__ directory, unless you are a regex ninja.

If you do want to overwrite it then you can update your  package.json with extra config:

I went with their defaults.

Now also note, you wouldn’t have this problem if you had read the landing page and the Docs link. I made the mistake of going direct to the Docs link via Google.

3. You may need to rename things

In React so far I have seen files named like either  thing.jsx,  or  thing.js. I’ve never seen anyone use  thing.react.js.

However, the Jest docs use this convention.

So, having made two mistakes already, I made the switch myself.

Tangible benefit: None(?)

4. Jest ran existing tests just fine

This one threw me.

I had an existing file left over from my purge of the boilerplate demo site. I manually deleted the files as I worked my way through and replaced the boilerplate parts with my own.

One such file that was left was a utility class called  mathHelper.spec.js 

Jest ran this just fine:

5. Snapshot Testing is a really smart idea

You are kidding me.

Another concept to learn?

When will this learning ever end? Never. Get reading.

Actually though this is fairly simple to understand, and incredibly beneficial.

An example illustrates it best.

Let’s say I have a very basic component:

And a really simple test:

The first time I run the tests with npm test then Jest will create a snapshot of how this page is expected to look:

And the test output:

Then, should you make a change to your component in some way which causes the output to change:

Then re-run:

Again, it looks nicer in the console.

6. You probably want an alias for updating snapshots

Here’s what I use, feel free to differ:

Every time you make a change to your component you likely need to re-update your snapshots. Having an alias is better than the alternative of typing out morse code.

7. There are concerns I only found out about after reading the Snapshot announcement blog post

Dropped in at the bottom of the blog post announcing Snapshot testing is some notes about forthcoming improvements.

This one caught my eye the most:

  • Mocking: The mocking system, especially around manual mocks, is not working well and is confusing. We hope to make it more strict and easier to understand.

Thankfully I did this migration on a new git branch 🙂

PHPNW16 Conference Review

With the family addition, client work, and growth of CodeReviewVideos – amongst many other things – this year has been incredibly busy. I wanted to attend three conferences this year, but as time has been so limited, I have had to rethink that. I distilled my initial list down to only PHPNW16.

Having attended the excellent PHP North West for the previous two years, I really didn’t want to miss this one. Also, it is the most local – being 45 minutes away – so was the most practical, and relevant. All in all, the best use of my time.

I managed to grab a blind bird ticket way back whenever they were released, which means you buy the ticket without knowing anything about the speaker line up. It’s a fairly safe bet, based on the previous two years.

Conference attendance levels seemed high. I have no official figures, but the opening address was packed out and the UK Fast intro video kicked everything off with a few laughs – followed by Darth Vader visiting the stage.


By the way, just like last year I must apologise for the quality of my photos. There doesn’t appear to be a phone created that can accurately still my shaky hands. Also, I have the near perfect knack of being able to get either the speaker, or the slides, but never together.

PHPNW16 Keynote – A World Without PHP by Ben Marks

There were some interesting points raised during this talk, echoing my own thoughts on the current state of PHP. Ben raised the point that looking around the room, generally the age of attendees was perhaps older than you may find with certain other popular languages (ahem, JavaScript). I hadn’t actually noticed this till it was pointed out but it’s true. Most of the room seemed 30+.

This is a concern for me. With fewer young developers coming into the language it raises questions about the long term future of PHP. I should state here that by long term future I mean decades. I don’t forsee PHP disappearing from the business world in my working lifetime, but that’s not to say most PHP roles won’t simply be supporting legacy / soon-to-be-replaced software with the new and shiny.

This saddens me, honestly. PHP gets an unfair level of bad press, but if used well, it is still a brilliant back end language for your typical web project.

What I’m noticing in my client work is the junior / newer devs only know JavaScript. They know front end JS, and back end JS, but beyond that they aren’t willing to pick up what is generally a language with bad press. I understand, but disagree.


It was nice to see PHP-Nuke get a mention in the slides 🙂 That brings back memories.

I liked this talk as it was provocative. I can’t say I came away from it with a renewed positivity towards PHP. I think the down hill trends in popularity will continue while newer devs remain undecided on which back end language outside of JS is worth their time learning.

Continuously Delivering – James Cowie

James’ talk was a great way to kick off the conference proper. I could really gel with his experiences and frustrations of modern development in the trenches. Chief of which appears to be feedback time, the time between which he and his colleagues implement a feature through to the time his stake holders (his peers, his internal QA resources, and the businesses client) respond with how well his changes / features hit the brief.


A number of his solutions were hugely suitable to larger organisations. Continuous deployment / delivery (there is a difference, see the following slide) are generally most widely used in larger organisations, but I’m sure there are other developers like me who use them as solo developers.


This fact inevitably leads to a whole bunch of Software as a Service (SaaS) offerings – which is fine, if you are a big business with a big budget. For smaller scale operations it is a lot more difficult to justify the expenses of some of these software tools, no matter how good they are. Having many small bills for individual parts of your development process can easily add up to large amounts, if left unchecked.

A big part of the talk for me was around feature toggles. This is something I have seen mentioned quite a bit recently, and I haven’t seen a defacto solution to the problem. James offered a bunch of useful tools and approaches, and also pros and cons to each approach. I found this very valuable.

I can’t wait to try out some of the tools mentioned in this talk. Whether I will use them or not is yet to be seen, but knowing they exist is useful in itself.

Coffee Break

During the break I had a chance to look around the sponsor stalls. I ended up having an interesting chat with the Sainsbury stand, who were running a competitive Kata session.

uncon track revealed at first break

You’re able to check out the project yourself and see how you fair. They assured me this wasn’t a recruitment tool, but top tip, check out the github repo if you are planning on interviewing there as there is a recruitment repo to peruse 🙂

Running PHP on NGINX – tips and tricks for high performance websites

I found Harald Zeitlhofer’s talk highly informative. Plenty of interesting examples illustrated each point made, and knowing a little Nginx made the talk easy enough to follow. There were plenty of take away tips.


With so many ‘things’ a modern developer is seemingly expected to know, recently I have switched to a different approach in learning about the more “ops” side of things.

Rather than try and setup my configurations in the most highly optimal way, I instead rely on the open sourced configs shared in the most popular ansible repositories.

I’ve talked on this before, particularly in my Ansible course here at, where I highlight how using a tool like Ansible enables you to leverage the expertise of true experts in any given technology.

A good example of this is in the configuration of a modern web server such as nginx. On your own you could spend days / weeks / months (or even an entire portion of your career) devoted to highly optimising nginx. The tips to be gleaned from experts like Harald Zeitlhofer are the results of his years of experience.

I was glad to see a whole bunch of the tips and tricks in this talk where already included in the Ansible scripts for nginx that I use these days. That said, I still gained a whole bunch of new tips, some of which are:

* pcre_jit on (for speed boost in any locations with regex)
* fast_cgi_finish_request() – keep your client responses snappy, then do slower stuff
* Memcache direct responses via nginx
* open_file_cache for keeping static assets file handles open
* Upstream makes it much easier to use nginx as load balancer

I really enjoyed this talk.

This is an amazing picture

Dinner Time

The dinner time session was a little confusing. From the third room we streamed back into the refreshment / sponsor area to be greeted by staff serving steak and self serve spuds / veg. Piles of forks but no knives? Also… Nowhere to sit? Thankfully having attended before I knew there was a designated dining area that thankfully did have cutlery and seats, but plenty of others stood round trying to eat a steak one handed.

Graylogging to the beat – Matt Cockayne


Another thoroughly enjoyable talk this time by Matt Cockayne, about a topic I have invested quite a bit of time I to recently: logging. Specifically with graylog.


I’m a big fan of Graylog, as between it and the ELK stack, I have found it to be the much simpler of the two to get going. This ultimately means it gets used a lot more. And that’s even with Ansible scripts taking away most of the pain.

There were some nice live demos here, always fun and potentially hazardous, but both went off without a hitch – a testament as much to Matt’s talk practice no doubt, as to Graylog’s simplicity.

I learned some new stuff here around Beats by Elastic. I need to do more digging here, but it seems interesting on the surface.

Lastly Matt was in full scout leader regalia. Full credit for this, I’m not sure if he rocked up to the venue in the morning dressed this way or changed once on site, but that’s a sure fire way to get an audiences attention.

Kicking off with Zend Expressive and Doctrine ORM

I went in early to this talk from James Titcumb, determined to get a good seat. My friend Matthew Setter is big on the whole Zend-sphere and I was curious to find out more.


Attendance of this talk was surprisingly lower than I expected. I’m not sure why that is, as this was an excellent talk that deserved more attention. I came away with a better understanding of a Zend Expressive app than I had to begin with, and seeing how Doctrine ties in was very helpful.


Around Zend Expressive I am still not yet sure if I would use it. It seems fully featured but I’m put off by the amount of config involved in getting started. It seems you need to write as much config as you do code.


And what worries me is that learning all this config is a big upfront cost if you end up switching to a competitor (slim, lumen, silex) if you don’t gel with it.

That said, it may well be worth it to get using PSR7.

I was happy that I would get to see Expressive’s big brother in the very next talk by Gary Hockin. Back to back Zend to end the day. As I say, I’m not sure I will ever use either of them in production currently, but that’s no excuse not to see what they can do and hopefully learn a thing or two in the process.

Being Ready for ZF3


Again, lower attendance than I expected. I’m really not sure why. When Gary asked who was using Zend Framework almost everyone in the room raised their hand. I’m guessing that’s indicative of the people who attend a Zend talk, and a representation of Zend Frameworks current position in the php ecosystem.

This talk would have been perfect for any working ZF developer. For me as someone who is basically a Zend Framework newb, I felt a little out of my depth. Factories, invokables, invokable factories…

What I do like about Zend is they are seemingly making themselves extremely component friendly. Everything seems to allow using one of many implementations, and you don’t need to use any of Zend implementations to make it work. I think that’s a really cool idea, and can only help adoption.

The downside – in my mind – is debugging may be a touch harder, as in finding a StackOverflow thread that uses your specific set of dependencies may be trickier. That’s just a guess.

In truth this talk was way over my head. If you use Zend Framework in any way then I would point you at the video of this talk (once it is available) as it’s info you will very likely need to know.

There were two tips that looked like the sort of useful information that needs sharing:

zf-3-gotcha-phpnw16 zf-3-useful-tip

I know my photo sucks on the second one, so pester Gary on twitter or his jetbrain’s email if he hasn’t already shared his slides on by the time you read this.

PHPNW16 – Day 2

I was unfortunately a touch late arriving for the start of the second day. Family commitments, and needing petrol, combined with a 45 minute journey, then finding a parking space… All my own fault.


The first talk of the day was on extracting wisdom from stupidity. I would like to say this is something I don’t have to do very often, but I’m all too aware that when I make mistakes (which is more often than I would like) they are usually, at the very least, daft given the benefit of hindsight.

An interesting take away from this talk for me was in having names for some approaches I already use. When encountering problems you can apply logical or lateral thinking in finding a solution.

I boiled this down to approaching the problem from different angles. It sounds easy / obvious, but as a developer it is all to easy to become so consumed by a problem / bug that we focus exclusively on the approach that might “just work”, rather than exploring other angles of attack that may lead to a much more optimal solution.

Another thing I would add here is its amazing how big a difference a 5 minute break away from your computer can make when thinking through a problem or bug.


There was a really fun example used throughout which was Ramon’s attempt to write a raffler – a piece of software for picking winners of a raffle – using every single array_ function. Apparently there are 50 of them. I feel there should be some Steam-esque achievement for things like this.

The talk ended with a nice takeaway point. Consider rephrasing your question from:

I don’t understand how this can happen!


How can I make this happen?

This should help greatly in your approach to debugging / problem solving.

Queues with RabbitMQ by Lorna Mitchell


For my second session of the day I attended Lorna Jane’s talk on RabbitMQ. Any unfortunate who follows my other interests will know all too well that queues are my current favourite topic. I am somewhat aware that they are my “hammer” as of late, and I am always out looking for nails to hit with them. Or something.

Lorna obviously has great enthusiasm for the topic and this was evident throughout the knowledge exchange. Two (terrible) queueing puns in one sentence.

Two questions I had were addressed in the talk: how to handle failed workers (Supervisord, or upstart); and how should I be handling retries (manually).

Another takeaway from this talk was in versioning queuing strings, something I am not currently doing but which is exactly the sort of excellent tip that only those with more experience will have learned and, thankfully, thought to share.

I hadn’t thought to handle empty messages, so again another really useful bit of insight into potential future problems.

Lastly, dead letter queues, these seem to be the answer for jobs that should work but perhaps some third party API is down during the processing of the job. This is something I need to investigate further – again a potential future problem.

My only quibble with this talk was in the lack of time for questions at the end. Often questions are asked that either I would not have thought of, or have an opinion on already but am interested in alternative viewpoints. Lorna did mention she was available to take questions, but outside of the Q&A section these unfortunately don’t get shared publicly.

Websockets and Torrents – James Mallison

This talk was packed full of technical, which is always great. The downside was I couldn’t see the screen so well. In hindsight, simply closing the back curtains would have improved the visibility massively. I was convinced it was darker on the Saturday, and looking back at the photos for Harald, I think it definitely was.

Generally having been doing quite a lot with Elixir and Phoenix (particularly Phoenix) as of late, conceptually I could piece together what James was talking about and relate it to what I knew.

The thing that surprised me, and maybe it shouldn’t have in hindsight, is that whatever language you use for web sockets, the process is largely the same. This is similar to creating and consuming queues with RabbitMQ. If you view the examples on the RabbitMQ home page, though the syntax differs, the concept / theory behind the implementation is similar enough between languages. As I say, obvious in hindsight.


It was clear that within researching and implementing this system that James had encountered a bunch of problems and accompanying solutions that bring about the kind of experience that only come through experimentation and curiosity. I wish more developers shared this level of passion.

Being a more technical session I am glad this one came as the third session of the day.

I loved the story element behind using pre-paid credit cards to fire up an untracable Swedish VPS. It’s certainly a more paranoid approach than I usually take when downloading the Ubuntu torrent 😉

I learned here that ws:// and wss:// are like http:// and https://.

James also recommended a talk from PHPNW15 which I have added to my playlist.

PHPNW16 Closing Keynote

The closing keynote was titled: Using Open Source for Fun and Profit, by Gary Hockin.


I thought this talk was excellent. It was humourous and fun, but also relevant and relatable.

I could not agree more with the points Gary raised around the benefits of contributing – in whatever way you choose to do so. One of the particularly important points was in starting a (or regularly updating you existing) blog. I think this is absolutely crucial for the modern developer.


Gary rasied the point that yes, contributing to open source can be scary. Your first public pull request is very likely to be a tense moment – more so for you than for the project 🙂

The example used here was in Gary’s first (and subsequent) commits to Zend Framework. He highlighted how he was effectively getting free code reviews from extremely clever and talented developers. If you were to bring these very same developers into your organisation and get them to do consulting for your internal projects, these very same code review sessions would cost hundreds, if not thousands of pounds.

But there are more benefits than this – contributing can lead to an increased number of social connections. These people share your interests. Over time these people may very well become your friends. These friendships are valuable for many reasons.


I honestly think my summary of Gary’s closing keynote has not done his talk justice. I really enjoyed this talk, and I thought it was a perfect end to another great year for PHP North West / PHPNW16.

See you all at PHPNW17 🙂

How I Fixed: cannot open shared object file

I recently updated all my Ansible build scripts to PHP7, and shortly after, my built boxes started throwing this annoying error:

There’s no indication as to where this  file is attempted to be loaded from.

I am using an Ubuntu box and all I could find was help for CentOS. Dammit, I have been meaning to make the switch for a while now, but I just haven’t yet found the time.

Anyway, after a bit of Google-fu, I found a quick way to find the file:

And from there, the fix is easy:

and inside the file, comment out the line mentioning

Problem solved.