Archivo de la etiqueta: programación

Maquetación de una web: II – Material gráfico

Antes de empezar a maquetar, deberíamos contar con todos diseños de la web en formato gráfico. Para mi, el formato ideal es el PSD, estando este bien estructurado y separado por capas, por lo que suelo hablar anteriormente con el diseñador para que me lo prepara de dicha manera.

En otros proyectos en los que he trabajado, para ahorrar costes lo que se hace es diseñar las páginas principales y el resto se estructuran mediante wireframes. Por lo tanto, en estas páginas de las cuales no se tiene el diseño, es el maquetador el encargado de “inventarse” los estilos basandose en las principales. Para mi no es la mejor opción, ya que el maquetador no tendría porque comerse la cabeza pensando en asuntos de diseño, pero a veces no queda más remedio.

Otras veces, por falta de tiempo, no es posible disponer de todas las páginas juntas ya diseñadas, y el trabajo del maquetador se solapa con el diseñador para agilizar el proceso, pero intentaremos evitar esto siempre que sea posible. La razón es que, a la hora de planificar la estructura del código, si se dispone de todas los diseños a maquetar, podemos ahorrar etiquetas HTML y clases CSS innecesarias porque contaremos con una visión más global del proyecto.

En las próximas entradas, utilizaremos como ejemplo un proyecto ideal en el que contaríamos con el diseño de todas las páginas en formato PSD.

Anuncios

Maquetación de una web: I – ¿Qué es y quien debe hacerlo?

En el ámbito del desarrollo web, se utiliza el término maquetación para designar el proceso de conversión del diseño en formato imagen (PSD, JPG, PNG, etc.) a formato HTML (en cualquier de sus variantes). Si bien dicho término no es el más adecuado para referirse a esa labor, es comúnmente aceptado por los profesionales del área. A mi parecer, creo que sería mejor utilizar la palabra “codificación”, aunque el objetivo de esta entrada no es discutir sobre ello.

Generalmente, el proceso de maquetación lo llevan a cabo o el diseñador o el programador, algo que no debería ser así, ya que ninguno de los dos está específicamente preparado para ello. En su lugar, debería existir otro rol dedicado, desempeñado por una persona con conocimientos orientados a dicha labor, como son:

  • Especialista en lenguajes (X)HTML, CSS y JavaScript
  • Amplios conocimientos de accesibilidad y estandares web
  • Nivel medio/avanzado en programas de diseño gráfico (p.ej.: Adobe Photoshop y Fireworks) y codificación (p.ej.: Adobe Dreamweaver)
  • Conocimientos básicos de programación en algún lenguaje web (p.ej.: PHP)

El porque de este rol independiente se explica muy bien en el articulo “El tercer hombre” del blog “Torpe y mal pensado“.

En próximas entradas, expondré todo el proceso que yo sigo para la maquetación de una web, desde la recepción del material gráfico, hasta la entrega de las plantillas finales.

Cuidado con el $_SERVER[‘HTTP_REFERER’]

Inauguro una serie de posts en los que iré explicando algunos consejos utiles para PHP que he ido aprendiendo con el tiempo.

En esta ocasión, os llamaré la atención sobre el uso indiscriminado que muchos programadores nóveles de PHP hacen de la variable de servidor $_SERVER[‘HTTP_REFERER’].
Muchos la utilizan (yo hace tiempo tambien lo hacía) para generar enlaces de “Volver atrás”, para redireccionar a la pagina de origen despues de la ejecución de un script, etc. El problema radica en que esta variable no siempre está disponible, ya sea por que el navegador no la envie, este siendo filtrada/bloqueada por el cortafuegos del usuario, u otras posibles causas. De hecho, en la manual oficial de PHP ya lo advierten:

… Este valor es definido por el agente de usuario. No todos los agentes de usuario lo definen, y algunos proveen la capacidad de modificar HTTP_REFERER como una característica del software. En resumen, no se puede confiar realmente en este valor…

Como consecuencia tenemos enlaces que no llevan a ningun sitio, redirecciones fallidas y otros errores derivados de su uso.
Visto todo esto, solo me queda recomendaros que no useis esta variable, o en cualquier caso programeis una función que compruebe su valor antes de usarla.

WordPress Pingback Encoding Fix

(Entrada en inglés para que la pueda leer más gente. Si alguien no la entiende que lo comente y se la traduzco.)

WordPress v1.5 fixes the trackback encoding problem between blogs with distinct charsets, but doesn’t fix the same problem with pingbacks.
Here you have a “xmlrpc.php” file hack that solves that problem: wordpress_pingback_encoding_fix.zip
Unzip and upload the file to your blog main folder, overwriting the old one.

Updated:
I have setup two blogs with distinct charset encoding. You can make your pingback tests on any of their posts:
WPUTF (WordPress Blog with UTF-8 encoding)
WPISO (WordPress Blog with ISO-8859-1 encoding)

WordPress Trackback Encoding Fix

Las versiones antiguas de WordPress muestras caracteres extraños (“chinitos” como los llama HighToro) en los trackbacks procedentes de webs con otra codificación (UTF-8, ISO-8859-1, ISO-8859-15, etc.) diferente a la propia.
Basandome en la versión 1.5 que ya corrige el problema, he realizado un hack del archivo “wp-trackback.php” para los que como yo todavia no se han actualizado a la nueva versión (ya sea por pereza, falta de tiempo, etc.).

Podeis descargar el fichero en cuestión comprimido en zip de aquí: wp-trackback_encode_fix.zip
Solo teneis que descomprimirlo y subir el archivo “wp-trackback.php” al directorio principal de vuestro blog, sobreescribiendo el antiguo.

Lo he probado en todas las version de 1.2.X de WordPress y haciendo trackbacks de un blog con codificación UTF-8 a otro con ISO-8859-1 y me ha funcionado bien. Si lo probais comentarme que tal os va. Yo cuando tenga un rato le pediré a algun bloguer japones que me haga un trackback a ver si rula bien.

Sobre el Agali Hackmeeting 2K4

Como le prometí a Cek, voy a intertar hacer un resumen del Hackmeeting que tuvo lugar hace un par de fin de semanas aquí en El Puerto.

Aunque había un monton de eventos programados, lo que más me interesaba eran las conferencias, en las cuales aprendí mucho del estado actual del mundillo del Linux.
Por ejemplo, la que más me entusiasmo fue la conferencia sobre Mono. Para quien no lo sepa, Mono es la adaptación libre de la plataforma .NET de Microsoft. ¿Que quiere decir esto? Pues que un programa compilado en .NET bajo Windows, ahora es posible ejecutarlo sobre Linux, Mac o cualquier otra sistema que tenga Mono, o viceversa (aunque todavía tiene algunas limitaciones). Yo mismo vi con mis propios ojos como compilaban un programa en Linux y lo ejecutaban perfectamente en Windows!!!

Aparte de las conferencias, gracias a algunos de los participantes descubrí el escritorio Gnome, para mi gusto (ahora que ya lo he probado bastante) mucho mejor que KDE. O como me decía uno de los organizadores citando a Icaza: “KDE es como la Pepsi, todo el mundo lo conoce, esta muy bien y blablabla, pero en cambio, Gnome es mas como un buen vino, algo de calidad”.

Bueno tampoco quiero explayarme mucho, ya que toda la información, incuyendo fotos, conferencias, etc. lo podeis encontrar en la web de Agali.

Mi propio CMS

Hoy, leyendo el post “CMS propios” en Delirios de un Informático, me ha entrado la picá de hacerme yo también el mio. Llevaba un tiempo dandole vueltas pero hasta hoy no me lo había planteado en serio.

Antes que nada, he decidido las caracteristicas internas del mismo, que serán las siguientes:

Como buen informático, lo primero que voy a hacer es el análisis del proyecto, centrandome sobre todo en realizar un buen diagrama ER. Os mantendré informados de los progresos…