Friday, September 28, 2012

Orion skyquest finder scope alignment

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 to be aligned to be in parallel to the  main mirror in the scope.  Thos two black screws in the image are used to move the scope left and right and towards and away from the scope.  So I took the scope out in the day light and pointed it  towards the street and put the 25mm eyepiece in the main scope. then I saw the top of a house in the finder scope and then in eyepiece. I kept tweaking the screws till I can see the exact object in finder scope cross hair intersection in the main eyepiece.  I repeated the same process with 10mm eyepiece.

And boy in the night I could locate the saturn or moon in finder scope cross hair and then it was dead centre in the main scope.

Next task is to see Jupiter and mars.

Got Orion skyquest Xt6 telescope

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).


Wednesday, September 26, 2012

Javascript developer interview and design patterns

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.


Fizz buzz and interviews of any engineers

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 without syntax error in 1-2 min.  It seems people are in software industry just for the heck of 8-5 jobs.

Monday, September 24, 2012

Java Annotations/AOP and being lazy

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 the developer. A junior developer now has to only annotate new methods with read/write and  if he is not curious he wouldnt even know what these are for.

2) I was given a requirement to track performance of methods of a particular class in Graphite. The problem was that in future developers can add more methods and add more code and what if they move code around and that can lead to wrong numbers being reported. So I just created a PerfInterceptor and added @PerfIntercepted annotation to every method that we wanted to track. Again being lazy helped me to hide the complexity.

3) I added sharding to our storage layer and again I wanted to hide the complexity of sharding to an average developer so I created a MetadataShardingInterceptor and it automatically handles selection of shard. The sql is assumed to written like
select * from ${SCHEMA_NAME}.files_${SHARD_NUMBER}.

The assumption is that every method would contain a customer argument and the AOP layer derives the shard metadata and does replacement transparent to junior developer.

So as you start to think in direction of making life easy for your team or be lazy to avoid DRY violation you tend to use more of AOP and annotation.

Tracking missing cobertura code coverage

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
     ui
          src
          src_test

The ui module depends on server module classes for testcase execution. I had a common_module.xml ant build file that is imported by both server  and ui module. The way I was calculating coverage is to run first instrument task and then run test and put build/instrumented_classes before the classpath.

Well it turns out the server classes were showing coverage for only code called by server/src_test and not by ui/src_test. The reason is that when I was running ui tests I was using only build/instrumented_classes whereas I also need to include ../server/build/instrumented_classes. 

Just adding that gave a solid 10% jump in code coverage :).

Thursday, September 20, 2012

Mysql release column name

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 :).

Saturday, September 1, 2012

Java code coverage using cobertura

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.sourceforge.net/sample/



Here are some more details on the steps:

    <target name="instrument" description="Run Tests">
        <delete file="${basedir}/cobertura.ser" />
        <delete dir="${basedir}/build/instrumented-classes" />
        <cobertura-instrument todir="${basedir}/build/instrumented-classes">
            <ignore regex="org.apache.log4j.*" />
            <fileset dir="${basedir}/build/classes">
                <include name="**/*.class" />
                <exclude name="**/*Test.class" />
            </fileset>
        </cobertura-instrument>
    </target>


        <junit tempdir="${basedir}/build" printsummary="on"
               fork="yes"
               forkmode="perBatch"
               haltonfailure="true"
               failureproperty="tests.failed"
               showoutput="false">
            <jvmarg value="-Djava.awt.headless=true"/>
              <jvmarg value="-Djava.io.tmpdir=${basedir}/build/jenkinstest"/>
            <jvmarg value="-Dnet.sourceforge.cobertura.datafile=${basedir}/cobertura.ser" />           
            <classpath location="build/instrumented-classes" />
            <classpath refid="${testClasspathRefId}"/>
            <classpath refid="cobertura.classpath" />
            <formatter type="plain" usefile="false"/>
            <batchtest todir="${basedir}/${testReportsDir}">
                <fileset dir="${basedir}/${build}/classes">
                    <include name="**/*${testClassPattern}.*"/>
                    <exclude name="**/*$*.*"/>
                </fileset>
                <formatter type="xml"/>           
            </batchtest>
        </junit>


    <target name="coverage">
        <delete file="build/cobertura.ser" quiet="true" />
        <delete dir="build/coverage"  quiet="true"/>

        <cobertura-merge datafile= "build/cobertura.ser">
            <fileset dir="${basedir}/">
              <include name="**/cobertura.ser"/>
            </fileset>
        </cobertura-merge>   
        <cobertura-report format="html" destdir="build/coverage" datafile= "build/cobertura.ser">
            <fileset dir="${basedir}" includes="**/*.java"/>
        </cobertura-report>   
        <cobertura-report format="xml" destdir="build/coverage" datafile= "build/cobertura.ser">
            <fileset dir="${basedir}" includes="**/*.java"/>
        </cobertura-report>
        <cobertura-check haltonfailure="false" />
    </target>