A Developer Switches from Windows to LAMP Part 3: Project Dagobah

The best way to learn any new language/platform/library etc. is to get your hands dirty playing with it. Build something useful , not merely a todo list, but something similar which has a utility, yet does not have a large scope in terms of use cases. But do it end to end: i.e. don't just have a working version on your development machine, deploy it to a server and make it readily available to the whole world. 

In April, from among the many ideas that I had, I chose to build a tool which would help you number your tweet storms. Even this phrase "number your tweet storms" is a result of multiple revisions. I did not even know what a tweet storm was back in April! Of course, there was a massive and a much needed break from mid April through May as I went back home for my sister's wedding and then went on a trek to the Himalayas. So I really started work on this in mid June after I was back in Bangalore. I will write in more detail about how I went about developing it, but right now I want to announce the first release of TweetSmart. As of today, it is only a web application. But very soon I hope to have built it into a chrome extension as well as an android app. 

This post, however, was not meant just for the announcement of the release of the app. It is meant to be a high level recap of my experience developing and deploying my first app on Linux, or to be more specific, Ubuntu. 

I originally envisioned TweetSmart as only a Chrome extension. Thus I started with Getting Started with Chrome Extension Development. Building a simple Hello World extension was easy. But I now wanted to build the TweetSmart compose box and that meant a a lot of javascript code. An immediate choice I had to make was to choose a javascript framework such as Angularjs, Emberjs etc. to build this. Having a bit of experience with Angularjs I was inclined to choose Ember but had heard a lot of good things about React. I decided to spend sometime familiarizing myself with React and understand its benefits. In the process I learnt about Flux as well. The uni-directional data flow in Flux architecture made sense to me. I also read many posts by people who were astonished by how much cleaner their code was due to using React and Flux. So I decided to proceed with Flux+React and not get bogged down by trying to make the perfect choice of framework. 

Till now, the choice of Flux+React has nothing to do with developing on Linux. I could very well have developed this extension on a Windows machine while using React+Flux. However, the first place that the difference becomes apparent is the choice of the IDE. On Windows, I would be using Visual Studio. On Ubuntu, I had started to learn Vim and thought the terminal and vim are going to be all that I need to code. However, a very important aim while coding is to be fast - i.e. use tools and extensions for productivity. E.g. you can significantly reduce the number of keystrokes in Visual Studio by using code-snippets for common code constructs such as if-else, function(){} etc. I am sure expert vim users would know a way to do that in Vim, but as a newbie, it was taking me time. 

As it is important to ship the MVP as soon as possible,  I looked at options where the learning curve was slightly less. Interestingly, Microsoft had just come out with Code, a new code editor for all platforms, but since it was pretty new on the block I looked at other options - Atom from Github and Brackets from Adobe. Both of them are very similar but it seemed Brackets had a more active plugin development community with much more plugins, which made me select Brackets. 

I felt at home with Brackets and quickly started adding code snippets which I would use frequently, such as rcc for React.createClass. I also installed plugins such as Emmet and Beautify to speed up coding. However, as I later realized, since I was using React, the Emmet plugin did not prove to be very useful there.

Next, I wanted to set up a local web server and chose Apache over nginx for some random reason I don't even remember. However later on, as I was building an API using expressjs, I had to use node behind an nginx server and thus I ended up using nginx and removed apache. I did this on my local system as well as my production server, a micro ubuntu instance running on AWS. It was a nice change from using the Inetmgr to configure the IIS, though not without issues. 

As I realized that to integrate with twitter I would have to build my own api, the question of which framework/language to use came up. The options in my mind were ruby with sinatra and python with flask. But I had a conversation with a friend who suggested to go with node and expressjs. And I happy that I did. 

So that is a high level recap of some of the decisions that were made when using ubuntu/linux. These might seem very trivial to many, but for a person who has been coding using the IIS, Windows, ASP.NET and Visual Studio, these were new choices which took a bit of time to research and arrive at a decision. 

I am definitely now more at home using ubuntu, desktop as well as server. I have much more confidence that I can quickly get up to speed with a team working on a variant of the LAMP stack.  I can only get better from here. 

Upwards and onwards.