Author here. I wrote this many years ago (2017?) while exploring techniques to create art that I could put up on my walls :-) If you enjoyed this article there are more similar ones linked on the main page: https://sighack.com/
Can I ask how you find the fastest links between countries and the servers for them? (Background: during my vacation last month I was playing an MMO from the APAC region but with servers in Germany, and it was crazy high latency. It made the experience quite bad. I wanted to rent my own servers and build a faster link for myself.)
I'm also motivated by small wins. However, at some point you have to face the realization that you need to power through some drudge work to get to those wins. I don't know if there's an easy workaround.
What I found worked best for me was:
1. Being passionate about the goal. This in isolation is not enough, but when you're already working on something, it helps for coping with the inevitable roadblocks and the frustration that follows.
2. Launch asap. Then iterate. Iteration is more fun than launching because the former provides quick wins while the latter requires expending enormous energy upfront before you see a win. The approach that worked for me is to pick the minimal features I need for the end product and build towards that with (metaphorical) blinders on w.r.t. all other features. Really think about the bare minimum features you need, and then slog through till you hit it. It's basically the path of least resistance to get to your MVP. Once I hit that, iteration is more fun.
3. Consistency beats extreme bursts of productivity. Try to improve things a little at a time. This isn't always possible, but still attempting to tackle things in digestible chunks helps me with procrastination. Whenever I do bursts of work, I get the results but also burn out on that particular project. I can't look at it for a while afterwards. It's like squatting five reps of 150kg at the gym and recovering for the rest of the week vs. lifting five reps of 75kg for three days in the week. The difference in total weight moved at the end of the week is huge.
4. Energy management. The above point is one example of energy management over time management. Attempting to micro-manage my time to gain efficiency never seems to work for me in the long run. Instead, thinking about it as managing my overall energy tends to be more fruitful. Eat healthy, daily exercise however little it might be, good sleep, and some social interaction all help. All those will improve overall energy and psychological outlook. Beyond that, work during your peak energy hours and temporarily remove distractions that will waste them.
5. Get feedback. Show it to your target community and gather feedback. This is the best form of external motivation you can get. (Of course this may also be very hard to get depending on the community you're targeting.)
Amazing how Stripe consistently executes fantastic solutions for all the very real and difficult pain points of building commercial products on the web. Fantastic work!
Very nice! I like your way much better than the one in my writeup :-) I'll refactor things over the weekend to use this approach if that's OK with you.
Agreed. The patterns are the most interesting bits. Actually, just the fact that there exist patterns is pretty amazing. It's unfortunately hard to see them through the notation and that made it very unintuitive for me for the longest time.
Unfortunately the momentum that Western music notation has, with a few centuries of tradition behind it, means one has to work within that system.
I used to be confused on why modes required modifying certain notes from a major scale until I tried deriving them in the way shown in the article.
Of course, once you understand that, the way you go about memorizing and practicing is probably easier the way you described; that is, deriving modes in any given key by modifying notes of the major scale using the circle of fifths.
> Do I have to read x86/arm spec + pcie spec + acpi spec + usb spec?
Pretty much, yeah. There's a reason not everyone is sitting around writing hardware drivers.
The alternative is reading through Linux kernel code. However it typically requires you digging through many layers of abstractions to get a fuller picture.
Generally, x86 is generally more mature, and the specs tend to be fairly large. ARM documentation should be a little simpler to dig into.
Honestly, this article presents a fairly ridiculous comparison. You could bump deploy times on Heroku to 20 minutes and I would still use it without a second thought. At best, I'll complain a little louder.
Here's step 1 from the article: The documentation says to create a new AWS IAM role with credentials for automation.
At this point, you've already failed. You are forcing more complexity on me than I have to care about when using Heroku. And the underlying complexity is worse. You need to be familiar with Gitlab's CI/CD pipelines. Your included YAML file hides all the complexity and uses all your magic variables: https://gitlab.com/gitlab-org/5-minute-production-app/deploy...
What happens when something breaks?
Quite literally, the only downside of Heroku is the pricing. Even that, I question for smaller teams where operational overhead can get way worse. I have yet to come across anything in the ballpark.
Anyway, this may still be a decent setup for deploying an app to AWS perhaps, but comparing to Heroku in the title is way off base.
The graph approach (e.g. Wikipedia) is pretty much useless without a search engine (e.g. Google) directing you to the first useful node in the graph. When is the last time you just jumped onto the Wikipedia homepage and found your way to the information you wanted?
So once you accept that a graph structure is useless without powerful search behind it, the advantages of the tree approach are more obvious: it provides a basic search mechanism through hierarchy, and still allows for a graph approach (via linking and duplication of content in multiple categories).
Also, maintaining documentation sucks. So there's that...
Can anyone more knowledgeable comment on the details and significance of the comment regarding the frequency of formation being a normal distribution?
> Straight away, they noticed a statistical pattern in the frequency at which the crystals emerged; it followed what’s known as a normal distribution, which has long been theorized but only now experimentally verified.
Clean, well-documented projects showcasing demos that end up having huge impact. Some of these projects single-handedly spawned entire tech ecosystems. (see FFMPEG, QEMU, JSLinux)