• (cs) in reply to TopCod3r
    TopCod3r (unregistered):

    Hmm, unregistered?

  • Mark (unregistered) in reply to bb

    I am not sure that is true. I thought VB defined true as -1.

  • (cs) in reply to Vollhorst
    Vollhorst:
    Erick:
    Sorry, but bGroup1 is one horribly named variable. It reeks of laziness, as its Hungarianish name doesn't even describe its type, let alone its function.
    It is a command variable. "be Group one". Can't you see that?
    No it is not. Clearly, it's a variable named in Hungarian Ebonics:

    "This variable be Group 1."

    What is it with all the language Nazis on this site?

  • Shatnered Arm (unregistered) in reply to ShatteredArm
    ShatteredArm:
    campkev:

    if you really are being serious, why would you do this:

    DECLARE @QUERY AS VARCHAR(1000)

    SET @QUERY = 'SELECT NUMTASK, YEARTASK, DATEOPEN ' SET @QUERY = @QUERY + 'from TaskStudio ' SET @QUERY = @QUERY + 'WHERE ( ' SET @QUERY = @QUERY + 'CODCOMPANY = ' + CONVERT(VARCHAR,@CODCOMPANY) + ' AND ' SET @QUERY = @QUERY + 'DATEOPENINGS = ''' + CONVERT(VARCHAR,(CONVERT(DATETIME,@ DATEOPENINGS,103))) + ''' AND ' SET @QUERY = @QUERY + 'CODCLIENT = ' + CONVERT(VARCHAR,@CODCLIENT) + ' AND ' SET @QUERY = @QUERY + 'OFFEREURO = ' + CONVERT(VARCHAR,@OFFEREUROVAR) SET @QUERY = @QUERY + ' ) '

    PRINT (@QUERY) EXEC (@QUERY)

    instead of this

    SELECT NUMTASK, YEARTASK, DATEOPEN 
    from TaskStudio 
    WHERE ( 
    CODCOMPANY = @CODCOMPANY AND 
    DATEOPENINGS =  CONVERT(VARCHAR,(CONVERT(DATETIME,@ DATEOPENINGS,103))) AND 
    CODCLIENT = @CODCLIENT AND 
    OFFEREURO = @OFFEREUROVAR
     ) 
    

    Not to mention stored procedures are compiled, thereby improving performance. That the dynamic sql would be compiled, however, seems doubtful. The only reasonable use of dynamic sql inside a stored procedure that I've seen is a stored proc that conditionally connects to different databases, but even if you're doing that, it seems likely that there is a better architectural solution to that problem.

    It's exactly because stored procedures are compiled that this is not a WTF. This approach compiles the stored procedure two times which doubles the speed of the stored procedure twice. Essentially giving you a 400% gain in efficiency.

  • Anders Hesselbom (unregistered)

    This makes me so happy. It's not every day you get the feeling that you have actually learned something from all the conceptual theories on how to write code.

  • (cs) in reply to Shatnered Arm
    Shatnered Arm:
    ShatteredArm:
    campkev:

    if you really are being serious, why would you do this:

    DECLARE @QUERY AS VARCHAR(1000)

    SET @QUERY = 'SELECT NUMTASK, YEARTASK, DATEOPEN ' SET @QUERY = @QUERY + 'from TaskStudio ' SET @QUERY = @QUERY + 'WHERE ( ' SET @QUERY = @QUERY + 'CODCOMPANY = ' + CONVERT(VARCHAR,@CODCOMPANY) + ' AND ' SET @QUERY = @QUERY + 'DATEOPENINGS = ''' + CONVERT(VARCHAR,(CONVERT(DATETIME,@ DATEOPENINGS,103))) + ''' AND ' SET @QUERY = @QUERY + 'CODCLIENT = ' + CONVERT(VARCHAR,@CODCLIENT) + ' AND ' SET @QUERY = @QUERY + 'OFFEREURO = ' + CONVERT(VARCHAR,@OFFEREUROVAR) SET @QUERY = @QUERY + ' ) '

    PRINT (@QUERY) EXEC (@QUERY)

    instead of this

    SELECT NUMTASK, YEARTASK, DATEOPEN 
    from TaskStudio 
    WHERE ( 
    CODCOMPANY = @CODCOMPANY AND 
    DATEOPENINGS =  CONVERT(VARCHAR,(CONVERT(DATETIME,@ DATEOPENINGS,103))) AND 
    CODCLIENT = @CODCLIENT AND 
    OFFEREURO = @OFFEREUROVAR
     ) 
    

    Not to mention stored procedures are compiled, thereby improving performance. That the dynamic sql would be compiled, however, seems doubtful. The only reasonable use of dynamic sql inside a stored procedure that I've seen is a stored proc that conditionally connects to different databases, but even if you're doing that, it seems likely that there is a better architectural solution to that problem.

    It's exactly because stored procedures are compiled that this is not a WTF. This approach compiles the stored procedure two times which doubles the speed of the stored procedure twice. Essentially giving you a 400% gain in efficiency.

    Thank you. I needed a laugh

  • InsanityCubed (unregistered) in reply to SomeCoder
    SomeCoder:
    ShatteredArm:

    Not to mention stored procedures are compiled, thereby improving performance. That the dynamic sql would be compiled, however, seems doubtful. The only reasonable use of dynamic sql inside a stored procedure that I've seen is a stored proc that conditionally connects to different databases, but even if you're doing that, it seems likely that there is a better architectural solution to that problem.

    The other time I've seen dynamic SQL in a stored proc was when the query had to conditionally run on different TABLES.

    Given this very, very poorly designed scenario, is there any other way to do it? I mean besides shooting the guy who designed the database and starting over.

    Even then why not do this:

    if @Condition = 1 then

    Select * from Table1

    else

    Select * from Table2

    end if

  • ShatteredArm (unregistered) in reply to Shatnered Arm
    Shatnered Arm:
    ShatteredArm:
    campkev:

    if you really are being serious, why would you do this:

    DECLARE @QUERY AS VARCHAR(1000)

    SET @QUERY = 'SELECT NUMTASK, YEARTASK, DATEOPEN ' SET @QUERY = @QUERY + 'from TaskStudio ' SET @QUERY = @QUERY + 'WHERE ( ' SET @QUERY = @QUERY + 'CODCOMPANY = ' + CONVERT(VARCHAR,@CODCOMPANY) + ' AND ' SET @QUERY = @QUERY + 'DATEOPENINGS = ''' + CONVERT(VARCHAR,(CONVERT(DATETIME,@ DATEOPENINGS,103))) + ''' AND ' SET @QUERY = @QUERY + 'CODCLIENT = ' + CONVERT(VARCHAR,@CODCLIENT) + ' AND ' SET @QUERY = @QUERY + 'OFFEREURO = ' + CONVERT(VARCHAR,@OFFEREUROVAR) SET @QUERY = @QUERY + ' ) '

    PRINT (@QUERY) EXEC (@QUERY)

    instead of this

    SELECT NUMTASK, YEARTASK, DATEOPEN 
    from TaskStudio 
    WHERE ( 
    CODCOMPANY = @CODCOMPANY AND 
    DATEOPENINGS =  CONVERT(VARCHAR,(CONVERT(DATETIME,@ DATEOPENINGS,103))) AND 
    CODCLIENT = @CODCLIENT AND 
    OFFEREURO = @OFFEREUROVAR
     ) 
    

    Not to mention stored procedures are compiled, thereby improving performance. That the dynamic sql would be compiled, however, seems doubtful. The only reasonable use of dynamic sql inside a stored procedure that I've seen is a stored proc that conditionally connects to different databases, but even if you're doing that, it seems likely that there is a better architectural solution to that problem.

    It's exactly because stored procedures are compiled that this is not a WTF. This approach compiles the stored procedure two times which doubles the speed of the stored procedure twice. Essentially giving you a 400% gain in efficiency.

    No, that still only compiles once. This is how you double compile:

    CREATE PROCEDURE [dbo].[my_proc] AS
    BEGIN
    
    DECLARE @QUERY VARCHAR(MAX)
    SET @QUERY = 'CREATE PROCEDURE [dbo].[my_2nd_proc] AS '
    SET @QUERY = @QUERY + 'BEGIN '
    SET @QUERY = @QUERY + '  SELECT * FROM MyTable '
    SET @QUERY = @QUERY + 'END '
    SET @QUERY = @QUERY + 'GO '
    SET @QUERY = @QUERY + 'EXEC my_2nd_proc '
    SET @QUERY = @QUERY + 'GO '
    SET @QUERY = @QUERY + 'DROP PROCEDURE [dbo].[my_2nd_proc] '
    SET @QUERY = @QUERY + 'GO '
    
    EXEC (@QUERY)
    END
    GO
    
  • (cs) in reply to Spectre
    Spectre:
    TopCod3r (unregistered):

    Hmm, unregistered?

    Exactly, someone can post using a registered person's name??? That, truly is the real WTF.

  • Spectre (unregistered) in reply to Spectre
    Spectre:
    TopCod3r (unregistered):

    Hmm, unregistered?

    Yes, it is easy, all you have to do is add a space to the end of the name!!! Check out my name, Spectre!!! Woo-hooooo!!! WTF!!!

  • Lurker (unregistered) in reply to Yaos
    Yaos :
    They just made it so changes are super easy. I get confused when people start using OR and I'm sure everybody else does as well.

    Surely, you can't be serious.

  • (cs) in reply to campkev
    campkev:
    Thank you. I needed a laugh
    You also need to learn to not be one of those nitwits who quotes two screens full of multi-nested quotes merely to tack on a vapid single-line reply.
  • (cs) in reply to Zylon
    Zylon:
    You also need to learn to not be one of those nitwits who quotes two screens full of multi-nested quotes merely to tack on a vapid single-line reply.

    sorry, been a long day. Normally edit the quotes better

  • emaN ruoY (unregistered) in reply to Shatnered Arm
    Shatnered Arm:
    It's exactly because stored procedures are compiled that this is not a WTF. This approach compiles the stored procedure two times which doubles the speed of the stored procedure twice. Essentially giving you a 400% gain in efficiency.

    I just laughed so hard I scared my boss.

    Captcha: veniam : Come to ME!

  • SomeCoder (unregistered) in reply to InsanityCubed
    InsanityCubed:
    SomeCoder:
    ShatteredArm:

    Not to mention stored procedures are compiled, thereby improving performance. That the dynamic sql would be compiled, however, seems doubtful. The only reasonable use of dynamic sql inside a stored procedure that I've seen is a stored proc that conditionally connects to different databases, but even if you're doing that, it seems likely that there is a better architectural solution to that problem.

    The other time I've seen dynamic SQL in a stored proc was when the query had to conditionally run on different TABLES.

    Given this very, very poorly designed scenario, is there any other way to do it? I mean besides shooting the guy who designed the database and starting over.

    Even then why not do this:

    if @Condition = 1 then

    Select * from Table1

    else

    Select * from Table2

    end if

    Well because if you did that, you'd have a Stored Proc that looks like this:

    if @Condition = 1 then

    Select * from Table1

    else if @Condition = 2 then

    Select * from Table2

    else if @Condition = 3 then

    Select * from Table3

    <snip>

    else if @Condition = 1000 then

    Select * from Table1000

    end if

    Yes, that design was heinous and I am really, really glad that I don't have to deal with that anymore. Someday, I might post something from that job to this site.

  • logic (unregistered) in reply to TopCod3r
    TopCod3r:
    [code]4. The compiler will optimize it all anyway. Better than you can.

    No it won't.

  • logic (unregistered) in reply to hikari
    hikari:
    Niels:
    If an 'as designed' feature of a programming language makes it to this site then one might wonder where the real problem lies. Is it the programmer or is it ... ?

    Well there's certainly a problem with a programmer.

    You're making the assumption that Microsoft programming languages are designed by developers. I wonder...

  • LordVashtal (unregistered) in reply to OhDear

    LUA is like that, and it drives me nuts

  • mgb (unregistered)

    Two things (not trolling here, but I am a maintenance programmer, so take this with a chunk of salt) regarding the dynamic SQL.

    First: the variables may in fact contain eval-able code rather than string data. It's not the best idea, but in a certain kind of shop it makes as much sense to do things this way as any other. In this case, given the converts, it is likely that this was created by a junior developer or a low-q developer copying something written somewhere else, but it can in fact be a valid approach to the problem of needed a very small but still nonzero level of dynamism in a query.

    Second: the reason why it's in a stored procedure is that that is Where The Database Stuff Goes under certain architectural approaches. Until you've spent years of your working life maintaining (not writing, solely maintaining) other people's code, it may not be obvious, but this is one way that people limit the amount of screwing around involved in finding particular application components. Call it Tiering Without Mercy.

  • Null303 (unregistered) in reply to Kozz

    I dont remember VB syntax, but it is (almost) the same as:

    bGroup = bGroup1 > 0

  • Null303 (unregistered) in reply to campkev
    campkev:
    sebbb:
    "bGroup = (bGroup1 != 0);"

    This line is C, not? Isn't in VB "<>", not "!="? Then, maybe (not VB):

    bGroup = (bGroup1<3) ? (bGroup1 != 0) : bGroup;

    you are making the assumption that bGroup1 can't be negative

    It all depends on what you are using bGroup for, perhaps all those "undefined" cases are irrelevant

  • Steve (unregistered)

    "Classes? We don't need no stinking classes!"

    You can write FORTRAN programs in any language.

  • Bob (unregistered) in reply to Shatnered Arm
    Shatnered Arm:
    It's exactly because stored procedures are compiled that this is not a WTF. This approach compiles the stored procedure two times which doubles the speed of the stored procedure twice. Essentially giving you a 400% gain in efficiency.

    A quadrupling of efficiency would be a 300% gain in efficiency. Captcha: minim (half note in American English)

  • Bob (unregistered) in reply to Steve
    Steve:
    "Classes? We don't need no stinking classes!"

    You can write FORTRAN programs in any language.

    Except THREETRAN, TWOTRAN, ONETRAN, and ZEROTRAN. FORTRAN added extra features that these languages do not have.

    Also, they should have called Fortran 90 FIVETRAN.

  • Glen Fingerholz (unregistered) in reply to Mark

    Mark, you are correct. VB .NET, VBScript, and VBA/VB6 all use -1 as True. However, when converting from other numeric types, anything other than 0 is treated as True.

    They fixed the datatype WTFs, and made it a fully-featured object-oriented language. Yet they left other WTFs in the language and seem to be adding new ones. Makes sense though, given that VB caters to the less skilled.

    CAPTCHA: suscipere (that's a word?)

  • Steve (unregistered) in reply to halcyon1234
    halcyon1234:
    TopCod3r:
    TopCod3r:
    [code]
    Wait, what? I didn't post this. Nice try.
    It must have been one of your team. You taught them well.
    On the Internet no one knows you're a dog.
  • Steve (unregistered) in reply to Bob
    Bob:
    Steve:
    "Classes? We don't need no stinking classes!"

    You can write FORTRAN programs in any language.

    Except THREETRAN, TWOTRAN, ONETRAN, and ZEROTRAN. FORTRAN added extra features that these languages do not have.

    Also, they should have called Fortran 90 FIVETRAN.

    I programmed in ZEROTRAN. . . except it was called BASIC.

    There used to be something called GOTRAN, which was a simplified version of FORTRAN II, which ran on an IBM 1620 waaaaaay back in the Dark Ages that probably would qualify as ONETRAN and FORTRAN II, along with its bastard spawn FORTRAN II-D, would definitely qualify as TWOTRAN.

    And don't get me started on ALGOL 60. . .

  • Steve (unregistered) in reply to Glen Fingerholz
    Glen Fingerholz:
    CAPTCHA: suscipere (that's a word?)
    No, it's not.
  • Shinobu (unregistered) in reply to Sven

    Maybe it is in VB.NET, but in VB the expression "" = X where X happens to be Nothing will land you a runtime error 91 ‘Object variable or With block variable not set’. Yes, I tried it. I also like how this thread is full of people bashing VB who obviously can't code in VB. And people who can't code at all, apparently. It always makes me smile how people are so desperate to find and point out more WTFs that they forget that they're not that good at programming themselves.

  • Shinobu (unregistered) in reply to Steve
    Steve:
    Glen Fingerholz:
    CAPTCHA: suscipere (that's a word?)
    No, it's not.
    Tis, philistine. Quoth my little book 'o words: suscipere, io, cepi, ceptum, III. - 1. to catch, to take on, to invite; s. aliquem labentem to catch, support someone who falls. - 2. to defend, to take in protection. - 3. to undertake, to start something, to take something on; s. personam to play a role; to be open to. - 4. to get yourself into, to face, to defy; s. inimicitias to expose oneself to hostilities. - 5. to beget. - 6. to be susceptible to, to be open to, to accept. 7. to take in, to accept (to), to agree to; aliquem in civitatem s. to grant someone citizenship. - 9. to take on, to undertake, to accept, to begin; s. laborem to begin a work; s. consilium to take a decision. - 10. to tolerate, to suffer.
  • Bob (unregistered) in reply to Mark
    Mark:
    I am not sure that is true. I thought VB defined true as -1.
    Yes, this is from line-number BASIC and QuickBASIC so that logical and bitwise operators could be combined.
  • Edward Royce (unregistered) in reply to OhDear
    OhDear:
    Some of that code slightly makes sense. I have used old VB and ended up writing some pretty stupid looking code to get around some very stupid language "features".

    A perfect example was when a single x+=1 had to be replaced with x=x+1. Why the first wouldn't work where it was while the second worked fine made no sense, but it made the code function. I can see someone following me and thinking that I was a dolt.

    Hmmmm. Well that's generally because old VB didn't support the syntax of "x+=1" and only supported "x=x+1".

    shrug it's VB.

  • (cs) in reply to Steve
    Steve:
    "Classes? We don't need no stinking classes!"

    You can write FORTRAN programs in any language.

    I tried writing them in fortran, but the compiler complained.

    I think it was something along the lines of "ooh, me knees! The sciatica's playing up, too. You young whippersnappers, you just don't understand the value of a ternary if-expression."

    Come to think of it, I don't understand the value of a ternary if-expression, either.

    We never did get around to discussing the actual fortran code. There was some degree of bickering as to whether it was intended to be IVe or 77, as I recall. I'm afraid I just had to put the Purdey against the poor old codger's head and let loose with both barrels.

    I think it was for the best.

  • Edward Royce (unregistered) in reply to Vollhorst
    Vollhorst:
    Erick:
    Sorry, but bGroup1 is one horribly named variable. It reeks of laziness, as its Hungarianish name doesn't even describe its type, let alone its function.
    It is a command variable. "be Group one". Can't you see that?

    Sooo. bExcelto1A would translate to "Be excellent to one another!"?

    Wyld Stallions!!

  • Bob (unregistered) in reply to pink_fairy
    pink_fairy:

    I think it was something along the lines of "ooh, me knees! The sciatica's playing up, too. You young whippersnappers, you just don't understand the value of a ternary if-expression."

    Come to think of it, I don't understand the value of a ternary if-expression, either.

    Which one? the ternary question mark operator in c or the fortran arithmetic if?

    IF (foobar) negative,zero,positive

  • Renaissance Man (unregistered) in reply to Shinobu
    Shinobu:
    Tis, philistine. Quoth my little book 'o words: suscipere, io, cepi, ceptum, III. - 1. to catch

    Only following "temptare".

  • Steve (unregistered) in reply to Shinobu
    Shinobu:
    Steve:
    Glen Fingerholz:
    CAPTCHA: suscipere (that's a word?)
    No, it's not.
    Tis, philistine. Quoth my little book 'o words: suscipere, io, cepi, ceptum, III. - 1. to catch, to take on, to invite; s. aliquem labentem to catch, support someone who falls. - ...
    I stand corrected.

    Now I shall go sit corrected.

  • Hullu Piipaa (unregistered) in reply to campkev

    While I understand that you weren't first (and hence only) one to comment that this does not do what the original code do, I'll share some insight based on experience from working with other people's code.

    Based on the quality of the code in the examples, I very highly doubt that even when separated on the context, the original coder never planned to handle the "case above 2". Based on educated guess, that function might as well go BOOM as soon as the number other than 0-2 entered the scope (I'm speaking of the original code).

    When starting to work with the code from someone else, it takes some time to adjust yourself to the level of code. At the level of these examples, it is very unlikely there is something "genious" behind any weird looking structures, rather than just piss-poor expression or design.

    On the last comment, of course one NEVER goes to change that code to function differnently without properly examining the entry points and evaluating the risk of actually changing some current behaviour (although it could be broken already).

    However I personally try to improve the code like that when I have to touch it or nearby.

  • Hullu Piipaa (unregistered) in reply to campkev
    campkev:
    bGroup = (bGroup1 > 0)

    would be to easy?

    First of all, it's TOO not TO and second, for the third time, that is not doing the same thing that the function does.

    When did everyone around here become terrible programmers.

    Puhh, newbie poster alert! I forgot to quote the original, hence "double" post to clear out where I was referring to:

    While I understand that you weren't first (and hence only) one to comment that this does not do what the original code do, I'll share some insight based on experience from working with other people's code.

    Based on the quality of the code in the examples, I very highly doubt that even when separated on the context, the original coder never planned to handle the "case above 2". Based on educated guess, that function might as well go BOOM as soon as the number other than 0-2 entered the scope (I'm speaking of the original code).

    When starting to work with the code from someone else, it takes some time to adjust yourself to the level of code. At the level of these examples, it is very unlikely there is something "genious" behind any weird looking structures, rather than just piss-poor expression or design.

    On the last comment, of course one NEVER goes to change that code to function differnently without properly examining the entry points and evaluating the risk of actually changing some current behaviour (although it could be broken already).

    However I personally try to improve the code like that when I have to touch it or nearby.

  • LogHead (unregistered) in reply to campkev
    campkev:
    bGroup = (bGroup1 > 0)

    would be to easy?

    First of all, it's TOO not TO and second, for the third time, that is not doing the same thing that the function does.

    When did everyone around here become terrible programmers.

    Ha!!!! When was anyone around here anything else?

  • Blackbeard (unregistered) in reply to pink_fairy
    pink_fairy:
    Vollhorst:
    Erick:
    Sorry, but bGroup1 is one horribly named variable. It reeks of laziness, as its Hungarianish name doesn't even describe its type, let alone its function.
    It is a command variable. "be Group one". Can't you see that?
    No it is not. Clearly, it's a variable named in Hungarian Ebonics:

    "This variable be Group 1."

    What is it with all the language Nazis on this site?

    Aghrr...be it talk like a pirate day once more?

  • AdT (unregistered) in reply to TopCod3r
    TopCod3r:
    Actually he's on the right track. I require my team to separately enumerate each possible value, even if there are 50 or more.

    Congrats, IHBT. Just the right combination of inanity and sounding like you actually meant it.

    (Would the real TopCod3r please stand up?)

  • Annoying Pedant (unregistered) in reply to Bob

    Bob said, ' the += assignment operator isn't (and never has been) a feature in basic or visual basic. '

    Never say never. BBC BASIC V (1985) had all kinds of assignment operators, including '+='. My personal favourites were '>>=' (arithmetic shift right assign) and '>>>=' (rotate right assign).

  • David Cameron (unregistered)

    Actually for IE5.0 an undefined value actually contains 'undefined' (ie a string). I don't have IE 5 arount right now to check whether casting to a string would be a valid check.

    Not necessarily WTFy.

  • Ben (unregistered) in reply to dsckeld

    Except that generation said SQL -inside a stored procedure- is stupid. If you want to generate SQL like that, you do it in the application and pass it off to the DB after.

    my $q = 'SELECT * FROM atable WHERE ' . map { q|($_=? OR $_ is null)| } (qw/field1 field2 field3 field4/);
    $sth->execute($q, qw/field1value field2value field3value/);
    

    Something along those ines...

  • more randomer than you (unregistered) in reply to Virtually Brillant
    Virtually Brillant:
    > If bGroup = True Then

    Just that line is enough to make me want to slap the developer with a wet haddock. To be really sure bGroup (presumably a Boolean) is true, why not If (bGroup = True) = True Then or If ((bGroup = True) = True) = True Then or (continue ad nauseam)

    You should probably cast that just to make absolutely sure:

    If ((bGroup = True) = True) = ((True) True) Then

  • (cs) in reply to Superdude

    So this is what it looks like when the CSI chick makes "a GUI interface using Visual Basic" to "See if I can track an IP"... (http://forums.thedailywtf.com/forums/t/8724.aspx)

  • (cs) in reply to Walk a mile in my shoes
    Walk a mile in my shoes:
    I found this article via an English Grammar and Punctuation WTF web site... where it was the WTF of the day... for its abuse... of the ellipse...
    I can't remember the name of the Law that says anyone criticising language will themselves make a linguistic error.

    http://en.wikipedia.org/wiki/Ellipse http://en.wikipedia.org/wiki/Ellipsis

  • m0ffx (unregistered) in reply to TopCod3r
    TopCod3r:
    Spectre:
    TopCod3r (unregistered):

    Hmm, unregistered?

    Exactly, someone can post using a registered person's name??? That, truly is the real WTF.

    Well, it does say 'unregistered'. Also, it's handy, if one can't be bothered to log in.

  • cthulhu (unregistered)

    TRWTF is they use SQL. A file based caching solution can be more efficient.

Leave a comment on “A Touch of Genius”

Log In or post as a guest

Replying to comment #227992:

« Return to Article