He's at it again!!

FROM: Mr. Douche McManager
TO: <developers>
SUBJECT: New Code Conventions

In order to increase the readability of the code that you people are turning out, we're going to have to implement some new code conventions.  I'm no idiot and used to be able to hang with the best of them back when I was writing cobol, but this java shit is nearly incomprehensible.  I've talked with Larry ButtKisser and we've come up with some new code conventions that will increase readability and promote accountability.

* In-line documentation

  Every line of code should be preceded by at least 1 line of commentary.  The line should, at a minimum, contain the following: The loginID of every developer who has edited that line of code and a little note saying what that line does.  The more in-line documentation there is, the better.

* Deleting lines of code

  No more deleting lines of old code, they should always be commented out instead with in-line documentation on who did the commenting and why it was done and what is replacing it.

* Variable Naming

  All of these long descriptive variable names are just wasting space and making the program bloat.  From now on, use sensible names like x, y, or i.  If you must use longer names, try to keep to 5 characters and under.  Of course, the real meaning of any shortened variable name should be noted in the in-line documentation for clarity.

These 3 simple changes should make the code much easier to read and maintain.  You people need to get on the ball! We are way behind schedule and I need to understand why and these changes should help.

That is all,

Mr. McManager


{submitted by A. Slaev}

Le Sigh

It's times like these that I'm convinced that some developers have read too much Kafka, but then I remember that most developers are busy reading Wrox books and XKCD instead and have no time for irony.

{submitted by tdc}

System.Text.StringDestroyer

string mszErrorMessage = "Error: " + "An Error Occurred In the " + "module (" + aexLocalException.Source + ")." + "\r\nPlease report this " + "error " + "to a system administrator." + "\r\nYou may not recover from " + "here " + "and must start the function (" + aszFunctionName + ") " + "over from the beginning.";


My only thought is that the author of this concatalicious line of code is severely overbuilding (so that parts of this message could be replaced with variables in the future) or that they have been smacked in the forehead with a hammer a few times by someone who was singing the praises of System.Text.StringBuilder while administering said hammer taps.

RFC3251 - Electricity over IP

Network Working Group

B. Rajagopalan
Request for Comments: 3251

Tellium, Inc.
Category: Informational

1 April 2002

                          Electricity over IP

Status of this Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2002).  All Rights Reserved.

Abstract

   Mostly Pointless Lamp Switching (MPLampS) is an architecture for
   carrying electricity over IP (with an MPLS control plane).  According
   to our marketing department, MPLampS has the potential to
   dramatically lower the price, ease the distribution and usage, and
   improve the manageability of delivering electricity.  This document
   is motivated by such work as SONET/SDH over IP/MPLS (with apologies
   to the authors).  Readers of the previous work have been observed
   scratching their heads and muttering, "What next?".  This document
   answers that question.

   This document has also been written as a public service.  The "Sub-
   IP" area has been formed to give equal opportunity to those working
   on technologies outside of traditional IP networking to write
   complicated IETF documents.  There are possibly many who are
   wondering how to exploit this opportunity and attain high visibility.
   Towards this goal, we see the topics of "foo-over-MPLS" (or MPLS
   control for random technologies) as highly amenable for producing a
   countless number of unimplementable documents.  This document
   illustrates the key ingredients that go into producing any "foo-
   over-MPLS" document and may be used as a template for all such work.

Read The Full RFC Proposal here!

None more black

FROM: Mr. Douche McManager
TO: <developers>
SUBJECT: Wasting Color Toner


I told you people to watch our toner budget and no one listened to me, so, now we are going to have to take steps to ensure that the situation is fixed.  I've told all of you repeatedly that the color toner is expensive and needs to be saved for reports and not used on code submissions.  And yet I continuously get all of these code submissions that are in a bunch of colors!  Yesterday, DougDev told me that he "can't help it" because the IDE colors the text that way for readability.  So, it's the IDE's fault?  Fine.


Henceforth, Devs should only use Notepad for coding.  Anyone caught using the IDE will be written up.  When someone figures out a way to keep the IDE from printing in color, we can talk about switching back.


That is all,


Mr. McManager

{submitted by A. Slaev}

The Unknown Table

  I'm a new employee at a software company where I was asked to take a look at our production DB schema and suggest possible avenues for optimization.  They said that it would probably be useful to have a "fresh pair of eyes" looking there for anything they have missed.

  I checked with all of the other devs who had been there for a few years about this mystery table and was told to check the DB Schema documentation.  There was no reference to Table X, of course.  I told them it was a mystery and no one could seem to remember what it did (if anything).  Upon looking into it more closely, the table was found to have over 6 million rows containing sequential numbers.  This was taking up a good bit of space, so a decision was made to delete it.

WHOOPS!

  Deleting it crashed the application.  Nobody could log in at all.  And, of course, restoring the table fixed the problem.  We spent a week or so looking through the application code to find any references to Table X and there were none.  Another week was spent trying to diagnose the crashing problem at the DB level and that's where we found it...  Apparently, an intern from the community college had mistakenly used our production DB to learn SQL instead of doing it on the dev DB (about a year before I showed up).  He had written a update trigger on the login auditing table to insert a new integer into table X.  It only took an hour to fix the problem once found, but, it certainly taught us a lesson.

You pay for unpaid interns: one way or another.


{submitted by DW}

A Reliability Solution for ZIP Drives...

Remember ZIP drives?  Those 100Mb Floppies that were the rage for a few years?  Remember the click of death?

For those who don't, both the drives and the disks that went into them were notoriously flimsy, and they when they failed, it usually let you know by clicking once a second, on and on forever...  the drive was dead, your data was gone, your disk was killed.  Well, when you've got bored web devs who are always worried about the survivability of their ZIP data, what happens?

This happens...

RAID Level 1, my friends, on a pair of ZIP drives.  So, now, when you get the click of death, you can replace the disk (and maybe the drive if it co-failed) and get your data back!  Thank god they invented USB Flash Drives a few years later...

{submitted by El}

Analytics = Hilarity

Google Analytics...  how I love thee!  Here's what analytics says you guys are using to find us here at "I can has Dev Job".

So, of course the #7 most frequent search term is "a job for a turd"; how could it not be?


Anyone else have some analytics hilarity to share?

Data Overload

/// <summary>

/// orderData class contains data for the order object
/// </summary>
public class orderData  
{
    public int orderDataID { get; private set; }
    public int orderDataDataID { get; private set; }
    public int orderDataMetaDataID { get; private set; }
    public int orderDataDataDataID { get; private set; }


    private string orderDataDataSetDataSource;
    public DataSet orderDataDataSet { get; private set; }


    private string orderDataDataTableDataSource;
    public DataTable orderDataDataTable { get; private set; }
    

  public orderData(int _orderDataID)
  {
        // connect to the DB
        and so on...

I wonder if this was an e-commerce application for Sally's SeaShells (which she sells by the sea shore) or for Peter Piper's Picked Pickled Peppers inc.?

The Doohick won't plug into the thingee...

  Years ago, I was working in the service department of our local computer shop and a man came in wanting to buy a monitor.  The salesmen were "too busy" to take care of "simple" (read as "low margin") sales like that (although they were first in line to sell a customer a cable).  At this time, VGA (running at 640x480) was common place (but only just) and it was, in fact, all we had in stock.

  The man was white-haired with a white beard and he was sort of a squirrelly non-talkative type.  Without much fuss, I sold him the monitor and went back to fixing computers.  He called about an hour later.

  "How can I help you, sir?"  I asked.

  "Well, the doohick won't plug into the thingee.  I starts to go, but then it stops short of being all the way plugged in."

  Beginning to suspect that the monitor pins might be bent - it was the only thing that sprang to mind that would prevent a monitor cable from going all the way in - I continued, "Okay, now, which is the doohick and which is the thingee?"

  He paused for a moment.  "The doohick you sold me won't plug into the thingee on the computer."

  "Gotcha.  Okay, can you look at the end of the plug of the doohick, sir?"

  "Sure, I see it, there's little doodads in there."

  "Yes, sir, those are called pins.  Are they bent?"

  "Are the doodads bent?  Naw, I can see most of 'em and they look straight."

  We went on for a while longer, I got him to look at the thingee on the computer to see if anything was in - or blocking - the holes.  No luck.  Finally, I asked him to bring both the doohick and the thingee in for me to look at.

  The next day, the man showed up with the doohick and the thingee.  I pulled out the doohick (the monitor) and looked at it...  The doodads (the pins) were, in fact, bent.  But I could see how a layman would say they weren't.  The 15 individual doodads, themselves, were still straight - as in they were uncurved - but they had been pushed together into a few teepee like structures.  Curious, I checked the computer...

  *boggle* I didn't even know Epson made computers.  He said he had bought it in Argentina for a really good price.  It had an 8088 processor, a pair of 5.25" floppies, no hard drive, and CGA graphics.    And therein lay the problem.  CGA used a 9-pin port and I had sold him a 15-pin VGA monitor.  He had been forcing the 15-pin plug into the 9-pin port and had teepeed all of the pins into the 9 available holes.  I apologized and tried to sell him a CGA monitor, but, he said they were too expensive (and he was right).

Ed: Exactly who's brilliant idea was it to take an existing plug form-factor and add 6 more pins to it.  When old graphics and serial ports were abundant, this kind of thing happened *all the time*.  I can't wait until someone designs a new USB port that happens to be a similar size to HDMI or something and the fun starts all over again.