Introducción:

Blogak 2.0 nos ha ofrecido una clara imagen de las nuevas ideas que están surgiendo en Internet en los últimos meses en lo referente a los blogs y redes sociales.

Al acceder a la sala de conferencias del museo Guggenheim de Bilbao, se respiraba un ambiente de pantallas de plasma, y personas que están más acostumbradas a comunicarse a través de un teclado o una webcam… el número de portátiles encendidos, la conexión wifi gratuita y la retransmisión del evento a través de diferentes medios como Twitter, Flickr, Youtube, múltiples blogs y videocast no dejaban lugar a dudas, estábamos en la edición 2007 de Blogak 2.0.

Este tipo de eventos , no solo son interesantes por el contenido , si no por la calidad del networking que se puede realizar. Pese a que había mucho solitari@, conocimos a personas muy interesantes.

El evento:

Comenzamos con una amena conferencia ofrecida por Rob Malda , fundador de Slashdot considerado el blog más longevo de Internet… Rob se mostró abierto, sencillo y sin aires de grandeza, lo cual es de agradecer cuando se trata de personas que saben que por un motivo u otro han destacado sobresalientemente en algún ámbito humano… el lo hizo siendo un pionero en Internet.

Sigue aquí »

Mañana 24 de Mayo durante todo el día se celebrará en el Guggemheim de Bilbao " BLOGAK 2.0 " , una serie de conferencias dedicadas a los blogs y las nuevas redes sociales. Todo ello comenzará a las 9:30 con Rob Malda fundador de Slashdot, considerado el blogger más pionero del mundo, y a partir de ahí, desfilaran un importante número de participantes.

Actualización 24 de Mayo:

Hemos comenzado a preparar un reportaje sobre lo mejor de Blogak, tenemos las imágenes, los mejores proyectos y nuestra opinión al respecto...

Ver álbum de fotos »

aNieto2K se hace eco de la nota aparecida en ajaxian: 210 Ajax Frameworks and counting.

 Y es que la verdad es que desde la popularización de ciertas técnicas avanzadas de Javascript y su implantación en muchas de las aplicaciones de lo que se ha venido a llamar la Web 2.0, resulta más que práctico casi imprescindible echar mano de algún tipo de framework que nos facilite el trabajo, ya sea en lo referente exclusivamente a comunicaciones AJAX o para simplificar el acceso y modificación del DOM, o la gestión de eventos.

De todas formas, a pesar de la variedad he de decir que, al menos hasta ahora, no he encontrado nada tan potente, sencillo de usar y optimizado en cuanto a rendimiento y tamaño como JQuery.

¿Qué framework usas tú? ¿O quizás eres de los que piensan que esto de los frameworks es para cobardes y te curras todo tu javascript a pelo?  

Más información

• La lista de los 210 Frameworks de AJAX en AjaxPatterns 

Justo esta semana pasada empezamos en la oficina una fase de revisión de marcado y de css de una web bastante grande, y en la que participaremos varios desarrolladores. Ésto nos ha obligado a acordar algunas convenciones a la hora de trabajar, en cuanto a codificación, estructura, nomenclatura... y a plasmarlas por escrito para que todo el equipo, ahora y en el futuro, pueda consultarlas en un documento de referencia.

En esa guía, además, hemos tratado de incluir algunas recomendaciones de "buenas prácticas" entre las que voy a tratar de resumir algunas de ellas, las más importantes a mi entender.

Consideraciones previas

• Asegúrate de definir siempre un DOCTYPE, ¡y úsalo!
  De otra forma, el navegador entrará en el Quirk Mode, aumentando el tiempo de renderizado y provocando algunos desajustes en cuanto a la interpretación de ciertas propiedades CSS.
• Evita usar estilos incrustados o elementos presentacionales en tu marcado.
  Reserva etiquetas <strong> y <em> para aquellos textos que realmente requieran ser enfatizados, y nada de estilos incrustados con styles dentro de tu código HTML. Los estilos SIEMPRE separados del contenido.
• Valida tu código a medida que codifiques.
  Te evitarás muchos dolores de cabeza al final del proceso. Gran parte de problemas de renderizado son consecuencia de marcado no válido.De igual forma, asegúrate de que esa propiedad tan molona de CSS que estás usando sea estándar y no exclusiva para IE.
• Resetea las propiedades CSS para eliminar diferencias entre navegadores desde el principio.
  Es muy buena idea empezar tu hoja de estilos general con una serie de declaraciones que reseteen propiedades como los margin, los padding y los border de los elementos más comunes. Echa un vistazo al reset.css que ofrece la librería de Yahoo o al artículo de Daniel que lo comenta más a fondo.
• Usa el navegador más moderno y con mejor soporte de los estándares durante el desarrollo y el testeo, antes de probarlo en los navegadores "problemáticos", y no al revés.
  Puede que no sigas esta norma y no tengas ningún problema, pero si testeas primero en IE6 tienes muchas probabilidades de terminar con un CSS lleno de hacks, o peor, de terminar metiendo "hacks" para los navegadores que sí cumplen los estándares. Tu objetivo tiene que ser conseguir el código y el CSS más limpio y cross-browser posible y, créeme, la mejor manera de conseguirlo es ésta.
• Usa el menor número de archivos posible. Es mejor un sólo archivo de 30Kb que 3 archivos de 10Kb.
  Piensa que para cada uno de los archivos estáticos enlazados desde un documento HTML ( CSS, Javascript, imágenes, etc... ), éste debe realizar una conexión HTTP y lanzar una petición, con sus correspondientes cabeceras, cookies si las hubiere... todo suma y al final, tanto en tamaño como en tiempo de descarga, penalizarás al usuario.

Estructura, nomenclatura y otras yerbas

• Sea cual sea, trata de ser consistente en el idioma usado cuando codifiques, tanto en los nombres como en los comentarios.
  Esto toma especial importancia en grandes equipos o con personas de diferentes procedencias.
• Usa siempre minúsculas y guiones o guiones bajos para separar palabras.
  Algunos navegadores antiguos han demostrado tener problemas con mayúsculas-minúsculas, así que ve a los seguro.
• Sé descriptivo en los nombres y huye de usar aquellos que se refieran a la apariencia de los elementos.
  Mejor usar un #main-product que un #m-prod, y nada de clases del tipo .centered, .red... O te encontrarás con que cuando toque cambiar el color o la alineación de contenidos, tendrás que ir modificando las clases de cada elemento... ¡¿Dónde están entonces las ventajas de gestionar el diseño desde una hoja de estilos?!
• Trata de sacar partido de la cascada
  Evita crear demasiadas instancias siempre que no sean imprescindibles. Por ejemplo
  #main_table { width:100% }
#main_table th { font-weight:bold; text-align:center }
#main_table td { text-align:right; font-size:1.5em }
  es mejor que
  #main_table { width:100% }
.cell_header { font-weight:bold; text-align:center }
.cell_contents { text-align:right; font-size:1.5em }
  Además, los nombres pueden ayudar a ubicar un elemento dentro de la jerarquía de capas. Por ejemplo, posiblemente sea mucho más práctico usar #header_logo que no #logo a secas.
• Usa criterios consistentes para organizar las declaraciones de estilos dentro de tu CSS.
  Puedes decidir enunciar las declaraciones según su orden de aparición dentro del código, o agruparlas por el tipo de elemento al que se refieren ( listados, titulares, imágenes... ) Sea cual sea, que éste sea constante, o te vas a volver loco cuando la hoja de estilos adquiera un tamaño importante...
• Trata de comprimir lo más posible el archivo resultante.
  Ésto lo puedes conseguir no sólo eliminando espacios y saltos de linea sobrantes en tu hoja de estilos mediante alguno de los compresores gratuítos disponibles en internet, si no configurando tu Apache para que sirva comprimidos los archivos determinados tipos de archivos ( HTML, Javascript, CSS ). Piensa que algunos archivos estáticos se enlazan desde todas ( o casi ) las páginas de tu site. Puedes ahorrarte mucho tráfico con esto.
• Evita usar comillas alrededor de las llamadas a imágenes.
  Todos los navegadores lo entenderán correctamente. Con comillas, en cambio, tendrás problemas en IE para Mac. Pudiendo tenerlos a todos contentos... ¿porqué no hacerlo?

Consideraciones adicionales

• En el 90% de los casos, la solución más sencilla será la que menos problemas dé entre navegadores.  KISS.
  Normalmente podrás usar varias combinaciones para conseguir el mismo efecto visual. Trata de encontrar la combinación más simple de elementos y propiedades. Mezcla paddings en el contenedor e hijos, margins e indentaciones negativos, y suma algunos posicionamientos absolutos en elementos anidados y tendrás los ingredientes perfectos para un bonito... caos.
• Los hacks son la última solución.
  Invierte hoy 30 minutos más en encontrar la alternativa cross-browser y ahórrate horas la semana que viene tratando de modificar tu hoja de estilos.
• Una mala y una buena noticia: ¿La mala? No te asustes, pero sí, algunos navegadores tienen bugs de render, sin explicación ni justificación alguna. ¿La buena? En sitios como PositionIsEverything han identificado muchas de ellas y pueden ahorrarte algunos quebraderos de cabeza. Un simple e inocuo position:relative; o un zoom:1; solucionan muchos de estos bugs.
• En la línea de lo que comentábamos al principio respecto a la cantidad de archivos CSS a enlazar desde tu página, hay algunas técnicas que pueden ayudarte a reducir la cantidad de archivos de imagen que uses para construir tu página: CSS Sliding Doors & CSS Sprites. Hacer más con menos, keep in mind.
• La guinda del pastel: no te olvides de preparar una hoja de estilos para impresión. Hace unos días dábamos algunos consejos desde Pixelovers al respecto en Hojas de estilo para impresión.
• Puedes usar parámetros en la llamada a tu CSS para mantener el control sobre la caché del navegador, y decidir cuándo debe expirar tu hoja de estilos o forzar a tus usuarios a descargarla de nuevo en su siguiente visita.

Conclusiones

Para empezar, concluyo que finalmente el artículo ha salido algo más largo de lo que había previsto, pero había algunos puntos que no quería que quedaran en el tintero, así que espero disculpes mis excesos.

Sin duda, elaborar una guia de estilo a modo de referencia es una práctica recomendable, cuando tengas que enfrentarte un proyecto de dimensiones considerables, y con más motivo si van a ser varios diseñadores / desarrolladores los que "metan mano" al código. Aún y codificando correctamente, cumpliendo estándares y produciendo código válido, semántico, etc... cada uno tiene sus costumbres y su manera de hacer, y mezclar formas de trabajar sin cierto orden en un mismo proyecto puede resultar algo problemático para mantener la web en un futuro. Definir una referencia de estilo, estructura y/o nomenclatura puede reducir, y mucho, esos problemas en equipos grandes.

¿Y tú, cómo trabajas? ¿Coinciden estas recomendaciones con las que incluirías tú en tu HOW-TO? 

Enlaces y más

• Especificación CSS 2.1
• Validador CSS
• Optimizador CSS
• 70 expert ideas for better css coding en Smashing Magazine
• CSS Crib Sheet de Dave Shea

Ver álbum de fotos »

Empezaré diciendo que nunca he encontrado mal inspirarse o basarse en ideas o diseños de otros. Más allá de la estética, el diseño tiene una vertiente funcional, y en muchos casos hay decisiones de diseño que vienen dadas o por la experiencia de un equipo resolviendo determinadas situaciones, o como resultado de análisis expertos o tests de usuarios. Para alguien que empieza o no tiene los mismos recursos que determinadas empresas, muchas veces aplicar la solución que ya usan otros con éxito o basarse en el diseño de terceros está justificado.

¿Pero qué ocurre cuando una gran empresa copia descaradamente a otra? Pues que se pone en evidencia ante la competencia y da una imagen penosa a sus usuarios y al mercado en general.

A la izquierda está el diseño de la versión BETA del nuevo portal de AOL, y a la derecha tenéis la home actual de Yahoo. El parecido es más que evidente. Me pregunto qué ha llevado a una empresa como AOL a perpetrar tan descarado plagio.

Via | Techcrunch

Coda es un editor de texto orientado al desarrollo web que integra, además, un completo gestor de sites, funciones de un cliente FTP, un cliente SSH, un editor visual de hojas de estilo, opciones de previsualización incorporadas, funciones de autocompletado para HTML, CSS, PHP, SQL... Vamos, un todo-en-uno en toda regla, y con la solvencia de haber sido desarrollado por la gente de Panic.

Lo conocí esta misma semana a través de una de estas webs que recopilan diseños interesantes: CSSRemix, CSSMania... no recuerdo cuál. Debo reconocer que en nuestra primera toma de contacto me quedé sólo con lo atractivo del diseño de su página y pensé que no sería si no "otro más" de esos programas que intentan sin mucho éxito combinar demasiadas cosas bajo un único interface. Sin embargo, el viernes Eric, uno de los compañeros de la oficina, me lo recomendó, así que hoy he decidido darle una oportunidad usándolo durante toda la tarde para llevar a cabo algunos cambios a OboLog.

La verdad es que supera con creces la prueba. Tanto, que me estoy planteando sustituir mi actual editor de texto, TextMate, por éste.

• El interface es cómodo e intuitivo, consigue conjugar todas las 'caras' de la aplicación sin saturar al usuario con miles de opciones.
  
• El editor de texto, como comentaba más arriba, incorpora auto-completion para los lenguages más habituales, así como coloreado automático del código.
• Organiza los archivos abiertos en pestañas, en vez de abrir nuevas ventanas para cada uno.
  
• Trabaja de forma fluida aunque los archivos se encuentren en red ( uno de los temas que más problemas me daban con TextMate ).

En mi caso la verdad es que poco partido le saco al cliente FTP. Si tuviera integrado un cliente para Subversion o similar sería ya El Editor Definitivo, pero será una carencia que perdonaremos, ya que con el cliente SSH en la misma interfaz podemos, en un momento dado, lanzar los commits en local o los updates en el servidor cuando haga falta.

En definitiva, toda una opción a tener en cuenta. Posiblemente siga usando CSSEdit 2 para la creación y edición de hojas de estilo, puesto que en ese aspecto es mucho más completo que Coda, pero creo que ambos van a formar un buen equipo. El precio, por otra parte, no es desorbitado: $79.

Actualización 2 de Mayo: Panic ofrece una actualización desde su web a Coda 1.0.1, en la que han añadido soporte para JPS-HTML y ActionScript, la posibilidad de trabajar con plantillas Smarty, y la opción de definir una URL local para lanzar las previsualizaciones mientras estemos desarrollando (release notes de la nueva versión). 

Ver álbum de fotos »

Getting Real es el libro sobre desarrollo de proyectos web en el que 37 Signals ha tratado de plasmar su filosofía de trabajo. A lo largo de 16 capítulos hablan de varios temas que van desde gestión del tiempo y de prioridades en el desarrollo de proyectos, de diseño de interfaces o producción de código, hasta cómo promocionar tu negocio o tu aplicación web.

Getting Real is about skipping all the stuff that represents real (charts, graphs, boxes, arrows, schematics, wireframes, etc.) and actually building the real thing.

Getting real is less. Less mass, less software, less features, less paperwork, less of everything that's not essential (and most of what you think is essential actually isn't).

Getting Real is staying small and being agile.

Hace unos meses empezaron a ofrecer su libro de forma gratuíta, para su lectura online, y empezaron a traducirlo a diferentes idiomas, entre ellos, el castellano. Si tu relación con la lengua de Shakespeare no es todo lo buena que debiera, ahora dispones de una versión en castellano del manual de "buenas prácticas" de 37 Signals: Getting Real en castellano.

Como apunte: a poco que puedas, te recomiendo leer la versión en inglés. La traducción en algunos puntos deja bastante que desear...

Corrección 08.05.07: Joselo nos avisa de que no todos los capítulos han sido traducidos. Aún quedan algunos capítulos centrales en inglés . Nos alegramos demasiado pronto... ¿Alguien se anima a echarles una mano y terminar la traducción que empezaron hace ya más de 7 meses? 

Web oficial | Getting Real

En esta ocasión veremos como evitar un problema con el que seguro os habréis topado en más de una ocasión: El navegador no detecta un cambio que hemos realizado en un archivos estático ( CSS / Javascript / imagen ) y usa la copia cacheada en disco, impidiendo que la web muestre los estilos correctos, actualizados, o lanzando un error Javascript por el uso de una función no existente, hasta que forzamos una actualización con Ctrl-F5.

El caché de los navegadores actúa en el 90% de las ocasiones como nuestro aliado. Permite que determinados archivos estáticos se carguen una única vez por usuario, y se lean desde el disco en sucesivas visitas, reduciendo drásticamente los tiempos de carga.

De todas formas, el caché también puede jugar en nuestra contra en determinadas ocasiones: Si hemos realizado modificaciones a un archivo estático en un intervalo corto de tiempo, y además estas modificaciones han hecho variar muy poco el tamaño de nuestro archivo, es muy probable que el navegador no detecte que existe una nueva versión, y en vez de descargar el fichero más actual, haga uso de la copia que guarda en el disco para montar la página.

Como apuntábamos al principio, las consecuencias de esto suelen ser desastrosas: webs descuadradas o errores javascript por culpa de funciones que "deberían estar", pero que el navegador no ha cargado. Y, claro , el Ctrl-F5 sirve para mostrar la página al compañero de mesa o para tranquilizar al jefe que ha pegado un bote en la silla al ver el resultado, pero el usuario no tiene ni idea... va a verlo todo descuadrado hasta que expire la caché o le dé por forzar la recarga ( cosa poco probable ).

La solución a este problema es sencillamente añadir un parámetro a la llamada que hagamos al archivo estático. Los hay que optan por usar una fecha, y otros simplemente un valor numérico. Yo soy de estos últimos: como suelo usar Subversion para el control de versiones, lo que hago es actualizar el valor con el nº de versión correspondiente. De esta forma puedo saber, además, cuándo se hizo la última modificacion "sensible" a la hoja de estilos, echando un vistazo al showlog.

Cada vez que cambiamos el parámetro que hemos añadido a la llamada al CSS ( o Javascript, o imagen... ), lo que estamos haciendo es forzar al navegador a descargar de nuevo el archivo, retomando de esta forma el control sobre cuándo cachear y cuándo no.