La deuda técnica

La deuda técnica es un tema importante a considerar en el desarrollo de software. Se refiere a la acumulación de tareas pendientes, como la documentación, el mantenimiento, el refactorizado y la eliminación de código obsoleto. A medida que la deuda técnica aumenta, se vuelve cada vez más difícil y costoso mantener y mejorar el software.

Robot arreglando código

En mi experiencia, hay varias razones por las que la deuda técnica puede acumularse. Una de las principales es la falta de tiempo para dedicar a tareas no relacionadas con el desarrollo de nuevas funcionalidades. A menudo, se priorizan las tareas que producen resultados visibles a corto plazo en lugar de las que tienen un impacto a largo plazo.

Otra razón es la falta de disciplina en el desarrollo de software. A veces, los desarrolladores se sienten presionados por plazos ajustados y optan por escribir código rápido y sucio en lugar de tomarse el tiempo para refactorizar y documentar adecuadamente.

La solución para reducir la deuda técnica es simple pero no es fácil. Es necesario dedicar tiempo y recursos para abordar las tareas pendientes. Esto puede incluir dedicar tiempo cada semana para el mantenimiento y la documentación, o incluso asignar un equipo específico para abordar la deuda técnica.

Además, es importante fomentar una cultura de disciplina y responsabilidad en el equipo de desarrollo. Esto puede incluir establecer estándares de calidad y proporcionar retroalimentación continua sobre el cumplimiento de estos estándares.

En resumen, la deuda técnica es un problema común en el desarrollo de software, pero puede ser manejado si se toman medidas proactivas para abordarlo. Dedicar tiempo y recursos, y fomentar una cultura de disciplina y responsabilidad, son fundamentales para reducir la deuda técnica y mejorar la calidad del software.

Cómo usar raspberry pi pico con PlatformIO

Hace tiempo que trasteo con varias placas de desarrollo que intento integrar en distintos proyectos de IoT, la mayoría relacionados con nomorekeys, el caso es que generalmente he utilizado arduino (el pro micro es mi favorito) o el ESP32 cuando necesito wifi (antes el ESP8266). Hay muchos otros por ahi, como el seeeduino xiao y muchos de Nordic.

Raspberry pi pico pinout

El caso es que tengo mucho código escrito en C/C++ para el entorno Arduino y, resulta, que puedo reutilizarlo en distintos procesadores utilizando un plugin para visual studio code llamado PlatformIO, lo que he ido haciendo para los distintos arduino, ESP y Seeeduino, Hace relativamente poco tiempo me decidí a probar el nuevo MCU de Raspberry, el Raspberry Pi Pico, pero me centre en usarlo con CircuitPython, teniendo unos resultados excelentes y que os recomiendo probar.

Llegado el caso necesité más memoria para un proyecto que inicialmente estaba codificado para arduino pro micro ya que este solo posee 2,5k de memoria RAM y se quedaba muy corta. Revisando lo que tenía por casa me di cuenta que tenía un par de rpi pico por ahí de las pruebas con python y me di cuenta que tenían 264k de memoria (x100 lo que tiene un arduino), tampoco andan mal de precio y tienen todos los pines de entrada salida que necesitaba, así que, manos a la obra… Vamos a ver si podemos adaptar el código de arduino a la pico… Usando PlatformIO.

No voy a entrar ahora mismo ni en cómo instalar platformio ni en como crear un proyecto, eso os lo dejo para vosotros o si me lo pedís lo esccribo más adelante, por ahora partiremos de que eso ya lo has hecho.

Si ya tienes un proyecto hecho con platformio, enhorabuena, todos los cambios que tendrás que hacer es incluir esto en tu platformio.ini:

[env:pico]
platform = raspberrypi
board = pico
framework = arduino

Recuerda poner el #include <Arduino.h> si estás importando un sketch del ide de arduino y ya estaría…

La primera vez que quieras subir el código a la placa tendrás que copiar el archivo firmware.uf2 después de haber puesto en modo boot la placa (enchufala al ordenador pulsando el botón de la misma), yo lo hago con este comando (uso linux)

cp .pio/build/pico/firmware.uf2 /media/$USER/RPI-RP2/

Las siguientes veces ya no hará falta, puedes dar al botón upload directamente y el código compilado se subirá a la placa.

Happy coding!

Gestión de versiones de Flutter

Flutter es un framework que me está gustando bastante, es muy consistente en cuanto a las distintas versiones, se ve muy similar en todas las plataformas y Dart como lenguaje es bastante interesante y nada esotérico (por eso de que usa cosas que ya manejamos y no se dedica a reinventar la rueda).

Flutter Version Management

Tanto es así que empezamos hace unos meses un proyecto de aplicación móvil con Flutter, coincidiendo con la llegada de la versión 2.0 y las cosas empezaron a ir «demasiado deprisa». La comunidad y los mantenedores del sdk parece que se han puesto las pilas y han decidido incluir mejoras a un ritmo trepidante, cuando escribo estas líneas ya vamos por la versión 2.8.1.

Nosotros estabilizamos la app en un contenedor docker usando la versión 2.5.2 de Flutter y nos encontramos ahora que no hay manera de instalar desde cero esa versión con los sistemas que proporciona Flutter. Todos aquellos sistemas en los que hicimos un upgrade ya no los podemos utilizar para desarrollo porque, entre otras cosas, han cambiado librerías y ya no son compatibles algunas partes de nuestro código.

Pero no soy el único con ese problema. Varios de los desarrolladores de Flutter se han encontrado con la misma situación y, afortunadamente, han desarrollado una manera de poder disponer de una versión propia de flutter para cada proyecto… Mediante FVM.

Os cuento los pasos básicos para tener FVM funcionando (partiendo de que has instalado flutter en tu sistema) y cómo usarlo para cada proyecto:

1. Instalar FVM

dart pub global activate fvm

Esto te instala el paquete, pero tendrás que cambiar el entorno para poder acceder al comando fvm cada vez, en mi caso es algo como:

export PATH="$PATH":"$HOME/.pub-cache/bin"

Añadiendo esta línea al final del ~/.bashrc conseguiréis meter en el path el comando FVM

2. Instalar una versión de flutter para su uso posterior

En mi caso quería instalar la versión 2.5.2 y tuve que ejecutar esto:

fvm install 2.5.2

Puedes instalar tantas como quieras (o necesites), puedes conseguir la lista de todas las instaladas con el comando fvm list

3. Usar una versión concreta en tu proyecto

Dentro del directorio del proyecto en el que quieras usar esta versión puedes sustituir el uso del comando flutter por el comando fvm flutter que te ejecutará la versión correspondiente, para indicar qué versión quieres usar debes escribir:

fvm use 2.5.2

Esto te genera un directorio .fvm en donde se almacenarán los enlaces correspondientes, no olvides incluir en tu .gitignore el directorio .fvm/flutter_sdk

Con esto y algunas cosillas más (os dejo consultar la documentación) ya podréis desarrollar y depurar con la versión de flutter que queráis.

log4j, las vulnerabilidades, los parches y la sobre-ingeniería

Durante estos días si te dedicas mínimamente a esto de la informática y has creado algún sistema con Java habras sufrido el problema del log4jshell. Si es que no, pues te lo explico:

log4j es una librería de Java que lleva existiendo desde hace innumerables años y que es muy utilizada para registrar los eventos que tienen lugar en un sistema y poder controlar qué se registra y qué no. Pues bien, la versión 2 de esta librería incluía funcionalidades para hacer sustituciones en las cadenas que se guardan en el log y, continuando con la tradición más añeja de Java, se les ocurrió que sería buena idea que esas cadenas a sustituir pudiesen hacer llamadas a sistemas externos y recibir objetos completos. Utilizando el estandar jndi permitían incluso hacer llamadas RMI o acceder a servidores LDAP. Supongo que el programador que añadió estas funcionalidades vería su utilidad en algún momento, pero también es cierto que yo nunca he visto a nadie usarla.

En fin, que esto llevaba ahí un tiempo y a algún «hacker malvado» se le ocurrió probar qué pasaba si en la url que le pasaba a la cadena a loguear incluía la dirección de un servidor que él controlaba y que permitía descargarse un objeto que hacía «cosas malas» en el sistema… Y la prueba funcionó y en cuanto alguien se dió cuenta que había cadenas extrañas que empezaban por ${jndi:ldap:// y que provocaban funcionamientos anómalos se dio la voz de alarma y se creó un registro de vulnerabilidad (CVE-2021-44228) y con un exploit super-sencillo y que mostraba que había cientos de miles de sistemas afectados.

El parche a esa vulnerabilidad llegó pronto (y eso que log4j está mantenido solo por voluntarios) y mucha gente se pasó buna parte del fin de semana parcheando los sistemas (alguno tardó algo más), aunque sin tener muy claro si el sistema había sido comprometido y modificado antes, cosa que requiere otras medidas adicionales y muy costosas. A día de hoy se ha encontrado que el parche que se hizo no contempla todos los casos y se ha registrado otra vulnerabilidad (CVE-2021-45046) que requiere otro parche… Parches, que, al fin y al cabo lo único que hacen es deshabilitar esa funcionalidad que, en algún momento, a alguien, le pareció interesante.

Son incontables el número de horas que el personal de IT (desde programadores hasta técnicos de sistemas) se han dedicado a tapar este agujero (y seguro que habrá muchos agujeros sin tapar todavía). Eso se traduce en muchos millones de Euros de dinero gastado sin sentido… Y todo porque a alguién «le pareció una buena idea esa funcionalidad» y porque todo el mundo usa componentes que no conoce, en los que «confía», aunque no poga un duro para su desarrollo…

Por cierto… Hay por ahí ya los «negacionistas de los parches» que van diciendo que si los parches son malos, que no saben lo que hay dentro, que todo es parte de una conspiración y esas cositas… En fin, el ser humano es lo que tiene (o no).

ACTUALIZACIÓN 17-12-2021: Hay todavía otro parche que meter, el 2.17.0 ya que hay una cadena especial que puede dar como resultado un DDoS… A ver lo que nos dura.

Subir automáticamente tu app a la play store

Últimamente estoy muy metido en esto del CI/CD (Integración continúa/Despliegue continuo) que no significa, ni más ni menos, que las actualizaciones a los repositorios de código generan automáticamente todos los artefactos necesarios para poder comprobar que están correctos y que pueden desplegarse en producción, e incluso desplegarlos si así lo consideramos.

En el caso de servicios en internet de cualquier tipo (webs, APIs, etc.) el método de despliegue suele ser más sencillo de automatizar (básicamente generas un contenedor con una versión nueva y lo «empujas» al sistema de producción), más sencillo incluso si utilizamos kubernetes o ansible. Pero en el caso de distribución de aplicaciones a instalar en clientes es más complicado. En el caso que traemos aquí lo que queremos hacer es subir a la tienda de google play (y ya veremos qué hacemos con apple) una nueva versión de una aplicación móvil.

En principio debería ser sencillo, ya que solo tenemos que utilizar el API de Google Play para desarrolladores. Pero antes, tenemos que conseguir ciertas «autorizaciones» de google que no son tan triviales como deberían. Para haceros la tarea un poco más sencilla, aquí os dejo un script python que hace justo lo que queremos: subir a la tienda nuestro apk recién compilado al canal alpha (upload_apks.py)

"""Uploads an apk to the alpha track."""

import argparse

from googleapiclient import discovery
import httplib2
from oauth2client.service_account import ServiceAccountCredentials
from oauth2client import client

TRACK = 'alpha'  # Can be 'alpha', beta', 'production' or 'rollout'
SERVICE_ACCOUNT_EMAIL = (
    'ENTER_YOUR_SERVICE_ACCOUNT_EMAIL_HERE@developer.gserviceaccount.com')

# Declare command-line flags.
argparser = argparse.ArgumentParser(add_help=False)
argparser.add_argument('package_name',
                       help='The package name. Example: com.android.sample')
argparser.add_argument('apk_file',
                       nargs='?',
                       default='test.apk',
                       help='The path to the APK file to upload.')
argparser.add_argument('key_file',
                       nargs='?',
                       default='key.json',
                       help='key in json format for service account')
argparser.add_argument('version',
                       nargs='?',
                       default='New version',
                       help='Version name')

def main():
  # Process flags and read their values.
  flags = argparser.parse_args()

  package_name = flags.package_name
  apk_file = flags.apk_file
  key_file = flags.key_file
  version = flags.version
  
  credentials = ServiceAccountCredentials.from_json_keyfile_name(
      key_file,
      scopes='https://www.googleapis.com/auth/androidpublisher')
  http = httplib2.Http()
  http = credentials.authorize(http)

  service = discovery.build('androidpublisher', 'v3', http=http)

  try:
    edit_request = service.edits().insert(body={}, packageName=package_name)
    result = edit_request.execute()
    edit_id = result['id']

    apk_response = service.edits().apks().upload(
        editId=edit_id,
        packageName=package_name,
        media_body=apk_file).execute()

    print ('Version code {} has been uploaded'.format(apk_response['versionCode']))

    track_response = service.edits().tracks().update(
        editId=edit_id,
        track=TRACK,
        packageName=package_name,
        body={u'releases': [{
            u'name': version,
            u'versionCodes': [apk_response['versionCode']],
            u'status': u'completed',
        }]}).execute()

    print ('Track {} is set for release(s) {}' .format (
        track_response['track'], str(track_response['releases'])))

    commit_request = service.edits().commit(
        editId=edit_id, packageName=package_name).execute()

    print ('Edit "{}" has been committed'.format(commit_request['id']))

  except client.AccessTokenRefreshError:
    print ('The credentials have been revoked or expired, please re-run the '
           'application to re-authorize')

if __name__ == '__main__':
  main()

Antes de poder ejecutar este código deberás instalar algunas librerías (o ponerlas en el Dockerfile)

apt-get update -y
apt-get install python3 -y
apt-get install python3-pip -y
pip3 install google-api-python-client
pip3 install --upgrade oauth2client

Y después crear un archivo pc-api.json con este contenido (que luego os explico como conseguir):

{
  "type": "service_account",
  "project_id": "<project-id>",
  "private_key_id": "<private-key-id>",
  "private_key": "-----BEGIN PRIVATE KEY-----...\n-----END PRIVATE KEY-----\n",
  "client_email": "<service-account>",
  "client_id": "<client-id>",
  "auth_uri": "https://accounts.google.com/o/oauth2/auth",
  "token_uri": "https://oauth2.googleapis.com/token",
  "auth_provider_x509_cert_url": "https://www.googleapis.com/oauth2/v1/certs",
  "client_x509_cert_url": "https://www.googleapis.com/robot/v1/metadata/x509/<service-account>"
}

Y ya, por último, solo nos quedaría ejecutar el comando con estos parámetros:

upload_apks.py com.paquete.app apk/app-release.apk res/pc-api.json ${VERSION}

Y ahora la parte más pesada… Los datos a rellenar en pc-api.json, para ello deberás configurar un proyecto API en la consola cloud de Google y crear una cuenta de servicio… Este no es un proceso inmediato, pero hay buenas instrucciones en la página de google.

Luego hay que ir a la sección de la Google Play Console al apartado Acceso a API, donde deberás vincular el proyecto que acabas de crear y crear las cuentas de servicio necesarias.

Para después en la sección de Usuarios y permisos dar permisos a la cuenta de servicio que acabamos de crear, al menos estos:

El tema de extraer la clave privada y eso ya os lo dejo para después por si alguien tiene curiosidad…

ACTUALIZACIÓN 4/01/2022

Como ahora Google solo deja subir bundles (.aab) dejo aquí el código modificado para poder hacerlo (según el tipo de archivo que elijamos):

#!/usr/bin/env python3
#
# Copyright 2014 Marta Rodriguez.
# Modified by Jose Antonio Espinosa (2021-2022)
#
# Licensed under the Apache License, Version 2.0 (the 'License");
# you may not use this file except in compliance with the License.
# You may obtain a copy of the License at
#
#      http://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS,
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
# See the License for the specific language governing permissions and
# limitations under the License.

"""Uploads an apk/aab to the alpha track."""

import argparse

from googleapiclient import discovery
import httplib2
from oauth2client.service_account import ServiceAccountCredentials
from oauth2client import client
import os.path
import mimetypes

mimetypes.add_type("application/octet-stream", ".apk")
mimetypes.add_type("application/octet-stream", ".aab")

TRACK = 'alpha'  # Can be 'alpha', beta', 'production' or 'rollout'
SERVICE_ACCOUNT_EMAIL = (
    'ENTER_YOUR_SERVICE_ACCOUNT_EMAIL_HERE@developer.gserviceaccount.com')

# Declare command-line flags.
argparser = argparse.ArgumentParser(add_help=False)
argparser.add_argument('package_name',
                       help='The package name. Example: com.android.sample')
argparser.add_argument('apk_file',
                       nargs='?',
                       default='test.apk',
                       help='The path to the APK file to upload.')
argparser.add_argument('key_file',
                       nargs='?',
                       default='key.json',
                       help='key in json format for service account')
argparser.add_argument('version',
                       nargs='?',
                       default='New version',
                       help='Version name')

def main():
  # Process flags and read their values.
  flags = argparser.parse_args()

  package_name = flags.package_name
  apk_file = flags.apk_file
  key_file = flags.key_file
  version = flags.version
  extension = os.path.splitext(apk_file)[1]
  
  # Create an httplib2.Http object to handle our HTTP requests and authorize it
  # with the Credentials. Note that the first parameter, service_account_name,
  # is the Email address created for the Service account. It must be the email
  # address associated with the key that was created.
  credentials = ServiceAccountCredentials.from_json_keyfile_name(
      key_file,
      scopes='https://www.googleapis.com/auth/androidpublisher')
  http = httplib2.Http()
  http = credentials.authorize(http)

  service = discovery.build('androidpublisher', 'v3', http=http)

  try:
    edit_request = service.edits().insert(body={}, packageName=package_name)
    result = edit_request.execute()
    edit_id = result['id']

    if extension == '.apk':
        apk_response = service.edits().apks().upload(
            editId=edit_id,
            packageName=package_name,
            media_body=apk_file).execute()
    else:
        apk_response = service.edits().bundles().upload(
            editId=edit_id,
            packageName=package_name,
            media_body=apk_file).execute()

    print ('Version code {} has been uploaded'.format(apk_response['versionCode']))

    track_response = service.edits().tracks().update(
        editId=edit_id,
        track=TRACK,
        packageName=package_name,
        body={u'releases': [{
            u'name': version,
            u'versionCodes': [apk_response['versionCode']],
            u'status': u'completed',
        }]}).execute()

    print ('Track {} is set for release(s) {}' .format (
        track_response['track'], str(track_response['releases'])))

    commit_request = service.edits().commit(
        editId=edit_id, packageName=package_name).execute()

    print ('Edit "{}" has been committed'.format(commit_request['id']))

  except client.AccessTokenRefreshError:
    print ('The credentials have been revoked or expired, please re-run the '
           'application to re-authorize')

if __name__ == '__main__':
  main()