Aventuras de la hackathon (Los niños jugando en el jardín): Sábado Parte II / V of IX

Los mitos y las siestas obligadas

10:00 El mundo despertando y yo aguantando el sueño

Cansado, tenso, preocupado coloque en el lector lo que seria una versión de Kubuntu de 2012 pensando en que esa distribución seria muy pesada para el ordenador que tenia entre manos.

La instalación no demoro demasiado, el promedio de instalación de las distribuciones era una media hora o poco más, si se actualiza mientras se instala (todas las distribuciones te preguntan si quieres hacer eso conscientes de que el core que tienes entre manos no tendrá los cambios posteriores que día a día suceden en el mundo linux) depende de cuanto halla de "nuevo", la conexión a internet, etc.

Recordemos que mi inteligencia aun me tenia con un cable de red de unos 40kb de transmisión. 

La instalación funciono estupendamente. CD sano, sistema reconocido, todo correcto. 

12:00 Todos menos tu... A jugar!!!

Cuando la hackPeum empezó creo que mi compañera entro en un momento de pánico. Uno de sus compañeros no tenia ordenador y el otro ESTABA DESAPARECIDO... Con horario diferente (para España eran las 12:00 y en su país (Argentina) eran las 07:00.

Además se encontraba frente a otra dificultad: No es mucho de front y esta hackathon apuntaba a eso más que nada. Ella es más de Back y con Java. O sea que Js que seria el lenguaje de la batalla ESTABA SOLA!!!!. 

Mi admiración hacia ella cuando dijo: "No pasa nada... Vamos a ver que se puede hacer".

Con una tablet que odia internet, unos ojos que se cerraban, una descorazonada sensación que no llegaría y un 33% de los miembros del equipo perdidos entramos a la reunión para el comienzo de la Hack.

¿Que puedo decir de la comunidad de PEUM?. Cuando se dan estas reuniones mi primer pensamiento siempre es ¿porque no lo hacemos más seguido? Pero en fin... Vamos a los hechos que se alarga el Post

Terminada la reunión repasamos en privado las peticiones, condiciones y demás. Y claro. Había que buscar información, material e ideas para hacer el código.

Genial ahí Laura (Lau) enseguida encontró la información (un poco pude mirar de la api elegida) y empezó a pensar en ideas (tuvo dos buenas ideas, se pillo una y en la hack hubo otro equipo que hizo a su manera la otra pero eso es un secreto que jamas será publicado) y con todo en contra empezó a codificar. Mi admiración.

Apareció Juan Manuel (malows)  enseguida se acoplo a la ida y entre los dos empezaron a darle caña. ¿Y saben que? En ningún momento hubo un rechazo a mi situación, jamas fue rebelado mi inutilidad en ese proyecto y ningún reproche.

Durante esa conferencia de equipo hubo risas, ideas, y momentos de dudas. Pero sobre todo un ambiente genial. Gracias a los dos por eso.

Me dormí.... 2 veces (las confesiones liberan el alma). No podía más y soy mal voyeur. Si no participo me duermo, eso de toda la vida, por eso no me gustan los deportes... De verdad... Puede ser la final del mundo de fútbol o la película más interesante que si me quedo quieto mirando y nada más me duermo. A eso agreguemos que llevaba sin dormir desde el día anterior, más la auto presión por llegar...  estaba destruido (no se puede decir que no me excuso adecuadamente).

Sin embargo ahí estuve casi todo el rato y cuando la hack termino a la 20:00 pude ser testigo de algunas de las presentaciones (desde la tablet aun). 

Tampoco ahí mi equipo expuso mi situación para ganar puntos por contar con uno menos... Chicos os quiero!!!

No ganamos pero quiero repetirlo con un ordenador funcionando. Que buena gente tan diversa se reúne allí.

En fin. Volvamos a mí ordenata. Paso la hack  y estaba un poco decepcionado, cansado, triste....

Sin  muchas ganas abrí mi sistema y el Kubuntu estaba raro (deberás leer más adelante para saber el origen de este mal), la actualización iba a demorar y las ventanas del GUI no se actualizaban correctamente. Más dificultades ahora nooooo!!!

Bueno. Volví a mí cajón de los recuerdos pero esta vez enfocando el hard. Quería ver si podía agregar algo a la artillería del ordenador para poder volver al curro rápidamente. (solo faltaba ser despedido para completar la semanita que llevaba) 

Encontré memorias como quien encuentra agua en el desierto pero... No valían. El motherboard usa DDR2 y las que yo tenia eran DDR o anteriores (más decepción), cables, recuerdos, placas incompatibles y mucho cansancio. No podía más así que a eso de las 22:00 aprox caí rendido. Mal día, malos resultados, mejor terminarlo ya...

Aventuras de la hackathon (La verdad sobre el mac mini): sin día especifico. III of IX

Recuerdos olvidados

Hace un tiempo empece con las app móviles. Y lo que habíamos elegido (el equipo de entonces) era Appcelerator que es un framework js.

El principal problema de ese desarrollo era iOS  que solo permitía la creación de las app en un ordenador con el sistema operativo de Mac.

En principio eso no fue un problema porque nuestra ignorancia de aquel entonces no nos dejaba ver algunas cosas que luego fueron evidentes.

Las app así como las aplicaciones de escritorio tienen dos opciones: respetar el sistema nativo o no.

El desarrollo con herramientas como Appcelerator te orientan a un si. O sea. Aquellas "particularidades de los OS" mantenerlas como el sistema nativo.

Cuando nos enfrentamos a ello teníamos un problema por delante. Yo usaba una distribución Linux en un portátil compartido con un sistema Windows pero nada de Apple (por elección  propia nunca he tenido nada de Apple la verdad)

Así que intentamos encontrar la solución. Primero optamos por un sistema de conexión remoto. Las primeras pruebas que hicimos requerían un horario especial de mi parte porque usaría un mac que durante los horarios de oficina tenia otras finalidades.

El resultado fue un poco desastre. No se para que lo voy a negar. Al final la maquina asignada no era demasiado potente, estaba sin actualizar (en Mac mantener el xcode actualizado es indispensable para el desarrollo ya que es el corazón de todo el código) y la conexión de red dejaba mucho que desear. Sin embargo íbamos adelantando a medida que podíamos.

Así llegamos al punto que el jefe que tenia por aquel entonces tenia un socio que vendía ordenadores Apple (si, si. Esto fue así). Yo me quede un poco en blanco. ¿Si estas vendiendo app móviles para clientes de iOS porque no tener los equipos adecuados si además tenia un socio que le podía facilitar las cosas?

Misterios de Misterios de la vida. Así llegamos a que (como siempre el trabajo de un programador no es evaluado en su justo valor) había por ahí una mac mini que había "petado" pero que se podía ver de enviarla al técnico.

Asi se hixoAsí se hizo. ¿Que le había pasado al Mac? pues que por una sobrecarga habían petado algunos componentes así que se cambio el disco duro y las memorias y funciono perfectamente.

SSí has leído hasta aquí ya estarás sacando las mismas conclusiones que yo saque aquella noche fatídica. La sobrecarga dejo tocada la tarjeta gráfica pero como no era evidente no se cambio, también era la posible causa de todos los problemas de hard de ese ordenador y ahora yo sufría las consecuencias simplemente por tener recuerdos olvidados

Aventuras de la hackathon (La revelación): Viernes II of IX

El factor humano

"Es el monitor... Es el monitor" seguía pensando cuando a media mañana (bueno, seré sincero, era ya cerca de las 12:00) me desperté. 

Tenia planes. Lo que me mantendría a salvo de la desaparición todo estos días venideros era eso. Tenia planes. Continuamente.

Comprobe que todo estaba como antes de acostarme con la vaga y torpe esperanza que solo hubiera sido una mala interpretación de lo que estaba pasando y que todo estuviera resuelto.

Bah, ¿que puedo decir?. La vida continuaba adelante a pesar de mis necesidades, emociones o intereses. Todo seguía igual. El mac mini y el monitor no se comunicaban.

Comí. Fui, vine, Apague el ordenador y el monitor, los desconecte. Puse el mac mini y sus cables  en una mochilita y salí a la calle. 

17:00 Volviendo al mundo

Nada había cambiado por las calles del pueblo a pesar que las recorro poco o nada. Me encamine a una tienda de un cliente mio de venta de segunda mano de ordenadores y videojuegos.

Llegue con mis piezas y le pregunte si podíamos comprobar monitores y no hubo ningún problema, así que me dio un lugar en su taller donde el técnico también estaba allí y empecé a probar monitores (con paciencia que recordemos que al inicio el monitor y el mac mini no se comunicaban).

20:00 emm... Gonzalo... Tenemos que cerrar

5 Monitores después (unos de marca, otros no), cambio de los dos adaptadores, cambios en los cables vga, diferentes combinaciones, el resultado era el mismo.

Una pausa: cualquier persona con un poco de experiencia en hardware hubiera sabido rápidamente cual era el problema en este punto o incluso unas horas antes pero yo seguía agobiando, bueno seguía no es la palabra, me iba agobiando cada vez más. 

Llevaba una semana buena en horas pero estaba en un punto delicado del proyecto y estaba por entrar una persona nueva al equipo que trabajaría sobre una parte del código que yo había desarrollado y me hubiera gustado dejarlo más preparado pero no, la vida no quería eso para mí... Juas.

Volvamos a la tienda. Hora de cerrar. Hable con mi cliente y le comente mi situación. Se ve que me vio mal de verdad porque me ofreció una solución. 

Un ordenador de sobremesa Pentium D con 2gb de memoria, disco de 160Gb sata y el OS Win7 instalado.

No vi muchas alternativas y me pareció que eso era mucho mejor que no tener nada. La verdad fue 

como una pequeña luz en la oscuridad. 

Volví a desmontar mis cosas y salia de la tienda con un ordenador nuevo bajo el brazo. 

21:00 Listo. Lo has solucionado. Deja de escribir!!!

¿Os conté que el día siguiente teníamos la hackPeum? 

Si, si, todo se acumula. Una razón de centrarme en hacer más horas de forma comprimida esa semana era tener el sábado más relajado para participar en la hackathon que además (y a pesar de perder a mi compañera del año pasado) tenia dos compañeros con los que me quería hacer código. 

En casa ya monte el ordenador y conecte el monitor. ¿Saben que? el monitor funcionaba.

Inicio el ordenador. Todo correcto. Conecto el cable de red. Lo configuro como "Red domestica" según los parámetros de Windows. El sistema se reinicia y upsss: "Inserte un disco bootable"

Ummm. El disco duro estaba dando problemas... Vale, no pasa nada. Tranquilo, tranquilo!!!!!, respira.

Este inconveniente lo vi más como una oportunidad de instalar algo que aprovechara mejor las capacidades limitadas de ese equipo.

Si, si, si. Estoy hablando de Linux por supuesto. Así que abrí mi baúl de la abuela (del abuelo en este caso) y empece a buscar entre CD's y DVD's abandonados.

Hay gente que se pone melancólica con fotos pero a mí me entro melancolía con los conectores, cd, discos duros, y adaptadores varios que tenia de mi historia por este mundo de la informática.

Reconozco que demore más de lo que debía buscando lo que tenia que buscar: Un conjunto de DVD's (algunos etiquetados, otros no) de distribuciones Linux variadas.

22:00 Manos a la obra de la primer noche larga de muchas

Hay que reconocer que no tenia del todo claro cual seria la mejor opción y como soy un bicho emocional tenia preferencia por dos distribuciones etiquetadas en especial: Kubuntu 12.04 y Xubuntu (sin versión en la etiqueta)

Una cosa de las distribuciones Ubuntu. El versionado indica el año.el mes de la release. Y las LTS son los años pares en el mes de abril. Por lo tanto Kubuntu era una LTS de 2012. (3 LTS por detrás de la ultima). 

Tenia la sensación que a lo mejor para este equipo Kubuntu era muy pesado así que comencé por Xubuntu. (Es una distribución de Ubuntu pensando en los equipos antiguos como el que tenia).

Al principio la instalación fue fenomenal para que negarlo, pero dejar un DVD abandonado tanto tiempo tiene sus consecuencias. Fallo en el disco. Pufff para mi pero bueno, había más.

Antes de dejarme llevar por el corazoncillo (Tengo emociones muy intensas con KDE) mire otras distribuciones que tenia etiquetadas: 

Google OS: Fallo en un reconocimiento de hardware que no tengo claro a que se refería.

Wifi Way; Una distribución para la seguridad de las redes que solo funcionaba desde el CD-ROM y no estoy seguro de que sirviera como distribución linux para el desarrollo de mi trabajo.

Y una sin etiquetar que en realidad es un conjunto de herramientas para la recuperación de disco, análisis de memoria y periféricos sin tener que bootear algo más que el mismo DVD.

A todo esto la medianoche se había pasado. Y el post se hace demasiado largo así que pasemos al siguiente día con la primer alegría y decepción en cuanto a instalación: Mandriva 2010.

No sin antes contarles la historia verdadera tras ese Mac mini. Detalles que habia olvidado.

Aventuras de la hackathon (El problema): Jueves I of IX

La obsolencia programada

Día 23 / 05 / 2019.

Ya hacia días que estaba lloviendo, como pronostico de los futuros eventos pero claro yo iba como siempre metido en mis cosas y no vi las señales del destino.

Primero un poquito de historia que sin ambiente las anécdotas no son igual de aburridas (😉).

Yo trabajo en el desarrollo web y de app móviles desde hace un tiempo utilizando un mac mini (no es mi elección preferida de OS, simplemente que lo he tenido que adoptar para el desarrollo de iOS).

El Mac y yo no nos llevamos bien, eso es desde siempre. De un tiempo a esta parte además Apple no lo actualiza más (es de la primera mitad del 2009), tiene múltiples fallos continuados y poco a poco he ido perdiendo software y herramientas de desarrollo (por ejemplo la ultima versión de php 7.3 o el frameworks para pruebas unitarias de php phpunit ya no se actualizan ni instalan en El Capitán)

Aparte de esos inconvenientes estaban los de hardware (el monitor se desconectaba cada tanto, perdía el teclado y debía reconectarlo y varios programas se quedaban colgados tras un uso prolongado. De vez en cuando (dos veces cada 15 días más o menos) el equipo se reiniciaba solo cuando quería.

Pero ojo. si esperas artículos en contra de Apple o Mac vas por mal camino. En realidad todo tenia otro origen y pronto hablaremos de ello.

18:00 aproximadamente:

El monitor que uso es de Pc (plano y antiguo) conectado mediante un adaptador al mac mini. Cada tanto el monitor perdía contacto por lo que siempre había asociado a que el adaptador debía ser cambiado (es el segundo monitor PC que uso con este Mac y desde un tiempo pasaba eso)

Ese día a esa hora el monitor se apago como siempre. Mi reacción fue de hastío mental y de rutina física. Desconecte el adaptador, apague el monitor, luego reconecte todo. 

Esta rutina es la que siempre había funcionado y tampoco sabia que más hacer así que cuando una hora más tarde seguí repitiendo el proceso y no cambiaba nada un cierto estado de miedo empezó a entrarme en el cuerpo... Algo iba mal... Peor que como siempre por lo menos.

19:30... Mismo día... Cabeza en estado de pánico total.

El disco duro del ordenador funcionaba correctamente. El teclado y el mouse parecían correctos. Solo había un fallo en la pantalla. Había muerto pero... ¿porque?. La luz de stand by del monitor funcionaba y podía apagarlo y encenderlo correctamente.

Me dije (19:45)- ¡El adaptador!!! Eso seria. Mire la hora y salí corriendo a la tienda a toda prisa. Cosas de la vida llegue 10 minutos después del cierre pero el técnico de la tienda estaba allí repasando unas anotaciones antes de cerrar.

Y a pesar de no vender ordenadores Apple si tenían ese adaptador para el monitor. Listo. Era feliz. El problema se había solucionado.

Pues el tema es que solo había comenzado una secuencia de sucesos que me llevaron a escribir estos artículos.

21:30... Mismo día... (¿Este día no se termina más o que?)

El adaptador nuevo no había cambiado nada. Tenia el mismo problema. El monitor y el mac mini no se comunicaban y ambas cosas parecían funcionar correctamente. Me hice cena. Comí. Volví. 

La decisión que me pareció más lógica en ese momento era reiniciar el sistema así que puse el oído sobre el mac y cuando el disco duro hizo silencio un ratillo supuse que era buen momento para reiniciar desde el botón de apagado sin que eso llevara otras consecuencias.

El Mac con un monitor de Pc tiene una particularidad y es que no esta "disponible" desde el arranque (o por lo menos ha sido mi experiencia) por lo que el ordenador arranca el proceso de inicio y cuando llega a la gui se comunica con el ordenador. Así que una vez iniciado debía esperar un poco (¿Cuanto es un poco?) para ver resultados en el monitor.

A todo esto el monitor sin actividad al encenderlo empezaba a dar unas rayas rápidas como de frecuencia incorrecta o algo así.

Tenia que encenderlo y apagarlo (porque dejarlo encendido sin mas lo llevaba al stand by que era como si nada) varias veces para que eso se fuera.

(05: 00) ... Hay gente que puede dormir. 

Nervios de punta, caminando por mi habitación para arriba y abajo. Nada funcionaba. Llevaba dos reinicios del ordenador y tenia miedo por el estado del disco duro (que no daba señales de estar mal pero la paranoia no pide razones). Ya había insultado para mis adentros toda la familia de los Mac's, iMac's, y cualquier cosa relacionada con una manzana mordida (incluido Adán y el pecado original).

Deje el ordenador y el monitor encendidos y cansado y nervioso como estaba me deje vencer por el sueño con un último pensamiento en la cabeza "Es el monitor, es el monitor..." 

Esa gente que se pasea por mi oficina

Trabajar en casa es una oportunidad, un reto y hay a quien le gusta y a quien no.

Hay muchas versiones sobre si es un paraíso o un infierno. Hoy quiero contar algunas verdades porque ni es un paraíso ni tampoco un infierno pero si pide un cambio de mentalidad cuando lo empiezas a hacer.

Horarios
La fantasía mayor que hay con respecto al trabajo en casa es que uno puede trabajar en cualquier horario sin problemas y hacer la vida que quiera porque no hay horarios... ERROR!!!

Trabajar sin horarios es llamar al caos sobre todo porque no creamos la presión de completar los trabajos en determinado tiempo y sin esa presión solemos distraernos bastante con otras cosas porque "Ahora me pongo y lo hago" y mientras el día avanza y avanza.

Los horarios son importantes y cumplirlos mas. Sobre todo para poder disfrutar del resto del día sin pensar que aun tengo que hacer esto o aquello.

Disciplina
Esto es nuevo para muchos de nosotros cuando trabajamos en casa. Porque eso nos viene impuesto con el trabajo presencial.
Ahora somos nuestro propio jefe y eso no es nada fácil de hacer de buenas a primeras. No solo la imposicion de horarios es importante, deberíamos tener objetivos, imponernos castigos (y cumplirlos), bonificaciones por logros alcanzados, metas alcanzables pero no infantiles (ser serios en estos puntos nos hará mas eficaces), optimizacion de nuestro tiempo y evitar las distracciones (sobre todo las propias).

Familia
Un tema difícil. Hay momentos que la familia debe respetar nuestro espacio como si no estuviéramos ahí. Estamos trabajando, sin embargo nuestros horarios deberían adaptarse al ritmo familiar (horas de colegio, comidas, etc.) y aprovechar a ser mas activo en la vida familiar sin que eso nos impida hacer nuestra labor y cumplir unas horas de trabajo eficaces para poder rendir adecuadamente. La clave: (el siguiente punto)

Organizacion 
La organizacion es algo tan personal que existen mil teorías de como llevarla a cabo. Yo creo sinceramente que las formulas existentes son guias para luego realizar nuestro propio método nacido de nuestra experiencia personal.
Los horarios familiares (despertar de los hijos, escuela, la hora de comer, horarios de la pareja, etc.) Nos pueden ayudar a iniciar un sistema óptimo en el cual podremos "negociar" los tiempos necesarios para poder llevar a cabo nuestra labor.

Como nos ven
Trabajar en casa tiene (aun hoy en día) una imagen un poco confusa para la gente que no lo hace.
Escucharas gente que te dice que tienes mucha suerte, que es una buena oportunidad, etc y gente que te dirá que trabajar en casa no es trabajar...
La mayoría tiene un preconcepto (equivocado al 90%) de lo que es trabajar en casa y se forman una opinión poco fundamentada de lo que significa.
En ese punto hay que tener paciencia a veces y recordar que aunque aun hay una cantidad creciente de personas que trabajan así es una manera bastante nueva de trabajar y que tampoco es posible en todas las profesiones así que mucho nos pondrán la imagen de vagos (cosa que suena a envidia). Recordar: Paciencia.

¿Porque el titulo de este post? Porque trabajar en casa tiene un problema y es el desconectar.
Desconectar DEBE hacerse vivas en familia, solo o como sea.
Por eso los coworking han crecido, mucha gente prefiere alquilar una oficina compartida y no tener el trabajo directamente en su casa. Otros en cambio tienen una habitación / rincón / parte de la casa ambientada para trabajar.

Lo cierto es que hay que crear un cierto ambiente laboral en una zona de la casa para marcar una diferencia con el resto para que cuando no estemos en esa zona dejemos de pensar en trabajar...

Si no lo hacemos corremos el peligro de que estemos donde estemos de la casa todo lo asociemos a nuestro trabajo sin desconectar del todo y que al final y poco a poco cometamos el imperdonable error de ver a las personas que conviven con nosotros como "Esa gente que se pasea por mi oficina".

PHP is not dead

Releyendo la declaración de intenciones de este blog recordé uno de los objetivos de este blog que no es otro que compartir soluciones a problemas concretos que surgen mientras afrontamos un desarrollo.

Acostumbrado a las críticas no tengo reparo en anunciar que el lenguaje principal que manejo en mis desarrollos es PHP.
Eso no quiere decir que no haya probado o considerado las múltiples alternativas que tenemos a día de hoy: Java, Ruby, Python, algo de Microsoft... Grandes lenguajes y maravillosos frameworks detrás de cada uno de ellos sin duda, todos ellos válidos y con características que los hacen únicos para resolver situaciones específicas.

Respeto es la palabra que quiero remarcar en este escrito, pues si bien los candidatos son grandes proyectos en la web hay un solo rey. Es el lenguaje que cada año gana el premio al mas odiado. Es la cara de los meme de programadores y el chiste fácil entre estudiantes de tercero. Pero los números no engañan: a día de hoy PHP es usado en el 79% de los sitios de internet directa o indirectamente. 4 de cada 5 páginas que visitamos en la web hacen uso de este lenguaje y es una realidad.

¿La decadencia de PHP?

Es cierto que en los círculos de programadores backend se ha intentado dar por muerto a este lenguaje en mas de una ocasión.
No podemos obviar que durante mucho tiempo ha sido el lenguaje mas usado a la hora de desarrollar servicios web, y eso tiene pros y contras: como baza se puede aportar la enorme comunidad que alimenta la red de soporte al lenguaje y a todos los frameworks y librerías que han catapultado a PHP a ser el líder en cuanto a desarrollo web por parte de servidor se refiere. ¿Su punto débil? Paradogicamente es la facilidad con la que cualquier programador puede usar el lenguaje. Si bien permite que programadores con poco conocimientos puedan hacer uso de su potencia (a priori esto se podría considerar una cualidad positiva) muchos programadores opinan que estos trabajos (y en muchos casos con razón) no superan los mínimos estándares de calidad. ¿Un poco raro no? En mi opinión culpar a PHP de que haya programadores noveles intentando hacerse paso es similar a culpar al castellano por permitir que (ponga aquí al grupo o cantante que más odie) cante o escriba sus canciones. No somos tan radicales, ¿verdad?

Nunca es tarde si la dicha es buena

Las previsiones siempre son malas para PHP. No hay temporada que no aparezca como uno de los lenguajes mas odiados por los programadores. Teniendo en cuenta su campo de acción (aplicaciones web) y su uso (79%) cuesta entender esos resultados negativos. No seré yo el que diga que esas estadísticas no son reales, pero de serlo estamos hablando de una gran comunidad de programadores que dicen odiar su trabajo. En cualquier caso, es posible que esta gente que año tras año vota a PHP como lenguaje mas odiado no conozca algunas características del mismo:

-Es código abierto. Puedes usarlo y modificarlo a tu gusto sin dar cuentas a nadie.
-Su comunidad. El 80% de las webs están escritas en PHP. No tendrás problemas en encontrar sitios o gente que hablen de este lenguaje.
-Su rendimiento. Es cierto que las versiones anteriores de PHP eras más lentas que sus competidores. A día de hoy con la última versión estable (7.3) no hay nada que envidiar a los demás lenguajes. ¡A estas alturas es incluso más rápido que NodeJS!


¿Y ahora qué?

Yo no quiero convencer a nadie. En proyectos de alta concurrencia uso NodeJS. He tenido que programar en .NET por exigencias del guión. Y tengo que reconocer que no ha sido tan traumático como pensaba. Ese no el mensaje que quiero trasmitir. Los lenguajes de programación, los frameworks, los IDES...son solo herramientas para desarrollar nuestro trabajo. Es bonito encariñarse o defender el medio de nuestro sustento pero los fanatismos, como en otros contextos, restan mas que suman.

Mi lenguaje principal es PHP. A veces me siento orgulloso del código que pico pero no tengo nadie con quien compartirlo. Cada día aprendo cosas nuevas, tanto del lenguaje como de las buenas prácticas. También me ocurren cosas raras, y se quedan en el olvido. Es por eso que este post es el inicio de un nuevo hilo de post dedicados a recopilar curiosidades y anécdotas relacionadas con PHP que espero sean de ayuda o recordatorio a ese 80% de programadores web que usamos este lenguaje.


La imagen usada de morguefile.com pertenenciente  a Jackileigh: https://morguefile.com/creative/jackileigh/1/all

Qué es ser un desarrollador agile

Antes de nada quiero dejar claro que no hablo desde el conocimiento acreditado de la materia, hablo principalmente desde la experiencia de pasar a metodologías agile y ver cómo se ha experimentado el cambio a mi alrededor. El fin de hacerlo es dar un punto de partida al debate o al menos a la reflexión individual sobre qué implica esa forma de trabajar en lo que respecta a los desarrolladores. No cambia nuestro nombre, seguimos siendo equipo de desarrollo, pero ¿hemos pensado si cambian nuestras funciones?

En una metodología tradicional en cascada (bien entendida, no en la que se quiere todo para ayer y nadie hace una mínima reflexión) el proyecto pasa por una fase de análisis en la que hay distintas "cabezas pensantes". Generalmente, si se trata de un proyecto o empresa de cierta envergadura, el equipo estará jerarquizado y en esta fase intervendrá el jefe de proyecto, junto con un arquitecto técnico y quizá alguien del equipo de calidad o de UX o similares. Todos estos generalmente no serán luego parte activa del equipo sino que habrán generado toda una documentación, infrastructura y bases y se encargarán de dirigir o revisar los aspectos propios de cada área. ¿Que le queda al equipo de desarrollo? Picar código. ¿Que se espera de ellos? Que lo piquen.

Quiza he simplificado mucho. En esto, como en casi todo, hay mil matices, formas y circunstancias. Pero, en general, de un equipo de desarrollo tradicional, lo que se espera es que construya el producto tal cual se pensó en el tiempo que se estimó. Para ello el jefe de equipo se encargará de controlar y organizar, adquiriendo la responsabilidad última del proyecto y llevandose los palos o los aplausos segun vaya la cosa. Por otro lado cada desarrollador se responsabilizará de la parte de la aplicación que le toque trabajar.

En agile (bien entendido también, no como un simple faseo del proyecto en N proyectos cascada) las jerarquías se difuminan. El proyecto se divide en "pequeños cachitos" que no habrán pasado por esa gran fase de análisis. En el momento de planificarlos se analizarán entre todos y la idea es que todos aporten para sacar la solución más adecuada. Esto implica el primer cambio en los desarrolladores porque, para que su intervención sea real y productiva necesitan:
1. Conocimiento tanto funcional como técnico de todos los ámbitos del desarrollo para, poco a poco, ser capaces de aportar más y mejor y detectar antes las dificultades o impedimentos.
2. Habilidades sociales y capacidad dialéctica para proponer y exponer de manera clara tanto a personas del ámbito técnico como no técnico.
3. Capacidad de escucha activa, de dialogo, asertividad y empatía para que, en conjunto se lleguen a soluciones válidas y a acuerdos sobre cómo llevarlas adelante.

Evidentemente al inicio no tendrá la misma aportación un junior que un senior o una persona que lleva años trabajando aplicación que alguien que acaba de llegar. Hay que limar esas diferencias, ahora bien: ¿queremos? ¿Queremos conocer los entresijos de la facturación para hacer la aplicacion de gestión si nosotros somos seniors que estamos investigando la tecnología molona que vamos a emplear? ¿nos apetece escuchar la opinión del nuevo sobre otra librería para hacer la descarga de ficheros distinta de la que nosotros dominamos? Como junior, a mi que me digan qué tengo que hacer, que no cobro para responsabilizarme de tanto.

Ese es otro punto clave: la responsabilidad. Y es que si todos hemos aportado para dar esa solucion, la hemos estimado, la hemos analizado y nos comprometemos con ella, entonces todos somos los responsables de lo bien o lo mal que vaya, ¿no?

Cuando todo va bien, esto gusta: no hay uno llevandose las alabanzas como jefe mientras que otros son los que se han pegado con ello. Si a alguien le surge alguna dificultad no es "su" problema, es de todos y es responsabilidad de todos que salga adelante. Se tiene un equipo de verdad, en el que, como en los equipos de futbol o baloncesto, cada jugador desde sus direfencias aporta al conjunto y se siente parte de él. O todos ganan o todos pierden.

Sin embargo ¿que pasa cuando vienen mal dadas? Entonces esa responsabilidad no apetece tanto y era mejor cuando el jefe de proyecto "aislaba" los problemas o al menos volcaba el problema en el responsable de esa parte. "¡Si yo de ese tema no toqué nada!", "Yo ya dije en la planificación que eso llevaba más tiempo", "Lo tenía que haber hecho yo que me conozco mejor esa parte", "Yo hice lo que me dijisteis" y otras tantas frases empiezan a surgir. Todo son "balones fuera" y dedos acusatorios. O lo que seguramente es peor: silencios. Porque la palabra revela cosas pero el silencio vale sólo por lo que oculta. Y lo que oculta es que nos falta la característica principal del equipo: CONFIANZA. Confiar en que los compañeros son profesionales, en su compromiso, en que las criticas son constructivas y hacia el equipo y no personales y con intencion de "dejar mal". Confiar en que se puede hacer mejor entre todos. Confiar en que todos tienen algo que aportarme y quieren hacerlo. Confiar en que nosotros tenemos algo que aportar y podemos hacerlo.

Seguro que me dejo más cualidades importantes, pero como decía, esto es solo un punto de partida a la reflexión. Ahora es el turno de que, quien quiera, se mire su ombligo y el de su equipo. ¿Sois agile? ¿Creeis que se valoran estas características en vuestro equipo? ¿Echáis algo en falta?