Text 4 Mar 5 notes Aplicaciones Orientadas a Servicios

En la actualidad contamos con múltiples aplicaciones las cuales nos brindan servicios, tales como Twitter, Facebook, Google Apps, Amazon, entre otras. Estos servicios nos permiten a nosotros los usuarios el tener acceso a información y/o herramientas que la aplicación nos pueda brindar, permitiéndonos de esta manera interactuar con ella por medio de solicitudes específicas. Entendamos por servicio las respuestas que estas aplicaciones nos regresan mediante solicitudes HTTP (GET, PUT, POST e incluso DELETE).

Generalmente las aplicaciones que cuentan con estos llamados servicios nos permiten interactuar con ellas por medio de una Interfaz de Programación de Aplicaciones (o API). Esta API nos provee de un medio por el cuál realizar peticiones. Estas peticiones se realizan en un determinado formato el cuál la aplicación interpreta y nos regresa una respuesta, pudiendo ser esta favorable o no. Los formatos de respuesta más comunes entre las APIs en la actualidad son JSON, XML y HTML.

¿A que servicios podemos acceder por medio de una API?

Pues, en realidad los servicios a los que podemos acceder por medio de una API varían dependiendo de la finalidad de la aplicación y el nivel de seguridad (o acceso). Algunos de estos servicios van desde solicitar autorización de acceso a usuarios, información de los mismos, publicar información (en Twitter serían equivalentes a DMs o tweets), cambios de estado en perfiles, solicitudes de conexión a espacios de almacenamiento, etc.

¿Quién utiliza este tipo de servicios prestados por estas aplicaciones?

Si bien este tipo de servicios lo utiliza el publico en general, ya sea navegando por un sitio que sirve como interfaz para el servicio o por aplicaciones que hacen uso del servicio para ofrecer un producto a un usuario, son los desarrolladores de aplicaciones los que más hacen uso de estos servicios. La razón es que estos les permiten integrar la funcionalidad que el servicio les proporciona mediante peticiones específicas en sus propias implementaciones.

¿Con que finalidad se crean Aplicaciones de Orientadas a Servicios?

En realidad, estas aplicaciones fueron creadas con la finalidad de permitir la comunicación entre aplicaciones, que no necesariamente son realizadas en el mismo lenguaje de programación, por medio de un canal “estándar” definido. Estas, permiten la integración de aplicaciones muy extensas y su interoperabilidad, y al mismo tiempo les permite funcionar de manera modular e interdependiente. Esto es, que cada servicio puede ser codificado, probado y publicado sin que su aplicación afecte el desempeño o las funciones del sistema en general permitiendole incluso el estar disponible en el caso de un fallo en un servicio diferente.

Text 28 Feb 37 notes El cambio vs. prácticas inútiles

El factor principal que promueven las metodologías Ágiles es el cambio. Planteando de esta manera, dentro de nuestro ciclo de desarrollo, procesos estandarizados pero flexibles aplicables dentro del contexto particular de cada equipo. Esto promueve, de alguna manera, eliminar parcialmente la burocracia que entorpece el entregar lo que realmente tiene "valor".

Desafortunadamente, durante el proceso de eliminar la burocracia eliminamos también prácticas importantes las cuales, aunque lentas y obstrusivas, también aportan valor (a su manera).

¿A que se debe que a menudo nos deshagamos de estas prácticas que consideramos molestas e inútiles? Por mencionar algunas de ellas nos encontramos con: QA, análisis y documentación de requerimientos, documentación del software, estandarización de prácticas de desarrollo, entre otros.

En general se debe a que no aplicamos procesos efectivos los cuales nos ayuden a suplir estas prácticas tradicionales evitando el desperdicio y convirtiéndolas en valor. En realidad esta es una tarea muy complicada y requiere tanto de una dirección eficaz como de un equipo de desarrollo propositivo, inquisitivo y autodirigido (casi nada ¿cierto?).

Debemos decir, entonces, que el “cambio” que promueven las prácticas ágiles es la transformación de nuestras prácticas en una “cultura de desarrollo”. Lo que sería igual a volver efectivas y eficaces nuestras prácticas transformándolas en valor. Siendo promovidas por la dirección y evolucionadas por nuestra fuerza de primera línea (o equipo de desarrollo) en función de su aplicación.

Quote 24 Feb
Un ciclo de de desarrollo saludable
— MGalv, 2011
Text 23 Feb 5 notes El poder de no ser técnico

Muchas veces nos encontramos en nuestra profeción (como developers, no sean mal pensados) con personas muy interesantes sin conocimientos técnicos, las cuales tienen una necesidad a ser cubierta.

Estas personas nos buscan a nosotros (personas con conocimientos técnicos) para desarrollar su idea e implementar las soluciones.

Como es de esperarse cuando el ying y el yang se juntan existen barreras comunicacionales las cuáles son dificiles de romper entre estos dos tipos de personas. Tanto es así que las personas no técnicas encuentran díficil hacerle saber su necesidades a las otras. Por lo tanto, las fallas en la comunicacióny la malinterpretación de soluciones llevan al fracaso a muchas ideas.

Para solventar estas malinterpretaciones en la comunicación existen algunas herramientas “técnicas” que las personas sin conocimiento técnico pueden utilizar para expresar una idea o funcionalidad sobre su solución. Estas aplicaciones nos sirven a  nosotros las personas técnicas para comprender el flujo que debemos considerar al momento de desarrollar estas soluciones.

¿Pero, cuáles son estas herramientas “mágicas” de las que hablamos? Pues son simplemente aplicaciones de Desarrollo Guiado por Pruebas (mejor conocidas como BDD). Y la razón por la que una persona no técnica puede hacer uso de este tipo de herramientas es que permiten guiar el flujo del desarrollo enfocandose en que la funcionalidad cumpla con los requisitos reales del solicitante sin tener la necesidad de conocer las tripas de la aplicación (o código).

Herramientas como Cucumber le permiten a cualquier persona no técnica el poder crear una prueba descriptiva sobre una funcionalidad reuniendo los requisitos minimos para que su ejecución sea exitosa, y esto es tan simple como escribir algo como esto:

Feature: Tacos for paisas
  In order to get fat
  As a starving paisa
  I want to eat tacos at the taco truck

  Scenario: Eat a taco
    Given I am starving
    And I go to the taco truck
    When I ask for a taco
    Then the taquero has to give me my taco
    And I can eat it

Esto describe de manera detallada, sin entrar enla parte técnica, el flujo de una actividad, la cuá puede ser traducida por una persona técnica en código y funcionalidad. Dandole las necesidades básicas a cubrir para considerar como realizada una actividad.

Por lo tanto, si eres una de esas personas no técnicas y quieres describir lo que realmente necesitas una recomendación es que propongas tus escenarios y describas el flujo. Las pruebas de comportamiento las defines tú.

Text 23 Feb 5 notes Prueba, falla, codifica, pasa, refactoriza

Como todo guerrero, nosotros los desarrolladores estamos acostumbrados a forjarnos en en fragor de la batalla. Sufrimos cada bug, gozamos cada reto, nos extaciamos con cada funcionalidad marcada como terminada! Y conforme avanzamos y mejoramos nos vamos llenando de cicatices de guerra, historias de victorias y derrotas. Al final, esto es lo que forma nuestro caracter ¿Cierto?

Pues en cierto modo esto es verdad. Sin embargo, al igual que los guerreros estamos expuestos a las mismas vulnerabilidades. Habilidad, fuerza, inteligencia, destreza se ven mitigadas cuando azotamos nosotros mismos contra las fortalezas a las que nos enfrentamos. No vemos mermados de a poco cuando con el avance de la batalla se merman nuestras proviciones.

¿Esto a que se debe? ¿No somos lo sufientemente fieros? ¿No provocamos ninguna baja en el enemigo? ¿No estamos suficientemente motivados? ¡De ninguna manera!

¡Nuestro problema es la estrategia!

Como guerreros que somos marchamos rumbo al campo de batalla sin una estrtegia definida, sin saber como concluir nuestro objetivo. Esto, traducido a nuestra area se refiere a que nuestro ciclo de desarrollo se basa en un sistema de aciertos y errores, o lo que es lo mismo, omitimos las pruebas.

Es verdad que somos guerreros, mas sin embargo, un guerrero sin estrategia de batalla es lo mismo que llebar al frente una cuchara para atacar a un ejercito.

¿Que podemos hacer para fortalecer esta debilidad? Es simple: prueba, falla, codifica, pasa y refactoriza

Esto, no solo nos prové de una estrategia, sino que a su vez nos sirve como escudo para cuando el enemigo cambia la suya. Nos permite cambiar de dirección sin olvidarnos de donde venimos.

Sigamos siendo los guerreros que somos, más convirtamonos también en estrategas y conquistadores. Un guerrero no es recordado por sus batallas, sino por aquellas batallas en las que se hizo recordar.

Text 22 Feb 1 note Pair Programming

Después de varios meses de no tocar código, sin intenciones serias, me tocó la suerte de pertenecer a un grán equipo con un muy divertido proyecto el cuál representa un grán desafío en muchos aspectos.

Con este nuevo proyecto he aprendido y puesto en práctica muchas de las teorías que había estado másticando por más de un año. Vaya que es diferente de como las recordaba de libros y blogs. La mayoría de ellas son bastante interesantes y provocan un cambio de perspectiva desde el inicio mas la que principalmente me ha llamado la atención debido al reto que supone es el Pair Programing (o Programación en Pares).

El Pair Programing es una dinámica de trabajo en la cual una pareja de desarrolladores desempeñan sus actividades en un mismo equipo de computo, al cuál se le ha provisto de un par de teclados y ratones. Estos desarroladores tienen que interactuar entre sí para poder generar soluciones a las solicitudes de la aplicación o proyecto en el cuál estén trabajando.

Esta práctica podría suponer un desperdicio de manos y ojos debido a que dos personas se encuentran enfocadas en una misma tarea. Sin embargo, esto no sucede así. El que dos personas centren su conocimiento en una solución les permite generar mejores resultados debido a que entre ellos: generan feedback inmediato, implementa cada uno sus mejores prácticas, se pierden factores de distracción externos al depender el uno del otro en la realización de la actividad, comparten conocimiento y mejora la relación de equipo. Suena genial, no es cierto?

Hay que entender que con esta práctica también vienen algunas contrapartes, como puede ser el que: los integrantes de la dupla no cuenten con el mismo nivel de conocimento, o que no siempre se tenga una pareja para poder llebar a cavo la actividad, e incluso tal vez que alguno de los dos tome una actitud de mando en el equipo. Pero, esto no tiene por que venir a mal tampoco, ya que podemos aprovechar también este tipo de situaciones para mejorar la situacion general de nuestros integrantes del equipo y ponernos a todos en un mismo nivel.

Los invito a evaluar esta técnica de desarrollo. Se comprende que pueda ser atemorizante el ser evaluado constantemente mientras se realiza una actividad, pero con el tiempo, esto mejora nuestro desempeño y beneficia el trabajo en equipo.

Text 22 Feb LiveSessions

Un buen amigo me dijo una vez “si quieres de verdad aprender, debes enseñar” y como a mi me gusta aprender, pueeees.

Las LiveSession son una gran iniciativa que comenzó hace poco más de un año. Se trata de pequeñas presentaciones en donde el expositor demuestra un poco de lo que hace en el día a día de un desarrollador. Esto pueden ser “Best Practices”, metodologías, técnicas de desarrollo de aplicaciones, alguna aplicación interesante, nuevos lenguajes, o simplemente su “Development way”. A mi en lo párticular me gusta mucho ser participe de estas pláticas.

Recientemente tuvimos la idea, genial o no, de hacer una grabación de las mismas por lo cuál próximamante les pondré algunos de los videos disponibles aquí. Les recomiendo ustedes mismos pongan en práctica iniciativas como estas. De seguro se divierten un rato, y de paso hasta aprenden.

Text 22 Feb Hola mundo

En ratos de ociosidad estaré posteando algunos tips rápidos y otros no tanto sobre el día a día de un Ruby Developer.

No sé si sean interesantes, pero por lo menos divertidos si.

Me estaré reportando durante mi próximo pomodoro time!


Design crafted by Prashanth Kamalakanthan. Powered by Tumblr.