31–40 of 62 posts
I wonder why Dave Paola (apparently admin at djangy according to DEBUG view at http://djangy.com/postreceive ) used room606 instead of his regular account endlessvoid94 for submitting this.
How do they plan to compete against Google App Engine? http://www.allbuttonspressed.com/projects/djangoappengine
App Engine is a pain in the ass, and I wouldn't recommend it to anyone. Heroku is so simple to use that I've many times felt that someone needs to build a Heroku for Python. The only thing really wrong with App Engine is the datastore: - It's very different than anything you've come across before - The docs are not sufficient for it's complexity. You end up having to read lots of blogs and watch lots of videos to fig…
I've been working on my Heroku for Django (or Python more generally) for a month or two now. It's good to see somebody else thinks this is a good idea.
How seriously can you take a service if developers forgets to disable the DEBUG flag :) http://djangy.com/admin
Use of SQLLite too - does that scale and perform well against something like postgres? I think what we're seeing here is an email/hype-grabbing attempt with an interesting vision, using the Heroku name for leverage. Would like to see it materialise, but they really should have hardened something as simple as a signup form. I've emailed the admin telling him to lock it down.
I tried SQLite for a few things, and it has always come out a champ. I would not hesitate to use it for most of the semi-static websites I make (web apps would be pushing it), if I were sure it can handle more than one connection (I'm not, sadly).
I am very, very impressed by it. Seriously solid database.
Earlier quoted context omitted.
I regularly use Fabric. After deploying a couple of projects with it, I have come up with a standard deployment layout and stack. Now its as simple as "fab deploy" and "fab revert". Thank you fab!
Same here, except I've set things up so that any changes I make to my project are automatically synced instantly to a live staging domain, and I don't have a revert command (although I do back up copies of previous deployments). I also keep apt and pypi dependencies in project-local config files and have a refresh command that updates those packages on both the remote and local machine along with some other stuff. I…
* push to
* update the files
* compile sass to css
* minify javascript
* process the dependencies file (using pip) for updates (it does nothing if I haven't added new dependencies)
* restart/flush/whatever I specify
It works beautifully, I can deploy changes in a few seconds.
EDIT: Okay how do I make lists :(
I've been working on my Heroku for Django (or Python more generally) for a month or two now. It's good to see somebody else thinks this is a good idea.
How does it work? How do you handle persistence and parallelism?
My number one goal is to provide a deployment environment with as few additional restrictions on the developer as possible.
Never write form confirmations ("Thanks for your email") in red color. Looks like a warning. If a form is processed correctly, it should be black or green. I hope that usability of djangy service will be better. Can't wait to try it :) Btw, isn't Heroku itself planning anything for Django?
> Btw, isn't Heroku itself planning anything for Django? Has that ever been mentioned or rumored before? Is that even feasible given Heroku's technology stack?
Never write form confirmations ("Thanks for your email") in red color. Looks like a warning. If a form is processed correctly, it should be black or green. I hope that usability of djangy service will be better. Can't wait to try it :) Btw, isn't Heroku itself planning anything for Django?
> Btw, isn't Heroku itself planning anything for Django? Has that ever been mentioned or rumored before? Is that even feasible given Heroku's technology stack?
The response was quite clear that they had no plans to enter the Django market.