Mostrando entradas con la etiqueta tests. Mostrar todas las entradas
Mostrando entradas con la etiqueta tests. Mostrar todas las entradas
jueves, 8 de noviembre de 2012
Scream if you wanna go faster
PageSpeed Insights is a webpage that allow to check the performance of a web page (specially about load time and bandwidth) both for desktop and mobile, but also give suggestions to improve it solving some typical errors, and also there are extensions for Firefox and Chrome to run it locally :-) At this moment it give a 73% value for desktop and 63% for mobile, I'll try later to make Google scream a little bit more (pun intended ;-) ).
lunes, 21 de marzo de 2011
PirannaFS Reloaded
Dos meses y medio, el ritmo decrece... :-P Lo cierto es que como bien predije este cuatrimestre iba a ser de aupa, y lo ha sido: jornadas de 12 horas, mudanza y media hora mas de transporte... y trabajo para casa los fines de semana. Por suerte hace dos semanas se hizo la presentación de los trenes y no solo la señora Cristina Fernández de Kirchner (para que veais como cotiza el niño... :-D ), sino que encima antes de que se terminara el proyecto conseguí trabajo en Vocento, y tiro oca porque me toca: estoy en todo el centro, tardo la mitad en llegar, el horario es flexible, las horas son ajustadas, el ambiente es agradable, el trabajo es tranquilo... y me pagan un 33% mas. Vamos, que me ha tocado la primitiva :-D Es por eso que despues de varios meses de estress y no dormir no solo vuelvo a tener fuerzas para estudiar en el tren sino que mucho mas importante, vuelvo a tener TIEMPO, y es por eso por lo que en las dos ultimas semanas le he pegado un chute bien fuerte a PirannaFS :-D
Para empezar, finalmente pude probar como seria el sistema usando PyFilesystem, y no hay lugar a dudas: me ha convencido. Dejando de lado que por su filosofia tan pythonica se queda a bastante alto nivel de lo que seria un sistema de archivos normal (el acceso a los sectores no se hace directamente sino a nivel de archivos...) lo cierto es que su uso de excepciones hasta la estenuación lo hace realmente potente y sencillo de programar: adios a comprobar continuamente valores de retorno que no nos atañen, si no nos interesa una excepcion ya habra otro que se encargue. Relax... y una limpieza de codigo y un estilo Zen minimalista increible. ¡Si hasta en algunos casos los comentarios de cabecera ocupan mas que el codigo! :-P
Ademas, este reinicio cual ave Phoenix me ha permitido el encontrar algunos fallos ciertamente molestos y solventar algunas idiosincrasias como el hecho de que la longitud de los chunks empezara en 1 para apuntar siempre al siempre simplemente por ahorrar algunas sumas de vez en cuando, aparte de poder limpiar codigo y encontrar soluciones mas optimas a algunos problemas, lo cual me ha llevado a pensar que al tener ahora un nucleo mas limpio, quizas si sea buena idea el tener tambien una version Python-FUSE del sistema de archivos saltandome algunas capas de abstraccion de PyFilesystem. Al fin y al cabo, el usar excepciones en lugar de retornar valores de error era el paso logico a dar para tener un codigo en condiciones, hoy dia el hacer las cosas al "estilo C", por muy simple, portable y optimo que pudiese ser, es un sin sentido teniendo opciones mas potentes (mismamente C++).
Ahora bien, despues de haberme metido en faena, efectivamente PyFilesystem no es la panacea: todavia esta muy verde e inmaduro, y no esta pensado para desarrollar sistemas de archivos nativos... ni parece que tengan intencion de hacerlo. Al igual que FUSE era famoso porque aparecieron multitud de sistemas de archivos "de juguete" (los sistemas de archivos para acceder a sistemas online son legion) esa filosofia es mucho mas real en PyFilesystem, lo cual tampoco es malo si lo que se pretende es que sea mas facil el desarrollo de sistemas de archivos. Sin embargo esta facilidad lleva implicita cierta abstraccion como es el hecho de acceder a nivel de ficheros (al menos, al ser "file-like objects", la integracion y uso de estos directamente en codigo python externo es directo), y tambien hay algunas decisiones como la ausencia directorio actual y el que los directorios realmente sean sub-sistemas de archivos (logico desde un punto de vista jerarquico-recursivo...) lo hace un poco extraño y dificil de manejar, aparte de que no hay definidas clases neutras desde las que poder heredar de _nada_. Al menos he intentado solucionar estos fallos en mi implementacion de PirannaFS sobre PyFilesystem, asi que cuando lo tenga mas fino y estable los adaptare a la libreria y enviare los parches correspondientes a ver que pasa :-)
Y recuerden niños: no olvidensupervitaminarse y supermineralizarse hacer unidades de test para todo: no veais el subidon de adrenalina que da despues de haber hecho una metamorfosis completa del codigo el no saber por donde empezar a comprobar que todo esta bien, encontrarse perdido dentro del codigo de PyFilesystem unas unidades de test basicas, ver como te dicen exactamente donde estan los fallos (incluso algunos que ni siquiera suponias que podrias llegar a tener, como es la corrupcion de archivos de gran tamaño) e ir resolviendolos uno a uno (a veces mas ;-) ) poquito a poco y pasar de no superar ninguno de los 49 a que solo queden 10 y la mayoria relaccionados con los hilos... :-D
Para empezar, finalmente pude probar como seria el sistema usando PyFilesystem, y no hay lugar a dudas: me ha convencido. Dejando de lado que por su filosofia tan pythonica se queda a bastante alto nivel de lo que seria un sistema de archivos normal (el acceso a los sectores no se hace directamente sino a nivel de archivos...) lo cierto es que su uso de excepciones hasta la estenuación lo hace realmente potente y sencillo de programar: adios a comprobar continuamente valores de retorno que no nos atañen, si no nos interesa una excepcion ya habra otro que se encargue. Relax... y una limpieza de codigo y un estilo Zen minimalista increible. ¡Si hasta en algunos casos los comentarios de cabecera ocupan mas que el codigo! :-P
Ademas, este reinicio cual ave Phoenix me ha permitido el encontrar algunos fallos ciertamente molestos y solventar algunas idiosincrasias como el hecho de que la longitud de los chunks empezara en 1 para apuntar siempre al siempre simplemente por ahorrar algunas sumas de vez en cuando, aparte de poder limpiar codigo y encontrar soluciones mas optimas a algunos problemas, lo cual me ha llevado a pensar que al tener ahora un nucleo mas limpio, quizas si sea buena idea el tener tambien una version Python-FUSE del sistema de archivos saltandome algunas capas de abstraccion de PyFilesystem. Al fin y al cabo, el usar excepciones en lugar de retornar valores de error era el paso logico a dar para tener un codigo en condiciones, hoy dia el hacer las cosas al "estilo C", por muy simple, portable y optimo que pudiese ser, es un sin sentido teniendo opciones mas potentes (mismamente C++).
Ahora bien, despues de haberme metido en faena, efectivamente PyFilesystem no es la panacea: todavia esta muy verde e inmaduro, y no esta pensado para desarrollar sistemas de archivos nativos... ni parece que tengan intencion de hacerlo. Al igual que FUSE era famoso porque aparecieron multitud de sistemas de archivos "de juguete" (los sistemas de archivos para acceder a sistemas online son legion) esa filosofia es mucho mas real en PyFilesystem, lo cual tampoco es malo si lo que se pretende es que sea mas facil el desarrollo de sistemas de archivos. Sin embargo esta facilidad lleva implicita cierta abstraccion como es el hecho de acceder a nivel de ficheros (al menos, al ser "file-like objects", la integracion y uso de estos directamente en codigo python externo es directo), y tambien hay algunas decisiones como la ausencia directorio actual y el que los directorios realmente sean sub-sistemas de archivos (logico desde un punto de vista jerarquico-recursivo...) lo hace un poco extraño y dificil de manejar, aparte de que no hay definidas clases neutras desde las que poder heredar de _nada_. Al menos he intentado solucionar estos fallos en mi implementacion de PirannaFS sobre PyFilesystem, asi que cuando lo tenga mas fino y estable los adaptare a la libreria y enviare los parches correspondientes a ver que pasa :-)
Y recuerden niños: no olviden
jueves, 4 de noviembre de 2010
Horror, espanto, pavor (2ª parte... y media)
Si antes me quejo de lo malo que es Python-FUSE para depurarlo y para hacer unidades de test, antes me encuentro con otro con el mismo problema :-P
Bindings de FUSE para python hay varios (eso ya lo sabia) y escogí Python-FUSE aparte de por ser el mas famoso y el "oficial" (o al menos es del unico que hay documentación en la pagina de FUSE) porque ya habia paquetes en Ubuntu. Lo que yo no sabia es que otra de las alternativas (fusePy) tenia paquetes dentro de la CheeseShop (si, asi se llamaba hasta hace poco el repositorio de paquetes oficial de Python antes de "profesionalizarse"), y por lo que parece esta alternativa no solo es mas "pythonica" que Python-FUSE sino que ademas es mas completa respecto a funcionalidad de bajo nivel, y para muestra un boton:
Si con esto no es mas facil el hacer las unidades de test sin necesidad de hackeos que baje FSM y lo vea. El problema viene entonces de tener que rehacer PirannaFS usando como base estos nuevos bindings o si hacer PirannaFS compatible con los dos, asi que quizas lo mejor sea estudiar previamente si realmente sera rentable o no, y leyendose el codigo no creo que baste. No se, otra alternativa podria ser el hacerme algun otro sistema de archivos (¿otro mas?), pero FullFAT no tiene bindings en Python (aparte de que queria usar la libreria para "entrenarme" para el paso a C++ de PirannaFS) y no he encontrado nada de bindings de Ext3 en Python, aunque sin lugar a dudas estaria interesante el hacerse una implementacion completa de Ext3 en Python (para chulo, yo :-P ). ¿Vosotros que opinais? ¿Reciclaje? ¿Reimplementación? ¿Mirar para otro lado y hacer como que no he visto esto? :-P
Al menos, de regalo me he encuentrado que CUSE, el hermano pequeño y marginado de FUSE para desarrollar drivers de dispositivo en espacio de usuario (el tio que lo desarrolló se dio cuenta que solo hacia falta añadir dos IOCTLs a FUSE para tener soporte para poder escribir drivers genericos fuera del kernel...) y del cual a casi nadie parece importarle (o al menos no he visto ningun proyecto importante o ni siquiera una pagina con documentacion)... ¡¡¡me encuentro con que han desarrollado unos bindings para Python!!! :-D
Quizas empezase PirannaFS porque CaOS (mi propio sistema operativo que llevo diseñando desde que tenia 10 años) se me hacia muy grande, pero parece que todo el universo se esta conspirando en que lo saque adelante... :-)
Bindings de FUSE para python hay varios (eso ya lo sabia) y escogí Python-FUSE aparte de por ser el mas famoso y el "oficial" (o al menos es del unico que hay documentación en la pagina de FUSE) porque ya habia paquetes en Ubuntu. Lo que yo no sabia es que otra de las alternativas (fusePy) tenia paquetes dentro de la CheeseShop (si, asi se llamaba hasta hace poco el repositorio de paquetes oficial de Python antes de "profesionalizarse"), y por lo que parece esta alternativa no solo es mas "pythonica" que Python-FUSE sino que ademas es mas completa respecto a funcionalidad de bajo nivel, y para muestra un boton:
>>> from fs.memoryfs import MemoryFS
>>> from fs.expose import fuse
>>> fs = MemoryFS()
>>> mp = fuse.mount(fs,"/mnt/my-memory-fs")
>>> mp.path
'/mnt/my-memory-fs'
>>> mp.unmount()Si con esto no es mas facil el hacer las unidades de test sin necesidad de hackeos que baje FSM y lo vea. El problema viene entonces de tener que rehacer PirannaFS usando como base estos nuevos bindings o si hacer PirannaFS compatible con los dos, asi que quizas lo mejor sea estudiar previamente si realmente sera rentable o no, y leyendose el codigo no creo que baste. No se, otra alternativa podria ser el hacerme algun otro sistema de archivos (¿otro mas?), pero FullFAT no tiene bindings en Python (aparte de que queria usar la libreria para "entrenarme" para el paso a C++ de PirannaFS) y no he encontrado nada de bindings de Ext3 en Python, aunque sin lugar a dudas estaria interesante el hacerse una implementacion completa de Ext3 en Python (para chulo, yo :-P ). ¿Vosotros que opinais? ¿Reciclaje? ¿Reimplementación? ¿Mirar para otro lado y hacer como que no he visto esto? :-P
Al menos, de regalo me he encuentrado que CUSE, el hermano pequeño y marginado de FUSE para desarrollar drivers de dispositivo en espacio de usuario (el tio que lo desarrolló se dio cuenta que solo hacia falta añadir dos IOCTLs a FUSE para tener soporte para poder escribir drivers genericos fuera del kernel...) y del cual a casi nadie parece importarle (o al menos no he visto ningun proyecto importante o ni siquiera una pagina con documentacion)... ¡¡¡me encuentro con que han desarrollado unos bindings para Python!!! :-D
Quizas empezase PirannaFS porque CaOS (mi propio sistema operativo que llevo diseñando desde que tenia 10 años) se me hacia muy grande, pero parece que todo el universo se esta conspirando en que lo saque adelante... :-)
Horror, espanto, pavor (2ª parte)
Nota mental: plantearme hacer de proyecto para el año que viene o una maquina del tiempo o un replicador de cuerpos o diseñar una droga que permita alterar la percepcion del tiempo sin los efectos secundarios de la cocaina y que pegue mas fuerte por las mañanas que un cutrebull del Lidl... la falta de tiempo es acuciante, y ahora que se acercan los examenes creo que la mejor opcion va a ser dedicarme a la meditacion tibetana, a ver si asi consigo concentrarme...
Quejas varias aparte, pequeño resumen de en lo que he estadoperdiendo el tiempo ocupado las ultimas semanas:
Para empezar, como ya puse en mi anterior post he empezado a realizar baterias de test para el sistema de archivos. Por un lado me hacia falta aprender a hacerlas, porque es algo que siempre he estado dejando de lado, y aunque no ha sido pan comido lo cierto es que no ha sido tan dificil como pensaba, pero la razon mas importante para hacerlo era el tema de difundir el proyecto, porque siendo un proyecto tan complejo y "delicado" (nadie quiere poner sus datos en peligro, y bastante ya me esta dando por [autocensurado] el Ext4 en el Ubuntu del trabajo poniendose en modo solo lectura cuando le doy un poco de caña por un error del kernel respecto a los timeout en discos lentos y antiguos... ¬¬) se necesitaba algun metodo para controlar la evolucion del proyecto y sobretodo para evitar regresiones. Y si, tengo que reconocer una cosa: funcionan, y mucho mejor de lo que pensaba. Tuve bastantes problemas a la hora de realizarlo por la forma en que esta diseñado python-fuse (no se si seria mejor arreglarlo o rehacerlo de cero...) pero lo cierto es que consegui que funcionara, y cuando despues de arreglar unos pequeños fallos que me encontre en la implementacion vi esto
realmente se me puso una sonrisa de oreja a oreja :-D
Pero mas interesante que esto fue cuando leyendome las especificaciones del OpenGroup vi algo que me dejo totalmente desconcertado: en readdir especifica que los famosos . y .. solo deben ser mostrados si el sistema de archivos en cuestion tiene referencias explicitas a ellos, cosa que no es el caso (y de hecho siempre me ha parecido una tonteria si ya sabemos tanto cual es el directorio actual como cual es el padre). Sin embargo en todos los ejemplos y documentacion que he visto los ponian explicitamente a mano. ¿Que hacer, saltarse el estandar, o seguirlo fielmente a pesar de que luego al listar el directorio se vea raro? Al final, como no sabia si la lista de correo del concurso podria servir para esto (apenas acababa de comenzar a usarse y esto era una pregunta muy especifica y hasta cierto punto yo entendia que seria cierta ventaja si alguien me ayudaba) asi que pregunte a mis colegas de AlcorconWireless, y como suele suceder en estas cosas mi amigo Dani (que al final le voy a tener que meter en los titulos de credito por toda la ayuda que me esta dando :-P ) dio con la mejor solucion:
Esa es la diferencia entre un ingeniero y uno que presume de serlo teniendo apenas la mitad de los creditos aprobados. Simplemente brillante.
En fin, la cuestion es que aunque apenas tengo tiempo sigo sacando las cosas adelante, solo espero que con el trajin que llevo no termine implosionando por el estress :-P Espero a ver si para el proximo post ya tengo terminados las unidades de test, porque iba a haber hecho una release especial para Halloween y lo cierto al final ha sido que hacia una semana que no encendia el PC de casa... :-P
Quejas varias aparte, pequeño resumen de en lo que he estado
Para empezar, como ya puse en mi anterior post he empezado a realizar baterias de test para el sistema de archivos. Por un lado me hacia falta aprender a hacerlas, porque es algo que siempre he estado dejando de lado, y aunque no ha sido pan comido lo cierto es que no ha sido tan dificil como pensaba, pero la razon mas importante para hacerlo era el tema de difundir el proyecto, porque siendo un proyecto tan complejo y "delicado" (nadie quiere poner sus datos en peligro, y bastante ya me esta dando por [autocensurado] el Ext4 en el Ubuntu del trabajo poniendose en modo solo lectura cuando le doy un poco de caña por un error del kernel respecto a los timeout en discos lentos y antiguos... ¬¬) se necesitaba algun metodo para controlar la evolucion del proyecto y sobretodo para evitar regresiones. Y si, tengo que reconocer una cosa: funcionan, y mucho mejor de lo que pensaba. Tuve bastantes problemas a la hora de realizarlo por la forma en que esta diseñado python-fuse (no se si seria mejor arreglarlo o rehacerlo de cero...) pero lo cierto es que consegui que funcionara, y cuando despues de arreglar unos pequeños fallos que me encontre en la implementacion vi esto
[piranna@Tontodelculo:~/Proyectos/FUSE/PirannaFS/src]
> cat ../test/error.log
...............
----------------------------------------------------------------------
Ran 15 tests in 4.176s
OKrealmente se me puso una sonrisa de oreja a oreja :-D
Pero mas interesante que esto fue cuando leyendome las especificaciones del OpenGroup vi algo que me dejo totalmente desconcertado: en readdir especifica que los famosos . y .. solo deben ser mostrados si el sistema de archivos en cuestion tiene referencias explicitas a ellos, cosa que no es el caso (y de hecho siempre me ha parecido una tonteria si ya sabemos tanto cual es el directorio actual como cual es el padre). Sin embargo en todos los ejemplos y documentacion que he visto los ponian explicitamente a mano. ¿Que hacer, saltarse el estandar, o seguirlo fielmente a pesar de que luego al listar el directorio se vea raro? Al final, como no sabia si la lista de correo del concurso podria servir para esto (apenas acababa de comenzar a usarse y esto era una pregunta muy especifica y hasta cierto punto yo entendia que seria cierta ventaja si alguien me ayudaba) asi que pregunte a mis colegas de AlcorconWireless, y como suele suceder en estas cosas mi amigo Dani (que al final le voy a tener que meter en los titulos de credito por toda la ayuda que me esta dando :-P ) dio con la mejor solucion:
mas friki.. activa una opción para verlos o para no verlos.. jajajaaja
Esa es la diferencia entre un ingeniero y uno que presume de serlo teniendo apenas la mitad de los creditos aprobados. Simplemente brillante.
En fin, la cuestion es que aunque apenas tengo tiempo sigo sacando las cosas adelante, solo espero que con el trajin que llevo no termine implosionando por el estress :-P Espero a ver si para el proximo post ya tengo terminados las unidades de test, porque iba a haber hecho una release especial para Halloween y lo cierto al final ha sido que hacia una semana que no encendia el PC de casa... :-P
martes, 19 de octubre de 2010
Horror, espanto, pavor
Acabo de darme cuenta de porque casi nadie hace baterías de test de casi nada, y no es porque no lo enseñan en la universidad... Acabo de hacerme la batería de test de la función ftruncate (es en la que mas modificaciones he hecho ultimamente con las optimizaciones. Ademas, por algun sitio tenia que empezar...) siguiendo las indicaciones de funcionalidad y errores de OpenGroup y me ocupa 254 lineas... y eso que solo he comentado lo que hace cada test, que ahora me toca programarlo :-/ Ahora bien, con la paliza que me voy a pegar, ¿que deberia hacer, acceder a las funciones a bajo nivel, o hacerlo rollo shell script y que ya que me pego la paliza con los test al menos que sirva para que otros no tengan que implementarselos tambien?
Y en plan recursivo... ¿deberia hacer una bateria de test para la bateria de test para testear que la bateria de test testea correctamente? X-D
Y en plan recursivo... ¿deberia hacer una bateria de test para la bateria de test para testear que la bateria de test testea correctamente? X-D
Suscribirse a:
Entradas (Atom)