Django community: RSS
This page, updated regularly, aggregates Community blog posts from the Django community.
-
Switch A Django Project To Use Pytest - Building SaaS #57
In this episode, I replaced the default Django test runner to use pytest. We walked through installation, configuration, how to change tests, and the benefits that come from using pytest. We started by looking at the current state of the test suite to provide a baseline to compare against. After that, I went to PyPI to find the version of pytest-django that we wanted to install. I added the package to my requirements-dev. -
Waiting in asyncio
One of the main appeals of using asyncio is being able to fire off many coroutines and run them concurrently. How many ways do you know for waiting for their results? -
Python at Microsoft- Nina Zakharenko
Nina’s website Learn Python FrontendMasters Course Goodbye Print Hello Debugger at DjangoCon US 2019 & PyCon2020 PythonTutor@nnja on Twitter Nina on Twitch Nina’s Frontend Masters author pageGetting Started with Python in VS CodeVS Code - Device Simulator Express ExtensionMicrosoft MakeCode - Block Based Programming for Hardware Emulator4 new *Python/Django video tutorials for productive cloud development -
De-Google my blog - How to blog in 2020 without Google
Hi everyone! Right now I have Google almost completely out of my life, but some of the top commentaries of my posts in /r/degoogle and /r/selfhosted were “Your blog still uses google for resources lol”, so I needed to change that. Shame. In my old blog, the features that used Google where: Disquss comments The Ghost theme Before we begin, I want to let you know that all these fixes have been applied, so you are currently experiencing the final result. Fixing comments I was using disquss to handle comments, since it is what everyone recommends. I checked the network resources on my site and found something horrible: A bunch of random calls to a bunch of external addresses, not just Google. Since I care about my reader’s privacy, disquss had to go. Someone in /r/degoogle suggested “Commento”, and it looked like it was exactly what I needed: A free and opensource, self-hosted alternative to disquss, and it also had an official docker release! According to their documentation: version: '3' services: server: image: registry.gitlab.com/commento/commento restart: always ports: - 5000:8080 environment: COMMENTO_ORIGIN: https://commento.rogs.me COMMENTO_PORT: 8080 COMMENTO_POSTGRES: postgres://postgres:mysupersecurepassword@db:5432/commento?sslmode=disable COMMENTO_SMTP_HOST: my-mail-host.com COMMENTO_SMTP_PORT: 587 COMMENTO_SMTP_USERNAME: mysmtpusername@mail.com COMMENTO_SMTP_PASSWORD: mysmtppassword COMMENTO_SMTP_FROM_ADDRESS: mysmtpfromaddress@mail.com depends_on: - db db: … -
De-Google my blog - How to blog in 2020 without Google
Hi everyone! Right now I have Google almost completely out of my life, but some of the top commentaries of my posts in /r/degoogle and /r/selfhosted were “Your blog still uses google for resources lol”, so I needed to change that. Shame. In my old blog, the features that used Google where: Disquss comments The Ghost theme Before we begin, I want to let you know that all these fixes have been applied, so you are currently experiencing the final result. Fixing comments I was using disquss to handle comments, since it is what everyone recommends. I checked the network resources on my site and found something horrible: A bunch of random calls to a bunch of external addresses, not just Google. Since I care about my reader’s privacy, disquss had to go. Someone in /r/degoogle suggested “Commento”, and it looked like it was exactly what I needed: A free and opensource, self-hosted alternative to disquss, and it also had an official docker release! According to their documentation: version: '3' services: server: image: registry.gitlab.com/commento/commento restart: always ports: - 5000:8080 environment: COMMENTO_ORIGIN: https://commento.rogs.me COMMENTO_PORT: 8080 COMMENTO_POSTGRES: postgres://postgres:mysupersecurepassword@db:5432/commento?sslmode=disable COMMENTO_SMTP_HOST: my-mail-host.com COMMENTO_SMTP_PORT: 587 COMMENTO_SMTP_USERNAME: mysmtpusername@mail.com COMMENTO_SMTP_PASSWORD: mysmtppassword COMMENTO_SMTP_FROM_ADDRESS: mysmtpfromaddress@mail.com depends_on: - db db: … -
How to auto-reload Celery worker on Code Change
In this Django Celery tutorial, I would talk about how to auto-reload Celery worker on code change. -
How to auto-reload Celery worker on Code Change
In this Django Celery tutorial, I would talk about how to auto-reload Celery worker on code change. -
Django Slug + ID URL Design
One of the things I like about dev.to is their URL design. It combines a slug with a hashed value representing an internal representative of some kind of index value to ensure uniqueness. You can see an example of it in my post "Autodocumenting Makefiles" featured in the URL "https://dev.to/feldroy/autodocumenting-makefiles-175b". Let's break apart that URL: feldroy is my company name. autodocumenting-makefiles is the slug and it's based off the article title. 175b is a hashed value that is either stored in an indexed character field or broken down by the router into a numeric primary key. Here is another way of looking at their URL design: /<org-or-username>/<slugified-title>/<hashed-id> Let's see how we can implement a simplified version of this technique using Django. Our Version of the URL We're going with a simpler version of the Dev.to implementation. Our implmentation will the database primary key to ensure uniqueness instead of the hashed value relied on by Dev.to. I think Dev.to uses an identifier because it's more easily remembered and/or they feel it makes for a more attractive URL. What Dev.to doesn't do is rely on it for security, as they know short hashes like this are easily broken. /<username>/<slugified-title>/<primary-key>/ Okay, now that … -
The Fast Way to Test Django transaction.on_commit() Callbacks
Django’s transaction.on_commit() hook is useful for running tasks that rely on changes in the current database transaction. The database connection enqueues callback functions passed to on_commit, and executes the callbacks after the current transaction commits. If the transaction is rolled back, the callbacks are discarded. This means they act if-and-when the final version of the data is visible to other database connections. It’s a best practice to use on_commit for things like sending external emails or enqueueing Celery tasks. (See my previous post Common Issues Using Celery (And Other Task Queues).) Unfortunately, testing callbacks passed to on_commit() is not the smoothest. The Django documentation explains the problem: Django’s TestCase class wraps each test in a transaction and rolls back that transaction after each test, in order to provide test isolation. This means that no transaction is ever actually committed, thus your on_commit() callbacks will never be run. If you need to test the results of an on_commit() callback, use a TransactionTestCase instead. TransactionTestCase is correct and works for such tests, but it’s much slower than TestCase. Its rollback behaviour flushes every table after every test, which takes time proportional to the number of models in your project. So, as your … -
Centralized Logging with Django, Docker, and CloudWatch
Let's look at how to configure a containerized Django app running on an EC2 instance to send logs to AWS CloudWatch. -
"Speed Up Your Django Tests" is Out Now
My previously announced book “Speed Up Your Django Tests” is out now on Gumroad. I’ve been writing since the 3rd March, so it’s quite a relief to have launched it. Since I announced the book for pre-order two weeks ago, I received 52 pre-orders. And since the release two hours ago, I have even received a full price order :) This was really encouraging and I’d like to thank everyone who ordered. The release is definitely a first version of the book. I set myself an ambitious deadline, in order to constrain Parkinson’s Law, but this also meant I cut a lot of content. I have 24 issues open in the book’s repo, and 42 “TODO” comments sprinkled through the source! I’m looking forward to reader feedback to guide the next edition. Thanks I’d like to thank everyone who helped me put this book together. Thanks to my partner Mafalda for her love, encouraging me to carry on when I needed it, and encouraging me to stop at the end of the day. Thanks to my parents - my mum for sharing her experience as an author, and my dad for proofreading this book with the same care he applied … -
Deploying Vault and Consul
This tutorial shows how to deploy Vault and Consul with Docker Swarm. -
Preventing SQL Injection in Django
I wrote this article for r2c, a security startup I’ve been consulting for. They’ve been building Bento, a program analysis toolkit that can find bug through static anaylsys of Python code. It uses semgrep, a code search tool that understands Python syntax. I’ve been helping them figure out which kinds of checks matter to Django developers. SQL injection is one of the places we decided to start, and I wrote this article to explain the problem, solutions, and how Bento/semgrep can help. -
Django News - New framework/language edition! - May 15th 2020
News Django 3.1 alpha 1 released Django 3.1's release is two months away, but you can start testing against it today. djangoproject.com Wagtail 2.9 Wagtail 2.9 brings some key improvements to the developer experience, fixing long-standing bugbears. wagtail.io Python 3.8.3 is now available blogspot.com Django Google Summer of Code Students 2020 Django is again participating in Google's Summer of Code. djangoproject.com Articles A Guide to ASGI in Django 3.0 and its Performance A thorough overview of ASGI in Django. arunrocks.com Thoughts on where tools fit into a workflow Brett Cannon on tooling. snarky.ca Using FastAPI with Django An overview of combining Django and FastAPI. stavros.io Preventing SQL injection: a Django author's perspective Django co-creator Jacob Kaplan-Moss on the risks of SQL injection. r2c.dev How to Check the Running Django Command It’s occasionally useful to be able to tell which Django manage.py command is being run, in a code path that otherwise has no way of telling. adamj.eu Sponsored Link Two Scoops of Django 3.x: Best Practices for the Django Web Framework The long-awaited update covers various tips, tricks, patterns, code snippets, and techniques of Django best practices. feldroy.com Videos PyCon 2020 Talk: Static Typing in Python by Dustin Ingram The … -
How To Fix A Bug - Building SaaS #56
In this episode, we picked an issue from GitHub and worked on it. I explained the flow of using test driven development to show how the bug existed in an automated test. We wrote the test, then fixed the code. After that, we did some test refactoring to clean things up. We looked at what the issue was and how it is related to the handling of the Course model in a weekly view in the app. -
How to Check the Running Django Command
It’s occasionally useful to be able to tell which Django manage.py command is being run, in a code path that otherwise has no way of telling. For example, in Speed Up Your Django Tests, I describe how to modify manage.py to default use a test settings file when the test command is run. The way to do this is to copy some of the parsing logic from inside Django, in ManagementUtility.execute(). This looks like: import sys try: command = sys.argv[1] except IndexError: command = "help" if command == "test": # Something specific to running "test" ... Whilst sometimes useful to change a default or add some instrumentation, I’d use this pattern with caution. Such changes will be hard to debug since they’re “at a distance.” It’s normally possible to instead override another part of the given command. In particular, you can write a custom management command that imports and wraps the built-in one, as I showed in Make Django Tests Always Rebuild the Database if It Exists. Warning: Incorrect sys.argv Checks I’ve seen several a few community resources suggesting a similar pattern. However, rather than checking sys.argv[1] they check it with the in operator: import sys if "test" in sys.argv: … -
Debugging a Containerized Django App in PyCharm
In this quick tutorial, we'll show you how to configure PyCharm for debugging a Django app running inside of Docker. -
Roll Your Own Tech Job - Erin Mullaney
Weekly Django Chat NewsletterErin Rachel ConsultingDjangoCon US 2019 - Roll Your Own Tech JobResources for Roll Your Own Tech JobA Quick Guide to Generating Fake Data with PandasMore of Erin's writing for the Caktus Group blogDjango ForumChooseFI podcast episode with Alan DoneganAll Up in Ya Business YouTube episode on how to operate your business (LLC, DBA, etc)SHAMELESS PLUGSLearnDjango - Free tutorials and premium books -
How I manage multiple development environments in my Django workflow using Docker compose
Hi everyone! Last week I was searching how to manage multiple development environments with the same docker-compose configuration for my Django workflow. I needed to manage a development and a production environment, so this is what I did. Some descriptions on my data: I had around 20 env vars, but some of them where shared among environments. I wanted to do it with as little impact as possible. First, docker-compose help command The first thing I did was run a simple docker-compose --help, and it returned this: Define and run multi-container applications with Docker. Usage: docker-compose [-f <arg>...] [options] [COMMAND] [ARGS...] docker-compose -h|--help Options: -f, --file FILE Specify an alternate compose file (default: docker-compose.yml) # more not necessary stuff --env-file PATH Specify an alternate environment file I went with the -f flag, because I also wanted to run some docker images for development. By using the -f flag I could create a base compose file with the shared env vars (docker-compose.yml) and another one for each of the environments (prod.yml and dev.yml) So I went to town. I kept the shared variables inside docker-compose.yml and added the specific variables and configuration to prod.yml and dev.yml docker-compose.yml: version: "3" services: app: … -
Two Scoops of Django 3.x Released
We just released the early release (alpha) of the fifth edition of our book, titled Two Scoops of Django 3.x. The 3.x means we are supporting Django 3.0, 3.1, and 3.2 Long Term Support (LTS) releases, ensuring the content will be valid until April of 2024. So long as it is May 11, 2020, anywhere on planet Earth, the e-book version sells for just US$42.95! On May 12th, 2020, the price goes up to $49.95. Hurry up and get your book! For now, the e-book is just in PDF format and will be expanded to epub and mobi formats in the days to come. Readers of this alpha version get all the updates and have the opportunity to help us shape the direction of the book through their feedback, and to be credited as contributors. If you bought the 1.11 e-book in 2020 you'll receive an email on May 11th with a discount code covering the cost of the new edition. The book will also be printed, but for several reasons that won't happen until hopefully August of this year. When we get closer to that date we'll take pre-orders and send everyone who ordered an e-book a big discount … -
Two Scoops of Django 3.x Released
We just released the early release (alpha) of the fifth edition of our book, titled Two Scoops of Django 3.x. The 3.x means we are supporting Django 3.0, 3.1, and 3.2 Long Term Support (LTS) releases, ensuring the content will be valid until April of 2024. So long as it is May 11, 2020, anywhere on planet Earth, the e-book version sells for just US$42.95! On May 12th, 2020, the price goes up to $49.95. Hurry up and get your book! For now, the e-book is just in PDF format and will be expanded to epub and mobi formats in the days to come. Readers of this alpha version get all the updates and have the opportunity to help us shape the direction of the book through their feedback, and to be credited as contributors. If you bought the 1.11 e-book in 2020 you'll receive an email on May 11th with a discount code covering the cost of the new edition. The book will also be printed, but for several reasons that won't happen until hopefully August of this year. When we get closer to that date we'll take pre-orders and send everyone who ordered an e-book a big discount … -
Two Scoops of Django 3.x Released
We just released the early release (alpha) of the fifth edition of our book, titled Two Scoops of Django 3.x. The 3.x means we are supporting Django 3.0, 3.1, and 3.2 Long Term Support (LTS) releases, ensuring the content will be valid until April of 2024. So long as it is May 11, 2020, anywhere on planet Earth, the e-book version sells for just US$42.95! On May 12th, 2020, the price goes up to $49.95. Hurry up and get your book! For now, the e-book is just in PDF format and will be expanded to epub and mobi formats in the days to come. Readers of this alpha version get all the updates and have the opportunity to help us shape the direction of the book through their feedback, and to be credited as contributors. If you bought the 1.11 e-book in 2020 you'll receive an email on May 11th with a discount code covering the cost of the new edition. The book will also be printed, but for several reasons that won't happen until hopefully August of this year. When we get closer to that date we'll take pre-orders and send everyone who ordered an e-book a big discount … -
How To Use Forms
Full show notes are available at https://www.mattlayman.com/django-riffs/5. -
Two Scoops of Django3.x Released!
We just released the early release (alpha) of the fifth edition of our book, titled Two Scoops of Django 3.x. The 3.x means we are supporting Django 3.0, 3.1, and 3.2 Long Term Support (LTS) releases, ensuring the content will be valid until April of 2024. So long as it is May 11, 2020 anywhere on planet Earth, the e-book version sells for just US$42.95! On May 12th, 2020, the price goes up to $49.95. Hurry up and get your book! For now, the e-book is just in PDF format and will be expanded to epub and mobi formats in the days to come. Readers of this alpha version get all the updates and have the opportunity to help us shape the direction of the book through their feedback, and to be credited as contributors. If you bought the 1.11 e-book in 2020 you'll receive an email on May 11th with a discount code covering the cost of the new edition. The book will also be printed, but for several reasons that won't happen until hopefully August of this year. When we get closer to that date we'll take pre-orders and send everyone who ordered an e-book a big discount … -
Episode 5 - How To Use Forms
On this episode, we will learn about HTML forms and Django’s form system to use when collecting input from users. Listen at djangoriffs.com. Last Episode On the previous episode, we looked at templates, the primary tool that Django provides to build user interfaces in your Django app. Web Forms 101 HTML can describe the type of data that you may want your users to send to your site. Collecting this data is done with a handful of tags.
