DevelUY

Planeta de desarrolladores uruguayos

26 de marzo de 2017

Enrique Almeida

Propuesta de proyecto colaborativo: GXWiki con balanceo de carga sin "Server Affinity"

Estoy buscando intersados que quieran participar en un proyecto colaborativo con GeneXus.

El objetivo primario del proyecto, seria crear una versión de GXWiki que permitiera funcionar instalándolo en varios nodos sin tener que configurar la afinidad por servidores.

El segundo objetivo es documentar que cosas impiden el tener aplicaciones GeneXus que funcionen sin afinidad, y para cada una de ellas proponer soluciones.

Que es "Server Affinity" y por que no es bueno tenerlo?

Tener una aplicación configurada con "Server affinity" significa que luego que un servidor atiende un pedido (request) de la aplicación, todos los pedidos sucesivos de dicho cliente, van a ser atendidos por el mismo servidor. Para aplicaciones de pocos usuarios y pocos nodos, esto generalmente no es un problema, pero si lo es para aplicaciones de muchos usuarios y/o proyectos que varios servidores en la nube.

Que inconvenientes tiene configurar el "Server Affinity"?

Como luego que un servidor atiende a un cliente, lo sigue atendiendo hasta que este finaliza la sesion, puede pasar que la carga quede muy mal balanceada entre los diferentes nodos. Si un nodo con mucha carga tiene problemas, el balanceador no puede pasar los pedidos de la aplicación a un nodo mas "libre" y por lo tanto la aplicación puede mostrar problemas, a pesar de tener nodos que podrían atender en forma correcta a los usuarios conectados.

Un ejemplo claro de esto, es cuando se genera una planilla excel y la misma se graba en disco local del server. Esta planilla, va a quedar en un directorio del tipo c:\Temp\PublicTempStorage o algo por el estilo. Luego voy a tener otro request que haga el link a dicha planilla para hacer la bajada desde el server al cliente.
Con afinidad en el servidor, los dos request van a ser en el mismo server.
Sin afinidad, se puede generar en un server, y luego intentar hacer el link a otro server, con lo cual no se encuentra la planilla en el disco local, pues se grabo a otro servidor.
Posibles soluciones, son tener grabar en un repositorio centralizado local, grabar en la nube, lograr hacer todo en solo request, etc.
No son problemas demasiados complejos, pero hay varios por resolver.

Algunos de los problemas a resolver serian:
* Manejo de Webssion (como configurar en C# y Java los servidores para tener sesiones compartidas)
* Blobs
* Full Text Search del wiki
* Upload de archivos
* Exportar a PDF

Porque es importarte este proyecto?

En el futuro, nuestras aplicaciones van a correr cada vez mas en los diferentes proveedores de plataformas, y es muy bueno para las mismas que no dependan de un nodo solo para funcionar.
El problema planteado, puede parecer que solo afecta a aplicaciones con muchos usuarios, pero es conveniente resolverlo de forma bastante general para que todos nos veamos beneficiados.

GeneXus viene mejorando desde hace tiempo la forma en que se generan las versiones para que sean mas fáciles de configurar con balanceo de carga, y pienso que este proyecto podría ayudar a coordinar entre mas personas que estén trabajando en el tema.

Si alguien está interesado, puede poner un comentario en el post o mandarme un mail a ealmeida en @concepto.com.uy y vemos como nos organizamos.




por noreply@blogger.com (Enrique Almeida), el 26 de marzo de 2017 a las 23:35

23 de marzo de 2017

Enrique Almeida

Paleta de colores en GeneXus


En las últimas versiones de GeneXus tienen la posibilidad de tener diferentes paletas de colores para las aplicaciones.

Lamentablemente me parece que los ejemplos que brinda GeneXus y otros proveedores de ejemplos (patrones y demás) no están aprovechando todo el potencial de estas herramientas. Muchas personas usan esos ejemplos con pocas modificaciones para generar sus aplicaciones, por lo que es importante que estos ejemplos brinden las "mejores practicas" desde el principio.

Para personas como yo, con "capacidades estéticas diferentes" , seria bueno tener contar con algo que permita cambiar el esquema de colores en forma mas fácil.

Que cosas no me gustan?

Nombre de los temas

Por ejemplo, el tema que viene con GeneXus 15 se llama Carmine (que es un color) lo cual indica que ese Theme seria para tener ese color.
A mi me gustaría que el theme se llame algo asi como ModernResponsive y tener varias paletas de colores asociadas.
Carmine es un buen nombre para una paleta de colores, pero no para un tema..

De esta forma, podria tener aplicaciones con varios esquemas de colores.

Nombre de Colores en la paleta

En los ejemplos que veo, me resulta muy dificil saber que afecto cuando cambio un color de la paleta, porque los nombres no son demasiado significativos.


Hoy los nombres de los colores son difícil de identificar con elementos de nuestras pantallas.

A mi me gustaría tener nombres del tipo

  • Label
  • Title
  • Subtitle
  • Data
  • DataReadOnly
  • Error
  • Warning
  • Base
  • BaseContrast
  • FormBackground
  • Column
  • BorderThin
  • Border


y varios mas.

A mi me gustaría que al definir un color en la paleta, ya se pudiera asociar un color de fondo y los de Hovered.

Seria muy bueno, que las paletas tuvieran un conjunto básico de nombres de colores, de forma de poder pasar una paleta de una KB a otra sin tener que hacer muchos ajustes.

Referencia a las colores

Todos las class deberían hacer referencias a algún color de la paleta y no directamente al código del color.
Los User Control, deberían hacer referencias a los colores de la paleta y no a colores.

Ejemplos

Seria bueno tener ejemplos (tal vez existen y yo no lo conozco) de KB con varias paletas de colores, de forma de poder aprender de los diseñadores, como adaptar una aplicacion a diferentes esquema de colores.

Por ejemplo, me gustaria que el GXWiki, tuviera varias paletas de colores y poder aprender desde ahi.

por noreply@blogger.com (Enrique Almeida), el 23 de marzo de 2017 a las 15:55

21 de marzo de 2017

Cristhian Gomez

Lanzamiento 2017 del GUG Montevideo

El sábado pasado estuve en el Lanzamiento 2017 del GUG Montevideo después de estar mucho tiempo sin asistir a un evento de la comunidad. Creo que en el pasado Gabriel Icasuriaga me empujaba o me contagiaba las ganas de participar y al no estar me sentía un poco perdido. En principio creo que hice mi duelo y pude volver con ganas y reencontrarme con esto tan lindo que es la comunidad de usuarios

por Cristhian Gómez (noreply@blogger.com), el 21 de marzo de 2017 a las 11:46

19 de marzo de 2017

Alejandro Segovia

Deferred Rendering – Part I

This week, work went into completing the initial implementation of a Deferred Renderer for Vortex. Every feature we had been incorporating into the Engine so far was building up to this moment and so, this time around, I finished writing all the components necessary to allow rendering geometry to the G-Buffer and then doing a simple light pass.

Initial implementation of deferred rendering in the Vortex V3 Engine.

Initial implementation of deferred rendering in the Vortex V3 Engine.

The image above shows the current functionality. Here, a box is created and its material is set to the “Geometry Pass” built-in shader. Other engines usually refer to this shader with another name, but ultimately, the purpose is always the same: populate the G-Buffer with data.

Once we’ve assigned the shader to the material, we attach a diffuse texture to it. This will be the object’s albedo value that we will write into the G-Buffer together with the corresponding position and normal data. Multi-Render Target support in Vortex is fundamental to efficiently fill the G-Buffer in only one render pass.

Next, we create a light entity. We mentioned the new light interface in Vortex from February. Light entities are gathered by the V3 renderer and, depending on their type, they are drawn directly on the framebuffer. The light shader is selected depending on the light type and it will access the readily available G-Buffer data to shade the scene.

The Postprocessing Underpinnings in the new renderer turned out to be essential for testing new ideas and debugging the implementation process every step of the way.

I’m quite happy with the results. Now that we have a complete vertical slice of the deferred renderer, we can iteratively add new features on top of it to expand its capabilities. From the top of my head, adding support for more light types and transparent meshes are two major features that I want to tackle in the upcoming weeks.

por Ale, el 19 de marzo de 2017 a las 06:30

16 de marzo de 2017

Cristhian Gomez

Table storage engine for "MiTabla" doesn't have this option... migrando MySQL

Estoy migrando una KB de GeneXus 9.0 a GeneXus 15 por lo que aproveche a realizar un rediseño de la aplicación y cambiando todo lo que se pueda. Aprovechando me instale una versión nueva de MySQL para dejar de usar la 5.1 que tenía funcionando en producción. Para esto hice un dump como lo hago siempre y al querer levantar el archivo me da el siguiente error: "Table storage engine for

por Cristhian Gómez (noreply@blogger.com), el 16 de marzo de 2017 a las 19:48

14 de marzo de 2017

Enrique Almeida

GUG Montevideo - Lanzamiento 2017

Llega la cita esperada

puertomadero2
El Sábado 18 de marzo a las 11:30  en Puerto Madero (Luis A. de Herrera 1172 casi 26 de marzo)
Inscripciones en: Meetup.com
Ticket $ 490
Formas de pago
  • REDPAGOS: Cta. 46855 “GUG Montevideo” 
  • Depósito en BROU , ITAU, SANTANDER (solicitar nros de cuenta a gugmontevideo@gmail.com)

Presentaremos el Plan de Trabajo del GUG para el 2017 y algunas sorpresas!
No te dejes estar, los cupos son limitados.

por noreply@blogger.com (Enrique Almeida), el 14 de marzo de 2017 a las 14:55

13 de marzo de 2017

Alejandro Segovia

G-Buffer

This week I started working on the G-Buffer implementation for the deferred renderer.

A test of the G-Buffer. Colors correspond to the coordinates of the vertices in world space.

A test of the G-Buffer. Colors correspond to the coordinates of the vertices in world space.

The G-Buffer pass consists in the first half of any deferred shading algorithm. The idea is that, instead of drawing shaded pixels directly on the screen, we will store geometric information for all our opaque objects in a “Geometry Buffer” (G-Buffer for short). This information will be used later in a lighting pass.

In sharp contrast to forward rendering, where the output of our rendering is the already-lit pixels, lighting calculations here are deferred to a later pass, hence the term deferred rendering.

The image above shows a simple test for the G-Buffer implementation in Vortex. In this test, we draw a number of boxes, with each vertex being colored according to their position in world space as read from the G-Buffer.

Notice how as vertices move left to right, we gain red (x translates to red). Similarly, as vertices move from bottom to top, we gain green (y translates to green). We cannot see it in this picture, but as vertices move from the back to the front, we also gain blue (z translates to blue).

Through this test we can also verify that moving the camera does not change the colors at all. This helps validate that our position data are indeed in world space.

This is going to be all for today. Next week, work will continue in the G-Buffer implementation. Stay tuned for more!

por Ale, el 13 de marzo de 2017 a las 05:29