Windows Forms es una tecnología que permite crear aplicaciones gráficas para escritorio en Windows. Ofrece capacidades para definir visualmente todo tipo de ventanas y controles dentro de éstas, y además facilita mucho la creación de interfaces orientadas al manejo de datos gracias a sus capacidades de enlace bidireccional a datos.

Apareció con la primera versión de .NET, hace casi 20 años, y enseguida se convirtió en la principal tecnología para crear aplicaciones de escritorio para Windows. En la actualidad es una tecnología madura y estable, con grandes capacidades para desarrollo rápido gracias a su diseñador visual integrado en Visual Studio.

Esta tecnología ha encontrado una segunda vida gracias a su integración en la plataforma .NET Core. En el momento de escribir esto se encuentra todavía en fase "Preview" y le están puliendo detalles (sobre todo al diseñador), pero es perfectamente capaz de crear aplicaciones listas para ser utilizadas en entornos reales. Ya te hemos hablado de ella con antelación.

Hoy te enseñamos cómo utilizar el mítico designer o diseñador de Windows Forms en Visual Studio 2019., incluyendo un vídeo que te lo muestra. ¿Lo vemos?

Preparación

Para empezar a crear aplicaciones Windows Forms con .NET Core 3 y disfrutar de su diseñador, necesitaremos seguir una serie de pasos.

En el momento de escribir esto, solo está accesible desde Visual Studio 2019 Preview, a partir de su versión 16.1 o superior. Una vez descargada e instalada esta versión en nuestro equipo, necesitaremos configurar una de las opciones que vienen como preview o versión preliminar.

Si seguimos la ruta del menú Tools > Options > Environment > Preview Features (o, si tienes el IDE en castellano, la ruta es Herramientas > Opciones > Entorno y Características en versión preliminar), encontraremos una casilla de verificación llamada Use the preview Windows Forms designer for .NET Core apps (lo que sería Usar el diseñador de Windows Forms en versión preliminar para aplicaciones .NET Core). Actívala, ¡y la magia comienza!

Esta casilla tiene un requisito: tienes que reiniciar Visual Studio para empezar a disfrutar de las ventajas del diseñador.

Creando tu aplicación

Gracias al diseñador, con tan solo unos cuantos movimientos de ratón, es decir, seleccionando y arrastrando controles al formulario que estás creando, puedes crear interfaces para tu nueva aplicación de escritorio.

Pero no olvides el hecho de que este diseñador sigue siendo una preview: si conocías Windows Forms de antes notarás que faltan algunos controles por añadir, el proceso de construcción puede ser lento y se nota que la versión aún no es lo suficiente madura como para publicarla como una herramienta estable dentro de Visual Studio.

En el siguiente vídeo te muestro cómo activar el diseñador y cómo utilizar su funcionalidad básica.

[youtube:dQjm_L4mpyA]

Poco a poco vamos recuperando esta estupenda funcionalidad del diseñador de Windows Forms, y en los próximos meses la tendremos soportada con toda su funcionalidad.

WinForms fue la primera librería para crear interfaces gráficas que aprendí después de hacer muchas aplicaciones en consola con C#, así que le guardo cariño y me hace especial ilusión su regreso.

Nostalgia aparte, espero que el contenido te resulte útil, ¡un saludo!

Cuando creas una pequeña aplicación, si tienes experiencia, es fácil "tener todo el código en la cabeza". Hay pocas cosas que controlar y es menos probable meter la pata al añadir nuevas características. Sin embargo ¿qué pasa cuando retomes la aplicación dentro de unos meses? ¿Te acordarás de qué partes se verán afectadas cuando toques algo? ¿Sabrás por qué hiciste el código de una determinada manera y no de otra?

Por otro lado, si trabajas en equipo, en aplicaciones reales dentro de una empresa, el software que creáis será sin duda mucho más complejo. Aunque alguien tenga una visión global del conjunto, es casi imposible que tenga claros todas los posibles efectos que se producen al tocar cualquiera de sus partes. En este tipo de entornos, el más mínimo cambio, por insignificante que parezca, puede traer una sucesión de efectos secundarios que hagan que todo el conjunto falle. Algo tan aparentemente inocuo como cambiar un tipo de datos en un módulo puede hacer que fallen partes de la interfaz, o que varios procesos que actualizan información en segundo plano dejen de funcionar.

Debido a ello, trabajar en un sistema real sin hacer testing es como hacer malabares con motosierras: puede que sea divertido hacerlo, pero los demás lo van a ver con terror (y un poco de morbo) y si en algún momento te equivocas... Digamos que deja de ser divertido 🤦‍♂️

Por eso es tan importante incorporar procesos de prueba de código a nuestra metodología y a nuestra mentalidad de trabajo.

Y fíjate en que resaltamos la palabra "mentalidad", ya que el testing de aplicaciones no sólo implica conocer una serie de técnicas y bibliotecas, sino que debe formar parte fundamental de la manera de pensar a la hora de crear código. De hecho existe el desarrollo guiado por pruebas, en el que antes de nada se diseñan y se crean los test, y luego se construye el código alrededor de éstos.

Hace tiempo que nos lo venís demandando y que queríamos hacerlo. Nos costó, y finalmente encontramos al autor ideal para ello: Jorge Turrado, galardonado como MVP de desarrollo por Microsoft y con amplia experiencia en el tema, al que ya conocerás de sus colaboraciones en este blog.

Así que, tras varios meses de trabajo, tenemos el gusto de presentar en sociedad nuestro nuevo curso de Testing de aplicaciones .NET y .NET Core con xUnit y Moq.

En el enlace anterior puedes conocer los detalles de la formación, pero verás que, como todos los nuestros, se trata de un curso muy completo: no sólo te enseña a dominar las herramientas y técnicas necesarias en tu día a día o a abordar situaciones avanzadas y complejas, sino que también te enseña la filosofía detrás del desarrollo guiado por pruebas (TDD) o te introduce en el apasionante mundo de la integración continua. De este modo, tú y tu equipo, podréis integrar la prueba de software en vuestro proceso de desarrollo, desde la concepción al despliegue, evitando nuevos errores, regresiones a errores antiguos y, en definitiva, mejorando espectacularmente la calidad de vuestro software y la satisfacción de los clientes.

Ademas, el autor, Jorge Turrado, estará disponible durante todo el curso para contestar a las dudas que te puedan surgir sobre el material, con contacto directo con él y tiempo de respuesta máximo garantizado (nada de esperar en un foro a ver si hay suerte y alguien te ayuda).

Por supuesto, recuerda que si tu empresa está en España, el curso os puede salir sin coste alguno, gracias a la bonificación con el Estado a través de Fundae.

Así que no hay disculpa para seguir haciendo malabares con motosierras: subid de nivel vuestro desarrollo con esta formación 😉

Dedicarse profesionalmente a programar es apasionante. Pero al mismo tiempo no es una carrera fácil. Con los avances constantes de la tecnología, cada día hay más innovaciones en la industria, y la programación se convierte en una carrera de fondo apasionante para aquellos que la disfrutan.

Trabajo en una empresa de desarrollo de software y recientemente desde RRHH decidimos lanzar una encuesta con el fin de ayudar a los nuevos programadores que incorporamos en la empresa. El tema general de la encuesta era "cosas que te hubiera gustado saber cuando empezaste a programar". Para ello recurrimos a los más veteranos de nuestro equipo de programación y seleccionamos a 17 entrevistados, mayores de 35 años todos ellos.

En principio nos habíamos planteado hacerlo solo en relación con el trabajo de desarrollo en la empresa, pero finalmente abrimos la mano y la hicimos sobre la profesión en general. Algunas preguntas eran abiertas y otras de selección única o múltiple. En este artículo voy a resumir algunas de las respuestas más repetidas para algunas de las preguntas que me parecen más relevantes.

En mi opinión, esta lista de preguntas y respuestas puede ahorrarle a cualquier nuevo programador muchos dolores de cabeza y mucha energía.

Puedes consultar esta lista a medida que avances en tu trayectoria profesional como programador. Si bien algunos de estos puntos pueden no ser relevantes para ti en este momento, algún día quizá veas la sabiduría que hay en ellos.

¡Allá vamos!

1. Como programador, ¿qué importancia le das a tener títulos oficiales o incluso a tener alguna licenciatura?

De este tema en concreto ya he escrito anteriormente en el blog.

En la encuesta, la mayoría de los desarrolladores respondieron a esta pregunta indicando que en su experiencia habían trabajado con muchos programadores que no se habían licenciado en nada relacionado con las ciencias de la computación ni con la informática. Y es cierto que la programación es una de las pocas profesiones que necesitan conocimientos avanzados pero que, al mismo tiempo, puedes ejercer sin depender de un título oficial necesariamente.

Por otro lado, absolutamente todos los encuestados están de acuerdo en que la programación es una carrera intensiva en conocimientos. Todos coinciden en la importancia de tener una base sólida sobre los fundamentos básicos de programación, así como la forma de trabajar en los equipos de proyecto de desarrollo.

Fijar una base firme para tus habilidades técnicas, con una sólida comprensión de los conceptos básicos, además de escribir código funcional, te permitirá realizar buenas entrevistas técnicas y comunicarte de manera efectiva con tus compañeros de trabajo.

2. ¿Cuál es la destreza más importante para ser un buen programador en ámbito laboral?

Tras analizar todas las respuestas, los encuestados repitieron dos habilidades de forma mayoritaria: por un lado, está el grupo que opina que lo más importante es tener capacidad analítica para la resolución de problemas, y por otro están los que destacan la creatividad.

La mayoría de la gente tiene la idea preconcebida de que la programación tiene que ver con las habilidades analíticas y de resolución de problemas, y nadie puede discutir eso. Pero eso no es todo. En efecto, la programación también implica mucha creatividad. A menudo, hay muchas maneras de escribir un determinado fragmento de código. La creatividad surge y es determinante a la hora de idear maneras de implementar una idea de la manera más sencilla y eficaz posible.

3. ¿Cómo gestionas el tema de la formación continua?

Todo el mundo, incluso los programadores "de élite" con una formación extensiva, continuarán formándose en el trabajo. De hecho, la capacitación en el trabajo es una de las mayores ventajas de trabajar para las grandes empresas tecnológicas. Las empresas te pagarán cursos y seminarios "caros" para formarte en las últimas tecnologías que quieren que utilices.

Aquí la conclusión que obtenemos de la encuesta es: no se puede aprender todo lo que hay para aprender, la clave es aprender unas cuantas cosas a la perfección.

Hay cientos de lenguajes de programación por ahí. Pero también técnicas, herramientas, patrones, tecnologías... y no podemos abarcarlas todas.

Existen áreas de programación que allanan el camino para trayectorias profesionales concretas: desarrollador web front-end, desarrollador back-end, desarrollador de aplicaciones de gestión, desarrollo de aplicaciones móviles, analistas, especialista en bases de datos, etc.

Cada uno debe decidir qué tipo de desarrollador quiere ser y, a continuación, aprender todas las tecnologías y habilidades necesarias para ese puesto en particular. La mayoría de las respuestas inciden en la especialización.

4. ¿Cómo llevas el tema de trabajar en soledad delante de un ordenador tantas horas?

Las respuestas a esta pregunta fueron muy variadas ya que cada persona es un mundo. Analizando las palabras más repetidas en las respuestas, sí se aprecia que en general las empresas en muchas ocasiones tratan a los programadores como si fueran una especie de robot,

No dejes que te traten como a un robot

No te olvides de que primero eres un ser humano y después un programador. Es fácil perderse en el código cuando se empieza a programar de forma profesional. Hay días en los que no se deja el ordenador hasta que se han completado todos los hitos de un proyecto. Pero todos somos seres humanos, necesitamos reír, llorar, desestresarnos y, sobre todo, hablar con la gente. Gestionando la vida de forma que se saque el máximo provecho de la diversión y la alegría fuera del trabajo, se consigue una mayor creatividad en el trabajo como programador.

Hace unos meses escribí un artículo dedicado a este tema: cómo ser mejor programador (aparte de programando).

Habrá momentos en los que serás como un ermitaño metido en casa. Sin embargo, para ser un programador realizado, hay que buscar proactivamente una vida más allá de la pantalla del ordenador. A menudo, el éxito de una carrera profesional, depende de las personas que conoces en la vida. El networking es también esencial cuando se es programador.

La adicción a la programación es algo real. Si te gusta de verdad, en algún momento de la carrera de programación, se viven maratones de programación que duran toda la noche. Uno no quiere irse a dormir hasta que se hayan terminado los hitos planificados. El cerebro está procesando mucha información y se te va a olvidar comer, beber o incluso levantarte de tu escritorio. Eso está bien. Una vez que hayas terminado, sal a dar un paseo o vete de minivacaciones si puedes.

Tener una identidad fuera de ser un programador es esencial para evitar que uno se vuelva adicto a la programación. Cuando uno puede disfrutar de sus pasiones sin verse obligado a hacerlo, su mejor trabajo sale a la luz.

5. ¿Cuál es la mejor forma de aprender a programar?

Con esta pregunta buscamos intentar aportar luz a un aspecto crucial en la vida de cualquier desarrollador.

Todos los encuestados respondieron que la mejor forma de aprender es aplicando el conocimiento, y no memorizando.

A diferencia de la investigación, en la que se inventan y crean nuevas áreas de conocimiento, la programación, como la ingeniería, consiste en aplicar el conocimiento existente. Los libros, los artículos de investigación, los artículos en Internet y los tutoriales de aprendizaje se convierten en recursos que se utilizan con frecuencia.

Por ello, no hay necesidad de memorizar nada. Siempre se puede buscar la forma de encontrar la respuesta. La memorización es automática y natural a medida que se trabaja en más proyectos.

6. ¿Cómo gestionas el temor a no cumplir con las expectativas depositadas en ti por parte de la empresa?

La programación es una profesión a la que mucha gente "inteligente" parece inclinarse. A no ser que seas un genio, experimentarás, como muchos de mis compañeros, el síndrome del impostor todos los días.

Cuando se experimenta esa sensación a menudo, uno tiende a encontrar una manera de lidiar con ello. Para muchos de los encuestados, esto es una motivación para aprender cosas nuevas. Muchos hablan de cómo han aprendido a ponerlo en perspectiva y a contentarse con mejorar un poco cada día sin dejarse llevar por la angustia y el estrés.

Este es un tema muy común entre los programadores, y que también hemos tratado en profundidad en este blog:

Quizá tengas el síndrome del impostor sin saberlo. ¿Qué hacer para librarse de él?

7. ¿Cuán importante es la figura del mentor y la programación entre pares?

Muchos de los encuestados reconocen que cuando eran más jóvenes, a la hora de programar, les gustaba cerrar la puerta y que nadie les molestase. Preferían aprender buscando online o leyendo manuales que teniendo que preguntar a un programador sénior o sometiendo el código a una revisión por un tercero.

La verdad es que se aprende mucho más rápido si se encuentra un "compinche". Cuando programas a pares con alguien, todos los "fallos" de programación salen a la superficie: te critican el código, pero se aprende a escribir código más limpio y eficiente porque alguien más está pensando en ello. Además, se fomenta una cultura de competencia sana ya que se establecen "piques" para ver quién es capaz de optimizar más el código.

En el mundo de la empresa, cuando se trabaja en programación, casi siempre hay alguien revisando el código. Nunca se programa solo. Hay que habituarse a ello.

8. ¿Qué habilidades mentales son las más importantes para ser programador?

A la programación se acercan perfiles de todo tipo, aunque mayoritariamente los perfiles son más de ciencias que de letras. El fin de esta pregunta es intentar determinar si para los encuestados los perfiles que no son de matemáticas o ciencias puras pueden llegar a tener una trayectoria profesional trabajando como programadores.

Aquí también hay bastante unanimidad. Algo más de la mitad de los encuestados dicen que para ser un buen programador hay que tener ciertas aptitudes relacionadas con la inteligencia lógica y matemática, ya desarrolladas. Otros opinan que, aunque no se tengan desarrolladas dichas aptitudes, sí es importante tenerlas latentes, ya que a medida que se aprende a programar se pueden desarrollar.

En mi caso particular, conozco algún perfil de letras reciclado a programador, pero generalmente a base de esfuerzo y constancia.

Los encuestados otorgan más valor a la constancia que a cualquier otra aptitud. La programación es un trabajo difícil y la persistencia es clave independientemente del perfil de cada cual.

Por otro lado, y que quede claro, ser bueno en matemáticas no te convierte en programador automáticamente. Hay mucha gente que aprende matemáticas al trabajar en el sector durante un tiempo. Con el tiempo, estas personas pueden incluso entender algoritmos complejos y ponerlos en práctica sin ningún tipo de educación matemática formal. Evidentemente, si ya sabes matemáticas de antes, siempre es una gran ayuda.

Otro tema que salió mucho en las respuestas a esta pregunta es el hecho de tener una gran capacidad de aprendizaje. Un programador debería ser casi por definición un buen estudiante. A lo mejor no se empieza siendo un alumno ejemplar, pero se consigue serlo con el tiempo.

A veces, en el lugar de trabajo le piden a un programador que aprenda tres lenguajes de programación en seis meses (por decir algo). Así es el estado de la innovación tecnológica. Como programador, se tiene que aprender todos los días. Aprender es como respirar. Si uno se siente a disgusto al tener que aprender algo todos los días, se verá obligado a acostumbrarse a ello o a dejar de ser programador.

La mejor forma de abordarlo es plantear el aprendizaje como lo hacen los atletas.

9. ¿A qué cosas dedicas más tiempo en el trabajo?

Depuración de errores

La mayoría de las veces, en los proyectos de programación, hay muchas partes que son interdependientes entre sí. A menudo, uno se da cuenta de que no puede seguir adelante a menos que haya corregido un pequeño error que ha estado al acecho en el software.

Los encuestados respondieron cosas del tipo: "como programador, uno se estresará con todo el proyecto a menos que encuentre la solución a este bug..." o "te pasarás todo el día frente al ordenador buscándolo. Soñarás con el código por la noche hasta que lo encuentres..."

Si se programa en un lenguaje muy difundido, se podrán encontrar las respuestas a la mayoría de los problemas que se presentan en la red. Sin embargo, hay excepciones. A veces, nadie se ha encontrado con los problemas con los que te has topado tú. En este caso, consultar la documentación oficial y preguntar en los foros generalmente te puede orientar en la dirección correcta.

Pero en muchos de esos casos tendrás que buscarte la vida y dedicarle mucho tiempo.

10. ¿Cómo gestionas la frustración?

¿Cuántas veces se rinde un programador ante un problema que no es capaz de resolver? ¡Nunca! pero la tentación de hacerlo está presente todo el tiempo.

En mi empresa, mis compañeros programadores a veces se encuentran con problemas tan difíciles que solo piensan en dejarlo todo y cambiar de trabajo (hacemos un software complicado).

Ante esta pregunta de la gestión de la frustración, la mayoría de las respuestas giraban en torno a la constancia, la auto-motivación y el orgullo propio. Cuando se decide ser programador, la verdadera prueba de fuego es en estos momentos de máxima ansiedad. La persistencia necesaria para aprender, es también necesaria en el trabajo del día a día.

Para ser buen programador te tiene que gustar mucho tu trabajo, y tienes que tener pasión por lo que haces, además de un punto de orgullo propio, un "puntito" de ego, para sacar adelante los proyectos.

La gestión de la frustración se supera sintiendo verdadera pasión por la programación. Cuando ves a alguien que disfruta de la programación, puedes dar por sentado que será capaz de resolver el 99,9% de los problemas más complicados. Esto es lo que distingue a los mejores programadores.

11. ¿Cuándo recomendarías a un programador cambiar de empresa?

Es habitual que en el sector de la programación haya algo de rotación laboral. Los buenos desarrolladores reciben buenas ofertas de trabajo a menudo y se les tienta a cambiar de empresa con frecuencia.

Cuando empiezas y no tienes experiencia, muchas veces tienes que optar por trabajar para alguien que no te gusta mucho y eso es normal. Incluso si eres un programador poco preparado, llegará un momento en el que ciertas empresas necesiten tus servicios.

La mayoría de las respuestas de los encuestados en este punto hablan de buscar una cultura de empresa compatible con tu forma de ser.

La moraleja podría resumirse en la siguiente respuesta que copio y pego literalmente.

"Cuando te entrevisten, trata de recordar que tú también los estás entrevistando a ellos. Dependiendo de la cultura de la empresa, es posible que quieras decir "no" a una oferta razonable. Como programador, trabajarás muchas horas, porque el trabajo se va contigo a casa. Es casi crítico encontrar una cultura de empresa en la que puedas encajar."

El ser feliz conduce a trabajar mejor. Si tus habilidades tienen demanda, otras empresas llamarán a tu puerta. Por favor, no te conformes a menos que sea indispensable.

12. ¿Cómo afrontas las entrevistas de trabajo técnicas?

Las entrevistas técnicas no son una broma, y se usan mucho en las empresas de programación que contratan a nuevos empleados. Los programadores sénior a menudo hacen preguntas técnicas solo por diversión. A menudo, estas preguntas son más difíciles por una razón muy concreta que se desconoce y que no determina el resultado de la entrevista.

Para los encuestados las entrevistas técnicas están sobrevaloradas y en general concluyen que si suspendes la entrevista técnica, no es el fin del mundo ni muchísimo menos. Ciertamente no dice nada acerca de tus habilidades como programador. Sólo pone a prueba tu base de conocimientos en torno a un problema concreto.

Hay que tratar de ver el lado bueno. Por ejemplo, si tus habilidades blandas destacan, los empleadores te recordarán. Si les gustas y no eres apto para este papel, es posible que te llamen para otro puesto.

13. ¿Cómo respondes cuando te dan feedback positivo sobre tu trabajo en la empresa?

Dado que la programación no tiene fama de ser un trabajo muy "sociable", en muchas empresas de desarrollo se organizan sesiones de evaluación y retro-alimentación para hablar sobre el trabajo y otras aptitudes relacionadas con el mismo.

La mayoría de los entrevistados en este punto saben que sus jefes juegan con el ego y el orgullo propio de cualquier programador. El consejo que se puede abstraer aquí es el de no "perder el norte". A veces, en tu carrera profesional como programador, te sentirás como una estrella del rock. Los mandos que dependen de ti para completar sus proyectos te dirán lo genial que eres para motivarte. Te sentirás como si estuvieras en la cima del mundo.

Recuerda que están apelando a tu ego. Mantente en con los pies en la tierra. Siempre hay nuevas tecnologías por aprender. Siempre hay programadores que son mejores que tú. Tenlo claro.

14. ¿Cómo respondes cuando te dan feedback negativo sobre tu trabajo en la empresa?

Este punto es parecido al anterior, pero a la inversa. Se trata de obtener consejos para cuando las cosas no vienen bien dadas.

A veces en tu vida laboral, te parecerá que no sabes nada. Alguien que esté frustrado con un proyecto se encargará de decirte que no sabes nada. Tal vez lo hagan para ponerte en tu lugar y bajarte los humos.

Lo importante aquí es tener calma y contemplar la situación con perspectiva porque probablemente sabes mucho más de lo que crees. Cada día que pase, aprenderás un poco más que el día anterior. Después de un tiempo, la gente te admirará por tu constancia y mejora. Sigue adelante. Con el paso del tiempo, es posible que hasta te ganes el respeto de la persona que te dijo que no valías para programar.

15. ¿Cómo gestionas el lado competitivo de la programación?

Que los programadores compiten entre sí no es ningún secreto. Es algo que se debe aprender a llevar con deportividad.

Casi todos los entrevistados concuerdan en que uno de los aspectos más extraordinarios de la programación es la competitividad. A los desarrolladores les gusta programar con gente a la que admiran, y también les gusta que les admiren a ellos por sus logros.

Muchos comentan que cuando se consigue crear un código que un programador que admiras considera digno, te sientes muy realizado y motivado.

La competencia en la programación siempre es o debería ser divertida. No se trata de quién es el mejor. Se trata más bien de aprender unos de otros.

16. ¿Qué consejo darías a un programador novato en la empresa para facilitar su integración en el equipo de trabajo?

Ante esta pregunta, muchas de las respuestas de los programadores encuestados giraban en torno a la comunicación y el miedo a hacer preguntas o a aclarar dudas.

La comunicación es clave en cualquier faceta de la vida, no solo en el lugar de trabajo. Muchos programadores admiten que no les gusta hacer preguntas porque temen quedar en evidencia o no estar a la altura de las expectativas depositadas en ellos, muchas veces escudándose en un "no quiero molestar a mis compañeros".

También es normal que se tengan muchas dudas a la hora de empezar a trabajar en una nueva empresa, con nuevos proyectos, nuevos compañeros y demás. Esto es aún peor si se es un programador novato.

Lo habitual es que la empresa le asigne a cualquier nuevo programador una especie de tutor o de mentor, que además suele ser un programador experto y veterano. Lo más importante en esta relación es la de fijar momentos para consultas, un espacio cada día (al principio) o cada semana (después) para la resolución de dudas relacionadas con el trabajo, y no estar interrumpiendo a cada rato salvo que haya verdadera necesidad.

Si la empresa no asigna un tutor, lo recomendable es "buscarse la vida" entablando una buena relación con los veteranos y buscando tener afinidad con alguno de ellos. La vida se basa en las relaciones personales, y en la empresa no es distinto.

No se trata de caerle bien a todo el mundo, ni de ir a buscar amigos a la empresa, pero sí se puede entablar una relación profesional de confianza con algún miembro del equipo, alguien a quien hacerle cualquier tipo de pregunta sin temores.

17. ¿Cómo gestionas el tiempo y las distracciones mientras trabajas?

La gestión del tiempo y evitar las distracciones y las interrupciones en ciertas ventanas de tiempo donde uno se concentra en programar o revisar código y en la resolución de problemas.

De los resultados de la encuesta llegamos a una conclusión rotunda: la mayoría de los programadores utilizan auriculares, y de los buenos, con sonido ultramegaclaro y aislamiento y/o cancelación de ruidos.

Suele ser un tópico, pero a la vista de los resultados, los programadores además suelen ser amantes de la música. Muchos comentan que la música les ayuda a programar con mayor fluidez, y que, en función de la tarea, la música que escuchan es más o menos intensa. En otras palabras, la música les ayuda a ser más productivo.

Además, el hecho de tener unos auriculares puestos es una señal para el resto: "estoy concentrado". Los que no escuchan música tiene señales físicas en los puestos de trabajo a modo de "no molestar", ya sean banderitas verdes y rojas, o cualquier otra que se tenga convenida en la empresa o con los compañeros.

Conclusión

Para este artículo he destacado estos 17 puntos, pero podría haber añadido algún otro como el de gestionar la vergüenza que se siente cuando ves los churros de código que programabas hace un año o la relación amor odio que se tiene con los meetups y los hackathons... Y alguna cosa más.

De todos modos, espero que estos puntos te ayuden como novato (o no tanto) en un sector tan complejo y a la vez emocionante. Sé que nadie aprende por cabeza ajena, pero al menos no podrás decir que no estabas avisado.

Si eres programador veterano y quieres añadir otro consejo para los nuevos, no dudes a hacerlo en la sección de comentarios.

Vivimos en un mundo muy ajetreado y más, si como yo, trabajas en el sector del software. Hay que poder conseguir la funcionalidad que espera el cliente lo más rápido posible cumpliendo además sus expectativas de funcionamiento. A medida que pasan los meses en un proyecto, la base de código no para de crecer y las cosas se empiezan a complicar para asegurar que todo funciona como debería después de hacer cambios en grandes bloques del sistema.

Sumergidos en esa vorágine, son muchas las situaciones en las que se hace tan solo una revisión exploratoria, que no es más que supervisar manualmente que todo sigue en su sitio, pero... Cuando la aplicación es grande ¿se puede cubrir el 100% de las situaciones de manera manual? ¿Es esto rentable en términos de coste?

La verdad es que ambas preguntas se pueden responder a la vez, no.

Aunque existen casos en los que una revisión manual pueda ser indispensable, como pueden ser ciertas comprobaciones sobre una interfaz gráfica (aunque también hay métodos para no necesitar intervención manual), la comprobación de la mayor parte del software es perfectamente automatizable, de modo que podamos comprobar con regularidad que todo funciona bien.

Si cada vez que vas a desplegar un proyecto a producción, todo tu equipo reza para que nada falle, lo que necesitas son pruebas de software.

Las pruebas de software son un conjunto de procesos con los que se pretende probar un sistema o aplicación en diferentes momentos para comprobar su correcto funcionamiento. Este tipo de pruebas abarca cualquier estadio del desarrollo del sistema, desde su creación hasta su puesta en producción. Lo interesante de las pruebas es que se puedan ejecutar de manera automática, para determinar en cualquier momento si tenemos una aplicación estable o si, por el contrario, un cambio en una parte ha afectado a otras partes sin que nos demos cuenta.

Tipos de pruebas de software

Imagina que estás desarrollando una aplicación web. Durante su proceso de creación utilizarías las pruebas unitarias y de integración para comprobar que todo funciona de la manera esperada internamente. Una vez que la web va cobrando forma, utilizarías las pruebas funcionales para poder comprobar que los requisitos de funcionamiento se están cumpliendo.

Llegados a este punto tenemos una web que cumple con el funcionamiento que se espera pero... ¿soportará el número de usuarios esperado?

Para resolver esa pregunta, recurrimos a las pruebas de carga y de estrés para poder asegurar que la web va a ser capaz de dar respuesta al número de usuarios esperado. De este modo es posible detectar problemas que, simplemente con el código, no se pueden ver con facilidad, y ayuda a encontrar los puntos calientes de nuestro sistema donde deberíamos mejorar.

En estos momentos ya tenemos una web que funciona y es capaz de dar soporte al número de usuarios que queremos. ¿Es usable la web? Por muy buen trabajo que se haya hecho, si la web no es usable no vamos a llegar a los usuarios de la misma. Para poder detectar esto, es el momento de hacer pruebas de usabilidad. Con ellas vamos a poder detectar problemas sobre la propia experiencia de usuario.

Todas estas pruebas, en los diferentes momentos del ciclo de vida de la aplicación, son pruebas de software que permiten asegurar la calidad del producto que estamos desarrollando. Pero aún podríamos comprobar más cosas: la interfaz gráfica, pruebas de extremo a extremo (End To End o E2E)...

¿Es rentable hacer pruebas de software?

Es evidente que crear pruebas es un trabajo extra, independientemente del momento del ciclo de vida del proyecto en el que nos encontremos. En primer lugar, hay que crear los tests y mantenerlos. A medida que el software crece y evoluciona, se producen cambios que obligan a modificar las pruebas, y eso es otro coste adicional, ya que una prueba que no funciona bien es totalmente inútil....

Pues bien, la respuesta es un rotundo... depende (eso no te lo esperabas eh 😆).

Depende principalmente de qué tipo de prueba de software estemos hablando y de cuál sea el alcance del sistema.

Si nuestra aplicación es muy básica y vamos a tener 3 o 4 usuarios, hacer pruebas de carga o estrés seguramente no tenga ningún sentido. En cambio, ¿te imaginas que una web como por ejemplo Facebook o Twitter no las tengan? ¡Podría ser catastrófico! Un cambio en un punto clave del sistema que haga que una petición tarde un 20% más en responderse, y de repente errores de servidor saturado a miles de personas... Pero, incluso para esa aplicación básica, sería interesante que tuviese alguna prueba de integración que comprobará que sus puntos clave están funcionando en todo momento.

Las pruebas de software deben ser acordes al producto que se está desarrollando, pero rara es la vez (por no decir nunca) donde no sean útiles.

Hoy en día existen herramientas y frameworks para automatizar la gran mayoría de las pruebas de software en sus diferentes niveles, de modo que se ejecuten automáticamente, de manera periódica o con los cambios. Gracias a esto, es posible reducir al mínimo los errores cuando se realizan cambios durante el ciclo de vida de un software.

Vale, son útiles en proyectos grandes y grandes equipos como Facebook o Twitter, pero, ¿si trabajamos solos en proyectos pequeños no carecen un poco de sentido? La realidad es que, por muy buenos que seamos, las personas nos equivocamos y no tenemos una memoria perfecta. Así que, incluso para trabajar una sola persona en proyectos pequeños, es interesante añadir pruebas que aseguren el funcionamiento. Al cabo de unas pocas semanas, ¿eres capaz de recordar el 100% de código que has desarrollado y la utilidad de cada línea o método? Lo que puede parecer un cambio menor que no va a afectar en nada al sistema, puede tener un alcance imprevisto al modificarlo.

En resumen

Como conclusión de todo lo anterior podríamos sacar las siguientes enseñanzas:

• Las pruebas de software son un conjunto de técnicas que nos permiten asegurar la calidad del producto que estamos desarrollando en sus diferentes etapas del ciclo de vida.
• Aunque tienen un coste de desarrollo y mantenimiento extra, son especialmente útiles para facilitar la calidad del software a medio y largo plazo.
• El tipo y cantidad de pruebas tiene que ser acorde al producto que estamos desarrollando: no es lo mismo un producto grande que una aplicación web para anotar tareas.
• Todo software debería tener algún tipo de prueba para asegurar su calidad independientemente del tamaño del mismo o del número de personas involucradas en su desarrollo.

Si trabajas en una empresa de desarrollo y tu cometido es planificar la formación de los nuevos desarrolladores que se incorporan a la empresa, probablemente tengas muchas dudas, ya que es un proceso a medio plazo y que varía mucho en función de los perfiles y de la especialización.

Muchos departamentos de recursos humanos y responsables de equipos de programadores tienen dudas a la hora de fijar un plan formativo para sus trabajadores tecnológicos.

La incorporación de nuevos programadores no es fácil, y se debe plantear como un proceso a medio plazo. Existen varias "trampas" en las que se suele caer como empresa, y las voy a intentar explicar más abajo.

Cuando el programador que se incorpora ya tiene experiencia y sabe programar, todo este proceso es bastante más sencillo. Este artículo no va dirigido a este perfil de desarrolladores.

Sin embargo, cuando son desarrolladores nuevos, tanto en la empresa como en la profesión, hay que formarles en varios sentidos: enseñarles a trabajar en general, enseñarles a trabajar en la empresa, enseñarles a seguir procedimientos y a trabajar en equipo siguiendo la metodología correspondiente, etc.

Surgen dudas del tipo:

• ¿Cómo se debe planificar la formación de un nuevo programador a lo largo del tiempo?
• ¿Es mejor un curso o que aprendan por su cuenta con ayuda del equipo de cara a su especialización?
• ¿Cuándo es el mejor momento, tras unos meses o nada más entrar?
• ¿Es mejor un curso presencial u online?

Cada equipo de programación tiene una forma diferente de hacer las cosas, lo que puede dificultar que los nuevos profesionales se familiaricen con el código y los procesos de formación de la empresa.

Retos para los departamentos de RRHH a la hora de incorporar nuevos desarrolladores

En este artículo voy a exponer los mayores retos a los que se enfrentan los departamentos de RRHH a la hora de incorporar y formar a nuevos desarrolladores, así como consejos sobre cómo intentar superarlos. No es fácil, y no hay una fórmula mágica, pero con un poco de trabajo todo se consigue.

1. Enseñarles a trabajar (de forma inteligente)

Hay más de una manera de realizar una misma tarea: desde modificar directamente el código hasta construir un sistema adaptable.

Muchas empresas detectan que, al principio, los nuevos desarrolladores tan solo quieren terminar su trabajo como sea, incluso si tienen que volver a rehacerlo por completo, para poder dar salida a un nuevo cambio que exige el cliente y tener sensación de que avanzan y hacen cosas útiles.

El problema en estos casos no es que no trabajen, sino que trabajan de más y no son productivos. Esto pasa en todos los oficios. A las personas sin experiencia hay que enseñarles cómo hacer las cosas en el contexto empresarial: rentabilidad, productividad, foco, eficiencia, etc.

Enseñarles la importancia de armar sistemas y estructuras de código flexibles que se adapten al cambio es la solución en estos casos. Es una labor a medio/largo plazo, pero es la mejor forma de trabajar en aras del éxito y la rentabilidad de la empresa. Eso y que lo perfecto es lo enemigo de lo bueno.

2. Evitar que los demás departamentos tiren del "nuevo" para cubrir sus necesidades

El departamento de marketing, el de producción e incluso el de finanzas a menudo se pelean por nuevos programadores que se incorporan. Estos departamentos ven en la nueva contratación como un objetivo fácil para sacar adelante sus listas de tareas pendientes.

Se les pide hacer esas tareas que nadie quiere hacer y que van desde hacer búsquedas en la base de datos hasta ayudarles a arreglar y configurar ordenadores lentos. Para evitarlo, asegúrate de que la estructura de mando sea clara, tanto para tu nuevo empleado como para los demás departamentos.

Lo peor que puede pasar es contratar a alguien para un fin concreto y que el recurso sea arrastrado por las carencias o déficits de los demás departamentos de la empresa.

3. Darles confianza y hacerles ver que son capaces de hacer cosas fascinantes

Uno de los mayores retos es conseguir que los nuevos desarrolladores crean que son capaces de hacer cosas increíbles. Seguramente los perfiles que se han incorporado son programadores inteligentes, motivados y creativos.

Hay que proporcionarles la capacidad de asumir responsabilidades y algo de liderazgo, y darles apoyo, formación y tutoría. Tanto la empresa como ellos mismos se sorprenderán de lo que son capaces de hacer.

Para ello es buena idea asignarles un tutor en el ámbito de la empresa (un veterano de otro departamento que le ayude a adaptarse a nivel personal y profesional a un entorno profesional). Por otro lado, es muy interesante asignarles un mentor al que consultar dudas técnicas de programación y de los proyectos de software (un mentor que les ayude en el desempeño de sus tareas).

Es muy fácil de decir y muy difícil de hacer. Hay muchas variables que no podemos controlar (incompatibilidad de caracteres, carga de trabajo de los tutores/mentores, habilidades blandas de ambas partes, etc).

En mi empresa la figura del tutor se asigna desde el primer día, pero la del mentor se pospone en el tiempo para ver si surge química entre la nueva incorporación y alguien veterano de forma natural. Si no se da tras un mes, se asigna uno teniendo en cuenta la idoneidad y la compatibilidad de las personas y las tareas.

4. Tener y usar software de código abierto

Al disponer y utilizar tecnologías de código abierto es posible encontrarnos que los nuevos fichajes ya estén familiarizados o sean competentes con las tecnologías que se usan en la empresa.

Además, el hecho de que hayan colaborado con su código en otros proyectos, te permitirá evaluar sus habilidades y competencia, y así poder enfocar su etapa de formación en mejorar aquellas cosas en las que no se muestran tan competentes.

Hoy en día hay tecnologías de este tipo en todas las empresas. Simplemente son un buen recurso para la adaptación de las nuevas contrataciones y para detectar ámbitos de mejora, aunque el software que desarrolléis sea propietario y no Open Source.

5. Familiarización de los nuevos desarrolladores con la base de código existente

Familiarizarse con la base de código existente, con todos sus elementos, es una curva de aprendizaje pronunciada para cualquier desarrollador, pero lo es más si son novatos.

Lo mejor es empezar con plantearles un problema sencillo que les permita centrarse en analizar el código fuente y familiarizarse con vuestros procesos.

A partir de ahí, se deberían seleccionar tareas cada vez más difíciles para varias áreas del código, con el fin de evaluar la capacidad del nuevo programador a enfrentarse a estos problemas y ajustando sus tareas en función de los misma.

En este proceso, la figura del mentor del punto 3 es clave para la resolución de dudas. Lo mejor es asignar un momento al día (15 minutos por la mañana y 15 minutos por la tarde), para que el nuevo programador no interrumpa al sénior todo el rato.

6. Integración con las prácticas de desarrollo en la empresa

Cada equipo de desarrollo tiene su propia manera de implementar buenas prácticas de desarrollo. En mi empresa hemos creado un manual SOP (procedimiento de operación estándar, por sus siglas en inglés) para que nuestros nuevos desarrolladores lo repasen una vez que hayan sido contratados.

En él se describen las herramientas de desarrollo que utilizamos, así como la forma en que las utilizamos en nuestras bases de código de producción. Esto ayuda a establecer expectativas y aliviar tensiones cuando el nuevo desarrollador hace sus primeras contribuciones a la empresa, ya que existe un marco de referencia y un consenso en el equipo en torno a un procedimiento que todos siguen.

Mediante la creación de un procedimiento operativo estándar, que pueda simplemente ir familiarizando a los nuevos empleados con los desarrollos y el código fuente, es posible incorporar y entrenar a los nuevos desarrolladores de forma más efectiva.

7. Desglosar la complejidad del software

La complejidad del software es un gran desafío. La funcionalidad del producto y la necesidad de cubrir muchos casos de uso y diferentes flujos de trabajo de clientes, se traduce en productos software de gran tamaño.

Por poner un ejemplo, la formación de los nuevos profesionales en cada microservicio es una buena manera de ayudar a reducir la complejidad.

Conclusión

Incorporar a perfiles nuevos a la empresa siempre supone un reto. Las cosas pueden salir bien o no, como con cualquier otro tipo de relación entre personas.

Lo que no se puede permitir una empresa de desarrollo es invertir tiempo y dinero en los procesos de selección de programadores para luego no tener bien planificada toda la fase de adaptación y formación en la empresa de los nuevos desarrolladores.

No sobran los perfiles de este tipo y como empresa, tenemos que hacer todos los esfuerzos necesarios para consolidar la relación con los nuevos programadores que incorporamos.

Si crees que falta algún consejo en esta lista, no dudes en compartirlo en la sección de comentarios.

Ante la situación de excepcionalidad que se está viviendo en todo el mundo estos días, y en particular en Europa y en España, por el virus COVID-19, nos gustaría comentar cómo estamos actuando en campusMVP:

• Nuestra actividad sigue siendo normal y podemos seguir respondiendo a vuestras dudas y consultas en la Web acerca de cualquiera de nuestros cursos, así como atendiendo nuevos pedidos y resolviendo cualquier incidencia.
• El 100% de nuestros tutores han trabajado de forma remota desde el primer día y ninguno está enfermo (al menos por ahora: actualizaremos si cambia), por lo que las tutorías no se verán afectadas en modo alguno y seguirán atendiendo a vuestras dudas con la rapidez y exhaustividad habituales.
• Aproximadamente el 35% de nuestro personal de estructura hace trabajo remoto desde hace años, y desde este lunes día 16 de marzo de 2020, el 100% trabajaremos desde casa. Podéis seguir llamando por teléfono al número habitual pues nuestra telefonía es VoIP, y por supuesto a través del email, redes sociales, etc...

Os enviamos ánimos a todos para afrontar las restricciones de movimiento, posible confinamiento e impacto en vuestra economía personal.

Os dejamos unos enlaces de interés sobre el COVID-19:

• Guía de actuación ante el coronavirus
• Datos oficiales del Gobierno de España
• Impresionante dashboard de PowerBI con la evolución actualizada de la enfermedad
• Los bulos del coronavirus
• Mapa del Coronavirus en España, por la RTVE
• Mapa y datos del virus en Europa por la OMS

La semana pasada Microsoft anunció sus planes de futuro para Visual Basic .NET. Aunque el artículo tiene un tono positivo y trata de quitarle hierro al asunto, la verdad es que marca el principio del fin del lenguaje, ya que manifiesta claramente que no tiene planes para hacer que Visual Basic evolucione y se adapte a las nuevas características que se añadan en el futuro, reforzando mi tesis de hace años de que C# es el lenguaje a elegir.

Como seguramente sabes, el próximo mes de noviembre Microsoft planea lanzar .NET 5, en la que planean refundir en una sola todas las plataformas, y que en realidad es el "rebranding" definitivo de .NET Core a .NET (dale una lectura si no lo tienes claro: te interesará).

El anuncio de Microsoft dice que "soporta la estabilidad del lenguaje y mantiene la compatibilidad entre las versiones de Visual Basic entre las plataformas .NET y .NET Core", pero lo que esto quiere decir también es que el lenguaje no va a recibir soporte para las nuevas tecnologías que incluye .NET Core. Es decir, que va a permanecer estable pero estancado, congelado en el tiempo...

Sí, sé que en el anuncio dicen que, a partir de .NET 5, Visual Basic va a soportar nuevos tipos de aplicaciones en .NET Core, a saber:

• Bibliotecas de clases
• Aplicaciones de consola
• Aplicaciones de escritorio con Windows Forms
• Aplicaciones de escritorio con WPF
• Servicios en segundo plano multiplataforma (Service Workers, terrible nombre con nada que ver con los de JavaScript en el navegador: aquí te los explica nuestro tutor Jorge Turrado)
• Servicios Web con ASP.NET Core Web API

y hasta ahora sólo soporta los dos primeros. Esto es algo estupendo, pero según Microsoft, se ha hecho con el objetivo de "ofrecer una buena ruta hacia adelante para aquellos clientes que usan VB y que quieren migrar sus aplicaciones a .NET Core". Es decir, esto es una manera de suavizar el golpe y dar tiempo para que puedas migrar algunas cosas a .NET Core / .NET 5, pero no una vía de futuro, ya que al mismo tiempo dejan claro que "En adelante, no tenemos planes de evolucionar Visual Basic como lenguaje", para más adelante añadir "Futuras características de .NET Core que requieran cambios en el lenguaje puede que no estén soportadas por el lenguaje".

Dado que .NET se incluye en el sistema operativo desde hace décadas, dejan claro que, mientras Windows esté soportado, .NET "tradicional" también estará soportado, así como Visual Basic. Esto es genial y da una garantía de futuro para el desarrollo con .NET tradicional en Windows, pero tampoco dejan lugar a dudas cuando dicen que Visual Basic (y .NET tradicional) no van a evolucionar más. Así que, a medida que la tecnología avance, y las necesidades de los desarrolladores cambien, no habrá una buena ruta de migración desde Visual Basic a .NET Core / .NET 5.

Si desarrollas en Visual Basic vas a poder seguir haciéndolo durante mucho tiempo. No obstante, mi recomendación sería que mantengas las aplicaciones actuales para Windows en Visual Basic .NET si ese es el lenguaje que utilizas, pero que aprendas C# y .NET Core, y te cambies a ese lenguaje para todos los proyectos nuevos que desarrolles. Esa es la garantía de futuro.

HTML, CSS y JavaScript nacieron como lenguajes simples, para crear documentos con un mínimo de interactividad (validar formularios y poco más). La mayor parte de la responsabilidad recaía en el servidor, que era el que se encargaba de hacerlo casi todo, dejando al navegador un papel secundario de visualización.

Con los años, la ubicuidad de Internet y gracias a la mejora de los navegadores, el hardware y los sistemas operativos, estos lenguajes han evolucionado para tener cada vez más potencia, hasta el punto de que, en la actualidad, no tienen casi nada que envidiar a lenguajes más tradicionales. Con HTML, CSS y JavaScript se pueden construir todo tipo de aplicaciones complejas, con casi las mismas capacidades que las nativas y que funcionan más allá de la Web: fuera del navegador en el escritorio, en dispositivos móviles, en servidores...

Al mismo tiempo se han creado inmensas comunidades alrededor de estos lenguajes, y han dado lugar a una explosión de herramientas especializadas, en su mayor parte gratuitas y de código abierto, que nos permiten acelerar mucho el trabajo, disminuir los errores, optimizar el código... y muchas otras cosas más.

Debido a todo esto, lejos quedan ya aquellos tiempos en los que, para crear una aplicación Web, lo único que hacía falta era un editor de texto más o menos avanzado y nada más. Hoy en día es complicado hasta, tan solo, seguirle la pista a todo lo que existe.

En esta guía voy a repasar contigo las principales categorías de herramientas para saber para qué se utilizan y cuáles son las más importantes.

Nota: algunas herramientas que menciono pueden estar en más de una categoría al mismo tiempo, ya que son muy versátiles. Por ejemplo, Webpack es un bundler pero también permite automatizar tareas y muchas cosas más. En esos casos las he colocado en la categoría que mejor encajan de entrada, aunque podrían mencionarse en otras partes también. El orden que he seguido va de lo más sencillo y obvio hasta lo más avanzado. Es posible que me deje algunas cosas en el tintero, ¡porque hay muchas!, pero sí que he querido incluir las más importantes y conocidas de cada categoría.

¡Allá vamos!

Gestores de plantillas

Si tenemos claro qué vamos a construir y con qué, antes de empezar con cualquier proyecto puede resultar muy útil no empezar en blanco y partir de algo ya hecho, que nos deje todos los componentes básicos en su sitio y una estructura de carpetas apropiada.

Por ejemplo, si vamos a crear una aplicación compleja, de nivel empresarial, basada en Angular, podemos usar las herramientas integradas que ofrece Angular Cli o partir de una estructura ya hecha que siga las reglas y buenas prácticas que aconseja el equipo de Angular.

O sea, se trata de conseguir algo parecido a lo que nos dan las plantillas de algunos IDE, como Visual Studio, pero para la Web, e independiente de cualquier editor o entorno de desarrollo.

En Front-End el gestor de plantillas por antonomasia es Yeoman. Se trata de un sistema con más de 3500 plantillas predefinidas en el que puedes encontrar casi de todo. La verdad es que a veces cuesta separar el grano de la paja, pero cuando encuentras tus 2 o 3 plantillas habituales, te ahorra mucho trabajo para arrancar con algunos proyectos.

Linters y formateadores de código

Tanto si se trabaja en equipo como si somos "llaneros solitarios" que trabajamos por nuestra cuenta, mantener la coherencia en el código que escribimos es muy importante a largo plazo. Si escribimos en cada lenguaje de una forma consistente, nos ayudará a entender mejor nuestro código y el de los demás, incluso aunque lo leamos varios meses más tarde, facilitará incorporar nuevas personas al equipo y sobre todo ayudará a que el mantenimiento y ampliaciones futuras no supongan un problema.

Cuando hablo de mantener la consistencia, no sólo me refiero a cosas simples de estilo como poner siempre el punto y coma al final, usar espacios y no tabuladores o que las llaves empiecen en la misma línea que la estructura que envuelven (que también), sino a cosas más complejas como la coherencia en los nombres de las variables y funciones, controlar que se siguen buenas prácticas o el modo estricto, que no se hacen llamadas innecesarias a call() o apply(), etc... O sea, reglas de estilo y de calidad.

Este tipo de herramientas nos permiten definir conjuntos de reglas (o incluso usar reglas de empresas conocidas, que ya están probadas), y luego comprueban el código a medida que se escribe de modo que no nos podamos salir del camino marcado. Consiguen aumentar la calidad de nuestros desarrollos, mantener la coherencia y en general evitar los problemas que comentaba al principio.

Las más conocidas y utilizadas son:

• ESLint: se trata de un linter para ECMAScript que es muy configurable y que trae de serie multitud de reglas preconfiguradas (a las que podemos añadir reglas propias). Nos permite reutilizar reglas en el equipo e incluso partir de reglas ya probadas en otras empresas (como AirBnB o Facebook, por ejemplo) y construir sobre ellas.
• JSHint: se trata de otro linter bastante utilizado que es más sencillo de emplear que ESLint, pero que nos proporciona menos flexibilidad y capacidad de ampliación y configuración. Poco a poco se está abandonando su uso por ESLint, pero conviene tenerlo en el radar porque todavía tiene muchos adeptos.
• Prettier: es un formateador de código, no un linter. Esto quiere decir que, como su propio nombre indica, se encarga de asegurar que el código "luce bonito" en cuanto a formato, en lo que se pisa un poco con los linters y es muy importante también, pero no nos ayuda con la calidad. Prettier es el más utilizado y el mejor con diferencia, y está integrado con la práctica totalidad de editores de código avanzados. Soporta más lenguajes que JavaScript, como HTML, CSS, JSX o Markdown, y ofrece muchos plugins para cosas concretas. Un "must have".

Verificadores de tipos estáticos

Como ya sabes, aunque JavaScript dispone de varios tipos de datos nativos y podemos crear nuestros propios tipos, se trata de un lenguaje débilmente tipado. Esto quiere decir, básicamente, que podemos definir una variable (que no lleva tipo alguno asociado) y luego le podemos asignar cualquier valor que deseemos, incluso varias veces, cambiando en cada ocasión el tipo utilizado. Obviamente, esto es una mala práctica, pero la realidad es que es muy fácil confundirse y luego tener problemas por cambios de tipo inesperados o porque le pasamos a una función algo para lo que inicialmente no estaba diseñada.

Los verificadores de tipos estáticos se ocupan de verificar la seguridad de los tipos de datos en nuestro código. Para entendernos, hacen que JavaScript se pueda comportar como un lenguaje tipado, de modo que podamos identificar directamente en el código, ciertos tipos de errores que, por regla general, sólo detectaríamos en ejecución. Como efecto secundario tendremos también mayor facilidad a la hora de escribir el código, ya que si el editor ofrece soporte para alguna de las herramientas que veremos a continuación, obtendremos ya información en línea sobre los tipos esperados, facilitándonos el trabajo. Aunque siempre hay quien no está de acuerdo con esto.

El verificador más conocido y utilizado es Flow. Se trata de un verificador creado por Facebook para uso interno y luego liberado al público en general. Está tomando un gran impulso en los últimos tiempos. Ofrece soporte para inferencia y seguimiento de tipos a partir del código existente, un sistema de tipos opcional, feedback a medida que modificamos el código, anotaciones de tipos, hace linting... Además es muy fácil de poner en marcha y está integrado con los editores más importantes (por ejemplo Atom, Sublime Text, Vim, Emacs, WebStorm... y por supuesto mi favorito, Visual Studio Code).

Además de Flow, el otro gran adalid de los tipos estáticos es TypeScript. En realidad, TypeScript va mucho más allá y es todo un lenguaje + compilador por encima de JavaScript, como veremos más adelante, pero su principal objetivo cuando nació era precisamente dotar de un sistema de tipos para JavaScript (de ahí su nombre), y por eso lo incluyo también en esta categoría.

Aquí te dejo una comparativa entre Flow y TypeScript, pero en mi opinión, ya de invertir en aprender uno de los dos, en la actualidad es más interesante aprender TypeScript, que está ganando muchísima popularidad y cada vez lo usan más empresas. Luego volveré sobre él.

Transpiladores de código

Un transpilador es un programa especializado en transformar código de un lenguaje o variante de lenguaje a otra. En contraste con un compilador tradicional, que transforma código fuente en código máquina listo para ser utilizado por el sistema operativo, un transpilador transforma código en otro código diferente.

¿Y para qué me vale esto? Pues fundamentalmente para dos cosas:

• Para poder utilizar otros lenguajes por encima de JavaScript
• Para poder usar versiones modernas de JavaScript sin problemas con navegadores antiguos

En el primer caso podrás utilizar superconjuntos de JavaScript como TypeScript o CoffeeScript para programar tus aplicaciones con muchas ventajas, y el transpilador correspondiente se encargará de convertir el código que has escrito a JavaScript/ECMAScript que funcione en cualquier navegador.

En el segundo caso, como sabes, JavaScript está evolucionando constantemente a través del organismo de estandarización ECMA, sacando cada año una nueva versión de ECMAScript. Las nuevas características que van apareciendo a veces son muy interesantes para aplicar en los desarrollos, pero los navegadores tardan un tiempo en incorporarlas y además hay usuarios que no tienen su navegador actualizado. Así que, un transpilador nos permite también compilar código moderno de ECMAScript a cualquier versión anterior del lenguaje, incluyendo los "parches" o polyfills que sean necesarios para que funcione. Esto nos da la oportunidad de utilizar las técnicas más modernas sin preocuparnos por posibles incompatibilidades.

Aunque todos los lenguajes superconjunto de JavaScript como los mencionados incluyen su propio transpilador, existe un transpilador predominante que es el que todo el mundo usa: Babel.

Babel nació como una manera de usar características modernas de ECMAScript en navegadores antiguos, pero con el tiempo se ha convertido en el transpilador universal para JavaScript, pudiendo incluso transformar el código con otros propósitos y también transpilar otros lenguajes directamente. Por ejemplo, puedes transpilar TypeScript a JavaScript usando Babel y sin necesidad de usar tsc.exe, el compilador/transpilador de TypeScript.

Lo usarás mucho más de lo que te imaginas, ya que a medida que usas ciertas bibliotecas o frameworks, verás que lo necesitas o que lo integran en su proceso de compilación.

Gestores de dependencias

En la actualidad, es casi imposible desarrollar una aplicación web no trivial sin hacer uso de componentes y bibliotecas externas, además de muchas de las herramientas que estamos viendo en este artículo.

Pero el uso de estas dependencias externas de nuestro proyecto conlleva una serie de complejidades adicionales. En primer lugar, mantenernos actualizados a medida que salen nuevas versiones que añaden funcionalidad, arreglan bugs y problemas de seguridad. Por otro lado, las interacciones y dependencias complejas que se pueden dar entre todo lo que utilizamos, ya que unas bibliotecas dependerán de otras y a veces lo hacen de una versión concreta. Finalmente, un tercer problema principal a solucionar, es el poner en común con todo nuestro equipo que trabaja en la aplicación todas estas dependencias. Es decir, que todos usemos siempre las mimas herramientas, componentes y bibliotecas, en las mismas versiones y con las mismas actualizaciones.

Para lograr estos objetivos necesitamos un buen gestor de dependencias, que nos ayude a llevar cuenta de todas ellas, a actualizarlas automáticamente y que sea capaz de compartir esta información de manera sencilla y transparente con todos los involucrados en el desarrollo.

Los gestores de dependencias más conocidos y utilizados en desarrollo Web Front-End son:

• npm: es hoy en día, con diferencia, el más popular. Si lo relacionas más con el desarrollo de lado servidor... tienes toda la razón: se empezó a utilizar como gestor de dependencias y paquetes de Node.js para aplicaciones de servidor, pero con los años se extendió hasta dominar por completo el Front-End también. Se utiliza, como todos, desde la línea de comandos y volveremos a verlo enseguida porque es capaz de hacer mucho más que gestionar dependencias, siendo en la actualidad una herramienta indispensable para todo desarrollador Web. Tiene un registro online de paquetes en su web y una herramienta de línea de comandos para instalarlos y gestionarlos.
• Yarn: es un proyecto que lanzó Facebook en 2016 para atajar algunas de las limitaciones que tenía npm por aquel entonces. Es 100% compatible con el registro de npm pero lo dota de más velocidad y seguridad de npm, por eso es bastante utilizado por muchos desarrolladores y empresas. Cuando se lanzó aportaba más que ahora, ya que npm se ha puesto "las pilas" y ha mejorado mucho, pero aún así es más rápido, genera menos archivos innecesarios, es más seguro y ofrece cosas únicas muy interesantes, como los Workspaces para poder crear subproyectos gestionados de manera independiente dentro de un único repositorio.
• Bower: es el gestor de paquetes clásico para Front-End ya que nació antes de que npm pudiera gestionarlos. Desde entonces ha ido cayendo en desgracia a favor de npm y Yarn, pero sigue siendo muy utilizado.
• pnpm: se trata de una utilidad relativamente reciente, pero con mucha actividad. Su objetivo es ser compatible con npm pero ser mucho más eficiente y rápido utilizando el espacio de los archivos, yendo más allá de Yarn. Si te preocupa el espacio consumido en disco por las carpetas de dependencias, pnpm merece la pena.

Ejecutores de tareas o Task Runners

Cuando trabajas en un proyecto de cierta envergadura existen infinidad de pequeñas tareas que vas a necesitar realizar una y otra vez. Desde cosas sencillas como copiado de archivos o limpieza de carpetas, hasta compilación/transpilación (como hemos visto), pasando por concantenación de archivos, minimización y ofuscación de código, linting (ver más arriba), optimización de imágenes, vigilancia de archivos, recarga de páginas mientras depuras, ejecución de pruebas/test, etc...

Todas estas tareas se pueden hacer a mano, pero cuando hay que hacerlas constantemente, en un orden determinado y/o en paralelo, y sobre todo después de cada cambio en el código para poder depurar, es necesario recurrir a alguna herramienta que las automatice.

Las herramientas más conocidas y utilizadas son:

• Gulp: que se basa en código JavaScript que escribes en un archivo para describir las diferentes tareas y enlazarlas. Se utiliza, como todos, desde la línea de comandos y dispone de miles de plugins para hacer cualquier cosa que se te ocurra, aunque puedes programar más cosas y combinaciones de los existentes. Es muy utilizado.
• Grunt: otro ejecutor de tareas de código abierto y basado en JavaScript, aunque en este caso prima la configuración frente al código a la hora de definir las tareas. Con miles de plugins para hacer cualquier cosa, tuvo su época dorada hace unos años y ahora está en declive, pero conviene al menos saber que existe porque te lo puedes encontrar por ahí.
• npm: sí, otra vez. El gestor de paquetes es también una excelente herramienta de ejecución de tareas puesto que nos permite crear pequeños scripts que se ejecutan con el comando npm run y que sacan partido al apabullante directorio de paquetes que tiene, con decenas de miles de paquetes para hacer cualquier cosa que se te ocurra. En la actualidad es el que se está llevando el gato al agua, siendo utilizado en muchísimos proyectos en detrimento de Gulp. Gran parte del éxito es también que nos ahorramos tener que instalar una nueva herramienta, puesto que npm, sí o sí, lo vamos a tener instalado, así que ¿por qué no aprovecharlo para esto también si puedes?

Otras opciones que han ido surgiendo pero cuya adopción es pequeña y de momento van por detrás de los mencionados en funcionalidad o flexibilidad son:

• Brunch: trata de competir con Gulp haciendo que la configuración y el código sean mucho más sencillos y breves.
• Broccoli.js: es muy sencillo de utilizar y usa instrucciones sencillas de JavaScript en una línea.

Estos no hay que perderlos de vista.

Empaquetadores de módulos o bundlers

Los bundlers nacieron hace unos años como una forma de incluir en un solo archivos múltiples recursos necesarios para una aplicación Web. Por ejemplo, mezclando en un solo archivo todas las bibliotecas JavaScript que usa tu aplicación, de modo que en lugar de tener que descargar 10 archivos, sólo se descarga uno. Esto tenía su lógica en aquel momento pre-HTTP2 porque cada descarga individual de archivos añadía retraso al renderizado de la página y la ejecución de la aplicación, y en aplicaciones grandes y orientadas a móviles cada décima de segundo cuenta.

En la actualidad eso es lo menos importante gracias a HTTP2 (que multiplexa la descarga de archivos a través de una misma conexión), pero los bundlers siguen llevando a cabo tareas importantes para optimizar el código: para empezar son capaces de gestionar dependencias entre partes de la aplicación aunque no usemos módulos, también pueden empaquetar recursos que no son JavaScript dentro de los "bundles" finales, y además ofrecen capacidades de "tree-shaking" del código, es decir, son capaces de eliminar automáticamente todo aquel código que no usa nuestra aplicación reduciendo enormemente el tamaño de la aplicación final.

Además, nos facilitan el uso de las dependencias gestionadas con npm y otros gestores de paquetes (ver más arriba) de modo que, aunque se encuentren en la carpeta node_modules podamos utilizarlos igualmente y aparezcan en los archivos de la aplicación final. De todos modos, si eso es lo único que necesitamos, ahora existen herramientas como Pika o SystemJS que están empezando a pisar fuerte y tienen una orientación completamente diferente (casi podría haber hecho una categoría aparte en este artículo con ellos, pero lo voy a dejar así 😉).

Finalmente, en la actualidad también incluyen muchas de las atribuciones tradicionales de los ejecutores de tareas que hemos visto antes, ya que son capaces de hacer muchas de las cosas que hacen éstos, incluyendo la transpilación de código usando plugins.

Es por esto que cada vez están ganando más aceptación, aunque generalmente debemos combinarlos con todo lo anterior, en cualquier caso.

Los más conocidos y utilizados son:

• Webpack: es sin duda el rey de los bundlers y la herramienta avanzada que todo desarrollador web Front-End debe conocer. Hace de todo: bundling, transpilación, modularización de código y de recursos (incluyendo dependencias de CSS, fuentes tipográficas o imágenes), optimización, automatización, code splitting, lazy loading, tree shaking, sustitución de módulos en caliente, monitorización automática de dependencias, trabajo para depuración... Puede llegar a ser compleja, pero es la "herramienta total", y muy, muy utilizada. En este artículo, hace tiempo, te explicaba con más detalle qué es y para qué sirve.
• Browserify: el bundler clásico un poco "de capa caída" debido a WebPack. Su principal y mayor objetivo es poder utilizar módulos de Node.js en el navegador. Muchas de las librerías Front-End que se incluían en el directorio de npm están encapsuladas con el sistema de módulos de Node.js, no con el estándar de ECMAScript, y con Browserify utilizarlos era sencillo y directo. Con el soporte nativo para el sistema de módulos de ECMAScript que tienen ya todos los navegadores modernos y el uso de herramientas com Webpack y Pika, su utilidad ahora es menor, pero hay que conocerlo.
• Parcel: es una seria competencia de Webpack que hace hincapié sobre todo en la velocidad y en la facilidad de configuración, y que está ganando mucho terreno en los últimos tiempos.
• Rollup: otro competidor en alza de Webpack que es especialmente bueno con el tree shaking.

En resumen

Todo lo anterior es tan sólo el "tooling", pero hay muchas otras cosas de base que debemos conocer. Sin duda, el mundo actual del desarrollo Web Front-End es mucho más complejo de lo que era hace años, pero a cambio obtenemos más velocidad de desarrollo, mayor calidad y mejora del trabajo en equipo.

Tan solo mantenerse al día de todo lo que hay en el mundillo ya da su trabajo, pero lo principal que debes conocer es lo que te he resumido en este (largo) artículo. He repasado las principales categorías de herramientas que existen, explicando para qué sirven y cuáles son las principales que debes conocer.

Espero que te sirva para ubicarte y saber qué opciones tienes. Y si quieres aprender a dominar las principales herramientas anteriores y dar un salto cualitativo en la profesionalización de tu carrera como desarrollador Web Front-End, ya sabes.

Por muy poco tiempo que lleves programando o incluso si estás pensando en aprender a programar para poder vivir de ello, ya sabrás que es una profesión que exige estar permanentemente aprendiendo cosas nuevas.

También te habrás dado cuenta que para ser buen programador no es tan importante asistir a cursos de forma presencial para obtener un diploma. Lo importante es aprender, da igual si lo haces en la Universidad, en un ciclo de FP, en tu casa como autodidacta o con un curso online (pero que sea bueno😉).

Al principio es bueno optar por una buena formación, pero muchos buenos programadores terminan siendo personas autodidactas que "aprenden a aprender" de forma más rápida que el resto. Esta es una cualidad fascinante de los buenos desarrolladores de software.

Todo el mundo es lo suficientemente inteligente como para aprender a programar, pero no todo el mundo puede ser programador por una serie de razones distintas a la inteligencia. Hay muchos otros factores: la gestión de la frustración, el esfuerzo o más bien la forma de enfocarlo, las motivaciones personales... y el hecho de que te apasione o no, entre otras.

En un mundo que cambia rápidamente, la capacidad de aprender una nueva habilidad lo más rápido posible se ha convertido en una obligación. La buena noticia es que no se necesita un don natural para ser mejor en el aprendizaje de algo nuevo, incluso cuando se tiene un trabajo a jornada completa. Algunos de los más famosos polímatas afirmaban no ser más inteligentes que el resto.

Todos tenemos suficiente poder mental para dominar una nueva materia si usamos las herramientas y enfoques apropiados, o si aplicamos lo aprendido correctamente. Casi cualquiera puede aprender cualquier cosa si se utilizan las técnicas adecuadas.

Con mejores enfoques didácticos, los procesos pueden ser más efectivos. La clave para la rápida adquisición de habilidades no es nada complicada, pero sí que requiere tiempo.

El proceso de aprender a aprender más rápido es largo porque hay que tener acumulada ya cierta experiencia y sufrir muchos fracasos para conseguirlo. De todos modos, sí que puedes empezar a adquirir desde ya una serie de buenos hábitos que te pueden ayudar a aprender mejor y más rápido en menos tiempo.

1.- Concebir el aprendizaje como un proceso

Más que nunca, la formación constante es vital si se quiere seguir siendo relevante, indispensable y prosperar en el cambiante mundo del trabajo, y más especialmente en el ámbito de la programación de software.

Hay personas que disfrutan más durante el viaje que en el punto de destino. Para las personas que adquieren conocimientos de forma ágil y aparentemente sin esfuerzo, aprender en realidad es como un viaje: es un descubrimiento de nuevos conocimientos, y no un destino final.

En otras palabras, las personas que están aprendiendo cosas todo el tiempo valoran el proceso. No tienen un objetivo final, buscan una mejora constante toda su vida personal y profesional.

Para estas personas, es un proceso agradable para toda la vida, un proceso que cada uno lleva a su propio ritmo pero que nunca se detiene. La comprensión de cualquier nueva materia exige y requiere no sólo de la observación aguda sino, lo que es casi más importante, mantener la curiosidad sostenida en el tiempo.

Invertir tiempo y dinero en aprender es una inversión que, por lo general, se recupera con creces con el consiguiente aumento de ingresos y mejores condiciones en el puesto de trabajo.

2.- Adoptar una mentalidad de crecimiento y desarrollo personal

Este consejo está muy relacionado con el punto anterior y ha sido desarrollado por la psicóloga Carol Dweck. Se trata de adquirir una mentalidad de crecimiento en la que los individuos valoran más el esfuerzo y la superación de las fronteras o límites mentales e intelectuales que la inteligencia natural.

Si valoramos solo lo segundo, según Dweck, se llega a una situación de estancamiento, que ella denomina mentalidad "fija". Valorando la capacidad de trabajo y el esfuerzo, se adopta una mentalidad de "crecimiento". A largo plazo las personas con más capacidad de crecimiento acaban superando en inteligencia y saber a aquellas personas que por naturaleza son inteligentes pero que no se esfuerzan tanto por crecer y desarrollarse.

Dweck afirma que esta tendencia a considerar las habilidades como fijas o no modificables tiene un profundo impacto en muchas áreas de la vida de una persona, especialmente en la motivación de los niños y profesores. En este pequeño vídeo puedes ver como explica su teoría en español.

Más allá del "rollo" bien intencionado, cultivar una mentalidad de crecimiento, también llamada adaptable, puede ayudarte a centrarte más en los objetivos que más quieras en la vida. Además, puede influir significativamente en tu motivación y hacerte más capaz de detectar oportunidades para aprender y aumentar tus habilidades.

La capacidad de mantener una mentalidad abierta, adquirir un mejor conocimiento y aplicarlo cuando sea necesario puede mejorar exponencialmente tu vida profesional como programador.

3.- Leer mucho

Leer, especialmente en formato largo, es para la mente lo que el ejercicio es para el cuerpo. Nos da la libertad de vagar por el espacio, el tiempo, la historia, y ofrecer una visión más profunda de las ideas, conceptos, emociones y el cuerpo de conocimientos.

El cerebro conectado a un libro se mantiene activo, crece, cambia y establece nuevas conexiones y patrones diferentes, dependiendo del tipo de material que estés leyendo. Los mejores alumnos leen mucho. Y no necesariamente libros técnicos (solamente).

De hecho, muchas de las personas más exitosas del mundo empresarial y del software comparten esta afición por la lectura - no conciben la lectura como una obligación sino como una oportunidad para mejorar sus vidas, sus trayectorias profesionales y sus empresas.

Elon Musk creció leyendo dos libros al día, según su hermano. Bill Gates lee 50 libros al año. Mark Zuckerberg lee al menos un libro cada dos semanas. Warren Buffett pasa de cinco a seis horas al día leyendo cinco periódicos y 500 páginas de informes corporativos. Houdini, Keith Richards, Oprah Winfrey o Diane Keaton son otras personalidades de éxito que tienen o tenían en común ser ratones de biblioteca.

4.- Enseñar a los demás tus conocimientos

Según algunos estudios, los alumnos retienen aproximadamente el 90% de lo que aprenden cuando explican/enseñan el concepto a otra persona, o lo usan inmediatamente.

Enseñar a otros lo que sabes es una de las formas más efectivas de aprender, memorizar y retener nueva información. Los psicólogos lo llaman "práctica de recuperación". Es una de las formas más fiables de desarrollar una memoria más fuerte.

Aprender enseñándole a otra persona un tema en términos simples te ayuda a identificar rápidamente tus propias lagunas de conocimiento.

La prueba definitiva de tu nivel de conocimiento es tu capacidad de transferirlo a otra persona. Una mejor forma de aprender, procesar, retener y recordar información es dedicarte a aprender y compartir esos conocimientos antes de seguir avanzando en la materia.

Por ejemplo, en lugar de completar un curso de programación sin parar, ponte como objetivo hacer la mitad del curso y luego comparte lo aprendido con los demás antes de continuar. Es una buena forma de apuntalar los conocimientos adquiridos de forma permanente en tu cabeza y de identificar lagunas.

Conclusión

Además de estos 4 consejos que deberías incorporar a tu vida en forma de hábitos si quieres aprender cosas de forma más rápida, hay otra serie de cosas que son importantes a la hora de aprender a programar y ser mejor programador como lo son los tiempos de desconexión, el tener una buena alimentación y aficiones que al margen del desarrollo de software.

Es un tema que tratamos ya de manera extensa en el artículo Cómo ser mejor programador (aparte de programando), y que no tiene sentido volver a repetir aquí.

Todos estos consejos son aplicables a todas las demás profesiones que exigen una formación continua, tan crucial para el éxito de cualquier profesional que se dedique al desarrollo de software.

Si eres programador y quieres compartir tus trucos para aprender cosas de forma más rápida y con más poso, no dudes en compartir tus consejos en la zona de comentarios.

Si desarrollas con Java, o lo has hecho en algún momento de los últimos años, seguramente te suene Spring Framework, aunque sea de oídas.

Spring Framework es un framework Open Source que facilita la creación de aplicaciones de todo tipo en Java, Kotlin y Groovy.

Si bien es cierto que, por lo que es más conocido es por la inyección de dependencias, Spring Framework está dividido en diversos módulos que podemos utilizar, ofreciéndonos muchas más funcionalidades:

• Core container: proporciona inyección de dependencias e inversión de control.
• Web: nos permite crear controladores Web, tanto de vistas MVC como aplicaciones REST.
• Acceso a datos: abstracciones sobre JDBC, ORMs como Hibernate, sistemas OXM (Object XML Mappers), JSM y transacciones.
• Programación orientada a Aspectos (AOP): ofrece el soporte para aspectos.
• Instrumentación: proporciona soporte para la instrumentación de clases.
• Pruebas de código: contiene un framework de testing, con soporte para JUnit y TestNG y todo lo necesario para probar los mecanismos de Spring.

Estos módulos son opcionales, por lo que podemos utilizar los que necesitemos sin tener que llenar nuestro classpath con clases que no vamos a usar.

Razones para usar Spring

Aunque no sea una característica única de Spring, el uso de inyección de dependencias facilita la programación contra interfaz, permitiendo a los distintos componentes depender únicamente de interfaces y produciendo así un código menos acoplado. No solo eso, también permite implementar el patrón singleton de una forma extremadamente sencilla (por defecto, las dependencias que inyectamos son singletons).

Hay cientos de tecnologías que Spring permite integrar. Desde bibliotecas que implementan opentracing hasta las que nos generan métricas para nuestra aplicación, pasando por serialización/deserialización a JSON y XML, seguridad con OAuth2 o programación reactiva entre otras.

En general, Spring aumenta la productividad y reduce la fricción al ofrecernos abstracciones sobre implementaciones de tecnologías concretas. Un ejemplo claro es el de spring-data, que nos permite definir el acceso a base de datos con interfaces Java. Esto lo consigue parseando el nombre de los métodos y generando la consulta con la sintaxis específica para el driver que utilicemos. Por ejemplo, cambiar nuestra aplicación de MySQL a PostgreSQL es tan sencillo como cambiar el driver: Spring se encarga de la sintaxis de forma transparente.

A pesar de "la magia de Spring" 🧙🏻‍♂️, como muchos lo llaman, Spring nos permite desactivar estos "comportamientos mágicos" en caso de ser necesario, por lo que podemos tomar el control cuando necesitemos más granularidad. Siguiendo con el ejemplo de spring-data, este control sería necesario si tenemos que realizar consultas mucho más complejas que un SELECT * BY name. En esos casos, entre otras opciones, podemos anotar nuestro método con @Query y escribir la consulta que deseemos. Ya no hay magia 😉

Por lo general, Spring no obliga a implementar ni extender nada, lo que nos permite escribir código que es "agnóstico" del framework. De esta forma, desarrolladores con cero o muy poco conocimiento de Spring pueden realizar su trabajo sin mayores complicaciones.

Spring es de código abierto y tiene una gran comunidad detrás. Si encuentras un bug, echas en falta una funcionalidad o lo que sea, siempre puedes abrir un ticket o contribuir por tu cuenta.

¿Pero no íbamos a hablar de Spring Boot?

Hasta ahora he hablado de Spring Framework en general, pero el título de esta entrada menciona Spring Boot, así que voy a presentarlo.

Si bien es cierto que Spring Framework es muy potente, la configuración inicial y la preparación de las aplicaciones para producción son tareas bastante tediosas. Spring Boot simplifica el proceso al máximo gracias a sus dos principales mecanismos.

Contenedor de aplicaciones integrado

Spring Boot permite compilar nuestras aplicaciones Web como un archivo .jar que podemos ejecutar como una aplicación Java normal (como alternativa a un archivo .war, que desplegaríamos en un servidor de aplicaciones como Tomcat).

Esto lo consigue integrando el servidor de aplicaciones en el propio .jar y levantándolo cuando arrancamos la aplicación. De esta forma, podemos distribuir nuestras aplicaciones de una forma mucho más sencilla, al poder configurar el servidor junto con la aplicación. Esto también es muy útil en arquitecturas de microservicios, puesto que permite distribuir nuestras aplicaciones como imágenes Docker que podemos escalar horizontalmente (algo muy complicado con un .war).

Nota: Spring boot permite distribuir tu aplicación como un jar, no lo impone. Si prefieres desplegar tu aplicación en un servidor de aplicaciones tradicional, Spring Boot te deja compilar el código como un .war que no incluya ningún servidor de aplicaciones integrado.

Starters

Spring Boot nos proporciona una serie de dependencias, llamadas starters, que podemos añadir a nuestro proyecto dependiendo de lo que necesitemos: crear un controlador REST, acceder a una base de datos usando JDBC, conectar con una cola de mensajes Apache ActiveMQ, etc.

Una vez añadimos un starter, éste nos proporciona todas las dependencias que necesitamos, tanto de Spring como de terceros. Además, los starters vienen configurados con valores por defecto, que pretenden minimizar la necesidad de configuración a la hora de desarrollar. Un buen ejemplo es el de spring-boot-starter-actuator: una vez que añadimos la dependencia, nuestra aplicación empezará a generar métricas tanto de la JVM como de la aplicación en sí (latencias, errores, etc).

Al igual que con Spring Framework, cualquier configuración puede ser modificada de ser necesario: desde el puerto en el que la aplicación escucha peticiones, hasta el banner que sale por consola al arrancar la aplicación.

Hola Mundo con Spring Boot

Para demostrar lo fácil que es empezar a usar Spring Boot, vamos a ver el código necesario para crear nuestro primer "Hola mundo":

@SpringBootApplication
@RestController
public class Application {

    @GetMapping("/hello")
    public String hello() {
        return "Hello Bootiful!";
    }
}

Sencillo, ¿verdad?

Un poco más abajo te explico en un vídeo práctico cómo llegar a este código y qué significa.

Bonus tip: Spring Initializr

El equipo de Spring también ha creado Spring Initializr, una herramienta web que puedes utilizar para autogenerar el esqueleto de tu aplicación Spring Boot.

Se trata de un inicializador muy útil, ya que genera el pom.xml (o build.gradle), el main de la aplicación, y un test que comprueba que la aplicación arranca correctamente.

Vídeo práctico: "Hola Mundo" con Spring Boot

[youtube:UxMuZ-UPwrI]

Empezar a trabajar siempre es un gran desafío para cualquier persona. Puedes poseer las mejores destrezas técnicas como programador, pero eso no te convierte en el mejor programador en el ámbito profesional. Evidentemente ayuda, pero además de saber programar, hay que aprender muchas otras cosas para convertirse en un programador profesional.

Las empresas cuando contratan a un novato no pretenden obtener de él un retorno de la inversión desde el primer día. Saben que habrá un proceso de adaptación de meses o incluso años, así que lo mejor es hacerse a la idea y tomárselo como una nueva etapa que te ayudará a crecer profesionalmente a medio plazo.

Tampoco se trata de que no saques a relucir tu verdadera personalidad ni que te calles siempre. Este artículo no va de eso. Siempre hay momentos y contextos en los que podrás decir lo que piensas a cualquier jefe o compañero.

Lo que expondremos aquí son conductas que suelen reproducirse en programadores con poca experiencia y que las empresas preferirían que se minimizasen, por el bien de la empresa y también por tu propio crecimiento profesional.

Lo normal es tener estos hábitos, pero también lo habitual es corregirlos a medida que se va adquiriendo experiencia.

Tras años muchos de experiencia trabajando con programadores noveles, he decidido recopilar aquellas conductas que más se repiten y que no ayudan ni a la rentabilidad de la empresa, ni al propio desarrollo de un programador inexperto que busca crecer profesionalmente. Además, he completado el listado con otras opiniones vertidas en foros sobre el tema.

De la A a la Z: Hábitos que se deben mejorar (si los tienes)

A) Ir de sabelotodo. No te aferres al sentimiento de inseguridad de que tienes que saberlo todo. No lo sabes todo. Y eso está bien, es lo esperable.

B) No saber decir que no cuando sea lo razonable. Como programador tienes que aprender a decir que no. "No puedo ir a la reunión", "no puedo hacer eso en ese plazo", "esa funcionalidad no sé hacerla"... Decir que no puede suponer un pequeño inconveniente a corto plazo, pero a la larga ganarás fiabilidad y tus compañeros confiarán más en ti.

C) Actuar a la defensiva cuando alguien critica tu código. Los mejores y más expertos desarrolladores están dispuestos a tener una conversación abierta y franca sobre el código que han desarrollado y cómo puede ser mejorado.

D) Rendirse demasiado pronto. Hay demasiados programadores que se acercan mucho a una solución, para luego darse por vencidos justo antes de que estén a punto de resolver el problema. No rendirse nunca es una aptitud fundamental para un programador.

E) Negarse a pedir ayuda. El simple hecho de exponer tu problema de programación a otra persona, a menudo te ayudará a descubrir la solución, incluso por tu cuenta.

F) Echar la culpa a los demás. El desarrollador más valioso es el que toma la iniciativa y la responsabilidad del código que escribe.

G) Optimización prematura, o sea, escribir código que optimice otro código antes de ser necesario. En muchos casos, la ventaja de rendimiento que se obtiene al optimizar tanto el código no compensa porque se vuelve difícil de entender por los demás compañeros, complicando su mantenimiento en el futuro.

H) Hacer caso omiso de las opiniones de otros desarrolladores. Una de las mejores maneras de aprender y crecer como desarrollador es revisar a pares el software con desarrolladores que tengan más experiencia que tú. Busca las opiniones de otras personas con más experiencia.

I) No saber cómo optimizar código. Hay algunas situaciones en las que el rendimiento es un gran problema, como por ejemplo problemas del tipo:

• Complejidad algorítmica
• Operaciones ineficientes de la base de datos
• APIs de terceros
• Consultas N+1

Cuando surgen problemas de rendimiento, es necesario saber cómo analizarlos, entender qué es lo que está consumiendo tiempo y cómo solucionar los problemas. Y esto requiere experiencia, y saber hacerlo en el momento oportuno (ver letra G :wink:).

J) Infravalorar las relaciones con los demás miembros del equipo. Se te contrata para escribir código. Pero también necesitas ser capaz de interactuar con otros miembros del equipo. El saber desarrollar en equipo es muy importante y la comunicación tanto o más.

K) Hacer la guerra dentro de la empresa contra otros departamentos. En ocasiones, otros equipos de desarrollo tomarán decisiones que tú crees que son equivocadas. Pero mientras puedas lograr los objetivos de tu equipo, es mejor trabajar simplemente en torno a las "caprichos" de otros equipos, en lugar de luchar contra ellos con demasiada fuerza.

Recuerda que muchas veces la respuesta a "¿Qué clase de idiota ha hecho esto?" es "Un tipo inteligente y con la mejor intención, teniendo que llegar a compromisos que ni siquiera se me habían ocurrido".

L) Paralizarse bajo presión. Cuando se opera en un escenario en el que los usuarios finales no pueden utilizar el software, se produce un montón de presión. Es necesario que uno sea capaz de seguir programando con calma y terminar el trabajo.

M) Ser incapaz de escribir código malo. En el mundo real, hay veces en los que compensa que no todo vaya perfecto en situaciones como:

• Fechas límite.
• Experimentos.
• Errores urgentes que deben ser arreglados inmediatamente.

Se necesita poseer la mentalidad de que está bien escribir un código malo para cumplir con las exigencias impuestas.

Recuerda: lo perfecto es lo enemigo de lo bueno.

N) No tener en cuenta la opinión del usuario. Si despreciar la opinión de tus colegas es malo, desoír los comentarios de los usuarios cuando estás haciendo una aplicación para usuario final es un grave error. Nunca deberías tomar decisiones de forma unilateral. 

Ñ) Escribir demasiados o no suficientes comentarios en el código. Los comentarios son notas esenciales para los desarrolladores. Pero como todo, se deben usar con moderación.

O) Usar herramientas equivocadas para los proyectos. No tomes decisiones basadas en "es lo que yo sé". Es necesario estar abiertos a utilizar diferentes tecnologías, lenguajes y entornos de desarrollo.

P) No mantener un buen dominio sobre tus herramientas de programación. Dado que pasarás muchas horas usando cosas como editores de texto, línea de comandos y otras herramientas para escribir código, es esencial dominarlas. Al igual que el sistema operativo, claro. Tómate el tiempo necesario para aprender los trucos y consejos que te hacen más eficiente y para estar actualizado. Te sorprendería saber cuántos programadores no dominan ni sus herramientas ni siquiera el sistema operativo.

Q) Obviar los mensajes de error. Los errores de código ocurren con frecuencia. También suelen incluir información muy valiosa sobre lo que ha fallado, por qué ha sucedido y qué líneas han desencadenado los problemas. Se deben investigar los mensajes de error, en lugar de tratar de eludirlos.

R) Contar las horas. Los mejores desarrolladores disfrutan del tiempo que pasan programando y se sumergen en él. Si no sientes una especie de evasión placentera programando, algo no funciona, aunque lleves años programando.

S) Negarse a aprender de los errores. Esto es contraproducente. Cuando ocurren errores, simplemente aléjate del contexto y piensa en estas tres cosas:

• ¿Cuál fue la causa última del error?
• ¿Podrían ponerse en práctica procesos o comportamientos para evitar que este tipo de errores ocurra en el futuro?
• ¿Se podría detectar el error antes y tener menos impacto?

Negarse a aprender de tus errores hará que los repitas.

T) Tener miedo de desechar código. Ten en cuenta que pasar tres días programando una solución incorrecta te enseñará más que si caes víctima de la parálisis por análisis.

U) Idealizar tu juego de herramientas de desarrollo. A algunos desarrolladores les encanta el editor de texto "vim". Otros lo odian y aman el editor de texto "emacs", o Atom, o Visual Studio Code... Pero habrá escenarios en los que tenga sentido usar unos en vez de los otros. El caso es no cerrarse en banda.

V) No compartir con la comunidad. Deberías unirte a la comunidad de programación en lugares como Github o Stackoverflow tan pronto como sea posible, aparte de en tus comunidades locales si el tiempo te lo permite. Si lo haces, te darás cuenta de lo útil y amigable que es.

W) Pedir disculpas constantemente por mal código. Si descubres que te estás disculpando continuamente por un código lleno de errores, podría significar que necesitas volver a evaluar tus plazos (o tus conocimientos).

X) No invertir la energía suficiente en pruebas de código. El equipo de desarrollo está en esto junto y es responsabilidad de cada miembro del equipo asegurarse de que el código con el que todos los demás miembros contribuyen está a la altura del nivel del equipo.

Y) Diferenciar entre buenas prácticas y estilos de programación. A los programadores sin experiencia les cuesta distinguir si su mentor le está enseñando buenas prácticas o lo está convirtiendo en un "miniyo".

Z) Aferrarse a un plan bien pensado que claramente no está funcionando. La única cosa peor que abandonar un plan en el último minuto es negarse a dejar de ejecutar una mala idea.

Conclusión

La clave para mejorar como desarrollador o como cualquier otro tipo de profesional es seguir estos tres pasos:

1. Reconocer que tienes malos hábitos.
2. Encontrar la motivación para cambiarlos.
3. Poner en práctica esa motivación eliminando los malos hábitos y practicando los buenos.

¡Es fácil decirlo pero no hacerlo!

Si se te ocurren otros hábitos que es preferible evitar cuando empiezas a trabajar como programador, o quieres compartir tu propia experiencia, te invito a que lo hagas en los comentarios.

Además te recomendamos:

• Los 7 pecados capitales del programador novato
• Los 10 problemas más comunes a los que deben hacer frente los programadores novatos
• 5 errores que suponen el despido inmediato de un programador

No hace mucho escribí en este blog una entrada describiendo qué son las pruebas de software. En ella planteaba qué son las pruebas de software y por qué son importantes, dando una visión superficial de algunos de los tipos de pruebas de software que existen. Si aun no la has leído te recomiendo leerla antes de continuar.

Asumiendo la gran variedad y cantidad de pruebas que existen a la hora de desarrollar software, es fácil perder la visión sobre qué está en el tejado de quién durante el ciclo de vida de un sistema. Como desarrolladores, las cuestiones de hasta dónde debemos llegar y qué escapa a nuestro control o responsabilidades, suele ser algo bastante difuso. Sin embargo, existe consenso en torno a que los desarrolladores, como mínimo, debemos desarrollar 3 tipos de pruebas sobre el código:

• Pruebas unitarias
• Pruebas de integración
• Pruebas funcionales

Existen otros tipos de pruebas que habitualmente pueden ser responsabilidad de los desarrolladores, pero ya no es algo tan aceptado y depende de a quién preguntes, te dirá una cosa u otra.

Vamos a darle un repaso a estas tres, las más importantes, para ver en qué consisten y qué implicaciones tienen para el desarrollador.

Pruebas unitarias

El primero de los grupos, las pruebas unitarias, es como se conoce a todas esas pruebas que solo comprueban una funcionalidad específica de una única clase. A este tipo de pruebas "les da igual" el comportamiento del resto, ya que la gran mayoría de las veces reciben un objeto que simula el comportamiento externo a esa clase, necesario para funcionar.

La finalidad última de las pruebas unitarias es comprobar funcionalidades muy concretas de cada clase.

Son pruebas que no deberían costarnos más de 5 minutos escribir, y de las cuales vamos a tener tantas como sea necesario para probar el 100% (o lo máximo posible al menos) de los posibles casos que estén contemplados en el código.

Por ejemplo, el hecho de comprobar que un método lanza una excepción en una condición concreta es un caso claro de prueba unitaria.

De este tipo de pruebas se espera que sean rapidísimas de ejecutar, ya que en un proyecto grande habitualmente habrá cientos (¡o incluso miles!) de éstas. Sin ir más lejos, el framework de simulación Moq tiene 2.843 pruebas unitarias, y cada una tarda en ejecutarse del orden de milisegundos.

Pruebas de integración

El segundo de los grupos, las pruebas de integración, es como conocemos a todas esas pruebas que verifican que las relaciones existentes entre las diferentes clases y servicios funcionan correctamente.

Este tipo de pruebas lo que busca es encontrar todos esos problemas que surgen al mezclar las diferentes capas de nuestra aplicación.

Por ejemplo, si trabajamos con una base de datos, en una prueba de integración utilizaremos un motor de base de datos real y no uno en memoria o simulado. De este modo validaremos la correcta integración de nuestro sistema con esa base de datos.

En este tipo de pruebas es posible utilizar simulaciones para algunos niveles que todavía no se pueden probar, como por ejemplo un servicio de terceros.

Suelen ser pruebas más costosas de desarrollar y ejecutar que las pruebas unitarias ya que en cada una de ellas se deben integrar varios puntos del sistema para asegurar que funcionan correctamente en conjunto.

Pruebas funcionales

Las pruebas funcionales verifican el comportamiento del sistema para afirmar que se cumple con la funcionalidad completa. Se les suele denominar también pruebas End-To-End o E2E.

Este tipo de pruebas se realizan con los requisitos de funcionamiento en la mano, y no se centran en los pormenores del sistema, que ya deberían estar probados con los dos grupos anteriores.

Por lo general, son pruebas que requieren de más esfuerzo que las anteriores, ya que en ellas debemos probar el funcionamiento completo del sistema en base a los requisitos existentes. Por esto debemos utilizar el mismo tipo de sistemas que utilizará el código en producción.

Además, es habitual que se hagan pruebas específicas para evaluar el rendimiento y comprobar que está dentro de los parámetros deseados.

Un ejemplo de pruebas funcionales podría ser cuando en ASP.NET Core utilizamos TestServer*, de modo que estamos probando que el funcionamiento completo es correcto: desde el enrutado hasta la conexión a una base de datos (pasando por cada uno de los componentes internos).

* TestServer es una clase incluida en ASP.NET Core que nos proporciona un servidor completo, con toda la aplicación en memoria, para poder probarla con gran rendimiento y sin necesidad de configurar y desplegar un servidor completo real.

Relación entre tipos de pruebas

A la hora de desarrollar los diferentes grupos de pruebas, como en casi todo, debemos aplicar el sentido común para conseguir probar el máximo código posible con el menor esfuerzo.

Por ejemplo, no siempre tiene mucho sentido intentar cubrir con pruebas funcionales el 100% de las posibilidades de una clase concreta. El motivo es que, además de que muchas veces no es ni siquiera posible, hacerlo aumentaría enormemente los costes.

En relación a cómo debería ser la cantidad de código a probar, se suele representar como una pirámide en la que las pruebas unitarias constituyen su base, y las pruebas funcionales están en la cúspide:

Esta pirámide se llama pirámide de testing o pirámide de Cohn (se atribuye a Mike Cohn aunque nunca ha quedado clara su autoría). Lo que nos intenta transmitir es que, aunque debes usar el sentido común para cada caso, en general siempre debe haber muchas más pruebas unitarias que de integración y muchas más que test funcionales.

De hecho, si dentro de los test funcionales tuviésemos pruebas de la interfaz de usuario (también llamados test End to End o E2E), estos deberemos mantenerlos al mínimo. El motivo es que este tipo de test, aunque suelen aportan bastante valor, son muy costosos de crear, pero sobre todo, son muy costosos de mantener y no conviene abusar de ellos.

Atraer talento no basta, hay que ayudar a desarrollarlo

Con captar talento no basta. Las empresas de programación necesitan necesariamente tener programas y planes de desarrollo profesional para sus empleados durante buena parte de su trayectoria.

Muchos profesionales del sector de la programación con experiencia son conscientes de lo que necesitan hacer para avanzar en su carrera, pero simplemente carecen del tiempo necesarios para planificar sus planes de desarrollo profesional y, lo que es más importante, ejecutarlos.

Ayudar a los programadores en la planificación de sus carreras profesionales y proporcionarles un ejemplo de trayectorias profesionales de otros compañeros dentro de la empresa, puede ser una de las principales formas en que las empresas pueden involucrar a su personal y hacer que se entusiasmen más por quedarse y aportar más dentro de la empresa.

A menudo, las personas cualificadas dejan sus empresas porque no son conscientes de la amplia gama de posibilidades de desarrollo profesional que se les ofrecen. Es posible que sólo sean conscientes de los puestos de trabajo dentro de su función o unidad, y se desalientan si no ven nada para cumplir sus propios objetivos profesionales.

Ciertamente, todo el mundo debería asumir como propio el desarrollo de su trayectoria profesional, pero las empresas pueden proporcionar valiosos recursos para ayudar a los programadores en esta importante empresa.

Es aquí donde los departamentos de recursos humanos desempeñan un papel fundamental. Son los responsables de planificar los planes de carrera de los programadores y de motivarles para que los lleven a cabo ofreciéndoles recursos, tiempo y nuevos cargos, salarios y responsabilidades a medida que avanzan.

Cómo y cuándo debe la empresa empezar con el proceso de planificación de la carrera profesional de los programadores

En realidad, hay dos áreas de trabajo principales en relación con los planes de desarrollo profesional por parte de los departamentos de recursos humanos.

Crear un procedimiento incluyendo ejemplos reales

El primer paso es proporcionar un procedimiento junto con una herramienta que muestre varios ejemplos del desarrollo profesional de algunos compañeros y que hayan tenido éxito dentro de la empresa.

Esto incluso podría ser una gran herramienta para atraer a los programadores. Para un candidato con múltiples ofertas, la propuesta de valor de la ayuda para el desarrollo profesional podría suponer un punto de inflexión en la decisión.

Medidas a largo plazo para el desarrollo profesional

En cuanto a la participación de los programadores de la empresa en su propio proceso de planificación de su desarrollo profesional, podría hacerse de forma anual o semestral e incorporarse a los procesos de evaluación del desempeño de la empresa ya existentes.

Casi todas las corporaciones tienen un proceso anual o semestral en el que los responsables se sientan con los empleados y revisan las competencias requeridas para su puesto de trabajo, las competencias en las que son más débiles, y ponen en marcha planes para mejorar esas competencias.

Pero es necesario añadir a ese proceso un horizonte profesional más largo. Además de considerar la mejora de las aptitudes para el puesto en el que se encuentran actualmente, los empleados deberían considerar dónde pueden querer estar en 2, 5 o 10 años y las diferentes acciones que pueden realizar hoy para empezar a desarrollar su carrera a más largo plazo y hacerse, en última instancia, más valiosos para la empresa.

El plan ideal de desarrollo anual o semestral de los empleados debería reflejar una buena combinación de desarrollo a corto y largo plazo.

Dada la inestabilidad del mercado actual y la alta movilidad y rotación de los programadores, ¿por qué deberían las empresas invertir en los planes de carrera?

Esto es una pregunta muy habitual que se hacen los directivos de las empresas y una batalla que se debe librar desde el departamento de recursos humanos para intentar convencer al resto de la organización.

Ayudar a los programadores con el desarrollo de su carrera profesional es una de las inversiones más sabias que las empresas pueden hacer, especialmente en los tiempos que corren.

La mayoría de las empresas no se dan cuenta de que sus mayores inversiones no son en plantas y máquinas, inventario o propiedades; sino que el mayor gasto de la mayoría de las empresas de nuestro sector es en pagar al personal.

El capital humano es el recurso más caro y más crítico para el éxito de una empresa. Y los empleados comprometidos, a menudo pueden proporcionar la ventaja competitiva que se necesita en un entorno en el que suele ser difícil diferenciarse de los competidores.

Muchos estudios recientes, incluidos los de la prestigiosa SHRM, señalan que la satisfacción o el compromiso de los empleados está actualmente en su nivel más bajo, y que más de un tercio de los empleados planean buscar un nuevo trabajo fuera de su empresa actual.

Y no serán los de menor rendimiento los que busquen algo mejor y se vayan... Lo más habitual es que sean los de mayor talento.

La pérdida de productividad de los empleados no comprometidos que trabajan muy por debajo de su nivel máximo puede costar a las empresas millones de euros.

Y si una persona cualificada cotizada por el mercado se va de la empresa, le puede costar a la empresa más de un año de salario en costes de reclutamiento y contratación de un sustituto.

A menudo, el coste de un programa de desarrollo profesional para una empresa puede recuperarse con solo retener a una persona que de otra manera se habría ido.

¿Qué debe incluir un plan de desarrollo profesional para desarrolladores de software?

Formación continua en diferentes formatos

En su mayoría, los desarrolladores de software piensan que la capacidad de seguir aprendiendo es su forma preferida de crecer en su profesión. Esto puede incluir el deseo de aprender un nuevo lenguaje o framework de programación, desarrollar una nueva habilidad, o incluso cambiar su trayectoria profesional.

Teniendo en cuenta la importancia del desarrollo profesional, aquí hay algunas cosas que debería presupuestar para permitir que los desarrolladores continúen aprendiendo:

• Talleres de programación
• Seminarios de programación
• Cursos/certificaciones online
• Conferencias técnicas
• Meetups
• Libros/revistas especializadas
• El software o hardware necesario
• Traer a ponentes expertos a la empresa

La posibilidad de trabajar en proyectos personales o paralelos

Si un desarrollador no tiene la posibilidad de trabajar en proyectos nuevos o emocionantes, probablemente se aburrirá y buscará cambiar de trabajo (o de departamento/equipo, dependiendo del tamaño de la empresa).

Una manera de combatir esto (y permitir que los desarrolladores aprendan nuevas habilidades y crezcan en su carrera) es darles tiempo para trabajar en otros proyectos. Esto puede incluir dejarles contribuir a proyectos de código abierto, darles tiempo para trabajar en su propia app o side project, o hacer que ayuden con algo fuera de sus obligaciones laborales habituales.

Muchas empresas también hacen que sus equipos de tecnología dediquen parte de su tiempo a escribir en blogs sobre los proyectos en los que están trabajando para crear una cultura de aprendizaje.

Desarrollo de habilidades no técnicas (habilidades blandas)

No todos los desarrolladores quieren convertirse en CTO o CEO, pero aquellos que sí quieren deben sentirse apoyados en esa senda de crecimiento.

Los programadores que buscan asumir más responsabilidades de gestión o liderazgo (como el de convertirse en un jefe de producto), deberían estar debidamente capacitados en esas áreas. Esto puede incluir oportunidades como traer un entrenador de liderazgo, ofrecer formación para los directivos noveles o programas de tutoría.

Para aquellos que no están buscando crecer hacia un rol de gestión o ejecutivo, existen todavía muchas habilidades no técnicas que podrían aprender. Esto podría incluir programas que ayuden a mejorar sus habilidades blandas, habilidades de comunicación, habilidades de gestión de proyectos y más.

Una última reflexión

Hay que destacar que uno de los elementos más importantes en los planes de carrera son las diferentes habilidades transferibles que una persona ha adquirido a lo largo de su carrera.

A menudo los títulos de los puestos y las responsabilidades cambian, pero aun así una habilidad clave adquirida dentro de un puesto o sector totalmente diferente podría seguir siendo transferible y deseable en un entorno totalmente nuevo.

Por ejemplo, un programador de software para autómatas puede estar adquiriendo aptitudes clave de que luego pueden ser transferibles a un tipo de programación distinto.

Las personas nunca deben minimizar su experiencia laboral inicial pasada, sin importar cuán insignificante consideren que haya sido el puesto. En cualquier puesto se pueden adquirir múltiples aptitudes clave. Aprender a trabajar es una de ellas :smile:

Cuando el navegador no puede cargar una imagen, suele mostrar una imagen de un icono de imagen rota genérico. Aunque este tipo de elementos no se suelen modificar, puede haber casos concretos en los que nos interese hacerlo, por ejemplo, en una web con contenidos generados por el usuario donde se quiere destacar bien este hecho, en sistemas gestores de contenido en los que ciertas imágenes (por ejemplo ornamentales para la cabecera) son opcionales y les quieres dar un aspecto por defecto si no están, o simplemente porque quieres cuidar hasta el más mínimo detalle del diseño de la web.

Veamos un ejemplo práctico con esta imagen:

<img class="imagen-rota-especial" 
     src="img/imagen-que-no-existe.png"
     alt="Este es el texto alternativo de la Imagen rota" />

Si la imagen no existe en la ruta que se indica en el atributo src, se verá algo así, un icono acompañado del texto alternativo del atributo alt (si lo tiene):

Entre lo más básico que podríamos hacerle estaría ponerle el texto en color, en este caso rojo:

img {
    color:red;
}

También podríamos ponerle el fondo de color:

img {
    background-color:red;
}

Pero nos puede dar problemas si vamos a usar imágenes con canal alpha, como PNGs transparentes:

Usando :before en la imagen rota

Hay una solución mucho más eficiente y que permite más opciones de personalización a través de los pseudoelementos :before y :after. Como norma general, en las imágenes no se pueden utilizar estos pseudoelementos porque las imágenes son elementos externos al documento, lo explica muy bien nuestro tutor José Manuel Alarcón en este post de su blog técnico.

Pero cuando el enlace a la imagen está roto, sí que se pueden usar, al menos en los navegadores de escritorio más comunes.

En primer lugar definimos el tamaño de la imagen y la posicionamos de forma relativa...

img {
    display:block;
    position:relative;
    width:fit-content;
    height: fit-content;
    min-width:250px;
    min-height:80px;
    font-family: 'Open Sans', sans-serif;
    font-size:15px;
}

...posicionamos el :before encima de la imagen rota de forma absoluta:

img:before {
    /*Solo se muestra en imágenes rotas*/
    display:block;
    box-sizing: border-box;
    content: "\0026A0  Imagen rota: \A" attr(src);
    white-space: pre-wrap;
    position: absolute;
    background-color:red;
    color:#fff;
    text-align:center;
    top:0;
    left:0;
    right:0;
    bottom:0;
    padding:20px;
}

...y se vería así:

Al no poder cargarse la imagen, se muestra el pseudoelemento :before que contiene un símbolo de peligro, el mensaje "Imagen rota" y el contenido del atributo src gracias a la función attr(), que nos permite utilizar en contentel contenido de cualquier atributo. Al visualizar la ruta, podemos identificar mucho mejor qué imagen está fallando sin tener que ir al código fuente.

Combinando :before y :after

Pero además de :before, podemos usar :after, así que vamos a montar un aviso más completo y, de paso, con colores más discretos. Esta vez, además de usar el atributo src usaremos el contenido del atributo alt:

De nuevo posicionamos la imagen en relativo y ya le aplicamos los estilos comunes de texto:

img {
    display:block;
    box-sizing: border-box;
    position:relative;
    width:100%;
    max-width:fit-content;
    min-width:350px;
    height: fit-content;
    min-height:120px;
    font-family: 'Open Sans', sans-serif;
    font-size:14px;
    border:0;
    padding:10px;
}

Y posicionamos de forma absoluta el :before arriba y el :after abajo. Ojo con las alturas, porque el color de fondo y los bordes deben ir en los pseudoelementos:

img:before {
    /*Solo se muestra en imágenes rotas*/
    display:block;
    box-sizing: border-box;
    content: "\0026A0  Imagen rota \A";
    white-space: pre-wrap;
    position: absolute;
    color:#333;
    text-align:center;
    top:0;
    left:0;
    right:0;
    padding:20px 20px 10px;
    height:61px;
    border: 1px solid #ccc;
    border-bottom:0;
    border-radius: 5px 5px 0 0;
    background-color:#eee;
    font-weight:bold;
    font-size:18px;

}

img:after {
    /*Solo se muestra en imágenes rotas*/
    display:block;
    box-sizing: border-box;
    content: attr(alt) "\A (Ruta: " attr(src)")";
    white-space: pre-wrap;
    position: absolute;
    color:#333;
    text-align:center;
    left:0;
    right:0;
    bottom:0;
    padding:0px 20px 20px;
    min-height:61px;
    border: 1px solid #ccc;
    border-top:0;
    background-color:#eee;
    border-radius: 0 0 5px 5px;
}

Y nos quedaría así:

En cualquiera de las dos soluciones el punto clave es posicionar la imagen comorelative para poder situar en absolute cualquier pseudoelemento que usemos. O lo que es lo mismo, usaremos los pseudoelementos para tapar el icono y el alt que se muestran por defecto.

Bola extra: Para poder hacer retornos de carro dentro del content tienes que usar el caracter unicode escapado \A y que el pseudoelemento tenga definida la propiedad white-space con los valores pre o pre-wrap

Ten cuidado, porque probablemente tendrás que aplicar anchos y alturas fijas, o al menos definir bien valores mínimos y máximos. Valora en todo momento cómo necesitas que fluya el contenido y vigila que los pseudoelementos no se te superpongan a otros contenidos.

Método alternativo: poner una imagen por defecto con <object>

Esta solución personalmente no me gusta tanto porque supone modificar el codigo HTML, pero la comento por si le puede resultar útil a alguien.

Podemos usar una imagen por defecto si insertamos la imagen como un elemento <object> en vez de usar <img>.

Importante: En el atributo data especificaremos la ruta a la imagen y en el atributo type el tipo de imagen. Dentro del <object> irá la imagen de sustitución.

Sería algo así:

<object data="img/logo-campusmvp-azul.png" type="image/png"><img src="img/falta-imagen.jpg" alt="Aquí falta una imagen" /></object>

Y se vería la imagen logo-campusmvp-azul.png:

En cambio, si la imagen del object no existe:

<object data="img/imagen-que-no-existe.png" type="image/png"><img src="img/falta-imagen.jpg" alt="Aquí falta una imagen" /></object>

...se vería la imagen de sustitución img/falta-imagen.jpg:

Espero que este post te haya resultado útil. Te dejo todos estos ejemplos comprimidos dentro de este archivo .zip (52KB). Si tienes alguna duda o quieres aportar algo, no dejes de escribir tu comentario.

La cantidad de dinero que ingresamos en nuestras nóminas depende de muchos factores, la mayoría de ellos bastante obvios.

Todos sabemos que cursar ciertos estudios, adquirir experiencia en el trabajo y demostrar capacidad de liderazgo pueden aumentar nuestros sueldos. Pero, ¿sabías que la cantidad que ganas también puede depender de tu tipo de personalidad?

A las personas que trabajamos en la industria del software nos insisten muchísimo en la mejora continua de las habilidades blandas y demás cosas al margen de nuestras labores técnicas.

Los departamentos de RRHH invierten muchísimo dinero en cursos para intentar mejorar la comunicación, la asertividad y las habilidades de liderazgo en general de los equipos técnicos.

Es cierto que en otros sectores también se hace coaching y formación de este tipo, pero se hace más incidencia en otro tipo de temas. Por ejemplo, para equipos comerciales se suelen encargar cursos relacionados con la gestión del tiempo, con las técnicas de venta o con cómo hablar en público.

Según la industria de que se trate, la formación en habilidades blandas es distinta, ya que en cada sector predominan unos tipos de personalidad sobre otros, y además las necesidades formativas y de mejora son distintas por la naturaleza del trabajo.

En términos generales, un buen programador probablemente gestione mejor su tiempo que un buen vendedor, pero un buen vendedor probablemente sea más extrovertido y tenga mejores dotes comunicativas.

En este artículo nos pararemos a analizar los tipos de personalidad que predominan en la industria del software por un lado, y por otro cómo afectan estos tipos de personalidad a los salarios en general. Por último, intentaremos deducir si los tipos de personalidad con mayores ingresos en el mercado en general se puede trasladar al sector de la programación.

¿Tipos de personalidad? ¿De qué va esto?

Antes de nada, explicaré brevemente de dónde viene toda esta teoría de los tipos de personalidad.

Aunque la teoría de Myers y Briggs no se utiliza ampliamente en la investigación académica, es la teoría de la personalidad más familiar para la población en general.

Para aquellos que no están familiarizados con esta teoría, Myers y Briggs propusieron cuatro dimensiones principales de personalidad, cada una de las cuales se describe en términos de dos extremos de un espectro:

• Extroversión vs. Introversión, que describe cómo una persona obtiene y gestiona su energía: a través de la interacción con otros, o siendo solitaria y tranquila. Se representan con las letras E (extrovertido) e I (introvertido).
• Sensación vs. Intuición, que analiza cómo una persona procesa la información: con un estilo práctico, o a través de la imaginación y la inferencia. Se representan con las letras S (sensorial) y N (iNtuitivo).
• Pensamiento vs. Emoción, para describir cómo una persona toma decisiones: basadas en la lógica, o basadas en preocupaciones morales y personales. Se representan con las letras T (racional) y F (emocional) (la T es de Thought en inglés y la F del inglés Feeling).
• Juzgar vs. Percibir, para centrarse en cómo una persona organiza su vida: de manera estructurada, de manera ordenada, o de una manera más suelta y espontánea. Se representan con las letras J (calificador) y P (perceptivo) (la J es del inglés Judgment).

Las puntuaciones de una persona en cada dimensión se combinan para crear 16 tipos de personalidad distintos, cada uno etiquetado por las iniciales de las cuatro preferencias.

Por lo tanto, una persona que favorece la Introversión, Intuición, Sentimiento y Juicio se consideraría un INFJ, muy común entre abogados, jueces e investigadores de la policía. Ahora veremos qué pasa en nuestra industria.

Si quieres saber más sobre los 16 tipos de personalidad, puedes ver este artículo.

¿Qué tipos de personalidad son más comunes en programación?

Los factores humanos en la ingeniería de software tienen diferentes dimensiones. Los estudios en este campo se han realizado desde diferentes perspectivas.

Echando la vista atrás dos o tres décadas, los ingenieros de software no tenían que hacer mucha interacción social en sus puestos de trabajo; sin embargo, la situación ha cambiado en la actualidad.

Los departamentos de recursos humanos no consideran que los conocimientos en programación o ingeniería de software sean suficientes para contratar profesionales de software.

Se espera que los candidatos tengan facilidad para aprender, capacidad para trabajar en equipo, habilidades de comunicación oral y escrita, y orientación a la salud y el bienestar.

En resumen, la flexibilidad, la comunicación y la gestión del estrés, entre algunas otras habilidades, se consideran aptitudes clave en el caso de los profesionales del software.

Un estudio llevado a cabo por la Universidad de Western Ontario determinó que los tipos de personalidad introvertidos dominaban fuertemente.

Esto es algo que no debería sorprender a nadie que esté familiarizado con el tema de los tipos de personalidad; es más probable que los introvertidos disfruten de carreras que les permitan trabajar de forma independiente, mantener un perfil bajo y llevar a cabo proyectos por su cuenta.

Los tipos introvertidos -casi el 60% muestra- como ISTJ, INTP y ISFJ estaban sobrerrepresentados entre la comunidad de programadores, pero son poco frecuentes entre la población en general. Entre los perfiles extrovertidos en programación, destaca según dicha muestra el tipo ENTP.

También se encontró que los desarrolladores de software son predominantemente del tipo pensante, personas que disfrutan de las habilidades analíticas y del trabajo con sistemas lógicos. ¡Menuda sorpresa! :smile:

En el sector del software es mucho menos probable que se encuentren ENFJ, ESFJ y ENTJ ya que es poco probable que se encuentren extrovertidos en general entre los perfiles de programación.

Los extrovertidos prefieren carreras que les permitan relacionarse con otras personas y, en general, se sentirían poco inspirados por un trabajo que requiera largas horas a solas con un ordenador.

¿Qué tipos de personalidad tienen mejores ingresos en general?

Hace poco, Truity ha publicado un informe en este sentido. En él vemos que los tipos de personalidad que más ingresos tienen en el mercado laboral en general son en su mayoría perfiles extrovertidos.

Para mayores de 21 años, este análisis muestra que los ingresos eran muy variables de un tipo de personalidad a otro, con algunos tipos con mucha más probabilidad de conseguir altas remuneraciones.

Los tipos extrovertidos y los de pensamiento dominan la parte superior de los gráficos de ganancias, siendo las ENTJs las que ganan los salarios más altos de todos:

Entre los salarios más altos (los que ingresan más de 150.000 dólares), después de los 30 a 59 años, salen los siguientes datos:

Viéndolo así, podemos ver el porcentaje de cada tipo de personalidad que entra en el rango de los que ganan más dinero. Para los encuestados que se encuentran en la mitad de su vida laboral, de 30 a 59 años, se calculó el porcentaje de personas que ganan un salario muy alto ($150,000 USD y más).

Los tipos de Pensamiento-Extrovertido (E y T) volvieron a dominar las categorías de los que ganan más dinero, junto con los INTJs.

¿Estos hallazgos son trasladables a la programación?

Bueno, pues vayamos por partes... Analicemos por separado los dos grupos de edad recogidos arriba.

Iniciando la carrera profesional: De 21 a 30 años

Antes señalamos que los perfiles más representados en programación eran los introvertidos: los tipo ISTJ (el 14%), INTP (8%) e ISFJ (7%).

Es decir, el grupo predominante en programación (ISTJ) es el tercero que más gana entre los 21 y 30 años, quedando los otros dos tipos por debajo de la media.

Entre el grupo de extrovertidos más representados en programación son los ENTP y ESTJ. Los ENTP son los que más dinero ganan entre los 21 y 30 años, y los ESTJ están en cuarto lugar.

Es decir, si eres programador y tienes tipo ENTP o ISTJ tienes muchas probabilidades de ganar más dinero que la media en este tramo de edad, sin despreciar en absoluto a los tipo ESTJ que ganaría un poco menos con los tipo ISTJ.

Carreras consolidadas y rentas altas: De 30 a 59 años

Repiten los perfiles de programación con tipo ENTP, que son los que tendrían la renta más alta, pero empatados en este tramo con los tipo ESTJ.

Los perfiles ENTP son, en general, personas especialmente movidas por la curiosidad y por los retos que para ser resueltos requieren afrontar preguntas intelectualmente estimulantes. Su agilidad mental y su facilidad para detectar inconsistencias lógicas hace de ellas personas predispuestas a interesarse por la ciencia o la filosofía. Además, su tendencia a mostrarse competitivas las vuelve personas muy activas durante el día, siempre intentando llegar a soluciones innovadoras a problemas complejos.

Los perfiles ESTJ son, en general, personas a las que les gusta tener el control sobre lo que ocurre a su alrededor, siempre buscan la manera de que todo funcione como debe y, si es necesario, la implementan ellos mismos.

Entre los perfiles introvertidos, señalar que en este tramo (de 30 a 59 años, más de 150.000 dólares) los ISTJ e INTP suponen el 7%, los ISFJ el 5%.

La conclusión que podemos deducir es que, con los años, aquellos desarrolladores que sean capaces de liderar equipos acaban ganando más dinero. Cuadra bastante con la realidad.

Muchas empresas de programación se encuentran con los años que sus programadores sénior no quieren liderar equipos, y que prefieren seguir programando o hacer tareas como consultoría técnica y cosas por el estilo, que no implican la gestión de personas.

Por este motivo, hoy en día, las empresas de software hacen planes formativos para mejorar esas habilidades de gestión y liderazgo entre sus equipos de desarrollo, y así convertir los perfiles introvertidos en ENTP.

Desde hace muchos años, es casi impensable desarrollar una aplicación seria que no tenga necesidad de conectarse y comunicarse con otras aplicaciones. Especialmente si se trata de una aplicación Web.

A lo largo de las últimas décadas se han desarrollado diversas especificaciones para facilitar esa comunicación. Por ejemplo, a principios de siglo, lo más de lo más era SOAP (Simple Object Access Protocol), un protocolo de llamadas remotas basado en XML. Y desde hace ya años, lo más utilizado son las APIs Web REST, aunque han surgido otras iniciativas como OData para manejo de datos o, más recientemente, GraphQL.

Otra opción de la que seguro habrás oído hablar mucho en los últimos años son los Webhooks.

Qué es una API y para qué sirve

Una API (Application Programming Interface) es una vía para que una aplicación exponga datos y funcionalidad a otras aplicaciones.

En las APIs que se exponen a Internet, una forma común de exponer estos datos y funcionalidades es mediante una API REST, que básicamente consiste en una API que funciona recibiendo mediante llamadas HTTP (como las que haces con tu navegador) en ciertas direcciones (URL) que se conocen como endpoints.

Por ejemplo, si estamos creando una tienda online y necesitamos servicios de pago, podemos usar la API de la conocida pasarela de pagos Stripe para delegar en ella multitud de cuestiones. A través de esta API podemos efectuar acciones, como llamar al endpoint que genera un cargo en una tarjeta de crédito, pero también podemos obtener información, como averiguar nuestro saldo u obtener un listado de nuestros clientes.

Existen APIs REST para todo tipo de servicios y funcionalidades: desde información del tiempo hasta las cosas más complejas con mapas o inteligencia artificial. Y la mayor parte de las aplicaciones Web que utilizas exponen parte de su funcionalidad (¡o toda!) a través de una API REST.

Qué es un Webhook y para qué sirve

Casi todo lo que hacemos en una aplicación, al final se traduce en eventos. Por ejemplo, volviendo al caso de la tienda online, un evento de interés para nosotros se produce en el momento en el que se procesa un pago con éxito. En ese instante nos interesará hacer varias cosas: enviar un correo al comprador, generar una factura, poner en marcha el proceso de envío del producto, etc.

Si lo único que tenemos es una API REST tradicional, para enterarnos de que un evento ha ocurrido en otra aplicación (la compra se ha efectuado con éxito en la pasarela de pagos), deberemos consultar la API periódicamente. Por ejemplo, mandamos a la pasarela la orden de pago, y por diversos motivos pueden pasar varios minutos hasta que se procese. Nuestra tienda llamaría a la API cada poco tiempo para conocer el estado de la operación, hasta el momento en el que nos dé un resultado (se ha procesado con éxito, se ha cancelado...). Lo podemos visualizar como algo así:

Bien, un Webhook invierte esta situación, para que sea la aplicación que nos interesa la que nos notifique automáticamente cuando se ha producido un determinado evento.

Es decir, un Webhook es también un endpoint pero en nuestra aplicación, y en lugar de iniciar la llamada nosotros, es la aplicación con la que nos coordinamos la que nos notifica cuándo ocurre algo de interés. Le da la vuelta a la comunicación.

En nuestra hipotética tienda, lo que haríamos sería registrar en Stripe un Webhook para el evento de que se ha procesado un pago y será la pasarela la que llame a un endpoint nuestro cuando se produzca, pudiendo iniciar el resto de acciones que procedan para ese caso.

De hecho, esta es la forma recomendada de realizar la integración con Stripe: mediante la API de Intents, que se basa en el uso de webhooks.

El esquema de las comunicaciones ahora es así:

Este esquema de funcionamiento tiene muchas ventajas, tanto para la aplicación usuaria como para la que presta el servicio:

• Ahorro de recursos y tiempo: con una API, la aplicación usuaria hará muchas veces llamadas "para nada", que no devolverán información alguna. Las dos aplicaciones gastan recursos para hacer y responder a muchas llamadas que no tienen utilidad alguna.
• Eliminación de los retrasos: con un webhook la aplicación usuaria recibirá una llamada en el momento exacto en el que la necesita y no tendrá retrasos.
• Velocidad de las llamadas: generalmente la llamada que se hace a un webhook es muy rápida pues solo se envía una pequeña información sobre el evento y se suele procesar asíncronamente. Muchas veces ni siquiera se espera por el resultado: se hace una llamada del tipo "fire and forget" (o sea, dispara y olvídate), pues se trata de notificar el evento y listo.

A los webhooks se les llama muchas veces API inversas (o reverse APIs en inglés), ya que tienes algo parecido a una API (un contrato entre las dos partes) pero las llamadas se hacen en el sentido contrario al habitual.

Los webhooks suelen estar en los dos lados. Es decir, en el ejemplo anterior nuestra tienda expone un webhook, pero la otra aplicación podría tener también sus propios webhooks a los cuales llamaremos cuando se produzcan eventos de interés por nuestra parte (no es el caso de Stripe).

¿Qué aplicaciones ofrecen Webhooks?

Pues hoy en día prácticamente todas.

Veamos ejemplos de algunas plataformas conocidas:

Github ofrece webhooks para notificar a otras aplicaciones cuando se producen ciertos eventos (por ejemplo, un push a master o a una rama):

Mailchimp, el famoso software de email marketing ofrece webhooks para notificar a otras aplicaciones cuando se producen eventos como que haya una nueva alta o baja en un boletín, o un si suscriptor ha cambiado su dirección de email.

Shopify, una de los productos de tienda online más utilizados del mundo, ofrece webhooks para notificarnos acerca de multitud de eventos, como cuando un usuario procesa una compra, solicita un reembolso o añade algo al carrito.

Twilio, el líder mundial en productos de telefonía y mensajería para desarrolladores, ofrece multitud de webhookspara notificar eventos a tu aplicación (por ejemplo, si se recibe una llamada) y para que tu aplicación le pueda notificar cosas también.

Sendgrid, el archiconocido backend para envío de email, ofrece Webhooks para notificar cosas como la recepción de un mensaje o un correo enviado que rebota entre otras muchas cosas.

Como ya dije antes, la mencionada pasarela Stripe recomienda el uso de webhooks para recibir notificaciones sobre cosas que ocurren con tus clientes.

Podría seguir todo el día, pero el resumen es: los webhooks son ya una parte integral del desarrollo de aplicaciones, y debemos aprender a sacarles partido para automatizar procesos en nuestros desarrollos y también deberíamos ofrecerlos para que otras aplicaciones puedan coordinarse con las nuestras.

Integración de múltiples aplicaciones usando Webhooks

Otra cuestión fundamental y muy interesante de los webhooks es que te permiten delegar la coordinación de tareas a servicios externos, ahorrándote mucho tiempo de desarrollo y problemas.

Por ejemplo, en el caso anterior del comercio electrónico, en lugar de ser tu aplicación la responsable de recibir el webhook de Stripe y llamar a otros servicios para enviar el correo, generar la factura, etc... puedes usar un servicio de orquestación para que haga todo por ti. Pagando una pequeña cuota mensual (o incluso de forma gratuita) tienes un punto central que coordina todas las aplicaciones que usas, incluyendo las propias, gracias al uso de webhooks. Además te permite crear reglas complejas en función de lo que ocurra y de los datos que recibas, y te aseguras la continuidad sin mantener servidores.

Existen diversas aplicaciones que, mediante el uso de webhooks y con integraciones de API hechas por ellos mismos que se comportan como webhooks, permiten definir procesos entre múltiples servicios que responden ante eventos y crear flujos propios.

Esto que suena un poco lioso, en realidad es muy sencillo y simplifica enormemente los desarrollos, ya que te permiten definir tus procesos de forma visual y sin apenas conocimientos técnicos.

Los servicios de este tipo más conocidos son:

• Zapier, casi el estándar, que integra más de 2.000 aplicaciones de todo tipo y permite crear todo tipo de flujos entre ellas. Para mi gusto la interfaz de usuario la han estropeado en los últimos años queriendo hacerla más sencilla. Tiene una capa gratuita bastante generosa.
• Integromat: una aplicación de una pequeña empresa checa pero que tienen un gran peso en este nicho. No ofrece tantos servicios como Zapier (aunque sí muchos) pero es muy fácil integrar cualquier servicio externo con los conectores HTTP y JSON (webhooks) e incluso cosas antiguas con los conectores XML y SOAP. Su capa gratuita es muy generosa.
• IFTT: una de las pioneras, pero que se han orientado más a integrar productos del hogar digital y que, en mi opinión, tiene una de las interfaces de usuario menos usables que se han diseñado. Eso sí, es gratuita y te da algunas integraciones interesantes. Los conectores para Webhooks son un tanto limitados en cuanto a parámetros que se pueden enviar y recibir porque los han pensado para IoT (pequeños dispositivos conectados) y no tanto para facilitar integraciones.
• Microsoft Power Automate. Empezó como Microsoft Flow hace unos años, con una orientación más hacia usuarios finales y con una versión gratuita bastante generosa. Ahora forma parte de la familia de Power Platform, y tiene una orientación completamente empresarial. Sin capa gratuita. Si trabajas con Office 365 o Azure, es el camino a seguir.
• n8n.io: menos conocida pero muy potente, esta plataforma de orquestación es gratuita y de código abierto. En mi opinión, tiene la interfaz de usuario más interesante de todas, que te permite ver de un golpe de vista lo que estás haciendo en cualquier flujo aunque sea complicado (es la figura de más arriba). No tiene tantos servicios preintegrados como las otras, pero es muy fácil usar webhooks para hacerlo. La puedes incluso albergar en un servidor propio.

Existen algunos más e incluso los hay orientados especialmente a programadores, como Pipedream, NodeRed o StackStorm.

¿Qué debo usar: API o Webhooks?

Lo primero que hay que tener claro es que no son elecciones excluyentes. Las API tienen sus usos y los webhooks otros distintos, aunque a veces se puedan solapar.

Aunque con webhooks se pueden obtener datos y ejecutar acciones, por regla general las API están más orientadas a esto último. Normalmente automatizarás a otras aplicaciones usando sus API, aunque puedes provocar acciones en otras aplicaciones usando webhooks también.

Si la operación tiene que ver más con un usuario concreto o una acción individual, lo más normal es que haya un webhook apropiado. Pero si lo que necesitas es consultar información puntualmente, tendrás que usar una API. Si necesitas ampliar la información de una operación, normalmente necesitarás usar la API también (por ejemplo, puedes recibir un webhook para decirte que un usuario ha comprado un producto, pero si quieres saber si ese usuario ha comprado antes o cuánto saldo tiene en su cuenta, necesitarás llamar a la API).

Como ves son herramientas complementarias y cada una tiene sus usos más apropiados según tus necesidades.

Si lo ves desde el otro punto de vista, que tu aplicación permita su automatización, entonces deberías tener ambas cosas: una API y diversos webhooks, por los mismos motivos expuestos antes.

En resumen; los webhooks son una herramienta de desarrollo muy potente que nos permite ahorrar recursos, tiempo y problemas de información desactualizada. Utilizados en combinación con otros servicios pueden ayudarnos a automatizar de manera sencilla y rápida tareas complejas. Complementándolos con una buena API permiten colaborar con otras aplicaciones de manera sencilla y profesional.

¡Espero que te resulte interesante!

Has trabajado duro en crear esa biblioteca JavaScript maravillosa en la que llevas trabajando varias semanas en tus ratos libres. La has probado bien y está lista para ser utilizada. Ahora solamente te faltan los usuarios que la quieran usar. ¿Cómo se la hago llegar? ¿De qué manera van a descubrirla para poder sacarle partido?

Si es una biblioteca Open Source, seguro que la tienes en GitHub. Además, puede que hayas hecho una pequeña página Web con Jekyll, albergada en el propio GitHub, que explique de qué va tu proyecto y por qué deberían usarlo. Pero, hoy en día, si quieres que una biblioteca Front-End sea accesible a millones de desarrolladores tiene que estar en el repositorio de npm.

Aunque el nombre de npm viene de Node.js Package Manager, hace ya mucho tiempo que no solo se usa para el Back-End, sino también para todo lo que tiene que ver con el Front-End. En npm puedes encontrar todo tipo de bibliotecas para desarrollo JavaScript, incluyendo extensiones de jQuery, y casi cualquier cosa que necesites para Angular, React o Vue.js.

Además, la mayor parte de los desarrolladores medianamente profesionales esperan poder gestionar todo este tipo de dependencias de manera automática con npm, por lo que la típica descarga del archivo .js no llega: tienes que tenerlo sí o si en npm.

Vale. De acuerdo, pero ¿cómo lo haces? A continuación te cuento cómo, paso a paso.

Parto de la base de que, como buen desarrollador Front-End, tienes instalado Node.js en tu máquina, y por lo tanto npm también. Si no es así, ya estás tardando en instalarlo. La versión LTS es suficiente.

1.- Crear una cuenta de npm

Bueno, este es bastante obvio, Para poder publicar paquetes allí necesitas tener una cuenta. Vete a la página de alta y rellena el formulario:

Tendrás que confirmar la dirección de email, pero en medio minuto puedes tener tu cuenta lista. 

Asegúrate de que puedes acceder sin problema antes de continuar.

2.- Acceder a tu cuenta desde la línea de comandos

Todo el proceso se realiza desde la línea de comandos, no desde la web, así que abre una línea de comandos (cmd.exe, PowerShell, bash... lo que tengas) y ejecuta el comando:

npm login

Te pedirá que introduzcas el login, la clave y el email de tu cuenta de npm, la que acabas de crear. Esto es lo que se ve (en mi caso en la línea de comandos de Visual Studio Code directamente):

No es necesario que estés en ninguna carpeta en especial, ya que el estado de login queda guardado a nivel global: una vez que te autentiques queda hecho hasta que decidas cerrar la sesión con npm logout.

3.- Definición del paquete y ajustes previos

Asegúrate de que la biblioteca que has creado está bien probada, con todos los flecos recortados. Una vez que subes una versión concreta de un paquete a npm, si te confundes no lo puedes borrar: tienes que crear una nueva versión. Así que párate a verlo bien.

Todos los archivos de tu biblioteca, lo que quieres publicar, debe estar dentro de una carpeta. Entra en esa carpeta con la línea de comandos y asegúrate de que tienes un archivo package.json creado en la raíz de la misma. Este archivo es el que define el paquete npm. Si haces desarrollo Front-End profesional seguro que lo tienes ya creado para gestionar tus dependencias, pero si no es así, tienes que crearlo antes.

Para ello vete a la línea de comandos, que debe estar en la carpeta raíz de tu proyecto, y escribe:

npm init

Este comando genera el mencionado archivo, pero antes te hace una serie de preguntas que debes contestar. La mayoría de ellas te ofrecen un valor por defecto sensato sacado del contexto. Por ejemplo, como nombre del paquete el nombre de la carpeta, para el directorio de código fuente, lógicamente, el origen de Git que tengas establecido para el proyecto, etc... Por ejemplo, esto es lo que pondría yo en mi proyecto jquery.pan (la misma biblioteca que se usa en este blog para el zoom de las imágenes) si tuviera que crear el package.json desde cero:

Atención: el nombre del paquete tiene que cumplir ciertas reglas para ser válido. Por ejemplo, no puede llevar mayúsculas ni espacios y no puede empezar por un punto o un guión bajo. Además, es muy importante que no coincida con el de ningún otro paquete publicado en npm, por lo que antes de ponérselo busca el nombre deseado en npmjs.com hasta que dés con uno que no exista. Sino no podrás publicarlo. Así que mucho ojo con esto.

Este es el aspecto del paquete que se ha creado:

Fíjate en cómo, dado que el código fuente está en Github, automáticamente le añade las propiedades para informar de bugs y la página de información propias de este servidor de código fuente.

Es muy importante que le pongas un número de versión apropiado, que siga además el sistema de versionado semántico, porque una vez que publiques el paquete no podrás eliminarlo, y si hay un error tendrás que generar una nueva versión y según cómo lo hagas la puedes liar parda. Así que ojo con esto.

Asegúrate también de tener un archivo readme.md (Markdown) en la raíz de tu carpeta. Ese archivo es el que va a usar npm para mostrar la información sobre tu proyecto, por lo que, lo que escribas ahí, es lo que saldrá publicado en el registro de paquetes. Invierte tiempo en escribirlo, repasarlo y que esté todo muy claro. Describe brevemente al principio lo que hace tu paquete, añade las instrucciones precisas y no escatimes en explicar lo que sea necesario, pero no más.

Fíjate también en que en la propiedad main (que se corresponde con la pregunta "Entry point" del asistente de creación de package.json) es interesante poner la ruta relativa al archivo principal de tu biblioteca. En realidad, esta propiedad es para los proyectos de Node.js, para saber cuál es el archivo principal para ejecutar la aplicación de servidor, pero en Front-End nos vale para dar pistas sobre por dónde empezar a trabajar (ya que puede ser más de un archivo).

4.- Publicar el paquete

Bueno, ya queda muy poco. Ahora que tienes todo preparado sólo hay que generar y publicar el paquete.

En realidad se puede hacer todo de golpe con un solo comando, pero puede ser interesante ver el paquete generado antes de subirlo y que se publique.

Puedes generar el paquete localmente sólo, usando el comando: npm pack:

Esto genera un archivo .tgz en la raíz del proyecto (un archivo TAR comprimido con GZip, típico de UNIX) que es el que se publicará a npm.

Si te fijas en la animación (aunque pasa muy rápido), pero sobre todo si miras el archivo que se ha generado, verás que pesa un montón (más de 20MB), lo cual es algo muy extraño para una biblioteca de JavaScript, así que algo estamos haciendo mal.

Por eso es bueno hacer esto antes de publicar directamente: tienes la oportunidad de ver qué se va a generar exactamente antes de que esté publicado y sea demasiado tarde.

Si abres el archivo comprimido (yo, en Windows, uso 7-ZIP, el mejor compresor del mundo) verás que tiene un montón de imágenes de prueba (para hacer zoom, pan y rotación, que es de lo que va la biblioteca) y que no hacen falta para nada en el paquete que debes publicar:

Dentro del .tgz hay un .tar y dentro de éste ya vemos todos los archivos, y detectamos enseguida que hay cantidad de cosas que sobran y que por eso pesa tanto.

No nos hacen falta para nada, en este caso, las carpetas:

• .vscode, con los ajustes personales de Visual Studio Code.
• src: que es el código fuente de la librería (el resultado final está en la carpeta dist, como ya sabemos de cuando creamos el package.json).
• img: todas esas imágenes de prueba que pesan tanto.

Tampoco queremos para nada que vayan los archivos .gitattributes (que incluso puede llevar información privada) ni index.html (que es el ejemplo para probar). Hay ciertas cosas que ya se descartan automáticamente, como el archivo .gitignore y, sobre todo la carpeta node_modules con todas las dependencias y herramientas usadas para el desarrollo del proyecto.

¿Cómo nos libramos de estas cosas que no queremos?

Pues creando un archivo de texto en la raíz llamado .npmignore. Al igual que .gitignore nos sirve para excluir archivos y carpetas del control de código fuente, este funciona exactamente igual, pero para los paquetes generados por npm para publicar. Crea el archivo y mete los recursos que quieres excluir, poniendo sus nombres y usando también globs si te hace falta. En este caso no me complico la vida y el contenido es tan solo el siguiente:

Si ahora lanzo de nuevo el comando npm pack, se incluyen tan solo 5 archivos:

OJO: no te olvides de borrar el archivo .tgz anterior antes de generar de nuevo el paquete o de publicar, puesto que sino se incluirá en el nuevo paquete y será otro archivo innecesario. Si quieres evitarlo añade *.tgz a tu lista de .npmignore.

Y el paquete final pesa tan solo 6,88KB. ¡Estupendo!

Vale, ahora que ya sabemos que va lo que queremos que vaya, estamos listos para publicar.

Borra el archivo .tgz de pruebas que hemos creado (no queremos que vaya por error en el paquete) y, ahora sí, damos el paso definitivo para publicar. Escribe en la línea de comandos:

npm publish

Al hacerlo, se generará de nuevo el .tgz, pero esta vez se enviará directamente al registro npm. Al cabo de unos momentos, si no hay ningún problema, recibiremos un correo electrónico de confirmación diciéndonos que el paquete está publicado:

Además podremos verlo en nuestro dashboard de npm:

y también podremos buscarlo en el buscador del registro:

¡Enhorabuena! ¡Has publicado tu primer paquete npm! Pero lo has hecho como un profesional 😉

Ya solo te queda recoger los beneficios económicos del trabajo bien hecho (oh, wait! 😆)

¡Espero que te resulte útil!

Convertirse en mentor puede ser una experiencia gratificante, y no sólo para aquellos a los que asesoras y enseñas. Además de ser un perfil altamente demandado por las empresas de desarrollo de software (programadores sénior con vocación de tutorizar a programadores júnior), tiene muchas otras recompensas que van más allá de lo profesional.

Ser mentor de otros desarrolladores puede ser muy gratificante. Es una gran manera de transmitir tu propia experiencia y conocimiento, así como cualquier consejo valioso que hayas recibido a lo largo del camino. También te ayudará a meditar sobre muchas cuestiones y a reforzar tus propios conocimientos. La orientación de jóvenes programadores con un futuro prometedor puede tener un impacto significativo en tus perspectivas profesionales y en tu salario.

Y es que a las empresas de programación les interesa. Se estima que las empresas de software que cuentan con una cultura de tutorización de los programadores noveles son entre un 10 y un 17 por ciento más rentables.

Pero, ¿qué es exactamente lo que hace a un buen mentor? Tanto si acabas de empezar, como si buscas mejorar tus habilidades como mentor, en el artículo de hoy te ofrecemos algunos consejos sobre cómo establecer relaciones sólidas y productivas como mentor de otros programadores.

1.- Ten un mentor tú también

Los profesionales que tienen o han tenido mentores son mejores mentores ellos mismos. El hecho de recibir asesoramiento de un mentor ayuda enormemente a comprender no sólo qué es lo que funciona, sino también la mejor manera de ofrecer lo que un discípulo necesita oír en cada momento.

Los mejores mentores son los que tienen o han tenido mentores ellos mismos - y cuantos más, mejor. Sería recomendable tener -y haber tenido en el pasado- una variedad de mentores. Los programadores que se convierten en buenos mentores, no sólo lo son por su propia experiencia, sino porque ellos mismos lo han sido y han aprendido de lo que funcionó y lo que no funcionó, y pueden aprovechar las lecciones que aprendieron y transmitirlas.

Da igual la edad que tengas, y aunque ya seas un sénior puedes buscar un mentor para aprender un lenguaje de programación de un compañero y hacer el rol de aprendiz, o buscar aprender de analistas u otras tareas ligadas a la profesión con la ayuda de un mentor.

Si eres júnior y crees que en el futuro te gustaría serlo, aprende de la experiencia y busca cuántos más mentores mejor al principio de tu etapa profesional. Te ayudará a desarrollar tus habilidades más rápidamente y a ser un gran mentor en el futuro.

2.- Prepárate y documéntate

Los consejos improvisados con poco seguimiento hacen que la relación de orientación sea inconsistente y probablemente improductiva. Es más, deberías documentar meticulosamente el antes, el durante y el después de tus sesiones de tutoría, tanto para ti mismo como para las personas a las que asesoras.

Este proceso no lo tienes que hacer en soledad. Debes implicar a los programadores. Por ejemplo, puedes llevar una diario de sesiones en un documento compartido y establecer tareas a modo de hitos entre las sesiones de tutoría.

Prepara las sesiones centrándote en un solo tema o en una breve lista de temas a tratar. Luego, cuando hayas resuelto lo de la lista, al final de la sesión, asigna tareas: al menos tres preguntas, pero no más de cinco, para que la persona que está siendo asesorada las considere de cara a la próxima sesión.

También deberías anotar la duración media de las sesiones, lo que funciona y lo que no, dónde te atascas tú o la persona a la que estás asesorando, y las forma de superar esos escollos. También es fundamental llevar por escrito los resultados obtenidos de tus consejos y aportes, tanto para documentar el valor del trabajo como para dar refuerzo positivo a los orientados.

3.- Asesora fuera de tu zona de confort

La tutoría debería consistir en solicitar, recopilar y poner en práctica los consejos, aportaciones, pensamientos y sugerencias de alguien cuya perspectiva, experiencia y conocimientos sean, al menos en cierto modo, diferentes de los tuyos. Eso significa hacer un esfuerzo consciente por salir de tu zona de confort.

La tutoría fuera de tu propia área de especialización es un buen punto de partida. La diferencia de perspectivas, conocimientos y experiencia puede permitir alcanzar una visión nueva o diferente que de otra forma no tendrías.

Por ejemplo, si eres programador back-end y haces de tutor de programadores júnior de front-end, seguro que toda la experiencia resulta muy enriquecedora para todas las partes, incluida la empresa.

4.- Dar a los participantes libertad para que sigan su propio camino

La tutoría debería permitir a los que estás tutelando la libertad y el espacio para articular mejor sus ideas, necesidades y deseos, y para hablar de su viaje. Tu papel como mentor debería ser el de crearles ese espacio y tiempo, sin dictarles un dirección concreta.

Muchas veces, a los aprendices les basta con exteriorizar sus propios pensamientos y sentimientos. Es mejor darles pistas para que reflexionen sobre sus propias ideas. En realidad, no se trata de decirle a las personas lo que tienen que hacer.

Un buen mentor proporciona ideas y conocimientos para que los beneficiarios puedan desarrollar ellos mismos esa dirección. No les estás enseñando a pensar. Se trata más bien de darles el espacio para resolver las cosas por sí mismos, y simplemente ir en el viaje con ellos, actuando como red de seguridad y apoyo.

5.- Asesora siempre teniendo en cuenta la diversidad y la inclusión

Las relaciones de tutoría son críticas para los distintos talentos, especialmente en programación, así que asegúrate de que estás tutelando (dentro de lo posible) a personas de distintos géneros y habilidades -abarca todo el espectro si existe-, esto incluye también la edad; no siempre te inclines hacia los que son más jóvenes que tú.

Un gran error que cometen muchos mentores es sólo tutelar a los de las generaciones más jóvenes, pero en realidad en muchos lugares de trabajo hay hasta cinco generaciones distintas.

Si has llegado a un punto en tu vida profesional en el que puedes ofrecer a otros el fruto de tu experiencia, hazlo con la vista puesta en ayudar a quienes son diferentes a ti y transmitir lo que sabes, son los que más se van a beneficiar de ello y a la larga serán también los que mayor satisfacción te harán sentir.

6.- Solicita feedback y autoevalúate como mentor

La retroalimentación es una parte crítica de cualquier relación de tutoría y especialmente al principio, cualquier comentario que consigas será mejor que ninguno. Esta retroalimentación no tiene que estar limitada a la relación de tutoría. Puede provenir de tus propios mentores, jefes o también del departamento de recursos humanos.

Preguntar si lo que estás haciendo sirve de ayuda o es útil es indispensable. Si las cosas no van muy bien, podrás encontrar puntos de mejora con la ayuda de tus compañeros o de recursos humanos, y si las cosas van bien, te servirán de motivación y recarga de energía para seguir con la tarea.

7.- Participa activamente en charlas y actividades formativas

Desde la participación en meet ups o en charlas de programación hasta estar en foros ofreciendo ayuda o incluso siendo autor de cursos online de programación, todo ello te ayudará a mejorar como formador y mentor.

Harás contactos, mejorarás tu capacidad de transmitir conocimientos y de expresión, y también desarrollaras un sentido de la paciencia nuevo y que es muy necesario a la hora de tutelar a otras personas en tus conocimientos.

Muchas empresas de desarrollo organizan unas horas al mes dedicadas a la formación o divulgación internas, en la que un voluntario prepara un tema para enseñar a los compañeros que voluntariamente quieran asistir. Si en tu empresa aún no se hace, puedes promoverlo con la ayuda del departamento de recursos humanos.

Conclusión

Para ser mentor o mentora no hace falta enseñar a programar, para eso están los cursos de programación y demás actividades formativas. Ser mentor consiste en orientar profesionalmente a personas con menos experiencia que tú: enseñar a trabajar en equipo, a seguir buenas prácticas, a gestionar el tiempo, a vender sus propias ideas dentro de la empresa y cosas por el estilo.

No se trata de dar respuestas, se trata de ayudar a los demás a que lleguen a sus propias conclusiones. Ser mentor es una especie de labor socrática en la que debes hacer pensar a los participantes y como mentor debes poner el foco en las preguntas y en el seguimiento más que en las respuestas.

Estos solo son algunos consejos, pero si quieres aportar más puedes hacerlo en la sección de comentarios.

Hace unas semanas tuve la suerte de participar en el meetup de un grupo de usuarios, compartiendo sesión y hablando sobre Github Actions con un miembro del equipo de desarrollo de la herramienta. De esa charla en el meetup y del tiempo de preparación previo, saqué una conclusión un poco agridulce:

Todavía hay mucha gente que piensa que Github es un simple almacén de código 😱

Precisamente, de esta conclusión que me llevé, y del hecho de que hace unos días, Github anunciase que ampliaba las capacidades gratuitas de la herramienta cuando se trabaja a nivel organizativo, surge esta entrada, en la que voy a dar un repaso a las capacidades que nos ofrece Github, y con la que podrás sacar la conclusión de si es o no un simple repositorio de código fuente 😉

Si tienes interés en ver la charla, está subida en el canal de YouTube de Dotnetters Zaragoza: Github Actions: ¿Hasta dónde podemos llegar?

Un poco de historia

Hace muchos años que aparecieron plataformas con las que poder gestionar el código fuente en internet. Los más veteranos en la sala recordarán como Codeplex o SourceForge se llevaban el mercado en los tiempos de Subversion (SVN). De hecho, aunque Codeplex está actualmente en modo archivo, SourceForge sigue funcionando y hospedando miles de proyectos como repositorio de control de versiones.

Con el paso de los años y la predominancia de Git como sistema de control de versiones distribuido (casi el estándar hoy en día), fueron tomando fuerza plataformas online alternativas centradas en Git como base para el control de versiones. Una muestra de estas plataformas puede ser la que nos ocupa (Github), pero también otras muy conocidas y utilizadas, como Bitbucket o Gitlab. Desde sus inicios, estas plataformas han ido evolucionando durante el paso de los años y han ido añadiendo cada vez más capacidades.

Antes de seguir, vamos a hacer una aclaración muy importante. Git es un software de control de versiones distribuido diseñado por Linus Torvalds como solución a los problemas de control de versiones que se encontraban los desarrolladores del kernel de Linux. Plataformas como Github son sistemas web para control de código fuente que utilizan Git como sistema de versionado subyacente y son compatibles con sus protocolos. Es decir, aunque parezca una obviedad, es necesario aclarar que todos los repositorios de Github utilizan Git pero no todos los repositorios Git están en Github.

Además de Git, algunas plataformas online soportan otros software de versionado como puede ser Mercurial, SVN, o la de los pucelanos Plastic SCM.

Teniendo clara la diferencia de concepto entre Git y Github, es lógico preguntar qué aportan plataformas como Github cuando puedes tener tu repositorio en un servidor directamente.

Github en concreto fue "una revolución" y se hizo enseguida con el mundillo del código abierto porque, aparte de facilitar el uso sencillo de los repositorios sin tener que gestionar nosotros la infraestructura, inventaron una forma de trabajo muy interesante: las bifurcaciones (más conocidas como fork) y los pull request.

Aunque el concepto de fork existe desde al menos el comienzo de los años 80 del siglo pasado, esta funcionalidad fue una importante revolución ya que clonaba el repositorio en el servidor (para un uso exclusivo del que hacía el fork), pero lo deja enlazado con el repositorio original. Eso elimina de raíz la necesidad de tener acceso de escritura sobre un repositorio para poder hacer cambios en él y facilita el poder contribuir cambios propios hacia el repositorio original.

Así, gracias a las bifurcaciones es posible que el desarrollador A cree un fork del repositorio del desarrollador B, haga cambios directamente sobre su propia copia independiente del repositorio y una vez que haya terminado con los cambios, aprovechando que su repositorio está vinculado al original, cree una solicitud de extracción de cambios (Pull Request) para que el desarrollador B (el único con permiso de escritura en el repositorio original) incorpore de manera sencilla esos mismos cambios.

Este flujo ha sido incorporado posteriormente por otros gestores de código fuente online.

Con el paso de los años, Github ha ido evolucionando y ampliando las herramientas que ofrece a los usuarios.

Vamos a ver sus principales características. Y lo mejor: son totalmente gratuitas.

1.- Github para gestionar proyectos

Desde hace ya algunos años es posible crear tableros de gestión de proyectos. Si bien es cierto que la idea original detrás de los tableros era gestionar las incidencias (y de hecho se pueden añadir directamente), nada nos impide crear nuevas tareas manualmente. Para crear nuestro tablero, basta con que dentro del repositorio vayamos a la pestaña de proyectos:

Dentro de un proyecto es posible crear tantas columnas como consideremos necesarias dentro de nuestro flujo de trabajo, de modo que podamos gestionar las tareas al estilo Kanban.

Por poner un ejemplo real, así es cómo se ve el tablero de tareas de la extensión DevOps de Az Cli:

2.- Solicitudes de extracción (Pull Request)

En la introducción planteaba que el "nuevo" concepto de bifurcación ofrecía una ventaja para el desarrollo colaborativo. Esta ventaja son las solicitudes de extracción. Al estar el repositorio original y nuestra bifurcación relacionadas, es posible que una vez que hemos terminado los cambios en la bifurcación solicitemos al propietario del repositorio original que incorpore esos cambios. Esto abre un mundo de posibilidades porque ya no es necesario tener permisos de escritura sobre un repositorio para poder contribuir en él, y facilita el desarrollo colaborativo.

Esto está integrado de manera nativa en GitHub de modo que, para el propietario del repositorio, aceptar una solicitud de extracción es tan simple como lo puede ser mezclar una rama.

Además de esto, Github ofrece integración con muchos servicios de terceros para realizar diferentes acciones, como una integración o despliegue continuo, una revisión con un analizador de código estático y otras variantes que se pueden incorporar como diferentes validaciones. En caso de que alguna de las validaciones no se cumpla, se notificará de manera bien visible para que el propietario sepa que los cambios tienen algún problema. Y por el contrario, se le mostrará de forma prominente que todo va bien.

3.- Revisión y discusión del código

Está muy bien tener un tablero con el que poder gestionar al proyecto, ya que aporta visibilidad al trabajo que se está desarrollando y marca el camino a seguir en el futuro cercano pero... en un mundo colaborativo donde cualquiera puede aportar su granito de arena a un proyecto, es necesaria una herramienta con la que poder revisar el código de las aportaciones. Y en el trabajo en equipo es algo indispensable.

Github ofrece esta posibilidad de manera integrada, de modo que cualquiera puede ir a una solicitud de extracción o a un commit y abrir una discusión en un punto concreto, incluso para una línea de código en particular.

Gracias a esto es posible revisar el código in situ, de manera que el que ha creado el código o el responsable del proyecto y los desarrolladores involucrados puedan debatir.

Esto es especialmente útil ya que, aunque se puede debatir todo lo que sea necesario en la propia conversación asociada a un commit, a un Pull Request o a una línea de código concreta, el hecho de poder hacer anotaciones directamente o poder poner el fragmento de código que se sugiere, dinamiza mucho la revisión del código.

4.- Gestión de incidencias (issues)

Con lo planteado hasta el momento tenemos un lugar donde almacenar nuestro código, gestionar el ciclo de desarrollo del producto y hacer solicitudes de extracción y revisiones de código pero... ¿y la interacción con los usuarios de lo que estamos desarrollando? Existen muchas herramientas para hacer seguimiento de las incidencias de modo que los usuarios puedan registrar sus problemas directamente.

Github integra esta característica de serie y además, no podría ser más fácil de utilizar. Basta con ir a la pestaña de incidencias (Issues en la interfaz de usuario) para poder ver, crear y editar incidencias. Los usuarios pueden ir e introducir problemas, sugerencias, preguntas...

Además, permite el definir cómodamente plantillas que se mostrarán siempre que se cree una nueva incidencia, de manera que guíe a los usuarios sobre qué información es útil para la resolución del problema o qué esperamos que pongan:

5.- Documentación (wikis)

Quizás uno de los puntos que menos nos gustan a los desarrolladores sea la documentación. Crear documentación suele ser tedioso ya que hay que mantenerla y suele ir evolucionando. Es por eso que tener un punto donde centralizarla es interesante, y si además podemos utilizar gestión de versiones para ella, es un escenario ideal. Como en todo, existen muchas plataformas donde poder documentar el código, pero Github lo ofrece de manera integrada gracias a la Wiki del proyecto.

La Wiki de un proyecto es un repositorio Git (¿a que no te lo esperabas 😆?) en el que se puede subir la documentación en formato Markdown (*.md). El hecho de usar Markdown facilita la creación de la documentación, ya que es un texto plano con ciertas convenciones para aplicar estilos (de hecho, esta entrada está escrita en Markdown), y como es un repositorio Git, subir cambios y tener un versionado es tan simple como hacer commit y push. Del resto se encarga Github, que va a crear un índice navegable a los diferentes ficheros y una búsqueda, de modo que la información sea útil y accesible.

6.- Páginas web (GitHub Pages)

Github ofrece una interesante utilidad para crear páginas Web. Lo que hace Github es servir una página web estática con todo su HTML, CSS y JavaScript desde el repositorio directamente, incluso en una rama aparte de modo que no interfiera con el trabajo normal.

Esto, aunque pueda parecer una tontería, es una gran ventaja para muchos casos ya que permite servir contenido en Internet de manera totalmente gratuita y desde la CDN global de Github (y recordemos que, como todo lo anterior, es gratis).

Si tienes curiosidad sobre cómo hacerlo, nos dudes en echarle un ojo a la serie de campusMVP sobre el tema: Crea tu propia página o blog gratis con Jekyll y Github

Todas aquellas páginas que optan por servirse desde Github pueden ser actualizadas de manera tan sencilla como añadir un cambio al repositorio y hacer commit y push. ¿Sencillo verdad? Todo esto con un ancho de banda muy generoso, nada menos que 100GB (recordemos que desde una CDN global como es Github) y con dominio propio y certificado HTTPS.

7.- Github para integración y despliegue continuo

Desde la compra de Github por parte de Microsoft, Github ha aumentado las herramientas que ofrece a sus usuarios, como el aumento de capacidades de manera gratuita o el fork de los agentes de Azure Pipelines. Precisamente del fork de esos agentes surge una iniciativa propia llamada Github Actions.

Github Actions es una herramienta de integración y despliegue continuo perfectamente integrada con la plataforma. Gracias a esta herramienta no es necesario recurrir a servicios de terceros como puedan ser Azure DevOps, Travis CI o AppVeyor, ni a ningún servicio propio como pueda ser Jenkins.

Para poder utilizar las acciones, basta con ir a la pestaña Actions del repositorio:

Una vez dentro es posible ver los flujos de trabajo que hay registrados así como crear nuevos. Los disparadores de estos flujos de trabajo son muchos y variados, desde cambios en el código hasta que alguien dé una estrella al proyecto. Esta versatilidad es la que nos permite realizar tanto integraciones continuas como despliegues continuos, como simplemente, por ejemplo, labores automáticas de documentación.

Estos flujos de trabajo, además, se registran en un fichero .yml que se queda en la carpeta .github/workflows dentro del repositorio, por lo que es muy simple el poder reutilizarlos en diferentes proyectos. Además, cuando alguien haga una bifurcación del proyecto, también tendrá disponibles los flujos de trabajo que garanticen la calidad del mismo.

8.- Organizaciones

Por si todo lo planteado antes fuese poco, Github permite crear organizaciones para poder gestionar de manera grupal un conjunto de repositorios. Esto a simple vista puede no parecer importante, pero es algo de vital importancia ya que permite que varios usuarios tengan control a diferentes niveles sobre los repositorios de la organización. Esto permite que los proyectos Open Source puedan seguir activos aunque su desarrollador original se retire, ya que otros pueden haber entrado a formar parte de la organización y tomar el relevo.

Imagina que una única persona en exclusiva tiene acceso al repositorio con el código de una librería de uso común. Mucha gente la utiliza y hace PRs a ella, pero si el propietario pierde acceso a su cuenta, se retira, o simplemente se cansa, el proyecto acabará muriendo ya que no se incorporarán los nuevos cambios.

Además, si trabajamos en una empresa con muchos proyectos en marcha gestionados en GitHub, podremos organizarlos y delegar el control de manera sencilla.

9.- Un montón de pequeños extras

En este artículo he pretendido citar las características más importantes (al menos desde mi punto de vista), pero no son todas ni mucho menos. Existen multitud de herramientas para usos muy variados dentro de la tienda de Github, muchas de ellas gratuitas para proyectos cuyo código es público.

Hace algún tiempo, se introdujeron de manera nativa feeds para diferentes repositorios de paquetes, de modo que es muy fácil tener a mano un feed propio donde alojar los paquetes que desarrollas (gratis si son repositorios públicos). Además, de manera integrada y automática, Github comprueba las versiones de paquetes que se utilizan en los proyectos para avisar de vulnerabilidades detectadas en ellos y ofrece una alternativa en base a lo que han hecho el resto de desarrolladores.

Por citar alguna otra capacidad, Github permite ver estadísticas sobre el código del repositorio y sobre el repositorio en sí mismo, dependiendo de los lenguajes, es posible navegar a la definición de los diferentes métodos desde el propio visor web... Sí, lo has leído bien, navegar por las definiciones dentro del propio navegador web 😯

Por resumir

Con todas estas características sobre la mesa, queda claro que Github no es exclusivamente un repositorio de código fuente. Sí lo fue en sus orígenes, pero es un producto que ha evolucionado mucho a lo largo de los años. Ya tenía un futuro muy prometedor antes de que lo comprara Microsoft, pero ahora que está en manos del gigante de Redmond sus opciones han mejorado todavía más.

Si pensabas que era tan solo un repositorio Git remoto... piénsalo otra vez.

Y tú ¿cómo le estás sacando partido a GitHub? Déjanos tus comentarios debajo.

Antes de nada voy a empezar con un buen repaso de qué es la propiedad z-index, para qué vale y cómo trabaja. Aunque creas que conoces z-index, no dejes de leer esta parte introductoria, puesto que hay detalles que es muy probable que no tengas tan claros como creías.

El artículo es bastante largo porque entra a fondo en cómo se apilan los elementos de una página, algo que es crucial entender bien para poder evitar problemas a la hora de maquetar y mostrar los elementos adecuadamente. Además quiero ser exhaustivo. Incluyo también un vídeo explicativo al final, en el que se puede ver en la práctica lo explicado.

Este artículo está basado en material de mi curso HTML5 y CSS3 a fondo para desarrolladores de campusMVP. Si quieres aprender bien estas materias, más complicadas de lo que parece a primera vista, este es tu curso. Habla con tu responsable en tu empresa: puede saliros sin coste.

La propiedad z-index

La propiedad CSS z-index sirve para indicar la posición de los elementos en el eje perpendicular (eje "Z" de ahí su nombre) de una página.

Si vemos una página Web como un papel colocado sobre una mesa, los ejes X e Y serían los que siguen los bordes de la página, y el eje Z sería el perpendicular a la mesa (hacia "arriba"), algo así:

Como vemos, todos los ejes parten de la esquina superior izquierda de la página. Los ejes horizontales, X e Y, que mueven los elementos sobre la superficie de la página, son los que establecemos con las propiedades top y left cuando un elemento está posicionado de manera diferente a la posición estática que tienen por defecto (por ejemplo: absolute, relative, fixed, sticky...). El eje Z es lo que establecemos con la propiedad z-index y se refiere a la posición de los elementos sobre el plano.

Con z-index podemos controlar cómo se posicionan unos elementos encima de los otros cuando coinciden al cambiar su posición.

En la página, este posicionamiento vertical se traduce en que unos elementos "tapan" a los otros porque se superponen, ya que, en la figura anterior, nosotros veríamos la página colocados de forma perpendicular a la mesa, o sea, desde arriba, por lo que no somos capaces de ver la "altura", y sólo veríamos unos encima de otros tapándose.

Lo básico que hay que saber de z-index es lo siguiente:

1. Sus unidades son "niveles", no longitudes. Al contrario que el posicionamiento en los otros ejes, el valor de esta propiedad no se mide en píxeles u otras unidades de longitud, sino en "niveles". Es decir, es un número entero, positivo o negativo, que indica el "nivel" sobre el plano de la página en el que se colocará ese elemento.
2. Sólo funciona en elementos posicionados. Es decir, en elementos con el valor por defecto de position (que es static), no tiene efecto alguno. Ya le puedes poner lo que quieras, que no te hará caso.

Cómo se colocan los elementos en una página: la importancia de z-index

Por defecto los elementos de una página tienen una posición estática, por lo que se colocan siguiendo el orden en el que están definidos en el código y, en principio, no se solapan nunca.

Nota: lo anterior no es del todo cierto ya que podemos jugar con márgenes negativos y cosas así para hacer que se solapen, pero no es lo habitual. En cualquier caso seguirían estando en el mismo plano, por lo que el término correcto sería "interfiriéndose", no solapándose. En caso de interferencia queda por encima el que se haya definido más tarde en el código.

Si cambiamos el modo de posicionamiento con la propiedad position y usamos alguno de los disponibles para poder colocarlos de manera relativa, absoluta, fija, etc... lo que ocurre es que estos elementos se salen del flujo normal de la página y se colocan en donde les corresponda, interfiriendo con cualquier otro elemento "normal" que hubiera en esa ubicación. Es decir, al posicionar un elemento éste interfiere con los demás elementos que ocupen su misma posición. Quedará por encima el que esté definido más tarde en el código, como en el caso comentado en la nota anterior.

Para poder controlar qué elemento se va a visualizar en caso de interferencia por posicionamiento existe la propiedad z-index. Gracias a ella podemos indicar en qué nivel queremos que esté cada elemento sobre el plano, decidiendo de esta manera cuál es el que se va a ver por encima de los demás.

Así, por ejemplo, consideremos este sencillo código HTML:

<div id="sc1" class="sc"><div class="caja roja">HOLA</div></div><div id="sc2" class="sc"><div class="caja verde">HOLA</div></div><div id="sc3" class="sc"><div class="caja azul">HOLA</div></div>

En él tenemos tres elementos con un <div> dentro cada uno de ellos. He establecido el CSS para que los divs interiores sean cuadrados y tengan un color diferente para verlos bien.

Nota: aunque los divs "padre" no son necesarios en general y, de hecho, en este caso se colapsan, quedando sin dimensiones, me interesa tenerlos para el ejemplo posterior, así que de momento no te preocupes por ellos.

Como sabemos, si no le cambiamos el posicionamiento quedarían unos debajo de otros, apilados en la vertical (posicionamiento estático):

Si les ponemos un posicionamiento absoluto, sin indicar realmente posición alguna, estarán todos colocados en (0,0) y por lo tanto interferirán en el mismo plano y el que se verá es el último: el azul:

Vamos, que es como si sólo tuviésemos uno a efectos de visualizarlos.

Ahora los voy a posicionar para que se muevan y se vean todos a la vez, pero interfiriendo unos con otros:

Ahora los vemos todos, pero como se interfieren parcialmente, unos se tapan a otros, tapando el azul al verde y éste al rojo que está debajo de todo por ser el primero en el código.

Si queremos que uno de ellos prevalezca sobre los demás independientemente de dónde esté en el código, podemos ponerle un z-index superior a lo de los otros:

¡Perfecto! Justo lo que queríamos. El CSS sería:

.caja {
    width: 200px;
    height:200px;
    position: absolute;
}

.roja {
    background-color: coral;
    top: 0;
    left: 0;
}

.verde {
    background-color: lightseagreen;
    top: 100px;
    left: 100px;
    z-index: 1;
}

.azul {
    background-color: skyblue;
    top: 200px;
    left: 200px;
}

Al ponerle un z-index:1; al segundo elemento (y tener todos ellos un posicionamiento absoluto), lo que estamos haciendo es colocarlo un nivel por encima del del documento "base", que es donde están los otros dos cuadrados, por eso se ve por encima.

Muy sencillo ¿no?

Cuando z-index no hace caso

Pues va a ser que no...

El problema de z-index es que parece muy sencillo (un número y listo), pero puede llegar a complicarse. Y es entonces cuando aparecen los problemas y nada parece funcionar. Vamos a verlo con un ejemplo sencillo.

Sigamos con la estructura anterior de cuadrados. Sólo voy a hacer un cambio muy pequeño: al div contenedor del tercer cuadrado le voy a aplicar una rotación con este estilo:

#sc3 {
    transform: rotate(360deg);
}	

Es una tontería, ya que lo deja tal cual estaba (girarlo 360 grados es dejarlo en la misma posición), pero me servirá para demostrar una cosa.

Nota: podría haber hecho otras muchas cosas con él, como cambiarle la opacidad un poco, aplicarle una máscara o aplicarle una ruta de recorte (propiedad clip-path), entre otras muchas cosas. Luego las veremos.

Ahora al cuadrado azul, el que está contenido en ese div que hemos rotado, le aplicamos un z-index:2;, es decir mayor que el del segundo cuadrado, el verde, por lo que en teoría debería quedar por encima, ya que está posicionado sobre él en el plazo Z:

¡No funciona!

Este es uno de esos casos en los que, hagas lo que hagas con z-index no podrás ponerlo por encima.

Muchos desarrolladores Web, cuando se encuentran con un problema como este lo que hacen es ponerle un valor muy grande a la propiedad z-index, tratando de "ser el que más arriba está", en plan z-index:9999; y cosas así. Eso no vale para nada.

¿Cuál es el motivo de que es no funcione?

Contextos de apilamiento (stacking contexts)

Para entender por qué un determinado elemento "no hace caso" del z-index hay que entender qué es un contexto de apilamiento.

Por defecto, siempre existe al menos un contexto de apilamiento que es el que se crea en el elemento raíz de la página (<html>). Es en este en el que se apilan todos los demás elementos de la forma que hemos visto antes.

Pero, además de este, se pueden formar muchos otros contextos de apilamiento dentro de la página. En concreto, se forman contextos de apilamiento en elementos que cumplan alguna de estas condiciones:

• Si están posicionados con absolute o relative y tienen un z-index aplicado (distinto de auto, el valor automático por defecto), como los tres cuadrados de nuestro ejemplo.
• Si tiene posición fixed o sticky.
• Si es hijo de un elemento Flexbox o Grid que tenga un z-index aplicado (nuevamente no auto).
• Si se le aplica una opacidad parcial, es decir, si no es totalmente opaco (un valor tan grande como opacity:0.9999; sería suficiente).
• Si se le ha aplicado alguna transformación (transform), filtro (filter), máscara (mask), perspectiva o ruta de recorte (como he comentado más arriba).
• Si se han hecho mezclas fotográficas o de colores o se le ha aplicado aislamiento.
• Si se ha cambiado su modo de contención de elementos.
• Si se le indica al navegador que el elemento va a cambiar en el futuro, para resolver problemas de rendimiento.

En general se puede decir que se forma un nuevo contexto de apilamiento cuando sacamos un elemento del flujo normal de la página, sea con el método que sea (todos los de la lista anterior lo hacen de un modo u otro).

Cuando se forma un nuevo contexto de apilamiento lo que ocurre es que todos los elementos hijos del que lo ha formado pasan a gestionarse con él, en grupo, y su propiedad z-index ya no tiene efecto sobre los demás elementos fuera de este contexto.

Esto es la clave: la posición en Z de sus hijos sólo tendrá influencia sobre otros elementos del mismo contexto de apilamiento.

Interferencia de los contextos de apilamiento

Sólo nos falta un detalle más: conocer cómo se relacionan entre sí los contextos de apilamiento.

Si hay más de un elemento que forma su propio contexto de apilamiento en una página (algo que pasa constantemente), en caso de que estos elementos interfieran entre sí, el orden de visualización es el siguiente, idéntico al de los elementos individuales que hemos visto antes:

1. Abajo de todo de la pila, en el nivel 0, se visualiza el elemento raíz, que forma su propio contexto de apilamiento, el global. Lo que se ven son los bordes y el fondo del elemento raíz de la página (el elemento <html>). Es importante señalar que, aunque le pongas a algún elemento hijo del raíz un z-index negativo, no podrá estar nunca por debajo del elemento raíz.
2. Justo encima se visualizan los elementos posicionados con un z-index negativo. Estos no pueden estar por debajo del raíz, pero sí por debajo de otros elementos.
3. A continuación se ponen los elementos no posicionados, es decir, los que tienen position:static, que es el valor por defecto, en el orden de aparición en el código fuente (los que están definidos más tarde, se ven por encima en caso de interferencia).
4. Luego se colocan los elementos posicionados de diversas formas (absoluta, relativa...) que no tienen un z-index especificado (lo tienen en auto).
5. Finalmente se colocan los elementos posicionados que además tienen un z-index positivo.

Sabiendo esto es fácil ver por que en nuestro ejemplo el cuadrado azul no se ve a pesar de que le hayamos puesto un z-index altísimo... ¿Sería capaz de ver el motivo?

Te lo voy a mostrar en un vídeo en el que te lo explico de manera visual:

[youtube:DlVMx1nS9gk]

En resumen

En más ocasiones de las que nos gustaría, las cosas en HTML y CSS parecen mucho más sencillas de lo que son en realidad. Una de estas cuestiones aparentemente fáciles, pero que tiene mucho más fondo del que parece, es el posicionamiento vertical de elementos, controlado por la propiedad z-index, que influye en qué elementos se ven cuando se solapan varios.

Existen dos conceptos clave para entender el posicionamiento vertical: los contextos de apilamiento y la prioridad cuando se produce una interferencia entre elementos.

En este artículo, basado en material de mi curso HTML5 y CSS3 a fondo para desarrolladores de campusMVP, te explico con detalle esos conceptos para ir más allá de lo que sabe el desarrollador medio sobre el tema, y ayudarte a evitar cualquier problema que te pueda surgir a la hora de aplicar la visibilidad vertical de elementos.

Además vemos un ejemplo práctico del problema, con un vídeo explicativo que te ayuda a entender qué pasa y cómo solucionarlo. Puedes descargar el ejemplo desde aquí (ZIP, 0,6Kb).

¡Espero que te resulte útil!