Teclado Virtual - HTML + Javascript

Después de 2 meses de no escribir nada, regreso con un "proyecto" que desarrollé en algo de mi tiempo libre.

Consiste en un teclado virtual que se puede implementar en cualquier página Web haciendo uso de simple HTML, CSS y Javascript. Para descargarlo y ver un ejemplo funcionando entren en http://htmlkeyboard.googlecode.com.

El contenido del proyecto está en espanglish, porque lo empecé a desarrollar totalmente en español y luego lo monté en google code, lo que me llevó a traducir algunas cosas pero todavía falta.

Sombras en HTML (Sin imágenes/CSS3)

La sombra puede que no sea una herramienta de diseño importante, pero en ocasiones aparece la necesidad de añadir "algo" al texto. Un ejemplo pueder ser colocar texto sobre una imagen, dependiendo de los colores de la imagen y el texto, sin una sombra el texto puede "perderse".
Cuando uno quiere poner sombras en HTML las opciones son bastante escasas:

• Se podría usar la propiedad text-shadow de CSS3, pero por los momentos esta opción sólo es soportada por Safari.


• Se podría usar el pseudo-elemento ":before" de CSS para duplicar el texto y simular la sombra, pero esto no funcionaría en Internet Explorer.


• Se podría usar un filtro de CSS propietario para que funcione en IE, pero eso sería una solución no estándar y además solo funcionaría en IE.

Si se usa una o varias de las opciones anteriores, la apariencia podría cambiar drásticamente en distintos navegadores. Por los momentos, un código de CSS estándar no nos dará la solución que queremos, pero un poco de manipulación del DOM es exactamente lo que necesitamos.

Primero, el código Javascript que permite que la magia ocurra:

function getElementsByClass(searchClass,tag) {
   var classElements = new Array();
   var els = document.getElementsByTagName(tag);
   var elsLen = els.length;
   var pattern = new RegExp("(^|\\\\s)"+searchClass+"(\\\\s|$)");
   var j = 0;
   for (i = 0 ; i < elsLen; i++) {
      if ( pattern.test(els[i].className) ) {
         classElements[j] = els[i];
         j++;
      }
   }
   return classElements;
}

function sombrear(){
   var aSombrear=getElementsByClass("sombreado","*");
   var total=aSombrear.length;
   for(i=0;i<total;i++){
      objeto=aSombrear[i];
   
      var texto=objeto.firstChild.data;
   
      var sombraSpan=document.createElement("span");
      sombraSpan.appendChild(document.createTextNode(texto));
      sombraSpan.className="sombra";
   
      var textoSpan=document.createElement("span");
      textoSpan.appendChild(document.createTextNode(texto));
   
      objeto.firstChild.data="";
      objeto.appendChild(sombraSpan);
      objeto.appendChild(textoSpan);
   }
}

Ahora el código CSS que nos ayudará a crear el efecto de sombra para el texto:

.sombreado, .sombreado span {position: relative;}

span.sombra{
 position: absolute;
 top: 2px;
 left: 2px;
 color: #b2b2b2;
}

Ahora simplemente creamos un elemento de texto en el documento y le aplicamos la clase de CSS "sombreado".

<h1 class="sombreado">Esto es un título con sombra</h1>

La función de javascript se encarga de

1. Encontrar todos los elementos del documento que pertenecen a la clase "sombreado"


2. Crea dos elementos span, uno para el texto y otro para la sombra


3. Copia el contenido del texto dentro de los 2 span recién creados


4. Reemplaza el contenido original con los 2 span con su correspondiente z orden (sombra, luego texto)

El posicionamiento de la sombra es manejado por la clase .sombra definida en la hoja de estilo. En nuestro ejemplo la sombra está desplazada 2 pixeles hacia abajo y a la derecha.

Es decir, para el ejemplo anterior

<h1 class="sombreado">Esto es un título con sombra</h1>

Se convierte en

<h1 class="sombreado">
 <span class="sombra">Esto es un título con sombra</span>
 <span>Esto es un título con sombra</span>
</h1>

Esto permite crear el efecto deseado sin necesidad de código HTML extra, sin imágenes y que funciona en los navegadores más populares del mercado.

Se puede ver un ejemplo funcionando en http://joserclblogs.googlepages.com/sombras.html

Usar GMail para links de correo en Firefox

En firefox siempre que tratamos de abrir los links a correos se nos abre el evolution (linux) o el outlook (windows) de forma predeterminada, a continuación muestro una manera de hacer que estos links a correos se manejen desde GMail.

1. Primero entramos en la configuración del firefox, para esto escribimos about:config en la barra de direcciones


2. Ahora buscamos la clave gecko.handlerService.allowRegisterFromDifferentHost y cambiamos su valor a True haciéndole doble click.


3. Ahora le indicamos al manejador de protocolos de firefox que agregue a GMail como aplicación copiando lo siguiente en la barra de tareas y presionando enter
   
   
   javascript:window.navigator.registerProtocolHandler("mailto","https://mail.google.com/mail/?extsrc=mailto&url=%s","GMail")
   
   O simplemente hacemos click AQUÍ
   


4. Firefox nos preguntará si queremos agregar a GMail como manejador de protocolos y hacemos click en el botón Añadir aplicación.


5. Ahora tenemos que elegir a Gmail como gestor predeterminado de los links de email. Para eso entramos en Opciones > Aplicaciones, elegimos mailto y seleccionamos GMail como aplicación de correo predeterminada.


6. Por último volvemos a poner el valor de la clave gecko.handlerService.allowRegisterFromDifferentHost en False con doble click.

Hamachi

Hamachi es una aplicación gratuita configuradora de redes privadas virtuales capaz de establecer vínculos directos entre computadoras que están bajo firewalls de NAT sin requerir reconfiguración alguna (en la mayoría de los casos), en otras palabras, establece una conexión a través de Internet para crear un entorno virtual que simula una red de área local formada por ordenadores remotos. Actualmente está disponible la versión para Microsoft Windows y la versión beta para Mac OS X y Linux.^[1]

Pues eso, hamachi permite que los usuarios sin conocimientos técnicos ni nada parecido puedan crear sus propias VPN y conectarse a ellas sin necesidad de abrir puertos en el firewall, enredarse con el NAT ni nada "fastidioso".

El software puede ser descargado de la página oficial y se instala fácilmente, pero esa no es la razón por la que escribo este post, la razón es la creación de un script para linux que permite que hamachi se ejecute como un servicio.

Primero y principal, necesitas poner los archivos de configuracion de hamachi en un directorio global a diferencia de tu directorio /home. hamachi-init crea scripts en el directorio home dentro de una carpeta llamada .hamachi por defecto, pero nosotros especificaremos como directorio de configuración /etc/hamachi. Para esto ejecutamos:

hamachi-init -c /etc/hamachi

Luego necesitamos crear un script para iniciar hamachi, usa el editor de texto de tu preferencia y crea un archivo llamado hamachi-start y copia lo siguiente.

#!/bin/sh

hamachi_start() {
  echo "Starting hamachi..."
  /sbin/tuncfg
  /usr/bin/hamachi -c /etc/hamachi start
}

hamachi_stop() {
  echo "Stopping hamachi..."
  killall tuncfg
  /usr/bin/hamachi -c /etc/hamachi stop
}

hamachi_restart() {
  hamachi_stop
  sleep 1
  hamachi_start
}

case "$1" in
'start')
  hamachi_start
  ;;
'stop')
  hamachi_stop
  ;;
'restart')
  hamachi_restart
  ;;
*)
  hamachi_start
esac

Guárdalo en la carpeta /usr/bin y otórgale permisos de ejecución:

chmod a+x /usr/bin/hamachi-start

Ahora editamos el archivo /etc/rc.local (haz un backup antes de "meterle mano" al archivo)

Al final del archivo agrega las siguientes lineas:

if [ -x /usr/bin/hamachi-start ]; then
 . /usr/bin/hamachi-start
fi

Ahora los comandos básicamente son los mismos con una pequeña diferencia, cada vez que se invoca un comando de hamachi, se tiene que especificar la localizacion del archivo de configuración con la opción -c.

hamachi -c /etc/hamachi set-nick nickname
hamachi -c /etc/hamachi login
hamachi -c /etc/hamachi create nombre_red clave
hamachi -c /etc/hamachi join nombre_red clave
hamachi -c /etc/hamachi go-online nombre_red
hamachi -c /etc/hamachi list
hamachi -c /etc/hamachi go-offline nombre_red

---

^[1] http://es.wikipedia.org/wiki/Hamachi

Correos en formato HTML

Internet es mas barato, rápido, y grande que nunca (y también más peligroso). Mientras que escribir correos en formato HTML es cada vez más usado para mercadeo en masa, también es cierto que: Correos en formato HTML pueden ser peligrosos, no siempre son fáciles de leer y consumen más ancho de banda, en corto, simplemente no son necesarios.

Este artículo no está destinado a presentar un argumento balanceado acerca de las ventajas y desventajas de correos en formato HTML, ni tampoco estoy sugiriendo que los correos HTML harán daño, es más, puede que mejoren las ventas de tu compañía. Sin embargo, recibir correos en ese formato puede causar problemas

1. Los correos en formato HTML son peligrosos
   Casi todos los virus son transmitidos por correo. Cualquier tipo de correo (HTML o texto plano) pueden traer adjuntos infectados pero con HTML hay un riesgo mayor pues algunos virus pueden aprovecharse de ciertas vulnerabilidades en el interpretador de HTML para ejecutar programas tan pronto como el correo se abra en "vista previa"


2. Los correos HTML consumen ancho de banda
   Si uno mira el código fuente de cualquier mensaje HTML, después de los encabezados uno puede observar que el mensaje está escrito 2 veces (sip, 2), la primera vez en texto normal y corriente y la segunda en HTML. Así que la mayoría de los correos HTML son el doble (al menos, pueden ser más) de grandes que el correo en texto plano.
   


3. Los correos HTML no siempre funcionan
   Algunos clientes de correo no muestran bien los correos en formato HMTL, otros simplemente no los muestran.
   


4. Los correos HTML se pueden conectar a internet por sí mismos
   Abrir un correo HTML que contiene imágenes puede (y generalmente es así) abrir una conexión a internet para descargarlas y mostrarlas.
   


5. Los correos HTML se muestran más lento
   Algunas aplicaciones para leer correos se pueden poner más lentas por el sólo hecho de abrir un correo HTML. La necesidad de incluir un interpretador de HTML en la aplicación puede hacer que la aplicación sea más grande y pesada de lo normal.
   


6. Los correos HTML no siempre son fáciles de leer
   HTML permite que el remitente use fuentes pequeñas o fuentes que no son estándar, colores contrastantes, imágenes mal formateadas y a veces no hay una forma rápida y sencilla de leer el mensaje

Enviar correos en formato HTML simplemente no es necesario. Si la apariencia del mensaje es "muy" importante, entonces es mejor colocarlo en un sitio web y mandar por correo el vínculo o salvarlo en un documento de word, un pdf o incluso un archivo comprimido y enviarlo como un archivo adjunto a un correo en texto plano.

Links relacionados:

• http://www.birdhouse.org/etc/evilmail.html
• http://efn.no/html-bad.html
• http://www.georgedillon.com/web/html_email_is_evil.shtml
• http://www.michaelhorowitz.com/bademails.html

Solo una caja y listo...

Quiero una de esas cajas para cuando sea grande...

UML es una basura!

Está bien, una notación gráfica estándar para representar el diseño de software es algo bueno ¿no?, sin embargo UML parece que es lo mejor y lo peor en esta área por unas cuantas razones.

UML perdio a los programadores, no hay duda de ello. Y cuando una tecnología de diseño de software pierde a los programadores se desvanece y no importa lo que piense la academia. UML es muy bonito en papel, pero cuando se empieza a usar se puede observar su mayor falla: se parece mucho a papeleo burocrático y administrativo sin sentido.

A continuación una lista de lo que salió mal en el proceso de adoptar UML como "estándar" de diseño:

1. Redundancia:
   La representación de UML está ligada a un proceso en particular del desarrollo de sofware, por lo tanto, hay diagramas que son similares (diagramas de clase y de concepto) pero cuya mayor diferencia es que simplemente se usan en distintas fases del proceso (análisis y diseño). Inencesariamente redundantes y son tan parecidos que causan confusión.
   
2. (In)Utilidad:
   La utilidad de los diagramas es discutible, no he conseguido nadie que sea capaz de entender un diagrama de casos de uso o un diagrama de clases sin haber estado involucrado en el proceso de creación. Además creo que ningún programador vuelve a ver los diagramas de casos de uso o los diagramas de colaboración una vez que empieza a escribir el código, simplemente escribe el código para que el software cumpla con los requisitos del cliente, no para que el cliente sepa que el código es bonito y está bien estructurado.
   
3. La obsesión de ponerle precio:
   Tratar de vender herramientas costosas por una tecnología que no es lo suficientemente madura (15 años después de su concepción!) y sólo hace promesas a la gerencia (sólo expresa tus ideas en dibujos y el código será generado por nuestra varita mágica) sólo puede funcionar a corto plazo. En algún momento alguien se dará cuenta que los costos son más grandes que los beneficios.
   
4. Trata de guardar todo bajo el colchón:
   Cuando tratas de ofrecer una solución para cualquier problema, al final no estás ofreciendo algo útil para ningún problema. UML trató de resolver todos los problemas relacionados con desarrollo de software. El software es usado o puede ser usado para casi cualquier actividad humana, tratar de capturar todo es una tarea imposible, a pesar de su "capacidad", UML sólo cubre una pequeña parte de la complejidad que necesita la ingeniería de software. Es demasiado grande y a la vez demasiado genérico y abstracto.
   
5. Exceso de conceptos:
   Tratar de incorporar la manera de representar conceptos de todos los lenguajes "de moda" en los últimos 10-15 años y sin embargo nadie sabe como representar una clase interna anónima de Java.
   
6. Siempre estar actualizado:
   Es una continuación del apartado anterior, como siempre se promete que la ventaja es la generación completa de código se tienen que poder representar las construcciones específicas de cada lenguaje. ¿Se podrá lograr en algún momento?
   
7. La necesidad de una herramienta posiblemente costosa vs. un editor de texto:
   El precio para usar UML para más que simplemente compartir ideas en un pizarrón es bastante alto. Las herramientas increiblemente buenas son increiblemente costosas. Además de eso se necesita capacitación y entrenamiento porque no siempre son herramientas intuitivas. Las consultoras adoran estas herramientas porque así abren oportunidades de impartir cursos de capacitación costosos.
   
8. Falta de claridad en el modelo:
   Las imágenes son interpretables. No importa que tan bueno sea el diagrama, tienes que ver el código para realmente entender el qué y el cómo de un determinado programa.
   
9. Falta de soluciones para problemas comunes:
   A pesar de que las especificaciones son enormes, no hay soluciones buenas para problemas comunes en algunos sistemas. Algunos ejemplos son: representación de multi-tareas y comunicación entre las mismas.
   
10. Asume que puedes saberlo todo antes de escribir la primera línea de código:
    El concepto de escribir primero el manual del usuario y después generar el código basándose en éste es una idea "algo" buena pero la mayoría de las veces es imposible de conseguir. En la práctica todo es tan dinámico, que el mantenimiento de los diagramas de UML para que estos compaginen con el código se convierte rápidamente en la tarea que nadie quiere hacer.
    
11. Las herramientas UML se enfocan en la tarea equivocada:
    La mayoría de las herramientas UML prometen la generación automática de código. Esto es la mayoría del tiempo una inutilidad porque casi siempre se generan clases vacías sin ninguna lógica del negocio. También es fastidioso porque se tiene que mantener el código y los diagramas en "sincronización".
    
    La herramientas debieron enfocarse en ingeniería en reverso con propósitos de documentación, creo que no existe una herramienta lo suficientemente completa que maneje esta área; incluso algunas herramientas que logran hacer ingeniería en reverso del código, realizan un trabajo pobre en el área de documentación porque no son capaces de diferenciar lo que es esencial de lo que no. Como resultado la mayoría de los proyectos que usan UML tienen código que no se acerca a los diagramas que se hicieron al principio del proyecto.

UML simplemente retrasa el trabajo efectivo de los desarrolladores; una idea o una funcionalidad que se puede diseñar, implementar y probar en 2 semanas se convierte en un via crucis de documentos, entregables, diagramas y descripciones que pueden tardar semanas e incluso meses en ser completados.

La idea detrás de UML fue buena: una forma de lograr una comunicación "sencilla" entre los distintos grupos de desarrolladores y los clientes. Pero cuando un estándar de especificación es tan abierto y confuso pierde su valor, la gran cantidad de diagramas existentes y las mil y un formas (todas correctas) de representar un concepto hacen que UML sea un lenguaje visual recargado y monstruoso y no facilitan las cosas al momento de desarrollar nada.

Quizás UML tiene un valor oculto que no logro entender.... nah, no creo.