Wednesday, May 30, 2012

Why We Started ZoomBA Cloud

Those who follow me on social media might have seen me go on about this "ZoomBA" thing and may have some idea about it. For others, in short, it's our own Cloud SaaS meant for Small Businesses (or SMEs as it is called elsewhere). But I thought of sharing the story of ZoomBA (which at this point sounds more like an African folk tale)r. Though we started working on ZoomBA earlier this year, the whole concept actually began quite a while back.

Once upon a time, in December 2004, Sanjiva rang me up on an idea of building an "Out of the box" appliance for Small Businesses out in the US. By his estimates, majority of them did not have a drop in IT solution which worked. Being a FOSS advocate myself and trying to drive Linux adoption, I immediately connected with the idea of making an IT system that worked for a Small Business. But I wasn't ready to start a company just then and had already committed to join another company, so it had to wait!

Finally in late 2005, myself and Lakmal teamed up for the challenge. We didn't have much startup capital and so incubated our project along side Sanjiva's other company. After a bit of brainstorming we came up with the name THINKCube for the company and the tagline "Out of the box solutions in a box" (Shahani was the inspiration for it). Company setup aside, we really started focusing on the key question of "What does it take for a Small Businesses to run their IT system and what's preventing them from doing it".

Without going into the details, I will simply state that we realized a lot of Small Businesses didn't want the hassle of hiring an IT department only to loose control to the IT guy. Instead they were very focused on growing their business and IT is seen as something that would be nice to have but not worth the trouble.

thinkCube's go to market exercise was an interesting learning experience. Like most startups, we had to go through a lot of experimentation in figuring out the product's technology and look & feel. The other challenge was how best to put it in front of our end user. First we tried to build a hardware appliance but later realized that we weren't really equipped to handle the logistics of moving devices around the globe. So we turned to virtualization by creating VMWare bottles of the product and then multi-tenant virtualization running on a Telco Cloud Infrastructure. In the same manner we did several UI iterations before settling down on our current dynamic shell which offers SAML based SSO, fun dashboard widgets and context sensitive end-to-end help. (You can read more about it on the ZoomBA blog.)

So thats how ZoomBA came about. It's our attempt to really address the core issues that prevent Cloud SaaS adoption among Small Businesses. While I know we haven't addressed all the issues, I am confident we have addressed some of the most fundamental ones.

The journey so far from the inception of thinkCube to us brainstorming, arguing, building, abandoning, rebuilding has been such a reward. I hope our hard efforts will come through when users finally get their hands on the system once we start sending invites out soon! In the mine time, if you know anyone who could benefit from a service like ZoomBA, please spread the news.

Monday, May 14, 2012

Peer-to-Peer Collaborative Development Using GIT

Wow how time flies when you’re having fun! I first thought of writing this post back in January, when I was on a roll with writing blog posts. But it never materialized beyond notes I collected in preparation. Come several months later with a lot more experience on what I am about to tell you, and you have this post. The notes I’m referring to is about a development style that came about as a result of optimizing, how we at thinkCube organize and work with source code in a revision control system. Considering the wide use of such systems such as SVN and GIT, I thought I’d share our development experience in the hope it will help you to take another look at your own development style. But before I get into it, I’d like very briefly touch on some background on the evolution of development styles around version control systems.

Thou shalt not commit, Yet!

Back in the days of CVS, source code lived centrally on a server called a repository. One had to earn the right to read/write to this repository in order to ensure “world order” (others had to submit a patch via Bugzilla). While this led to a centrally managed system of Collaborative software development, it also created a new software development style of “Earn your commitership”, “Commit often” and “Communicate often”. Nothing much changed when everyone moved over to SVN, which started out as an improved CVS. This development style didn’t go down well with Linus Torvalds for his Linux work and so he created GIT instead and hates CVS/SVN.

Pray-Pull-Push style of development

We started with CVS back in 2005 and then SVN for managing our development at thinkCube. A little while after git came along when it was stable enough to use and also was usuable by mere mortals, we made the switch. At first we had some trouble wrapping our heads around git and so just used it like SVN where we used to always do commit/pull/push operations as if they were atomic. But after about a week or two, we realized the power of git was in its ability to let you commit locally and push when you were ready to share. And so, yet another development style arose where git acted as a Collaborative Whiteboard for sharing code changes. This also meant developers needed push access to the central repository in the same manner commit access was required with SVN/CVS.

The unfortunate development style this results in is that developers may occasionally push unfinished worked upstream just to share it with the “Developer next door”. The consequence of that maybe felt by the poor developer that spent all night working on a feature, pulls in oder to push to find that his code now conflicts for no apparent reason!

Now I know a lot of you may be on this style of development and thinking, “If our developers do that, we punish them!” and so they don’t! Good for you! But my take on this is, if the system is fundamentally broken then it’s better to fix it than to enforce tough rules. For example, if I may digress for a bit, “Why are TukTuk drivers and Motor Cyclist so careless?”. Is it likely that only careless drivers pick up these vehicles or is it more likely the vehicle made them reckless? My advice is if the tool is broken, then fix it! (and ban TukTuks :)

Therefore last year we decided to adopt our current style of development which is as follows.

Fetch-Merge-Push style of development

If Linus can do it, then so can you! We didn’t invent this stuff but we did adapt it in a manner which scales for us. The idea is simple, stop devs from committing upstream as a means of sharing changes but instead get them to share peer to peer by fetching from each other. Our git repos are setup so that everyone has read access to clone the repo but only a couple of devs (usually just one dev) can push to a given repo. That means the dev who has push access usually will not need to pull prior to pushing because no one else can change it. This is what git was designed to do and yet it’s probably one of the least used features among git converts.

Ok so lets get technical shall we?

First off, I’m assuming you know git basics and are already using it. If not then checkout my git article on Digit

Sharing your repo

Let’s look at how you can share your git repo with another P2P style. Suppose you have a repo as follows:


You can easily share your awesome.repo with anyone on the local networking using git-daemon command by first cd-ing to it’s parent directory.

$ cd /home/bud/repos
$ git daemon --export-all --base-path=.

The above will share all your git repos under the current directory as read-only for others in the network to fetch. Git daemon will run in the foreground by default and so once you’re done sharing you can just Ctrl+C it.

Fetching a shared repo

In order to fetch from a fellow dev, you will first need to add him/her as a remote. Chances are you cloned the project from upstream in which case you have just one default remote called origin which points to your upstream repo.

To add another remote for your friend joe for example

$ cd /home/bud/repos/awesome.repo
$ git remote add joe git://joes-computer.local/awesome.repo

From within your repo, you add a remote using the git remote command. The url above uses git’s special git:// protocol that is understood by the git-daemon, while I’m relying on mDNS to resolve joes-computer.local automatically. If your network(or OS) doesn’t support this, then you can just use the IP address.

Finally to fetch joe’s changes over the network to your machine issue:

$ git fetch joe

The above command should give you some feedback as to the success of the fetch operation. Remember that fetch is safe since it only “fetches” as opposed to pull which fetches and then tries to merge. So while you could’ve used pull instead of fetch, I wouldn’t recommend it!

Merging and deleting

Now that you have a copy of the remote changes, what you’d want to do next is to see which branches they were working on. Usually joe will tell you, hey my latest changes are on the new-cool-feature branch.

$ git branch -a
* master

Git branch will first show your local branches (master, experimental) followed by the remote ones. At this point you should checkout a remote branch you’re planning to merge and just make sure everything is working.

$ git checkout -b joes-new-cool-feature remotes/joe/new-cool-feature

This creates a local branch called “joes-new-cool-feature” which tracks the remote branch remotes/joe/new-cool-feature and switches the current HEAD to it. Once your happy then you can switch back to master and merge.

$ git checkout master
$ git merge joes-new-cool-feature

But… if you have any merge conflicts then you will have to resolve it! If you don’t then your master will remain in a state of CONFLICT. If that sounds like additional work, then do what I do instead of above.

$ git checkout master
$ git checkout -b master-merge-joes-new-cool-feature
$ git merge joes-new-cool-feature
$ git checkout master
$ git merge master-merge-joes-new-cool-feature
$ git branch -d master-merge-joes-new-cool-feature

Wow that’s a handful of commands to type, you say. Trust me, it beats wasting time trying to resolve someone elses conflict! In above, we fork master as master-merge-joes-new-cool-feature in anticipation of a bumpy merge. If things go right, we then merge the merged to master :) The last line is just to delete the temporary branch which we no longer need.

Of course, as you go back and forth merging these micro commits with a dev, you will get into a comfort zone of realizing things won’t go wrong in which case you could merge the remote directly.

$ git merge remotes/joe/new-cool-feature

It all depends on how much you trust the other dev :) and how much of merge conflict resolution you’re prepared to take on. The branching approach is safer and if you’re the BOSS and you have a merge conflict you can simply abandon the branch and ask your peer dev to fetch from you and fix the conflict and let you know! (Which is what Linus would generally do)

One particularly useful technique to extract a good commit from a potentially set of conflicting ones is to use Cherry Picking. If you know the commit log’s SHA1 then you can use that to do a cherry-pick style merge.

$ git cherry-pick 623a3dfb5e86f4da4e043f26b6f075f6e3be77ad

Working remotely

The issue with git-daemon is that it is more difficult when you’re not on the same network and masked by a bogus IP. One technique is to get the router to DNAT the 9418 port. Another option is to setup a VPN. A third option is to use a bit of SSH tunneling magic to get everything to work. I’ll cover that in a different post, perhaps.

Sunday, January 01, 2012

A New Desktop for a New Year

Simple, minimilistic Mint desktop

Compared to other new years where I would spend some time cleaning up my room or upgrading my gear, this year I did none of that! Instead I invested some time cleaning up my online space starting with a brand new distro. I’m a big fan of MacOSX’s Lion desktop and wanted to bring some of that minimilistic simplicity to the Linux desktop. So if the above screenshot looks appealing, then read on to see how you too can get a modern desktop that is simple and elegant. Unlike some of my previous desktop customization article, I’ll keep this one to the bare minimum so that you can implement it fairly quickly.

Installing the base OS

IMHO, Gnome 3 is the best next thing when it comes to being a modern desktop. I realize this is a controversial statement, given news of some ditching and some forking the project. But IMHO when you have a project that can polarize a community that was once united, it means you’ve got true innovation - not just incremental tweaks.

Having said all that, I’ve started with Linux Mint 12, as the base distro to build my minimilistic desktop even though Mint has many of the traditional Windows like UI elements. Now, I’m sure you could do this with Ubuntu 11.10, the base for Mint 12, but I like Mint due to their focus on usability where most of what I need work out of the box!

Let the tweaking begin!

Don’t worry I’ll keep it to a minimum! The first thing I did was to get rid of the bottom taskbar completely, because its soo Windows 95 like! Fortunately, Gnome 3 comes with an “Advanced Settings App” (gnome-tweak-tool in CMD line) which uses the same iPhone like on-off toggles to do the job.

Gnome 3 Advanced Settings App aka Gnome tweak tool

Goto Desktop section within Advanced Settings App.

Have file manager handle the desktop -> ON
Computer icon visible on desktop -> OFF
Home icon visible on desktop -> OFF
Network Servers icon visible on desktop -> OFF
Trash icon visible on desktop -> ON
Show mounted volumes on the desktop -> ON

From the above list if you decide you want to see the Computer and Home icons or perhaps not have any icons then go right ahead. I have my reasons for the above :)

Goto Shell section and make sure every toggle is OFF

Goto Shell Extensions

This is where we do most of the customizations. We will come back to this but for now:

Menu Extension -> OFF
Media Player Extension -> ON
Smart Overview Extension -> ON
Monitor Status Extension -> OFF
Bottom Panel Extension -> OFF
User Themes Extension -> ON
noa11y Extension -> ON
Alt Tab Extension -> ON
Notification Extension -> ON
Shutdown Menu Extension -> ON
Window List Extension -> OFF

Goto Theme section and select Mint-Z-Dark as the Shell theme

Installing tweaks

As I’m running this distro on a 10” netbook, I wanted all the screen real-estate I can get. Besides running apps in full screen mode is all the rage these days! The other tweak that comes from the same repository, is to overlay an icon when viewing all open windows in the Exposé view. This makes it a lot easier to figure out which window preview is for which App.

Install PPA repository and plugins

sudo add-apt-repository ppa:webupd8team/gnome3
sudo apt-get update
sudo apt-get install gnome-shell-extensions-autohidetopbar
sudo apt-get install gnome-shell-extensions-windowoverlay-icons

After logging out and back logging back in (or Alt+F2 followed by r), head over to the “Advanced Settings App”

Next to the “Shell Extensions” section you should find new toggles

Smart Overview Extension -> ON
Auto Hide Top Panel Extension -> ON

In order to get more space and simplify the window, I wanted to get rid of the menubar by integrating it as a global menubar. Unlike MacOSX’s global menubar which is horizontal, this one is vertical and works perfectly with my limited screen width.

sudo apt-get install gnome3-globalmenu

Next I wanted get rid of the scrollbar, similar to how it is with Ubuntu. I used an updated verion of it from another PPA.

sudo add-apt-repository ppa:ayatana-scrollbar-team/release
sudo apt-get update
sudo apt-get install overlay-scrollbar  

Ok almost done. The final step I did was to install a nifty applet that is great for laptops to manage power settings and screen resolutions, especially when you want to project. It adds itself right to the top menubar for easy access.

Install Jupiter

sudo add-apt-repository ppa:webupd8team/jupiter
sudo apt-get update
sudo apt-get install jupiter

And we’re done! Enjoy your new desktop this holiday season and Happy 2012!

Update (02-Jan-2012)

After writing the article I wondered if it was possible to get the Window titlebar to dissapear whereby Apps can run in full screen similar to Lion. Though its not perfect, the following hacks will give you just that!

Install window-buttons extension to mirror minimize, maximize, close buttons in the top menubar

sudo apt-get install gnome-shell-extension-window-buttons

Now enable the extension using “Gnome Advanced Settings” by visiting the “Shell Extensions” section.

Window Buttons Extension -> ON

Install maximus daemon to automatically remove the title bar as a window is maximized.

sudo apt-get install maximus

Restary Gnome 3 and your set. You can restore a maximized window using the buttons in the top right corner of the top menu bar.