Circle of Size
-
@HardwareGeek said in Circle of Size:
@dkf said in Circle of Size:
@Arantor said in Circle of Size:
that’s a slightly
interpretationDuh! That's the best we can do on
No, it's not. We routinely do very
, and on good days we get to extremely .
-
@Arantor said in Circle of Size:
@DogsB I’m working on a diversified exit strategy for this reason.
Hognose snake is the way to go.
-
@DogsB
pfff weaksause ... I once (god,
it's been more then15 years) worked with a system that called (like a good old analog phone call) the remote party, navigated the phone menu, entered some secret menu options (generaly available under the * or # options) only to have it retrieve a string of like 20-30 characters that supposedly told a lot about the system status (disk, cpu & phone line usage). But I never cared enough to figure out what exactly it was sending back. Only question was that it was alive. Kicker was that is was at that time already phased out and replaced by a system from IBM because ours was just too damn cheap and made within the union. Can't have that kind of thing when you're the 
parlement.Bonus fun fact: I once drove from northern
to 
(no not 
or 
but the small, even by Euro standards, state of Luxembourg through the one snow blizzard we usually get per year for system maintenance or something like installing a patch or so. Only to find out that the 'server' had some BIOS locked case and that the password wasn't in the customers file. Used a screw driver as a persuasive argument to let me do the job. Pretty sure it was using Dialogic ISA cards that had a 486 cpu.Going full
A bit like the bigger brother of this one ... this is only a 4 port card. there where full height, full lengt boards that had 8 ports or a whopping 16 simultanious analog calls and where you had to interconnect the boards with som flat cable.
It looked more like this E1 (digital, 30 calls) card
Holly crapper ... look at those c r a z y prices! I should have misplaced some cards into my car when I left that job ... they had literal stacks of old cards laying around ...
I even remember seeing shit like this dubble board
and this fucker ... it normally had some brake out box to that one port where you would plug in the phone lines
sweet jesus
Oh man this doesn't bring back good memories ... these cards where a pain to set up. Even the PCI (and PCIe) versions required the hell stew that was "Dialogic Configuration Manager" on Windows 2000 or newer. You just ignored the fact that Windows couldn't figure out the device and had to use the hellstew to actually configure the board.
-
@Arantor said in Circle of Size:
A lot of the “but serverless” arguments come down to “I pay for exactly what I use rather than a set amount of resources every month” which in startup mode can be useful, or not.
And then someone goes like muh security, you try to set up a private endpoint and find you need to switch to the premium tier where you are paying a dedicated VM full time anyway. Azure, duh.
-
@jinpa said in Circle of Size:
@Arantor said in Circle of Size:
But yes, no true monolith fallacy lurks around the corner
Most examples given of fallacies are not true fallacies.
That’s why it lurks around the corner rather than being directly invoked.
Which in itself is an allegory of the whole issue at hand of indirection and misdirection that is modern software dev.
-
@Luhmann said in Circle of Size:
E1 (digital, 30 calls)
Oh!I know what that is (or I used to; that was a long time ago). I once worked on a chip for an E1 device. That might even be the project that used my one and only patent (long-expired at this point), or maybe that was used for T1 (the North American equivalent). I worked mostly with T1, but I did work on one E1 product, and I can't remember which one resulted in the patent.
-
@izzion said in Circle of Size:
@Arantor said in Circle of Size:
@DogsB I’m working on a diversified exit strategy for this reason.
My "become a lottery winner" strategy is fairly stalled out
Yeah, if I'm lucky, I actually match 1 number. TBF, I only buy 1 ticket when I happen to be in the store when the jokepot gets big.
-
@error said in Circle of Size:
@topspin said in Circle of Size:
You could’ve built that with half of the WTDWTFers too bored to build real stuff.
Only
stands between us and world domination.Proof the world is safe from us. (I won't say "the world is safe", because, well, just look...)
-
@error said in Circle of Size:
Only
stands between us and world domination.If we dominate the world, then we'll have to manage it.
No thank you
-
@TimeBandit said in Circle of Size:
@error said in Circle of Size:
Only
stands between us and world domination.If we dominate the world, then we'll have to manage it.
No thank you
THE WORLD IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.
-
@Arantor said in Circle of Size:
@DogsB I’m working on a diversified exit strategy for this reason.
There's a reason I keep my forklift operator certifications up to date.
-
@Watson said in Circle of Size:
@Arantor said in Circle of Size:
@DogsB I’m working on a diversified exit strategy for this reason.
There's a reason I keep my forklift operator certifications up to date.
I’m not sure about forklifts but there’s good money in heavy vehicle driving and you’re driving something HUGE!
-
-
@DogsB said in Circle of Size:
it made a rest call to my service
abd then it did what was requested: it went back to
rest.
-
@GOG said in Circle of Size:
To be fair, DRY is - in my experience - a good practice that helps ensure that shared functionality is maintained throughout changes for all users. Whether you implement it through a library, service, or whatever, it's nice to know you're unlikely to run into "we changed things to match the new requirements everywhere except this one seldom-used bit of functionality that everyone forgot about".
The problem is that sometimes you instead run into “we can change this in most places, but not this one, because it would break that other business critical system” and then you start repeating yourself anyway and after couple such cases—with different component each time—the whole factoring out of common functionality starts to look like a wasted time because the functionality isn't common any more.
-
@LaoC said in Circle of Size:
do a HEAD on each gif in a page and if it was bigger than a few kB, rewrite it to a request to my own web service. That downloaded the picture and returned a new URL for a local copy that would have the image transcoded to jpg or mp4
So, a precursor to Twitter, Imgur, Mastodon and countless others' GIF mangling?
Edit: Fixed possessive grammar.
-
@Medinoc said in Circle of Size:
@LaoC said in Circle of Size:
do a HEAD on each gif in a page and if it was bigger than a few kB, rewrite it to a request to my own web service. That downloaded the picture and returned a new URL for a local copy that would have the image transcoded to jpg or mp4
So, a precursor to Twitter, Imgur, Mastodon and countless other's GIF mangling?
Yes, just on the fly and less transparent due to the greasemonkeying.
-
@Bulb said in Circle of Size:
@GOG said in Circle of Size:
To be fair, DRY is - in my experience - a good practice that helps ensure that shared functionality is maintained throughout changes for all users. Whether you implement it through a library, service, or whatever, it's nice to know you're unlikely to run into "we changed things to match the new requirements everywhere except this one seldom-used bit of functionality that everyone forgot about".
The problem is that sometimes you instead run into “we can change this in most places, but not this one, because it would break that other business critical system” and then you start repeating yourself anyway and after couple such cases—with different component each time—the whole factoring out of common functionality starts to look like a wasted time because the functionality isn't common any more.
That's what polymorphism is for.
-
@GOG the last time I mentioned that to someone, they asked me if I liked that episode of Red Dwarf.
-
@Arantor Come to think of it, that was a pretty good one...
-
@GOG said in Circle of Size:
@Bulb said in Circle of Size:
@GOG said in Circle of Size:
To be fair, DRY is - in my experience - a good practice that helps ensure that shared functionality is maintained throughout changes for all users. Whether you implement it through a library, service, or whatever, it's nice to know you're unlikely to run into "we changed things to match the new requirements everywhere except this one seldom-used bit of functionality that everyone forgot about".
The problem is that sometimes you instead run into “we can change this in most places, but not this one, because it would break that other business critical system” and then you start repeating yourself anyway and after couple such cases—with different component each time—the whole factoring out of common functionality starts to look like a wasted time because the functionality isn't common any more.
That's what polymorphism is for.
Rejected by QA, they don't have time to do regression tests.
-
-
@Arantor said in Circle of Size:
#monolithforever
Another long article about complexity in software:
Why embracing complexity is the real challenge in software today
In the midst of industry discussions about productivity and automation, it’s all too easy to overlook the importance of properly reckoning with complexity.
-
Ken Mugabe or whatever the fuck said:
However, it’s important that we don’t ignore complexity or see it as something that can be fixed
In other words, let's continue exactly the way we got up to our necks in this goddamn shit creek in the first place. Jood gob
and shove it up your arse.Because technical solutions have a habit of reorganizing complexity
Technical solutions create more complexity. Always.
This content was produced by Thoughtworks.
But it reads like ChatGPT did it, because it asserts some plausible combinations of techy words with confidence, but says nothing of value.
-
@BernieTheBernie said in Circle of Size:
Why embracing complexity is the real challenge in software today
-
To be honest, he does advocate a thoughtful approach, which sounds sensible on the surface. But that's a way equally wrong, because of the point two above - there are no solutions which do not add entropy. You must unmake some of the existing complexity to keep it at the current level.
No matter how carefully you think, architect, plan, you cannot begin to comprehend the monumental mountain of shit the industry runs on. No matter what you do, you will always be adding to the pile.
-
@Applied-Mediocrity said in Circle of Size:
Ken Mugabe or whatever the fuck said:
"However, it’s important that we don’t ignore complexity or see it as something that can be fixed"
In other words, let's continue exactly the way we got up to our necks in this goddamn shit creek in the first place. Jood gob
and shove it up your arse.No, he's just arguing against the Blakeyfantasy of "The world was great when we had hypercard! Stuff is difficult because people can't make good tools like that!"
Because technical solutions have a habit of reorganizing complexity
Technical solutions create more complexity. Always.
Right, but they solved some other complexity. Like TFA says, it's about tradeoffs.
-
@boomzilla said in Circle of Size:
No, he's just arguing against the Blakeyfantasy of "The world was great when we had hypercard! Stuff is difficult because people can't make good tools like that!"
I happen to believe that Blakey isn't really wrong. I'm just - you see - being less blakey about it.
-
@Applied-Mediocrity I DIDN'T ASK FOR YOUR WRONG OPINION
Blakey often has some good points. Or at least the start of them. But he could never understand that the shit pile we keep adding to can't be reduced to something simple because ultimately the problems really aren't that simple.
Not that people don't come up with some much shittier ways than others to solve them.
-
@boomzilla The other wrong opinion is that we can - nay, have to - simply keep piling on, but think really carefully about it (as much as that's likely to start happening), and then we'll be able to just tough it out when the mountain shrugs?
-
@Applied-Mediocrity we can - nay, we have to - nay, we simply must - …
The users don’t like it when we remove features out of “reducing complexity”.
-
@boomzilla said in Circle of Size:
@Applied-Mediocrity I DIDN'T ASK FOR YOUR WRONG OPINION
Blakey often has some good points. Or at least the start of them. But he could never understand that the shit pile we keep adding to can't be reduced to something simple because ultimately the problems really aren't that simple.
Not that people don't come up with some much shittier ways than others to solve them.
The problem is that while it's hard or even impossible to reduce the solution's complexity below ==> that level because the problem's complexity is at that level, it's very easy to make the solution arbitrarily more complex than the problem requires.
But at least the writer in the Mugrage article recognises that there is a lot more to what developers (whether you call them developers, programmers, software engineers or whatever) do than just "coding".
-
@Arantor said in Circle of Size:
The users don’t like it when we remove features out of “reducing complexity”.
OK, call it "no longer causing the poor developer to go batshit insane and start shooting random people from the nearest clock tower".
-
@Arantor Yes, indeed, no software developer worth his weight in shit does not think about their dear users day and night, striving to support them to the best of the ability. We have collectively even come up with this endearing term for them that starts with L, which stands for lovely.
-
@Applied-Mediocrity said in Circle of Size:
@boomzilla The other wrong opinion is that we can - nay, have to - simply keep piling on, but think really carefully about it (as much as that's likely to start happening), and then we'll be able to just tough it out when the mountain shrugs?
I'm not seeing what's different between that and TFA. However, in the spirit of piling it on, I just came across this:
When Debug Symbols Get Large
TL;DR – upgrade your tools, including Visual Studio, windbg, and Windows Performance Toolkit, if you want to handle Chromium’s symbol files.Details:Death, taxes, and browser engines relentlessly gr…
tl;dr Chromium's PDB files are now greater than 4GB
-
@boomzilla said in Circle of Size:
Chromium's PDB files are now greater than 4GB
That's about the size of one of my template instantiations.
-
@topspin You wait until that is the size of the type of one of your template instantiations.
-
@dkf that is what I meant. At least the mangled type name.
-
@Applied-Mediocrity said in Circle of Size:
@boomzilla The other wrong opinion is that we can - nay, have to - simply keep piling on, but think really carefully about it (as much as that's likely to start happening), and then we'll be able to just tough it out when the mountain shrugs?
Nature's been doing that for about four billion years and so far it's come up with us
-
@Bulb Nature came up with delusions of grandeur enough to discuss their own existence as if that meant something. Gotta hand it to Nature that's quite an achievement.
-
@Bulb Have you ever tried debugging a human?
-
@ixvedeusi said in Circle of Size:
@Bulb Have you ever tried debugging a human?
A surprisingly lethal outcome occurs if fully debugged.
-
@ixvedeusi said in Circle of Size:
@Bulb Have you ever tried debugging a human?
I don't know about humans, but monkeys do debug each other:
-
@Zerosquare said in Circle of Size:
I don't know about humans
I thought about getting an archive picture of DDT usage in the southern US. But
-
@dkf said in Circle of Size:
@Zerosquare said in Circle of Size:
I don't know about humans
I thought about getting an archive picture of DDT usage in the southern US. But
Les nasty buggers are still good for a national crisis these days.
