81–90 of 256 posts
Earlier quoted context omitted.
Have your teams use façade pattern and you no longer need microservices to "isolate it"
Facade doesn't help with poor tests, scripts, new dependencies, cicd workflows, repo settings, etc
But you're probably not the person I should telling this, developers aren't usually in charge of that.
Earlier quoted context omitted.
It’s okey to prefer open source over proprietary applications. But obviously we can still learn lessons about interface design from proprietary systems. We don’t need the source code in order to observe those aspects of the application. (And if we need understand how to application operates under the hood, it’s entirely possible to use tools like IDA and Ghidra.)
Make an extensible platform through a plug-in facility is hardly new or specifically closed source solutions, doesn't it?
The conclusion is: "There are no easy answers". I wish I was kidding.
To count the number of functions in a rust file you could run: cat main.rs | grep "^\s*fn\s" | wc -l This both promotes the "one thing well" model, while revealing its inherent limitations. How many functions are in this rust file? /* confuse things fn fo fp fn fm fl */ fn main() { println!("Hello, world!"); } The above grep reports two, when there is only one. It can be made to work if everyone agrees to follow conv…
This sort of heuristic bugs me too. We should be able to write language server-adjacent tools which could do this sort of thing as easily as grep. You could do a lot of useful stuff with that, for example to implement custom linting rules: - Count non-comment tokens within each scope, to look for complex scopes: `foo --tokens --exclude-comments --group-by=scope` - Count expressions (as opposed to just SLOC) per funct…
Earlier quoted context omitted.
Ls seems like a bad example. Anything that you'd want to colour, the data should already be there. Further I'm not sure the Unix way inherently requires completely unstructured text
Unstructured text is the unix way. You can have pipelines sending other things between your programs (see powershell), but that's definitely not Unix.
Earlier quoted context omitted.
>But ... firstly, let's stop with the Unix worship. They didn't deliver, even in the domain of the terminal. My copy of `ls` has at least 40 flags GNU is Not Unix. I count 13 flags on both Unix V10 [1] and on Plan 9 [2], its spiritual successor. [1] http://man.cat-v.org/unix_10th/1/ls [2] http://man.cat-v.org/plan_9/1/ls
This is a version of a No True Scotsman argument: the True Unix did not have these flags and therefore these flags are not part of the Unix Way. The extra flags were added over time because the One True Unix did not provide the functionality that people needed in real world use. They couldn't be added in a composable way because of failures in the shell programming model (unstructured text + sh is terrible). The Unix…
-1 list one file per line
-C list entries by columns
-t sort by time, newest first; see --time
-r, --reverse reverse order while sorting
-S sort by file size, largest first
--sort=WORD sort by WORD instead of name: none (-U), size (-
S), time (-t), version (-v), extension (-X), widthGood article, but to me it seems to be co-opting the term enshitification in a strange way: > Large codebases will eventually reach an “enshittification point” — the point at which bugs are introduced faster than they can reasonably be fixed. I think of enshitification primarily as an organisational/business phenomenon rather than a technical one. It doesn’t necessarily emerge “bottom up” as the result of technical d…
> I think of enshitification primarily as an organisational/business phenomenon rather than a technical one. I will second this. I can't count how many projects were started with a clean design and clean early releases (what worked well), to be later messed up with business changes because the original (business) idea didn't work. And those sudden changes are expected to be implemented usually "yesterday", which adds…
If the point of a project was to run a business, I would argue the project was messed up from the start if it could not adapt to the changes. Very little software survives contact with the real world.
Earlier quoted context omitted.
Facade doesn't help with poor tests, scripts, new dependencies, cicd workflows, repo settings, etc
If it's that bad, you might be better off paying extra to avoid shitty outsourcing companies. But you're probably not the person I should telling this, developers aren't usually in charge of that.