exogen

113 ms·

451.
by exogen 15y ago
I realize that, just wasn't sure of how to describe it which is why I tacked on "effect" (might not be the actual type of distortion, but to a user the appearance is similar). From a user's perspective it most definitely does look wrong eve
452.
by exogen 15y ago
I'm most impressed with the stitching and lack of the typical fisheye distortion effect that plagues 3D views like this. Almost every possible view looks like a normal photo. Well done!
453.
by exogen 15y ago
Hmm, you'd still have to ensure that your selector has higher specificity, right? That itself can be hard unless you're okay with adding !important to everything. I was thinking that inherit: none would somehow address this, but the rules w
454.
by exogen 15y ago
> In general, I would argue you should just try to play nice with whatever inheritable styles you're given to the extent you can. Sure, your widget will be unreadable if the page chooses black-on-black text, but so will the page, so tha
455.
by exogen 15y ago
There is that, which is nice when you can get away with it. Unfortunately I still consider this the "hard" approach for a few reasons. 1. Supporting IE7, for which people tend to use an intermediate Flash object to do the communication. 2.
456.
by exogen 15y ago
I'm surprised only one person mentioned "inherit: none" for CSS (that's what they called it, anyway). If you've ever tried to develop a widget that anyone can stick on any old page, you know this: either you go with an IFRAME and your style
457.
by exogen 15y ago
I've been using Inkscape forever and I love it. Very easy to learn. It's one of those programs that I never even knew had a settings/preferences window until years later, because the default behavior is just that good. Even after switching
458.
by exogen 15y ago
There's a tradeoff here, which is that you'll have to stick to a strict subset of conventional Node. Not just the builtin libraries (fine, that's expected), but basic conventions. For instance, your approach doesn't support assigning to `mo
459.
by exogen 15y ago
Well, you've got some stiff competition. :) See: http://blog.brianbeck.com/post/10667967423/node-js-require-i... Is there something that differentiates your approach? I do actually think there's room for improvement in these libraries, so
460.
by exogen 15y ago
I noticed that too. Look at the backs of the filled chairs, though – all reserved.
461.
by exogen 15y ago
If "obviousness" is the criteria for a well-designed OS, I'm not sure we've seen a (successful) well-designed OS in the history of computing. OS X certainly doesn't deserve to be called out. :)
462.
by exogen 15y ago
Yes, I suspect that you're right; I also thought it might be due to the GIL. I reran this test with Python 2.7 and it no longer appears to be true: Spawning 100 children with Thread took 0.03s Spawning 100 children with Process took 0
463.
by exogen 15y ago
Please, show us even one Node developer who posted "Yes it is the one true tool!" – or even a sentiment that is remotely similar.
464.
by exogen 15y ago
1 & 3 might be conventional wisdom, but are you absolutely certain they're still true on modern platforms? http://blog.extracheese.org/2008/05/processes-spawn-faster-t... (I'm not saying they aren't or that I know the answer.)
465.
by exogen 15y ago
I think a lot of people would find this comment more helpful if you explained why.
466.
by exogen 15y ago
I think it's safe to say that typical Ruby deployments (as I qualified) are not using JRuby, especially not those on Heroku. Thus, even if the process spawns threads, they will be limited to one core at a time. Whether JRuby's threads are
467.
by exogen 15y ago
I think in this case, we have yet to see the master put anyone on their ass. We have non-masters slinging insults and ineffective demonstrations. Don't typical Python and Ruby deployments also need 8 processes to utilize 8 cores? If I'm not
468.
by exogen 15y ago
It's possible I'm misinterpreting the results (or the benchmark is flawed), but this seems to imply that it is often the case: http://shootout.alioth.debian.org/u32/benchmark.php?test=all...
469.
by exogen 15y ago
Whoa, whoa. "Just as slow at handling?" It's most likely an order of magnitude faster at handling those. But you're right, deployment isn't a totally solved problem. Unless you just use Heroku: http://devcenter.heroku.com/articles/node-js
470.
by exogen 15y ago
I'll say this again: Ted shouldn't have wasted everyone's time highlighting the response time of the request. He effectively benchmarked V8 right on his blog and then called it slow. Now everyone's complaining that people at least demonstra
471.
by exogen 15y ago
Sure you're calling fibonacci(40) and not just defining the function?
472.
by exogen 15y ago
I'm not sure if many people are choosing Node just because they're familiar with JavaScript. Most people would probably rather be less familiar with JavaScript. More likely they're choosing it because the runtime is very fast and a lot of l
473.
by exogen 15y ago
One Node process is reduced to doing the trivial work, like you'd have in any other system. Nothing is preventing the other processes from also being Node.
474.
by exogen 15y ago
Thanks, I didn't know that. I've added a link to the article.
475.
by exogen 15y ago
It's a bit extreme to conclude that since Node's built-in HTTP server works this way, that it's "cancer." People still use it because it suits their purposes; there's nothing wrong with that. AFAIK, nothing's stopping anyone from writing a
476.
by exogen 15y ago
Nice. I just wrote a followup to Ted's post myself: http://blog.brianbeck.com/post/node-js-cures-cancer I couldn't believe when folks on Twitter seemed to be buying his "argument." (Apologies for the self-promotion. I had literally just p
477.
by exogen 15y ago
Looks great. Just a suggestion, I'd add another download link to the top of the page.
478.
by exogen 15y ago
I realize the situation may have been different when the Applications chapter was written, but I would be careful of the subtle jQuery.tmpl "endorsement" in the "JavaScript templates" section. jQuery.tmpl is unmaintained, slow, and very bro
479.
by exogen 15y ago
Weird – I'm using Chrome 14 and Safari 5 and don't see it. Firefox works though.
480.
by exogen 15y ago
Seattle, WA BigDoor: http://www.bigdoor.com/ We're a gamification platform – we make it easy for anyone to add fun, relevant loyalty programs to their site or app. Lots of people are focused on badges and leaderboards – and we do that – b

More ›