Resolver problemas interesantes

2011 febrero 10
by rafadc

Estos días estoy leyendo con avidez “Linchpin” de Seth Godin (recomendación de Alberto Peña en su twitter) . Cuando lo termine seguramente escriba algo más pero de momento voy a poner negro sobre blanco una idea que me ha encantado del libro.

Hago una traducción un poco a mi gusto ;) :

Resolver problemas interesantes

“Interesante” es la palabra clave. Responder a preguntas del tipo: “¿Cuando fue la guerra de 1821?” es una habilidad inútil en un mundo en el que Wikipedia siempre está disponible. Es mucho más útil ser capaz de contestar preguntas a las que Google no nos puede ayudar. Preguntas del tipo: “¿Qué es lo que debería hacer a continuación?”

Ayer, mientras volvía a casa en coche escuchaba un programa en el que se debatía sobre si internet nos ha hecho más listos o más tontos. Yo creo que ni lo uno ni lo otro. Ha hecho que nos tengamos que adaptar al nuevo medio. Ahora todos llevamos en nuestro bolsillo una enciclopedia preparada para ser accesible a cada instante así que memorizar ciertos datos resulta completamente inservible. En cambio ahora es más importante que nunca asimilar conceptos y ser creativos. Son dos habilidades que, en mi humilde opinión, creo que son básicas para avanzar cualquier tarea en el mundo que nos movemos.

Cuando adquirimos un nuevo conjunto de habilidades es importante adquirir nuevos conceptos con ella. Creo que es incluso más importante el concepto adquirido que la nueva habilidad en sí. Pongo como ejemplo cuando un programador aprende un nuevo lenguaje de programación. Si somos programadores de Java y aprendemos Scala tendemos a escribir código Scala igual que escribíamos Java solamente que con la nueva sintaxis. Eso, personalmente, creo que es absolutamente inútil. Cuando nos aporta algo es cuando empezamos a aplicar modelos de desarrollo que no eran posible en el lenguaje en el que trabajábamos antes. Cuando aprender ese nuevo lenguaje de programación sirve para ampliar nuestras miras hacia nuevos modelos (p.ej. programación funcional) que eran imposibles de aplicar con la herramienta anterior. Entonces es cuando nos metemos un nuevo concepto en el bolsillo y adquirimos la verdadera ganancia. Cuando salimos del lugar en el que nos movemos habitualmente y nos vamos a una zona inexplorada para nosotros.

La creatividad es después muy importante. Con ella podemos coger los nuevos conceptos abstractos que hemos adquirido y convertirlos en algo real y que resuelva un problema concreto. Nos convertimos cada vez más en gente que resuelve problemas. No estamos para cuando todo funciona sino para cuando algo falla. Además normalmente no hay una sola vía para resolver el problema y tenemos que encontrar la mejor cuando ni siquiera el concepto de mejor está claro. Tenemos un problema si nuestro trabajo lo puede desempeñar una máquina porque, no lo dudes, tarde o temprano lo hará. Es una carrera contra el tiempo entre tú y la tecnología hasta tu jubilación (si es que la llegas a tener en algún momento).

Si juntamos ambas cosas creo que tenemos una persona resolutiva y es la habilidad que tenemos que alcanzar de verdad. Me parece muy revelador un concepto que trata el libro y es que todo esto no son cualidades innatas sino habilidades que adquirimos. Si somos conscientes todos podemos ser un poco más resolutivos.

Propósitos de año nuevo

2010 diciembre 31
by rafadc

Estos días David Bonilla ha lanzado un guante a la comunidad de desarrolladores pidiendo unos propósitos de año nuevo así que yo también me voy a plantear unos objetivos…

  • Bajo ningún concepto no más código sin tests. Lo siento pero no. Me dan igual las prisas o lo que sea. Si voy a arreglar algo en el Brownfield se empieza escribiendo test y luego se va cambiando.
  • Mantener una aplicación web activa y abierta al público. Aunque sea un miserable redireccionador. La cosa es obligarme a ir manteniéndola con mimo y respetando los principios. Además es un banco de pruebas público con lo que me obligaré a cuidarme más de hacer tonterías. Si ya pudiese lanzar otra idea que tengo en mente sería maravilloso.
  • Ruby, ruby y más ruby… teniendo en cuenta que Ruby no es sólo rails. Empiezo a cogerle el gusanillo, especialmente a Sinatra. Me parece que es un banco de pruebas estupendo donde se van viendo un montón de tendencias encuanto a programación se refiere. Una vez que te has metido un poco en este mundo ves las enormes limitaciones de los frameworks a los que estás acostumbrado.
  • Android. Terminar el año con al menos una aplicación más en el market.
  • Escribir más en el blog que lo tengo bastante abandonado.
  • Todo esto dedicando más tiempo a mi santa esposa que bastante me aguanta ya.

No voy a decir que en lo técnico haya sido un mal año porque mirando la vista atrás si que veo que he aprendido bastantes cosas con respecto al año pasado teniendo en cuenta que ha sido un año en el que el trabajo me ha tenido bastante amargado viajando por el mundo y derrochando mi ya de por si limitado tiempo.

Feliz navidad

2010 diciembre 25
by rafadc

¡MiCubiculo.com os desea una Feliz navidad a todos y un próspero año nuevo!

Dojo en Autentia con Carlos Ble

2010 diciembre 17
by rafadc

El día 16 de Diciembre participé en un pequeño dojo con Carlos Blé en el que nos explicaba un poco lo que eran las APis fluidas. Como siempre la mejor manera de explicarlo es con ejemplos así que para explicar lo que es un API fluida nos fijaremos en Mockito ;) Para los que no lo sepais mockito es una librería para definir test doubles en la que especificamos el comportamiento de los mismos mediante un API fluida. Por ejemplo tenemos la siguiente linea de código:


LinkedList mockedLisk = mock(LinkedList.class);
when(mockedList.get(0)).thenReturn("first");

Si nos fijamos en la segunda línea vemos que definimos nuestro código de una manera que intentamos asemejarnos lo más posible al lenguaje natural. Podemos decir que las APIs fluidas son una forma de DSL. El caso es que Carlos planteó diversos ejercicios que fuimos resolviendo haciendo pair programming en pomodoros de media hora. En concreto en mi grupo nos toco implementar un APi que pueda haceer algo parecido a lo siguiente:

.

when_successful ( obj.m() ).then_call ( obj.x() ).as_a_chain()
when_successful ( obj.m() ).then_call ( obj.x(), as_a_chain() )
when_successful ( obj.m() ).then_call ( obj.x() ).with_args(args)
.
Obviamente usar TDD no es opcional así que nos lanzamos al turrón. Últimamente me va mucho la marcha así que decidí utilizar Ruby para resolver la kata. Si no empiezo a utilizarlo de una forma regular no voy a aprender jamás así que tuve un montón de problemas con la sintaxis y probablemente habrá maneras mejores de hacer ciertas cosas.
.
He subido el código a github así que si quieres ver mi torpe resolución puedes descargarlo de allí así que tan solo tienes que clonar el repositorio con el comando
git clone git://github.com/rafadc/kata-as_a_chain.git
.
Y a continución paso a comentar un poco mi experiencia:
.
El primer test es bastante sencillo. Como parece que lo de encadenar parámetros va a ser un poco lío[1] mejor hacemos un primer caso lo más sencillo que podamos sin parámetros ni nada a ver qué pasa.
.
.
Como when es palabra reservada vamos a saltárnoslo con una función estática (primera cosa que no me convence 100% pero una función sencillamente me convence menos y hay que seguir el enunciado ;) ) y crearemos nuestra clase llamada When. De todos modos vamos viendo un poco el concepto del API fluida que estamos creando.
.
Las dificultades para mi comenzaron cuando pretendí encadenar el parámetro y es que me quede con el siguiente código que no me gusta nada:
.
.
Particularmente mi problema es con el “then_call{|x| myObject.method_to_be_called(x)}” y es que me gustaría que hubiese una manera de especificarle el método sin decirle el número de parámetros en el propio bloque. Pensé en usar un símbolo y reflexión imitando un poco a mocha pero creo que es demasiado complicado y nos cierra posibilidades a futuro de definir alguna cosa interesante. Los bloques parecen una solución natural para esta API. ¿A alguien se le ocurren alternativas?
.
Otra pieza que tampoco me convenció 100% fue la sobrecarga de that. En ruby no existe la sobrecarga de métodos así que tuve que ingeniármelas para pasar un símbolo y un bloque. El caso es que no tengo más remedio que psarlo en el orden inverso al que proponía el enunciado por sintaxis. Otro punto a favor de la reflexión en lugar de los bloques. No me parece definitivo pero ahí esta ;)
.
;
.
Sorprendentemente una vez llegado a este punto la implementación de los últimos casos con el with_args era absolutamente trivial. Mirando un poco hacia atrás a lo mejor hubiese sido una buena idea empezar por aquí y no hacer el primer truco de la función sin retornar parámetro. Supongo que sería el primer refactor que afrontaría si tuviese que continuar.
.
El resultado final me parece relativamente corto y, si no he entendido mal algo (que probablemente lo haya hecho) es bastante conciso. Me parece asombroso que con una explicación de unos minutos nos hayan presentado un concepto tan interesante. De todos modos tienen razón los que critican el abuso de este tipo de APIs porque es verdad que viendo el código solamente es exageradamente complicado entender que diablos hace. Para eso mejor nos vamos a los test y ahí ya queda bastante claro.
.
Es un lujo participar en un evento de este tipo con un tipo que sabe tanto como es Carlos y que explica conceptos tan complejos como estos de una manera tan clara.
.
[1] : En honor a la verdad no nos enteramos muy bien del enunciado del ejercicio y no nos dimos cuenta que había que encadenar los parámetros pero ¿a que la excusa es buena?

Citas 015

2010 noviembre 27
by rafadc

Siempre quise que mi ordenador fuera igual de fácil de usar que mi teléfono. Mi sueño se ha hecho realidad: ya no soy capaz de usar mi teléfono.

- Bjarne Stroustrup

Rails para zombies

2010 noviembre 19
tags: ,
by rafadc

No suelo poner enlaces en el blog pero creo que cuando se hacen las cosas bien, se hacen de manera original y además divertida debemos de publicitarla lo más posible. Ese el el caso de Rails for Zombies, una web dedicada a enseñarnos a utilizar ruby on rails de la más amena de las maneras: con zombies.

El buen humor y el buen hacer pueden ir de la mano ;)

Desinstalar un plugin en Eclipse

2010 octubre 26
tags: ,
by rafadc

Vamos a ver…. Llevo programando desde que tengo uso de razón…. 5 años como profesional utilizando Eclipse. No me puedo creer que aún hoy he descubierto como se desinstala un plugin. Increible.

Vais a About->Installation Details->Installed Software y ahí os sale una lista de los plugins.

También he de reconocer que no me gusta usar muchos plugins, solo o necesario y no suelo instalar ninguno (y menos desinstalar) pero he estado jugueteando con el plugin de Scala que aún está muy verde y causaba algún NullPointerException a los refactor incluso en Java.

Me hace gracia porque últimamente me estoy preocupando más de lo habitual por aprenderme los shortcuts de teclado de Eclipse para llevar la contraria a la moda de volver a usar vi y eMacs que estoy viendo por internet ;) y resulta que nunca había hecho algo tan básico. Eso si, el que decidió poner la opción ahí se merece guillotina.

Citas 014

2010 octubre 24
by rafadc

“No es necesario hacer que cada módulo sea perfecto antes de subirlo al repositorio de código. Simplemente basta con hacer que sea un poquito mejor que cuando lo bajamos”.

Robert C. Martin (Uncle Bob)

Switch to our mobile site