No recuerdo nada ahora mismo, desde la última entrada que escribí, algo que me haya generado alguna inquietud, grande o pequeña, en un sentido u en otro, o la necesidad de apuntarlo por alguna parte para luego recordarlo, ni nada similar. También es cierto que no he buscado demasiado, pero habitualmente los canales básicos como el twitter, las diversas tribus creadas, o la misma blogosfera de embarcadero, nos permiten sospechar que hay novedades y que existe un movimiento entre bastidores, presagio de lanzamientos comerciales o de cambios importantes.
Me queda la impresión de que todos andan concentrados en sus trabajos y quimeras y que, las pocas novedades que surgen son mas bien algo artificial, con el fin de que no decaiga la cosa y se siga hablando…
De las pocas cosas que me puedo llevar a la boca, el aperitivo de un pequeño vídeo en español, editado por Andreano Lanusse, y que nos presenta las dos herramientas: ER/Studio Developer y DB Optimizer, interactuando desde RAD Studio.
Visionar los poco más de 7 minutos que dura, no os va a hacer expertos en estas herramientas pero al menos, sí os pueden ayudar a comprender que papel pueden jugar ambas en el contexto de vuestro compilador.
Del resto de temas, quizás destacaría el enlace a la pagina de Tim del Chiaro,
En otras ocasiones hemos compartido la publicación de estos cuestionarios dirigidos a los usuarios de las herramientas de Embarcadero. Ya veis que no es una noticia deslumbrante pero bueno, también entiendo que forma parte de esas cosas que se deben hacer de forma regular para analizar los mercados y la intención de compra y necesidades de sus desarrolladores. Un feedback que siempre es bien recibido.
Durante todos estos días parece que vamos a poder ver y conocer mas de cerca las ultimas novedades sobre RAD Studio 2010 y la muestra la tenemos en este video que publicó ayer Embarcadero y donde, David Intersimone y Nick Hodges , nos acompañan para conocer las novedades y nuevas caracteristicas del IDE.
Aunque el video está en inglés, os aconsejo que no os lo perdais porque hay cosas que no necesitan traducción y las vais a poder apreciar mejor que leyendo simplemente una nota técnica de caracteristicas.
La dirección original de la entrada de Embarcadero es:
Un comentario mas… por lo que allí se anuncia, el proximo 11 de agosto esta prevista la aparición de un segundo video sobre una de las muy esperadas novedades, el comentado “Gesture manager“.
Sobre el contenido del video, se centra principalmente en las novedades a nivel de IDE, del propio entorno, y una de ellas, la mas llamativa es lo que han llamado “IDE Insight”, que viene a ser una ventana que nos facilitará una búsqueda rapida dentro del propio interfaz de trabajo. Si estamos editando en un formulario, IDE Insight nos facilitará la busqueda de las clases disponibles para introducir por ejemplo un componente en el mismo. Si estamos editando código, nos permitiría acceder a caracteristicas y opciones sin tener que acceder a los menús. Todo desde una única ventana de exploración. En el video se puede ver bastante bien todo esto.
Otra novedad que llama la atención y que a muchos sorprenderá, no se si positivamente o no porque parece ser que fue motivo de discrepancias durante la primera etapa de discusión, es la posibilidad de formatear el código de acuerdo a nuestras necesidades o manias por decirlo de alguna forma, con un simple [Ctrl + Alt + F]. Este formateo del codigo se va a realizar de acuerdo con las opciones fijadas en nuestro IDE.
Y respecto al depurador, parece que también se han incorporado algunas mejoras, a nivel de hilos de ejecución, permitiendo que se pueda depurar de forma aislada cada uno de ellos (existe una opción para congelar la depuración de cada hilo o thread).
Además de poder verlo en el propio video, también podeis leer la entrada del blog de Nick Hodges, donde nos lo comenta:
Esta es la tercera y última parte de una serie que ha querido abordar el control de versiones JediVCS, con la sana intención de que quedaran lo mas claros posibles, algunos puntos que en mi opinión estaban un tanto confusos, sobretodo para las personas que se enfrentan por primera vez a este tipo de servicios. Una vez entiendes el funcionamiento lo ves tan obvio que piensas:
-¿Cómo he podido pensar de otra forma…?
Creo que debería empezar por comentar que es lo primero que pensé cuando decidimos hacer uso de un control de versiones. Uno piensa que lógicamente, el código se situa en algun servidor. Yo me imaginaba la escena mas o menos así:
El código fuente del proyecto se copiaba inicialmente a una carpeta del servidor (ese era el directorio de trabajo) y el servicio protegía el acceso a los ficheros físicos bloqueando el estado de lectura/escritura y comprometiendose como un semaforo para todos los usuarios que accedían a los módulos. En ese estatus, es facil pensar que el usuario, al hacer CheckOut estaba trayendose una copia local de un modulo concreto y al hacer CheckIn devolvía a ese directorio de trabajo los ficheros que habían sido comprometidos, sobrescribiendo los cambios. Al menos, yo tenía esa primera intuición sobre el trabajo en la red local, entre usuarios de un mismo equipo de trabajo y accediendo a un servidor global.
El problema reside en que algunos de los patrones comentados coinciden en parte. Coincide el funcionamiento de las dos funciones principales, que son CheckIn y CheckOut, coincide el efectivo uso real y la posibilidad de trabajar en un mismo equipo las dos partes básicas implicadas, que son el cliente y el servidor de JediVCS. Así que como Platón y su visión de las sombras, podemos ir elucubrando sobre un pilar falso conclusiones veraces que se cumplen solo de forma casual. Dicho en cristiano… montamos sobre una verdad aparente una teoria que no es cierta e intentamos descubrir como se accede a ella.
Así que lo primero que vamos a hacer es desmontar la teoria y para ello vais a hacer los siguiente: (enumeramos primero el supuesto y luego los puntos que hay que seguir)
* Tenemos dos equipos A y B.
* En el equipo A tenemos intalado el cliente de Jedi y Delphi. Además hemos creado la unidad virtual V: apuntando a la carpeta D:ProyectosTest. En dicha carpeta existe el codigo fuente que vamos a controlar mediante Jedi. El equipo A tiene la Ip 192.168.1.2.
* En el equipo B tenemos intalado el servidor de JediVCS. Su Ip es la 192.168.1.50. El servicio está en marcha y hemos habilitado nuestro firewall con los permisos necesarios para que permita el acceso al puerto. Tambien hemos creado el administrador del proyecto, que será Salvador, con derechos de acceso de nivel 3 (identificador de derechos segun el servicio de control para administradores de proyecto). Tambien hemos instalado el cliente de Jedi en el equipo B (pero esto es opcional). Igualmente hemos creado la unidad virtual V: pero esta vez apuntando a la carpeta física D:Repositorio_Jedi
Punto 1: Desde el entorno de Delphi en el equipo A, nos conectamos al servidor de Jedi del equipo Servidor (B), a través del usuario Salvador, que va a ser quien añada el nuevo proyecto que tiene el usuario alojado inicialmente en A, en la unidad V:. Esos pasos los pudimos ver en el video. En el pudimos ver cómo se creaba el proyecto y se añadian los módulos.
Punto 2: Hecho el punto 1, el equipo A, sigue conteniendo una copia local en V de los archivos del proyecto de Delphi. En el equipo B existe una copia archivada, que mantiene el servicio de JediVCS. Fisicamente no existen todavía los ficheros en B.
Punto 3: Desconectamos A de la red. El usuario del equipo A, se fue a tomarse una cerveza bien fría acompañada de unas almendritas y un ración de ensaladilla. Es un usuario que sabe disfrutar de la vida.
Punto 4: Veamos que pasa con el equipo B… Conectamos el cliente de JediVCS. Nos hacemos pasar por Salvador y accedemos al proyecto. Vemos los modulos pero presentan un icono similar al de eliminados (una cruz roja tachada) que nos indica que no existen en el hipotetico directorio de trabajo V:. Efectivamente no existen. Sincronizamos los modulos y tras confirmar, ¡voila!, la unidad virtual se sincroniza con el servidor y recibe una copia local de la versión archivada de los ficheros.
Lo cual entra en conflicto con la idea original que teniamos en mente y nos desmonta la teoria…
Ahora deberíamos comprender que significa para JediVCS el directorio de trabajo y cómo resulta sencillo en el uso del proyecto compartido entre varios programadores con una única unidad virtual local. Cada programador trabajaría de esta forma localmente compartiendo una misma unidad virtual, que podría apuntar en cada uno de los desarrolladores a distintas carpetas locales. No obstante, ni siquiera esto es obligatorio y de ahí que nos recomienden no variar la unidad de destino, con el fin de que no podamos accidentalmente sobrescribir los cambios. Al principio, y debido a que no entendía el correcto funcionamiento del flujo de trabajo, no comprendía bien el sentido de Sincronizar, puesto que si partes de una premisa inicial erronea es realmente fácil aventurar deducciones falsas de la misma.
Como véis, el servicio de control de versiones es una buena idea incluso para un unico desarrollador que pretenda llevar un minimo control sobre el codigo fuente. Le permitiría mantener un comentario de los distintos cambios realizados de forma versionada, a cada nueva versión de los módulos. Le permitiría guardar distintar versiones del mismo proyecto, recuperarlas si no ha avanzado correctamente y necesita deshacer lo andado. Y le permite guardar de forma automática en el supuesto de que el servidor se aloje en un equipo distinto del de desarrollo de una copia de seguridad actualizada del codigo fuente, puesto que podría mantener una copia local en dicho equipo con la ultima versión física de los ficheros. Y por último, podría mantener un sistema de control de bugs o errores, ya que el mismo servicio cuenta con los apartados necesarios para la anotación y control de errores y tareas pendientes.
Existen otros controladores de versiones mas complejos. JediVCS se basa en el sistema de bloqueo de ficheros de forma que un modulo solo puede ser accedido por uno solo desarrollador. Todo depende un poco de que es lo que realmente necesite vuestro equipo de desarrollo. Si necesitais que simultaneamente accedan a un único módulo varios programadores, no os va a ayudar. Para ello existen otros servicios que sí que contemplan esta situación y que confrontan distintas versiones, que comparan y mezclan las versiones archivadas. Es otro enfoque que resuelve el problema.
En fin… un poco como resumen. Creo que es bueno plantearse el uso de cualquier control de versiones. Mucho mas si trabajan varios desarrolladores en el proyecto. Y en este caso además, es una opción gratuita. Puede ser un buen comienzo para valorar en un momento posterior otros VCS y decidir que mejoras nos aportan.
Espero que os haya podido servir de algo esta pequeña serie sobre JediVCS.
Inicialmente no había previsto crear esta segunda entrada, de forma que lo escrito en “Atrevete a conocer Velneo” era un pequeño guiño a la nueva V7 y en concreto, a una de las novedades que ya se habían dado a conocer desde la empresa Velneo pero que, quizás para muchos pudieron pasar inadvertida. De hecho, y sin querer restar importancia al resto de novedades, que anticipo no son pocas y algunas muy significativas, quizás la que marca en mi opinión un antes y un después y una apertura hacia el exterior es la que ya pudimos leer desde su blog, en fecha 19 de Junio de 2007. Es la primera referencia oficial que pude encontrar.
Dentro de la misma, extraigo un pequeño parrafo que es el que nos interesa:
Actualmente el equipo de desarrollo trabaja con distintos subproyectos de V7, principalmente en el área de datos, Velneo vServer y Velneo vDataClient y en las próximas semanas empezaremos a probar internamente el driver ODBC de acceso a Velneo vServer que se realiza paralelamente al Velneo vDataClient.
Yo decía al finalizar “Atrevete a conocer Velneo”:
“Es posible que pronto descubramos que no están tan lejos, y que desde el pequeño mundo de la diosa griega tambien se puede llegar a Velneo… ¡Milagros de la V7!”
Pues bien… Me gustaría romper una lanza a favor de Velneo en este punto y reflexionar sobre lo difícil que resulta sacarse las etiquetas de encima una vez que te las asignan. Y es que, a Velneo, le ha caido el estigma de que es una plataforma que va a aislar al programador, fruto de la nula conectividad hacia el exterior y hacia otras bases de datos. Y quizás la peor mentira es una verdad a medias que se propaga (fruto en un gran numero de casos de nuestra ignorancia) ya con razón o sin ella. Os pongo un ejemplo… Hace un par de días, sin ir mas lejos, comentaba con un compañero que programa habitualmente con Delphi, al igual que yo lo hago, y al salir en la conversación el tema de la existencia de Velneo y su posibilidad de uso como una posibilidad mas de oferta de nuestros servicios, zanjaba él de forma categorica:
-¡No hombre, no!. ¡Si usas Velneo vas a tener que morir a ellos! ¿Qué pasa con lo que ya tengo desarrollado? Todos dicen que es un entorno cerrado y … -En este punto no pude menos que interrumpirle-
- Pero bueno… vamos a ver… -intenté razonar con mi compañero- ¿Qué conoces de Velneo…?
Y ciertamente, tal y como yo pensaba, mi compañero recitaba de memoria lo que había escuchado y leido, aun cuando no fuera estrictamente cierto.
¿Qué hay de verdad y qué hay de falso?
Vosotros mismos lo vais a juzgar. Os he preparado este pequeño video donde se puede ver el funcionamiento del pluggin vOdbc que ya existía en Velneo, en la V6, y que nos va a permitir conectarnos a cualquier base de datos externas para la que exista un driver ODBC a la misma.
La moraleja que deberíamos obtener tras la visualización del video es que a la postre, no resulta demasiado cierto decir que Velneo, como plataforma de desarrollo, aisla al programador. Desde la V6 y a través de este pluggin podemos conectarnos a cualquier base de datos externa. De hecho, yo mismo he visto desarrollos de compañeros que programan con Visual Basic, y que han podido enlazar una gestion comercial basada en Access y Visual Basic con la plantilla de contabilidad de Velneo, resolviendo de forma sencilla la necesidad que les pudo surgir al serle requerida por la empresa una contabilidad, que por descontado ellos no tenían ni pajolera idea de como hacer, ni tampoco tiempo para experimentos… Por supuesto que tuvieron que recurrir a la IMAGINACIÓN… pero eso nos sucede a todos ¿no os parece? En ese caso concreto bastó crear una serie de procedimientos en Velneo que importaran los datos de las tablas de access, actualizando los codigo contables de las cuentas de clientes, proveedores y generando los asientos asociados a la importación de facturas. Con la ventaja añadida de que ese programador, una vez introducido en el mundo de Velneo, podría modificar esa plantilla para adaptarla a nuevos requerimientos.
Y deciamos que no hay peor mentira que una verdad a medias porque lo realmente cierto es que en la V6 de Velneo existe una limitación que es la que ha dado pie a la referida etiqueta: No podemos acceder desde una aplicación externa a nuestra base de datos de Velneo. Y posiblemente eso, es lo que hace que el programador se sienta inseguro y aislado (desde la optica del desarrollador que se acerca a Velneo desde otros entornos). Yo mismo pensaba así al principio. Sin embargo, cuando conocí la existencia de la V7 y los cambiós importantes que esta nueva versión iba a proporcionar cambió mi forma de verla y la imagen que tenía de ella.
Yo creo que las etiquetas cuando no son ciertas hay que decirlo claramente porque podemos correr el riesgo de despreciar productos que pueden aportar valor añadido a nuestros servicios. ¿Os imaginais contar con una contabilidad, una gestion comercial completa, una gestión de fabricación, que podais incorporarla facilmente a vuestro catálogo de servicios?.
Es mas… y aquí viene lo mas importante:
La V7, va a contar con un API de conexión al vServer de Velneo y podréis conectaros a vuestro servidor de Velneo desde vuestro entorno de desarrollo habitual (Delphi, Visual Basic, etc…), disfrutando de las mismas caracteristicas y beneficios que se obtendrían desde Velneo. En el último seminario sobre V7 se pudo comprobar el estado actual del nuevo driver ODBC que permitirá la conexíon a Velneo y que posee todas las ventajas del vDataClient (otra novedad que ha sido demandada por los programadores de V6) de V7 : caché de datos, acceso a campos objeto, protocolo VATP, sockets envolventes, etc.
Los asistentes al seminario pudieron ver en ejecución una aplicación externa que accedía a los datos del servidor de Velneo. Y si bien faltan algunos detalles, el driver odbc se encuentra bastante avanzado y ya empieza a ser operativo. Quiero decir con esto que no es una conjetura, que es algo que los asistentes al seminario pudieron ver en tiempo real.
Así que, resumiendo y ya para finalizar, hay etiquetas que deberíamos empezar a quitar y una de ellas es la de que “Velneo aisla al programador…”. Ni era cierto del todo con la V6 y mucho menos de ahora en adelante, con la esperada V7, que nos va a proporcionar conectividad total en ambos sentidos, desde y hacia Velneo.
En esta ocasión, la entrada del blog la ocupa Veneo, pero no tanto pensando en los programadores de esta plataforma de desarrollo, sino mas bien con el pensamiento puesto en los compañeros de Delphi, para los que posiblemente no sea tan conocida. Así que he extraido estos cuatro videos que están presentes en la web de la empresa Velneo y que creo resumen de forma clara, didáctica y visual la mecánica de trabajo.
Los videos forman parte de la página central de información del producto, y representan una mínima expresión de lo que simboliza la enseñanza audivisual en Velneo, parte principal de los seminarios y cursos que se imparten desde la misma empresa. Pero mas que explicarlos, vale la pena que lo valoreis vosotros mismos.
Ya… creo saber qué estais pensando… ¡qué son dos mundos distintos…! ¡y que no tiene nada que ver Delphi y Velneo!
Pues yo por si acaso los iría visualizando…
Creación y diseño de la base de datos.
Creación de los objetos visuales (I)
Creación de los objetos visuales (II)
Ejecución de nuestra aplicación
Es posible que pronto descubramos que no están tan lejos, y que desde el pequeño mundo de la diosa griega tambien se puede llegar a Velneo…
por decirlo de alguna forma, con un simple [Ctrl + Alt + F]. Este formateo del codigo se va a realizar de acuerdo con las opciones fijadas en nuestro IDE.
http://www.danysoft.com/
http://www.embarcadero.com
Delphi Access
Comentarios recientes