If you don’t know… maybe you don’t know :)… think in grid now is abiquo. We have relocated our blog.
See you ;)

Think in grid wants to wish you a MERRY CHRISTMAS and a HAPPY NEW YEAR

Thank you John ;)

Yesterday, Angel and Miguel, creators of the development Flex framework called Guasax visited Think in grid. After a visit to CitiLab and greet people of iWeekend, we started to talk about Flex and how to apply it in our Grid Portal.

One point for Diego, who started to defend it a few months ago. Flex it’s a very good RIA solution, maybe the best. Angel and Miguel solved our questions and my concerns:

1º I don’t want to use another technology if I can solve it with Ajax, gwt or other java solutions. Flex surpass the probe. It’s easy to learn, and the most important thing, it’s very easy to integrate with a Java architecture (I am thinking in Spring + hibernate). And the development time is shorter than a RIA application using Ajax. The result, no color, flex wins.

2º The performance. Our web application have on-line chart pages, Many nodes to manage, etc. This page answered our concerns.

3º How much does it cost? Flex is open source. The development IDE (Standalone or eclipse plugin) is unexpensive. Maybe the bad news are that some interesting solutions (data management module) are expensive when the application is stored on a production environment. But we can avoid this module using our own solutions.

4º No limits. Easy development for rich interfaces with usability and design. All in one.

Thanks to Angel and Miguel, now we will start to work and “think in flex”.

Con este título, robado de mi querido Albert abro este pequeño post. Digamos que está bien hablar de otras empresas o de externalidades, pero de vez en cuando toca contar como va el tema técnico.
La verdad que las cosas pintan muy bien, después de un proceso intenso de prototipaje en estos últimos 4 meses el FW entro hace 2 semanas en fase de testeo intensivo donde tenemos varios objetivos:

· Probar el sistema de Agentes desarrollado por Isaac y sacar conclusiones.
· Hacer sufrir el FW e ir depurando código para sacar el máximo partido y conocer los límites actuales con los que nos encontramos.
· ¿Cuanto fácil de instalar es?

Sobre el primero… creo que Isaac estará encantado de comentar sus resultados en otro post, hace 1 semana que se ha cerrado en su laboratorio de pruebas y anda allí jugando con el tema. De forma sencilla, en mis últimas pruebas pude observar como el FW descartaba uno de los nodos al comprobar que este andaba saturado haciendo cosas en local.

Sobre el segundo punto… Espero que Albert os comente algo, pero ya ha montado su servicio de saturación y ha empezado a realizar peticiones intensivamente a la arquitectura. Hasta el momento, 1086 conexiones abiertas entre el FW i los diferentes MW. No está mal ;). Encima se ha montado un interesante sistema de monitorización que nos permite ver bonitos gráficos online de la carga de CPU en cada MW y el estado de las diferentes colas de ejecución.

Por último, la prueba de fuego :). Diego ha cogido el FW y el MW y mediante documentación generada en nuestra wiki interna ha instalado todo el entorno en el despacho. Creo que ver su cara de satisfacción no tiene precio :). En 15 min. (Contando la instalación puramente estandard de Tomcat), a conseguido hacer correr un pequeño Grid con 7 nodos (1 Linux, 2 Mac y 4 Windows).

Bueno, después de lanzar retos a Isaac, Albert (Para que escriban un post) solo me queda añadir que todo y las interesantes resultados obtenidos en las pruebas (hasta el momento) ya tenemos una larga lista de @TODO’s para la próxima versión (de aquí la grandeza del prototipaje) que, añadido a la agonía a la que estoy sometiendo a Albert con la documentación del FW nos permitirá tener una versión de la que ahora ya, nos sentimos muy orgullosos.

Por cierto, ando buscando artículos, manuales, documentación que hable sobre testing de arquitecturas montadas con tecnología Java, cosas a tener en cuenta, herramientas, etc. El objetivo, añadir más conocimiento a lo que ya tenemos hasta el momento y encontrar otros puntos de vista en ejecución de pruebas de estrés. Por lo tanto, lanzo está petición a quien quiera contar sus experiencias.

Hasta la próxima…

Llevamos 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:

1. 3 horas de definición técnica de los objetivos.
2. 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.
3. 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.
4. 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.

1. 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.
2. 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.

1. Sacaremos números de rendimiento para ver que tal funciona esto. (Isaac nos lo agradecerá)
2. Integraremos la primera versión del portal de Gestión Grid que está realizando Kiusap.
3. 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.

Creo que los comentarios e inquietudes expuestas por Luís y Lluís se merecían un nuevo post.  Nos hemos sentado Albert y yo, un par de vasos de Coca-cola y este es el resultado:

Web Services e interoperabilidad… ese gran dilema. No creas que no hemos hablado de ello. Si una cosa está clara es que los web Services fueron definidos para solucionar la interoperabilidad. Y después de mucho darle vueltas, creemos que Axis cubre nuestras expectativas. Así, como funcionalidad, se puede desplegar el framework como web service. Esto nos permite conectarnos a un framework remotamente a través de una interface web (pudiendo administrar o requerir ejecuciones).

Como dice Luís "…no es un problema atacar un SW implementado en Java desde un cliente .Net, Python o Symbian C++.." . Yo incluso creo que cosas sencillas y un poco complicadas, que realmente por mi justa experiencia creo que cubrimos el 90% de las necesidades de todos nuestros clientes potenciales. Pero ya puestos a pedir, y espero que no me cobres por ello , conoces alguna tecnología que te cubra todo el abanico de posibilidades?

La API de aplicaciones (ya hablaremos más adelante de que lenguajes soportaremos) permitirá la representación en objetos para su manipulación,  que en última instancia se traduciran a mensajes xml a enviar al FW (a través del puerto nativo). Por lo tanto destacar que tanto los mensajes que llegan a través del web service como en socket son equivalentes.

Lo que se comentaba sobre la API REST, quizás no me he explicado bien. Es justamente lo que tenemos :). Un servidor web + AXIS + XML. Todo y eso, creemos que no debemos olvidar tener un soporte clásico de sockets, porque como dices tu en otras palabras, no se puede pedir todo en esta vida y menos a los web Services.

Ligero, si, ligero, ligero, ligero. Por suerte, el diseño de nuestra arquitectura requiere de un módulo ligero en cada nodo de la red (El middleware) pero nos podemos permitir el lujo de decidir que FW exponen sus servicios en forma de web services, que es la parte central (que no centralizada) de nuestra arquitectura.

Los beneficios que nos aportaba tener sockets y SOA era mayor a los perjuicios de no hacerlo. Encima, está montado de tal forma que se reaprovecha gran parte del código en las dos interfaces (Que en el fondo es una pero con dos puertos de entrada).

La liberación de código está planificada para finales del mes siguiente (si todo va según lo planificado). Como comentábamos en el post del KICK OFF, de entrada no liberaremos el framework.

Sin más me despido. Gracias por vuestros comentarios :)

Creo que de entre todas las cosas que estamos desarrollando en ThinkInGrid la más importante se encuentra en la pasarela de entrada (API) a nuestra arquitectura basada en la comunicación por mensajes XML y donde esperamos que empresas de todo el mundo programen sus aplicaciones.

Como conseguir llegar a ser lo suficientemente específicos para que nuestra arquitectura sea sencilla de usar y como llegar a ser lo suficientemente abiertos para no limitar las mentes perturbadas (En las  que me incluyo) a la hora de diseñar una nueva aplicación.

Llegados a este punto y como si de un hijo se tratara actualmente estamos trabajando en ello. Es por eso que hoy quiero mostraros un par de pinceladas sobre la decisión tomada sobre el acceso a la API.

La decisión… no cerrarnos a un solo tipo de acceso. Es por ello que hemos preparado un entorno que permitirá trabajar con web services o con el sistema tradicional de sockets (Habilitando un puerto para dicho proposito). Por supuesto…a gusto del consumidor.

Sobre la primera, el motivo es claro, subirnos al carro de las nuevas arquitecturas SOA, facilitar la comunicación entre máquinas en una red y ofrecer al desarrollador la posibilidad de brindarle las ventajas que proporciona dicha tecnología. Para ello,  mediante un servidor de aplicaciones (Tomcat, WebLogic, etc.), nuestro framework y Axis ofrecemos la posibilidad de interactuar fácilmente con toda la arquitectura grid que pueda tener un dominio o grupo de dominios determinado. Como ejemplo de uso y que nos servirá para accelerar implantaciones en cliente estamos desarrollando un entorno web para el mantenimiento de dominios Grid.

Los sockets, para los nostálgicos, para los que prefieren seguir realizando comunicaciones entre máquinas sin depender de un servidor web, o simplemente para los que por necesidad de entorno precisan de esta comunicación.

¿Que creéis vosotros? En ThinkInGrid creemos que no podíamos descartar ninguna de las dos opciones y es por eso que hemos dedicado nuestro tiempo a implementar las dos posibilidades. Por ejemplo, Albert está acabando unos scripts muy chulos con el ANT para facilitar la carga del framework.

Y eso es todo lo que os puedo contar… seguimos en contacto.

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 : )

Cada vez queda menos, cada vez más Thinkingrid empieza a oler a "máquina rodada". Es curioso observar, desde mi posición en el margen entre la parte técnica y  la parte de negocio como los elementos que conforman esta "comunidad virtual" empiezan a actuar sincronizados. Es curioso, pero pronto va ha hacer 9 meses que montamos este proyecto, la criatura está lista para salir.

Los técnicos no cumplen sus horarios ni por asomo, pero saben hablarse entre ellos para estar juntos el mayor tiempo posible. Estamos empezando a ser muy eficientes (y me gusta). Isaac, el más precoz en la compañía, está perfectamente integrado en Thinkingrid e incluso se atreve a dar sus pinitos en el área comercial, jeje. A Sergio le sigue creciendo el pelo, y cada vez se le ve más seguro de que el middleware+framework están ofreciendo los resultados deseados. Y esto nos empuja a todos a seguir trabajando cada vez un poco más. 

El modelo de negocio, superado, a ver si Albert Miquel se anima a escribir unas líneas en este blog y pronto empezamos a colgar la web corporativa. Los continuos brainstorming aportan valor (y me gusta).

Esta semana ha sido eSpEcIaL. Después de anunciar el éxito de la primera versión del middleware, de conseguir nuestra primera (aunque pequeña) primera subvención lo fuimos a celebrar con una humilde cena. Se respira buen rollo (y me gusta). Antes conocimos a Yannick Laclau, veterano de guerra en start-ups, que nos dio su visión de todo este mundo. Fue alentador ver como una persona como él, sin nociones de programación, un día decide dedicarse a ello y actualmente está a punto de sacar al mercado una idea potencialmente buenísima que ya os la contará él mismo. Ramón y Sergio fueron a visitar a nuestro primer ¿cliente? ¿betatester externo a ThinkInGrid? ¿Partner? Espero pronto poder hablar más de ello por aquí. Y por último, y después de una intensa reunión, ya tenemos decidido nuestra política comercial : "Orientar nuestra fuerza de ventas a las empresas con las que queramos trabajar". Alguien puede creer que es pretencioso, yo les diré que es la clave del éxito. Con una plataforma tan abierta como la que ofrece ThinkInGrid, el mercado es amplio, por lo tanto, mejor crecer con proyectos que motiven al equipo, las metas están garantizadas.

En fin, somos exigentes (Que se lo digan a Diego, nuestro validador de código web particular), y sabemos que aún estamos entre las cuatro paredes de esta oscura oficina, con muchas ilusiones, i con mucho camino que recorrer. Pero si todo sigue igual, no dudo en que este grupo de amigotes de universidad podamos dejar nuestra huella en este competitivo mundo (Y me gusta).