Note: The recommendations in this post are intended for a very advanced audience. While the content applies broadly, creating and maintaining your own framework is not advised for everyone, unless you know exactly what you’re doing.
For many of us in the PHP community, our identities are as much tied into the framework we use as the language that powers our products. For better or worse, we often tie our careers to a particular platform, and we spend considerable energy on the community and culture of that platform and it’s supporting tools.
Whenever I give lessons on the Single Responsibility Principle, I always teach that object creation is a job, and that it should be separate from classes that are using the objects. Continue reading
The biggest complaint people have about object-oriented design is where they put all the “glue code” that ties together a bunch of objects and makes them work well. For many, this place is the controller, but as I’ve covered before, most of this logic belongs in the model. In fact, the model should be where all business logic resides. And yet, it can still seem difficult to figure out precisely how to manage all of these behaviors in one place and still follow the best practices of object-oriented design and development.
But there is a way to accomplish this that won’t make you crazy. It’s accomplished by making use of “services” – bits of code that act as the “glue code” for all the different objects that have to operate.
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.
Object oriented PHP can be a struggle. It’s complicated, difficult, abstract, obtuse. You fight. You end up with a headache. You wish there was an easier way to learn object oriented PHP.
Ever since releasing Mastering Object Oriented PHP in December, PHP developers have had an easy and straightforward way to learn how to write better object oriented PHP. It is possible to write better object oriented PHP; Mastering Object Oriented PHP can help!
Like many people, I upgraded my iPhone to iOS 6 this afternoon. The update for me wasn’t all that exciting, being that I’m on the Death Star network, but it was still worthwhile to upgrade for the Do Not Disturb features.
Shortly after updating, it seems that the wifi connectivity stopped working for me, as well as for lots of other people all over the world. Many people got a screen, similar to what they see when they log in on a wireless network that requires payment or agreement to certain terms and conditions. It appears that whatever URL the iPhone utilizes to determine whether or not connection to the outside world is established was returning a 404 error – not what the iPhone expected, and thus resulting in the display of the Log In screen.