Why Are You Not Prepared for an Interview? Wednesday, June 06, 2007

First off, I have to say this post is pointless. If you are reading it, then you obviously don't fall into the category being addressed.

Why don't candidates prepare for stinking job interviews? Why do they lie so badly on their resumes?
I'm trying to add 3 Java/J2EE developers to my team. I would think that if you are going to a Java job interview, you might Google for "java interview questions" and actually read a few pages. From my experience, as a job candidate, you could probably pass most interviews even if you knew absolutely nothing by simply doing that.

So, the simple rules for getting a job:

Don't put crap you don't know on your resume. You will be busted.

Don't put every damn technology you have ever touched on your resume. I will not think you are a "Jack of All Trades", I will more likely think you can't keep a job.

Write your resume so that it is focused on the job you are trying to get. If you are looking for J2EE work, leave off the VB, MS Access, etc... Stuff in the middle is ok, Ruby/PHP/Python. Being well rounded is good. Just don't give me the kitchen sink. I know PHP, Perl, VB, I don't advertise it.

Be very careful about how you put "team projects" on your resume. I don't care what your team did. I want to know what you have done. In an interview, the more I here the "we" word, the less I think you personally have done.

Be able to write code. If I prepared to interview you (I probably didn't, I'm busy) I will simply make you write some code and ask you questions related to your future job, and completely ignore your resume (its full of lies anyway).

Be able to answer questions about everything on your resume. If I did not prepare (more likely), I will be shooting from the hip, and we will focus on your resume. My experience is pretty broad, I'll instantly know if you are feeding me crap.

And here's the gist of things. Even if you don't really know anything, if you spend an hour with Google and the job description, you can gain enough knowledge to pass most interviews. Hell, if you've at least prepared for the interview, you are well ahead of most. Why can't candidates at least lie well?

<willCode4Beer/> posted at 9:26 AM


Process Overkill, A Developer Strikes Back Sunday, February 11, 2007

Recently, all of the developers in my group were hauled off for 'process' training. The managers of the shop want to take us to CMMI level 3. Rather than rant about the process, I'm willing to give it a fair shake. They are looking for a some benefits from the certification that go beyond the actual software.

Then the instructor then covered unit testing. He said that we'd need a test plan (script) document for each of our unit tests. Now, if you use TDD (test driven development) you are thinking, that could be hundreds, if not thousands of documents. Each of these documents is a MS Word doc that is a minimum of about 7 pages.

After recovering from shock (and the first impulse to polish off the resume), my lazy developer instincts kick in. Thinks I, why not embed some extra meta-data into the JUnit tests. Combine this with a custom doclet, and I can be drinking coffee while the documents write themselves.

With the custom doclet and metadata, I can generate an XML file that represents the information that needs to go into the test plan.

There is one last piece to make this all come together. As of version 2003 of MS Word, there is this capability to save MSWord documents as XML (WordML). So, I put some place holder tags in the word file and save it as XML. Next, I open it in a text editor, wrap the document in <xsl:stylesheet> tags, and just run searches for the placeholders written earlier. The placeholders are replaced with XSL tags to generate the desired output.

I put together a proof of concept. Calling the custom doclet from javadoc generates XML files. Running a transformer makes a WordML from the sham XSL document and the XML file. Woohoo.
Finally, a highly motivated intern spots this and gets conned into perfecting the XSL file.

Now to see the manager's face when I say that 700 test plans are ready to be reviewed....

<willCode4Beer/> posted at 3:48 PM


HTML DOM Attributes Thursday, May 11, 2006

Ok, to start with this post is just dumb but, I just wanted to add a snippet.
This reference brought up an issue I had dealt with before when creating DOM nodes in IE.
Trying to set the css class with node.setAttribute("class",className); basically does nothing while working on every other browser.
The Chris' solution is to use a loop to find the attribute node and set the value. I think mine might be a bit less complex:

function setAttribute(node,name,value){
var att = node.getAttributeNode(name);
att.value = value;

Update, an even easier way to set the css class:

function setCssClass(node,className){

was posted by Chris Gillis

<willCode4Beer/> posted at 11:53 AM


Recent excursion into Tagland Sunday, April 02, 2006

Recently I was working on a project dealing with content items that could be rated by a user (think Netflix style ratings). The forward most portion is relatively simple JavaScript that handles the mouseovers and click actions. There is of course the JSP which will render the page. In this instance, we're using a custom tag to render the rating block so a new tag class and appropriate entries in our existing custom TLD are required.

For this, we used a different approach than I am used to.

In the past, we typically used our custom tags for utility purposes- things like finding out if a user is signed in or retrieving string values from IDs, etc. Basically anything that keeps scriptlets out of the JSP and maintains a "pure" markup state. Any presentation was handled in the JSP and never in the tag class.

What we did this time still keeps out scriptlets and maintains the preferred seperation of presentation from the class. Just differently.

First, all of the pages are built from many different JSPs that all do very specific things. With this project, many sections not only look the the same, but act the same as well. For these sections, we opted to use custom tags to render them, passing in just the object and additional parameters (iconsize, in my case) needed to return a fully rendered and ready to use block of code.

To do this we start with the basic custom tag setup in our TLD and write a new class that will handle all the heavy lifting involved in retrieving the rating for a given object for a given user. Now, we also write a second JSP that will be included into the servlet request by the DoStartTag method and this is what will actually perform the render. That is then returned back to the calling JSP and ta-da!

I'm sure this is not novel, and is not new either. But I bring it up here, not just because it's new to me, but because this method of custom tag creation has it's benefits and drawbacks.

First, the benefits. The obvious one being the presentation is still coupled to the tag class, but is separate from it and you can change the display at will without ever having to go back into the class. Simple sounding, yes, but if you have a team of mixed Java devs and front-end devs, this can make for strong symbiosis and promote sanity.

Another benefit is that it makes your error handling a lot easier, if you choose to you can do all of your checks in the class and set attributes you can then check in your JSP rather than sending values in and checking to see if they're null or not before acting on them. This can get unwieldily, but in most cases may be better than having the huge, ungainly, choose/when/otherwise blocks in the JSP.

Reusability! Yes! I am a huge proponent of reusable front-end code. If you have a site with a bunch of yellow boxes, and all the boxes look and behave the same, there's no reason to have every developer build a new box for his or her assigned deliverables in their own way. There should be one way to render the yellow box. This method achieves that, and that's my number one reason for doing it.

The biggest downside comes straight out of the best reason to use this method- reusability. Using our yellow box example, what happens if on one instance of the page the box should be red? Or has a header? Or a border? Or different content? Sure, you add more attributes to the tag to handle these off cases. And you will also get bit in the rear doing this, because every time you add one more level of complexity, you're changing not just the tag def, but the JSP that renders it and maybe even the other pre-existing calling JSPs as well (although, if authored well, probably not).

Another "against" is keeping track of what file does what and where it lives. You don't want your calling JPS living in the same directories as your rendering JSPs, so you're probably going to create a new file structure to keep the tag JSPs. It's also a learning curve to anyone else who comes into your group that might not be familiar with writing custom tags in this manner.

So what about you? Done this before? What do you think?

<R(k)/> posted at 6:04 PM


Parsing currency into a BigDecimal Monday, February 06, 2006

This is only slightly related to a previous post.
To start off, one would think that a DecimalFormat object just might be able to parse a string into a BigDecimal object. hahaha
Well, what about doing an in between double conversion?
Number nbr = fmt.parse(testVal);
BigDecimal bd = new BigDecimal(nbr.doubleValue())
Ahh, but here is where you get into why not to use doubles (or floats) for money.

NumberFormat fmt = new DecimalFormat("$0.00");
String testVal = "$5.35";
Number nbr = fmt.parse(testVal);
BigDecimal bd = new BigDecimal(nbr.doubleValue());
System.out.println("val: "+bd.toString());

This will put "val: 5.3499999999999996447286321199499070644378662109375" on the console. Not quite 5.35 anymore.
Now to be clear, I created the NumberFormat object incorrectly for the context. It should be done as:
Locale loc = Locale.US;
NumberFormat fmt = NumberFormat.getCurrencyInstance(loc);
Anyway, the results are the same.
Now, by creating the BigDecimal using the string constructor, as:
bd = new BigDecimal(nbr.toString());
works. Also, the javadoc for BigDecimal says that the string constructor should be preferred over the double constructor. However, converting by going String->Object->String->Object is just wrong, on so many levels. Besides, there is this java convention that says never depend on the toString() implementation.
Now, one might be tempted into doing something like:
BigDecimal adjustedBD = bd.setScale(2,BigDecimal.ROUND_HALF_UP);
Because, here in the US, the fractional part of a dollar (cents) should always be two digits. Truth is, I'm not sure what it may be in other locales.
I've chosen a different variation on this.
This ensures that the fraction is based on the currency for a given Locale.

So, now my (JUnit test) code looks like:
import java.math.BigDecimal;
import java.text.NumberFormat;
import java.util.Locale;
public void testParseCurrency() throws Exception
Locale loc = Locale.US;
NumberFormat fmt = NumberFormat.getCurrencyInstance(loc);
String testVal = "$5.35";
Number nbr = fmt.parse(testVal);
BigDecimal bd = new BigDecimal(nbr.doubleValue());
BigDecimal adjusted =
assertEquals("5.35", adjusted.toString());
The very astute will notice this test will fail if the currency symbol has been omitted. Fixing this is somewhat less than trivial. You can get the Currency object from the NumberFormat object, and, you can get the currency symbol from that. But, currencies differ as to whether the symbol should go before or after the amount. The joy never ends.

Comments on this issue are appreciated.
Also, a jUnit test for a locale with a very different currency would be great too.

<willCode4Beer/> posted at 11:08 AM


Formatting a BigDecimal Friday, February 03, 2006

Ok, this one is just me being stupid.
It took me slightly longer to figure out how to apply a format to a BigDecimal than it should have.

using java.math.BigDecimal and java.text.DecimalFormat.
BigDecimal bd = getIt();
DecimalFormat frmt = new DecimalFormat("$0.00");
String formatted = frmt.format(bd.doubleValue());

Feel free to make fun of me now.

<willCode4Beer/> posted at 10:58 AM


emulated by a synthetic accessor method Monday, September 19, 2005

I stumbled across this warning while performing my regular cleansing the code base for wanings.
Being the first time I've seen it I felt the need for a bit of research.
This is generated by Eclipse and IBM WSAD when an nested class is trying to reference a private field in its containing class.
For example:

package demo;
public class Foo {
private String myFoo;

private class Bar {
private String myString;

void changeVal() {
myFoo = "bar";

To understand this, you have to remember that the inner class is compiled into a separate file. So, the compiler outputs two files: Foo.class and Foo$Bar.class into the same folder. Since a class cannot see the private member variables of another, the compiler generates an accessor method, and links to it.
Running javap -s -c -private demo.Foo yields:

Compiled from "Foo.java"
public class demo.Foo extends java.lang.Object{
private java.lang.String myFoo;
Signature: Ljava/lang/String;

public demo.Foo();
Signature: ()V
0: aload_0
1: invokespecial #11; //Method java/lang/Object."":()V
4: return

static void access$0(demo.Foo,java.lang.String);
Signature: (Ldemo/Foo;Ljava/lang/String;)V
0: aload_0
1: aload_1
2: putfield #19; //Field myFoo:Ljava/lang/String;
5: return


Here we can see the compiler generated the static method (with package level access) access$0(Foo foo, String s)
This is literally the equivalent of:

static access$0(Foo foo, String s){
foo.myFoo = s;

Disassembling Foo$Bar (javap -s -c -private demo.Foo) shows the method being called.

void changeVal();
Signature: ()V
0: aload_0
1: getfield #17; //Field this$0:Ldemo/Foo;
4: ldc #24; //String bar
6: invokestatic #30; //Method demo/Foo.access$0:(Ldemo/Foo;Ljava/lang/String;)V
9: return

This means the method changeVal() was changed from its original form to:

void changeVal(){

Where this$0 is the instance of Foo that was sent to the constructor of the nested class Foo$Bar.
So, how do you make the original warning go away? Just change the access of the private variable to package level access (no access modifier).

<willCode4Beer/> posted at 12:36 PM