sokrates
Joined 16 years ago
Karma
328
Submissions
65
Member since
Oct 24
Recent submissions
Comment · 5 years ago
Comment · 11 years ago
As a non-native English speaker, I find the omissions of "the" very prominent and interesting in SpaceX speech. "shortly before first stage shutdown", "resulting in loss of mission", "139 seconds into flight", "some period of time following separation", "data to determine root cause" -- is this a general theme in engineering or journalism? I wonder what linguists have to say about this.
Comment · 12 years ago
As a complete physics noob, can I mod this to work in 3D? I.e. model a concave rigid body shape, and have the fluid flow around it?
Comment · 12 years ago
https://gist.githubusercontent.com/jonasschneider/bfa93fbb35...
Extended the melody & progression a bit. I'm so proud, this is awesome!
Comment · 12 years ago
Comment · 12 years ago
They probably started development after the Skype fiasco at 30C3.
Comment · 12 years ago
SMS/MMS are shit and a relic of the past. I don't think it's a good idea to try and build a product based on them, ever. Use the Internet.
Comment · 12 years ago
Most points raised by the auther are criticism with specific Cucumber step implementations. I understand that this is not criticism of Cucumber-the-tool but Cucumber-the-process, but of course, if you're using your tools wrong, nobody's going to just fix your process.
The awkward step naming, and the routing issue, are all with the default steps of an integration of something like Webrat or Capybara. In recent projects (and I think this is the default for newer versions of Capybara), no steps are automatically generated for you. You have to choose the level of detail you want to operate at yourself. Comparing character count of a method call and a Gherkin step is also a rather useless metric.
The "doesn't share code with my test env" issue is a trivial fix: move your test-but-also-cucumber-env code from test_helper.rb into another file, then require it from both cucumber's env.rb and test_helper.rb.
Personally, I write Cucumber features exactly because they mean I don't have to think about routing, or paths, or syntax. I try to put myself in the role of the user and write down what I want to accomplish, and how. A key indicator for reasonably abstracted feature files might be the equivalence "I changed something in a .feature file" IFF "I have to communicate a change to my users."
But if you want to shoot yourself in the foot, you really have to do it yourself.
Comment · 12 years ago
The entire idea is that, while keybase stores the pubkey, you don't have to trust them to deliver the right key. They have basically rolled their own type of digital certificate that's stored within a variety of social services, i.e. Twitter -- you tweet something like "I'm <fingerprint of your key> on keybase.io!". The keybase server says this to the keybase CLI: "Bob's pubkey is <key>, and I'm right because https://twitter.com/bob/tweets/1234 says so". The CLI then verifies that the tweet URL really contains the right fingerprint. This extends the trust root to the twitter user (and your local HTTPS CA store). Repeat for a variety of services similar to Twitter. This extends the trust root to the union of all the social site accounts of the keybase user. Whether you choose to trust those is (as always with trust roots) entirely up to you.
Not the worst idea ever, in my opinion.
Comment · 12 years ago
> In the months since, as the team built and tested and refined the product, we’ve been watching Metro’s adoption. From what we can see, it’s pretty flat.
Cue rimshot.
Daedalus is reinventing precision manufacturing. We are a team started by two OpenAI tech leads (we did the Rubik's cube robot hand project). We're building a distributed system for software-defined autonomous production of precision parts for spacecraft, medical devices, robots, and many others.
Tons of interesting challenging problems in the areas of distributed systems, reinforcement learning, computational geometry algorithms, robot perception & control, scheduling & optimization, FEM simulation, and many more.
No robotics experience required— we're looking for experienced software engineers (e.g. working on SaaS/infra) who are looking for a challenge. You'll join a multi-disciplinary team of folks hailing from SpaceX, Cruise, Stripe, Ripcord and others.
Our stack is built from scratch to power the next generation of robotics: Python, Rust, Bazel, gRPC, runC
Job posting:
San Francisco, CA — https://bit.ly/3udjQdC
Karlsruhe, Germany — https://bit.ly/39A4ojX
Or email me directly: [email protected]