284 karma · joined March 17, 2008
https://nertzy.com
8 hours a day pairing means that pairing is the default, but it’s not the only thing that ever happens.
also: 8 hours/day pairing meant 16 hours/day not working at all in my case. Really really really not working. Not checking Slack. Not trying out some crazy idea. Not working at all.
But seriously it does read well like normal thoughtful human writing, so I am on the side of it not being “AI slop” while also noting that you didn’t claim it was.
~ ping yahoo.com
PING yahoo.com (74.6.231.20): 56 data bytes
64 bytes from 74.6.231.20: icmp_seq=0 ttl=50 time=42.366 ms
^C
--- yahoo.com ping statistics ---
1 packets transmitted, 1 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 42.366/42.366/42.366/0.000 msUsing UUID here wouldn’t help here because you don’t want different identifiers for the same content. Time-based UUID versions would negate the point of ETag, and otherwise if you use UUIDv8 and simply put a hash value in there, all you’re doing is reducing the bit depth of the hash and changing its formatting, for limited benefit.
Bonus: we self-selected for people who don’t like to pair. We paired 100% of the time.
Then I look at the username and it’s my classmate from down the hall in the same dorm.
And I’m pretty sure I actually did end up in a beach house with them at some point.
I mean, it’s Linux.
If I visit an HTML page with a link to “.evil.com/people/123” and click on it, the user agent won’t append “.evil.com” to the hostname. You’d instead get something like “https://api.hotstartup.com/.evil.com/people/123” which would be safe (if not broken).
Seems to me that the relationship between Boeing and its various 737 MAX customers could be seen in a very similar light. Abusing high-risk technical systems as a tool to extract resources to cover for artificial scarcity in budgets or market expectations.
March 20: Confirmation of receipt of issue, boilerplate response detailing expected next steps
And as far as we know, this might have actually happened! Maybe it wasn’t deemed interesting enough to include on that timeline.
http://topple.ngmoco.com http://topple2.ngmoco.com
Although yours has more of a puzzle feel to it.
Just because they're displayed in a different form doesn't make them any less organic.
I was one of the 30 student Partners they talk about and I can't even begin to enumerate how many wonderful experiences I've had. After graduating, transitioning to work for a small software startup was quite natural.
Also, it is interesting to note that several Y Combinator teams have been made up of Olin students. (Flagr and Thinkature come to mind)
It's also important to note that scholars don't actually know the proper plural of virus because they haven't really found one in extant literature.
Wikipedia has a longer discussion at http://en.wikipedia.org/wiki/Plural_of_virus#Virus
No tenure, collaboration with nearby institutions to share courses, encouragement for all community members to contribute to developing and changing all aspects of the college at any time, and no separated academic departments. The list goes on and on.
It's a great place for entrepreneurially-minded students to find an atmosphere that allows them to build up their skills without having to settle for university-level bureaucracy.
At the very least I hope that you would read the article before deciding what it's actually about.
Prof. Downey has a great knack for making complex CS topics seem very simple.
I guess my response to that would be that Microsoft is quite opaque regarding Ruby. By being such a closed system, Windows doesn't do anything to help developers improve Ruby library compatibility.
Compare this to Apple. Apple builds Ruby into its operating system, contributes patches upstream, and is even supporting the development of MacRuby, which more tightly integrates Ruby into the Mac OS X operating system.
So the opaqueness goes both ways in my opinion.
Due to this, I am very impressed that Ruby even has the level of support in Windows that it currently enjoys. I would say that Windows hackers should keep up the good work and submit substantive patches as often as possible.
Your first paragraph presents a straw man. Sure, in extreme cases, reproducing a bug is not mandatory. Again, the author does not claim that reproducing a bug is mandatory, but rather that it is a useful practice.
It is not a virtue to try to base your work on the least amount of information.
You say that "when the hard problems come you will be ready". But really when the hard problems come you will look at them assuming that the logged information is enough to solve them. No programmer can know ahead of time what information to log, so by purposefully blindfolding yourself from experiencing the bug directly, you might miss the bigger picture.
Indeed, I can't think of a reasonable logging mechanism that the author could have thought of ahead of time that would have helped with this particular bug. Emphasis on "reasonable".
They have found a way to cause an unusual interaction, but that doesn't make the whole of chemical knowledge up to this point any less useful or correct.