Archivo de la categoría: Personal

Entradas y comentarios relativos a mi mismo (qué egocentrico)

El desarrollador como impedimento de Scrum

No hace mucho tiempo que hemos empezado a utilizar Scrum como framework para los desarrollos que hacemos en el trabajo. En este corto periodo de tiempo he visto mucha información sobre los problemas en las grandes empresas en la adopción de Scrum (renombrado de roles, «flexibilización» de Scrum, etc.). No voy a entrar en detalles en esto porque ya hay mucho.

Un problema que he visto es que no sólo la empresa puede ser un obstáculo para la adopción de Scrum (y cualquier sistema ágil), sino que los propios desarrolladores pueden ser un obstáculo.

En las metodologías clásicas, lo desarrolladores suelen ser tratados como meros obreros que ponen ladrillos.  Concretamente, los desarrolladores suelen recibir instrucciones muy precisas de lo que deben hacer, sin posibilidad de intervención de ningún tipo. Con las metodologías ágiles, esto cambia y los programadores pasan a formar parte del proceso creativo. Este cambio de paradigma puede hacer que mucho programadores (especialmente lo que lleven más tiempo) se sientan incómodos ya que ahora tienen que hacer más funciones. Éstos desarrolladores, si no quieren adaptarse, pueden convertirse en un impedimento importante en la estrategia de paso a un modelo ágil.

Y tú, ¿has tenido algún problema similar?

Como hacer que tu código sea legible

Reconozco que no soy el mejor programador del mundo, pero intento mejorar cada día. Puede sonar tonto, pero una de las mayores complicaciones del trabajo de un programador es conseguir que el código que escribes un día sea entendible por otras personas !y nosotros mismos! en el futuro.

Casi todo lo que voy a contar a continuación lo he aprendido a partir de diversas lecturas y por propia experiencia.

Algunos de los consejos más útiles que creo que son importantes tener en cuenta son:

Utiliza el inglés al programar

Puede resultar extraño para algunos que dominando un idioma (español, portugués, francés, etc.) tengan que programar en inglés. El motivo es sencillo, la mayor parte de la documentación en nuestro sector está en inglés por lo que acabamos mezclando idiomas. ¿A quién no le ha pasado tener funciones llamadas setPeso o getNombre?

Por otra parte, el inglés permite abrirnos puertas en dos sentidos:

  • Para empezar como programadores que dominemos el inglés podremos acceder a más puestos de trabajo. La globalización no es sólo para las empresas; nosotros también podemos aprovecharnos de ella.
  • Podemos contratar programadores extranjeros que no tendrán problemas al leer el código.

Utiliza normas de codificación

Esto en algunas metodologías se llama gestión de configuración del software. También se puede encontrar como convención de codificación (code convention) o guías de estilo. La idea es tener una serie de normas que indica cómo debe ser la nomenclatura de codificación y tabulación para que todo el desarrollo sea consistente. Con esto conseguimos un programa más homogéneo y fácil de entender.

Tampoco es necesario inventarse una propia porque ya existen muchas. A modo de ejemplo:

Elige bien los nombre

La verdad es que el tema de los nombres es uno de los más complejos. Sobre todo para funciones y clases. Por norma los nombres de métodos, funciones, clases, etc. deben ser descriptivos y breves. Por ejemplo, un nombre como ApplicationModelAbstractObjectFactory quizá sea un poco largo, pero parece descriptivo. Igualmente, algo como EntraSola (caso real) es muy breve, pero no dice nada; no es posible determinar realmente su funcionalidad (además, puede inducir a tener pensamientos impuros).

Utiliza comentarios

Este punto es bastante controvertido porque mucho programadores piensan eso de “el código bien escrito se entiende solo”. Y es verdad. El problema es cuando el código no hace lo que toca.

No hay que llenar el código de comentarios, deben ser lo mínimo posible y sólo para cosas que claramente lo necesiten. Esto suele ser para aquellas construcciones que sean muy abstractas y que cueste mas comprender.

Se organizado

Otro punto que quizá no sea obvio, pero es cierto que tener bien organizado el código ayuda mucho a su legibilidad. Es más fácil entender una función que está dividida en partes (preparación de datos, realización de acciones, generación de resultado) que otra en la que se vayan mezclando todas estas tareas.

Refactoriza

Por mucho que nos esforcemos en que nuestro código sea claro y legible, con el tiempo acabará por convertirse todo en algo caótico. Es normal, porque conforme evoluciona un software se añaden nuevas funcionalidades para las que no estaba inicialmente pensado.

Para evitar esto hay que hacer ciclos de refactorización que mantengan el código limpio y optimizado.

Conclusiones

Está claro que una parte importante para evitar la deuda técnica reside en la calidad del código un código más claro facilita el mantenimiento al poder ser entendido fácilmente (ojo, que a parte de esto es necesario un buen diseño del mismo). El uso de unas normas que permitan que éste sea entendible ayudan mucho para evitar este problema.

Finalmente me gustaría comentar que este artículo es meramente introductorio y faltan muchas cosas que contar. Estoy más que seguro que habrá discrepancias con algunas cosas; si es así, te animo a que dejes un comentario.

Bibliografía

La mayor parte de lo que he expuesto aquí procede del libro The Art of Readable Code de O’Relly.

Errata

  • 2017-02-01: Corrijo la parte de la deuda técnica a sugerencia de Fioddor.

Perezosidad

Algo que me ha sorprendido mucho de haskell y, que aún me cuesta mucho lidiar con ello, es el hecho de que sea perezoso.

¿Y eso qué significa?

Significa que no va a ejecutar las cosas sin más, sino que se esperará hasta que no le quede más remedio.

Por ejemplo, si tenemos algo como esto:

Como se puede ver, se “crea” una lista de infinitos elementos que empiezan en 1 (intinite_list). Como no accedemos a ningún elemento, el compilador en realidad no crea nada en memoria.

Luego indicamos que queremos elevar todos los elementos al cuadra para después quedarnos con aquellos que no son múltiplos de dos ni de tres. Eso lo almacenamos en values. En haskell esto significa que values representa esa operación, no que contenga dichos valores, así que aquí tampoco ha hecho nada: no ha elevado los infinitos elementos al cuadrado ni ha filtrado después.

Lo último que hacemos es un take 10. En este momento (si utilizamos ghci), en este momento intenta mostrar los 10 primeros elementos, lo que fuerza a hacer todo lo anterior. ¡Pero sólo lo hace sobre los 10 primeros! Ni elevamos la lista entera al cuadro, ni comprobamos los infinitos elementos. Sólo vamos a hacer esto las veces justas.

Esto lo hace todo el compilador por su cuenta.

¿A dónde quieres ir a parar?

Pues estaba hace poco mirando documentación de Rust y me he encontrado con algo muy parecido:

Básicamente hace lo miso y me sorprendió mucho porque Rust no es un lenguaje que haga evaluación perezosa.

¿Entonces cómo lo hace?

Pues simulando la evaluación perezosa. Para ello lo que hace es jugar con iteradores personalizados. Cada iterador tiene información de qué es lo que va a hacer cuando se llame a su función next. Así que cuando llamamos a map lo que hace es crear en memoria la información necesaria para hacer la operación, pero no la ejecuta. Lo mismo sucede con los filtros. Cuando llamamos al next de iterador resultante, este ejecuta el next del iterador que contiene y luego comprueba o ejecuta la condición que tenga definida.

Conclusión

Sinceramente me ha encantado ver esta aproximación. Es una modo fantástico de lidiar con el problema de infinito de un modo sencillo. Esto permite tratar muchas cosas como iteradores que, aún dando listas potencialmente infinitas, no tengan un gran impacto en rendimiento (o sí, todo dependen de como esté diseñado).

Si quieres saber más sobre evaluación perezosa quizá te interese ver la entrada en Wikipedia.

Aprendiendo haskell

Ya hace unos meses que, con tiempo que dispongo, estoy aprendiendo haskell. El motivo principal es que quería empezar con un lenguaje que fuera completamente distinto a los que ya conozco.

Confieso que de momento me parece todo un galimatías. Si bien llego a resolver algunos problemas sencillos, aún me pierdo con cosas medianamente complejas.

Además, para ir aprendiendo e ir estrujándome los sesos utilizo codewars para ir resolviendo ejercicios. Creo que es un buen modo para ir tomando contacto con el lenguaje.

¿Qué me aporta haskell?

La verdad es que no lo estoy estudiando porque sí. El objetivo es poder aprender nuevos mecanismos para afrontar los problemas. Haskell te obliga a afrontarlos desde una perspectiva completamente diferente a lo que es habitual en los lenguajes imperativos. Con ello espero que a futuro pueda incorporar nuevas formas para resolver problemas a mi día a día (siempre que valgan la pena).

¿Por qué haskell?

Porque al ser un lenguaje funcional puro me obliga a desconectar totalmente de lo que ya sé. Hay otros lenguajes funcionales, pero no llegan a la pureza de haskell¹ lo que me podría permitir desviarme de la intención de aprender programación funcional.

¿Qué haré con él?

Cuando tenga más claro como funciona y no me pierda tanto me pondré con yesod, un framework para desarrollo web. Creo que será toda una experiencia.

¿Y después?

Una vez que ya tenga haskell dominado espero poder ponerme con Rust. La verdad es que de un tiempo a esta parte ando muy desencantado con C. Cada día me parece peor lenguaje de programación, pero eso ya será otro artículo.

Notas

  1. Probablemente haya más lenguajes funcionales puros, pero haskell es de los que tiene la comunidad más amplia y, por tanto, en la que es más fácil encontrar documentación.

La necesidad de invertir en herramientas

Supongo que de una vez os habrá  pasado que ante ciertas tareas (tanto de desarrollo como de administración) repetís una y otra vez las mismas acciones o el mismo código. Otras veces, simplemente os encontráis que hay cosas que son fáciles de automatizar, pero no se hace (por ejemplo, rellenar cierto tipo de fichero en donde hay patrones muy comunes).

En este punto surge un gran problema: no se quiere automatizar/desarrollar herramientas que faciliten dicha tarea. Sí, suena extraño y contraintuitivo, pero es así. Las razones pueden ser muchas:

  • Sería otra herramienta a mantener y no hay recursos para ello.
  • Si el que hace la herramienta se va quién lo va a mantener.
  • Todo trabajo que no sea directamente la tarea asignada es tirar el dinero.
  • No lo hacemos porque no nos lo van a agradecer (sí, no siempre es cosa de la empresa no hacerlo).

Seguro que hay más motivos, pero los anteriores los he oído más de una vez.

Es muy importante tener en cuenta que todo el tiempo que se utilice en automatizar (o simplificar) este tipo de tareas debe ser considerado inversión. Y es así porque se pueden llegar a ahorrar muchas horas de trabajo (pude hablarse, en algunos casos, de hasta cientos de horas anuales) y, por tanto, el retorno de la inversión será muy importante.

Como siempre, hay que ir con cuidado: para una tarea que se hace para un proyecto concreto que sabemos que no durará más de X tiempo puede que no compense la automatización. Por tanto hay que estudiar cada caso. Pero lo que está claro es que es necesario tener esto en cuenta.

En mi caso concreto, que estoy en desarrollo, veo como poco a poco se mejora el proceso de creación de software. Por una parte podemos escribir código menos propenso a errores, y, por otra parte, tenemos más tiempo para realizar las pruebas y ofrecer un mejor producto.

Trabajos pendientes y futuros

Bueno, hay que ir dando continuidad al blog. Para empezar, tengo desde hace más de un año la segunda parte del artículo de creación de paquetes… ¡Vergüenza me da! Tengo que revisarlo bien antes de publicarlo y ponerme con la tercera parte.

Por otra parte, estoy tratando de retomar el mundo del desarrollo web. Vuelvo a practicar con Grails. En un futuro me gustaría ponerme con nodejs.

Y si dicen que en la vida hay que escribir un libro yo me conformo con poder hacer mi propio lenguaje de programación.

Finalmente, tengo que echarle un ojo al tema de la nueva basura hecha por el gobierno y ver si lo que dicen en Kriptópolis es factible.

Concurso de C “a pelo”

Recientemente surgió en una newsletter de O’Reilly un concurso que me pareció bastante curioso. Las bases eran las siguientes:

It seems like a new language is spawned every day, but the old tried-and-true warriors of the code world continue to soldier on. This week, the specification for C++ version 14 was frozen, and it includes such features as enhanced lambda expressions (because all the cool languages are doing it). In honor of this momentous event, we’re running a little contest to test your chops with the bare C. Sure, anyone can create awesome code using all the libraries that modern operating systems come with, but what can you do close to the metal?

Your challenge is to create a nontrivially useful application that will compile on a Linux system using the following command:

 gcc -nostdlib -o sample sample.c startstub.S

startstub.S is an i386 assembler file that can call main() without the standard libraries and can be downloaded here. You need to have a function main defined as “int main()” that can return a value, which will end up in $?. Only C is allowed, no assembler or other funny business. Entries will be judged on two criteria: binary size and functionality of the program. For reference, a program that does nothing weighs in at 1502 bytes.

Básicamente dice que hay que hacer un programa en C, que no va a poder enlazar con biblioteca de funciones alguna (no hay libc) y que no se puede hacer uso de ensamblador. Esto último es importante, porque con esta restricción se pierde la capacidad de hacer llamadas al sistema: no se puede reservar memoria con malloc, ni leer ni escribir en disco, etc. Eso sí, el programa debe tener alguna utilidad y te dicen que puede devolver un valor que será podrá ser consultado con $? (variable de la shell con el resultado del último programa ejecutado). Eso sí, el startstub.S que suministran no permite dicho uso (¿despiste quizá?).

Estas premisas tan restrictivas me animaron a tratar de crear algo para el concurso. Tras varias ideas descartadas decidí hacer una aplicación que devolviese la posición de una palabra en una lista de palabras (no parece muy útil) y que con una opción permitiese devolver la palabra de la lista más parecida a la buscada (puede resultar algo más útil).

El problema es que con lo suministrado por la gente de O’Reilly, la función main no recibe argumentos. Así que no tenemos un mecanismo sencillo para comprobar los parámetros.

La solución al problema anterior es tener en cuenta que Linux, cuando ejecuta un programa y pasa le pasa el control deja en la cima de la pila argc, luego argv y después env. Como la función _start suministrada no mueve los punteros de la pila, main tendrá esos mismos datos. Así que sólo hay que buscar un mecanismo para obtener un puntero a la cima de la pila.

En la arquitectura i386, los argumentos de las funciones se pasan por pila. Así, si tenemos una función que sólo acepta un parámetro, en el momento en que entramos en la función nos encontraremos esto en la cima de la pila:

0x000000 Dirección de Retorno
0x000004 Parámetro

Por tanto, la dirección de memoria del primer parámetro será una posición en la pila. En este caso sabemos que se correspondería con argc.

El problema es que en las arquitecturas de 64 bits, no se comporta de este modo: los 6 primeros parámetros son registros de procesador. En este caso, si es una arquitectura de este tipo, creamos una función que acepta 7 parámetros. Los seis primeros que serán registros (y los ignoramos) y el séptimo que ya se encuentra en la pila.

El resto del programa ya no tiene más misterios y lo podéis ver a continuación:

Curiosidades de C++

Ayer trasteando con el compilador de C++ descubrí una cosa nueva sobre cómo funciona por dentro.

Si compilamos el siguiente programa y lo ejecutamos veremos que falla con un bonito SIGSEGV:

El motivo es que, para empezar, hay dos estructuras que son diferentes pero se llaman igual. El constructor de dichas estructuras no deja de ser una función, por lo que en cada fichero objeto se generará una función para construir la estructura. Sí, la función se llamará igual en ambos objetos.

Cuando enlazamos se queda con la primera función que encuentre (en este caso con la de a.cpp). Así que cuando desde run_example_b se trata de instanciar la estructura lo hace con el constructor de a.cpp.

Hasta ayer por la tarde no caí en porque esto funciona así, pero es bastante lógico. Hay muchas clases en las bibliotecas estándar (y de terceros) cuyos constructores están implementados en la propia cabecera. Esto significa que cada fuente que tengamos tendrá su propia implementación del constructor y luego, al enlazar, se reduce a sólo uno.

Si el ejemplo anterior lo compilamos todo con ‘-O2’, el constructor lo convierte en inline para optimizar y funciona correctamente.

Nota mental: hay que mejorar los nombres de funciones in clases según su utilidad y contexto (debe ser más semántico).

Heartbeat

Pensabais que me había olvidado del blog, que me había vendido a las redes sociales mass-media, pues no. ¡Ojalá! Simplemente que no ando ni bien de tiempo y que el poco que tengo no lo organizo bien.

Desde la última vez que escribí han pasado muchas cosas, tanto en lo laboral como lo personal, y, lo más importante, tengo cosas técnicas para contar.

La semana que viene espero publicar un par de cosillas sobre creación de repositorios debian (no es que sepa mucho, pero me ha tocado hace poco hacer alguna cosilla sobre ésto).