Historias de developers

by Alberto de Vega Luna

es pragmático y razonable añadir un verbo a la URL y exponer tal cual esa funcionalidad especial que tanto requieren los consumidores del API. No será RESTful, pero los consumidores del API tendrán exactamente la herramienta que requieren para la operación que más utilizan.

metodología

Metodología para definir una API REST

Identifica los recursos: colecciones y recursos individuales.

Identifica las operaciones permitidas y las no permitidas

Intenta hacer todo RESTful

Detalla los recursos y los atributos de...

Detalla los usos avanzados: filtrados, pagina...

Haz iteraciones y vuelve al paso inicial tantas veces como sea necesario para cambiar lo que sea necesario.

conceptualizarlo bien.

A la vez que defines el API, i...

conseguirás validar o desechar las decisi...

qué queda forzado o qué no has podido modelar. Solo en ese caso, añade los ‘atajos de funcionalidad’.

tienes que añadir muchos atajos, entonces no lo estás haciendo bien,

identificad sus carencias. Tal vez tengas que replantear algún concepto.

Identifica los ‘atajos de usabilidad’. Extiende el API para soportar estos casos concretos.

Big Data se hace referencia al tratamiento y análisis de enormes cantidades de información (como la que mencionábamos en el párrafo anterior) que resulta imposible tratar empleando las herramientas de bases de datos y analíticas convencionales.

las “4V” que lo definen: Volumen (gran cantidad de información), Variedad (múltiples fuentes), Velocidad (procesamiento en tiempo real o en un tiempo razonable y finito) y Valor (búsqueda de conclusiones beneficiosas descartando la información no útil).

MapReduce es un paradigma de programación para procesamientos de datos en paralelo, basado en la combinación de operaciones map y reduce para resolver un problema.

optimización del uso de su flota de vehículos,

mejorar las capacidades de venta cruzada de productos, el control de fraude y de ofertas personalizadas

Android es un sistema operativo basado en Linux y diseñado para correr principalmente en dispositivos móviles, tales con smartphones o tablets, pero quizás no es tan conocido, que el desarrollo de Android es realizado por Google, en colaboración con la OHA (Open Handset Alliance).

Cómo comenzó todo: Andy Rubin, el papá de Android

tras un primer intento de usar nombres de robots famosos

las siguientes versiones y una vez decidido seguir la temática de los dulces,

Google empezaron a darse cuenta de la imperiosa necesidad de imponer unas guías de estilo sobre las aplicaciones que corrieran sobre sus sistemas operativos, y de proporcionar compatibilidad con las versiones más antiguas de su API

de los usuarios de iPhone, que están siempre al día de actualizaciones, y corren a la tienda en cuanto sale una nueva

usuario de Android entiende el móvil como una herramienta, y mientras cubra sus necesidades no lo va a cambiar. Tampoco son muy dados a estar al día de las novedades en cuanto a aplicaciones, ni a descargarlas compulsivamente.

2011 Google se sumergió en el mercado de las tabletas y liberó Honeycomb,

aparecieron los Fragments, orientados a apoyar diseños de interfaz de usuario más dinámicos y flexibles en las pantallas de gran tamaño, pero tremendamente útiles, además, a la hora de reutilizar componentes

ActionBar, implementada con un claro objetivo: intentar estandarizar la apariencia de las aplicaciones desarrolladas para Android.

ActionBar se convierte en el lugar desde el cual se maneja la navegación de la aplicación, dejando claro en cada momento, donde estás, de dónde vienes, y qué puedes hacer en la pantalla en la que te encuentras.

En enero del 2012 Google lanza unas guías de estilo para el desarrollo de Apps sobre ICS,

En marzo del 2011 se liberó la primera versión de la librería de compatibilidad android-support.

proporcionar a los desarrolladores una serie de bibliotecas estáticas de apoyo, de manera que puedan seguir desarrollando sus aplicaciones para una determinada versión de la API, o con compatibilidad para ésta, pero utilizando características de una versión de la API de Android superior.

6. la comunicación, ese gran desconocido por Alberto de Vega Luna

un proyecto de desarrollo software llegue o no a buen puerto: la tecnología utilizada, la experiencia del equipo, la coordinación del mismo, el trato con el cliente,… Y casi todos estos factores tienen en común una única cosa: la comunicación.

Todo el mundo tiene que saber la tecnología que se usa, en qué tiene experiencia cada miembro del equipo, qué se espera de cada uno, qué tareas quedan por hacer, las expectativas del cliente,… ¡Comunicación, comunicación, comunicación!

es bueno enviar la convocatoria con antelación para que a todo el mundo le aparezca en la agenda y la acepte o la rechace.

indicar si la asistencia es obligatoria u opcional a cada participante.

empezar a la hora acordada, pero también terminar en el momento que se había programado.

reuniones tienen que tener un objetivo

deberían tener una agenda que se haya enviado con antelación para que la gente pueda prepararse los contenidos a debatir.

invitar a aquellas personas que es imprescindible que vayan.

A veces es posible que una persona tenga que estar solo en un momento determinado para explicar o aclarar una cosa:

Tras la reunión, tiene que haber unas conclusiones y unos puntos de acción y que esté claro quién tiene que llevar a cabo esos puntos de acción y las fechas esperadas para su cumplimiento o revisión.

Lo ideal sería tener una herramienta común con una vista para los gestores (con el seguimiento de tareas, lo que falta por hacer, las prioridades, etc.) y otra vista para los desarrolladores (con el código fuente, los parches, las revisiones de código, etc.) que estuvieran relacionadas (cuando subas un trozo de código, que el bug corregido se refleje en el seguimiento de tareas) que tuviera también un repositorio de documentación asociada a las tareas.

El código fuente debe estar en un repositorio compartido con su control de versiones correspondiente,

Lo que nos ha servido para hacer ese código fuente (diagramas de arquitectura, flujos, especificaciones de requisitos, validaciones por parte de cliente, actas de reuniones, etc.) tiene que estar en un repositorio de documentación.

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 hecho un documento en concreto y hacerle cualquier pregunta que tengamos.

El correo es una mala herramienta para el debate.