On the MayFlower blog today there's a new post looking at two ways to do software architecture (the easy way and hard way) and some of the traditional practices behind its development.

When it comes to software architecture, stuff gets funny. First we learn everything about it at university. We learn to use it as a part of our main project plan. We learn how to do risk evaluation. [...] Since we didn't have a lot of experience with software back then, the resulting architecture is a badly done, but well documented. This style of software architecture is called "Enterprise Architecture" and usually done by consultants.

They talk about delivering software versus delivering documentation and list some of the actual common reasons software architecture turns out how it does including: "I read about it in a blog", "It worked for me once" and the idea of the "Golden Hammer" of standardized structures.

This post is going to describe how I've ending up designing, what I consider to be a fairly RESTful web API. I'm far from being an expert, and this is definitely the closest thing to a RESTful API that I've ever created, so I'm not even experienced with REST APIs. [...] Until about 6 months ago, I'd always been sceptical of creating RESTful APIs, but I think I've had a few pennies drop since then that have made me fairly confident that I grasp the basics pretty well.

He touches on topics like: authentication, the Richardson Maturity model, HTTP verbs, sample request and response messages and some BDD-style tests to predict the output of a basic request.

On IT World there's an interesting article about the programming skills that seem to be lost in today's coders and how what they may not know might hurt them in the end.

Some of these skills aren't likely to be needed again, any more than most of us need to know how to ride a horse or (sigh) drive a manual-transmission vehicle. But other skills and "lessons learned" may still or again prove relevant, whether developers are banging their heads against legacy systems, coding for new mobile and embedded devices... or other devices and applications we haven't yet thought of. [...] Here's what some industry veterans and seasoned coders think the younger generation doesn't know ... but should.

He's broken it up into a few different sections - one dealing with the lack of general hardware knowledge by a good section of the today's developers, another noting that programming is not the same as software engineering (yes, really). He also touches on the lacking idea of "thinking before coding" and how planning for errors has become less and less of an importance.

If you've ever been to a conference and felt like they missed the target on the topics you wanted to see, Kevin Schroeder, an organizer for this year's Zend/PHP Conference, is asking for feedback from the community as to what they want to see at this year's event.

The primary responsibility I have, as being in charge of content is making sure that, well, we have good content. [...] While ZendCon may have the Zend name in it, it is the conference attendees who determine its success. It is whether or not you, as an attendee, are satisfied which determines my success in determining content. That said, I would like your input on what types of topics YOU would like to see. So if you have an opinion on what would make ZendCon compelling for you please leave a comment.

You can voice your opinion by leaving your comment on his post. There's already some good suggestions and lists for several hot topics around the community right now including deployment practices and community-oriented sessions. The date and the location for this year's event have not been released yet.

This post was sparked by a very simple question from an ex-colleague: "Why bother with PHP interfaces?" The subtext here was that the classes themselves contain the interface definition (through the methods they define) and hence interfaces are not needed, particularly where there is only one class that implements a given interface.

He talks about two reasons he things that interfaces could be beneficial - they help you think about things "the right way" of planning out structure before implementation and that it makes things more "future proof" the code by forcing future elements into the same mold as the current use.

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.

Padraic Brady has kicked off a new series of blog posts with part one posted today - a look at the creation of a sample Zend Framework blogging application.

Starting any new application is like walking into a shop and being dazzled by the displays. You want everything but finally realise you only have so much resources to spend. So you isolate the specifics you must have, and focus on those.

This first part focuses on the planning stages of the application. He works through the features he wants the blog to have and some of the external libraries he's going to rely on (things like PHPUnit and jQuery). His goal for the series and the application is to have something he can replace his current blog with and to provide readers a step by step detail of the progress along the way.

It's basically a piece of web-based software, written in Python and PHP, that allows you to allocate tickets from multiple Trac projects to a simple week-based 'board' in order to organise work priority for developers.

I've written about why we wanted this, and created a short user guide on the Trac site for the project. This is still in development and we're working on some more features (You can see what we've got planned from our timeline).

It's been released under the GPL and has a Subversion repository where you can grab the latest code from. There's also an installation guide that's been developed to help you get started.

The Zend Developer Zone has posted their latest podcast in the PHP Abstract series. This time, it's a focus on planning in your programming projects - how to get the most structure out of the simplest planning.

Davey [Shafik] is going to talk to us about one of the most neglected areas of software development, planning the project.

The International PHP Magazine is back this week with the results from their latest user poll that asked the question "Which Stage Comes First in the Development of the Basic CMS?"

Of course, of the options they gave, "Planning your CMS" came in with an overwhelming lead of 60.5 percent of the votes. Lagging far behind that was "Further Development" and "Database creation". It is good to see that a large majority of the people out there think that taking the time out to plan out the application first is the best way to go. Throwing something together, especially something that can get as complex as a CMS, is a very bad idea.

Be sure and get your votes in on this week's poll that asks which of the given options including "Web and command-line interface" and "Generates a todo list from @todo tags in source") wouldn't be a good option to be added to the phpDocumentor functionality.