I like the beginning of a new year because it provides the perfect place to consider what happened last year and what I can do this year. In evaluating 2012, I’ve come to the realization that as a software developer, I need to “up my game” somewhat. Though I consider myself to be a great developer, I want to be even better, work even ahrder and share even more with the communities that care about the topics I care about. Software development is an art form, and I want to perfect it in 2013.
Including today, there are six business days remaining in 2013 (five if you are lucky enough to get New Year’s Eve off). My brother used to call this week “the lost week” – there’s hardly anything to get done because so many people are on vacation or preoccupied with setting goals for the new year. But the downtime provides a perfect opportunity for the aspiring software developer to do the one thing they are always told there’s no time to do: make the code better for better’s sake.
With few deadlines and plenty of free time, most developers can get a few hours of refactoring in to their code towards the end of the year. They can rearchitect sections that were implemented with haste in September; they can write tests for sections that were untested in April. Put another way, the “lost week” can be redeemed.
Maybe you struggle with object oriented code, understanding it and writing it. Perhaps you’re tired of having to rewrite code that doesn’t pass code review or introduces a bug you didn’t expect. Maybe you’d like to impress your boss by improving your skills without having to attend an expensive conference.
If any of that describes you, then I have good news: Do This, Not That: Object Oriented PHP is almost here! I’m launching it tomorrow to subscribers to my mailing list, and then on Wednesday to the general public. But here’s the catch: I’m offering a special 20% off launch day deal and it’s only available to people who are members of the launch list!
This is a rebuttal post to comments posted Private Methods Considered Harmful
I do not wholeheartedly believe that private methods are evil, or that they were mistakenly included in the PHP language by the core development team. Nor do I believe that there are only two true options when it comes to devising visibility requirements: public and protected. There is a place for private methods, in PHP development and elsewhere.
The following is an excerpt from a draft version of Do This, Not That: Object Oriented Development. Sign up today to be the first to get a copy this week!
A few weeks ago, I was tasked with integrating a library that was designed by someone else. This library was intended to access APIs and return the data so that it could be used by my application. This seemed straightforward enough, except that the API I was working with had a few quirks, namely that it interpreted the query string directly, and so it was possible to have a query string similar to this:
When I was a new PHP developer, I discovered that there’s a myriad of solutions, options, configurations and frameworks available. I thought, how does one sift through all the noise and get something done? How can anyone have a grasp of the best practices in PHP, and make sense out of all the options? Which extensions do we use, and how do we use them? What’s a best practice, anyway?
This is why I’ve decided to offer “Do This, Not That” for beginning and intermediate PHP developers looking to find a better grasp on precisely how to develop in PHP. This great series of highly focused e-books will offer tips, tricks and best practices focused on core areas of PHP development, including databases, security, filtering, regular expressions, configuration and more. Since it will be a series of tightly targeted solutions, developers will be able to pick all, some or just one of the offerings that solves their specific problem(s).