blog counter
August 2008 - Artículos - SkunkWorks

August 2008 - Artículos

Guarde el secreto... sobre clientes, SharePoint y aceptación de código...

Hace un par de días Microsoft ha liberado una lista de chequeo para aceptación de código de SharePoint, y lo primero que he pensado es: hmmm... Microsoft le está entregando un garrote mas a clientes de esos pesados que todos conocemos, que no hacen más que discutir sobre cosas de las que no tienen ni idea apoyándose en información de la que no entienden ni jota...

El nombre en ingles del articulo es “Sample code acceptance checklist for IT organizations”, y lo puede encontrar en http://technet.microsoft.com/en-us/library/cc707802.aspx (on-line) o en http://go.microsoft.com/fwlink/?LinkId=125134&clcid=0x409 en formato Word. Un extracto en español lo puede encontrar en http://www.gavd.net/servers/sharepointv3/spsv3_item.aspx?top=0&itm=725. La lista esta divida en secciones (Seguridad, manejo de sesión, etc) y diciendo la verdad, me parece que hay algunos puntos interesantes para tener en cuenta, pero muchos caben simplemente en las “buenas prácticas” de cualquier software, no solamente de software para SharePoint, y algunas son simplemente o no realizables, o totalmente subjetivas.

Veamos, alguien sabe que es “IOSec”? estupendo que tantos levanten la mano... yo no tenía ni idea hasta que estuve googleando al respecto. IOSec es una librería para evitar vulnerabilidades de cross-site scripting (http://blogs.msdn.com/ace_team/archive/2006/03/13/550687.aspx ), que en realidad, me parece a mí, hace el mismo papel que la bien conocida clase SPEncode de WSS, es decir, codificar caracteres “peligrosos” como “<” y “>” en su equivalente de HTTP, de tal forma que no se puedan usar para inyectar scripts. Por supuesto, es una buena regla de conducta, pero supongo que es una de las primeras cosas que se aprenden a usar cuando estas programando para SharePoint... Lo mismo se puede decir de cosas tan obvias como no usar claves sin encriptar en el web.config o en cookies o en cualquier otro sitio que se pueda ver fácilmente.

Y ya que vamos por ese lado, usted que prefiere: ISO-8859-1 o UTF-8? Bueno, otra de las cosas con las que nos van a dar garrote cuando estemos entregando el famoso código. La lista recomienda usar ISO, pero lo chistoso es que todos los archivos de SharePoint, creados por Microsoft mismo, usan UTF-8. Y en cuanto a mí, si quiere quitarse los problemas de encima cuando está usando caracteres fuera la tabla ASCII extendida, no le queda más remedio que usar Unicode... a ver como se lo explicamos a nuestros clientes...

Y en cuanto a explicar, el tiempo que nos va a costar explicar porque código de validación está o no está en el lado del cliente... La lista recomienda: “Seguridad no se debe basar en validación en el lado del cliente. En lugar de esto, validación debe ser hecha al lado del servidor”. Esta es una de esas cosas que cada uno hace según su propio juicio, y que no siempre es explicable el porqué. Validaciones complicadas, en donde hay que validar contra diferentes fuentes es imposible de hacer al lado del cliente; en validaciones “comunes y corrientes”, como por ejemplo si la entrada es un numero o no, no tiene sentido hacer todo un viaje al servidor para ser realizadas, con un simple validador en el cliente es suficiente. De acuerdo, de acuerdo, ya sé que validaciones al lado del cliente pueden ser anuladas en el navegador mismo, pero atrapándo la excepción que se va a generar en el servidor es suficiente, pues sabemos (y nuestro cliente tiene que saberlo también) que para usar a SharePoint, el navegador tiene que tener el motor de Java activado... En cualquier caso, si quiere ser paranoico, valide en los dos lados, aunque yo diría mejor que hay que ser pragmático, confiar en el buen juicio del programador y rezar un par de padre nuestros a su dios favorito...

Regresando a la lista, hay algunas cosas que son incomprensibles; un buen ejemplo: “The design addresses potential canonicalization issues”. Fuera de que “canonicalization” es prácticamente impronunciable, la oración en realidad no dice nada más que “el diseño tiene que cumplir ciertas especificaciones”, sin especificar las especificaciones a especificar... otro de esos garrotes con los que nos pueden machacar la cabeza por delante o por detrás, pues no está especificado...

En cualquier caso, si le quedan cinco minutos libres, dele una leída a la lista, y, sobre todo, tenga en cuenta algunos de los puntos que menciona. Pero al final, todo este rollo es solamente para pedirles el favor de que guarden el secreto muy bien guardado y no le cuenten a nadie que esta lista existe, no sea que alguno de mis clientes se la lea, y se me ponga pesado cuando vaya a recibir el código del proyecto...

Gustavo - http://www.gavd.net/servers/
Escriba un Comentario que me haga reir...

Publicado por Gustavo Velez con 1 comment(s)
Archivado en:

El Manual de Campo de Sabotaje, SharePoint y SQL 2008

Andando por aquí y por allá en la red, mientras espero que SQL haga el upgrade de 2005 a 2008 (hasta ahora sin problemas) en uno de mis servidores de SharePoint, me he encontrado el “Manual de Campo de Sabotaje Simple”, preparado por los Servicios Estratégicos del ejército norteamericano durante la segunda guerra mundial (enero 17 de 1944), http://www.gutenberg.org/etext/26184. Fuera de ser gracioso para leer, y también muy útil si esta en el medio de una guerra y quiere hacer el mayor daño posible sin ser atrapado (“sature una esponja con solución de azúcar; comprímala en una bola, enróllela con una cuerda y déjela secar. Remueva la cuerda cuando este seca y tirela por un sanitario; la esponja se expenderá gradualmente y trancara la tubería de desagüe”), me ha hecho recordar una de las personas con las que tuve que trabajar en uno de mis últimos proyectos...

Probablemente la parte más interesante del Manual es la sección final: “Interferencia general con organizaciones y producción”. Aunque parezca raro, un saboteador no es el que pone bombas y ataca convoys de trenes, como nos lo han hecho creer los millones de películas de los últimos cien años. El saboteador de verdad trabaja en una oficina como burócrata sin nombre, y le tira constantemente arena a los engranajes de la maquina oficial. Veamos las instrucciones para hacer que las cosas salgan más mal de lo normal:

1. Insista en utilizar los canales oficiales todo el tiempo, no permita que se utilicen vías expeditas

2. Cree todo tipo de “Comités” para “estudiar y considerar la situación”, y haga que los comités sean lo más grande posibles, nunca menos de 5 personas (así no se ponen de acuerdo nunca)

3. Haga relevantes las cuestiones que sean irrelevantes lo más frecuentemente posible

4. Recatee sobre las palabras precisas a utilizar en comunicados, minutas y resoluciones

5. Refiérase a puntos decididos en reuniones anteriores e intente abrirlos para discutirlos de nuevo

6. Siempre recomiende “precaución” e intente que sus colegas se comporten “precavidamente”

7. Siempre exija que las ordenes sean dadas por escrito

8. “No entienda” el trabajo que se le asigne. Pregunte hasta el infinito y, preferiblemente, discuta por escrito al respecto

9. Retrase todo lo más posible. Aunque entienda perfectamente lo que hay que hacer, no lo haga hasta que no haya leído completamente todos los manuales, correspondencia, etc

10. No ordene nuevo material hasta que el antiguo no esté prácticamente terminado y siempre pida material que es difícil de encontrar

11. Cuando asigne tareas a colegas, asigne el trabajo sin importancia primero. Asigne el trabajo sin importancia a sus colegas más capaces y el más importante a los menos capaces

12. Insista en obtener trabajo perfecto en cosas irrelevantes y no sea exigente con cosas relevantes

13. Para bajar la moral, sea complaciente con colegas ineficientes y promuévalos frecuentemente. Discrimine trabajadores eficientes y quéjese habitualmente de su trabajo

Bueno, la lista sigue y sigue, pero me parece que todos reconocemos a alguien en nuestro entorno que satisface por lo menos una de estas recomendaciones...

Y volviendo al proyecto que les contaba al principio, el encargado de manejar el proyecto por la parte de mi cliente era (es) todo un experto saboteador... probablemente se había leído el manual de marras antes de que yo lo hubiera encontrado. Para decidir hasta la más pequeña modificación era necesario organizar una reunión con la mayor cantidad posible de participantes, en la que con toda seguridad se revisarían puntos resueltos con mucha anterioridad (puntos 1, 2 y 5). Era prácticamente imposible hacer las cosas de una manera más eficiente (crear un Job de SharePoint para importar elementos desde un sistema de archivos) pues se debería trabajar con cautela (punto 6). Todo lo que se decidía había que ponerlo por escrito y enviar dos docenas de emails a veinte personas diferentes, de los cuales regresaban 19 pidiendo mayores explicaciones (puntos 7, 8 y 9). Los servidores para producción los pidió una semana antes de la fecha límite para poner todo on-line, y exigía que tuvieran discos duros de 15.000 rpm (punto 10). Junto con un colega estuvimos ocupados literalmente días y días corriendo tablas un pixel hacia la izquierda y cambiando el color de letras a “un gris menos oscuro” (puntos 11 y 12)...

Bueno, mi servidor ha terminado de hacer la migración de SQL a 2008 sin problemas. Inclusive SharePoint está funcionando como si no se le hubiera cambiado la Base de Datos... estupendo. El upgrade me ha aumentado el espacio utilizado en el disco duro en 600 MB... aceptable. A veces Microsoft hace las cosas bien... aunque a veces tenga la extraña idea de que el Manual de Campo de Sabotaje es lectura obligatoria para todos los empleados de Microsoft... probablemente me equivoco...

Gustavo - http://www.gavd.net/servers/
Escriba un Comentario que me haga reir...

Publicado por Gustavo Velez con 6 comment(s)
Archivado en:

Alguien me puede explicar porque... (SharePoint y demás)

1 - Windows 2008 - Internet Explorer 7 - WSS y/o MOSS:

Porque la animación no funciona?

2 - Windows 2008 - Administrador de tareas de Windows:

Porque se me perdieron las pestañas de “Aplicaciones”, “Procesos” y “Servicios”?

3 - Windows 2008 - runas.exe. El programa (que ha existido en Windows desde el tiempo de los dinosaurios) todavía se puede encontrar en el directorio C:\Windows\System32.

Porque cuando se intenta utilizar produce este mensaje?

4 - Instalar SQL 2008 en un Windows 2008 que contiene Visual Studio 2008

Porque aparece ese mensaje (y no se puede instalar), siendo que el SP1 para Visual Studio 2008 todavía no existe? (Solamente en Beta, inapropiado para trabajar con sistemas de producción [2008-08-09]).

5 - Porque el “Internet Explorer Developer Toolbar” no funciona en Windows 2008 con IE 7?

6 - Algo que he encontrado, para no ser totalmente negativista: Cuando se crean bastantes usuarios en Windows 2008, todos aparecen en la pantalla de Logon. Para evitarlo, puede iniciar el programa de “Directiva de seguridad local” desde las Heramientas administrativas de Windows, y en “Configuración de seguridad” - “Directivas locales” - “Opciones de seguridad” habilite las opciones “Inicio de sesión interactivo: no mostrar el ultimo nombre de usuario” e “Inicio de sesión interactivo: no requerir Ctrl+Alt+Supr”, lo que produce en el Logon:

Gustavo - http://www.gavd.net/servers/
Escriba un Comentario que me haga reir...

Publicado por Gustavo Velez con no comments
Archivado en:

Hay cosas inútiles, cosas totalmente inútiles y Métricas de Código (sobre todo para desarrollo con SharePoint)

Todos tenemos de esas cosas que nos enervan... cuando empieza a llover (y nos mojamos) en un día de sol... la fila en el supermercado que avanza más rápido que en la que estas... despertarse y no poderse volver a dormir... Métricas de Código... cosas de esas que te irritan sin saber por que...

En estos días, por eso de que hay que estar al tanto de lo que pasa en el mundo, he estado dándole una revisada a las últimas herramientas para Visual Studio, sobre todo las últimas versiones de CodeRush y Resharper. Con herramientas para Visual Studio siempre he tenido una relación de amor-odio: me encantan por lo que pueden hacer y las odio porque son tan lentas y porque se comen tanta memoria y tiempo de CPU, que me rompen la “dinámica” cuando estoy escribiendo código... con toda seguridad me entienden... si estas inspirado y por fin te están saliendo las líneas de código a borbotones, lo menos que quieres es que una herramienta estúpida se demore media hora en mostrar la lista de Intellisense en una variable...

En fin, luego de usar un par de días Resharper 4.0, termine sacándolo del sistema por eso mismo... los 5.835 (o que se yo cuantos) shortcuts que utilizaba la version anterior son ahora 10 veces más, y la velocidad de operación es 2 veces menor... fuera de mi sistema... luego instale CodeRush 3.0.8; la verdad, este va evolucionando mas por el camino que yo desearía: menos funcionalidad que nunca se usa, y menos carga para el sistema. Aunque sigue poniendo problemas de vez en cuando, sobre todo por lo de las graficas que utiliza (CodeRush era anteriormente conocido como CodeCrash, según me comentaba alguna vez Hadi Hariri), es bastante más rápido para utilizar que Resharper, y la verdad sea dicha, la parte grafica es realmente encantadora (cuando funciona).

Pero se trata de Métricas de Código. Pues bien, CodeRush ofrece la posibilidad de mostrar al lado de cada método o clase que crees un número indicando la cantidad de renglones del método, su Complejidad Ciclomática o su Complejidad de Mantenimiento. Estos dos últimos son Métricas de Código que pretenden indicar que tan difícil de entender es un pedazo de código (“Cyclomatic Complexity en SharePoint” http://geeks.ms/blogs/gvelez/archive/2007/09/02/cyclomatic-complexity-en-sharepoint.aspx ) o que tan difícil será para darle mantenimiento. La forma para calcular la Complejidad de Mantenimiento es tan complejo que es prácticamente imposible de darle mantenimiento, pero si lo desea saber en detalle, en el articulo “Here’s your new metric” (http://www.doitwith.net/PermaLink.aspx?guid=39a0e537-5d0e-4f9b-ac5c-51e8b3d1d4ec) encontrará todo lo que desee saber al respecto. En resumidas cuentas, un número mayor de 1001 es “Ultra-complejo, extremadamente difícil de mantener, alta prioridad para simplificar”.

Pues bien, da la casualidad de que yo trabajo con SharePoint, en donde si quiero hacer una WebPart tengo que usar un override de un método que se llama “CreateChildControls”, en donde tengo que crear todas las instancias de los controles que quiero usar y asignarles sus propiedades básicas. En la WebPart que estaba construyendo, tengo 38 controles creados, lo que me produce un Maintenance Complexity de 1154, una enorme raya roja a lo largo de toda la rutina y un enorme insulto del compilador cuando genero el ensamblado... pero que quieren que haga? Partir el CreateChildControls en 38 rutinas pequeñitas y llamarlas desde el metodo una por una? Eso es mas inmantenible que el código actual... y entre otras cosas, los 38 controles usan cada uno código muy sencillo, que no tiene ningún problema de mantenimiento por si mismo... Métricas de Código son estúpidas... CodeRush fuera de mi sistema...

Sigamos... Visual Studio 2008 Team System viene con Métricas de Código: excelente. Podemos ver Profundidad de Herencia, Acoplamiento de Clases, Complejidad Ciclomática e Índex de Mantenibilidad. Por supuesto que este último es diferente al de CodeRush, y, si lo desea saber, es calculado según la fórmula:

Maintenability Index = 171 - 5.2 * log2 (Halstead Volumen) - 0.23 * (Cyclomatic Complexity) - 16.2 * log2 (Lines of Code)

Queda claro? Perfecto... Como se habrá podido dar cuenta, 171, 5.2, 0.23 y 16.2 son factores calculados científicamente por la Carnegie Mellon University (no, en serio, no es para reírse, léalo usted mismo en http://blogs.msdn.com/fxcop/archive/2007/11/20/maintainability-index-range-and-meaning.aspx si no me cree) de tal forma que te salga un numero entre 100 (muy bien) y 0 (requetemal). Yo diría que lo hicieron al revés, un indexe de mantenibilidad de cero me dice que hay que darle cero mantenibilidad, pero quién soy yo para contradecir a la Carnegie Mellon University...

Pues bien, al intentar usar las Metricas de Visual Studio 2008, sale inmediatamente un error “An error ocurred while calculating code metrics for target file bla-bla-bla...”. Googleando por aquí y por allá, parece que es un bug del tamaño de una vaca, que posiblemente será corregido en el Service Pack 1 de VS, y que para evitarlo hay que meter referencias a los NameSpaces mencionados en el error (http://neovolve.com/archive/2007/12/21/bug-found-in-calculating-code-metrics-in-vs2008.aspx). Luego de hacerlo de esa forma, es posible hacer funcionar la cosa, y que resulta? Que mi método CreateChildControls tiene un Maintenability Index de 25... Bastante malo... Métricas de Código a la basura... O soy yo el que está metiendo las patas por algún lado?... lo único que puedo decir es que digan lo que digan las Métricas, mi código funciona bastante bien, y hasta ahora solamente un par de programadores incapaces e ineptos se han atrevido a quejarse de que no es mantenible...

Gustavo - http://www.gavd.net/servers/
Escriba un Comentario que me haga reir...

Publicado por Gustavo Velez con 7 comment(s)
Archivado en: