That the prediction engine so strongly suggests there should be two b’s in the middle implies that we instead may, in fact, be spelling it wrong.
77 karma · joined April 11, 2014
That the prediction engine so strongly suggests there should be two b’s in the middle implies that we instead may, in fact, be spelling it wrong.
Bigger Burger is great! Aliterates, rhyming, and TWO plosives!
I guess whether it’s human error at the hands of the pilot/driver, or human error at the hands of the engineer/designer, we can never fully remove it from the equation.
Should we just give up? Seems the best we can do is try and mitigate risk, and automated systems condense this risk down into fewer points of failure (i.e., there are less engineers than users!).
But when we think forward to the inevitable autonomous vehicle accidents that will occur, the conversation turns to how many lives they’ll have saved, and how much safer they’ll be.
Is there a known psychological phenomenon for “negative hindsight, positive foresight” that I can go learn more about?
If done masterfully—this overrealization captivates me, and the emotions I feel at the end are real. And I can learn something new about myself for it.
alias ao='ls'
alias aoe='ls -l'
alias aou='ls -a'
alias aoeu='ls -la'
Problem solved!“I placed myself in the situation that a child of mine had died. When I really lost my daughter, I could not have written these songs any more.”
Does anybody know if you might actually be safer from, say, a theoretical surveillance program by "blending in" as a typical Internet user vs. using Tor, where just one mistake might trigger a red flag?
I guess this technique wouldn't applicable if you do have something to hide, though... Hmm!
A great way to be motivated to write abstract code is to first understand how cool it is!
Some resources for getting started down this path: [2] [3] [4]
If anybody wants to chat about audio synthesis on iOS, feel free to get in touch :)
[1] https://github.com/aclissold/twyst
[2] http://jackschaedler.github.io/circles-sines-signals/
[3] http://mkonrad.net/projects/ios_audio_synth.html
[4] https://developer.apple.com/library/ios/documentation/MusicA...
It needs minor tweaks to make it uniformly readable across arbitary screen sizes, but in general this just made my day!
EDIT: Ah. It's a different story on iPhone 6s Plus than say, 5s.
In Swift, types are non-optional by default. You can never end up with a null, the compiler makes it impossible. Optionals are out of the way until you need them, and if you use them properly (i.e. avoid the .get() equivalent), it's still impossible to crash from a null.
In Java 8, things can still contain null by default and you might not know about it, right? You can express that something is Optional in your API, but that's only marginally better than documentation, doesn't solve "unexpected nulls" whatsoever, and makes this only halfway to a solution and therefore broken entirely. Why not just use annotations?
Are my assumptions and understanding correct?
Relegating you to use a password manager anyway, at which point you might as well just generate random passwords that don't rely on dictionaries?
I'm not saying it's a good idea, because only a subset of people would be capable of it, but it's interesting to think about!