¿Sabes reclutar a un profesional de las IT?

Llevo 35 años entre teclados y ordenadores. Muchos años. Un cúmulo de experiencias y miles de horas pensando, resolviendo, aplicando predicciones, controlando errores… bien, esa es la vida del programador. En estas últimas décadas todo ha cambiado, no se si a mejor, pero ha cambiado, y mucho. Cuando empecé a programar en serio, usando el lenguaje COBOL, tenías tiempo para aprender un lenguaje hasta los apéndices de su manual. Tenías la posibilidad de dominarlo, de convertirte en experto. La próxima versión no aparecería hasta 5 o más años después. Aún así, algunas veces nos perdíamos en la espesura y los mensajes de error crípticos. Y pasó el tiempo, hasta llegar a Internet, la WWW, el mobile… un cúmulo de plataformas nuevas, distintas, con lenguajes y paradigmas diferentes a todo lo anterior. La nube se nos apoderó. De todos. Hoy día es difícil encontrar una aplicación «de escritorio» en lugar de su contrapartida en versión web. En suma, la cantidad de lenguajes, plataformas, arquitecturas y conceptos que manejamos los profesionales del sector es, cuando menos, abrumador.

Me atrevo a postular que hoy día nadie puede alzarse con la etiqueta de «experto» en nada relacionado con la programación. Es imposible. Nadie puede dominar ni un solo lenguaje antes de que aparezca una nueva versión, que con suerte deja obsoleta la anterior o peor, antes de que sea sustituído por un nuevo lenguaje «más rapido», «más fácil», «más seguro»… Así pues todos llegamos a ser mediocres, en mayor o menor grado, pero mediocres. No hay tiempo físico disponible para leerse tomos de mil páginas y, aún menos, asimilarlos para poder aplicarlos. Así son las ciencias de la computación hoy día. Tienes que poder tratar con muchas opciones a la vez, intentar jugar bien con ellas, que combinen lo suficiente como para que el resultado sea, al menos, decente.

El Agilismo parece la solución final, la panacea. Y muchos quizás no sepan que el Agile Manifesto tiene más de 20 años de antigüedad… (publicado en 2001, lo tienes más abajo). Ahora es cuando hay que aplicarlo si o si, a ultranza y sin pensar en otra cosa, y recuerdo que la programación paralela casi me cuesta el puesto de trabajo por allá los inicios de los 2000. Bien, está bien que se quiera poner orden en algo tan caótico como la programación, más cuando ésta se realiza en equipo y cada cual tiene sus criterios y sus formas de hacer las cosas, sus manías y sus genialidades. Pero el Agilismo nos deja encima de la mesa una colección de términos y siglas, tales como DDD, TDD, SOLID, buenas prácticas, programación extrema, programación paralela, etc. que, cuando veo una oferta de trabajo y las contempla todas como requisitos fundamentales, además de media docena de lenguajes de programación, unos cuantos frameworks, tres o cuatro sistema de bases de datos y un largo etcétera de cosas más, me pregunto quién redacta esas ofertas y en qué está pensando, o mejor, en quién piensa que puede haber abarcado tal cantidad de tecnología aplicada en un periodo de tiempo razonablemente corto.

Nadie.

Tal como he dicho, la mediocridad nos impide ser expertos en conceptos tales como el Domain-Driven Design, las Unit Tests, los principios SOLID, las buenas prácticas de tal o cual lenguaje, la administración del sistema operativo, la conectividad con sabe nadie qué redes, colas, bases de datos y sistemas alienígenas remotos, y además, dominar cinco o seis lenguajes de programación hasta la excelencia última. Y no sigo añadiendo más cosas, porque la idea está clara, ¿cierto?

Dejando a un lado que alguien pueda conseguir una puntuación de 10 sobre 10 en todo lo anterior (excepciones las hay en todo, cómo no), ¿no sería mejor intentar ponderar cada uno de estos conocimientos según su impacto en el puesto de trabajo, y en el trabajo en sí, para valorar a un candidato de una forma más equitativa y precisa?

Pongo por caso que saber programar con un lenguaje orientado a objetos tiene más valor que con un lenguaje que no lo está. O que es más valorable un lenguaje de programación de aplicaciones que uno orientado a scripts (aunque eso dependa del puesto de trabajo). ¿Es mejor saber usar WordPress o Joomla? ¿Y administrarlos? ¿Y programar plugins para los mismos? Ah, plugins. ¿Qué es eso? No voy a seguir añadiendo palabrotas y siglas… pero así es como las ofertas de trabajo aparecen. «Se requiere PHP, Java, C#, .NET, SQL, TDD, DDD, SOLID, SCRUM…..»… ¿en serio? Muchas de esas listas incluso son contradictorias… y vuelvo a lo anterior: darle un peso, una puntuación a cada palabra, a cada requisito, a cada aptitud, y entonces quizás los filtros sean más precisos y cumplir 3 de 8 aptitudes, según nuestros perfiles, no sea tan malo, ni cumplir 9 de 10 sea tan bueno.

Hace algún tiempo un usuario de un canal de chat sobre programación, en general, preguntaba dónde podía encontrar un libro, un tutorial, una guía sobre cómo programar, así en general. Buena pregunta. Porque al fin y al cabo programar no es más que plasmar un proceso que, en primera instancia, hay que pensar. Y eso nunca se pide como requisito, saber pensar y resolver un problema, convertirlo en uno o más procesos, y luego plasmar esos procesos en programación. Esa compentencia parece darse por sentada, como si todos los programadores pensaran de la misma forma, con la misma velocidad y precisión, con la misma elegancia y solución para un mismo problema o situación.

Si has llegado hasta aquí y eres recruiter, habrás visto que no es sencillo valorar a un profesional a base de listas de términos. Hay mucho más detrás de cada uno de ellos, y más allá, hay una persona que aplica todos esos conocimientos, tenga muchos o pocos o distintos, para enfrentar cada problemática a su manera, con la mayor eficacia y eficiencia posibles.

Estoy pensando en dejar la programación y pasar a reclutar personal IT. En serio. Muy en serio.

Principios del Manifiesto Ágil

Seguimos estos principios:

Nuestra mayor prioridad es satisfacer al cliente
mediante la entrega temprana y continua de software
con valor.

Aceptamos que los requisitos cambien, incluso en etapas
tardías del desarrollo. Los procesos Ágiles aprovechan
el cambio para proporcionar ventaja competitiva al
cliente.

Entregamos software funcional frecuentemente, entre dos
semanas y dos meses, con preferencia al periodo de
tiempo más corto posible.

Los responsables de negocio y los desarrolladores
trabajamos juntos de forma cotidiana durante todo
el proyecto.

Los proyectos se desarrollan en torno a individuos
motivados. Hay que darles el entorno y el apoyo que
necesitan, y confiarles la ejecución del trabajo.

El método más eficiente y efectivo de comunicar
información al equipo de desarrollo y entre sus
miembros es la conversación cara a cara.

El software funcionando es la medida principal de
progreso.

Los procesos Ágiles promueven el desarrollo
sostenible. Los promotores, desarrolladores y usuarios
debemos ser capaces de mantener un ritmo constante
de forma indefinida.

La atención continua a la excelencia técnica y al
buen diseño mejora la Agilidad.

La simplicidad, o el arte de maximizar la cantidad de
trabajo no realizado, es esencial.

Las mejores arquitecturas, requisitos y diseños
emergen de equipos auto-organizados.

A intervalos regulares el equipo reflexiona sobre
cómo ser más efectivo para a continuación ajustar y
perfeccionar su comportamiento en consecuencia.

Técnicas de Web scrap

De la página Web a datos estructurados

¿Qué es el Web scrap? Explicado de forma simple no es más que «rascar» una página Web para obtener información de la misma. Así de sencillo.

¿Qué tipo de información podemos obtener de una página Web? Cualquiera que se presente en la misma: imágenes, vídeos, ficheros adjuntos, documentos, o bien la misma información textual que aparece en ella. Datos numéricos, textos, etc.

Las razones para capturar datos de una página puede ser muy variados. Desde el deseo de salvaguardar su información, según nuestros deseos, hasta obtener datos para ser más tarde tratados. En el primer caso, quizás nos interesa guardar una galería de imágenes completa, sin tener que hacer clic en cada imagen de forma manual. O quizás descargar algunos ficheros adjuntos, tales como libros, vídeos, música, etc. En el segundo, quizás queramos capturar información de horarios de trenes, reservas de hotel, precios de productos, cualquier cosa.

En todo caso antes de cualquier proceso de captura tenemos que investigar cómo funciona la página Web en cuestión. Para ello hay que seguir los pasos necesarios, de forma manual, para llegar hasta la información deseada. Y en cada paso, examinar las entrañas de la página en cuestión. Esto es, ver el código fuente para localizar los elementos que contienen la información buscada.

Por tanto, el primer requisito es contar con un navegador que permite inspeccionar los elementos de la página, o cuando menos, ver el código fuente completo. Prácticamente todos los navegadores permiten lo segundo. Lo primero, es posible que necesite que activemos o instalemos lo que se llama «herramientas de desarrollo» para poder investigar concienzudamente el contenido de dicho código fuente con cierta ayuda.

Desde Chrome, viendo el elemento anterior

El segundo, conocer el lenguaje HTML o HTML5. Es básico para saber qué estamos observando en esa pantalla. Si no, nos parecerá poco menos que el código de Matrix.

HTML utiliza lo que se conoce como etiquetas. Estas actúan, en su mayor parte, como contenedores. Los hay de diversos tipos, como DIV, para diferenciar bloques, P, para párrafos, LI, para listas, A, para los enlaces o links, etc. Además, para que dichas etiquetas sean «únicas» o al menos pertenezcan a un mismo tipo, éstas pueden tener atributos que indiquen una clase determinada (usadas para aplicar estilos CSS, por ejemplo), o incluso un identificador único dentro de toda la página (con frecuencia esto se usa en los formularios de entrada de datos).

De cualquier modo, lo interesante es que los contenedores que queramos leer sean lo más inequívocos posibles. Así estaremos asegurando que leemos un dato concreto y no otro.

Cuando digo «leer» me refiero a que un programa debidamente escrito sea capaz de encontrar un dato sin posibilidad de error. O no encontrarlo en absoluto.

¿Y con qué escribimos dicho programa?

Depende del gusto personal. Hay muchos lenguajes de programación, y muchas librerías que permiten hacer la lectura de páginas Web. Incluso hay utilidades de terminal, es decir, que se ejecutan como un comando de línea, que son factibles para el scraping. Por ejemplo, CURL o WGET. Para usos sofisticados es muy complejo sacarles partido, pero es posible.

Mi opción personal es el lenguaje Python junto a un par de librerías básicas: requests y BeautifulSoup. Ambas en conjunto permiten leer una dirección URL y pasarla por un parser o intérprete de texto para aislar los elementos HTML (las etiquetas o contenedores) y sacar partido de los mismos.

La instalación del lenguaje, si es que no está disponible en nuestro sistema, es bastante fácil. Desde la página oficial de Python, http://www.python.org podemos instalar el lenguaje para cualquier sistema operativo soportado.

Asimismo, las librerías o módulos de terceros para Python suelen ser instalables con el comando pip, de esta forma:

pip install módulo

donde módulo es el nombre de la librería. Por ejemplo:

pip install bs4

instalará BeautifulSoup versión 4, y

pip install requests

instalará la versión más reciente de la librería requests.

Resumiendo, con Python y esas dos librerías ya podemos armar un Web scrap.

Dificultades

Superados los requisitos anteriores, es decir, sabemos qué lenguaje usar, conocemos HTML para identificar elementos, etc. el Web scrap no está exento de dificultades. Algunas de las más frecuentes son:

  1. La página Web no nos permite usar ningún tipo de lectura mecanizada, es decir, detecta que no es un humano quien interactúa con ella.
  2. La página se carga y completa mediante Javascript o similar, lo cual quiere decir que nuestro programa no verá la página tal como un humano, ya que ésta se genera después de cargar el código fuente, ejecutando una serie de procesos de forma asíncrona.
  3. Se requiere la identificación del usuario, esto es, hay un formulario para introducir el usuario y clave de acceso. Da los mismos problemas que el caso anterior.
  4. La programación dinámica de la página sólo funciona con interacción humana, por lo que es necesario simular la misma.
Selenium puede usar Firefox, Chrome, etc.

Antes de tratar con estos casos, hay que decir que existen miles y miles de páginas que no ofrecen esta resistencia y se pueden aprovechar para el proceso de scrap. Así que no hay que desanimarse. Para todo lo anterior existe la librería Selenium. La veremos en otra ocasión.

La quinta

Si, será la quinta vez que destruyo por completo mi sitio Web y lo pongo otra vez en marcha.

Tras el intento de utilizar el mínimo posible un software de terceros, vuelvo a WordPress, pero sin demasiadas ganas de añadir muchas «cositas brillantes». Con texto y alguna imagen es más que suficiente.