Una de "herramientas"

Hace varios años yo era responsable por el funcionamiento de una pequeña red en una pequeña línea aérea nacional. En la oficina principal teníamos un servidor principal (Netware 3.12 para 50 usuarios) que servía para compartir archivos e impresoras localmente y para alojar un servidor Btrieve que manejaba los datos de la aplicacion de reservaciones y gestión operacional. Luego teníamos cinco centros de operaciones (en tres aeropuertos y dos oficinas comerciales en la ciudad correspondiente) con servidores locales, tambien NetWare 3.12, de 5 a 10 usuarios, para compartir archivos e impresoras localmente y para almacenar tablas locales de Btrieve (de manera que un terminal en Maracaibo no tuviera que enviar solicitudes al servidor de Caracas cada vez que quisiera acceder al precio de un boleto, por ejemplo). Cada centro de operaciones remoto se identificaba en el servidor central como un usuario “genérico”, a fin de poder tener acceso a los servicios de Btrieve del servidor principal.

Cada usuario trabaja en un departamento. Y cada departamento se representa mediante un grupo de usuarios. Cada usuario tenía su carpeta de datos personal, a la que tenían acceso irrestricto, y para cada departamento había una carpeta compartida, a la cual tenían acceso irrestricto todos los usuarios del grupo correspondiente. Todos los usuarios de una localidad tenían permiso para acceder a todas las impresoras de esa localidad. Los servidores locales cumplían tambien la función de routers, y todas las comunicaciones se basaban en IPX, el protocolo nativo de Netware.

Al menos una vez al mes, tenía que atender a un imbécil con pretensiones de “proveedor de tecnología” que intentaba demostrarme lo difícil que resultaba administrar una red como aquella, y cómo podía beneficiarme del producto que me ofrecía. La “administración” de la red se reducía a agregar nuevos usuarios, alguna que otra nueva impresora, y a hacer respaldos diarios en cinta magnetica (de lo cual se ocupaba automáticamente un NLM en el servidor).

Hace ya ocho años que abandoné aquel trabajo, pero sigo teniendo contactos esporádicos con la empresa. Han cambiado dos veces su plataforma, han gastado montañas de dinero en nueva infraestructura -incluyendo decenas de herramientas administrativas- y la unica diferencia es que los usuarios de localidades remotas no tienen acceso a ninguna carpeta del servidor central.

De alguna manera siento que la capacidad de hacer las cosas está siendo suplantada a muchos niveles por la capacidad de elegir la “herramienta correcta”. Cada vez más, la capacidad de resolver un problema -del tipo de desenchufa este cable de aquí y pégalo allá- se valora menos ante la capacidad de “tomar la decisión correcta”. Y creo que esta situación, que es ni mas ni menos que una monstruosa inversión de los valores, tiene que ver con el auge de la “Gerencia” como una profesión autónoma.

Cada vez más, decisiones de importancia vital para el desarrollo informático de las empresas son tomadas no por la gente de sistemas (ya sean desarrolladores o técnicos de la información) sino por “gerentes”, que saben mucho de planificación, de matrices de decisión, de instrumentos de control, normas y procedimientos, que con frecuencia saben algunos terminos de la jerga del medio (“tenemos que reemplazar tu esquema de archivos planos por una verdadera arquitectura orientada a los servicios”), pero que no tienen idea de cómo funciona nada, que son incapaces de escribir una linea de código y que al menos una vez a la semana necesitan asistencia para encontrar un archivo vital que accidentalmente grabaron donde no era.

El auge de esa generación de especialistas en nada es el caldo de cultivo para una hiperabundancia de herramientas inútiles y cada vez más caras.

No está de más decir que la existencia de esos imbéciles (cuyos sueldos están entre los más altos de la empresa que tiene la desgracia de alojarlos) tiene mucho que ver con las hambrunas en Africa, con el recalentamiento global y con los miserables niveles de vida de casi todo el tercer mundo.

Bueno, puede que ellos no sean los responsables directos; todos sabemos que son los políticos. Pero intuyo que esa gente de la que hablo son algo así como la clase política del mundo privado, de manera que vienen a ser más o menos lo mismo. 

A estas alturas no me defino para nada como marxista, aunque sigo reconociendo que Marx hizo un gran aporte a mi manera de ver el mundo (y creo que a la manera en que nuestra civilización se ve a sí misma); pero no puedo de dejar de pensar en su concepto de “alienación”, de subordinación de cualquier capacidad real de hacer las cosas a un poder cada vez más abstracto, cada vez que pienso en toda esta situación. Es a través de estos cretinos ignorantes y privilegiados como el sistema se reproduce y garantiza su supervivencia.

Pero no era de filosofía política que iba este artículo (comenzado y olvidado varias veces desde hace cuatro meses) sino acerca de algunos programas que he recibido de regalo (o que he descargado de sitios donde se ofrecen de gratis) recientemente.

PrimalScript

Uno de los programas que más útiles he encontrado es PrimalScript, un editor (y parece ser que mucho más que un editor, a quien le interese puede verlo aquí: http://www.primalscript.com) con un par de cosas muy convenientes: un explorador de objetos COM -que puede verse en el lado izquierdo de la imagen- y un explorador de bases de datos, visible al lado derecho. En mis aplicaciones hago uso muy frecuente de VBScript como un mecanismo para agregar funcionalidad especifica de cada usuario, sin necesidad de tocar el código fuente de la aplicación “base”. En esos scripts hago uso de componentes COM, y con frecuencia tengo que escribir consultas SQL para acceder a la base de datos de la aplicacion anfitriona.

Lo más bonito de PrimalScript es que tiene Intelisense (o como quiera que lamen ellos a la facultad de proponerte una lista con los elementos disponibles en el contexto de lo que estas escribiendo). Por ejemplo, escribes CreateObject(“ y PrimalScript te presenta una lista con los ProgIds de todos los objetos COM registrados en tu equipo. Pero lo mejor es que una vez que nstanciaste el objeto, el programa recuerda con qué componente está asociado. Si luego escribes pPrinterFiscal. aparecerá un listado con todos los miembros de la clase CPrinterFiscal. Cada vez que tengo que escribir un script más o menos largo o complejo (y a veces me tocan “scripts” de varios cientos de líneas, con tres o cuatro clases locales y un par de decenas de procedimientos privados) le agradezco tremendamente este detalle a la gente de Sapien Technologies.

 Apex SQL Doc:

Creo que no hay un desarrollador profesional que no haya intentado en algun momento de su vida escribir sus propias herramientas de documentación. Una de las primeras cosas que hice con VB5 fue escribirme un progama que te permitía seleccionar un archivo de Access y te listaba cada tabla con sus columnas, las propiedades de cada una de ellas y sus dependencias. Luego lo fui modificando para que me escribiera las declaraciones de variables de las clases a partir de las columnas de una tabla, o para que me generara las instrucciones CREATE de SQL, o el código genérico para insertar o modificar nuevos registros. A veces lo uso todavía. Pero el SQL Doc de Apex es otra cosa. Genera la documentación en un archivo .chm (HTML compilado), y es de lo más completo y adaptable que uno puede imaginar. La interfaz es intuitiva (y de alguna manera “simple”, aunque la cantidad de opciones puede ser abrumadora cuando quieres generar una documentación rápida), y la documentación generada es fácil de navegar y tan completa como puedas necesitar. SQL Doc es parte de un conjunto de herramientas específicas para SQL Server publicadas por ApexSQL (www.apexsql.com), que incluye otra herramienta que me ha servido: ApexSQL Diff, un programa para examinar las diferencias en las definiciones de los objetos (y en el contenido de las tablas) de dos BBDD de SQL Server, y luego sincronizarlas de manera automática. Producen otra cantidad de cosas, pero en realidad o no las he necesitado, o no he entendido como funcionan (prefiero pasar el tiempo haciendo cosas que aprendiendo a usar herramientas que pueden ser muy útiles pero sin las cuales he sobrevivido hasta hoy). Si se necesitan herramientas para documentar o sincronizar BBDD de SQL Server, y se puede pagar por ellas (399USD cada una, o 999USD por una suite de todos los productos de ApexSQL), SQL Diff y SQL Doc son excelentes opciones.

NOD 32:

Despues de usar los antivirus de Symantec y de McAffee, llegué a la conclusión de que era mejor contraer un virus de vez en cuando que un antivirus todo el tiempo.  Panda es más o menos de la misma escuela.

 Luego “descubrí” el AVG Free Edition, y lo estuve usando con buenos resultados por un par de años, cuando ESET, la compañía que fabrica NOD32, decidió regalarle una licencia a cualquier MVP que la pidiera. Lo que me convenció de usar NOD32 fue una comparación que ví en alguno de esos sitios serios que comparan el rendimiento y las ratas de detección de virus de los diferentes productos, en la que NOD 32 aparecía consistentemente entre los primeros puestos en todas las categorías, con la mejor evaluación global de todos. 

No hay que creerle mucho a lo que dice “internet”: es el reino de la especulación, del palangre, de la opinión libre, libre incluso de cualquier rigor lógico, y libre de sesgarse hacia donde mejor convenga

Pero me ha ido bien, pero que muy bien, con el NOD32. Salvo cuando inserto un pen drive que ha andado por los bajos fondos clientelares contrayendo cunata cochinada se encuentra, que inmediatamente salta una ventana de advertencia, es como no tener antitvirus.

No tengo idea de cuanto pueda estar costando, y a fin de cuentas no me da la gana de que esto sea una guía de compras: si a alguien le interesa, que vaya y averigüe, pero por lo general los antivirus son bien asequibles, y vale la pena estar protegido por un programa tan poco intrusivo y tan seguro (hasta ahora) como NOD 32.

MZ Tools

No conozco a nadie que haya probado las MZTools para VB6 (www.mztools.com) que no se haya preguntado cómo había podido trabakjar sin ellas. Simplemente son el mejor add-in jamás escrito para Visual Basic. La versión 3, para VB6 y VBA, sigue siendo gratis. La versión seis, compatible con Visual Studio 2003 y 2005, se vende (tengo entendido que por 40USD). Paso mucho más tiempo trabajando en VB6 que en .Net, y los IDE de VS 2003 en adelante son bastante más completos que el de VB6, de manera que le he sacado mucho más partido a la versión 3 que a la 6. Sin embargo, tampoco me imagino ninguna versión de VS.Net sin MZTools.

Luego sigo…

 

Propiedades, variables publicas y dogmas

Ayer alguien corrigió un comentario ajeno afirmando que las variables públicas de una clase debían ser definidas como propiedades.

Tengo graves problemas con la autoridad (un poco por eso no me queda mas remedio que vivir como desarrollador independiente). Y la autoridad no es más que alguien que dice como deben ser las cosas.

 El encapsulamiento es un concepto de la OO que permite ocultar la estructura interna de una clase y controlar su interfaz, es decir, la manera en que sus clientes la ven. Entendido de una manera amplia (y todo debe entenderse de una manera amplia) cuando en un programa no OO llamamos a una función, estamos recurriendo a una forma de encapsulamiento: sólo vemos el nombre de la función, sus parametros y el valor que devuelve. La implementación de la función podría cambiar radicalmente, y no nos daríamos cuenta.

La gracia del encapsulamiento en los objetos es que no sólamente la implementación de los métodos se oculta tras una “firma”. El acceso a los miembros de datos tambien puede ocultar efectos secundarios o verificaciones, tras una simple instrucción de asignación.

Por ejemplo:

Class Cliente

Public Enum NivelesCliente
    Detal,
    Mayor,
    GrandesClientes
End Enum

Public nivel As NivelesCliente
Private mLimiteCredito As Decimal

Public Property LimiteCredito As Decimal
    Get
       Return mLimiteCredito
    End Get
    Set (ByVal Value As Decimal)
       mLimiteCredito = Value
       If mLimiteCredito < 100000 Then
          nivel = Detal
       ElseIf mLimiteCredito < 10000000 Then
          nivel = Mayor
       Else
          nivel = GrandesClientes
       End If
    End Set
End Property

En este ejemplo estamos encapsulando una regla de negocio, que hace depender la clasificacion del cliente de su límite de credito.

Encapsular los atributos de las clases puede ser extremadamente útil. La gran pregunta, sin embargo es ¿deben todos los artibutos de las clases estar encapsulados?

Si decidimos que no, podemos escribir cosas tan simples como:

Class UnaClase
    Public Nombre As String
    …

Class OtraClase

   Dim u As New UnaClase()
   u.Nombre = “Julian”

pero si decidimos que sí, entonces deberemos escribir:

Class UnaClase
    Private m_Nombre As String
    Public Property Nombre As String
       Get
          Return m_Nombre
       End Get
       Let (Value As String)
          m_Nmbre = Value
       End Let
    End Property

y en OtraClase el texto queda igual.
 
La unica diferencia evidente es que en la primera versión usamos una linea de código (la declaracion de una variable publica), mientras que en la segunda tenemos que escribir nueve lineas.

En principio, cuanto menos tiene uno que escribir, mejor. Pero la programacion, como todos sabemos, es un arte arcano donde no siempre lo evidente es lo verdadero (y donde casi nunca lo verdadero es evidente).

Los defensores del encapsulamiento a la fuerza te dicen que si bien ahora no existe ninguna regla de validación ni ningún efecto secundario asociado con el atributo en cuestión, podría ser que en el futuro resulte necesaria, y en ese momento deberías cambiar la interfaz de la clase. Y llevan razón. A diferencia de lo que ocurría con VB6 y COM, donde las variables públicas eran convertidas tras bastidores en propiedades, en el CLR las variables públicas se identifican como campos (field), y las propiedades publicas se identifican como variables de instancia (instance) y se generan dos metodos “ocultos” (get_<nombrePropiedad> y set_<nombrePropiedad>) que son los que usan los clientes de la clase (recordemos que eso de acceder a las propiedades mediante simples operadores de asignacion es uno de los pocos privilegios que tenemos los usuarios de VB).

Si la interfaz de una clase privada cambia, no hay mayor problema, ya que todos los clientes de la clase forman parte del mismo ensamblado y se adaptarán a la nueva interfaz en el mismo momento en que la clase sea modificada. Pero si se trata de una clase pública en una DLL, ahí si es verdad que las cosas se complican, ya que sería necesario recompilar todos los ensamblados que dependan de esa DLL.

Pero no me queda mas remedio que conceder que los defensores del encapsulamiento a la fuerza tienen algo de razón.

Por otra parte, cada vez es más frecuente el uso de generadores de código, de manera que la diferencia en esfuerzo de escritura es insignificante en ambos casos.

Por ejemplo, uso MZ Tools 4 para VS2003. Convertir una variable publica en una propiedad es tan simple como escribir la declaración, pulsar con el botón derecho sobre el identificador declarado y seleccionar MZ Tools \ Convertir campo en propiedad.

Pero secuencias de codigo como esta:

    Private m_Nombre As String
    Public Property Nombre As String
       Get
          Return m_Nombre
       End Get
       Let (Value As String)
          m_Nombre = Value
       End Let
    End Property

siempre me ponen los pelos de punta.

Al final todos tenemos nuestros dogmas. Me gustan los mios porque son producto de mi experiencia y de mi reflexión sobre esa experiencia. Y porque de repente se me ocurre exponerlos (al final, si te abres un blog es para escribir cosas, digo yo), pero ni por asomo se me ocurriría intentar imponerlos.

Entonces, mi dogma dice  más o menos así:

Los elementos de datos publicos de las clases privadas, son variables públicas (campos -“fields”- en jerga del CLR) a menos que haya la necesidad de implementarlos de otra manera.

Los elementos de datos publicos de las clases publicas son propiedades, a menos que tenga la seguridad absoluta (algo que nunca pasa: mi esencia es la inseguridad) de que nunca será necesario agregarle funcionalidad a las operaciones de asignacion/lectura de los mismos.

Eso si estoy trabajando con VB.Net. Porque si se trata de VB6  -que aun me consume el 90% del tiempo de trabajo- todos las atributos públicos son variables públicas hasta el momento en que surge la necesidad de implementarlos como propiedades.

 
Salud!