News Feed
Sections

 feed this:

Looking for more information on how to do PHP the right way? Check out PHP: The Right Way

SitePoint PHP Blog:
Time Complexity of Algorithms
May 14, 2014 @ 12:25:37

The SitePoint PHP blog has a recent post looking at time complexity in the algorithms you develop in your PHP applications and how that relates to "Big O notation". Big O notation is simply a way of expressing complexity and performance of a method in a less subjective way than "it's faster than.."

If you are a web developer or a programmer in general, you have most likely written algorithms for various tasks. [...] One specification of an algorithm is its correctness. You will probably assume that your algorithm works after testing it out a few times. However, if you can mathematically prove that your algorithm will work as expected for every input value possible, this is a huge bonus. I will not go further in to that subject in this writing. Another specification is its efficiency: how does the computing time relate to the amount of input? Is it a linear relation? Does computing time rise exponentially for the doubling of input? That's what this article will be about.

He starts by talking about the concept of "time complexity" and how it relates to the overall efficiency of the algorithm. He then gets into the definition and examples of Big O notation, including code showing O(n) and O(n2) methods. He talks some about inefficient and efficient algorithms and follows with a refactoring example of moving from one to the other.

Andrew Podner:
NPATH Complexity Demystified
November 14, 2012 @ 10:55:57

In a new post to his site today Andrew Podner takes a look at NPATH and tries to "demystify" some of the concepts around it.

"NPATH, which counts the acyclic execution paths through a function, is an objective measure of software complexity related to the ease with which software can be comprehensively tested."[1] This is the definition from an article written in 1988 by Brian Nejmeh. As informative as this is, my eyes glazed over half way into it. So what the heck is acyclic execution anyway?

He defines the term in a bit easier to understand language and includes an example function to help illustrate how NPATH is measured.

The goal is to limit your NPATH complexity in a given method down to 200 or less. [...] As with other complexity metrics, this one can be checked with PHP Mess Detector (phpmd). The importance of staying under the 200 path threshold is realized when you develop tests and start trying to debug.

Sameer Borate's Blog:
Source Code Signatures in PHP
November 10, 2011 @ 13:11:17

In this new post to his blog Sameer Borate applies an interesting method of discovery of structure in unfamiliar code - generating code signatures.

One method [Ward Cunningham] suggests is that of summarizing on a single line select punctuation characters from each source file. He calls this the file's "signature". This will help the developer gauge the complexity of the code base.

He includes a few examples from files in WordPress - looking for the structure of curly braces and semicolons as delimiters for chunks of functionality. Included are a few lines of code to help you generate a signature from any file and an example of a result. It's an interesting idea, but I'm not sure how practical it is. It could be a helpful reference for how complicated the file is, though.

Freek Lijten's Blog:
Expressing algorithm complexity the big O notation explained
August 04, 2011 @ 11:28:29

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.

Jani Hartikainen's Blog:
You don't need a service layer Fat controllers are okay
May 23, 2011 @ 08:42:15

Jani Hartikainen has a new post to his blog today about why, in your framework-based applications, it's okay to have "fat controllers" instead of a service layer.

Here's a counterpoint to the currently popular view of "fat controllers are bad", and the current fad of everyone and their cousin implementing service layers: You don't need one. Fat controllers are okay too.

He starts by explaining the "why you don't need a service layer" part, mentioning that keeping it in the controller keeps things simple and keeps your code from having to go through extra hoops just to work correctly. He also points out that, just because he recommends "fat controllers" doesn't mean he's advocating code reuse. In fact, just the opposite:

It's fine if you code your things in the controllers, but there comes a point when you should stop that. The moment you realize you're duplicating your code, stop and refactor. This is one of the very basics of software engineering: Avoid duplication by creating functions and classes.

Sebastian Bergmann's Blog:
CRAP in PHPUnit 3.5
January 12, 2010 @ 11:14:03

As Sebastian Bergmann mentions in his latest post, he's changed up how the code coverage functionality is handled in PHPUnit so that he can add something new - CRAP.

PHP_CodeCoverage is a component that provides collection, processing, and rendering functionality for PHP code coverage information. [...] Having all code that deals with code coverage in a separate component allows for easier development and better testing. The first result of these improved development conditions is a small new feature that I recently implemented, the support for the CRAP metric.

Your code's CRAP (Change Risk Analysis and Predictions) scoring combines the idea of cyclomatic complexity and code coverage statistics to try to guess at how difficult any given piece of code would be to maintain. You can see an example here - the lower the number the better.

PHPImpact Blog:
Zend Framework The Cost of Flexibility is Complexity
February 23, 2009 @ 07:51:51

Sometimes power comes at a price - you get benefits from the added features and functionality, but you can lose something else along the way - the simplicity that brought you in originally. Federico Cargnelutti takes a look at a tool that can do just that - the Zend Framework.

Don't assume that just because you're using an object-oriented framework you are writing reusable and maintainable code. You are just structuring your spaghetti code. [...] The main problem with flexibility is that most developers give up trying to understand. I don't blame them, no one likes dealing with complexity

TO illustrate, he gives two code snippets from two example developers - Developer A makes full use of the framework and takes a more compact approach to the problem while Developer B adds in a bit more checking and takes a different path to the same (basic) end result.

Stefan Mischook's Blog:
Podcast Structuring PHP Projects
November 11, 2008 @ 10:25:52

Stefan Mischook has posted a new podcast that gives an overview of things to consider when structuring your application.

In the following podcast I go over the key factor when determining how to structure a PHP project. In a nutshell, it comes down to the size and complexity of the job. For the details, listen to me yap.

You can download the mp3 directly from his site. For more great PHP tutorials, check out his videos section.

Michael Kimsal's Blog:
Magento book review found
June 11, 2008 @ 14:36:44

In response to another blogger's review of the php|architect "Guide to Programming with Magento", Michael Kimsal has posted some clarifications.

Starting off with "However, I'm not really the type of person to give accolades unless something is absolutely stellar. As such, this post will primarily be about the shortcomings of the book" I wasn't particularly surprised that there was more of a focus on negatives rather than positives.

Michael mentions three topics - the "first to market" point the reviewer makes about different versions of Magento between the book being authored and the release, some of the missing information the reviewer would've liked to see and the complexity of the example module that the reviewer complains is too hard to follow.

1 comment voice your opinion now!

Debuggable Blog:
Programming Psychology - Return home early
April 28, 2008 @ 14:36:43

Felix Geisendorfer is taking an interesting approach to defining programming in this new post to the Debuggable blog - he's coming at it more from the level of the perception the programmer has about writing good code.

I believe understanding the patterns in your own thinking will by far make the biggest impact on how good you will get as a programmer. Forget design patterns, forget unit testing, forget all those functions you know. Important is to question why they exist and how they could be improved.

He illustrates through a few examples what he means. He describes one such thought method, the "return home early" process - basically, if something looks too complex for its own good, it probably is. He offers a different way of thinking about it too, a more visual way that can help simplify things even more by laying out the pieces and seeing where they all fit.