#2,941 in Computers & technology books
Use arrows to jump to the previous/next product

Reddit mentions of Practical Django Projects (Expert's Voice in Web Development)

Sentiment score: 1
Reddit mentions: 1

We found 1 Reddit mentions of Practical Django Projects (Expert's Voice in Web Development). Here are the top ones.

Practical Django Projects (Expert's Voice in Web Development)
Buying options
View on Amazon.com
or
    Features:
  • Used Book in Good Condition
Specs:
Height9.25 Inches
Length7.01 Inches
Number of items1
Weight1.14199451716 Pounds
Width0.62 Inches

idea-bulb Interested in what Redditors like? Check out our Shuffle feature

Shuffle: random products popular on Reddit

Found 1 comment on Practical Django Projects (Expert's Voice in Web Development):

u/AntiMS ยท 5 pointsr/django

James Bennett, Django release manager and author of Practical Django
Projects
, in a lecture he gave at PyCon 2009 suggested five criteria for writing Django apps:

Do one thing and do it well. This is known as one of the main points of the Unix Philosophy. Basically, it means that every Django app should have exactly one function or feature, and this function should be narrowly defined. For instance, instead of a blogging app, you'll want (depending on your feature requirements) one app for the WYSIWYG interface, one for writing and viewing blog entries, one for handling the archives interface, one for the tag cloud, one for user comments, and one for the captcha.

Don't be afraid of multiple apps. It's a good thing to have lots and lots of apps in your project. In general, I'd recommend erring on the side of too many apps rather than too few.

Write for flexibility. Write your apps so that they can be used without being forked. If you're writing an app to allow users to make comments on an object, it shouldn't be necessary for you to modify your app in order to allow the users to have avatars. This may mean you'll have to go to a bit of extra "trouble" to make such additions possible, but that "trouble" will pay off in the end.

Build to distribute. If you write your app as if other developers are going to use it, you get several benefits including a cleaner API, better documentation, and generally higher quality code.

Extend carefully. If you think of a new feature, think hard before you add it to an existing app. First ask yourself if the new feature fits within the defined purpose of the existing app. If it doesn't, then the new feature almost definitely belongs in a new app. For instance, if you write an app for users to leave comments and it later becomes apparent that you might need to have a captcha when users leave comments, first ask yourself if a captcha is strictly part of the definition of your comment app. In this case, the answer is a pretty resounding "no". So, write (or obtain) an app for captchas and "plug it in" to your app. (Pro tip: if your app isn't flexible enough to allow the addition of a new feature by adding a new app, then that's an indication that you're not fully following the third directive. In such a case, you should "retrofit" your existing app with additional flexibility which allows you to accomplish your goals, but you should not add any code to your old app which is specific to your new function. So, in the case of the commenting/captcha example, you could change your comment app so that the django.forms.Form subclass users use to make a comment could be overridden by another app, write a captcha app which defiens a django.forms.fields.Field subclass CaptchaField, and write a glue app which defines a new django.forms.Form subclass with the necessary field for writing a comment as well as a CaptchaField. Magic.)

James Bennett has another talk on the subject (perhaps another version of the same talk. I'm not sure.) on YouTube. It might be worth it to give it a watch: http://www.youtube.com/watch?v=A-S0tqpPga4

Good luck, and happy hacking.

Edit: Formatting.