{"id":286,"date":"2025-01-20T10:00:00","date_gmt":"2025-01-20T16:00:00","guid":{"rendered":"https:\/\/douglasstarnes.dev\/?p=286"},"modified":"2025-01-15T12:42:21","modified_gmt":"2025-01-15T18:42:21","slug":"building-a-countdown-application-with-python-django-azure-and-github-1","status":"publish","type":"post","link":"https:\/\/douglasstarnes.dev\/index.php\/2025\/01\/20\/building-a-countdown-application-with-python-django-azure-and-github-1\/","title":{"rendered":"Building a Countdown Application with Python, Django, Azure and GitHub – (1)"},"content":{"rendered":"\n

In this series we will build a web application that counts down the number of days to events. We will use Django to write the application and Python since Django is implemented using Python. The application and database will eventually be hosted on Microsoft Azure. More specifically, Azure Container Apps will host the application and Azure Database for PostgreSQL Flexible servers will be used to serve a database. And we will use several services from GitHub: Repositories for source control, Actions for CI\/CD and Codespaces for a development environment.<\/p>\n\n\n\n

GitHub Codespaces<\/h3>\n\n\n\n

We will use GitHub Codespaces for the development environment. GitHub Codespaces is Visual Studio Code running in the browser, backed by a Linux compute instance. This means that many applications can be developed on GitHub Codespaces and all you need is a web browser and a network connection! Mobile and desktop applications don’t work so well as GitHub Codespaces does not provide a virtual desktop. But web, command line, data science and other applications work just fine. Thus, a lot of what you will see in this series on GitHub Codespaces will transfer to Visual Studio Code on the desktop with little if any friction. The extensions you use on GitHub Codespaces will work on Visual Studio Code on the desktop. The keyboard shortcuts are also the same. If you are using WSL, macOS or a Linux like compute the command line will work the same. You can even connect remotely to a Codespace from Visual Studio Code. It’s like having the best of both worlds!<\/p>\n\n\n\n

Now, because GitHub Codespaces uses compute in the Microsoft cloud, it’s not entirely free. However, you can use it for free, for up to 60 hours per month. That’s an average of 2 hours per day which is enough time to experiment with. All you need is a personal GitHub account which you likely already have and is free. You don’t even have to provide a credit card or payment info. I’ll be using a free GitHub account to write the demo application. In order to conserve your free quota, GitHub Codespaces time out after they have been idling. By default, the time out length is 30 minutes. You can set this anywhere from 5 minutes to 4 hours. I find 5 minutes to be rather limiting so I usually have mine set to 10 minutes. I’ll show you how set the time out but first we need to create a new Codespace.<\/p>\n\n\n\n

Go to https:\/\/github.com\/codespaces in a browser. <\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

Here you can create a new Codespace from a template or manage existing Codespaces. For this application, we will start from scratch by clicking the Use this template<\/strong> button for the Blank <\/strong>template.<\/p>\n\n\n\n

After a minute or less, you’ll see a brand new GitHub Codespace in a new tab.<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

Again, if you’ve used Visual Studio Code on the desktop, this interface will not be a surprise.<\/p>\n\n\n\n

Before moving on, let’s see how to save your free hours by setting a time out interval. Go back to the tabs where you created the Codespace. In the upper right, click your profile picture to open the menu and then click Settings<\/strong>. <\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

In the settings, under Code, planning and automation<\/strong>, click Codespaces<\/strong>.<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

In the next screen, scroll down to Default idle timeout<\/strong>, change the value to between 5 and 240 minutes (4 hours) and click the Save <\/strong>button.<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

Return to the tab with the Codespace and continue the setup.<\/p>\n\n\n\n

Configuring the Development Environment<\/h3>\n\n\n\n

To get started, we need to install a few extensions. Click on the icon for the Extensions panel in the sidebar.<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

In the search box at the top of the Extensions panel, search for python<\/em>.<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

The first result, Python by Microsoft is what we want. This provides lots of features useful for developing Python applications including syntax highlighting, automatic indentation, code hints, debugging and virtual environment support. Click the green Install <\/strong>button to install the extension.<\/p>\n\n\n\n

While the Python extension is installing, search for ruff <\/em>in the Extensions panel. Install the extension from Astral Software. Ruff is a Python linter and formatter. And do the same for sqlite viewer<\/em> and install the extension from Florian Klampfer.<\/p>\n\n\n\n

We’ll install more extensions for other features as we progress through the series but for now these will be enough.<\/p>\n\n\n\n

Now you’re going to configure some of the settings of Visual Studio Code. Press the F1 key to open the command palette. Search for and select Preferences: Open Settings (UI)<\/strong>.<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

The default font sizes are a little small for my preferences, and for the screenshots so I’m going to make them a little bigger. In the Search settings field, search for editor font size<\/em> and change the size from the default to 20. Do the same thing for terminal font size<\/em>. Notice that a brown bar appears to the left of the changed settings.<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

Search for format <\/em>in the Settings. Click the dropdown in Editor: Default Formatter and select Ruff charliemarsh.ruff.<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

And check the boxes for Editor: Format On Paste and Editor: Format On Save to run Ruff when Python code is pasted or Python files are saved.<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

Starting the Django Project<\/h3>\n\n\n\n

At this point we could create a virtual environment. However, I don’t usually do this with working in a GitHub Codespace. A Codespace is generally tied to a single GitHub Repository and one repository is generally going to contain a single project or at least several projects with the same requirements. At least that’s have I’ve used them. So I won’t be making a virtual environment. On Visual Studio Code for the desktop, where you will have many projects with different dependencies, I would use a virtual environment for each one.<\/p>\n\n\n\n

Django is distributed as a Python package. Therefore it can be installed with pip<\/code>. To keeps things manageable, we’ll create a requirements.txt file and install the dependencies from there. Open a folder for the project and inside create a new file named requirements.txt<\/code>. Place the names and optionally version numbers of the packages you wish to install.<\/p>\n\n\n\n

Django<\/code><\/pre>\n\n\n\n
The requirements.txt<\/code> file will be distributed as part of the project so that later on, we can install the dependencies again.  To install the package from the requirements.txt<\/code> file, use pip<\/code> with the -r<\/code> option passing it the name of the requirements file.<\/p>\n\n\n\n
<\/circle><\/circle><\/circle><\/g><\/svg><\/span><\/path><\/path><\/svg><\/span>
$<\/span> <\/span>pip<\/span> <\/span>install<\/span> <\/span>-r<\/span> <\/span>requirements.txt<\/span><\/span><\/code><\/pre><\/div>\n\n\n\n
This will install Django and its dependencies.  As part of the Django package, a utility named django-admin<\/code> has been installed and is the starting point for a new Django project.<\/p>\n\n\n\n
Throughout this series, you will be the phrase Django project <\/em>and Django app<\/em>. While you might think they mean the same thing, Django treats them differently. A Django project is a container for a web application build using Django. A Django app is actually a way of organizing your Django project into manageable and reusable features. For example, you could implement an e-commerce web application as a Django project. Then the project might include Django apps for a catalog, shopping cart, user management and so on.<\/p><\/blockquote><\/figure>\n\n\n\n
Press Ctrl-`<\/strong> to open the integrated terminal panel.  Run the django-admin<\/code> utility, with the startproject <\/code>command. The startproject<\/code> command accepts two arguments. First is the name of the project, I’ll call mine countdown. Second is an optional folder. If this argument is omitted, the project will be placed in a new folder with the same name as the project. I find this to be unendingly redundant so I like to place the project in the folder the command is run from. So I will provide a dot for the location.<\/p>\n\n\n\n
<\/circle><\/circle><\/circle><\/g><\/svg><\/span><\/path><\/path><\/svg><\/span>
$<\/span> <\/span>django-admin<\/span> <\/span>startproject<\/span> <\/span>countdown<\/span> <\/span>.<\/span><\/span><\/code><\/pre><\/div>\n\n\n\n
You will notice that two items have been created. First is a folder with the same name as the project, countdown<\/code>, but this is not the same as if a location was omitted. That would have put the two items you see in a new folder with the project name. Having those two folders with the same name to me can be confusing. The second is a file named manage.py.<\/code> We will be making extensive use of this file as we develop the the countdown application in the series.<\/p>\n\n\n\n
\"\"<\/figure>\n\n\n\n
You now have a Django project that implements a web application that you can run using the development server.  And you use the manage.py<\/code> file, with the runserver <\/code>command, to start the development server.  Run the server from inside of the terminal panel.<\/p>\n\n\n\n
<\/circle><\/circle><\/circle><\/g><\/svg><\/span><\/path><\/path><\/svg><\/span>
$<\/span> <\/span>python<\/span> <\/span>manage.py<\/span> <\/span>runserver<\/span><\/span><\/code><\/pre><\/div>\n\n\n\n
You’ll see some errors in red about unapplied migrations.  You can ignore those for now.  We’ll resolve the error when we start to work with databases in a future post.  The development server will start and listen on the localhost address (127.0.0.1) and port 8000.  And if you are running on Visual Studio Code on the desktop, you can open a browser and go to http:\/\/127.0.0.1:8000\/ and see the default page for a new Django project.  But what if you are running on a GitHub Codespace?  The localhost address is referred to a server somewhere in the Microsoft cloud.  So how do you view the Django project running on a Codespace?  You may have noticed this popup in the lower right corner of the Codespace.<\/p>\n\n\n\n
\"\"<\/figure>\n\n\n\n
It tells us that the GitHub Codespace has forwarded port 8000 to a URL generated by the GitHub Codespace.  Click the Open in Browser<\/strong> button, and the generated URL will open in a new tab.<\/p>\n\n\n\n
\"\"<\/figure>\n\n\n\n
This URL is only for development and by default, it is only accessible by you (notice the Make Public <\/strong>button on the popup).  However, it’s a great alternative to configuring it yourself.  Regardless, you should see the default Django home page pictured above.<\/p>\n\n\n\n
Summary<\/h3>\n\n\n\n
In this post you learned about GitHub Codespaces.  You created a Codespace, configured it to save your free hours, and installed several extensions to help with Python application development.  You also installed the Django package and created your first Django project.  You saw how to run the Django development server and learned how port forwarding works in a GitHub Codespace so you can view the web application during development.<\/p>\n","protected":false},"excerpt":{"rendered":"
In this series we will build a web application that counts down the number of…<\/p>\n","protected":false},"author":1,"featured_media":309,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[35],"tags":[38,36,37,4,24],"class_list":["post-286","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-django","tag-codespaces","tag-django","tag-github","tag-python","tag-vscode"],"_links":{"self":[{"href":"https:\/\/douglasstarnes.dev\/index.php\/wp-json\/wp\/v2\/posts\/286","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/douglasstarnes.dev\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/douglasstarnes.dev\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/douglasstarnes.dev\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/douglasstarnes.dev\/index.php\/wp-json\/wp\/v2\/comments?post=286"}],"version-history":[{"count":5,"href":"https:\/\/douglasstarnes.dev\/index.php\/wp-json\/wp\/v2\/posts\/286\/revisions"}],"predecessor-version":[{"id":310,"href":"https:\/\/douglasstarnes.dev\/index.php\/wp-json\/wp\/v2\/posts\/286\/revisions\/310"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/douglasstarnes.dev\/index.php\/wp-json\/wp\/v2\/media\/309"}],"wp:attachment":[{"href":"https:\/\/douglasstarnes.dev\/index.php\/wp-json\/wp\/v2\/media?parent=286"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/douglasstarnes.dev\/index.php\/wp-json\/wp\/v2\/categories?post=286"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/douglasstarnes.dev\/index.php\/wp-json\/wp\/v2\/tags?post=286"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}