244 karma · joined October 21, 2010
https://davidwilemski.com
Twitter: @davidwilemski email: hn [at] [lastname] [dot org]
The shell's builtin keyword for `time` is more limited in nature than the full `time` binary. This is true of a number of other common unix commands as well, e.g. `echo`. The manpage for your shell should describe the builtins functions.
I disagree with this entirely. Devs _you have workd with_ might not have cared but it doesn't make the statement universally true. As a counter argument, some of the best software developers I've worked with were also very good at operating and debugging production software and the reverse has also been true.
I also don't buy that the two are a different mindset (at least in the domains I work in and care about). In my experience the very best people (whether they're working "dev" or "ops" roles or something in the middle care about the entire development and deployment lifecycle of the software they work on. Building a good experience in software includes thinking about reliability and availability and planning a reliable and performant deployment also requires that to be thought of in the application layer at some point.
https://help.github.com/articles/open-source-licensing/#what...
http://defcon.org/html/links/dc-archives/dc-19-archive.html#...
While I don't actively participate in many open source projects, I have found myself reading the mailing lists and watching the issue trackers for a few projects over the past few months and as a result I feel that I have a very good idea of what is going on with them.
(not against your idea, just curious how you handle it)
I suppose API access to that would be a logical extension - this is very cool.
Running the detector on just a few nodes sounds like a great way to offset the performance penalty a bit. The docs on the race detector say that "memory usage may increase by 5-10x and execution time by 2-20x" which could be quite significant.
I also wonder about the effectiveness of randomly fuzzing your app with the race detector on as a form of testing.
I'm very excited with the Python integration. I'm going to try doing some web development with Light Table now. One thing that would be very handy would be support for virtualenvs or requirements files to integrate into workspaces so that we can work on projects without installing all dependancies globally.
http://www.tornadoweb.org/documentation/releases/v2.0.0.html
https://github.com/facebook/tornado/tree/master/demos/s3serv...