The newest 7.X version matured well and it’s hitting hard to the market. Ethics and morality issues are now more commonly discussed among tech community, so let’s see what did we find at the biggest International PHP Conference ever.
Inclusive Design and Ethics
As Laura Kalbag told, author of Accessibility for Everyone, we need to start thinking inclusively instead of adapt our websites later on, so everybody can freely consume our content without any problem and enjoy it as well. Nobody wants to listen to a list of 100 cities SEO-tagged on the page’s title when accessing to a news webpage via screen reader…
There aren’t disabled people, just disabled websites blocking people away.
Everybody love minions and train them to become what they are meant to be: the true warriors of our technology stack!
But how do we train them? During how many time? How do we scale up our small startup’s squad to become a battalion? What’s the success key for our army to perform effectively?
The ideal training time to evolve from minion to warrior is 3 months. Doing the same exercise or kata 3 times, first just with the main PHP documentation (or whichever language is the minion meant to learn), later on introducing git and an IDE, and finally using a simple MVC framework, erasing the job done at the end of every iteration. The exact training path can be found in Gerogiana Gligor’s slides.
The success key to scale up and perform effectively is the communication. As less team members, less communication channels in our teams. So, smaller teams of around 5 members will avoid communication troubles and improve effectiveness.
The main focus of the conference was coding related, coming up next some highlights:
Is Microservices the right word for them? Why don’t we change it for self-contained systems? Because is it what they really are, right? Nowadays everybody knows about microservices architecture, but not all of them are well implemented. This architecture should be a bunch of loosely coupled services which allows to deploy, scale and test separately and in a more sophisticated way. Each service should have a clear purpose to avoid share logic through all of them, having specialized apps in our business. A cool tool to manually test them is HTTPie but please, do not forget to automate the tests!
Code Reviews are important, but how often should we do them? How deep the analysis has to be? In fact, if we focus on reviewing code just for a specified time-box when we can, let’s say an empty 15 minutes after finishing a task but before a meeting, we will improve a lot the quality of our codebase.
But be careful, we don’t want to waste our time reviewing code style, misspelled variables or other simple bugs that can be automatically detected. We could just add some git hooks or automated CI tools to avoid those and go find the early legacy!