lunes, 22 de octubre de 2007
Como en otros lenguajes y plataformas, .Net permite la creación de enumeraciones de campos de bits, así como su tratamiento de forma muy sencilla e intuitiva para el desarrollador.
A diferencia de las enumeraciones normales, cuyos elementos son habitualmente excluyentes, las de campos de bits permiten la combinación de ellos, permitiendo su utilización en escenarios algo más complejos que los primeros. Fijaos en los siguientes ejemplos.
Si pretendemos almacenar el estado de las luces de un semáforo, donde sólo uno de los elementos está activo, posiblemente optaríamos por crear una enumeración como la siguiente, de lo más tradicional:
En cambio, si deseásemos almacenar el estado de las lucecillas del teclado de nuestro PC (BloqMays, BloqNum y BloqDespl), tenemos un total de 8 combinaciones de estados distintos (desde el "todas apagadas" hasta "todas encendidas"), lo cual ya se convierte en incómodo para utilizar una enumeración tradicional de selección única. Y es aquí donde saltan a la palestra los campos de bits, permitiéndonos hacer cosas como esta:
Vamos a explicarlo paso a paso. En primer lugar, nos encontramos con el atributo [Flag], que indica a .NET que la enumeración es de este tipo y que debe permitir la combinación de elementos como veremos un poco más adelante.
A continuación se define la enumeración como siempre, aunque estamos forzando a que cada elemento de interés se asocie a un valor potencia de 2, que corresponderá con el valor decimal de su representación binaria. De esta forma, cuando combinemos elementos, su suma lógica nos dará valores únicos que permitirán determinar cuáles de ellos se están uniendo. El siguiente cuadro quizás ayude a entender esto mejor:
Como podemos ver, a cada elemento de la enumeración se asigna un bit en el interior de un byte (o conjunto de bytes); así, BloqMays está asignado al bit 0 (con un valor en decimal de 2^0=1), BloqNum al bit 1 (con valor 2^1=2), etc.
De esta forma, cuando estén activas las luces del bloqueo de mayúsculas (BloqMays) y el del desplazamiento (BloqDespl), estarán a uno los bits 0 y 2, mientras que el bit 1 estará a cero, resultando el número "101" cuyo valor será cinco.
Siguiendo con el ejemplo, tenemos un elemento ("All") que se define como combinación de los anteriores. Esto puede ser util para facilitar las comparaciones con combinaciones muy frecuentes o cuya agrupación tenga un sentido especial, como podría ser un elemento del tipo SuperUsuario en una enumeración de tipos de usuario de un gestor de contenidos:
Volvemos ahora a algo que antes dejamos un poco a medias... ¿para qué el atributo [Flags] que adorna la enumeración? ¿No podemos hacer prácticamente lo mismo sin él, simplemente usando valores potencia de dos en las enumeraciones? Y la respuesta es sí, exactamente lo mismo. La única diferencia que he encontrado es que el método ToString() es capaz de mostrar la combinación de valores, es decir:
Si hemos utilizado el atributo [Flags] por consola podremos ver el texto "BloqMays, BloqNum". Si no lo usamos, sólo aparecerá "3", el valor numérico de la combinación de ambos elementos. Supongo que alguna diferencia más habrá, pero como digo, no la he encontrado.
Por último, comentar que existen varias ventajas a la hora de decidirse a utilizar este tipo de enumeraciones. Sin duda, se trata de una forma realmente compacta de almacenar información de estado o indicadores combinables. Eso, aunque hoy en día cada vez tiene menos importancia, era hace tiempo motivo más que suficiente para propiciar su uso en programación ligada al bajo nivel, como en C o ensamblador, donde además existe mucha facilidad para el tratamiento de bits.
También es ventajosa su versatilidad a la hora de tratar los valores. Con conocimientos básicos de aritmética binaria podemos hacer cosas como alternar entre activo e inactivo (operador ~ o Xor), activar varios elementos de golpe (usando máscaras OR) o desactivarlos (máscaras AND), realizar desplazamientos laterales binarios a derecha o izquierda (L ó RShifts), etc.
Sin embargo, el uso de estas enumeraciones presenta varios inconvenientes también relacionados con su naturaleza binaria. Citar, por ejemplo, que la asignación hay que realizarla mediante operadores de combinación lógicos de bit para no alterar el estado de otros indicadores, es decir:
De la misma forma, no podemos realizar comparaciones utilizando los operadores de igualdad, puesto que sólo evaluarán a cierto sin los dos operandos son estrictamente idénticos:
Las comparaciones deben realizarse utilizando de nuevo operadores de aritmética binaria, concretamente el AND lógico, de la siguiente forma:
Publicado en: www.variablenotfound.com.
A diferencia de las enumeraciones normales, cuyos elementos son habitualmente excluyentes, las de campos de bits permiten la combinación de ellos, permitiendo su utilización en escenarios algo más complejos que los primeros. Fijaos en los siguientes ejemplos.
Si pretendemos almacenar el estado de las luces de un semáforo, donde sólo uno de los elementos está activo, posiblemente optaríamos por crear una enumeración como la siguiente, de lo más tradicional:
public enum EstadoSemaforo
{
Rojo, Amarillo, Verde
}
En cambio, si deseásemos almacenar el estado de las lucecillas del teclado de nuestro PC (BloqMays, BloqNum y BloqDespl), tenemos un total de 8 combinaciones de estados distintos (desde el "todas apagadas" hasta "todas encendidas"), lo cual ya se convierte en incómodo para utilizar una enumeración tradicional de selección única. Y es aquí donde saltan a la palestra los campos de bits, permitiéndonos hacer cosas como esta:
[Flags]
public enum LedStatus
{
BloqMays=1,
BloqNum=2,
BloqDespl=4,
All=BloqMays | BlogNum | BloqDespl,
None = 0
}Vamos a explicarlo paso a paso. En primer lugar, nos encontramos con el atributo [Flag], que indica a .NET que la enumeración es de este tipo y que debe permitir la combinación de elementos como veremos un poco más adelante.
A continuación se define la enumeración como siempre, aunque estamos forzando a que cada elemento de interés se asocie a un valor potencia de 2, que corresponderá con el valor decimal de su representación binaria. De esta forma, cuando combinemos elementos, su suma lógica nos dará valores únicos que permitirán determinar cuáles de ellos se están uniendo. El siguiente cuadro quizás ayude a entender esto mejor:
Como podemos ver, a cada elemento de la enumeración se asigna un bit en el interior de un byte (o conjunto de bytes); así, BloqMays está asignado al bit 0 (con un valor en decimal de 2^0=1), BloqNum al bit 1 (con valor 2^1=2), etc.De esta forma, cuando estén activas las luces del bloqueo de mayúsculas (BloqMays) y el del desplazamiento (BloqDespl), estarán a uno los bits 0 y 2, mientras que el bit 1 estará a cero, resultando el número "101" cuyo valor será cinco.
Siguiendo con el ejemplo, tenemos un elemento ("All") que se define como combinación de los anteriores. Esto puede ser util para facilitar las comparaciones con combinaciones muy frecuentes o cuya agrupación tenga un sentido especial, como podría ser un elemento del tipo SuperUsuario en una enumeración de tipos de usuario de un gestor de contenidos:
public enum TipoDeUsuario
{
Anonimo = 0,
Registrado = 1,
Gestor = 2,
SuperUsuario = Registrado | Gestor;
}Volvemos ahora a algo que antes dejamos un poco a medias... ¿para qué el atributo [Flags] que adorna la enumeración? ¿No podemos hacer prácticamente lo mismo sin él, simplemente usando valores potencia de dos en las enumeraciones? Y la respuesta es sí, exactamente lo mismo. La única diferencia que he encontrado es que el método ToString() es capaz de mostrar la combinación de valores, es decir:
LedStatus leds = LedStatus.BloqMays | LedStatus.BloqNum
Console.WriteLine(leds);
Si hemos utilizado el atributo [Flags] por consola podremos ver el texto "BloqMays, BloqNum". Si no lo usamos, sólo aparecerá "3", el valor numérico de la combinación de ambos elementos. Supongo que alguna diferencia más habrá, pero como digo, no la he encontrado.
Por último, comentar que existen varias ventajas a la hora de decidirse a utilizar este tipo de enumeraciones. Sin duda, se trata de una forma realmente compacta de almacenar información de estado o indicadores combinables. Eso, aunque hoy en día cada vez tiene menos importancia, era hace tiempo motivo más que suficiente para propiciar su uso en programación ligada al bajo nivel, como en C o ensamblador, donde además existe mucha facilidad para el tratamiento de bits.También es ventajosa su versatilidad a la hora de tratar los valores. Con conocimientos básicos de aritmética binaria podemos hacer cosas como alternar entre activo e inactivo (operador ~ o Xor), activar varios elementos de golpe (usando máscaras OR) o desactivarlos (máscaras AND), realizar desplazamientos laterales binarios a derecha o izquierda (L ó RShifts), etc.
Sin embargo, el uso de estas enumeraciones presenta varios inconvenientes también relacionados con su naturaleza binaria. Citar, por ejemplo, que la asignación hay que realizarla mediante operadores de combinación lógicos de bit para no alterar el estado de otros indicadores, es decir:
// la siguiente instrucción activa el
// BloqMays, pero desactiva todos los demás
estado = LedStatus.BloqMays;
// las siguientes instrucciones
// activan el bit 0 (BlockMays)
// dejando intactos los demás leds:
estado = estado | LedStatus.BloqMays;
estado |= LedStatus.BloqMays;
De la misma forma, no podemos realizar comparaciones utilizando los operadores de igualdad, puesto que sólo evaluarán a cierto sin los dos operandos son estrictamente idénticos:
if(estado==LedStatus.BloqMays)
// sólo se cumple si está
// activo únicamente BloqMays
Las comparaciones deben realizarse utilizando de nuevo operadores de aritmética binaria, concretamente el AND lógico, de la siguiente forma:
if ( (estado & LedStatus.BloqMays) != 0)
// se cumple cuando el BloqMays
// está activo, independientemente del resto
Publicado en: www.variablenotfound.com.
jueves, 18 de octubre de 2007
Si hace unos días Jeffrey Palermo recogía en su blog la presentación del futuro ASP.Net MVC Framework, es ahora el propio Scott Guthrie, uno de los padres de la criatura, el que hace una pequeña introducción en su bitácora sobre esta tecnología que se avecina.Aunque en el post de hace unos días donde me hacía eco de la presentación ya recogí alguna de las características principales, no está de más visitar el blog de Scott para conocer, de primera mano, por dónde van los tiros. Además comenta que las próximas semanas seguirá publicando artículos explicando cómo funciona el framework, habrá que estar atentos a su página.
Por último, decir que hay una traducción al español del post original en Thinking in .net, de la mano de Juan María Laó.
miércoles, 17 de octubre de 2007
Hace unos días publiqué un post donde comentaba lo que sin duda era mi descubrimiento del mes: la posibilidad de codificar constantes de cadena multilíneas en C# al más puro estilo Heredoc de PHP y otros lenguajes.
Al día siguiente en la oficina pude observar que, como sospechaba, no era una característica muy conocida (aunque todo el mundo sabía que la arroba @ se utilizaba para introducir fácilmente caracteres extraños en los strings) y que su utilidad era enorme a la hora de asignar sentencias SQL largas, porciones de scripts en código, HTML, etc. La legibilidad que aporta al código es increíble.
Sin embargo, hay un detalle importante que olvidé comentar en el post: para concatenar cadenas definidas de esta manera hay que utilizar la arroba en cada una de las subcadenas constantes.
Para que quede más claro, ahí va un ejemplo en C# donde se pretende incluir el valor de la variable "pattern" en una sentencia SQL:
Y sí, sé que el ejemplo no es muy correcto desde el punto de vista de la construcción de la sentencia SQL (ojo a la inyección SQL), pero creo que ilustra perfectamente la forma de incluir un contenido variable en el interior de una cadena de este tipo.
Al día siguiente en la oficina pude observar que, como sospechaba, no era una característica muy conocida (aunque todo el mundo sabía que la arroba @ se utilizaba para introducir fácilmente caracteres extraños en los strings) y que su utilidad era enorme a la hora de asignar sentencias SQL largas, porciones de scripts en código, HTML, etc. La legibilidad que aporta al código es increíble.
Sin embargo, hay un detalle importante que olvidé comentar en el post: para concatenar cadenas definidas de esta manera hay que utilizar la arroba en cada una de las subcadenas constantes.
Para que quede más claro, ahí va un ejemplo en C# donde se pretende incluir el valor de la variable "pattern" en una sentencia SQL:
string sql =
@"SELECT product_name,
product_details,
total_rows
FROM (
SELECT product_name,
product_details,
total_rows,
rownum row_counter
FROM (
SELECT product_name,
product_details,
count(*) OVER () total_rows
FROM products
WHERE product_name
like '%" + pattern + @"%'
ORDER BY product_name
)
)
WHERE row_counter between v_start_row and v_end_row;";
Y sí, sé que el ejemplo no es muy correcto desde el punto de vista de la construcción de la sentencia SQL (ojo a la inyección SQL), pero creo que ilustra perfectamente la forma de incluir un contenido variable en el interior de una cadena de este tipo.
martes, 16 de octubre de 2007
Desde este mismo momento, y gracias a la gentil invitación del amigo Rodrigo Corral, estoy publicando en Geeks.ms, una selecta comunidad de desarrolladores orientada a la programación con y para tecnologías de Microsoft. La compañía no puede ser mejor: un grupo de auténticos maestros, MVPs, MCP ó MCT como El Guille, Jorge Serrano, el mismo Rodrigo, Sergio Tarrillo, El Bruno, y un larguísimo etcétera (que no se ofenda nadie, en algún momento hay que acabar la lista ;-)).Por mi parte, seguiré con lo mismo que vengo haciendo desde hace ya año y medio en Variable Not Found: escribir sobre lo que más me gusta, el mundo del desarrollo de software. La diferencia es que ahora llegará a más lectores. :-)
De momento, hasta que descubra otra forma más apropiada, realizaré crossposting artesano (vamos, copiar y pegar) de las entradas de VariableNotFound.com hacia mi dirección en Geeks, http://geeks.ms/blogs/jmaguilar.
Nos vemos también por allí.
miércoles, 10 de octubre de 2007
Siempre he envidiado a los desarrolladores PHP, Ruby o a las figuras del shell-scripting por poder utilizar heredoc para representar cadenas de caracteres de longitud considerable.Por si no te habías encontrado antes con este término, heredoc es una forma de escribir cadenas literales de forma directa, sin preocuparse de caracteres de control, secuencias de escape o saltos de línea de forma manual. Simplemente se indica en el comienzo la marca que permitirá identificar su final y el resultado será el conjunto de caracteres contenidos entre el inicio y la marca, todo incluido.
De hecho, Heredoc es una abreviatura de "Here document", que viene a ser algo así como "documento a continuación".
Un ejemplo para enviar al navegador del cliente una porción de código script correctamente formateado sería el que se muestra a continuación. Se puede distinguir la marca de comienzo (<<<) seguida de la etiqueta que se usará para determinar su finalización (EOT); a continuación va el contenido del literal y, por último, la marca asignada al comienzo (EOT):
<?php
echo <<<EOT
function AddCss()
{
var l=document.createElement('link');
l.setAttribute('type','text/css');
l.setAttribute('rel','stylesheet');
l.setAttribute('href','styles.css');
document.getElementsByTagName('head')[0].appendChild(l);
};
EOT;
?>Sin embargo, y aquí va la buena noticia, resulta que en C# podemos realizar algo bastante parecido precediendo la cadena por el carácter "@" (arroba), de la siguiente forma:
string script =
@"function AddCss()
{
var l=document.createElement('link');
l.setAttribute('type','text/css');
l.setAttribute('rel','stylesheet');
l.setAttribute('href','styles.css');
l.setAttribute('media','screen');
document.getElementsByTagName('head')[0].appendChild(l);
}";
Response.Write(script);Su principal ventaja es la capacidad de representar texto estructurado como Javascript, CSS, (X)HTML, XML o SQL de forma muy directa, ya véis el ejemplo anterior. Nada de "trocear" la cadena en líneas e ir concatenando, ni de introducir caracteres de escape para saltos de línea o tabulaciones. Todo un gustazo.
Por citar algún inconveniente, la cadena siempre debe acabar en dobles comillas; por tanto, si queremos usar este carácter debemos introducirlo doblemente (por ejemplo ""hola"" en vez de "hola"). Tampoco se realiza sustitución de variables en su interior (como ocurre, por ejemplo, en PHP), por lo que hay que usar los operadores de concatenación.
Aunque un poco menos, sigo envidiando a los Heredockers.
domingo, 7 de octubre de 2007
Vía CodeBetter llego a un interesante post de Jeffrey Palermo donde cuenta que Scott Guthrie, de la división de desarrolladores de Microsoft, anunció y demostró el pasado 5 de ocubre en el contexto de las conferencias Alt.Net un framework MVC para ASP.NET en el que los de Seattle llevan tiempo trabajando.Algunas de las características que describe, aunque muy someramente, de la nueva plataforma son:
- Soporte nativo para TDD (¿qué diantres es esto?) en los Controladores.
- Vistas basadas en ASPX, sin viewstate ni postbacks.
- Soporte para enlaces otros motores como MonoRail.
- Soporte para contenedores IoC (¿ein?) y DI (¿y esto qué es?).
- Control absoluto sobre las URLs y la navegación. Éstas seguirán un modelo común, algo similar a: "/Ruta/Acción/Param1/Param2... ", que se mapearán hacia la acción oportuna del Controlador asignado.
- Separación de la capa de negocio de la de presentación, como buen MVC.
- Integración total en ASP.NET, sin traumas. De hecho, la llegada de esta tecnología no implica, ni por asomo, la desaparición de los conocidos y utilizados Webforms actuales, ambos modelos podrán convivir incluso en la misma aplicación.
- Soporte para lenguajes estáticos como C++, C#, o VB.Net y dinámicos como Javascript, Ruby o Python.
Se espera una CTP pública hacia finales de año, y se espera la versión definitiva como add-on para el próximo Visual Studio 2008. Mínimo primavera-verano, por tanto.
miércoles, 3 de octubre de 2007
Hasta hoy pensaba que la página maestra (MasterPage) de un .aspx era una propiedad que se definía en tiempo de diseño, concretamente en las directivas de página, y no era posible modificarlo de forma programática al encontrarse la declaración a un nivel tan bajo:
Nada más lejos de la realidad. Aunque con algunas restricciones, es perfectamente posible alterar en tiempo de ejecución la MasterPage de la página, haciendo posible cosas como, por ejemplo, modificar completamente la apariencia y disposición de los elementos sobre la marcha.
Por ejemplo, el siguiente código hace que una página .aspx utilice una maestra u otra en función de si la hora actual del servidor es par:
Las restricciones a las que me refería antes están plasmadas en esta porción de código: sólo puede cambiarse en el evento PreInit o antes. A efectos prácticos, sobreescribir OnPreInit (como en el ejemplo anterior) es una buena solución.
<%@ Page Language="C#" MasterPageFile="~/Site1.Master"
AutoEventWireup="true" CodeBehind="WebForm1.aspx.cs"
Inherits="PruebasVariadas.WebForm1"
Title="Página sin título" %>
Nada más lejos de la realidad. Aunque con algunas restricciones, es perfectamente posible alterar en tiempo de ejecución la MasterPage de la página, haciendo posible cosas como, por ejemplo, modificar completamente la apariencia y disposición de los elementos sobre la marcha.
Por ejemplo, el siguiente código hace que una página .aspx utilice una maestra u otra en función de si la hora actual del servidor es par:
// C#:
protected override void OnPreInit(EventArgs e)
{
if (DateTime.Now.Hour % 2 == 0)
this.MasterPageFile = "~/Maestra1.master";
else
this.MasterPageFile = "~/Maestra2.master";
base.OnPreInit(e);
}
' VB.NET:
Protected Overrides Sub OnPreInit(ByVal e As System.EventArgs)
If DateTime.Now.Second Mod 2 = 0 Then
Me.MasterPageFile = "~/Maestra1.master"
Else
Me.MasterPageFile = "~/Maestra2.master"
End If
MyBase.OnPreInit(e)
End Sub
Las restricciones a las que me refería antes están plasmadas en esta porción de código: sólo puede cambiarse en el evento PreInit o antes. A efectos prácticos, sobreescribir OnPreInit (como en el ejemplo anterior) es una buena solución.
domingo, 30 de septiembre de 2007
El otro día comentábamos en mi empresa que podría ser el momento de incorporar un nuevo desarrollador software en el equipo, de contratar a alguien. Esto, que puede resultar rutinario en grandes compañías, es para los que somos pequeños, un auténtico suplicio.
Experiencias anteriores nos han demostrado que los portales de empleo son útiles cuando se trata de ofertas muy específicas a la que acudirán pocos candidatos. Casos más genéricos, como podría ser la contratación de un desarrollador con cierta experiencia bajo unas condiciones aceptables, provocan una entrada masiva de candidatos que hacen de la selección un proceso imposible... ¿qué pequeña empresa puede preseleccionar con tino de entre una lista de cientos de personas, entrevistar físicamente a decenas de personas y encontrar a su candidato ideal?
Esta masificación es la que hace que tengan mayores probabilidades de éxito aquellos candidatos que destacan de alguna forma sobre el resto. Conocimientos técnicos, habilidades, actitudes... son muchas las características interesantes para las empresas, y algunas de ellas son difíciles de demostrar a priori, y más aún usando el habitual curriculum.
Y es justo aquí donde los blogs pueden jugar un papel fundamental. Si estás buscando empleo, se me ocurren al menos diez razones por las que deberías tener tu propio blog e incluirlo en tu currículum como un activo de alto interés:
1. Demuestras tus conocimientos.
Sí, es cierto que tu título debería hacerlo o al menos ser una pista, pero por desgracia no es así. El mero hecho de poseer una ingeniería, titulación técnica o haber realizado cursos específicos no implica un nivel de conocimientos determinado, pues la mayoría de las veces éste se adquiere con la experiencia o de forma autodidacta.
En un blog puedes demostrar tu nivel de conocimientos en los temas que tratas, tus especialidades, preferencias e inquietudes de forma mucho más directa, detallada y creíble de lo que puedes hacer con un currículum tradicional.
2. Demuestras tu facilidad de aprendizaje
Respecto a esto, siempre digo lo mismo: si piensas que vales lo que sabes, estás muy equivocado. Tus conocimientos de hoy no tienen mucho valor más allá de un par de años. Lo que vales es lo que puedes llegar a aprender, la facilidad con la que te adaptas a los cambios que esta profesión nos regala tan frecuentemente.
Tu blog puede demostrar que tienes una actitud positiva frente al aprendizaje.
3. Demuestras pasión por tu profesión
La pasión por tu profesión, por tu trabajo, esa característica tan demandada en el mundo empresarial, viene incluida casi de serie en el blogger. Resulta imposible imaginar a alguien al que no le guste el mundo del desarrollo de software escribiendo varios posts mensuales comentando las nuevas tecnologías que va descubriendo, trucos o cualquier tema relacionado con ello.
El simple hecho de tener un blog ya es un punto a tu favor.
4. Demuestras tu capacidad de trabajo
Un blogger, salvo excepciones (que seguro que hay), es un trabajador nato. Es importante tener en cuenta que cada post requiere un trabajo considerable, sobre todo cuando se genera contenido propio. Existen asimismo otras tareas, como la lectura de fuentes o la gestión de comentarios que pueden llegar a consumir mucho tiempo y esfuerzo. Esto, además, tiene mucho más mérito cuando se hace por gusto (véase el punto 3).
Obviamente, ser trabajador es una característica muy apreciada por la empresa, y tu blog te ayudará a demostrar que lo eres. ;-D
5. Demuestras rasgos importantes de tu personalidad
En cada post que escribes vas dejando un poco de tí mismo; consecuentemente, si sumas muchos de ellos seguro que podríamos unir tantos trocitos que habría información suficiente para psicoanalizarte en profundidad.
Las características personales de los candidatos son aspectos vitales en un proceso de selección. En el mundo del desarrollo, nadie va a contratar a personas conflictivas, violentas, de posturas radicales o de difícil encaje para el trabajo en equipo.
La imagen que transmites en tu blog puede ayudar a las empresas a hacerse una idea de cómo eres y de cómo no.
6. Demuestras tus habilidades literarias
Aunque a veces sea injustamente considerada la parte más tediosa y poco creativa de nuestra profesión, no olvidemos que una buena parte del trabajo de desarrollador consiste, a distintos niveles, en escribir textos. Pantallas, mensajes, ayudas, documentación de código, documentos técnicos, de diseño, análisis o propuestas son sólo algunos ejemplos de las tareas para las que hay que saber redactar apropiadamente. Las faltas de ortografía, o simplemente una redacción pobre en cualquier entregable, dan muy mala imagen de la persona y empresa que los generan.
Tu blog, aparte de ayudarte a cultivar estas virtudes, demuestra cómo podrías hacerlo en el desempeño de tus tareas como profesional, aportando un plus respecto al resto de candidatos que simplemente presentan un currículum.
7. Fortaleces y demuestras tu capacidad de comunicación
Un blog, aunque pueda parecer lo contrario, no es una herramienta de comunicación unidireccional, una palestra donde recitar monólogos: se escribe, se escucha, se debate, se critica, se comparten conocimientos y experiencia.
Ya en su momento, en el post "Entre 10 y 28 desarrolladores por el precio de uno" comenté que una de las características imprescindibles de un buen desarrollador es la capacidad comunicación bidireccional, pues repercute de forma muy positiva en la productividad del equipo de trabajo donde se ubique. Y, ¿qué es un blog sino un potente medio de comunicación?
Tu blog hace que te comuniques, y demuestra la facilidad que tienes para ello.
8. Demuestras tu experiencia, incluso si no la tienes
Está claro que nadie que busque su primer trabajo tiene experiencia; también es cierto que la experiencia es vital para encontrar empleo... ¿cómo salimos de este círculo sin fin?
Hay personas que sin haber salido todavía al mercado laboral, acumulan ya centenares de horas de vuelo. Suelen ocupar sus ratos libres en investigar, probar, aprender, y a veces pueden llegar a alcanzar niveles de dominio de una tecnología increíbles, y que serían muy valiosos en el mundo empresarial. El problema casi siempre es demostrarlo.
Tu blog puede demostrar la experiencia que tienes como desarrollador, independientemente de si has comenzado o no tu carrera profesional. Y si además participas en proyectos de software libre, mucho mejor.
9. Ganas prestigio
Lo mejor para conseguir un puesto de trabajo son, sin duda, las referencias y recomendaciones facilitadas por personas o entidades de confianza. Sin embargo, en un mundo 2.0 como éste, donde somos los usuarios de la red los que vamos aportando nuestro granito de arena a la inteligencia colectiva, no hay mejor aval que la credibilidad y fidelidad de cientos o miles de individuos repartidos por todo el mundo que, día a día, leen, comentan y citan nuestros posts.
Un blog con contenidos medianamente decentes se va haciendo, a la larga, un hueco en la red, aumentando el prestigio y autoridad de su autor.
10. Y sobre todo, destacar
Destacar sobre el resto de candidatos que, como tú, son ingenieros, técnicos, programadores estupendos o grandes expertos en lenguajes de última generación. Es la distinción lo que puede hacer que triunfes, y especialmente si acabas de terminar tus estudios, momento en el que se lanzan al mercado laboral decenas de jóvenes con currículums prácticamente idénticos.
Incluir el blog en tu currículum provocará, como mínimo, la curiosidad de los responsables de las primeras fases de una selección de personal, que probablemente acudirán a comprobar si eres el candidato apropiado.
En fin, espero que estas reflexiones puedan servir para algo; por un lado, motivar a aquellos que todavía no tienen blog para que se atrevan a empezar, y por otro, para animar a los que ya lo tienen y trabajan duro en él. En cualquier caso, tened por seguro que va a valer la pena.
Experiencias anteriores nos han demostrado que los portales de empleo son útiles cuando se trata de ofertas muy específicas a la que acudirán pocos candidatos. Casos más genéricos, como podría ser la contratación de un desarrollador con cierta experiencia bajo unas condiciones aceptables, provocan una entrada masiva de candidatos que hacen de la selección un proceso imposible... ¿qué pequeña empresa puede preseleccionar con tino de entre una lista de cientos de personas, entrevistar físicamente a decenas de personas y encontrar a su candidato ideal?Esta masificación es la que hace que tengan mayores probabilidades de éxito aquellos candidatos que destacan de alguna forma sobre el resto. Conocimientos técnicos, habilidades, actitudes... son muchas las características interesantes para las empresas, y algunas de ellas son difíciles de demostrar a priori, y más aún usando el habitual curriculum.
Y es justo aquí donde los blogs pueden jugar un papel fundamental. Si estás buscando empleo, se me ocurren al menos diez razones por las que deberías tener tu propio blog e incluirlo en tu currículum como un activo de alto interés:
1. Demuestras tus conocimientos.
Sí, es cierto que tu título debería hacerlo o al menos ser una pista, pero por desgracia no es así. El mero hecho de poseer una ingeniería, titulación técnica o haber realizado cursos específicos no implica un nivel de conocimientos determinado, pues la mayoría de las veces éste se adquiere con la experiencia o de forma autodidacta.
En un blog puedes demostrar tu nivel de conocimientos en los temas que tratas, tus especialidades, preferencias e inquietudes de forma mucho más directa, detallada y creíble de lo que puedes hacer con un currículum tradicional.
2. Demuestras tu facilidad de aprendizaje
Respecto a esto, siempre digo lo mismo: si piensas que vales lo que sabes, estás muy equivocado. Tus conocimientos de hoy no tienen mucho valor más allá de un par de años. Lo que vales es lo que puedes llegar a aprender, la facilidad con la que te adaptas a los cambios que esta profesión nos regala tan frecuentemente.
Tu blog puede demostrar que tienes una actitud positiva frente al aprendizaje.
3. Demuestras pasión por tu profesión
La pasión por tu profesión, por tu trabajo, esa característica tan demandada en el mundo empresarial, viene incluida casi de serie en el blogger. Resulta imposible imaginar a alguien al que no le guste el mundo del desarrollo de software escribiendo varios posts mensuales comentando las nuevas tecnologías que va descubriendo, trucos o cualquier tema relacionado con ello.
El simple hecho de tener un blog ya es un punto a tu favor.
4. Demuestras tu capacidad de trabajo
Un blogger, salvo excepciones (que seguro que hay), es un trabajador nato. Es importante tener en cuenta que cada post requiere un trabajo considerable, sobre todo cuando se genera contenido propio. Existen asimismo otras tareas, como la lectura de fuentes o la gestión de comentarios que pueden llegar a consumir mucho tiempo y esfuerzo. Esto, además, tiene mucho más mérito cuando se hace por gusto (véase el punto 3).
Obviamente, ser trabajador es una característica muy apreciada por la empresa, y tu blog te ayudará a demostrar que lo eres. ;-D
5. Demuestras rasgos importantes de tu personalidad
En cada post que escribes vas dejando un poco de tí mismo; consecuentemente, si sumas muchos de ellos seguro que podríamos unir tantos trocitos que habría información suficiente para psicoanalizarte en profundidad.
Las características personales de los candidatos son aspectos vitales en un proceso de selección. En el mundo del desarrollo, nadie va a contratar a personas conflictivas, violentas, de posturas radicales o de difícil encaje para el trabajo en equipo.
La imagen que transmites en tu blog puede ayudar a las empresas a hacerse una idea de cómo eres y de cómo no.
6. Demuestras tus habilidades literarias
Aunque a veces sea injustamente considerada la parte más tediosa y poco creativa de nuestra profesión, no olvidemos que una buena parte del trabajo de desarrollador consiste, a distintos niveles, en escribir textos. Pantallas, mensajes, ayudas, documentación de código, documentos técnicos, de diseño, análisis o propuestas son sólo algunos ejemplos de las tareas para las que hay que saber redactar apropiadamente. Las faltas de ortografía, o simplemente una redacción pobre en cualquier entregable, dan muy mala imagen de la persona y empresa que los generan.
Tu blog, aparte de ayudarte a cultivar estas virtudes, demuestra cómo podrías hacerlo en el desempeño de tus tareas como profesional, aportando un plus respecto al resto de candidatos que simplemente presentan un currículum.
7. Fortaleces y demuestras tu capacidad de comunicación
Un blog, aunque pueda parecer lo contrario, no es una herramienta de comunicación unidireccional, una palestra donde recitar monólogos: se escribe, se escucha, se debate, se critica, se comparten conocimientos y experiencia.
Ya en su momento, en el post "Entre 10 y 28 desarrolladores por el precio de uno" comenté que una de las características imprescindibles de un buen desarrollador es la capacidad comunicación bidireccional, pues repercute de forma muy positiva en la productividad del equipo de trabajo donde se ubique. Y, ¿qué es un blog sino un potente medio de comunicación?
Tu blog hace que te comuniques, y demuestra la facilidad que tienes para ello.
8. Demuestras tu experiencia, incluso si no la tienes
Está claro que nadie que busque su primer trabajo tiene experiencia; también es cierto que la experiencia es vital para encontrar empleo... ¿cómo salimos de este círculo sin fin?
Hay personas que sin haber salido todavía al mercado laboral, acumulan ya centenares de horas de vuelo. Suelen ocupar sus ratos libres en investigar, probar, aprender, y a veces pueden llegar a alcanzar niveles de dominio de una tecnología increíbles, y que serían muy valiosos en el mundo empresarial. El problema casi siempre es demostrarlo.
Tu blog puede demostrar la experiencia que tienes como desarrollador, independientemente de si has comenzado o no tu carrera profesional. Y si además participas en proyectos de software libre, mucho mejor.
9. Ganas prestigio
Lo mejor para conseguir un puesto de trabajo son, sin duda, las referencias y recomendaciones facilitadas por personas o entidades de confianza. Sin embargo, en un mundo 2.0 como éste, donde somos los usuarios de la red los que vamos aportando nuestro granito de arena a la inteligencia colectiva, no hay mejor aval que la credibilidad y fidelidad de cientos o miles de individuos repartidos por todo el mundo que, día a día, leen, comentan y citan nuestros posts.
Un blog con contenidos medianamente decentes se va haciendo, a la larga, un hueco en la red, aumentando el prestigio y autoridad de su autor.
10. Y sobre todo, destacar
Destacar sobre el resto de candidatos que, como tú, son ingenieros, técnicos, programadores estupendos o grandes expertos en lenguajes de última generación. Es la distinción lo que puede hacer que triunfes, y especialmente si acabas de terminar tus estudios, momento en el que se lanzan al mercado laboral decenas de jóvenes con currículums prácticamente idénticos.
Incluir el blog en tu currículum provocará, como mínimo, la curiosidad de los responsables de las primeras fases de una selección de personal, que probablemente acudirán a comprobar si eres el candidato apropiado.
En fin, espero que estas reflexiones puedan servir para algo; por un lado, motivar a aquellos que todavía no tienen blog para que se atrevan a empezar, y por otro, para animar a los que ya lo tienen y trabajan duro en él. En cualquier caso, tened por seguro que va a valer la pena.
jueves, 27 de septiembre de 2007
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:
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:
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.
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.
martes, 25 de septiembre de 2007
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/
Fotos de http://vibrance.wordpress.com/2007/05/22/dont-push-the-bus/
lunes, 24 de septiembre de 2007
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):
¿Que os parece? ¿Podríais entrar a trabajar en el equipo de 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:El control debe exponer la siguiente propiedad, que permitirá al desarrollador modificar el contenido (en este lenguaje de marcas) de forma programática.
- <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
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?
jueves, 20 de septiembre de 2007
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.
Editado [2/11/07]: Si usas ASP.NET, es posible que te interese NiftyDotNet, un componente que encapsula Nifty Corners Cube para hacer aún más sencillo su uso.
martes, 18 de septiembre de 2007
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. :-)
domingo, 16 de septiembre de 2007
Vía The Server Side acabo de enterarme de la existencia de Quaere, una implementación para Java del proyecto LINQ de Microsoft, creada por Anders Norås.Se trata de un DSL (Domain Specific Language, lenguaje específico de dominio) que permite integrar dentro de código Java sentencias muy parecidas a SQL para extraer información de arrays, colecciones y otros almacenes de información, de forma muy sencilla y potente. Gracias a la utilización de static imports y fluent interfaces, no es necesario usar preprocesadores o generadores de código intermedios, el código se compila directamente sobre javac importando las librerías de Quaere.
Y para que se entienda mejor el alcance del proyecto y cómo puede ayudarnos a desarrollar, unos ejemplos básicos tomados del blog del autor, que demuestran la potencia de esta extensión para gestión de datos:
// Obtiene los números menores de
// cinco del array:
Integer[] numbers =
{5, 4, 1, 3, 9, 8, 6, 7, 2, 0};
Iterable<integer> lowNums =
from("n").in(numbers).
where(lt("n", 5)).
select("n");
// Obtiene una colección
// de strings con los nombres de
// los productos:
List products =
Arrays.asList(Product.getAllProducts());
Iterable<String> productNames =
from("p").in(products).
select("p.getProductName()");
viernes, 14 de septiembre de 2007
De todos es sabido que las enumeraciones son un tipo valor, y se representan internamente como Byte, Int32 u otros tipos primitivos de la plataforma, lo que hace imposible la asignación de valores como null, concebido para los tipos referencia.Así, en el siguiente ejemplo en C#:
Estado estado1 = Estado.Correcto;
Estado estado2 = null;La segunda línea provoca el error en compilación "No se puede convertir null en 'ConsoleApplication1.Program.Estado' porque es un tipo de valor". Lógico, es igual que que si intentáramos asignar el maldito valor nulo a un integer.
Esto puede causar ligeras molestias para la gestión de valores "indeterminados", puesto que estaríamos obligados, por ejemplo, a utilizar otro miembro de la enumeración para representar este valor, como en el siguiente código en Visual Basic .Net:
Public Enum Estado
Indeterminado = 0
Correcto = 1
Incorrecto = 2
End EnumSin embargo, hay ocasiones en la que resulta más interesante poder disponer del valor nulo como una opción para las variables del tipo de nuestra enumeración. Por ejemplo, si estamos desarrollando componentes que leen de una base de datos donde la indeterminación se representa por un nulo, sería más natural poder trasladar esta particularidad al modelo de objetos.
Y para esto inventaros los tipos anulables, de los que ya publiqué un post hace tiempo (Nullable Types, o cómo convivir con los nulos). Dado que las enumeraciones son tipos valor, nada impide crear tipos anulables de enumeraciones:
' VB.NET
Dim estado1 As Nullable(Of Estado)
Dim estado2 As Nullable(Of Estado)
estado1 = Estado.Correcto
estado2 = Nothing
// C#
Estado? estado1 = Estado.Correcto;
Estado? estado2 = null;
miércoles, 12 de septiembre de 2007
Javascript, ese lenguaje tan de moda, nos permite manipular en cliente algunas propiedades de los utilísimos validadores de ASP.Net.
La función ValidatorEnable, proporcionada por la plataforma .Net en cliente y utilizable mediante scripting, nos permite habilitar o deshabilitar validadores de nuestros Webforms sin necesidad de hacer un postback. Un ejemplo de uso sería el siguiente:
El segundo parámetro sería el booleano (true o false) que indica si se desea activar o desactivar el validador. El primer parámetro es el ID en cliente del mismo, y podemos obtenerlo usando la propiedad ClientID del control; por ejemplo, imaginando que tenemos un validador de tipo RequiredFieldValidator llamado Rfv en nuestro Webform, una llamada a la función anterior sería algo así como:
La función ValidatorEnable, proporcionada por la plataforma .Net en cliente y utilizable mediante scripting, nos permite habilitar o deshabilitar validadores de nuestros Webforms sin necesidad de hacer un postback. Un ejemplo de uso sería el siguiente:
function onOff(validatorId, activar)
{
var validator =
document.getElementById(validatorId);
ValidatorEnable(validator, activar);
}El segundo parámetro sería el booleano (true o false) que indica si se desea activar o desactivar el validador. El primer parámetro es el ID en cliente del mismo, y podemos obtenerlo usando la propiedad ClientID del control; por ejemplo, imaginando que tenemos un validador de tipo RequiredFieldValidator llamado Rfv en nuestro Webform, una llamada a la función anterior sería algo así como:
function algo( )
{
onOff("<%= Rfv.ClientID %>", true);
}
lunes, 10 de septiembre de 2007
Hoy seguiremos jugado un poco más con las plantillas de Blogger, y estudiaremos cómo modificar la forma en que este gestor de blogs, sobre el que está montado Variable not found, muestra el mensaje al pie de los posts indicando el número de comentarios de cada entrada, que es bastante soso (al menos en las plantillas por defecto).
Por defecto Blogger nos deja configurar exclusivamente qué texto aparecerá detrás del número de comentarios, es decir, a lo más podríamos hacer que apareciera "3 comentarios, ¡comenta ya!" o mensajes así, pero nunca con lógica dependiente del número, lo cual resulta demasiado lineal y cutre para un blog de renombre como el nuestro ;-)
A lo largo de este post vamos a modificar la plantilla para hacer que se muestre un mensaje cuando no hay ningún comentario, otro distinto cuando hay sólo uno, y otro para el resto de los casos. Esto podríais después complicarlo todo lo que queráis, pero de momento con lo que vamos a ver será suficiente para que podáis empezar a jugar.
En primer lugar he de decir que, al igual que ocurría el otro día cuando tratamos el tema de modificar la forma de aparecer la lista de categorías en Blogger, lo más prudente es hacer una copia de seguridad de la plantilla, pues cualquier paso en falso puede tumbar nuestra bitácora. Por si no viste el post anterior, la forma de hacerlo era accediendo al panel de administración de la herramienta y pulsando el enlace "Descargar plantilla completa" que encontrarás en la pestaña "Plantilla", opción "Edición de HTML".
Una vez realizado el backup, podemos continuar sin peligro.
A continuación, marcamos la casilla "Expandir plantillas de artilugios", que nos permitirá acceder al código fuente completo de los Widgets, que son los elementos, bloques o controles que componen la interfaz de Blogger.
Una vez marcada esta casilla, podemos desplazarnos sobre el texto y buscar una porción de código similar a este, donde se ve claramente el comportamiento por defecto del gestor a la hora de mostrar el número de comentarios de una entrada:
A simple vista se entiende el comportamiento por defecto del sistema, ¿no? Fijaos que se distingue cuando hay un único comentario para poner la etiqueta en singular, mientras que en resto de casos es en plural.
Si escudriñáis en el código de la plantilla, detectaréis que hay dos puntos donde aparece una porción similar. Uno de ellos es para indicar la presentación en la página principal de vuestro Blog, donde aparece la lista de los últimos posts; el otro es para la página individual de cada post. A efectos prácticos, lo que quiere decir es que podemos establecer reglas diferentes para cada caso, aunque por simplificar un poco el ejemplo no lo haremos aquí.
Pues bien, vamos a modificarlo ligeramente para animar al lector a participar en el blog con sus comentarios. Por cierto, no me gusta mucho moverme en el interior del textarea de Blogger. Prefiero llevarme el código a un editor de texto de mi equipo, y desde ahí manipularlo todo lo que quiera. Una vez he acabado de hacer los cambios, copio y pego sobre el cuadro de edición y listo; o si lo he salvado a mi disco, también podría subirse usando la opción de cargar o subir la plantilla disponible en la parte superior de la pantalla.
En cualquier caso, el nuevo código a incluir sería:
Como se puede comprobar, si sólo hay un comentario lo indicamos y hacemos un llamamiento directo a la participación del usuario. Si no hay comentario alguno, animamos a ser el primero en comentar, y en el resto de los casos, hacemos como siempre.
Vamos, que ya no hay excusa para que en tu blog no haya participación. ;-D
Por defecto Blogger nos deja configurar exclusivamente qué texto aparecerá detrás del número de comentarios, es decir, a lo más podríamos hacer que apareciera "3 comentarios, ¡comenta ya!" o mensajes así, pero nunca con lógica dependiente del número, lo cual resulta demasiado lineal y cutre para un blog de renombre como el nuestro ;-)
A lo largo de este post vamos a modificar la plantilla para hacer que se muestre un mensaje cuando no hay ningún comentario, otro distinto cuando hay sólo uno, y otro para el resto de los casos. Esto podríais después complicarlo todo lo que queráis, pero de momento con lo que vamos a ver será suficiente para que podáis empezar a jugar.
En primer lugar he de decir que, al igual que ocurría el otro día cuando tratamos el tema de modificar la forma de aparecer la lista de categorías en Blogger, lo más prudente es hacer una copia de seguridad de la plantilla, pues cualquier paso en falso puede tumbar nuestra bitácora. Por si no viste el post anterior, la forma de hacerlo era accediendo al panel de administración de la herramienta y pulsando el enlace "Descargar plantilla completa" que encontrarás en la pestaña "Plantilla", opción "Edición de HTML".Una vez realizado el backup, podemos continuar sin peligro.
A continuación, marcamos la casilla "Expandir plantillas de artilugios", que nos permitirá acceder al código fuente completo de los Widgets, que son los elementos, bloques o controles que componen la interfaz de Blogger.Una vez marcada esta casilla, podemos desplazarnos sobre el texto y buscar una porción de código similar a este, donde se ve claramente el comportamiento por defecto del gestor a la hora de mostrar el número de comentarios de una entrada:
<b:if cond='data:post.numComments == 1'>
1 <data:commentLabel/>:
<b:else/>
<data:post.numComments/> <data:commentLabelPlural/>:
</b:if>A simple vista se entiende el comportamiento por defecto del sistema, ¿no? Fijaos que se distingue cuando hay un único comentario para poner la etiqueta en singular, mientras que en resto de casos es en plural.
Si escudriñáis en el código de la plantilla, detectaréis que hay dos puntos donde aparece una porción similar. Uno de ellos es para indicar la presentación en la página principal de vuestro Blog, donde aparece la lista de los últimos posts; el otro es para la página individual de cada post. A efectos prácticos, lo que quiere decir es que podemos establecer reglas diferentes para cada caso, aunque por simplificar un poco el ejemplo no lo haremos aquí.
Pues bien, vamos a modificarlo ligeramente para animar al lector a participar en el blog con sus comentarios. Por cierto, no me gusta mucho moverme en el interior del textarea de Blogger. Prefiero llevarme el código a un editor de texto de mi equipo, y desde ahí manipularlo todo lo que quiera. Una vez he acabado de hacer los cambios, copio y pego sobre el cuadro de edición y listo; o si lo he salvado a mi disco, también podría subirse usando la opción de cargar o subir la plantilla disponible en la parte superior de la pantalla.
En cualquier caso, el nuevo código a incluir sería:
<b:if cond='data:post.numComments == 1'>
Ya hay 1 comentario, ¡participa!
<b:else />
<b:if cond='data:post.numComments == 0'>
No hay comentarios. ¡Sé el primero!
<b:else />
<data:post.numComments/> <data:commentLabelPlural/>:
</b:if>
</b:if>Como se puede comprobar, si sólo hay un comentario lo indicamos y hacemos un llamamiento directo a la participación del usuario. Si no hay comentario alguno, animamos a ser el primero en comentar, y en el resto de los casos, hacemos como siempre.
Vamos, que ya no hay excusa para que en tu blog no haya participación. ;-D
jueves, 6 de septiembre de 2007
Visitando algunos blogs, me he fijado que aquellos que usamos Blogger sufrimos un pequeño problemilla a la hora de presentar la lista con las etiquetas principales de nuestros posts: mostramos todos los tags, por insignificantes que hayan sido, aunque sólo los hayamos tocado de refilón.
Personalmente, creo que la lista de etiquetas aportan una forma rápida y clara de ver de qué trata principalmente nuestro blog, y no es muy positivo tener una lista interminable de tags, la mayoría de ellos con una única entrada asociada.
Aunque Blogger permite dos formas de verlas, en orden alfabético o según su frecuencia, el resultado es igual de terrible. En el primer caso se entremezclan los tags significativos con los que no lo son; en el segundo, la lista de etiquetas importantes vendría seguida de la lista de tags sin peso, que alargan y hacen más pesada la página innecesariamente.
Sin embargo, el potente sistema de plantilla de Blogger permite "retocar" de forma sencilla este comportamiento. En este caso, vamos a hacer que sólo aparezcan en esta lista los tags que tengan más de una entrada, aunque de la misma manera podríamos hacerlo para incorporar otras lógicas más o menos complejas.
Vamos a ver cómo se hace.
En primer lugar, debemos acceder, desde el panel de Blogger a la opción "Plantilla", seleccionando la subopción "Edición HTML".
Importante antes de seguir: si no lo has hecho ya, no vendría mal realizar una copia de seguridad de tu plantilla actual. Puedes hacerlo simplemente pulsando el enlace "Descargar plantilla completa" que encontrarás en la zona superior de la página. De esta forma, si metes la pata podrás volver a dejarlo todo como estaba. :-)
Ahora, fíjate que aparece un cuadro de edición con el código fuente de la plantilla, aunque debes marcar la casilla "Expandir plantillas de artilugios" para tener acceso a las zonas que necesitamos retocar.
Como ayuda, si os es incómodo manipular el texto sobre el cuadro de edición de la web, podéis copiarlo y pegarlo en vuestro editor favorito. Una vez hechas las modificaciones en el código, se vuelve a pegar sobre Blogger y listo.
El siguiente paso es buscar un texto parecido al siguiente (en mi caso está casi al final del código fuente). Puede no ser igual, pero sí que debe ser muy parecido a:
A simple vista, se entiende que se trata del Widget (en mi caso su título es "Categorías") que muestra las etiquetas de los posts del blog, iterando sobre el conjunto de labels registrados (loop sobre data:labels), y montando una lista (ul) donde en cada elemento (li) se dibuja la etiqueta (label.name) y el número de veces que aparece (label.count).
Por tanto, lo que queremos hacer es realmente sencillo. Vamos a incluir en el interior del bucle un condicional que realice estas tareas sólo si el número de veces que se utiliza una etiqueta (label.count) es mayor de uno. El resultado, con el nuevo código resaltado es el siguiente:
Una vez realizado este cambio, podéis previsualizar el resultado usando el botón de "vista previa", y una vez esté todo a vuestro gusto podéis guardarla, pasando desde ese momento a estar activa. Si os aparece algún problema a la hora de previsualizar es posible que hayáis olvidado algún carácter a la hora de copiar y pegar el código: revisadlo detalladamente y seguro que solucionáis el problema. Si, a pesar de todo la cosa se os pone fea, volved a cargar la plantilla que habéis salvado previamente y todo volverá a su estado inicial.
El resultado podéis verlo a la derecha: mi lista de categorías sólo muestra aquellas que tienen más de una entrada. :-)
Espero que os sea de utilidad, o al menos de inspiración para hacer vuestros propios ajustes de Blogger.
Personalmente, creo que la lista de etiquetas aportan una forma rápida y clara de ver de qué trata principalmente nuestro blog, y no es muy positivo tener una lista interminable de tags, la mayoría de ellos con una única entrada asociada.Aunque Blogger permite dos formas de verlas, en orden alfabético o según su frecuencia, el resultado es igual de terrible. En el primer caso se entremezclan los tags significativos con los que no lo son; en el segundo, la lista de etiquetas importantes vendría seguida de la lista de tags sin peso, que alargan y hacen más pesada la página innecesariamente.
Sin embargo, el potente sistema de plantilla de Blogger permite "retocar" de forma sencilla este comportamiento. En este caso, vamos a hacer que sólo aparezcan en esta lista los tags que tengan más de una entrada, aunque de la misma manera podríamos hacerlo para incorporar otras lógicas más o menos complejas.
Vamos a ver cómo se hace.
En primer lugar, debemos acceder, desde el panel de Blogger a la opción "Plantilla", seleccionando la subopción "Edición HTML".
Importante antes de seguir: si no lo has hecho ya, no vendría mal realizar una copia de seguridad de tu plantilla actual. Puedes hacerlo simplemente pulsando el enlace "Descargar plantilla completa" que encontrarás en la zona superior de la página. De esta forma, si metes la pata podrás volver a dejarlo todo como estaba. :-)Ahora, fíjate que aparece un cuadro de edición con el código fuente de la plantilla, aunque debes marcar la casilla "Expandir plantillas de artilugios" para tener acceso a las zonas que necesitamos retocar.
Como ayuda, si os es incómodo manipular el texto sobre el cuadro de edición de la web, podéis copiarlo y pegarlo en vuestro editor favorito. Una vez hechas las modificaciones en el código, se vuelve a pegar sobre Blogger y listo.
El siguiente paso es buscar un texto parecido al siguiente (en mi caso está casi al final del código fuente). Puede no ser igual, pero sí que debe ser muy parecido a:
<b:widget id='Label1' locked='false' title='Categorías' type='Label'>
<b:includable id='main'>
<b:if cond='data:title'>
<h2><data:title/></h2>
</b:if>
<div class='widget-content'>
<ul>
<b:loop values='data:labels' var='label'>
<li>
<b:if cond='data:blog.url == data:label.url'>
<data:label.name/>
<b:else/>
<a expr:href='data:label.url'><data:label.name/></a>
</b:if>
(<data:label.count/>)
</li>
</b:loop>
</ul>
<b:include name='quickedit'/>
</div>
</b:includable>
</b:widget>
A simple vista, se entiende que se trata del Widget (en mi caso su título es "Categorías") que muestra las etiquetas de los posts del blog, iterando sobre el conjunto de labels registrados (loop sobre data:labels), y montando una lista (ul) donde en cada elemento (li) se dibuja la etiqueta (label.name) y el número de veces que aparece (label.count).
Por tanto, lo que queremos hacer es realmente sencillo. Vamos a incluir en el interior del bucle un condicional que realice estas tareas sólo si el número de veces que se utiliza una etiqueta (label.count) es mayor de uno. El resultado, con el nuevo código resaltado es el siguiente:
<b:widget id='Label1' locked='false' title='Categorías' type='Label'>
<b:includable id='main'>
<b:if cond='data:title'>
<h2><data:title/></h2>
</b:if>
<div class='widget-content'>
<ul>
<b:loop values='data:labels' var='label'>
<b:if cond='data:label.count > 1'>
<li>
<b:if cond='data:blog.url == data:label.url'>
<data:label.name/>
<b:else/>
<a expr:href='data:label.url'><data:label.name/></a>
</b:if>
(<data:label.count/>)
</li>
</b:if>
</b:loop>
</ul>
<b:include name='quickedit'/>
</div>
</b:includable>
</b:widget>
Una vez realizado este cambio, podéis previsualizar el resultado usando el botón de "vista previa", y una vez esté todo a vuestro gusto podéis guardarla, pasando desde ese momento a estar activa. Si os aparece algún problema a la hora de previsualizar es posible que hayáis olvidado algún carácter a la hora de copiar y pegar el código: revisadlo detalladamente y seguro que solucionáis el problema. Si, a pesar de todo la cosa se os pone fea, volved a cargar la plantilla que habéis salvado previamente y todo volverá a su estado inicial.
El resultado podéis verlo a la derecha: mi lista de categorías sólo muestra aquellas que tienen más de una entrada. :-)
Espero que os sea de utilidad, o al menos de inspiración para hacer vuestros propios ajustes de Blogger.
miércoles, 5 de septiembre de 2007
Me acabo de encontrar en The Inquirer la siguiente noticia:
Parece que los chicos de Microsoft y los de Novell (desarrolladores principales de Mono) no se llevan nada mal.
Microsoft anuncia Silverlight 1.0 ¡compatible con Linux!
La tecnología pretende competir con Adobe Flash ya ha llegado a su versión 1.0 y está disponible para su descarga y utilización en todo tipo de navegadores. Incluidos los de Linux a través del proyecto Moonlight y del acuerdo entre MS y Novell.
(Seguir leyendo...)
Parece que los chicos de Microsoft y los de Novell (desarrolladores principales de Mono) no se llevan nada mal.
martes, 4 de septiembre de 2007
Esto de que cada navegador utilice su propio dialecto derivado del CSS para indicar atributos, como la transparencia u opacidad de los elementos de una página, tiene su gracia... o mejor pensado, no tiene ninguna gracia.
Menos mal que en CSS-Tricks nos enseñan cómo definirla para que funcionen con prácticamente todos los browsers del universo conocido:
De esta forma, para hacer que un bloque div (por ejemplo) se convierta en semitransparente (al 50% según el ejemplo anterior), sólo habría que poner:
Obviamente, el nivel de opacidad puede modificarse al valor deseado, siendo el 100% el máximo (totalmente opaco) y 0% el mínimo (totalmente transparente). Ojo, que en la primera línea (filter:alpha...) se usa el rango 0-100 y en las restantes este valor dividido entre cien, es decir, en un rango del 0 al 1.
Eso sí, supongo que los validadores CSS igual se quejan un poco. ;-)
Menos mal que en CSS-Tricks nos enseñan cómo definirla para que funcionen con prácticamente todos los browsers del universo conocido:
.transparente
{
filter:alpha(opacity=50);
-moz-opacity:0.5;
-khtml-opacity: 0.5;
opacity: 0.5;
}De esta forma, para hacer que un bloque div (por ejemplo) se convierta en semitransparente (al 50% según el ejemplo anterior), sólo habría que poner:
<div class='transparente'>
... lo que sea
</div>Obviamente, el nivel de opacidad puede modificarse al valor deseado, siendo el 100% el máximo (totalmente opaco) y 0% el mínimo (totalmente transparente). Ojo, que en la primera línea (filter:alpha...) se usa el rango 0-100 y en las restantes este valor dividido entre cien, es decir, en un rango del 0 al 1.
Eso sí, supongo que los validadores CSS igual se quejan un poco. ;-)
domingo, 2 de septiembre de 2007
Hace unos días Miguel de Icaza hablaba en su blog de la inminente posibilidad de hacer funcionar ASP.Net Ajax sobre Mono, incluso comenta un mensaje de Onur Gumus a la lista de programadores de la plataforma explicando cómo hacerlo en la actualidad con versiones internas.Todavía tendremos que esperar un poco para poder incorporarlo en producción, pero sin duda es una buena noticia para los que ya disfrutábamos de estas librerías en el framework de Microsoft y esperábamos ansiosamente su implementación en Mono.
¡Y ya estamos de vuelta! Parece que fue ayer cuando me despedía con la alegría de ver un mes de descanso por delante, y casi sin darnos cuenta ha llegado Septiembre, con todo lo que ello implica.Pero no me refiero exclusivamente a cosas malas, que para recordarlas están los telediarios; también vienen nuevos proyectos, expectativas, ilusiones... todo un año por delante para seguir haciendo lo que nos gusta.
En cuanto a Variable not found, ¡queda oficialmente inaugurada la temporada 07-08!
Nos leemos.
miércoles, 1 de agosto de 2007
¡Por fin llegaron! Salvo un par de maletas pendientes de repasar, todo está listo para comenzar nuestra gira veraniega.
Variable not found, por tanto, quedará a su libre albedrío hasta primeros de Septiembre, momento en el que volveré con más energía que nunca, muy motivado por la evolución del blog y sobre todo por este mes de Julio que ha terminado con una actividad y unas estadísticas de visitas que no habría podido imaginar hace unos meses (debido principalmente al efecto Menéame, todo sea dicho).
En cuanto a las vacas, aunque es posible que hagamos ciertos reajustes en la planificación (hasta en vacaciones hay de eso), tenemos previsto pasar unos cuantos días en El Portil, una pequeña localidad costera a caballo entre Cartaya y Punta Umbría, ambos en provincia de Huelva. Esto será a partir de hoy mismo, hasta finales de la semana que viene.
Después pasaremos unos días también en Sanlúcar de Barrameda, un pueblo de la costa de Cádiz que no tengo la fortuna de conocer, pero según cuentan es una maravilla.
Por último, también pretendemos ir de viaje familiar unos días. No sabemos cuándo. No sabemos a dónde. No sabemos cómo. Digamos que esta es la parte más emocionante del plan vacacional. ;-D.
Nos vemos por aquí a la vuelta.
Variable not found, por tanto, quedará a su libre albedrío hasta primeros de Septiembre, momento en el que volveré con más energía que nunca, muy motivado por la evolución del blog y sobre todo por este mes de Julio que ha terminado con una actividad y unas estadísticas de visitas que no habría podido imaginar hace unos meses (debido principalmente al efecto Menéame, todo sea dicho).
En cuanto a las vacas, aunque es posible que hagamos ciertos reajustes en la planificación (hasta en vacaciones hay de eso), tenemos previsto pasar unos cuantos días en El Portil, una pequeña localidad costera a caballo entre Cartaya y Punta Umbría, ambos en provincia de Huelva. Esto será a partir de hoy mismo, hasta finales de la semana que viene.Después pasaremos unos días también en Sanlúcar de Barrameda, un pueblo de la costa de Cádiz que no tengo la fortuna de conocer, pero según cuentan es una maravilla.
Por último, también pretendemos ir de viaje familiar unos días. No sabemos cuándo. No sabemos a dónde. No sabemos cómo. Digamos que esta es la parte más emocionante del plan vacacional. ;-D.
Nos vemos por aquí a la vuelta.
lunes, 30 de julio de 2007
El pasado miércoles 25 en el blog oficial de Google Analytics publicaban "Notice of Brief Processing Delay", un post donde comentaban que durante el día habría algunos retrasos. No sé si tendrá que ver con esto o con el jolgorio prevacacional, pero me encuentro en mi blog un total de cero visitantes desde hace un par de días... ¡como en los viejos tiempos! :-D
Y aunque sé que es consuelo de tontos, alegra saber que le ocurre a más gente:
En fin, espero al menos que no borren los datos...
Actualización, martes 31 de Julio: ya hay noticias oficiales por parte de Google sobre este retraso:
Y aunque sé que es consuelo de tontos, alegra saber que le ocurre a más gente:
- http://groups.google.com/group/analytics-help-troubleshoot/browse_thread/thread/94acb7f4f84fe168/
- http://www.slicksurface.com/blog/2007/07/google-analytics-down-for-nearly-two.html
- http://groups.google.com/group/analytics-help-troubleshoot/browse_thread/thread/e660e578964bfbbe
- http://groups.google.com/group/analytics-help-basics/browse_thread/thread/3f312ea50966a39d
- http://groups.google.com/group/analytics-help-troubleshoot/browse_thread/thread/105dea7423696537/d1649dd6cdbb8c79#d1649dd6cdbb8c79
- etc.
En fin, espero al menos que no borren los datos...
Actualización, martes 31 de Julio: ya hay noticias oficiales por parte de Google sobre este retraso:
domingo, 29 de julio de 2007
Hoy seguimos con la serie inspirada por Phil Haack en su post "19 Eponymous Laws Of Software Development" donde estoy recogiendo leyes que se aplican en el mundo del desarrollo del software y muchos otros ámbitos. La particularidad de estas leyes y principios es que han hecho famosos a sus autores, pues tienen el mismo nombre que ellos.
Enlaces relacionados: leyes epónimas relacionadas con el desarrollo de software (I)
Ley de Conway
Cualquier software refleja la estructura organizacional de quien lo produjoA pesar de que suena a guasa, la ley de Melvin Conway no puede ser más cierta. Una empresa con tres grupos de desarrollo tenderá a generar software distribuido en tres subsistemas, reflejo fiel de las relaciones entre los grupos participantes. Y por cierto, ¿habéis pensado alguna vez que el software que se hace en vuestra empresa es un desastre? ¿creéis que con esta ley podríais obtener alguna conclusión? ;-D
Principio de Kerchkhoff
En términos de criptografía, un sistema debería ser seguro incluso si todo sobre el mismo se conoce públicamente, salvo una pequeña porción de informaciónEs increíble que Auguste Kerckhoffs critógrafo alemán, enunciara en el siglo XIX este principio, base de todos los sistemas de criptografía de clave pública actuales.
Ley de Linus
Dados suficientes ojos, todos los errores son obviosPues sí, Linus Torvalds, uno de los más famosos artífices de Linux tal y como es conocido hoy en día, no sólo desarrollaba software, también emitía este tipo de aseveraciones. Aunque la frase fue cosa de Linus, fue Eric S. Raymond, un hacker a la antigua usanza, el que la popularizó y le dio el nombre de su creador.
Ley de Reed
La utilidad de grandes redes, y en particular las sociales, crecen exponencialmente con el tamaño de la redDavid P. Reed, científico americano, enunció esto que parece obvio en los tiempos actuales dado el tamaño y utilización de este tipo de redes. En esta entrada de la wikipedia podéis encontrar una introducción del soporte teórico en el que se basa.
Ley de Moore
La potencia de los ordenadores se duplica cada dos años, reduciendo además su costeRepetida hasta la saciedad en revistas de cacharreo, y constatada desde hace décadas, fue promulgada por Gordon Earl Moore quien, por cierto, es co-fundador de Intel, fijaos si lo tenía claro el muchacho, en 1965 (!). No sé si entonces utilizó la bola de cristal o es simplemente un genio, pero desde luego su ley es una referencia de la medida del avance en los ordenadores y demás dispositivos basados en tecnología similar, y un objetivo mínimo a cumplir.
Ley de Wirth
El software se ralentiza más deprisa de lo que se acelera el hardwareBrillante la frase de Niklaus Wirth, que allá por el año 1995, aún sin conocer Windows Vista, observó su entorno y predijo la situación actual: cada vez el software es más lento y pesado, a pesar de que según la Ley de Moore tendría que ser al contrario. Este señor, una eminencia, es conocido sobre todo por haber dirigido la creación de los lenguajes Pascal, Modula y algunos otros menos difundidos.
Ley de Zawinski
Todo programa intenta expandirse hasta que pueda leer emails. Aquél que no pueda ser expandido hasta ese punto, será sustituido por otro que sí tenga esa capacidadLo que más me ha llamado la atención de Jamie Zawinski aparte de su metafórica ley, es su página web personal. No os la perdáis, pues es bastante indicativa del tipo de individuo de que se trata, todo un friki. También es curioso que es propietario de un club nocturno en San Francisco, este sí que sabe.
Enlaces relacionados: leyes epónimas relacionadas con el desarrollo de software (I)
lunes, 23 de julio de 2007
El siempre sorprendente Phil Haack nos regaló hace unos días un post sobre leyes relacionadas con el desarrollo de software en su post "19 Eponymous Laws Of Software Development". Del artículo me llamaron la atención dos cosas: primero, ¿qué diantres es un epónimo? y segundo, las leyes objeto del post; algunas eran muy conocidas, otras menos, pero en cualquier caso, son perlas dignas de tener en cuenta.
Un epónimo es el nombre de una persona o lugar que cede su nombre a una época, pueblo, unidad, ley, etc. Son epónimos por ejemplo "Diesel", cedido por Rudolf Diesel, inventor de este tipo de motores, o "Hamburguesa", infame trozo de carne picada cuyo nombre le fue cedido por su lugar de origen. Para los curiosos, en esta dirección encontraréis muchos más epónimos.
Solventada esta primera duda, pasamos a ver las leyes epónimas a las que Phil hace referencia. De las diecinueve originales he seleccionado las que me han resultado más interesantes y cercanas, añadiendo algo de información sobre sus autores, orígenes o curiosidades sobre las mismas. Me tendréis que perdonar por esto, pero voy a partir el post en dos entregas para no hacerlo demasiado largo.
Bueno, ya vale por hoy, peroamenazo con prometo seguir pronto.
Un epónimo es el nombre de una persona o lugar que cede su nombre a una época, pueblo, unidad, ley, etc. Son epónimos por ejemplo "Diesel", cedido por Rudolf Diesel, inventor de este tipo de motores, o "Hamburguesa", infame trozo de carne picada cuyo nombre le fue cedido por su lugar de origen. Para los curiosos, en esta dirección encontraréis muchos más epónimos.
Solventada esta primera duda, pasamos a ver las leyes epónimas a las que Phil hace referencia. De las diecinueve originales he seleccionado las que me han resultado más interesantes y cercanas, añadiendo algo de información sobre sus autores, orígenes o curiosidades sobre las mismas. Me tendréis que perdonar por esto, pero voy a partir el post en dos entregas para no hacerlo demasiado largo.
Ley de Postel
Sé conservador en lo que hagas y liberal en lo que aceptes de los demásEsta frase, de Jonathan Bruce Postel, también llamada Principio de Robustez, es la piedra filosofal del protocolo TCP, y está recogida en la RFC 793, sección 2.10, de septiembre de 1981.
Ley de Parkinson
El trabajo se extiende siempre hasta rellenar la totalidad del tiempo disponible para completarloEsta ley fue postulada inicialmente en 1955 por C. Northcote Parkinson en The Economist y más tarde entró a formar parte de su libro, basado principalmente en las experiencias de la administración británica.
Principio de Pareto
Para muchos fenómenos, el 80% de las consecuencias derivan del 20% de las causasWilfredo Pareto fue un estudioso de la economía y sociología del siglo XIX, y se fijó que el 80% de las propiedades y riqueza estaban repartidas entre el 20% de la población, enunciando su famoso principio. A partir de ahí, se piensa que esta proporción es cierta en múltiples ocasiones, hasta en el número de bugs en el código fuente de un software, o el tiempo de desarrollo de funcionalidades.
Revelación de Sturgeon
El noventa por ciento de cualquier cosa es una porqueríaTheodore Sturgeon era un autor de ciencia ficción americano que escribió esta frase defendiendo a este tipo de literatura de críticos que opinaban que el 90% era basura. Hay un corolario que dice
"La revelación de Sturgeon es cierta salvo para la porquería, donde el 100% es porquería".
El principio de Peter
En una jerarquía, todo individuo tiende a subir hasta alcanzar su nivel de incompetenciaSeguro que todos conocéis ejemplos de ello: un fabuloso desarrollador es ascendido a directivo en una empresa, la cual gana un gestor pésimo y pierde un programador excelente. Doble penalización. Lawrence J. Peter, pedagogo de profesión, ya lo enunció en 1968 en el libro El principio de Peter.
Ley de Hofstadter
La realización de un trabajo siempre dura más de lo esperado, incluso habiéndose tenido en cuenta la Ley de HofstadterEsta genial y recursiva Ley creada por el científico, filósofo y académico estadounidense Douglas Hofstadter es absolutamente cierta. Y si no, pensad un poco, ¿cuántas veces habéis estimado un desarrollo, lo habéis incrementado de forma considerable por los imprevistos y aún así os habéis quedado cortos?
Ley de Murphy
Si algo puede ir mal, lo haráLa famosa ley, también enunciada en forma de tostada que recurrentemente cae con la mantequilla hacia abajo, fue dictada por Edward A. Murphy, Jr., mientras trabajaba para la fuerza aérea americana como ingeniero, diseñando un sistema de cohetes experimental. Sería lógico pensar que el experimento acabó en tragedia, pero parece ser que la creación y consideración de esta ley les ayudó a evitar graves desastres en sus pruebas.
Ley de Brook
Incluir trabajadores a un proyecto retrasado hará que vaya aún más lentoFred Brooks postuló esta ley en su famoso libro The Mythical Man-Month: Essays on Software Engineering como resultado de su experiencia en IBM. Existen variantes y corolarios como
"Una señora es capaz de tener un hijo en nueve meses, pero este plazo no puede disminuir por muchas mujeres embarazadas que pongamos a ello". Simplemente genial.
Bueno, ya vale por hoy, pero
jueves, 19 de julio de 2007
Hace tiempo ya, oí hablar sobre el libro The Mytical Man-Month, de Frederick P. Brooks, donde se asegura que los mejores programadores rinden hasta 10 veces más que los que se encuentran en el lado opuesto, los peores. Otras fuentes, como "Facts and Fallacies of Software Engineering" llegan a indicar que la diferencia puede ser incluso de 28 a 1.
Sin duda, la productividad en el desarrollo es algo más que tirar muchas líneas de código por día; ya lo comenta Charles Connell en su artículo It's not about lines of code, donde explica por qué la productividad no puede ser medida en esos términos, de hecho, ¿muchas líneas de código implican un trabajo bien hecho? ¿y si se trata de un nido de bugs?
Así, a lo largo de su artículo, Charles va definiendo y añadiendo características que debería presentar el código creado hasta llegar a una posible unidad de medida de la productividad, líneas de código limpio, simple, correcto y bien documentado por día, para finalmente llegar a la conclusión de que tampoco es del todo apropiado: ¿qué ocurre si un buen desarrollador es capaz de crear una función en 100 líneas de código perfecto y salir de la oficina a la hora habitual, mientras que otros realizan el mismo buen trabajo en 2000 líneas de código trabajando hasta altas horas de la madrugada? ¿quién es más productivo?
La conclusión de Charles es que la productividad de un desarrollador es justamente su habilidad para resolver problemas de forma rápida. La ingeniería del software trata precisamente de eso, de aportar soluciones a los usuarios que usarán el sistema desarrollado, todo lo demás sobra. Sin embargo, como él mismo indica, es realmente difícil medir estas capacidades utilizando indicadores habituales como número de líneas de código, bugs provocados o tiempo de trabajo en la oficina.
Partiendo de esto, en "10 Developers For The Price Of One", Phil Haack, cuyo apellido seguro que lo predestinó a dedicarse a la informática, escribe sobre este tema centrando la medida de la productividad de los desarrolladores en torno al concepto TCO (Total Cost of Ownership), o Coste Total de Propiedad (CTO), e introduce algunas características propias de los buenos desarrolladores que hace que este factor sea óptimo.
La primera de ellas es la asunción de un proyecto como propio, la autosuficiencia en la resolución de problemas, tomar el control, resolver y asumir el avance del mismo como un objetivo personal. De esta forma se libera a los responsables de estar tan pendientes de estos aspectos y se recurre a ellos sólo cuando surgen problemas de entidad y con objeto de plantear una solución. Un desarrollador que escribe código rápido no es productivo, pues requiere de tiempo de los demás, y sobre todo, de aquellos que por sus responsabilidades disponen de menos tiempo.
La segunda hace referencia a la escritura de código con pocos errores. Un mal programador que escriba código muy rápidamente es un generador de bugs a una velocidad proporcional, lo que provocaría un mayor gasto de tiempo del equipo de testeo y control de calidad, así como del propio equipo de desarrollo en la corrección de los errores. Como comenta Phil, de nada vale ir rápido hacia la dirección equivocada.
En la tercera, se introduce el concepto de la creación de código mantenible. Y no sólo pensando en el mantenimiento futuro del software, sino durante el propio desarrollo inicial. Me ha gustado mucho su visión sobre esto, textualmente,
En cuarto lugar, comenta que los buenos desarrolladores hacen más con menos código, son capaces de identificar cuándo deben y cuándo no deben escribir software y utilizar componentes o elementos existentes. El reinvento de la rueda, no es beneficioso para nadie, y los buenos programadores suelen y deben esquivarlo.
Teniendo todos estos aspectos en cuenta, Phil retoma el concepto TCO indicando que todos estos factores son importantes a la hora de evaluar la productividad de un desarrollador en tanto en cuanto que influyen en el coste total de tener a un programador en la empresa, y no sólo fijándose en el coste directo que representa su nómina. Por ello asegura que intenta contratar, aunque no siempre lo consigue, al mejor desarrollador que encuentra en cada momento puesto que si es capaz de hacer más con menos código, escribir de forma inteligible, fácilmente mantenible y con menos errores, incrementará la productividad de sus compañeros, directivos y colegas. Por el contrario, un mal desarrollador puede disminuir la productividad de su entorno por los motivos anteriormente expuestos. Por este motivo puede justificarse la relación de 28 a 1 en la productividad entre unos y otros.
Estoy absolutamente de acuerdo con estas apreciaciones, un desarrollador no puede ser evaluado únicamente teniendo en cuenta aspectos cuantitativos como la cantidad de líneas de código que es capaz de generar: si lo que buscas es velocidad a la hora de teclear, contrata a un mecanógrafo, leche. Y aunque para cerrar un proyecto hace falta escribir líneas, tanto o más importante es la calidad con que esto se haga o tener capacidad para decidir cuándo hay que reutilizar en vez de escribir.
Quizás, por poner alguna pega, echo en falta un par de factores que a mi entender son fundamentales para aumentar la productividad en el desarrollo, y están relacionadas con la visión global introducida en el artículo citado anteriomente.
En primer lugar, la capacidad de comunicación bidireccional, es decir, ser tanto capaz de entender los mensajes de los usuarios, de analistas, comerciales o cualquier otro grupo de interés, como transmitir claramente mensajes, problemas o cuestiones siempre adaptándose a su interlocutor. Esta es, en mi opinión, una habilidad difícil de encontrar y que puede repercutir de forma muy negativa en la productividad global de un equipo de trabajo. ¿Quién no ha tenido que desechar código por culpa de un malentendido?
En segundo lugar, es fundamental la facilidad de integración en equipos de trabajo. Los desarrolladores trabajando en islas son difíciles de ver, la complejidad del software actual hace que en casi cualquier proyecto tengan que intervenir varias personas colaborando de forma muy estrecha. Además, en una máquina perfecta de producción de software la información y conocimientos fluyen con facilidad, lo cual influye en la productividad de cada uno de los componentes de la misma.
Sin duda, la productividad en el desarrollo es algo más que tirar muchas líneas de código por día; ya lo comenta Charles Connell en su artículo It's not about lines of code, donde explica por qué la productividad no puede ser medida en esos términos, de hecho, ¿muchas líneas de código implican un trabajo bien hecho? ¿y si se trata de un nido de bugs?
Así, a lo largo de su artículo, Charles va definiendo y añadiendo características que debería presentar el código creado hasta llegar a una posible unidad de medida de la productividad, líneas de código limpio, simple, correcto y bien documentado por día, para finalmente llegar a la conclusión de que tampoco es del todo apropiado: ¿qué ocurre si un buen desarrollador es capaz de crear una función en 100 líneas de código perfecto y salir de la oficina a la hora habitual, mientras que otros realizan el mismo buen trabajo en 2000 líneas de código trabajando hasta altas horas de la madrugada? ¿quién es más productivo?
La conclusión de Charles es que la productividad de un desarrollador es justamente su habilidad para resolver problemas de forma rápida. La ingeniería del software trata precisamente de eso, de aportar soluciones a los usuarios que usarán el sistema desarrollado, todo lo demás sobra. Sin embargo, como él mismo indica, es realmente difícil medir estas capacidades utilizando indicadores habituales como número de líneas de código, bugs provocados o tiempo de trabajo en la oficina.Partiendo de esto, en "10 Developers For The Price Of One", Phil Haack, cuyo apellido seguro que lo predestinó a dedicarse a la informática, escribe sobre este tema centrando la medida de la productividad de los desarrolladores en torno al concepto TCO (Total Cost of Ownership), o Coste Total de Propiedad (CTO), e introduce algunas características propias de los buenos desarrolladores que hace que este factor sea óptimo.
La primera de ellas es la asunción de un proyecto como propio, la autosuficiencia en la resolución de problemas, tomar el control, resolver y asumir el avance del mismo como un objetivo personal. De esta forma se libera a los responsables de estar tan pendientes de estos aspectos y se recurre a ellos sólo cuando surgen problemas de entidad y con objeto de plantear una solución. Un desarrollador que escribe código rápido no es productivo, pues requiere de tiempo de los demás, y sobre todo, de aquellos que por sus responsabilidades disponen de menos tiempo.
La segunda hace referencia a la escritura de código con pocos errores. Un mal programador que escriba código muy rápidamente es un generador de bugs a una velocidad proporcional, lo que provocaría un mayor gasto de tiempo del equipo de testeo y control de calidad, así como del propio equipo de desarrollo en la corrección de los errores. Como comenta Phil, de nada vale ir rápido hacia la dirección equivocada.
En la tercera, se introduce el concepto de la creación de código mantenible. Y no sólo pensando en el mantenimiento futuro del software, sino durante el propio desarrollo inicial. Me ha gustado mucho su visión sobre esto, textualmente,
Tan pronto como una línea de código sale de la pantalla y volvemos a ella, estamos en modo mantenimiento de la misma". Un código bien escrito, comprensible y limpio puede ahorrar mucho tiempo en el presente y futuro.
En cuarto lugar, comenta que los buenos desarrolladores hacen más con menos código, son capaces de identificar cuándo deben y cuándo no deben escribir software y utilizar componentes o elementos existentes. El reinvento de la rueda, no es beneficioso para nadie, y los buenos programadores suelen y deben esquivarlo.
Teniendo todos estos aspectos en cuenta, Phil retoma el concepto TCO indicando que todos estos factores son importantes a la hora de evaluar la productividad de un desarrollador en tanto en cuanto que influyen en el coste total de tener a un programador en la empresa, y no sólo fijándose en el coste directo que representa su nómina. Por ello asegura que intenta contratar, aunque no siempre lo consigue, al mejor desarrollador que encuentra en cada momento puesto que si es capaz de hacer más con menos código, escribir de forma inteligible, fácilmente mantenible y con menos errores, incrementará la productividad de sus compañeros, directivos y colegas. Por el contrario, un mal desarrollador puede disminuir la productividad de su entorno por los motivos anteriormente expuestos. Por este motivo puede justificarse la relación de 28 a 1 en la productividad entre unos y otros.
Estoy absolutamente de acuerdo con estas apreciaciones, un desarrollador no puede ser evaluado únicamente teniendo en cuenta aspectos cuantitativos como la cantidad de líneas de código que es capaz de generar: si lo que buscas es velocidad a la hora de teclear, contrata a un mecanógrafo, leche. Y aunque para cerrar un proyecto hace falta escribir líneas, tanto o más importante es la calidad con que esto se haga o tener capacidad para decidir cuándo hay que reutilizar en vez de escribir.
Quizás, por poner alguna pega, echo en falta un par de factores que a mi entender son fundamentales para aumentar la productividad en el desarrollo, y están relacionadas con la visión global introducida en el artículo citado anteriomente.
En primer lugar, la capacidad de comunicación bidireccional, es decir, ser tanto capaz de entender los mensajes de los usuarios, de analistas, comerciales o cualquier otro grupo de interés, como transmitir claramente mensajes, problemas o cuestiones siempre adaptándose a su interlocutor. Esta es, en mi opinión, una habilidad difícil de encontrar y que puede repercutir de forma muy negativa en la productividad global de un equipo de trabajo. ¿Quién no ha tenido que desechar código por culpa de un malentendido?En segundo lugar, es fundamental la facilidad de integración en equipos de trabajo. Los desarrolladores trabajando en islas son difíciles de ver, la complejidad del software actual hace que en casi cualquier proyecto tengan que intervenir varias personas colaborando de forma muy estrecha. Además, en una máquina perfecta de producción de software la información y conocimientos fluyen con facilidad, lo cual influye en la productividad de cada uno de los componentes de la misma.
Curiosamente, ninguna de estas dos habilidades son técnicas... Sin duda esto de la productividad es un tema tan interesante como complejo, ¿eh?
martes, 17 de julio de 2007
Como en internet hay de todo, a alguien se le ha ocurrido desarrollar una bonita web en Flash con un curioso jueguecillo: se nos van mostrando consecutivamente fotografías de personajes (concretamente diez), y debemos identificar cuál de ellos es un inventor de lenguajes de programación y cuál es un asesino en serie (!).
Y es que es verdad que algunos tienen unas pintas... Pero bueno, seguro que si en vez de hacerlo con informáticos lo hacen con cualquier otro tipo de profesionales les habría quedado igual de bien, aunque probablemente perdería el morbo que tienen los programadores y su fama de ser gente rara, muy rara, y con un físico acompañando a su presunta personalidad.
La dirección es: http://www.malevole.com/mv/misc/killerquiz.
He acertado 9 sobre 10, se ve que identifico bien a mis colegas... (me refiero a los programadores, claro ;-)). ¿Y tú? ¿Qué nota has conseguido?
Y es que es verdad que algunos tienen unas pintas... Pero bueno, seguro que si en vez de hacerlo con informáticos lo hacen con cualquier otro tipo de profesionales les habría quedado igual de bien, aunque probablemente perdería el morbo que tienen los programadores y su fama de ser gente rara, muy rara, y con un físico acompañando a su presunta personalidad.La dirección es: http://www.malevole.com/mv/misc/killerquiz.
He acertado 9 sobre 10, se ve que identifico bien a mis colegas... (me refiero a los programadores, claro ;-)). ¿Y tú? ¿Qué nota has conseguido?
viernes, 13 de julio de 2007
A partir de ayer mismo, por cortesía de Armonth (fundador de SigT), tengo el honor de compartir cartel con los grandes maestros en Planet Webdev, un agregador de blogs sobre programación e internet de lo más recomendable por la cantidad, y sobre todo la calidad, de los autores que colaboran en el proyecto.Por citar sólo a algunos, podemos encontrar a Anieto2k, Javier Pérez, InKiLiNo, Boja, Xavier, y así hasta 30 figuras de este mundillo.
Espero contribuir desde Variable not found a difundir información y compartir conocimientos y experiencias sobre esta profesión que tanto nos apasiona.
