If you don’t know… maybe you don’t know :)… think in grid now is abiquo. We have relocated our blog.
See you 
Archivos de la categoría ‘think in grid’
New blog…
Junio 19, 2008
Ibergrid trip: Facendo amigos
Mayo 30, 2007La pasada semana estuvimos con un poster en el ibergrid, la primera conferencia de lo que será futura red de Grid España, Portugal y quizás Iberoamérica. El congreso lo abrió Ian Foster nada menos, con una gran charla sobre la evolución de las infraestructuras de investigación desde los griegos hasta el Grid ….
Nuestro poster presentaba la infraestructura Grid de la empresa, con los resultados correspondientes al meta-scheduler o planificador adaptativo basado en agentes de IA. Estuvimos haciendo algunos amigos:
Simulador agentes en el Grid disponible para descarga en sourceforge, versión alpha
Marzo 10, 2007Ya anunciamos en un post de hace un par semanas que teníamos completado un simulador de agentes en el Grid.
Hemos completado la fase de documentación y hemos añadido un manual de usuario que esperamos sea de utilidad. El release está ahora mismo disponible para descarga en souceforge.
Incluye:
- código fuente
- manual de usuario/tutorial
Debería de ser posible para cualquiera (con algo de background en Grid y manejo de java/eclipse) procesar el manual y ejecutar simulaciones básicas en unos 30 minutos. Animaros a probarlo!
Si encontrais agún problema intentando llevar esto acabo, agradecemos especialmente vuestro feedback.
Si os meteis a inspeccionar el código y tenéis sugerencias y/o recomendaciones, también son especialmente bienvenidas
Si os interesa lo que veais, el proyecto seguirá vivo en sourceforge, estáis invitados a participar activamente. En paralelo iremos informando por el blog de avances importantes 
AgentGrid Repast Simulator
Febrero 16, 2007Dicen algo para ti las palabras Grid, agente, y simulación en una misma frase? Entonces seguro que echabas de menos lo que vamos a presentar. Tranquilo, si no te dice nada la combinación, es muy posible que esto tambíen te parezca interesante o curioso. Sigue leyendo
Lo veníamos anunciando desde Navidades, estábamos desarrollando un simulador de agentes en el Grid. Tenemos algún post explicando para qué queremos este simulador:
Acabamos de montar en sourceforge el proyecto que da cobijo la alpha de nuestro simulador de sistemas multiagente en el Grid.
AgentGrid Repast Simulator at sourceforge
La idea central es crear una comunidad (es un dominio muy específico, pero hay bastantes investigadores a nivel europeo y mundial) al rededor de la herramienta, que es pionera ya que no existe otro simulador de Grid enfocado a Inteligencia Artificial y que sea accesible públicamente. Por un lado los investigadores obtienen una herramienta agil y flexible para analizar de manera sencilla sistmas mulitiagente en el Grid. Por el otro contribuyen a la mejora de la herramienta. La licencia, GPL. Tendremos un lugar en la web de la empresa para complementar la info sobre el simulador.
En un post posterior (en 1 semana digamos) daremos cumplida cuenta de los detalles técnicos (los imprescindibles) sobre el simulador, así como acceso via sourceforge al simulador en sí, el código y el manual de usuario. La idea central es que cualquira con algún conocimiento de los entornos Grid y algunos (escasos) conocimientos de Java, y una idea de lo que quiere que sus agentes hagan y como quiere que aprendan (eh, esta parte no la podemos hacer por ti, esa es tu aportación creativa a la receta;) podrá disponer de una herramienta sencilla para testear sus hipótesis.
De momento os pasamos este video para que podais verlo en acción. Pedimos disculpas por la baja calidad del video, de momento lo nuestro es el Grid y no la edición de video / optimización de formatos para youtube. Agradecemos consejo de algún entendido en la materia sobre herramientas/trucos para pulir la edición del video
Noches de bohemia… y java
Enero 21, 2007Llevamos 4 días metidos en el despacho, 4 días non-stop donde el portero del edificio nos mira con cara rara. 4 días a ritmo de start-up. 4 días para poder cerrar temas aplazados, empaquetar demostraciones y terminar material de soporte para mostrar a nuestros futuros clientes a que cosas nos dedicamos y que cosas podemos llegar a realizar con ellos.
Pero no quiero hablar de ventas… quiero hablar de las demos.
Think in grid cuenta con una herramienta interactiva que se dedica a comprobar resultados obtenidos de una base de datos para recuperar el patrón molecular que más se parece al que el usuario ha dibujado por pantalla. Ya os aviso que el cuello de botella se encuentra en dicha comprobación, y más cuando te encuentras con una base de datos repleta de valores, y mucho más cuando esta base de datos se encuentra distribuida por toda tu organización. Pues nada, a gridear se ha dicho. El resumen del resultado es el siguiente:
- 3 horas de definición técnica de los objetivos.
- 2 horas para montar el servicio de comparación de moléculas. Aclarar que el algoritmo de comparación no está hecho por nosotros, menuda gracia tendría hacer algo que desconocemos y que será uno de los pre-requisitos marcados por el cliente.
- 1 hora para montar el entorno. Un Framework corriendo sobre un servidor Tomcat con axis2 y 4 middlewares (1 línux, 2 windows y un mac). Toda una delicia.
- 53 minutos (Contados con el reloj). Para programar la aplicación con la infraestructura grid (Instalar la librería de desarrollo y escribir 4 líneas de código).
Con eso cumplimos el primer pre-requisito de nuestra arquitectura. Simplicidad de implementación.
Pero tiene truco…. porque eso no suma 4 días… La verdad que toda la complicación la hemos encontrado en 2 puntos, que creo que conocido por todos los programadores java de este, nuestro mundo.
- Gestión de librerías…. No puede ser que sea un caos definir que librerías necesitas. Que entre librerías existan conflictos porque dentro de ellas tienen otras librerías repetidas entre jar’s, que te vayas encontrando con incompatibilidades a medida que pruebas…. ufff, ha sido toda una odisea.
- Java.policy. La aplicación la teníamos corriendo en un simple applet (No quiero comentarios). Y eso conlleva modificar las políticas propias de seguridad que implementa Java en su ficherito Java.policy, que dicho quede de paso… puedes llegarte a encontrar 3 o 4 versiones del mismo en tu ordenador y no sabes cual tocar, y como tocarlo. ¿Cual es el motivo de esto? Porque no utiliza las propias políticas de seguridad de la máquina? Porque de tanta anarquía? El tema esta en que ya somos casi expertos en el tema…. y no nos sirve de nada :).
De estos dos puntos Albert ya se encargará de hacer una buena optimización a nuestra librería y a lo que no lleguemos por limitaciones, un buen manual y una dirección y foro de soporte… lo arregla todo.
Pero aún queda 1 día y una noche más. La demo debe de estar para el lunes a las 19:00. Ya sabéis… clientes y esas cosas…. Por eso ahora toca adornarnos…. Y vamos a rematar el trabajo realizado con los siguientes puntos.
- Sacaremos números de rendimiento para ver que tal funciona esto. (Isaac nos lo agradecerá)
- Integraremos la primera versión del portal de Gestión Grid que está realizando Kiusap.
- Montaremos una presentación de soporte para la venta :).
Y con eso creo que nos mereceremos unas buenas vacaciones: Lunes por la noche libra todo el mundo. El martes por la tarde volvemos al trabajo.
PD: La foto lo dice todo… material de start-up.
Marca en Flickr aquello que reconozcas
“What are all those guys doing down there at 2 a.m.?”
Noviembre 17, 2006
That is what our neighbors wonder about. Here is the answer:
Think in grid was founded in early 2006. We are a group of heterogeneous people located in Barcelona. Young people with fresh ideas and a breakthrough technology that will offer an interesting range of solutions in a few time.
We have developed the first multiplatform multidevice Grid application, which is also as light as 300Kb. We are also in the final steps of developing a framework, which easily allows programmers to develop services that work with it.
To sum up, we have a system that distributes not only processing capacity of the devices involved, but also storage and accessibility to any kind of resource within these devices.
As a friend would do, all the devices in a network work together to provide a service to one or more than one members of this network.
All that stuff is how we do things. Right now we are working in the following fields:
1. Embedded devices: Wherever you are, whatever you need. Your mobile device is no longer a mobile device, but all you want wherever and whenever you want it. Because resources are virtualized, you only need to develop applications once. Take advantage of other devices available to develop application you never imagined. It is not a matter of having all your data, information and files with you, but to be able to access to it, and that is what we do.
2. Streaming: due to the high processing capacity and interoperability that our technology provides, audio and video streaming can be delivered to a huge range of computers and devices, including mobile phones, PSPs and s.o.
3. Massive distributed computing capacity: do you guess which is the less optimized resource in your company? Computers! Only 8 hours working at, let’s say, 10% of what they are capable of? We take advantage of this valuable resource to save you costs while you are processing huge amounts of data you never thought you are capable of. It is not only that it reduces costs, but also allows you to obtain valuable and differentiable information from the data you already have, something that will give you a clear competitive advantage. IBM makes you buy mainframes? Never more!
4. Virtual Organizations and Social Networks. You should have people and objectives; we deliver the resources and infrastructure needed. Build “all to all” connections, forget about complex networks and extremely pricy solutions.
We are also working in other interesting stuff such as sharing PSP saved games or creating a world community of processing & storage.
Want to know more? Keep visiting us. More and more things are on the way : )
Requerimiento: acabar con los requerimientos
Noviembre 1, 2006Esta semana, Xavi y yo hemos estado hablando sobre los requerimientos. Y me alegra que en un tema tan trascendente estemos de acuerdo sin necesidad de darle excesivas vueltas.
Llevo varios años en proyectos de investigación, y he pasado por dos proyectos europeos. Si algo he aprendido es que los requerimientos no sirven absolutamente para nada. Bueno, sí. Sirven para darse cuenta al final del tiempo de implementación de que los requerimientos más estúpidos han sido cumplidos con brillantez mientras que los esenciales aún están criando malvas en lo más profundo del documento de análisis. Por supuesto que ésto no tiene que ser una regla general. Pero sí que es aplicable a nuestro proceso de desarrollo.
Tenemos la inmensa suerte de estar recopilando un grupo de gente competente que, además, sabe cuál es el objetivo y dónde tenemos que mirar en cada momento. Como equipo. ¿Hace falta que malgastemos nuestro preciado tiempo en redactar un documento lleno de frases sin sentido, que no hacen más que cimentar una futura carrera de obstáculos?
La respuesta es NO.
En una de las transparencias de la presentación base que Tom Peters lleva a cuestas por todo el mundo, hay una cita extraída de "Bloomberg por Bloomberg" que describe lo que quiero expresar con suma precisión:
“We made mistakes, of course. Most of them were omissions we didn’t think of when we initially wrote the software. We fixed them by doing it over and over, again and again. We do the same today. While our competitors are still sucking their thumbs trying to make the design perfect, we’re already on prototype version No. 5. By the time our rivals are ready with wires and screws, we are on version No. 10. It gets back to planning versus acting: We act from day one; others plan how to plan—for months.”
Grid Computing y GMPLS
Septiembre 25, 2006Ando unos días buscando información sobre el tema. El otro día me entró el gusanillo mientras pensábamos en nuevos recursos que añadir a nuestro catálogo de "plugins" para el middleware. Y es que, como ya sabéis (Y si no lo sabéis ahora es el momento), soy Ingeniero de Telecomunicaciones y de entre los temas que más me atrajo en mi dorada época estudiantil, las redes ópticas y las nuevas arquitecturas definidas sobre ellas.
Las redes ópticas actuales constan de un elevado número de capas que otorgan la capacidad de manejar perfiles determinados de información, lo que estaba tendiendo a redes demasiado específicas y difíciles de gestionar. Pero a algunos iluminados se les encendió la bombilla y pensaron que las redes debían simplicarse, evitando funcionalidades redundantes entre capas. Esto derivo hasta llegar a tener solo dos. Esto ha permitido desarrollar un plano de control común, y entre algunos protocolos de gestión, se encuentra GMPLS.
GMPLS es el resultado del trabajo entre Optical Internetworking Forum, Optical Domain Service Interconnect consortium y la Internet Engineering Task Force que pretende estandarizar un protocolo que pueda servir para todo tipo de tráfico. La clave se encuentra (y aquí os empezará a sonar a Grid) en la capacidad que tiene la capa de control de extender la topología de la red y la gestión del ancho de banda a lo largo de todas las capas para lograr un sistema eficiente que integre servicios y transporte.
Siguiendo con la filosofía Grid, GMPLS necesita tres componentes básicos para su correcto uso:
- Exploración de recursos: se obtiene información acerca de los recursos de red tales como conectividad o capacidad de los enlaces. Los mecanismos utilizados para diseminar esta información de estado se basan en una extensión del Internet Gateway Protocol (IGP).
- Selección de ruta: se utiliza para seleccionar una ruta apropiada a través de la red óptica inteligente en base a unas ciertas restricciones impuestas por el entorno y las limitaciones de la capa física.
- Gestión de ruta: incluye distribución de etiquetas, así como establecimiento, mantenimiento y terminación de ruta. Estas funciones se realizan por medio de un protocolo de señalización extendido como Resource Reservation Protocol for Traffic Engineering (RSVP-TE) o Constraint-routed Label Distribution Protocol (CR-LDP).
Estos tres componentes deben estar diseñados para su correcta utilización independiente entre si, permitiendo a las operadoras diseñar sus redes en consonancia con su modelo de negocio.
Aquí entra ThinkInGrid y nuestros componentes desarrollados. Queremos llegar a desarrollar un plugin capaz de virtualizar los datos provenientes de una red óptica. Esto debería permitir a empresas mucho más especializadas desarrollar productos o proyectos a medida para gestión de redes troncales:
- Uso de información descentralizada y distribuida por la red.
- Uso del plano de inteligencia artificial para optimizar y automatizar procesos de control y balanceo de carga.
- Monitorización de red añadiendo un plano de decisiones automatizadas.
- Desarrollo rápido y estandarizado de aplicaciones mediante el Framework.
- Creación de mecanismos de colaboración entre operadoras o empresas complementarias.
- Generación de nuevos modelos de negocio. Lo que permite una clara diversificación de servicios.
Bueno, creo que la cosa está clara. ¿Algún directivo de Telefónica, Wanadoo, Jazztel, Ono, etc en la sala y que quiera desarrollar la idea con nosotros? Las líneas de teléfono y de mail quedan abiertas :).
Colaboro, ergo, me comprometo
Agosto 15, 2006Estos días de meteorología variable en Barcelona desde el equipo de desarrollo de ThinkInGrid andamos ultimando la primera fase de nuestro entorno Grid. Como primer paso, a partir de ahora, eludiremos la palabra computing, en clara alusión a nuestra orientación a cliente y no a tecnología, tal y como se empieza a insinuar en los post de Albert y Diego.
Nuestro siguiente paso, utilizar dicho entorno para adaptar una aplicación ya existente a este nuevo modelo. Con esto, la búsqueda de varios objetivos:
- Testear la arquitectura desarrollada.
- Testeo integrado y funcional del entorno.
- Testeo de los primeros servicios desarrollados y desarrollo de nuevos servicios básicos no contemplados en fase de análisis.
- Empezar a realizar valoraciones prácticas de las mejoras que aporta el desarrollo realizado. Que mejor forma que acercarnos al cliente con números reales y no solo con propósitos
- Primera aplicación grideada con nuestro Framework y que corre sobre nuestro Middleware.
- Medir la convergencia con otras arquitecturas Grid pero que cumplen con los estándares.
Para dicho acometido, se está valorando la utilización de alguna herramienta colaborativa. Lo primero que se nos viene a la cabeza es el uso que se le está dando a dichas herramientas, que hasta el momento no está mal, pero estoy seguro que aún es insuficiente. Según la RAE COLABORAR: "Trabajar con otra u otras personas en la realización de una obra.". Puntualizo con un sinónimo que nos aporta: CONTRIBUIR, lo siento, pero me encanta. Ahora yo modifico la definición para nuestro propósito: "Trabajar con otro/a u otros/as departamentos u organizaciones para la realización de una obra".
Si se empieza a pensar en la definición lo primero que se te pasa por la cabeza es: compartir ficheros, foros, interlocución on-line vía chat, etc. que no está mal, pero vamos, que me sabe a poco. ¿Se os ha encendido la lucecita? A nosotros si. Y con nuestro entorno estamos pensando en:
- Compartición de potencia de cálculo en una organización virtual. (1 problema contra 100 cpu’s = solución rápida y fiable).
- Compartición de recursos (Yo invierto en una herramienta de análisis biomédico y vosotros aportáis a la herramienta vuestras BBDD –> Todos le sacamos la máxima rentabilidad).
- Compartición de servicios (Yo se mucho de análisis de genoma, pero no puedo dedicar más personas a tu proyecto, te cedo el uso de mis servicios específicos para que explotes la información).
- Toma de decisiones en tiempo-real (colaboración entre 10 empresas, no nos podemos reunir cada semana para decidir que hacer en tareas del día a día. Porque no automatizamos decisiones con inteligencia artificial en función de parámetros económicos, estratégicos, humanos, etc.).
- Monitorización de la contribución (¿Como repartimos el pastel después de la colaboración? ¿Quien se ha mojado más el culo por esta idea? ¿Como saber con quien volver a trabajar?).
- Y podríamos seguir…
Sin duda esta reflexión me ha llevado a creer y darme más argumentos para defender que nuestras herramientas llevan un buen camino si son lo suficientemente generalistas para poderse adaptar rápidamente a cualquier sector y son lo suficientemente concretas para aportar mejoras reales en entornos determinados. Porque por mucho que alguien se encabezone, la colaboración entre empresas de biomedicina nunca requerirá de las mismas necesidades que una colaboración entre entidades financieras.
xfernandez
