21–30 of 89 posts
Migration implementations for any platform have always been somewhat vexing for me, but South has been all but automatic for me. I've never had to deviate from `schemamigration app --auto && migrate app`.
Excellent. Pile up your django with extensions, then look forward to the fun when you have to port your app from e.g. django 1.3 to 1.5 and find a new set of versions of all of your dependencies that work nicely together. And of course figure out a migration path for it all. That is, if extension xyz is still maintained at all. Lean is beautiful, people. Carefully assess every dependency you add, as each one has the…
Wait. If you need a piece of functionality, you either get something that works out of the box, or you spend X hours writing it. If the out-of-the-box thing breaks and you spend Y hours fixing it, then Y has to be much greater than X to not be worth it, which, in my experience, it never is. Not to mention that, if the library broke, then the thing you would have written would have probably broken as well, and you wou…
As someone who is just starting to dive into Django and Python in general I have to admit being confused by benchmark after benchmark that puts Python near to the bottom of the performance curve when compared to other technologies (Go being one that jumps out at me). I have to admit that part of me is wondering if I am making the right decision in investing time, effort and money getting up to speed on Python/Django…
Your performance concerns (and I believe the other comments have touched on this) likely don't matter for most real world sites, and then, even if you get big, you can probably work it out (Pintrest is done with Django I believe, Github is rails, etc).
The question you really want to ask yourself is what does your compiler/runtime do for you. I've been pretty much solely a Python developer for the past year or so, but I like Java (... yea, I know), and find Go interesting, too. A compiler is no excuse to not write tests, but you know what you've written is going to run after it compiles. Added datetime's wrong in Python by adding one that has a timezone marked and one that doesn't? Runtime error. In fact, everything is a runtime error. Tests should not be optional regardless of language, but with Python and Ruby, they really take the place of the compiler in statically typed languages.
I don't want to discourage you from Python by any means, the Django community is fantastic, and Rails 4 with it's Russian doll caching seems pretty sweet. And nothing can beat the libraries for these two projects. The other options that I've seen (ASP.NET, Java Play, Go Revel, all for which, admittedly, I've only done preliminary reading about) just don't seem to have the libraries to get you off the ground as fast (though, if you've never written all the tedious stuff like user creation, email password resets, it is a good exercise in web development basics).
If you stick with Python I encourage you to: 1. Tackle learning the best practices for testing as you go. 2. Check out Two Scoops of Django [1] after having used Django for a bit. 3. Learn good server management skills (maybe look into Puppet [2])
The third seemingly is an offshoot, and would be necessary for really any framework, but once you're ready to deploy your app, you'll likely spend a great deal of time comparing your various options for stack choices and will get your sever set up just how you want it. Make sure that process is easily repeatable. If you don't like how Puppet does it, look into Chef or Salt Stack or whatever; these will save you tons of time down the line.
[1] https://django.2scoops.org/ [2] http://docs.puppetlabs.com/mcollective/reference/basic/getti...
As someone who is just starting to dive into Django and Python in general I have to admit being confused by benchmark after benchmark that puts Python near to the bottom of the performance curve when compared to other technologies (Go being one that jumps out at me). I have to admit that part of me is wondering if I am making the right decision in investing time, effort and money getting up to speed on Python/Django…
Excellent. Pile up your django with extensions, then look forward to the fun when you have to port your app from e.g. django 1.3 to 1.5 and find a new set of versions of all of your dependencies that work nicely together. And of course figure out a migration path for it all. That is, if extension xyz is still maintained at all. Lean is beautiful, people. Carefully assess every dependency you add, as each one has the…
As someone who is just starting to dive into Django and Python in general I have to admit being confused by benchmark after benchmark that puts Python near to the bottom of the performance curve when compared to other technologies (Go being one that jumps out at me). I have to admit that part of me is wondering if I am making the right decision in investing time, effort and money getting up to speed on Python/Django…
Here's the advice I was given: if you're going to go with an opinionated framework, go with Rails. If you really want to use Python over Ruby, go with Flask. His thought is that Ruby is more dogmatic than Python by design, so Rails' dogmatic nature lends itself to Ruby more. Python's flexibility lends itself to a more flexible, lightweight framework like Flask.
http://www.python.org/dev/peps/pep-0020/
Choosing a minimalistic web framework like Flask or Sinatra makes sense if you're experienced enough to know what choices Django and Rails make for you and you're comfortable making those decisions on your own. Otherwise, pick Django or Rails and start building things.
What, no django-annoying? That's the first thing I ever use: https://github.com/skorokithakis/django-annoying That, and shortuuid: https://pypi.python.org/pypi/shortuuid/ Disclosure: I maintain one and wrote the other, but they and South are the three things I use for every project.
I don't think I'd ever feel comfortable starting a Django project of any size without using South. Wish I had known about it since the beginning of my time with Django. Migration implementations for any platform have always been somewhat vexing for me, but South has been all but automatic for me. I've never had to deviate from `schemamigration app --auto && migrate app`.
On the other hand, I ensure that every change that needs to be made to the schema can happen at any time, and both new and old versions of the code will happily work. I believe this helps with upgrading in that there is no delay during deployment and migration. Having not used south on a real project though, I'm unsure if this is a false benefit.
We are all eagerly waiting south to be merged into Django. https://github.com/django/django/commit/9aa358cedd1ad93c0f4c... Or have we?
We are but it will still need South or other app to actually command the migrations if I have understood correctly.
As someone who is just starting to dive into Django and Python in general I have to admit being confused by benchmark after benchmark that puts Python near to the bottom of the performance curve when compared to other technologies (Go being one that jumps out at me). I have to admit that part of me is wondering if I am making the right decision in investing time, effort and money getting up to speed on Python/Django…
For many web programming tasks, your user-perceptible speed and/or maximum system loads will not be dominated by the performance of your web application but rather by database, I/O (including networking), and client performance (JS performance, aggressive asset caching, CDN usage, etc etc). Go or Java are wonderful languages if you have serious number-crunching needs or if cutting your server budget in half would sav…
That said, I'm not Google either, and I'm happily using django and love using it.
[0] http://www.techempower.com/blog/2013/03/28/frameworks-round-...