DEV Community: Marco Ramírez

Pruebas Unitarias en Laravel con Sanctum

Marco Ramírez — Sat, 07 Sep 2024 00:11:49 +0000

Qué hay, mis niños, espero que estén pasándola de maravilla y que estén teniendo una gran semana, e incluso un mejor mes. Este post lo escribí dentro de thedevgang.com y lo comparto por acá para que tenga más engagement con todos ustedes. Espero que les guste :3

Ya es el último jalón del 2024 y de otras cosas más, de las cuales no vale la pena platicar en este momento. Pues bien, en una publicación anterior del blog hicimos la migración de la librería de autenticación Passport a Sanctum, sin embargo, ahora, me gustaría ahondar en las pruebas unitarias de algunos endpoints y así poder ejecutarlas en algún pipeline de integración contínua como Github Actions.

Previamente, había escrito sobre cómo hacer pruebas unitarias con Passport en dev.to, este post lo puedes encontrar aquí , en donde expongo también qué son las pruebas unitarias y aspectos básicos sobre su implementación en Laravel. En este post, abarcaremos lo siguiente:

Pruebas unitarias ya con Sanctum implementado
Probando algunos endpoints

Pruebas unitarias con Sanctum implementado

Para el caso de este post, tengo algunos endpoints que armé para un proyecto alterno que he estado desarrollando desde hace unos meses. Este proyecto tiene las siguientes características en cuanto al framework y demás:

Laravel 11 con Sanctum 4
PHPUnit 10
Laravel Sail como ambiente de desarrollo

Probaremos en este caso tres endpoints que armamos para el proceso de autenticación de esta app, primero haremos lo pertinente con el siguiente método:

public function login(Request $request)
    {
        $validator = Validator::make($request->all(), [
            'email' => 'required|email',
            'password' => 'required',
            'device_id' => 'required',
        ]);

        if ($validator->fails()) {
            return response()->json(['success' => false, 'error' => $validator->errors()], $this->badRequestStatus);
        }

        $result = $this->getToken(request('email'), request('password'), request('device_id'));

        if ($result['success'] == true) {
            return response()->json($result, $this->successStatus);
        } else {
            return response()->json(['success' => false, 'error' => 'Unauthorized'], $this->unauthorizedStatus);
        }
    }

Este método es el que gestiona por completo el proceso de login de nuestra app, sin embargo el registro no se inclute en este snippet, ese será el próximo a probar. En este caso, lo hemos confirmado y al parecer funciona correctamente, pero para poder cerciorarnos de ello, armaremos sus respectivas pruebas.

Primeramente con terminal ingresa este comando:

php artisan make:test UserTest --unit

Esto te creará un archivo UserTest en la carpeta tests/Unit, el cual estará completamente “en blanco”, como el siguiente:

<?php

namespace Tests\Unit;

use PHPUnit\Framework\TestCase;

class ExampleTest extends TestCase
{
    /**
     * A basic test example.
     */
    public function test_basic_test(): void
    {
        $this->assertTrue(true);
    }
}

Borra el método test_basic_test(), no lo necesitaremos. En este caso digo que está en blanco porque es únicamente el mock de nuestras pruebas unitarias y para esta ocasión será el que usemos para los métodos antes mencionados. Ahora bien, antes de comenzar a programar las pruebas, necesitamos asegurarnos de los casos de uso que estaremos ejecutando y probando, por lo tanto tenemos los siguientes casos de uso a probar:

Login correcto.
Login inválido ingresando todos los datos.
Registro correcto.
Registro del perfil correcto.
Registro del perfil erróneo por no ingresar datos.
Perfil no encontrado.
Registro del perfil correcto y su retroalimentación.

Una vez enumerados los casos de uso, tenemos en cuenta de que los que cubren en este caso el método antes mencionado son los casos 1 y 2, por lo que procederemos con ellos.

Preparación de las pruebas

Ahora bien, antes de comenzar a codificar las pruebas, necesitamos configurar las mismas para que puedan ser ejecutadas correctamente, para ello crearemos dentro del archivo UserTest el método setUp, el cual realiza la ejecución de instrucciones previo a ejecutar las pruebas unitarias. Aquí es donde nosotros podemos indicarle al sistema que debe realizar las migraciones y poder comenzar con las mismas en caso de requerir datos, así como de asignación de valores en variables. El método setUp que crearemos está estructurado de esta manera:

public function setUp(): void
    {
        parent::setUp();
        $this->faker = \Faker\Factory::create();

        $this->name = $this->faker->name();
        $this->password = 'password';
        $this->email = 'valid@test.com';
        $this->deviceId = $this->faker->uuid();

        Artisan::call('migrate:fresh', ['-vvv' => true]);
    }

El setUp hará lo siguiente:

Crea una instancia de Faker, una librería para simular ingreso de datos de diversos tipos de variables.
Creamos un nombre ficticio
Asignamos el password y el correo electrónico a valores predeterminados.
Asignamos un ID de dispositivo ficticio igualmente con el faker.
Correrá las migraciones de la base de datos

Arriba de este método, declara las variables globales que usaremos para todas nuestras pruebas:

public $faker;
public $name;
public $email;
public $password;
public $deviceId;

Desarrollo de las pruebas unitarias

Para la prueba 1, necesitamos asegurarnos que el login es correcto invocando el endpoint al que llamaremos en nuestra app. Crearemos el método test_login_success y quedaría de la siguiente manera:

public function test_login_success()
    {
        Artisan::call('db:seed', ['-vvv' => true]);

        $body = [
            'email' => $this->email,
            'password' => $this->password,
            'device_id' => $this->deviceId
        ];

        $this->json('POST', '/api/login', $body, ['Accept' => 'application/json'])
            ->assertStatus(200)->assertJson([
                "success" => true
            ]);
    }

Este método, primeramente alimentará la base de datos con los catálogos pertinentes para poder confirmar que los mismos existen sin problemas. Después asignará el body y enviará los datos por medio de un request POST, al enviarlo, revisará que el status que devuelva su llamada es 200 y que los datos sean conforme al arreglo solicitado para confirmar, en este caso [ “success” => true ]. Si todo sale bien y se cumplen las condiciones, se considera prueba satisfactoria, en caso contrario, se considerará fallida y es donde se tendrá que revisar nuevamente el código.

Ahora bien, haremos el caso de uso 2. Para ello crea un método llamado test_login_error_with_data_ok e ingresa el siguiente código:

public function test_login_error_with_data_ok()
    {
        Artisan::call('db:seed', ['-vvv' => true]);

        $body =  [
            'email' => 'invalid@test.com',
            'password' => 'password',
            'device_id' => $this->deviceId
        ];

        $this->json('POST', '/api/login', $body)
            ->assertStatus(401)->assertJson([
                "success" => false
            ]);
    }

A diferencia del anterior, en este caso, se le entregan datos erróneos y se solicita que confirme que el endpoint devuelva un error 401, así como un body [“success” => false ], esto con el fin de que se confirme que el sistema deniega el acceso a alguien que no tenga credenciales correctas.

Con esto, cubrimos el método presentado anteriormente y ya quedaría cubierto el método. Para poder probarlo, podemos ejecutar el siguiente comando bajo Sail:

docker compose exec laravel.test php artisan test

Te mostrará los siguientes resultados:

PASS  Tests\Unit\UserTest
  ✓ login error with data ok 0.08s  
  ✓ login success 0.16s

Si te sale todo bien como te lo he mostrado, tus unit tests han salido satisfactoriamente, pero estamos lejos de terminar. Ahora necesitamos probar el siguiente método:

public function register(Request $request)
    {
        $validator = Validator::make($request->all(), [
            'email' => 'required|email|unique:users',
            'password' => 'required',
            'c_password' => 'required|same:password',
            'device_id' => 'required',
        ]);

        if ($validator->fails()) {
            return response()->json(['success' => false, 'error' => $validator->errors()], $this->badRequestStatus);
        }

        $password = $request->password;
        $input = $request->all();
        $input['password'] = bcrypt($password);
        $user = User::create($input);

        if (null !== $user) {
            $result = $this->getToken($user->email, $password, $request->device_id);

            if ($result['success'] == true) {
                return response()->json($result, $this->successStatus);
            } else {
                return response()->json(['success' => false, 'error' => 'Unauthorized'], $this->unauthorizedStatus);
            }
        }
    }

En este caso, realizaremos el caso de uso 3, el cual solicita confirmar que el registro sea correcto, para ello, crea el método test_register_success e ingresa el siguiente código:

public function test_register_success()
    {
        $body = [
            'name' => $this->name,
            'email' => $this->email,
            'password' => $this->password,
            'c_password' => $this->password,
            'device_id' => $this->deviceId
        ];

        $this->json('POST', '/api/register', $body)
            ->assertStatus(200)->assertJson([
                "success" => true
            ]);
    }

Al igual que con el login, solicitamos que nos confirme el sistema que se nos está entregando un código 200 así como el arreglo [“success” => true], si logramos eso, ya hemos terminado, pero si te das cuenta, nos hace falta la prueba en caso de que se equivoque el usuario. Ese método te lo dejo de tarea para que puedas corroborar tus conocimientos.

Ahora bien probaremos los siguientes métodos:

public function profile()
    {
        $user = Auth::user();
        $profile = Profile::find($user->id);

        if (null !== $profile) {
            return response()->json(["success" => true, "data" => $user], $this->successStatus);
        } else {
            return response()->json(['success' => false, 'message' => 'Usuario no encontrado.'], $this->notFoundStatus);
        }
    }

public function createProfile(Request $request)
    {
        try {
            $validator = Validator::make($request->all(), [
                'first_name' => 'required',
                'last_name' => 'required',
                'birth_date' => 'required|date',
                'bloodtype' => 'required|numeric',
                'phone' => 'required',
                'gender' => 'required|numeric',
                'country' => 'required|numeric',
                'state' => 'required|numeric',
            ]);

            if ($validator->fails()) {
                return response()->json(['success' => false, 'error' => $validator->errors()], $this->badRequestStatus);
            }

            $user = Auth::user();
            $profile = Profile::where(['user_id' => $user->id])->first();

            $data = [
                'user_id' => $user->id,
            ];

            $dataInsert = array_merge($data, $request->all());

            if (null !== $profile) {
                $profile = $profile->update($dataInsert);
            } else {
                $profile = Profile::create($dataInsert);
            }


            return response()->json(["success" => true, "message" => 'Perfil actualizado correctamente.'], $this->successStatus);
        } catch (QueryException $e) {
            return response()->json(["success" => false, "message" => 'Error al actualizar el perfil.'], $this->internalServerErrorStatus);
        }
    }

Este par de métodos son los referentes a la gestión del perfil del usuario y su retroalimentación, por lo que los casos de uso que debemos probar son del 4 al 7. Para el caso 4, debemos crear un nuevo método llamado test_register_profile_success y agregamos el siguiente código:

public function test_register_profile_success()
    {
        $body = [
            'first_name' => $this->faker->firstName,
            'last_name' => $this->faker->lastName,
            'birth_date' => '1987-10-10',
            'bloodtype' => 1,
            'phone' => $this->faker->phoneNumber,
            'gender' => 1,
            'country' => 1,
            'state' => 1,
        ];

        $user = User::factory()->create();
        $token = $user->createToken('TestToken')->plainTextToken;

        $response = $this->withHeaders([
            'Authorization' => 'Bearer ' . $token,
        ])->post('/api/user/profile', $body);

        $response->assertStatus(200);
    }

En esta ocasión, necesitamos declarar un arreglo que simule el contenido del cuerpo del request para que pueda ser enviado correctamente por el endpoint y una vez enviado, el confirmar que el request tiene una respuesta satisfactoria (200).

Para el caso del perfil erróneo por no ingresar datos, necesitamos agregar un nuevo método que denominaremos test_register_profile_validation_failed, el cual implementaremos de la siguiente forma:

public function test_register_profile_validation_failed()
    {
        $user = User::factory()->create();
        $token = $user->createToken('TestToken')->plainTextToken;

        $response = $this->withHeaders([
            'Authorization' => 'Bearer ' . $token,
        ])->post('/api/user/profile', []);

        $response->assertStatus(400);
    }

En este caso, es prácticamente el mismo contenido de la prueba anterior, con la diferencia que ahora le enviamos un arreglo en blanco, para poder asegurarnos que si no se están enviando los datos correctamente, no permita la creación del perfil del usuario por medio de un Bad Request error (400).

El siguiente método probará que en caso de no encontrar el perfil de algún usuario, así lo indique con un código 404, por lo que creamos otro método denominado test_obtain_profile_not_found e ingresando el siguiente código.

public function test_obtain_profile_not_found()
    {
        $user = User::factory()->create();
        $token = $user->createToken('TestToken')->plainTextToken;

        $response = $this->withHeaders([
            'Authorization' => 'Bearer ' . $token,
        ])->get('/api/user/profile');

        $response->assertStatus(404);
    }

En el modelo de negocio, nosotros al registrarnos, creamos el usuario, mas no el perfil que tiene que ser ingresado posteriormente, por lo que al momento de ejecutar la prueba unitaria, al ejecutar el request para obtener el perfil, nos enviará un código 404, comportamiento que estamos buscando para esta prueba unitaria.

Finalmente para el último caso de uso, crearemos el método test_register_profile_and_obtain para confirmar que un mismo test pueda obtener dos comportamientos en un mismo flujo. Para este caso implementaremos el siguiente código:

public function test_register_profile_and_obtain()
    {
        $body = [
            'first_name' => $this->faker->firstName,
            'last_name' => $this->faker->lastName,
            'birth_date' => '1987-10-10',
            'bloodtype' => 1,
            'phone' => $this->faker->phoneNumber,
            'gender' => 1,
            'country' => 1,
            'state' => 1,
        ];

        $user = User::factory()->create();
        $token = $user->createToken('TestToken')->plainTextToken;

        $this->withHeaders([
            'Authorization' => 'Bearer ' . $token,
        ])->post('/api/user/profile', $body);

        $response = $this->withHeaders([
            'Authorization' => 'Bearer ' . $token,
        ])->get('/api/user/profile');

        $response->assertStatus(200);
    }

En este test, implementamos dos casos de uso realizados previamente, el primero es la creación del perfil y posteriormente, retroalimentamos el perfil, indicando a PHPUnit que deseamos confirmar que el response del endpoint que retroalimenta el perfil sea satisfactoria (código 200). Igualmente podríamos realizar el assert de la inserción de datos cambiando algunas líneas de código, pero por el momento es más que suficiente.

Ya terminando las pruebas unitarias, procedemos a ejecutar el comando docker compose exec laravel.test php artisan test y confirmamos el estatus de nuestras pruebas unitarias. Si nos salen de esta forma:

PASS  Tests\Unit\UserTest
  ✓ login error with data ok.                 0.10s  
  ✓ login success.                            0.15s  
  ✓ register success.                         0.20s  
  ✓ register profile success.                 0.10s  
  ✓ register profile validation failed.       0.09s  
  ✓ obtain profile not found.                 0.10s  
  ✓ register profile and obtain.              0.10s

Las pruebas unitarias salieron satisfactorias. En caso contrario, checa lo siguiente:

El método que haya tenido broncas, checa que no sea una situación de código.
Checa que la configuración de PHPUnit sea la adecuada, ahondaremos en ello en el siguiente post.

Igualmente, voy a explicarles cómo configurar el Github Actions para ejecutar las pruebas unitarias en este y poder inclusive obtener reportes de cobertura de código y un posible despliegue contínuo. Espero que este post, aunque largo, sirva para que tengan más contexto sobre pruebas unitarias y sobre un proceso de integración y despliegue continuos.

Happy coding!

Laravel: Migrar de Passport a Sanctum

Marco Ramírez — Wed, 14 Aug 2024 06:10:45 +0000

Mis chamacos ¿me extrañaron?

Espero que no, amigos. Estuve muy alejado por cuestiones laborales de este bonito espacio, pero a la vez quisiera comentarles que he abierto un espacio dedicado a todos los apuntes, tutoriales, guías y demás posts que vaya armando aquí o en él.

Su nombre es The Dev Gang y tiene como objetivo el conglomerar ahí todo el conocimiento que les traigo en español y ¿por qué no? en un futuro que haya más colaboradores (algunos dirán ¡NO MAMES, STERNIE!, quédate aquí), pero pues la verdad es que lo hago para probar AdSense y ver si aunque sea cae para los cigarros con ello. Pueden verlo desde aquí.

Dicho lo anterior, vamos a darle con este bonito post.

Verán, al trabajar en este caso con Laravel, nos encontramos en ocasiones que deseamos tener el clásico comportamiento de autenticación de nuestras REST APIs, por lo que para ello tenemos dos alternativas: Passport y Sanctum. Passport es una librería que provee de un servidor OAUTH2 para poder realizar este trabajo. Passport hace una implementación del mismo en minutos y con la que podemos contar con tokens JWT para poder acceder a endpoints restringidos en nuestra API.

Ahora bien, Laravel, desde la versión 7, integró una nueva librería para autenticación más liviana que Passport y que a la vez puede generar múltiples tokens para los diferentes dispositivos que acceden a la API. Ahora bien, eso no quiere decir que Passport no lo haga, sin embargo, la pregunta del millón de dólares sería la siguiente:

¿Tu proceso de negocio requiere OAUTH2?

Si tu respuesta es sí, usa Passport, si no, puedes decantarte por Sanctum, que en mi opinión es más económico, en cuanto a uso de recursos del sistema se refiere y a que en este caso, las tokens generadas por Sanctum son más duraderas (hasta años) y pueden ser revocadas manualmente. La desventaja que le veo a Sanctum es que como tal, no puedes renovar token alguna, pero esa no es como tal la intención de Sanctum, misma que sí es de Passport el refrescar una token.

Si estás en el caso de uso de que no necesitas OAUTH2 o simplemente quieres cambiarte a Sanctum proveniente de Passport, entonces este post es para ti, te contaré el cómo migrarte de Passport a Sanctum en poco tiempo y poder así tener un proceso más eficiente en cuanto a autenticación se refiere.

ATENCIÓN: Migrar de Passport a Sanctum es un proceso que debes pensar muy bien y más si es que tienes muchísimos usuarios registrados en tu aplicación, puesto que el realizar dicha migración involucraría, en el caso más extremo, el solicitar a todos y cada uno de los usuarios registrados que vuelvan a ingresar una nueva contraseña, así que como decimos en México “tantéale el agua a los camotes”

Pasos para migrar

Primeramente, debemos instalar Sanctum, esto lo hacemos con la siguiente línea:

composer require laravel/sanctum

Posterior a eso, ejecuta la siguiente línea en tu terminal:

php artisan vendor:publish --provider="Laravel\Sanctum\SanctumServiceProvider"

Esto publicará los archivos de configuración de Sanctum a nuestra carpeta config. Esto incluye archivos de migración para la base de datos por lo que necesitas ejecutar:

php artisan migrate

Una vez realizada la instalación, es momento de manipular lo siguiente:

Ve al archivo config/auth.php y cambia la guard que desees tener bajo Sanctum, por lo general es la de API la que queremos tener tokenizada, por lo que tendrás:

'api' => [
    'driver' => 'passport',
    'provider' => 'users',
    'hash' => false,
 ],

Cambia passport por sanctum.

Ahora, pasa hacia la clase User, esta se encuentra dentro de tu carpeta app/models. Busca esta línea:

use Laravel\Passport\HasApiTokens;

y cámbiala por esta:

use Laravel\Sanctum\HasApiTokens;

Con esto bastará en la parte de nuestro modelo, pero es hora de meternos al servicio donde generamos el login y el registro. Comencemos con el login. Si tienes un método como el siguiente:

private function getAuthAndRefreshToken($request, $email, $password) {
        $oClient = OClient::where('password_client', 1)->first();

        $request->request->add([
            'grant_type' => 'password',
            'client_id' => $oClient->id,
            'client_secret' => $oClient->secret,
            'username' => $email,
            'password' => $password,
            'scope' => '*',
        ]);

        $response = Route::dispatch(Request::create('oauth/token', 'POST'));

        $result = json_decode((string) $response->getContent(), true);
        $result['success'] = !isset($result['error']);

        return $result;
    }

Entonces tenemos que hacer un refactor. Primero cambia de getAuthAndRefreshToken a getToken, posteriormente cambia los parámetros que recibirás a $email, $password y $deviceID. El código en su interior se va, quedando primeramente así:

private function getToken($email, $password, $deviceID)
{

}

Ingresa esta línea de código dentro del método:

$user = User::where('email', $email)->first();

Esto nos buscará el usuario con el correo electrónico que el usuario nos solicita. Si encuentra el usuario, proseguimos, en caso contrario, se regresa una respuesta de tipo 401 o 403 para denegar el acceso. Esto a la vez lo hacemos con este condicional:

if (null !== $user || !Hash::check($password, $user->password)) {
    return ['success' => false, 'message' => 'Correo electrónico o contraseña incorrectas'];
}

Además de checar de que el usuario que buscamos existe, confirmamos que la contraseña es correcta entregando el password que nos da el usuario y confirmando que los hashes coincidan.

En caso que la validación sea correcta, podemos regresar la token sin problemas de esta forma:

return [
    'success' => true,
    'access_token' => $user->createToken($deviceID)->plainTextToken
];

Con esto bastará para el login y para el registro, ahora bien, en los métodos que utilices para el controlador del login y del registro, cuida de sustituir la línea:

$result = $this->getTokenAndRefreshToken(request(), request('email'), request('password'));

Por esta otra:

$result = $this->getToken($user->email, $password, $request->device_id);

Prueba ahora tu implementación, si te entrega un objeto similar al siguiente:

{
    "success": true,
    "access_token": "1|1QjmwWuwL3EocZcErFPw0RoBLYBT6mO9GNblOVVHd1f0ed6a"
}

La migración fue completada con éxito. Ahora es tiempo de hacer limpieza. Dentro de tu implementación, puedes eliminar lo siguiente:

Las tablas que comienzan con OAUTH en la base de datos.
Cualquier referencia a Passport que encuentres en tu código.
Si hiciste la implementación de un middleware denominado CheckClientCredentials, elimínalo.
En el archivo app/Http/Kernel.php, elimina esta línea (solo aplica si implementaste el CheckClientCredentials):

'CheckClientCredentials' => \App\Http\Middleware\CheckClientCredentials::class,

Elimina del composer.json las líneas referentes a Passport.
Ejecuta composer update.

Ya con esto, puedes implementar esta autenticación como de costumbre.

Ya para terminar, debo mencionarte que las tokens generadas por Sanctum, se utilizan como tokens BEARER, por lo que estas las entregas a tu request, por medio de la cabecera Authorization de esta manera:

Authorization: Bearer 1|1QjmwWuwL3EocZcErFPw0RoBLYBT6mO9GNblOVVHd1f0ed6a

Para cada lenguaje y aplicación es diferente, por lo que dejo a tu criterio cómo la debes implementar en el frontend.

Pues bien, espero que les haya gustado este post y procuraré tenerles muchos más posts de estos y ya no ausentarme. Por el momento estaré migrando el contenido a The Dev Gang, pero como les dije, por aquí seguiré escribiendo también.

Happy coding!

Android: ¡Adios Groovy! Migrar a Kotlin nuestro build.gradle

Marco Ramírez — Tue, 30 May 2023 14:29:09 +0000

Mis niños, hoy es un día un poco ajetreado, sin embargo me he caído de la cama y tengo energía para poder escribirles unas líneas ahora sobre un tema que nosotros hemos visto desde hace tiempo en el desarrollo de Android: migrar los archivos build.gradle a Kotlin.

Recientemente, en la documentación de Google se ha notificado que Kotlin Script (KTS) será el lenguaje por default ahora para la sincronización de dependencias y que a partir de la siguiente versión de Android Studio, este proceso será por default en nuevas apps, por lo que este pequeño tutorial podrá servirte para poder migrar un pequeño proyecto de Groovy a KTS.

¿Qué es KTS?

KTS es el acrónimo para Kotlin Script, en sí el migrar de lenguaje entre Groovy y Kotlin no quiere decir que vamos a cambiar el núcleo de la importación de librerías en Android, que seguirá haciéndose con Gradle. Para los nuevos, Gradle es una herramienta de construcción de aplicaciones y automatización de rutinas compatible con diversos lenguajes de programación; esta fue construida con Java y fue el sustituto de Ant cuando llegó Android Kit Kat (o un poco antes).

Hay varias diferencias entre archivos KT y archivos KTS, una de ellas es que los archivos KT son interpretados por el compilador de Kotlin, mientras que los KTS por el soporte de Scripting de Kotlin, por lo que no necesitan una compilación previa (¿Javascript eres tú?) y en este caso es como Gradle lo tomaría en cuenta sin necesidad de compilarlo previamente.

¿Tarda mucho?

Pensarán muchos que esto es muy difícil y hasta tardado, pero en realidad es muy sencillo, pues solamente hay que cambiar cierta sintaxis dentro de los archivos build.gradle para conseguirlo, así que es hora de meter las manos al fuego

1. Cambiar el settings.gradle

Lo primero sería cambiar de nombre el archivo, agregándole la extensión .kts al archivo y tendrás la siguiente línea:

include ':app'

En KTS, debes cambiarla por las siguientes:

include("app")

Ya no hay que hacer más en este archivo e inclusive si quieres probarlo, te dejará sincronizar tus dependencias. Ahora bien, es importante que no uses comillas simples ('), pues Kotlin te las interpretará como caracteres y te marcará error. Procura siempre usar comillas (") en las cadenas de caracteres para que no tengas ningún problema.

2. Cambiar el build.gradle raíz

Ahora bien, haz lo mismo de cambiar el nombre del archivo en el build.gradle raíz y cambia lo siguiente:

Si tienes asignadas variables de versión (en un nodo ext) haz lo siguiente. Cambia lo siguiente:

buildscript {
    ext.androidGradleVersion = "8.0.1"
    ext.androidKotlinPlugin = "1.8.20"
}

Por esto:

buildscript {
    val androidGradlePlugin by extra("8.0.1")
    val androidKotlinPlugin by extra("1.8.20")
}

Aún no terminamos. Más abajo tendremos el nodo de plugins, cambiémoslo de esto:

plugins {
    id "com.android.application:$androidGradleVersion"
    id "com.android.library:$androidGradleVersion"
    id "org.jetbrains.kotlin.android:$androidKotlinPlugin"
}

a esto

plugins {
    id("com.android.application") version "${extra["androidGradlePlugin"]}" apply false
    id("com.android.library") version "${extra["androidGradlePlugin"]}" apply false
    id("org.jetbrains.kotlin.android") version "${extra["androidKotlinPlugin"]}" apply false
}

Y ya tendremos listo este archivo, ahora es tiempo de pasar al archivo (o archivos) build.gradle de nuestros módulos.

3. Cambiar el build.gradle de nuestro módulo

En este caso cambiaremos el del módulo app, en este caso, si tienes más módulo, tendrás que hacer prácticamente lo mismo para el resto. Igual que los otros 2, cámbiale el nombre al archivo agregando extensión KTS al final. Luego cambia lo siguiente:

plugins {
    id 'com.android.application'
    id 'org.jetbrains.kotlin.android'
}

por esto:

plugins {
    id("com.android.application")
    id("org.jetbrains.kotlin.android")
}

Igualmente en la parte de la definición de Android, agrega a todas las definiciones un signo de igual (=) a cada una de ellas, es decir, en lugar de esto:

android {
    namespace 'mx.dev1.deadpool'
    compileSdk 33

    defaultConfig {
        applicationId "mx.dev1.deadpool"
        minSdk 24
        targetSdk 33
        versionCode 1
        versionName "1.0"

        testInstrumentationRunner "androidx.test.runner.AndroidJUnitRunner"
    }

    buildTypes {
        release {
            minifyEnabled false
            proguardFiles getDefaultProguardFile('proguard-android-optimize.txt'), 'proguard-rules.pro'
        }
    }
    compileOptions {
        sourceCompatibility JavaVersion.VERSION_1_8
        targetCompatibility JavaVersion.VERSION_1_8
    }
    kotlinOptions {
        jvmTarget = '1.8'
    }
}

que quede esto:

android {
    namespace = "mx.dev1.foo"
    compileSdk = 33

    defaultConfig {
        applicationId = "mx.dev1.foo"
        minSdk = 24
        targetSdk = 33
        versionCode = 1
        versionName = "1.0"

        testInstrumentationRunner = "androidx.test.runner.AndroidJUnitRunner"
    }

    buildTypes {
        release {
            isMinifyEnabled = false
            proguardFiles (
                getDefaultProguardFile("proguard-android-optimize.txt"),
                "proguard-rules.pro"
            )
        }
    }
    compileOptions {
        sourceCompatibility = JavaVersion.VERSION_1_8
        targetCompatibility = JavaVersion.VERSION_1_8
    }

    kotlinOptions {
        jvmTarget = "1.8"
    }
}

Finalmente, encierra entre paréntesis los nombres de tus implementaciones para que queden en vez de esto:

dependencies {

    implementation 'androidx.core:core-ktx:1.8.0'
    implementation 'androidx.appcompat:appcompat:1.4.1'
    implementation 'com.google.android.material:material:1.5.0'
    implementation 'androidx.constraintlayout:constraintlayout:2.1.3'
    implementation 'androidx.navigation:navigation-fragment-ktx:2.5.3'
    implementation 'androidx.navigation:navigation-ui-ktx:2.5.3'
    implementation 'androidx.legacy:legacy-support-v4:1.0.0'
    implementation 'androidx.lifecycle:lifecycle-livedata-ktx:2.6.1'
    implementation 'androidx.lifecycle:lifecycle-viewmodel-ktx:2.6.1'
    testImplementation 'junit:junit:4.13.2'
    androidTestImplementation 'androidx.test.ext:junit:1.1.3'
    androidTestImplementation 'androidx.test.espresso:espresso-core:3.4.0'
}

quede esto:

dependencies {
    implementation("androidx.core:core-ktx:1.8.0")
    implementation("androidx.appcompat:appcompat:1.4.1")
    implementation("com.google.android.material:material:1.5.0")
    implementation("androidx.constraintlayout:constraintlayout:2.1.3")
    implementation("androidx.navigation:navigation-fragment-ktx:2.5.3")
    implementation("androidx.navigation:navigation-ui-ktx:2.5.3")
    implementation("androidx.legacy:legacy-support-v4:1.0.0")
    implementation("androidx.lifecycle:lifecycle-livedata-ktx:2.6.1")
    implementation("androidx.lifecycle:lifecycle-viewmodel-ktx:2.6.1")
    testImplementation("junit:junit:4.13.2")
    androidTestImplementation("androidx.test.ext:junit:1.1.3")
    androidTestImplementation("androidx.test.espresso:espresso-core:3.4.0")
}

(Best practice: Por ahorita, dejé las versiones de las dependencias "hardcoded", pero siempre tenlas en una variable adicional, en este caso los extras del paso 2.)

Ahora, una vez terminado, sincroniza tu proyecto.

Ya con esto habrás dejado actualizado tu proyecto para tenerlo con KTS y poder disfrutar de sus bondades, así como mantener actualizada tu aplicación.

Espero que este tutorial les haya servido y de ser así compártanlo con más banda para que puedan ver más contenido que les estaré trayendo en este pequeño blog.

Happy coding!

Visitando de Nuevo el Pokedex, con Jetpack Compose (Parte 1)

Marco Ramírez — Tue, 25 Apr 2023 13:38:14 +0000

Otra vez dejándolos por mucho tiempo, mis niños adorados, pero bueno, ya nos encontramos aquí escribiendo para todos ustedes. Esperando que ya después de 4 meses de este 2023 todo les esté saliendo de maravilla y que no batallen mucho con los bugs.

Si recuerdan, en un post anterior que les dejo aquí, armamos el Pokedex y lo armamos con los siguientes parámetros:

Usamos Clean Architecture para conectar la API. En esa ocasión no usamos Room.
Usamos RxJava para poder hacer los repositorios y usecases (interactors)
Usamos Navigation Component para la navegabilidad.
Usamos MVVM para poder estructurar las llamadas a la API desde nuestros Fragments o Activities.

En esta ocasión, por fin he profundizado en el conocimiento de Jetpack Compose para Android y he decidido comenzar a armar el Pokedex pero utilizando esta tecnología, al igual de hacer los siguientes cambios:

Se usará Jetpack Compose desde el principio para generar todo el workflow de nuestra aplicación.
Conservaremos la implementación de la Clean Architecture, pero ahora sí usaremos Room.
Conservaremos el uso de MVVM, sin embargo ahora lo orientaremos a Jetpack Compose en lugar de Fragmentos. En los siguientes posts lo averiguaremos.
Usaremos en lugar de RxJava, corrutinas, mismas que abonarán en el desarrollo de esta versión del Pokedex.

Oye, pero ¿qué diablos es Jetpack Compose?

Jetpack Compose es el futuro, dirían algunos y sí, es un nuevo sistema de creación de interfaces incluído para Android, el cual arma de forma declarativa todas y cada una de nuestras interfaces gráficas.

Esta forma de armar interfaces gráficas se ha establecido muy popularmente en SwiftUI (iOS) y Flutter (apps híbridas), por lo que ya prácticamente la curva de aprendizaje en cualquier sistema declarativo es muy similar y abona para poder aprender cualquiera de los otros dos, es decir, sabes Flutter, vas a agarrar Jetpack Compose y SwiftUI como pez en el agua (claro, sabiendo únicamente las sintaxis propias de cada framework).

¿Cambia la generación de interfaces en Jetpack Compose?

Definitivamente, como lo mencionamos anteriormente, Compose (así le diremos de ahora en adelante) utiliza el paradigma de programación declarativa, mismo que permite que una aplicación en vez de montar todos los componentes o widgets de la UI en un árbol de componentes, Compose únicamente aplique los cambios necesarios sin afectar el resto de la UI, haciéndolo más económico en cuanto a procesamiento y consumo de recursos.

Ahora, unos ejemplitos.

Históricamente, nosotros para generar un TextView, teníamos que hacer esto:

<TextView
    android:id="@+id/text_view_id"
    android:layout_height="wrap_content"
    android:layout_width="wrap_content"
    android:text="@string/hello" />

Ahora en Compose, el declarar un TextView se hace de la siguiente manera:

@Composable
fun Greeting() {
    Text("Hello")
}

Igualmente, si nosotros deseamos enviarle un parámetro a nuestra función Composable, lo podemos hacer y anidarla como cualquier variable en Kotlin:

@Composable
fun Greeting(name: String) {
    Text("Hello $name")
}

Ok, hasta aquí todo muy bien, pero te has de preguntar ¿cómo es que lo mando llamar a mi interfaz? Pues de la siguiente manera:

@Composable
fun AppMainScreen() {
    val scaffoldState = rememberScaffoldState()
    val coroutineScope = rememberCoroutineScope()

    Scaffold(
        scaffoldState = scaffoldState,
        topBar = {
            TopBar(
                title = "Pokedex",
                buttonIcon = Icons.Filled.Menu,
                onButtonClicked = {
                    coroutineScope.launch {
                        scaffoldState.drawerState.open()
                    }
                }
            )
        },
        drawerContent = {
            Column(
                modifier = Modifier
                    .fillMaxSize()
                    .padding(start = 8.dp, top = 32.dp),
                horizontalAlignment = Alignment.CenterHorizontally,
            ) {
                Greeting("World")
            }
        }
    )
}

El código arriba mencionado, es la forma predeterminada para mandar lo que antes conocíamos como un fragmento, sin embargo nos falta una parte importante: asegurarnos de que el punto de entrada, la Activity lance como tal nuestra pantalla, por lo que tenemos que modificar nuestra MainActivity a lo siguiente:

class MainActivity : ComponentActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContent {
            PokedexTheme {
                AppMainScreen()
            }
        }
    }
}

Con esto podremos lanzar nuestra primer aplicación móvil con Jetpack Compose y se verá así:

En el siguiente post, voy a profundizar en armar la Toolbar (que ya está en la pantalla anterior), pero quisiera explicar funciones necesarias para controlar la navegabilidad dentro de Jetpack compose y otras features que tenemos. Asimismo, ya estaremos construyendo algo un poquito más elaborado en cuanto a interfaces se refiere. Stay tuned.

Hackathones: ¿Por qué me retiré de ellos?

Marco Ramírez — Tue, 25 Oct 2022 11:43:11 +0000

¡Mis niños adorados!

Ya tiene tiempo que no les escribo y en parte es porque el trabajo no me ha dejado, pero ahorita que el insomnio me está dando con todo, aprovecho para escribir un ratito.

En esta ocasión he de escribir algo para hacer catarsis y ya dejarlo ir de mi mente (y no es un clásico post sobre ayuda psicológica, ni soy psicólogo ni este es el lugar), solo quiero platicarles mi punto de vista y opinión sobre los hackathones.

Insisto, es mi opinión y recuerden lo que dicen las opiniones son como el c*lo, todos tenemos uno, así que venga de ahí.

¿Qué ch******* es un hackathon?

Comencemos por definir un hackathon, este es un evento en donde se reúnen profesionales de TI, marketing, UX/UI, PM's y demás disciplinas y arman equipos para poder desarrollar una solución que sea benéfica para el organizador en el tiempo que dura el evento a cambio de un premio o una compensación. Que eso de la compensación es a veces y eso si el organizador tiene con qué, porque luego hay gandules que te dan como premio las gracias o como decimos en México "una larga vida y dos costales de oro". De esos ni vale la pena hablar.

Una vez definido esto, podemos comenzar a ver una problemática en este tipo de eventos: primeramente el estar en un hackathon es asumir que estás trabajando para el organizador. LITERAL. Es chingarle para esa persona o empresa hasta 72 horas sin parar (tocaré ese tema en breve) para poder tener una solución que le guste al organizador (también tocaremos eso) y así poder hacerte de un dinerito extra para ti y los miembros de tu team. Si no ganas, date de santos que en los términos y condiciones no te metan un golazo de que lo que hayas desarrollado pase a ser propiedad del organizador (aunque eso se estilaba al principio, ahorita ya no por el conocimiento que tiene la banda sobre sus derechos como creadores de software y contenido).

¡Buenísimo horas extra!

Como lo mencioné anteriormente, el estar en un hackathon es trabajar horas extra, es estar en friega loca para poder sacar una solución en base a una idea que te da el comité organizador, empresa, etc. Lo que llega a suceder es que en estos eventos lo que piden es una demo de la solución que estás proponiendo.

Así es, tienes que mostrar una demo de tu producto (por muy pinche que esté e incluso si lo quieres programar a la Bolognesa, no hay problema) y por lo general ponerte de acuerdo con los miembros del team para que realicen las tareas que necesitan. En la parte de hacer tus pininos como líder podría decir que te enriquece y te hace pensar ya no de forma individualizada, pero ahorita les cuento sobre eso. Regresemos a los entregables.

Las horas trabajando en el desarrollo suelen ser demasiado extenuantes si es que no llevas control de tus horas ni de la actividad en sí, puedes llegar a quedarte codeando día y noche y perder noción del tiempo, lo cual resulta ser demasiado contraproducente y al momento de la premiación del evento, si no ganas te llega una frustración como ninguna, puesto que el esfuerzo que diste para con el evento tiene un sublime y hermoso siga participando y más cuando los organizadores literalmente escogen a los ganadores sin ver las viabilidades de implementación o solamente la eligen por razones fuera de lo técnico y del enfoque de negocio.

Sí, en los hackathones se lleva uno demasiado esfuerzo, pero también grandes enseñanzas, comencemos por los cuentos de terror que me han sucedido.

Cuentos desde la cripta de Hackathones

En mi carrera participé de al menos 5 hackathones, unos pasaron sin pena ni gloria, otros no. Pero en dos, fueron como catastróficos y que ya después de algo de tiempo puedo sacar a la luz. No ventilaré marcas (mas que las necesarias para fines comparativos) ni nombres, pero quienes me conocen sabrán qué pedo y nuevamente les digo que es mi más sincera opinión, muchos tendrán la propia y pues qué importa, ahí les voy.

¿Eres juez de hackathon o de concurso de belleza?

Por ahí de 2018, entré a un "popular" Hackathon de CDMX con algunos amigos, incluso estuvo buenísimo en el ámbito de convivencia pues fue el primero en el que le dediqué el fin de semana completo a estar allá (yo vivo a 45 minutos del centro de la CDMX, pero se le considera Zona Metropolitana), por lo que compré hospedaje para 3 días, en ese entonces no había Airbnb y lo compré en el Holiday Inn de la Zona Rosa (¡FIESTA!).

El entusiasmo estaba desbordado, puesto que era la primera vez que tenía equipo completo y todos compartíamos la ilusión en ese momento de poder ganarnos la suma de 150 mil pesos (USD $7,500). La organización del evento, impecable, todo en orden. Conexión a Internet, muy buena. Seguridad, absoluta. En cuanto a organización hablando estrictamente de ser anfitrión, muy por encima (es lo que salva al hackathon de una hecatombe segura).

Vayamos con la solución: La solución que se pedía en ese entonces era de poder "democratizar" el sector bancario, por lo que en ese momento, propusimos el poder dar y recibir pagos por medio de un código QR con una aplicación móvil (¿les suena eso? Aclaro, para nada soy el inventor de ello, sino que quedó en una propuesta para esa empresa). Esto sin importar el cliente, incluso podrías operarlo con un teléfono celular de gama baja. Era sensacional la idea, incluso a empleados de la empresa les encantaba la idea.

Pero como dice Polo Polo: no falta el hijito de la ch******.

Llegó el momento de presentar la idea a los "jueces", en ese momento, los nervios me invadieron pues era la primera ocasión que me echaba al hombro el trabajo de todo mi team y que exponía la idea a otras personas. Creía tenerlo todo bajo control, preguntas, cómo podría esto beneficiar a los cuentahabientes, cómo podrías provisionar la aplicación, etc. Todo en orden, de hecho uno de los jueces (eran 2) estaba convencido de que la idea podía pasar a la etapa del pitching, pero el "juez" 2, salió con una pregunta que créanme que es de mentada de madre:

¿POR QUÉ DEBERÍAS GANAR ESTE HACKATHON?

Mi equipo se quedó helado. Yo peor. Contesté lo primero que me venía a la mente, la verdad. Pero cuando los jueces agradecieron y se fueron varios nos quedamos de ¿Pues qué no era un hackathon? y uno de los miembros de mi team tiempo después me dijo ni que hubiéramos estado en Miss Universo. Si bien mi reacción a la pregunta no fue la correcta y aprendí que esos individuos hacen esas preguntas para hacerte flaquear, también la pregunta fue una reverendísima ma****. Si hoy me hicieran esa pregunta les contestaría:

Pues mira, la razón principal es porque mi equipo no se está quemando las pestañas gratis.

Obviamente, perdimos.

Lo peor no paró ahí, lo peor vino cuando pues la gran mayoría, ya sin ilusiones (pero sí con mucho swag), quería retirarse del recinto, pero teníamos que quedarnos a la premiación. Obviamente, ya molestos y cansados, nadie de los equipos que no pasaron quería y empezó la silbatina, las mentadas de madre y pues hasta tuvieron que llamar la atención los del comité organizador, pero poco pudieron lograr. Terminaron dejándonos ir.

Ese día acabó en una pizzería de Buenavista. Ya mucho mejor que los 3 días de desvelo.

LO ELIJO POR MIS 🥚🥚

En 2021, se volvió a armar otra vez ese popular hackathon (cualquiera diría S.S.D.D., pero decidí darle un voto de confianza). En esta ocasión se decidió que iba a ser remoto y el equipo fue muy ameno. Aunque el requerimiento era de 6 personas, terminamos siendo 5, puesto que la sexta persona nos quedó mal al final.

El primer día recuerdo que me puse en contacto con el líder de la vertical a la que nos habíamos inscrito para que nos diera a entender qué era lo que buscaban. Se trataba de hacer una "super-app", sin embargo nos dijo que por el tipo de negocio que la empresa manejaba, no pueden ser como otras super-apps del mercado como Baz o MercadoPago, pero que querían ofrecer una app tipo WeChat.

Nos esforzamos en sacar la idea, que aunque no era como para quedar ganadora, sí tenía mucho potencial y sabíamos que por lo menos podría quedar considerada. En esta ocasión, me tocó desempeñarme, además de representante del team, como desarrollador iOS y pues como Dios me dió a entender, se hizo el desarrollo de la app.

Siento en lo personal que todo el equipo se rifó en lo que pedía. En 2020, valimos gorro porque definitivamente no entregamos (hay que saber reconocer cuando hacemos las cosas mal y tenemos la culpa). Pero en este 2021 fue una "redención" y al entregar todo en tiempo y forma era un aliciente.

Llegó el día de la premiación. 72 horas como locos armando diversas soluciones y era tiempo de saber quién era el ganador. Fueron pasando ganador por ganador, hasta llegar a la vertical de super-app. Nos quedamos otra vez helados por la decisión:

La superapp ganadora tenía todo lo que el líder dijo que no se podía poner. Todo lo que el líder de la vertical me dijo que no podía contener, la contenía.
No era aplicación móvil (es más, ni se molestaron en hacerla así).
UX/UI deplorable (hasta hay becarios que hacen mucho mejor trabajo), pero se comprende, en estos eventos lo que más falta es personal de UX/UI.

Los reclamos no se hicieron esperar. Muchos equipos se quejaron y reclamaron precisamente eso, a lo que los organizadores se limitaron a decir:

Se tenía que entregar un prototipo, por lo que se entiende la falta de calidad del mismo. (O sea podías entregar puras cochinadas y no había problema.)

Obviamente, como en estos tiempos sucede, comenzaron a tildarnos de haters. Pero lo gacho no terminaba, no conforme con elegirlos ganadores de la vertical, ese "prototipo" ganó el hackathon de ese año. Fue cuando se armó un hervidero el hilo de comentarios, donde muchísimos (incluyéndome) sí les reclamamos que las disposiciones y condiciones que habían puesto se las pasaron por el Arco del Triunfo (a la fecha sigo pensando eso). Al día de hoy, la transmisión de esta premiación ocultó los comentarios de dicho hilo.

Terminó la transmisión y decidí dejarle mi queja a la empresa y los organizadores (misma que terminó en la máquina de escribir invisible de la empresa y de los organizadores). Una vez hecho eso, me fuí a dormir.

No todo es Viernes 13

Pero no todo es zozobra, también he tenido triunfos en hackathones. En un hackathon que participé con otro colega, ganamos 10 mil pesos (USD $500) por realizar una aplicación en la que se pudieran fomentar las artesanías del país, misma que hicimos como prototipo en 2 días.

Fue muy ameno y nos trataron muy bien en ese hackathon, que aunque tuve que ir de mi casa a las oficinas de Google 2 días seguidos, fue muy satisfactorio el haber desarrollado esa pequeña solución. Lamentablemente ya no pudimos sacarla bien a producción por falta de inversión y de tiempo. Abandoné el coworking donde estaban las empresas involucradas y ya no los pude contactar (el error más garrafal de toda mi carrera, luego les contaré).

El destino de ese premio solo lo sabemos los involucrados. No lo compartiré ;).

Epílogo

Luego del hackathon de 2021, me retiré de este tipo de eventos. Comprendí que ya no estoy para malpasarme a lo tonto, mucho menos por empresas que tienen cierto desdén por las reglas. Ahora trato de terminar un par de side projects, que esperemos en Dios así sea, así como a dedicarme a mi mismo en la parte profesional y en la personal (aprendí a ser mejor líder). Igualmente aprendí varias cosas de todo este berenjenal:

A veces se gana y a veces se pierde, pero molesta bastante perder con dados cargados o por causas estúpidamente sencillas.
A pesar que otros rompan las reglas, mantente firme y recto en el trabajo.

Y la más importante:

Si te vas a esforzar y malpasar por algo, que ese algo sea para tu beneficio.

Espero que no los haya aburrido con este post y si leyeron hasta acá, muchísimas gracias por su apoyo. Espero ya no tener abandonado este espacio, pues veo que mis posts están pegando cool. Nos vemos en la próxima.

Sternie out.

P.D: Las ideas rechazadas que menciono aquí ya otras empresas las han desarrollado y les va muy de poca madre. Una de cal por las que van de arena.

100 Days of Code: Día 1

Marco Ramírez — Sat, 02 Oct 2021 19:25:31 +0000

Qué bueno que ya se me está haciendo costumbre esto de escribir unas cuantas líneas en mi perfil y pues el día de hoy, como les mencioné en mi Twitter, voy a estar en el reto #100DaysOfCode para poder fortalecer mis skills y estar aún más al tiro en lo último de código.

¿En qué consiste?

El reto consiste en programar al menos durante 1 hora diaria durante 100 días, con el fin de poder crear o reforzar conocimientos adquiridos previamente y publicando dichos avances durante la misma cantidad de días. Muchos solo lo hacen por Twitter, sin embargo otros más lo hacen en sus respectivos canales de YouTube, Twitch, DEV.to, etc.

Las reglas del reto son las siguientes:

Programa 1 hora durante 100 días
Publica tus avances
Motiva a 2 personas al día a que comiencen el reto.

Si quieres saber más sobre esta iniciativa, visita https://www.100daysofcode.com/, la página oficial de la iniciativa.

¿Cuál es tu objetivo para esta iniciativa?

Pues bien, ha habido varios rubros que necesito reforzar como desarrollador, entre los cuales veo los siguientes:

iOS con Swift
React (JS, Native y Gatsby)
Angular (actualizarme)
GraphQL
Microservicios
Uso de Cloud Development (Lambdas)

Igualmente, les dejo el enlace al repositorio de la bitácora para que puedan checar más a detalle los avances en https://github.com/RZEROSTERN/100-days-of-code

Por lo tanto, para este día 1 ¿qué les parece si nos ensuciamos un poquito las manos con iOS? Para esta ocasión, armaremos un proyecto Hello World! con Swift :3. A más tardar, el día de mañana les comentaré las actualizaciones del día.

Update: CocoaPods

El proyecto en cuestión he podido prepararlo e implementar CocoaPods. Para los que no van empezando, CocoaPods es el repositorio de librerías para iOS, con él puedes tener las capacidades que tiene Android con Maven. Está hecho con Ruby y da mayor flexibilidad a tu desarrollo iOS.

Para instalar CocoaPods tienes que hacer lo siguiente:

Instala CocoaPods en tu Mac con el siguiente comando:

sudo gem install cocoapods

Crea un proyecto de app en XCode.
Cierra XCode y abre una terminal.
Ejecuta los siguientes comandos a nivel de la carpeta raíz de tu proyecto:

pod init
pod install

Finalmente abre el archivo .xcworkspace que se ha creado. Al haber instalado CocoaPods correctamente, observarás que ha cambiado el layout del proyecto al siguiente:

Ahora sí podemos comenzar con el desarrollo de nuestra app en iOS y concluir con el día 1 de #100DaysOfCode. Lo que prosigue es hacer la pantalla de splash y comenzar con el diseño de una interfaz dentro del Storyboard de iOS.

Happy coding !!!

Mi primer package en Flutter y contribución al Open Source, en HACKTOBERFEST

Marco Ramírez — Fri, 01 Oct 2021 19:48:43 +0000

Mis niños, estoy de regreso como de costumbre y ahora en este mes de Octubre tenemos la novedad de todos los años que es el Hacktoberfest, de lo que les platicaré en el siguiente post sobre mis patoaventuras en contribuir al software libre. Sí, por fin me animé a contribuir.

Primeramente, nunca había colaborado con el mundo del open source, pues en algunas ocasiones he pensado que algunos desarrolladores desmotivan el participar en ello al imponer sus dogmas como la verdad absoluta y que debe seguirse al pie de la letra o el denostar el trabajo de otros desarrolladores solo porque sí. Esto ha sido siempre motivo de muchas discusiones y dramas pues los llamados cuidarranchos o gatekeepers siempre andan a la orden del día y van a querer fastidiarte el día.

El gatekeeper es el clásico sabelotodo que siente que se las sabe de todas y que es el auténtico master y al que muchos (por miedo o lo que sea) veneran, siendo su especialidad el estar criticando de forma muy airada e incluso hasta agresiva a los que quieren cambiar algún estándar, código, modus operandi o hasta modelo de negocio. Si me piden ponerlo en una imagen, que South Park nos ayude:

Gatekeeper in a nutshell

Ahora, la segunda causa por la que no entraba es referente al síndrome del impostor que muchos de nosotros manejamos como desarrolladores. El síndrome del impostor es el creer que no puedes hacer ciertas cosas justo cuando ya las has hecho o crees que has defraudado a las personas por hacer un mal trabajo cuando es prácticamente lo contrario. Recientemente me ha tocado colaborar en múltiples desarrollos tanto de mi trabajo como de freelance y de side projects y ya poco a poco se me ha ido quitando eso, aunque al ver desarrollos mejores llega a reaparecer, pero aquí ya es más de comprender que hay mejores desarrolladores que uno.

¿Qué has hecho con el Open Source ahorita?

Verán, al entrar al desarrollo con Flutter, me he encontrado con que algunas librerías no existen o como todo en este mundo de la programación, puede llegar a tener huecos de seguridad o simplemente es obsoleta.

En este caso una vez me habían pedido en realizar una aplicación de posts en la que pudiéramos dar soporte a formato WYSIWYG (What You See Is What You Get, para los que no conocían el acrónimo) y comenzó a usar mi compita @kiramishima_3 EditorJS en su backend. Cuál fue mi sorpresa de que no había en Flutter una librería que hiciera eso y pues me tocó hacerla desde cero.

Dentro de la misma he podido ya agregar elementos como:

Selección de fuente
Creación de párrafos
Inserción de imagenes, ya sea de la cámara o de la galería
Barra de estados
Retroalimentar un JSON tipo EditorJS a un contenedor
Obtención de información JSON desde un archivo estático o una API.

Ahorita ¿cuál es el destino del package?

Pues bien, he de decirles que no he podido terminar, dado a que me atiborraron con muchísimos proyectos, gracias a Dios.

Sin embargo, en este Hacktoberfest decidí liberarlo como alpha para poder ir agregando las features restantes y compatibilidades ad-hoc a los estándares del desarrollo Flutter y siento que la comunidad open source puede apoyarme en estos momentos en los que este proyecto, que se ve prometedor, pueda servir para muchos desarrolladores.

El Hacktoberfest es un evento anual donde los desarrolladores, empresas, entusiastas open-source, etc, deciden compartir desarrollos y ponerlos a disposición de la comunidad para así poder expandir los mismos. A cambio, si haces 4 Pull Requests válidos tienes derecho a una playera y swag del evento. Muchos dirán ¿trabajas por una playera?, yo digo sí ¿por qué no? Es divertido y me gusta y eso en lo personal es lo que me motiva a seguir siendo ingeniero de software. Les dejo el link del repositorio para que colaboren aquí.

Una vez que ya la librería tenga una forma más estable se publicará en pub.dev (repositorio de librerías para Flutter y Dart) para que pueda usarse en desarrollos retail. Solo esperemos que la banda gatekeeper no se ponga sus moños y no nos quieran funar :P.

Pues bien, como de costumbre, muchísimas gracias por leerme y no olviden darle amor a este y el resto de mis posts y pronto estaré de regreso con el streaming. Stay tuned.

Happy coding !!!

Pruebas Unitarias en Autenticación con Laravel y Passport

Marco Ramírez — Mon, 13 Sep 2021 17:57:55 +0000

Mis niños, la verdad, así como los he dejado solos un buen rato, ahora ando inspirado para publicar algo que me trajo muchos dolores de cabeza: las pruebas unitarias con Passport, no sin antes, quiero felicitarlos hoy por el día del programador a todos y cada uno de mis colegas y de la comunidad DEV en español.

Para los que no conocen Passport, es una librería dentro de Laravel que te permite realizar autenticación con OAuth 2 mediante Personal Access Tokens o por medio de las clásicas JWT junto con una Refresh Token para mantener el login el mayor tiempo posible.

El rollo de implementar UT

Cuando uno está acostumbrado a desarrollar sin Unit Testing, por lo general se vuelve un dolor de cabeza el implementarlas, sin embargo conforme va uno agarrando el hilo de las mismas, además de que es una economía al momento de poner en producción un desarrollo te da la certeza de que desarrollaste un módulo correctamente.

Pero antes que nada dirán los que empiezan ¿qué es una prueba unitaria? Ah pues como lo dice la gran amiga Wikipedia una prueba unitaria es una forma de comprobar el correcto funcionamiento de una unidad de código.

Entonces, cuando nosotros hacemos algún comportamiento dentro de un sistema, tenemos que pasarlo por pruebas diversas, sin embargo, las que nos alertan desde un principio si están bien son las unitarias. En PHP (lenguaje de Laravel) usamos lo que es PHPUnit para realizar las mismas y este por lo general ya viene incluido cuando instalas Laravel.

El tema viene cuando quieres hacer unit testing con Passport. Puesto que en uno de los pasos, tienes que llamar al servidor para generar tus respectivas tokens. Sin embargo sucede que tu UT va a tronar si careces de un servidor web implementado en la misma. Veamos qué sucede.

Ahora bien, si quieres saber más a fondo sobre cómo implementar Passport en Laravel, te dejo este link, mismo que es en el que me basé para armar este post.

El código a testear

Primeramente, tomamos en cuenta el siguiente método:

public function getAuthAndRefreshToken($email, $password) { 
        $oClient = OClient::where('password_client', 1)->first();
        $http = new Client;
        $oauthUrl = (env('APP_ENV') != 'local') ? route('passport.token') : env('APP_URL') . 'oauth/token';
        $response = $http->request('POST', $oauthUrl, [
            'form_params' => [
                'grant_type' => 'password',
                'client_id' => $oClient->id,
                'client_secret' => $oClient->secret,
                'username' => $email,
                'password' => $password,
                'scope' => '*',
            ],
        ]);

        $result = json_decode((string) $response->getBody(), true);
        return response()->json($result, $this->successStatus);
    }

La implementación en el método a testear:

public function login(Request $request){
        $validator = Validator::make($request->all(), [
            'email' => 'email|required',
            'password' => 'required'
        ]);

        if($validator->fails()) {
            return response()->json(['success' => false, 'details' => $validator->errors()], 401);
        }

        $result = $this->getAuthAndRefreshToken(request('email'), request('password'));

        if($result['success'] == true) {
            return response()->json($result, 200);
        } else { 
            return response()->json(['success' => false, 'error'=>'Unauthorized'], 401); 
        } 
    }

Y su respectiva UT:

   public function test_login_success() {
        $user = User::factory()->make();

        $response = $this->postJson('/api/login', [
            'email' => $user->email,
            'password' => 'password'
        ]);

        $response->assertStatus(200)->assertJson([
            'success' => true
        ]);
    }

Al momento de nosotros realizar nuestras pruebas unitarias, van a fallar irremediablemente y la razón es de que no hay como tal una implementación de un servidor web existente dentro de PHPUnit. Nosotros para poder realizar nuestras pruebas, tenemos que simular el request dentro del primer método y precisamente el bloque siguiente:

$response = $http->request('POST', $oauthUrl, [
            'form_params' => [
                'grant_type' => 'password',
                'client_id' => $oClient->id,
                'client_secret' => $oClient->secret,
                'username' => $email,
                'password' => $password,
                'scope' => '*',
            ],
        ]);

es el que nos está dando lata :(. Si lo pasas por un Github Actions, va a tronar riquísimo marcándote que no existe la URL que tienes en la siguiente línea:

$oauthUrl = (env('APP_ENV') != 'local') ? route('passport.token') : env('APP_URL') . 'oauth/token';

La solución a todos nuestros problemas

Primeramente, el método que tenemos que refactorizar es el de getAuthAndRefreshToken. Tenemos que cambiar el modo como llamamos el request y que sea funcional tanto en la implementación como en las pruebas.

La forma de realizarlo es:

Asignando al request principal los parámetros que el endpoint OAuth requiere para armar un nuevo request.
Despachar una ruta en POST: el endpoint oauth/token por medio de un nuevo Request interno.

Lo anterior sin utilizar cliente alguno como Guzzle o similares, mismas que requieren tener un servidor Apache o nginx implementado, features que no se utilizan en pruebas unitarias.

Para ello cambiamos a lo siguiente:

private function getAuthAndRefreshToken(Request $request, $email, $password) {
        $oClient = OClient::where('password_client', env('DEFAULT_PASSWORD_CLIENT_ID', 1))->first();

        $request->request->add([
            'grant_type' => 'password',
            'client_id' => $oClient->id,
            'client_secret' => $oClient->secret,
            'username' => $email,
            'password' => $password,
            'scope' => '*',
        ]);

        $response = Route::dispatch(Request::create('oauth/token', 'POST'));

        $result = json_decode((string) $response->getContent(), true);
        $result['success'] = (isset($result['error'])) ? false : true;

        return $result;
    }

En este refactor, hemos cambiado varias cosas:

Ya no necesitarás una URL ni un cliente para armar el request. Es más sano, pues ya así puedes asignar la implementación sin importar la URL o factores externos al método y puedes testear sin problemas desde consola.
Obtienes mayores detalles de la respuesta que te da Passport al momento de llamar el endpoint de OAuth para poder dar más transparencia al proceso, igualmente ya podrás hacer manejo de errores del método sin problemas.

Y ya con este refactor, tendrías que cambiar la implementación en tu método login, concretamente el inicio del método ya sería así:

$result = $this->getAuthAndRefreshToken(request(), request('email'), request('password'));

Al terminar todo esto, puedes pasar tus unit testings de forma manual en tu código o por Github Actions para poder confirmar las mismas y ya proceder a realizar implementaciones adicionales.

Y pues bien, esto era lo que me traía de los pelos en cuestiones de pruebas unitarias y quiero compartirlo con ustedes para que puedan sacar más rápido este tema con Passport. Ahora, no olvides de reaccionar y compartirlo con los colegas para que haya más y mejores posts en español dentro de DEV.

Happy coding!

Wizeline y yo: De reclutamiento en mobile y un objetivo cumplido

Marco Ramírez — Mon, 06 Sep 2021 15:17:34 +0000

Mis niños, ya hace rato que no escribo para ustedes. De verdad les pido una disculpa, sin embargo he estado algo atareado con este nuevo reto que les he de platicar en estas líneas.

En esta ocasión me gustaría platicarles sobre reclutamiento y cómo obtener trabajo en el ámbito móvil; algunas cosas aplicarían tanto para Android como para iOS, sin embargo seré más específico para la parte de Android, la cual es mi skill principal al día de hoy junto con PHP.

Pues ahora sí, al grano. Les quiero platicar sobre cómo fue que entré a Wizeline, una de las empresas más importantes en el ramo de la ingeniería de software hoy en día y que poco a poco ha ido creciendo en dicho ámbito. En verdad, a un mes de haber entrado, sigo sin creermela de estar en estos momentos siendo parte de esta gran empresa. Les platicaré aspectos sobre todo que les pueden servir a quienes quieren entrar en el ámbito mobile y de cómo poder formar parte no solo del equipo de Wizeliners, sino de cualquier otro team.

¿Cómo conocí a Wizeline?

A Wizeline lo conocí cuando estaba trabajando con Kira y Chemasmas en Iterando. Recuerdo muy bien que se encontraban sus oficinas a 2 cuadras de las de COW Roma y muchas comunidades tomaban a Wizeline como sede de sus Meetups. Llegamos a ir a algunas de ellas y se llegaba a armar una que otra workshop sobre algún lenguaje de programación (JS, PHP, Java, etc) y andábamos de pata de perro visitando las Meetup.

Fue precisamente durante una de ellas en donde se ofrecieron vacantes para poder ingresar a la empresa, mismas a las que en lo personal acepté entrar, sin embargo...

Primeros Intentos: WASTED

Las primeras veces que llegué a aplicar a Wizeline, no les niego que fue mi reality check como desarrollador, pues conocí un paso dentro del proceso de reclutamiento que se ha vuelto un verdadero Calvario hasta el día de hoy: la prueba de algoritmos.

El conocer las pruebas de algoritmos fue el parteaguas para poder aprender un poco más de estructuras de datos y para poder ver otros procesos de reclutamiento como los de las FAANG en donde inclusive llega a ser el clásico white board. Sin embargo, como les mencioné antes, estas pruebas no son mi fuerte. Así que ya sabrán cómo fueron los primeros resultados.

En varias ocasiones fuí rechazado para entrar como frontend y backend developer y hubo un tiempo en el que dije toda esperanza está perdida. Hasta que llegó la pandemia, el 2021 y una nueva oportunidad.

El reclutamiento

Después de mucho tiempo, en este 2021 volví a obtener una nueva oportunidad para entrar y en esta ocasión las cosas cambiaron muchísimo:

DISCLAIMER: He de decir que este fue el proceso que seguí para mobile y puede cambiar dependiendo de las diferentes ramas que se requieren en Wizeline, sobre todo con las pruebas técnicas.

Primeramente fue un screening con RR.HH. en donde conoces a la empresa y ellos te conocen a ti. En este caso es una llamadita de 30 minutos donde platicas sobre temas referentes a tu experiencia profesional. En mi caso la entrevista fue muy fluída y hasta el tiempo se pasó por 5 o 10 minutos.
Una vez que pasas esta entrevista, lo siguiente son las pruebas de inglés. Sí, en Wizeline, por la naturaleza de los proyectos, se considera como must tener inglés de upper intermediate para arriba, por lo que se hace una entrevista en inglés 100% de igualmente 30 minutos, así como una pequeña prueba de gramática hecha por una plataforma web. La ventaja es que esta entrevista es completamente separada de las demás, por lo que no tienes que preocuparte de estar estresado por una entrevista anterior.
Si todo sale bien en esta entrevista, se vienen un par de entrevistas adicionales: las entrevistas técnicas. Estas tienen la finalidad de poner a prueba tus skills en la tecnología a la que aspiras (sea iOS o Android). Por lo general, lo requerido para entrar a vacantes móviles (no solo aquí en WZ, sino ya prácticamente en cualquier empresa) son las siguientes:
- Fundamentos del SDK de iOS o de Android (según corresponda). Incluyendo life-cycle, uso de diversas herramientas dentro del framework, etc (en Android es el uso de fragmentos, activities, navigation components, estilos, etc).
- Patrones de Arquitectura como MVVM (recomendado) o MVP. MVC ya no se toma en cuenta.
- Manejo de arquitecturas como Clean Architecture o VIPER.
- Tener conocimiento de los principios de SOLID.

Estos conocimientos, te serán evaluados en dos entrevistas:

Entrevista de arquitectura de apps: Aquí pondrás a prueba tus skills con el manejo de datos provenientes ya sea de un modelo de datos o de una REST API.
Entrevista de UI: Aquí tendrás que demostrar tus conocimientos en el uso de UI de la plataforma que has elegido implementando un layout de acuerdo a los requerimientos que te den los reclutadores.

Finalmente, se te hará una última entrevista con el líder de la división, quien en 30 minutos platicará contigo sobre ti y sobre lo que es la empresa. En esta entrevista es la última oportunidad que tienes para despejar todas tus dudas antes de que se tome la decisión final.

Wizeline siempre te notificará si eres elegido o no. Si eres elegido, el/la reclutador(a) que comenzó tu proceso te notificará de ello y te enviará propuesta económica así como los siguientes pasos y la fecha de tu ingreso.

En caso contrario, igualmente el/la reclutador(a) te enviará un correo con las áreas de oportunidad que has tenido para poder volver a postular en 3 meses. Como tal no hay un mínimo predeterminado, pero es lo recomendable para volver a aplicar.

A un mes de entrar...

Me convertí en Wizeliner el 2 de agosto pasado, por lo que al día de hoy ya llevo 1 mes laborando para esta gran empresa. Como tal no había visto que una organización tuviera ese balance que uno como colaborador de una empresa tenga: el balance entre el compromiso contraído y el de tener tu vida personal en orden. Haciendo que día a día no se vuelva tedioso e incluso dejes de pensar en la llegada del lunes.

Dentro de WZ, he sentido la motivación que en algunas ocasiones ha faltado en trabajos anteriores y aunque llevo solamente un mes, estoy completamente seguro que podrán ser muchos meses más. Ya a partir de aquí todo depende de mi y de mantener la actitud como la tengo en este momento y aprovechar los recursos que la empresa proporciona para poder servir a la misma como debe ser.

Unos tips para las entrevistas

Finalmente te daré 5 tips por si quieres postular:

Estudia bien sobre qué quieres entrar.
Si vas a front o backend, estudia también algoritmos. Te recomiendo el libro Cracking the Coding Interview, viejo lobo de mar en estas entrevistas y problemas.
Siempre pregunta lo esencial sobre Wizeline, todas las dudas que tengas, despéjalas.
Antes de las entrevistas técnicas, descansa y mantente bien hidratado y alimentado. Por lo general son 2 horas contínuas que estarás en tu computadora.
Demuestra una gran actitud en todas tus entrevistas. Eso también es importante.

Pues bien, no me queda mas que agradecer al team que estuvo en mi proceso de reclutamiento y les mando un gran abrazo a todos y cada uno de ellos y espero que este post sirva para hacer crecer la empresa aún más. Si les interesa alguna vacante, pueden checarlas en este link.

Happy Coding!

Post Mortem: La ansiedad de una puesta en producción

Marco Ramírez — Sun, 13 Jun 2021 13:08:46 +0000

Mis niños, el día de hoy, de hecho hace no más de 3 o 4 horas he puesto en producción una actualización a un sistema que se encarga de llevar entradas y salidas de estacionamientos.

Sin embargo, como cualquier desarrollador, hay veces que los nervios se apoderan de uno y me genera ese bonito sentimiento que llamamos ANSIEDAD y que desencadena aún más cosas y quisiera compartirlo con ustedes, amigos desarrolladores.

Según la bendita Wikipedia, la ansiedad es un mecanismo de defensa natural del organismo frente a estímulos externos o internos que son percibidos por el individuo como amenazantes o peligrosos. En mi específico caso, puede llegar a darme en la torre con insomnio (de hecho escribo este post para poder conciliar el sueño) y el síndrome del impostor.

¿Por qué llega a pasarte eso?

Pues bien, primeramente el que todo te reviente en las manos en un modelo de negocio bastante complejo o en donde el trabajo de reingeniería, refactoring, planeación y demás ha sido extremadamente laborioso es algo que me causa pavor, puesto en algunas ocasiones en lo primero que pienso es:

"Ya valió ma, me van a correr/quitar el proyecto"

Si algo puedo decirte, es que en la mayoría de las ocasiones no será así. No es por querer decir que uno sea indispensable en el mismo, pero si ya llevas un tiempo considerable en el mismo, pues quiere decir que tu trabajo es el que ha hablado y con creces e inclusive te empiezas a hacer más prestigio en la empresa para la que trabajas (como empleado o freelance), sin embargo es ahí en donde entra el otro peor amigo: el síndrome del impostor.

¡Valgo versia otra vez!: ¿Qué es el síndrome del impostor?

Igualmente, según Wikipedia, el síndrome del impostor es un fenómeno psicológico en el que la gente se siente incapaz de internalizar sus logros y sufre un miedo persistente de ser descubierto como un fraude. Un ejemplo de cómo llega a manifestarse es el constante miedo a que un proceso que hiciste llegue a tener bugs o que lleguen a refactorizar tu código.

Te lo digo como experiencia, en algunas ocasiones cuando un proceso me llega a salir mal, hay veces que me pasa por la cabeza la clásica frase ¿y si mejor me dedico a otra cosa? o también al ver el progreso de colegas más experimentados el decir jamás voy a llegar a ser como ellos, no creo ser tan senior, cuando es de que en Github he podido hacer algoritmos bastante perrones e inclusive apps completas.

Al final del día, termina pasando ese sentimiento y volvemos otra vez al mundo de la tecla como si nada.

¿Cómo puedo mejorar y combatir a esa pareja malévola?

Si me animé a escribir esto, es precisamente para ayudar a quien lo desee y pues igualmente, en mi experiencia dividamos en dos el cómo mejorar estos aspectos: las habilidades blandas y las habilidades duras.

Habilidades Blandas

En tus habilidades blandas te recomiendo lo siguiente:

Trabaja en equipo: siempre asesórate con colegas o con cualquier persona que se encuentre en tu entorno. Si estás solo (comunmente con los freelancers), acude a cualquier comunidad de desarrolladores de software. En México hay varias y una de las que recomiendo es PHPMX (no solo se habla de PHP y siempre vas a encontrar a alguien que te ayude).
Platica tus problemas con gente de tu confianza: en quien tú confíes, platica estos malestares. Platica siempre cuando te sientas ansioso, cuando sientas que no van las cosas bien y aunque no sea del ramo, te desahogarás y podrás dejar atrás eso.
Manda a la chin**** a quienes hagan menos tu trabajo: No precisamente con groserías. Encuentra la manera de ser polite y dale la vuelta a sus estupideces. En cuanto demuestres tu valía, creeme que el silencio es más ensordecedor que una mentada de madre.
No sobrepienses las cosas: Si llega a suceder algo, encuentra la solución y ya. No te concentres en lo que va a suceder después. Recuerda siempre que todo en la vida tiene solución, menos la muerte y un DELETE sin WHERE y sin respaldo

Habilidades duras

Ya en la parte de software engineering te puedo sugerir:

Haz pruebas: PRUEBA, PRUEBA, PRUEBA antes de hacer deployment a producción. Igualmente entrena todo lo referente a Unit Testing, E2E Testing, Integration Testing, etc.
Crea un plan de contingencia técnica: No dejes todo a la suerte. Siempre ten todo respaldado y procura que puedas tener un punto de rollback por si el servicio llega a caerse. Eso es primordial.
Monitorea: Ya que hayas puesto en producción, mantente al pendiente del desarrollo y ya si ves que todo está corriendo como debe de, ve por una cerveza (o algo de tu agrado) y disfruta.

Un consejo de pilón (pero muy importante)

Finalmente y como un consejo especial, siempre pide a tu empleador o cliente autorización para que puedas poner tu participación en ese desarrollo dentro de tu portafolio. Al final del día, es lo que va a quedar para la posteridad.

Si lo sacan de línea, POPOCATÉPETL. Nada es eterno y en algún momento un sistema tiene que morir. Solo guarda testigos del mismo para posteriores referencias (claro, si te dan la autorización).

Pues bien, ya me está entrando el sueño y pues quiero echarme una siesta, pues este domingo me va a tocar monitorear esta bonita actualización.

Happy coding!

Post Mortem: El Pokedex en Android y Clean Architecture

Marco Ramírez — Wed, 24 Feb 2021 06:21:56 +0000

Hey, ¡mis chamacos! Ya estoy de regreso deleitándolos con más contenido en español. En esta ocasión quiero contarles sobre un poquito más de desarrollo Android. Como ustedes sabrán, uno de los ejercicios que como ingenieros de software nosotros hacemos para pulir nuestras técnicas en el desarrollo de software es el desarrollo del popular POKEDEX, el cual es la guía de todo maestro Pokémon y prácticamente su mano derecha.

¿Qué rayos es el Pokedex?

Como ya lo mencioné, es la guía de un maestro Pokémon en forma de un dispositivo electrónico de formas diferentes, mismo que servía además de "enciclopedia" Pokémon, para otras cosas como mapa y comunicaciones.

¿Qué fue lo que se implementó?

Pues bien, dentro de este desarrollo que se hizo con Kotlin 100%, se estuvieron utilizando diversas prácticas usadas hoy en día en el desarrollo móvil como la implementación de la conocida "Clean Architecture" y de la inyección de dependencias.

Para ello, usamos Koin para la inyección de dependencias y fuimos armando la parte de datos en un módulo "core" separado de la parte de presentación de la app. En la parte de llamadas a la API también se utilizó un poco de RxJava/RxKotlin y RxAndroid.

Luego para el backend, se implementó PokeAPI como backend, mismo que se ha convertido en un referente en el desarrollo de este proyecto en diferentes lenguajes, sobre todo en los que son usados en frontend (JS, Dart, TypeScript) y apps móviles (Swift, Kotlin, Java).

Finalmente para las librerías externas, se utilizaron las habituales en un desarrollo de este tipo tales como:

Glide
Retrofit
GSON (extensión de Retrofit)

Sobre Clean Architecture

Clean Architecture es un marco de trabajo propuesto por Robert C. Martin como forma de estructurar nuestro código en capas, mismas que solamente se pueden comunicar entre las que están a sus lados.

El esquema de Clean Architecture es el siguiente:

Y las capas, tomando en cuenta Android son las siguientes:

UI: La interfaz de usuario (el Fragment). Pero ¡AGUAS!, no quiere decir que vayas a meter toda la lógica de llamadas a datos en el Fragment (mala praxis), para ello se usa el ViewModel del mismo, que es donde viene la siguiente capa.
Presentación: Son clases que se comunican con las clases e interfaces de interacción de nuestra aplicación realizando las llamadas pertinentes a datos. Como lo mencioné en el punto anterior, aquí es donde entran los ViewModel.
Use Cases o Interactors: Estas clases se encargan de interactuar con el modelo de negocio de datos e implementa el modelo de negocio pertinente para el manejo de datos dentro de nuestra aplicación. En este punto es donde uno como desarrollador puede armar diversos comportamientos avanzados con la información entregada por la capa contigua: los Repositorios.
Repositorios o Entities: Aquí es donde se albergan todas las llamadas a datos internos y externos de nuestra aplicación, es decir, las llamadas a REST API, servicios web diversos, bases de datos SQLite (si es que se requiriese ROOM), etc.

Caso Práctico

Ahora bien, como un caso práctico les mostraré un flujo de datos usando CA. Una disculpa si no doy tanto detalle de la implementación y no toco un par de tópicos, pero me gustaría profundizar en ellos por separado:

ReactiveX (tal vez me aviente algo sobre corrutinas).
Inyección de Dependencias.
El modelo MVVM utilizado en apps móviles.

Para fines de implementación se debe de realizar de forma inversa (de adentro hacia afuera) por lo que primeramente sería implementar nuestro llamado a Retrofit de esta forma:

CAPA 4: REPOSITORIOS

interface RestApi {
    @GET("region")
    fun getRegions(): Observable<RegionResult>

    @GET("region/{region}")
    fun getDetailedRegion(@Path("region") region: String): Observable<RegionDetailedResult>

    @GET("pokedex/{pokedex}")
    fun getPokedex(@Path("pokedex") pokedex: String): Observable<PokedexResult>

    @GET("pokemon/{pokemon}")
    fun getPokemonByName(@Path("pokemon") pokemon: String): Observable<PokemonResult>

    @GET("pokemon-species/{pokemon}")
    fun getPokemonSpeciesByName(@Path("pokemon") pokemon: String): Observable<PokemonSpeciesResult>
}

Cada uno de los métodos declarados en dicha interfaz serán los utilizados por nuestros repositorios y de esta forma es como los iremos implementando cada uno. Posteriormente, se realiza la implementación de dicha interfaz por medio de una clase:

class RestApiImp {
    companion object{
        var retrofit: Retrofit? = null
        val REQUEST_TIMEOUT: Long = 30
        var okHttpClient: OkHttpClient? = null

        fun getClient(): Retrofit {
            if(okHttpClient == null)
                initOkHttpClient()

            if(retrofit == null) {
                retrofit = Retrofit.Builder()
                    .baseUrl(Constant.MAIN_URL)
                    .client(okHttpClient!!)
                    .addCallAdapterFactory(RxJava2CallAdapterFactory.create())
                    .addConverterFactory(GsonConverterFactory.create())
                    .build()
            }

            return retrofit!!
        }

        private fun initOkHttpClient() {
            var httpClient: OkHttpClient.Builder = OkHttpClient().newBuilder()
                .connectTimeout(REQUEST_TIMEOUT, TimeUnit.SECONDS)
                .readTimeout(REQUEST_TIMEOUT, TimeUnit.SECONDS)
                .writeTimeout(REQUEST_TIMEOUT, TimeUnit.SECONDS)

            var interceptor: HttpLoggingInterceptor = HttpLoggingInterceptor()
            interceptor.level = HttpLoggingInterceptor.Level.BODY
            httpClient.addInterceptor(interceptor)

            httpClient.addInterceptor { chain ->
                var original = chain.request()

                val newRequest = chain.request().newBuilder()
                    .addHeader("Accept", "application/json")
                    .build()

                chain.proceed(newRequest)
            }

            okHttpClient = httpClient.build()
        }
    }
}

Como pueden ver, la clase cuenta con un "companion object", el cual es el símil en Kotlin de declarar una clase estática y en dicho objeto, tenemos el método getClient, mismo que se encargará de realizar la implementación de Retrofit, la extensión para GSON y un interceptor para inyectar cabeceras antes de llamar al request (es aquí donde podríamos inyectar tokens, sin embargo no las necesitamos en esta ocasión).

Luego, pasamos a los repositorios persé. Para poder llamar a los métodos para obtener los diferentes tipos de "Pokedex", declaramos la siguiente interfaz:

interface PokedexRepository {
    fun getPokedex(pokedex: String): Observable<PokedexResult>
}

Con su respectiva implementación:

class PokedexRepositoryImp: PokedexRepository {
    private var apiRequest: RestApi = RestApiImp.getClient().create(RestApi::class.java)

    override fun getPokedex(pokedex: String): Observable<PokedexResult> {
        return apiRequest.getPokedex(pokedex)
    }
}

En esta interfaz y clase, podemos nosotros ver que invocaremos como tal a Retrofit hacia un endpoint de los declarados en RestApi.kt pero como parte de la Clean Architecture, quien se encargará de ello serán los Interactors.

CAPA 3: INTERACTORS

Para los Interactors se declarará de la misma manera que los Repositorios, una interfaz y una clase de implementación, quedando de la siguiente forma la interfaz:

interface PokedexInteractor {
    fun getPokedex(pokedex: String): Observable<PokedexResult>
}

Y la clase que implementa:

class PokedexInteractorImp(private val pokedexRepositoryImp: PokedexRepositoryImp,
        private val pokemonRepositoryImp: PokemonRepositoryImp): PokedexInteractor {
    val logger: Logger = LoggerFactory.getLogger(PokedexInteractorImp::class.java.simpleName)

    override fun getPokedex(pokedex: String): Observable<PokedexResult> {
        return pokedexRepositoryImp.getPokedex(pokedex)
            .doOnNext { response ->
                run {
                    for(item: Pokemon in response.pokemonEntries) {
                        var pokemonID: String = item.pokemonSpecies.url
                            .replace(Constant.MAIN_URL, "")
                            .replace("pokemon-species", "")
                            .replace("/", "")

                        item.pokemonImage = Constant.POKEMON_IMAGE_URL + pokemonID + ".png"
                        pokemonRepositoryImp.getPokemon(item.pokemonSpecies.name)
                            .subscribeOn(Schedulers.io())
                            .subscribe({response2 -> item.pokemonDetails = response2}, {t -> logger.error(t.message)})
                    }
                }
            }
            .doOnComplete { logger.debug("Service complete") }
            .onErrorReturn { error ->
                logger.error(error.message)
                null
            }
    }
}

Y como podemos observar en PokedexInteractorImp.kt, quien se encarga de armar lógicas complejas en el modelo de negocio de la aplicación es el interactor o use case. Es en esta capa donde se recomienda hacer las manipulaciones de datos pertinentes para que en la capa 2, únicamente se encargue de hacer las llamadas pertinentes para obtener estos datos.

CAPA 2: PRESENTACIÓN

En Android, la capa de presentación se ve representada por el ViewModel de nuestro fragmento en cuestión. Por lo tanto, dicho ViewModel tiene que estar establecido y asignado dentro del fragmento. Armamos el ViewModel como sigue:

class PokedexInfoViewModel : ViewModel() {
    var compositeDisposable = CompositeDisposable()
    lateinit var dependencies: ApiDependencies // I'll talk about this later
    var pokemon: MutableLiveData<MutableList<Pokemon>> = MutableLiveData()

    fun getPokedex(pokedex: String) {
        compositeDisposable.add(dependencies.getPokedex(pokedex)
            .subscribeOn(Schedulers.io())
            .subscribe(
                {res -> pokemon.postValue(res.pokemonEntries) },
                {t: Throwable -> Log.e(ContentValues.TAG, t.message!!) }
            )
        )
    }
}

Con esto, nosotros vamos armando la capa 2 y dejamos todo dispuesto a que la capa 1 únicamente quede a la escucha de la información que llegue al momento de requerirlas y seguir el flujo de ida y vuelta conforme a la Clean Architecture.

CAPA 1: UI

Finalmente, el encargado de invocar todo este caminito será el Fragment (puedes usar Activities, pero gastarás más memoria), por lo que tenemos que realizarlo de la siguiente manera:

class PokedexInfoFragment : Fragment() {

    private lateinit var viewModel: PokedexInfoViewModel
    private lateinit var toolbar: Toolbar
    private val dependencies: ApiDependencies by inject()
    lateinit var items: MutableList<Pokemon>
    lateinit var recyclerView: RecyclerView

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setHasOptionsMenu(true)
    }

    override fun onCreateView(
        inflater: LayoutInflater, container: ViewGroup?,
        savedInstanceState: Bundle?
    ): View? {

        val view = inflater.inflate(R.layout.pokedex_info_fragment, container, false)

        val activity = requireActivity() as AppCompatActivity
        toolbar = view.findViewById(R.id.tb_pokedex_info)
        activity.setSupportActionBar(toolbar)

        activity.supportActionBar!!.title = arguments?.getString("pokedex")!!
            .capitalize(Locale.getDefault()).replace("-", " ") + "'s Pokedex"
        activity.supportActionBar!!.setDisplayHomeAsUpEnabled(true)

        return view
    }

    override fun onOptionsItemSelected(item: MenuItem): Boolean {
        when (item.itemId) {
            android.R.id.home -> {
                var bundle = bundleOf("region" to arguments?.getString("region"))
                Navigation.findNavController(requireView()).navigate(R.id.action_pokedexInfoFragment_to_regionFragment, bundle)
                return true
            }
        }

        return super.onOptionsItemSelected(item)
    }

    override fun onActivityCreated(savedInstanceState: Bundle?) {
        super.onActivityCreated(savedInstanceState)
        viewModel = ViewModelProvider(this).get(PokedexInfoViewModel::class.java)

        viewModel.dependencies = dependencies
        viewModel.pokemon.observe(viewLifecycleOwner, Observer {
            items = it
            initRecyclerView()
        })
        viewModel.getPokedex(arguments?.getString("pokedex")!!)
    }

    private fun initRecyclerView() {
        val listener = View.OnClickListener() {
            val bundle = bundleOf("pokemon" to it
                .findViewById<TextView>(R.id.txt_pokemon_name)
                .text.toString().toLowerCase(Locale.getDefault()),
                "pokedex" to arguments?.getString("pokedex"))

            Navigation.findNavController(requireView())
                .navigate(R.id.action_pokedexInfoFragment_to_pokemonFragment, bundle)
        }

        recyclerView = requireView().findViewById(R.id.rv_pokedex_info)
        recyclerView.setHasFixedSize(true)
        recyclerView.layoutManager = GridLayoutManager(requireContext(), 3)
        recyclerView.adapter = PokedexInfoAdapter(items, listener)
    }

    override fun onDetach() {
        viewModel.compositeDisposable.dispose()
        items.clear()
        super.onDetach()
    }

    override fun onDestroy() {
        viewModel.compositeDisposable.dispose()
        items.clear()
        super.onDestroy()
    }
}

Varios métodos son asignados como override pues son parte de la API de Android, sin embargo son de vital importancia (onDetach y onDestroy) para que el ViewModel no se quede en memoria al momento de cambiar de Fragment, salir de la app o algún punto en el que el ciclo de vida de la app se vea terminado o interrumpido.

El método onActivityCreated es el encargado de realizar el llamado de todo el camino por medio del siguiente bloque:

        viewModel.pokemon.observe(viewLifecycleOwner, Observer {
            items = it
            initRecyclerView()
        })
        viewModel.getPokedex(arguments?.getString("pokedex")!!)

Al momento de asignar el ViewModel, nosotros asignamos un observer de LifeCycle (no confundir con los observers de ReactiveX) para que en cuanto la información llegue, realice los procesos que uno asigne dentro del Observer y así poder enviar la información hacia la vista del Fragment (nuestro XML).

Siguientes pasos

Hasta ahorita ando viendo el trabajar lo siguiente ya que se tiene una versión estable:

Mejorar el UX/UI de la app. Ahorita lo hice muy básico.
Agregar un news feed en el dashboard. Ahorita no lo agregué porque no encontré ninguno libre.
En lugar de usar RxKotlin, poder cambiar a corrutinas para la parte asíncrona y tener una alternativa de trabajar las llamadas de este tipo. Aunque la verdad, soy más fan de ReactiveX que de las corrutinas, pero uno nunca sabe cuándo necesitará trabajar con ellas.
Revisar que no haya memory leaks en la app.
CI/CD

Como es costumbre, he de comentar que no soy el mejor desarrollador de Android y que tal vez este código no sea el mejor que hayas visto y me gustaría mejorarlo. Si te interesa dejar tus issues, darle stars, forkearlo o ayudarme a mejorar, puedes hacerlo en el siguiente repositorio: https://github.com/RZEROSTERN/roadtocertification_pokedex.

Igualmente, si quieren dejar sus comentarios, pueden hacerlo bajo este post. Estaré feliz de contestarlos.

Bueno pues, espero que les haya gustado este post, aunque largo, nutritivo en cuestiones que tal vez puedan sacar de dudas a más de una persona.

Happy coding !!!

Post Mortem: Global Game Jam 2021

Marco Ramírez — Wed, 03 Feb 2021 08:31:03 +0000

Pues bien, el día de hoy les traigo otro post y en esta ocasión no les hablaré de aplicaciones móviles, sino de desarrollo de videojuegos.

Una de mis más grandes pasiones son los videojuegos y me gusta mucho estar inmiscuido en dicho mundo, desde "manquear" un ratito en la PC o en el Nintendo Switch hasta el desarrollo pasando por un poco de armado de arte y demás.

Ahora bien, me gustaría dar un post mortem sobre mi participación en la Global Game Jam 2021, misma que comenzó el 27 de enero y terminó el día 31 todo de forma remota pues el COVID19 está haciendo de las suyas y no nos deja salir para nada.

¿QUÉ ES LA GLOBAL GAME JAM?

Pues bien, la Global Game Jam es un evento anual de desarrollo de videojuegos en el que prácticamente cualquier persona interesada en hacer un videojuego, juego de rol o juego de mesa puede participar sin importar su experiencia. Las reglas son muy sencillas:

Be kind
No digas el tema más que a tus colegas dentro de la sede. Ni siquiera en redes sociales. Esto solo lo puedes hacer hasta que Honolulu haya empezado el evento (de verdad).

De ahí, tienes 48 horas para armar un prototipo de juego y presentarlo a los demás. Puedes valerte de cualquier herramienta y prácticamente si necesitas comprar/descargar assets, lo puedes hacer dando crédito a sus creadores (sí, tampoco hay que ser piojos).

GGJ2021 en tiempos de COVID19

Como todo, la Global Game Jam se tuvo que adaptar a realizarse en un formato digital. Mismo que fue muy cómodo para muchísimos de nosotros, pues el traslado a las diferentes sedes puede ser algo caótico (desde donde vivo a la sede del CCD en CDMX son 2 horas de camino :( ) y nos puso en contacto con muchísimas personas que comparten el mismo interés por los videojuegos.

Esta facilidad me dio a mi la oportunidad de participar en tres proyectos:

PSYCHE (de este hablaré en el presente Post Mortem)
De lo perdido... lo encontrado (un pequeño juego de rol, iniciándome en el desarrollo de juegos de este género)
Codename Panopticon. Este lo hice con un amigo de San Diego, CA. Aunque apenas va el concepto, espero que desee continuar con el mismo y no me mande a volar :(.

Afortunadamente, para los 3 hubo tiempo, además de mis pendientes en el trabajo y pude retomar mi camino de disciplina que perdí a causa del Cobijas (sí, me dio COVID19 por segunda ocasión). Pero es tiempo de contarles cómo me fue.

PSYCHE: El inicio de una IP

Primeramente les daré el bosquejo narrativo del videojuego y ya después el cómo me fue :3.

¿De qué va el juego?

Psyche es un juego que tiene como lugar la CDMX y trata de Adrián, un chico como cualquiera que se dedica a programar y a estar apegado al trabajo todo el tiempo. A pesar de ello tiene a su novia, Ivette y en ella ve un apoyo y a una gran persona con la que piensa vivir por el resto de sus días.

Desafortunadamente, un día despierta con un mensaje de Whatsapp que dice más o menos así:

Hola Adrián:

Quiero escribirte para terminar nuestra relación. Tú no tienes la culpa, eres una gran persona, sin embargo nuestros caminos deben separarse.

Por favor, no me busques.

Ivette

Al ver el mensaje, Adrián entra en depresión y busca respuestas, pues no era posible que algo que había sido tan bonito a la vez fuera tan pasajero. Entonces decide ir a una sesión de terapia psicológica para saber qué fue lo que pasó, sin saber él que con ello iba a cambiar la perspectiva que tiene de Ivette, él mismo, su psique e inclusive de eventos del pasado que creyó olvidados.

¿Cómo me fue con el desarrollo?

Pues al empezar el desarrollo y en base a que ya tenía muchas cosas en la narrativa que considero que estaban listas a espera de pulirlas, decidí poner manos a la obra el día 26. Ese día dieron el tema de este año a nivel internacional: LOST AND FOUND. Al ver que coincidía el tema con la narrativa del juego, fue tiempo de codear. Entonces, agarré Unity y unos asset packs que había comprado previamente y empecé a armar las diferentes escenas que involucraban al juego.

Me dí cuenta de varias cosas:

Unity da tratamiento diferente en la interfaz a la parte de la UI y al Tilemap y al principio te malviajas, pero ya al final le agarras la onda y listo.
Por fin le agarré el hilo a las herramientas de Tilemaps y me facilité el trabajo a lo bestia.
Igualmente investigué del uso de librerías que ya son estándar en el desarrollo con Unity como Cinemachine y una de IA básica.
También pude realizar deploys tanto a Windows como a MacOS, aunque solo publiqué en Windows por tiempo, con esto pude confirmar el multi-platform para computadoras. Incluso se podría hacer deploy para XBOX One, pero pues como no tengo, me la pelé :(.

En cuestiones de código fue más sencillo, puesto que al tener ya conocimientos previos de C# y estar con el diplomado de desarrollo videojuegos de la Universidad Anáhuac, así como el ver los videos de Brackeys, es como pude sacar adelante el juego, que a pesar de no estar completo, sí quedó muy avanzado en los aspectos básicos.

¿Y qué sigue?

Me encantó trabajar por fin en un proyecto de videojuegos después de más de 5 años de no haber hecho mucho y pues la verdad estoy muy ansioso de seguir trabajando en él. De principio de cuentas, hay que hacer lo siguiente:

Agregar shooting al personaje principal
Finalizar los personajes (protagonistas, antagonistas y minions).
Arreglar bugs y sacar el primer alpha.
El website.

Después para irme al siguiente Alpha, considero lo siguiente:

Terminar los tres primeros escenarios.
Probar un reproductor de videos cinemáticos en Unity. Ya debe haber alguno hecho y está en la Asset Store o de forma gratuita.
Mejorar la IA de los enemigos.
Mecanismo de seguimiento para los protagonistas (Una protagonista adicional seguirá al principal, hay que detallarlo más).

De pendientes opcionales están:

Armar assets originales y prescindir de los que usé. No es porque sean malos, de hecho son buenísimos, sin embargo, me gustaría hacer algo más original. Esta es tentativa, pues los assets que usé fueron comprados y están autorizados para desarrollos comerciales.

Finalmente, les dejo el video de "trailer" que armé ese día, como demostración de lo que hice en ese fin de semana, esperando que sea de su agrado.

Próximamente les traeré más aventuras de código, mientras tanto, solo puedo decirles como de costumbre Happy coding!