1,215 karma · joined March 16, 2009
I design and develop websites and apps.
That's where the DI part comes from -- to enable us to load a different dependency based on the customer. Now, you could provide a different bootstrapper class per customer or start building a mega class with a lot of ifs-and-buts(elses), or you specify this kind of stuff in a configuration file.
We opt for configuration files. We opt for IDEs that can interpret Spring configuration files which means typos or incorrect dependencies do show up. This allows us to swap out implementations in case shit goes down without having to recompile, connect over a VPN to a remote desktop and hop through a few more hoops to get our class file on the other side. If you're not running your own apps on infrastructure you control (we should be so lucky), you have to take this sort of stuff into account. I'd love to be able to say "This is how stuff's set up. Deal with it."
(And when shit goes down, it is usually not at the place you were expecting it to happen, which means all kinds of configuration options for your bootstrapper would probably still fall short.)
What the hell does it do? I'm not signing up without knowing a single thing about this service.
If you want to invoke some Django-based logic at regular intervals without having to install Celery (and monitoring and a decent queue) you'll opt for a management command. The link you posted should help you out here. Invoking the script yourself or telling cron to invoke it for you shouldn't be hard if you know about cron.
With regards to Celery: I think the tutorial and docs are pretty clear on how to use it and how to set it up.
But you don't have to use "startproject". Here's an example: http://olifante.blogs.com/covil/2010/04/minimal-django.html
No, I don't recommend you to do that. Use Flask, Bottle or any other lightweight framework/library you want to use. Just don't get hung up on how the Django docs suggests you structure your project. It's all still Python.
Really, Flask's config options are better, but they aren't that different from Django. Use the default settings, tell Django which settings to use from the commandline or specify an environment variable pointing at the settings to use. Where you put those settings is completely up to you - nobody's saying they absolutely positively must be part of your repo.
When you're working with multiple environments you'll have to specify which configuration to use one way or another so I'd prefer it to use the least amount of abstraction.
Have a look at PatternTap (http://patterntap.com/) to find inspiration for specific bits of the UI. Find out how you would create your own in Photoshop/Gimp/Illustrator/Pixelmator/Paint. Maybe add a texture, find a better color scheme or change around the font.
Then build it with HTML/CSS/JS. Use Frontpage, Dreamweaver, Eclipse, Vim, Notepad++ or, hell, even regular Notepad. It does not matter.
Great designers use the tools they are comfortable with. Most use a tool such as Photoshop to build something tangible (a PNG, PSD or, if you're management-material, PPT). That let's them define the way the website should look under ideal circumstances without getting to hung up on the correct HTML and CSS. Then they cut that up and code it in HTML and CSS to create something useful.
That's what you need to practice. And if you're worried your designs look too "Web 1.0", you need to focus on the first part of that process: defining what it should look like, before opening up your editor of choice.
(But I think you guys forgot to filter the proposal queryset by account in the SnippetForm.)
It looks great and I can't wait it to try it out myself (hint).
As someone mentioned before, he'd be better off tweaking bits and pieces and iterating. Making the oval in the logo a bit smaller and making the size of the bingo card the same as the text next to it.
But what I'm really wondering (and it's far less work): would changing the favicon to a bingo card or perhaps a green or blue square with a white B on it make a difference? Don't laugh, I'm willing to put some money on it ;)
It's difficult to quantify the increase in productivity using Django - since I never wrote the same project twice and a lot depends on the Java frameworks you use and the type of apps you write - but I certainly feel more productive and: happier! A lot can be explained by the fact that I'm basically forced to do the whole compile-war-deploy cycle on my current Java project and that Python allows me to write real generic code.
Be sure to first check out the tutorials in the Django docs because setting up a project for the first time can be a bit intimidating. Totally worth it, though ;)