Soa and Life

It’s amazing how principles and styles from software world map directly to day-to-day events. Let it be core OOP concepts such as abstraction, inheritance, polymorphism or design patterns such as singleton, MVC, MVVM, Observer and so on, one can always track the origin of these entities back to different aspects of human society.

For those who don’t know SOA - service oriented architecture. It basically means derivation and integration :).  In this post, instead of getting into the details of SOA I would like to highlight how SOA relates to real life. so let’s get to it!

In SOA, typically the solution is divided into different services which are exposed as HTTP endpoints to other services. They can interact with each other as well as with outside world in some cases. Now in real life, consider your solution to be an organization-MyCompany Inc. Like any organization, MyCompany Inc will divide responsibilities among various groups: there will be a sales team, a marketing team, a production team, a finance and a legal team. Pretty standard, eh? - correct. 

Now comes the interesting part, even though all these teams are headed by the same management folks or C-class executives so to speak, they often interact with each other and with higher management, so what makes this interaction possible ? emails ? - you can’t possibly go wrong with this answer! but if you consider these transactions from a software point of view, the term would be “A Data Contract”! Two teams can understand each other only if both of them are agreed upon the same data contract! just like SOA!

Next, by splitting the entire organization into small focused teams MyCompany Inc can achieve separation of concerns, each team is focused on doing ONE thing, and ONE thing only. This helps people working on the team to align themselves with the goal of team as a whole, and we do exactly the same for SOA! Each service stands for a purpose, to achieve one small thing the right way.

Now the diversity, it very unlikely that MyCompany Inc will have each team with same background, ethnicity, culture, language or even continent for that matter! Also for functioning of the team, each of them requires a specialized setup. Sales guys can probably live with a slow PC, but production guys can’t. Yet despite all the differences, MyCompany Inc has to function somehow, right ? so how SOA is similar here ?, As each service is an individual component, each service can have its own environment, from underlying language to production server, every piece can be customized.

Just to sum it up, understanding the way SOA relates to life gives you a much more comprehensive approach for analyzing pros and cons of this architectural style.

---

Adaption of Java Script

It’s funny how people react to JavaScript, some get excited, some get terrified, while some start crying. In recent past, I’ve seen many folks arguing that JavaScript isn’t really a language. They often say its just something kids like to play with. And some talk about JavaScript with so much passion that I feel they love JS more than their wives. Interestingly, I could see a pattern emerging out of all these discussions. 

A JavaScript conqueror has to go through 4 phases to accept the language.







1. Ignorance: 



Typical sentiments - Who cares about JavaScript ? Do people actually code it in ? OMG! what the hell world has come to. Real programmers code in Java, So I’m just gonna learn java.



2. Hatred:

Then comes a project requirement asking developers to learn JavaScript. 

Typical sentiments - Why are you making me do this ?

After coding for a while in JavaScript developers usually fall prey to JavaScript gotchas. And hatred grows even more!

Typical sentiments - No, I’m never going touch JavaScript again, the hell with this project and this company!

3. Acceptance:

Finally folks understand that JS isn’t going anywhere. Then comes zen moment in JavaScript. If you’re in this phase, just step back from computer and think about meaning of life. Why JS exists.

4. Realization:

After you’ve hit the zen moment, then comes realization of beauty and simplicity of JavaScript, you get introduced to awesome frameworks like Angularjs, Backbone, jaydata. tools like grunt, bower and JavaScript becomes your beloved language!

And remember, this is just the beginning! 

---

Beauty of Closure in Java Script

Closure is one of the good parts in JavaScript. Its an amazing way to enable access of local variables from parent function scope, irrespective of the context in which function was invoked. Wait, Instead of getting into jargon about closure, let me just illustrate with a few examples.

Problem statement:

Write a function which will take a digit as input and output verbal representation of the same.

Solution 1:

var numberMapping = [‘zero’,’one’,’two’,’three’,’four’,’five’,’six’,’seven’,’eight’,’nine’];
function getNumber(number) {
    return numberMapping[number] ? numberMapping[number] : ‘Inavlid input’;
}

// getNumber(1)
// “one”
// getNumber(12)
// “Invalid input”

Lets try to analyze this, we have a global array which holds verbal representation of all digits, and then we’re using this array to return corresponding output of given number. Problem with this approach is, numberMapping array is just dangling in global namespace, means it could be modified anywhere in code. And ofcourse, if modified it will give incorrect result. So this approach is bad. In JavaScript always try to avoid global variables to the extent possible. Also this might create a problem in minification as most of the minifiers tend to change the variable names to shorter versions.

Solution 2:

function getNumber(number) {
    var numberMapping = [‘zero’,’one’,’two’,’three’,’four’,’five’,’six’,’seven’,’eight’,’nine’];
    return numberMapping[number] ? numberMapping[number] : ‘Inavlid input’;
}

// getNumber(1)
// “one”
// getNumber(12)
// “Invalid input”

Oh! so we just take the variable inside getNumber function making it local. It works fine and solves the problem we faced in solution 1. But this still isn’t the best approach. Because every time getNumber is called, numberMapping array will be initialized and memory will be allocated to it. So this is nice but not the optimum solution.

Time to use closure:

var getNumber = (function() {
    var numberMapping = [‘zero’,’one’,’two’,’three’,’four’,’five’,’six’,’seven’,’eight’,’nine’];
    return function (number) {
        return numberMapping[number] ? numberMapping[number] : ‘Inavlid input’;
    }
})();
// getNumber(1)
// “one”
// getNumber(12)
// “Invalid input”

OK, so this looks a bit complex. What we’re doing here is executing an anonymous function and storing the returned value in a variable named getNumber. In this particular case we’re returning a function. And yes, we can do this in JavaScript! This approach solves the problem we faced in solution 1 by encapsulating numberMapping array. Also as the upper function will only be executed once, hence numberMapping array won’t be initialized every time we call getNumber. And the inner function has access to numberMapping variable because of the beauty of closure!

To sum it up:

This approach is helpful in many conditions, the most common one is while trying to write object oriented code in JavaScript. using ‘prototype’ or ‘this’ for creating classes does not really fit in overall code ethics of JavaScript. if you use ‘this’ or ‘prototype’ for creating classes, implementing singleton class is not an option. Whereas if you use closure you can use the same style of coding throughout the code base. Using closure in javascript definitely helps in writing beautiful code.

---

Companions for Phonegap

Phonegap has opened up a whole new way of creating mobile applications, in a nutshell it follows “write once, run anywhere” principle. There are some obvious trade-offs of using phonegap. But once you decide upon this framework, there is still some further RnD required on things like which mobile framework should I choose ? How do I build application for various platforms ? and so on. In this article, I’ll try addressing these issues.

The main problem with JavaScript world is, there are just too many options to choose from. Every other day there comes a new framework claiming it makes development far easier than others. As a result there is nothing like one framework to rule them all. So it ultimately boils down to a soup of frameworks which you have to choose. However just like any other application; JS apps can also broken down to two separate layers of UI and Logic. With this in mind we can now look at various frameworks for mobile development.

UI frameworks
In case of UI, its mostly CSS magic. There are few points should be considered when looking at CSS framework.

1. Supports CSS3 transitions - CSS3 is the fastest way one can animate in browser
2. Provides wide range of mobile controls
3. Supports vector icons
4. Grid support is a must
5. Has helper classes for creating common elements such has action bar, tab navigation.
6. Should be lightweight (in size and complexity of rules)

Also make sure you test on actual device before zeroing down on a framework. Device emulator in chrome doesn’t give you the real picture! In my personal experience I’ve found that many frameworks claim support for all the platforms but do not perform up to the mark when tested on actual devices. If you don’t have a device in mind, then try testing it on as many different devices as possible :)

There is a really nice website I found for comparing mobile frameworks - http://frameworkdemos.com/

Just open this from any mobile browser and start looking how elements are actually rendered on the device.

Backend

Now as for the logic part, most of the UI frameworks give you a way of listening to events. But that’s not enough when we are considering a large application. so for deciding back end logic part of your application there is another great project TodoMVC - http://todomvc.com/. By looking at the code samples, you can get hold of how popular MV* frameworks in JavaScript actually work. Most of the frameworks in this arena are opinionated so in this case there can’t be a thumb-rule for selecting a framework. Just see if it fits your requirements!

Building your application

There is a great tool to build your application for all platforms. https://build.phonegap.com. You can hook up this with a github repository, start the build, download apk and you’re done! Now what if you have to automate this build ? sadly, build phonegap doesn’t support that as of now, at least for the free version. but they have exposed APIs in case you want to fire a build request programmatically. For further reading use https://build.phonegap.com/api

Additions are most welcome :)

---