Esas típicas excusas...

Hace algún tiempo conseguí un blog donde comentaban los 10 mandamientos de los programadores. En http://www.devtopics.com/10-commandments-for-programmers/ los hay a montones. Sin embargo, voy a dar un nuevo enfoque: esas excusas/peticionies que nos damos/hacemos unos a otros en esto de soporte, desarrollo e infraestructura:

1. Si desarrollas, el tradicional "en local me funciona". LO ODIO. Por supuesto que en local te funciona! eres administrador, tienes todos los privilegios, eres SA de la BBDD! pero eso NO ES SEGURO, y cuando vas a otro entorno, suele explotar por todas partes.
2.  "qué versión estás usando de..." o "qué nivel de parches..".  De verdad! Hay diferencia entre 32bits/64 bits. Por lo menos en lo relacionado a Windows. NO es lo mismo trabajar con el Framework 2.0 que el 3.5 o el 4! y mucho menos con los Service Packs, por lo que suelen haber problemas entre las distintas versiones de Java, .Net, SQL, MySQL...
3. Pelea diaria entre cliente/managers/desarrolladores:  "Eso no está especificado" o "No está documentado".  Suele venir seguida de la siguiente frase en la lista:
4. "Haz un RFC con..". Vale. Nos equivocamos. Consideramos que una tarea era más sencilla que lo que al final resulta ser. Pero por DIOS! una cosa es que se documenten los cambios que pide un cliente en inferfaz gráfica (UI) y otra muy distinta es que no contemples el tiempo para documentar, probar debidamente y un laaaargo etc.
5. De esta estoy cansado: "ponlo hard-coded (a cañón, cableado, directo.. etc) y luego lo cambiamos". NO!. Error crucial. Las cosas deben hacerse 1 vez y bien, porque si no, implica re-trabajo. He visto muchos ficheros de configuración con Passwords/usuarios/Cadenas de conexión sin encriptar como para pasar esto por alto...
6. Cuando una persona hace las cosas de una forma, y ahora tiene que hacerlas de otra: "Es que esto en la versión TAL se hace de otra forma". Anécdota: esto se lo escuché a un comercial de Microsoft, cuando en una consultoría para SharePoint 2007, cada 5 minutos que no conseguía algo, decía que en SharePoint 2010 estaba en otro sitio o se hacía de otra forma... SI, eso lo sé: Que se hace de otra forma en otro producto. Pero el que ahora nos preocupa este, es el que estamos trabajando y deja el fastidio!!!!
7. El típico peloteo entre áreas: que si una incidencia es de Operaciones, de Desarrollo, de BBDD, de comunicaciones, de Servidores.. en fin. Va pasando entre tantas cosas que llega un punto en que cuando te dan una respuesta oficial... ya ni te acuerdas porqué lo abriste..  siempre sale alguno que dice "Pero esto no es nuestro" y en vez de reenviarlo a quien corresponde, te lo retorna...
8. En un mundo tan altamente dinámico como el de la tecnología, no puedo creer que todavía hoy tenga que escuchar cosas como "es que está en inglés..." y te pongan carita de perro pisao y te lo digan con una voz de niñita llorosa.  A ver. Esto es tecnología. Cuando terminas de traducir un libro al español, el producto probablemente ya es obsoleto y hay una nueva versión. Así que acostúmbrate! No digo que se hable inglés nativo, pero al menos entiende lo que te pone una ventana... Esto tiene muchos vértices, porque cuando te sale algún mensaje de error, basta con googlearlo en Inglés y tienes N resultados. Pero si lo buscas en Español.. debo informarte amigo, que vas a tener apenas una fracción de los resultados posibles...
9. Hay cosas que van contra-natura. Yo entiendo que trabajando en una consultora o en un departamento de informática, quien paga mi salario suelen ser comerciales/negocio/clientes.. y como tal, hay que tratar de satisfacer sus necesidades. Pero eso es una cosa y otra muy distinta es el "pero es que el cliente quiere"... Eso a veces se traduce en cosas como que cuando presionen el botón de "TAB", en vez de ir a la sección que está a la derecha, vaya hacia abajo. Esto no estaría mal, si luego no te piden que no haga Scroll, teniendo 100 campos que llenar!
10. "Arregla en Producción y luego lo bajamos al resto de entornos". Todos los años consigo uno así... y al final, los entornos son distintos, las pruebas en los otros entornos luego fallan por esta corrección y bueno....

Si sabéis alguno más, espero sus comentarios!

Limitaciones de navegadores con SharePoint 2010

Microsoft ha liberado un pequeño artículo donde indica el soporte que tienen
los distintos navegadores al usar SharePoint 2010. Aunque el nuevo ServicePack1 incluye
algunas mejoras y soportes adicionales (Google Chrome por ejemplo), hay ciertas cosas interesantes.

Browser	Soportado	Soportado con Limitaciones	No Probado
Internet Explorer 9(32-bit)	X
Internet Explorer 8(32-bit)	X
Internet Explorer 7(32-bit)	X
Internet Explorer 9(64-bit)		X
Internet Explorer 8(64-bit)		X
Internet Explorer 7(64-bit)		X
Internet Explorer 6(32-bit)			X
Mozilla Firefox 3.6 (en Sistemas Operativos Windows)		X
Mozilla Firefox 3.6 (Con Sistemas Operativos No-Windows)		X
Safari 4.04(Con Sistemas Operativos No-Windows)		X

Uno de los aspectos fundamentales de esto es que Internet Explorer 7,8 y 9 para 64 Bits
tienen problemas reconocidos con SharePoint 2010. Traduzco y resumo a continuación
los principales problemas reconocidos.

Característica	Limitación	IE7	IE8	IE9
Conectar con Outlook, Conectar con Office y Sincronización con el Workspace de SharePoint	Funciona con un control ActiveX y el protocolo stssync://. Las funcionalidades pueden estar limitadas sin un control ActiveX como el incluido en Microsoft Office 2010. También requiere una aplicación compatible con el protocolo stssync:// como Microsoft Outlook.	X	X	X
Vista de Hoja de Datos	Requiere un control ActiveX de 64Bits. Microsoft Office 2010 no provee una versión 64bits de este control.	X	X	X
Editar en aplicación de Microsoft Office	Requiere un control ActiveX de 64Bits. Microsoft Office 2010 no provee una versión 64bits de este control.	X	X	X
Vista del Explorador	Eliminado en SharePoint Server 2010. Las bibliotecas que hayan sido migradas de una versión anterior de Sharepoint pueden contener Vistas de Explorador y puede que las vistas no funcionen.	X	X	X
Exportar a Excel	Descarga un fichero con una extensi&ocute;n .iqy al navegador. Si Microsoft Excel no está instalado y no hay otra aplicación configurada para abrir estos ficheros, la característica no funcionará.	X	X	X
Subir ficheros y Copiar	Requiere un control ActiveX de 64Bits. Microsoft Office 2010 no provee una versión 64bits de este control.	X	X	X
Integración con Microsoft InfoPath 2010	Requiere un control ActiveX de 64Bits. Microsoft Office 2010 no provee una versión 64bits de este control.	X	X	X
Integración con Biblioteca de Imágenes de Microsoft PowerPoint 2010	Requiere un control ActiveX de 64Bits como el provisto en Microsoft Office 2010. Pueden usarse los siguientes workarounds cuando no se ha instalado ningún control: -Si se desean subir varias imágenes en una Biblioteca de Imágenes, el usuario debe subirlas una a una usando Upload.aspx -Si se desea editar una imagen en una Biblioteca de Imágenes, hay que descargar la imagen, editarla y subirla nuevamente a la biblioteca. -Si se desea descargar más de una imagen de una Biblioteca de Imágenes, hay que descargarse imagen por imagen haciendo clic en el link de la imagen.	X	X	X
Creación de Diagramas con Microsoft Visio 2010	Requiere un control ActiveX de 64Bits. Microsoft Office 2010 no provee una versión 64bits de este control.	X	X	X
Nuevo Documento	Requiere un control ActiveX de 64Bits. Microsoft Office 2010 no provee una versión 64bits de este control. Aunque la opción “Nuevo Documento” puede no funcionar, puede usarse la funcionalidad “Subir Documento”. Si se instala y configura Office Web Applications en el servidor, laopción “Nuevo Documento” funciona y pueden crearse documentos Office en el Navegador	X	X	X
Enviar a	Puede necesitar un control ActiveX 64 bits. Microsoft Office 2010 no provee una versión 64 Bits de este control. Sin el control, los archivos no pueden ser enviados de una granja a otra de SharePoint. Sin embargo, pueden ser enviados de un sitio web a otro.	X	X	X
Firmar Formularios (InfoPath Form Services)	Requiere un control ActiveX de 64Bits. Microsoft Office 2010 no provee una versión 64bits de este control.	X	X	X
Integración con Hojas de Datos y Bases de Datos	Requiere un control ActiveX de 64Bits. Microsoft Office 2010 no provee una versión 64bits de este control. Pueden usarse los siguientes workarounds cuando no se ha instalado ningún control: -Si el usuario quiere editar un documento, debe descargarse el documento, editarlo y subirlo al sitio nuevamente. -En una lista que requiera hacer un CheckOut del documento para su edición, debe usarse el menú “Edición…” para hacer el CheckOut, editarlo y luego hacer el CheckIn usando el menú “Edición...” -Expotar a hoja de datos. Puede realizarse haciendo clic en “Exportar a Hoja de Datos” en la pestaña “Lista” en el Ribbon.	X	X	X
Conexiones entre Web Part	Puede requerir la desactivación del bloqueo de Popups del Navegador para los sitios de SharePoint.	X	X	X
Integración entre Biblioteca de Presentación y PowerPoint 2010	Requiere un control ActiveX de 64Bits. Puede utilizarse el siguiente mecanismo cuando no se ha instalado un control: -Eliminar una diapositiva. Se pueden eliminar las diapositivas seleccionando la diapositiva y haciendo clic sobre “Eliminar Diapositiva”. Esto debe repetirse para cada diapositiva que se desee eliminar.	X	X	X

En esta URL pueden apreciar más información:

http://technet.microsoft.com/en-us/library/cc263526.aspx

Nuevo mecanismo para los updates de Microsoft

Hola!

Tiempo sin escribir. Pero les dejo algo de info interesante. Es una de esas tonterias a las que no les prestamos atencion pero que posteriormente, cuando no tienes mas nada que hacer y te das cuenta, te parecen super interesantes.

Microsoft ha mejorado el proceso de actualizacion de parches. He probado con el SP1, el SP2 de SQL Server 2008 y con uno para Windows 2008 Server. Lo que me sorprende es que ya los parches no solo se ejecutan y punto, sino que vienen varias pantallas para indicarnos los ficheros que pueden ser conflictivos, hace un pre-run para ver si se cumplen ciertas condiciones.

He aqui unos pantallazos...

Aqui se puede ver el PreScan. Nos dice si falta algun elemento.

Luego tenemos una segunda pantalla, donde podemos seleccionar los elementos a instalar/actualizar

Una tercera pantalla novedosa, que nos indica que procesos/ficheros estan siendo utilizados y pueden afectar nuestro proceso de instalacion 

Una cuarta pantalla nos muestra el resumen de todo aquello cuanto hemos seleccionado.

Una quinta pantalla con el proceso como tal de actualizacion (esta si es tipica)

Creo que esto es todo por ahora. Tengo un par de chorradas mas que compartir, veremos si las actualizo pronto

Tercerización de servicios (y la seguridad asociada)

Una de las cosas con las que frecuentemente solemos toparnos los desarrolladores, consultores y tecnócratas en general, es con la administración de permisos y seguridad en las redes. Si se tiene una empresa pequeña, unos 25 empleados en plan Fabrica de Software, pues.. lo normal es que todos los desarrolladores sean administradores locales, se establezca una política para subir cambios a un entorno de Desarrollo común, estable. Pasadas las pruebas del equipo de desarrollo, pasamos a un ambiente de pre-producción donde otras personas ejecutan sus test. Esto.. en plan pequeño.
Que sucede cuando nuestra compañía es una empresa de mas de 100 empleados, con personas con computadores portátiles, y donde hay tercerizados (esto es, nuestra empresa sub-contrata a otras empresas para labores específicas)? Cómo se determinan los privilegios administrador/usuario avanzado/colaborador/solo lectura?
En mi recorrido, creo que una práctica sana sería: los desarrolladores como usuarios restringidos en sus equipos, pero con una máquina virtual con la que puedan "trastear" y desarrollar. Políticas de supervisión de navegación en el proxy para limitar las cosas que pueden acceder (dudo que Youtube tenga algo interesante para un programador). Si el requerimiento es prohibir a los usuarios estar todo el dia conversando por MSN/GTALK (que me parece iluso, uno puede ser tan o incluso mas productivo y usar estas herramientas), algun cliente de mensajería que puedan usar los miembros del equipo de desarrollo, pero que no permita comunicación web (algo tipo MS Comunicator). Un servidor de fuentes, y una política acertada de cambios en servidores (a desarrollo puede ser diaria, mientras que a otros entornos, semanales o mensuales). A los miembros tercerizados, se les pudiese crear un "grupo" de Active Directory con pemisos similares a los del grupo de desarrollo local.
El asunto que vendría a complicar todo es: quien maneja el AD? personal de la empresa, o se subcontrata? esto es un asunto espinoso, ya que hay empresas en las que la burocracia y procedimiento de cambios en ambientes de explotación, suelen demorar mucho y pasar por tantos niveles, que mas que controlar la seguridad, entorpecen el desarrollo y mantenimiento de aplicaciones.

Rompiendo los ladrillos

De jovencito, recuerdo mi fascinación por los tipos que rompían ladrillos a punta de golpes: Manos, cabeza, piernas, rodilla. Todo era permitido. Me los imaginaba super fuertes. Un día, mi primo, que de eso sabía bastante, me indicaba no lo rompes solo con una parte del cuerpo, sino con todo el cuerpo. El peso ejerce un enorme poder al momento de transmitir algo....

Recuerdo también la "estela de la destrucción": los ladrillos que estaban arriba tenian pequeñas fracturas que a medida que se descendía, era mayor. Hasta llegar a los últimos ladrillos que quedaban desmenuzados.

Ya de "mayorcito" me he fascinado al ver como ese mismo fenómeno se repite en las oficinas. El Jefe Superioris está haciendo algo y le falla un sistema (digamos, un hipervínculo no se muestra en una página web). Comienza el proceso de "estela de destrucción": el dichoso jefe transmite a un gerente de primera linea (el CIO, el responsable de TI, etc, etc etc) la "incidencia" con un "sabes que me pasó esto". Empieza allí el calvario: "ya te envío a alguno de los muchachos para que lo resuelva" o "Que raro? ese comportamiento no es normal". Sigue un "vamos a escalarlo con el personal apropiado para verificar el porqué ocurre eso". Frases acartonadas van y vienen cual manual de protocolo. Y así comienza la estela. El gerente de primer nivel le dice al de segundo "el Jefe me manifestó que hay algo en la aplicación X que no le funciona". El de segundo al de tercero: "el jefe/dueño/manda más/chivo que mas mea/papá de los helados le dijo al gerente qe algo no le funciona". y sigue con un "el XXX le armó un rollo al gerente porque algo no le funcionó, y nos están presionando para que lo resolvamos lo mas pronto posible" hasta que llega al último nivel:
- Se presentó una incidencia, la aplicación falló totalmente (la desmesura de las palabras y lo exagerado de la situación) mientras la usaba el sr. Fulanito, se han encendido varias alarmas porque es algo que no salió en ninguna prueba...
- Disculpa, fulano... una pregunta..... según veo aquí, la incidencia es porque las palabras que constituyen un hipervínculo.. el mouse no cambia de puntero a la manito típica ni se subraya...
- Eso es correcto, pela_patatas_01
- Vale.. Es que.. según el correo enviado por el subgerente_posición_51 cuando la definición de requerimientos, dijeron que no querían que los hipervínculos tuviesen el subrayado ni el cambio del mouse, ya que querían que fuese un texto lo mas compacto, ultraliviano y que nada destacase por encima del resto de las palabras.....

Sorpresa, sorpresa. Comienza entonces una serie de reuniones con usuarios, gerents, desarrolladores, el Papa Juan Pabl.. ahh, que ahora es Ratzinger. Bueno.. en fin. La negociación típica de plazos, de eso no estaba en los requisitos iniciales, que el cambio cuesta tanto, que eso es mucho dinero para algo tan minúsculo, que si, que si no.. que es para el gerente, que se aprueban los 200 mil $ presupuestados... y al final, son los pobres programadores luchando para ver donde rayos estaba el condenado 'a href' que fallaba, con un plazo de 2 días, y si no lo cumples, corre que te despido!!

En fin.. que la terminan pagando los curritos, mientras que el jefe superioris se sorprende que el gasto de su departamento de TI se gaste 200mil $ colocando un 'a href'.. ahh.. no.. en un "proyecto de actualización, mejora y upgrade de las capacidades gráficas de la aplicación"...

Ya decía yo, El peso ejerce un enorme poder al momento de transmitir algo.... sobre todo si es el jefe superior quejándose de algo a los "mortales" que tiene por debajo en el organigrama

El español como idioma de desarrollo

Apenas entraba a la universidad y recuerdo los cientos de errores que Borland C me daba cuando creaba variables "castellanas": 'año', 'adición', etc. Entendí entonces que en lo que respecta al código, el español no es un idioma.. 'bonito', sobre todo por el hecho de tener que interpretar caracteres 'extraños'. Recuerdo también un consejo que decía "los libros de tecnología en español son una utopía, porque cuando llegan a ver la luz, ya la aplicación a la que se refieren, es obsoleta o tiene varios parches encima". Por todo esto pues, siempre me he acostumbrado a las versiones "inglesas" de las cosas: Sistemas operativos, IDE's, Suites de oficina, documentación, etc.


Es que verdaderamente, eso de "ir a Definición", no me cuadra mucho (a pesar de que es muy literal y fácilmente deducible de "go to Definition"). Pero hay conceptos que verdaderamente escapan a mi mente, como el porqué una persona instala aplicaciones en inglés y luego aplica parches de idioma.. cuando va a programar en un lenguaje pseudo-inglés...


Algunas cosas inevitablemente deben ser en español (He conocido sitios donde por política, el nombre de tus métodos debe ser en inglés, y en otros sitios, en español -aunque sin acentos y sin ñ- o en portugués). Usualmente, una de ellas es la documentación / Comentarios de código. Sin embargo pues.... colocarlos en inglés tampoco está mal (sobre todo si se trabaja en equipos con varias locaciones internacionales). Y verdaderamente tiene su ventajas trabajar en inglés, sobre todo el hecho de no tener que descargar paquetes adicionales de idioma (uno para Office, otro para Sistema Operativo, otro para el Framework).. y empiezas a acumular megas y megas de "paquetes" para simplemente poder leer "Archivo" en vez de "file"...

Tiene sentido esto?

Sobre la ética profesional

YO siempre he tratado de ser comprensivo con las personas, sus motivaciones y su forma de hacer las cosas. Espero no haber juzgado a nadie, ni haberle ofendido durante mis cortos 28 años de vida. Sin embargo, hay varias cosas que he observado, que me han afectado directamente y que me gustaría compartir.. y están relacionadas con ese sitio donde pasamos 9 hrs al día (incluyendo el almuerzo) de lunes a viernes...
Recientemente cambié de empleo. Nada fuera de lo corriente en esto. Las motivaciones de siempre. Al salir de la que fue mi empresa durante dos años, me tocó entregar el portátil que tenía asignado. 1 hr antes de entregarlo, procuré eliminar mis archivos personales, dejar todos los archivos y código fuente en repositorio compartido, verificar (de forma doble) que no tuviese archivos "sueltos", que todos los Login/passwords estuviesen en una hoja al momento de entregar todo, para que mi reemplazo o el que sea, pueda acceder de forma "libre" e "inmediata" a lo que fueron mis cosas. Reconozco que durante 2 años he instalado ciertos programas que aunque no estaban en la lista, me ayudaban a desempeñar mis funciones: Firefox, programas para comparar versiones y un laargo etc.
Sin embargo, en el nuevo empleo me he conseguido con un portátil, fuera de lo "estándar". Perteneció a otra persona, y como "logicamente" hubiese hecho, eliminó muchos programas que en principio no debieron estar ahi: clientes P2P (como Ares y eMule), MP3 y videos. Aun así, empleé un par de días en limpiar la compu de reproductores multimedias (VLC, QuickTime, VideoRa etc), Programas de transferencia de datos con Celulares/Moviles.
Entiendo que muchas personas guarden con gran recelo el "secreto profesional". Tal vez porque no soy 100% Microsoft y mas bien soy un anarquista, nunca me ha gustado llevarme el código fuente conmigo. Aquí hay un punto interesante: los pro-Software libre dicen "el código es de todos, distribúyelo", mientras que los de Software privativo.. no. Sin embargo, como programador del lado "privativo" entiendo que el código no es de mi propiedad, sino que es propiedad del cliente o de la empresa para la que trabajo. Y como tal, debo dejar constancia de ello (notificar al jefe o al "heredero" la ubicación de los fuentes, etc). Inclusive, siempre he sido un fanático de dejar todo comentado, estructurado, con explicaciones cuando el código es medio confuso. Pero.. que carajo, eso es lo que YO hago, porque a lo largo de 7 años de trabajo, he tenido buenos compañeros y maestros que me han dejado esas enseñanzas... pero creo que a no todos nos enseñan igual....