Alpha's Manifesto

La madriguera de una insignificante figurita blanquinegra.

tardis.js

Viajando en el tiempo de forma transparente

tardis.js logo

Para un proyecto tuve la necesidad de una herramienta que me permitiera cambiar el “momento actual” de una aplicación JavaScript. Les presento a tardis.js.

(Leer más →)

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.

T IEnumerable.RandomElement()

Seleccionar un elemento cualquiera de un conjunto

Otro de mis pequeños snippets, este es útil para unit testing.

Cuando tienen un repositorio de datos que en realidad es mockup, y algún objeto tiene que estar pre-populado, podrían querer que los tests sean independientes de los datos. Y con esto me refiero a ser independiente de los valores que esos objetos tienen. Para esos casos, utilizar un objeto al azar de un conjunto de objetos sería una buena aproximación. No es tan determinista, pero eso es algo deseable, e incluso más cerca a probar la aplicación real.

Para obtener un objeto al azar, este pequeño snippet ayuda:

Link del día: Aprendan estadística o los mato a todos

Este link que me llegó del nuevo Delicious trata de un rant de Zed Shaw titulado Programmers need to learn statistics or I will kill them all. Trata de las frustraciones que él encuentra al momento de discutir resultados de tests y generalizaciones con determinados programadores con los que ha trabajado.

Si bien no deja de ser un rant y por eso no es realmente informativo, es un buen punto de partida para entender por qué el conocimiento básico que tenemos de estadística (si no todos, probablemente una gran mayoría). Creo que muchos hemos pecado de cometer las mismas acciones que él cuenta en su artículo, como dar un número grande de pruebas, sacar un promedio y entender que ese es el promedio de los casos, cuando hay muchos otros factores que afectan y muchos otros datos que aportan información y nunca se tienen en cuenta. Para sacar una frasecita de su artículo: “El punto es que si ustedes dan un promedio sin mostrar la desviación estándar, perdieron completamente el punto de siquiera intentar medir algo“.

Soy un zorrinito promedio.

Link del día: Multiversiones IE

Alguna vez les conté de Xenocode, una suerte de plugins que ejecutándose virtualizaban distintas versiones de Internet Explorer (aunque me pregunto en dónde dejé ese artículo). Ahora que no está más disponible, entre nuestras opciones disponibles para hacer testing de IE está Utilu IE Collection, un conjunto de versiones standalone de Internet explorer (desde la 2.0!) para poder utilizar en nuestro testing de cross-browsing.

No sólo eso, la gente de Utilu también ha trabajado para ofrecer lo mismo en el mundo de Firefox, coherentemente llamado Utilu Mozilla Firefox Collection.

Al ser todas standalone se pueden correr en paralelo y comparar. Todo sin dejar la comodidad de tu localhost.

Soy un zorrinito 2.0, 3.0, 4.0, 5.0, 5.5, 6.0, 7.0, 8.0, 9.0 y 10 CTP 1.

Link del día: LoadTest

Como ya sabemos, la web está llena de herramientas gratis que podemos utilizar, y el load testing no queda excluído. Hace poco me crucé con una herramienta llamada LoadImpact, que, como su nombre nos da a pensar, es una herramienta web que permite hacer test de stress sobre websites. En este caso, para acceder a la totalidad de sus funcionalidades deberíamos subscribirnos y abonar un pago, pero también podemos acceder sin registrarnos a una batería de tests gratuitos.

Desafortunadamente los tests al correr no nos dan información demasiado detallada sobre lo que ocurre tras el telón, pero logra el objetivo de mantener los resultados y la información simple como para poder detectar cualquier problema de performance que la concurrencia de usuarios nos pudiera llegar a dar.

Soy un zorrinito concurrente.

Link del día: Diseñar con TDD

Para los que no conocen la sigla, TDD representa el concepto de Test Driven Development, la metodología de hacer las pruebas de lo que queremos lograr antes del código.

Este es el caso de alguien que estaba demostrando esa metodología ante uno de los escépticos que no creen que sea realmente aplicable. “Funciona muy bien en la teoría pero al momento de la verdad no se puede respetar totalmente”, pensaba. Ese es el caso de Rob Conery, explicando las técnicas de TDD de Brad Wilson.

Lo que él hizo fue, intencionalmente, planear una situación en un sistema medianamente complejo, para luego introducir un nuevo requerimiento que cambiaba todo el diseño. Parece que entonces lo que Wilson hizo fue, en lugar de tirar todo y comenzar de cero, ir adaptando las pruebas gradualmente, ir refactorizándolas hasta que comenzaron a formar “clases”, que luego se movieron del entorno de pruebas al sistema real.

“Un concepto en el que no había pensado nunca” – menciona Conery – “usar el archivo de pruebas como una especie de útero {de dónde nacen las clases}”.

Soy un zorrinito TDD.

Link del día: Notas sobre HTTP Load testing

Hace poquito encontré esta serie de notas que conformaron un artículo sobre HTTP Load Testing. El artículo trata distintos puntos relativos a cómo se ve afectada la calidad del testing, a la vez de distintas técnicas para tener (o para evitar) de forma que los resultados del testing sean lo suficientemente confiables como para significar algo.

Por otro lado, siempre están esos consejos de la experiencia que podemos leer ahí también, y que si bien no tienen mucho sentido en un principio, tras haber hecho caso podemos ver la razón real de por qué se nos aconsejaba eso.

El artículo está muy interesante, incluso si están pensando en aplicarlo a load testing que no necesariamente sea HTTP, yo creo que aplicaría a cualquier tipo de testing cliente-servidor, y también varios de estos conceptos serían útiles para load testing de cualquier tipo de aplicación.

Soy un zorrinito cargado.

Link del día: AngularJS

Hace poquito apareció en mi feed de Youtube una charla de Google Tech Talks llamada How to Write Clean and Testable Code. Para ser sinceros, el video dura más de una hora así que no lo ví, pero en lugar de eso busqué las diapositivas que se habían usado en él y las encontré aquí: How to write Clean and Testable Code Slides. Las diapositivas no me resultaron demasiado reveladoras tampoco pero sí resaltan algunos conceptos claves que es bueno siempre tener en mente.

Más allá de eso, en las diapositivas (y muy seguramente en la charla) se menciona a AngularJS, así que lo fui a buscar. Parece que AngularJS es un sistema de templating a través de JavaScript, pero mucho mayor que simplemente templating. Digamos que más que estar orientado en generar HTML a partir de datos, también se preocupa de la forma en que esos datos deben interactuar, de forma que, podríamos decir, también genera algo de código dinámicamente para que estos datos funcionen correctamente.

No lo he probado, pero ellos dicen que es la forma en la que debería haber sido HTML si es que hubiera sido pensado desde un principio para aplicaciones web.

¿Alguien lo probó? ¿Cuáles son sus experiencias?

Soy un zorrinito javascript.

Link of the day: RamDisk

I was reading a blog entry on the Web Developer’s Personal Notepad, and came across an article of how he could speed up his PHP Unit tests by 10 times. I mean, wow, TEN. TIMES. That’s a lot indeed.

So, it turns out that he used a RAM storage for the databases, and that really lowered the bottleneck effect on those tests. Not only that, it turns out that the used software, RAMDisk, is available free of use for storage under 4 GBs. Even if you need to have a licensed version, it only costs 10 dollars, so there’s no excuse to start making your databases go on memory for this kind of stuff.

Also, it’s disposable storage, so it fits perfectly the purpose of testing. Sadly it’s only available for Windows Vista+, but hey, it’s still free for all of us!

I’m a tested little skunk.