Autocrítica y mejora contínua

Jul 03

jjballanoFormación, Saraos 14 Comments

Por diferentes conversaciones que he tenido ultimamente, llevo unos días dándole vueltas al tema de la autocrítica y a lo poco que la usamos.

Hace unos días estuve hablando sobre el movimiento 15M y la falta de autocrítica que hubo en ese movimiento. Se culpaba de la situación actual a banqueros, al gobierno, a los mercados, etc… pero nadie decía “me metí en una hipoteca que en cuanto me subieran un € no podía pagar”, “conseguí que me tasaran el piso un poco más de su precio real para poder comprarme un coche también” o “no ahorré ni un € por si venían mal dadas, prefería gastarme todo lo que ganaba en vacaciones, salir a cenar fuera y de compras”. Realmente los bancos, gobiernos, etc tienen mucha culpa de todo lo que está pasando y movimientos tipo 15M (para mi con algunos cambios, pero ese es otro tema) me parecen imprescindibles, pero igual de imprescindible creo que es que la gente haga autocrítica y la gente que está pasando problemas económicos ahora mismo (que tienen todo mi apoyo, por supuesto) piensen en qué fallaron ellos para no volverlo a repetir en el futuro.

Ayer estuve en el open space llamado “la esencia de Scrum”, donde la idea era hablar sobre los valores que hay por debajo de Scrum y también sobre el propio Scrum. En una de las sesiones, propuesta por Emma y Raquel, se empezó hablando de qué es mejora contínua, por qué la queremos, si hay que apostar por ella o comprometerse con ella, etc. Una conversación muy interesante que acabó con una conclusión (entre otras muchas) y es que la empresa limita la mejora de los trabajadores. En cada sesión tratábamos de en los últimos 5 min decir con qué nos quedábamos de la sesión para escribir unos post-it y pegarlos sobre el tablón para que los demás que habían ido a otra sesión pudieran ver más o menos de qué se habló. En ese momento yo dije que lo que sacaba de la sesión es que no había visto ningún tipo de autocrítica, porque seguimos buscando excusas externas a problemas internos.  Traté de explicar en la propia sesión por qué para mi el decir que la empresa me limita es una excusa más, pero creo que no supe explicarlo y acabó pareciendo que quería decir que ya era perfecto y que no tenía como mejorar… A ver si ahora lo puedo explicar mejor :)

Para mi una empresa puede facilitar o no el crecimiento personal y profesional de una persona, su aprendizaje, etc, pero no limitarlo. Haciendo un simil con el camino de Santiago, estoy en Roncesvalles y quiero ir hasta Santiago, todo andando como buen peregrino. La empresa podrá darme un buen material deportivo, podrá poner en cada km del camino una botella de agua para que beba si tengo sed e incluso si estoy muy mal podrá poner a una persona que me lleve a hombros unos kms. O la empresa podrá ponerme una mochila con ladrillos y dejarme a mi aire a ver si llego. Es decir, la empresa me podrá facilitar las cosas o podrá ponérmelo más difícil, pero si quiero llegar hasta Santiago llegaré, con más o menos esfuerzo.

En resumen, la empresa podrá crearme el ecosistema perfecto para que mi mejora contínua sea más sencilla, más rápida y mucho más provechosa para todos, o podrá ponerme trabas, pero si quiero que mi mejora contínua sea tal, podré hacerlo mientras yo quiera. Puede que llegue un momento en que no sepa como mejorar (por aquí venía mi lío que hizo que pareciera que estaba diciendo que yo soy perfecto…) porque dentro de mi empresa no tenga nadie que me apoye o me ayude a dirigir mi mejora, pero para eso se organizan una serie de eventos donde conocer gente nueva y que te dirija un poco. Puede que como equipo dentro de la empresa no sepais como mejorar (lo mismo, hay otras formas fuera del trabajo para ello) o que por ejemplo la empresa no te permita mejorar tu proceso (te puede decir que eso de Scrum para la gente de Rugby) y tengas que buscarte la vida para mejorar por otro lado, pero no habrá empresa que te diga que no intentes hacer cada vez mejor software, que no aprendas un poquito más sobre el lenguaje que estás usando, que no aprendas más sobre patrones, o sobre BD, o sobre lo que se te ocurra… Y además, tienes más horas en el día aparte del trabajo para aprender y practicar lo que te de la gana.

Alguien me dijo un vez: “estoy cansado de escuchar a gente decir que hay cosas imposibles para no hacer cosas que son muy difíciles”. Por lo tanto, más trabajo si tu empresa “no te permite” mejorar y más autocrítica para no culparla de seguir igual que hace 6 meses.

He dicho!! (y ahora podeis discutirme lo que querais ;) )

Code Retreat en Valladolid

May 08

jjballanoFormación, Metodologías ágiles, Saraos Comments Off

Este fin de semana he estado en un Code Retreat facilitado por Enrique Comba.

¿Qué es un Code Retreat? Es un formato creado por Corey Haines donde unos cuantos programadores locos con mucho vicio (locos que madrugan un sábado para programar…) y muchas granas de mejorar, se juntan durante un día entero para desarrollar en iteraciones de 45 minutos el Juego de la Vida, en cualquier lenguaje. Se desarrolla siempre en parejas, haciendo TDD y en cada iteración hay que cambiar de pareja y borrar el código que hemos hecho antes.

Al principio suena un poco raro, pero acaba sorprendiendo lo mucho que se puede llegar a aprender realizando siempre el mismo problema. La idea es que como no tenemos la presión de tiempos, de clientes, de jefes ni nada parecido, nos centramos en hacer las cosas bien y aprender de los puntos de vista y modos de trabajo de la pareja con la que estamos en el momento.

En esta ocasión hicimos la friolera de 8 iteraciones, despertando la admiración de otros code retreats. Porque además este ha sido un día especial en este tipo de eventos, ya que se realizaron 6 simultaneamente, uno en UK, otro en Bélgica, dos en Rumanía, uno en EEUU y el nuestro. Pudimos comunicar vía Skype con el de UK, el de Bélgica y uno de Rumanía. Además de que teníamos en pantalla grande una web que mostraba todo lo que se estaba diciendo en Twitter con el tag #coderetreat, lo cual hacía que vieras lo que estaban diciendo en otras partes del mundo sobre lo mismo que estabas haciendo tu.

Compartí iteraciones con @semurat, @amaliahern, @ArturoHerrero, @eduferrandez, @mariotux, @kinisoftware, @isidromerayo y otro (con el que hice la iteración de refuctoring) que si lee esto me diga su nombre porque soy taaaan desastre que no lo se :(  Cosas interesantes en todas y cada una de las iteraciones. Programar en PHP o Groovy y no tener ningún problema, atacar el problema de diferentes formas (aunque eso suponga volver loca a mi pareja), que en la última iteración Enrique diga “ahora lo vamos a hacer con orientación a objetos de verdad” cuando llevas 7 iteraciones (y varios años) intentándolo o “todavía no he visto un código limpio” o que en la sesión de refuctoring (hacer el peor código que podamos) diga “no es tan diferente el código de ahora al que he visto antes”, ver que el TDD as if you meant it (hacer todo el código en el propio test y sólo sacarlo a método cuando se repita, y luego si hay métodos que huelan a clase sacarlos) es una práctica tan difícil y dura como interesante. Y en resumen, 8 iteraciones donde aprender mucho pero ver que todavía te falta mucho más por aprender de lo que pensabas.

Mi retrospectiva personal sobre el code retreat de ayer la resumo en 2 puntos:

  • Mi TDD y mi diseño orientado a objetos ha mejorado mucho desde el anterior code retreat (por Octubre o algo así del año pasado), aunque me falta, por suerte, muchísimo por mejorar.
  • Guié demasiado. Tengo la sensación que en todas o casi todas las iteraciones fui yo quien decía por donde atacar el problema en vez de ser algo más consensuado. Punto a mejorar.

Mucho que agradecer a:

 

Buena metodología + buen entorno de trabajo = Un nuevo mejor adaptado

Apr 07

jjballanoFormación, Java, Metodologías ágiles 4 Comments

Hace ya casi un mes que he empezado a trabajar en IPSA y ya en este tiempo he visto la diferencia que tiene la forma de trabajar con respecto a las otras tantas consultoras por las que he pasado. Lo primero es que aquí se hace producto, no se hace software a medida. Esto en sí no es mejor ni peor, es sólo un modelo de negocio.

Lo primero que sorprende a alguien como yo acostumbrado a la vorágine de las consultoras, es que aquí llevo 4 semanas haciendo pair programming. Esta me parece la mejor forma de hacer que alguien que entra nuevo aprenda más rapidamente. Estaba acostumbrado a que el “arquitecto” de turno me soltara una charla de 20 minutos sobre como está todo, y en seguida ponerme a desarrollar. Por supuesto solía ser una aplicación que tiene un diseño chusquero y los test automáticos es de esas cosas que haremos al final si da tiempo y que nunca daba tiempo porque ya íbamos con semanas/meses/años (sí sí, años!!) de retraso.

En estas semanas en IPSA he confirmado junto a Alfredo (y Xavi Gost en la semana que pasé con él) mis sospechas de que haciendo test automáticos todo es mucho más sencillo. Da igual si quito esto, si pongo esto otro aquí o si cambio esta línea por esta otra, tengo una batería de unos 3000 test (si no recuerdo mal) que respaldan que no estoy rompiendo nada. Y claro, por cada cambio que hago no voy a pasar yo a mano todos esos test, para algo está algo llamado servidor de integración contínua. En este caso usamos Hudson, pero da igual cuál de las herramientas elegir, lo importante es tener algo que nos de la tranquilidad de que si hemos roto  algo con un cambio nos enteremos como mucho con 1 día de diferencia, y no a los 6 meses cuando instalemos en producción.

Otro avance importante es Scrum. Entré justo a trabajar el día de una demo de final de sprint y me sirvió para ver un poco de qué iba la herramienta. Sólo vi una parte pequeña, pero al menos me sirvió para hacerme alguna idea general. Mucho mejor una demo que el jefe de proyecto de turno te cuente durante 2 interminables horas lo que están haciendo. Además la reunión diaria ayuda para ver que está haciendo cada uno con lo que también te das cuenta de hacia donde avanza el proyecto.

Las prisas son malas consejeras. En este último sprint no entró una historia que había planificada porque faltaba por hacer una tarea de 2 puntos. Corriendo se podría haber hecho pero, ¿para qué? ¿para hacerlo corriendo y arriesgarnos a hacerlo mal?

TDD me ayuda a centrar lo que quiero hacer. Ya pensar el nombre que le voy a dar el test me obliga a tener muy claro qué es lo que quiero hacer. Si no lo tengo claro (y muchas muchas veces he empezado a desarrollar algo sin saber exactamente lo que tengo a hacer) me será imposible elegir nombre. Y lo mismo para hacer el código de ese test.

En resumen, si quieres que la gente nueva que entra en tu equipo sea productiva más rapidamente, dales el entorno adecuado para que aprendan lo más rápido posible. Si quieres que no te rompan nada mientras aprenden ten toda la aplicación a prueba de manazas como yo con test automáticos de todo lo que sea posible. Si quieres que se hagan las cosas bien, no quieras las cosas para ayer, desarrollar algo en condiciones lleva su tiempo. Y si quieres irte a casa y dormir tranquilamente, pon un Hudson (o similares) en tu vida.

Internship en Valencia

Mar 11

jjballanoFormación, Metodologías ágiles 2 Comments

Acabo de llegar de pasar una semana con el gran Xavi Gost en BeCode. A la gente no metida en estos mundillos me cuesta explicarles qué he hecho. No entienden como puedes coger una maleta para unos días, comprar unos billetes de tren e irte a otra ciudad distinta de la tuya a “trabajar” gratis. Yo trato de explicarlo de la siguiente forma: “¿cuánto cuesta un curso? Pues en vez de pagar ese dinero, yo me pago una estancia en donde sea y aprendo mucho más en vivo y en directo, porque aprender a hacer tu trabajo se consigue trabajando”. Y qué mejor que aprender a ser un buen profesional, trabajando codo a codo con grandes profesionales.

Por desgracia Xavi ha estado muy liado con otras cosas y no he podido sacarle todo el jugo que me hubiese gustado, pero me traigo un montón de cosas distintas que he aprendido:

  • Soy capaz de ser productivo con un lenguaje para mi casi desconocido como es Javascript. Hasta ahora no había hecho más que validar formularios y cuatro cosas más. Ahora sin conocer todavía realmente el lenguaje, ya me atrevería a meterme en un proyecto con él. Realmente ya me he metido a hacerlo, ya que todo el código que he picado en estos días en BeCode ha sido en Javascript y no me he sentido nada incómodo.
  • Una nueva forma de trabajar. Trabajar con tarjetas de colores en función de si es un bug, una deuda técnica, una historia, etc ayuda a que de un golpe de vista sepas más o menos lo que le falta a tu proyecto y ayuda a enfocarse en lo realmente importante. Por ejemplo, ver una tarjeta roja en el tablón para Xavi es motivo de “parar las máquinas”. Todo el mundo para hasta que ese bug deje de aparecer. No significa que esté solucionado, pero sí que al menos no molestará al resto. Ya sea siendo tan radical o no, es importante que los bugs nos duela verlos en el tablón y los quitemos cuanto antes.
  • Me falta disciplina con el TDD. En alguna ocasión me he visto tratando de cambiar código sin tener un test fallando. Para eso Xavi me regañaba diciendo “qué haces? tienes un test fallando?”. No es que no supiera hacer el test, es que por mi falta de disciplina y una costumbre de no hacer TDD, me hacía irme directamente a hacer ese cambio que veía claro. Creo que esto es un punto a mejorar, aunque cada vez lo tengo más interiorizado.
  • Quería hacer cosas distintas y hoy mismo por la mañana hemos hecho una mini-inception de una cosa que tengo entre manos. Quería saber cómo enfocar el análisis de un proyecto que te cuentan con 4 palabras y 4 gráficos. Ha sido algo corto pero he aprendido cómo enfocar este tipo de cosas. Aparte de los consejos, que me son muy útiles, sobre este proyecto en concreto, quería “ver en acción” como actuar.
  • Por casualidad, he coincidido que estaba preparando una consultoría para mejorar la forma de trabajar de una empresa (motivo por el que no ha podido dedicarme el tiempo que quería). He visto cómo gestiona este tipo de consultorías e incluso he tenido la suerte de asistir a la presentación que ha hecho en la empresa donde les ha explicado cómo deben trabajar. Es un caso concreto, y no servirá para todas las empresas, pero sí el estudio y la forma de abordarlo ayuda a saber cómo atajar problemas que muy probablemente acabe teniendo en algún momento en el futuro.

En resumen, me traigo semillas de muchas cosas y ahora me toca a mi regarla para que salga la flor. No quiero hablar demasiado de proyecto, tecnologías y cosas más concretas porque me parece mucho más importante todo lo demás que decir si he trabajado con el framework X o el lenguaje Y.

La experiencia de un internship es algo que merece y mucho la pena y creo que repetiré de vez en cuando. Y por supuesto se lo aconsejo a todo el mundo, sobretodo a la gente que no se ha movido mucho de trabajo y lleve años haciendo lo mismo en el mismo sitio de la misma manera. Es una bocanada de aire fresco que viene muy bien.

Grandes errores

Feb 09

jjballanoFormación, Otros 3 Comments

Llevo unos días “discutiendo” en el foro de alumnos de la universidad donde estudié. Esta discusión empezó con un alumno que está buscando una beca para empezar en este mundillo y pedía opiniones de diferentes empresas. La opinión de este futuro profesional (esperemos) era que él no quería “estar picando teclas”, que para esto “están los de FP”, que “como Ingeniero nosotros tenemos que hacer cosas más de gestión de proyectos” y que por eso “le llamaba mucho más una beca donde le ofrecían hacer labores más de gestión y que no tocaría código”. Voy a ir comentando cada una de estas malas ideas que nos meten (al menos fue mi caso) en la cabeza los profesores de la universidad (no es una crítica al alumno en cuestión, yo salí con la misma idea de la universidad):

  • Picar teclas: Hay peor manera de desprestigiar nosotros mismos nuestra profesión que diciendo de forma despectiva “picar teclas”? Por qué nos empeñamos nosotros mismos en destrozar nuestra reputación? Somos idiotas o algo? Alguien ha visto a un arquitecto decir “pintar dibujitos”? Desarrollar es mucho más que aporrear un teclado… Requiere un conocimiento muy bueno de lo que se tiene entre manos, una práctica y experiencia brutal, un nivel de concentración importante, incluso una chispa de inspiración! Para desarrollar no vale cualquiera, para “picar teclas” sí.
  • Para programar están los FPs: Para empezar, diré que la FP de informática según está montada en España me parece una aberración (si estoy equivocado en algo rectificadme, que esto es lo que yo tengo entendido). No es posible que con 1,5 años, de los cuales hay asignaturas de orientación laboral y tal, manden a un tío unos meses de prácticas (muchas veces de las de llevar cafés al jefe porque la empresa COBRA por que tu estés allí) y luego le den un titulito como que sabe desarrollar… mal empezamos. Después, el desarrollo como he dicho requiere un nivel de conocimientos y de destreza que ni siquiera todos esos ingenieros de título tienen… Creo que con estas expresiones desprestigian algo tan importante como HACER SOFTWARE. Hacer software no es hacer un Gantt, hacer software es mancharse las manos, remangarse y ponerse codo con codo con un equipo y sacar adelante el proyecto. Esto no es cosa ni de FPs, ni de Ingenieros mega-guays, ni de porteros de discoteca… esto es cosa de gente con conocimiento para hacerlo! Lo que pasa es que hay mucho Ingeniero Informático que no sabe hacerlo y prefiere ocultar su ignorancia entre UMLs y si luego no funciona decir que son los “picateclas” que no han sabido interpretarlo.
  • Los Ingenieros están para gestionar proyectos: ¿Cómo vas a gestionar un proyecto si no has hecho uno en tu vida? ¿Cómo puedes tomar decisiones de estimaciones si no has programado más que 1 añito usando el framework de moda? ¿Cómo vas a poder elegir tecnología si todavía estás asimilando los conceptos de la universidad de los árboles B+? Para gestionar proyectos, primero haz 200! demuestra que cualquier decisión que hay que tomar en un proyecto lo sabes hacer mejor que nadie de tu equipo y luego, si acaso, dirígeles.
  • Beca de gestión de proyectos: Esto me ha parecido ya la repanocha… una beca para la gestión de proyectos? Que mi trabajo lo va a estimar un becario? Qué va a ser él quien me diga lo que tengo que hacer? No me lo creía, y me ha mandado la oferta literalmente:

    Colaboración en gestión de proyectos de Tecnologias de la Información y las Comunicaciones, participando en actividades de: – Soporte a los Jefes de Proyecto en la elaboración de ofertas técnicas, en el diseño y planificación de los proyectos en relación a las especificaciones y requisitos técnicos definidos, y posterior seguimiento de proyectos (SLA´s, hitos, plazos…). – Soporte en la instalación y configuración de servidores y aplicaciones. – Soporte en la elaboración de informes de seguimiento de proyectos, incidencias y estado de sistemas. – Apoyo en la relación con fabricantes de tecnología, partners y proveedores.

    Elaboración de ofertas técnicas? diseño y planificación? Seguimiento? Todo esto un becario? De verdad? Y sí, lo mejor que puede hacer un becario es llevar la relación con partners y proveedores… “oye mira, soy el becario de la empresa X, que me dice mi jefe que para cuando me vais a tener listo esto… es que le corre un poco de prisa, ¿sabes? me ha dicho que os insista mucho mucho, hasta que me lo tengáis listo. ¿Hola? ¿Hay alguien ahí? Vaya, otro que me cuelga…”.

Da mucha pena lo que hay en las universidades. Luego, los mismos que dicen todas estas cosas son las que están dando palmas con las orejas de que se acabe de crear el Excelentísimo y Real Colegio de Super Ingenieros Informáticos Molones, porque van a luchar por nuestros derechos y por fin todos los males de esta profesión se van a acabar, ya que sólo podremos trabajar informáticos en un proyecto de software.

No culpo a los alumnos… culpo a ese entorno nocivo y poco informado que hay entre una parte del profesorado (al menos el que yo conozco, y con muy honrosas excepciones), que son funcionarios acomodados que la última vez que programaron lo hacían en tarjetas microperforadas. ¿Esa gente es la que está preparando a nuestros futuros profesionales? ¿A esos profesionales que seguirán haciendo software que nos facilitará nuestra vida? Al menos es la que les está mal formando y les está metiendo ideas tan equivocadas como peligrosas.

Qué Uncle Bob nos pille confesados….

PD: Soy Ingeniero Informático, por si hay dudas.

Cambiando a la universidad española

Jan 18

jjballanoFormación, Otros 4 Comments

El título del post para muchos será una utopía, algo inalcanzable… o quizás para otros sea algo no necesario porque ya está bien.  Trataré de explicar en este post mi visión y mis primeros pasos para tratar de cambiarlo.

Hace poco, hicimos un evento que llamamos 15en5 (por el número de slides y el tiempo para contarlas) unos cuantos amigos donde cada uno exponía sobre el tema que le daba la gana. Hubo desde temas sobre música hasta magía, pasando por otras más técnicas o la búsqueda de nuestra Alicia particular entre otras charlas igual de interesantes. Mi charla fue sobre los problemas que veo en el sistema educativo universitario actual en el mundo de la informática (no conozco el estado actual de otras carreras/sectores). Traté de darle un formato divertido con imágenes que poco o nada tenían que ver con la charla, pero que me servían bien para explicar lo que quería. Es decir, mi objetivo fue plantear entre risas un mensaje para mi muy serio.

En resumen lo que conté fue que a día de hoy (y de ayer también) los recién titulados salen sin saber absolutamente nada. Pero nada es nada! Y lo que es peor, en la mayoría de los casos les da igual no saber nada y el interés por la profesión que han elegido es casi nula, queriendo únicamente ir al trabajo y cobrar a final de mes, importando poco el cómo se hacen las cosas y si los resultados son buenos o no. Ojo, no hablo de lo que algunas empresas llaman “compromiso”, es decir, hacer todas las horas que hagan falta. Hablo de algo mucho más importante, el compromiso con uno mismo para hacer bien nuestro trabajo.

Yo achacaba estos problemas a varias cosas, en ningún orden en particular:

  • Profesorado poco cualificado. Hay profesores (muchos en lo que yo conozco) que llevan años y años sin saber lo que hay en la calle, lo cuál en este sector es un problema enorme. Si no sabes lo que hay fuera, ¿cómo vas a formar a los que van a salir?
  • Método de enseñanza. No es posible que una carrera tan técnica sea tan teórica. Esto hace que la gente se aburra mucho y que realmente no aprendan lo importante, que es trabajar! Me puedo saber un libro entero de sistemas operativos, pero si luego no he tocado uno en mi vida, mal asunto. Y no me vale la excusa de “bueno pero luego con un par de días tocando un SO vale, la base ya la tiene”. Con eso NO VALE. No asimilas igual los conceptos si te los cuentan o los repites como un loro, que si te has pegado con ello en una ocasión y has practicado “cienes y cienes” de veces.
  • Poco interés del alumno. Me cuentan algunos profesores que no hay interés por nada, que la gente se mete a la carrera porque algo hay que estudiar y porque tiene salidas. Esta gente o cambia de actitud o nos espera un futuro muy negro. Esta profesión es de ponerle interés y mucho, incluso fuera de tus horas de trabajo. Si no lo haces, estás perdido.
  • La universidad no es para todos, pero por un tema social quien no va a la universidad está tirando por la borda su futuro. Este tema da para mucho, por lo que lo dejaré para otro post.
  • Falta de conocimiento de lo que hay fuera por parte de los alumnos. La culpa aquí la reparto al 50% entre alumnos y profesores. Los puntos 1 y 3 explican por qué existe este problema. En este punto en la presentación hacía un símil entre diferentes cosas que podría pensar un alumno recién salido sobre determinados términos que pueden parecer una cosa y para trabajar son otra, por ejemplo “despliegues” (de aplicación o policiales), “test” (automáticos o de embarazo), “agilidad” (metodología o física), etc. La idea era decir lo que querríamos decir en un trabajo y lo que podría entender un recién salido que no sabe lo que hay “en la jungla” (como nos gustaba hablar del mundo laboral dentro de la unviersidad).

Pero mostrar los problemas sin buscar soluciones es de quejicas, así que hablé de cómo pensaba que se podría cambiar y de algunos pasos que voy a dar en la universidad donde estudié (la EUI de la UPM).

  • El primer punto de los problemas es el más difícil de solucionar porque hablamos de que los profesores que no conocen lo que se hace fuera son funcionarios (para mi, primer error grave), con puesto asegurado y que salvo que tengan vergüenza torera, seguirán dando la basura que se aprendieron hace años. Pero si no podemos cambiar a los profesores, consigamos que los alumnos estudien cosas fuera de la universidad y sepan separar el grano de la paja entre las asignaturas. Metámosles la idea en la cabeza de que vayan a eventos, que practiquen otras cosas en casa, que disfruten con lo que será su futuro trabajo… En este punto mi aportación es picar lo que puedo en el foro de los alumnos, poniendo eventos a los que voy a asistir, recomendando links, haciendo preguntas para ver el nivel que hay en determinada cosa… Además, he hablado con un profesor para colaborar con él en una asignatura que tiene sobre desarrollo y arquitectura, dando 2 o 3 charlas (o las que sean). En estas charlas quiero hablar de cosas que se quedan cojas en la carrera: Lenguaje de empresa (qué es un repositorio? que son los entornos de desarrollo, pre y producción?, cómo se trabaja habitualmente en la empresa? etc etc), test automáticos y calidad del código (este según vea el nivel) entre otros que pudieran surgir.
  • Quiero creer que el poco interés de muchos alumnos es por el desconocimiento. Creo que la forma de despertarles el interés es mostrarles lo que hay, mostrarles lo bonita que puede ser esta profesión. Esto trataré de hacer en las charlas de las que he hablado antes.
  • Buscar a los early adopters y tratar de llevarlos a mi terreno. Si consigo que entre las charlas aparezcan algunos con intereses y les puedo mostrar algunas cosas, es posible que sean ellos mismos los que a sus compañeros de clase consigan despertarles la curiosidad.
  • Enseñarles cómo está el mundo laboral a día de hoy. Para ello contaré con la ayuda de Wiseri que vendrá el día 24 de Febrero en el horario de 12 a 14 (los jueves en este horario es tiempo no lectivo para actividades extra-escolares de este tipo). Con esto busco 2 cosas, la primera es que vayan alumnos y vean qué se van a encontrar cuando dentro de unos meses salgan al mercado laboral. Y por otro, mucho más ambicioso, es ir acostumbrándoles a ir a charlas y eventos fuera de su horario laboral o de clase. Primero hay que tratar de que vayan a eventos donde ven un beneficio claro y rápido, luego ya se irá intentando que vayan a otros con un beneficio menos claro a priori.

Como decía al principio, el título del post puede parecer misión imposible, pero en el 15en5 Xavi Gost dijo una frase que me ha marcado mucho y que trato de tener siempre presente desde entonces:

Si te marcas objetivos mediocres y los consigues al 100%, habrás conseguido algo mediocre. Si te marcas objetivos imposibles, si consigues el 50% será la ostia.

Mi objetivo imposible es conseguir que todos los que salgan de la universidad sean auténticos profesionales. Sin conocimientos de muchas cosas, pero al menos con la actitud e inquietud necesaria para mejorar día a día.

Curso de Ruby on Rails – Parte 2

Jan 16

jjballanoFormación, Ruby 4 Comments

Voy a seguir esta “saga” de como hacer una aplicación muy sencilla desde 0 con Ruby on Rails. En el post anterior instalamos el entorno y creamos nuestro “Hello World!”, incluso lo subimos a Heroku para que nuestros amigos lo pudieran ver.

Pero nos apetece que nuestra aplicación tenga más “chicha”, verdad? algo que justifique el uso de RoR y no simplemente HTML plano. Pues vamos a crear algún scaffold que más adelante uniremos entre sí.

El primero que crearemos será el de los alumnos. Para ello, en una consola y estando en el directorio de nuestro proyecto, ponemos lo siguiente:

rails generate scaffold student first_name:string last_name:string

Le estamos diciendo que cree un scaffold llamado student con 2 campos string: first_name y last_name. De momento no necesitamos más, ya que Rails internamente ya nos meterá un id numérico, además de la fecha de creación y de última modificación (que puedes quitar si quieres). Si necesitamos más campos después, ya los añadiremos.

Si nos vamos a nuestro proyecto vemos que nos ha creado varias cosas: Un controlador, un helper, un modelo y una carpeta con varias vistas (las del CRUD). Como vemos, algunas cosas nos las ha pasado a plural, ya que Rails detecta los singulares y los plurales y te los pone de una u otra forma en función del tipo de fichero que esté creando (cuidado con esto si hacemos un scaffold de cosas como “person”, que su plural es “people” no “persons” y Rails lo sabe, que es muuuuy listo). Y ahora vamos a ver que tal nuestro CRUD y para eso entramos a http://localhost:3000/students. Pero… que pasa? no funciona!!! Lo primero, te has acordado de levantar el servidor? Lo tienes levantado y te sigue sin funcionar? Normal, has creado el modelo (fichero db/xxxxx_create_students.rb) pero no lo has migrado a la BD, vamos que tu BD no sabe que hay estudiantes ni los campos que tienen. Para hacer que nuestra BD se entere, vamos a hacer lo siguiente en la consola:

rake db:migrate

Ahora ya sí que nos debería de funcionar. Ya tenemos nuestro CRUD funcionando, podemos crear, borrar, consultar y actualizar a cualquier alumno. Que fácil, ¿verdad? Esto lo haría hasta un mono!

Hacemos lo mismo con las asignaturas en las que se matricularán los alumnos:

rails generate scaffold subject name:string
rake db:migrate

Podríamos haber hecho un sólo db:migrate para los 2 scaffold, pero aquí vamos paso a paso :)

Ahora vamos a meterle algún requisito a nuestro modelo, como que todo alumno tiene que tener obligatoriamente un first_name y que una asignatura debe tener al menos nombre, porque sino vaya asignatura…

Para ello, nos vamos al fichero app/models/student.rb y ponemos los siguiente:
Vemos que es muy fácil decirle qué campos tienen que ser obligatorios. Probadlo y ya veréis que funciona ;) No hago el del otro scaffold porque es igual y vosotros sois chic@s listos!

Ahora creemos que estaría bien enlazar esta nueva funcionalidad a nuestra página de inicio, porque es un rollo tener que andar jugando con la URL del navegador… Para ello nos vamos al fichero app/views/welcome/index.html.erb que definimos ayer, y ponemos los 2 enlaces a los scaffolds recién creados:

Qué cómodo, ¿verdad? No tenemos ni que saber donde está el controlador, simplemente le decimos el texto que queremos en el enlace y luego rails sabe donde redirigir cuando pongamos students_path.

Ahora en vez de avanzar, vamos a mirar un poco el código que se nos ha generado, ya que en algún momento tendremos que cambiarlo. Empezaremos por uno de los controladores, el del student para seguir un poco con el hilo del resto del post. Lo primero que vemos es una operación llamada “index”
Vemos que lo primero que genera es una variable de instancia con todos los alumnos que recoge de Student.all. Si queremos ver lo que hace esto internamente podemos ir a la ventana de la consola y veremos las sentencias SQL que se ejecutan. Después vemos algo de formatos… que raro parece eso… pues si nuestra aplicación la queremos en html nada más no sirve para mucho, pero y si queremos por ejemplo ver nuestra aplicación en xml? Pues Rails te la convierte automáticamente! Si accedemos a http://localhost:3000/students.xml esto nos devolverá la página pero en formato XML. Podríamos también usar json por ejemplo, añadiendo a la lista de formatos lo siguiente:

format.json { render :json => @students }

Cuidado, esto vale para la operación show, en otras igual hay que poner student (en singular). Fíjate en las otras de esa misma operación.

Vamos a ver otra, y ya el resto para vosotros:

Quería ver otra distinta a index porque es importante ver el detalle del params. Cuando vamos a algún controlador, Rails internamente nos ha creado el array llamado params con todos los parámetros de la petición. En este caso ha cogido la URL que había en el link de “show”, lo ha partido en trozos y lo ha metido en params. Luego con eso podemos acceder al :id (que si te fijas aparece en la URL del enlace) del alumno sobre el cuál queremos consultar sus datos.

Ahora vamos con las vistas. Si nos fijamos, el formulario de edición y creación de un alumno es igual. Para no repetir código, en RoR tenemos la opción de crear lo que se llaman “Partials”, que es sacar una parte de código a otro fichero y luego enlazarlo desde donde queramos. El nombre de estos partials tienen que empezar por el caracter “_”. En nuestro caso vemos que el directorio “views/students” tiene un _form.html.erb con los datos del formulario de edición y creación de usuario y que luego por ejemplo en new.html.erb tenemos un “render ‘form’ ” que lo que hace es colocar el partial form en ese punto. Rails automáticamente sabe que si le decimos “form” tiene que buscar en la carpeta actual un fichero con nombre _form.html.erb. Podríamos sacarlo a otra carpeta si creemos que lo podemos necesitar en otro lado y acceder con “render ‘otra_carpeta/form’ “.

Otro código que me gustaría resaltar es cómo trabaja Rails con las variables de instancia que hemos hablado antes en la operación “index” del controlador. Si por ejemplo nos vamos al fichero views/students/show.html.erb vemos lo siguiente:

Lo primero vemos un “notice”, que lo veremos más adelante, pero que sirve para sacar textos informativos al usuario. Después ya se ve como se accede a la variable de instancia para recoger los valores, ya que desde la vista la tenemos accesible sin problemas. Otra vez, ¿qué sencillo verdad?
A muchos no les resultará desconocido, pero para los que sí, la diferencia entre código Ruby metido entre <%= %> y <% %> es que cuando está el igual significa que el resultado de la operación se añadirá al código html y sin el igual es para realizar operaciones sin resultado visible (por ejemplo, sentencias IFs, o realizar una operación que usaremos más adelante o cosas así)

Con esto ya tenemos para jugar un poco. Para próximos post dejo los layout (templates de la aplicación), cómo hacer que se relacionen alumnos y asignaturas, y cosas así que nos harán la aplicación un poco más bonita y útil.

Si lo quieres subir a Heroku para que tus amigos estén más orgullosos de ti aún, ya sabes como se hace!

Curso de Ruby on Rails – Parte 1

Jan 15

jjballanoFormación, Ruby 4 Comments

Desde el lunes hasta ayer he estado dando un curso de 2 horas diarias en Madrid On Rails impartido por Raimond García de Ruby on Rails (aka RoR). El curso ha sido muy introductorio, dándo lo básico tanto de Ruby como de Rails, con la idea de que luego cada uno vaya profundizando. He de decir que pensaba que iba a ser algo más avanzado el curso, no tan tan introductorio, pero creo que al final me ha venido mejor que sea así. Además me ha gustado como Raimond ha llevado el curso, centrándose en que codificáramos que es como realmente se aprende y resolviendo las dudas que pudiéramos tener.

Mi idea en estos post es ir poniendo lo que hemos ido viendo para guardarme un backup ya que mi memoria es limitada y si le sirve a alguien más pues perfecto! Lo iré haciendo por capítulos para que no quede muy largo y los que me salgan, 2, 3 o 15 (espero que no, que aburrimiento!).

Lo primero ha sido la instalación del entorno. Voy a poner sólo el de Mac, que es el que he utilizado. Tengo más información sobre instalaciones en otros sistemas operativos, con lo que si alguien la quiere, que la pida en los comentarios. Toda esta información está sacada del correo que nos envió Raimond a todos los participantes, así que el mérito a él :) 

Librerias basicas
    Apple Xcode Developer Tools (versión 3.2 o superior)
Ruby
    sudo port install ruby
Gems
    sudo gem update --system
    sudo gem uninstall rubygems-update
Sqlite3
    sudo port upgrade sqlite3
    sudo gem install sqlite3-ruby
Rails
    sudo gem install rails
Rspec
    sudo gem install rspec
    sudo gem install diff-lcs
Git
    sudo port install git-core
    Crear una cuenta en github.com
Comprobar
    rails -v	(deberia ser Rails 3.0.3 a día de hoy)

Una vez que tenemos ya instalado lo que necesitamos, vamos a hacer algo en unos minutos con lo que ya podremos empezar a jugar. Por ejemplo voy a hacer una aplicación para una academia donde tendremos por un lado alumnos, asignaturas, y matrículas de los alumnos en las asignaturas. Muy sencillo, sin lógica practicamente ninguna, un CRUD de toda la vida.

Para ello, en un terminal, nos ponemos en el directorio que queramos tener nuestra aplicación, y ejecutamos lo siguiente:

rails new MiAcademia

donde MiAcademia es el nombre que queremos darle a la aplicación. Al ejecutar esto nos creará una carpeta llamada igual que la aplicación y dentro de esta tendremos un esqueleto de nuestra aplicación con un montón de ficheros y carpetas.

Para que no se nos olvide, lo primero que vamos a hacer es levantar el servidor para ver que todo está correcto. Para ello, desde el terminal, entramos en el directorio MiAcademia que hemos creado y desde ahí ejecutamos:

rails server

Para ver si todo está bien, entramos en un navegador, vamos a http://localhost:3000 y veremos una pantalla donde Rails nos da la bienvenida y una guía mínima de cuales pueden ser los siguientes pasos. Esa página que vemos es public/index.html. Como no la queremos para nada, la borramos, y ahora vamos a crear nuestra página de bienvenida.

rails generate controller welcome index

¿Qué significa esto? Estamos creando un controlador llamado “welcome” y una operación llamada “index”. Si vamos a nuestro directorio del proyecto, veremos que se nos han creado varios archivos: app/controllers/welcome_controller.rb, app/helpers/welcome_helper.rb y app/views/welcome/index.html.erb. Es decir, se nos ha creado nuestro controlador de bienvenida, un helper (ya veremos para que sirve), y nuestra vista. Es decir, que si en el navegador ponemos http://localhost:3000/welcome/index deberíamos poder ver nuestra página index. Vamos a modificarla para que aparezca otra cosa distinta a la página que se crea por defecto. Podemos poner algo como lo siguiente:

<h1>Bienvenido a nuestra academia</h1>
<p>Pronto tendremos más información</p>

Nada original, pero de momento no tenemos mucha más información que poner.

Pero queda un poco feo tener que poner esa URL tan larga, ¿verdad? Vamos a tratar de acortarla. Para ello editamos el fichero config/routes.rb. Ahí vemos que hay una línea que pone “get ‘welcome/index’”. Quitamos esa línea y la cambiamos por la referencia a nuestra página de bienvenida, poniendo lo siguiente: root :to

root :to => "welcome#index"

Y si ahora ponemos en el navegador http://localhost:3000 nada más, debería de salirnos nuestra página de bienvenida (si hemos borrado la que está en public/index.html como hemos dicho antes).

Pero ahora nos gustaría que nuestros amigos pudieran ver nuestro pedazo de trabajo, no? Pues vamos a hacerlo en Heroku (donde previamente tendremos que habernos creado una cuenta accediendo a la página) que es un servicio muy cómodo y gratuito (si usamos lo básico) con la ayuda de Git, que ya tenemos instalado. Para empezar a trabajar con Heroku, lo primero instalarnos la gema:

sudo gem install heroku

Y ya podemos ponernos a guardarlo en el repositorio de git y a publicarlo en heroku. Estando en el directorio principal del proyecto, ponemos lo siguiente en el terminal:

git init
git add .
git commit -m "Mi primera aplicacion con rails"
heroku create MiAcademia-[MI_NOMBRE_DE_USUARIO]
git push heroku master
heroku rake db:migrate

¿Qué significa todo esto? Primero inicializamos el repositorio, después añadimos todos los ficheros del directorio actual, para a continuación hacer el commit en nuestro repositorio local con un comentario. Una vez hecho esto, creamos en heroku nuestra aplicación (cambiar [MI_NOMBRE_DE_USUARIO por lo que sea, de cara a no entrar en conflictos), hacemos el push (igual que el commit, pero hacia el repositorio "en la nube") donde le indicamos que queremos meterlo en la rama "master" y por último le decimos que nos exporte la base de datos que tenemos también a heroku.

Una vez hecho esto, y si no tenemos ningún problema, deberíamos poder ir a http://miacademia-[MI_NOMBRE_DE_USUARIO].heroku.com y ver la aplicación. Ahora ya podemos enviársela a nuestros amigos para que vean lo que hacemos en 10 min :)

Creo que esto ya ha quedado demasiado largo. Las cosas más complejas para el siguiente post que escribiré a lo largo del día de hoy o quizás mañana.

Curso TDD

Nov 17

jjballanoFormación, Saraos 5 Comments

Ayer terminó el curso de 2 días al que asistí sobre TDD y que impartió el gran Enrique Comba.

El curso comenzó con diferentes ejercicios para ver qué pensábamos que era TDD, conocer a gente del curso a la que no habíamos visto nunca y tratar de centrar un poco lo que se daría en el curso y ver sobre que de todo nos interesaba que se profundizase. Si no recuerdo mal (que seguro que sí), el “temario” del curso era el siguiente:

  • TDD
  • Refactorización
  • BDD
  • Mocks & Stubs
  • Diseño Simple
  • SOLID

De estos 6 temas teníamos que votar 3.

El curso al final se ha centrado en un problema muy simple, pero que nos ha costado a todos horrores hacerlo porque estábamos preocupados de cada uno de los detalles de la implementación. El problema era sobre un cajero autómatico, es decir, meto tarjeta, pongo pin, pido dinero y si tengo suficiente en mi cuenta me lo da. Sencillo pero donde hemos estado trabajando más de un día. No importa, el aprendizaje ha sido mucho.

No hemos aprendido (que sí practicado) a hacer test unitarios, de integración ni nada así, tampoco era el objetivo y creo que por eso puede haber gente a la que le haya decepcionado el curso (sobretodo a la gente que no conocía a Enrique de antes). Nos hemos centrado en el buen diseño, en el buen nombre de las cosas, en poner cada cosa en su sitio, etc.

Yo siempre digo que mi modo de programar es el de la consultora, y es algo que llevo intentando cambiar de un año para acá. Con “modo consultora” me refiero a programar deprisa, sin preocuparme del código que hago siempre que parezca funcionar y sacar cuantas más funcionalidades posibles en el menor tiempo, ya nos preocuparemos de los bugs por lo que les vamos a cobrar otro tanto… Error de los gordos! Y una estafa como decía Xavi Gost en el Agile Open Spain.

Ahora toca practicarlo en casa, hasta que salga sólo, sin necesidad de pensarlo. En el trabajo no aplicaré TDD sobre software que vaya a llegar al cliente mientras no domine la técnica en condiciones. No tengo que hacer pagar a ningún cliente por mi aprendizaje.