Cuando un desarrollador dice: “Eso no se puede hacer…”

La visión de las cosas del programador

Es difícil para los no programadores, entender cuán complejo puede ser el desarrollo de software. Sólo tienes que decirle al al ordenador qué hacer, ¿verdad? ¿Qué tan difícil es eso?

Bueno, es engañosamente difícil, porque el ordenador carece completamente de lo que los teóricos han descrito como un marco de conocimiento. Por ejemplo, puedo pedirle que haga algo simple, como “tráeme un bocadillo de jamón”. Puedes intuir rápidamente que yo en realidad lo que quiero decir es “vete a la cocina,” haz un bocadillo de jamón, y tráemelo “o”vete a la bocatería, pídeme un sándwich de jamón, y me lo traes” basado en el contexto en el que físicamente estamos y lo que ha sucedido las últimas veces que esa misma petición se ha realizado.

Se puede intuir, en el caso del escenario de ir a la cocina, que hay que ir a la nevera, encontrar el jamón, el queso cheddar blanco (porque sabes que me gusta, y no el americano), la mostaza Djion (porque sabes que me gusta en el bocadillo de jamón y no la mayonesa) , encontrar una barra de pan, montar todo el asunto, guardar los ingredientes de nuevo en la nevera, averiguar dónde están los platos, emplatarlo, y traerlo. Y si eres muy observador, notarás que me estoy saltando un mogollón de pasos como saber cuánta mostaza a utilizar, sacarle la envoltura plástica al queso, cuánto jamón entra en un bocadillo estándar de jamón, qué es en realidad un bocadillo, y si nos ponemos qué es el “jamón”…

Cuando te sientas a programar no te puedes saltar ni uno de esos pasos minúsculos. Si no se especifican detalladamente los pequeños pasos aparentemente microscópicos que son intuitivamente obvios para ti, como ser humano, que vives en un mundo lleno de contextos y matices, el ordenador hace lo incorrecto, o falla, o a veces las dos cosas.

Un poco de empatía a la hora de hacer peticiones

Como no programador, probablemente le estés diciendo a los programadores que están trabajando en un software cosas del estilo: “¿puedes hacer que esa ventana sea más grande?” o “dirigirte al usuario por su nombre de pila” o “deja que el usuario publique eso en su página de Facebook” o cosas vagas e indeterminadas del estilo, en un contexto de una gran variedad de cosas de las que el ordenador “no sabe” absolutamente nada.

Para ti es intuitivo, y parece muy fácil…. entonces, ¿Cuál es el problema?

El problema está en que los programadores con este tipo de tareas tienen que manejar diferentes capas de complejidad. Hoy en día, hay que dar por hecho que no han escrito todo el código con el que trabajan ellos mismos, han usado una librería (trozos de código escrito por otra persona para solucionar problemas muy comunes) proporcionada por un tercero, para hacer todo el trabajo “gordo”. Normalmente esto implica usar más de una librería, ya que hay muchos tipos de dependencias e interdependencias.

Así que cuando le dices a un desarrollador: “deja que los usuarios posteen en Facebook”, tienes que tener en cuenta que van a esccuchar tu pertición y van a pensar “eh, claro, eso se puede hacer más o menos de forma sencilla quizás, creo que tenemos su información de Facebook en una base de datos por aquí, creo que tenemos las librerías apropiadas para eso aquí, sí, se puede hacer fácilmente”, lo que conduce a hacer una estimación optimista de cuanto tiempo puede tomar.

Empiezan los problemas imprevistos

Pero cuando se ponen a hacer la tarea en cuestión, los desarrolladores caen en la cuenta de que uno o más de los supuestos que habían pensado estaban equivocados, o que para usar la librería que querían usar implica que no pueden usar la versión de una librería que están usando ahora, y tienen que usar una nueva librería distinta de la versión actual, lo que implica volver a programar todo el código que hace uso de esa librería (nada de esto tiene que ver con el trabajo que tú habías solicitado, si te fijas)  y luego ponerse con la tarea encomendada, para luego darse cuenta de que algo que pensaban que podían usar ahora se ha quedado obsoleto y ahora necesitan encontrar otra librería que luego tienen que volver a valorar para ver si es compatible con el código que tienen montado ahora…

Todo este proceso se va haciendo cada vez más complejo en el momento en que un supuesto mal asentado de base resulta ser equivocado. Al principio todos los supuestos parecen tener lógica y aparentemente están bien planteados, pero cuando te metes a programar es cuando puedes aseverar al 100% que todo va a salir según lo previsto.

La técnica del descargo de la responsabilidad

Los mejores programadores con los que he trabajado empiezan a establecer sus previsiones y estimaciones de tiempo de trabajo en torno a fórmulas de descargo de responsabilidad del tipo: “si damos por cierto X, entonces…” 0 “si algo no funciona como está documentado…” y cosas parecidas. Saben, por experiencia, que siempre hay algo escondido, al acecho, en las profundidades como un oso polar que sorprende a la foca para devorarla. Y por ello preparan al cliente que les paga las aplicaciones en consecuencia, mentalizándolo de que estas cosas suelen pasar de forma inevitable.

Los programadores menos experimentados, llenos de confianza en si mismos tanto a la hora de programar, como a la hora de pensar que saben todo lo que tiene que hacerse y dando a entender que lo tienen todo bajo control, son menos cautos y caen en el “sí, claro, eso me toma una semana”. Pues aveces sí, tienen algo de presupuesto y pueden tapar los problemas que surgen de temas inesperados, pero muchas otras veces no, y se meten en un problemón con el cliente y con la empresa para la que trabajan.

Conclusión: hay que saber traducir lo que dice un programador

Conclusión, hay que saber traducir. Si un programador dice “eso no se puede hacer”, casi siempre lo que quiere decir es “ni de broma voy a poder hacer eso dado que mi forma de percibir intuitivamente las limitaciones operativas reales con las que me tengo que desenvolver en la empresa, y es tan difícil explicarte todo esto, que me va a explotar la cabeza. Vete. Lejos.”

Si eres el jefe de proyectos y recibes muchos “eso no se puede hacer”, es hora de volver a evaluar no solo tus expectativas, sino el entorno de trabajo en el que están los programadores a tu cargo. No hay suficientes, no tienen suficientes recursos, les estás exigiendo demasiado en cosas que no les permite avanzar en tareas fundamentales -algo está fallando…

En vez de poner cara de frustración e incredulidad, enfoca el asunto con un “Vale, ¿y que podemos hacer para que esto sea posible de hacer?”. Llegarás mucho más lejos, y con un poco de suerte podrás corregir la deriva de un barco que va hacia el naufragio.

Nota: este texto es de Stan Hanks, ingeniero de software, y lo publicó originariamente en Quora.

 

 

 

Este artículo Cuando un desarrollador dice: “Eso no se puede hacer…” es original de Velneo.

Demasiado bonito para ser cierto

¿Donde están los clientes de Velneo? ¿Que tipo de empresas son? ¿Que clase de proyectos llevan a cabo? ¿Que opinan de Velneo?

Miguel Pérez nos hace un repaso en profundidad, intentando responder a estas y otras preguntas que probablemente se hacen muchos de los miles de desarrolladores que cada mes se acercan a descubrir Velneo. En el siguiente vídeo nos explicará que es lo que aporta Velneo a sus clientes, que barreras se pueden encontrar aquellos que se plantean el cambio a Velneo y, principalmente, que opinión tienen de Velneo aquellos que ya han dado el salto y disfrutan ya de Velneo a pleno rendimiento.

Este artículo Demasiado bonito para ser cierto es original de Velneo V7.

Agenda con Calendario

Esta Open App te permite gestionar una agenda con las siguientes características:

  • Al heredar de vBase permite la gestión de tareas por usuario.
  • Contempla la agrupación de proyectos/fase por iteración.
  • Permite la gestión de tareas por proyecto.
  • Contempla la división de proyectos en fases que se organizan por iteraciones.
  • Las proyectos, fases e iteraciones disponen de estado.
  • Las tareas pueden estar pendientes o completadas.
  • Todos los registros incluyen un campo objeto texto para observaciones.
  • Las tareas pueden tener tareas hijas.
  • Es posible generar tareas repetitivas por un período de tiempo.

Incluye opciones para consultar:

  • Las tareas para hoy (Ejemplo QML).
  • Las tareas día a día (Ejemplo QML).
  • Las tareas de la semana.
  • Las tareas  completadas.
  • Las iteraciones.
  • Los proyectos.
  • Las fases.
  • Las tareas por usuario (Ejemplo de herencia inversa).

Además incluye dos ejemplos de QML sin conexión a datos Velneo:

  • La imagen de portada con múltiples colores y movimiento.
  • El reloj de las vistas de tareas para hoy y tareas día a día.

En el siguiente vídeo verás como se puede reutilizar el QML usado en esta Open App para utilizarlo en tus aplicaciones.

 

 

Programar con abreviaturas

Una de las decisiones más importantes que deben tomarse cuando se comienza a desarrollar con una plataforma es la nomenclatura que daremos a los identificadores de los diferentes elementos que debemos crear para el desarrollo de nuestras aplicaciones.

Las nomenclaturas alcanzan a todos los ámbitos de la programación ya que es conveniente tener reglas para nombrar de forma clara y precisa desde una carpeta del disco donde almacenaremos nuestro solución hasta la variable local más insignificante.

Una buena nomenclatura proporciona grandes beneficios:

  • Facilita la comprensión clara del concepto.
  • Evita ambigüedades.
  • Facilita la organización.
  • Facilita la localización.
  • Facilita el mantenimiento.
  • Permite la comprensión de otros desarrolladores.
  • Reduce el tamaño de los identificadores.

Todas estas ventajas están muy bien, sin embargo, cuando empezamos a trabajar con un nuevo lenguaje no siempre es sencillo saber qué nomenclaturas debemos utilizar. Me gustaría aprovechar este artículo para indicar 3 recomendaciones sobre el uso de nomenclaturas en Velneo V7.

1ª) No tengas 2 proyectos con el mismo nombre

Cuando creamos una solución desde el asistente y nos pide el nombre de los proyectos de aplicación y datos, podemos tender a darles el mismo nombre. En principio parece lógico ya que son de diferente tipo y cada uno cumple una función específica. Sin embargo, no debemos obviar que existen objetos que pueden ser creados en ambos proyectos (procesos, funciones, búsquedas, esquemas, etc.) Si no tenemos la precaución de darles un nombre diferente nos podemos encontrar con un objeto llamada [email protected]. Y entonces es cuando comienzan tus problemas para discernir de qué objeto se trata y donde puedes encontrarlo, este mismo ejemplo lo puedes aplicar a cualquier circunstancia en la que tengas que trabajar a nivel del proyecto Gestion, que no podrás identificar si es el de aplicación o el datos. La recomendación que te hago es de añadir un prefijo o sufijo a tus nombres de proyectos donde identifiques el tipo. En nuestro ejemplo podríamos crear GestionApp y GestionDat, lo que supondría que la búsqueda anterior tendría como identificador [email protected] o [email protected], lo que no daría lugar a dudas.

2ª) Usa abreviaturas en los identificadores de objetos

Nadie duda de que es más sencillo leer y entender el identificador CLIENTES que el identificador CLT. Sin embargo esa ventaja inicial se puede volver en nuestra contra en proyectos de envergadura.

Hay que tener presente que no sólo usan identificadores las tablas, también tenemos que usarlos en los objetos visuales y, es práctica habitual los objetos visuales contengan en su identificador la tabla origen del mismo. Esto pueden generar identificadores realmente largos.

Identificadores largos

Pros

  • Fácil comprensión.

Contras

  • Mayor tamaño de nuestro código.
  • Identificadores cortados en propiedades.
  • Identificadores compuestos muy largos.

Identificadores abreviados

Pros

  • Menor tamaño en nuestro código.
  • Identificadores que se ven completos en propiedades.
  • Identificadores compuestos cortos.

Contras

  • Requiere más conocimiento para su comprensión.

Vamos a ver un ejemplo en ambos casos:

Nomenclatura sin abreviar

  • Tabla: CLIENTES
  • Búsqueda: CLIENTES_NOMBRE_SIN_FORMULARIO
  • Identificador compuesto: [email protected]

Nomenclatura abreviada

Si ahora te imaginas estos identificadores en el árbol de propiedades comprenderás que sin abreviar, la mayoría de los identificadores de objetos no estarán visibles de forma completa salvo que trabajes con una resolución de pantalla muy elevada. Además, tus fórmulas serán más largas y más complicadas de escribir.

 

Cuando desarrollan varios programadores en un equipo de trabajo el uso de nombres largos completos suele llevar a la ambigüedad algo que se puede evitar con el uso de abreviaturas, eso sí, siempre que las abreviaturas estén  documentadas.

3ª) Usa un diccionario de abreviaturas

Como se comenta en la recomendación anterior, para que el uso de abreviaturas sea válida debe ir acompañada del uso de un diccionario de abreviaturas.

En Velneo utilizamos la Open App vEstandar para documentar nuestras normas de programación y también las abreviaturas a usar por lo desarrolladores. En la ficha de la Open App también encontrarás los documentos PDF correspondientes a dicha información.

Te recomiendo que utilices esta Open App o una aplicación similar a la que todos los desarrolladores tengan acceso para buscar, consultar y crear nuevas abreviaturas. Es importante ser estrictos en el uso del diccionario para evitar duplicidades o errores en el código.

Entra en escena, Livecode 5.0

Livecode LogoHace mucho ya hablé de Livecode, aunque al parecer, la entrada se perdió en el cambio de blog. La idea de escribir esta entrada, es porque estamos evaluando de nuevo esta herramienta, muy seriamente, para adoptarla para migrar nuestros proyectos actuales, y basar en ella los futuros, sobre todo, tras la salida de la nueva versión 5, que incluye soporte para Android.

Sí, ya sé que soy impulsivo, y que cambio de lenguaje como quien cambia de camisa, pero las decisiones que suelo tomar, siempre suelen basarse en algún tipo de fundamento, y siempre va acompañado de un análisis del mercado. En Komenco nos encontrábamos desarrollando “felizmente” bajo Velneo. Una herramienta que nos gusta mucho, de una empresa española, con una comunidad envidiable respecto a otras plataformas de desarrollo, y con una filosofía basada en cloud más que interesante. Pero ciertas reuniones con clientes, han hecho que surjan distintos proyectos nuevos, que nos han obligado a plantearnos la posibilidad de migrar los proyectos ahora, antes que sea demasiado tarde.

 Antecedentes

Por un lado, nos han surgido proyectos de movilidad, bajo Android e iPhone. Velneo ha sacado en su nueva versión v7.8 un cliente beta para Android (para niveles 3 y 4), que además de ser Beta, requiere de conexión con el vServer para funcionar. La idea no es mala,  todo lo contrario, pero no nos sirve. Nosotros requerimos que nuestras aplicaciones funcionen autónomas del lado del cliente, y luego sincronicen con el servidor, y además, para iOS no ha salido nada y no se sabe tampoco si está en planning o para cuando. Existiría la posibilidad de montar la aplicación sobre Tablets con Windows XP/7, pero entonces obligaríamos al cliente a migrar sus dispositivos, cuando muchos de ellos ya disponen teléfonos Android. También existe la posibilidad de montar las aplicaciones de movilidad sobre PhoneGAP, y que comuniquen con la aplicación Velneo por sockets, pero entonces estamos diversificando, y el equipo requiere el doble de conocimiento para mantener dos aplicaciones en dos lenguajes distintos, algo, que en Komenco, acabando de comenzar, no nos podemos permitir, y más aún cuando mi filosofía es, siempre y cuando sea posible, usar el mismo lenguaje “para todo”.

Por otro lado, el cliente también nos han pedido que requieren una pequeña intranet web que ellos mismos pudieran ampliar y modificar. También podría desarrollarse perfectamente en Velneo, con el módulo vModApache, pero que exista vModApache no implica que Velneo sea una herramienta para desarrollar web (ya que no lo es), y por último, los datos deben ser cómodamente gestionados por un DBA e integrados con otras herramientas y por todos es sabido que la BBDD de Velneo es cerrada, y se requieren herramientas propias de Velneo, o tirar de ODBC para poder acceder a los datos, sin contar, que Velneo no es una herramienta pensada, que no quiere decir que no pueda, con otras BBDD. Tema vetado.

Por supuesto, el entorno que elijamos, debe estar totalmente respaldado por una empresa consolidada.

Alternativas

Tras darle muchísimas vueltas al asunto, nos encontrmos con distintas opciones viables.

  • Windev, WebDev y Windev Mobile de la empresa PCSoft.
  • RealStudio de la empresa RealSoftware.
  • Livecode de la empresa Runrev LTD.

Seguramente existan muchas otras herramientas existentes, pero de todas las que se estuvieron estudiando, estas tres, fueron las que más nos gustaron.

WinDev/WebDev/WinDev Mobile

Windev ya lo conocemos. Ya he programado en WLanguage, y es una herramienta muy potente, además de disponer en la actualidad de licencias de V15. Tras navegar un buen rato por internet, y acordarme de haberlo usado en el pasado, decidimos descartarlo. Por un lado por el tema económico, del que hablaré más adelante. Las principales razones por la que se descartó, fué que la Suite de PCSoft, sólamente corre en Windows. Los desarrolladores deben programar forzosamente desde Windows, y además, sobre un IDE bastante pesado e inestable. En el pasado ya me hizo alguna que otra jugarreta, y no fué en un proyecto precisamente grande. Además, las indagaciones por internet no han sido muy satisfactorias. Me he encontrado con una comunidad bastante quemada, quejándose de, inestabilidad, cantidad ingente de novedades que se presentan a bombo y platillo tras un año sólamente de la aparición de la versión anterior, y además, de las cuales, novedades sólo son una cuarta parte, y de ahí, habría que eliminar las que no funcionan, o estan mal implementadas.

RealStudio

Realstudio era otra alternativa. Me gustaba la simplicidad del lenguaje (a pesar que no me guste Basic, pero ésto es otro tema) que no restaba potencia a la herramienta. IDE que funciona en Windows/Mac/Linux, con deploy nativo en Windows/Mac/Linux, y con un modo Web Edition, que permite generar aplicaciones CGI para correr en la web, como si fuera una aplicación de escritorio. Pero algo fallaba, y ese algo, era la movilidad. RealStudio, actualmente no tiene ninguna solución para movilidad, salvo el Web Edition. Diréis que al fin y al cabo, los terminales si tienen conexión a internet, pueden trabajar perfectamente sobre una Web, pero recordar, que uno de los requisitos, es que pueda trabajar desconectado. Existen muchas razones que pueden provocar que el dispositivo móvil, por alguna u otra razón, no tenga cobertura, se caiga la red, mil razones, que no queremos que puedan interferir en el trabajo de nuestros clientes, ya que, si no hay cobertura en cierto lugar, la responsabilidad, no sería del operador, si no nuestra por no tener prevista una solución ante ésta situación. Para mantener conexión constante, hubiéramos continuado con Velneo, con el que relativamente, estábamos bastante contentos. Existía la alternativa de usar Realstudio + PhoneGAP. Esta solución no me terminaba de desagradar. Los proyectos Web y Escritorio podríamos afrontarlos con RealStudio, y PhoneGAP para movilidad (mucha movilidad, ya que PhoneGAP funciona en muchas plataformas), pero entonces, me acordé de Livecode y la belleza de su lenguaje…

LiveCode

Livecode era la última alternativa. A finales de 2010, ya fué una herramienta que estuve “estudiando” para basar nuestras soluciones, y sinceramente, la única razón por la que no acabé comprándola, fueron unos problemas en el pago de la solución. Por aquel entonces, disponía de una tarjeta Maestro, pero necesitaba una tarjeta Mastercard/VISA que me permitiera realizar la compra, y el intentarlo desde una transferencia bancaria internacional (la sede de Runrev se encuentra en Edimburgo) no fué satisfactoria. Podría haberme esperado al Lunes, y haberla hecho desde mi banco, pero mi impaciencia de aquel entonces hizo que lo descartara (lo sé, soy impulsivo, ya lo dije, pero he madurado) y me decantara al final por Velneo (hecho, que por cierto, no me arrepiento para nada, si no fuera por la prisa que me corre ahora).Livecode corre sobre Windows/Mac/Linux, y despliega en Windows/Mac/Linux. Para movilidad permite generar aplicaciones para iOS y Android, y para web, permite generar una aplicación que corre directamente en el navegador a través de un plugin propio, o bien instalar el RevServer (que es un CGI) para poder programar en scripting como hace PHP, mezclando HTML y código Livecode. Livecode tampoco es que sea perfecto. El plugin para web no está actualizado (aunque de todas formas no pensábamos usarlo), el despliegue para Android al parecer tiene alguna carencia aún, y Runrev tiene una política al parecer bastante curiosa con el licenciamiento de actualizaciones de sus productos hacia  nuevas versiones. Pero su lenguaje (me quiere sonar que se llama Transcript)su manera de trabajar, me llamaba demasiado la atención.

Conclusión

Tras perder una semana, como habréis podido imaginar por el título de la entrada, nos hemos decantado por Livecode por diversas razones.

Despliegue

Livecode nos permite programar desde Windows, Mac y Linux pudiendo hacer despliegue de la aplicación en Windows, Mac, Linux, iOS, Android, y Web, pudiendo abarcar con la misma herramienta los proyectos con sus requerimientos que tenemos actualmente, así como cualquier solución que se nos pueda presentar.

Lenguaje

Transcript es un lenguaje de programación “bello“. Escribir, mantener código, e incorporar nuevos desarrolladores, es totalmente entendible por otros programadores debido a que se programa como si estuvieras escribiendo inglés. No sé explicarme correctamente, por eso os pego un ejemplo de código.

De serie, trae funciones para todo tipo de necesidades, y si algo faltara, puede implementarse, o bien directamente en Livecode, o usando externals. Una

on mouseUp
put “Hello World!” into field 1
pass mouseUp
end mouseUp

De serie, trae funciones para todo tipo de necesidades (XML, sockets, bases de datos,manejo de archivos comprimidos, etc..etc..etc..), y si algo faltara, puede implementarse, o bien directamente en Livecode, o usando externals. Un detalle, es, que LiveCode, está escrito en LiveCode, eso ya dá un indicio de la potencia del lenguaje.

Versatilidad

LiveCode es una herramienta multipropósito. Podemos afrontar, no sólo aplicaciones empresariales, si no también contenido multimedia, juegos, etc… Además, todo el entorno, al estar construido sobre Livecode, tenemos acceso a él y podemos “alterarlo” a nuestras necesidades. Es programación basada en eventos, donde objetos interactúan unos con otros mandándose mensajes que recorren el message path“siguiendo una jerarquía, y que nosotros podemos capturar, dándonos un control absoluto del entorno. El control DataGrid, sin ir más lejos, no es un control como tal. Es un grupo de controles, agrupados (valga la redundancia), con un comportamiento ya programado que nos hace tener la impresión que es un único control, pero podemos desagrupar, controlar totalmente su comportamiento para nuestras necesidades, y volver a agrupar, obteniendo a partir de ahí un control totalmente distinto. Si, sé que no es nada nuevo, y que ésto existe desde hace eones, pero la facilidad con la que podemos tratarlo, si que no la he visto en otros lenguajes. Además, en LiveCode no hace falta “editar/compilar/depurar”. Cuando trabajamos sobre una stack ésta se está ejecutando en ese mismo instante, pudiendo controlar y modificar en todo momento el comportamiento de la aplicación a tiempo real.

Potencia y estabilidad

Para finalizar, lo que más me ha gustado de LiveCode. Es el conjunto de potencia y estabilidad. El IDE es muy muy ligero y estable, apenas enterándose el ordenador que tiene un completo entorno de desarrollo funcionando en ese momento, y las aplicaciones generadas son rápidas como un rayo. Si, es cierto, que a los 15 minutos llegué a colgar el IDE, pero también hay que admitir que fué culpa mía por tocar donde no debía y sin saber.

Finalizando

Como siempre he dicho, cada programador tiene unas necesidades, y el entorno de programación debe amoldarse en la medida de lo posible a éstas, así como el programador debe poner de su parte, ya que cada entorno tiene sus peculiaridades. LiveCode no es una excepción. Tendrá sus defectos, como todos, ya que no existe la herramienta perfecta, pero tras el estudio que hice en su momento, más el actual, diría que LiveCode es la herramienta que mejor se amolda actualmente a nuestras necesidades.

Para quienes les haya picado la curiosidad, en su web (que se encuentra, hoy 22/10/2011 a las 12:00 caída por un problema en sus servidores), podéis descargar un Trial para probar la herramienta, y creo que todos los Sábados se realiza un evento por streaming llamado LiveCode.tv Event donde programadores en LiveCode exponen sus proyectos y curiosidades. En estos eventos, los ponentes se comunican con los observadores mediante una aplicación llamada ChatRev, precisamente desarrollada en LiveCode.

Me gustaría enlazaros a una parte del primer LiveCode.tv Event que ví (de 1 hora de duración), donde Bjoernke, un experimentado programador en LiveCode, está mejorando un pequeño Generador de consultas SQL, y desarrollando modificaciones en tiempo real que le van pidiendo por ChatRev, mostrando la potencia que tiene este entorno. Por cierto, Bjoernke es un cachondo, no dejéis de revisar su canal de UStream.

Compartir tablas entre distintas aplicaciones

En Velneo 6.x es posible declarar la mismas tablas en dos proyectos ( mapas ) y que las dos aplicaciones trabajen sobre dichas tablas. El desarrollador debe tener mucho cuidado que la estructura de las tablas sea la misma en las dos aplicaciones y así evitar errores en el acceso a los datos por parte de las aplicaciones debido a tener dos estructuras distintas.

En Velneo V7 para resolver este escenario se recomienda que las dos aplicaciones compartan un mismo proyecto de datos donde se declara una única vez esas tablas comunes. Esta forma de trabajo es mucho más útil y nos ahorraremos preocupaciones en las modificaciones de nuestras aplicaciones. Todas las modificaciones realizadas sobre nuestro proyecto donde están definidas las tablas beneficia instantáneamente a todas las aplicaciones que usen dicho proyecto.

En Velneo V7 también es posible que dos proyectos distintos compartan la misma tabla, siendo esta definida en esos dos proyectos exactamente igual. Esto obliga al desarrollador a mantener las declaraciones de las tablas exactamente iguales en los dos proyectos.

El la versión 7.5 se ha añadido un control interno en Velneo vServer V7 para que certifique que la definición de las tablas son iguales cuando están siendo utilizadas por dos instancias (proyecto en ejecución) distintas. Esta funcionalidad permite que el sistema alerte ante estas situaciones que pueden complicar el mantenimiento de las aplicaciones que comparten tablas.

Desde Velneo recomendamos el uso de la compartición de instancias entre aplicaciones que ofrece muchas más posibilidades y evita problemas de mantenimiento.

Herencia de proyectos y esquemas de soluciones

El 13 de Noviembre de 2009 se celebr en el saln de actos del Parque Tecnolgico de Gijn el Seminario con Juan Muoz-Cobos.

El vdeo que puedes ver a continuacin corresponde a un fragmento de la ponencia de Juan Muoz-Cobos en el que explica la arquitectura de soluciones y proyectos, el editor de esquemas y da recomendaciones de cmo abordar un proyecto y de cmo hacer desarrollo colaborativo en equipo.