TutsPlus.com has continued their "Building Your Startup with PHP" series today with this latest tutorial covering the creation of an issue tracking and feature planning process with the help of the Anana service.

Even for a one-person startup, it helps to have more than a spreadsheet (or paper) to track issues, ideas, and bugs. A few years ago, I'd used Lighthouse for my grant-funded NewsCloud Community Starter Project. Last year, I'd been introduced to Asana during a consulting gig.

[...] Eventually, I found my way and discovered the tool works well whether you're working with a variety of people or just solo. In today's episode, I'll walk you through how I began using Asana for Meeting Planner. I use Asana not only to track issues but to organize them and plan for the future. I also use it to track and process bugs.

He walks you through getting started with the service (they have a free tier) and how to set up your first project. He includes examples of task creation, tagging tasks and tracking bugs right inside the service. He then uses it to create a "release plan" for the next version of the Meeting Planner application. He wraps up the post talking about what's next on his side for the Planner application and its funding goals.

The TutsPlus.com site has kicked off a new tutorial series today with part one of a look at using the WordPress REST API and AngularJS to create an API-powered frontend application.

In this series about building a WordPress-powered front end with the WP REST API and AngularJS, we will put the knowledge acquired in the introductory series to use. We will learn how we can leverage this knowledge to decouple the conventional theme-admin model supported by WordPress until now. We will plan and build a single-page application (that I've named Quiescent) with a WordPress back end which will feature posts, users, and categories listing pages. We will configure AngularJS routing and build a custom directive and controllers for the resources mentioned above.

In this first part of the series they walk you through some of the planning steps before the application even gets written (including wireframes). From there they get a bare-bones HTML structure setup for the Angular app to live in and make a matching WordPress plugin. This plugin will return a featured image, author name, associated categories and image resize data related to a post. The code for the plugin is included.

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.

Dave Marshall is in the process of building a "RESTish" web service and has shared some of his planning steps in a new post to his blog.

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.

David Gardner has a suggestion for your development that he thinks can help keep things neat and tidy - using interfaces.

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.

David Goodwin has pointed out a new open source project that the PalePurple group are releasing - the Virtual Planning Board.

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.