Planet

Después de meses sin parar de programar, he fijado por fin unos límites en el proyecto, y he comenzado a realizar la memoria de la aplicación, lo cual llevará al menos un par de meses más. Mientras tanto, se realizarán … Continue reading →

Como habréis podido observar, la web que creé para el proyecto antes de empezar con él, se encontraba anteriormente alojada en http://rephus.es/piano. Ha sido transladada a http://piano.coconauts.net El motivo de dicho cambio ha sido porque hemos abandonado el servicio de … Continue reading →

Hoy ha sido un dia repleto de novedades, en especial para el blog. Se ha añadido una nueva página, contiene la información de las puntuaciones, se muestran como máximo las 5 mejores puntuaciones de cada canción. Ahora mismo, las puntuaciones … Continue reading →

Ha costado toda la mañana, pero finalmente, se ha conseguido reproducir y visualizar en el selector de canciones, archivos midis de forma offline (leidos de un archivo.txt) con archivos alojados localmente u online (directamente de la base de datos) y … Continue reading →

He publicado un roadmap (hoja de ruta) para las liberaciones de versiones del proyecto. Intentaré no pasarme de los plazos que establezca esta planificación. El roadmap puede verse en la sección Roadmap de este blog.

El principal problema que tiene la Escuela Superior de Informática, es el elevado número de abandonos que tienen las titulaciones que se imparten en ella (Ingeniería Técnica en Informática de Gestión y Sistemas e Ingeniería Informática). Una de las posibles causas de este elevado número de abandonos puede ser la excesiva carga de trabajo que cae sobre los alumnos, lo cual provoca que no puedan seguir el ritmo de trabajo, no obtengan buenos resultados en las pruebas, se desanimen y abandonen. Otro de los motivos puede ser que los alumnos intentan remontar los resultados adversos que arrastran, sobrevalorando sus posibilidades, lo cual les lleva a matricularse de más asignaturas de las que pueden afrontar. Además, existen alumnos que compaginan trabajo con formación, y no son conscientes de que son un tipo especial de alumno que no puede seguir el ritmo de trabajo de los alumnos que dedican su tiempo únicamente a formarse. Al no obtener los mismos resultados que estos últimos hacen que abandonen.
El próximo curso se implantarán los nuevos títulos y planes de estudios adaptados al Espacio Europeo de Educación Superior (EEES), en concreto el Grado en Ingeniería Informática, que entre otras cosas obligará a asistir a clase para poder realizar una serie de actividades presenciales que tienen peso en los resultados. Esto puede ayudar a que los alumnos de nuevo ingreso dedicados únicamente a formarse no pierdan el ritmo y obtengan resultados que les permitan ir a curso por año. Pero la situación puede empeorar aún más si las cargas de trabajo de las distintas asignaturas no se controlan bien. En esta situación puede ocurrir que los alumnos tengan que abandonar asignaturas ya que no puedan compaginar los trabajos.
Además en este nuevo contexto, con los alumnos que compaginan trabajo y formación, el problema del abandono se acentúa aún más, ya que no podrá asistir a clase y puede que se pierda multitud de actividades presenciales obligatorias o recomendables para superar las asignaturas. Teniendo en cuenta todo esto, se puede prever que el número de abandonos será muy similar al que existe actualmente o al de cursos anteriores.
Por esta razón, un asistente (humano/automático) que ayude al alumno a confeccionar matrículas que respeten la normativa vigente pero que sean acordes con su ritmo de trabajo, con sus circunstancias personales y por su puesto con sus capacidades y destrezas, podría ser muy útil como mecanismo para reducir el número de abandonos. Con él, cada alumno obtendría una recomendación de matrícula cuyo objetivo sería que el alumno obtuviera el mayor número de asignaturas superadas.
En este sentido el asistente, en base a la información personal/académica proporcionada por el alumno, a la institucional determinada esta por los planes de estudio y por la normativa, y al conocimiento derivado del análisis de experiencias previas, determinaría cual es la carga adecuada de trabajo para el siguiente curso para el alumno, con el objetivo de:
- Evitar la sobrestimación de sus capacidades, impidiendo que se matricule de más de lo que puede.
- Aprender más, ya que tendrán una carga más balanceada, y le permitirá dedicar más tiempo a cada asignatura.
- Obtener calificaciones más altas.
- Evitar los agobios producidos por la falta de tiempo.
Otro de los problemas que se encuentran los alumnos es el de escoger las asignaturas optativas y de libre elección, aquí muchos alumnos escogen las que creen que le gustarán más o creen más sencillas. El asistente también podría ayudar a los alumnos a escoger estas, indicando cuales son las asignaturas que mejor pueden venirle en base a su marcha académica, sus capacidades y sus habilidades.
Por otra parte, en la actualidad la Escuela está inmersa en un proceso de implantación de nuevas titulaciones adaptadas al EEES que implica la extinción de las titulaciones existentes en la actualidad. En todo proceso de implantación de nuevos planes de estudio debe haber un plan o procedimiento de adaptación por el cual aquellos estudiantes que están  matriculados en un determinado plan de estudios de cualquier titulación a extinguir y desean matricularse en el plan de estudios que se está implantando, solicitan que las asignaturas y/o créditos que tienen superados le sean reconocidos en el nuevo plan de  estudios. El asistente podría también aconsejar a los alumnos en este procedimiento de adaptación.
 
El principal problema que tiene la Escuela Superior de Inform´atica, es el elevado n´umero
de abandonos que tienen las titulaciones que se imparten en ella (Ingenier´ıa T´ecnica en
Inform´atica de Gesti´on y Sistemas e Ingenier´ıa Inform´atica). Una de las posibles causas
de este elevado n´umero de abandonos puede ser la excesiva carga de trabajo que cae sobre
los alumnos, lo cual provoca que no puedan seguir el ritmo de trabajo, no obtengan buenos
resultados en las pruebas, se desanimen y abandonen. Otro de los motivos puede ser que
los alumnos intentan remontar los resultados adversos que arrastran, sobrevalorando sus
posibilidades, lo cual les lleva a matricularse de m´as asignaturas de las que pueden afrontar.
Adem´as, existen alumnos que compaginan trabajo con formaci´on, y no son conscientes de
que son un tipo especial de alumno que no puede seguir el ritmo de trabajo de los alumnos
que dedican su tiempo ´unicamente a formarse. Al no obtener los mismos resultados que
estos ´ultimos hacen que abandonen.

Bueno, ya he terminado la documentación, en lo que respecta al análisis y elicitación de requisitos, así que ya me he puesto manos a la obra con la implementación.
Al no saber nada de las tecnologías que iba a usar (Python y Django), ya me he puesto a “trastear” y empecé por lo mínimo que se despacha en un lenguaje de programación, el Hello World.
De momento tiene muy buena pinta Django, aunque la documentación está en ingles, y en español no hay casi nada de información, pero bueno….así aparte de programación, aprendo ingles…que no viene mal.

Se ha publicado en la forja el enlace para bajarse la primera versión beta de JavaDiKt Mirai. Bajo el nombre de Mirai (futuro) se agruparan las primeras versiones de JavaDiKt, de forma que el cambio de nombre conllevará en todas las versiones futuras adición de nuevas funcionalidades.
Dentro de poco pondré un manual de uso y acutalizaré la página web, mientras tanto podéis trastear un rato bajando el ejecutable desde aquí.

Se ha publicado en la forja el enlace para bajarse la primera versión beta de JavaDiKt Mirai. Bajo el nombre de Mirai (futuro) se agruparan las primeras versiones de JavaDiKt, de forma que el cambio de nombre conllevará en todas las versiones futuras adición de nuevas funcionalidades.
Dentro de poco pondré un manual de uso y acutalizaré la página web, mientras tanto podéis trastear un rato bajando el ejecutable desde aquí.

Hasta ahora, hemos instalado el entorno de desarrollo, y conocemos las particularidades de un Makefile para generar un ejecutable .dol que podemos correr en nuestra Nintendo Wii. Es decir, podemos empezar a desarrollar un proyecto desde cero, contando con algunas bibliotecas en local, pero … exacto, faltan detalles por conocer.
Hoy voy a hablaros de los detalles que, forzosamente, debemos tener en cuenta a la hora de desarrollar un proyecto en Wii, y que de no ser contemplados, generarán un montón de bugs inexplicables (creedme, lo he sufrido).
Voy a enumerar estos detalles en una lista:

1. Alineación de la memoria.
   La caché de la Wii trabaja leyendo y escribiendo, por cada operación de E/S, 32 bytes cada vez. Para evitar problemas como, por ejemplo, que una operación de lectura machaque lo que se ha leído en la lectura anterior, debemos alinear los datos. Esto se consigue de una manera muy sencilla sustituyendo cada llamada a malloc (ya sabéis, reserva de memoria) con una llamada a memalign, que funciona igual que la primera, sólo que recibe un parámetro extra en el que le indicamos la alineación de los datos (que debe ser a 32 bytes).
   Por ejemplo:
   u8* var = (u8*)memalign(32, tam * sizeof(u8));
2. Relleno, o padding de la memoria:
   Derivado de la misma situación, hay otro problema con la caché de la Wii, y es que, como cada vez que se lee algo, se hace de 32 bytes en 32 bytes, puede ocurrir que queramos leer 24 bytes de datos, y justo despues, 96 bytes más. ¿Qué ocurrirá? Que se leen primero 32 bytes (los 24 de la primera variable, y 8 extra de la segunda), y después, al realizar la siguiente lectura, se machacarán esos 8 bytes extra de la segunda variable. Para evitar esta pérdida de información, se recomienda añadir un relleno hasta los 32 bytes en toda reserva de memoria. Siguiendo el ejemplo anterior:
   u32 padding = (tam * sizeof(u8)) % 32;
u8* var = (u8*)memalign(32, tam * sizeof(u8) + padding);
   Con esto nos aseguramos de que no habrá problemas de ‘machacamiento’ de información al realizar varias lecturas de datos consecutivas.
3. Fijar la información leída desde la caché:
   El último detalle a tener en cuenta para que no nos salgan bugs hasta de debajo de las piedras debido a la caché es el fijamiento (o flusheo) de ésta. Cada vez que leamos un dato desde un periférico, tenemos que fijar los datos leídos con un flush a la caché. Básicamente, se vuelca lo que hay en la pila de lectura a la zona de memoria que reservamos anteriormente. Completando el ejemplo anterior:
   // Una vez reservada la memoria, alineada y 'paddeada'
// Leemos desde un flujo de archivo de entrada, ifstream
archivo.read((char*)var, tam);
// ... y fijamos lo leído desde la caché
DCFlushRange(var, tam * sizeof(u8) + padding);
4. El Big Endian.
   Wii trabaja con Big Endian, al contrario que los sistemas “normales” (me refiero a los PC’s). ¿Qué significa ésto? Que si vas a leer dos bytes desde un periférico, la representación que espera el procesador de la Wii es, primero el segundo byte, y después el primero (me he tomado la licencia de simplificar mucho en esta explicación). ¿Cómo lo solucionamos? Simplemente, cada vez que vayamos a leer más de un byte desde un periférico, debemos hacer uso de las funciones siguientes, que se encargan de “traducir el endian” (en mi biblioteca se incluyen en ‘util.h’, en el espacio de nombres ‘endian’):
   // Leer dos bytes
u16 inline swap16(u16 a) {
return ((a<>8));
}
// Leer cuatro bytes
u32 inline swap32(u32 a) {
return ((a<>24) | ((a<>8) & 0xff00));
}
   Un ejemplo de aplicación sería:
   u16 var;
// Leer el tamaño de un u16 y guardarlo en var. archivo es un ifstream.
archivo.rdbuf()->sgetn((char*)&var, sizeof(u16));
// Para operar correctamente con el dato u16, hay que cambiarle el endian
var = endian::swap16(var);
5. Los tipos de datos:
   A estas alturas de la entrada, os habrá llamado la atención los tipos de las variables (u8, u16, … ). Efectivamente, para evitar que nos afecte la distinta representación de un mismo tipo en diferentes sistemas (un entero en Windows no es lo mismo que un entero en Unix, hablo de la representación en bytes), la biblioteca LibOgc redefine una serie de tipos (que están en gctypes.h). Los más importantes son:
   • Entero de 8 bits; sin signo: u8, con signo: s8 (equivale a char)
   • Entero de 16 bits; sin signo: u16, con signo: s16 (equivale a short)
   • Entero de 32 bits; sin signo: u32, con signo: s32 (equivale a int o a long int)
   • Entero de 64 bits; sin signo: u64, con signo: s64 (equivale a long long int)
   • Flotante de 32 bits: f32 (equivale a float)
   • Flotante de 64 bits: f64 (equivale a double)

   Se recomienda utilizar siempre estos tipos de datos, aunque también se pueden utilizar char, wchar_t y bool sin problemas (cuando sea necesario).

Y eso es todo lo que hay que tener en cuenta a la hora de programar para Nintendo Wii. Por supuesto, faltan por tratar el formato de sonido, la codificación de las imágenes y algunas cosillas más, pero sobre esos temas hablaré en sus correspodientes capítulos.
Con estos puntos que he descrito, ya nos es suficiente para ir empezando a trastear un poco. En el próximo post, aprenderemos a gestionar el Wii Remote (vamos, el mando).