Author: Giovanni Collazo

Hace mas de siete años y sin avisar me llamó Arnaldo para contarme de un invento que tenía. La idea era simple, vamos a hacer un app para que la gente pueda pagar la gasolina.

Inmediatamente me pareció una buena idea. Estaba seguro que los consumidores les encantaría poder pagar en la bomba. Ahí, en esa misma llamada acordamos hacer el app y ver qué pasaba.

Desde cero

Dos o tres semanas más tarde nos encontramos en una estación de gasolina en Caguas. El dueño de la estación nos permitió probar el app ahí en un ambiente real. En este punto Arnaldo tenía casi todo el software de su lado terminado y yo tenía un app que parecía que debería funcionar. Lanzamos la primera transacción pero falló porque yo cometí un error configurando la bomba de gasolina. En el segundo intento la transacción llegó a la estación pero la bomba no encendió. Luego de tres o cuatro intentos más, la bomba encendió y logramos servir gasolina. ¡Funciona!

Desde ese día hemos estado pensando y trabajando sobre esta idea. Han pasado muchas cosas desde entonces, en su mayoría buenas y otras menos buenas pero hemos logrado seguir adelante. Hoy nuestros apps funcionan en la mayoría de las estaciones de servicio en Puerto Rico y el negocio sigue creciendo.

Tenemos clientes en República Dominicana, Colombia, Islas Vírgenes Americanas, Bahamas y Estados Unidos. Ahora el enfoque es Centro América así que muy pronto habrá noticias sobre este esfuerzo.

Siempre aprendiendo

Trabajando en este proyecto he tenido muchas oportunidades de aprender. Aprendí a hacer servicio al cliente a gran escala, a contratar personal técnico y personal no técnico, sobre ciberseguridad y sobre cómo manejar un equipo remoto de forma efectiva mucho antes que eso fuera la norma.

En los últimos años me he enfocado en tres areas: arquitectura de software, ciberseguridad y procesos de desarrollo de software.

Mucho de mi aprendizaje ha sido producto del éxito súbito e inesperado de nuestro negocio. Como suele pasar el “demo” se volvió el producto y había que moverse rápido. La velocidad produce deuda técnica que si no se atiende con prontitud se puede volver un problema.

Hace un tiempo nos dimos cuenta que nos estábamos moviendo un poco más lento de lo usual. La deuda técnica estaba empezando a ser un tema importante. Desde entonces hemos estado poco a poco “refactorizando” las areas donde hay más deuda y empezando a usar nuevas arquitecturas para evitar problemas en el futuro. Todos en el equipo hemos aprendido mucho, el software está en mucho mejor forma que cuando empezamos y tenemos una ruta clara para seguir mejorando.

Sobre el tema de ciberseguridad es de lo menos que sabía y a lo mas que le he dedicado tiempo. Desde antes de entrar en este negocio me interesaba la ciberseguridad pero nunca fue mi enfoque. En este negocio la ciberseguridad es posiblemente el tema más importante. Por suerte lo teníamos claro desde el principio y le hemos dedicado el tiempo y los recursos necesarios. Ha costado mucho dinero y ha tomado mucho tiempo pero lo hemos hecho bastante bien.

Pasar por el proceso de auditoría de PCI por primera vez fue casi traumático pero ya en este punto me parece lo mas normal del mundo. Además, desde el principio y sin saber, muchas de nuestras políticas y medidas de seguridad superaban por mucho los requisitos de PCI. Lo que más trabajo nos dio fue aprender a documentar cómo esperan los auditores, para poder demostrar lo que en gran medida ya estábamos haciendo correctamente.

Estos años han sido una escuela y me siento en un gran momento profesional. Tengo mucho conocimiento y muchas experiencias del mundo real que son increíblemente valiosas. Le he sacado el jugo a esta experiencia y estoy muy complacido.

De cero otra vez

Hace mas o menos un año tomé la decisión de dejar mi posición en Alias Payments (Gasolina Móvil) y moverme a hacer algo nuevo.

En Alias Payments tomamos una simple idea y la llevamos a ser un gran negocio. En este punto ya siento que he logrado todo lo que me propuse y que es momento de llevar lo aprendido a otros lugares.

Empezar de cero otra vez.

En el momento que escribo esto, todavía no tengo claro que voy a hacer pero hay tres areas generales que me interesan y estoy explorando:

• Empezar una compañía de software para negocios (B2B) con un modelo “software as a service” en algo relacionado a ciberseguridad.
• Armar un equipo de ingenieros especializados en “secure coding practices” para hacer consultoría a empresas y startups. El enfoque sería hacer auditorias de seguridad y ayudar a establecer políticas de “secure coding”.
• Explorar la idea de hacer consultoría a nivel ejecutivo a tiempo parcial con varias compañías a la vez, comúnmente conocido como “fractional CTO / CISO”.

Para ser honesto no tengo una idea favorita y no sé si terminaré haciendo alguna cosa totalmente diferente. Desde hoy empezaré a hablar con mis contactos y a explorar diferentes ideas para poder ir acercándome a una decisión.

Estoy claro que lo que sea que escoja hacer será un proyecto de tres o cuatro años mínimo así que no quiero apresurarme. Dicho eso, antes de que acabe el año espero saber y compartir a qué me voy a dedicar.

Beluga es un “hobby”

Llevo unos meses trabajando en un app para iOS que se llama Beluga. Este app es “un Twitter” que funciona sin necesidad de centralizar todos los datos en los servidores de una sola compañía. Es un Twitter descentralizado y antes de que me pregunten, no usa blockchain.

Mi meta es recrear “el Twitter del principio”, donde había mucha menos gente y las interacciones eran mas saludables. Había un momento cuando la gente en Twitter no estaba buscando de qué quejarse o de cómo montarsela a alguien que dijo una tontería. Tampoco había anuncios en cada tres tweets y no había un feed algorítmico tratando de robar toda tu atención para vender anuncios.

Otro de los objetivos de este proyecto es diseñar un protocolo que otros apps puedan adoptar y no quedarme en construir un app que solo funciona si una empresa tiene el control total.

Beluga no es mi próximo negocio o por lo menos dudo que lo sea. Por diseño, este proyecto hace bastante difícil que una sola entidad pueda “adueñarse” de los datos de los usuarios dificultando la mayoría de los modelos de negocio tradicionales para este tipo de apps.

Beluga es un “hobby” y dudo que se vuelva un negocio. Si se vuelve un negocio sería un grata sorpresa pero lo dudo. Pronto compartiré mas información sobre Beluga y anunciaré cuando lo publique.

Agradecimiento

No quiero terminar este post sin darle las gracias a todas las personas que han trabajado y que trabajan en Alias Payments y Artisoft Labs por lo mucho que me han enseñado, lo profesionales que son y sus buenos deseos. También quiero darle gracias a José Padilla quien fue uno de nuestros socios originales cuando arrancamos el negocio. Gracias a todos.

Finalmente, quiero agradecer a mi amigo desde por lo menos 1999 y socio en este negocio Arnaldo Rivera. Sin su iniciativa, conocimiento y su ética de trabajo sería imposible haber llegado donde hemos llegado. Durante todos estos años que hemos trabajado juntos hemos tenido sorprendentemente pocas diferencias y cuando han surgido siempre se han resuelto rápidamente y con mucho respeto. Hemos trabajado mucho y la hemos pasado muy bien. Ha sido genuinamente una gran experiencia en gran medida por el liderato de Arnaldo. Gracias.

Próximo

Tan pronto sepa lo que voy a hacer estoy seguro que lo comunicaré por aquí. Por ahora voy a explorar las alternativas y escucharé todas las propuestas que reciba.

Estoy increíblemente entusiasmado por empezar algo nuevo y sentir nuevamente la adrenalina de esos primeros días.

Déjame tus comentarios escribiendo a [email protected]

Photo: Unsplash

En mi trabajo escribo principalmente TypeScript sobre Node.js y aunque no es mi lenguaje favorito, no me molesta, tiene muchas cosas buenas. Para el tipo de proyecto que trabajo, el tener un “type system” es altamente valioso.

También escribo bastante Python (de mis lenguajes favoritos) para “scripts” locales y otras cosas que no necesariamente terminan en un ambiente de producción. Algún día escribiré un poco más sobre porque terminamos corriendo en Node.js y MongoDB.

No creo que exista el lenguaje de programación perfecto, perdón por el “clickbait”, pero para mi el lenguaje ideal es una mezcla entre Python, TypeScript, Go y Rust.

En este post enumero los ingredientes que me gustaría tomar prestados para un lenguaje nuevo imaginario. Seguramente este lenguaje jamás existirá y posiblemente eso sea lo mejor. Si hay algo que NO soy, es diseñador de lenguajes de programación.

Python

De Python me encanta que es fácil de leer y escribir y que tiene un “standard library” bastante completo. Cuando quiero resolver un problema que se puede resolver corriendo un pequeño “script” local, Python siempre me da los mejores resultados. Además hay muchas librerías para manejar datos y visualizaciones que son fáciles y útiles.

En cuanto “web apps” que es lo mas que hago, creo que Django es de lo mejor que he usado. Todo lo importante está incluido y lo que falta es fácil de añadir. Me gustaría que fuera un poco más flexible en cuanto a como organizar los proyectos para hacer mas fácil implementar una arquitectura hexagonal pero al final del día no tengo quejas mayores.

• Fácil de leer y escribir.
• El “standard library” es bastante completo.
• Hay muchas librerías para análisis y visualización de datos.
• Me encanta Jupyter Notebook.
• Django es mi web framework favorito.

TypeScript y JavaScript

De TypeScript me gusta mucho el “type system” y principalmente la idea de que puedes añadir los tipos poco a poco en un “codebase” viejo. Se que Python tiene su propio “type system” pero de lo que he visto el de TypeScript es mas poderoso y no es mucho más difícil de aprender.

Otro feature de TypeScript y JavaScript que me gusta mucho es la sintaxis para los “arrow functions” (args) => body. Además de facilitar el crear funciones anónimas creo que hace que el código sea más fácil de leer, especialmente cuando se usa map y filter.

Python tiene los list y dictionary comprehensions que me gustan bastante, pero creo que la sintaxis de los “arrow functions” es un poco mejor. Tambien en Python hay lambdas para definir funciones anónimas pero nunca recuerdo como se escriben. Sin duda los “arrow functions” son mejor.

• El “type system” es buenísimo y opcional.
• Me parece que el “type system” es mas poderoso que lo que ofrece Python en versiones mas recientes.
• Es fácil de aprender a sacarle provecho a los “types”.
• Los “arrow functions” en JavaScript me gustan más que los list y dictionary comprehensions de Python.
• Hacer funciones anónimas es mucho más natural que en Python.

Go

De Go lo más que me gusta es el modelo de concurrencia. Los goroutines hacen que sea fácil escribir código concurrente sin errores, algo que es un poco más complicado en Node y ni hablar de Python.

Otra cosa que me parece buenísima es la posibilidad de generar binarios “statically linked” para Windows, Linux y Mac. Un solo archivo binario con todas sus dependencias hace posible crear contenedores de Docker pequeños usando FROM scratch.

El tema de “performance” aunque no es una de las cosas que más me emocionan de un lenguaje, no se debe ignorar. Go al ser un lenguaje compilado produce programas que ejecutan mucho más rápido que programas escritos para Node o Python. Sin duda esto es algo positivo especialmente cuando estás haciendo “hosting” en la nube.

• El modelo de concurrencia facilita escribir código concurrente con menos errores.
• Compilar a un solo binario “statically linked” facilita “deploys” y el manejo de dependencias.
• Poder hacer un contenedor FROM scratch permite tener imágenes pequeñas y con la menor superficie de ataque posible.
• Mejor “performance” cuando se compara con Python o Node.

Rust

De Rust me gustan muchas cosas pero el enfoque del lenguaje en producir programas que sean fácil de analizar estáticamente, ha empujado ese lenguaje a tomar decisiones conservadoras sobre como manejar los datos.

El que todo sea inmutable por “default” sin duda es bueno para facilitar el análisis estático del programa y ayuda al programador a no tener sorpresas.

Los tipos Option y Result son otra cosa que me encanta de Rust. Estos dos tipos se encargan de manejar errores y funciones que pueden no devolver el valor que esperas. Esto te obliga a ser extremadamente explicito manejando errores y los casos donde el programa puede fallar. Nuevamente esto ayuda al programador a no tener sorpresas.

• Toda la data es inmutable por “default”.
• Al igual que Go los errores son valores que hay que atender de forma explícita.
• Los tipos Option y Result son enormemente útiles y me gustan mas que el if err != nil {} que se ve en todas partes en Go.
• Los “features” de “pattern matching” en combinación con Option y Result son una maravilla.

Conclusión

Ahí está, mi lenguaje de programación ideal es una mezcla de algunas ideas y “features” de estos cuatro lenguajes. ¿Te gustaría un lenguaje así?

Photo by Raimond Klavins

Recientemente escuché esta serie de podcasts sobre la historia de la web y me encantaron. Creo que cualquiera que trabaje construyendo la web debería conocer un poco sobre su historia y esta serie me parece ideal para eso.

Muy recomendado.

https://css-tricks.com/category/history/

If you have done any Node.js development, you’ve likely used NPM, and you should know that on your package.json file, you can add simple scripts that can be executed using npm run <name of script>. At first, this might seem convenient, and since most projects use it, why not use it.

In my experience, NPM scripts have a few problems.

• They are encoded as JSON strings that don’t have syntax highlighting or linting by default on most editors.
• Strings in JSON must be double-quoted, which produces the need to escape double quotes inside your scripts.
• Longer scripts make your package.json difficult to read and understand.
• On larger projects, you might need many scripts which can become unmanageable quickly. 
• Scripts are all on a single namespace forcing you to invent naming conventions like build:css, build:js, build:production:js, etc.

The only good reason to use NPM scripts is to hook into life cycle events like postinstall, prestart, and friends. If you need something more than mocha src/**/*.test.js, you will be better off avoiding NPM scripts.

My suggestion is to create a top-level folder named scripts and organize it however you like. Inside the scripts folder, you will have executable files without file extensions, and each file must begin with the correct shebang line. 

Here’s an example from one of my projects. This file is located at scripts/build, which can be invoked by running ./scripts/build on the root of the project.

#!/usr/bin/env bash
#
# Build project for production
#
set -euf -o pipefail

echo "-> Building App..."

# Remove old files if they exist
rm -rf ./build

# Run postcss build
./scripts/css-build

# Copy images to build
./scripts/img-build

# Run server TypeScript build
echo "-> Compiling server-side TypeScript..."
npx tsc

# Run client side JS build and minify
./scripts/js-build

# Copy other files to build dir
echo "-> Copiying *.hbs and *.json files..."
npx copyfiles --up 1 ./src/**/*.{hbs,json} ./build

echo "-> Build done"

This example is written in bash because it is a very short list of commands, each calling another smaller and much more focused script. You don’t have to use bash. Actually, if your script is more than a few lines long and requires some sort of logic, you might be better off using a more familiar programming language like JavaScript or Python or whatever you like.

Here’s the smallest possible example using Node.js as the runtime. This script can be invoked with ./scripts/node-env.

#!/usr/bin/env node
/**
 * Print the current NODE_ENV
 */
console.log(`NODE_ENV='${process.env.NODE_ENV}'`);

That’s it, that’s the idea. Just to recap:

• Create a top-level scripts folder and add your scripts to it.
• Scripts must not use a file extension. This will make it easier to change the language later.
• Add the required shebang like to the file. 
• Make sure the scripts are executable by running chmod +x scripts/<name of script>.
• Invoke scripts by running ./scripts/name.
• Only use NPM scripts to hook into the life cycle events like preinstall, postinstall, etc.
• If you use one of the life cycle event hooks, just call one of your scripts.

Let me know what you think.

Photo: Unsplash