On PHPMaster.com today there's an article with some good suggestions about ways to deprecate parts of an API safely.

Deprecation can happen for various reasons - perhaps an API is no longer useful and has reached its end-of-life, or the refactoring of code to improve its reusability and testability obsoletes particular methods. In this article I'll share with you some key points that you should follow when deprecating APIs so you can continue to grow your code and provide fair warning to those who depend on it.

They break it up into a few different steps:

• Prepare for Refactoring
• Employ the Single Responsibility Principle
• Communicate with your Users
• Remove the Old Code

As developers, one of the best things you can do for a project is to use version control (or "source control") for your code. Lorna Mitchell suggest using it on a wider scale, though. She sees it as a great place for all sorts of other things around a project too.

Short answer: everything! However we need some good directory structures and source control configuration to make that a really practical answer, so this article is a quick outline of my usual advice for a good source control structure for a standard web project. The examples are for a PHP project but I'm sure you could apply this to your own language of choice, also.

These "other things" she suggests that should end up in source control including things like:

• The actual "web root" of your application
• Library code
• Build scripts
• Configuration files
• Database patches
• Tests (unit, functional, integration, etc)

On Reddit.com a reader has asked the community what they think he needs to do to progress his PHP skills past the "little bit" he's learned so far.

Last summer I started learning a little bit of PHP, knowing HTML and CSS drove me towards wanting to learn some PHP for fun. I went through a pretty simple book, and made some simple websites (registration and message system, user submitted data, file uploads) using mostly tutorials which I tweaked a little bit. Since last summer I haven't learned anything new, but now that summer is coming along again I might be a bit bored, so I have been thinking of attempting to learn even more.

Suggestions included in the comments are things like:

• Learn about software architecture.
• Understand your environment.
• I very highly suggest learning a PHP framework.
• http://www.phptherightway.com
• Start learning industry tools for PHP. It will all influence your coding style, and illustrate why some styles are considered best practices.
• To add to the other suggestions, I recommend becoming a regular contributor to one or more open source projects.
• What helped me a lot was to write my own micro framework using OOP that I can now use for future websites and web applications.
• Come up with a 'complex' web site/application idea and get to it. Bonus points if you can launch it and make money off it (half kidding).

You can read the full set of comments for more good suggestions here.

On Reddit.com there's a conversation kicked off by user swiftpants about making the move from procedural PHP programming to the world of object-oriented programming. They ask for advice from the community for the next steps to take to make the jump.

One thing I always have in the back of my head is that all my code is procedural and I should be making use of classes and ?? more. I have a very basic understanding of OO programming but I rarely implement it. Is there a good book or online guide that can get me on my way to OO programming in php. I am especially looking for feed back from self taught programmers.

There's lots of comments on the post talking about everything from:

• Introductory videos from KillerPHP
• Reading lots of other people's (OOP) code
• That OOP is more about code reusing and simplicity (DRY) than abstraction.
• You can learn a lot by working with one of the MVC/OO frameworks. Download one and build something.
• The suggestion of phptherightway.com

Have any other thoughts on the best ways to learn OOP in PHP? Share them here!

Brandon Savage has posted some ideas about making conferences better and how they can appeal to a wider (and maybe more inexperienced) level of developer.

I love PHP conferences. I attended a lot of PHP conferences when I was a brand new developer. Zendcon, OSCON, php[tek], Wordcamp Baltimore, DC PHP and others were my stomping grounds. I learned a lot, and the conferences I attended were on the whole useful, beneficial and wonderful experiences. But I also felt challenged by the fact that conferences don't offer much for bringing up new developers with concrete information and training. This isn't necessarily the fault of conferences: it's impossible to truly impart a useful skill into a developer with only a 45 minute talk.

He includes four ideas in the post and talks some about the role of training at the events:

• Are conferences even the right place for training?
• Creating Different Tracks of Different Lengths
• Including Hands-On Training During Tutorial Days
• Offer Learning-Focused Hackathons

He also notes that some of it is up to the developers to find a good fit for what they need and the skills they're looking to learn. There's other options out there besides just the usual conferences, too and, as Brandon states, "investing in your career is the most valuable thing you can do for yourself."

In a new post James Fuller has shared a list of programming podcasts he suggests you take a listen to as this new year starts off.

I have a long drive to work, and one of the things I do to pass the time regularly is listen to podcasts in the car. I really enjoy programming podcasts and conference talk recordings, and it's a really great way to educate yourself on the go. I wanted to throw a shout out to some podcasts that I haven't previously mentioned on the blog and hopefully turn on a few new listeners.

He's included six different shows in the list, some with a slant towards certain languages, but still valuable for developers in others:

• /dev/hell
• Giant Robots Smashing into other Giant Robots
• Programming Throwdown
• Javascript Jabber
• Hanselminutes
• Herding Code

If you're going to be rolling your own user handling in your application, no doubt you've heard that something like bcrypt-ing your passwords is a good idea. Well, Anthony Ferrara has some suggestions for you and shows you seven ways you can "screw up" when trying ti implement it.

There are numerous articles on the web about how to properly use bcrypt in PHP. So this time, rather than write yet-another-how-to-use-bcrypt article, I'm going to focus on the mistakes that are commonly made when implementing bcrypt.

Here's the list of seven ways (each has its own description in the post):

• Using A Non-Random Salt
• Using An Incorrect Random Source for Salt Generation
• Using Too Weak Of A Cost Parameter
• Using The Wrong PHP Version
• Using The Wrong Prefix
• Not Checking For Errors
• Not Using A Library

He also includes two "bonus" things to consider: "Not Using A Timing Safe Comparison" and "Not Encoding The Salt Correctly".

if you've ever considered contributing to a PHP (or any other technology conference) but weren't sure about how to even get started writing up a proposal for a session, you should check out this recent post from Ben Ramsey with a good guide (and some advice experienced speakers could use too).

Earlier today, I was asked "Any tips on how to write a proposal for a major conf?" I've never shared tips on this, and since the calls for proposals for Sunshine PHP and Midwest PHP both end tomorrow, I thought it would be a good idea to share my approach to writing conference proposals. Remember those standard, five-paragraph essays you used to write in high school? Remember how you thought they sucked and wouldn't provide any practical benefit to your life? Well, it turns out they do have some redeeming qualities.

He suggests that this "five paragraph essay" format helps you not only come up with a more fleshed out, full idea but also can provide you with the abstract to submit to the conference (possibly the first paragraph). He mentions the need for a "hook" and finishing off with an opinion that's the basis of the talk. He also has a reminder of a few things - don't talk down, don't use negative language and try not to use absolutes.

On his Reflective Thought blog Luis Atencio takes a look at the current state of dependency injection in PHP and shares a simple refactor from non-DI to code that uses it as a service locator.

If you have worked with frameworks such as Spring or Google Guice, you will understand the power and flexibility that dependency injection provides your humongous code base. [...] One quick drawback that I see is that the stateless nature of PHP makes things like object containers not very practical.

He proposes a slightly different kind of dependency injection system, one more akin to what's provided in the Java world where annotation and reflection are components of the integration. He provides a code sample of how this would look and points to Java's JSR-330 standard for some of the annotation examples (like "@inject" or "@scope").

PHPMaster.com has a new post with ten helpful tips for you to consider using during your development. These tips can help to not only make your current development simpler but make for easier to maintain, stronger code in the future.

Good code is maintainable, reusable, and testable. The following tips address how you and/or your development team can handle various coding tasks and how to keep everything as neat as possible. I will introduce you to some "best practices" that will help you write better code and help make you and your team happy and efficient.

Among the suggestions on the list, there's things like:

• Use a Coding Standard
• Refactor
• Use Meaningful Names
• Use Automated Build Tools
• Use a Testing Framework

Links are provided in several of the tips to other resources/tools that can provide you with more information about how to use it in your development.