The Spike

Como redactar correctamente correos electrónicos (I)

TheSpike — Mon, 06 Oct 2008 00:11:00 GMT

Introducción

Este el primero de una serie de artículos dedicados a ayudar y mejorar el intercambio de mensajes a través del correo electrónico, "correo" a secas, "e-mail", "mail", o "email" así escrito, según como cada uno tenga costumbre de nombrarlo.

Sea cual sea nuestra labor dentro de la industria o incluso en puestos de trabajo fuera del ámbito de la tecnología, nos encontramos en la necesidad de comunicarnos con los demás a través del correo electrónico. Y el motivo por el que realmente en muchos de los casos se utiliza este medio -a parte de permitirnos una mejor organización de nuestro trabajo diario- es porque deja constancia de la información que se transmite. No es la primera vez que alguno de nosotros tiene que apelar "a lo que se dijo por escrito" o por el contrario nos pasó que, en más de una ocasión, "las palabras se las llevó el tiempo".

Por ello es indispensable, mucho más (o por lo menos antes) que manejar a la perfección tal o cual cliente de correo, poder redactar y transmitir nuestros mensajes de forma adecuada y clara, para que nuestros interlocutores entiendan claramente lo que queremos decirles. De esta forma beneficiamos (o por lo menos no perjudicamos) a nuestro trabajo principal.

Los puntos principales que quiero tocar en esta serie son los siguientes:

Destinatarios: a quién y cómo dirigirse así como añadir o "poner" en copia.
Asunto y mensaje: Parte principal de la serie. Resumen en un cabecera que permita entender el motivo de la comunicación y consejos para la redacción.
Firma y detalles adicionales.
"Escalada de correos": Consejos y recomendaciones cuando la comunicación se extiende a una línea de discusión y esta acaba involucrando hasta al portero del edificio.

Empecemos pues...

Vuelta a la actividad

TheSpike — Thu, 18 Sep 2008 08:06:00 GMT

He de reconocer que ha pasado desde mi última publicación más tiempo que el que realmente había deseado. No soy amigo de las excusas: de igual forma que no me gusta recibirlas, tampoco me gusta utilizarlas para liberarme de mi responsabilidad. De acuerdo a este pensamiento quisiera dar una explicación (y no una excusa) por este prolongado paréntesis en mi (mal llamado) "diario".

Hace unos meses surgió la oportunidad de impartir un curso de formación para la certificación oficial de SQL Server 2005 como una actividad fuera de mi trabajo habitual. A parte, claro está, de beneficiarme económicamente y ayudar a pagar mi reciente certificación MCT, la idea con la que acepté impartir curso era la de continuar con mi deseo de trasmitir mis experiencias personales y mis consejos.

La experiencia fue dura: compaginar la preparación de la materia, la clase y mi trabajo como consultor no fue algo que precisamente me dejara mucho tiempo libre. Pero sin embargo aprendí y disfruté mucho de la situación. Pude además estrechar lazos profesionales y personales con David Carrasco: una de las mejores personas y uno de los mejores profesionales que este trabajo me ha permitido conocer.

Precisamente, fruto de esta relación con David surgió otra nueva oportunidad: realizar una serie de charlas técnicas para Technet España bajo la marca de Tropas IT. De hecho a mediados de junio realizamos la primera presentación la cual trataba sobre Exchange 2007 SP1 y Alta Disponibilidad. La verdad es que el tema habría merecido su propio comentario en este diario pero he dejado pasar tanto tiempo por mi parte que hacerlo ahora carece de sentido. Es mejor pasar el enlace del artículo que realizó David y de esta forma también podéis conocer su diario. Aquí tenéis el artículo.

Tanto el curso como el ciclo de charlas me han permitido apreciar el esfuerzo de aquellos que, como David, centran su trabajo en la formación y la comunicación. Sinceramente ellos dan significado completo a la palabra "dedicación".

Si más arriba ya hablaba sobre el poco tiempo que me dejaba el trabajo diario y la formación, preparar la charla para Tropas IT consumió las pocas horas restantes que me dejaba el día durante las semanas previas al evento.

Finalmente, de vuelta de vacaciones, con el curso con el proyecto de conferencias encaminado, ya vuelvo a encontrar hueco para volver a escribir. También me espera una nueva posición en mi trabajo, algo más enfocada a bases de datos, que me permitirá avanzar mucho más profesionalmente y me ayudara con nuevas experiencias a añadir más contenido a este diario.

Un saludo y gracias por leerme.

Caso: Modificación del texto en el icono de "Mi PC"

TheSpike — Mon, 26 May 2008 14:48:40 GMT

Prólogo

Este caso es un claro ejemplo sobre lo conveniente que es una buena comunicación a la hora de resolver una incidencia. Una buena pregunta ayuda siempre a una buena respuesta.

Síntoma

Un administrador encargado de gestionar las políticas de grupo de la organización informa que, tras aplicar una gpo que modifica el texto del icono de "Mi PC" por el nombre del equipo, los usuarios son capaces de volver a cambiarlo. Llega a la conclusión de que la política sólo se aplica la primera vez. Esta incidencia ha sido comunicada a través de un correo donde se introduce el problema en un simple par de líneas y se adjunta la siguiente captura de pantalla:

El administrador solicita que o bien se deshabilite la modificación del texto al usuario o bien se asegure que la política se aplique de nuevo y sobreescriba los cambios.

Investigación

Es muy poco frecuente que, salvo en estaciones de trabajo, las organizaciones y sobre todo las grandes empresas decidan utilizar versiones de sistemas operativos de servidor traducidas a su idioma local. Este caso es una excepción a la regla ya que no sólo los servidores de dominio sino todos los servidores de su infraestructura están castellano, tanto los sistemas operativos como los sistemas de gestión de bases de datos y correo. Se podría hablar largo y tendido sobre el tema, pero, desde el punto de vista de soporte, donde la amplia mayoría de fuentes de información están en inglés, es más que conveniente mantener el software de infraestructura de servidores en su idioma original.

Por otro lado estamos hablando de políticas de grupo. A través de estas políticas se puede modificar casi cualquier parámetro no sólo de los sistemas operativos de Microsoft, sino también de otros productos como Office, Internet Explorer, o incluso Firefox. De hecho la tecnología permite desarrollar nuevas políticas a medida a través de plantillas. Como dato adicional indicar que existen más de 1500 configuraciones "de fabrica" para Windows 2000, 2003 y XP modificables a través políticas de grupo.

Como paso preliminar en este caso resulta conveniente investigar sobre la opción de cambiar el texto del icono de "Mi PC": cómo se denomina en inglés, en qué sección se configura, qué es lo que modifica realmente a nivel de registro o si aplica a la configuración del equipo o a la del usuario. Por las razones que se han expuesto más arriba, puede ser realmente difícil localizar información una política de grupo, máxime cuando sólo contamos con su nombre traducido. Afortunadamente, para facilitar su consulta, Microsoft ha publicado un listado en Excel con todas las opciones de configuración de políticas de grupo disponibles para sus sistemas operativos. El listado se puede descargar desde este enlace.

Tras una buscar (sin éxito alguno) la configuración en la hoja, averiguar la traducción al inglés de "Cambiar la el texto del icono Mi PC", usar una maqueta de pruebas y dar una vuelta por las KBs de Microsoft y Google surge la idea: ¿No será una política diseñada a medida?

Ahora, revisando la captura de pantalla adjunta en el escueto correo de la incidencia, empieza a tener sentido la palabra "Personalizadas" que aparece en el encabezado del texto de la imagen.

Entre el enfado y la vergüenza se solicita al cliente que confirme si se trata de una plantilla a medida y, de ser efectivamente así, que por favor remita el código fuente de la plantilla para revisarlo. No sin alguna "labor burocrática adicional" se consigue confirmar la sospecha y se obtiene el código de la plantilla personalizada:

 1 CLASS USER
 2 
 3 CATEGORY !!Personalizadas
 4 
 5     POLICY !!Nombre_Host
 6 
 7     KEYNAME "SOFTWARE\Policies\Classes"
 8     EXPLAIN !!Explicacion_Mipc
 9 
10     PART "Cambiar el texto del icono Mi PC a..." COMBOBOX NOSORT EXPANDABLETEXT
11     KEYNAME "SOFTWARE\Classes\CLSID\{20D04FE0-3AEA-1069-A2D8-08002B30309D}"
12     VALUENAME "LocalizedString"
13       
14     SUGGESTIONS 
15       "%computername%"
16       "%username%"
17       "@%SystemRoot%\system32\SHELL32.dll,-9216"
18     END SUGGESTIONS
19 
20     END PART
21     END POLICY
22     
23 END CATEGORY
24 
25 [strings]
26 Explicacion_Mipc="Permite Que el nombre del Icono que Habitualmente llamamos Mi Pc."

En este punto, sin entrar en demasiado detalle, hay que explicar que, por un lado, cuando se aplican políticas personalizadas , lo que hacen en realidad es modificar una sección del registro del sistema operativo y que, por otro lado, pueden ser diseñadas para que afecten a usuarios del dominio (independientemente del equipo donde se conecten) o a equipos del mismo (independientemente del usuario que se conecte).

Partiendo de esta aclaración y revisando el código de la plantilla, este aporta dos pistas importantes:

En la línea 1 se declara con el texto "CLASS USER" que es una plantilla diseñada para modificar la configuración del nodo de usuario.
En la línea 11 se indica que la clave del registro que modifica es "SOFTWARE\Classes\CLSID\{20D04FE0-3AEA-1069-A2D8-08002B30309D}" y, dado que es una configuración de usuario, esta clave cuelga del raíz HKEY_CURRENT_USER.

Nota: Si por el contrario se tratara de una configuración de ordenador, CLASS COMPUTER, la clave se del registro colgaría del raíz HKEY_LOCAL_MACHINE.

Ya con esta nueva información, el siguiente paso es descubrir por qué cuando el usuario cambia a mano el texto "no se vuelve a aplicar la política". Pongo esto último entre comillas porque Windows, en el caso de las políticas personalizadas, no "fuerza" su aplicación.

El funcionamiento de las políticas en la plataforma Windows es un tema algo complejo y a veces confuso: hay que tener en cuenta que este sistema está pensado para dominios formados por volumen considerable de equipos y que, dependiendo del uso que se dé, puede consumir una cantidad de recursos importantes durante los procesos de inicio de sesión. Para evitar problemas de ancho de banda o retrasos en el arranque de los equipos, el "motor" encargado de gestionar las políticas las divide en diferentes grupos de configuraciones y controla su ejecución durante el inicio de sesión, el refresco de políticas automático o la ejecución del comando de refresco manual gpupdate. Uno de esos grupos en los que se divide la ejecución es precisamente el de políticas personalizadas y su configuración por defecto es que sólo se aplican cuando la política es nueva o cuando esta ha sido modificada.

Por lo tanto, atendiendo a lo que el administrador nos solicita en este caso, para que se vuelva a cambiar el texto del icono de Mi PC en los equipos existirían estas tres opciones:

Esperar a que se modifique la gpo y por lo tanto el motor aplique de nuevo las políticas personalizadas.
Ejecutar en los equipos que se desea actualizar el comando "gpupdate /force" el cual obliga a refrescar por completo la política.
Modificar la configuración por defecto de los clientes para que el motor encargado de la aplicación de gpos personalizadas se ejecute siempre.

Por el número de equipos afectados, ninguna de las posibilidades arriba mencionadas sería efectiva ya que modificar las políticas constantemente o forzar su ejecución afectaría negativamente a los recursos de red del dominio y al tiempo de inicio de sesión de las máquinas.

La opción lógica por lo tanto es impedir que el usuario modifique el texto del icono desde la interfaz. Para ello se necesita denegar el permiso de escritura a la clave del registro que referencia la política personalizada.

Tras realizar una prueba en maqueta, se comprueba que el usuario puede seguir cambiando el texto del cono de Mi PC pese a que se han denegado permisos en el registro. Esto complica un poco más el caso, pero gracias a la herramienta que monitoriza los accesos al registro (entre otros recursos) Procmon se descubre que, cuando se hace desde la interfaz gráfica, la clave que se modifica en realidad es otra:

HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\CLSID\{20D04FE0-3AEA-1069-A2D8-08002B30309D}

Seguramente exista algún artículo que explique este comportamiento más en detalle pero, en lo que respecta a este caso, sólo nos interesa saber que, pese a que las dos claves del registro contienen el texto del icono de Mi PC, la que cuelga de SOFTWARE\Classes\CLSID tiene "menos prioridad" que la que cuelga de Software\Microsoft\Windows\CurrentVersion\Explorer. Esta última es la que se modifica desde la interfaz de usuario y si no está vacía, su valor es el que se muestra siempre en la pantalla.

Solución

Primero es necesario modificar la política personalizada de tal forma que se esta enlace a la clave del registro que se modifica desde la interfaz de usuario:

 1 CLASS USER
 2 
 3 CATEGORY !!Personalizadas
 4 
 5     POLICY !!Nombre_Host
 6 
 7     KEYNAME "SOFTWARE\Policies\Classes"
 8     EXPLAIN !!Explicacion_Mipc
 9 
10     PART "Cambiar el texto del icono Mi PC a..." COMBOBOX NOSORT EXPANDABLETEXT
11     KEYNAME "Software\Microsoft\Windows\CurrentVersion\Explorer\CLSID\{20D04FE0-3AEA-1069-A2D8-08002B30309D}"
12     VALUENAME "LocalizedString"
13       
14     SUGGESTIONS 
15       "%computername%"
16       "%username%"
17       "@%SystemRoot%\system32\SHELL32.dll,-9216"
18     END SUGGESTIONS
19 
20     END PART
21     END POLICY
22     
23 END CATEGORY
24 
25 [strings]
26 Explicacion_Mipc="Permite Que el nombre del Icono que Habitualmente llamamos Mi Pc."

Después se procede a modificar el permiso de la citada clave. Al tratarse de la sección del registro HKCU este cambio de seguridad no puede realizarse a través de políticas de grupo, por lo que habrá que utilizar una herramienta o un script que sí lo permita, como por ejemplo subinacl. Subinacl está incluido en el Kit de Recursos de Windows y se puede llamar desde un script de inicio de sesión o también se puede distribuir un archivo de proceso por lotes que llame al ejecutable a través de políticas de grupo o mediante Microsoft Operations Manager. El comando completo para este caso es el siguiente:

subinacl.exe /subkeyreg HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\CLSID\{20D04FE0-3AEA-1069-A2D8-08002B30309D} /deny=S-1-5-4=S

El primer parámetro indica que se va a modificar una clave del registro, después se pasa la dirección y por último se da al orden de denegar el permiso de establecer valor (la opción S) al grupo S-1-5-4, el SID de Windows para INTERACTIVE USER.

Conclusiones

Fuera de lo complicado o no que sea una incidencia, es importante que esta sea comunicada con el mayor número de detalles que ayuden a su resolución siempre, dentro de la medida de lo posible, claro.

Con la experiencia y el conocimiento se puede llegar a detectar a priori la falta de información adicional para la resolución de una incidencia. Una buena práctica es estar atento a los datos más comunes que normalmente se necesitan para resolver los distintos tipos de casos con los que solemos trabajar; esto puede ayudarnos a tener una serie de criterios previos o incluso crear platillas de información preliminar.

Sobre la indumentaria

TheSpike — Tue, 22 Apr 2008 16:46:48 GMT

Siempre ha sido un tema polémico. Algo en parte generacional, en parte lucha de clases. Desde que los informáticos dejamos de pasear en bata blanca por las salas repletas de máquinas ojeando listados de papel continuo, hemos tenido que decidir sobre la conveniencia o no de mantener una "apariencia adecuada".

No es mi intención seguir con la amarga discusión sobre si ir de traje y corbata al trabajo es moral o funcional o si por el contrario ir "de calle" demuestra falta de seriedad. Para mí esto es dar vueltas y no llegar nunca a una conclusión. Es cierto que, salvo en El Gran Héroe Americano, un traje no te va a hacer ni mejor ni peor profesional, pero es igual de cierto que nuestro trabajo implica mantener un trato adecuado con los demás.

Mi consejo personal es evitar en la medida de lo posible que el hecho de llevar una ropa u otra perjudique nuestra labor profesional. Si vistiendo de acuerdo a lo que el cliente espera conseguimos una mejor actitud por su parte y facilita nuestro trabajo ¿por qué no hacerlo? Es más, visto desde otro ángulo: ¿no querer llevar un tipo ropa es un principio por el que se deba arriesgar el resultado del trabajo?

Con esto no quiero decir que se deba ir siempre de punta en blanco, respetando las modas de corbatas, trajes y vestidos. Emilio Tucci, Hermes y Pedro del Hiero. Puede ocurrir (y no es la primera vez que lo veo) que un cliente que vista informalmente se sienta demasiado intimidado por un proveedor con atuendos más "litúrgicos". Tan sólo hay que procurar saber estar en consonancia con entorno.

En muy pocas ocasiones se alcanza un juicio completamente objetivo por parte de los demás. Nuestra valía depende del criterio de nuestros superiores o de nuestros clientes, criterio que en muchos casos contiene sensaciones y sentimientos personales. Es este juicio con el que realmente debemos encajar en primer lugar. Después viene la autocrítica y la opinión propia. Aunque la razón o el sentido común esté de nuestra parte, no debemos olvidar nuestros objetivos como profesionales y estos no dependen del todo de nosotros.

Existe una excepción que confirma la regla de la indumentaria: En ocasiones, para algunos profesionales, resulta conveniente destacar y, utilizando términos de marketing, diferenciar su oferta de entre las demás. Aportar un sello personal para ser recordado o identificado. Un ejemplo claro de ello se ve entre los compañeros dedicados a la formación o la comunicación en un sentido más amplio. En todo caso, esta es una técnica que requiere habilidad y confianza en uno mismo, ya que al juicio de la etiqueta se puede añadir el prejuicio de la envidia.

Un saludo a todos.

Mi experiencia con la formación para MCT

TheSpike — Sun, 06 Apr 2008 09:52:10 GMT

Dentro de mi plan profesional actual y también como medio para llevar a cabo mi deseo de compartir mi experiencia, decidí que era conveniente certificarme como formador en tecnologías Microsoft. Entre las opciones para conseguirlo, se encuentra la asistencia a un seminario en el que al final de éste se entrega un certificado de habilidades.

Siendo sincero, he de reconocer que consideré el "seminario de certificado de habilidades" inicialmente como un mero trámite: pagas lo que piden, te quitas de un día de trabajo, pasas unas horas en una sala haciendo que prestas atención y te llevas a casa un documento sellado tal como si se tratara de una aventura gráfica. Estaba totalmente equivocado: en contra de lo que esperaba, el seminario fue planteado como un foro de participación entre los asistentes, donde pudimos intercambiar nuestras experiencias y opiniones. La audiencia estaba formada en gran parte por profesionales de la formación y todos en general éramos gente con mucha experiencia a nuestras espaldas, por lo que era lógico no enfocar el tema como si fuera una mera retransmisión. Se trataron además gran cantidad de aspectos no sólo relacionados con la formación en sí, sino que también se abordaron temas más generales, tales como el hablar en público (cosa que encontré de extremada utilidad) y el diálogo y el uso del lenguaje.

Todavía estoy asimilando todos los puntos que se trataron, pero, como he comentado, el resultado para mí ha sido tremendamente positivo. Seguramente avance sobre algunos de los contenidos y los utilice en algunos de mis artículos. Por ahora, quisiera remarcar un concepto el cual considero muy importante para todos aquellos que trabajamos de cara al cliente: la asertividad. Ya que es nuevo para mí también, prefiero dejar un enlace de su definición (mil perdones por ello) para que pueda investigar por su cuenta aquél que esté también le resulte algo nuevo y le llame la atención.

Mi recomendación para todos aquellos que estén interesados en la formación es que si se lo pueden permitir no duden en realizar este seminario. Recomiendo también esta clase de cursos a todos aquellos que quieran iniciarse en la realización de presentaciones, en hablar en público o en el trato con los clientes.

Por último me gustaría agradecer desde aquí a nuestro instructor en el seminario, Elisardo López de la empresa Marcom-Deli, su tiempo, su dedicación y su excelente técnica a la hora de trasmitir sus conocimientos.

Saludos a todos.

Caso: El inicio de sesión no funciona adecuadamente

TheSpike — Sun, 23 Mar 2008 16:12:03 GMT

Prólogo

El presente caso muestra algo que, dicho mal y pronto, es una verdadera perogrullada: una solución diseñada a medida no es directamente aplicable a otro entorno por mucho que se parezca al original.

Síntoma

Usuarios de una gran organización localizados en dos edificios distintos experimentan problemas con su inicio de sesión. En concreto hay unidades de red que siempre se les asignan a arrancar el sistema pero hay otras que, de forma aleatoria, no aparecen cuando sí deberían de estar disponibles. Sólo reiniciando el equipo varias veces consiguen que funcione correctamente.

Investigación

Aunque los síntomas iniciales ya apuntan a que el problema es algo externo a los equipos cliente, es conveniente buscar un patrón común entre las máquinas afectadas de todas formas. Esto puede aportar alguna pista adicional para la resolución del caso. Yo, como primer paso, tengo la costumbre de comprobar si los sistemas tienen o no un software o hardware similar.

Efectivamente, todos los equipos involucrados tienen instalados el mismo sistema operativo (parches incluidos) y el mismo conjunto de aplicaciones. Esta pista no es del todo concluyente ya que el usuario asegura que en en la sede principal unos equipos similares no experimentan problemas. Hay diferencias en el hardware entre los equipos, pero viendo que el problema aparece por igual en todos, no resulta útil usar esta idea como criterio de discriminación.

Avanzando un poco por la parte de la configuración de software, el usuario comenta que se tratan de una nueva plataforma de producción para un determinado departamento y que actualmente está desplegada sólo en las dos oficinas con problemas y en la sede principal. Esto ya centra más el caso. La sede principal se conecta con los Controladores de Dominio y a los servidores de ficheros a través de la red de área local mientras que las oficinas afectadas se conectan a través de conexiones remotas. Los servidores de ficheros de las unidades que siempre se conectan correctamente están disponibles en la red de área local de las oficinas.

Ya con las pistas de la configuración y velocidad de conexión, el siguiente paso es revisar el script de inicio de sesión.

El cliente comenta que el script de inicio de sesión en realidad esta compuesto por numerosos scripts los cuales se van invocando los unos a los otros. Este sistema depende de la configuración de la máquina y su pertenencia a uno u otro departamento. De forma casual sale un detalle que, como veremos después, resulta importante para el caso: la tecnología usada se basa originalmente en una solución que un grupo de consultores diseñó para otra organización y ahora han aplicado a esta. Tan sólo se realizaron una serie de modificaciones menores para ajustarlo al nuevo dominio. Avanzando más en la revisión de estos ficheros, se ve que es un script concreto el que aparentemente no llega a ejecutarse, el encargado de asignar las unidades de red. Esta información termina ya de centrar por completo el caso.

Analizando el código, se destacan las siguientes secciones.

En la función principal:

'Inicio del Sript
On Error Resume Next
......

'Creación e inicio de entorno de informe de estado en pantalla
  Set objExplorer= Nothing
  Set objExplorer=CreateObject("InternetExplorer.Application")
  objExplorer.Navigate "about:blank"   
  objExplorer.ToolBar = 0
  objExplorer.StatusBar = 0
  objExplorer.Width=500
  objExplorer.Height = 200 
  objExplorer.Left = 0
  objExplorer.Top = 0
  Do While (objExplorer.Busy)
    Wscript.Sleep 100
  Loop    
  objExplorer.Visible = 1             
  strOutput = "<P><B>CONFIGURACIÓN DE ENTORNO</b></p>"
  objExplorer.Document.Body.InnerHTML = strOutput
......

'Creación e inicio del log en fichero
Set objFilelog= CreateObject("Scripting.FileSystemObject")
If (objFilelog.FileExists(strLogPath)) Then
objFilelog.DeleteFile(strLogPath)
End If
Set filLog = objFilelog.CreateTextFile (strLogProcom, 1)
filLog.WriteLine ("==========================")
filLog.WriteLine ("INICIO DEL LOG")
filLog.WriteLine ("Fecha ; Hora: " & date & " ; " & time) 
......

'Llamada a la función de asignación de unidad MapDrive
Set objNetwork = CreateObject("WScript.Network")
Call MapDrive (strUnidad , "\\" & strSrv & "\" & strRecurso objNetwork, 3)
......

'Cierre de los medios de registro
  strStream.WriteLine("================================================")
  strStream.Close
  WScript.Sleep(2000)
  objExplorer.Quit

Y la función MampDrive completa:

 1 Function Mapdrive(ByVal strUnidad, ByVal strRecurso , ByVal objNetwork, ByVal intReintento)
 2 
 3   On Error Resume Next 
 4 
 5   Dim objDrives, i 
 6   Do 
 7     Err.Clear 
 8     Set objDrives = objNetwork.EnumNetworkDrives 
 9     If objDrives.Count > 0 Then 
10       For i = 0 To objDrives.Count-1
11         If UCase(objDrives.Item(i)) = UCase(strUnidad) Then 
12           objNetwork.RemoveNetworkDrive strUnidad, True, True 
13           i=objDrives.Count-1 
14         End If 
15       Next 
16     End If 
17     strOutput = strOutput&"<P>Conectando la letra "& strUnidad &" a la ruta "& strRecurso &"</p>" 
18     objExplorer.Document.Body.InnerHTML = strOutput 
19     strStream.WriteLine ("Conectando la letra "& strUnidad &" a la ruta " & strRecurso ) 
20     objNetwork.MapNetworkDrive strUnidad, strRecurso 
21     ierr=Err.Number
22     intReintento= intReintento - 1
23   Loop Until Err.Number = 0 or intReintento = 0 
24 
25   Select Case ierr 
26     Case ierr=0 
27       objExplorer.Document.Body.InnerHTML = "<p>Unidad conectada</p>"
28       strStream.WriteLine ("Unidad conectada " & strRecurso) 
29     Case ierr=-2147024829 
30       objExplorer.Document.Body.InnerHTML = "<p>No existe el recurso</p>"
31       strStream.WriteLine ("Error: No existe el recurso " & strRecurso) 
32     Case ierr=-2147024811 
33       objExplorer.Document.Body.InnerHTML = "<p>No se pudo liberar la unidad</p>" 
34       strStream.WriteLine ("Error: No se pudo liberar la unidad "& strUnidad) 
35     Case Else 
36       objExplorer.Document.Body.InnerHTML = "<p>Error no controlado</p>"
37       strStream.WriteLine ("Error: " & CStr(ierr) & " - " & Err.Description) 
38   End Select 
39   On Error Goto 0 
40 End Function

Analizando la salida por pantalla y el fichero de registro se comprueban dos cosas:

Por un lado las ventanas de Internet Explorer cierran muy rápido o que incluso no aparecen.
Tanto si funciona el script como si no , el fichero txt de registro se corta siempre después de la línea 19 del código: "Conectando al recurso \\Servidor\Z"

¿Qué hacer llegado a este punto? Muy sencillo: ya que pese a tener un control de errores y un sistema de registro no aparece ningún mensaje claro... ¡Desactivemos el control de errores! :-). Para ello se hace una copia del script original, se comenta todas las instrucciones "On Error" y se le asigna a un usuario de los del grupo afectado.

Cual es la sorpresa cuando el usuario reporta que, tras numerosas pruebas, le aparece un mensaje de error en tiempo de ejecución en una línea de la función principal, la correspondiente a la instrucción que crea el objeto Internet Explorer para el informe en pantalla:

Set objExplorer=CreateObject("InternetExplorer.Application")

El error en tiempo de ejecución (del que lamentablemente no pude capturar pantalla) detalla que, pese a haber abierto otras ventanas de explorador, existe un bloqueo de recursos que impide abrir una más. Este bloqueo, por lo que se pudo ver después, ocurría en todos las oficinas. Se pudo ver también que el fallo sólo ocurría si el usuario iniciaba sesión nada más encender el equipo.

Con el control de errores activado y ocurría este problema, la función principal continuaba ejecutando las siguientes instrucciones, eso sí, sin la pantalla del explorador. De hecho llamaba a la función MapDrive y llegaba a la siguiente instrucción:

    strOutput = strOutput&"<P>Conectando la letra "& strUnidad &" a la ruta "& strRecurso &"</p>" 
    objExplorer.Document.Body.InnerHTML = strOutput

Aquí, al no existir el objeto objExplorer, el sistema registraba un fallo más. Esto en teoría no sería problema, ya que la función también posee un control de errores. El problema surge cuando al ejecutar la asignación de unidad esta también falla: al producirse dos errores seguidos, el control de errores se desactiva y la ejecución sale de la función. Si la ventana del explorador estuviera funcionando este problema nunca ocurriría, ya que los errores de asignación de red se descartan en el siguiente reintento gracias a la instrucción:

Err.Clear

Por último se comprueba que la sentencia select de la función estaba mal escrita, lo que impedía que salieran las entradas del fichero txt de registro que se echaban en falta.

  Select Case ierr
    Case ierr=0
......

Solución

Como solución al caso se opta por eliminar por completo los mensajes por pantalla a través de Internet Explorer. Es "vistoso" y da la sensación de "algo funcionando por debajo" al usuario pero en grandes compañías, con un gran número de equipos y servidores conectados a redes de distintas velocidades, lo que prima es la eficiencia.

Una mención especial merece la instrucción "on error resume next". La verdad es que el uso de este comando en entornos como inicios de sesión o tareas administrativas tendría que reducirse al mínimo. Yo personalmente intento hacer lo posible para no tener que utilizarlo. El uso de "on error resume next" debería de ser sólo utilizado en partes del código donde se realicen llamadas a recursos no controlados y exista una posibilidad común de fallo y deseamos evaluarlo para reaccionar de forma adecuada. Un ejemplo, basándonos en el código anterior sería el siguiente:

 1 Function MapeaUnidad(ByVal strUnidad, ByVal strRecurso , ByVal objNetwork)
 2 On Error GoTo 0
 3 
 4   Dim objDrives, i 
 5     Set objDrives = objNetwork.EnumNetworkDrives 
 6     strOutput = strOutput&"<P>Conectando la letra "& strUnidad &" a la ruta "& strRecurso &"</p>" 
 7     objExplorer.Document.Body.InnerHTML = strOutput 
 8     strStream.WriteLine ("Conectando la letra "& strUnidad &" a la ruta " & strRecurso ) 
 9 
10     On Error Resume Next
11 
12     objNetwork.MapNetworkDrive strUnidad, strRecurso 
13 
14     On Error GoTo 0
15 
16      ierr=Err.Number
17  
18     Select Case ierr 
19     Case 0 
20       objExplorer.Document.Body.InnerHTML = "<p>Unidad conectada</p>"
21       strStream.WriteLine ("Unidad conectada " & strRecurso) 
22     Case Else 
23       objExplorer.Document.Body.InnerHTML = "<p>Error no controlado</p>"
24       strStream.WriteLine ("Error: " & CStr(ierr) & " - " & Err.Description) 
25   End Select 
26 End Function

Conclusiones

Cada organización es diferente y requiere que ciertas soluciones sean ajustadas a sus necesidades. En otros sitios, los mismos ajustes no serían necesarios o incluso provocarían problemas imprevistos. Esto no invalida que se pueda utilizar en distintas ocasiones una buena idea, tampoco hay que reinventar el plato sopero, vamos, pero sí es conveniente prestar mayor atención cuanto más particular sea el entorno donde nos movemos. Sobre todo no hay que sorprenderse si algo que ha funcionado en miles de despliegues ahora deja de hacerlo.

Ser metódico en la resolución de los problemas e incluir siempre una búsqueda de patrones comunes entre los elementos afectados como se ha intentado mostrar en este artículo, en cambio son medidas que siempre darán buenos resultados independientemente del tamaño o tipo de organización donde se aplique.

Un saludo a todos y gracias por leerme.

Sobre la redacción

TheSpike — Fri, 29 Feb 2008 12:18:05 GMT

Un breve mensaje sobre algo que considero realmente importante: una comunicación adecuada es algo crucial para el desarrollo de nuestro trabajo. Muchos de nosotros, los que tuvimos una vocación temprana, desde el principio de nuestras carreras (o incluso antes, cuando sólo jugábamos con los ordenadores) hemos centrado nuestros esfuerzos en adquirir el mayor número de conocimientos técnicos posibles. Siempre en constante actualización, siempre atentos a los nuevos avances de la industria. Somos máquinas de leer manuales. Esto, naturalmente, ha supuesto sacrificar otros aspectos no tan importantes quizá, pero a la larga necesarios. Hemos descuidados otras facetas, tales como ordenar nuestras ideas correctamente y expresarlas sobre el papel, por ejemplo.

Por otro lado, por el tipo de trabajo que desempeñamos, orientado al servicio, no hemos acostumbrado a intentar responder siempre de forma inmediata a las situaciones que se nos presentan, muchas veces como si se tratara de un acto reflejo. Esto en ocasiones no nos permite reflexionar sobre lo que realmente queremos expresar y sobre la mejor forma de hacerlo.

Combinadas, la falta de práctica y la precipitación hacen que nuestra escritura sea confusa y errónea, perjudicando así nuestra labor como técnicos. Puede incluso que esto nos pase hasta al hablar en los peores casos.

Y, aunque a muchos (entre los que me incluyo activamente) nos parezca injusto, es un hecho que, a la larga, la forma siempre acaba teniendo más importancia que el fondo. Se puede hacer una gran labor técnica y tener también la razón de nuestro lado pero si no somos capaces de explicar correctamente nuestro punto de vista, de reportar adecuadamente nuestras actividades o solicitar la colaboración de los demás, todo nuestro esfuerzo caerá en saco roto. ¿Quién no ha oído la típica coletilla de "es un excelente técnico, pero para tenerlo encerrado en una habitación"?

Por lo tanto, no olvidemos que nuestro trabajo también consiste en relacionarnos con otras personas, personas que, en la mayoría de los casos, no tengan ningún conocimiento técnico ya que esa no es su tarea principal. Tengo muchas experiencias reales que ilustran esta opinión y seguramente cuente las más interesantes en su momento. Por ahora quiero recordar a Vicente R., un excelente administrador de sistemas que estuvo a mi cargo durante lamentablemente sólo un año, al que el mezquino jefe del Departamento de Organización de mi empresa le llamaba despectivamente "Cantinflas" porque, cuando hablaban, Vicente siempre se ponía nervioso y acababa tartamudeando y confundiendo palabras.

La verdad es que al final me he enrollado más de lo que quería. Tan sólo intentaba subrayar algo de lo que normalmente nadie suele tratar en las áreas técnicas donde nos movemos. En absoluto me considero experto, pero intentaré enseñar algún truco y algún ejemplo en siguientes artículos que ayude mejorar esta forma de relacionarnos con jefes, clientes y proveedores. Precisamente, una de las razones por las que yo escribo aquí es practicar y avanzar en mi redacción y recuperar un poco del tiempo perdido.

Un saludo a todos.

La leyenda de la hoja Excel errante (Parte I)

TheSpike — Sat, 23 Feb 2008 09:18:00 GMT

Blanco sobre negro

Nació como hoja Lotus 1-2-3. Su creadora, Veva, Genoveva Pérez Lauzán, había ido a un curso de ofimática pagado por la empresa - una cadena de concesionarios a nivel nacional de coches nuevos y de ocasión - y se sentía muy orgullosa por ello. Sin duda alguna, por esa fecha -corría el año 1988- era la secretaria mejor preparada de todo el departamento de marketing. Por eso, cuando su jefe, Paco, Francisco José García Marcos, la encargó un informe-resumen-mensual-con-los-resultados-de-ventas-de-coches-organizada-por-provincias-y-modelos ella no dudó un instante en diseñarse una hoja de cálculo. Ahí iría sumando periódicamente las cifras que recogía de los enormes listados en papel continuo que le entregaba el Departamento de Explotación de Datos. Este fue el primer paso de un largo camino para la hoja Excel errante.

Así pasaron un par de años. Cansada de gastar tres días enteros todos los meses metiendo cifras a mano, Veva consiguió que el Departamento de Explotación de Datos sustituyera el engorroso taco de papel troquelado blanco y crema por un disquete de 5¼ negro, no sin antes habiéndolo peleado duramente. Sus compañeras se sorprendieron un poco ya que por esa época lo que precisamente sobraba era papel, no como ahora, que para imprimir algo tienes que mendigar por un folio con una cara limpia al menos. Pero Veva era una adelantada a su tiempo y sabía que "esto de la informática iba a ahorrarle muchas horas de trabajo". Claro que no sabía que eso era a costa de las horas de sueño de algún informático.

Smells like a teen spirit

A finales de 1992, comienzos de 1993, el recién creado Departamento Operaciones y Microinformática empezó a sustituir "esa chatarra de equipos con pantallas verdes fosforito" por flamantes IBM PS/2 con "tarjetas gráficas VGA". Y con estas tarjetas vino "El Windows", el cual casi arruina la vida de los más veteranos, tan poco acostumbrados al ratón y a pantallas tan brillantes y blancas.

Superada esta crisis con algunos filtros para la pantalla y cursillos de 40 horas, todo el mundo se calmó tras comprobar que sus aplicaciones de siempre seguían funcionando igual pero en una pantallita algo más pequeña. De hecho, nadie se preocupó en actualizar la versión de Lotus 1-2-3 de Veva. Además ya no necesitaba el dichoso disquete de 5¼ negro. Ahora recibía el fichero "por red" gracias a un proyecto que según se rumoreaba había costado mucho esfuerzo y, sobre todo, mucho dinero. Bien es verdad que el dinero no se iba muy lejos, ya que la encargada de llevar a cabo el citado proyecto era la nueva empresa creada por Paco, su ahora ex-jefe, junto con un profesor de informática de la Universidad Politécnica y formada por algunos "estudiantes espabilados" de la misma. Nuestra hoja seguía viva y coleando y, por ahora, estaba sobreviviendo al comienzo de la "Revolución Windows" y la "Cultura del Pelotazo". Hasta que de repente...

Reencarnación

...en 1995 un señor llamado William Henry Gates III vino a Madrid a presentar "El Nuevo Windows", que no por casualidad, claro, se llamaba Windows 95. Dicen que incluso firmó cajas de su programa en El Corte Inglés de Sol. Por cierto, ya no había que llamarlo programa sino Sistema Operativo. Esos trece disquetes (más el de arranque) de 3½ grises no parecían traer muy buenas noticias para nuestra hoja. Y así fue: A principios de 1996 reinstalaron todos los equipos de la oficina con el nuevo Windows llevados por el entusiasmo del márketing y en contra de todo sentido común. Tras noches en vela, sobredosis de cafeína y plegarias a Santa Rita, la compañía logró rehacerse, consiguió que su programa de contabilidad volviera a la vida y presentó "El Cierre de Cuentas Anuales más Largo de su Historia". Los jóvenes estudiantes de la nueva empresa de Paco consideraron este logro equivalente al de los mártires que trajeron los planos de la segunda Estrella de la Muerte. Pero lamentablemente, pese a muchos esfuerzos, la discreta pero eficiente hoja Lotus 1-2-3 no conseguía salir de sus pobres 16 bits.

Sin duda el gran beneficiado de esta catarsis tecnológica fue Paco: su empresa era la encargada casi en exclusiva de migrar todos los programas que habían dejado de funcionar por el cambio a Windows 95. Además, gracias a los "lenguajes de cuarta generación" y a los nuevos Ciclos Formativos de Grado Superior -una forma elegante y pretenciosa de llamar a la Formación Profesional de toda la vida- ahora disponía de una herramienta barata y rápida y de unos becarios más baratos pero no muy rápidos. De ahí que Paco obviara la solución más fácil y presentara un presupuesto por un desarrollo en Visual Basic 4 para sustituir la hoja Lotus 1-2-3. El hecho de que el precio de un desarrollo como este era casi el doble de lo que costaba una versión de Lotus nueva no fue un problema ya que salvo él y su amigo, el ejecutivo de la cadena de concesionarios que se llevaba un 5% de cada contrato, nadie más conocía ese detalle.

El desdichado encargado de la ejecución fue José Manuel, José Manuel López Iglesias, de 22 años y a tres meses de terminar su titulación de Técnico Desarrollador de Aplicaciones Informáticas... si es que aprobaba estas "prácticas en lugar de trabajo". "Trabajo en lugar de prácticas" habría sido un término más acertado, pero cuando uno entra de novato en la informática la semántica es algo fuera de cualquier discusión.

Por supuesto, ni que decir tiene que el proyecto fue un auténtico desastre: Las dos semanas de experiencia profesional de José Manuel más el hecho de que era la primera vez en su vida en el que había visto una hoja de cálculo ayudó mucho a que se cumpliera la famosa parábola del usuario que quiere un columpio. El pobre en los tres meses de beca bajó a dos cifras su peso, cosa que sus repetidas dietas no habían conseguido nunca antes. Sudaba como pollo en el matadero cada vez que se acercaba a la mesa de Veva e instalaba una nueva prueba la cual siempre funcionaba en su equipo pero invariablemente fallaba en el de ella. Justo cuando terminó su período de prácticas, Coritel le ofreció un "puesto con una gran proyección para un joven como él". No sabía cómo esa empresa había dado con él, pero no dudó un instante en firmar a ciegas el contrato como si fuera un ex-convicto que se alista a la Legión Extranjera. Así que dejó el proyecto a medio terminar, a Veva tomando valerianas como si fueran Juanolas y a Paco maldiciendo el Estatuto de los Trabajadores y la L.O.G.S.E. Marchó en busca de "un futuro brillante y prometedor", que Dios se apiade de su alma.

Finalmente la razón venció a la codicia y se optó por una evolución natural del producto. En escasos tres clicks de ratón (presupuestados en tres jornadas de un técnico especialista a 7.000 Pts. la hora menos un 5%) la antigua hoja "ventas.wk2" ahora pasó a llamarse "ventas.xls". Su aspecto flamante, blanco y brillante, fresco y nuevo, parecía un remake a todo color de un clásico de la R.K.O.

Y según pasó el tiempo el término "hoja de cálculo" dejó de usarse de igual forma que el viejo MS-DOS fue cayendo en el olvido. Todo el mundo empezó a llamarla "Hoja Excel" o "Excel" a secas y ahora viajaba a través "del email" por "La Internet" y se compartía en un "disco compartido" y se imprimía en las nuevas impresoras láser de la oficina y de vez en cuando se "corrompía" y había que buscar un "backup" para volver a trabajar con ella.

Pasaron más cosas, cosas buenas y cosas no tan buenas, pero ya veremos en la segunda parte de esta historia....

Manifesto 1.0

TheSpike — Sat, 09 Feb 2008 12:39:56 GMT

No ha sido hasta ahora, después de veinte años delante del ordenador -doce de ellos pagándome "el vicio de vivir" gracias a él- cuando he sentido interés por compartir las cosas que he ido aprendiendo, así como las que ahora llaman mi atención. Tengo la sensación de estar en un momento de mi vida y de mi carrera en la que mi experiencia y mis ideas ya merecen ser compartidas.

Pero... ¿cómo hacerlo? O mejor dicho: ¿Cómo hacerlo para que sea útil y original?

Soy el primero en admitir que Internet no necesita un blog más que se alimente de otros blogs, que a su vez se alimentan de más blogs, que a su vez tiran de la documentación técnica que ya publica el propio fabricante. Por eso, como punto de partida, me he propuesto escribir en esta primera entrada una declaración de intenciones que me comprometa a intentar que este "cuaderno de apuntes" merezca la pena.

Estos son mis propósitos:

Publicar de forma principal experiencias personales. Casos del día a día que vaya encontrando en mi trabajo y que, por su complejidad o interés, sea algo que aporte una lección positiva a los demás.
Además de dar una visión técnica, dar también una "visión política" de la tecnología. Incluir artículos enfocados en procedimientos genéricos de resolución de problemas, cómo tratar con clientes, compañeros y proveedores, etc.
Intentar referenciar un mínimo de artículos externos. Sólo cuando cuando estos documenten o amplíen el contenido técnico del caso que describa.
Las pocas ocasiones que publique artículos de otros blogs o documentación técnica "a cuchillo" pediré mil disculpas, o incluso un millón.

Respecto a dar "una visión política", haré una presentación más detenida sobre esta idea en posteriores artículos. Tan sólo comentar que, en algunas ocasiones, no sólo basta con ser un técnico excelente, sino que también es necesario saber trasmitir correctamente las opiniones que se tengan y sobre todo saber relacionarse con los demás actores que participan del entorno de trabajo.

Por otro lado, cuando incluya un artículo externo, lo haré por tres razones:

Que sea algo que me resulte a mi parecer muy interesante.
Porque no tenga más que aportar que lo que el autor ya ha dicho.
Y porque crea conveniente hacerlo llegar a un mayor número de personas.

Según vaya evolucionando este cuaderno, seguramente tenga que replantear mis intenciones y mis deseos. Por eso he decidido añadir un "versionado" al artículo, para poderlo hacer también evolucionar.

No perdamos más tiempo y empecemos ya con esta aventura.