The ORM is bad because it is a poor abstraction of SQL. This manifests itself in several ways, the largest being little control over the SQL queries generated.
The poor abstraction really causes problems when you need to do anything beyond the simplest of use cases. To achieve even modest performance gains, you're better off hand writing your SQL. Additionally, doing even the most trivial of trivial aggregate queries will also mean that you're hand writing SQL.
SQLAlchemy is light years beyond the django ORM in this regard.
I think the most important difference between Alchemy and Django is the separation between the SQL abstraction layer and the ORM. There is no separation with django, making it very difficult to really get in there and make changes.
But I don't think this makes the django ORM bad. It is very easy for beginners to get up and running. It is very easy to understand the models and the query language.
As an FYI - 1.8 should make it possible to use .annotate() for constructs that aren't aggregates - like functions and extra select columns. You'll also be able to write more complex aggregates. It should give you greater control over your SQL, removing the need for .extra() in most cases (but not .raw()). It's what I've been working on recently: https://github.com/django/django/pull/2496
>The poor abstraction really causes problems when you need to do anything beyond the simplest of use cases. To achieve even modest performance gains, you're better off hand writing your SQL. Additionally, doing even the most trivial of trivial aggregate queries will also mean that you're hand writing SQL.
This isn't really a big deal - you can just hand-write your sql directly using .raw() and just pull out the corresponding result set and use it as you were doing before.
I've had to do what you're suggesting, but not a huge amount. Maybe 10-15 times on large, high scale projects.
SQLAlchemy is better but the number of times I have to break out of its abstraction layer are not enough for me to feel like I really have a desperate need to use alchemy instead. It's a minor inconvenience, nothing more.
On the CDN urls, you can just change them to use protocol relative urls.
It Looks like the jquerytools cdn doesn't support HTTPS, but you should be okay to use this one from cloudflare
I've had very similar situations to the poster. It's incredibly frustrating. This week I tried:
"I'm sorry, I don't understand. We just saw a demo showing the Facebook JS SDK was taking X minutes to load, and then masonry took a second. My understanding is that you want to concentrate on optimising masonry. I certainly agree with you that we can and should make masonry as fast as possible. However it seems to me that resolving the thing that's taking minutes rather than seconds would benefit us more."
In other words:
- restate the situation as you see it
- highlight the areas in which you believe common values exist
- rather than saying 'you're not listening to me' - even when it seems like they're really not listening to you - ask what their opinion of the matter is in light of what you've just stated.
This at least got us further: my colleague thought that resolving FB JS SDK performance wasn't possible. I disagreed and thought that with the massive amount of Facebook apps FB either have to know about the performance degradation or we were specifically doing something to interfere with the JS SDK performance.
(1) Part of it is about choosing whom you work with. Be careful about choosing a job that might have fun work, but is with repressed people. (2) If they are ignoring you in a meeting, there is a good chance that they have their self-image caught up in the conversation, and don't want to back down, and are getting emotional. The emotion behind rationality is humility.
Our interview process tries to filter out people that can't collaborate.
One thing to be aware of when storing sensitive information in environment variables, is that it is possible to view the environment variables a process is using.
A couple friends and I just spent the past 48 hours building an app that recreates a lot of this functionality. Some key things to note with this is that you're stuck with RDS, and locked in to amazons platform choice.
Can't you use RDS like any MySQL database? And since you're writing a standard WSGI app, it seems like there is very little lock-in. This seems to basically automate the provisioning of EC2 instances for the web app and the DB. and since you just have a standard app, you're free to move it around as needed.
Or is there something that I'm missing with the Elastic Beanstalk? (I've only used raw EC2)
Yes RDS is like any MySQL db. The key word there being MySQL. If you want to use another data store like say, postgres or even some NoSQL solution. You're outta luck.
As for platform lock-in, my comments were less towards the web services level and more about system level concerns. It's not entirely clear how you would run persistent background tasks (read: celery). This doesn't even get into the headaches of learning yet another DSL to define OS packaging requirements.
That being said, IMO this would be great for simple apps, with no strenuous requirements. In addition, anything that allows more people to easily deploy their django apps is a good thing.
Yes, RDS works with MySQL. And you're right about the provisioning for the EC2 instances for beanstalk, but it doesn't do much for RDS, that needs to be set up independently.
Here's a gist I made the other day demonstrating this. https://gist.github.com/jawnb/cd7a899cac5300c01709
The poor abstraction really causes problems when you need to do anything beyond the simplest of use cases. To achieve even modest performance gains, you're better off hand writing your SQL. Additionally, doing even the most trivial of trivial aggregate queries will also mean that you're hand writing SQL.
SQLAlchemy is light years beyond the django ORM in this regard.
Don't take just my word for it though, here's a talk Alex Gaynor gave saying the same things. https://www.youtube.com/watch?v=GxL9MnWlCwo