eschatology

Less boilerplate, centralization, leading to less maintenance burden

A universal helm chart like this allows a lot of defaults to be set, with the values containing only the necessary changes to get the code running in the cluster (and small adjustments, as needed). When you need to add/change/remove something from all services, this can all be done through the universal chart, greatly reducing maintenance friction of getting changes through to all services from one location. In a large enough organization, there can be hundreds of services with almost exactly the same chart with the same set of things.

I think creating a helm chart makes sense if you're planning to publish it and have it used by multiple, different entities that don't own the project (think about any open-source projects really). However for internal, closed-source services, the same entity owns the code, the chart, the values, and the deployment. It adds a lot of boilerplate and there's really little reason to maintain and publish a chart as an artifact for each service.

I was thinking if we could directly tap and pump fresh cerebrospinal fluid and eliminate sleep

If you had read you would have found that government entities are exempt from the CTF fee

I really think you misunderstood what he wrote

> ...he seems to wave his hands and say it should be taught, but that's exactly what happened to him, that is traditional university

That's not true; he did experience the traditional university, but that's really not what he said how it should be taught

> I'm not exactly sure how you'd learn it otherwise.

By teaching differently (what he calls systematic debugging): figure out why students fail to grasp a concept, and fill in whatever gap of knowledge is causing it. Teach how to self-perform this process. Instead of throwing in the towel and say they won't hack their way through the rest of the course i.e. the traditional university way.

Great title; really exposes who didn't even bother reading and just goes straight out typing words

If you're wondering: the article (and the original article by Dan) is not talking about software debugging tools or techniques. Not at all. (Systematic) Debugging here is used in a loose meaning: the process of (re)reviewing information at hand and finding gaps and errors in your understanding — "to start at the symptom of a problem and trace backwards to find the source"

They are user comments: https://en.wikipedia.org/wiki/Danmaku_subtitling

Compared to regular comments on say youtube, these kinda give a time element to the comments, when they should appear in the video playback

I tried railway and northflank. Really like the UI northflank has; I think anyone familiar with Kubernetes should feel right at home. I also agree with the sentiment that railway ui is simpler.

- Just send them as multiple lines or messages

- Ending a sentence with period sounds overly serious for one-liner or short messages. If you write multiple sentences in a message it's still OK to use periods (though writing a long paragraph over multiple messages can also come off as serious, so ultimately it depends on the tone you want to convey in your message)

> Job market issues aside, don't come across as a dork.

Not disagreeing with you, but I think what constitutes as being a dork depends heavily on the situation (workplace culture, etc.). Writing like a Gen Z doesn't necessarily make one a dork.

I'd argue that the reverse is true: not writing like everyone else (i.e. completely ignoring the so called "Gen Z Netiquette") makes you a dork for being inept at adapting to the new social norm.

Here's an attempt to demonstrate how :) can come off as very toxic or passive aggressive:

---

Serious take: The new generation rejects what was acceptable to the previous generation as part of the process of developing their own identity :)

Humorous take: Sensitive snowflakes gonna sensitive :)

Moved from Heroku to Railway:

> 5. Summary/description of your apps

Simple discord.js bot interface to fire Lambda functions, about roughly 5000 times a month

> 1. How much work it took to move apps (be honest)

Roughly 2 hours and it's running! Pretty good replacement.

> 2. How much experience you had at the time of the migration

Experienced with k8s, practically a newbie with heroku-like environment.

> 3. How valuable were your learnings?

Barely any learning, it was quite straightforward.

> 4. Cost comparison

My application is pretty low resource so it remains free with the Railway pricing model.

> 6. Anything else you want to add

Related to point 4. Cost: Heroku did have more extras built-in (logging system, alerting), these are missing in Railway.

It's just a principle, used in some laws in some legal systems in some countries — nothing dictates all accusations made on the planet has to abide by "innocent until proven guilty" principle.

Nothing dictates that burden of proof is always on the accuser, especially in the internet where there isn't really any authority or agreements on subjects like this. It's just a statement/opinion by grandparent and it baffles me why presumption of innocence is even brought up like it's something to be held everywhere.

The limits are actually pretty darn extreme for CF Pages — no bandwidth limits, 20000 files, and 500 deployments per day.

It's mind-boggling for me to read the comment section with people paying (and recommending!) anything above 0$/mo for static page hosting, because most likely GitHub / CF Pages can handle more requests than that and requires zero maintenance.