Los que vamos evolucionando a la vez que lo hace la plataforma .Net (bueno, unos cuantos pasos por detrás ;-)), a veces se nos hace difícil superar nuestras costumbres y adaptarnos a nuevos métodos o utilidades que, sin duda, vienen para facilitarnos la vida y ofrecen mejores soluciones a problemas comunes que las que utilizamos de forma habitual.

Un ejemplo lo tenemos con los métodos estáticos xxx.Parse(), útiles para convertir de un string a un tipo valor, como puede ser int32 o boolean. Desde el principio de los tiempos usamos, para obtener un entero desde su representación como cadena, construcciones de tipo:

string num = "123";
int i = 0;
try
{
   i = int.Parse(num);   
}
catch (Exception ex)
{
  // TODO: hacer algo...
}

Sin embargo, la llegada de .NET Framework 2.0 supuso la inclusión del método estático TryParse() en la práctica totalidad de tipos primitivos numéricos (en la versión 1.1 sólo existe en el tipo double), cuya forma más simple de utilización (y también más usual) dejaría el bloque try/catch anterior en uno más compacto y legible:

if (!int.TryParse(num, out i))
  // TODO: hacer algo...

 
El método TryParse devuelve true si se ha podido realizar la transformación con éxito, dejando en la variable de salida que le indiquemos el valor parseado, en este caso un int.

Sin embargo, además de para evitarnos dolores en las articulaciones de los dedos, existen otros motivos para utilizar xxx.TryParse() en vez de xxx.Parse(): el rendimiento, sobre todo si se prevé que el número de fallos de conversión será relativamente alto en un proceso. De hecho es el método recomendado en la actualidad para realizar estas conversiones.

Según la prueba de rendimiento de TryParse publicada Microsoft, ejecutada sobre su propia plataforma, la utilización de este método aventaja de forma considerable al modelo try-parse-catch. Por ejemplo, realizando varias simulaciones de parsing de enteros sobre un conjunto de 100 cadenas de las cuales 5 son erróneas, el tiempo de proceso llegar a ser mil veces superior usando este último patrón; si asumimos 20 incorrectas (80% de cadenas correctas), el modelo tradicional puede tardar 4.000 veces más que usando TryParse.

Aunque lo normal no es efectuar un gran número de transformaciones de este tipo y esta diferencia de rendimiento podría entenderse despreciable, podría ser un factor a tener en cuenta cuando estas operaciones se realicen en contextos de gran carga de usuarios o concurrencia, como en sitios web de alto tráfico. Ojo pues a esas aplicaciones (o componentes) que hemos tomado de .NET 1.x y estamos reutilizando en las versiones superiores.

Por cierto, todo lo dicho, aunque los ejemplos están codificados en C#, es válido para Visual Basic .NET y cualquier otro lenguaje que compile sobre la plaforma .NET de Microsoft. A ver si un día tengo un rato y compruebo si el comportamiento en Mono es el mismo.

Sin duda, la filosofía 2.0 se impone en otros aspectos de la vida...




Fotos de http://vibrance.wordpress.com/2007/05/22/dont-push-the-bus/

Hace unas semanas Miguel de Icaza publicaba en su blog personal un par de ejemplos del tipo de pruebas técnicas que realizan cuando contratan personal, en este caso para el proyecto Mono.

La filosofía es bastante simple, y la verdad es que no carece de sentido: los aspirantes reciben por correo electrónico el "enunciado" de la prueba, y disponen de dos semanas para responder. Aunque el tiempo de respuesta puede parecer excesivo, está pensado para ser realizado por los aspirantes cuando vuelven a casa tras sus jornadas de trabajo o estudio.

Según Miguel, esta técnica le da mejores resultados que las tradicionales entrevistas cara a cara, donde una lectura del currículum y varias preguntas rápidas no permiten conocer en profundidad al candidato. No hay nada como ver planteamientos y código para saber el tipo de desarrollador que tenemos delante.

La prueba para trabajar en el ámbito de Windows.Forms consistía en desarrollar un Control (Widget) y responder una pregunta, y decía más o menos esto (traducción libre):

Desarrollo de un control

Debes implementar un pequeño motor de renderizado para un lenguaje de marcas basado en XML. Este lenguaje acepta las siguientes etiquetas:

<p>...</p>, para definir el inicio y fin de párrafos.

Los párrafos pueden contener en su interior los siguientes tags:

• <b>...</b>, para poner en negrita el texto
• <i>...</i>, para poner el texto en cursiva


• <link>...</link>, para que el texto sea renderizado como un hiperenlace.
• <blink>...</blink> para que el texto parpadee

El control debe exponer la siguiente propiedad, que permitirá al desarrollador modificar el contenido (en este lenguaje de marcas) de forma programática.

  string Markup { get; set; }

 
Por ejemplo:

  m = new MarkupControl ();
  m.Markup = "<p>Hello <b>World</b>!</p>";

 
El control también debe exponer un evento que permita notificar de los clicks del usuario sobre los enlaces (etiqueta <link>), algo así como:

  delegate void LinkClicked (object sender, string link_text);

 
De esta forma, será posible suscribirse al evento usando un código como el siguiente:

  m.LinkClicked += my_clicked;
...
        
  void my_clicked (object sender, string link_text)
  {
    Console.WriteLine 
      ("The link {0} was clicked", link_text);
  }

 
Debes enviar una aplicación completa que se ejecute correctamente en Linux, y debe hacerse uso del evento y la propiedad citados con anterioridad. Por ejemplo, estaría bien tener algo como:

void my_clicked (object sender, string link_text)
{
  Console.WriteLine ("Link {0} pulsado", link_text);
  ((MarkupControl) sender).Markup = "<p>Nuevo <b>texto</b></p>";
}

 
Puntos extra: al usar <blink> será necesario actualizar la vista, se valorará si se evita el parpadeo usando buffers dobles o repintando sólo el área modificada.

Quiero una pequeña y sucinta implementación, pero es tu oportunidad para demostrar que puedes escribir código robusto, así que impresióname.

Pregunta

En nuestra implementación de corlib, en System/DateTime.cs tenemos una implementación no óptima del método TryParse, básicamente invocamos a Parse dentro de un bloque try/catch.

Explica:

• ¿Por qué digo que nuestra solución no es óptima?


• ¿Qué debería tener para hacerla más eficiente?


• ¿Por qué el desarrollador que escribió el código no realizó lo más eficiente?

La trick-question es: ¿por qué el proceso más rápido no se realizó en primer lugar? Explícalo.

¿Que os parece? ¿Podríais entrar a trabajar en el equipo de Mono?

Si eres de los que, como yo, piensan que la moda de los bordes redondeados la ha impuesto gente que odia a los programadores y diseñadores de webs, nunca te ha convencido introducir (X)HTML sin carga semántica sólo para poder incluir estas filigranas en las esquinas de los DIVS o elementos de bloque similares, o no soportas crear imágenes redondeadas para las esquinas, es posible que te interese Nifty Corners Cube.

Se trata de una librería Javascript para redondear los bordes de elementos de bloque sin necesidad de crear imágenes ni nada parecido, sólo usando CSS y scripting. Además, no es intrusiva: si un navegador no soporta scripts o se trata de una versión no contemplada, el usuario simplemente verá sus bordes como siempre. Buena pinta, eh?

Y la forma de usarlo, fácil. En primer lugar, una vez descargado el archivo .zip y extraído en un directorio de la web, se coloca la referencia al script sobre la página (X)HTML como siempre:

<script type="text/javascript" src="niftycube.js"></script>

Desde ese momento ya podemos invocar desde Javascript a las funciones de la librería para que actúen sobre los elementos cuya presentación queremos modificar, por ejemplo así:

// Esto hace que al div con id="box"
// se le redondeen los bordes con
// esquinas grandes (10px):

Nifty("div#box","big");

Esta llamada, o mejor dicho, todas las llamadas que necesitemos para ajustar los efectos de nuestra página, pueden situarse en el evento onload de la misma, como se muestra a continuación. De todas formas, la propia librería ofrece un método alternativo, a través de la función NiftyLoad(), para cuando esto no sea posible.

<script type="text/javascript">
  window.onload=function(){
    Nifty("div.redondeadoGrande","big");
    Nifty("div.redondeadoPeque","small");
  }
</script>

En la función Nifty, el primer parámetro es el selector CSS al que se aplicará el borde (o efecto) deseado. Si no tienes claro qué es un selector, podrías echarle un vistazo a este post (selectores CSS), este (selectores CSS-II-), y este otro (selectores CSS-III).

Así, si indicamos el selector "div.redondeado" estaremos aplicando el efecto a todos aquellos divs cuya clase sea la indicada (class="redondeado").

El segundo parámetro es una palabra clave, a elegir entre una larga lista de opciones, algunas de ellas combinables. Aunque en la web del autor viene muy bien explicado con ejemplos, :

Palabra	Significado
tl	esquina superior izquierda
tr	esquina superior derecha
bl	esquina inferior izquierda
br	esquina inferior derecha
top	esquinas superiores
bottom	esquinas inferiores
left	esquinas izquierdas
right	esquinas derechas
all (default)	las cuatro esquinas
none	no redondear las esquinas (útil para usar las nifty columns
small	esquinas pequeñas (2px)
normal (default)	esquinas normales (5px)
big	esquinas grandes (10px)
transparent	permite crear esquinas transparentes con alias. Se aplica automáticamente cuando el elemento no tiene un color de fondo especificado.
fixed-height	se aplica cuando el elemento tiene un alto fijo especificado en su CSS
same-height	Parámetro para nifty columns: todos los elementos identificados por el selector CSS tienen el mismo alto. Si el efecto se utiliza sin bordes redondeados, este parámetro se puede usar en conjunción con la palabra clave none.

En la web del autor hay multitud de ejemplos de uso que demuestran lo fácil que puede llegar a hacernos la vida. Por cierto, también he encontrado una versión en español.

Por último, comentar que la librería se distribuye bajo licencia GNU GPL, y lo podéis descargar en esta dirección.

Hala, a disfrutarlo.

---

A raíz de los posts sobre los tipos anulables en .NET (introducción a los nullables y uso tipos anulables con enumeraciones), mi amigo Javi me hizo una pregunta que sólo un friki como él sería capaz de formular ;-): ¿cómo afecta el uso de tipos anulables a la serialización de clases?

Aunque sospechaba la respuesta, he hecho un par de pruebas a través de las cuales, ahora sí, puedo asegurar que no afectan en nada, es decir, el sistema controla perfectamente la forma en que se serializan y deserializan este tipo de valores.

El comportamiento es el siguiente: cuando el tipo anulable contiene un valor no nulo, la serialización la delega en el tipo subyacente. Si es un int?, se realizará la serialización por defecto para el int. Usando un serializador XML, un ejemplo de salida sería:

<?xml version="1.0" encoding="utf-16"?>
<int>10</int>

 

En cambio, cuando se trata de serializar el valor null, el sistema genera una etiqueta que indica este hecho, de la misma forma que lo haría si estuviéramos haciéndolo para un tipo referencia. Un ejemplo de salida XML sería:

<?xml version="1.0" encoding="utf-16"?>
<int xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   xmlns:xsd="http://www.w3.org/2001/XMLSchema"
   xsi:nil="true" />

 

En fin, que hoy hemos aprendido una cosa más. Y que no falte. :-)