JAVA 4 Ever

Muchos se van a identificar con el niño de este video

Considerado una obra maestra por el padre de Java James Gosling

El peor de los PK2

No es un nuevo Framework para programar, no es una herramienta para el bug del Y2K.

Es solo un acrónimo de 3 letras para designar algo que, si fuera creyente, pensaría que es malo.

Creyentes o no, el termino es muy familiar e incluso la acción para algunos es mas familiar que para otros.

Quien no ha cenado,cuando dijo estar a dieta?, quien no ha entrado al Facebook por vigésima vez en el día para enterarse de los acontecimientos (chismes) de sus conocidos?, en fin, la lista de PK2 diarios puede seguir...

Cual sera el peor de los pecados?? los invito a descubrirlo en el siguiente libro:

http://www.elsiglodetorreon.com.mx/noticia/526612.html

Look de Sebastien Tellier

Una canción que se antoja para acompañar un paseo de media tarde en un dia de primavera



Un estilo desenfadado y ligero,muy parecido a ciertos acordes de Alan Parsons Project

Invitación plática "Patron Facade: Implementacion mediante WCF"

Dentro de las actividades de la Sociedad de Estudios en Computación de la UACJ (SEC), se realizan pláticas de temas técnicos enfocadas a compartir conocimiento y exponer temas relacionados a la tecnología, principalmente en las áreas de TI.

Este viernes me toca participar con un tema de Arquitectura de Software, el cual lleva por titulo "Patrón Facade: Implementacion mediante WCF" 

La plática se llevará a cabo en la UACJ, en el Instituto de Ingeniería y Tecnología. La cita es este viernes 23 de Abril a las 18:00 en el Audiovisual del Edificio E.

El temario de la platica es el siguiente:

• Que es un patrón
• Que es un patrón de diseño
• Usos
• Ventajas de su uso
• Antipatrón
• Tipos de patrones
• Ejemplos de patrones
• Singleton
• Proxy
• Observador
• Decorador
• Facade (Fachada)
• Que es WCF
• Ejemplo práctico del patrón Facade con WCF

Entrada libre, los espero!

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

No me gusta el código comentado

Esta entrada trata sobre una mala practica de programación que afortunadamente esta quedando en desuso, al menos por los buenos programadores.

Me refiero al famoso código comentado, que no es lo mismo que documentar código, en términos prácticos el código comentado es basura, son líneas que a nadie benefician y que si perjudican mucho al momento de dar mantenimiento a un sistema.

Imaginemos que un escritor esta escribiendo (valida la rebuznancia) un nuevo libro, para llegar a la versión final tiene que pasar por numerables etapas, muchos ensayos, muchos borradores; tiene que pasar por la revisión de mucha gente antes de ser publicado. En este proceso creativo el escritor va a transformar su idea, escribir y reescribir una y otra vez líneas y líneas que se irán quedando en papeles hechos bola en la papelera.

Te gustaría comprar un libro y que traiga 3000 hojas, de las cuales solo la mitad sea contenido?, y que las otras 1500 sean anotaciones, versiones preliminares, apuntes, borradores, calis de ese libro que tanto esperas leer??

En lo personal no me gusta leer escritos que contengan mas basura que contenido, para ejemplo un boton.

El código comentado es así, son vagas ideas de un monstruo llamado código, que espera ser completado. Haciendo a un lado la poesía técnica, el código comentado es la punta del iceberg, si hay código comentado, significa que hay un problema de fondo mas grave.

Para algunos quitar el código comentado es mera estética, para otros(principalmente para quien no hizo el código) es una tarea necesaria antes de cada entrega (release), ya que es difícil trabajar con código basura.

Por lo general el desarrollador deja sus migajas en los programas por varias causas:
• Pereza
• Falta de profesionalismo
• Carencia de procesos de calidad
• Tiempos de entrega apretados
• Desconocimiento
• Y en algunos casos soberbia (El clásico “Yo si entiendo mi código”)

Como programador es tu responsabilidad generar buen código, recuerda que tal vez mañana (Sonó a canción) tus líneas, las va a leer Apu en Bangalore y al verlo dira: यह क्या है?

Me gusta el código comentado /* Y que */

//SIG=11dsqp54d\/*-//http:\/\/video.search.yahoo.com\/search\/video"},"shopping":{"button":"Shopping //Search","action":"http:

Esta entrada trata sobre una mala practica de programación que afortunadamente esta quedando en desuso, al menos por los buenos programadores.

/* Esto no es codigo, es solo un recordatorio de que hice algo mal y deje evidencia

Tambien es la evidencia de mi trabajo, es como la papelera de un genio que siempre

esta llena antes de que llegue a la conclusión de una gran idea. Solo que yo, acompaño la idea con la papelera.

Ademas debo dejar mis cambios anteriores y como no conozco herramienta para versionar el codigo, prefiero dejarlo comentado, por si se ofrece después

Incluso puedo poner la lista del mandado, mis conversaciones del Messenger, letras de canciones */

//Un limon, medio limon, 2 limon, medio limon,….

//

// Puedo dejar lineas en blanco comentadas, todas las que quiera

//

//

//Al cabo no importa, el compilador no las lee, las ignora cuando hace su trabajo

Me refiero al famoso código comentado, que no es lo mismo que documentar código, en términos prácticos el código comentado es basura, son líneas /*Incluso puede estar en cualquier lugar */que a nadie benefician y que si perjudican mucho al momento de dar mantenimiento a un sistema.

/* static void CopyObject(SampleClass original)

{

if (original == null)

{

throw new System.ArgumentException("Parameter cannot be null", "original");

}

}*/

Imaginemos que un escritor esta escribiendo (valida la rebuznancia) un nuevo libro, para llegar a la versión final tiene que pasar por numerables etapas, muchos ensayos, muchos borradores; tiene que pasar por la revisión de mucha gente antes de ser publicado. En este proceso creativo el escritor va a transformar su idea, escribir y reescribir una y otra vez líneas y líneas que /* Se pueden camoflajear como lineas validas */ se irán quedando en papeles hechos bola en la papelera.

/*{"props":{"crumb":"O2oDA5QWh6WWpHcTlLY3U.","libRoot":"http:\/\/l.yimg.com\////a\/lib\/","proxyUrl":"\/proxy","ultSpaceId":"2023538075","ultBeaconHost":"\/p.gif","re///questUrl":"\/js","comboRoot":"http:\/\/l.yimg.com\/a\/combo?","sdaRequestUrl":"\/sda2//","passthru":"","proxyTimeout":15000,"modChromeHtml":"_{view_name}\">{html} <\/div>\n */

Te gustaría comprar un libro y que traiga 3000 hojas, de las cuales solo la mitad sea contenido?, y que las otras 1500 sean anotaciones, versiones preliminares, apuntes, borradores, calis de ese libro que tanto esperas leer??

/* El concepto de culpa y de castigo, comprendida la doctrina de la gracia, de la redención, del perdón- todas las completas mentiras privadas de toda realidad psicológica- fue inventado para destruir en el hombre el sentido de las causas; fue un atentado contra la noción de la causa y efecto! */

El código comentado es así, son vagas ideas de un monstruo llamado código, que espera ser completado. Haciendo a un lado la poesía técnica, el código comentado es la punta del iceberg, si hay codigo comentado, significa que hay un problema de fondo mas grave.

Para algunos quitar el código comentado es mera estética, para otros (principalmente para quien no hizo el código) es una tarea necesaria antes de cada entrega (release), ya que es difícil trabajar con código basura.

Por lo general el desarrollador deja sus migajas en los programas por varias causas:

• Pereza
• Falta de profesionalismo
• //Porque no afecta la funcionalida!!, de todos modos compila
• Carencia de procesos de calidad
• Tiempos de entrega apretados
• Desconocimiento
• Y en algunos casos soberbia (El clásico “Yo si entiendo mi código”)
• //Porque si

Como programador es tu responsabilidad generar buen código, recuerda que tal vez mañana (Sonó a canción) tus líneas, las va a leer Apu en Bangalore y al verlo dira: यह क्या है?

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

Cuantas veces hemos escuchado que nos digan, ser dicha o decir la siguiente frase “No te lo tomes personal”

Por lo general esta gastada frase se aplica en el entorno laboral, familiar, fraternal, de pareja, es decir, en todos lados.

En una sociedad impersonalizada como la actual, es común ver mensajes, dedicatorias e invitaciones aparentemente “personalizadas”, nada mas falso que eso, para muestra basta un spam. Quien no ha recibido un mensaje como este:

O una tarjeta de felicitación electrónica por tu cumpleaños, de esas que llegan automáticamente por el simple hecho de que agregaron tu dirección electrónica a un servicio como Sonico. Son bienvenidas, pero no tanto cuando dicen: “Feliz Cumpleaños/Santo/Graduación/Boda Amigo(a) Fulano_De_Tal:”

La impersonalizacion es lo de hoy, los medios masivos, la aldea global (termino acuñado por Marshall McLuhan), nos orillan a ver cada vez mas normal este fenomeno social.

Creo que estamos en un tiempo de la historia que se podría definir como impersonate=true

Esta idea surgió porque hace tiempo vi una línea de código similar en un sistema al cual le doy mantenimiento. Pasando al tema técnico veamos cuando y para que se usa la impersonalización

Al ritmo de Benny Benassi

Every single day, repitiéndolo una y otra vez Dhany, una muy buena rola, que tal vez no fue inspirada para inspirar sino para bailar, pero en este día de mis 30 años, me llego una breve corriente de inspiración.

Como buen dependiente de la tecnología, escucho la canción directamente de youtube, desafortunadamente mi laptop no tiene 2 monitores (como en el trabajo), de tener un monitor extra estaría con un ojo al gato (este escrito) y otro al garabato (viendo el video), y tal vez pecando de “multitasking”, leyendo la letra de la canción para tratar de cantarla. Pero como no es el caso, alternare con ALT+TAB para medio ver el video, medio escribir y medio cantar. Otra opción seria ordenar mis ventanas en horizontal o verticalmente, pero en lo personal creo que se pierde amplitud, en una ventana medio abierta nunca se ve bien, es como cuando la vecina se asoma por la cortina.

Y hablando del multitasking, sin meternos en cuestiones de doble core o aplicaciones multithread y pese a ser hombre (las mujeres tiene un cuerpo calloso mas grande), veo que el multiproceso es algo inherente al ser humano, esto debido a la forma en que se procesa la información en el cerebro. Sabemos que no hace un procesamiento rápido, pero si lo hace en paralelo, ahí radica la maravilla, millones y millones de neuronas comunicándose a cada instante, algo parecido a las nueva maravilla de procesamiento llamada Roadrunner de IBM, con la pequeña diferencia de que el cerebro piensa, tiene conciencia y millones de años de evolución de ventaja.

Y agrego una tarea mas a mi lista, ahora bailo en mi asiento al ritmo del Trance…

El futuro de C# (1/2)

Feliz decimo aniversario

Hace 10 años, mientras el lenguaje Java crecia sano y se posicionaba como un excelente lenguaje de programacion, Microsoft decidio no seguir perdiendo terreno y se  "inspiro", por decirlo de alguna forma, en java para sacar a la luz un nuevo lenguaje de programacion: C#.

En esta decada C# ha nacido, crecido y esta entrando en una etapa de madurez, su hermano mayor (java) le lleva buen camino recorrido y le va dejando sus experincias en el camino, las cuales habilmente Microsoft les ha puesto envoltura y las ha vendido como ideas originales.

Con lo anterior se establecen 2 bandos de desarrollo bien definidos: .Net con su estrella C# y Java, ambas ramificaciones provienen del mismo tronco, tiene un mismo origen, es escencia son hermanas y como en todo, hay veces que una de las hermanas es mas guapa, pero la otra es mas inteligente. En este caso la Orientacion a Objetos fluye por las 2 ramas.

De Pascal a C#

Nos han platicado que Blaise Pascal es uno de los padres que donaron su ADN para dar vida a la computacion actual. Y efectivamente, fue tal su influencia que hace algunos años (casi 50) se creo un lenguaje de programacion con su nombre, el Pascal, cobro mucha fuerza en las escuelas como herramienta para aprender programacion, y creanlo o no, al menos en Cd. Juarez, algunos maestros los siguen enseñando.

En la decada de los 80's en joven programador Anders Hejlsberg creo un compilador para Pascal, lo cual fue su carta de recomendacion para ingresar a Borland donde creo Turbo Pascal convirtiendose en el desarrollador insignia de Broland.

Dicho talendo llego a los oidos de Microsoft quien despues de hacer muchas ofertas le llego al precio a Anders, en 1996 se integro a las filas de Microsoft teniendo como primera asignacion la creacion del lenguaje J++. Actualmente es el arquitecto principal del lenguaje C#.

Queria platicar del futuro de C# y termine hablando de su pasado y origienes, pero como es regla y sin afan de sonar como el brujo mayor  "para entender el presente y predecir el futuro, es necesario conocer el pasado"

Google Chrome (2/2)

Goliat vs Goliat

Segun las guerra de los navegadores (browser wars) hasta antes de la liberacion de Chrome el pastel se repatia asi: 50.5% Microsoft 5.7% Apple 43.7% Mozila. Despues de Chrome segun W3Schools las cosas no cambiaron mucho 48.6% Microsoft 4.7% Apple 42.6% Mozila y Chrome se gano su 3.1%.
Se espera que Google compita con todo para quitarle una buena rebanada principalmente a Microsoft. Esta se antoja que sea una pelea de Goliat contra Goliat, ambos son gigantes y en veces algo torpes.
Algo que me llama la atencion es que despues de 2 meses de su lanzamiento, Google se ha mantenido muy discreto en cuanto a Chrome, sera que esta tramando algo??

Mas vales Beta... que malos comentarios

El 2 de Septiembre se lanzo en 43 idiomas la version Beta para Windows, las versiones para Linux y MacOS aun esta en desarrollo. Al parecer la politica de liberacion de software de Google implica que todo producto vaya acompañado por la palabra Beta. El grupo de CM (Configuration Management) de Google sabe muy bien que hacer un release de una version Beta tiene sus ventajas:

• Si algo falla, no problema... es beta
• Mantiene la espectativa constante en el usuario ("Si esta es la version Beta, imaginate lo que va a venir en la version buena")
• Tener un ejercito de testers (usuarios) de a free reportandote animosamente los defectos encontrados.
• Deslindarse de cualquier responsabilidad en caso de alguna falla, las versiones Beta se usan baja tu propio riesgo

Tambien hay que comentar que ha pasado los test Acid1 y Acid2 con buena calificación (un 79/100) comparada con otros navegadores, nada mal para el nuevo alumno de la clase. Todavía le falta pasar la prueba Acid3

Les dejo el video promocional, los mismo de la historieta, pero con los personajes reales