If you've been working with open source software for any amount of time, chances are you've seen licenses attached to the projects you've used (or even contributed to). There's quite a few of them out there and it can be confusing as to what's actually covered by them and how it effects you directly. In this recent post to Kyle E. Mitchell's site he explains, line-by-line, one of the most common Open Source licenses: the MIT license.

The MIT License is the most popular open-source software license. Here’s one read of it, line by line.

If you’re involved in open-source software and haven’t taken the time to read the license from top to bottom—it’s only 171 words—you need to do so now. Especially if licenses aren’t your day-to-day. Make a mental note of anything that seems off or unclear, and keep trucking. I’ll repeat every word again, in chunks and in order, with context and commentary. But it’s important to have the whole in mind.

He then walks you through the different sections of the license, explaining what it all means:

• License title (header)
• Copyright notice (header)
• Grant scope (license grant)
• Conditions (license grant)
• Attribution notice, warranty disclaimer and limitation of liability

There's a lot of detail here but in the end you'll definitely understand the license in and out. He ends the post with links to a few other resources that have helped him better understand source licenses.

On NetTuts.com there's a recent post that tries to explain the "whens" and "whys" of design patterns - when using them is a good idea and why you might want to implement them as a part of your application.

There are plenty of articles that explain what design patterns are, and how to implement them; the web doesn’t need yet another one of those articles! Instead, in this article, we will more discuss the when and why, rather than the which and how. I’ll present different situations and use-cases for patterns, and will also provide short definitions to help those of you who are not so familiar with these specific patterns.

They've broken them up by topic instead of by the patterns themselves with sections like:

• Finding the Data We Need
• Reusability
• Discover-ability
• Singularity
• Controlling Different Objects

There's also a few sections that look at other patterns that really only have a handful of uses - like the Decorator, State and Composite patterns.

Freek Lijten has put together a new post to his blog looking at a method for showing how complex an algorithm is without having to get too deep into how it works - the big O notation (with examples written in PHP).

I'd like to share a topic today which was re-introduced to me by a lightningtalk of a colleague of mine. His talk was on the "big O notation". The big O notation is a tool you can use to express the order of complexity of an algorithm. It is useful because it lets you express the order of complexity of an algorithm without taking a lot of time profiling or researching the underlying algorithm. In other words: it gives you a quick way to gain an understanding of what might be wrong (or right) with a specific algorithm.

He introduces the notation as the result of a series of steps needed to solve a problem (ex. 2+2 is less complex than 2+2+2). He illustrates with PHP examples that show adding complexity to a class, adding sets of numbers, looping to find needles in haystacks and finding duplicates in an array of strings. Each of these expand on the theory and show more complexity as the article progresses.

On Kovshenin.com there's a recent post looking at the whole development lifecycle of web-based applications, breaking it out into the three main steps - development, testing and production (splitting out some of these into other, smaller groupings).

Since January this year I’ve been working on a few projects with a team of over 5 people and high-demanding standards. This raised the problem of project managing and a completely different view of the web development cycle. In this article I’d like to outline the major steps of the software development cycle and how they could be applied to the web development business.

Along with the main three categories (dev, test and production) he also gets a bit more fine grained with things like:

• Development: Pre-alpha Stage
• Development: Beta Stage
• Testing: Release Candidate
• Production: General Availability