• Why (unregistered)

    I just removed a logging WTF where it would write an error to log and alert the errors slack channel is a user got their logins wrong.

  • Also (unregistered)

    Frist

  • P (unregistered)

    TRWTF is Remy mentioning this function changing the property values without mentioning it changes the property keys too, which is even worse. Now you might get duplicate keys!

  • bvs23bkv33 (unregistered)

    single line? regexes!

  • Pabz (unregistered)

    I guess they could have solved the newline problem by adding a \n somewhere?

  • not a robot (unregistered)

    at the very least split by "} {"

  • (nodebb)

    If they had 2 brain cells, which they don't, they could've written a parser which utilizes a json reader and stops at { right after the }. But then, if they had the aforementioned brain cells, they would've delimited it properly and there would be no need for this crap.

  • (nodebb) in reply to not a robot

    Right??!! I bet they didn't think of it because they couldn't figure out what to do with strings missing the {} at both ends

  • (nodebb)

    Actually the best solution would be to write a virtual text reader, which stops at "} {". That way strings aren't allocated for blobs and there's no need to roll your own deserializer. I'm not sure if it's possible in Python though, definitely is in .NET.

  • SSA (unregistered)

    Am I missing a subtle joke here? The word "than" is misused in several places. It is really distracting. Somebody tell me the joke! :D

  • ooOOooGa (unregistered)

    Someone likes the word 'than' way too much.

  • ooOOooGa (unregistered) in reply to Pabz

    My suspicion is that the logger is already adding \n to each log entry - when it needs to add \r\n instead. When loaded up in text editors that are expecting \r\n, a \n will usually display as a single space.

    If I am right, then this is even more of a WTF because the code can still split the log file on \n even if all of the text editors on the user's computers are expecting \r\n.

  • tbo (unregistered) in reply to P

    I would guess that the keys don't have spaces, so it isn't a problem, and therefore isn't worth mentioning.

  • I dunno LOL ¯\(°_o)/¯ (unregistered) in reply to P

    Nobody puts spaces in keys! It's not enterprisey unless the keys are either 60 character CamelCase monstrosities, or short ambiguous words like "data" (which probably contain a base64 string or an XML object).

  • I dunno LOL ¯\(°_o)/¯ (unregistered) in reply to ooOOooGa

    It would be funny if they had tried the "} {" method but failed because the search failed due to a \n in there. Probably nobody involved with the project had ever heard of a hex editor, much less knew what raw file data looked like.

  • I can be a robot if you want me to be (unregistered)

    So the company that was taken over was happy with their logging system, probably having things put in place that knew how to parse the log file, but the company that took them over didn't like it? Sounds like the standard takeover process where everything is a lie and the smaller company has to change everything.

  • SlowMoe (unregistered) in reply to Mr. TA

    { "problem": "your solution does {not}{work}" }

  • Jeff Jeffson (unregistered) in reply to I can be a robot if you want me to be

    Apart from the bit where the larger company was the one making the change to their systems and the smaller company didn't have to do a thing.

  • (nodebb) in reply to SlowMoe

    The text reader and splitting by "} {" both have the same problem that you pointed out. However text reader improves performance by preventing allocation of strings after split. The custom deserializer doesn't have this problem but it is quite a good amount of work.

  • James (unregistered)

    What's the problem? Look like a regular Java exception to me.

  • James (unregistered) in reply to SSA

    First than is a common mistake, probably Remy is overworked. The second one looks like a typo.

  • symbiont (unregistered)

    they should have just fixed the logging

  • (nodebb) in reply to Mr. TA

    If it's a typical serialiser, it's much easier than that, as there won't be any unnecessary spaces or backslashes, so the only spaces in the JSON will be quoted; you just need to find the first space that appears after an even number of unquoted quotes. Try .match(/([^ "]|"([^"\\]|\\.)*")+/g).

  • (nodebb)

    OMFG, this is now officially the worst code I have ever seen in my life. Congratulations to the author. I'll never raise my voice to another junior again. :'(

    Addendum 2019-10-18 23:33: I'll just refer them to this article and let them do the crying.

  • (nodebb) in reply to urkerab

    Looking for solutions to this moronic problem is how this started out in the first place. Use a delimiter, Who cares what it is, so long as its at least probabilistic unique (Please note: The newline character is not a good candidate for this, unless escaped)

    Addendum 2019-10-18 23:47: Even then, I wouldn't use it. It's too easy for someone upstream to make a mistake, which lands you with a newline in a string. Have you considered using a proper logging framework?

Leave a comment on “Parse, Parse Again”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article