Re: Takes me back
Yeah, it was my job to save IBM money by denying bonuses to executives. My departure was...mutual.
"Will be skunk at dinner party for food."
AMD understood the importance of QA. Very, very few places do.
3516 publicly visible posts • joined 23 Jan 2015
Unanchored regex? Really? Didn't they cover that in like CS 110 or something?
There are a lot of people that fail to grok this basic fact: Regexes are _code_. They need testing like any other code.
I can understand that most programmers, even, don't actually have the chops to properly test them. Team leads should be well aware, however, and implement processes to ensure garbage like this doesn't get out there.
<sigh> Has it really been that long since everyone knew to be hyper-vigilant around regex?
That treaty has always been a dead letter. Tell me, what formal complaint has EVER been filed by one country against another under it?
Look, the ideas are (mostly) good, but as soon as actual commercialization of orbital space got going, additional laws got going, and not always in accordance.
Big money pays for the big guns. That's not going to change.
At my last company, the sales team was using a QR code generator. I found out about it, and ran it through a qr code reader. Yep, short-coded to some server in German.
What I don't get is that scanners don't catch these things. Okay, so there is an image file. Decoding the thing takes work. What exactly am I paying you for?
They're not just technical. They are technical issues being painted in the worst possible light. I stopped reading part way in because it's clear that the author hates & is dumping.
Brave was trying hard to find a way to get funding that did NOT end up going the way that Mozilla has gone. To that end, they were probing what was technically possible & socially acceptable. Like a lot of research, they had more failures than success. What he perhaps did not anticipate is that, having successfully driven him from Mozilla, the hounds were NOT being called off, and anything innovative he tried would be attacked. Pioneers, they say, are the ones with arrows in their backs. Doubly so in this case.
Okay, physics fanboi here, so I'm likely to get part of this quite wrong. Nevertheless..
In the 70's & 80's, communications satellites all went to geosynchronous orbits. Many of us thought that meant geostationary, but it turns out geostationary is a misnomer. Even in geosynch orbit, satellites have to spend fuel "station keeping" lest they drift too much out of place. Geosynch was was the "natural" orbit for communications satellites because satellites using it could be tracked from the ground with fixed or minimally-gimbled antenna. HOWEVER, it turns out that 22,236 mi (35,786 km for snooty folks) is actually quite a long ways up. This has several implications:
1) The rocket equation is NOT your friend. It's going to take a lot of energy to get your bird up there.
2) Essentially no atmospheric drag. This is great, so long as you have fuel. But it also means that you get no help coming down. They have designated "dead" orbits for satellites, but those only work if the bird doesn't have a catastrophic failure, and these orbits are subject to Kessler.
3) Compared to lower orbits (550 km / 400 km), quite a bit more signal boost (~71db round trip) is needed.
4) Once they go up, they never come down, so they are designed for long lifespans.
5) Between 1 & 4, birds are going to be big as well.
Of course, low orbits come with their own problems. Namely, the bird is by no means "fixed" in the sky, and that pesky atmosphere makes stationkeeping a LOT more expensive. We fix the location issue via software. Since we have to have several birds to maintain an active channel, why not do LOTS?
1) The loss of any particular bird is NBD. A 5-year bird is a lot cheaper than a 20-year bird.
2) In particular, a 5-year bird needs a lot less fuel for station keeping than a 20-year bird at the same altitude.
3) So the birds a a lot smaller. So they CAN'T threaten to make craters anywhere.
4) When the time comes for a satellite to retire, a minimal final burn can drop the perigee to the point that it rapidly becomes a gas.
5) You first birds are defacto beta tests. Five-year-old models are simply no one's problem at all, if all goes to plan.
It sounds like they selected the 550 orbit based on a certain amount of atmospheric drag, but (oops!) forgot that the solar cycle makes a big difference up there. They actually are spending a significant amount of fuel to lower lower these orbits, which will in turn shorten the lifespans more than originally planned.
Well, look at the times. There were a lot of new websites out there exploding in popularity. Thanks mostly to Ruby on Rails, they were often being built by coders with, shall we say, limited experience. In particular, RoR basically promised that you didn't need to worry about your database--and these coders believed it. So your website gets featured somewhere, and suddenly, RoR on MySQL is falling over horribly.
So...where did things go wrong? It couldn't be Rails. It certainly wasn't the coders. It had to be the database. Problem: if you needed more than MySQL could provide, the only option was Oracle. CFOs would NOT be happy about that, and most startups were hard-core open-source-only anyway.
So, the time was ripe for a database that could multi-master with high throughput. The CAP theorem was known, and MySQL didn't do multi-master at all, AIR. So you couldn't just throw more MySQL servers at the problem. Then someone noticed that a lot of the data used for the web site wasn't very relational. Thus you had a spasm of NoSQL databases come out. Any everyone got to experience the joys of "eventual consistency", and also "cluster lock".
For all of its sins, very, VERY few of those startups actually had any need to get off RoR + MySQL. Software engineers could easily read up on MySQL enough to be able to figure out where the bottlenecks were happening, and a few custom queries with maybe a couple of stored procedures and perhaps a few triggers would handle anything short (at the time) of Twitter or Facebook. But that would require a willingness to demand that RoR stay in its own lane, and very few places had people with the maturity to do that & were willing to listen.
You need to pay more attention during your screen time on this site, then. And maybe do some more research on things like brain plasticity.
The brain interacts with near-screens VERY differently than the full 3-d world. What's more, apps are specifically designed to continuously draw attention. We now have a study demonstrating what kind of differences are actually occurring.
"the moment the tech world held its breath and hoped years of Year 2000 bug remediation efforts would work."
The tech world most certainly did not. At all. We ALL KNEW that the hype was 90% BS. Also, that a lot of work had gone into fixing the 10%. Even though 99% of THAT would not have been very serious even if unaddressed. Yeah, that .1%, though--that stuff would have been pretty bad. BUT, things like mortgages had been fixed--in the 70's. Credit cards '96 and '97. Anything dealing solely with forward dates that had NOT been fixed suddenly got a hundred year reprieve at that point.
The techies were mostly concerned about the normies freaking out. Personally, when I heard about the wine shortage due to people stocking THAT, (in July), I relaxed.
Actually, did you see that video of that social engineer sweet-talking her way into the interviewer's bank account? It took me two or three takes to realize--she looked like a dumb, dizzy blonde because it helped her to play one. There is actually a significant edge that we can gain by physically getting into character as well.
Not that this article should have run at all--interviews are supposed to challenge idiocy.
Okay, let's try this again: When people say "think like a hacker", what happens is that the thinker thinks, "What would I do if I were hacking?" That fails, and it fails badly. First, unless you are an actual hacker, you are comparing the efforts of a dilettante to that of a professional. Second, even if you someone precisely model the attack modes of some particular hacker, what about the different attack modes that some other hacker will take?
99.99% secure == completely insecure.
You have to make it impossible to hack your system. Again, this is the realm of mathematics, and most just cannot get there.
What's with these puff pieces for FakeICEOs?
Let's start with the opener "think like a hacker". What naivety. If you want to win that route, you cannot think like "a" hacker, you need to think like each & every one that finds your site. Hint: random processes will NEVER win that game. That especially included FakeI. Defense needs to be absolute.
The Founders most definitely were high-minded. They also were historically literate, and built a system that they had hope would be resilient in the face of the many, many failure modes observed. One wrote, "I flatter myself that this system we devised will last twenty years." Benjamin Franklin, when asked what sort of government had been wrought, replied, "A republic, if you can keep it." I think it was Thomas Jefferson who stated, that the government would work, "until the people realize that they can vote themselves money out of the treasury". A different many wrote, "We have based all of our institutions on the proposition that men will govern themselves according to the Ten Commandments of God. This is a constitution for a Christian people, it is not fit for any other."
A government is simply too complex of a thing not to have failure modes. You try to defend against the most problematic.
Ahh, the slide rule. I showed up to my first Chem I test with mine in 1983. All of the problems expected 4 digits of accuracy.
Because apparently, knowing how to use a calculator was the main point of Chem I. I had assumed that, given programmable calculators had recently come out, those would be banned.
Unmaintainability doesn't cause incorrectness. You're following the wrong trails.
Proposition: The requirements for code change over time.
Corollary: Perfectly "correct" code at t_x will become incorrect a t_y.
Observation: This change in correctness has nothing to do with the maintainability of the code.
Proposition: The claim that code is "correct" is properly a statement in mathematics.
Corollary: Unless you are a trained mathematician (at least to the level of passing your prelims), you cannot reliably prove such a statement.
Observation: The number of trained mathematicians working as programmers is vanishingly small.
Conclusion: Almost no code is known "correct" in the strict sense.
Corollary: It is far safer to assume that all code is broken, even at any given time.
Conclusion: If you code is unmaintainable, when you either discover that your "correct" code is broken all along, or the code will simply be deemed wrong because the requirements change, you will be in trouble.
The definition of "maintainable" code is that it is easy to fix what is broken. It is the necessary prerequisite for code being even correct-ish for longer than a particular snapshot.
FDiv is generally the slowest instruction on the part that doesn't pull from main memory. If you are doing multiple divides by the same thing, you can save time by storing the reciprocal. Of course, you introduce an additional 1/2 ulp of error. But there is an obvious reason to prefer multiplying by the reciprocal.
I'm afraid you have the order wrong.
Because what happens to your "correct" code when the requirements change? It's no longer correct. Almost no one is a Knuth.
The real world is constantly changing. A lot. Some small sliver of those changes almost inevitably turn into update requirements for a given piece of software.
Even a critical security failure requiring a major re-write of the code can be managed.
Remember when XSS attacks became a thing? Almost every website managing use accounts became imperfect overnight. At that point, there was code that could be maintained--and code that could not.
Except that the name IS a kind of documentation. I don't really care what the official documentation says, if you name your function SoapHttpClientProtocol when it can be used for file:// instead of SoapUriClientProtocol, you are deliberately misleading the users of your function.
When I get called in to debug code in some language I've not dealt with before, I don't start by reading the docs end to end. Now, I HAVE, to my great pain, worked with .Net, so I am warned to expect this sort of garbage from Microsoft, but it is still on the function creator to not create functions with clearly misleading names.