Un artesano siempre novato

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:

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.

Y fin del DevOpenMadrid

Jan 09

jjballanoSaraos 7 Comments

Ayer hicimos el DevOpenMadrid y la verdad es que estoy bastante satisfecho con el resultado final y viendo los Tweets que va escribiendo la gente parece que en general el sabor de boca con el que ha salido todo el mundo es bueno.

El viernes había tenido el 15en5 (del que quizás hablé en posteriores entradas, pero @jmbeas me presiona con su F5 para que escriba esta), y varias personas me dijeron cosas como “mañana es tu gran día” o “nervioso?”, pero siempre les decía lo mismo, si tampoco hace falta nada para organizarlo y una vez que hay gente que está apuntada, el éxito es seguro. Y así fue, la auto-organización es algo que funciona cuando la gente va con gusto y muchas ganas a un sitio. La única organización por mi parte fue buscar un local, abrir la posibilidad de comprar los tickets y comprar unas bebidas. Todo lo demás fue organizado por todos en el momento.

La primera muestra de que no hace falta organizar nada para un Open fue el tablón. Yo contaba con liarnos y tardar como una hora y no se si llegó a la media al final, todo rapidísimo. En mitad del día se decidió mover un par de sesiones y todo perfecto, nadie se quejó, al contrario, todo el mundo contento y a pensar en cual sería la siguiente a la que iría. Y estoy seguro que si una vez ya empezado hubiesen salido charlas nuevas, se hubiesen incorporado sin problemas. También me gustó del tablón que se organizaron algunas “en el pasillo”. No hace falta ni salas para hablar de algo, sino que si nos interesa a 4, pues nos juntamos en el pasillo y lo hablamos.

Se decidió hacer 5 sesiones por sala, más las 3 que salieron en el pasillo si no recuerdo mal, total 13 sesiones para unos 45 que éramos. Teníamos más tiempo para hacer más, pero con eso nos valió, que también agota mucho ir a muchas sesiones y si lo hablamos todo ahora, ¿de qué hablaremos en el siguiente? Si alguien tiene fotos del tablón y me las puede enviar, actualizaría el post con una

Las sesiones a las que yo fui fueron las siguientes, aunque igual no en ese orden:

• Modelo anémico (por @kinisoftware y @jacegu): Un tema muy de moda ultimamente y que me interesa. Personalmente no le veo tanta importancia como se le da a estos malos modelos, quizás por el tipo de aplicaciones que he hecho ultimamente que son muy basados en los datos, pero sí que es algo que trato de ir mejorando. Me gusta más lo que proponen en el lugar de estos modelos, por lo que trato de adaptarlos a mis prácticas diarias.
• Mockeas? (por Emma – @hell03610): Se empezó hablando de mocks y la mayoría entendíamos que se hablaba de dobles en general, pero resulta que realmente lo que buscaba Emma era hablar del matiz que hay entre Mocks, Stubs y Spies. Al final se terminó hablando de testing en general. Buena charla con gente que sabe bastante de estos temas. Tengo mucho que mejorar en el tema test y este tipo de sesiones me vienen muy bien.
• Buenas prácticas (por @kinisoftware y @jacegu): No recuerdo el nombre exacto de la charla, pero iba sobre ir viendo los diferentes capítulos del Clean Code (libro imprescindible para los que desarrollamos) e ir hablando sobre lo que pensamos/hacemos de cada uno. Muy interesante esta charla que se hizo en el pasillo.
• AOP. Con esta sesión propuesta por mi, buscaba quitarme los miedos que tengo a veces de usar AOP, ya fuera porque viera que lo que suelo hacer está bien o porque sea una aberración y deje de usarlo. En general vi que los usos que le daba eran parecidos a los que usaban otros, por lo que me tranquiliza bastante. Eso sí, saqué en claro (más de lo que ya lo tenía), que hay que tener mucho cuidado con AOP o puedes liar unas muy gordas.
• Tecnologías Web (por @borillo): En esta se hablaba sobre todo lo relacionado con tecnologías web aunque creo que se centró la conversación mucho en Rest. Otra charla de pasillo donde aprender bastante.

Hubo una retrospectiva donde vi que es imposible que llueva a gusto de todos, ya que había puntos (el tema Wifi y el horario) que estuvieron tanto en lo positivo como en lo negativo, así que para la próxima (sea quien sea quien lo organice), que haga lo que le de la gana También se habló como positivo que vino gente nueva que los más habituales a este tipo de saraos no conocíamos, ya que es muy importante no caer en la “endogamia” como dijo Xavi Gost y no vernos siempre los mismos. Es importante el aire fresco que venga de fuera para mostrarnos que más hay y que se hace fuera de nuestro círculo de gente.

Y mi retrospectiva personal. Es muy fácil organizar algo así. Si no te metes en acreditaciones, caterings, etc es simplemente buscar un local (que podríamos hacer/continuar alguna wiki pública para ir poniendo los que conocemos), publicitarlo y decidir como gestionarás el que la gente se apunte. Idealmente no debería hacer ni falta tener que apuntarse y que fuera todo el que quisiera, pero por problemas de espacio era imposible y había que limitarlo a unos 50 y fuimos unos 45. La organización de esto no me ha llevado más que unas pocas horas, por lo que no hay excusa para no organizar más y por todo el territorio español. Quizás habrá algunos que reunan a 10 personas y otros a 100, da igual, el objetivo es el mismo, ir a aprender del resto de la gente y enseñar lo que uno buenamente pueda.

Por otro lado el tema StageHQ para los tickets lo gestioné mal y se habló en la retrospectiva. Punto a mejorar para la próxima.

Otro tema a tener en cuenta es que por las tardes el nivel de las sesiones baja. No por la sesión en sí, sino que ya estamos todos más cansados y las discusiones a veces creo que se hacen un poco más pesadas.

En resumen, creo que se han cumplido todos los objetivos que me marqué haciendo esto: Aprendí un montón, y demostré que cualquier persona puede organizar un evento sin necesidad de patrocinador, ni asociación ni nada detrás, ya que sin nada el precio por persona es tan bajo que cualquiera puede pagarlo (incluso si alguien no puede, seguro que el resto no tendría problema en que esa persona no pagara).

¿Quién se anima a organizar el siguiente? Tengo muchas partes de España por conocer y otras donde no me importaría volver. Podríamos organizar el DevOpenTour2011. Ahí lo dejo…

Retrospectiva y objetivos 2011

Jan 01

jjballanoOtros 2 Comments

Como desde ayer no he parado de leer retrospectivas del 2010 y los objetivos para este año recién empezado, no he podido hacer otra cosa que también escribir lo mío… Empecé a escribir el post hace 4 o 5 días pero al final lo borré, pero bueno a reescribirlo toca!

En lo profesional, el año 2010 ha sido un año agridulce. El “agri” me lo da el trabajo. He cambiado este año 2 veces de empresa, en las 2 tomé la decisión de irme antes de encontrar otra cosa, me daba igual, quería conseguir algo que me llenara y esos no lo hacían. En ambos cambios no tomé la mejor decisión a la hora de elegir sitio, cosa a mejorar. El dulce es por la cantidad de gente impresionante que ha pasado en este tiempo por delante de mis narices y de la que he aprendido un montón. Algunos ya los conocía del año pasado (algunos virtualmente nada más) aunque realmente ha sido este año cuando les he conocido de verdad, coincidiendo con ellos en un montón de saraos. Gente (me dejaré a alguno SEGURO, lo siento…)  como Jorge (Semurat), Amalia, Raquel, Kini, Javi, Alejandro, Germán, Alfredo, Laura, Xavi Gost, Leo, Alberto, etc etc etc etc ha hecho que este año haya sido muy importante en mi aprendizaje y en mi forma de ver esta profesión.

En el listado anterior faltan un par de personas que quizás sean los principales culpables de este cambio de mentalidad que he tenido durante el 2010. Quería destacarlos y explicar algo sobre ellos (podría hacerlo de los demás, pero el post tendría que hacerlo por capítulos):

• José Manuel Beas, el liante I de España. Este pedazo de profesional y de persona ha levantado un sector que estaba moribundo gracias a sus ganas y coraje. Yo que me dejo liar facilmente le he seguido en muchas de sus “locuras” de las cuales he aprendido mucho más que en cientos de cursos. Me ha hecho aprender que ser un profesional no es conocer el último framework de moda, sino preocuparme por mi trabajo y tratar de hacerlo cada día un poco mejor.
• Enrique Comba, EL oficial (prefiere oficial a maestro, respetémosle). Un tío que ha entrado en mi forma de ver las cosas en los últimos 3 meses como un elefante en una cacharrería, pisoteando toda la chatarra que tenía en la cabeza y haciendo que me dirija en el buen camino. Me ha enseñado el movimiento de la artesanía del software, de la que había oído hablar pero que no acababa de entender. Me ha mostrado otra forma de hacer las cosas, incluso me ha hecho plantearme el cómo vivir mi vida.

El 2010 ha sido el año de los saraos. He asistido a varios, entre ellos el Code Retreat de Madrid y San Sebastian (en este sólo como mirón, ya que cedí mi plaza) dados por Enrique Comba, el Agile Open Spain de Barcelona, el DevFest de Google, diferentes coding dojos, el curso de TDD también de Enrique, la Software Craftsmanship de UK… y lo más importante, las cañas de después de la mayoría de estos eventos donde he aprendido lo mismo o más que en los propios eventos.

En lo personal, año para hacer una retrospectiva más profunda y personal. Año de mucho cambio, bueno y malo.

Para el 2011, los objetivos son, sin ningún orden de importancia:

• Seguir mejorando como profesional. Para ello seguir yendo a cualquier sarao que pueda. Incluso montarlos, como el próximo DevOpenMadrid. También seguir leyendo libros, blogs, etc. Practicar, practicar y practicar.
• Aprender un nuevo lenguaje. Creo que este lenguaje será Ruby. Algo se después de hacer las rubykoans, pero con aprender me refiero saber hacer una aplicación más o menos decente.
• Hacer una aplicación útil para aportar mi granito de arena a la comunidad. Si ya la hiciera en el lenguaje nuevo del punto anterior sería la leche!
• Darle vida al portal para el que registré el dominio. Tengo varias ideas en la cabeza. Lo que me falta es conocimientos de interfaz de usuario, otro punto a mejorar.
• Uno de los más importantes, estar pronto trabajando en algo que realmente me guste, de esos sitios a los que no cuesta ir a trabajar. Ahora mismo tengo trabajo, si es el actual perfecto, sino será momento de buscar nuevos objetivos.
• Ver como trabajan los demás. Quiero ir a diferentes sitios donde se hagan bien las cosas y pasar algún día con ellos.
• Continuar con la cadena del aprendizaje, es decir, aprender de los buenos y enseñar a los que todavía no tengan demasiados conocimientos. Para lo primero están los puntos anteriores, para lo segundo quiero involucrarme hasta donde me dejen en la enseñanza en la universidad. De momento ya está prevista una charla de la gente de Wiseri en la escuela de informática de la UPM y estoy hablando con un profesor de una asignatura de esa misma universidad para colaborar con él dando un par de charlas. Pero esto no es suficiente, hay que hacer más y a nivel nacional. Cambiando cómo se enseña en la universidad podremos cambiar el sector más rápidamente.
• Mejorar de las rodillas y volver al deporte. Tengo mono de correr y montar en bici. Si me recupero a lo largo de enero me gustaría prepararme para el verano hacer algún tipo de viaje relacionado con la bici (camino de Santiago, hacer algún recorrido durante varios días viendo distintas ciudades/pueblos o algo así).
• Continuar con este blog.
• Llevar un listado de todos los eventos importantes que ocurran durante el año con fecha, lugar y por qué ha sido importante. Idea sacada del post de retrospectiva de Enrique.
• Mejorar mi inglés. Si quiero hacer algo importante con mi vida es necesario que mejore mi dominio de esta lengua.

Dentro de 365 días veremos qué de todo esto he conseguido, qué tengo empezado y qué tengo completamente abandonado.