• 1 Post
  • 103 Comments
Joined 1 year ago
cake
Cake day: June 13th, 2023

help-circle





  • I don’t really think it’s any of those things in particular. I think the problem is there are quite a few programmers who use OOP, especially in Java circles, who think they’re writing good code because they can name all the design patterns they’re using. It turns out patterns like Factory, Model View Controller, Dependency Injection etc., are actually really niche, rarely useful, and generally overcomplicate an application, but there is a subset of programmers who shoehorn them everywhere. I’d expect the same would be said about functional programming if it were the dominant paradigm, but barely anyone writes large applications in functional languages and thus sane programmers don’t usually come in contact with design pattern fetishists in that space.




  • NFS is generally the way network storage appliances are accessed on Linux. If you’re using a computer you know you’re going to be accessing files on in the long term it’s generally the way to go since it’s a simple, robust, high performance protocol that’s used by pros and amateurs alike. SSHFS is an abuse of the ssh protocol that allows you to mount a directory on any computer you can get an ssh connection to. You can think of it like VSCode remote editing, but it’ll work with any editor or other program.

    You should be able to set up NFS with write caching, etc that will allow it to be more similar in performance to a local filesystem. Note that you may not want write caching specifically if you’re going to suddenly disconnect your laptop from the network without unmounting the share first. Your actual performance might not be the same, especially for large transfers, due to the throughput of your network and connection quality. In my general experience sshfs is kind of slow especially when accessing many different small files, and NFS is usually much faster.







  • I wouldn’t recommend it. The Git documentation itself doesn’t recommend rebase for more than moving a few unpushed commits to the front of a branch you are updating. Using it by default instead of merge requires you to use --force-push as part of your workflow which can lead to confusing situations when multiple developers end up commiting to the same branch, and at worst can lead to catastrophic data loss. The only benefit is a cleaner history graph, which is rarely used anyway, and you can always make the history graph easier to read with a gui without incuring any of the problems of rebase.