feldroy / two-scoops-of-django-3.x Goto Github PK

Location within the Book

• Chapter or Appendix: 6
• Section: 4
• Subsection: 5

Description

This table is misplaced in between the warning for "Don't serve files from BinaryField".

Possible Solutions

It should move up to 6.4.4

======

ManyToManyField
As to the content: Its kinda contradictory to say do it and don't do it in the same line. This needs an explanation. :)
Furthermore this table IMHO is only meaningful when the dont's are explained in a form of "Don't do that otherwise this will happen ..".

Reading up on the Django docs "null has no effect since there is no way to require a relationship at the database level." brings even more mystery to why you are telling the user to set or not set null=something?
Whats the issue here? I never had any.

Also this table might be a good reference to find out why only some others are broken.

Location within the Book

• Chapter or Appendix: 21
• Section: 3
• Subsection: 1

Description

Implementing str() is straigt forward:

Possible Solutions

fix typo straigt forward -> straightforward

The changelog references a few changes that seems to not be in the book. As the changelog is dated May 10 and the book May 11 I would assume that the changes should be in the book.

Do you want these inconsistencies as issues or is the dating of book and changelog just a bit off?

The book says

There are a number of problems with Django’s default project layout. While useful for the
tutorial, it’s not quite as useful once you are trying to put together a real project. The rest of
this chapter will explain why.

While I agree with you. The book didn't discuss in the rest of the chapter what are these problems as promised.

Also I personally didn't understand the benefit of separating the config from project root.

I've only found this explanation

When anyone visits this project, they are provided with a high-level view of the project.
We’ve found that this allows us to work easily with other developers and even non-
developers. For example, it’s not uncommon for designer-focused directories to be created
in the root directory.

but doesn't that mean that templates and static directory also be outside project root since it's designer-focused? or what would designer focused files be?

class CustomQuerySet(models.QuerySet):
    def sample(self):
        return self.filter(sample=True)


class SampleModel(models.Model):
    objects = CustomQuerySet.as_manager()

Original: twoscoops/two-scoops-of-django-1.11#1

People want this instead of copy/pasting the code.

The tabu LaTeX package we used in the past is no longer working and no longer maintained. We need a new way to present our tables in an attractive fashion.

If you are an expert at LaTeX, we're interested in talking to you. We will pay for expert LaTeX help.

Location within the Book

• Chapter or Appendix: 5
• Section: 2
• Subsection: Table 5.2

Description

The table doesn't have a top line (above the word "Environment"). This is inconsistent compared to Table 5.1.

Possible Solutions

Greetings!

Location within the Book

• Chapter or Appendix: 3
• Section: 5
• Subsection: 2

Description

I'm reading the book using Preview.app on Catalina, if that matters. The second line in Example 3.10 starts with "You've downloaded" and the apostrophe is highlighted by a white box with a red outline. This highlight makes no sense in this example.

Possible Solutions

Escape the apostrophe?

Location within the Book

• Chapter or Appendix: 17
• Section: 17.6
• Subsection: 17.6.2 REST Frameworks Must Come With Rate Limiting

Description

Article stress on importance of throttling your API but doesn't show how to do it.

Possible Solutions

The bare minimum is giving link to django rest framework documentation on this regard

https://www.django-rest-framework.org/api-guide/throttling/#setting-the-throttling-policy

Greetings!

Hello! As a reader, you're encouraged to submit bug reports to us for errors that you find. In turn we will give you credit for your contributions in not just the e-book but also in the print paperback. This is your opportunity to have your name in one of our books as a contributor, which you are then welcome to add to your resume and LinkedIn profile.

Notes:

• TODOs are markers to let you know we are going to expand an area, so reporting them during the ALPHA and BETA period doesn't qualify as an attributable item.
• ??:?? are references for areas written but still being examined by our reviewers and not yet in the published version of the book. Reporting them doesn't qualify as an attributable item.

Location within the Book

• Chapter or Appendix: 6
• Section: 1
• Subsection: 2

Hint: Page numbers change all the time. The best way to report an issue is by chapter, section, and subsection numbers.

Description

The name of Table 6.1 overlaps with the page footer.

Possible Solutions

The warning box higher up the same section seems to have more whitespace around it than most boxes, so removing some of this would shift the table up the page, and avoid it overlapping with the footer.

The link in 28.26 to ponycheckup.com exists but is just a line to say that the site has been shut down,

Location within the Book

In section 24.3.5 (Don’t Rely on Fixtures), in the 'PACKAGE TIP' box.

Description

The 'model mommy' project has been renamed to 'model bakery'. You might want to use the new name, or at least mention the change in some way.

Location within the Book

• Chapter or Appendix: 0 Introduction
• Section: Conventions used in this book
• Subsection:

Description

Sample table is missing or if you didn't want to put an example table, the sentence should be closed by a period (.) instead of a colon (:)

Possible Solutions

Greetings!

Hello! As a reader, you're encouraged to submit bug reports to us for errors that you find. In turn we will give you credit for your contributions in not just the e-book but also in the print paperback. This is your opportunity to have your name in one of our books as a contributor, which you are then welcome to add to your resume and LinkedIn profile. (Note: TODOs are markers to let you know we are going to expand an area, so reporting them during the ALPHA and BETA period doesn't qualify as an attributable item.)

Location within the Book

• Chapter or Appendix: 0 (Introduction)
• Section: xxvii Conventions used in this book

Description

You say there are two typographical conventions for code:
a) "Constant width" which is properly shown with constant width font used in the book
b) "Shaded constant width" which is shown the same way as a).
I think you mean that second typographical convention is:

which is NOT constant width and should be printed shaded and with that font to work as an example

Possible Solutions

rewrite "shaded constant width" -> shaded && apply that style there

Maybe I got it wrong and that shaded blocks are not for code, but then it should be listed as whatever it is. (variables or function names?)

Location within the Book

• Chapter or Appendix: 17
• Section: 2
• Subsection: N/A - Inside TIP-box

Description

Rendered link ("http://cdrf.co") is correct, but when clicked the schema ("http://") is missing, giving errors in at least some PDF viewers when clicked.

Possible Solutions

Should probably be the other way around, as most other rendered links in the book don't have schemas, but the target does.

Django approach

class Flavors(models.TextChoices):
    CHOCOLATE = 'ch', 'Chocolate'
    VANILLA = 'vn', 'Vanilla'
    STRAWBERRY = 'st', 'Strawberry'
    CHUNKY_MUNKY = 'cm', 'Chunky Munky'
    flavor = models.CharField(max_length=2, choices=Flavors.choices)

django_model_helpers approach

from model_helpers import Choices

# Suggested be placed separately in constants.py file to reduce chances of circular imports
FLAVORS = Choices({
    "chocolate": "ch",
    "vanilla": "vn",
    "strawberry": "st",
    "chunky": {"id": "cm", "display": "Chunky Munky"},
}, order_by="id")

class IceCreamOrder(models.Model):
    flavor = models.CharField(max_length=2, choices=FLAVORS())

Usage:

# Filter by flavor
IceCreamOrder.objects.filter(flavor=FLAVORS.chocolate)
# Get display name for certain flavor
In [7]: FLAVORS.get_display_name(FLAVORS.chunky)
Out[7]: 'Chunky Munky'

Why second approach is favourable over first one?

1. Works on all versions of Django, not just Django 3
2. Flexible: You can add extra information about your choices.
   For example:

FLAVORS = Choices({
    "chocolate": {"id": "ch", "help_text": "Made of coca beans and milk"},
    "vanilla": {"id": "vn", "help_text": "The basic ice cream flavor"},
    "strawberry": {"id": "st", "help_text": "With artificial strawberry flavor"},
    "chunky": {"id": "cm", "display": "Chunky Munky", "help_text": "verry chunky"},
}, order_by="id")

Then you can do

In [12]: FLAVORS.get_value(FLAVORS.chocolate, "help_text")
Out[12]: 'Made of coca beans and milk'

3. More useful when exposing your code to an API.
   Suppose you want to expose an API for mobile developers to interact with your orders.
   Since Choices class is basically a dictionary, you can json serialize it - as it is - for mobile developers to know what options are available

In [16]: json.dumps(FLAVORS)
Out[16]: '{"chocolate": {"id": "ch", "help_text": "Made of coca beans and milk", "display": "Chocolate"}, "vanilla": {"id": "vn", "help_text": "The basic ice cream flavor", "display": "Vanilla"}, "strawberry": {"id": "st", "help_text": "With artificial strawberry flavor", "display": "Strawberry"}, "chunky": {"id": "cm", "display": "Chunky Munky", "help_text": "verry chunky"}}'

# or

In [27]: json.dumps(list(FLAVORS.keys()))
Out[27]: '["chocolate", "vanilla", "strawberry", "chunky"]'

Moreover, your API can continue using the "code names" of your choices in API requests/responses.
For example:

# GET /?flavor=chocolate
user_flavor = request.GET["flavor"]
try:
    order.flavor = FLAVORS[user_flavor]["id"]
except KeyError:
    return {"error": "Invalid flavor"}

When returning API data regarding your order, you don't need to show its internal database value

return {
    "user": order.user.name
    "price": order.price,
    "flavor": FLAVOR.get_code_value(order.flavor)  # return "chocolate" instead of "ch"
}

Finally django_model_helpers has other useful functions that make your life much easier.

For example:

upload_to

import model_helpers

class Profile(models.model):
    name = CharField(max_length=100)
    picture = ImageField(upload_to=model_helpers.upload_to)

It will automatically create folder for your files (configurable), will do validations to ensure users don't upload dangerous files like .php or .exe (configurable) with almost no effort at all.

cached_model_property

Similar to django's cached_property except that it doesn't cache the value in the model instance but rather it utilize django's builtin cache feature

example:

class Team(models.Model):
    @cached_model_property
    def points(self):
        # Do complex DB queries
        return result

    # You can manually override the cached value
    @cached_model_property(readonly=False)
    def editable_points(self):
        # get result
        return result

    # cached value will only be cached for one second (default is 5 minutes)
    @cached_model_property(cache_timeout=1)
    def one_second_cache(self):
        # get result
        return result

Location within the Book

• Chapter or Appendix: Chapter 6 Django Model Design
• Section: 6.4
• Subsection: 6.4.4

Description

This section appears to be missing the guidance relating to when to use Null and Blank. It skips right over to the next section after explaining what this section is supposed to be about.

Possible Solutions

I checked version 1.11 of the book and it appears there used to be a table here, so that's what is missing and needs added back.

Edit: The table is actually a page down, after the entire next section, so it's still missing from the correct section but does exist.

Greetings!

Location within the Book

Chapter 4

Description

In chapter 4 I do miss is a sort of best practice on when using an index page that is leading to a app. Or creating a 'Home' app where you dump the general stuff in like 'contact' and 'about' that doesn't necessarily use models.

When using an 'index' page that is existing within a app like 'blog', you are basically creating a dependency. And when using a 'Home' app you don't have this 'problem'.

But what is the industry standard for something like this? I do understand it sounds like a noOb problem. But I didn't find any answer (even in advanced books) any resource that is even the Django website doesn't really give any answer on this topic.

Possible Solutions

Extend Chapter 4 on this topic.

https://myst-parser.readthedocs.io/en/latest/using/syntax.html

According to wemake-python-styleguid you shouldn't use local imports "for consistency". fluke8 raises LocalFolderImportViolation if you do so.

Not a big deal but I think it's worth a mention in the book.

References to a section in the appendix consistently start with „Chapter 37: Appendix ...“. The „Chapter 37:“ should be omitted. One (of many) example is right before section 5.3.1 where the text refers to appendix E as „ Chapter 37: Appendix E: Settings Alternatives“.

Original author: @lmsteffan
Original issue: twoscoops/two-scoops-of-django-1.11#87

https://cdf.9vo.lt/

Credit to Ana Balica (https://twitter.com/anabalica)

Greetings!

Hello! As a reader, you're encouraged to submit bug reports to us for errors that you find. In turn we will give you credit for your contributions in not just the e-book but also in the print paperback. This is your opportunity to have your name in one of our books as a contributor, which you are then welcome to add to your resume and LinkedIn profile.

Location within the Book

• Chapter or Appendix: 8
• Section: 4
• Subsection: 1

Hint: Page numbers change all the time. The best way to report an issue is by chapter, section, and subsection numbers.

Description

If grammar, enter problematic text here, otherwise delete this line.

8.4.1 Makes for Shorter, More Intuitive, and Don’t Repeat Yourself
URL Names
In example 8.2 what we don’t see are URL names like “tastings_detail” and
“tastings_results” that copy the model or app name.

Possible Solutions

I think It should say: example 8.3

Now we have a windows machine so this should be easier to test

Original issue: twoscoops/two-scoops-of-django-1.11#58
Original author: @you-zhou

Greetings!

Location within the Book

• Chapter or Appendix: 5
• Section: 2
• Subsection: TIP: Multiple Files With Continuous Integration Servers

Description

The final line of the tip is orphaned after Table 5.1 (Settings files and their purpose).

Since you're here, I'm not sure whether that label for Table 5.1 should be "and their purposes" for plurality agreement?

Possible Solutions

Fun new Django 3 feature!

The braces are missing after OPTIONS: in the example box.

https://github.com/twoscoops/two-scoops-of-django-1.11/issues

I've been thinking about this a bit.. links are usually something messy in printed and digital books:

• They are ugly and sometimes long enough to break whatever paragraph or box they are (printed and ebook)
• You can't click them (printed) so get ready to type (usually weird long urls not easy to read)
• Digital resources evolve fast so links are weak references that may change in the future (printed and ebook)

Now that you and I hate links, let's remember that they are very useful so... how can we make them better?

mantained shortened links

The idea is to use your own maintained shortener to achieve this:

• Short links that won't break lines or boxes (printed and ebook)
• Short links are easy to type (printed)
• Short links can be updated if the resources move so your printed version gets flexible

This is nice but:

• It needs a redirection machine working somewhere (and a domain)
• A lot of work to rewrite links along the book
• Short links don't show you where you are going

A combination of short link+footnote with the complete urls would help the reader know where does this link should go. All of this must be explained in conventions used in the book.

Unexpected benefits: you get feedback on the use of links in your book. You could do something in the future, when the next book shows, like: hey we have a newer one! You can periodically check all of them and prevent broken links.

//// There is another approach to fix very long links: design them as you would if the book was not intended to be printed. (href + short and clearer tag) and use some kind of numbering so printed version readers can browse some "links table" with chapter references on your website.

I hope this helps, thanks for all!

Location within the Book

• Chapter or Appendix: Chapter 14 or 22
• Section:
• Subsection:

Description

Krzysztof Żuraw wrote a very clear article on the topic: https://krzysztofzuraw.com/blog/2017/how-to-test-django-template-tags.html

• Either link to it or use it as an example.
• Provide full accredation

Original Issue: twoscoops/two-scoops-of-django-1.11#25

Location within the Book

• Chapter or Appendix: 23
• Section: 10
• Subsection: 3

Description

As described in Chapter 25: Documentation: Be Obsessed, your docs should be written in ReStructuredText.

But chapter 25 recommends Markdown (which according to the changelog is new).

Possible Solutions

Rewrite the "23.10.3 Documentation" section to also recommend Markdown

Description

The security chapter could use a reference to the PyCharm Security project, which has automated checking for Django security pitfalls. The project is free and open-source.

It can be run from PyCharm as an extension, or as a GitHub Action. It will find and highlight pretty-much all of the issues marked in the chapter. Including-

• All of the insecure Django SQL injection holes
• Missing CSRF middleware
• Missing Xframe middleware
• Enabling Debug mode
• Run PyUp.io against the installed packages
• Check for pyyaml and defusedxml usage

https://github.com/wemake-services/wemake-django-template

Location within the Book

• Chapter or Appendix: 6
• Section: 4
• Subsection: 4
  6.4.4, Table 6.2 BooleanField row

Description

The book says not to use null with BooleanField, and to rather use NullBooleanFields
However, the latest Django docs (https://docs.djangoproject.com/en/3.0/ref/models/fields/#nullbooleanfield) state:

NullBooleanField
class NullBooleanField(**options)
Like BooleanField with null=True. Use that instead of this field as it’s likely to be deprecated in a future version of Django.

Possible Solutions

Update to say that null=True is Okay

So dated!

Greetings!

Location within the Book

• Chapter or Appendix: 4
• Section: 4
• Subsection: 2

Description

signals.py item has undefined references "(see ??:??)"

Possible Solutions

In page 116 of the book (page 150 of the pdf) there is the view declaration:

def check_sprinkle_rights(request: HttpRequest) -> HttpRequest:

Should've been

def check_sprinkle_rights(request: HttpRequest) -> HttpResponse:

In example 7.4, an F() expression is used, but also give barely any explanation as to what it is.

• Original Issue: twoscoops/two-scoops-of-django-1.11#8
• Original Author: @raiderrobert

Location within the Book

• Chapter or Appendix: 36
• Section: 36.4
• Subsection: 36.4.1 - 10 Easy Ways to Participate

Hint: Page numbers change all the time. The best way to report an issue is by chapter, section, and subsection numbers.

Description

There is an unnecessary equals sign in the Django Subreddit link in recommendation 5 of this section. Clicking the link still works, but if you copy and paste the full URL you'll get an error due to that equals sign being there.

From 1.8, in example 7.1 and 7.3, Q object is shown and given no explanation as to what it is. In context, it's used to show why you shouldn't make a pep8 violation for line lengths.

• Original Issue: twoscoops/two-scoops-of-django-1.11#7
• Original Author: @raiderrobert

Location within the Book

Any block with a "bad code" example, for example: "Example 1.2: Bad Python Imports". All of the comment text is invisible when viewed on some reading devices.

Description

These blocks are completely unreadable on e.g. a Kindle paperwhite device which renders in greyscale so relies on contrast for readability. The "grey" text is not visible at all, and dark red text is almost invisible.

Possible Solutions

Please provide a light background, always. Light red if must be, but a dark background and darker white foreground make the example code unreadable due to lack of contrast.

PS: A .mobi and/or .epub release of this book would be greatly appreciated. The PDF version converted to these formats does not allow native font change, text resizing and page reflow which very much sucks for reading ebooks on almost any device.

Location within the Book

• Chapter or Appendix: 5
• Section: 5
• Subsection: 1

Description

In "TIP: Using Multiple Requirements Files With PaaS"

We cover this in ??: ??

Greetings!

Hello! As a reader, you're encouraged to submit bug reports to us for errors that you find. In turn we will give you credit for your contributions in not just the e-book but also in the print paperback. This is your opportunity to have your name in one of our books as a contributor, which you are then welcome to add to your resume and LinkedIn profile.

Notes:

• TODOs are markers to let you know we are going to expand an area, so reporting them during the ALPHA and BETA period doesn't qualify as an attributable item.
• ??:?? are references for areas written but still being examined by our reviewers and not yet in the published version of the book. Reporting them doesn't qualify as an attributable item.

Location within the Book

• Chapter or Appendix: 6
• Section: 4
• Subsection: 5

Hint: Page numbers change all the time. The best way to report an issue is by chapter, section, and subsection numbers.

Description

In table 6.2, the "Setting blank=True" column for ManyToManyField mention setting null=True which is discouraged in "Setting null=True" column.

Possible Solutions

Delete the last sentence: "If so, you will also want to set null=True"

Location within the Book

• Chapter or Appendix: Appendix H
• Section: (not numbered) Watch Out For Spaghetti Code

Description

Dead link to https://channels.readthedocs.io/en/stable/testing.html

Possible Solutions

Should link to https://channels.readthedocs.io/en/stable/topics/testing.html

Original author: @mpachas
Original issue: twoscoops/two-scoops-of-django-1.11#71

Location within the Book

• Chapter or Appendix: 2
• Section: 2
• Subsection: 0

Description

In info box "WARNING: Be Wary of Pipenv", the reason for staying clear of Pipenv is stated as it not having seen a formal release since late 2018. The project has had 3 github releases the last few weeks so a new pypi release soon seems likely.

Possible Solutions

Current state may not warrant immediate changes to the book so you could consider this more of a heads for now.

Cheers,
pabu

1. Write custom formatter so our customized LaTeX will work with TextHT. This will render the HTML. This is a major effort which will take at least a two weeks.
2. Convert HTML to epub
3. Convert epub to .mobi

Expected delivery: Mid-June