Planet

He añadido una nueva característica al cliente, la capacidad de desplazarnos por el escritorio gracias al sensor de orientación, es decir inclinando el teléfono hacia un lado o hacia otro. Realmente no funciona con un teléfono real, como ya he dicho, trabajo con el emulador y no está implementado ningún método que te permita [...]

Ayer por la noche me quedé hasta tarde haciendo las tareas. Como tenía que empezar desde la temporada para luego ir desglosando en los periodos más pequeños decidí hacer todas las comprobaciones necesarias de fechas en esta etapa para que luego me sirvieran en las demás.
El resultado es el siguiente, al crear una temporada se comprueban:

1. Que la temporada tenga un nombre diferente de cualquier otra para un usuario dado. Así cuando listemos las temporadas del usuario x podremos ver claramente cual es la que buscamos. Sucederá lo mismo en todos los periodos, pero en vez del usuario dependerá de la clave que relaciona con el nivel superior, así nopoderá haber dos periodos de igual nombre en un macrocilo, ni dos macrociclos iguales en una temporada.
2. Que la fecha en la que empieza la temporada sea anterior a la fecha en la que acaba… obvio.
3. Que la fecha en la que empieza la temporada sea posterior a cualquier fecha de fin de cualquier temporada del usuario, porque la temporadas no pueden solaparse.

Para esto se han tenido que realizar tres nuevos validadores de datos y una clase de herramientas “MyTools” donde se establece la validez de las fechas.
En los validadores se ha documentado los parámetros necesarios para su correcto funcionamiento. Se puede ver el código en los diferentes ficheros del cvs en gesport/apps/lib. Además tengo agradecer al foro de Symfony y en especial a los usuarios richyrich y noods que abordaron este problema antes que yo y me sirvió muy bien su solución, aunque la modifiqué para separar las diferentes validaciones.
Además el módulo de validación de fechas iniciales contra fechas de la base de datos permite una completa configuración que podría usarse para evitar otro tipo de solapamientos ya que se pueden configurar desde la columna a comparar como el tipo de comparación.

Se ha completado el manual de usuario para la versión 1.0, aquí.
Actualizado el wiki a la última versión de DokuWiki. También se ha añadido el Translation Plugin para incluir traducciones de la documentación.

Supongo que muchos usuarios de Tucan habréis experimentado, algunos sin saberlo, los limites que imponen los servicios para descarga anonima.

• Rapidshare. Este servicio tiene un limite variable que normalmente oscila alrededor de los 15 minutos por cada 100MB descargados.

• Megaupload. Este servicio limita dependiendo de la cantidad de datos descargados y de la carga de sus servidores, pero siempre de duración 120 minutos.

• Gigasize. Este servicio no impone ningún tipo de limitación temporal.

Si no ejecutáis Tucan desde un terminal, podríais pensar que este se ha bloqueado por algún fallo, pero en realidad lo que ocurre es que esta esperando 5 minutos antes de volver a intentar descargar.
Así que para que sepáis si os encontráis con un limite de descarga he añadido un botón al Statusbar donde aparece el servicio, el tipo de descarga y la hora a la que empezó el limite.

Todo esto y la solución a los problemas en las cuentas premium podéis encontrarlo en la versión 0.3.3.
Un saludo, Crak.

Ya están disponibles los manuales de instalación y uso de AVBOT en formato PDF. El primer comenta los pasos necesarios para integrar pywikipediabot + irclib + AVBOT, y el segundo explica los comandos básicos de ejecución y algunos consejos.

• Manual de instalación
• Manual de usuario

Bueno , hoy es dia de retrospectiva me ha dado por ver como ha ido mi blog desde que empece , y no esta mal , tiene mejor resultado que mi anterior proyecto Jitunes .
Solo agradezer a los que me leen como JC  que me lee de manera normal , A isaac que devez en cuenado me lee desde las Holandas y tambien al Sr de Ruby On Rails que me lee tambien.Y al resto pues lo mismo Gracias por el perder algunos minutos de vuetsras vidas en este sitio.

Uno de los grandes problemas que tenemos hoy en un el mundo del análisis de datos es la cantidad de datos y el tiempo.
Aquí la discusión de siempre  ¿Como podemos analizar una gran cantidad de datos? , algunos , son de los que yo llamo ,  de “recursos” lo solucionan metiendo mas medios , ordenadores mas potentes y claro mas caros , los otros son los llamados , “paralelos” , comprar ordenadores baratos y los ponen en granjas (todo el mundo sabe de quien hablo ¿ verdad? XD).
Pero supongamos que tenemos los segundos , el siguiente problema es  ¿Que algoritmos usamos? necesitamos buenos algoritmos para poder conseguir los datos de  manera mas efectiva mas rápidamente.
En el mundo de hoy se prefiere un algoritmo rápido en tiempo pero se desprecia el volumen de datos , es decir, supongamos que si para conseguir 1 hora mas de velocidad , se tienen que acumular no se 10 GB de espacio en disco , ¿es rentable? . Un ordenador común lo puede hacer esta es la pregunta.Donde se aplica esto en Mineria de Datos en DataWarhose en Robotica.
Todo esto viene por un articulo sobre un nuevo algoritmo que ha salido que analiza gran cantidad de información en un ordenador normal.
Bien me he leído el articulo y he llagado a algunas conclusiones .
Evidentemente esto no es lo miso , aplicar Bayes, un Markov o un Kohonen.Es mas bien un divide y vencerás o como lo llaman ellos divide y conquista.
Los científicos tienen más datos en sus dispositivos, a menudo más de los que pueden examinar apropiadamente. Pero un nuevo algoritmo podría facilitarles ver enormes conjuntos de datos.
Y, además, es barato; el software basado en un algoritmo puede correr en computadoras personales con tan poco como 2GB de RAM.
Los científicos en la Universidad de California del Laboratorio Nacional Davis y Lawrence Livermore desarrollaron el algoritmo durante un periodo de cinco años. Basado en el complejo y antiguo Morse-Smale, divide, analiza y recombina conjuntos de datos e ilustra sus cálculos.
El proyecto fue dirigido por Attila Gyulassy, una estudiante graduada en ciencias de la computación de la UC Davis como su tesis de doctorado. Ya que las supercomputadoras ahora pueden simular fenómenos físicos como corrientes oceánicas y la combustión, la gran cantidad de datos que generan hacen imposible trabajar con ellos. “¿Qué son todos los datos sin las herramientas de visualización que nos permitan ver realmente qué es lo que está pasando? Tenemos la habilidad de generar, pero no necesariamente de comprender”, explicó el profesor de Gyulassy, Bernd Hamann, en una conversación con Industry Standard.
Gyulassy probó el algoritmo en una simulación de dos líquidos que venían juntos, un conjunto de datos con cerca de mil millones de una trama tridimensional. Al correr en una computadora portátil, el software fue capaz de analizar la información en 24 horas e ilustrar aspectos del fenómeno en segundos.
Hamann le dio a Gyulassy la mayoría del crédito. “Ella está realmente empujando la tecnología hacia adelante”. Sin embargo, agregó que la mayoría del trabajo debe ser hecho en el software antes de que pueda volverse disponible de forma más amplia.
Fuentes del Articulo

• paper
• Noticia
• Comunicado

Unas entradas atrás (http://opendomotica.wordpress.com/2009/01/18/arduino-i-porque-arduino-du...) tuve que hacer la decisión de cual de las distintos modelos de Arduino elijiría para el proyecto. Como ya dije me quedé con el Duemilanove. En la decisión nombre a los Arduino que había analizado por eso he considerado importante recopilarlos a todos en un documento poniendo una pequeña descripción junto [...]

Python es un lenguaje con el que se pueden programar grandes cosas sin tener que conocer nada más que un par de cosas, pero que si te pones a aprender vas aprendiendo diferentes formas de hacer las cosas.
En python todo es un objeto. Esto que parece una tontería, en realidad lo es. Todo un objeto, guay, una función es un objeto con un método __call__. Por lo tanto puedo hacer una función que reciba como argumento una función y devuelva una función. Y eso está guay, y es uno de los fundamentos de la programación funcional.
Y te preguntarás, ¿Para qué puedo querer yo una función que reciba una función? Pues eso es un "decorador" en python. Y tienen su utilidad. Y da la casualidad de que cuando no conoces algo no tienes la necesidad de usarlo, pero cuando lo conoces dices: "¿cómo he podido vivir yo sin esto?".
Así pues en cuanto supe de los decoradores en python empecé a verle utilidad en cada programa que hago.
¿Y a qué viene todo esto? Vamos a ver algún ejemplo práctico que he usado en geco.
Por ejemplo, para el cliente web yo tenía varias funciones en las cuales hacía la misma comprobación:

1. def GET(self, args):
2. username = session.get('username', '')
3. if username:
4. ...
5. (aquí lo importante de la función)
6. ...
7. else:
8. raise web.seeother('/login')

Para evitar la repetición de este código se puede usar un decorador, y la cosa quedaría así:

1. @authenticated
2. def GET(self, args):
3. ...
4. (aquí lo importante de la función)
5. ...

Si esto se escala a varias funciones claramente se ve que nos ahorramos un buen cacho de código (no tanto :P ), y la parte realmente importante de la función queda mucho más clara.
authenticated es una función que recibe una función y devuelve una función, y que con la sintaxis esta tan bonita de la arroba no quiere decir más que esto:

1. def GET(self, args):
2. ...
3. (aquí lo importante de la función)
4. ...
5. GET = authenticated(GET)

Pero con la sintaxis de la arroba queda más bonito. Por otra parte queda ver el código de la función decoradora:

1. def authenticated(function):
2. session = web.ses
3. def new_function(*args, **kwargs):
4. username = session.get('username', '')
5. if username:
6. return function(*args, **kwargs)
7. else:
8. raise web.seeother('/login')
9.  
10. return new_function

Es una función, en la cual se define una función anidada, new_function, que recibe un número indeterminado de argumentos sin nombre (*args) y un número indeterminado de argumentos con nombre (*kwargs), y desde esta función anidada se hace una llamada a la función original que es la que se recibe por parámetro.
Otras cosas interesantes de python
Cuando en una función se define un parámetro con asterisco (*args) quiere decir que esta función puede recibir varios argumentos. Estos argumentos se almacenan en una lista de nombre args. El operador asterisco también sirve para desplegar una lista en argumentos a una función, por ejemplo una función que reciba dos argumentos "def f(x, y): pass" puede ser llamada pasándole una lista como
argumento "a = (1, 2)", ">>> f(*a)".
Lo mismo que lo anterior pasa cuando se ponen dos asteriscos, pero en lugar de tratar con argumentos sin nombre tratamos con argumentos con nombre y en lugar de una lista tenemos un diccionario. Por ejemplo:

1. def f(x=1, y=2):
2. pass
3.  
4. d = {"x": 3, "y": 5}
5. f(**d)

-> pass -> no hace nada
-> raise -> sirve para lanzar una excepción
Y ya está, que me enrollo. Pronto pondré más capturas y contaré como va el cliente web, que ya tiene una pinta estupenda :P

Today has been a day for doing some design tweaks with my partner Angel Soler, just to give empathy a more dynamic look:It's been also very interesting discussing with Ondrej and other members of the SymPy community the best way to output formulas. Proposed solutions so far are:

1. jsMath: this uses sympy's latex output and transforms it using javascript into something the browser can read (mathml or images, depending on the browser). Disadvantages: you have to load an entire javascript library, which takes quite a lot of time, and CPU goes up to 90% during 5 seconds.
2. MathML: sympy supports mathml output natively and mathml is a universal language for displaying formulas. This would be the ideal solution, if it wasn't because of ... 1. Sympy outputs "Content" MathML, whereas firefox (and other browsers) knows only how to display another variant of MathML, "Presentation" MathML. You can transform Content MathML to Presentation MathML (and sympy knows how to do it), but it is an expensive opperation (maybe too expensive to be done on every request), and 2: MathML support in browsers is partial. To view MathML in IE you have to install a plugin (MathPlayer) which, by the way is not open source.
3. Image. This would be a nice solution, and is the one chosen by wolfram's integrator as the main output. Sympy's png printer is a bit slow, since it does the following: expression -> latex -> dvi -> png.
4. ASCII (pretty). This is the easiest solution. It renders ok (although i'm having some issues with wrapping), but is not as pretty as the image output.