Reflexiones sobre tecnología, IA y futuros posibles

Mes: febrero 2010

  • programadores en un proyecto

    Genial artículo de Eduardo Manchón sobre el papel de un programador en una start-up. Cómo programador me he sentido completamente identificado. Aparentemente le da una importancia exagerada al programador, pero creo que lo hace para dejar claro que sin tecnología no hay proyecto. Hay que tener en cuenta que habla de startups tecnológicas, en las que si no hay tecnología, no hay start-up.

    Para mí, el valor de una idea tiene dos componentes: la ejecución y el valor potencial de una idea. El valor real se obtiene del producto de ambas magnitudes. Una buena idea sin ejecutar, no tiene valor, sólo está escrita en un papel (puede que ni siquiera sea realizable). Una ejecución impecable de una mala idea, tampoco (muchas empresas de la burbuja .com entran en esta categoría).

    Relacionado con esto, he leido hace poco un artículo interesante en coding horror, crea equipos no ideas:

    If you give a good idea to a mediocre group, they’ll screw it up. If you give a mediocre idea to a good group, they’ll fix it. Or they’ll throw it away and come up with something else.

    Si le das una buena idea a un grupo mediocre, la estropearán. Si le das una idea mediocre a un buen grupo, la arreglarán. O la tirarán y pensarán en algo nuevo.

    Cuando un proyecto tecnológico comienza, la ejecución depende fundamentalmente de los programadores, ya que la tecnología no existe todavía o está bajo investigación. Una vez que la tecnología funciona, entonces puede pasar a un segundo plano y el diseño, marketing, etc, se vuelven mucho más importantes. Por eso es fundamental tener buenos programadores que comprendan la tecnología cuando empieza un proyecto.

  • realidad aumentada para reparaciones

    Todos nos hemos enfrentado alguna vez a algún aburrido e incomprensible manual de usuario. Gracias a un impresionante proyecto de realidad aumentada aplicada a tareas de reparación y mantenimiento, esto podría cambiar. En vez de utilizar un manual de usuario convencional, es posible que una aplicación de realidad aumentada nos guíe para averiguar y resolver nuestro problema o para aprender a utilizar un aparato.

  • la deconstrucción de la bases de datos

    Éste es otro post rescatado de los borradores que tengo acumulados. Es una referencia a un artículo de Dale Dougherty: deconstructing databases, deconstruyendo las bases de datos.

    La idea que expone es que en ciertas aplicaciones no es necesario modelar los datos utilizando una base de datos, sino que plantea cómo alternativa almacenar los datos en forma parcialmente desestructurada (algunos campos en la base de datos más textos en bruto) y utilizar herramientas de búsqueda de información para recuperar la información. Parte de  un ejemplo concreto, la herramienta de seguimiento de problemas de  google code. Pero hay que tener en cuenta que google debe tener las herramientas más potentes de búsqueda de información en textos. Otra herramienta que va en esta línea es google squared, que partiendo de la información desestructurada de la web, trata de devolver información estructurada.

    De otra forma diferente, pero creo que con la misma idea subyacente, lei hace poco una reflexión de Ignacio de Miguel sobre el abuso de las bases de datos. Aunque la reflexión de Ignacio está más relacionada con el abuso de recursos, parte de un base similar, el uso del modelo de base de datos para todo. Almacenar textos en forma desestructurada y utilizar herramientas de búsqueda de información en textos para recupar esa información de forma ordenada, podría se una forma de romper ese abuso.

    Por otra parte, de cara al usuario, las aplicaciones convencionales que almacenan y presentan la información en forma esructurada, son normalmente muy rígidas (formularios con multitud de campos desglosados). La alternativa es permitir que el usuario escriba texto libremente del que se pueda extraer información ordenada por medio de algoritmos de comprensión de textos. Para el común de los desarrolladores, creo que todavía no hay herramientas suficientemente avanzadas, aunque seguramente los desarrolladores de google tengan ventaja.

  • processing.js

    Para los que trabajen con arduino, sabrán que es un proyecto basado en Processing, un lenguaje y entorno de programación para aplicaciones multimedia e instalaciones interactivas. Lo que quizá no sepan es que processing se ha portado a javascript utilizando la nueva etiqueta canvas de html5: processing.js. En el estado actual, soporta muchas de las instrucciones de processing, excepto las instrucciones 3D, que esperan poder implementarlas cuando se desarrolle una etiqueta canvas 3D (para firefox ya hay un intento de implementación). Además processing.js fue portado por John Resig, creador entre otros proyectos de la librería jquery. Igualmente sorprendente para mí es que muchos de los ejemplos de chrome experiments están hechos con processing.js.

    Una ventaja de processing.js sobre processing es que además de ejecutarse en navegadores recientes y aceptables sin ningún plugin (explorer no entra en esta categoría todavía) se integra fácilmente con el entorno web y se pueden agregar otras librerías javascript (jquery, por ejemplo) para realizar experimentos muy visuales.

    El lado negativo está en el rendimiento, que no es nada bueno. En mi ordenador con 4 cores, se me quedaba bloqueado porque sólo tiraba de una cpu. Si alguien diseña un proyecto complejo, debería implementar parte de la lógica con web workers.

  • más sobre el debate de html5

    Un estudio concluye que el futuro de las aplicaciones móviles está en las aplicaciones móviles web adaptadas a los interfaces táctiles. El estudio viene de una empresa que se dedica a las búsquedas en la web para terminales táctiles, así que no es extraño que hayan llegado a esa conclusión.

    Sin embargo el estudio apoya con cifras la idea de que los juegos y las aplicaciones de entretenimiento se distribuyen más como aplicaciones nativas mientras que las apliaciones sociales y las aplicaciones para compras y servicios se distribuyen más como aplicaciones web.

    En cualquier caso existe la duda técnica de si las aplicaciones basadas en web serán tan rápidas como las aplicaciones de escritorio. Muchas aplicaciones son lo suficientemente buenas, pero probablemente los juegos más exigentes no sean adaptables a la web.

    Un ejemplo que me he encontrtado es el de freeciv un juego de escritorio para el que han desarrollado un frontend en html5 y por ahora la experiencia no me ha parecido demasiado buena. Se puede jugar, pero no tiene una interfaz demasiado buena comparado con el juego de escritorio.

    Por otro lado está la duda económica. Las aplicaciones web generan ingresos principalmente por medio de la publicidad y las suscripciones. Las aplicaciones nativas lo hacen mayoritariamente a través del cobro por descarga. Aunque técnicamente sea viable desarrollar juegos completamente html5, es posible que generen más ingresos con el modelo de cobro por descarga, por lo que quizá no sea rentable desarrollar juegos html5.