Code Review Videos

Last week I asked the following question:

I know this mail out doesn’t go to a huge number of people, but I was hoping for a slightly better response rate than what I received.

As it stands I got 4 replies.

Sad trombone.

As the survey was anonymous, I unfortunately cannot personally contact each respondent to say thank you – so if you did reply then sincerely, thank you 🙂

Still, here are the results:

This is still very useful to me. It’s roughly in line with what I was thinking.

Let’s take a video series on integrating RabbitMQ with Symfony as an example.

There’s broadly three parts (in my mind) to a series like this:

• Server setup
• Basic usage
• Advanced usage

For me, the hardest part is the server setup phase.

There’s a ton of ways to setup a server. To what level do I cover this part? Should it be good enough to get started, or a complete build that’s secure and ready for production?

Docker is fairly straightforward (to a point) – something like me sharing a docker-compose.yml  file, and then you running docker-compose up. That assumes you’re comfortable with Docker, and have Docker install, of course 🙂

Manual set up is a little more involved. What OS are we installing on? Will it be on a VM, or on a VPS like Digital Ocean or Linode? How to do we reproduce this build when moving into production? Etc.

Anyway, lots of new things for me to ponder. I really do appreciate knowing this stuff, even if it does open up further questions.

Again, thank you 🙂

Video Update

This week saw three new videos added to the site.

We are continuing on with our Wallpaper website, specifically this week wrapping up the test-driven approach to wallpaper file uploads.

I’m genuinely curious as to your opinions on this process so far. I find it somewhat amusing that we covered wallpaper file uploads without tests in just two videos, and the very same process when testing took five videos.

The underlying differences and resulting system design are definitely different. But are they different good, or different bad? Is the system now easier or harder to understand?

These aren’t questions that I have a definitive answer too, by the way.

Next up we are going to repeat this process for both ‘Edit’ and ‘Delete’.

This will bring us almost to a close of the first part of this series.

Until next week, have a great weekend and happy coding.

Chris

Testing is an interesting subject. I’d say it’s a fairly safe bet to say that we all believe we should be writing tests. However, from personal real-world experience, far fewer developers actively write tests than I would have ever thought.

This often gets me to wondering: Why?

Why – if we know that well-tested code is easier to work with, easier to change, and generally makes our lives easier – do we choose not to write tests?

“Time” is probably the easiest thing to blame. I’ve lost track of the number of company stand-ups I’ve attended where a developer will mention testing in some capacity, and an antsy project manager will espouse the following wisdom:

Let’s skip the testing for now, and get this feature done. We can come back and add tests later.

If only we had a remote control to fast-forward time. We could quickly visit the future stand-up where the bugs introduced as a result of this PM’s (complete lack of) years of programming wisdom and skill came back to bite the entire team on the backside.

Time is easy to blame because it’s not about exposing our lack of understanding of something technical.

I’m sure you’ve been there: part of a conversation about some programming concept that, even though you’ve never heard of up until now, for some inexplicable reason, you suddenly strongly believe you should already be a fully-versed expert in. The correct approach here is to nod and make affirmative noises, then excuse yourself, lock yourself in the toilets and frantically StackOverflow all these new terms on your smart phone.

No, not really.

There’s so much to know as part of our job as a software developer. It’s a constant drive to self-improve.

And the truth is: there’s too much stuff to know. You cannot feasibly be expected to know all of it.

But that’s no excuse to avoid learning new stuff that does matter to getting your job done in the most efficient and effective manner.

For me, this means that generally my development life will be easier and less stressful.

How the heck does any of this relate to testing?

Well, to understand that let’s forget all about PHP for a moment. We’re going to choose a completely different language:

F#.

I’m hoping I’ve chosen a language here that you don’t know. If you do already know F# then you get a free re-roll, and you can magically substitute this for a language you don’t already know.

Let’s imagine that we’ve been learning a little bit here and there about F# in our spare time.

As part of a different project, some particular problem has come up that we are confident F# is the correct language in which to solve it.

The thing is, our knowledge of F# is firmly rooted in the “beginner” tier.

But our skill set as a PHP developer tells us that if we’re going to be writing code, we should probably be writing some tests.

At this point we have a few options:

• Don’t test
• Accept that figuring out how to test is going to slow down our prototype significantly, and resolve to pay that price
• Don’t use F#

I guess you could also outsource this to some high priced F# contractor.

The easiest approach here not to use F#.

We could likely fudge our way through whatever challenge we face by making use of the skills we already have. I’m sure you’ve encountered code like this before.

I’m not exactly sure how to find a Higgs Boson, but I reckon the best place to start is with PHP.

But this approach sucks. You’ve likely seen the advice: use the right tool for the job. PHP is often not the right tool for the job, but it gets used anyway. For every day evidence of this, just look to WordPress, where a blogging platform is being used as a help desk, business listing directory, or a shop. Heck, if you look long enough, I bet you’d find a WordPress website out there right now that’s doing all three.

By the way, that’s not a slight on WordPress which I think in itself is a brilliantly useful tool.

This leaves us with two options: Don’t test, or … learn how to test.

Skipping the tests will likely yield you a working system in a much faster time frame.

It’s when you need to continually work on, improve, and generally maintain your code that a lack of tests really bites you. It’s during this phase that all that time you saved up front is meticulously eaten away until suddenly, you’re on the wrong side of the curve and it’s a very long way back.

But I get it.

I mean – we barely know F#. How on Earth can we be expected to know how to write testable F# code?

It’s a really, really tricky spot to be in. I know, I’ve found myself in this very same spot in a variety of languages – from PHP to Python, to more recently Elixir.

Personally I’ve found it really hard to mentally accept that I don’t know enough to achieve what my mind is telling me should be really quite straightforward.

Ok, enough F#.

Back To PHP

I’ve found it really easy to forgive myself about a lack of testing when writing code in any language other than PHP.

It’s hard enough to learn a new language, let alone having the burden of writing some tests to prove my stuff works as expected.

But I’m going to assume you are past the absolute beginner phase when it comes to PHP. You feel comfortable with the syntax, and now you want to continue your learning by seeing what Symfony has to offer.

Even though you know PHP, and maybe you know how to write tests in PHP, applying that knowledge whilst learning Symfony kinda feels like we are back in that F# position again. It’s all new, and that can be incredibly overwhelming.

So here’s what we are going to do:

We are learning us some Symfony. That much should be obvious, given what CodeReviewVideos is predominantly about.

Along the way we are learning how to do common “stuff” with Symfony. Forms, database interaction, services, all that jazz.

Once we’ve seen how all this stuff works, we are ripping it out again and having another crack at it. Only this time, we are going to learn how to do it with tests.

In this week’s videos we are covering how to use PhpSpec to guide ourselves through this process.

If you haven’t already done so, I’d strongly recommend starting with last week’s videos.

There are a bunch of new concepts and techniques to learn here.

It’s true, testing isn’t easy.

If it were, we would probably all do it much more than we actually seem to do.

This week’s videos follow consecutively. To get the most of out of them, you really need to have been following along, at least since video 19 – No Tests – Part 1 – Uploading Files in EasyAdminBundle.

There’s really no excuse on this – all of these videos are completely free. I’d love to hear your feedback – as ever please either reply here, or on the video your questions or feedback directly relate too.

Whilst testing is initially hard to get started with, even having just one or two test files in your project is hugely beneficial to adding more (think: copy paste! although with PhpSpec, there’s a better way than that.)

Following Along

There’s a problem that I’d really appreciate your help with this week:

Thinking about a project where you would need to use RabbitMQ, or Redis, or the ELK stack, or any other potentially complex external software, how would you prefer to cover the setup of this stack?

I would really appreciate it if you could answer this one question survey.

I am running this survey until next Friday at 10AM GMT. After which, I shall share the results in next week’s newsletter.

As ever, thank you very much for reading, I hope you enjoy this week’s new videos, and that you have a great weekend.

Until next week, happy coding!

Chris