Hacker Newsnew | past | comments | ask | show | jobs | submit | tkaemming's commentslogin

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.


I'll add a link to the HN discussion.

edit: ok link added at the bottom of the article. I hope that helps, I figured out belatedly that this may have been your way of making a joke but it is a useful addition so thank you for the hint.


> 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.)


Exactly, that's my point. Not meant to demerit your great work.

The admin/crud stuff, moderation panel, account management, etc, that's what django was developed for. Great choice.

If you ask me to start Disqus from scratch again, I'd probably use django too, for the admin part, but for the API I'd go commando, closer to the metal, without framework at all. No need to load a 100MB routing/modeling/templating monster just to perform an invisible API call.

Highly optimized plain python scripts would work better.

Sometimes frameworks are more like handcuffs. Just sometimes.


We have never ever used the Django admin, and I would choose Django any day of the week for a project that is web on the web and using a database.

(In fact almost every single project I've ever built has used Django, and there's never been a limiting factor of that choice)


It's pretty easy to implement yourself but Django's middleware helps a lot too even with APIs.


> 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.


Provider redundancy goes against the concept of PaaS IMO (ignoring the sci-fi future where there are multiple 100% compatible providers). Heroku needs to become internally redundant to really live up to its promise.


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


I've found this view_class_decorator and MultipleFormView particularly helpful with class-based views: https://gist.github.com/1953579


I don't care for the decorator at all, but the MultipleFormView mixin looks very handy. Thanks.


The decorator actually raises an interesting issue. Are permissions and security part of the core application logic, or are they wrappers.

The mixin approach is nice and OO, but it's potentially tying two different layers of functionality together. Whereas the decorator is closer to aspect-oriented programming which attempts to isolate core business logic from such modifiers.

I'm actually quite interested in the challenge of applying design patterns for large systems (inversion-of-control, AOP etc) to Django, which has some stubborn behaviours that get in the way.


True, that does bring up an interesting point.

I'll have to give it another look later, maybe I'll change my mind.


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.


Steve actually drove a Mercedes SL55 AMG: http://latimesblogs.latimes.com/money_co/2011/10/steve-jobs-...


The article mentions that he drove with no license plate. But I always wondered if he possessed the plate and never attached it, keeping it inside the car just in case.


New cars in California don't come with plates, so it's not uncommon to see cars without any plates at all, especially in the Bay Area. You get temporary plates in the mail and are responsible for affixing them yourself. As long as your registration is current, your taxes are paid, and you have insurance, getting caught without the plates is a small fine.


California has special rules for celebrities stemming from safety concerns.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: