Programming fun at startup

I got my orion skyquest XT6 telescope from craigslist and on first good day of viewing I was able to see moon craters and saturn but  even though I would see the moon in cross hair intersection of finder scope I will have to literally spend 1-2 mins trying to bring it in the main eyepiece. And man I was frustrated as moon is still big but saturn took me almost 5 mins to bring it in eyepiece. Something was not right and I remembered the owner had said to collimate the telescope. So I used this youtube video http://www.youtube.com/watch?v=YAVGcGEBmCE   to collimate the telescope next day and again in the night same frustration something wasnt right. So I remembered that in order to  bring it home I had to disassemble the finder scope, tube and base in order to transfer it safely in my car and when putting it back I had tightened some screws on the finder scope and voila that was it.  I read the manual it seems that as shown in the image the finder scope mirror need...

My friend recently brought Orion skyquest Xt8 and I saw moon with it and boy I was hooked on to it. So I had to get a one but I wasnt sure if I would really use it or not so I saw got a used one for $75 from craigslist.  The next few days were cloudy but then on third day finally I was able to see Saturn and I was all thrilled. The moon was awesome. The only problem is that its hard to get the object into view in the main eyepiece even though finder shows it. I have finally fixed the issue, I will write a post about the issue (debugging the issue was fun).

I have been taking interviews of Javascript developers lately and one of the question I ask is "Can you tell me what design patterns you have used in Javascript besides MVC?". People with 6-10 year exp  have gone blank on this question. wth  any decent developer would have seen: 1) Composite pattern if you had build a custom widget. 2) Observer/Observable pattern to do event handling. 3) Proxy pattern if you had mocked server apis 4) Delegate pattern. 5) Factory pattern. 6) Singleton pattern.

Lately I have been doing lots of interviews from Java developer to UI/JavaScript developers to Build/Release engineer and my forte is Java but unfortunately I have to be pulled in other interviews so how do I test a Javascript developer when I myself cant write decent Javascript (I can google and get things done but I consider myself a newbie in Javascript). So I resorted to basics and started asking fizzbuzz tests like 1) given an array find max out of an array. People with 10 years of exp have flunked on it. One guy wrote code like for(var i=0;i++;i<arr.length-1) {   if(arr[i]>max } one guy told me to sort the array and find it out of it. 2) given an array find second max out of an array. 3)sort an array 4) reverse an array 5) binary search in a sorted array I have seen experienced people taking anywhere from 5-15 mins just to find max out of an array. I mean even if you wake me up in the night at 3:00 AM and ask me to find max of an array I can do it w...

I have found that if you try to be lazy then you would use AOP and annotations more. I try to be lazy and my blood boil when DRY being violated in the code. My goal is to how to make code simple yet powerful and try to hide complexity from an average developer and if the complexity cant be avoided then keep it in a single layer as much as possible. AOP allows you to hide the compexity in a single layer transparent to an average junior developer.  For e.g. 1)  I was given a requirement to allow X no of Read and Y no of Write request per node as Berkely db couldnt handle >X+Y requests.  So AOP helped me sort it out. I created an interceptor MetadataThrottlingInterceptor and created two annotations @MetadataWriter and @MetadataReader.  So I just annotated the methods in the storage layer with these annoatations and used a threadpool in the Interceptor class to limit the read/write request.  This allowed me to hide the complexity in a layer and transparent to ...

I had recently plugged in code coverage tool cobertura in our startup and got X% of coverage and was happy because this is the first time we had testcases and code coverage working in jenkins.  I was happy and we were planning to steadily increase this code coverage but then one of the developer complained that some of the jersey tests were showing proper coverage but the server classes calling it were not showing any coverage at all.  When I had initially plugged in the coverage tool I had seen server classes showing coverage and those classes are still  showing coverage.  I thought this has to do with the grizzly rest container we were using for Jersey test.  Then while tracing missing code coverage like a detective I had an Aha moment.  Our code structure is something like module      server           src           src_test   ...

Ran into an issue where mysql would throw some weird exception saying there is a syntax error in my insert query. After 20 mins of investigation I found that I had named a column in the table as 'release' and its a reserved keyword :).

Code coverage is important as it gives developers confidence in the code that they are checking in. And for a startup automated test and measuring code coverage is equally important to be able to Ship early and be nimble.  I recently automated unit testing in jenkins and wanted to measure how much code coverage we have. So I integrated cobertura in the build framework. Cobertura is a build time instrumentation plugin so the steps are: 1) compile the code 2) Instrument the classes to generate instrumented classes with cobertura hooks. 3) modify junit class path to put instrumented classes before real classes 4) add a system property in junit ant task, so that cobertura knows where to write its statistics. 5) generate a coverage report in html to be used by developers 6) generate a coverage report in xml so that it can be published to sonar so we can do trends on code coverage release after release. Here is how a typical code coverage report looks like http://cobertura.sourc...