Wheel Workshop

Why Are You Not Prepared for an Interview?

2007-06-06T09:26:00.000-07:00

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?

Process Overkill, A Developer Strikes Back

2007-02-11T15:48:00.000-08:00

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

HTML DOM Attributes

2006-05-11T11:53:00.000-07:00

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);
    if(att){
       att.value = value;
    }else{
       node.setAttribute(name,value);
    }
}

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


function setCssClass(node,className){
   node.setAttribute("class",className,0);
   node.setAttribute("className",className,0);
}

was posted by Chris Gillis

Recent excursion into Tagland

2006-04-02T18:04:00.000-07:00

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?

Parsing currency into a BigDecimal

2006-02-06T11:08:00.000-08:00

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?
ie...
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.
bd.setScale(fmt.getMaximumFractionDigits(),BigDecimal.ROUND_HALF_UP);
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 =
       bd.setScale(
           fmt.getMaximumFractionDigits(),
           BigDecimal.ROUND_HALF_UP);  
   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.

Formatting a BigDecimal

2006-02-03T10:58:00.000-08:00

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.

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

emulated by a synthetic accessor method

2005-09-19T12:36:00.000-07:00

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
Code:
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
Code:
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
Code:
 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(){
   Foo.access$0(this$0,"bar");
}

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

Write once debug everywhere...

2005-07-21T08:31:00.000-07:00

Oh, the joy of Websphere on HPUX.
First, I discover that UTF-8 character encoding is not supported without some plugins to the appserver. How the hell is UTF-8 not supported? weak
Next, I discover that url parameters are not decoded. So, if you have a param &foo=this%20is%20cool and call String foo = request.getParameter("foo"); you get foo.equals("this%20is%20cool"); Seems every other appserver (J2EE or not) will decode url parameters automatically. So, now everything has to be wrapped in URLDecoder.decode(request.getParameter(...
Struts forms, all sets need to be changed as well;
instead of:
public void setFoo(String val){ this.foo=val; }
you need
public void setFoo(String val){ this.foo=URLDecoder.decode(val); }
One might think, IBM would choose to have their app server behave the same on every OS. LOL
This is the kind of crap I'd expect from oracle. HPUX sucks enough on its own.
I really want these methods to not use the deprecated and actually say:
URLDecoder.decode(param,"UTF-8")
But, as mentioned, UTF-8 is not an option. As Cartman would say, "weeak".

Breaking into entry-level Web Development

2005-07-19T21:53:00.000-07:00

Today I conducted an interview for a Web Development position on my team. The candidate should be a rockstar Web dev, knowledgeable and well versed in cross-platform/cross-browser XHTML, CSS 2, JavaScript plus one or more scripting languages and/or JSP.

He had all but the JSP bit on his resume, but when interviewed he met none of those requirements and more. Less? Whatever, he wasn't right for the position.

But why?

Because he didn't have even a fundamental understanding of XHTML/HTML (on his resume) or CSS (also on his resume) and JavaScript seemed to be an amorphous entity to him. Despite building and managing Web sites, these things escaped him. Looking back over his resume, I think I've discovered why- DreamWeaver.

WAIT! Before you flame me about the benefits of DreamWeaver, I am not debating its usefulness nor any other thing about it. The point here is that he didn't write any code- the editor did it for him.

Clearly this is a bad way to get a job. If you have something on your resume, you probably should have more than just an idea of what it actually is- you should KNOW it, you should UNDERSTAND it.

For anyone who is considering getting into Web Development or Web Programming (use your own definition for this) there are some tips I'd like to impart to you.

Start early
The Internet, believe it or not, is a great place to help you learn front end things like HTML and CSS. There are a few dozen odd books you can start reading as well. Reading is only part of it though, knowledge is power but unless you have the ability to use it you "ain't got nothing!" so to speak. While you're reading and learning, you should start building Web pages. Find a free site host like Yahoo or Tripod and BUILD. Explore HTML and XHTML, find out why they're different, challenge yourself by trying to find a good looking site and then make one of your own using only XHTML and CSS2 and running it through the W3C validator.

Craft the sword, then learn how to wield it
When you get to the point where you are comfortable with coding and can write nice, valid code. Volunteer to help someone build a Web site. Family, friend's band, your own startup- whatever. The idea here is to get some practice working in HTML. Learn JavaScript (and please note that it and Java are not the same) and play with XML if you can. Write a new template for your blog, if you have one. If you don't- make one for someone else. Get familiar with browsers other than the one you're using right now. If you have access to a Mac (or if you're a Mac user: a PC) look around at your favorite sites and see if they look any different. Look at your own, what's different? If you find some variance between the way your page looks and works in different browsers or computers, fix it. This single thing (aside from actually learning the languages) is going to be your most valuable asset- the ability to code cross browser/platform.

It may be true that "anyone" can learn HTML, however few people are actually good at it.
Fewer still are what I would consider expert, and these are the hardest to find.

School
Schooling is great, schooling is awesome. If you are in high school, take any classes having to do with the Internet that are available to you. Got a computer lab? Get familiar with it. Learn everything you can about HTTP and then start learning HTML and CSS.

BUT once you get into college, take programming and computer fundamental courses. Maybe even get a CS degree. Why? Because having a good educational background in structured languages will only benefit you, even if you only want to work on the front end.

I know, I know. "What about the Web stuff though? How do you gain any kind of experience in that?" See next paragraph.

Volunteering
While you're taking college courses and burning up some ones money trying to better yourself, give up a few nights a week and find a Web site to volunteer as a developer for. This is much easier than you think. Pick a topic you're interested in, Google it, view the resulting Web pages. Find one you think you can make better and contact the administrator. Tell them you're in school and are looking for a few sites to do some volunteer development on, no charge.

What you're going to gain here are two things: Experience and work history.

Wielding the sword
Education versus experience is a double edged sword. Too much of one and not enough of the other might be ok for some jobs. For those companies that prefer to hire straight out of college, having more education is great, they often don't WANT you to have experience.

The majority of the remaining companies would rather have the experience or experience and some formal education, even if it is only a few classes focused on programming languages or theory.

When I am interviewing, the first thing I look at is wether or not the candidate actually knows the stuff he or she put on their resume. I'll ask simple questions first, because they often have simple answers that require knowledge of the subject. That's the point, actually. If you've told me you know XHTML, then none of the things I aske you should stump you.

What's it worth?
Many new Web devs don't know what they're worth. Sometimes this is a bad thing for more than just the obvious reason of getting underpaid. Thinking you should be paid more than what's reasonable is even worse. There's nothing wrong with wanting a little more. If you're coming into a company at an entry level, especially I should say, especially if you're coming into a company at an entry level, do a little research before your interview to find out what someone in the position you're applying for with your skills and experience gets paid.

50k is honestly not too bad a salary for this kind of work at the entry level. 80k is bordering on unreasonable if you have less than 2 years of consistent work experience (even if most is voluntary) and no or little education. Everything is relative though, in some areas of the country these salaries may seem very high or really low, so hopefully this sheds some light. If you're in a city like Seattle, no way would I take less than 45k unless you really need the work. My friend and colleague here at Wheel Workshop has this advice:

"If you are going into the field for the money, instead of love of the craft, find another career."

Too true. We've seen too many people who just do the minimum because they are not really interested in their jobs. You can spot right away the person who does what they do because they love it. They know what they're talking about, their eyes blaze with new ideas about how to solve problems and they are good at what they do. The people who do it because it's a job usually have nothing to contribute. They come in, work their hours, go home and that's it.

Hopefully I've managed to actually say something here. If I had to sum it up I guess it would come out something like this: Like it, learn it, love it, do it.

On the JSP atomic pattern

2005-06-18T15:45:00.000-07:00

Last week I started a new project to bring a better music and radio experience to my company's customers. One of my tasks this time around was application setup and base configuration using our in-house application framework. This is the first time I have done the initial setup myself as all other projects I've worked on were ready to start building on.

In the last few apps I've helped develop, the Atomic pattern has been the primary JSP pattern used. This pattern uses distinct code components responsible for individual "modules" in the view. These atomic modules can thus be shifted around in the view and still perform their functions because they are not tied to a "place" in the model in order to work.

Before I go any further, let me drop some quick definitions for clarity. These words will be used in this manner for these meanings in the remainder of this post. The author makes no guarantee that anyone else uses these defs, but they are close to real-world and this is free after all.
View - the visible rendering
Module - an atomic portion of the view
JSP module - the code that represents a view module
Module definition - the configuration (usually in XML) of the JSP module
Decorations - Simplified here to mean parameters, attributes and flags that alter minor changes in the view. (Could be text transforms, toggles for list ordinals, etc)

Sharing Pain
Implementing this pattern in the past produced two extreme ends of the spectrum for me. On one end we have too few code components, basically JSP files, responsible for handling too much view. The components became massive switch cases of EL tags (we try to keep scriptlets out of the view-producing JSPs) that tried to cover, say, 3 or more ways a module could look. On the opposite end we took atomic units and made multiple levels of smaller code components responsible for the view. This produced an overwhelming number of files, mostly lower-level includes that rendered things like an artist name or image. The problem stemmed from creating JSPs that were trying to be reusable and extendable when they didn't really need to be either one of those things to meet the business requirements.

Author's note - The second extreme mentioned just now? It got to the point where we actually exceed the number of included files at request time that the JVM could handle.

The happy medium
Before starting to write any code and just after I set the app core up, I decided that this time we should take a new approach. On this project I wanted to not just follow the standards we had in place already, but look at how and why we write JSP code. An Atomic pattern again makes sense due to the modular nature of what we're building. I also chose to change some precepts of other devs on my team that it really is OK to build JSPs that did one thing or two rather than "everything" or breaking them up into tiny fragments. But how to convince them?

The epiphany
I began to write a document outlining the project structure, conventions and why we should seek this happy medium. The hard part was how to find it. Thinking back on the previous projects and their SODs, it occurred to me that they were all missing one very important (and now obvious) thing: There were no guidelines for developing atomic units in JSP! No one had ever mentioned how to make the decision on how to write a JSP module, only what they would look like and where they fit into the app.

Clarity raises its hand
I was excited! I wanted to build a clean app and now I had the vehicle to describe HOW that could be done. A quick yes/no test would help the developer to decide wether the JSP module they are working on should do more than just handle its view.

It went a little something like this:
During development, and even refactoring at a later time, if it naturally fits to reuse one JSP module for another, by all means do so if you can answer yes to these questions:

Does it make sense?
For example, will the data will be represented in the same way excluding any decorations?

Will it happen quickly?
Will the work to build one JSP module or merge two (or more) be faster than the work to build both individually?

Are the view modules able to coexist in a single JSP?
If the views are drastically different, it may cause problems in implementation.

Can the module definitions work with a single JSP?
If modules are defined/configured differently and you need to use different methods or bean properties, you must answer no to this question.

Are view modules you want to merge context independent?
That is, can this JSP module that contains logic for more than one view work on any page without each view having to know which page it is on?

... and no to these:

Is this an attempt to make one module do "everything?"

Will it bloat the base code in the JSP you're starting with?
Nobody likes bloat, but what is it? In this case, bloat is not the code the modules themselves require, it's the handling code that surrounds them, helping to live in a single JSP module. If it takes more code to make your modules "fit" in the same space, you've got bloat. Break them up and use them individually.

Can it survive changes that alters the view of any given module?
Ah, so this one is key. If you are going to make one JSP module do the work of multiple views, keep in mind the requirements for the view modules can change on you. If the view requirements do change, read back through the list of questions and if your answers have changed- it's time to split it out into a new JSP.

Similarly, you can use the opposite approach to determine wether or not a JSP should be split into more than one JSP module.

With guidelines now in place, we'll see how development goes. I am hoping smoothly. In any case, I'll update on this topic as we go along in the process.

Java turning into perl

2005-06-17T10:23:00.000-07:00

I'm growing increasingly fustrated with the removal of some of the best features of Java. Namely type safety.
More and more we are getting these configuration driven frameworks where objects are cast to their correct types willy nilly. The idea behind these systems is "a non developer can reconfigure the application without touching code". This is just dumb. There is no way a non-developer can edit a half-megabyte Spring configuration and know what they are doing. Even developers are having a hard time with it. Next, since its just a bunch of xml, typos can cause huge problems that are not discovered until runtime. And sometimes not till a certain piece of code is executed.

We are creating defacto programming languages with these configurations that only the application developers can understand. We are losing the benefit of a compiler to tell us if the object we are pointing to exists. Even in the code, we are losing type safety as the objects handed from the framework are cast to the correct type.

Worse of all, people keep saying "its more object oriented". This is just incorrect. It does make the code more abstract but, this is really a farse since objects must be cast before they can be used. About the only thing it is really good for is enforcing developers to code to interfaces instead of implementation classes.

I got started on this rant in the process of migrating a rather large code base from Hibernate 2 to version 3. I must clarify that I was using a patched version of Hibernate 2. This patched allowed one to call count on a criteria object. So my pagination code basically called:
List results = criteria.list(); // get a page of results
long totalCount = criteria.count(); // get the toatl count
The criteria had criterion added to it to restrict the results for a page of data.
The Hibernate developers decided that its more convienent for me to get the count with:
Integer count = (Integer)criteria.setProjection(Projections.rowCount()).uniqueResult();
int total = count.intValue();
So now instead of the safety of a method that returned a long. We have a method that returns an Object. We *know* the Object is an Integer because we passed Projections.rowCount() to the object that we passed to the criteria, and we cast it. So instead of the criteria interface getting bloated, every consumer of the library gets to have their code bloated. If the Hibernate code ever changes, you won't know until you run the code because of the cast. Suppose one fine day they decide to return a Long instead of an Integer. You'll get no compile error because the interface returns an Object. Instead of using the compiler to find the code that needs to change, you'll have to grep for it (unless you use windows, then your life will suck).

Any developer who has spent time using the Spring framework can tell you how much time they've wasted because they have to start the application to find errors in the configuration.

How about we start writing configuration classes. Actual compilable code to configure the application. Return actual objects instead of strings. Return actual types and not just Object. Drop construction via reflection. Non developers are not going to be able to reliably configure your application anyway. Create a configuration package. All of the config classes can go in there. If anything is wrong, you get a compile error. No more spending an hour debugging just to find a typo in hte config (the config), hehe.

Finally, a word regarding setter injection so loved by Spring aficionados. If the object passed in a setter to an object is required to make it function, then get rid of the setter method and pass it to the constructor. How else can anyone know that a required thing is missing?

Final word, I am not finished with this subject.

Problems with Hibernate Expression.not( criterion )

2005-06-02T11:14:00.000-07:00

So, I'm building my hibernate queries dynamically with Criteria (that I love so much).
Then I come accross a problem while trying to do a not:
Criteria criteria = session.createCriteria(MyValueObj.class); criteria.add(Expression.isNotNull("dateCreated")); criteria.add(Expression.not(Expression.eq("deleteCode", "D")));
This yields no results, suck.
It looks like it generating some bad SQL.

I decide to try refactoring the statements into:
Criteria criteria = session.createCriteria(MyValueObj.class); criteria.add( Expression.not( Expression.and( Expression.isNull("dateCreated"), Expression.eq("deleteCode", "D"))));
And all is well and happy in the world. Perhaps there is some kind of bug in the implementation of the not expression. Investigation will have to wait until another time.
When all else fails, find another way to skin the cat.

thursday morning configuration woes

2005-05-19T07:37:00.001-07:00

XML is like violence. If it doesn't solve the problem, use more.

Mondays

2005-05-16T10:44:00.000-07:00

A new exception to start the day
java.sql.SQLException: Fail to convert to internal representation

This morning after a CVS update my app starts giving this exception trying to get some data.
FYI, my app is using Spring->Hibernate->Oracle
A google search (always the first thing with strange errors) shows a bunch of posts with replies telling people to use prepared statements instead of string hoodoo-voodoo. Well, I'm using hibernate, so this doesn't apply. suck.
A quick check shows the hibernate config and the value object still match-up (woohoo, my co-workers aren't conspiring against me). Well, the next thing is to actually *read* the stack trace ;)
So, I see some interesting lines:
at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:226) at oracle.jdbc.driver.CharCommonAccessor.getBigDecimal(CharCommonAccessor.java:324) at oracle.jdbc.driver.CharCommonAccessor.getBoolean(CharCommonAccessor.java:157) at oracle.jdbc.driver.OracleResultSetImpl.getBoolean(OracleResultSetImpl.java:394) at oracle.jdbc.driver.OracleResultSet.getBoolean(OracleResultSet.java:1570) at com.ibm.ws.rsadapter.jdbc.WSJdbcResultSet.getBoolean(WSJdbcResultSet.java:686) at net.sf.hibernate.type.BooleanType.get(BooleanType.java:19)
Well, I've only got a few fields that are booleans, this should be easy to trace down. The exception also points out that Oracle is expecting the booleans to really be BigDecimals. So, time to look at the database.
Aha, they are consipring against me (jk), the columns have misteriously been changed to varchars. Gently abuse the dba, and all is well in the world again.

Now if I could only stop them from changing my checked exceptions to unchecked ones....

First!

2005-05-12T21:04:00.000-07:00

First post!