Destacar que esta nueva versión ha incorporado nuevos desarrolladores y el trabajo de nuestro nuevo puesto en documentación (Technical Writter), todo un mundo J.

Las funcionalidades más destacadas de esta versión es la siguiente:

• Gestión avanzada de roles (Con más de 50 privilegios que gestionar): Capacidad de crear roles a nivel genérico o roles específicos a nivel de empresa. Esto tiene muchos casos de uso como podéis imaginar, por ejemplo, tenemos clientes que quieren gestionar Grandes clientes (Que les darán roles especiales) y clientes pequeños, que no podrán crearse sus propios roles.

• Integración   LDAP/AD: Autentificación a través de LDAP. Funcionalidad básica requerida por muchos clientes Enterprise.

• VMware Distributed Virtual Switch: Uno de los grandes ausentes en el producto hasta el momento. Hace unos años decidimos prescindir de esta integración debido al precio de licencias requerido con los ESX. Pero debido a que ha sido uno de los requerimientos más repetidos de nuestros clientes hemos decidido incorporarlo.

• HA (Alta disponibilidad) :  A petición de varios clientes, lanzamos una primera versión de HA, en el que es Abiquo quien gestiona las maquinas que han caído y mueve las VM entre nodos. Esto está orientado a clientes  que no quieren usar los sistemas proporcionados por los hypervisores. A más a más, es un sistema que respeta las reglas de negocio definidas en la plataforma (¿HA inteligente?).

• Persistent Volume Management – allows iSCSI volumes to be added to a VE pool using an IQN:  A esto le llamamos Business iSCSI. Esto también es petición de varios clientes enterprise, que no querían delegar la funcionalidad de self service storage. Cualquier cabina iSCSI puede ser gestionada (En modo no self service) por abiquo. Modo no self-service significa que el volumen se crea en la cabina, se da de alta en abiquo y se asigna a un Cliente. Una vez allí, se puede usar en el flujo normal de almacenamiento.

• Cisco UCS Discovery and Power Management: La primera integración con los sistemas UCS. En esta versión te permita crear un UCS como un Rack Gestionado en abiquo, descubrir los blades y el hypervisor instalado en él, añadiendo capacidades de parado y encendido de blades. Un primer flujo básico que abre la puerta a futuras integraciones. Vale vale, que no sabéis que es UCS. Aquí un link.

• Secured VNC Connections to VMs:  Una mejora requerida por la plataforma. El usuario puede añadir un password a la VM para mayor seguridad en la conexión VNC.

• Configuración de tipo de reserva: Esto también requerido por algún cliente. Hasta ahora en abiquo puedes asignar unas máquinas físicas a una empresa. Esto significaba que esta empresa podía desplegar  en estas máquinas reservadas o en las maquinas compartidas por todo el mundo. En esta nueva versión el cloud provider puede escoger si usa este comportamiento o restringe el uso de solo las maquinas reservadas a esa empresa.

• API Extensions – Permitimos VM Start/Stop/Pause y gestión de reglas: Con el objetivo de ir cerrando y completando el API (Que está quedando muy completa), proporcionamos las habilidades básicas de PowerOn, PowerOff, Pause, reset de una VM y gestionar las reglas de despliegue en la plataforma y un DC físico, que se une a todas las capacidades que tiene hoy por hoy el API.

• Mejoras en el sistema de accounting: Ahora permitimos definir códigos de coste a las templates de la Biblioteca (eg Windows, Linux).  La herramienta de Billing puede saber que tipos de coste aplicar (Esto nos lo han requerido clientes que quieren desplegar linux y Windows, y dependiendo del OS facturar con un coste u otro)

• Mejoras en la GUI y en la gestión de errores: En cada versión veréis una tarea de estas. Básicamente, en nuestro modelo de mejora continua y gracias a vuestro feedback, vamos introduciendo mejoras de usabilidad y en los mensajes de error proporcionados.

• Mejoras con la integración con Vmware – vCenter (orphan VMs and IQN re-use): Esto también, pequeñas mejoras de integración con estas tecnologías.

• Orden de encendido básico y  retraso del encendido: Esto también es una pequeña  funcionalidad que se verá mejorada en futuras versiones. Básicamente permite ordenar el orden de despliegue a partir del nombre del nodo en la aplicación y permite definir un parámetro genérico para retrasar el encendido entre nodos de una aplicación

• Mejoras en la gestión del almacenamiento: Esto también es una pequeña funcionalidad que mejora la usabilidad en la parte de self-service storage y mensajes. Permitimos gestionar volúmenes todos y estar el nodo desplegado en el hypervisor.

• Billing URL: Esta funcionalidad permite apuntar a una URL de una herramienta de Billing, pasando el parámetro de empresa de la persona que lo ha requerido. Con esto, la herramienta parece mejor integrada en el producto.

!Y eso es todo!

Me encantaría destacar que el equipo ha hecho un muy buen trabajo en esta versión (que requería de una especial atención). En esta última versión hemos incorporado algunas mejoras en nuestro proceso de release (A nivel de proceso y de integración continua). Conectar tanta gente y en diferentes puestos (Development, QA, release y documentación). Es divertido ver como ahora hemos tenido que pensar e implementar una mejora para optimizar la fase de testing automatizado. Señal de que el volumen empieza a ser importante (Aunque cantidad no significa calidad).

Ya sabéis que si queréis podéis pedir una versión Enterprise para nuestros productos en la web de abiquo. Disfruten de ella.

Tema aparte es el networking. Aún nos toca mucho que aprender de países anglosajones. Como técnicos nos cuesta mucho entablar conversación con gente que no conocemos y nos recluimos en los contactos anteriores para conversar. No sé si está inventado (Espero feedback) pero creo que deberíamos instaurar la métrica (No encuentro el nombre sexy) que nos de la visión de cuantos eventos de networking necesita coincidir un ingeniero (Técnico, programador, y sus variables) con otro para empezar a entablar una conversación (Con contenido).
Y nada, lo dejo aquí, solo añadir que a modo práctico el evento me ha aportado otra visión de la analítica web y el marketing en redes sociales. Tema que pienso indagar y hablar de él en próximos post.
Cuanto bien hacen eventos como #TheEvnt en España. No los dejemos perder. Gracias a la organización por su entrega y dedicación para que el evento fuera todo un éxito.

- Business dice: Quiero para ayer estas nuevas 20 funcionalidades. Testeadas, documentadas y a poder ser que sean compatibles con todas plataformas tecnológicas con las que nos integramos. ¿Fácil no?

- El equipo tecnológico dice: Necesito el doble de tiempo que tu me das para hacer la mitad de funcionalidades que me pides. La verdad que para ir bien deberíamos introducir nuevos componentes tecnológicos para poder estar seguros que entregamos algo con la calidad que el proyecto requiere.

Y la verdad que todos tienen tanta razón como errores en sus afirmaciones. Veamos en perspectiva.

De siempre nos han dicho que el cliente tiene la razón, quizás sea cierto. Pero también es cierto que lo que distingue un buen equipo de negocio de uno mano es su habilidad para separar el grano de la paja, la capacidad para ver más allá de una venta y la destreza para conocer el negocio del cliente para poner peso a sus prioridades. En resumen:  El cliente tendrá la razón ponderada siempre que seas capaz de medirla. Y aquí me lanzo a dar unos humildes consejos:

• Aprende todo lo que puedas de tu cliente (Con o sin él).
• Ten preparado tu roadmap de cliente en función de tu visión del mercado…
• … pero debes estar capacitado a cambiarlo profundamente en función de tus clientes (No seas orgulloso).
• Aprende a ponderar. No es más importante la feature que te requiere el último cliente que has ido a visitar, sino el que REALMENTE te dará más negocio.
• Si no eres capaz de explicar QUÉ y PARA QUÉ quiere un cliente una funcionalidad (Con más de 2 líneas de definición) no es digna de que influya en tu producto (¿Como se lo vas a explicar al equipo técnico?). Primero aprende a escuchar y entender, muchas veces el propio producto puede ofrecer una alternativa sin necesidad de nuevos desarrollos.
• Conoce el ritmo de tu cliente. ¿Para qué quieres una funcionalidad A si el cliente tiene bloqueado el presupuesto hasta el próximo año?
• La frase ¨Muchos clientes lo piden¨ debería estar prohibida. Aprende a montar matrices cliente-funcionalidad para poder actuar en consecuencia. Muchas veces te sorprenderías.
• Un buen producto debe incorporar aquello que tu comunidad quiere (Clientes, partners, open source, etc.) pero sin perder la esencia de la visión de tu empresa (Ya sabéis… aquello de Henry Ford). A mí me gusta la proporción 7 a 3.
• ! El buen producto no es el que más funcionalidades tiene! Sino el que mejor se adapta a lo que realmente demanda el mercado. No peques de visionario.
• Quien define necesidades debe entender que un error en las expectatuvas impactará en el desarrollo y la calidad de la siguiente release.

Y luego eso se traslada al equipo técnico. Del cual me siento partícipe con sus virtudes y defectos. Cuando nos llega una lista de features siempre tendemos a ponernos las manos a la cabeza (¿A qué suena?), no entender los motivos ni preocuparnos en encontrarlos. El buen ingeniero es el que es capaz de salir del huevo en el que solemos vivir la gente con alto componente  tecnológico, entendiendo el gran valor que aportan a la compañía involucrándose en su desarrollo y aportando sus habilidades para la maduración del producto.

• No incorpores algo por el simple hecho de que parece que aportará más valor a la funcionalidad. Usa los canales estándares de definición, participa activamente con el Product Manager. No hay nada peor para Business que no saber explicar el comportamiento de una pantalla cuando está el producto instalado en un cliente.
• Pierde 1 día más de lo que tenías en la cabeza a definir una funcionalidad. Minimizarás por 10 los riesgos y serás capaz de apuntar más fino a la funcionalidad deseada.
• El equipo técnico también debe conocer el mercado y el tipo de cliente para el que desarrolla. Es responsabilidad del Product Manager transmitirlo y del ingeniero asimilarlo. A veces las cosas no son como uno piensa.
• Trabajar en la definición no es perder tiempo reunidos. Si no aportas nada levántate y vete a hacer otra cosa. Pero luego no pidas explicaciones sobre un diseño.
• Usa el poder de las metodologías ágiles. No escondas tus desarrollos. Crea, testea y comparte rápido.
• Entiende la funcionalidad que desarrollas. Porque es necesaria. Eso te ayudará a definir y focalizar.
• Prioriza en el diseño la arquitectura, librerías o herramientas que tienes definidas. Tampoco te salgas del estándar de desarrollo definido sin comunicarlo antes. Un ingeniero es curioso y atrevido por naturaleza. Eso hace a veces querer probar cosas nuevas. Encuentra el momento. Sistemas te lo agradecerá (Y el proceso de upgrade también )
• El valor del producto está en parámetros como robustez, escalabilidad y mantenimiento. Argumenta un nuevo desarrollo en base a estos parámetros, no en las tecnologías que usas.
• Normalmente las previsiones a más de 6 meses vista suelen fallar .
• Un ingeniero debe entender que una mala planificación impacta fuertemente en el ciclo de release y en las ventas. Que por suerte o desgracia son los dos puntos que mantienen viva una empresa.

En resumen, la diferenciación que permite a empresas como Abiquo competir con otras como VMware está en la agilidad, comunicación y compromiso con el proyecto. Un sector puede pensar que la clave de una empresa está en la facturación, otra en la excelencia y la innovación en el producto. Pero la realidad nos hace aprender que en medio se encuentra el buen camino.

PD: En este post hablo del mundo Business (Sales, Business development, etc) y Desarrollo ( I+D, desarrollo, etc.) como dos equipos diferenciados. Claro queda que es una separación ficticia. El éxito de cualquier empresa de producto radica en la mezcla de ambos.

En breve se lanzará la nota de prensa y esas cosas que gustan tanto, pero he querido adelantarme y comentar las major features que incorpora. Tanto a nivel técnico como funcional. Vamos allá!

Como nuevas funcionalidades:

• La perla de la versión es un completo sistema de WORKLOAD que permite afinar mediante un sistema de reglas el despliegue de máquinas virtuales en tu parque de nodos cloud: Define políticas de seguridad, modelos de sobresuscripción o balanceo de maquinas en modo carga máxima o primando la performance.
• Complementando este sistema hemos añadido funciones avanzadas de reserva. Posibilidad de restringir Datacenters a empresas, posibilidad de reservar máquinas a una empresa. Gestión de límites a 3 niveles (Empresa, Empresa/Datacenter y VirtualDataCenter), etc.
• En abiquo llevamos una actividad frenética en paises asiáticos como Japón. Es por ello que gracias a la colaboración con uno de nuestros partners la interfaz ya está preparada para mostrar caracteres japoneses. Y por si eso no fuera poco, permitimos escribir y trabajar con caracteres japos (Creerme… eso da para un post entero).
• A nivel de networking también viene con muchas novedades. Para resumir, ahora es mucho más facil adaptar tu política de VLANs a la plataforma (Vlan mínima y máxima permitida, descarte de tags vlans, reservas de redes públicas, etc.).
• Se han incorporado nuevas funcionalidades respecto a la convivencia con vCenter y otras tools de management de virtualización. Ahora abiquo se entera y actualiza sus datos cuando existe un movimiento de máquinas virtuales debido a sistemas como vMotion, DRS u otros sistemas de HA. Eso significa que nuestros clientes pueden seguir trabajando con vCenter (Si consideran que aún es necesario) e incorporar abiquo como plataforma cloud para ofrecer a sus usuarios finales las capacidades de una infrastructura como servicio.
• La API sigue ampliándose a marchas forzadas. Muchas más capacidades de la plataforma al alcance de servicios REST.
• Se han incorporado mejoras en usabilidad propuestas por algunos de nuestros principales clientes.
• Se me olvidaba! Ahora sera muy fácil poder ofrecer abiquo como marca blanca. Posibilidad de usar los themes predefinidos y de incorporar nuevos al sistema. Y lo más divertido… customizando a nivel de empresa, lo que permite un mejor acabado para resellers.
• Y un sin fin de improvements, bugs y pequeñas nuevas features que seguro que serán la delicia de aquellos que quieran probarlo.

Ejemplo de pantalla en japonés

A nivel tecnológico:

• En 1.6.8 ya asomó REDIS en nuestra arquitectura. En 1.7 hemos consolidado su uso y ampliado las habilidades en virtud de la escalabilidad del producto.
• RabbitMQ como gestor de colas también se ha incorporado a la arquitectura. Espero que Enric cuente tanto la experiencia con Redis y con Rabbit en los últimos meses.
• El nuevo instalador merece un caso aparte! Una ISO basada en Centos 5.6 que permite instalar (O upgradear desde la versión anterior) con pocos clicks de ratón y con herramientas para checkeo y gestión de propiedades. Instalar abiquo nunca fue tan fácil.
• El sistema de propiedades se ha mejorado substancialmente. Muerte al XML, larga vida a los ficheros de propiedades de toda la vida.

Pantalla proceso instalación

Y alguna cosa más que seguro que me dejaré! Pero con este post seguro que muestro el espíritu de la versión .

Por último como siempre, dar las gracias públicamente al equipo de abiquo involucrado en el proyecto (Desarrolladores, QA, sistemas, soporte, etc.). Están haciendo un trabajo magnífico!!!

• Primero voy a destacar un blog en General, el de Pensamientos Ágiles de Martin Pérez. Y 2 entradas que me han encantado: Consejos para crear aplicaciones de alto rendimiento y consejos para gestionar 100K TPS con menos de 1ms de latencia.
• Rackspace se viene a Europa. Otra vez van a venir de fuera para enseñarnos como se gana dinero… Hay muchos en el viejo continente que están perdiendo el tren y el pastel.
• Nuestros amigos de Amazon la vuelven a liar incluyendo Cloud Watch a la consola de gestión. Y hace poco anunciaban algo mejor: Elastic Beanstalk. Parece que se han subido al modelo de anunciar nuevas features en cortos espacios de tiempo. Y yo me pregunto… ¿llegará alguien a debatirles el liderazgo en innovación y mercado de los cloud públicos?
• Por último, más verdades contadas por Diego Mariño, reflexionando sobre las realidades del estado de la inversión en proyectos iniciales en España comparando con lo que hacen en otros lugares. Personalmente tengo la esperanza que los primeros cash-outs que empiezan a producirse estos años ayuda a iniciar un nuevo ciclo de inversión (¿en 1-2 años?).

Aquí lo dejo por esta semana, creo que dejo suficiente material .

Quiero compartir con vosotros dos experiencias que estoy teniendo al respecto de este tema. La verdad que en muchos casos lo contado no es requerido en abiquo pero quise profundizar en el tema para no quedarme atrás en tecnologías (O una excusa más para frikear).

Creo que el mundo de la consultoría tecnológica te enseña (Entre otras cosas) que aunque a veces sea una lástima, el valor tecnológico de la solución está muy por debajo a la solución funcional que aporta. He hecho tanto truños en la que nos han felicitado como auténtica cirugía fina que se guardó en el cajón simplemente porque los usuarios han dudado de lo que la aplicación les ayudaba.

Es por ello que creo (En contra de lo que piensan otros) que herramientas que ayudan a focalizar e introducir metodologías ágiles en el desarrollo son siempre bienvenidas. Desde un simple eclipse plagado de plugins hasta los 2 proyectos que os presento a continuación, que te permiten en base a scripts montar el esqueleto de tu producto y poder ver rápidamente los primeros resultados. Aquí les presento:

• Play: Me lo presento Albert Puig (de los viejos de abiquo) y realmente es un proyecto que te permite tener cosas presentables en un abrir y cerrar de ojos. Basado en el stack de Java permite crear arquitecturas RESTfull sin tener gran conocimiento al respecto. Una documentación decente y varios tutoriales permiten introducirte rápidamente con el modelo de trabajo. Me gusta su modelo hot deploy para desarrollo rápido y como se basa en estándares Java (JSP, JPA, etc.), teniendo incluidas las herramientas que permiten un desarrollo TDD. Lo que no me acaba de convencer es la gestión de los flujos de navegación, creo que para proyectos grandes puede dificultar su mantenimiento.

• Spring ROO: El nuevo juguete que nos presentaron los señores de Spring Source y creo que no hace falta contar que es una tool parecida a Play pero basada en stack Java del Framework Spring. Quizás no es tan sencillo como Play pero realmente te permite montar aplicaciones fácilmente con Spring. La documentación está en constante mejora (Desde la primera vez que la vi) y aún quedan muchos puntos de usabilidad (Como que mientras vas creando las entidades de mapeo de la BBDD si te equivocas no puedes volver atrás, debes editarlo a mano en Eclipse). Pero sus capacidades de integración con terceras tecnologías son realmente prometedores (Aunque aún hay quejas). Así que este también tocará estudiarlo en profundidad. Albert muy amablemente me envió un post en el que lo ponen de vuelta y media (Pero por suerte desarrollan rápido y bien, así que las nuevas versiones intentan solucionar ese gap)

Y nada, ahora estoy en fase exploración, lectura de documentación y jugar con el terminal y eclipse. Espero contaros más al respecto. ¿Alguien los ha probado? ¿En producción? ¿Algo a comentar?
AVISO PARA NAVEGANTES (o ingenieros): El uso de estas tools no debe eximir del conocimiento en profundidad de las tecnologías que se usan. Sin ese conocimiento profundo no se puede sacar el máximo partido a tu aplicación (En parámetros como escalabilidad, robustez, performance, etc.). Haz que estas herramientas mejoren tu día a día o tu velocidad de respuesta ante un cliente pero que nunca nublen tu afán de conocimiento.

Hoy algo más corto y más humano. Y que espero que sea útil para mucho gente (Diego tuvo que sufrirlo hace 3 meses).

He estado durante 2 meses (a ratos muertos) intentando trabajar con SCROLL WIKI EXPORTER para poder exportar la documentación y que quedara bonito para nuestros clientes y miembros de la comunidad. Pero la verdad, entre que tenías que hacer la template con DocBook y luego agregarlo como nuevo plugin en Confluence, pfff, una mierda rollo vamos. Y más cuando tengo cosas más importantes que hacer. Eso no quiere decir que las herramientas de k15t sean malas (ni mucho menos). Pero se iba del objetivo requerido por abiquo.

El scope era claro. Debíamos lograr que Marketing y soporte no tuvieran que hacer transcripción de la wiki para generar un nuevo documento adaptado a las necesidades del cliente. Y eso quiere decir tanto en contenido (Que obviamente el error es que no esté cubierto directamente en la wiki) como a nivel formato (Que eso aunque no lo parezca… es importante). Para el primero ya estamos dándole remedio, poco a poco estamos pasando a ser Confluence Centric. Y sobre el segundo aquí va mi aportación:

• Confluence tiene una funcionalidad que permite exportar las paginas deseadas de un SPACE. Estando logado: BROWSE > ADVANCED >PDF EXPORT. Allí solo tenemos que indicar que páginas queremos exportar. Creo que lo mejor es tener una organización que te permita fácilmente hacer documentos. En Abiquo: User Guide, Administration Guide y API. Luego tenemos varios HOW TO’s

• Y luego la parte que hasta hace poco estaba oscura… como editar el template de exportación. Para ello siempre teníamos las opciones de PDF LAYOUT (Definir la página de portada, el Header y el footer) y PDF STYLESHEET (Definir los estilos de página, los títulos, la letra, etc.). Pero faltaba la documentación, estaba incompleta y tenías que buscarte la vida en foros (Diego da fe de ello).  Ahora la documentación está bastante mejor explicada aquí y aquí. Y encima te dan el CSS que usa confluence para formatear la exportación. Cosa que te facilita la vida y puedes externalizar el trabajo a tu diseñador favorito (En estos momentos uno echa de menos a Diego )

Así que nada, aquí va mi aportación a los fans de los productos de atlassian.

PD: Espero que este post también ayude a algunos lectores que ya me reclamaban cambios en la documentación de abiquo

Con miedo a sonar pedante, si nos ceñimos a lo que dice la RAE encontramos que talento es:

(Del lat. talentum, y este del gr. τάλαντον, plato de la balanza, peso).

1. m. inteligencia (‖ capacidad de entender).

2. m. aptitud (‖ capacidad para el desempeño o ejercicio de una ocupación).

3. m. Persona inteligente o apta para determinada ocupación.

4. m. Moneda de cuenta de los griegos y de los romanos.

Y creo que nos quedamos con la tercera definición. En ya casi 5 años (¡ Cinco !) de abiquo han pasado todo tipo de personas. Considero que todas personas inteligentes, estoy seguro que todas aptas para ganarse bién la vida en el mundo de la ingeniería. Pero no todas se han adaptado al modelo abiquo. Que sin entrar a valorar si es bueno o malo, es el que es.

La verdad que nuestras pruebas de acceso son de lo más normales. Gracias a Enric y Albert que le ponen un poquito de profesionalidad al tema con sus pruebas técnicas (Simplemente hechas para hablar de algo con el candidato). Por defecto o virtud suelo moverme mucho por instintos y si me gusta lo que veo o lo que escucho me cuesta mucho decir a alguien que no entre a probar en abiquo (¿Porque el gobierno no aprueba una ley en la que los 3 primeros meses son subvencionados? Bién estructurado tendría hasta sentido). El feeling aquel que Guardiola puso tanto de moda . Lo siento pero nunca creí en grandes procesos de selección. Conozco verdaderos especialistas en pasarlos y ya he perdido la esperanza de encontrar a una persona con más de 5 años de experiencia en tecnologías de datacenters (virtualización, storage, networking) a nivel integración, con conocimientos en tecnologías de desarrollo, entornos escalables y distribuidos y lleve más de 2 años siendo usuario de Amazon AWS u otra tecnología cloud (Mensaje subliminal para posibles candidatos )

El talento no es único. Hay de miles de colores y quien sirve en un sitio puede no encajar en otro. Me acuerdo que en everis se daba mucha importancia a la habilidad resolutiva, analítica y de inmersión en clientes. En abiquo creo que las aptitudes son otras:

• Disfrute por la tecnología. Aquí no tenemos largas carreras profesionales con sus categorías y sus objetivos anuales definidos para ser de una u otra. Disfruta de la tecnología, disfruta creando y si te adaptas a nosotros encontraras tu carrera tecnológica. Cuando la persona está dentro en menos de 6 meses ya sabrás si acabará llevándote equipos, ayudándote con las implantaciones, echándote una mano con un cliente o lo que haga falta. Para este punto solemos pedir a la gente un trozo de código del que se sienta orgulloso. Eso dice mucho de uno. Creo que los mayores fracasos han sido buscando gente específica para un puesto determinado, modestamente creo que no suele funcionar.
• Be ingeniero. Pasión por afrontar retos, proponer soluciones y llevarlas a cabo. La verdad que por nuestro carácter de pez pequeño en gran océano debemos buscar gente autónoma (que no autista). Gente que sepas que a la que conozca la arquitectura del producto va a poder afrontar los nuevos desarrollos sin miedo al fracaso. No existen manuales de como programar plataformas distribuidas de software de sistemas (si pautas básicas). En abiquo deben haber piezas que hemos cambiado 10 veces hasta encontrar la forma en que todos pudiéramos dormir tranquilos por las noches.

• Responsabilidad. El de 9 a 18 no existe. Aquí solo hay historias a completar (terminologías scrum), plazos de entrega, clientes a contentar y perfección que buscar. Si las 4 premisas no se cumplen simplemente abiquo cierra. La responsabilidad recae en cada uno y el que no sepa afrontarla no sirve. En el desarrollo de abiquo es tan importante el más experto del equipo como el becario. A todos se les asigna su grado de responsabilidad y sin su pieza el puzle no se completa.
• Se persona. Aquí somos pocos, buena gente y con ganas de hacer cosas. Aprende a socializarte por el bien del proyecto.
• Quéjate. Todo y que eso a veces acabe con mi paciencia prefiero a alguien crítico con lo que se hace mal en la compañía. Alguien que se queja porque en un punto se han encontrado muchos errores o el documento entregado a un cliente es deficiente suele ser una persona que busca la calidad en su propio trabajo (Suele).
• Aporta. Todo el mundo tiene algo que aportar fuera de la propia plataforma. Unos hacen distribuciones de linux que luego ayudan a distribuir el producto, otros juegan con python o jruby para crear clientes para la API. Otros juegan con jquery para crear tools para facilitarnos la vida y otros hacen sistemas de rimas por twitter con tecnologías que luego aplican al producto.
• Adaptación. Si una cosa hemos hecho en abiquo… es cambiar: de tipo de producto, de metodología de trabajo, de oficinas… de todo! Si una persona no es capaz de aceptar el cambio… no sirve para abiquo.

Y nada, para mí eso es mi versión del talento. Luego existirán los líderes, los currantes natos o los geniales… pero el equipo pone a cada uno en su sitio en su debido momento.

De vez en cuando si veo algunos realmente interesantes de verdad (Independientemente de su naturaleza) los agruparé en un post como este y daré mi comentario en unas breves 10-15 palabras. Seré capaz?

Estos son algunos de las entradas interesantes que os dejo:

• How to write code that scales. Interesante. Aunque no es ningún ABC de la escalabilidad de aplicaciones ayuda a reflexionar de lo que uno piensa al respecto.
• Estas reflexiones sobre cloud y su continuación. Mucha información junta pero con interesantes reflexiones sobre la evolución del cloud. Algunas de ellas hace tiempo que comparto como el cierto desacople entre profesionales del hosting y los que desarrollamos soluciones de cloud. En abiquo siempre intentamos reducir este gap.
• La nota de humor. Mucha gente en el mundo de la tecnología ha twitteado o blogueado sobre Dilbert.
• Cambiando de tema, quiero compartir con vosotros este blog de un amigo mío de la infancia.  Lástima que esté en catalán. Pero pocas veces me he enganchado a un blog no tecnológico. En el explica con todo lujo de detalles sus 2 años de viaje por toda Asia. Impresionante. Solo con las fotos ya vale la pena entrar.
• Como siempre Diego un mar de sabiduría  . De sus últimos post me quedo con este. Una verdad como un templo.

Y nada, lo dejo aquí. No vayamos a estropearlo .

Esta es una de las preguntas más repetidas que me han hecho en eventos o algunos conocidos. Y es algo que sin haber preparado… respondo de carrerilla.

Primero de todo veamos las cosas con perspectiva: Sillicon Valley. Si queréis saber más sobre él os propongo que naveguéis un poco por la red, hay mucha literatura al respecto. Mi resumen es claro… una amplia zona al sud de la bahía de San Francisco que hace muchos años apostaron claramente por la tecnología y todo lo que le envuelve y que han convertido a la zona en el punto con mayor concentración de empresas tecnológicas (Con diferencia) que jamás nadie ha visto. No es el objetivo de este post, pero si rascáis un poco en su historia veréis que no es algo que salió por generación espontánea o montando un parque tecnológico subvencionado sino que es fruto del trabajo de muchos años y de tener claro un modelo de cómo hacer las cosas. En mi opinión es como una especie de meca tecnológica que todo ingeniero debería visitar.

La idea de ir al Valle ya era pretendida años atrás por Diego y por mí. Teníamos claro que teníamos que estar. Teníamos también claro que hace 2 años no nos lo podíamos permitir pero también nos pusimos en el punto de mira el poder conseguirlo. Solo como resumen… en abogados, alquiler y otros menesteres no teníamos suficientes riñones que vender Diego y yo para poder hacer frente a esos costes astronómicos. Pero eso no freno a mi socio para pasarse unos meses allí para ver qué pasaba. Sin despacho, sin teléfono americano. Solo ganas de patear, mostrar abiquo al mundo y una americana

En aquella época todo eran teorías de porque ir al Valle. Nos habíamos paseado varias veces y hablado con mucha gente. Es ahora cuando estás allí que ves que fue un acierto a medias. Con un ejemplo todo se ve más claro:

Finales de 2009. Todo y no tener publicada la versión 1.0, ésta ya la teníamos cerrada (Por temas de Marqueting esperamos a su publicación oficial). Unos meses antes Diego había estado en la zona y había conocido y hablado con mucha gente de allí. Una vez en España empezamos a recontactar con aquella gente y todo aquel simpático que nos recibía con una sonrisa y buenas palabras no se dignaba a coger el teléfono o a contestar los mails. Realmente desalentador.

Dos meses después, el mismo producto pero una oficina en el valle. La misma persona que contacta pero  con número de teléfono del valle y  zaaas! Todos contestan al teléfono, todos preparan una reunión formal para conocer el producto y con muchos de ellos a día de hoy seguimos trabajando. Me gustaría hablar de nombres, pero no puedo. Pero os puedo asegurar que muchos de ellos son inmensas multinacionales que no les debería de importar trabajar con empresas de fuera de EUA. Yo he llegado a la conclusión que es tema de mentalidad, como diría Guardiola es cuestión de feeling. He creído entender que por el hecho de estar allí se te supone una forma de hacer las cosas, como un sello de identidad.

Mucho a mi pesar… es así. Y todo y que muchas veces no haya querido reconocerlo… simplemente el juego funciona así. Estás en el valle luego existes. No importa que el 100% de tu desarrollo se haga desde Barcelona. Si desarrollas el negocio desde el Valle… todo se ve diferente. De cara a EUA y de cara al mundo.

Si soy persona válida para ofrecer consejos el único que puedo atreverme a decir es que si tu empresa se plantea estar allí que no lo haga a medias.  Haz números, averigua el precio de las cosas, define un plan, dedícale dinero y disfruta de la experiencia. Seguro que cometerás errores, pero para eso están los que no arriesgan, para recordártelo :)

Conozco otras empresas españolas que han cogido las maletas y se han ido para allí y me gustaría saber sus experiencias. A ver si el boca a boca consigue llegar a alguien que pueda comentar su visión del tema.