• 0 Posts
  • 37 Comments
Joined 1 year ago
cake
Cake day: August 15th, 2023

help-circle
  • I really don’t see the issue there, you’re only outputting highly specific data to a website, not dumping half the database.

    Do you mean your typical CRUD structure? Like having a User object (AuthId, email, name, phone, …), the user has a Location (Country, zip, street, house number, …), possibly Roles or Permissions, related data and so on?

    SQL handles those like a breeze and doesn’t care at all about having to resolve the User object to half a dozen other tables (it’s just a 1…1 relation, on 1…n, but with a foreign key on the user id it’s all indexed anyway). You also don’t just grab all this data, join it and throw it to the website (or rather the enduser API), you map the data to objects again (JSON in the end).

    What does it matter there if you fetched the data from a NoSQL document or from a relational database?

    The only thing SQL is not good at is if you have constantly changing fields. Then JSON in SQL or NoSQL makes more sense as you work with documents. For example if you offer the option to create user forms and save form entries. The rigid structure of SQL wouldn’t work for a dynamic use-case like that.


  • I mean in my case it’s for an international company where customers use this structure and the depth can basically be limitless. So trying to find the topmost parent of a child or getting all children and their children anywhere inside this structure becomes a performance bottleneck.

    If you have a single level I really don’t understand the problem. SQL joins aren’t slow at all (as long as you don’t do anything stupid, or you start joining a table with a billion entries with another table with a billion entries without filtering it down to a smaller data subset).


  • If you only join on indexed columns and filter it down to a reasonable number of results it’s easily fast enough.

    For true hierarchical structures there’s tricks. Like using an extra Path table, which consists of AncestorId, DescendentId and NumLevel.

    If you have this structure:

    A -> B -> C

    Then you have:

    A, A, 0

    A, B, 1

    A, C, 2

    B, B, 0

    B, C, 1

    C, C, 0

    That way you can easily find out all children below a node without any joins in simple queries.



  • Well, there’s modern C++ and it looks reasonable, so you start to think: This isn’t so bad, I can work with that.

    Then you join a company and you find out: They do have modern C++ code, but also half a million lines of older code that’s not in the same style. So there’s 5 different ways to do things and just getting a simple string suddenly has you casting classes and calling functions you have no clue about. And there’s a ton of different ways to shoot your foot off without warning.

    After going to C# I haven’t looked back.


  • I mean I didn’t check how long it actually takes, it’s not 500ms.

    It opens quick, but I can’t find the default value (you can change the behavior via registry), but it’s definitely less than half a second. Especially when you’re already hovering down there it appears near instant for me.

    And let’s be honest: The only reason why multiple icons worked back in the day was because the name of the open workbook was next to it. So you had “(Excel) My Workbook 123.xlsx” in your taskbar. Which ended up as a mess when you had several programs open. Now you have one Excel icon, you hover over it and you see all your open workbooks as a preview so you select the one you want. It’s definitely cleaner.



  • Of course, but it’s mostly for reading. The color will probably be used for notes and the occasional image, for which it’s easily good enough. When I read it’s usually a foot away, while I keep my monitor at 2 feet.

    Black and white content (text) has 300 dpi atleast, so for that it’s perfect.

    E-Ink is fantastic for lots of reading and battery life, for everything else an actual screen is leagues ahead. The response time is awful too.


  • Vlyn@lemmy.ziptoTechnology@lemmy.mlKobo announces its first color e-readers
    link
    fedilink
    English
    arrow-up
    18
    arrow-down
    1
    ·
    6 months ago

    Both use E Ink’s latest Kaleido color screen technology, which has subtle, pastel-like hues and drops from a 300ppi grayscale resolution to 150ppi when you view content in color.

    I had to check just how bad 150ppi would be when dropping down the resolution for color.

    A 24" Full HD monitor has a PPI of 92. So it’s actually okay.

    I’m still using my old Kobo Aura HD (now roughly 11 years old) and the battery still lasts over a month. The screen was already decent back then, but a bit sluggish. I just checked, the old one has 265 ppi. Maybe it’s not time for an upgrade yet :)







  • Vlyn@lemmy.ziptoProgrammer Humor@lemmy.mlLeave it alone
    link
    fedilink
    English
    arrow-up
    16
    ·
    9 months ago

    Yeah, I’ve worked with the leave it alone types. What do you get in return? Components of your system which haven’t been updated in the last 20 years and still run .NET 3.5. They obviously never stopped working, but you have security concerns, worse performance (didn’t matter much in that case) and when you actually need to touch them you’re fucked.

    Why? Because updating takes a lot of time (as things break with every major revision) and on top of that if you then decide not to update (yeah, same coworker…) then you have to code around age old standards and run into bugs that you can’t even find on Stack Overflow, because people didn’t have to solve those in the last 20 years.






  • I still haven’t found a proper command or tool to do a multi-commit git blame.

    Like I want to know who changed the logic in this line. But the last commit was a format refactor. And the commit before that just changed a tiny detail. So now I’m digging through the entire file history just to find the spot where this one line was introduced or actually changed.

    If you have any tips for that, I’m all ears.