If the site isn't taken down during an update, some parts of it will always be broken during a schema migration since our ORM expects each table corresponding to a data model to be in sync after a code update. I guess you could always version your data models and handle the pre-upgrade and post-upgrade cases, but that seems like a lot of work in our situation.
Actually we're on postgres... It just makes me nervous when the migration is taking upwards of 10 minutes to complete since some of our tables have millions of rows and lots of concurrent read/writes are happening.
That's reassuring, I thought I was the only crazy fool who was storing json objects in database columns =). We do something similar for some of our data models at thesixtyone.com. It's really nice for not having to bring down the site for schema upgrades.
If you have an account, you can access your recently played history by going to your profile and then hitting the music tab. We're also working on an easier way to access your play history from the mini-player at the bottom left.
One killer for me is that GAE doesn't support running scripts outside of web requests. Webapps need cronjobs to do things like sync or cleanup data, populate news feeds, perform analytics etc.
You store the password hashed with a salt in the database (just keep track of the salt you used). The server can send the salt to the client, in addition to the random number. So the client is performing two hashes: md5(md5(password+salt)+random_token).
There are still ways to add a little extra security for non-ssl logins. One way is by hashing the password via javascript with a random number provided by the server before posting it via HTTP. (see http://pajhome.org.uk/crypt/md5/auth.html)
As a web app developer, I've found memory to be the greatest bottleneck for both web and database servers. But this will no doubt be useful for sites like animoto that need to do a lot of offline processing.
Seems like this script does a top level document search for nodes to apply it's PNG fix. This can really hurt performance for sites that have complicated layouts. Sometimes it's best just manually code your own png fix solutions (fix exactly the image and div nodes you need for each page, rather than conducting a document.getElementsByTagName.. sweep)
Let me get this straight. So you would choose the framework with slightly better plugin support and larger community even if it meant it was three times slower and consumed twice as much memory? If you have deep pockets and have no adversion to unnecessarily managing huge server farms, then go ahead.
I've presided over two rails websites in the past and topping out at around 15req/s on average was not fun. Rewriting to Django and getting 45req/s and less memory usage was definitely worth it. (I'd rate my development experience in other areas to be about equal)
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 to using SQLAlchemy was supposed to address the gaps, but the branch for the upgrade seems pretty dead... But overall I'm pretty happy due to the transparency of django's framework code. I've implemented some customizations that would have been a lot harder to pull off in rails.
If you had to choose a python web framework, I'd suggest taking a look at pylons which is more flexible (also, by default it uses mako templating which > django's templating and supports SQLAlchemy).
Well, ProjectWedding.com was designed by women and it is steadily growing (it currently receives 10,000 page views a day from northern california bride-to-bes).
It's assumptions like yours about theknot.com's monopoly which make this "project" (pun intended) particularly enticing :)
http://www.thesixtyone.com/tags/song/show/sam/mellow/
Or go to your profile and click on the tags that appear to your right.