• Raphael (unregistered)

    Wait, was the assignment to create a class that you could serialize this particular schema definition to and from? As opposed to JSON data conforming to said schema?

  • Naomi (unregistered)

    I'm actually not sure what's so wrong with this code (taking days to implement it is a different matter). What would be "the right way"? I'm always eager to learn (or argue!) :)

  • P (unregistered)

    inb4 "TRWTF is 'He was fired the next week.'"

  • bvs23bkv33 (unregistered)

    not bad enough to fire anyone

  • (nodebb)

    The JSON looks like a schema describing the config. The actual config class would be something like: class Config { public bool enabled; public string keyId; }

  • Mohammed Shahim (github)

    So what IS the right way? its a 5 minute job and shouldn't take 2 days. I see no problem other than that.

  • (nodebb) in reply to Raphael

    That was my first question. I think he was fired because he lacked the basic skills to understand what was provided to him.

  • Steve (unregistered) in reply to P

    My exact thought!

  • Naomi (unregistered) in reply to Mr. TA

    This is why I shouldn't comment before I've had my coffee. :/

  • Nick (unregistered)

    To be fair - this is the first time I’ve seen a JSON schema myself - I’m quite intrigued by this :)

  • Angela Anuszewski (google)

    I don't think that "14 years in the industry" comment is very fair. Not everyone writes web services or is passing around serialized data.

  • Brian (unregistered)

    If I had this assignment, I probably would have done the exact same thing. Pretty much every time I've had to make a class (or set of classes) for a JSON object, it's always been defined by example. You know, "here's some JSON that this API returns, make some C# classes to deserialize it". I'd never even heard of a JSON schema until right now.

    Sounds like this is more of a misunderstanding than a WTF.

  • 🤷 (unregistered) in reply to Brian

    May I introduce you to the "System.Text.Json" namespace? There are tons of helpful nuget packages that pretty much handle the de-/serialization for you. No need to "write C# classes to deserialize it", imo.

  • (nodebb) in reply to Brian

    The head is not only for chewing, you know.

  • Rich (unregistered) in reply to Brian

    I think Brian's point is, and it's a good one, it's that this is a poorly worded assignment, especially given JSON schema is not exactly well known. Is the JSON itself something you want to store or is it a meta-document defining the schema of something you want to store. The design almost got a bit too cute.

  • MiserableOldGit (unregistered)

    Surely the request was for a class to handle configuration options, whatever they might of been? Isn't TRWTF (apart from not looking serialising/deserialising JSON) that he didn't work out all that JSON header stuff is not the configuration he was meant to be dealing with?

    I suppose it is the sort of thing you get from people who just don't have the first clue about the new-fangled thing they've been asked to deal with and try to use it as they would things they are familiar with. Funny I guess, but sounds more like a smart-arse deliberately stitching up the team dinosaur than a proper example of this guy's incompetence.

  • Wizofaus (unregistered) in reply to Naomi

    First thing I googled was generate java from json schema. Lots of free online tools to basically spit out the whole class for you. But what he's done here is write a class to represent the schema itself, rather than the object defined by it.

  • Worf (unregistered)

    I took it as the class read a JSON file that contained a bunch of settings for various features. The purpose of the class was to allow you to test for those features - to see if they were set or not.

    Thus, besides the initialization functions, I believe the only function is a boolean that takes in the keyID and returns if it's enabled or not. Say "bool featureEnabled(string keyID);"

    You see, the application would say "if (featureEnabled("foo")) { foo(); }". That's it. The class reads the JSON, and when interrogated returns if a feature is enabled or disabled so the application and respond appropriately.

    I don't care for a class that simply lets me traverse the JSON programmatically - that's not what I want to do.

  • Guri Bashlir (unregistered)

    If this site and experience are anything to go by, anyone who calls himself an "architect" is inevitably going to be like this. They know nothing more than how to turn everything into an object.

  • (nodebb) in reply to Guri Bashlir

    Experiences vary. I've known two architects. The first was very smart. No complaints, he was a fierce guy, though. Second had poor communication skills, but was pretty smart about programming in general and about many aspects of the system. He fixed a problem I'd been working on for a week. (He had, however, been on the project for 10 years whereas I was a newby there.)

  • (nodebb)

    At first I read this article and thought that the solution was actually fairly well-designed (except boilerplate and unnecessary getters and setters). Then I read in the comments that the provided file was a schema describing valid configuration files. I don't think the author of this article realized this, since she wrote "a config like this".

    I personally believe that fitting received JSON into statically typed classes is a good thing, because it has a single point of enforcement that the received JSON is of the proper format. After you "try-parse" the JSON, you don't need to do a try-cast every time you read from the JSON object.

    I read an article a while back: https://lexi-lambda.github.io/blog/2020/01/19/no-dynamic-type-systems-are-not-inherently-more-open/ I don't fully agree with the article, and I haven't used Haskell or aeson, but I personally like statically typed fields better.

  • (nodebb) in reply to Angela Anuszewski

    Yeah, long years in an industry doesn't mean you deal with JSON. If you haven't seen it you'll overengineer, which takes time. 2 days is nothing, for the record.

    That said the class design looks like a mess... (I don't do JSON ¯_(ツ)_/¯ )

  • (nodebb) in reply to 🤷

    This is what I'd do.

    Don't reinvent the wheel if you know it probably exists.

  • Oldgit (unregistered)

    Ermm.... isn't json all about data serialisation to/from server and browser? So why they using it for configuration? Is the "not so experienced guy" trying to be trending and using tech for techs sake?

  • Oldgit (unregistered)

    I hope that submitter realises the folly of being young

  • Robert (unregistered)

    It literally took me 5 minutes to read up on JSON Schemas. The real WTF is not looking up or asking for help for things not outright understood. Worse, taking 2 days to do it.

  • Marko (unregistered) in reply to 🤷

    If you haven't noticed, this is Java, not C# code.

Leave a comment on “Simple Class”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article