Depending on how closely you follow the Symfony community, you may or may not have seen the Grafikart story last weekend. If you didn’t see it, the gist of it is that lawyers demanded Grafikart remove their Symfony tutorial videos from YouTube.
As best I understand it, the laywer(s) believed they had found potential issues with trademark violations on their tutorials.
The aftermath of this was particularly interesting to me, what with a large part of CodeReviewVideos content being in a very similar category – i.e. Symfony tutorial videos, a number of which are on YouTube.
Now, thankfully, without much delay, Fabien Potencier got involved and resolved the issue:
— Fabien Potencier (@fabpot) March 14, 2017
Phew. Ok, so crisis averted.
However, whilst all this was happening I do have to say that there was an anxious knot in my stomach. It concerns me that the vast majority of the content on the site is about Symfony, and if this had gone the other way, the site may be offline right now.
That got me to thinking: Are all my eggs in one Symfony-shaped basket?
Right now, I would say 8 out of 10 of my eggs are Symfony-shaped eggs.
Historically the vast majority of the content has been focused on Symfony. More recently the content is Symfony alongside some front-end framework / library. I favour React, but have covered Angular, and Ionic.
Whatever front end you choose, Symfony – in my experience – can make a wonderful back end.
I still believe that the Symfony framework is the very best way I can be productive with PHP in 2017. There are always other frameworks and languages popping up that try to seduce me with their new and shiny, and there likely always will be. But when stuff needs to get done, it’s PHP and Symfony that I go to.
As many know already, I started CodeReviewVideos because I found learning Symfony to be difficult and stressful. This stress is amplified many times over if you have to learn Symfony “on the job”. That stress can be greatly reduced if you have access to a library of videos that explain the various ways and means of working with the framework to help you through.
Everything I learn, and have learned on this journey I share with you via the site. If its working for me, then chances are, it will work for you too.
From the feedback I’ve had recently, I’m excited that many of you are open to different types of video / tutorial content. Node JS gets requested a lot. I would also like to cover Elixir. And of course, lots more React.
All of this said, I’m not stopping recording Symfony content. I just spent a week recording loads of new content, and have another week booked in to do even more at the end of this month.
I’m interested in your opinion on this. Please can you hit reply in the comments below and let me know your thoughts?
This week there have been four new videos added to the site.
In this video we are getting started with Workflow Guards.
The concept behind a Workflow Guard is simple enough: We want to block a transition if some criteria that we set is not met.
This criteria can be as simple, or as complex as you require.
Guards are going to give us a surface level skim of Events inside the Symfony Workflow Component, which will stand us in good stead for our deeper dive in a couple of videos time.
There are three different ‘levels’ of guards. In the previous video we look at the first two, the more generic guards.
In this video we cover very specific guards, and their potential use cases.
We also look at a way of improving the error message output – this might be a little controversial, but hey, it’s working ok for me so far.
One of the pain points I encountered when working with a Symfony-backed JSON API and React on the front end was dealing with error messages. In particular, those returned from a Symfony form error.
There’s likely a bunch of ways of addressing this problem. My advice is to use TDD to ensure your solution behaves as expected. Handling errors is painful for sure, but it’s pain worth enduring so your end users aren’t left scratching their heads.
In this video we start building an error helper function which takes the returned JSON form errors, and extracts useful information from those errors, allowing display on our Redux Form front end.
In the previous video we made a start on the form error helper.
Whenever you nest anything – in this case an ‘if’ inside and ‘if’ – you increase the complexity of your code. Nothing gripes me more than opening a file to find some “christmas tree” shape where ifs are buried in ifs, buried in ifs… oh and a lovely else at the end with another if inside it. Who are these people who can keep this in their heads?!
Ok, until next week, have a jolly fine (and hopefully sunny) weekend, and happy coding!