• (disco)

    Nothing matters except Roger being away while shit hit the fan. Everyone automatically blames+hates him.

  • (disco) in reply to accalia
    accalia:
    NoSQL?

    is good at solving one class of problem, is utter crap at solving most of the problems people ask it to solve.

    What class of problem is it good for solving?

  • (disco) in reply to Scott_Coleman

    In my experience:

    Changing column type / rename table can create new one with correct type - less than a day.

    Have the QA team approve to code change for Int32 to Int64 - more than 3 months. (Note that without this, depend on what data component you use for insert record, you may experience error when the data component try to read back inserted data)

    Therefore rename the old table can create new 2 new tables - one with the same type one with correct type, and use insert trigger to connect them is the correct solution.

  • (disco) in reply to cheong
    cheong:
    Have the QA team approve to code change for Int32 to Int64 - more than 3 months

    If the table is being used as a log and the column is autoincrement, the only thing changing it can break is whatever is used to read the logs - and that isn't mission critical, whereas transaction failures are a bad idea. Currently we can't read the logs anyway because they are not being written, so in a properly modular architecture - and what we're reading suggests that we have one here - any log reading bugs can be flattened while the system is running, without ill effects.

    Getting a competent person to identify possible side effects of the change - 1 day Getting a worried management to tell QA to extract finger - 20 minutes.

  • (disco)

    It's not a WTF at all. You can't prepare for all future error events.

    The problem was easily solvable. Why is Danny looking for a new job after this minor incident? He is on some never ending mission to find a "perfect company" where no errors happen?

  • (disco)

    I'm slightly surprised that the errors table supported duplicate errors.

  • (disco) in reply to MRAholeDBA
    MRAholeDBA:
    2- Does it need to be transaction controls and ACID compliance? Maybe the app has government compliance or PCI tier 1 requirements/etc. etc. where you have to enforce this level of compliance on your logging data. Perhaps you can get this with many NoSQL solutions but this is one area I'd look at.

    That would be for transaction logging though, not general logging, and you'd want to write exactly one record per transaction. I'd still want to keep general logs separate. For example, they might go in their own database, though if they're not needed to be kept live I'd write to something non-database and then roll that periodically into the analytics DB via some sort of batch processing. The point is that running out of space (or IDs) on the (general) logging system shouldn't cause transactions to fail since general logs shouldn't be business-critical.

    But then I've seen live systems fail due to running out of space. It's not pretty…

  • (disco) in reply to Vault_Dweller

    This seems like a pretty simple change to make in a future release/patch. It even seems like an honest mistake on Roger's part. If the traffic is 10K/day and he receives even passing assurances that the traffic will remain in that range, even doing a 10X estimate to allow for over success of the business it still gives Roger's design a 58 year runway. I don't know about anyone else, but I generally don't account for the software not needing to be redesigned/patched/iterated upon for longer than the duration of the average person's career.

  • (disco) in reply to Teodor_Spiridon
    Teodor_Spiridon:
    I generally don't account for the software not needing to be redesigned/patched/iterated upon for longer than the duration of the average person's career.

    Think of all the people in the 60s and 70s who by thinking exactly that created some great job opportunities for COBOL people in the years leading up to 2000. Many a programmer had a nice sabbatical in 2000 because somebody many years before said "Hey, we could save space on tape by making all these years 2 digits. And that will speed up date operations too!".

    Teodor_Spiridon:
    It even seems like an honest mistake on Roger's part.
    It wasn't even really a mistake. We all have 100% hindsight, but I doubt anybody scoped out the future scaling to be that high. When PCs went from 32 to 64 bits, nobody called the original decision to go from 16 to 32 a "mistake", because at the time I doubt many people imagined a portable computer would ever need to address as much as 4Gbytes of RAM; and if anyone did, they would assume that paging would apply rather than a uniform address space.
  • (disco) in reply to Teodor_Spiridon
    Teodor_Spiridon:
    I don't know about anyone else, but I generally don't account for the software not needing to be redesigned/patched/iterated upon for longer than the duration of the average person's career.

    That's better than a lot of these WTF creators (article sources): they don't account for next week.

  • (disco) in reply to dkf

    Yup one great thing about I.T. is that there's multiple ways to solve the problem and several of them could be considered 'good'. I was thinking of logging batch processes, or whatever it might need. Transaction logging is a very strong feature of RDBMS too though. Yup, at the end of the day, it's whatever's best for the enterprise. It's nice to talk data on this site!

  • (disco) in reply to accalia
    accalia:
    I love NodeJS... i use it all the time myself for personal projects, it's a fun language and the design makes it easy to fall into a pit of success for certain classes of problems.... but it's no silver bullet.

    Did NodeJS stop using JavaScript when I wasn't looking or did someone manage to make a JS implementation that doesn't suck? (Hint: No)

  • (disco) in reply to powerlord

    It helps to use good libraries with Node ;)

    Example: async. Makes so many things so easy :smile:

  • (disco) in reply to powerlord
    powerlord:
    Did NodeJS stop using JavaScript when I wasn't looking or did someone manage to make a JS implementation that doesn't suck? (Hint: No)

    What I really hate is the "JavaScript is a perfect introductory language" brainworm.

    No, it's belgiuming not. It's a terrible first language. It's best used asynchronously, encourages globals, is dynamically typed, and very easily leads to code smell. If you know what you're doing, JavaScript is OK. But it's not good for introductory learning.

  • (disco) in reply to sloosecannon
    sloosecannon:
    What I really hate is the "JavaScript is a perfect introductory language" brainworm.

    No, it's belgiuming not. It's a terrible first language. It's best used asynchronously, encourages globals, is dynamically typed, and very easily leads to code smell. If you know what you're doing, JavaScript is OK. But it's not good for introductory learning.

    No kidding -- I'd rather see Python as an intro language myself. It is a language which encourages locality, tends to discourage smelly code in several ways, and is strongly (albeit dynamically) typed -- the sloppy-typing shenanigans pulled by JS cowboys simply get hit by the nope cannon when tried in Python. (It also has fantastic support nowadays for some things that other languages come up short on, like Unicode ;) )

    Filed under: please stop conflating dynamic types and sloppy types

  • (disco) in reply to tarunik
    tarunik:
    Noted :smile:
  • (disco) in reply to tarunik
    tarunik:
    No kidding -- I'd rather see Python as an intro language myself. It is a language which encourages locality, tends to discourage smelly code in several ways, and is strongly (albeit dynamically) typed -- the sloppy-typing shenanigans pulled by JS cowboys simply get hit by the nope cannon when tried in Python. (It also has fantastic support nowadays for some things that other languages come up short on, like Unicode ;) )

    Filed under: <a>please stop conflating dynamic types and sloppy types</a>

    There are plenty of languages with decent unicode support... it's just that for whatever reason, the popular languages that use dynamic types tend to have poor support for unicode (as opposed to say, .NET languages, where the String type is UTF-16 internally).

  • (disco) in reply to powerlord
    powerlord:
    as opposed to say, .NET languages, where the String type is UTF-16 internally

    So the length of a string in .NET isn't the number of characters in it? It can't be if there's a character outside the BMP present. Not unless the length of the string isn't the number of char units in it, which is even crazier. (Having an encoding scheme in use that is exposed to user code is the root of this problem. It's just the same problem that happens with “char is an 8-bit byte” except with more bits.)

    I used to think that there's exactly one sane way to handle Unicode, but now I think that Unicode itself is mad too. It's still the sanest game in town, but that town is Loonytoon McMaddsville.

  • (disco) in reply to dkf
    dkf:
    So the length of a string in .NET isn't the number of characters in it?

    Yes it is.

    Oh wait. Kind of. I guess not. Oh well.

  • (disco) in reply to blakeyrat
    blakeyrat:
    Yes it is.

    Oh wait. Kind of. I guess not. Oh well.

    Precisely. Fucking Unicode. :moving_goal_post:

  • (disco) in reply to dkf

    Well I thought it was before I looked it up. So there's that.

  • (disco) in reply to dkf
    dkf:
    So the length of a string in .NET isn't the number of characters in it? It can't be if there's a character outside the BMP present. Not unless the length of the string isn't the number of `char` units in it, which is even crazier. (Having an encoding scheme in use that is exposed to user code is the root of this problem. It's just the same problem that happens with “`char` is an 8-bit byte” except with more bits.)

    I used to think that there's exactly one sane way to handle Unicode, but now I think that Unicode itself is mad too. It's still the sanest game in town, but that town is Loonytoon McMaddsville.

    The assumption that a char is an 8-bit character would be wrong in .NET.

    It's a UTF-16 code point.

  • (disco) in reply to powerlord

    He didn't make that assumption, who the fuck are you correcting?

  • (disco) in reply to powerlord
    powerlord:
    There are plenty of languages with decent unicode support... it's just that for whatever reason, the popular languages that use dynamic types tend to have poor support for unicode (as opposed to say, .NET languages, where the String type is UTF-16 internally).

    Python 3.3 and newer do even better -- their string type is one index unit to the codepoint externally, but internally is variable-width, depending on how wide the codepoints are (so an ASCII string is still 8 bits/codepoint, while a BMP-only string is 16 bits/codepoint, and you only pay the 32 bits/codepoint penalty if you are using non-BMP characters).

    dkf:
    I used to think that there's exactly one sane way to handle Unicode, but now I think that Unicode itself is mad too. It's still the sanest game in town, but that town is Loonytoon McMaddsville.
    See above -- the Pythonistas came up with a way out of (at least part of) the madness ;)

    @powerlord -- ever seen what a naive wide-character (16bits/codepont) setup does to non-BMP chars?

  • (disco) in reply to tarunik
    tarunik:
    @powerlord -- ever seen what a naive wide-character (16bits/codepont) setup does to non-BMP chars?

    I'll admit that I haven't... but just to be on the clear side, we're all aware here that a char in C#/.NET is a struct and not a raw type, right?

  • (disco) in reply to powerlord
  • (disco) in reply to tarunik
    tarunik:
    No kidding -- I'd rather see Python as an intro language myself.

    I'd rather see Python 3.x as an intro language. 2.7 has examples of bad design. Unfortunately, the Higgs Field of programming, the programming inertial field that gives old code its mass, ensures it will be around till the heat death of the Universe or the Big Crunch, whichever comes first.

  • (disco) in reply to kupfernigk
    kupfernigk:
    I'd rather see Python 3.x as an intro language. 2.7 has examples of bad design. Unfortunately, the Higgs Field of programming, the programming inertial field that gives old code its mass, ensures it will be around till the heat death of the Universe or the Big Crunch, whichever comes first.

    Agreed -- 2.7 is a legacy language, more or less...

  • (disco) in reply to kupfernigk
    kupfernigk:
    I'd rather see Python 3.x as an intro language. 2.7 has examples of bad design. Unfortunately, the Higgs Field of programming, the programming inertial field that gives old code its mass, ensures it will be around till the heat death of the Universe or the Big Crunch, whichever comes first.

    It takes a massive sweetener to get people to take a jump to a new major version. Major performance enhancement is about the only thing that will really turn peoples' heads that much. Without that, you get a huge hangover of unconverted.

Leave a comment on “The Monolith”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article