We’ve all been there before: we’re sitting across the table from someone, who is interviewing us for a new position. We’re getting close and we know it because the conversation shifts from talk of “…if you come on board…” to “…when you come on board…” And suddenly you have a thought that strikes fear into the core of your heart: what kind of code base am I getting myself into?
The truth is that nobody is ever going to volunteer that their code base is a complete mess (I’ve had it happen maybe once), and short of asking to see the code before you start, you’re not going to really know what it’s like until you dig in. Many if not most companies would be reluctant to open their code base to an outsider, so how will you know in advance?
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.