La generación de los 8 bits

Alguna vez jugaste al invaders?, sabes porque mario bros es un Plomero italiano? y que decir del famoso Pac-man.

Como unos cuadros, rectangulos y barras, nos podian mantener entretenidos por horas; como un juego ruso conquisto el mundo entero? porque tetris al reves se dice triste?

Recuerdo a la ranita que queria pasar la calle y que tu mision era que no la atropellaran, era un juego cruel, sobre todo cuando atropellaban a la rana.

Asi es, todo esto fue gracias a los famosos 8 bits, tal vez suena poco 8 bits, sobre todo ahora que las tarjetas de graficos permiten tener representaciones de 32 bits.

El Plomero bigotón

Cuenta la historia, que la decisión de que Mario fuera un plomero obedeció a razones técnicas. En realidad el diseño de Mario no era así, si iba a ser Italiano, pero no plomero.

Le pusieron guantes porque con 8 bits no se podían representar con finura los dedos de la mano, le pusieron bigote porque nuevamente con 8 bits, no se podía representar la boca. Lo mismo paso con el cabello y optaron por ponerle gorra. Entonces por consiguiente alguien bigoton, con guantes y gorra solo podria ser un plomero.

Los detalles finos de la vida

Con 8 bits se tiene la opción de representar 256 colores, es decir 2 a la 8va. potencia, en cambio con 16 bits los colores que se pueden representar sube a  65536.

El ojo humano no percibe colores, percibe solo longitudes de onda, hay 3 principales logitudes que corresponden a los 3 colores primarios (azul, verde y rojo) el ojo los mezcla y de esta forma representa todos los colores. Este es el principio basico del color, te suenan las siglas RGB. 

Y cuantos colores puede percibir el ojo humano?, varia de una persona a otra, pero el promedio aceptado es que podemos percibir 18 bits de color, algo así como 262,144 colores. 

Con tantos colores disponibles y en ocasiones nos movemos en un espectro tan pequeño, hay veces que la vida se pone color de hormiga (les debo la combinación RGB de este color), algunos ven la vida de color de rosa, algunos les gusta el humor negro, los chistes blancos, los hay rabos verdes, a otros les cuesta tener azul celeste o que pasa cuando te piden que pongas la situación en blanco y negro?

Somos la generacion de los 8 bits, donde el ingenio era mas importante que los efectos, que las texturas, que la velocidad de procesamiento o el 3D. Donde se cimentaron las bases de la animacion, del arte digital y de tantas maravillas que ahora vemos tan comunes. 

Mensaje de graduación

Les comparto este mensaje que Steve Jobs a una generación de graduandos de Stanford



muy inspirador

Recuerdos

Hay tantas cosas que se quedaron guardadas, tantas cosas que me hubiera gustado escuchar, aprender y reflexionar.

Aunque no tengo una memoria digital, tengo en mi mente recuerdos tan nítidos como ese árbol de navidad que cobijaba nuestros regalos, o como el naranjo que daba naranjas tan agrias como limones, pero que era nuestra proeza poder cortarlas.

Adonde va la mente?, puede ir a algún lado? o es una cantera que se desvanece con el paso de las generaciones

Una neurona se ha extinto en el inmenso mar de la eternidad...

Hasta siempre Abuelita Tomi

No te lo tomes Im-Personal (impersonate=true) Parte 2/2

Antes de entrar de lleno a lo que es la impersonalización, hay que comentar algunas cosas básicas sobre la configuración de los sitios web (al menos con .Net)

Hay un archivo XML llamado Web.Config que es donde se definen/guardan las configuraciones de las aplicación asp.net. aquí es donde se especifica la impersonalización.

Por otro lado, podemos configurar el comportamiento del Framework de .Net en el servidor, para eso tenemos un archivo muy machín, el archivo Machine.config. Pero aguas!!, las configuraciones que hagamos en el machín, van a afectar a TOOODAS las aplicaciones .Net que estén alojadas en el servidor.

Me llega a la mente la primicia de Homero Simpson, “si no está quebrado, no lo repares”. Si no sabes para que sirve una configuración, por favor, por lo que más quieras… No le muevas!! 

Que es la impersonalización (Hablando de sitios web)?

Las aplicaciones web necesitan accesar a recursos, entiéndase archivos, servicios del sistema operativo, web services, archivos, carpetas, etc. Este recursos no está accesibles a todo el mundo, por seguridad están restringidos y se requiere tener permisos para poder usarlos.
Como hacerle para que una aplicación web que está expuesta a sin número de ataques e intrusiones pueda utilizar recursos tan sensibles como DLL del sistema operativo?

En las aplicaciones que comúnmente llamamos desktop o cliente servidor, para usar la aplicación te tienes que loguear al sistema operativo, por lo tanto la aplicación corre con los permisos de un usuario autentificado por el sistema operativo y por lo tanto tiene permisos para usar los recursos de la maquina (salvo que ingreses como invitado)

Las aplicaciones web no cuentan con un usuario autentificado por el Sistema Operativo,  de hecho como están al alcance de todo el mundo, pueden ser accesadas por personas que no están en nuestra red, en nuestro idioma, en nuestro país, en nuestro planeta (exagere un poco).

Y volvemos a la pregunta, como le hacemos para que cualquier usuario de nuestro sistema web tenga permisos para usar recursos, sin comprometer la seguridad?

Hay 2 formas: El Usuario .Net y la Impersonalización

Como implementar impersonalizacion?
El usuario .Net .- En Asp.Net todas las aplicaciones utilizan un usuario para iniciar, dicho usuario se configura en el archivo Machin del que hablamos allá arriba.

Cada vez que alguien se conecta a la aplicación aumenta el consumo de recursos de ese usuario (léase memoria)

La bronca aquí es que, ese usuario se va a poner muuuy choncho, lo cual no es bueno para el performance de la aplicación y por otro lado ese usuario omnipotente tendría acceso a todos los recursos, lo cual es poco recomendable ya que cada recurso debe tener sus propias restricciones. Por ejemplo no son los mismos permisos que se necesitan para crear un archivo en un folder que ejecutar un CLR en la Base de datos.

Y otro problema es que se tiene un solo usuario para todas las aplicaciones web que estén alojadas en el servidor.

Impersonalización.- La opción B implica que cada aplicación web, cuenta con su archivo de configuración (web.config), dentro de este archivo definimos un usuario con el que se va a conectar la aplicación.  Se agrega una llave al XML en la sección de Identity

<identity impersonate="true|false" userName="username" password="password"/>

Por lo anterior la aplicación se ejecutara bajo el contexto de la identidad del cliente que esta accesando la aplicación.

La cuenta de ASPNET de Windows es usada para accesar recursos de ASP.Net a través del el llamado Worker Process (Aspnet_wp.exe). Esta cuenta esta limitada, en comparación con la cuanta de invitado de Internet (IUSR_ NombreComputadora), la cual se usa por el ASP clásico. 

En ciertas ocasiones se quiere que la aplicación sea ingresada por medio del usuario anónimo IUSR_NombreComputadora, en esos casos se configure la impersonalización, pero sin poner el usuario, los cual le indica al IIS que debe utilizar el usuario anónimo:

<system.web/>
<identity impersonate="true"/>
</system.web/> 


En cambio si se quiere usar un usuario especial, solo basta con especificarlo en la llave del Identity:

<Identity impersonate=”true” 

userName=”misuariodeejemploparaelblog”
password="mipassworddelusuariodeejemploparaelblog " />

Riesgos de impersonalización de sitios web

• La impersonalización puede afectar significativamente la escalabilidad (ni que fuera montaña) y performance de una aplicación. Nos sale más caro hacer la llamada a un recurso por medio de la impersonalización que hacer la llamada o el uso directamente. Se gana en seguridad pero se pierde en uso de recursos.
• Otro detalle es que la impersonalización corre en forma local y sobre un hilo de ejecución. Cuando el código cambia de hilo, por ejemplo cuando se tiene un pool de hilos de ejecución, por default los hilos nuevos se ejecutan usando el identity, es decir, ya no usa el usuario de la impersonalización. Como sabemos el manejo de hilos de ejecución no es cosa sencilla, hay que tener vastos conocimientos sobre hilos e hilasas.
• La impersonalización esta deshabilitada por default, esto es para tener compatibilidad con ASP (el antiguo) y para no vulnerar la seguridad de los sistemas.
• Hay que tener cuidado al usar impersonalización, ya que permite que una aplicación ejecute código usando permisos no vislumbrado originalmente por el programador, aguas con esto.
• Se tiene que poner en el web.config el usuario y el password, dejándolo accesible a cualquier persona que tenga un notepad para abrirlo.

Test Driven Development: Pruebas de Software a priori

En Abril del 2007 di una platica en la UACJ que llevó el mismo título de este post.

Dicha plática se dio dentro de las actividades de la Sociedad de Estudios en Computacion, sociedad que liderea el profesor Saúl González.

Desempolvé este tema porque veo útil mostrar lo que es TDD (Desarrollo Orientado a Pruebas) y cómo TDD ayuda al desarrollo y al mantenimiento de un sistema. Tradicionalmente las pruebas de una aplicación  representan una tarea monótona y talachera  (entiéndase manual, repetitiva y sujeta al error humano).

Pones a un equipo de monos a ejecutar Test Cases y que Dios nos agarre confesados!!, la idea es que hagan pedazos la aplicación, la idea es que encuentren cual Sherlock Holmes todos los bugs habidos y por haber. Lo cual en la práctica, no es una tarea sencilla, depende de la pericia del tester, depende de que tan bien estén diseñadas las pruebas, depende de muchos factores.

En sistemas complejos, lo que más quieres es controlar esos factores, con TDD puedes controlar que las Pruebas Unitarias se cumplan, las cuales son un factor crucial en los sistemas diseñados bajo el Paradigma de Orientados a Objetos.

Que es TDD?

Es una metodología de desarrollo de Software que consiste en implementar las pruebas unitarias antes de comenzar a escribir el código de un modulo

Las pruebas unitarias consisten en comprobaciones (manuales o automatizadas) que se realizan para verificar que el código correspondiente  a un modulo concreto de un sistema funciona de acuerdo con los requisitos del sistema.

Ø  Tradicionalmente las pruebas se realizan a posteriori, es decir, después de codificar la funcionalidad

Ø  En TDD, las pruebas se preparan antes de comenzar a escribir el código

Primero se escriben los casos de prueba y después se implementa el código necesario para que la prueba pase con éxito

Por lo general las pruebas son métodos que ejecutan una acción específica, por ejemplo:

•         CrearUsuario()

•         CalcularArea()

•         BloquearPassword()

•         BorrarFactura()

•         SacarLaBasuraPorLasMañanasAntesDeQuePaseElCamionRecolector()

Tipos de pruebas

Hay muchas pruebas que se le pueden (deben) hacer al software antes de liberarlo. De otra forma la calidad no va a estar garantizada. Hoy en día nadie se pondría una vacuna que no paso por años de pruebas, sin embargo en la industria de software aun hay Cromañones que no les cae el veinte con esto de las pruebas.

Existen varios tipos d pruebas, por citar algunos:

•         Pruebas de usuario

•         Pruebas cruzadas

•         Pruebas Unitarias

•         Pruebas de regresión

Que son las pruebas Unitarias en TDD?

En TDD una prueba unitaria no es otra cosa que código que permite probar los módulos mediante condiciones de prueba.

Las pruebas son diseñadas por el desarrollador y por los expertos del negocio. Estas pruebas se pueden automatizar usando una herramienta como NUnit. Una ventaja de automatizarlas es la posibilidad de lanzar las pruebas tantas veces como sean necesario. En caso de haber cambios en la funcionalidad al correr la prueba se puede verificar si se siguen cumpliendo las reglas de negocio de los objetos.

Ventajas de usar TDD

•         Al escribir primero los casos de prueba, definimos de manera formal los requisitos que esperamos que cumpla nuestra aplicación. 

•         Al escribir una prueba unitaria, pensamos en la forma correcta de utilizar un módulo que aún no existe.

•         Se puede automatizar la ejecución de los casos de prueba (por ejemplo, con ayuda de algún framework de pruebas como NUnit)

•         Los casos de prueba nos permiten perder el miedo a realizar modificaciones en el código.

•         Los casos de prueba definen claramente cuándo termina nuestro trabajo (cuando pasan con éxito todos los casos de prueba)

•         Se puede obtener un avance real de la fase de contruccion, basándonos en el code coverage 

•         Esta práctica es compatible con el Desarrollo Agil (Agile Development).

•         TDD permite fácilmente la refactorización.

•         TDD fomenta la disciplina del equipo de programación

Proceso de desarrollo con TDD

•         Escribir solo el código necesario, que cumpla con la funcionalidad requerida.

•         Pasos de este proceso:

–        Diseñar las pruebas unitarias

–        Escribir el esqueleto de los modulos (o clases) necesarios para la prueba

–        Escribir las pruebas unitarias

–        Ejecutar las pruebas unitarias

–        Codificar los mínimo requerido para que pase cada prueba unitaria asociada a un modulo.

–        Ejecutar la prueba y verificar que pase correctamente.

–        Iterar

Herramientas para hacer pruebas automáticas

•         Existen un número considerable de herramientas que nos pueden ayudar para automatizar las pruebas unitarias.

•         Usualmente son frameworks que permiten rápidamente escribir “código que prueba código”.

•         La elección de la herramienta dependerá de la naturaleza del proyecto.

•         Algunos de los más conocidos son:

–        Microsoft Team System

–        NUnit

–        MbUnit

–        JUnit

–        csUnit

–        TBrun

–        XTest

–        y muchos mas

Limitaciones de TDD

Hay que tener precaución al decidir cuándo usar TDD. No es recomendable usar TDD cuando:

• Por la naturaleza de la aplicación  no sea factible automatizar las pruebas
• No se tenga un conocimiento solido de la Programación Orientada a Objetos (no es suficiente usar lenguajes orientados a objetos, hay que pensar en objetos)
• El equipo esté formado por desarrolladores poco experimentados. Se requieren fuertes habilidades técnicas y de análisis para producir buenas pruebas.
• Los requerimientos no estén definidos en forma clara.
• No se cuente con expertos en el negocio dentro del equipo
• Exista mucha rotación de personal en el equipo

Si aplicas mal o a medias TDD puedes encontrarte los siguiente problemas:

•         Generar pruebas mal diseñadas que no te sirvan para determinar si tus objetos tienen el comportamiento esperado.  La calidad de la prueba depende del conocimiento del desarrollador.

•         Se puede invertir mucho tiempo en hacer pruebas y dejar corta la fase de construcción.

•         Diseñar pruebas poco representativas, que no cumplan con un code coverage que en algún momento dejen de usarse

•         Invertir mucho tiempo en hacer las pruebas y no darles mantenimiento, lo cual representa un gasto inútil de tiempo.

Google Chrome OS

La Union Europea esta enfrascada en una demanda contra Microsoft por integrar Internet Explorer a su Sistema Operativo, lo cual va en contra de la libre competencia.

Y me pregunto, le lloverán demandas a Google por integrar su Sistema Operativo a su Navegador??

Por lo pronto, si me gustaria que mi computadora inicie en 7 segundos

Disparar y avanzar

Acabo de leer un post de Joel Spolsky, un cuate que tiene una pequeña compañía de software en New York y que tiene mucha razón en lo que escribe.Su post es muy recomendable porque refleja cosas tan cotidianas que siempre nos preguntamos los desarrolladores:

• Porque en veces no me concentro para programar?
• Porque me concentro cuando ya es la hora de salida?, jaja, típico
• La programación requiere mas inspiración que transpiración?
• Es posible trabajar 40 horas a la semana sin comprometer el rendimiento y los entregables?
• Ganará algún partido los Indios de Juarez esta temporada?

Y también habla de cosas tan profundas como las estrategias comerciales, que pueden llevar a una empresa a la quiebra o al crecimiento. Incluso estrategias que van fijando el rumbo de la tecnología misma.

Me gusta la analogía que hace entre las estrategias militares y la industria del software, el mundo del software esta íntimamente ligado con estas estrategias. Seguramente han escuchado el principio de Divide et vinces (Divide y vencerás), frase que le atribuyen al emperador Julio Cesar, algunos manejan que Maquiavelo la adopto en su libro El Príncipe.

Esta máxima se usa en algoritmos de recursividad, que consiste en dividir un problema en partes mas chicas, las cuales son mas manejables y fáciles de resolver. Como se dice vulgarmente “Si el marrano esta muy grande, hay que hacerlo carnitas”

Regresando al post de Spolsky, plantea que en la industria del software hay que “Disparar y avanzar”, para no perecer en el camino.

Les ha pasado que quieren implementar muchas mejoras en su proyecto, las cuales les facilitarían la vida enormemente y que no las implementan porque se la pasan resolviendo problemas cotidianos, amoldándose a nuevos estándares, ajustándose a nuevas tecnologías, etc.?

Lo anterior es síntoma de que estas recibiendo mucho “fuego enemigo”, te la pasas cubriéndote de las balas, y se te va el tiempo en atender lo que la competencia te dicta.

Cuando no se esta a la vanguardia y se trabaja siempre en la retaguardia, se corre el riesgo de que el “enemigo” (la competencia), dispare y avance sin encontrar ninguna resistencia. No les digo mas, vale la pena leerlo:

Versión original en Ingles

Versión traducida al Español