Documento Nod Up

5/28/2018 Documento Nod Up

1/380

historias de developers

Un libro para developers y sus jefes

Publicado por Lulu.com

ISBN: 978-1-4466-2883-6


2/380


3/380

licencia

Usted es libre de:

copiar, distribuir y comunicar pblicamente la obra

Bajo las condiciones siguientes:

Reconocimiento: Debe reconocer los crditos de la obra de la maneraespecificada por el autor o el licenciador (pero no de una manera quesugiera que tiene su apoyo o apoyan el uso que hace de su obra).

No comercial:No puede utilizar esta obra para fines comerciales.

Sin obras derivadas: No se puede alterar, transformar o generar una obraderivada a partir de esta obra.

Entendiendo que

Renuncia:Cualquiera de las condiciones anteriores puede ser eliminada si seobtiene permiso del autor que ostenta los derechos.

Para ms informacin:

http://creativecommons.org/licenses/by-nc-nd/3.0/es/legalcode.es
http://www.google.es/url?sa=i&rct=j&q=&esrc=s&frm=1&source=images&cd=&cad=rja&docid=3tNBUBbp_PZ0nM&tbnid=lYh4gheYHYXmFM:&ved=0CAUQjRw&url=http://www.lib.umich.edu/copyright/using-cc-licensed-material&ei=F0kTUeWaEqeq0AXixIDwDQ&bvm=bv.42080656,d.d2k&psig=AFQjCNHNxdzvokVzOaC4fZvcaKi6ku8SBw&ust=1360304763084713


4/380


5/380

crditos

Coordinacin:

Alberto de Vega Luna y Rafael de las Heras del Dedo

Autores:

Carlos Domingo Soriano Josep Lluis Jimnez Castelltort Juan Lambea RuedaDiego Gonzlez MartnezRafael Pelln Gomez-Calcerrada

Jess Gumiel Ramrez Alberto de Vega Luna Jess Manuel Gonzlez EspinillaStefano Marinelli Daniel Micol Ponce Sebastin Ortega Torres

Miguel ngel Santiago Cabello Juan de Bravo DezJonatan Tierno AlviteEduardo Alonso Garca Ral Cumplido Domnguez Marina Serrano Montes

Rafael de las Heras del Dedo Toni Cebrin Chuli Fernando Navarro GilFrancisco Jess Gmez Rodrguez Joaqun Guanter Gonzlbez

Roberto Prez CuberoJuan Roldn Parra Germn Toro del ValleFernando Rodrguez SelaGuillermo Lpez Leal

Rubn Gonzlez BlancoSalvador de la Puente Gonzlez Cristina Santa Cecilia

Portada, comics y diseo grfico:

Cristina Santa Cecilia

Maquetacin:

Alberto de Vega Luna

Tag Clouds generadas con Tagul.com


6/380


7/380

aviso

Todos los que aqu escribimos somos empleados de Telefnica I+D. Losartculos que puedes encontrar en este libro no deben tenerse en cuentacomo la voz oficial de Telefnica. No obstante, el lector debe conocernuestra vinculacin laboral con Telefnica a la hora de juzgar la

imparcialidad de nuestros contenidos.


8/380


9/380

ndice

prlogo............................................................................................................................ 13

por Carlos Domingo

sobreingeniera, el enemigo en casa............................................................. 19

por Josep Lluis Jimnez Castelltort

la creatividad en el diseo y desarrollo de software..................... 27

por Juan Lambea Rueda

mejores prcticas en APIs en REST: uso pragmtico......................... 35

por Diego Gonzlez Martnez

map reduce: el camino hacia bigdata........................................................... 45

por Rafael Pelln Gomez-Calcerrada

de apple pie a jelly bean: la dulce historia de Android..................... 59

por Jess Gumiel Ramrez

la comunicacin, ese gran desconocido...................................................... 71

por Alberto de Vega Luna

cmo la programacin genrica puede ayudar a reducir el

volumen de cdigo.................................................................................................... 81

por Jess Manuel Gonzlez Espinilla


10/380

10

desarrollo personal................................................................................................ 93

por Stefano Marinelli

procesos para escribir cdigo mantenible y estable....................... 103

por Daniel Micol Ponce

la programacin funcional te hace ms fuerte...................................... 111

por Sebastin Ortega Torres

relaciones de cdigo con un desarrollador en un entorno de

innovacin................................................................................................................... 123

por Miguel ngel Santiago Cabello

crear un sitio web o un blog con contenido esttico

es posible..................................................................................................................... 131

por Juan de Bravo Dez

apologa del reboot frente al refactor..................................................... 145

por Jonatan Tierno Alvite

importancia del unit testing en el cdigo................................................ 159

por Eduardo Alonso Garca

debugging & profiling: garanta del funcionamiento de un

programa..................................................................................................................... 169

por Ral Cumplido Domnguez y Marina Serrano Montes


11/380

11

1, 2, 3, estima!...................................................................................................... 183

por Rafael de las Heras del Dedo

programacin usando actores........................................................................ 197

por Toni Cebrin Chuli

qu podemos aprender de las industrias del cine

y del videojuego....................................................................................................... 207

por Fernando Navarro Gil

hackers, ellos tambin son developers..................................................... 217

por Francisco Jess Gmez Rodrguez

utiliza tu lenguaje.................................................................................................... 231

por Joaqun Guanter Gonzlbez

alternativas al desarrollo mvil................................................................... 243

por Roberto Prez Cubero

anlisis de seguridad en el cdigo............................................................... 265por Juan Roldn Parra

la motivacin del desarrollador.................................................................... 277

por Germn Toro del Valle

servidor de notificaciones push de open web device..................... 291

por Fernando Rodrguez Sela y Guillermo Lpez Leal


12/380

12

entendiendo y gestionando el desarrollo de software................... 309

por Rubn Gonzlez Blanco

christmas tree........................................................................................................ 327

recopilado por Salvador de la Puente Gonzlez

bola extra: 5 claves para comprender a un diseador................ 369

por Cristina Santa Cecilia


13/380

prlogo

por Carlos Domingo


14/380


15/380

En estos momentos en el mundo estamos ante una transformacintecnolgica que solo tiene antecedentes en la revolucin industrial delsiglo XIX. En los ltimos diez aos hemos visto cmo finalmente

Internet y, ms recientemente, los telfonos inteligentes hanrevolucionado todos los aspectos de nuestras vidas y de nuestra forma detrabajar, desde cmo hacemos una reserva de hotel o de un vuelo a cmopedimos un taxi desde un smartphoneviendo en tiempo real en un mapadnde est y cundo va a llegar a donde estamos. Productos que hastaahora no han cambiado de forma sustancial en los ltimos aos como losmapas, los libros, los monederos, los coches o las gafas, estn siendoreinventados y transformados en esta nueva era digital. Y debajo de toda

esta revolucin est el software. Y las empresas que sobrevivan y sereinventen para triunfar en este mundo digital al que nos estamosdirigiendo sern las empresas que entiendan y dominen el software. Comodecan recientemente en un artculo en Forbes, hoy en da todo el mundoes una compaa de software y eso fue algo que entendimos en sumomento y que nos pusimos a ejecutar para completar esatransformacin.

Cuando llegu al centro de Barcelona de Telefonica I+D en 2006recin contratado, haba un trmino comnmente usado en la compaaque yo desconoca y que me cost un poco entender. Era el llamado"apalancamiento". Ese trmino se refera a cuntos desarrolladores desoftware tenas subcontratados por cada empleado propio de la compaa.Como los subcontratados eran "ms baratos", pues las propias finanzas dela empresa te forzaban a tener cierto nivel de apalancamiento en tu

presupuesto anual para poder llevar a cabo los proyectos sin salirte delmismo. Y esos niveles de apalancamiento eran del orden de 1 a 6, es decir,haba 6 desarrolladores subcontratados por cada empleado propio. Enresumen: el desarrollo de software no se vea como una actividad corey sesubcontrataba de forma masiva, intentando adems hacerlo lo ms baratoposible. Para colmo, el laboratorio de Barcelona de Telefnica I+D parael cual yo haba sido contratado como director estaba siendo usado comopiloto para certificacin de CMMI21. Y, finalmente, en Telefnica I+D no

exista una carrera profesional tcnica (en contra de lo que el nombre de laempresa pudiera indicar) y solo una de gestin, con lo que los mejores

1http://es.wikipedia.org/wiki/Capability_Maturity_Model_Integration
http://es.wikipedia.org/wiki/Capability_Maturity_Model_Integrationhttp://es.wikipedia.org/wiki/Capability_Maturity_Model_Integration


16/380

16

perfiles tcnicos y de desarrollo acababan pasndose a tareas de gestinpara poder promocionar y progresar profesionalmente en la empresa.

El trabajo para el que haba sido contratado consista, en trminosgenerales, en crear servicios innovadores ms all de la conectividad, confoco en servicios de Internet y multimedia, algo que empez con elgermen del centro de Barcelona de Telefonica I+D. En aquella pocahaba unas 40 personas dedicadas a estos temas y durante los aos hemosido haciendo crecer esta actividad hasta dar lugar a la unidad de desarrollode producto e innovacin de Telefonica Digital de hoy en da dondetenemos ms de 1.000 profesionales en 5 centros en Espaa as como

centros en Israel, Reino Unido, Brasil y California. Como os podisimaginar, innovar en ese tipo de servicios (fundamentalmente serviciosbasados en software) sin tener tus propios desarrolladores y conmetodologas waterfall como CMMI2 iba a ser algo muy complicado asque lo prioritario era cambiar la forma de trabajar, la metodologa, losperfiles, crear una nueva carrera profesional para ellos, etc.

As que mi equipo y yo nos pusimos manos a la obra con esta tarea.

Durante estos aos, hemos ido contratando ms desarrolladores desoftware y formando a los que ya tenamos, cambiando la metodologapara abandonar el CMMI2 y pasarnos a metodologas giles (Scrum enconcreto) as como reforzar las otras disciplinas complementarias eigualmente necesarias para llevar a cabo el desarrollo de software conxito como el grupo de experiencia de usuario, el departamento de QA,etc. Por otro lado, en 2007 Telefonica I+D cre una carrera tcnica para

dar oportunidades de promocin profesional y reconocimiento a losperfiles tcnicos y de desarrollo que no queran convertirse en gestores.

Y as es cmo nos convertimos en una empresa de software deverdad. El resto es historia y desde entonces la transformacin de lacompaa ha sido increble y este libro es un testimonio de esatransformacin. En l, podis leer las historias de los developers de

Telefonica I+D donde a da de hoy podemos decir que la cultura del

desarrollo de software ya forma parte de la cultura central de la compaa.Es un libro para developers escrito por developers donde se tratan todotipo de temas, desde algunos ms tcnicos como el uso de APIs en RESTa otros ms culturales como el evitar la sobreingeniera o mejorar la


17/380

17

comunicacin, pasando por temas de rabiosa actualidad empresarial comola historia de Android, las nuevas tecnologas de bases de datos norelacionales o el trabajo que estamos desarrollando conjuntamente con

Mozilla sobre Firefox OS.

Espero que lo disfrutis tanto como lo he hecho yo.

Carlos Domingo (Barcelona, 1971) es director dedesarrollo de productos e Innovacin, as como

miembro del consejo de Telefnica Digital ypresidente y consejero delegado de TelefnicaInvestigacin y Desarrollo. Es adems miembro de losconsejos de administracin de Jajah, Tuenti y TokBox.Doctorado en Ingeniera Informtica por la UPC, yMster en Ingeniera Informtica por el TokyoInstitute of Technology, ha cursado tambin estudiosde postgrado en direccin de empresas en la Stanford

Graduate School of Business.Durante el poco tiempo libre del que dispone, es unmentor de startups y ngel inversor en ms de 10startups de tecnologa.


18/380


19/380

sobreingeniera, el enemigo en casa

por Josep Lluis Jimnez Castelltort


20/380

20


21/380

21

La sobreingeniera y sus consecuencias

La sobreingeniera es la consecuencia de desarrollar intentando dar

solucin a funcionalidades futuras. Pasa en las mejores familias. A quinno le ha ocurrido esto alguna vez? A m personalmente, unas cuantas.

La experiencia nos dice que los requisitos de un proyecto suelencambiar y esa es una realidad que hemos de asumir desde el inicio deldesarrollo. Los cambios realizados durante la fase de desarrollo implicanmodificar, adaptar o incluso desechar partes del cdigo implementado.Por lo tanto, desarrollar teniendo en cuenta tanto el espacio contexto

concretocomo el tiempopensar demasiado en el futuro- no parece unabuena idea.

Imaginemos que estamos desarrollando un componente propiopara nuestra aplicacin, una librera open source o un plugin para nuestroframework favorito. En estos casos, solemos implementar funcionalidadextra porque creemos que nos ser til ms adelante. Todo un clsico enel mundo software.

El resultado final es la acumulacin de fragmentos de cdigo quenunca van a ser usados. Estamos engordando el nmero de lneas ydificultando la legibilidad. Esto es nefasto a nivel individual y mucho msa nivel de equipo.

Recapitulando, estas son las consecuencias de aplicarsobreingeniera en nuestro diseo software:

1. Mayor coste de tiempo (en su implementacin) y en consecuencia,de presupuesto

2. Aumento de la complejidad del cdigo hacindolo menos legible ymenos mantenible

3. Peor rendimiento de la aplicacin (dependiendo de la complejidadaadida)

4. Aumento del riesgo a tener nuevos bugs ya que hay funcionalidadque nunca se prueba

Suena bastante mal, verdad? Cmo podemos protegernos de loscambios sin caer en las garras de la sobreingeniera?


22/380

22

Alternativas para protegernos de los cambios

En esta seccin vamos a ver una serie de principios y buenas

prcticas que nos ayudarn a desarrollar un cdigo ms a prueba decambios.

Empecemos viendo un par de tcnicas para mejorar nuestracomunicacin e interaccin con el personal (cliente) que se encarga dedefinir los requisitos.

El mtodo MoSCoW (Must, Should, Could, Wont)

Se aplica antes de iniciar la fase de desarrollo y sirve para priorizarlos requisitos de las entregas en 4 niveles:

1. Mnimos para considerar la entrega completada (Must)2. Importantes pero negociables (Should)3. Deseables pero no prioritarios (Could)4. Descartados para esta entrega (Wont)

Con este mtodo se fija el alcance del producto a priori y as seevitan malentendidos en el momento de la entrega. Adems, elcumplimiento de los tres primeros puntos nos puede servir paracuantificar el xito del entregable.

La filosofa RERO (Release Early, Release Often)

Esta filosofa apuesta por una poltica de despliegues muy

frecuentes para poder recibirfeedbackdel usuario o cliente lo antes posible.Esta forma de trabajar suele utilizarse en entornos cerrados donde

el acceso est restringido a los desarrolladores, el equipo de pruebas yalgunos usuarios finales, pero algunas veces, sobretodo en startups,tambin se usa en entornos de produccin.

La finalidad de esta metodologa es no desviarnos de lo que elcliente realmente quiere. Al tener un entorno siempre actualizado con losltimos cambios, ste tiene la oportunidad de supervisar los avances ydetectar cualquier desviacin en la entrega.


23/380

23

La experiencia nos demuestra que seguir estas tcnicas se acabatraduciendo en una clara mejora en la relacin desarrollo - producto queacaba resultando beneficiosa para ambas partes.

Una vez cubiertos los requisitos, veamos cmo mejorar nuestrashabilidades de programacin a travs de tres de los principios mspopulares del mundo del desarrollo:

DRY Dont Repeat Yourself: No repitas cdigo, abstrelo yresalo.

KISS Keep It Simple, Stupid!: Mantn tu cdigo simple y evitacomplejidad innecesaria.

YAGNI YouAint Gonna Need It: No aadas ninguna funcionalidadque no vayas a usar.

Pueden sonar triviales pero aplicarlos en el da a da no es tan

sencillo como parece. Las fechas de entrega juegan en nuestra contra y suaplicacin suele posponerse a la fase de refactor, una de las ms importantesdel ciclo de desarrollo.

Veamos una serie de consejos prcticos para cumplir estosprincipios en la siguiente tabla.

DRY Usa patrones de diseo software, en especial los estructurales

como por ejemplo el adaptador (Adapter), el objetocompuesto (Composite) o el envoltorio (Decorator).

KISS Evita el spaghetti code2 dividiendo las funciones enormes ensubfunciones y minimiza las dependencias siempre quepuedas.

YAGNI Escribe las pruebas primero (Test First Development) y desarrollael cdigo despus. Esta prctica se conoce como Test-DrivenDevelopment(TDD)3.

2Cdigo spaghetti:http://es.wikipedia.org/wiki/C%C3%B3digo_spaghetti3http://es.wikipedia.org/wiki/Desarrollo_guiado_por_pruebas
http://es.wikipedia.org/wiki/C%C3%B3digo_spaghettihttp://es.wikipedia.org/wiki/Desarrollo_guiado_por_pruebashttp://es.wikipedia.org/wiki/Desarrollo_guiado_por_pruebashttp://es.wikipedia.org/wiki/C%C3%B3digo_spaghetti


24/380

24

Para terminar, no podemos olvidarnos del anti-patrn RSW

(Reinventing the square wheel).Este se cumple cuando desarrollamos una funcionalidad que ya nos

proporciona una solucin existente (reinventar la rueda) y obtenemos unresultado peor (rueda cuadrada).

Tal y como hemos visto en el principio DRY, es muy importanteno repetir nuestro cdigo, y como acabamos de ver, es igual de

importante no repetir el de los dems. Reutilizar cdigo de fuentes fiablessuele ahorrarnos mucho tiempo y un buen nmero de bugs.

En definitiva, reinventemos la rueda cuando las solucionesexistentes no satisfagan nuestras necesidades o cuando queramos aprenderms sobre ruedas.

Conclusiones

El propsito de este artculo es analizar la sobreingeniera, uno delos problemas que surgen durante la fase de desarrollo de cualquierproyecto software, y buscar alternativas para evitarla o minimizar almximo su impacto.

Para entender mejor la sobreingeniera hemos visto lasconsecuencias de aplicarla y se han expuesto varias propuestas paraevitarla en dos mbitos distintos: comunicacin y programacin.

Existen ms propuestas al respecto e incluso algunas quecontradicen a las expuestas. No hay que olvidar que el desarrollo softwareno es una ciencia exacta y como sucede en otros sectores, como laeconoma o la medicina, no todos los expertos se ponen de acuerdo encul es la mejor forma de afrontar los problemas ms comunes.


25/380

25

Pepe (Barcelona, 1984) es desarrollador en TelefnicaI+D. En su corta vida profesional ha programado,diseado, maquetado, flirteado con arquitecturas varias

e incluso ha intentado emprender montandoBuscopista, una startup relacionada con el mundo deldeporte. Entusiasta del cdigo abierto y del trabajocooperativo, colabora en proyectos sin nimo de lucroen su tiempo libre.


26/380


27/380

la creatividad en el diseo

y desarrollo de softwarepor Juan Lambea Rueda


28/380

28


29/380

29

Qu es la creatividad?

La creatividad segn la Real Academia Espaola de la lengua4, es la

facultad de crear o capacidad de creacin. As que como esto no nos dicemucho, veamos qu significa el verbo crear (proviene del latn crere)segn la misma fuente:

1. Producir algo de la nada2. Establecer, fundar, introducir por vez primera algo; hacerlo nacer o

darle vida, en sentido figurado. Crear una industria, un gneroliterario, un sistema filosfico, un orden poltico, necesidades,derechos, abusos.

Esta definicin ya s que nos ofrece un detalle aplicable 100% anuestra profesin de desarrollo de software. Cualquier ingeniera otorga alestudiante unos mnimos conocimientos y capacidades para resolverproblemas, adems de ofrecer las herramientas bsicas para que se ejecutela implementacin de un proceso creativo. Porque el desarrollo desoftware es algo muy creativo y debemos convencernos de ello.

Realmente esto enlaza directamente con lo que llamamosinnovacin y aqu est una de las claves de la creatividad. Puede habermuchas ideas, productos, servicios, programas o aplicaciones nuevas peropocas de ellas pueden ser innovadores. Por otro lado, a veces pasa locontrario y es que realmente la innovacin no se encuentra en la creacinen s, sino en la ejecucin, implementacin y desarrollo de algo yaconocido o implementado por otro. En este ltimo caso se puede ofrecer

un valor aadido difcil de superar en el mercado aplicando la excelenciaen la implementacin en algn aspecto realmente diferencial. Un ejemplode sobra conocido son los productos de Apple, ensalzados por unos ycriticados por otros: en muchos casos la creatividad e innovacin queaportan es bsicamente, la excelente implementacin de un valor aadidoque es clave: la experiencia de usuario.

4http://www.rae.es/
http://www.rae.es/http://www.rae.es/


30/380

30

El proceso creativo de un producto

Hoy en da se producen muchsimos avances a diario y se innova

constantemente. Parece que es muy difcil encontrar una idea para unproducto que realmente sea innovador, pero tampoco hay que encontrarsefrustrado. Muchas veces la innovacin proviene de enlazar creaciones eideas existentes que aportan un valor y aplicacin nuevos al encontrarsejuntas. Hay que resaltar que no estamos hablando de copiar productos oservicios que ya existan en el mercado sino de enlazar conceptos oproductos que, al estar integrados, aportan un novedoso valor aadido.

As pues, no es cuestin de encontrar la idea feliz sino ms bien de

tener un conocimiento previo de otros productos o servicios novedososque existan en el mercado y que juntndolos creen algo nuevo yrevolucionario.

Como vemos, la estrategia a medio o largo plazo consta de untrabajo de fondo de investigacin y conocimiento de los productos quehay en el mercado, aunque obviamente hay chispas de creatividad queacaban en el lanzamiento de productos totalmente disruptivos y

novedosos.

Diseo del software y creatividad

En el diseo de la arquitectura de los sistemas a alto nivel siemprehay que tener en cuenta el estudio previo de soluciones exitosas que sehan aplicado con anterioridad. Es decir, antes de poder innovar y sercreativos en aspectos de diseo tiene que existir un estudio previo de otras

arquitecturas que hayan funcionado no solo sobre el papel (por ejemplo,patrones de diseo). Como se dice mucho en el mundo del desarrollohacer cajas es muy fcil.

Desde mi punto de vista es muy importante que las personasencargadas de realizar los diseos hayan experimentado el esfuerzo deldesarrollo software para tener conciencia de las implicaciones en cambiosde diseo y esa experiencia debe haber sido real, con productos que han

estado en produccin en los que hayan surgido problemas reales,urgencias, cambios de requisitos, etc.


31/380

31

Todos tendemos a olvidar el esfuerzo necesario para realizartrabajos pasados y esta experiencia ayuda a recordar que las elecciones enel diseo pueden tener consecuencias de peso en nuestros productos.

Adems, estas elecciones permiten tomar conciencia de la deuda tcnicaen la que se suele incurrir al disear y no implementar ciertascaractersticas tcnicas necesarias en nuestros productos. Caractersticasque por cuestiones de priorizacin a veces se relegan a un segundo otercer plano y no se implementan. Esto es un riesgo real que aumenta conel tiempo y crecimiento del producto y nueva funcionalidad.

Por otro lado, a nivel de diseo de software, constantemente hay

nuevas tendencias y un error muy comn por querer construir algonovedoso a nivel tcnico es el adoptar para todo las tecnologas que estnen boga en un momento determinado. La creatividad en el diseo desoftware tiene que ir de la mano de los requisitos del producto. Es decir,podemos pensar en un diseo muy creativo y novedoso pero no olvidarciertas restricciones en relacin a la implementacin del producto queinvalidan dicha solucin en un momento dado.

Un ejemplo muy claro es la necesidad de tener en cuenta la variabletiempo. Habitualmente el xito en el lanzamiento de un producto dependeentre otros factores del momento de oportunidad. La ventana deoportunidad en el tiempo es crucial y est marcada por nuestroscompaeros de marketing y negocio, cuyo conocimiento debe estarcompartido con el equipo tcnico para que todos los implicados en laconstruccin del producto tengan conciencia del time to market(el tiempo

que se tarda en llegar al mercado).

Tambin para ser creativo en relacin al diseo creo importante loque comnmente se llama tener la mente abierta. Parece algo obvio, perocon el trabajo diario, tendemos a especializarnos y profundizar entecnologas y en diseos, de forma que retrasamos los cambios sin poderevitarlo.

De alguna forma hay que abstraerse de nuestra experiencia pasada ypensar en cmo podramos resolver esos mismos problemas cambiando elfoco. Esto no quiere decir que siempre sea necesario realizar cambios enel diseo para cosas que funcionan demostradamente. Pero en cualquier


32/380

32

caso ese ejercicio de anlisis cambiando el foco es muy valioso pues puedeaportarnos puntos de vista que anteriormente no habamos tenido encuenta. Como deca Albert Einstein: "Si quieres resultados distintos, no

hagas siempre lo mismo".

Actualmente est en auge en psicologa lo que se conoce comoPNL (programacin neuro-lingstica). Bsicamente permite reeducarciertos comportamientos no muy asertivos para cambiar y obtenermejores resultados a todos los niveles. Relacionado con estos temasrecuerdo hace unos aos el libro Quin se ha llevado mi queso que permiteextraer conclusiones sobre cmo enfrentarnos al cambio constante y lo

que aporta tener esa predisposicin al mismo (ya que la vida es un cambioconstante).

Desarrollo e implementacin de software,

creatividad y realidad

En relacin a la implementacin de software, generalmente aplicalo comentado a nivel de diseo anteriormente. Podemos ser muy creativos

definiendo una arquitectura de clases con un diseo magnifico, que seamuy acadmico, organizado, ordenado e incluso elegante. Pero si al hacerunas pruebas de prestaciones no cumplimos los requisitos del productopor haber demasiadas capas de clases o no estar lo suficientementeoptimizado de cara al rendimiento que debe ofrecer, no nos sirve de nada.O por ejemplo utilizar una base de datos no SQL (que no soporte ACID)para almacenar transacciones econmicas y tener un problema en

produccin y perder el registro de dichas transacciones econmicas porfalta de transaccionalidad, integridad, etc (con el problema que estoimplica). Hay que tener en cuenta el contexto y contorno de cadacomponente a desarrollar dentro del producto y negocio en el que seencuentra as como la naturaleza de los datos que se manejan.

Enlazando estas dos ltimas secciones, diseo e implementacincreativa de software, se puede aplicar el mismo principio o recomendacin

siguiente: Si realmente crees que una tecnologa o implementacinnovedosa puede ser exitosa, antes de ponerte manos a la obra estudia,sopesa ventajas e inconvenientes y reserva un tiempo extra. Ese tiempoextra hay que contemplarlo en muchos aspectos que no suelen ser


33/380

33

despreciables en absoluto: nueva tecnologa en la que no tenemosexperiencia, un posible cambio de paradigma y un tiempo mnimo deadaptacin (desde el ms alto nivel hasta el ms bajo tcnicamente

hablando), as como un tiempo extra final de validacin de tu nuevasolucin e implementacin.

Es decir, antes de llevar a la prctica dicha implementacin hablacon tu equipo y con tus responsables para que se gestione laincertidumbre de tu apuesta. El equipo ha de ser consciente que esnecesario hacer un especial hincapi en el chequeo de la calidad desoftware y de pruebas de prestaciones. Realmente se trata de un ltimo

paso forzoso de validacin de cara a realizar una serie de pruebas quegaranticen el resultado y el xito del componente dentro del producto.

Por ltimo, resaltar que la toma de conciencia creativa en todos losaspectos de un producto, desde su concepcin hasta su implementacintiene mucha importancia. La implementacin a veces despreciada, muchas

veces es ms creativa y constructiva que la propia definicin del producto.Todos sabemos que a veces llegan requisitos indefinidos al equipo de

desarrollo. Por tanto, el desarrollador en este caso, conociendo las tripasdel producto se pone en el rol del creador del producto para concretar eserequisito. Se trata de una mezcla entre dar la mejor solucin tcnicaproporcionando una creatividad extra para contemplar adems de losrequisitos funcionales los requisitos tcnicos. As que es un trabajocomplejo que requiere un esfuerzo intelectual muy importante.

Por este motivo se entiende que los programadores rehyen lasreuniones, evitan las interrupciones y necesitan mucha concentracin parasu trabajo. La prdida de esa concentracin implica perder y olvidar cosasque tienen en la cabeza y que pueden tener impacto en la implementacin.La tendencia actual de trabajar en espacios abiertos para este tipo de tareastan intensas - intelectualmente hablando - desde luego que no son unbeneficio para el desarrollador en este aspecto y es algo que debeconsiderarse con la perspectiva adecuada.


34/380

34

Juan Lambea (Madrid, 1972) es Solution Architect enTelefnica I+D. Inici su profesin realizandoprogramacin en diversos lenguajes as como otras

labores junto al desarrollo de software: definicin dearquitecturas e interfaces, gestin de ofertas, gestin deequipos, consultoras, investigacin tanto en proyectosinternos de Telefnica como en proyectosinternacionales europeos, desde prototipos y pruebasde concepto hasta puesta en produccin y soporte.

Tambin ha participado como coautor en la escritura

de varios captulos del libro Service Level Agreements forCloud Computing(Springer ISBN: 978-1-4614-1613-55).

5http://link.springer.com/book/10.1007/978-1-4614-1614-2/page/1
http://link.springer.com/book/10.1007/978-1-4614-1614-2/page/1http://link.springer.com/book/10.1007/978-1-4614-1614-2/page/1


35/380

mejores prcticas en APIs en REST:

uso pragmticopor Diego Gonzlez Martnez


36/380

36


37/380

37

Conceptos de REST: lo que todos sabemos y alguna

cosa mas

REST (Representational State Transfer6) no es un protocolo, sino unosprincipios de arquitectura, un estilo y unos patrones de diseo para ladescripcin de interfaces web. No hay unas normas completamentecerradas, sino una serie de guas que, si se siguen, permiten obtenerinterfaces o APIs RESTful. O RESTlike, si aplican las guas con algo deimaginacin y flexibilidad cuando REST no encaja como un guante al APIque se necesita implementar.

Los conceptos bsicos de REST son los siguientes:

Lo principal son los recursos. Un recurso es igual a una URI. La URIindica donde est el recurso, por ejemplo un libro en una biblioteca:

http://mibiblioteca.com/biblioapi/v1/libros/libro1234

De forma general, una URI puede identificar a dos tipos de recursos:una coleccin o un recurso individual. Una coleccin es simplementeuna agrupacin de recursos del mismo tipo.

Las colecciones se deben nombrar en plural y con nombradosconcretos. Adems deben usarse nombres, puesto que el verbo lodefine el mtodo HTTP7. Los recursos individuales tienen su propioidentificador, que debe ser nico dentro de la coleccin. As, elidentificador del recurso sirve como indexador en la coleccin.

Como hemos dicho, los mtodos HTTP sirven para realizaroperaciones sobre las colecciones y recursos. Los mtodos HTTPnos permiten operaciones CRUD: Create, Retrieve, Update y Delete.POST para Crear, GET para Obtener, PUT para actualizar yDELETE para borrar. Esto de forma bsica, pero siempre haymatices: qu ocurre si se intenta POST sobre un recurso que yaexiste? cmo puedo actualizar solo algunos atributos de un recurso?y borrarlos? debo permitir todas las combinaciones? Estos matices

6Representational State Transfer (REST),

http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm7RFC 2616: Hypertext Transfer Protocol -- HTTP/1.1,

http://www.ietf.org/rfc/rfc2616.txt
http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htmhttp://www.ietf.org/rfc/rfc2616.txthttp://www.ietf.org/rfc/rfc2616.txthttp://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm


38/380

38

y su solucin los veremos posteriormente desde un punto de vistapragmtico.

Analizando temas algo ms avanzados, surgen aspectos como:

Manejo de errores, que es un tema fundamental para obtener unbuen API. En REST lo fundamental es utilizar los cdigos de errorHTTP: 400 Bad Requestsi la peticin es sintcticamente invalida, 401Unauthorized para problemas de autenticacin, 403 Forbidden paraproblemas de autorizacin o limitacin por polticas, 404 Not Foundsi se intenta acceder a un recurso que no existe (o que se quiereocultar), 5xx cuando hay algn problema en el servidor. Otroscdigos se pueden usar, pero no es recomendable usar todos, sinoaquellos cuyo uso est ms extendido. Para complementar al cdigoHTTP es muy til incluir un bodyHTTP con un formato definidoque incluya por ejemplo el cdigo del error (til para la mquina), untexto descriptivo (para el humano) y una URL donde obtener msinformacin del error. Por ejemplo:

HTTP 403 Forbidden

Content-Type: application/json

{ "errorId": "SVC1000",

"errorInfo": "Falta parmetro obligatorio: autor",

"masInfo":

http://mibiblioteca.com/biblioapi/v1/utils/error/svc1000 }

Filtrados y bsquedas, tiles para obtener recursos de una coleccinque cumplan ciertos criterios y para obtener solo los atributos de losrecursos que se requieran. Tanto los filtrados como las bsquedas, ascomo la paginacin, se consiguen a travs de query strings o query

parameters. Hay diferentes formas de conseguirlo; las siguientes sonformas sencillas y tiles:o Para obtener solo los atributos requeridos de un recurso, basta

con incluir el query ?fields=param1,param2,param3o Para obtener solo los recursos que cumplan uno o varios criterios,

basta con incluir el criterio como query: ?crit1=2&crit2=3,4.Diferentes valores y criterios pueden combinarse para obtenerlgica AND y OR.


39/380

39

o Para paginar, usando dos query parameters se puede hacer todo.Con un parmetro offsetse indica el desplazamiento en el listadode recursos y con un parmetro limitse indica el nmero mximo

de resultados deseados.

Un aspecto fundamental para el mantenimiento y evolucin de unAPI es elversionado. Existen muchas estrategias, pero una sencilla yrecomendable es incluir el nmero de versin del API en la propiaURL, justo despus del nombre del API. Cuando se hagan cambioscompatibles hacia atrs no se evoluciona la versin en la URL, solocuando se haga un cambio que haga incompatible la nueva versin

con la antigua. Existen mtodos probablemente ms ortodoxos ypotentes como utilizar las cabeceras HTTP para sealizar la versindel recurso y las versiones soportadas. Estos mtodos tambin sonms complicados, y en un API REST la sencillez y usabilidad es piezaclave.

Otro aspecto interesante es, cmo indicar la URL de un recursocuando ste es creado? Dos son las principales tcnicas: una esincluir una cabecera HTTP Location en la respuesta a la peticin decreacin del recurso. En la cabecera se incluye la URL donde se ha

creado el recurso. Otra es incluir en la respuesta la representacin delrecurso creado, que incluir entre sus atributos el identificador delrecurso. O, de forma alternativa, devolver solo el identificador delrecurso en vez de su representacin completa. Una prcticarecomendable es incluir tanto la cabecera Location como elidentificador del recurso en el body HTTP; as se consigue de formasencilla una solucin vlida para distintos clientes, los que quieranhacer uso de cabeceras HTTP y los que no.

Formatos y representaciones. El formato que mejor encaja en unAPI REST es JSON8, as que en general elgelo como formato derepresentacin de tus recursos. Tambin puedes hacer un API RESTrepresentando los recursos en XML9, y puedes asociar un esquemaque defina el XML para definir el tipo de tus recursos y sus atributos.Es posible que quieras ofrecer ambas representaciones, en cuyo casotienes que tener unas reglas claras para la transformacin entreformatos, lo cual puede no ser obvio salvo que fijes algunas reglascomo no usar atributos en XML.

8JavaScript Object Notation (JSON), http://www.json.org/9Extensible Markup Language (XML),http://www.w3.org/XML/
http://www.json.org/http://www.w3.org/XML/http://www.w3.org/XML/http://www.json.org/


40/380

40

Por ltimo, usar URLs sencillas y entendibles es fundamental.Recopilando los conceptos tratados en puntos anteriores, se obtieneel siguiente esquema:

https://host:puerto/nombre/{version}/coleccion/{Id}?quer

ies

o nombre: sita aqu el nombre del API.o {version}: variable para indicar la versin del API, con las

normas comentadas anteriormente.o coleccin: nombre en plural para indicar el nombre de la

coleccin. Por ejemplo libros. Puede aadirse jerarqua adicionalcomo colecciones de colecciones. Pero conviene no abusar de lajerarqua, pues complica el entendimiento del API.

o {id}: Variable con el identificador del recurso, que lo indexadentro de la coleccin.

o queries: para filtrar o buscar (en GETs y DELETEs), paginar, etc.Las queries pueden situarse tambin detrs del nombre de lacoleccin, cuando definen escenarios aplicables a la coleccin.

Uso pragmtico de REST: Situaciones y solucionesLas bases de REST son sencillas y claras, pero no siempre es obvio

aplicarlas. Diferentes escenarios o casos de uso requieren un usoimaginativo de REST. No siempre se pueden aplicar las reglas a rajatabla,pero la solucin no es ni optar por soluciones no-REST ni obviar los

principios de REST. La solucin es el REST pragmtico. Los siguientesson casos que pueden ocurrir a la hora de disear un API y sus soluciones,a veces obvias y a veces pragmticas:

Restringir y elegir. No se debe permitir todo

Aplicar CRUD sin contemplaciones puede suponer algunosproblemas. No hay que permitir CRUD totalmente, si alguna operacinno tiene sentido en tu API, simplemente restrngela. Tu API no sermenos REST porque no permita todas las operaciones CRUD.


41/380

41

Algunos escenarios no encajan como recursos, qu hacer?

No intentes ser pragmtico nada ms empezar, piensa bien tus

recursos tratando de ser RESTful. Si aun as sigue alguno de los escenariossin encajar como un recurso, diferncialo claramente. Cmo? Pon un

verbo en tu URL e indica lo que hace esa URL. S, as estars rompiendolos principios de REST, pero estars siendo coherente puesto que no esposible modelar en un recurso tu escenario. A esto lo podemos llamaratajos de funcionalidad y algunos casos tpicos son clculos,conversiones o traducciones. Por ejemplo:

http://miapi.com/diccionario/v1/traducir?texto=hola&de=ESP&

a=ING

Has aplicado un atajo? Lo has pensado bien, no? Una cosa es serpragmtico y otra es hacer trampas

Crear un recurso 'eligiendo su identificador' frente a 'el

servidor elige el identificador':

Generalmente un recurso se crea con POST hacia la URI de lacoleccin. El servidor del API devolver el identificador del recurso enuna cabecera HTTPLocationo en elbodyde la respuesta 201 Created, o enambos.

Pero algunos APIs requieren que el cliente que enva la peticin elijael identificador que indexa al recurso dentro de la coleccin. En este casoen vez de usar POST simplemente se usa PUT y en vez de enviarlo a laURI de la coleccin se enva a la URI del recurso a crear, poniendo elidentificador tras el nombre de la coleccin.

No estamos inventando nada, es la definicin de lo que debe hacerun PUT segn el RFC de HTTP!


42/380

42

PUT para actualizar un recurso completo, POST y DELETE

para actualizaciones parciales:

Observando muchos APIs existentes esto suena raro, pero unabuena estrategia es usar PUT solo cuando se pretende sustituir un recursoenviando su nueva versin de forma completa. De nuevo, as debera sersegn la RFC de HTTP!

Con POST se deberan hacer actualizaciones parciales: los atributosenviados sustituyen a los existentes en un recurso y si no existen los crean.

No se borra nada.

DELETE completa las actualizaciones parciales: los atributosindicados son borrados de la representacin del recurso

De hecho, usa DELETE como GET:

DELETE borrar lo mismo que obtendra un GET a la misma URL.Por ejemplo, si un GET con un queryobtiene solo ciertos atributos de unrecurso, un DELETE con el mismo queryborrar solo esos atributos deun recurso.

Los atajos de usabilidad:

Una vez implementado un API, pasa el examen de su usabilidad. El

examen puede destapar carencias o fallos de diseo, pero tambin puedemostrar que hay algunos casos especiales: una operacin que es utilizadamucho ms que cualquier otra, una combinacin de POST+DELETEque se hace constantemente, un GET previo que sea necesario para poderhacer una actualizacin, etc.

Si alguno de estos casos ocurre en el API, es razonable aadir un

atajo de usabilidad. De nuevo, aunque no sea RESTful, es pragmtico yrazonable aadir un verbo a la URL y exponer tal cual esa funcionalidadespecial que tanto requieren los consumidores del API. No ser RESTful,


43/380

43

pero los consumidores del API tendrn exactamente la herramienta querequieren para la operacin que ms utilizan.

Otros consejos:

Las siguientes son otras decisiones que se pueden tomar, o no. Elcriterio es simplemente hacer lo que mejor encaje en tu API:

En un GET a una lista, devuelve solo los indexadores. Generalmente no permitas una actualizacin a una coleccin, maneja

los recursos uno a uno. Si permites DELETE a una coleccin, fuerza a que se metan

criterios, permitir el borrado de una coleccin no suele ser buenaidea.

Permite la actualizacin parcial (POST, DELETE) o completa(PUT), pero no ambas.

Qu pasos seguir para definir un API REST, unprocedimiento

Para definir un API REST, es posible seguir una metodologa comola siguiente:

Identifica los recursos: colecciones y recursos individuales. Dibuja turbol de recursos, simplemente un esquema jerrquico dondevisualices las colecciones y recursos.

Identifica las operaciones permitidas y las no permitidas sobre losrecursos.

Intenta hacer todo RESTful, no busques los atajos. Detalla los recursos y los atributos de los recursos. Detalla los usos avanzados: filtrados, paginacin, bsquedas,

borrados parciales, etc. Es normal que cuando detalles los recursos, sus atributos y sus usos,

te des cuenta de errores en tu planteamiento. Haz iteraciones yvuelve al paso inicial tantas veces como sea necesario para cambiar lo


44/380

44

que sea necesario. Un API puede ser complejo, y es muy importanteconceptualizarlo bien.

A la vez que defines el API, implemntalo. As conseguirs validar odesechar las decisiones de diseo. No se debe ni disear un API queno se valide implementndolo ni implementar sin haber trabajadomnimamente en el diseo.

Ya est? Revisa qu no ha encajado bien, qu queda forzado o quno has podido modelar. Solo en ese caso, aade los atajos defuncionalidad. Si has llegado a este paso rpidamente y tienes queaadir muchos atajos, entonces no lo ests haciendo bien, vuelve a la

casilla de salida! Ahora s, ya est. y luego? Usa el API, que lo usen otros y entre

todos identificad sus carencias. Tal vez tengas que replantear algnconcepto.

Haz un seguimiento del uso del API. Identifica los atajos deusabilidad. Extiende el API para soportar estos casos concretos.

A lo largo de este artculo hemos visto unas pinceladas de REST, lobsico y algunos usos avanzados. Hemos visto tambin cmo algunasdecisiones pragmticas ayudan a definir APIs ms potentes y a la vezsencillas y operativas. Finalmente, hemos planteado una metodologa aseguir, que esperamos te sea til cuando tengas que definir un API REST.

Diego Gonzlez (Vitoria, 1982) es Solution ArchitectenTelefnica I+D. A lo largo de su vida profesional ha

trabajado en proyectos relacionados con SIP e IMS,habiendo contribuido en el organismo OMA en laestandarizacin de PoC (Push-to-Talk over Cellular) y enlos organismos OMA y GSMA en la estandarizacinde APIs REST de red. Actualmente se centra en laespecificacin y desarrollo del estndar de APIs de reden Telefnica (UNICA APIs), y realiza labores dearquitectura en el producto TuBlue y en laincorporacin de nuevos operadores de fuera delgrupo Telefnica al sistema de pagos contra facturamvil de BlueVia.


45/380

map reduce: el camino hacia bigdata

por Rafael Pelln Gomez-Calcerrada


46/380

46


47/380

47

Introduccin

Algunos conceptos: Big Data, Hadoop, Data Scientist y

Map Reduce

En la actualidad, nos rodea una gran cantidad de informacin por lairrupcin de fenmenos como las redes sociales, aplicaciones mviles,pginas web, comercio electrnico, localizaciones GPS, etc. Adems,existe otra informacin que procede de sensores instalados en aparatoscomo coches, trenes, aviones, autobuses, centrales de energa, incluso

electrodomsticos,... para medir el rendimiento y las actividades de dichosaparatos. Por Big Data se hace referencia al tratamiento y anlisis deenormes cantidades de informacin (como la que mencionbamos en elprrafo anterior) que resulta imposible tratar empleando las herramientasde bases de datos y analticas convencionales. Tras este concepto seesconden las 4V que lo definen: Volumen (gran cantidad deinformacin), Variedad (mltiples fuentes), Velocidad (procesamiento entiempo real o en un tiempo razonable y finito) y Valor (bsqueda deconclusiones beneficiosas descartando la informacin no til).

Apache Hadoop es un entorno de software de cdigo abierto quepermite desarrollar aplicaciones de computacin masiva permitiendo suejecucin de forma distribuida en hardware de bajo coste. Se basa en dostecnologas liberadas por Google conocidas como MapReducey Google FileSystem (GFS).

MapReducees un paradigma de programacin para procesamientos dedatos en paralelo, basado en la combinacin de operaciones map y reducepara resolver un problema. Lo veremos en ms detalle en el siguienteapartado.

El profesional capaz de analizar grandes volmenes de datosempleando tcnicas de Big Data y Anlisis (estadstica y lenguajes comoR) para proporcionar resultados valiosos para los departamentos denegocio se conoce como DataScientisto Cientfico de Datos.


48/380

48

Big Data: Una realidad ya

Mltiples sectores estn adoptando soluciones Big Data. Los

primeros en adoptarlas fueron los sectores de distribucin y financiero.Por ejemplo, la empresa US Xpress10realiz una optimizacin del uso desu flota de vehculos, reduciendo el tiempo de inactividad y el consumo decombustible basndose en la informacin obtenida de multitud desensores en sus camiones.

En el sector financiero, nos encontramos, entre otras, aplicaciones

para mejorar las capacidades de venta cruzadade productos, el controlde fraude y de ofertas personalizadas. Otros sectores donde se estempezando a aplicar son la medicina11, tanto para analizar patrones comopara prevenir enfermedades y las aseguradoras (para proporcionar mejoresofertas y ms personalizadas dependiendo de los patrones de uso).

Finalmente, cabe destacar la iniciativa colaborativa The Human Face ofBig Data12. Se basa en la premisa de que la visualizacin en tiempo real de

datos recopilados, en todo el mundo, por satlites, millones de sensores,etiquetas RFID, smartphonesy cmaras con GPS, permite a la humanidadpercibir, calcular, comprender e influir en aspectos de la existencia comonunca se hubiera imaginado: los hbitos de las personas al levantarse,cmo mejorar el consumo elctrico, el porqu del ruido de los radares enlos aeropuertos, el comportamiento de algunas especies animales,...

El paradigma MapReduce

El concepto. Partes que lo componen e implementaciones

El nico enfoque viable para hacer frente a los grandes problemas dedatos de hoy en da es emplear la idea de divide y vencers, un concepto

10http://www.computerweekly.com/news/2240146943/Case-Study-US-

Xpress-deploys-hybrid-big-data-with-Informatica11

http://tecnologia.elpais.com/tecnologia/2012/08/30/actualidad/1346316706_66

8335.html12

http://humanfaceofbigdata.com/
http://www.computerweekly.com/news/2240146943/Case-Study-US-Xpress-deploys-hybrid-big-data-with-Informaticahttp://www.computerweekly.com/news/2240146943/Case-Study-US-Xpress-deploys-hybrid-big-data-with-Informaticahttp://tecnologia.elpais.com/tecnologia/2012/08/30/actualidad/1346316706_668335.htmlhttp://tecnologia.elpais.com/tecnologia/2012/08/30/actualidad/1346316706_668335.htmlhttp://humanfaceofbigdata.com/http://humanfaceofbigdata.com/http://tecnologia.elpais.com/tecnologia/2012/08/30/actualidad/1346316706_668335.htmlhttp://tecnologia.elpais.com/tecnologia/2012/08/30/actualidad/1346316706_668335.htmlhttp://www.computerweekly.com/news/2240146943/Case-Study-US-Xpress-deploys-hybrid-big-data-with-Informaticahttp://www.computerweekly.com/news/2240146943/Case-Study-US-Xpress-deploys-hybrid-big-data-with-Informatica


49/380

49

fundamental en la informtica desde hace mucho tiempo. La idea bsicaes dividir un problema grande en pequeas tareas. En la medida que lastareas son independientes, se pueden ejecutar en paralelo (en diferentes

procesos y en una o mltiples mquinas). Los resultados intermedios decada tarea individual se combinan para producir la salida final deseada1314.

Las dificultades de la programacin distribuida radican en lasincronizacin de la ejecucin de las tareas, la obtencin de los datosadecuados para cada uno de ellas y la combinacin de resultados parciales.MapReduce proporciona una abstraccin que oculta muchos de estosdetalles a nivel de sistema al programador. Por lo tanto, un desarrolladorpuede concentrarse en las tareas que se tienen que realizar, en lugar decmo se ejecutan y/o cmo se obtiene la informacin que necesitan (yasea directamente o de otras tareas).

El paradigma MapReduce deriva de las funciones map y reduce queexisten en el lenguaje de programacin funcional LISP. En este lenguaje,la funcin map, recibe como argumentos una funcin y una serie de

valores y luego aplica dicha funcin a cada uno de los valores de la serie;luego la funcin reduce aplica alguna operacin bsica para resumir (oreducir) los datos de la secuencia. En el modelo MapReduce queimplementa Hadoop, tenemos

Funcin map

Se encarga del mapeo y se aplica en paralelo para cada tem de la

entrada de datos. Esto produce una lista de pares (clave, valor) por cadallamada. Si por ejemplo tenemos un fichero de texto como entrada, elnmero de lnea sera nuestra clave (k1) y el valor (v1) sera la lnea detexto.

Map (k1, v1) -> lista (k2, v2)

13http://lintool.github.com/MapReduceAlgorithms/ed1n/MapReduce-

algorithms.pdf14

http://youtu.be/bR2LOic_mAM
http://lintool.github.com/MapReduceAlgorithms/ed1n/MapReduce-algorithms.pdfhttp://lintool.github.com/MapReduceAlgorithms/ed1n/MapReduce-algorithms.pdfhttp://youtu.be/bR2LOic_mAMhttp://youtu.be/bR2LOic_mAMhttp://youtu.be/bR2LOic_mAMhttp://lintool.github.com/MapReduceAlgorithms/ed1n/MapReduce-algorithms.pdfhttp://lintool.github.com/MapReduceAlgorithms/ed1n/MapReduce-algorithms.pdf


50/380

50

Funcin reduce

Se aplica en paralelo para combinar todos los valores intermedios

(v2) asociados con la misma clave (k2) para reducirlos y generar la salidacorrespondiente para cada uno de ellos (k3). El resultado global ser elconjunto de todas las salidas de los reduces.

Reduce (k2, lista (v2)) -> lista (v3)

Veamos un ejemplo en la Figura 1:Disponemos de un conjunto deformas geomtricas con un color determinado y queremos saber cuntas

hay de cada una de ellas. Las formas se pueden leer fila a fila. Para cadafila, se aplica la funcin map, obteniendo cada una de las formas (clave) yel valor ser 1 (una ocurrencia de una forma) ya que lo que estamoshaciendo es contar. Posteriormente, los datos se reorganizan de formatransparente al programador, para servir de entrada a la funcin reducequese encarga de sumar el nmero de veces que aparece cada forma.

Figura 1: Ejemplo MapReduce de cuenta de formas


51/380

51

Los problemas habituales en donde se emplea son la bsqueda decoincidencias de patrones, frecuencia de variables y la obtencin de

ndices invertidos.

Dentro de Hadoop, existen mltiples implementaciones deMapReduce en distintos lenguajes, desde la versin nativa en Java a otrasen C++ o Python. Los ejemplos descritos en este artculo utilizarn laimplementacin descrita en Python por ser la ms sencilla de comprender.Dicha implementacin se conoce con el nombre de Dumbo15. Lainstalacin del mismo no tiene ningn problema y simplemente es seguirlas indicaciones que se explican en la documentacin.

Ejemplo Bsico: Vamos a contar palabras

El objetivo de este ejemplo es contar el nmero de ocurrencias quehay de cada palabra en un fichero de texto. El carcter separador entrepalabras ser el espacio. El fichero se llamar wordcount.py.

# Cuntas veces ocurre cada palabra en un fichero de texto

def mapper(key,value):

for word in value.split():

yield word,1

def reducer(key,values):

yield key,sum(values)

if __name__ == "__main__":

import dumbo

dumbo.run(mapper,reducer)

15https://github.com/klbostee/dumbo/
https://github.com/klbostee/dumbo/https://github.com/klbostee/dumbo/


52/380

52

Para ejecutarlo, simplemente ejecutaremos el comando siguiente:

dumbo start wordcount.py -input -output

La idea es la misma que en el ejemplo descrito previamente de lasformas. En este ejemplo, la lectura de lneas del fichero es transparente alprogramador, que se puede centrar en realizar la operacin que deseaimplementar. Vemoslo con ms detalle.

Operacin Map

En nuestra definicin de Map (k1, v1), v1se corresponde con cadauna de las lneas del fichero de texto que ser, mientras que k1 no nosinteresa (ser el nmero de lnea del fichero pero la implementacin deHadoop/MapReduce nos los abstrae). La salida de la operacin Map, seruna lista (k2, v2)donde k2ser cada una de las palabras de la lnea y el

valor en este caso ser 1 ya que lo que queremos hacer es contar palabras.

As, por ejemplo para la lnea la casa roja es la tuya tendremos laspalabras siguientes: la, casa, roja, es, la, tuya. Para cada unade ellas generaremos una salida [la, 1], [casa, 1], [roja, 1], [es, 1], [la, 1], [tuya,1].

Operacin Reduce

En nuestra definicin de Reduce (k2, lista (v2)), k2 se

corresponde con cada una de las palabras a contar, mientras que lista (v2)ser una lista de 1s (las ocurrencias de la palabra). La salida de laoperacin Reduce ser cada una de las palabras con la suma de los 1s.

As, por ejemplo tendremos distintas ejecuciones de la funcin Reducepara cada una de las palabras [la, {1,1}], [casa, {1}], [roja, {1}], [es, {1}],[tuya, {1}] y los resultados respectivamente para cada una de estasentradas sern [la, 2], [casa, 1], [roja, 1], [es, 1], [tuya, 1]

Si imaginamos, por ejemplo, que esta operacin se puede hacer paratodos los libros de la biblioteca nacional para obtener la palabra que msaparece en el castellano en sus libros, nos encontramos ante un problemade Big Data, que con esta tcnica se puede resolver fcilmente.


53/380

53

Ejemplo Avanzado: Secuencia de maps y reduces

Una empresa de paquetera, tiene organizada su informacin en tres

tipos de ficheros:

Ficheros de usuarios, que contienen el nombre del cliente el cdigodel pedido que tiene asociado.

Ficheros de pedidos, donde se almacena para cdigo de pedido, suestado

Fichero de estados de un pedido, donde se tiene el cdigo de estadoy la descripcin de dicho estado.

La empresa de paquetera quiere tener un informe, en el que se leindique para cada usuario, su pedido y el estado del mismo en texto.

Los datos para cada uno de los ficheros sern los siguientes:

Delivery_users.txt

P123,Jim

P456,Tom

P789,Harry

P111,Richa

delivery_details.txt

P789,002

P123,001

P456,004

P111,003

delivery_statuscodes.txt


54/380

54

001,Delivered

002,Pending

003,Failed

004,Resend

El fichero se llamar delivery_report.py

import sys

import dumbo

from dumbo import main, identityreducer, identitymapper

from dumbo.lib import MultiMapper

def users_parser(key, value):

tokens = value.split(",")

k = tokens[0]

v = ('US', tokens[1])

yield k, v

def deliveries_parser(key, value):


k = tokens[0]

v = ('ST', tokens[1])

yield k, v

def status_parser(key, value):


55/380

55


k = tokens[0]

v = (tokens[1],)

yield k,v

def reducer1(key, values):

user = ""

status = ""

for v in values:

if v[0] == 'US':

user = v[1]

elif v[0] == 'ST':

status = v[1]

# Generate the exit

if (user != "" and status != ""):

yield status, (user, key)

def reducer2(key, values):

status = ""

info = []

for v in values:

if len(v)==2:

info = v


56/380

56

elif len(v)==1:

status = v[0];

# Generate the exit

if (status != "" and len(info)>0):

yield info, status

# Jobs workflow function

def runner(job):

# Step 1: Prepare users, details deliver

opts = [ ("inputformat","text"), ("outputformat","text")]

multimapper = MultiMapper();

multimapper.add("users", users_parser)

multimapper.add("details", deliveries_parser)

o1 = job.additer(multimapper, reducer1, opts=opts )

# Step 2: Get status description

multimapper = MultiMapper();


57/380

57

multimapper.add("status", status_parser)

o2 = job.additer(multimapper, identityreducer,opts=opts, input=[job.root] )

# Step 3: Join results

o3 = job.additer(identitymapper, reducer2, opts=opts,input=[o1, o2] )

if __name__ == "__main__":

from dumbo import main

dumbo.main(runner)

Para ejecutarlo, simplemente ejecutaremos el comando siguiente:

dumbo start delivery_report.py -input -

output

En este ejemplo, se crea un trabajo compuesto por tres pasos:

1. Se ejecuta un paso map/reduce para juntar los ficheros de usuarios yde pedidos, empleando para ello dos maps dependiendo del nombredel fichero y un nico reduce donde se juntan las salidas. lasfunciones que corresponden a este paso son users_parser,deliveries_parser y reducer1. La salida ser el cdigo del estadodel pedido y el nombre del usuario y el cdigo de pedido. Este pasosera equivalente a una funcin JOIN en una base de datos.

2. El segundo paso, consiste en un map/reduce para organizar elfichero de cdigo de estados de pedidos y descripcin con unformato similar al primer paso. Las funciones asociadas a este pasoson el status_parser y un tipo especial de reducer conocidoidentityreducerque genera una salida por cada entrada.


58/380

58

3. Finalmente, se juntan ambas salidas de los pasos intermedios paraconseguir el resultado final. las funciones asociadas a este procesoson un identitymappery el reducer2.

Ms cosas a explorar

Como hemos visto, existe la posibilidad de construir flujos deoperaciones ms complejas donde se encadenan una serie de operacionesMapReduce16 o realizar distintos tipos de join entre varios datasets.Dumbo realiza realmente bien este tipo de operaciones. Existen mltiples

tcnicas para ejecutar los map/reduces, pero quedan fuera del mbito deeste artculo. Lo importante es que conozcas la tcnica y hayas entendidoen qu escenarios puede ser ms til; ahora slo queda que comiences aresolver problemas con MapReduce.

Rafael Pelln Gmez-Calcerrada (Madrid, 1974) esData Scientist en Telefnica I+D. Durante su vidaprofesional ha trabajado en proyectos web enmltiples tecnologas (ASP, JSP, Java, Flex) y BI; desdesoluciones tradicionales (informes, cuadros demando,) hasta soluciones novedosas relacionadascon Big Data (Hadoop, Hive, MapReduce,),especialmente en temas de visualizacin de datos.

16http://dumbotics.com/
http://dumbotics.com/http://dumbotics.com/


59/380

de apple pie a jelly bean:

la dulce historia de Androidpor Jess Gumiel Ramrez


60/380

60


61/380

61

Introduccin

Este artculo tiene como principal objetivo hacer un repaso de lahistoria de Android, desde su concepcin hasta el da de hoy (Noviembre2012). La intencin del mismo es dotar al lector del contexto suficientepara entender la evolucin del sistema operativo, y las razones que lo hanllevado a ser lo que es.

Qu es Android?

A da de hoy es difcil encontrar alguien que no sepa que Android esun sistema operativo basado en Linux y diseado para correrprincipalmente en dispositivos mviles, tales con smartphoneso tablets, peroquizs no es tan conocido, que el desarrollo de Android es realizado porGoogle, en colaboracin con la OHA(Open Handset Alliance).

La OHA es una alianza comercial de 84 empresas de todos losmbitos (proveedores de telefona, fabricantes de chips, fabricantes determinales, desarrolladores, etc.), que se dedica a desarrollar estndaresabiertos para dispositivos mviles.

Cmo comenz todo: Andy Rubin, el pap de Android

No se puede hablar de los comienzos de Android sin mentar alhombre que le dio la vida, Andy Rubin. Un licenciado en Ciencias de

Computacin por la Universidad Utica de Nueva York, que curiosamenteempez a trabajar como ingeniero de Apple.

Tras Apple, vino General Magic, donde particip en el desarrollo deMagic Cup, que pretenda ser un sistema operativo para telfonos. De ahpas a Artemis Research (comprada posteriormente por Microsoft) antesde fundar Danger Inc, la empresa que desarroll el Hiptop, un telfonoque marcara las pautas de los actuales smartphones.

As que tenemos que entre 1989 y 2003 Andy pas por Apple,Microsoft, fund su propia empresa y particip en proyectos de desarrollo


62/380

62

tanto hardware como software relacionados con telefona mvil. Quesera lo siguiente? Pues fundar Android Inc en 2003.

En agosto del 2005 Android fue comprada por Google, donde Rubinostenta actualmente el puesto de Vicepresidente de Ingenierasupervisando el desarrollo de Android.

El porqu del nombrado de versiones

A nadie se le escapa el tirn comercial de los nombres de las

versiones de Android, y todo el juego que da en cuanto a marketing, peropocos saben qu llev a los chicos de Google a seguir esta nomenclatura.

Empecemos por el principio, el comienzo del desarrollo, all cuandolas primeras versiones se identificaban por una M de Milestone, seguidadel nmero de hito. El siguiente paso fue aadirle una wb de WeeklyBuild, debido a que las compilaciones por aquel entonces eran semanales, ypara rematar tc de TestCycle, con lo que acababas teniendo algo como

M3-WB22-TC3. Sencillo de recordar, no?

Los desarrolladores vieron que era inviable usar esta nomenclatura, ybuscaron un criterio divertido y sencillo de recordar. Se decidi que elorden de nombrado fuera alfabtico, y tras un primer intento de usarnombres de robots famosos - de ah que las primeras versiones fueranconocidas como Astro Boy y Bender - se opt por los pastelitos. Larazn? El gusto por los Petit Fourdel manager de producto, que decididar este nombre interno a la versin 1.1. A partir de las siguientes

versiones y una vez decidido seguir la temtica de los dulces, seestandariz el orden alfabtico para continuar con CupCake, Donutyas hasta la actual Jelly Bean. Posteriormente se ha conocido la versin 1.0como Apple Pie, aunque segn explica Google oficialmente, tanto las

versiones 1.0 como 1.1 no tenan codename; el inicio de la dulce saga fue la1.5.

En el siguiente listado aparecen las versiones liberadas a da de hoy(noviembre 2012):


63/380

63

Versiones preliminares, entre ellas las nombradas Astroboy yBender.

1.0Sin nombre oficial, nombrada a posteriori como Apple Pie. 1.1Sin nombre oficial, internamente se la llam Petit Four. 1.5Cupcake. 1.6Donut. 2.0/2.1clair. 2.2Froyo. 2.3Gingerbread. 3.0Honeycomb. 4.0Ice Cream Sandwich. 4.1/4.2Jelly Bean.La evolucin de Android

Desde la primera versin de Android hasta el da de hoy, el procesode evolucin y aparicin de nuevas versiones ha sido continuo e

increblemente rpido: 11 versiones en 5 aos nos dan una idea de laseriedad con que se toman los californianos de Google la evolucin de susistema operativo mvil.

La primera versin en salir a la luz, la 1.0, la pudimos ver en el primermvil Android, el HTC Dream, all por Octubre del 2008. Poco ms deun ao despus de que su gran competidor Apple presentara el iPhone.

Ah empezara la lucha de poder entre estos dos gigantes, lucha que ha

vivido su ltimo hito en Octubre del 2012 con la presentacin de laversin 4.2de Android, anunciada como un nuevo sabor paraJelly Beany preinstalada en su flamante Nexus 4.

En la tabla siguiente se esquematiza la evolucin de Android,mostrando sus versiones, fecha de lanzamiento, versin de la API queimplementan y la cuota de distribucin que tienen a fecha de Noviembre2012. Hay que tener en cuenta que estos porcentajes corresponden conalrededor de 400 millones de dispositivos Android activados.


64/380

64

Tabla 1. Distribucin versiones de Android17

Android y la fragmentacin

Una vez repasados los orgenes de Android y su evolucin, tenemossuficiente datos para analizar la principal problemtica con la que sus

desarrolladores se encuentran a da de hoy, la fragmentacin.

11 versiones en 5 aos, 400 millones de dispositivos activados,cientos de diferentes modelos de terminales con Android instalado, y msde 300 socios en diversos mbitos: hardware, software, proveedores detelefona,

Este crecimiento vertiginoso sufri una aceleracin exponencial

durante el ao 2011, justo el ao en que los chicos de Google empezarona darse cuenta de la imperiosa necesidad de imponer unas guas de estilo

17http://developer.android.com/about/dashboards/index.html

Versin Nombre Liberada API Cuota

1.5 Cupcake Abril 2009 3 0.1%

1.6 Donut Septiembre 2009 4 0.3%

2.1 Eclair Enero 2010 7 3.1%

2.2 Froyo Mayo 2010 8 12.0%

2.32.3.2 Gingerbread Diciembre 2010 9 0.3%

2.3.3- 2.3.7 10 53.9%

3.1 Honeycomb Febrero 2011 12 0.4%3.2 13 1.4%

4.0.X Ice CreamSandwich

Octubre 2011 15 25.8%

4.1 Jelly Bean Junio 2012 16 2.7%

4.2 Octubre 2012 17 Sin datos
http://developer.android.com/about/dashboards/index.htmlhttp://developer.android.com/about/dashboards/index.html


65/380

65

sobre las aplicaciones que corrieran sobre sus sistemas operativos, y deproporcionar compatibilidad con las versiones ms antiguas de su API. Yes que, qu desarrollador iba a lanzar su producto utilizando el SDK 15, si

no iba a poder ser usado por casi el 75% de los usuarios.

El perfil de los usuarios de Android es otro de los factores que hanfacilitado sobremanera la existencia de tantos terminales ejecutndose con

versiones de Android de hace ms de dos aos. A diferencia de losusuarios de iPhone, que estn siempre al da de actualizaciones, y corren ala tienda en cuanto sale una nueva actualizacin, el usuario de Androidentiende el mvil como una herramienta, y mientras cubra sus necesidadesno lo va a cambiar. Tampoco son muy dados a estar al da de lasnovedades en cuanto a aplicaciones, ni a descargarlas compulsivamente.En datos, slo el 13% de los usuarios tiene ms de 50 aplicacionesinstaladas, y menos de un 3% tienen aplicaciones de pago.

La importancia de Honeycomb

Estamos hablando de la fragmentacin de Android, de cmointentan estandarizar sus desarrollos, y de pronto aparece un puntodedicado a Honeycomb; parece un tema fuera de contexto, pero nada mslejos de la realidad.

Cmo comentamos en el apartado dedicado a la evolucin deAndroid, en 2011 Google se sumergi en el mercado de las tabletas yliber Honeycomb, una versin especfica para estos dispositivos, peroque sin embargo supuso un punto de inflexin en la evolucin de

Android.

Con Honeycomb aparecieron los Fragments, orientados a apoyardiseos de interfaz de usuario ms dinmicos y flexibles en las pantallas degran tamao, pero tremendamente tiles, adems, a la hora de reutilizarcomponentes entre actividades y liberar de cdigo a estas.

Otra de las grandes novedades de la versin fue la ActionBar,implementada con un claro objetivo: intentar estandarizar la apariencia delas aplicaciones desarrolladas para Android. De esta manera la ActionBar


66/380

66

se convierte en el lugar desde el cual se maneja la navegacin de laaplicacin, dejando claro en cada momento, donde ests, de dnde vienes,y qu puedes hacer en la pantalla en la que te encuentras.

Y ahora que tienes Fragments, y tienes ActionBar, por destacar lasdos principales novedades introducidas por HoneyComb, cmo le dices alos desarrolladores que no pueden usarlas en dispositivos con una APIinferior a la 11. Simplemente no puedes, y ah radica la importancia de esta

versin.

ICS, Estandarizando el diseo

Tras Honeycomb lleg ICS, que se podra considerar casi una mezclaentre Gingerbread y ste, ya que su principal caracterstica es aunar elmundo tableta con el mundo mvil.

Google empez a darle una importancia mxima al diseo, y a crearuna imagen fcilmente reconocible en sus aplicaciones; el objetivo es que

cualquiera que viera una aplicacin para Android supiera a que sistemaoperativo perteneca.

En enero del 2012 Google lanza unas guas de estilo para eldesarrollo de Apps sobre ICS, algo muy en la lnea de Apple. Es algo quedesde hace tiempo reclamaban tanto los usuarios como losdesarrolladores, y durante este ao se convirti en una obsesin.

Unos meses ms tarde lavan la cara de la web de Android developerspara seguir el estilo ICS, una decisin controvertida inicialmente, pero queal final ha resultado ser acertada, y que ha dotado al mundo Android deuna lnea clara de diseo en todos sus frentes.

Soluciones contra la Fragmentacin

En este apartado se hablar de las medidas que desde el ao 2011est tomando Google para acabar con el problema de la fragmentacin.En los siguientes puntos veremos cmo las soluciones pasanprincipalmente por los desarrolladores, y por intentar que estos sean los


67/380

67

encargados de hacer aplicaciones compatibles con el mayor nmero decantidad de dispositivos posibles, manteniendo una apariencia y unanavegabilidad uniforme en todas ellas.

Aunque no podemos olvidar decisiones comerciales como podranser el lanzamiento del Nexus 4 libre y a un precio bajsimo, sin duda unabuena manera de convencer a los usuarios con un mvil antiguo (digamoscon una versin de Android 2.3), que ya es hora de cambiar de terminal.Ser interesante ver la evolucin de la tabla 1 en los prximos meses.

Android Support Library

En marzo del 2011 se liber la primera versin de la librera decompatibilidad android-support. El objetivo de esta librera esproporcionar a los desarrolladores una serie de bibliotecas estticas deapoyo, de manera que puedan seguir desarrollando sus aplicaciones parauna determinada versin de la API, o con compatibilidad para sta, peroutilizando caractersticas de una versin de la API de Android superior.

Por ejemplo gracias a la librera de soporte, es posible implementaruna aplicacin ejecutable en un dispositivo con Froyo instalado (API 8),pero que haga uso de Fragments, incorporados en la versin 11 de la APIde Android.

La primera versin de la librera de soporte, llamada android-support-v4, debe su sufijo v4, a que ofrece compatibilidad desde la API 4

haca arriba. A da de hoy van 11 revisiones de la librera, que cada par demeses ms o menos va siendo incrementada con nuevas funcionalidades.

A partir de la revisin 3 del paquete, se incluye la biblioteca android-support-v13, que ofrece compatibilidad para versiones con un nivel 13 osuperior de la API. Esta librera es un superconjunto de la v4, e incluyeclases adicionales para trabajar con las API v13.

Hay que tener cuidado qu versin de la librera utilizar, porque sibien podras utilizar la v13 para todo, ya que contiene a la v4, si se utiliza


68/380

68

alguna de las clases que requieren a la API 13, la aplicacin dejar de sercompatible con mviles corriendo versiones inferiores de Android.

Otras libreras de soporte no oficiales. Compatibilizando laActionBar

Con la aparicin de HoneyComb tambin surgieron varias librerasno oficiales para ofrecer soporte a los nuevos diseos introducidos en la

versin para tabletas. Dichas libreras se centraron sobre todo en ofrecercompatibilidad con la ActionBar, un elemento que haba sido olvidadopor la librera de soporte de Android. Probablemente el olvido no sea tal,sino que vieron inviable ofrecer desde la librera el soporte grfico que la

ActionBar requiere.

As a principios de 2011 surgieron algunos proyectos que hanacabado siendo imprescindibles para el desarrollo de cualquier aplicacinque pretenda implementar la ActionBar en dispositivos con una versinde Android inferior a la 11.

De todos los proyectos de este tipo, el ms utilizado sin duda ha sidoActionbarsherlock18, una extensin de la biblioteca de soporte diseadopara facilitar el uso del patrn de diseo ActionBar a travs de todas las

versiones de Android con una nica API. La biblioteca utilizaautomticamente la barra nativa cuando es posible (API >=11) o utiliza laimplementacin de sherlock en caso contrario.

Android y el diseo

Cmo hemos comentado al hablar de ICS, en Enero del 2012Google lanz unas guas de estilo para Android, y comenz su lucha porintentar que todos los desarrolladores las siguieran. Parte de esa estrategiade plantear una lnea comn fue el rediseo del portal de desarrolladoresde Android, lugar de referencia dnde se puede encontrar toda la

informacin que Google proporciona sobre Android.

18http://actionbarsherlock.com/
http://actionbarsherlock.com/http://actionbarsherlock.com/


69/380

69

De esta manera Google intenta responder a la principal reclamacinque histricamente ha tenido Android, y es que sus diseos no seguanuna lnea comn, que cada desarrollador haca las cosas de una manera, y

que en muchas ocasiones el resultado final era bastante poco atractivo, ydaba sensacin de dejadez grfica.

Ahora se anima al desarrollador a cuidar estos aspectos con frasescomo: Tu aplicacin debe esforzarse por combinar la belleza, la sencillezy la intencin de crear una experiencia mgica, sin esfuerzo y poderosa.

La muestra definitiva de cmo Google ha puesto el foco en el diseose ha visto en el Google I/0 del 2012, dnde gran cantidad de lasponencias y los talleres estaban dedicados a este aspecto.

En resumen, la web sobre patrones en Android19 debera ser lacabecera de todos aquellos que trabajamos con Android. Si todosseguimos sus consejos, quizs en el prximo libro sobre Android que leas,la fragmentacin sea descrita como un problema del pasado.

Jess Gumiel (Badajoz, 1982) es Ingeniero I+D enTelefnica I+D. Comenz su carrera profesionaldesarrollando backend para provisin de servicios, ypoco a poco fue evolucionando hasta el mundo deldesarrollo mvil, aunque sin olvidar los servicios decomunicacin y la VoIP. Fan del mundo emprendedor,en el cual se ha introducido con el proyectoFootballtracker20.

19http://developer.android.com/intl/es/design/patterns/index.html20

http://www.football-tracker.com
http://developer.android.com/intl/es/design/patterns/index.htmlhttp://www.football-tracker.com/http://www.football-tracker.com/http://developer.android.com/intl/es/design/patterns/index.html


70/380


71/380

la comunicacin, ese gran desconocido

por Alberto de Vega Luna


72/380

72


73/380

73

Y esto, qu tiene que ver con el desarrollo?

Hay muchas cosas que pueden impactar en que un proyecto dedesarrollo software llegue o no a buen puerto: la tecnologa utilizada, laexperiencia del equipo, la coordinacin del mismo, el trato con elcliente, Y casi todos estos factores tienen en comn una nica cosa: lacomunicacin.

Por tanto, como desarrolladores o arquitectos o coordinadores deequipos (o cualquier otro rol que se te ocurra), tenemos que asegurarnos

de que todo el mundo sepa lo importante que es la comunicacin. Todo elmundo tiene que saber la tecnologa que se usa, en qu tiene experienciacada miembro del equipo, qu se espera de cada uno, qu tareas quedanpor hacer, las expectativas del cliente, Comunicacin, comunicacin,comunicacin!

Qu no es la comunicacin

Cuando nos damos cuenta de que algo no ha ido bien debido a unproblema de esta ndole, la solucin parece clara y siempre hay alguien quedice Necesitamos ms comunicacin. Y la siguiente mente brillante diceeso de Podemos hacer reuniones de seguimiento peridicas. En smisma, esta idea no es mala, pero debemos tener cuidado con no morirpor reunionitis. Por tanto, son las reuniones una manera de mejorar lacomunicacin?

S, pero siempre que tengamos en cuenta las siguientes condiciones:

Aprovechando las herramientas de calendario existentes hoy en da,es bueno enviar la convocatoria con antelacin para que a todo elmundo le aparezca en la agenda y la acepte o la rechace. Tambin esbueno indicar si la asistencia es obligatoria u opcional a cadaparticipante. Una convocatoria enviada as recibe ms atencin queun correo electrnico diciendo algo como Nos vemos a las 7 para

ver el tema de. Hay que empezar a la hora acordada, pero tambin terminar en el

momento que se haba programado. El tiempo es una de las cosas


74/380

74

ms valiosas que hay, as que no se lo hagas perder al resto mientraste esperan ni les hagas llegar tarde a las siguientes reuniones.

Las reuniones tienen que tener un objetivo y todos los asistentestienen que saber cul es el objetivo concreto de esa reunin. El que laha convocado tendr tambin que presentar dicho objetivo nada msempezar.

Las reuniones deberan tener una agenda que se haya enviado conantelacin para que la gente pueda prepararse los contenidos adebatir. Si sale algn tema que tenga ramificaciones fuera del mbitode esta reunin, es mejor convocar otra reunin separada para ello

(con los asistentes adecuados, como comento en el siguiente punto). El organizador de la reunin solo debera invitar a aquellas personas

que es imprescindible que vayan. A veces es posible que una personatenga que estar solo en un momento determinado para explicar oaclarar una cosa: pues bien, para eso tenemos una agenda. As esapersona puede saber a qu hora tiene que entrar y salir de la reunin.Otra posibilidad es que le llamemos por telfono para hacer esaaclaracin y luego le dejemos seguir con sus tareas habituales;

obviamente, hay que avisarle con suficiente antelacin para que tengapreparado lo que tiene que contar y pueda planificarse tambin suagenda de ese da teniendo en cuenta esa reunin.

Tras la reunin, tiene que haber unas conclusiones y unos puntos deaccin y que est claro quin tiene que llevar a cabo esos puntos deaccin y las fechas esperadas para su cumplimiento o revisin. Porsupuesto, es importante que esto quede escrito en algn sitio parafuturas consultas. Lo que me lleva a hablar de

Herramientas: cuando tenemos un martillo todo

nos parecen clavos

No por tener la herramienta ms impresionante del mercado en losservidores de la compaa vas a conseguir una mejor comunicacin. Y si

no, fjate en tu entorno: sistemas de control de versiones, wikis, carpetascompartidas, herramientas colaborativas, foros, microblogging, Estamosdesbordados de herramientas y pese a todas esas posibilidades, en muchos


75/380

75

proyectos sigue pasando eso de Pero eso, cundo lo habis decidido? Am no me lo habis dicho.

Est claro que una herramienta es solo un medio de comunicacin ydebemos usar la ms adecuada en cada caso. Lo ideal sera tener unaherramienta comn con una vista para los gestores (con el seguimiento detareas, lo que falta por hacer, las prioridades, etc.) y otra vista para losdesarrolladores (con el cdigo fuente, los parches, las revisiones decdigo, etc.) que estuvieran relacionadas (cuando subas un trozo decdigo, que el bug corregido se refleje en el seguimiento de tareas) quetuviera tambin un repositorio de documentacin asociada a las tareas.Pero mientras buscamos esa herramienta, no podemos dejar abandonadaesta parte, as que aqu van una serie de consejos basados en la experienciapara seleccionar el medio de comunicacin a emplear en cada ocasin.

El cdigo fuente debe estar en un repositorio compartido con sucontrol de versiones correspondiente, eso es obvio. Pero noadelantemos acontecimientos, porque vamos a dedicarle su propio

apartado a este punto. Lo que nos ha servido para hacer ese cdigo fuente (diagramas de

arquitectura, flujos, especificaciones de requisitos, validaciones porparte de cliente, actas de reuniones, etc.) tiene que estar en unrepositorio de documentacin. Este trmino tan genrico puedesignificar una wiki, una carpeta compartida o una herramienta tipo

Alfresco o Sharepoint. El caso es que cuando tengamos dudas,podemos ir ah a consultarlas o al menos, ver qu persona ha hechoun documento en concreto y hacerle cualquier pregunta quetengamos. Lo que no es eficiente es compartir esta informacinnicamente por mail y luego estar rebuscando en nuestro cliente decorreo la informacin cuando ni siquiera recordamos el asunto delcorreo o quin lo envi.

El correo es una mala herramienta para el debate. En cuanto unasunto provoque tres correos seguidos, hay que usar el telfono o

hacer una reunin con los implicados. Si no, corremos el riesgo deprovocar una oleada de SPAM que rete t de las botnetde las mafiasrusas. El resultado de la reunin s podemos mandarlo por email. O


76/380

76

mejor an, debemos meterlo en el repositorio de documentacin ymandar un mail para decir dnde est disponible.

El correo tambin es una mala herramienta para hacer un documentoentre varios. Olvida eso de mandar adjunto el documento (o la hojade clculo o la presentacin) para que cada uno aplique los cambios yte los mande. Eso produce ms caos que un imn en un disco duro.Seguro que te suenan frases como Perdona, te mando otra vez elfichero que faltaban por integrar los cambios de Juan. Eh! Heaadido dos filas ms en verde para que las integres con la ltima

versin. Y, cul ser la ltima versin? Para estos casos, tener unaaudio conferencia mientras el dueo del documento lo compartemediante join.me (por ejemplo, tambin se puede usar Skype, Lync o

Webex) permite que todo el mundo vea a la vez los cambios de losdems y pueda haber debates. Y otra posibilidad es alojar eldocumento (si no es confidencial, porque incluso con las opciones deprivacidad hay riesgos) en Google Docs para que todo el mundopueda ir aadiendo a la vez las modificaciones y ver las de los dems.Incluso puedes combinar ambas opciones, usando Google Docs para

una primera ronda de contribuciones y luego hacer el remate final enesa audio conferencia.

El correo es bueno cuando no podemos tener una comunicacinsncrona con nuestro interlocutor (o interlocutores) y necesitamospedir algo. Y, cmo deberamos estructurar un correo? Puesdeberamos explicar el contexto, el problema que tenemos, lasolucin que proponemos (si la tenemos) y lo que estamos pidiendo(puede ser la propia solucin, una autorizacin, un dato, una reunin,etc.). Y el correo si breve, dos veces bueno. Siempre puedes ponerun enlace al repositorio documental o a una wiki donde des mscontexto o incluir un adjunto o cosas as.

Los chats (como Skype o Lync) tambin son tiles para resolverdudas rpidas en el momento. Si la cosa se complica (malentendidosen el texto, conversacin con varios interlocutores simultneos), usala voz. Y respeta a las personas que tienen su Estado como Ocupado

o No disponible. Mejor an,

Documents

Documento Nod Up