Desarrollando desde la trinchera.

 Cuando estamos monitoreando aplicaciones distribuidas (en varias webapps o en varios nodos) es util tener centralizado el manejo de los logs de errores, de forma de poder ver en un unico lugar todos los errores que esta dando la aplicación. Esto es particularmente neceario cuando tenemos parte de nuestra aplicacion instalada de forma serverless.  Para hacer mas facil la identificacion de las causas de los problemas, lo que he visto que funciona bien, es mandar los ERRORS (y FATAL) y agregar a los mismos el Call Stack.  Para lograrlo, alcanza con agregar  %stacktrace{level} y cambiar level por el numero de niveles de la pila de llamada que quiero que muestre el log.  Por ejemplo, hay que cambiar el log.config, en la linea         <layout  type="log4net.Layout.PatternLayout">            <conversionPattern  value="%d{ISO8601} [%t] %-5p %c - %m   %stacktrace{10} %n"/>         </layout> De esta forma, cada vez que haga Log.Error('Se produjo un erro

 GeneXus utiliza log4net/log4j para generar el log tanto de las bibliotecas internas de Genexus como para el log de usuario.  Estas bibliotecas de log, son sumamente poderosas y permiten hacer un registro detallado de la actividad realizada en nuestra aplicación.  Para un proyecto especifico, necesitamos el registro del usuario y un identificador de la sesion en el log, de tal forma de poder filtrar luego por la actividad de un usuario especifico.  Vos a mostrar como lo resolví para .NET pero sirve también para java (aunque no lo probé).  Primero hice un procedure para definir una propiedad de log4net, con el código: SetLog4NetProperty //Log4NetPropertyKey and Log4NetPropertyValue son VarChar(100) CSHARP    log4net.ThreadContext.Properties[  [!&Log4NetPropertyKey!]  ] = [!&Log4NetPropertyValue!]; Luego del Login en la aplicación hago: SetLog4NetProperty('GAMUser',&GAMUser.Name) y en los archivos de configuración del log (log.config y log.console.

 Acompañando la tendencia de la industria, en la comunidad GeneXus estamos pasando de tener aplicaciones monolíticas de una sola KB, a aplicaciones de multiplex KB.  No hablo solo de microservicios, que pueden ser uno de los casos aca contemplados (*), sino de algo un poco mas general de tener varias KB que conforme una solución.  Como todo en esta vida, cada cambio trae ventajas y también tiene algunos inconvenientes que es bueno tener en cuenta.  Las ventajas de tener todo en una KB monolítica: Todo en una misma base de datos con integridad transaccional.  Los cambios se reflejan en todos los programas  Es mas facil de instalar La comunicación entre objetos es mas rapida Que cambia cuando se tiene multiples KB?  El deploy es bastante mas complejo y tambien es mas complicada la comunicación entre las diversas KB.  Como GeneXus hoy esta enfocado a aplicaciones mono-kb, se necesitan algunas herramientas que aun no están disponibles entre las standard de GeneXus.  Por ejemplo: Cambiar pr

Quienes tienen aplicaciones GeneXus generadas con .NET Framework, deberán migrarlas a .NET Core. Esta forma de decirlo, es usando la nomenclatura vieja de Microsoft, pues ahora deberia decirse que hay que pasarse a .NET (a secas).  Las nuevas versiones de .NET traen como ventaja la de ser mas liviano su consumo en ejecución y la de poder ejecutar en Linux y en Windows.  Quienes programamos con GeneXus tenemos el camino un poco mas fácil que el resto pero igual hay que hacer un trabajo lindo de migración del generador .NET Framework al generador .NET.  Esto es indispensable, pues entiendo que el generador .NET Framework no va a tener mejoras en el futuro y todos los cambios se realizaran únicamente en el generador .NET.  Como toda migración, va a traer diferentes dolores de cabeza.  Por ejemplo, tengo el siguiente proyecto.  KB Mediana, generada con .NET Framework.  Utilizar PDFTools para concatenar archivos PDF (no funciona aun en .NET Core) Necesita usar Azure Queues para realizar un

GeneXus 17 introdujo el objeto API . Considero que va a tener un rol importante en el desarrollo de aplicaciones de los próximos años.  En un par de charlas brindadas por diferentes empresas, he visto que lo presentan como un objeto que "agrega una capa de servicios REST a nuestra aplicación" . Si bien esta es una de las funcionalidades del objeto API es una simplificación que sirve para que se entienda la utilidad, pero no me parece que sea una buena definición.  El objeto API, lo que hace es definir una interfaz de los métodos para que puedan ser usados por el resto de la aplicación o por aplicaciones externas.  En el objeto API, yo distingo dos partes bien diferenciadas. Por un lado, tenemos la lista de métodos/servicios expuestos, con sus parámetros de entrada, parámetros de salida y todo lo necesario para lograr procesar los parámetros de entrada y devolver la salida esperada.  Esta parte es la que tiene el verdadero conocimiento y es la que va a perdurar mas en el tiemp

Una tendencia que es clara desde hace unos cuantos años, es que los usuarios exigen cada vez mas, poder modificar / configurar / cambiar el funcionamiento del sistema, sin tener que recurrir a programación.  Esto es una tendencia basada en que los ciclos de programación / instalación por mas que se han acelerado, no alcanzan en rapidez a la velocidad que exigen los negocios actuales.  El conjunto de cambios en un sistema es un conjunto difícil de limitar o describir y en todas las épocas existieron y existirán cambios que necesiten cambios en programación, otros que exigen cambio de configuración o en instalación y otros que pueden hacerse en momento de ejecución.  La tendencia que veo, es que antes era mucho mayor el porcentaje de cosas que se resolvía programando o cambiando el código del sistema y los clientes ahora piden que se pueda hacer  Cambios en Design Time.  Hace varios años, para hacer un cambio en el funcionamiento de un sistema, por mas chico que fuera, se necesitaba hace

 Al hacer una aplicación, no es trivial darse cuenta si la misma va a persistir muchos años o va a ser sustituida en poco tiempo.  Si se piensa tener una aplicación que dure mucho, conviene tomar algunas precauciones para que sea mas fácil su transición tecnológica.  En un esquema básico de los diferentes componentes de la aplicación tenemos  Toda aplicación tiene estos componentes, aunque no en todas las aplicaciones están separados y se instalan todos juntos.  La interfaz de usuario (listados, formularios, paneles) son los que a lo largo de los años han sufrido cambios mas profundos y han necesitado mas reprogramaciones.  Las pantallas de caracteres, luego los winforms, después los webforms y ahora los paneles de SD.  Estos son cambios provocados por cambios tecnológicos que han implicado cambios en nuestras aplicaciones.  En la capa de lógica de negocio, hay muchos cambios provocado por cambios en la forma de trabajar (por ejemplo antes se necesitaban muchos listados y ahora no) y c

 En el ultimo evento GeneXus , hicieron hincapié en que GeneXus permite tener "Eternal youth for your code" Por un lado, el codigo es cada vez mas importante, pero por otro lado, cada vez intentamos tener menos codigo y el mismo queda bastante escondido. Por eso creo que lo mejor es hablar de aplicaciones que se mantengan actualizadas en vez de juventud eterna. Pero mejor le dejo eso a los de marketing que saben de esas cosas. De lo que si puedo opinar, pues hace muchos años que mantengo aplicaciones GeneXus es de como hacer para tener aplicaciones actualizadas a las ultimas tecnologias.  Lo fundamental, es tener claro que una porción de la aplicación va a tener que ser cambiada para adaptarse a los cambios tecnológicos y tratar de minimizar dicha porcion de codigo, es lo que hace que sea mas o menos fácil el cambio de version.  Interfaz de Usuario En primer lugar, las cosas que sufren mas los cambios son aquellas que tiene interfaz de usuario. Si analizamos los cambios por

Necesitaba utilizar Procedures que estaban expuestos como SOAP desde otra KB, que venian con un namespace incorrecto.  En mi KB debia usar el Namespace default, pero habia algunos que tenian un namespace fijo.  Lo que hice, fue procesar el archivo de export para eliminar el tag en el XML.  <Properties> <Property><Name>Name</Name><Value>Movimientos</Value> </Property> <Property><Name>ExternalNamespace</Name><Value>http://tempuri/Incorrecto</Value></Property> <Property><Name>IsDefault</Name><Value>False</Value> </Property> </Properties>     </Object>     <Object parentGuid="17460adf-89c4-f141-237b-252d2ccfdd60" user="" ..... Para cambiarlo, use Notepad++ y busque la expression regular <Property><Name>ExternalNamespace<\/Name>[\s\S]*?<\/Property> Volvi a importar y con eso logré eliminar esa propiedad en muc

  Quienes estudiamos computación en algún momento de la carrera nos han enseñado de la importancia de la cohesion, el acoplamiento y la separación de intereses. * Esas características tienen fuerzas en algún sentido opuestas, y la práctica nos ha enseñado a que cuando se logra hacer programas, clases, módulos, servicios, sistemas enteros, etc que tengan ALTA COHESIÓN, BAJO ACOPLAMIENTO e INTERESES SEPARADOS, es mucho más fácil mantener y agregar cambios a los sistemas. En conclusión, se tiene mayor productividad, se pueden hacer más cosas, con menos esfuerzo.  Esto es algo un poco contraintuitivo, pues lograr esto en los sistemas, da más trabajo al principio, pero se paga con creces en lo que se ahorra en el futuro.  En lo que no me había puesto a pensar nunca, era en aplicar estos conceptos, a los grupos humanos que producen software. Estudiando porque algunos grupos logran una alta productividad y otros no tanto, veo que muchas veces los grupos que tienen problemas de productividad e

 En el foro de la Beta de GeneXus, se quejaban que era una tarea engorrosa el cambiar propiedades de las conexiones a base de datos.  Es una tarea sumamente engorrosa y se comenten muchos errores en el proceso.  Estoy en un proyecto, donde vamos a necesitar unificar muchas propiedades de al menos 5 KB y ademas, personalizar muchas propiedades, por lo que valia la pena dedicarle un tiempo a automatizar dicha tarea.  Una de las contras que planteaban, era que no se puede exportar e importar las propiedades, pues hay muchas que son NO EXPORTABLES.  Desde hace tiempo, se tienen tareas MSBUILD para poder cambiar propiedades de la KB / Version / Ambientes / Generadores / Repositorios de Datos.   Había hecho varios scripts para cambiar propiedades, pero mi problema siempre había sido que tenia que encontrar el nombre de la propiedad, para poder implementarlo.   Para esto, exportaba las propiedades, abría el archivo XML, adivinaba cual era la propiedad, buscaba el nombre y ponía el valor que

En mi trabajo me encuentro a menudo con el siguiente problema: Optimizar un determinado objeto GeneXus que anda lento, o consume demasiados recursos (memoria, cpu, disco, ancho de banda, etc).  Por lo general, son objetos de los que son Legacy Code.  Me gusta la definición  Legacy Code = Code without automated unit test.  Tambien es comun que no lo haya programado y tengo una idea de que es lo que hace ese objeto, pero no un conocimiento profundo de como funciona.  Resulta entonces bastante peligroso hacer un cambio en un objeto para lograr que funcione mejor, sin tener una forma de comprobar que sigue teniendo el mismo comportamiento que antes.  Una forma de trabajo que me ha resultado muy util, es ejecutar muchas veces el objeto que debo cambiar, con una combinación de parámetros que sean representativos de los parámetros habituales y de borde del objeto y registrar su resultado. Luego de hacer la modificación, volver a ejecutar las mismas pruebas y asegurarme que todo sigue igual, y

  Hice un video de como utilizar la metodología de desarrollo TDD (Test Driven Development) con GeneXus y GXTest.   Me quedó más largo de lo que quería pero ya voy a aprender a resumir mejor.  Update: A pedido del publico, mejoro la resolucion del video. 

Estoy intentando hacer un pattern para lograr crear servicios que se puedan crear desde la estructura de una entidad (representada por una transacción).  La documentación va ir  quedando aqui .  Copio aqui la información para que quede documentado.  Objetivo: Facilitar y centralizar el acceso y modificación de los datos de una entidad.  Uso Dada una Entidad (en forma de transacción) facilitar el acceso a sus datos con operaciones comunes.  Ejemplo Dada la transacción Customer Customer * CustomerId CustomerName //tiene indice unico por CustomerName CustomerAddress CustomerType se pueden poner dicha transacción como BC y generar los objetos para lograr: //CONSULTAS (QUERIES) &CustomerCollection = GetAll () // Se implementa con un Customer_DP - Data provider &CustomerCollection = GetBy < Condition >( &ConditionParameters ) // Se implementa con un Customer_DP<Condition> - DataProvider que usa un Data Selector por <Condition> Customer_DS_Conditio