Grab a Backlink

I can’t quite believe it’s Friday again already. I mean, it’s nice and all because of the weekend, but I never feel like I’ve achieved quite as much as I had planned.

This week I saw a really interesting ‘thread’ (is that the right word?) on Twitter from the Laravel community showcasing interesting projects being worked on:

(credit where it’s due, I found this via @davedevelopment, a really talented and knowledgeable dev who I would highly recommend you follow, if you don’t already)

Anyway, I think we should share our own projects in the same way. You already know mine – CodeReviewVideos – but I’d love for you to share yours. If you want to get in touch, reply here, or any of the other numerous ways to get in touch, and I will share any I do get in next weeks mail out, plus you will get a backlink from the blog. I can’t promise heaps of traffic, but as Tesco say, every little helps.

There have been three new videos added to the site this week:

https://codereviewvideos.com/course/beginner-s-guide-to-symfony-3-forms/video/snake-case-on-your-forms-camel-case-on-your-entities

I was recently on a piece of client work whereby an API had been created, and somewhere along the lines the business requirements had dictated a change in JSON output from camelCase to snake_case.

Now, there’s a couple of points that need to be addressed here – firstly you’ve got your output (GET requests) which is the obvious one. But if you’re accepting input (POST, PUT, PATCH) then you need to ensure you update the associated form fields, and that’s a breaking change for API consumers.

Anyway, in this particular case the externally visible change had already been made. But to make the change, the devs had decided to fudge all the class properties from camelCase to snake_case, which in turn, caused some additional, seemingly unrelated problems. Most of the time when you circumvent the way Symfony expects you to work, you’re going to open an entire pallet of cans of worms that should make you sit up and think – hey, we cannot be the first people who want to do this. What’s the right way to do it?

In this video we cover the simple way to do this that ensures your view concerns don’t need to affect your model concerns. And if you’re in a similar position and need to handle the GET / read side of things, one easy way is to use JMS Serializer’s SerializedName annotation.

https://codereviewvideos.com/course/phpstorm-shortcuts/video/become-a-better-developer-with-php-inspections-ea-extended

If you aren’t using PHPStorm then I would strongly advise you to give it a try. For Symfony there is an excellent plugin – the Symfony plugin being the most essential.

However, regardless of whether you “do” Symfony, Laravel, one of Zend’s offerings, vanilla PHP, WordPress, Magento… (the list goes on), then your code quality stands to be improved by using the PHP Inspections EA Extended plugin.

Honestly, this plugin is fantastic. Unless you have the cold, artificial heart of a PHP codebot, I am confident this plugin will find at least one ‘problem’ in your code that could be improved. My favourite feature is how it finds code that may throw exceptions somewhere down your stack, which you may very well not be handling – or at the very least, not documenting.

This one is well worth the 30 seconds it takes to install, and I cannot recommend it enough.

https://codereviewvideos.com/course/react-redux-and-redux-saga-with-symfony-3/video/testing-authsaga-unhappy-paths

Lastly this week we covered testing the “unhappy path” through the AuthSaga in our React / Redux / Redux Saga > Symfony 3 API project.

In this video we look at how we can quickly test a couple of problem areas:

1. Ensuring our saga throws when a call to api.login fails, and;
2. Ensuring our saga throws if the api.login response doesn’t contain a token in the response body.

As a side note this week I’ve been playing with JavaScript’s MobX as an alternative approach to Redux. Whilst I like it, I still think Redux Saga is the easiest way to write code that is extremely testable, which means you gain that much higher level of confidence that it will work now, and in the future even when you inevitably change stuff.

Until next week, take care, and happy coding.

Chris

Have You Ever Used A Symfony Compiler Pass?

It’s been JavaScript, JavaScript, JavaScript for the past few weeks, so this week I thought I’d vary things up a little and, heck, cover a little Symfony 🙂

Yes, two new – dare I say – useful videos were added to CodeReviewVideos this week.

Lets go ahead and jump right into it.

First up we venture into the wonderful – and scary sounding – world of Compiler Passes. Now, this is one of those Symfony things that is really useful, but also something you’re unlikely to try until you’ve seen it working before. Ahh, the old catch 22. Not so bad if you work in a huge team of devs who all share knowledge (or you are particularly good at reverse engineering), but if you’re a lone wolf, or part of a smaller, less experienced team, things like this may completely pass you by.

To begin with, we start with a code smell that I saw recently when working with a client. This problematic code is fairly common, and isn’t specific to Symfony projects. You may even have it in your own projects:

Controller bloat.

This particularly issue starts off with an if  / else , which turns into an if  / elseif  / else , and within a few further iterations you’ve got this nasty conditional dominating the method. Actually in the code I was looking at, this was a common theme throughout multiple controllers, and multiple actions in each controller. It’s things like this that make people believe Symfony is hard, when in reality, this problem would follow you if you switched to Laravel, or Zend, or Slim, or any other.

We’ll use an example of having to convert an array of data into a variety of formats – CSV, XML, YAML, and so on.

To begin with, these various conversion strategies live inside our controller action.

In the first video we cover a simple way to start refactoring this code:

https://codereviewvideos.com/course/symfony-compiler-pass-example/video/extract-extract-extract

At this stage all we are doing is extracting the problem code from the controller. This is really easy to do, and can immediately start to reduce duplication, and increase code re-use.

Unfortunately this doesn’t actually solve the tight coupling problem. But sometimes, you know what? You don’t need too. Over engineered code can be just as painful to work with as sloppy code. It’s just a different kind of pain.

Anyway, on larger systems simply extracting code out like this may not give you the flexibility you need. For that we can use a technique that third party bundles use:

https://codereviewvideos.com/course/symfony-compiler-pass-example/video/introducing-the-compiler-pass

In this video we cover how to use a Symfony Compiler Pass to decouple the Conversion service we’ve created from the various conversion strategies (e.g. convert to YAML, convert to JSON, and so on).

Let’s imagine that you wanted to create a Symfony Bundle that you could then share with the world in order to help others who might need to convert arrays in the future. Whilst you might provide a variety of implementations out of the box – ConvertToJSON, ConvertToXML, and so on – you don’t want to be solely responsible for adding every possible implementation in the future.

Instead, you could allow users of your library to implement the expected interface, and then use a Symfony service Tag that tells your Conversion service to also include this custom converter that your library user has created.

There’s loads of uses for this approach, and honestly it’s easier to do than you might think. Much like a lot of Symfony concepts, actually 🙂

All of this weeks videos are free to watch, though I will be making the Compiler Pass video a Members Only video at the end of this month.

Until next week, take care and happy coding

Chris

Testing, Testing, 1, 2, 3

2017 is here. I hope you’ve had an enjoyable New Years? These last two weeks seem to have flown by, but then I guess they always do.

I’m going to keep this week’s update short and sweet, as I’m sure you will have had a bunch of accumulated emails to plow through after a two week break.

In the first two videos this week we covered testing the “happy”, and “unhappy” paths through the Request reducer. Writing the tests helped guide us through what should happen, and as your logic gets more complex, tests become ever more important in delivering working code on time, every time:

https://codereviewvideos.com/course/react-redux-and-redux-saga-with-symfony-3/video/testing-request-reducer-part-1

and

https://codereviewvideos.com/course/react-redux-and-redux-saga-with-symfony-3/video/testing-request-reducer-part-2

Testing reducers should be easy though. After all, they are pure functions. Where things get a little more involved is in functions that have side effects – calls to our API, and all the perils that entails.

As we’ve already covered, to handle these side effects we are using Redux Saga. But up until now, we haven’t tested these functions. When I first sat down to write a test for a Saga I have to admit, I found it daunting. Thankfully though, testing Redux Sagas is actually really, really easy.

https://codereviewvideos.com/course/react-redux-and-redux-saga-with-symfony-3/video/testing-authsaga-happy-path 

We’re covering the “happy” path through our doLogin generator function, and in the process we’ll see how easy it is to reliably test functions that contain calls to APIs, or other side effect generating (excuse the pun) activities.

What’s New This Week at CodeReviewVideos – 30th December 2016

I hope you’ve had a nice Christmas week. I remember carving the turkey on Christmas day somewhat concerned there might not be enough. And yet, only yesterday did we finish the last of the left overs. Madness.

Over the course of the last week you may have read (via Twitter) a discussion around “side projects” and should developers be doing them in their free time over Christmas. I’ll start by sharing my opinion on this, but I’d love to hear yours:

For me, side projects are amongst the most important things a developer can be doing with their free time. Now, I’m not talking about sacrificing spending time with your family to instead be eyeballs-in-front-of-monitor (Lord knows, we do enough of that all year anyway). I mean if you’re going to sit down and write a bit of code, it might as well have some structure to it.

One of the things that I frequently hear from others developers is that we don’t get the opportunity – at work – to play with interesting / new technology. For example:

“I want to learn Redis, but my boss won’t let me.”

Controversial – I agree with your boss! 🙂

I mean I agree with the underlying reason: no, you are not hacking Redis into the production, money-making stack that runs the companies business to scratch your technical itch.

And that’s fine. There’s a way to play with Redis without any approval from your boss:

Use it in a side project!

Side projects don’t need to change the world. They don’t need to become self sustaining businesses in their own right. They have always worked best for me when they satisfy some personal demand I have that might also just happen to allow me to play with some new tech – Elasticsearch, Ansible, Graylog, etc.

Then, once you’ve played with your new tech (e.g. Redis), and used it in a real (side) project, not only will you have something new to stick on your CV, but you can also talk more authoritatively with your boss / colleagues / significant other about how awesome {shiny_new_tech} is, and how it might improve said current money making business system even further.

And hey, if your side project does transform into something money making, maybe one day in the not too distant future you will have employees of your own asking to shoehorn Rails into your PHP code, so they too can scratch their own itch 🙂

This Week in Videos

Throughout this week there have been three new videos.

First up, we looked at how we might add a spinner to our React / Redux application:

https://codereviewvideos.com/course/react-redux-and-redux-saga-with-symfony-3/video/showing-spinning-icons-because-why-not

Whilst on the surface this seems really simple, what’s cool here is how that spinning icon is displayed depending on a current value in our Redux-managed state. The idea here is to keep our application’s code sane and manageable as we grow.

This implementation is fairly naive. As our application grows – think: maybe we add a Registration flow using Stripe – then we’re going to hit a bug in the way our spinner works on the back end. Thinking about this, we then move on to a better implementation:

https://codereviewvideos.com/course/react-redux-and-redux-saga-with-symfony-3/video/more-robust-request-tracking

This is nice and all, and maybe good enough, but from my own personal real world experience, we could still hit on an issue whereby our spinner seems to show / hide unexpectedly. The problem we have now is that to track multiple requests (e.g. one to Stripe, another to our API, all in the same form submission), we need a more involved reducer implementation. And whilst we could have a hack at it, instead it makes sense to write a tested implementation.

https://codereviewvideos.com/course/react-redux-and-redux-saga-with-symfony-3/video/getting-started-testing-with-jest

As if we haven’t covered enough new stuff in this series (what with React, Redux, Redux Saga, React Router, Yarn, Bootstrap 4… the list goes on), we’re going to start testing all our code using Facebook’s JavaScript testing framework – Jest.

To me, this makes sense as our entire stack is Facebook centric already. We might as well embrace the tooling they use. After all, if it’s good enough for the third biggest web site in the world then it’s good enough for me.

I’ll finish up here by covering one last point:

In my quest to find out how popular Facebook is for the purposes of this post, I Google’d “alexa”. In the olden days, the defacto result for Alexa would have always been the site I linked to earlier. Now Alexa is an Amazon product which occupies the top two search engine results. Alexa – the company – is owned by Amazon, and comes third. I feel old.

And with that, I would like to wish you all a very Happy New Year, and a prosperous and successful 2017.

Chris

What’s new this week at CodeReviewVideos? 23rd December 2016

I hope you’ve had a fun week coding. As it’s really nearly Christmas I’m in full scale geek mode over a present I know I’m getting. I’ve been looking forward to reading this for ages, and I’m also excited about reading a paperback. It still sucks if you drop it in the bath, but at least you don’t risk electrocuting yourself like if you drop your tablet.

I’ve been experimenting with Elixir (the language used by the Phoenix Framework) over the past few months and I love it. Apparently it’s very similar to Ruby, which I never gelled with, but there’s so much more to it than that. If you are at all interested in learning Functional Programming, I cannot recommend Elixir highly enough. A couple of nice resources to check out are:

But that doesn’t mean I’m stopping with PHP. Far from it. PHP7.1 is proving really nice, and my codebases are starting to see a liberal use of return types, nullable types, and more.

I also couldn’t be happier with how Symfony is performing as the API (back end) for the React / Redux / Saga project.

There’s some really cool new things in Symfony 3 that will be covered over the next few weeks, and there’s a really cool thing that’s been in since early days on Symfony 2 that may help make your code base more modular. Stay tuned for those.

This week we covered logging out (in a fashion) from our React front end:

https://codereviewvideos.com/course/react-redux-and-redux-saga-with-symfony-3/video/logout

There’s a bit more to it than this as we shall see once we add in a few more pages to our app, but as a starting point, it’s good enough.

Then we added a Bootstrap 4 (alpha :)) NavBar to our project:

https://codereviewvideos.com/course/react-redux-and-redux-saga-with-symfony-3/video/adding-an-auth-aware-navbar

We added in some of that ‘classic’ React style ternary to display our username and a logout button if available, or just the log in button if not. Though the code to implement this is trivial, it’s only trivial because we’ve done a bunch of the hard work before hand (via Redux / Sagas).

BTW – did you know ‘Sign In’ is probably better to use than ‘Log In’ – obligatory StackOverflow link.

Finally, we tidied up the project:

https://codereviewvideos.com/course/react-redux-and-redux-saga-with-symfony-3/video/cleanup-linting-and-login-form-styling

With using a boilerplate, we gain a load of things we do want, but a few that we don’t. The benefits of initially having these files around as examples far outweighs the downsides of having to spend a bit of time deleting them in the future.

All this code is fine, but it’s untested. I know there’s an absolute ton of new things to cover for any PHP dev who is new to JavaScript, but now that we’ve covered a typical work flow, and you’ve hopefully started to get a feeling of how pages / components fit together, we can now add yet another ‘thing’ to our cornucopia of things, and look at testing.

We’re going to be using Jest. It’s CV friendly 🙂

Before I go, could I ask you to reply and let me know of any conference / meet up group / user group talk – that you can find on YouTube (or similar) – that you would recommend a watch?

I’ve been watching a bunch of them recently (follow along on Twitter if you’d like to know which) and my mind seems to go blank whenever I need to think of one to watch next. I’d love a few recommendations.

I hope you have a very merry Christmas. I’ll be back before New Years, but if you don’t catch the mail before then, a happy new year to you also 🙂

Chris