• Global (unregistered)

    Globalization is the future Frist

  • Andreas (unregistered)

    The next WTF is that you do not need to initialize out-parameters before calling a method. You cannot access the values inside the method anyway.

  • hoodaticus (cs)

    Procedural coders should be banned from .NET development.

    When Visual Studio starts up, it should require you to implement an OO design pattern in a mini-game. If you win, Visual Studio won't uninstall itself, delete all your projects, and revoke your license.

  • ObiWayneKenobi (cs)

    Sounds like some of the code I have to deal with. If it's not a class with nothing but static methods (used in moderation that's fine, all over the place not so much), Hungarian notation and weird naming conventions in C#, it's passing strings as output parameters to methods, usually for error messages.

    Sometimes I wonder. My co-workers are smart people, but I can't fathom that some of them write code like it was old crufty VB6 or worse and never once think there's a better way to do it.

    Addendum (2011-09-28 10:14): The worst part of all is trying to mention this (i.e. better ways) or say that we need to have unit testing (as opposed to manual testing) gets a scoff and a "We don't have time to do that" kind of reply...

  • TheSHEEEP (cs) in reply to hoodaticus
    hoodaticus:
    Procedural coders should be banned from .NET development.

    They should be banned from pretty much anything. Just to be sure.

    Except crochet.

  • hoodaticus (cs) in reply to ObiWayneKenobi
    ObiWayneKenobi:
    If it's not a class with nothing but static methods (used in moderation that's fine, all over the place not so much)
    I wouldn't permit static classes unless there is a damn good justification. Too many people in the hiring pool need to be deprived of their crutch if they are to learn anything.
  • Jellineck (unregistered)

    That's what happens when you get ASP developers trying to migrate code to ASP.NET without actually understanding ASP.NET.

  • Bradley (unregistered) in reply to hoodaticus

    [quote user="hoodaticus"]s fine, all over the place not so much)[/quote]I wouldn't permit static classes unless there is a damn good justification. Too many people in the hiring pool need to be deprived of their crutch if they are to learn anything.[/quote]

    They will just move on to singletons. For every crutch you take away, another will be found.

  • frits (cs)

    Well duh. Everybody knows that using bools is short-sighted. That method should return a enumeration like the following:

    public enum TestResult
    {
    Passed,
    Failed,
    Aborted //Never used
    };

  • JayC (unregistered) in reply to hoodaticus
    hoodaticus:
    ObiWayneKenobi:
    If it's not a class with nothing but static methods (used in moderation that's fine, all over the place not so much)
    I wouldn't permit static classes unless there is a damn good justification. Too many people in the hiring pool need to be deprived of their crutch if they are to learn anything.

    I guess you've never learned about C# extension methods, which by definition are static :-P. Quite usefull too.

  • frits (cs) in reply to hoodaticus
    hoodaticus:
    ObiWayneKenobi:
    If it's not a class with nothing but static methods (used in moderation that's fine, all over the place not so much)
    I wouldn't permit static classes unless there is a damn good justification. Too many people in the hiring pool need to be deprived of their crutch if they are to learn anything.
    All they'll learn is that it's pretty safe to make classes that require instantiation but have no data members.
  • BlackBart (unregistered)

    This is an alternative to the Global Design Pattern I have seen: place everything in the first form, and end up with a single 300,000 line .cs file. In that case, all the form variables are effectively global.

  • z00n3s!$ (unregistered)
    Article:
    I work with those people each and every day — most of them senior to me
    If they are old and frail than their orifices are vulnerable. If they don't have any real teeth left, their throats are ripe for the taking.

    Remember this and you'll fix them quick.

  • Paul (unregistered) in reply to Andreas
    Andreas:
    The next WTF is that you do not need to initialize out-parameters before calling a method. You cannot access the values inside the method anyway.
    That's exactly what I was thinking. A variable passed as an out argument need not be initialized and the out parameter must be assigned a value before the method returns.
  • hoodaticus (cs) in reply to frits
    frits:
    hoodaticus:
    ObiWayneKenobi:
    If it's not a class with nothing but static methods (used in moderation that's fine, all over the place not so much)
    I wouldn't permit static classes unless there is a damn good justification. Too many people in the hiring pool need to be deprived of their crutch if they are to learn anything.
    All they'll learn is that it's pretty safe to make classes that require instantiation but have no data members.
    Which I consider to be the same thing. Gary did that - it's one of the reasons he no longer works for me.
  • hoodaticus (cs) in reply to JayC
    JayC:
    hoodaticus:
    ObiWayneKenobi:
    If it's not a class with nothing but static methods (used in moderation that's fine, all over the place not so much)
    I wouldn't permit static classes unless there is a damn good justification. Too many people in the hiring pool need to be deprived of their crutch if they are to learn anything.

    I guess you've never learned about C# extension methods, which by definition are static :-P. Quite usefull too.

    If you want to get pedantic about it, then you should know that, at the IL level, all methods are static. Instance methods are merely static methods that accept the instance as the first parameter (arg0).

    Extension methods are definitely an exception to the rule :). But then, I never complained about static members. My complaint is against procedural programmers creating stateless "classes" in .NET.

  • Nagesh (cs)
    1. java developer never meke this mistake.
    2. not all static method is bad. sometime static method is very useful.
    3. peepul who lern vb6 and cum to OO background are total useless at geting their head around stuff.
    4. drinking cofee stimulate brian cells. report availebel on http://www.bbc.co.uk/news/health-15059266
    5. that is all for now.
  • C-Octothorpe (cs) in reply to hoodaticus
    hoodaticus:
    Procedural coders should be banned from .NET development.

    When Visual Studio starts up, it should require you to implement an OO design pattern in a mini-game. If you win, Visual Studio won't shock you with a cattle-prod and shove you down a large flight of stairs followed by several overloaded tape safes.

    FTFM

  • Matt (unregistered)

    The real WTF is that J.D. hasn't left yet. Idiot.

  • hoodaticus (cs) in reply to C-Octothorpe
    C-Octothorpe:
    hoodaticus:
    Procedural coders should be banned from .NET development.

    When Visual Studio starts up, it should require you to implement an OO design pattern in a mini-game. If you win, Visual Studio won't shock you with a cattle-prod and shove you down a large flight of stairs followed by several overloaded tape safes.

    FTFM
    You win +5 intern- BZZZZEEEERT!

  • Lockwood (cs) in reply to frits
    frits:
    Well duh. Everybody knows that using bools is short-sighted. That method should return a enumeration like the following:
    public enum TestResult
    {
       Passed,
       Failed,
       FileNotF //Never mind
    };
    

    FTFY

  • Nagesh (unregistered)

    Can some ones post Java code for this plz? I being tied to have put this in my 1.2 Java browser but failing to compile. Should I be using 1.3 browsers?

    Test.java:1: class, interface, or enum expected
    public bool DoQualityControlChecksPass(
    ^
    1 error

  • tom103 (unregistered)

    "Of course, since the variable declaration isn't always consistent in the dozen or so places this method is called, the DoQualityControlChecksPass method re-initializes all parameters anyway."

    Of course it does: a method MUST assign a value to all its out parameters. But the caller doesn't have to initialize them...

  • JayC (unregistered) in reply to frits
    Comment held for moderation.
  • Hortical (unregistered) in reply to Nagesh
    Nagesh (damn faker):
    Can some ones post Java code for this plz? I being tied to have put this in my 1.2 Java browser but failing to compile. Should I be using 1.3 browsers?

    Test.java:1: class, interface, or enum expected
    public bool DoQualityControlChecksPass(
    ^
    1 error
    "enum expected" in your 1.2 Java browser, huh?

  • ObiWayneKenobi (cs)

    Don't get me wrong. I think static methods have their uses, typically in what DDD people call the "Service" - components that only do input/output on something, but aren't directly related to any one entity or domain concept.

    That said even then I would prefer to use instance methods to use Dependency Injection/IoC, but having a static class that acts as a "broker" or possibly as a Factory pattern implementation is okay with me. I've used static methods in Factories that simply construct a domain object from some type of raw data.

    Having a single file with half a dozen classes inside that file, all of which have static methods, however, is blasphemy and anyone who does it should be fired immediately for being a clueless Mort; it shows not only no understanding of OOP but no understanding of component design.

  • Nagesh (unregistered) in reply to Nagesh

    Solution! With help of collegue, I am geting farther on problum. Changing "bool" to Java type, I guet insted: Test.java:1: class, interface, or enum expected public Boolian DoQualityControlChecksPass( ^ Test.java:29: class, interface, or enum expected public string GetQCRuleFailuresText( ^ Test.java:55: class, interface, or enum expected bool replInsurRateInRange = false; ^ Test.java:56: class, interface, or enum expected decimal actualReplInsRate = -1.0m; ^ Test.java:57: class, interface, or enum expected bool rentalYieldInRange = false; ^ Test.java:58: class, interface, or enum expected decimal actualRentalYield = -1.0m; ^ Test.java:59: class, interface, or enum expected bool propValUnderMax = false; ^ Test.java:60: class, interface, or enum expected decimal actualPropValue = -1.0m; ^ Test.java:61: class, interface, or enum expected bool livingAreaInRange = false; ^ Test.java:62: class, interface, or enum expected double actualLivingArea = -1.0d; ^ Test.java:63: class, interface, or enum expected bool riskRatingsAllUnder4 = false; ^ Test.java:64: class, interface, or enum expected bool riskRatingsHave3OrMoreOver3 = false; ^ Test.java:65: class, interface, or enum expected bool twoTierMktIsNo = false; ^ Test.java:66: class, interface, or enum expected string actualTierMkt = null; ^ Test.java:67: class, interface, or enum expected bool mktValEqualsContrPrice = false; ^ Test.java:68: class, interface, or enum expected decimal actualContractPrice = -1.0m; ^ Test.java:69: class, interface, or enum expected bool mktValVarianceFromEMVInRange = false; ^ Test.java:70: class, interface, or enum expected decimal actualEMV = -1.0m; ^ Test.java:71: class, interface, or enum expected bool valDateNotInFuture = false; ^ Test.java:72: class, interface, or enum expected DateTime actualValuationDate = DateTime.MinValue; ^ Test.java:73: class, interface, or enum expected bool intCondWordsNotFound = false; ^ Test.java:74: class, interface, or enum expected List<string> intCondWordsFound = null; ^ Test.java:75: class, interface, or enum expected bool extCondWordsNotFound = false; ^ Test.java:76: class, interface, or enum expected List<string> extCondWordsFound = null; ^ Test.java:77: class, interface, or enum expected bool essRepairsWordsNotFound = false; ^ Test.java:78: class, interface, or enum expected List<string> essRepairsWordsFound = null; ^ Test.java:79: class, interface, or enum expected bool commentsWordsNotFound = false; ^ Test.java:80: class, interface, or enum expected List<string> commentsWordsFound = null; ^ Test.java:81: class, interface, or enum expected bool salesCountCorrect = false; ^ Test.java:82: class, interface, or enum expected bool salesPricesInRange = false; ^ Test.java:83: class, interface, or enum expected bool salesNotTooOld = false; ^ Test.java:84: class, interface, or enum expected bool minReqSalesInSameSuburb = false; ^ Test.java:85: class, interface, or enum expected List<int> invalidSalesIDs = null; ^ Test.java:86: class, interface, or enum expected bool sameValAndValValidDate = false; ^ Test.java:87: class, interface, or enum expected bool sameTenderPriceAndCheckCost = false; ^ Test.java:88: class, interface, or enum expected bool latestSaleGreaterThanValAmount = false; ^ Test.java:89: class, interface, or enum expected bool strataEqualsStratum = false; ^ Test.java:90: class, interface, or enum expected List<string> falseSecuritisationFields = null; ^ Test.java:92: class, interface, or enum expected string qcResultText = null; ^ Test.java:93: class, interface, or enum expected bool qcRes = false; ^ Test.java:94: class, interface, or enum expected bool currentUseIsResidential = true; ^ Test.java:95: class, interface, or enum expected string currentUseNotAsResidential = string.Empty; ^ Test.java:96: class, interface, or enum expected bool impValRateInRange = true; ^ Test.java:97: class, interface, or enum expected decimal impValRate = 0; ^ Test.java:98: class, interface, or enum expected bool landValRateInRange = true; ^ Test.java:99: class, interface, or enum expected decimal landValRate = 0; ^ Test.java:101: class, interface, or enum expected try ^ Test.java:127: class, interface, or enum expected "Of course, since the variable declaration isn't always consistent in the dozen or so places this method is called, the DoQualityControlChecksPass method re-initializes all parameters anyway." ^ Test.java:130: class, interface, or enum expected replInsurRateInRange = true; ^ Test.java:131: class, interface, or enum expected actualReplInsRate = 0m; ^ Test.java:132: class, interface, or enum expected rentalYieldInRange = true; ^ Test.java:133: class, interface, or enum expected actualRentalYield = 0m; ^ Test.java:134: class, interface, or enum expected propValUnderMax = true; ^ Test.java:135: class, interface, or enum expected actualPropValue = 0m; ^ Test.java:136: class, interface, or enum expected decimal actualImpValue = 0m; ^ Test.java:137: class, interface, or enum expected decimal actualLandValue = 0m; ^ Test.java:138: class, interface, or enum expected livingAreaInRange = true; ^ Test.java:139: class, interface, or enum expected actualLivingArea = 0d; ^ Test.java:140: class, interface, or enum expected riskRatingsAllUnder4 = true; ^ Test.java:141: class, interface, or enum expected riskRatingsHave3OrMoreOver3 = true; ^ Test.java:142: class, interface, or enum expected twoTierMktIsNo = true; ^ Test.java:143: class, interface, or enum expected actualTierMkt = null; ^ Test.java:144: class, interface, or enum expected mktValEqualsContrPrice = true; ^ Test.java:145: class, interface, or enum expected actualContractPrice = 0m; ^ Test.java:146: class, interface, or enum expected mktValVarianceFromEMVInRange = true; ^ Test.java:147: class, interface, or enum expected actualEMV = -1.0m; ^ Test.java:148: class, interface, or enum expected valDatePastOrPresent = true; ^ Test.java:149: class, interface, or enum expected actualValuationDate = this.moJob.ValValidDate; ^ Test.java:150: class, interface, or enum expected intCondWordsNotFound = true; ^ Test.java:151: class, interface, or enum expected intCondWordsFound = null; ^ Test.java:152: class, interface, or enum expected extCondWordsNotFound = true; ^ Test.java:153: class, interface, or enum expected extCondWordsFound = null; ^ Test.java:154: class, interface, or enum expected essRepairsWordsNotFound = true; ^ Test.java:155: class, interface, or enum expected essRepairsWordsFound = null; ^ Test.java:156: class, interface, or enum expected commentsWordsNotFound = true; ^ Test.java:157: class, interface, or enum expected commentsWordsFound = null; ^ Test.java:158: class, interface, or enum expected salesCountCorrect = true; ^ Test.java:159: class, interface, or enum expected salesPricesInRange = true; ^ Test.java:160: class, interface, or enum expected salesNotTooOld = true; ^ Test.java:161: class, interface, or enum expected minReqSalesInSameSuburb = true; ^ Test.java:162: class, interface, or enum expected invalidSalesIDs = null; ^ Test.java:163: class, interface, or enum expected sameValAndValValidDate = true; ^ Test.java:164: class, interface, or enum expected sameTenderPriceAndCheckCost = true; ^ Test.java:165: class, interface, or enum expected latestSaleGreaterThanValAmount = true; ^ Test.java:166: class, interface, or enum expected strataEqualsStratum = true; ^ Test.java:167: class, interface, or enum expected bool noSecuritisationFailures = true; ^ Test.java:168: class, interface, or enum expected falseSecuritisationFields = new List<string>(); ^ Test.java:169: class, interface, or enum expected currentUseIsResidential = true; ^ Test.java:170: class, interface, or enum expected currentUseNotAsResidential = string.Empty; ^ Test.java:171: class, interface, or enum expected impValRateInRange = true; ^ Test.java:172: class, interface, or enum expected impValRate = 0; ^ Test.java:173: class, interface, or enum expected landValRateInRange = true; ^ Test.java:174: class, interface, or enum expected landValRate = 0; ^ 93 errors helping plz?

  • frits (cs) in reply to Nagesh
    Nagesh:
    4. drinking cofee stimulate brian cells. report availebel on http://www.bbc.co.uk/news/health-15059266
    Totally irrelevent! That is an article on how coffee prevents women from getting depressed. We all know nobody here is a woman.

    Welcome back.

  • z00n3s!$ (unregistered) in reply to C-Octothorpe
    C-Octothorpe:
    hoodaticus:
    Procedural coders should be banned from .NET development.

    When Visual Studio starts up, it should require you to implement an OO design pattern in a mini-game. If you win, Visual Studio won't reach out with robot arms, pulling you over the desk, with a third arm that reaches around with an electric, spiked dildo, forcibly sodomizing you, while urine is squirted onto your face and a recorded message let's you know you're nothing but a piece of shit (HIS piece of shit) and a funnel collects the dripping excrement from your swollen anus and liquifies it and then injects it up your urethra or vagina (as applicable) and then a gloved, mechanical hand slaps you back and forth demanding you never do that again until you say "Yes, master" at least three slaps in a row.

    FTFM
    FTFY

  • Nagesh (unregistered) in reply to Hortical
    Hortical (unregistred inpolite H8R):
    Nagesh:
    Can some ones post Java code for this plz? I being tied to have put this in my 1.2 Java browser but failing to compile. Should I be using 1.3 browsers?

    Test.java:1: class, interface, or enum expected
    public bool DoQualityControlChecksPass(
    ^
    1 error
    "enum expected" in your 1.2 Java browser, huh?
    Sry. Mispeling -sorce in comand line flags. Corect option is:

    javac -source 1.2 -target 1.2 Test.java

    Dont be a H8R.

  • Nagesh (unregistered) in reply to frits
    Comment held for moderation.
  • hoodaticus (cs) in reply to ObiWayneKenobi
    ObiWayneKenobi:
    Don't get me wrong. I think static methods have their uses, typically in what DDD people call the "Service" - components that *only* do input/output on something, but aren't directly related to any one entity or domain concept.

    That said even then I would prefer to use instance methods to use Dependency Injection/IoC, but having a static class that acts as a "broker" or possibly as a Factory pattern implementation is okay with me. I've used static methods in Factories that simply construct a domain object from some type of raw data.

    Having a single file with half a dozen classes inside that file, all of which have static methods, however, is blasphemy and anyone who does it should be fired immediately for being a clueless Mort; it shows not only no understanding of OOP but no understanding of component design.

    +5. It's not statics that are evil. It's the exclusive use of stateless classes to prove true the axiom "You can do FORTRAN in any language."

  • Peter L (unregistered)

    Hah, I once had to maintain a system written in Visual Basic, and the term "spaghetti programming" sprung to mind. However, this was not literally spaghetti programming, but rather "tortellini programming", if we stay in the pasta domain: Tortellini programming is islands of event handling code in a sauce of global variables. Yuck!

  • Hortical (unregistered) in reply to Nagesh
    Nagesh (quite possibly faker):
    Hortical:
    Nagesh (quite possibly faker):
    Can some ones post Java code for this plz? I being tied to have put this in my 1.2 Java browser but failing to compile. Should I be using 1.3 browsers?

    Test.java:1: class, interface, or enum expected
    public bool DoQualityControlChecksPass(
    ^
    1 error
    "enum expected" in your 1.2 Java browser, huh?
    Sry. Mispeling -sorce in comand line flags. Corect option is:

    javac -source 1.2 -target 1.2 Test.java

    Dont be a H8R.

    I'm starting to get the feeling that you're not who you say you are.

  • hoodaticus (cs) in reply to Peter L
    Peter L:
    Hah, I once had to maintain a system written in Visual Basic, and the term "spaghetti programming" sprung to mind. However, this was not literally spaghetti programming, but rather "tortellini programming", if we stay in the pasta domain: Tortellini programming is islands of event handling code in a sauce of global variables. Yuck!
    VBA forces you to do that in some situations. TRWTF is _ _.
  • Some damn Yank (unregistered) in reply to hoodaticus
    hoodaticus:
    Procedural coders should be banned from .NET development.

    When Visual Studio starts up, it should require you to implement an OO design pattern in a mini-game. If you win, Visual Studio won't uninstall itself, delete all your projects, and revoke your license.

    Good idea, but they have to learn somehow. What if losing the mini-game installed C# Express Edition with save disabled?

    CAPTCHA: uxor. Where the hell's the L?

  • Nagesh (cs) in reply to frits
    frits:
    Nagesh:
    4. drinking cofee stimulate brian cells. report availebel on http://www.bbc.co.uk/news/health-15059266
    Totally irrelevent! That is an article on how coffee prevents women from getting depressed. We all know nobody here is a woman.

    Welcome back.

    Pls dont draw concluson basing on headline. Pls read entire article first.

  • Some damn Yank (unregistered) in reply to Nagesh
    Nagesh:
    5. that is all for now.
    We wish.
  • The Great Lobachevsky (cs) in reply to frits

    Yeah, there aren't any women in computers, right? At least any that know JavaScript. ;-)

  • Some damn Yank (unregistered) in reply to hoodaticus
    hoodaticus:
    It's not statics that are evil. It's the exclusive use of stateless classes to prove true the axiom "You can do FORTRAN in any language."
    Oh? Well, then, how would you prove true the axiom "You can do FORTRAN in any language." without stateless classes?
  • Mort (unregistered) in reply to ObiWayneKenobi
    ObiWayneKenobi:
    Don't get me wrong. I think static methods have their uses, typically in what DDD people call the "Service" - components that *only* do input/output on something, but aren't directly related to any one entity or domain concept.

    That said even then I would prefer to use instance methods to use Dependency Injection/IoC, but having a static class that acts as a "broker" or possibly as a Factory pattern implementation is okay with me. I've used static methods in Factories that simply construct a domain object from some type of raw data.

    Having a single file with half a dozen classes inside that file, all of which have static methods, however, is blasphemy and anyone who does it should be fired immediately for being a clueless Mort; it shows not only no understanding of OOP but no understanding of component design.

    Huh?

  • C-Octothorpe (cs) in reply to The Great Lobachevsky
    The Great Lobachevsky:
    Yeah, there aren't any women in computers, right? At least any that know JavaScript. ;-)
    I don't have any in my computer, but I've got a couple in my trunk, if that counts for anything...

    What?

  • z00n3s!$ (unregistered) in reply to C-Octothorpe
    C-Octothorpe:
    The Great Lobachevsky:
    Yeah, there aren't any women in computers, right? At least any that know JavaScript. ;-)
    I don't have any in my computer, but I've got a couple in my trunk, if that counts for anything...
    Like to keep mobile, do ya?

    I found carrying around the whole bodies to be too much work (and too likely to be discovered) so I just cut off the parts I actually use and carry them around in my briefcase.

  • ObiWayneKenobi (cs) in reply to Mort
    Mort:
    Huh?

    Here, let me translate:

    If Not mort.UnderstandsProperProgramming And mort.IsClueless Then mort.Dispose() Set mort = Nothing End If

  • eVil (unregistered) in reply to The Great Lobachevsky
    The Great Lobachevsky:
    Yeah, there aren't any women in computers, right? At least any that know JavaScript. ;-)

    Got to the right websites, and you'll find your computer is chock-full of them. They generally naked and licking each other though, so I doubt they have much time for JavaScript.

  • Jon (unregistered) in reply to Global
    Global:
    Globalization is the future Frist

    +1.000 for humor +0.025 for frist

  • frits (cs) in reply to The Great Lobachevsky
    The Great Lobachevsky:
    Yeah, there aren't any women in computers, right? At least any that know JavaScript. ;-)
    Please don't mistake my jokiness for ignorance, ma'am.
  • Some damn Yank (unregistered) in reply to Bradley

    [quote user="Bradley"][quote user="hoodaticus"]s fine, all over the place not so much)[/quote]I wouldn't permit static classes unless there is a damn good justification. Too many people in the hiring pool need to be deprived of their crutch if they are to learn anything.[/quote]

    They will just move on to singletons. For every crutch you take away, another will be found.[/quote] This board quotes everything for you. How did you manage to mess it up? Whatever you did even messed up my quoting of you!

  • Nagesh (unregistered) in reply to ObiWayneKenobi
    ObiWayneKenobi:
    Don't get me wrong. I think static methods have their uses, typically in what DDD people call the "Service" - components that *only* do input/output on something, but aren't directly related to any one entity or domain concept.

    That said even then I would prefer to use instance methods to use Dependency Injection/IoC, but having a static class that acts as a "broker" or possibly as a Factory pattern implementation is okay with me. I've used static methods in Factories that simply construct a domain object from some type of raw data.

    Having a single file with half a dozen classes inside that file, all of which have static methods, however, is blasphemy and anyone who does it should be fired immediately for being a clueless Mort; it shows not only no understanding of OOP but no understanding of component design.

    IoC is best OO patern in existance, but I think imposible in C.

  • queisser (unregistered)

    Normally I laugh at TDWTF but this one made me a little queasy.

Leave a comment on “The Global Workaround”

Log In or post as a guest

Replying to comment #:

« Return to Article