Deployment of Rails sucks. Django is far better thought out, and can be deployed in a very sane manner. A fleet of Mongrels is just an embarrassingly bad way to handle concurrency. "I know, let's write a crappy barely functional web server, spawn a metric ass ton of them, and then balance between them with a proxy. It'll be most leet and super fast! We'll call it a Best Practice. It'll be awesome." In fact, it's frag…
what is the preferred way to deploy django these days?
Rails vs. Django
21–30 of 35 posts
Re: Rails vs. Django
#22Earlier quoted context omitted.
Both, but the ORM more. I am curious, why do you ask?
I've been learning it recently and I'm not sure what to make of it, specifically the ORM component. It certainly has a good reputation as far as ORM's go, but I'm not sure if even a good ORM fits a large, popular, or complex app, or is perhaps more suitable for protoyping and low-traffic uses. But since SQL is pretty necessary for most web apps, it makes sense to pick some abstraction layer, and as far as I can tell…
Things I learnt, that might help.
1. You don't have to use SQL.
2. If you are going to use SQL, Find a wrapper that is minimalistic for your current needs. Work with lesser and you will work more but you will also work with more freedom and sanity.
Best of luck friend. :)
Re: Rails vs. Django
#23Earlier quoted context omitted.
I've been learning it recently and I'm not sure what to make of it, specifically the ORM component. It certainly has a good reputation as far as ORM's go, but I'm not sure if even a good ORM fits a large, popular, or complex app, or is perhaps more suitable for protoyping and low-traffic uses. But since SQL is pretty necessary for most web apps, it makes sense to pick some abstraction layer, and as far as I can tell…
Things I learnt, that might help. 1. You don't have to use SQL. 2. If you are going to use SQL, Find a wrapper that is minimalistic for your current needs. Work with lesser and you will work more but you will also work with more freedom and sanity. Best of luck friend. :)
I know nothing about sql wrappers but I do know whenever I have a scaling problem it is ALWAYS the sql. I doubt if any wrapper will save me from this. As your database grows larger you need to fine tune your sql, indexes, and so on.
Re: Rails vs. Django
#24Earlier quoted context omitted.
Both, but the ORM more. I am curious, why do you ask?
I've been learning it recently and I'm not sure what to make of it, specifically the ORM component. It certainly has a good reputation as far as ORM's go, but I'm not sure if even a good ORM fits a large, popular, or complex app, or is perhaps more suitable for protoyping and low-traffic uses. But since SQL is pretty necessary for most web apps, it makes sense to pick some abstraction layer, and as far as I can tell…
Oh yeah...One more thing. The good reputation of SQLAlchemy - is unfounded. Let me explain.
See it does all the basic stuff and so do the others.
Then some relatively famous programmer who is also a blogger wants to do something esoteric so they evaluate all wrappers and eventually find that SQLAlchemy can do it if you are willing to write brain damaging code.
Then because after many many hours of head banging they finally make it work they can't wait to gloat over the sustained brain damage and how SQL Alchemy rocks, so they write it up in a blog.
Then guess what, simpletons like me read the famous peoples blogs, get suitably impressed and sustain permanent brain damage, if we survive we join the bandwagon and gloat too - with good reason, this thing is impossible for humans to use. If we fail, we do what we should have done in the first place, look for alternatives.
PS: Now that I read it again it sounds like I am talking about Ruby on Rails!!
Re: Rails vs. Django
#25A search on amazon.com for 'ruby on rails' yielded 48 books, a search for Django comes up wuth 3 unpublished books.
The stats above, made the decision for me.
Re: Rails vs. Django
#26Deployment of Rails sucks. Django is far better thought out, and can be deployed in a very sane manner. A fleet of Mongrels is just an embarrassingly bad way to handle concurrency. "I know, let's write a crappy barely functional web server, spawn a metric ass ton of them, and then balance between them with a proxy. It'll be most leet and super fast! We'll call it a Best Practice. It'll be awesome." In fact, it's frag…
I'm not sure why they think "assload of processes + proxy" is so good either, but deploying an assload of mongrels behind the "pound" load balancer is damn easy. Plus, pound is light-weight, fast, and designed to be small so that it can be easily security audited.
All you have to do is install pound, edit the pound config file to tell it how many mongrels you have and what port range they live at (easy), do a "gem install mongrel_cluster", then a "mongrel_rails cluster::configure" and a "mongrel_rails cluster::start".
I know this sounds like a lot of steps, but if you've ever built and configured apache from source you know this is cake in comparison.
Re: Rails vs. Django
#27jesusphreak has a pretty good writeup that's worth reading on the pros of using django: http://jesusphreak.infogami.com/blog/why_django Having come from a rails background and later switching to django I think it comes down to a matter of preference. Django's ORM gets the job done but leaves something to be desired (ugly syntax, no multiple database support, also watch out for implicit cascading deletes!). Conversion…
Actually SQL sucks and hence all wrappers suck too. The over-engineered SQLAlchemy sucks most. If you are python user you should find SQLAlchemy ugly. As far as frameworks goes, for most deployments(not for all) I would suggest pylons over django. Mako is very useful.
"Actually SQL sucks and hence all wrappers suck too. "
Amen.
Re: Rails vs. Django
#28Deployment of Rails sucks. Django is far better thought out, and can be deployed in a very sane manner. A fleet of Mongrels is just an embarrassingly bad way to handle concurrency. "I know, let's write a crappy barely functional web server, spawn a metric ass ton of them, and then balance between them with a proxy. It'll be most leet and super fast! We'll call it a Best Practice. It'll be awesome." In fact, it's frag…
I'm not sure why they think "assload of processes + proxy" is so good either, but deploying an assload of mongrels behind the "pound" load balancer is damn easy. Plus, pound is light-weight, fast, and designed to be small so that it can be easily security audited. All you have to do is install pound, edit the pound config file to tell it how many mongrels you have and what port range they live at (easy), do a "gem in…
Ah, yes, I'll wait here while you go convince a few shared hosting providers to let you do that to their servers.
Re: Rails vs. Django
#29Deployment of Rails sucks. Django is far better thought out, and can be deployed in a very sane manner. A fleet of Mongrels is just an embarrassingly bad way to handle concurrency. "I know, let's write a crappy barely functional web server, spawn a metric ass ton of them, and then balance between them with a proxy. It'll be most leet and super fast! We'll call it a Best Practice. It'll be awesome." In fact, it's frag…
I went for rails myself, and agree about Mongrel. It seems like the Rails guys are all anxious to throw the Apache baby out with the bathwater, and spend a lot of time fooling around with dodgy ways of doing things. For now, I use the mod_fcgid Apache module, and it seems to work ok for what I need.
i heard through the grapevine that zed shaw, the dude who wrote mongrel, is down on it and isn't actively developing it anymore. hopefully someone else will pick up the slack, but i'm afraid that 95% of the folks using ruby+rails are know-nothing newbies (like me). =P
anyone have any experience with lighttpd + rails?
Re: Rails vs. Django
#30Earlier quoted context omitted.
I'm not sure why they think "assload of processes + proxy" is so good either, but deploying an assload of mongrels behind the "pound" load balancer is damn easy. Plus, pound is light-weight, fast, and designed to be small so that it can be easily security audited. All you have to do is install pound, edit the pound config file to tell it how many mongrels you have and what port range they live at (easy), do a "gem in…
Ah, yes, I'll wait here while you go convince a few shared hosting providers to let you do that to their servers.
Touche.