Introducción a Internet para mi suegro y aspirantes a Business Angels

Un video de 50 minutos sobre los fundamentos de Internet y por qué es importante tener un mínimo conocimiento si quieres invertir dinero en tecnología.

Se me ponen los pelos como escarpias al ver el mensaje oficial que llega a los valientes que deciden invertir su dinero en el mundillo estartapil sin tener mucha idea de como funciona todo esto.

Por eso, cuando el año pasado los amigochos de Tetuan Valley me pidieron que explicara “Internet en 15 minutos” a los asistentes de su Angel School -una suerte de escuela para inversores que quieren empezar a invertir en empresas tecnológicas-, acudí encantado a la llamada, con la intención de dejar claros tres conceptos:

  • Construir cualquier cosa con un mínimo de calidad en Internet es difícil
  • Construirlo sólo es el principio. Lo difícil es crear un modelo de negocio
  • Si alguien te dice que se puede hacer con 30.000€, te está engañando

Para conseguirlo, me propuse explicar los conceptos básicos en los que se basa Internet desde un punto de vista de negocio, intentando ser ameno y lo más neutro posible, pero no puede evitar que se me colara alguna bonillada, como mi propuesta para gravar con impuestos el 99% de las plusvalías generadas por la compraventa de dominios para acabar con los domainers.

Gracias a mi ya famosa capacidad de concreción, ese cuarto de hora se convirtió en un LADRILLAZO de 50 minutazos. Aún y con todo, un tiempo más que aceptable para intentar explicar la fontanería de Internet.

Definitivamente, con este vídeo NO aprenderás cómo funciona Internet, pero, si estás pensando en meter pasta en una empresa tecnológica o hacer negocios en Internet, con él podrás partir de una base y, sobre todo, escuchar un mensaje ligeramente distinto al oficial.

  • Er juan

    ‘grabar’ es mas bien ‘gravar’ ¿no?

  • damarsan

    Video muy interesante, sobretodo aclaratorio. Ahora con la crisis todos los negocios se dan la vuelta y miran internet como algo barato que con 4 cacahuetes se hace.

    • “si pagas con cacahuetes, contratarás monos”. ESO ES ASÍN 😛

  • Pues me ha gustado, aunque quizá para la siguiente iteración yo acortaría un poco el principio técnico y alargaría al final de gestión… Y pondría en letras más grandes eso de “todo esto cuesta dinero si se quiere hacer bien” Me parece la lección más importante, hay que explayarse! 😀

    Sólo un par de matizaciones, por la discusión, más que nada:

    – Es cierto que con cualquier lenguaje se puede hacer (poco más o menos) cualquier cosa. Sin embargo, creo que la elección de lenguaje de alguien dice mucho sobre esa persona y la forma de trabajar. Mi opinión es que los buenos programadores tienen fuertes opiniones sobre si este u otro lenguaje es mejor o más adecuado. El tener una posición no es una “bandera roja” (bajo mi modo de ver), aunque sí que lo es el hecho de que no sea razonado y desde una perspectiva “es mi opinión, no la verdad absoluta” respetuoso, no troleando, claro… En general (y esto es experiencia personal), la gente buena con la que he trabajado preferían unas tecnologías a otras, aunque entendían que había veces que trabajar con las que no les gustaban (legacy code, más adecuado para el problema)

    – Respecto al tema NoSQL para graaaandes aplicaciones. El enfoque creo que es ligeramente diferente. No es necesario tener una aplicación con muchos usuarios para tener muchas peticiones (que es lo que cuenta). Una página web estática puede tener muchísimas visitas antes de dar un problema, mientras que una página de bolsa en tiempo real a lo mejor con 1.000 usuarios que la tengan abierta constantemente puede generar un montón de accesos a BBDD. Por experiencia, cuando estuve haciendo un juego online, cada usuario generaba un montón de peticiones y accesos a BBDD, así que no hacían falta millones de usuarios para necesitar ese extra NoSQL. Así que la respuesta es, como siempre, haz una estimación y consulte con su desarrollador de cabecera 😀

    Paso de otras consideraciones técnicas NoSQL-SQL sobre facilidad de diseño de esquema, DBA, etc, que entiendo que están fuera de consideración para este nivel, pero creo que es interesante reseñar que las BBDD SQL son muy interesantes cuando tienes miles de enlaces distintos sobre unos datos comunes, que deben estar fuertemente protegidos para que nadie haga nada raro con ellos y disponibles en formatos soportados en todos los variados programas de los departamentos. Esto es muy importante en empresas grandes, que tienden a tener este tipo de escenario, no normalmente las que están empezando, pero creo que es interesante saberlo a nivel de negocio.

    • Pues completamente de acuerdo con tus dos puntualizaciones.

      Respecto al tema NoSQL, como comentaba en la charla, creo que también es importante tener en cuenta la disponibilidad de gente con experiencia REAL con esas herramientas. Hoy por hoy, poca. Ya veremos con el tiempo… pero vamos, que un MySQL te aguanta 1000 conexiones concurrentes sin que estalle nada 🙂

      • DISCLAIMER: Batallita/Autobombo…

        Me acuerdo justamente de hablar de esto hace poco tiempo, cuando estaba buscando trabajo, y decir que, oye, después de todo, tenía (y sigo teniendo) dos años de experiencia utilizando MongoDB (tecnología MUY controvertida, pero “de moda”). Me comentaba este amigo que le llamó la atención el comentario, pero que le parecía muy interesante, porque es verdad…

        Ya digo, he usado MongoDB durante algo más de dos años en producción. Sé cómo hacerle cosquillas, donde se rompe, donde funciona y he metido el cazo y solucionado problemas unas cuantas veces. El caso es que me gusta y me parece una tecnología interesante. Me considero además favorable al NoSQL. Pero, en mi último trabajo recomendé migrar de Riak a una BBDD SQL (terminó siendo PostgreSQL) porque, oye, lo que pedían los datos era una BBDD relacional. Que al final las tecnologías son herramientas al servicio de.

      • Ah, otra cosa, en la empresa que trabajo ahora (DemonWare), todo va sobre MySQL. Y soportamos millones de jugadores a la vez.

      • uno que pasaba

        Hay dos motivos para elegir una BD NoSql:

        ·La escalabilidad horizontal en clusters.

        ·La productividad.

        En una BD de datos relacional los datos están “aplanados” así que una gran parte del trabajo se va en el mapeo de datos relacional a estructuras de datos en memoria y al revés.

        • ¿Te puedes explicar un poco más? No sé exactamente a que te refieres.

          • uno que pasaba

            En el vídeo comentas que la única razón para elegir una BD NoSQL es por temas de rendimiento, y como en estos comentarios ha salido el tema… pues he puntualizado que no es así.

            Además defender el uso de una BD relacional porque tenemos una serie de datos relacionados entre si no tiene ningún sentido (la definición de BD podría ser: “un conjunto de datos relacionados entre si”). En una BD de datos NoSQL también tienes un conjunto de datos relacionados entre si.

            Se llama “relacional” porque implementa el álgebra relacional donde se define matemáticamente una relación; que es un conjunto de tuplas, es decir una tabla. Una referencia de una columna a otra columna con el mismo nombre en otra tabla no es una relación. Otra cosa es que estas BBDD puedan manejar operaciones atómicas a través de varias tuplas por varias relaciones asegurándote una integridad referencial.

            En las BD NoSQL, la mayoría (porque esa palabra es un cajón desastre que engloba varios modelos), están orientadas al agregado todos los datos relacionados que quieras que se traten de forma atómica los tendrás que meter en el mismo agregado, si no si que tendrás que programarte tú la integridad referencial.

            Me estoy yendo por las ramas, no me mal interpretes, no soy DBA y además siempre he trabajado con Oracle, no quiero ir de taliban ni de evangelizador del NoSQL ni ser un hipocrita… pero eso no quita que pueda tener cierta cultura más allá de escuchar campanas de algún sitio sin saber de donde. Sólo quería puntualizar que además del rendimiento la productividad es la otra razón por la que podría merecer la pena elegir una BD de éste tipo, y tener cierto grado de consistencia (referencias entre datos).

            Para explicar el tema de la productividad os pongo un link y así me evito escribir tanto que además me explico como el culo: http://martinfowler.com/bliki/OrmHate.html
            Todo este tochaco por preguntar… (que no por sacar punta ¡eh!)

  • Hola David,

    Antes de nada, tengo que reconocerte el mérito de afrontar la tarea hercúlea que es explicar todo esto a gente no técnica en tan poco tiempo.

    Aunque hay partes que podrías haber omitido (o simplificado), por ejemplo las más técnicas como el tema de protocolos, etc., ya que dudo que a alguien no técnico le hayan calado demasiado en tan poco tiempo.

    A pesar de esto, creo que está muy bien que hablaras sobre la “fontanería”, no tanto para que lo entiendan sino para mostrar la complejidad que supone un desarrollo (supongo que esa era la idea). Pero lo que creo que ha sido más efectivo son las ocasiones en las que explicas por qué esto cuesta lo que cuesta, como el ejemplo de Oracle, y sobre todo la parte final de metodología, que creo que ha sido con lo que más impacto habrás hecho, y donde dejas claro la forma correcta de hacer las cosas.

    Personalmente, creo que en estos casos, la mayor barrera que te encuentras para comunicar todo esto es el lenguaje. Términos habituales para nosotros como “ejecutar”, “modelo”, “relacional”, “REST”, u otras expresiones técnicas, creo que es difícil que lleguen al receptor correctamente en este contexto, aunque está claro que tienen que empaparse un mínimo de todo esto. Ojo, y de hecho esto es normal, ya que cada uno sabe de lo que sabe y punto. Por eso creo que el enfoque más adecuado en este contexto, es el que tomaste en la última parte.

    Un recurso que puede resultar bastante válido para estas ocasiones (con más tiempo, claro), sería esta web, que creo que está bastante bien redactada (es posible que ya la conozcas): http://www.20thingsilearned.com/es-ES/home

    Respecto a lo que comentas sobre posicionarse en un lenguaje u otro, no estoy muy de acuerdo con lo que dices, ya que aunque obviamente respeto el uso de cualquiera, SÍ que es muy discutible la productividad que te va a proporcionar la elección de uno u otro (lo digo por experiencia de bastante tiempo, y no creo que seamos pocos los que opinamos así). Y lo que sí es discutible es el uso de esto como “detector de cretinos”, aunque reconozco que en ocasiones puedes acertar con esto 😀

    Bueno ya por último, y en plan humor, si no te funciona nada de esto, te remito a cierto capítulo de IT Crowd donde presentan “the internet”, aunque ya es un poco “from the past” 🙂

    Un saludo!

    • Hola Alberto!

      Conocía el recurso. Creo que fue uno de los primeros ejemplos de HTML5 ¿no? En cualquier caso, sigue vigente y es MUY, MUY bueno.

      Respecto a mi infalible “detector de cretinos”… yo creo que una discusión razonada y argumentada sobre pros y contras de 2 o más lenguajes es muy enriquecedora, pero me he encontrado con MUY pocos expertos en 2 o más lenguajes y si mucho “fan”.

      Yo por ejemplo, no puedo decir que PHP sea una mierda porque, básicamente no tengo ni idea de PHP, pero sin embargo mucha gente lo dice gratuitamente.

  • Luis Ascorbe

    Hay algunos porcentajes no se de dónde los sacas, como:
    El 95% de las apps que no son juegos están hechas en HTML5. Hay un mundo increible de desarrolladores nativos, y creciendo.

    El resto me ha gustado bastante aunque yo no hubiese ni mencionado lo de GET/REST ;).

    Un saludo!
    Luis.

    • Creo que lo dije -o al menos lo que pretendía- era que el 95% de las apps que no son juegos se pueden hacer con HTML5 perfectamente, porque no requieren rendimiento gráfico y su UX no penaliza mucho por el hecho de no utilizar código nativo.

      Evidentemente, si se puede, yo prefiero nativo en todo. Hasta para GameBoy ^_^

  • Ahora el dummy de turno es el business angel. Muy bueno 😉

  • No me he animado a comentar hasta ahora, pero es que lo de que los programadores tenemos que hacer un poco de todo en este país me ha llegado al alma, porque es una gran verdad. Además, me gusta que defiendas las soluciones de pago frente al software libre, ya que en este país se defiende mucho el software libre, pero más por ahorrarse pasta que porque realmente piensen que es mucho más eficiente. Saludos.

  • Me ha gustado mucho. He anotado algunas ideas para cuando tengo que dar explicaciones a mis clientes de porqué nuestro trabajo es tan caro si ‘todo el mundo lo hace’ o ‘no te puede costar más de una tarde’ ‘una app que se vende por menos de 1 euro costará poco más de 200 euros de desarollo’ y mil frases por el estilo.

  • laura

    Interesante. Es cierto que parece que ahora todo el mundo quiere unirse al carro y está claro que no es tarea fácil, aún así, hay gente que lo consigue. Al menos a mi parecer, unos jovenes emprendedores que han lanzado hace poco la web de http://www.tikcode.com, un comercio electrónico solidario, distinto a los demás, han sabido ofrecer algo diferente, y al parecer está creciendo como la espuma!!