En concreto, me topé con unas 50 o 60 construcciones que tenían una estructura como esta:

if Variable <> '' then
begin
  VariableA := VariableA + X;
  VariableV := VariableB + Trim(Variable);
end;

Dado que de todas maneras había que re-escribir el código, pensé que era una buena oportunidad para aplicar el principio DRY y que a su vez esto permitiría tener una rutina más fácil de leer.

Por tanto, pensé en hacer una rutina genérica que recibiera las variables (el caso real implicaba cambios más profundos, pero para fines didácticos acá asumiremos que la estructura básica se mantendría):

La nueva rutina sería similar a esta:

procedure AsignaValor(Variable, X: string;
  var VariableA, VariableB: string);
begin
  if Variable <> '' then
  begin
    VariableA := VariableA + X;
    //se ha quitado la llamada a trim
    VariableV := VariableB + Variable;
  end;
end;

De esta manera, la vieja rutina luciría así:

  VariableA := '';
  VariableB := '';
  //Ahora Trim() se llama al llamar a la nueva rutina
  AsignaValor(Trim(Variable1), X1, VariableA, VariableB);
  AsignaValor(Trim(Variable2), X2, VariableA, VariableB);
  AsignaValor(Trim(Variable3), X3, VariableA, VariableB);
  AsignaValor(Trim(Variable4), X4, VariableA, VariableB);
  AsignaValor(Trim(Variable5), X5, VariableA, VariableB);

¡Muy bien, hasta ahora! pero (siempre hay un pero), hay dos cambios imporantes que debía considerar.

Primero, el funcionamiento se alteraría, ya que antes, si una variable contenía una cadena de uno o más espacios, sin caracteres, la asignación ocurría de todas maneras, pero al utilizar la nueva rutina no entraría al if. Luego de valorar la situación, resultó que eso no tenía importancia en este caso, por lo que vamos a valorar el segundo tema, y el motivo de esta entrada:

Cuando una cadena ya estaba vacía, lo cual ocurre con bastante frecuencia, en el flujo anterior del programa, la función Trim() no era llamada al hacer la comparación, ni posteriormente. En esta nueva versión, la función Trim() sería llamada para todas las variables. Tomando en cuenta que esto ocurriría unas 60 o 70 veces por transacción, y que el objetivo es mejorar el desempeño, me pregunté qué tanto cuesta llamar a Trim(”), para medir el impacto de este cambio y estar seguro que no afectaría.

Por ello, hice una pequeña prueba, donde llamo a Trim(”) diez millones de veces, lo cuál arrojó el siguiente “pantallazo”:

Como puede verse, la llamada a Trim(”), en mi máquina, toma en promedio tan solo 43.8 nano-segundos. Llamarlo 70 veces tendrá un costo de aproximadamente 3 micro-segundos (1 micro-segundo es la milésima parte de un mili-segundo). He elegido hacerlo diez millones de veces, pues esta es más o menos la cantidad de veces que esta rutina se ejecutará cada hora en horas pico, lo cual en total aumentará el tiempo de proceso en mas o menos medio segundo por hora.

Considerando que dentro de los cambios se han introducido mejoras importantes en el desempeño, que Trim() de todas maneras es llamado para las variables que no están vacías y que el hardware del servidor es más robusto que el de mi PC (o debiera serlo), el costo, en esta ocasión ha resultado aceptable.

–
Edición 25/nov/2011. El código publicado originalmente no era correcto, en realidad se compara una desigualdad y no una igualdad, si no, realmente no tendría sentido. Gracias a Juan por el comentario que me hizo darme cuenta de este error.

En esta ocasión, estimado lector, estoy invitándote a unirte a la propuesta para crear un sitio de preguntas y respuestas sobre desarrollo de software en español, en Area51 de StackExchange. Dejame explicarte.

Primero, un poco de información sobre la red StackExchange, Area51, el proceso y StackOverflow. Si ya lo conoces, puedes ir directamente a la información de la iniciativa

¿Qué es StackExchange?

StackExchange es una red de sitios de preguntas y respuestas sobre temas diversos. Tras cada uno de estos sitios hay una comunidad compuesta tanto por expertos en la materia, como por estudiantes y neófitos, que buscan ayudarse mutuamente compartiendo información y conocimientos. Los sitios de StackExchange utilizan básicamente la misma metodología (y más o menos el mismo software) de StackOverflow, que difiere un poco de los tradicionales sistemas de foros y que como ya he dicho antes, me parece una idea genial.

StackExchange permite la creación de nuevos sitios de preguntas y respuestas (sin costo), siempre que haya una comunidad que haya demostrado que va a usar el sitio (y generar un buen volumen de tráfico en él).

Encontrarás más información en la sección Acerca de StackExchange (en Inglés)

¿Qué es Area51?

Area51 es la zona donde se incuban nuevos sitios para la red StackExchange. Allí, cualquier usuario puede proponer la creación de un nuevo sitio o involucrarse en el proceso

Encontrarás más información en la sección de preguntas frecuentes de Area51 (en inglés)

¿Cuál es el proceso para crear un nuevo sitio?

Como ya he dicho antes, StackExchange creará un nuevo sitio solamente si se ha demostrado que hay una comunidad que soporta la idea y que será activa en el uso del sitio. Para ello han ideado un proceso que describo a grandes rasgos a continuación

Propuesta

Lo primero, es que el sitio sea propuesto. Esto puede hacerlo cualquier usuario con al menos 50 puntos de reputación.

Definición

Una vez la propuesta existe, el siguiente paso es definir el sitio. Para ello, a la propuesta debe sumarse un número de seguidores que participarán en el proceso de definición. Dado que es un sitio de preguntas y respuestas, los seguidores lo definen a través de proponer preguntas hipotéticas para el sitio. Estas preguntas podrán obtener votos a favor (si se consideran buenas preguntas), en contra (si se consideran malas preguntas) o ser cerradas (si son preguntas fuera de tópico y por tanto no tendrían cabida en el sitio). Se considera que el ámbito y alcance del sitio ha alcanzado la definición cuando hay un número suficiente de seguidores y entre estos han definido al menos 10 preguntas con 10 votos netos cada una.

Compromiso

La propuesta entra entonces a la fase de compromiso. Durante esta fase, se busca encontrar una masa crítica de usuarios dispuestos a comprometerse a participar en el sitio. El compromiso consiste en que, una vez se llegue a la fase beta, la persona publicará al menos diez preguntas o respuestas. Al comprometerse, el usuario indica si es un experto, un neófito o un estudiante. Se busca que la comunidad tenga una cierta mezcla de expertos y neófitos/estudiantes para que haya quién pregunte, y quién responda. No es pública la forma en la que el sitio determina el avance o la cantidad de usuarios requeridos para alcanzar la siguiente fase.

Beta

Al alcanzar esta etapa, es creado el sitio como tal y su meta-sitio (hablaremos del meta en otra entrada en el futuro). Se considera la etapa más crítica, ya que si el sitio no presenta un tráfico aceptable, si no hay preguntas suficientes o si muchas de estas se quedan sin respuesta, será cancelado. La fase beta tiene una duración de 30 días. La beta se lleva a cabo en un sub-dominio de StackExchange (p.ej. esStackOverflow.StackExchange.com)

Sitio creado y funcionando

Finalmente, al sitio le es asignado un dominio y es puesto en marcha. StackExchange provee los recursos tecnológicos y la comunidad administra el contenido del sitio

StackOverflow

StackOverflow es un sitio de preguntas y respuestas de la red StackExchange (de hecho, es el primero y existe antes que existiera dicha red). En este sitio, el tema es el desarrollo de software y ya he hablado de él en el pasado por lo que no me repetiré.

¡StackOverflow en Español!

La propuesta de un sitio de preguntas y respuestas sobre desarrollo de software en español busca, en pocas palabras, que exista un sitio con la misma temática y alcance de StackOverflow, ¡pero en español!.

El sitio dará, entonces, acogida a las preguntas de programación en cualquier lenguaje (c, c#, c++, lisp, delphi, etc.), sistema operativo y/o tecnología utilizada. StackOverflow es bastante cerrado en el ámbito, ya que no permite preguntas de otros temas (aún cuando sean relacionados con tecnología). Esto deja fuera temas como redes, servidores, charla general, etc.

La existencia de este sitio es, a mi criterio, necesaria por varias razones, entre las que puedo mencionar

• En StackOverflow las preguntas en Español no son bienvenidas y tienden a ser ignoradas debido a que la gran mayoría de usuarios no habla el idioma. De hecho, recuerdo haber visto algunas con votos negativos por el simple hecho de estar en Español.
• La falta de más preguntas/respuestas en Español incide directamente en la calidad y cantidad de resultados devueltos por los motores de búsqueda a las dudas de programación en español.
• Hay una gran cantidad de programadores de habla hispana que, siendo capaces de leer textos en Inglés, tienen grandes dificultades para expresar correctamente una pregunta en ese Idioma y por tanto tienen dificultades para participar directamente en StackOverflow.
• Es mucho más placentero escribir y leer en la lengua de Cervantes (al menos, para mi)

Esta propuesta ha alcanzado ya la fase de compromiso. Al momento de escribir estas líneas, muestra tan solo un 14% de avance con 33 usuarios comprometidos. Si la relación fuera lineal (me temo que no lo es), se requeriría de unos 236 usuarios dispuestos a comprometerse.

Tomando en cuenta que la fase de definición se completó con 69 seguidores, y que tomó casi un año reunirlos, el camino se ve cuesta arriba, sin embargo, quizás no lo sea tanto. Desde hace tiempo he pensado que parte del problema es la falta de disponibilidad de información en Español sobre el proceso, ya que creo que la comunidad de habla hispana gustará del sitio, lo utilizará y aprovechará al máximo. Eso me ha motivado a reseñar el proceso aquí en pocas palabras (pocas en comparación con la cantidad de información disponible en Inglés, me temo que si has llegado a este punto de la lectura, eres una persona difícil de aburrir. )

¡Se busca compromiso genuino!

Ya para terminar, te pido que, si luego de leer estas líneas te sientes motivado a participar del sitio, te unas a nosotros. Hazlo solo si tu interés es genuino y puedes cumplir con el compromiso, ya que si te comprometes y, al alcanzar la fase beta, no participas, el sitio será cerrado y, en mi opinión, la comunidad saldrá perjudicada al perder este valioso recurso.

Consideraciones finales

• No he sido el creador de la propuesta (la encontré cuando iba a hacer una propuesta similar), pero creo que estoy entre los 10 ó 20 primeros seguidores de la misma.
• El proceso de StackExchange es bastante democrático, pero no es perfecto. Una prueba de ello es que este sitio debe cumplir con todo el proceso para su creación, incluso la definición, aún cuando es prácticamente igual a StackOverflow
• Lo más probable es que, cuando el sitio entre en fase beta, aún cuando el contenido esté en Español, el sitio como tal seguirá en Inglés (menús, preguntas frecuentes, etc.), y por tanto conteniendo barreras para muchas personas de habla hispana. Será la comunidad la que deberá pedir y quizás ayudar a traducir la interfaz completa
• No hay un tiempo límite para superar las etapas, exceptuando la beta. Esto significa que quizás tengamos que esperar mucho tiempo (¿años?) para superar la fase de compromiso
• Eres libre de invitar a más personas a unirse, de hecho, te ánimo a correr la voz.
• StackExchange buscará hacer algo de dinero del sitio, por ejemplo, publicando publicidad u ofreciendo otros servicios. En lo personal eso no me molesta, dado que es su negocio, pero lo menciono porque quizás prefieras no participar al saberlo.
• Todo el contenido publicado en StackExchange tiene licencia de CreativeCommons (atribución). Al crear un usuario, aceptas que el contenido que tu creas se publique bajo dicha licencia. Esto, en lo personal, me parece positivo, pues permite que el contenido siga existiendo más allá de StackExchange
• Al comprometerte luego de seguir los vínculos que publico en esta entrada, el sistema registra que eres mi referid@, no ganaré dinero por eso, pero si la atribución de haberte llevado. Puedes hacer lo mismo con las personas que refieras utilizando el vínculo que encontrarás en el botón “share this” de la propuesta

La actividad en Delphi es, a mi gusto, aún baja, sin embargo presenta una clara tendencia al alza y eventualmente publico algunas respuestas, también en un esfuerzo por practicar y pulir mi habilidad para escribir en inglés (que aún da pena, pero va mejorando).

Escribo estoy hoy, principalmente porque StackOverflow me parece una idea genial y una comunidad interesante, con sus propias reglas de las que probablemente escriba algo a manera de introducción en el futuro. Si podes leer/escribir en Inglés, seguro vale la pena darte una vuelta por allí, y si podes ayudar con mi (hasta hoy) única pregunta, aún pendiente de una respuesta definitiva, tendré algo más que agradecer al hecho de que leas esta entrada.

Nuevamente, si sabes como hacer una ventana de notificación tipo Windows 7 en Delphi, toda la ayuda es bienvenida.

Si no estás familiarizado con la terminología del control de versiones, particularmente SubVersion, lo que esto significa es que el código fuente, que alguna vez se ramificó del desarrollo principal (branch), para soportar el cambio a Unicode en los tiempos de Delphi 2009 (llamado Tiburon), finalmente ha sido llevado de regreso (merge) a la raíz del desarrollo (trunk).

No es que hasta ahora se terminara de portar el código… en realidad es que luego de realizar las adaptaciones necesarias, quién sabe por qué, el equipo de INDY siguió desarrollando en el branch y el código nunca se integró de vuelta. Ahora lo hacen, en parte, porque estamos próximos a ver el inicio del desarrollo de INDY 11 (probablemente otro release que romperá la compatibilidad con el código existente).

En conclusión

• Si obtenés el código de INDY directamente de SVN, deberás configurar el cliente para que obtenga el código de trunk y no de branches/tiburon, como lo haces ahora
• Si obtenés el código de INDY descargando el ZIP del mirror, ahora debes descargar el archivo Indy10_xxxx.zip y no el Indy10Tiburon_xxx.zip
• Si aún compilas con versiones viejas de SVN, mi consejo es que lo actualicés y te hagás a la idea que es buena idea mantenerlo actualizado

Como es costumbre en INDY, la documentación oficial (incluyendo el sitio de descarga) aún no refleja esta información, y será actualizada pronto.

Vía anuncios de Remy Lebeau en foros Embarcadero y foros Atozed Software

La idea de cambiar el tema es aprovechar mejor el espacio con una plantilla que agrega mas contenido y, en mi opinión aprovecha mejor el espacio disponible. Francamente no le he dedicado mucho tiempo a buscar una plantilla, así que estoy abierto a sugerencias.

A lo que le he dedicado mas tiempo es a configurar lo que se mostrará en la barra lateral, pero si no te gusta o si crees que debo hacer algún cambio, estimado lector, por favor deja un comentario que prometo considerar seriamente, pues la idea de este cambio es que encontres más y mejor información de lo ya contenido en la bitácora y de lo que ocurre en el mundillo de Delphi.

Si no lo sabías, debo confesar que lo gráfico no es lo mio… por lo mismo no tengo todavía una imagen para poner en el encabezado de la página y he decidido, mientras logro la inspiración colaboración de un alma caritativa para diseñar una, el blog estará al aire sin el tal gráfico, que pienso, si existiera, ayudaría a hacer el sitio mas estético y agradable.

De antemano, gracias por el tiempo que tomes para hacer sugerencias.

Hace unos minutos he sido informado por Embarcadero que RAD Studio XE está disponible para descarga. Estoy en eso ahora (como puede verse en la imagen), asistiré mañana al webinar de Mike Rozlog, con lo que espero pronto poder comentar acerca de esta nueva versión, aunque adelanto que la presión actual de proyecto la sacaré con el 2010… pero en unas semanas prometo estar totalmente a la carga con XE.

En lo que a mi respecta, el roadmap dice más o menos lo mismo que decía el anterior, con algunas adiciones. Como desarrollador comprendo que la meta es alta, es decir, no cualquiera compila con la facilidad que se busca para varias plataformas y el cambio de 32 a 64 tampoco es trivial, los recursos son limitados, aunque no inexistentes, tomando en cuenta los precios y popularidad del producto y el tiempo quizás no de para más. Como cliente, espero que la compañía y el producto (Delphi/RAD Studio) se mantenga agresivamente a la vanguardia en el desarrollo nativo y me de más que promesas y razones para seguir soportándolo, recomendándolo y usandolo, cosa en la que confío por ahora.

Espero que la comunicación siga mejorando; el roadmap definitivamente es un buen paso para calmar algunos ánimos. Me gustaría ver plazos mas concretos… mi enfoque sigue estando en el código nativo y me encanta la idea de un compilador para 64, y mucho mas la de un compilador multi-plataforma. Espero pronto ver algunos servidores DataSnap corriendo sobre linux, contra una de tantas bases de datos soportadas por las capas de conexión existentes.

Me encantaría ver un preview de este compilador, aún en línea de comandos como el ofrecido para 64 bits. ¿será un año mas de espera y veremos en el futuro Delphi XE2 estas dos gemas?

Creo que nadie puede afirmarlo o negarlo… creo también que muchos le darán nuevamente la oportunidad al producto de intentarlo y creo que Embarcadero debe poner toda la carne al asador para lograrlo en el siguiente release. Por ahora, espero que llegue a mis manos el XE y que el presupuesto nos de para otro año de SA…. es algo que se verá en los próximos meses.

Me parece increíble que una empresa pague a un desarrollador entre us$60 a us$100 mil (en Latinoamérica) us$8 a us$25 mil, y aún así mantenerle en terribles condiciones de trabajo y con hardware de segunda mano. Esto no tiene sentido para el negocio, y sin embargo lo veo todo el tiempo. Es sorprendente como muchas empresas siguen sin dar a sus programadores las cosas esenciales que necesitan para triunfar.

Propongo que se adopte una Declaración de Derechos del Programador, que proteja los derechos de los desarrolladores, previniendo que las empresas les priven de los elementos fundamentales necesarios para alcanzar el éxito.

1. Todo programador tiene derecho a dos monitores

   Con la caída de precios de los LCDs y la ubicuidad de las tarjetas de vídeo de doble salida, habría que estar loco para limitar a los desarrolladores una sola pantalla. Los beneficios a la productividad al duplicar el escritorio están bien documentados en estos días. Si desea maximizar la productividad del desarrollo, asegúrese de que cada desarrollador tenga dos monitores.

2. Todo programador tiene derecho a un PC rápido

   A los desarrolladores se les requiere ejecutar una gran cantidad de software para realizar su trabajo: entornos de desarrollo, motores de base de datos, servidores web, máquinas virtuales, y más. Ejecutar todo este software requiere una PC rápida con mucha memoria. Cuanto más rápido sea el PC de un desarrollador, más rápido podrá ir entre ciclos de depuración y compilación. Sería tonto pagar los precios de extorsionistas en el extremo más alto de la pila de rendimiento actual – pero asegúrese que está comprando cerca del extremo superior. Equipe a sus desarrolladores con PC’s rápidos que tienen montones de memoria. El tiempo dedicado a mirar una barra de progreso es tiempo perdido.

3. Todo programador tiene derecho a usar el ratón y teclado de su elección

   En la universidad tuve un negocio de pintura. Cada pintor que contraté tenía que comprar sus propias brochas. Esta fue una de las primeras cosas que aprendí. Lanzar una brocha estándar a los nuevos pintores no funcionó. Las brochas “de la compañía” fueron rápidamente descuidadas y degeneradas a un estado de deterioro. Pero los pintores que compraron sus propias brochas tuvieron cuidado de ellas. Los pintores que compraron sus propias brochas aprendieron a apreciar la diferencia entre sus brochas profesionales de 20 dólares y las desechables y baratas de un dolar. Tener su propia brocha engendró un duradero sentimiento de responsabilidad y “hermandad”. Los programadores deben tener la misma relación con su ratón y teclado – que son sus herramientas esenciales de trabajo, que utilizamos diariamente para la práctica de nuestro oficio, y deben tratarse como tal.

4. Todo programador tiene derecho a una silla cómoda

   ¡Enfrentemoslo! Hacemos nuestros salarios en gran medida por estar sobre nuestros traseros 8 horas al día. ¿Por qué no pasar esas 8 horas en una silla cómoda y bien diseñada? Dé a los desarrolladores sillas que hagan sentarse por 8 horas algo no sólo tolerable sino agradable. Claro, usted contrata a los desarrolladores principalmente por sus grandes cerebros, pero no olvide sus otros activos.

5. Todo programador tiene derecho a una conexión rápida a Internet

   Los buenos programadores nunca escriben lo que pueden robar. Y la Internet es el mejor conducto inventado jamas para el material robado. Soy todo por los libros, pero es difícil imaginar la realización de cualquier trabajo sin las rápidas y responsivas búsquedas de Internet al alcance de mis dedos.

6. Todo programador tiene derecho a trabajar en condiciones de tranquilidad

   La programación requiere alta concentración mental. Los programadores no pueden trabajar eficazmente en un entorno controlado por interrupciones. Asegúrese de que el entorno de trabajo protege el “estado de fluidez” de sus programadores, de lo contrario perderán la mayor parte de su tiempo rebotando entre distracciones.

Los pocos derechos básicos que estamos pidiendo son fáciles. No son exigencias extravagantes. Son fundamentales para la calidad de la vida laboral de un desarrollador de software. Si la empresa para la que trabaja no está haciéndolo bien, hacerlo correctamente no le será caro ni difícil. ¡Demanda tus derechos como programador! Y recuerda: puedes cambiar tu empresa, o puedes cambiar de empresa.

Hoy se supo que la nueva versión de RAD Studio se llamará RAD Studio XE, y no RAD Studio 2011, como algunos esperabamos.

El 10 de agosto estaba destinado a ser el día en que varias personalidades de esta compañía han publicarían artículos en sus blogs, comentando sobre las nuevas características de esta versión.

Hasta ahora, no se ha comentado nada acerca de los esperados proyecto X y commodore 64, por lo que es de esperar que no se incluya ni soporte multi-plataforma ni un compilador de 64 bits por ahora.

Luego de quejas sobre la imposibilidad de ver el video del Sneak Preview #1 detrás de un firewall (el cuál es mi caso en estos días), este ha sido publicado en youtube bajo el título RAD Studio XE 2010 Preview|Productivity enhacements, donde David I. y Mike Rozlog nos cuentan de primera mano lo que veremos en unas semanas en nuestros escritorios (si tenemos la suerte de tener SA)

Lo más relevante que se ha informado ahora sobre las nuevas características es:

• Integración con Sub-versión: Es el único controlador de versiones soportado por ahora, Mike Rozlog afirma que será muy sencillo integrar otros al IDE
• Beyond Compare: Producto de Scotter Software integrado al IDE, utilitario para comparar (versiones de) archivos y entender rápidamente que ha cambiado
• Actualizaciones al formateador de código
• Muchas pequeñas características de productividad: Se cita como ejemplo que podrá compilarse y ejecutarse un proyecto en el menú contextual del administrador de proyectos, mejor formateo del IDE Insigiht y más…
• RadPHP -anteriormente Delphi for PHP- ahora incluido en RAD Studio
• Diagramas de secuencia: Generados automáticamente a partir del código Delphi

Encontrarás más información en:

• Anders Ohlson: RAD Studio XE Preview
• Tim Del Chiaro: Sneak Preview: Delphi 2011 is Delphi XE
• Michael Rozlog: Finally able to talk about things…
• Andreano Lanusse: RAD Studio XE ahora con Delphi XE, C++Builder XE, Delphi Prism XE y RadPHP XE

Implementing a partial serial number verification system in delphi

Contiene ideas prácticas y sencillas para desarrollar un sistema de protección único para nuestros sistemas “públicos”.

Aclaro: No estoy en contra del uso de componentes o soluciones de terceros… solo creo que el artículo no tiene desperdicio y quise compartirlo.