> I've found that you really need to design for it
It's an architectural step a lot of people skip, and by doing so you often end up in a situation where the only way to make things faster is via caching, and chasing caching bugs for the rest of your tenure.
One of the less appreciated aspects of model-view-controller is that usually it demands that you plan out your action before you do it - especially when that action is read-only. Like a cooking recipe, you gather up all of the ingredients at the beginning and then use them afterward.
By fetching all of the data early, you reduce the length of the read transactions to the database, allowing MVCC to work more efficiently. You also paint a picture of the dependency tree in your application, up high where people can spot performance regressions as they show up in the architecture - where there's a better opportunity to intercede, and to create teachable moments.
To make dry-run work you are best served by book-ending your reads and your writes, because if the writes are spread across your codebase how do you disable all of the writes? And if any reads are after writes, how do you simulate that in your dry-run code? It won't be easy, that's for sure.
The problem is that we tend to write code stream-of-consciousness, grabbing things just as we need them instead of planning things out. This results in a web of data dependencies that is scattered throughout the code and difficult or impossible to reason about. This is where your caching insanity really kicks into high gear.
To my eye, Dependency Injection was sort of a compromise. You still get a good deal of the ability to statically analyze the code but you can work more stream-of-consciousness on a new feature. But it does rob you of some more powerful caching mechanisms (memoization, hand tuning of concurrency control, etc)
To me, it's rather scary that even the aviation industry is now seemingly changing the UI and confusing users; HN (and a lot of other people) love talking about how much they hate a redesign of some site or software because it broke their workflow and hid/removed critical functionality, and now it's happening to pilots in life-or-death situations.
First, everyone's depression is specifically their own. While there are groups of people who react similar to each other, that doesn't at all negate the experience of other different groups and their reactions.
I take an SSRI. It's worked well for me. If the cause of my depression is a defect in the serotonin path, then I see no reason why I, with that particular problem, should wean myself off my SSRI; I don't think SSRIs repair the serotonin path, they just mitigate the defect (production or transmission).
If I had a defective leg, with no hope of repair or regeneration, I wouldn't try to wean myself off my brace.
With the wide adoption of WebGL, it's a good time to get involved in graphics. Furthermore, GPUs are taking over esp. with the advent of machine learning (nvidia stock grew ~3x, amd ~5x last year). The stuff nvidia has been recently doing is kinda crazy. I wouldn't be surprised if in 15 years, instead of AWS, we are using geforce cloud or smth, just because nvidia will have an easier time building a cloud offering than amazon will have building a gpu.
These are some good resources to get started with graphics/games
# WebGL Programming Guide: Interactive 3D Graphics Programming with WebGL
Historically, C++ has definitely been THE language for doing graphics but if you are starting these these, you would have to have really compelling reasons to start with C++ and not JavaScript and WebGL. And that's coming from someone who actually likes C++ and used to write it professionally.
This is more of college textbook if you'd prefer that but the WebGL one is more accessible and less dry.
# Physically Based Rendering & Real-Time Rendering
These discuss some state of the art techniques in computer graphics. I'm not going to claim to have really read them but from what I've seen they are very solid.
I used Dokku on DigitalOcean. Was it worth it? Honestly? No.
Would it have been worth it if there was any sort of clear roadmap for the future of Dokku, or anything coming out of Flynn other than "a first beta" (which I think I've seen at the top of flynn.io for literally months now)? Perhaps.
I eventually got fed up with the lack of direction, ditched Dokku, and went with a pure Docker-solution (which I documented here: https://medium.com/@robringham/how-interviewpad-uses-docker-...), and I don't feel like I lost much, and I don't regret moving away from Dokku. I feel like I have much more control now (at the cost of the Docker learning curve, which honestly wasn't that bad).
From my post on Medium:
"It [Dokku] worked great for a basic setup, but ultimately was simply not mature enough — minor customizations were straightforward, but anything past that (particularly around security) involved rolling up your sleeves and being willing to wade through Dokku’s source code (and that of Dokku’s plugins). Lack of direction in the project was another concern — Dokku is on hiatus, with Flynn, Dokku’s spiritual successor, in apparent eternal beta/preview mode."
To make up for losing Dokku's nice Heroku-like Git deployment, I rolled my own script-based Docker image swapping system for deployments, which has worked great.
It's an architectural step a lot of people skip, and by doing so you often end up in a situation where the only way to make things faster is via caching, and chasing caching bugs for the rest of your tenure.
One of the less appreciated aspects of model-view-controller is that usually it demands that you plan out your action before you do it - especially when that action is read-only. Like a cooking recipe, you gather up all of the ingredients at the beginning and then use them afterward.
By fetching all of the data early, you reduce the length of the read transactions to the database, allowing MVCC to work more efficiently. You also paint a picture of the dependency tree in your application, up high where people can spot performance regressions as they show up in the architecture - where there's a better opportunity to intercede, and to create teachable moments.
To make dry-run work you are best served by book-ending your reads and your writes, because if the writes are spread across your codebase how do you disable all of the writes? And if any reads are after writes, how do you simulate that in your dry-run code? It won't be easy, that's for sure.
The problem is that we tend to write code stream-of-consciousness, grabbing things just as we need them instead of planning things out. This results in a web of data dependencies that is scattered throughout the code and difficult or impossible to reason about. This is where your caching insanity really kicks into high gear.
To my eye, Dependency Injection was sort of a compromise. You still get a good deal of the ability to statically analyze the code but you can work more stream-of-consciousness on a new feature. But it does rob you of some more powerful caching mechanisms (memoization, hand tuning of concurrency control, etc)