Jython 2.2 is finally out!
I was busy this week and didn’t get a chance to blog this:
Jython 2.2 released!! Woohoo!!
It’s been a long time coming guys. Congrats!
Powered by ScribeFire.
Another Work Example
This email was in my inbox one day. It was meant for another team, but I’m on their alias (long story). The contents were:
It is important that we keep our test cases up to date. Whom ever has the pager should run continuous integration on a daily basis.
There is nothing “continuous” about someone logging in on the weekend just to do a build. And they are going to forget. I fired off an email about CruiseControl and said I would help set it up since I’ve done it before. Only silence was heard.
Today this was in my inbox:
It looks like the continuous integration was not ran since August 14th. Whoever has the pager should run it on a daily basis. It just takes few seconds to start the process.
They aren’t going to remember. Why do something manual when you can do it automatically? Luckily, I’ve been told that I’m going to setup CruiseControl up on another machine for them. They just may not know it yet. 
Powered by ScribeFire.
My Big Ball of Duct Tape
I have two projects at work — one is new, and I’m using Spring, and unit tests and life is good. But one is old — quite old. There is code from five years ago, which is positively ancient for a J2EE application! This app is just a Big Ball of Duct Tape.
Some of you are familiar with the [Big Ball of Mud](http://en.wikipedia.org/wiki/Big_ball_of_mud) concept. You know, when someone just pounds more and more stuff into an application and it turns out so spaghetti-like it’s unbelievably difficult to work, to change, to fix, etc. My Big Ball of Duct Tape is like that, only that there were at least five development teams that have worked on this, each with different abilities. Some are still at the company, and have confided in me that this was their first J2EE application.
I think this app started out pretty good, but when they needed to make changes, like bug fixes or added functionality, they didn’t gracefully put it in. Instead they stuck it on with duct tape. And, when they needed to fix those bugs, they used more duct tape. And when more functionality was needed, they added more duct tape. When I got it, the app is so horrid, so temperamental, that a small change can have disastrous results. And I can show you an 10,000 line Struts “Action“ class to prove it.
Needless to say there are plenty of odd things that happen in this strange app. One of them is this: the user turns something off in my app, it gets saved to a database. Every hour another app has a batch job that looks at my database, finds what the user turned off and turn it off in their app. Janky? Very. And prone to breakage.
It seems that if my app doesn’t save it right, the other app can’t find the changes. So my app has it turned off and the other app has it on. That messes with my users, who can look at both things. And some people only look at the other app. Yeah, it’s a mess.
I was assured that this only happened once in a while, and they sent me an email saying what I had to do to fix the database. That email described the exact state that the database needed to be in for App #2 to find the info and the bad state that the DB was in when the update didn’t happen. It sounded like someone researched the problem thoroughly, but I still wasn’t sure why no one fixed it. I guess some duct tape was enough.
Late last week, I got the call that it had happened. I was in a hurry because I had a training class starting in a few minutes, so I quickly made the update and went to class. I left a message with the user that called me and said to let me know right away if there were problems.
On Monday, I got a call from another user that said it was still not fixed. And then he said, “How come our software never works?”
Me: “I was under the impression here that this only happens once in a while.”
User: “No! This happens all the time!”
Well, now we are in a different situation! I dropped what I was doing and went full board into the issue. I re-read the email that described how to fix this, and did it right this time. I called the user back and said that, at the next sync (which happens every hour) it should be fixed and to call me back if should. And then I told him I was going to look and the issue and solve it once and for all.
I started up my dev environment, and could easily replicate the problem. Good — Step 1 down.
So I started unraveling the duct tape. Slowly and surely I unwrapped it, carefully making sure that nothing fell off. I started removing unused variables (which were legion) and got to the offending section. That section has a nice, long comment about the fact that the present code wasn’t a good fix and it needed to be fixed soon. That comment was dated in 2003.
But as I looked closely at it, I wasn’t sure that section was ever actually called. A log message into that section confirmed it. I looked up above and saw very, very similar code. I put a log message in that section — bingo!
I took the nicely commented code, warning and all, and put it in it’s own method, put a flag on it so I knew which section called it, and made both parts of the code call that method instead of having the same logic in twice.
As I started poking at it, I figured out what it was. The logic should have been to make a copy of the object, and then make a state change. The actual code changed the state first, and then made a copy! So, we were never saving the right data to the database after all.
Did I mean never? Yes, I did — with “never” meaning ever since I inherited the code. And, I guess, ever since the developer before me inherited the code, since they are the ones that warned me that it happens once in a while.
Somewhere in that time, I noted that two hours had passed and I hadn’t heard from my user yet. I called him and asked him to check the applications again. “I’ll be darned, ” he said, “things are working now!”
I still need to test my changes to make sure that nothing bad happens. Such is life when you support an application that is a Big Ball of Duct Tape.
Book Review: Spook Country
[](http://www.amazon.com/gp/redirect.html%3FASIN=0399154302%26tag=ws%26lcode=xm2%26cID=2025%26ccmID=165953%26location=/o/ASIN/0399154302%253FSubscriptionId=1MW1MMWX4EMWX0T93DR2)
It’s not often I review a book only published a couple of weeks ago. But some strange twist of fate, I was able to get it from the library on the same day it was published.
I like William Gibson, but kind of lost hope for him in his second trilogy. I didn’t care that it wasn’t scifi, but it seemed to lose focus. I read [*Pattern Recognition*](http://www.amazon.com/gp/redirect.html%3FASIN=0425198685%26tag=ws%26lcode=xm2%26cID=2025%26ccmID=165953%26location=/o/ASIN/0425198685%253FSubscriptionId=1MW1MMWX4EMWX0T93DR2) with little anticipation and was greatly surprised. I thought *Pattern Recognition* was his best book since [*Neuromancer*](http://www.amazon.com/gp/redirect.html%3FASIN=0441569595%26tag=ws%26lcode=xm2%26cID=2025%26ccmID=165953%26location=/o/ASIN/0441569595%253FSubscriptionId=1MW1MMWX4EMWX0T93DR2). While I think *Pattern Recognition* is a better book, [*Spook Country*](http://www.amazon.com/gp/redirect.html%3FASIN=0399154302%26tag=ws%26lcode=xm2%26cID=2025%26ccmID=165953%26location=/o/ASIN/0399154302%253FSubscriptionId=1MW1MMWX4EMWX0T93DR2) is still very, very good.
It’s hard to talk about the plot without giving anything away. Let’s say it starts with three divergent plot lines, which is typical in a Gibson novel. But two are connected very early on, in a very fascinating way. Mysteries are revealed, tension gets high, and many questions are answered in a the end. A few, however, are not.
I like the world that *Spook Country* takes place in because it’s the one I live in — I’ve gone war-driving, I tend to Google people to see how what comes up about them, I love to see where the new tech trends are, etc., etc. This world is the same one Gibson writes about.
There are a lot of people that are going crazy about this being Gibson’s first book that takes place in New York City and L.A. I would also like to say that *Spook Country* is Gibson’s first book that mentions Nebraska, even though no plot really happens here.
I give *Spook Country* 4 out of 5 stars.
**What others have said**
[Corey Doctorow](http://www.boingboing.net/2007/07/31/william_gibsons_spoo.html) has one of the best reviews out there. He’s right when he says this is a weird, futuristic world. But it’s also the world we live in. What makes it so weird is that we barely recognize it.
[Tim Bray likes this too. ](http://www.tbray.org/ongoing/When/200x/2007/08/15/Spook-Country) He likes the Vancouver setting in the climax of the novel. I love Vancouver too! And he likes Gibson’s use of language, which I also admire great admire.
Setting up a JNDI Data Source in Spring
Just put something like this in your applicationContext.xml
<bean id=”appDS” class=”org.springframework.jndi.JndiObjectFactoryBean”>
<property name=”jndiEnvironment”>
<props>
<prop key=”java.naming.factory.initial”>weblogic.jndi.WLInitialContextFactory</prop>
<prop key=”java.naming.provider.url”>t3://localhost</prop>
</props>
</property>
<property name=”jndiName” value=”data_source_jndi_name”>
</property>
</bean>
You’re properties and jndiName will probably be different. But still — no code, just configuration. It doesn’t get much better than that!
Powered by ScribeFire.
