DEV Community: Nahuel Segovia

Gitlabnotifications, my new package to handle Gitlab web hooks events as notifications

Nahuel Segovia — Tue, 28 Nov 2023 21:23:08 +0000

I have been working in a library that allows you to receive Gitlab web hook events as notifications.

How to install?

npm install express
npm install gitlabnotifications

Basic configuration

If you need to send notifications only one platform at time, just delete its configuration lines

const { GitlabNotifications } = require('gitlabnotifications');
const express = require('express');

const app = express()
app.use(express.json());
app.listen(3000, function () {
});


const sendNotificationsTo = {
    configuration: [
      {
        telegram: {
          token: 'your_telegram_token',
          chat_id: 'your_chat_id',
        },
      },
      {
        slack: {
          workspace_id: 'your_workspace_id',
          channel_id: 'your_slack_channel_id',
          token: 'your_slack_app_token',
        },
      },
    ],
  };

const myMiddleware = (req, res) => {
 /*Your custom middleware has to return true if everything it's okay
  and return false if isn't */
  return true;
}

const gitlabNotificationsService = new GitlabNotifications(
  ['/gitlab-webhook'], //Webhooks urls directions previously configured in Gitlab
  false, //Set in true if you want to send custom notification messages
  null, // Custom messages (if needed)
  sendNotificationsTo,
  app, //Your express instance
  myMiddleware
);


gitlabNotificationsService.connection()

How to use custom notifications messages?

For more information about to get events values you can visit the official gitlab web hooks documentation
https://docs.gitlab.com/ee/user/project/integrations/webhook_events.html

You can declare an object that contains all custom message handlers like this.


const customMessages = {
  pushMessage: (eventData) => `Custom push message: ${eventData.user_username} pushed to ${eventData.project.name}`,
  issueMessage: (eventData) => `Custom issue message: ${eventData.user.username} created an issue in ${eventData.project.name}`,
  commentMessage: (eventData) => `Custom comment message: ${eventData.user.username} commented on something`,
  tagMessage: (eventData) => `Custom tag message: A new tag ${eventData.ref} was created in ${eventData.project.name}`,
  mergeRequestMessage: (eventData) => `Custom merge request message: ${eventData.user.username} created a merge request in ${eventData.project.name}`,
  issueTaskMessage: (eventData) => `Custom task message: ${eventData.user.username} created a merge request in ${eventData.project.name}`,
};

const gitlabNotificationsService = new GitlabNotifications(
  ['/gitlab-webhook'], 
  true, //Set in true if you want to send custom notification messages
  customMessages, // Custom messages (if needed)
  sendNotificationsTo,
  app, //Your express instance
  myMiddleware
);

gitlabNotificationsService.connection()

How to manage physical resources in your Docker containers and keep production servers faster?

Nahuel Segovia — Sat, 18 Feb 2023 15:59:31 +0000

Hi! If you don't know that Docker can manage physical resources, this is the place to learn about it and keep your production servers running faster.

In my current job, we have a lot of Docker containers running in production, but the problem was that we never considered how much CPU memory it occupies in our servers.

To solve this, in Docker, using docker-compose, we have a section named "deploy" that lets us manage limits and reservations of RAM. For example, here we have a Web Service based on Python and Django which has a Postgres database.

In this docker-compose.yml you can see "deploy" with "resources", that we need to configure for reserve quantity of RAM that can use the container and set a limit that which it can reach


version: '3.8'

services:
  web:
    build: .
    volumes:
      - .:/code
    ports:
      - "8081:80"
    command: "python3 manage.py runserver 0.0.0.0:80"
    deploy:
        resources:
            limits: #Definiendo el límite de acceso a memoria RAM y núcleos CPU
              cpus: 0.50
              memory: 512M
            reservations: #Reservando espacio de memoria RAM y núcelos del CPU
              cpus: 0.25
              memory: 128M 

  database:
    image: postgres:14.1-alpine
    restart: always
    environment:
      POSTGRES_DB: dockerized
      POSTGRES_USER: postgres
      POSTGRES_PASSWORD: postgres
      PG_SYSTEM_MAX_CONNECTIONS: 500
    ports:
      - '5432:5432'
    volumes: 
      - database:/var/lib/postgresql/data

volumes:
  database:

So, with

docker stats

we can see the information of the containers that are running and confirm that everything as we expected:

¿Cómo manejar los recursos físicos a los que tienen acceso nuestros contenedores?

Nahuel Segovia — Sat, 07 Jan 2023 21:30:58 +0000

Podemos especificarle a Docker que cantidad de memoria RAM y núcleos del CPU pueden utilizar con una subsección en la parte del servicio lamada Deploy, esta especificación nos permite definir algunos requerimientos para el contexto de ejecución de nuestro contenedor/servicio, es decir cuando el contenedor ya está corriendo.

Entre las opciones que nos deja configurar esta funcionalidad está la parte de Resources que nos ayuda a manejar las restricciones de recursos físicos a los que va a tener acceso el contenedor una vez que esté en ejecución.

Entonces, adentro de la configuración de Resources tenemos dos campos que son siempre opcionales:

Limits
- Como su nombre lo especifica, nos permite establecer un límite de memoria ram y nucleos del cpu para el contenedor
Reservations
- También muy descriptivo, nos da la posibilidad de reservar espacio de manera exclusiva para la memoria RAM y núcleos del CPU

Ahora miremos un ejemplo concreto y sencillo:

version: '3.8'

services:
  web:
    build: .
    volumes:
      - .:/code
    ports:
      - "8081:80"
    command: "python3 manage.py runserver 0.0.0.0:80"
    deploy:
        resources:
            limits: #Definiendo el límite de acceso a memoria RAM y núcleos CPU
              cpus: 0.50
              memory: 512M
            reservations: #Reservando espacio de memoria RAM y núcelos del CPU
              cpus: 0.25
              memory: 128M 

  database:
    image: postgres:14.1-alpine
    restart: always
    environment:
      POSTGRES_DB: dockerized
      POSTGRES_USER: postgres
      POSTGRES_PASSWORD: postgres
      PG_SYSTEM_MAX_CONNECTIONS: 500
    ports:
      - '5432:5432'
    volumes: 
      - database:/var/lib/postgresql/data

volumes:
  database:

Ahora sí, con el comando stats, que nos sirve para inspeccionar en tiempo real la información de los contenedores que están en ejecución, vamos a comprobar que todo este funcionando como lo especificamos:

docker stats

Escribiendo un custom hasher para llevar contraseñas de un sistema hecho en Java/Grails a Django

Nahuel Segovia — Tue, 15 Nov 2022 20:11:40 +0000

Contexto: Cliente con un sistema hecho en Java/Grails pide que se re-escriba el proyecto en Django, ya que se les dificultaba encontrar desarrolladores para poder mantenerlo.

Problema: Muchos, pero uno de ellos era que la forma en que se hasheaban las contraseñas de los usuarios en la plataforma legacy no coinciden con las que trae Django por defecto, por lo que no encontrábamos la forma de llevar esas contraseñas al proyecto nuevo.

Cosas que se intentaron:

A través de settings.py, especifcarle a django en el array de configuración PASSWORD_HASHERS que utilice sha256 como algoritmo de cifrado para las contraseñas

Problema: escribía las contraseñas pero además les agregaba un salt y otros caracteres que no nos permitía hacer coincidir con los hashes que teníamos en producción

Crear una clase nueva que extienda de AbstractUser y pisarle los métodos en donde escribía la contraseña de los usuarios, para que cuando vayamos a crear los usuarios esta los haga como requeríamos(muy mala idea, pero hay que pensar fuera de la caja cuando sea posible)

Problema: por supuesto que se rompía por todos lados y lo descarté rápidamente

Momento de reflexión: Decidí que debería entender un poco más de como funcionaba así que primero fui a buscar código en donde estábamos creando usuarios de forma automática en el momento en que el proyecto se levanta en los contenedores. Descubrí que estábamos usando el método instanciaUsuario.set_password para crearle la contraseña a un usuario con permisos de administración.

Fui al código y llegué hasta el archivo base_user.py que contiene ese método, y me encontré con esto:


def set_password(self, raw_password):
        self.password = make_password(raw_password)
        self._password = raw_password

El método make_password me llevó hasta el archivo hashers.py, en donde se encuentran diferentes clases que contienen la configuración para diferentes tipos de algoritmos más alguna que otra cosita que le agregaba Django al algoritmo, como salt y caracteres, etc.

Todos extendían de la clase BasePasswordHasher, y ya que estamos pego el código:


class BasePasswordHasher:
    """
    Abstract base class for password hashers

    When creating your own hasher, you need to override algorithm,
    verify(), encode() and safe_summary().

    PasswordHasher objects are immutable.
    """
    algorithm = None
    library = None
    salt_entropy = 128

    def _load_library(self):
        if self.library is not None:
            if isinstance(self.library, (tuple, list)):
                name, mod_path = self.library
            else:
                mod_path = self.library
            try:
                module = importlib.import_module(mod_path)
            except ImportError as e:
                raise ValueError("Couldn't load %r algorithm library: %s" %
                                 (self.__class__.__name__, e))
            return module
        raise ValueError("Hasher %r doesn't specify a library attribute" %
                         self.__class__.__name__)

    def salt(self):
        """
        Generate a cryptographically secure nonce salt in ASCII with an entropy
        of at least `salt_entropy` bits.
        """
        # Each character in the salt provides
        # log_2(len(alphabet)) bits of entropy.
        char_count = math.ceil(self.salt_entropy / math.log2(len(RANDOM_STRING_CHARS)))
        return get_random_string(char_count, allowed_chars=RANDOM_STRING_CHARS)

    def verify(self, password, encoded):
        """Check if the given password is correct."""
        raise NotImplementedError('subclasses of BasePasswordHasher must provide a verify() method')

    def _check_encode_args(self, password, salt):
        if password is None:
            raise TypeError('password must be provided.')
        if not salt or '$' in salt:
            raise ValueError('salt must be provided and cannot contain $.')

    def encode(self, password, salt):
        """
        Create an encoded database value.

        The result is normally formatted as "algorithm$salt$hash" and
        must be fewer than 128 characters.
        """
        raise NotImplementedError('subclasses of BasePasswordHasher must provide an encode() method')

    def decode(self, encoded):
        """
        Return a decoded database value.

        The result is a dictionary and should contain `algorithm`, `hash`, and
        `salt`. Extra keys can be algorithm specific like `iterations` or
        `work_factor`.
        """
        raise NotImplementedError(
            'subclasses of BasePasswordHasher must provide a decode() method.'
        )

    def safe_summary(self, encoded):
        """
        Return a summary of safe values.

        The result is a dictionary and will be used where the password field
        must be displayed to construct a safe representation of the password.
        """
        raise NotImplementedError('subclasses of BasePasswordHasher must provide a safe_summary() method')

    def must_update(self, encoded):
        return False

    def harden_runtime(self, password, encoded):
        """
        Bridge the runtime gap between the work factor supplied in `encoded`
        and the work factor suggested by this hasher.

        Taking PBKDF2 as an example, if `encoded` contains 20000 iterations and
        `self.iterations` is 30000, this method should run password through
        another 10000 iterations of PBKDF2. Similar approaches should exist
        for any hasher that has a work factor. If not, this method should be
        defined as a no-op to silence the warning.
        """
        warnings.warn('subclasses of BasePasswordHasher should provide a harden_runtime() method')

Podemos ver después de esta clase, que tenemos PBKDF2PasswordHasher, que ya en los comentarios nos dice esto:


"""
    Secure password hashing using the PBKDF2 algorithm (recommended)

    Configured to use PBKDF2 + HMAC + SHA256.
    The result is a 64 byte binary string.  Iterations may be changed
    safely but you must rename the algorithm if you change SHA256.
    """

La primera parte del código nos muestra como crean el hash para guardarlo en la base de datos y de que manera lo hacen


algorithm = "pbkdf2_sha256"
    iterations = 320000
    digest = hashlib.sha256

    def encode(self, password, salt, iterations=None):
        self._check_encode_args(password, salt)
        iterations = iterations or self.iterations
        hash = pbkdf2(password, salt, iterations, digest=self.digest)
        hash = base64.b64encode(hash).decode('ascii').strip()
        return "%s$%d$%s$%s" % (self.algorithm, iterations, salt, hash)

    def decode(self, encoded):
        algorithm, iterations, salt, hash = encoded.split('$', 3)
        assert algorithm == self.algorithm
        return {
            'algorithm': algorithm,
            'hash': hash,
            'iterations': int(iterations),
            'salt': salt,
        }

    def verify(self, password, encoded):
        decoded = self.decode(encoded)
        encoded_2 = self.encode(password, decoded['salt'], decoded['iterations'])
        return constant_time_compare(encoded, encoded_2)

El método encode es quien hashea nuestras contraseñas, y verify, parecía ser el encargado de comprobar el hash guardado con el que se le pasa en el login.

Solución: Crear nuestra propia clase para cifrar nuestras contraseñas con sha256:

from django.contrib.auth.hashers import BasePasswordHasher
from django.utils.crypto import constant_time_compare


class CustomizedPasswordHasher(BasePasswordHasher):
    algorithm = 'sha256' #NOTA: SI O SI HAY QUE PASARLE EL ALGORITMO
    def encode(self, password, salt):
        assert password is not None
        hash = hashlib.sha256(password.encode()).hexdigest()
        return hash

    def verify(self, password, encoded):
        encoded_2 = self.encode(password, '')
        return constant_time_compare(encoded, encoded_2)

De esta forma nos aseguramos de guardar las contraseñas solo en sha256, sin salt, sin caracteres especiales, tal y cual como estaban en producción. Solo nos queda agregar nuestro hasher a la configuración del proyecto en settings.py:

PASSWORD_HASHERS = [
    'backend.utils.CustomizedPasswordHasher',
]

Resultado:

Documentación oficial de Django acerca de PASSWORD_HASHERS:

https://docs.djangoproject.com/en/4.1/ref/settings/#std-setting-PASSWORD_HASHERS

Django eficiente - select_related

Nahuel Segovia — Wed, 31 Aug 2022 22:31:07 +0000

Uno de los grandes desafíos de una aplicación cuando esta está siendo utilizada en producción, es que tenga un tiempo de respuesta razonable.

Empecemos con un problema sencillo, supongamos que tenemos un modelo de subforo de un foro, en donde cada sufbforo puede tener un comentario, y ese comentario a su vez puede pertenecer a un subforo en concreto.


class SubForo(models.Model):
name = models.CharField(max_length=255, null=True)
creator = models.CharField(max_length=255, null=True)
hashtags = models.CharField(max_length=255, null=True)


class Comentario(models.Model):
comment = models.TextField()
subforo = models.ForeignKey(SubForo, on_delete=models.CASCADE)

Ahora para poder listar todos los comentarios con el foro al que pertenece, lo más común es encontrar código como este:

@api_view(["GET"])
@permission_classes([permissions.IsAuthenticated])
def obtener_comentarios_foro(request):
  comentarios = Comentario.objects.all()
  comentarios_con_foro = {}
  for comentario in comentarios:
      comentarios_con_foro['comentario'] = comentario.comment
      comentarios_con_foro['foro'] = comentario.subforo.name
  print(comentarios_con_foro)

El problema de esto es que estamos accediendo a la base de datos por lo menos, dos veces:

Cuando vamos a buscar los comentarios
Por cada comentario vamos a ir a buscar el subforo al que pertenece

es decir que si tengo 10 comentarios, iríamos a buscar todos los comentarios y además hacer una query para ir a buscar el subforo al que pertenece ese comentario, la querie seria algo como esto:

SELECT
 `comentario`.`id`,
 `comentario`.`comment`,
 `comentario`.`subforo_id`
FROM
 `comentario`;

#QUERIES A EJECUTAR UNA VEZ QUE OBTENEMOS EL COMENTARIO CON SU SUBFORO_ID CORRESPONDIENTE:
SELECT `subforo`.`id`, `subforo`.`name`, `subforo`.`creator`, `subforo`.`hashtags` FROM `subforo` WHERE `subforo`.`id` = 1 LIMIT 21;
SELECT `subforo`.`id`, `subforo`.`name`, `subforo`.`creator`, `subforo`.`hashtags` FROM `subforo` WHERE `subforo`.`id` = 1 LIMIT 21;
SELECT `subforo`.`id`, `subforo`.`name`, `subforo`.`creator`, `subforo`.`hashtags` FROM `subforo` WHERE `subforo`.`id` = 1 LIMIT 21;
SELECT `subforo`.`id`, `subforo`.`name`, `subforo`.`creator`, `subforo`.`hashtags` FROM `subforo` WHERE `subforo`.`id` = 2 LIMIT 21;
SELECT `subforo`.`id`, `subforo`.`name`, `subforo`.`creator`, `subforo`.`hashtags` FROM `subforo` WHERE `subforo`.`id` = 2 LIMIT 21;
SELECT `subforo`.`id`, `subforo`.`name`, `subforo`.`creator`, `subforo`.`hashtags` FROM `subforo` WHERE `subforo`.`id` = 3 LIMIT 21;
SELECT `subforo`.`id`, `subforo`.`name`, `subforo`.`creator`, `subforo`.`hashtags` FROM `subforo` WHERE `subforo`.`id` = 4 LIMIT 21;
SELECT `subforo`.`id`, `subforo`.`name`, `subforo`.`creator`, `subforo`.`hashtags` FROM `subforo` WHERE `subforo`.`id` = 4 LIMIT 21;
SELECT `subforo`.`id`, `subforo`.`name`, `subforo`.`creator`, `subforo`.`hashtags` FROM `subforo` WHERE `subforo`.`id` = 4 LIMIT 21;
SELECT `subforo`.`id`, `subforo`.`name`, `subforo`.`creator`, `subforo`.`hashtags` FROM `subforo` WHERE `subforo`.`id` = 5 LIMIT 21;

Quizás en un proyecto chico esto no sea un gran problema, pero ahora imaginemos que tenemos 600 comentarios en el subforo… sería totalmente ineficiente hacer un select por cada uno de esos comentarios.

¿La solución? Usar select_related, de esta forma vamos a hacer una query mucho más larga pero el tiempo de respuesta será mucho menor:

@api_view(["GET"])
@permission_classes([permissions.IsAuthenticated])
def obtener_comentarios_foro(request):
  comentarios = Comentario.objects.select_related('subforo').all()
  comentarios_con_foro = {}
  for comentario in comentarios:
      comentarios_con_foro['comentario'] = comentario.comment
      comentarios_con_foro['foro'] = comentario.subforo.name
  print(comentarios_con_foro)

la query nos quedaría de esta manera:

SELECT
"comentario"."id",
"comentario"."comment",
"comentario"."subforo_id",
"subforo"."id",
"subforo"."name",
"subforo"."creator",
"subforo"."hashtags",
FROM
 "comentario"
 INNER JOIN "subforo" ON (
   "comentario"."subforo_id" = "subforo"."id"
 )

Demostraciones de un proyecto con datos reales

Tiempo de respuesta de una api utilizando select_related:

Tiempo de respuesta de una api sin utilizar select_related:

Configurando JWT en Django Rest Framework

Nahuel Segovia — Tue, 26 Apr 2022 16:32:55 +0000

Lo primero que tenemos que hacer es instalar simplejwt:

pip install djangorestframework-simplejwt

en este caso yo lo tengo configurado junto a mi archivo requirements.txt:

Django==4.0.0
django-cors-headers
django-getenv
djangorestframework==3.12.2
psycopg2-binary
djangorestframework-simplejwt

Una vez instalada la dependencia vamos a nuestro proyecto, y en urls.py agregamos las siguientes rutas:

path('api/token/', TokenObtainPairView.as_view(), name='token_obtain_pair'),
path('api/token/refresh/', TokenRefreshView.as_view(), name='token_refresh'),

En settings.py en las configuraciones de REST_FRAMEWORK definimos la autenticación que vamos a usar por defecto con el framework:

REST_FRAMEWORK = {
    'DEFAULT_AUTHENTICATION_CLASSES': (
        'rest_framework_simplejwt.authentication.JWTAuthentication',
    ),

    'DEFAULT_PERMISSIONS_CLASSES':(
        'rest_framework.permissions.IsAuthenticated'
    )
}

Sin olvidarnos que en INSTALLED_APPS tenemos que indicar que vamos a usar rest_framework:

INSTALLED_APPS = [
    'django.contrib.admin',
    'django.contrib.auth',
    'django.contrib.contenttypes',
    'django.contrib.sessions',
    'django.contrib.messages',
    'django.contrib.staticfiles',
    'rest_framework',
]

Una vez hecho esto, en nuestras views podemos pedir que para que alguien haga una petición hacia nuestro endpoint, como mínimo tiene que estar autenticado, y el método de autenticación que configuramos es el de JWT:

from django.http import JsonResponse
from rest_framework import permissions, status
from rest_framework.decorators import api_view, permission_classes


@api_view(["POST"])
@permission_classes([permissions.IsAuthenticated])
def create_post(request):
    return JsonResponse({'msg': 'todo funcionando'})

Probando la configuración:

Sin autenticación:

Autenticándonos para obtener el token

Utilizando el token para hacer peticiones

Json Web Token, ¿Qué es?

Nahuel Segovia — Sun, 17 Apr 2022 02:39:54 +0000

¿Qué es JWT o Json Web Token?

JSON Web Token es un estándar abierto basado en JSON propuesto por IETF para la creación de tokens de acceso que permiten la propagación de identidad y privilegios o claims en inglés.

Contiene toda la información importante sobre una entidad, lo que significa que no hace falta consultar una base de datos ni que la sesión tenga que guardarse en el servidor (sesión sin estado)

¿Cómo se compone un JWT?

Un token JWT se compone de 3 partes codificadas en base64 que están separadas por un punto. Estas tres partes son las siguientes:

Header:

Contiene generalmente 2 valores y nos proporciona información sobre tipo de token y el tipo de cifrado que se utilizó para generarlo:

{ "alg": "HS256", "typ": "JWT" }

Payload:

Contiene los datos del usuario y sus privilegios, aunque también podemos enviar otros tipos de datos(algo que no es recomendable)

Signature:

Sería la firma que nos permite verificar que quien está tratando de hacer algo con nuestra aplicación sea la persona con los permisos suficientes. Esta firma se crea a través de la unión de las anteriores partes (Header + Paylod) codificados en base64 y una clave secreta que generalmente es proporcionada por el servidor, esto hace que el hash generado sea único y si alguien intenta modificarlo, su valor va a cambiar, por lo que no ya no va a servir para hacer peticiones en nuestro server.

Generando un JWT en pseudocódigo(Platzi):

key =  'clavesecreta'
unsignedToken = base64Encode(header) + '.' + base64Encode(payload)
signature = SHA256(key, unsignedToken)
token = unsignedToken + '.' + signature

Token final:

eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJ0b2tlbl90eXBlIjoiYWNjZXNzIiwiZXhwIjoxNjUwMTYyNzQxLCJpYXQiOjE2NTAxNjI0NDEsImp0aSI6Ijg0ZjhjMDlkZDE2MzRiMGNhZDlhMzUzZTNmODNlMDA4IiwidXNlcl9pZCI6MX0.qflyviX71uzLknz5YAjviVr1Bya-Z1e9AGXuHKuwEFc

Algo bueno es que podemos jugar con la página oficial de JWT y ver la composición de un token de una manera mucho más entendible:

POO - Encapsulamiento

Nahuel Segovia — Wed, 23 Mar 2022 03:15:13 +0000

Cuando hablamos de encapsulación nos referimos generalmente a definir grados o niveles de acceso y modificación para nuestros métodos y atributos. En Python específicamente no existe como tal una 'protección' real hacía los atributos de una clase, ya que estos se pueden acceder de forma pública simplemente a través de la instancia. Lo que se hace para evitar que estos atributos sean cambiados es usar convenciones ya definidas por Python que nos permiten HACER SABER que esos atributos pueden ser accedidos solamente por la clase en la que se encuentran o por las clases que heredan de la misma:

self.__body < de esta forma, con dos guiones bajos, especificamos que únicamente vamos a poder acceder a este atributo estando dentro de la clase en la que se declaró,lo que se conoce como ACCESO PRIVADO

self._body < de esta forma, con un guion bajo, especificamos que la propiedad puede ser accedida tanto como la clase en donde fue declarada, como en las que hereden de esta, lo que se conoce como ACCESO PROTEGIDO

¿Por qué en Python no existe como tal una forma real de proteger a estos atributos?

Porque en realidad todos estos atributos son de acceso público, ya que podemos acceder a ellos y modificarlos a través de la instancia simplemente llamando a la misma clase:

post = Post('Titulo del post', 'contenido del post', 'programacion', 'Nahuel')

*Para el caso donde el acceso sea "PRIVADO" post.Post._title = 'Cambiando el valor del título'

*Para el caso donde el acceso sea "PROTEGIDO" post._Post._title = 'Cambiando el valor de título'

def __init__(self, title, body, hashtags, author):
        self._title = title
        self._body = body
        self._hashtags = hashtags
        self._author = author

    def get_name(self): return self._title
    def get_body(self): return self._body
    def get_hashtags(self): return self._hashtags
    def get_author(self): return self._author`

POO - Abstracción

Nahuel Segovia — Wed, 23 Mar 2022 03:08:24 +0000

Según una definición que encontré en internet, abstraer algo significa: separar por medio de una operación intelectual(pensar)
un rasgo o una cualidad(en nuestro caso métodos y atributos) para
analizarlos aisladamente. En palabras más simples aún, sería enfocarnos en eliminar o ignorar detalles de algo para obtener los puntos más relevantes para su funcionamiento.

¿Pero como nos sirve todo lo de arriba?

Bien, supongamos nuevamente que tenemos un celular moderno, este va a poder:

- Llamar
- Enviar SMS
- Instalar aplicaciones
- Sacar fotos
- Grabar video

Y para realizar todas estas cosas el celular necesita:
- Batería
- Placa wifi 
- Camára de foto y video
- Sistema operativo funcional(Android, iOS)

De esta forma vemos como se puede realizar una abstracción de un celular, así que ahora podemos crear nuestra clase:

class Celular():

    def __init__(self, name, wifi_card, battery, camera):
        self._name = name
        self._battery = battery
        self._wifi_card = wifi_card
        self._camera = camera

    def call(self, number:int): print('Calling'+str(number)+'...')

    def send_sms(self, number:int, msg:str): print('Sending '+msg+' to ' +str(number))

    def install_app(self, app_name:str): print('Installing '+app_name+' app...')

    def take_a_photo(): print('Taking a photo...')

    def record_video(): print('Recording video...')

Testeando endpoints con Django Rest Framework

Nahuel Segovia — Wed, 23 Feb 2022 19:57:04 +0000

En mi trabajo decidimos empezar a utilizar tests unitarios como una manera rápida de identificar errores a la hora de llevar algo a producción.

Lo primero que hice fue testear una de las primeras funcionalidades del proyecto que yo mismo realicé(es un proyecto muy nuevo) y encontré diferentes maneras de hacerlo.

Endpoint a testear:
- /topic/create/
Permisos necesarios:
- Estar logueado
- Ser administrador

Lo primero que tenemos que hacer es importar lo siguiente adentro del archivo test.py del proyecto:

from rest_framework.test import APITestCase, APIClient
from django.urls import reverse
from rest_framework import status
from .models import *

Lo siguiente es crear una clase en donde vamos a reunir todos los casos de testeos:

class TestTopics(APITestCase):

es importante que esa clase herede de APITestCase.

Una vez que tenemos la clase vamos a crear el método de configuración: acá adentro vamos a escribir todas las configuraciones necesarias para poder testear/probar nuestro endpoint, crear usuarios, asignarle permisos, crear grupos etc..

class TestTopics(APITestCase):
    def setUp(self):

        administrator_group = Group(name='administrador')
        administrator_group.save()

        administrator_group = Group.objects.get(name='administrator')

        admin1 = User(username="administradorprueba", first_name="Admin", last_name="Dos")
        admin1.set_password("administradorprueba")
        admin1.save()
        admin1.groups.add(administrator_group)

DATO IMPORTANTE: cuando vayamos a testear nuestro endpoint y este necesite que un usuario se encuentre logueado y con todos sus permisos, no hace falta que hagamos una petición para loguearnos y obtener el token para después hacer la petición hacia nuestro endpoint. DRF nos trae por defecto en APIClient un método llamado force_authenticate al que nosotros le pasamos la instancia de nuestro usuario y se loguea por nosotros.

    def test_create_topic_only_name_and_description(self):

        client = APIClient()
        data = User.objects.get(username='administradorprueba')
        client.force_authenticate(user=data)

        response = client.post(
                    reverse('create_topic'), {
                    'name': 'productos recomendados',
                    'description': 'solo productos bien rankeados por la comunidad',
                },
                format='json')

        self.assertEqual(response.status_code, status.HTTP_200_OK)

Como ven, ahora a través de client podemos enviar la petición después de habernos logueado con force_authenticate.

En esta línea reverse('create_topic') lo que estamos haciendo es buscar el endpoint con el name="create_topic" definido adentro de nuestro script urls.py

Actualizando los datos de un modelo en Django con un loop

Nahuel Segovia — Wed, 16 Feb 2022 20:23:20 +0000

Buenas... últimamente se me ocurrió empezar a documentar un poquito algunos de los problemas con los que me encuentro día a día. Quizás en algún momento vas a necesitar actualizar los datos de un modelo y no tenés ganas de andar escribiendo campo por campo. Acá dejo una función que realicé y terminó siendo bastante útil para el proyecto en el que estoy trabajando:

if request.POST['id']:
    post = Post.objects.get(id=request.POST['id'])
    try:
       for request_data_in_array in request.POST:
           request_post_values = request.POST[request_data_in_array]
           setattr(post, request_data_in_array, request_post_values)
           post.save()

Los pasos/lógica que seguí es la siguiente:
_ Si existe id, buscamos un post con el id proporcionado

_ Recorremos la cantidad de datos proporcionados(en este caso son campos del modelo Post)

_ Una vez que los recorremos obtenemos el valor de cada uno adentro del loop. Esto lo hace cuando le solicitamos al objeto POST que nos traiga cada uno de los campos recibidos: < request.POST[request_data_in_array] > ahora a estos valores los tenemos dentro de una variable.

_ La función setattr(object, property_name, values) nos permite asignar valores a las propiedades de un objeto, tan solo es necesario pasarle la istancia del objeto al que queremos cambiar, el nombre de la propiedad y el valor. En este caso tenemos varias propiedades y varios valores para esas propiedades, entonces lo hacemos también dentro del loop para que lo haga con todos.

_ Una vez terminado podemos guardar con el método .save() y tendremos nuestro modelo actualizado ;)

Simular un array asociativo(map) con tipos dinámicos en Golang

Nahuel Segovia — Mon, 08 Nov 2021 18:57:04 +0000

Seguramente si venís de lenguajes de programación con tipado dinámico como Javascript o Python, te preguntaste como es posible guardar en un map distintos tipos de datos incluso sin saber que tipo de dato estás guardando. La respuesta es que si nos llevamos solamente por las reglas que Golang nos impone para programar, esto no se podría ni debería hacer. Pero por obvias razones en algún momento vas a necesitar hacerlo, y para lograrlo hay que utilizar interfaces vacías.

¿Por qué utilizar interfaces vacías? Porque estas pueden almacenar cualquier tipo de dato, tan simple como eso.

Vamos a ver un ejemplo sencillo:


claveValor := make(map[string]interface{})
claveValor["uno"] = 4
claveValor["dos"] = false
claveValor["tres"] = "Esto es una cadena"
claveValor["cuatro"] = 20.54

fmt.Println(claveValor)

=> map[cuatro:20.54 dos:false tres:Esto es una cadena uno:4]

Por lo que ya sabes, sino sabes que tipo de datos vas a almacenar en un map, o simplemente te es indiferente, cuando lo declares especificale que e tipo de valor es una interface y te olvidas del problema.

Incluso si queremos ponernos más sucios, podemos declarar que tanto clave como valor serán interfaces, entonces da igual todo:

claveValor := make(map[interface{}]interface{})

claveValor[5] = 4
claveValor[true] = false
claveValor["tres"] = "Esto es una cadena"
claveValor["cuatro"] = 20.54

fmt.Println(claveValor)
=> map[true:false 5:4 cuatro:20.54 tres:Esto es una cadena]

Porsupuesto que esto es solo para mostrar lo que se puede logar, no creo que sea muy recomendable hacer esto último.