At SunshinePHP in January, Elizabeth Naramore gave a talk on how GitHub uses GitHub internally for projects that may or may not involve code. For example, all requests for sponsorship are turned into issues, which are tracked, tagged and labeled.
After this talk, I decided to create repositories for the purpose of tracking bugs in my books. The idea was that I would have a place to track the issues, and that readers would be able to file their issues with the books in a place that most of us are familiar with using and interacting already. No writer is perfect, and no book is published without bugs, so it seemed like a win for everybody.
With a couple projects wrapping up, I will once again have some free time to take on additional work in the form of contract or long-term projects.
With more than ten years of experience in PHP development, I’ve worked on both large and small code bases alike. I am available to provide help modernizing a code base, training your team in best practices, and implementing features. I’ll help your organization move faster, with less stress, in whatever projects you’re currently working on.
During the recent Crafting Code Tour, Paul Jones would ask people who was currently using Composer. It was a rare night that more than half an audience raised their hands, meaning that the best invention in the PHP world in the last three years is still not being widely used by everybody. I want to share a bit about how to get started with Composer, and why you should care in the first place.
What is Composer?
I speak a lot on design patterns. This year, I’ve given nearly a dozen talks on design patterns, relating to my book, Practical Design Patterns in PHP. One of the questions I get the most often about design patterns is, “how do I pick a design pattern to use in my project?”
My answer is always the same: you don’t.
There’s a large group that seems to think I’m against frameworks of any kind, telling beginners that instead of using a framework they should learn straight PHP, build stuff from scratch.
I’m definitely not interested in that.
Towards the end of my talk at phpDay in Verona, I was asked by two developers which framework I thought they should learn: Symfony or Laravel. I understand the pressure that developers feel like they’re under to learn a framework, and to somewhat “predict the future” by figuring out what is likely to be popular in PHP for the next few years.
But my answer to them wasn’t what they expected. I told them that if they were new to PHP, that they should focus on learning PHP.