miércoles, 30 de junio de 2010

¿Hasta cuándo el divide y vencerás?

En los inicios el aprendizaje se aglutinaba en una sola materia, a saber, LA FILOSOFÍA, aunque ya Aristóteles en su libro FÍSICA, dividía entre matemáticas, física, filosofía primera, etc.
Pero esta división hay ido aumentando con el paso de los años y han aparecido muchísimas materias, entre ellas, historia, geografía, matemáticas, física, química, religión, medicina, etc., y ojo que estoy enumerando las materias troncales, porque de éstas además aparecen otras como, ingeniería de puertos y caminos, ingeniería informática, ingeniería industrial, estadística, y un sinfín que no me voy a poner ahora a enumerar. Si además cogemos una de estas materias vemos que aparecen dentro de ellas innumerables especializaciones, y el lector en este punto se preguntará que a dónde quiero llegar.

Antes de que el lector se desoriente del todo y abandone este blog voy a explicarle, el porqué de esta entrada. Llevo un tiempo fijándome en que la gente se suele especializar en una rama de una materia concreta haciéndose poseedor de un gran conocimiento sobre su especialización, un sabio, se podría decir, y esto no es malo, pero puede llegar a un punto que antepone su conocimiento al resto de los conocimientos, y de alguna forma puede llegar a ningunear los "otros conocimientos". Para intentar clarificar mi posición voy a poner un ejemplo, hoy he estado leyendo un blog sobre una persona experta en usabilidad y arquitectura de la información, en uno de sus posts había escrito que "lo más importante" son las interfaces y el autor podría enumerar muchos argumentos donde le tendríamos que dar la razón de manera inexorable. Pero da la casualidad que si hablas con un administrador de bases de datos, te dirá que "lo más importante" son los datos y de nuevo nos bombardeará con n argumentos, todos dignos de aprobación, y es increíble que si hablásemos con un experto en cualquier otra rama podría ofrecernos un abanico de argumentos exponiéndonos que su rama es "lo más importante". Y aquí es donde empieza a perder la credibilidad el primero, el segundo y el resto de expertos.

Personalmente, creo que nada es "lo más importante" sino que cada cosa es importante en su medida, y lo realmente importante es el todo y el todo visto como una composición de las partes, y digo composición y no agregación, porque no creo que ese todo pueda sobrevivir a una de sus partes. En el campo del desarrollo (que es donde mejor me muevo, debido a mi "especialización"), no puede existir una gran aplicación donde la interfaz sea muy buena, pero por ejemplo la aplicación no sea mantenible, o no puede existir una gran aplicación donde tenga una estructura de datos inmejorable, pero la interfaz sea bochornosa, y así con cada una de sus partes. Dejemos de "dividir" y empecemos a "componer".

Pero bueno en realidad no estoy diciendo nada nuevo, yo creo que esto es sabido por todos, pero no soporto cuando leo a expertos que a propósito o inducidos por su súper yo piensan que su rama o especialización se puede sobreponer a cualquier otra, para mi esto es el claro ejemplo de la definición de hombre masa expuesta por Ortega y Gasset.

"He aquí un precioso ejemplar de este extraño hombre nuevo que he intentado, por una y otra de sus vertientes y haces, definir. He dicho que era una configuración humana sin par en toda la historia. El especialista nos sirve para concretar enérgicamente la especie y hacernos ver todo el radicalismo de su novedad. Porque antes los hombres podían dividirse, sencillamente, en sabios e ignorantes, en más o menos sabios y más o menos ignorantes. Pero el especialista no puede ser subsumido bajo ninguna de esas dos categorías. No es sabio, porque ignora formalmente cuanto no entra en su especialidad; pero tampoco es un ignorante, porque es «un hombre de ciencia» y conoce muy bien su porciúncula de universo. Habremos de decir que es un sabio-ignorante, cosa sobremanera grave, pues significa que es un señor el cual se comportará en todas las cuestiones que ignora no como un ignorante, sino con toda la petulancia de quien en su cuestión especial es un sabio."
José Ortega y Gasset. La rebelión de las masas.

martes, 15 de junio de 2010

SharePoint css y error javascript al mover webparts

Hoy me he encontrado con un problemilla al intentar mover (drag and drop) unas webparts de una webpart zone a otra, el problema era bien simple, me ha saltado un error javascript y no me dejaba hacer esta operación.

He debugado el javascript que me estaba dando problemas y resulta que era una función llamada MSOLayout_GetRealOffset. Esta función se encuentra en el fichero  \TEMPLATE\LAYOUTS\1033\IE55UP.JS.

Googleando un poco me he encontrado que este problema aparece cuando tu master page contiene algún referencia a estilo con position:relative. Y este era mi caso. Puedes observarlo aquí.

Googleando también he econtrado una solución a este problema aquí. Ésta básicamente reside o bien en quitar el position:relative del css (cosa que no me ha interesado) o bien sobreescribir esta función. Por lo que he optado por esta segunda. Para sobreescribir esta función simplemente has de copiar el siguiente código después del SPWebPartManager.

Updating SPListItem

En un proyecto en el que estoy trabajando me he encontrado con la necesidad de añadir datos a listas en tiempo de despliegue, a partir de un archivo xml, más o menos como lo que haria la feature listinstance cuando le especificamos un child element data.

Más info...

Una vez leído este fichero xml obtenemos un diccionario key-value, con los fields (keys) de nuestro item y sus valores (value), en nuestro caso ambos serian string.

El problema con el que nos encontramos es que en un SPListItem almacenamos objects, y por lo tanto tendriamos que parsear de alguna forma nuestros strings al tipo de campo que requiere ese field. Para saberlo necesitamos consultar el SPField y este SPField tiene un SPFieldValueType que nos permite determinar el tipo de dato que se almacena en ese campo. Luego añadimos un poco de reflection y utilizamos una función muy interesante que he descubierto, Convert.ChangeType, que permite cambiar de un tipo a otro, y eureka!!! Tenemos un extensión method super útil.

/// 
/// Update an item using a dictionary with key-value pairs
///

/// The item
/// The data collection
public static void Update(this SPListItem item, Dictionary data)
{
bool overwriteVersion = false;

foreach (String internalFieldName in data.Keys)
{
if (item.Fields.Contains(internalFieldName))
{
SPField field = item.Fields.GetFieldByInternalName(internalFieldName);

ConstructorInfo constructor = field.FieldValueType.GetConstructor(new Type[] { typeof(string) });

if (constructor != null)
{
item[internalFieldName] = constructor.Invoke(new object[] { data[internalFieldName]});
}
else
{
item[internalFieldName] = Convert.ChangeType(data[internalFieldName], field.FieldValueType, CultureInfo.InvariantCulture);
}

if (field.ReadOnlyField || field.Type == SPFieldType.Computed) overwriteVersion = true;
}
}

if (overwriteVersion) item.UpdateOverwriteVersion();
else item.Update();
}

miércoles, 9 de junio de 2010

Expresiones regulares

Hoy en un proyecto he tendio que buscar un texto dentro una cadena que cumpla un determinado patrón, bueno esto como seguramente todos conocen lo podemos solventar utilizando expresiones regulares. La verdad es que nunca me ha gustado batallar con expresiones regulares, pero creo que son de gran utilidad para estos casos.

He estado buscando en la red alguna herramienta que sea de ayuda a la hora de elaborar estas expresiones regulares y he encontrado esta herramienta online que me ha venido muy bien: http://gskinner.com/RegExr/

Supongo que como esta, habrán otras muchas herramientas similares.

Hago también una mención especial a la siguiente web site ya que me ha servido de gran ayuda http://www.radsoftware.com.au/articles/regexlearnsyntax.aspx