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)
• 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)

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)

(cc) Lizzybethhh (flickr)

… a pesar que desde Twitter y Facebook, ahora todos los años alguien dice que los blogs se acabaron, aún quedamos algunos dando vueltas… aunque publiquemos cada vez menos — se me hace más posible que hayan menos blogs (como los de antes, quiero decir) porque todos los bloggers consiguieron trabajo (gracias a sus blogs) más que cualquier otra cosa… al final, sólo es falta de tiempo.

Aunque tampoco debiera ser tan fatalista: desde el año anterior hasta ahora, estoy con un promedio de 1 post por mes (que es poco, pero es mejor que nada)… y continuando con los anuncios que no le importan a nadie: estoy probando un cloud server en Rackspace (también-conocido-como “humilde servidor”, props para @pedroarellano) y acabo de dar de baja un servicio de publicidad que prometía mucho pero resultaba una molestia más que nada (no para mí, sino para los pocos valientes que aún se pierden por acá)… ¡ah! y por fin tengo un proceso de desarrollo ordenado (ya no más “en casa de herrero, cuchillo de palo”).

En fin… si me dedico a terminar el montón de borradores que tengo por ahí, queda yukei.net para rato.

Tags: Weblogs, Yukei

Related posts

• Un nuevo tema para yukei.net (II) (0)
• De vuelta a lo básico… ¿? (0)
• ¿La micropublicación mató al blog? (0)
• yukei.net cumple tres años (7)
• Yo [corazón] WordPress (6)

Quizás uno de sus puntos débiles es que no existen paquetes disponibles para Ubuntu ni Debian, por lo que su actualización es un poco menos que obvia, pero de todos modos resulta bastante sencilla.

Al modo de Firefox, Komodo te notificará cuando exista una nueva versión disponible (al menos cuando se trate de actualizaciones menores), pero junto con eso presentará un aviso que, en resumen te indicará que con tu cuenta actual no tienes privilegios para poder actualizar el software.

Para solucionar esto, la forma más sencilla es abrir la terminal y dirigirte al directorio donde está instalado Komodo, en mi caso, /var/opt/active-state/. Una vez en esa carpeta, debes iniciar el programa como administrador, lo que puedes hacer de forma fácil y segura (con la tranquilidad que no existirán cambios de permisos u otros que pudieran dificultar el uso posterior) con gksu bin/komodo.

Una vez iniciado el software, dirígete al menú Help → Check Updates y ejecuta la actualización. Reinicia el programa (aun como gksu) y listo… ya puedes volver a ejecutarlo como usuario normal.

Tags: IDE, Komodo Edit, Open Source, programación, Software, Ubuntu

Related posts

• Komodo Edit, editor de código multiplataforma (4)
• Servidor de música DAAP en Ubuntu (0)
• Y tenemos WordPress 2.1 (2)
• Xubuntu (VII): Síntesis y evaluación final (27)
• WordPress y Habari (27)

• poder aceptar una cantidad variable de argumentos, sin importar el orden en que estén declarados y además con la posibilidad de aumentar los argumentos que la función recibe sin tener problemas de compatibilidad
• aceptar argumentos como una cadena de consulta(query string)o como array
• poder dotar de opciones predeterminadas para cada uno de los argumentos de la función, de modo que la mayoría de las veces sólo debamos indicar un par de variaciones para utilizarla efectivamente

Según el Codex: se usa a través de WordPress para evitar tener que preocuparse sobre la lógica de las opciones predeterminadas y los inputs, y produce un patrón estable para pasar argumentos.

Aprovecharlo en tus funciones es muy sencillo. Veamos algunos ejemplos.

Supongamos que queremos tener una función muy sencilla para mostrar la fecha actual, pero a la que queremos dar algo de flexibilidad para, por ejemplo, poder mostrar otras fechas que le podamos indicar como parámetro.

function show_date( $args = null ){
	$s = wp_parse_args( $args, array(
		'format'    => 'j F Y',
		'date'      => time(),
		'echo'      => false,
		'class'     => 'date-now',
		'translate' => true
	) );
	$out = '<span class="'. esc_attr( $s['class'] ) .'">';
	if ( $s['translate'] ) {
		// si queremos obtener la fecha en el idioma de la instalación de
		// WordPress, utilizaremos la función date_i18n()
		$out .= date_i18n( $s['format'], $s['date'] );
	} else {
		$out .= date( $s['format'], $s['date'] );
	}
	$out .= '</span>';
	if ( $s['echo'] ) echo $out;
	else return $out;
}

En este caso, la mayoría de las veces podríamos utilizar la función llamando simplemente a show_date( ), sin ningún parámetro (ni siquiera $args es requerido), pero en otros casos contamos con una buena cantidad de opciones para poder reutilizar la función en distintos contextos, por ejemplo: show_date('echo=0&class=otra-clase').

En este caso, dado que podríamos utilizar la función sin indicar ningún parámetro, en la definición de la función $args es igual a null, ya que wp_parse_args() espera recibir exactamente dos parámetros: los argumentos que la función está recibiendo ($args) en forma de array o query string, y un array de valores predeterminados.

Por supuesto, también se puede dar el caso que tu función necesite recibir argumentos para hacer lo suyo; en ese caso podrías declarar esos argumentos de forma separada a los que trabajará wp_parse_args.

Por ejemplo, una función que suelo utilizar para construir select:

/**
 * Create an HTML select
 * @param array $els Array with the select options, the array key is the "value" attribute that will be sent with the form and the array value is the option text
 * @param array|string $args Select attribute options, selected items and other arguments
 * @return string Select
 * @author Felipe Lavín <felipe@yukei.net>
 **/
function create_select($els, $args){
	$s = wp_parse_args($args, array(
		'id'               => null,
		'echo'             => false,
		'size'             => null,
		'class'            => null,
		'style'            => null,
		'multiple'         => false,
		'selected'         => null,
		'__checkboxes'     => true,
		'show_option_all'  => false,
		'show_option_none' => false,
	));
	$multiple_values = ( is_array( $s['selected'] ) ) ? true : false;
	$do_cb = ( $s['__checkboxes'] && ( $multiple_values || $s['multiple'] ) ) ? true : false;
	$atts = ( $do_cb ) ? array('id', 'class', 'style') : array('id', 'name', 'class', 'size', 'multiple', 'style');
	$selected = $do_cb ? ' checked="checked"' : ' selected="selected"';
	if ( !empty($els) ) {
		$out = ( $do_cb ) ? '<ul' : '<select';
		foreach($atts as $k){
			if ( !is_null( $s[$k] ) && $s[$k] !== false ) {
				switch($k):
					case 'multiple':
						$out .= ' multiple="multiple"';
						break;
					case 'name':
						$out .= $s['multiple'] ? ' name="'. $s['name'].'[]"' : ' name="'. $s['name'] .'"';
						break;
					default:
						$out .= ' '. $k .'="'. esc_attr( $s[$k] ) .'"';
				endswitch;
			}
		}
		$out .= '>';
		if (!$do_cb ) {
			// "none" could be empty, but "all" should be a string
			if ( $s['show_option_none'] !== false ) {
				if ( is_array( $s['show_option_none'] ) ) {
					$out .= '<option value="'. key( $s['show_option_none'] ) .'">'. current( $s['show_option_none'] ) .'</option>';
				} else {
					$out .=	'<option value="-1">'. $s['show_option_none'] .'</option>';
				}
			}
			if ( $s['show_option_all'] != false ) $out .= '<option value="_all">'. $s['show_option_all'] .'</option>';
		}
		foreach ( $els as $key => $val ) {
			if ( !$multiple_values ) $active = $s['selected'] == $key ? $selected : null;
			else $active = in_array( $key, $s'selected'] ) ? $selected : null;

			// So we can directly pass query results
			if ( is_object( $val ) && isset( $val .'_'. $key .'"><input'. $active .' type="checkbox" value="'. $key .'" name="'. $s['name'] .'[]" id="cb_'. $s['id'] .'_'. $key .'" /> '. $val .'</label></li>';
			else
				$out .= '<option value="'. $key .'"'. $active .'>'. $val .'</option>';
		}
		$out .= ( $do_cb ) ? '</ul>' : '</select>';
		if ( $s['echo'] ) echo $out;
		else return $out;
	} else {
		return false;
	}

En este caso los dos parámetros son requeridos: el primero porque… porque necesitas elementos para poder construir el select; y el segundo porque determina el output que produce la función.

Algunas notas para finalizar:

• Al mezclar los argumentos recibidos con los predeterminados los primeros no se filtran, por lo que podrías pasar argumentos que no estén considerados en la misma función a la que se los estás pasando…
• Por lo mismo, si dentro de tu función invocarás otras como query_posts, get_posts o crearás objetos de WP_Query es buena idea filtrar qué argumentos pasarán de un lado a otro.
• Por otra parte esto te puede dar una gran flexibilidad si, por ejemplo, usas este patrón como parte de un constructor de clase

Ah, y por cierto, en jQuery puedes lograr algo bastante similar con jQuery.extend()

Tags: buenas prácticas, php, programación, WordPress

Related posts

• WordPress Tips: Utiliza el parámetro action para determinar la acción que estás realizando (1)
• Trabajando con datos serializados en WordPress (3)
• PHP te facilita la vida (6)
• Crear un Tumblelog con WordPress (20)
• Y tenemos WordPress 2.1 (2)

La premisa es relativamente simple: en lugar de entender a la “piratería” como un problema legal, se comprende como un problema originado por deficiencias en la forma de comercializar contenidos.

Un ejemplo: si eras fanático de Lost y vives en un país latinoamericano, probablemente hayas optado por descargar la serie o verla en algún sitio online antes que esperar dos o tres semanas para poder verla por TV paga o meses para ver un mal doblaje en algún canal de televisión abierta… en otras palabras, la opción de recurrir a formas “no oficiales” para consumir la serie se debe fundamentalmente a un problema de acceso: ¿porqué esperar semanas o meses para ver un programa de televisión, si con poco esfuerzo puedo obtener el mismo producto antes?

Y de aquí podemos desprender tres factores clave para la comprensión del problema como un tema de negocios. Asumiendo que los usuarios estarían dispuestos a pagar por los contenidos (que lso contenidos tienen como mínimo la calidad necesaria para interesar a un mercado a adquirirlos):

• El acceso a los productos debe ser inmediata: no tiene sentido hacer fila de una hora para comer helado si al lado los están regalando
• La entrega del producto debe ser impecable: el proceso de compra debe estar diseñado de principio a fin para sugerir la mejor experiencia posible al usuario final — pensemos en facilitar desde el registro a la selección de productos y su pago (¿alguien dijo “compra con un click”?), y por supuesto se debe considerar hasta el consumo (lo que significa nada de software adicional que el usuario deba instalar, ni de codecs raros, ni de restricciones con lo que pueda hacer con su producto legítimamente adquirido)
• La calidad del producto debe ser igual o mejor a la que se podría conseguir gratuitamente — ¡vamos, que hay que vender! ¿Por qué habría de pagar por un MP3 de 320kbps? Por otra parte, si me ofrecen archivos de audio sin DRM y sin pérdida de calidad, la oferta es un poco más interesante… y si tiene un par de bonus tracks, mejor aún… o quizás acceso a una descarga extra. Y obviamente, una transferencia ultra rápida. Y acceso eterno a los productos que haya adquirido. Y si es video, que pueda elegir entre distintas resoluciones, desde una descarga liviana si estoy apurado a formatos portables en smartphones a 720 y 1080p… sin publicidad, lógicamente — en definitiva, ¿cuál es el valor agregado por el que se convencerá a los usuarios de pagar?

Los dejo con los links donde pueden profundizar más en el tema:

• Ars Technica: Competing with free: anime site treats piracy as a market failure
• Cory Doctorow en The Guardian: In the digital era free is easy, so how do you persuade people to pay?
• Enrique Dans: Guía para desarrollar servicios de descarga
• Claudio Ruiz: Mejorar la experiencia, una alternativa al paywall y Las dificultades del despegue del ebook en castellano las crea la industria editorial
• Ricardo Galli: No seamos incautos, Libranda no pretende vender ebooks

Tags: copyright, descargas, ebook, piratería

Related posts

• En contra del cartel del copyright (1)
• Usufructo y atribución (5)
• Los usos justos no son delito (3)
• Anti-(anti-piratería) (2)

Hace algún rato que quería presentar algunos de los trucos o buenas prácticas que he ido descubriendo o aprendiendo al desarrollar temas y/o plugins para WordPress; no espero despertar grandes revelaciones sino poner en discusión nuestras formas de trabajo diarias sobre este sistema.

Comencemos por algo sencillo, casi cosmético… Es algo que primero noté en la misma interfaz de administración de WordPress y que luego de empezar a utilizar en mis propios desarrollos me ha demostrado ser muy valioso: al enviar solicitudes al servidor, siempre utiliza la variable action para determinar la acción que estás realizando.

Ya sea que estés enviando un $_POST o solicitando algo por $_GET, sabrás que action siempre tendrá directa relación con lo que vayas a realizar. Esto resulta aún más conveniente si lo relacionas explícitamente al tipo de datos que estás trabajando: por ejemplo, si en tu plugin vas a crear un evento en un calendario, es bastante lógico que tu action sea algo como add_calendar_event, edit_calendar_event al editar o remove_calendar_event si lo vas a borrar (o simplemente add, edit y remove como métodos de una clase).

Luego, al procesar el formulario puedes tener una estructura de control muy clara y ordenada, por ejemplo:

function calendar_actions(){
	// primero, revisar si está definida la variable; al usar $_REQUEST quedamos cubiertos tanto para $_POST como $_GET
	if ( isset($_REQUEST['action'] ) {
		switch ( $_REQUEST['action'] ) {
			case 'add_calendar_event':
				// procesar acción de agregar evento al calendario
				calendar_event_add();
				break;
			case 'edit_calendar_event':
				// procesar acción de edición de datos del evento
				calendar_event_edit();
				break;
			case 'remove_calendar_event':
				// eliminar evento del calendario
				calendar_event_remove();
				break;
		}
	}
}

Si te das cuenta, las funciones que procesan cada acción también siguen un patrón: calendar sería el nombre del plugin, eventes el objeto sobre el que estoy trabajando, y finalmente la acción que se realiza sobre cada objeto.

He visto plugins donde las acciones desencadenadas por formularios se determinan verificando combinaciones de parámetros que a la larga resultan poco comprensibles. Por ejemplo:

function calendar_actions(){
	if ( !empty($_POST['start_date']) && $_POST['add'] == 'true' ) {
		calendar_add_event();
	} elseif ( !empty($_GET['event_id']) && $_GET['remove'] == 'do' ) {
		calendar_event_remove();
	} elseif ( !empty($_POST['event_id'] && $_POST['edit'] == 'true' ) {
		calendar_event_edit();
	}
}

A la larga, las combinaciones de parámetros se van haciendo cada vez más confusas. Por otra parte, la comprobación y validación de datos se corresponde mejor con las funciones ligadas a cada acción más que a la detección de qué función ejecutar.

Tags: buenas prácticas, php, programación, WordPress

Related posts

• 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)
• Crear un Tumblelog con WordPress (20)
• Y tenemos WordPress 2.1 (2)