Go with Atom for Go-Lang

Recently IĀ became docker advocate for out teams here in Pune, if you are thinking what does it actually mean, well I have to ramble about how cool docker is and how can we use it for our advantage till person / team across me says “Alright ! We get it, docker is awesome, lets use it” šŸ™‚

One curious thing that I foundĀ while my travels through dockerized world of container as service is docker is written in new language around the corner – Go Lang. Creators of Docker intentionally chose to wrote docker in Go. There are some nice articles that answer typical questions like why and how, but I wanted to personally take a closer look at Go-lang and decide for myself.

As always first step is Initiation and for that I wanted to setup go lang on mac + IDE. Here is roundup of all that worked for me (In short here is how you setup Go Lang and IDE for the same in 10 minutes):

  1. Install GO Lang for Mac, package is available at https://golang.org/dl/
  2. Setup GOPATH – On Mac, I simply added export GOPATH in my bash_profile like this
    • export GOPATH=$HOME/sid-projects/go-workdir
  3. Download and Install Atom editor for mac fromĀ https://atom.io/download/mac
  4. Open preferences for Atom -> +Install, Install following packages:
    • go-plus – This will install everything needed for Atom – GO integration.
    • autocomplete-go – For obvious purpose, if not installed already, install this ASAP šŸ˜‰
    • Platformio Ide Terminal – This will install terminal so that you’ll be able to run code directly through Atom editor
    • After each package install, restart Atom.
  5. If any of those packages have dependencies, you’ll be prompted to take action, it’s just a matter of clicking through all “Yes” buttons.
  6. After final restart of Atom, It’s time to Point your Atom editor to project location.
    • File -> Add Project Folder will allow you to point to project directory that you want to use.
  7. Create new file hello.goĀ like this: Ā  Ā Atom-Go
  8. IF it fails to auto complete, like in my case, it actually gave me warning that some nativeĀ modules needed to be rebuilt, once you do that, restart Atom and you’ll have all the auto complete that you want!

Thanks it folks, It cannot get easier than this, so far I have loved Atom + GO Lang integration, as I progress through learning through GO, I’ll add more on this topic.

Laziness pays off !

I think software engineers are supposed to be lazy as far as development is concerned. Confused ? Let me explain, software engineers are supposed to write good reusable code so that they won’t have to write same thing over and over again, hence be lazy ! I know this sounds funny, but recently while working on my own project as described in my previous post, I had a chance of being “lazy” so I wanted to share the experience on the same with you all …

In my almost 6 years of software development experience, I had to work on a lot of tools. Trust me when I say “a lot”, I mean it. I had to work on like 7-8 tools for various purposes – be it for an upgrade of platform or as a regression tool or as a performance driver or as a validation tool. In all those tools one thing what I always hated doing was loading some configuration into some JAVA POJOs. Those who have worked on ground up piece of software will know this is something you have to write for almost everything and it just sucks to write similar thing over and over again ! So when I started working on my recent project, I decided to make sure I will do something about this problem and try to write something generic so that I can be lazy in future. šŸ™‚

If you see what we all as developers need is to read some specific configuration, say from a properties file or an XML and populate the same in memory as JAVA POJO which represents configuration e.g. For my socket server and client, I need configuration such as server host name, server port etc. After I do that, I’ll need to make server multi-threaded and now I’ll need no of threads as a configuration. So one thing is sure – as we work on the problem at hand, configuration we need can also grow.

Now lets take a look at what process we follow to do all of above in scenario say when we want to load configuration from a properties file:

  1. Add property to properties file
  2. Add same property as attribute to Java POJO class along with getter, setter methods following Java Bean standard
  3. Add code which will read from properties file and call respective setter method on Java POJO

This seems okay once, but when you change configuration and add new properties, you have to go back do all 3 steps over and over again. It doesn’t stop here, you can’t even use same code across your projects because its too dependent on POJO and property names.

So how about writing something generic which can easily adapt for property additions and can also work across different project so that you can truly reuse it ? What we basically need is to take POJO and property names out of the equation. Way to do this is by making sure that our “configuration loader” can work on any given class of POJO and is able to associate property names with attribute names of POJO class. Java gives you some very powerful tools to do this which is called “reflection”. Reflection gives us a way to prospect a class and find out all information about it like what methods, fields a class has.

Now instead of directly jumping to most complex situation, lets lay some assumptions such as:Ā Property name in properties file should match field name in POJO. Now new steps to load configuration would be as follows:

  1. Prospect class of POJO and find out all public setter methods having just one argument.
  2. Instantiate POJO object using POJO class
  3. For each property name in properties file, find setter method in POJO class
  4. Convert property value to expected datatype of setter method in POJO class
  5. Set property value on POJO field using setter method

Using these steps, we have made sure that we can work on any combination of properties file and POJO class. We have created a generic facility which can give us POJO sourced from a properties file. This approach is however not without limitations, if you go through new steps you will notice we have following limitations:

  1. POJO class must have default constructor so that we can instantiate object
  2. Property names and field names should match

Obviously there are ways to work around these limitations but you get the basic point – we have successfully created configuration loader which will let us become lazy !

You can find such implementation on GitHub as part of my pet “Java Pad Server” project as follows:

Actual implementation of configuration loader can be found in a class here, junit tests for the same can be found here.

Project can be found here on GitHub. Don’t forget to visit our org here for other interesting project.

Opening Act

It has always been really hard for me to think of something really nice as opening act, this time I have deliberately tried not to think of anything for opening act, instead let me directly jump into who I am and what am I doing here without wasting your time !

I am Sid, working professional (!) for an MNC company in security domain. Like 10% other ppl of my experience, I am not too happy with limited things I get to do at workplace. So this is just an effort to get out of work cycle and do something that I would want to learn.

Now coming back to part where I explain what the hell is that I am doing here – well I am going to try few things on technology, philosophy and other things here which I would love to work on. Now my aim here to popularize new term that I like to use for some software engineers – “Experimental Software Engineers”. Like we have “Experimental Physicists” ! This term crossed my mind when I was in office discussing how a certain approach would work against another approach technically. Now instead of just speculating on how some thing would work, why not set up an experiment and try it out ?

So here I am trying to adopt my own philosophy of being an “Experimental Programmer”. So as a start, I am going to start with a simple problem and incrementally add complexity to the problem statement and thereby add complexity to solution as well. So lets start by defining problem statement –

We will have a system where multiple clients will send data to a plain socket server. Data that clients send to server is nothing by collection of words. Server processes this data by counting unique number of words in each data. Clients can send multiple data lines in each connection to server. Data is sent intermittently not consistently.

Sound simple right ? Now this is very basic problem statement and as I said before, I’ll make this complex after we get successful “experiment” for current problem statement. Lets take a look at what we are looking for in our experiment:

  1. Wait time for each client connection
  2. Overall throughput of data lines / second that can be achieved
  3. CPU, Memory consumption

Now since we have so much to measure, we also need to make sure that we setup our “experiment” in such a way that experiment itself is not affected by any other external factors. This means we have to same environment for all of our experiments. For simplicity I have created a simple Ubuntu Server setup on Amazon where I’ll be running our experiment. Clients can be situated on my laptop / any other public machine which can talk to my Amazon EC server.

Lastly, one thing I would like to mention here is that it’s not just me who will be working on this, we are a group of individuals who would be working on this project. In case you want to look at the code we are developing, you can visit GitHub account for our org here.