Eventos en backbonejs

Posted: enero 2nd, 2016 | Author: | Filed under: Sin categoría | Tags: , , , | No Comments »

Una de las formas más interesantes de desacoplar código, vistas fundamentalmente, usando un framework MV* tipo backbone es aprender a usar correctamente los eventos y patrones asociados. Observer (pub/sub), Event Aggregator, Mediator, …

La mejor lectura al respecto que he encontrado es este post de Derick Bailey (creador de MarionetteJS), donde de forma muy ilustrativa examina distintas opciones finalizando con como hacerlo con eventos. Es recomendable también leer los comentarios, donde Derick responde a varias dudas de los lectores.

La sección sobre Eventos de Developing Backbone Applications explica bien como usar los eventos en general en backbone y esta otra sección revisita el post de Derick exponiendo la diferencia entre Event Aggregator y Mediator.

Pero para trabajar con Eventos de forma correcta además de los patrones y las especifidades de backbone es necesario conocer algunas técnicas y características de javascript relacionadas con el contexto. La siguiente selección de artículos puede ahorrarte un par de horas de quebraderos de cabeza:


Libro: Developing Backbone.js Applications

Posted: diciembre 28th, 2015 | Author: | Filed under: Sin categoría | Tags: , , , , | No Comments »

He terminado de releer estos días Developing Backbone.js Applications, escrito fundamentalmente por Addy Osmani con la colaboración de más gente vía pull-requests en github. Los primeros capítulos del libro (Introduction, Fundamentals, Basics) se leen muy rápido y dan una buena idea, no sólo de como usar backbone si no de porqué usar un framework MVC.

La idea de mezclar el uso concreto de la herramienta con explicaciones de más alto nivel de patrones se produce a lo largo de más capítulos del libro, por lo que uses backbone o no lo que aprendas te seguirá sirviendo. Esto creo que es el principal aliciente del libro, ya seas un programador novato e inexperto en backbone, o no, puedes aprovechar las explicaciones sobre patrones MV*, Mediator vs Event Aggregator, Desarrollo Modular, …

Otra de las cosas que me gusta del libro y que es muchas veces ignorada es que dedica un capítulo entero a testing. Tal vez demasiado centrado en explicar distintas herramientas (Jasmine, QUnit, Sinon) pero aún así d utilidad.

Algunos otros capítulos me dan la impresión de ser demasiado específicos, como aquellos dedicados a desarrollo para móviles y a otros frameworks construidos sobre backbone como Marionotte y Thorax. El capítulo sobre herramientas por ejemplo también es muy específico y al ritmo al que evolucionan en estos momentos ya se ha quedado desactualizado.

Salvando eso, creo que sigue siendo un libro muy recomendable.


¿Es “decrecimiento” una buena palabra?

Posted: diciembre 5th, 2015 | Author: | Filed under: Sin categoría | Tags: , , , | No Comments »

Aunque puedo coincidir con algunas de sus ideas la palabra “Decrecimiento” me pone nervioso. Por eso el artículo de Kate Raworth en el blog de Duncan Green explicando algunos de los motivos por los que Decrecimiento es una mala palabra creo es digno de ser leído. Este otro post, con el que no concuerdo, es una respuesta al artículo original.

No dejéis de leer los comentarios y fijaros en la encuesta, en este momento la opción “buena idea, buena palabra” tienen 117 votos, “buena idea, mala palabra” 76 votos y “no una buena idea” tiene 41 votos. Es decir que aún sumando las dos últimas opciones el resultado está empatado. En cambio, la mayoría de comentarios, son críticos con la palabra.

Siendo un pelín malvado parece que a los fans del decrecimiento les va más la adhesión a la idea que a presentar argumentos a su favor.


El sol, la tierra la luna y animaciones con css3

Posted: noviembre 21st, 2015 | Author: | Filed under: Sin categoría | Tags: , , | No Comments »

Hace algún tiempo vi un ejemplo brutal de como usar únicamente html5 y css3 para hacer una “representación” del sistema solar.

Viendo que estaba como uno de los proyectos de codeacademy hice una pequeña prueba que comparto. La diferencia fundamental con el de code academy es que en lugar de usar imágenes para representar a los planetas uso div con background-color y que he añadido la luna para poder jugar un poco con las animaciones “anidadas”. Que fundamentalmente es un problema de posicionamiento css.


Aquí el resultado.

Hay otros experimentos muy chulos en esta línea como este que trata de reproducir el primer experimento usando un html más semántico. O este otro clon del primero donde también modifica la estructura del html usando div todos al mismo nivel de anidamiento. Este otro también sigue la idea del primero pero añade cosas chulas como usar funciones css para posicionar las estrellas de fondo en localizaciones aleatorias.

Y por último, uno que a pesar de incluir algo de javascript (para los controles) es capaz de reproducir el sistema solar en 3D.


Aitor Guevara hablando de la arquitectura de Ducksboard

Posted: septiembre 26th, 2015 | Author: | Filed under: Sin categoría | Tags: , , , , | No Comments »

Un vídeo algo antiguo (2013) en el que Aitor Guevara (CTO de Ducksboard) nos habla de cual era la arquitectura de Ducksboard en aquel momento. A pesar de que el vídeo dura más de una hora y media Aitor consigue hacer amena una charla técnica. No entra al mínimo detalle técnico pero si da una buena idea general. Responde sin rubor a preguntas como cual era el costo de la infraestructura que tenían en Linode (400$) o cuantos clientes de pago tienen.

Por el medio de la charla caen perlas del estilo de:

  • Usamos twisted para hacer aplicaciones asíncronas en python. ¿Conoceis nodejs? pues lo mismo pero tiene 10 años en lugar de 1.
  • Usamos backbone, porque tenemos un montón de javascript. Tenemos un montón no porque nos guste si no porque es lo que hay.

Otra de las cosas que más me gustan es la defensa que hace de PostgreSQL, que es el componente central de su infraestructura (especialmente hacia el minuto 50 pero en realidad lo hace en varios momentos). Hacia el minuto 44 explica como usan ellos backbone. La verdad es que aquí no me quedo muy claro desde donde servían el html, o si iba todo en los templates, porque el django del frontend en principio sólo actuaba como API Rest sirviendo JSON al navegador. Eso si, su django usa SQLAlchemy y no django-orm porque tenían cosas en el postgres que django-orm no soporta.

Los últimos minutos de la charla presenta un par de herramientas que “análisis del negocio” que también son de interés.

En este post además del vídeo están las transparencias.


Un sistema como otro cualquiera para recuperar tus contactos en un Android con la pantalla rota

Posted: septiembre 23rd, 2015 | Author: | Filed under: Sin categoría | Tags: , , , , , | No Comments »

Uno de esos días cualquiera en que te llega alguien (a quien no puedes mandar a freír puñetas buscar en google) que una semana después de comprarse su primer móvil con Android se le ha caído al suelo, se le ha roto la pantalla y quiere recuperar sus contactos.

La primera respuesta es fácil. No hay problema, estarán en la memoria de la tarjeta, o sincronizados en la cuenta de google. Pero no, ni uno ni otro. Están en la memoria del teléfono.

Las primeras búsquedas en google se refieren a sistemas que necesitan que el teléfono esté rooteado para por ejemplo copiar la base de datos (sqlite) con los contactos. Teniendo el sqlite es fácil sacar un csv o al menos un listado que copiar a mano. Pero por supuesto el teléfono no está rooteado.

Bueno, la pantalla no está del todo muerta, la parte de arriba responde. Así que igual da para hacer pulsar en los sitios clave. El teléfono en sí no puede desbloquearse, pero si se puede llegar al botón de “Ajustes“, porque no tiene activado la protección por figura. Jugando con la rotación automática para modificar los sitios a pulsar, podemos llegar de “Ajustes” a “Aplicaciones“, de ahí a la pestaña de “Todas” y desplazarnos hasta “Contactos“. Muchas de las apps, como la “Contactos” tienen un botón “Lanzar” equivalente a como si las abrieras desde el Launcher.

Estando en la app de Contactos sólo hay que poder lanzar la opción de “Exportar“, pero en este teléfono ese menú se lanza desde la tecla de “Menu” que no responde. Teóricamente con el conector adecuado, podríamos conectar un ratón al teléfono para controlarlo, pero a falta de conector resulta que es posible enviar eventos (como pulsaciones de teclas) al móvil a través de adb.

“Pulsamos” la tecla de menú:

$ ./adb shell input keyevent 82

Y un par de veces KEYCODE_DPAD_DOWN que actúa como el curso hacia abajo

$ ./adb shell input keyevent 20

Y enviamos el evento KEYCODE_DPAD_CENTER para hacer click / pulsar / tap sobre la opción seleccionada

$ ./adb shell input keyevent 23

Y ya tenemos lanzada la la aplicación de exportación. Siguiendo un proceso parecido de ver en que partes de la pantalla de puede pulsar y enviando eventos desde adb, seleccionamos como origen el smartphone, como destino la cuenta de gmail. Y listo. En un par de minutos tenemos los contactos en gmail, desde donde podemos exportarlos a csv, vcard o listos para ser usados desde otro teléfono android.

Espero que a alguien le sea de ayuda. Se admiten otros modos de hacerlo en los comentarios.


Video: Aplicaciones en tiempo real con python y postgres

Posted: agosto 25th, 2015 | Author: | Filed under: Sin categoría | Tags: , , , , , , , | No Comments »

Una charla de como montar aplicaciones en tiempo real con python y postgres. Tiempo real entendido como notificaciones de un chat, hacer algo cada vez que se actulice una tabla de la bd etc,…

El vídeo se hace un poco largo, seguramente con las transparencias llegaba para hacerse una idea general. Pero aún así se hace interesante por alguna de las técnicas que emplea:

  • Aboga por no usar frameworks en python. Con las librerías de hoy en día es sencillo montar una API Rest gestionando las llamadas de bajo nivel directamente
  • Usa las funciones de postgres de LISTEN y NOTIFY que combinadas con un trigger permiten que código cliente (psycopg2) sean notificados cuando algo pasa en la base de datos (se modifica una fila o lo que sea) y actuén en consecuencia (provocar un cambio en el navegador mediante websockets)
  • Para simplificar la API y el diseño de la bd, los datos se guardan como tipos nativos postgres (varchar, boolean,…), y se usa la función de postgres row_to_json para recuperarlos una cadena de texto con formato json.
  • Usa httpie para probar la API Rest. Si alguna vez usaste curl para esto enseguida verás que está bien conocer httpie.
  • A pesar de que la idea principal de la charla es montar una aplicación en tiempo real con el mínimo número de dependencias (complejidad) el proceso de build que monta no parece trivial. pip para dependencias en python, nodeenv (una especie de entorno virtual para node que se integra con el virtualenv de python), bower para las dependencias javascript de cliente,… Todo ello orquestrado por un Makefile.
  • No muestra como hacer la parte del frontend, pero en todo caso el código está en su repo

Comentarios al artículo de Complejidad y Reversibilidad de Kent Beck

Posted: agosto 9th, 2015 | Author: | Filed under: Sin categoría | Tags: , , | No Comments »

Andrés me pincha para que lea y comente el último post de Kent Beck en su muro de facebook. Como todo lo que escribe Beck hay que leerlo con atención y se pueden sacar lecciones interesantes. Pero este artículo en particular se me hace complicado de leer porque creo que mezcla demasiadas cosas a la vez. Comienza con una teoría general sobre sistemas complejos y luego salta a prácticas concretas de facebook para atajarla en distintos estadios del desarrollo sin pararse a explicar que técnicas tienen sentido en según que contextos. Analicémoslo por tanto atendiendo al artículo como dos partes separadas.

Complejidad y Software

Software complexity es un término con definición propia en el mundo académico. En la práctica todo desarrollador tiene una noción intuitiva de que es complejidad y debería tener como principio el atajarla. Beck explica alguno de los elementos de la complejidad y cuales de ellos se puede intentar mantener bajo control en un producto como facebook. La cuestión es, si en otro tipo de productos software se puede o tiene más sentido atacar otro frente distintos al de la irreversibilidad. Personalmente se escapa de mis conocimientos esta reflexión pero apunto algunos elementos para el debate:

  • Estados. Atendiendo al producto como un todo (hardware, acciones del usuario, red,..) seguramente será difícil de atajar. Si nos quedamos con las acciones (interacción) del usuario me recuerda a la diferenciación entre mapa y camino de la que se reapropió Andrés atendidendo a Verplank.
  • Interdependencias. SOLID, KIS, Patrones, Modularidad o cualquier práctica de buen diseño entiendo que ayuda a disminuirla a no ser que se me escape algo.
  • Incertidumbre. Supongo que es el más complicado. Usuarios usando la aplicación en formas no previstas. Requisitos cambiantes,…
  • Irreversibilidad. Nada que decir, es en el que se centra Beck.

Atajar la Irreversibilidad

La segunda parte del artículo habla de algunas de las técnicas que usan en Facebook para combatirla. Algunas pueden ser consideradas de modernas como el Frequent Pushes (¿Continuous Delivery?) y otras como el Code Review llevan con nosotros mucho tiempo. Beck las enumera todas juntas pero creo que intentar ponerlas bajo una clasificación más o menos habitual en factorías de software tradicionales puede ayudar a decidir cuales pueden ser aplicables en cada caso. Dejo fuera (IRC y Data-informed decisions)

  • Desarrollo
    • Development servers
    • Code review
    • Correlation
  • Pre-Producción / Testing
    • Internal usage
    • Staged rollout
    • Advance countries
    • Shadow production
  • Producción
    • Frequent pushes
    • Soft launches
    • Dynamic configuration
    • Right hand side units
    • Double write/bulk migrate/double read

Sin duda algunas de las técnicas como Staged Rollout es discutible en que fase van y son clasificables bajo esta óptica. La idea de intentar clasificarlas es sólo para poder compararlas con una forma de trabajo que nos resulte más cercana para a partir de ahí ver cuales podemos empezar a aplicar y en que punto de nuestro proceso.

Qué puedo aplicar y cómo si no soy Facebook

Más que técnicas concretas en realidad lo que Beck plantea es una cultura (o dos). El Desarrollo Ágil y el DevOp. Intentar aplicar alguna de sus estrategias de forma separada sin abrazar la filosofía subyacente creo que sólo produce desgaste. Con esto no quiero decir que tengas que hacer pair programming y tener un devop en tu equipo, pero sí al menos comprender que hay valor en los principio que proponen.

Para mi los pasos en ese camino son tres: Tests, Automatización y Monitorización.

Monitorización. Si no estás midiendo lo que sucede rendimiento, comportamiento de usuarios, … saber lo que está pasando o cuando un cambio no tiene el efecto previsto.

Automatización. Si hacer un despliegue es costoso e implica varios pasos, se harán pocos , se tardará más tiempo en tener feedback, se introducen más posibilidades de error y no hablemos de lo que supone revertir un mal cambio. Si no se automatizan los procesos se vuelve más complicado que todos los desarrolladores tengan el mismo entorno y este sea parecido a producción.

Tests. Probablemente la piedra angular. Estoy leyendo Working Effectively with Legacy Code, y en los primeros capítulos expone algunas cuestiones sobre tests que tienen relevancia para la “reversibilidad”. En el libro comparan trabajar sin tests a hacer acrobacias sin red, y expone dos formas de introducir cambios en un sistema.

Changes in a system can be made in two primary ways. I like to call them Edit and Pray and Cover and Modify. Unfortunately, Edit and Pray is pretty much the industry standard. When you use Edit and Pray, you carefully plan the changes you are going to make, you make sure that you understand the code you are going to modify, and then you start to make the changes. When you’re done, you run the system to see if the change was enabled, and then you poke around further to make sure that you didn’t break anything. The poking around is essential. When you make your changes, you are hoping and praying that you’ll get them right, and you take extra time when you are done to make sure that you did.
Superficially, Edit and Pray seems like “working with care,” a very professional thing to do. The “care” that you take is right there at the forefront, and you expend extra care when the changes are very invasive because much more can go wrong. But safety isn’t solely a function of care. I don’t think any of us would choose a surgeon who operated with a butter knife just because he worked with care. Effective software change, like effective surgery, really involves deeper skills. Working with care doesn’t do much for you if you don’t use the right tools and techniques.
Cover and Modify is a different way of making changes. The idea behind it is that it is possible to work with a safety net when we change software. The safety net we use isn’t something that we put underneath our tables to catch us if we fall out of our chairs. Instead, it’s kind of like a cloak that we put over code we are working on to make sure that bad changes don’t leak out and infect the rest of our software. Covering software means covering it with tests. When we have a good set of tests around a piece of code, we can make changes and find out very quickly whether the effects were good or bad. We still apply the same care, but with the feedback we get, we are able to make changes more carefully.

En esencia, durante el desarrollo tener tests te permite probar y si no funciona revertir a coste casi cero. En producción el coste de revertir no es cero (al menos sin aplicar otras de las técnicas mencionadas) pero al menos te permite detectar errores de forma temprana.

 

 

 

 


Libro: Ready Player One

Posted: agosto 8th, 2015 | Author: | Filed under: Sin categoría | Tags: , , | 2 Comments »

Ready Player One es sobre todo una buena lectura ligera para el verano. En un mundo futurista donde la energía resulta un bien escaso y grandes cantidades de población viven empobrecidas la única diversión, fuente de trabajo y vía de escape es OASIS. Una versión a lo grande de Second Life a la que los usuarios se conectan mediante aparatos de realidad virtual. En OASIS no importa quien seas o como seas, tu Avatar es lo que te representa. La historia cuenta como el protagonista del libro intenta resolver el reto planteado por el creador de OASIS a su muerte y quien lo consiga herederá su fortuna.

 

El libro es una mezcla ligera de ficción ciberpunk con corporaciones tratando de resolver la búsqueda (no leas demasiado del enlace hay spoilers) y misiones al más puro estilo Dungeons & Dragons por el medio del mundo virtual.

 

Si te gustan películas ochenteras como Lady Halcon o los Goonies, eres geek/freak, jugaste al rol o estás enganchado a los MMORPG este libro te encantará.

 

Puedes comprarlo en amazon y también hay gente que lo comparte.


Portátiles entre 600 y 700€ para CAD y Diseño

Posted: agosto 8th, 2015 | Author: | Filed under: Sin categoría | Tags: , , | No Comments »

Estos días un amigo me pidió ayuda para comprar un ordenador. Los requisitos:

  • Ofimática, CAD y Diseño sin grandes necesidades
  • Entre 600€ y 700€
  • Pantalla de 15.6”

Échando un ojo a lo que había en el mercado empecé a hacer una hoja de cálculo. Descarté todas los que tuvieran una gráfica peor que una 820M y un micro peor que un i5-4210 porque son configuraciones habituales en ese rango de precios. Luego comparando precios, características y preferencias personales llegamos a esta lista.

Están separados dos rangos de precios los que están más cerca de 600 y los que están más cerca de 700, con mis preferencias resaltadas en amarillo. Si alguién está buscando un portátil así espero que le sirva. El hecho de hacer la hoja de cálculo ya lleva un buen rato, igual hay espacio aquí para hacer un scrapper. ¿Algún programador en la sala :P?