Usando Atom para Node.js

Node es una plataforma que me gusta para hacer pruebas de concepto, porque con poco código es fácil hacer muchas cosas.

Buscando un editor he empezado a utilizar Atom. Viniendo como vengo de Java, estoy familiarizado con entornos como Eclipse o IDEA de JetBrains, pero me apetecía practicar con algo mas ligero. Vim es otro editor que manejo bien y me gusta, pero no lo veo para esto. Me encanta para editar rápidamente sobre la línea de comando, pero no para desarrollar de forma continua.

Atom es sencillo, es bonito, es abierto, y tiene una comunidad muy rica detrás. No es tan rápido como Sublime y Visual Studio Code, pero me da igual.

En un sistema Linux como Ubuntu la instalación es la habitual con su gestor de paquetes. En la sección Atom Basics del manual de Atom se describen los comandos básicos para desenvolverse en el editor, en caso de duda un “Ctrl+Shift+P” te permite encontrar lo que necesites.

Una de las características de Atom es que es muy personalizable, existe multitud de extensiones disponibles para adaptarlo a tus necesidades. La instalación de estos paquetes se puede hacer con un “apm install <nombre-de-paquete>“.

Las que siguen son las extensiones que he encontrado mas útiles para desarrollar programas en servidor. He ignorado las que tienen que ver con la parte de presentación como autoclose-html, pigment o color-picker.

Las primeras en mi lista son atom-ternjs, node-debugger y script. Para mí son las mas necesarias, y las primeras que he instalado.

atom-ternjs

  • Acostumbrado a trabajar en IDEs como Eclipse algo que busco de forma natural es una utilidad de autocompletado de código y de chequeo de sintaxis. Esto es lo que encuentras en esta extensión. Como indica su documentación, si quieres usarla en tu proyecto, debes añadirle un fichero de configuración para tern donde le puedes indicar como quieres que te ayude.

node-debugger

  • Esta extensión es un depurador para Node con las funciones habituales de inserción de puntos de ruptura, ejecución paso a paso y consulta de pila de llamadas, entre otras.

script

  • Esto es una pequeña maravilla que te permite seleccionar un trozo de código y ejecutarlo en un momento. Algo como https://repl.it/ pero dentro de Atom. Ideal para prototipar una función o para probar con rapidez.

Otro grupo de extensiones que uso son las que me ayudan a editar mas rápidamente, porque visualizo mejor las cosas, o porque llego a ellas mas rápidamente: minimap, open-recent, highlight-selected, file-icons, maximize-panes, fold-lines y tool-bar.

minimap

  • Muestra a la derecha del editor una visión resumida de todo el código contenido en el fichero, permitiendo situarte con mas facilidad. Existen extensiones relacionadas con esta que permiten indicar la posición del cursor en el minimapa.

open-recent

  • En el menú de fichero muestra siempre los ficheros y carpetas que hemos abierto mas recientemente.

highlight-selected y minimap-highlight-selected

  • Al seleccionar una variable o una palabra clave, todas las ocurrencias de las mismas en el fichero aparecen resaltadas.

file-icons

  • Asocia un icono para cada extensión de fichero facilitando encontrar lo que buscas.

maximize-panes

  • Permite maximizar el panel del editor donde estás trabajando sin cerrar el resto de paneles.

fold-lines

  • Permite compactar en una línea distintos bloques de código para facilitar la lectura.

tool-bar

  • Aunque me encanta usar atajos de teclado, mi magia es limitada y necesito de una barra de herramientas como esta. Permite personalizar su contenido.

Y ahora este grupo final de plugins que veo interesantes. Puedo vivir sin ellos pero les he dado una oportunidad: linter, auto-detect-indentation y atom-beautify.

linter y linter-eslint

  • Es una extensión para corrección de código que también se integra en otros entornos de desarrollo. linter es el paquete base que soporta HTML, CSS y JavaScript. linter-eslint es una ampliación sobre el anterior específico para JavaScript y JSX. Como en el caso de tern, para usarlo en tu proyecto debes incluir un fichero de configuración eslint donde puedes detallar, por ejemplo, si se va a programar en JavaScript ES6 o con una versión anterior.

auto-detect-indentation y atom-beautify

  • El primero configura la identación del fichero basado en el contenido que ya tiene, no solo en las settings del editor. El segundo organiza el código para verlo mejor.

Y tras tanta personalización, ¿que pasa si quieres llevártela a otra máquina, quieres compartirla, o simplemente no perderla? Pues usar otra extensión: sync-settings.

syn-settings

  • Permite guardar la personalización realizada en el editor en un gist de GitHub. Hay que tener una cuenta disponible. Para hacer el backup hay que introducir en Atom el token de acceso a GitHub y el ID del gist donde vas a hacerlo. Aquí puedes encontrar la configuración descrita en este post.

En Internet hay muchas páginas mostrando conjuntos de extensiones preferidas para distintos usos. Aquí he compartido las mías.

¿Agile vs Remote?

Cuando leo sobre experiencias de desarrollo ágil en la red tengo la impresión de que mucha gente percibe el Agilismo como algo contrapuesto a tener en una organización personas y equipos trabajando en remoto. ¿Hasta qué punto el desarrollo ágil es compatible con tener equipos distribuidos?

El acento en el agilismo está puesto en la cercanía. Se prioriza la interacción directa entre las personas sobre los procesos y las herramientas. El cliente, el negocio, participa del proceso de desarrollo, no se limita a negociar un contrato.

Continue reading ¿Agile vs Remote?

La comunicación en los equipos colaborativos

Continuando con Software for Your Head, he leido algunos aspectos sobre comunicación entre los miembros de un equipo que quiero compartir con vosotros.

En este libro se concretan en cuatro apartados básicos los comportamientos que permiten a cualquier equipo colaborativo mejorar sus resultados. En cierta manera los primeros sirven de base a los siguientes. Los apartados son:

  • “Checkin”, relativo a la presencia, a la participación real de los miembros de un equipo.
  • “Decider”, relativo al proceso de toma de decisión.
  • “Aligment”, facilitador de la toma de decisiones.
  • “Shared Vision”, con los comportamientos que logran una visión compartida de los miembros del equipo: el objetivo final.

En los cuatro casos los comportamientos están “codificados” haciendo uso de protocolos, patrones y definiciones. Ese es el software para tu cabeza del que habla el título del libro. Por ejemplo los aspectos de comunicación son presentados como un patrón dentro del apartado de “Checkin”.

Jim y Michele MCarthy explican que la presencia, la integridad para con uno y con el grupo está en la base de la calidad en la comunicación. Sin presencia real hay represión de emociones, rechazo a la visión compartida, y esto lleva a que la conexión entre las personas sea de baja calidad y la información transmitida pobre o nula. Acabamos perdiendo el tiempo.

La presencia es el prerequisito de una buena comunicación, una vez que se establece “la conexión”. Sin embargo esta no llega gratis.

Como dicen los autores: “Most people spend their working hours in the default human-human interface environment, created by no one, but
affected by everyone.” El mecanismo con el que se trabaja es de lo mas rudimentario, y en el lo mas importante es no sentirnos molestos o incómodos. La gente “conecta” solo por casualidad.

Lo que proponen es sustituir esa casualidad por algo elaborado. La mayoría de los equipos no logran “conectar” porque no realizan las tareas previas que garantizan una buena comunicación. No comprueban “el estado de la línea” para ver las velocidades a las que es posible comunicarse ¿en que estado emocional está el otro? ¿su contexto es el mismo que el nuestro o lo que le vamos a decir le va a sonar a chino?.

Tras empezar la conversación la calidad no se mantiene sola, hay que cuidarla activamente, tener una comunicación consciente. La comunicación en un equipo debe partir de un acuerdo para establecer comunicación de calidad. Se debe monitorizar el estado de esta mientras se realiza, para poner remedio en caso de que se esté perdiendo.

En algún lugar del libro nos acaban diciendo “ni te molestes en comunicarte si previamente no has establecido una conexión”. ¿Quien no ha sentido la frustración de creer que se le ha entendido y darse cuenta al cabo de unos días que no ha sido así? Eso entre compañeros del mismo área, imaginad en un equipo multidisciplinar o multicultural.

Un libro prometedor “Software for your head”

Estoy leyendo un libro que he encontrado a través de este post. Su título: “Software for your head. Creating and maintaining a shared vision” y su versión electrónica se puede descargar de forma gratuita.

Me atrajo porque ayuda a clarificar las características esenciales que están detrás de los grandes equipos, mas allá de sistemas o modelos mas o menos elaborados o mas o menos de moda. Además sus resultados se apoyan en la observación de multitud de talleres de equipo realizados por los autores. El libro describe estas características como una serie de protocolos, patrones y otros elementos que seguidos permiten generar equipos que viven para crear productos sobresalientes.

La primera parte está dedicada al requisito básico para abandonar la mediocridad: los miembros del equipo deben estar presentes. Cuando se les ve reunidos no son máscaras que no expresan con sinceridad lo que sienten y piensan, su tiempo es precioso y saben lo que les gusta. Un equipo excelente tiene personas que actúan con integridad hacia si mismos y hacia los demás. Ese es el camino.

Hay un parrafo en el libro donde traducido viene a decir: “Es falso pensar que actuar profesionalmente es actuar de alguna manera sin emociones, o pensar que lo personal y lo profesional son aspectos separados, donde uno es uno mismo solo en el ámbito personal”. En una cadena de montaje o en una organización jerárquica produciendo productos indiferenciados, podía tener sentido que las personas estuvieran desconectadas, ausentes del trabajo. Hoy en día esto no tiene sentido. Menos cuanto mas diferenciado es el producto que se pretende crear.

Los autores llegan a hablar de que el producto es un reflejo del equipo, una idea muy potente.

La presencia está muy relacionada con la conciencia de lo que se hace, con el conocimiento de lo que se quiere. De ahí que la presencia en el trabajo vaya pareja con la eficiencia en el trabajo, nuestro tiempo es valioso. Lo único con derecho a captar nuestra atención son los resultados.

En otro parrafo comenta: “La especificaciones, los planes o las presentaciones no suelen tener que ver con el resultado. De igual manera las reuniones, las revisiones y la administración no son el resultado. Aunque estas cosas pueden contribuir a lograrlo, a menudo evolucionan hasta convertirse en tareas que se justifican por si mismas”. Si te ves realizando tareas no relacionadas con la creación del producto o no contribuyendo directamente a aquellas que lo producen, probablemente estas haciendo algo mal. Seguro que tu presencia real y comprometida se necesita en alguna parte.

Creo que este libro va a merecer una lectura completa.

El mito del desarrollador solitario

Acabo de leer esta entrada en O’Really Radar sobre los mitos de la programación, en concreto sobre el mito del desarrollador solitario. En este post se termina afirmando que, al contrario de lo que afirma el mito, ningún software de entidad surge de la mente de un único programador. Es similar a ese otro clásico, el del científico solitario, ese genio, ese héroe que logra de la nada una nueva teoría. ¡Qué daño hacen los mitos!

En el desarrollo de software, cualquier cosa que vaya más allá de un prototipo necesita de un equipo para crearse. El artículo nos recuerda el ejemplo de Linus Torvalds, que al contrario de lo que cuenta la leyenda, es falso que sea la persona que desarrolló Linux. Lo que hizo fue crear un prototipo del núcleo de este sistema operativo. Los siguientes 19 o 20 años los empleó en coordinar el trabajo de los voluntarios que escribieron el 99% restante del código.

Ya se sabe lo acertado que estuvo hace unos siglos ese egocéntrico llamado Isaac Newton cuando dijo aquello de que “Si he visto un poco más lejos es porque me he elevado a hombros de gigantes”.

Programar es una habilidad básica

Programar es construir algo diciéndole a una máquina de forma precisa qué es lo que quieres, con unas herramientas que nos obligan a cumplir unas reglas muy claras. Esto no es algo que hagan solo los programadores. Aunque pueda resultar chocante, cualquiera que haya modificado fotos con photoshop ha programado, también cualquiera que haya creado páginas web con editores sencillos, que haya metido una animación en una presentación o que haya creado un video casero definiendo tiempos y transiciones.

En programación se suele hablar de programación imperativa y de programación declarativa. En el primer tipo se usan lenguajes con los que se establecen los pasos necesarios para llevar a cabo una tarea. En la programación declarativa se define lo que se va a crear haciendo uso de definiciones, de condiciones y otras características. El primero es útil en la definición de un trabajo a realizar, el segundo en la definición de una entidad que va a cumplir una función. Cuando pensamos en programación solemos pensar en programación imperativa. Pero cuando trabajamos con una hoja de cálculo o creamos una página web hacemos uso de programación declarativa.

Los ordenadores personales, móviles, tabletas y todo lo que está por venir nos ofrecen cada vez mas posibilidades, multiplican nuestra capacidad de hacer cosas. Pasado mañana se valorará a la gente aún mas que hoy en día por su capacidad para manejar herramientas. ¿Pero que es en realidad manejar una herramienta? Usar una herramienta de forma eficaz es comunicarnos con ella haciendo uso de un lenguaje. Pasado mañana se valorará a la gente por su habilidad para hablar y aprender muchos lenguajes, muchos idiomas. De esto es de lo que hablamos cuando hablamos de alfabetismo digital.

Profesionales excelentes, no prima donnas

Uno de los principios contenidos en el manifiesto por el desarrollo ágil de software, publicado en 2001, dice lo siguiente:

“Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.”

En el desarrollo ágil el acento está puesto sobre el individuo, sobre el experto en algo. Con buen criterio afirma que hay que confiar en su capacidad para aportar soluciones, hay que despejarle el camino en caso de que haya obstáculos que dificulten la consecución de su tarea, hay que darle inspiración en vez de darle instrucciones.

Se nos dice que la empresa ideal no es jerárquica, es cooperativa, es rápida. Con una gestión ligera y diferente y un grupo de expertos que se autoorganizan. Para llegar a ella la organización debe cambiar, los “jefes” deben cambiar…  Pero también son necesarios individuos, expertos con las cualidades adecuadas para trabajar de esta manera.

Un equipo ágil que ofrezca resultados de calidad también exige tener personas con unos valores y cualidades particulares. Se cede el poder al experto, pero de nada nos valdrá si olvida que trabaja por un objetivo común, poco aportará si no es capaz de escuchar, si no busca activamente integrar las ideas de los demás en sus ideas.

Cada vez mas, los problemas a los que nos enfrentamos son esos que llaman “wicked problems“, problemas perversos. Complejos, sin procedimientos claros para resolverlos y por supuesto sin posibilidad de automatizarlos. Para aportar soluciones hacen falta muchas voces, pero también muchos oidos.

No son prima donnas lo que necesitan los equipos sino profesionales excelentes, gente que no solo sirva para sacar las castañas del fuego sino que ayuden a crear equipos brillantes y con futuro.