Twitter, Snowflake, Números grandes y PHP

Desde que los ID’s de los estados en Twitter son mayores que la representación de enteros usando 32bits, había estado usando el tipo float para filtrar rápidamente esos valores, digamos:

$statusid = isset($_GET['statusid']) ? (float)$_GET['statusid'] : 0;

Con float se pueden tener hasta 14 dígitos sin pasar a la representación exponencial (1.xxxxxxE+NN), y como Twitter solo estaba generando ID’s de 11 dígitos, me pareció que había bastante tiempo antes de que se pasara el límite de float. Además me sirve que tenga la representación como número para comparaciones ($lastid > $firstdbid ) o para hacer cálculos sobre estos (etags).

Ahora que Twitter anda generando los ID’s con Snowflake (más información al respecto en el blog de Twitter), cada ID requiere 15 dígitos o más (53bits por ahora).

Esto no es problema si se tiene PHP a 64bits, ya que se pueden tener hasta 19 dígitos antes de alcanzar el límite. Si se tiene PHP compilado a 32bits, no queda de otra más que usar strings. Un forma rápida para filtrar los IDs tanto para 64bit y 32bit sería:

function safelongint($strint)
{
	$intval = intval($strint);
	if ( $intval == PHP_INT_MAX)
	{
		return preg_replace('/[^0-9]/','',$strint); //eliminar cualquier cosa que no sea dígito
	}
		
	return $intval;
}

Aún si los ID’s pasan el límite de los 64bits, debería usar strings automáticamente. Ya solo queda que la base de datos no tenga problemas con números tan grandes 😉 .

Actualización: Al 10 de Noviembre, Twitter ya llegó a los 17 dígitos en los ID’s… a ese paso el límite de los 64bit durará menos de lo que imaginé.

Como mostrar el número de revisión SVN en un sitio

Estás trabajando en un proyecto (web), usas Subversion para el Control de Versiones y te interesa que en alguna parte del sitio se muestre el número de revisión al que está actualizado. Se asume que el “desarrollo” se hace en una copia aparte y el en sitio web solo se sincronizan los cambios respecto al repositorio (svn up).

La mejor forma de hacer esto es crear un archivo que contenga el número de revisión y que este se actualice cada vez que cambie la copia en el servidor, por ejemplo un script así:

cd /home/user/public_html/
svn up 
rm version.php
svnversion > version.php

Este script se puede llamar incluso desde un hook en post-commit, el único requisito es que version.php no esté en el repositorio para que no de problemas con futuras actualizaciones.

Ahora que version.php ya tiene la revisión en la cual se está trabajando, solo falta incluirla desde el sitio web. Un simple include debería bastar:

<?php include 'version.php'; ?>

Este método debería funcionar mejor que usar svn:keywords ya que este solo se actualizaría cuando el archivo (ej. version.php) se modificado. Y aún mucho mejor que examinar el contenido del directorio .svn o modificar el archivo a mano 😉

La que es siempre vuelve

phpBBUna de las comunidades que siempre ha sido afectada por fallos de seguridad, es la de los foros phpBB. Recuerdo en mis primeros años ya «administrado un sitio» (allá en el 2002) había que actualizar constantemente el foro para evitar que arruinaran los foros y aún así un par de veces tuvimos problemas. Esos eran los días en que uno odiaba a phpBB 2.0.x

Hace unos días me entere que volvieron a sufrir otro ataque, aunque no por un fallo en phpBB sino otro en phpList, y fue tan grave la cosa que lograron tomar todas las contraseñas de los usuarios:

the attacker was able to steal all email addresses from our mailing list, as well as the password hashes from this board’s database.

Pobres, no quisiera ser admin de su sitio, y que bueno que tampoco administro un foro con phpBB (tampoco crean que vBulletin es la gran maravilla, pero almenos no los hackean xD). Luego de tantos años en las mismas de siempre, phpBB y los fallos de seguridad son ya un sinónimo.

dBug, var_dump() con estilo

Hace unos poco días encontré un pequeño script php para poder mostrar el contenido e información de alguna variables que indiques, muy similar al funcionamiento de var_dump(), pero con la gran diferencia que despliega la información dentro de tablas HTML y estilos CSS. El script se llama dBug y está disponible bajo licencia GNU GPL.

Por ejemplo, me ha servido para curiosear dentro de las variables de WP-Cache mientras le hago algunas modificaciónes. Usando var_dump() resulta un poco incomodo ya que firefox presenta los datos mal agrupados:

salida de var_dump() vista en firefox

Usando dBug, la información de las variables las presenta así:

PHP dBug

Facilita mucho la lectura e interpretación de las variables. Incluso al hacer clic sobre las filas, estas se encojen para ocultar contenidos que no necesitamos o son muy amplios. Pueden ver algunos ejemplos de dbug y los datos que presenta.

Para usar dBug es tan sencillo como primero tener:

include_once("dBug.php"); 

En alguna parte de nuestro script (como dentro de wp-config.php) y luego hacer la llamada pasando la variable de la cual deseamos obtener más información usando dBug:

new dBug($variable); 

A mi me parece muy útil para enfocarse en depurar o curiosear las variables, sin tener que perder tiempo en presentar los datos en forma leíble.

Etiquetas de búsqueda: , , , , debug

Agrega tu comentario

Fin del ciclo de vida para PHP4

Hoy PHP.net anuncia el fin del ciclo de vida para PHP4, luego de tres largos años desde la liberación de PHP5. Los desarrolladores anunciaron de despues de 31 de diciembre de este año ya no habrán más versiones de php4 y que seguirán lanzado exclusivamente versiones de parches de seguridad hasta el 8 de Agostso de 2008.

Este anuncio sumado a la campaña de GO PHP5, son claros indicios de que es hora de moverse definitivamente a php5 y empezar a aprovechar sus bondades.

Etiquetas de búsqueda: , ,

GoPHP5.org, quitando el soporte a PHP4

GoPHP5PHP4 ya tiene siete años de haber se liberado, y PHP5 ya casi llega a los 3 años de estar en el aire; pero a pesar de ello muchos hostings aun no han agregado soporte para php5 por temor a que las aplicaciones de sus clientes no funcionen, o al menos no lo activan por defecto. De acuerdo con Nexen.net el 80% de los hostings aún continuan usando php4 en sus servidores.

Es por ello que nace GoPHP5.org, como una iniciativa para que los proyectos basados en php abandonen el soporte a PHP4 y se pasen a PHP5, aprovechando sus ventajas; así como comprometer a los hostings para que ellos también eliminen php4 de sus servidores.

La meta es llegar 5 de Febrero de 2008 con el mínimo soporte para php4. Proyectos como Drupal 7 y phpMyAdmin ya se han comprometido a esta iniciativa, y otros como MediaWiki desde ya solo corren en php5. En la lista de correo wp-hackers ya han discutido el cambio hacia php5 varias veces ya. La respuesta siempre ha sido: cuando exista mayor soporte de php5. Haber que pasa esta vez 😉

Etiquetas de búsqueda: , , , , ,

Instalando PHP 5.2.1 en Ubuntu Edgy Eft

PHP 5.2.1 no hace mucho que salió, incluye numerosos parches de seguridad y estabilidad; como siempre es importante que tus scripts sean compatibles y no hayan problemas con la actualización. Dado que en Ubuntu Edgy Eft solo está disponible PHP 5.1.6 desde los repositorios oficiales, la forma más fácil de instalar la ultima versión es agregando un repositorio de Debian.

Para ello es necesario editar /etc/apt/sources.list, agregando estas lineas:

deb http://packages.dotdeb.org stable all
deb-src http://packages.dotdeb.org stable all

Si ya tienes php5 instalado, solo es necesario ejecutar sudo aptitude update para que nos informe de la nueva versión disponible y se actualice automáticamente. El único inconveniente es que la librería mysqli no esta disponible para 5.2.1, aunque realmente no se si funcionaría la version para 5.1.6.

Etiquetas: , , ,

MediaWiki 1.9.x y los problemas con las extensiones

MediaWiki es el software detrás de los diversos proyectos de Wikipedia, que incluye soporte de extensiones que agregan nuevas características al wiki. En su versión más reciente, MediaWiki 1.9.x, algunas extensiones que hacen llamadas al interprete de sintaxis wiki (parser) tienen problemas para funcionar en la nueva versión. El problema es la forma en que se llama ahora al interprete de sintaxis wiki, antes era un código similar a:

function customfunction($input, $argv) {
   [...]
   global $wgOut;
   $output = $wgOut->parse($input, false);
   [...]
   return $output;
}

Para solucionarlo solo hay que adecuar la función de la extensión a esta nueva forma:

function customfunction($input, $argv, &$parser) {
   [...]
   $poutput = $parser->parse( $input, $parser->mTitle,
                   $parser->mOptions, false, false );
   $output = $poutput->getText();
   [...]
   return $output;
}

Y listo, ya esta hecho el chapuz para que nuestra extensión vuelva a funcionar ;).

Etiquetas: , , wikis