Hace ya algún tiempo que terminé de leer el libro Apprenticeship Patterns, y uno de los patrones que no he utilizado hasta ahora, entre otros muchos, es el denominado "Brekeable Toys". No se si es técnicamente lo mismo que un Pet Project o no, pero para mi se parecen lo suficiente.

No sabría como definir un Pet Project de forma académica, pero básicamente se trata de un proyecto personal, no comercial, en el que intentamos resolver un problema de un tamaño relativamente grande. Por ejemplo podemos implementar un blog, una wiki o cualquier otra herramienta que nos venga a la cabeza, su función principal es aprender. Al tratarse de un sistema que no están utilizando otras personas, podemos tomárnoslo con calma y cometer tantos errores como queramos, siempre que eso nos enseñe alguna lección. Incluso es aconsejable cometer errores y arriesgarse con el Pet Project, porque posiblemente no tengas dicha oportunidad en tu trabajo diario.


Personalmente veo bastantes ventajas en realizar este tipo de proyecto en nuestro tiempo libre.

• Practicar la base, sin prisas ni presión. Al no tener ningún plazo temporal podemos pasar un mes entero, o dos o los que quieras, leyendo sobre una determinada tecnología o implementando nuestro propio framework para usarlo en el Pet Project. Esto solo es añadir más trabajo al mismo, pero nos dará un conocimiento más profundo de las herramientas que utilizamos día a día en nuestro trabajo.
• Poder elegir la tecnología que desees. Es nuestro tiempo libre y no tenemos que rendir cuentas con nadie, por lo que podemos utilizar las herramientas que más nos gusten, alguna que no conocemos pero nos gustaría conocer mejor, o simplemente mejorar en las que ya conocemos pero tenemos más "oxidadas".
• Tendrás un "portafolio" que enseñar a tus clientes, en tus entrevistas de trabajo, etc. Es común que nos encontremos en casos en los que nuestros contratos nos impiden mostrar nuestro trabajo, ¿qué mejor que un Pet Project , o varios, para que nuestros futuros clientes puedan ver nuestro trabajo?.
• En unos pocos casos, el Pet Project se convierte en un producto "del mundo real" que utilizan otras personas e incluso que se puede monetizar. Pero no tengas esto en mente, son casos muy excepcionales.

Por otro lado hay una "desventaja" bastante evidente a la que recurren muchas personas.

• Has de utilizar tu tiempo libre para poder llevar a cabo dicho proyecto. Sí, así es, el conocimiento, como todas las cosas en la vida, tiene un precio, en este caso no es económico sino temporal. Que lo quieras pagar o no solo depende de tí, pero te aseguro que es posible compaginar tu vida privada con la realización de un Pet Project, siempre y cuando no trabajes más de 8 horas al día en la "oficina", claro.

En mi corta experiencia he recopilado algunos consejos que te pueden resultar de utilidad si quieres realizar un Pet Project.

• No es un proyecto comercial, así que ten calma, no te pongas fechas límite ni plazos. Si a tu novia (o novio) le apetece ir a cenar contigo, tus amigos te llaman para ir a hacer senderismo o simplemente quieres ver una película o leer un libro, ¡hazlo!. Trabaja en el Pet Project cuando realmente te apetezca.
• Escribe sobe tu errores, aciertos, cosas que has aprendido. Al fin y al cabo la razón de hacer un Pet Project es aprender y mejorar, por lo que escribir sobre ello te puede ayudar un poco más. Si además lo haces en un blog y lo compartes, ayudarás a más gente a parte de tí mismo, con lo cual mejorará tu karma :-)
• Elige un proyecto que te guste y pueda ayudarte en tú día a día, pero sin tener miedo de hacer cosas que ya existan. En mi caso personal, trabajar en una herramienta que yo mismo puedo utilizar me ayuda a mantener una mayor motivación. Por ejemplo, ahora mismo yo estoy trabajando en una pizarra de tareas compatible con dispositivos touch, como tablets, y que utiliza Jira como repositorio.
• No temas cometer errores. Investiga, toma decisiones arriesgadas que no tomarías "en la oficina", no vas a hacer daño a nadie y podrás sacar conclusiones muy interesantes.
• No des ningún paso sin entender profundamente lo que estás haciendo. En el día a día la presión es muy alta y tarde o temprano se toman decisiones sin tener todos los datos, ahora no tienes porque hacerlo.

Mucho se ha hablado sobre la reciente oferta de empleo de Atlassian y el proceso de selección que están llevando acabo, pero poco se sabe realmente de este proceso, razón por la que muchas personas están interesadas en conocer detalles. Y de eso mismo va esta entrada, de detalles sobre el Recruitment Roadshow de Atlassian. Eso sí, rociado de algunos pensamientos o reflexiones que me gustaría dejar por escrito para no olvidarlas.

El primer detalle que ya muchos saben es que yo participé en dicho proceso, y a la vista de la forma verbal que he usado, obviamente, no he pasado su code assessment. Las reacciones de la gente han sido muy diversas.

• Unos reaccionan con cara de asombro y pena, como si fuese un tremendo fracaso del que nadie se podría reponer. En serio, no pasa nada, es una oportunidad perdida, pero que me ha enseñado muchas cosas la verdad. Por otro lado, no es una cuestión de vida o muerte. Continúo trabajando para Avantic, en donde he sido muy feliz los últimos 4 años y medio y lo seguiré siendo a buen seguro.
• Otros han reaccionado de forma un poco menos sincera, y diría que ahora piensan que soy peor desarrollador que antes. Sinceramente sigo siendo el mismo ahora que hace 1 mes, no es la primera vez que suspendo un examen o no paso una prueba, ni será la última.
• Y por último los más cercanos a mi piensan - "Atlassian se lo pierde" - gracias chic@s. Sinceramente, no creo, seguro que encuentran a gente muy buena y preparada. Eso sí, sigo seguro de mi mismo y esta entrada en ningún caso intentará justificar el "fracaso", es algo que ha ocurrido y ha ocurrido porque no estaba suficientemente preparado, punto.

Pero bueno, no vamos a estar todo el día con esta sensiblería, vamos al turrón, a lo que la gente quiere saber, ¿cómo es el proceso?.

El comienzo de todo

En febrero de 2012, durante la fiesta de la Spring I/O organizada por Atlassian, anunciaron mediante su embajador en España la intención de contratar a 15 desarrolladores en Europa, y España es uno de los países por los que van a pasar. Si eso no hubiese sido suficiente publicidad, dicho embajador, más conocido por David Bonilla, empapeló la twitter-sfera con su entrada en el blog dando unos cuantos detalles más. Algunos un poco obscenos incluso :-P



Una vez anunciado, cada persona se lo plantea de forma totalmente diferente, pero después de darle muchas vueltas y con el apoyo incondicional de alguna que otra persona en especial (a quien agradezco su ayuda), decido presentarme. Total, como dijo David Bonilla, vivo en Canarias, ¿qué más da irme a Australia? ^_^

El resume y la cover letter

Para inscribirte en la oferta, tienes que tener preparada cierta documentación previa, llámese resume y cover letter. Algo muy similar al curriculum vitae, pero en cierta manera totalmente diferente. No soy un experto en este tipo de cosas, pero me documenté un poco y vi bastantes ejemplos para obtener este resultado. Lo peor de todo para un tornillo como yo, hacerlo en inglés :-S

Enlace a mi resume.

Enlace a mi cover letter.

Como se puede observar es algo un poco más enfocado al puesto exacto al que optas, y por lo que pude intuir, en la cultura anglosajona importa mucho las actividad paralelas que realizas, tu propio esfuerzo por mejorar y aprender, no solo el trabajo diario.

Una vez que tienes estos documentos listos, pues rellenas el formulario que Atlassian tiene preparado a tal efecto y te registras en el proceso. Inmediatamente te llega un mail de confirmación y a la mañana siguiente un mail de una persona de contacto en Atlassian, explicando los pasos que se seguirán y las fecha detalladas que llevará cada parte.

• Primero un code assessment.
• Luego, si pasas el code assessment, o así lo indican, se revisa tu resume, cover letter y otra información que hayas decidido enviar. Por ejemplo, se valorará muy bien que indiques repositorios de código con proyectos en los que hayas trabajado.
• Finalmente, si les interesas, se concertará una cita para una entrevista cara a cara de 2 horas.
• El resto, ya te lo imaginas :-)

Una pregunta que me han hecho recientemente es si los mails son respuestas automatizadas o no, no tengo ni idea, es posible que tengan un proceso automático, pero lo que es cierto es que siempre son enviados desde la cuenta de la persona responsable.

El code assessment

Aquí viene lo bueno, lo que todo el mundo quiere saber realmente. Antes de nada hay que aclarar que al menos hay dos pruebas diferentes, una para las solicitudes a desarrollador Java y otra para los de JavaScript. Tengo la sospecha de que incluso dentro de cada uno, hay más de una prueba, así que la experiencia de cada persona puede ser totalmente diferente a la mia.

Lo que yo esperaba es una prueba de código un poco más completa, un proyecto "real" a desarrollar durante un periodo de tiempo, algo similar a lo que solicita Autentia en sus entrevistas. Pero lo que realmente me encontré es una prueba más similar a un examen de certificación de Java. Aquí se puede debatir largo y tendido sobre si esto es mejor o peor, mi opinión personal es que no es la forma más directa de contratar talento, pero es una forma sencilla de verificar si la persona posee los "skills" que buscas.

En mi caso la primera pregunta era esta.



Puesto que Java utiliza UTF-16 como representación interna, la respuesta sencilla es 16 bit sin signo, pero hay un modificador de la JVM (-XX:+UseCompressedStrings) que permite usar un byte (en los casos posibles cuando se use ASCII puro). Por lo que la respuesta correcta imagino que es la que yo seleccioné, pero podría tener truco si nos ponemos tiskis-miskis :-) Según tengo entendido es raro una representación en memoria sin signo en Java, pero parece que para los char es así.

Tras ir contestando y enviando una a una, mi última pregunta fue esta otra.


No recuerdo que contesté en esta, es un poco comprometida, en principio todos los navegadores (más utilizados) entienden este bloque, pero su utilidad es indicarle al mismo el tipo de documento que viene a continuación. Dado que no pasé la prueba, no me hagáis mucho caso :-P

Vale, ¿y qué había en medio?. Pues tres preguntas de código y 7 más de elegir la respuesta correcta. Obviamente habían preguntas mucho más complejas, incluso relacionadas con el funcionamiento interno de la JVM. Respecto a las de código, dos de ellas eran asequibles, la otra me descolocó un poco. Aquí va.


Sencillo, ¿verdad?. Recorrido primero profundo con recursividad y ya lo tenemos. Aquí os dejo las clases que había que utilizar.

flatten/Couple.java
flatten/Either.java
flatten/FlattenTree.java
flatten/Function.java
flatten/Tree.java

Ahora os haréis una última pregunta. ¿Cuánto tiempo tienes para hacer esto?, pues todo el que tu quieras dentro del plazo indicado que era más de una semana, puedes parar cuando quieras y volver. Ellos estiman que la prueba es para aproximadamente una hora y media. Ahí reside uno de mis fallos, lo intenté hacer seguido y aunque no lo creas siempre es mejor tomar el fresco un rato, FAIL. Mejor hacerlo poco a poco y si tienes que pensar una pregunta más, pues lo haces, es mejor que contestar mal, mi otro fallo (obviamente) :-S A mi personalmente me llevó más de 3 horas en total.

Algunas personas me han preguntado, cuál es la puntuación de cada pregunta o cómo se evalúa, no tengo ni idea. Pasados unos días te mandan un mail indicando el resultado y en mi caso que no deseaban continuar con el proceso. Esa es otra cosa que me ha gusta mucho, sea automática o no, siempre te envían una comunicación, muy educada, informándote del proceso. Algo que nunca me ha gustado cuando he buscado trabajo aquí en España, si no están interesados en tí, ni un correo para decirte que te han descartado, con todo el esfuerzo que has puesto en ello, sobretodo cuando eres novato :-(

Conclusiones

Cada cual puede sacar conclusiones totalmente diferentes, las mias son las siguientes.

• Me guste más o menos el tipo de test, fallé y lo hice yo solito, no hay más donde buscar. Lo mejor, de todos esos errores puedes aprender cosas muy interesantes. Sinceramente, creo que la experiencia me ha hecho mejor desarrollador, aunque no tenga pruebas empíricas de ello.
• En este tipo de empresas es muy importante presentar código hecho por tí, un pet project o colaboración con proyectos de software libre que demuestren tus habilidades. No es nada nuevo y en Atlassian no son unos genios por saber esto, lo son por otras cosas, es algo que ya me dijo Xavi Gost que debo hacer. También lo puedes leer en Apprenticeship Patterns, en fin ya ireis viendo cual es mi próximo PetProject :-) (ya esta en marcha)
• Cuando tengas dudas, pregunta, en Atlassian también se pueden equivocar al desarrollar el test. Pero hazlo durante la prueba, al menos es lo que yo creo, no es ético hacerlo a toro pasado. Si cuando estas haciendo algo notas algo raro, confía en tu instinto ... aunque te recomiendo contrastes un poco tu instinto antes también :-P
• Sí, voy a seguir usando los productos de Atlassian en mi día a día, es una pregunta que ya me han hecho :-) ¿por qué iba a dejar de usarlos?, es una de las razones de que quisiera trabajar allí.
• Por último, no es la única oportunidad de tu vida, ¿realmente quieres trabajar en Atlassian?, están contratando como locos, presentate de nuevo, mejora, aprende y vuelve a intentarlo, no te ponen trabas al respecto ... eso sí me han indicado que el tiempo óptimo para notar una mejoría son 12 meses :-) Por otro lado no es la única empresa del mundo, es buena, pero hay otras igual de buenas.

Material de referencia 

Para aquellas personas que deseen saber como es el proceso de contratación en este tipo de empresas. Si alguien me envía más enlaces los colgaré aquí :-)

Enlace al blog de Jeff Atwood sobre su forma ideal de contratar programadores.

Vaya, he estado ojeando los borradores acumulados en mi cuenta de Blogger y parece que por aquí había una idea que no estaba mal. No se porque razón no completé este artículo y lo publique, pero como nunca es tarde si la dicha es buena, allá vamos.

Hace poco (bueno, ahora ya hace más de año y medio :-) leí un artículo de Krzysztof Adamczyk sobre la potencia de hacer uso de objetos valor en nuestro código, y he pensado que podría ser interesante que presente mi propia opinión al respecto de este tema. Para ello tomaré prestadas las ideas del propio Krzysztof Adamczyk y las expuestas por Dan Berg Johnsson en su presentación en la QCon London 2009.

*Nota al lector*

El siguiente código no es de producción, tan solo es a modo de ejemplo. Está realizado en Scala, pero cualquier persona con conocimientos de Java lo puede entender de forma sencilla.

¿Qué es un objeto valor?

Lo mejor será empezar por el principio. Para todos aquellos que no sepan lo que es un objeto valor, Eric Evans define en su libro un objeto valor de la siguiente manera.

"An object that represents a descriptive aspect of the domain with no conceptual identity is called a Value Object."

He preferido dejarlo en el idioma original porque es posible que yo metiese la pata al hacer la traducción, por lo que con esta definición y lo que cada uno entienda de ella, empezaré con el contenido de esta entrada.

Los detalles del dominio se hacen explícitos

Una de las ventajas de hacer uso de los objetos valor, es que en el código desaparecen los tipos como String o int por tipos como PhoneNumber o Email. Aquí muchos pensaréis que esto no es ninguna ventaja sino que añade complejidad, puede ser pero dejadme unos párrafos de ventaja por favor.

Imaginad que estamos trabajando en un nuevo y avanzadísimo sistema de gestión ... como por ejemplo, una simple una agenda. Como en cualquier agenda, tendremos un objeto de modelo que define el contacto y generalmente nos encontraríamos con algo similar al siguiente código.

class Contact(val firstName: String, val lastName: String,
 val phoneNumber: String) {
 
 override def toString(): String = {
  firstName + " " + lastName + " : " + phoneNumber
 }
}

object Agenda {
 
 def main(args: Array[String]) = {
  val contact = new Contact("Pepe", "García", "922222222")
  println(contact)
 }
 
}

Genial, muy sencillo, pero ahora imaginemos  que nuestro cliente quiere que su agenda indique de forma automática con un icono (que nosotros representaremos en el ejemplo con texto) cuando se trata de un teléfono fijo y cuando de un móvil, por poner un ejemplo. Muchas veces la opción más utilizada es la siguiente.

class Contact(val firstName: String, val lastName: String,
 val phoneNumber: String) {
 
 def phoneNumberType(): String = {
  if (phoneNumber.startsWith("6"))
   "móvil"
  else
   "fijo"
 }
 
 override def toString(): String = {
  firstName + " " + lastName + " : " + phoneNumber + 
   " (" + phoneNumberType + ")"
 }
}

object Agenda {
 
 def main(args: Array[String]) = {
  val pepe = new Contact("Pepe", "García", "922222222")
  println(pepe)
  val juan = new Contact("Juan", "Juanez", "633445566")
  println(juan)

 }
 
}

Pero ¿qué ocurriría si hiciésemos esto otro?.

class PhoneNumber(val phoneNumber: String) {

 def withType(): String = {
  phoneNumber + " (" + phoneType + ")"
 }
 
 private def phoneType(): String = {
  if (phoneNumber.startsWith("6"))
   "móvil"
  else
   "fijo"
 }
 
}

class Contact(val firstName: String, val lastName: String,
 val phoneNumber: PhoneNumber) {
 
 override def toString(): String = {
  firstName + " " + lastName + " : " + phoneNumber.withType
 }
 
}

object Agenda {
 
 def main(args: Array[String]) = {
  val pepePhone = new PhoneNumber("922222222")
  val pepe = new Contact("Pepe", "García", pepePhone)
  println(pepe)
  val juanPhone = new PhoneNumber("633445566")
  val juan = new Contact("Juan", "Juanez", juanPhone)
  println(juan)

 }
 
}

Ciertamente son bastantes más líneas de código, pero ¿qué hay de la limpieza? y aún más importante, de esta manera se cumple la regla que dice que cada elemento debe tener una única responsabilidad. Ahora la clase Contact no tiene lógica sobre la forma en la que se muestra el número de teléfono.

Al tratarse de un ejemplo hemos metido lógica de la vista en el modelo, pero en un caso real lo que haríamos es tener un método en PhoneNumber que nos indique de que tipo de dispositivo se trata, y ya se encargará la capa de la vista de representarlo.

El código se extiende más fácilmente

Sigue sin parecerte nada especial y la legibilidad del código no te importa mucho, aunque debería. Pues otra ventaja es que el código se extiende más fácilmente y de manera comprensible. Imagina que ahora queremos saber qué números de teléfono tienen errores, pues basta con que añadamos dicha funcionalidad en el propio objeto PhoneNumber, sin seguir complicando otras clases ni desperdigar la lógica por el resto de la aplicación.

Para acabar me gustaría señalar como de esta manera hemos evitado tener un modelo anémico. Es muy usual que se creen modelos como si fueran simples CRUD y luego se reparta cierta lógica en validadores y helpers, ¿no es más lógico que sea el propio objeto el que tenga la lógica que le afecta únicamente a él?