(Not so) Stupid interview question

August 7, 2006

Once I’ve read about funny question for interview. “If you have to become a core Java class, which one would you choose? And why?”. You are on job interview. It is not really good idea to ask interviewer about his last visit to psychologist. Moreover the question is not as silly as it seems to be from first sight. As you realise the question is not about java but merely behavioral. So, how you react on that and what is correct approach? It depends. It depends on company and vacant job position you are trying to get. There are several thoughts about it and great many bad answers. You should not tell:”I want to be System class! I AM System class!!! I always felt likesomone who can rule them all and only I may have access to all goods and low level resources!”.

Well, get serious. If you are trying to get any Senior or team lead or architect position espetialy in Banking/Financial sector the only correct answer is “I don’t know because I never thought about it”. You do not have any specific preferences in becoming a Java class and any *.class answer will be -not_based_on_your_experience, -not_well_thougt, -not_only_right_answer. And you definitely will not be able to prove yourself other that “why not?”. So you gave a very random answer without thinking and not having any explanation. Why? Because you thought it was silly question. IN YOUR OPINION. At that time the interviewer will draw a minus sign in checklist in the row “Tend to give quick answers when the subject is not clear. “. You are trying to explain your choice another minus will appear with comment “may insist on poor decisions just because he made them once”.

It was my IMHO. What do YOU think about it?

Job interview question 1

August 7, 2006

Q: Write equation function for class

public class Customer {
private int id;
private String name;
private float balance;
}

A1: What for? It is already implemented in Object class.
A2: Why me? My favourite IDE generates such staff for me.
A3: You think for a while and write classical equation code with null-checking, casting and equation of values of all fields.
A4: Easy job. Just put inside

return EqualsBuilder.reflectionEquals(this, other);

A5: Look mait! It seems to be a Business object! And field “id” looks like primary key for me! So it should be something like:

public boolean equals(Object other) {
if(this.id==null)
return false;
if (other==null)
return false;
if( !(other.getClass().equals(this.getClass())))
return false;
return id.equals((Customer)other.id);
}

Java: most wanted

July 27, 2006

javapic  -I know Java.
-Wonderful! It is exactly what we need! When you can start?

Funny job interview? It was like that in nineties but not anymore. Now Java is so broad that two experienced Java programmers that develop similar(from user’s point of view) applications may not know any of tools, frameworks, IDEs, AppServers that other is using. Sometimes bunch of technologies is chosen based on company’s budget, sometimes it depends on vendors support, sometimes it just because of historical reasons.
Whatever was the cause it is the fact that Java-flavour in Australia is significantly different to European. So my “Europe-tailored” skill set become slightly “out of fashion” and need some altering according to local preferences. That is why I decided to start new project that exploits all modern Australian java technologies, tools, etc. As an architect I have to sacrifice some good practices and even common sense as it would never allow me … let say use 1.4 -based things in the middle of 2006.
What am I building? It is n-tiered webapp that allows me to manage simple schedule and TODO list and receive voice remainders over the phone. I will add whatever I want to it as soon as I feel like it.
Let the show begin! I introduce java buzz-words in Australian IT market.
1. Oracle. Nobody cares about postgres, mysql, derby and other open-sourced rdbms.
2. Hibernate. No surprises here.
3. Spring. It is extremely popular all around the world.
4. Struts. Still alive. Bit outdated technology that is demanded 5 times more than Spring MVC or JSF.
5. AJAX. It is rarely used but people like this word. So do I.
6. SOA! WebServices, SOAP, BPEL and all other SOA-related terms.
7. WebSphere + WSAD(RAD). WebSphere beats WebLogic, JBoss, Tomcat, GlassFish altogether.
The first release will comprise whatever is ready scheduled to 1 September 2006. Will keep you informed how the project goes. By the way. The name is Ascon.

Java trivia

July 18, 2006

JavaSketchWe all know core java very well. But there is always something to be curious about. Or be surprised. Take a look

  Object objectA = ObjectB.new ObjectC();

Something is wrong with that. Tell me what.

XSLT + JSON-RPC as alternative to JAXB

July 17, 2006

Lately I use JSON-RPC extensively and not only for RPC communication. JSON-RPC library comes with few very useful helpers that made worth using it as standalone JSON-> Java conversion tool for really complex objects.
In one of projects I had to convert proprietary XML-formatted data to Java POJOs with number of calculations/transformation rules that made using of standard JAXB tools seamless. Each XML file comprised more than 1000 elements and resulting domain model had 20 classes organized in a tree. After some attempts to write annotation-based transformation engine(it actually worked but java code was poisoned with 2/3 of annotations. Moreover transformation rules were not changeable without recompilation) a decided to use XSLT + JSON-RPC chain.
First of all I wrote XSL templates for performing all transformation rules. Have to admit that it was mach easier to define rules with XPath/XQuery than in plain java(ok, there is common-collections + bean-utiles but it is nothing comparing to XSLT). As result of XSLT I had text file with my objects tree defined in JSON.
Second step was converting JSON to Java. JSON-RPC library is just brilliant for that. You need to get Bridge class, define mapping hints to Java classes, get serializer and you good to go.

JSONRPCBridge bridge = JSONRPCBridge.getGlobalBridge();
bridge.registerClass("com.maersk.tpd.domain.Route", com.maersk.tpd.domain.Route.class);
bridge.registerClass("com.maersk.tpd.domain.RouteLeg", com.maersk.tpd.domain.RouteLeg.class);
bridge.registerClass("com.maersk.tpd.domain.RoutePoint", com.maersk.tpd.domain.RoutePoint.class);
bridge.registerClass("com.maersk.tpd.domain.RoutePointRole", com.maersk.tpd.domain.RoutePointRole.class);
JSONSerializer serialiser = bridge.getSerializer();


Nice part that JSONRPCBridge has number of predefined serializers for various Java classes like Date, Float, Boolean, etc. However sometimes you need to add you own serialisers for custom types. The JSON-RPC guys definitely anticipated it so you can register you own serialiser on bridge with registerSerializer(Serializer s) method. Fair enough unless you want to redefine serialiser that handles already mapped class. Let say you execute myBridge.registerSerializer(new MyDateSerialiser()). What you get is “different serializer already registered” exception. No comments here. It is probably has some explanation.. So if you steel want to do it (I did) you have to add one more function to JSONSerialiser:

public void registerOrReplaceSerializer(Serializer s) throws Exception {
  Class classes[] = s.getSerializableClasses();
  synchronized (serializerSet) {
    if(!serializerSet.contains(s)) {
      if(isDebug())
        log.info("registered serializer " + s.getClass().getName());
      for(int i=0; i < classes.length; i++) {
        serializableMap.put(classes[i], s);
      }
      s.setOwner(this);
      serializerSet.add(s);
      serializerList.add(0, s);
    }
  }
}


So now you might add your own serialisers and see the whole beast working:

serialiser.registerOrReplaceSerializer(new GcssDataSerialiser());
serialiser.registerOrReplaceSerializer(new GcssBooleanSerialiser());
Object obj = serialiser.fromJSON(jsonString);


Need to mention that both transformations XML-JSON and JSON->Java work extremely fast. So when the time to optimization came the transformation part was out of questions. Hibernate batches were most time consuming thing. But it is another story for next post.

Concrete objects with JSON-RPC

July 16, 2006

jsonJSON-RPC is one of the most used transport technologies in modern AJAX world. It has many advantages especialy comparing to fatty XHR. However it has .. not drawbacks but rather space for improvement. As you remember the JSON Object is a classic TO and typeless by nature.
Good enough for most cases but sometimes I want to transfer from server to client full-fledged objects that carry internal functionality. Say client-side Customer must have toString() function. So we need a way how to transform typeless JSON transfer objects to class of our domain model defined in JS. The solution is simple. We hint our Java class Customer with name of JS class the same way as we hint JS classes with name of Java class representation (see JSON-RPC manual for more details). On client side we need to cast JSON object to our model class with name taken from jsClass property. To cast? In JS? Yes indeed. myJsonObject.toString = Customer.prototype.toString will do the job if we have few functions. Let say we may define function Customer.decorate(obj) on Customer that will extend given object with all functionality of Customer. Otherwise we may use Prototype library’s metod Object.extend(myJsonObj, Customer) which will extend myJsonObj with all methods that Customer’s methods. So putting all together we have bidiractional Java-JS transfer of typed objects.