[–] 1 point 2 months ago*

Same, although I did wish I could like, just select text with my mouse properly, or move the cursor to a place by clicking there, delete blocks without cutting them, and/or remember the copy/paste/undo shortcuts...etc

  • source
  • parent
  • context
  • [–] 3 points 7 months ago

    That's a bit too naive. Propaganda, marketing for products, fake reviews, referral links (or just links to promote blogs/new sites) all make money indirectly. There absolutely is money to make in any popular social network and due to its architecture fediverse is potentially even more susceptible to it. Without a plan to address it, it is only a matter of time before it becomes an issue (unless it stays a niche small community forever but I am skeptical even those are free from bots and malicious actors)

  • source
  • parent
  • context
  • [–] 4 points 9 months ago

    The problem is obvious however, most people just want a quick and easy component library and don't care about stuff like that. I often fall into that group too, because making new components from scratch is boring and annoying and then often end up looking worse with fewer features anyway than if you just copy pasted the messy shadcn amalgamation

  • source
  • [–] 11 points 1 year ago

    I really wish gimp had a command palette, kinda like the Ctrl+Shift+P thing in VSCode. As a beginner in gimp I often know approximately what I want to do, but not how to find that thing and just being able to type "crop", "scale", "add layer" and have it happen would be much easier than having to look for it through various menus.

  • source
  • [–] 1 point 1 year ago

    I still don't think it's nearly as convenient as being able to just see the changes side by side and click the one you want (or both). You can even easily modify the final outcome in the 3rd preview panel, in case you need to do a quick fix after a conflict resolution.

  • source
  • parent
  • context
  •  

    cross-posted from: https://programming.dev/post/6513133

    Short explanation of the title: imagine you have a legacy mudball codebase in which most service methods are usually querying the database (through EF), modifying some data and then saving it in at the end of the method.

    This code is hard to debug, impossible to write unit tests for and generally performs badly because developers often make unoptimized or redundant db hits in these methods.

    What I've started doing is to often make all the data loads before the method call, put it in a generic cache class (it's mostly dictionaries internally), and then use that as a parameter or a member variable for the method - everything in the method then gets or saves the data to that cache, its not allowed to do db hits on its own anymore.

    I can now also unit test this code as long as I manually fill the cache with test data beforehand. I just need to make sure that i actually preload everything in advance (which is not always possible) so I have it ready when I need it in the method.

    Is this good practice? Is there a name for it, whether it's a pattern or an anti-pattern? I'm tempted to say that this is just a janky repository pattern but it seems different since it's more about how you time and cache data loads for that method individually, rather than overall implementation of data access across the app.

    In either case, I'd like to learn either how to improve it, or how to replace it.

     

    It is a common sentiment that managing dependencies is always a big issue in software development and the reason why so many apps come pre-bundled with all the requirements so it reliably works on every machine.

    However, I don't actually understand why is that an issue and why people generally bash npm and the way it's done there. Isn't it the simplest and most practical solution to a problem - you have a file which defines which other libraries you need, which version, and then with one command you can install them and run the program?

    Furthermore, those libraries and their specific versions can be stored elsewhere and shared across all apps on a system so you can easily reuse them instead of having to redownload for each program individually.

    I must be missing something since if it were that easy, people would have solved it years ago and agreed on a standardized best way, so I'm wondering what is the actual issue and a cause of so many headaches.