viernes, 3 de agosto de 2012

Integrando LinkedIn en Android

En el post de hoy vamos a ver como podemos integrar de manera sencilla la red social de trabajo LinkedIn en nuestras aplicaciones Android. Para ello vamos a utilizar la librería linkedin-j, que encapsula las llamadas a la API Rest de LinkedIn y que además incorpora soporte para OAuth, el sistema de autenticación utilizado por la red social.

viernes, 20 de julio de 2012

Errores comunes de los Daily Meetings

La reunión diaria de Scrum, más conocida cómo Daily Meeting (o Stand Up Meeting), es la reunión que permite al equipo mantenerse sincronizado, comunicarse y estar al tanto del avance en los objetivos del Sprint, y aunque es una de las prácticas más utilizadas (ha sido adoptada por muchas otras metodologías) y de las que más documentación existen, todavía se siguen cometiendo muchos errores a la hora de realizarla.

image from http://kept.co.za


A continuación he recopilado una pequeña lista con algunos de los errores con los que más veces me he ido encontrando a lo largo de los últimos años:

Reportar al Scrum Master (o a otro cargo)
El Daily Meeting es una reunión del equipo. El objetivo es mejorar la comunicación y la transparencia entre los miembros del equipo no pasar un report a ningún cargo superior (ni tampoco al Scrum Master). Los miembros del equipo deben mirar a sus compañeros cuando contesten a las 3 preguntas del Daily.

Reuniones muy largas
En muchas ocasiones, sobretodo cuando participan jefes o cargos superiores,  las reuniones se alargan mucho más allá de los 15-20 minutos que marca la metodología haciendo que baje la productividad de la reunión.
Evitar preguntas que entran mucho en detalle y limitarse a una breve sincronización es la mejor manera de mantener una reunión diaria saludable y productiva.

Discusiones sobre diseño
La reunión diaria se acaba convirtiendo en el lugar donde se tienen las discusiones sobre diseño o arquitectura. Este problema hace que, ademas de alargar las reuniones (punto anterior), las personas que no estén involucradas pierdan el foco de la reunión y pasen a "perder el tiempo". Cuando aparezcan este tipo de discusiones, lo mejor es apuntarlas y que las personas involucradas se reúnan posteriormente para seguir tratando el tema.

Reporte de bugs
Los equipos de soporte o test aprovechan la reunión del daily meeting para hacer llegar los bugs o incidencias detectadas, o para preguntar por aquellas incidencias que no les han sido resueltas (el "¿que hay de lo mío?"), haciendo de nuevo que la reunión se alargue y se pierda el foco. El reporte de incidencias del estado de las mismas debería ser una reunión diferente en el caso de que fuera necesaria.

¿Qué otros tipos de problemas os habéis encontrado al realizar la reunión diaria? ¿Y cómo los habéis solucionado?

sábado, 5 de mayo de 2012

¿Eres un programador profesional?



Leyendo hace unos días el libro “97 Things Every Programmer Should Know”, una recopilación de 97 artículos escritos expresamente para el libro por expertos en desarrollo de software de los últimos años, me llamó bastante la atención uno de los artículos llamado “The Professional Programmer”, en el cual Robert C.Martin (más conocido como Uncle Bob) explica una serie de ideas sobre lo que el entiende por ser un Programador Profesional.

El artículo no sorprenderá demasiado a los que hayan leído algún libro u otras referencias del autor, ya que siempre ha dejado bastante clara su postura respecto al tema, pero me pareció que podía ser interesante como tema de discusión.

Las ideas que expone  Uncle Bob en el artículo son las siguientes (la traducción es  bastante libre):


  • Un programador profesional es aquel  que se responsabiliza de su propia carrera profesional: Estudiando, leyendo libros, formándose, estando al día en las últimas tecnologías  y metodologías y no esperar que sea nuestro jefe el que nos pague la formación.  
  •  Un programador profesional es responsable del código que escribe: No sube código a producción que no ha sido probado o del cual no se está seguro que vaya a funcionar.
  • Un programador profesional trabaja en equipo: Se responsabiliza de “todo” lo que tiene que entregar su equipo, y no únicamente de su trabajo. Ayuda a sus compañeros cuando estos tienen problemas y les enseña y aprende de ellos lo máximo posible.
  • Un programador profesional “no soporta” grandes listas de bugs: es una  señal de que se está siendo poco cuidadoso con el sistema.
  • Un programador profesional no hace “ñapas”:  Acaba el trabajo de forma correcta y sin prisas, manteniendo su código limpio , bien estructurado y lo más legible posible, siguiente estándares y buenas prácticas de desarrollo.

Para enfatizar los puntos anteriores Uncle Bob da diversos ejemplos, como los de los abogados o médicos que utilizan parte de su tiempo libre para estar el día en los diferentes aspectos y avances de su profesión, u otro ejemplo con un médico al explicar lo de las “ñapas” utilizando una hipotética situación en la que un médico está operando a corazón abierto y hace un apaño para ir tirando porque tiene que irse a casa.

La visión que expone Uncle Bob de lo que es ser un profesional de nuestro campo se acerca bastante a la idea que yo tengo de la misma. Hay alguna idea un poco cogida con pinzas (la lista de Bugs) pero en general creo que es una visión muy buena. Lamentablemente, por lo que llevo visto en mi (aún corta) carrera profesional, parece que lo que la mayoría de desarrolladores entienden por ser profesional  poco tiene que ver con esto, acercándose más a la idea de pasar 8 horas intentando hacer de manera más o menos “bien” las tareas que se les asigna y poner la mano a final de mes (en un país donde ser funcionario es el gran sueño para una gran parte de la población, esto es algo que no debería sorprender).

A pesar de ello, sigo pensando que es importantísimo el cuidar de nuestra carrera profesional, que se supone que es lo que nos va a dar de comer a nosotros y a nuestra familia, y más ahora en este tiempo un tanto “oscuro” que nos está tocando pasar, donde la actitud respecto a nuestra profesión va a ser un factor diferencial clave, y para ello, las propuestas e ideas de Uncle Bob pueden ser una gran ayuda.

¿Qué opináis vosotros? ¿Se acerca vuestra visión de lo que es un programador profesional a lo que nos cuenta Uncle Bob? 

jueves, 23 de junio de 2011

Mi AOS2011

Me encantan los Open Spaces. Mi primera experiéncia fue en Buenos Aires en marzo de 2009, y supuso una revolución para mi en la forma de encarar la organización de eventos. El segundo fue el del año pasado en Barcelona, en el que, a parte, participé en la organización. Y este fin de semana se realizó el Agile Open Spain 2011 en Pamplona, al que no podia faltar. Como siempre me encontré allí a un montón de amigos, aunque la novedad de este año fue poder ir acompañado de casi la totalidad de la gente de la oficina de Plain Concepts en Bilbao.

Una de las razones por las que me encantan los Open Spaces es porque creo que ejemplifican a la perfección el espiritu del agilismo. Es un evento hecho por la comunidad para la comunidad. Por supuesto que necesita un comité organizador ( y que lo hicieron a la perfección ) para todo el tema logístico, pero la "chicha" del evento, las 36 charlas que hubo, fueron un trabajo de los miembros de la comunidad para los miembros de la comunidad. Se formaron 36 equipos enfocados en dar el máximo valor posible a las charlas.



Yo propuse una charla sobre calidad del código que fue bien recibida y que creo que estubo bastante bien, aunque no se tocaron todos los temas que me hubieran gustado. La discusión se centró sobretodo en la cobertura de tests y en los comentarios en el código. También se habló de los equipos de QA.

Por otra parte asistí a charlas tan variopintas como Stubs, Mocks y Spies, taller práctico de histórias de usuario, talento, estimaciones, deduda técnica y romper la rutina.

Por encima de las charlas en sí ( que podéis ver en detalle en los diferentes resúmenes hechos por los participantes ) yo me quedo con las personas que asistieron al evento. Se reunieron 150 personas preocupadas por su profesión, con ganas de mejorar su entorno, con ganas de hacer cosas para ellos y para los demás y comprometidos con la excelencia.

Espero ya con ganas el Agile Open Spain del año que viene, en el que espero veros a muchos de vosotros.

Un saludo!

Instalar una plantilla metodológica en castellano en un TFS2010 en inglés

Puede darse el caso que tengamos un TFS 2010 instalado en inglés pero nos interese cargar una plantilla metodológica en castellano. Nuestro primer impulso será cargar la plantilla metodológica sin hacer ningún cambio en nuestro servidor y crear un proyecto con ella. A veces es bueno seguir los impulsos, así que vamos a ello.

En nuestro querido Visual Studio 2010 vamos al menú Team y abrimos el Process Template Manager:







Y seleccionamos nuestra plantilla para cargar. Se carga la plantilla correctamente y se nos añade a la lista de plantillas disponibles.



Una vez cargada la plantilla ya podemos crear un nuevo Team Project con ella, así que creamos un Team Project con el Team Explorer y como plantilla metodológica escogemos la plantilla recién subida. Todo parece ir bien hasta que...



Le hechamos una ojeada al log y vemos que el error está en la creación del portal de Sharepoint ya que no encuentra un template del site para el idioma español (3082):



Para solucionar esto nos vamos a la web de Microsoft a descargarnos el Language Pack para nuestra versión de Sharepoint, en nuestro caso la 3.0. Y la instalamos, claro. Al finalizar la instalación nos pedirá si queremos ejecutar el asistente para configuración de Productos y Tecnologías de SharePoint.



Le decimos que si y nos ejecutará el asistente, que prácticamente no requiere de nuestra intervención.



Y si todo ha ido bien:



Si nos vamos a la carpeta C:\Program Files\Common Files\microsoft shared\Web Server Extensions\12\TEMPLATE\1033\XML (inglés) veremos que tiene un fichero ( WEBTEMP.Microsoft.TeamFoundation.SharePoint.Dashboards) que en la carpeta C:\Program Files\Common Files\microsoft shared\Web Server Extensions\12\TEMPLATE\3082\XML (español) no está.

Tenemos que conseguir este archivo de alguna instalación del TFS en español y copiarlo aquí y volvemos a pasar el asistente para configuración de Productos y Tecnologías de SharePoint dejando las opciones marcadas por defecto. Una vez hecho esto ya podemos crear el nuevo proyecto con la plantilla metodológica en castellano.

Ahora solo nos faltará editar el portal de proyecto de SharePoint para que muestre los elementos en castellano en lugar de en inglés.

Espero que haya servido de ayuda.

Un saludo!

miércoles, 15 de junio de 2011

Codificación manual y enlace a datos de tests funcionales con CodedUI

En el anterior artículo, veíamos como hacer un test funcional con CodedUI grabando nosotros los pasos del test. En el artículo de hoy veremos como codificar a mano estos pasos, ya que llega a ser más rápido y más flexible hacerlo así.

Empezaremos de la misma manera, creando un proyecto de test, añadiéndole un archivo de test con CodedUI y generando una nueva grabación. La diferencia es que ahora, en lugar de hacer clic sobre el botón de grabar y empezar a realizar los pasos, arrancaremos la aplicación y arrastraremos el botón con la cruceta de la barra del test builder sobre un control de la aplicación, en nuestro caso el textbox correspondiente a la operación.



Al hacer esto se nos abrirá la misma pantalla que se nos abrió al hacer la aserción en el anterior tutorial. Esta vez, haremox clic sobre las dos flechas hacia la izquierda que hay arriba a la izquierda y se nos abrirá un panel que contiene un árbol donde se muestran los diferentes controles que vamos seleccionando.



Seleccionaremos el control que acabamos de añadir y haremos clic sobre el botón de añadir el control al UI map. Haremos lo mismo con todos los controles, incluída la cruz de cerrar la aplicación, hasta que nos quede algo parecido a esto:



Ahora ya podemos hacer clic sobre el botón de generar el código de la grabación. El Visual Studio detectará que no hemos hecho ninguna grabación y nos preguntará si queremos que añada los controles seleccionados al UI map del test. Le diremos que si.



Si nos fiajmos en el test de donde hemos partido, veremos que no ha cambiado nada, ya que no se ha realizado ninguna grabación. Vamos ahora a hacer por código lo mismo que hacia Visual Studio automáticamente por nosotros antes. Para ello, no vamos a editar el archivo UIMap.Designer.cs, ya que este archivo es autogenerado y podriamos perder los cambios realizados allí. Para permitirnos añadir nosotros nuestros tests, Visual Studio nos proporciona una clase parcial vacia situada en el archivo UIMap.cs. Es aquí donde podemos hacer un método nuevo con las acciones que queremos que se realicen.

Empezaremos incluyendo la libreria de testing para los controles Wpf:



Lanzamos la aplicación a testear:







Definimos las variables para manejar los textbox de la calculadora, que en CodedUI son WpfEdit:



Ahora definimos las variables para manejar los botones:



Inicializamos los textboxes con los valores que queremos testear:



Y simulamos un clic sobre los botones del igual y de cerrar la aplicación:



Ahora simplemente tenemos que llamar a esta función desde nuestra clase de test, y veremos que si ejecutamos el test este hace todo lo que le hemos dicho y pasa correctamente.



Por ahora solo hemos comprobado que la aplicación no le pase nada raro, pero no hemos comprobado que el resultado sea el correcto. Para ello tenemos que simular nosotros lo que, cuando grababamos los tests, eran las aserciones.

Para ello vamos ha hacer algo parecido a lo que hace automáticamente Visual Studio. Nos vamos a crear una clase que contenga todos los parámetros que necesitamos ( los dos operandos, la operación y el resultado de la operación) y vamos a crearnos una instancia pública de la misma en la clase UIMap.cs:



Modificaremos la función que acabamos de realizar en el UIMap.cs para que utilice los valores de las propiedades de esta clase y para que, después de clicar sobre el botón de igual, recupere el valor que hay en el textbox del resultado:



Ahora sólo nos queda rellenar los valores de los operandos y la operación desde nuestro test, y hacer un assert del valor esperado con el valor del parametro Resultado:



Y ahora sólo nos queda alimentar este tests con datos provenientes de un XML. Primero de todo nos creamos el XML, que tendrá una aspecto como este:



Ahora le decimos al test que sus datos se alimentaran de este XML. Para hacerlo, seguiremos los mismos pasos que si quisieramos hacer lo mismo en un test unitario. Nos vamos a la ventana de test view, seleccionamos el test y en la ventana de propiedades, clicamos sobre el botón situado en el campo Data Connection String. Se nos abrirá una pantalla como esta:



Seleccionamos XML file y clicamos en siguiente.



Clicamos sobre siguiente:



Seleccionamos la tabla adecuada en el XML ( en nuestro caso sólo tenemos una ) y verificamos que los campos sean correctos. Clicamos en finalizar. Nos pedirá de copiar el archivo en el proyecto y de añadirlo a la lista de items a desplegar. Le decimos a todo que si.

Ahora ya estamos preparados para utilizar estos datos. Para hacerlo, nos ayudaremos de la propiedad DataRow del objeto testContextInstance, de la siguiente manera:



Y ya tenemos el CodedUI tests alimentado con datos de un XML!

Espero que el tutorial os haya gustado y no os haya aburrido en exceso.

Un saludo!

miércoles, 8 de junio de 2011

Tests funcionales con CodedUI

Como ya muchos sabéis, CodedUI es la tecnología de Microsoft que nos permite realizar tests funcionales sobre nuestra aplicación, sea esta del tipo que sea. En el artículo de hoy veremos como crear un test funcional básico y añadirle una aserción. Empecemos!!

Lo primero es presentaros la aplicación que vamos a testear. Se trata, como no, de una pequeña calculadora realizada en WPF y compuesta de 4 textboxes y un botón. En los tres primeros textboxes introduciremos los operandos y la operación a realizar y, al apretar el botón, se nos mostrará el resultado en el último textbox.



Para realizar los tests vamos a crear un acceso directo a la aplicación en nuestro escritorio y vamos a añadir un nuevo proyecto de test a la solución. A continuación, añadiremos un nuevo item al proyecto de test de tipo CodeUITest. Automáticamente se nos mostrará un cuadro de diálogo que nos da a elegir entre generar un nuevo grabando acciones o utilizar uno existente. Escogeremos la primera opción.



Esto hace que nos aparezca la barra del CodedUI test builder, que es una pequeña barra que nos ayudará en nuestro cometido.



Como podéis ver, la barra sólo tiene cuatro botones;

  • Empezar o pausar la grabación.
  • Ver los pasos que llevamos guardados.
  • Seleccionar un control para hacer una aserción (luego lo vemos).
  • Generar el código de la grabación existente.

Para empezar le daremos al botón de grabar y empezaremos a realizar la prueba que queremos guardar. En este caso, será hacer doble clic en el acceso directo, introducir una operación del tipo 5 + 6, darle al botón y cerrar la aplicación. Esto en nuestra clase de test genera un código tal como este:



Ahora veremos un poco más el código interno, pero por ahora nos vamos a limitar a ejecutar el test. Esto hará magia en nuestro ordenador y se nos abrirá la aplicación, se tecleará lo mismo que hemos tecleado nosotros, se pulsará el botón, se mostrará el resultado y se cerrará la aplicación. Ni Tamariz lo haría mejor!

Si miramos un poco el código interno, veremos que es prácticamente auto-explicativo:



Vemos como abre la aplicación, inserta los textos correspondientes y hace clic en los botones. Destacar sobre todo las tres líneas donde rellenamos los textboxes, porque lo utilizaremos después para alimenar al test de datos.

Ahora vamos a hacer una aserción sobre el textbox del resultado. Lo que queremos es que el test compruebe que la operación es correcta, no sólo que no hay ningún problema para ejecutarlo. Así pues, vamos a hacer un nuevo test como si fuera un test unitario, es decir, haciendo un método público decorado con el atributo [TestMethod]. En el cuerpo del método, hacemos clic con el botón derecho del ratón y seleccionamos la acción "Generato code for CodedUI test -> User CodedUI Test Builder":







Volvemos a estar como antes, con la barra del CodedUI test builder. Realizaremos los mismos pasos pero, antes de cerrar la aplicación haremos clic sobre el botón de pausa y generaremos el códig de los pasos que llevamos hasta ahora. Ahora, haremos clic en el icono de la aserción y lo arrastraremos hasta el textbox del resultado. Esto hará que se nos habra la siguiente ventana:



Hacemos clic con el botón derecho en el campo text y seleccionamos la opción "Add asertion". Esto nos abre la siguiente pantalla, donde introducimos el valor que queremos asegurar que se muestre.



Generamos el código para la aserción, empezamos otra grabación para grabar el cierre de la aplicación y generamos el código para esta última acción. El código resultante tendria que ser algo parecido a esto:



Pasamos el test y vemos que se pone en verde. Si vamos a nuestra clase calculadora y cambiamos el comportamiento de la suma para que no devuelva la suma de los dos operandos, veremos que el test deja de pasar.

Bueno, pues por hoy ya es suficiente. Espero que os haya sido útil el tutorial. En la próxima entrega, veremos como alimentar este test de datos provenientes de un XML.