El nuevo PHP

Aunque por mucho tiempo PHP ha sido considerado el patito feo de los lenguajes de programación, lo cierto es que desde que hace aproximadamente un año pudimos confirmar la sospecha de que es por lejos el lenguaje más popular en la web: según cifras de Google, se trata del lenguaje que está tras el 75% de la web.

Pero esta cifra no es la única buena noticia para quienes utilizamos este lenguaje, ya existen varias señales ligadas a su desarrollo y utilización que auguran un futuro cada vez más brillante, al punto que en varios medios se habla del renacer de PHP.

Continue reading “El nuevo PHP”

Curso Diseño Front-End HTML5 + CSS3 en la e[ad]

En una iniciativa conjunta de AyerViernes U y la e[ad] PUCV, hemos gestado un curso de Diseño Front-End HTML5 y CSS3 dirigido a planificadores de productos y servicios, desarrolladores, vendedores, profesionales de usabilidad, diseño, profesionales y gestores que están comprometidos en la creación de una gran experiencia del cliente.

image

Entendemos que diseñar desde el código permite entender las claves de un proyecto digital. El Diseño Front End se preocupa que la capa de negocios que son las interfaces conversen con las plataformas y software que activan el servicio.

Los objetivos del curso son:

  • Comprender las relaciones del Diseño Front End con las diversas disciplinas que cruzan su campo ocupacional
  • Dar valor a la producción del Diseño Front End a partir de sus relaciones con el Diseño de Interfaz e Interacción
  • Adquirir los conocimientos y destrezas técnicas básicas e intermedias para ejecutar el diseño frontend de un proyecto digital
  • Desarrollar las competencias necesarias para liderar el diseño frontend de un proyecto digital

El curso se desarrollará en 4 semanas, a partir del 27 de septiembre.

Puedes descargar el programa del curso o ver más información e inscripciones en el sitio de la Escuela de e[ad].

Sanitizar consultas con cláusulas “IN” con $wpdb en WordPress

Uno de los métodos que incluye la clase wpdb es prepare, que permite preparar una consulta a la base de datos para asegurarnos que se ejecute de forma segura.

Su utilización es bastante sencilla — y si hasta ahora no la estás utilizando deberías leer inmediatamente la sección sobre cómo proteger tus consultas ante ataques de inyección SQL — pero hasta hace poco no había ideado una forma sencilla de preparar consultas con cláusulas IN.

Una solución bastante sencilla que podemos aplicar es la siguiente:

// obtener un listado de IDs de entradas "especiales"
// $special_entries = array(1, 3, 5, 8, 13, [...]);
$special_entries = get_option('my_special_entries');

// ¿cuántas condiciones se van a seleccionar?
$how_many = count($special_entries);

// prepara la cantidad adecuada de reemplazos
// si se buscarán strings, el último parámetro sería '%s'
$placeholders = array_fill(0, $how_many, '%d');

// unir los reemplazos con comas
// $format = '%d, %d, %d, %d, %d, [...]'
$format = implode(', ', $placeholders);

// la consulta
$query = "SELECT ID, post_title, post_name, post_parent FROM $wpdb->posts WHERE post_parent IN($format)";

// obtener los resultados de forma segura
$results = $wpdb->get_results( $wpdb->prepare($query, $special_entries) );

Mejorar la velocidad de carga de dumps de MySQL con InnoDB

Un tip rápido: si notas que al importar dumps de bases de datos que utilizan InnoDB la carga es mucho más lenta que en bases de datos con MyISAM, puedes mejorar bastante la velocidad de carga con algunas opciones de mysqldump:

  • En primer lugar, está la opción --opt, que habilita una serie de alternativas que hacen que la importación sea bastante rápida…
  • … pero si por alguna razón debes utilizar alguna opción no predeterminada al crear el dump (en mi caso, era --skip-extended-insert), puedes utilizar --no-autocommit, que hace que la importación sea tan rápida como utilizando MyISAM

¿La explicación?

Como InnoDB es transaccional, lleva un registro de cada operación.

Con la primera alternativa, sólo se ejecuta un INSERT por tabla, por lo que no necesita realizar muchas operaciones de registro.

Con la segunda alternativa, a pesar que se indican muchos INSERT, sólo se confirman los cambios una vez por tabla ya que los bloques de INSERT van rodeados con set autocommit=0; y un único COMMIT al final.

Tres malas razones para elegir un servicio de hosting

Siempre me ha llamado profundamente la atención esa costumbre que tienen algunos clientes de preferir proveedores de hosting nacionales… no es que tenga nada en contra de los proveedores nacionales por el hecho de ser nacionales, sino porque son comprobadamente y rematadamente pésimos — por cierto, me refiero particularmente al escenario de Chile, desconozco cómo será el panorama en otros países pero tengo la impresión que puede pasar algo similar.

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.

Continue reading “Tres malas razones para elegir un servicio de hosting”

WordPress: no sólo blogs

Con ocasión del WordCamp Chile 2010, junto a Basilio Cáceres preparamos una presentación sobre nuestras razones para utilizar WordPress en sitios dedicados principalmente a la publicación de contenidos en estructuras más complejas que un blog.

La presentación no es tanto técnica sino más bien estratégica, y expande lo que hace algunos meses Basilio había identificado como tres razones para desarrollar sitios web sobre WordPress: experiencia de uso, extensibilidad y comunidad.

Continue reading “WordPress: no sólo blogs”

Trabajar con fechas en Javascript

En AyerViernes estamos trabajando en un proyecto tan ambicioso como apasionante, lo que como siempre implica aprender nuevas técnicas, habilidades, etc; y en este caso un desafío interesante tenía que ver con trabajar de forma precisa con fechas a nivel de cliente.

El problema surge cuando pensamos en una fecha como una cadena de texto (por ejemplo 2010/06/12 asumiendo que estamos usando un formato año/mes/día como recomendaría la W3C) y necesitamos realizar algún cálculo con esa fecha, como sumar o calcular diferencia de días, ya que como sabemos, los meses pueden tener 30 o 31 días, Febrero tiene 28 (o 29 si es año bisiesto), etc… por lo que a 2010/06/12 no es tan fácil sumarle 60 días sin antes comprobar todas esas variables.

Sin embargo, el error fundamental ahí es nuestra primera suposición (tratar a una fecha como una cadena de texto o un conjunto de números), ya que estas dificultades se resuelven al trabajar con las fechas como objetos Date de Javascript.

Continue reading “Trabajar con fechas en Javascript”

Tres usos para jQuery.extend()

Tres ejemplos de algunas de las cosas que puedes hacer utilizando el método $.extend() de jQuery: fusionar objetos y arrays, utilizar opciones predeterminadas en una función y extender jQuery

$.extend() es uno de esas funciones de jQuery que quizás no son las que más utilizarías al comenzar a trabajar con este estupendo framework, pero que con el tiempo descubres que puede ser de inmensa ayuda, ya que es una solución simple a una tarea bastante común: mezclar objetos o arreglos.

Revisaré tres ejemplos de uso. Claramente, se puede utilizar en muchísimos casos más; como siempre, los comentarios quedan abiertos para aportes. Para una referencia completa, puedes echar un vistazo a su documentación.

Continue reading “Tres usos para jQuery.extend()”

Software libre y el futuro de MySQL

¿Existen razones para preocuparse por el futuro de MySQL luego de que Oracle comprara a Sun? Estos temores resultan en gran parte infundados al comprender el espíritu del software libre.

La compra de Sun por parte de [Oracle->Oracle Corporation@wiki] ha levantado alarmas sobre el futuro de [MySQL->@wiki], una de las bases de datos más utilizadas (si no la-más-utilizada) en el mundillo del desarrollo web, fundamentalmente por su carácter de software libre — sin ir más lejos, cientos de CMS como WordPress, Joomla o Drupal la utilizan de forma preferente o exclusiva, por lo que la posibilidad de que Oracle decidiera detener su desarrollo para favorecer sus propios sistemas de bases de datos (propietarios y de pago) se presenta para algunos como una amenaza real al futuro de sus aplicaciones.

Pero… ¿existen verdaderamente razones para estas preopcupaciones? Creo que no, y es más, creo que temer por el futuro de MySQL es no entender las ventajas del software libre, o peor aún, pensar que “software libre = software gratis”… Habría que agregar también que es en puntos como este donde se aprecia la diferencia práctica entre el código abierto y el software libre: a pesar de las diferentes concepciones que podríamos encontrar al respecto (por ejemplo, la definición “oficial” de código abierto, de la Open Source Initiative se parece más bien a una definición de software libre), podríamos reducir didáctica e ilustrativamente su diferencia al hecho de que en su sentido más básico, “código abierto” hace referencia al simple hecho de que es posible ver el código fuente de un programa. En este sentido, cualquier programa escrito en un lenguaje interpretado (PHP, Perl, Python, Ruby [on Rails]) distribuido públicamente caería en la definición de “código abierto” (a menos que por alguna razón “especial” su autor decidiera ofuscar el código).

Un ejemplo de lo anterior podría ser [Movable Type->@wiki], que en lo fundamental siempre ha sido de “código abierto”: el programa es puro código fuente interpretado, pero hasta hace poco no existía la libertad de distribuir una versión modificada, la que existe sólo a partir de su licenciamiento con la [GPL->@wiki]. Es entonces cuando las cuatro libertades para usuarios de software cobran sentido: no se trata de una razones puramente filosóficas o políticas (aunque también lo es) ni de una posición utópica o radical (como si ello fuera algo malo)… software libre no es lo mismo que código abierto.

¿Y qué tiene que ver esto con MySQL? Que justamente, su carácter de software libre asegura un futuro protegido: si Oracle decide detener su desarrollo, cualquier grupo de desarrollo podrá tomar la última versión publicada bajo la GPL y continuar el desarrollo, creando un fork… con otro nombre (si Oracle decide proteger su marca), con nuevas metas, con otras personas participando; agregando nuevas características o simplemente mejorando su seguridad y rendimiento o con cualquier otro plan de desarrollo.

No es una posibilidad utópica: ha pasado un montón de veces y seguirá pasando. [Ubuntu->@wiki] es un fork de [Debian->@wiki], [WordPress->@wiki] es un fork de [b2->@en.wiki], [Webkit->@wiki] es un fork de [KHTML->@wiki] e incluso el sistema operativo de Apple, [Mac OS X->@wiki] es un fork de [Nextstep->@wiki], que a su vez es un fork de [BSD->@wiki] (que es una variante de [UNIX->@wiki]).

¿Y si Oracle no detiene el desarrollo de MySQL sino que lo transforma en un producto de software libre de pago? Está dentro de sus libertades, mientras siga publicando su código fuente. Y esto tampoco sería el peor de los escenarios: del mismo modo, cualquier grupo podría dedicarse a distribuir ejecutables compilados a partir del código fuente, y en este caso también hay referentes —CentOS es una distribución de GNU/Linux compilada a partir del código fuente liberado por Red Hat, una distribución comercial de Linux (y una de las de mayor tradición).

De cualquier modo, los primeros pasos para asegurar el futuro de MySQL ya se han dado: uno de los creadores de esta base de datos ha anunciado la creación de la Open Database Alliance para coordinar el desarrollo colaborativo en torno a MySQL.

Y los más paranoicos se alegrarán de saber que ya existe un fork totalmente compatible con MySQL y que fácilmente podría convertirse en su sucesor: MariaDB, una rama de MySQL desarrollada en comunidad que mantendrá la compatibilidad con los nuevos lanzamientos de MySQL… y quién sabe, si Oracle decide finalmente jubilar a MySQL, quizás podríamos tener un sucesor que no sea solamente una copia sino una nueva y mejor base de datos.