799 karma · joined March 11, 2014
Personal email: my username at gmail.com
Yet, as Hillel says in their post, 'Most people would agree that the software running on spacecraft counts as “real engineering”.'.
I think looseness stems from three interrelated factors (1) potential complexity of a piece of software (2) the role complexity plays in causing faults (3) the fault tolerant nature of many domains in which software runs.
(1) Potential complexity - literally the amount of logic branches - that can exist in a piece of software. If you were to compare the logic branches for a bridge, what would it be - 10? 100? if(load> X); if (temp > Y); etc...
(2) The reality is you can hold a bridge (or the relevant variables[0]) in your head. Holding it in your head is necessary to be certain you can think through failure cases, or even know what cases to conduct/write tests for.
When writing software, the branches can get so unbelievably high that it's basically impossible to hold the whole thing in your head. Even if you break apart and solidify each underlying abstraction in your system, a single user outcome may be composed of so many underlying abstractions that their interactions are impossible to predict.
(3) Going back to the '"...software running on spacecraft counts as “real engineering”.' I think this is a not-loose example of SWE . The stakes are high, and accordingly, I'm certain a lead engineer on such a piece of software would do as much as possible to fully understand the entirety of the system so that it can be precisely tested. Get the number of irrelevant variables as high as possible, and keep the complexity of code as small as possible.
OTOH, most software is low stakes. Even if you're dealing with money, transactions can be rolled back, payments refunded. There are rarely undoable mistakes, and even more rarely do those mistakes destroy the project (spacecraft) or kill a person.
---
So in summary - I guess my point is: SWE is its own thing, in creating a world where complexity is orders of magnitude higher than in physical things. "Engineering"-ness operates on a plane of rigor, the high end of which contains only certain kinds of software.
[0] I'd define an irrelevant variable as an abstraction that has zero possible implication for the logic branches of your project. For a bridge, this might be melting point of the steel (not a bridge guy, as you can tell); for a typical software project, this might be the OS.
Are you sure this is true? In my (admittedly limited) experience, the way it works is that the bank asks for your annual income and you have to provide proof of that, which you can do by providing a statement from the brokerage account your company vests your RSUs to. RSUs issued from your (presumably publicly traded) company are liquid, so you can pretty easily claim them as part of your annual income and get a mortgage against that income.
See https://gdpr-info.eu/art-6-gdpr/ (6)(1)(c) (6)(3)(a/b) and https://gdpr-info.eu/art-48-gdpr/ (48)
That's not to say I know how a Google would react to a US warrant about an EU citizen (especially given the CLOUD act https://en.wikipedia.org/wiki/CLOUD_Act) but from what I can tell it's not permitted under GDPR
GraphQL lets you write queries for objects. This fundamentally changes how you architect your app and database.
In a REST API, you turn known a finite list of known query patterns (endpoints) into DB queries, which you can test, hand-write, and optimize.
If you let end users query your object model, it takes far more work to ensure they don't do something very expensive.
Abstract— Goal: We hypothesized that COVID-19 subjects, especially including asymptomatics, could be accurately discriminated only from a forced-cough cell phone recording using Artificial Intelligence. To train our MIT Open Voice model we built a data collection pipeline of COVID-19 cough recordings through our website (opensigma.mit.edu) between April and May 2020 and created the largest audio COVID
....
Results: When validated with subjects diagnosed using an official test, the model achieves COVID-19 sensitivity of 98.5% with a specificity of 94.2% (AUC: 0.97). For asymptomatic subjects it achieves sensitivity of 100% with a specificity of 83.2%.
Simultaneously, TikTok has captured the daily attention spans of millions of Americans, many of them especially young and impressionable. They've captured their attention in the form of a black box algorithm that promotes content in whichever way TikTok deems most appropriate.
These two facts mean that the Chinese government now has direct access to the brains of millions of young Americans, with zero oversight. Imagine China subtly promoting videos to create outrage and civil unrest in the US, or to feed anti-US propaganda to germinate terrorist groups in the US. These might sound like far flung possibilities, but I think it's hard to say what a country that views the US as its enemy (politically, economically, philosophically) might do with that kind of power, and I don't think we can wait to find out.
Demo vid https://v.usetapes.com/85knuAPruB Longer description in github readme https://github.com/jtmarmon/hackerthreads
Ironically it's actually easiest to have 100% coverage in worse code, because the more entangled and coupled your code is, the more likely you are to hit branches that are not under test.
From reading the original notice [https://help.twitter.com/en/protected-tweets-android] it sounds like the setting would just be disabled, which then made your tweets public. But not that Twitter's app would continue to say they were protected. That's a pretty significant difference (also by the fact that such a huge thing was not noticed for 6 years I'm guessing not many people were actually impacted)
Also just for fun, I'd wager how it happened is that the developer had some "default request object" that had "true" as the default setting for this and merged it with the updated property values ;) a classic
The problem with that is now you have to maintain two functions that do the same thing just to satisfy the type system.
> If `Maybe` is an output then existing callers SHOULD be broken,
He agrees with you on this, according to the talk
- Why is it uniquely good at doing that (e.g. iteration speed is super fast, no installing dependencies, etc)
- For the non-clojure inclined, what is the value of clojure/datomic to them
The first paragraph of actual text on the page says "Isn't a tool this powerful too dangerous for production?" - you're trying to debate a problem I haven't even mentally flagged because I have no idea what it does. The demo vid is way too fast (and long - the worst combination) for me to get an understanding. I'm generally in-favor of having a demo video as the first thing on your site but only if it's max 20 seconds long and gives me a very clear picture of what it does.
> Git is clearly not a VCS, and it has never tried to be one, and people calling it one doesn't change that. The absense of a progressing version number and lack of a definitive timeline, not to mention all the many "unnatural acts" you can do to a git repo are sufficient arguments to settle this point.
OK - all of these things you can get by having a central authority thereby creating a VCS (by your definition) out of git. So git matches your definition of a VCS under constraints you already have.
> But in many cases Git is an adequate substitute for a VCS, you just have to augment it with an out-of-band definition of which tree is the 'definitive', and settle who gets to define what 'a version' means. This is why github exists in the first place.
Oh great so you agree that you can make git into a VCS based on your definition. So what's wrong with git again?
>In FreeBSD we have insisted on "proper version control" from day one, 23 years ago, and while it is a decision we should revisit periodically, everytime it has come up, it has been overwhelmingly confirmed as "the way we do things here".
Ah, it's just not "the way we do things here". That's what's wrong with git. Got it.
An argument that might make some sense to me is "the beneficial collaboration features we'd get out of git isn't worth the switching costs". But I just found this written so matter o-factly ("It's impossible to refute this line of reasoning in my opinion.") for something that seems to make no actual point at all
Because they used a signed user ID, there was no way to differentiate the user 123 from before the system restore and after.
Food for thought: the security issue wouldn't have happened if (1) travis used UUIDs instead of sequential IDs as a pkey, or (2) used a secret token for auth instead of a signed (presumably) JWT.
Maybe if you had used datomic as your database it would’ve been fine (/s)