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

Liberar una versión: el fin del principio

Quienes desarrollamos software buscamos afectar positivamente la vida de las personas a través de nuestras aplicaciones. Ese es nuestro objetivo final, ese es nuestro éxito. Quienes desarrollamos , que ayuda a nuestros colegas en esa misión, solo tenemos éxito cuando ellos tienen éxito, por eso solemos decir que cuando liberamos una versión es "el fin del principio". Es un escalón fundamental, pero solo el primero. Tuve el privilegio de formar parte del equipo de y de su pero a su vez no he podido dedicarle tanto tiempo   como quisiera, casi no he podido  , ni  he podido leer. El mundo siguió girando, hay  , hay que me perdí y . Casi de casualidad me enteré del encuentro del a partir del 16/marzo en Montevideo. En cualquier caso: ¡el esfuerzo valió la pena!. Ahora que está siendo liberada en el   , hay que celebrar porque aplica aquello de "release is a feature". Podría tirarme en mi casa y estrenar mi  con una buena peli o sino aprovechar ir al un poco má...

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...

Mi primer chatbot con whatsapp

No voy a hacer "apología de whatsapp" pues es claro para todos que es una herramienta de comunicación que todo el mundo (al menos occidental) tiene y usa a diario. Siendo así ¿que tal si mi aplicación pudiera responder por ese medio? ¿Qué skills necesitaría? ¿Qué otros recursos? Revisé algunos contenidos al respecto, por cierto los recomiendo, especialmente los producidos en el GX29:  https://meetings.genexus.com/2019/sessions/chatbots Es tremendo lo que se puede hacer alrededor del tema. Sin embargo lo que yo quería era algo bien sencillo, no quería tanto la parte de NLP (PLN), IA, etc que es un camino muy interesante pero que implicaba más trabajo y lo mio era explorar, divertirme, hacer algo útil y aprender en el camino (algunos le llaman "procastinar":)). Quería probar la utilidad de "dialogar" con mi aplicación vía Whatsapp, generar otras ideas a partir de ver y sentir algo funcionando, resolviendo un problema real, un prototipo de bajo costo....