nitely

One application not mention in this thread is to traverse trees, like in the old forums where you had many levels of categories/subcategories. AKA hierarchical query. SQLite already has support for this[0]. It seems they are supporting multiple selects now.

[0] https://sqlite.org/lang_with.html

The SDK could have a command line tool (or option) to dump the config in JSON format, if that config is meant to be consumed by other tools. I can come up with examples where config files are a bad idea all day long. Bottom line is neither is a silver bullet, and there are always trade-offs to be made.

> I've seen some outright tragic Django setups with major companies.

Well, the same thing can be said about pretty much anything. I've seen good and bad Django setups, so what?. The point is configuration as code works well if you know what you are doing. A config minimal language (toml, yaml, etc) may also work well as long as you don't need something that's not supported by it, and as long as you don't need to debug it.

> Having a programmable config is how you end up with horrible interdependencies where function f() does foo, and you can't figure out why it's not blowing up, until you realize the only caller is dynamically configured in staging_env_4.json which is emitted by config_generator.py which always ensures the precondition for foo, but only if it's also generating prod_env.json at the same time, but it's OK because we always do that anyway, and you're not sure if you need another cup of coffee or whiskey.

That sounds like the opposite of what the article describes. The point of having configuration as code is having all code related to config in a single file. There is no config generation, nor config loading.

As well as every company using Django (the most popular Python web framework)...

TBH, the real problem is AWS bills cannot be capped in any way (you can setup an alarm, though). It's unreasonable to expect a programmer won't make mistakes.

> complex/nested responsive grids are not simple, unfortunately.

How does utilities make complex/nested responsive grid simple, again? I'm arguing semantic css is simpler than using utilities all over the HTML, not that it magically makes responsive design easy.

> your grid has zero media queries in it, which means whatever grid classes you were using before were not responsive - which is where 90% of the complexity lives.

There are some in the examples [0][1]. Both for responsive design and nested grid, sadly not for both at the same time. It's not much more complex, though, well I guess it depends on how complex are we talking about. Anyway, CSS Grid makes semantic layout a lot simpler now.

[0] https://github.com/nitely/semantic-flex-grid/blob/gh-pages/s...

[1] https://nitely.github.io/semantic-flex-grid/

Sass removes most of the cruft. I made a semantic flex grid many years ago, and the result was a lot more clean than using utilities, even in the css side [0]. This was before CSS Grid Layout was widely supported, nowadays you can use plain CSS grids and get similar results.

[0] https://github.com/nitely/semantic-flex-grid/

The many blog posts (from people doing it) suggesting working remote and traveling the world is as easy as getting a remote job and travel the world:

https://www.theladders.com/career-advice/how-i-perfected-tra... https://doist.com/blog/travel-remote-work-digital-nomad/ https://www.refinery29.com/en-us/remote-work-digital-nomad https://www.thebalancecareers.com/working-remotely-while-tra...

etc

Here's a US tax attorney talking about it:

https://www.whereverwriter.com/digital-nomad-tax-questions/

Isn't the promise of working fully remote that you can be a "digital nomad"? What if I just want to visit poor countries while my home is in the US?

You still need to know that range starts at 0 and the end is not inclusive. Also, the second example is not the same as the first one, unless the second is non-inclusive.

I agree. Scrum is about self-organized teams. Managers are not part of the Scrum team, in fact, they are not allowed to speak in any of those meetings (if they choose to assist at all).

I think the main problem here is a lot of companies do this weird hybrid where Scrum processes are somewhat followed, but managers keep managing the team and sometimes even taking the role of product owner and/or scrum master as well, and that just doesn't work.

Run `certbot renew --force-renewal`. That's what it says in the email they sent me. But if you didn't get an email, then your domains should not be affected.

> if you perform them in parallel switching between them, you get the benefit that at time 51 you can show both of the recipients that you are 25% complete, but you deliver A at time 199 and B at time 200.

That's not parallelism, that's concurrency. You are basically doing round-robin. If they were done in parallel, then both tasks would get completed at time 100. Throughput usually improves the otherwise maximum latency when there is at least some parallelism, otherwise I agree improving throughput would not make a lot of sense in many cases.

> I think that what I am doing is some variant of Domain-Driven Design?

Sounds like iterative and incremental software development. I dare say Agile.

Assuming you care about taking on more responsibility. That's not the path for everyone, though. I'm fine being just a very experienced programmer. I couldn't care less about "leading".

Fortnite started as a cooperative tower defence kind of game, it's still out there with a name I can't remember, but it was not a good game. AFAIK, the battle royale mode was someone's side project, thanks to PUBG being all the rage back then. The fact that fortnite even exists seems like dumb luck to me.

If you follow GP's convention then yes, and it's not a bad convention.

Sorry, I can only speak for myself.

You seem to be under the impression a side-project means spending every spare time working on it.

> There is a risk though that after ten years you could be a great programmer with a great portfolio, but with a failing body and unhappy social life.

There's no reason this should be the case, and life is full of risks.

> Building a side project is work

I'd say it's nothing like work. There's no stress, no deadlines, no fixed hours, no team work, etc. For many people programming is a hobby, something that's fun and they are not paid to do, they don't do it for the money, but for self-fulfillment. Not everyone find that at work, and even if they do, they may choose to spend a few hours a week building something for themselves, to scratch an itch or whatever.

> It's not so much that we can't accept that some people enjoy working, it's that they're screwing their health. There is no free lunch, staring at monitors for years on end will take its toll.

I doubt 50hs of screen time is a lot worse than 40hs, but I'd need data to prove/disprove it. However, you don't even need to spend that much time, it could be just a few hours a week.

> at the beginning or end of the day? or before or after lunch break?

That could work if everyone gets at work at the same time (+/-30m) or if everyone takes lunch at the same time (+/-30m), which has not been the case in most of the companies I've worked for. It'd be better at the end of the day, assuming no one does extra hours, but then it's even less useful or at least it becomes obvious it's all about status-updates.

> micro-management is if i tell you every single step that you should do, but a daily status-update is not

It's a micro-management enabler. There's no way to know if it's used to pressure someone to deliver, or to do things a certain way, without working in that team.

The bottom line is that stand-ups are of very questionable use. There are just better, more effective ways to communicate what everyone is working on, what things are done, and when someone is blocked. i.e: ticket assignments, PRs, sporadic side meetings, asynchronous communication (Slack, emails, etc), etc.

5 minutes or 5 hours, an interruption is an interruption. My ideal day to be fully productive would've no meetings at all. I don't need each day to be an ideal day, just once a week (or more if at all possible). However, when there is an scheduled interruption each day every day, guess what?

Also, anything that feels like micro-management will be considered micro-management. A daily meeting to give a status report looks a lot like that.

Sure, adding meetings that affect the whole team instead of addressing someone's lack of communication is the way to go.

Well said. Trust falls bring great value as well.

This assumes people don't communicate when they get blocked, but wait 24hs to announce it in a meeting.

Does your team communicate outside of the stand-up?

I usually know what everyone is working on (because of ticket assignments, code reviews, some occasional side meeting, etc), as I usually work with teams of 5 (or less) people.

First look up the definition of a lock and mutual exclusion. There are two types of basic locks: mutexes and semaphores. Both keep two threads or coroutines from executing a block of code/instructions at the same time, and both work in a similar way I already described.

> There simply is no concurrency in JS though,

There is no parallelism in JS (well there is with workers now), concurrency is not parallelism.

Even the original solution is a lot more complex than just checking some primitive value. A lock is still needed when doing concurrency on a single thread, which is the point I'm making anyway.

> Long story short: Your problem is with ordering, not locking.

Look up the definition of a concurrency lock.

No, I didn't. That's how a lock works. Only one coroutine (or thread) is allowed to hold it at a time while the others must await their turn. A state machine is a lot more than a boolean variable.

If the callback throws an error, none of the awaiting coroutines will run, and adding a catch would break the callback error propagation.