DEV Community: Rasul Kireev

Linux Laptops in 2025: A Developer's Guide to Hardware, Distros, and Making the Switch

Rasul Kireev — Mon, 23 Jun 2025 16:26:09 +0000

As Intel-based Macs approach their final supported macOS version, many developers are evaluating Linux as a primary operating system for their laptops. The landscape for Linux on laptops in 2025 appears mature and promising, though not without its considerations.

Hardware: The Foundation of Your Linux Experience

Hardware compatibility remains a pivotal factor. While many users report flawless experiences, particularly with slightly older or well-supported hardware like Lenovo's Yoga series (even recent models with 12th Gen Intel CPUs), caution is advised for the newest, most specialized components. Features such as Apple's XDR-quality displays or highly nuanced touchpad gestures might not have perfect support out-of-the-box on all Linux distributions. Investing time in researching specific laptop models and their Linux compatibility is highly recommended.

For those seeking a more guaranteed experience, several vendors specialize in Linux laptops:

System76: Known for powerful machines, even offering configurations with high-end GPUs like the RTX 5090, and they develop their own Ubuntu-based Pop!_OS.
Framework: Offers modular, repairable laptops with good Linux support, appealing to users who value sustainability and customization. Arch Linux is a common choice for these.
Tuxedo Computers: A strong option for users in the EU, providing a range of Linux-preinstalled laptops.

Even Chromebooks can be repurposed by installing most mainstream Linux distributions.

Navigating the World of Distributions and Desktops

The sheer number of Linux distributions can seem overwhelming, but it also offers unparalleled choice. For developers accustomed to macOS or Windows:

Debian with KDE Plasma: Some users find KDE Plasma, running on a stable base like Debian, offers a more familiar experience, particularly regarding text anti-aliasing (similar to ClearType) and traditional taskbar setups. This combination is often praised for its stability and speed, even on older hardware.
Fedora Silverblue: An increasingly popular choice, offering an immutable OS design for enhanced stability and reliability. It often ships with GNOME, which can be customized.
Ubuntu and Pop!_OS: Frequently recommended for users new to Linux due to their large communities, ease of use, and broad hardware support.
Arch Linux: Favored by users who want deep customization and a rolling-release model, though it requires a more hands-on approach to installation and maintenance.

Desktop environments like GNOME and KDE Plasma are the most common, with user preference often boiling down to workflow, aesthetics, and specific features like text rendering. Some users find GNOME's default text rendering less ideal compared to KDE or Windows.

The Developer's Playground

For software development, Linux is widely regarded as an excellent platform. It supports a vast array of tools, from classic command-line editors like Emacs and Vim to modern IDEs such as VS Code (or its open-source version, VSCodium), Sublime Text, IntelliJ IDEA, and Zed. The transition for developers is generally smooth, with many finding they don't miss their previous environments.

Overall Sentiment

The consensus is that Linux on laptops is not only viable but a strong contender, especially for developers. While initial setup and hardware choices require some attention, the benefits of stability, performance, customization, and the ability to revive older hardware make it an attractive option. Many have found long-term satisfaction and productivity using Linux on their laptops.

How to Prove Future Claims: A Guide to Cryptographic Foreshadowing

Rasul Kireev — Mon, 26 May 2025 14:18:12 +0000

A user on Hacker News posed an intriguing question: how can one foreshadow specific information and only reveal it at a future date, while also providing irrefutable proof that the information was recorded before its eventual public disclosure? This problem touches upon concepts of trust, verification, and the integrity of time-stamped data.

The discussion yielded a practical and widely accepted cryptographic solution, detailed in a key comment. Here's a breakdown of the proposed method:

The Cryptographic Proof-of-Prior-Knowledge Method

The core idea revolves around using cryptographic hashes to create a "digital fingerprint" of your secret information, publishing this fingerprint publicly, and then revealing the original information later.

Prepare Your Document:
- Compile the information you wish to foreshadow into a digital document. This could be a text file, a PDF, or any other file format.
- Crucial Tip: The content of this document should be substantial. As the commenter noted, if the text is too short (e.g., a single sentence or a few words), it might be possible for someone to brute-force guess the content that produces the same hash, undermining your proof. Longer text makes this computationally infeasible.
Generate a Cryptographic Hash:
- Use a strong cryptographic hash function, like SHA256 (as suggested in the example Sha256 a9774a1a6ebf564cc408cfd86b5f2c06c13d830e143989714d958d34f325db13), to compute a unique hash sum of your document. This hash is a fixed-length string of characters that acts as a digital fingerprint. Even a tiny change in the document will result in a completely different hash.
Publish the Hash Publicly and Securely:
- This is the "foreshadowing" step. Publish the generated hash in a place that is:
  - Publicly accessible: So others can see it.
  - Timestamped: So there's a clear record of when it was published.
  - Immutable (or difficult to alter post-facto): To ensure the integrity of the timestamp.
- Examples of suitable platforms mentioned or implied by the discussion include:
  - Social media (e.g., Mastodon timeline, Reddit, Hacker News comments)
  - A public blockchain transaction (e.g., in an OP_RETURN field – though not explicitly mentioned, it fits the criteria)
  - An advertisement in a national printed newspaper (a traditional, but effective, method for a widely accepted timestamp).
- When publishing, include a clear statement, such as the example provided: “My prediction will be revealed on Dec 31 2025. Sha256 a9774a1a6ebf564cc408cfd86b5f2c06c13d830e143989714d958d34f325db13.”
Reveal the Original Document:
- On or after the specified future date, publish the original document you created in Step 1.
- Anyone can then independently download this document, calculate its SHA256 hash (or whichever algorithm was used), and compare it to the hash you published earlier. If the hashes match, it provides strong proof that the document (and its contents) existed in that exact form at the time the hash was originally published.

Why This Method Works

This technique leverages the fundamental properties of cryptographic hash functions:

Deterministic: The same input will always produce the same hash.
Pre-image resistance: It's computationally infeasible to find the original input (your document) given only its hash, especially for non-trivial documents.
Second pre-image resistance/Collision resistance: It's computationally infeasible to find a different document that produces the same hash.

By publishing the hash first, you commit to the content without revealing it. The public, timestamped nature of the hash publication prevents you from changing the document later and claiming it was the original. This method offers a robust way to foreshadow events, make sealed predictions, or establish prior art for an idea, ensuring that when the time comes for the reveal, you have verifiable proof of when your information was first recorded.

The Hidden Secret to Get the Job of Your Dreams

Rasul Kireev — Tue, 29 Apr 2025 10:06:00 +0000

Want to stand out?

Video introductions are your secret weapon in today's competitive tech job market. They offer a personal touch that resumes simply can't match. This article will show you how to craft a compelling video intro and leverage gettjalerts.com to find the perfect email addresses to send it to.

1. Craft a Killer Video Intro

Your video intro is your first impression. Make it count!

Keep it concise: Aim for 30-60 seconds. Recruiters are busy.
Highlight key skills: Focus on skills relevant to the specific job. Tailor your message!
Show your personality: Let your enthusiasm shine through. Be authentic.
End with a call to action: Encourage them to view your resume or portfolio.

I once helped a junior developer land a coveted role at a startup by suggesting he create a short video showcasing his coding projects. He got the job because the hiring manager was impressed by his initiative and personality.

Practical Application: Script your video, practice your delivery, and record in a well-lit, quiet environment. Use a professional tone.

2. Find the Right Email Addresses with gettjalerts.com

Sending your video to the right person is crucial.

Use gettjalerts.com to find tech companies that are hiring. Check out the Companies that are hiring right now page.
Identify relevant job postings. Explore the Available Jobs - March 2025 to find opportunities that align with your skills.
Research company websites and LinkedIn. Look for hiring managers or recruiters in the specific department you're targeting.

gettjalerts.com can help you discover companies and job titles that are in demand. For example, check out the Tech Job Titles that are in demand right now page to see what roles are trending.

I remember struggling to find the right contact information when I was applying for jobs. Using a tool like gettjalerts.com would have saved me so much time and effort.

Practical Application: Combine gettjalerts.com with LinkedIn to build a targeted list of email addresses for your video intro.

3. Follow Up Strategically

Don't just send your video and hope for the best.

Personalize your email: Reference something specific about the company or role.
Keep it brief: Reiterate your key skills and express your enthusiasm.
Follow up within a week: A gentle reminder can make all the difference.

I once received a follow-up email from a candidate that included a personalized video response to a question I had asked in the initial interview. It showed me that he was truly engaged and interested in the role.

Practical Application: Track your emails and follow-up consistently. Persistence pays off.

Conclusion

A video introduction can be a game-changer in your tech job search. By crafting a compelling video and using gettjalerts.com to find the right email addresses, you can significantly increase your chances of landing your dream job.

Ready to take your job search to the next level? Head over to gettjalerts.com and start exploring the latest tech job opportunities. What are you waiting for?

Create Smarter & Better Git Commits with AI

Rasul Kireev — Fri, 07 Feb 2025 07:53:47 +0000

How many times have you stared at your terminal, trying to craft the perfect git commit message? Probably not much.

I know what you have done often though...

git add --all
git commit -m "fix"
git push

If you are a super lazy person like, me you maybe even created a git alias for that and only have to do:

git cm "fix"
gp

Today I decided to change this forever. I decided to be the most thoughtful person in he world and think about my future self an anyone who is going to search for my code in the future...

Enter commit.

🙏 The Script

#!/bin/bash

check_git_repo() {
    if ! git rev-parse --is-inside-work-tree >/dev/null 2>&1; then
        exit 1
    fi
}

check_changes() {
    if [ -z "$(git status --porcelain)" ]; then
        exit 0
    fi
}

generate_commit_message() {
    local diff_content=$(git diff --cached)
    local files_changed=$(git status --porcelain)

    echo -e "Files changed:\n$files_changed\n\nChanges:\n$diff_content" | \
        llm -m anthropic/claude-3-5-sonnet-latest \
        "Generate a git commit message for these changes. The message must have:

        1. TITLE LINE: A specific, concise summary (max 50 chars) that clearly
           describes the primary change or feature. This should not be generic like
           'Update files' but rather describe the actual change like 'Add user
           authentication to API endpoints'

        2. BLANK LINE

        3. DETAILED DESCRIPTION: A thorough explanation including:
           - What changes were made
           - Why they were necessary
           - Any important technical details
           - Breaking changes or important notes
           Wrap this at 72 chars.

        IMPORTANT:
        - Output ONLY the commit message
        - Make sure the title is specific to these changes
        - Focus on the what and why, not just the how"
}

# Main execution
main() {
    check_git_repo
    check_changes
    git add --all
    commit_message=$(generate_commit_message)
    git commit -m "$commit_message"
}

main "$@"

⚒️ Breaking it Down

Repository Validation

check_git_repo() {
    if ! git rev-parse --is-inside-work-tree >/dev/null 2>&1; then
        exit 1
    fi
}

This function ensures we're working within a git repository.

Change Detection

check_changes() {
    if [ -z "$(git status --porcelain)" ]; then
        exit 0
    fi
}

Verifies that there are actually changes to commit.

AI-Powered Message Generation

generate_commit_message() {
    local diff_content=$(git diff --cached)
    local files_changed=$(git status --porcelain)

    echo -e "Files changed:\n$files_changed\n\nChanges:\n$diff_content" | \
        llm -m anthropic/claude-3-5-sonnet-latest \
        "Generate a git commit message for these changes. The message must have:

        1. TITLE LINE: A specific, concise summary (max 50 chars) that clearly
           describes the primary change or feature. This should not be generic like
           'Update files' but rather describe the actual change like 'Add user
           authentication to API endpoints'

        2. BLANK LINE

        3. DETAILED DESCRIPTION: A thorough explanation including:
           - What changes were made
           - Why they were necessary
           - Any important technical details
           - Breaking changes or important notes
           Wrap this at 72 chars.

        IMPORTANT:
        - Output ONLY the commit message
        - Make sure the title is specific to these changes
        - Focus on the what and why, not just the how"
}

This is where the magic happens - the script analyzes your changes and uses AI to generate a meaningful commit message.

The script uses Simon Willison's llm command-line tool, which is an incredibly useful utility for interacting with various AI models directly from your terminal. Head over to his documentation to learn more about it. How to set it up and actually use it.

Please note that I use anthropic's model in this script, which means you will have to set up the llm-anthropic plugin.

💻 Setting it up

To run this, just create a commit file and add it your bin directory, such that it ends up in you PATH.

Don't forget to run

chmod +x ~/.local/bin/commit

to make the script executable. Of course, update the path to the script depending on where you save it.

🎉 Yay

Now after working hard on your code you'll just have to run commit and you'll get a commit message generated by AI.

Django Codebase Updates: January 2025

Rasul Kireev — Fri, 07 Feb 2025 07:52:04 +0000

Here's a structured summary of Django's development activity in January 2025:

Overview

The month showed significant development activity with 90 commits focusing on several major themes:

Extensive work on composite primary key support and validation
Bug fixes and improvements for database operations
Documentation updates and cleanup
Security and dependency updates
Test suite improvements and optimization

Key Changes and Features

Major Features

Added automatic model imports to Django shell command, a GSoC 2024 project (by Salvo Polizzi - commit)
Implemented double squashing of migrations capability (by Georgi Yanchev - commit)
Added ability to customize admin password change form (by Mohammadreza Eskandari - commit)

Composite Primary Key Improvements

Added serialization support for composite primary keys (by Sarah Boyce - commit)
Fixed password reset functionality with composite primary keys (by Sarah Boyce - commit)
Added validation for non-local fields in composite primary keys (by Bendeguz Csirmaz - commit)

Bug Fixes

Fixed UnicodeEncodeError in email attachments (by greg - commit)
Fixed bulk_update handling with multiple primary keys (by Sarah Boyce - commit)
Fixed RecursionError in FilteredRelation joins (by Peter DeVita - commit)

Security and Dependencies

Updated minimum supported package versions for Python 3.12 compatibility (by Mariusz Felisiak - commit)
Added documentation for security vulnerability CVE-2024-56374 (by Natalia - commit)

Development Patterns and Contributors

Active Contributors: Sarah Boyce, Simon Charette, Jacob Walls, and Mariusz Felisiak were particularly active
Focus Areas: Strong emphasis on improving composite primary key support and fixing related edge cases
Testing: Significant attention to test coverage with many commits including comprehensive test additions
Documentation: Consistent updates to maintain accuracy and clarity of documentation

Recommendations

Developers should review the new composite primary key functionality carefully as it represents a significant change
Projects planning to upgrade should pay attention to the new minimum package version requirements for Python 3.12 compatibility
Teams using Django's admin interface should evaluate the new password change form customization capabilities
Consider using the new automatic model imports feature in Django shell for improved developer experience

The month showed strong progress in both feature development and stability improvements, with particular attention to composite primary key support and developer experience enhancements.

7 Simple Ways to Create Blog Posts That Actually Rank in Google

Rasul Kireev — Tue, 03 Dec 2024 09:44:04 +0000

Creating blog content that ranks well in Google isn't just about writing great content anymore. With over 7 million blog posts published daily, you need a strategic approach to stand out and reach your target audience. In this guide, we'll explore seven proven methods to create blog posts that actually climb the search rankings.

1. Start with Solid Keyword Research

Before writing a single word, understand what your audience is searching for:

Use keyword research tools to identify relevant search terms
Focus on long-tail keywords with manageable competition
Analyze search intent behind your target keywords
Consider keyword difficulty and monthly search volume

2. Optimize Your Content Structure

A well-structured post helps both readers and search engines understand your content:

Create clear, descriptive headings using H2 and H3 tags
Include your target keyword in the first 100 words
Write short, scannable paragraphs
Use bullet points and numbered lists for better readability

3. Create Comprehensive Content

Google favors content that thoroughly covers a topic:

Aim for detailed, in-depth articles (1,500+ words)
Cover all relevant aspects of your topic
Include supporting data and statistics
Address common questions your audience might have

4. Focus on User Experience

Engagement metrics matter for SEO:

Ensure fast loading times
Make content mobile-friendly
Use clear fonts and adequate spacing
Include relevant images and videos

5. Implement Technical SEO Best Practices

Don't overlook the technical aspects:

Optimize your meta title and description
Use proper header hierarchy
Include alt text for images
Create SEO-friendly URLs

6. Build Quality Backlinks

Backlinks remain a crucial ranking factor:

Create linkable assets (infographics, studies, tools)
Reach out to industry influencers
Guest post on relevant websites
Promote content through social media

7. Regular Content Updates

Keep your content fresh and relevant:

Update old posts with new information
Add recent statistics and examples
Remove outdated content
Monitor and improve based on performance

Putting It All Together

Creating content that ranks isn't a one-time effort. It requires consistent attention to both on-page and off-page factors. Tools like SEO Blog Bot can help streamline this process by:

Analyzing your website's current content performance
Suggesting relevant blog topics based on your niche
Generating SEO-optimized content structure
Providing keyword-rich content suggestions

Conclusion

Implementing these seven strategies will significantly improve your chances of ranking in Google. Remember, SEO is a marathon, not a sprint. Focus on creating valuable content for your audience while following these optimization techniques.

Ready to start creating content that ranks? Try SEO Blog Bot today and transform your content strategy with AI-powered SEO optimization.

Note: Stay consistent with your content creation efforts and regularly monitor your rankings to adjust your strategy as needed.

Improve your Django Code with pre-commit

Rasul Kireev — Wed, 05 Apr 2023 12:22:42 +0000

Update (04/01/2023): A kind reddit user by the name of lanemik suggested I give ruff a go. So i decided to add it to the guide.

In the previous tutorial we have finished styling our Authentication pages. Before we go any further I would like to introduce you to an awesome developer tool that will improve your code, a lot!

Meet pre-commit.

Pre-commit is a tool that allows you to automate the process of checking your code for errors and issues before committing it to your repository, hence the name.

In simple terms, it will help you catch bugs and errors. Not only that, but it will also be able to sort your imports based on PEP recommendation as well as lint your code for better readability.

In this guide, I will show you how to set it up, and then I will share my favorite hooks that I use in all my projects.

TL;DR

See all the code from this tutorial here
Install pre-commit
Create .pre-commit-config.yaml
Start adding hooks. Here are the ones I recommend:
- black
- isort
- flake8
- pylint
- djlint
- poetry export

Follow Along

Before we continue, I would like to mention that you can look at all the code that we wrote in this tutorial by looking into the pre-commit PR on the basic-django repo.

All the previous tutorials have been applied to that repo too. If you have any questions or concerns, feel free to leave a comment below or on the PR. I'll try to respond as soon as I see the comment.

Finally, last comment before we begin is that you are following the whole series that you should see the same results as I will. However, if you are using a different repo, or you have wrote more code, then the pre-commit messages that you will receive might be slightly different.

But don't worry, even if they are different, they should be clear and very actionable.

Pre-Commit

I am going to go through each step with you, but I encourage you to check out the official website. The instructions they have are very useful.

1. Install Pre-Commit

You can install it on your whole system (MacOS) with brew install pre-commit, but we are also going to add it to our project explicitly with by running poetry add --group dev pre-commit.

Please note, the --group dev, this will add the dependency to the dev section. This is useful because when we install libraries in the production setting those won't be installed, thus using less storage space and increasing installation/deployment steps.

Let's confirm that the library has been installed by running poetry run pre-commit --version. If you don't know what this poetry run stuff is, I recommend you check my Poetry guide.

2. Create a `pre-commit` Config File

Next, you will need to create a .pre-commit-config.yaml file in the root of your repository. This is where the magic happens. Once you create the file add the following text to it.

repos:
-   repo: https://github.com/pre-commit/pre-commit-hooks
    rev: v4.4.0
    hooks:
    -   id: check-yaml
    -   id: end-of-file-fixer
    -   id: trailing-whitespace

This file defines the pre-commit hooks that will be run. For example, in this specific case, we are using 3 hooks provided by pre-commit: check-yaml, end-of-file-fixer, trailing-whitespace.

This is the structure we are going to follow when we want to add new hooks. Under the repos array we will specify an object that has the following:

repo: the location of the hook (some libraries provide those hooks, but if one is not provided, we can write our own, we will do that later in that guide)
rev: this is the version/release of the repo you have specified. If you look at the pre-commit-hooks library you can see it in the releases section:
hooks: now to the actual hooks that will be used from that repo. Again, check the pre-commit-hook repo to see what hooks are available (there are maaany), maybe you'll find them useful.

These specific hooks are pretty self explanatory, so instead of describing each one of those, let's just run this and see what happens.

Please note, that if you are running it outside of your repo, it is not likely to do anything. You should set this up as part of some repo.

3. Install and Run your Hooks for the first time

Once you have created your config file, you need to install the hooks specified in the file. You can do this by running: poetry run pre-commit install

Once this command is done, run poetry run pre-commit run --all-files which will run these hooks against your repo. You should see something like this:

So, what happened is that pre-commit checked all the files in the library and "fixed" them based on the hooks you have set up.

!!! danger "!! Warning !!"
These first checks are harmless, so there is no worry about running them with --all-file.

However, later we will start adding hooks that format your code. If you have a large codebase, I don't recommend you run the `pre-commit run --all-files`, since that will affect a lot of the code. 

Instead, you may want to start testing that the new hooks are working by running on one file at a time like so `pre-commit run --files YOUR_FILENAME`.

If you would still prefer to "fix" the whole codebase, I will recommend you do it slowly, step, by step, like I do in this tutorial.

4. Use Pre-Commit

In the future you will not be using poetry run pre-commit run --all-files, instead pre-commit will automatically on all the files that you are committing to your repo.

Here is the general workflow that will now happen:

You work on a feature for your website and have changed a bunch of files.
You run git add --all (doesn't have to be --all you could add files one by one, whatever is your preference)
Then, you will run git commit -m "adding new feature". At that stage pre-commit starts. If all the checks have Passed, then the commit will go through and you can then run git push. If, on the other hand, at least one check fails commit will not go through.
Depending on your set up (which we will discuss later) either of the two things will happen.
1. pre-commit have fixed those mistakes automatically (like in the example above we saw pre-commit say that a number of files have been "fixed")
2. pre-commit won't fix mistakes, but will point you towards where those foxes are, so that you can fix them yourself.
In either case once the fixes are done, you want to re-add the fixed versions of the file with git add --all and re-try running the git commit -m "adding new feature". This time, if all things have been fixed the commit will go through.

I know that this can sound a little tedious or slow. But once you go through this a couple of times, you will realize how quick, easy and useful this is.

Good Hooks to Use

Now that the setup is done, let go through some of my favorite hooks that I use in almost all my projects. The first three you have already seen, I do use them everywhere.

Black

Black is a Python code formatter. This means that when this hook will run, all the files that you want to commit will be checked for any inconsistencies and bad styling (based on PEP 8 standard). This hook will automatically fix those issues.

Before we add this hook, let's do something first. Add exclude: ^migrations/ to the top of your pre-commit config file. So that it will look like this:

# .pre-commit-config.yaml
exclude: .*migrations\/.*
repos:
-   repo: 
...

This will make sure that the files that Django migration generates are not touched. You don't have to do that. I, personally, I think it makes sense not to touch files that are autogenerated by Django.

Alright, now that this is out of the way, let's add black to pre-commit. All you have to do is add the following lines to the pre-commit config file, right after the first "repo":

exclude: .*migrations\/.*
repos:
- repo: https://github.com/pre-commit/pre-commit-hooks
...
- repo: https://github.com/psf/black
  rev: 22.12.0
  hooks:
  - id: black
    language_version: python3.9

Keep in mind that at the time that you are reading, black might have a newer version available. You should go to the repo and check the latest available version (just like described above).

Another thing to keep in mind is that you should change the language version depending on what you are targeting. For example, when setting up the basic-django repo we specified that this project will be version 3.9.

!!! note "Optional"
If you are using poetry in your project, like I described in a previous post you can also add another layer of configuration. In you pyproject.toml file you can add the following block:

[tool.black]
line-length = 120
target-version = ['py39']
include = '\.pyi?$'

!!! note "Optional, continued"
Black will you these configurations when being ran by pre-commit. To see the full list of available configurations, check out the official docs page.

Once you've added it, you can test by running poetry run pre-commit run --all-files.

You should see something like this:

If you do, congratulations!!! 8 files were formatted to adhere to the PEP-8 standard 🤘

If something went wrong, please comment below, I'll take a look ASAP.

We can move on to other hooks.

isort

isort is an awesome tool that will sort imports across your repo.

You know the drill. Let's add this hook to the pre-commit config file. It will look like so:

repos:
... pre-commmit stuff
... black stuff
 - repo: https://github.com/pycqa/isort 
   rev: 5.12.0 
   hooks: 
     - id: isort 
       name: isort (python)

And optionally, but very much recommended add these configurations to the pyproject.toml file:

[tool.isort]
profile = "django"
combine_as_imports = true
include_trailing_comma = true
line_length = 120

Let's go over at what these do.

isort has profiles, which let you choose what type of repo you have. This will slightly change the behaviour of the check.
The next too are something that isort recommends for the django profile. combine_as_imports will that imports with as statement are combined and the include_trailing_comma will keep the comma after the last import in a statement that imports multiple items.
Next is the line length, which is important. I ran into this problem a few times. Make sure that this number is the same as the one configure in black. If that is not the case, often times, these two will conflict with each other, correcting each others behavior.

Let's try running pre-commit again with poetry run pre-commit run --all-files. You should see something like this:

Please note,that black passed the test, since we habe already run it before, which is cool. Also, interesting to see the fix end of files hook being triggered. Probably I added extra line in the pre-commit config file. Finally I can see that 2 files have been fixed by isort, awesome.

Let's move on!

flake8

flake8 is yet another awesome tool that will help you check the style and quality of some python code.

This one is going to be a liiiitle bit different. Instead configuring the behaviour in the pyproject.toml file like before we will create a separate file for it.

But first, let's add to the pre-commit file first. As before check the latest version that is available in the github repo.

...
- repo: https://github.com/pycqa/flake8
  rev: 6.0.0
  hooks:
    - id: flake8

Note create a .flake8 file at the root of your repository and add the following to it:

[flake8]
max-line-length=120

Now, let's try running it with poetry run pre-commit run --all-files. Here is what I got:

Awesome. Couple of things to note.

First, I did not talk about this before, but you can see in the first lines where pre-commit is setting up the environment for flake8 (essentially checking if the hooks exist). If something went wrong at this stage, then it is likely that you entered url incorrect or that you added a non-existent version.

Second, is that this plugin doesn't update the file for us. It just tells us what is currently wrong so that I can go and fix it myself before committing the new code, which is fantastic. Let's do exactly that.

First, it doesn't like that the HTML string in the utils.py file is too long. Black did not make it smaller, because it doesn't know how to operate on strings. There are two approaches we can take:

Fix the line length by breaking up the svg code into multiple lines.
Tell flake that this exact case is fine.

I'm going to opt for #2, since I don't care about the readability of the svg tag (no one actually "inspects" those). Plus, would be good to show how to tell packages to ignore some lines.

I'm going to put the following comment # noqa: E501 on lines 16 and 17. The E501 comes from the message in the terminal. Same for the lines, flake8 tells me which lines are affected. After adding this comment to both lines, let's rerun the pre-commit command.

Et Voila! This specific message is gone. Now let's fix others. Looks like it is about unused imports. That should be easy to fix. Let's remove those import and rerun.

Hooray! Let's move on to pylint.

pylint

pylint is a linter and a static code analyzer just like flake8. It will check your code for any formatting issue as well as any performance issues. The difference is that pylint is a little more thorough and more customizable.

I feel like those two complement each other. You don't have to set both of them up, but I sleep better when I know that two unrelated programs checked my code 🤣

Set up for pylint is a little different. Here is a quote from the official docs:

Since pylint needs to import modules and dependencies to work correctly, the hook only works with a local installation of pylint (in your environment).

So, we need to install pylint into our repo with poetry add --group dev pylint.

Once pylint was installed we will need to tell pre-commit to use that specific version. Again, let's check the docs for that. They recommend we do it that way (I removed a couple of args):

...
- repo: local
  hooks:
    - id: pylint
      name: pylint
      entry: poetry run pylint
      language: system
      types: [python]
      args:
        [
          "-rn", # Only display messages
          "-sn", # Don't display the score
        ]

Note the change I made on the entry line. Instead of running pylint, we are telling pre-commit to run poetry run pylint, since that is the preferred way to invoke packages installed with poetry.

One last thing to do before running the hooks is to create a config file, just like we did with flake8. For this you are going to create a pylintrc file at the roor of your project and copy the contents of the pylintrc file from the pylint repo (here is the link to it).

These are the recommended setting for pylint that we can configure in the future if we want.

Let's run poetry run pre-commit run --all-files to see what happens.

Here is what I got.

Good, that means it's working. Before going further, I would like to show you another cool feature of pylint. Extensions.

There is a Django extension that we can install and apply to the pylint check. Let's do that.

Install with poetry add --group dev pylint-django. And add the 2 new lines to the args list, like so:

...
      args:
        [
          "-rn",
          "-sn",
          "--load-plugins=pylint_django", # new
          "--django-settings-module={NAME OF YOUR REPO}.settings", # new
        ]

Let's run poetry run pre-commit run --all-files once again, to make sure everything is working correctly.

Looks like pylint found the same 3 errors. I'm not going to go over them one by one, since they are very detailed, and more importantly, you might be seeing something else.

The only note I'll make is that I will add

--ignore=manage.py

to the list of args, since this was generated by Django, and I don't want to lint that.

So, let's use the magic of reading and see what it looks like after I modified the code to the pylint's liking.

Nice. Another useful check added to the list.

I will tell you this... In my opinion, pylint is the hardest and the most annoying to setup and "please" in the future. However, it doesn't mean that you should do it. I think all (most) the error messages that it is showing are useful.

If you encounter those error, at setup or at commit don't worry. Spend some time trying to fix them, or googling about them. This will make you a better dev for sure.

Comment below, if something is not working for you. I'll try to help.

djlint

For Django users, which you presumably are, this will be a God send! Check out the repo. This is an HTML linter... but for Django templates 🤯

It will look for errors and inconsistencies in your HTML files. The setup for this one is straightforward.

Add this to the pre-commit-config file:

- repo: https://github.com/Riverside-Healthcare/djLint
  rev: v1.19.16
  hooks:
    - id: djlint-django

Also, I will add the following conf to the pyproject.toml file:

[tool.djlint]
profile="django"

For all the conf options, check out the official docs

One thing to note is that I would recommend you put this "repo", before the "local" one. It is preferable to keep the "local" one last. So, in our case we would add this one right after flake8 one.

And, as before make sure you are using the latest version. Let's give this a run with poetry run pre-commit run --all-files.

Oof, there is a lot to fix. Thankfully, errors are pretty clear.

I've included the following ignores to my conf file:

[tool.djlint]
profile="django"
ignore = "H031"

Added H031 because keywords meta is no longer used. Everything else, fixed.

poetry export

Final one that I like to use is the poetry export hook. It used to be the case that we needed to add this one to the local repo, but no longer.

This is useful if you don't want to install poetry on your prod server or in your Dockerfile. That is to say very useful.

Instead of dealing with poetry in Docker or prod we will just have a nice and fresh "requirements.txt" file to use for out dependencies. Beautiful.

To make this work add the following to your pre-commit config file. I put it right after the djlint hook.

- repo: https://github.com/python-poetry/poetry
  rev: '1.4.1'
  hooks:
    - id: poetry-export
      args: [
        "-f", "requirements.txt",
        "-o", "requirements.txt",
        "--without-hashes"
      ]

This one doesn't require any configurations ♥️. To see other poetry hooks, check out their docs.

ruff

A kind reddit user by the name of lanemik suggested I give ruff a go. I have heard of this tool before, but never actually gave it a go.

According to the README

Ruff can be used to replace Flake8 (plus dozens of plugins), isort, pydocstyle, yesqa, eradicate, pyupgrade, and autoflake, all while executing tens or hundreds of times faster than any individual tool.

I'm not going to replace isort and Flake8 for the purpose of this tutorial, but I will add ruff above those two to see it's performance.

Let's add the following block to the pre-commit config file:

- repo: https://github.com/charliermarsh/ruff-pre-commit
  rev: 'v0.0.260'
  hooks:
    - id: ruff

I will also add the following configuration to the pyproject.toml:

[tool.ruff]
line-length = 120

, but there are a ton of other things you can configure. Check out the README for that.

Now, let's run the poetry run pre-commit run --all-files and see what happens.

I got the same error as in the flake8 about the long HTML lines in the utils.py. The syntax for ignoring error is the same as in Flake8. The only difference is that here I had to add "# noqa: E501" at the end of a multi-line string, as opposed to the end the line. Once added at the end of the string I can remove noqa comments on lines 16 & 17. I personally think that looks nicer.

That's it. As easy as that.

Conclusion

Aaaah, it's hard to explain the joy I get from seeing all those "Passed" messages.

First of all, green is a nice color to look at.
Second, I get to sleep knowing that my code quality is safe 👍 which is useful both for team and individual projects.

In conclusion, here is what we did:

Install pre-commit as a dev dependency in you poetry project.
Installed a bunch of pre-commit hooks to the pre-commit config file.
Configured the behavior of new hooks through pyproject.toml configurations or through rc file configurations.

Can't believe it took more than 3000 words to go over these 3 bullet points 🤷‍♂️. If you made it to here, a salute you 🖖, you are an incredible human being with a ton of patience and focus! You will do good in life.

If you have any questions or comments, please them leave below.

How to Version Control your Django project

Rasul Kireev — Fri, 05 Aug 2022 00:00:00 +0000

In the previous post, we have gone through the process of setting up a basic Django project. In this post, we will be talking about version control and the best practices when it comes to Django projects.

TL;DR use the following .gitignore.

I'm not going to be teaching you git in this post. I'm going to assume that you have git installed on your computer and you have a Github account. If you haven't worked with git before I recommend you check out this post, it helped me when I was learning, but really there are a ton of other awesome posts.

However, that said, this post is aimed toward beginners when it comes to version controlling Django projects.

Why?

Why is it important to dedicate an entire post on how to version control your Django project?

When I was starting out I was just doing stuff and not using tutorials. I was silly, unlike you! I ended up putting secret information to the public. For example, I was using AWS to host images, and accidentally put my secret key on Github. I was contacted by the Amazon team and was told to delete it and immediately create a new one so that some bad actors would use it maliciously. I almost sh*t my pants. I don't want this to happen to you!

Another important point is that eventually (in the next post) we are going to be creating a SQLite database and storing user information on it. We don't want to expose that either.

So, now that you understand the importance of good practices when it comes to version control we can begin.

The good news is that it actually is not so hard.

Beginning of History

After you finished the previous post, you should have a functional code. Make sure everything works by running poetry run python manage.py runserver.

Let's start by creating a repo for your project on Github. If you head over to https://github.com/new you will be prompted for some info.

Give your repo a name and press "Create repository". No need to change anything else.

Tip: use kebab case for the name: something-like-that.

Once you've done that you will see a convenient list of instructions on Github:

We don't need the first line, since we already have some files.

We do however need to run git init in our terminal (hopefully in an integrated VS Code terminal) to start the version control history. Once you run git init you should see a couple of changes.

First is the terminal itself will show the branch you are on:

Second is the File Explorer, all files should have turned green meaning that they are new files in our repo, they haven't appeared before in our history. If files had existed but were changed, they would have turned yellow.

Ignoring secrets

Awesome! Now, before adding all our files to our repo history let's create a .gitignore file in which we will list all the files and folders that we don't want to end up in the history.

So, create .gitignore file at the root of your project. Copy the content from the following gist and paste it into the .gitignore file. Now files and folders that match the Regex in .gitignore, will not be version controlled.

You should care about most of them. Here are the important ones:

.env. We will be storing our secrets in this file, so we don't want them to end up on Github.
*.sqlite3. We don't want any database to end up on Github either.
node_modules/ this is where all Javascript packages will be stored, once we get there. node_modules/ are notoriously large directories, so we don't want them to be on Github as they will slow up all actions immensely.
media/ when we are going to work locally, some images that we will upload into our database will end up in the media folder. Since Github has some rules regarding how much space you can take, we don't want any images to end up there, as they tend to be heavy.
other than that you shouldn't worry too much about other things, at least for now.

Final Steps

Now we can run other commands provided by Github. In your terminal run:

git add --all to add all the files (except the ones in .gitignore) to version control history.
git commit -m "first commit", to "commit" the changes.
git branch -M main to rename the main branch. New standard.
git remote add origin git@github.com:{your username}/{your project name}.git. Use the command provided by Github.
Finally, run git push -u origin main

If you didn't run into any issues, then you can try reloading the Github page and seeing if the files have been added to the repo.

If all is good, then congratulations.

Conclusion

In this post, we have created a repo and committed our files to it. This will help us keep track of our code in future posts.

Originally posted on Built with Django

Setting up a basic Django project with Poetry

Rasul Kireev — Fri, 28 Jan 2022 16:58:12 +0000

In this tutorial, we will go through the process of setting up the most basic Django project that we will be using for other posts and tutorials.

We will be using Pyenv and Poetry to manage the virtual environment and dependencies for your project.

Unfortunately, some things that I'm going through don't work exactly the same for Windows users (e.g. Pyenv). So, if you are following on a Windows machine you might run into some issues. If you do, try messaging me on Twitter, I'll try to do my best to help you.

During this tutorial, it might seem like too many things are going on things are becoming confusing. I'll try to separate it into manageable chunks that are easy to understand. And don't worry, some of the things in this tutorial only have to be done once.

The method of setting up repos that I propose can differ from others, but I really enjoy it. It helps me keep all the versions and virtual environments neat and tidy, which reduces the amount errors and bugs in the future. And if you stay with me till the end of the tutorial, hopefully, I can convert you to a Poetry person too :).

So, let's get the party started.

Prerequisites

Pyenv

We are going to use brew to install Pyenv. If you don't have brew installed on your Mac, run the following command:

/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

now let's install pyenv:

brew update
brew install pyenv

If this didn't work for you try these fixes.
If you are on a Windows machine, follow the following instruction to install pyenv.
to test if this was installed correctly try running this in your terminal:

pyenv versions

we are going to be using Python version 3.9.9 in our tutorial, so let's get that installed with the following command:

pyenv install 3.9.9

Your terminal will start giving you some outputs. Wait for a minute or two until the download and installation are complete. This is everything we are going to cover regarding pyenv, we don't need to know more for the purposes of this tutorial.

Poetry

If you have Poetry installed you can skip this step.

So, let's first install Poetry. You can do that by running the following command in your terminal:

curl -sSL https://raw.githubusercontent.com/python-poetry/poetry/master/get-poetry.py | python -

If you are on Windows you would run the following in your Powershell:

(Invoke-WebRequest -Uri https://raw.githubusercontent.com/python-poetry/poetry/master/get-poetry.py -UseBasicParsing).Content | python -

The good news is that you have to do it once. To test that everything went smoothly, try running the following in your terminal:

poetry --version

Setting up the Environment

Alright, we are now ready to start. Here is what you want to do:

Open up your terminal, cd into the directory that you use to store all your code. For me it is:

cd ~/code

Then create a new directory for your project. I'm going to call mine "basic_django", but you can call it whatever else you want:

mkdir basic_django && cd basic_django

Now, I suggest you open up your VS Code and open your newly-created directory. Alternatively, you can run this command in your terminal:

code .

Let's use pyenv to explicitly say what Python version we will be using in that repo. For that, run the following in your terminal:

pyenv local 3.9.9

You should see a file named .python-version created in your folder. That's good.

Now were are going to initialize Poetry project with:

poetry init

You will be prompted to confirm a couple of settings. You can just skip the following:

Package name [basic_django]:
Version [0.1.0]:
Description []:
Author [Rasul Kireev <rasul.kireev@guycarp.com>, n to skip]:
License []:

When you get to the following line type in "^3.8" and press Enter:

Compatible Python versions [^3.7]: ^3.9

The reason we do that is that the latest Django version requires the use of Python Version 3.8 and up.

When you get to these prompts, type in "no". We are going to add our own dependencies later on:

Would you like to define your main dependencies interactively? (yes/no) [yes]

Would you like to define your development dependencies interactively? (yes/no) [yes]

In the end, you would have gone through the process that looked something like this:

This command will guide you through creating your pyproject.toml config.

Package name [basic_django]:
Version [0.1.0]:
Description []:
Author [Rasul Kireev <rasul.kireev@guycarp.com>, n to skip]:
License []:
Compatible Python versions [^3.7]: ^3.9

Would you like to define your main dependencies interactively? (yes/no) [yes] no
Would you like to define your development dependencies interactively? (yes/no) [yes] no
Generated file

[tool.poetry]
name = "basic_django"
version = "0.1.0"
description = ""
authors = ["Rasul Kireev <rasul.kireev@guycarp.com>"]

[tool.poetry.dependencies]
python = "^3.7"

[tool.poetry.dev-dependencies]

[build-system]
requires = ["poetry-core>=1.0.0"]
build-backend = "poetry.core.masonry.api"


Do you confirm generation? (yes/no) [yes]

Now let's add the Django dependency and try running the test server. So, to add a dependency in a Poetry project you just simply do:

poetry add Django

After this command finished running let's see what we have. You should see two files:
- pyproject.toml
- poetry.lock

poetry.lock is a file that keeps all the project dependencies nice and constant so that if other people want to use your project, they will be able to install the exact same versions.

pyproject.toml is a nice visual file that lists all the project dependencies. In future posts, we will be using it to give our project configurations. Here is what we have in the pyproject.toml file right now (you should see something very similar):

[tool.poetry]
name = "basic_django"
version = "0.1.0"
description = ""
authors = ["Rasul Kireev <rasul.kireev@guycarp.com>"]

[tool.poetry.dependencies]
python = "^3.9"
Django = "^4.0.1"

[tool.poetry.dev-dependencies]

[build-system]
requires = ["poetry-core>=1.0.0"]
build-backend = "poetry.core.masonry.api"

You can see that we are using the latest Django version, 4.0.1. If you want to use some other Django version, you can specify that when adding that dependency, like so:

poetry add "Django>=3.2.4"

If you want to change the version of the file retroactively, you can manually change the value in the pyproject.toml file and run:

poetry update

Let's initiate a Django project with the Django admin command:

poetry run django-admin.py startproject basic_django .

Ok, if you have never used poetry before this is important. In the command above can see I'm using poetry run. I'm adding this so that poetry runs the django-admin command for me from the virtual environment that will have all the dependencies that we specified earlier. If you don't want to keep typing poetry run for every command, you can simply run:

poetry shell

and then use commands as you usually would. However, I don't recommend that, since if you have multiple projects open, virtual environments might not work nicely with each other. I suggest explicitly running python commands with poetry run ….

Second thing to note is the "." at the end of the command. This tells us that we have a parent directory already created, no need to do that for us.
Now in your File Explorer you should have the following:

basic_django/ (This will be different for you)
manage.py      
poetry.lock    
pyproject.toml

Finally to test that everything is set up as it should be let's run the local server:

poetry run python manage.py runserver

Tip: you should not be writing these commands all the time. If you have already run one of these commands previously you can press the ⬆️ key on your keyboard, while in the terminal and it will show the previous command you run, so that you don't have to write it down again.

Another tip: This is related. If you start typing "poetry run" in your terminal and then start pressing the ⬆️ key, your terminal will show only commands that have started with these keywords.

You will see something like this:

Watching for file changes with StatReloader
Performing system checks...

System check identified no issues (0 silenced).

You have 18 unapplied migration(s). Your project may not work properly until you apply the migrations for app(s): admin, auth, contenttypes, sessions.
Run 'python manage.py migrate' to apply them.
January 27, 2022 - 17:25:15
Django version 4.0.1, using settings 'basic_django.settings'
Starting development server at http://127.0.0.1:8000/
Quit the server with CONTROL-C.

This is good! We can go to our browser and go to the URL specified in the output (http://127.0.0.1:8000/)

You should see a Django welcome screen.
Notice the following line in the terminal output: "You have 18 unapplied migration(s). Your project may not work properly until you apply the migrations for app(s): admin, auth, contenttypes, sessions." This is because we haven't run any migrations, and that's by design. We will not run any migrations until we have created a custom user model. If you don't anticipate your app to have a user, then don't worry about this.
I did not yet write a guide on how to create a Custom User Model, so will refer you to the best resource I know and that is Will Vincent's blog

Adding Static Pages

Before we create models, databases, and other fun stuff let's first create some static pages. For that, we are going to create a "pages" application. I got this approach from Will Vincent, and have been using it for a long time.

Create a new application with the following command:

poetry run python manage.py startapp pages

You should see a new folder pop up in your Code Editor named "pages" 👍.

Head over to the urls.py file in the basic_django directory (remember for you the name of the "core" directory is different, whatever you chose when setting up the project) and add the following:

# basic_django/urls.py
from django.contrib import admin
from django.urls import path, include # new

urlpatterns = [
    path('admin/', admin.site.urls),
    path("", include("pages.urls")), # new
]

What we are doing here is we are adding a namespace to our site, basically saying that all the pages that will be created under the pages app will be at the root of the URL.

Head over to the setting.py in the root folder (basic_django for me) and search for the TEMPLATES variable and replace the DIRS list to be this:

# basic_django/settings.py
...
TEMPLATES = [
    {
        'BACKEND': 'django.template.backends.django.DjangoTemplates',
        'DIRS': [str(BASE_DIR.joinpath('templates'))], # new
        'APP_DIRS': True,
        'OPTIONS': {
            'context_processors': [
                'django.template.context_processors.debug',
                'django.template.context_processors.request',
                'django.contrib.auth.context_processors.auth',
                'django.contrib.messages.context_processors.messages',
            ],
        },
    },
]
...

This will tell our Django application that all templates are under the templates folder.

Now, let's actually create the templates directory in the root folder. You can do that in the VS Code UI, or with the mkdir command. Just make sure that you are in the root folder.
Inside the templates folder create a base.html file. Inside that html file add the following:

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <meta http-equiv="X-UA-Compatible" content="IE=edge">
  <meta name="viewport" content="width=device-width, initial-scale=1.0">
  <title>Basic Django Project</title>
</head>
<body>

  {% block content %}
  {% endblock %}

</body>
</html>

This template will be used as a base for all other templates in our project. Here, we can add the header, footer, and other components that will be present on each page of the site.

Now, let's create a template for the home page. Create a pages folder, under templates folder. And inside that folder create a home.html file and add the following to it:

{% extends 'base.html' %}

{% block content %}
  <h1>Helllloooooo!</h1>
{% endblock content %}

Here were are extending the base template and adding a header to it.

Tip: If you are doing this for the first time, this might seem like a hard, long, and annoying task. But once you get the hang of it, things become to make sense and fall into their places.

Now the last two pieces to finish the proper setup of our Django project are URLs and Views.

Let's start with views. Go to the views.py file under the pages folder and add the following code:

# pages/views.py
from django.views.generic import TemplateView

class HomeView(TemplateView):
    template_name = "pages/home.html"

And let's create a URL for that HomeView. Create a urls.py in the pages folder and add the following:

# pages/urls.py
from django.urls import path

from .views import HomeView

urlpatterns = [
    path("", HomeView.as_view(), name="home"),
]

Now if you start the dev server with:

poetry run python manage.py runserver

you should see the word "Helllllooooo!".

Conclusion

Congratulations! You are done with the Django Project Setup. After all of this you should have a directory looking something like this:

.
├── basic_django
│   ├── __init__.py
│   ├── __pycache__
│   │   ├── __init__.cpython-39.pyc
│   │   ├── settings.cpython-39.pyc
│   │   ├── urls.cpython-39.pyc
│   │   └── wsgi.cpython-39.pyc
│   ├── asgi.py
│   ├── settings.py
│   ├── urls.py
│   └── wsgi.py
├── db.sqlite3
├── manage.py
├── pages
│   ├── __init__.py
│   ├── __pycache__
│   │   ├── __init__.cpython-39.pyc
│   │   ├── urls.cpython-39.pyc
│   │   └── views.cpython-39.pyc
│   ├── admin.py
│   ├── apps.py
│   ├── migrations
│   │   └── __init__.py
│   ├── models.py
│   ├── tests.py
│   ├── urls.py
│   └── views.py
├── poetry.lock
├── pyproject.toml
└── templates
    ├── base.html
    └── pages
        └── home.html

After finishing this tutorial you should know how to set up a Django Project with Poetry and Pyenv. In the future, I'm going to be writing a guide on how to integrate various tools into your Django Project, and having this neat setup will help a lot.

If you run into any issues or have any questions, feel free to message me on Twitter.

Managing a Django Project with Poetry

Rasul Kireev — Sat, 31 Oct 2020 00:00:00 +0000

Poetry is relatively new packaging and dependency manager. It makes it very easy to upload libraries to PyPI, manage dependencies visually, and has a couple of handy features. Today, I'm not going to do a deep dive into how Poetry works and all its features. Today I just want to focus on configuring a Django project.

1. Install Poetry

curl -sSL https://raw.githubusercontent.com/python-poetry/poetry/master/get-poetry.py | python -

2. Create a Directory for you Django Project

mkdir django_poetry_example && ls django_poetry_example

3. Initiate a Poetry Project

poetry init

You will be asked to confirm the information about your project. You can skip through most of it.

4. Add the Necessary Dependencies

Run poetry add django. Poetry will add django to the pyproject.toml file under the dependencies section. A virtual environment will also be created for you.

5. Start you Django Project

django-admin startproject django_poetry_example .

6. Working on your Django Project

When you need to run any python function (for example, python manage.py createsuperuser) you have two options.

You can leverage poetry run, which will run against the current project's dependencies. The command will be this:
poetry run python manage.py createsuperuser
You can activate the virtual environment with a poetry shell command. Now you can run python commands, as is. They will be run with dependencies you have installed.

Bonus. Export dependencies to a requirements.txt

If you need to have the requirements.txt file with all the dependencies, you can run poetry export -f requirements.txt --output requirements.txt. If you have configured a CI/CD job that auto deploys your project, you can add this function as a step, which will generate the updated version on each update.

Bonus II. Video

If you prefer a more visual approach, I have made a video that shows how to start a Django project with Poetry.

https://youtu.be/-c8DASfFNZM

If you have any feedback, please let me know on Twitter.

Sponsorware is picking up

Rasul Kireev — Tue, 18 Aug 2020 15:38:47 +0000

A couple of months ago, I signed up for Caleb Porzio's newsletter about VS Code. I then rediscovered Caleb through his post on hitting $100k/y through Github Sponsors. This post made quite the round across the internet, after all, that's the dream, right?

In this post, he said that one of the spikes was due to the Sponsorware. It's not an app or anything, it's just an idea. The idea is that you only let your supporters use your "open-source" work until you reach a certain number of sponsors. Once you reach this level, you make the repo public. That's pretty genius.

I'm very intrigued by this idea and have decided to give it a go. I have applied for the Github Sponsors program. The process is very straight forward. If you do any open-source work, I suggest you apply as well, there is no harm. If you get in, try this Sponsorware thing, I think the future of open-source is very bright if more people adopt this strategy. If I don't get in, no worries, I'll just keep working on my open-source projects until I can get in.

I don't have a huge following my work, but I hope this post will spread. I think that this way of working is very healthy for the developer and for the community alike. I really hope this picks up.

Thanks for reading, have a wonderful day!

You can reply on Twitter. Your reply will be displayed here, also, thanks to the webentions.

Multiple Graphql Queries on a Single Page with Gridsome

Rasul Kireev — Thu, 23 Jul 2020 00:00:00 +0000

Ever wonder how include multiple queries on the same page, when using Gridsome? Well, this is how.

Let's say you have the following queries:

// query details about the current blog post 
query Post ($path: String!) {
  post: post (path: $path) {
    title
    date (format: "MMMM D, Y")
    content
    path
  }

and

// query to pull all the webmentions on a specific post
query($path: String!) {
    mentions: allWebMention(filter: { wmTarget: { regex: $path } }) {
      edges {
        node {
          wmId
          wmProperty
          content {
            text
          }
          author {
            name
          }
        }
      }
    }
  }

The question is: How do you get both of those queries in your Post.vue template?

I was going to give you all the options that I tried before making this work, but that would be the waste of your time. So here is he working version:

<page-query>
query Post ($path: String!) {
  post: post (path: $path) {
    title
    date (format: "MMMM D, Y")
    content
    path
  }
  mentions: allWebMention (filter: { wmTarget: { regex: $path } }) {
    totalCount
    edges {
      node {
        wmId
        wmProperty
        content {
          text
        }
        author {
          name
        }
      }
    }
  }
}
</page-query>

Then you can access these queries like this:

<div>{{ $page.post.title }}</div>

<div 
v-for="mention in $page.mentions.edges"
:key="mention.node.wmId"
>
    <p>{{ mention.node.wmProperty }}</p>
    <p>{{ mention.node.content.text }}</p>
</div>

If you have any thougths, comments or questions please let me know on Twitter.

DEV Community: Rasul Kireev

Linux Laptops in 2025: A Developer's Guide to Hardware, Distros, and Making the Switch

Hardware: The Foundation of Your Linux Experience

Navigating the World of Distributions and Desktops

The Developer's Playground

Overall Sentiment

How to Prove Future Claims: A Guide to Cryptographic Foreshadowing

The Cryptographic Proof-of-Prior-Knowledge Method

Why This Method Works

The Hidden Secret to Get the Job of Your Dreams

1. Craft a Killer Video Intro

2. Find the Right Email Addresses with gettjalerts.com

3. Follow Up Strategically

Conclusion

Create Smarter & Better Git Commits with AI

🙏 The Script

⚒️ Breaking it Down

💻 Setting it up

🎉 Yay

Django Codebase Updates: January 2025

Overview

Key Changes and Features

Major Features

Composite Primary Key Improvements

Bug Fixes

Security and Dependencies

Development Patterns and Contributors

Recommendations

7 Simple Ways to Create Blog Posts That Actually Rank in Google

1. Start with Solid Keyword Research

2. Optimize Your Content Structure

3. Create Comprehensive Content

4. Focus on User Experience

5. Implement Technical SEO Best Practices

6. Build Quality Backlinks

7. Regular Content Updates

Putting It All Together

Conclusion

Improve your Django Code with pre-commit

TL;DR

Follow Along

Pre-Commit

1. Install Pre-Commit

2. Create a pre-commit Config File

3. Install and Run your Hooks for the first time

4. Use Pre-Commit

Good Hooks to Use

Black

isort

flake8

pylint

djlint

poetry export

ruff

Conclusion

How to Version Control your Django project

Why?

Beginning of History

Ignoring secrets

Final Steps

Conclusion

Setting up a basic Django project with Poetry

Prerequisites

Pyenv

Poetry

Setting up the Environment

Adding Static Pages

Conclusion

Managing a Django Project with Poetry

1. Install Poetry

2. Create a Directory for you Django Project

3. Initiate a Poetry Project

4. Add the Necessary Dependencies

5. Start you Django Project

6. Working on your Django Project

Bonus. Export dependencies to a requirements.txt

Bonus II. Video

Sponsorware is picking up

Multiple Graphql Queries on a Single Page with Gridsome

2. Create a `pre-commit` Config File