Entrevista Kite Invest
Aqui teneis nuestra entrevista en Kite Invest.
Kite Invest promueve y desarrolla oportunidades de negocio a través de un incremento constante en la recepción de Flujos de Capitales Extranjeros de la mano de algunas de las instituciones financieras y bancarias de mayor prestigio.
Presentación a Inversores XV Foro de Inversión Madri+d
Presentación a inversores en el XV Foro de Inversión Madri+d, un foro para empresas tecnológicas organizado por BAN Madrid (Business ANgels Madrid) y la Fundación Madri+d.
¡Esperamos que os guste!. Y los interesados: no dudeis en contactarnos.
Representación del Conocimiento y Automatización de Software
La representación del conocimiento es una disciplina que persigue la representación de la información del mundo real de una manera que pueda ser interpretada por las máquinas para resolver, mediante inferencia, problemas complejos.
Tradicionalmente ha sido una disciplina de la inteligencia artificial y últimamente ha adquirido gran relevancia por su utilización en el ámbito de la semántica. El proyecto de la Web Semántica, liderado por la W3C, es un claro ejemplo de ello.
Aunque existen muchos enfoques para la representación del conocimiento, comúnmente todos persiguen: definir los conceptos, las relaciones y las reglas que definen la información. Mediante los diferentes conceptos podemos clasificar la información y mediante las relaciones y reglas podemos inferir (razonar) sobre ella. Por lo tanto, en vez de tener información “plana” tendremos además una meta-información que nos permitiría procesarla.
Desde la perspectiva de los lenguajes
En anteriores publicaciones vimos como los Language Workbenches definen los lenguajes mediante las sintaxis abstracta y concreta y las semánticas estáticas y dinámicas. Si nos damos cuenta esa definición sería la meta-información que hace que un programa sea una representación del conocimiento y que, por tanto, podemos utilizar todo el potencial que esta disciplina nos aporta.
Se suele pensar en los Language Workbenches como generadores de código pero, enfocados desde el punto de vista de la representación del conocimiento y de la semántica, pueden ofrecernos muchos más servicios. Enumeramos algunos:
Tradicionalmente ha sido una disciplina de la inteligencia artificial y últimamente ha adquirido gran relevancia por su utilización en el ámbito de la semántica. El proyecto de la Web Semántica, liderado por la W3C, es un claro ejemplo de ello.
Aunque existen muchos enfoques para la representación del conocimiento, comúnmente todos persiguen: definir los conceptos, las relaciones y las reglas que definen la información. Mediante los diferentes conceptos podemos clasificar la información y mediante las relaciones y reglas podemos inferir (razonar) sobre ella. Por lo tanto, en vez de tener información “plana” tendremos además una meta-información que nos permitiría procesarla.
Desde la perspectiva de los lenguajes
En anteriores publicaciones vimos como los Language Workbenches definen los lenguajes mediante las sintaxis abstracta y concreta y las semánticas estáticas y dinámicas. Si nos damos cuenta esa definición sería la meta-información que hace que un programa sea una representación del conocimiento y que, por tanto, podemos utilizar todo el potencial que esta disciplina nos aporta.
Se suele pensar en los Language Workbenches como generadores de código pero, enfocados desde el punto de vista de la representación del conocimiento y de la semántica, pueden ofrecernos muchos más servicios. Enumeramos algunos:
- Generar baterías de pruebas.
- Generar cargas iniciales de datos. Relleno de estructuras de bbdd para pruebas de rendimiento.
- Auto-documentación.
- Auto-validación.
- Análisis estadísticos de los datos y de los programas.
- Inferir comportamiento de los usuarios, clientes, etc.
- Facilitar la importación y exportación de datos. Por ejemplo XBRL: lenguaje de presentación de informes de negocio extensible.
- Enlazar con ontologías estándar. Por ejemplo FIBO: ontología del negocio financiero.
- Facilitar la integración con otros sistemas.
- Razonamiento automático (machine reasoning).
Conclusión
La representación del conocimiento esta siendo un área de investigación enfocada sobre todo en el tratamiento de los datos: estructurar la información de los buscadores, análisis semánticos aplicados al Big Data, definiciones de ontologías asociadas a diferentes negocios, etc.
Construir metodologías de desarrollo que doten a los programas de esas capacidades es una puerta hacia el futuro con potenciales aun por descubrir.
Ver todos los posts Teórico.
La representación del conocimiento esta siendo un área de investigación enfocada sobre todo en el tratamiento de los datos: estructurar la información de los buscadores, análisis semánticos aplicados al Big Data, definiciones de ontologías asociadas a diferentes negocios, etc.Construir metodologías de desarrollo que doten a los programas de esas capacidades es una puerta hacia el futuro con potenciales aun por descubrir.
Ver todos los posts Teórico.
Language Workbench
En anteriores publicaciones vimos lo que son los DSLs y por qué son necesarios y útiles en el desarrollo de software. Una vez que decidimos apoyarnos en ellos, nos encontramos ante la necesidad de una herramienta que nos permitan diseñarlos y utilizarlos. Esta herramienta se denomina técnicamente Language Workbench (LW).
Un LW está formado por dos partes fundamentales:
Un LW está formado por dos partes fundamentales:
- Diseño del lenguaje.
- Uso del lenguaje. Programación.
Es posible que en el futuro la herramienta se divida en dos, de tal manera que, dentro o fuera de una organización, existirán dos roles perfectamente diferenciados: quienes diseñen el lenguaje y quienes se encarguen de utilizarlo, de programar en él.
Diseño del lenguaje
Un LW debe ser capaz de proveer las utilidades para definir las diferentes partes que forman el lenguaje:
Diseño del lenguaje
Un LW debe ser capaz de proveer las utilidades para definir las diferentes partes que forman el lenguaje:
- Sintaxis abstracta. La estructura gramatical/conceptual que define el lenguaje. Puede ser entendido también como el meta-modelo.
- Sintaxis concreta. La representación o representaciones visuales de dichos conceptos. Pueden ser representaciones en formato texto y/o gráfico. Para entendernos, es la definición de la interfaz visual con la que trabajará el programador.
- Semántica estática. Define aquellas restricciones o reglas que el lenguaje debe cumplir (aparte de ser sintácticamente correcto).
- Semántica dinámica. Sería sobre todo la traducción a lenguajes tradicionales aunque, como mencionaremos luego, aquí se encuentra el mayor potencial de esta metodología de desarrollo.
Uso del lenguaje
Una vez definidos los puntos anteriores, la herramienta es capaz de interpretarlos y proveernos de un entorno de desarrollo (IDE). Según sea más o menos sofisticado, a parte de la edición, nos podrá proveer de utilidades como: autocompletar, validaciones estáticas, resaltar elementos sintácticos, mostrar diferentes vistas e incluso debug.
A parte de las características anteriores, este entorno nos permitirá generar código e incluso podrá dotarnos de un proceso de building para obtener el aplicativo final.
Potencial futuro
Todo lo comentado hasta ahora nos permite tener un proceso de desarrollo análogo al tradicional pero con las ventajas que ofrecen los DSLs y la generación de código, lo cual es un enorme avance en el que se apoyan los defensores e investigadores de esta metodología.
Estando de acuerdo en lo anterior, para nosotros el verdadero potencial, aun por descubrir, es el hecho de que la programación deja de ser una mera declaración funcional y pasa a ser una representación del conocimiento. Una vez que definimos los conceptos y sus reglas, la semántica puede ser capaz de ofrecernos muchos más servicios que la simple generación de código.
Ver todos los posts Teórico.
Una vez definidos los puntos anteriores, la herramienta es capaz de interpretarlos y proveernos de un entorno de desarrollo (IDE). Según sea más o menos sofisticado, a parte de la edición, nos podrá proveer de utilidades como: autocompletar, validaciones estáticas, resaltar elementos sintácticos, mostrar diferentes vistas e incluso debug.
A parte de las características anteriores, este entorno nos permitirá generar código e incluso podrá dotarnos de un proceso de building para obtener el aplicativo final.
Potencial futuro
Todo lo comentado hasta ahora nos permite tener un proceso de desarrollo análogo al tradicional pero con las ventajas que ofrecen los DSLs y la generación de código, lo cual es un enorme avance en el que se apoyan los defensores e investigadores de esta metodología.
Estando de acuerdo en lo anterior, para nosotros el verdadero potencial, aun por descubrir, es el hecho de que la programación deja de ser una mera declaración funcional y pasa a ser una representación del conocimiento. Una vez que definimos los conceptos y sus reglas, la semántica puede ser capaz de ofrecernos muchos más servicios que la simple generación de código.
Ver todos los posts Teórico.
DSLs
Los lenguajes específicos de dominio (Domain-Specific Languages – DSLs) son lenguajes de programación diseñados para definir, de una manera más precisa y expresiva, áreas particulares, bien sean técnicas o de negocio.
Se denominan así en contraposición a los lenguajes de propósito general (General Purpose Languages – GPLs – Java, C#, C++, etc), ofreciendo un enfoque menos amplio pero más preciso, es decir, su objetivo es cubrir únicamente el área o dominio para el que se diseñan pero hacerlo con las estructuras gramaticales y/o abstracciones gráficas que mejor le definen.
Para entender estos lenguajes vamos a verlos desde dos puntos de vista: como una evolución a partir de la generación de código y como una evolución desde los GPLs.
DSLs desde la generación de código
Existen diferentes formas, más o menos sofisticadas, para generar código: macros, datos estructurados en tablas, generación dinámica, parseo de estructuras simples, modelados tipo CASE, etc, pero siempre que hablemos de un nivel elevado hablaremos de lenguajes (de tipo texto o gráfico), donde se define de manera formal las estructuras lingüísticas, su representación y su interpretación.
De este modo, entendemos que los DSLs son la vía más sofisticada en la generación de código.
DSLs desde los GPLs
Los GPLs son potentes porque permiten definir todos los problemas (Turing completo) pero en muchos casos son expresivamente pobres debido al salto entre la definición del problema (mundo real) y su solución (código fuente). Esto hace muy complicada la programación y el mantenimiento porque se hace difícil entender lo que se pretende solucionar.Pongamos por ejemplo la definición de una interfaz de usuario web y su representación en HTML: el salto expresivo es enorme.
En base a esta necesidad surgen los DSLs.
Características y ventajas de los DSLs
Se denominan así en contraposición a los lenguajes de propósito general (General Purpose Languages – GPLs – Java, C#, C++, etc), ofreciendo un enfoque menos amplio pero más preciso, es decir, su objetivo es cubrir únicamente el área o dominio para el que se diseñan pero hacerlo con las estructuras gramaticales y/o abstracciones gráficas que mejor le definen.
Para entender estos lenguajes vamos a verlos desde dos puntos de vista: como una evolución a partir de la generación de código y como una evolución desde los GPLs.
DSLs desde la generación de código
Existen diferentes formas, más o menos sofisticadas, para generar código: macros, datos estructurados en tablas, generación dinámica, parseo de estructuras simples, modelados tipo CASE, etc, pero siempre que hablemos de un nivel elevado hablaremos de lenguajes (de tipo texto o gráfico), donde se define de manera formal las estructuras lingüísticas, su representación y su interpretación.
De este modo, entendemos que los DSLs son la vía más sofisticada en la generación de código.
DSLs desde los GPLs
Los GPLs son potentes porque permiten definir todos los problemas (Turing completo) pero en muchos casos son expresivamente pobres debido al salto entre la definición del problema (mundo real) y su solución (código fuente). Esto hace muy complicada la programación y el mantenimiento porque se hace difícil entender lo que se pretende solucionar.Pongamos por ejemplo la definición de una interfaz de usuario web y su representación en HTML: el salto expresivo es enorme.
En base a esta necesidad surgen los DSLs.
Características y ventajas de los DSLs
- Mayor nivel de abstracción. Definen conceptos más complejos, más abstractos y por tanto más expresivos.
- Tienen menos grados de libertad. Normalmente no son Turing completos. Permiten definir el dominio, nada más que el dominio y con las reglas que rigen el dominio, lo cual les dota de una enorme potencia (en ese dominio, claro).
- Aumentan la productividad ya que permiten programar de una manera más rápida y eficiente.
- Mejoran la calidad del software. Abstraen de la complejidad técnica, generalmente resuelta por el generador de código, evitando errores.
- Soporte IDE (entorno de desarrollo integrado). Validaciones, comprobación de tipos, autocompletar, etc. Esto es una gran diferencia respecto a la definición del dominio mediante APIs o Frameworks.
- Independientes de la plataforma.
- En general todos las ventajas de la generación de código.
Los DSLs son comunes en el mundo real, a lo largo de la historia han sido creados en matemáticas, ciencia, medicina… Es el momento de usarlos en el desarrollo de software.
Ver todos los posts Teórico.
Ver todos los posts Teórico.
XV Foro de Inversión Madri+d
Hemos sido seleccionados para presentar en el XV Foro de Inversión Madri+d, un foro para empresas tecnológicas organizado por BAN Madrid (Business ANgels Madrid) y la Fundación Madri+d.
¡Hablemos!.
10 Ventajas de la Generación de Código
Vayamos al grano. He aquí la lista:
- Calidad SW: En todos los aspectos: rendimiento, fiabilidad, seguridad, etc.
- Estandarización: no sólo en el código fuente: en la interfaz de usuario, en las estructuras de base de datos, etc.
- Centralización: políticas globales tales como el manejo de errores, la gestión de excepciones, el formato de visualización de datos, las validaciones de datos, comprobar los permisos, etc. están centralizados en el generador. Este tipo de políticas son también conocidos como funcionalidades transversales y es un tema abordado por la Programación Orientada a Aspectos (AOP en inglés) en la programación tradicional. La centralización evita este problema.
- Refactorización: relacionado con el beneficio anterior, la refactorización de código es fácil y segura.
- Productividad: Menor coste y menor tiempo de lanzamiento al mercado (entre versiones).
- Habilidades Analíticas: la generación de código requiere un análisis más profundo del dominio antes de implementar la solución a través del generador.
- Habilidades de Diseño: requiere un buen arquitecto, con una visión más amplia.
- Crecimiento Sano: previene la degradación de la arquitectura.
- Integración de Nuevos Miembros: la cultura o las normas de desarrollo son menores cuando se trabaja con generación de código.
- Nivel de abstracción: la programación a un nivel más abstracto, además de fácil de entender (es más intencional), abre la puerta a nuevas posibilidades, tales como: generación de pruebas unitarias, auto-documentación, carga automática de datos, semántica, racionamiento automático, etc.
La generación de código no es fácil, la implementación de un generador requiere de tiempo y esfuerzo, y más aún si se trata de un Language Workbench, pero, sin duda, los beneficios son enormes.
Ver todos los posts Teórico.
Programa «Soy Emprendedor»
Hemos sido seleccionados para el programa «Soy Emprendedor, Soy de la Mutua», un programa de la Mutua Madrileña para Startups.
¡Vamos a disfrutarlo!
Buenas Prácticas en la Generación de Código
El error más común cuando generamos código es verlo como una caja negra, pensando que lo importante es «lo que hace» y no «cómo lo hace». Esto es un error. Como siempre, la calidad importa.
Estas son algunas de las características que un buen código generado debería tener:
Estas son algunas de las características que un buen código generado debería tener:
- Independiente: el código manual y el generado deben estar en archivos diferentes, de lo contrario se corre el riesgo de perder el primero en el caso de que tengamos que volver a generar el código (y sucederá).
- Inmutable: no se debe cambiar, por dos razones: es peligroso, por ser desconocido, y por la misma razón que en el caso anterior.
- Legible: eso significa: nombres de variables y funciones significativos, comentarios, sangría, organizados en carpetas, archivos, etc. El código generado debe estar presentable para recibir la visita de los desarrolladores: para saber cómo funciona y ¿por qué no?, para aprender de él. Debemos generar un código del que sentirnos orgullosos.
- Extensible: por diferentes razones es posible que tenga que implementar manualmente algunas funcionalidades, por lo que el código generado debe dejar algunas puertas abiertas. La mejor manera es diseñar el código generado como un Framework, donde el código manual puede extender sólo algunas funcionalidades permitidas y en un entorno seguro.
- Estructurada: elevar el nivel de abstracción requiere un buen conocimiento del campo que se está tratando. Un código mal estructurado puede ser un síntoma de que ese campo no está completamente bajo control. Una buena generación de código requiere un buen arquitecto.
- Robusto: el código generado puede fallar, por supuesto. El control de errores, la gestión de excepciones, la validación de las entradas, validaciones internas, etc deben ir siempre incluidas en el código. Este tipo de políticas de seguridad se pueden implementar fácilmente en la generación de código y debe ser una de las razones de su calidad.
- Potente: una vez dicho lo anterior, deberíamos ver la generación de código como una forma de escribir un código más potente, eso significa pensar en estrategias, en el código generado, que nunca usaríamos si lo hiciéramos a mano (por lo general por razones de mantenimiento).
En resumen, las buenas prácticas en la generación de código son una mezcla de las buenas prácticas tradicionales y una forma más amplia de pensar.
Ver todos los posts Teórico.
Ver todos los posts Teórico.
¿Por qué generación de código?
La generación de código no es un nuevo estilo o técnica, es el camino seguido por los lenguajes de programación para hacer frente a la complejidad, desde la codificación en binario hasta la primera, segunda y demás generaciones de lenguajes. Es lo que los compiladores han estado haciendo desde el inicio.
El tema clave aquí es «hacer frente a la complejidad». Mientras más complejo sea el problema más abstracto tiene que ser la forma de pensar para resolverlo. En otras palabras, es necesario elevar el nivel de abstracción. Y esta regla se aplica igualmente a las herramientas que se utilizan para resolver el problema: los lenguajes de programación.
Por lo tanto, podemos afirmar que «elevar el nivel de abstracción es el objetivo perseguido en la evolución de los lenguajes de programación».
Los lenguajes comunes que se utilizan hoy en día para resolver los problemas (Java, C #, C + + , Delphi … ), se conocen como “lenguajes de propósito general” (GPL en inglés ), y aquí está el problema: «propósito general», que significa que pueden resolver «todos» los problemas, pero desde una perspectiva global. Pueden resolver desde un nivel de abstracción lo suficientemente amplio como para llegar a la solución, pero no tan alto como lo que necesitaríamos en cada problema particular. Existe una brecha entre el nivel de abstracción que utilizamos para lidiar con el problema y el nivel de abstracción que utilizamos para resolverlo a través de GPLs.
¿Cómo podemos cubrir esa brecha? Obviamente, con la generación de código.
Como conclusión, para abordar adecuadamente un problema tenemos que encontrar un lenguaje particular para definir la solución en el nivel de abstracción que cada problema requiere. Con el fin de hacer que la solución sea computable, tenemos que generar código, por lo general en el nivel inferior más cercano: el de GPL.
Esos lenguajes particulares se conocen como “lenguajes específicos de dominio” (DSL en inglés), pero este tema se abordará en otro post.
Como conclusión, decir que este enfoque no es solo aplicable a problemas de negocio sino también a la resolución de problemas técnicos. Por ejemplo, los nuevos retos que ofrece la programación de aplicativos web de escritorio requieren un enfoque más abstracto que integre todas las tecnologías: HTML, CSS, JavaScrpit, AJAX y otros.
Ver todos los posts Teórico.
El tema clave aquí es «hacer frente a la complejidad». Mientras más complejo sea el problema más abstracto tiene que ser la forma de pensar para resolverlo. En otras palabras, es necesario elevar el nivel de abstracción. Y esta regla se aplica igualmente a las herramientas que se utilizan para resolver el problema: los lenguajes de programación.
Por lo tanto, podemos afirmar que «elevar el nivel de abstracción es el objetivo perseguido en la evolución de los lenguajes de programación».
Los lenguajes comunes que se utilizan hoy en día para resolver los problemas (Java, C #, C + + , Delphi … ), se conocen como “lenguajes de propósito general” (GPL en inglés ), y aquí está el problema: «propósito general», que significa que pueden resolver «todos» los problemas, pero desde una perspectiva global. Pueden resolver desde un nivel de abstracción lo suficientemente amplio como para llegar a la solución, pero no tan alto como lo que necesitaríamos en cada problema particular. Existe una brecha entre el nivel de abstracción que utilizamos para lidiar con el problema y el nivel de abstracción que utilizamos para resolverlo a través de GPLs.
¿Cómo podemos cubrir esa brecha? Obviamente, con la generación de código.
Como conclusión, para abordar adecuadamente un problema tenemos que encontrar un lenguaje particular para definir la solución en el nivel de abstracción que cada problema requiere. Con el fin de hacer que la solución sea computable, tenemos que generar código, por lo general en el nivel inferior más cercano: el de GPL.
Esos lenguajes particulares se conocen como “lenguajes específicos de dominio” (DSL en inglés), pero este tema se abordará en otro post.
Como conclusión, decir que este enfoque no es solo aplicable a problemas de negocio sino también a la resolución de problemas técnicos. Por ejemplo, los nuevos retos que ofrece la programación de aplicativos web de escritorio requieren un enfoque más abstracto que integre todas las tecnologías: HTML, CSS, JavaScrpit, AJAX y otros.
Ver todos los posts Teórico.
Bheudek 