12.28.2007

blogs&twitter en valladolid

Me llega el siguiente correo:
"""
Hola!

Se va a celebrar el próximo 3 de enero el Blogs&Twitter Valladolid, una reunión para personas que tienen blog, twitter, flickr o participan de cualquier forma en alguna de las muchas redes que hay en la web. Está organizado por el Consejo Provincial de la Juventud de Valladolid y por 5lineas.com

Hay varias fuentes con toda la información:
http://5lineas.com/archivo/internet-web20/blogstwitter-valladolid-el-3-de-enero/
http://www.amapolasdigital.com/blogstwitter-valladolid/2007/12/27/

http://wiki.5lineas.com/blogs_and_twitter_valladolid (el wiki para apuntarse)

http://www.flickr.com/photo_zoom.gne?id=2141779196&size=l (cartel en grande)

Esperamos que te interese y poder contar con tu participación.

Muchas gracias por tu tiempo

Un saludo!
Dani
"""
Me imagino que habrá llegado a mi a través de planet augcyly reproduzco aquí por si alguien está interesado. Parece interesante, no sé si podré asistir :/

12.25.2007

Feliz navidad versión "art coder"

Llega la moda de felicitad navidad y yo con estos pelos. Aquí teneis un video que he capturado de una intro que hice para un juego que he dejado a medias pero cambiando el texto.



música: wonder
herramientas: blender, ODE, vc++ express, paint

y otra más, un pequeño raytracer para móvil con ambient occlusion (sin filtrar). En un k610i tarda una media hora, no se puede decir que esté muy optimizado.



si alguien quiere el código que lo pida :)

12.17.2007

Grafistas vs programadores (round 1)

Los pobres grafistas de unkasoft, faltos de argumentos, atacan a los programadores con cosas como esta:



Transcribo:
"""
Hay que ser muy hombre para ser grafista...\n por eso soy programador
"""

Agradezco el detalle, como prometí me la pondré, aunque habrá venganza...

12.09.2007

Test n80

Molan los telefonos con wifi :)

12.03.2007

Consejos para crear tu propio formato de fichero

Cuando programas una aplicación, por pequeña que sea, siempre tienes la necesidad de almacenar ciertos datos que permanecerán durante las sucesivas ejecuciones. Lamentablemente los requisitos y diseños de las aplicaciones cambian y normalmente se ven reflejados en el modelo de datos que tenemos, con el consecuente cambio en la forma de almacenar los datos.

Esto se eleva a la máxima potencia cuando además esos datos son de usuario y se añaden varios problemas más:

- el primero y más importante es que para el usuario sus datos son importantes y no puede perderlos.
- el segundo es que los datos ya no están tranquilamente resguardados en un sitio calentito, van a salir a la calle, VAN A SER MANIPULADOS POR EL USUARIO, serán comprimidos, copiadas, borrados y transferidos.

Hay una serie de puntos que pueden salvarnos de muchos problemas, no son desde luego axiomas, pero a mi me han salvado de más de un problema, aquí van:

- Elige un formato: texto o binario, por un lado el texto nos permite hacer debug rápidamente, hacer cambios a mano, tiene la pega que es más complejo de leer ya que requiere un parseo. Por el contrario el binario para debug es un infierno pero permite una lectura más rápida y además evita que los usuarios sepan más de lo que quieres. Esta pequeña guía es para formatos binarios

- Usa un magic al comienzo del fichero: esto es, unos bytes prefijados por los cuales sepas nada más leer los primers bytes que de verdad es tu fichero. Esto es condición necesaria, pero no suficiente, aunque te quitará de problemas. Un detalle más, el MAGIC si puede ser ascii mejor, de esta forma cuando abrimos el fichero con un editor de texto veremos nuestro magic ahí, lo primerito y sabremos si es un hijo nuestro o no. Probadlo con un PNG, ZIP o similar, todos tienen un magic ascii.

- Usa un número de versión. De esta forma cuando tus datos vayan cambiando tus loader sabrán que hacer con ese fichero en función del número de versión. Además, conviene que tengas dos números de versión, uno que indique que cambia tu formato y otro que diga que el fichero ha cambiado pero que el formato sigue siendo el mismo. En este punto hay un tema bastante interesante: qué hacemos con ficheros que son de versiones anteriores a la actual? tenemos varias opciones, personalmente he usado dos, por un lado tener algo así:

loader = loaderFactory.getLoader(fileVersion);
loader.load(file);

o por otro:

if(fileVersion != currentFileVersion) {
migrateFile(fileVersion, currentVersion);
}
loader.load(file);


Sinceramente no sabría decir cual de las dos es mejor, en agroguía uso la primera y no me cuesta mucho mantenerla.

- guarda siempre más datos de los que necesites. Salvo que el dispositivo esté muy limitado normalmente dará igual tener un fichero de 500kb que de 600kb y te puede ayudar una burrada. Para qué puede servir esos datos extra? pues por ejemplo para almacenar datos de debug, acciones del usuario, datos internos que es posible que dentro de 4 días te puedan servir. Personalmente a mi los datos de más que guarda la aplicación me han servido para poner la cara roja a más de uno y me ha evitado problemas.

- No te cierres puertas, deja el formato abierto al futuro (pero tampoco demasiado), esto es, organizalo por secciones de forma que dejes secciones para uso futuro, te ahorrás tiempo haciendo conversores y loaders, aunque será un poco más complejo crear el loader la primera vez.

- Utiliza serializer si puedes, en pocas palabras, intenta que el código que guarda y salva ser el mismo siempre, así no habrá problemas de incoherencias entre lo que guardas y lo que cargas. No es fácil hacer un sistema así, sobretodo cuando hay objetos de por medio, el código público del unreal tiene un ejemplo a lo bestia. La idea sería más o menos así:

class serializer {
 public:
  bool isReading;
  bool serialize(int &i) {
   if(isReading)
    i = readIntFromFile();
   else
    writeIntToFile(i);
 }

};

class MyClass {
 int data;
 void serialize(Serializer s) { s.serialize(data); }
}


No es lo más óptimo, pero te soluciona la vida :). También se puede implementar al modo cutre con una macro de c++. Otra forma de verlo en la web de chaos^fr.

- Puede que tus datos ocupen mucho, intenta que cuando lo guardes sean lo más fácilmente comprimibles, un codificador de deltas no es prácticamente nada en código y puede resultar en un ahorro de espacio considerable una vez se ha comprimido el fichero, para por ejemplo enviar por correo.

Seguro que hay mucho más, pero estos son para mi los más importantes. A mi me habría venido muy bien a la hora de no perder el tiempo cuando he tenido que modificar el fichero de save.

12.01.2007

agroguía @ innovaduero

Ayer estuvimos todo el día en un stand en innovaduero, un feria que mezcla de una forma un tanto extraña tecnología y turismo y que se desarrolló en Zamora, más concretamente en IFEZA . Nosotros estuvimos allí grancias al foro info rural que nos contactó (gracias a Jaime Gómez Gil).



Nunca había ido a una feria así que fuimos un poco al tuntun, con un proyector, unos videos preparados días antes a toda prisa, unas pda y unos GPS para hacer bulto. Por suerte la organización de innova (los mismos que foro info rural) nos había impreso unos carteles en grande que me preparó Juanma Zarza, aka mr koala (un nuevo compañero de trabajo) a toda prisa y casi sin material, lo cual le agradezco de verdad.




Al llegar nisiquiera estabamos en las listas de inscripción y aquella tenía toda la pinta de que iba a ser un desmadre... menos mal que al final no fue así, la organización nos traó de lujo, nos invitó a un café a media mañana, a comer, unas botellas de vino, etc.

Lo siguiente fue montar el stand, no digo más, una foto:



En el rato de preparación del stand preparé una versión de agroguía para poder enseñar una demo de una parcela y preparé unas transparencias (en powerpoint, claro) para una charla que teníamos que dar horas después y de la que nos enteramos horas antes ;)

La mañana pasó divertida, hablando con los compañeros de stand de los que luego hablaré y explicando una y otra vez en que consistía nuestro proyecto, me entrevistaron en la radio, unos 3 minutos, en los cuales mi "habilidad" no me dejó nisiquiera decir la página web ni un teléfono de contacto. Total... te dejan hablar 3 minutos en la radio y no hacer un mínimo de publicidad es para llamarme tonto hasta aburrirte. Una foto de las presentaciones de por la mañana, están aburridos:



Por la tarde más demostraciones y explicaciones, aquello se conviritó en un coñazo terrible, pero bueno. De compañeros de stand tuvimos a:

- fundación médico rural, una fundación que trata de transmitir la necesidad de aplicar la tecnología a las urgencias médicas en poblaciones alejadas. En resumen, tenían un acuerdo con philips que había creado un monitor de esos del corazón que transmitía los datos a un pc remoto gracias a GPRS y de esa forma un equipo especializado podría ayudar al médico o enfermero de la zona rural a salir del apuro. Lo que me contaron los dos señores que estuvieron allí era muy curioso y la verdad es que da que pensar. Tenemos a alcaldes en la cárcel, se están gastando dinero en gilipolleces y para algo que realmente es interesante y puede ayudar a salvar vidas no hacen ni puto caso. La única que había metido pasta era telefónica para poder compensar las supuestas (o presuntas,muy de moda ahora) enfermedades provocadas por las antenas... ahora gracias a la cobertura se pueden salvar vidas y las antenas dejan de ser peligrosas. De esto sí que se debería hacer publicidad, debería recibir ayudas políticas y económicas y atención por parte de los medios de "comunicación".

- Proxima systems, una empresa que integraba productos de comunicación para aplicación a domótica, video vigilancia y demás. Muy interesante lo que hacían, además tuve la suerte de que eran técnicos y pudimos hablar de algo más que de vender humo y de lo maravilloso que eran sus productos. Muy agradables.

Como curiosidad tuvimos todo el día un segway de esos, además casi en exclusiva, con el que casi nos matamos :). Fue la sensación de la feria.

En resumen, una jornada muy divertida, pudimos conocer a mucha gente y aprendimos bastantes cosas acerca de lo que hacer en una feria.

Decir que un 0 para lo políticos, los cuales llegaron mal y tarde. Como siempre, para hacerse la foto. De mal en peor.