Velneo bajo lupa
Novedades
Ya tenemos una nueva versión de Velneo, v7.18 está en nuestras manos. Como novedades destacadas tenemos:
- XMLHttpRequest con soporte de binarios
- Procesos en cuarto plano
- Depurador vJavaScript
- vModApache compatible con Apache 2.4 y pequeñas mejoras
- Herramienta de migración de bases de datos SQL
- Nueva clase VSqlDatabase
- Tiempo máximo de expiración de enganches
- Mejoras de usabilidad del vClient, vDevelop y vAdmin
- Tutor con decenas de ejemplos y buenas prácticas
- Mejoras y nuevas funcionalidades en vERP
Hay varias novedades interesantes, aunque desde nuestro punto de vista las dos más importantes tienen que ver con Apache y con XMLHttpRequest. Estas mejoras permitirán abordar proyectos de integración con mayores garantías. Curiosamente son dos novedades que en teoría no tendrían que suponer ningún esfuerzo importante a Velneo (son simples en lo tecnológico y por ende no tendrían que suponer un gran coste). Estratégicamente las dejaron para el final, pregúntense el motivo.
Es de agradecer la incorporación de los procesos 4 plano y el depurador vJavaScript, son también dos novedades importantes. Gracias al trabajo de Velneo podemos tener estas importantes demandas resueltas y otras muchas menores también.
Flaquezas
Respecto a QtQuick 2.0 no hay novedades, seguimos sin soporte en Velneo V7. Como detalle importante, parece que Velneo implementa los nuevos asistentes en QtQuick 2.x apuntando claramente a esta posibilidad.
Seguimos sin cliente para iOS y lo más preocupante, sin noticias al respecto.
Estaría bien alguna referencia por parte de Velneo al cliente para iOS, es un problema importante de negocio no conocer el estado del desarrollo en esta cuestión.
Ya tenemos cuarto plano pero seguimos sin demonios de servidor (aunque tiene fácil solución gracias a vRemoteFunction.exe o Cirrus).
La compilación se sigue basando en Qt 5.3.2 (actualmente Qt está estable en la versión 5.5.1), por lo que poco que decir respecto a las nuevas funcionalidades incorporadas en Qt5 y QtQuick (decenas de ellas muy interesantes a futuro).
¿Qué sigue faltando?
Veamos como siguen las cosas:
Arquitectura:
- No existe versión de 64 bits. En el LIS 2015 se anunció que nos preparemos, que están trabajando en ello (seguramente en la próxima reléase tengamos noticias al respecto).
- Faltan facilidades para la exposición de servicios web (Arquitecturas SOA/WS-*/REST). El vModApache es manifiestamente mejorable.
- No hay soporte para RIA y esto puede ser un problema importante a futuro.
- No existe ningún avance para llevar el vClient a HTML5 (aunque haya proyectos basados en Qt que estén trabajando en varias direcciones).
Movilidad:
- No hay versión para iOS. Sabemos que están trabajando en ello pero no saber roadmap respecto a esta cuestión genera grandes incertidumbres.
- vClient desconectado. Sin cliente desconectado el área de movilidad está totalmente coja. Esperemos que la incorporación de QtQuick 2.x y tiempos de desconexión altos palien el problema.
- El vClient para Android sigue inestable. En este caso el problema es seguramente achacable a Qt pero no deja de ser un trastorno ver continuamente cierres del vClient.
- No hay versión para Android x86 y empiezan a calar en el mercado.
- No hay versión para Linux ARM. El no disponer de versión ARM limita mucho las posibilidades de cara a desplegar v7 en dispositivos embebidos y de bajo coste.
- No hay soporte para BB10. Ya no es importante ya que parece que pronto será otra plataforma en desuso.
Componentes:
- En MacOSX y Android no hay vServer (limita los despliegues).
- ODBC sigue en fase beta y con algunos problemas importantes.
La Nube:
- La API cloud sigue siendo manifiestamente mejorable. No podemos gestionar correctamente las instancias de las aplicaciones y algunas otras funcionalidades requeridas por lo que queda descartada para un uso masivo.
- No hay ejemplos de integración de la API para PHP (estaría bien poder contar con ellos para WordPress, Joombla y otras plataformas ampliamente utilizadas).
Otros problemas:
- La representación gráfica (componentes de representación para gráficos de tartas o similares…). De momento nada de nada y al no incorporar QtQuick 2.x no nos permite ningún nuevo enfoque. HTML 5 es la solución actual para estas cuestiones (con sus pros y contras)
- Algunos bugs sin resolver (revisar vBugman).
- Problemas con los estilos en MacOSX
- Apertura para otras plataformas (Windows Phone y Windows RT)
Percepción del estado de ánimo de la comunidad
Por último quiero hacer mención al estado de ánimo de la comunidad en foros y artículos de blogs:
- http://ayudavelneo.com/has-probado-ya-la-version-7-18-de-velneo-v7/
- http://velneo.es/foros/topic/7-18-velneo/
En general no se percibe un gran descontento con el estado actual de la plataforma (hay gente descontenta, pero ni mucho menos es generalizado). Lo que si se percibe es una preocupación por el ritmo de incorporación de novedades y de mejoras.
- http://velneo.es/foros/topic/vclient-andriod/
- http://velneo.es/foros/topic/mejoras-y-correcciones-de-vdevelop-en-una-sola-idea/
Comparto la preocupación, también tenemos la sensación de que el ritmo de lanzamientos descendió de forma significativa a raíz de la salida del vArquitecto.
Como ya apuntábamos en su momento (https://tipesoft.com/ingenieria-informatica/), “Ningún grupo de trabajo estará a la altura de Juan, por muy buenos que sean los que queden (creo que son pocos), o los que se incorporen en esta nueva etapa”. Juan es ante todo un brillante programador y su salida se está haciendo notar de forma clara en el ritmo, calidad e importancia estratégica de las novedades presentadas.
Rentabilidad de los productos y servicios
Tal vez la única cuestión importante que nos tenemos que plantear a día de hoy es la rentabilidad de Velneo V7. ¿Es económicamente rentable mantener las inversiones en la plataforma Velneo?
Extraído desde https://velneo.zendesk.com/entries/41203938-Comparativa-entre-niveles
Resumiendo… Precios anualizados:
- El Nivel 4 cuesta: 2.880 € al año
- El Nivel 3 cuesta: 1.836 € al año
- El Nivel 2 cuesta: 720 € al año
Nivel 4:
- Dispone de todos los productos y servicios
- Soporte: 10consultas/mes y 4 llamadas anuales de soporte telefónico para urgencias (activación de servidores y programación).
- 20% de descuento sobre el precio de tarifa de componentes y servicios adicionales.
- 20 usuarios de ejecución PaaS
- Edición en Velneo vServers propietarios de clientes
- TCP en servidores cloud
Nivel 3:
- No tiene vTranslator, ODBC
- Soporte: 5consultas/mes
- 10% de descuento sobre el precio de tarifa de componentes y servicios adicionales.
- 10 usuarios de ejecución PaaS
Nivel 2:
- No incluye el vERP
- Soporte: 2consultas/mes
- No tiene descuentos
- 3 usuarios de ejecución PaaS
De todos los productos y servicios ofrecidos en los niveles tenemos que establecer cuales de ellos son importantes para nuestro negocio y decidir mantenernos en el nivel adecuado según necesidades. No es una decisión simple, pero visto el ritmo de desarrollo se hace bastante más sencilla. Tenemos que responder a muchas preguntas, entre ellas… ¿Qué sentido tiene pagar una cuota anual de importe similar a la compra de los productos en una plataforma madura como Velneo? ¿Justifican los servicios y descuentos ese precio? ¿La demanda y márgenes de beneficio compensan el nivel de inversión? ¿Es momento de ajustar el nivel de inversión a la realidad de Velneo como plataforma?.
Toca responder a estas y otras muchas preguntas.
Conclusiones
Era previsible que el ritmo de novedades descendiese. De momento no parece especialmente preocupante, siguen apareciendo correcciones y novedades importantes. Vistos los lanzamientos de las últimas versiones podemos estar relativamente tranquilos.
Hemos dado tiempo a las últimas versiones para decidir que hacer con las inversiones en Velneo, es momento de tomar decisiones al respecto.
Microsoft está preparando su plataforma .NET para abordar el mercado de la multiplataforma y lo está haciendo bastante bien, tenemos que valorar invertir también en esta otra dirección.
TipeSoft cumplió en septiembre 10 años y en este tiempo no hemos parado de cambiar. Seguiremos haciéndolo de igual forma para adecuar nuestra oferta a las exigencias del mercado.
Tu super articulo de Velneo, que vas siempre actualizando. Eso me ha dejado preguntas.
Tu que estas en España y has tenido contacto directo incluso en el LIS, ¿has podido preguntarles alguna vez, que impide tener vServer MacOSX, vServer Android o vServer iOS?
Porque SQLite si puede funcionar como servidor de bases de datos en esos sistemas operativos, y Velneo no?
Es decir, ya que es imposible que provean el vclient offline (otras herramientas ya permiten esto, y hace tiempo), al menos que se puedan tener aplicaciones monopuesto en sistemas moviles, deberia ser la mayor exigencia, cierto?
Otra cosa que no entiendo en la comunidad, es que no necesiten un verdadero MODELADOR. El editor de esquemas no te muestra campos y llaves, y uno pierde mucho tiempo, especialmente cuando uno es mas arquitecto de software que programador, y gusta de tener visualmente todo.
Como es que una idea como esta que se ve en el enlace de abajo, tiene tan pocos votos? ¿No necesitan los desarroladores velneo ver graficamente sus tablas, campos, llaves y relaciones?, ¿o como salvan las papas?
El problema del vServer creo que es una cuestión de calidad de Qt en las dos plataformas. MacOSX y Android son plataformas que adolecen de ciertas funcionalidades que requiere el vServer (una de ellas es el soporte completo de multihilo).
El vClient se planteó desde el principio con soporte únicamente conectado. Esto hace que el cambio no sea menor (hay varios hilos que dependen del vServer de forma continua). Vamos que los cambios que se están haciendo para dotar de capacidad offline al vClient no permitirán tener un cliente totalmente desconectado en el corto plazo. Nosotros en mobile hemos descartado de momento Velneo, usamos directamente Qt5.
Lo del modelador es sencillo de explicar. La comunidad V7 proviene en una parte importante de entorno pequeños, en muchos casos no son programadores. No requieren de cosas que son realmente importantes para entornos grandes; modeladores, facilidades de consumo de servicios web, cliente desconectado, escalabilidad, debug completo, seguridad integrada, cifrado de bases de datos, cifrado de tabla o de columna, etc… vamos que el cliente al que se dirige Velneo es un cliente poco exigente en esta cuestión. Por eso creo que tiene pocos votos la idea del modelador.
En mi caso me apaño bien sin modelador, realmente pocas veces uso modeladores (solo en plataformas como .NET para EF y algunas cosas basadas en T4). En general la comunidad no lo requiere.
Me olvidé poner el link de la idea a que hago referencia.
https://velneo.zendesk.com/entries/24487591-Habilitar-el-uso-de-un-modelador-al-generar-archivos-XMI-desde-esquemas-Velneo-
Deberia ser muy, pero muy poco tiempo para el equipo de I+D de Velneo, tener esto listo (generar el XMI desde la informacion de nombres de tablas, campos y relaciones de tablas enlazadas, etc.), no les parece?
Asi uno importa ese XMI (que solo es un subset de XML) y lo abre con Umbrello, y cualquier cambio en las tablas Velneo, uno regenera el XMI y sigue viendo visualmente el diseño.
¿No es demasiado valor agregado, para algo que I+D hara una sola vez y quedara una poderosa herramienta de diseño disponible para los velneadores, especialmente para potenciales nuevos usuarios que vienen de otras herramientas, y estan acostumbrados al modelado de datos?
Es cierto que Velneo no nos da nada integrado para generar el fichero XMI con los metadatos de la estructura de nuestro proyecto, pero no parece demasiado problema. Yo creo que desde vJavaScript podrías implementar una salida en este formato.
Para los que desconocen XMI (XML Metadata Interchange), es un vocabulario XML que describe la estructura de un diagrama UML (http://www.omg.org/spec/XMI/). Fundamentalmente nos permite integrar distintas herramientas de diseño de modelos UML.
Cesar ¿UML? https://youtu.be/L9qlrgKWqfI?t=279
Miguel, no tengo tiempo de ver el video ahora, pero mas que usar UML, la necesidad es poder ver campos y llaves en los diagramas, imprimirlos en papel y tenerlos a mano.
Esto es independiente de que metodología ágil uses. Ver los campos, llaves y relaciones GRAFICAMENTE es una necesidad imprescindible. Como no piensan cambiar los esquemas de Velneo, deberian al menos construir el exportador de XMI. En el mismo Velneo SA dicen que es algo demasiado simple, entonces porque no lo hacen? que lo impide?
En vez de esperar que un desarrollador que solo usa Velneo para cosas muy puntuales, tenga que ponerse a profundizar sobre el API javascript para poder generar ese XMI?
Es algo que I+D LO HARA RÁPIDO (mucho mas rapido que cualquier usuario final de v7), lo hara UNA SOLA VEZ, y quedara un valor agregado grandisimo PARA TODOS (valor grande para el segmento de desarrolladores que indica Jorge, y que Velneo SA parece no detectar propiamente hasta ahora), poder usar un modelador gratuito como Umbrello, para poder ver gráficamente las tablas, llaves y relaciones construidas en una BD Velneo.
Jorge, ahora con algo mas de tiempo, te paso algunos enlaces sobre mi punto.
Si con SQLite pudieron esto:
http://stackoverflow.com/questions/11058098/interprocess-sqlite-thread-safety-on-ios
https://nfrolov.wordpress.com/2014/08/16/android-sqlitedatabase-locking-and-multi-threading
En Qt supuestamente se puede tener codigo thread-safe.
http://doc.qt.io/qt-5/threads.html
http://stackoverflow.com/questions/29048721/qt-android-how-to-access-an-external-object-in-qrunnable
Por eso no se que tan imposible podria ser pensar en un vServer MONOPUESTO (porque la idea es que funcione de forma desconectada, y que despues nosotros lo sincronicemos via algoritmos, si en v7 aun seguiran sin existir herramientas para esto), en Android e iOS, incluso una version ‘watered down’ del vserver (las funciones mas basicas posibles para que almacene datos en tablas velneo), pero que permita trabajar desconectado en dispositivos.