perseverance

Einstein vs Bohr

Sun, 31 Mar 2013 22:14:37 +0800

Einstein: God does not play dice
Bohr: Einstein, stop telling God what to do

"Ah! that feeling of reading first few lines of an old loved book again - it’s like first drops..."

Fri, 15 Feb 2013 23:40:29 +0800

“Ah! that feeling of reading first few lines of an old loved book again - it’s like first drops of monsoon rain after a long dry summer.”

- me :-)

Go Getable Code On Github in 7 Easy Steps

Thu, 14 Feb 2013 01:41:00 +0800

This post is based on Github Code Layout and How to Write Go Code. But works from a slightly different angle. I’ll list down steps to create a new go repo under your own account at github. Also, helps illustrate the use of “go get” command and some concepts about structuring of go code.

Let’s start:

1. Set GOPATH

Set GOPATH to a directory of your choice that will act as workspace for your go project(s)

example: export GOPATH=/home/haps/langs/gomy/gows

2. Create Base Path

In your GOPATH directory, create directory structure based on your github username as follows:

cd $GOPATH
mkdir -p src/github.com/<your github username here>

example: mkdir -p src/github.com/harprit

src is the directory under GOPATH that holds go code. Other two directories allowed under GOPATH are bin and pkg

github.com/<your github username> is your “base path” that’ll serve as a unique identifier for your project(s)

3. Create Project

Next under the base path, create the directory that will eventually hold the actual code for your project. I’ll use my new project’s name as gogithub which is same as my repo name on github.

cd $GOPATH/src/github.com/<your github username here>
mkdir <your project name here>

example:
cd $GOPATH/src/github.com/harprit
mkdir gogithub

4. Work on Project

Next, move to your project directory and wget (or copy paste) uselessd.go from jmcvetta’s github repo. We are using this file as it’s an example code that in turns depends on other repos like “code.google.com/p/go.net/websocket” and “github.com/jmcvetta/useless”. As we’ll see, these dependencies will be automatically taken care of by “go get” command.

cd <your project name here>
wget https://raw.github.com/jmcvetta/uselessd/master/uselessd.go

example:
cd gogithub
wget https://raw.github.com/jmcvetta/uselessd/master/uselessd.go

5. Build and Install Project

uselessd.go is a main file (uses main package) and can be considered a mini application in itself. That’s it we are done, just need to install this app now.

From your project folder (gogithub in my case), execute:
go get .

Or, from any location, execute:

go get github.com/<your github username here>/<your project name>

example: go get github.com/harprit/gogithub

(you may use symbolic links to make this a bit convenient)

This will download all repos used in main file and install the executable under your $GOPATH/bin folder.

6.Verify Executable

Executable can be verified as follows:

cd $GOPATH/bin
./gogithub

This will start a web server using websockets.On hitting http://localhost:3000/useless, you should get something like “not websocket protocol”.

7. Upload Project to Github Repo

You can now upload your new go project to github. Please note that it’s your project that needs to be added to github not the entire workspace.

go to $GOPATH/src/github.com/<your github username here>/<your project name here> and run the usual git commands.

example:
cd /home/haps/langs/gomy/gows/src/github.com/harprit/gogithub
git init
git add uselessd.go
git commit -m “first commit”
git remote add origin https://github.com/harprit/gogithub.git
git push -u origin master

This example code is at https://github.com/harprit/gogithub If you face any difficulty you may get, build and install this example code directly to your $GOPATH using the same go get command as follows:

go get github.com/harprit/gogithub

One last but very important thing - when you add more go files in your project - always import paths relative to $GOPATH/src i.e. import should include your base path.

To understand this fully:

go get github.com/harprit/gogreeter

(run $GOPATH/bin/gogreeter to verify installation)

Check how the main.go file in this project imports internal greet package using:

import ”github.com/harprit/gogreeter/greet”

and not just import “greet”

This is important as it makes code aware of its repo host (base path) and is thus “go getable” i.e it builds, installs and runs seamlessly anywhere without any changes whatsoever.

"The only article Lady Fortuna has no control over is your behavior. Good luck."

Tue, 15 Jan 2013 23:34:00 +0800

“The only article Lady Fortuna has no control over is your behavior. Good luck.”

- Last line in Fooled by Randomness by Nassim Taleb

Square root by Newton’s method in Go

Sun, 06 Jan 2013 01:05:00 +0800

Doing that famous first exercise from SICP in Go:

Square root by Newton's method in Scala

Sun, 06 Jan 2013 00:26:00 +0800

Doing that famous first exercise from SICP in Scala:

Square root by Newton's method in Clojure

Sun, 06 Jan 2013 00:14:00 +0800

Doing that famous first exercise from SICP in Clojure:

Empty interfaces in Go

Sun, 08 Apr 2012 01:08:00 +0800

Consider that you have to implement a collection in Go. A collection, by definition, must be able to hold any type. Something which Java Collections achieve using Generics (or the Object class before Generics). How do you define such as a generic type in Go?

Check out the following struct definition of a list element in list.go implementation:

It defines the Value as an empty interface{}. This is interesting - as an interface usually defines a set of methods. Any type that implements those method can be assigned to the interface type. But there’s is no such restriction here at all - interface{} does not defines any methods for implementation. This means that it simply can be satisfied by every Go type.

The other side of coin is that you cannot call any method on such a type, since there is none defined. But this is fine as we are only concerned about collecting such types without worrying about there behavior. Crafty.

Java Library readResolve usage

Tue, 03 Apr 2012 22:49:00 +0800

Haven’t been using old-style static singletons much nowadays. But the Java Library always keep surprising you with things you may not have noticed before. Saw following small EmptyList implementation in Collections.java. The class makes use of readResolve() to dis-allow any other instance to sneak in after de-serialization.

Liskov Substitution Principle

Thu, 29 Mar 2012 16:04:00 +0800

LSP is about well designed inheritance keeping both in mind: the domain understanding and the usage in code. When you substitute a subclass for it’s base class its should be for flexibility, reuse etc. There shouldn’t be any side effects / discrepancies / repercussions. If it doesn’t feels right dump inheritance and use: Delegation / Aggregation / Composition.

The good old Rectangle Square example (from here):

In mathematics, a Square is a Rectangle. Indeed it is a specialization of a rectangle. The “is a” makes you want to model this with inheritance. However if in code you made Square derive from Rectangle, then a Square should be usable anywhere you expect a rectangle. This makes for some strange behavior.

Imagine you had SetWidth and SetHeight methods on your Rectangle base class; this seems perfectly logical. However if your Rectangle reference pointed to a Square, then SetWidth and SetHeight doesn’t make sense because setting one would change the other to match it. In this case Square fails the Liskov Substitution Test with Rectangle and the abstraction of having Square inherit from Rectangle is a bad one.

Open Closed Principle

Mon, 27 Feb 2012 03:27:00 +0800

Template, Strategy, Decorator are some patterns that facilitate OCP. Read this for discussion on the same and why it must not be taken to an extreme:

This prevents you from introducing new bugs in existing code. If you never change it, you can’t break it. It also prevents you from fixing existing bugs in existing code, if taken to the

…

XP has shown us that there are many classes that can be altered frequently, at low expense, and to the benefit of the overall quality of the program. There is no need for these classes to follow the OCP, indeed adding otherwise unneeded code to do so is probably detrimental. However, those who have developed libraries, component based software, and software frameworks have shown that there is a tremendous value in having some classes that never change. These classes benefit greatly from the OCP.

Single Responsibility Principle

Sat, 21 Jan 2012 01:52:00 +0800

Single Responsibility = Single Reason For Change

For example, if for a change request we need to modify the class. Then in the next iteration, a change request of only a similar nature/type should demand a change in the class. Different types of change requests do not lead to changes in the same class.

Type of change requests define SRP conformation/violation. Same class in one applications may be conforming to the SRP but may be violating it in another application. So, it depends on the changes.

This One For ?:

Thu, 08 Dec 2011 02:33:00 +0800

If else shorthand is one of the few things that makes Java code readable in that clutter of curly braces. Recently discovered there’s a Wikipedia page for the usage of the same in different languages. Cool.

Here’s my go. Ever implemented a nullSafeEquals method in your utility code with a number of if else blocks (nested even) and still stay confused if you got it right or not. Observe the simplicity here:

Integration Tests

Mon, 28 Nov 2011 19:03:00 +0800

unlike unit tests, have more than one responsibility
span over more than one component / architectural layer / classes
may use some actual dependencies and may mock others - what exactly you want to test drives this

Unit Tests

Mon, 21 Nov 2011 17:54:00 +0800

Any kind of dependency that is hard to understand / initialize / manipulate should be stubbed/mocked/whatevered using the appropriate techniques so you can focus on what the unit of code is doing, not what its dependencies do.

Initially, unit tests are viewed as “design documents” for the code. But later (when related code is done), each unit test does serves to verify one unique thing about a piece of code.

Usually, when an acceptance or integration test fails, related unit tests fail as well and are more helpful in pointing out the exact cause of the failure.