57 karma · joined January 5, 2022
TITLE=$(echo '${{ github.event.issue.title }}' | sed 's/"/\\"/g' | sed "s/'/\\\'/g")
Even in ruby it would have been something like
TITLE=shell_escape(github.event.issue.title)
where shell_escape could at least have unit tests. I don't know anything about github actions, but anything that takes user input needs to be processed with a language that uses static typing I believe to help ensure that the user input doesn't get into expressions given to other programs, shell, sql, or whatever.
Unix was just not made for this sort of thing. It was made for in-house people to write patent applications.
If you're not interested in learning the course content, then what are you doing there? Pretty expensive waste of time.
I very fondly recall many of the course I did at university. The exams were a helpful motivating factor even for the interesting courses.
Clanker (ai assistant) also love to unwrap and if you don’t catch them you have an abort waiting for you.
context("Loading configuration from {file}")
Then you get a useful error message by unfolding all the errors at some point in the program that is makes sense to talk to a human, e.g. logs, rpc error etc.Failed: Loading configuration from .config because: couldn't open file .config because: file .config does not exist.
It shouldn't be harder than a context command in functions. But somehow Rust conspires to require all this error type conversion and question marks. It it is all just a big uncomfortable donkey game, especially when you have nested closures forced to return errors of a specific type.
I think when there is an extended outage it exposes the shortcuts. If you have 100 systems, and one or two can't start fast from zero, and they're required to get back to running smoothly, well you're going to have a longer outage. How would you deal with that, you'd uniformly across your teams subject them to start from zero testing. I suspect though that many teams are staring down a scaling bottleneck, or at least were for much of Amazon's life and so scaling issues (how do we handle 10x usage growth in the next year and half, which are the soft spots that will break) trump cold start testing. Then you get a cold start event with that last one being 5 years ago and 1 or 2 out of your 100 teams falls over and it takes multiple hours all hands on deck to get it to start.
This is a lot to place on the DM, but I like the anarchy of a system like dungeon crawler classic. You expect some of your characters to die, e.g. in one adventure my character in a last ditch effort to save himself drank a potion of unknown origin, that potion turned him into a mithral statue. It was a fitting end to his short but eventful life.
Another character played by a different player managed through a long process involving books and negociations with his patron to construct a demonic sentient flying dog through whom he could cast spells and see.
This kind of exploration I think encourages players to see their characters much more as characters than machines to be min maxed and it is way more fun.
Give the DM total control to decide the dice roles that determine the outcome of the shenanigans. You try to hire an army of peasants you're going to be dealing with appointing sergeants, logistics, mutany, desertion all before you try to line them up to throw a ladder at some dude, which in the end is probably like a 1d20 >= ac for a chance of 1d4 damage, with of course crit tables, where on a critical success the dude might be tangled up in the ladder and fall over or something.
That said there are also contexts in which the existing system that was built sucks so bad that rewriting it usually a boon, even if the new wheel sucks, it sucks less from the start.
You at a minimum should engage with the existing wheels and their users to find the ways in which they do and don't work.
In your own time I think it is great to tinker, pull apart, assemble your own things. Every Jedi makes her own light saber right?
x += labelW+20;
hDescEdit = createModernEdit(hwnd, x, y, editW, btnH, ID_DESC_EDIT);
x += editW + gap;
What no clang-format or equiv in 1990?If the build language is LUA, doesn't it support top level variables. It probably just takes a few folks manipulating top level variables before the build steps and build logic is no longer hermetic, but instead plagued by side effects.
I think you need to build inside very effective sandboxes to stop build side effects and then you need your sandboxes to be very fast.
Anyway, nice to see attempts at more innovation in the build space.
I imagine a kind of merging between build systems, deployment systems, and running systems. Somehow a manageable sea of distributed processes running on a distributed operating system. I suspect Alan Kay thought that smalltalk might evolve in that direction, but there are many things to solve including billing, security, and somehow making the sea of objects comprehensible. It has the hope of everything being data driven, aka structured, schemad, versions, json like data rather than the horrendous mess that is unix configuration files and system information.
There was an interested talk on Developer Voice perhaps related to a merger of Ocaml and Erlang that moved a little in that direction.