Artículo original:
"How to make Visual FoxPro cool"
http://craigbailey.blogspot.com/2006/05/vfp-how-to-make-visual-foxpro-cool.htmlComo hacer a
Autor:
Craig Bailey
Traducido por:
Luis María Guayán
Como hacer a Visual FoxPro bonito (*)
(*) Nota del traductor: He elegido "bonito" como traducción de "cool" ya que ésta palabra tiene varias traducciones según la zona geográfica.
Por si usted no lo hubiera notado, Visual FoxPro (VFP) no es muy bonito. En este artículo mi objetivo es cubrir 3 áreas:
- ¿Por qué VFP no es bonito?
- ¿Por qué esto importa?
- ¿Cómo podemos hacer a VFP bonito?
1. ¿Por qué VFP no es bonito?
De acuerdo, entonces la primera cosa en la que tenemos que convenir consiste en que VFP no es bonito. He estado charlando últimamente con algunas personas del ambiente .Net (incluso
Adam Cogan y
Paul Stovell) acerca de sus opiniones sobre VFP. Me he concentrado en desarrolladores que nunca han usado VFP, porque ellos pueden brindar las opiniones más útiles (a diferencia de los desarrolladores VFP/.Net que son bastante mas conscientes de lo que VFP puede hacer).
Seguidamente tenemos que reconocer que hay una ignorancia general en la comunidad .Net de lo que VFP puede hacer. Por ejemplo, ellos están verdaderamente sorprendidos de saber como VFP puede "hablar" con un SQL Server tan fácilmente. La contestación a esto no es mi orden del día, sin embargo, hubo muchas discusiones en la falta de comercialización para VFP y no tengo ningún interés en repetirlos aquí. Sin embargo volveré, separando el mensaje, más adelante en este artículo.
Mejor dicho, voy a concentrarme en áreas no técnicas. Aquí están algunos motivos por qué la gente piensa que VFP no es bonito:
Razón 1: Está "sobre la cima"
La primera cosa que VFP tiene en contra, es el hecho que ha existido por mucho tiempo. Usted piensa que esto es bueno ¿verdad?. Estable. Optimizado. Gran comunidad. NO!. Los nuevos desarrolladores de la actualidad, están más interesados en trabajar con la última tecnología. Y VFP no es nuevo.
Piense en COBOL. Cuando la gente se ríe de alguien que es programador de COBOL, no porque ellos recuerden un lenguaje deficiente, sino, principalmente ellos piensan que el lenguaje es anticuado, es decir, debe ser un poco en broma todavía usarlo.
Y lamentablemente, Visual FoxPro avanza lentamente a ese mismo lugar. Esto es a pesar de que Microsoft trabaja actualmente en la
siguiente actualización de VFP y ha confirmado el
soporte de este hasta 2014. ¡Pero es tan viejo! Sí, debe ser bien aprovechado a lo largo de esa fecha ... mas o menos como dice la teoría. Este en desacuerdo todo lo que quiera, pero es un hecho. Pregunte a un novel estudiante universitario lo que el piensa de VFP, y él lo mirará sin expresión. Pregunte a un desarrollador más viejo (no un desarrollador VFP) su opinión, y él preguntará si todavía existe. Infórmele de VFP y observe su reacción, -Debe estar en el depósito de chatarra seguramente ... y hacia allí va. Todos nos hemos topado con este pensamiento en el mundo que nos rodea.
Y puedo referirme a mi mismo con esto. Amo todas las cosas nuevas, así que entiendo totalmente de donde esto proviene.
Ahora, en este punto usted puede preguntar si los nuevos desarrolladores son realmente tan "superficiales". Quiero decir que seguramente ellos tendrían algún interés en comparar las herramientas y elegir la mejor para trabajar con ella. NO!. Calculo que las capacidades actuales de las herramientas comprenden aproximadamente el 5 % del proceso de decisión.
¿No me creen? Entonces considere esto: ¿Por qué hay más desarrolladores que ingresan a C# que a VB.Net? C# es bonito, es por eso. Ambos lenguajes tienen mas o menos la misma funcionalidad, y aún C# es percibido como el lenguaje que los auténticos desarrolladores avispados eligen. Sí, y VB es para la gente que encuentra C# demasiado dificultoso ... Hay, desde luego, algunos importantes (y elocuentes) defensores de VB, pero el hecho de que ellos tienen que explicar por qué VB es como el bueno, es parte de la demostración que es la hermana fea. (A propósito, creo que probablemente este último párrafo conseguirá la mayor reacción por parte de los lectores, y de ser así, entonces es porque ha perdido mi punto principal).
Punto principal => Lo bonito no es sobre la capacidad técnica, es sobre la percepción. La percepción es todo.
Razón 2: No hace Código Administrado (Managed Code)
La segunda cosa contra VFP, consiste en que esto no es parte del paquete .Net. El código de VFP no es código administrado. Y aquí está la parte interesante, pregunte a un nuevo desarrollador .Net por qué el código administrado es mejor. Usted conseguirá algunos balbuceos sobre la mejor administración de memoria, unos cuantos mencionarán garbage collection (información basura), pero en términos generales, los desarrolladores no podrán decirle que es lo bueno acerca del código administrado. Es solo mejor, Ok.
Así que, porque VFP no es código administrado, entonces, este debe ser anticuado. Por supuesto, todos ellos usan Word, Outlook, Skype, Windows Media Player y una multitud de otras aplicaciones que no son escritas en código administrado, pero este es inútil. El caso es que si usted escribe código administrado, entonces la percepción es que usted escribe el mejor código. El código administrado es bonito, VFP no lo es.
Y no me considere equivocado, no ridiculizo esta manera de pensar, realmente pienso que esto tiene un gran mérito. Mi punto es enumerar simplemente las razones de la percepción que VFP tiene.
Razón 3: La experiencia de Usuario del Desarrollador
El tercer golpe contra VFP es la apariencia y comportamiento. Ejecute VFP y usted se enfrentará con los viejos menús de Windows 2000. Ningún simpático menú Whidby (
Nota del traductor: nombre de código de Visual Studio 2005), ni siquiera menús estilo Outlook 2003. Abra algunos diálogos, todos los iconos son antiguos. Nada es 3D (excepto algunos iconos del nuevo diálogo de informes); y la barra de estado es de los años 90. Esto no tiene ni un interfaz tabulada (alguien realmente tiene que hacer algo respecto de esto :-)) Por supuesto que esto no importa un bledo a la calidad de las aplicaciones que esto produce, pero en estos días, la
experiencia del usuario es lo mas importante.
Razón 4: Tiene la palabra "Fox" en él
Aunque realmente la palabra Fox se haya beneficiado un poco del navegador FireFox, en general, las palabras Fox y FoxPro son en gran parte antiguas. VFP realmente necesita algún cambio de nombre para superar esto. Para muchas personas hay un estigma grande ligado a la palabra FoxPro. Ellos no pueden desvincularlo de las asquerosas aplicaciones FoxPro para DOS que ellos usaron en la compañía hace 10 años (mi atención ha girado aquí a desarrolladores más viejos). Pero los desarrolladores aún más recientes recuerdan el FoxPro que vino con el Visual Studio 6. Ellos lo vieron allí, pero realmente sólo pueden recordar el aburrido icono de 16 colores que este tenía. Otra vez, la percepción es que es viejo e irrelevante.
Y no subestime la necesidad de cambiar el nombre. Tome por ejemplo Microsoft FrontPage. El estigma atado a FrontPage desde versiones previas (donde este solía corromper su HTML) era tan malo, que Microsoft sabía que tenían que renombrarlo. Y entonces lo que en principio iba a ser FrontPage 2007, ahora se ha convertido en
Microsoft Expression Web Designer Edition (compruebe el demo
aquí y verá lo que quiero decir). Mismo producto, percepción diferente.
2. ¿Por qué esto importa?
¡Y qué! Si VFP no es bonito, todavía hace lo que los desarrolladores VFP necesitemos ¿Correcto?
Incorrecto. El problema más grande que enfrenta VFP hacia el futuro, es la carencia de desarrolladores. Lo mas probable es que el banco de programadores VFP disminuya. Asumo que la mayor parte de las personas estarán de acuerdo con esta afirmación.
El desafío para un negocio que desarrolla en VFP no es la tecnología, es la gente. Si usted quiere aumentar su negocio y tomar a nuevos desarrolladores, usted tiene que tener una buena fuente de ellos para seleccionar. ¿Entonces, por qué hay menos desarrolladores VFP?
Esto es porque todos los nuevos estudiantes universitarios estudian .Net o Java. Hay excepciones, por supuesto, pero esta es la tendencia general (y sospecho que esto pasa en India y Asia también, no sólo en países Occidentales).
¿Y por qué los estudiantes universitarios no aprenden o se interesan al menos acerca de VFP? Deje de lado las exageradas promociones y enorme empuje de la comercialización de Microsoft durante un minuto y todo se vuelve al factor de bonito. Si pudiéramos hacer a VFP bonito, conseguiríamos a más interesados.
3. ¿Cómo hacer a Visual FoxPro bonito?
De este manera, ¿qué podemos hacer para hacer a VFP bonito? Aquí están algunas ideas (algunas podemos hacer, otras están fuera del alcance de nuestras manos):
Cambio de nombre (Requiere Microsoft)
Es tiempo para perder la palabra "Fox".
Microsoft no ha indicado como será llamada la siguiente actualización/versión. Por el momento esto es simplemente llamado con el nombre de código Sedna. Sin embargo, yo he comenzado a referirme a ello como Microsoft VF.Net.
VF es la abreviatura para Visual FoxPro, y el .Net se refiere a la integración fuerte que este tiene con el .Net Framework 2.0. No, este no escribe código de .Net, sino que utiliza .Net Framework. Este es un lenguaje .Net despabilado.
También he cambiado el icono en la esquina superior izquierda del IDE de VFP. De esta manera cuando la gente me ve usar VFP, ellos ven el título como Microsoft VF.Net y un icono agradable. También puede deshabilitar la pantalla de presentación usando un archivo de configuración, tanto que, a menos que usted mire la Ayuda -> Acerca de ... no hay ningún "zorro" a la vista.
También uso
FoxTabs, aunque esto esté todavía en beta y tenga algunas cuestiones conocidas, y necesite un cambio de nombre :-) que mejora la experiencia de diseño.
Modernizar la interfaz (Requiere Microsoft)
La interfaz necesita una revisión. Actualizar los menús para parecer a Visual Studio 2005, embellecer la pantalla de presentación y los diálogos. Advierta, no necesitamos un cambio de la funcionalidad, sólo de aspecto y sensación del producto.
Promover la integración .Net
En demostraciones a un auditorio variado (es decir no limitado a desarrolladores Fox) trataré de mencionar los nuevos
ejemplos de Sedna (y caramba espero que haya nuevo CTP que pronto llegará ...). Los desarrolladores no comprenden que tan fácil pueden usar VFP con .Net (tanto usando Sedna como usando controles .Net, por ejemplo, consulten los sitios de
Craig Boyd y de
Rick Strahl)
Promueva los datos vinculados (data binding)
Las cosas que trae LINQ para .Net son grandiosas. Sin embargo, muestre a la gente cuanto más ellos pueden hacer con VFP, y díganles que ellos deberían hacer campaña contra el Equipo .Net para que les provean lo mismo. Los desarrolladores de .Net deberían gritar sobre lo mal que ellos han sido tratados en las apuestas de datos vinculados. Dígales que ellos pueden usar VFP como un ejemplo de como es posible hacerlo.
Promueva a VFP como una herramienta de ayuda
VFP es una gran herramienta para usar junto a Visual Studio. No trato de convencer a desarrolladores .Net de cambiar a VFP, pero hay muchas ventajas que ellos podrían sacar teniendo a VFP como una herramienta de ayuda, incluyendo:
- ¿Necesita escribir algunas pruebas SQL Server rápidas? Use VFP con datos de prueba del sistema. Además use VFP para hacer llamadas a procedimientos almacenados y comprobar los datos devueltos.
- ¿Necesita sacar algunos datos en una hoja de cálculo? Use VFP.
- ¿Necesita programar algunas actualizaciones? VFP es extraordinario como una herramienta de programación, similar al lenguaje de programación VB.
- ¿Necesita comprobar si un objeto de COM está instalado? Pruebe una rápida llamada CREATEOBJECT en VFP.
Promueva a VFP como una herramienta de prototipos
VFP es una gran herramienta para desarrolladores .Net, para construir prototipos. Tome un formulario, tire algunos controles, enlace a algunos datos de ejemplo, entregue la aplicación al cliente en un pequeño instalador, etc.
Difunda el mensaje
Esto no es una nueva petición.
Craig Boyd (e incluso
yo mismo) ha solicitado de la acción de la comunidad VFP a que ayude a hacer conocer a otras comunidades de desarrolladores un poco de las grandes cosas que VFP tiene, (por la sencilla razón que ellos pueden hacer presión sobre Microsoft para apresurar y conseguirlo en .Net :-)
Sin embargo, el mensaje se trata de la difusión de algunos conceptos equivocados sobre VFP. Aquí están algunas cosas que tenemos que promover:
- VFP trabaja estupendo con .Net
- Sedna realmente se enfoca en la interoperabilidad .Net
- VFP es un conector impresionante para SQL Server
- VFP tiene llamadas SQL en línea
- VFP está bien soportado y sigue mejorando
Conclusiones
Después de leer mi artículo, yo comprendería si pensó que era anti .Net. En realidad, es lo contrario, por ejemplo me ocupo de un equipo de 15 desarrolladores; más de la mitad son desarrolladores de .Net. Hacemos muchos desarrollos ASP.Net, SQL Server y BizTalk. Pero también hacemos mucho desarrollo en Visual FoxPro Visual. Mi preocupación es acerca de la percepción que VFP tiene, y afrontar en el largo plazo la obtención de más desarrolladores VFP. De ahí mi interés en mejorar la percepción que VFP tiene.
Sus opiniones
Si usted es un desarrollador .Net y dispone de un minuto para enviarme sus opiniones de lo que piensa de VFP, y lo que tomaría de esto para convencerlo de que VFP es bonito, estaría encantado de tener noticias suyas. Puede enviarme un correo electrónico a:
cb@talman.com.au o dejar un comentario en este artículo.
Agradecimientos
Paul Stovell y Adam Cogan me han dado montones de ideas, con muchas de las cuales he concluido este artículo. Sin embargo, cualquier prejuicio, equivocación o animosidad percibida son las totalmente mías.
