Out of the box the Phing -l option can be used to get a first overview of all available targets in a given buildfile but it doesn’t untangle the target dependencies and sometimes a picture is still worth a thousand words. Luckily the Ant community already provides several tools to accomplish the visualization of Ant buildfiles, reaching from solutions that apply a Xslt stylesheet upon a given buildfile.

He uses the ant2dot tool and the Graphiz library to show the XML from a buildfile into a graphic. The image represents the flow of the build.

Via | Raphael Stolt

It doesn’t make such a big job, but it’s nice to see the result on a clean interface. The last release is 0.81, and you can get it from Google Code.

The famous Rasmus Lerdorf’s dixit is shown up in these slides, via some amusing examples: Frameworks are performing poorly. Arno prooves this statement using a Hello World application, and yes, Rasmus is right and framework performances suck for Hello Word applications.

You can read more about it on the Official Google Webmaster Blog.

class Person
{
    private $name;
    private $email;

    public static function withName($name)
    {
        $person       = new Person();
        $person->name = $name;

        return $person;
    }

    public static function withEmail($email)
    {
        $person        = new Person();
        $person->email = $email;

        return $person;
    }

    public static function fullPerson($name, $email)
    {
        $person        = new Person();
        $person->name  = $name;
        $person->email = $email;

        return $person;
    }
}

We have a class called Person which contains 2 private attributes: name and email. It also has 3 static methods: withName, withEmail and fullPerson. These methods will behave like constructors.

So if we want to create a Person object just with the name value, we can do it using the following statement:

$person = Person::withName('Example');

1. 75-85 characters per line: Each line must contains approximately 75-85 characters. If a line exceeds more than 85 characters, consider splitting the line into multiple lines. It will be helpful for code readability. You can see a great post on this topic in Paul Jones’ blog. He talks about why this limitation is not really arbitrary, and he puts some brilliant examples such as this one:

   Bad

   list($foo, $bar, $baz) = array(Zim::getVal('foo'), Dib::getVal('bar'), Gir::getVal('baz', Gir::DOOM));
   

   Good

   $foo = Zim::getVal('foo');
   $bar = Dib::getVal('bar');
   $baz = Gir::getVal('baz', Gir::DOOM);
   

2. Assignment statements: Assignment statements ought be aligned for better readability. Let’s see an example:

   Bad

   
   $example = 'string_value';
   $anotherExample = 42;
   $exampleInst = new ExampleClass();
   

   Good

   
   $example        = 'string_value';
   $anotherExample = 42;
   $exampleInst    = new ExampleClass();
   

3. 4-spaces block indentation: Use an indent of 4 spaces with no tabs. It helps to avoid problems with diffs, patches and SVN history. It helps the readability as well. Usually tabs are 8 spaces length, which means a 5th-block indent starts 40 spaces from the left border (nearly to 50% of a code line).
   

   
   {block1}
       {block2}
           {block3}
               ...
   
   

4. Control & conditional structures: These statements must have one space between the control keyword (if, else, for, while, …) and the opening parenthesis, to distinguish them from function calls (which obviously don’t have a space). It’s nice to always use curly braces because they help to decreases the likelihood of logic errors.

   
   if ($display === 1) {
       while ($obj->next()) {
           echo $obj->toString();
       }
   }
   
   

5. Class and function/methods declarations: Class and function/methods declarations have their opening brace on a new line.

   
   class Foo
   {
       private $_obj;
   
       public function __construct($obj)
       {
           $this->_obj = $obj;
       }
   }
   

6. Comma-space between items of a list: When we list some items, it’s nice to separate them clearly with a comma followed by a space.

   BAD

   
   $example = array(Foo::get('key',2),$value,true);
   

   GOOD

   
   $example = array(Foo::get('key', 2), $value, true);
   

7. Use constants properly: If we have a method which returns some status codes, it’s nice to use literal constants. Having descriptive constants helps to make better intelligible code. For example:

   BAD

   
   class Foo
   {
       public static function getStatus()
       {
           $res = 0;
   
           if (!self::isValid()) {
               $res = 1;
           }
           ...
   
           if ($res === 0 && self::isRepeated()) {
               $res = 2;
           }
   
           return $res;
       }
   }
   

   GOOD

   
   class Foo
   {
       const STATUS_SUCCESS  = 0;
       const STATUS_FAILURE  = 1;
       const STATUS_REPEATED = 2;
   
       public static function getStatus()
       {
           $res = self::STATUS_SUCCESS;
   
           if (!self::isValid()) {
               $res = self::STATUS_FAILURE;
           }
   
           ...
   
           if ($res === self::STATUS_SUCCESS && self::isRepeated()) {
               $res = self::STATUS_REPEATED;
           }
   
           return $res;
       }
   }
   

These tips are just some coding style tips. If we really want to write intelligible code, we would keep in mind many more things like to use software patterns, to make use of well established software practises, …

Ladies and gentlemen, the doors are opened on the Neon project. Neon is no more than a new service by Amarok, which offers nightly builds to the users who want to try the lastest available version. It should be noted that is not a stable version, but it’s intended to be used by everyone who wants to help find bugs or to join development for Amarok.

If you are using Kubuntu Hardy Heron and you are interested on installing it, just add this line to /etc/apt/source.list and install the amarok-nightly package:

deb http://ppa.launchpad.net/project-neon/ubuntu hardy main

More information | Official Amarok site

People wants to install non-free software on free systems because they have not idea. They have not been educated using the free software principles. They don’t understand why the software should be free. They are confused between the free software and the open source movement. The universities doesn’t teach anything about the free software principles, even many teachers don’t know anything about free software. People wants to install non-free software on free systems because they don’t know what the free software is.

The insistence of running Adobe Photoshop on GNU/Linux is a good example of this. I’m not going to talk about the Photoshop/The Gimp challenge, although I manage well myself using The Gimp. Each user should know that Adobe Photoshop has a horrible license which it doesn’t allow the freedom to run, modify and redistribute it. The Gimp (GNU Image Manipulation Program) is available under the terms of the GNU General Public License (GPL), so we have the freedom to run, copy, change, study, distribute, improve the software and release our improvements. That’s how the community gets benefits. The Gimp, like free software, contributes to human knowledge, whilst Adobe Photoshop, like non-free software does not.

I read a message in a mailing list that could not have shocked me more. It said: Google also sponsored some work by Codeweavers to improve [Wine] support for Photoshop (’cause so many people want it) What a bad news for the free software! That’s not what people want, that’s not what GNU/Linux was made for. Why don’t Google support The Gimp instead of a Wine support for Adobe Photoshop?

Sometimes, assigning more people to a project to speed up the development is not the best idea, due to the time required to explain, learn, understand, mets, … about the project. Also we can find non-divisible tasks, so only one person can to do it. If we want to reduce the time, the way to do this is not by adding developers but discarding functionalities not implemented yet. For example, in DSDM we have the time and the resources fixed and the functionalities are variable (they depends on the fixed stuff).

The Mythical Man-Month is a chapter of a book called The Mythical Man-Month: Essays on Software Engineering written by Fred Brooks. This book was written 32 years ago, and it’s been one of the most transcendental books about software project management. It was republished as an anniversary edition in 1995 with the essay No Silver Bullet, where the author maintains the idea that there isn’t single development, in either technology or in management technique, that by itself promises even one order-of-magnitude improvement in productivity, in reliability or in simplicity. The main question is: Is it possible to develop without developers?