Monday, December 08, 2014

Android Studio version 1.0.0 Released

Much waited Android studio V1 is out. Well,  if you are android dev, and do android as your day job, you should not be excited about this release much because , we know how quick is google when it comes to AS releases.

I am happy now the AS is out of BETA. Now I expect google to be responsible as not to ship buggy versions anymore. Thanks Google for taking AS out from Beta.

While this post is about AS 1 release, this is particularly about a FIX you need to do to your Gradle builds to get the new version up and running. If you use following properites in your build file, you might have a tough time figuring out why your builds are failing with this new shiny production ready AS.

OK, lets cut to the chase.

If you get one of these errors,


  1. Gradle DSL method not found: 'runProguard()'
  2. Gradle DSL method not found: 'zipAlign()'
  3. Gradle DSL method not found: 'jniDebugBuild()'
  4. Gradle DSL method not found: 'renderscriptDebug()'

You should change those property names to these new ones,

  1. BuildType.runProguard  ->  minifyEnabled
  2. BuildType.zipAlign  -> zipAlignEnabled
  3. BuildType.jniDebugBuild  -> jniDebuggable
  4. BuildType.renderscriptDebug  -> renderscriptDebuggable


Find more changes below,

http://tools.android.com/tech-docs/new-build-system

Lesson learned,

Don't update AS, without looking at release notes as new releases may not be backward compatible.







Friday, November 21, 2014

Java-OOP fermentation


Java is a wonderful language. No doubt about that. Almost all my generation of university students were taught java. Most of them who became software engineers end up doing Java for the rest of their lives. Java and Object oriented principles (OOP) (also taught in uni) complements each other very well. If you love Java, you love OOP. When you only work with Java and OOP for years, with every passing year, there is something happening in-side you. I call it "Java-OOP fermentation". While fermentation has a positive effect on milk hence yoghurt, it has less desirable outcome on Java and OOP.

Here are some clues to know whether your Java-OOP is fermented.
  1. Your day-today thinking is based on objects and behaviours. Ball is an object and bounce is a behaviour of that object for you. ;)  (which is horribly wrong)
  2. When you see a class full of static methods,  you go "WTF?" and remove statics.
  3. You instantly vomit on your desk and leave the office if you happen to see a new key word.
  4. You believe that the purpose of life is to inject more and more beans as dependencies to surrounding beans.
  5. You usually get in to bar fights while arguing IOC is not DI.
  6. You believe, Mockito is not a mocking framework. Its the meaning of testing.
  7. You feel miserable, when someone refer to one of your stubs as a mock, and you instantly interrupt the conversation and correct them "Well..Its not a mock, its a stub"
  8. You either believe 1) Never test Private methods. Never. or I kill you. or 2) Test every method, or I kill you.
  9. You feel, POJOs are the purest form of code and extracted from earth.
  10. You wonder why "Organic" is not part of - POJO.
  11. You feel, annotations are so synthetic and never mix with your organic POJOS.
  12. You are big on layers.
  13. You love data transfer objects. To transfer data among Layers. Then Mappers. Enrichers...!
  14. Your DTOs lives in their own layers. (more layers)
  15. You usually get in to bar fights while discussing what level of testing you should do, Unit or Integration or functional and who does what.
  16. For you, curly braces defines the scope of everything. You are big on where to put the curly braces and they should ALIGNE !!
  17. For you, a language without curly brace is no language. Period.
  18. Your head spins and feeling bloated if you happen to see a Clojure snippet.
  19. You are proud of the speed of  for loop and you really feel it when it loops, and you think its mechanical sympathy.
  20. You use ORM. Use Hibernate. All the way. Everyday.
  21. You think, ORMs ? NO WAY ! It kills performance. Lets hand code SQL. All the way. Everyday.

The list goes on.. ;)

Non of these are essentially wrong. Actually, all these are fine and should consider doing in moderate. But not every time, every day, every where. There is no silver bullet, and there is no *one absolute right way*.  But once your Java-OOP fermented, you become highly opinionated and end up choosing camps. For an instance, if you can't think of writing unit tests without mocking the world using Mockito ? There is certainly something wrong !


Docker - Part 1


Never heard of docker ?

I found this docker explanation is the quickest to get up-to speed with docker. Also docker official documentation is more complete and up to date.

https://docs.docker.com



So what is docker ?

In short its a better "VM orchestration tool".

But a docker VM is not a VM you used to know. Usually the VM you know is sort of itchy, bloated and makes you vomit. Docker VM (to be more precise, we call it docker container) is like a Pineapple juice in a desert!

Lets cut to the chase.

Docker has two parts. Docker client and Docker server (Docker Host). Docker host can have multiple docker containers. Docker server expose REST Api which the docker client use to manipulate docker containers in the docker server.


Docker Host should run in a Linux box. In MAC, we can use boot2docker VM to run docker host.


Starting up in MAC

boot2docker up   ← How to start docker in MAC.


 asanga@MacBoo-Pro:~$ boot2docker up  
 Waiting for VM and Docker daemon to start...  
 ..........ooo  
 Started.  
 Writing /Users/asanga/.boot2docker/certs/boot2docker-vm/ca.pem  
 Writing /Users/asanga/.boot2docker/certs/boot2docker-vm/cert.pem  
 Writing /Users/asanga/.boot2docker/certs/boot2docker-vm/key.pem  
 To connect the Docker client to the Docker daemon, please set:  
   export DOCKER_TLS_VERIFY=1  
   export DOCKER_HOST=tcp://192.168.59.103:2376  
   export DOCKER_CERT_PATH=/Users/asanga/.boot2docker/certs/boot2docker-vm  


Congratulations. Your docker host is up !! 

But, Now what ? Host is up. But if you want to control the host to do anything useful, you need a remote control to your docker host, which is a docker client.


Remember : docker host is just a server with a REST API. You need a docker client which talks to that API to interact with docker.

Ok lets connect a docker client to the host we just spun up. docker client needs to know about your docker host in-order to connect (Usually in production environments, docker client and docker hosts are in different boxes)

So how does docker client know about docker host ? Your guess is right. Via Environmental Variables.

So here we set those.


export DOCKER_TLS_VERIFY=1  
   export DOCKER_HOST=tcp://192.168.59.103:2376  
   export DOCKER_CERT_PATH=/Users/asanga/.boot2docker/certs/boot2docker-vm 

If you ask me how I knew what those variables and their values, and if I tell you it comes with experience and practise, then you believe me..mmm thats alright ;)

But if you look at the out put of the first command boot2docker up at the end, last 4 lines, Docker actually gives you those values ;)

Extra
boot2docker ip  ← shows docker host ip
boot2docker ssh ← How to connect to docker server in MAC
Or you can use traditional ssh command.  
ssh docker@192.168.59.103
pass: tcuser


See stuff


docker ps ← Show all docker containers
docker images ← Show all docker images
docker logs CONTAINER_NAME  ←Show logs from running container
docker logs 5d3852fa1aef


Start continers


docker run -d IMAGE_NAME command ← Starts container in Deamon mode
docker run -P IMAGE_NAME command ← Starts with all ports exposed to docker host
docker run -d -P --name web nginx    ← Starts nginx deamon with all ports published
docker run -t -i IMAGE_NAME /bin/bash  ← Jump in tp docker container


Port maps are in this format.  HOST:PORT -> CONTAINER:PORT
docker run -p 8080:8080 IMAGE COMMAND


Remove / Stop stuff
docker stop CONTAINER_NAME ← Stops container
docker rmi 195eb90b5349  ← Removes docker image by image id
docker rm 195eb90b5349  ← Removes docker container by container id
docker rm $(docker ps -a -q) ← Remove all docker containers

Monday, May 26, 2014

OMVIF - Oh my version is FASTER !!


Let's imagine you have a legacy system. Lets call it Dragon. Legacy in the sense, no one knows whats going on in Dragon. Let's say the code base is *horrible* and millions of LOCs. So no one understands it.

But..Dragon juussst works fine...!

However, no one is brave enough to fight dragon (extend it? or just to be with it), because the moment you make a change, earth just stops spinning then starts spinning the opposite direction until you roll back your changes. And you have no clue how your change in dragon messed with earth's spin.

Some times you hate dragon, some times you respect it, love it ! wish you could understand it more.

But this is certainly not a good position to be. You know it better than me. So in such situations, there are many interesting things happening around you. One such thing is “OMVIF” or “Oh my version is FASTER”. This happens, when you decided *not* to touch the Dragon but do a part of Dragon in your own language/technology. You take a part, a very simple part, understand it, and re-implement it in your favourite technology. “Oh” you say. My version is FASTER than Dragon.

Now at this point. Long story short. Ask this question from you.

“What did I do *SPECIAL* (optimisations) to make it faster ?”

IF the answer is *NO*,  and you just did it the most obvious way, straight forward implementation, no optimisations !

Unfortunately if thats the case, 90% of the time, you are simply missing something in your implementation, which means your implementation is *FAST* because it is *NOT* what dragon does.

Or in other words, your implementation is *FAST* because it is incomplete.

So Dragon Winks.


Just think, If you didn’t do any *SPECIAL* optimisations, and even after that your version is faster, is that mean, Dragon is just plain dumb ? Can be.. But sadly it is very very very rare !

So next time when you feel “OMVIF” ! Just.. look at the dragon.

Wednesday, May 21, 2014

Are you a Clojure man ? here is a test.

Clojure is a fantastic language to learn and work with. This is a simple test you can do to figure out whether you are made for Clojure. When you first learn Clojure you think..

"Wow Cool !! Very little you have to remember ! So simple.. (+ 1 2 3 ) = 6"

Then after reading some Clojure code or learn more..you think.

"Mmmm.. Actually you have to remember certain forms and little tricky flags to do *cool* stuff. But its worth it..Very little"

Then after some time..one day you find this *new* directive (say ^).. you think

"Wow what the hell is this one ? Let me check the Clojure docs..mm nothing make sense (lot of ^s in different contexts)..let me do a text search in that my killer Clojure book (search for ^)..mmm nothing"

Then.."I should google, but how ? by this =  ^, Clojure or ^ + Clojure ??"

Then at this point, you usually do two things. You say..

1) "Clojure is not my cup of tea, I love you Scala."
or
2) "Wow this is getting more interesting..Lets keep digging,ask in Clojure forums, friends"

If you did 2) then you are a Clojure guy.
If you did 1) I suggest give it a another try..! It's worth to dig more given the mine is full of gold.

Saturday, May 17, 2014

FP- Functional Programming.

I do value FP, respect FP , learn FP and admire FP every day. This is merely how I reason the 'Satus Quo' of current software development landscape.

These days (2000+) people use FP a lot. The reason ? It is easy to develop much correct (less bugs) code with FP. The reason ? FP is backed by pure mathematics. Some math theories related to FP are form 1800s.

On the other hand, OOP with non FP (object oriented programming) is called an old paradigm. The problem with the *old* OOP style is, bugs (less correct codes) and issues related to parallel programming.

FP has a strong mathematical background (Category theory..etc). OOP not. FP's success is based on the math behind the scene, which leads to develop correct code. If you use a FP language without adhiring to FP principals or mathematical concepts (rules), you still can produce inferior code. So, no FP language (Scala, Clojure..) will save you from a writing *BAD* code. What saves you is the math behind FP.

So now. Think of this. How wonderful it will be If we find OOP's mathematical theory. Currently GOF and other design patterns  are the saviour of OOP. But non of those are based on math. I think the reason we couldn't find a mathematical backing for OOP is not OOP's fault. OOP is much closer to how humans think (Object and skeuomorphism), so certainly, if there is any mathematical theory which backs OOP, it should not be from 1800s (as such - Category theory for FP). Such theory should be a complex or may be not yet even devised (Quantum Mathematics ?)

So, Is our decision to switch to FP from OOP for correctness based on our lack of knowledge about modern mathematics ?