Nota del autor

Si la entrada que estás leyendo carece de imágenes, no se ve el vídeo que teóricamente lleva incrustado o el código fuente mostrado aparece sin formato, podéis conocer los motivos aquí. Poco a poco iré restableciendo la normalidad en el blog.
Este blog es un archivo de los artículos situados previamente en Lobosoft.es y ha dejado de ser actualizado. Las nuevas entradas pueden encontrarse en www.lobosoft.es. Un saludo,
Lobosoft.

martes, 29 de abril de 2008

Generación de código con DSL Tools

Una de las posibilidades más interesantes de DSL Tools para Visual Studio es la generación de artefactos y código a partir del elementos pertenecientes al modelo de dominio que definamos para nuestro DSL. En el ejemplo de hoy usaremos el proyecto más básico de cuantos ofrece Visual Studio DSL Tools para obtener un generador de código básico que permitirá, definir un "lenguaje de programación visual" para nuestros usuarios. Obviamente, el alcance de la programación será algo limitado, máxime si tenemos en cuenta que se trata de un mero ejemplo de generación de código, pero nos permitirá vislumbrar hasta qué punto es potente y flexible esta herramienta.


En primer lugar, entramos a Visual Studio y creamos un nuevo proyecto Domain-Specific Languaje Designer, dentro de las plantillas Extensibility. Daremos un nombre a la solución, por ejemplo, MyDSLGenerator, y al pulsar en OK aparecerá un asistente para definir algunos de los parámetros de nuestro DSL. Seleccionaremos la plantilla MinimalTemplate, la extensión que tendrán los archivos de nuestro lenguaje (.mydlsg, en este ejemplo), y otras características como el espacio de nombres raíz para los proyectos de la solución. Hecho esto, pulsaremos en Finalizar, y tendremos ante nosotros el diseñador del DSL. Lo primero que nos preguntará siempre (a menos que indiquemos que no deseamos ser advertidos de ello) es que va a procederse a regenerar todos los archivos de la solución a partir de los Text Templates (archivos .tt) de la misma. Aceptamos, y nos encontraremos con algo similar a lo siguiente:



dsl1.PNG


Aunque podemos personalizar todo el DSL desde el proyecto Dsl de la solución, optaremos en esta entrada introductoria por hacer los mínimos cambios posibles. En primer lugar, hemos renombrado el nombre de los elementos del diagrama (ExampleShape, ExampleConnector, etc.).



dsl2.PNG


Lo más importante aquí va a ser definir una nueva propiedad de dominio sobre la clase xxElement (en nuestro caso, ActivityElement), ya creada por la propia plantilla del DSL. A esta propiedad podremos darle un valor, posteriormente, para cada Shape correspondiente a la clase que dibujemos en nuestro diseñador, o lo que es lo mismo, para cada objeto instanciado de la clase. Introduciremos una actividad denominada "Activity", de tipo string.



dsl21.PNG


Dentro del DSL Explorer haremos lo propio con las opciones correspondientes al Editor (Editor->Toolbox Tabs-> ActivitiesDesigner->Tools), para que aparezcan también los nombres en el Visual Studio Hive, y en la aplicación DSL una vez que la instalemos en otro equipo.



dsl3.PNG


Volvemos a generar el código del proyecto, pulsando sobre el botón Transform All Templates, y ejecutamos (F5). Aparecerá el Visual Studio Hive.


Creamos un diagrama acorde con lo especificado en nuestro DSL. Por ahora, lo único que hará es asignar una serie de propiedades a los Shapes (los rectángulos correspondientes a nuestras actividades). Estas propiedades son las que definimos anteriormente en el diseñador del DSL. Por un lado, la propiedad Name, que ya venía definida con la propia clase, y la propiedad Activity, que incluimos en ese momento.



dsl5.PNG


Para cada Shape, damos valor a las propiedades Name y Activity.



dsl6.PNG


Ahora vamos a preparar nuestro generador de código. Se tratará de un TextTemplate, de modo que añadimos un nuevo elemento al proyecto, de tipo fichero de texto, con el nombre LibraryCode.tt, y que va a permitir la generación de código a partir de los elementos existentes en nuestros diagramas. Más adelante nos quedará ver cómo llevar a cabo esta acción automáticamente cada vez que añadamos un elemento de nuestro lenguaje (archivo con extensión .mydlsg, que es la que definimos con este fin). De momento, lo generamos a mano, y le damos contenido.








using System;
using System.Collections.Generic;
using System.Text;
using LOBOSOFT.MyDSLGenerator;

namespace LOBOSOFT.Activity
{


///
/// The MainClass is the enter point for the functionality of this assembly
///
public class MainClass
{
public void MainMethod()
{
<# /* Calls to the private classes */
foreach(ActivityElement activity in this.ActivitiesModel.Elements){ #>
// Sequential caller
Class oClass = new Class();
oClass.m();


}
}

<# /* Creating classes for the Diagram Activities */
foreach(ActivityElement activity in this.ActivitiesModel.Elements)
{
#>
///
/// The Class gives functionality for managed class (test case)
///
public class Class
{
public void m()
{
o = new ();
o.MainMethod();
}
}
<#
}
#>

}

A grandes rasgos, este código se encarga de recorrer los elementos de nuestro diagrama, generando código según los valores que hemos definido para las propiedades. En primer lugar, se encuentran una serie de directivas.


<#@ template language="C#v3.5"..., por ejemplo, indica el lenguaje usado para la plantilla, ya que después de generar el código, será validado sintácticamente según las reglas del lenguaje, y compilado en una DLL cuando compilemos nuestro proyecto. El v3.5 es opcional, y sería necesario para aplicaciones que usen C# del .NET Framework 3.5 (como por ejemplo, que hagan uso de LINQ).
indica que haremos uso del archivo .mydslsg llamado Sample1. Por tanto, cada TextTemplate (.tt) irá vinculado inicialmente a un .mydslg, aunque veremos más adelante que esto podrá automatizarse.

El resto del template "escribe" el código en C# que necesitamos. Si pulsamos con el botón derecho del ratón sobre el archivo y seleccionamos la opción Run Custom Tool, o bien pulsamos sobre el botón Transform All Templates se generará el código C# asociado. En nuestro caso, el código correspondiente es el siguiente:


[csharp]
using System;
using System.Collections.Generic;
using System.Text;
using LOBOSOFT.ManagedDLLEncapsulation;

namespace LOBOSOFT.Activity
{

///
/// The MainClass is the enter point for the functionality of this assembly
///
public class MainClass
{
public void MainMethod()
{
// Sequential caller
pruebaClass opruebaClass = new pruebaClass();
opruebaClass.mprueba();

}
}

///
/// The pruebaClass gives functionality for prueba managed class (test case)
///
public class pruebaClass
{
public void mprueba()
{
prueba oprueba = new prueba();
oprueba.MainMethod();
}
}

}
[/csharp]

El código será generado e incluso compilado si hemos incluido en las referencias del proyecto las DLLs que estamos usando.

Nos quedará por ver cómo automatizar varios de estos procesos, y cómo realizar el despliegue en otro ordenador de este DSL gráfico, pero eso será en una próxima entrega.

lunes, 28 de abril de 2008

Open Proj, la alternativa libre a Microsoft Project

A la hora de planificar un proyecto de desarrollo software que implique el trabajo de varios desarrolladores y diversas tareas a acometer, la herramienta idónea para ello era Microsoft Project. Sin embargo, y aunque el potencial de la herramienta es muy alto, posiblemente como ocurre con tantas otras, no llegamos a aprovechar ni el 50% de sus posibilidades en el día a día, lo que no justifica el importante gasto en licencias que supone adquirir una o más copias de la herramienta. Además, nos encontramos con una aplicación propietaria, de código cerrado, de la que no es posible saber qué hace entre bambalinas, ni personalizarla en modo alguno. Por si esto fuera poco, sólo funciona en sistemas Windows. Ante esto, si la magnitud de los proyectos que vamos a llevar a cabo no justifica la adquisición de una o más licencias de Microsoft Project, no deseamos usar software privativo o, simplemente, queremos buscar una alternativa a la aplicación de Microsoft, tenemos algunas opciones interesantes dentro del mundo del software libre.


openproj-big-small.jpg


Una de las más interesantes es Open Proj, una aplicación open source que puede utilizarse en Linux, Unix, Mac o Windows, y que además accepta ficheros en el formato Project de Microsoft. Aunque no ofrece el 100% de la funcionalidad de su hermano privativo, lo cierto es que ese 40% real que usamos del mismo viene soportado con creces en esta aplicación multiplataforma. La probé hace algún tiempo, y ahora que la estoy usando por propia iniciativa en proyectos profesionales he de admitir que no tiene nada que envidiar a la aplicación de Microsoft. Una interfaz gráfica de similares características (eso sí, algo menos fluida, debido a que usa JRE para su ejecución y los WinForms suelen ser más eficientes en entornos Windows), y similares opciones a la hora de gestionar nuestros proyectos. Recomendable, sin duda alguna.

Windows Server 2008 y PowerShell

 


powershell.jpg


El pasado 18 de abril asistí a una serie de charlas sobre los nuevos productos de Microsoft: Windows Server 2008, virtualización con Hyper-V, SQL Server 2008, IIS 7.0, Visual Studio 2008 y Silverlight 2.0. De todas ellas, una de las que me llamaron más poderosamente la atención fue la referentes a virtualización, ya que Hyper-V es un producto bastante interesante para aquellas empresas, cada vez más, que trabajan con virtualización, aunque los requisitos de la misma son algo exigentes, sobre todo respecto al hardware, ya que requieren de determinadas familias de procesadores que tengan soporte para la virtualización. La otra que me interesó (aunque dedicado a la programación desde hace unos cuantos añitos, el ser de Sistemas sigue tirando), es referente a Windows Server 2008 y un par de características de este sistema operativo para servidores. Una, la inclusión de un modo Windows Server Core, que no dispone de interfaz gráfica, solamente incluye línea de comandos, y que será idónea para servidores con los que no haya que interactuar habitualmente, o estén disponibles de forma remota. También, obvia decirlo, será una instalación ideal para equipos potentes, pero en los que no deseemos consumir recursos innecesarios en la interfaz gráfica. La forma de administrar estos servidores, al igual que cualquier otro Windows Server 2008 que se precie, será a través de la línea de comandos, con PowerShell, que es la otra novedad a que me refería, y la más interesante de todas. PowerShell es un entorno de trabajo en la línea de comandos que posibilitará a los administradores de sistemas exprimir al máximo las posibilidades de Windows Server. En mi caso, que trabajé hace unos años en la administración de servidores con Windows Server 2003 (particularmente creando entornos de seguridad y trabajo remoto mediante Active Directory e ISA Server), las herramientas de configuración del servidor se me quedaban cortas, y esto es algo que a cualquier administrador de sistemas Windows le habrá ocurrido a poco que haya intentado sacar partido a las posibilidades del sistema operativo. Esta tortura llega a su fin con PowerShell, ya que no sólo muchas de las opciones del Server estarán disponibles con un mayor potencial a través de su interfaz, sino que no serán accesibles de ningún otro modo.


 


ps.jpg


PowerShell permite además el trabajo conjunto de administradores y programadores, ya que su núcleo está basado en .NET Framework (es, por tanto, un Shell hasta cierto punto orientado a objetos), y Microsoft lo incorpora en Windows Vista y todas las versiones de Windows Server 2008. Sin embargo, para aquellos que deseen probarlo con Windows XP, es posible gracias a la instalación de un paquete que proporciona Microsoft, y que servirá para ir practicando antes de enfrentarnos a un Server 2008 en producción.


P.S.: Por cierto, quién lo diría hace unos años. Linux cada vez tiende más a sacar distribuciones para PCs de escritorio y usuarios finales, y Microsoft lanza un S.O. servidor, en modo consola y con un shell que nada tiene que envidiar a Korn o Bash o Bourne shell...

viernes, 25 de abril de 2008

Hacienda reclama a la SGAE sus deudas

Ya iba tocando poder leer una noticia como ésta. El fisco reclama a la SGAE unos 6 millones de euros por intereses de demora. Como ya dijo Stallman en una conferencia que dió en Gijón hace unos años, la SGAE "es muy mala, no merece existir y debe ser eliminada", añadiendo después que "la SGAE intenta aplacar la libertad de expresión con demandas para cerrar los sitios web que la critican y pretende eliminar el software capaz de compartir música, algo a lo que todo debemos
tener derecho". Encima, son mafi... esto... morosos. A ver si tiran de la manta de una vez. Y es que Hacienda somos todos ;).


Pulse sobre la imagen para ampliar.

miércoles, 23 de abril de 2008

Error en la web

¡No puedor, no puedor!, que diría el inefable Chiquito de la Calzada.


En la noche del 23 al 24 de abril (este San Jorge y su dragón...), la versión de Wordpress en el que se basa Lobosoft actualmente cayó por la tremenda carga en plugins que soportaba. Como me suele comentar mi amigo Fernando, de Alblogera, esto no es un blog, parece un portal web de tan rococó que resulta.


A los lectores que recibieron un error similar al siguiente:

Fatal error: Allowed memory size of 8388608 bytes exhausted (tried to allocate 77824 bytes) in /home/lobosxxx/xxxxxxxxxxxxx/wp-admin/includes/xxxxxxx.php on line 460



les debemos una disculpa. De momento, y ante la imposibilidad de solucionar el error del script (se trata de un problema de eficiencia con PHP 4 -aunque la cuestión es que en mi servidor se ejecuta PHP5-, la versión de Wordpress que uso, y posiblemente por una programación poco óptima de alguno de los plugins), he desactivado todos. El problema se da porque la base de datos ha crecido demasiado y en algún punto se intentan cargar en memoria demasiados datos, lo que provoca el error. Lo próximo va a ser, en estos días, una actualización de Wordpress y una criba de los plugins que mantengo. En cualquier caso, y por si alguien recibiese un error similar, los pasos a probar serían:




  1. Si tenemos acceso al servidor, cambiar en el fichero /etc/php5/apache2/php.ini la variable memory_limit = 8M por 16M o los que consideremos necesarios.

  2. Si no es así, incluir en el script que da el problema (justo al inicio), la línea ini_set(”memory_limit”,”16M”);


Después de esto, hemos lucido este "lindo diseño minimalista":

errorweb.PNG


Al menos hasta que mi proveedor de hosting ha aumentado la memoria dedicada a los procesos PHP. Una vez más, pedir disculpas. En breve toda la funcionalidad del sitio web estará restablecida.

lunes, 21 de abril de 2008

Uso dinámico de código no manejado desde .NET

El último día estuvimos viendo cómo usar las funciones de librerías creadas en C desde C#, realizando una importación de la misma en el momento de la compilación. Para ello, era necesario adornar con el atributo DllImport la función que deseáramos usar, y el CLR nos permitiría acceder a la misma. Sin embargo, podría darse el caso de necesitar enlazar con la librería en tiempo de ejecución, por ejemplo, porque fuese un elemento de terceros, o que proporcionase el propio usuario en un momento dado para usarla dentro de nuestra aplicación .NET, por ejemplo, dándonos un codificador o una funcionalidad específica. En ese caso, el proceso se complica un poco (pero no mucho), como veremos a continuación.


Lo primero que tenemos que hacer es pensar cómo estructura la memoria el CLR, y de qué manera se produce la ejecución de una aplicación .NET. Todo el código .NET es código manejado, y como tal se ejecuta sobre un framework, en una capa superior a la del sistema operativo, en una zona de memoria que podríamos denominar "segura". El código no manejado tiene acceso a recursos del propio sistema operativo, lo que lo hace más inseguro, pero a la vez más rápido y eficaz en algunas tareas. Cuando el CLR ejecuta una de nuestras aplicaciones .NET, éstas no tienen acceso a los recursos del sistema de una forma directa, sino a través del propio Framework, lo que evita accesos indebidos a recursos del sistema, así como un mayor control en caso de error. Sin embargo, esto también dificulta el acceso a las funciones que deseamos usar desde las .DLLs (hay que tener en cuenta que las DLLs de .NET no son iguales a las que obtenemos con un compilador de C o C++ "al uso"). Por ello, si queremos usar de forma dinámica de éstas, deberemos recurrir a algún pequeño truco. El primero de ellos, y el más evidente, sería usar código en C++ para acceder a la función de la DLL que deseásemos, y lanzarlo, actuando en cierto modo como un "proxy" entre el código manejado y el no manejado. Sin embargo, esta solución, si bien no es mala, implica un problema y es que para cada función requeriríamos una función proxy en C++. Otra opción más óptima es la de usar algo de lenguaje ensamblador para codificar la llamada a la función, y utilizar librerías de Win32 para ejecutar la llamada.


capas.PNG


Una posible implementación del código en ensamblador sería la siguiente:





; -------------------------------------------------------------
;
; InvokeFuncAsm - Invokes a function through a function pointer passed as
; the first argument. All other parameters are forwarded on, plus the return
; value of the function invoked is returned.
;
; Copyright (c) Richard Birkby, ThunderMain ltd, November 2001
;
; -------------------------------------------------------------

.386
.model flat

option prologue:none
option epilogue:none
option dotname

.code
align DWORD
DllMain proc stdcall public, instance:DWORD, reason:DWORD, reserved:DWORD
mov eax, 1 ; success
ret 12
DllMain endp

align DWORD
InvokeFunc proc stdcall public, funcptr:DWORD

pop ecx ; save return address
pop edx ; Get function pointer
push ecx ; Restore return address
jmp edx ; Transfer control to the function pointer
InvokeFunc endp

end


El código es de Richard Birkby, ya que tengo el ensamblador suficientemente oxidado como para no lanzarme a programar algo así, aunque no sea excesivamente complejo. Básicamente, el código recibe el un puntero a la función a invocar así como los parámetros que recibirá. La carga de la DLL que queremos usar se hará a través de la función LoadLibrary de Kernel32, y su dirección dentro del espacio de ejecución de la aplicación la podemos obtener con GetProcAddress, también de Kernel32. Se ejecuta la función mediante el código en ensamblador, que a su término retorna el valor con una instrucción jmp, que devuelve además el control a la aplicación que la llamó. Al finalizar, liberamos los recursos con FreeLibrary. El código completo puede verse a continuación.



[csharp]
///


/// Usa la librería mediante una importación dinámica, en tiempo de ejecución
///

class UsoDinamico
{
[DllImport("kernel32.dll")]
static extern IntPtr LoadLibrary(string csFileName);

[DllImport("kernel32.dll")]
static extern IntPtr GetProcAddress(IntPtr IntPtr_Module, string
csProcName);

[DllImport("kernel32.dll")]
static extern bool FreeLibrary(IntPtr IntPtr_Module);

[DllImport("Invoke", CharSet = CharSet.Unicode)]
static extern int InvokeFunc(IntPtr funcptr, int operando1,
int operando2);

///
/// Calcula la operación Suma sobre todos los enteros introducidos en los parámetros
/// de la aplicación de consola
///

///
public static void Calcular(string[] args)
{
IntPtr DllACargar = LoadLibrary("c_math_lib.dll");
IntPtr PunteroAFuncion = GetProcAddress(DllACargar, "Sum");
int resultado, operando;

resultado = 0;

for (int i = 0; i < args.Length; i++)
{
int.TryParse(args[i], out operando);
resultado = InvokeFunc(PunteroAFuncion, resultado, operando);
}

Console.WriteLine("El resultado de la operación es " + resultado);

FreeLibrary(DllACargar);
}
}
[/csharp]

Como vemos, es bastante sencillo usar una librería dinámicamente, tanto con una importación implícita, en tiempo de compilación, como explícita durante la ejecución del programa. Nos quedará ver cómo saber qué funciones ofrece, por ejemplo, una DLL, sin necesidad de conocer sus nombres desde un principio, pero esto será tema para otra entrada.

sábado, 19 de abril de 2008

Usando código no manejado desde .NET (con C#)

Una de las situaciones con las que me he encontrado habitualmente en el trabajo, particularmente cuando lo hacía con autómatas y, especialmente, con entornos y lenguajes de programación diversos, era la necesidad de comunicar los diversos procesos, que podían ser aplicaciones completas (y complejas), con una funcionalidad específica e independiente, pero que trabajando en conjunto permitían obtener más beneficios para el usuario. Esto es particularmente cierto, y muy usado, en entornos UNIX, donde cientos de pequeñas (a la par que potentes) aplicaciones interactúan entre sí para permitir incluso la programación de scripts mediante los diversos lenguajes de shell que incorporan.

Sin embargo, hay ocasiones en las que las aplicaciones no han sido pensadas para facilitar este uso, y sus salidas y entradas pueden ser de lo más diversas: stdin/stdout, ficheros de texto o binarios, grabación en bases de datos, uso de sockets, etc. En estos casos, o bien tenemos acceso al código fuente y podemos establecer algún vínculo de comunicación específico, o debemos ingeniárnoslas como mejor podamos para comunicar estos procesos. Si es posible.

Recientemente me encontré en la tesitura de usar aplicaciones desarrolladas en diversos lenguajes (C, C++…) desde .NET Framework. Aunque podría tratarse de ejecutables como tales, lo ideal en este caso, de cara a una futura integración con .NET y ante la imposibilidad de reciclar a todo el personal, el equipo material, etc., lo ideal era reconvertir estas aplicaciones en otras "huecas" que usasen la funcionalidad actual a través de su compilación como librerías DLL, e implementar las futuras que se desarrollasen también mediante DLLs. Sin embargo, aún me encontraba con un pequeño problema. ¿Cómo usar dichas librerías desde .NET? Por un lado, habría que tener en cuenta que las librerías .DLL de .NET Framework no son iguales a las .DLL "de toda la vida", sino que contienen código para ser ejecutado por el CLR. Sin embargo, las .DLLs de C, por ejemplo, contienen código no manejado, que es ejecutado directamente por el sistema operativo, y no por una máquina virtual, como ocurre en .NET o Java. Esto es posible mediante el uso de las librerías que aporta el propio sistema operativo, como veremos a continuación.

Usando una .DLL creada en C, desde C#

El modo más sencillo de usar una librería de C desde .NET es, sin duda, importarla en la compilación de nuestro código. Esto lo conseguimos mediante el atributo [DllImport()], en el que indicaremos la DLL a cargar. Posteriormente declararemos las funciones que deseamos usar de la misma, y listo. Por ejemplo, imaginemos el siguiente código C:int

[c]Sum(int a, int b)
{
return a+b;
}[/c]

Una función que toma dos números enteros, y devuelve el resultado. Para probarlo, creamos un proyecto vacío de Visual C++, de tipo librería DLL, y creamos un archivo con dicha función. Añadimos un fichero de definición del módulo (.def), y le agregamos las líneas:

LIBRARY "c_math_lib"
EXPORTS
Sum


Mediante las mismas, declaramos el nombre de la librería así como las funciones que pone a disposición de sus usuarios (en cierto modo, las que son públicas). Compilamos en modo Release para obtener la librería.

Creamos ahora otra solución (aunque el anterior podría ser un proyecto dentro de la misma) de consola en Visual C#, e incluimos la DLL generada anteriormente.

[csharp]namespace Lobosoft.UsoDLLNoManejadas
{
///
/// Entrada al programa.
/// Usa la librería mediante una importación en tiempo de compilación
///

class Program
{
static void Main(string[] args)
{
[DllImport("c_math_lib.dll")]
static extern int Sum(int a, int b);

int resultado, operando;
resultado = 0;

for (int i = 0; i < args.Length; i++)
{
int.TryParse(args[i], out operando);
resultado = Sum(resultado, operando);
}
Console.WriteLine("El resultado de la operación es " + resultado);
}
}[/csharp]

El atributo DllImport indica a Visual Studio que importe la librería en tiempo de compilación, de modo que reservará la memoria y permitirá usar la función Sum declarada como externa. El programa simplemente recuperará los valores que se pasen como argumentos en la ejecución del programa, irá sumándolos, y devolverá el resultado por pantalla.

suma1.PNG



Puede verse que es bastante simple hacer uso de código no manejado en .NET, aunque surgen otras dudas, como, por ejemplo, cómo cargar dinámicamente una DLL, en tiempo de ejecución o cómo conocer qué funciones pone a nuestra disposición. Esto lo veremos en sucesivos artículos.

viernes, 18 de abril de 2008

Publicando en el blog con Office 2007

Estoy escribiendo esta entrada desde Word 2007. No se trata de que esté escribiendo el artículo en sí, y luego use la herramienta de pegado desde Word que incorpora Wordpress, o que haga un "copy&paste"™ desde el mismo sino que, como curiosidad, quería explicar cómo podemos publicar directamente desde Word, escribiendo y pulsando en un botón que a tal efecto dispone el mismo. En cierto modo, se trata de una opción que ya proporciona software freeware como bloggar, que es el que suelo usar para publicar en los variopintos blogs por los que deambulo, pero puede resultar útil para aquellos que quieran amortizar el coste de la licencia que hayan pagado a Microsoft (¿porque lo habéis hecho, verdad?) por su copia legal de Office.


Bueno, vamos al grano. Publicar desde Word resulta tan sencillo como:

  1. Pulsar sobre el botón de inicio de Office (sí, el redondito de arriba a la izquierda), seleccionar la opción "Publicar" y, dentro de la misma, "Blog".



  2. Usaremos el asistente que se despliega para configurar los datos de acceso a nuestro blog. Su URL (incluyendo el "/xmlrpc.php", que no es más que el protocolo basado en RPC que permite la publicación remota, usando XML como sistema de codificación, y sobre HTTP para la comunicación). Daremos también los datos de login, para que Word pueda conectarse al blog.

  3. Vemos que Word muestra un nuevo grupo de opciones en un Ribbon especialmente preparado para la publicación en blogs.



  4. Realmente pueden gestionarse varios blogs, y podremos gestionarlos desde la opción "Gestionar cuentas":




  5. En cualquier caso, lo interesante es que podemos escribir en el blog, como estoy haciendo ahora con éste. Permite indicar el título, insertar imágenes (una de las opciones a configurar es dónde y cómo almacena el blog las mismas). También podemos abrir los post que ya tenemos publicados o como borrador para editarlos.



  6. Podremos escoger la categoría del post, abrir existentes para su edición…




  7. Podemos ir guardando versiones del documento en la opción "Publicar – Publicar como borrador". Cuando terminemos con la escritura, pulsaremos en el botón "Publicar" y… ¡listo! (Eso sí, monta un cirio con el HTML que genera. Después de publicar la entrada he tenido que entrar en Wordpress para "retocarla" un poco).

jueves, 17 de abril de 2008

Introducción a Scrum

Sebastian Chabal y Scrum


La solidez del equipo de rugby, con su líder alerta ante las presiones del entorno es una de las bazas de la metodología de desarrollo Scrum, tal y como refleja la imagen superior. Scrum proporciona un conjunto de reglas para proveer dicha protección y una mayor comunicación entre los miembros del equipo, y recibe precisamente su nombre del de la formación en que se disponen estos jugadores. Está inscrita dentro de las metodologías ágiles, entre ellas Extreme Programming (XP), y sus valores derivan del Manifiesto Ágil.


En cualquier caso, la intención de esta entrada es dar una breve introducción a Scrum, aunque que existen varias muy completas y accesibles que pueden encontrarse al pie del artículo, pero en este caso pretendo estudiarlo desde la perspectiva de la integración de Scrum con Test-Driven Development (TDD) y el Rational Unified Process (RUP).


La definición que para RUP tiene la Wikipedia es:




Un proceso de desarrollo de software y junto con el Lenguaje Unificado de Modelado UML, constituye la metodología estándar más utilizada para el análisis, implementación y documentación de sistemas orientados a objetos.


El RUP no es un sistema con pasos firmemente establecidos, sino un conjunto de metodologías adaptables al contexto y necesidades de cada organización.

Por otro lado, TDD ya es conocido por los lectores del blog, y se trata de una metodología de desarrollo que basa el mismo en la guía mediante pruebas unitarias del software. De este modo, tenemos un proceso de desarrollo, RUP, que consta de cuatro fases (Concepción, Elaboración, Construcción y Transición), unas directrices proporcionadas por Scrum, y una metodología que es la aportada por TDD. ¿Cómo encajar todo esto en una organización en la que está implantado RUP? Lo primero, como ya apuntaba en su día respecto a la implantación de TDD en la empresa, es comenzar por pequeños equipos que actúen como motor de transición para el resto de la organización. Además, a esto se suma que Scrum está especialmente indicado para equipos que consten de 7 a 15 miembros, aproximadamente. Comenzaremos, ya que introdujimos TDD en su día, a hacer lo propio con Scrum, para ir ampliando tanto uno como otro en sucesivas entradas.Ante todo, debemos tener claro que Scrum plantea ciclos de desarrollo de unos 30 días, y define unos roles muy específicos en todo el proceso. Comenzando por los roles, tendremos:

  • Cliente: en efecto, es quien piensas :).

  • Product Owner: muy cercano al cliente, o un miembro de la organización que conozca claramente el producto y los requerimientos asociados al mismo.

  • Scrum Master: similar al jefe de equipo, se encargará de definir tareas, y será el “paraguas” que cubrirá al equipo de desarrollo, evitando que se interfiera en el proceso de desarrollo.

  • Scrum Team: el equipo de desarrollo. A sus miembros se les suele denominar cerdos (pigs). Antes de que nadie se ofenda, diremos que en Scrum hay dos tipos de individuos: los cerdos, que se comprometen con el desarrollo, y las gallinas (chickens), que se involucran, tienen interés en el producto, pero no se implican. La mejor explicación que he encontrado para estos roles es la siguiente tira cómica:



060911-scrumtoon-spanish.jpg






En cuanto a las actividades definidas por Scrum, tenemos:

  • Product Backlog: donde el Product Owner define los requisitos, las nuevas funcionalidades y errores a subsanar.

  • Sprint Planning Meeting: El Product Owner se reúne con el Scrum Master y el Scrum Team. Definen DE FORMA REALISTA, last areas a realizar durante los próximos 30 días.

  • Sprint Backlog: Durante 30 días se desarrolla para conseguir alcanzar los objetivos, definidos en la Sprint Planning Meeting. Diariamente el Scrum Master se reunirá con el Scrum Team (Daily Scrum Meeting), para dar respuesta a tres cuestiones, para cada miembro del equipo:

    • ¿Qué he hecho desde la última reunión?

    • ¿Qué haré hasta la próxima?

    • ¿Existe algún problema que me impida cumplir con las tareas asignadas?






El Scrum Master deberá actuar como paraguas del equipo, evitando que se interfiera en el trabajo. Durante todo el Sprint Backlog no se redefinirán tareas, ni se incorporarán cambios. Al finalizar los 30 días, existirá un entregable. El Product Owner podrá hacer una presentación del mismo a los clientes o directivos de la empresa. Se llevará a cabo otra reunión, de forma retrospectiva, como evaluación del Sprint Backlog, para ver el grado de alcance de los objetivos fijados, y cuáles han sido los logros y problemas encontrados (lecciones aprendidas).

Se volverá a entregar un nuevo paquete de trabajo del Product Backlog, y se comenzará un nuevo ciclo de Sprint Backlog.





En los sucesivas entradas iremos viendo cómo integrar estos ciclos con TDD y, a mayor escala, con RUP en toda la empresa.

Para saber más:



Comprobando DNS

 


dns.gif


Cuando registramos un dominio, o cuando cambiamos de proveedor de hosting (o instalamos nuestra página o aplicación web en un servidor propio), el nombre de dominio asociado a dicha ubicación real (un servidor concreto de la infinidad de nodos que componen Internet) debe actualizar la dirección IP a la que apunta. Esto, gracias a los servidores de DNS (Domain Name System), permite que desde cualquier ubicación de la red pueda visitarse nuestra página, simplemente conociendo nuestra URL, de la que forma parte el nombre de dominio. Este proceso, aunque rápido y automático, requiere su tiempo. Los servidores de DNS van reiniciándose cada cierto tiempo (usualmente unas 24 horas), y conforme lo hacen van propagando los cambios en los dominios a los que apuntan, y actualizando sus tablas de correspondencia Nombre de Dominio – Dirección IP.


 


how_dns_works_f01.png


Hace unos días registré un nuevo dominio .es y, además, debí cambiar los DNS que tenía asignados. Para ver cómo se propagaba el cambio, y en qué estado estaba el dominio en diversos servidores DNS usé la página Squish, que permite realizar diversas consultas (estados de A, CNAME, SOA, NS…) sobre el dominio que le indiquemos. En mi caso, la propagación ha estado produciéndose durante más de dos días (unos DNS iniciales durante el registro, más el cambio que llevé a cabo en NIC posteriormente), terminando con pleno éxito, a menos que la página caiga en uno de los agujeros negros que pululan por Internet.

Privado: Scrum y TDD

http://weblogs.asp.net/russnem/archive/2007/01/17/shaking-things-up-scrum-agile-and-tdd.aspx

http://www.codeproject.com/KB/architecture/scrum.aspx

http://www-128.ibm.com/developerworks/rational/library/feb05/krebs/

miércoles, 16 de abril de 2008

El culebrón de OOXML. Capítulo 3.587

cristal.jpg


- ¿Qué lees, Javier Fernando?


- Las noticias de Barrapunto e Historias de Queso, María Felisa.


- ¿Y de qué hablan, pues?


- De Microsoft, OOXML y la ISO. Un apasionante tema.


- Ya imagino, Javier Fernando. ¿Pero, qué ocurre ahora con ellos?


- María Felisa, es largo y arduo de explicar. Pero podríamos resumirlo en pocas palabras diciendo que tienen al padrísimo de Redmond cogido por los machos.


- ¿Y lo permite?


- No le queda otra. La ISO, ante la reacción de la sociedad, no ha tenido más opción que recular. Tras unas turbias votaciones que habrían dejado a cualquier dictadura a la altura de la más limpia de las democracias, o recapacitan y le piden a los chicos de Redmon que usen el auto-resumen de Word con las especificaciones de su OOXML, o perderían (más aún) la credibilidad.


- ¿Pero por qué deberían resumir ese documento de especificaciones? ¿Tan largo es?


- Más de 6.000 páginas. Si fuese un best-seller, todavía podrían convertirlo en una "novela-río", María Felisa.


- ¡Ay padrito, que me da algo! ¿Pero qué han escrito ahí?


- Ni el padre Marcial Luis, acérrimo lector de la Biblia y otros textos sagrados podría saberlo, María Felisa. Pero eso no es todo. A los chicos de Guillermito las desgracias no les vienen solas. Allá en el Viejo Continente también han dejado de cantarles rancheras. La UE se plantea no renovar contratos de las Administraciones Públicas con Microsoft.


- Pues lo tienen crudo estos chicos, Javier Fernando.


- Ya te digo, María Felisa.

lunes, 14 de abril de 2008

El gusanito del amor se cuela en tu buzón de e-mail

Leí la noticia de la existencia de este ataque contra la seguridad de nuestros equipos hace un tiempo en el Blog de Hispasec. Ahora que recibo el correo, y como prevención ante una posible invasión de SPAM en los equipos de nuestros lectores, muestro a continuación una captura del mail recibido:

gusanito1.PNG


Puede observarse cómo, si nos posicionamos sobre uno de los enlaces, éste apunta no al dominio que nos está diciendo, "gusanito.com", sino a una página ubicada en un servicio de hosting gratuito. Esto ya de por sí pondría sobre aviso a cualquiera.


gusanito2.PNG


Sin embargo, el ataque que lleva a cabo es bastante más complejo, y atañe a la seguridad de una serie de routers. Para ver más información sobre el mismo, les recomendamos visitar el post que Hispasec dedicó al gusanito.

Privado: 4D Sports Boxing

Para saber más:

¡Quiero un Spectrum!

Publicidad Spectrum


for (i=0;i<100;i++) { printf("Los informáticos no somos friquis.\n"); }

domingo, 13 de abril de 2008

Google App Engine

google-app-engine.png


A nadie debería quedarle la menor duda: la guerra del software está más activa que nunca. A las amenazas de la OPA hostil de Microsoft a Yahoo! se le suman los continuos lanzamientos de todas las grandes compañías que están cayendo en un frenetismo inusitado. A los usuarios y a los profesionales de la informática no nos queda más remedio que actualizar nuestros conocimientos y las referencias que tenemos de "lo que se está cociendo", y no existe tregua para ello.


La penúltima noticia es el lanzamiento oficial de Google App Engine, actualmente en preview release, o versión previa, usada por 10.000 desarrolladores. Las características de esta beta del producto están limitadas al uso de 500MB de espacio, 10GB de ancho de banda diarios y 200.000 megaciclos de CPU, y el lenguaje inicial del producto es Python. En resumen, lo que Google nos ofrece con este App Engine es la posibilidad de desarrollar productos que se ejecuten en sus propios servidores, obviando el desarrollador tareas como la escalabilidad del producto, ya que éstas son mantenidas por el propio Google. Así, se podría comenzar con una aplicación a muy bajo coste, e ir requiriendo mayores servicios conforme fueran necesitándose. Aunque podría manifestarse una natural reticencia a hospedar nuestras webs en Google, lo cierto es que no es más que lo que ya hacemos cuando contratamos o montamos un servidor propio, eso sí, con tecnología Google tras de sí. Esto implica el uso de la BigTable, un sistema de almacenamiento distribuido y no relacional que ya usaba Google en productos internos, con su propio lenguaje de consultas similar a SQL (el GQL), y el GFS, un sistema de ficheros también propio de Google.


Aunque el cupo de desarrolladores está cubierto desde hace tiempo, lo cierto es que si queremos investigar un poco más sobre las posibilidades de Google App Engine deberemos limitarnos, por ahora, a inscribirnos en la lista de espera que Google ha creado a tal efecto. Entretanto, es posible descargar el SDK para ir desarrollando "en local", así como consultar la documentación disponible en las páginas de Google. A continuación enlazamos un video en que, en apenas 10 minutos, podemos ver una introducción al uso de este nuevo producto:


[youtube]http://www.youtube.com/watch?v=bfgO-LXGpTM[/youtube]

sábado, 12 de abril de 2008

Software libre en la Administración Pública

Correa y Stallman


A tenor de los que comentaba días atrás respecto de la conferencia en Málaga de Richard Stallman a la que pude asistir, y tras la que me reiteraba en la opinión de que la Administración Pública debería apostar por el software libre siempre que fuese posible, ya que es más seguro, generalmente más barato y, en cualquier caso, fomenta el desarrollo local del tejido empresarial, aparece como noticia que el Gobierno de Ecuador establece mediante decreto el uso de software libre en sus sistemas y equipamientos informáticos. Los detalles figuran en el Decreto nº 1014, de 10 de abril, y recoge las cuatro libertades que debe cumplir el software, según la filosofía de la GNU, a saber:



Los programas de computación incluyen las siguientes libertades; utilización del programa con cualquier propósito de uso común; distribución de copias sin restricción alguna; estudio y modificación del programa (requisito: código fuente disponible); y publicación del programa mejorado (requisito; código fuente disponible).

Además, deja claro que la decisión o ha sido tomada a la ligera, y que no cierran las puertas al software propietario (y privativo), pero que



[...] faculta la utilización de software propietario (no Libre), únicamente cuando no exista una solución de Software Libre que supla las necesidades requeridas, o cuando esté en riesgo la seguridad nacional, o cuando el proyecto informático se encuentre en un punto de no retorno.

En relación a lo que argumentaba respecto a cómo el software libre beneficia al pequeño empresario local frente a las grandes corporaciones multinacionales de software, el decreto cita de forma tácita lo siguiente:



El artículo 5 del Decreto, precisa que tanto para Software Libre como para software propietario, siempre y cuando satisfagan los requerimientos, se debe preferir 6 soluciones: nacionales que permitan autonomía y soberanía tecnológica; regionales con componente nacional; regionales con proveedores nacionales; internacionales con componente nacional; internacionales con proveedores nacionales; e internacionales.

ecuadorsl.png


Desde Lobosoft nos congratulamos de dicha decisión, y esperamos que contribuya al crecimiento tecnológico del país sin merma en su economía, seguridad y, sobre todo, en las libertades de sus ciudadanos.

PowerCommands para Visual Studio 2008

PowerCommands for Visual Studio 2008


Hace un tiempo comentaba en el blog el lanzamiento por parte de Microsoft de su Visual Studio Gallery, una especie de repositorio complementario a CodePlex especialmente dedicado a proporcionar herramientas y add-ins para el IDE de la compañía. Plugins de pago y gratuitos que se ofrecían de forma complementaria al propio Visual Studio con la idea de hacer el trabajo del desarrollador más cómodo.


El equipo de desarrollo de Visual Studio 2008 ha lanzado PowerCommands, una serie de utilidades añadidas al propio entorno que nos brindan comodidades como las siguientes:




  • Copiado y pegado de clases: se puede llevar una clase al portapapeles y pegarla en otro fichero o proyecto.

  • Copiado y pegado de referencias: permite copiar las referencias de un proyecto a otro.

  • Copiar el proyecto como una referencia: para llevarlo a otro proyecto donde será usado.

  • Editar el fichero de proyecto: En ocasiones debíamos editar por algún motivo el fichero de proyecto que gestionaba automáticamente Visual Studio. En mi caso solía usar para ello la herramienta libre PSPad, pero sin duda la integración en el propio IDE es una práctica idea.

  • Abrir la carpeta contenedora: Sobre cualquier fichero del proyecto, podemos usar esta opción para abrir la carpeta donde está ubicado físicamente. Esto nos ahorra mucho trabajo, en particular cuando los archivos se distribuyen en distintas ubicaciones, y el acceso a la estructura de directorios es algo compleja.


Pero no son las únicas opciones que nos ofrece. Para descubrir esta práctica herramienta, podemos descargarla desde su ubicación en Visual Studio Gallery: PowerCommands for Visual Studio 2008.

.NET Portable Framework

DotGNU Logo


Hablaba anteriormente sobre las aplicaciones portátiles y su utilidad cuando no disponemos de ordenador portátil o, simplemente, deseamos llevarlas en nuestra memoria USB para trabajar con ellas en cualquier momento, siempre que dispongamos de un ordenador donde ejecutarlas. Llevaba algún tiempo pensando escribir sobre ellas cuando se me ocurrió qué ocurriría con nuevas aplicaciones desarrolladas en .NET que deseáramos ejecutar en ordenadores sin el Framework instalado. Obviamente no funcionarían pero, ¿y si necesitamos ejecutar una de nuestras aplicaciones en un ordenador de alguien que no pudiese o quisiese instalar el .NET Framework? Ya que tenemos el Framework .NET "normal", el .NET Compact Framework, el .NET Micro Framework... ¿existiría, por así llamarlo, un .NET Portable Framework? La respuesta es que no. No existe uno, sino que tenemos dos a nuestra disposición. Parece que en esta vida esté todo inventado ya ;) .


Por un lado, está el Intermediate Language Distributed Just In Time (ILDJIT), un compilador para bytecode CIL, desarrollado por el Politécnico de Milan y disponible bajo licencia GPL, y que puede ser descargado desde su página web.


Por otro, tenemos el proyecto DotGNU Portable, que permite ejecutar aplicaciones desarrolladas para el .NET Framework 2.0 con apenas modificaciones sobre el código. Sin duda, iniciativas como el proyecto Mono o DotGNU Portable, auspiciadas por la comunidad de desarrolladores de software libre, dan un empuje envidiable al crecimiento tecnológico incluso con entornos inicialmente de software privativo, como es el del framework de Microsoft.


Para saber más:

Aplicaciones portátiles

portableapps.png


En nuestros días la necesidad de desplazarnos y aun así mantener nuestro entorno de trabajo cercano es cada vez más apremiante. Al margen de si estamos de acuerdo o no en la estresante vida que llevamos, lo cierto es que la tecnología nos facilita la tarea. Ordenadores portátiles, asistentes digitales (PDA’s, vamos), Internet y dispositivos de almacenamiento cada vez más pequeños contribuyen a ello. Los que me conocen saben que mantengo una relación de amor-odio con los portátiles, y también que prefiero trabajar, a ser posible, con un ordenador de sobremesa. Así, uno de los gadgets que más uso es un pendrive en el que llevo instaladas las aplicaciones que más uso. Esto es posible, en la era Windows, gracias a las aplicaciones portátiles (o “portables”, como se les da en llamar por una mala traducción al castellano). Resulta curioso cómo con estas aplicaciones se ha vuelto al pasado, en el sentido de poder llevarlas en una memoria externa (antaño en disquetes, hoy día en discos duros externos o memorias USB, principalmente), y ejecutarlas en cualquier lugar sin necesidad de instalarlas en el ordenador donde van a ser usadas. Además, con mi flamante adquisición de un pendrive de 4GB, puedo dejar mi vetusto Bit4flash de 128MB como unidad de arranque del pequeño pero útil DSL (Damn Small Linux, una de las distribuciones de GNU/Linux que uso, junto a Vector Linux en un equipo antiguo, y Ubuntu, en el portátil).


En el USB de 4GB he instalado estos días varias aplicaciones portátiles. En primer lugar, una de las que más me gusta, la suite de PortableApps, una aplicación que gestiona a otras simulado el menú de Inicio de Windows, pero en el lado derecho de la pantalla. Así, es posible acceder a documentos y programas de una forma sencilla y rápida. Además de OpenOffice Portable, Firefox y Thunderbird Portables, he instalado bastantes aplicaciones de entre las que tenemos disponibles en la web del producto. Una de las más prácticas para mí es XAMPP, un gestor para servidores Apache (con PHP) y MySQL que permite tener un servidor web, para desarrollo, pruebas y despliegue ante un hipotético cliente en cualquier lugar y situación. Además, como buen pendrive de un freak de la seguridad y los sistemas, mantengo versiones portátiles de Wireshark (la versión actual del conocido sniffer o, si somos políticamente correctos, analizador de protocolos de red Ethereal) y otras aplicaciones de monitoreo de red y encriptación.


Dejo algunos enlaces para la descarga de este tipo de aplicaciones (en particular, es muy interesante PortableFreeware, repleto de aplicaciones gratis y, muchas de ellas, open source), así como a una aplicación que permite, a partir de un ejecutable “normal”, generar el correspondiente a la aplicación portátil que deseemos. Entre otras aplicaciones que pueden convertirse se encuentran algunas tan interesantes como Adobe Photoshop u Office 2007.


Para saber más:



Lenguajes Específicos de Dominio en Visual Studio

"Lenguaje personalizado que se centra en un dominio problemático y define el problema en un nivel alto de abstracción", es la descripción que proporciona Microsoft en su glosario de Visual Studio Team System para los DSL, o Lenguajes Específicos de Dominio, a los que da soporte, entre otros, mediante el Visual Studio SDK, en el que centraremos la entrada de hoy.


Los lenguajes específicos de dominio han venido utilizándose desde los albores de la informática. Como su propia definición indica, estos lenguajes enfocan el problema desde alto nivel, abstrayendo al programador de los detalles de la implementación. Imaginemos que deseamos realizar una consulta sobre una base de datos, o un fichero XML. Con un lenguaje de propósito general generalmente utilizaríamos alguna API o capa de acceso a datos que nos abstrajese de los detalles. Los lenguajes de dominio específico "son" la propia abstracción en sí, y permiten solicitar qué queremos, sin necesidad de hacer lo propio con el cómo lo queremos obtener. Así, los DSLs son lenguajes declarativos, y tenemos ejemplos de ellos en el SQL, XQuery o el propio LINQ.


Como avanzaba al comienzo, Visual Studio 2008 SDK (existen también versiones previas del producto para ediciones más antiguas de VS) proporciona diversas herramientas que posibilitan la extensibilidad del IDE (no en vano se encuentra dentro de la gama de productos Visual Studio Extensibility), dotándole de capacidades específicas para la resolución de problemas como el que nos ocupa. Al SDK se le complementaría, por ejemplo, con Visual Studio 2008 Shell, que ya introdujimos hace un tiempo, y en el que profundizaremos dentro de no mucho tiempo.


dsl-sdk.PNG


Si descargamos el SDK (actualmente en su versión 1.0) de la página de Microsoft y procedemos a instalarlo, veremos que nos proporciona una serie de recursos para trabajar con DSLs, WCF, creación de Add-ins y extensiones específicas para el tratamiento de datos. Nos centraremos hoy en el primero de ellos, viendo además la interesante posibilidad de producir DSL "gráficos" mediante los cuales podamos proporcionar a los usuarios elementos de programación rudimentarios pero a la vez potentes. Por ejemplo, podríamos crear un DSL que constase de componentes mecánicos e interconexiones para fabricar maquinaria pesada, y que el propio Visual Studio verificase en la "compilación" del lenguaje que se cumplen todas las restricciones necesarias para que el programa diseñado (un camión, por ejemplo) sea correcto. La salida de la compilación podría ser desde especificaciones en XML, a un ejecutable con determinada funcionalidad. El abanico que se abre ante nosotros es amplio y apasionante, como veremos.


Hoy simplemente nos centraremos en uno de los ejemplos que proporciona el SDK, y en una próxima entrada veremos cómo generar uno propio. Abrimos el ejemplo del árbol genealógico (Family Tree DSL), diseñado específicamente para mostrarnos cómo funcionan los validadores, sirviéndonos además de introducción a los lenguajes de diseño gráficos que generan, como decíamos, código para los componentes o "artefactos" que dibujemos.


DSL Tree Family Sample - Visual Studio 2008 SDK


Una vez cargado el proyecto, procedemos a ejecutarlo y... voilà, tenemos otro Visual Studio como resultado de la ejecución. Pero no es el mismo Visual Studio, sino uno preparado para dar soporte al DSL creado en el ejemplo. Veremos que disponemos de artefactos persona, que podemos arrastrar al diseñador, e interconexiones de parentesco (enlaces matrimoniales y relaciones padre-hijo), así como diversos atributos, como el año de nacimiento y de defunción de las personas.


DSL Tree Family Sample - Visual Studio 2008 SDK


Si probamos a ejecutar el proyecto, obtendremos un error de validación que nos indica que un hijo no puede nacer después de la fecha de nacimiento del padre.


DSL Tree Family Sample - Visual Studio 2008 SDK


Tampoco podrá hacerlo, si probamos a cambiarlo, antes del nacimiento de éste. Por último, si corregimos las fechas y volvemos a ejecutar, el proyecto "compilará" correctamente, produciendo en su caso una salida adecuada.


DSL Tree Family Sample - Visual Studio 2008 SDK


Otro de los ejemplos que proporciona Visual Studio 2008 SDK es un diseñador de diagramas de clases en UML bastante curioso, por cierto. En una próxima entrada veremos cómo diseñar nuestro propio DSL, incluyendo validadores y una salida a la compilación de los proyectos.

viernes, 11 de abril de 2008

Libros para geeks

Me gustan las listas. No hablo de listas genéricas, ni de las que heredan de System.Collections, ni tan siquiera de una estructura de datos en su vertiente más teórica, sino de listas en general. De la compra, de tareas pendientes, o de libros por leer, por ejemplo. Crear las listas, organizarlas, reestructurarlas, tachar elementos de las mismas y agregar nuevos. Leo en Microsiervos, que a su vez lo hacen de Geeks Are Sexy, una lista de diez libros que todo Geek debe leer. Ahora que me encuentro leyendo la hilarante novela jPOD de Douglas Coupland (aunque no lo sea tanto como El asombroso viaje de Pomponio Flato), no podía dejar pasar la oportunidad de hacer referencia a la noticia. Además de los libros reseñados en la lista (que, para los que no dominen el BASIC, se encuentra traducida en el espacio de Wihe), yo agregaría algún otro de mi cosecha para este fin de semana lluvioso e hijo de Eolo que se nos viene encima:


Libros gratis, disponibles en Internet:





  • The Hacker Crackdown, de Bruce Sterling: Un clásico de la filosofía hacker, traducido al español por Kriptópolis y también disponible en la red. He decidido actuar como mirror de ambas ediciones por si en un futuro no estuvieran disponibles, por lo que también pueden obtenerse en la sección de descargas.




  • The Art of Computer Game Design, de Chris Crawford: Más clásicos, en esta ocasión para los adictos a los videojuegos como lo es el equipo de Malvicio. Se trata de un libro escrito en 1982 por Chris Crawford, autor de los míticos Wizard, Excalibur o Patton vs Rommel.




  • Lista de interrupciones de Ralf Brown: no es un libro, pero es un clásico. ¿Quién no ha programado en ensamblador al menos un “Hola mundo”? Para aquellos que añoren la INT 21H (la interrupción de llamadas a funciones de DOS), el sitio de Ralf Brown es un lugar de peregrinación.




  • Libro Electrónico de la Seguridad Informática y Criptografía, de Jorge Ramió: Si además de geek te consideras perseguido por todo el mundo, si la humanidad entera conspira contra ti, éste es tu libro. Un clásico de la seguridad informática, gratuito y disponible desde hace años en la red, resulta una introducción amena al mundo de la seguridad y la apasionante criptografía.




Los que no son gratis, pero sí recomendados:





  • The ZX Spectrum Book – 1982 to 199x, de Andrew Rollings: Un libro que, desde que lo vi, quise tener. Se trata de un recorrido visual a lo largo de la historia del Spectrum y sus juegos. La edición impresa tiene un curioso formato que simula al “gomas”, y parece tener muy buena calidad. Desgraciadamente, sólo pude tener acceso a la versión electrónica del mismo, y pierde mucho en encanto. En cualquier se trata de un “must” para los que añoramos al pequeño 8 bits.




  • Microsiervos, de Douglas Coupland: Hoy día descatalogado e imposible de conseguir en las librerías, es un clásico de la literatura geek. En esta novela, el autor de Generación X describe las peripecias de un grupo de trabajadores de cierta compañía, gigante del software, ubicada en Redmond. Con jPOD, que actualmente estoy leyendo, actualiza Microsiervos a la era de Google.




Y de momento, poco más. Existen muchos más libros disponibles, pero me gustaría que recomendaseis alguno. ¿Qué libro geek falta en esta lista creciente?


P.S.: Tengo la sensación de que este post ha venido con la intención de quedarse durante un tiempo, e ir actualizándose. De modo que veremos a dónde nos lleva esta pequeña andadura.

jueves, 10 de abril de 2008

¿Qué es y cómo usar GoogleLookup?

Entre las funciones disponibles en las hojas de cálculo de Google Docs se encuentra GoogleLookup, que podríamos denominar como un "buscador embebido" en la hoja de cálculo. La sintaxis de la función es similar a la de cualquier otra que podamos usar: signo igual, nombre de la función y parámetros, en concreto, el nombre de la entidad sobre la que deseamos realizar la búsqueda y el atributo por el que deseamos buscar. Nuestra llamada a la función quedaría así:


=GoogleLookup("entidad"; "atributo")


Y su uso, en algún ejemplo, de este modo:


=GoogleLookup("granada"; "alcalde")


GoogleLookup


Desgraciadamente, la mayor parte de las consultas que obtienen resultados aceptables son en inglés. En cualquier caso, GoogleLookup sigue una lógica aplastante respecto a las entidades y sus atributos asociados. Así, si la entidad es una persona, podremos consultar su edad, o lugar de nacimiento, pero si además es un deportista, uno de los atributos posibles sería alguna marca personal, o el número de goles de la temporada actual, en caso de ser un futbolista. La propia documentación de Google Docs nos habla de la función, y de los posibles valores que pueden tomar las entidades y atributos:




  • Países y territorios (como "Burkina Faso"): población, capital, ciudad más grande, PIB

  • Estados de EE.UU. (como "Tennessee"): superficie, gobernador, alias, flor

  • Ríos (como "río Amazonas"): origen, longitud

  • Ciudades y municipios (como "Chicago"): estado, alcalde, elevación

  • Músicos (como "John Lennon"): fecha de nacimiento, lugar de nacimiento, nacionalidad

  • Elementos químicos (como "Helio"): número atómico, descubridor, masa atómica

  • Compuestos químicos (como "Alcohol isopropílico"): formulación química, punto de fusión, punto de ebullición, densidad

  • Estrellas (como "Betelgeuse"): constelación, distancia, masa, temperatura

  • Planetas (como "Saturno"): número de lunas, duración del día, distancia al sol, atmósfera

  • Empresas (como "Hewlett-Packard"): empleados, consejero delegado, ticker

  • Etc.


Y ya por último, como informáticos que somos, podríamos preguntarnos qué se esconde tras esta función. Si introducimos la función GoogleLookup en una celda, y posicionamos el ratón sobre la misma, Google Docs mostrará un tooltip con la acción que está realizando, que no es otra que una llamada a un script en Python que realiza la consulta por nosotros.


pythonengoogledocs.PNG


Así, no parece extrañarnos que Python sea uno de los lenguajes (minoritarios pero vitales) que usa Google en sus proyectos.

Los trucos de Google Docs

Una de las facetas más conocidas de Google respecto a sus empleados es permitirles usar un pequeño porcentaje de su tiempo en el trabajo para que lo utilicen como deseen, en proyectos innovadores e imaginativos. Precisamente de esos pequeños lapsos de tiempo provienen algunas de las herramientas más usadas de Google, elementos que se nos podrían antojar absolutamente prescindibles... hasta que decidimos probarlos.


Estos días he estado investigando un poco en torno a Google Docs y las posibilidades que ofrece. Es una de las herramientas que más he usado, junto al correo y al propio buscador, y resulta realmente práctico poder editar documentos en cualquier lugar, contando únicamente con el navegador. Es una buena alternativa cuando queremos prescindir de enviar los documentos por e-mail, o transportarlos en una memoria USB, y permiten además el trabajo colaborativo real, por lo que es posible la edición simultánea de los mismos por varios miembros de un equipo, además de realizar un versionado automático durante la edición, lo que permite que podamos volver atrás ante algún error o, simplemente, hacer un seguimiento de la evolución del documento. Obvia decir que hablo de documentos sin implicaciones de seguridad, y que puedan ser accedidos libremente, ya que resultaría bastante comprometedor guardar en una ubicación como ésta, con acceso a Internet y en un sistema cerrado cuyo funcionamiento interno se desconoce, cualquier tipo de información confidencial.


En cualquier caso, mis averiguaciones iban más en el sentido de poder usar, además del propio editor de documentos que incorpora Google Docs, algún otro, como Microsoft Office u OpenOffice, sincronizando la edición con el servidor de Google. Sin embargo, jugueteando con las hojas de cálculo de Google Docs, he encontrado un par de curiosas características que no conocía, y que Google tiene documentada. Se trata del relleno automático de rango, y de funciones como GoogleLookup.


Hoy veremos la primera de ellas, muy similar a la opción que ofrece Microsoft Excel. Se trata de rellenar dos o más celdas para que, al marcarlas y copiarlas mediante la pulsación y arrastre del pequeño marcador que aparece en la parte inferior derecha de la selección. Por ejemplo, si ponemos en la celda A1 el valor 10, y en la celda A2 el valor 20, marcamos esas dos celdas y arrastramos la selección, los valores de las celdas consecutivas serán: A3=30, A4=40, A5=50, etc. Hasta aquí, nada extraño, y funcionan de igual modo ambas hojas de cálculo. La sorpresa viene cuando en Google Docs insertamos en una hoja de cálculo varios valores como, por ejemplo, un par de nombres de ciudades o países, o la marca de dos o tres coches. Al marcar y arrastrar (en Google Docs, manteniendo pulsada la tecla Control mientras lo hacemos) se reproducen en las siguientes celdas otros valores similares, según los que hayamos introducido previamente. El resultado puede observarse en la siguiente figura:


gdocs-spreadsheet.PNG


¿Qué otras combinaciones curiosas que establezca Google puedes encontrar?

miércoles, 9 de abril de 2008

Agujeros negros en Internet

telescopio_espacial_hubble.jpg


Que Internet es un inmenso cúmulo de información es un hecho que nadie puede negar. El acceso a los servicios de Internet es posible gracias a la existencia de diversos protocolos que permiten a las aplicaciones cliente (navegadores, programas de correo, lectores de noticias...) el acceso a los recursos que se encuentran en una máquina servidor, en cualquier lugar del mundo, siempre que ambos, cliente y servidor, se encuentren conectados a Internet, obviamente. En ocasiones, podemos encontrarnos navegando, por ejemplo, para buscar cierta información, y al intentar acceder a una determinada dirección web obtener por único resultado un mensaje de error indicando que el servidor está caído o no disponible en ese momento. Algunas veces el problema se soluciona al poco tiempo, pues se trata de alguna operación de mantenimiento que estaban llevando a cabo en el mismo, lo que explica la falta de disponibilidad del mismo en ese momento. Sin embargo, esto no siempre es así. Internet tiene su propio Maelstrom o, como han dado en llamarlo sus descubridores, Internet tiene agujeros negros.


El proyecto Hubble (Hubble: Monitoring Internet Reachability in Real-Time), desarrollado por la Universidad de Washington, es el equivalente en Internet del conocido telescopio espacial, gracias al cual podemos visualizar (o, más bien, inducir) la existencia de agujeros negros en el Universo. En el caso de Internet, el proyecto Hubble ha desatado la controversia sobre "agujeros negros" en los que la información, simplemente, desaparece. Es decir, aun existiendo una ruta física entre dos equipos conectados a Internet, puede darse el caso de que, llegada a un punto, esa información simplemente desaparezca. Aunque no esperaba obtener resultados tan espectaculares, Ethan Katz-Bassett desarrolló un sistema informático que lanza mensajes a ordenadores conectados a Internet, esperando respuesta. En ocasiones dichos paquetes desaparecen por motivos normales: deterioro de los paquetes, extravío, rutas no alcanzables, etc. Sin embargo, hay ubicaciones que, en momentos determinados, pierden la información y, aun existiendo servidores DNS distintos y rutas alternativas para alcanzar el destino, este permanece inaccesible.


Según los estudios de Hubble, bastante recientes por otro lado, ya que el proyecto inició su andadura el 17 de septiembre de 2007, han detectado más de 880.000 agujeros negros con las características señaladas anteriormente, y con una actividad de duración variable.



hubble.PNG


Particularmente, creo haber sufrido en una ocasión, hace apenas un par de meses, un caso similar. Sitios web a los que no podía acceder y, sin embargo, un amigo sí, en el mismo momento y desde dos ubicaciones distintas. Pasadas unas horas, en las que seguía teniendo acceso al resto de sitios web a los que intenté entrar, se restableció la comunicación sin más. En su momento me pareció una pecular pertubación que ahora, al conocer la existencia de estos agujeros negros, puede quedar satisfactoriamente explicada.


Además de lo curioso y anecdótico del hecho, lo cierto es que la herramienta Hubble nos puede dar idea del porcentaje de acceso existente para una determinada ubicación en Internet.

Google Docs y Microsoft Office 2007

Google proporciona, mediante sus proyectos de código (Google Code), todo tipo de herramientas, algunas de las cuales nos permiten interactuar con sus productos, como puede ser el correo, documentos o calendario. Entre ellas, se encuentra la .NET Library for the Google Data API, dentro de .NET Client Library. Mediante el uso de esta biblioteca de clases podemos desarrollar aplicaciones .NET que puedan acceder a los recursos de Google. Sin embargo, se trata de una biblioteca programada inicialmente sobre el .NET Framework 1.1, ya obsoleto, aunque es posible obtener el código y recompilarlo para el Framework 2.0, por lo que sería posible usarlo con Visual Studio 2005 y 2008.


En cualquier caso, hoy quería mostrar cómo interactuar de una forma sencilla y unilateral con Google Docs a través del correo electrónico. Google Docs, la aplicación web para la gestión de documentos (hojas de cálculo, documentos de texto y presentaciones), permite la edición en línea de los documentos, así como la conversión entre distintos formatos (tanto exportación como importación). Así, a la hora de incluir un nuevo documento, podemos crearlo directamente on-line, o subir uno que ya tengamos creado con aplicaciones del tipo de OpenOffice Writer o Microsoft Word. Sin embargo, existe una posibilidad interesante y poco usada que consiste en enviar el documento por correo electrónico, bien como documento adjunto al mismo, bien dentro del propio cuerpo del mensaje. La dirección a la que debemos enviarlo nos la proporciona el propio Google Docs en su opción Upload, y suele ser del tipo "Nombre+Del+Usuario-listadenumeros @prod.writely.com". Aunque no es la forma más elegante ni eficiente para disfrutar de las posibilidades de Google Docs, nos va a servir para unir dos proyectos presentados en Lobosoft y conseguir un sencillo método para hacer una copia de seguridad de un documento de Microsoft Word 2007 en Google Docs. Microsoft y Google juntos, ¿da miedo, verdad?


El proceso no puede ser más sencillo. Creamos un nuevo proyecto de Visual Studio 2008 del tipo Office 2007-Word 2007 Add-in. Añadimos al proyecto un nuevo Ribbon, mediante el mismo proceso que seguimos en su día en la entrada de aproximación a Visual Studio Tools for Office (VSTO v3). A continuación, añadimos la funcionalidad de envío de correo que creamos en el post sobre el envío de correos mediante Gmail y C#. Lo ideal sería, cuando tuviésemos la funcionalidad de envío y recepción de correo completa, crear un nuevo componente que pudiésemos reutilizar en nuestros proyectos, pero por la sencillez del ejemplo, simplemente traemos la clase Lobosoft.Outgleek.Mail al proyecto, y nos disponemos a usarla.


pestania.PNG


Y lo novedoso viene ahora. Simplemente debemos añadir un botón al RibbonGroup que ejecute el envío del correo. En el ejemplo, además, he incluido un pequeño TextBox donde insertar la dirección de correo a la que deseamos enviar el documento (y que será, presumiblemente, la que nos proporcionó Google Docs). En un proyecto mayor, esto podría ser configurable desde algún punto de la aplicación, al igual que los parámetros de la cuenta de correo de Gmail, y el propio servidor de correo, que usaremos para llevar a cabo el envío.


opciones.PNG


El código asociado al botón Save to Docs será el siguiente:

[csharp]
private void SaveToDocs_Click(object sender, RibbonControlEventArgs e)
{
Mail newMail = new Mail();
newMail.SendMail(editBox1.Text, DocumentManagement.DocumentName, DocumentManagement.GetText());
}
[/csharp]

Y llevará a cabo un par de acciones: recuperar el nombre del documento, a través de la clase DocumentManagement, que habremos creado a tal efecto, y el texto del documento en un formato apropiado. La recuperación del texto del documento tiene su miga, ya que (al menos hasta donde llegan mis conocimientos actuales de la jerarquía del objeto Document de Interop.Word.Document, no es trivial recuperar todo el texto y el formato del documento. Para hacerlo hemos recurrido a un pequeño truco. Usar el método Select() de la clase Document para seleccionar todo el documento para, posteriormente, copiarlo al portapapeles mediante el método Copy() de Interop.Word.Selection. A partir de aquí, volvemos a pedir al portapapeles (Clipboard) el texto del documento, indicándome mediante el parámetro format, del tipo TextDataFormat, el formato en que deseamos que nos lo devuelva, en este caso HTML.



[csharp]
public static string GetText()
{
try
{
Word.Document myDocument = Globals.ThisAddIn.Application.ActiveDocument;
myDocument.Select();
Globals.ThisAddIn.Application.Selection.Copy();
return Clipboard.GetText(TextDataFormat.Html);
}
catch (Exception ex)
{
throw ex;
}
}
[/csharp]

El documento que vamos a almacenar en Google Docs es el siguiente:


documento.PNG


Hecho esto, procedemos a enviar el correo a Google Docs, con el nombre del documento por Asunto, ya que este campo le indicará el nombre que debe dar al documento remoto, y el HTML del documento en el cuerpo del mensaje.


Accedemos a Google Docs para ver que, en efecto, un nuevo documento ha sido creado.


engoogledocs.PNG


Sin embargo, los resultados están a la vista, y la conversión a HTML que lleva a cabo el método GetText() del Clipboard no es del todo compatible con Google Docs.


eldocumentofinal.PNG


Por tanto, aunque resulta un método extremadamente simple para realizar un backup de nuestros documentos en Google Docs, no es todo lo adecuado que debería. No nos quedará más remedio, pues, que volver a compilar y adaptar el código de la .NET Client Library a los Frameworks 2.0 ó 3.5 de .NET.