When a customer commissions Ibuildings for a new application, he usually has plenty of functional demands. [...] And maybe some thoughts have been given to performance metrics, but security? Well… it "needs to be secure". [...] It is said, conveniently enough mostly by software engineers, that building software is perhaps the most complex activity humans have ever undertaken.

He notes that "security is not a checkbox, it's a dropdown" and should be continuously considered continuously through out development. The OWASP ASVS provides a structure that a development group can follow to test the security of their application. It defines 4 types of testing/validation and fourteen other topics to consider.

While ASVS is a wonderful addition, it has it's issues: verification and reporting can take a significant amount of time and validation rules are not specific enough to use the tools and techniques.

Star Fluxx is a science-fiction-themed version of Fluxx, "a card game [that] is different from most other card games, in that the rules and the conditions for winning are altered throughout the game, via cards played by the players." (Wikipedia) When I heard the description of the game on the aforementioned episode of TableTop it reminded me of software development projects. Changing business rules and requirements (rules and the conditions for winning), probably sounds familiar to you, too.

He talks about how the game could be implemented effectively in OOP classes and interfaces - and how this structure would make it easier to make changes. A largely procedural codebase, however, would make the task much more challenging. The analogy breaks down a bit when it gets to the competitive nature of the game and how software development should be collaborative instead, but it's still effective.

When applying for PHP jobs would it be more advantageous to have made your own software without the use of a framework? I'm starting a portfolio of projects and I'm unsure whether to stick to one framework and learn it well, use a variety of them, or also try building software from scratch. Which would look better to a prospective employer? or does it not matter too much? (considering I'm talking junior roles)

Recommendations from the comments including things like:

• "Making your own software is always a better qualification. Because doing your own frameworks means that you understood the general concept of frameworks. But it doesn't hurt to be familiar with the big ones"
• "It doesn't matter. Show that you know how to write good quality code."
• "Frameworks change, the language doesn't. With a good understanding of the language itself, you should be able to pick up any framework fairly quickly."
• "I think you need to know enough of the underlying language to understand what the framework is doing for you. Typically that comes from folks rolling their own framework for awhile"

Read the rest of the comments (or make your own contribution) on the full post.

If you are a first-time entrepreneur and likely someone with little experience with software development, the chances of you successfully directing the development of a product on your own, are slim. [...] In software development, too often vision holders hand off a "vision document", i.e. "The Specifications", to a developer and expect him to translate it to the finished product they have in their mind. Most software developers or graphic designers are simply not fit for that role - they do not have the experience, skills or vested interest in transforming your vision to an actual product.

His examples revolve around the idea of outsourcing the development to another group, but a lot of the concepts still apply to in-house development too. He talks some about the idea of "you get what you pay for" when it comes to quality and how much you're willing to pay. He then gets into one of the hardest questions when dealing with development - how to find good developers. He mentions several things that need to be a part of that relationship like trust and good communication.

Developers like to think that companies hire developers to write code. But companies do not hire developers to write code; they hire developers to solve problems. They hire developers with the expectation that the developer knows about, or can learn about, the problems of the company, and find a creative solution to those problems at minimal cost.

It is therefore up to the developer to choose what tools they will use to achieve the outcome. The customer doesn't much care what tools the developer uses; they only care that the outcome they desired is achieved.

He goes on to talk about preferences in the tools "used by craftsmen" and why they're less important than the result of the work they create. He notes that languages matter, but only in a certain context - as a piece of a puzzle, a part of a whole to reach an objective of functioning software.

Last week I wrote an email to a client who hasn't yet implemented source control, but who is thinking about it. It turned into rather a long email as I attempted to convey WAY too much information in one long email. After some twitter banter, I repackaged my thoughts into a whitepaper on Source Control entitled You're not using source control? Read This! (PDF, no registration needed).

The whitepaper looks at three different tools - Subversion, git and Mercurial (Hg) - and includes a "sales pitch" you can give to the people involved in your project about how it can help them. There's also a few helpful links included at the end for more information about each piece of software.

Unusually for me, I did not speak on a Zend Framework topic, and had only one regular slot (I also co-presented a Design Patterns tutorial with my team). That slot, however, became one of my favorite talks I've delivered: "Designing Beautiful Software". I've given this talk a couple times before, but I completely rewrote it for this conference in order to better convey my core message: beautiful software is maintainable and extensible; writing software is a craft.

You can find the slides for his presentation on his site as well.

These days, good PHP object-oriented libraries are all around and easily available. To me, it is actually thrilling to be part of this flourishing community, while working with Symfony2 and blogging about the Framework, the Components and their neighbors (like Silex). [...] Still, to me, contributing felt like too big a step to take right now. Until a few weeks ago, when I was looking for something I needed (a PHP client for the Microsoft Translator API) and could not find a decent solution. I decided to make it myself, and share it online.

He shares his "checklist" of steps he followed to get the library up and working (less about the library and more about the process):

• Write the code
• Initialize a Git repository
• Add a composer.json file
• Add unit tests
• Make it open source and developer friendly
• Push your code to GitHub
• Register your project at packagist.org
• Register the Packagist Service Hook
• Versioning
• Continuous integration using Travis CI

He also suggests that, at least at the outset, you skip some of your tests that might rely on external data sources/resources (so the build can start as green on Travis) then coming back and refactoring to mock things out correctly. It might look like an intimidating list for a beginner, but it's a great process to follow to have a robust, effective development/deployment process.

In the past few years, there has been a great increase in the number of websites with user-generated content (UGC). One of the most common Web applications with UGC is a Web forum -- a place where people can share their impressions and opinions on different topics. As forum software is becoming more and more popular, I will compare the three best forum software products written in PHP: vBulletin, phpBB and Kunena.

They go through each of them and talk about what features they offer and some of the pros and cons of each. At the end of the post there's a table laying out each of these in a bit more easy to reference form.

I found his questions to be well-posed and thoughtful, so I figured I'd post my responses as a blog post. I'll be sending this post to Jordan, so if anyone has additional comments or advice for the kid, please feel free to leave some wisdom in the comments!

Some of the questions include:

• Describe the duties and responsibilities of someone working in software engineering.
• Do you have assignments that seem to drag on forever, or are they usually pretty quick?
• Are there any specific tools or equipment required for your job?
• What are the advantages/disadvantages?
• So do most people work for themselves, private industry, or the government?

You can read Evan's answers to these and more in the full post.