Tip Forms (I)

Cuando estemos trabajando con Forms y vayamos desarrollando y, sobre todo, manteniendo un form, nos encontraremos con que tenemos Unidades de Programa en dicho Form que actualmente no se usen. Bien porque estén obsoletas o porque se han sacado a una librería compartida.
Pues bien, aunque inicialmente estas U.P. no hacen daño a nadie es mejor irlas eliminando conforme no se usan. el motivo es que cuando compilemos y generemos el correspondiente 'fmx' estamos metiendo también este código con lo que estamos sumando tamaño al fmx de forma innecesaria.

Cuando la velocidad de la red local penaliza la carga de estos fmx es mejor tenerlos lo más 'a dieta' posible. Si podemos ahorrar algo de tamaño, por pequeño que sea, será siempre bienvenido.

Por otro lado, si el motivo para no eliminar este código obsoleto es mantenerlo "por si acaso" es bueno recordar que debemos usar un programa de control de versiones para evitar estas situaciones innecesarias.

Y cómo podemos identificar si una P.U. está siendo utilizada o no? Aquí un ejemplo:

Cuando desplegamos la información de una PU veremos tres apartados:

• Specification: La especificacion de la PU [Parámetros de E/S]
• References: Qué PU son llamadas en su código
• Referenced by: Qué PU, Triggers, etc llaman a nuestra PU. Si este apartado está en blanco quiere decir que ningun proceso está usando esta PU y que, por tanto, puede ser eliminada.

Trabajando con Subversion (I)

Voy a dar por hecho que ya tenemos instalado un servidor de Subversion y un cliente. Un servidor sencillo lo podéis ver aquí o aquí. Un par de clientes gratuitos: aquí y aquí.

Usando Subversion en Forms / Reports

Usar un programa de control de versiones es siempre un problema cuando tratamos de comparar distintas revisiones / versiones de un fichero. No hay una solución fácil para esto, así que vamos a proponer un para de formas de trabajar para sortear un poco el problema.


Estas dos formas de trabajar están basadas en cómo se hace en otras compañías donde he estado. No es la única, así que en vuestra mano está decidir si se adapta o no a vuestras necesidades. A saber:

• Pequeños desarrollos: fácil de fusionar los cambios en la rama principal y rápido de desarrollar. Lo veremos en detalle en 'Trabajando con Subversion (II)'
• Grandes desarrollos: necesitan de uno o más desarrolladores trabajando conjuntamente en los mismos fuentes. No es fácil hacer la fusión manualmente en la rama principal.  Lo veremos en detalle en 'Trabajando con Subversion (III)'

Estructura de directorios en Subversion

La estructura de directorios no es muy compleja y se puede encontrar información detallada por aquí. Aunque cada uno puede usar un poco la estructura de directorios que le apetezca, es recomendable usar la que viene por defecto. No es difícil acostumbrarse.

En las siguientes entradas veremos en detalle cómo trabajar con los Pequeños y Grandes desarrollos.

Empezando a trabajar en el Extranjero (I)

Antes de empezar a buscar trabajo en Irlanda estuve empapándome de cómo buscar las ofertas, hacer las entrevistas, consejos, etc. Sobre estos temas hay mucha información, afortunadamente. Lo que ya no encontré tanto fue información sobre cómo afrontar los primero días/semanas/meses en un nuevo trabajo en el extranjero.

Si que hay muchas información sobre la vida en otro país, pero no enfocado tanto al día a día del trabajo. Es por eso que espero que mi experiencia sirva como caso práctico, sin más pretensión que ser una opinión más.

Me saltaré la parte en la que se busca casa, medio de transporte, etc, ya que como decía, hay mucha información sobre estos temas e iré al grano: el primer día de trabajo.

Si es la primera vez que trabajais en el extranjero lo que más va a pesar al principio es el idioma. Aquí cuanta más base tengáis mejor, pero creedme que al principio os va a costar y, según con qué personas, os va a costar mucho. Aquí van una serie de consejos sin un orden en particular:

• Mantened una actitud positiva: hay personas a las que las entenderéis en un 90%, otras un 50% y otras un 10%. Esto es normal, así que nada de agobiarse. Paciencia.
• Apuntad todo lo que os digan. Si la memoria en vuestro propio idioma a veces os falla, no os quiero ni contar lo que vais a olvidar en otro idioma.
• Preguntad si no habéis entendido algo, pero no seáis pesados. Si hay algo que no lo tenéis al 100% claro esperaos a trabajar en ello. Si después de haberle dedicado un rato no dais con lo que os piden, podéis volver a preguntar pero aportando vosotros nueva información. Que se vea por lo menos que le habéis dedicado tiempo y esfuerzo.
• Concentraos al principio en hacer las cosas bien, no en hacerlas rápido. Esto vendrá más adelante, ahora lo que importa es ser fiable y ganaros la confianza de los jefes y compañeros.
• Sed humildes, si veis cosas que sabéis que se están haciendo mal en vuestra nueva empresa no vayáis corriendo a decir a vuestros jefes todo lo que se hace mal. Primero porque podéis estar equivocados y segundo porque es mejor esperar a que tengáis la confianza de vuestros jefes y compañeros primero.

En el tema de las relaciones personales no voy a entrar porque aquí cada uno ya es mayorcito y debe saber como tratar estos temas. Lo único que diré es que hay que tener presente que igual que nosotros tenemos prejuicios sobre los extranjeros, ellos también los tienen sobre nosotros. Esto no es ni bueno ni malo, pero nos tiene que servir para entender ciertas situaciones a las que nos enfrentaremos.

Control de Versiones con Oracle: Forms y Reports

Cuando desarrollamos con Oracle, generalmente Forms y Reports, queremos tener un control de versiones para mantener nuestro trabajo a salvo y hacer un cierto seguimiento de como evoluciona el Software desarrollado.

Aunque hay muchas herramientas para esto, libres o no, nos vamos a enfrentar siempre al mismo problema. Los fuentes de Oracle son binarios (fmb/rdf/mmb/pll,...). Qué quiere decir esto? Pues que cuando queramos comparar entre versiones no podremos hacerlo como se hace en un fichero de lenguaje c, c++, java, etc, ya que en esos casos lo que tenemos es texto plano que podemos comparar.

Es cierto que podemos usar herramientas de terceros tales como "Forms API Master", pero no será tan rápido ni cómodo como en otros lenguajes. Nunca.

Así que lo mejor que podemos hacer es tener una lista de buenas conductas a la hora de mantener o desarrollar nuevo Software:

• Etiquetar dentro del código los cambios realizados con comentarios. 
• Usar siempre el mismo formato para las etiquetas.
• Si son cambios más o menos pequeños dentro del código y siempre que sea posible, meter el código dentro de un bloque PLSQL begin/end para hacer un 'Merge' de los cambios en otro sitio si fuese necesario.
• Comentar, comentar, comentar...
• Si el código va a ser mantenido por varios desarrolladores es vital que todos sigan las mismas pautas, sean las que sean. No debe hacer cada uno la guerra por su cuenta. Esto es generalmente lo más difícil y seguramente volveré sobre esto más adelante.

Personalmente creo que lo más razonable es usar Subversion, y de ello hablaré más adelanta en una entrada más o menos extensa dedicada a este tema.

Quick Tips

En este blog intentaré que las entradas sean breves y sencillas, para lo cual habrá categorías tales como:

• Reports Tip: pequeños consejos o recomendaciones o cuestiones típicas cuando diseñamos un report.
• Forms Tip: pequeños consejos o recomendaciones o cuestiones típicas cuando diseñamos un nuevo Form.
• PLSQL Tip: lo mismo, aplicaciones al mundo PLSQL
• SQL Tip: orientado sobre todo a evitar errores y al Tuning.