rss.xml

<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
  xmlns:content="http://purl.org/rss/1.0/modules/content/"
  xmlns:dc="http://purl.org/dc/elements/1.1/"
  xmlns:itunes="http://www.itunes.com/dtds/podcast-1.0.dtd"
  xmlns:trackback="http://madskills.com/public/xml/rss/module/trackback/">
  <channel>
    <title>Jenko</title>
    <link>http://localhost:4000</link>
    <description>Words & Code</description>
    <pubDate>Mon, 21 Nov 2022 00:00:00 +0000</pubDate>
    <item>
      <title>Hacktoberfest checking out</title>
      <link>http://localhost:4000/hacktoberfest/2022/11/21/hacktoberfest-checking-out</link>
      <description><![CDATA[
]]></description>
      <pubDate>Mon, 21 Nov 2022 00:00:00 +0000</pubDate>
      <guid>http://localhost:4000/hacktoberfest/2022/11/21/hacktoberfest-checking-out</guid>
      <content:encoded><![CDATA[{% include JB/setup %}

The first [hacktoberfest](https://hacktoberfest.com/) I took part in was 2015, you can [read more about my experience on the blog of where I used to work](https://www.boxuk.com/insight/archived-hacktoberfest-2015/). It was pretty novel back then and it felt like every pull request was a very minor step in the progress of open source. One thing that was missing was an easy way to check your progress so you could see how close you actually were to claiming a free t-shirt. That's what gave me the idea to create a little checker app. It wasn't complicated, just a small node app that used the Github API to look up how many PRs a specific username had created during the qualifying period of October. Back then, the rules were pretty simple, open 4 PRs on Github in October and you've qualified. Spammers and scammers weren't so much around back then, so all the additional checks that are required nowadays weren't needed back then. 

![The initial basic design](https://github.com/jenkoian/hacktoberfest-checker/raw/version2016/hacktoberfest-checker-2016.png)

It got a little bit of interest from others taking part and I think it's fair to say for a small part of that 2015 edition at least it was _the_ way of checking your hacktoberfest progress. It was quite rewarding and exciting to lead a popular (popular being relative here, for me it was popular, I'm sure others it would barely be on their radar) open source project. One of the best aspects was seeing comments like [this one](https://github.com/jenkoian/hacktoberfest-checker/pull/7#issuecomment-148894994).

![](https://user-images.githubusercontent.com/131355/203045926-4b555987-9332-44cd-a549-42e60882f06e.png)

Year after year I updated the app with a fresh look and feel to match the underlying theme and I tried to introduce some new bit of technology each year, even if just a new CSS or JS framework so I could try and learn something new in the process. What started as an extremely simple node app with some basic front end JS and CSS is now a fully fledged [React](https://reactjs.org/) app usig [Tailwind CSS](https://tailwindcss.com/). The React rewrite is particularly worth calling out, as I had expressed an interested in rewriting the app in React and [someone submitted the most incredible PR](https://github.com/jenkoian/hacktoberfest-checker/pull/333) essentially doing all the work for me! It was great because it meant I could read through and understand the changes without undertaking the daunting task of having to start a big rewrite with no knowledge of React. Building upon this over the years has left me with a slightly above zero understanding of React, which is great.

The app started as an app hosted on the free tier on [Heroku](https://www.heroku.com/), this changed after a few years after I realised I was hosting this on a Digital Ocean competitor for an initiative organised by Digital Ocean. I reached out to them and they were only happy to give me some free credits to move over to [Digital Ocean](https://www.digitalocean.com/). The free credits ran out a year or two after than initial edition and although I'm sure they would have been more than happy to replenish them, I didn't want go back cap in hand so have been paying the hosting for the last couple of years. 

The cost isn't a big deal, a bit annoying given the economic state of the world at the moment, but it's not a massive amount. However, it's the maintenance, support and frankly the motivation of keeping the app running that has led me to decide that...

**The hacktoberfest checker has come to the end of it's life**

It's only a month a year, but when it came around this year I was actually dreading having to give up some of my free time to dedicate to it. It's not even that big of an upkeep, but still enough for it to become a distraction I could do without. 

The other aspect to this is that the app is more or less superfluous now anyway, worse than that it's not even accurate anymore. Digital Ocean has since built [it's own progress checker](https://hacktoberfest.com/profile/) and due to the spammers and scammers mentioned earlier have added more and more complexity to the rules, most of which we've added support for now, but some are extremely difficult/impossible, like Digital Ocean maintains a private list of repositories/users that are banned, also PRs have to be approved by Digital Ocean after a grace period which could be different for each PR, there's also a maintainers reward which seems to be manually picked by Digital Ocean which we obviousy can't add support for.

So although it was rewarding at first, the fact there is now a better and more accurate alternative, the fact I don't look forward to October coming and the fact I could save a bit of money, means that now is a good time. The repository on Github has over 700 stars, by far the most I've ever had on any other repository I've open sourced, to which I'm extremely grateful for and I'm chuffed that it helped a few people get into open source. The website will be offline, probably by the time you are reading this and I'll archive the repository. 

Cheers!]]></content:encoded>
      <dc:date>2022-11-21T00:00:00+00:00</dc:date>
    </item>
    <item>
      <title>I do WordPress now</title>
      <link>http://localhost:4000/wordpress/2021/09/22/i-do-wordpress-now</link>
      <description><![CDATA[
]]></description>
      <pubDate>Wed, 22 Sep 2021 00:00:00 +0100</pubDate>
      <guid>http://localhost:4000/wordpress/2021/09/22/i-do-wordpress-now</guid>
      <content:encoded><![CDATA[{% include JB/setup %}

<div class="standfirst" markdown="1">
I do a lot, pretty much all my work in WordPress these days. This post talks about how that came about, what it’s like working with WordPress from a code point of view and the ecosystem. I discuss on things like the use of globals, composer support as well as things I really like, such as WP-CLI. I also touch on the community and finally on the direction I think WordPress is going and my thoughts on that.

If you want a really succinct tl;dr it’s probably, I do WordPress and well, I like it.
</div>

From approximately 2012 - 2018 I was working predominantly, if not exclusively with [Symfony](https://symfony.com/). When we were pitching for a new e-commerce project in 2018 it therefore felt natural to reach for Symfony. I had used [Sylius](https://sylius.com/) a bit, and had high opinions of it, as did the people I spoke to about it too. Even if we went with a platform such as [Shopify](https://www.shopify.co.uk/), the APIs are so rich and Symfony’s tools for dealing with APIs so rich that this felt like not a problem too. Anyway, the pitch went really well and the client told us they were selecting us as their development partner for the project. Great news. 

> We want you to use WooCommerce.

We had looked into [WooCommerce](https://woocommerce.com/) as part of our analysis, but we had made the recommendation of Shopify and was fully expecting to go down that route. So WooCommerce it is! Since that point, I’ve pivoted pretty strongly to working predominantly, if not exclusively with WordPress. If you’re interested in more of the story of the project described above, you can check out the [talk I did at Bristol WP a few years ago](https://speakerdeck.com/jenkoian/from-zero-to-vip). For the remainder of this post though I want to talk about my experiences with WordPress over the last few years.

## Community
When first turning my focus to WordPress, I wanted to try and get a feel for the community a little bit. Luckily, there was a [local meet up](https://www.meetup.com/Cardiff-WordPress-Meetup/) happening mere days after discovering that I’d be working more with WordPress, so along me and a colleague went. 

It was a small, yet vibrant meet-up, what immediately stood out to me was how rich in diversity it was, not just in ethnicity and gender but also in age and ability. From professional developers who made their career in developing on WordPress to those less technical who just use WordPress to run their small business. It was certainly different to the tech meet-ups I’d attended previously and it was, well, lovely.

From there I attended another fairly local, but slightly bigger meet up, [Bristol WordPress People](https://wpbristol.co.uk/). Similar diversity, similar loveliness, really good food, like really good food. Sustainably sourced, all dietary needs met, you name it. So, a community that values..

* Diversity
* Sustainability
* Equity
* Good Food

Well, sign me up.

### WordCamp Europe
It would be remiss of me to talk about the WordPress community with out talking about an experience that I’ll remember for the rest of my life. In June of 2019 I attended my first WordCamp. [WordCamp Europe 2019 in Berlin](https://europe.wordcamp.org/2019/). 

I remember for years hearing about how WordCamps (and DrupalCons IIRC) are like these uber versions of conferences I’ve long been attending (Symfony Live’s and PHP Conferences mostly) but it wasn’t until experiencing one that I really knew what they meant. It was honestly incredible. I reckon even if you had little interest in WordPress you’d have a smashing time. Tons of sponsors offering activities and freebies, loads of people creating a nice atmosphere, lovely food, yoga classes, heck it even had a free creche!

<figure>
<img alt="Me with John Blackbourn @ WCEU 19" src="/assets/img/wceu19.jpg" />
<figcaption>Me hanging out with <a href="https://twitter.com/johnbillion" target="_blank">John Blackbourn</a> @ WCEU19</figcaption>
</figure>

The community knows how to party too, with the end of the event culminating in live entertainment and a big (80s themed) disco. So, reflecting on my points about the community again, we have:

* Diversity
* Sustainability
* Equity
* Good Food
* Knows how to party

Which funnily enough, would be my manifesto, should I ever move into politics. 

## The Codes
So I have to be honest, and I’m sure it comes of no surprise my impression coming into WordPress was that code quality was quite low. I was determined to keep an open mind and to keep any ego / elitism at the door though, which I think I have done, but I still think there are some observations to make. I’m going to touch on those now, I’m sure it’s nothing new to anyone who works with WordPress and I’ll touch on why this is likely the case later on too.

### The Bad

In a way I think WordPress is likely a victim of its own success. Built in an era where PHP was used [as a fractal of bad design](https://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/) it got so popular that it likely kept building and growing to the point it’s at today where it powers like 40% of the web or something. Over that time I think it’s fair to say it accrued quite a bit of technical debt without much in the way of payback.

Let’s just take a look at some of the things I found hard to deal with.

#### Globals...everywhere

I remember when I was first getting in to PHP (circa 2006) and one of the first things I learnt was to avoid globals like the plague. I wasn’t too sure why at the time if I’m honest but I’ve come to learn why over the years, among the many reasons is how hard it is to write tests, but more on that later.

#### Plugins

Plugins play a pivotal role in the world of WordPress, this isn’t necessarily a bad thing, but there are lots of them out there, and plenty of bad ones. I’m probably going to have this in the ‘The Good’ section (spoiler) but it’s here as well, purely due to the risk of a plugin completely breaking your site at any point, largely due to…

#### Hooksageddon 

WordPress has an extremely powerful extension system called hooks. There are two main types of hooks, filters and actions.

{% highlight php %}
<p>Hello <?php echo apply_filters( 'welcome_message_second_word', 'world' ); ?></p>
{% endhighlight %}

The above will output `Hello world` … or will it :notsureif: 

As there’s a hook (filter) around `world` it means any plugin/theme/project developer can change this value, e.g.:

{% highlight php %}
<?php
add_filter( 'welcome_message_second_word', fn( string $second_word ) => 'universe' );
{% endhighlight %}

So it will now say `Hello universe` … or will it :notsureif:

Unless of course a plugin uses the same hook with a higher priority. You can get around of course by changing your priority, or by adding some logic to only change it if the argument is a certain value or something, but, the point is, it can seem a little … wild, that at any point values can be changed multiple times by multiple plugins.

So that was a filter example, let’s have a look at an action:

{% highlight php %}
<p>Hello world</p>

<?php do_action( 'post_welcome_message_printed' ); ?>
{% endhighlight %}

Actions are more or less events, in the example above we’re essentially raising an event `post_welcome_message_printed` which plugins/themes/project developers can use to do … whatever they like - output a post welcome message template (maybe a gif or something), or send an email or, do some logging or whatever they want really. 

Similar concerns to the filter just slightly different in that it isn’t necessarily _changing_ a value, just performing an action. 

#### WP Query

Perhaps a little un-nuanced but `WP_Query` is horrific, I mean I’m sure it’s highly optimised and efficient and all that jazz, but just look at it 😱

[https://github.com/WordPress/WordPress/blob/25daf03a8ea95cf47b9f25ab40336a1f6501cff4/wp-includes/class-wp-query.php](https://github.com/WordPress/WordPress/blob/25daf03a8ea95cf47b9f25ab40336a1f6501cff4/wp-includes/class-wp-query.php)

If you look at `get_posts` specifically, then [this post from Tom J Nowell sums it up beautifully](https://tomjn.com/2013/08/12/wp_queryget_posts/).

#### Random other stuff

* Lack of namespaces which leads to best practices such as [https://developer.wordpress.org/plugins/plugin-basics/best-practices/#prefix-everything](https://developer.wordpress.org/plugins/plugin-basics/best-practices/#prefix-everything) (you can use namespaces I hasten to add, just that they aren’t completely ubiquitous)
* Lack of types which leads to functions returning things like `string|int|false` etc.
* Lack of unified autoloading which leads to loads of `require_once` calls or custom autoloaders all over the place
* Debugging can be difficult - particularly as you start stepping into hooks and things 

There’s probably other things too but I think you get the point.

### The Good

#### Extendability 

Ok, so the hook system can be problematic but it’s kinda cool you can customise almost anything! You have the power to turn WordPress into anything you want it to be, I think this is part of the reason WordPress has become so successful, particularly for agencies. 

#### Plugins

Related to the extendability, but there are plugins for almost anything, again you need to be _really_ careful to pick good ones, but you can really enhance the offering through plugins. [Multilingualpress](https://multilingualpress.org/) is a good example here, you get some really nice tools for providing a multilingual multisite with a relatively low footprint. 

#### Massive suite of functions

There is a huge number of utility and likewise functions in WordPress which come in really handy. One example that springs to mind is the HTTP functions, I saw [a good blog post on these recently over on DeliciousBrains](https://deliciousbrains.com/wordpress-http-api-requests/).

There are definitely others too, but this is a pretty neat example.

## The Ecosystem
WordPress is optimised for its users, not just the CMS but the entire ecosystem is user led, again another reason it’s likely so popular. This does make it challenging for a developer like me, particularly coming from Symfony which is very developer focussed. 

The WordPress ecosystem is focussed on empowering users of all abilities get up and running with a CMS or E-Commerce store, or whatever they want through ease of use. You want [a social media platform built on WordPress](https://buddypress.org/)? Sure, just upload this zip file!

Things which I’d come to take for granted to working with Symfony were no longer readily available. Let’s dig into some of that now.

### Git / Github

I love using Git and GitHub, it just feels so natural and easy to me. WordPress uses … Subversion and Trac, I used to use this too, a long time ago, and it was great at the time but things have moved on. There’s a strong element of ‘it works for them so why change?’ Going on, but I truly believe the WordPress ecosystem would gain so much if they moved wholesale to Git / GitHub. 

I should point out that WordPress _is_ on Github, you can submit a pull request however it won’t get merged:

> **Note:** Pull requests on GitHub will **not** be merged. Code changes are still required to be made to the SVN repository by trusted long term contributors granted commit access.
[https://make.wordpress.org/core/handbook/contribute/git/github-pull-requests-for-code-review/](https://make.wordpress.org/core/handbook/contribute/git/github-pull-requests-for-code-review/)

I don’t know how many contributors prefer GitHub over SVN but the fact they even have this an option suggests to me contributors at least would like to use Git/GitHub. 

The existing “SVN but you can use Github, but only kinda” is just convoluted, it makes it hard work to contribute, where do you even begin? Do you need to learn SVN? Why are there so many hoops compared to almost every other open source project out there?

I realise I’m fairly fresh to WordPress and maybe the current setup is like an old pair of slippers to the current core contributors, but this is my opinion looking at it with (fairly) fresh eyes.

### Coding standards

In a similar vein to the point above where WordPress seems to be different to the vast amount of other similar projects, this too rings true for the coding standards in WordPress. Again, I think they would benefit so much from adopting the standards adopted by the wider community. 

The wider PHP community has adopted PSR-1 and PSR-2 (now superseded by PSR-12) coding standards quite widely and for quite a while now, it just makes sense for WordPress to do the same? Or at least base their own standards from these, or at least just PSR-1. I’m not too familiar with the history but it seems it [was discussed years ago](https://core.trac.wordpress.org/ticket/23357), it made sense not to adopt given the support for PHP included 5.2 back then but I wonder if now given PHP 5.6 is the minimum supported version it might make sense?

It’s not too big a deal I guess, you quickly get used to tabs and extra spacing around brackets and stuff, but it just strikes me as yet another barrier for new contributors. Again though, the vast majority of existing contributors may not want to lose those comfy slippers, and I get that. 

### Composer

[Composer](https://getcomposer.org/) is by far the best thing to ever happen to PHP, heck, I’d argue it’s the best package manager there is. WordPress doesn’t have native support for composer, which again I think is a shame. There are some _excellent_ community tools out there though.

[WordPress Packagist](https://wpackagist.org/) mirrors all the plugins and themes listed on the WordPress directory and exposes them to composer through a custom packagist repository. It truly is fantastic, absolute hats off to [Outlandish](https://outlandish.com/), the company behind it. In the age of [mass WordPress acquisitions](https://poststatus.com/acquisitions/) I’m amazed Automattic haven’t acquired it. 

WPackagist makes it possible to install plugins and themes just as you would any composer package. WordPress plugins often come in premium flavours though which aren’t listed on the public directory and thus aren’t listed on WPackagist. Some of them (such as Yoast) offer up [custom repositories you can use for composer](https://yoast.com/help/how-to-install-yoast-plugins-using-composer/), but others do not. In this scenario, you have a few options such as [https://github.com/Rarst/release-belt](https://github.com/Rarst/release-belt) or [https://github.com/cedaro/satispress](https://github.com/cedaro/satispress) for example or you can set just include the plugins in your repository if all else fails.

### Dependency Injection

Coming from a Symfony background it was a bit of a shock to the system not having a [Dependency Injection Container](https://symfony.com/doc/current/components/dependency_injection.html) (DIC) at my disposal, everything in Symfony comes through the container pretty much. Singletons, where again much like globals you’re taught pretty early on ‘are bad mmmkay’ are quite common.

It is possible to use Dependency Injection (DI) and a DIC of course, as we have done on our [project skeleton we use in work](https://github.com/boxuk/wp-project-skeleton/blob/main/docs/dev/custom-code.md#dependency-injection), but as per composer and other things, it requires additional effort. 

### Testing

Unit Testing WordPress is hard work, mostly due to the way it relies so heavily on globals. The best way I’ve found around this is to wrap things heavily, so you can use DI for core functions and things and replace those with mocks in your tests. There is [WP_Mock](https://github.com/10up/wp_mock) too if you prefer to use a mocking framework.

Should we even bother unit testing? Possibly not, I like this quote from [Alain Schlesser](https://www.alainschlesser.com/) in the [Post Status](https://poststatus.com/) slack recently

> WordPress is like the toxic material you only can interact with through these protective barrier glasses with built-in gloves

So you probably want to unit test your custom code but find a way to decouple that from WordPress as much as possible so you don’t end up covered in toxic material. 

For those times where you want to test that your code is interacting with the WordPress bits ok, that’s where you’d want to move into integration testing.

There are some good libraries here. [WP PHPUnit](https://github.com/wp-phpunit/wp-phpunit) is good for providing factories and things to create data within your test, as well as to help with general test setup (installing WordPress etc.).

Beyond PHPUnit, you have [behat](https://docs.behat.org/en/latest/) which is used a fair bit in the community, [particularly by WP-CLI](https://github.com/wp-cli/wp-cli-tests). 

If you want to do more browser based testing, to ensure clicking buttons and things actually does what it’s supposed to, you should be able to use most/any UI testing framework, in work we’ve had some success with [Robot Framework](https://robotframework.org/) but more WordPress centric tools I’ve heard good things about include [WP Cypress](https://github.com/bigbite/wp-cypress)  and [Codeception with WP Browser](https://github.com/lucatume/wp-browser)

### WP-CLI

I’m not sure how long ago WordPress got WP-CLI but it is excellent. I’ve not dug too much into the internals, but I know using it is always a pleasure, it’s easy to extend and the (behat based) testing setup and tools are brilliant as well.

I’ve no idea how the WP-CLI was incepted and then executed but whoever was behind it deserves a lot of praise.

### WP Rest API

Similar to the WP-CLI, I’ve no idea when the Rest API aspect of WP was added, but again it’s excellent. The endpoints make sense, supports the necessary verbs as you might expect, is nicely queryable where it should be and is really easy to extend and customise. Once again, bravo.

### Other notable things

Some other notable ecosystem things I thought worth mentioning.

#### Dictator

Perhaps I’m biased because we use it heavily and have taken on the maintenance and development through our own fork, but I really think [Dictator](https://github.com/boxuk/dictator) is a nifty library. One thing I’m hoping to add at some point is the ability to run it in `pre_filter_` mode, so instead of replacing database values with the configuration set in the YAML file it will create the necessary `pre_filter_*` hooks instead. 

#### Flagpole

It’s a small little library just run by one guy, but [flagpole](https://github.com/jamesrwilliams/flagpole) is an excellent little feature flagging library in WordPress, we use it heavily at work and would recommend.

#### WP-CLI Fixtures

We used to run Alice fixtures in our Symfony projects in work, and we can do the same in WordPress thanks to a neat little WP-CLI package called [wp-cli-fixtures](https://github.com/nlemoine/wp-cli-fixtures). There are other solutions similar to this such as [FakerPress](https://en-gb.wordpress.org/plugins/fakerpress/) but I prefer YAML files for this sort of thing.

## Bringing PHP to a Javascript fight?
Almost everything I’ve talked about up until this point has been focussed on ‘classic’ WordPress or PHP centric WordPress, however there is a slow turning wheel that suggests that the future of WordPress is beyond PHP.

I think it started in 2015 where Matt Mullenweg suggested the community should [“Learn Javascript Deeply”](https://www.youtube.com/watch?v=KrZx4IY1IgU). Over 5 years since then, WordPress now has the [block editor](https://github.com/WordPress/gutenberg) built in [React](https://reactjs.org/), with [Full Site Editing](https://fullsiteediting.com/) just getting rolled out, which expands the use case of the block editor even further. The other big thing happening in WordPress right now is [Headless WordPress](https://www.gatsbyjs.com/docs/glossary/headless-wordpress/), with a [number](https://github.com/wpengine/faustjs) [of](https://frontity.org/) headless frameworks and approaches being pushed, all of which are Javascript based. 

There’s so much in WordPress that I can’t see PHP being eradicated from WordPress too soon, but it does feel like they are [strangling](https://www.boxuk.com/insight/minimal-disruption-maximum-gains-applying-the-strangler-pattern-to-legacy-software/) away classic WordPress and honestly, I can’t say I blame them.

I started off this post hinting at the massive amounts of tech debt that existed in WordPress and I’ve often [gone on about the virtues of strangling a legacy application](https://www.boxuk.com/insight/archived-from-legacy-to-new-the-anfield-approach/) that it makes sense? That’s not easy for me to say either given that I’m a PHP developer mostly. I’ve not used either the block editor or headless WordPress enough at this point to give a full opinion on either, but learning React has long been on my to-do list, so maybe this will provide the opportunity? Having said that, I would like to see a headless WordPress approach which isn’t Javascript based. I would like to see an approach using something like [Hotwire](https://hotwired.dev/) or [HTMX](https://htmx.org/) with a PHP backend. It makes me wonder if something like that would make it easier to use the wider plugin ecosystem in a headless setup. Again though, I’ve not used either of those technologies enough to give a firm opinion.  I do think it’s all very exciting though.

## Summary
Well this post was way longer than I expected, sorry about that. I realise I’ve ripped at WordPress a bit in places, but I hope that’s not the stand out element of this post. I was trying to be constructive in any criticism and I completely understand why the situation with a lot of these things is like it is. If anything, I want the summary of this post to be that, I like WordPress, I enjoy the community, I enjoy the power it enables in delighting the clients I work with, I enjoy the challenge of trying to bring best practice into it, I’m intrigued with the future direction, I’m hopeful I can eventually improve my React skills through the block editor and/or headless approaches. 

I feel like I’ve barely scratched the surface in what I’ve learnt from day zero until now of working with WordPress. On the face of it, I can understand why developers might be put off, but peel back some of the layers and I think you’d be surprised, there are good people doing good things in WordPress and there’s no reason that couldn’t be you. Oh and attend a WordCamp (when safe to do so) it will blow you away.
]]></content:encoded>
      <dc:date>2021-09-22T00:00:00+01:00</dc:date>
    </item>
    <item>
      <title>The Developer CV</title>
      <link>http://localhost:4000/opinion/2018/08/24/the-developer-cv</link>
      <description><![CDATA[
]]></description>
      <pubDate>Fri, 24 Aug 2018 00:00:00 +0100</pubDate>
      <guid>http://localhost:4000/opinion/2018/08/24/the-developer-cv</guid>
      <content:encoded><![CDATA[{% include JB/setup %}

<div class="standfirst" markdown="1">
 I put myself off writing this post for a long time due to fear as coming across a bit ostentatious (isn't it ironic that the word ostentatious is itself very ostentatious, anyway..) however, [I came across this medium post](https://medium.com/@dominicwhite/i-hire-software-developers-your-resume-is-the-reason-youre-not-getting-interviews-dc7b2520a2f1) recently and as it aligns quite closely to my own thoughts I thought I may as well publish. Hopefully, someone will find it useful, if it just comes across as me being picky then fair enough.
 </div>

I've been reviewing developer CVs a fair bit over the last few years, due to a recent recruitment drive, even more so over the past week or two. I don't work for a big silicon valley tech giant or anything like that, but there are some little things which I see time and time again which I'd like to just pass comment on, I guess you could call them 'tips' but I dunno, just things I've noticed.

## Length & Girth

This isn't anything new, I'm sure I got told this in year 11 careers advice class but there is absolutely no reason whatsoever to have a CV more than 1 page. 2 pages at an absolute push, anything more than 2, the person reading that CV is already resenting you. 

At the risk of coming across harsh, nobody cares that you got an A at GCSE French and worked one summer in Tesco Express. Keep it relevant, read the job ad and show off what skills you have in order to do that job.

You don't need to list every job you've ever done, only the last (most relevant few) even then you don't need to list everything about each job. Maybe go into a bit of detail about your current/previous role but roles before that, just list the achievements.

## Get the order right

I've seen so many CVs that start off with qualifications at the top (in chronological order) followed by experience, then finally touching on skills. This is completely backward to me. You want to start the CV with the headlines, the things that are going to have the person at the other end take notice and want to finish reading your CV. Go skills first, read the job ad. If the ad suggets it is looking for developers with experience in Symfony, start off your CV showing off everything you know about Symfony and surrounding ecosystem.

## Go easy on the buzzwords

If you're reading a CV and the person has done nothing more than list a bunch of technologies/buzzwords, you're gonna think they've just put it on the CV for the sake of it, if I see a big list of tech with little to no explanation of any it's an immediate red flag for me. What is much much better is a small set of relevant technologies with an explanation next to each one as to how you used that tech to solve a problem.

## Keep it simple

Black text on white is absolutely fine, preferred even. You don't need to make your CV look like a website, it doesn't need colour, those things are merely a distraction (possibly different if you're going for a design role?).

Some people include a picture of themselves, if you can do it in a subtle way without causing a distraction then fine, but I don't think it's particularly necessary to include a pic.

Oh and for the love of god don't submit a CV in a proprietary format, this includes Microsoft Word. Just use PDF if in any doubt.

## My ideal CV

Prob easier if you just see what I think would be my ideal CV:

---

<script src="https://gist.github.com/jenkoian/c2b0809aa2abd11d8bf5ced6adf837ea.js"></script>
]]></content:encoded>
      <dc:date>2018-08-24T00:00:00+01:00</dc:date>
    </item>
    <item>
      <title>From Gaufrette to Flysystem and back again</title>
      <link>http://localhost:4000/legacy/2017/03/07/from-gaufrette-to-flysystem-and-back-again</link>
      <description><![CDATA[
]]></description>
      <pubDate>Tue, 07 Mar 2017 00:00:00 +0000</pubDate>
      <guid>http://localhost:4000/legacy/2017/03/07/from-gaufrette-to-flysystem-and-back-again</guid>
      <content:encoded><![CDATA[{% include JB/setup %}

When I saw [Gaufrette added a Flysystem adapter](https://github.com/KnpLabs/Gaufrette/pull/390) (a year ago to this day!) 
it somewhat captured my imagination and it seemed only right that [Flysystem should have a Gaufrette adapter](https://github.com/jenkoian/flysystem-gaufrette) and the two 
file-system abstraction layers could work completely bi-directional. 

It was mostly a bit of fun, although I could potentially see a use case even if that use case hadn't crept up on me yet.
**Until now!**

I recently worked on a legacy project which made use of [Gaufrette](https://github.com/KnpLabs/Gaufrette) and we were taking [my favourite approach to tackling legacy](https://twitter.com/ziobrando/status/675305573127208960).
We were working completely on new code and writing adapters to old stuff which handled a lot of the existing heavy
lifting. So, in the case of file-system abstraction we were writing an adapter to the old Gaufrette stuff, 
but due to a few reasons we were also keen on trying to make use of [Flysystem](https://github.com/thephpleague/flysystem). 
Then I remembered, this silly little library I had created!

*"You mean we could work with Flysystem whilst not having to rewrite all of these touch points with Gaufrette"*

We were using Symfony, so actually used [this bundle](https://github.com/1up-lab/OneupFlysystemBundle) to hook up Flysystem but essentially it just worked like this:

<script src="https://gist.github.com/jenkoian/b2c40bc307d30a4e398935382fb67812.js"></script>

Pretty neat! 

Obviously, having two file-system abstraction layers is a bit pointless, so eventually it would be nice to completely
move away from Gaufrette, but as a nice compromise to ease over the transition this came in really handy.

So if you're in a similar boat and want to transition from Gaufrette to Flysystem give my silly little library a try.

Finally, I'm not advocating that Flysystem is better than Gaufrette or anything, just that our needs for this particular 
project meant Flysystem was a better fit. They are equally as good as one another and I'm sure in some scenarios Gaufrette 
might have the edge. Indeed, if you wish to transition in the other direction you can always use the [Gaufrette Flysystem adapter](https://github.com/KnpLabs/Gaufrette/blob/master/doc/adapters/flysystem.md) :).




]]></content:encoded>
      <dc:date>2017-03-07T00:00:00+00:00</dc:date>
    </item>
    <item>
      <title>Retro fitting Symfony Security into a Legacy App</title>
      <link>http://localhost:4000/legacy/2016/03/21/retro-fitting-symfony-security-into-a-legacy-app</link>
      <description><![CDATA[
]]></description>
      <pubDate>Mon, 21 Mar 2016 00:00:00 +0000</pubDate>
      <guid>http://localhost:4000/legacy/2016/03/21/retro-fitting-symfony-security-into-a-legacy-app</guid>
      <content:encoded><![CDATA[{% include JB/setup %}

In [my last blog post](http://jenko.me/legacy/2016/02/03/an-escape-route-from-legacy-with-stackphp-and-the-symfony-microkernel/) I talked about how I had escaped legacy by leveraging the Symfony MicroKernel as well as the new Guard authentication component. Once this was all in place, my next task was to migrate the legacy, home-baked, role based access control to Symfony, so I could make extended use of [Symfony’s fantastic Security component](http://symfony.com/doc/current/book/security.html).

## Roles & Permissions

Having evaluated the current state of play with regards roles and permissions, I had determined that something akin to the following was at play:

|                | Add Content   |  Moderate Content | Edit User |
|----------------|:-------------:|:-----------------:|:---------:|
| ROLE_EDITOR    | x             |                   |           |
| ROLE_MODERATOR |               | x                 |           |
| ROLE_ADMIN     |               |                   | x         |

Now I knew which roles and permissions I needed to set up, there was going to be two ways in which I needed to protect the app. 

* Routes - stop users from seeing content should they navigate to a URL that is protected.

* Template - stop buttons etc... displaying if the user doesn’t have permissions to perform the action the button performs.

## Route protection

Securing routes in Symfony is actually quite easy. Just some basic configuration and that’s pretty much it!

<script src="https://gist.github.com/jenkoian/3f38b15298517f99e07b.js"></script>

However, in my scenario it wasn’t quite this easy. I needed to give the client a simple way to be able to tweak the permissions each role has. So for example, editors may be given the ability to  moderate content at some point. In most applications you’d probably say, just give the editor the  moderator role in that case, but due to the legacy nature and the fact there are many roles and permissions, simply giving a user an extra role, although possible, may be ill-advised. Therefore, the access control in my scenario needed to be something like the following:

<script src="https://gist.github.com/jenkoian/098695ae18feb8a5c67d.js"></script>

In other words, I needed the permissions to be mapped to the routes rather than the role. 

To achieve this I needed to use a custom RequestMatcher as described in this [excellent blog post from Matthias Noback](http://php-and-symfony.matthiasnoback.nl/2012/07/symfony2-security-using-advanced-request-matchers-to-activate-firewalls/). For this to work I simply set up a static map of permissions to roles, I used a php array, but could just as easily be yaml, xml, whatever.

<script src="https://gist.github.com/jenkoian/5fda9fad505e12186bb5.js"></script>

My `RequestMatcher` then looked something like:

<script src="https://gist.github.com/jenkoian/e5c4d717b2cdb1d8bd97.js"></script>

Then as Noback points out, this all gets configured via a compiler pass:

<script src="https://gist.github.com/jenkoian/bf5ff2c80179b0583285.js"></script>

With that in place the next thing to do was to write a custom  `PermissionUrlVoter` to vote on whether the user can access the route or not. As we’re not using roles anymore, the core `RoleVoter` will abstain from the vote so we need to make sure we have something in it’s place. Here is my custom voter:

<script src="https://gist.github.com/jenkoian/3d7810e8fba57006994b.js"></script>

`getConfigurationRoleMap()` basically extracts roles form a configuration file. The configuration file in question, looks something like:

<script src="https://gist.github.com/jenkoian/aa182c799aec96f30bed.js"></script>

This allows the client to easily see which permissions apply to which role(s) and, if you throw in a basic page with an [ace-editor](https://ace.c9.io/) on, make changes to. 

So all done on route protection right? Well, pretty much. As I have my Symfony application sat alongside the legacy application using [Stack](http://stackphp.com/), it basically attempts to hit the route in the Symfony app, if it encounters a `NotFoundException` falls back to the legacy application. The problem with this is that Symfony will forgo the security stuff completely if the route simply doesn’t exist in the Symfony app. The solution for this was relatively straight forward. Define a ‘catch all’ route in the Symfony app so that each request will get through the Symfony routing and into the Security system. It will of course throw a `NotFoundException` eventually when it realises there is no controller set up for the route.

<script src="https://gist.github.com/jenkoian/53ed3a789380d2b94015.js"></script>

This should go beneath any routes you currently have set up in the Symfony app so they continue to work as expected.

## Template protection

For the template protection, Symfony has a wonderful Twig extension which allows you to easily wrap things you want to protect, for example:

<script src="https://gist.github.com/jenkoian/ffe15e8d271e6b7877e1.js"></script>

In our Symfony application we can use this, with the caveat being that again we want to check permissions rather than roles, e.g.:

<script src="https://gist.github.com/jenkoian/b61c7a2dd30fd9381dd9.js"></script>

For this to work we require another custom voter:

<script src="https://gist.github.com/jenkoian/8f251a75ee55549a4b6f.js"></script>

This basically checks the users’ role, checks it against the configuration file and votes accordingly.

So now we have working template protection in the Symfony app, but how about the legacy app? Well, unfortunately it isn’t using Twig so we can’t use the nice Twig extension, nor does it know anything about the Symfony application at all, so we can’t easily grab things out of the container or anything. 

My solution was to create a static facade into the Symfony security bit that does the `is_granted` check. For this to work, I ended up having to use the (sorry mum) global keyword to expose the kernel to the legacy app.

<script src="https://gist.github.com/jenkoian/948437a9a5fa56824627.js"></script>

This allows us to use the following in the legacy code ‘templates’ and well just about anywhere we need to check permissions really:

<script src="https://gist.github.com/jenkoian/869a5e9848921a127801.js"></script>

## That’s it!

That’s pretty much it as to how I started using the extremely powerful Symfony security in the legacy application I’m working with. The roles and permissions are currently set and updated via a configuration file. The next step though, now that we have all our security features in the Symfony ecosystem would be to look to have some kind of ACL editor.

### Testing

One last thing I wanted to touch on is testing. 

[Symfony voters](http://symfony.com/doc/current/cookbook/security/voters.html) are quite easy to test, I’d recommend looking into [how some of the core voters are tested](https://github.com/symfony/symfony/blob/master/src/Symfony/Component/Security/Core/Tests/Authorization/Voter/RoleVoterTest.php) if interested in this. Ideally though, you’d have some functional tests which tested the routes that are protected before the security was migrated to the Symfony stuff, i.e. go to this page with this user and make sure you get a 403 response then try with this user and make sure you get a 200 response. 

Another neat thing you could do is use [Scientist](https://github.com/daylerees/scientist) to perform ‘experiments’ of this new security code against the existing ‘controlled’ code. This would allow you to ‘trial’ this new security code in production before rolling it out for real. It has things such as journals and reports to allow you to see how your new approach is working out, whether it’s performing in unexpected ways for instance or if it’s performing slower than it’s counterpart. 
]]></content:encoded>
      <dc:date>2016-03-21T00:00:00+00:00</dc:date>
    </item>
    <item>
      <title>An escape route from legacy with StackPHP and the Symfony MicroKernel</title>
      <link>http://localhost:4000/legacy/2016/02/03/an-escape-route-from-legacy-with-stackphp-and-the-symfony-microkernel</link>
      <description><![CDATA[
]]></description>
      <pubDate>Wed, 03 Feb 2016 00:00:00 +0000</pubDate>
      <guid>http://localhost:4000/legacy/2016/02/03/an-escape-route-from-legacy-with-stackphp-and-the-symfony-microkernel</guid>
      <content:encoded><![CDATA[{% include JB/setup %}


<em class="prologue">I came to, slightly dazed, I was cold and confused, where am I? I tried to take in my surroundings, reams of commented out code to my left, singletons to my right. I don’t know how I got here, but I knew at that point. I was. I was in legacy hell.</em>

Although developers generally want to always be working with the latest and greatest, the new shiny if you will, it can’t always be fresh daisies and green fields, every now and again, in fact, probably more often than not, developers have to deal with legacy code, i.e. code written in the past, either by an (*obviously inferior*) dev, or even worse themselves. 

Yep, legacy is some what of an occupational hazard. So when I had recently taken ownership of a particularly iniquitous legacy codebase, I wanted to steer clear of it as much as I could, poke it with a stick, give it snide looks, that kind of thing. So this is how I managed to work with modern tech whilst fighting this thankless battle.

## Using StackPHP to separate the old from the new

[StackPHP](http://stackphp.com/) is a convention for composing middlewares in PHP. It works with Symfony’s HttpKernelInterface and basically allows you to apply decorators to your application. This idea has become so popular in the PHP community that a [PSR standard has been adopted](http://www.php-fig.org/psr/psr-7/) with one of the aims to make it easier to build standardised middlewares. 

We can make use of this approach to easily split requests between a legacy codebase and something more modern, like a Symfony app. Carlos Buenosvinos wrote a brilliant blog post about this which is required reading if this post is proving of any interest: [http://carlosbuenosvinos.com/migrating-progressively-to-symfony-without-pain-with-stackphp/](http://carlosbuenosvinos.com/migrating-progressively-to-symfony-without-pain-with-stackphp/)

<script src="https://gist.github.com/jenkoian/641dcca3e47fc321825e.js"></script>


## Where the MicroKernel fits in

The legacy codebase I was dealing with was already large and convoluted with many directories and sub-directories. Adding in an app, a web, a src and whatever other directories seemed overkill and counter intuitive. I know that’s a minor detail and I could have just put them in a separate directory under the root and all probably would have been fine, but even so I wanted to bring in Symfony with the lowest foot print I could. 

Despite always being able to be used as a micro framework, Symfony formally introduced [‘Symfony as a Microframework’](http://symfony.com/blog/new-in-symfony-2-8-symfony-as-a-microframework) with a  new MicroKernel trait which allows you create an entire Symfony application from a single class. This fitted my use case perfectly, as it meant I could have a fully functional Symfony with minimal number of files. What was also really nice was that it could grow along with the development of the app. As I start to do more and more work in the Symfony part of the application the more of the framework I can use and the more files and directories I can create.

<script src="https://gist.github.com/jenkoian/6e00d8a8569ce4afa99f.js"></script>

So now I have this lightweight, small footprint Symfony app I needed it to fit in with the legacy app. To the user it should be transparent. On the whole this wasn’t too difficult, the main structure of the page was just HTML which I could just copy into some simple twig templates. The layout did have a few complicated bits though. Firstly, a global language switcher.

## Changing the locale across the entire app

As the existing legacy app already had a mechanism for setting and changing locale, we needed to hook into that in order to set the locale for our Symfony app. This was fairly trivial via a listener. 

<script src="https://gist.github.com/jenkoian/f79c6984eba54271d7b4.js"></script>

It’s worth noting here the importance of creating interface and adapters for everything we do with regards the legacy app (and in general really). By doing so we can quite easily swap out the implementation to something newer when we no longer need to support the legacy app. It’s also a great way of ensuring we can add tests without relying on legacy classes. It’s a good refactoring technique too, in his [seminal book on legacy](http://www.amazon.co.uk/Working-Effectively-Legacy-Michael-Feathers/dp/0131177052), Michael Feathers refers to this as the ‘Extract Interface’ technique.

## Authenticating the user across the entire app

The last thing I needed to do was handle authentication. It needed to work seamlessly across both the legacy side of the application and the Symfony application.

The [security component](http://symfony.com/doc/current/book/security.html) within Symfony is super flexible but can be a complicated beast. Fortunately, some work was recently undertaken to simplify it a little and a new component called [‘Guard’](http://symfony.com/blog/new-in-symfony-2-8-guard-authentication-component) was created to help.

There is an excellent cookbook entry on [‘How to Create a Custom Authentication System with Guard’](http://symfony.com/doc/current/cookbook/security/guard-authentication.html) which gave me everything I needed. I was basically treating the legacy authentication system like a third party API in this case. It boils down to creating the following: A User class, a UserProvider class, and an Authenticator class. All is covered in excellent detail in the cookbook entry and the [docblock of the GuardAuthenticatorInterface](http://api.symfony.com/3.0/Symfony/Component/Security/Guard/GuardAuthenticatorInterface.html). Here’s mine.

<script src="https://gist.github.com/jenkoian/731628f51b1ea89002e9.js"></script>

<script src="https://gist.github.com/jenkoian/e66744a3af7125e5670f.js"></script>

<script src="https://gist.github.com/jenkoian/9dacbc175bf6fd163096.js"></script>

Most of it is self explanatory and explained well in the documentation. One thing to note for my use case is the following. 

<script src="https://gist.github.com/jenkoian/33e87298a93f5eb17f02.js"></script>

This is a simple method which maps roles from the existing authentication system to the new User class used by Symfony. This will ensure the user in Symfony land has the appropriate roles set and means you can make use of Symfony features such as [Voters](http://symfony.com/doc/current/cookbook/security/voters.html) and what not.  It means you can do things like `if is_granted(‘ROLE_MODERATOR’)` and also use the access control stuff which you can see in the security config in AppKernel.

So now we have all the elements for the Guard authentication it’s time to hook it all together with some basic config. Here is mine:

<script src="https://gist.github.com/jenkoian/e8a6d4f908c314e8c3f7.js"></script>

As you can see we have access to all the powerful features of the Symfony security component with only a few small classes and crucially, without making any changes to the existing codebase or functionality.

## Summing up

When faced with the original daunting task of taking on, maintaining and adding new features to this spaghetti bolognese of legacy code I was worried. Having used some OOP techniques and with help from a few nice PHP and Symfony libraries, I feel not only less worried about the future of this project but also enthused and, dare I say, excited to work on it.

Finally, I saw a tweet just before starting this piece of work which summed up perfectly what I was hoping to achieve and I think sums up this blog post perfectly as well.

<blockquote class="twitter-tweet" data-lang="en"><p lang="en" dir="ltr">How do you make greenfield project with legacy? 1. pretend you&#39;re greenfield 2. write an adapter.</p>&mdash; Alberto Brandolini (@ziobrando) <a href="https://twitter.com/ziobrando/status/675305573127208960">December 11, 2015</a></blockquote>
<script async src="//platform.twitter.com/widgets.js" charset="utf-8"></script>
]]></content:encoded>
      <dc:date>2016-02-03T00:00:00+00:00</dc:date>
    </item>
    <item>
      <title>Memoirs of a UDiffer</title>
      <link>http://localhost:4000/opinion/2015/09/17/memoirs-of-a-udiffer</link>
      <description><![CDATA[
]]></description>
      <pubDate>Thu, 17 Sep 2015 00:00:00 +0100</pubDate>
      <guid>http://localhost:4000/opinion/2015/09/17/memoirs-of-a-udiffer</guid>
      <content:encoded><![CDATA[{% include JB/setup %}

This evening will see the 34th(?) and final [Unified Diff](http://unifieddiff.co.uk). Unified Diff, or  UDiff as us old timers call it, has been a staple part of my life for the past 3 and a bit years so I wanted to take a bit of time to write up some of my experiences/memoirs of this time. An Ode to UDiff if you will.

Unified Diff is a local tech meetup in my home (ish) city of Cardiff (gerrit?). It was started by 5 of the smartest guys I’ve ever had the pleasure of working with. In size order: [Carey](http://twitter.com/handybitesize), [Gavin](http://twitter.com/gavd_uk), [Craig](http://twitter.com/craigmarvelley), [Rhodri](http://twitter.com/rodnaph), [Warren](http://twitter.com/woogoose).

I somehow managed to worm my way in to make it a 6some, which was kind of an honour. I didn’t want to take such an event for granted so tried to help out as much as I could with the website and filming and what not, and for them to recognise that and get me on board meant a lot.

## The Early Years

Back in 2012, a tech meet up in Cardiff was badly needed, other than the smaller niche meet ups like [SWLUG](http://swlug.org.uk/) and [Cardiff RB](http://www.cardiffrb.com/) there wasn’t really anything to serve the wider tech community. UDiff aimed to fill that void. 

The first couple of meet ups were fantastic. We chose a small O’Neills bar, which worked out quite well. In fact I think, for me at least, this was the golden generation of UDiff, I really enjoyed the ‘bar camp’ feel of them which I don’t think we managed to recreate elsewhere. It allowed people to relax, have a drink, get some food if they wished. It also had a good screen and was a perfect size.

<iframe class="iframe-video" src="//player.vimeo.com/video/36267777?title=0&amp;byline=0&amp;portrait=0" width="600" height="400" scrolling="no" frameBorder="0"> </iframe>

There were many good talks throughout the O’Neills days, from interesting panel discussions with legends like [Stu Herbert](http://twitter.com/stuherbert) and [Richard Gaywood](http://twitter.com/penllawen), to grand reveals of MySpace projects that never materialised.

The other thing about O’Neills is that it gave me my first experience of public speaking. I had came up with a (somewhat silly) talk idea on a long car journey. 

I had started looking into front end tools a little bit having been solely interested in server side stuff previously so thought I’d give a quick run down of what the in tools were at the time. Nothing too technical just a nice little overview of tools and techniques that were previously completely new to me. 

I wanted to inject a bit of personality into a pretty dull topic so I came up with the title ‘Frontend Awesome SHit Any Nerd can Use’ or ‘FASHANU’ if you will. It basically allowed me to sprinkle in a bunch of [John Fashanu](https://en.wikipedia.org/wiki/John_Fashanu) facts and anecdotes to keep the audience from falling asleep. What I thought would be really fun was if I could actually get John to turn up (!?) as a surprise guest and although I knew it was a long shot I thought I’d give it a go anyway. Here is the email exchange between me and his agent in it’s entirety (with some redacting):

<script src="https://gist.github.com/jenkoian/b99a7a12527a89dbf9dd.js"> </script>

So no luck with John Fashanu but the talk went well even though I had a cold and my boss decided to turn up and crank my nerves up to 11 just before hand.

<iframe class="iframe-video" src="//player.vimeo.com/video/42411606?title=0&amp;byline=0&amp;portrait=0" width="600" height="400" scrolling="no" frameBorder="0"> </iframe>

## The Awkward Adolescence 

After Warren and Carey managed to get us barred from O’Neills (and a speaker pulling out of talking because the whole experience ruined his zen) we embarked on our teenage phase by meandering around a few venues. 

There were a few flash in the pan venues such as the Promised Land, which was decent but a little small and required Rod to haul a projector half way across Cardiff. Followed by Fire Island (now the [Urban Tap House](http://www.urbantaphouse.co.uk/)) which I think held a few events. My good friend [Aurélien](http://twitter.com/a_thieriot) talking about [Scala](http://www.scala-lang.org/) in the pitch black is a fond memory as is my second go at public speaking when I talked about Breaking Bad, I mean [Bugs](http://jenko.me/breaking-bugs).

<iframe class="iframe-video" src="//player.vimeo.com/video/83349876?title=0&amp;byline=0&amp;portrait=0" width="600" height="400" scrolling="no" frameBorder="0"> </iframe>

We then settled on [Porters](http://www.porterscardiff.com/) for a time, which was pretty good. They had a small cinema-esque room which worked well, but the the venue wasn’t free and was a small walk outside of the city centre. There were some brilliant talks there though, [one that sticks in the memory](https://vimeo.com/83487514) is [Dayle Rees’](http://twitter.com/daylerees) introduction to [Laravel](http://laravel.com) with a live (not actually live) link up with it’s creator [Taylor Otwell](http://twitter.com/taylorotwell).

![Cinema Room in Porters]({{ site.url }}/assets/img/600_306200662.jpeg)

## Settling down

The tail end of 2013 saw the opening of a great new collaborative open space for creatives in Cardiff called [Founders Hub](http://foundershub.co.uk). It had a small stage area with projector, PA and good lighting. It was basically the perfect venue for us. This was to become our home for the next year and a bit.

UDiff & Founders Hub felt like a match made in heaven. We were all geeks talking geeky stuff together in a place decked out for geeks (there were floppy disks blue tacked to the walls for Pete’s sake!). Attendances here were good, [Craig](http://twitter.com/craiginwales) and [Amie](http://twitter.com/amienlockwood), the owners of Founders Hub, often kindly ran a small bar and the space was great for chatting to people and getting to know one another.

![UDiff @ Founders Hub]({{ site.url }}/assets/img/600_377102622.jpeg)

There were some great talks here on a wide range of topics from [3D printing](https://vimeo.com/106176421) to [SEO](https://vimeo.com/99744479) to the incredibly successful ‘AWS night’. If I had to pick a favourite talk from this era it was probably [James Cryer’ talk on ‘Janky’](https://vimeo.com/90738845) as it opened my eyes up to stuff I didn’t really know about yet.

Everything at Founders Hub felt right, it was all just so easy and we had settled in to it as our natural home. It was therefore a big shame when Founders Hub announced they were closing at the end of April 2015. Not only a great shame for us but for the creative/tech industry in Cardiff as a whole. We must give thanks to Craig and Amie though for everything they did for us and hope their new ventures are working out well.

## The Twilight Years

With Founders Hub gone, the future of UDiff was up for discussion and although we came close to calling it a day then, we decided to keep it going and we got lucky with a [local recruitment company](http://www.acornpeople.com/) offering us a space to run the meet ups with free food and drink. We had been nervous of including recruiters in the past due to the ‘from the community, for the community’ vibe we were going for but we were ensured that there would be minimal sales speak or ‘networking’ and to be fair they were true to their word.

Although a good size, the venue at Acorn wasn’t perfect. The projector wasn’t brilliant and we struggled a bit with the lighting, particularly as it was Summer. However, the food and drinks provided were brilliant and I’m sure helped get people involved. Also, there were some really strong talks. In fact looking back I don’t think there were any weak ones, they were all really really strong and I’m struggling to pick a favourite but I think [Warren’s talk on Monads](https://vimeo.com/133746104) stands out to me, mainly because I really liked his ego-free explanation of it all. 

<iframe class="iframe-video" src="//player.vimeo.com/video/133746104?title=0&amp;byline=0&amp;portrait=0" width="600" height="400" scrolling="no" frameborder="0"> </iframe>

We also got to experiment with using [Periscope](https://www.periscope.tv/) for live streaming the events at Acorn and it was fun and worked well. Whether people actually tuned in and got much out of it I’m not sure, but it was certainly fun to do and see people pop up on my phone.

## The Quizzes

A small aside here to talk about one of my favourite bits of UDiff history, the Christmas Quizzes. They were absolutely brilliant fun and if anyone runs a local meet up I highly suggest you do a quiz at some point. We tended to arrange ours for our Christmas meet up and had such rounds as ‘O’Rly - name the O’reilly book from it’s redacted cover’, ’Guess the legend - guess the famous computer scientist from a picture of them’, ‘Tweet or false - whether tweets from famous computer people were real or fake’ as well as the obligatory regex section. If UDiff does come back in any fashion, I really hope we are able to do some more quizzes.

## Favourites

### Favourite talk

[Gav D’s clean code talk](https://vimeo.com/36714130). A must watch for anyone interested in becoming a programmer IMO.

<iframe class="iframe-video" src="//player.vimeo.com/video/36714130?title=0&amp;byline=0&amp;portrait=0" width="600" height="400" scrolling="no" frameBorder="0"> </iframe>

### Favourite venue

O’Neills. The whole bar camp feel was great.

### Favourite speaker

[Richard Gaywood](http://twitter.com/penllawen). Spoke confidently and really knew his stuff.

### Favourite moment

[Aurélien](http://twitter.com/a_thieriot) talking about Scala in the dark. Unfortunately not recorded :(

## See you later

To sum up, UDiff has been brilliant over the 3 (nearly 4) years it has been running. It has felt like mission accomplished in many respects as there are now loads more tech meet ups in Cardiff which I like to think UDiff at least influenced. 

The timing of all this seems apt. All the guys organising are in a much different place to where they were when all this started, people have got married, had babies and so on. It’s a lot harder to find the time and energy basically. 

However, I think we’re going out on a high and you never know, there could be a come back. With that in mind, I’ll end this with how Craig so succinctly put it in our email thread about this decision:

"Let’s just do an indefinite hiatus like all the best bands do."

![Craig & Rod]({{ site.url }}/assets/img/600_276671772.jpeg)
]]></content:encoded>
      <dc:date>2015-09-17T00:00:00+01:00</dc:date>
    </item>
    <item>
      <title>Building a house with DDD</title>
      <link>http://localhost:4000/ddd/2015/01/23/building-a-house-with-ddd</link>
      <description><![CDATA[For the past, I dunno, year or so, I’ve been reading a lot about Domain Driven Design (DDD) and even got to try it out on some projects. There are a number of resources which helped me out with this journey, but there are two stand out resources which really got me into it.

]]></description>
      <pubDate>Fri, 23 Jan 2015 00:00:00 +0000</pubDate>
      <guid>http://localhost:4000/ddd/2015/01/23/building-a-house-with-ddd</guid>
      <content:encoded><![CDATA[For the past, I dunno, year or so, I’ve been reading a lot about [Domain Driven Design (DDD)](http://en.wikipedia.org/wiki/Domain-driven_design) and even got to try it out on some projects. There are a number of resources which helped me out with this journey, but there are two stand out resources which really got me into it.

The first was [Ross Tuck’s excellent talk about Models & Service Layers](https://www.youtube.com/watch?v=ajhqScWECMo), if you haven’t watched it yet, then definitely, definitely do. This got me thinking about the tactical parts of DDD such as commands, handlers and [CQRS](http://martinfowler.com/bliki/CQRS.html).

Having opened up a journey into trying out this new approach, reading [red](http://www.amazon.co.uk/Implementing-Domain-Driven-Design-Vaughn-Vernon/dp/0321834577) and [blue](http://www.amazon.co.uk/gp/product/0321125215/ref=pd_lpo_sbs_dp_ss_1/277-9653975-7643565) books and basically being stoked about it all, along came an article from [Everzet](http://everzet.com/) called [‘Introducing Modelling by Example’](http://everzet.com/post/99045129766/introducing-modelling-by-example) which took my understanding one step further and helped me understand how BDD fits in with all this.

Everything seemed to be clicking into place and so I wanted to try it all out. See if this approach worked for me. So I came up with a silly example project to ‘Build a house with DDD’ - note: the title could easily have been ‘Build a house with Modelling by Example’ or ‘Build a house with BDD’ or even ‘Build a house with TDD’ ([as BDD is what TDD is supposed to be right](http://vimeo.com/68375232)).

## So here is how I built a house using DDD

*Note: I thought it’d be cool to do this commit by commit, gives a nice view of how each change was made etc. Unfortunately I only thought of this half way through writing it, so I am basically now the king of rebasing. Anyway, after I did this I came across [a similar project created by Everzet which takes a similar approach](https://github.com/MarcelloDuarte/pick-my-talks), it’s probably a better example of Modelling by Example (it was his thing after all!), although it doesn’t cover Command Handling etc. it’s __definitely__ worth checking out.*

[Version0](https://github.com/jenkoian/ddd-house/commit/ba1160626505e1f3a5df963bfa974178e6fc391d)

Here I set up a fresh Symfony install and added some libraries I thought I would be going to use via composer. With hindsight, this is completely the wrong approach. I started with the framework here because that's what I had been used to doing, but I actually don't need the framework until much later in the process. So the lesson here, don't do this. Don't set up the framework until you are ready to, if you are using a
framework at all of course. Start with your domain.

[Version1](https://github.com/jenkoian/ddd-house/commit/f5a95111f479785454cf6cf5b765ca20cb61475b)

Ignore the change to AppKernel which was again me thinking of the framework when I shouldn't have been.

I've added my first feature file. It contains some examples of how the feature 'navigating the house' would work. Looking back, I'm now thinking this should be broken up. So, enter the house is a feature and the scenarios should contain examples of that. Overall though, you get the idea.

This file is the kind of thing that would derive from the conversation with the client. No code, just language.

[Version2](https://github.com/jenkoian/ddd-house/commit/f3fc5150db91a0ad1be9d56eb8b0af72a48f0026)

The change to the behat.yml file is me just trying to tidy up, you can ignore that.

The changing of "outside the house" to "in the front garden" is just an example of me consolidating the language for consistency. I don't think this is always appropriate, the language is always primary. However, in some cases I think it can actually help the language to be more consistent on some things.

Finally, I've added a context file which implements `SnippetAcceptingContext` which means it can be used to generate
some step definitions for me.

Once this is done, I run `bin/behat —append-snippets` to fill the context file with some template step definitions.

[Version3](https://github.com/jenkoian/ddd-house/commit/9abb0ec5c8d7918537ba84ed28b999798414aab4)

Here I start designing my model. The use of [Named Constructors](http://verraes.net/2014/06/named-constructors-in-php/) really helps here. It allows me to think purely about the domain at the interface level. This, for me, is where the true power
of Modelling by Example is. It's BDD and indeed TDD in its truest form.

The fundamental thing to look at, is the language of the model and how it maps so directly the conversation with the client `$this->house->enterRoom($room)` etc. It's DDD at play, and is a big step forward to the `$this->house->setRoom($room)` I may have done in the past.

It also helps point out gaps in the initial story, considerations that haven't come up previously and thus making your model more resilient.

[Version4](https://github.com/jenkoian/ddd-house/commit/5661411bc0a6f5a0b942f9922150b045709be1c3)

This is the point where I move in a level to actually writing the domain models designed from [behat](http://behat.org). Here I use [PHPSpec](http://phpspec.net) to aid me in the creation of these models. The benefits of this is that it re-enforces that approach of designing through the interface, but it also ensures mistakes are caught and even more, it basically writes the models for you, with it's excellent interactive spec runner.

Finally (no pun intended) you may spot the use of final in front of the class names. I had seen this been used but wasn't really sure why, until I heard [Everzet's explanation of it at Symfony Live London 2014](https://www.youtube.com/watch?v=UIDlOV40xCY&list=PLo7mBDsRHu123EqX-kXnE2tLYXtdbVuzf#t=2871) and
subsequently the [excellent blog post by Ocramius on when to use final](http://ocramius.github.io/blog/when-to-declare-classes-final/). I now see why using final is a great idea and it has even subsequently altered how I think when designing classes.

[Version5](https://github.com/jenkoian/ddd-house/commit/3dab522b244512d6fbfad70d27d947819d9c16b2)

Some further refactoring of the models basically following the Red -> Green -> Refactor loop at this point. Abstract Rooms and Gardens with Location. Why not just use Location altogether? Perhaps, but wanted to maintain the language. You don’t enter a Location as such, you enter a room or the garden.

[Version6](https://github.com/jenkoian/ddd-house/commit/bc7dc0840e634ab22475aee1d5b97a7ad5221427)

Further refactoring, add a way of entering rooms.

[Version7](https://github.com/jenkoian/ddd-house/commit/f68fd0975ead6a6a1177732491ed3d29ba021880)

I thought it would be neat to be able to enter a room from just a room name, as well as a Room object.

[Version8](https://github.com/jenkoian/ddd-house/commit/d125b4a7f5e2ab55ce0910c7c4bd1d240d336f68)

Adding a way of exiting a room. Notice it's very similar to entering a room but it's important that the language is maintained. We can tidy up the code re-use later, although as a side note I like [Mathias Verraes’ definition of DRY](http://verraes.net/2014/08/dry-is-about-knowledge/).

[Version9](https://github.com/jenkoian/ddd-house/commit/1cd52fe156bfd5a93118aac5348988d08142d028)

A minor change to the behat context to ensure room can be entered through their name.

[Version10](https://github.com/jenkoian/ddd-house/commit/56319d09ada9b9a08fe682d697a3973bf36d6bb2)

Here we add our first Value Object, Dimensions. Again, using PHPSpec as the crutch to aid the design. Dimensions is defined as a Value Object because it has no identity and is considered equal based on attributes of the class, in this case: width & height. Dimensions can be set on a location.

I found [Richard Millers post on Value Objects](http://richardmiller.co.uk/2014/11/06/value-objects/) good if you require more information about them have a read.

[Version11](https://github.com/jenkoian/ddd-house/commit/a81431f281b154644c0f899afb64ace67b74d50d)

What happens if we try and enter a room which doesn't exist? Let's add an exception for this.

It's important to note at this point that at all work between versions I’m running `bin/behat` and `bin/phpspec run` constantly and fixing any errors or discrepancies that may arise and using this whole process to shape the domain models.

[Version12](https://github.com/jenkoian/ddd-house/commit/802936f09a1c85c06c7b5b572f45d4e76b0b6b69)

Adding steps for checking dimensions and exits are available. These weren't explicit in our initial conversation but through working through the model and subsequent (ok fake in this case) conversations with the client it's now apparent that dimensions and exits are part of this model. In true DDD style, making the implicit, explicit.

[Version13](https://github.com/jenkoian/ddd-house/commit/50fce972753cab2f914a4569762bb4ba99d25b35)

Just removing a no longer required method. Red -> Green -> REFACTOR.

[Version14](https://github.com/jenkoian/ddd-house/commit/2712efbf1e3719b0295c3cc547176ad405beb262)

Just me tidying up the behat file. In this contrived example we aren't going to be doing anything special with potential buyers, so we can just get rid of this explicit context for now.

[Version15](https://github.com/jenkoian/ddd-house/commit/83cbbd8651af8514211d0c6198b9512e10cb5211)

One thing that was bothering me was how to exit a room. I didn't want to have circular references for example. So here I have a property of the previous location so we know where we've come from and a way of exiting to a room (notice we've tidied up that duplicated code from earlier too).

[Version16](https://github.com/jenkoian/ddd-house/commit/2355c7582e8260d7cb03401bfad48fcc30174fe6)

Allowing our Locations to have exits.

## A Raspberry Pi without the ports

Before I move on to the more tactical parts of DDD, let’s stop and think about what we’ve just done. At this point I’d consider the domain model to be quite complete. Of course it could evolve with further conversations with the client, but from what we know of the domain thus far, I think it’s pretty complete.

### So what do we have?

* A working domain model
* Created from the ubiquitous language
* High level behat stories and lower level PHPSpec tests proving it works
* We've not touched any framework code
* We've kept code to a minimum
* We're completely decoupled

We essentially have a *Raspberry Pi without any ports*.

![Raspberry Pi without any ports]({{ site.url }}/assets/img/pi_bare.jpg)

If you think about [the clean architecture](http://blog.8thlight.com/uncle-bob/2012/08/13/the-clean-architecture.html) diagram below, we have our middle layer.

![Clean architecture]({{ site.url }}/assets/img/CleanArchitecture.jpg)

It’s time now to work out from the middle into the other layers. So let’s add some ports onto our Raspberry Pi so we can connect it to something to make it useful.

[Version17](https://github.com/jenkoian/ddd-house/commit/60f9b70ab227785a5e503a4ed88c7da01d98adc9)

I've simply added two commands for entering rooms and exiting rooms at this point. These are two lightweight DTOs that will be used as a means of transferring messages from our framework into our domain.

[Version18](https://github.com/jenkoian/ddd-house/commit/e4ace656623d57cb78b6c8e5dc9b870b33ef4186)

A long with commands, I've identified an event, `EnteredRoomEvent`. This would ordinarily be done through some kind of event storming session with the client.

[Version19](https://github.com/jenkoian/ddd-house/commit/0952bb45115bb90786b0b685a0ce04de41cf7091)

So as you may have noticed I've been avoiding persistence throughout this. It's a small, simple, contrived example which I didn't want to muddy by adding any means of persistence. I realise this perhaps removes validity to the example, but I don't really care. This is more about how to model a domain with a modelling by example approach, as opposed to the intricacies of database persistence with DDD.

However, I did want a tidier way of dealing with the state of the House. Building the house in the constructor every time wasn't ideal. So I came up with this idea of a factory. Because we all know houses come from factories right? In essence it's more of a singleton, which works for me here. I'm still building the house on every request, but at least this does it in a clear and re-usable manner. It also doesn't get me bogged down in persistence when it's not my primary aim here.

The final thing to note is that I added some basic handlers to handle the commands I created earlier. These are likely to change but are fine for the time being.

[Version20](https://github.com/jenkoian/ddd-house/commit/b8ebbea1bf200e399661f252acc4aee9ff7d2da9)

Adding a Symfony bundle and some basic infrastructure.

Where I say in Version0 I shouldn’t have been adding the framework, it’s in this commit where I should have been.

Few things to point out here. Firstly, the lightweight controllers. They do little more than take the request, set up the command and pass it off to the handler.

When I first started this, I was very much of the mindset:
decouple from the framework, controllers as services etc. I agree massively with decouple from the framework with regards the domain and even the ports layer (commands/handlers) but, [similar to what Dave mentions in ‘that podcast’ episode 10](http://thatpodcast.io/episodes/episode-10-the-one-with-the-best-practices/), I've come a little full circle in the controllers as services and using DI to completely
decouple your controllers. I now feel, it doesn't really matter. So long as your controllers are really light, it doesn't really matter if they're tightly coupled, because essentially they don't matter. They are merely passing messages from framework to domain. The second point to note is that you can see from the images and twig templates how advanced my UI is going to be :).

[Version21](https://github.com/jenkoian/ddd-house/commit/73bb68c1d9fe6a9d125191b3e535af3fb1165c09)

Adding exits and dimensions to rooms for a fuller experience.

[Version22](https://github.com/jenkoian/ddd-house/commit/2c2ec90ebf0d55b5bf30366df99a1dfd31e14077)

The main thing I did in this commit was to add an event dispatcher. I throw a domain event in my model when entering a room and needed the dispatcher in place to support that.

As I am using Symfony it made sense to me to use the Symfony event dispatcher. However, it is a bit of a pain because it expects an event to have a name and to be of type `Symfony\Component\EventDispatcher\Event`. As I was trying to follow the clean architecture and have no outer dependencies I didn't want to have my event extend `Symfony\Component\EventDispatcher\Event`.

Therefore, I needed to create an adapter. Going back to the Raspberry Pi analogy made in a previous version. I needed a Serial to USB adapter, or something like that. I’m starting to add some ports on to my Pi.

![Raspberry Pi with ports]({{ site.url }}/assets/img/pi_ports.jpg)

I also wanted to use my own Dispatcher interface, because what if I wanted to stop using the Symfony dispatcher and replace it with something else? I want to be able to continue using the same interface but just add a new adapter and change my DI. I want to be decoupled.

You can see how I achieved this from the code within this commit. Finally, I added a `HandlerInterface` so that I can swap out handlers using DI should I need to also.

[Version23](https://github.com/jenkoian/ddd-house/commit/dcb675d273260b6a9e0af7948a26945ca2605a01)

Adding an event subscriber to log when a room is entered.

I again used the adapter approach and created my own interface for logging/event subscribing. I then have an adapter for example using PSRLogger which is easily replaceable should I need to.

[Version24](https://github.com/jenkoian/ddd-house/commit/4fdc5ed94368ef1656ea80e6fde634a58020cc04)

To show off the benefits of decoupling domain from the framework I wanted to show an example of how the domain could be used outside the browser, so I thought it'd be cool to set up a quick CLI example.

Symfony makes it trivial to add CLI programs, and you can see from this commit how exactly it works. Essentially it's the same deal as controllers. Request in -> Create command -> Pass off
to Handler.

![CLI version of the house]({{ site.url }}/assets/img/dddhouse-cli.gif)

[Version25](https://github.com/jenkoian/ddd-house/commit/a9ca03a9d882cf03d1e8ca48f17f9780a62ec1f5)

Adding a command bus and separate out command handling from domain.

If you’re unsure what a command bus is or does, [I’d recommend Shawn McCools excellent post on them](http://shawnmc.cool/command-bus).

After initially considering [CommanderBundle](https://github.com/tabbi89/CommanderBundle) I eventually opted for [SimpleBus](https://github.com/SimpleBus) because I liked the simplicity and have a lot of respect for it's maintainer Mathias. I did have [some misgivings over the use of a type hint for commands](https://github.com/SimpleBus/CommandBus/pull/2), but generally it suited what I needed to do well, it also forced me to create an explicit CommandHandling layer, which I think works quite well. It's been completely changed in version 2 now anyway, and is [more of a generic 'MessageBus' now](https://github.com/SimpleBus/MessageBus).

There are quite a few command buses that have popped up recently, I created [CommandBusCommandBus](https://github.com/jenkoian/CommandBusCommandBus) as a case in point. To be honest with you though, the command bus is a really simple concept and you may even be better off just rolling your own if you don’t need anything fancy. The main reason I went with Simple Bus was because it [hooked into Symfony quite nicely](https://github.com/SimpleBus/SymfonyBridge).

Anyway the point is I wanted to introduce a command bus to make my example complete.

Here you can see how I've moved all the command handling bits to the CommandHandling layer (or ports layer as I’ve heard Ian Cooper describe it) I spoke about above. It just means that rather than passing command to handlers directly, I can just 'throw' them on to the command bus now. This has the advantages of being able to decorate the command bus to be able to perform additional tasks against commands should I want to; I can make the command bus handle commands asynchronously should I choose; plus other niceties that arise when delegating message handling in this way.

## …and we’re done!

You can check out the crib on heroku: [http://dddhouse.herokuapp.com](http://dddhouse.herokuapp.com)

You may have guessed from the code but that is indeed the Home Alone house.

Ok, it’s not going to win any design awards, but with a bit of imagination you can perhaps picture some interactive JS whizzy interface which allows you to hover over doors and enter rooms in a fun way.

## So let’s recap what we’ve done

* Created our core domain using Modelling by Example/BDD/TDD
* Worked our way out from the middle
* Identified our use cases (commands)
* Created our infrastructure
* Added ports into our domain
* Created adapters to plug our infrastructure into our domain
* Created a working application

We’ve gone from components to a Raspberry Pi logic board, to a Raspberry Pi with Ports, to a Raspberry Pi with a case - the next step would be to a Raspberry Pi with a fancy case (the JS whizzy version I alluded to above).

![Raspberry Pi Cycle]({{ site.url }}/assets/img/pi_cycle.png)

## Where do we go from here?

One thing I haven’t tackled yet is end-to-end testing, or acceptance testing.

For a while, at work, I’ve often thought we were missing a trick in how QA is integrated with development. In that, it isn’t really. It all feels a little ‘thrown over the wall’. Although, I’ve not done anything with regards this at the time of writing I have a few ideas off the back of this as to how to integrate them closer. I’ll use another post to go in to details, but I’m thinking QA could be involved in the initial feature writing (Given/When/Then). Then when it comes to acceptance testing, they write their automated scripts using [Watir](http://watir.com/) (what they currently use anyway) and [Cucumber](http://cukes.info/) but re-using the feature files developed for creating our domain.

So I’m quite keen to give that a go, maybe using the house as a nice example application, or perhaps starting a new internal application. Either way, I’m quite stoked about the possibilities.

## Conclusion

Theoretically I was a big fan of this approach and practically it hasn’t altered my view. My domain seems so much more concise, and uses the ubiquitous language in a substantial way. It’s made a number of concepts click for me. Take TDD for example, I’d often liked the idea but didn’t truly understand it. I’d taken a test first approach before, but wasn’t that sold on it. However, this subtle difference in approach to TDD has unlocked it’s power for me. I now think, through a combination of [the excellent talk by Ian Cooper](http://vimeo.com/68375232), and this Modelling by Example approach that I ‘get TDD’. It’s about design, not about testing.

What I have learned through taking this approach is how DDD can really work for me. Not just the tactical parts either. I feel I now have a better understanding of how to turn conversations directly into code; How to design aggregates around entities and value objects and how to use ports and adapters to ensure decoupling.

Ok, my example is small and contrived but it’s been enough to expose me to a practical use of these approaches. I’m left with little doubt that this could work on larger projects and have indeed started using it on larger, albeit internal at the moment, projects and have to say it brings everything together quite nicely.

A silver bullet I’m sure this is not, but I can imagine this kind of thing to work in lots of scenarios. It reduces complexity to the point I can see paths forward in projects where before I may have been scratching my head.

Finally, the other brilliant thing about all this is the excellent community behind it. The PHP community has really embraced DDD and has really been pushing some of the ideas, but also people like Ian Cooper and Greg Young from the .NET world have become a huge source of inspiration for me.

{% include JB/setup %}
]]></content:encoded>
      <dc:date>2015-01-23T00:00:00+00:00</dc:date>
    </item>
    <item>
      <title>Some thoughts on Agile</title>
      <link>http://localhost:4000/opinion/2014/08/08/some-thoughts-on-agile</link>
      <description><![CDATA[I would in no way describe myself as an evangelist of Agile practices, I’m not a certified scrum master and I’ve never had any formal training or anything on Agile practices. However, over the last few years the company I’ve worked for has adopted an agile methodology and so I’ve had no choice but to have had some experience with Agile. Here are some of my thoughts on ‘Agile’, or working with ‘Agility’ or whatever the hell you wanna call it.

]]></description>
      <pubDate>Fri, 08 Aug 2014 00:00:00 +0100</pubDate>
      <guid>http://localhost:4000/opinion/2014/08/08/some-thoughts-on-agile</guid>
      <content:encoded><![CDATA[I would in no way describe myself as an evangelist of Agile practices, I'm not a certified scrum master and I've never had any formal training or anything on Agile practices. However, over the last few years the company I've worked for has adopted an agile methodology and so I've had no choice but to have had some experience with Agile. Here are some of my thoughts on 'Agile', or working with 'Agility' or whatever the hell you wanna call it.

## Kanban and Scrum

It took me ages to work out what these terms exactly meant. I'm still not 100% sure, but this is my take.

Kanban I see as basically trello. You work from left to right in a production line type approach. So you'd still have user stories and possibly story points, although I don't think it's as important in Kanban and you'd basically move the stories or tickets through the pipe line, from (typically) to-do to done, via some variation of in-progress, merged and ready for testing. I basically see Kanban as a lightweight version of Scrum.

Scrum for me is the fuller version of Kanban. So you still have the board and the production line approach, but you split work up into sprints, work towards a velocity and plan and demo with the product owner in order to maintain focus on what the product will turn out like. Oh, you have daily 'scrums' which are basically stand ups where everyone gets updated. People put a lot of emphasis on this, but for me it's a minor detail. It just makes sense to catch up daily to update each other?

It's this Scrum approach I'm going to be talking most about in the rest of this post.

## User Stories are king

In my experience, the user stories are *the* most important part of the entire process. Without good user stories it makes it really difficult to estimate, get a good idea of velocity and deliver features ready to demonstrate.

User stories are difficult. When you read one, a good one, it will not appear that way. It will appear as almost too simplistic. Getting to that point however, can be very hard.

### What makes a good user story?

This is in my opinion what makes a user story a good one.

* Describes exactly what the feature should do.
* Should have no hard dependencies.
* Should have a list of Acceptance Criteria (AC).
* Should be short and concise.


Let's go into a bit more detail, with some example user stories.

A bad example:

*As a User I want to see notifications.*

A good example:

*As a logged in User, when I am on my dashboard I want to see a list of notifications at the top of the page.*

Let's break down this example.

*As a logged in User*

We specify that the User needs to be logged in at this point. If you have various Roles in your application it would make sense to include that in the story also, e.g. *As a logged in Editor*.

*when I am on my dashboard*

Now, this isn't perfect. The reason being that this indicates a dependency. What is dashboard? You are assuming in your story that there is a dashboard in place, and thus you can't work on this story until a dashboard has been created.

I think this kind of dependency, which I'd call a 'soft' dependency is inevitable. You will undoubtedly come up against situations like this. I think there are two things we can do to help here.

1. Be  mindful when planning that some tickets are undoubtedly going to need to come after others. Although avoid this if possible.
2. Allow user stories to have a Background. If anyone reading this (hi Mum!) has experience with BDD they will likely be familiar with features having a Background, which is basically where you set up the environment for the test. I see these kind of soft dependencies as similar. In our example, the Background would simply be: I have a dashboard in place.


*I want to see a list of notifications at the top of the page*

Again, this implies some kind of soft dependency, so the background for this ticket may be: There is a notification mechanism in place. The other questions surrounding this part of the story relate to the Acceptance Criteria. How should the notifications look? How many should there be? What determines the *top* of the page? These questions should all be answered within the AC for the story.

### Example of good Acceptance Criteria

* Notifications should appear in an unordered list.
* The list should appear at the top of the page, directly beneath the fixed menu.
* There should be a maximum of 5 notifications displayed.
* The text of the notifications should be black using the default font of the site.

You get the idea. The level of detail here is up to the product owner. Some may want complete control over their definition of done, down to pixel sizes and font styles. Others may simply be happy with something a bit more high level.

**The key point is that a good User Story can be understood by the developer and tested against by QA and the product owner/client.**

## Planning

I don't have too much to say on planning. I think if you have good user stories planning is a lot easier. Planning should be short and simple if you're doing it right. If your stories aren't good, then planning can end up taking a long time and be fairly painful.

Estimation can probably be seen as a part of planning. For my money the best way of estimating is [affinity estimation](http://www.boxuk.com/blog/affinity-estimation-what-is-it/). Whether you do this against the backlog at the beginning of the project or in planning at the beginning of each sprint, I don't think matters too much. I think it makes more sense to do it before each sprint as you will gain more insight of the product and your estimations are likely to be more realistic. However, I can understand that sometimes you need to do it before the project to get an idea of scope.

Planning is all about green fields, so try and have some fun with it if you can. Fun sprint names, a sense of competitiveness in increasing velocity are all ok in my eyes.

## It's all about the big game

For me, as a developer, the demo is *the* most important part of the entire process. It is your chance to show off to the product owner and/or client what you have done this sprint. As a keen Football (Soccer) fan I see this very much like the big game at the end of a week of rigorous training.

I think each sprint should be focussed on the demo. It is where you are shipping the features you've been working on. Take pride in this time slot you have, show off a little, be enthusiastic, encourage questions, engage with the audience. I've been into demo's embarrassed at how little there was to show, or worried that something is unfinished, worried it will undoubtedly break in front of an audience. I'm now firmly of the belief that if you find yourself in that situation, you're doing things wrong.

If you can't demonstrate something which you feel is good, working software then your sprint has gone wrong. Perhaps you committed yourself to too much work which you couldn't deliver. Perhaps your sprint period was too little, 2 weeks seem to be the norm but if you're features are too big, consider increasing this period? More likely, your user stories were poor, which comes back to why User Stories are king.

## Retrospectives are vital

Sometimes when you feel there is a lot to do, it can be tempting to skip the retrospectives. It's often seen as a non mandatory part of the process where we all just pat ourselves on the back or if things haven't gone right, play the blame game. I disagree with this.

I think Retrospectives are vital in the health of an agile project. They highlight early where things are going wrong or where things are going right. They encourage communication amongst the team and can be quite bonding.

They should be fun and action focussed.

I would highly recommend taking a look at [plans-for-retrospectives.com](http://www.plans-for-retrospectives.com) for some ideas of fun 'games' you can play in your retrospective. We've bought some of the hard copies for the office and they've been brilliant. The best thing I like about them is that they're fun but very action focussed. So you don't just feel like you're wasting time gassing about the project, you're actually putting down actions as to how to make things better.

## Jira is actually pretty great

It almost pains me to say it because it's so frickin expensive, but Jira is actually pretty great. Well, more accurately the Agile (formerly Greenhopper) plugin for Jira is great.

I think you could probably get a similar experience with something like Trello and a bit of admin work on your side, but Jira just makes it all fit together so nicely. It's the various reports, especially the burn down charts which I think are it's greatest features. It's really excellent, if you can afford it (and can work out the mental user roles management?!) then I would definitely recommend it.

## Conclusion

I have no real conclusions, just some of my thoughts on working Agile. My thoughts are changing all the time, but after a few years working in an Agile way, this is what I think works best.

I have a habit of waffling, so I hope this all makes sense, I can probably sum up with the following bullet points:

* User stories are king.
* Each sprint should focus on the demo, which for me is the most important part of the process.
* Retrospectives are important.
* Use Jira (if you can)


Of course, your experiences may be different, and I would love to hear about them!

{% include JB/setup %}
]]></content:encoded>
      <dc:date>2014-08-08T00:00:00+01:00</dc:date>
    </item>
    <item>
      <title>Using Bower in a Symfony2 app</title>
      <link>http://localhost:4000/symfony2/2013/12/06/using-bower-in-a-symfony2-app</link>
      <description><![CDATA[
]]></description>
      <pubDate>Fri, 06 Dec 2013 00:00:00 +0000</pubDate>
      <guid>http://localhost:4000/symfony2/2013/12/06/using-bower-in-a-symfony2-app</guid>
      <content:encoded><![CDATA[{% include JB/setup %}

I've been hearing good things about [bower](http://bower.io) for a while now but never really had the chance to try it. So having recently started a new Symfony2 side project I thought I would take a look at integrating it. It turned out to be very very easy.

## Setting up

Well, obviously I needed to install it first. Pretty easy:

`npm install -g bower`

Cool. Next up I needed to create a `bower.json` file. This is basically `composer.json` for front end assets.

Bower has a nice interactive way of creating this file by simply running:

`bower init`

This will take you through each step of adding the necessary fields, much like the composer equivalent (`composer init` naturally).

Once I had done that, I had a bower.json file looking something like:

<script src="https://gist.github.com/jenkoian/7833778.js"> </script>

I won't go in to too much detail about how bower works, there is some pretty decent docs [on the website](http://bower.io) but essentially it is `composer` for your front end dependencies.

## Integrating bower with Symfony2

So how did I set this all up in a Symfony2 app? Well very easily, probably easy enough that it doesn't really require a blog post, but hey, I need to blog more and had some free time.

So my `bower.json` file I simply placed in the root of my project (right there alongside `composer.json`) then to get my front end assets, I simply needed to run:

`bower install`

Sweet, that was easy! Wait though, what is this `bower_components` nonsense. I could do without this littering the root of my project. Particularly as the standard in Symfony2 apps is to install front end assets in a `Resources/public` location.

I needed to tell bower to install my assets somewhere else. This was actually really easy too. I needed another file in the root of my project, this time a `.bowerrc` file. Here it is:

<script src="https://gist.github.com/jenkoian/7833818.js"> </script>

Pretty neat! 

I was a bit torn as to which was the correct directory for this. I ended up going with `src/Acme/Bundle/DemoBundle/Resources/public/vendor` in my main website bundle, but you may decide to put it in `app/Resources/public/vendor` or somewhere else altogether, i.e. YMMV.

So deleting that `bower_components` folder and running `bower install` again downloaded all the assets in the directory I was happy with. I then realised I wanted to include [bootstrap](http://getbootstrap.com) too. Rather than edit the `bower.json` though (although that would work) I simply ran:

`bower install bootstrap --save`

This works more or less exactly like `composer require`. It will install the dependency into your specified directory. The `--save` switch will ensure it will be added as a dependency to your `bower.json` also (I'm not sure why you *wouldn't* want this?!). You can specify a version, but if omitted the latest version will be assumed.

## Using your front end dependencies

So we have bower all set up, let's see how we include these things within our templates.

Well, pretty much just how you would include CSS/JS normally.

<script src="https://gist.github.com/jenkoian/7833806.js"> </script>

## Summing up

That's pretty much all there is too it. One thing that I was wondering about at first was the lack of `bower.lock` file or equivalent. Without this it means that you can't rely on libraries being the same versions on different environments (ok you can set exact version numbers, but still). This is a bit of a problem if you want to use bower in production as part of a deploy script for example. [There is some discussion on this](https://github.com/bower/bower/issues/505), but if this is an issue for you, you essentially have 3 options:

1. Use exact version numbers
2. Commit front end assets
3. Just accept the possibility of a variation in assets across environments


For my side project, option 3 is fine and I happily set the assets directory in my .gitignore file, but I do think a .lock file function is a must for bower going forward.

All in all though, I think bower is very nice. It does exactly for front end development what composer does for PHP development. It makes managing front end dependencies much much nicer. Hopefully gone are the days of downloading zip files and boshing into your web app.

## Going further

There is an interesting looking Symfony2 bundle for bower, called [SpBowerBundle](https://github.com/Spea/SpBowerBundle). I didn't use this in my case as I was after a simple solution and wanted to ensure I was learning about bower rather than a bundle. 

However, having taken a quick look, the bundle looks very nice. I can see it being particularly useful if you want to manage front end dependencies across multiple bundles. The assetic integration also looks good.

Finally, there was a recent discussion started about the state of the front end and Symfony2 which ultimately led to [this github issue](https://github.com/kriswallsmith/assetic/issues/529) so definitely worth keeping your eye on that if you're interested in this.

## Related links: 
[http://bower.io](http://bower.io)   
[http://williamdurand.fr/2012/12/24/being-a-frontend-developer-for-a-weekend/](http://williamdurand.fr/2012/12/24/being-a-frontend-developer-for-a-weekend/)   
[https://github.com/Spea/SpBowerBundle](https://github.com/Spea/SpBowerBundle)   ]]></content:encoded>
      <dc:date>2013-12-06T00:00:00+00:00</dc:date>
    </item>
    <item>
      <title>Symfony2: Caching a Rest API</title>
      <link>http://localhost:4000/symfony2/2013/01/29/symfony2-caching-a-rest-api</link>
      <description><![CDATA[
]]></description>
      <pubDate>Tue, 29 Jan 2013 00:00:00 +0000</pubDate>
      <guid>http://localhost:4000/symfony2/2013/01/29/symfony2-caching-a-rest-api</guid>
      <content:encoded><![CDATA[{% include JB/setup %}

As part of a project I'm currently working on, I needed to create a Rest API as a facade into an old legacy database.

Some of the data I was retrieving from this legacy database was quite large and quite complex, one particular endpoint for example would take approx. 10 seconds to load. This is simply far to slow to service the client that would be consuming this data and so it soon became obvious that some caching was required to ensure that data was loaded quickly.

I knew I needed some kind of data caching, and I had planned to take full advantage of the expiration model of HTTP caching as much as possible, however due to the dynamic nature of the data, I knew I needed a flexible validation model of HTTP caching to ensure maximum efficiency from the API.

I was in the fortunate position that the client consuming this endpoint was being developed by our team also. Therefore, as long as the Rest API returned appropriate caching headers, I could also set the appropriate caching headers to make use of these within my client. HTTP Caching was a go.

Symfony2 has excellent support for HTTP Caching. If you haven't done so already, I would highly recommend [reading the \(f\*\*\*\*ng\) manual on it](http://symfony.com/doc/current/book/http_cache.html).

What I wanted was to cache a particular endpoint "forever" until a record within the result set of the endpoint was updated. So for example, if you hit the following endpoint:

```http://acme.com/things```

It should **always** return a cached version of *things*, unless a *thing* has been updated since the last time the endpoint was called.

So what I needed to do was to work out when a *thing* was last updated **before** the main query was run and change the response. 

## Getting the last modified date

This was simple enough, just add something along the lines of the following to the appropriate repository class:

<script src="https://gist.github.com/4667994.js"> </script>

So now we have a cheap way of getting the the last modified thing, or a last modified date for our endpoint.

## Using last modified date to alter the response

The problem I had now was how to look up this date and alter the response if necessary. 

I could have done what they have in [the example on the Symfony docs](http://symfony.com/doc/current/book/http_cache.html#validation-with-the-last-modified-header) however this wasn't very flexible, as it meant adding a lot of duplicated code to every action. I wanted something much more flexible. I wanted to make a controller cacheable with minimum effort required.

My solution for this was to use a listener:

<script src="https://gist.github.com/4668158.js"> </script>

What this does is before the controller is used, checks to see if it implements "Cacheable" and if it does will check the last modified date and then change the action it will call on the controller (and thus the response) accordingly.

Here is the code for the interface:

<script src="https://gist.github.com/4668261.js"> </script>

So all that's left to do then is to add three methods as stipulated in our interface - isNotModified(), getLastModifiedDate() and getLastModifiedResponse().

It makes sense for isNotModified() and getLastModifiedResponse() to live in an abstract parent class as these are unlikely to change across multiple controllers:

<script src="https://gist.github.com/4668398.js"> </script>

It is simply then a case of adding a getLastModifiedDate() to the children controllers, for example:

<script src="https://gist.github.com/4668420.js"> </script>

You should now have an unobtrusive way of setting a 304 response for endpoints on your API. Of course this relies on the appropriate headers being sent by the client consuming this service. This is easy using something like Guzzle, but more on that in another post.]]></content:encoded>
      <dc:date>2013-01-29T00:00:00+00:00</dc:date>
    </item>
    <item>
      <title>Silicon Valleys?</title>
      <link>http://localhost:4000/opinion/2013/01/20/silicon-valleys</link>
      <description><![CDATA[
]]></description>
      <pubDate>Sun, 20 Jan 2013 00:00:00 +0000</pubDate>
      <guid>http://localhost:4000/opinion/2013/01/20/silicon-valleys</guid>
      <content:encoded><![CDATA[{% include JB/setup %}

A little while ago (ok a long while ago, I procrastinate a lot) [I noticed someone from the web industry crowd sourcing for somewhere to live](https://twitter.com/drewm/status/265523881446629376). I looked at the responses they received and noticed a few [people recommend South Wales](https://twitter.com/emmaboulton/status/265534744857550848). As a born and bred South Walian it obviously perked my interest, but it also got me thinking; would South Wales be a good place to live for a web professional?  In this post I aim to answer that very question and to also reflect on why I enjoy living and working in South Wales as a web professional.

## The people

The welsh are renowned for there passion, and I could talk about how this is true and even drop a mention for the great welsh rugby team, but as this is a techy blog I will try and keep it relevant.

There are hard working people all over the world. I'm sure you will be able to find people who work hard wherever you are, nothing here sets Wales apart from the rest. However, nothing should set other places above Wales in this regard either. There is a wide net of passionate developers and designers (UX'ers, content writers, marketeers, managers etc. etc.) throughout South Wales. You will not be short of good people when looking for someone to help you work on that idea you have or when arranging a meet up to discuss that new bit of tech you've been experimenting with.

## The community

Speaking of meet ups there are a number available for whatever you're interest may be. Speaking as a developer, there is an excellent meet up called [Unified.Diff](http://unifieddiff.co.uk/), which I've had the pleasure of speaking at and would recommend whole heartedly for anyone wanting to learn/speak about software development. If you're a designer there are a number of conferences and smaller meet ups available, the recent emergence of the [Port80](http://port80events.co.uk/) and [Handheld](http://www.handheldconf.com/) conferences, both of which received excellent feedback, stand out. There is also the Port80 localhost events and the [UX book club](http://www.meetup.com/Cardiff-UX-Bookclub/) if you're looking for something on a smaller scale.

If you're a freelancer you may be looking for co-working space or people in a similar situation as you to have some community when seemingly working alone. The excellent [indyCube](http://indycube.com/) is just what you need. [IndyCube](http://indycube.com/) is a set of premises set up for freelancers to pay a small fee to use as their office, you get internet access, a desk, chair, the all important tea and coffee facilities and more importantly, people just like you to share an office with and who knows, maybe make new friends/acquaintances/colleagues.

## The company

You may have heard about [Specific Media buying Myspace with a little help from a certain Mr. Timberlake](http://www.bbc.co.uk/news/business-13969338). As part of this take over, it was decided that much of [the new Myspace](https://new.myspace.com/) development was to be undertaken in the UK. In London you may think, isn't there some kind of silicon roundabout or something? Well no, a large chunk of the new myspace is being developed right here in South Wales. If it's good enough for Timberlake, it may just be good enough for you too?

Of course it's not just celebrities and world famous brands choosing to innovate and develop right here in South Wales, there are lot of outstanding, industry leading agencies right here in the heart of the country.

From [influential designers](http://markboultondesign.com/), to [innovative developers](http://boxuk.com) it really is no coincidence that [one of the most famous websites started right here in the capital city](http://www.cs.cf.ac.uk/movies/).

## The infrastructure

This is a crucial area as to why South Wales and in particular Cardiff is a great place to start a new chapter in your digital career. As well as being among one of the [first cities in the UK to get super fast, fibre optic broadband](http://yourcardiff.walesonline.co.uk/2012/07/03/cardiff-to-get-fibre-broadband-on-demandif-there-is-any/), Cardiff was also listed among the [first cities in the UK to have 4G internet access](http://www.walesonline.co.uk/news/wales-news/2012/10/30/superfast-4g-mobile-phone-technology-to-be-launched-in-cardiff-today-91466-32128590/).

Where as perhaps neglected before, Cardiff is now firmly established as one of the brightest cities in the UK and certainly one of the most digitally enhanced. The infrastructure here is first class in aiding you do your online business.

Of course, if you should be without internet access but badly need it, there is that ever present [community I was talking about earlier to help you out](https://itunes.apple.com/gb/app/cdf-hotspots/id558826581?mt=8).

## Conclusion

I'm sure working in South Wales is not perfect, it is probably still some way off San Francisco or possibly even [Shoreditch](http://www.siliconroundabout.org.uk/about/), however I think it should be given a lot of consideration if you work in the web and are looking for somewhere to setup home in the UK. 

If you don't mind having to see everything in Welsh as well as English, like being surrounded by passionate people and want a digital infrastructure that's first class, then come on over, we'll get the kettle on.]]></content:encoded>
      <dc:date>2013-01-20T00:00:00+00:00</dc:date>
    </item>
    <dc:date>2022-11-21T00:00:00+00:00</dc:date>
  </channel>
</rss>