Planet

Durante el diseño de cualquier dispositivo una de las decisiones más importantes que se pueden tomar son las medidas del dispositivo, ya que esto estará influenciado (si tenemos una limitación) o influenciará en las decisiones mecánicas posteriores.
En este proyecto las medidas del dispostivos son libres, no tenemos limitación (siempre dentro de unos márgenes razonables); en estos casos una de las decisiones más acertadas que podemos hacer es coger una medida estándar (Cajas DIN, Rack 19″, etc.), ya que esto nos abaratará el precio de la parte mecánica.
Nosotros escogeremos los siguientes límites en las medidas:
1.- 115mm de altura y 66mm de diámetro, la masa no debe exceder los 350 gramos.
2.- 240mm de altura y 146mm de diámetro , con una masa total máxima de 1050 gramos.
El porqué de estas medidas es simple, corresponden a las categorías CANSAT y OPENCLASS del concurso CanSat, escoger una u otra dependerá de la medida y disposición de los componentes y circuitos durante el desarrollo (aunque personalmente me inclino por la opción de CANSAT).
El peso es un recurso muy limitado en este diseño, a mayor peso mayor necesidad de helio para levantarlo, lo que implica un globo mayor y por lo tanto un precio mayor; solamente el circuito puede llegar a pesar del orden de 70-90gr., a este peso hay que sumar la caja, anclajes y tornillería varia, protección térmica, paracaídas y sobretodo baterías.
Las baterías se llevarán la mayor parte del peso, aquí por lo tanto tendremos otra disyutiva: si utilizamos baterías más grandes el peso aumentará sin embargo el tiempo de vuelo podrá ser mayor, en cambio si utilizamos baterías más pequeñas el peso. De todas formas realizar un diseño de bajo consumo ayudará a solucionar la disyuntiva ya que a menor consumo mayor duración de la batería y/o menor el peso de la misma. De todas formas el problema con las baterías lo trataremos en profundidad en otro post más adelante.

En el siguiente esquema hemos representado las principales tecnologías que usaremos para desarrollar el proyecto:

Como se puede observar el proyecto se divide en 3 grandes aplicaciones:
Servidor web: Programado con Django+Python y corriendo sobre Google App Engine. Hemos decidido usar esta tecnología porque creemos que además de ofrecer una buena calidad de servicio también nos permitirá soportar los esperados picos de tráficos que creemos que podríamos obtener en el futuro. El servidor utilizará lás APIs de Google Maps, Places, y muy posiblemente Calendar, Predict, etc.
Cliente web: Estará implementado usando HTML5+CSS3+Javascript. Aprovecharemos las posibilidades que HTML5 ofrece para mejorar la experiencia de usuario reduciendo tiempos de respuesta, combinando AJAX con la capacidad de almacenamiento local, permitiendo a su vez seguir trabajando con la aplicación web incluso cuando no tengamos acceso a Internet. También utilizaremos la API de Geolocalización para obtener la posición cuando el GPS no esté activado. Hemos pensado también en desarrollar extensiones para los navegadores: Google Chrome, Mozilla Firefox, etc.
Aplicaciones para móvil: las aplicaciones serán desarrolladas en Java, a pesar de los rumores que corren acerca de poder desarrollar con Go en Android.


Para las interacción Cliente/Servidor se trabajará para que la aplicación móvil y el cliente web trabajen con la máxima independencia posible del servidor, reduciendo al mínimo las peticiones a simples sincronizaciones puntuales.
Todas las comunicaciones serán codificadas y para ello utilizaremos un cifrado SSL (HTTPS), dando de esta forma una robusta seguridad al servicio. Para implementar las comunicaciones utilizaremos SOAP.
Se agradece cualquier idea o sugerencia, podéis hacérnosla llegar a través de la plataforma de feedback.

Hace como un mes que nos inscribimos en el CUSL pero hemos estado postponiendo la creación del blog y de la forja hasta hoy por diversos motivos.
Hoy hemos creado ambas secciones y estamos a la espera de que se active la forja para poder empezar a subir el trabajo que vamos realizando poco a poco.
Para comenzar he publicado una página con un vídeo explicativo de unos 10 minutos donde explicamos paso a paso las normas del juego y simulamos una partida en los puntos más importantes.
Además adjunto en pdf las normas y el tablero del juego.

Welcome to WordPress.com. This is your first post. Edit or delete it and start blogging!

A la hora de aplicar domótica a una bodega de vino, me puse en contacto con una bodega real para ver sus necesidades (muchas gracias a Miro por la visita guiada que nos hizo).
Allí­ me comentaron la necesidad de medir la temperatura en distintas partes de la bodega.
Necesitaba medir la temperatura en tiempo real y con un formato de Software Libre.A mi mente en ese momento vino Arduino, una plataforma libre con la que podría medir la temperatura de una forma fácil,rápida y barata.
Para realizar esto voy a necesitar:

• una placa de Arduino modelo Duemilanove.
• cable usb.
• un sensor de temperatura.
• una placa de prototipado.
• cables.

Para empezar esto sería todo lo necesario.
En los próximos post colgare un video de como hacerlo, además del código utilizado.

Podríamos dividir el proyecto en dos partes.
La primera parte sería sobre todo domótica de la forma que todos la conocemos.La segunda parte trataría los RFID y sus aplicaciones. Utilizaré los RFID para poner información sobre las botellas y para posteriormente realizar un seguimiento de las mismas.
En la parte de domótica, probablemente utilizaré placas de Arduino para controlar la temperatura, humedad y nivel de oxigeno.
La razón por la que quiero utilizar Arduino es porque esta es una nueva tecnología, barata y ademas libre como todo el proyecto.
En los siguientes post iré poniendo mis nuevas ideas, asi como nueva información.

A continuación voy a escribir un tocho de extensión considerable, así que para ahorrar sufrimientos innecesarios a adictos al twitter y amantes del proverbio lo bueno si breve, dos veces bueno, aquí va la conclusión:
Windows tiene Graphics Gale, Mac OS X tiene Pixen, y GNU/Linux tiene… el Allegro Sprite Editor. Si te lo compilas.
Bueno, técnicamente los otros dos también lo tienen, es multiplataforma.
Antes de plantearse empezar un proyecto de software, considero imprescindible echar una ojeada a lo que han hecho otros en el mismo campo de lo que pensamos desarrollar. Vamos, ver cómo está el percal.
En el mundo del software privado (lo siento, soy alérgico a la palabra privativo en este contexto), por no intentar hacerle la competencia a monstruos como Photoshop o Flash. Ni la mismísima Adobe pudo hacerle sombra a Flash invirtiendo en SVG, así que acabó comprando Macromedia.
En el mundo del software libre, por no duplicar esfuerzos.
Al menos es lo que yo he hecho. Como usuario de software libre desde hace ya bastante tiempo, veo que una tendencia importante en el mundillo es la de empezar un proyecto nuevo por desavenencias tan graves con otros proyectos similares como:

• No me gusta GTK.
• No me gusta Qt.
• No me gustan ni GTK ni Qt.
• Las interfaces gráficas son para maricas, donde se ponga un buen modo texto…
• Vim es Dios.
• emacs r00lz.
• Este editor de texto no soporta resaltado de sintaxis del lenguaje de programación klinkon, que además de que puedes programar un juego tipo Final Fantasy XXVI con dos líneas, te hace las tostadas y te saca el perro a pasear… y aunque podría añadirle soporte fácilmente a dicho editor, prefiero programarme mi propio editor de texto. ¡Con casino! ¡Y furcias!
• El tirano del fundador del proyecto fasdafasda no me ha aceptado un parche que tardaba 0,000000000000001 segundos menos en pintar monos verdes con openGL. Mira que decirme que la ganancia en velocidad era nimia, estaba dentro del margen de error y no justificaba un hack tan feo… Pues he creado mi propia versión, FAST fasdafasda. ¡Chúpate esa!
• La licencia del programa asdf no es suficientemente libre. No incluye ninguna cláusula que permita explícitamente la impresión del código fuente en papel higiénico serigrafiado con dibujos de gatitos, así que hemos hecho un fork del proyecto original con una licencia prácticamente idéntica salvo en ese aspecto para acabar con semejante injusticia, la KPTPGPL (Kitten-Patterned Toilet Paper General Public License).
• Hay 9384 distribuciones distintas de Linux. Pero yo quiero una con el nombre de mi novia/perro/hijo primogénito.

Por una razón u otra, para cada tarea más o menos determinada suele haber del orden de 10 a 20 programas que básicamente hacen lo mismo, por lo que como usuario te puedes encontrar con 4 programas de diseño 3D, 10 sistemas de control de versiones o 200 editores de texto sin formato, con lo que te queda la duda de si al decantarte por uno no te estarás perdiendo nada de los otros 199.
¿A qué viene todo esto? ¿El tema de la entrada (y del blog) no eran los editores de sprites? Pues precisamente a eso iba: he estado buscando editores de sprites para Linux hasta debajo de las piedras y…
no hay.
Bueno, está el ya mencionado Allegro Sprite Editor. Si te lo compilas. Y ya está.
Con la de videojuegos basados en sprites para linux que hay, es curioso que la oferta de aplicaciones disponibles para esto sea tan limitada.
Peor aún: los editores tipo raster tampoco abundan. Ni Gnome Paint ni Gpaint tienen zoom y están verdes, verdes. Sólo pinta se salva de la quema. Los degradados son exageradamente lentos, pero aparte de eso me ha parecido bastante decente. ¡El zoom funciona! Y es indispensable si quieres tener un mínimo de precisión a nivel de pixel.
El zoom de Gnome Paint. Lo verás, pero no lo catarás...
Pero con pinta no se puede animar. Ni siquiera con un plugin aparatoso como GAP. Para hacer animación 2D tenemos a nuestra disposición programas más que aceptables y de filosofías tan diferentes como Synfig y Pencil. Adoro sobre todo Pencil, esa sencillez y orientación a la animación tradicional… pero claro, ninguno de los dos está orientado específicamente a sprites, y no tienen toda la artillería para procesar imágenes de GIMP, por lo que animar un muñecajo y llevarlo a tu juego pasaría por las siguientes fases:

1. Una vez acabada tu animación, exportarla en forma de secuencia de imágenes png.
2. Pencil está bastante limitado a la hora de colorear, así que tal vez prefieras hacerlo con GIMP.
3. La mayoría de motores de sprites y bibliotecas de funciones multimedia prefieren o exigen sprite sheets por motivos de rendimiento, así que toca hacerse un script que trabaje con GIMP, PIL, ImageMagick o similar para pegar todos los cuadros de animación en una sola imagen.
4. Te queda lo más duro: especificar los datos propios de los sprites como número de cuadros y frecuencia (cuadros por segundo) de cada animación, coordenadas de mapeado de cada cuadro, cajas de colisión, etc. Mucha gente lo suele hacer directamente en código (hard coding), lo cual es un horror, ya que te obliga a mantener tu código actualizado respecto a los sprites y a volver a compilar o ejecutar cada vez que cambias algo. También los hay que se fabrican sus propias mini-utilidades para exportar este tipo de datos a XML. Lo malo es que lo suelen hacer en Visual C++ o Visual BASIC…
5. Si ves que la animación se te queda corta, larga, o no pega con el resto del juego, vuelve al punto uno. No te olvides de revisar uno por uno los cuadros que componen cada animación si cambias algo. De nada.

Animar y desarrollar videojuegos ya son actividades sobradamente duras por sí mismas. Por esto y por mucho más, he decidido hacer bueno el dicho de si te pica, te rascas tan propio del software libre y ayudarme a mí mismo a la vez que, espero, ayudo a otros.

Uno de los primeros pasos que consideramos imprescindibles a la hora de desarrollar un proyecto de software desde cero es diseñar algunos bocetos de lo que queremos que sea nuestra aplicación. Podríamos hacer un análisis completo de requerimientos de la forma tradicional pero creemos que de cara a que también seáis vosotros quienes opinéis y aportéis ideas y sugerencias es mejor ir directamente al grano. Además, creemos que todos los que a diario usamos Twitter conocemos bastante bien los requisitos que debe tener la aplicación.
Por eso, vamos a publicar de aquí a algunos días una serie de bocetos sobre los que estamos trabajando, para hablarlos y discutirlos entre todos los que queráis seguir el desarrollo de nuestra aplicación. Os sabremos escuchar y esperamos también poder aprender de vuestras experiencias de usuario para realizar una aplicación que cubra la mayoría de las posibles necesidades.
Así que aquí tenéis el primero de los bocetos en los que estamos trabajando, en el que podéis ver el aspecto que queremos darle a pytweetclin. Por supuesto, todo es discutible. Estamos abiertos a todo tipo de críticas constructivas.
Primera Propuesta para pytweetclin (click en la imagen para verla a mayor escala)
Creemos que la idea a grandes rasgos se entiende bastante bien. A continuación algunas cuestiones:

• Si os fijáis, en las listas aparecen dos de ellas activadas y otra lista desactivada. Esta metáfora, del encender/apagar, es para poder seleccionar cuales de nuestras listas queremos que se actualicen de forma automática. Imaginad que estamos siguiendo un Gran Premio de Fórmula 1 y queremos saber todo lo que ocurre: encendemos esta lista y se actualizará en tiempo real, indicándonos el número de tweets pendientes de leer en la lista. Que acaba el Gran Premio y ya no nos interesa lo que se dice en la lista: pues la apagamos.
• El icono que aparece justo arriba a la derecha del cuadro de escritura de un tweet es para configurar diversos parámetros de la aplicación en otro cuadro de diálogo que aún no hemos diseñado. No hemos encontrado un mejor sitio que darle. ¿Se os ocurre alguna otra idea?
• Otra cuestión en la que hemos dudado es en la lista de tweets. ¿Creéis que es mejor, en lugar de distinguir con colores cuales son los tweets del usuario y los del resto de usuarios, hacerlo alienando nuestra fotografía en el lado derecho y la del resto de usuarios en el lado izquierdo?

Por cierto, gracías al equipo de cacoo por la magnifica herramienta que han desarrollado para el diseño en colaboración de diagramas de todo tipo. Es la herramienta con la que estamos desarrollando nuestros bocetos.
Filed under: Noticias

Ayer por la tarde nos reunimos en Granada 5 de los integrantes del equipo de GeoReminMe (@dugo, @mr_esti, @plof_, @guyikcgg & @hhkaos) y otras 2 compañeras (@annalogik & @pepit4) estuvieron presentes por Skype. En las más 5 horas que estuvimos juntos aprovechamos para:

• Presentarnos todos
• Aclarar algunas dudas sobre el enfoque de la aplicación
• Dividir responsabilidades
• Configurar los equipos para poder desarrollar las aplicaciones en Android y con App Engine
• Actualizar el blog
• Darnos persmisos en la forja, appspot, etc.
• Realizar algunos diagramas
• Trabajar sobre la página web promocional de la aplicación.
• etc.

Finalmente no tuvimos tiempo suficiente para empezar a escribir ni una línea de código, pero ya estamos mucho más cerca , esperamos que en los próximos días empiece el movimiento en el repositorio.
Team working
Plof programming

Hola a todos.
Desde que me propuse desarrollar este proyecto, he pasado prácticamente cada día pensando y/o programando, y es bastante cansado. No obstante, siempre hay buenas noticias que me animan a seguir en cada momento: unas cuantas lineas de código escritas, una nueva funcionalidad añadida, un bug corregido… pero sobre todo, nueva gente siguiendo el proyecto.
Y es por esto por lo que hoy son muy buenas noticias: cada día más gente sigue el progreso de YUD. Ya hay gente que visita el blog desde México, Estados Unidos, Argentina, Ecuador, Suiza, Perú, Alemania, Italia, Francia… aparte de España. Creo que ha sido una buena idea escribir de forma simultánea las entradas del blog tanto en castellano como en ingés, ya que ha contribuido a la difusión del proyecto.
Y por si fuera poco, empiezan a unirse seguidores a la cuenta del proyecto en “Identi.ca“. En este aspecto, hay gente que me ha comentado que no sigue las micro-entradas en Identi.ca porque no tienen cuenta en el servidor (aunque se puede leer sin tener cuenta, no avisa de nuevos cambios de tus seguimientos), así que he decidido añadir también al panel lateral del blog un enlace para poder seguir las entradas de Identi.ca por Rss, y así llegar a todo el mundo con mayor facilidad.
Y para rematar las buenas noticias, ya hay una primera versión básica de la interfaz gráfica. Estoy probandola más a fondo y corrigiendo pequeños detalles (gracias a mi compañero de universidad Adrián García, “tester” del proyecto), y subiré en unos días la aplicación al repositorio del proyecto.
Muchas gracias a todos por seguir el proyecto, y os animo a participar en él. Creo que puede llegar a ser algo interesante.