Spring, Struts and Weblogic 8.1 SP6

It's hard to get these things working together in Weblogic. You will have to think about class loading issues. The main problem is Spring support action classes reference Struts action classes and this fails to work if they are located in sibling class loaders. It's a pain to find why. Weblogic doesn't come with a nice class loader debugger (or I am blind enough not to see it) and you have to write your own debugger. The only thing so far I could do to get around this is to edit Spring manifest file and add struts.jar to class path dependency so that Weblogic makes the link. I am wondering if this should be a part of spring jar file anyways. As far as I understand it is a Java fashion to do this. On top of this, I think spring jar file should be sliced up a little bit for class loading reasons. I mean the web part of it might not need to be in the same class loader its container code is. The container code has state, it loads a network of beans and it keeps the network in memory along with static scoped beans. Therefore, it makes much sense if you want to share this container with multiple modules for performance reasons. Nonetheless, you won't need to share the web helper classes. 

Spring Experience 2007

A colleague of mine sent this picture to us, right from Spring Experience 2007. I resist not to comment on it. It's cool, hey?

 

Flex is the future?

The more I read about Flex the more I am convinced Flex is the way to go. For me the bigger question is how long HTML and its descendents will last. HTML was really useful but know it is just too incapable and simply it has no memory. It's intelligence is also usually supported with scripting languages such as JavaScript which is a beast of its own kind. Look at the complexity of Java front end frameworks. There is tons of them and still neither has a neat solution to the front end puzzle. The Java front end code is usually terrible. It really takes very good developers to come up with a web based GUI in Java that is well designed and it is easy to maintain. However, this is not what we want. We want stupid programmers to be able to produce. Java front end model is suffering from HTML shortcomings. Mostly from its lack of memory. That is, a request should be sent to user for every time a data is updated and server should keep this in memory for the scope of a conversation. Think of a form that adds items incrementally and as user presses save the changes are flushed to database. This will require Java code to take care of the temporary list of Items. That is why we have request scope variable, session scope variable and application scope variables. These are all a problem when it comes to scaling. In any events, Flex seems to be the answer. At least it is a great improvement. It has memory. It is richer that HTML and it can customized the same way. Even Microsoft is pushing its SilverLite.

SELECT FOR INSERT

Wouldn't it be nice if we had some like SELECT FOR INSERT in SQL?  I am not even sure if we don't but I have not been able to find anything like that. The problem I am trying to address is the classic problem of two transactions trying to insert a data if it is missing. Lets say T1 reads for record X and if it doesn't find it, X gets inserted. T2 is doing the same. T1 and T2 happily start together so T1 reads and there is no X, same happens to T2. T1 inserts X and commits, T2 inserts and commit and boom, Duplicate data. In the same fashion we have SELECT FOR UPDATE, it would be nice to have SELECT FOR (POSSIBLE) INSERT in SQL. This would mean looks for this data and if you don't find it lock the table because I am going to insert it. It has a bad effect on performance though. That's probably why we don't have it.

The most dreamed tool on Windows, Grep!

Done nicely!

http://tools.tortoisesvn.net/grepWin

Why do they still lock game CDs?

Game hacks and cracks are usually out within a week or two. Sometimes they are available before games are out. I am still wondering why companies are spending money on preventing copies of their CDs. I don't know how many stupid people there are and by stupid I mean the ones that can't go on internet and do a simple google search. I am talking about a 'XYZ no cd crack'. It doesn't look very hard, does it? The downside of this is legal users have to suffer. They have to push in their CDs each time they want to play a game, and of course one day their CDs are no good because all scratching and everything.

Once I asked my manager if we needed to obfuscate our code so that nobody can hack into it. He pointed at one our colleagues and said look at him---he was decompiling a flash code---there is billions and billions of these people. The only way we can be ahead of them is to be literally ahead of them by developing faster than they can hack.