Think of a developer as an athlete. He or she is aiming for a medal in a competition. A figure skater can't just perform a triple axel in the Olympics after seeing it done on television. This requires a lot of practice, so that when the time comes, the performance is flawless. Of course, programming doesn't have to be flawless. One must remain pragmatic, yet it still requires practice before a concept can be safely implemented without breaking the project or missing deadlines. Who will pay for that practice?

She relates the development manager to the coach of a sports team, being the one that guides the developers into being all they can be and trying out new ideas in the process. She also recommends making use of idle time between projects to prototype, do R&D and learn in general.

Developers need a sandbox. If you don't give it to them, you can end up with one of the following issues. Your entire project could become a sandbox, making it unstable. [...] If you want your developers to get better, allow time for practice, not just learning. It's necessary, easy to do when planned and provides countless benefits to your company. Let me know how that advice worked out for you.

I've been there myself. I recently needed to prototype something. As I sat down to work on it, I had absolutely no idea how I was going to write the component I was working on. And so, I started working - without a plan, without writing tests, without designing an architecture, and without really knowing how the component was going to end up. You know what? The component came out working, but when I was done it was ugly. Totally ugly. The code was bad. But I had a solution, and a solution that worked.

He points out that sometimes, doing things "the right way" can stifle creativity and experimentation - two things that a developer needs to solve the problems they face day to day. He notes that refactoring is a part of their job and moving from a rough prototype to a finished product often improves this skill and can find issues not discovered before.

This does NOT mean that developers can push bad code into a repository. Nothing lives longer than temporary code; see to it that your finished code is always good.

If your knowledge of constructors ends with "the place where I put my object initialization code," read on. While this is mostly what a constructor is, the way a developer crafts their class constructor greatly impacts the initial API of a particular class/object; which ultimately affects usability and extensibility. After all, the constructor is the first impression a particular class can make.

He starts at ground level, reintroducing what a constructor is and what it should (and shouldn't) be used for. He talks about constructor overloading, constructor injection, dynamic class extension and using the Prototype pattern to create "an unlimited number of objects of a particular type, with dependencies in tact, each with slight variations." He gives an example with a "DbAdapter" class, showing dynamic class instantiation and how to, using the Prototype method, inject a DbAdapter object and have your class use that instead.

Opinions from commentors range widly:

• "The layout's nice. But those colors are downright disgusting."
• "To be honest, the new version is 100x better."
• "It's definitely way better than the old design but still not exactly great is it?.."
• "Much more profressional. Welcome to the 21st century PHP.net."

Have an opinion on the new layout? voice it here!

Let's face it: we all have great ideas for a web application. Whether you write them down on paper or remember them using your eidetic memory, there comes a point when you want test whether or not your idea is really viable. In this tutorial, we'll use a micro framework, a templating language and an ORM to rapidly develop an application prototype.

There's an introduction to help you get Slim, some extras, Twig templating and Paris and Idorm set up and working happily together. There's code included for bootstrapping the application, creating a few routes, building models and using them to pull data from the database. They also create an "admin" area for their sample blog application, building an "add article" form and protecting it with a simple login system. You can download the source if you'd like to see it all working together.

Following the principle of "release early, release often", I put live a very early version of the v2 API for joind.in today (so that I can use it in another project!). I haven't updated the documentation yet but in case anyone was thinking of consuming data from joind.in, this at least gives you an idea of the direction of the project so I thought I'd share.

The new service is RESTful and has a few working features already including fetching event and talk details, pagination and multiple output formats. You can find samples of the output here and here. If you're interested in seeing the source so far, check out the github account for Joind.in (and maybe even clone a copy).

Sure, it is important to have your code as bug free as possible, well documented and as optimized as possible. It is, however, impossible to achieve this all without prior planning. Good project coordination.

He suggests one of the most useful and reliable forms of planning and defining the requirements for an application - writing them down on a normal piece of paper. Then from there let the ideas flow with things like look and feel, mapping out page structure, etc. Website planning tools are good, but when it comes down to basic prototyping, sometimes there's just nothing better than a pencil and a few sheets of plain white paper.

In this article I will demonstrate the power and simplicity of developing PHP applications using the WASP Framework through the illustration of a simple user module design pattern. The example code will encompass the creation of a user account and subsequent login validation. In the course of this discussion, we will cover the creation of the three tiers of the application- model, view, and controller-and introduce a simple approach to using AJAX to save application form data and present flexible user interfaces.

The provides the code and database structure to make the application work, including the "touch of Ajax" made using the Prototype Javascript library.

Learn the process of writing Asynchronous JavaScript + XML (Ajax) applications using native JavaScript code and PHP. This article introduces a few different frameworks and application program interfaces (APIs) that reduce the amount of code you need to write to achieve a complete Ajax-based Web application.

They (briefly) explain what Ajax is and the benefits of it before jumping right in to a sample page. They go for the "manual first" approach so developers know to make basic connections with the XMLHttpRequest object and handle the responses. They do mention some of the libraries offered that help with the connections too (like jQuery, Prototype and Dojo).

Finally, a link to the shopping cart is provided, although you could just as easily have displayed the cart contents on the same page. For the sake of brevity I'll just show you how to integrate the add feature, and will leave the subtraction mechanism to you as an exercise.

The Ajax frontend calls a managecart.php backend file that calls addToCart and deleteFromCart based on which type of "task" is passed to it.