Archive: February 2012
19 posts published in February 2012
Las 10 reglas del trabajador Zen
La noble tarea de trabajar, efectivo y eficaz y en paz.
Sé que AP acaba de publicar esto (¡Gracias!), pero creo que su relevancia es tanta que voy a republicarlo también. él publicó un link a un artículo llamado The 10 rules of a Zen Programmer y antes de que digan nada: casi no tiene nada que ver con programación (de ahí el título que yo le dí). Las reglas que expone son imprescindibles para un buen trabajo, organizado y tranquilo. Estoy totalmente de acuerdo con todas.
Aún más, como yo comentaba, actualmente me encuentro leyendo un libro llamado Hagakure, que se trata del código de honor y conducta de los samurais del siglo XVI, escrito por samurais mismos. Me sorprendió mucho (y quizá no debería) ver que las pautas dadas en este artículo son muy cercanas a las expuestas en ese libro. Se trata de hacer noble la tarea a la que nos dedicamos y convertirla en algo casi espiritual.
Si a alguien le gustó tanto como a mí este artículo, el autor, Christian Grobmeier, tiene una categoría en su blog llamada The Zen Programmer, algo vacía aún, y está trabajando en un eBook en donde explicará todos estos conceptos con detalles, ejemplos y algunas cuestiones más. Si les interesa seguir el progreso, pueden ver los detalles en el Libro: The Zen Programmer.
Sisyphus.js
Widget de autoguardado
Una característica que seguramente todos adoramos de GMail es el autoguardado. Al momento exacto en que dejamos de escribir un mail, este se autoguarda, y no recuerdo cuándo fue la última vez que perdí un mail por accidentalmente refrescar la página. Quienes vienen de las viejas épocas de Hotmail conocen mi frustración.
Hay alternativas interesantes para lograr este mismo efecto, una de las cuales es Sisyphus.js (gracias JH!), un proyecto de open source en GitHub que es un wrapper para formularios. Se encarga de automáticamente atrapar los eventos de cambio en ellos para guardar automáticamente en local storage la información del formulario. De esa forma, nuestro formulario siempre tiene la información guardada.
No dudo que pueda modificarse o atrapar eventos que nos permita también serializar esta información al servidor para que, al igual que GMail, esta información autoguardada quede relacionada con nuestra cuenta y no con nuestro navegador.
Soy un zorrinito autoguardado.
Encontrando problemas de performance en SQL
Cuando la respuesta no es obvia
Otro de los foros de Stack Exchange que suelo leer es Database Administrators, en donde, como imaginarán, las preguntas y respuestas rondan sobre bases de datos y tecnologías afines. Cada tanto me encuentro con alguna joyita útil y este fue uno de esos casos.
La pregunta trataba sobre alguien que tenía problemas de performance cuando no se trataba de el acceso a disco ni del consumo de CPU. Muy apropiadamente, la pregunta se llama SQL: What is slowing down INSERTs if not CPU or IO?, y por supuesto, siendo un caso particular puede que no nos sea realmente útil la respuesta. Lo que quiero destacar de esta pregunta es el método de investigación que usaron y las herramientas con las que analizaron la performance interna del motor de base de datos. Puede ser muy revelador para nosotros trabajar con estas herramientas cuando la respuesta no es obvia y los planes de ejecución no son suficientes para detectar problemas de performance.
Soy un zorrinito performante.
VisualEvent
Bookmarklet de visualización de eventos
Muy parecido a debugCSS que alguna vez envié, VisualEvent es también un bookmarklet que nos permite trabajar con los interiores de alguna página. En este caso, nos mostrará visualmente cuáles son los eventos asignados a los distintos elementos e incluso muchas veces el código. Muy útil para debuggear y detectar problemas de interacción con código que tenemos que corregir. Además, también para considerar cuánto JavaScript estamos usando en una página (puede que sea mucho, no?)
Soy un zorrinito JavaScript.
Joel Test para programadores
Simpleza autocrítica
Para quienes no conocen el Joel Test, es una prueba muy simple, solo 12 preguntas que nos guían a darnos cuenta si nuestro equipo de desarrollo va por el buen camino o tenemos cosas que arreglar.
De ahí alguien preguntó si había una especie de Joel Test para la evaluación de un programador en particular, especialmente preguntas para hacer en entrevistas y para evaluar a gente de forma individual. Alguien mencionó que se podía trabajar con la Programmer Competency Matrix de IndianGeek, con la que ya he trabajado anteriormente. Aún así, no se ajusta específicamente a todas las características que alguien quisiera medir en un programador.
Al fin y al cabo, las respuestas no fueron muy iluminadoras, usuarios relacionados hicieron una pregunta en Quora sobre qué hay que preguntar a un candidato antes de contratarlo, las respuestas son un poco más interesantes y más allá del tema del entrevistado y la contratación, es interesante como ejercicio preguntarnos esas cosas a nosotros mismos y evaluar las respuestas.
Soy un zorrinito evaluado.
Web Application Design Patterns
Una librería de referencias de patrones de usabilidad
Bueno, son las 4 AM y no puedo dormir. Acabo de terminar de leer el libro que venia leyendo lentamente desde hace tiempo ya, llamado Web Application Design Patterns, de Pawan Vora.
El libro en sí tiene el título muy bien puesto, porque realmente de eso se trata. Es una colección de patrones de diseño orientados a la usabilidad y la interfaz gráfica de las aplicaciones web. Para los que ya lo sabemos, recordaremos que los patrones son, como su palabra lo indica patrones. Son características en común y no soluciones definitivas ni detalladas de como aproximarse a una situación en particular.
Hablando de patrones en software, generalmente se los identifica de una forma muy común y muy particular. Cada patrón tiene un nombre que lo identifica, un problema particular que resuelve y una descripción de la solución básica a la que aproxima. La compilación de patrones que Vora hizo en este caso hace muy buen tributo de ese esquema y lo mejora en varios aspectos.
El libro se divide en varios capítulos que atacan temas comunes que merecen la atención en el desarrollo y la usabilidad de aplicaciones web, los cuales son:
- Formularios
- Autenticación de usuarios
- Página principal de la aplicación
- Navegación
- Búsqueda y filtrado
- Listas
- Rich Internet Aplications
- Aplicaciones Sociales
- Internacionalización
- Accesibilidad
- Diseño visual
- Librerías de patrones
Le doy crédito especial por la inclusión de esa última sección, en donde se definen las características que una librería de patrones (como este propio libro) debería tener, y se basa en varias librerías actuales en uso y recopiladas anteriormente por estudios al respecto.
En todas las secciones se muestran ejemplos, tanto de implementación como de uso real de esas características. Una gran mayoría de las veces se fundamentan los beneficios de estos patrones con estudios (las referencias están todas incluidas y detalladas al final del libro). Al mismo tiempo, están todos los conceptos explicados de una forma lo suficientemente detallada como para ser comprensible, lo suficientemente abstracta como para ser reusable y lo suficientemente clara como para ser entendida por no-programadores o diseñadores.
Una distinción que en este libro no se hace y me gustaría agregar como apreciación propia es que los patrones, como ya comenté, son soluciones a problemas determinados. No hay que confundirlo con buenas prácticas que, aunque cercanas, siempre conviene aplicarlas. El caso de los patrones es distinto, y de hecho, parecería ser imposible aplicar la totalidad de los patrones a cualquier sitio web. Ni siquiera los que están entre los ejemplos (Google, Apple, Mint, Facebook, Yahoo!, Basecamp, eBay, Amazon, y una larga lista de etcéteras) cumplen con la mitad de los patrones mencionados.
Volviendo al libro, lo recomiendo mucho como un libro de referencia. Está redactado como tal y no es una lectura ligera, pero vale la pena. 4 zorrinitos.
UPDATE 22/02: Tras pensarlo un poco más me dí cuenta que este libro no cubre una característica que si bien no está muy relacionada con la usabilidad, sí está relacionada con la experiencia del usuario, y ciertamente son patrones aplicados en web applications. Lo encerraría bajo la categoría de Performance, e incluiría cosas como caching de nivel aplicación, caching de nivel usuario, AJAX, conexiones persistentes, preprocesamiento de resultados. Son todas cosas que aplican como patrón a resolver un problema en particular en una situación en particular, siendo lo suficientemente abstractos como para ser aplicados en una variedad de casos. Posiblemente sería más difícil encontrar ejemplos (porque muchos sistemas no cuentan cómo es que funcionan por dentro), pero creo que sería bueno haberlos cubierto.
Soy un zorrinito usable.
Schema.org
Repositorio público de esquemas de markup
En el punto intermedio entre estándares y SEO está Schema.org, un sitio que haciendo uso de los estándares de microdata permitiría mejorar la meta-información que un sitio está aportando, específicamente para hacerlo más apropiado a los motores de búsqueda. La página de Getting Started nos da una buena idea de qué trata esto.
Según cuentan, Google y otros proveedores de búsqueda están teniendo mucho en cuenta estos formatos de metadatos, llamados micro-formatos, y justamente podemos apreciar muchos de ellos y su estado de aprobación en Microformats.org.
Soy un zorrinito micro-formateado.
¡Volvieron los comentarios!
...y volvieron para quedarse!
Eso, ya pude habilitar los comentarios (y quedarom medianamente arreglados), hagansé un festín de feedback para decirme qué piensan. Acuerdensé de comentar en todo lo demás, toda opinión es bienvenida (no por eso aceptada, jeje).
Soy un zorrinito comentado.
¿Qué loggear de los usuarios?
Orientado a mejorar la experiencia del usuario
Un problema común en cuanto a mejorar la experiencia del usuario es que muchas veces no se sabe cuál es el problema, o cómo los usuarios interactúan con la aplicación. Si bien algo de eso mencionamos cuando hablamos de 22 herramientas para mejorar la usabilidad, hoy el problema es interno de la aplicación, y se trata de loggear las acciones de los usuarios para identificar qué necesita mejora.
Entonces, ante la pregunta: ¿Qué vale la pena loggear de los usuarios para ganar perspectiva de su comportamiento? la respuesta es, como muchas veces, depende. La razón es que loggear es caro, loggear todo es imposible y solo resultaría en un montón de datos sin correlación a nada. Los detalles de qué aproximaciones se pueden tomar están también entre las respuestas a esa pregunta.
Soy un zorrinito loggeado.
22 herramientas para probar usabilidad
Compendio de herramientas para mejor usabilidad
En mashable tienen un artículo muy interesante llamado 22 Essential Tools for Testing Your Website’s Usability. Cane destacar que el artículo no sólo expone las herramientas sino que además las categoriza y da una pequeña explicación de cada categoría, para que sepamos exactamente qué queremos medir en cada caso. Las categorías son: Análisis de tareas de usuario, legibilidad, navegabilidad, accesibilidad, velocidad y experiencia de usuario.
Soy un zorrinito usable.
DotLess
Precompilación de CSS para .NET
Sé que esto no es ninguna novedad, pero lo explico para el que no lo conozca: less es un componente JavaScript que nos permite tener más flexibilidad en el tipo de cosas que podemos escribir en nuestros archivos CSS. Estos archivos pasan luego a llamarse archivos less, con una sintaxis muy parecida a CSS, pero con algunas mejoras, como la definición de variables, mixins (“funciones”) y anidamiento (namespacing?) de declaraciones. Como bien dicen entonces, less is more.
Ahora, uno de los grandes problemas con esto es que less es JavaScript, y por tanto, no está bueno que cada navegador tenga el trabajo de pre-compilar el CSS y aplicarlo a cada página. Es un poco trabajoso (dependiendo de la complejidad de nuestros estilos y nuestras páginas), pero está claro que es demasiado trabajo. Alguien preguntó si había una forma de compilar los archivos less a CSS para que cada navegador no tenga que hacerlo, y obtuvo una buena cantidad de alternativas.
Yo encontré una no mencionada, y sacada directamente de NuGet, dotless es la portación de esto mismo a .NET, con la diferencia de que está implementado en forma de HTTP Handler, lo que significa que el browser se encarga de resolver los pedidos de archivos .less y devolverlos como CSS. Mejor aún, ya puede devolverlos minimizados y cachearlos. Dije que es un paquete Nuget? La instalación en sí son 4 clicks. Muy adecuado.
Soy un zorrinito cómodo.
ELMAH
Error Logging Modules and Handlers for ASP.NET
ELMAH es un proyecto hosteado en Google Code bajo la licencia Apache 2.0, que automáticamente se inserta en nuestro código para darnos un tratamiento mucho más complejo de errores, incluso de aquellos que surgen de forma inesperada (que, filosóficamente hablando, debería ser la mayoría de ellos).
Cabe aclarar que las características que ELMAH provee out-of-the-box son:
- Loggeo de todas las excepciones no atrapadas
- Una página para remotamente ver un log de las excepciones
- Una página para remotamente ver los detalles de las excepciones
- Ver el yellow screen of death original
- Notificaciones por email
- Notificaciones por RSS
Cabe destacar que se sabe que ELMAH tiene ciertos problemitas en integrarse a aplicaciones ASP.NET MVC, específicamente por la forma en que se tratan algunos errores, pero tienen una solución aceptable, como explican en What are the definitive guidelines for custom error handling in ASP.NET MVC 3? (Lástima que la pregunta original nunca se respondió de forma completa.)
Si les interesa una respuesta más apropiada a esa pregunta (cómo deben tratarse las excepciones), les recomiendo un link compartido por JM, 15 Best Practices for Exception Handling, muy recomendable.
Soy un zorrinito excepcional.
ASP.NET: Transfiriendo información entre páginas
8 formas comunes, en ASP.NET
Este es un problema común y por eso me pareció apropiado hacer un poquito de difusión a este link en particular que encontré entre los Enlaces interesantes número 66 de VariableNotFound. Muy apropiado, el artículo se titula Eight Different Ways to Transfer Data from One Page to Another Page (por Dios, son feas las páginas de EggheadCafe). Como bien aclara el mismo artículo, hay más formas de hacer eso, pero creo que estas primeras ocho son las aproximaciones más comunes, e incluso muchas independientes del lenguaje. Cada una de ellas tiene consideraciones que no se mencionan en el artículo, pero aún así es bueno como referencia rápida.
Soy un zorrinito transferido.
Selectores CSS4
No está el 3, vamos por el 4!
Síp, los selectores CSS4 ya hicieron su apareción en uno de los primeros drafts de la W3c en septiembre del 2011. Sin embargo, les falta un buen camino para que siquiera vayan a implementarse en cualquier navegador, por lo que no están listos para ser usados, ni siquiera para ser probados.
Hay muchos pseudo-selectores y unos cuantos selectores en sí, y si prefieren una versión resumida, pueden visitar el artículo de Meet the CSS4 selectors, pero en el fondo les recomiendo leer el draft de la W3C y hacerse agua la boca con lo fácil que va a ser aplicar estilos.
(vía los Enlaces interesantes número 65 de VariableNotFound)
Soy un zorrinito estilizado.
Backbone.js
Hace un tiempo ya que en nuestro equipo estamos integrando Backbone.js a nuestros proyectos. La idea tras backbone.js es, como su nombre lo indica, ser la columna vertebral del código javascript frontend, de forma que todo trabaje sobre una estructura centralizada y permita al código no ser un desastre auto-destructivo o conflictivo cuando los proyectos crecen. Esto se da mucho en aplicaciones con mucha interacción de usuario, y es importante para una aplicación compleja poder tener el código organizado. Backbone le da una estructura al código del tipo MVC en donde podemos diferenciar datos, de presentación de los mismos y de elementos que controlan la interacción entre ambos.
Ahora, el problema con backbone es que es un poco difícil de aprender. Tiene mucha estructura, poca documentación y no todo es obvio. Gracias a AM y a SC que me han compartido estos documentos útiles: Backbone Fundamentals y Backbone Patterns.
Toda esta temática queda muy acorde a The Seven Deadly Sins of JavaScript Implementation, en donde backbone.js se encarga de un par de pecadillos.
Soy un zorrinito frontend.
**UPDATE: **For English readers, you may check out this Backbone.js Introduction and Resources.
Git, Parte 1
Un fauvista con cubiertos de gala
No hace mucho que, gracias a un proyecto paralelo a mi trabajo, estoy aprendiendo a usar Git. Encontré que es una herramienta sumamente compleja y flexible, distribuida y rápida.
Un poquito de historia
Git, para quién no lo sabe, es un sistema de control de versiones, distribuído, enfocado en la velocidad, y que fue desarrollado por Linus Torvalds exclusivamente para el desarrollo de Linux, luego dejándolo libre para su uso indiscriminado. La historia es algo humorística, ya que, en pocas palabras, Linus decía que todos los sistemas de control apestaban de una forma u otra, y quiso hacer algo que fuera bueno de verdad. Quizá no estén de acuerdo con que sea tan superior, pero tienen que aceptar que es realmente radical. Si no saben por qué, sigan leyendo.
Con su primer release en el 2005 y ganando más popularidad en la actualidad, Git ha probado ser eficiente y un buen recurso para el control de versiones. Mejor aún, para el programador.
De qué va a tratar esto
Soy un novato todavía, pero quiero compartir mis pequeños avances con Git como para que los demás puedan aprender conmigo. Suelo trabajar mucho en Windows y si bien mis primeras experiencias fueron con Git Extensions, al final el uso de la consola terminó siendo mucho más efectivo. Git Extensions mismo viene con una consola y si están en Linux, hay versiones de Git de sobra que pueden utilizar.
Nuevamente, decía que soy solo un novato por ahora, y si bien creo tener razón en lo que voy a afirmar, entiendo que puedo estar totalmente equivocado. Sientansé libres de contactarme y corregirme. Estoy dispuesto a hacer crecer esto todo lo que sea necesario, o de hacer muchas entregas como para aportar información interesante. No sé en qué terminará esto, pero mientras más informativo, mejor.
La filosofía de Git
Git, a diferencia del resto de los sistemas de control de versiones, funciona de una forma tan granular que nos permite generar nuestro propio proceso en lugar de adaptarnos a un proceso estándar. Hay quienes prefieren trabajar de alguna forma y quienes prefieren trabajar de otra, pero una vez que se entiende bien la filosofía de Git, es todo , en el fondo, lo mismo. Comencemos.
La filosofía de Git, en pocas palabras, es de apartarse del trabajo diario del programador (o diseñador, o lo que sea que hagamos) y dejarnos hacer nuestro trabajo. Git se encargará, cuando se lo indiquemos, de identificar las diferencias, y de convertirlas en cambios graduales que querremos versionar de forma conjunta o de forma separada. Cambiar un archivo dos veces no implica un único cambio. Cambiar varios archivos no implica cambios separados. Todo queda a nuestra discresión.
Y eso es parte de lo importante: Git nos permite hacer nuestros cambios de una forma “ordenada” y hasta semántica. (Me gusta mucho últimamente esa palabra.) Podemos dar determinado significado al progreso de nuestros cambios, de forma que tengamos controlado cuando podemos volver atrás y cuándo podemos seguir adelante. Cabe destacar que ambos son posibles en cualquier punto de nuestro trabajo. Más adelante se darán cuenta de por qué digo esto.
Para aquellos que estábamos acostumbrados a VSS, TFS o SVN, nos daremos cuenta de que es algo distinto. Quizá los que usaban SVN desde la consola lo encuentren, en algo, similar, pero la filosofía en la que se manejan los cambios es totalmente distinta. Se darán cuentas que cosas que por lo general son imposibles de hacer, son totalmente naturales, y de hecho, se hacen todo el tiempo. Esa es, en pocas palabras, la filosofía de Git: No ponerse en el camino del programdor. Ser una herramienta, no un obstáculo.
Un sistema distribuído
Distribuído, cloud computing y todo lo demás es un término exageradamente abusado hoy en día. Todos sabemos las ventajas que esto tiene y en general por qué convienen (o por qué no). En el caso de Git, es realmente una ventaja, y no tenemos por qué sufrirla si un sistema distribuído no nos conviene.
Que Git sea distribuído significa que no hay ningún repositorio central, ninguno vale realmente más que otro. Por supuesto, muchas veces nuestra organización hace que hagamos de uno de ellos el repositorio central, pero cualquiera de ellos podría hacerlo, y esto significa que los repositorios centrales también pueden invertir su rol de a ratos. Supongamos que Alice y Bob se copian un repositorio central de Carlos (esto se llama clonar). Ambos trabajan sobre A y B, pero Carlos también sigue trabajando en C. Si Bob quiere obtener la última versión de todos ellos (así convirtiéndose en un repositorio central por un momento), sólo tiene que “jalar” los datos (pull) desde los repositorios A y B. Cualquiera de ellos puede hacer lo mismo.
Mejor aún, con los permisos necesarios, cualquiera de ellos puede “empujar” cambios (push) a los otros repositorios. Claro, que si no hubiera reglas, todo sería un descontrol, pero Git nos permite acomodar la organización como mejor queramos. Los repositorios son gratis, ocupan poco espacio y pueden clonarse infinidad de veces.
Se imaginan que con una característica tal, cada repositorio copia es, en cierta forma, un backup del repositorio central (o del que designemos como repositorio central). Cada cambio puede pasar por un proceso separado y por una cantidad de repositorios distinta hasta llegar a estar presente en todos lados. “Qué desastre!”, pensarán. Y eso les comienza a dar la idea más importante: Git es una herramienta muy avanzada, podemos realmente hacer desastres catastróficos con ella, pero también podemos hacer procesos elegantes y simples, sin comprometer las necesidades.
Un ejemplo real: en un proyecto en el que actualmente estamos trabajando, A, B y yo (yo seré C), tenemos un repositorio central en GitHub, online. Cada uno de nosotros tiene su fork (copia) del mismo repositorio también en GitHub, y a la vez, cada uno de nosotros tiene una copia local. Todos trabajamos en la copia local, hacemos nuestros branches, commits, etc. Cuando es necesario, empujamos nuestras cosas a nuestro repositorio de GitHub, de forma que ambos están sincronizados. Cuando el momento es el apropiado, enviamos pushes al repositorio central. Cada uno de nosotros tiene acceso al repositorio central de la misma forma que al suyo, lo cual permite muchas veces arreglar errores del pasado (sí, Git permite eso) pero en general, esta estrategia ayuda a sincronizarnos. A veces trabajamos trayendo y llevando cosas entre nuestros repositorios, sin uso del central, hasta que una característica esté lo suficientemente madura.
Dejo esto por ahora. Prefiero hacer los posts cortos y que sean muchos, a que sean grandes, largos y nadie los lea.
Soy un zorrinito distribuído.
Pro ASP.NET MVC3 Framework
Acabo de terminar de leer Pro ASP.NET MVC3 Framework, un libro de Apress, escrito por Adam Freeman y Steven Sanderson. En pocas palabras, el libro es muy bueno, no exageradamente detallado pero buena aproximación para quiénes quieran ganar un nivel principiante/intermedio en la plataforma. Determinadas características han quedado afuera, y por supuesto, detalles de la implementación del framework también. Eso habría sido material para una buena cantidad de otros libros. Este en particular está muy orientado al ejemplo práctico, y es ideal para afianzar teoría con pequeños snippets de código que la hacen práctica. Cubre algunos aspectos relacionados a esto para darle un buen contexto y es una buena opción por su precio, pero no es suficiente para el que quiera entrar demasiado profundo en los interiores de la plataforma.
El libro se divide en tres grandes partes. La primera parte, llamada Introduciendo ASP.NET MVC 3, es una explicación muy a vuelo de pájaro de qué es MVC, cómo es la aproximación de Microsoft a él y unos ejemplos básicos para demostrar la organización de una aplicación MVC. Se habla un poco de inyección de dependencia, haciendo uso de Ninject, pero su aplicación es de lo más básica y no justamente asociada a las buenas prácticas, aunque como primer paso, es bueno. Habla de DDD y de TDD, ayudado de Moq, desde un punto de vista tan superficial que no hacen impacto en el resto del contenido, pero siguen estando ahí.
La segunda parte del libro, ASP.NET MVC3 en Detalle, comienza a hablar del sistema de ruteo, de cómo se enlazan a él los controladores y las acciones, el uso de filtros (casi tocando AOP para controladores, pero no mencionándolo), uso de controladores propios, autorización, generación de un engine propio de vistas, uso de helpers, vistas parciales, acciones hijas, templates de modelos, binding de modelos, validación, AJAX, y el uso de jQuery. En estos últimos dos puntos debo hacer una aclaración: la forma en la que se implementa AJAX es todavía muy Microsoft-oriented, del estilo de hacer una receta y que todo funcione de forma mágica. Se queda muy corto para customizaciones y aplicaciones reales con lógica de cliente compleja, pero recordemos que este libro es sobre ASP.NET MVC, no sobre JavaScript. Aún así, es un buen comienzo para profundizar en otro libro.
La tercera y última parte, Entregando Projectos ASP.NET MVC 3 Exitosos, cubre varios puntos extras no exactamente de a la plataforma pero relacionados. Uno de ellos es la seguridad. Se le dedica un capítulo entero a determinados tipos de ataque y forma de evitarlos. Como los otros temas tangenciales, no es una guía definitiva, pero un buen punto para comenzar. Otro capítulo está dedicado a la autenticación y la autorización, sin mucho detalle y sin mucho ejemplo esta vez, pero pasos básicos que nos permiten conocer varias opciones distintas para las distintas situaciones que debamos afrontar. El último capítulo de esta parte se enfoca en el deployment y la generación de paquetes de instalación. Nuevamente, no contiene mucho detalle.
El libro en general es bueno como introducción y bueno como ejercicio de aprendizaje. Es detallado en el comienzo y light al final, con lo cual sus 836 páginas en realidad son un resumen de mucho más que podría cubrirse. Es un balance apropiado, con lo cual recomiendo su lectura. Le otorgo unos 4 zorrinitos.
Principios Universales del Diseño
Partiendo desde la base de lo básico
Este es otro de esos encuentros que hago en los foros de StackExchange, específicamente en el de User Experience. Aquí alguien preguntó ¿Cómo es que los bordes redondeados afectan la usabilidad?
La pregunta estaba orientada al saber el por qué los bordes redondeados son algo deseable, y de qué forma afectan a nuestra experiencia de una página web. Al mismo tiempo, también pregunta por qué la mayoría de los sitios permite que estos bordes aparezcan no-redondeados en versiones viejas de algunos navegadores, si es que es una característica tan importante.
La respuesta más votada habla de la psique humana y cómo el ser humano responde de forma más amigable a objetos redondeados. Hizo una referencia muy interesante también, basándose en el libro Universal Principles of Design, un libro que analiza desde lo más básico la experiencia de usuario en mundos más allá de la informática (incluyéndola también). Mostrando cosas como desde el diseño de juguetes, al diseño de menúes y pasando por el diseño de elevadores, este libro parece ser una de esas joyitas que iluminan más el por qué que el cómo hacemos lo que hacemos todos los días.
Soy un zorrinito especulativo.
GoMo
La iniciativa mobile de Google
Gracias a i.MicroSiervos me enteré de GoMo, una aplicación web que toma nuestro sitio y nos analiza de forma personalizada las características del mismo y nos da sugerencias para pasar al mundo mobile. Cosas como la visibilidad de la página, los links, las tecnologías utilizadas y demás, está todo disponible en un reporte de forma gratuita.
Cabe destacar que este sitio es en realidad una iniciativa de Google, con lo cual gana un poco más de renombre.
Les recomiendo también visitar el mismo sitio desde un dispositivo movil, la enorme diferencia con el sitio original realmente habla de tomar una aproximación diferente al momento de pensar en mobile.
Soy un zorrinito móvil.