Carat
Debugging de energía colaborativa
Desde el feed de i.MicroSiervos me llega la noticia de Carat, un sistema que nos aconseja sobre maneras para hacer que nuestro dispositivo móvil haga mejor uso de su batería y dure más.
Está disponible tanto para Android como para iOS, y lo más curioso es que la fuente de información es puramente colaborativa. Es el mismo uso de los dispositivos que sirve como fuente de información para identificar las características que insumen más batería para que de esa forma se pueda desrecomendar su uso a quienes no la utilizan activamente. De esta forma, mientras más uso se haga de la aplicación, más información habrá para utilizar.
La versión de iPhone no está tan preparada en cuanto a interfaz gráfica, pero es totalmente funcional y ya está dando buenos consejos sobre cómo mejorar la calidad de vida de nuestra batería (y nuestro battery-lifecycle). La de Android se ve más bonita en cuanto a interfaz y la funcionalidad es básicamente la misma que la de iPhone.
Este sistema está desarrollado por el AMP Lab (Algorithms, Machines and People Laboratory) de la Universidad de Berkeley, en un pequeño grupo de cinco personas. Sin embargo, el proyecto es open source y se puede encontrar en GitHub, para hacer un fork y ayudar a trabajar sobre él.
Soy un zorrinito ahorrador.
Blockly
Un lenguaje de programación visual
Blockly es una apuesta de Google para enseñar programación desde los bloques más básicos con esa misma aproximación: bloques.
Gracias a la novedad visual (y la autogeneración de código que ocurre por detrás) se puede programar fácilmente con encajar piezas de rompecabezas, de forma muy intuitiva. Lo que nos demuestra es que se ahorraron la complejidad de la sintaxis de un sistema reemplazándola por un rompecabezas, que vuelve el conocimiento de sintaxis en un juego.
Existen tres demos para Blockly actualmente:
- Maze, nos impone el desafío de resolver un laberinto con instrucciones simples
- Code, nos permite ver un poco detrás de la cortina y observar como Blockly puede generar código en otros lenguajes.
- RTL es un demo de cómo se vería la interfaz de derecha a izquierda.
Parecería por estas características no se trata sólo de un intento de educación, sino también la capacidad de extender aplicaciones propias de una forma visual y fácil de comprender. Imaginen permitirle a los usuarios de un sistema “programar” cómo debe comportarse el sistema en determinados casos. Realmente es una opción muy poderosa de extensibilidad, sin requerir la complejidad de saber programar.
Soy un zorrinito en bloques.
on{X}
Automatizando nuestra vida, un teléfono a la vez
De parte de MicroSiervos me entero que Microsoft está desarrollando un sistema de macros basadas en eventos para teléfonos móbiles. El proyecto se llama on{X} y aquellos que conozcan IfTTT verán una gran similaridad.
El sistema se basa en eventos porque los macros se disparan según determinadas situaciones se presenten. Ver las recetas pre-armadas ya les dará una idea:
- Lanzar la aplicación de música cuando estoy caminando.
- Cuando llegue a casa, recuérdame comprar leche.
- Recuérdame ir al gimnasio si no he ido por 3 días.
- Enviar el mensaje “voy para allá” a mi esposa cuando salgo del trabajo.
- Cuando mi novio me pregunta “dónde?”, responder automáticamente con mi localización.
Como esas, se pueden hacer muchas, ya que el código detrás de ella es simple JavaScript, lo que permitirá que una gran comunidad comience a construir sobre ellas. En este momento solo funciona para teléfonos Android (Microsoft, really?) pero esperemos que pronto se extienda el soporte. Todavía la comunidad en los foros y el blog están algo vacíos, pero nuevamente, es algo muy reciente todavía.
Yo realmente pienso que esta idea puede despegar.
Soy un zorrinito automatizado.
La belleza entra por los ojos
Una historia real
Una muy bonita anécdota que tenemos para contar cómo nuestro trabajo en User Experience comienza a dar sus frutos es una historia que a César le gusta contar, específicamente por la fuerza que esta historia tiene.
La historia comienza con MakingSense trabajando en una propuesta para un cliente nuevo. Siendo nuevos en nuestras tratativas con esta empresa (una empresa con altos estándares de seguridad), queremos realmente mostrar lo mejor que tenemos. La aplicación que debíamos realizar era desafiante desde el concepto que trataba, porque involucraba mucha seguridad, muchas tecnologías nuevas y muchas características que ayudan al usuario pero hacen difícil de congeniar con las anteriormente mencionadas. Nuestros arquitectos trabajaron en resolver ese problema pero las propuestas siempre resultaron más concretas cuando se puede ver el resultado final.
Entonces también se invirtió mucho en la zona de User Experience de esta propuesta. Sabrán ustedes que estamos haciendo presión sobre este tema últimamente (y si andan leyendo por aquí, seguramente lo habrán notado). Creemos que el UX es un factor de valor agregado, creemos que cuando todo lo demás está bien hecho, este marca una diferencia increíble.
De vuelta en la historia, el equipo de MakingSense trabajó en hacer un buen pre-diseño de user experience, lo que involucraba el desarrollo de flujos de usuario, screenshots de cómo podría llegar a verse el producto, muchos mockups y pequeños prototipos que nunca vieron la luz, pruebas de concepto, etc. Cuando uno trabaja para un proyecto que no es proyecto aún, sabe que está en riesgo. Sabe que si no se concreta la oportunidad, fue tiempo y dinero perdido.
El día de la propuesta se acercaba y las gotitas de sudor iban siendo más comunes en la frente de los involucrados. Se hizo muchisimo hincapié en esos screenshots, se cuidó hasta el ultimo detalle, se hicieron varias rondas del desarrollo del UI (interaction design, wireframes, IA) hasta llegar al diseño final con el que se estaba listo para presentar.
Finalmente, el día llegó.
César asistió a esa reunión en donde nos presentábamos de manera formal con nuestro cliente (aunque ya había habido tratativas informales anteriormente) y pusimos el proyecto sobre la mesa. Se explicó por qué MakingSense era apropiado para hacer el proyecto, se explicó qué teníamos en mente para solucionar su problema, y se mostraban algunas pantallas que ejemplificaban cómo podría haber quedado el sistema terminado.
En ese momento de la reunión la tensión subió. El arquitecto que pertenecía al cliente interrumpió la conversación, dijo “Esperen”, y se fue de la habitación. En menos de dos minutos estaba de vuelta con alguien más, y lo presentó como el CEO de la empresa.
“Quiero que él vea lo que ustedes pensaron”, nos explicó. “Estas pantallas son más de lo que teníamos en mente, definitivamente queremos que esto se vea así, y que de ahora en adelante, todo lo que hagamos sea así.”
Traduciendo la experiencia, ellos sabían lo que querían que el sistema haga. No sabían la diferencia que se podía hacer con UX, no sabían que se podía brindar una experiencia totalmente nueva y agradable, especialmente cuando los sistemas tienen muchos requerimientos de seguridad, o cuando la complejidad son los árboles que no dejan ver el bosque.
La propuesta se convirtió en proyecto y el cliente se convirtió en partner, y hemos trabajado juntos para lograr maravillosos productos.
Naturaleza y ciencias
Sobre el punto en donde dos mundos se tocan
¿Puede la naturaleza ser un modelo de cómo resolver problemas de las ciencias? La pregunta tiene una respuesta obvia. Sabemos que sí, sabemos que muchos procesos pueden copiarse desde la naturaleza para mejorar la forma en la que resolvemos determinados problemas. Desafortunadamente, muchas veces, determinadas áreas de las ciencias quedan fuera porque la relación con el mundo natural está algo alejado. Por ejemplo, las ciencias de la computación o la aritmética.
Sin embargo, hay gente que sabe ver ese tipo de relaciones. Por ejemplo, el caso de micahoover, quién se preguntaba qué algoritmo de búsqueda realizan los relámpagos al caer. Y parecería que, curiosamente, es una búsqueda de tipo simulación Monte Carlo (Monte Carlo Search: A New Framework for Game UI [PDF]).
O el caso de Vihart, quien tiene una serie de videos hablando sobre Doodling in Math: Spirals, Fibonacci and Being a Plant (Part 1, Part 2, Part 3), en donde nos cuenta, desde el punto de vista de una planta, cómo maximizar el consumo de luz solar sin que nuestras hojas nos tapen otras hojas y cómo la serie de Fibonacci y las espirales son la forma de lograrlo.
Estos son dos ejemplos de muchos otros que deben haber ahí afuera (los invito a contarme de más si los conocen)
Soy un zorrinito natural.
The Noun Project
Iconos minimalistas para todas las ocasiones
The Noun Project es una colección de iconos minimalistas, la gran mayoría libres para usar. Cada imagen tiene asociada un sustantivo que lo describe, y por lo general la imagen es una buena representación de esa palabra. Disponible tanto en inglés como en español para buscar, esta galería de imágenes nos permite inspirarnos como diseñadores y conseguir una buena cantidad de iconos para nuestros sistemas de necesitarlos.
También existe una visualización por categorías que nos permite interiorizarnos en alguna de ellas en particular, que puede estar asociada a nuestra necesidad.
Soy un zorrinito iconizado.
Front-end code standards
Una aproximación de best practices
Acabo de leer el artículo de IsoBar Front-end Code Standards & Best Practices. El artículo cubre de forma extensiva varias de las tecnologías utilizadas, con las sugerencias que esta empresa utiliza interamente. Cubre varios aspectos del uso de HTML (y algunas nuevas características de HTML5), CSS (y algunas nuevas características de CSS3), JavaScript, Performance, e integración cross-browser.
Personalmente no me siento de acuerdo con la totalidad de los items mencionados, pero creo que como punto de partida es muy bueno. Tienen una buena cantidad de referencias al por qué conviene hacer las cosas de la forma que ahí están explicadas, y muchas veces las razones son totalmente válidas. Muchas veces también se pesan pros y contras de cada aproximación, lo cual ayuda a tomar una decisión educada del proceso que elijamos seguir.
Soy un zorrinito front-end.
Pruebas con VS11: Día dos
async y await
Continuando con mi serie de posts e investigación sobre lo que VS11 ofrece (Parte 1), quisiera tomar una aproximación separada. Si bien la exploración es interesante, es poco apropiada cuando uno quiere aprovechar el tiempo.
Es por eso que comencé con las referencias en MSDN sobre qué hay de nuevo en VS11, que seguiremos de a partes. Pero a la vez quiero cumplir con mi promesa, por lo cual, si comenzamos sobre qué hay de nuevo en el lenguaje C# (lo siento VB, lo siento C++, soy del bando de C#), nos encontramos con la excusa para cumplir lo prometido.
Características nuevas de C#: await y async
Esto, bien sabemos, no es algo propio de VS11, sino de C# 5.0, que va de la mano con VS11 y .NET 4.5. Como MSDN lo indica, una de las primeras características es la habilidad de construir fácilmente código asíncrono. “We have to go deeper…“
Cabe aclarar que ya existía la posibilidad de escribir código asíncrono. Los callbacks y el multithreading no es nada nuevo, aunque esto es ligeramente distinto, ya que simplifican un poco la idea y esconden el trabajo sucio. Sin duda se logrará que en el futuro mucha gente no sepa cómo funciona los métodos asíncronos por detrás pero esconder complejidad es un buen paso para permitir innovación.
Digamos que tenemos un programa que factoriza números grandes, porque logramos un trabajo de criptoanalista para el FBI. Nuestro método recibe un parámetro long y nos devuelve un ISet<long> con el conjunto de factores primos que conforman este número original. Dejando de lado la matemática, sabemos que este proceso toma un rato en ejecutarse y queremos que nuestro programa lo trate de forma asíncrona. ¿Cómo se haría este trabajo de la forma tradicional?
Básicamente deberíamos definir un método que sirva de callback. El callback (también llamado continuación) es un método que el thread que trabaja en la tarea llama cuando termina para avisar que su trabajo terminó. De esta forma, podemos preparar nuestra tarea, enviarla a ejecutar, hacer otras cosas en el intermedio y ejecutar código extra cuando la tarea termina, como por ejemplo, trabajar con los resultados.
(Ejemplo del código en Gist.GitHub: Async without async)
Esta aproximación tiene un problema muy claro: la complejidad. Estamos de acuerdo con que el código de FactorNumber debería estar separado en su propio método, pero la continuación de la llamada a FactorNumber y el resto de esa lógica son parte de una misma operación. El hecho de que estén separados en el código no es más que una obligación que debemos cumplir por las restricciones del framework para la instanciación de threads.
Las palabras clave async y await resuelven este problema.
Aquí podemos notar que la estructura del código ha cambiado un poco para dar soporte a esta característica. Por un lado, tuvimos que aislar el código que interactuará con métodos asíncronos, ya que los mismos deben devolver un tipo Task. Esto es porque devuelven un identificador de la tarea que está corriendo en background. En nuestro caso en particular, este será StartWork(), pero no estamos haciendo uso de su Task.
StartWork, siendo asíncrono, se ejecutará a la vez del resto del código, ya que no será bloqueante. Por tanto, el próximo Console.WriteLine se ejecutará, muy seguramente, al mismo tiempo que el procesamiento de StartWork ocurre. Dicho procesamiento hace una llamada bloqueante a FactorNumber, es decir, espera a que FactorNumber termine (lo cual nos permitió convertir la llamada en síncrona) y una vez que tenemos el resultado, se escribirá en consola. No era realmente necesario convertir esta llamada en síncrona de esa forma, una simple llamada a FactorNumber hubiera sido suficiente, pero de esta forma demostré que si bien el sistema espera por su respuesta suspendiendo el thread actual, sigue siendo asíncrono internamente. Eso significa que está ejecutando toda la tarea de callback que vimos antes de forma interna, y ahora nuestro código se lee fácilmente de arriba a abajo.
Confieso que debo trabajar un poco más en esto para no ensuciar tanto el código, pero por ahora parecería que el uso de las keywords exige modificar los valores de retorno y por tanto las llamadas a esos métodos deben ejecutarse de forma distinta. Eso no me agrada, porque inclina un poco la complejidad innecesaria para usar esto, pero sigue siendo una ventaja sobre la solución original.
Análisis de la Batalla Naval
Pasos para crear una buena estrategia
Ya que están pasando Battleship en el cine, me pareció muy apropiada la publicación de este link. De parte de MicroSiervos, Nick Berry de DataGenetics nos habla de un análisis estadístico para la estrategia de la Batalla Naval.
Atacando el problema primero en la forma más simple posible y luego mejorándola, él nos muestra cómo fácilmente se puede construir una inteligencia que, sin ser muy compleja, se acerca mucho a ser un buen competidos en un juego como este, y los números están ahí para probarlo.
Cabe destacar que esto parece ser algo muy común para la gente de DataGenetics y su blog, el cual comencé a seguir. Tienen muchos buenos análisis de varias cosas totalmente distintas. De hecho, hace poco me crucé con un post llamado Counterintuitive Conundrums, que básicamente son problemas con soluciones inesperadas (y nuevamente, los números están ahí para probarlo).
Soy un zorrinito analítico.
Jasmine
Javascript BDD
Jasmine no es el primer ni el último testing framework que existe, pero aquellos que vengan desde RSpec lo encontrarán muy parecido y fácil de usar. La misma página de Jasmine muestra una buena cantidad de ejemplos de cómo puede ser usado y de sus capacidades. Cabe destacar que no depende de ningún otro framework, pero juega bien con ellos (lo cual es interesante para realizar pruebas de UI aprovechando capacidades que jQuery, Dojo o Mootools nos puedan dar), y ni siquiera necesita del DOM estando cargado, lo que significa que de tener una aplicación compleja en JavaScript, podemos realizar pruebas unitarias respecto de nuestras propias librerías, independientemente de que se encuentren cargadas en un entorno o no.
Soy un zorrinito testeado.