Agile methods are often described as “common sense”. For this reason Ken Schwaber refuses being titled the Co-Creator of Scrum. Several software development practitioners such as Ivar Jacobson, Grady Booch, and James Rumbaugh all contributed to the set of principles that today form the Scrum framework.

However, having Scrum, XP, or any other method classified as common sense leaves a lot of room for interpretation by the individuals applying them. Thus, iteration planning efforts sometimes end up being superficial, not entirely committed to the system actors’ real goals. As a practical consequence, user stories are found reduced to single sentences hanging on the white-board.

It is clear that User Stories are not Use Cases or Requirement Statements, as detailed by Mike Cohn, and highlighted as follows. Firstly, use cases are generally written as the result of a long analysis, whereas user stories are written as notes that will be used to initiate further analysis conversations. Secondly, requirement statements make costs visible only when all of them have been formally written in a lengthy document, whereas with user stories a complexity estimate is associated with each story immediately. Costs are then easily calculated by taking into account the velocity of the team.

Nonetheless, developers should not underestimate the complexity inherent in each story, and complementary theory can be found on this topic. Ron Jeffries breaks down the stories into three aspects: Card, Conversation, and Confirmation.

Firstly, the card does not detail the story in depth, but successfully identifies it. Typically, team members and product owners adhere to the following template, popularized by Mike Cohn: “As an <actor>, I want to <action>, so that <achievement>”. Although advantages derived from using this template have been listed, other agile evangelists have proposed enhancements. Elizabeth Keogh, for instance, came up with a new user story format that better emphasizes business value. One way or the other, templating has been the common approach, and teams should adopt one that will fit in smoothly within their environment.

Secondly, conversation is the activity that communicates the requirement from customers to developers during the product and sprint planning. At this stage, details such as dependencies and barriers are mapped out. As depicted by Jeffries, the conversation is largely verbal, but is often supplemented with documents. It is important to bear in mind that good communication is a key success factor in any software development project, and none of the artifacts produced throughout the process may substitute that.

Finally, stories are verified through confirmation or, more specifically, acceptance testing. All criteria taking into consideration ought to be defined during planning phases as well.

Although the theory presented above brings some structure to the loose perception of user stories, the writing itself remains vague. So William Wake advocates that agile practitioners should INVEST in good stories and SMART tasks. Despite not being a particular fan of forced acronyms, I have to admit that some guideline will be welcome here.

Briefly, characteristics that form a good story description are the following:

• Independent
• Negotiable
• Valuable
• Estimable
• Small
• Testable

.
Hence, a story should be independent from others, negotiable between customers and programmers, valuable to customers, estimable in terms of complexity, small for the sake of understandability, and testable on account of readiness confirmation. Further studies suggest that “Small” should be replaced with “Sized appropriately”, as the bottom of the product backlog may contain items that are not fully understandable by the team yet, also known as Epics.

Tasks, in their turn, should be:

• Specific
• Measurable
• Achievable
• Relevant
• Time-boxed

.
So a task needs to be specific by addressing one particular point, measurable in order to be tested against the definition of done, achievable by the task owner, relevant to the story at hand, and time-boxed. This latter characteristic should not be perceived as a formal estimation in hours or days though, as it does not work. The raw material in Software Engineering is the developer’s own intellect, and nobody would be able to estimate its maturation time. The same applies to activities such as painting or novel writing. Civil Engineering, on the other hand, benefits from using raw materials that allow for accurate calculations, such as concrete and iron.

As a final note, during the planning, instead of defining longer iterations and allowing for bigger stories, you might be interested in giving the following set of constraints a try. SWAT has successfully built some of its software by adhering to them. Manageability goes through the roof!

• 5-day sprints
• 5-point stories, or less
• 2-developer teams, up to 4

.
In conclusion, a better organized agile planning is more likely to drive the team towards the goals identified by project stakeholders. Theories and guidelines have been proposed, and I suggest bringing these concepts to the table when starting a new agile project.

As outlined in his talk, the very first question when developing for mobile is: what type of application do I want my product to have? Currently, there are three different types: Native, Web and SMS. Choosing one is based on the purpose of your project as well as the target audience.

• Native: used when the aesthetics of the app is very important. Native is recommended when you want to access a core feature of the device, like a camera or GPS. And, because of their app stores, Native apps have the added advantages discoverability and visibility.  The disadvantage with this type of application is fragmentation, i.e. you must write a different application for each device.
• Web: used when the focus is on distribution. Web apps are available on any device enabled with Internet access and there is no need to download. Considering testing and supporting, web applications have an advantage since they do not need to go through all the bureaucracy of the app store. Updates are also up and running instantly. The main disadvantage of web apps is sand-boxing.
• SMS: rare and only used in markets where internet access on the phone is not available or prohibitively expensive. SMS apps don’t offer discoverability.

Considering the above, Web applications are usually the best choice. They are cheaper to produce, more standardized and easier to distribute. According to Stark himself, “If you CAN build your app with HTML, CSS and JavaScript, then you probably should.”

In the second part of the talk, two interesting tools were demonstrated:

jQTouch

jQTouch is a jQuery plugin for mobile webkit browsers developed by David Kaneda. It Allows native animations, navigation and automatic customization of theme. Even if you will not actually using it in your application, it is a great tool for prototyping it.

To set jQTouch, you have to add in your page:

That means:

(1) adding hardcore structural design rules. This is required and you shouldn’t edit it
(2) add your theme style file. There are some options in jQTouch website or you can write your own
(3) initialize jQTouch after javascripts files are added. You can pass an object as a parameter with some values as icon and preloadImages

You can learn more from the jQTouch website or its documentation.

You can also see a quick overview in the video bellow:

PhoneGap

PhoneGap is a framework for building cross-platform mobile apps. Using it, you can still take advantage of core features in iPhone, Android, Palm Symbian and Blackberry. It’s been recognized as a game-changer and its source code has been downloaded more than 200,000 times! Web applications can now compete with native applications when functionality is the main requirement.

For more information, you can visit the PhoneGap website.

To learn how to install it, check the video bellow:

For those not familiar with Scrum, let me summarise the key principles quickly:

1. A project team is setup usually consisting of between 5 and 9 resources.
2. The resources within the team have the set of skills needed to develop products.
3. There are defined roles within this setup, namely

• The Product Owner: Manages a list of product features that require development. These features are prioritized by the Product Owner.
• The Scrum Master: Ensures that the processes are followed and helps the team deliver the product features by removing any impediments that prevent them from delivering.
• The Team: Self organises around the product features and collectively work together to deliver these product features.

I’m simplifying the roles here of course – there are further responsibilities that are played by each role, but this is the essence.

4. The team produces working demonstrations of the product features at regular intervals (typically every two weeks).
5. These working demonstrations are visible to the business, allowing the business to get a view on where the product is going and whether it needs refinement or a complete change in direction.
6. The refinements or improvements are then fed back into the team, prioritised by the Product owner and driven through to demonstration once again.

The framework is agile in nature. Problems are quick to identify, and quick to change. Traditional project management methodologies would allow a project to proceed down a long and drawn-out development path and if the up-front analysis had not been 100% accurate, or if external factors had required a change to the project during development, this would be very difficult to accommodate. The Scrum process by contrast makes sense – it is a simple, logical way of delivering projects and caters for changing requirements.

That said, the question of how to setup the Scrum team and environment remains. As a new team, we are facing these questions and trying to figure out the best path to creating the esteemed “High Performance Team“. There are two schools of thought here. Let me deal with the first.
As competent and experienced team members, there is a sense of “doing things right, from the start”. This includes everything from ordering the right development hardware, deciding on what software is appropriate, defining the practices and principles the team is going to follow, which languages are best suited for the projects that need to be developed, and what the collaboration environments need to look like. All good stuff, and completely necessary. The planning also includes discussion and decisions around how to test the code that is developed, how it is documented, how much of this is automated versus manual, which tools are best suited for testing, how new issues get logged and fed back into the team, and how much test coverage is considered acceptable. Again, all good stuff, and all appropriate to the work that is being done within the team. It is also a good idea to get the overall context of the project defined up front so that broad architecture decisions can be made. Where the team needs to be careful however, and we are all sometimes guilty of this, is when it comes to over-engineering a solution up-front. Chances are that this picture is changing, or will eventually change. Nothing wrong with good architecture up-front, but trying to understand too much detail too soon is probably wasted effort.

Lets take a look at the second school of though for a moment. The principles of Scrum and Agile development methodologies and practices suggest that the value lies in delivering small, incremental features, regularly. Mistakes and changes to project scope are inevitable and it is the ability of the team to correct these mistakes, and accept the changes in scope that makes them “High Performance Teams”. Through continuous feedback and team “retrospectives”, the gaps get filled, and the holes get plugged. The team continues to improve as a result and the delivery continues to speed up – well, from the initial stages anyway. Its a situation in which the team adapts the principles of Agile software development to suit their unique environment, the individual strengths and weaknesses and their team characters.

The point that I am trying to make here, is that there are two ways to try and achieve the “High Performance Team”. There is the “Lets build the 6-foot armour-plated robot with Augmented Reality vision”, or, the “Lets build the stick man and determine what he needs next” approach. There is a fine line between setting up a team that does everything right from the start, and a team that is setup to learn how to do what is right for them.

I was recently made aware of an agile development team based in the UK that has been together for the past 60 months. They deliver code weekly, have a number of visible metrics for how many bugs are in their system and how quickly they are resolved, what the velocity (capacity for delivery) of the team is, converted into monetary value, and a number of other “reporting” metrics. Incredibly useful information, and a sign that they are a “High Performance Team”, but I wonder how much of that was setup from the start, and how much of it “evolved” as the team progressed through their 60 months of development together?

To take the analogy used above, whilst it is important to have a team vision in place and to follow best practices where ever possible, I firmly believe that it is best to create the stick-man from day one, and get him running in an agreed direction, rather than spend too much time thinking and planning the 6-foot robot that potentially is only capable of taking a few steps at a time, and hopefully, in the right direction.

That being said, our team is in a good place. We are positioned nicely and are moving forward as a unit. Hopefully the discussions that our team have had, and the conclusions drawn here, can help you position and setup your own team.

Nowadays it’s almost impossible to write an article about mobile phones without mentioning the very successful iPhone. Apple had practically turned the mobile  industry upside down with its touch screen device. Some people will argue to the death about how the iPhone, or the “Jesus Phone” as some call it, is the best thing since sliced bread – and nobody can argue against how successful this device has become. But I am predicting a total onslaught of Android devices within 2 years. The Android army of phones will be everywhere you look and you will not be able to visit any cellphone store without running into at least 50 different phones running this OS. OK – maybe that is going a bit far but I think you get the message and already we are seeing signs of it. At the time of writing this article there are 16 official Android devices. How will this army of Android devices be created you ask ? Enter the Open Handset Alliance.

The Open Handset Alliance was formed in 2007 and currently has 47 members. It is a consortium of technology and mobile companies all dedicated to bringing us better mobile experiences, with Android being their first project . There are some big names amongst the 47 members, including Google, Intel, Nvidia, HTC, Asus, SonyEriccson, LG, Ebay. With so many big names dedicated to Android development, it is bound to be amongst the top mobile device OS’s. You can read more about this argument here, let me get to the Android architecture.

Android is a Linux based software stack. On top of the Linux kernel layer lies a layer for the system libraries such as SQLite, SSL, OpenGL, etc. This layer also houses the Android runtime, which runs the Dalvik Virtual Machine. On top of this there’s the Application Framework, housing the managers like the Activity Manager, Window Manager, etc. Then finally there is the application layer, which is the layer we are most interested in.

Android applications can consist of different sections, namely Activities, Services, Broadcast Recievers and Content Providers. Activities form the User Interface(UI) part of the application, Services run in the background similar to RSS feed readers checking for updates. Broadcast Receivers just listen for particular system broadcasts, for example , when the battery is low. Content Providers just provide content to any asking application , for example your application asking the contact book to provide the users contacts for use within your application. We will mostly be concerned with Activities.

Activities were designed to be totally integrated with one another. What I mean is that Activities can call one another and pass data to one another, basically  like an event driven system, but on a system wide level. An application is thus a group of Activities passing Intents to one another. It is then possible to include , lets say, a Google Maps Activity into your application by passing a Google Maps Intent to it and waiting for a result from it. It would seem to the end user that you created a Google Maps section to your app. I think this is pretty powerful.

To get started with creating these applications you need the free Android SDK, Apple iPhone developers need to register first($99!). Then you going to need an IDE, there is an Eclipse plugin, the Android Development Tools(ADT) plugin that has everything including the latest stable SDK. You don’t immediately need a phone to test on as ADT comes with an Android emulator that you can debug and test with but you will eventually need a phone to properly test with. ADT is pretty awesome as it comes with many tools to tell you exactly whats happening on the phone, which threads are running,it has code completion, wizards to quickly create sub classes and much more. It took me less than 30 minutes to get a “Hello World” application running on the Android emulator from the time I installed the ADT!

Since ActionScript 3 is a lot like Java I could easily jump in even though there were a few syntax differences – but after about 2 days and the help of ADT I had a basic application drawing a ball bouncing round the screen. But that was only the beginning and have rewritten sections of the game many times. Now after two weeks of lots of learning I have created the game and have it running on my phone. It is still a prototype and even though it needs weeks more spit and polish, after demonstrating the game I have gotten the thumbs up to turn it into a real game which we will be registering in the Android market.  There is still a lot to learn from this wonderful framework but the Android groups have been great help, as well as all the Android forums and of course, the Reference guide which ships with the SDK. It has been a challenge to get to grips with this entirely new development area but it was far easier than imagined it would be. I spent about 10 times longer getting to know Flash, and that was with people available to help me.

What about my experience using the phone? I can honestly say I am now more connected than ever before. My email, both gmail and exchange, is pushed to the phone. My Twitter application runs in the background constantly fetching  tweets, while my Facebook application gets all my buddies’ status updates to me as often as I want to see them. News and weather is updated all the time. My calendar and contacs are synchronised between my phone and my mobile. I never get lost anymore, maps are always available and my Gtalk status is always “available” and running in the background, unlike on some other phones Oh, and it makes phone calls as well.

I will follow up with another article of my findings, good and bad, this time focusing on the actual Android game development.

The 5.3 release of PHP is the most important release ever, and adds a lot of new features – leading to a delay in its release date. We will look at the most important feature enhancements from version 5.2 to version 5.3.

Let’s first look at the enhancements from PHP 5.1.X to PHP 5.2.0:

• Memory optimizations
• Filter extension
• JSON extension
• ZIP extension
• File upload progress hooks
• DateTime and DateTimeZone objects
• A couple of others small ones

While these changes were interesting, (especially the first one, which lead PHP 5 to run quicker than PHP 4), they were not very visible and “hype” changes.
Now, let’s take a look at what PHP 5.3 will offer, and let’s try to judge the extent of the upgrade.

PCRE, Reflection and SPL functions are always enabled
It sounds obvious, but some libraries rely on Reflection/SPL to be able to work. One example is Doctrine ORM, which enables you to work at the OO level when using databases as storage medium.
PCRE is a faster library than POSIX RegEx, which may help you to write faster code when dealing with regular expressions.
Also, I am helping with the re-implementation of the spl_object_hash function, to solve some collisions and also to improve performance.

NOWDOC and HEREDOC syntax
While HEREDOC syntax has been available for quite a while, it has some interesting optimizations that will allow it to behave as fast as a normal string declaration. HEREDOC uses the same syntax as a normal string declaration with double-quotes.

$author = 'Guilherme Blanco';

$msg = <<< EOT
This is \x41 message from $author!
EOT;

$msg2 = "This is A message from $author!";

// $msg1 === $msg2
echo $msg1; // Prints: This is A message from Guilherme Blanco!

NOWDOC is a new inclusion to the language, which behaves exactly like a normal string declaration with single-quotes. This means it doesn’t convert the variables and symbol codes to their correspondent values.

$author = 'Guilherme Blanco';

$msg = <<< 'EOT'
This is \x41 message from $author!
EOT;

$msg2 = "This is A message from $author!";

// $msg1 !== $msg2
echo $msg1; // Prints: This is \x41 message from $author!

?: operator
Quick alias for those that have to do this all the time:

// PHP < 5.3.0
$data = isset($var) ? $var : 'default';

// PHP >= 5.3.0
$data = isset($var) ?: 'default';

__DIR__ constant and error modes E_USER_DEPRECATED, E_DEPRECATED
These two error modes are quite simple. They have been introduced to inform the user of stuff being scheduled for removal in future PHP versions.

The __DIR__ constant is a nifty feature for those who are not happy with include paths.
For many years, I personally had to work around directory mismatches by checking the directory of the current file.

Now we’ll be able to use this new constant (which is much faster):

// PHP < 5.3.0
require_once dirname(__FILE__) . DIRECTORY_SEPARATOR . 'File.php';

// PHP >= 5.3.0
require_once __DIR__ . DIRECTORY_SEPARATOR . 'File.php';

__callStatic(), __invoke() and dynamic access to static members
One awesome feature that PHP 5 introduced was the magic methods: __set, __get, __call were quite useful for developers who wanted to control access to their objects. But one missing feature was the ability to control static method calls. To fix that, PHP 5.3 will introduce the __callStatic magic method, which will allow it to handle static method calls, like Foo::bar();

With a new implementation of lambdas and closures that I’ll detail later, more dynamic behaviour will be required from the OO side. To make us – PHP developers – more comfortable, PHP 5.3 will introduce the possibility to call an instance of a class as a function. This support was included under the magic method __invoke(). Sounds weird, but I’ll show you a quick example:

class Foo
{
public function __construct()
{
echo "Calling from constructor...\n";
}

public function __invoke()
{
echo "Calling from invoke...\n";
}
}

$foo = new Foo(); // Prints: Calling from constructor...
$foo(); // Prints: Calling from invoke...

For those who do not know hebrew, the PAAMAYIM NEKUDOTAYIM is not more difficult to be found. Now it’ll be possible to do some weird calls such as $var::staticMethod(); and it’ll work!

Garbage Collector
After a lot of discussion and a Google Summer of Code project, David Wang devised a very good garbage collection mechanism that deals perfectly with cyclical references for PHP.
This means that PHP will use MUCH LESS resources on the server, consuming much less memory, not throwing memory exhausted exceptions any more when importing things.

This extension is built-in, and as far as I have been able to determine, it cannot be disabled. The only way to prevent the Garbage Collector from collecting lost cyclical references, is by calling gc_disable. The other gc_* functions will always be available. This means that you will be able to enable/disable GC through functions gc_enable(), gc_disable(). When it becomes necessary to remove non-referenced objects, simply call gc_collect_cycles(), and PHP will perform its magic for your server.

Late Static Binding
Currently, static references to the current class, like self or __CLASS__ are resolved using the class in which the function belongs, as in where it was defined:

// PHP < 5.3
class A
{
public static function who()
{
echo __CLASS__;
}

public static function test()
{
self::who();
}
}

class B extends A
{
public static function who()
{
echo __CLASS__;
}
}

B::test(); // A

Static references to the current class like self:: or __CLASS__ are resolved using the class in which the function belongs, as in where it was defined, so when we call the test() method on class B it will call the who() method of class A.

LSB tries to solve that problem by introducing a keyword that references the class that was initially called at runtime. Basically, a keyword that would allow you to reference B from test() in the previous example.

It was decided not to introduce a new keyword but rather use “static”, which was already reserved.

// PHP >= 5.3
class A
{
public static function who()
{
echo __CLASS__;
}

public static function test()
{
static::who();
}
}

class B extends A
{
public static function who()
{
echo __CLASS__;
}
}

B::test(); // B

Some people describe static:: as the $this-> resolution for static calls, this is not true as $this-> follows the rules of inheritance while static:: doesn’t.

Namespaces
After months of discussions and a lot of issues that had to be fixed, the namespaces implementation has finally been incorporated, and is already available under alpha 3.
The namespace separator doesn’t please everyone especially those that do not use english keyboard layouts. These people will suffer due to the lack of “\” char on keyboard.

Here is an example usage of this new feature of PHP 5.3:

// File1.php
namespace Foo;

class Bar
{
public function test()
{
try {
do_some_stuf();
} catch (Exception $e) { // Refers to Foo\Exception
// Special handling of Foo Exception
} catch (\Exception $e) { // Refers to PHP Exception
// Special handling of Exception
}
}
}

// File2.php
$b = new Foo\Bar();
$b->test();

// OR...

use Foo\Bar as Baz;

$b = new Baz();
$b->test();

Lambdas Functions/Closures
This can be considered to be an important new feature of PHP, as important as namespace support.

From now on, it’ll be possible to do this:

$func = function ($str) { echo $str; }

$func('Hello World!'); // Prints: Hello World!

Certain situations arose where variables from an outer scope should be allowed internally too. That was a limitation of PHP (variable scope), but it was fixed by the usage of new syntax when defining the lambda function:

$first = "Guilherme";
$second = "Blanco";

$func = function () use (&$first, $second)
{
$first = "Hello";
$second = "World";

echo $first . ' ' . $second; // Prints: Hello World
};

$func();

echo $first . ' ' . $second; // Prints: Hello Blanco

New SPL classes
A lot of work has been done, especially by Etienne on SPL (the Standard PHP Libraries). There is a bunch of new data structures that will be available to users starting on PHP 5.3.
Until now, no updated documentation has been made available, but looking at the source it is easy to figure out how to use these new structure.
Here are the new data structures which will become available:

• SplObjectStorage (added ArrayAccess support + new features)
• SplDoublyLinkedList
• SplStack
• SplQueue
• FilesystemIterator
• GlobIterator
• SplHeap
• SplMinHeap
• SplMaxHeap
• SplPriorityQueue
• SplFixedArray
• RecursiveTreeIterator
• MultipleIterator

mysqlnd
This is a replacement library (and it’s not an extension) for libmysql, offering a lot of advantages over it the latter. While libmysql was developed primarily for C and C++, mysqlnd is optimized for PHP, taking advantage of the Zend Engine.

These advantages are:

• Tight integration with Zend Engine
• Faster execution
• Lower memory
• Easier compilation of PHP,since it’s native now (libmysql was bundled with MySQL Server)
• Usage of PHP stream API
• Statistical Data Collection
• Client-side (PHP userland) Query Cache
• License compatibility
• Easy to introduce future improvements (prepared statement cache, built-in profiling, automatic load balancing, etc)

Fileinfo
This great PECL extension is now enabled by default in PHP to replace mime_magic.
It is possible to pick the right content-type of files, giving you more secure code and preventing some security issues the previous library allowed, such as uploading a PHP script as a GIF file for example.

Here is a piece of code that shows how to use this extension:

$fileinfo = new finfo(FILEINFO_MIME);
echo $fileinfo->file('/path/to/file/to/be/checked.jpg'); // Prints: image/jpg
$fileinfo->close();

Phar
How do you share your library? How do you share all the source code?
While other languages provide a nifty packaging system, PHP until now had not features to support anything like this.
With PHP 5.3, phar has been included for all of us.

You may not be aware of this – but I work on my spare time on the Doctrine ORM project. Let’s use Doctrine as an example.

First we want to pack our entire project into a single file called “doctrine.phar”.

$phar = new Phar('doctrine.phar', 0, 'doctrine.phar');
$phar->buildFromDirectory('/path/to/doctrine/lib');
$phar->setStub($phar->createDefaultStub('Doctrine.php', 'Doctrine.php'));

It’ll generate a “doctrine.phar” file that we can distribute to people.

Once you have the phar file, you would have to do the following to load the library:

include '/path/to/doctrine.phar';

Improved Windows support
As a member of the PHP Windows team, I cannot finish this article without mentioning that some PHP developers are working extremely hard to be able to provide a lot of *NIX only features for Windows server too.
Two days ago Pierre finished the link() support, which creates symbolic links (shortcuts for Windows users) through PHP. Currently there is a list of functions for which support on Windows is planned – this list can be accessed via URL: http://wiki.php.net/internals/windows/todo

Also, I worked on a PHP webpage at http://windows.php.net which provides customized Windows builds of PHP. It’s possible to pick a snapshot or a VC9 compiled version.

I hope you all enjoy it! =)

Let me provide some background. The majority of our team members, both in South Africa and Brazil, had been Microsoft .Net developers at some point in their careers, and some had never been anything else. We used to hire people based – in part – on their expertise with Microsoft development tools.

As a business unit, SWAT comes into contact with a large number of organisations from around the globe that are members of the MIH group. In our interaction with these companies we were experiencing a great deal of resistance to implementing Microsoft software.

The reasons for this resistance were varied but often based on cost – both the cost of the software and the cost of the people who are skilled in the use of Microsoft tools. Cost was not the only consideration – the general perception out there is that the Web is built on open source software, and that open source is where the best developers want to place their efforts and build their reputations.

It was very clear that we had to cross the great divide if we wanted to stay relevant in the markets where the group operates.

Although we had never been a pure Microsoft shop – we used Flash technologies, Javascript , CSS and their kin, as well as various tools for mobile development – our core development tools were Microsoft Visual Studio, using C# with .Net and ASP.Net, and the challenge was to change our primary development platform.

Our greatest concern was what the reaction of the team members would be – I mentioned earlier that the majority of people in the team at that time were skilled in Microsoft technology, and we were worried that the re-skilling that would be required would present us with a very steep (and costly) learning curve. A further concern was that the changeover may cause people to leave the team, rather than lose the skills they have already acquired in Microsoft technologies.

Once the decision had been made to shift our focus to open source development, we had to choose a platform. The obvious choice was PHP 5.0. “Obvious” because of the wide popularity of the language within the group, the wide support for PHP and the vibrant PHP community. An additional consideration was that PHP is fairly similar to C#, in terms of syntax and in terms of being a “traditional” object oriented language. Although we considered options such as Ruby, we concluded that PHP would represents the best option for migrating to open source.

It has been more or less a year since we finally phased out Microsoft tools, and here’s the summary of our experience:

• Great programmers do not care about the language. We lost no-one because they wanted to work only on Microsoft platforms.
• The web IS built with open source tools – and using open source tools gave us a wider audience.
• Costs for software development tools have plummeted to virtually zero.
• The Microsoft Visual Studio IDE is one of the best (if not the best) development environments available.
• If you are going to use open source, you must be willing to change and adapt all the time. Frameworks, tools and methodologies are continuously changing in the open source world – forget about well-planned migration routes for technology. Be pragmatic, and use what works. We still use Microsoft tools when our clients require it.
• Because it is open source, it is possible to look into the code to find why things do not work as expected. Often it is very hard to find the solution, and there is hardly ever a helpdesk which you can call. But you can look if you want – the option is there.
• Microsoft is not bad. In our experience it is simply a matter of choosing the most appropriate tool for the job, and the Microsoft tools are more suited for enterprise development. Although of course the platform CAN be used for web development.

In summary – the decision to go open source was the best decision for our team, and I would encourage every team that does web development to do the same thing.

Let’s start with a little bit of background. Sometimes the way businesses are modeled are constrained by the available technology, which may block innovation, change and even growth in the business. Instead of establishing barriers, technologists should keep pushing for the evolution of technology, and keep fighting people who are against this evolution.

You may be fortunate enough to live in a better world, where software is built according to real business goals, bringing real value to the company. Great! However, this is not quite enough yet. Business models keep changing quickly, which means that the software in place ought to be flexible enough to support these changes, and also expansible enough to support that always desirable growth.

The real problem here is the following: How can we simultaneously achieve flexibility, expansibility, and maintainability in software architecture? This is a very tough question, but the answer is rather simple: “Achieve this by using high modularity levels”. Unfortunately, this cannot be achieved by some sort of magic, but only by dint of a focused architectural effort, as described below.

I like thinking of a module as just a block of code – this block of code can vary from being a method to being a class, a component, and a (web) service. Now, the modularity level evaluates the usage of modules in a given software architecture, mainly when it comes to encapsulation, coupling, and cohesion. Several authors have written about modularity, but my personal choice is Bertrand Meyer. His study on Object-Oriented Software Construction presents five criteria as a guide to evaluating modularity.

1. Modular Decomposability – A software construction method satisfies Modular Decomposability if it helps in the task of decomposing a software problem into a small number of less complex sub-problems, connected by a simple structure, and independent enough to allow further work to proceed separately on each item.
2. Modular Composability – A software construction method satisfies Modular Composability if it favors the production of software elements which may then be freely combined with each other to produce new systems, possibly in an environment quite different from the one in which they were initially developed.
3. Modular Understandability – A software construction method satisfies Modular Understandability if it helps produce software which a human reader can understand each module without having to know the others, or, at worst, by having to examine only a few of the others.
4. Modular Continuity – A software construction method satisfies Modular Continuity if, in the software architectures that it yields, a small change in the problem specification will trigger a change of just one module, or a small number of modules.
5. Modular Protection – A software construction method satisfies Modular Protection if it yields architectures in which the effect of an abnormal condition occurring at run time in a module will remain confined to that module, or at worst will only propagate to a few neighboring modules.

Mr. Meyer also presents the following six principles.

1. Linguistic Modular Unit – Modules must correspond to syntactic units in the language used.
2. Few Interfaces – Every module should communicate with as few other modules as possible.
3. Small Interfaces – If two modules communicate at all, then they should exchange as little information as possible.
4. Explicit Interfaces – When two modules communicate, this fact must be obvious.
5. Information Hiding – All information about a module should be private to that module unless it is specifically declared public.
6. Open & Closed – A module should be open for small changes (with no impact on its interface), and closed in terms of readiness.

Both lists are quite self-explanatory, aren’t they?

From my point of view, software modularity is an overused expression, and people are usually not familiar with any criteria or principles for evaluating the level of modularity, such as the ones listed above. This post aims to provide a means whereby the  often misunderstood concept of modularity is made explicit, while providing a foundation for designing truly loosely-coupled modules. I hope you find it useful.

Obviously, the schema presented here is just part of a complete software architecture – for the purposes of this discussion we assume that all orders issued are stored in a relational database instance (MySQL more specifically). The natural way of thinking leads the architect to model a dependency from Order to MySQL, mainly because the former class is the one responsible for deciding when database transactions begin. However, the resulting dependency leads to at least three undesirable consequences, as follows:

• Business objects and rules start depending on purely technical matters such as database manipulation. We all know that what is cutting-edge technology at the moment, is likely to become obsolete in a few month’s time. Business concepts, on the other hand, tend towards stability – an order will always be an order, potentially keeping the same attributes in the long-run. It’s important to notice that the undesirable direction of the dependency may force the developers to change business objects whenever the database technology they are using changes.
• The architecture assumes that storage will always be handled by a specific relational database. This is a risky assumption, since the development team may decide to swap out the database provider. Moreover, alternative storage mechanisms like the file system itself may come up as a viable option in the future.
• Unit testing becomes painful. This sort of dependency makes it difficult to use the mock objects technique, which is quite common within unit testing methods.

We can address these issues by placing an interface between the classes, and therefore inverting the related dependency. As demonstrated below, we have just succeeded in decoupling storage manipulation from business objects.

The dependency inversion technique has addressed all the problems we identified. People usually think of an interface as just a simple set of common functions, but it’s not. Instead, a strategically applied interface contributes desirable outcomes such as mobility, flexibility, reusability, and maintainability.

OK, but wait a minute, the business object Order still needs to send messages to the data access layer, doesn’t it? Yes, it does, but interfaces do not exist at runtime, only objects do. Therefore, IStorage is replaced by an object defined by a class that realizes this interface, the MySQL class in our example. It’s now clear that we could also have realizations to other database providers and storage mechanisms (Oracle, MSSQL, PostgreSQL, and File System).

Visualizing the dependency inversion is even easier when we deal with components, instead of classes. The first component diagram below does not take advantage of the technique we just learned.

Unlikely the previous diagram, the following schema turns over the dependency between the components, making the business component independent, and enabling new data providers.

The black-box notation makes things even clearer:

Again, the dependency inversion:

Techniques such as the one presented by this post prevent the Active Record pattern from being a complete failure. Now I bet you realize how powerful dependency inversion is, right? So back to your dashboard and take your interfaces to the next level!

Successful development processes such as UP (Unified Process) are usually defined as architecture-centric, which basically means that development iterations are guided by the evolution of the architecture,  and by architectural artifacts such as UML (Unified Modeling Language) diagrams. Therefore, the architect is responsible for establishing a high level of modularity in order to achieve both expandibility and maintainability potentials. Nicely designed modules connected by healthy dependencies have the power to minimize three undesired, internal properties: Rigidity, Fragility, and Immobility. Let’s have a closer look at each one.

The Rigidity property states that maintenance in a specific point in the architecture may oblige the developer to also change directly related points, generating a maintenance chain. I like calling it the Domino Effect. If you don’t enjoy reading Wikipedia articles, you can just read the following extract: “The Domino Effect is a simple chain reaction that occurs when a small change causes a similar change nearby, which then will cause another similar change, and so on in linear sequence”. It’s pretty clear, isn’t it?

The Fragility property, in its turn, states that maintenance in a specific point in the architecture may force the developer to change a point indirectly related to or far from the former point. We will call the consequence of ths property the Butterfly Effect. Again, another Wikipedia snapshot: “The Butterfly Effect is a phrase that encapsulates the more technical notion of sensitive dependence on initial conditions in chaos theory. Small variations of the initial condition of a dynamical system may produce large variations in the long term behavior of the system”. I am sure the meaning is clear.

Finally, the Immobility property takes place when a developer tries to reuse an existing component, but then gets blocked by other component’s classes that the desired ones depend on. I usually call this the Banana-Gorilla Effect, funny huh? This is because whenever you try to get just the banana, the gorilla comes after it. There’s no way of running away from the big animal, and you suddenly lost one of the major features of the object orientation tenet, code reuse.

OK, enough talking, let’s get back to business. How can we avoid having these three bad properties? How can we design only healthy dependencies? Quick answer: Using Interfaces for dependency inversion. An Interface is a partial description of a domain concept, and is certainly an invaluable ally for any software architect. Technically speaking, it’s a bunch of method signatures that allow further specialization. Erich Gamma et al wrote an entire (best-seller) book called “Design Patterns: Elements of Reusable Object-Oriented Software”, which provides a full set of solutions that address common object-oriented software problems. The solutions are divided in three categories (namely Creational, Structural, and Behavioral), and all of them take advantage of interfaces (holy thing!).

In the next post I’ll illustrate the discussion using a graphical, concrete example. Cheers!

You can say anything you want about Microsoft – but one thing is undeniably true: they treat third-party developers as their most valuable resource. Since the first ages of 16-bit Windows consolidation, it was clear that as long as their platform was the mainstream software-running machine (and the minimum bar for hardware support in the PC world), their reign would be safe.

And that translates into treating their developers well. Yes, they have to pay some fees here and there, but they are rarely left behind. MSDN and competent MS staff reveal all you need to know to develop any sort of application for Windows; backwards compatibility is taken to extremes; and all sorts of developers (from corporate form cut-and-pasters to low-level hackers) are treated as first-class citizens.

In contrast, no matter how sexy the platforms are that Apple makes available for your software to run on, they make it painstakingly clear that users are number one. Cupertino doesn’t mind at all if a tiny minor new feature creates one or a dozen hurdles for developers every other week. This is not “right” or “wrong” (and both approaches have shown their results), but it is something to be aware of when you consider developing for an Apple platform.

This was not seen as much of a problem for most developers, since Apple has always been a niché market (even with Mac OS X putting the Macintosh onto the radar for people outside the Mac cult). However, January 2007 saw the announcement of the iPhone, and since then the handset has received  pretty much all types of review – from the Apple fanboy praise (blind to the most obvious flaws and limitations) to the most radical states of denial that ignore the (r)evolutionary aspects of the platform.

In the end, however, the number of iPhones on the market (no one has the exact real number, but it can be extrapolated to be at least 4 million after the worldwide 3G expansion) was the only important thing for developers – those numbers turn it into a big enough market to be considered by anyone that wants to deploy sophisticated mobile software applications.

(J2ME possibly beats those numbers, but having a unified platform for development is an advantage that Jobs has pushed since the early days of the first Macintosh – even when it was almost against common sense).

Development was not allowed by Apple during the first year of the iPhone’s existence, but developers found ways to bend the rules, using alternative ways to build their apps. Distribution was, however, the main hurdle: users needed to “jailbreak” their devices to get applications via alternative channels such as Installer.app (a simple, yet fragile distributed system) and Cydia (a wrap-up of the apt distribution system, which is one of the backbones of software distribution in the Linux world).

The introduction of the App Store (Apple’s official distribution system) changed the landscape, not only by introducing a legal (and ubiquitous) alternative for developers to distribute apps, but also by giving them a nice opportunity to piggyback on iTunes as a distribution channel. This approach of not having a middle man is an enabling factor for thousands of small-scale developers: one little dirty secret of the mobile application world is that mobile operators (which own the distribution and revenue channel) rarely talk to small developers – they have to market their apps by means of “publishers”, which pretty much stifle innovation and initiative in this field.

Even if you want to distribute your application for free, there are operators and handset makers that will make it hard (if not impossible) for users to download your app or transfer it via Bluetooth from other devices. Apple’s App Store distributes free content for free (well, you have to pay $99 for the iPhone Developer Membership, but it’s a fixed, once-off cost).

It’s not all roses, however: Apple imposes all sorts of restrictions – ranging from technical ones (you can’t let an application do background processing) to operational (registration as a developer takes some time to be processed; your app can’t duplicate functions on Apple’s apps; if they don’t like it you are out; you must submit source code to their approval, and nobody knows for sure how compatible with licenses such as GPL their model is). Besides that, the code signing process can be a burden to developers not used to it (even if you decide to ignore Apple and limit yourself to jailbroken iPhones).

It is a “my way or the highway” situation – but recently the first handset with Android (Google’s operating system for mobiles) hit the market. Some consider it underpowered, but others are excited by the tricks it has on its own (while some even question its openness). It is a welcome addition not only for users/developers who won’t be interested on Apple’s offerings, but also gives iPhonophiles the hope that competition will put some pressure on the Big Cupertino Brother to force it to relinquish some of the grip it has on the market.

I have high hopes that this will happen. But even if it doesn’t, it won’t stop a legion of developers (myself included) from working working on my $0.99 app, in the hopes that will be useful for one million people – and that its success will contribute to their own retirement. That is a really hard argument to beat, and it will keep the iPhone going for a long time. But unless we start to see some retired iPhone Developers on their yachts, Apple would do themselves a favor by treating iPhone developers a little bit better – or they will jump ship at the first opportunity – be their destination may be Android or otherwise.