¿Es esta tu situación?

• 1. Programo con Visual Basic, Visual FoxPro… soy consciente de que está descontinuada, pero cambiar lo veo muy costoso para mí.
• 2. Las alternativas que se me presentan son .Net o Java, lo he intentado pero…
• 3. Cada vez tengo más peticiones de aplicaciones en remoto, en móviles o accesibles desde la Web, pero son mundos diferentes.
• 4. Ahora empiezo a oír hablar del Saas y el Cloud Computing y creo que me va a complicar más.
• 5. Me entran ganas de limitarme a distribuir un ERP o software de otros, pero eso tiene otros problemas

¿Evaluaste alguna vez Velneo 6.x como alternativa?

Una plataforma de la que no vamos a descubrir ahora sus virtudes que nació hace ya 15 años, que la mayoría ha descubierto en los 3 últimos gracias a Velneo. Muy probablemente no justificaba por si sola el cambio que representa para ti o quizás le encontrabas algunos peros…

Continuar leyendo… "Es el momento del cambio"

Etiquetas: formacion, formacion presencial, foxpro, V7, Velneo V7, Visual Basic, Visual FoxPro

Éste es un pequeño repaso a los cambios más importantes que ha sufrido el blog de Velneo las últimas semanas:

Continuar leyendo… "Novedades de Velneo en la web"

Etiquetas: cambios, foro, Velneo, Velneo 6.x, Velneo V7

Por si no está clara contestación a este pregunta Domk nos da su punto de vista.

“Si necesitas multiplataforma, multiprocesador, balanceo de carga sin artificios, y desarrollos a nivel mundial multilenguaje con cientos o miles de usuarios atacando simultaneamente la bd desde el vClient, esperate”

Leer más

Etiquetas: Velneo V7

¿Trabajas de analista? ¿En tu trabajo tienes que fijar las normas sobre las nomenclaturas de las bases de datos y los objetos visuales?

Alguno puede pensar que este es un problema menor, pero este tipo de decisiones suelen ser complejas. Sabes que cualquier error en el análisis supone un montón de horas de reprogramación. Sobre todo porque habitualmente las plataformas de desarrollo no te permiten hacer cambios drásticos de forma sencilla o al menos sin riesgos.

La independencia entre base de datos y lenguaje de programación tiene múltiples ventajas, pero también múltiples inconvenientes y este precisamente es uno de ellos. No es rápido, ni seguro y en muchos casos tampoco sencillo poder modificar el identificador de cualquier tabla, campo, índice u objeto visual sin asumir riesgos.

Copiar y pegar es un recurso que todos los programadores empleamos, pero también sabemos que este es un de los mayores orígenes de errores en los programas. De la misma forma usar la opción buscar y reemplazar suele ser muy arriesgada.

Continuar leyendo… "Identifícate y no cambies, por favor"

Etiquetas: multi-idioma, Velneo V7

En V7 el código se organiza en cajas que a su vez se distribuyen en soluciones. Podemos definir una solución como una ubicación física en la que guardamos las cajas, que son ficheros contenedores de código fuente. Las soluciones pueden estar ubicados localmente, en el disco duro del ordenador en que estás trabajando, en un servidor de tu red local o en un servidor remoto al que accedes a través de Internet.

vServer: El servidor de edición
Una de las grandes novedades de V7 es el servidor de edición, vServer aporta importantes ventajas:

- Es un servicio o demonio por lo que no requiere tener una sesión abierta de un usuario ni interfaz gráfico. La administración remota del servidor se realizará con la aplicación vAdmin.

- Trabajo en equipo. El bloqueo se realiza por caja, cada caja puede ser editada por un programador, pudiendo el resto del equipo tener heredada la caja y trabajar con todos los objetos de la misma. Además cualquier modificación realizada en la caja será refrescada a todos los programadores que la tengan heredada.

- Edición centralizada con control de acceso al código fuente. El código fuente estará en el servidor no teniendo necesidad de dar permisos de disco a los programadores. Además cada programador podrá ver y editar las cajas de las que tenga permisos, de esta forma se puede controlar quien tiene acceso a todo el código fuente de un proyecto.

- Si instala el servidor de edición en su cliente final, podrá editar el código fuente directamente contra su servidor, pudiendo hacer cambios en caliente sin necesidad de enviarle instalaciones o versiones actualizadas de su aplicación.

- El servidor de edición además será capaz de crear instalaciones para implantar un proyecto en otro servidor de ejecución.

Organizando los proyectos en soluciones
En el servidor de edición de una empresa de desarrollo será muy habitual tener un gran número de proyectos y en cada uno de estos proyectos un importarnte número de cajas. Por este motivo con V7 cobra gran importancia una buena organización, y para tenerla contamos con las soluciones.

Será muy habitual tener una solución por cada proyecto.

También podrá ser habitual que cada programador tenga su solución particular.

No debemos olvidarnos de que los permisos sobre las cajas y su contenido los otorga la solución en el que se encuentre la caja, por ese motivo una caja ubicada en una solución común para todos los programadores del proyecto permitirá editarla a ese equipo, mientras que esa misma caja movida a la solución de un programador donde sólo él y los administradores tengan acceso sólo permitirá a estos editar el contenido de la caja.

Las soluciones también tendrán control de permisos de traducción para permitir a los traductores acceder a las cajas, pero sólo para la traducción de los textos al idioma correspondiente.

Soluciones compartidas
Una caja puede heredar múltiples cajas y cada caja debe estar ubicada en una solución conocida. Cada solución como se puede apreciar en la ventana de creación de una solución, tiene una propiedad denominada “compartido” que podremos activar a todos las soluciones que creamos oportuno, en principio a los que contegan cajas a reutilizar en otros proyectos, es decir, heredadas por otras cajas.

Otra importante ventaja de las soluciones compartidos, es que durante el desarrollo y posterior instalación de un proyecto las cajas pueden variar su ubicación. El gestor de cajas del servidor es capaz de localizar una caja tanto en su ubicación original como en cualquier de las soluciones compartidas a donde puede haber sido movida por motivos de organización.

El resultado final es que podremos tener perfectamente organizados nuestros proyectos y sus cajas así como compartir las cajas a heredar por otras cajas de la misma solución o de otras.

Una nueva arquitectura
Servidor de edición, soluciones y cajas son tres conceptos que se unen para crear la nueva arquitectura de desarrollo propuesta en V7.

Etiquetas: arquitectura, servidor de edición, solución, soluciones, Velneo V7, Velneo vServer

En V7 aparece el revolucionario concepto de caja. En este artículo vamos a analizar el aspecto práctico de las cajas y las relaciones de conocimiento, obtenidas a través de la herencia, que se establecen entre ellas y como nos afecta a nuestro estilo de programación.

Cajas
Una caja es un fichero contenedor de código fuente V7.

Es probablemente la novedad más importante a nivel de análisis y programación de V7. Hasta ahora nuestros proyectos tenian el handicap de la modularización y de la integración de mapas, es decir, se programaba sobre un único fichero y en caso de programar en equipo, al final era preciso unir en un sólo mapa todo el código generado.

Existen 2 tipos de cajas en V7, de datos y de objetos.

Cajas de datos
Podemos asociar el concepto de caja de datos a lo que hasta ahora era la parte izquierda del Edmap:

- Tablas.
- Tablas estáticas.
- Variables globales.

Cajas de objetos
La caja de objetos equivale a la parte derecha del Edmap:

- Carpetas.
- Objetos visuales.

Antes de V7, después de V7
Con la versión actual, antes de V7, nuestros desarrollos son monolíticos, es decir, una aplicación (.map) es equivalente en el nuevo sistema de cajas a:

- Una sola caja de datos y
- Una sola caja de objetos.

Sin embargo, a partir de V7 podremos tener tantas cajas de datos y de objetos como queramos. El servidor de edición se encargará de gestionar las cajas y de controlar los bloqueos en su edición.

La herencia aporta la relación de conocimiento
Las cajas no son entidades aisladas. Entre ellas se pueden establecer relaciones de conocimiento, a través de la herencia, que permiten a la caja usar los objetos de la caja conocida y, por lo tanto, usar dichos objetos de forma directa.

Un ejemplo:

1.- Cuando una caja “A” hereda a otra caja “B”, pasa a conocer todos sus objetos.

2.- Desde ese momento en la caja “A” se podrán usar todos los objetos de la caja “B” como si estuviesen declarados dentro de la caja “A”.

3.- Una caja puede ser heredada por muchas cajas que reutilizan su código. En nuestro ejemplo la caja “B” también puede ser heredada por la caja “C”.

4.- Una gran ventaja de la herencia es que los objetos sólo existen en la caja “B” y, de esta forma el mantenimiento de los mismos será mucho más sencillo, cualquier cambio en un objeto de “B” será reflejado directamente en “A” y en “C”.

Conocimiento inverso: Las relaciones de histórico son dinámicas
En un mapa de la versión 6.x o anterior las relaciones de histórico se creaban entre tablas que debían estar incluidas en el mismo mapa.

En V7 las cajas de datos pueden heredar otras cajas de datos. Y en cualquier tabla se puede crear un relación de maestro contra otra tabla de su propia caja o de otra caja heredada.

¿Qué pasa con las relaciones de histórico?

Pensemos que el programador que ha creado las tablas de la caja heredada no sabe ni que cajas la van a conocer ni que tablas tendrán enlaces a alguna de sus tablas. Además hoy puede estar siendo heredada por una caja y mañana por varias, cada una con sus tablas y enlaces.

¿Cómo tener actualizadas en todo momento las relaciones de histórico en la caja conocida?

Muy sencillo, el programador no tiene que hacer nada ya que el gestor de cajas del servidor de edición es capaz de crear dichas relaciones, tanto en tiempo de edición como de ejecución cuando usamos la caja. Es decir, el gestor de cajas analiza todas las relaciones de las tablas entre las cajas conocidas y crea dinámicamente la relaciones de histórico.

Conocimiento recíproco
Si una caja “A” hereda la caja “B”, ¿Puede la caja “B” a su vez heredar la caja “A”?

La respuesta es SÍ.

Será habitual que en una aplicación modular, por ejemplo, en una aplicación de gestión comercial se pueden crear los módulos de ventas y compras en la cajas vVentas y vCompras.

Será habitual tener funcionalidad del tipo: “Desde el pedido de ventas tengo que poder generar uno o varios pedidos de compra”. Para hacer esto en V7 la caja vVentas deberá heredar la caja vCompras, una vez creado el conocimiento, en el formulario de pedido de ventas podremos añadir un botón que muestre el formulario de alta de un pedido de compra.

Pero también quiero desde el pedido de compras poder ver el pedido de ventas que lo originó, esto es posible gracias al conocimiento recíproco que nos permite que vVentas también pueda ser heredada por vCompras y por lo tanto se pueda, desde el formulario de pedido de compra, lanzar el formulario de pedido de venta al que está enlazado.

Lo más importante es que todo se puede hacer desde 2 cajas distintas: Sin código duplicado, con la posibilidad de reutilizar dicho código desde otras cajas y sabiendo que cualquier cambio que haga en estas cajas se reflejará de forma automática en todas las que la conocen.

En el próximo artículo sobre la herencia en V7 hablaremos de la alteración de objetos heredados, que nos permitirá además del conocimiento y el uso la personalización de los objetos que sean configurados como heredables.

Los objetos ahora tienen nombre y apellido
Todo lo que se ha contado en este artículo es posible debido a que el gestor de cajas conoce todas las cajas con un identificador único y todos los objetos contenidos dentro de una caja vienen definitidos por:

- El identificador de la caja (nombre) +
- El identificador del objeto (apellido)

Esto garantiza que dos cajas distintas pueden tener un objeto con el mismo identificador, sin que esto produzca ningún conflicto, ya que cada objeto es distinto para el gestor.

Termino con el que esperamos sea el lema de los programadores de V7
CON V7… TODO EN-CAJA.

Etiquetas: cajas de datos, cajas de objetos, conocimiento, Velneo V7

Una de las mayores novedades que encontraremos en el nuevo servidor de aplicaciones de V7 será, sin duda, el servidor de edición, pero esta no será la única gran novedad.

En los próximos días los betatesters dispondrán de la primera beta que incorpora la funcionalidad de servidor de edición, esto permitirá compartir la experiencia de programar en grupo a un número elevado de programadores.
Esta es una de las novedades de este nuevo servidor V7, al que debemos quitarle el apellido “de aplicaciones” que tuvo su hermano anterior, ya que en realidad se trata de un multi servidor, algo que ya lo era con la tecnología Velázquez Visual.

La primera gran novedad de vServer será la ausencia del interfaz gráfico que lo caracterizó hasta la versión actual. No se trata de una renuncia, sino de un paso adelante. Es cierto que era cómodo disponer de un interfaz en tiempo real para la administración y control del servidor, pero no es menos cierto que las desventajas eran importantes: Pérdida de rendimiento, imposibilidad de gestionarlo como un auténtico servicio y carencia de administración remota. En este apartado no ha habido ninguna duda, vServer será un servidor sin entorno gráfico obligado por la multiplataforma que además será suministrado como un servicio en todos los sistemas operativos y que mediante un cliente “vAdmin” podrá ser administrado tanto local como remotamente de forma transparente, y por si esto fuera poco, además se beneficiará de un notable aumento de rendimiento.

vServer además sufrirá una importante optimización al reducirse con el nuevo diseño el número de sockets necesario para la mayoría de los comandos que gestiona.

Aunque todas las novedades comentadas hasta ahora son muy importantes, sin lugar a dudas la más importante por la funcionalidad que aporta es la de convertirse en un auténtico servidor de edición, capaz de servir las cajas a vDevelop, gestionar las cajas incluso entre servidores y por supuesto ejecutarlas. vServer también controlará los bloqueos de cajas y la seguridad de acceso a las mismas. Los primeros pasos que dará vServer serán precisamente los de servir cajas al nuevo vDevelop.

Etiquetas: Velneo V7, Velneo vServer

En V7 aparece el revolucionario concepto de caja que no existía hasta ahora en nuestra herramienta de programación. En este documento vamos a analizar el aspecto práctico de las cajas y las relaciones de conocimiento o herencia que se establecen entre ellas.

Cajas
Comenzaremos por ver el concepto de caja. Es probablemente la novedad más importante a nivel de análisis y programación de V7. Hasta ahora nuestros proyectos eran monolíticos, es decir, se programaba sobre un único fichero o en caso de programar en equipo al final era preciso unir en un sólo mapa todo el código generado. Existen 2 tipos de cajas en V7, de datos y de objetos.

Cajas de datos
Podemos asociar el concepto de caja de datos a lo que hasta ahora era la parte izquierda del Edmap:
Tablas.
Tablas estáticas.
Variables globales.

Cajas de objetos
La caja de objetos equivale a la parte derecha del Edmap:
Carpetas.
Objetos visuales

Antes de V7, después de V7
Como podemos observar hasta antes de la V7 nuestros desarrollos equivalían a utilizar el nuevo sistema de cajas con:
Una sola caja de datos y
Una sola caja de objetos.
Sin embargo, apartir de V7 podremos tener tantas cajas de datos y de objetos como queramos, el servidor de edición se encargará de gestionar las cajas y la edición de las mismas controlando los bloqueos.

Las cajas no son entidades aisladas, entre ellas se pueden establecer relaciones de conocimiento que permiten a la caja que recibe el conocimiento de otra el uso de todos sus objetos. De esta forma cuando una caja A conoce todos los objetos de una caja B, desde la caja A se podrán usar todos los objetos de la caja B como si estuviesen declarados dentro de la caja A, con la ventaja de que en realidad estos objetos sólo existen en la caja B y, de esta forma el mantenimiento de los mismos será mucho más sencillo a la vez que se permite que una caja pueda ser conocida por muchas cajas que reutilizan su código.

Con la herencia y el conocimiento todo encaja
El mayor avance que llegará con las cajas es la herencia, pero en este documento vamos a centrarnos en las relaciones de conocimiento entre cajas y la reutilización de código que permite esta característica.

En el gráfico se observa como la caja de datos vGestion conoce la caja de datos vBase por lo que las tablas de vGestion pueden tener enlaces directos a las tablas de vBase, por ejemplo desde la tabla Facturas de vGestion se puede añadir un campo puntero a la tabla de Entidades de vBase, pese a que físicamente la tabla Entidades no existe en vGestion y sólo existe en vBase.

Uno de los problemas que se podrían plantear con el uso de cajas es que, siguiendo con el ejemplo anterior, la tabla de Entidades de vBase no tiene conocimiento de que es usada en vGestion y por lo tanto no podría crearse una relacion de histórico con la tabla de Facturas de vGestion, sin embargo el servidor de edición mediante la técnica de conocimiento inverso es capaz de analizar los enlaces entre tablas de diferentes cajas y permite automatizar las relaciones a histórico. Es importante tener claro que:
Una caja de datos podrá conocer a otras cajas de datos pero no cajas de objetos.
Una caja de objetos podrá conocer a otras cajas tanto de datos como de objetos.

Trabajando en equipo gracias al gestor de cajas
Las cajas nos van a permitir una organización de nuestros proyectos adecuada al trabajo en equipo ya que cada programador podrá estar editando una caja diferente sin que existan conflictos debido a que los bloqueos son gestionados por el servidor de edición.

En el gráfico podemos observar como la caja de objetos vCompras recibe el conocimiento de la caja de datos vGestion y de la caja de objetos vBase. Esto permite que desde cualquier objeto de vCompras se use de forma directa cualquier tabla, tabla estática o variable global declarada en el DataBox vGestion y también cualquier objeto visual existente en la ObjectBox vBase.

Será habitual que en nuestros desarrollos nos encontremos con múltiples cajas y que entre ellas se definan múltiples relaciones de conocimiento. Esto que aparentemente puede ser sinónimo de complejidad es sencillo de comprender si vemos al servidor de edición y a su gestor de cajas como si de un mapa antiguo se tratase, ya que el gestor conoce todas las cajas y los objetos contenidos en las mismas, por este motivo cuando declaramos que una caja conoce a otra simplemente estamos activando la posibilidad de que una caja use los objetos de la otra, es lo mismo que ocurre ahora cuando declaramos una relación de histórico en una tabla, en esa declaración no se realiza nada físico, simplemente estamos dando a conocer como se relacionan dos tablas y es a través del uso de esta relación cuando se puede navegar a través de la información, el conocimiento de las cajas es similar, se trata de establecer la relación de uso sin que esto suponga ninguna acción o limitación.

Conocimiento bidireccional con identificadores únicos
Una caja A puede conocer a otra caja B y a su vez la caja B podrá conocer la caja A. Un ejemplo práctico lo encontramos en un programa de gestión, tal y como vemos en el gráfico el uso del conocimiento bidireccional nos permite que desde un pedido de compras podamos mostrar información del pedido de ventas, incluso utilizar los formularios para editar la información y desde el pedido de ventas hacer lo mismo con el documento de compras, todo ello teniendo los objetos visuales definidos una única vez, en su caja correspondiente.

Todo esto es posible debido a que el gestor de cajas conoce todas las cajas con un identificador único y por lo tanto los objetos contenidos dentro de una caja vienen definitidos por el identificador de la caja más el identificador del objeto lo que garantiza que dos cajas distintas pueden tener un objeto con el mismo identificador sin que esto produzca ningún conflicto ya que cada objeto es distinto para el gestor.

Por ejemplo, en las cajas de vCompras y vVentas podríamos tener declarado un objeto formulario para el alta de pedidos y aunque dentro de cada caja el objeto aparentemente se llama igual, a nivel del gestor de cajas el nombre de cada formulario sería:

• OBJECTBOX-COMPRAS.PEDIDO-ALTA
• OBJECTBOX-VENTAS.PEDIDO-ALTA

Etiquetas: cajas de datos, cajas de objetos, conocimiento, herencia, Velneo V7