If you are human and you've written something and are reasonably intelligent - say somewhere between a door stop and Fox News Anchor, chances are good that if you come back to whatever it was that you wrote after a bit of time, you are going to see things that could be improved or written differently. Those that fail the reasonably intelligent bit think their shit is golden and keep making the same damn mistakes. If you are writing novels or editorials or blogs, the impact of your poor writing is probably negligible. But, if you are writing code and scripts and doing tasks that other people's code and scripts are based on, as the Ski Instructor says...You are gonna have a bad time. The mishmash of half-assed code and fucktard scripts snowballs into a leviathan of suck. It is an epic undertaking to unfuck the fuckeduppedness.
All of the places I have written code for, yeah, both of them, have been somewhere in the midst of gosh we have done some shitty things and we really need to do things in a sane way...maybe follow some best practices and not consult the magic eight ball or other eight ball before making crucial architectural decisions or implementing some homegrown, inbred, failed abortion of a thing with Patrick Duffy for a leg and a celery hand. Goddamn it - unraveling this FSM-looking colossal mess will test your testicular or ovarian fortitude. You better wear a cup. Servers may crash, skies may fall - rest assured tears will be shed. Suck it up and forge ahead.
There is an old proverb (Mongolian maybe) that states: No matter how far down the wrong road you go, turn back. This definitely applies to technology and diabeetus - depending where you are on 435 in KC or 270 in STL it might by shorter to keep going.
So, after years of being told, get it done, of changing code during a deploy - not right before a deploy, but during a goddamn deploy, of we'll come back to documentation at a later date, of he who screams the loudest gets his feature added, we are attempting to put in structure and do things sanely. Let's test our shit before we deploy it. Wat? Document your inputs and outputs - make it easier for someone to code against your stuff. Da fuq?
Being the only database and sql dude on the app side, I was forgotten or picked last. I had heard some bitching from the full on coders about having to write tests for something that has worked for years when there are other things breaking and new fun shit to do and thought, "hahaha - fuck you, cry about it you baby girl" *in my best Vince Vaughn* - well this baby girl is crying about it now - jokes on me. I had a 7 second change to a stored procedure - literally 7 seconds - not literally almost about 7 seconds - well, no, really more 10-ish - fucking 7 Mississippi's and I was done with the code change. It took me days to figure out all of the inputs and how to appropriately build out the data picture "because you cannot assume the data exists - you have to create it and then clean up after yourself" and our system is pretty fucked up. If there was a God and he was a heroin addict with Schizophrenia, Priapism, Parkinson's and Tourette's - not to mention a spastic colon - He could not eat tainted sushi from a sidewalk vendor and shit something worse that this. Or maybe I am just a little bitter.
This process is going to make you want to shoot some people or at least pistol whip them. The sad truth is that most of the time, you had a hand in creating this candidate for a really really late term abortion. You may want to pistol whip yourself, as well. Don't waste time doing that however because there is a mountain of work ahead of you. It is going to suck. It is going to drain your soul and make you question your choice in profession. I have been thinking about how I used to tend bar. I was pretty goddamn good at it too. Bars are fun. Sometimes you can drink. Sometimes a girl will go wild and that's always fun. When my eyes are crossing and I am cussing my mother for not swallowing me instead, I consider going back to that life. Not one single person has come back to the bar after I made them a drink and asked me to rollback. That sounds pretty good. But then I remember the bad parts of it, getting shot at, tires slashed, ass kicked in monolithic brawl, having to socialize with mouth-breathing knuckle-draggers and scumbag Steve's as far as the eye can see. Fuck that. Benefits are nice too. Paid holidays and occasional free pizza make me happy. I could use a nice pair of tittays once in a while though. I'll have to settle for CTRL-SHIFT-N.
Anyway, virtually nobody does it right the first time. You have to pay your dues. Things that are difficult to accomplish make you feel like a fucking badass when you triumph over them. And fuck it, it all pays the same. But, someday - some fine day - you will be sitting atop the Everest of code done the right way. Shit actually works as expected. Changes that fix one thing but break something else are caught quicker than Mexican food through a goose. You can install things like Chaos Monkey and break shit without impacting user and losing money. And ultimately, your end-users are served better, quality is high, output is fast, everyone gets raises and you get to live the good life. Or at least that's what these motherfuckers keep telling me. Maybe I'll get there one day. Maybe I'll see the bright shining lights of Utopia. But for now, its all asses and elbows and "who in their right fucking mind would think that inserting values without checking them is a good idea?" and "step away from the firearm, sir."
In closing, I feel like I just brain-skeeted all over this page but catharsis is good for me but potentially puzzling for you Dear Reader. Console yourself with the fact that "We lib a fyt anuda day". I'm off to drink some Gatorade, or maybe H2O. Toodles.
Thursday, September 27, 2012
Tuesday, September 4, 2012
Adventures in the Fog
Disclaimer: I am not positive of what guidelines, etiquette, etc. I should be following here so I am going to write this like I would tell someone that I bumped into at the water cooler. It may be bitchy at times. Some stuff is really aggravating and I've heard tell that Blogs can be cathartic. Take everything with a grain of salt and don't be such a bitch.
I had an interesting ulcer inducing morning this morning. I received a request for a report that was timing out in the Admin, which is Standard Operating Procedure for us because we report off of the transaction system because why would you want to do things the right way. That is so boring and it has totally been done before.
Anyway, I get the request and it is for data from the old system that was cobbled together by steam punk artists and Katrina survivors. The queries for the reports are built in the java code, are pulled together by loading temp tables and massaging data in the application. It is horseshit. We had a project a few months back that allows for pulling old system data from the new system so I checked and we had converted the requested report to a stored procedure. One would think this would be a fantastic thing. Turns out, not so much.
I convert the parameters to bind variables so I can just run the query and export the data. I get an Invalid Number error on the service code field...which is alpha-numeric. WTF, right? How can Oracle throw a number error on a character column with no conversion functions on it? I know! It shouldn't! Does not compute!
For those of you who don't know...a good way to figure out what is wrong with an extensive query is to strip things out by commenting column lists, joins, etc until you get to something you know works right. I begin the process by dropping some tables from the query (NOTE: I did NOT drop tables from the schema - that's just a phrase for commenting things out) until I get something that works. Problem is, I never got something that worked.
Another good method for fixing a broken query is rewriting it from scratch - adding in more columns and tables until you get the desired result or recreate the issue. Hopefully by this time we are getting zeroed in on the problem and can formulate a plan of attack to fix the goddamn thing.
I start out with a single table and the query runs as expected. I add in a few more columns and joins and stuff and everything seems to be working. I get to the last little bit and boom. No dice. It doesn't make any sense. Service Code can contain numbers but should not be restricted to numeric only. And why the sometimes issue? Not sure.
I take another tack and create a few temp tables to simulate the joins in the query. It is basically the idea that if there is a problem when you join table a, table b and table c all at once, how about create table ab and then joining that to c. It may shine light on whatever the ultimate issue is.
So, after a few hours of investigation, false starts and curses hurled at a world that would birth an abomination like this, I discover the true issue. The start and end date parameters are passed as timestamp and in the query, a to-char wraps the end date but not the start date. When you convert a parameter in a query to a bind variable (by adding a ':' in front) and are passing date or timestamp, you can write the value in the default format to short circuit conversion. In this case the varchar2 value'01-AUG-2012' will implicitly convert to timestamp when the query runs. Since we are doing an inclusive range, we are converting the end date to character and adding in the time component of ' 23:59:59' and since the incoming parameter is timestamp when the procedure runs as normal we need to convert that timestamp to varchar2 to add in the time component. There was a superfluous to_char() on end date. Oracle somehow flagged service_code as the problem column. Wild goose chases ensues. Fun is had by all.
I blame: Oracle for misleading errors, the system for not working appropriately, all of the developers and managers that are no longer here to defend themselves, users that have the gall to use the system and expect results, the liberal media and right-wing bible-thumping fascists. Oh, and Apple. Steve Jobs was a dick.
So, the ultimate lesson to learn here is that the error you see may not be the real error. You could have a ninja error - pops in, fucks shit up. poof - disappears. You could also have a Fox News error. This is an error that points to other things that are fine as the issue. Fox News errors are totally oblivious of their own culpability in the matter and will argue against all evidence to the contrary. The bible says God exists. Problem, Athiests?
And so concludes my virginal foray into blogging. I hope to continue blogging but let's be realistic. All of that girl on girl action is not going to watch itself, now is it. We all have our priorities.
I had an interesting ulcer inducing morning this morning. I received a request for a report that was timing out in the Admin, which is Standard Operating Procedure for us because we report off of the transaction system because why would you want to do things the right way. That is so boring and it has totally been done before.
Anyway, I get the request and it is for data from the old system that was cobbled together by steam punk artists and Katrina survivors. The queries for the reports are built in the java code, are pulled together by loading temp tables and massaging data in the application. It is horseshit. We had a project a few months back that allows for pulling old system data from the new system so I checked and we had converted the requested report to a stored procedure. One would think this would be a fantastic thing. Turns out, not so much.
I convert the parameters to bind variables so I can just run the query and export the data. I get an Invalid Number error on the service code field...which is alpha-numeric. WTF, right? How can Oracle throw a number error on a character column with no conversion functions on it? I know! It shouldn't! Does not compute!
For those of you who don't know...a good way to figure out what is wrong with an extensive query is to strip things out by commenting column lists, joins, etc until you get to something you know works right. I begin the process by dropping some tables from the query (NOTE: I did NOT drop tables from the schema - that's just a phrase for commenting things out) until I get something that works. Problem is, I never got something that worked.
Another good method for fixing a broken query is rewriting it from scratch - adding in more columns and tables until you get the desired result or recreate the issue. Hopefully by this time we are getting zeroed in on the problem and can formulate a plan of attack to fix the goddamn thing.
I start out with a single table and the query runs as expected. I add in a few more columns and joins and stuff and everything seems to be working. I get to the last little bit and boom. No dice. It doesn't make any sense. Service Code can contain numbers but should not be restricted to numeric only. And why the sometimes issue? Not sure.
I take another tack and create a few temp tables to simulate the joins in the query. It is basically the idea that if there is a problem when you join table a, table b and table c all at once, how about create table ab and then joining that to c. It may shine light on whatever the ultimate issue is.
So, after a few hours of investigation, false starts and curses hurled at a world that would birth an abomination like this, I discover the true issue. The start and end date parameters are passed as timestamp and in the query, a to-char wraps the end date but not the start date. When you convert a parameter in a query to a bind variable (by adding a ':' in front) and are passing date or timestamp, you can write the value in the default format to short circuit conversion. In this case the varchar2 value'01-AUG-2012' will implicitly convert to timestamp when the query runs. Since we are doing an inclusive range, we are converting the end date to character and adding in the time component of ' 23:59:59' and since the incoming parameter is timestamp when the procedure runs as normal we need to convert that timestamp to varchar2 to add in the time component. There was a superfluous to_char() on end date. Oracle somehow flagged service_code as the problem column. Wild goose chases ensues. Fun is had by all.
I blame: Oracle for misleading errors, the system for not working appropriately, all of the developers and managers that are no longer here to defend themselves, users that have the gall to use the system and expect results, the liberal media and right-wing bible-thumping fascists. Oh, and Apple. Steve Jobs was a dick.
So, the ultimate lesson to learn here is that the error you see may not be the real error. You could have a ninja error - pops in, fucks shit up. poof - disappears. You could also have a Fox News error. This is an error that points to other things that are fine as the issue. Fox News errors are totally oblivious of their own culpability in the matter and will argue against all evidence to the contrary. The bible says God exists. Problem, Athiests?
And so concludes my virginal foray into blogging. I hope to continue blogging but let's be realistic. All of that girl on girl action is not going to watch itself, now is it. We all have our priorities.
Subscribe to:
Comments (Atom)