Por eso empecé a construir un pequeño hub de orquestación. La idea es tener una sesión central de Claude Code, el agente de AI que uso desde la terminal, que conoce el proyecto, revisa los tickets y envía el trabajo al repositorio correcto. Esa sesión no escribe código. Su trabajo es coordinar a los agentes que sí lo hacen.

En este post quiero compartir cómo funciona esta idea, qué partes me han resultado útiles y qué cosas todavía necesitan mejorar. No creo que sea la única forma de trabajar con agentes de AI, pero hasta ahora me ha ayudado a mantener orden en un proyecto que está dividido en varios repositorios.

El problema no era generar código

Un agente puede leer un repositorio, hacer un plan y modificar archivos bastante bien. El problema aparece cuando una tarea necesita cambios en varios lugares. Cada agente tiene su propio contexto y puede tomar decisiones que no coinciden con las decisiones de los demás. También puede pasar que dos agentes trabajen sobre la misma rama o que una nueva sesión tenga que volver a investigar algo que ya se había discutido.

Mi primera decisión fue separar la coordinación de la implementación. El orquestador lee el ticket, revisa el contexto que ya existe y pregunta en cuáles repositorios se necesita trabajar. Después crea una sesión especializada para cada repositorio.

Esto parece una diferencia pequeña, pero me permite tener una sola vista del trabajo sin darle a una sesión demasiado poder. El orquestador no cambia código, no crea commits y no hace push. Cada agente trabaja con las reglas, herramientas y pruebas de su propio repositorio.

Worktrees y memoria compartida

Para aislar el trabajo uso Git worktrees gestionados por Worktrunk. Cada ticket obtiene su propio directorio y su propia rama, así que un agente puede trabajar sin modificar el directorio principal y sin interferir con otro ticket. También puedo abrir ese worktree en Neovim y revisar los cambios mientras el agente continúa trabajando.

Para monitorear cada tarea uso Herdr, un multiplexor de terminal para coordinar agentes, con una pestaña para Claude Code, otra para Neovim y otra para ver el diff en vivo usando Hunk, un visor de diffs de Git para la terminal. Cada worktree tiene su propio workspace de Herdr, así que puedo ver lo que está haciendo cada agente y revisar los cambios sin mezclar el contexto de un ticket con otro. No es un sistema automático de aprobación. Es solamente una forma práctica de tener a la vista lo que está ocurriendo y poder intervenir cuando algo no se ve bien.

El otro problema era la memoria. Si cada sesión empieza desde cero, una parte importante del tiempo se pierde leyendo el proyecto y reconstruyendo decisiones anteriores. Para evitarlo uso un vault de Obsidian como memoria compartida. Ahí guardo notas de los tickets, planes y contexto que puede servir para las siguientes tareas.

Antes de enviar un agente, el orquestador consulta esa memoria y le pasa solamente la información que necesita. De esta forma el vault funciona como una fuente común de contexto, pero el código continúa siendo responsabilidad de cada repositorio.

Cómo se ve una tarea

El flujo que uso ahora es más o menos el siguiente:

1. El orquestador lee el ticket y determina conmigo qué partes del proyecto necesitan cambios.
2. Consulta las notas existentes para no repetir investigación.
3. Crea un worktree y abre un agente especializado por cada repositorio involucrado.
4. Los agentes preparan un plan a revisar antes de escribir código.
5. Una vez aprobado el plan, los agentes hacen cambios, crean commits y hacen push a sus ramas.
6. Después de hacer merge, el orquestador guarda el contexto útil y elimina los worktrees que ya no se necesitan.

La revisión humana sigue siendo importante. En especial para cambios de frontend, prefiero revisar el plan antes de que el agente empiece a modificar archivos. Hago pruebas manuales y capturas de pantalla que sirven de documentación para el pull request.

Revisar un plan toma poco tiempo y es mucho más simple que corregir una implementación completa basada en una idea equivocada.

También uso el diff en vivo para revisar el trabajo sin esperar un reporte final. No necesito preguntar constantemente por el estado del ticket. Puedo ver si el agente está trabajando, si necesita ayuda o si está cambiando algo que no esperaba.

Lo que todavía no funciona tan bien

El sistema no está libre de problemas. La memoria compartida usa symlinks en algunos lugares y eso hace que la creación y limpieza de worktrees necesite más cuidado del que me gustaría. Una mala secuencia puede dejar un enlace roto o hacer que una nota no termine donde esperaba.

La limpieza de ramas también es más complicada de lo que parecía. No basta con revisar si existe una rama. El sistema debe confirmar que el cambio ya fue integrado antes de eliminar el worktree y la rama local. Por eso prefiero que cada repositorio termine su propio flujo de commit, push y pull request, y que el orquestador solamente limpie después.

La otra limitación es encontrar información en el vault. Guardar notas es sencillo, pero después de varias tareas ya no es práctico buscar archivo por archivo. Por ahora uso búsqueda por palabras y búsqueda semántica, aunque creo que la memoria necesitará un mejor índice conforme crezca el proyecto.

También he aprendido que guardar todo no significa tener buena memoria. Las notas deben ser cortas, claras y útiles para la siguiente sesión. De lo contrario solamente estamos moviendo el problema del contexto a una carpeta con demasiados archivos.

En conclusión

Construir este orquestador no hizo que los agentes escribieran mejor código de forma automática. Lo que mejoró fue la coordinación. Ahora cada agente tiene un espacio aislado, recibe el contexto necesario y trabaja dentro de las reglas de su repositorio. Yo mantengo una vista general de los ticket y todavía debo revisar los planes y los cambios antes de aceptarlos.

Lo más útil para mí ha sido separar tres responsabilidades: coordinar el trabajo, implementar los cambios y conservar el conocimiento. Claude Code se encarga de una parte, Git worktrees de otra y el vault de Obsidian mantiene el contexto entre sesiones. Tener una visibilidad completa de lo que ocurre en cada worktree con Herdr me permite intervenir cuando es necesario.

Aún hay detalles por simplificar, especialmente la sincronización de la memoria y la limpieza de worktrees. Pero como experimento ha sido una buena forma de trabajar con varios agentes sin perder por completo el control del proyecto.

Como Ingeniero de Software me es muy interesante todo lo que la comunidad hace con “Vibe Coding”. Y existen muchas opiniones y muchos comentarios de hasta donde llegaría el límite de AI como asistente o un reemplazo del Ingeniero de Software.

De nuevo al tópico de este sitio, al principio en su primera versión creé el sitio con Jekyll y hosteando en Github Pages. Posteriormente encontré Middleman y me pareció muy interesante la forma de crear el contenido estático. Ya por último y desde mi ultima versión migré el sitio de Middleman a Bridgetown y usando Netlify como hosting.

Y ahora, de vuelta a Jekyll. Y creo que Jekyll es la mejor plataforma para hacer un sitio blog como este. Es simple y ha estado en el mercado por muchos años. Y saltar de framework a framework cada que sale uno nuevo no es algo que quiera hacer seguido, al menos no con este sitio. Pero si quiero tenerlo actualizado, quiero que las dependencias se mantengan actualizadas. Por eso opte por migrar mi sitio a Jekyll y usar Vite con TailwindCSS y DaisyUI. Espero que estos ultimos no requieran de mucho esfuerzo para actualizarse en el futuro.

Y que tiene que ver el Vibe Coding?

Bueno, quiero enfocarme mas en escribir y quería darle un nuevo diseño a mi sitio sin tanto problema o este caso sin invertir mucho tiempo. Y también, probar que tan bueno sería la AI para hacer un diseño. Un Blog es sencillo, y Tailwind y DaisyUI ya están en el contexto de entrenamiento de las AI mas modernas, así que no fue tanto trabajo.

Para esto use VSCode, lamentablemente Neovim no tiene soporte avanzado para AI y agentes o herramientas que editen archivos. Así que simplemente activé el “Agent-mode” de VSCode y use Gemini 2.5 Pro. Creé los archivos que necesitaba y solo pedí que haga una UI “mobile-first”.

Luego de varias iteraciones sobre los templates, varios archivos, y configuraciones obtuve un resultado satisfactorio. Y no, no fue libre de errores. La paginación de posts no salio bien y ya tuve que intervenir para arreglarlo. De igual forma en varios detalles visuales y organización del código HTML. Pero donde si puedo decir que hizo un excelente trabajo fue cuando le pedí que basado en un CSS que tenia estilos para Rouge (el highligther default de Jekyll) hiciera uno con el tema catppuccin-frappe para dark-mode y latte para el sitio en light-mode. He aquí un ejemplo:

# This is an example

def fibonacci(n)
  return n if n <= 1
  fibonacci(n - 1) + fibonacci(n - 2)
end

En conclusión

Jekyll es una excelente opción para blogs y sitios estáticos. Tiene excelente soporte y le apuesto a su longevidad para mi sitio personal. TailwindCSS y DaisyUI son simples e increíbles, y la AI puede ser una gran ayuda para acelerar el proceso de diseño y desarrollo, aunque siempre es bueno tener un ojo crítico y hacer ajustes manuales cuando sea necesario. Para el fin de migrar mi sitio, le doy un punto a la AI.

Puedes consultar el repositorio de este sitio en Github.

Antes que nada, si no conoces o sabes que es Vim te explico de forma sencilla: Vim es un editor de texto cuyos predecesores existen desde los 80’s (ya unos 40 años), que funciona directamente en la terminal del sistema. Muchos llaman a Vim como el editor de los programadores y esto es por lo configurable y más que nada programable que es Vim.

¿Por qué usar algo tan viejo en este siglo XXI?

Mi cambio a Vim sucedió por algo inevitable: La pronta muerte de Atom. Esto sucederá tarde o temprano, y aunque no quiera sonar pesimista eso es lo que pasará. ¿Por qué morirá Atom? Es fácil resolver eso, ya no es cool para muchos.

Cuando Atom salió en el 2012 fue increible. Un editor que promovió y evolucionó la tecnología web dando a luz a muchos proyectos como Electron y que impulsó mucho el poder oculto de javascript fuera de la web, pero cuyos tiempos se agotan cada vez gracias a la mayor adopción que VS Code de Microsoft tiene ahora. Y no es culpa de Microsoft (ésta vez), es del trending, el hype que tiene, un algo que lo hace un competidor mejor que Atom.

Pero la gota que derramó el vaso fue la adiquicicíon de Github por Microsoft. Eso creo que declaró la muerte a Atom. Sin embargo Atom tiene su gente, tiene sus fans y seguramente seguira como un proyecto activo por algunos años más. Pero eso no lo sabremos.

Si VS Code es mejor que Atom, ¿por qué no usas VS Code y ya?

NO. No puedo. Existe algo que me impide realmente verlo como algo útil. Y jamás he estado a gusto con tecnología de Microsoft. Simplemente no se puede.

¿Qué opciones tengo?

¿Volver a Sublime? Si, quizás (y amé Sublime). Pero quiero algo open source, quiero algo libre.

¿Neta Vim?

Si, Vim. ¿Por que no?. Mucha gente lo usa y lo ha usado por casi 40 años. Muchos desarrolladores que admiro lo hacen. Y si eso sucede es por algo. Y si aún vive en estos tiempos de hype/trending adopment es porque algo bien hace. Y es la verdad. Es un editor increible.

Si ya leiste hasta aquí, lamento decepcionarte que esto no es un tutorial de Vim. Hay muchos por ahi que podrías revisar. Pero creo que lo importante de aprender ha usar una herramienta, como lo es Vim, es que lo hagas por pasos. Que lo hagas a tu forma y ya tu ritmo. Podrías obligarte a usar Vim desintalando cualquier otro editor como lo hice yo. Podrías ir acostumbrandote a sus comandos usando plugins para tu editor favorito, de tal forma que éste emule Vim. El chiste es que es algo muy personal, pero que sin duda te recomiendo hacer alguna vez.

¿Valió la pena?

Lo valió cada maldito segundo. Por su puesto que me sentí como un completo simio al principio. Habián veces que no sabía que estaba haciendo. Y en las que al presionar alguna tecla algo cambiaba en el archivo y solo presionaba ESC como loco para ver si no la había cagado en algo. Me tomó meses de aprender, de crear memoria muscular con los comandos, de interpretar la pantalla y de crear una configuración para mi.

Creo que realmente ha mejorado la forma en la que escribo código. Ha cambiado la forma en la que veo y percibo un entorno de desarrollo.

Éste no será el último post sobre Vim. Espero hablar un poco de las configuraciones que tengo. Sin embargo tengo otro contenido que quiero escribir, pero ahora sobre Emacs.

Pop!_OS 18.04 supports the graphics card with an ISO image that has the most current proprietary drivers that System76 maintains. The most current driver is version 418, you can check the version installed on your OS with the command nvidia-smi.

+--------------------------------------------------------------------------+
| NVIDIA-SMI 418.56       Driver Version: 418.56                           |
|-------------------------------+----------------------+-------------------+

Pop!_OS has a metapackage to natively install Tensorflow and CUDA, however this metapackage installs up to version 1.9 of Tensorflow.

Configure Python 3

First we install the necessary packages to start our development with python3, we will install pip and venv to manage the dependencies of our python projects.

$ sudo apt install python3-dev python3-pip python3-venv

Install CUDA 10.0

To install version 1.13, the last stable of Tensorflow, we need to have the Nvidia 418 drivers and install the following dependencies for CUDA and Tensorflow.

$ sudo apt install autogen autogen-doc cmake cmake-data\
    guile-2.0-libs libblas3 libgc1c2 libgfortran4 libjsoncpp1\
    liblapack3 libnvidia-compute-418 libopts25 libopts25-dev\
    librhash0 libuv1 python3-numpy

Now install the necessary CUDA packages.

$ sudo apt install system76-cuda-10.0 system76-cudnn-10.0

There are CUDA packages with version 10.1, however they do not have support for Tensorflow 1.13. See here.

Install Tensorflow GPU

We will create a new folder for our project

$ mkdir ~/test_tensorflow_gpu
$ cd test_tensorflow_gpu

We started a new virtual environment for our dependencies to this project.

$ python3 -m venv venv
$ source venv/bin/activate

Having activated the virtual environment already allows us to run both python3 and pip3 as python and pip respectively.

Install Tensorflow. The correct package to install Tensorflow with CUDA support is tensorflow-gpu.

(venv)
$ pip install --upgrade tensorflow-gpu

Test the installation of Tensorflow.

(venv)
$ python -c "import tensorflow as tf; print(tf.test.is_built_with_cuda());"
True # <-- expected output

Pop!_OS 18.04 da soporte a la tarjeta gráfica con una imagen de ISO que tiene los drivers privativos más actualizados que System76 da mantenimiento. El driver más actual es la version 418,puedes revisar la versión instalada en tu OS con el comando nvidia-smi.

+-------------------------------------------------------------------------+
| NVIDIA-SMI 418.56       Driver Version: 418.56                          |
|-------------------------------+----------------------+------------------+

Pop!_OS tiene un metapaquete para instalar nativamente Tensorflow y su soporte a CUDA, sin embargo este metapaquete instala hasta la versión 1.9 de Tensorflow.

Configurar Python 3

Primero instalamos los paquetes necesarios para iniciar nuestro desarrollo con python3, instalaremos pip y venv para manejar las dependencias de nuestros proyectos python.

$ sudo apt install python3-dev python3-pip python3-venv

Instalar CUDA 10.0

Para instalar la versión 1.13, la última estable de Tensorflow, Necesitamos tener los drivers Nvidia 418 e instalar las siguientes dependecias para CUDA y Tensorflow.

$ sudo apt install autogen autogen-doc cmake cmake-data\
    guile-2.0-libs libblas3 libgc1c2 libgfortran4 libjsoncpp1\
    liblapack3 libnvidia-compute-418 libopts25 libopts25-dev\
    librhash0 libuv1 python3-numpy

Ahora instalar los paquetes necesarios de Nvidia CUDA.

$ sudo apt install system76-cuda-10.0 system76-cudnn-10.0

Existen paquetes de CUDA con versión 10.1, sin embargo no tienen soporte para Tensorflow 1.13. Ver aquí.

Instalar Tensorflow GPU

Creamos una nueva carpeta para nuestro proyecto

$ mkdir ~/test_tensorflow_gpu
$ cd test_tensorflow_gpu

Iniciamos un nuevo virtual environment para nuestras dependencias a este proyecto.

$ python3 -m venv venv
$ source venv/bin/activate

Al tener activado el virtual environment ya nos permite ejecutar tanto python3 como pip3 como python y pip respectivamente.

Instala Tensorflow. El paquete correcto para instalar Tensorflow con soporte a CUDA es tensorflow-gpu.

(venv)
$ pip install --upgrade tensorflow-gpu

Prueba la instalación de Tensorflow.

(venv)
$ python -c "import tensorflow as tf; print(tf.test.is_built_with_cuda());"
True # <-- salida esperada

What are the Webhooks for?

Webhooks are endpoints in your application where a service like Paypal or Stripe will inform you about the events happening in them. Paypal and Stripe use them to notify whether a charge was successful or not, for example. This mechanism is necesary given the charges proccess are asyncronous. Ergo, in the moment we create a charge using thier API we won’t know until in the future if the charge was successful or not.

Standard way

The webhook is just an endpoint (route or path) which receives information through POST method. In Rails a barebone implementation of Stripe webhook could be:

# controllers/stripe_controller.rb
# Method responsbile for handling stripe webhooks
def webhook
  begin
    event = JSON.parse(request.body.read)
    case event['type']
      when 'invoice.payment_succeeded'
        # handle success invoice event
      when 'invoice.payment_failed'
        # handle failure invoice event
      # More events...
    end
  rescue Exception => ex
    render :json => {:status => 400, :error => "Webhook failed"} and return
  end
  render :json => {:status => 200}
end

This webhook method uses a switch-case in order to determinate, with the event type that was received, which code block execute. Now imagine implement more events, this method will smell and get hard to maintain.

Sure we can write more methods to put the logic of each event and call them into the switch-case, however we can still improve this webhook method.

Cleaner way

The cleanest webhook implementation I’ve seen is in Laravel Cashier. Cashier’s Webhook Controller allows you to handle automaticaly by mapping each event to a method. The controller convention says that if you want to handle the event invoice.payment_succeeded create a method in the controller whose name start with handle and the camelCase form of the event type: handleInvoicePaymentSucceeded.

<?php

namespace App\Http\Controllers;

use Laravel\Cashier\Http\Controllers\WebhookController as CashierController;

class WebhookController extends CashierController
{
    /**
     * Handle a Stripe webhook.
     *
     * @param  array  $payload
     * @return Response
     */
    public function handleInvoicePaymentSucceeded($payload)
    {
        // Handle The Event
    }
}

Refactoring

How can we achieve this with Rails?. Easy, thanks to metaprogramming in Ruby. Refactoring the previous method could get like this:

def webhook
  begin
    event = JSON.parse(request.body.read)
    method = "handle_" + event['type'].tr('.', '_')
    self.send method, event
  rescue JSON::ParserError => e
    render json: {:status => 400, :error => "Invalid payload"} and return
  rescue NoMethodError => e
    # missing event handler
  end
  render json: {:status => 200}
end

def handle_invoice_payment_succeeded(event)
  #handle the event
end

def handle_invoice_payment_failed(event)
  #handle the event
end

# and more...

In the webhook method we need to parse the event type to the name of the method which will handle that event.

1. Translate all '.' to '_' and concatenate with "handle_".
2. Then send the message to call the resultant method with the payload obtained.
3. Otherwise, if there’s no method implemented for that event, it will be rescued where we can make another action.

Laravel Cashier implementation looks wonderful to handle webhook events. Therefore this way you get a clean and maintainable controller.

ProTip

As a next step you could write concerns to group event handlers. Now you have a lighter controller.

Do you want to read this article in spanish? Check it here

¿Para qué sirven los Webhooks?

Los webhooks son endpoints en tu aplicación por el cuál un servicio como Paypal o Stripe te informarán sobre los eventos que ocurran dentro. Paypal y Stripe los usan para avisar sobre si un cargo fue exitoso o falló por ejemplo. Este mecanismo es necesario ya que los procesos de cargos, creación o cancelación de pagos se hacen de forma asincróna de nuestra aplicación. Es decir, en el momento que creamos un cargo a traves de la API no sabremos hasta en un futuro si el cargo fue exitoso o no.

Implementación estandard

El webhook es un solo endpoint (ruta) que recibe información mediante el método POST de HTTP. En ruby on rails una implementación de Webhook de Stripe podría ser la siguiente:

# controllers/stripe_controller.rb
# Method responsbile for handling stripe webhooks
def webhook
  begin
    event = JSON.parse(request.body.read)
    case event['type']
      when 'invoice.payment_succeeded'
        # handle success invoice event
      when 'invoice.payment_failed'
        # handle failure invoice event
      # More events...
    end
  rescue Exception => ex
    render :json => {:status => 400, :error => "Webhook failed"} and return
  end
  render :json => {:status => 200}
end

Este método webhook hace uso de un switch-case para poder determinar, a través del tipo de evento que se ha recibido, cuál será el bloque de código a ejecutar. Ahora imagina implementar más eventos, este método se volvería muy sucio y difícil de mantener.

Claro que podemos hacer más métodos para colocar la lógica de cada evento e invocar estos métodos dentro del switch-case, sin embargo aún podemos mejorar el método de webhook.

Implementación Limpia

La implementación más limpia que he visto sobre este tema de webhooks es de Cashier de Laravel. El controlador de webhook de Cashier permite manejar los eventos del webhook de forma automática mapeando cada evento a un método. La convención del controlador dice que si quieres manejar el evento invoice.payment_succeeded, entonces crea un método en el controlador cuyo nombre empiece por handle y la forma en camelCase del tipo de evento: handleInvoicePaymentSucceeded.

<?php

namespace App\Http\Controllers;

use Laravel\Cashier\Http\Controllers\WebhookController as CashierController;

class WebhookController extends CashierController
{
    /**
     * Handle a Stripe webhook.
     *
     * @param  array  $payload
     * @return Response
     */
    public function handleInvoicePaymentSucceeded($payload)
    {
        // Handle The Event
    }
}

Refactoring

¿Cómo podríamos conseguir lo mismo con Rails?. Es sencillo gracias a la metaprogramación en Ruby. La implementación refactorizando el método anterior sería más o menos así:

def webhook
  begin
    event = JSON.parse(request.body.read)
    method = "handle_" + event['type'].tr('.', '_')
    self.send method, event
  rescue JSON::ParserError => e
    render json: {:status => 400, :error => "Invalid payload"} and return
  rescue NoMethodError => e
    # missing event handler
  end
  render json: {:status => 200}
end

def handle_invoice_payment_succeeded(event)
  #handle the event
end

def handle_invoice_payment_failed(event)
  #handle the event
end

# and more...

En el método del webhook debemos convertir el tipo de evento al nombre del método que se encargara de manejar ese evento específicamente.

1. Convertimos los '.' por '_' y concatenamos con "handle_".
2. Lo siguiente es pasar el mensaje de invocar el método resultante con el payload obtenido.
3. Posteriormente, si no existe un método implementado para un evento entraría en el rescue NoMethodError => e donde podemos realizar otra acción en su caso.

La implementación de Laravel Cashier para manejar los eventos de Stripe me pareció increible. Por lo tanto de esta forma obtendrás un controlador mantenible y limpio.

ProTip:

Como siguiente paso podrías implementar concerns para agrupar en modulos los eventos que necesites manejar. Así mantienes el controlador del webhook ligero.

Although the salary range skill classification is aimed towards PHP programmer, the type of programmer classification can be applied outside php programming. The following list suggests what a Rookie, Junior, Senior and Master developer skills are expected to get into that classification.

The salary range could be generalized as follows:

Rookie usually writes code without consistency in indentation or conventions and usually copies and pastes anything found on the internet that seems to do what it was asked to deliver and that, according to the forums, is the solution.

Apprentice has accepted that he/she needs to improve and decides to learn the best practices and apply them. He/She consults forums not for searching code that he/she could simply copy/paste, instead he/she analyzes it and asks her/his issues after having investigated by his/her own.

Junior knows what design patterns are and applies them, understands the basics of what MVC, REST, CRUD, ORM, SQL Injection, XSS, I / O Sanitization, etc. are, applies this knowdledge alogside other techniques; He/she is an excellent learner and uses third-party APIs.

Senior is capable of developing his/her own tools and APIs, is aware of how his/her domain language works internally, is highly interested in the performance of applications beyond its ease of development, he/she is not satisfied with the functioning and design of all third-party tools and APIs as they come, and always seeks to innovate and create things that improve performance, facilitate their work and the speed of their deliverables; contributes with code in different projects and communities.

Master is capable of developing his own extensions, gems or libraries, and optimizing them for his/her best use; contributes to Open Source projects and he/she is normally dedicated to improving the performance of high performance applications. Knows the domain language its origin and differences with others languages.

Core contributes to the development of the core of the domain language; contributes in some extensions, gems or libraries and public tools; He/she is a frequent speaker at international conferences and it is usual to see his/her name in the credits of changes of version of his domain language.

So … What kind of programmer are you?

Many developers are called Senior after years of work, or experts in some framework or language when they only do tutorials; however, your work and contribution and how it affects other’s people work (not only in your workplace) tells vastly what type of programmer you are.

Do you want to read this article in spanish? Check it here

Es por eso que decidí escribir acerca de C, y de cosas que he encontrado de él que no me fueron enseñadas cuando tomé el curso de programación hace años. Espero encuentres útil la siguiente información que comparto.

Apuntadores

La definción más sencilla de mencionar de un apuntador es:

Un apuntador es una variable que posee un tipo de dato, él cuál apunta a una dirección de memoria.

Decir que apunta a una dirección de memoria es que el valor que un apuntador guarda es literalmente el número de la dirección de memoria. La memoria esta direccionada como si fuera un arreglo, desde el 0 hasta, por ejemplo, tus 8GB de memoria RAM.

Tengamos como ejemplo este programa en C.

#include <stdio.h>
#include <stdlib.h>

int main(int argc, const char *argv[])
{
	int numero = 20;
	int * a_numero = &numero;

	printf("El numero es %d\n", numero);
	printf("El apuntador tiene como memoria %d\n", a_numero);
	printf("El valor del apuntador es %d\n", *a_numero);

	return 0;
}

En este programa vemos la definición de un apuntador, esta es int * a_numero = &numero, que significa: definir un apuntador de enteros llamado a_numero. El valor que se le da al apuntador es &numero, poner el & antes del nombre de la variable pide el apuntador (o dirección de memoria) de la variable numero.

El resultado del código sería lo siguiente

El numero es 20
El apuntador tiene como memoria 1598883260
El valor del apuntador es 20

Observa el segundo resultado de imprimir el apuntador. Este es el número de memoria en donde se encuentra alojado la variable numero. El apuntador a_numero puede obtener su valor al usar el * al inicio de su nombre, es decir: *a_numero obtiene el valor de aquella posición de memoria del que a_numero apunta.

El apuntador es una referencia

Si, el apuntador a_numero es una referencia a numero, asi que cualquier operacion que hagamos sobre *a_numero será sobre el valor de numero. La reasignación, por ejemplo, de *a_numero hará que el valor de numero también cambie.

#include <stdio.h>
#include <stdlib.h>

int main(int argc, const char *argv[])
{
	int numero = 20;
	int * a_numero = &numero;

	printf("El numero es %d\n", numero);
	printf("El apuntador tiene como memoria %d\n", a_numero);
	printf("El valor del apuntador es %d\n", *a_numero);

	*a_numero = 40;

	printf("El numero es %d\n", numero);
	printf("El valor del apuntador es %d\n", *a_numero);

	return 0;
}

En el ejemplo de código anterior, observa que hacemos una reasignación *a_numero = 40;.

El resultado de ejecutar el programa es:

El numero es 20
El apuntador tiene como memoria 1598883260
El valor del apuntador es 20
El numero es 40
El valor del apuntador es 40

Entonces al modificar el valor de *a_numero modificó de igual forma a numero. Esto es lo que se conoce como referencia en programación. Tener una referencia es tener un apuntador a un valor que ya se encuentra en la memoria y que los cambios que apliquemos sobre ella tomarán efecto como si trabajaramos con la variable real.

Espero que encuentres útil ésta información. En la siguiente publicación de esta serie hablaré sobre los struct en C y cómo hacer nuestros propios tipos de datos complejos para dar a nuestros programas un mejor manejo de la memoria.

No sigas ninguna convención.

Eres un Senior Developer, ninguna convención de un grupo gringo de programadores te va a decir como programa. Tu código es hermoso de por sí. ¿Por qué necesitas poner todo bien indentado? No es tu culpa que el IDE de los demás no ponga bien los tabs o spaces.

No hagas pruebas para tu código.

No las necesitas. Es tu código y es perfecto. Las pruebas sólo son una perdida de tiempo y tu no tienes ese tiempo. Si no te lo enseñaron en el colegio es porque no son importantes. Esos Ingenieros de software son muy desconfiados, tu código no necesita probarse. Además las pruebas no son seguras, no es como que un usuario lo este probando de verdad, ¿no?

No uses patrones de diseño.

Solo hacen que tu código sea menos entendible. Todos sabemos como funcionan los switches, if’’s y for’s, asi que unos cuantos anidados no le hacen mal a nadie. No tienes porque mejorar eso. Eres un Senior Developer y tu sabes lo que haces.

No extiendas librerías, tómalas y modifícalas.

Eres un gran Senior Developer, tan grande que podrias tomar jQuery y “mejorar” sus métodos. No tienes porque pluggear nada. Tu puedes tomar la fuente y hacer tus cambios sobre ella. Eres grande.

No uses herramientas automatizadas, ni minifiques tus archivos.

Sabemos que hacer las cosas a mano es mejor que automatizar esas tareas repetitivas. Webpack y Gulp son cosas que no necesitas.

No necesitas pensar mucho en las soluciones de software.

Eres un gran Senior developer, obsesionate con esa base de datos no relacional y úsala en TODO, no te pongas a investigar cuanto te va a costar, Tú úsala, sabes que “one size fits all”, total ese “relacional” es tan anticuado. Todo lo que tu digas que se debe usar se usará, tanto así que ya eres un Arquitecto de Soluciones.

Estos son solo algunos de los pasos a seguir para llegue alguien y tire todo tu código. Un buen Senior Developer debe tener la mente abierta a técnicas que ayuden a incrementar la calidad del producto software en el que trabaja.

Las pruebas unitarias y de aceptación son parte de tu mismo código, uno sin el otro no están completos, así que documéntate de los beneficios que tiene seguir metodologías de testing en tus proyectos. así que no ignores a los Juniors developers que tienes ahí. Ellos sólo quieren mejorar el código.