amateur at best...

I have a confession. (re: #tigerbloodtourney)

2011-03-19T00:18:00.000-07:00

I cast false ballots in Fired Up! Missouri's Tiger Blood Tournament. In fact, it is likely that I decided the race between Speaker Steve Tilley (NBPP - Perry/Ste.Genevieve) and Jolie Justus (D - Freedom). It was a decision that happened by fits and starts, but it was my decision. I am not a man to step back from my decisions. As such, I submit to you the facts of the situation as they presented themselves. Mistakes were made. Yet, I know without a doubt that, ultimately, I did what was right. I took the action that no one else would and set the course of destiny down its true and proper path.

On Thursday evening, I checked in on the immensely enjoyable Tiger Blood Tournament. At that time, there was nothing particularly stunning happening in the voting, although there was a lot of jocularity on twitter surrounding the event. I noticed that most of my picks were doing pretty well, watched a couple of the YouTube videos and headed to bed. However, the following morning I was treated to this shocking tweet from Senator Jolie Justus.

Now, any fool can see that either Tilley had members of his New Black Panther Party up all night clicking on tiny radio buttons while plotting to give St. Louis control of the Missouri Highway Patrol and install NBPP members to the controlling board giving Tilley his own private army just in time to wrestle control of the state from Lt. Gov. Tweets-a-lot (R - Where the hell did we get this guy?)...OR somebody was running a votebot. As the votes for Tilley continued to soar, I contemplated the situation. How could this have happened? As her previous contests had shown, Jolie Justus has to be the most universally liked politician that has ever held elected office. Not long ago, I would have sworn that politicians had developed a forcefield to keep all that was good and honest out of the halls of every Capitol in the country. Then Jolie Justus came along. For goodness' sake, just look at her name. Now, say it out loud it sounds even better. Clearly this woman came directly from the planet Krypton to fight for truth, justice and the Missouri way.

Something had to be done...

Now, I'm no Jolie Justus. Which is good, because that would be weird. However, I've heard a cliché or two in my day and it just so happens that "fight fire with fire" is one of them. I really don't understand that, because I thought you were supposed to fight fire with water. Water beats fire, fire beats earth, earth beats water. Am I right?? Anyway, I happen to have written a little program or two in my day. So, I set out to even the score. FOR GREAT JUSTUS!

While the robot minions of Team Tilley stuffed the ballot boxes with thousands of fraudulent votes, I toiled away through my lunch hour. I gave up sushi! Damn you, Steve Tilley. Despite already being behind by what looked like an unrecoverable margin, I dedicated myself to leveling the playing field for the sake of justice (or at least Justus, but whatever). In less than the amount of time it would have taken for me to consume a delicious caterpillar roll at Sushi Sen, I had created a monster. Well, actually a robot...or...an Android.

That's right. I defeated Team Tilley's band of robot minions with a single, solitary cellphone.

It comes down to this: I had to be home in time for dinner. I simply couldn't sit around the office until 5 waiting for voting to finish so that I could be sure that the NBPP hadn't swarmed the polls in a last ditch effort to keep the lead. So, my votebot went mobile. While I drove home, my phone executed a program that I am lovingly calling "Absentee Ballot". It gave back to Jolie Justus the comfortable lead that she so rightly deserved.

I am proud of my little Samsung Captivate. She did her part to restore Justus to the Tiger Blood Tournament. Now that the world has been set right and Missouri snatched from Steve Tilley's clutches, I am retiring my little program. But let this be a warning to those who would try to take the reins of Democracy from the hands of The People...wherever voter fraud rears it's ugly head, Absentee Ballot will be there and so will the Justus League.

A Reply from and an Open Response to Dan Rastatter

2009-12-18T21:51:00.000-08:00

While I have not yet received a response from Dr. Alvin Goldstein, I did hear from Dan Rastatter this evening. I was disappointed in the response on a variety of levels. Not only did he give no indication that he intended to change the content of his abstract with regards to the Jerry Parker case, but he also accused me of desiring revenge, being callous and complacent with regards to police corruption. Here is his replay in its entirety.

Dear Mr. Kimberlin,

I read your email in regards to my summary of the Jerry L. Parker molestation case. You raise a few claims that conceivably chip away at Parker's defense. However, the case against Parker is so weak that the points you make would have little effect in changing an evaluation of his case based on the information presented in Dr. Goldstein's account. Parker may now be attending parole hearings, but innocent persons often feel coerced into doing so.

Because of the girls' youth, it is questionable whether they were old enough to give credible testimony. Individuals that young are quite susceptible to believing and parroting opinions of adults rather than what they actually witnessed. Secondly, the girls all failed to identify Parker in the first photo lineup they saw. The case against Parker should have died there. Even if one ignores the girls' youth and their failure to initially identify Parker, there are many aspects to the case that are not very credible.

Your email suggests you allow emotion to enter into your evaluation of the case. The severity or emotional impact of a crime does not logically affect what the evidence proves. Apparently you are callously willing to subject a possibly innocent person to decades of imprisonment because it is "poor taste" to seriously question his accusers.

Judging from Dr. Goldstein's account, I am not at all sure the girls were molested, even if not by Parker. It would be easy to believe that the girls got their stories from an actual event, but the details of their stories suggest that the molestation could not have happened in the way they describe. If the girls were molested, they don't seem particularly upset about it, as they appear willing to cavalierly add to their account.

In your letter to Dr. Goldstein you dispute Parker's claims and write "I tend to desire a higher level of proof for claims of any kind in order to be swayed." However, the burden of proof is on you or the prosecution to prove Parker guilty, not on him to prove his innocence. I am not aware of any clear evidence that a crime was committed by anyone.

I am sorry that Parker murdered members of your family, if the evidence does indeed prove that. Nevertheless, the fact that Parker may have murdered people does not mean he molested the girls. It is unfortunate that Parker was less than polite to members of your family during his most recently trial, but few individuals take kindly to others who attempt to put them in jail.

In reading Goldstein's account, I wondered why police seemed to be framing Parker. The evidence you relate suggests that police framed him because of his past murder convictions. Police initially told the girls that they did not believe their stories; then they suddenly decided to focus on Parker as a suspect and kept pursuing him even after the girls failed to identify him.

I realize you want revenge on Parker, which he may deserve, but I would only seek such revenge in regard to provable crimes he committed. If courts refuse to incarcerate him for these crimes, you just have to live with that. If you support police corruption in your desire for revenge, you are doing evil and are hurting people other than Parker. Keep in mind that Parker's incarceration is never going to not provide you justice. It is never going to bring back family members that were killed.

Sincerely,

Dan Rastatter

I felt it necessary to address his points and criticisms. My response was as follows:

Mr. Rastatter,

I must admit that I am disappointed by your interpretation of my correspondence. I would like to clarify the fact that I do not in any way desire revenge upon Jerry Parker. While I would have loved to have known my grandmother and uncle, and while there is no doubt that he committed their murders, it would be completely antithetical to my own personal ethics to wish harm or hardship upon him. Having never known my slain relatives, my sense of loss with regards to them is of more a theoretical nature than a personal or emotional one. Personally, I have nothing to gain by convincing you or Dr. Goldstein of Mr. Parker's guilt. Furthermore, I have made no attempt to convince anyone of his guilt with regards to the molestation of the three young girls. Quite the contrary, I explicitly stated that I would "not attempt to further argue Parker's guilt in this case".

You should be aware that Dr. Goldstein made his living as an expert witness. He was paid to testify against the credibility of eyewitness testimony. This in and of itself is reason to read his account with a skeptical eye. Furthermore, the evidence presented on the page in question was provided by Mr. Parker. Dr. Goldstein readily admits that he had nothing to do with the case. His interest in the case is to make use of it as an example of why eyewitness testimony is imperfect. My assertion is simply that the facts that are presented on his page are questionable and incomplete. If Dr. Goldstein feels the need to relay the story of Mr. Parker, it should be the entire story. Putting forth only those pieces of information which support the idea that one is trying to espouse while ignoring contrary and/or harmful information is a classic example of confirmation bias. It is foolish to take the word and evidence of the convicted as truth and parrot it as fact without investigation. The information surrounding the handling of the investigation comes from Mr. Parker. Dr. Goldstein did not speak with the investigators. He did not speak with the prosecutors. He did not speak with the defense attorney, the judge, the witnesses or even the court clerk. He spoke with no one with any relationship to the case whatsoever, with the exception of Mr. Parker.

There may well have been issues with the handling of the investigation. There may have been serious flaws. That does not change the fact that Dr. Goldstein's account of it is one sided and incomplete. Anyone who reads the entirety of Dr. Goldstein's article can plainly see the bias that is displayed. The article is peppered with unnecessary quotations used to convey sarcasm and skepticism. They are so prevalent that it detracts from the article. Dr. Goldstein's desire to persuade the reader of the problems relating to eyewitness testimony is so strong that it colors the arguments and the text as a whole.

As for my being 'willing to subject a possibly innocent person to decades of imprisonment because it is "poor taste" to seriously question his accusers', I would suggest that you read my email to Dr. Goldstein again. I have absolutely no desire to see any innocent person imprisoned. My comment regarding Dr. Goldstein's "poor taste" was directed exclusively to his use of quotation marks around the words victim and crime. Of the 23 jurists who heard the testimony and evidence in the case, 22 felt that he was guilty beyond a reasonable doubt. Neither you nor Dr. Goldstein were present for that testimony and I find it rather arrogant on the part of Dr. Goldstein to claim superiority of reasoning over all 22 of those men and women. The simple facts of this matter are that Dr. Goldstein obtained his information from Mr. Parker and based his arguments on that information. You obtained your information from Dr. Goldstein's account. As such, you are working from a set of half-truths provided by a convicted murderer and pedophile and filtered by a man with a career interest in the argument that he is expressing. You claim below that the girls "don't seem upset" about their victimization and that they "cavalierly add to their account". I can tell you from having seen these young girls give testimony that they were upset beyond what I can describe. The trial and testimony was clearly very difficult for them. If you have children, as I do, you should know that it is difficult for a 10 and 11 year old to tell any story the same way twice...much less while under interrogation from a defense attorney. So, the fact that there were differences and/or discrepancies in their testimony is not surprising. I will agree that this makes their testimony less reliable. However, your statement that they do not seem upset is unfounded and ill conceived.

You told me in your reply that "the burden of proof is on you or the prosecution to prove Parker guilty, not on him to prove his innocence". I agree completely that the burden of proof was on the prosecution to prove his guilt. However, it is certainly not on me. I have nothing to do with Mr. Parker, his case or his guilt or innocence. A jury of his peers concluded that the prosecution met that burden of proof beyond a reasonable doubt. Therefore, he was convicted and jailed. I do not ask you or anyone else to believe one way or the other with regards to Mr. Parker's guilt in this matter. I only asked that the entire story be told accurately or that no story be told at all. I cannot imagine that anyone would find this to be an unreasonable request. Simply regurgitating information supplied by the accused is not only irresponsible, but also disrespectful to the victims of Mr. Parker's crimes and their families.

I am by no means a "callous" man. I believe that we all make mistakes in our lives and that we all should be given the opportunity to atone for those mistakes. Mr. Parker has at no point in his incarceration made any attempt to do so. As for your insinuated skepticism of Mr. Parker's responsibility for the 1970 murders of my grandmother and uncle (as read from "if the evidence does indeed prove that" and "may have murdered"), I would direct you to the Missouri Supreme Court verdict on the matter. It clearly elicits a variety of physical evidence, testimony and admissions on the part of Mr. Parker which led to his conviction. I am confident that no one, even Dr. Goldstein, would question the merits of that case. For your reference, that verdict can be found here:

http://mo.findacase.com/research/wfrmDocViewer.aspx/xq/fac.%5CMO%5CMO2%5C1974%5C19740408_0017.MO.htm/qx

At the risk of repeating myself, I would like to directly address the last paragraph of your email. I wish for no revenge of any kind. The penalties prescribed by the courts for Mr. Parker's convictions on the charges of murder and with regards to the molestation of the three young girls are more that sufficient for me. Clearly the courts have not refused to incarcerate him, quite the contrary. I have in no way supported, nor will I ever support, police corruption of any kind, in any form or for any purpose. In fact, I find it abhorrent and take exception with any attempt to suggest otherwise. Those who abuse the power that society grants them are even more despicable than the common criminals that they are tasked to attend.

It seems clear to me that you have dismissed my email as emotionally driven. I can assure you that it was not. I simply desired to express to both you and Dr. Goldstein that Mr. Parker is not the innocent victim that he is made out to be and to ask that either his entire story be told or that it be removed in its entirety. An unwillingness to provide all of the information relating to Mr. Parker would only illustrate a desire to prop up an argument against the legal system over a desire to see the truth of his story told. It is certainly your prerogative to maintain your site in whatever way you see fit. However, I honestly hope that you are not so blinded by your desire to put forth a belief as to be unwilling to give a complete account of the stories that you use to support it. I am sure that you can understand how detrimental that would be to the integrity of your site and your desire to see justice served.

Sincerely and respectfully yours,
-Michael Kimberlin

An Open Letter to Alvin G. Goldstein, PHD

2009-12-17T08:53:00.000-08:00

Forgive me for stating the obvious, but I rarely write blog posts. Every now and again something comes up that prompts me to put in the time and effort needed to construct something in a longer form. This is one of those occasions. I recently came upon a website that contains information that I believe to be both factually inaccurate and misleading. It paints a picture of a man wrongly accused and victimized by the police, his attorney and the court system. The man in question is Jerry Lynn Parker. Mr. Parker was convicted of the 1970 murder of both my grandmother (Hazel Marie Kimberlin) and my uncle (Michael Wayne Kimberlin) who was only eleven at the time. An abstract of that case can be found in the appeal judgment issued by the Missouri Supreme Court. While he maintained his innocence for many years, he has since admitted to these senseless slayings. While out on parol, Mr. Parker was arrested and convicted of the molestation of three young girls (aged 10, 11 and 13). In my opinion, Mr. Parker is a predator and a danger to society.

What follows is an email response of the contents of the page EYEWITNESS ERROR --AGAIN. This has been sent to Dr. Goldstein in an attempt to have him either remove the page in question or, at the very least, update it for accuracy and completeness of the story of Jerry Parker. Please note that the statements here are my opinions and should be read as such. If there are inaccuracies, please feel free to bring them to my attention in the comments.

Dr. Goldstein,

I am writing to you with regards to your website relating the case of Jerry Lynn Parker. As I understand, I am a bit late in getting this email to you as my father has already sent you a rather emotional response. You should know that while seeing your site brought forward feelings of anguish and anger for him, there is no hate involved...only the pain that accompanies the loss of a parent and a sibling. I wish that I would have gotten the chance to send my correspondence in advance of his email, as I should like to address some of your points and I fear that you are unlikely to be receptive now that you have already heard from our family. Nonetheless, I shall attempt to persuade you against using Mr. Parker as an example for your campaign against eyewitness testimony. As you now know, Jerry Parker murdered both my grandmother and my young uncle. This took place before I was born. While it saddens and frustrates me that he took away my opportunity to know them both, I also do not have the acute sense of loss that my father and aunts must have. As such, I am able to view your arguments with a bit more detachment. I also attended the trial of Mr. Parker that concluded in his conviction for the molestation of the three young girls. So, I have a perspective that you could not possibly attain from examining court documents.

I am curious. Have ever seen a picture of Mr. Parker that was not a mug shot? I can tell you that when the trial occurred, Mr. Parker did not have the pronounced double chin that you point to as a discrepancy between the description from the girls and the mug shots on your page. His appearance in the mug shots is largely a result of Mr. Parker pulling his head back, creating the exaggerated appearance of a double chin. This can be plainly seen in the side-view photo on your site. The assertion that he had "fatty tumors" may be true, however he is clearly attempting to make them more prominent in the photo. Furthermore, Jerry Parker was thin at the time. This means that the girls' assertion that the man that accosted them was less "chunky" than the man in the initial photo line up appeared was accurate. He does appear to be carrying more weight in that picture.

As for the questions regarding the differences in the cars described by the girls, I am sure that you are aware that young girls this age are not likely to be able to identify the make and/or model of a car on sight. I am 32 years old and I am not capable of doing this without seeing it on the rear of the vehicle. The same is true for the gun identification. No eleven or thirteen year old girl could be expected to tell the make and caliber of a weapon. These girls were young and frightened. They endured a horrendous event that they likely barely understood. To expect that their testimony would be iron clad and completely without inconsistency is simply not reasonable.

You also raise questions about the defense attorney's refusal to call witnesses that would profess to his being elsewhere at the time. If you spoke to his attorney, you would probably be aware that these witnesses were not called because they were deemed to be a liability to Mr. Parker's case rather than a help. Mr. Parker never took the stand to defend himself either.

It is clear from your site that a good deal of the information that you have was given to you by Mr. Parker directly. You would be wise to view his stories and claims with a grain or two of salt. I am a skeptic by nature. I tend to desire a higher level of proof for claims of any kind in order to be swayed. As such, I understand the problems inherent in eyewitness identification. So, I am sympathetic with the desire to see convictions made on the basis of physical evidence. Therefore, I will not attempt to further argue Parker's guilt in this case. What I will say is that Mr. Parker is not an innocent victim of poor police procedure, improper defense, etc. He is a predator. As for his "refusal" to attend parole hearings,because of his desire to maintain his innocence, he must have had a change in conviction. He attended his hearing in 2008 and is going to be having another hearing in January. He also maintained his innocence in the 1970 murders until he confessed it to a bailiff during the trail involving these girls. Yet he did not hesitate to attend the hearings that set him free to inflict harm on the innocent again. Mr. Parker likes attention. During the trail for this most recent crimes he would wave and sneer at our family. He made lewd gestures toward my older cousin while leaving the courthouse. He was snide and arrogant in demeanor throughout the trial. For years he sent Christmas cards to my family members, pouring salt in the already painful wounds that he had inflicted. He has brought a number of law suits against the state and employees of the state on a variety of grounds, many of which are frivolous. All of these cases have been dismissed. Mr. Parker is no innocent man and is by no means a victim nor a model for your cause. I would request that you build your case against eyewitness testimony on a different case and leave Mr. Parker to his own faculties.

Also, I would like to say that your use of quotations around the words crime and victim is in poor taste. These young girls were victims of a horrible crime, whether you believe that Jerry Parker was the perpetrator of that crime or not. They were deeply affected by these events and in at least one case it led a family to be torn apart. This was not something in the imagination of some silly little girls. At the very least, please treat the events with the respect and gravity that they deserve and tell Mr. Parker's complete story.

Very sincerely yours,
-Michael Kimberlin

In addition to this email, I sent a request to Dan Rastatter regarding his abstract based on Dr. Goldstein's write up of the Parker case found on the Victims of the State website. That email was as follows:

Mr. Rastatter,

I am writing you with regards to Jerry Lynn Parker. You have him listed on your Victims of the State website with regards to his conviction on charges relating to the molestation of three young girls. Your site led me to the source of your information, one Dr. Goldstein. I have written Dr. Goldstein in an attempt to persuade him that Mr. Parker is by no means an innocent man. I am including that correspondence below. I should also like to request that you give your abstract of the case a second look and consider its removal from your site.

I appreciate your consideration and look forward to your response.

Sincerely,
-Michael Kimberlin

As of the time of this post, I have not received a response from either individual.

The Kimberlin Acting Dynasty

2008-10-10T20:14:00.000-07:00

Since I have demonstrated my prowess in front of the camera in a previous post. I thought I would let my dear old dad get in on the action. Here he is playing the creepy school teacher (check out that jacket and bow tie) for a Springfield, MO CVB film. Enjoy!

You don't have to answer that...

2008-07-08T07:59:00.000-07:00

So, I had another funny interaction with Jeremiah Holly Abraham-Castlevania yesterday. This one was on the phone, but it went basically like this:

(While trying to debug an issue in her application...)
Me: Okay, I just sent you an email with a couple of configuration changes. Put those in and we'll try it again.
Jeremiah Holly Abraham-Castlevania: Okay, I got it. Do you want me to put those in?
(crickets: *chirp*chirp*chirp*)
Jeremiah Holly Abraham-Castlevania: Okay, you don't have to answer that.
Jeremiah Holly Abraham-Castlevania: Alright, they are in.
Me: Okay, now try it out.
Jeremiah Holly Abraham-Castlevania: Do you want me to run it now?
(again with the crickets: *chirp*chirp*chirp*)
Jeremiah Holly Abraham-Castlevania: You don't have to answer that either...
Me: You don't really need me here for this conversation, do you?

Another victim of The Wall of Erasure

2008-07-01T13:54:00.001-07:00

Ahh, Erasure.... Today I was implementing an extension to a class that performs traversing of tree-like object structures (think UI component hierarchies). The parent class extends another type-parameterized version of an abstract class which provides general tree traversal logic. The problem is that I wanted to check that the current node is of a type beyond that of the type parameter provided to the parent class. So to put that into something that might actually be understandable:

public class ParentFinder<T extends Component> extends ComponentVisitor {

 private T parent = null;

 public ParentFinder() {
  // Set up things to travel up the tree...
  ...
 }

 public void visit(Component node) {
  if(T.class.isAssignableFrom(node.getClass())
   parent = (T)node;
 }
}

Survey says! *BZZZZ* XXX *BZZZZ* This line is no good thanks to erasure:

  if(T.class.isAssignableFrom(node.getClass())

And, no...you cannot do "instanceof" either. The JVM couldn't tell you if it wanted to. That info is G-O-N-E, gone!

How dare you want to know what you are working with!

It's a Hate-Really Hate kind of relationship...

2008-06-30T08:15:00.000-07:00

So, I have a lot of interesting little chats with a co-worker of mine. We have what I can only describe as a pseudo hate-hate relationship. Pretty much the whole thing revolves around the intentional antagonizing of one another at every opportunity. Generally, our conversations go something like this:

Abraham-Castlevania, Jeremiah Holly [9:22 AM]:
Michael, I can't get to my test environment!
ME [1:18 PM]:
Is the application server running?
Abraham-Castlevania, Jeremiah Holly [1:18 PM]:
Yes.
ME [3:02 PM]:
Are you sure?
Abraham-Castlevania, Jeremiah Holly [3:02 PM]:
No.
ME [3:53 PM]:
Check.
Abraham-Castlevania, Jeremiah Holly [4:01 PM]:
I hate you.

I have changed her name to protect the far-from-innocent. I will state that the name that I have given her, believe it or not, is no more ridiculous than her actual name. ;) Here is one of our more recent interactions.

Abraham-Castlevania, Jeremiah Holly [10:02 AM]:
Michael, I see this error...JVM appears hung: Timed out waiting for signal from JVM.
Abraham-Castlevania, Jeremiah Holly [10:02 AM]:
could that have caused the problem?
ME [10:06 AM]:
uh...yeah...
Abraham-Castlevania, Jeremiah Holly [10:07 AM]:
don't be smart
Abraham-Castlevania, Jeremiah Holly [10:07 AM]:
what causes the jvm to hang
ME [10:07 AM]:
goblins
Abraham-Castlevania, Jeremiah Holly [10:07 AM]:
I can't stand you
ME [10:07 AM]:
maybe fairies...
Abraham-Castlevania, Jeremiah Holly [10:07 AM]:
really really can't stand you

Confessions of a Geek...

2007-10-08T07:46:00.001-07:00

Just in case there was ever any question about it, my geekiness goes WAY back. The way I figure it, better to admit fully to the existence of this tape well before my run for president.

@BFNH This is a Big Fat Nasty Hack. Be ye' warned!

2007-10-03T08:16:00.000-07:00

The above is my recent favorite @ tag. We all come upon those times when, no matter how much we try to avoid it, a Big Fat Nasty Hack is required. We try to make them pretty. We roll them in perfume, wrap them in silk and adorn them with flowers, but they remain BIG, FAT and NASTY. It's like a warthog in a wedding dress. Let's just call them what they are. The @BFNH tag calls these hacks out and exposes them to the world. Use it wisely.

I ran across this situation most recently when trying to insert cells into an Excel workbook that contained functions with references to named ranges. It would seem that Apache POI does not really support this. POI can read these cells in, but it is unable to provide a valid "function value" for the cell when calling HSSFCell.getFunctionValue(). Instead of a good function string, it gives something like "COUNT( NO IDEA )" or some such nonsense. Not being able to produce a function string for this type of function call, it also fails to parse a function of this type for insertion. I really needed this functionality. As I described in my previous post, I came upon a way to provide dynamic charts in Excel from Java. Seeing what could be done with this, my users went a little over-the-top. Excel reports with charts are something they have been requesting for a while, only to be rejected. So, I set upon the creation of the plethora of new "must have" reports. Many of the reports they want involved breaking up data into ranges and reporting on range statistics. They also wanted to be able to play with the raw data and see the results in the charts. This was a task.

What I decided to do was create named ranges referencing the desired "raw" data ranges for periods. Because this data is being queried based on the users parameters, the ranges must be calculated and created on the server. I planned to then reference these ranges in the cells of a table of period statistics. This would free me from calculating the statistics on the server and allow Excel to alter the charts as data in the ranges is changed. The only thing that was missing was how to go about setting a cell value to something like "MEDIAN("MyWorkbook.xls"!MyNamedRange)". I looked everywhere for a solution. I scoured the POI mailing lists and APIs, I tried a number of variations on the formula string, I searched Krugle like mad and I got nowhere. Not getting any response on lists or forums, and being one to take defeat likely, I took up my trusty debugger and set to probing the depths of POI. Let me warn those of weak constitution to stop reading here. The resulting code involves accessing the inaccessible, breaking the rules that the makers have set out for us and generally doing nasty things.

I created a number of cells that contained references of the type that I required, then created expressions in the debugger to expose the internal representation of the file that POI uses. I found that formulas are parsed into a list of references (to functions, ranges, etc.). I found that I could create formulas that resembled the ones that I desired, using a dummy static reference as a place holder and then swap the static reference for a dynamic one of my creation. This converts a formula like "AVERAGE(A:A)" to something like "AVERAGE("MyWorkbook.xls"!MyNamedRange)". The thing is, the POI guys/gals didn't really intend these things to be accessed directly. So, naturally, I promptly went against their wishes. The following is the result. Use it at your own risk, observe the comments and stated limitations, expand it, generalize it, whatever...but I would appreciate it if you relay any improvements back to me as well. ;)

    /**
     * The purpose of this method is to HACK OUT a static range reference from
     * POI's internal representation of a single range parameter function cell
     * and replace it with a reference to a existing named range. Because the
     * necessary fields and methods are not meant for general use, they are
     * inaccessible. As a result, reflection was used to obtain the necessary
     * references. This provides an opportunity for undetected errors to creep
     * in, as changes to these methods would not be detectable at compile time.
     * Furthermore, as non-accessible methods, they are more likely to be
     * subject to change with future releases.
     * 
     * The process for replacement of references is as follows: - Retrieve the
     * FormulaRecordAggregate from the target cell. - Reduce the FormulaRecord's
     * expression length by 2 (area references are larger than name references). -
     * Set the calculate on load option for the cell to true (options = 2). -
     * Create a new named range reference and set field_2_ilbl to the index of
     * the desired name in the workbook's name table. - Remove the static area
     * reference from the parsed expression (index = 0). - Insert the newly
     * created named range reference into the parsed expression (index = 0). -
     * Smile.
     * 
     * @BFNH  This is a Big Fat Nasty Hack. Be ye' warned!
     * @param results  the workbook being dealt with
     * @param targetcell  the cell in which the formula reference
     * @param nameName the name of the named range to reference
     */
    @SuppressWarnings("unchecked")
    protected void hackFunctionCellToSetNewNamePointer(HSSFWorkbook results,
     HSSFCell targetcell, String name) {
 try {
     short nameIndex = (short) (results.getNameIndex(name) + 1);

     // Get the original formula record aggregate. This must be done
     // via reflection, as it is not an accessible method.
     Method method = HSSFCell.class.getDeclaredMethod(
      "getCellValueRecord", new Class[] {});
     method.setAccessible(true);
     FormulaRecordAggregate original = (FormulaRecordAggregate) method
      .invoke(targetcell);

     // A static area reference is a couple of bytes larger than a name
     // reference. So, if we don't reduce the formula record size, we
     // will get corruption of the produced file.
     List parsedExpression = original.getFormulaRecord()
      .getParsedExpression();
     short length = (short) (original.getFormulaRecord()
      .getExpressionLength() - 2);
     original.getFormulaRecord().setExpressionLength(length);

     // Now we want to make sure that we cause the cell to be calculated
     // on-load. The following line should accomplish that. Note, that
     // if you have other options on the cell, they will be wiped out by
     // this. Chances are that won't effect you though.
     original.getFormulaRecord().setOptions((short) 2);

     // Now we create a name pointer...the constructor I'm using here has
     // not been implemented yet. If it were, we would likely not need to
     // set the "field_2_ilbl" value. From what I can tell, this field is
     // essentially the pointer to the name table in the workbook. We
     // give it the name index and leave the rest alone.
     NameXPtg nameptr = new NameXPtg(name);
     Field nameTableIndex = NameXPtg.class
      .getDeclaredField("field_2_ilbl");
     nameTableIndex.setAccessible(true);
     nameTableIndex.setShort(nameptr, nameIndex);

     // Now we remove the static area reference from the parsed
     // expression and add our name pointer in it's place. Please note
     // that I have only tried this with functions that take a single
     // name pointer and of those, only functions with 1 or 2 total
     // parameters. In the case of two parameters, I have only tested
     // when the second parameter is a constant. For example,
     // This should work with: COUNT("MyFile.xls"!MyName) or
     // AVERAGE("MyFile.xls"!MyName) or even
     // QUARTILE("MyFile.xls"!MyName, 1). I would imagine that the
     // process is similar for more complex function cells, but this is
     // all I have needed, so that's as far as I've gone. My guess is
     // that the length would have to be decremented once for each Area
     // to Name conversion you do and I have no speculation about where
     // the other area pointers might land in the parsed expression (in
     // terms of their index).
     parsedExpression.remove(0);
     parsedExpression.add(0, nameptr);
 } catch (Exception e) {
     // You screwed up and I don't care...write your own error handling.
     // ;)
     log.error("Bad developer...BAD!");
 }
    }

Excel Charting in Java

2007-08-10T09:11:00.001-07:00

Ahh, Excel... I hate it. I find it rather unintuitive, to be honest. No, no no...that is not quite saying enough. I find it nearly impossible to use. Business folk however, love it. In every company that I have worked for, every user group I have served has, eventually, asked for something to be output to Excel. Of course, for us Java folk, there is good old Apache POI. Now, POI is pretty good. I've used it in a number of projects and have not had any stability issues. Performance is generally acceptable when dealing with reasonable amounts of data. It does however, have a good number of limitations. A large subset of the Excel functions are still unimplemented and there is almost no support for charts (To be specific: charts will be preserved but cannot be altered). This is often a big stumbling block. Furthermore, building spreadsheets with method calls is not a very efficient process for the developer. Creating just a single spreadsheet can require a lot of code.

This is the problem I found myself up against recently. In searching for a possible solution, I came up with a couple of really useful finds. The first of which was jXLS. jXLS is an excel templating framework of sorts. It allows a designer to insert tags into a template spreadsheet which will be interpreted by jXLS and populated appropriately. The tags utilize an expression language very similar to the EL used in JSPs or XSLT. Developers who are comfortable with either of these technologies should feel right at home with jXLS.

Basically, you can create an excel sheet and throw in some expressions like so:

Then you run in through jXLS with something similar to:

Map beans = new HashMap();
beans.put("item", items);
XLSTransformer transformer = new XLSTransformer();
HSSFWorkbook results  = transformer.transformXLS(Thread.currentThread().getContextClassLoader()
    .getResourceAsStream("daysToProvideInstructions.xls"), beans);

As you can see by the fact that we get a HSSFWorkbook back from this method call, jXLS is based around POI, but it does the having lifting for the data insertion. If you want to shove that file back out via a HttpServletResponse, you don't need much:

response.setContentType("application/vnd.ms-excel");
response.setHeader("Content-Disposition","attachment; filename=warrantyAgingReport.xls");
results.write(response.getOutputStream());

Put all this in your web app and you'll get:

So, jXLS gives me a nice and easy solution for populating a spreadsheet with data...but, we still cannot edit the ranges of any tables that we create. Furthermore, if we want functions to be evaluated when the spreadsheet is opened, we have to evaluate them in POI, right? Named Ranges to the rescue! It just so happens that we can define a dynamic range in Excel and give it a name. We can then use those named ranges in charts, functions, etc. This results in a those items being dynamically evaluated and gives us the results we want. So following Micro$oft's own instructions on the matter, we can create a couple of ranges in our template spreadsheet like so:

Using those ranges in a chart gives us the following:

Now we have the dynamic Excel charts we need, generated via our Java web application with very little excess effort. So, while I still hate Excel...today I hate it from Java just a little less. :)

Austrailian Echoes

2007-08-02T09:02:00.001-07:00

Would you like a fork, sir? It looks like the Echo2 community has finally made that option a reality with the Cooee project. Cooee (an Austrailian "Over here!", of sorts) is being put forth by Karora, an open source group with routes in Melbourne. The "openness" of the Echo2 project under the guidance of NextApp has been questioned by the user community for some time now.

I am, personally, torn on this issue. I empathize with the issues raised by Karora. I think that the leadership of the Echo2 project have given the community the impression of being forsaken or, worse yet, irrelevant. However, I am still a little unsure of the timing. Echo seems to be on the verge of a fairly major release and I can't help but wonder if waiting for that code to surface might have been worth it. What is done is done, however and Karora can always spend some time merging code. :)

I want to wish the best of luck to the core Karora team in gaining acceptance as well as momentum. A little competition never hurts...

Blogged with Flock

Work, school and other such obstacles...

2007-08-01T11:39:00.001-07:00

So, school, work, and life have gotten in the way of posting recently. Summer classes are always time consuming. I am working on a couple of different tutorial ideas right now. I've got SCRUM, JavaFX and the Swing Application Framework in my sights at the moment. SCRUM is almost ready to go, I can decide on the App Framework or JavaFX to follow it up though. I've begun work on both, but hit the breaks when everything else picked up.

To those of you reading, my apologize for the delay.

Podcasting Tutorials?

2007-06-19T13:38:00.001-07:00

So, I've been thinking a lot about the kind of information that I want to convey here. I am very fond of the tutorial format. The problem is that I am not really convinced that blogging tutorials is appropriate. The reason that I say this is that my tutorials tend to get long-winded rather quickly (as does anything that comes out of my head). Tutorials seem to be a better fit for the multi-paged, online magazine format. The problem I have with going that route is two fold. First of all, I have no desire to spend time trying to convince some online editor to publish my tutorials. Yes, I could always do it myself, but I really do not think that my goals match up with that format. I, like many of you out there, am a busy guy. I think I do a pretty good job of keeping current, but it takes a significant effort. This is an effort that, sadly, most developers either do not have the time or the motivation to undertake. My answer to this problem has been multi-pronged. First, I utilize the wonderful service provided by Netvibes to keep my time spent having to jump from site to site at a minimum. Secondly, (and this is something that Netvibes also helps with) I practice active "time shifting". What I mean by this is that I utilize technology to help me make something out of the time in my day that is lost to the abyss. The time I am talking about is that spent in the car, in lines, waiting for other people or even performing the less "thought intensive" parts of my day job. Now, I do not want to give anyone the idea that I put all of those minutes to actively advancing myself. A good many of those minutes get devoted to things that are nothing but mind candy. I do, however, listen to a number of podcasts that take aim at intellectual topics or attempt to educate their listeners in some way or another.

This got me thinking: would a podcast be a good format for tutorials of this type? While there are a number of podcasts that address software development, most of them focus on news or interviews. From what I can tell, there really is not much out there providing active training to the community. Personally, I know that I would listen to a podcast of this type...but that goes without saying. What I am stuck on is whether or not audio is a format that would be widely accepted for this purpose. I have a number of tutorials canned and ready to go. So, I am contemplating recording a few of them up front to determine if there are any hurdles to getting this type of information across in an audio format...and maybe syncing that audio with a "screencast" if I get ambitious. If it goes well, maybe I will release them and see what everyone has to say. If the response is good, I'll keep it up. I am a bit concerned about being able to create tutorials at a rate that would keep a listener base coming back. However, if I get enough feedback, I may try to balance that out by requesting tutorial submissions from listeners. We'll see...it is really just a thought at this point.

technorati tags:Podcasting, Software, Training, Tutorials

Drink More Guice...

2007-06-19T13:05:00.000-07:00

Okay, okay...this post is, seriously, a long time coming. I have not posted anything for a while for a number of reasons. I could give the details, but there aren't enough of you out there who are going to care. So, I'll skip it and get into the goodies.

Reading this may actually kill two birds with a single stone for many of you. For the example project that I put together here, I made use of the Echo2 framework. There are a number of reasons that I chose to do this. First of all, I think that dependency injection (D.I.) can be particularly beneficial when working in a component model. I think the switch to a real component model in Java GUI development is long overdue, particularly in the world of web UI development. So, I am hoping that this example will convey the ease with which a simple UI can be created using a framework like Echo2 or GWT as well as provide a few simple, yet useful, ways to leverage D.I. when creating a user interface.

We have all seen dependency injection brought into the main stream by the Spring Framework. As many of its proponents will tell you, Spring is a very powerful and highly configurable tool, whose usefulness goes way beyond simple dependency injection. Many people see Guice as a competitor to Spring, and in some ways it is. However, Guice is not nearly as broad in functionality as Spring. Guice is aimed at being fast and simple for dependency injection only. One immediately evident difference between Spring and Guice is Guice having fully embraced annotations in its implementation of DI. While I must point out that while the JavaConfig project has brought annotation based configuration to Spring, the implementation is, arguably, more complex and results in a more intrusive presence in the most common circumstances where DI is being used. If you are familiar with Spring and JavaConfig, much of this will become evident as I continue.

Enough of this blathering, let's look at some code. I am going to start with what many tutorials will save to the end: the point of injection. Ideally, D.I. should be something that is as invisible as possible. Far too often you see people directly accessing a framework's DI context directly in several different places in their application code. This is a situation that I will try to avoid in this tutorial. To that end, I am going to try to find a place where injection can happen once and the effects will flow throughout the rest of the application. In an Echo2 application this choice is simple, every Echo2 application instance is feed off and attached to the user session via a WebContainerServlet implementation:

package com.amateuratbest.examples.guice;

import nextapp.echo2.app.ApplicationInstance;
import nextapp.echo2.webcontainer.WebContainerServlet;

import com.amateuratbest.examples.guice.layout.LayoutModule;
import com.google.inject.Guice;
import com.google.inject.Injector;
import com.google.inject.Module;
import com.google.inject.servlet.ServletModule;

/**
 * This is where all the Guice-iness goes on.  We will look for our injector
 * in the ServletContext, create it if necessary and then inject our newly
 * constructed ApplicationInstance.  All done!
 * 
 * @author mkimberlin
 */
public class TestGuiceServlet extends WebContainerServlet {

   private static final long serialVersionUID = 2715828643772899566L;

   /* (non-Javadoc)
    * @see nextapp.echo2.webcontainer.WebContainerServlet#newApplicationInstance()
    */
   @Override
   public ApplicationInstance newApplicationInstance() {
      TestGuiceApplication newApp = new TestGuiceApplication();
      // This uses the Injector class name as the attribute name...
      Injector injector = (Injector) getServletContext().getAttribute(
            Injector.class.getName());
      if (injector == null) {
         injector = Guice.createInjector(new Module[] {new LayoutModule(), new ServletModule() });
         getServletContext().setAttribute(Injector.class.getName(), injector);
      }
      injector.injectMembers(newApp);
      return newApp;
   }
}

In order to avoid constructing the injector more than once, I am keeping it in the ServletContext. If one isn't in context when I need it, it can be instructed by specifying the configuration modules that contain the desired configuration. Yes, you read that right. The configuration is done in Java, not XML. For the purposes of this example, I have a set of two modules that will be used for injection. In this case, I have one application specific module (LayoutModule) and one Guice-provided module (ServletModule). If you are working with a web application, you will almost definitely want to include this second module, as it defines injection scopes for request and session as well as providing bindings for injection into the request, session or response. It should be noted that there is nothing preventing the use of different modules as dictated by your applications needs. Module selection could be done based on user preferences, branding, or any number of other concerns. The main thing here is that, if I do things right, we should never see an injector again.

Now that we've seen our "point of entry", as it were, let us grab a quick look at those configuration modules:

package com.amateuratbest.examples.guice.layout;

import nextapp.echo2.app.Column;
import nextapp.echo2.app.SplitPane;

import com.amateuratbest.examples.guice.annotations.NamedAnnotation;
import com.google.inject.AbstractModule;

/**
 * This class contains the DI bindings for the main layout components.
 * 
 * @author mkimberlin
 */
public class LayoutModule extends AbstractModule {
   public static final String BANNER = "banner";
   public static final String NAVIGATION = "navigation";

   @Override
   protected void configure() {
      bind(Column.class).annotatedWith(new NamedAnnotation(BANNER))
         .to(BannerColumn.class);
      bind(SplitPane.class).annotatedWith(new NamedAnnotation(BANNER))
         .to(BannerSplitPane.class);
      bind(SplitPane.class).annotatedWith(new NamedAnnotation(NAVIGATION))
         .to(NavigationSplitPane.class);

      
      // Note that if you uncomment the following lines you will get a compile
      // time error.  Guice's use of generics means a far less error prone
      // configuration process.  If this were done in a config file, you would
      // have to wait until run time to discover your mistake.
      //
      //bind(Column.class).annotatedWith(new NamedAnnotation(BANNER))
      //   .to(BannerSplitPane.class);
   }
}

This module, lovingly dubbed "LayoutModule" extends the abstract class AbstractModule that is provided as a part of Guice. As you can see, you only need to override the configure() method and specify the bindings that you would like Guice to honor when doing injection based on this configuration. The first two calls to bind() produce bindings for the given classes for any case where the target is annotated with a named annotation constructed with the name "banner". Using named annotations like this is simply one way to accomplish multiple bindings for the same class. The third call to bind() produces a second binding for the SplitPane class. However, this binding only applies when the target was annotated with a the NamedAnnotation for "navigation".

The section of code that has been commented out can be uncommented to see how Guice's "config in code" approach results in a less error-prone configuration. Static typing results in a compile time error if you have configured a binding that doesn't make sense.

This next piece of code has a couple of methods that are requesting injection. What is worth attention in these is the fact that there was no binding necessary. If you look at the earlier configuration module, you will not find anything that creates a binding for these classes. Crazy Bob Lee and his ilk at Google appear to have put a good deal of effort in to minimizing the amount of configuration you have to do (of which this is but one example). In this particular case, I just need to make sure that any new instances get a rootWindow and layoutPane. Since Window has an available default constructors, Guice will just take care of things for us without having to be told. LayoutPane is a similar, but not identical circumstance, but I will investigate that in a moment.

package com.amateuratbest.examples.guice;

import nextapp.echo2.app.ApplicationInstance;
import nextapp.echo2.app.Window;
import nextapp.echo2.app.componentxml.ComponentXmlException;
import nextapp.echo2.app.componentxml.StyleSheetLoader;

import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;

import com.amateuratbest.examples.guice.layout.LayoutPane;
import com.google.inject.Inject;

/**
 * Very simple implementation of the Echo2 ApplicationInstance.  Normally, we
 * would not want to have a check that is "injection aware", per se...but I did
 * here for "instructional" purposes.  Now I think I'll use some "more quotes",
 * "just because" i think they are "groovy".
 * 
 * @author mkimberlin
 */
public class TestGuiceApplication extends ApplicationInstance {
   private static Log log = LogFactory.getLog(TestGuiceApplication.class);

   private Window rootWindow;
   
   private LayoutPane layoutPane;
   
   /* (non-Javadoc)
    * @see nextapp.echo2.app.ApplicationInstance#init()
    */
   @Override
   public Window init() {
      try {
         setStyleSheet(StyleSheetLoader.load("/style.xml", Thread.currentThread().getContextClassLoader()));
      } catch (ComponentXmlException e) {
         log.warn("Could not load default styles for routine builder.");
      }
       
      if(rootWindow == null) {
         rootWindow = new Window();
         log.debug("Injection Failed...");
      } else {
         log.debug("Injection Worked...");         
      }
      rootWindow.setContent(layoutPane);
       return rootWindow;
   }

   public Window getRootWindow() {
      return rootWindow;
   }

   @Inject
   public void setRootWindow(Window rootWindow) {
      this.rootWindow = rootWindow;
   }

   public LayoutPane getLayoutPane() {
      return layoutPane;
   }

   @Inject
   public void setLayoutPane(LayoutPane layoutPane) {
      this.layoutPane = layoutPane;
   }
}

Unlike with Window, Guice is not using a default constructor for LayoutPane:

package com.amateuratbest.examples.guice.layout;

import nextapp.echo2.app.ContentPane;
import nextapp.echo2.app.SplitPane;

import com.amateuratbest.examples.guice.ComponentUtil;
import com.google.inject.Inject;
import com.google.inject.name.Named;

/**
 * Constructs and contains the main layout components of the application.
 * You will notice the constructor parameters are named.  In this example
 * I'm using named mostly to avoid writing a bunch of custom annotations.
 * This may or may not be the right approach for your project.
 * 
 * @author mkimberlin
 */
public class LayoutPane extends ContentPane {
   private SplitPane bannerSplitPane;
   private SplitPane navigationSplitPane;

   @Inject
   public LayoutPane(
            @Named(LayoutModule.BANNER) SplitPane bannerSplitPane,
            @Named(LayoutModule.NAVIGATION) SplitPane navigationSplitPane) {
      super();
      this.bannerSplitPane = bannerSplitPane;
      this.navigationSplitPane = navigationSplitPane;
      
      add(bannerSplitPane);
      bannerSplitPane.add(navigationSplitPane);
   }

   /**
    * @return the navigationSplitPane
    */
   public SplitPane getNavigationSplitPane() {
      return navigationSplitPane;
   }

   /**
    * @param navigationSplitPane the navigationSplitPane to set
    */
   public void setNavigationSplitPane(SplitPane navigationSplitPane) {
      ComponentUtil.replaceChild(bannerSplitPane, this.navigationSplitPane,
            navigationSplitPane);
      this.navigationSplitPane = navigationSplitPane;
   }

   /**
    * @return the bannerSplitPane
    */
   public SplitPane getBannerSplitPane() {
      return bannerSplitPane;
   }

   /**
    * @param bannerSplitPane the bannerSplitPane to set
    */
   public void setBannerSplitPane(SplitPane bannerSplitPane) {
      ComponentUtil.replaceChild(this, this.bannerSplitPane, bannerSplitPane);
      this.bannerSplitPane = bannerSplitPane;
   }
}

In this case I have made Guice aware of a constructor available for use during injection with the @Inject annotation. Furthermore, I have annotated the parameters of said constructor in such a way as to trigger the bindings that I presented in the LayoutModule.

Another instance of injection in this example application that deserves calling is in the NavigationSplitPane. Let's take a look at its constructor:

@Inject
public NavigationSplitPane(Column buttonColumn, ContentPane mainPane, ContentDAO contentDAO) {
   ...
}

Here again, there is a constructor being marked for injection, and again there are default constructors being used without configuration. The last parameter deserves a few words, and not only because it is highly irregular to construct a GUI component by handing it a DAO...but that's not the point here. ;)

As you might expect, ContentDAO is an interface. So, how did Guice know what to do for it?

package com.amateuratbest.examples.guice.dao;

import com.amateuratbest.examples.guice.dao.mock.ContentDAOImpl;
import com.google.inject.ImplementedBy;

/**
 * Simple DAO interface with a default implementation annotated for Guice.
 * Using the ImplementedBy annotation allows the developer to supply a default
 * implementation in the event that there is no explicit binding for an
 * interface.  This is the case 90% of the time for most projects.
 * 
 * @author mkimberlin
 */
@ImplementedBy(ContentDAOImpl.class)
public interface ContentDAO {
 public String getContent();
}

Some people are going to balk at this right off of the bat. "WHY does my interface know about its implementation?!?" However, I think you have to see this as something that is available for your convenience (and boy is it convenient) and not a required part of working with Guice. If we developers are honest with ourselves, or simply inspect our code, it is clear that most interfaces we create use a single implementation 80+ percent of the time. This makes those 80+ percent easy. Obviously if this is an interface that you are going to package as a public API for some B2B system, you probably want to avoid this type of dependency. Most of the time that is not the case, however. Most of your interfaces only exist on the server and only have one implementation in the first place. So, it is up to you to decide when using this "default implementation" feature is appropriate

I have not presented all of the code contained in the example application in this tutorial. I would encourage you to download and deploy the application for yourself. Plop the war in tomcat and off you go...all of the dependencies are included in the project zip file. You will then be the proud papa (or mama) of a rich web application developed with only a few Java classes, and without touching any javascript directly, which manages to hydrate itself successfully with only one initial point of injection.

Geekfest is good for the soul!

2007-04-13T07:19:00.001-07:00

So, this post was originally going to be all about Google Guice. After writing for a few paragraphs, I realize that if I ever got to Guice this would be the longest blog post of all time. So, tomorrow you get Guice and today you get Geekfest! "What the heck is Geekfest?", you might ask, or maybe not, but you should. Yes, I am sure there is some concert or conference or some such wonder by that name...but, we do not care for such things. Geekfest in this conversation is a few hours that the team that I work on puts aside every other week to encourage, even require, developers to take the time to keep their skills up-to-date and share their experiences with the group. Think of it as on-the-job training that even the veterans need. I have been on so many teams that do not make learning a priority. On most of those teams, training would be provided only if there was an impending need. This is a disastrous way to do things. First of all, we as developers absolutely must stay current if we want to stay employed. Furthermore, we as organizations must keep the skills of our development staff current if we wish to be able to compete in the marketplace. Now, we can simply expect developers to keep themselves current. We can put in the job description that a developer must advance the knowledge of the team, or stay current with market trends or run a freaking marathon...but that does not make it happen. Even for those developers who are self-motivated enough to do these things on their own, what percentage of them go around to the group and make sure everyone knows what they know? Not very many, I can tell you. We geeks tend to be made up of a high percentage of the less-than-social crowd. A lot of people just do not feel comfortable doing this. So, what happens to that knowledge? Maybe it gets utilized, maybe that person puts it to work on a project or more likely it wastes away.

Managers and team leads: You have a responsibility to ensure the best performance of your teams. You have a responsibility to facilitate the growth of those around you. Do not forget this. Yes, I know that you have to get the project done. Yes, I know that it is already 3 weeks behind schedule (that is your fault too, but we will talk about that in another post). None of that matters. Admit it! Two or three hours every other week will not be noticed as even a blip in your time line. What do you get out of this? You get a team that feels like their development is important enough to you and to the organization to make it a priority. Have you ever felt that way? Does your organization put you first? Make it happen for your employees, it makes a world of difference.

Maybe all that touchy-feely mumbo jumbo is not enough to convince you. So, let us take a look at the basic rules that will allow us to realize some actual benefit for the team:

Thou shalt not skip the 'fest, no matter how busy you are...only actual emergencies qualify as an excuse for absence.
Thou shalt not investigate anything directly related to project work during the 'fest.
Thou shalt share your experiences with the group before leaving the 'fest.
Thou shalt capture the results of your investigation at some level on the 'fest wiki.

Now, that isn't asking all that much is it? Do you see where the increased benefit comes in here? No, well let me wax poetic on that for a bit. :)

We have already addressed the fact that, if left to their own devices, only a fraction of of the group will actively expand their horizons and that only a fraction of those will share a fraction of what they learn with the group. Wow...that is a lot of fractions and a lot of lost knowledge. What makes Geekfest different? Everyone learns what everyone was learning! I scream, you scream we all scream for...oh, never mind. Even the thickest headed of management will see the benefit of this. If a team of six goes into a room and spends two hours investigating different topics then each one shares what they learned, what do you get? Let us do a bit of arithmetic. 6 people do 2 hours of work and share that with the team of 6...hrrrm: 6 x 2 x 6 = 72 hours with of gathered knowledge. You invested 12 man hours. Need I say more? Now of course our implementations of this will be less than perfect. Still, this is a great deal for an organization What will happen if we let developers do this on their own? We have to start dividing instead of multiplying. Oh, and those developers who were learning on their own...do you think they stop because of this new found study time? Not from my experience. If anything, they are spurred forward in their endeavours. This is a big fat win for everyone involved.

Now, you have read this. It all makes perfect sense to you. How could you not have seen this before? So, what are you going to do about it? If you are a manager or team lead, schedule the meeting now. Do not wait. You and I both know it will get swept under the table. If you are a developer, suggest it to your boss. If you do not feel comfortable being that forward then send them a link to this post. Tell them your friend that works over at the major competitor said his team has been doing this for months and how much they are gaining from it. The entire industry will be all the better for it.

technorati tags:Agile, Software, Development, Learning, Training, Guice, ROI

Domain Driven Design...revisiting good ol' fashion OO.

2007-04-10T09:04:00.001-07:00

A few weeks ago I attended the Gateway Software Symposium put on by the guys from No Fluff Just Stuff. While I was there, I got the opportunity to listen to Venkat Subramaniam talk about domain driven design. I almost skipped out on it for something else, but Venkat's knack for speaking is always good for an enjoyable lecture at the very least...so I went for it. As expected, Venkat gave a great talk. While the content convinced me even further that DDD is essentially a repackaging of old ideas, it also made me realize that some of the things that have bothered me about some of the ways we utilize patterns, and how many of them are even enforced as standards. This is just evil. Some of this stuff is so ubiquitous that we just accept it as perfectly normal. How many of you have worked on a project that looks something like the one below (hopefully with a few more classes)?

I know that I have...and not just one. Now, mind you, this project is trying really hard to have good practices. It wants to reduce tight coupling...heck, it might use DI a la Spring or Google Guice. What it does more than anything is insult our intelligence. When I see a project like this, it makes me wonder why all this poor User has been scattered all over creation. I feel like this project is trying to be a self-describing code cookbook. It practically begs you to right a BO, a controller, a DAO, a model object and a factory for every class you create. Now, I know we all hear a lot of people telling us not to put business logic in with our model. I say, "Bullocks!"...put logic where it belongs, wherever that may be. Sometimes our objects want to know how to do things for themselves. Not only that, but why are we all so afraid of maintaining state in our applications? Yeah, it comes with some complications...but sometimes those complications are worth it and even appropriate.

I want us to start taking a hard look at what the users are saying about how they work. Listen to what they are doing...how they are working now. You probably had a professor use the old analogy of the bicycle and how all bicycles have a few attributes and actions that are common to them. That same professor probably talked about 10-speeds and how they have some extra attributes and actions that a plain old bicycle might not. I often wonder what this professor would think of seeing:

int gear = bicycleBO.getCurrentGear(tenSpeed);

bicycleBO.setGear(tenSpeed, gear+1);

I will tell you exactly what he would say:

tenSpeed.upShift();

I am not advocating that we go back to the days of gigantic all encompassing classes...where a bicycle knows how to do anything that one might possibly want to do with it. I mean, I might want to hang my bicycle from a tree, but that does not mean that my bicycle should know how to climb trees. I am merely saying that we need to stop worrying so much about applying patterns across the entire landscape of a project and start thinking about the design that fits best.

technorati tags:domain, driven, design, java, patterns, misuse

Fresh Blood

2007-03-30T21:20:00.000-07:00

No, no, no...I'm not going all Scott Sigler on you. (Go get Ancestor tomorrow, Junkies!!!)

I am talking about breathing life into that dead project. We have all been there. You are assigned to a project where momentum appears unattainable and you fear the worst. If you are a project manager and this is your project that I am talking about, big red flashing warning lights should be going off for you right now. When the dynamics of a project team go stagnant and the momentum has died off (if it ever existed), it may be time to call in some fresh blood.

Let me make it clear that I am not suggesting that adding new people in the middle of a project is going to solve all your problems. As most of us in the real world are aware, this is rarely an option. Often only projects of the highest priority and visibility have the freedom to infuse their team with "resources" at a whim. Furthermore, this will often be counter productive. What I am suggesting is much more benign that any of this. I am saying simply that the right person can breath new life and vitality into a project. So Mr. Manager, if you happen to find yourself in the sorry position of needing to fill a vacancy on a project that is already flailing, turn it into an opportunity. Do not simply fill the slot with someone who can crank out that code. Take the time to find someone who has a focus on team communication. Experience with agile development practices can bonus points to your candidate. Finding these candidates is no easy task, but they are out there...and if you are having a hard time getting your hands on the right person, just give my employer a ring. I am sure they would be happy to let you know when I will being freeing up. ;)

Someone who is excited to dive in and learn from the team, who has focus on the user community and goes out of their way to encourage involvement from everyone can turn a failing project upside-down. When it works, the change is dramatic. Let us hope that your project is not need of such a "magic-maker"...but remember that it is never too late to make a necessary change.

Down with JSP!!!

2007-02-14T11:46:00.001-08:00

Okay, okay...that's a bit of a troll, I admit. However, I have been doing Java based web applications for what must be more than 7 years now and I am honestly sick of JSPs. Now, before I get all ideological on you, I want to point out that I am not sure that we are ready to completely eliminate the JSP from the planet. I will tell you that the average developer of Java web apps is spending way too much time looking at these things. JSPs are nasty, dirty things that are difficult to put together and even worse to maintain. Now, I'm sure some people reading this will start thinking things like "this guy probably still uses scriptlets everywhere" or other such blasphemies. I will assure you this is not the case. I use all the happy little taglibs that are supposed to make my life so much easier. Yeah, well they don't...

So, it's obvious that I am getting a bit hot-in-the-collar about this. However, I think that most of us who care about such things realize that the old familiar style of web development just isn't doing it any more. I am tired of switching from XML to Java to SQL to CSS and on and on and on. I am tired of writing unnatural form bindings and silly validation scripts. I am tired of not being able to interface with the components on my web UI in the same way I would any other components in my application; via a Java API. Now, that there are frameworks that are getting there. I have used Echo2 and fiddled with Google Web Toolkit a bit, and they are on their way. I am really excited to see the switch to a component and event paradigm in web frameworks. I wish that JSF had not been so little so late. However, I guess that change is in the air and we really will not know where we are going until the dust clears. Wherever that may be, I sure hope we get there soon...because, if I have to write another <%@ taglib prefix="c" uri="/WEB-INF/tld/c.tld" %>, I'm not sure I can take responsibility for my actions...

technorati tags:Java, JSP, JSF, Echo2, GWT