BringAuto

bringauto

[Hacking Tinder] Train an AI to Auto-Swipe for You 🖖

How to Add Full Text Search to Your Django App with django-watson

Meet Jane, a passionate software developer who loves building robust and efficient web applications using Django. Jane is currently working on a project where she needs to execute a certain piece of code based on certain events that occur in her app. She has heard about Django signals, but she is not quite sure what they are and how they work. Django signals are a powerful tool for executing code based on certain events in your Django application. Signals are decoupled and allow senders to notify a set of receivers that some action has taken place. This can be useful for automating tasks, such as sending emails, updating records, or logging data, whenever a certain event occurs in your app. In this tutorial, we will go through the process of using Django signals to execute code based on certain events in your app. Understanding Django Signals Django signals are a way to allow certain senders to notify a set of receivers that some action has taken place. Signals are sent by senders, using the method, and are received by receivers, using the decorator. Signal.send() @receiver There are several built-in signals in Django, such as , , , and . These signals are sent whenever a model instance is saved or deleted. You can also create custom signals for your app. pre_save post_save pre_delete post_delete Django signals can be used for a wide range of events, including user authentication, object creation, object deletion, and many more. By using signals, developers can create more modular and extensible code that is easier to maintain and test. In the next section, we'll take a closer look at how Jane can use Django signals in her project to execute code based on certain events. Creating a Signal Receiver Now that you understand the basics of Django signals, it's time to explore how to use them in your own projects. Let's continue following the journey of our character, Jane, as she discovers the power of signals in her Django app. Jane has been working on a web application that allows users to subscribe to different newsletters based on their interests. Whenever a user subscribes or unsubscribes from a newsletter, Jane needs to update the user's profile to reflect their choices. She could update the user's profile directly whenever a subscription or unsubscription occurs, but that would create extra code and make her application less modular. Instead, Jane decides to use signals to keep her code clean and organized. The first step for Jane is to define the signals that her app will use. She creates two signals, one for subscribing and one for unsubscribing, and gives them descriptive names: and . user_subscribed user_unsubscribed She also includes any relevant data that needs to be passed along with the signal, such as the user's email. # File: yourapp/signals.py
from django.dispatch import Signal

user_subscribed = Signal(providing_args=['user_email'])
user_unsubscribed = Signal(providing_args=['user_email']) Once Jane has defined her signals, she needs to connect them to the appropriate functions that will execute whenever the signal is triggered. She creates two functions, and , which will update the user's profile whenever a subscription or unsubscription occurs. subscribe_newsletter unsubscribe_newsletter # File: yourapp/signals.py
...
from django.dispatch import receiver

...
@receiver(user_subscribed)
def subscribe_newsletter(sender, **kwargs):
    user_email = kwargs['user_email']
    
    # Business logic
        # user = User.objects.get(email=user_email)
    # user.profile.subscriptions.add("my_newsletter")
        # user.profile.save()
    print(f"Subscribed {user_email} to our newsletter")

@receiver(user_unsubscribed)
def unsubscribe_newsletter(sender, **kwargs):
    user_email = kwargs['user_email']
    
    # Business logic
        # user = User.objects.get(email=user_email)
    # user.profile.subscriptions.remove("my_newsletter")
        # user.profile.save()
    print(f"Unsubscribed {user_email} from our newsletter")

# Connecting recievers & signals
user_subscribed.connect(subscribe_newsletter)
user_unsubscribed.connect(unsubscribe_newsletter) In this example, the decorator is used to register the function as a receiver for the signal. The function simply prints it out to the console. @receiver subscribe_newslettter() user_subscribed Use it in your views That’s it now Jane can use those signals in her file. views.py from .signals import user_subscribed, user_unsubscribed
from django.http import HttpResponse

def subscribe(request):
    user_email = request.GET.get('user_email')
    if user_email is None:
        return HttpResponse("Please provide a user_email parameter in GET request.")
    else:
        user_subscribed.send(sender=request.user, user_email=user_email)
        return HttpResponse(f"Subscribed {user_email} to our newsletter.")
    
def unsubscribe(request):
    user_email = request.GET.get('user_email')
    if user_email is None:
        return HttpResponse("Please provide a user_email parameter in GET request.")
    else:
        user_unsubscribed.send(sender=request.user, user_email=user_email)
        return HttpResponse(f"Unsubscribed {user_email} from our newsletter.") With her signals and functions in place, Jane can now use them in her application whenever a user subscribes or unsubscribes from a newsletter. She simply needs to import the appropriate signal and send it with the relevant data. To make it work… There is one catch to this situation, the code isn’t functional yet. To make our code work as desired we need to import our signals into our application’s config file - apps.py from django.apps import AppConfig

class AccountsConfig(AppConfig):
    default_auto_field = 'django.db.models.BigAutoField'
    name = 'accounts'

    def ready(self) -> None:
        import accounts.signals
                print("Signals connected") In this example, the method imports the module, which contains our signals. It then logs a message to indicate that the signal receiver has been connected. ready() signals.py Now when you send requests to your view endpoints, you can see your signals working in action. Also, see You can also use in-built model signals like . pre-save from django.contrib.auth.models import User
from django.db.models.signals import pre_save

@receiver(pre_save, sender=User)
def user_created(sender, **kwargs):
    user = kwargs['instance']
        # Other business logic you might want to add...
    print(f"Creating user, {user}") Django documentation will always be the number 1 resource for further studying: https://docs.djangoproject.com/en/4.1/topics/signals/ is a good blog post by simpleisbetterthancomplex, if you want a detailed overview; rather than an introductory post like this one. Also, this Conclusion Django signals provide a powerful tool for executing code based on certain events in your application. By using signals, you can keep your code modular and organized, making it easier to maintain and update in the future. Whether you're building a simple web app or a complex enterprise application, signals can help you streamline your code and create a more efficient development process. Happy Coding! Also published here

You Need Django Signals Right Now — Here's Why 

Most of our web applications run in LXD containers. Not without reason LXD is one of the of Ubuntu Server for me. There are many ways to access a web application in an LXD container from outside. For example, you can use a reverse proxy to control access to the containers. Another possibility is to set up a network bridge so that the containers are in the same network as the container host (the Ubuntu server). In this article I would like to describe how to set up a network bridge for LXD containers. most important features Network Bridge for LXD Containers To set up a network bridge under Ubuntu, you need to install the : bridge-utils $ apt install bridge-utils Then you can set up the network bridge. Ubuntu 16.04 Up to Ubuntu 16.04 Ubuntu uses to set network connection settings. The configuration is done in the files under . A simple network bridge — to get the containers into the host network — might look like this: ifupdown /etc/network/ $ cat /etc/network/interfaces# This file describes the network interfaces available on your system# and how to activate them. For more information, see interfaces(5). source /etc/network/interfaces.d/* # The loopback network interfaceauto loiface lo inet loopback # The main Bridgeauto br0iface br0 inet dhcpbridge-ifaces enp4s0bridge-ports enp4s0up ip link set enp4s0 up # The primary network interfaceiface enp4s0 inet manual In this example the bridge gets its address from a DHCP server. The real network card is set to manual mode and assigned to the bridge. enp4s0 Ubuntu 18.04 As of Ubuntu 18.04 is used to configure the network connections. The configuration files can be found under . A definition for the bridge could look like this: Netplan /etc/netplan/ $ cat /etc/netplan/50-cloud-init.yaml# This file is generated from information provided by# the datasource.  Changes to it will not persist across an instance.# To disable cloud-init's network configuration capabilities, write a file# /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following:# network: {config: disabled}network:ethernets:enp3s0:dhcp4: noversion: 2bridges:br0:dhcp4: noaddresses:- 10.10.10.5/24gateway4: 10.10.10.254nameservers:addresses:- 10.10.10.254interfaces:- enp3s0 In the upper part you configure the real network card ( ) and don’t assign an address to it. Then the definition of the network bridge follows. It is set up like a static network connection and also contains the key . There you define which real network card should be “bridged”. You will find of network bridges on the official website. enp3s0 interfaces further (more complex) examples Now the following command applies the changes to the network settings: $ netplan apply --debug Assign Network Bridge Once you have finished setting up the network bridge and it gets the correct IP address, you have to tell the LXD container to get its IP address from the network bridge. This can be done with the following command: $ lxc config device add containername eth0 nictype=bridged parent=br0 name=eth0 With you define under which name the network card can be found in the container. Now you can configure eth0 in the container as you like. From now on the container will get an IP address from the host network. name=eth0 Conclusion You can set up a simple network bridge quit easily and assign it to a container. This allows other users on the network to access a web application without the need to set up a reverse proxy on the container host. More complex scenarios are also possible (VLANs, multiple bridges to get containers into different networks, etc.), but this would go beyond the scope of this short article. Originally published at openschoolsolutions.org .

Stories, News & Mentions about BRINGAUTO

Trending Topics

Classic

Neon Noir

Minty

Newspaper

HN StartUps