• Cyclops66 (unregistered)

    Frist!

  • ray10k (unregistered)

    So, going by the "out" keyword, this is in C#?

  • Alex (unregistered)

    I have to admit I'm probably not smart enough to solve Andre's problem either. Sure, just use a data structure to pass the necessary information around before writing it out to a file, but I'm stuck trying to figure out why the system would be hanging on the IniHelper calls … or is there something I'm just missing and the entire joke here is writing data to a file just to pass it between methods?

  • rre (unregistered)

    I'm confused about the "Complementary information" variable... (the space)

  • Medinoc (nodebb) in reply to Alex

    Frequent open-write-close cycles on a file usually run afoul of the antivirus trying to scan the file between each cycle. If you try to open it again (at least, for writing) before the antivirus is done scanning it, you'll get a lock conflict.

  • sdebeli (unregistered)
        MyMutex.WaitOne();
        File.AppendAllText(outputFolder + "BufferOutput.tmp", "\r\n" + Buf, Encoding.Default);
        MyMutex.ReleaseMutex();
    

    This part shows high promise.

  • NickJ (unregistered) in reply to Cyclops66

    The 'frist' joke, once it was brillant, but is now getting old.

  • PWolff (nodebb) in reply to NickJ

    Oh come on, it isn't THAT old.

    I don't think there's an older reference than the one found recently about 30 km west from here in the Neander valley (Neandertal) - a cave inscription that translates to

    Uggu (04/01/12438 BC) FRIST!

    Addendum 2016-03-31 08:08: (I miss a preview and/or a true edit feature.)

  • 5UpMushroom (unregistered) in reply to Alex

    Just imagine this system sending data to multiple scales at the same time. Each instance of the program writing data to this single .ini file and then, after some further processing, reading it back out again. The file is not only a bottleneck, but lord only knows if it was changed in between the write and read. I would imagine if Andre noodled on this enough his next trick would be to generate a GUID or similar non-unique string and append it to the .ini file's name, then figure out how to pass that guid around so it could get to the read function. Perhaps in "A Meaty Problem II: Face Palm".

  • rre (unregistered) in reply to 5UpMushroom

    They did not tell anything about the frequency of the data. So, I think this is not the problem Even when this is a problem: This mix the data, but it should not lock the file...

  • Nicholas "LB" Braden (github)

    Oh god, using a file in place of global variables is even worse than just using global variables...

  • Anonymous Coward (unregistered)

    See, he should have just made them static (I've seen static abused too many times I guess) properties, that would have solved everything...... until eerie concurrency issues stated to show up anyway.

  • Steve_The_Cynic (nodebb)

    Look, dudes and dudettes, don't you know about the three-parameter limit for functions in C#? Of course he couldn't do it the right way, and we all(1) know that stamp coupling is a bad thing, so a "bundle" struct is all wrong as well.

    (Yeah, I know, I'm out by a day, sorry.)

    (1) Well, of course, OOP makes ALL function calls stamp-coupled via the this/self "parameter"...

  • Anonymous (unregistered)

    Hmm. Data coming in, data going out and some traces of xml - why not BizTalk?

  • Toby Johnson (google)
        Buf = Buf.Replace("<UnitPrice>", UnitPrice);
        Buf = Buf.Replace("<Components>", Components);
        Buf = Buf.Replace("<Birth>", Birth);
        Buf = Buf.Replace("<Breeding>", Breeding);
        Buf = Buf.Replace("<Felling>", Felling);
        Buf = Buf.Replace("<Carving>", Carving);
        Buf = Buf.Replace("<Category>", Category);
    

    What's Felling, papa? Papa, what's Felling?

  • That one guy (unregistered)

    Heh. I saw the problem pretty quickly myself. People under pressure tend to make those minor mistakes with disastrous consequences. At least it was a pretty simple, easily overlooked one this time!

  • Paul Neumann (unregistered) in reply to Toby Johnson

    Well, it comes after <Birth /> and before <Carving />. TRWTF is <Breeding /> coming after <Birth />.

  • Johan_B (nodebb)

    Easy reader : but how does the story end?

    Also, because of the "GTIN_ProduitFini" reference, it looks like the submitter was from a French-speaking country.

  • Shoreline (nodebb)

    Useless manager is useless.

    "After a bad stretch of frequent outages, Pierre, the plant manager, had enough. Furious, he called the entire IT department into a conference room to give them a dressing down. He had a slide deck with charts and graphs documenting each of the IT failures that had impacted meat packing. “We pack and ship meat,” Pierre said as he paced in front of the projector screen. “This company’s been doing that since before you had this newfangled computer garbage, and we’ll keep doing it when computers get replaced by robots or whatever. All I want to know is, why are you screwing up my goddamn plant?”

    If problem is with one guy, guy has a problem. If problem is with entire team, manager is the problem.

    I've already worked for this scato-vocal individual, and if he talks to me like this again, his body will be better used as fertiliser. I'll be civilised: I'll tell him my case for this, and that I'm deadly serious about making it happen before actually doing it.

    Side note: Is this how we have to post against articles now? It's foreign and I don't like it, which is pretty much Trump's stance on everything.

  • Jordan (unregistered)

    Oh man... this one. This one is the worst I've seen in a while. I'm having flashbacks to vb6...

  • Tsaukpaetra (nodebb) in reply to Toby Johnson

    What's Felling, papa? Papa, what's Felling?

    What? You pass by Birth and Breeding, but felling trips you up? Felling: Making something undergo the process of falling! Obs!

  • Tsaukpaetra (nodebb) in reply to Shoreline

    Side note: Is this how we have to post against articles now? It's foreign and I don't like it, which is pretty much Trump's stance on everything.

    Yeah, do you like it? It was custom hand-built because (for some reason) migrating off of Discourse meant the comments system could no longer be coupled to the articles anymore.

  • _DbConnectionString (unregistered) in reply to That one guy

    Do you really see it? I see no small problem with that code, he didn't understand method arguments, that is a serious problem. As others have said, pass a struct or (judge my abuse of memory if you want to) a class, and pass it to the next method or make a monstrously long method that does both but dont write to a file if you dont have too.

  • Making it up (unregistered) in reply to Tsaukpaetra

    Yeah, do you like it?

    I don't. Discourse was better.

  • Matt Westwood (unregistered) in reply to NickJ

    "The 'frist' joke, once it was brillant, but is now getting old."

    YMBNH: it's "brillant".

  • Matt Westwood (unregistered) in reply to Matt Westwood

    Whoops sorry, my mistake, you did write "brillant". Apologies, my eyes are getting as old as Frist.

  • LTT MDM (unregistered) in reply to Alex

    Agreed, the joke isn't obvious to me, either. Maybe I'm just slow in the uptake, but I would like to know what I'm missing. I also don't program in C#, so maybe I'm trying to understand a joke in a language I don't speak. LOL

    I can only make a few generic assumptions as to what the joke is:

    -- The MyMutex object isn't created here, so maybe trying to release a Mutex object you didn't create is a problem; -- The outputFolder variable isn't associated with an object, so maybe that's a problem? -- One could avoid the ugliness of file I/O by storing these variables in an array -- an associative array, maybe -- and passing the address of the array as a single argument to the UpdateData() and SendVariablesToScale() functions. You could even add the paths to the internal database file and scale file to the array. That would completely sidestep the three-argument limit to function calls. -- Or hell, avoid the argument-passing nightmare altogether and just combine the two functions into one: read from the internal database, write to the scale file, exit.

  • Roflo (unregistered)

    Is the problem the fact that the content is being appended to the same file over and over again?

  • Erik (unregistered) in reply to Anonymous

    Haha! I hope you're joking... (Sarcasm and I aren't the best of friends...)

    If global variables are the "bad" thing they want to avoid they're running in the same system, the same execution. No need for Biztalk..

    But I guess he couldn't see the o[bject]vious solution for all the static noise in there...?

  • PaulMurrayCbr (unregistered) in reply to _DbConnectionString

    "Sure, just use a data structure to pass the necessary information around before writing it out to a file,"

    Data structure? He's getting back a bean with all of the fields in it! Return that!

    He has a function named updateData. It's passed a parameter named Data. With an initial uppercase. But this function doesn't update anything, 'update' is not a verb here, it's a noun. The function should be called 'getUpdateData'.

    Everything is wrong. He re-reads his template off the file system each time something gets weighed, for God's sake!

  • PaulMurrayCbr (unregistered)

    “Because that b-” Andre caught himself and glanced around the cube-farm. In a whisper, he said, “Because Elene said I’m not allowed to use global variables, even when they totally make sense. This was the easiest way I could come up with to pass product details to the SendVariablesToScale function.”

    Fire Elene, too. As we see, you can't turn a bad coder into a good one by imposing arbitrary code-nazi rules. If her job is to supervise, and that's how she goes about it, then she doesn't know how to do her job, either. The problem with this dude wasn't that his code was full of globals: that was the symptom of an underlying cause, the cause being that he just doesn't get it. It's as misguided as setting line-count limits on classes - people work there way around things like this in even worse ways, as we see here.

  • Guest (unregistered) in reply to Making it up

    Your comment is dated 3/31, are your clocks right?

    Either you're a day ahead of the rest of us, or you're Atwood.

  • Olivier (unregistered)

    Am I the only one wondering why he used a temporary file?

    Andrè mentioned global variables, so it is all happening inside a single program. So SendVarialeToScale could easily receive Data as an input.

    Or am I missing something?

  • Berend de Boer (google)

    Was the swearing really necessary in this article?

  • ac (unregistered) in reply to Berend de Boer

    swearing?

  • dkf (nodebb)

    So… is it InfoComplementaires or Complementary information as a variable name? I'm relatively cool with variable names having spaces in, but a programming language that provides automatic translation of variables from French to English would be a little strange, as it would require an interesting AI in the compiler to not make things much worse.

  • Icke (unregistered)
    Comment held for moderation.
  • Joseph Osako (google) in reply to Making it up

    And here I didn't think that was an idea humans were capable of expressing.

    Addendum 2016-04-01 14:00: As I've often said in this message board (both before and after the Great Forum/Comments Schism on March 2016), the biggest problem with Dis-Curse was Atwood's refusal to listen to his users, and his belief that all the bug reports were just kvetching from Those Fools Back At The Institute who failed to see his grand vision (== "hallucination", I suspect).

    Addendum 2016-04-01 14:04: Admittedly, this makes me different only in that I am only compelled to tell everyone about my wondrous epiphany, without trying to ram the use of it down people's throats.

    Addendum 2016-04-01 14:06: Yet. We'll see how sane I really am after I've implemented some of it.

  • mainframe web dev (unregistered) in reply to Icke

    There is no file handle close in the writer function. When trying to read in the following function, going to hit intermittant file lock errors depending on how quickly the non-deterministic VM will descope that C# method and structrures (meaning the file writer will close when the writer object is garbage collected at some point in the future). With that said, the funny is the problem is the coder, not the code. Should use direct parameter passing into the module and not pass temp files. But then, maybe this guy came really likes asynchrnous queue / ESB patterns and really just wants some IBM MQ or Tibco EMS or MSMQ. The problem is file handles as stated in the error message.

  • metzomagic (unregistered)

    I've been reading this site on and off for years now, but just as a lurker, never commented before. It's always very entertaining. We can all laugh at the misfortune of others, knowing that we did the same kind of things when we first started off... or, maybe not :-)

    Looks to me like the problem here is that the Input.ini file is being used in the place of global variables, so the code is not re-entrant (but it needs to be!). There's a mutex on the output file, BufferOutput.tmp, but what about Input.ini if messages need to be sent to two scales at the same time?

  • Crunger (nodebb) in reply to sdebeli

    It seems obvious that the problem is multi-threading. It seems like Someone told Andre that a Mutex was necessary, but again Andre did not drink deeply enough from the well of knowledge.

    If a mutex is required, the mutex needs to last from the first moment the program starts modifying files on disk, until the temp file is fully under control of the recipient. (We don't see the code where this hand-off occurs, so it might be inherently unsafe.)

    The comedy of passing variables via file merely increases the risk footprint -- the problem was "usually" the INI file, which implies it choked on the TMP file sometimes..

  • Icke (unregistered) in reply to mainframe web dev

    ah okay. Thanks. Yeah, closing files is something I have seen forgotten many many times...

  • urkerab (nodebb)

    I really want to see the calls to UpdateData and SendVariablesToScale. I like to think they're consecutive.

    P.S. How do you do formatting in these comments?

  • Hoffmann (unregistered)

    Besides the obvious:

    1. why isn't he using method parameters or class properties or calling everything in the same shitty function (!!!)?
    2. why isn't he closing the ini-file?
    3. why isn't he using the exception part to handle the total fuck-up he wrote?

    Other questions arise: 4. why is the the Buf-data APPENDED to the file? That may take longer and longer each time 5. why are the functions static? 6. why isn't he caching the template? 7. why is IniHelper.WriteVariable as well as IniHelper.ReadVariable called with "Input" as it's third parameter? 8. why is he writing not the same variables to the ini-file as he reads and later sets? a) saved but not loaded/set: id, GTIN_ProduitFini, Weight, FlagModif (what's going on with this one?) b) loaded but not saved/set: DLC c) loaded/set but not saved: BATCH, DLC, Birth, Breeding, Felling, Carving, Category, Type d) set but not loaded/saved: UBD e) translation problems: InfoComplementaires <-> Complementary information and GTIN_ProduitFini <-> EndProduct_GTIN I assume there is more to the ini-file than translation f*ck ups and global variable replacement.

    Minor comments: 9. don't call it "import folder" in the comment and "outputFolder" as a variable 10." send the file to" or "save the file in" 11. either path variables contain a slash as last char or not, be consistent 12. if E.Message contains multiple lines every line should be prefixed with "(NEXT)"

  • DavidTC (unregistered)

    I'm confused as to why there are even two functions in the first place. I mean, yes, he's an idiot who doesn't apparently know how to pass variables, but why did he set up a system where he had to pass variables?

    He has to save every currentProduct.* to the ini file, define a bunch of variables, file them in from the ini file, and then replace them in the template.

    Just...replace them in the damn template, in the first function, using currentProduct.*, to start with. You idiot.

    And as an aside...to people asking why they're not caching the template...they're not caching because it's a goddamn scale system that can't possibly weigh more than one animal per second, and thus aren't at anywhere near the limitations of the system, so have no need to set up the complexities of caching. Um, duh. (Someone go get the 'premature optimization is the root of all evil' mallet.)

Leave a comment on “A Meaty Problem”

Log In or post as a guest

Replying to comment #:

« Return to Article