Otra vez Rob Conery. esto es más un tweet que un post. Rob escribe sobre BDD, un post interesante, lo voy a leer en profundidad y compararlo con las técnicas que nosotros utilizamos. Por ahora y como comentario BDD funciona, aporta claridad y se puede complementar con TDD (y buenos User Stories por supuesto). Vuelven los post y espero que sea una vuelta que se mantenga en el tiempo.
Por distintas razones me había quedado con las ganas de ver como funcionaba el formato del Open Space. Y por otro lado ahora que los conceptos de Agile dejaron en mi de ser meramente teóricos para convertirse en la practica del día a día.
A pesar de ser complicado arrancar un sábado a las 9. Un rato después allí estaba. Como siempre la gente de Agiles tiene todo organizado en forma espectacular. Todo funciona.
Ahora viendo un poco las cosas que me sorprendieron. Primero que a pesar de no haber sido el lugar físico el mas convocante (hay temitas en La Plata) se junto bastante gente y con el cope de que no solo había interés por lo ágil sino mucho conocimiento y experiencias.
En los temas que participe fueron de comunicaciones en equipos distribuidos geográficamente (tema propuesto por mi, dado que es algo que me preocupa ahora particularmente). Éramos pocos pero pudimos charlar algunas cosas interesantes. Principalmente medios de comunicación ilimitados. Preferentemente viajes periódicos. etc.
Después participe en un debate sobre las comunicaciones de los proyectos (no me intereso demasiado). Participe en una reunión sobre herramientas, surgieron algunos datos interesantes. Y por ultimo en la de retrospectiva que estuvo muy interesante. Ya que por ser intima pudimos charlar sobre el valor real de la retrospectiva y sus diferencias con las Lecciones Aprendidas.
No me pude quedar hasta el final, pero tengo varias conclusiones. Como metodología el Open Space es muy útil, e interesante. El grupo de Agiles sigue haciendo encuentro que aportan muchísimo a la comunidad. Ahora espera Florianopolis.
Para la resolución del primer problema del Proyecto Euler hice un extension method:
public static class IntExtension
{
public static bool IsMultiplesOf (this int number, int multiple)
{
return (number % multiple) == 0;
}
}
i.IsMultiplesOf(3)
Proyecto Euler tiene como objetivo mostrarnos diferentes problemas matemáticos o computacionales que deberemos resolver. A pesar que una persona con mayores conocimientos matemáticos podrá resolver algunos de los problemas sencillamente, para la solución de los mismos se requiere del uso de software.
A modo de prueba la solución de los dos primeros no me demoro en C# más de 10 minutos. Ahora para complicarme un poco más las cosas voy a intentar resolver los siguientes en Python y aprovechar para probar un poco de Ruby
En la búsqueda de información sobre refactoring de código me encontré con éste interesante post de Anders Noras que me condujo a conocer The Oblique Strategies.
The Oblique Statregies son un conjunto de cartas creadas por Brian Eno y Peter Schmidt en 1975 Cada carta contiene una frase o mención críptica que puede ser utilizada para romper un bloqueo o un dilema.
Algunos ejemplos:
- Exprese el problema en palabras lo más claramente posible
- Sólo un elemento de cada tipo
- ¿Qué haría su amigo más cercano?
- ¿Qué incrementar? ¿Qué disminuir?
- ¿Son éstas secciones? Considérelas transiciones.
- Intente falsificarlo!
- Honre el error como una intención oculta
Original y traducción libre
Para obtener la versión original hay muchas opciones, entre ellas éste PDF para imprimirlas. Me tomé el atrevimiento de hacer una traducción y libre y generar una mini aplicación Silverlight que nos de una carta al azar para ayudarnos a romper con los deadlocks creativos. La aplicación viene en próximo post.
Brian Eno
No voy a contar mucho sobre Brian Eno, pero como es un blog de tecnologías, sólo voy a poner un link a una de sus últimas creaciones Bloom, una aplicación para IPhone que es un flash.
Para los lectores de blogs tecnológicos, particularmente los interesados en temas de .Net los nombres 
de Phil Haackman, Scott Hanselman, Rob Conery y Scott Guthrie les deben sonar conocidos. Son artifices del Microsoft como lo conocemos actualmente, en distinto grado de responsabilidad. Pero particularmente son tipos muy interesados en transmitir sus conocimientos.
Es en esa dirección que publican ahora un libro sobre Asp.Net MVC llamado Professional Asp.Net MVC 1.0 y lo liberan al mercado junto al proyecto NerdDinner, que es el primer capítulo como tutorial, es proyecto que se puede bajar y es también sitio en vivo para poder ver el proyecto en acción.
Es muy interesante el tutorial y aunque se pueden objetar muchas cosas (como en todo) del estilo, porqué no se utilizó TDD, porque el uso de repository no es tan respetuoso del patron, etc. Pero dándole la derecha a éstos cuatro grossos, lo recomiendo sobremanera como forma de iniciarse en MVC.
Algunas reflexiones sobre el trabajo distribuido. Estaba pensando como mejorar la problemática del trabajo distribuido. Supongamos el hipotético caso de dos grupos trabajando en diferentes países en un gran proyecto que engloba un desarrollo Core y una extensión para el país.
Llamaremos a los grupos Core y País. Core tiene que desarrollar la funcionalidad general de tal manera que sea extensible, customizable en cada país y dentro de cada país en cada desarrollo particular. Les recuerdo que éste es un caso hipotético que no tiene ningún basamento en la realidad, sólo nos sirve para ver distintas implicancias del trabajo distribuido.
El equipo Core desarrolla tres tipos de tareas principalmente: agregar funcionalidad Core nueva, eliminar bugs y prestar soporte al equipo País, dado que puede tener menor conocimiento técnico y metodológico.
El equipo Pais por su parte realiza las siguientes tareas: extiende la capa país, corrige bugs en su capa, carga solicitudes de solución de bugs en la capa Core, implementa su producto.
Ahora visitemos un poco lo técnico, el equipo Core cada vez que agrega nueva funcionalidad compila, integra, corre tests, realiza pruebas automatizadas y publica una versión al equipo País, el cual toma las DLL del producto y pisa en su librería Core y continúa su extensión. Cada vez que el equipo País, agrega cierta funcionalidad realiza un proceso análogo.
Con los bugs es algo similiar, con la diferencia que cuando se resuelven un grupos de bugs y los mismos integran una versión, la misma puede ser sólo de solución de bugs, el número de versión sólo cambia el build y no el minor como cuando se publica nueva funcionalidad.
Hasta aquí un mundo bastante ideal.
Compliquemos las cosas
Ahora supongamos, siguiendo en el campo de la irrealidad, que el equipo Core (que es el que tiene el conocimiento técnico) se ve diezmado por temas de actualidad laboral.
Entonces la delgada línea que separaba los equipos se disuelve. Todos pueden tocar cualquiera de los dos proyectos.(Primer error se pierde administración y governance)
Compliquemos un poco más. El equipo País decide que dado que pueden tocar el Core, entonces porqué esperar una versión de Core, si podemos actualizarnos las DLL cada vez que modificamos algo en Core? (Segundo error se pierde traza, se genera inestabilidad)
Siguiendo la línea del caos (no el creativo o interesante y ágil), el equipo País realiza modificaciones en Core que les son suficientes para su capa País, pero se despreocupan por el estado de Core (compila, pero no necesariamente pasa test, se integra o simplemente sigue funcionando, se rompen interfaces) (Tercer error se piede la integración, consistencia y producto)
Conclusión
Siguiendo en ésta línea se podría continuar, pero creo que es ejemplo suficiente. A partir de éste momento hay que tomar muchas decisiones. ¿Que harías vos con éste hipotético caso? Me gustaría tener opiniones.
Disclaimer
Todo surge de una febril imaginación del autor, ningún personaje o situación tiene relación con la realidad. No fueron dañados animales en la realización del post.
Pensaba hacer un post sobre los podcast tecnológicos que escucho. 
Sin embargo viendo ésta pregunta en Stackoverflow, creo que responde en forma más amplia.
Mis top six son:
Update! Scott Hanselman se inspiró en mi y puso esté post de Podcast para programadores.
Estaba escuchando un podcast de HerdingCode (esto me da pie para un próximo post sobre los podcast que escucho, thanks to commute!) donde Phil Haack habla sobre Asp.Net MVC. Y aprovechando la salida del RC (Release Candidate) podemos discutir algunos temas. (Más info sobre el patrón MVC)
Ante la pregunta de cual es el elevator speech que Phil utilizaría para describir Asp.Net MVC para alguien que utiliza Asp.Net webforms, Phil contesta:
Si utilizás Webforms y estás felíz, entonces ignorá MVC. Si sos muy productivo con Webforms, MVC no va a reemplazar Webforms. Pero los beneficios de utilizar MVC son varios: nos pone nuevamente en control de nuestra aplicación (por ejemplo los controles de Webforms generan mucho markup que si no hacen lo que deseamos puede ser complicado), otro beneficio es que el patrón arquitectónico de MVC es muy bueno en lo que respecta a la separación de conceptos, lo que permite aplicaciones más mantenibles y testeables (valgan los neologismos). Temas que no estaban tan en boga en la creación de Webforms.
Un ejemplo
Una pequeña aplicación que me permite almacenar los gastos diarios (me agarró la paranoia).
El modelo lo forman categorías y gastos.
La persistencia del mismo es a través de Entity Framework (del cual no voy a empezar una discusión, porque Gus tiene muchos argumentos en contra)
Una parte del ExpenseController de ejemplo:
[AcceptVerbs(HttpVerbs.Post)]
public ActionResult Create(FormCollection collection)
{
try
{
var expenseToCreate = new Expense();
Category category = new Category();
UpdateModel(expenseToCreate, new[]{"Date", "Amount", "Description"});
UpdateModel(category, new[]{"CategoryId"});
expenseToCreate.Category = _db.Category
.Where(cate => cate.CategoryId == category
.CategoryId).First();
_db.AddToExpense(expenseToCreate);
_db.SaveChanges();
return RedirectToAction("Index", "Home");
}
catch (Exception exep)
{
return RedirectToAction("Error");
}
}
Esta es la acción de crear un nuevo gasto. Acá y por culpa de no poder utilizar el SelecList.SelectedValue, tuve que hacer algo más rebuscado.
Por último, una parte de la View que representa el Create:
<fieldset>
<legend>Fields</legend>
<p>
<label for="Date">
Date:</label>
<%= Html.TextBox("Date") %>
<%= Html.ValidationMessage("Date", "*") %>
</p>
<p>
<label for="Amount">
Amount:</label>
<%= Html.TextBox("Amount") %>
<%= Html.ValidationMessage("Amount", "*") %>
</p>
<p>
<label for="Description">
Description:</label>
<%= Html.TextBox("Description") %>
<%= Html.ValidationMessage("Description", "*") %>
</p>
<p>
<select size="5" name="CategoryId" id="CategoryId">
<option value="0" selected="selected">Sin seleccionar categoría</option>
<% foreach (Category category in (IList)ViewData["Categories"])
{ %>
<%= "<option value='" + category.CategoryId + "'>" +
category.SmallDescription + "</option>" %>
<%} %>
</select>
<br />
<%= Html.ActionLink("Crear Categoria nueva", "Create", "Categories") %>
</p>
<p>
<input type="submit" value="Create" />
</p>
</fieldset>
En la misma se ve como resolví el tema de no poder utilizar un Helper Method de la entidad Html (como Html.ListBox o Html.DropDownList) debido al problema del SelectList.
Es un pequeño ejemplo. Se encuentran muchos en internet, no intento hacer un tutorial, pero si les interesa el código no tienen más que pedirlo.
Felicidad
Siguiendo con el concepto de Phil Haack, aquellos que no éramos felices con Asp.Net Webforms, nos encontramos con la chance de encontrar la felicidad en éste camino de desarrollo.
Como seguir
El RC tiene todavía algunos problemas, por ejemplo tuve muchos problemas queriendo utilizar un SelectList (lista para Views) y obtener el SelectedValue. Nunca lo logré y tuve que utilizar otras formas. Tal vez sea problemas que se solucionen en la versión definitiva, hay que tener en cuenta que es un proyecto (MVC) con mucho tiempo y mucha gente muy interesante y capaz atrás. Seguimos atentos.
“Resisten la bomba atómica, pero no sobreviven a un simple zapato!”
Esta frase la escuché el otro día en la calle y la mujer hablaba de las cucarachas. Me quedó dando vueltas y hoy le encontré el real sentido.
El escenario es una aplicación (no pensaban que iba a hablar de cucarachas, la lección es sobre bugs) con años de desarrollo, varias versiones en producción y una funcionalidad que el folklore de users+team la había declarado como TO DO.
Sin embargo la funcionalidad existía en el código y lo único que ocurría era que ciertos bugs (a partir de ahora los puedo llamar cucarachas) nunca se habían corregido. En relación, el desarrollo original de la funcionalidad había sido como resistir a la bomba atómica, y por culpa de un simple zapato el valor nunca llegó al cliente.
Cada cual que genere su propia moraleja.
Al parecer un gran mercado se está moviendo en éste sentido. Y a pesar de todas las posibilidades que brindan los dispositivos actualmente para acceder a internet, que tal si queremos realizar una aplicación para los dispositivos?
Voy a fijarme un poco en lo que son los principales SO para dispositivos móviles (por favor, favoritismos aparte, pude olvidarme de algunos, por ejemplo Symbian o Blackberry, sólo quiero hacer una enumeración general).
Windows mobile
Windows mobile es una plataforma conocida (al menos para mi), casi cualquier programador .Net (a mi juego me han llamado) a jugado alguna vez con el .Net Compact Framework. El desarrollo desde el Visual Studio es muy sencillo, en la parte 2 del post voy a incluir un ejemplo sencillo.
Android
El SO Android, un proyecto de la Open Handset Alliance, es un desarrollo Open Source de Google. Aunque actualmente sólo existe un teléfono, HTC G1, es probable que el 2009 veamos una explosión (a al menos varios modelos).
Para desarrollar una simple aplicación (el ejemplo provisto con el SDK de Android es HelloAndroid) me tuve que meter en un mundo poco conocido por mí, y debo decir que quedé gratamente sorprendido.
Bajé el Eclipse, el SDK de Android, instalé el Eclipse, que anduvo sin problemas desde el primer momento, instalé el plugin para el desarrollo de Android en el Eclipse. Y voilá, ya estamos funcionando. Debo decir que además de que en 15 minutos estaba funcionando no tuve que regsitrarme en ningún sitio!
En el segundo post de la serie voy a mostrar el ejemplo desarrollado, pero mientras tanto les dejo una imagen del emulador con mi aplicación (HelloAndroid) funcionando.
Apple IPhone
El desarrollo para el IPhone, es otro tema. Para este caso tenemos que registrarnos, debemos utilizar las herramientas provistas por Apple (esto es similar en todos los casos), utilizar ObjetiveC como lenguaje (a leer!) y si queremos participar del mundo de las aplicaciones para IPhone (aunque no querramos lucrar) tenemos que participar del IPhone Developer Program que tiene costo.
Tal vez pueda hacer algo en éste terreno también.
Primera conclusión
Hay un mercado muy interesante para aplicaciones para dispositivos móviles, y además resulta muy interesante ver como la interacción con otras cosa que nos resultaban inimaginables en el desarrollo para desktop o para web, como por ejemplo la interacción con GPS, acelerómetros, voz, cámáras, etc. generan un montón de posibilidades para los que nos gusta jugar!. Como ejemplo se pueden ver miles de aplicaciones locas e interesantes para el IPhone en el repositorio de ITunes o los resultados del Android Development Challenge de Google.
Lo que me interesa es, dado que estoy viendo las distintas tecnologías de presentación, como se puede implementar en WPF el primero de los puntos. Improper Input Validation.
Existe en WPF una clase base abstracta llamada ValidationRule. Verifiquemos si el título del post tiene sentido. ValidationRule, Rules?
Un ejemplo de implementación de los miembros de la clase (MandatoryValidationRule es una clase que verifica que el valor no sea nulo o un string vacío)
public class MandatoryValidationRule : ValidationRule
{
public override ValidationResult
Validate(object value, System.Globalization.CultureInfo cultureInfo)
{
return
String.IsNullOrEmpty((string)value) ?
new ValidationResult(false, "Value is Mandatory") : new ValidationResult(true, null);
}
}
Un ejemplo de uso de la clase en el XAML (simlpemente bindeamos (neologismo ampliamente aceptado) la ValidationRule)
<TextBox Name="textBox1"Width="50"FontSize="15"
Validation.ErrorTemplate="{StaticResource validationTemplate}"
Style="{StaticResource textBoxInError}"
Grid.Row="1"Grid.Column="1"Margin="2">
<TextBox.Text>
<Binding Path="Name"
UpdateSourceTrigger="PropertyChanged" >
<Binding.ValidationRules>
<c:MandatoryValidationRule/>
</Binding.ValidationRules>
</Binding>
</TextBox.Text>
</TextBox>
Por lo visto no es tan complejo y al estar utilizado directamente en el lenguaje declarativo podemos tener muchas posibilidades de manejo de estilos, recusos, templates, etc.
No se si concluir que es una buena forma o no de validar, sin embargo podemos ver un buen post de Josh Smith que nos puede dar un poco más de elementos para juzgar.
Esto se puede ver en miles de blogs. 
Al parecer un viaje Buenos Aires-Villa Elisa alcanza.
Update: alcanza el tiempo, pero no la batería.
Entradas
