tkaemming
tkaemming on Hacker News
It's a shame that comments like this one repudiating several of the details in the original article can't be viewed at the location of the originating post.
Instead, everyone who reads the article in the future will have an one-sided impression of the situation (unless the author edits the post based on the points brought up in this thread) due to the lack of comments.
> What is a distributed commenting system? An HTML script tag to load a static file that will ping an api that will serve you comments.
This is how Disqus works. Something still has to power the API that serves the data for it and we happen to like Django a lot so that's what we use. There are also a lot of parts of Disqus that are not the embed (moderation panel, account management, etc.)
> There's no way that we can entrust the business to something that can just catastrophically fail at any moment.
Anything, including service providers, can catastrophically fail at any moment. Fault-tolerant architectures are based on redundancy (including infrastructure provider redundancy, as you mention), not on "guaranteed" SLAs.
It's worth noting that if you're planning on instantiating multiple instances of the same "class" (to use the term generically/loosely) instead of immediately invoking the function, the module pattern has a much more significant memory footprint than prototypical inheritance — total memory usage should increase linearly with the number of objects you're creating, since you're creating new copies of all member functions each time.
Jeremy Ashkenas (who knows a lot more about this than I do) explains this in another comment thread here: http://news.ycombinator.com/item?id=2991904
> "git reset" has quite simple syntax, but it confuses the hell out of even experienced git users because it's very clever and potentially very dangerous.
For anyone who gets a panic attack before running `git reset`, this talk may help clarify how things are working under the hood: http://www.infoq.com/presentations/A-Tale-of-Three-Trees
Seeking Work - Remote preferred, or SF-ish (North Bay)
Available for short- or long-term engagements. Experience with building large Django applications and working all over the stack (both server- and client-side). Would prefer working in a team environment, opposed to being the primary/single programmer responsible for development.
Contact: ted [at] kaemming.com, other details at http://kaemming.com, code at http://github.com/tkaemming
> Running a whole VM just to run an app is immensely irritating.
Although starting a VM to run an app is irritating, spending time hunting down why your build is breaking (or worse, why production is breaking) because someone had a library a few minor versions out of sync or because they're on a different operating system is immensely more irritating.
The redirection has to be done on the client-side, because the server never receives the fragment identifier as part of the URL.
Posted by
tkaemming on Monday January 30, 2012 @01:21PM
from the code.google.com dept.
If you think that's exorbitant, you should check out the $29.99 iPhone app.
Also worth noting is Steve Souders' control.js (
http://stevesouders.com/controljs/) which adds some tools for delayed script execution and solves a few document.write use cases that have been issues with deferred loading/execution.
It's easier to ensure that you live on a "quiet street" when the street doesn't go anywhere.
Posted by
tkaemming on Sunday May 01, 2011 @01:21PM
from the rc3.org dept.
That's easy — just delete `decimal.py` from your standard library.
"I agree with you and generally this is a great way for a startup to save money as well because new grads are cheap."
I'd argue the opposite case — if it's true that a good programmer is at least 5-10x more productive than an average programmer[1], you'd actually save money by paying the experienced programmer significantly more when compared to hiring a team of beginning or average programmers.
[1]: http://en.wikipedia.org/wiki/The_Mythical_Man-Month#The_surg...
I updated the original comment w/ the original and updated text. Sorry if you saw this as inappropriate — I had updated it before it was upvoted and thought it only clarified the points, not changed it.
Regardless, many deployments use this same technique for just this reason (to avoid spoonfeeding slower clients responses). How is this any more risky than running Apache up front, barring configuration errors (which could just as easily happen with any other server software)?
They (nginx, lighttpd) are more difficult to exploit, especially when used to buffer requests to a heavier upstream server like Apache.
EDIT (Clarification):
They (nginx, lighttpd) are more difficult — although not impossible — to exploit, especially when used to buffer requests to a heavier upstream server like Apache.
Specifically, they are typically able to handle many more connections than your application server would be able to (as long as they are properly configured), without the incurring the resource overhead of your application server by bufferring the HTTP request/response.
I'd hardly consider the V8 JavaScript engine a second-class citizen in Chrome at this point.
If you're going to call Deschutes a Portland beer at 160+ miles away (and at the same time, leave out Rogue? That one confused me.), I think it's fair to call Russian River, North Coast, Lagunitas, Bear Republic, Anchor, and Sierra Nevada all San Francisco area breweries — and it's a little hard to argue with those. (As long as you like hops, at least.)
They've been sending them out progressively. (I've received 3 over the past 5 hours.)
Posted by
tkaemming on Wednesday October 13, 2010 @02:22PM
from the research.google.com dept.
Odd — I'm running Snow Leopard and haven't had any issues with many of the libraries or apps you mentioned (boost, ampqlib, postgresql), although it's probably worth noting that I installed them all through Homebrew (
http://www.github.com/mxcl/homebrew/).
A possible disaster scenario: connection issues with the SMTP server are causing the initial exception, resulting in webserver connections that are open for excessively long periods of time (unless you're sending the emails asynchronously), since the process is blocked first on the failed SMTP connection, then again on the exception email attempt (and you're still not getting any notification that something is broken, unless you're doing some other kind of monitoring!)
Safari 5.0.1 (6533.17.8) here, no issues.