On NetTuts.com today they've posted a list of tips they think will help you learn a new technology faster. They've broken it up into ten different steps, some which could be done at any time but some have a bit more of an order.

We live in a very exciting time. Never before has education been so cheaply available to the masses (if not free). The medium, itself, has made tectonic shifts from a classroom setting, to blogs, screencasts and complete university classes, as a set of videos and interactive forums. Given these resources, there's absolutely no excuse not to dive in and learn. However, with such a wealth of resources, filtering through the options can often become overwhelming. In this article, I will outline a simple process to kick-start your education.

Among the items in their list there's things like:

• "Let the Information Flow Begin"
• "Listen and Watch"
• "Blogging"
• "Feel the Pulse"
• "Meetups and Conferences"

Each tip comes with a bit of description and some links to other resources and tools that can help you along your way.

PHPMaster.com has posted a list of six things they think you should think about as you're selecting the framework for your next application.

You've decided that it makes sense to use a framework when writing your next new application, and chances are that if you're already familiar with a specific framework, then you'll probably be leaning towards using that one when you start. But are you sure it's really the most appropriate for the task at hand? In the name of due-diligence, here are some of questions that you should ask yourself before settling on a particular framework to make sure you're not programming "against the grain" and also to make sure it will be able to meet your needs now and in the long-term.

He doesn't get into any specifics of any PHP frameworks out there, but suggests general questions to ask even before getting too deep into the technology:

• What do I need from the framework?
• Do I expect the framework to help manage consistency?
• Is good documentation available?
• Is the framework actively developed, and does it have an active user base?
• Does the framework work in what I run in production?
• What business factors are influencing my decision?

Not every application needs to be written using a framework. But if you've decided that yours does, then it's beneficial to compare your needs against the features and benefits of the various framework offerings.

On Reddit.com a discussion has started up around a question asked about legacy application migration - things to consider when moving a large existing project onto a framework.

I am working for an online store that has a codebase which has spanned dozens of developers and has been constantly upgraded. The codebase has its problems but it is not too bad. I would love to put it onto a framework like laravel and systematically start cleaning up as I go, but I am unsure if it will work trying to shove a framework into the current site. Has anyone done something similar, it would take me months to rewrite the whole system, has anyone done something like this successfully? Any advice would be appreciated.

There's lots of good recommendations made in the comments including:

• "If it were me, I'd take a step back before trying to build on top of a framework. I'd start by refactoring the existing codebase out into PSR-0 compliant namespace."
• "In my experience you only rewrite an entire application if what you have has become too expensive to maintain. At this point it is actually more cost effective to rewrite it using a framework."
• "We have recently moved our website to the Symfony2 framework at my company [...] it definitely is not a one programmer job."
• "Whatever you do, replace one bit at a time. And always strive to de-couple code."

Read up on the rest of the responses or add your own to the post.

On Reddit.com recently, it was asked what kinds of things someone would need to know if trying to move from being a senior developer to a lead developer in their role. There's lots of answers - some serious, some not - but it's an interesting read.

I'm fairly confident that I am able to move into a lead developer role quite easily. I have worked in many places where the CTO was so incompetent that I've ended up doing a CTO's job as well as coding. Now I want to find a job where I can be a good lead developer. I might have some holes in my self-taught PHP knowledge, so what do you think I should know?

Some of the recommendations include:

• "The lead engineer is not the smartest guy in the room. Sometimes you will know the right answer, but just telling people what to do won't always get the right results. Ask them how to solve problems and let them own it."
• "It may be different where you are but I expect lead developers to be more of a 'lead' as in 'leader' than 'lead' as in 'best developer'. That is, you'll probably be expected to actually manage, delegate, and architect on top of your development abilities."
• "The lead dev will guarantee the whole architecture of the application and the processes of development."
• "If you, as a lead dev, are project managing then your employer is doing it VERY wrong."

Check out the full post for more discussion and to add your own thoughts.

In his most recent post Chris Hartjes looks at the concept of "test whenever" (vs TDD) development practices and how, sometimes, writing tests for things that are may get tossed when they're done may not be the best option.

Let's look at TDD vs. Test whenever. The trade-off being made here is not about quality of code or guarding against regressions. It's about opportunity cost. This had occurred to me but I had dismissed it as being "anti-testing". But I think I was wrong, and here's why.

He talks some about a presentation from Dan North< ("Decisions, Decisions") about when to test (not whether to test or not) and how he noticed his development team was being very productive, but with a "spike and stabilize" development method. He also talks about the concept of "opportunity cost" and how it plays a factor in when tests are introduced to the process.

The key to all this is being able to identify at what stage in this particular pattern your code is at. Is it still a spike, meaning you are working out implementation details and trying to figure out if it will even have the desired result? Or is it stable, providing solid value to the application as a whole and ready to be wrapped in tests to protect against regressions?

Adam Culp has written up a great post with some good suggestions about how you can more effectively foster a better technology community in your area or company.

As most know, I am the organizer of the South Florida PHP Users Group and I am passionate about helping the PHP community grow in south Florida. Over my years as a developer I have noticed the decline of technology in this market, and specifically the PHP community. It was this that led me to organize a group dedicated to turning this trend around, and and grow the PHP community rather than continue to watch it decline.

He shares suggestions on a few different topics, spurred by a conversation at a recent meeting he attended:

• Having a litte-to-no distraction workplace
• Being open to telecommute/remote workers
• Avoiding the "sweat shop" mentality
• Advocating bringing in a fresh perspective (hiring an entry-level dev)
• Supporting company-provided training opportunities
• Respect them as professionals
• Not worrying as much about salary and more about the quality of the developerA

Chris Hartjes has written up a new post for his site, So you want to write tests, giving a good overview of some of the things you'll need to consider when wanting to move into a more test-friendly development world.

I often get asked for some advice on how to get started with writing tests for your PHP code. It's a fair question, since I am presenting myself as an expert-ninja-rockstar-sensei-opinionated-egomaniac on the topic. I often struggle with coming up with an answer that can fit into the 140 characters available via Twitter, but clearly this is not a good strategy. As an early Christmas 2012 present to all my loyal followers, who put up with my never-ending stream of nonsense and provide a slowly-increasing portion of my income, here are my thoughts on how to get started with testing your PHP code.

He offers a list of suggestions, each with a bit of explanation:

• Learn how to recognize untestable code
• Keep learning the language
• Chain units of code together for greatness
• Start asking "how am I going to test this?"
• Stop people from pushing code without proof it's fixed
• Stop people from doing things manually
• Stop using tools without test suites
• Always wonder if you're doing it right

In a recent post to his blog Grzegorz Godlewski talks about some of the criteria to consider when selecting your source code management tool (between Subversion, Git and Mercurial).

Each of them has its own advantages and disadvantages so the project's requirements, development environment and team members receptivity should be taken into consideration. Relying on my own experience in project management and using version control systems to manage the development process I've formed the conclusions listed below that may be helpful while considering usage of one of described SCM's in your own projects.

He talks about how the size of the project can effect the decision and a bit more detail about what each of the version control systems are good at. The PHP project itself has recently made the shift to git away from Subversion (you can find more information on the PHP.net site).

In this recent post from PHPMaster.com Aaron Saray gives a few helpful hints (and reasons to speak) for the aspiring presenters out there wanting to give their first talk at a PHP (or any technology-related) conference.

Your heart begins to race. Suddenly, it's stifling hot in here. Your palms begin to sweat and your knees are threatening to give up and flee to a vacation in Cancun without you. The dull rhythmic thump-thump in your ears heightens to a frenzied jack-hammer. You can't remember a time when your mouth has been this dry. It's time to begin - and your voice cracks. It's public speaking time and you're the next one up. In this article I'll cover the basics of why presenting PHP is important, who can present about PHP related topics and what you can do to make your presentation stand out.

He starts off by answering the "why" question - why even give a presentation at a conference or local user group? His answer has a few parts and involves things like giving back to the community and being considered an expert in the field. He follows this with a few ways to help your talk stand out - include code samples, give live demos and be entertaining.

If you're into Open Source software (doesn't matter if you're new to it or an old hand), you'd do well to check out the book Henri Bergius has posted about - that he also contributed to - "Open Advice - FOSS: What We Wish We Had Known When We Started".

As quoted from the LWN review of the book:

Open Advice is a book that will be helpful to those who are new to FOSS, but, because of the individual voices, styles, and tones, it doesn't read like a "how to". It could even be recommended to those who aren't necessarily interested in contributing, but are curious about what this "free software thing" is all about.

It contains real experience from real developers that work on FOSS projects with chapters titled:

• "Code First"
• "University and Community"
• "Love the Unknown"
• "Quality Assurance"
• "Good Manners Matter"
• "Stop Worrying and Love the Crowd"

The book is licensed under a Creative Commons license (CC-BY-SA) and can be downloaded in multiple formats - ePub, mobi, PDF and paperback, if you prefer that.