Proposal: Tutorial Refresh
Rob Hudson
complete website, describing everything from start to finish. This
would allow for many more topics to come into play -- things we all
deal with at some point in developing websites using Django. This
would also allow for those topics to have a concrete central model and
not be hypothetical situations. The end result should be source code
someone can checkout of a source control repository and run
themselves. It would also be nice if the site being developed in the
tutorial were available and useful to the community as a whole.
To that end I'm also proposing that the site be http://www.djangosnippets.org/,
as long as James Bennett is ok with it. The source code is already
available and under a BSD license. The site is already well used and
important to the community. The model is relatively simple (snippets)
with the possibility of a few 3rd party apps for things like ranking
of snippets, tagging, registration, Pygments, etc. Django snippets
would also benefit from this process by getting an update to Django
1.0 (or newer).
I think an outline of the tutorial steps and what should be covered is
important to solidify at the outset. That way if someone has a
particular interest in, say, caching, they could jump right in and
start fleshing out that step. There are some dependencies on early
steps, of course.
Here's a very rough proposed outline that should be fleshed out more
and more detail added to each step on what topic areas to cover. Much
of the current tutorial could be "ported" to the appropriate steps...
1. Creating a project - install, runserver, settings
2. Creating an app - app philosophy, INSTALLED_APPS
3. Creating models
4. Enabling the admin
5. Writing urls and views - generic views, custom views
6. Templates
7. Forms
8. Tests
9. 3rd party apps
10. Search
11. Feeds
12. Caching
13. APIs
14. i18n and l10n
15. Deployment
What I'd like to know is:
* How do people feel about a tutorial that covers a complete site?
* How do people feel about that site being Django snippets?
* Comments on the proposed outline? Are there any important steps
missing? Ordered logically? Feel free to add detail to any step.
* Do we cover things not in Django -- like model migrations, search,
RESTful APIs -- using 3rd party Django apps?
* Would it be possible to do this openly, with easy user comments,
like the Django book? Is that software available?
Also, if we're going to pull this off we're going to need people to
help in a variety of ways. So I'm also curious who might be
interested. We'll need: authors to write some sections, reviewers to
give feedback, editors to clean up text and bring uniformity to the
whole thing, developers to make sure the software the tutorial is
describing is coded using best practices and works, a handful of
people to drive the process and foster community involvement, etc.
Feedback welcome,
Rob
Jacob Kaplan-Moss
First, thanks for taking this on. The tutorial indeed needs some good
lovin'; glad to see someone stepping up to the plate. I don't have a
huge amount of bandwidth these days, but I can commit to writing a
bit, and to editing anything you or anyone else writes.
On Fri, Oct 9, 2009 at 9:41 AM, Rob Hudson <r...@cogit8.org> wrote:
> * How do people feel about a tutorial that covers a complete site?
Like you, I think it's the best way to teach Django. A complete site
can show off more parts than just a small example project can.
> * How do people feel about that site being Django snippets?
Mmmm... that I'm not so sure about. Partly because this steps on
already trodden ground -- James' book (Practical Django Projects) goes
through djangosnippets as part of the book -- but also because it's a
somewhat insular example. That is, pastebins (of which djangosnippets
is a particular complex instance of) are the type of tool that really
only highly geeky folks use. Django's got a wider audience -- I know
Django users who are primarily journalists, designers, biologists, ...
-- and ideally the example we use should have relevance to a broad
cross-section of Django's audience.
Of course, all that said, I don't have a better suggestion other than
the tired personal blog example. So once again this is "if you build
the bikeshed you get to paint it" territory.
> * Comments on the proposed outline? Are there any important steps
> missing? Ordered logically? Feel free to add detail to any step.
Couple of things:
* This new tutorial absolutely should cover pip+virtualenv, most
likely right off the bat.
* We should de-emphasize the "apps live inside of projects" thing.
virtualenv gets the same effect we were shooting for there with much
less mess.
* Testing ought to be covered from the start -- I'd like to see every
little bit cover how to test it.
> * Do we cover things not in Django -- like model migrations, search,
> RESTful APIs -- using 3rd party Django apps?
I think the best idea would be cover how to find, install, and use
third-party apps, and then link to some popular ones. But leave the
actual how-tos to those authors.
> * Would it be possible to do this openly, with easy user comments,
> like the Django book? Is that software available?
Heh. Sorta. The JS is okay and if you view source you should be able
to figure out how to find it; the backend code is a terrible one-off,
though.
However, I'm not totally sure that comments make a whole lot of sense
for documentation. We had comments on the docs for a while, back in
the day, and they just confused people. The comments were mostly the
type of questions people *should* be asking on django-users or in IRC.
Since nobody who could help them was reading the comments, they didn't
help at all. The other major open source projects with comments (PHP,
PostgreSQL) also seem to show similar trends. PHP's doc comments, in
particular, are a morass of bad advice.
The ideal, I think, would be a contextual *editing* tool: something
like the comment system, but allowing people to suggest changes that
editors could easily apply. That way people could fix typos, suggest
better wording, etc., but also not confuse the situation with bad
comments.
> Also, if we're going to pull this off we're going to need people to
> help in a variety of ways. So I'm also curious who might be
> interested. We'll need: authors to write some sections, reviewers to
> give feedback, editors to clean up text and bring uniformity to the
> whole thing, developers to make sure the software the tutorial is
> describing is coded using best practices and works, a handful of
> people to drive the process and foster community involvement, etc.
Well, in grand Django tradition, by suggesting this, you've
volunteered to be in charge :)
But sign me up as an editor (language and code), at least, and I'll
try to help out by writing some sections, too.
Jacob
Russell Keith-Magee
>
> On Fri, Oct 9, 2009 at 9:41 AM, Rob Hudson <r...@cogit8.org> wrote:
>> * How do people feel about a tutorial that covers a complete site?
>
> volunteered to be in charge :)
>
> But sign me up as an editor (language and code), at least, and I'll
> try to help out by writing some sections, too.
Hi Rob,
I started to write a reply too, and then realized I was just writing
"hell yeah" after each of Jacob's paragraphs. So I decided to stop.
:-)
Put me down as willing to assist with reviewing and/editing, or just
general sanity checking.
The only point I though I would elaborate on is the specific example
for the tutorial. I agree with Jacob's comment that a pastebin is a
bit of an esoteric example. There's also value in diversity - every
extra example is one more sample site people can use as a point of
reference. Having 2 pastebin examples floating around the community
doesn't help much, but having a pastebin and something else adds some
value.
My immediate reaction was that a blog engine is the natural example.
It allows you to expose date-based generic views. You can use
contrib.comments. You could show integration with any number of 3rd
party apps. You could even demonstrate the transition to Pinax. The
problem space is well known and well understood. Plus,
write-your-own-blog-engine is a running joke in the Django community.
:-)
That said, Jacob's bikeshed comment is also completely accurate. You
build it, you get to choose. There's also something to be said for
having a tutorial that doesn't duplicate the capabilities of any
number of existing pluggable applications.
Russ %-)
Jani Tiainen
> On Fri, Oct 9, 2009 at 11:22 PM, Jacob Kaplan-Moss <ja...@jacobian.org> wrote:
>> On Fri, Oct 9, 2009 at 9:41 AM, Rob Hudson <r...@cogit8.org> wrote:
>>> * How do people feel about a tutorial that covers a complete site?
>> Well, in grand Django tradition, by suggesting this, you've
>> volunteered to be in charge :)
>>
>> But sign me up as an editor (language and code), at least, and I'll
>> try to help out by writing some sections, too.
>
> Hi Rob,
>
> I started to write a reply too, and then realized I was just writing
> "hell yeah" after each of Jacob's paragraphs. So I decided to stop.
> :-)
>
> for the tutorial. I agree with Jacob's comment that a pastebin is a
> bit of an esoteric example. There's also value in diversity - every
> extra example is one more sample site people can use as a point of
> reference. Having 2 pastebin examples floating around the community
> doesn't help much, but having a pastebin and something else adds some
> value.
>
> My immediate reaction was that a blog engine is the natural example.
> It allows you to expose date-based generic views. You can use
> contrib.comments. You could show integration with any number of 3rd
> party apps. You could even demonstrate the transition to Pinax. The
> problem space is well known and well understood. Plus,
> write-your-own-blog-engine is a running joke in the Django community.
> :-)
Time of my learning I wondered this part - why always blogs. I don't
want to write blog engine... :)
> That said, Jacob's bikeshed comment is also completely accurate. You
> build it, you get to choose. There's also something to be said for
> having a tutorial that doesn't duplicate the capabilities of any
> number of existing pluggable applications.
I can also lend my small hand. I've recently (last spring) gone through
learning curve how to use (Geo)Django and how to get at least decent
(IMO) system up and running.
I live in world of GIS. My projects are not traditional web apps, like
blogs, pastebins. Personally I found a bit hard to find information that
goes much beyond standard blog engine or simple forum. Also few
surprises came along the path to where I am now.
And of course got some "why this wasn't mentioned in tutorial" moments.
--
Jani Tiainen
Eric Florenzano
( http://github.com/ericflo/startthedark )
I can attest, from the amount of feedback that I've received about
that series of screencasts, that building an entire website from the
ground up is extremely valuable to beginners. It's also a fairly
massive amount of work. There's a lot that's changed in the Django
ecosystem since those screencasts, so I'm excited about the prospect
of a fresh new tutorial.
Some lessons I learned along the way:
* Develop the entire site first, and then deconstruct it into the
pieces
My first attempt I didn't do this, and I ended up having to scrap it
and start over after having built the whole site. This will save you
so many headaches later down the line.
* Actually launch the site somewhere
Last week or so I forgot to renew the startthedark.com domain, and (to
my surprise) I've gotten several e-mails from people about it. People
apparently really do go to the site itself to see it in action before
watching the screencasts.
* Have the bits and pieces of code in-line with the tutorial, but also
provide a full checkout of the entire site
A lot of what people need to know can be contained in the tutorials,
but what some people need is to actually see the full picture--
everything and how it all fits together, down to the minute details.
This may be less of a problem now with Pinax on the scene, but that
was one major piece of feedback that I had was that people liked being
able to download the whole source tree.
Hrm, I feel like I have more battle scars, but right now I can't think
of anything else. I'll be around so feel free to ask me any questions
or whatever.
Thanks,
Eric Florenzano
Simon Willison
that covers pip, virtualenv, unit testing and the like.
I have a suggestion for a site, too: How about the conference website
for the next DjangoCon? It's meant to be a community run conference so
the job needs to be done at some point, and building it as a community
tutorial project feels like it would be a nice fit.
A conference site is neat because it's a good example of a content
oriented site that isn't a blog, but can still take advantage of
generic views (and the admin, of course). It can be as simple or as
complicated as needed for the tutorial. We can even include API driven
features (recent tweets / photos from Flickr etc) which would be a
good way of demonstrating advanced concepts like caching.
Cheers,
Simon
Sean Brant
http://hello.carsonified.com/ would be cool to have, though it might
be to advance for this kind of tutorial.
Sean
Bryan Veloso
adding features like the ones on the Carsonified site for brevity's
sake. Definitely +1 to the prospect of seeing examples of unit testing
and caching. On a tangent, if there's any design work needed for said
site, I'll be happy to throw my hat in.
On Oct 9, 1:49 pm, Sean Brant <brant.s...@gmail.com> wrote:
> +1 Simon's idea of a conference site. Adding some features likehttp://hello.carsonified.com/would be cool to have, though it might
Rob Hudson
sounds useful for upcoming conferences. I wasn't too crazy about the
blog idea, and was convinced away from the snippets idea. So shall we
call it a conference site and move on? :)
For a nice reference implementation, I'd like to point to the software
running the Open Source Bridge website. It's developed in Ruby on
Rails and is hosted on Github:
http://github.com/igal/openconferenceware
I attended the Open Source Bridge conference and thought the website
was one of the most well done of any conference I've been to -- from
initial call for talks to attending and checking the schedule.
The website is here:
http://opensourcebridge.org/
If the intention is that this will be used for the DjangoCons, we
would need input from those that run DjangoCon. For example, I really
liked the open submission process and the fact that the conference
took everyone's comments (which were private) into consideration when
picking the subset of talks. But I can imagine that's not for
everyone.
Thanks,
Rob
Russell Keith-Magee
>
> I, too, like the idea of a conference site. It fills a void and
> sounds useful for upcoming conferences. I wasn't too crazy about the
> blog idea, and was convinced away from the snippets idea. So shall we
> call it a conference site and move on? :)
A conference site it is then.
One piece of guidance, especially if you're aiming for the final site
to be used for DjangoCon. Keep in mind that a tutorial needs to be
simple at the start. However, a real site for a conference will be a
lot more complex. There is a delicate balance that will need to be
made between "useful tutorial example" and "useful real site".
Of course, you could also use this to your advantage - showing how a
simple site evolves into a complex one, and using the opportunity to
demonstrate how you evolve models etc.
> If the intention is that this will be used for the DjangoCons, we
> would need input from those that run DjangoCon. For example, I really
> liked the open submission process and the fact that the conference
> took everyone's comments (which were private) into consideration when
> picking the subset of talks. But I can imagine that's not for
> everyone.
For reference, in case you didn't already know: the three key people here are:
* Rob Lofthouse (Conference Organizer DjangoCon 2010)
* James Tauber (Conference Chair, DjangoCon 2010)
* Jannis Leidel (Conference Organizer, EuroDjangoCon 2010).
Yours,
Russ Magee %-)
Kenneth Gonsalves
> On Sat, Oct 10, 2009 at 6:55 AM, Rob Hudson <r...@cogit8.org> wrote:
> > I, too, like the idea of a conference site. It fills a void and
> > sounds useful for upcoming conferences. I wasn't too crazy about the
> > blog idea, and was convinced away from the snippets idea. So shall we
> > call it a conference site and move on? :)
>
> A conference site it is then.
cool (I just lurk here) but we have a conference site at in.pycon.org/2009/ -
maybe you could get some ideas there (or give some ideas).
--
regards
kg
http://lawgon.livejournal.com
Ned Batchelder
On Sat, Oct 10, 2009 at 6:55 AM, Rob Hudson <r...@cogit8.org> wrote:I, too, like the idea of a conference site. It fills a void and sounds useful for upcoming conferences. I wasn't too crazy about the blog idea, and was convinced away from the snippets idea. So shall we call it a conference site and move on? :)A conference site it is then. One piece of guidance, especially if you're aiming for the final site to be used for DjangoCon. Keep in mind that a tutorial needs to be simple at the start. However, a real site for a conference will be a lot more complex. There is a delicate balance that will need to be made between "useful tutorial example" and "useful real site".
The tutorial is extremely important. It will be the first part of the docs read by 98% of new users. Don't complicate it by tying it to DjangoCon. This thread has already seen requests for features that will be great for real use, but would probably be too much to put into a tutorial. While it would be very cool to have the two sites be just one site, I think it will either create an overgrown underexplained tutorial as DjangoCon adds features needed for a real-world conference site, or a simplistic toy DjangoCon site because the tutorial needs to ensure that everything is clean, understandable, and accompanied by clear prose.
Why not serve just one master well, and have the tutorial be purely about exposition and pedagogy?
Am I being too pessimistic?
--Ned.
Stephen Wolff
> The tutorial is extremely important. It will be the first part of the
> docs read by 98% of new users. Don't complicate it by tying it to
> DjangoCon. This thread has already seen requests for features that
> will be great for real use, but would probably be too much to put into
> a tutorial. While it would be very cool to have the two sites be just
> one site, I think it will either create an overgrown underexplained
> tutorial as DjangoCon adds features needed for a real-world conference
> site, or a simplistic toy DjangoCon site because the tutorial needs to
> ensure that everything is clean, understandable, and accompanied by
> clear prose.
>
> Why not serve just one master well, and have the tutorial be purely
> about exposition and pedagogy?
>
> Am I being too pessimistic?
>
> --Ned.
>
is actually used for the actual DjangoCon or not, I like the idea of it
being a conference site.
I wonder if mechanize (http://wwwsearch.sourceforge.net/mechanize/) can
be included in the testing side of the tutorial. I noticed the module on
Jacob's top ten, and hadn't come across it before. It sounds useful
compared with (or in addition to) asserting that a particular
HttpResponse code is returned.
Stephen
Rob Hudson
> My strong feeling is that these two goals will quickly become impossible to
> reconcile. I think the idea of a conference site is a good one (everyone
> will understand the problem domain, lots of interesting avenues to explore,
> it's not yet-another-blog), but aiming for it to be the actual site used for
> DjangoCon will not work in the long run.
>
> The tutorial is extremely important. It will be the first part of the docs
> read by 98% of new users. Don't complicate it by tying it to DjangoCon.
> This thread has already seen requests for features that will be great for
> real use, but would probably be too much to put into a tutorial. While it
> would be very cool to have the two sites be just one site, I think it will
> either create an overgrown underexplained tutorial as DjangoCon adds
> features needed for a real-world conference site, or a simplistic toy
> DjangoCon site because the tutorial needs to ensure that everything is
> clean, understandable, and accompanied by clear prose.
>
> Why not serve just one master well, and have the tutorial be purely about
> exposition and pedagogy?
After more thought I agree with Ned. Not only will the goals be hard
to reconcile, I think we're encroaching the turf of the DjangoCon
conference organizers. I also think the data model will be
sufficiently complex and lead to a lot of hand waving in the tutorial.
Ideally, I think a good candidate for a website/tutorial will have the
following components:
* The goal and domain should be simple to grasp and explain in a few sentences.
* Have one main app that is the central focus on the website
* Have one main model, with several peripheral models that could be
introduced as the tutorial progresses.
* Be complex enough to require many areas of Django (e.g. Forms,
Aggregates, Caching, etc)
I'll have to ponder further on what fulfills these requirements.
One thought I had was to use the existing poll tutorial, but expand it
to be a site on its own. Something along the lines of
http://strawpollnow.com/ but not necessarily with the Twitter
integration?
Thanks,
Rob
David Chandek-Stark
the opposite -- that apps should *not* live inside of projects. I get
that one of the purposes of the tutorial is to get you up and running
fast, but when someone's trying to get a quick start and not really
paying attention to comments like "we'll show how to de-couple later",
they may just follow the pattern given and unconsciously assume that
it's the usual way to do things. IMO startproject and startapp are
misleading because 1) they sound necessary, but they're not; 2) they
don't really do much for you; and 3) folks are led to use manage.py
instead of django-admin, which causes confusion down the road. I'm
not an expert in pedagogy, but it seems preferable to me to
demonstrate best practices up front.
Thanks,
David
Simon Willison
> My strong feeling is that these two goals will quickly become impossible
> to reconcile. I think the idea of a conference site is a good one
> (everyone will understand the problem domain, lots of interesting
> avenues to explore, it's not yet-another-blog), but aiming for it to be
> the actual site used for DjangoCon will not work in the long run.
tutorial to be the exact site used for DjangoCon will lead to both
goals being fulfilled poorly, but I still think they can be addressed
at the same time. Build out a basic conference site for the tutorial,
then use that as the basis for the full DjangoCon site (which can fork
off from the tutorial to add more features). I'd love to see the final
DjangoCon site being open source and demonstrating Django best
practices.
That said, until we hear from the DjangoCon organisers we won't know
if this is a good idea from their point of view.
Cheers,
Simon
andybak
'building for re-usability' ideas that have devloped via Pinax et al.
Maybe at least one part of the functionality developed in the tutorial
should be in the form an app intended to be used across projects.
Combine this with incorporating existing 3rd party apps in the project
and we've captured a very powerful lesson about Django.
(edit - this is already hinted at in some of the other comments but
I'll still post this for the extra emphasis)
Alex Gaynor
tutorial would be a pointless waste of energy. It has served us
exceptionally well over the past 4 years, and none of the problems
with it are fundamental, we'd be far better served by working to
improve it, by adding more stages, than by rewriting it. Further, I'd
ague that the "staleness" of the tutorial is irrelevant, because the
primary audience for the tutorial are precisely people who haven't
seen it before.
Alex
--
"I disapprove of what you say, but I will defend to the death your
right to say it." -- Voltaire
"The people's good is the highest law." -- Cicero
"Code can always be simpler than you think, but never as simple as you
want" -- Me
Zachary Voase
> I don't want to be overly negative, but in my view rewriting the
> tutorial would be a pointless waste of energy. It has served us
> exceptionally well over the past 4 years, and none of the problems
> with it are fundamental, we'd be far better served by working to
> improve it, by adding more stages, than by rewriting it. Further, I'd
> ague that the "staleness" of the tutorial is irrelevant, because the
> primary audience for the tutorial are precisely people who haven't
> seen it before.
>
> Alex
I think I have to agree with Alex here. I’ve taught Django to a couple
of people in the past, and I found that the tutorial (as it is) worked
perfectly as an introduction to the concepts behind Django. After the
tutorial, the Django Book[1] is the next natural step, and it provides
a very solid grounding in pretty much everything, from development to
deployment. To round it all off, Eric Florenzano’s ‘Django from the
Ground Up’ showed them how to put what they had learned into practice.
If there’s one thing *at all* that we should do, it’s add a chapter on
testing to the Django Book, and perhaps another section in the
tutorial devoted to it. But a comprehensive rewrite of the tutorial
seems completely unnecessary.
--
Zack
Rajeev J Sebastian
+1
I've trained 8 apprentices over the past 1-1/2 years. The existing
django tutorial is invaluable since it can be done in about a day.
Regards
Rajeev J Sebastian
Joshua Russo
Zachary Voase
> How about the possibility of an advanced tutorial, to highlight more
> advanced features.
That's pretty much what the Django Book is for.
--
Zack
Wolf.Halton
I volunteer to test the tutorial.
Wolf
On Oct 9, 10:41 am, Rob Hudson <r...@cogit8.org> wrote:
> I'd like to propose the addition of a new tutorial that represents a
> complete website, describing everything from start to finish. This
> would allow for many more topics to come into play -- things we all
> deal with at some point in developing websites using Django. This
> would also allow for those topics to have a concrete central model and
> not be hypothetical situations. The end result should be source code
> someone can checkout of a source control repository and run
> themselves. It would also be nice if the site being developed in the
> tutorial were available and useful to the community as a whole.
> Feedback welcome,
> Rob
Russell Keith-Magee
No, it really isn't.
Firstly, The Django Book is an excellent resource, but it's not part
of the Django project itself. Django's documentation is Django's
documentation. Jacob and Adrian (and others) have written an excellent
book, and I have no objections to people suggesting that newcomers
should read that book, but it isn't part of Django's documentation.
Secondly, the Django Book isn't a tutorial. It's an excellent set of
explanatory notes of some advanced features, but it isn't a
walkthrough of a specific worked example.
I aspire to Django having the best documentation of any product out
there - open source or otherwise. Having a comprehensive tutorial is
part of that. Django's tutorial has said "more coming soon" for over 4
years, and there is a lot that could (nay, should) be explained in a
tutorial that we simply don't cover at the moment.
As for whether a complete rewrite is necessary - I'm happy to call
that a bikeshed. The current tutorial has served us well for four
years, but it is a simple example. If that simple example doesn't
provide enough scope for improvement, and Rob et al can come up with a
good replacement - one that starts equally simple, but can become
complex over time - I'm happy to entertain that proposal.
Rest assured, we're not going to replace a good tutorial with a bad
one. The tutorial won't be replaced until it is a worthy replacement
for what we already have.
Yours,
Russ Magee %-)
Joshua Russo
Wolf Halton
Contrary-wise, or maybe in addition, I would like to see a tutorial that showed a whole site from end to end, as I am nowhere near being able to see everything that Django can do.
-Wolf
This Apt Has Super Cow Powers - http://arrowstars.com
gareth rushgrove
> would like it better if it were expanded somewhat, with more troubleshooting
> paragraphs in it. It already has a few of these, but it would cut down on
> my struggles if it had a few more. Maybe a complete (this really works,
> right out of the box) copy of the finished tutorial, so the student could
> compare the two.
>
> Contrary-wise, or maybe in addition, I would like to see a tutorial that
> showed a whole site from end to end, as I am nowhere near being able to see
> everything that Django can do.
tutorial (like the existing one) and a larger one focused on bigger
projects.
I'm currently helping teach a small development team Django (formerly
PHP people), at the same time building production software with them.
The poll tutorial helped a few of them with basic syntax but on some
of the bigger things like project organisation, caching, testing, etc.
having a canonical example I could point them at would be extremely
useful.
With all that in mind I'd be happy to help out on the new tutorial. In
particular I've lots of stuff kicking around when it comes to testing
[1], deployment and general automation [2] including pip and
virtualenv.
Let me know what I can do.
Ta
Gareth
[1] http://github.com/garethr/django-test-extensions
[2] http://github.com/garethr/django-project-templates
Gareth Rushgrove
Web Geek
Member WaSP Education Task Force
morethanseven.net
garethrushgrove.com
Jeff Anderson
> I'm currently helping teach a small development team Django (formerly
> PHP people), at the same time building production software with them.
> The poll tutorial helped a few of them with basic syntax but on some
> of the bigger things like project organisation, caching, testing, etc.
> having a canonical example I could point them at would be extremely
> useful.
Hello,
When I started learning Django, I used production code as a model far more
often than the tutorial. The problem I ran into was that I wasn't following
best practices by following the code that I had, and I didn't know *why* some
decisions as to how things worked were made. The very code that I learned with
ended up being scrutinized and updated by me a year or so later.
An official "real-life", advanced tutorial would have been wonderful to fill
the gap that I had. It would have saved me quite a bit of *re-learning* things,
which is always annoying.
Thanks!
Jeff Anderson
Dougal Matthews
An official "real-life", advanced tutorial would have been wonderful to fill
the gap that I had. It would have saved me quite a bit of *re-learning* things,
which is always annoying.
If you can outline some of the gaps you had and examples it might be useful for somebody when tackling the content for this. A more advanced topic is fine but as long as it covers the topics people learning consider to be advanced or initially more difficult.
Dougal