Angel "Java" Lopez : Desarrollo de Software, C Sharp

Escribiendo una Aplicación usando TDD (Part 6) Modificando Vistas

lopez — Sun, 07 Apr 2013 11:33:39 GMT

El post de hoy va a mostrar que, al haber usado MVC (Model-View-Controller) podemos modificar nuestras vistas, sin necesidad de tocar el código. Ni siquiera tenemos que recompilar, en muchos casos.

Primero, una novedad: he pasado el ejemplo, paso a paso, a ASP.NET MVC 4, usando Visual Studio 2010. Y también lo pasé a mi cuenta de GitHub

https://github.com/ajlopez/TddAppAspNetMvc

Vean que cada versión (cada entrega por post) está señalada por tags. La de este post es la 0.0.5. Siempre pueden ver en

https://github.com/ajlopez/TddAppAspNetMvc/commits/master

Una de las cosas nuevas que me dió esta versión de ASP.NET MVC es el soporte de Razor, ahora las vistas están escritas con Razor. Como en el anterior post, use los “wizard” de creación de vistas del propio Visual Studio, y luego las modifiqué un poco (apenas algun texto).

En el paso de este post, lo que hice fue agregar Twitter Bootstrap:

Agregué estilos y javascript que necesita Bootstrap, y armé un _viewstart.chtml que le indica a Razor que todas las vistas usan un _Layout.cshtml

Vean cómo se ve ahora la página de Subjects:

Notablemente, no toqué nada de código ni de tests. Esto muestra que hasta se puede trabajar en paralelo, o en distintos tiempos: primero se arma el código de los controladores y acciones con tests. Luego, al mismo tiempo o en algun momento, se agregan y mejoran las vistas.

Próximos posts: agregar libros, aparición de primeros servicios, modelo de negocio, etc.

Nos leemos!

Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez

TDD y Reglas de Negocio (1)

lopez — Sat, 28 Jul 2012 09:47:07 GMT

Este mes estuve trabajando como miembro de un equipo ágil, desarrollando una aplicación privada. Una de las características interesates es que el sistema permite la creación y existencia de entidades del dominio del negecio, aún cuando estén en algún estado “inválido”. El product owner quiere armar un sistema flexible que refleje la realidad del negocio, en vez de uno más estrcito que no permita ese reflejo porque no se cumple alguna regla de negocio. Pero quiere ver también cuáles son las entidades que están en estado “inválido” y por qué. Así que se le muestra (la parte de interfaz de usuario está en ASP.NET MVC) una página con lo que hemos llamado Findings: una lista de mensajes alertando sobre los estados a revisar. Por ejemplo: que tal factura tiene un importe demasiado bajo o que no tiene renglones asociados.

Me gustaría explorar el mode TDD de armar esa característica. Para conseguirlo, necesito un dominio de prueba, y en este post voy a describirlo, simplificado, para tener algo en firme sobre el que implementar los Findings.

Sea una Order. Cada Order tiene uno o más Order Item. Cada Order Item tiene un Product, Quantity, Price (Producto, Cantidad y Precio). Cada Order tiene un Customer (Cliente). Hay reglas de negocio que describen cuáles son los estados “inválidos”. Algunos ejemplos:

- Una Order para un Customer de categoría Y no puede tener un monto total que supere X.
- Una Order debe tener uno o más Order Items.
- Los Order Items deben tener una Cantidad/Quantity > 0.
- Los Order Items deben tener Precio/Price > 0.
- El Producto P debe tener Cantidad > Cantidad Mínima en cada Order Item.
- Producto P tiene un Precio, y cada Order Item que lo incluya no puede tener su Precio < Precio de Producto < 0.80.
- y así…

De esta forma, las Ordenes pueden ser creadas y persistidas sin tener que cumplir con todas las reglas. La Order no es RECHAZADA por el sistema. Solamente que hay páginas para pedir (en cualquier momento) cuáles son los Findings, la lista de las reglas que no se cumplen.

Las reglas de negocio pueden cambiar, y se pueden definir nuevas. No está definido en esta esta etapa del proyecto cómo conseguir esto: puede ser que simplemente agregando código, o escribiendo un DSL (Domain-Specific Languages) de reglas. Por ahora es un tema que no importa. En la aplicación real, el cliente final tiene programadores a disposición, así que la modificación del código sigue siendo una opción aceptable. Bien puede descubrir que 30 reglas bastan, y que no hace falta cambiarlas o se cambian cada 6 meses. Este es un tema a investigar: no siempre crear un DSL de reglas se justifica. En esta versión inicial, las reglas de negocio están en el código, compiladas. En una segunda versión, algunas reglas se aplicarán a algunas órdenes (por ejemplo, a las Orders que tienen clientes de Canadá). El Product Owner quiere tener: Findings por Order, Findings por Producto, Findings por Customer.

En esta serie de post, quiero entonces explorar y mostrar una forma de armar lo pedido, USANDO TDD. Para simplificar el ejemplo, no habrá UI ni persistencia, solamente objetos del dominio, y su grafo de relaciones. Veremos cómo, usando TDD, las reglas y su forma de ejecución van emergiendo desde los casos de uso planteados. Usaré mi cuenta en GitHub para ir compartiendo el código. Será escrito, como la aplicación original, en C#.

Nos leemos!

Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez

TDD Paso a Paso (6) La semana del panadero

lopez — Fri, 25 May 2012 22:36:09 GMT

Anterior Post

Sigamos mejorando la clase de calendario de días laborables. Quiero ahora plantear el caso:

- El sábado y domingo se trabaja
- El lunes no se trabaja

Acá en Argentina, es común que así sea la semana del panadero (aunque dado los tiempos que corren, muchos abren todos los días). Este es el test que me armé: configuro al calendario con sábado y domingo como días laborales, y lunes como no laborable. Luego se prueban esos tres días:

[TestMethod]
public void SetWeekendAsWorkingDaysAndMondayAsANonWorkingDay()
{
	WorkingDaysCalendar calendar = new WorkingDaysCalendar();

	calendar.AddDayOfWeekAsWorkingDay(DayOfWeek.Saturday);
	calendar.AddDayOfWeekAsWorkingDay(DayOfWeek.Sunday);
	calendar.AddDayOfWeekAsNonWorkingDay(DayOfWeek.Monday);

	DateTime saturday = new DateTime(2012, 3, 10);
	Assert.AreEqual(saturday.DayOfWeek, DayOfWeek.Saturday);

	Assert.IsTrue(calendar.IsWorkingDay(saturday));
	Assert.IsTrue(calendar.IsWorkingDay(saturday.AddDays(1)));
	Assert.IsFalse(calendar.IsWorkingDay(saturday.AddDays(2)));
}

Al ejecutar este código, si tenemos la clase calendario del post anterior, da en rojo, porque no tengo contemplado más que un día especial por tipo: sólo un día laborable especial, o sólo un día no laborable especial. Pero al llegar a este test, puedo implementar mejor el algoritmo interno. Llegó la hora de tener una lista de días:

public class WorkingDaysCalendar
{
	private IList<DayOfWeek> nonWorkingDaysOfWeek = new List<DayOfWeek>() { DayOfWeek.Saturday, DayOfWeek.Sunday };

	public bool IsWorkingDay(DateTime day)
	{
		if (this.nonWorkingDaysOfWeek.Contains(day.DayOfWeek))
			return false;

		return true;
	}

	public void AddDayOfWeekAsWorkingDay(DayOfWeek dayOfWeek)
	{
		if (this.nonWorkingDaysOfWeek.Contains(dayOfWeek))
			this.nonWorkingDaysOfWeek.Remove(dayOfWeek);
	}

	public void AddDayOfWeekAsNonWorkingDay(DayOfWeek dayOfWeek)
	{
		if (!this.nonWorkingDaysOfWeek.Contains(dayOfWeek))
			this.nonWorkingDaysOfWeek.Add(dayOfWeek);
	}
}

Agregué una lista interna de días no laborables, sin cambiar la interfaz pública de la clase. ¿Pero habré cumplido con lo pedido con el test? Ejecuto, y da verde. ¿Pero no habré roto algo? Ejecuto el resto de los tests, también estan en verde. En cualquier caso, seguiría trabajando hasta que todo quede en verde. Luego, vendría refactorización. Por ejemplo, no estoy conforme conque los métodos comienzen con Add. No se agregan días, sólo se informa de su carácter de laborable o no laborable. Pero bueno, eso será para otro post.

Próximos temas: refactorizar, soporte de días feriados, feriados puentes, etc…

Nos leemos!

Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez

TDD Paso a Paso (5) Lunes como día no laborable

lopez — Wed, 09 May 2012 09:11:00 GMT

Anterior post
Siguiente post

Veamos ahora otro test, que como los anteriores, nos va a obligar a implementar mejor nuestro software en construcción.

Queremos configurar, sobre la semana básica, cuáles son los días laborables y cuáles son no laborables. En el anterior post, agregué la capacidad de especificar un nuevo día laboral. Ahora, quiero poder especificar que los lunes son no laborables. Este es el test que escribí:

[TestMethod]
public void SetMondayAsANonWorkingDay()
{
	WorkingDaysCalendar calendar = new WorkingDaysCalendar();

	calendar.AddDayOfWeekAsNonWorkingDay(DayOfWeek.Monday);

	DateTime monday = new DateTime(2012, 3, 12);
	Assert.AreEqual(monday.DayOfWeek, DayOfWeek.Monday);

	Assert.IsFalse(calendar.IsWorkingDay(monday));
}

Primero, no compila. Porque usa el método no existente, AddDayOfWeekAsNonWorkingDay . Lo creo, lanzando una excepción de no implementado, ejecuto el test, y da rojo. Pongamos el mínimo código que hace que esto funcione, con algún refactor de nombre de parámetros.

private DayOfWeek? workingDay;
private DayOfWeek? nonWorkingDay;

public bool IsWorkingDay(DateTime day)
{
	if (this.workingDay.HasValue && this.workingDay.Value == day.DayOfWeek)
		return true;

	if (this.nonWorkingDay.HasValue && this.nonWorkingDay.Value == day.DayOfWeek)
		return false;

	if (day.DayOfWeek == DayOfWeek.Sunday || day.DayOfWeek == DayOfWeek.Saturday)
		return false;

	return true;
}

public void AddDayOfWeekAsWorkingDay(DayOfWeek dayOfWeek)
{
	this.workingDay = dayOfWeek;
}

public void AddDayOfWeekAsNonWorkingDay(DayOfWeek dayOfWeek)
{
	this.nonWorkingDay = dayOfWeek;
}

Ahora el test está en verde. Agregué una nueva variable interna “nullable” nonWorkingDay. Ciertamente que la clase escrita sólo soporta un sólo día laborable configurable y un sólo día no laborable configurable. Pero los tests que escribimos pasan. Voy por “baby steps”, de a “pasos de bebé”.

Pero van viendo la aplicación de TDD: en cada test, hay una nueva especificación de cómo queremos que actúe nuestro software en construcción. Y sólo implementamos lo que necesitamos para pasar el test. Poco a poco, va emergiendo la implementación interna, donde ponemos lo que conocemos como programadores. Pero sin caer en la tentanción de “Ah! acá pongo esto que lo voy a necesitar”. Si el test no lo necesita, nosotros tampoco :-)

Nos leemos!

Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez

TDD Paso a Paso (4) Otro tipo de Semana

lopez — Tue, 24 Apr 2012 10:05:00 GMT

Anterior Post
Siguiente Post

Ahora veamos de tratar uno de los requerimientos: que los días laborables/no laborables sean configurables, ya sea por feriados puntuales, feriados que se repiten año a año, o porque la propia semana tenga otro reparto de días laborables.

El primero que se me ocurre es contemplar que el sábado sea día laboral. Escribo el test:

[TestMethod]
public void SetSaturdayAsAWorkingDay()
{
	WorkingDaysCalendar calendar = new WorkingDaysCalendar();

	calendar.AddDayOfWeekAsWorkingDay(DayOfWeek.Saturday);

	DateTime saturday = new DateTime(2012, 3, 10);
	Assert.AreEqual(saturday.DayOfWeek, DayOfWeek.Saturday);        

	Assert.IsTrue(calendar.IsWorkingDay(saturday));
}

Al ejecutarlo, da rojo, porque el código que tengo hasta ahora pone a los sábados como días no laborables. Siguiendo la idea de poner el mínimo código necesario para pasar el test, y que sigan dando verde los anteriores, éste es el código que agregué (y luego refactoricé un poco):

private DayOfWeek? workingDay;

public bool IsWorkingDay(DateTime day)
{
	if (this.workingDay.HasValue && this.workingDay.Value == day.DayOfWeek)
		return true;

	if (day.DayOfWeek == DayOfWeek.Sunday || day.DayOfWeek == DayOfWeek.Saturday)
		return false;

	return true;
}

public void AddDayOfWeekAsWorkingDay(DayOfWeek dayOfWeek)
{
	this.workingDay = dayOfWeek;
}

Con esto, el test da en verde. Ejecuto toda la batería de test y sigue dando verde.

Noten que la variable adicional es “nulleable”. Podría haber puesto un arreglo, una lista de días laborables o algo así. PERO NINGUN TEST ME LO PIDIO. Es decir, no hay caso de uso del código que estamos desarrollando que necesite esa flexibilidad. Seguramente en los próximos test tendré que agregarlo. Pero no cruzar el puente ANTES de llegar al puente.

Nos leemos!

Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez

TDD Paso a Paso (3) Domingo y Semana Típica

lopez — Wed, 18 Apr 2012 14:25:00 GMT

Anterior Post
Siguiente Post

Sigo con la descripción de los tests que fui escribiendo para este problema. Ahora que ya tengo un test para ver si sábado es día laborable, agregué un test para ver si cada domingo es día laborable:

[TestMethod]
public void TypicalSaturdayIsANonWorkingDay()
{
    WorkingDaysCalendar calendar = new WorkingDaysCalendar();

    DateTime saturday = new DateTime(2012, 3, 10);
    Assert.AreEqual(saturday.DayOfWeek, DayOfWeek.Saturday);

    Assert.IsFalse(calendar.IsWorkingDay(saturday));
}

Inicialmente, el test quedó en rojo. El problema es que el código que llevo escrito solamente reconoce como no laborable a los Sábados. Modifiqué la función que determina eso a:

public bool IsWorkingDay(DateTime day)
{
    if (day.DayOfWeek == DayOfWeek.Sunday || day.DayOfWeek == DayOfWeek.Saturday)
        return false;

    return true;
}

Y el test pasó. Vean que aparecen dos constantes en el código interno. No me preocupa por ahora, porque refleja lo que tengo hasta ahora en los tests. En algún momento, tendré que contemplar (como pedía el problema original) que hay otras semanas típicas: por ejemplo, para un peluquero el sábado puede ser día laborable, y para una panadería el domingo es laborable pero el lunes no.

Llegado a este punto, escribí un test que sale un poco de TDD “estricto”. Es un tests que me dió en verde desde el comienzo. Es el que prueba los días de una semana típica:

[TestMethod]
public void TypicalWeek()
{
    WorkingDaysCalendar calendar = new WorkingDaysCalendar();

    DateTime monday = new DateTime(2012, 3, 12);
    Assert.AreEqual(monday.DayOfWeek, DayOfWeek.Monday);

    Assert.IsTrue(calendar.IsWorkingDay(monday));
    Assert.IsTrue(calendar.IsWorkingDay(monday.AddDays(1)));
    Assert.IsTrue(calendar.IsWorkingDay(monday.AddDays(2)));
    Assert.IsTrue(calendar.IsWorkingDay(monday.AddDays(3)));
    Assert.IsTrue(calendar.IsWorkingDay(monday.AddDays(4)));
    Assert.IsFalse(calendar.IsWorkingDay(monday.AddDays(5)));
    Assert.IsFalse(calendar.IsWorkingDay(monday.AddDays(6)));
}

Me gusta tener ese test, para que alguien pueda ver, en un solo lugar, lo que considero para esta API como semana típica. Otros “approach”: no escribir este test, o escribirlo y eliminar los anteriores. Pero yo me “encariño” :-) con los tests, y es raro que los elimine. También dan una idea de la historia, de la evolución de la API. Así que agregué este test de arriba, nacido prístinamente en verde, y dejé los anteriores.

Próximos posts: cómo admitir otro tipo de semanas “típicas”, feriados, etc.

Como siempre, toda esta serie de cambios quedó reflejado en el log del proyecto. Ver https://github.com/ajlopez/TddOnTheRocks

Nos leemos!

Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez

TDD Paso a Paso (2) Días No Laborables

lopez — Tue, 20 Mar 2012 16:20:00 GMT

Anterior Post
Siguiente Post

En el primer post de esta serie, expliqué el problema y el primer test, que va quedando en el repositorio del proyecto.

Veamos ahora el segundo test. Me decidí por probar que un domingo típico es día no laborable, que implica un cambio con respecto al anterior test. En el primer test que escribimos, preguntábamos por un caso positivo de día laborable. Ahora cambiamos a probar un caso negativo.

El nuevo test:

[TestMethod]
public void TypicalSundayIsANonWorkingDay()
{
    WorkingDaysCalendar calendar = new WorkingDaysCalendar();

    DateTime sunday = new DateTime(2012, 3, 11);
    Assert.AreEqual(sunday.DayOfWeek, DayOfWeek.Sunday);

    Assert.IsFalse(calendar.IsWorkingDay(sunday));
}

Al ejecutarlo, da rojo. El problema es que la actual implementación retorna que todos los días de la semana son laborables. El mínimo cambio en el código que hace que todo funcione es:

public bool IsWorkingDay(DateTime day)
{
    if (day.DayOfWeek == DayOfWeek.Sunday)
        return false;

    return true;
}

Ahora sí funciona, habiendo agregado el if del comienzo. El próximo test que se me ocurre es probar que un sábado típico (más adelante veremos otros calendarios, por ejemplo, el de un peluquero, que acá en Argentina tienen como día no laborable el lunes, y muchos trabajan el sábado Y el domingo; era parte de los requerimientos, poder configurar el calendario). El tercer test, entonces, es:

[TestMethod]
public void TypicalSaturdayIsANonWorkingDay()
{
    WorkingDaysCalendar calendar = new WorkingDaysCalendar();

    DateTime saturday = new DateTime(2012, 3, 10);
    Assert.AreEqual(saturday.DayOfWeek, DayOfWeek.Saturday);

    Assert.IsFalse(calendar.IsWorkingDay(saturday));
}

Mínimo código que hace que el test pase a verde:

public bool IsWorkingDay(DateTime day)
{
    if (day.DayOfWeek == DayOfWeek.Sunday || day.DayOfWeek == DayOfWeek.Saturday)
        return false;

    return true;
}

Agregué un día más no laborable en la condición del if.

Vean que quedaron dos constantes el código de implementación. Por ahora, no me preocupa. Es más: me parece que son constantes que reflejan algo básico del sistema que estamos armando, no son constantes arbitrarias. Comienza a surgir lo que entiendo como calendario típico: semana laborable, excepto sábados y domingo.

No hice mucho refactoring en estos test. Diferencias con el Coding Dojo: sigo usando nombres significativos para los tests (si hay que cambiarlos, los cambio). Tampoco usé métodos auxiliares que me devuelvan un lunes o un domingo o un sábado. Si necesito esos métodos, será porque surjan de refactor de código de tests (probablemente, si necesito obtener un lunes desde más de 2 tests, digamos).

Próximos pasos: ver qué es una semana típica, plasmarla en un test; comenzar a configurar el calendario (tal vez, sábado es laborable, para algunas profesiones, que usaran un calendario configurable para ellas).

Nos leemos!

Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez

TDD Paso a Paso (1) Primer Test

lopez — Sun, 18 Mar 2012 16:15:00 GMT

Siguiente Post

Comenté en el post Coding Dojo – TDD on the Rocks el ejercicio que hicimos en conjunto con el bueno de @HernanWilkinson. Quisiera hoy comenzar una serie explicando un poco mi estilo de programar ese ejercicio, para ir viendo las diferencias con lo visto en el coding dojo. No digo que sea mejor o peor, pero sí que es la forma en la que me siento más cómodo. Esta forma de encarar TDD (Test-Driven Development) la estoy publicando en

https://github.com/ajlopez/TddOnTheRocks/tree/master/MySrc

Pueden ver ahí el log de lo que fui escribiendo: estuve enviando commit al repositorio Git prácticamente por cada paso. Les recuerdo el problema:

- Calendario de días laborables y no laborables

- Se debe saber si una fecha particular es laborable o no

- Se debe configurar con:

- día de la semana no laboral (ej. Domingo)

- día de mes no laboral (ej. Primero de Enero)

- fecha particular no laboral (ej. 4 de Abril de 2012)

Primero, construí una solución en C# con Visual Studio, con dos proyectos: uno de librería de clases, y otro de test:

Vean que fui creando una clase para los tests, y otra clase para lo que quieron implementar. Ahí difiero del “approach” de @HernanWilkinson, que llamó a la clase de tests con un nombre no significativo. Yo prefiero empezar con un nombre más relacionado con el problema, aunque puede que después lo cambie.

El primer tests, para mí, es probar que los lunes, en general, son un día laborable. Este fue mi primer test:

[TestMethod]
public void TypicalMondayIsAWorkingDay()
{
	WorkingDaysCalendar calendar = new WorkingDaysCalendar();
	
	DateTime monday = new DateTime(2012, 3, 12);

	Assert.IsTrue(calendar.IsWorkingDay(monday));
}

Acá otra “departure” del ejercicio del coding dojo. Mientras que aquel día codificamos el test poniéndole un nombre neutro como test1, yo prefiero darle un nombre significativo desde el principio, aunque después lo cambie. Me queda claro qué estoy intentando hacer, y también para cualquiera que lo vea. No me ha pasado con frecuencia que tenga que cambiar radicalmente el nombre a un test. Pueden ver los logs de proyectos de código abierto (por ejemplo los de GitHub), para notar que no he necesitado mucho el “renaming” de nombre de test.

Pero este test no compila. Armé una primera clase:

public class WorkingDaysCalendar
{
	public bool IsWorkingDay(DateTime day)
	{
		throw new NotImplementedException();
	}
}

que consigue que el test compile, pero al ejecutarlo, da rojo. El código mínimo que consiguió que pase a verde:

public bool IsWorkingDay(DateTime day)
{
	return true;
}

No hay mucho lugar para hacer refactor, en este punto. Pero mejoré el código de test, para afirmar/controlar explícitamente que la fecha que estoy usando es un lunes:

[TestMethod]
public void TypicalMondayIsAWorkingDay()
{
	WorkingDaysCalendar calendar = new WorkingDaysCalendar();
	
	DateTime monday = new DateTime(2012, 3, 12);
	Assert.AreEqual(monday.DayOfWeek, DayOfWeek.Monday);

	Assert.IsTrue(calendar.IsWorkingDay(monday));
}

En el coding dojo usamos una función someSunday() (en este caso sería someMonday()), pero todavía no la necesité. Así que para mantener el test simple, me bastó crear una fecha de lunes directamente en el código del test. Para cualquiera que lea el test dentro de un año, me aseguro que la fecha elegida sea la de un lunes.

En el próximo post comentaré los siguientes tests que se me ocurrieron: probar que un domingo típico es no laborable, y que un sábado típico tampoco. Veremos cómo fue emergiendo la implementación interna, y al llegar a nuevos tests, cómo esta implementación fue siendo mejorada y refactorizada.

Jeje… “dog fooding”, el código de arriba fue “coloreado” con Acquarella.

Nos leemos!

Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez

AjModel: Modelo por Código (Parte 2) Modelos y Repositorios

lopez — Thu, 30 Jun 2011 10:04:26 GMT

Anterior Post

Estuve trabajando en mi projecto AjModel. Pueden bajar el avance del código desde mi AjCodeKatas Project dentro de trunk/AjModel. Agregué una clase Model, y mejoré EntityModel y PropertyModel:

El modelo referencia a todos los modelos de entidades que quiero tomar de mi modelo ya codificado. Recordemos: AjModel se basa y enriquece un modelo ya codificado de clases, permitiendo agregar información como descripciones para humanos, leyendas, etc. La idea es generar automáticamente la UI desde el modelo en código, para diferentes tecnologías. El modelo de AjModel permite establecer ese puente entre nuestro modelo en código y las distintas UI. El modelo enriquecido debería servir para esa función AUN cuando no se le agregue nada. Y servir de base para generar la UI en ejecución. El modelo enriquecido debe ser poder consumido por distintas tecnologías de UI: la aplicación “prueba de concepto” que incluyo en el código es ASP.NET MVC.

Como anticipaba en el post anterior, agregué una interfaz “fluent” a EntityModel y PropertyModel. Hay métodos de extensión, wrappers/builders, como:

Algunos ejemplos de uso, tomados de los tests:

EntityModel<Customer> model = new EntityModel<Customer>();
FluentEntityModel<Customer> fluentModel = new FluentEntityModel<Customer>(model);
fluentModel.Name("BusinessCustomer")
    .SetName("BusinessCustomers")
    .Descriptor("Business Customer")
    .SetDescriptor("Business Customers");
//..
Model model = new Model();
var entityModel = model.ForEntity<Customer>();
entityModel.Descriptor("Business Customer")
    .SetDescriptor("Business Customers");
//..
Model model = new Model();
model.ForEntity<Customer>().Property(
    c => c.Name,
    pm => pm.Descriptor("Customer Name")
            .Description("The Customer Name")
);

donde pm es un FluentPropertyModel.

En el proceso de la UI, quiero recuperar una entidad por su identidad, para poder mostrar su detalle. Y también, quiero obtener una lista de entidades para alimentar una grilla. Entonces, necesito algo para manejar entidades, como una lista, y que se implemente por abajo en distintas tecnologías. La actual implementación se basa en una lista en memoria:

En mis planes está escribir ejemplos de adapter para NHibernate, Entity Framework, pero eso todavía está solo en papel y en mi mente ;-)

Ejemplos de uso:

this.entityModel = new EntityModel<Customer>();
this.domain = new SimpleDomain();
this.repository = new Repository<Customer>(this.entityModel, this.domain.Customers);

Noten que hay repositorios con tipo, usando generics. Y necesita para manejarse un EntityModel, y (en la actual implementación) un IList de entidades. El Context contiene una lista de todos los repositorios:

var entityModel = new EntityModel<Customer>();
var domain = new SimpleDomain();
var repository = new Repository<Customer>(entityModel, domain.Customers);
var context = new Context();
context.AddRepository(this.repository);
var repo = context.GetRepository("Customer");

SimpleDomain es una clase que creé para los tests:

public class SimpleDomain
{
    public SimpleDomain()
    {
        this.Customers = new List<Customer>();
        for (int k = 1; k <= 10; k++)
        {
            Customer customer = new Customer()
            {
                Id = k,
                Name = string.Format("Customer {0}", k)
            };
            this.Customers.Add(customer);
        }
    }
    public IList<Customer> Customers { get; set; }
    public ProductList Products { get; set; }
}

Un modelo puede ser creado alimentándose de la estructura de una clase como SimpleDomain. Descubre las propiedades públicas que implementan IList (por ahora):

var model = new Model(typeof(SimpleDomain));
var entityModel = model.GetEntityModel("Customer");
Assert.IsNotNull(entityModel);
entityModel = model.GetEntityModel("Product");
Assert.IsNotNull(entityModel);

Planeo agregar automáticamente todos los tipos de un assembly que satisfagan un predicado, como tener “Entities” en su namespaces. new Model(IEnumerable<Type> types) debería bastar.

Las entidades (objetos) pueden ser agregadas y recuperadas usando un repositorio:

Customer entity = new Customer() { Id = 1000 };
this.repository.AddEntity(entity);
Customer newEntity = this.repository.GetEntity(1000);

Y pueden ser removidas, también.

El modelo de entidad tiene la información para crear nuevas entidades desde valores (en un diccionario con pares nombre/valor). Una capacidad que necesito para usar en la creación de entidades desde la UI:

EntityModel<Person> model = new EntityModel<Person>();
IDictionary<string, object> values = new Dictionary<string, object>()
{
    { "Id", 1 },
    { "FirstName", "Joe" },
    { "LastName", "Doe" },
    { "Age", "30" }
};
object entity = model.NewEntity(values);

En próximos posts, discutiré alguna implementación de la UI en MVC. Todo es “work in progress”, pero el proyecto ya va tomando forma. Y me divieggtto como loco ;-)

Nos leemos!

Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez

Escribiendo una Aplicación usando TDD (Part 5) Agregando Vistas

lopez — Mon, 27 Jun 2011 10:21:00 GMT

Anterior Post
Próximo Post

Ahora ya tengo algunos tests y en verde. Voy a agregar algunas vistas MVC en este paso de hoy. Pueden bajar el código desde mi AjCodeKatas Google Project, en trunk/AppTdd/Step04. Así que este post tiene pocos nuevos tests: muestra que podemos agregar interfaz de usuario DESPUES de los tests, y (para destacar) SIN TENER una base de datos aún, ni siquiera una capa de servicios (“service layer”).

Primero, agregué una master page Site.master y un estilo style.css (que tomé de otro proyecto ASP.NET MVC 2)

Agregué un nuevo controlador Home:

Y usando el menú de contexto sobre el método Index agregué una vista asociada al método:

Modifiqué el código de la master page para tener una nueva opción en el menú:

Entonces, agregué una vista, esta vez asociada al método Index del controlador Subject:

Seleccioné a “List” como “Vien Content”, y a “Subject” como el tipo a usar como base del modelo.

Pero el método del controlador es:

public ActionResult Index()
{
    return View(subjects);
}

Usa una lista de temas (“subjects”) que ha sido inyectada hasta ahora en un constructor por los tests:

public SubjectController(IList<Subject> subjects)
{
    this.subjects = subjects;
}

Pero esperen! Esa lista es inyectada por los tests. Ahora, necesito que esté disponible en el proceso normal de un controlador. Así que agregué un constructor sin parámetros:

public SubjectController()
    : this(Domain.Instance.Subjects)
{
}

El Domain.Instance es un dominio en memoria:

public class Domain
{
    private static Domain instance = new Domain();
    private Domain()
    {
        this.Subjects = new List<Subject>()
        {
            new Subject() { Id = 1, Name = "Mathematics" },
            new Subject() { Id = 2, Name = "Physics" },
            new Subject() { Id = 3, Name = "Biology" },
            new Subject() { Id = 4, Name = "Literature" }
        };
    }
    public static Domain Instance { get { return instance; } }
    public IList<Subject> Subjects { get; set; }
}

Ahora sí el controlador de Subject puede manejar el método Index. Cambio enlaces en la vista que me agregó el wizard. Los cambio de:

a que usen la propiedad Id como clave primaria:

Este es el resultado:

Creé entonces otras vistas, para los otros métodos del controlador Subject. Seguí usando el wizard de Visual Studio “Add View … “:

Me encontré que me faltaban algunas acciones. Escribí una nueva:

public ActionResult Edit(int id)
{
    var model = this.subjects.Where(s => s.Id == id).FirstOrDefault();
    return View(model);
}

con tests! ;-)

[TestMethod]
public void GetSubjectForEdit()
{
    IList<Subject> subjects = GetSubjects();
    SubjectController controller = new SubjectController(subjects);
    ActionResult result = controller.Edit(1);
    Assert.IsNotNull(result);
    Assert.IsInstanceOfType(result, typeof(ViewResult));
    ViewResult viewResult = (ViewResult)result;
    Assert.IsInstanceOfType(viewResult.ViewData.Model, typeof(Subject));
    Subject model = (Subject)viewResult.ViewData.Model;
    Assert.AreEqual(1, model.Id);
    Assert.AreEqual("Mathematics", model.Name);
}

Curiosamente, detecté un test “malo”. Yo había escrito en test AddSubject:

Assert.IsTrue(subjects.Any(s => s.Name == "Chemistry"));
Assert.AreEqual(4, subject.Id);

Pero el nuevo Id debería dar 5 (mi lista usada en los tests tiene 4 temas predefinidos (“subjects”)):

Assert.IsTrue(subjects.Any(s => s.Name == "Chemistry"));
Assert.AreEqual(5, subject.Id);

Arreglé el código y la acción del controler, ejecuté la aplicación web, y voila! Todo funcionó.

Puntos principales:

- Estoy usando un dominio en memoria.

- Las vistas se ejecutan sobre las acciones YA probadas con tests

No hay capa lógica de servicios ni persistencia, aún. Vean que no son necesarias al principio. Voy a agregar una “service layer” como gran refactor. Otros próximos pasos: agregar más clases al dominio (libros en clase Book), escribir esa capa de servicio usando tests, “enchufarla” en los controladores. Y en algún momento agregar persistencia.

Pueden leer posts interesantes sobre TDD sin una base de datos (o agregándola después) escritos por @RonJeffries:

But We Need a Database … Don’t We? | xProgramming.com
See? We Don’t Need a Database … Yet | xProgramming.com

Nos leemos!

Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez

Escribiendo una Aplicación usando TDD (Parte 4) Alta y Actualización

lopez — Thu, 02 Jun 2011 10:05:00 GMT

Anterior Post
Siguiente Post

En el anterior post, implementé la recuperación de los datos de un Tema de libros. No implementé aún ninguna vista. Estoy escribiendo los tests, e implementando el código del controlador. Es hora de agregar un nuevo Tema (Subject), usando una acción del controlador.

Este fue mi primer test:

[TestMethod]
public void AddSubject()
{
    IList<Subject> subjects = GetSubjects();
    Subject subject = new Subject() { Name = "Chemistry" };
    SubjectController controller = new SubjectController(subjects);
    ActionResult result = controller.Create(subject);
    Assert.IsNotNull(result);
    Assert.IsTrue(subjects.Any(s => s.Name == "Chemistry"));
    Assert.AreNotEqual(0, subject.Id);
}

GetSubjects() es un método ayudante que presenté en el anterior posts. Retorna una lista de temas para tests. Agregué una nueva acción en la clase controladora, para que la solución compile:

public ActionResult Create(Subject subject)
{
    throw new NotImplementedException();
}

Compiló, y el test quedó en rojo:

Entonces, completé el método de acción con el código mínimo para que pase el test:

public ActionResult Create(Subject subject)
{
   subject.Id = this.subjects.Max(s => s.Id);
   subjects.Add(subject);
   return RedirectToAction("Index");
}

Pero quiero redireccionar a la vista de detalle luego de haber dado de alta un item. Agrego el test:

RedirectToRouteResult redirect = (RedirectToRouteResult)result;
Assert.IsTrue(string.IsNullOrEmpty(redirect.RouteName));
Assert.IsTrue(redirect.RouteValues.ContainsKey("id"));
Assert.AreEqual(subject.Id, redirect.RouteValues["id"]);
Assert.IsTrue(redirect.RouteValues.ContainsKey("action"));
Assert.AreEqual("Details", redirect.RouteValues["action"]);

Cambio el código de la acción para que cumpla con el nuevo requerimiento:

public ActionResult Create(Subject subject)
{
    subject.Id = this.subjects.Max(s => s.Id);
    subjects.Add(subject);
    return RedirectToAction("Details", new { id = subject.Id });
}

Ahora, el test en verde:

Seguí un camino similar para escribir el test de actualización de un Tema existente. Esta es la versión actual de ese test:

[TestMethod]
public void UpdateSubject()
{
    IList<Subject> subjects = GetSubjects();
    Subject literature = subjects.Where(s => s.Name == "Literature").FirstOrDefault();
    Subject subject = new Subject() { Name = "SciFi" };
    SubjectController controller = new SubjectController(subjects);
    ActionResult result = controller.Update(literature.Id, subject);
    Assert.IsNotNull(result);
    Assert.IsInstanceOfType(result, typeof(RedirectToRouteResult));
    RedirectToRouteResult redirect = (RedirectToRouteResult)result;
    Assert.IsTrue(string.IsNullOrEmpty(redirect.RouteName));
    Assert.IsTrue(redirect.RouteValues.ContainsKey("id"));
    Assert.AreEqual(literature.Id, redirect.RouteValues["id"]);
    Assert.IsTrue(redirect.RouteValues.ContainsKey("action"));
    Assert.AreEqual("Details", redirect.RouteValues["action"]);
    Assert.IsTrue(subjects.Any(s => s.Name == "SciFi"));
    Assert.AreEqual(literature.Id, subjects.Where(s => s.Name == "SciFi").Single().Id);
}

La acción del controlador:

public ActionResult Update(int id, Subject subject)
{
    Subject toupdate = this.subjects.Where(s => s.Id == id).Single();
    toupdate.Name = subject.Name;
    return RedirectToAction("Details", new { id = id });
}

Todos los tests en verde:

Algunas advertencias: los tests están revisando dos salidas: los cambios en el dominio (por ahor auna simple lista) y los resultados de las acciones (un tema MVC). Debería hacer refactor (seguramente en un futuro post) de la implementación del controlador, para separar las actualizaciones del dominio de los resultados de la navegación. Escribí el ejemplo de esta manera para mostrar cómo hacer refactor más adelante para conseguir una mejor implementación. Mi idea es tener un servicio de manejo de temas, y escribir con tests. Luego usarlo desde el controlador. Debería tambien tratar los casos de actualización de un item inexistente o la creación de un item ya existente.

Otra nota: no puse ninguna vista MVC todavía. Pero ahora ya tengo los tests como para agregarlas con confianza. Cuando las agregue, la conducta esperada del controlador ya estará probada.

Nos leemos!

Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez

Escribiendo una Aplicación usando TDD (Parte 2) Primera lista

lopez — Fri, 25 Mar 2011 14:48:00 GMT

Siguiente post en esta serie
Anterior post en esta serie

Gracias a un comentario de @MartinSalias, en mi post anterior, elegí para desarrollar este ejemplo un dominio simple: mi biblioteca personal, mis libros. En esta primera iteración de código, quiero listar los temas de los libros: Física, Matemáticas, Biología, Literatura… (similar a los génereos del ejemplo MvcMusicStore de @jongalloway).

Primero, creé una solución ASP.NET MVC 2 (estoy usando Visual Studio 2008) (el código de este post, como siempre, queda en mi AjCodeKatas Google Project, en el directorio trunk/AppTdd/Step01)

Luego, agregué un proyecto de test:

A este proyecto le agregué referencias a System.Web.Mvc and MyLibrary.Web.

Agregué un test:

Limpié el código de la clase generada por el wizard, removiendo código no usado. Quedó:

namespace MyLibrary.Web.Tests.Controllers
{
    using System;
    using System.Text;
    using System.Collections.Generic;
    using System.Linq;
    using Microsoft.VisualStudio.TestTools.UnitTesting;
    [TestClass]
    public class GenreControllerTests
    {
    }
}

Ahora, agregué mi primer test:

        [TestMethod]
        public void GetGenres()
        {
            IList<Genre> genres = new List<Genre>()
            {
                new Genre() { Name = "Mathematics" },
                new Genre() { Name = "Physics" },
                new Genre() { Name = "Biology" },
                new Genre() { Name = "Literature" }
            };
            GenreController controller = new GenreController(genres);
            ActionResult result = controller.Index();
            Assert.IsNotNull(result);
            Assert.IsInstanceOfType(result, typeof(ViewResult));
            ViewResult viewResult = (ViewResult)result;
            Assert.IsInstanceOfType(viewResult.ViewData.Model, typeof(IList<Genre>));
            Assert.AreSame(genres, viewResult.ViewData.Model);
        }

La idea del test: crear el controlador, alimentarlo de una lista de temas, y luego invocar su acción Index. Hecho eso, controlar el resultado. A esta altura, el código no compilaba: el controlador no existía, no había clase Genre. Así que escribí esas clases. La clase Genre, en el directorio Model del proyecto MyLibrary.Web:

    public class Genre
    {
        public string Name { get; set; }
    }

Un controlador simple GenreController (agregado con click derecho sobre el directorio Controllers):

El wizard produjo este código:

    public class GenreController : Controller
    {
        //
        // GET: /Genre/
        public ActionResult Index()
        {
            return View();
        }
    }

Lo modifiqué para que tenga el constructor que necesito en el test:

    public class GenreController : Controller
    {
        public GenreController()
        {
        }
        public GenreController(IList<Genre> genres)
        {
        }
        public ActionResult Index()
        {
            return View();
        }
    }

Noten que mi intención es compilar el test, no que fuencione: la lista de temas no es usada por esta primer implementación de controlador. Con todos estos cambios, pude compilar la solución y ejecutar el test:

El resultado:

El problema:

Como esperaba. Esto es parte del ciclo TDD: compilar, rojo, y ahora, hay que ir por el verde.

Cambié el controlador (su interfaz ya estaba completa):

    public class GenreController : Controller
    {
        private IList<Genre> genres;
        public GenreController()
        {
        }
        public GenreController(IList<Genre> genres)
        {
            this.genres = genres;
        }
        public ActionResult Index()
        {
            return View(genres);
        }
    }

Y ahora, el resultado es:

Triunfo de la mente sobre la materia! ;-)

Ahora, es tiempo de refactoring. Bien, no tengo mucho para hacer ahora (me llega un comentario en mi post en inglés de @MartinSalias, sugiriendo cambios en la nomenclatura, bien, quedará para el próximo paso). Podría mejorar alguna variable, nombre. La principal pieza faltante: la vista. Nota: el controlador no está preparado, aún, para ser consumido por una vista. No hay quien le provea los temas en ejecución. En el test, usé un constructor que se los provee, pero ASP.NET MVC crearía la instancia del controlador usando el constructor sin parámetros.

Próximos pasos: mejorar el controlador para usar una vista, algunas acciones CRUD con tests, y vistas.

Podrían preguntar: ¿dónde está el repositorio de los temas? ¿dónde están los libros? ¿y la base de datos? ¿y la capa de servicios (service layer)? ¿separación del dominio? Ok, son todas preguntas válidas y temas a tratar. Pero mi idea es mostrar, de forma incremental, con TDD, cómo podemos ir agregando todo eso a medida que aparezcan más requerimientos y especificaciones. Quiero que cada cosa que se agregue provenga del proceso de escribir test (ya sea de la especificación del test, o de la etapa de refactoring). Como escribí en mi anterior post, esta es una clase de aproximación arriba-abajo (top-down). En este caso, el dominio es simple, así que comienzo desde el tope de la presentación. Luego de este ejemplo simple, a desarrollar en varios post, cambiaré a un dominio menos simple. En ese caso, comenzaré por construir por tests al propio dominio, en lugar de la presentación.

Nos leemos!

Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez

Escribiendo una Aplicación usando TDD (Part 1) Introducción

lopez — Tue, 01 Mar 2011 09:21:00 GMT

Siguiente Post

Estoy escribiendo una serie de posts sobre escribir un intérprete usando TDD (Test-Driven Developement). Mi intención es mostrar el uso de TDD en código de producción. Desde mi adopción de TDD, produzco mejor código (eso espero ;-) y en menos tiempo (no más largas sesiones de depuración ;-). Hay otros beneficios: si tenemos una aplicación con TDD, tenemos un buen code coverage (cubrimiento de código), y escribimos los casos de uso del código de la aplicación y los resultados esperados. Todo esto da confianza para mejorar la aplicación, posiblemente por otro equipo. Pienso que entregar una aplicación con TDD es un plus para el cliente final y para la evolución saludable de software exitosa. Podemos tener lo mismo con simples tests, pero TDD agregar el correcto proceso iterativo para armar código de producción, en vez de dejar los tests “para después”.

Pero el ejemplo de intérprete que estoy armando es una especie de “largo code kata”. Podrían decir: “Eh! No es la clase de código que escribo todos los días”. Sí, es verdad. Entonces, es tiempo de comenzar una serie de posts escribiendo una aplicación.

Elegí estas tecnologías para usar:

- .NET 3.5 (puede que pase en algún momento a 4.0)

- ASP.NET MVC 2 (podría usar la versión 3)

- Visual Studio 2008 (el otro candidato es VS 2010), usando su soporte de tests, como en mis anteriores posts.

Tengo que seleccionar una tecnología de persistencia. Esoy pensando en NHibernate 3.x + Fluent NHibernate o con ConfORM; La alternativa es Entity Framework 4 with Code First.

Hay dos caminos a seguir, en este ejemplo iterativo:

- Dominio simple: comenzar escribiendo código de presentación y tests, entonces pasar a una capa de aplicación/servicios, y de ahí, pasar a la capa de persistencia

- Un dominio más complejo: escribir el código del dominio con tests, recién ahí pasar a la presentación y a la persistencia.

El primer camino es un tipo de aproximación “top-down”. Es opuesto a lo que he usado en mi serie de intérprete (noten la ausencia de mocks, stubs, en mi camino “bottom-up”, escribiendo expresiones, comandos, pasando a parte del lexer, luego al parser, etc…). Ahora, con esta nueva forma de hacer TDD, quiero mostrar el armado incremental de funcionalidad, aún sin tener una base de datos, modelo de persistencia, y otros detalles tecnológicos desde el principio. ASP.NET MVC y TDD nos permiten escribir los casos de uso iniciales de una manera simple, en un dominio simple, abrazando un desarrollo ágil e incremental. Otro beneficio es que podemos entregar algo “que funciona” para obtener "feedback" temprano del usuario.

Luego de explorar esta forma de hacer desarrollo con TDD, cambiaré a un dominio un poco más complejo. En esos casos, yo prefiero comenzar escribiendo el dominio con tests, enfocándome en el núcleo de la aplicación, agregarn en el camino algo de presentación, para mostrar algo al usuario final, pero sin gastar mucho tiempo en temas complejos de interfaz (AJAX, javascript, interfaz dinámica en el browser).

El formato de escribir una serie de post es importante: hay muchos ejemplos de código de aplicaciones con TDD (por ejemplo, muchos proyectos de código abierto), pero muchos de esos ejemplos muestran “la etapa final” de un largo camino. Escribiendo un ejemplo más simple, incrementalmente, es una mejor forma de comenzar a comprender el estilo TDD de hacer desarrollo de software.

Bueno, suficiente por hoy. Este es un post de introducción, para presentar la idea, y comenzar a calentar motores! Comentarios, sugerencias, bienvenidas!.

Nos leemos!

Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez

Popularidad de Lenguajes de Programación

lopez — Wed, 08 Jul 2009 09:50:06 GMT

Me temo que AjLisp y AjBasic lo usamos yo y nadie más… snif… :-). Pero hay lenguajes más populares que esos. Ya es clásica la lista de TIOBE Software:

http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html

donde aparece Java como el lenguaje más popular, lo que no me asombra. Pero sí me llama la atención la popularidad de C y C++, que deben tener su gran uso en el ambiente Unix, Linux, y otros. Como cuarto, encuentro hoy, Julio de 2009, a PHP, que lo entiendo: la mayor parte del código de sitios dinámicos está en PHP, lejos quedaron los años del predominio del venerable Perl. Y recién en sexto y séptimo lugar, está Visual Basic (parece que agrupan el de .NET y el clásico), y C#. Vean que al final de la lista, aparecen lenguajes con mínimos porcentajes, pero aparecen: RPG, Pascal, Abap, Lisp/Scheme. Más abajo, en la misma página encontraran la lista de posición 21 a 50, donde aparecen COBOL, Objective-C, Fortran, Logo, Prolog, Ada (todavía anda por ahí? :-), Scala, Erlang…. y esta es la lista de 51 a 100:

ABC, AD, Algol, Alpha, Applescript, Beta, Boo, C shell, cg, Clean, Cobra, cT, Curl, Dylan, Eiffel, Euphoria, Factor, Fan, Icon, IDL, Inform, Io, Lingo, MAD, Magic, Maple, Mathematica, MAX/MSP, MOO, MUMPS, Natural, Oberon, Occam, Oz, PL/I, Postscript, PowerBuilder, Progress, Q, R, Revolution, REXX, S-lang, SIGNAL, SPSS, SuperCollider, VBScript, Verilog, VHDL, XSLT

Notable lista, recomendaría tantos lenguajes de esa lista, simplemente para aprender nuevas formas de programar (notable que aparezca todavía MUMPS, REXX, tendría que ver con más detalle a Io). Esta lista de popularidad se basa en el examen de búsquedas en Google, hace un tiempo pasaron a agregar MSN y Yahoo.

Pero en estos días, encontré otra página:

http://langpop.com/

con información de ranking de popularidad, pero con agrupadas con distintas fuentes, como Yahoo Search, search en Google Code, Freshmeat, Craiglist, Amazon.

En lo que veo hoy ahí, julio de 2009, según Yahoo Search C es más popular que Java. Pero para Craiglist, primero PHP, segundo SQL (!!!), en Amazon ganan C, C++ y C#, por encima de Java. Y así, noto dispersión de los resultados, dependiendo de la fuente.

La popularidad de un lenguaje importa. No tanto para entender el lenguaje (muchos lenguajes “boutique” tienen interesantes conceptos, a estudiar con detalle), sino para tener una idea de qué tecnología ha sido adoptada por la comunidad, pero habría que ver más allá: por qué la eligieron, y en qué tipo de proyectos. Dudo que haya muchas aplicaciones desktop, en PHP.

Resumen: gran cantidad de lenguajes, hay lenguajes viejos, desde COBOL y Smalltalk, y más “nuevos” como Boo, Ruby, Python. Y `cuatros grandes grupos: Java, C/C++, lenguajes .NET (VB.NET, C#), PHP, como claros grupos líderes.

Pienso que, como desarrolladores de software, debemos tener contacto con esos cuatro grupos, y además, con alguno de los “otros”, para aprender otras ideas y formas de programar.

No me enojo si intentan ver AjLisp o AjBasic… :-)

Nos leemos!

Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez

Presentando AjCat

lopez — Wed, 29 Apr 2009 10:24:00 GMT

Hace algo más de un mes, estuve trabajando en un intérprete del lenguaje Cat:

The Cat Programming Language

Cat is a functional stack-based programming language inspired by the Joy programming language. The primary differences is that Cat provides a static type system with type inferencing (like ML or Haskell), and a term rewriting macro language extension language called MetaCat.

Cat is a high-level intermediate language translation that can also be used as a stand alone language for simple application development. In this way it occupies a similar niche to PostScript. Cat is also an appropriate language for teaching of basic programming concepts.

Si no conocen el lenguaje Cat, recomiendaría leer:

Cat Tutorial
Cat Specification
Cat Primitives

Publiqué el código como parte de mi proyecto Code Katas en Google Code. El nombre que usé es AjCat:

http://code.google.com/p/ajcodekatas/source/browse/#svn/trunk/AjCat

La solución tiene tres proyectos:

La actual implementación no es completa. Solo soporta enteros, todavía no soporta objetos .NET, y no hay primitivas de gráficos. Pero está implementado gran parte de las primitivas y funciones definidas en Cat.

Corriendo el programa de consola, pueden ingresar y evaluar expresiones:

Este código está dedicado a Rodolfo Finocchieti (@rodolfof en Twitter) quien me dejó un comentario acá en este blog, comentándome de este lenguaje Cat, una idea fascinante.

Los tests están en verdes:

Y hay un buen code coverage

Como siempre, me divertí escribiendo este código.

Nos leemos!

Angel “Java” Lopez
http://www.ajlopez.com/
http://twitter.com/ajlopez

Enjoying Eric Clapton Everyday I Have the Blues Live

CodeRun plataforma de desarrollo en línea

lopez — Tue, 24 Mar 2009 11:54:50 GMT

El bueno de Martín Salías (@MartinSalias) me avisa de este sitio y aplicación notable:

http://www.coderun.com/

Pueden registrarse, el servicio básico es gratuito.

Al ingresar, se encuentran con algo parecido al Visual Studio:

Si vamos a crear un nuevo proyecto, vemos los distintos tipos de soluciones soportadas:

Hasta tienen para desarrollar una aplicación para Facebook. Eligiendo el ejemplo de Hello World, clásico desde el Kernighan y Ritchie, obtenemos:

Lo podemos compilar y ejecutar:

Era algo que yo estaba esperando: tener un entorno de desarrollo en línea (no solamente una máquina a la que pueda acceder, sino todo instalado para cumplir con una función). Veremos hasta dónde llega esta tendencia, pero veo que tendremos cada vez más poder de procesamiento, sin tener que actualizar el hardware local o el software nuestro. En vez de menú de programas, iremos a favoritos en el browser.

Ya me veo programando un Code Kata desde un ciber, como en mis tiempos de PHP ... ;-)

Debe haber un Eclipse en línea, ¿conocen algún enlace?

Nos leemos!

Angel "Java" Lopez
http://www.ajlopez.com/
http://twitter.com/ajlopez

Test-driven development en acción, usando Visual Studio

lopez — Wed, 18 Mar 2009 09:09:42 GMT

Estoy preparando una charla para el jueves de la semana que viene, 26 de Marzo, en el Microsoft User Group de Argentina. Pueden inscribirse en:

MEDIA JORNADA "Test-driven development en acción, usando Visual Studio".

El horario es de 18:30 a 21:30. La idea es ir armando ejemplos usando los principios de TDD, con código que muestre:

Documentar el código con tests, en vez de en papel
Usar listas de test para generar requerimientos explícitos
Refactorear y mejorar el diseño del código
Test bajo una UI delgada
Test para cambios incrementales, minimizando la depuración
Entregar software que sea verificable y robusto

Lo que veremos estará basado en .NET y Visual Studio, pero se puede aplicar a otros entornos, lenguajes y tecnologías. Las ideas de base son las mismas.

Como siempre, preparar una charla sirve para aclarar los puntos que uno va aplicando en el día a día. Explicar algo, nos permite entenderlo mejor.

Es gratis PARA LOS SOCIOS DEL MUG. Los demás, ¿qué esperan para asociarse? ;-)

Como en otras ocasiones, publicaré en mi sitio el material que utilice en el curso, y probablemente, aparecerán posts por este blog, explicando algunos puntos.

¿Sugerencias a incluir en el temario? ¿Otros temas interesantes para armar una charla-serie de posts?

(Gracias a la gente del MUG, en especial a Gustavo Bachrach, que me han pedido un post para publicar en la revista que entregan a los socios).

Nos leemos!

Angel "Java" Lopez
http://www.ajlopez.com/
http://twitter.com/ajlopez

TDD and Code Kata: Writing a Lexer for AjRuby

lopez — Thu, 12 Mar 2009 05:11:00 GMT

Muchas veces, escribo programas tipo code kata, para entrenarme en algún tema de desarrollo de software. En estos últimos meses, escribí varios mini intérpretes, usando TDD, code coverage, y C#. La semana pasada, estuve trabajando en el lanzamiento de otro pet project, AjRuby. El punto de inicio: el analizador léxico, el lexer.

Un lexer es un programa que analiza el código fuente de un programa, y retorna sus tokens, las “palabras” que componen el programa. En el caso de AjRuby, escribí un lexer que sigue la gramática de Ruby. No está completo aún, pero funciona.

Pueden ver el progreso del proyecto, en el repositorio de Google Code:

http://code.google.com/p/ajcodekatas/source/browse#svn/trunk/AjRuby

La solución tiene un proyecto de librería de clases, y otro de tests:

Hay una clase Token, que representa cada token:

    public class Token
    {
        public string Value { get; set; }

        public TokenType TokenType { get; set; }
    }

El TokenType es una enumeración:

    public enum TokenType
    {
        Name,
        Integer,
        Real,
        Boolean,
        String,
        Operator,
        Separator
    }

Hay una clase LexerTest.cs, conteniendo tests como:

        [TestMethod]
        public void ShouldProcessName()
        {
            Lexer lexer = new Lexer("name");

            Token token;

            token = lexer.NextToken();

            Assert.IsNotNull(token);
            Assert.AreEqual(TokenType.Name, token.TokenType);
            Assert.AreEqual("name", token.Value);

            token = lexer.NextToken();

            Assert.IsNull(token);
        }

Hay un test para cada tipo de token a ser procesado. Otro ejemplo:

        [TestMethod]
        public void ShouldProcessNameWithInitialUnderscore()
        {
            Lexer lexer = new Lexer("_name");

            Token token;

            token = lexer.NextToken();

            Assert.IsNotNull(token);
            Assert.AreEqual(TokenType.Name, token.TokenType);
            Assert.AreEqual("_name", token.Value);

            token = lexer.NextToken();

            Assert.IsNull(token);
        }

Escribí los tests usando ideas TDD: escribir el test, compilar con error, arreglar los problemas de compilación, ejecutar los tests en rojo, arreglarlos, conseguir el verde para los tests. No estuve haciendo tanto refactoring. El código merece algún refactor, pero por ahora, estoy tratando de conseguir un lexer que trabaje. Los tests quedaron en verde:

Mi objetivo es tener más del 80% de code coverage, en cualquier momento del desarrollo del proyecto:

Es bueno escribir algo sólo por diversión y aprendizaje. Para mí, es parte de la mejora continua que todo desarrollador de software debe perseguir.

Nos leemos!

Angel "Java" Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez

AjGa: una librería de algoritmos genéticos

lopez — Wed, 28 Jan 2009 07:33:03 GMT

Estuve codificando una librería de algoritmos genéticos, usando C#. El código está en mi proyecto AjCodeKatas en Google Code dentro de:

http://code.google.com/p/ajcodekatas/source/browse/#svn/trunk/AjGa

El proyecto principal es AjGa (con AjGa.Tests para testing):

Las principales interfaces son:

Uso generics, con dos tipos genéricos: G, que es el tipo de implementación de un gen, y V como el tipo al que se evalúa un genoma (por ejemplo, int, double). Con ese valor se catalogan los genomas.

IPopulation es una colección de genomas.

IGenome es una colección de genes, que es evaluado a un valor de tipo V.

IEvaluator está a cargo de evaluar un genoma.

La implementación de IEvolution ejecuta generaciones sobre una población, que va cambiando, usando mutadores, operadores de cruzamiento, para irla modificando después de cada ejecución.

Hay interfaces para generar un genoma, mutar uno existente o hacer cruzamiento de dos genomas.

Para probar estas ideas, implementé un proyecto con gen, genoma, y operadores, que ataca el clásico problema del Travelling Salesman Problem, el vendedor que tiene que visitar una serie de ciudades, minimazando la distancia a recorrrer:

En este ejemplo, el evaluador tiene una lista de posiciones de ciudades a visitar:


    public class Evaluator : IEvaluator<int, int>
    {
        private List<Position> positions;

        public Evaluator(List<Position> positions)
        {
            this.positions = positions;
        }

El tipo de gen acá es int, y cada valor de genoma se expresa como un int. El genoma mantiene una lista de enteros, que representan el número ordinal de las ciudades a visitar:

    using AjGa;

    public class Genome : BaseGenome<int, int>
    {        
        public Genome(int size)
        {
            for (int k = 0; k < size; k++)
            {
                AddGene(k);
            }
        }

Esto es, cada gen es un int, y un genoma con genes 2, 0, 1, representa un viaje que visita la tercera ciudad, pasa por la primera, y termina en la segunda.

Podemos ejecutar el proyecto WinForm, para probar esta implementación:

En la ejecución de arriba, la distribución de ciudades es al azar. Las ciudades pueden ser distribuidas en una grilla:

De esta forma, podemos probar la eficiencia del algoritmo para encontrar un solución óptima, que en el caso de disponer las ciudades en grilla, se conoce de antemano.

Si queremos implementar un nuevo proyecto GA, tenemos que:

- Definir el tipo que tendrán los genes

- Definir el tipo valor a usar

- Escribir operadores (creadores, mutadores, cruzadores) de genomas

Los tests que tengo están en verde:

Buen Code coverage:

En 4 horas tuve la primera versión, gasté 3 horas explorando TSP, y cerca de 8 horas preparando y "tuneando" la aplicación WinForm.

Como de costumbre, ¡me divertí escribiendo este ejemplo!

Nos leemos!

Angel "Java" Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez

Clean Code Talks -- Herencia, Polimorfismo y Tests

lopez — Tue, 13 Jan 2009 09:15:54 GMT

Son un usuario fanático de Twitter. Una cuenta a la que sigo es @delicious_prog, que envía varios mensajes por día, relacionados con programación, desarrollo de software en general. En uno de esos tweets, encontré el post

The Clean Code Talks -- Inheritance, Polymorphism, & Testing

de Daniel Wild, donde incluye el vidio de una Google Talk:

(Please visit the site to view this media)

de Misko Hevery en Google Tech Talks.

Es claro e interesante. Es una charla explicando los usos del polimorfismo, y también, las formas de realizar test sobre métodos polimórficos. Me gusta encontrara en este vido varios argumentos similares a los que uso en mis charlas de desarrollo. Hace unos días, estuve usando polimorfirsmo en mi intérprete AjCat (un intérprete del lenguaje cat que me hizo conocer el bueno de @rodolfof):

http://code.google.com/p/ajcodekatas/source/browse/#svn/trunk/AjCat

Esta es mi implmentación de Integer Binary Operation:

    public abstract class IntegerBinaryOperation : Expression
    {
        public abstract int Apply(int op1, int op2);

        public override void Evaluate(Machine machine)
        {
            int op2 = (int) machine.Pop();
            int op1 = (int) machine.Pop();

            machine.Push(this.Apply(op1, op2));
        }
    }

Las operaciones Add y Subtract sobreescriben el método Apply:

    public class IntegerAddOperation : IntegerBinaryOperation
    {
        private static IntegerAddOperation instance = new IntegerAddOperation();

        private IntegerAddOperation()
        {
        }

        public static IntegerAddOperation Instance
        {
            get
            {
                return instance;
            }
        }

        public override int Apply(int op1, int op2)
        {
            return op1 + op2;
        }

        public override string ToString()
        {
            return "add_int";
        }
    }

    public class IntegerSubtractOperation : IntegerBinaryOperation
    {
        private static IntegerSubtractOperation instance = new IntegerSubtractOperation();

        private IntegerSubtractOperation()
        {
        }

        public static IntegerSubtractOperation Instance
        {
            get
            {
                return instance;
            }
        }

        public override int Apply(int op1, int op2)
        {
            return op1 - op2;
        }

        public override string ToString()
        {
            return "sub_int";
        }
    }

Es muy similar al ejemplo presentado en el video. Estuve algo más perezoso en mi implementación de operadores en AjPython (otro intérprete, de nuevo en C#, trabajo en progreso):

http://code.google.com/p/ajcodekatas/source/browse/#svn/trunk/AjPython

    public class BinaryOperatorExpression : BinaryExpression
    {
        private Operator @operator;

        public BinaryOperatorBLOCKED EXPRESSION;
        }
    }

Pero confío en refactorearlo, tengo espaldas para hacerlo, gracias una buena base de test ya escritos.

Es bueno encontrar este tipo de material, como esta charla, la recomiendo, gracias a @delicious_prog y a Daniel Wild!

Nos leemos!

Angel "Java" Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez