101–110 of 256 posts
Earlier quoted context omitted.
Facade doesn't help with poor tests, scripts, new dependencies, cicd workflows, repo settings, etc
Micro services don’t solve any of those either.
You don't need a damn network between two pieces of code just to "do one thing and do it well", for God's sake, I'm so sick of this rampant cluelessness in the industry. Do you saturate the resources of one machine and need to split things off? Do you have multiple teams each taking care of their own stuff? Do multiple services, it's fine in those cases. For almost any other reason you are just adding complexity, boi…
"grug wonder why big brain take hardest problem, factoring system correctly, and introduce network call too seem very confusing to grug" -- https://grugbrain.dev
Fundamentally, don't make life hard for yourself, or others.
I take issue with the pasta diagram. I was there, in the 1990's, as a working professional not a hobbyist. The popular architecture was, for better or worse, structured as layers, not spaghetti. Some software from the 80s might meet that definition, but I think it's uncharitable (almost to the point of insulting) to assert that until the 2000s most programmers didn't know how to write anything but spaghetti code.
Earlier quoted context omitted.
Have your teams use façade pattern and you no longer need microservices to "isolate it"
Can your "facade" "isolate" interns making change in your service as well so that the whole service which powers the system doesn't go down. Microservices can.
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.
And on pricing specifically, both shitty and good consultancies charge about the same. The ones that charge well below market are an outlier that will guarantee bad product - those are to be avoided.
Earlier quoted context omitted.
Have your teams use façade pattern and you no longer need microservices to "isolate it"
Can your "facade" "isolate" interns making change in your service as well so that the whole service which powers the system doesn't go down. Microservices can.
I think it is hard to reconcile this with the reality that every big billionaire dollar app does the complete opposite. Excel, Word, Jira, Salesforce, Facebook, Oracle ERP, etc.
That's why as a small team it is wrong to adopt 'The Spotify model'. And yet, many companies will do just that. At every level of the corporate ladder there are different appropriate sets of tools and ways of working that will allow you to achieve particular results. Once you reach the Microsoft of the 1990's era level size (or Oracle, or SAP) you can ignore some of the truisms from the leaner days and do different things that would have killed a younger version of your company.
Just like an adult can run and jump further and faster than a toddler.
Earlier quoted context omitted.
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.
Who mentioned outsourcing?
lijok wrote:
When we get consultants in to speedboat a new system, we give them their own separate service. Saves a lot of time and de-risks our beautiful monolith.
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.
CSV, line delimited, is that unstructured?
Further if you wanted to go with JSON or something you can, there's nothing preventing it. Pipes are based on unstructured text so you have that flexibility. If you want to add JSON ls and filter that through JSON sed to JSON less you can.
Finally 'the Unix way' is a cultural thing. It isn't set in stone. It can, and probably has evolved. So while you could argue that it meant that to some people at some time, that doesn't make it true today or in the future. The down side is that we have these disagreements over what 'the Unix way' is. But any philosophy that's been around for 40 years, in tech no less, has to be flexible, that's why it's stay relevant.
Earlier quoted context omitted.
Unstructured text is the unix way. You can have pipelines sending other things between your programs (see powershell), but that's definitely not Unix.
I disagree, the unix way has structure: lines of text each consisting of space-separated fields. The real issue is that sometimes your data has spaces, or even newlines, so the structure quickly isn't enough. And that "sometimes" happens xay more often than it has to, and the escape hatch is a mess.
I wish! Back in the day, tools like iostat and vmstat printed tabular data using fixed width fields with no spaces between. This worked fine until the computers got bigger and faster, then the larger numbers filled the fields so they ran together making the output unreadable. A surprising number of vendors had this problem.