22 Database & Frontend Developer Congress in Frankfurt 2015


He tenido la oportunidad de asistir al Devcon 2015 de Frankfurt, donde pude tomar el pulso de la situación de VFP y disfrutar de algunas de las ponencias que se hicieron en inglés.

Este año me centré en conocer mejor XBase++, una alternativa de Alaska Software para los desarrolladores de Visual Foxpro 9. A diferencia de años anteriores, había múltiples ponencias en inglés de Xbase++, por lo que aproveché la ocasión para conocerlo mejor y resolver algunas dudas que se me planteaban, las cuales amablemente fueron respondidas por el equipo de Alaska Software, a los que agradezco su fantástica predisposición.

Como en años anteriores, las ponencias de VFP fueron llevadas a cabo por los ponentes americanos, los cuales son redactores habituales en la revista FoxRocks, además de ponentes y/o organizadores del congreso americano SWFox. Este año sus ponencias estaban relacionadas con programas disponibles del proyecto VFPX, así como artículos de la revista FoxRocks. Si no conoces la revista, o el proyecto VFPX Codeplex, es el momento de hacerlo. Podrás hacer aplicaciones con apariencia moderna y usar funcionalidades avanzadas.

XBase++ es el desarrollo de un lenguaje xBase al que gran parte de los programadores de Clipper se han pasado por ser su mejor sucesor.

Los programadores de XBase++ están acostumbrados a crear formularios con sus objetos usando código, mientras que los de VFP tenemos tendencia a usar las herramientas visuales propias del IDE, es algo que puede chocar un poco al principio.

Algunos puntos fuertes de Xbase++  son:

  •        El soporte de multihilo en las aplicaciones, con lo que se consigue un rendimiento excepcional.
  •        El motor de la base de datos puede ser el propio de XBase++ para trabajar con DBFs, o por ejemplo Postgree u otra base de datos. La ventaja del planteamiento es que puedes usar las mismas instrucciones, independientemente del motor de BD.
  •        Permiten programar en Xbase++ aplicaciones de Windows, así como páginas web.
  •        Ya admite muchas de las instrucciones de VFP, pues han ido añadiendo las funciones propias de VFP.
  •        Tiene un repertorio de instrucciones SQL interesante, con funcionalidades similares a las que LINQ dispone, como es poder hacer consultas con una tabla como origen, usar como origen de datos un array y/o mezclar ambos conceptos.
  •        Integración con objetos que tengan codificación html/css.

Cosas interesantes en las que están trabajando o que están relacionadas con su futuro:

  •        PolarFox, es la versión que debe permitir hacer una migración desde VFP a XBase++
  •        La versión actual compila en 32 bits. Por las pruebas que han hecho, han visto que el rendimiento del ejecutable en 32 bits es mejor que generándolo nativamente en 64 bits, por lo que por ahora no están interesados en compilar EXEs en 64 bits nativos.
  •        Un tema espinoso es las reports actuales de VFP. Por ahora, no hay una opción que permita su conversión, VFP tiene un generador de reports potente, con sus varias líneas de detalles, grupos, etc, que lo hacen un hueso duro a la hora de migrarlas.

Por otra parte, cabe mencionar que en el congreso también se habló de VFP Advanced, aunque no asistí por ser en alemán. Tal como ya  avancé en  este blog, VFP Advanced nos permite compilar VFP en 32 bits y está en fase beta la versión de 64 bits.

Anuncios

7 comentarios en “22 Database & Frontend Developer Congress in Frankfurt 2015

  1. David, He leído sobre tu concurrencia a Devcon 2015 de Frankfurt y tu comentario sobre VFP-Advanced a la que no pudiste concurrir. Siguiendo tus comentarios hemos iniciado una tarea importante investigado Baiyujia de 64 bits y hemos conectado con el Sr Chen.
    No obstante ello quisiéramos dialogar por mail con la gente que dio la charla en alemán de VFP-Advanced, podrías vos ser tan amable de conseguir los mails del o las personas que dieron esa charla. Saludos , Daniel Linardi

  2. Hola David, gracias por estos interesantes artículos. Mi cliente principal que tiene todo en tablas de VisualFox 9 desea poder llegar a contar con una página web desde donde sea posible realizar pedidos en línea y en todo momento poder visualizar las existencias reales entre otras cosas y poder tener un mercado bastante amplio para que la gente vea y compré sus productos en línea, y es allí donde uno siente que las tablas de VisualFox tocan el límite ya que aunque sea posible realizar la conexión hay otros temas como seguridad, optimización, conocimientos de parte de la empresa desarrolladora de la página web etc, En un caso así, cual sería tu recomendación ya que entre las opciones se encuentran: 1.Dejarlo como esta y accesar las tablas de visualfox desde la web, 2.Migrar de dbf a SQL modificando el código de VisualFox, 3.Migrar de visualfox a Xbase++, y no sé que otras opciones mas. El sistema a trasladar es bastante grande y ese es el principal problema. Saludos.

    • Hola Julio,
      Creo que tienes 2 decisiones importantes: El lenguaje y la base de datos a usar.
      Si estás acostumbrado a las peculiaridades de trabajar con MySQL, Postgree o SQLServer, creo que por aquí ya solucionas el problema de escalabilidad y seguridad más importante, con temas como autentificación, límite de tamaño, disponibilidad, etc. El problema aquí es en realidad adaptarse a trabajar con instrucciones SQL y no usar el seek, locate, replace, etc. El límite más importante de las tablas DBF es sus 2GB de tamaño máximo y no tener seguridad de autentificación de acceso a la base de datos de forma nativa para acceder a la tabla (debes gestionarlo tú por aplicación, si tienes acceso al DBF, puedes abrirlo con VFP y manipularlo sin conocer datos de usuarios/contraseña).
      El lenguaje a usar puede ser VFP o cualquier otro, recuerda que VFP trabaja no sólo con DBF, soporta ODBC.
      El cambio de lenguaje es duro, conseguir hacer lo mismo en C# puede triplicar el tiempo de desarrollo en comparación con VFP, sin contar costes de librerías externas, lenguajes o bases de datos no gratuitas.
      Yo creo que deberías revisar la aplicación de tu cliente y ver que código puedes reciclar para hacer las rutinas de la web, y cuál no. Por ejemplo, si vende productos con stock, seguro que tienes rutinas para generar la venta, descontar el stock, crear apunte contable y enviar el documento de venta a tu cliente.
      Dependiendo de lo anterior, puedes optar por crear algo desde cero, o bien crear la web mediante ASPX, PHP, etc y conectar a tu backoffice mediante un webservice (podría ser desarrollado en VFP) para realizar las peticiones y obtener los resultados mediante XML o JSON. Esto da la posibilidad de reciclar tu código existente, además de crecer en un futuro. Si más adelante cambias la web por un nuevo diseño, las rutinas de manipulación/consulta/compra son las mismas del webservice.
      Si no quieres webservice, pero quieres seguir usando VFP para la programación, puedes llamar a VFP desde otros lenguajes (por ejemplo desde .NET/Asp), compilas en VFP una DLL y la llamas desde la web. Esa DLL puede contener las funciones e incluso devolver código para pintar tu web.
      Yo he hecho todas estas opciones para la empresa en la que trabajo, usando cada adaptación según requisitos de carga de trabajo previstos/disponibilidad/seguridad/conectividad, y te puedo adelantar que en todos los casos ha funcionado, siendo las aplicaciones de gestión/backoffice afectadas de gran tamaño y complejidad.

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s