Este artículo es la segunda parte de la entrevista que me concedió Diego Mariño a propósito de la ronda de financiación de 560.000€ que consiguió Ducksboard, la startup de la que es CEO y accionista.

Mientras que la primera parte se centró en los aspectos más económicos del día a día de una compañía tecnológica, en esta ocasión, hablaremos de la parte más técnica de la misma.

[box type="note" icon="none" style="rounded"]ATENCIÓN

Los CEOs “de salón” y los orgullosos poseedores de un MBA por la Universidad de Wichita o Canford pueden sufrir un síncope vasovagal al leer este artículo[/box]

Diego, Ducksboard es el primer proyecto de la era DA -después de Abiquo- ¿Cómo se te ocurrió pasar de algo tan serio y corporativo como el cloud al trendy y bohemio mundo de los dashboards?

La idea original me la venía planteando ya desde la época de Abiquo. Vi la necesidad cuando empezamos a crecer y empecé a tener cada vez menos información de mi propia empresa. Pensé que no debía ser tan complicado eso de ir llamando a diferentes SaaS para traer datos y poder compartirlos con el equipo en una pantalla.

[quote]Vi la necesidad cuando empezamos a crecer y empecé a tener cada vez menos información de mi propia empresa.[/quote]

Unos meses después de dejar el día a día de Abiquo, nos encontramos en Madrid mi mediohermano Aitor, su colega Jan y yo, con muchas ganas de hacer algo juntos y un hervidero de ideas en la cabeza. Retomé la idea de los dashboards y, finalmente, nos lanzamos, por la capacidad técnica del equipo -lo podíamos afrontar sin ayuda externa- y por la probabilidad de exit. Veíamos clara la posibilidad de venta de la empresa.

El equipo técnico de Ducksboard

Aitor disfruta de su habitual siesta de 3 horas mientras Jan sigue preguntándose porque tiene un teclado delante del portátil

¿Cómo engañaste al equipo técnico?

Con respecto a los fundadores, fue relativamente sencillo. Aitor y yo habíamos trabajado juntos hacía muchos años y teníamos clavada la espinita de montar un proyecto propio, y Jan sólo tuvo que rechazar una MEGAOFERTA económica para seguir desarrollando sus proyectos Open Source de forma sponsorizada.

Para el resto de contrataciones, nos hemos traído a gente con la que ya habíamos trabajado anteriormente. La siguiente incorporación será la primera que hagamos fuera de nuestro círculo más inmediato.

¿Por qué lenguaje de programación y plataforma tecnológica optasteis?

Pues optamos por programar tanto Java y  XML como nos fuese humanamente posible mantener…

Diego, a ver si vas cambiando de broma que esa es muy “de los 90″. Actualmente, casi todo en Java se puede configurar con anotaciones en el propio código…

(risas) Vale, ahora en serio, la “lingua franca” de Ducksboard es Python. Tanto nuestro backend, que se encarga de la recopilación y almacenamiento de datos, como nuestro frontend, la aplicación web expuesta a los usuarios, están escritos en Python.

El backend está escrito usando Twisted, un framework para el desarrollo de aplicaciones de red para Python. Gran parte del trabajo del backend es gestionar miles de conexiones concurrentes a cantidad de servicios web y nuestra prioridad era poder escribir esa parte de la aplicación usando código asíncrono. Twisted cubre esa necesidad proponiendo un modelo de programación basado en eventos.

Para la aplicación web estamos usando algo mucho más “mainstream“: Django, un framework MVC en Python muy conocido.

La elección de Python se debe a la experiencia previa con el lenguaje de los dos fundadores técnicos. Nos parece un lenguaje muy expresivo y mantenible.

¿Qué requisitos teníais a la hora de diseñar la arquitectura?

Teníamos muy claro que backend y frontend debían estar totalmente separados. Son aplicaciones independientes, el único punto en común es la base de datos: el backend escribe en ella, el frontend lee de ella.

[quote]Teníamos muy claro que backend y frontend debían estar totalmente separados. Son aplicaciones independientes.[/quote]

Usamos PostgreSQL. Queremos una base de datos relacional porque nuestro datos son, claro está, relacionales, y su consistencia juega un rol crítico en nuestro servicio. PostreSQL ^_^ PostgreSQL en concreto porque Jan es colaborador del proyecto, y nuestras experiencias previas con MySQL no fueron demasiado buenas.

Eso me recuerda a la anécdota de los figuras de Mint, que tuvieron que contratar a un Administrador de Base de Datos antes de una demo importante porque su MySQL no “iba bien”, sólo para descubrir que la habían instalado limitándola al uso de 64MB de memoria… ¿Y encima de vuestra capa de datos que podemos encontrar?

La aplicación como tal tiene tres características principales:

  1. Arquitectura “shared nothing” para poder escalar horizontalmente sin volvernos locos. Los distintos componentes del backend corren como procesos independientes en máquinas separadas. La comunicación entre los mismos se lleva a cabo vía HTTP y los componentes de un mismo tipo se balancean con un Nginx. Al no haber un estado compartido, podemos escalar la aplicación horizontalmente añandiendo instancias tras el balanceador.
  2. Frontend en tiempo real, queda muy chulo, y los datos nunca esperan (risas). Somos de las primeras aplicaciones comerciales en hacer uso intensivo de Web Sockets. El frontend web recibe notificaciones cuando hay datos nuevos sin tener que hacer requests constantes. Usamos RabbitMQ para que los componentes de backend puedan dejar mensajes pendientes de enviar al frontend en un lugar común.
  3. Somos los principales usuarios de nuestra APIs. Usamos las mismas APIs para construir la aplicación que ofrecemos posteriormente a los usuarios. Tanto para empujar datos al backend, como para gestionar tu configuración en el frontend. El frontend, de hecho, es una API JSON en sí mismo, y usamos backbone.js para interactuar con esa API y dibujar los widgets y demás en el navegador del usuario.

Si estás interesado en conocer más sobre la arquitectura y tecnología de Ducksboard, puedes echarle un vistazo a estos slides.

¡66 diapositivas! Una presentación digna de Mordor. Yo suelo pedirle a Jero que me explique todas las decisiones técnicas y aportar todo lo que puedo. ¿Hasta qué punto te involucras tú? ¿Crees que un CEO debe saber lo que está haciendo su equipo técnico?

Para empresas tecnológicas, sin duda alguna. Has de saber lo suficiente como para poder discutir todas las decisiones, pero recordando que la última palabra la tienen ellos.

Como tú comentas, realmente lo que hago es preguntar “¿Por qué?” a menudo e ir comprobando que las decisiones técnicas no limitan las posibilidades de negocio en el largo plazo.

¡Oh! Yo sólo lo hago por irritar a Jero (risas) ¿Y qué herramientas habéis utilizado durante el desarrollo?

Muchas. Te hago una lista:

Vamos, startup de manual…

No tan “de manual” ya sabes que lo trendy es utilizar las herramientas de 37signals (risas).

Me sorprende que utilicéis GitHub en vez de Bitbucket, que también te proporciona repositorios de Git, sobre todo con lo popular que es en la Comunidad de Python… lo de que no hayáis sido capaces de haceros con JIRA, sabes que no te lo perdono. Un día voy a pasar por el Patoplex con el látigo listo para atizar a Jan y Aitor… pero en cualquier caso, no puedo quejarme: debéis ser una de las pocas compañías españolas que pagan licencias…

[typography font="IM Fell DW Pica" size="24" size_format="px"]To be continued?[/typography]

 

Ya hemos hablado de la parte financiera y hoy hemos hablado de tecnología, pero aún me queda material para una tercera parte en la que hablar de negocio puro y duro (coste de adquisición de usuarios, canales de venta y demás…) En el anterior artículo, pedimos 20 comentarios para escribir la segunda parte y ¡superamos los 60! Con este va a ser difícil llegar a ese número, porque un contenido tan técnico habrá espantado a mucho emprendedor de Excel y Powerpoint. En cualquier caso, hay que subir un poco el nivel: [highlight]si llegamos a los 40 comentarios, tendréis la tercera y definitiva entrega[/highlight] del Mariño versus Bonilla…

Disclaimer anti-bocachanclas

Soy el orgulloso embajador español de Atlassian, la compañía desarrolladora de JIRA, el mejor gestor de proyectos del mundo mundial de la vida vital. Una herramienta TAN potente (algunos confunden potencia con complejidad) que ni siquiera los cracks técnicos de Ducksboard han podido controlar su poder desatado… ^_^

Bitbucket -mucho “más mejor” y más sexy que GitHub- también es de Atlassian. Que, por cierto, hace poco, también compro HipChat.

57 comments

  1. Reinaldo Aguilera 13 abril, 2012 at 10:32 am

    Reply

    Esto es como el padrino. La segunda parte es mejor que la primera.
    Esto es lo que buscan muchas personas y no se cuenta, Felicidades y quedo pendiente de la 3ra parte

  2. David Pardo 13 abril, 2012 at 10:35 am

    Reply

    Brillante. y además, me acabo de suscribir a la bonilista de correo. Más, quiero más!

    • David Bonilla 13 abril, 2012 at 11:35 am

      Reply

      ¿Llegaremos a los 666 inscritos antes del domingo, necesarios para lanzar ‘La Bonilista de la Bestia‘? No lo creo… :P

  3. Juanluis 13 abril, 2012 at 10:37 am

    Reply

    Yo quiero que Diego cuente para que sirve el espejo ese tan fashion que hay en la foto? 
    Para hacerse la manicura? ;)

    • Diego Mariño 13 abril, 2012 at 11:43 am

      Reply

      Es de mi mujer… nos pasamos el 1er año en mi casa, y tomamos su vestidor al asalto para poner ahí unas mesas de trabajo :)

  4. Omar Garrido 13 abril, 2012 at 10:41 am

    Reply

    Genial la explicación ^^. Estoy deseando como se desarrolla la batalla entre Mariño y Bonilla :P. 

    “El duelo de bastones está apunto de comenzar :P”

  5. Ivan Guardado 13 abril, 2012 at 10:47 am

    Reply

    Ducksboard rocks!!

  6. Jorge Uriarte 13 abril, 2012 at 10:48 am

    Reply

     Bah, David, nos escamoteas contenido, pareces un guionista de lost. Queremos todooooo, de un trago largoooo, sin pausas para la publicidad! Ansioso me quedo!

    • David Bonilla 13 abril, 2012 at 11:31 am

      Reply

      Oye, que vamos a más de 1300 palabras por artículo. Si los hago más largos, bajamos la productividad del país… :)

      • Sebasj 13 abril, 2012 at 4:36 pm

        Reply

        Si nos leemos los articulos de jotdown 1300 palabras no es nada.
        Nos gustan los detalles y si lps hacen amenos mas. Muy buen artículo, corto pero bueno ;)

  7. Rafa Roda 13 abril, 2012 at 10:56 am

    Reply

    ¡Mil gracias a Diego por aportar el contenido y a David por redactarlo de forma tan amena! Excelentes primera y segunda parte, me uno a la petición de la tercera y la cuarta, si es necesario ;-)

    • David Bonilla 13 abril, 2012 at 11:32 am

      Reply

      Menos mal que alguien se da cuenta de mi aportación. Las palabras originales de @diegomarino:twitter  son una mezcla de Klingon, Euskera y gruñidos de Chewbacca. Soy YO el que las convierte en algo inteligible… ^_^

      • Aitor Guevara 13 abril, 2012 at 12:16 pm

        Reply

        Oiga, caballero, un respeto. La explicación técnica del asunto es obra de un servidor y su inteligibilidad es incontestable.

        Exijo una satisfacción! Escoja arma, hora y lugar :)

        • David Bonilla 13 abril, 2012 at 12:21 pm

          Reply

          Esto sólo hay una manera de solucionarlo:
          http://www.youtube.com/watch?v=ooEFVUCirXM

          DUELO DE BAILES en el Patoplex. Si tu ganas, yo tendré que escribir un review de Assembla, pero… SI YO GANO, tu te tendrás que tragar un día de formación, mano a mano conmigo, sobre las bondades de JIRA.

          ¿Hay deal? Como dice mi suegro Benito, el dinero y los coj#### están para las ocasiones…

          • Aitor Guevara 13 abril, 2012 at 12:25 pm

            Acepto el reto. Vas a ver lo que es un moonwalk on the rocks y by the way.

          • Rafa Roda 15 abril, 2012 at 12:50 pm

            No se enojen, señores… aunque si hay duelo de bailes se agradecerá el vídeo ;) PD: Don David, cuídese :)

  8. Invitado 13 abril, 2012 at 10:59 am

    Reply

    Venga ahí va el primer comentario, con pregunta.

    ¿Que tipo de empresas se espera que se interesen por Ducksboard y que rentabilidad obtienen de la herramienta?

    • Invitado 13 abril, 2012 at 9:13 pm

      Reply

      ¿No procede responder esta pregunta? :(

    • Aitor Guevara 13 abril, 2012 at 11:03 pm

      Reply

      Apuntamos a PYMEs que hacen uso de otros SaaS para su gestión (CRMs, analítica web, herramientas de soporte, …).

      El uso de Ducksboard aporta al negocio los mismos beneficios que otras herramientas de monitorización aportan a los departamentos técnicos: control del estado de la empresa, con el fin de mejorar la toma de decisiones. A medida que añadamos más carga analítica esperarmos fortalecer nuestra aportación a esa toma de decisión basada en datos.

      • Manuel 14 abril, 2012 at 2:06 am

        Reply

        ¿ Y cual es el target de PYMES que estáis considerando (empleados, facturación, tipo de negocio) si puede saberse?.

        (Perdón si pregunto demasiado)

        Por que, ahora mismo con las funcionalidades que ofrece Ducksboard, veo difícil justificar ese pago mensual.

        Lo digo por propia experiencia. Trabajaba en una pyme dedicada al mundo de Internet (que se supone es un lead por definición para Ducksboard) y me fue imposible encontrar argumentos para convencer al gerente de contratar Ducksboard. Mucho menos cuando las pymes de este país están empezando ahora a mal-usar redes sociales. Y no les hables de mail marketing, crm’s, u otras herramientas SaaS que eso es chino.

        • Aitor Guevara 14 abril, 2012 at 12:47 pm

          Reply

          Lo cierto es que actualmente la mayoría de nuestros usuarios están ubicados en EEUU. El uso de SaaS allí está mucho más extendido, y por tanto la utilidad de Ducksboard es más evidente.

          En España, como bien indicas, la transición hacia una empresa más “SaaS-céntrica” se está dando ahora. Cuando esa realidad sea más palpable supongo que te será más fácil convencer a tu gerente de contratar servicios de ese tipo :)

          Actualmente muchos de nuestros usuarios son departamentos de soporte o técnicos. En parte porque son quienes más rápidamente entienden la utilidad del producto. El enfoque a departamentos menos técnicos va a verse acompañado de una campaña de publicidad mucho más específica y una explicación del producto mejor orientada.

          • Invitado 14 abril, 2012 at 4:01 pm

            Ah claro en EEUU. Así si. Gracias por las respuestas.

  9. Alberto Sanz 13 abril, 2012 at 11:57 am

    Reply

    es un gustazo leer sobre una ronda de financiación sin acabar con la sensación de que el dinero cae del cielo, el dinero viene, si hay talento, esfuerzo y compromiso!

  10. Jjbachiller 13 abril, 2012 at 12:08 pm

    Reply

    Quiero tercera entrega!!

  11. Carlos Melero 13 abril, 2012 at 12:50 pm

    Reply

    Muy buen artículo, felicidades. Espero el siguiente.

  12. Oscar Calvo 13 abril, 2012 at 1:11 pm

    Reply

    Qué grande esta serie.

  13. Aitor Guevara 13 abril, 2012 at 1:12 pm

    Reply

    Por cierto, la presentación no son 66 slides. El problema es que soy un nefasto powerpointero, y para ir hacer apareciendo bullets de las listas uno por uno, hice una slide separada cada vez xD.

    Así que en realidad el número de slides se queda en poco más de 20. Prometo afinar mis artes keynoteras para futuras ocasiones :)

    • David Bonilla 13 abril, 2012 at 1:29 pm

      Reply

      Pero esto no lo confieses NUNCA en público Aitor ¡Tu gurú level puede caer peligrosamente! :)

      PRO TIP: A la hora de exportar de Keynote a PDF, desmarca la opción “exportar cada fase de las dispositivas”.
      PRO TIP2: Los bullet points son muy de los 90… :P

      • Diego Mariño 13 abril, 2012 at 1:59 pm

        Reply

        No lo has entendido… no ha sido al exportar… realmente copia y pega cajas de texto en todas las diapositivas para hacer creer al respetable que van apareciendo bulletpoints.

        O eso hacía con herramientas libres. Ahora con Keynote mete efectos to reshulones :)

        • David Bonilla 13 abril, 2012 at 2:50 pm

          Reply

          O_o No sé que decir… me has dejado con el culo torcido :O

          • Aitor Guevara 13 abril, 2012 at 4:55 pm

            Bah, el pagüerpoin es lo de menos, en las presentaciones lo que cuentan son los chistes.

  14. Jose Luis Mondelo 13 abril, 2012 at 1:15 pm

    Reply

    Muy interesante!! Aunque estaría mejor si se pudiese conocer algún dato de la infraestructura con la que cuentan y la carga que soportan actualmente.

    Por supuesto  quedamos a la espera de la tercera entrega…

    • David Bonilla 13 abril, 2012 at 1:26 pm

      Reply

      La verdad es que eso es lo más inteligente que te he oído en eones. Ya podía @aitorciki:twitter estirarse y decirnos que es lo que tiene contratado en Linode, que carga de usuarios le aguanta y por cuanto pastizal sale al mes…

      • Aitor Guevara 13 abril, 2012 at 1:31 pm

        Reply

        Si hay tercera entrega seguro que hay sitio para colar esos numerillos :)

  15. Iván López 13 abril, 2012 at 1:20 pm

    Reply

    Me han encantado los dos artículos. A por el tercero!!

  16. Jacobo C. 13 abril, 2012 at 1:38 pm

    Reply

    Me uno a la petición de la tercera entrega.

  17. Oscar Ray 13 abril, 2012 at 2:41 pm

    Reply

    Lo primero enhorabuena a los chicos de Ducksboard por la merecida ronda de financiación y a tí también David, por lo cachonda a la par que interesante entrevista.

    Es un gustazo que se comparta tal cantidad de información técnica sobre el desarrollo y puesta en marcha de un proyecto por parte de sus creadores. Muchas gracias por haber espantado a unos cuantos emprendedores de Excel y Powerpoint con tanto contenido técnico, ja, ja…

    Por supuesto que queremos tercera parte, pero estoy con Jorge en que te gusta hacerte de rogar un poco :P

    Por cierto, todos sabemos que eres un cashondo mental, pero lo de PostreSQL no creo que haya sido a propósito, ¿no? o ¿sí? …ya me haces dudar XD

    • David Bonilla 13 abril, 2012 at 2:49 pm

      Reply

      Ha sido un GAZAPAZO de marca mayor ^_^ Lo he corregido, pero dejando el error porque me ha parecido MUY gracioso. Hehehehe :)

      • Oscar Ray 13 abril, 2012 at 3:21 pm

        Reply

         La verdad es que es para dejarlo corregido, te había quedado que ni a posta XD

  18. Luis Martín 13 abril, 2012 at 3:42 pm

    Reply

    Muy bueno. Me sumo a la suma. 

  19. Trollaco 13 abril, 2012 at 3:57 pm

    Reply

    Back y front usan la base de datos como mecanismo de comunicación. Eso más que MVC me suena a M-WC…

    PD: los trolls también cuentan?

    • Aitor Guevara 13 abril, 2012 at 5:05 pm

      Reply

      De hecho no hay MVC más que en el frontend. En la aplicación de obtención de datos no tiene el menor sentido hablar de MVC, no es una app con UI ni nada por el estilo.

      El uso que cada una de las aplicaciones hace de la DB es distinto, pero hacer que la app web use la DB de manera normal, sin saber que existe un backend complejo de obtención de datos detrás, nos supone un montón de ventajas.

      La idea es que el frontend se limite a leer/escribir configuraciones de dashboards de usuarios, como sus widgets, servicios y demás, y no se entere del resto de la película. El backend tiene acceso a esos datos y a muchos más, y en base a eso se ejecuta la obtención y tratamiento de datos.

      Si ambas aplicaciones no tuviesen acceso a esas configuraciones de usuarios, la plataforma simplemente no podría funcionar. O tendría que hacerlo con una comunicación explícita y constante entre ambas, cosa que descartamos de raíz como uno de los pilares del diseño.

      • Trollaco 13 abril, 2012 at 6:22 pm

        Reply

        Gracias por aclarárlselo a trollaco. Esa arquitectura de pizarra que describes tiene toda la lógica. En el texto del post cuando se habla de Django parece que se está diciendo otra cosa.

        • Aitor Guevara 13 abril, 2012 at 6:24 pm

          Reply

          Lo cierto es que en la entrevista hemos dado 4 pinceladas de como está montado el asunto, nada más, no es muy concreto.

          En los slides hay más información, y en caso de duda nosotros explicamos encantados como está montado el tema. Ayer estuvimos charlando del asunto con la gente de Python Madrid por ejemplo.

  20. pit 13 abril, 2012 at 4:52 pm

    Reply

    “emprendedor de Excel y Powerpoint”   XD  …. me parto +10000 points

  21. Kisco 13 abril, 2012 at 5:10 pm

    Reply

    Interesante articulo, espero la tercera parte pronto.

    La verdad es que es bueno leer este tipo de artículos para entender como funcionan este tipo de iniciativas que acaban convirtiéndose en grandes proyectos. Ademas me encanta conocer el apartado técnico :)

    Por cierto, acabo de suscribirme a la bonilista.

    PD: Algún día tendré que aprender python :)

  22. Oriol Rius 13 abril, 2012 at 6:56 pm

    Reply

    Quiero la tercera entrega :) 

    Hace tiempo que tengo en el punto de mira esta empresa ya que curiosamente coincidimos en muchas decisiones técnicas en la empresa en que soy CTO.

    Buen trabajo y felicidades a todos, a ti Bonilla por el blog y post también felicidades.

  23. Alejandro Martinez 13 abril, 2012 at 6:57 pm

    Reply

    Estos son los más interesantes para un desarrollador :) Ver las tecnologías que se usan y sobretodo las razones de elegir una u otra. 
    No nos dejes sin la tercera parte! ;)

  24. Alfredo 13 abril, 2012 at 11:14 pm

    Reply

    Mas, mas, mas! Quiero mas! En plena startup estos post me vienen de lujo.
    Enhorabuena por la entrevista,muy buena!

  25. shibumi hell 14 abril, 2012 at 6:54 pm

    Reply

    Muchas gracias por todos los detalles, unas preguntas

    ¿Por qué se ha elegido Linode?
    Hasta llegar a esta arquitectura, ¿algún fracaso con algún elemento que se pueda contar?
    ¿Por qué Python, en vez de nodeJS al manejar websockets y tantos datos en tiempo real?
    ¿Qué cambiariais si volvieráis a empezar?

    • Aitor Guevara 15 abril, 2012 at 2:03 pm

      Reply

      Linode se merienda al resto de VPS en comparativas de rendimiento: http://journal.uggedal.com/vps-performance-comparison/ . El soporte es excelente, sólo he visto buenas críticas, y además ya lo usábamos Jan y yo como VPS personal :) Como usamos instancias pequeñas, el precio es competitivo. Y como no buscamos una plataforma elástica ni vamos a explotar los 1000 servicios extra, AWS no tiene ventajas que nos interesen.

      Nuestro principal error fue no hacer un trabajo de diseño del frontend tan exhaustivo como el llevado a cabo en el backend. De modo que tras escribir un frontend “naive” con HTML y jQuery de toda la vida, nos dimos de bruces con la realidad: la aplicación era inmantenible por su tamaño. Tuvimos que reescribirla en Backbone.js, tomándola tan en serio como el backend, pero con la consecuente pérdida de tiempo.

      Python porque Javascript no nos parece un lenguaje serio. Lo usamos en frontend porque no queda otra opción, pero comparado con Python nos parece un lenguaje deficiente. Tiene cantidad de “quirks” para nuestro gusto: undefined vs error, el cachondeo que es el scope de “this”, castings automágicos, no hay parámetros por defecto, … Node.js es un proyecto con 1 o 2 años de recorrido, Twisted tiene 10. Y por experiencia, nosotros venimos de un entorno Python + Twisted.

      Estamos razonablemente cómodos con el diseño actual. De volver a empezar, me tomaría el frontend como un proyecto complejo de buen principio, claro. Ahora mismo estamos luchando por mejorar la calidad del CSS, por ejemplo.

  26. David Chumpitaz 14 abril, 2012 at 11:02 pm

    Reply

    muy buen articulo, en espera de la 3era parte

  27. Mikel 15 abril, 2012 at 4:34 pm

    Reply

    ¡Felicidades por el artículo y ahi va uno más que está a la espera de la 3a parte!

    Este artículo no tiene nada que envidiar  a los de http://highscalability.com/ y encima nos cuenta la historia de algo cercano … pq a mi ya me daba por pensar que estas cosas sólo pasaban al otro lado del gran charco.

  28. Raul Garcia 16 abril, 2012 at 9:19 am

    Reply

    TErcera parte ya!!!!

  29. Juanjo Coello 23 abril, 2012 at 4:40 pm

    Reply

    Voto para la tercera entrada! (Y como buen friki, esta entrada me gustó más que la primera xD)

  30. Pingback: Emprender en... España: Entrevista a Diego Mariño

Leave a reply

Tu dirección de correo electrónico no será publicada. Los campos necesarios están marcados *

Puedes usar las siguientes etiquetas y atributos HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>