Tags: Internet, política

Related posts

• La des/ilusión de la red (0)
• Evgeny Morozov: Cómo la red ayuda a las dictaduras (2)
• [Análisis patrocinado] Tiendas Virtuales de laprimera.net (0)
• YouTube al límite (0)
• Xubuntu (IV): Compartir Internet (2)

No es necesario preocuparnos por tener que escapar caracteres ni escribir demasiado código, ya que a partir de PHP 5.1.0 contamos con la función fputcsv() que se ocupa de prácticamente todo. Un ejemplo sencillo para generar un archivo descargable a partir de una consulta cualquiera a una base de datos:

La función recibe dos parámetros: un archivo (abierto con fopen()) y un array de valores. En el ejemplo, se muestra una forma de generar un archivo CSV descargable a partir de una consulta a la base de datos (utilizando la clase wpdb de WordPress, aunque obviamente podría aplicar para cualquier otro caso).

Por supuesto, también existe la función complementaria para leer un archivo CSV, fgetcsv().

Tags: csv, 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)

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)
• Snippet: generar fácilmente un archivo CSV con PHP (0)
• PHP te facilita la vida (6)

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)