martes, julio 08, 2014

Ser o no ser... ese no es el dilema

El dilema es más simple... Llevo mucho tiempo escribiendo y armando un framework... pero no es público, es el que usamos como base para varios proyectos... el problema, es que el principal contribuyente de este he sido yo mismo... y funciona... y hace las cosas como a mi me parece que es lo correcto, y lo hace, en la mayoría de los casos, en forma elegante... pero no puedo llegar y escribir ejemplos usándolo ;) y tampoco puedo llegar y escribir otro, así de la nada, dos frameworks... dos veces... la pura idea me agota y no me motiva... mal que mal, para que hacer dos veces algo que ya en la primera funciona razonablemente bien... Entonces que puedo hacer... la verdad, o callarme (y sumergirme otra vez, por quien sabe cuanto tiempo y no escribir nada)... o hablar de las problemáticas, pero en genérico... o focalizarse en problemas concretos, cortitos... no sé, y mientras no sé, pasa un día y pasa otro (cada uno con un nuevo afán)... Como no tengo una respuesta, lo más simple, probar y probar a ver que resulta más cómodo, más fácil, que se escribe con más ligereza, qué palabras resultan menos forzadas...

miércoles, mayo 21, 2014

Interfaces, algunas ideas en paralelo

Tengo que darme el tiempo para continuar con el post de Mercurial, y al mismo tiempo, para comenzar a dar algunas vueltas sobre el desarrollo basado en interfaces... modelo de desarrollo que cada día me acomoda más...

Al desarrollar con interfaces tiendo a pensar en tomar un elemento, en este caso una clase, e ir decorándolo con atributos y/o características, sobrecargándolo semánticamente, viendo el problema que la clase ataca desde diferentes perspectivas, pero siempre dentro un modelo existente.

Esto significa que al contar con un conjunto pre-existente de interfaces, que ha ido evolucionando con el resto del proyecto, se han ido definiendo formas de enfrentar problemas diversos, pero de forma consistente.

Es quizás, ese grado de consistencia, y en muchos casos, elegancia en el resultado, el que me atrae de esta forma de programar, aún considerando las dificultades que este modelo y su curva de aprendizaje (uno debe entender la filosofía de las interfaces definidas para utilizar adecuadamente los concepto, en cierta forma, es como aprender una técnica para pintar un cuadro, digamos pintar con acuarela, en que se debe saber como difuminar los colores, el efecto de un poco más de agua, y las diferentes capas que interactuan o el orden en que se despliegan).

Un ejemplo práctico de este tipo de enfoque, si tenemos una interfaz para validar un elemento de un tipo dado, algo del estilo:

IValidacion:  bool Check(T value);
  string Message {get; }


Y se quiere procesar un Xml de nodos con data, en que se validarán el contenido de sus atributos.

Podemos definir algunos test generales, por ejemplo:
1) Test para verificar si un string es el path para un archivo que existe
2) Test para verificar si un valor es parte de un dominio

Las implementaciones de tales tests, sobre el modelo ya existente, es bastante simple, pero lo interesante es el siguiente paso, pues al analizar el procesamiento del archivo indicado, uno ve que es posible considerar una clase CheckConstraint que implementa IValidation y que tiene como propiedad una instancia de un test específico (Test), y el atributo dentro del nodo que debe ser validado, en este caso el método Check es algo de este estilo:

bool Check(XmlNode value)
{
  return (value!=null && Test.Check(value.Attributes[Field].Value));
}

y CheckConstraints es una colección de CheckConstraints que a su vez implementa la misma interfaz de IValidation, por lo que su método Check sería algo como:

bool Check(XmlNode value)
{
  bool retorno = true;  // Si la colección de Tests es vacía, entonces check da true

  foreach (IValidation test in Tests)
    retorno = retorno && test.Check(value);

  return retorno;
}

Luego tenemos una clase XmlConstraints que implementa IValidation y tiene una propiedad Test de tipo CheckConstraints, y por lo tanto sirve para aplicaa, a todos los nodos de una lista, las reglas de validación definidas, es decir, algo como:

bool Check(XmlNodeList value)
{
  bool retorno = true;
  foreach (XmlNode item in value)
    retorno = retorno && Test.Check(item);

  return retorno;
}

Como puede ver, la gracia de este modelo es que el código resultante es simple, mantenible y consistente, y fácilmente generalizable (que sería otra técnica que me gusta, el refactoring, que me recuerda a mi profesor de Algebra e Introducción al Cálculo... pero esa es otra historia de los tiempos anteriores a Noe).

Voy a escribir más de estas cosas cuando resuelva un dilema que tengo... y que dejo para explicar otro día...

lunes, abril 07, 2014

Como manejar ramas de desarrollo y no morir en el intento

En Subversion la respuesta es simple, estás muerto... A pesar de la literatura que pueda decir lo contrario, la práctica muestra que hacer merge de las distintas ramas en Subversion es un dolor de cabezas, y al final, en esa herramienta, la única forma de llegar a manejar las diferentes ramas es teniendo efectivamente diferentes ramas, es decir, generando un directorio clon del release correspondiente... al final, abuso del espacio y una forma poco elegante de resolver un problema que en teoría esta herramienta resuelve.

En Mercurial, a primera vista, la respuesta es simple... Mercurial fue diseñado con el merge en mente, por lo tanto, hasta cosas como gestionar cambios en archivos que han sido renombrados y otras proezas no es difícil... y en este caso, es cierto... aunque con un poco de letra chica.

En Mercurial hacer merge es simple, y manejar ramas, a primera vista resulta normal, pues de hecho si dos personas clonan un repositorio y comienzan a trabajar, implícitamente cada uno ha creado una rama diferente, que en su minuto deberá unificarse... y la clave del punto está en el "implícitamente", pues esto significa que ocurren cosas sin que el usuario tenga plena conciencia de lo que está ocurriendo, por lo mismo, tampoco tiene mucha claridad de que debe hacer, es factible, y ya me ha pasado en la vida real (esa en que los problemas nunca tienen como resultado un número bonito, como 2, 12 ó 34) en que al final, un desarrollador sigue en su rama, sin preocuparse de lo que le ocurre al resto, hasta que después de mucho, mucho, mucho avanzar (lease como hartos commits más tarde), viene el momento del merge, y los problemas aparecen.

Mercurial está pensado para hacer merges frecuentes, de hecho, aceptando las premisas de XP (Extreme Programming), la integración (merge) continua es lo deseable, pues encapsula el impacto de los cambios y facilita la detección del problema... y en este punto la realidad está de acuerdo con la literatura ;)
En ese sentido entonces, ¿cual es la mejor práctica para la gestión de ramas en Mercurial?

Breve paréntesis no tan breve ... Debo reconocer que he buscado en Internet (y he encontrado respuestas), y que he probado algunas, hasta formarme una opinión, y este post es justamente el resumen de mi opinión (y una descripción de las mejores prácticas que uno encuentra en internet).... o sea, un post del tipo "Yet Another Post About...", pero como la mayoría de la documentación que he encontrado está en inglés, digamos que es mi aporte para tener en español parte del conocimiento... fin del paréntesis.

En líneas generales, Mercurial permite los siguientes mecanismos de branching:

1) Implícito (no hay que hacer nada en especial, simplemente hacer commit en la rama default y luego sincronizar con un repositorio externo), en este modelo, lo relevante es hacer el correspondiente merge de una rama y la otra.

2) Con nombre, es decir, se crea explicitamente una nueva rama, en la cual se trabaja y se hacen los commits correspondientes, para luego hacer merge con la rama principal.

3) Utilizar la clonación del repositorio y trabajar en el repositorio clonado en forma independiente.

La 3era permite a su vez utilizar el branching implícito o con nombre... ahora, el punto relevante de este punto es como hacer el merge, pues un mal manejo de este tema lleva finalmente a un repositorio con la historia totalmente desordenada, difícil de entender.

La idea de los próximos posts son explicar cada uno de estos mecanismos (con sus ventajas y desventajas), y luego avanzar en la definición de las líneas relevantes de una estrategia de branching, que ayude a contar con una estructura ordenada.

Back to the Past (parte del Intermezzo)

Hmmm, releyendo y releyendo, reencontrando al Alejandro de entonces, me pillé con un post, del cual rescato esencialmente el nombre del proyecto... NPerseo, me gustó la definición:

 "N por .NET y Perseo por el heroe griego que mató a Medusa."
Ahora, no pretendo hacer lo que supuestamente hacía la herramienta original (supongo que si me pongo a cachurear, en algún disco duro aún estará el código)... sino darle ese nombre al proyecto donde pondré las cosas que escribiré para este blog... porque mal que mal, son muchas las serpientes que tiene la cabeza de la medusa... y muchas las que uno se encuentra...

domingo, abril 06, 2014

Intermezzo

He releído varios posts.... la mayoría más bien tipo Tumblr o casi Twitter... breves, con algo de contexto, un poco de información, algo así como encontré algo interesante y lo "re-posteo" aquí... respetable, pero hoy eso es más simple con Google+, Facebook o los mismos Tumblr o Twitter, así que he decidido darle un toque más práctico a todo esto, a ver, si en la pasada, el blog tiene más lecturas que yo mismo cada 4 ó 5 años :)...


Asi que, aprovechando el tema del post anterior, he creado un repositorio en Bitbucket (un repositorio de Mercurial), para ir juntando allí las ideas que vayan saliendo de estas líneas... porqué Bitbucket, por que es gratis, sin límites de archivos o volumen, y porque permite tener un repositorio listo de Mercurial, con herramienta de seguimiento de incidentes y wiki en .... 1 segundo?

Ahora, si uno quiere bajar el contenido es simple, basta tener Mercurial instalado y ejecutar:

mkdir /path/to/your/project cd /path/to/your/project hg clone https://adiazsanti@bitbucket.org/adiazsanti/blog

Las dos primeras líneas son triviales, y son crear el directorio y moverse a él, y la tercera, toda la magia....

Ahora, si como yo se tiene TortoiseHg, entonces es aún más simple, creamos el directorio, nos paramos en él, botón derecho y "TortoiseHg/Clone" y como fuente:

https://adiazsanti@bitbucket.org/adiazsanti/blog

Y voilá.... el repositorio listo en el equipo (en este instante... sólo un directorio vacío).... Ahora como buena hoja en blanco hay que ver como llenarla XD

Subversión versus Mercurial

5 años atrás usaba Subversion, aún lo hago, es la herramienta oficial en la oficina, pero, desde entonces me he vuelto un fan de otra herramienta, Mercurial, en que el control de las versiones es distribuido y no centralizado como en Svn.

No es Git, bastante más famoso, pero todos los reviews que he leído (no he usado Git, así que me debo conformar con los reviews) apuntan a que con funcionalidades similares Mercurial es una herramienta más "amigable" frente a una solución más de múltiples herramientas que permiten hacer casi cualquier cosa... Incluido el modificar la historia (quizás por ese punto en particular es que no me atrae, tengo un tema más bien filosófico al respecto).... 
Ahora, para qué cambiar de uno a otro.... subversion no es malo, de hecho es una excelente herramienta, sólida y con una base de desarrollo sólida... Pero tiene algunos problemas, y son esos problemas los que me acercaron a Mercurial.

  1. Subversión es un gran repositorio, con múltiples proyectos, que crece y crece, y del cual uno sólo ve las ramas específicas que baja. Eso supone cada vez más esfuerzos de mantención, por el otro lado, Mercurial es un repositorio un proyecto, bastante más auto contenido.
  2. En Subversión uno hace commit o demasiado pronto o demasiado tarde, me explico, sí uno está desarrollando algo, digamos que tome algunos días, o hace commits intermedios, "contaminado" el repositorio central con código incompleto, que puede que hagan que la aplicación falle, o uno se espera hasta el último minuto, después de terminar y probar bien lo que hizo, y recién hace el commit (por ende, durante todo el tiempo en que uno desarrolló lo hizo SIN control de versiones). En Mercurial, al tener repositorios distribuidos, uno puede realizar el desarrollo, hacer commits en el repositorio local (y por lo tanto tener la flexibilidad de regresar a un punto intermedio, o el analizar los cambios que se hicieron en forma más específica), y una vez que está listo puede sincronizarse con el servidor principal, e incluso, si durante el desarrollo, algo que uno hizo puede ser utilizado por otra persona (sin esperar que esté terminado el total), sincronizando los repositorios personales, sin pasar por el servidor central.
  3. En Subversión la conexión al servidor central es un requisito al hacer commit, el poder trabajar off-line, haciendo commits, no es factible. En Mercurial, el repositorio local está en el mismo disco, por lo cual no es necesaria una conexión, sólo cuando se debe hacer sincronización con el servidor central.
  4. Subversion tiene un modelo relativamente inflexible para trabajar, mientras que Mercurial permite armar el modelo que más le acomode, por ejemplo, un servidor local y repositorios locales (igual que en Subversion pero con capacidad de aplicar control de versiones al trabajo intermedio), o por ejemplo, un servidor central de desarrollo, uno de paso a producción y uno de código en producción, o en realidad el modelo que a uno le parezca más apropiado.
Ahora, Mercurial no es puras rosas, el modelo distribuido es más complejo de explicar, y requiere de mayor esfuerzo por quienes lo utilizan (es fácil olvidarse de pasos)... en ese sentido, dos artículos son buenos para poder entender mejor como funciona Mercurial versus Subversion, el primero, un tutorial (Hg Init, de Joel Spolsky), con un capítulo especial de "re-educación" para usuarios de Subversion, y un libro on-line de Eric Sink que en una forma bastante didáctica explica la forma de hacer las tareas en una herramienta u otra.

De hecho, una de las ventajas que suelen indicar respecto a Mercurial es su capacidad para manejar exitosamente ramas, pero no es tan simple la verdad, y es materia para otro post el comentar un poco más de ese punto....

sábado, abril 05, 2014

Y si uno de estos días....

Si hay un tema del que nunca he sabido mucho y sólo he usado lo mínimo necesario, algo así como la gente que con tres o cuatro frases en inglés sobreviven de viaje es de los temas de diseño en el HTML.... Este libro pareciera ser un punto de inicio... https://itunes.apple.com/es/book/gran-libro-html5-css3-y-javascript/id679338364?ign-mpt=uo%3D2 A ver si me doy el tiempo para avanzar en este tema XD

5 Años no es nada, que febril la mirada

El tango dice 20, pero tengo botado este sitio por 5, tanto tiempo que la verdad, no recuerdo bien que he escrito, pero si, que últimamente he decidido volver a escribir de este tipo de temas, en forma más sistemática (principalmente después de ver unos tutoriales sobre trabajo en madera... a primera vista puede que no tenga mucho que ver, pero a veces hay relaciones más sutiles entre las cosas...)

Mi idea es enfocarme a postear regularmente, una a dos veces por semana, y hacerlo en forma más ordenada.... vamos a ver que resulta (si en 5 años más me encuentro que este fue el único post, uno de esos en mitad de una noche temblorosa... como referencia hace unos días fue el terremoto de Iquique y hace una hora un temblor bastante fuerte y prolongado de 5,4 en la escala de Richter... entonces veré si simplemente borro lo que hay ;) o, en una de esas, mi intención resulta y comenzamos a poblar esto con post, espero útiles a mi y a alguna que otra persona), también es mi intención darle una vuelta de como hacer el blog más visible... ya veremos como me va...

lunes, agosto 11, 2008

Para tener en mente

¿Abré dicho alguna vez que odio las grillas ;-) ?

La verdad, es que es así, pues por lo general son controles con muchos casos particulares y manejos oscuros (aunque tengo buenos recuerdos de DataWidgets, la primera versión, era simple y funcionaba, y venía en una cajita bien bonita, con un manual bien impreso y costaba 100 dolares... a diferencia de otro producto, que compramos en esas mismas fechas, que venía en un diskette roñoso, con manual fotocopiado y costaba 1.100 o 1.200 dolares ;-) )

Lo malo, es que son necesarias, todo el mundo espera que se usen en las aplicaciones, y lo que es peor, la versión básica que trae ASP.NET para mostrar registros en forma tabular, tiene una pifia a la hora de manejar bien la paginación... y es algo aceptado ... "por diseño" (por que uno no puede decir lo mismo ;-) )

Asi que,  siempre a la caza de una buena grilla dejo este link para posterior revisión y comentario:

Blogged with the Flock Browser

Buenas ideas

Uno no sabe nunca cuando va a encontrarse con una buena idea vagando por allí. A modo de despejar la mente, mientras escribía una presentación llegué a este sitio:

Y leyendo sin demasiado detalle (los códigos en gris con fondo blanco y letra minúscula, incluso para mi, no hacen que la lectura sea muy interesante) me encontré con unas línas que me intrigaron:

    // set up an option parser
var p = new OptionSet () {
{ "n|number=", "The planet number to greet",
(int v) => planetNum = (v < planet.Length ? v : 0) }
};
p.Parse (argv);

Además de estar usando C# 3.0, el darme cuenta que estaba parseando la línea de comandos, cosa de por si interesante, asi que miré un poco más y llegué a:

Para tener en cuenta más adelante ;-)
Blogged with the Flock Browser