Forem: Ahmad Salah

Getting to know Django Signals

Ahmad Salah — Mon, 12 Jun 2023 10:48:18 +0000

If you've been working with Django for a while, you've probably heard of Django Signals. But what are they, and why should you care? Well, my friend, you're in for a treat. In this article, we'll dive deep into the world of Django Signals and discover how they can supercharge your app.

what are Django Signals?
Simply put, they're a way for different parts of your app to communicate with each other without being tightly coupled. Think of them as the secret sauce that makes your app more flexible, scalable, and maintainable. With signals, you can easily trigger actions based on certain events or conditions, without having to write custom code for each one.

When should you use signals?
The short answer is: whenever you need to perform an action based on some event or condition, but you don't want to tightly couple your code. For example, let's say you have a blog app, and you want to send an email notification whenever a new post is published. You could write a custom function to do that, but that would tightly couple your code and make it harder to maintain. With signals, you can simply listen for the post_save signal and trigger your email function when the event occurs.

How does Django Signal work?
At a high level, signals are just a way for different parts of your app to communicate with each other. When an event occurs, a signal is sent out, and any listeners that have registered for that signal will be notified. The listeners can then perform their own actions based on the event

Creating a signal is easy
You simply define a Signal object in your code, like this:

from django.dispatch import Signal

my_signal = Signal()

Now, anyone can send a signal using the send method, like this:

my_signal.send(sender=self, message='Hello, world!')

To listen for a signal, you define a function and use the receiver decorator to register it with the signal, like this:

from django.dispatch import receiver

@receiver(my_signal)
def my_listener(sender, message, **kwargs):
    print(f'Received message "{message}" from {sender}.')

Finally, to connect a signal to a specific model or action, you can use the connect method. For example, to listen for the post_save signal on a specific model:

from django.db.models.signals import post_save
from myapp.models import MyModel

@receiver(post_save, sender=MyModel)
def my_post_save_handler(sender, instance, created, **kwargs):
    # Do something here

And that's it! Now, whenever a MyModel object is saved, your my_post_save_handler function will be called.

There are also many built-in signals available in Django, such as pre_init, post_init, pre_save, post_save, pre_delete, post_delete, and m2m_changed. These signals allow you to hook into various stages of the object lifecycle and perform custom actions.

In conclusion, Django Signals are a powerful tool that can help you write more flexible, scalable, and maintainable apps. By using signals to communicate between different parts of your app, you can reduce coupling and make your code more modular. So why not give signals a try in your next project? Your future self will thank you.

Solving Common Performance Issues in Django REST Framework

Ahmad Salah — Mon, 17 Apr 2023 23:55:41 +0000

original post Solving Common Performance Issues in Django REST Framework

Are you experiencing sluggish load times or inefficient database queries in your Django REST Framework (DRF) application? These performance hitches can hinder your app's scalability and impede your development momentum. Fortunately, with the right tools and strategies, you can surmount these obstacles and unleash your DRF app's full potential.
In this article, we'll explore powerful tools such as the Django Debug Toolbar and show you how to leverage techniques like caching and serialization optimization to take your DRF app to the next level.

Django Debug Toolbar:
If you're looking for a powerful tool to diagnose performance issues in your Django REST Framework (DRF) app, the Django Debug Toolbar is an excellent option. With this nifty open-source library, you can gain deep insights into the inner workings of your app, including SQL queries and cache hits.

Step-by-step guide on how to install the Django Debug Toolbar
Add "debug_toolbar" to your INSTALLED_APPS setting in your Django project's settings.py file.

Add "debug_toolbar.middleware.DebugToolbarMiddleware" to the MIDDLEWARE setting, right after the CommonMiddleware class.

(Optional) Set DEBUG_TOOLBAR_CONFIG in your settings.py file to customize the toolbar's behavior and appearance.

Run your app and append ?debug_toolbar=on to your app's URL to access the toolbar.

Common issues and best practices when using the Django Debug Toolbar
While the Django Debug Toolbar is a powerful tool, it can also cause issues if not used properly. Here are some common issues and best practices to keep in mind:

Make sure to only use the Django Debug Toolbar in development environments, not in production.

Remember that the toolbar can reveal sensitive information about your app, such as database queries or HTTP headers, so be careful not to expose it to unauthorized users.

Avoiding the N+1 query problem
Slow loading times can be a major pain point for Django REST Framework app developers, especially when dealing with large datasets. This issue may be caused by the N+1 query problem, where N queries are executed to load N records, leading to sluggish performance and inefficient database queries. Fortunately, there's a solution to this problem. Django expert Ahmad Salah has penned a comprehensive guide to optimizing Django REST Framework and tackling the N+1 problem. His expert advice can help you ensure that your app runs smoothly and efficiently. To learn more about solving this issue, check out my guide on detecting and solving this N+1 in Django here.

Caching to improve performance: leverage the power of caching to speed up your DRF app
When it comes to improving the performance of your Django REST Framework app, caching is a key tool in your arsenal. By caching commonly used data, you can reduce the number of database queries needed to generate a response and improve load times. DRF provides built-in support for caching at the view level, which makes it easy to cache the response generated by a particular view.

You can use the @cache_page decorator to specify the cache settings for a view. For example, to cache the response of a view for 60 seconds, you can add the following code to your view:

from django.views.decorators.cache import cache_page
from rest_framework.views import APIView

class MyView(APIView):
    @cache_page(60) # this will cach values for 60 seconds
    def get(self, request):
        # Your view logic here

Using caching in DRF can be a powerful way to improve performance and reduce load times. However, it's important to use it judiciously and only cache data that is unlikely to change frequently

Caching user-specific content in DRF
Caching is an excellent technique to boost the performance of your DRF app, but it requires careful handling, especially when it comes to user-specific data. In this case, we can leverage the user's ID to generate a unique cache key for their profile data

from django.core.cache import cache
from rest_framework.decorators import api_view
from rest_framework.response import Response

@api_view(['GET'])
def user_profile(request):
    user_id = request.user.id
    cache_key = f'user_profile_{user_id}'
    cached_profile = cache.get(cache_key)
    if cached_profile:
        return Response(cached_profile)
    else:
        # Your logic to retrieve the user's profile
        profile_data = {'name': request.user.username, 'email': request.user.email}
        cache.set(cache_key, profile_data, timeout=300)
        return Response(profile_data)

Note that caching sensitive user-specific data can pose privacy risks, so ensure that you handle such information securely.

Django Cache Back-Ends
Django cache back-ends are pluggable components that provide a consistent API for storing and retrieving cached data in various data stores such as memory, file system, and databases.

It's what our previous example will use to actually store your cache to get started using it!

First, you need to define the cache backend settings in the settings.py file of your project. Here is an example:

CACHES = {
    'default': {
        'BACKEND': 'django_redis.cache.RedisCache',
        'LOCATION': 'redis://localhost:6379/0',
        'OPTIONS': {
            'CLIENT_CLASS': 'django_redis.client.DefaultClient',
        },
        'KEY_PREFIX': 'my_cache_key_prefix',
    }
}

REST_FRAMEWORK = {
    'DEFAULT_CACHE_RESPONSE_TIMEOUT': 60*5,
    'DEFAULT_CACHE_BACKEND': 'django_redis.cache.RedisCache',
    'DEFAULT_CACHE_ALIAS': 'default',
}

and to use in your view

from django.conf import settings
from django.utils.decorators import method_decorator
from rest_framework.views import APIView
from rest_framework.response import Response


class MyView(APIView):
    @method_decorator(cache_page(60))
    def get(self, request):
        # Your view logic here
        response_data = {'message': 'Hello, World!'}
        return Response(response_data)

Serialization optimization:
Serialization is a key part of any DRF application, and optimizing the serialization process can significantly improve the load times of your app. In this section, we'll explore a few strategies for optimizing serialization.

Use the right serialization format: DRF supports several serialization formats, including JSON, XML, and YAML. JSON is the most commonly used format and is generally the most efficient, but you should choose the format that best suits your app's needs.

Customize your serialization settings: DRF provides a number of serialization settings that you can use to customize the serialization process. For example, you can use the depth option to control the level of nested serialization, or the fields option to specify the fields that should be included in the serialized output.

Use a serialization library optimized for performance: While DRF's built-in serialization is generally quite efficient, several third-party libraries are optimized for performance. Two popular options are ujson and orjson, which offer significantly faster serialization than the built-in JSON serializer.

By using the right serialization format, customizing your serialization settings, and choosing a performance-optimized serialization library, you can significantly reduce the load times of your DRF app.

In this article, we explored tools and strategies that can help improve the performance of your Django REST Framework (DRF) app. We started with the Django Debug Toolbar, a powerful open-source library that can diagnose performance issues in your app. We also looked at how caching can be used to speed up your DRF app and tackled the N+1 query problem.

Finally, we discussed how to cache user-specific content and the different Django cache back-ends that can be used to store and retrieve cached data. With these tools and techniques, you can take your DRF app to the next level and ensure that it runs smoothly and efficiently.

Commit messages are mostly useless

Ahmad Salah — Fri, 10 Sep 2021 00:57:20 +0000

Commit messages are really not that useful! you can argue as much as you want only if people did it this way or only if they implemented that set of standards.

Commit messages will still be useless!

Why?

All teams use some sort of git host like GitHub. and all of these services provide much better tooling to have a discussion around the feature you added or the bug you just fixed. Why would you use the commit body to explain what you did? what is the point? While you have a really nice UI with a nice text editor and you can tag your teammates and they can respond to you?

With this mindset let's think about what do we need in our commit messages.

State your intent & Make it shorter

I hate long commit messages no one is going to read a long commit message. So declare your intent is it a fix, feature, enhancement, or a refactor.

The enhancement flag is for developer-related features. added linting, CI/CD enhancement, introduced a tool, docs, add tests, etc.

Write in 10 words or less what you made. e.g

fix/login-screen-validation
refactor/class-a-to-introduce-endpoint-b

Reference the issue

As I said at the beginning commit messages are redundant because we don't need them to add context or start a conversation. So we need to bring context to our changes. The best context you can provide is where did this start so reference the issue at the commit. and have your conversation on the issue. this makes it accessible for devs, PM and QCs

You can use ref # which refers to the commit and add a comment to the original issue. this is supported by almost all of the Git hosting services.

I dislike close, fix and I prefer to do this manually from the issue itself as usually need to add final remarks but you can sometimes use them for hotfixes or something.

Details are for PRs

What the told you to add in the commit message you can write it here. it's much clearer and more visible this way! here you should

What have you changed in detail?
Why have you made these changes?
Keep it short & use bullet points.
Emojis are fun please use them more.

Stylistic preferences

You can write however you like but if you are not so great at writing like me I find these guidelines nice to follow.

Start with a verb I find past tense makes more sense. Rename class A to B. VS Renamed class A to B!
Stick to bullet points
Add a conclusion sentence "If applied, this commit will achieve X"

Git Rebase

Ahmad Salah — Thu, 09 Sep 2021 01:07:41 +0000

What is Git Rebase? - Conceptual Overview
The first time I tried the git rebase command, I was confused -I find most git commands unwieldy & git has a bad user experience- Rebase has a simple job integrate the changes from one branch into another. Just like merge.

But git rebase has a very different flow to achieve this.

What does git merge exactly do?
To highlight the difference between the two approaches. Let's examine git merge first as it's the more common approach.

git merge starts by creating a commit in the feature branch that ties together the histories of both branches, maintaining both branches without any alteration. Although git merge is a simple safe command, it can clutter the history of your feature branches.

Git Rebase
As an alternative to merging, you can rebase the feature branch onto the main branch. rebase puts your feature branch in front of the main branch.

DANGER!

git rebase rewrites the project history by creating brand new commits for each commit in the feature branch. This can cause lots of problems we will discuss but, first the nice things. Eliminate the unnecessary merge commits required by git merge Linear project timeline. Instead of the miss of "metro lines" merge creates you get a single line simple easy to follow.

Avoiding a disaster
Tinkering with time is a dangerous act. Now that you know about rebasing, the most important thing to learn is when to avoid it.

Never rebase a branch used by other people.

Think about what would happen if you rebased the dev branch on the main branch?

The rebase moves all of the commits in dev in front of main. Only you have this update in your local repository. All of the other developers are still working with the original dev. Since rebasing results in brand new commits, git will think that your dev branch history has diverged from everybody else’s

For such branches only use merge

Null Object Design Pattern

Ahmad Salah — Mon, 06 Sep 2021 00:02:45 +0000

Nulls are bad!
I call it my billion-dollar mistake…At that time, I was designing the first comprehensive type system for references in an object-oriented language. My goal was to ensure that all use of references should be absolutely safe, with checking performed automatically by the compiler. But I couldn’t resist the temptation to put in a null reference, simply because it was so easy to implement. This has led to innumerable errors, vulnerabilities, and system crashes, which have probably caused a billion dollars of pain and damage in the last forty years.
– Tony Hoare, inventor of ALGOL W.

But, why null is so evil?

NULL indicates a distinct state, and any type can have this state.
Rather than defining a new type for each state, an entity needs to express.
We confuse our abstraction by this rather odd generalized value.
It's hard to reason about NULL when debugging.

To find the NULL-related bugs. You will have to determine which state the program was in and what leads to this state.

Once NULL references are used as valid states for parameters as well as return values. We have to duplicate NULL reference checks in various places.

Taming the NULL
Enters, the Null Object Pattern

The root cause of the troubles null introduces. Is it uses a generalized value to represent a distinct state?

Why not use NullableObject? It's more work to create NullObject class for each interface with which you want to represent a special state.

But the specialization is isolated to each special state, rather than the scattered if statements.

7 Essential Tips to Debug Software

Ahmad Salah — Mon, 06 Sep 2021 00:01:05 +0000

“If debugging is the process of removing software bugs, then programming must be the process of putting them in.”
There will always be BUGS!
Bugs are part of writing software. Be it a new piece of code you're adding or an old module you are fixing. Bugs will be there.
Working with bugs is challenging, both mentally and emotionally. Therefore we need a systematic approach to solving bugs as staring at your screen shouting - "it should be working! Why this is not working" will not resolve anything.

Be aware of the emotional toll
Most developers suffer from imposter syndrome and not feeling they belong. Especially people who are just starting.
When you get stuck, it's necessary to calm down, be mindful of how you feel and trust the process, and go through a step by step.

*Reminder raise your hand and ask for help when you need it, even if you are a senior engineer. It is OK!
The Process

Reproduce the problem consistently
The first to solve a problem is to define it.
It doesn't make much sense to work on a solution for an ill-defined problem.
Don't think about the code and dedicate all your energy to finding a repeatable step to reproduce this bug.
Finding the root cause
Now, you got the steps to reproduce the bug. You will have to reduce the steps required to reproduce the bug. This step is critical to isolate the root cause of the problem.

*Don't overload your short-term memory. always write down the steps & even take screenshots/casts if necessary.

Now we examine the code After writing down the minimum steps required to reproduce the bug, you can examine the code. Your focus should be on isolating the part responsible for this bug. Start by finding the module then, the class then, the method where things deviate from the expected behavior.

it's always a good idea to ask a teammate where to start

The debugger is your friend print statements are fine. But, the debugger is a powerful tool use it to your advantage. The debugger allows you to set multiple breakpoints, step in function, display all local variables, and more.

Make sure to know your IDE shortcuts and how to get the most out of it. this will save a lot of time

Zoom out
Avoid introducing new bugs with your fix.
It's necessary to get an overview of how this area of the code base works.
Identify the moving parts and how they interact.
What is the business logic and the expected?
Don't make assumptions about the code there is plenty of sneaky edge cases and workarounds everywhere be very wary of brushing off these details.
Small changes only
Tiny changes are easier to validate wasting, 20 minutes typing and think you've solved it. There is a possibility that you've done too much work or broke something along the way.
Writing long patches will most likely end up with you debugging the newly added code.
and remember, version control is your friend you, can do as many commits as you and eventually squash and tidy up your branch
Tunnel vision
Sometimes, you have spent too much time with a bug that you can't see what is wrong and all you need is a fresh set of eyes. Ask a teammate or take a 5 min walk.
It's important to recognize this and avoid sinking more time being stuck.
A great tip to avoid this is to timebox your bugs to a set number of hours, then you must ask for help.

Treating Primitive Obsession with Value Objects

Ahmad Salah — Sun, 05 Sep 2021 23:59:40 +0000

Primitive Obsession
Primitive values are your friends. We all start our programming journey by learning about the fundamentals types. Int, Double, String they are friendly familiar faces.
They are the default tyes we reach for whenever we are writing code and for a good reason they are convenient and we are very familiar with them.

But this obsession with the primitive types and the tendency to use to represent almost everything especially when presenting 'simple' abstractions like a measuring unit, postal code, or an email field.

What is wrong with that you might ask?

There are few issues with making primitives represent domain objects.

Wrong assumption
Take temperature as an example you might be inclined to present a temperature field as a double.
but this means you assume all double values are valid temperature values! which is wrong.

You assume that double representation is similar to temperature representation. which is wrong usually you want to limit the decimal points, add a prefix and maybe add a method to convert between Celsius and Fahrenheit.

Breaking encapsulation
When you use primitive values you will break encapsulation. how many times you will need to verify, transform or represent a type in your application?
Thinking about temperature, we might add a validation upon storing the value and again when updating it and then we will need to duplicate our logic. Now, think about all the places where you will need to display temperature you will duplicate this code!

Value Objects to the rescue
Value objects are just classes but with a couple of important features.

Value Object can answer equality check
if we wanted to represent a currency as a and later wanted to check if two points are equal. unless you are careful with your code you may get the wrong answer.
Therefore, value objects must implement a correct equality check method
Value Object should be immutable
What we gain from delegating the equality check to the object. can lead to aliasing bugs

Aliasing as defined by Martin Fowler is "Aliasing occurs when the same memory location is accessed through more than one reference. Often this is a good thing, but frequently it occurs in an unexpected way, which leads to confusing bugs."

This can happen when dealing with value objects as we blur the lines between values and reference.

As we have seen implementing value objects requires some extra work to make your development faster you may consider using a library that helps you with that. If you are using C# I would recommend ValueOf & for Java people, you can use the @Value annotation from Lombok

Further reading on implementing Value Objects