Link del día: Genetic Algorithms

Recuerdan que en algún caso publiqué una introducción a algoritmos genéticos (que incluía visualizaciones gráficas y todo)? Bueno, varios luego de ver eso me preguntaron “Y esto para qué sirve?” y aparte de la chorrera de palabras que habré largado, poco convincentes, hoy publico también 15 Real-World Applications of Genetic Algorithms.

Por si fuera poco, me animo a publicar otra introducción más al tema, llamada Genetic Algorithms: Cool Name & Damn Simple y otra más: Introduction to Genetic Algorithms, y a republicar el autito generado con algoritmos genéticos, o la evolución de la Mona Lisa.

Soy un zorrinito genético.

(Read more →)

Testing Flexible | Flexible Testing

Español:

Estos días estuve trabajando en desarrollar un proceso de testing adaptable a empresas que pueden querer tener un ciclo de testing completo (con todo el ciclo de vida del mismo que eso implica) como también tener simplemente un par de días y un par de recursos libres para poder testear. Ante tanta variabilidad, es necesario generar un modelo de testing que sea adaptable y particionable según las necesidades del momento, o según lo planificado con anterioridad.

Para casos planificados, pueden anticiparse testings que comienzan a trabajarse desde los requerimientos del sistema en desarrollo, y pueden incluso seguir el ciclo de vida de desarrollo del software a lo largo del mismo y en paralelo. Este es el famoso modelo en V del ciclo de vida de testing, pero este es el que presenta una gran deficiencia, que es la misma dependencia entre todas sus etapas. Este modelo se ajusta perfectamente a desarrollos con ciclos de vida de cascada, y si bien es fácilmente adaptable a otros ciclos de vida definidos, qué ocurre cuando nuestras etapas no son del todo claras? O peor aún, qué pasa cuando diferentes etapas se mezclan entre sí?

Por supuesto, esta situación no es deseable, pero al momento de darse, también sería deseable que nuestro modelo de testing no sea un contra más en esta situación, sino que permita ser utilizado también para aportar calidad, que es – al fin y al cabo – la finalidad del mismo.

Nuestro acercamiento a dicha tarea fue definir distintos tipos de testing, que variarían según los requisitos que estos tuvieran (documentos en qué basarse, cantidad de recursos necesarios proporcionalmente al tamaño del sistema, tiempo invertido, nivel de capacitación necesaria para los recursos, etc.), y para cada nivel de este tipo de testing, una variante que permitiera evaluar cierto aspecto de un sistema. De esta forma, logramos tener testing que puede ser hasta casi improvisado por los mismos desarrolladores, dejando documentación útil para el futuro del desarrollo del sistema, como a la vez también tenemos testing que puede planificarse desde el comienzo del proyecto y comenzar a trabajarse desde los requerimientos.

Por supuesto, creemos que mientras más haya, mejor, pero esto no es siempre posible, y es una realidad a la que tenemos que mantenernos atentos, porque negarla es condenarnos al fracaso.

Desafortunadamente, no puedo detallar información sobre los tipos de testing que hemos definido (ya que estos son propiedad e información de la empresa), pero los mismos también han sido planeado de un estilo y estructural totalmente formal, de manera que fácilmente puede tercerizarse el trabajo, o realizar testing para terceros de ser necesario o de surgir la oportunidad.

Soy un zorrinito adaptable.


English:

These days I’ve been working on developing a testing process which would be adaptable to companies having a large testing cicle (including the whole life-cycle for testing it implies) as well as companies having just a couples of days they can use for testing and few resources available. On such variability, it was necesary to generate a testing model which would be adaptable and partitionable acording to particular necesities, or according to what can be planned in the project.

For cases where the testing is a planed part of the whole development cycle, testing itself may begin from the requirement specification and may even follow the whole development life-cycle at the same time. This is the famous V-model of testing life-cycles, but this model presents a great deficiency, and it is the same dependency between all of its internal stages. This model adjusts perfectly to developments with waterfall life-cycles and, it is even adaptable to other well-defined life-cycles. But what happens when these life-cycles do not have well-defined stages? Or, even worse, when this stages are sometimes mixed-up?

Of course, this situation is not desirable at all for a project, but, when it is found, it would be desirable that our testing model does not fall with it, but should allow us to be used also to give more quality – i.e., the purpose of it.

Our approach to this task was defining several different types of testing, which would vary from the requirements they had (documents on which to be based on, resources needed according to project size, time invested, knowledge level required for resources, etc.), and for each of these levels of testing, different variants which would allow us to evaluate a certain aspect of a system. This way, we achieved having testing processes which could be improvised by the developers themselves leaving useful documentation for future developments, as well as it could be also used for being planned and start being analyzed by a testing team from the very beggining of the development proces.

Of course, we belive that as more testing, best quality can be achieved, but this is not always posible, and this is a fact we should take into account, as deying it is condemn ourselves to failure.

Unfortunately, I’m not allowed to go into details on about the different types of testing we’ve defined – as they are our company’s property – but these types of testing had been designed with a formal structure and style, so that they can be also used to be outsourced to other testing companies, or that, needed the case, we could be testing another’s company code.

I’m an adaptable little skunk.

(Read more →)

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 →)