• 0 Posts
  • 56 Comments
Joined 1 year ago
cake
Cake day: June 12th, 2023

help-circle




  • dan@lemm.eetoAsklemmy@lemmy.ml*Permanently Deleted*
    link
    fedilink
    English
    arrow-up
    53
    arrow-down
    1
    ·
    9 months ago

    On mobile: multiple top and bottom tool/nav bars that automatically show/hide themselves when you scroll. They’re invariably more irritating than if they were just pinned at the top of the page (or perhaps viewport, but ideally page - I can scroll to the top of I want it back)

    On desktop: animations tied to scrolling.

    Anywhere: any kind of popup, modal, etc that I didn’t click on something to get. Please fuck alllllllll the way off.


  • dan@lemm.eetoAsklemmy@lemmy.ml*Permanently Deleted*
    link
    fedilink
    English
    arrow-up
    18
    arrow-down
    1
    ·
    9 months ago

    The browser implements the text selection behaviour, but how infuriating it is depends on how convoluted your page construction is.

    On a simple page with no floats, overlaid elements, negative margins, absolute positioning, hidden stuff, and other css layout tomfoolery, it’s perfectly predictable. It’s only when designers do designer things does it start to break down.











  • I write Perl at work. Supporting an actively developed Perl based application.

    It’s honestly not that bad as a language, the biggest downside is that the ecosystem of libraries around it are often abandoned or outdated. The language isn’t perfect and it needs a bit of discipline to avoid creating unreadable code, but honestly it’s not as bad as its reputation might have you believe.

    It has quite a few tricks and unexpected bits of flexibility that make it quite a bit more expressive than other languages - you can really craft nice compact, elegant code with it if you want to.

    These days I use other languages too (Python, Ruby, JS, etc) but none of them quite match Perl for expressiveness.

    Oh also it’s great for oneliners. That expressiveness can be abused for brevity in some really interesting ways.




  • dan@lemm.eetoProgrammer Humor@programming.devOrder
    link
    fedilink
    English
    arrow-up
    34
    ·
    edit-2
    11 months ago

    Lossless compression algorithms aren’t magical, they can’t make everything smaller (otherwise it would be possible to have two different bits of input data that compress to the same output). So they all make some data bigger and some data smaller, the trick is that the stuff they make smaller happens to match common patterns. Given truly random data, basically every lossless compression algorithm will make the data larger.

    A good encryption algorithm will output data that’s effectively indistinguishable from randomness. It’s not the only consideration, but often the more random the output looks, the better the algorithm.

    Put those two facts together and it’s pretty easy to see why you should compress first then encrypt.