Enlaces de interés 3

Aquí tenéis la lista de enlaces de noticias y cosas que he ido recopilando durante la semana:

[¿Truco WPF?] User Control a pantalla completa

No he tenido la oportunidad de realizar muchas aplicaciones con WPF y en un proyecto en el que trabajo nos ha surgido la necesidad de incluir un la funcionalidad de poner un User Control a pantalla completa.

Después de hablar con un compañero que sí tiene más experiencia que yo en estos menesteres me sugirió que siguiera estos pasos:

  1. Crea una nueva ventana ("Window") que contenga sólo un grid con un nombre, por ejemplo "fullScreenGrid".
  2. Define una función pública que reciba como parámetro el user control que tu quieres y añade el user control como hijo de ese grid: fullScreenGrid.Children.Add( tuUserControl )
  3. Y a correr.

Con esto en la cabeza, lo he hecho y lo hemos conseguido. Sólo hay que tener en cuenta que ántes de añadirlo a la ventana nueva, hay que eliminar el user control de la ventana principal para que podamos cambiar el user control de padre, ya que si no lo hacemos, nos saltará la excepción InvalidOperationException con el mensaje "El elemento especificado ya es el elemento secundario lógico de otro elemento. Desconéctelo primero"

También he tenido que añadir un botón en la ventana que está a pantalla completa para poder salir del modo "Full Screen". Además, para que la ventana esté ha pantalla completa, hay que setear las propiedades WindowStyle a None y WindowState a Maximized para no mostrar la barra con los botones de maximizar, minimizar y cerrar y para que esté maximizada.

Para que podáis ver cómo funciona os dejo un ejemplo de código con un proyecto completo con todo lo necesario y comentado para que lo veáis más claramente: WPF Full Screen Sample

El resultado después de compilar y ejecutar el ejemplo debe ser algo parecido a esto:

Ventana principal

Y cuando hagamos click en el botón de "Go to full Screen":

User Contorl a pantalla completa

¿Habéis tenido que hacerlo alguna vez? ¿Cómo lo habéis hecho?

¿Es realmente un truco?

Juan María Laó Ramos.

[Evento] HTML Tour 2014

En Plain Concepts estamos que no paramos.

No ha terminado el Wave Tour y ya hemos empezado un año más el HTML Tour 2014

HTML Tour

En las siete sesiones preparadas veremos cuáles son las ventajas de HTML 5, javascript y en petí comité veremos qué es lo que hemos estado haciendo en Plain Concepts, cómo hemos aprovechado las ventajas de esta tecnología y veremos el resultado de los proyectos reales que están en producción.

Sinceramente, alucino con las cosas que son capaces de hacer los compañeros, con los que he tenido el privilegio de trabajar.

Aquí tenéis la agenda. En Sevilla estarán el día 24 de Abril, podéis registraros aquí.

Y los fieras que nos darán las sesiones:

ALFREDO FERNÁNDEZ

Alfredo ha estado desarrollando durante unos 6 años, utilizando tecnologías Microsoft y en gran medida centrado en tecnologías web y patrones de desarrollo, está muy interesado en Asp.Net MVC y HTML5, pero también tiene una amplia experiencia en WPF. Es uno de los coordinadores de SecondNug, uno de los principales grupos de usuarios. NET de España y colabora con diversas iniciativas para crear eventos de alta calidad en todo el país.

DAVID GARCÍA

David García uno de los especialistas del equipo Web de Plain Concepts. Ha participado en proyectos como La Cura y el Training Center de la web de la película Prometheus (proyecto ganador de un FWA), proyecto para el cual creó, junto a otros compañeros, la librería WaveJS, la cual nos permite pintar 3D en canvas 2D.

LUIS MIGUEL JIMÉNEZ

Luis Miguel Jiménez lleva varios años trabajando como diseñador gráfico y gracias al avance de las tecnologías de desarrollo web (HTML5 y CSS3) su carrera da un giro hacia el diseño y la maquetación web donde descubre un nuevo mundo de posibilidades a las que poder aplicar los conocimientos en diseño.

MANUEL MARTÍNEZ

Manuel Martínez es un apasionado de las tecnologías web, empezó como desarrollador de PHP y actualmente pertenece al equipo web de Plain Concepts, donde trabaja habitualmente con ASP.NET MVC y JavaScript.

QUIQUE MARTÍNEZ

Quique Martínez actualmente trabaja en Plain Concepts como Senior Software Developer Engineer. Es un apasionado de la #ArquitecturaDeSoftware y del #CloudComputing, en concreto #WindowsAzure.En esta última ha sido nombrado #MicrosoftMVP y además pertenece a los #AzureInsiders.

Enlaces de interés 2

Aquí va la segunda entrega de los enlaces que he visto esta semana y quería compartir con todos:

Happy and cool coding!

Enlaces de interés

Bueno, voy a comenzar con una pequeña colección sobre enlaces que voy encontrando por ahí emulando a un amigo.

- Why agile has failed. Scott Bellware

- Scott Hanselman's Complete List of Productivity Tips. Scott Hanselman

- 10 cosas a hacer para securizar tus datos. Scott Hanselman.

- Nueve técnicas para transmitir una imagen positiva que te ayude a conectar con la audiencia. El Arte de Presentar.

- Software Testing with Visual Studio 2012 Jump Start. Microsoft Virtual Academy

- Tests unitarios y dependencias.  Juan María Hernández

- Aprendiendo TDD con C#

 

El enésimo post sobre el Singleton (UPDATE 1)

La cosa es que el Singleton hace dos cosas:

- Se asegura de que sólo haya una instancia del objeto.

- SomeStuff()

El problema de hacer dos cosas es que viola la S de los principios Solid: Single Responisability Principle. Y esto hace que no sea fácilmente testeable.

Cuando quiero hacer que sea testeable quito el Singleton y lo sustituyo por una factoría, una clase estática y una clase que hace la funcionalidad de SomeStuff.

Aquí tenéis un ejemplo simple:

public static class Singletons
 {
     private static Factoria fact = new Factoria();

     public static void HazLoTuyo()
     {
         fact.GetUnicaInstancia().DoStuff();
     }
 }

 public class Factoria
 {
     private Clase unicaInstancia;

     public Factoria()
     {
         unicaInstancia = new Clase();
     }

     public Clase GetUnicaInstancia()
     {
         return this.unicaInstancia;
     }
 }

 public class Clase
 {
     public Clase()
     {
     }

     public void DoStuff() { }
 }

De esta manera puedo testear la clase Clase sin preocuparme de que sólo hay una instancia de ella en el sistema.

Es por esto que me asalta la duda, ¿no será el Singleton un antipatron?

¿Cómo lo veis vosotros?

[Update 1]

Gracias a los comentarios voy a ir actualizando el post con algunas conclusiones y dudas que se me plantean.

Resumiendo un poco los comentarios, cuando sólo queremos una instancia de nuestra clase Clase (definida más arriba) suele ser buena idea usar un inyector de dependencias y registrar nuestra clase para que el inyector nos devuelva siempre la misma instancia.

De esta manera "invertimos el control" de la instanciación de nuestra clase, y podemos testearla de manera aislada.

¿Pero que pasa si no queremos meter un inyector de dependencias por el motivo que sea?

Podríamos meter una clase parecida a esta:

 public class ClaseFachada
 {
     private static Clase clase = new Clase();

     public static void DoStuff()
     {
         clase.DoStuff();
     }
 }

De esta manera podemos usarla en nuestro código de esta forma:

ClaseFachada.DoStuff();

Como si fuese un Singleton, pero evitando el típico Clase.Instance.DoStuff(). La cosa es que si estamos desarrollando una librería y queremos que nuestra librería se use así.

¿Os parece adecuado? ¿Cómo lo mejoraríais?

[Evento] Wave Engine University Tour

Wave Engine University TourA partir del 17 de Marzo comenzaremos un Tour que nos llevará por un montón de universidades españolas para enseñar Wave Engine.

Wave Engine es un motor gráfico multiplataforma y gratuito, en continua evolución añadiendo cada día nuevas funcionalidades. Y además soy miembro del equipo de desarrollo :).

El propio equipo será el encargado de impartir el taller para ayudarte a introducirte en el desarrollo de videojuegos o, si ya estás en el mundillo, para enseñarte todo lo que Wave Engine puede aportar a tus juegos y cómo puede facilitarte la vida.

También habrá premios para los que lleguen a publicar juegos en la Store de Windows 8 y/o Windows Phone. Y muchas sorpresas más.

¡NO TE LO PUEDES PERDER! Busca tu ciudad y regístrate aquí.

P/D: Los que me conocéis, sabréis enseguida quién fue la musa del diseñador del cartel ;).

Difundid y  compartid por las redes sociales. Y gritad por la calle que Wave Engine está de gira.

monos alados

PERO SOBRE TODO PARTICIPAD

TFS, Xamarin y MSTests

Hace un tiempo vimos un pequeño truco para poder ejecutar tests en las builds de TFS para proyectos Windows Phone.

Me ha sido necesario hacer lo mismo con proyectos con Xamarin Android y Xamarin iOS y aquí os pongo mi experiencia y cómo lo he resuelto. Sigue leyendo

Qué es lo que no hay que hacer en ASP.NET, y qué hacer en su lugar

Vamos a ver varios errores que se suelen cometer en proyectos ASP.NET. Veremos algunas recomendaciones de qué deberíamos hacer para no caer en esos errores. Está basado en una presentación de Damian Edwards en el Norwegian Developers Conference. Sigue leyendo

Windows Azure: Release de Windows Azure SDK 2.2 (y sus chuladas)

Ya está publicada la nueva release de Windows Azure SDK 2.2. En esta release se han incluido un gran número de características:

  • Soporte para Visual Studio 2013.
  • Se ha integrado el Sign-In de Azure en Visual Studio.
  • Debugging remoto de servicios cloud con Visual Studio.
  • Soporte de administración de Firewalls en Visual Studio para bases de datos SQL.
  • Imágenes de máquinas virtuales con Visual Studio 2013 RTM para suscriptores MSDN
  • Windows Azure Managemente Libraries for .NET
  • Se han actualizado los Windows Azure PowerShell Cmdlets y ScriptCenter Sigue leyendo

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

StyleCop

StyleCop, TFS y Nuget

StyleCop es una herramienta que analiza nuestro código para ver si se cumplen un conjunto de reglas y estilos de codificación.

Por resumir un poco, el equipo que lleva el proyecto de StyleCop ha identificado un estilo y conjunto de reglas para la programación en C#. En esas reglas se define, por ejemplo, que todo método debe tener una sección de documentación, toda variable de clase debe estar documentada, etc ... Si queréis ver cuales son esas reglas por defecto no dejéis de pasaros por la sección de la documentación dedicada a ello. No voy a entrar en la discusión de si esas secciones son necesarias o no para documentar el código ;). El objetivo que se busca con este proyecto es que todo el código esté escrito de manera homogénea, evitando de un plumazo las discusiones entre los miembros del equipo del tipo: "Has vuelto a poner el { en la misma línea del if ..."

StyleCop en NuGet

Para integrarlo en nuestros proyectos, simplemente con NuGet, buscamos StyleCop:

StyleCop En Nuget

Una vez que lo instalemos los paquetes StyleCop y StyleCop.MSBuild en nuestro proyecto, si queremos que los errores que nos marca StyleCop sean errores de compilación en lugar de warnings tan solo tenemos que editar el .csproj y añadir la línea:

<StyleCopTreatErrorsAsWarnings>false</StyleCopTreatErrorsAsWarnings>

En la sección que queramos que esto ocurra, por ejemplo, si queremos que esto sólo salte cuando compilemos en debug, buscaremos la sección de configuración para ello, y la añadiremos al property group:

<PropertyGroup>
    <Configuration Condition=" '$(Configuration)' == '' ">Debug</Configuration>
    <Platform Condition=" '$(Platform)' == '' ">AnyCPU</Platform>
    <ProjectGuid>{471ADD54-6DE1-42F2-8ECD-A41C5C05029E}</ProjectGuid>
    <OutputType>Library</OutputType>
    <AppDesignerFolder>Properties</AppDesignerFolder>
    <RootNamespace>ClassLibrary1</RootNamespace>
    <AssemblyName>ClassLibrary1</AssemblyName>
    <TargetFrameworkVersion>v4.5</TargetFrameworkVersion>
    <FileAlignment>512</FileAlignment>
    <SccProjectName>SAK</SccProjectName>
    <SccLocalPath>SAK</SccLocalPath>
    <SccAuxPath>SAK</SccAuxPath>
    <SccProvider>SAK</SccProvider>
    <StyleCopTreatErrorsAsWarnings>false</StyleCopTreatErrorsAsWarnings>
    <SolutionDir Condition="$(SolutionDir) == '' Or $(SolutionDir) == '*Undefined*'">..\</SolutionDir>
    <RestorePackages>true</RestorePackages>
  </PropertyGroup>

Personalizar las reglas

Una vez que hayamos instalado StyleCop, podemos configurarlo haciendo clic derecho en el proyecto y veremos las reglas y opciones que podemos configurar:

StyleCop SettingsEsto va a generar un archivo en la raíz del proyecto llamado "Settings.Stylecop" que tenedremos que añadir al proyecto y al TFS

No es mala idea usar siempre el mismo archivo de configuración para todos nuestros proyectos, así que una vez que tengamos un archivo de este tipo podemos ponerlo en un directorio dentro del TFS y enlazarlo al archivo de nuestro proyecto en la sección de configuración de StyleCop, en la pestaña "Settings Files" de esta manera:

StyleCop Custom Rules

Esto generará un "Settings.stylecop" tan sólo con la ruta que le hemos indicado. Este archivo también tenemos que añadirlo al TFS para que se ejecute StyleCop en la nube.

Juan María Laó Ramos

Una experiencia ALM ++

En estos últimos tres meses he tenido la oportunidad de aplicar Scrum y TDD de manera estricta.

Ha sido una experiencia muy enriquecedora y la voy a compartir con todos.

En el proyecto hemos usado Team Foundation Service y Visual Studio 2012 como solución ALM con la plantilla por defecto de Scrum. Con esto solventamos varias cosas de un plumazo:

  • Gestión del Backlog
  • Definición de Sprints
  • Gestión de Tareas.
  • Gestión de Bugs.

La interacción con el cliente también la hacíamos a través de la web del proyecto.

Lo que más me llamó la atención fué lo fácil que es la gestión de bugs. Cuando el cliente encontraba un bug, lo abría y le ponía la prioridad, el scrum Master lo comunicaba en el daily scrum y nos organizábamos para ver quién lo corregía

ALM

  • Teníamos definidas varias Builds para cada parte del sistema que lanzaba una compilación y ejecución de los Test Unitarios que había para asegurar que no se había roto nada.
  • También había otra serie de Builds manuales necesarias para generar una versión para desplegar en los distintos entornos Desarrollo, Pre-producción y Producción.

La verdad que esto de no salir de Visual Studio para crear un sistema es una bendición. En su día integré Jenkis, Trac y Subversion en un proyecto en .NET, me maravillaba lo que se podia hacer con estas herramientas. La verdad es que me costó un tiempo montarlo y después mantenerlo.

Y en una conversación con el Scrum Master me soltó esto:

“Luego te llegan los empalmados que si Subversion, Jenkins, Jira, Trac, Bugcilla, que es gratis. Si estás desarrollando en .NET, el intentar integrar todo eso para que funcione con .NET es posible, pero es cuestión de tiempo y dinero”

Y en estos tres meses de trabajo, le habremos dedicado 40 horas a estos temas (daily scrums incluidos) y todo sin salir de Visual Studio.

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?

[Evento CartujaDotNet] Wave Engine

Wave EngineImagina que quieres hacer un juego, pero sólo quieres programarlo una vez y desplegarlo en la mayoría de plataformas posibles.

Deja de soñar y aprende a usar Wave Engine y podrás desplegar tus juegos en iOS, Android, Windows 8 y Windows Phone.

Los grandes Marcos Ligthyear y David Woody nos enseñarán todo lo necesario (y quizás algo más ... ) para empezar a sacarle partido a Wave.

¿Dónde y cuando?

En el Cloud Pointing de Sevilla.

c\ Biología, 12, Edificio Vilamar 2, 3ª Planta
Parque Empresarial Nuevo Torneo
41015 Sevilla

El Jueves 23 de Mayo de 19:30 a 21:30.

Aquí tenéis juegos reales hechos con Wave Engine. Y estas son  unas cuantas demos tecnológicas.

¿Te lo vas a perder? Pues regístrate aquí

Microsoft Sync Framework 2.1 (COM Error 80040154 Class not registered)

He tenido que trabajar en un proyecto para sincronizar tanto bases de datos como blobs con Azure , Microsoft Sync Framework y Worker Roles.

Nota: Ibon Landa nos explica qué es un worker role de Azure aquí.

La cosa es que una vez instalado Microsoft Sync Framework y empezar a trabajar con él, estaba obteniendo una excepción que no entendía muy bien:

{"Retrieving the COM class factory for component with CLSID {EC413D66-6221-4EBB-AC55-4900FB321011} failed due to the following error: 80040154 Class not registered (Exception from HRESULT:

0x80040154 (REGDB_E_CLASSNOTREG))."}

La máquina en la que suelo trabajar es una máquina x64, con el sistema operativo también en x64.

Tras un tiempo buscando por google pude llegar a la conclusión que no estaba encontrando el componente de Sync Framework. Tras comprobar que estaba todo instalado no conseguía averiguar cuál era el problema.

Ya desesperado me dio por pulsar en la segunda página de resultados de google y ahí estaba: Sync Framework 2.1 Com Error

La cosa es que como tenía un proyecto de test para probar las clases que iba creando, resulta que Visual Studio se ejecuta siempre en modo x86, y como los test se lanzan desde Visual Studio, no estaba encontrando las librerías correspondientes.

La solución

Instalar los componentes x86 de Sync Framework y problema resuelto.

Espero que sirva.

Juan María Laó Ramos

PlainConcepts

Plain Concepts Cloud Tour

Desde Plain Concepts nos invitan a un evento bastante interesante sobre tecnologías Cloud: http://www.plainconcepts.com/cloudtour/

Nos hablarán  sobre todo de qué opciones tenemos de usar el Cloud si no trabajamos con tecnologías Microsoft, aquí teneís los principales temas de los que se hablará:

  • IaaS - Linux, Máquinas y Redes Virtuales
  • PaaS, trabajando con Java y Eclipse
  • PHP y Azure Web Sites
  • Almacenamiento en la nube – SQL, NoSQL
  • Big Data y Hadoop
  • Desarrollo de backends para el desarrollo de aplicaciones móviles

El evento es a nivel nacional. Aquí tenéis los diferentes lugares, fechas y enlaces de registro:

¿Te lo vas a perder?