A continuación, por qué es preferible utilizar solamente un dominio para tu sitio, y cómo configurarlo en distintos servidores web.

¿Por qué se debe utilizar un dominio como el principal?

Porque a Google no le gusta ver el mismo contenido en dos direcciones distintas

La razón que probablemente resulta más convincente a estas alturas es simplemente que utilizar más de una URL para mostrar el mismo contenido significa una penalización en los resultados de buscadores… sí, por supuesto eso significa que tu sitio va a salir más abajo si puedes ver lo mismo en http://www.dominio.com/noticia/ que en http://www.otro-dominio.com/noticia. En otras palabras: mantener tu sitio con más de un dominio es pésimo para tu SEO.

Hasta han inventado un nombre para convencerte de que uses sólo una URL para tus contenidos: la dirección “principal” es llamada URL canónica… ésa es la que importa y el resto ¡meh!

Por cierto, esto no aplica solamente cuando los dominios son radicalmente distintos, sino también cuando una opción es www.dominio.com y la otra dominio.com… con www, o sin www, debes elegir una.

Porque las peticiones AJAX entre distintos dominios no funcionan

… o al menos habría que decir “no funcionan del mismo modo que una petición AJAX hecha en el mismo dominio”.

Esto sucede ya que por seguridad los navegadores restringen las peticiones AJAX a un mismo dominio, y aunque existen formas de saltarse esta medida (en particular, implementar llamadas JSONP), considerarla dentro del desarrollo del proyecto va a agregar una complejidad que de otro modo es innecesaria… por supuesto que se puede considerar, pero agrega tiempo y ya se sabe, tiempo es dinero

Porque algunas de las fuentes utilizadas con font-face se restringen a un dominio

Esto también tiene sus grises: no son todas las fuentes, ni es en todos los navegadores.

Si utilizas solamente las fuentes disponibilizadas por Google, no tendrás problema pues sus fuentes no tienen restricciones por dominios.

Sin embargo, si tu diseño considera la utilización de otras tipografías como font-face y debes servirlas desde tu propio servicio, lo más probable es que el archivo de la fuente incorpore una protección (para evitar el hot-linking de fuentes sin autorización), que causará que en algunos navegadores la tipografía se muestre correctamente y en otros no:

… y cuando digo “algunos navegadores”, me refiero a… ¡no, no es Explorer! En realidad, el único que incorpora esta restricción es Firefox… pero claro, a estas alturas no lo usan sólo un par de geeks, por lo que no es muy sabio no considerarlo.

¿Cómo implementar redirecciones para usar dominios canónicos?

Afortunadamente, implementar la configuración necesaria para utiliza un dominio canónico es relativamente sencillo de ejecutar en los servidores web más usados. Debemos considerar lo siguiente:

• La redirección debe ser transparente al usuario: si intenta acceder a dominio.com/noticias/lorem-ipsum-dolor-sit-amet/ y has preferido la versión “con www” de tu dominio, le debe llevar automáticamente a www.dominio.com/noticias/lorem-ipsum-dolor-sit-amet/ (¡no redirigir todas las direcciones bajo los dominios alternativos a la raíz del sitio!)
• La redirección debe ser clara para los buscadores, lo que conseguimos enviando una respuesta HTTP con código 301 Permanent Redirect, es decir, indicando la URL canónica como definitiva

Veamos algunos ejemplos, considerando que nuestra URL canónica será www.domain.com:

… por supuesto, en cada caso debemos cerciorarnos que los módulos necesarios estén activados.

Tags: apache, lighttpd, nginx, seo, servidores

Related posts

• VPS local con Ubuntu y VirtualBox (6)
• Tres trucos para OJS (5)
• Soporte para ImageMagick en PHP con LAMPP (1)
• Próximamente en WordPress: numeración inversa de páginas (1)
• Intentando montar un VPS (4)

El libro se enfoca en lograr una buena base y fomentar buenas prácticas en el desarrollo plugins o funcionalidades con AJAX, y a partir de eso plantea el análisis de tres plugins. Si bien sus explicaciones son bastante detalladas, es necesario tener un conocimiento básico de javascript y WordPress, y algo más acabado de PHP.

Tags: ajax, descargas, e-book, javascript, programación, WordPress

Related posts

• WordPress Tips: Utiliza el parámetro action para determinar la acción que estás realizando (1)
• Usa parámetros variables en tus funciones con wp_parse_args (WordPress Tips) (0)
• Tres usos para jQuery.extend() (1)
• Trabajar con fechas en Javascript (2)
• Trabajando con datos serializados en WordPress (3)

A una semana desde que Google comenzara a aplicar su nueva política de privacidad, y aunque a primera vista pareciera que estos cambios no alteran fundamentalmente nuestro trato con el buscador, probablemente recién estamos en la víspera de las transformaciones más profundas.

Al respecto, la semana pasada comentaban en TheNextWeb sobre las implicancias que estos cambios tendrían en nuestros procesos de búsqueda: An information paradox: How Google’s new privacy policy may harm our discovery process.

There’s really nothing we can do. Google is going to change its privacy policy and we’re going to keep using its products. Simply because it’s incredible and addicting to have so much information pouring out of a screen. Google has us by the proverbial (digital) balls. But in a very short while it’s going to be essential we become more responsible searchers, more savvy web surfers. Interneters that actively search for things they disagree with and Googlers that get to the fifth page of their search results. Because soon the world’s information will be filtered through the habits and dependencies of the most biased, unforgiving and scary editor of all: ourselves.

Y en el mismo tema, vale la pena recordar la presentación que Eli Pariser dio en TED en marzo pasado: cuidado con la “burbuja de filtros” en la red

Tags: cultura digital, Google, privacidad

Related posts

• WordPress 2.3 y las preocupaciones por la privacidad (3)
• Tareas (1)
• Sin querer queriendo (0)
• Mejorando la privacidad en BitTorrent (1)
• Jeff Jarvis en TEDx (1)

php-mobile-detect es una clase en PHP para detectar las plataformas móviles más importantes: Android, iOS, BlackBerry, Opera Mini, Palm, Windows Mobile y móviles genéricos. Además, permite diferenciar entre móviles y tablets.

Su forma de funcionamiento es muy sencilla:

<?php

include('Mobile_Detect.php');
$detect = new Mobile_Detect();

if ( $detect->isAndroidtablet() || $detect->isIpad() || $detect->isBlackberrytablet() ) {
	// mostar versión para tablets
} elseif( $detect->isAndroid() ) {
	// versión Android
} elseif ( $detect->isIphone() ) {
	// versión iPhone
} elseif ( $detect->isMobile() ) {
	// versión para otros móviles
} else{
	// versión "normal"
}

?>

La lista completa de métodos es: isAndroid(), isAndroidtablet(), isIphone(), isIpad(), isBlackberry(), isBlackberrytablet(), isPalm(), isWindowsphone(), isWindows(), isGeneric(), isMobile()

Tags: móviles, php, programación

Related posts

• WordPress Tips: Utiliza el parámetro action para determinar la acción que estás realizando (1)
• Usa parámetros variables en tus funciones con wp_parse_args (WordPress Tips) (0)
• Trabajando con datos serializados en WordPress (3)
• PHP te facilita la vida (6)
• Manuales de PHP (7)

Una secuencia de acciones me llevó a una situación terrible: por un momento pensé que había perdido un conjunto de cambios del historial. La condiciones fueron más o menos las siguientes:

1. Estaba trabajando en una copia local sobre la cual no sabía que estaba bindeada a un repositorio remoto (o sea, un checkout)
2. Hice commit de un conjunto de cambios (que se grabaron con número de revisión 5)
3. Ejecuté un bzr bind, con lo se aplicaron una serie de cambios que estaban en el repositorio remoto
4. La versión del repositorio local bajó a 4… ¡los cambios realizados en la 5ª versión no estaban en ninguna parte!

En resumen, lo que había ocurrido era que había cambiado de línea temporal (al mejor estilo Fringe). Transformar nuevamente la copia en una rama no solucionaba nada, sin embargo suponía que esa revisión debía existir en el repositorio…. ¿cómo restituirla?

La respuesta es conceptualmente sencilla: todo lo que necesitamos hacer es traer los cambios de esa revisión al estado actual de nuestro árbol de trabajo; y a pesar que los números de revisión de bzr son dígitos, en realidad cada commit tiene un identificador único que podemos utilizar para recuperar esos cambios.

En este caso, para recuperar esos cambios debemos ejecutar en primer lugar bzr heads --all, con lo que podremos ver las últimas versiones que conviven en el historial de cambios, por ejemplo:

TIP of branch: /var/www/repo.bzr/master/
HEAD: revision-id: user@domain.com-20111220131621-ao5rkri1o80evnhh
  committer: Felipe Lavín <user@domain.com>
  branch nick: master
  timestamp: Tue 2011-12-20 10:16:21 -0300
  message:
    mensaje del commit

Luego, para recuperar los cambios extraviados:

bzr pull . --overwrite -r revid:user@domain.com-20111220131621-ao5rkri1o80evnhh

… y podemos seguir trabajando con normalidad.

Tags: bazaar, bzr, control de versiones, howto

Related posts

• Migrar un proyecto desde SVN a Bazaar (2)
• Control de versiones centralizado con Bazaar (0)
• Tres consejos para ser un buen (mejor) blogger (11)
• Personalizar las opciones del TouchPad Synaptics en Linux (7)
• Ordenar elementos alfabéticamente en Word (100)

Afortunadamente, los clientes más nuevos y populares han incluido un par de opciones que nos permiten aumentar (aunque sea sólo un poco) el nivel de privacidad de nuestras conexiones.

Las opciones que nos interesan son fundamentalmente dos:

• Activar el cifrado de las conexiones para evitar la escucha del tráfico por parte de terceros.
• Configurar una lista de bloqueo de IPs para bloquear distribuidores de malware, spyware y otras molestias

Adicionalmente, si te sientes especialmente paranoico, puedes desactivar el intercambio de pares a través de DHT, puesto que al activar esta opción vas a compartir tu dirección IP y otros datos a través de una red distribuída — por otra parte, al desactivarla probablemente vas a tener menos pares y vas a depender en mayor medida de los pares que estén registrados en el tracker central.

En Transmission

Transmission es cliente pequeño y sencillo, pero con las opciones justas. Está para varias distribuciones de Linux (en Ubuntu viene preinstalado) y Mac.

Para activar estas opciones, debemos ir a Editar → Preferencias y luego a la pestaña Privacidad.

1. Activa la opción para habilitar la lista de bloqueo. Puedes obtener buenas listas de bloqueo desde I-BlockList; donde encontrarás listas clásicas como las level-1, level-2 y level-3, en orden ascendiente según tu nivel de paranoia. Tan solo debes copiar la URL y pegarla en el campo indicado. El programa refrescará automáticamente la lista de bloqueos de modo que permanezca actualizada.
2. En la sección Privacidad, selecciona el modo de cifrado: permitir, preferir o requerir. A estas alturas, me parece que la gran mayoría de clientes de BitTorrent traen alguna opción de cifrado activada por defecto, por lo que la opción de requerir cifrado no debería darte mayores problemas.

Si deseas desactivar el intercambio de pares por DHT, puedes hacerlo en la misma pestaña.

En Deluge

Deluge es un cliente liviano y multiplataforma, disponible para Linux, Mac y Windows.

Para activar las opciones de privacidad, debes ir a Editar → Preferencias y luego

1. En la categoría Red, activar las opciones de cifrado: forzado tanto para entrante como saliente, flujo completo en el nivel y activar la casilla de cifrar flujo completo
2. Si aun no lo has activado, anda a la categoría Complementos y activa Blocklist
3. En la categoría Lista de bloqueados, ingresa una de las alternativas disponibles en I-BlockList. Puedes indicar cada cuántos días quieres refrescar la lista de bloqueos (yo lo tengo cada 5) y ya estás listo.

Finalmente, si quieres desactivar DHT, debes hacerlo también desde la categoría de Red, en la sección de Extras de red.

Tags: bittorrent, P2P, privacidad

Related posts

• WordPress 2.3 y las preocupaciones por la privacidad (3)
• Torrents de los conciertos de Pearl Jam en Chile (35)
• Sin querer queriendo (0)
• Servidor de música DAAP en Ubuntu (0)
• Qué pasa en el negocio de la música (4)

La plataforma Estorninos es un espacio diseñado para la conformación de una comunidad, donde los alumnos se puedan formar en un cuerpo organizado, desde el cual participen en el hacer universidad, que se concreta a través de 4 módulos de abierta participación: proyectos, debates, eventos y notas.

El desarrollo del proyecto está en un estado alpha funcional, y continuará su marcha durante el próximo año, con el objetivo de convertirse en una solución extensible bajo la forma de un conjunto de un tema y plugins para WordPress, distribuido libremente bajo una licencia FOSS. El proyecto está ampliamente documentado en la Wiki de e[ad], donde pueden ver sus fundamentos, metas y logros.

Tags: Diseño, diseño de interacción, estorninos, e[ad], Personal, proyectos, WordPress

Related posts

• Pequeña actualización de Satori (3)
• eduStyle: inspiration for campus web designers (5)
• WordPress: no sólo blogs (7)
• Un nuevo tema para yukei.net (II) (0)
• Typographic: un tema tipo-tumblelog para WordPress (21)

Uno de estos proyectos ha sido el rediseño de un sitio bastante grande y complejo que hemos desarrollado en AyerViernes y que hasta ahora se encuentra versionado con svn, pero que queremos trasladar a Bazaar por la buena experiencia que hemos tenido. En este proyecto frecuentemente se realizan cambios al modo de funcionamiento de sus diversas características o se agregan nuevas funcionalidades, por lo que no podíamos trabajar bajo el supuesto de congelar el trabajo en el sitio actual y migrar todo inmediatamente a la nueva versión en desarrollo; en síntesis, debíamos ser capaces de:

• Seguir implementando cambios en la versión en producción
• Desarrollar paralelamente la nueva versión, sin interferir con la anterior
• Poder incorporar los cambios de la versión en producción a la versión en desarrollo

Afortunadamente, Bazaar puede interoperar con Subversion gracias a un plugin llamado (adecuadamente) bzr-svn, disponible en los repositorios de Ubuntu.

La estrategia que utilizamos demuestra la flexibilidad y potencia de Bazaar. Los pasos a seguir serían aproximadamente los siguientes:

Preparación

Si aún no lo tienes, lo primero es instalar el plugin bzr-svn. En Ubuntu esto se puede lograr con sudo apt-get install bzr-svn desde el terminal.

Luego, crear un repositorio compartido bajo el cual almacenaremos tanto la versión online (en producción) como sobre la cual trabajaremos el rediseño (versión de desarrollo), cada una de ellas como una rama (branch).

Al utilizar un repositorio compartido, las revisiones se almacenan en el repositorio en lugar de en cada rama, lo que permite optimizar drásticamente la utilización de espacio y crear nuevas ramas velozmente. Para inicializar el repositorio compartido, debemos ejecutar bzr init-repo proyecto.repo

Importar el historial de versiones

Una vez que está creado el repositorio compartido, nuestro objetivo será importar los archivos y el historial del proyecto desde el repositorio SVN donde se está trabajando actualmente, lo que podemos realizar de diversos modos dependiendo de la forma en que esté organizado el repositorio SVN.

Para ello contamos con dos opciones proporcionadas por el plugin: podemos importar solo una parte del repositorio SVN (por ejemplo, solamente el trunk o una de las ramas) o bien hacer una copia completa del repositorio (incluyendo todas las ramas y etiquetas además del trunk).

Para el primer caso, tenemos la opción de crear una nueva rama a partir de la versión seleccionada tal como si lo estuviésemos haciendo desde una rama de Bazaar: bzr branch svn://servidor.com/proyecto trunk, con lo que Bazaar importará todo el historial de versiones a la nueva rama junto con crear un árbol de trabajo con la última versión de los archivos. Por otra parte, si deseamos que los commits en este árbol siempre se suban al repositorio svn, también contamos con la opción de hacer un checkout (o bien pasar desde una rama a un checkout con bind/unbind).

Para el segundo caso, podemos utilizar el comando bzr svn-import svn://servidor.com/proyecto repositorio. Bazaar importará todo el historial de versiones, pero no creará el árbol de trabajo a menos que agreguemos la opción --trees.

Trabajo en una nueva rama como “feature branch”

Suponiendo que hemos utilizado la primera de las opciones recién indicadas, tendríamos lo siguiente:

$ cd /var/www
# Inicializar el repositorio compartido
$ bzr init-repo proyecto.repo
# Importar el historial del proyecto
$ cd proyecto.repo
$ bzr branch svn://servidor.com/proyecto trunk

Y llegamos finalmente al momento en que comenzaremos a trabajar en la nueva versión. Para ello, crearemos una nueva rama en el repositorio compartido, donde ejecutaremos todos los cambios necesarios para el desarrollo de la nueva versión.

# Crear rama de desarrollo
$ cd /var/www/proyecto.repo
$ bzr branch trunk feature-branch
$ cd feature-branch
# hack, hack, hack...

A partir de este punto, lo que queda es introducir todas las modificaciones que sean necesarias en nuestra nueva versión — dado que es una rama, los commits de cambios serán locales al repositorio. Nuestro flujo de trabajo sería básicamente el siguiente:

De este modo, la mantención del proyecto puede continuar de forma paralela al nuevo desarrollo, sin cruzarse entre sí a menos que así lo queramos. Si hubiesen cambios en el sitio en producción que se envíen al repositorio SVN, podríamos integrarlos dentro de nuestra versión de desarrollo con los siguientes pasos:

# Ingresamos a la rama ligada al sitio en producción
$ cd /var/www/proyecto.repo/trunk
# Obtener los cambios desde el repositorio SVN
$ bzr pull # O bzr up si es un checkout
# Cambiar a la rama en desarrollo
$ cd ../feature-branch
# Incorporar los cambios de producción al nuevo desarrollo
$ bzr merge ../trunk

Del mismo modo, cuando queramos integrar los cambios de la versión en desarrollo a la rama principal, también recurriremos a bzr merge, de modo de preservar el historial que la rama en producción (el “trunk” del ejemplo).

$ cd /var/www/proyecto.repo/trunk
# Mezclar cambios de desarrollo en la versión de producción
$ bzr merge ../feature-branch

Es importante recalcar la utilización de merge, y no un push desde feature-branch al trunk, ya que de otro modo sobreescribiremos el historial de versiones del trunk.

Ya en este punto, podremos chequear que todos los cambios que introdujimos se complementan bien con los últimos cambios del sitio en producción. Una vez que se hayan alisado todas las asperezas, podemos enviar finalmente nuestros cambios desde /var/www/proyecto.repo/trunk con un bzr push hacia el repositorio SVN.

Colaboración con otros desarrolladores

Hasta acá tenemos la versión simplificada, pero lo más probable es que durante el desarrollo debamos cooperar con compañeros de equipo encargados de otras piezas del puzzle… a partir de lo anterior, podemos seguir expandiendo el modelo para incorporar estas nuevas posibilidades: nuestros compañeros pueden crear nuevas ramas locales en sus respectivos equipos, o bien montar un checkout donde implementar cambios que luego serán enviados a nuestro repositorio.

De este modo, una versión más completa del esquema anterior sería la siguiente:

Como se puede ver, existen muchas alternativas para organizar el trabajo en la forma que sea mejor para tu equipo; y lo que es mejor aún, es muy fácil implementar otras variantes que vayan siendo más apropiadas según el desarrollo del proyecto.

Tags: bazaar, control de versiones, flujos de trabajo, programación

Related posts

• Control de versiones centralizado con Bazaar (0)
• Recuperar revisiones perdidas en Bazaar (0)
• WordPress Tips: Utiliza el parámetro action para determinar la acción que estás realizando (1)
• Usa parámetros variables en tus funciones con wp_parse_args (WordPress Tips) (0)
• Tres usos para jQuery.extend() (1)

Una opción para guardar estos datos sería recurrir a alguna convención de nombres de modo que cada dato se almacena como una fila en la tabla $wpdb->postmeta; algo como _persona_telefono, _persona_email, _persona_direccion, etc. Luego, al mostrar los datos podríamos hacer una consulta como SELECT * FROM $wpdb->postmeta WHERE post_id = $post_id AND meta_key LIKE '_persona%'.

Sin embargo, una mejor alternativa en este tipo de casos sería recurrir a la utilización de datos serializados, ya que nos permitirán guardar en un solo campo una estructura compleja de datos como un array (uni o multidimensional) o un objeto; lo que nos puede facilitar de forma importante varias tareas si planificamos con cuidado nuestra estructura de datos.

Por qué y cuándo preferir datos serializados en WordPress

Me atrevería a decir que en general los especialistas en bases de datos relacionales no miran con muy buenos ojos la utilización de este tipo de técnicas (ya que idealmente, cada objeto debiese estar modelado de acuerdo a un esquema que permita optimizar el rendimiento de la base de datos), sin embargo en WordPress muchas veces nos encontraremos con la necesidad de guardar un conjunto limitado (no necesariamente fijo) de datos relacionados y sin un esquema inmutable en la base de datos, ya sea como metadatos de un post (o un tipo de contenido personalizado), de un comentario o un usuario, o bien como opciones de un plugin — convenientemente, WordPress nos provee de APIs para interactuar de forma sencilla con la base de datos en estos casos, en los que la serialización de datos ya está considerada como parte del proceso de lectura/escritura desde/hacia la base de datos.

Por lo tanto, el trabajo con datos serializados nos presenta una serie de ventajas, como:

• Mejor performance, al obtener un solo valor desde la base de datos en lugar de múltiples filas
• Mayor orden, al trabajar con una estructura de datos más evidente con el solo hecho de obtener la información requerida
• Mayor simplicidad al momento de guardar o recuperar datos, ya que sólo tendrás que recurrir a un campo
• Menos posibilidades de tener conflictos con datos insertados por otros desarrolladores, ya que es más fácil utilizar un nombre único para tus claves de búsqueda

Cómo trabajar con los datos serializados

Como decía anteriormente, WordPress nos hace este trabajo muy simple, ya que las APIs de metadatos para posts, comentarios y usuarios, tanto como el API de opciones ya contemplan la posibilidad de trabajar con datos serializados.

Retomando el ejemplo del principio:

// esta es la información sanitizada a partir del envío del formulario
$person_data = array(
	'tel' => '+1 012 345 678',
	'email' => 'homero@plantanucleardespringfield.com',
	'adr' => array(
		'street-address' => 'Avenida Siempre Viva 742',
		'locality' => 'Springfield',
		'region' => '??'
	)
);

// para guardar los datos
// (el "_" antes del nombre de la opción hace que
// no se vea en la lista de campos personalizados)
update_post_meta($post->ID, '_person_data', $person_data);

// para obtener los datos
// devuelve un array similar a $person_data
get_post_meta($post->ID, '_person_data', true);

No es necesario serializar los datos antes de guardarlos ni des-serializarlos al obtenerlos, ya que WordPress internamente determinará si es necesario hacerlo (mediante las funciones maybe_serialize y maybe_unserialize, respectivamente).

Cuándo NO ocupar datos serializados

Quizás alguien a estas alturas estará pensando “¿bueno, y cuáles son las desventajas?”… muy suspicaz, ¿eh? Quizás no lo suficiente.

Al serializar el array anterior, la información que se guarda en la base de datos corresponde a:

a:3:{s:3:"tel";s:14:"+1 012 345 678";s:5:"email";s:36:"homero@plantanucleardepsringield.com";s:3:"adr";a:3:{s:14:"street-address";s:24:"Avenida Siempre Viva 742";s:8:"locality";s:11:"Springfield";s:6:"region";s:2:"??";}}

En primer lugar, habría que plantear lo obvio: cada vez que obtienes el valor necesitarás transformarlo a su representación correcta (array u objeto). A partir de ello, no tiene mucho sentido usar esta técnica cuando los datos que se almacenan no tienen mucha relación entre sí y se utilizan siempre de forma individual. Por otra parte, tampoco convendría guardar cantidades demasiado grandes de información de este modo, ya que el gasto de procesamiento y memoria sería demasiado alto.

El valor serializado que se guarda en la base de datos es simplemente una cadena de texto … el problema surge cuando queremos buscar algún dato en particular (ya que no será tan sencillo como buscar en un campo que tiene un texto simple) o bien al utilizar un dato como condición en en SELECT (por ejemplo, cuando se utiliza un campo de la tabla postmeta para obtener un conjunto de posts).

Sin embargo… aquí si conviene ser más estricto en temas de bases de datos, ya que en todos los casos contemplados (meta datos de posts, usuarios, comentarios; opciones) el campo donde se almacenan los valores (meta_value, option_value, etc) no tiene índice, por lo que las consultas que utilizan estas condiciones están fatalmente sub-optimizadas: por ejemplo, al hace una consulta como SELECT * FROM $wpdb->postmeta WHERE meta_key = '_persona_ciudad' AND meta_value = 'Springfield', la base de datos debe revisar todos los registros de la tabla en busca de coincidencias (esto no ocurre al hacer consultas como SELECT * FROM $wpdb->postmeta WHERE post_id = $post_id AND meta_key = '_person_data' ya que en esas columnas existen índices que permiten que la base de datos devuelva rápidamente los valores coincidentes con los criterios indicados).

Por lo tanto, si deseas guardar muchos datos que pueden servir como criterios de búsqueda, la mejor opción en ese caso será crear una tabla especial para esa información, que te permita definir los índices adecuados según las necesidades del programa.

Tags: performance, php, plugins, programación, rendimiento, WordPress

Related posts

• Usando la API de Transients en WordPress (0)
• WordPress Tips: Utiliza el parámetro action para determinar la acción que estás realizando (1)
• Usa parámetros variables en tus funciones con wp_parse_args (WordPress Tips) (0)
• PHPSpeedy: mejora el tiempo de carga de tu sitio (6)
• PHP te facilita la vida (6)

Pensando un poco por las razones que uno podría tener para dispararse en el pie de este modo, creo que hay al menos tres motivos que podrían influir en esta decisión.

Creer que quien te vende el acceso a internet también debe ser un experto en hosting

… después de todo, no es tan descabellado pensar que son expertos en infraestructura y deberían tener las competencias para poder manejar ambos aspectos del negocio… lo que sabemos que no es necesariamente cierto: en general el servicio de hosting que venden los ISP está atado al paquete de servicios contratados o bien es tan limitado que no aguanta nada que se más que un simple sitio tipo panfleto.

La búsqueda que sigue a partir de este punto suele terminar con alguno de los resultados de la primera página para “hosting {inserte su país aquí}” en Google: por lo general con una web que parece un homenaje a los 1990s, y que se preocupa de utilizar términos que parecen muy técnicos pero no aportan nada.

Que puedes pagar con cheque o transferencia bancaria, en moneda local

A pesar de que prácticamente todos los navegadores se han preocupado de aumentar y resaltar sus características de seguridad, al tipo de cliente que prefiere contratar un hosting nacional le preocupa más que le puedan hacer un cargo en la tarjeta de crédito (probablemente porque ha visto algún reportaje en las noticias de la televisión o en alguna película de hackers) a que lo estafen mensualmente en su cara, y contratar un servicio malo que puede pagar con un cheque o una transferencia bancaria a uno que debe pagar con tarjeta de crédito en un servicio que le puedas recomendar.

Lo criticable no es el hecho de querer tomar sus decisiones en torno al servicio que quisieran contratar, más bien que de fondo probablemente está la idea que su sitio es simplemente uno más de los gastos de la oficina, como el agua o la electricidad, y que con el solo hecho de pagar la cuenta mensualmente su sitio debiera funcionar por sí mismo, sin preocuparse de crear contenidos ni hacer ningún tipo de mantención — es el tipo de sitio que encuentras con una noticia con más de un año de antigüedad… sobre su nuevo sitio.

Que hablan tu idioma y tienes “a quién llamar”

Probablemente el argumento más poderoso a la vez que el más engañoso. En lo personal, me parece inexplicable la especie de fascinación que a algunas personas les produce tener un “ejecutivo de cuenta” que les plantee un servicio “a la medida”, como si se tratara de una cuenta de banco o un sastre.

Por otra parte, está la confianza ciega en que el personal de servicio técnico hable en tu idioma, lo que difícilmente podría ser una ventaja ya que si hay un fallo en el sitio o si por alguna razón el sitio se ve comprometido, el servicio técnico del hosting no es el que va a responder ni solucionar el problema: si el problema es a nivel de la aplicación, con razón podrían argumentar que no es de su responsabilidad (aunque si es así, no tiene mucho sentido contar con el servicio técnico del hosting, sino más bien con una mantención de quien desarrolló el sitio, ¿no?), pero por otra parte, si el problema es realmente de más bajo nivel y responsabilidad directa del hosting, entonces la cuestión no debería recaer en que puedas llamar a alguien para que solucione el problema, sino en que esos problemas no se produzcan, y si bien todo sistema es susceptible a fallos, un buen proveedor no necesita que le digan “esto está fallando” para saber que tiene algo que solucionar.

La trampilla del “tener a quién llamar” pasa también por vender cosas que no son tal como las pintan: por una parte, están los que promueven a cPanel o Plesk como entornos “amigables” o “autoadministrables” (vaya a saber uno qué significa esto para ellos) como si cualquier persona fuera a entender mágicamente todas las opciones que se le ofrecen; mientras que por otra están los que se ufanan de tener un panel de control propio y que salvo contadas excepciones suelen ser engendros horripilantes y poco funcionales.

Finalmente, están también los que exhiben como medallas de guerra sus certificaciones de Microsoft, Oracle y Java, pero que te miran como si estuvieras hablando en zulu (o peor, condescendientemente como a un párvulo) cuando planteas que estás trabajando sobre PHP+MySQL, WordPress y “todas esas cosas hippientas de software libre/código abierto”. Algunos llegan a afirmar que nadie da soporte a “esas cosas”, por lo que ellos sólo garantizan, básicamente, que el servidor está conectado a la electricidad, pero de ahí en más no es su responsabilidad.

¿Y cuál es la moraleja?

No estoy tratando de hacer una fábula, pero hay algunas cosas que podemos sacar en limpio:

• Negocia tus contratos hasta la entrega del sitio, no la puesta en producción: muestra el sitio funcionando en tu propio hosting para que tu cliente lo pruebe a sus anchas, pero haz una entrega en CD con los archivos del sitio, base de datos, manual de uso e instalación, etc. Puede que parezca cavernícola, pero te permitirá poder poner fin al proyecto cuando lo que es de tu responsabilidad ya se haya dado por cumplido.
• Recuérdate y recuérdale a tu cliente que el objetivo de su trabajo conjunto es llegar a tener un sitio funcionando. Plantea la puesta en línea del sitio como un mini-proyecto adicional de acuerdo a las características del hosting que decida contratar, ya que de acuerdo a esto podría ser desde una tarea de un par de horas a días enteros peloteando e-mails con los de soporte.
• Aconseja a tu cliente, guíalo y edúcalo en las características del producto que le estás vendiendo. Entrégale la documentación adecuada y la información sobre las condiciones necesarias para que su sitio web funcione correctamente.

Siempre trata de anticipar y solucionar los escollos que puedan encontrar en este paso que debería ser un mero trámite. Un desarrollo no implementado le sirve tan poco a tu cliente como a tu portafolio y reputación.

Tags: Desarrollo Web, Estrategia, metodología

Related posts

• WordPress: no sólo blogs (7)
• YUI y otros Frameworks CSS (4)
• Yo [corazón] WordPress (6)
• Y tenemos WordPress 2.1 (2)
• XHTML Semántico aplicado a listas (11)