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

1. 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).
2. 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.
3. 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 :).

Los lectores habituales habréis notado que hasta el momento apenas hemos hablado de la tecnología Grid, ni hemos entrado en profundidad a explicar nuestros productos o modelo de negocio. Todo ello irá saliendo en breve.

Nos hubiese gustado seguir volando "below the radar" hasta poder presentarnos en condiciones, pero la competencia nos ha "descubierto". En nuestros logs veíamos peticiones desde sus dominios, e incluso accesos desde webs de traducciones.

Hoy, Dan Ciruli de Digipede nos ha dejado un mensaje. Muy cordial pese a ser competidor. Sergio y yo, por contra, solíamos "trollear" en sus blogs. Con educación, también :)

Así que toca empezar a mostrar las cartas. Seguid atentos al feed.

Ander Hilario ha posteado un video motivacional sobre ventas. Casi me arrepiento de no haber enviado a Albert a un cursillo parecido antes de que se fuese de ventas por España esta semana. Sencillamente, acojonante.

Creo que es mucho mejor el de Glengarry Glen Ross. A ver si lo consigo.

If I’m going to do something, I do it spectacularly or I don’t do it at all.

Prince Alwaleed Bin Talal Alsaud

Anything that can go wrong, will go wrong.

Edward A. Murphy Jr.

Si el día ha empezado cojonudamente bien al poder, al fin, juguetear con nuestro producto y comprobar que es más eficiente que cualquiera de la competencia, la tragedia se ha cebado con nosotros esta tarde.

Mañana íbamos a tener la g-r-a-n reunión. Tras meses de pequeñas reuniones e intercambios de información, al fin un cargo directivo, con potestad para tomar decisiones, de una gran empresa viajaba a Barcelona para entrevistarse con Ramón. Murphy ha querido que a Ramón se le estropease el coche esta tarde mientras volvía de Benasque, y tras una breve comunicación para avisarnos, lleva horas sin cobertura

Así que la situación es tristemente entretenida: en Madrid no hay nadie en las oficinas a quien avisar para que esa persona mañana no coja el puente aéreo, Ramón está en medio del Pirineo sin cobertura  y ninguno puede sustituirle.

Barajadas todas las alternativas, incluso incumplir el artículo 20 de la Ley Penal y Procesal de Navegación Aérea, no queda otra opción que resignarse. Ajo y agua.

Son casi las 6 de la mañana y acabamos de vivir la sesión de programación más intensa que recuerde, pero ya podemos anunciar que tenemos versión "release candidate 1".

Y con sólo 2 días de retraso :)

Ahora queda lo más difícil: explicar claramente que es lo que hemos desarrollado. Aunque mejor se lo dejo a otro.

Este post difiere mucho del contenido habitual, pero hay un chico de Valencia que necesita ayuda.

Conoció a una chica en una discoteca, pero su timidez le venció y no le pidió su telefóno. Ahora pide ayuda para ver si alguien puede localizársela.

Lo curioso es que su estrategia para localizarla esta basada en el teorema del "número Bacon", una ejemplificación del Teorema de Erdős para distancias colaborativas.

Dada la acuciante necesidad y el planteamiento freak para enfrentarse a la sitaución, se merece nuestro apoyo. Aún así, me gustaría leer una modelización ampliada del problema, y, si la encuentra, un estudio sobre la solución. Ojalá tenga suerte :)

[UPDATE]: En Menéame también se hacen eco

Me entero por Don Dodge que finalmente Kiko Calendar fue subastado por 258.100 $, más de 5 veces por encima del precio de salida.

La intención de Tucows es integrarlo en su e-mail como un servicio extra. Este resultado va en linea con el post  que escribí cuando empezó la subasta: la mejor forma de darle valor es permitiendo la integración con otras aplicaciones. Tucows se ha ahorrado mucho dinero en programadores (programar un buen calendario no es algo trivial), y puede rentabilizarlo licenciando. Elliot Noss, CEO de Tucows, ofrece más explicaciones en su blog.

Interesante ver en la página de la subasta que en los últimos minutos la puja se incrementó en más de 100.000 $.

En breve ampliaremos nuestro equipo, por lo que estos días estamos líados definiendo perfiles "óptimos".

De entrada tenemos muy claro el concepto "no false positive": en una startup sería posible establecer una regresión muy ajustada entre el potencial de sus primeros trabajadores y sus ingresos en los 2 primeros años, por lo que no se deben cometer errores al contratar. O estamos todos perfectamente seguros de que la persona va a ser la apropiada para el equipo, o no hay contrato. Caer en el error "hire fast, fire fast" puede ser extremadamente costoso en demasiados aspectos.

Cada uno tiene sus manías para dar el visto bueno, aunque quizá la mía sea la más peculiar: no contratar a nadie a quien no permitiese casarse con mi (hipotética) hija. Esta condición para establecer relaciones hace décadas que la práctica Warren Buffet, y no le va nada mal.

Por otro lado, es curioso ver que las entrevistas de trabajo mantienen su fórmula invariable: el entrevistador miente, el entrevistado miente más, y ambos cruzan los dedos mientras se dan la mano confiando en que el otro trague. Algunas empresas intentan sofisticar el proceso añadiendo psicotécnicos (algún día tocará hablar calmadamente sobre el tema).

Más invariante en el tiempo permanece el formato "curriculum": son iguales hoy que hace 20 años y son iguales unos con otros. Además, si es difícil encontrar un business plan que cumpla sus previsiones financieras, mucho más es encontrar un curriculum en el que no hayan mentiras o exageraciones. ¿Alguien puede darme algún motivo lógico y coherente para mentir en un currículum?

Pensando en ello, sería interesante observar variaciones en el formato aplicando conceptos de "marketing lateral": en vez de adjuntar la experiencia (preferiblemente sin maquillar), explicar qué ofertas rechazaste anteriormente y por qué. Llegar a este punto implica que se ha tenido un exceso de demanda y personalidad suficiente, lo que hace sumar muchos puntos.

En definitiva: contratar es difícil y mucho más con usos y costumbres ineficientes.

Entre línea y línea de código son comunes los brainstorming entre el grupo de trabajo con el humilde propósito de descargar nuestras apretadas mentes y porqué no, encontrar esa idea que nos expulse del anonimato.

Hoy le ha tocado el turno a las arquitecturas ad hoc. Para quien no sea entendido en el tema, os comentaré que estas infraestructuras pretenden inhibir el concepto de nodo central para tender a un entorno en el que todos los recursos estén en igualdad de condiciones, o lo que es lo mismo, los elementos en una red, comparten las funcionalidades de cliente/servidor por igual.

Actualmente, uno de los máximos exponentes que se ha popularizado gracias a la implantación en un sinfín de "gadgets" es el sistema Bluetooth, que ha facilitado la interconexión entre dispositivos sin necesidad de pasar por entornos centrales, lo que ha facilitado saturaciones, colapsos, mal humor, etc.

Pues si señores, en ThinkInGrid hemos, estamos y vamos a seguir pensando en el concepto mientras desarrollamos nuestro entorno MIDDLEWARE - FRAMEWORK con el objetivo de descentralizar al máximo las "Funciones Grid" y de esta forma aprovechar las ventajas que proporciona las redes Ad hoc tanto en protección contra errores, transmisión de información, etc.

Nuestro Middleware basándose en estos conceptos proporciona una arquitectura muy ligera a cualquier estructura de recursos heterogéneos (Ordenadores, SCADAs, PDAs, camiones, dispositivos domóticos, etc.), sobre cualquier tipo de comunicación: Wireless, bluetooth, satélite, Powerline Communications, etc.; y mostrándose dentro de la misma estructura de información para nuestro FRAMEWORK, lo que permitirá a nuestros clientes afrontar infinidad de problemas (proyectos) de origen variante en un entorno homogéneo de análisis y desarrollo.

Por otro lado el FRAMEWORK, entre otros, proporciona los protocolos de protección de errores, descubrimiento de recursos, seguridad y gestión de colas que todo sistema Ad Hoc necesita. Todo embalado en un elegante sistema orientado a servicios (SOA) y que ha de facilitar el desarrollo estructurado de cualquier entorno empresarial.

En resumen, veamos las ventajas que proporciona durante la fase de desarrollo de un proyecto:

• Reducción de tiempos de análisis. –> El desarrollo se define siempre para un mismo entorno.
• Generalización de problemas –> Para un programador, la forma de utilizar un recurso CPU será igual que para utilizar un recurso EMBOBINADORA .
• Fácil adaptabilidad de los equipos de desarrollo –> El desarrollo siempre se realiza sobre una misma plataforma
• Disminución de impactos –> Si el entorno es conocido, los riesgos son fácilmente cuantificables.
• Minimización de desviaciones. –> Si el entorno es conocido, las desviaciones son medibles.

En resumen, REDUCIMOS COSTES en los proyectos de desarrollo. Y aún nos falta por contabilizar el beneficio económico derivado de la propia aplicación o las ventajas técnicas que adquirirá el proyecto por el uso de nuestros entornos.

Nunca el pensar en entornos ad hoc fue tan fácil, con ThinkInGrid ese día ha llegado.