Planet

La nueva encuesta esta resultando realmente útil para enfocar el desarrollo del proyecto. No esperéis posts de resultados como en las anteriores, ya que aquí no se decide que implementar, sino el orden en que se implementaran las nuevas funcionalidades.
Las principales novedades de la versión 0.3.9:

• Addon para apagar la maquina al finalizar todas las descargas. En GNU/Linux se debe modificar sudoers, “myuser ALL = NOPASSWD: /sbin/shutdown” para que funcione.
• Single Package Mode en “Advanced Packages”. Este modo evita que se creen múltiples directorios concatenando todo en un solo paquete.
• Reportar problemas desde el “LogView”. Si crees que algo falla reportalo y comentanoslo en el foro. No olvides el REPORTID.
• CLI. Primera implementación del interfaz en modo texto sin soporte de sesiones.
• Mejor soporte para el monitor de clipboard. ¡Copiad los enlaces, o incluso la pagina completa del navegador y al pulsar en Añadir Descargas se pegaran automagicamente todos los enlaces!

Para el resto de cambios podéis revisar el changelog.
Están disponibles para descarga tucan-0.3.9, tucan-0.3.9-win32 y tucan-0.3.9.dmg. ¡Disfrutadlas!
Un saludo, Crak.
Posted in New feature

Desdeslin en Recercat
La Universitat de Lleida tiene un convenio con el deposito de la investigación en Cataluña (Recercat).
Recercat es un repositorio cooperativo de documentos digitales que incluye la literatura de investigación de las universidades y de los centros de investigación de Cataluña, como artículos aun no publicados (preprints), comunicaciones a congresos, informes de investigación, working papers, proyectos de final de carrera, memorias técnicas, etc.
En mi proyecto fin de carrera especifique que quería que este apareciera en Recercat y ya está disponible. En él podréis encontrar el pdf de la memoria y un tar.gz con los archivos mencionados en la memoria.
Desdeslin en Recercat
Un mirror más para Desdeslin.
Estado FAI en Ubuntu
El estado de FAI en Ubuntu no es muy esperanzador. Oficialmente se ha quitado el soporte para Ubuntu. Se puede hacer funcionar Ubuntu con FAI pero con triquiñuelas. Es decir no vale con leer la documentación original de FAI sino que uno ha de usar un howto ad hoc.
Se supone que con la sincronización (más o menos) que habrá de Ubuntu y Debian (Ubuntu ya publica cada 6 meses y Debian aunque publicará cada 2 años creo que congelará cada 6 meses) se supone que será más fácil portar el paquete de FAI de Debian a Ubuntu.
La verdad es que Ubuntu será todo lo famosa que uno quiera pero, a la hora de la verdad, no tienen a gente que mantenga sus paquetes.
Ya veremos en que acaba Ubuntu.

Probablemente hayáis notado bloqueos al usar el Update Manager y es que el método de actualización actual no es demasiado eficiente. Ahora mismo existen 6 actualizaciones y 2 servicios nuevos partiendo de una instalación  limpia de la versión 0.3.8.
Así que usando Wireshark he comprobado cuantos paquetes se necesitan para la actualización.
587 para comprobar y 1007 mas para descargar. (210K)
Pues usando un índice para comprobar las actualizaciones y comprimiendo los servicios se obtiene.
20 para comprobar y 201 mas para descargar. (32K)
Además del beneficio en rendimiento de estas optimizaciones se va a habilitar un mirror en build-tucan-doc, para así aliviar la carga de la forja y se ha mejorado la respuesta del dialogo para que no parezca congelado.

Esta mejora la podréis disfrutar a partir de finales de mes, cuando espero salga la versión 0.3.9.
Un saludo, Crak.
Posted in Uncategorized

Bueno después de casi un año llegamos al final; puede que esta sea nuestra última entrada en el blog, nunca se sabe.Como resumen de este proyecto decir que ha tenido un poco de todo desde que empezamos montando el blog, ¡Qué jovenes eramos! ¿Os acordáis?, luego le toco la fase alfa a la web, comenzar a mirar los plugins junto con el servidor, millones de revisiones, ese pedazo de base de datos, algoritmo de reputación, verano en la universidad... En definitiva momentos mejores y peores que supongo que en unos añitos cuando seamos señores informáticos recordaremos con cariño.Y nada más que hasta aqui hemos llegado, pero eso si llegamos vivitos, coleando y mas que satisfechos con el resultado obtenido. Para demostrar nuestra satisfacción no puede faltar un vídeo de despedida; dale Homer!PD: Gracias a todas las personas que de una forma u otra nos han ayudado a completar este proyecto; va por ustedes!

Gracias a todos los usuarios que habeis participado en la encuesta, la ultima sobre servicios a implementar.
Las próximas serán sobre que funcionalidades creéis que Tucan necesita tener, así podremos orientar el desarrollo entre todos y dedicar el máximo tiempo a lo realmente importante.
Actualizad con el Update Manager y disfrutadlos.
Un saludo, Crak.
Posted in Community

Empezando con los servicios, primero iré mostrando ejemplos de cada servicio, y luego posteriormente ya el widget con la versión definitiva del servicio.
En primer lugar, comenzaré con la monitorización de los usuarios en Asterisk, lo cual realizaremos a través de la API Manager mediante asterisk-java.
El ejemplo lanza la acción SipPeers, que devolverá un evento PeerEntry por cada extensión, pudiendo tratar datos sobre ésta como el estado, y un PeerlistComplet cuando haya terminado.
Además, tendrá escuchadores para los eventos PeerStatus y ExtensionStatus que permiten ver los cambios en los estados de las extensiones (usuarios), tanto al conectar, como al recibir llamadas, colgarlas…
El código de ejemplo está aquí: Ejemplo

La Espina es un algoritmo de reputación que en función de una serie de parámetros modificables por parte del equipo de desarrollo cambiará la reputación asociada a un determinado usuario en nuestra base de datos. Su funcionamiento es muy sencillo; a partir de unas variables que o bien se mandan en el mensaje desde el cliente o bien se sacan de la base de datos se realizan unos cálculos matemáticos, el resultado es lo que llamaremos factor de cambio; el factor de cambio es lo que sumaremos o restaremos (según convenga) a la antigua reputación quedando está actualizando.A continuación pasamos a detallar el funcionamiento de la Espina especificando los parámetros empleados en su cálculo y como se modifican.a) Reputación del Votante:Cuando un blogger emite un voto sobre un comentario en su blog se envía un mensaje al servidor RASPA, el algoritmo lo primero que hace es ver si la persona que ha emitido el voto no es spammer ya que de ser así el algoritmo no le protege de otros spammers terminando aquí toda su funcionalidad; por el contrario si el valor de su reputación es lo suficientemente alto se pasa a medir cual es el valor del voto; este puede ser un valor de uno a cinco dependiendo de lo alta que sea la reputación del emisor del voto.b) Índice de Colegueo:Es un factor que mide el grado de amistad/enemistad entre dos usuarios entendiendo este como el número de comentarios que se han cruzado entre los blogs de los cuales son administradores ambos en la última semana. El objetivo es evitar que entre dos amigos se aumenten sus reputaciones votándose positivamente de forma reiterada o el caso contrario entre dos personas enemistadas.El funcionamiento de este índice consiste en obtener de la base de datos el número de comentarios que tengan como emisor y receptor a los dos usuarios implicados en la votación y se hayan producido durante la última semana. El valor del índice es un valor entre el rango uno y cero; de esta forma si los mensajes entre usuarios han sido constantes y el valor llega a cero el valor final de la votación será cero con lo que no habrá cambio en la reputación del votante. Cabe destacar que este factor decrece de forma exponencial.c) Índice de Actividad:Factor empleado para que los votos de los usuarios más activos tengan más peso; su forma de actuar es sencilla, se busca en la base de datos la última fecha de actualización de sus posts; si esta es superior a quince días el peso final del voto se reduce a la mitad, en caso contrario no se ve alterado; la finalidad es que los usuarios que más usen el servicio sean los que más importancia tengan en la modificación de una reputación.d) Factor Negativo:Este es un factor que únicamente se aplica a los votos clasificados como spam; su función es la de hacer que un voto negativo pondere más que uno positivo, lo cual permitirá una identificación de los spammers más rápida.Todos estos factores e índices se operan como se indica a continuación para obtener la nueva varianza en la antigua reputación:Si el voto es positivo (aprobado):VarianzaReputacion = (ValorVoto*IndiceColegueo)/IndiceActividadSi es negativo (spam):VarianzaReputacion = (FactorNegativo*ValorVoto*IndiceColegueo)/IndiceActividadUna vez obtenidos todos estos factores y operados lo único que resta por hacer es sumar el coeficiente resultante a la antigua reputación de la persona que emitió el voto.DATOS DEL ALGORITMOEn este apartado mostramos cómo evolucionan los parámetros del algoritmo según fluctúan las distintas variables.a) Reputación del votante:En la tabla podemos ver la línea de tendencia que cumple esta función. El eje horizontal representa la reputación del votante y el vertical el coeficiente que le corresponde.b) Índice de colegueo:En la gráfica podemos ver como a partir del quinto mensaje (eje horizontal) el valor del índice es cero anulándose los votos.c) Evolución general:Según todo lo citado anteriormente y teniendo en cuenta el índice de actividad y el factor negativo para los votos clasificados como spam; la evolución general del algoritmo será como se representa a continuación.Los votos pueden ir desde un valor de cinco si es muy alta la reputación del votante (eje horizontal) hasta cero si es muy baja, también vemos como desciende la ponderación del voto según aumentan los comentarios comunes entre los usuarios.Los votos negativos tienen un mayor peso con el fin de detectar antes a los posibles spammers; todos los valores de la tabla anterior se ven multiplicados por el factor negativo; hemos considerado conveniente darle a este una ponderación de un 50% superior al de un voto positivo; los resultados por tanto resultan de la siguiente forma.Vemos como se puede llegar a un valor de menos siete para aquellos votos clasificados como spam.Por último sólo nos queda resaltar que la ponderación de cada nuevo voto puede reducirse a la mitad si el usuario no ha actualizado su blog en los últimos quince días.ConclusionesCreemos que nuestro algoritmo es completo y adecuado ya que cubre todos los posibles parámetros básicos que influyen en la modificación de la reputación así como otros menos triviales como el tiempo que lleva el votante inactivo. Teniendo en cuenta todo esto, en nuestra opinión, se premia los votos imparciales sobre los que pueden ser más objetivos y los votos negativos sobre los positivos haciendo que sólo los usuarios sobre los que no haya dudas puedan seguir sus tareas con total normalidad; según esto nuestro sistema es bastante disuasorio para los usuarios que envíen mensajes comerciales no solicitados; como curiosidad afirmar que si un usuario nada más comenzar su actividad (supongamos una reputación inicial de cincuenta) empieza a mandar mensajes que a juicio del resto de los usuarios son spam sólo podría enviar seis mensajes; si la tasa por darse de alta en RASPA es de cinco euros cada comentario tendría un coste de 0,83 céntimos; por este motivo creemos que RASPA no es solo un filtro anti-spam si no también una herramienta disuasoria contra este tipo de usuarios.Además se cubre esta funcionalidad sin sobrecargar el servidor ni con un gran número de consultas ni con una alta carga computacional.

Aunque hasta ahora no se había subido nada de implementación al blog, el desarrollo se ha ido realizando. A partir de hoy, habrá múltiples entradas con las cosas desarrolladas y las que se van aún desarrollando.
A partir de hoy el blog no estará descuidado.

La lucha se desarrollara de la siguiente forma
class Escenario {
Jugador uno,dos;
vector<Magia> v_magia;
void listen_(){
mover( uno);
mover( dos)
mover ( magia)
comprobar_colisiones( uno,dos,v_magia);
calcular_daños( uno,dos,v_magia);
}
void Ejecuta_(); // cambia estados y aplica los cambios
void dibuja(); // dibuja la pantalla , las magias y los personajes
};
Así me queda un sistema un poco más acoplado que lo que yo esperaba, en realidad este diagrama es una simplificación de lo que pasa en realidad, por que  las colisiones dependen del Subsistema de colisión que en mi caso yo lo he modelado como una clase la cual pertenece a cada jugador y que hace corresponder estado-> vector< SDL_Rect >  y con funciones estaticas  para poder ver si una magia ( con su propio SDL_Rect para sus colisiones ) colisiona con el cuerpo de jugador.
Pero estas comprobaciones las hace La clase escenario la cual tendrá control sobre jugador mediante una interfaz defina por un objeto, llamemoslo estado_comun, que no solo controlará eso , sino que muchas más cosas, esta clase merece una explicación mucho más detallada , pero será más adelante.

Bueno, un saludo a todo el mundo y  a ver si tengo la beta para octubre totalmente funcional.
PUEDE CONSIDERARSE BIENAVENTURADO Y NO PEDIR MAYOR FELICIDAD EL HOMBRE QUE HA ENCONTRADO SU TRABAJO.
Thomas Carlyle

VIDEO AQUI
He estado todo el verano depurando código, y luchando para conseguir una versión estable para poder jugar 2 jugadores, por fin he podido hacer una versión alfa  del videojuego que segun la wikipedia:
“Algunos equipos de desarrollo utilizan el término alfa informalmente para referirse a una fase donde un producto todavía es inestable, aguarda todavía a que se eliminen los errores o a la puesta en práctica completa de toda su funcionalidad, pero satisface la mayoría de los requisitos.”
Pues bien, ahora mismo el juego  se encuentra en una fase de perfeccionamiento de todos los requisitos del programa en cuanto tenga una versión beta o medianamente decente  para ser criticada , será subida a la forja , la cual no se lleva bien conmigo, ni  yo con ella.
Disfruten del vídeo caballeros grabado usando el VLC, en breve escribiré un poco sobre los grandes cambios que he realizado sobre este pograma, ya que antes era un poco ilegible.


La lucha por la vida no la gana
Siempre el más fuerte ni el más rápido,
Pero, tarde o temprano, ¡el que gana
Es el hombre que piensa que es capaz de ganar!
BRUCE LEE