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..
- 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.
For Django, all you need is a portable Python installation, and a start script for starting the development server, isn't it?
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.
Sourcetree is a little slow for them (they use Macs), but they seem to get the idea.
Happy to share if you ping me.
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.
And that is not a happy place to end up when you're just starting out with them, since in there you're seeing the whole inheritance/mixin layout structure, which is what leads to the belief that it's too complicated to use.
Which... no, class-based generics are pretty darned easy. Here are the views for my blog app, for example:
https://github.com/ubernostrum/blog/blob/master/blog/views.p...
It'd be nice to cut down the use of super(), but that's about the only issue I have with it. All of the simpler-CBV implementations I've seen make a few too many assumptions for my personal taste, or otherwise cut down on flexibility in favor of simplifying the inheritance diagram, which I don't agree with as a goal in itself.
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.
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?
Nit-pick: suspect you are actually a fan of statically-typed languages. Python is a strongly-typed language, but not statically-typed.
(general easy way to tell them apart: in a statically-typed language, both the name and the value bound to it have a type, and those types must match; in a dynamically-typed language only the value has a type; in a weakly-typed language, operations on incompatible types are permitted, and they may be coerced for compatibility; in a strongly-typed language, operations on incompatible types are an error -- usually at compile-time or equivalent for statically-typed, usually run-time for dynamically-typed)
I definitely use Python professionally (and some Django, but that's not the critical stuff.) It's not the only thing I do, but it's another arrow in my quiver. It's really useful for generating applications that need to do a lot of stuff, but benefit from brevity in code. Django is actually more responsible for me learning Python and how to use it responsibly in a production environment. I knew how to write services in C# and Java that wouldn't be an administrative nightmare or cause pagers to go off at odd hours, so I needed to learn that with Python (turns out, it's not hard.)
As always, your mileage may vary. Nonetheless, lean toward finding a use for it in your operation, if only for experience. It's super practical, and to minimize transitional familiarity, go with IronPython. Works with all the VS IDEs.
Django admin site is still my favourite feature.
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.
From personal experience, most of the critical ones are compatible.
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.
Once your project is deployed then think about sticking with specific version. Development should be on the bleeding edge!
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.
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.
And if we catch a minor packaging error at this point, it's easy enough to fix on the spot without having to do an entire new release.
Except in this case somebody got really eager, saw the release process starting, and posted a link to our downloads page (and I'm not entirely certain if it would have been possible to get the incorrect package from it), rather than waiting for and linking to the release announcement once we'd vetted and made everything public.
> BooleanField no longer defaults to False
It caused quite a few headaches. Boolean can't have default.
I don't see the problem.
Think about this code:
class Missile(models.Model):
# we can only attack short countries
target = models.CharField(max_length=7)
should_launch = models.BooleanField()
def launch(self):
"""
pass launches the missile
"""
pass
Then you have a view:
/missile/launch_missiles
for missile in Missile.objects.filter(should_launch=True):
missile.launch()
missile.should_launch is True
The announcement and release notes both have the information you want:
https://www.djangoproject.com/weblog/2013/nov/06/django-16-r...
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.
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!
Form fields will get extended support like input[type="email"]
Django comments are now deprecated.
Congratulations to everyone using Django!
https://docs.djangoproject.com/en/dev/releases/1.6/#improved...