Link del día: Un poquito de Encodings

El otro día, leyendo un post de I know the answer (it’s 42) hablando sobre cuál es el post del blog por el que te conocen (cosa que generalmente suele ocurrir), me desvíe leyendo otro de los artículos que él linkea, llamado The Absolute Minimum Every Software Developer Absolutely, Positively Must Know About Unicode and Character Sets (No Excuses!) […la frotó sobre una piedra, la colgó de un abedul…]. Dicho post en particular habla de toda la historia que hay detrás de las distintas representaciones de los caracteres y la forma de codificarlos. Muy fácil de leer y hasta muy didáctica. Importante para los desarrolladores y buen dato para los curiosos (notesé que tiene fecha del 2003… y aún aplica muy bien).

Por ahí también anda el link a la página oficial de Unicode, que es actualmente el repositorio más grande de información que hay sobre símbolos utilizados para la transmisión de información, desde letras latinas y números hasta símbolos matemáticos y caracteres ideográficos.

Como extra también tenemos una página para testear distintos encodings en nuestro navegador (aunque a mí no me anduvo del todo bien), o una que tiene varios elementos todos juntitos, acá o acá.

Soy un zorrinito latin-1.

(Read more →)

Testing como parte del proceso de calidad de software

Hoy finalizó el curso de tres días de Testing como parte del proceso de calidad de software, organizado por [ATICMA](http://www.aticma.org.ar/), [Universidad FASTA](http://www.ufasta.edu.ar/) y [SEPYME](http://www.sepyme.gov.ar/), en conjunto con el [INTI](http://www.inti.gov.ar/). Dicho curso, dictado por Victoria Martínez Suárez del Laboratorio de Testing y Aseguramiento de Calidad de Software del INTI Córdoba, constó de una serie de puntos a tener en cuenta en el momento a comenzar con el proceso de testing y cómo integrarlo a un proceso de desarrollo ya implantado en nuestras empresas. El curso constó de 7 (siete) horas por día durante 3 (tres) días, siendo los mismos Jueves 19, Viernes 20 y Sábado 21 de Marzo de 2009. El curso comenzó con la introducción al testing del software. Sus ventajas y desventajas, y la introducción a conceptos comunes en un área que aún se encuentra en desarrollo como parte del proceso de software. Se introdujeron varios de los estándares internacionales utilizados para la organización de dicho proceso en cuanto a documentación, definiciones de ciertos de los aspectos del mismo. Ese mismo día, tras haber terminado con esa introducción, se procedió a hablar del testing como parte del proceso de calidad. Se hizo mucho énfasis en el valor agregado que aporta el hecho de hacer testing de software ante el aseguramiento de la calidad, y, como se repitió varias veces: "el costo de no hacerlo". Finalmente, se procedió a hacer combinar el proceso de desarrollo y el proceso de testing, que posee un ciclo de vida propio, flexible y complejo. Terminada la visión de proceso, se siguió ya introduciéndonos en distintas metodologías de testing de software, que incluyen distintos tipos de prueba, es decir, según el aspecto que quiera medirse. Según lo deseado de evaluar, qué tipos de pruebas pueden efectuarse y cómo se relacionan con el proceso, qué granularidad deben tomar esas pruebas, qué se debe hacer para que sean satisfactorias, qué hacer con los resultados, cómo re-evaluar, etc. Teniendo una posición más práctica, comenzamos a indagar en el proceso de derivación de casos de prueba a partir de distinta documentación o fuentes de información (bases de las pruebas) que pueden generarse a lo largo de las etapas del desarrollo de software (sea cual sea su ciclo de vida, cascada, iterativo, ágil, etc). Luego se habló del ambiente de pruebas, se resaltó la enorme importancia de un ambiente de pruebas controlado y correctamente configurado. Luego se habló de un modelo tentativo para el ciclo de vida de las pruebas (no confundir con el ciclo de vida del proceso de testing), y cómo puede tratarse de forma organizada y ordenada los resultados de las mismas. Para esto fue que luego se dedicó toda una sección a explicar gestión de la configuración, que si bien no es algo directamente relacionado al testing, sino más a áreas de Quality Assurance, tiene enorme impacto en todos estos procesos que de otra forma se volverían caóticos e incontrolables. Por último, se realizó un repaso sobre la automatización del testing, que incluyó demostraciones prácticas sobre aplicaciones web y Selenium para testing funcional y NUnit como ejemplo de testing unitario. Agradecemos a Victoria por su dedicación, esfuerzo, organización y dictado del curso, con el cual tuvimos una visión bastante satisfactoria. Esperemos que este sea el comienzo de un proceso de interiorización en el área de testing y quality assurance para la mejora de los procesos en las empresas y en el testing en sí, para que madure como proceso reconocido y firme. _Soy un zorrinito testeado._

(Read more →)

Jobeet - symfony en 24 horas

Ayer terminé de leer y prepararme según el manual de symfony 1.2 llamado _Jobeet_. Este manual es uno de los de la saga de _Practical symfony_, de aquellos que presentan las principales características de la plataforma en base a un ejemplo práctico que se desarrolla de principio a fin. De esta forma, permite al lector no solamente conocer esas características sino además poder ponerlas en práctica, y experimentar por cuenta propia. Por mi parte, cometí el pequeño error de utilizar no la versión en inglés online (que está disponible [aquí](http://www.symfony-project.org/jobeet/1_2/)), sino la versión PDF descargable en español (disponible [aquí](http://www.librosweb.es/jobeet/pdf/)). Ese error me llevó a tener que pelear con ciertos problemitas menores de traducción, ciertas correcciones que no se encontraban aún realizadas en el PDF a modo fe de erratas (en cambio, la versión original en inglés se está constantemente actualizando), y, curiosamente, posee menos formato y menos aclaraciones la versión PDF que la versión online. Más allá de eso, creo que como manual en parte peca de cumplir esos prejuicios que a veces tenemos sobre los manuales de 24 horas. Primero, son un poco superficiales en cuanto a muchas de las características. Segundo, nunca son realmente 24 horas. Respecto de lo primero, debo decir que si bien era un poco superficial, me resultó mucho más fácil de comprender que otro libro que comencé a leer, llamado _symfony, la guía definitiva_. Esto se debe a que esta última planteaba muchas de las características de symfony como "arte de magia" y no explicaba la forma de utilizarlas, haciendo un gran conjunto de conocimientos nuevos para el lector disponibles de un solo golpe y sin ninguna idea de siquiera como ponerlos en funcionamiento. En cambio, el paulatino avance que nos propone la guía práctica resulta mucho más útil y más fácil de asimilar y poner en práctica a la vez que uno comienza a adquirir experiencia. Respecto de lo segundo, debo aclarar que, se supone, el manual estaba diagramado en 24 capítulos que deberían consumir una hora del lector cada uno. En esta hora, el lector podría leer y trabajar al mismo tiempo, y luego de esa hora estaría disponible. En algunos casos, una hora era una cuestión de sobra para comprender y llevar a la práctica los conceptos (por ejemplo, la comprensión de las clases del modelo), mientras que en otra era una hora demasiado estirada. Como ejemplo de este último caso puedo mencionar el capítulo dedicado a los plugins de symfony, en donde se suponía que leyendo el capítulo, refactorizando todo nuestro proyecto, comprendiendo la estructura de los plugins, creando un plugin, reconfigurando nuestra aplicación, y a la vez asimilando lo aprendido, no habría pasado más de una hora. Considero ese caso un poco irreal, pero también ha habido casos (como el día del diseño, o el día del descanso), en donde literalmente no se hace nada, y uno puede simplemente adelantar trabajo de otros días o experimentar cosas que quedaron en el tintero. Más allá de todo eso, debo aclarar que es un buen libro y un buen manual para comenzar. No sirve para adentrarse en los aspectos más ocultos de symfony, pero como introducción es realmente muy bueno, y fácilmente asimilable. _Soy un zorrinito en 24 horas._

(Read more →)

Capacitación VS2008 & Framework .NET 3.5

De la parte de la gente del [MUG](http://www.mug.org.ar/) hemos podido realizar una capacitación interna sobre las novedades que Visual Studio 2008 y el Framework .NET 3.5 nos ofrece sobre las respectivas versiones2005 y 2.0 de las mismas. El temario fue bastante extenso para el tiempo disponible de tres días (unas doce horas completas de capacitación, que en realidad se convirtieron en catorce), pero el tiempo fue totalmente aprovechado, y pudimos tener una buenísima introducción a todo lo que es .NET 3.5 y lo que el entorno de Visual Studio nos provee en su nueva versión. Más allá de eso, también se abordaron algunas tecnologías que si bien no son nuevas, están comenzando a tomar peso en estos tiempos, como lo es la dinámica de Workflow, Windows Communication Foundation y Windows Presentation Foundation. También hicimos un breve paneo de otras, como Silverlight, Expression Studio y otras herramientas que forman parte de la nueva suite de Microsoft para desarrollo y diseño. De parte de la empresa queremos agradecer a Adrián Cura, quién fue el orador que nos estuvo acompañando en esos días y dictando esa capacitación.

(Read more →)

Code review guidelines

En estos días mientras anduve haciendo los code reviews se me ocurrió estandarizar de alguna forma cómo podrían estos hacerse y de qué forma podría “puntuarse” al código evaluado en cuestión. Por ahora, eso último queda pendiente (ya que es lo más difícil de determinar y no lo más útil), pero lo primero se convirtió en un conjunto de categorías y puntos que pueden ser muy interesantes tener en cuenta al momento de ver el código y ver qué se puede mejorar de él.

Seguro que esta lista que viene a continuación está lejos de estar completa, y que se podrían agregar y quitar un montón de cosas, pero lo tiro como una introducción a esto que quiero (queremos?) terminar de formar, que nos puede llegar a ser muy útil.

PD: No creo que nada de esto sea “requerido” para que un sistema esté “bien”, sino que partiendo de que funciona, podemos decir “qué tan bien” o “qué tan mal” estamos.

Estandarización / Legibilidad de código

¿El código está comentado explicativamente?

El código debería estar acompañado de comentarios que expliquen qué es lo que se está haciendo y por qué más allá de explicar el cómo. A la vez, el código debería ser lo suficientemente claro como para que se entienda cómo es que se está resolviendo un problema en particular.

¿Los nombres son significativos?

Debería entenderse qué función tiene una variable, un método o una clase cuando se lee el nombre que se le dio.

¿El código de una clase accede a la información que necesita de forma correcta?

Si una clase necesita información de otras debería pedirla en los parámetros de sus métodos o en su constructor. Las propiedades también son una buena opción.

¿El código se encuentra correctamente modularizado?

El código de un método no debería excederse en tamaño, y debería ser explicativo en unas pocas líneas de código sobre qué es lo que está haciendo. De ser compleja su acción, debería repartirse en varios pasos que se desdoblen en todo lo que deban hacer.

Arquitectura

¿Se respeta el concepto de la arquitectura propuesta?

Sea cual sea la arquitectura propuesta para la aplicación, debería respetarse el esquema que esta propone, poniendo la lógica de la aplicación en donde esta debería estar, el acceso a datos en otro lado, etc.

¿Se encuentran separadas las capas de la misma lo suficiente?

De existir distintas capas en la arquitectura, estas deberían encontrarse lo suficientamente separadas como para depender de cada otra sólo como distintos módulos de un sistema y nunca según su implementación.

¿Qué tan fácil sería camiar alguna de las capas por una implementación distinta?

Como medición de la independencia de las capas, el acto de crear una nueva implementación para una de ellas debería ser tan costoso como la implementación misma y no más que eso. De ser de otra forma, existe dependencia en la implementación de las capas.

Code-coverage

¿Existe un testing definido para el código escrito?

Debería existir alguna forma de probar el código escrito, cualquiera sea su metodología.

¿Las pruebas testean que el código devuelva resultados correctos en escenarios esperados?

Las pruebas deberían testear, como caso esencial, que el sistema se comporte correctamente ante determinados escenarios.

¿Las pruebas testean el comportamiento del código en escenarios no esperados?

Las pruebas deberian testear, como caso adicional, determinadas situaciones no comunes, o incluso situaciones que no deberían darse, para poder probar la forma en la que el sistema responde al mismo.

¿Ocurre esto último con cada uno de los datos de entrada?

Las pruebas con elementos erróneos o inesperados deberían variarse para cada uno de los datos de entrada, pudiendo evaluar qué tan sensible es el sistema a la variación de cada uno de estos.

¿Ocurre esto último con combinaciones de los datos de entrada?

La misma situación es aplicable a la combinación de distintos datos de entrada. A veces la variación de los datos de entrada de forma individual no genera problemas, pero una determinada combinación de los mismos, sí. Así también puede evaluarse la correlación que tienen estos datos de entrada respecto del funcionamiento del sistema.

Estabilidad

¿Qué parte del código se encuentra atrapando excepciones o situaciones no esperadas?

El sistema debería programarse considerando que pueden darse situaciones adversas que puedan afectar el correcto funcionamiento de los bloques sobre los que depende. Si bien un extremo de esto llevaría a la reescritura de todo el código en cada capa superior (lo cual no sólo es imposible sino indeseable), debe considerarse que un bloque del que dependemos, cuanto menos, no esté disponible.

¿Cómo se comporta la lógica de tratamiento de errores?

Un sistema debería tener al menos una rutina de tratamiento de errores, que controle la situación o alerte al usuario.

¿Puede una situación imprevista alterar el funcionamiento del sistema?

La ocurrencia de un error o una situación no esperada no debería generar comportamientos no esperados del sistema. Posiblemente resultados erróneos, pero el comportamiento del sistema debería mantenerse estable.

Flexibilidad

¿Cuánta información utilizada es parametrizable, versus la que se encuentra codificada en el sistema?

La información que se considera “fija” para el sistema debería poderse parametrizar, para otorgar más flexibilidad en casos especiales en donde la misma se viera sujeta a cambios.

¿Es extensible el funcionamiento del sistema o sus funcionalidades?

En caso de no poderse alterar el código de la aplicación, debería existir cierta posibilidad de agregarle funcionalidad desde la entrada o la salida de datos.

¿Qué tanto afecta al sistema agregar una funcionalidad?

En caso de tener que agregar una funcionalidad al sistema, la menor cantidad de módulos deberían verse afectados, y nunca debería verse afectado el código de otras funcionalidades.

¿Qué tanto afecta al sistema quitar una funcionalidad?

En caso de tener que quitar o deshabilitar una funcionalidad al sistema, el código de las demás funcionalidades no debería verse afectado.

¿Qué tanto afecta al sistema el modificar la implementación de una funcionalidad?

En caso de tener que alterar una funcionalidad del sistema, el código de las demás funcionalidades no debería verse afectado.

¿Cuánto afecta al sistema que cambien las reglas de negocios?

Si las reglas de negocio que definen el comportamiento del sistema cambiaran, sería deseable que la menor parte del sistema se volvería obsoleto, y que el resto pudiera ser reusado para la implementación de las nuevas reglas de negocios.

Recursos

¿Qué recursos requiere el sistema para su funcionamiento?

Sería deseable que un sistema requiera la menor cantidad de recursos posibles. Estos incluyen tanto la utilización de procesador, memoria, tiempo de ejecución, sistemas sobre los que depende, bases de datos, archivos en disco, etc.

¿Cuánto tiempo hace uso de los recursos versus cuánto tiempo los retiene ociosos?

Sería deseable que en el momento mismo en que el sistema ya no hace uso de un recurso, lo libere. A veces esto puede ser contraproducente por cuestiones de performance, pero de todos modos sería deseable que lo haga.

Performance

¿Cuánto tiempo requiere el más pesado de los procesos que efectúa el sistema?

Los procesos que requieren mucho tiempo de ejecución deberían ser optimizados al máximo posible, ya que en ellos se encuentra el peor de los casos que el sistema puede encontrar.

¿Cuántos cuellos de botella se identifican en el flujo de información / acciones del sistema?

Sería deseable que existan alternativas para que un punto en particular no sea determinante de no poder utilizar el sistema. A veces las reglas de negocios requieren que así sea, pero de no ser necesario, es deseable que existan vías alternativas de continuar con el flujo de utilización del mismo.

Seguridad

¿Cuántos datos de entrada son validados por el sistema en cuanto a su tipo de datos?

Los datos que entran al sistema deberían controlarse si son válidos para el tipo de datos que deben representar. Ejemplo típico es el de los datos numéricos, o de fecha, que muchas veces se leen simplemente como cadenas.

¿Cuántos datos de entrada son validades en cuanto a sus restricciones según su uso?

Los datos también deberían validarse según su contenido, es decir, que contengan un valor que tenga sentido en el ámbito en el que se necesita usar. Ejemplo, una fecha de nacimiento del 1/1/0001.

¿Qué medidas toma el sistema para la protección de los distintos recursos que utiliza?

Algunos datos alteran el funcionamiento del sistema (recursos tiempo de ejecución, memoria, etc) y otros se envían a ser almacenados en determinados recursos del sistema (recursos de bases de datos, archivos, etc). Todos estos recursos deben verse protegidos de datos que hagan al sistema abusar de ellos, como ser por ejemplo los loops infinitos, el escalado de prioridades, SQL Injection, XSS, etc.

¿Qué usuarios tienen acceso a la utilización del sistema y cuáles no?

Es deseable que el sistema restrinja el acceso a los usuarios que efectivamente deben hacer uso de él y tienen permitido acceder a la información que el sistema maneja.

¿Qué usuarios tienen acceso a la administración o configuración del sistema y cuáles no?

De la misma manera, el sistema debería restringir el acceso solo a determinados usuarios que puedan modificar su configuración o comportamiento. A veces es incluso deseable que este perfil de usuarios no puedan tener acceso al resto de la información que el sistema utiliza, sino solo a la información de configuración en sí.

(Read more →)

Link del día: Preloaders, botones y DOM

Para aquellos que hacen web / flash / loquefuera, Preloaders.net es una aplicación web que les permite armar fácilmente preloaders para sus aplicaciones, de una forma elegante y bastante simple. Se le puede personalizar el color, el tamaño, la velocidad de animación entre otros parámetros.

Por otro lado Custom Buttons 3 es un proyectito que andan desarrollando en StopDesign, que, si quieren ir derecho a lo que hay hoy en día, pueden visitar el Custom Buttons 3 Demo. La idea es correctamente utilizar el elemento <button> de HTML y poder estilizarlo de forma propia. Ya los pueden ver ahí qué tan elegantes pueden verse.

Y ya que estamos con lo web, dejo también un pequeño documento que da una referencia del DOM Core, que me hace un poco de falta aprendermeló.

Soy un zorrinito web.

(Read more →)

Métricas de code review

En estos días me encuentro desarrollando técnicas para la automatización y estadarización de resultados de code reviews de los distintos proyectos que estén siendo implementados. La idea es poder tener una idea cuasi-numérica de qué tan bien o qué tan mal está desarrollada una aplicación. Si bien no está decidido y apenas he comenzado con esa idea, estoy seguro que hay muchas cuestiones que sin duda serán ponderadas ahí. Entre ellas: - **Estandarización:** qué tan bien se respeta el estándar propuesto para trabajar (nombres, capitalización, formas en que se conocen distintas clases) - **Arquitectura:** qué tanto se respeta la arquitectura, sea cual sea la utilizada (decidido al comienzo del proyecto) - **Code-coverage:** cuánto código se encuentra cubierto por pruebas de unidad (code-coverage percentage) - **Estabilidad:** cuánto código se encuentra capturando errores que puedan generar y la forma en que los tratan - **Flexibilidad:** cuánto funcionamiento de la aplicación se encuentra parametrizado y cuánto se encuentra cableado en el código o codificado según la lógica del negocio - **Recursos:** cuántos recursos utiliza innecesariamente o aprovecha eficientemente el sistema - **Performance:** de qué forma se realizan ciertas acciones que podrían mejorarse desde el punto de vista de la velocidad y la respuesta al usuario Si bien no tengo mucha idea aún de la forma de evaluarlo, se me estaba ocurriendo basarme en sistemas de scoring estandarizados, como pueden ser el [CCWAPSS](http://ccwapss.blogspot.com/) para seguridad de aplicaciones web, en donde cada criterio a ser tenido en cuenta debe cumplir una serie de requisitos y es evaluado según una serie de preguntas simples que son fáciles de responder para el evaluador. Incluso fantaseaba con llegar a un punto tal en donde esto pudiera automatizarse. Sé que muchas de las cuestiones serán altamente imposible de programar (o al menos, altamente difíciles de llevar a código), pero cuestiones como la forma en que se respeta la arquitectura, la estandarización y el code-coverage son fácilmente codificables para cualquier sistema que con algún u otro medio pueda reconocer el código y tracear dependencias y relaciones. En fin, es un proyecto que apenas está empezando, y no dudo que pueda tener un futuro muy útil. _Soy un zorrinito review._

(Read more →)

Link del día: Web SQL Designer

Paseando por ahí me encontré con un proyecto llamado WWW SQL Designer, que apunta a la creación visual de esquemas de bases de datos, tablas, y relaciones en un entorno visual, enteramente utilizando HTML, CSS y Javascript. Por si fuera poco, en realidad se trata de un proyecto open source, hosteado en una de las páginas de Google Code. Desde allí puede bajarse e instalarse en algún sitio local para que utilicen quienes tengan acceso a ese servidor.

Soy un zorrinito web.

(Read more →)

ASP.NET MVC 1.0 Release Candidate

Hoy anduve probando esta publicación de Microsoft que pueden descargarse gratuitamente desde [aquí](http://go.microsoft.com/fwlink/?LinkID=141184&clcid=0x409), disponible para VS 2008. Estaba siguiendo las indicaciones que mostraban más que nada las nuevas features, que leí en [Scott's Blog](http://weblogs.asp.net/scottgu/archive/2009/01/27/asp-net-mvc-1-0-release-candidate-now-available.aspx), pero imagino de todos modos que el [sitio oficial de ASP.NET MVC](http://www.asp.net/mvc/) estará lleno de tutoriales y explicaciones al respecto. La instalación es totalmente indolora, tan natural como el típico "Acepto, siguiente, siguiente" y el instalador se encarga de todo por nosotros. Fuera de eso, la integración a VS 2008 se hace a través de un nuevo project template, en este caso, el ASP.NET MVC Web Application, que ya incorpora cierta estructura que incluye una definición de Master Pages. También se encuentra muy organizado el proyecto, separando obviamente Views, Controllers y Models, pero incluyendo además una sección en donde organizar la estructura de nuestro sitio web, como puede ser la sección de Scripts, Content, o (de forma opcional) Code Templates, que nos permiten extender y modificar el comportamiento por defecto para la generación de muchos elementos. Con algunas primeras pruebas y experimentaciones, pude ver que realmente es muy ordenada la forma en que está pensado para trabajar, y que en muchos aspectos respeta la esctructura de MVC, incluso en muchos aspectos no permitiéndonos saltar el esquema de trabajo para que todo se haga - por decirlo de alguna forma - de la manera que debe hacerse. Esto, si bien quita un poco de flexibilidad, garantiza una buena manutención del código. Me gustaría poder opinar en términos de performance, pero el haber efectuado pequeñas pruebas no me da mucha evidencia de algo que marque realmente una diferencia. Personalmente no noté mucha distancia en tiempos de lo que tardaría un sitio diseñado con algún otro patrón, pero sí entiendo que existe mucho procesamiento de fondo que está siendo hecho, excepto que para algunos casos se esté cacheando mucho de la solución en sí. Más allá de eso, es altamente reconocible el trabajo que han hecho para que el programador pueda llevar a cabo el proyecto con código muy entendible, y, lo más interesante, con muchos templates que le hacen el trabajo muy rápido y dinámico. De esta forma, el programador puede concentrarse por "enlazar las partes", y programar tanto la lógica como la forma que debe verse y tratarse los datos, más que en pelear con las bases de datos, con cuestiones de diseño de objetos y demás cuestiones que no hacen a la funcionalidad final. En fin, me parece una buena aproximación, aunque por alguna razón se siente que no está totalmente orientado a eso todavía, puesto que muchas de las features no funcionaron o se encuentran algo defectuosas todavía... pero recordemos que nos encontramos en una release candidate y no en una versión final. _Soy un zorrinito MVC._

(Read more →)

Problemas con el feed

Para aquellos que me seguían a través de algún feedreader habrán notado que de golpe no hubo más actualizaciones (o, de otra forma: “habrán dejado de notar que había actualizaciones”). Esto se debía a un problema de configuración que surgió un tiempo después de que reconfiguré los subdominios… el por qué, no lo tengo claro todavía, ya que con el subminio nuevo ya había entradas y estaban correctamente publicadas.

Ahora supongo que es cuestión de tiempo para que todos los feeds que quedaron apretados esperando salir aparezcan en sus correspondientes lectores. Posiblemente tengan un rato para leer. Ojalá lo disfruten.

Soy un zorrinito con problemas.

(Read more →)