¿Cuanto ocupan mis tablas y mis vistas indexadas en Sql Server?

A menudo es importante conocer que tablas o vistas indexadas ocupan un mayor espacio en nuestras bases de datos. Es importante sabe que las vistas indexadas ocupan espacio, ya que mantienen una copia de los datos, por lo tanto tambien incrementan el numero de escrituras a discos cuando se realizan inserciones.

Por ejemplo, la información devuelta por este script es muy util para detectar situaciones de 'fugas de datos', en las que tablas que se limpian periodicamente o en respuesta a un evento, dejan de hacerlo y en consecuencia nuestra base de datos crece desmesuradamente. Para una de estas situaciones escribí el script que se encuentra abajo.

Tambien puede ser muy útil en otras situaciones, como por ejemplo detectar las tablas que más ocupan para optimizar su almacenamiento, o para detectar las tablas con más filas, para pensar en su particionado.

–Cursor que contiene todos los objetos que ocupan espacio

DECLARE objects_cursor CURSOR LOCAL FAST_FORWARD READ_ONLY FOR

      SELECT name FROM

            sysobjects o

      WHERE

            o.xtype = 'S' or –Tablas de sistema

            o.xtype = 'U' or –Tablas de usuario

            o.xtype = 'V' –Vistas (solo las indexadas devuelven tamaño)

–Tabla temporal para albergar los resultados

CREATE TABLE #results

      (name SYSNAME, rows CHAR(11),

      reserved VARCHAR(18), data VARCHAR(18),

      index_size VARCHAR(18),Unused VARCHAR(18))

–Recorremos el cursor obteniendo la información de espacio ocupado

DECLARE @object_name AS SYSNAME

OPEN objects_cursor

FETCH NEXT FROM objects_cursor

INTO @object_name;

WHILE @@FETCH_STATUS = 0

BEGIN

      INSERT INTO #results

            EXEC sp_spaceused @object_name

   

      FETCH NEXT FROM objects_cursor

            INTO @object_name;    

END;

CLOSE objects_cursor;

DEALLOCATE objects_cursor;

— Quitamos "KB" para poder ordenar

UPDATE

  #results

SET

  reserved = LEFT(reserved,LEN(reserved)-3),
  data = LEFT(data,LEN(data)-3)
,
 
index_size = LEFT(index_size,LEN(index_size)-3)
,

  Unused = LEFT(Unused,LEN(Unused)-3)

–Ordenamos la información por el tamaño ocupado

SELECT

  Name,

  reserved AS [Tamaño en Disco (KB)],

  data AS [Datos (KB)],

  index_size AS [Indices (KB)],

  Unused AS [No usado (KB)],

  Rows AS Filas FROM #results

ORDER BY

  CONVERT(bigint, reserved) DESC

–Eliminar la tabla temporal

DROP TABLE #results

Reseñar que el script anterior solo funciona en SQL Server 2000, para que funcione en SQL Server 2005, tenemos que modificar la declaración del cursor. Esto es debido a que en SQL Server, el procedimiento almacenado sp_spaceused espera el nombre de los objetos calificados con el nombre del esquema al que pertnenecen. Además los tipos de objetos que devuelven en SQL Server información sobre su tamaño son más. En SQL Server 2005 debemos hacer la declaración del cursor como sigue:

DECLARE objects_cursor CURSOR LOCAL FAST_FORWARD READ_ONLY for

      SELECT s.name + '.' + o.name from sys.schemas s

      INNER JOIN sys.objects o

      ON o.schema_id = s.schema_id

      WHERE

            o.type = 'S' or –Tablas de sistema

            o.type = 'U' or –Tablas de usuario

            o.type = 'V' or –Vistas (solo las indexadas devuelven tamaño)

            o.type = 'SQ' or –Cola de servicio

            o.type = 'IT' — Tablas internas usadas p.e. por el Service Broker o los indices XML

Project Server Visual Studio Team System Connector

Uno de los grandes huecos que tiene la gestión de tareas en Team System es la dificultad de consolidar las tareas de desarrollo en una vista común con el resto de proyectos llevados a cabo en la empresa y con las tareas que no son propias del desarrollo. En los proyectos pequeños y medianos esto no es un gran problema puesto que la gran parte de tareas están relacionadas con el desarrollo 'puro y duro', pero, en los grandes proyectos tenemos una importante carga de trabajo no estrictamente relacionada con el desarrollo. Además las tareas de desarrollo tienen que ser cortas y binarias para facilitar su gestión y una pronta detección de los problemas que se produzcan. La información de estas tareas tan cortas debe ser agregada para facilitar una visión de más alto nivel del progreso del proyecto o incluso para obtener información agregada de toda la empresa y manejar 'portfolios' de proyectos.

Hasta ahora careciamos de una herramienta que nos permitiese cubrir las necesidades que he expuesto anteriormente. Team System nos facilita la labor de la gestión de las tareas de desarrollo, la monitorización del progreso de las iteraciones, e incluso nos permite exportar estas tareas a Project. Pero para proyectos más grandes o complejos se hace necesario utilizar soluciones del estilo de Enterprise Project Management (EPM) Microsoft Office Project Server 2003. Para cerrar el hueco existente ha nacido Project Server Visual Studio Team System Connector, que además de util es gratuito.

Este conector sincroniza información sobre el proyecto, los recursos, y las tareas entre Team System y Project Server. Los gestores de la empresa pueden seguir los proyectos en su EPM  mientras, los desarrolladores utilizan el entorno de desarrollo, Visual Studio Team System. De esta manera los gestores optienen la vista de alto nivel que les pemite guiar la empresa y los desarrolladores pueden de manera natural, realizar el seguimiento fino necesario para que los proyecto de desarrollo lleguen a buen puerto, utilizando los informes de Team Foundation Server (en la imagen adjunta se puede ver el gráfico de trabajo restante).

Code Camp: Exito de crítica y publico una vez más

Estoy en el aeropuerto de Barajas, volviendo de una nueva edición del Code Camp, medio muerto de cansancio pero feliz (sarna con gusto no pica), de haber consumido un fin de semana con la 'fauna' que se ha dado cita en este extraordinario evento, que auna tecnología y diversión a partes iguales. Una edición más la tecnología la puso Microsoft y la diversión Chema Alonso y Ricardo Varela (en la foto adjunta) en las sesiones y Miguel Jimenez, que además de sus robots que fueron la sensación, organizo un 'fiestón' con su hermano en los platos que fue muy divertido… hasta que llego la mañana siguiente y las consecuencias de la charla y el whisky se hicieron patentes ;). Desde aquí propongo a Miguel como MVP LEF (Lúdico Erótico Festivo). Unai Zorrilla tambien contribuyo al ambiente festivo con su queimada, que esperemos aleje la meigas y los bugs.

Me voy con la sensación de que hay un motón de universitarios con devoción por la tecnología que van a poner a este pais en el lugar que merece en los rankings tecnológicos. El interés de estos 'chavales' hace mucho más que las subvenciones a I+D que se comen (si literamente, se comen ) las empresas. Señores politicos si quieren que España prospore en lo tecnológico, dejen de engrasar a empresas obsoletas y empiezen a apoyar a la juventud interesada en la tecnología. Que hace muchas más cosas que ir de botellón. Se lo puedo asegurar, lo he visto con mis ojos durante todo un fin de semana, en iniciativas como grupos de universidad, revistas, iniciativas empresariales etc… Algo pasa en la universidad cuando son los estudiantes los que tienen que ser el motor de las iniciativas nuevas (aunque se que muchos tienen el apoyo de sus profesores y que algunos de estos hacen un excelente trabajo, por lo que los chavales cuentan, son la excepción). Comentaban algunos que reciben más apoyo de empresas privadas como Microsoft, Plain Concepts, Solid o Ilitia, que ponian los ponentes y que participan en sus iniciativas en la medida que pueden, que de sus profesores.

Voy a hacer un somero repaso de la agenda, más que nada para que los que se han pensado si venir o no y finalmente no han venido, sepan que se han perdido.

Habría el sabado el Code Camp, Miguel Jimenez, hablando de Robotics Studio y mostrandonos su propios robots. Sin duda una de las grandes sensaciones del Code Camp. Y es que la informática puede ser muy divertida.

Continuaba Fernando Guerrero, contandonos como esta en nuestra mano 'pilotar' nuestra carrera profesional. Excelente charla de Fernando, nada técnica, pero de gran interés en la que nos contaba como es responsabilidad nuestra y de nadie más el gestionar nuestra carrera profesional.

Luego para volver a la arena técnica, nos hablaban, siento no recorcar quien, sobre reconocimiento de voz, y es que los tiempos avanzan una barbaridad… cualquier PC corriente, es capaz de entendernos… eso si con alguna dificultad si tenemos catarro!!!!

La tarde del sabado comenzaba con el gran Pablo Pelaez contando 10 maneras de llevar tu empresa a pique. Y os puedo asegurar de que tiene cierto curriculum es este tema… pero a la vista de su divertida y util charla parece que ya ha aprendido la lección. Así lo espero por lo que me toca :P.

Luego Paco y Miguel Ejea nos contaban las virtudes de la mineria de datos. Interesante ver lo que se puede aprender a partir de los datos y ver como alguien se monta en poco tiempo, en directo, con datos reales la solución necesaria para realizar este proceso.

La última charla, como siempre extraodinariamente divertida, la daban el 'egregio miembro de la comunidad, avispado empresario y docto concedor de los oscuros secretos de la seguridad' Chema Alonso y Ricardo Varela, 'el en su juventud declarado como mejor programador de europa, miembro distinguido del IEEE y uno de los primeros, sino el primer español que traspaso la puertas de los mayores gigantes informáticos del mundo'…. jejejejej… lod que vieron su charla sobre Web 2.0 entenderán de que va esto. Para el resto decir que contarón de manera amena las oportunidades y peligros que se abren ante nosotros con al Web 2.0.

El sabado Unai Zorrilla y Alejando Mezcua, se 'curraban' una secretaria virtual, que corria en una PDA capaz de responder por nosotros de manera automática a las llamadas perdidas, pero sin otra funciones que se suelen atribuir (que mala es la gente) a las secretarias… no se me ofenda ninguna que la broma es de los ponentes y no mia, y no lleva maldaz ¿eh?.

Sin más, comentar que no queda otra que dar las gracias a la gente de Microsoft por organizar un evento que nos premite a profesionales y universitarios estar en contacto, contar nuestras inquietudes, aprender y crear lazos de colaboración. Por que lo realmente importante del Code Camp pasa entre las sesiones, no durante ellas. Y no lo digo por la fiesta de Miguel y la queimada de Unia!!! sino por la excelente oportunidad de hablar con un motón de gente que esta haciendo cosas interesantes y a la que une una misma pasión.

Check out en Team System

Este post esta básado y contiene textos e imagenes directamente tomados del artículo Check Out in Team System de Martin Woodward, publicado bajo licencia Creative Commons. Todos los textos en cursiva han sido 'directamente' traducidos del artículo anteriormente citado las partes que no están en cursiva son de mi cosecha. Una vez aclarado esto, vayamos al grano…

Cada vez más gente me está preguntando ¿por qué TFS cuando hace check out, no obtiene la última versión?.

El problema es que la terminología empleada varia dependiendo de cual sea el gestor de fuentes del que vienes. En Visual Source Safe o PVCS, Check Out significa "dame la ultima versión del archivo y bloqueale para que ningún otro pueda editarlo". En CVS y Subversion, Check Out significa "dame la última versión". Si estas usando las caracteristicas de control de código fuente de Team System, entonces, Check Out significa "dile al servidor que yo quiero editar este archivo y marca el archivo como escribible en mi sistema de archivos", al mismo tiempo que tu haces Check Out del archivo tambien tiene la opción de bloquerlo usando uno de tres tipos de bloque existente (none, Check Out o Check In).

Team System tiene el concepto de Workspaces. El servidor conoces tu Workspace, conoce que directorios locales has mapeado en que Workspace, que versiones de los archivos tienes en este Workspace y de que cambios pendientes has informado al servidor. Para obtener la última versión de un archivo, debes llamar explicitamente al comando Get Latest para descargar los archivos.  Si alguien crea una nueva versión de un archivo, no lo verás en tu sistema local de archivos hasta que vuelvas ha ejecutar Get Latest otra vez. Y no esto no se puede cambiar, ni siquiera usando Check Outs exclusivos.

Diagram showing get latest operations from a server

Cuando hace Check Out de un archivo, lo que realmente estás diciendo es "Servidor, estoy a punto de editar la versión 3 del archivo"

Diagram showing pend edit command

Finalmente, cuando haces Check In del archivo, coges el archivo desde tu Workspace local y le pasas hasta el servidor. Este archivo ahora se convierte en la última versión.

Diagram showing check-in operation

Ahora, imagina que no has optenido la última versión antes de hacer el Check Out. Cuando haces el Check In, el servidor sabe que los cambios fueron hechos en la versión 1 del archivo, por eso te avisa de que es un cambio conflictivo y te pide que resuelvas estos conflictos antes de hacer Check In en este archivo.

Diagram showing conflict

Why does it not just get the latest version when you do a check-out the file? The problem with that is that if it were to get the latest version then that might introduce new dependencies on files that you have not got yet. Team System plays safe and only gets the file when you tell it to.

¿Por qué no simplemente obtener la última versión cuando tu hace Check Out de un archivo? El problema con este enfoque es que si obtuviesemos la última versión podríamos intruducir nuevas dependencias repecto a archivos que aun no tenemos. Team System opta por el enfoque más seguro y optiene el archivo solo cuando se lo pedimos.

Hasta aqúi las partes relevantes de como funciona el tema. Pero yo voy a ir un paso más allá que el amigo Martin Woodward, explicando que significa eso de "introducir nuevas dependendias". El problema es que cuando hacer Check Out implica obtener la última versión, nosotros perdemos el control de que es lo que realmente obtenemos. Se puede dar el caso de que simplemente para hacer una edición menor en un archivo, por ejemplo para hacer un Workarraound temporal para poder continuar con una pequeña tarea, no tengamos que bajar infinidad de ficheros solo para poder compilar. Si el archivo del que hacemos obtenemos la última versión cambio mucho, y por ejemplo, llama a nuevas partes del código que a nosotros no nos interesan, el obligar la obtencion de la última versión no obliga a bajar un motón de código que no es relevante para nuestra tarea actual.

La manera de trabajar en Team System tambien soporta algunas técnicas avanzadas de gestión de código que son dificiles de llevar a cabo con otros gestores de fuentes, como por ejemplo Golden Lines o Quality Gates, en las que puede que tu no tengas permiso para integrar código, que las integraciones de nuevo código solo se hagan en un determinado momento fijado en el tiempo o que el desarrolador ni siquiera sea quien puede integrar ese código, sino que hay un equipo exclusivamente encargado de la integración. Resumiendo hay patrones de gestión de código fuente que son dificiles o imposibles de llevar a cabo si se realiza la obtención de la última versión en el momento de realizar el Check Out.

En VSS y otros gestores que implementan el enfoque de obtener última versión al hacer Check Out, esto se solucionaba, quitando 'a manopla' el atributo de solo lectura al proyecto, lo que de todos modos te llevaba a tener que corregir una incosistencia.

Eso si, he de reconocer que este escenario no es habitual, y que no acaba de convencerme al 100% el enfoque que han elegido en Team System, sobre todo por una cuestión: se separa de el enfoque al que estamos acostumbrados. Seria simple haber puesto una opción que permitiese variar el comportamiento. Parece que esta posibilidad la introduciran en proximas revisiones/versiones de Team System, puesto que de hecho el Visual Studio 2005 Team Foundation Server MSSCCI Provider (que se usa para acceder al gestor de fuentes de TFS desde Visual Studio 2003, PowerBuilder, VB 6.0 etc…) ya soporta "GetLatest on Checkout support".

De todos modos existen algunos 'workarrounds' que nos pueden ayudar. Por ejemplo podemos añadir una macro de Visual Studio para que cuando abramos un fichero que es de solo lectura (y por tanto, es probable que este en el gestor de fuentes) se obtenga su última versión. Para ello solo tenemos que hacer Alt + F11 en visual estudio, y añadir en el archivo EnviromentEvents, dentro del modulo EnviromentEvents el siguiente código:

Public Sub DocumentEvents_DocumentOpening(ByVal DocumentPath As String ByVal Read_Only As Boolean) Handles DocumentEvents.DocumentOpening

 

        Dim attr As IO.FileAttributes

 

        attr = IO.File.GetAttributes(DocumentPath)

 

        If (attr.ReadOnly) Then

            DTE.ExecuteCommand("File.TfsGetLatestVersion")

        End If

 

End Sub

Otra opción es hacer una macro similar que podemos asociar a un menu o a un botón que, nos permita de manera simultanea optener la última versión y hacer Check Out:

Sub CheckoutLatest()

        DTE.ExecuteCommand("File.TfsGetLatestVersion")

        DTE.ExecuteCommand("File.TfsCheckOut")

End Sub

Mas sobre pizarras…

Hablaba hace un tiempo en este mismo blog sobre la importancia de las pizarras para facilitar la comunicación y el proceso creativo en los proyectos de software. Comentando esto en un curso sobre Gestión de Proyectos de Software que he estado impartiendo recientemente, uno de los alumnos me pasaba una foto que muestra una pizarra. Simplemente viendo esta imagen nos podemos hacer idea del proceso creativo, de la transmisión de conocimiento que se a realizado alrededor de esta pizarra. ¿Hubiese sido posible sin una pizarra? Apuesto a que no…

Curioso tambien este video sobre una pizarra en la que esta trabajando el MIT.

¿Un gestor de fuentes para mi solo?

Ningún proyecto debe llevarse a cabo sin un gestor de fuentes. Sin duda en proyecto en el que haya dos desarrolladores un gestor de fuentes es una herramienta imprescindible para facilitar el trabajo y reducir riesgos. A fuerza de ser pesados estamos consiguiendo que esto sea así. Cada vez se ven menos proyectos en los que no se utiliza un gestor de código fuente.

Cuando el proyecto solo involucra a un desarrollador, el tema es más dificil de 'vender', las ventajas son obvias, anda que mi querido y odiado Source Safa no me salvo el culo millones de veces en mi epoca de freelance. Pero es cierto que un gestor de fuentes, para un solo desarrollador puede ser un poco engorro. Los chicos de Visual Studio, han pensado en eso y nos permiten seleccionar, con solo utilizar un combo, una configuración que permite que si solo hay un desarrollador el uso del gestor de fuentes sea totalmente transparente. Instalar Source Safe es un proceso que lleva 15 minitos y con estas opciones ni nos enteramos de que está, Visual Studio se encarga de todo de manera transparente, asi que ya no hay escusa. Todos a usar gestor de fuentes, aunque seamos uno.

Desde esta misma pantalla tambien podemos definir a nuestro gusto como se comporta Visual Studio 2005 en relación a nuestro gestor de fuentes, sea este Source Safe o Team Foundation Server.

Pon un tester en tus proyectos

A menudo recibo la pregunta: ¿Qué puedo hacer para mejorar la calidad del software que desarrollamos? Y mi respuesta siempre es la misma: Pon un tester en tu proyecto.

Pero la reacción a mi respuesta es siempre reticente. Las cuestiones que se plantean suelen ser del estilo:

¿Cómo se los voy a justificar a mis superiores? o ¿Cómo voy a poner alguien solo a probar, con todo lo que tenemos que desarrollar?
No existen tester en el mercado.
Los desarrolladores ya prueban.
Las pruebas las hace el usuario.

…y algunas variantes de las anteriores.

Iré abordando estas cuestiones a lo largo de este post, aprovechándolas como una perfecta excusa para hablar sobre algunas de las ideas erróneas que se tienen sobre la calidad en el software. De todos modos antes de seguir leyendo te recomiendo que leas un post anterior: En el software, la calidad, no es opcional.

Primero de todo voy a dar varios motivos por los que la figura de un tester es valiosa para un proyecto:

Es muy útil contar con alguien cuyo trabajo sea única y exclusivamente vigilar la calidad del software para asegurar que la calidad se ve como una autentica prioridad. Se nos puede llenar la boca de lo importante que es la calidad del software para nosotros y nuestra empresa, podemos llenar el pasillo de carteles tipo "la calidad nuestra razón de ser", pero nada deja más claro la importancia que le damos a la calidad que poner un tester en nuestro proyecto. Todo el equipo de desarrolla sabrá a ciencia cierta que alguien va a estar vigilante sobre la calidad del software que se desarrolla, y por tanto será mucho más cuidadoso. A nadie le gusta que le saquen los colores

Un tester impulsa el desarrollo, por que ayuda a que los errores se descubran rápido y por lo tanto con mucho menor impacto sobre las tareas cotidianas del equipo de desarrollo. Además, el tester mantiene la infraestructura necesaria para probar el sistema, de manera que siempre contamos con un entorno de pruebas en buen estado. Otro factor por el que un tester impulsa el desarrollo es porque tiene que tener algo que testear, lo que 'obliga' al equipo de desarrollo a mantener cierta velocidad en el desarrollo para 'alimentar' al tester.

Un tester impulsa el uso de buenas prácticas porque para que alguien pueda probar nuestro software este tiene que ser construido a menudo, lo que obliga a tener algún sistema de construcción automática. Otra buena práctica relacionada con que haya un teste en nuestro equipo de desarrollo es la necesidad de actuar pronto sobre los bugs. Ningún tester soporta encontrarse con el mismo bug más de dos veces. Además si tenemos un tester en nuestro proyecto, con total seguridad tendremos un sistema de bug tracking, o el se asegurará de ponerlo en marcha, por su salud mental. Otro efecto beneficioso, es que si tienes un tester en tu equipo, no caerás en el error habitual de dejar la calidad para el final.

Bueno ahora que ya os he convencido de que necesitáis un tester en vuestro proyecto voy a entrar en las reticencias para no tenerlo que comentaba al principio:

¿Cómo se los voy a justificar a mis superiores?: No lo hagas, no lo necesitas, no tienes porque explicar que necesitas un tester, si tu equipo aun no lo tiene muy probablemente tus superiores no entienden esa necesidad. Si tu equipo de desarrollo se componen de n desarrolladores, convierte a uno o varios en testers. Si estas formando un nuevo equipo, aun es más fácil, pon n-m desarrolladores y contrata m testers (m no puede ser cero!!!). Ahora pensarás, si tengo menos desarrolladores, voy a correr menos!!!. Pero esto es falso, la manera más rápida de desarrollar software es hacerlo con calidad. El proceso de desarrollar un proyecto de software es algo iterativo, construyes software sobre software existente, iteración sobre iteración, si no logras tener una base de código estable, es muy difícil que la siguiente iteración añada código de calidad. En una frase, sobre cimientos de basura solo se sostiene más basura.

No existen tester en el mercado: Falso, lo que no existe es demanda de testers desgraciadamente, pero hay mucha gente dispuesta e interesada en trabajar mejorando la calidad del software que otros prueban. Es un trabajo interesante, en el que se usan herramientas avanzadas y que para ser realmente efectivo exige escribir código, automatizar pruebas, crear scripts de limpieza de la red pruebas, utilizar herramientas avanzadas de pruebas como Team System Tester Edition. El problema es que debido a la ignorancia de la importancia de esta figura esta devaluada. Probar en este país, es un trabajo de becarios, que dada su inexperiencia no obtienen grandes resultados, lo que se traduce en que los testers no esten valorados. En Microsoft por ejemplo, solo programadores senior pueden testear el trabajo de otros, el que más sabe es el encargado de asegurar que otros hacen un trabajo correcto, ¿podría ser de otro modo?. Adeás incluso hay certificaciones para testers.

Los desarrolladores ya prueban: Falso, los desarrolladores están entrenados y se centran en que las cosas funcionen, no en tratar de romper las cosas. Un programador puede desarrollar un pantalla de login y nunca hacer login usando el ratón, solo el teclado, miles de veces. Un tester entrenado y metódico probará la pantalla de login con el afán claro de romperla, detectando que no se puede hacer login usando el ratón al poco rato. Otro enfoque que a menudo veo es que los analistas sean los que prueban, pero no estén entrenados para ello. Es más a menudo no tienen el tiempo para ello, y son 'analistas' algo mucho más reconocido que ser tester, no quieren dedicar su tiempo a probar, sino a analizar. Además los analistas cuenta con una visión propia del sistema, no en vano ellos son los autores del análisis, pero nada asegura que esta visión sea la correcta. La consecuencia es que la calidad de tu software caerá. Otro factor a tener en cuenta es que el software cada vez es más complejo, y las pruebas que necesita tambien, e incluso las herramientas que existen para realizar esas pruebas (hechadle un vistazo a VSTS for Testers Edition) por lo tanto es imprescindible un alto grado de especialización.

Las pruebas las hace el usuario: Sin duda a parte de los problemas que se derivan para tu imagen como empresa o tu imagen como profesional, el problema más grave es otro. Cuanto más tarde te enteras de un error, más te cuesta en términos económicos. Si los errores te los cuenta el usuario, te estas enterando lo más tarde posible y por tanto lo vas a pagar caro. Ver el gráfico adjunto.

Este post va dedicado a Hector, de Panda Software, el tester con más dedicación y entusiasmo con el que he tenido el placer de trabajar. Sin su excelente labor, 'parir' AdminSecure hubiese sido mucho más doloroso.

La declaración de interdependencia

Cualquiera que en conozca algo sobre metodologías ágiles de desarrollo conoce el manifiesto ágil, pero mucha menos gente conoce la declaración de interdependencia. Este segundo manifiesto, firmado por muchos de los autores del manifiesto ágil, es mucho más legible para los jefes de proyecto y gestores formados en las metodologías basadas en el control y la aversión al cambio. Además hace especial incapíe en la dependencia que existe entre los diferentes implicados en un proyecto (desarrolladores, clientes y stakeholders).


La declaración de interdependencia proporciona una serie de valores modernos, relacionados y a mi modo de ver imprescindibles para que un proyecto de desarrollo de software triunfe. En cualquier caso me ha parecido muy interesante y por eso he decidido traducir sus principios. Ya he hablado anteriormente en este blog sobre como ayuda, en mi opinión, contar con principios que guien tu trabajo como desarrollador.


Los principios de esta declaración, que todo equipo de desarollo ágil debería asumir sin problemas, son:


«Nosotros…



Incrementamos el retorno de la inversión enfocándonos en lograr un contínuo flujo de valor.
Proporcionamos resultados fiables involucrando frecuentemente al cliente y compartiendo con el la propiedad del proyecto.
Esperamos incertidumbre y la manejamos mediante iteraciones, anticipación y adaptación.
Liberamos creatividad y motivación reconociendo a los individuos como la fuente última de valor y creando un entorno donde ellos puedan marcar la diferencia.
Impulsamos el rendimiento mediante la responsabilidad compartida en los resultados y efectividad del equipo.
Mejoramos la efectividad y la confianza mediante procesos, prácticas y estratégias especificas para cada situación.
«


Más información (en inglés) en la página de Alistair Cockburn.

¿Que proceso o usuario esta bloqueando un fichero o directorio?

A menudo, cuando trabajamos con ficheros desde un programa acabamos en este callejón sin salida, sobre todo si se trata de un archivo al que se accede desde varias aplicaciones.

Esta mañana teniamos un problemilla de bloqueos, unos archivos que se sirven desde una aplicación web y que editamos desde Visual Studio, estaban dando problemas de bloqueos. No podiamos editarlos desde Visual Studio, yo no sabia si el problema era nuestro o de Visual Studio 2005 pues en 2003 el problema no se daba. En el proceso de depuración he encontrado una herramienta muy útil. Es una simple extensión del shell que nos permite desde el menu contextual del explorador averiguar quien esta bloqueando un archivo o directorio. La herramienta se llama, como no podia ser de otro modo WhoLockMe, y podeís descargarla gratuitamente.

Sin duda esta utilidad es el complemento ideal a Process Explorer y Handle cuando tratamos de 'cazar' problemas de bloqueos sobre ficheros o directorios.

La Web 2.0 y la seguridad

Lo que se a dado en llamar la Web 2.0 es sin duda el camino a una experiencia más rica para los usuarios de aplicaciones web, pero según Shreeraj Shah en su artículo 'Top 10 Web 2.0 Attack Vectors' , tambien es un nuevo caldo de cultivo para nuevas vulnerabilidades y vectores de transmisión de virus y ataques. El artículo me ha parecido especialmente interesante, por eso me he decidido a traducir la listas de esos vectores con el afán de tenerlos siempre en cuenta, a modo de checklist de comprobación, para más información os remito al artículo original.

Aquí va la lista de vectores de ataque en aplicaciones Web 2.0 y una breve descripción de cada uno de ellos:

Cross-site scripting en AJAX: Las vulnerabilidades basadas en XSS son ya unas viejas conocidas de todos los desarrolladores web, pero sin duda el amplio uso de JavaScrip que hace AJAX hace que estas tomen una nueva dimensión.

Envenenamiento XML: Muchas aplicaciones Web 2.0 mueven datos entre el servidor y el cliente en forma de XML. Es relativamente facil crear XML malformado, que unido a un parseo poco cuidadoso del mismo en el servidor, puede degenerar en una denegación de servicio. Debemos validar en cualquier caso todo XML recibido en el servidor.

Ejecución maliciosa de código AJAX: Las llamadas AJAX se ejecutan en segundo plano sin la interacción directa del usuario. Esto hace que el usuario no siempre sea consciente de las activdades que esta realizando un determinada web, lo que una web maliciosa puede aprovechar para, por ejemplo, hacerse con cookies de autentificación.

Injección RSS / Atom: Esta tecnica consiste en inyectar código JavaScript en el RSS o Atom para que el navegador lo ejecute. Casi todos los navegadores son capaces de mostrar feeds RSS o Atom. Si nuestra aplicación produce un RSS o un Atom deberiamos validar su contenido antes de enviarlo al cliente.

Enumeración y escaneo WSDL: Básicamente los posibles atacantes pueden encontrar un motón de información sobre simplemente viendo la información que nosotros publicamos sobre nuestros servicios web. Debemos proporcionar el acceso más limitado posible a nuestros WSDLs.

Validación (unicamente) de cliente en rutinas AJAX: La validación en cliente en la aplicaciones Web 2.0 es muy rica, esto ha hecho que algunos desarrolladores no hagan estas misma validaciones en el servidor. Esto es un error porque es facil crear una petición y enviarla al servidor saltandose la validaciones de cliente. Por ello las validaciones de cliente siempre deben ser respaldadas en el servidor.

Cuestiones relacionadas con el enrutado servicios web: WS-Routing permite enviar un mensaje SOAP debidamente encriptado por un camino de servidores, pero si un solo servidor de ese camino se ve comprometido, nuestro mensaje SOAP puede ser comprometido.

Manipulación de parámetros con SOAP: Es posible crear mensajes SOAP malformados que intenten realizar inyecciones clasica tipo SQL, XPATH, LDAP o de comandos.

Injección XPATH en mensajes SOAP: Es un proceso similar a las inyecciones de SQL sobre bases de datos, solo que utilizando XPATH como lenguaje de consulta y documentos XML como destino del ataque.

Manipulación binaria del cliente rico ligero: La aplicaciones utilizan componentes ActiveX, Flash o Applets, que ya han demostrado historicamente que son caldo de cultivo para virus y otros tipos de malware.