Archivo de la categoría: Mi cosecha

[ebook] Guías de Visual Studio Version Control [ALMRangers]

ALMRangers

Los Visual Studio ALM Rangers ofrecen una guía profesional, experiencia práctica y proporcionan soluciones a la comunidad ALM. Son un grupo especial compuesto por miembros del grupo de producto de Visual Studio, de Microsoft Services, Microsoft Most Valuable Professionals (MVP) y Visual Studio Community Leads. La información sobre sus miembros está disponible aquí online.

Hace un tiempo me lancé a traducir una guía que escribieron que me pareció muy interesante: Testing Unitario con Microsoft Fakes. (Hace poco lanzaron la segunda revisión y también actualicé la versión que traduje.

En estas últimas semanas he estado trabajando en otras traducciones de otras guías sobre Visual Studio Version Control y todas sus funcionalidades:

EstrategiasDeBranching JoyasTFVCGestionDependenciasNuGet

Espero que os resulten interesantes.

[Updated]

Aquí tenéis los enlaces directos a los pdfs a las traducciones:

Post en el blog de Willy-Peter Schaub

Juan María Laó Ramos

TFS, Windows Phone y MSTests

¿Quieres que en las builds que tengas configuradas en TFS se ejecuten los test de tu aplicación Windows Phone?

Seguramente habéis probado a incluir un proyecto del tipo "Windows Phone Unit Test App" y os habéis puesto a crear nuestros tan amados tests. Pero a la hora de incluirlo en el repositorio de código, os habréis dado cuenta de que pasa algo raro: Los test no se ejecutan. (Si no te has dado cuenta, deja de leer esto y ve a comprobarlo)

La cosa es que ese proyecto de test lanza un emulador de WP y ejecuta los test y eso TFS no lo soporta todavía. Así que tienes dos opciones:

1) Dejar de hacer tests de tu aplicación WP.

2) Continuar leyendo.

Bien, si estás aquí, te cuento la solución en unos cuantos pasos:

1) Añade un proyecto de test típico de Visual Studio: Visual Studio Unit Test Project.

2) A este proyecto de test, añade una referencia del proyecto Windows Phone 8 que estés desarrollando.

3) Añade una copia local de los assemblies de Windows Phone que necesites, por ejemplo:

- System.Windows

- Microsoft.Phone

Los encontrarás en el directorio C:\Program Files (x86)\Microsoft SDKs\Windows Phone\v8.0\Tools\MDILXAPCompile\Framework

4) Copialos a un directorio local, que también tendrás que subir al TFS, llámalo por ejemplo /lib/ y ahora edita el XML del proyecto de test (el .csproj) y reemplaza:

<Reference Include="System.Windows" />
<Reference Include="Microsoft.Phone" />

por:

  <Reference Include="System.Windows, Version=2.0.6.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e, processorArchitecture=MSIL">
  <HintPath>lib\System.Windows.dll</HintPath>
</Reference>
<Reference Include="Microsoft.Phone, Version=8.0.0.0, Culture=neutral, PublicKeyToken=24eec0d8c86cda1e, processorArchitecture=MSIL">
  <HintPath>lib\Microsoft.Phone.dll</HintPath>
</Reference>

Además, para evitar los warnings cada vez que compiles añade este elemento al primer grupo de <PropertyGroup> del .csproj:

<ResolveAssemblyWarnOrErrorOnTargetArchitectureMismatch>None</ResolveAssemblyWarnOrErrorOnTargetArchitectureMismatch>

A partir de este momento, cuando incluyáis vuestro proyecto en vuestro TFS vuestros tests se ejecutarán como si lo hiciesen en el emulador, pero sin tener que lanzarlos.

Espero que pronto den solución a este "problema" y lo incluyan en la próxima versión.

Este post ha sido gracias a una respuesta en stackoverflow http://stackoverflow.com/a/13035195 que me ha salvado el día.

¿Se os ocurre otra forma de conseguir el mismo resultado?

Espero que sirva.

Juan María Laó Ramos.

[ebook] Testing Unitario con Microsoft Fakes

Hace un tiempo encontré un recurso que me pareció bastante interesante de compartir con la comunidad hispano-hablante.

Me lié la manta a la cabeza y fui traduciéndolo poco a poco. Y gracias a Jose Bonnin (@wasat) y a los Visual Studio ALM Technical Rangers aquí tenéis el resultado:

MicrosoftFakes

Post en el blog de los Visual Studio ALM Technical Rangers: http://blogs.msdn.com/b/willy-peter_schaub/archive/2013/08/22/191-habla-espa-241-ol-testing-unitario-con-microsoft-174-fakes.aspx

Espero que sirva.

OneNote 2013

GTD y OneNote

Y así damas y caballeros es como llevo un tiempo aplicando GTD con OneNote, usando un OneNote que está siempre en la nube 🙂

OneNote y GTD

Secciones:

  • Entrada: voy poniendo todas las cosas que van surgiendo que tengo que hacer.
  • Siguiente: Pongo las tareas que he decidido que voy a hacer en el día.
  • Proyectos: Los diferentes proyectos que tengo a la vista y de los que quiero ir cerrando tareas. Esta sección tiene páginas, una por proyecto.
  • Algún día: Al igual que la sección de proyectos, en esta sección creo una página por proyecto que algún día me gustaría hacer.

¿También usas OneNote para gestionar tus tareas? ¿Cómo lo haces?

Juan María Laó Ramos

Knock, knock … Buenos días developer, venimos a hablarle de TDD

Aviso: Este es un post que te va a vender TDD.

En otras publicaciones han resumido las bonanzas de TDD, como el libro de @carlosble "Diseño ágil con TDD". Os lo recomiendo desde ya.

Pero he encontrado una presentación de Francesco Carucci, antiguo desarrollador de Crytek que actualmente trabaja en Apple, en la que muestra/vende TDD desde el punto de vista del desarrollo de video juegos.

Me ha parecido muy bien estructurada y cómo vende TDD, así que lo pongo aquí para escribirlo, compartirlo y de manera egoísta, como un ejercicio para que me ayude a no olvidar algunas cosas.

La estructura consiste en poner las diferentes razones y excusas que solemos dar para no escribir tests o por qué no hacer TDD y las respuestas que deberíamos grabarnos como mantras. Así que allá vamos:

No hago Tests por que ...

... el tiempo que gasto en escribir test es tiempo que podía estar escribiendo código.

  • Al final gastamos más tiempo en debugear y mantener código que escribiéndolo.
  • Si escribimos primero los test y el código que los pasa, el código que los pasa es código de producción. La consecuencia es que tardamos menos tiempo en tener código que funciona, esto es: código de producción.
  • La modificación del código es más confiable. Cuando modificamos código lo hacemos "más tranquilos" ya que sabemos que vamos a romper pocas cosas, y si se rompen, nos vamos a dar cuenta rápido.
  • Se evitan bugs de regresión. Al detectar un bug, escribimos un test que lo reproduzca y ese bug no volverá a aparecer.
  • Se detectan antes los bugs, como ya vimos en el post anterior

... los test no lo pueden probar todo

  • Un test es mejor que ninguno.
  • El código legacy o de terceros no hay que testearlo a menos que tengamos que modificarlo.
  • Roma no se construyó en un día, pero se construyó (y conquisto el mundo conocido)

... este código es temporal y lo cambiaré después, no necesito testearlo

  • Todo el código se modifica tarde o temprano. Hacer código que sea fácil de cambiar es la razón fundamental de TDD: elimina la sobre-ingeniería (KISS, Keep It Simple, Stupid!)
  • Los requisitos cambian: entonces hay que modificar los tests afectados y el código de producción. Pero como está testeado unitariamente, el código está más desacoplado, es más fácil de modificar y los cambios tendrán menos efectos secundarios.

En el mundo del desarrollo de juegos

El desarrollo de juegos es diferente: los test automatizados pueden no funcionar.

  • En general el desarrollo de juegos es totalmente diferente …
  • … pero escribir código es lo mismo, incluso más simple.
  • El código de un juego es más algoritmia y matemáticas, eso es incluso más fácil de testear que un proceso de negocio.
  • Un código de sobresaliente es lo mismo tanto en un juego como en una web.
  • El código de un juego cambia a menudo: más cambios es un motivo más para tener test que comprueben que no se ha roto nada.

Los juegos son para divertirse, un test no puede comprobar que un juego sea divertido.

  • Pero sí puedes capturar bugs, y menos tiempo debugando errores significa más tiempo para implementar la parte divertida.
  • Crear un test para un bug te asegura que ese bug no volverá a aparecer (El 30% de las correcciones de bugs crean nuevos bugs debido a efectos colaterales)

Esto es un juego AAA, es muy arriesgado hacer test automatizados sobre él.

  • Los juegos AAA son muy complejos, muy tecnológicos y muy divertidos. Para conseguir un juego AAA, se deben usar herramientas adecuadas, y los test automatizados son una de esas herramientas.
  • Lo arriesgado es NO hacer test en un juego AAA

¿Cuándo TDD no es apropiado?

  • Prototipos. Mientras buscamos/probamos posibles soluciones a un problema.
    • La solución final SÍ debe estar hecha con TDD.
  • En el código de wrappers de librerías existentes.
  • En la capa GUI, eso no es testing unitario, es testing de integración.
  • En código de bajo nivel, el que está muy cerca del hardware

Objetivo: Producir más funcionalidades en menos tiempo.

No perdamos de vista el objetivo, producir lo antes posible código que vaya a producción, esto es código que funciona, libre de bugs y mantenible

¿Y tu porqué no haces Test o TDD?

TDD: Mentirosos el ciclo no es Red – Green -Refactor

Nos han engañado estos del TDD, son unos malditos mentirosos, el verdadero ciclo es:

Think - Red - Green - Refactor

Y no te lo dicen, aunque para algunos iluminados sea algo implícito, el primer paso es pensar (Think) el algoritmo/lógica que quieres implementar, y es ese primer paso el que siempre me saltaba. Soy una persona visceral y suelo actuar por impulsos, y a la hora de programar ... pues me pasa un poco que me dejo llevar.

Por eso voy a desglosaros cómo veo yo el ciclo de TDD:

Think

  1. Piensa y reflexiona la lógica que tienes que implementar.
  2. Identifica las diferentes responsabilidades que hay
  3. Por cada responsabilidad habrá una clase. (¡Quieto!, aparta las manos del teclado, no es el momento de escribir las clases. Dibújalas en un PDA (Papel de Apuntar))
  4. Elige un buen nombre para cada una de ellas. Nombres descriptivos, limpios, claros, afeitaditos. Evita las terminaciones de LoQueSeaObject, LoQueSeaManajer, etc... Si no dice nada sobre la funcionalidad de la clase quítalo. Si aún así estás tentado a ponerlo, es que esa clase hace más de una cosa (Principio KISS), así que vuelve al paso 1.
  5. En el PDA dibuja las relaciones entre las diferentes clases

Foreach (responsabilidad in PDA)

  • Crea una clase de Test por cada una (ejemplo: responsabilidad1Test)
  • Y ahora sí, en cada clase de test haz todos los Red - Green - Refactor necesarios para probar la funcionalidad que la clase testeada debe tener.

Mis conclusiones

Escribe tu código como si un asesino esquizofrénico que tiene tu dirección fuese a mantenerlo

Esta es una frase muy conocida en el mundo Agile, no recuerdo si era exactamente así, pero lo que viene a resumir es que al final pasamos más tiempo leyendo, debugeando y manteniendo código que escribiéndolo. Por eso es muy importante pensar muy bien el nombre que les vamos a dar a las clases, variables, métodos, propiedades, etc. En definitiva haz lo que sea necesario para que tu código sea legible.

La formación no es importante, es IMPRESCINDIBLE

Aprender la teoría está bien, pero si viene acompañada de una práctica con alguien que te guíe te va a ayudar mucho más, sí, es algo obvio, pero que no se suele hacer.

Las herramientas de refactoring son nuestras amigas

Sólo hablo del "generate method" y "generate class" de Visual Studio, no me han hecho falta más. Cuando empiezas a escribir el test, y haciendo clic derecho y buscar esa opción en el desplegable nos permite crear rápidamente las clases y métodos que nos vayan haciendo falta, pero no te olvides del asesino esquizofrénico.

El Nirvana del TDD

El Nirvana del TDD es no tener que debugear para detectar un bug, sólo crear un test que lo reproduzca y corregirlo. Si consigues llegar a este punto ya eres un TDD Master.

¿Cómo ampliarías este post?

Cambio de dominio

Hola a todos:

Os habréis dado cuenta que hemos redirigido el gran blog http://speakingin.net que comenzamos ya hace 4 años en el 2007.

A partir de ahora este será nuestro nuevo sitio en el que seguiremos haciendo las traducciones de Scott Guthrie y buscaremos más contenidos interesantes para la comunidad Hispano hablante que tanto cariño y aprecio nos tiene.

Espero que esta nueva etapa que comienza sea aún más emocionante para todos nosotros.

Espero que os gusten los nuevos contenidos que tenemos preparados.

Speakingin.net Team.

ShareBill, la e-Servilleta

¿Estáis cansados de salir con “amigos” y a la hora de pagar nunca salen las cuentas? Ya tienes una solución mucho más cómoda, manejable y con menos errores que la calculadora de tu Smartphone.

Imagen digital de una servilleta de bar

Ha llegado Sharebill, la e-Servilleta(para los de la LOGSE servilleta electrónica) y totalmente gratuita desde el Marketplace de Microsoft.

Imagen de la interfaz de usuario de la aplicación Sharebill

Espero que os sirva.

Juanma

Documentación del formato XNB

Me voy a atrever con mi primer post sobre XNA, y es que he encontrado una documentación muy interesante sobre el formato XNB en el App HUB: http://create.msdn.com/en-US/sample/xnb_format

El documento cuenta en 22 páginas el formato de compilación de los .xnb generados por el proceso de compilación del pipeline de XNA Game Studio 4.0. Una lectura muy interesante si queremos enterarnos de las entrañas de ese proceso ... sip, uno se vuelve loco de vez en cuando y le da por buscar cosas ... y luego encuentra esto.

Y para más inri (¿es con o sin hache?) incluye un ejemplo en C++ nativo de un parser xnb en el que vemos cómo parsear un archivo compilado mostrando el contenido en la pantalla.

Espero que os guste tanto como a mi. 🙂

Juan María Laó Ramos.

 

First Lego Leage en Sevilla

La First Lego Leage llega a Sevilla. El día 6 de Marzo en la Escuela Técnica Superior de Ingeniería Informática estaremos viendo los robots que niños de hasta 16 años han hecho para pasar las pruebas de la competición de este año.

Este año las pruebas están orientadas a realizar una serie de asistencias médicas: desde tratar un hueso roto hasta realizar una operación cerebral a vida o muerte.

Estáis todos invitados.

JuanMa

¿Puedo ayudarte a dejar de fumar?

Pues si me dejas intentarlo os ofrezco esta sencilla herramienta para Windows Mobile 6.1/6.5 que he realizado para controlar el número de cigarros que fumas.

Es de uso sencillo e intuitivo y si tenéis alguna pregunta sobre su uso me tenéis disponible para lo que queráis:

La tenéis disponible para descarga en el MarketPlace aquí.

Espero sinceramente que os sirva como a mi.

Juan María.

Autenticación en WCF

Gracias a una duda en la lista de correo del Club .Net de Sevilla vamos a ver cómo funciona esto de la autenticación en WCF.

Os recomiendo que os leáis un poco la documentación que hay en MSDN sobre WCF, y que os descarguéis los ejemplos que están disponibles aquí. Son muy pero que muy completos, y muestran casi cada característica de WCF.

Lo que vamos a ver es sobre cómo poder autenticar a un usuario con un login y password. El ejemplo que trata este caso en concreto lo tenéis aquí. En el ejemplo, se usa un binding wsHttpBinding, está muy bien, todo perfecto. Pero lo que no queda claro es que la credenciales del login y password viajan cifradas por la red. Todo para evitar sniffers, ataques man-in-the-middle, etc...

El pero es que necesitamos un certificado que permita esa seguridad, que como se dice en el ejemplo, al definir la autenticación por Username a nivel de mensaje:

Con esta configuración, lo que no queda claro, es que las credenciales y todo el tráfico va cifrado a nivel de transporte. Pero para eso nos hace falta un certificado que el servicio usará para: 

  1. Autenticarse a los clientes.
  2. Cifrar las comunicaciones a nivel de transporte.

En los ejemplos nos indican cómo generar un certificado para pruebas. Esto lo tenemos en los archivos Setup.bat y clean.bat junto a los archivos de solución de VS. Esos archivos usan unas herramientas disponibles para XP, Vista, Server 2003 y 2008, etc. Para XP podéis descargarlo aquí.

Este certificado no es confiable, ya que está firmado por nosotros mimos como entidad certificadora. Esto tiene sus ventajas e inconvenientes. Ventajas de cara a la seguridad (siempre incómoda pero necesaria, que luego pasa lo que pasa) y los inconvenientes es que no es barato. Pero bueno, lo importante es que necesitamos un certificado x509 (de esos).

Lo importante que no se dice en la documentación pero que si se ve en el código de los ejemplos, es que tenemos que indicar cuál es el certificado que nuestro servicio WCF va a usar. Una vez ejecutado el setup.bat y si vemos la palabra succeedd podemos continuar:

¿Por donde iba?.. Ah si. Tenemos que indicar el certificado que va a usar el servicio. Esto se hace en la sección de ServiceCredentials:

Ya tenemos un servicio que usa un certificado para autenticarse y cifrarse, muy bien. Pero quién se va a fiar de un certificado que no está firmado por Verisign? ¿Yo? No debería, ya que entonces la seguridad que le estamos metiendo es "pa na". Quiero decir, que a la hora de hacer esto y poner un sistema en producción debemos contar con un certificado bueno, de pata negra. Aquí estamos viendo sólo cómo se hace para un entorno de desarrollo.

La falla de seguridad está en que podemos decirle a la aplicación cliente que no se fíe de este tipo de certificados. Por defecto, cuando agregamos una referencia a un servicio wcf con certificados con Visual Studio, la configuración que nos planta es que no va a aceptar certificados que no estén firmados por autoridades de confianza (como Verisign).

Esto es lo que me estaba fallando y lo que originó la serie de preguntas y respuestas en la lista de correo del Club .Net de Sevilla. Si nos vamos al App.Config de la aplicación cliente podemos cambiar ese comportamiento, y decirle a la aplicación cliente que confíe en estos certificados, esto lo hacemos de la siguiente forma:

Si nos vamos al App.Config del cliente que viene en el ejemplo, lo vemos. Además tenemos que decirle al endpoint del cliente que use este behavior:

Y ya está. A runear.

Espero que seáis más listos que un servidor (que no tiene certificación alguna) y no necesitéis esto.

Espero que sirva.

Juan María.

Nuevo cambio en MSDN

El Jueves leí en el blog de Somasegar el anuncio de otro cambio en MSDN. En concreto del look & feel. Soy programador y bueno, como a muchos programadores (cada vez menos), el tema del diseño es algo que nos cuesta más trabajo. Crear interfaces y experiencias  de usuario amigables no es algo fácil, pero tampoco imposible.

En realidad envidio a las personas que tienen esa capacidad de crear de la nada algo bonito y usable para una gran mayoría. Pero en definitiva es algo en lo que, yo por lo menos, tengo que mejorar. Para gustos los colores y nunca mejor dicho.

La cosa es que estaba yo tan tranquilo con mis cosas y fuí a hacer una consulta a MSDN, mientras escribía la dirección en la barra de direcciones me acordé del post de Somasegar y pensé: Uy, a ver que han puesto nuevo...

Y toma, la primera en la frente: En la sección Sus recursos que está en el centro de la página aparecen tres enlaces a recursos impresionantes, como los blogs de los Davises (Carmona, Salgado, Cervigón), el de Héctor Montenegro, Jose Murillo, Cesar de la Torre y un largo etcétera. Cada uno con sus cosas buenas y cosas no tan buenas (por ser políticamente correcto, 😉 ). Gente de las que he aprendido un montón y sigo aprendiendo.

A lo que iba, la cosa es que este humilde blog aparece entre tan "privilegiada" compañía:

Captura MSDN

 Se que suena ya un poco de autobombo pero es algo que me llena de orgullo y satisfacción. Ya comenté que no esperaba esta acogida cuando empecé con este blog.

Sólo puedo dar las gracias a toda la gente que he conocido y de las que tanto estoy aprendiendo.

Ya por último me gustaría tener un poco de feedback y saber vuestras opiniones, halagos, insultos, cambios y cosas que creeríais que podría cambiar, mejorar, eliminar, añadir ...

Y sobre todo, muchas gracias por pasar por aquí.

Casi un año

Hace ya casi un año que comencé con la aventura de este blog. Una idea que se coció en el Club .NET de la Universidad de Sevilla, entre amigos. Unos cuantos locos por la tecnología que se reúnen para hablar de ella. No sólo sobre tecnologías de Microsoft, ahí están las experiencias con Mono, uno de nuestros compañeros está implementando la parte de WCF, otro como parte de la comunidad de desarrolladores de OpenLayers,  ... y una lista enorme de gente que si me pongo a enumerar ... dejo a WordPress sin espacio en disco.

He conocido y sigo conociendo a un montón de gente tan apasionada en este tiempo que me llego a sentir incluso un poco acongojado de ver cómo se mueve este mundo. Y es que aunque siempre he sabido que el mundo de la informática se mueve deprisa, nunca lo había experimentado hasta que "engañé" a gente para que me dejara entrar en este mundo.

Hoy hemos alcanzado en este humilde blog las cien mil visitas. No se si será mucho para un año de vida de un blog técnico. Realmente no me importa, ya que las visitas que más me impresionaron fueron las treinta y tres primeras visitas en el mes de Marzo de 2007.

Sólo puedo daros las gracias a todos los que me visitáis y linkais. Sólo espero que este pasatiempo de traducción ayude a otros a resolver problemas. 

Muchas gracias.

 Juan María Laó Ramos.

Problemas con el servidor web de VS

Llevaba un tiempo teniendo varios problemas con la ejecución de una aplicación web en el servidor web que trae Visual Studio, llamado Cassini.

El principal problema es que los incidentes que sufría ocurrían de vez en cuando, es decir, no conseguía reproducir exactamente el error. Y lo peor de todo es que no sabía cuales eran las condiciones que hacían aparecer ese error. En el IIS funcionaba perfectamente, pero en mi máquina de desarrollo, de vez en cuando y sin saber porqué fallaba. 

Después de estar un tiempo ejecutando paso a paso la aplicación resulta que la cache de un postback a otro se vacía. Sigo investigando y doy con este link: http://www.johnsadventures.com/archives/2006/02/why_does_my_aspnet_cache_keep_clearing_i.html

Parece ser que cuando la máquina se va quedando sin memoria, pues la cache de dicho servidor web para las aplicaciones web que esté ejecutando se libera.

Sólo con configurar el web config de la aplicación va perfecto, un poco lento cuando estoy haciendo varias cosas a la vez, pero ya no padezo de dicho error. Lo conseguimos configurando la cache en la sección System.Web del Web.config de nuestra aplicación de la siguiente manera:

<caching>
  <cache disableMemoryCollection = “true
    disableExpiration = “false
    privateBytesLimit = “0
    percentagePhysicalMemoryUsedLimit = “90
    privateBytesPollTime = “00:02:00/>
</caching>

Espero que sirva.

Juan María Laó Ramos

Firefox, Visual Studio 2005 y Windows Vista

Llevo tiempo peleándome con el pequeño servidor que trae VS 2005 para hacer pruebas con páginas ASP.NET en local. El problema que tenemos los desarrolladore web es el de siempre, que si no se ve bien en Firefox e IE, etc, etc. Típica discusión cuando no se hacen las cosas bien con los estilos CSS. Afortunadamente estoy aprendiendo un poco y le voy cogiendo el truco. Sigue leyendo

De vuelta

Acabo de volver de unas pequeñas vacaciones. Y veo que tengo mucho que traducir, así que me pongo a ello ahora mismito.

Huelva: CodeCamp y Madrid: Remix

A ver si mi jefe no me pilla escribiendo esto en horario de trabajo. :).

Hemos estado en dos eventos en los útlimos cuatro días. El primero en la CodeCamp, en Huelva. Evento para estudiantes y profesionales. Una especie de toma de contacto entre ambos sectores en la que pudimos conocer productos, empresas, planes empresariales, experiencias en la sesión de "El diván de Mónica",en donde tres MVP's aportaron su testimonio y carrera en esto de la informática, sesiones sobre Silverlight por Jose Murillo, una de Robotics Studio por Miguel Ángel Ramos ... y un largo etcétera.

Lo más importante que me llevo de este CodeCamp es las posibilidades y facilidades que hay disponibles para emprendedores que quieran montar su empresa por parte de Microsoft. Sigue leyendo