Django is one of my favorite open-source projects. I owe the project a lot.
Years ago, when I was a Microsoft-only shill (yeah, I'll say it), I knew how to build almost anything as long as something from Microsoft was under the covers. I was proud of my abilities, and in spite of the anti-MS crowd, I stood up for my platform and was a good developer.
In 2006, I had a short two-week break from my startup job, and my wife & kids were traveling to their grandparents' house at the same time. I had 336 consecutive hours to spend as I wanted, something I hadn't been able to do in many years. I decided I wanted to work on a little side project, something I could complete within those two weeks.
I made a decision to break out of my comfort zone. I knew a little about Linux, nothing about Apache, zero about Python, and had never worked with Mysql. I came up with an idea for a simple little CRUD application, just a utility site. It was something I knew I could build in maybe two or three days using Microsoft tools.
So, I searched around and found Django. I downloaded v0.9x (it was sometime in the summer, can't recall what it was specifically. I know it was pre-v1.)
And I started from the beginning, purely a newb. It was a position I wasn't accustomed to, so I immediately felt a lack of boundaries and sense of control. But the Django documentation was really good, and I soon gained an understanding of everything I needed to learn -- Python, running Apache, configuring Django, wiring up Mysql. I stayed focused and in one week, I had written my ridiculously simple CRUD app.
But the value I got out of it was how well the project pulled me in to becoming productive on a platform that I'd never used. Not only that, there was the help in the discussion groups from the community. It was a lot of fun, and I could recognize myself becoming a better developer.
The biggest realization came when I compared my Django project to an equivalent built on Microsoft tools. It wasn't a comparison of one-week vs. two-days, but rather one-week coming from square 1. All this led me to rethink my thoughts around my Microsoft background. I didn't become a convert per se, but it made me realize there are so many other ways of solving problems and other systems on which to build applications. And, after feeling productive, it made it easier for me to explore other (non-Microsoft) technologies. The feeling of being productive in multiple environments was so empowering.
I'm not sentimental about software, but the Django project is kind of that kid who can do no wrong in my eyes, due to my formative experience with it.
I'm quite interested in your experiences with Django, as I'm somewhat in the same boat. I'm a .NET developer, and while I love C#, am a fan of strongly-typed languages, and am quite fond of the .NET framework I have a soft spot for Python and especially Django.
Similarly, I had a few days and decided to go out of my comfort zone. A few days later I had written a blog script and had modified it to work with Google App Engine.
Do you use Python/Django in a professional setting now? If so, how did you find the full-time conversion?
I had a somewhat similar experience. I was using PHP for many, many years and after hearing all the fuzz about Ruby/Rails I tried to learned it but it didn't really click with me. However, when I tried Python/Django I was immediately hooked. The main deciding factors were Django admin site and the (cleaner than Ruby) Python syntax.
Looks like somebody jumped the gun when they saw the commits and uploads happening; the official release announcement went up only a few minutes ago, and is here:
Also: if you downloaded the package in the period between the parent link going up, and now, you might want to grab it again. The first roll of the 1.6 package (which wasn't announced, so we could do final checks first) failed to update our trove classifier, so the package was regenerated, which changed its signature and checksums.
Seems like a new release should be done? Isn't that what RC and pre releases are for?
Was the release uploaded to pypi or a download page? If so, that's released IMHO. eg, debian, various news outlets, and others auto scan download pages for new releases.
The dedication to Malcolm Tredinnick was a very nice thing for the Django team to do. I didn't know of Malcolm or his passing before reading the release notes, but he seemed like a wonderful person who will be missed by many. Very sad that somebody like that is no longer with us. Reading his tweets I get the sense he was a really cool guy.
One of the reasons I like Django so much is because of the community. This might seem rather meta but the comments in this thread are generally positive. Most Django users I know are well aware of its limitations and don't try to sugarcoat it if Django is not the right tool for the job. But overall I've found the community (and that of Python) pretty receptive.
The persistent connections that now exist within Django should give a quite but great performance boost for the vast majority of Django applications, which are not already running a connection pooler (http://www.craigkerstiens.com/2013/03/07/Fixing-django-db-co...). This alone can be reason enough to upgrade in addition to all the other improvements.
For those who works with designers or html people who don't use the command line, how do you collaborate with them with Django?
For me it's a perpetual issue to get them up and running, commit/push with git, etc etc. Is there an easier solution? Basically, I'd like them to get started and be able to tweak the templates and css as effortless as possible.
It's kind of very hard to have people working directly in templates/css and others updating html/css and them diff the changes, integrate them, etc..
- Build a workflow around pull requests / review branches a la github/bitbucket/gerrit so you can have them submit changes but an engineer reviews/verifies before it's merged.
In general, empowering them to do this is an investment in the future and well worth it.
I don't use django, but one of the easiest ways to get designers and non technical folks working directly on projects is to run virtual machines with vagrant[0] and automate everything as much as possible.
I also have this same problem. It's one of the things which has made me think about switching to web2py - you can edit templates and css, and do commits directly in the admin. There is something a bit crazy about it though.
Alternatively I don't think it would be that difficult to put a decent JavaScript-based editor on a page and allow editing of certain files, combined with a way of running the collectstatic management command.
Difficult enough for me to not have tried it though.
What command line stuff would they need to do? I've built a couple reasonably complex projects using Django, and I don't remember spending much time at all on the command line.
I think I had a one line batch file to start the server, but that's it. Subversion integrates directly into the filesystem with tortoisesvn and even Git has good tools these days.
I can't imagine a designer needing to touch the command line at all.
Working with frontend designers/developers in a few different languages (PHP/Python), the easiest way for our office was to just use a central development server in the office then use NFS.
Sourcetree is a little slow for them (they use Macs), but they seem to get the idea.
We put together a vagrant script and a set of instructions specifically for front-end devs on Windows who might lack the bash-fu and Python skills needed to get a local setup.
I would recommend using 1.6 and South for now. 1.7 is at least nine months away, and who knows where the API will go in that time. You're probably better off developing a stable version of your project using 1.6/South, and then refactoring when 1.7 lands.
No: 1.7 is not stable and it's not like the current migration situation with South is a particularly large pain-point.
What I'd do is use South now and essentially rebase when you upgrade to 1.7 – ensure that your servers are current with South, remove it and start over with 1.7's built-in migrations.
1.7 It is not hard to keep up with changes. And it is easier to do them incrementally than have big jump which you never find time to do and end up lagging versions and huge technical debt.
Once your project is deployed then think about sticking with specific version. Development should be on the bleeding edge!
I was always opening an object link in a new tab and then going back and hitting refresh in the main tab with the admin listing. Guess I won't have to do that anymore.
1.7 release will be very interesting. Instead of South there will be migrations support. At DjangoCon EU Andrew Godwin told about his vision of it. i.e. if you have 200 migrations you'll be able to merge them into 1.
Form fields will get extended support like input[type="email"]
Thirded! This is a better implementation for a framework. CBGV as-is would be better as an add-on app.
This is a great example why framework projects could benefit from being a bit more democratic. Most people seem to be pulling their hair out, telling you something is too complicated to effectively use. The response: It's worth it once you learn. The complexity cost is worth it. Trust us. Read the docs (of course), use this 3rd party site (ok...), read the code. (so I can write a non-trivial view!?). If you are still giving that answer years later, you have to be open to the fact that that your users might be on to something.
Often when you hear someone say they're using CBGV on a large project, you can almost sense the pause for applause.
The person who posted this apparently saw the version-bump commits and jumped the gun, posting a link to just our download page before we even had the release announcement out.
The announcement and release notes both have the information you want:
are there any particular performance improvements over the previous versions ?
I was thinking basically of transaction management, especially the autocommit behavior.
I browsed through the docs and saw that the default python database API requires autocommit to be turned off... but then again django overrides this behavior.
any comments on this ? (or am I completely lost ?)...
> Django’s transaction management was overhauled. Database-level autocommit is now turned on by default. This makes transaction handling more explicit and should improve performance. The existing APIs were deprecated, and new APIs were introduced, as described in the transaction management docs.
> Please review carefully the list of known backwards-incompatibilities to determine if you need to make changes in your code.
> Persistent database connections¶
> Django now supports reusing the same database connection for several requests. This avoids the overhead of re-establishing a connection at the beginning of each request. For backwards compatibility, this feature is disabled by default. See Persistent connections for details.
jroseattle|12 years ago
Years ago, when I was a Microsoft-only shill (yeah, I'll say it), I knew how to build almost anything as long as something from Microsoft was under the covers. I was proud of my abilities, and in spite of the anti-MS crowd, I stood up for my platform and was a good developer.
In 2006, I had a short two-week break from my startup job, and my wife & kids were traveling to their grandparents' house at the same time. I had 336 consecutive hours to spend as I wanted, something I hadn't been able to do in many years. I decided I wanted to work on a little side project, something I could complete within those two weeks.
I made a decision to break out of my comfort zone. I knew a little about Linux, nothing about Apache, zero about Python, and had never worked with Mysql. I came up with an idea for a simple little CRUD application, just a utility site. It was something I knew I could build in maybe two or three days using Microsoft tools.
So, I searched around and found Django. I downloaded v0.9x (it was sometime in the summer, can't recall what it was specifically. I know it was pre-v1.)
And I started from the beginning, purely a newb. It was a position I wasn't accustomed to, so I immediately felt a lack of boundaries and sense of control. But the Django documentation was really good, and I soon gained an understanding of everything I needed to learn -- Python, running Apache, configuring Django, wiring up Mysql. I stayed focused and in one week, I had written my ridiculously simple CRUD app.
But the value I got out of it was how well the project pulled me in to becoming productive on a platform that I'd never used. Not only that, there was the help in the discussion groups from the community. It was a lot of fun, and I could recognize myself becoming a better developer.
The biggest realization came when I compared my Django project to an equivalent built on Microsoft tools. It wasn't a comparison of one-week vs. two-days, but rather one-week coming from square 1. All this led me to rethink my thoughts around my Microsoft background. I didn't become a convert per se, but it made me realize there are so many other ways of solving problems and other systems on which to build applications. And, after feeling productive, it made it easier for me to explore other (non-Microsoft) technologies. The feeling of being productive in multiple environments was so empowering.
I'm not sentimental about software, but the Django project is kind of that kid who can do no wrong in my eyes, due to my formative experience with it.
btgeekboy|12 years ago
EnderMB|12 years ago
Similarly, I had a few days and decided to go out of my comfort zone. A few days later I had written a blog script and had modified it to work with Google App Engine.
Do you use Python/Django in a professional setting now? If so, how did you find the full-time conversion?
azio_m|12 years ago
Django admin site is still my favourite feature.
ubernostrum|12 years ago
https://www.djangoproject.com/weblog/2013/nov/06/django-16-r...
The release notes are here:
https://docs.djangoproject.com/en/1.6/releases/1.6/
Also: if you downloaded the package in the period between the parent link going up, and now, you might want to grab it again. The first roll of the 1.6 package (which wasn't announced, so we could do final checks first) failed to update our trove classifier, so the package was regenerated, which changed its signature and checksums.
illumen|12 years ago
Was the release uploaded to pypi or a download page? If so, that's released IMHO. eg, debian, various news outlets, and others auto scan download pages for new releases.
EliAndrewC|12 years ago
Personally, I'm happy that Python 3 is now officially supported, though in practice I haven't had an issues with using Django 1.5 with Python 3.
speg|12 years ago
fletchowns|12 years ago
Really nice piece about Malcolm from his former boss: https://plus.google.com/+errazudinishak/posts/6j6iAMhNfnb
Congrats to the Django team on releasing 1.6, I'm looking forward to upgrading soon!
targusman|12 years ago
[deleted]
jtchang|12 years ago
lowkeykiwi|12 years ago
craigkerstiens|12 years ago
d0m|12 years ago
For me it's a perpetual issue to get them up and running, commit/push with git, etc etc. Is there an easier solution? Basically, I'd like them to get started and be able to tweak the templates and css as effortless as possible.
It's kind of very hard to have people working directly in templates/css and others updating html/css and them diff the changes, integrate them, etc..
ispivey|12 years ago
- Use Vagrant and some bootstrap scripts (or Docker) to make giving them a dev environment easy
- Get them to use a git GUI like SourceTree (free & good: http://www.sourcetreeapp.com/)
- Build a workflow around pull requests / review branches a la github/bitbucket/gerrit so you can have them submit changes but an engineer reviews/verifies before it's merged.
In general, empowering them to do this is an investment in the future and well worth it.
phpnode|12 years ago
[0] http://vagrantup.com/
marcosdumay|12 years ago
For Django, all you need is a portable Python installation, and a start script for starting the development server, isn't it?
scardine|12 years ago
maaku|12 years ago
willemmerson|12 years ago
jasonkester|12 years ago
I think I had a one line batch file to start the server, but that's it. Subversion integrates directly into the filesystem with tortoisesvn and even Git has good tools these days.
I can't imagine a designer needing to touch the command line at all.
thejosh|12 years ago
Sourcetree is a little slow for them (they use Macs), but they seem to get the idea.
andybak|12 years ago
Happy to share if you ping me.
earless1|12 years ago
euroclydon|12 years ago
wiremine|12 years ago
acdha|12 years ago
What I'd do is use South now and essentially rebase when you upgrade to 1.7 – ensure that your servers are current with South, remove it and start over with 1.7's built-in migrations.
voorloopnul|12 years ago
njharman|12 years ago
Once your project is deployed then think about sticking with specific version. Development should be on the bleeding edge!
andybak|12 years ago
paganel|12 years ago
magnusgraviti|12 years ago
Form fields will get extended support like input[type="email"]
Django comments are now deprecated.
Congratulations to everyone using Django!
lunchbox|12 years ago
https://docs.djangoproject.com/en/dev/releases/1.6/#improved...
daGrevis|12 years ago
> BooleanField no longer defaults to False
It caused quite a few headaches. Boolean can't have default.
mhurron|12 years ago
I don't see the problem.
andybak|12 years ago
snoonan|12 years ago
This is a great example why framework projects could benefit from being a bit more democratic. Most people seem to be pulling their hair out, telling you something is too complicated to effectively use. The response: It's worth it once you learn. The complexity cost is worth it. Trust us. Read the docs (of course), use this 3rd party site (ok...), read the code. (so I can write a non-trivial view!?). If you are still giving that answer years later, you have to be open to the fact that that your users might be on to something.
Often when you hear someone say they're using CBGV on a large project, you can almost sense the pause for applause.
jsmeaton|12 years ago
tomchristie|12 years ago
sethish|12 years ago
mjhea0|12 years ago
anderspetersson|12 years ago
eliben|12 years ago
ubernostrum|12 years ago
The announcement and release notes both have the information you want:
https://www.djangoproject.com/weblog/2013/nov/06/django-16-r...
https://docs.djangoproject.com/en/1.6/releases/1.6/
pydanny|12 years ago
anan0s|12 years ago
I was thinking basically of transaction management, especially the autocommit behavior.
I browsed through the docs and saw that the default python database API requires autocommit to be turned off... but then again django overrides this behavior.
any comments on this ? (or am I completely lost ?)...
masklinn|12 years ago
> Django’s transaction management was overhauled. Database-level autocommit is now turned on by default. This makes transaction handling more explicit and should improve performance. The existing APIs were deprecated, and new APIs were introduced, as described in the transaction management docs.
> Please review carefully the list of known backwards-incompatibilities to determine if you need to make changes in your code.
> Persistent database connections¶
> Django now supports reusing the same database connection for several requests. This avoids the overhead of re-establishing a connection at the beginning of each request. For backwards compatibility, this feature is disabled by default. See Persistent connections for details.
smaili|12 years ago
paganel|12 years ago
Walkman|12 years ago
unknown|12 years ago
[deleted]
adamlj|12 years ago
Siecje|12 years ago
mukgupta|12 years ago
christopherryan|12 years ago
[deleted]
dmooray|12 years ago
[deleted]