Meritocracia y sus consecuencias

Voy a generalizar a lo bruto, así que disculpen si se sienten ofendidos. Creo que en España nos movemos por ser amigo de para conseguir las cosas, y el mérito y sus consecuencias no se tienen en cuenta. Creo que en el mundo del software libre es necesario aplicar esta filosofía, no debe destacar este por ser mi amigo, si no porque ha realizado más trabajos que otro. Además, que tu trabajo hable es bueno, es algo objetivo y no subjetivo, no influenciados por juicios de valor que deberían quedar en lo privado.

Así la meritocracia según la Wikipedia es:

es una forma de gobierno basada en el mérito. Las posiciones jerárquicas son conquistadas con base al mérito, y hay una predominancia de valores asociados a la capacidad individual o espiritu competitivo tales como, por ejemplo, la excelencia en educación o deportes.

En una comunidad de software puede ser una vara de medir, el número de tickets cerrados, las incidencias comunicadas, los artículos escritos, las charlas dadas… No es una sociedad igualitaria, pero si se entiende que todos somos iguales, porque todos podemos cerrar tickets, comunicar incidencias, etc … lo cierto es que es algo realmente fácil y basado en el trabajo.

Las consecuencias del mérito

Las consecuencias son básicamente de visibilidad, tu trabajo habla aunque tú no estés, y esto te pone en el foco de críticas. Las criticas te llueven, las opiniones sobre tí intentan influenciarte de que puede que estés haciendo algo mal trabajando y haciendo cosas. Esta frase de la Biblia refleja claramente esta idea:

Obras son amores y no buenas razones.

Seguid currando, que el mérito de vuestro trabajo hable y quien se quiera unir que se una, pero para trabajar y ser feliz, no para incordiar y no hacer nada.

 

 

Anuncios

Los errores de Gnome

Me encanta el proyecto Gnome, desde siempre he estado enamorado de él, era tener como un Mac pero de bajo precio y además podías tocar el código fuente, había una comunidad y era usable, cada vez más rápido y cada vez más bonito.

Pero se lio parda, la decisión de revolucionar Gnome con Mono supuso una fragmentación en la comunidad, Mono acabó por su lado y Gnome por otro con lo que años de esfuerzo se diversificaron. Y salió Gnome 3, bello, nuevo… pero de nuevo revolucionario. Rompía con el pasado, y en vez de sumar restaba, después Unity, después un fork por parte de Linux Mint y ahora fuera de Debian, la distribución que lo hizo grande. ¿y todo esto porqué?

El porqué, por factor ideológico, para muchos es más importante la licencia, que los usuarios, la pureza del código que la funcionalidad que se desarrolla. Y es más importante hacer la paja mental del momento que el no romper con el pasado y evolucionar. No revolucionar, evolucionar a buen ritmo.

Me acuerdo de la Guadec de Sevilla de hace unos años, se preguntaron donde estaban los usuarios, y claro, yo lo tenía claro quejándose de Guadalinex. En vez de utilizar este feedback para poder enfocar su desarrollo, se quejaban de la falta de participación de estos. Además, no es un dato objetivo, pero también ha bajado el número de voluntarios a la hora de codificar nuevas funcionalidades.

Falta una cabeza visible que lidere el proyecto, la ida de Miguel de Icaza se nota, la falta de coherencia se nota, no todo se resuelve en asamblea votando.

Complementos para MonoDevelop: acciones para archivos

Introducción

MonoDevelop es el IDE con una arquitectura orientada a los complementos. El elemento primario es el Addin o complemento que a elección del programador  del usuario es utilizado para su uso.

En este artículo vamos a ver un detalle de las plantillas para proyectos en MonoDevelop. En concreto las acciones sobre los archivos que contienen por defecto estos proyectos.

Plantillas en MonoDevelop

Las plantillas en MonoDevelop son de dos tipos, las plantillas para archivos y las plantillas para proyectos. En ambos casos son archivos XML que contienen los metadatos necesarios para que MonoDevelop trabaje con ellos. Entre estos metadatos están los que permiten trabajar con archivos, así la etiqueta File permite integrar en el archivo XML el archivo que integre el proyecto.

 

Los atributos que admite el atributo File son los siguientes:

  1. Name: es el nombre del archivo. Si se incluye un archivo llamado Main que tiene la extensión .cs, el nombre del archivo será “Main.cs”.
  2. DefaultExtension: es la extensión del archivo. Si tenemos un extensión .json, la información que incluirá este atributo sera “.json”.
  3. BuildAction: las acciones es un tema más amplio que veremos en el siguiente apartado. Son heredadas de Visual Studio.

BuildActions: acciones de construcción sobre los archivos.

En el artículo enlazado en [1] podemos ver que hay 5 tipos de acciones sobre los archivos que se incluyen en un proyecto:

  1. Compile: el archivo será compilado.
  2. EmbeddedResource: se agregará como un recurso, por ejemplo, dentro de la carpeta  Resources.
  3. None: no hará ninguna acción especifica.
  4. Content: dentro de los proyectos ASP.NET 
  5. Page: para los proyectos basados en Moonlight.
En la imagen que hemos visto sobre la plantilla para un proyecto podemos ver que se ha seleccionado la acción None, es decir no hacer nada.

Bibliografía

[1] – http://mjhutchinson.com/journal/2011/03/monodevelop_tips_build_actions

[2] – http://upload.wikimedia.org/wikipedia/commons/f/ff/MonoDevelopLogo.png

 

 

Un fin de semana con ChromeOS: Viernes 25 de Noviembre por la noche

Estoy leyendo documentación sobre ChromeOS, entre ella, que el plazo para el concurso finaliza el 20 de Enero, como podeis comprobar especialmente dirigido a estudiantes universitarios que por esas fechas empiezan sus exámenes.

Lo primero que he hecho ha sido entrar en la página web del concurso y he inscribir la aplicación. Se supone que de esta manera ya concursamos, algo realmente cutre ya que es un formulario hecho con Google Docs y deja que desear, no parece nada profesional e incluso da que pensar que sea un timo. En cualquier caso prosigo, y paso a la página para realizar los primeros pasos:

1.- Crear un icono con las medidas que indican.

2.- Subir capturas de pantalla: si ni la he empezado por dios, esto es empezar la casa por el tejado.

Y hablan de Appmator que sirve para publicar las aplicaciones para Google Chrome Web Store: http://www.appmator.com/ además permite configurar una aplicación de manera rápida y efectiva. Genera el archivo de Manifiesto de nuestra aplicación con los valores necesarios.

Empezando con TDD en Javacript

Para realizar la aplicación voy a utilizar la metodología TDD, Desarrollo Orientado a Pruebas. Para Javacript desconozco si hay algo pero he encontrado estos dos artículos que he leido para ponerme a empezar:

1.- TDD en Javascript (I) – http://www.etnassoft.com/2011/02/10/tdd-en-javascript-1/

2.- Haciendo pruebas con QUnit – http://www.etnassoft.com/2011/02/01/qunit-testeando-nuestras-aplicaciones-javascript/

El uso de QUnit es bastante intuitivo, simplemente hay que añadir la línea que llama al script en una página web estandar y empezar a escribir las pruebas.

Mañana continuaré.

 

 

 

NUnitLite–TDD en MonoDroid

Introducción

TDD o el Desarrollo Orientado a Pruebas es una metodología que ha llegado para quedarse. Esta metodología, como breve explicación, se resume en 3 pasos: primero se hacen las pruebas, después de codifica y diseña para que esas pruebas den un resultado positivo y por último se refactoriza, es decir, se hacen los cambios oportunos para mejorar el código.

Bajo MonoDroid esto no es posible a nivel de emulador, hasta que hace poco que el programador @SpiritMachine ha liberado NUnitLite. Para obtener la última versión de NUnitLite podemos acudir a su cuenta de GitHub [1].

El resultado es que la aplicación mostrará si pasa los test o no en el dispositivo, real o virtualizado, como se ve en la imagen inferior.

 

image

 

Preparando nuestra aplicación para usar TDD

con NUnitLite para MonoDroid

 

Creamos un nuevo proyecto con Visual Studio 2010 para MonoDroid,y agregamos la referencia a NUnitLite.MonoDroid.

 

image

Las pruebas las incluimos en la propia aplicación en forma de TestFixture.

Conclusión

Ya podemos probar la capa de presentación de nuestra aplicación para Android de manera cómoda y efectiva, seguiremos viendo la evolución de este Framework de pruebas.

 

Referencias

[1] – https://github.com/SpiritMachine/NUnitLite.MonoDroid

EMHO – El proyecto Gnome necesita que vuelva Miguel de Icaza

Tras instalar Gnome 3 en mi distribución de Linux favorita, el cambio me impactó por ser espectacular. Efectos de transiciones entre espacios, actividades, nueva forma de interactuar con el usuario y cambios a nivel de código. Nuevos lenguajes de programación: Vala, Genie. Incorporación de la introspección para simplificar los binding de los lenguajes, todo realmente bien pensado para… ¿quién?

En la fiesta de celebración de la llegada de Gnome 3 estuve como espectador, he de reconocer que éramos pocos en la sala y la autocrítica también estaba ausente. El gran criticado, el usuario esa persona que veían casi lejana.

Hace falta que vuelva Icaza, hace falta que vuelva la orientación al usuario.

ASP.NET MVC 3: Layouts con Razor

Introducción

Este es un documento de trabajo para aprender como funcionan las capas en Razor. Sin más comienza el post.

Layouts con Razor

 

Las Layout views son las mater pages de razor. Usa los métodos RenderPage, RenderBody, RenderSection para dibujar la página. En el enlace [1] se pueden ver varios ejemplos de desarrollo.

En el código fuente siguiente podemos ver el uso de RenderBody:

<!DOCTYPE html>
<head>
<title>@ViewBag.Title</title>
<script src=”@Url.Content(“/Scripts/jquery.js”)” type=”text/javascript”></script>
</head>
<body>
@RenderBody()
</body>
</html>

Usando RenderSection

RenderSection se utiliza para indicar que una parte de la página va a contener una capa determinada, el método utiliza dos atributos, nombre de la Sección y un booleano. Una llamada de ejemplo puede ser la siguiente:




Declarando secciones

Las secciones se declaran con la directiva @Section NOMBRE-DE-LA-SECCION. Y entre llaves el código de la sección. Por ejemplo:


@Section Footer{
	Esto es el pie de página
}

Comentarios dentro de los layouts

Para realizar comentarios dentro del código de las layouts, utilizaremos arroba asterisco @* para iniciar el bloque de comentarios y para finalizarlo utilizaremos asterisco arroba *@ .

Localización de las Capas en el proyecto

Las capas se guardan dentro de la carpeta Shared,que a su vez está dentro de la carpeta Views.

Nombrado de las capas

Todas las capas comienzan por el carácter guión bajo _ y contienen la extensión cshtml.

Vista Inicial

Para indicar cual es la vista que se va a cargar utilizaremos el archivo _ViewStar.cshtml, contiene dentro una directiva para indicar la capa de inicio.

@{
	Layout="RUTA-DE-LA-CAPA-NOMBRE-DEL-ARCHIVO-EXTENSION-DOTCSHTML";
}

Enlaces:

[1] – http://www.dotnetcurry.com/ShowArticle.aspx?ID=636

Traducción: Mono.Addins – Punto de Extensión y Extensiones

Introducción

Este artículo es una traducción del original disponible en [1], las licencias aplicadas al original se aplican a la traducción.

mono-logo

La traducción

Una aplicación basada en Mono.Addins se compone de:

  1. Una aplicación huésped (o un huésped de complementos (add-in)), que contiene varios puntos de extensión (extension points).
  2. Varios complementos, que extienden los puntos de extensión del huesped (host)

Implementando un huesped de complementos

El código inmediatamente inferior es un ejemplo básico de una aplicación que contiene complementos, es decir, hace de huésped de complementos. Esta aplicación ejecuta un conjunto de comandos que pueden ser implementados como complementos (add-in).

   1:  using System;
   2:  using Mono.Addins;
   3:   
   4:  [assembly:AddinRoot ("HelloWorld", "1.0")]
   5:   
   6:  class MainClass
   7:  {
   8:      public static void Main ()
   9:      {
  10:          AddinManager.Initialize ();
  11:          AddinManager.Registry.Update ();
  12:          
  13:          foreach (ICommand cmd in AddinManager.GetExtensionObjects<ICommand> ())
  14:              cmd.Run ();
  15:      }
  16:  }

.csharpcode, .csharpcode pre
{
font-size: small;
color: black;
font-family: consolas, “Courier New”, courier, monospace;
background-color: #ffffff;
/*white-space: pre;*/
}
.csharpcode pre { margin: 0em; }
.csharpcode .rem { color: #008000; }
.csharpcode .kwrd { color: #0000ff; }
.csharpcode .str { color: #006080; }
.csharpcode .op { color: #0000c0; }
.csharpcode .preproc { color: #cc6633; }
.csharpcode .asp { background-color: #ffff00; }
.csharpcode .html { color: #800000; }
.csharpcode .attr { color: #ff0000; }
.csharpcode .alt
{
background-color: #f4f4f4;
width: 100%;
margin: 0em;
}
.csharpcode .lnum { color: #606060; }

Este código muestra declaraciones e inicializaciones que tienen que hacerse en todas las aplicaciones extensibles:

  • El atributo [AddinRoot] aplicado a un ensamblado indica que ese ensamblado es un huésped de complementos. Todos los proyectos que incluyan gestión de complementos tendrán un identificador y una versión.
  • La llamada al método AddinManager.Initialize se encarga de inicializar el administrador de complementos (AddinManager). Ante de realizar cualquier operación con la clase AddinManager hay que realizar esta llamada.
  • Cuando se realiza la llamada al método AddinManager.Registry.Update, el motor de complementos inspeccionará la carpeta donde está alojada la aplicación (y otras carpetas indicadas por el programador) buscando complementos, esto actualizará el registro de complementos (add-in registry) que almacena la información sobre los complementos.
  • La llamada al método AddinManager.GetExtensionObjects se puede entender como una consulta a los puntos de extension. Devuelve una lista de objetos registrados en un determinado punto de extensión.

Para completar el ejemplo anterior deberemos declarar los puntos de extensión.

Declarando puntos de extensión

Los puntos de extensión se declaran como indica el siguiente código:

   1:  using Mono.Addins;
   2:   
   3:  [TypeExtensionPoint]
   4:  public interface ICommand
   5:  {
   6:      void Run ();
   7:  }

El atributo [TypeExtensionPoint] cuando se le aplica a una clase o a un interfaz indica que un punto de extensión acepta objetos de ese tipo. En el ejemplo, hemos creado un punto de extensión para los objetos que implementan el interfaz ICommand.

Implementando un Complemento (add-in)

Un complemento extiende un punto de extensión de la siguiente manera:

   1:  using System;
   2:  using Mono.Addins;
   3:   
   4:  [assembly:Addin]
   5:  [assembly:AddinDependency ("HelloWorld", "1.0")]
   6:   
   7:  [Extension]
   8:  public class HelloCommand: ICommand
   9:  {
  10:      public void Run ()
  11:      {
  12:          Console.WriteLine ("Hello World!");
  13:      }
  14:  }

.csharpcode, .csharpcode pre
{
font-size: small;
color: black;
font-family: consolas, “Courier New”, courier, monospace;
background-color: #ffffff;
/*white-space: pre;*/
}
.csharpcode pre { margin: 0em; }
.csharpcode .rem { color: #008000; }
.csharpcode .kwrd { color: #0000ff; }
.csharpcode .str { color: #006080; }
.csharpcode .op { color: #0000c0; }
.csharpcode .preproc { color: #cc6633; }
.csharpcode .asp { background-color: #ffff00; }
.csharpcode .html { color: #800000; }
.csharpcode .attr { color: #ff0000; }
.csharpcode .alt
{
background-color: #f4f4f4;
width: 100%;
margin: 0em;
}
.csharpcode .lnum { color: #606060; }

Los complementos se desarrollan en ensamblados diferentes, tienen que estar marcados con el atributo [Addin] para ser reconocido como un complemento. Los complementos tienen que indicar a que huesped extienden utilizando el atributo AddinDependency, indicando el id del huesped o complemento y el número de versión.

Mediante la aplicación de la [extensión] atributo a una clase que se declara una nueva extensión del nodo que tipo que se agrega a un punto de extensión. El punto de extensión se determina observando la tipos base e interfaces de la clase. Así que en este ejemplo, la clase implementa la ICommand interfaz, y hay un punto de extensión definida para esa interfaz, por lo que es la extensiónpunto en el que el tipo se registrará. Si una clase implementa varias interfaces, podemos seleccionar el punto de extensión, especificando el nombre del tipo en el atributo, por ejemplo: [Extensión (typeof (ICommand))].

Copiado y Pegado:¿Todavía crees en los mitos? – Carlos Blé

Así que crees que tal o cual persona es un super gurú venido de otra galaxia como los personajes de Dragon Ball… claro…. te crees el mito y eres fan de tal persona, le idolatras. Amigo, tienes que madurar.

Nadie es mejor ni peor que tú. Nadie es mas ni menos especial que tú. Si todavía no lo ves, tienes que seguir madurando. Todos tenemos que seguir madurando, pero en lo que respecta a las expectativas que te creas de los demás, te invito a que las deseches.

Todos tenemos cosas relativamente únicas y a la vez todos somos iguales. Lo que realmente tiene magia es la interrelación y la colaboración. Entre todos, entre un equipo, las cosas sí salen adelante como por arte de magia y el grado de satisfacción es realmente sano.

Ultimamente voy a sitios donde no conozco a gente que ha oído hablar de mí y cuando me dicen que soy famoso o que soy un gurú me entra la risa.El efecto es el siguiente: cuando sólo han oído hablar de mí, recibo un trato especial, halagos y expectación. Cuando les digo a la cara que no soy mas listo ni más capaz que ellos y muestro mis fallos, entonces paso de ser una estrella a ser una mierda. Es la caída desde la alta expectativa. ¡ni una cosa ni otra!

No debemos evaluar a las personas por lo que dicen de ellas, los rumores son perversiones de la realidad. Me gustaría que me reconociesen por mi trabajo, por las ganas que le pongo y por tratar de mejorar, sobre todo cuando me equivoco. No que me tomen por lo que no soy cuando me conocen y luego me infravaloren cuando digo que soy como cualquier otro, que sólo trato de vivir la vida como voy entendiendo que quiero y puedo hacerlo. Escribo y hablo en público porque me gusta compartir, porque donde yo vivo no hay trabajo para que me quede quieto en casa. Si quiero hacer lo que me gusta tengo que moverme, ser activo. Ser un famosillo no es el objetivo, no debería serlo para nadie con mas de 15 años. Creer en famosillos tampoco. Cree en tí mismo.

Ultimamente está habiendo un movimiento curioso en la comunidad Agile-Spain y con el tema de la artesanía, que parece resaltar la figura del gurú todo-poderoso. Se piensa que determinadas personas son mágicas y aparecen fans por todas partes. Es un punto de vista erróneo (como siempre en mi opinion, que para eso es mi blog). El verdadero ideal de la artesanía del software es el de ser más profesionales, hacer mejor el trabajo, ponerle toda la atención posible y mejorar constantemente.
Paradójicamente, las técnicas ágiles se han inventado para hacer frente a nuestras limitadas cualidades intelectuales mediante disciplina, potenciando el trabajo en equipo, la participación. Y alguna gente anda pensando que se trata de seguir a un tío que sabe más que nadie y que tiene una barita mágica para iluminarnos. Wrong!

Tenemos que madurar y dejar de creer en cuentos. A mayor expectativa, mayor decepción. Lo que estamos persiguiendo es la excelencia técnica a través de la motivación de las personas, con ayuda de la comprensión, la empatía, la paciencia, constancia y el sentido común. La figura del “crack” no me pega para nada con las metodologías ágiles. Paradójicamente algunos se lo creen.

Alguna gente me dice que si sigo diciendo que soy normal y corriente perderé la fama de mito. ¡ojala! lo que quiero es ser reconocido como profesional, como currante, con ganas y buena voluntad. No me voy a cansar de repetir de que estoy continuamente aprendiendo y que me sigo metiendo buenas cagadas con desarrollos y con tantas otras cosas. Gracias a los métodos ágiles, cada vez voy equivocandome antes y así, readaptando y mejorando. Eso es la agilidad en mi opinion.

Los que están en esa posición de ser admirados deberían utilizarla para ayudar a los demás a sentirse más felices consigo mismos, con su vida profesional e incluso personal. Es cómodo acostumbrarse a los halagos y vivir en la nube, pero es engordar el ego para bien de nadie. Cuando te mueras, no te vas a llevar nada de eso. Quedará de tí lo que dejases en los demás.

Desgraciadamente parece que esta idea de que el desconocido y el extranjero son más que uno, es muy española. Como digo, lo peor es luego el efecto rebote. Cuando voy a trabajar como mentor y coach a las empresas, el efecto es muchísimo mayor cuando les han hablado bien de mí. Cuando entro por la puerta y me han vendido como una estrella, la gente escucha atentamente lo que digo y me hacen caso sin conocerme de nada. Si me conocen no me valoran. En un sitio donde nunca me han visto como Huesca, hacemos un dojo y se llena hasta la bandera. En Canarias les digo a los amigos del grupo que les doy un curso de TDD gratis y pasan del tema. Total como ya echamos las birras juntos… (ojo, no digo que mis amigos del grupo agile-canarias no me tengan estima).
Por exceso o por defecto, no hay una correspondencia con como creo que debería de ser. Hay que intentar aprender de todos, aprovechar lo bueno de cualquiera, y cuando alguien te presta ayuda, ser agradecido. Sea famoso, o sea tu peluquero.

Las personas de agile-spain con las que mejor me llevo son las que me han tratado exactamente igual antes de conocerme que despues de jartarnos de birras juntos o de ver código malo mío. Intentamos aprender unos de otros sin envidias ni exaltaciones.

La naturaleza de nuestro ego es querer sentirse distinto y especial, es humano. Por es la gente está orgullosa de pertenecer a una comunidad como agile-spain, porque creen que eso les convierte en algo diferente hacia mejor. Sin embargo, no veo nada distinto en agile-spain a lo que veía hace 10 años en las comunidades de usuarios de linux. Algunos buenos profesionales y algunos que necesitan madurar algo más que otros. Por esto la palabra “agile” suena mal en algunos ambientes, porque ha pasado a ser dogma (bueno, también porque la han usado pero luego no tenían ni idea de “agile”). Estar en la comunidad agile-spain no te hace mejor profesional. Demuestralo con tu trabajo, demuestralo siendo mejor compañero.
Cuando hablo con un cliente que no ha oído nada de “agile”, no voy diciendole “agile”, “scrum”, “tdd”… le hablo de valores. De entregas tempranas e iterativas. De colaboración, de valor, de satisfacción para el cliente.

Nos pasamos la vida comparando a los demás con uno,… “más listo”, “más tonto”, “más guapo”, “más feo”… cuando en realidad no hay mejor sensación que la de ver que los otros son capaces de sentir como uno, y viceversa. Sentir que somos iguales.

Para que las metodologías ágiles o cualquier otras pongan a nuestra profesión en el lugar que merece, tenemos que madurar nosotros primero. Dejarnos de pajas mentales y trabajar duro. En equipo, con humildad, con ilusión, sin límites mentales.

Enfrentándome a código legado (finalmente no es así)

Finalmente no es así, me enfrentaré a dos tipos de proyectos pero con desarrollos completamente nuevos y utilizando los últimos avances de las tecnologías Microsoft. Creo que he tenido suerte, me voy a encontrar dentro de una pequeña empresa, con buen ambiente de trabajo, y todo más cercano al concepto de Startup que al de factoría de software, del que soy crítico desde mi postura personal y con conocimiento de causa.

Desean aplicar metodologías ágiles, y están empezando a usar Scrum, y son personas humildes y trabajadoras, que es lo principal, nadie es más que nadie y el error es un paso más hacia la mejora contínua, un éxito o un fracaso no te define como profesional y menos como ser humano.

Ya iré contando la experiencia.

 

Posiblemente, y no hablo con total seguridad, me enfrentaré a un código legado de un equipo de desarrollo que ha utilizado MS SQL Server 2000 para la base de datos, contínua con ASP.NET 1.1 y utiliza Visual Basic .Net.

En pocos proyectos que he estado he podido partir de cero, y en pocos he podido dirigir como me hubiera gustado. Así, que en esta etapa que me voy a enfrentar de código legado, me gustaría ver que prácticas son buenas cuando el poder de decisión se anula y sólo sirve escribir código, conociendo poco de la arquitectura del proyecto y con documentación casi nula.
Lo que importa es sacar trabajo adelante, eso me dijeron en la entrevista de trabajo, y ciertamente me preocupa como esté hecho el proyecto y hasta que punto ocurran cosas incontrolables.

¿Podré utilizar TDD? He desenpolvado la máquina virtual de Windows XP con Visual Studio 2003 y he iniciado un proyecto con estas características. Así establezco que, recibiré un ticket con una información de la nueva característica a implementar, realizaré los test correspondientes, implementaré la solución y veré si pasan o no los tests, y todo esto contra sourcesafe.
Nada de servidor de integración.
Ya iré contando mis experiencias por aquí, a ver que tal sale la cosa.

A %d blogueros les gusta esto: