Ir al contenido principal

Tres nombres que nunca se deben usar

La historia es larga, vamos al final:  hay tres nombres que nunca se deben usar:

"Ultimo" o "Final" - para el nombre de un archivo, por ejemplo, para una propuesta o documento de spec de algo. Muy probablemente no sea la última ni la final. Eventualmente ud u otro se encuentre estudiando o editando un documento que piense que es el "ultimo" o la version "final" porque así lo indica su nombre pero NO lo es.  Tip: http://gxwiki.genexus.com/

"InvoicesBuild12100" - jamás incluir el nro de build en el nombre de una KB, salvo que sea un respaldo o algo que ud destruirá o renombrará (*) a la brevedad. De lo contrario en unos dias (horas? minutos?) estará trabajando con el build 12108 en una KB que se llama build12100, nada más equivocado o por lo menos confuso.

"DBServer208" - jamás incluir el propósito de un server en su nombre. Probablemente esos servers no cumplirán esa función mucho tiempo y serán reciclados con otro propósito. Ud se encontrará haciendo el deployment de unas DLLs/Classes en un server que se llama "DBalgo" y la base de datos la creará en un server de producción que se llama "AppBackupServer01" o configurando el acceso a una red vía un proxy que se llama ExchSrv. La realidad es demasiado dinámica para que un server sirva para lo mismo por mucho tiempo.

NOTAS:
1. Soy el primero en cometer esos errores así que, como en la escuela, lo escribo a ver si me exorcizo
2. Igual hoy me encontré con 2 de estos ejemplos que no eran de mi autoría así que "mal de muchos.."
3. No crea en el rename porque no es fácil, por ejemplo, no puede renombrar un documento que tiene abierto o una KB que el IIS tiene un directorio virtual apuntando y ni que hablar que renombrar un server puede dejar a un planeta a pie (a pesar del DNS, IP y todo eso).

Comentarios

  1. Y tenes alguna sugerencia de como nombrar los servidores, las base de datos y/o las aplicaciones?

    ResponderBorrar
  2. Hummm capaz un nombre de fantasía nomás onda "Visigoten" o serializado ese onda "Visigoten01", "Visigoten02".

    Sino "Server1" "Server2", digamos que algo que no indique mucho pero facilmente memorizable.

    El punto es que prefiero no saber cual es el propósito de un server que pensar que si se y en realidad estar en un error.

    Las bases de datos... ni idea.. diría que normalmente soportan una aplicación que tiene un fin, talvez lo mejor sea ponerle un nombre relacionado a eso pues dificilmente cambie. Una aplicación de "facturación" se podría llamar "facturacion" y listo, dificilmente se transforme en una aplicación de RRHH. Sino nombres tipo "Consolidada" o "Corporativa", no se, esas creo que cambian menos su propósito.

    Aplicaciones, aplica lo mismo que a base de datos.

    La otra es consultar a Les Luthiers que tienen experiencia :)

    ResponderBorrar

Publicar un comentario

Entradas más populares de este blog

Abrir links con aplicaciones nativas y no el browser (deeplinking)

El problema que tengo con algunas aplicaciones Android/iOS es que cuando recibo un link por algún medio (mail, tweet, etc) al abrirlo me lo abre con el browser, en lugar de abrirlo con una aplicación nativa asociada a ese “contenido”. Por ejemplo, si recibo un link a un tweet espero que lo abra con alguna aplicación de twitter que tenga instalada y no con el browser. De modo análogo si recibo un mail con una nota de prensa de un medio X y tengo la aplicación de ese medio X instalada, espero que el link lo abra con la aplicación nativa y no con el browser. Lo mismo quisiera con mi aplicación de "banking" o cualquiera que tenga instalada y sepa manejar ese "contenido" (link). Los motivos son bastante obvios pero los resumo en: la experiencia de usuario es mucho mejor en la aplicación nativa que en el navegador. Parte importante del tema es que el mismo link sea válido tanto para ver el contenido en el browser como para verlo en la aplicación, porque como prove

¡A la salud de mi KB!

Es bueno, especialmente en "bases de conocimiento" (KB) que han pasado por varias versiones de Genexus, chequear su "estado de salud". En este sentido KBDoctor  es una herramienta que ayuda mucho, principalmente desde el punto de vista del "modelo" Genexus (atributos, calls, definiciones de variables, etc) representado en una KB. También es útil revisar la salud de los archivos que lo soportan. Hasta la 9.0 eran archivos C-tree (los famosos .DAT) que tenían indices (los famosos .IDX) y teníamos en "rebuild -y" que mejoraba esos archivos y sobre todo reconstruía los indices. A partir de la X las KBs se almacenan en MS SQL Server por lo cual la administración de la misma pasó de ser un "file server" a un "database server". En este sentido algo que me ha dado muy buenos resultados es el "CheckKnowledgeBase".

Rocha:Constantes tipo fecha

En la Rocha se soportan constantes del tipo fecha o fecha-hora con formato ANSI/ISO (AAAA-MM-DD HH:MM:SS).  Tecnicamente (Sintáxis): <date>::=    [0-9]{1,4}"/"[0-9]{1,2}"/"[0-9]{1,2} | [0-9]{1,4}"."[0-9]{1,2}"."[0-9]{1,2} | [0-9]{1,4}"-"[0-9]{1,2}"-"[0-9]{1,2} <hms>::=    [0-9]{1,2}[ap] | [0-9]{1,2}":"[0-9]{1,2}[ap]? | [0-9]{1,2}":"[0-9]{1,2}":"[0-9]{1,2}[ap]? <constant> ::=   "#"<date>"#" | "#"<date> <hms>"#" | "#"<hms>"#" Funcionalmente Se pueden utilizar esas constantes en las reglas, eventos, propiedades, etc (todo lugar donde se utilice el parser): Algunos ejemplos básicos: &FechaInicial=#2007-01-01# &FechaHoraInicial=#07-1-1 11:15a# &HoraInicial=#11a# Me parece bueno no tener que escribir funciones (CTOD, TTOC) sobre constantes tipo char para lograr una fecha y mucho mejor aun en