• Ã (unregistered) in reply to RichP
    RichP:
    It was probably a <10M plain text log file before the Exchange server got ahold of it and decided to turn it into HTML.

    I'll won't hijack the thread with my horror story on the topic.

    It hasn't stopped Nagesh.

  • TW (unregistered) in reply to Nkokot
    Nkokot:
    Looks like the Safety and Health IT (S H IT) is doing what their acronym tells...

    Oh! NOW I get it.

  • Seth (unregistered) in reply to Bastiaan van Zwieten
    Bastiaan van Zwieten:
    Seth:
    What Brian should have done was attach the log file to the heartbeat message, and then he wouldn't have to go through the operations department the next time something like this happens. Yes, I said "something like this." Cue the frits-bot in 3...2...1...

    Seriously? Another way to clogg up the pipes!

    Maybe receive a summary by mail, because entire logfiles can be BIG.

    TFA clearly state's that Brian's process was a "simple little app read records off of a flat-file on the mainframe and sent it to the "Product Management Services" database". How exactly does a simple little app generate massive log files?

  • Ã (unregistered) in reply to Seth
    Seth:
    TFA clearly state's that Brian's process was a "simple little app read records off of a flat-file on the mainframe and sent it to the "Product Management Services" database". How exactly does a simple little app generate massive log files?
    Given the initial trouble he had, in addition to the heartbeat email it sent him every night to confirm it ran, he had designed the application to generate a painfully verbose log file.
  • Pervert (unregistered) in reply to Seth
    Seth:
    TFA clearly state's that Brian's process was a "simple little app read records off of a flat-file on the mainframe and sent it to the "Product Management Services" database". How exactly does a simple little app generate massive log files?
    20110225094523: Keystroke received from /dev/USB/1/: B
20110225094524: Keystroke received from /dev/USB/1/: e
20110225094525: Keystroke received from /dev/USB/1/: c
20110225094526: Keystroke received from /dev/USB/1/: a
20110225094527: Keystroke received from /dev/USB/1/: u
20110225094528: Keystroke received from /dev/USB/1/: s
20110225094529: Keystroke received from /dev/USB/1/: e
20110225094530: Keystroke received from /dev/USB/1/:  
20110225094531: Keystroke received from /dev/USB/1/: h
20110225094532: Keystroke received from /dev/USB/1/: e
20110225094533: Keystroke received from /dev/USB/1/: '
20110225094534: Keystroke received from /dev/USB/1/: s
20110225094535: Keystroke received from /dev/USB/1/:  
20110225094536: Keystroke received from /dev/USB/1/: b
20110225094537: Keystroke received from /dev/USB/1/: o
20110225094538: Keystroke received from /dev/USB/1/: g
20110225094539: Keystroke received from /dev/USB/1/: g
20110225094540: Keystroke received from /dev/USB/1/: e
20110225094541: Keystroke received from /dev/USB/1/: d
20110225094542: Keystroke received from /dev/USB/1/:  
20110225094543: Keystroke received from /dev/USB/1/: d
20110225094544: Keystroke received from /dev/USB/1/: o
20110225094545: Keystroke received from /dev/USB/1/: w
20110225094546: Keystroke received from /dev/USB/1/: n
20110225094547: Keystroke received from /dev/USB/1/:  
20110225094548: Keystroke received from /dev/USB/1/: i
20110225094549: Keystroke received from /dev/USB/1/: n
20110225094550: Keystroke received from /dev/USB/1/:  
20110225094551: Keystroke received from /dev/USB/1/: l
20110225094552: Keystroke received from /dev/USB/1/: o
20110225094553: Keystroke received from /dev/USB/1/: g
20110225094554: Keystroke received from /dev/USB/1/: g
20110225094555: Keystroke received from /dev/USB/1/: i
20110225094556: Keystroke received from /dev/USB/1/: n
20110225094557: Keystroke received from /dev/USB/1/: g
  • Kloro (unregistered) in reply to Seth
    Seth:
    TFA clearly state's that Brian's process was a "simple little app read records off of a flat-file on the mainframe and sent it to the "Product Management Services" database". How exactly does a simple little app generate massive log files?

    Simple little app dealing with large quantities of data.

  • (cs) in reply to Kloro
    Kloro:
    Seth:
    TFA clearly state's that Brian's process was a "simple little app read records off of a flat-file on the mainframe and sent it to the "Product Management Services" database". How exactly does a simple little app generate massive log files?

    Simple little app dealing with large quantities of data.

    Or doing simple tasks thousands or millions of times a day.

  • (cs) in reply to Seth
    Seth:
    TFA clearly state's that Brian's process was a "simple little app read records off of a flat-file on the mainframe and sent it to the "Product Management Services" database". How exactly does a simple little app generate massive log files?
    Who cares about that? I want to know WhoTF Brian thinks he is taking credit for Rick's app.
  • Charles Duffy (unregistered) in reply to Nagesh
    Nagesh:
    I never think of this as a WTF, though.

    If you don't have an easy way to tell where everything is, it's a WTF.

    I'm a DevOps type -- and all the infrastructure I deploy has a query interface; you can easily ask for "role:memcache" or "role:cluster_foo" and get a list of who's where. Moreover, we have central log shipping and management, and our developers (who don't have access to the production servers themselves) can query those logs without help.

    ...so yeah, not having any documentation or query interface or centralized logging, and relying on just one person who knows where everything is (and trusting that they won't get fired / quit / get hit by a bus) is very much a WTF.

  • (cs) in reply to TGV
    TGV:
    Where's the WTF?
    Mostly in the commented-out parts, particularly at the end:
    Remy Porter:
    Postscript: And then, after all this crap, Rick's NEW PMS-integration application was scheduled to go-live. He wrote it and had it ready for production six months ago. S&H IT didn't get a chance to look at it for most of that six months. He warned them that he was going to take the last week of November off. Two months later (he planned way ahead), they scheduled the go-live- for the Monday of his week off. And then, during his week off, nobody actually checks the data until Friday, and WHOOPS! They mapped columns wrong.

    AND THEN the app goes into production, runs that way for six weeks. A few minor bugs are found, fixed, passed to UAT, and promoted to production. And suddenly? "HOLY CRAP, THIS APPLICATION IS TOTALLY WRONG! STOP RUNNING IT IN PRODUCTION!"

  • Gary Olson (unregistered) in reply to boog
    boog:
    ....leave Subversion log messages blank on commits - every time).

    One solution would be to tie these programmers' hands to their chairs. Another would be shock collars.

    Better solution ... they don't feed the SVN, you don't feed the developer. Hunger will make a person pay attention to the important details.

  • Gunslinger (unregistered) in reply to Dan
    Dan:
    Seth:
    What Brian should have done was attach the log file to the heartbeat message, and then he wouldn't have to go through the operations department the next time something like this happens. Yes, I said "something like this." Cue the frits-bot in 3...2...1...

    A 750M log file? Every day?

    No, moron. You only email the daily log not the complete log.

    CAPTCHA - opto: It's opto whether you then delete the log file once you email it and only store a daily log.

  • (cs) in reply to Nagesh
    Nagesh:
    NOT the original:
    Nagesh:
    Hasteur:
    And this kids is why you document the hell out of everything that goes on with your code. When it comes time to figure out what's going on and where your application is you hold up your signed deployment document along with your phone so that the systems people can call your boss and explain that the location they claimed they installed the application is not where they "did" install the application.

    Yes it passes the buck, but by this point you've sorted through 5 layers of BS and you're not taking the blame.

    Good point! Documentation is essential. That's how we got CMM 5 certification. We have also documented the number of allowable bathroom breaks that employees can have in a shift.

    I like this new Nagesh... He's funnier, and not, um, retarded.

    Your opinion though important is completely irelevant. Love, Nagesh.

    And his Indlish is nice, too

  • (cs) in reply to Seth
    Seth:
    Bastiaan van Zwieten:
    Seth:
    What Brian should have done was attach the log file to the heartbeat message, and then he wouldn't have to go through the operations department the next time something like this happens. Yes, I said "something like this." Cue the frits-bot in 3...2...1...

    Seriously? Another way to clogg up the pipes!

    Maybe receive a summary by mail, because entire logfiles can be BIG.

    TFA clearly state's that Brian's process was a "simple little app read records off of a flat-file on the mainframe and sent it to the "Product Management Services" database". How exactly does a simple little app generate massive log files?

    Could it be XML?

  • (cs) in reply to Nagesh

    Real programmers don't use log files. Real programmers use core dumps.

  • Kempeth (unregistered)

    Wouldn't it have been faster to just search one server after another than to run after those IT guys? Surely in three days you can go over quite a few servers...

    They searched Server 1, 7, 2, 5 and probably 3 before finding it on 4. They could have saved them self a lot of running around.

    Also 700KB of logs per day? Respect...

  • (cs)

    I'm doing science and I'm still alive. Still alive, Still alive.

  • (cs) in reply to Pr0gramm3r
    Pr0gramm3r:
    Real programmers don't use log files. Real programmers use core dumps.

    Sounds like Software Health IT good practice indeed: every morning after the coffee, you dump a core and attach it to an email you send to the whole company. Or you wrap it in a nice xls file and put it right there one the corporate Sharepoint where everyone can see it.

  • SG_01 (unregistered) in reply to boog
    boog:
    "Oh, that application? Yeah, it's been getting bounced between servers as we need to..."
    I'm not sure what compels some people to do what they do. Really? You need to bounce this application between servers? Why?

    I worked on a project with people like this for a while. No applications floating from server to server (at least not this bad), but several people would arbitrarily jump in and make major changes without telling anyone (they'd even leave Subversion log messages blank on commits - every time). Something would break, and after figuring it out we still wouldn't know what drove the programmer to make the change they did. It's as if they just "felt like it".

    One solution would be to tie these programmers' hands to their chairs. Another would be shock collars.

    Another solution is mandatory log-messages (SVN has an option to have a minimum number of characters), or a commit-hook that checks the log message formatting :)

  • Shea (unregistered)

    All of this is well and good, but as a best practice when dealing with potentially large logs, the app should roll the log over to a new file once per day. Then you can keep 30 days worth of log files and never worry about them.

    The rest, well, sounds like process for process sake. Why have all the bureaucracy if, in the end, nothing is documented adequately, and you have to call the only guy (a single point of failure) that knows where the documentation and program is?

    If you're going to fly by the seat of your pants, you might as well get rid of the rest of the process-for-process-sake. It exists for a reason and needs to be followed by everyone, or don't waste your time.

    JM2c,

    Shea

  • Andrew Brehm (unregistered) in reply to TGV

    The WTF is writing an application whose log messages or "I am alive" messages did not include a server name in the first place. Every time I see a "could not connect to database server" message I curse at the developer who didn't make the application spit out the name of the server it thinks it has to connect to.

  • trwtf (unregistered) in reply to Andrew Brehm
    Andrew Brehm:
    The WTF is writing an application whose log messages or "I am alive" messages did not include a server name in the first place.
    Bullshit, logging the server name was not in the original requirements and good coders do not arbitrarily implement non-existent requirements as they feel like it. Your dumbass opinion is TRWTF.
  • Havelock (unregistered) in reply to Dan
    Dan:
    From one of my intra-office emails (addresses changed to protect the guilty): Received: from SMTPSERVER4 ([1.2.3.4]) by SMTPSERVER1 ([1.2.3.1]) with mapi; Wed, 23 Feb 2011 10:17:48 -0700

    This is all the routing information I got from this message. No indication of the client machine that originated the message.

    IIRC, exchange does add proper received headers for messages received via SMTP, not via crazy-activesync-connection.

  • (cs)

    Who doesn't think to include the machine name in their status and exception emails? Oh well, lesson learned.

  • (cs) in reply to trwtf
    trwtf:
    Andrew Brehm:
    The WTF is writing an application whose log messages or "I am alive" messages did not include a server name in the first place.
    Bullshit, logging the server name was not in the original requirements and good coders do not arbitrarily implement non-existent requirements as they feel like it. Your dumbass opinion is TRWTF.
    You are insane and TRWTF. No one ever had to tell me to put the client machine name in my status and exception messages; it's so blindingly fucking obvious that it goes without saying.
  • (cs) in reply to Nagesh
    Nagesh:
    NOT the original:
    Nagesh:
    Hasteur:
    And this kids is why you document the hell out of everything that goes on with your code. When it comes time to figure out what's going on and where your application is you hold up your signed deployment document along with your phone so that the systems people can call your boss and explain that the location they claimed they installed the application is not where they "did" install the application.

    Yes it passes the buck, but by this point you've sorted through 5 layers of BS and you're not taking the blame.

    Good point! Documentation is essential. That's how we got CMM 5 certification. We have also documented the number of allowable bathroom breaks that employees can have in a shift.

    I like this new Nagesh... He's funnier, and not, um, retarded.

    Your opinion though important is completely irelevant. Love, Nagesh.

    His opinion is interesting, unlike your petty, mis-directed revenge for being reminded yesterday that we don't care what your C++ professor from high school told you. Every one of us is probably a better C++ programmer than that asshat anyway.

  • (cs) in reply to Charles Duffy
    Charles Duffy:
    Nagesh:
    I never think of this as a WTF, though.

    If you don't have an easy way to tell where everything is, it's a WTF.

    I'm a DevOps type -- and all the infrastructure I deploy has a query interface; you can easily ask for "role:memcache" or "role:cluster_foo" and get a list of who's where. Moreover, we have central log shipping and management, and our developers (who don't have access to the production servers themselves) can query those logs without help.

    ...so yeah, not having any documentation or query interface or centralized logging, and relying on just one person who knows where everything is (and trusting that they won't get fired / quit / get hit by a bus) is very much a WTF.

    I was actually hired and put in management for the sole purpose of being a human UPS in case my boss gets hit by a truck or wins the Powerball. This was considered superior to documentation.

  • (cs) in reply to Pervert
    Pervert:
    Seth:
    TFA clearly state's that Brian's process was a "simple little app read records off of a flat-file on the mainframe and sent it to the "Product Management Services" database". How exactly does a simple little app generate massive log files?
    20110225094523: Keystroke received from /dev/USB/1/: B
20110225094524: Keystroke received from /dev/USB/1/: e
20110225094525: Keystroke received from /dev/USB/1/: c
20110225094526: Keystroke received from /dev/USB/1/: a
20110225094527: Keystroke received from /dev/USB/1/: u
20110225094528: Keystroke received from /dev/USB/1/: s
20110225094529: Keystroke received from /dev/USB/1/: e
20110225094530: Keystroke received from /dev/USB/1/:  
20110225094531: Keystroke received from /dev/USB/1/: h
20110225094532: Keystroke received from /dev/USB/1/: e
20110225094533: Keystroke received from /dev/USB/1/: '
20110225094534: Keystroke received from /dev/USB/1/: s
20110225094535: Keystroke received from /dev/USB/1/:  
20110225094536: Keystroke received from /dev/USB/1/: b
20110225094537: Keystroke received from /dev/USB/1/: o
20110225094538: Keystroke received from /dev/USB/1/: g
20110225094539: Keystroke received from /dev/USB/1/: g
20110225094540: Keystroke received from /dev/USB/1/: e
20110225094541: Keystroke received from /dev/USB/1/: d
20110225094542: Keystroke received from /dev/USB/1/:  
20110225094543: Keystroke received from /dev/USB/1/: d
20110225094544: Keystroke received from /dev/USB/1/: o
20110225094545: Keystroke received from /dev/USB/1/: w
20110225094546: Keystroke received from /dev/USB/1/: n
20110225094547: Keystroke received from /dev/USB/1/:  
20110225094548: Keystroke received from /dev/USB/1/: i
20110225094549: Keystroke received from /dev/USB/1/: n
20110225094550: Keystroke received from /dev/USB/1/:  
20110225094551: Keystroke received from /dev/USB/1/: l
20110225094552: Keystroke received from /dev/USB/1/: o
20110225094553: Keystroke received from /dev/USB/1/: g
20110225094554: Keystroke received from /dev/USB/1/: g
20110225094555: Keystroke received from /dev/USB/1/: i
20110225094556: Keystroke received from /dev/USB/1/: n
20110225094557: Keystroke received from /dev/USB/1/: g
    You're almost there, but you need a GUID. Natural keys, such as timestamps, can change after all.
  • (cs) in reply to RichP
    RichP:
    It was probably a <10M plain text log file before the Exchange server got ahold of it and decided to turn it into HTML.

    I'll won't hijack the thread with my horror story on the topic.

    I want to hear it! I demand a Sidebar WTF! Please?

  • (cs) in reply to Nagesh
    Nagesh:
    Ouch!:
    TRWTF is log files. For real.

    I guess you are not programmer.

    He probably uses the built-in system log on whatever machine he deploys to. TRWTF is re-writing functionality already included in the operating system.

  • frits (unregistered) in reply to boog
    boog:
    "Oh, that application? Yeah, it's been getting bounced between servers as we need to..."
    I'm not sure what compels some people to do what they do. Really? You need to bounce this application between servers? Why?

    I worked on a project with people like this for a while. No applications floating from server to server (at least not this bad), but several people would arbitrarily jump in and make major changes without telling anyone (they'd even leave Subversion log messages blank on commits - every time). Something would break, and after figuring it out we still wouldn't know what drove the programmer to make the change they did. It's as if they just "felt like it".

    One solution would be to tie these programmers' hands to their chairs. Another would be shock collars.

    I'm pretty sure both of these are firable and prisonable offenses. I'd hate to meet you in real life, boog. You sound like a complete asshole. Your not too smart, are you?

  • frits (unregistered) in reply to hoodaticus
    hoodaticus:
    Who doesn't think to include the machine name in their status and exception emails? Oh well, lesson learned.
    Who hasn't thought about including something like this?
  • Purge the Hood (unregistered) in reply to hoodaticus
    hoodaticus:
    Nagesh:
    NOT the original:
    Nagesh:
    Hasteur:
    And this kids is why you document the hell out of everything that goes on with your code. When it comes time to figure out what's going on and where your application is you hold up your signed deployment document along with your phone so that the systems people can call your boss and explain that the location they claimed they installed the application is not where they "did" install the application.

    Yes it passes the buck, but by this point you've sorted through 5 layers of BS and you're not taking the blame.

    Good point! Documentation is essential. That's how we got CMM 5 certification. We have also documented the number of allowable bathroom breaks that employees can have in a shift.

    I like this new Nagesh... He's funnier, and not, um, retarded.

    Your opinion though important is completely irelevant. Love, Nagesh.

    His opinion is interesting, unlike your petty, mis-directed revenge for being reminded yesterday that we don't care what your C++ professor from high school told you. Every one of us is probably a better C++ programmer than that asshat anyway.
    TROLL-FEEDER!

    Stop. Your doing it on purpose.

  • trwtf (unregistered) in reply to hoodaticus
    hoodaticus:
    trwtf:
    Andrew Brehm:
    The WTF is writing an application whose log messages or "I am alive" messages did not include a server name in the first place.
    Bullshit, logging the server name was not in the original requirements and good coders do not arbitrarily implement non-existent requirements as they feel like it. Your dumbass opinion is TRWTF.
    You are insane and TRWTF. No one ever had to tell me to put the client machine name in my status and exception messages; it's so blindingly fucking obvious that it goes without saying.
    I work safety critical (commercial/military flight controllers) and I stand by my practices. In my business, if you don't have the discipline to follow the specs to the letter then there's a very real risk that people will die. Hoody, for the love of God don't ever go into aerospace.
  • hoodaticus (unregistered) in reply to trwtf
    trwtf:
    hoodaticus:
    trwtf:
    Andrew Brehm:
    The WTF is writing an application whose log messages or "I am alive" messages did not include a server name in the first place.
    Bullshit, logging the server name was not in the original requirements and good coders do not arbitrarily implement non-existent requirements as they feel like it. Your dumbass opinion is TRWTF.
    You are insane and TRWTF. No one ever had to tell me to put the client machine name in my status and exception messages; it's so blindingly fucking obvious that it goes without saying.
    I work safety critical (commercial/military flight controllers) and I stand by my practices. In my business, if you don't have the discipline to follow the specs to the letter then there's a very real risk that people will die. Hoody, for the love of God don't ever go into aerospace.
    rite, because we all know that government contractors never make mistakes.
  • HighlyLaidContractor (unregistered) in reply to trwtf
    trwtf:
    hoodaticus:
    trwtf:
    Andrew Brehm:
    The WTF is writing an application whose log messages or "I am alive" messages did not include a server name in the first place.
    Bullshit, logging the server name was not in the original requirements and good coders do not arbitrarily implement non-existent requirements as they feel like it. Your dumbass opinion is TRWTF.
    You are insane and TRWTF. No one ever had to tell me to put the client machine name in my status and exception messages; it's so blindingly fucking obvious that it goes without saying.
    I work safety critical (commercial/military flight controllers) and I stand by my practices. In my business, if you don't have the discipline to follow the specs to the letter then there's a very real risk that people will die. Hoody, for the love of God don't ever go into aerospace.
    Aren't you just a technical writer? Because that sounds like a typical oversimplified technical writer POV.
  • powerload (unregistered) in reply to Purge the Hood
    Purge the Hood:
    hoodaticus:
    Nagesh:
    NOT the original:
    Nagesh:
    Hasteur:
    And this kids is why you document the hell out of everything that goes on with your code. When it comes time to figure out what's going on and where your application is you hold up your signed deployment document along with your phone so that the systems people can call your boss and explain that the location they claimed they installed the application is not where they "did" install the application.

    Yes it passes the buck, but by this point you've sorted through 5 layers of BS and you're not taking the blame.

    Good point! Documentation is essential. That's how we got CMM 5 certification. We have also documented the number of allowable bathroom breaks that employees can have in a shift.

    I like this new Nagesh... He's funnier, and not, um, retarded.

    Your opinion though important is completely irelevant. Love, Nagesh.

    His opinion is interesting, unlike your petty, mis-directed revenge for being reminded yesterday that we don't care what your C++ professor from high school told you. Every one of us is probably a better C++ programmer than that asshat anyway.
    TROLL-FEEDER!

    Stop. Your doing it on purpose.

    Says a member of a group of twenty-something virgins who sit on IRC and take turns trolling SO and TDWTF comments.

  • Christian (unregistered)

    S&H IT folks sounds like shit folks

  • Andrew Brehm (unregistered) in reply to trwtf
    trwtf:
    I work safety critical (commercial/military flight controllers) and I stand by my practices. In my business, if you don't have the discipline to follow the specs to the letter then there's a very real risk that people will die. Hoody, for the love of God don't ever go into aerospace.

    In which country do you work?

    Learning that you guys won't know which particular server sent an error when you receive the message isn't exactly reassuring.

  • trwtf (unregistered) in reply to HighlyLaidContractor
    HighlyLaidContractor:
    trwtf:
    hoodaticus:
    trwtf:
    Andrew Brehm:
    The WTF is writing an application whose log messages or "I am alive" messages did not include a server name in the first place.
    Bullshit, logging the server name was not in the original requirements and good coders do not arbitrarily implement non-existent requirements as they feel like it. Your dumbass opinion is TRWTF.
    You are insane and TRWTF. No one ever had to tell me to put the client machine name in my status and exception messages; it's so blindingly fucking obvious that it goes without saying.
    I work safety critical (commercial/military flight controllers) and I stand by my practices. In my business, if you don't have the discipline to follow the specs to the letter then there's a very real risk that people will die. Hoody, for the love of God don't ever go into aerospace.
    Aren't you just a technical writer? Because that sounds like a typical oversimplified technical writer POV.
    Senior software engineer and team lead, since you're so interested.
  • trwtf (unregistered) in reply to Andrew Brehm
    Andrew Brehm:
    trwtf:
    I work safety critical (commercial/military flight controllers) and I stand by my practices. In my business, if you don't have the discipline to follow the specs to the letter then there's a very real risk that people will die. Hoody, for the love of God don't ever go into aerospace.

    In which country do you work?

    I bounce between UK, France, Germany and Italy (EADS).

  • HighlyLaidContractor (unregistered) in reply to trwtf
    trwtf:
    HighlyLaidContractor:
    trwtf:
    hoodaticus:
    trwtf:
    Andrew Brehm:
    The WTF is writing an application whose log messages or "I am alive" messages did not include a server name in the first place.
    Bullshit, logging the server name was not in the original requirements and good coders do not arbitrarily implement non-existent requirements as they feel like it. Your dumbass opinion is TRWTF.
    You are insane and TRWTF. No one ever had to tell me to put the client machine name in my status and exception messages; it's so blindingly fucking obvious that it goes without saying.
    I work safety critical (commercial/military flight controllers) and I stand by my practices. In my business, if you don't have the discipline to follow the specs to the letter then there's a very real risk that people will die. Hoody, for the love of God don't ever go into aerospace.
    Aren't you just a technical writer? Because that sounds like a typical oversimplified technical writer POV.
    Senior software engineer and team lead, since you're so interested.

    Well, eeexcuuuuse meeeeee. Don't most job descriptions for senior software engineers have a bullet that reads something like "a wide degree of creativity and latitude is expected"?

    BTW- I'm pretty sure implying prtinting the hostname of a machine in a log file that you most like designed yourself will not cause death. I'm also pretty sure that implying it would is some sort of logical fallacy.

  • (cs) in reply to SG_01
    SG_01:
    boog:
    I worked on a project with people like this for a while. No applications floating from server to server (at least not this bad), but several people would arbitrarily jump in and make major changes without telling anyone (they'd even leave Subversion log messages blank on commits - every time). Something would break, and after figuring it out we still wouldn't know what drove the programmer to make the change they did. It's as if they just "felt like it".

    One solution would be to tie these programmers' hands to their chairs. Another would be shock collars.

    Another solution is mandatory log-messages (SVN has an option to have a minimum number of characters), or a commit-hook that checks the log message formatting :)
    True, those solutions certainly would work if I had access to make those changes to the repository. But the sysadmins who would have had to do it were some of the above-mentioned people arbitrarily breaking configs; if I asked (or was able to convince) them to do it, they probably would have broken it.

  • (cs) in reply to frits
    frits (cheap imitation):
    boog:
    One solution would be to tie these programmers' hands to their chairs. Another would be shock collars.
    I'm pretty sure both of these are firable and prisonable offenses. I'd hate to meet you in real life, boog. You sound like a complete asshole.
    It's not a firable offense if it's company policy. Gee, what was your first clue?
  • Red Phoenix (unregistered) in reply to HighlyLaidContractor
    HighlyLaidContractor:
    trwtf:
    HighlyLaidContractor:
    trwtf:
    hoodaticus:
    trwtf:
    Andrew Brehm:
    The WTF is writing an application whose log messages or "I am alive" messages did not include a server name in the first place.
    Bullshit, logging the server name was not in the original requirements and good coders do not arbitrarily implement non-existent requirements as they feel like it. Your dumbass opinion is TRWTF.
    You are insane and TRWTF. No one ever had to tell me to put the client machine name in my status and exception messages; it's so blindingly fucking obvious that it goes without saying.
    I work safety critical (commercial/military flight controllers) and I stand by my practices. In my business, if you don't have the discipline to follow the specs to the letter then there's a very real risk that people will die. Hoody, for the love of God don't ever go into aerospace.
    Aren't you just a technical writer? Because that sounds like a typical oversimplified technical writer POV.
    Senior software engineer and team lead, since you're so interested.

    Well, eeexcuuuuse meeeeee. Don't most job descriptions for senior software engineers have a bullet that reads something like "a wide degree of creativity and latitude is expected"?

    BTW- I'm pretty sure implying prtinting the hostname of a machine in a log file that you most like designed yourself will not cause death. I'm also pretty sure that implying it would is some sort of logical fallacy.

    Putting the host name of the machine in the log file won't help you find out which machine the log file is on. So I guess you actually meant "including the hostname of the machine in the email" - which is a good idea in hindsight.

    If, however, you expect your app to be installed and run on a specific named server, and you don't expect it to be moved without notification, then adding the hostname to the email just wouldn't seem a particularly necessary thing to do.

  • HighlyLaidContractor (unregistered) in reply to Red Phoenix
    Red Phoenix:
    HighlyLaidContractor:
    trwtf:
    HighlyLaidContractor:
    trwtf:
    hoodaticus:
    trwtf:
    Andrew Brehm:
    The WTF is writing an application whose log messages or "I am alive" messages did not include a server name in the first place.
    Bullshit, logging the server name was not in the original requirements and good coders do not arbitrarily implement non-existent requirements as they feel like it. Your dumbass opinion is TRWTF.
    You are insane and TRWTF. No one ever had to tell me to put the client machine name in my status and exception messages; it's so blindingly fucking obvious that it goes without saying.
    I work safety critical (commercial/military flight controllers) and I stand by my practices. In my business, if you don't have the discipline to follow the specs to the letter then there's a very real risk that people will die. Hoody, for the love of God don't ever go into aerospace.
    Aren't you just a technical writer? Because that sounds like a typical oversimplified technical writer POV.
    Senior software engineer and team lead, since you're so interested.

    Well, eeexcuuuuse meeeeee. Don't most job descriptions for senior software engineers have a bullet that reads something like "a wide degree of creativity and latitude is expected"?

    BTW- I'm pretty sure implying prtinting the hostname of a machine in a log file that you most like designed yourself will not cause death. I'm also pretty sure that implying it would is some sort of logical fallacy.

    Putting the host name of the machine in the log file won't help you find out which machine the log file is on. So I guess you actually meant "including the hostname of the machine in the email" - which is a good idea in hindsight.

    If, however, you expect your app to be installed and run on a specific named server, and you don't expect it to be moved without notification, then adding the hostname to the email just wouldn't seem a particularly necessary thing to do.

    The log file could have been hardcoded to a specific file server. It seems likely in this case, since they didn't have to retrieve multiple log files.

  • Nagesh (unregistered)
    NOT the original:
    Nagesh:
    Good point! Documentation is essential. That's how we got CMM 5 certification. We have also documented the number of allowable bathroom breaks that employees can have in a shift.

    I like this new Nagesh... He's funnier, and not, um, retarded.

    That is racist comment and unfair. There are now over 100 Nagesh in our company, and only 87 are retarded. We all take turns posting and working on code so we can do much more work than lazy USA programmers. That Nagesh is in bathroom right now so I am posting instead. I must remember to document it.

    I only have one more bathroom break allowed today, it will have to last me another 7 hours. Last week I had a bad curry and had to use my rubbish bin because I could not use the bathroom any more. But I coded a record amount! The company owners were so impressed they are going to start installing toilets in cubicles now so we can get even more work done and never have to leave! Soon we will drive all the USA coders out of business, they will never be able to compete with us!

    Nagesh:
    So Long did I wait. I go to have snack and now you post this article. ;)
    You went to snack at work? I am reporting you!
  • (cs) in reply to trwtf
    trwtf:
    Andrew Brehm:
    The WTF is writing an application whose log messages or "I am alive" messages did not include a server name in the first place.
    Bullshit, logging the server name was not in the original requirements and good coders do not arbitrarily implement non-existent requirements as they feel like it. Your dumbass opinion is TRWTF.

    Oh hello there, you must be a manager.

  • (cs) in reply to trwtf
    trwtf:
    Andrew Brehm:
    trwtf:
    I work safety critical (commercial/military flight controllers) and I stand by my practices. In my business, if you don't have the discipline to follow the specs to the letter then there's a very real risk that people will die. Hoody, for the love of God don't ever go into aerospace.

    In which country do you work?

    I bounce between UK, France, Germany and Italy (EADS).

    Aha, all makes sense now. "Eugh, we don't want him." (boot) "Zut, il est un poop du nincom, nous ne le voulons pas ..." (boot) "Achtung, ein scheisskopf!" (boot) "Argh, va fan culo ..." (boot) ... etc.

  • Pragmatist (unregistered) in reply to Nagesh

    You really should think of it as a WTF I'm afraid.

    You can point your /network/admin directory at a shared location using environment variables, and have as many people as you want share the same sqlnet.ora and tnsnames.ora.

    None of that will prevent TRWTF being Oracle of course though

Leave a comment on “Dropping a Log”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article