Where Are The Wise Men?

Mike's Ramblings

Some Random Techie Notes

| Comments

  • I was going to try out Git on my machine this afternoon as a little project. But then read the warnings on Git's [WindowsInstall][]page and agreed with the user's comment at the end. I'll give it another year.
  • How come I just found out about the svn list command?

    $ svn list file:///c:/Projects/repos/my_proj/branchescheckpoint-1.187/checkpoint-1.188/checkpoint-1.189/checkpoint-1.190/checkpoint-1.191/checkpoint-1.192/checkpoint-1.194/
  • I switched to using [Poderosa][]as my command line emulator of choice earlier this week. It hasn't been a normal work week for me, but I like it. It's not as configurable as [Console2][] but it does do a better job with the actual emulation part. And it understands Cygwin without too much pain. The End key doesn't work in Poderosa which is a pain when you are in a long less command. I'm not 100% sold on Poderosa yet. Oh, iTerm clone for Windows, where are thou?
  • [YSlow][]is very cool.

Powered by [ScribeFire][].

Compliance vs Commitment

| Comments

I was taking the last of my New Employee classes this week. One class was on communication and one of the Big Ideas from that class was "Compliance vs Commitment " and that you really want people to be committed to what you are saying as opposed to just complying. This passed through my brain with little impact but later in the day, this was brought up again and I had an "A-ha" moment. This question of Compliance vs Commitment is really the same argument as the Law vs Grace.

the Law. That's because we simply can't follow the Law -- we are full of sin. But some people ask, "Couldn't God just make us follow the Law?" or "Couldn't God just forgive us anyway?"

The answer is yes He could but no He won't. The answer is the same for compliant.

Christ showed us what being committed to God is like -- even to death on the cross. And the Christ sacrificed himself in exchange for our sins since we can't commit to the Law, we could be commit to God's forgiveness. That's really it -- commit to God's forgiveness and the rest is done for you.

With grace, commitment is the only option God has given us. We can't simply comply with it, because God has done it all. This goes back to one of the profound statements that I have ever heard. It has stuck with me for over ten years and will probably be with me until I die. "Grace brings forth response." Meaning that once you are confronted with the reality of God's grace, you must respond in one way or another. There is no middle-of-the-road, shrug your shoulders kind of response to the grace and forgiveness of God.

So, then, how are we showing our commitment to God?

Powered by [ScribeFire][].

Jython 2.2 Is Finally Out!

| Comments

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

| Comments

This email was in my inbox one day. It was meant for another team, but

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.

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

| Comments

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 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 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?"


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.