Editorial #1

Estimados Colegas de los GUGs
El emprendimiento que dimos en llamar RosarioGX, cuyo principal objetivo es el intercambio profesional entre miembros de la comunidad, nos ha dado hasta hoy importantes satisfacciones. Entre ellas debemos mencionar la oportunidad de conocernos personalmente y tomar contacto entre los colegas que trabajamos con GeneXus. Se han realizado varias actividades desde nuestro primer encuentro en el mes de diciembre de 2006 que también han sido muy satisfactorias. El II Encuentro en marzo de 2007, por ejemplo, fue un logro muy grande contando con más de 130 asistentes y representantes de Artech que vinieron a Rosario especialmente para acompañarnos y colaborar en el evento. Recordemos que el mismo fue declarado por el Honorable Concejo Deliberante de la Ciudad de Rosario como "Evento de Interés Municipal". A partir de entonces se realizaron reuniones organizativas de las cuales surgió un documento de lineamientos generales para brindar un marco de funcionamiento del grupo y especialmente de sus organizadores, que constituye un antecedente que puede ser tomado como modelo por otras comunidades. Otras actividades, tales como las Sesiones Técnicas o ST, que a la fecha han sido cinco y en las que podemos contar un promedio de 16 aistentes en cada una, nos permiten actualizarnos profesionalmente en pequeñas reuniones "tecno-sociales", respondiendo siempre a las necesidades en los temas expresadas por la comunidad. Intercambiamos conocimientos, compartimos experiencias y materializamos el objetivo fundamental mencionado al principio en un plano personal en lugar de hacerlo totalmente en el ciberespacio. Nos gusta vernos las caras y estrecharnos las manos.
A este esfuerzo, se ha sumado GxRíoCuarto que comparte los mismos objetivos y realiza similares actividades. En conjunto con ellos editamos este primer número del NewsLetter, que pretende mantenernos informados de novedades en el plano tecnológico y también social acerca del funcionamiento de los GUGs, dejando siempre abierta la posibilidad de que otros GUGs se sumen en los próximos números.
Esperamos hacer más y más, y para ello es necesario que todos aquellos miembros de la comunidad que deseen colaborar aportando un poquito de su tiempo y sus conocimientos se acerquen a las reuniones organizativas y se sumen trabajando a los emprendimientos.Hasta ahora, los resultados nos muestran que estamos en el camino correcto.
Vamos por más!

Tips and Tricks

1) Aplicar la nomenclatura GIK a toda velocidad
2) Generar planillas Excel preformateadas

1) Artech no solo nos recomienda el uso de la nomenclatura GIK para ordenar nuestro trabajo, sino que ademas nos facilita su aplicación.
¿Cómo?
Simplemente cuando estamos creando los atributos de las transacciones (structure) o de los dataviews, al pulsar la tecla ". (punto)" Genexus entiende que queremos que el atributo lleve el nombre de la tabla como prefijo.

2) Si querés que tu aplicación genere planillas Excel estéticamente elaboradas hacé lo siguiente:
Formateá la planilla excel, definí las fórmulas, los formatos, gráficos y todas las funciones que necesites.
Desde la aplicación GX abrí esa planilla con variable.Open(FileName), salvala con otro ruta/nombre con variable.Save() sin hacerle Close. Luego trabajá como lo hacías normalmente grabando las celdas. Por último la salvás nuevamente.

Mi Escritorio

En esta sección mostraremos el entorno de trabajo de los colegas de la Comunidad. La idea es conocer y dar a conocer ese lugar donde pasamos tantas horas de nuestra vida. Los interesados en participar en esta sección pueden enviar sus fotos a la dirección de contacto del Newsletter (newsgug@gmail.com) o bien a los referentes de su GUG.
El éxito de la misma depende exclusivamente del material que nos manden.
No necesariamente debe ser una imagen tomada con una cámara de última tecnología, una tomada con celular también sirve!! Así que ya saben... a fotografiar los escritorios se ha dicho...! No vale hacer orden antes de sacar la foto!!!


En este número y para comenzar, lo hacemos con una celebrity de la comunidad GeneXus, dos veces premiado por Artech y la comunidad en general como Most Valuable Member (2005 y 2006) y uno de los recientes ganadores del GxChallenge 2007 con el proyecto GxWebResources, con dos Premios "People´s Choice" y el de "Proyecto que agrega mayor valor a la comunidad".


Con uds. [Gab]riel Medina miembro del GUG GxRioCuarto.

El lenguaje de programación Ruby

Por Javier Smaldone
http://www.smaldone.com.ar
Miembro de GxRioCuarto

Historia

El origen de este lenguaje es bastante atípico. Fue desarrollado por el japonés Yukihiro Matsumoto (más conocido como "matz") en el año 1995 y durante sus primeros años de vida su uso no se extendió más alla de la frontera de Japón, debido a la falta de documentación en otro idioma. A finales del año 2001, gracias a la aparición de un libro de O'Reilly en inglés [0] , comenzó a ser conocido internacionalmente y en el 2005 alcanzó la fama a través de "Ruby on Rails", un framework para el desarrollo de aplicaciones web escrito en Ruby.
Un detalle curioso aparece si comparamos la difusión de Ruby con la de Python. En los últimos 10 años, Python (que data de fines de los '80) ha sido el lenguaje de scripting de mayor crecimiento en todo el mundo. El auge de Ruby está apenas empezando y en los últimos 2 años ha tenido un crecimiento mucho mayor a Python. Sin embargo en Japón, donde ambos lenguajes han sido conocidos desde su comienzo, Ruby siempre ha sido más usado que Python.
Muchos programadores se acercan a Ruby a través de "Ruby on Rails" (las aplicaciones desarrolladas con este framework son, básicamente, programas Ruby que usan las librerías de RoR). Sin embargo no debemos confundirnos: el hecho de que Rails esté desarrollado y permita desarrollar en Ruby, no significa que este lenguaje sirva exclusivamente para construir aplicaciones web. En realidad, son las virtudes de este último las que han posibilitado desarrollar un framework tan potente y simple como Rails.

Características

Ruby es un lenguaje totalmente orientado a objetos que incorpora características de SmallTalk, Lisp, Eiffel, Ada y Perl. En palabras de su creador: "Quería un lenguaje de scripting que fuera más potente que Perl y más orientado a objetos que Python[1] ".
En rigor, el lenguaje no incorpora ninguna característica realmente innovadora (inclusive, "revitaliza" algunas técnicas presentes en Lisp en 1958 y en SmallTalk en 1980). Su principal virtud es la forma simple en que integran mecanismos como orientación a objetos, clausuras y macros, entre otros. El resultado es un lenguaje simple (de fácil lectura), pequeño (muy pocas palabras reservadas y construcciones) y extremadamente potente (con una expresividad muy cercana a la de los lenguajes funcionales).
Ruby, como todo lenguaje de scripting, es interpretado. Existen varias implementaciones del intérprete, además de la "oficial". Una facilidad adicional, tanto para el aprendizaje como para la depuración de programas, es la disponibilidad de "irb", un intérprete interactivo (ejecutado en la línea de comandos), que permite tanto "jugar" e investigar el lenguaje, como también depurar clases de un sistema complejo.

Presentación del lenguaje

En Ruby todos son objetos. La forma de invocar un método en un objeto, es mediante expresiones "objeto.metodo". El uso de paréntesis en este tipo de invocaciones es totalmente opcional, de manera que "cuenta.depositar(20)" puede escribirse también como "cuenta.depositar 20". Otra característica llamativa es que los nombres de métodos pueden incluir, por ejemplo, el caracter "=", de manera que podemos definir un método "saldo=(valor)" y luego escribir "cuenta.saldo = valor" (nótese el espacio introducido antes de "=", permitido gracias al "azúcar sintáctica" de Ruby).

Veamos algunos ejemplos:

class Cuenta

  def initialize(saldo_inicial)

    @saldo = saldo_inicial

  end

  def saldo

    @saldo

  end

  def depositar(monto)

    @saldo += monto

  end

  def extraer(monto)

     if monto < @saldo then

       @saldo -= monto

       return true

     else

       return false

     end

  end

end

a = Cuenta.new 20

puts a.saldo          

a.depositar 10

puts a.saldo

if a.extraer 15 then

   puts "Extracción realizada"

else

   puts "Extracción superior al saldo"

end

puts a.saldo

Hemos definido una clase "Cuenta", que tiene los métodos "initialize", "saldo", "depositar" y "extraer". Luego hemos creado una instancia (objeto) "a" y lo hemos utilizado.

La salida de este programa es:

20

30

Extracción realizada

15

Examinemos este ejemplo:

• Las clases se nombran con el primer caracter en mayúsculas ("Cuenta"). En caso de usar varias palabras, se utiliza la notación "camello" (por ejemplo "CuentaCorriente").
• Los métodos y variables se nombran en minúsculas.
• Las variables cuyo identificador comienza con "@" son "variables de instancia" o atributos (por ejemplo, "@saldo").
• El método "initialize" de una clase, se invoca al crear una instancia de la misma. La creación de un objeto se realiza llamando al método "new" de la clase en cuestión, y los parámetros que éste reciba, serán pasados a "initialize" (por ejemplo, "Cuenta.new 20").

Ruby también permite variables y métodos de clase. Por ejemplo, podríamos modificar nuestra clase "Cuenta" de la siguiente forma:

class Cuenta

  @@cuentas = 0

  def self.cuentas 

    @@cuentas

  end

  def initialize(saldo_inicial)

     @saldo = saldo_inicial

     @@cuentas += 1

  end

  ... 

end

Hemos definido una variable de clase "@@cuentas", que será compartida por todas sus instancias (objetos). Además, hemos definido un método de clase "cuentas" (nótese la palabra "self" en la declaración, que indica que el método pertenece a la clase y no a sus instancias). Luego, podemos invocarlo directamente en la clase "Cuenta". Por ejemplo, si hiciéramos lo siguiente:

a = Cuenta.new 20

b = Cuenta.new 50

puts Cuenta.cuentas

Obtendríamos como salida "2".

Existe una serie de convenciones que simplifican la comprensión de los programas escritos en Ruby. Por ejemplo:

• Si un método toma un valor y lo asigna a un atributo (comúnmente llamado "setter"), ese método debería llamarse igual que el atributo, con el agregado del caracter "=". Esto, sumado a la posibilidad de omitir los paréntesis, hace que la invocación de ese método parezca una asignación (como vimos en los ejemplos anteriores).
• El nombre de un método que devuelve un valor lógico, debería terminar con el caracter "?". (Podríamos implementar un método "puede_extraer?" en la clase "Cuenta" y luego escribir "a.puede_extraer? 40".)
• El nombre de un método que modifica el objeto sobre el que es invocado, debería finalizar con "!". (Un ejemplo de esto son los métodos "sort" y "sort!" de la clase "Array". El primero devuelve el arreglo resultante de ordenar el arreglo original, en tanto que el segundo ordena a este último.)

Ruby y las "clausuras"

Las "clausuras" son mecanismos que nos permiten pasar bloques de código como parámetros en la llamada a una función. En dichos bloques, podemos hacer referencia a identificadores definidos en el contexto (alcance o "scope") en el que se realiza la llamada. Veamos un ejemplo.

La clase "Array" provee un método "each" que recibe como parámetro un bloque y lo ejecuta para cada elemento del arreglo. El siguiente código:

saludo = "Hola "

a = ["Gabriel", "Pablo", "Javier"]

a.each{i puts saludo + i}

Produce la siguiente salida:

Hola Gabriel

Hola Pablo

Hola Javier

La expresión "i" establece la ligadura de el identificador "i" con cada uno de los elementos del arreglo "a". Luego, el bloque se ejecuta para cada uno de los elementos de este último. Nótese que, en el contexto de arreglo "a" no existe el identificador "saludo", sin embargo, el bloque es pasado como parámetro incluyendo las ligaduras al contexto en el que fue definido. Esta es la "magia" de las clausuras.

Otro ejemplo: supongamos que tenemos un arreglo "c" de objetos de clase "Cuenta" y deseamos calcular la suma de todos los saldos. Para ello, podemos hacer lo siguiente:

sumatoria = 0

c.each{i sumatoria += i.saldo}

puts sumatoria

Otro método de "Array" que soporta bloques como parámetros es "select", que devuelve sólo aquellos elementos para los cuales el bloque devuelve "true". Veamos otro ejemplo:

d = c.select{i c.saldo > 1000}

Esto selecciona (filtra) de "c" aquellas cuentas con un saldo mayor a 1000 y asigna el arreglo resultante a "d". Nótese cómo el texto del programa y su lectura (aún en castellano) son bastante similares. (Más adelante hablaremos sobre "expresividad".)

Clases "opensource"

Cualquier lenguaje de implementación "abierta" nos ofrece la posibilidad de modificar su librería estándar de funciones. En Ruby esto es trivialmente simple, ya que si ya hemos definido una clase "MiClase", una declaración del tipo "class MiClase ... end" añadirá las declaraciones introducidas a la definición ya existente.

Por ejemplo, si estamos acostumbrados a usar los métodos "head" y "tail" que devuelven, respectivamente, el primer elemento de una lista y el resto, los extrañaremos en la clase "Array" de Ruby. Pero, afortunadamente, podemos escribir la siguiente definición:

class Array

  def head

    self[0]

  end

  def tail

    slice(1..-1)

  end

end

Con esto, hemos añadido los métodos "head" y "tail" a la clase "Array" y, por lo tanto, pueden ser invocados en cualquier otra clase que la utilice. De esta forma es que las clases de Ruby son totalmente abiertas, ya que en cualquier lugar de nuestro sistema en donde se requiera, podemos extenderlas o modificarlas.

Expresividad

Por "expresividad" entendemos la posibilidad de expresar "claramente" mediante el código de un programa qué es lo que este realiza. Todos sabemos que algunos lenguajes, aunque quizás muy eficientes, son extremadamente "oscuros", y requieren de un buen rato estudiando cada línea y cada construcción para averiguar exáctamente qué hace un programa y cómo lo hace (al extremo en que podríamos hablar de lenguajes de "sólo escritura").

Ruby, a través de sus construcciones, nos ofrece la posibilidad de programar de forma "declarativa", esto es, que el código de nuestros programas resuelva el problema y, a la vez, sirva de especificación del mismo.

Tomemos como ejemplo el algoritmo de ordenamiento "quicksort". En su forma más simple, este algoritmo podría enunciarse como sigue:

Se toma el primer elemento de la lista a ordenar, se ubican a su izquierda los valores menores que éste, a su derecha los mayores, y luego se aplica recursivamente el mismo algoritmo en ambas partes.

De una manera aún más sintética, podríamos decir que hacer "quicksort" de una lista es aplicar "quicksort" a los menores que el primer elemento, luego agregar este y finalmente "quicksort" aplicado a los mayores.

Implementar "quicksort" en lenguajes como Java, C#, PHP o Pascal requeriría de más de 50 líneas de código y su comprensión, para alguien que no conociera el algoritmo de antemano, no sería trivial. En Ruby, utilizando los métodos definidos anteriormente en "Array", podríamos escribir lo siguiente:

class Array

  def qs

    empty? ? [] : tail.select{e e<=head}.qs + [head] + tail.select{e e>head}.qs

  end

end

El método "empty?" devuelve "true" si y sólo si el arreglo está vacío. El operador de asignación condicional "a ? b : c" evalúa la expresión "a", si ésta es verdadera devuelve el valor "b" y en caso contrario, "c".

Habiendo aclarado esto, la lectura de nuestro "quicksort" ("qs") es muy simple: Si el arreglo es vacío, devuelve un arreglo vacío ("[]"), y en caso contrario, devuelve el resultado de aplicar "qs" a los elementos menores al primero ("head"), seguido de éste elemento, seguido del resultado de aplicar "qs" a los elementos mayores al primero.

Como podemos ver, la implementación de "quicksort" en Ruby es prácticamente su especificación. ¡Esto es expresividad!.

Programación divertida

20:11 ST: Talleres 2 -vs- Instituto 0

La expresividad de Ruby se combina con un principio llamado de "menor sorpresa". Esto significa que las cosas se llaman como uno esperaría que se llamen y funcionan de la manera en que uno esperaría que funcionen. Sumando ambos elementos, el resultado es un lenguaje en el que resulta "divertido programar".

La realidad nos muestra que muchas veces los programadores desperdiciamos la mayor parte del tiempo (y de nuestra energía), lidiando con particularidades de los lenguajes que utilizamos. Esto llega a ocasionar que muchos pierdan la pasión que en los primeros años sentían por esas largas horas (¿días? ¿noches?) escribiendo código. Ruby, en cierta forma, fue creado para tratar de evitar esta situación. En palabras de matz:

"Quería minimizar mi frustración mientras programaba, por lo tanto, quería minimizar mi esfuerzo al programar. Ese fue mi principal objetivo en el diseño de Ruby. Quería divertirme programando. Luego de liberar Ruby, cuando muchas personas en todo el mundo lo conocieron, dijeron que se sentían igual que yo."^[2]

Enlaces útiles

Enlaces útiles

• El sitio oficial de Ruby: http://www.ruby-lang.org/es/
• Intérprete Ruby online (accesible con un navegador, con un excelente tutorial): http://tryruby.hobix.com/
• Ruby on Rails (la "killer app" de Ruby):http://www.rubyonrails.org/

Referencias

• [0] http://www.oreilly.com/catalog/ruby/
• [1] http://www.linuxdevcenter.com/pub/a/
• [2] http://www.artima.com/intv/rubyP.html

Licencia

© Copyright 2007 Javier Smaldone


Este artículo se distribuye bajo una licencia "Atribución-NoComercial-CompartirDerivadasIgual 2.5 Argentina" de Creative Commons.

XVII Encuentro Genexus Porque, como, donde y cuando

Por Martín Rampo
Blog
Miembro de RosarioGX

El encuentro de Montevideo es el evento más esperado por toda la comunidad Genexus, pero ¿Por qué?
Bueno en su blog Armin Bachmann nos detalla la lista de razones por las que el amigo Gabriel Medina (gab) considera a este encuentro uno de los más fantásticos círculos virtuosos, además Gustavo Carriquiry en su blog nos presenta un video donde, él, Nicolas Jodal y Breogan Gonda, nos invitan a participar del Evento comentando justamente las razones por las que es importante participar.
Viendo que, como en la canción, sobran los motivos seguramente te estas preguntando ¿Cómo hago?
Si pasan por el blog de RosarioGX van a encontrar un exhaustivo detalle de cómo llegar, donde alojarse, y hasta que documentación llevar.
Bueno solo queda por contestar ¿Cómo y donde? Las respuestas en el sitio del encuentro
Además en este sitio encontraran la lista preliminar de charlas, como para ir mirando en que vas a invertir tu tiempo esos tres días, junto con mucha información relevante.
Para estar informado de las últimas novedades del encuentro les sugiero que visiten el blog del encuentro.
Nos vemos el 24 en Montevideo.

Contacto

Para comunicarte con este newsletter utiliza los siguientes canales:

NewsGUG
newsgug@gmail.com

RosarioGX
contacto@rosariogx.com.ar
Coordinadores: Germán Rampo, Carlos Lucatti, Diego Serván, Martín Rampo
Recursos:
Foro - http://groups.google.com/group/rosariogx
Blog - http://rosariogx.blogspot.com/

GxRíoCuarto
gxsoft@gmail.com
Coordinador: Gabriel Medina [gab]
Recursos:
Foro – GxRioCuarto@googlegroups.com
Blog - http://gxriocuarto.blogspot.com/

BairesGUG
Coordinador: Paulo Sapuppo
Recursos:Site - http://www.bairesgug.com.ar/
Foro - http://www.bairesgug.com.ar/foro
Mail - bairesgug@gmail.com

Información sobre los GUGs
http://www.gxtechnical.com/gug

Ya somos más de 200!

Por Germán Rampo
Blog
Miembro de RosarioGX

La lista de mails de GUG RosarioGX ya suma más de 200 integrantes y el número sigue creciendo. Por lo que se ha podido observar, en la misma participan en su inmensa mayoría desarrolladores de la Ciudad de Rosario pero también de otras localidades de Santa Fe, otras provincias e incluso de otros paises. Además y en menor medida también están presentes cuentas de email de miembros de Artech, empresarios, líderes de proyectos, analistas y gerentes de sistemas. Por otra parte también conforman la lista los referentes de otros GUGs que fueron invitados a integrarse para mantenerlos informados de nuestras actividades y que puedan aportar sus opiniones o potencialmente repetir las experiencias en sus propios grupos de usuarios.
La lista no tiene alto tráfico diario. La misma es usada para algunas consultas técnicas, si bien no hay restricciones en cuanto a este uso y está totalmente permitido hacerlo, este no es una de sus fortalezas ya que los foros técnicos de Artech son mucho más apropiados para esto. El punto fuerte de este canal de comunicación es principalmente difundir, coordinar y permitir sumarse virtualmente y con un click a las actividades que se van desarrollando en el plano real. Es el medio por el cual se comunica, lo que se va a hacer, lo que se hizo o simplemente se confirma con un "cuenten con mi presencia!" la asistencia a una actividad del GUG. La lista de mails constituye un lugar de encuentro, un canal abierto y una posibilidad de llegada importante hacia toda la comunidad, es por eso que tratamos de hacer un uso responsable de la misma y afortunadamente está dando muy buen resultado!
En fin... ya somos más de 200 y la familia se sigue agrandando!!


Si usa el webmail GMail puede crear una etiqueta "GugRosarioGX" y crear el filtro:

Concordancias: subject:[rosariogx-l] Aplicar: Aplicar etiqueta "GugRosarioGX" De esta manera al archivar los mensajes estos quedarán clasificados dentro de la etiqueta.

Para formar parte de la lista puede ingresar en http://groups.google.com/group/rosariogx

Desarrollo web versus desarrollo win

Por Carlos Lucatti
Blog
Miembro de RosarioGX


Todos sabemos que en los últimos tiempos se ha intensificado el desarrollo de aplicaciones basadas en web. Este cambio de paradigma, por cierto inevitable, nos abre nuevas posibilidades antes impensables. Pero desde hace tiempo hay algunas cosas que me preocupan en este proceso de cambio que estamos viviendo.
Como ventajas de una aplicación web veo lo siguiente:
Posibilidad de que la aplicación sea usada sin cambios desde cualquier punto geográficamente remoto que trascienda los límites físicos de la empresa. Los empleados pueden trabajar en su casa, los supervisores pueden revisar datos y autorizar acciones aún cuando se encuentren en viaje, los gerentes pueden consultar estados desde cualquier parte del mundo aún en vacaciones (bueno… ellos son así…), los clientes pueden consultar sus cuentas corrientes o hacer pedidos on-line, los proveedores pueden tomar directamente las ordenes de compra desde la web y saber si sus pagos ya están disponibles, etc. etc. Estas son algunas de las ventajas desde el punto de vista de aplicación.
Desde el punto de vista tecnológico veo como ventajas lo siguiente:
El sistema funciona en cualquier computadora personal con capacidad para ejecutar un navegador. No se requieren configuraciones de hardware potente (disco, procesador y memoria). No se requieren instalaciones locales (en los “clients”) de componentes del sistema. Se reduce la necesidad de licenciamiento de componentes y sobre todo de componentes “propietarios”. Se reducen los esfuerzos de distribución de las aplicaciones (instalación y puesta en marcha) y por consiguiente los costos.
Otra ventaja pero desde el punto de vista social es que gran cantidad de gente (fuera de las empresas y sus trabajos) usa internet, con lo cual “saber navegar” comienza a volverse parte de nuestra cultura. Así, para las personas que se inician en un nuevo trabajo en una empresa y especialmente aquellas para quienes se trata de su primer trabajo será mucho más fácil adecuarse al uso de los sistemas de aplicación, ya que las interfases se “parecerán” mucho a los sitios que suele navegar.
Ahora pasemos a los aspectos que no se ven claramente.
Respecto a que la aplicación puede usarse desde fuera de los límites físicos de la empresa, esto es cierto si la empresa posee un vínculo a InterNet publicando su aplicación. No todas las empresas están en condiciones de hacerlo ya que para una empresa chica o mediana el costo del vínculo permanente puede ser caro. Además de esto, debe implementar una serie de medidas de seguridad reforzando todo lo que tenga que ver con posibles intrusiones vía su enlace al mundo (hackers) instalando y configurando routers y firewalls. Algo que antes no necesitaba y para lo cual ahora seguramente deberá contratar especialistas que además le cobrarán un abono de mantenimiento. Al analizar esto, las empresas ven que es “lindo” pero que no es tan necesario que se pueda usar la aplicación "desde afuera".
En el caso de una intranet donde hay ubicaciones geográficamente remotas (WAN) que están conectadas por medio de un vínculo privado, sí, se justifica ampliamente una aplicación web, de todos modos el vínculo debe existir igual.
En el caso de una intranet local, el beneficio solo se aplica a la escasa necesidad de recursos de máquina y esfuerzos de instalación y distribución de aplicaciones. Aún así, cuando las empresas compran una computadora personal compran las configuraciones de hardware estándar, o sea, máquinas tan potentes como para correr las aplicaciones Windows usuales hasta el momento. Los usuarios siguen necesitando correr aplicaciones de oficina que requieren más recursos. Difícilmente una empresa le pida a su proveedor de hardware renovar un parque de máquinas con configuraciones mínimas para correr solo un navegador. Mi conclusión es que no ahorrarán en hardware.
Hoy, la comunidad informática dice: “Las aplicaciones nuevas deben ser todas basadas en web”... ¿Todas?, Si, todas.
Este planteo es el que me preocupa y a continuación comentaré las razones.
Comencé a trabajar en informática en 1981. Desarrollaba sobre arquitecturas propietarias con pantalla de caracteres. Con el advenimiento de los desarrollos basados en Windows los usuarios comenzaron a demandar cada día nuevas comodidades en pantalla. Evidentemente el manejo de eventos por medio de botones, ventanas, idas y vueltas “controladas” le daban al usuario una posibilidad de hacer muchas más cosas y más rápido en su sistema. Cuando recordaban la rigidez de las validaciones a pantalla completa se referían a ella como la era por suerte pasada.
Hoy veo que los estamos obligando a volver. Las interfases web son mucho más rígidas que las interfases Windows y con menos posibilidades de interactividad. ¿AJAX?, si, pero la página web sigue siendo un formulario plano y rígido. Por eso, mis jóvenes colegas, les cuento que esta historia ya la viví hace varios años, y estamos recomenzando el ciclo. Ahora debemos decirle a los usuarios que las interfases no serán tan cómodas como antes. Pero seguramente me dirán que ... bueno, con un poco de esfuerzo adicional las interfases se pueden diseñar bastante más elaboradas y amigables. ¿Un poco de esfuerzo?, pregunto. Me parece que con mucho más esfuerzo.
Pasando a otra cuestión. La aplicación se ejecuta en un navegador que le da al usuario muchas posibilidades “justamente” para navegar. Ya que se nos ha recalentado tantas veces el cerebro para controlar la transacción del usuario, que no se corte, que pasa si se corta, que no salga de allí hasta que defina tal resultado, etc. etc. , ¿cómo manejaremos la idea de que en medio de una transacción compleja como ser “Definir el plan de producción semanal” , el usuario pulse graciosamente un link que lo lleve a la página de espectáculos antes de confirmar? ¿y vieron además con qué facilidad se puede cerrar el navegador?
Seguramente los más avanzados en esta tecnología me dirán que hay formas o técnicas o productos adicionales que eviten estos problemas, pero coincidirán conmigo en que no son cuestiones de conocimiento común.
Hablando de navegadores, creo que fueron inventados para “ver” páginas de internet y saltar entre ellas, pero no fueron concebidos para contener aplicaciones así que todas las nuevas facilidades que se le están incorporando son forzadas para darles más habilidades y más seguridades porque les queremos poner en las espaldas algo para lo que no han sido concebidos. Creo que es necesaria una nueva generación de navegadores.
Me ha tocado desarrollar sistemas en los cuales el usuario debe trabajar a un ritmo muy veloz y por ello, a lo largo de la evolución de las aplicaciones me han solicitado sutilezas importantes en la interfaz. Cosas que son fáciles y prácticas de hacer en Windows. El usuario debe trabajar muy rápido con múltiples ventanas de selección, con manejo de diferentes tipos de productos para los cuales existen diferentes interfases de tratamiento, leyendo códigos de barra, imprimiendo permisos de despacho, emitiendo remitos, etc.… y todo muy rápido con toques de teclado. ¿Cómo haremos esto con una interfaz web más rígida y que además hace un uso mucho más intenso del mouse?
El desarrollo web es más complejo que el desarrollo Windows. Insume más tiempo. Si queremos que nuestras aplicaciones luzcan decentemente necesitamos asesoramiento de diseño o “look” ya que los editores de forms web son muy limitados (por el html en sí y por las tablas donde debemos ubicar los objetos). Si queremos darle ciertas funcionalidades que antes eran propias de Windows debemos recurrir a programación en JScript por ejemplo y comenzar a mezclar cosas de diferentes mundos que era una de las críticas que más nos hacían acerca del paradigma client/server.
¿Ya hemos preparado a nuestros jefes o a nuestros clientes explicándoles que el desarrollo web es más caro en tiempo y dinero? ¿Cómo vienen reaccionando a esto?
Sin dudas hemos comenzado una nueva era en el desarrollo. Pero no debemos dejar de reconocer que hay varios puntos flojos por el momento y que son difíciles de resolver.
La tecnología seguirá avanzando como lo hizo siempre y espero que termine resolviendo estos problemas y conteste naturalmente estas dudas.
Bueno,…. ahora los dejo, tengo que seguir estudiando desarrollo web.

Conociendo a nuestros amigos de la comunidad - Armin Bachmann

Armin, cuéntanos acerca de tu persona, edad, carácter, hobbies, donde estudiaste.
Nací cuando arrancaba el tercer cuarto del siglo pasado y me crié en el campo, en Colonia Gartental, departamento de Rio Negro. Lo de ordeñar no me gustó mucho pero sí “tractorear” (hacer tareas de campo en tractor como arar, etc.), pescar y cazar, hobbies que casi dejé de practicar. De ir a la escuela alemana en el campo, liceo en San Javier y posteriormente en Paysandú pasé a gustar de las matemáticas y terminé sacando el título de Ing. en Computación en la Facultad de Ingeniería de la Universidad de la República (universidad publica y gratuita de Uruguay). Me gusta leer y aunque con 2 hijos el tiempo para ello es menor, si lo hago es sobre temas de liderazgo o dirección de empresas en general.

¿Cuánto tiempo hace que trabajas en Artech?
Comencé en el 98, luego de terminar tercer año en la facultad.

¿Cómo fue tu carrera desde que comenzaste en esta empresa?
Lo que debían ser dos años, terminaron siendo 4….(casorio de por medio también).

¿Cuál es tu área de responsabilidad en Artech?
Soporte de los generadores VFP, .NET y XBase (sí, este año todavía recibimos una consulta sobre foxpro 2.6 DOS ….hay sistemas así funcionando aún); ayudo en coordinación del soporte y desarrollo para liberar nuevas versiones como la Rocha (que no es solo una nueva versión…); y cada vez más y especialmente en lo referente a comunidades de usuarios (lo que terminó en collaborative projects, grupos de usuarios, challenge, etc. )

¿Cómo es uno de tus días de trabajo en Artech?
Pah! Complicado, varía mucho. Muchos mails ( más de 800 mails pasaron por mi inbox la semana pasada, sin contar los de los foros y el spam.), tareas de bomberos, algunas reuniones, lectura de mis blogs preferidos y de lo que pasa en algun foro.

¿Viajas mucho? ¿A dónde y qué haces en cada lugar?
No, ahora viajo poco. Por ahí en el 2001 y 2002 viajé más. En el último viaje estuve en Rosario, Argentina: linda ciudad, gente super amable, conocí algunos amigos allí, no se si conocen. En general los viajes fueron de “apoyo técnico a ventas” (Demos y Early Adopter Program de .NET en Centroamérica), cursos (un mes en Japón), presentaciones a eventos (San Pablo este año).

¿Qué espera Artech de las comunidades de usuarios y qué deben esperar las comunidades de Artech?
Creo que el lema del XVII Encuentro Internacional GeneXus lo establece claramente: Creá más!. En este sentido entre todos tenemos que apelar a nuestra creatividad para encontrar nuevos mecanismos para unirnos y avanzar en la construcción de aplicaciones de misión crítica, y ser referentes en el mundo!

¿Artech planea actividades dirigidas a los GUGs ?
Si, los seguiremos apoyando en todo lo que podamos. Hasta ahora hemos ayudado a organizarse y apoyado con charlas sobre temas de interés. A medida que los grupos van avanzando y quemando etapas, van teniendo otras necesidades. Como novedad, en particular estamos invitando a algunos miembros de los gugs a participar de laboratorios de Rocha en el marco del Encuentro GeneXus, para que así puedan después transmitir ese conocimiento al resto.

Informe de ingresos y egresos del II Encuentro de Usuarios GX de Rosario

Este es el informe de la utilización del dinero recaudado en concepto de acreditaciones en el II Encuentro de Usuarios de RosarioGX realizado el 17 de marzo de 2007.

INGRESOS
Ingresos por acreditaciones..................... $ 3.250.-
________
Total ingresos: $ 3.250.-

EGRESOS
Adelanto catering..................................... $ 700.-
Tarjetas de acredit y serv. recepción........... $ 190.-
Cena invitación a visitantes de Artech......... $ 250.-
Saldo Catering ...................................... $ 1.580.-
Artículos de librería .................................... $ 10.-
Cena invitación a visitantes de Artech.......... $ 180.-
________
Total egresos: $ 2.910.-

Saldo
Saldo a favor ........................................... $ 340.- (*)

(*) El saldo a favor se encuentra actualmente en poder de Carlos Lucatti, designado como tesorero del evento.
Dicha suma espera ser aplicada a nuevas actividades del grupo.

Un pequeño raconto de las actividades realizadas

19/12/2005 Primer encuentro de usuarios Gx de Rosario.
17/03/2007 Segundo encuentro de usuarios GX de Rosario.
27/04/2007 Reunión organizativa.
16/05/2007 Reunión organizativa. Se aprueba el documento de lineamientos de funcionamiento del grupo
24/05/2007 Reunión organizativa.
24/05/2007 Primer Reunión del GUG GX Río Cuarto.
15/06/2007 Reunión organizativa.
22/06/2007 ST 1. Envío automático de mails y SMS a celulares, por Carlos Lucatti. 11 asistentes.
27/06/2007 ST 2. Tipos de dato Web Session, por Germán Rampo. 11 asistentes.
11/07/2007 ST 3. Tipos de datos estructurados (SDT), por Daniel Ambort. 15 asistentes.
26/07/2007 ST 4. Migración de versiones, por Claudia Audisio y Diego Martínez. 16 asistentes.
24/08/2007 ST 5. Configuración de un modelo Java, por Elías Eblagón. 25 asistentes.
12/09/2007 Lanzamiento del Número #1 de NewsGUG