Vulnerabilidad en ASP.NET y su efecto en Team Foundation Server

Como seguro que sabéis, hace poco se ha detectado una vulnerabilidad en ASP.NET, y aunque ya se está trabajando en su solución, mientras tanto, hay una serie de configuraciones que se pueden aplicar en nuestros websites para evitar vernos afectados, y que ScottGu ya puso en su blog

Team Foundation Server, está basado en ASP.NET, tanto para los webservices que lo forman como para otras partes del servidor, y por tanto, esta vulnerabilidad afecta a los siguientes servicios de TFS, y que necesitaremos “parchear” temporalmente mientras que salga la solución definitiva:

  • TFS Web Services
  • Team Web Access
  • TFS Proxy
  • Sharepoint
  • Reporting Services
Por lo que Brian Harry, ha publicado en su blog, un documento, para parchear todos estos servicios, excepto la parte de Reporting, para la que el equipo de SQL aún no ha publicado los pasos a seguir para parchearlo.
El documento lo podéis encontrar aquí:

 

La necesidad de probar … y el iPhone 4

Últimamente, en varias listas de correo y foros variados, estabamos comentando la necesidad de probar, todo lo que hacemos y desarrollamos desde el principio.

Y cuando decimos desde el principio, decimos desde la primera línea de código, y es que no debería de haber ni una sóla línea de código sin una prueba, no voy a discutir si usar TDD o cualquier otra técnica, da igual, pero no debería de haber ni una sóla línea de código sin una prueba. Con esto nos aseguramos, entre otras muchas cosas, que cuando metamos mano a ese código, podamos estar seguros de que lo dejamos funcionando, y que cuando venga alguien y vea ese código pueda estar seguro de que funciona.

En esta primera categoría entran pruebas unitarias y de integración, y pueden sernos de gran ayuda tanto las propias herramientas de Visual Studio 2010, como los frameworks tipo nUnit o Gallio.Con esto ya tenemos nuestra primera capa de pruebas creada.

OJO, aquí sólo estamos asegurando los componentes y/o su integración entre ellos, aún no estamos asegurando que la aplicación haga lo que tiene que hacer, mucho cuidado, que esto  no es suficiente aún.

Y es que ¿cómo sabemos que cierta característica de la aplicación está terminada? aquí entran las pruebas funcionales y de aplicación, que tienen que describir, para cada caracterísitca, que condiciones se tienen que dar para que aporte valor, y esto es importante, que aporten valor al cliente, este es el objetivo último de lo que quiera que estemos construyendo, que aporte valor, y esto lo tenemos que describir (junto con el cliente), tanto para el sistema completo, como para cada una de sus características, y que no haya duda razonable de cuando está “hecho” algo.

Para esto, podemos apoyarnos en herramientas como las nuevas herramientas de testing de Visual Studio 2010, con el Test Manager, y también, usando técnicas como Behaviour Driven Development, que intentan promover la colaboración entre desarrolladores, departamento de QA, y gente de nivel de negocio, y que por ejemplo a nivel técnico, podemos implementar usando MSpec.

Vale, hasta aquí con estas dos capas de pruebas, que no es poco, vamos bien, por supuesto luego hay más pruebas que muchos productos tienen que pasar, como por ejemplo pruebas de accesibilidad para pasar la AAA, pruebas de usabilidad para ver como se adaptan los usarios al software, pruebas de rendimiento, de escalabilidad, etc.

Y ¿por qué saco todo esto sin más?, pues porque recientemente, y gracias a mi operadora, me han regalado un iPhone 4, si ese que si lo agarras “mal” pierde cobertura, y la verdad es que tenía intriga por ener uno entre mis manos y ver la realidad del tema, ya que incluso en foros por ahí, hablan de que Apple, había sacado otro modelo sin el fallo de diseño y sin hacerlo público, claro, como si cambiar una línea de producción fuese rápido y barato, en fin …

Por supuesto, lo primero que hice cuando tuve mi nuevo cacharro en las manos, fue probar el tema del famoso agarre, y sorpresa, es perfectamente reproducible, especialmente en sitios dónde la cobertura no es óptima. Y esto me lleva a preguntarme ¿cómo hacen las pruebas los señores de Apple?, porque está claro que nadie ha probado que un móvil, al ser agarrado, no pierda su principal valor, que es la cobertura o bien dicho la capacidad de llamar con la mejor calidad posible.

Tampoco veo que hayan hecho pruebas de usabilidad en ese sentido, ya que cualquier persona que lo hubiese cogido con ánimo de probarlo, se habría dado cuenta.

¿Entonces?, la verdad es que el iPhone 4, en otros términos es un buen producto, la pantalla es muy buena, la funcionalidad es buena, etc., pero han fallado en algo básico, y esto ha hecho que se desate, y con razón, toda la red con comentarios negativos. si, es cierto que los usuarios  más acérrimos lo negarán, pero es algo que ocurre, que está ahí y que es reproducible, y que pueden dar al traste, y dejar mal sabor de boca, a un producto que no es malo (hasta que venga Windows phone 7 y le de un repaso jejeje).

Por tanto ¿cómo probáis vuestras aplicaciones?¿cumplís con el valor que tienen aportar?¿tenéis claro cúal es ese valor que tienen que aportar? … ahí dejo eso, os dejo que creo que me llaman … vaya al coger el móvil he perdido cobertura Smile

Versión de septiembre de las TFS Power Tools 2010

Ya tenemos la versión de septiembre de las (a mi juicio) indispensables TFS Power Tools, y que podréis descargar de aquí: http://visualstudiogallery.msdn.microsoft.com/en-us/c255a1e4-04ba-4f68-8f4e-cd473d6b971f

Se han actualizado tanto la herramienta de línea de comandos tfpt.exe, como el TFS Best Practices analyzer (para comprobar despliegues de TFS 2010).

Pero lo que más me ha gustado de esta nueva versión es la nueva herramienta de backups de TFS. Cómo muchos sabéis y muchos habréis sufrido, el backup de TFS, suele ser trabajoso, ya que incluye no sólo las bases de datos propias de TFS, si no también las de Sharepoint y las de Reporting.

Con esta nueva herramienta, desde la consola de administración de TFS 2010 (en el servidor), podremos establecer una tarea programada para hacer backups de las bases de datos de configuración de TFS, de cada Team Project Collection, y si tenemos Sharepoint y/o Reporting, también hará backup de esas bases de datos, nosotros sólo tendremos que preocuparnos de decirle cuando y dónde queremos los backups.

Y por su puesto, trae también un wizard d e restauración de los backups, que suele ser otro de los temas complejos.

Ah, sólo una cosa más, cuando tengáis Reporting, también tendréis que hacer backup de la llave de encriptación de Reporting, esto sólo hay que hacerlo una vez, y NO se incluye en esta herramienta de backups, precisamente por eso, porque sólo se hace una vez.

Y ahora nada, a descargar las TFS Power Tools y probarlas.

¿Es “agile” una moda, tendencia, la mejor opción … la única opción?

Hola a todos, es cierto, hace tiempo que no escribía, una mezcla entre pereza, falta de “creatividad”, acumulación de trabajo, etc., bueno quizás más de lo primero, pero espero volver a reincorporarme poco a poco.

La cosa es que leyendo hoy uno de los blogs que sigo bastante habitualmente: http://navegapolis.net/ (y que recomiendo a cualquiera interesado en Scrum), leo un post acerca de la inversion de tendencias entre CMMI y agile, en las búsquedas de google.

Y como no, me viene a la cabeza, todas las opiniones que leo y escucho (bueno algunas sólo las oigo), y me empiezo a preguntar, ¿es la “agilidad” sólo una moda?, cada vez si que es cierto que veo más interés por este tipo de metodologías, incluso en personas, que hace un tiempo, eran bastante incrédulos ante las ideas de la “agilidad”, es más, y lo que más me preocupa, ya empiezo a escuchar las voces que propugnan agile, o algunos de sus proceso y prácticas, como la única verdad.

Y me preocupa porque, o yo no entiendo el tema de “agile” (me considero un mero aprendiz pero eso da para otro post), o la gente se hace muchos líos en la cabeza, ahora resulta que el que no hace ciertas cosas está equivocado, vaya, yo que pensaba que precisamente el manifiesto ágil iba, entre otras cosas, en contra de las balas de plata, y que lo que funciona para unas personas puede no funcionar para otras (people over processes and tools).

Y es que, como siempre decimos muchos, no hay una bala de plata, llámese “agile” (partiendo de lo más genérico), scrum o CMMI.

También es cierto, que soy un poco, como decirlo hmmm, toca narices??? por no decir otra cosa, y es que cuando veo que mucha gente empieza a crear uina “moda”, tiendo a desconfiar de eso, lo se, no debería de desconfiar inmediatamente, pero soy así y lo hago.

Y es que, ¿si haces agile no puedes hacer CMMI?, si que es cierto que muchos de sus principios son contrapuestos, pero ¿dónde dice en scrum que no se puedan tratar los entregables de CMMI como parte del producto a entregar en un sprint?, o ¿dónde dice en CMMI que no se pueden hacer sprints, retrospectivas o daily scrums?.

En definitiva, que me gusta que la gente se interese por el movimiento “agile”, pero ojo con esto de las modas, ni todo es tan bonito como lo pintan los que lo venden, ni todo es tan feo como lo pintan los que se oponen, hay que probar, investigar, adaptar, hay mucho trabajo que hacer antes de poder empezar a sacar provecho de cualquier cosa.

Ojo, tampoco defiendo que cada uno haga lo que buenamente le venga en gana sin fijarse en más, hay que leer mucho, compartir opiniones, probar las cosas “según el libro”, antes de poder adaptar o afirmar si algo funciona o no, y siempre teniendo en cuenta que lo que me funciona a mí, puede no funcionarte a tí, y eso no lo hace ni mejor ni peor.

Lo dicho, a empaparse de las cosas, a aprender, a probar, y no sólo dejarse guiar por las tendencias.