The Master Zend Framework site has posted a new tutorial showing you how to [use the ReflectionBasedAbstractFactory for prototyping](How To Do RAD Prototyping and Development With The ReflectionBasedAbstractFactory) and development in a Zend Framework 2 application.

Rapid application development isn't normally associated with Zend Framework. That's considered Laravel's domain. But thanks to the ReflectionBasedAbstractFactory, prototyping and rapid application development is now just as easy in Zend Framework as it is in Laravel. In today's tutorial, I'm going to show you how.

When using Zend ServiceManager, it's quite common to create a factory class for any class which require constructor dependencies. While tedious, it ensures we both follow development best practices and that the code we create is fully testable.

However, if we're not careful, it can lead to an enormous amount of factories — perhaps where we have one factory for every class. Needless to say, that can seriously hurt development. There needs to be a better way. And there is!

The ReflectionBasedAbstractFactory is included in the 3.2.0 release of Zend ServiceManager and makes use of the Reflection API to do some automagic, handy things. The article starts with some reasons why you might use it and a brief look at how it works. It also points out that, despite how it makes things easier on the developer it's "not for production" and instead relying on the other configuration handlers to help out.

The Scotch.io site has a tutorial they've posted showing how to prototype a site quickly using Laravel and its built-in server/SQLite support.

If you are a seasoned Laravel developer, you know the usual project setup drill that involves creating a new project, a fresh database, and adding a virtual host entry to Apache.

If you are starting from scratch, the Apache and MySQL installation can take some time and slow things down for you. However, I will show you how you can jump start your Laravel development without Apache and MySQL.

The tutorial shows you how to use the internal PHP server to host the application, run a Laravel site inside it and integrate SQLite as the database. Each section comes with some example code and the commands/configuration you'll need to make the system work. They also take a "deep dive" into Larvel's serve command and how it bootstraps the Laravel instance for the PHP built-in server. The post ends with a look at switching back to MySQL and a comparison of SQLite vs MySQL (as well as using SQLite for production).

Anna Filina has a new post to her site today suggesting that developers are like athletes, they need to practice before they can be good at what they do.

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.

Brandon Savage has posted some of his thoughts on when it's okay to write bad code in your development lifecycle:

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.

In this new post Ralph Schindler takes a look at the Prototype design pattern and uses it to illustrate some best practices in using constructors in PHP.

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.

In this recent post on Reddit.com, there's some good discussion/feedback about the proposed redesign of PHP.net.

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!

On NetTuts.com today there's a new tutorial posted about using a microframework for prototyping an application you may not need a full stack framework to get running. Their examples are based on the Slim framework.

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.

Lorna Mitchell has posted about an API release she's made for the Joind.in website today - the first stages of a completely reworked version of the site's API.

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).

In a recent (quick) post to the php|architect site Koen Van Urk reminds us that it's not all about the code, there's planning to consider too.

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 new post to the PHPInfo site, Brian Fioca takes a look at the WASP framework and how it can help you develop your applications quickly.

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.