For some time, I used org-mode for almost all type of note taking. I love the structure being functional without HTML rendering. However, it's pretty much locked to emacs and so the portability is very poor. I need most of my notes to be at least readable on my mobile devices.
When I discovered Obsidian, I decided to fully switch to Markdown. It's very nice that it supports vi bindings.
A lot of words that we use are arbitrary anyway. I respect people's preferences for their style of communication, but let's stop pretending that things like blacklist and whitelist are difficult to understand.
Linux as a server/headless OS has been fantastic for me. I have a home NAS running Linux that hasn't been rebooted in over a year and that was due to swapping out hard drives.
Linux as my desktop OS, not so much. I have to reboot my Linux laptop every few days for various reasons, including complete unresponsiveness to any keyboard input.
That's really weird. Which distro and hardware are you using? I can go months without rebooting. I mostly do so when Linux tells me it needs a reboot to apply some update.
Keep in mind I use my laptop for both coding and gaming (if it ever locks up it's because of a game -- which wasn't uncommon years ago when I used Windows, either).
DP as a paradigm is very interesting. From a high level view, one can appreciate the essential concepts that make it work, with things like memoization, optimal substructure, etc. It's also interesting how it relates to shortest paths problems, and greedy algorithms.
However, as you said, actually trying to solve DP problems relies on knowing the trick, and the tricks varies almost wildly from problem to problem. They're unintuitive, and difficult to derive normally. The intuition you gain from one of them could be entirely useless, or, worse, counterintuitive for another. I personally think, they shouldn't be used for interviews because being able to solve them seems to be more a matter of luck than actual competence.
If I were interviewing I'd take a LeetCode over take homes any day of the week. Preparing for LeetCode prepares you for nearly 70% of the jobs you will likely interview at.
Whereas with take homes the amount of time doing say 12-take homes can easily be too much. You end up in this weird positions where you can only devote so much time for certain take homes but with the LC & System Design you can at least prepare once and hit up a bunch of companies.
> Anyone that isn't able to write modular code using the language features is going to write network spaghetti code, with the added benefit to debug network packets and connection issues on top of everything else.
This is the most important bit. To me microservices is just another way to arrange your system into module, not much different in concept to modules and packages. Regardless of whether you’re dealing with monolithic or distributed system, if your abstractions are poor, your work and your system will suffer.
> Regardless of whether you’re dealing with monolithic or distributed system
Agreeing somewhat, but not totally ; monoliths are much easier to test and stabilise. All bigger microservices projects I know (personally, not what I read from Uber etc) have tremendous overheads compared to their monolithic counterparts. Some of them are really nicely done, but there still is a lot of overhead in support (usually the services are written by different people (and possible different languages/environments, for instance .net core, .net framework (for Windows specific services) + Typescript/node), so other people need quite a large ramp up to get into them), networking, monitoring, etc. As far as I have seen, it needs a larger team.
And it is very different from having you modular built monolith in your IDE for a spin, than doing a little (local/dev) testrun of 25 microservices + the one you are working on. I can feel the benefits but I have yet to encounter them in real life; so far I have seen (smaller; ~100m/year rev) companies going back to monolith and most of the stories I read are from very large companies with massive development+deployment teams where you actually can have 3+ people per microservice.
If you are working with 3-4 people managing 20+ (changing, forming a complex system), I don't really seen it happen (but would love to see practical examples of that) while monoliths of the same complexity/functionality (literally; I worked on a few 'just because scaling!' rebuilds from monoliths->MS(->back)) have no issues at all with that.
I’m not really arguing which one is easier to run, maintain, or anything; I was just making a point about abstractions and system modularisation.
Hypothetically, I should be able to take a well-designed monolith and “deconstruct” it into a distributed system by deploying modules individually and replacing function calls with network calls. Going the opposite direction, I should be able to do the reverse with a well-structured distributed system.
This pattern of modularisation exists across the software stack; it goes as far as the digital logic level with lumped-element abstraction. In general, we trade-off some benefits with a more complex messaging mechanism, akin to threads sharing the same memory space VS processes communicating through sockets or files. In general these are all technical details that help us accomplish what we need our system to do, but pinning the right abstractions helps us actually reason about our system.
I currently work on a project that has struggled to make actual sense for a few years now. Sure I like getting paid, but there's a growing void in my soul.
Sorry. Lecture 6 (part 2 of files and disks) talks about cache strategies...but the entire list is worth watching except for parts about class administration. Triplebyte had recommended it to me after unsuccessfully interviewing.
I can't consider myself to be an emacs superuser but I've built muscle memory around its key bindings so on JetBrains IDEs, I use my custom emacs based key maps. I used to be an Eclipse user many years ago, but when IntelliJ community came out, and it started supporting emacs key maps, I made the jump. I'm now using ultimate licensed by the shop I work at.
When I discovered Obsidian, I decided to fully switch to Markdown. It's very nice that it supports vi bindings.