Lenguajes como novias

Si, seguro que también alguno de vosotros os habéis dejado seducir por otros lenguajes de programación. Los que comenzamos a tener una edad, seguro que hemos pasado ya por varios.

En estos momentos soy un PDP, Programador Dependiente de la Plataforma, de modo que mis opciones en cuanto a la elección del lenguaje quedan por el momento un poquito limitadas.

Sin embargo, adoro la programación y siempre trato de probar todo lo que puedo, antes programaba en Python, muchas utilidades y desde hace algún tiempo es Ruby, el que me tiene “loquito”. Me gustan y flirteo con ellos, pero a muchos de ellos nunca les puedo dedicarles todo tiempo que me gustaría.

Ayer por la noche, leyendo el blog de Ruby, di con este post “7 reasons I switched back to PHP after 2 years on Rails” de Derek Sivers. 

Derek, como se desprende del post, se enamoró de Ruby y lo dejo todo, hasta el momento en que se pregunto si había algo en RUBY que no pudiera hacer con PHP, bueno, no soy quién para decir si dos años es poco o mucho tiempo, creo que es más de los 5 minutos con los que muchos se enamoran de Ruby viendo esas demos tan cañeras y tiempo suficiente para tener un conocimiento profundo de Ruby.
Aunque conozco PHP y RUBY, tampoco puedo decir con rotundidad si se puede hacer todo lo que se hace en PHP en RUBY y todo lo que se hace en RUBY en PHP.

Pero puedo aventurar que sí que se puede. Obviamente el esfuerzo que se debe emplear y/o el resultado que se obtiene puede que no tengan nada que ver en este caso.

Ahora suponiendo por un momento que tenemos dos lenguajes, con los que se puede hacer lo mismo, con el mismo esfuerzo y con los mismos resultados. ¿Cuál escogerías?   (Vb.Net y C#)

Casi con toda seguridad, aquel con el que te encuentres más cómodo. De modo que entiendo a Derek,  aunque no esté del todo  en esta misma disyuntiva.

Pero si él se siente más agustito con su PHP, ¿Por qué no continuar? ¿Quiénes somos los demás para decirle que no cambie?

Por un momento imagina que tienes Java en las venas, que lo lees todo, que escribes un blog de Java, que participas en charlas y conferencias etc… , pero en tu trabajo de 8 a la hora que sea, tú jefe te hace escribir código en (Vb ó C#). ¿Qué harías si fueras tú propio jefe?

En mi caso las decisiones en cuanto a los cambios de lenguaje han venido ocasionadas por un cambio de trabajo o por un cambio de plataforma. Y el conocimiento de muchos otros por mera inquietud. Y puedo decir que de todos he aprendido algo. Y que siempre hay unos con los que te sientes más cómodo que con otros.

Durante una temporada programe en Multibase, un 4GL de Transtools, parecido al 4GL Informix, y aunque era muy potente y programe muchas cosas, nunca me sentí tan agusto como con Clipper que era el lenguaje con el que había programado antes.

En cualquier caso no deja de ser divertido el revuelo que ha levantado al reconocerlo públicamente en el blog de Ruby en O’Reilly, ya que no suele ser una cosa normal (344 comentarios, esta mañana). 

Derek, nos ha dejado un poquito de su experiencia, lo que es de agradecer, ya que este tipo de cosas son enriquecedoras, se podrá estar más o menos de acuerdo con su decisión, pero al fin y al cabo es a él al que le afecta.

La gente prueba y se equivoca, se equivoca y prueba de nuevo. Incluso con el tiempo se prueba otra vez algo que ya se probó… para ver si ha cambiado.

Dentro de las 7 razones hay una que me gusta especialmente, “PROGRAMMING LANGUAGES ARE LIKE GIRLFRIENDS: THE NEW ONE IS BETTER BECAUSE *YOU* ARE BETTER

Vista pasa por la óptica

ó Vista usará gafas

Así es, para ver mejor. Y en este caso no como las de Ciclope “slim” de x-men que las necesita para no andar destrozándolo todo con su poderosa visión.

Hace unos días en hotfix.com se hablaba de



Sin embargo hoy era el día en que se abría la óptica para unos 10.000 cieguillos (no de fin de semana) que podrían probar la tan esperada lente correctora.

Esa  con la que se podrá Ver  lo que no se Vio, Velocidad…  y al parecer el asunto funciona 🙂 yo pobre cieguito…  desde que abandone la XP (Programación eXtrema) y digo esto ya que comparado con lo que tengo aquello era eXtremo de verdad, estoy probando las maravillosas lentes correctoras y de momento puedo decir que Veo mejor.

¿Que yo que sé? con lo del NDA, (Nunca Devuelvas hAcienda) lo que se puede decir o no….

Y el 7º Dia Descanso

Y el séptimo día, descansó


¿Pero? ¿Y si hubiera tenido que seguir un día tras otro y una semana tras otra? Más o menos lo que nos pasa a los desarrolladores, el trabajo nunca termina, con una línea completas un método, con un método una clase, con una clase un caso de uso un espacio de nombres, una biblioteca… siempre habrá detrás otra nueva clase, otra nueva biblioteca y así sin parar.

Un día tras otro…  codificando, depurando, compilando, probando, no pongo meando porque a veces creo que me lo puedo hacer encima por no despegar los dedos del teclado …

Y a todo esto, cientos y cientos de tecnologías a nuestro alrededor que cambian constantemente, ¿y si a Dios le hubiesen cambiado las especificaciones una y otra vez?, y ¿si cada día hubiera tenido una nueva tecnología a su alcance?

Sinceramente, el mundo estaría por hacer. Sólo con el tiempo que lleva aprender, probar, crear un manual de buenas prácticas y realizar un framework adaptable y extensible y bla bla bla, para poder empezar a trabajar… estaría todavía diseñando a Adán.

Y eso gracias a que no dejo que Adán  diera las especificaciones de Eva, porque todavía estaríamos esperando… (Lo digo sin ánimo de ser machista), porque estaríamos  todavía en alguna iteración de la metodología divina, comprobando si el modelo cumple con las especificaciones del cliente.

En fin, si las cosas fueron así de rápidas supongo que serian por que no había, “cliente” y ¿si no había cliente?, ¿si no había especificaciones?, siempre me quedaré con la duda si se pudo hacer  en 5 ó incluso en 4 días y se demoró el asunto. Digo yo, que siendo Dios, podía haberlo hecho todo en UNO, Mundo y Ploffff, toma MUNDO.

De modo que no me queda más que pensar que uso algún tipo de metodología para acometer el trabajo. ¿Cuál?, ¿Cómo hacer un mundo en 6 días y descansar el 7º? ó tal vez usó ¿Cómo hacer el mundo en 4 días y descansar 3?, desde luego que si uso esta no consiguió su objetivo, a pesar de la metodología.

Creo que nos quedaremos sin saberlo…

Volviendo al asunto, que en absoluto es la metodología, si no la gran cantidad de tecnologías de las que disponemos, y la gran cantidad de las que dispondremos en breve.  Haciendo un pequeño resumen de las que necesitamos para desarrollar, pongamos por ejemplo SharePoint… un lenguaje .Net(C# ó VB.Net), Html, ASP.Net, XML, XSLT, JavaScript, Windows Workflow Foundation, InfoPath, TSQL, un SDK gordito y sin ejemplos, con más de 120Mb, 98 NameSpaces y 1.256 clases…

¿Sabéis una cosa? Yo quiero, que llegue el 7º Día.

SharePoint – WebParts para la Navegacion


Tres webparts para mejorar la navegabilidad en nuestros sitios de SharePoint. Si bien es cierto que la navegabilidad de los sitios de SharePoint 2007, ha mejorado mucho desde el 2003, yo he echado en falta estos que me solucionan algunas cosas.


FolderBreadCrumb WebPart


Esta pensado para trabajar con listas y bibliotecas de documentos que usan el ListViewWebPart, como comenté anteriormente (http://www.ideseg.com/SharePointTreeExplorerWebpart.aspx) que el botón de subir una carpeta había desaparecido, lo que hago ahora es dejar al ListViewWebPart sin título y encima le añado este webpart para poder navegar por las carpetas. Además (esta mal que yo lo diga pero) queda chulo y así se sabe en que carpeta se encuentra uno. 


Permite especificar el número de niveles que se desea que aparezcan (por defecto 3).



FolderExplorer WebPart


Este es ya un clásico, pero en esta versión he corregido algunas cosas y permite tener más de uno en la misma página sin que se vuelva loco. También podemos especificar la imagen que deseamos que aparezca y el número de niveles abiertos la primera vez que se abre.



WebExplorer WebPart


Otro clásico, pero en esta versión podemos especificar la url del sitio desde donde queremos ver los sub webs. También permite especificar una imagen así como el número de niveles que queremos tener abiertos la primera vez. Otra propiedad es que nos permite aplicar un sencillo filtro para incluir solo los subsitios en donde el titulo contiene una determinada palabra.




 IdeSeg.SharePoint.WebParts.Navigation

SharePoint – CAML.Net genial

Jhon Holliday (tambien MVP de SharePoint) lidera un proyecto llamado CAML.Net, que es una manera muy inteligente de integrar las consultas CAML en cualquier lenguaje .Net, con CAML.Net podemos mantener la estructura de las consultas de una manera intuitiva y natural, permitiéndonos construir componentes reusables.
 
Además podemos realizar data-bindings con los resultados devueltos por las consultas, de manera brillante. Además está trabajando en un editor visual que tiene un aspecto excelente.

Podéis leer más sobre CAML.Net en:

Working with CAML.Net – Part 1
Working with CAML.Net – Part 2 (Introducing the CAML)

y el proyecto está en CodePlex http://codeplex.com/camldotnet

Yo he seguido jugando con YACAMLQT mi programita y he decidido adaptarlo para generar también 🙂 CAML.Net.





 YACAMLQT.zip (15,07 KB)


Update: Thanks to Cameron to report the Gq/Gt bug.

SharePoint – Pruebas Unitarias (2)

Como comentaba hace unos días, realizar pruebas unitarias usando mocks, no se siempre la mejor solución, personalmente, creo que no se debe abusar de ellos y usarlos para todo.


A continuación os cuento, como realizo mis pruebas unitarias cuando programo para SharePoint, seguramente no sean lo más idóneo del mundo, pero como dije en su día, no considero esto una ciencia sino más bien, un arte en donde cada uno utiliza aquello con lo que obtiene los mejores resultados, en cuanto a calidad. Siempre mantengo en mente el principio de que no deben llevar más trabajo que la realización del código.


El SDK de SharePoint, como comenté con anterioridad, es un framework con lo cual debemos dar por hecho algunas cosas, tenemos que tener claro que Microsoft, tomo ciertas decisiones en su diseño que por ende, nosotros no podemos cambiar.


SharePoint consta de un complejo modelo de objetos, en tres capas. De modo que cada vez que manipulamos estos, de forma transparente vamos cambiando la base de datos donde estos son persistidos. Esta cuestión es importante ya que es como si trabajásemos contra una base de datos y todos los que han realizado pruebas unitarias con bases de datos, saben la complejidad añadida que esto conlleva. Al margen de la discusión ya conocida sobre si las pruebas unitarias deben o no deben usar la base de datos como apunto Rodrigo.


Yo soy de la opinión de que mientras se pueda (por que se conoce) que base de datos se va a usar y podemos recrear un modelo de los datos sin un gran esfuerzo, es la mejor opción.


En SharePoint, aplico el mismo principio. Por diseño, la base de datos esta de manera subyacente así que la mejor manera de probar las cosas es usándola.


Mis pruebas con las Webparts


Las Webparts son un elemento dentro de SharePoint que nos permite interactuar con el usuario, a través del interface de usuario. En esta nueva versión como sabéis son los nativos de ASP.Net.


Como tales elementos, debemos confiar en que el comportamiento que tienen es el esperado, y me centro en realizar pruebas de la lógica subyacente, aquello que se encargará de producir los resultados en función de las entradas que reciba.


Veamos un simple ejemplo con un webpart que muestra el número de elementos que cumplen una condición en una lista.

private string _list = string.Empty;
private string _message = string.Empty;
private string _query = string.Empty;

#region WEBPART PROPERTIES
[Personalizable(PersonalizationScope.Shared),
WebBrowsable,
Category(«Settings»),
WebDisplayName(«List Name»)]
public string List
{

}

[Personalizable(PersonalizationScope.Shared),
WebBrowsable,
Category(«Settings»),
WebDisplayName(«CAML Query»)]
public string Query
{

}

[Personalizable(PersonalizationScope.Shared),
WebBrowsable,
Category(«Settings»),
WebDisplayName(«Mesaage»)]
public string Message
{

}
#endregion

protected override void Render(HtmlTextWriter output)
{
try
{
SPWeb web = SPControl.GetContextWeb(Context);
SPList list = web.Lists[List];
SPQuery query = new SPQuery();
query.Query = Query;
SPListItemCollection items = list.GetItems(query);
output.Write(«<div>{0}<b>{1}</b></div>», Message, CountListItems(web, List, Query));
}
catch (Exception ex)
{
output.Write(String.Format(«<div>{0}: {1}</div>», ex.GetType(), ex.Message));
}
}


Bien, aquí algunas buenas prácticas que suelo recomendar. Siempre que podamos debemos independizar nuestra lógica del componente, esto lo podemos hacer bien separando nuestro código en nuevos métodos:

protected override void Render(HtmlTextWriter output)
{
SPWeb web = SPControl.GetContextWeb(Context);
try
{
output.Write(«<div>{0}<b>{1}</b></div>», Message, CountListItems(web, List, Query));
}
catch (Exception ex)
{
output.Write(String.Format(«<div>{0}: {1}</div>», ex.GetType(), ex.Message));
}
}

private int CountListItems(SPWeb web, string listName, string queryFiler)
{
SPList list = web.Lists[listName];
SPQuery query = new SPQuery();
query.Query = queryFiler;
SPListItemCollection items = list.GetItems(query);

return items.Count;
}


O lo que es mejor, aplicando los principios de delegación o composición para extraer las responsabilidades y la lógica a una nueva clase.

protected override void Render(HtmlTextWriter output)
{
SPWeb web = SPControl.GetContextWeb(Context);
ListItemCounter listCounter = new ListItemCounter(web);

try
{
output.Write(«<div>{0}<b>{1}</b></div>», Message, listCounter.CountListItems(List,Query));
}
catch (Exception ex)
{
output.Write(String.Format(«<div>{0}: {1}</div>», ex.GetType(), ex.Message));
}
}

internal class ListItemCounter
{
private readonly SPWeb _web;

public ListItemCounter(SPWeb web)
{
_web = web;
}

public int CountListItems(string listName, string queryFiler)
{
SPList list = _web.Lists[listName];
SPQuery query = new SPQuery();
query.Query = queryFiler;
SPListItemCollection items = list.GetItems(query);

return items.Count;
}
}


Esto es importante ya que de este modo nuestro código quedará aislado de algunos de los elementos que el componente Webpart lleva implícitos, como el contexto en el cual la aplicación ASP.Net se está ejecutando; que entre otras cosas da bastante guerra ya que es complicado de reproducir. Y como consecuencia será más sencillo poder realizar las pruebas como veremos.