We have a few positions vacant at the moment – have a look:

In Sao Paulo, Brazil – we need a junior front-end developer. You are highly skilled in front-end development, with specific skills in CSS, HTML and Javascript. You are a competent programmer, but you prefer to work on the front-end. You will be working under the guidance of an experienced and expert engineer. You like working with bright and clever people, and you are passionate about the web. The successful candidate will speak English, and will be a paulistano, or be willing to relocate to Sao Paulo.

In Johannesburg – we are looking for a senior technical architect. You will have the opportunity to establish the blueprint and create the framework for truly cutting edge media delivery platforms that will change the face of media in South Africa. And that is no exaggeration. You should have outstanding technical skills, including the ability to code as and when required. You must be able to interact with a team of highly skilled professionals. You will ideally have experience of VOD, digital TV, IP-TV and related technologies. A background as a developer is essential – you will have in-depth knowledge of the Microsoft .Net platform, but also wider knowledge of open source platforms and languages. You are comfortable dealing with executives and senior managers. You’re not only an ubergeek, but also an inspirational tech leader. This is a challenging position – but it represents a massive opportunity to the right person. Detailed requirements here.

In Cape Town – we are looking for a junior tester, who will devote a great deal of time to ensuring that a large corporate social network meets the right quality standards. You will be part of the SWAT core team – you must be prepared to work with some of the best developers, architects, geeks and web-heads you are ever likely to meet. Can you execute tasks on your own initiative, prepare and execute test plans ? More details on the position can be found here.

Cape Town – we are looking for someone to play the role of Internet Evangelist. This role is available to anyone who is absolutely passionate about the web, who is capable of conveying this passion to diverse audiences, who learns quickly … and who can teach others. Your role will be to evangelise the use of Web technologies (and other Internet related technologies) into the larger group – the challenge is to make people from all non-internet businesses see the Internet as an opportunity not a threat. In addition you will perform tasks as assistant community manager for the corporate social network, and you will assist the Analyst in the team with research tasks. You must be willing to travel in South Africa and abroad, as required. To apply for this job, you will have to demonstrate passion, interest and knowledge of the Web and related technologies. You are a well-spoken, confident geek, web-head and proud to be a Web addict.

Finally, and also in Cape Town – we want to recruit a PHP developer. You will be have outstanding technical skills, wide experience in web based development, and you will be able to hold your own amongst an elite group of developers and architects. Javascript, Zend Framework, AJAX, OO, Web 2.0, REST, SOAP and UML will be old news to you. You are passionate about the web. If you think Twitter is silly, you don’t need to apply. More information here.

If you are interested in any of these positions, please send your CV to Melanie Koch. We look forward to hearing from you.

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.

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!