Archive forNovember, 2005

Sessions for sessions sake

I have a client who’s website I am now responsible for. This site suffers from “too many developers” syndrome, in that there are some very different coding styles througout. The unfortunate thing is that by reading through the code you can see that most of them have absolutely no idea what they were doing.

I’ve found instances of horribly inefficient JavaScript where 3 functions are defined for each record in a result set and the Primary Key field is appended to the function name to make it unique. None of these repeated functions did anything different. None of them used any of the information from the recordset other than the Primary Key field. It was effectively just a window.alert('Are you sure?'); type function.

I’ve found inefficient ASP where a query is performed, the record set is looped through and counted, the query is closed, and then it is redone. All just so that the number of returned records would be known before the record set was processed. Never mind that the record set can be interogated to find out how big it is. Never mind that even if that was not possible, you could have processed the record set, perform a MoveFirst and then start again without having to destroy the recordset and recreate it.

I think I’ve just found the piece de resistance - storing information in session variables just for the sake of it. A Page that I am currently reworking sections of has the following brilliant piece of coding

Session(”CustomMessageSmall”) = “error about credit card payment failure”
response.write Session(”CustomMessageSmall”) & “<br />”

I could understand putting the message into a session variable if it was being used on another page somewhere, but it’s being used on the very next line. I mean seriuosly guys, lets not make the server do any more than it has too.

Comments (2)

Slight hicup on the network

We’re currently going through a bit of an upgrade of the Oracle database server that have at work at the moment. We’ve purchased new hardware, which has been mounted into the shiny new rack and we are now up to the connecting, configuring and installing stage.

We’ve gone for a fairly modest 2 server Oracle RAC cluster. This gives us the additional power and disks that we need now and the smothes upgrade path in the future when we need more power.

The hicup on the network came about when we were connecting the new servers into the main switch. Our main switch is a nice little 1U, 48 port device and we appeared to only have 1 spare port on it. After a fair amount of cable chasing we managed to find a couple of unused ports. Unfortunately we also managed to slightly dislodge the network cable for the server that is responsible for DHCP on the office LAN.

All up, things were probably offline for about 10 minutes tops before we a: heard about it, and b: fixed it up. Not exactly a great acheivement, but amusing enough. The image below should give a clear indication of the mess that is the main patch panel and switch at the moment.

Main patch panel

Comments (2)