hacb

I agree with you, but in my case I'm teaching programming, so doing table-top assignments is a no-go for me. I wrote too many C programs with a paper in a pen to know how bad it is. :)

That's why those assessments are tailored to be done at home, and then they send me an archive or a Git repo link.

I'm using LocalSend for local network sharing needs (typically stuff between my laptop and my phone). It works like a charm, and is really easy to use

https://github.com/localsend/localsend

I hope you enjoyed your dinner! I'm currently in bed, sick as hell while family and friend are having fun downstairs. I guess it's my illness quota for the year :)

Happy new year !

What "Detect Cloudflare" is for, in terms of privacy?

If my favorites subreddits go to Discord, I'll simply not go there. Discord has nothing to do like a forum, it is almost impossible to search for valuable information, and is really hard to use when dozens and dozens of people are talking simultaneously.

I really don't get why so many people want their sub to go to Discord tbh.

I'm glad they are so transparent about it.

Initially, we were using kube-downscaler to do this. It stops a namespace at a given time and restart it in the morning. However, a lot of namespaces (= dev env in out case) were restarted for nothing, so we created our own tool that stops them at 8PM, and restart them when the dev runs a command with our internal CLI.

That will also add a lot of overhead/maintenance cost that we can't currently handle.

We currently have ~40 microservices running (for the same number of devs), and having the full stack on a laptop is not possible. Especially with 80% of the devs having MacBook and Docker in a VM.

Also, this allow us (the infra folks) to chose how devs will work (partially), so it's easier for us to debug when they have issues because we do not have to deal with custom Makefiles etc.

In our case, those dev envs are actually feature envs: they are a copy of staging with only the microservice they are working on that differs. So it is impossible for those env to end up as prod stuff for us. However, each FE is an almost exact copy of staging, and each dev has 1-2 running FE, so it requires a lot of compute and stopping them has a real impact

We kind of already have. We built a CLI that allows them to create/update/delete/list all their dev envs, so they have all the tooling needed. Also, we are still a small/medium sized company, so we often had the chance to talk with them to expose this issue, but in the end it never really worked.

Fun to read this comment, as I'm part of the team that deployed the exact same measure as for your wife: we now shutdown dev environments each day at 8PM. We decided to do so because over the weeks, we saw that a lot of devs "forgot" about their dev envs and they were up & running for 6+ months for absolutely nothing. On the other side, we are constantly requested to reduce infra costs, and dev environments (even unused) cost a lot.

In the end, I'm glad we deployed this.

Now I know that some people get pcap files with bug report and I'm jealous

Tip: if you download OsmAnd from F-Droid, you have the premium version for free

According to another comment, only Tom Cruise is fake

What about testing? In my company, before any code goes to production it has to go through hundreds if not thousands of unit tests. This can't be done on a dev laptop (see XKCD #303)

About take away #2:

> I spent several hours fixing a problem and I learned next to nothing in the process. This trick is unlikely to be useful again. By the time I encounter something similar, it is likely I will have forgotten about the solution.

This is why it is important to keep a personal knowledge base/documentation. Mine is full of things I'll probably never encounter again, but I know it may be useful one day or another.