amikazmi

6 ms·

31.
by amikazmi 14y ago
Sounds like a good thing to me- If it was better for your previous firm to pay more than to optimize, it's actually preferring developers time (which cost money, as you know) over servers cost. This can be cost effective until some point. I
32.
by amikazmi 14y ago
You can make the benchmark with Rails Metal, or with Rack. If you want to compare non-blocking IO, use with eventmachine.
33.
by amikazmi 14y ago
I think he meant to say that the idea is trivial, not the execution. Just like twitter "idea" of publicly broadcasting 140 chars is trivial to make, but the whole "twitter" isn't.
34.
by amikazmi 14y ago
In your experience, it's necessary with others' code. In my experience, it's rarely necessary. As long as you're glad with your false assumptions, I have nothing more to add.
35.
by amikazmi 14y ago
False dichotomy. "All code has bugs" claim is true, but it doesn't mean you need debuggers in order to solve/fix the problems. If your methods ARE small enough, and you have tests for OTHER cases, printing/console is actually faster (at l
36.
by amikazmi 14y ago
1. if you keep your methods small, and have tests, you rarely need a debugger. 2. the generated js isn't that complex and you can easily map it in your head- it's not like trying to "debug" asm generated from C. 3. you'll get debugging soon
37.
by amikazmi 14y ago
So you could jump right into the talking part- with a web interface you'll have to get a phone afterwards.
38.
by amikazmi 15y ago
IO.readlines(file).each do |w| puts w.split(//).find { |c| w.count(c) == 1 } end
39.
by amikazmi 15y ago
I think the idea was that only Google will crawl your site and update the index, then the rest of the search engines will use the index instead of hitting your site.
40.
by amikazmi 16y ago
jruby bytecode is heavily cached (on top of the caching done by the JVM) http://blog.headius.com/2010/05/kicking-jruby-performance-up...
41.
by amikazmi 16y ago
But (b) assumes that they use light to know about us.. That may be false :)