Disposición de Páginas Web sin usar tablas

Al principio del boom de internet y las páginas Web, no había mucho que hacer o inventar para hacer una página interesante y atractiva, después de cierto tiempo, los diseñadores y desarrolladores de páginas Web descubrieron la factibilidad de hacer sus páginas web iguales al diseño "increíble" que tenían en su cabeza.

Eso lo lograron mediante el uso de tablas, imágenes y colores de fondo, "INCREÍBLE" se llegó a decir en algún momento de esta historia, "¡¡La página es igual al diseño original!!", esto era aceptable en los 90's cuando todo lo relacionado con internet era relativamente nuevo, pero en la actualidad una página diseñada enteramente con imágenes simplemente no llama la atención como lo hacía antes, son más lentas para cargar y además son un dolor de cabeza cuando se quieren hacer algunas modificaciones.

Mucha gente se dió cuenta de esto y cambió las imágenes por flash (que es igual de malo para el diseño) o por texto con ciertos estilos asociados, pero siguió haciendo uso de las tablas para mostrar el diseño de su página. Las tablas en HTML NUNCA fueron creadas pensando en la disposición de imágenes en una página Web, más bien se pensaron para mostrar datos de forma tabular, más nada, el uso que se le dió fue erróneo desde el principio.

Bueno después de esa breve "introducción" vamos al meollo del asunto, es posible crear páginas sin necesidad de usar tablas para la disposición de los elementos, haciendo uso de DIVs y CSS, los DIV son "Divisiones" (de ahí el nombre) de la página que pueden ser posicionados a voluntad y dentro de éstos se puede mostrar lo que uno desee.

Los "tipos" de página más comunes son los de 2 y 3 columnas, los links que siguen son ejemplos de como es la disposición básica de los elementos en una página Web.

• 2 Columnas con el menú del lado izquierdo
• 2 Columnas con el menú del lado derecho
• 3 Columnas

Pueden usar esas página "guía" para crear sus páginas sin problemas.

Referencias:
Simple CSS templates
Sample CSS Page Layouts
Floatutorial: Step by step CSS float tutorial

Las Cadenas (los correos, no las de Chávez)

¿Cómo es posible que a estas alturas de la vida la gente siga mandando los benditos correos cadena?

¿No se cansan de ver a cada rato el mismo mensaje de "Te quiero mucho, mándalo a 123 personas", "Si no lo reenvías se te caerán las orejas","Envíalo a 200 personas en 5 minutos y te traerán el almuerzo"?, POR FAVOR, yo pensaba que ya la gente había pasado esa etapa; yo por lo menos ya estoy cansado de esos bentidos correos, ya tengo repetido en mi bandeja de entrada el correo de la "Antorcha Olímpica que te quema el disco duro" como 40 veces (no estoy exagerando), Les voy a decir algo ... ESE CORREO LO INVENTÓ ALGÚN OCIOSO CUANDO SE HICIERON LAS OLIMPIADAS EN ATLANTA 96, quizás hasta antes, y todavía la gente lo reenvía para "advertir" a los demás de un posible desastre pirotécnico con tu disco duro.

Aún peores son los correos que son "rastreados" por Microsoft, AOL o cualquier otra compañía grande en el mercado de internet para (supuestamente) ayudar a un niño enfermo de cáncer / SIDA / gripe aviar / dolor de muela / diarrea, ¿saben qué? eso es pura BASURA, sip, pura basura, los correos no pueden ser rastreados así de fácil como la gente cree y si en todo caso se pudieran rastrear, esas compañías podrían estar enfrentando problemas legales por invasión de la privacidad, porque para rastrear un correo tienen que saber quién te lo mandó y a quién se lo mandaste, ellos no hacen una especia de "barrido" por todo internet para ver a donde fue a parar ese correíto ... Bueno, siguiendo con el tema de los niños enfermos: Amy Bruce NUNCA TUVO CÁNCER PORQUE NUNCA EXISTIÓ!!! si quieren revisen esta dirección para que no les vean y no me vean la cara de pendejos: Amy Bruce Chain Letter

Sigamos con otros ejemplos de cadenas, las que más odio son las que intentan manipularte con eso de que "Si puedes enviar chistes pero no envías oraciones ... que mala persona eres". Les voy a decir una cosa: UN CORREO ELECTRÓNICO NO VA A CAMBIAR A LA GENTE!!!. Si las personas creen o no creen en determinada religión no van a cambiar su forma de pensar por un correo con musiquita bonita. Lo peor de esos correos es que te obligan a leer una oración y después te dicen que si no lo reenvías te mueres en el infierno, como diría el Conde del Guácharo: ¡¡NO ME JODAS!!

Y de últimos pero no por eso los menos fastidiosos, los correos de amor en cadena. Ok, les puedo entender que las personas quieran a otras personas, hasta ahí todo va bien, pero cuando te mandan un correo don 200 caritas sonrientes, 400 cachorros y 500 atardeceres con viejitos ya llegan al extremo. Lo peor es cuando el correo contiene mensajes del tipo: "Mándalo a 4578 personas, luego voltea a la derecha, parpadea 7 veces y después presiona F5, y verás el nombre del perro de tarzán cuando tenía 5 años y estaba perdido en la selva.". ¿Cómo es posible que la gente crea ese tipo de cosas? Un correo no va a cambiar el funcionamiento de una tecla en tu computadora por muy hacker que sea la persona que te la envió ... está bien, lo reconozco, la primera vez que me mandaron un correo de ese tipo caí en la trampa, pero de ahí en adelante aprendí (algo que la gente se resiste a hacer) que F11 no muestra el nombre de la persona que me quiere, simplemente pone el navegador en modo pantalla completa.

Ah, otra cosa, se me olvidaba decirles, si me mandan un mensaje cadena NO LO VOY A ABRIR ya los he visto todos, en todos los colores, sabores y olores y si en algún momento llego a abrirlo y leerlo, tengan por seguro que no lo voy a reenviar aunque me calga la maldición de tongo le dió a borondongo.

Y para que no digan que lo único que hago es quejarme sin razón, revisen este artículo en wikipedia. Cadena de Mensajes

Y si tienen tiempo o estan fastidiados, busquen en Google cualquier asunto de cualquier correo cadena que recibieron y reenviaron, eventualmente se golpearán ustedes mismos en la frente y pensarán: "Cooooño caí como un pendejo".

12 señales de que eres un mal programador

1. Java es todo lo que necesitas.
   No ves la necesidad de usar ningún otro lenguaje, ¿por qué no se puede hacer todo con Java? No te importa ver código en Python o Ruby que logra en 10 lineas lo que llevaría varias hojas de código Java. Además, seguramente las nuevas características de la próxima versión del lenguaje lo arreglaran de todas formas. (Esto es aplicable a casi cualquier lenguaje, pero ocurre que entre la comunidad Java parece estar más extendida esta forma de pensar)



2. El término "enterprise" no te suena a broma.
   "Enterprise" no es sólo una palabra, es una filosofía, una forma de vida, un camino a la iluminación. Cualquier cosa que pueda ser escrita, desplegada o actualizada con un trabajo mínimo es descartada como un juguete que no "escalará" para futuros usos. Mientras tanto la mayor parte del trabajo real en tu oficina se hace enviando hojas de cálculo en Excel mientras esperan a que termines de construir tu nueva visión corporativa.



3. Te opones férreamente a las funciones/métodos de más de 20 líneas de código.
   (o 30 o 10 o cualquier otro número) Lo siento, algunas veces una función larga es justamente lo que necesitas. Normalmente las funciones cortas son más sencillas de entender, pero algunas veces se pueden expresar más fácilmente en una sola función más larga. El código no debería hacerse más complejo sólo para adecuarse a criterios arbitrarios.



4. "¡OH DIOS MÍO! ¡PATRONES!"
   Los desarrolladores que buscan constantemente la forma de aplicar patrones a cualquier problema de código con el que se encuentran están añadiendo una complejidad innecesaria. Lejos de ser algo que busques, deberías sentirte mal cada vez que tienes que utilizar un patrón de diseño, significa que estás escribiendo código que hace las cosas más complicadas y que puede ser de dudosa utilidad. Pero, ¡ey!, tu código tiene patrones, bien por ti.



5. Los ciclos de CPU son un recurso precioso y tu estilo de programación y lenguaje reflejan esas creencias.
   Hay montones de problemas en los que tienes que tener muy en cuenta el consumo de CPU (modelado/simulación, procesado de señales, kernels de sistemas operativos, etc), pero no es tu caso. Para la mayor parte de los desarrolladores de software sus principales problemas de rendimiento están relacionados con las bases de datos y la entrada/salida. El único efecto de optimizar tu código para mejorar el uso de CPU será disminuir en 2 milisegundos el tiempo necesario para la próxima consulta a la base de datos. Mientras tanto el desarrollo de la aplicación se hace más lento, no puedes hacer frente a los nuevos requerimientos y te encuentras con problemas serios de calidad. Pero al menos estás ahorrándote montones de ciclos de CPU… eventualmente.



6. Piensas que ninguna función/método debería tener más de un return.
   Esta la he oído alguna que otra vez, y normalmente la razón que me dan es que el código es más sencillo de analizar. ¿Según quién? Yo encuentro más fácil de leer un código más simple, y normalmente el tener más de un return simplifica el código.



7. Tus usuarios son estúpidos. Realmente estúpidos.
   Simplemente no puedes creer lo estúpidos que son, olvidándose constantemente de hacer las cosas más sencillas del mundo y cometiendo errores tontos al usar tu aplicación. Nunca has considerado que quizás es tu aplicación la que es estúpida porque eres incapaz de escribir software decente.



8. Te enorgulleces enormemente del gran volumen de código que escribes.
   Ser productivo es bueno, desafortunadamente escribir montones de líneas de código no es lo mismo que ser productivo. Los usuarios nunca comentan "Guau, este programa puede ser difícil de usar y estar lleno de errores, pero al menos sé que hay un montón de código por debajo." En lugar de ser productivo, generar toneladas de mal código retrasa a los demás desarrolladores y en el futuro su mantenimiento constituirá una pesada carga.



9. Copiar y pegar es genial, te ayuda a escribir código desacoplado.
   Defiendes tu uso del copy paste con extraños argumentos sobre desacoplar código y eliminar dependencias, mientras ignoras el aumento del tiempo de mantenimiento y los problemas de duplicación de errores. A esto se le llama "racionalizar tus acciones".



10. Piensas que la gestión de errores consiste en capturar todas las excepciones, registrarlas, y continuar como si nada.
    Eso no es gestionar errores, eso es ignorar errores y es el equivalente semántico al "on error next" de VB. Sólo porque hayas registrado el error en algún sitio no significa que lo estés tratando. Tratar errores es algo duro. Si no sabes qué hacer exactamente cuando te encuentras con un cierto error, simplemente deja que la excepción se propague y que un nivel más alto del código lo trate.



11. Modelas todo tu código en UML antes de escribirlo.
    El modelado entusiasta de UML se lleva a cabo normalmente por aquellos que no escriben demasiado código, sino que se consideran arquitectos de software. Las herramientas de modelado atraen más a aquellos que piensan que el código se puede escribir en una sala de conferencias manipulando pequeños gráficos. Los gráficos no son el diseño, y nunca serán el diseño, para eso está el código.



12. Tu código borra datos importantes.
    Escribiste un cierto código que se supone que debe sobrescribir los archivos de la aplicación con otros nuevos, pero se vuelve loco y borra todos los datos del usuario.

Artículo original en español en Mundo Geek y en inglés en http://damienkatz.net/2006/05/signs_youre_a_c.html?repeat

Cambio de Imágenes sin Javascript

En mis inicios de creación/desarrollo y mantenimiento de páginas web llegué a "aprender" algo de javascript y me di cuenta que se podían mejorar muchísimos elementos en cualquier página si hacía uso de ciertas funciones de javascript, en ese momento parecía una buena idea.

Conforme pasó el tiempo aprendí a desarrollar páginas con PHP, JSP y MySQL; con estas nuevas herramientas y mi nuevo conocimiento de Javascript logré hacer ciertas cosas interesantes como menús contextuales e imágenes que cambiaban de acuerdo al tipo de página que se estuviese mostrando o al tipo de consulta que se hiciera a la base de datos.

El problema con todo esto es que el bloque de código de javascript de cada página HTML/PHP era gigantesco, ilegible e inmantenible lo que no ayudaba para nada si en algún momento cualquier otra persona deseaba realizar cambios a la página.

Un ejemplo clásico de código de javascript es el usado para cambiar una imagen mostrada. Uno puede pensar que es bastante sencillo, pero si haces uso de herramientas como Dreamweaver, el código generado de forma automática puede representar una pesadilla. El siguiente código es el que genera Dreamweaver para cambiar una imagen:

function MM_swapImage() { //v3.0
   var i,j=0,x,a=MM_swapImage.arguments;
   document.MM_sr=new Array;
   for(i=0;i<(a.length-2);i+=3){
      if ((x=MM_findObj(a[i]))!=null){
         document.MM_sr[j++]=x; 
         if(!x.oSrc) x.oSrc=x.src; x.src=a[i+2];
      } 
   }
}

Yo quisiera entender ese bloque de código y hasta ahora no lo entiendo, créanme lo he intentado pero al final desistí.

Menos mal que eventualmente aprendí las ventajas de CSS y entendí que no siempre hacer todo con javascript es bueno.

Supongamos que queremos cambiar esta imagen:

por esta otra:

en el menú de cualquier página. Generalmente el código HTML del menú sería algo así:

<a href="#">Item 1</a>
<a href="#">Item 1</a>
<a href="#">Item 1</a>
<a href="#">Item 1</a>

Para lograr el cambio de imagen hay que definir ciertos elementos en la hoja de estilo y añadir una "clase" a los link.

La hoja de estilo sería algo como esto:

a.menu_item{
display: block;
width: 75px;  <-- coincide con el ancho de la imagen
height: 40px; <-- coincide con el alto de la imagen
background: url(imagen0.jpg) no-repeat top left;
line-height: 40px;
padding-left: 10px;
color: white;
text-decoration: none;
}

a.menu_item:hover{
background: url(imagen1.jpg) no-repeat top left;
}

Después de definir la hoja de estilo sólo hay que cambiar el código HTML de los link:

<a href="#" class="menu_item">Item 1</a>
<a href="#" class="menu_item">Item 1</a>
<a href="#" class="menu_item">Item 1</a>
<a href="#" class="menu_item">Item 1</a>

Y Listo, se puede ver este ejemplo funcionando aquí

Menú Desplegable con CSS

Todos hemos visto alguna vez una página web con un menú desplegable que nos dejó asombrados la primera vez que lo vimos.

Bueno he aquí una pequeña guía para hacer un menú de esos usando solo HTML y CSS, sin flash ni trucos raros.

1.- Lo primero que haremos es hacer una lista no ordenada que contendrá los items del menú:

<ul id="menu">
 <li><a href="#">Item 1</a>
    <ul>
       <li><a href="#">Item 1.1</a></li>
       <li><a href="#">Item 1.2</a></li>
       <li><a href="#">Item 1.3</a></li>
       <li><a href="#">Item 1.4</a></li>
    </ul>
 </li>
 <li><a href="#">Item 2</a></li>
 <li><a href="#">Item 3</a>
    <ul>
       <li><a href="#">Item 3.1</a></li>
       <li><a href="#">Item 3.2</a></li>
       <li><a href="#">Item 3.3</a></li>
       <li><a href="#">Item 3.4</a></li>
    </ul>
 </li>
 <li><a href="#">Item 4</a></li>
</ul>

2.- Luego empieza el desarrollo de la hoja de estilo (CSS) encargada del funcionamiento del menú:

ul.menu , ul.menu li ul{
width: 100%;
list-style-type: none;
margin: 0;
padding: 0;
border-top: 1px solid #bababa;
background: white;
}

ul.menu li{
float: left;
position: relative;
border-bottom: 1px solid #bababa;
border-right: 1px solid #bababa;
border-left: 1px solid #bababa;
}

ul.menu li a{
display: block;
width: 146px;
padding: 2px;
text-decoration: none;
color: black;
font-weight: bold;
}

ul.menu li a:hover{
background-color: #7abedf;
color: white;
}

ul.menu li ul{
display: none;
position: absolute;
top: -1px;
left: 150px;
}

ul.menu li:hover ul{
display: block;
}

Ya con esto es suficiente para tener un menú funcional en cualquier navegador decente (léase cualquiera que no sea Internet Explorer). Para hacerlo funcionar en IE es necesario recurrir a javascript y cambiar un poco la hoja de estilo.

4.- El cambio en la hoja de estilo no es gran cosa, solo se agrega la clase "mostrar":

ul.menu li ul.mostrar{
display: block;
}

5.- La función de javascript que usaremos la llamaremos cambiarClase y es la que sigue:

<script>
function cambiarClase(obj,clase){
 document.getElementById(obj).className=clase;
}
</script>

6.- Luego hay que asignarle nombre a todos los submenú existentes haciendo uso de la propiedad id y añadir los eventos de javascript a los items correspondientes:

<ul id="menu">
 <li onMouseOver="cambiarClase('submenu1','mostrar');" 
onMouseOut="cambiarClase('submenu1','');"><a href="#">Item 1</a>
    <ul id='submenu1'>
       <li><a href="#">Item 1.1</a></li>
       <li><a href="#">Item 1.2</a></li>
    </ul>
 </li>
 <li><a href="#">Item 2</a></li>
 <li onMouseOver="cambiarClase('submenu3','mostrar');"
onMouseOut="cambiarClase('submenu3','');"><a href="#">Item 3</a>
    <ul id='submenu3'>
       <li><a href="#">Item 3.1</a></li>
       <li><a href="#">Item 3.2</a></li>
       <li><a href="#">Item 3.3</a></li>
       <li><a href="#">Item 3.4</a></li>
    </ul>
 </li>
 <li><a href="#">Item 4</a></li>
</ul>

Con esto es suficiente para que el menú funcione en cualquier navegador.
Se puede ver un ejemplo totalmente funcional aquí

Web 2.0

Aquí les dejo un video bastante interesante que muestra algunas bondades de la web 2 y sus infinitas posiblidades.

Bajando MP3

Yo siempre me he sorprendido de la capacidad de la gente para no entender las cosas más simples así se las expliques como a un niño de 2 años.

¿Por qué CARAJO todo el mundo tiene que descargar MP3, videos, fotos, juegos o cualquier otra cosa que se les antoje cada vez que se sientan frente al monitor?, yo entiendo que uno quiera descargar una que otra cosa de vez en cuando, pero TODOS los días es una maldición, la red se pone como una mierda, el ancho de banda se consume en su totalidad por esos vampiros de Kbytes, simplemente porque descargar MP3 es una especie de símbolo de estatus.

Ya me imagino a los adolescentes de hoy teniendo conversaciones como esta:

#1: "Mi iPod tiene 2134221993993 canciones y es más fino que el tuyo".

#2: "¿Ah sí? pues apenas llegue a mi casa voy a descargar 1123845 canciones para tener más MP3 que tú".

Este tipo de conversaciones genera una reacción en cadena - según la teoría del caos - en la que los únicos perjudicados somos los que usamos internet para trabajar ... SÍ!!, INTERNET SE PUEDE USAR PARA TRABAJAR. No todo en esta vida es hablar por el Messenger, actualizar tu página de MySpace y descargar MP3 con Limewire o Ares, en realidad Internet es un universo más grande que tu cerebro en el que sólo caben MP3 y fotos de mujeres con pechos enormes en ropa interior mínima, y gracias a tu MALDITA Y NEFASTA manía para descargar basura todos los días se me hace imposible trabajar.

Nota: Este mensaje no va dirigido a nadie específico, todos los personajes aquí representados son ficticios y todo parecido con la realidad es pura coincidencia.

¿Qué tipo de programador eres?

Después de abandonar el blog por demasiado tiempo, regreso con una lista algo graciosa que muestra los distintos tipos de programadores que pueden trabajar en un proyecto.
La lista se encuentra en esta dirección http://blogs.techrepublic.com.com/10things/?p=262