Requirements: Git-Click the link and download the installer. Heroku CLI  - Click the link and download the installer. After successfully installing the above requirements, below are the steps for deploying your react app to heroku. Step 1 - Sign u...

17 Apr 2021 4:32pm GMT

17 Apr 2021 2:03pm GMT

This post was co-authored with fellow General Assembly Software Engineering Immersive member JC Coles If you've written full stack applications in JavaScript using Node, Express, perhaps Mongoose for accessing a database, maybe some packages like Pas...

16 Apr 2021 10:52pm GMT

News

Announcement of 4.x Technical Board Election Registration

A new Technical Board will be elected for Django 4.0+. All DSF Members are automatically eligible to vote. if you are not a DSF Member but would like to apply to vote, please register online.

djangoproject.com

Django Debug Toolbar security releases issued: 3.2.1, 2.2.1 and 1.11.1.

These releases address a security issue with severity "high." We encourage all users of Django Debug Toolbar to upgrade as soon as possible.

djangoproject.com

DEFNA: Board Updates

DEFNA Board updates for 2021.

defna.org

Get PyCharm, Support Django

Until April 29, you can purchase PyCharm at 30% off and the full purchase price will be donated to the Django Software Foundation.

jetbrains.com

Sponsored Link

Migrating from Django 1.7 to 3.1 is no small task. Learn how to successfully leapfrog a massive Django/Python upgrade.

sixfeetup.com

Articles

Deploying Django at small scale by Timo Zimmermann

An interesting look at building and deploying an intentionally small scale Django site.

screamingatmyscreen.com

Big Bay Dam Monitoring Dashboard: 4-Part Tutorial

Learn how to build a dam safety monitoring dashboard using Django.

engineertodeveloper.com

Fluent in Django: Improving your application

The second part in a series covers uploading an image, using packages, pagination, and customizing the admin.

girlthatlovestocode.com

Embrace the Grind by Jacob Kaplan-Moss

Sometimes, programming feels like magic: you chant some arcane incantation and a fleet of robots do your bidding. But sometimes, magic is mundane. If you're willing to embrace the grind, you can pull off the impossible.

jacobian.org

Reindexing all tables after upgrading to PostgreSQL 13 by Adam Johnson

Adam shows how and why reindexing is a good idea with PostgreSQL 13.

adamj.eu

Python, Django, and React Development on Apple Silicon

Last year, Apple announced that they would transition their entire Mac line from Intel processors to their ARM64 Apple Silicon chip called the M1. Several weeks ago, I started testing development on MacBook Air with the Apple M1 chip.

caktusgroup.com

Porting VaccinateCA to Django

The VaccinateCA project was ported quickly from AirTable to Django. Read Simon's writeup about how that went and some nice OSS projects that helped get there.

simonwillison.net

Design Articles

My current HTML boilerplate by Manuel Matuzović

Every element I use for the basic structure of a HTML document, with explanations why.

matuzo.at

Podcasts

Django Chat #89: Project Beacon with Jackson Wilkinson

Jackson is the CTO of Project Beacon, a social benefit organization that increases the availability and decreases the price of Covid-19 testing in Massachusetts. He has a long history as an engineer and executive working in tele-medicine including previous stints with US Digital Response, PathAI, Care.com, LinkedIn, and many more.

djangochat.com

Projects

nalgeon/sqlean

All the missing SQLite functions.

github.com

mbi/django-rosetta: Rosetta is a Django application that eases the translation process of your Django projects

Rosetta is a Django application that eases the translation process of your Django projects - mbi/django-rosetta

github.com

Sponsorship

Sponsor Django News Newsletter!

Reach over 1,860 engaged Django developers every week. Sponsorship availability, prices, and details are available here.

django-news.com

This RSS feed is published on https://django-news.com/. You can also subscribe via email.

16 Apr 2021 3:00pm GMT

When organizations are performing well, the whole is more than the sum of its parts. That's the whole point of building teams: together we can accomplish more than if we work solo. But many organizations get stuck: suddenly, the whole becomes less than the sum of its parts! When this happens, it can be difficult to understand what's going on: everyone can be working hard, and yet as a whole, the team just seems to be treading water. When this happens, I've found a useful model for understanding what's going on. I like to ask: is the organization stuck on vision, strategy, or tactics?

16 Apr 2021 5:00am GMT

heroicons is a free SVG icon set for your websites, from the creators of tailwindcss. SVG icons are great - they're small, they sit inline in your HTML, and you can scaled and colour them with plain HTML and CSS. And heroicons is a great icon set - minimal, clear, and consistent.

I've decided to use both tailwindcss and heroicons in DB Buddy. Since others have shown interest I've turned my work into a package.

heroicons itself provides the icon set on their web page for copy-pasting, but this gets tiresome. Inline SVG's have no labels, and bloat template files. heroicons provides React and Vue packages to summon icons by name, and a zip file for the rest of us.

My new python package heroicons bundles a shrunken version of that zip file, to provide both Django and Jinja template tags. Using these you can include an icon by name, set its size, and add extra HTML attributes.

For example, in a Django template:

{% load heroicons %}

{% heroicon_outline "academic-cap" size=48 class="h-4 w-4 inline" data_controller="academia" %}

It currently bundles version 1.0.1 of the icon set, and I'll update it as new releases come out. Check it out on PyPI.

Fin

Thanks to Steve Schoger for creating such great icons!

-Adam

16 Apr 2021 4:00am GMT

• @mjacksonw
• Project Beacon
• PathAI
• Viget: Consultancy that built site
• Aptible
• US Digital Response

Support the Show

This podcast is a labor of love and does not have any ads or sponsors. To support the show, please consider recommending a book from LearnDjango.com, signing up for the free weekly Django News newsletter, or learning more about Button, a simpler deployment story for Django.

14 Apr 2021 10:00pm GMT

Overview Over the past few weeks, I have been working on a project where one of the main requirements is to enable token verification and authenticate or register & authenticate a user with Django. What we're going to do We are going to use google-a...

14 Apr 2021 9:21pm GMT

Hello! Meet Django. In this era, Django is leading because it has become every business's need. But why is Django Development so popular? "Django is an open-source high-level Python framework that serves the primary purpose of enabling super-fast dev...

13 Apr 2021 6:44pm GMT

I created django-feature-policy in 2018 allow Django projects to control the draft security header Feature-Policy. Feature-Policy allows your site to restrict which origins can use some sensitive browser features, such as the the payments API or access to the webcam. This is valuable if you're using any third party JavaScript. Whether such JavaScript comes from npm or an external script tag, you can protect against it doing some bad things with your users.

In 2020 a new specification renamed the header to Permissions-Policy, with different syntax. Browsers updated accordingly, so I also updated django-feature-policy. I left it sending both the old and new forms so that older browser versions would remain protected.

A few weeks ago, I updated my package once more, renaming it to django-permissions-policy, and removing the old Feature-Policy header. This is because Chrome now logs warnings about the old Feature-Policy header.

To update for the rename, I uploaded the new version as django-permissions-policy version 4.0.0, and released django-feature-policy 4.0.0 as an empty package that depends on the new name. Thanks to Simon Willison for his repo template demonstrating this technique.

If you are using django-feature-policy, updated and swap it for django-permissions-policy. And if you're not, try it out, and score your site an extra grade on SecurityHeaders.com.

For reference, here's the policy I'm using on DB Buddy:

PERMISSIONS_POLICY = {
    "accelerometer": [],
    "ambient-light-sensor": [],
    "autoplay": [],
    "camera": [],
    "document-domain": [],
    "encrypted-media": [],
    "fullscreen": [],
    "geolocation": [],
    "gyroscope": [],
    "magnetometer": [],
    "microphone": [],
    "midi": [],
    "payment": [],
    "sync-xhr": [],
    "usb": [],
}

This policy disables many privacy-sensitive features for all origins, including the site itself. It also disables the sync-xhr feature, which prevents AJAX requests from blocking the main thread - this helps performance rather than improving security. If you add any policy to an existing site, be sure to test all functionality thoroughly with your browser console open.

To further boost your site's security, check out my Django Security Headers Guide, although with renames like this it's getting a little dated!

Fin

May your site be ever more secure,

-Adam

13 Apr 2021 3:42pm GMT

It feels like common knowledge and an accepted fact that you want to run PostgreSQL in production. And have some sort of load balancer to be able to scale your application server horizontally. Throw in Redis for caching and you have the most generic web application stack I can come up with. At scale this makes a ton of sense. It is a battle tested stack, that will most likely not fail you and if it does, there are tons of resources on how to fix it. Those are a lot of moving parts you want to keep updated and maintained, so let us talk about simplifying this stack a bit for small scale deployments.

There are lots of resources out there explaining the setup I mentioned above. Those resources are valuable and will guide you through production setups you will see at many places. But what when you are just starting and want to get your first application online? Things can be a lot easier.

I recently started moving my blog and photo sharing site to their own, small virtual server. I just blogged about the reason for doing this, so I will not go into detail. Both sites are powered by Django and are setup in exactly the same way. Deploying one of those sites took me roughly fifteen minutes, which I consider reasonably fast.

SQLite

Depending on how your application is designed and used, you might not need PostgreSQL or any other database server. I am the only person publishing content on both sites. So I can pretty much say it is a read only application, as one or two writes to the database every other day are negligible. For read heavy applications SQLite is doing an amazing job. There are surely limitations, but you can get away with using SQLite more often than you would imagine.

I could go into more details how SQLite is suitable for production use, but let me link to some articles which are doing a way better job, and have actual data to show you which its strengths are.

• Scaling SQLite to 4m qps
• Appropriate uses for SQLite
• SQLite in production with WAL

A really neat feature is being able to move your database around with cp. Having a copy of your production database on your local system with a simple copy and paste, or moving a newly prepared database to your production system before going live is pretty nice. For backups I would still suggest using .backup.

Caddy

When deploying to a single box, general wisdom is to setup a reverse proxy and use it to terminate SSL. The goto way to do this is setting up nginx and using the acme client to get a certificate from Let's Encrypt. (I have been deploying nginx for roughly ten years now, and I still cannot remember the stupid configuration file syntax.)

Caddy on the other hand not only takes care of getting a certificate from Let's Encrypt, but also keeping it renewed. And configuration is pretty simple if all you want is getting your site online.

static.screamingatmyscreen.com {
  root * /home/timo/static
  file_server
  encode zstd gzip
}

media.screamingatmyscreen.com {
  root * /home/timo/media
  file_server
  encode zstd gzip
}

www.screamingatmyscreen.com {
  reverse_proxy 127.0.0.1:8000
  encode zstd gzip
}

screamingatmyscreen.com {
  redir https://www.screamingatmyscreen.com{uri} permanent
}

I can actually remember how to do this! Caddy still lacks a few features and might not work for more complex setups, but for many scenarios it is more than good enough. Did I mention that it is easy to setup?

If you want tools like goaccess to be able to parse your webserver logs, you most likely want them stored in the Common Log Format. To turn on logging you throw a small snippet in the domains configurations.

log {
  output file /var/log/sams.log {
    roll_size 1gb
    roll_keep 5
    roll_keep_for 720h
  }
format single_field common_log
}

You might want to consider throwing in some cache headers as well :)

Server restarts

One of the most common questions I have heard from people deploying their first app, is how to make sure the app starts and restarts when the server is rebooted. I usually deploy on boxes running Debian, which ships with systemd.

[Unit]
Description=gunicorn
After=network.target

[Service]
User=blog
Group=blog
WorkingDirectory=/home/blog/app
ExecStart=/home/blog/venv/bin/gunicorn --bind 127.0.0.1:8000 --workers 5 blog.wsgi

[Install]
WantedBy=multi-user.target

Assuming you setup a user named blog, created a virtual environment in /home/blog/venv and cloned your app to /home/blog/app, you can paste this in /etc/systemd/system/gunicorn.service and enable and star the service.

$ systemctl enable gunicorn
$ systemctl start gunicorn
$ systemctl status gunicorn

Scale

I know we wanted to talk about tiny or small scale deployments. But this does not mean you do not hope your small website goes viral, is the next big hit or that your latest post hits HackerNews, Reddit and Twitter trending at the same time.

I am currently running my apps on a CPX11 virtual server from Hetzner. 2 cores, 2GB memory for 4,15€ / month. The little box is not even close to maxing out its resources, even when visitor count spikes when a new article goes live and is shared on larger platforms.

Let us assume your website goes viral, millions of unique visitors come each day to read your latest article. First of all: congratulations! You made it further than most of us ever will :) But rest assured bare metal servers will get you a long way. A PX62-NVME costs 88.06€ / month. 6 real cores, 64GB memory and 2 NVMe disks in raid 1. A box like this will handle way more traffic than you can imagine, if all you did so far was working with virtual servers from AWS or other cloud providers.

There are obviously very good reasons why we started using database servers on external boxes, scaling apps horizontally and adding a load balancer in front of it. If you run an app and not a website which hit scale, you will want to start doing all of this and more.

If you ever plan to manipulate data outside of your Django application, you might want to consider adding CHECK constraints to make sure the data going into the DB is actually what you expect. When you want to migrate to another database server, this will make your life a lot easier.

Famous Final Words

Small scale websites allow you to get away with things which sound counter intuitive when you are used to deploying complex web applications with service level agreements, or when you are just starting out and only find resources talking about those production ready deployments.

You might want to use your small site or app to learn how to do a full scale deployment, which is a really good hands on way to learn. But if you are only after getting your site online, consider taking shortcuts. Getting the first deployment done and seeing your site live will be a great feeling and you can always iterate, do not worry about getting everything 100% right for a scale you do not have from the start.

13 Apr 2021 1:42am GMT

A model is the single, definitive source of information about your data. It contains the essential fields and behaviors of the data you're storing. Generally, each model maps to a single database table. Create your project folder e.g "my project" and...

12 Apr 2021 2:24pm GMT

Progress Highlights Project Research Drafted the low-level 3-tier system architecture diagram for Fitweet using Visual Paradigm (my favourite UML diagram tool) Attended 5th FYP meeting with supervisor to discuss regarding Use Case Description (UCD...

12 Apr 2021 12:22pm GMT

Hi guys, in the last article we looked into Django architecture where we stated that Django is majorly of three layers i.e Model layer, Views layer and Template layer (MVT structure). So in this article we will look into the full gist about Django ...

12 Apr 2021 12:22pm GMT

Django's TestCase class provides the setUpTestData() hook for creating your test data. It is faster than using the unittest setUp() hook because it creates the test data only once per test case, rather than per test.

Converting TestCases from setUp() to setUpTestData() is one of the most reliable ways to speed up a test suite, with no costs beyond from the time it might take to change your code. I've often found it confers a 3x speedup, or more.

Here's my how-to guide for doing this conversion for a single TestCase. Rinse and repeat across your code base!

Example Test Case

We'll convert this test case:

from django.contrib.auth.models import User
from django.test import TestCase

from example.core.models import Book


class IndexTests(TestCase):
    def setUp(self):
        self.book = Book.objects.create(title="The Checklist Manifesto")
        self.user = User.objects.create_user(
            username="tester",
            email="test@example.com",
        )
        self.client.force_login(self.user)

    def test_one(self):
        ...

    def test_two(self):
        ...

0. Install django-testdata on Django < 3.2

Before Django 3.2, use of setUpTestData() has a major caveat: Django rolls back changes to model instances in the database but not in memory. This means you often need extra code to re-fetch data to ensure tests are correctly isolated.

Django 3.2 includes a fix: TestCase now copies any objects created in setUpTestData() on-demand for subsequent tests. Your tests can thus change objects as needed, with following tests seeing the original versions.

Luckily, this behaviour is available for older Django versions in the django-testdata package. Install this if you're using Django < 3.2 - you can remove it when you upgrade in the future.

1. Run the target test case

This will check the tests currently pass and gives us a baseline for how long they take. Run the test command to run just this test case, with the database reuse flag to reduce startup time.

For example with Django's test framework:

$ ./manage.py test --keepdb example.core.tests.IndexTests
Using existing test database for alias 'default'...
System check identified no issues (0 silenced).
..
----------------------------------------------------------------------
Ran 2 tests in 0.015s

OK
Preserving test database for alias 'default'...

Or with pytest:

$ pytest --reuse-db example/core/tests.py::IndexTests

2. Add a stub setUpTestData()

Add a setUpTestData() class method in the test case class.

On Django 3.2+ this can be a vanilla class method:

 class IndexTests(TestCase):
+    @classmethod
+    def setUpTestData(cls):
+
     def setUp(self):
         self.book = Book.objects.create(title="The Checklist Manifesto")
         self.user = User.objects.create_user(

On Django < 3.2 you'll also need to import and use @wrap_testdata from django-testdata:

 from django.contrib.auth.models import User
 from django.test import TestCase
+from testdata import wrap_testdata

 from example.core.models import Book


 class IndexTests(TestCase):
+    @classmethod
+    @wrap_testdata
+    def setUpTestData(cls):
+
     def setUp(self):
         self.book = Book.objects.create(title="The Checklist Manifesto")
         self.user = User.objects.create_user(

3. Move data creation from setUp() to setUpTestData()

Move all code that creates data from setUp() to setUpTestData(), and change its use of self to cls. This can mean moving code that creates model instances, supports such creation, or that creates other expensive objects. Other per-test setup, such as using methods on the test client, cannot normally live in setUpTestData() as it won't be reset between tests.

If nothing remains in setUp() after this, delete it.

In our example this change looks like:

 class IndexTests(TestCase):
     @classmethod
     def setUpTestData(cls):
+        cls.book = Book.objects.create(title="The Checklist Manifesto")
+        cls.user = User.objects.create_user(
+            username="tester",
+            email="test@example.com",
+        )

     def setUp(self):
-        self.book = Book.objects.create(title="The Checklist Manifesto")
-        self.user = User.objects.create_user(
-            username="tester", email="test@example.com"
-        )
         self.client.force_login(self.user)

     def test_one(self):

With this final result:

from django.contrib.auth.models import User
from django.test import TestCase

from example.core.models import Book


class IndexTests(TestCase):
    @classmethod
    def setUpTestData(cls):
        cls.book = Book.objects.create(title="The Checklist Manifesto")
        cls.user = User.objects.create_user(
            username="tester",
            email="test@example.com",
        )

    def setUp(self):
        self.client.force_login(self.user)

    def test_one(self):
        ...

    def test_two(self):
        ...

4. Re-run tests

Re-run the test command from step one to check the conversion has been successful, and to see any time savings:

$ ./manage.py test --keepdb example.core.tests.IndexTests
Using existing test database for alias 'default'...
System check identified no issues (0 silenced).
..
----------------------------------------------------------------------
Ran 2 tests in 0.012s

OK
Preserving test database for alias 'default'...

We don't see much difference in this example because there isn't much test data, and we only have two tests, but it is a few milliseconds faster. In real world test cases you should see more change.

Done

That's all it takes! Repeat for the next test case in your suite.

If you're trying to convert your whole test suite, try working in batches, starting with the slowest cases.

Fin

Thanks to Simon Charette for creating django-testdata and submitting it for merging into Django 3.2.

May your tests run ever faster,

-Adam

12 Apr 2021 4:00am GMT

Weeknotes (2021 week 13 and 14)

Sorting django-admin-ordering instances in Python code

django-admin-ordering's OrderableModel gained a __lt__ function (and functools.total_ordering) in 0.14 which allows sorting model instances in Python code. This is useful for my projects.

Some user agents do not like single quotes in OpenGraph tags

Django autoescapes content inserted into HTML (an excellent default). It also converts some special characters into entities (resp., html.escape does this). It seems that some user agents do not like entities in OpenGraph tags and show &x27; instead of '. Oh well. I added a workaround for this problem to feincms3-meta. It checks whether the value is safe¹ and basically skips escaping in this case - at least I hope it is safe!

feincms3-forms - A new forms builder for the Django admin interface

For a current project we needed a forms builder with the following constraints:

• Simple fields (text, email, checkboxes, dropdowns etc.)
• Custom validation and processing logic
• It should be possible to add other content, e.g. headings and explanations between form fields

The form_designer fulfilled a few of these requirements but not all. It still works well but I wanted a forms builder based on django-content-editor for a long time already. Also, I really like the feincms3 pattern where the third party app only provides abstract models. Yeah, it is much more work to start with but the flexibility and configurability is worth it - especially since it's possible to write straightforward code to handle special cases² instead of configuring even more settings.

The humble beginnings are here in the feincms3-forms repository. The test suite already shows how things work together but as of now no documentation exists and no release has been made yet. I hope it will be ready for a first beta release in the next few weeks 😄

11 Apr 2021 10:21am GMT