Planet

Nueva libreria que he encontrado para manejar 3D en python, y parece ser que tiene funcionalidades suficientes como para hacer lo que quiero hacer, que es rotar un cubo de rubik, creo que me pondré a probar a ver que tal y ya colgaré fotillos de los resultados, no lo espereis muy pronto ya que hasta este viernes no creo que toque mucho el proyecto.
Saludos!!!
      

Han sido añadidos los siguientes blogs a la página de enlaces. Espero que no falte ninguno de los de la lista blogroll. En el caso de que no os encontreis, no dudeis en poneros en contacto con nosotros, y lo añadiremos en un plis (no como lo que hemos tardado ahora jeje, disculpad :P).

• AVBot
• Eslime
• Free Padel
• Gesport
• Gestas
• Host Manager
• Informática Training
• LabGNU
• Magic Cards
• Mandarina Project
• OpenDomotica
• Proyecto Baca
• Pyrubik
• Ragu
• Ramirez’s Challenge
• Ratogi
• Tutatisk

Hasta pronto!

Tras un par de horas de trabajo el repositorio ya está funcionando y el proyecto está en marcha. Durante la tarde de hoy he tenido que lidiar con:

• La configuración de WordPress
• La configuración del servidor de DreamHost
• La herramienta web de RedIRIS
• La herramienta web propia del concurso
• Aprender a crear y manejar un repositorio con subversion
• Aprender a usar scp

No esta mal por hoy.

Sí! No lo habéis leido mal, ya lo tenemos hecho! Nos ha costado muchas horas de sueño y  mucho esfuerzo y trabajo de campo.
Sin más preámbulos os dejo un screenshot de los mismos:

Hahahahaha, realmente ya nos gustaría tener el proyecto tan avanzado. La cosa es que un poco de humor nunca viene mal, además, con el nombre de nuestro proyecto.. lo tenemos a huevo Hehehe.
Bueno, hasta otra!
Posted in Anuncios   Tagged: Humor   

este post es una prueba

Tras una tarde y media, bastante intensa, buscando software para el desarrollo en UML, hemos concluido que la mejor alternativa será el empleo de NetBeans con el plugin que trae de desarrollo UML.
En principio queríamos un plugin para Eclipse capaz de manejar de forma eficiente una amplia variedad de diagramas UML. Sin embargo, tras buscar y buscar, todos los plugins que encontramos no satisfacían nuestras necesidades: sus licencias no nos convencian; no permitían tratar una gran cantidad de diagramas; eran antiintuitivos; no se dejaban llevar por la filosofía “lo frecuente, fácil, y lo complejo, posible”, etc. Otras alternativas como Visual Paradigm tenían el clásico problema de “un sólo diagrama de un tipo en un mismo proyecto”.
Al final, NetBeans. El año pasado lo estuvimos usando para un proyecto de software de nuestra facultad, y aunque era una herramienta bastante pesada, nos daba lo que queríamos: diagramas fáciles y rápidos, así como generación de código.
La versión usada de NetBeans es la 6.5, con el plugin UML.
      

Como todavía no he empezado con la implementación y barajo varias tecnologías , pues a ver si con una consulta popular me aclara .
Puede que allá , cosas que no sean Framework y yo crea que si , así que post para que así lo pueda enterder
View Poll
      

Bueno, después de unos cuantos días sin poner nada, hoy me apetece compartir con vosotros unas capturas del juego. Primero una del menú principal:

Sencillo pero funciona. Ahora dos de un partido, por ahora, todos los jugadores tienen el mismo modelo, diferenciandose solo en las texturas.


Por último, una foto del modo entrenamiento, consiste en dar en la diana, está bastante chulo.

Bueno, espero que os haya gustado, y si no no lo digais.
PD: La encuesta habla por si sola, con lo cual traduciré el código, pero a mi ritmo, por lo pronto voy a terminar lo que me queda de la memoria del proyecto.
      

Ya solo me falta implementar la cola de descargas…
Así acababa mi ultimo post, cuando creía que las partes fundamentales de Tucan habían encajado. Pero esto no era mas que un espejismo, ya que la pieza que intento implementar no encajaba en la estructura general.
Para que comprendais el desajuste necesito explicaros los distintos subsistemas de Tucan. (Solo me centrare en las descargas, pero lo que voy a comentar es extensible a las subidas)

• Por un lado esta el sistema de plugins, que es quien se encarga de las descargas propiamente dichas, cada una en un hilo diferente. Cada plugin gestiona sus descargas de forma independiente, aplicando sus limitaciones particulares.
• Por el otro esta el GUI, que es el que interacciona con los usuarios. La parte que nos interesa en este caso es un widget, gtk.Treeview que es el que se encarga de mostrar una estructura de datos, gtk.TreeStore. En esta estructura estarán todas las descargas ordenadas por paquetes y debe ser actualizada para que el usuario vea el progreso.

Lo primero que se nos podría ocurrir seria implementar la cola sobre el gtk.TreeStore, pero si lo volvemos a pensar, con esto haríamos una parte principal del proyecto muy dependiente del interfaz gráfico, decisión poco recomendable.
Por el contrario si utilizamos una nueva estructura de datos, tendríamos la información por duplicado, con lo que deberíamos de extremar las precauciones al actualizar los datos.  Además tendriamos que hacer de puente entre los plugins y el GUI.
Estoy implementando esta ultima opción, minimizando el movimiento de datos entre subsistemas, así que tendremos que esperar un poco mas hasta que Tucan pueda descargar de manera automatizada.
También quería mostraros como esta quedando el GUI en la rama donde implemento la cola de descargas.

Como podréis observar ahora las descargas están ordenadas por el nombre del archivo, conteniendo estas los posibles links intercambiables.
Un saludo, Crak
      

Otra vez estoy aquí escribiendo unas líneas, y lo primero que quería decir es que muchas gracias a todos, sois gente de p$%& madre :-). No me esperaba que entrara tanta gente y que me diérais tantos ánimos, gracias!!!! Todos me han hecho mucha ilu, pero sobre todo los de Ramón y Miguelillo, que están ambos en Inglaterra (uno en Londres y otro en Cranfield); muchas gracias gambiteros por sacar un ratillo y hacerme una visita :-)Bueno, al turrón. Perdón por saltarme el post que había prometido los dos domingos pasados, pero he estado pringando al máximo para ir sacando esto adelante, y el comienzo se está haciendo un poco durillo. Voy a intentar comentar brevemente qué he estado haciendo estas dos semanas de atrás.Metodología y planificaciónLa metodología de desarrollo que estoy siguiendo es RUP, que junto con UML constituyen la metodología estándar más utilizada para el análisis, implementación y documentación de sistemas orientados a objetos. Es un proceso iterativo, de tal forma que en cada iteración, y según el estado del proyecto, hay una serie de tareas que se deben de realizar como pueden ser definición de requisitos, realizar análisis y diseño... etc. Una de las ventajas que tiene RUP es que es adaptable a la realidad de cada proyecto, y como en este tengo tan poquito tiempo haré más hincapié en las fases de diseño y de implementación.Dicho esto, he planteado que voy a realizar 5 iteraciones, y he marcado unos objetivos para cada una de ellas. Y sobre estas iteraciones y sus objetivo, he planteado una planificación de lo que debería ser mi trabajo en estos 6 meses de desarrollo. Está realizada con un programa que se llama Planner que bueno, no es perfecto pero es bastante usable.Configuración del repositorioUna de las razones por las que tenía muchas ganicas de que comenzara el CUSL (aparte de porque estoy motivado) era porque quería contar lo antes posible con un control de versiones para ir subiendo cosillas e ir organizándome mejor; llevo usando regularmente SVN desde hace un par de años, y estoy más que contento con él. El caso es que después de que me abrieran un proyecto en la forja de Molinux, ya pude comenzar a meter mano al repositorio, que es lo que quería.Un proyecto software produce muchos artefactos o productos: documentación, especificación de requisitos, diagramas UML, código... etc., y la mayoría es posible que vayan evolucionando según vaya avanzando el proyecto. Es interesante entonces meterlos en el control de versiones, y para ser mínimamente organizado es necesario definir un layout del repositorio. Si le echáis un ojo al repositorio de eOPSOA veréis la siguiente configuración:

• code: en este directorio iré subiendo el código fuente de la aplicación. Dentro hay otros tres directorios trunk, branches y tags. No es obligatorio pero es una práctica común dentro del mundo de Subversion; muy brevemente se podría decir que en el directorio trunk se realizaría el desarrollo de la rama estable del producto, en el directorio branches se podrían crear ramas paralelas de desarrollo, sobre todo para añadir características nuevas que no podrían ser muy estables, hasta que maduran lo suficiente como para volver a trunk. Y en el directorio tags se podrían ir creando puntos interesantes, como por ejemplo la revisión que marca la versión 1.0 del software.
• management: aquí iré subiendo los artefactos que se vayan generando, como por ejemplo el subdirectorio analysis_design que contendrá el modelo de Rational Rose de diseño, planning donde irá la planificación del proyecto, requirements el modelo de requisitos de Rational RequisitePro... etc.
• y por último, proof-of-concept, que será algo parecido aun cajón de sastre, donde iré subiendo ejemplillos o pruebas que crea que puedan ser útiles.

Estado actual, y trabajo para esta semana...Teniendo una planificación, y un repositorio, tenía las herramientas que me hacían falta para empezar a trabajar y crear cosas útiles. Por algo habré hecho ¿no?, aparte de no escribir en el blog... :-P. A estas alturas puedo decir que he finalizado la primera iteración ¡bien!, y tengo lo siguiente:

• Tengo especificados los requisitos funcionales (casos de uso) para la primera y la segunda iteración. Me falta generar documentación, UML sobre todo, para describir la activación de los plugins en Eclipse, estructuras de datos y demás.
• He creado el esqueleto/armazón/stub de los dos módulos que voy a desarrollar por ahora. Por ahora hacen algo muy básico: básicamente se limitan a registrarse en Eclipse, definen una perspectiva, una naturaleza y crean proyectos (vacíos), pero es un comienzo. Sobre estos dos plugins iré construyendo el resto de funcionalidades.
• ¿He dicho que estoy aprendiendo un huevo sobre Eclipse? ;-)

El trabajo que se plantea para esta semana que entra es el siguiente:

1. Especificar los modelos EMF para el asunto de la gestión de los documentos que necesita OPSOA para caracterizar el software a certificar: el documento de visión , el glosario y un checklist.
2. Crear una serie de formularios para dar soporte a la edición y posterior persistencia en XML de los modelos anteriores.

Las tareas no parecen tampoco muy complicadas, y el asunto de la persistencia en XML no es complicada porque aunque lleva más trabajo definir los modelos de los documentos con EMF, merece la pena porque se encarga el mismo EMF en serializar y deserializar el modelo en XML.El principal problema con el que me enfrento ahora es el siguiente... que Eclipse es muy grande, y muchas cosas dependen de otras para realizarlas. Por poner un ejemplo, para hacer el formulario que he comentado antes, debo implementar la interfaz IFormEditor del API de Eclipse, porque realmente estoy realizando un editor. Bueno, pues para comprender el asunto de los editores, antes debo estudiar también las views, y para las views necesito conocer anteriormente el tema de las JFace Viewers... ahí es na. El API es enorme, hay muchas cosas que dependen de otras, y a diferencia del API de Sun (que es la que conocía hasta ahora) que es más restrictiva en cierto modo, y te "guía" a la hora de realizar las cosas, esta es mucho más flexible. Puedes hacer lo que quieras a tu aire... pero lo primero, posiblemente tardes más, y no se integre bien con la plataforma, o directamente no te funcione. O lo haces a la Eclipse way, para ello debes estudiar y mirar código de los demás, y eso también lleva tiempo y por desgracia no es algo de lo que me sobre actualmente.Me está ayudando un montón un libro que compré en eBay hace un par de semanas, se llama The Java Developer's Guide to Eclipse. Es un libro muy muy bueno, yo diría que fundamental si se está comenzando con el asunto de la creación de plugins/RCP para la plataforma Eclipse. Es un mostrenco de más de 1000 páginas, escrito por ingenieros de IBM que estuvieron/están trabajando en Eclipse. Entre historias de cambio euro/dolar, y gastos de envío me costó algo más de 40€, pero sinceramente creo que vale cada uno de esos euros :-)Bueno, nada más por esta semana, un abrazo muy grande a todos :-)Happy hacking!!