IDisposable Thoughts

Una de las preguntas que suelo escuchar varias veces cuando converso con varios grupos de desarrollos a los cuales se integra el DBA es la siguiente: “¿Y cómo hago para controlar los cambios o agregar los cambios de la base de datos en el sistema de control de versiones”? Bueno, en cierta manera lo comprendo, llego a tal punto de decir que si no esta en el repositorio de versiones entonces no ha sido hecho.

Red Gate me sorprende con una nueva herramienta que nos puede ayudar a controlar este pequeño problema, Red Gate SQL Source Control, un sistema de control de versiones que permite versionar una base de datos SQL Server y agregar su esquema a un repositorio de Subversion junto con el código fuente. Al principio me parecía algo extraño y hasta bizarro, pero luego de usarlo un tiempo hasta me terminó gustando

El Red Gate SQL Source Control se integra al SQL Server Management Studio (creo que soporta la versión express, pero no estoy para nada seguro). El versionar la base de datos es sumamente fácil, la seleccionamos, “linkeamos” la base de datos a un directorio de un repositorio ya existente (aunque permite crear un repositorio nuevo para la base de datos) y escogemos luego que objetos agregar al repositorio

La versión actual de Red Gate SQL Source Control se encuentra en Early Access y puede ser bajado al instante con sólo registrarse en la página.

Hay ciertos criterios que debemos tomar en cuenta:

• No es posible hacer revert a un cambio ya existente (o por lo menos no he encontrado dónde hacerlo) NOTA: la versión 2.1 agregará soporte para Revert
• En la versión EA actual solo hay soporte para Subversion, el próximo EA soportará TFS (no Git, no Vault, no Hg por el momento)
• El equipo de Red Gate esta buscando feedback para mejorar la herramienta, algo sumamente positivo a mi parecer.

Resumiendo, RedGate SQL Source Control es un gran paso hacia la integración del control de versiones de nuestra base de datos a nuestro repositorio de código, un paso positivo. Le doy 9 estrellas de 10

Pueden suscribirse al programa de Early Access y bajar el instalador del siguiente link http://www.red-gate.com/products/SQL_Source_Control/index.htm

Saludos!

Subversion es un excelente sistema de control de versiones centralizado (VCS) de código abierto ampliamente utilizado alrededor del mundo no sólo por los desarrolladores sino también por diversas personas que lo usan para mantener un control de cambios en sus documentos varios.

Es común para un usuario de Subversion utilizar el famoso cliente TortoiseSVN para manejar sus directorios de trabajo actuales conectados a un repositorio de Subversion. Como algunos se habran percatado, Subversion crea directorios “ocultos” .svn donde contiene la metadata necesara para trabajar de forma desconectada al repositorio, a veces estos directorios pueden llegar a ser un poco “irritantes” y necesitamos deshacernos de ellos. Recientemente un amigo me llamó con el siguiente problema:

Tengo un problema, el repositorio original no existe, por lo tanto no puedo hacer el “export” de TortoiseSVN de mi repositorio para deshacerme de los directorios .svn, necesito enviarle el código fuente a un cliente pero no quiero enviarle los .svn, ¿cómo hago para deshacerme de ellos? la estructura de directorios es muy compleja por lo que navegar uno a uno y quitarlos es un poco tedioso.

Es ahí cuando sale a la luz nuestro viejo amigo la línea de comando, no es nada que un simple script de Cmd o PowerShell en Windows no pueda resolver. Comencemos con el viejo y ya casi obsoleto Cmd:

for /r %%f in (.svn) do rd /s /q "%%f"

En PowerShell es un poco más complejo, pero igual se puede lograr

get-childitem -Include .svn -Recurse -force | Remove-Item -Force –Recurse

Obviamente, cualquiera de los dos comandos deben correrse en el directorio que queremos limpiar.

Saludos!

UPDATE: mi amigo jfroma me sugiere el uso de SVN Export para lograr lo mismo, bueno, recordemos que SVN Export es una operación conectada de Subversion, eso indica que debemos tener conexión al repositorio para efectuarla. Como expongo en mi caso, mi amigo no tiene acceso al repositorio original (para ser exacto según me contó fue borrado), he ahí porqué no podemos usar Export y debemos recurrir a otras “técnicas” tibetanas para lograrlo.

En los últimos meses he estado ya más que aburrido en Microsoft Workflow Foundation, una relativamente impresionante framework de creación de flujos de trabajo de forma declarativa (o por lo menos así lo mencionan teóricamente, luego conversamos más de esto). Hoy mi cliente me menciona que uno de sus workflows no funciona, si, así de descriptivo…

Revisando el tracelog del proceso me doy cuenta que simplemente se debe a que dentro del Workflow existe una InvokeWebService Activity, yep, esta es una actividad de Workflow Foundation 3.0 diseñada para consumir viejos servicios ASMX.

Como recordaremos nuestro viejo ASMX no soporta configurar cosas como credenciales desde el archivo de configuración (como lo soporta WCF obviamente) y esto puede hacerse fácilmente desde código, el problema es que a “simple vista” nuestra InvokeWebService Activity no presenta una forma de cambiar las credenciales, es cuando un poco de lectura en MSDN nos ayuda enormemente

Bien, si bien no podemos “settear” las credenciales de un webservice directamente en el designer, lo podemos hacer en “código” antes que el servicio sea invocado, eso lo logramos con un handler al evento Invoking

Lo demás es simple manejo de credenciales en ASMX webservices.

// C# Code: Dentro del codebehind del workflow
protected void InvokeWebService_Invoking(Object sender, InvokeWebServiceEventArgs e) {
    var proxy = e.WebServiceProxy as MyWebServiceDefinition;
    if (proxy == null) return;
    proxy.ClientCrendetials =
        new System.Net.NetworkCredential("usuario", "password");
}

' VB Code
Public Sub InvokeWebService_Invoking(e As InvokeWebServiceEventArgs)
    Dim proxy = CType(e.WebServiceProxy, MyWebServiceDefinition)
    If proxy IsNot Nothing Then
        proxy.Credentials = New System.Net.NetworkCredentials("usuario", "password")
    End If
End Sub

Ojo con las definiciones anteriores, WebServiceProxy retorna tipo Object, por lo que hay que castearlo al tipo del webservice en específico.

Suficiente Workflow Foundation por hoy… Por cierto, les interesa el tema? ¿les gustaría más de WF en el futuro?

Saludos!

A few weeks ago on of my clients asked me to add international support for one of his web applications. Their current customers were located in different countries with different time zones. At first sight, it looks like an easy task, after all, .net has great support for globalization.

As expected, add internationalization and localization was an easy task to do, but after a few minutes of hacking I just realized it will not be an easy task to add multiple time zone support in a web application, the reason? simple: There is not an easy way in the server to get the client’s time zone location from the browser request. Yes, you can get things like .Net Framework installed, or even preferred browser languages, but no, there is no time zone information.

I googled for some hint to guide me in my journey, and the only thing I got was the obvious: Ask to the user where is his time zone preference and store it in user profile (database, or any other storage as you wish). Obviously my client didn’t want it, what they want is automatically detect client’s time zone location (in a future release probably they will add preferred client’s time zone modification in their application, but not in this release).

So I started looking for another way to bypass the issue. I remembered some old article in an ASP.NET Pro Magazine (now defunct), it was published at January 2007 and was entitled “It’s about Time” by someone named Alek Davis (sorry, no blog url found). Great article about how handle multiple time zones for the same web application. Sadly there was no sample source code available.

The solution background is simple:

• Store every date as UTC date, you can use the method DateTime.ToUniversalTime from the .Net Framework
• When display, Get the Browser Client’s Time Zone from somewhere
• When display, Add client’s time zone hours to stored UTC time

There is just a little issue, how to get the client’s time zone information from the server?

Well, the article give us a light, there is a javascript function which returns browser’s time zone offset in minutes, such function is Date.getTimezoneOffset(), but now there is another issue, how to get that information back to the server? What about this:

• Use javascript to get the time zone offset
• Store that information in a browser cookie
• Get that cookie with the client’s request
• Get time zone offset value from the cookie

So, I decided to write a simple Http Module to intercept ASP.NET request, check if that cookie exists, otherwise, inject a simple javascript code which get time zone offset, create that cookie and refresh the page to the original request. Well, you can check the sample code

To use it, first add a reference to the library to your web project and configure your asp.net module in your web.config file:

<!-- for IIS6 -->
<system.web>
    <!-- more configuration over here -->
    <httpModules>
        <add name="ScriptModule"
            type="System.Web.Handlers.ScriptModule, System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35"/>
        <add name="UtcModule" type="Cprieto.Utils.UtcInfoModule, Cprieto.Util.UtcInfo" />
    </httpModules>
</system.web>

<!-- for IIS7 -->
<system.webServer>
    <modules>
        <remove name="ScriptModule"/>
        <remove name="UtcModule"/>
        <add name="ScriptModule" preCondition="managedHandler"
            type="System.Web.Handlers.ScriptModule, System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35"/>
        <add name="UtcModule" preCondition="managedHandler" type="Cprieto.Utils.UtcInfoModule, Cprieto.Util.UtcInfo"/>
    </modules>
<!-- more configuration here -->
</system.webServer>

Now you can use the page extension with your project:

using Cprieto.Utils;

public partial class _Default : System.Web.UI.Page {
    protected void Page_Load(object sender, EventArgs e) {
        var current = DateTime.Now;
        var utc = current.ToUniversalTime();
        currentTimeLabel.Text = current.ToString();
        currentUtcTimeLabel.Text = utc.ToString();
        currentTimeOffsetLabel.Text = this.UtcOffset().ToString();
        calculatedTimeLabel.Text = this.LocalTimeFromTimeOffset(utc).ToString();
    }
}

There is an example web project in the source code if you want to check it.

Probably I will start to improve the current solution library. You could download my current source code from github http://github.com/cprieto/TimeZoneForAspNet

Aunque el concepto de “Currying” no es algo extraño para los lenguajes funcionales (y por lo tanto bastante conocido entre usuarios de este tipo de lenguajes). No es sólo una palabra extraña sino un concepto quizás desconocido para muchos usuarios de lenguajes imperativos como C#.

Currying (llamado así en nombre de Haskell Curry) no es más que el efecto de tomar de forma individual parámetro por parámetro y procesar cada parámetro por separado en su propia función, esto lo logramos tranformando el método o función en cuestión por uno que tome uno de los parámetros y una función para luego retornar otra función. Por ejemplo, tomemos el hecho de una simple suma:

sum       :: (Int, Int) -> Int
sum (x, y) = x + y

En este caso indicamos una función llamada sum que toma dos parámetros de tipo Int y retorna un parámetro de tipo Int. Dado que las funciones son ciudadanos de primer orden en los lenguajes funcionales, podemos transformarla y definir una función que tome como uno de sus parámetros una función y retorne otra función

sum'     :: Int -> Int -> Int
sum' x y = x + y

En este caso, creamos la función sum’ que toma un parámetro tipo Int y retorna otra función que toma un parámetro tipo Int y retorna un Int. Si, ya se que a simple vista esto puede parecer extraño, pero regresemos a ver un par de puntos claves: Currying involucra evaluar uno a uno los parámetros de una función pudiendo retornar otra función en su lugar.

Bien, regresemos a la Tierra y veamos como podemos transformar este tipo de cosas en una forma más "C#". Aprovechando los métodos lambda en C# (otra adición netamente funcional) podemos describir algo como esto:

public static void Main()
{
    Func<int, int, int> sum =
        (x, y) => x + y;

    int result = sum(1,2);

    Console.WriteLine(result);
}

Pero que les parecería si cambiamos "un poco" la definición de la función sum:

public static void Main()
{
    Func<int, Func<int, int>> sum =
        x => y => x + y;

    int result = sum(1)(2);
    Console.WriteLine(result);
}

Ahora sum en vez de tomar dos enteros como parámetro y retornar un entero, ahora toma un entero retorna una función (que toma un entero y retorna otro entero) como parámetros. De esta manera sum(1) retornará otra función que luego toma el parámetro 2 y retorna 3, wow…

El concepto de currying es práctico, permite definir funciones complejas a partir de funciones mucho más simples, aunque la definición en C# parece compleja, en realidad permite definir una función a partir de simplemente un parámetro (el cual convenientemente puede permanecer dentro de la función como si fuera una constante).

public static void Main()
{
    Func<int, Func<int, int>> ntimes =
        x => y => x * y;

    var twice = ntimes(2);
    var three = ntimes(3);

    Console.WriteLine(twice(4));
    Console.WriteLine(three(4));
}

Es interesante todo lo que podríamos lograr con solamente un poco de imaginación.

Escuchando al Dr. Meijer en su serie Functional Programming with Haskell, me topé con algo interesante: el caracter wildcard de Haskell. El "wildcard” (_) en Haskell es prácticamente lo mismo que el caracter wildcard (*) en nuestros sistemas operativos, evalúa o implica cualquier “otra cosa”. Por ejemplo:

(&&)         :: Bool -> Bool -> Bool
True && True = True
_ && _       = False

Tiene una interpretación sumamente sencilla: “Dada una función llamada &&, que toma un Bool y retorna una función que toma un Bool y retorna un Bool siendo sus parámetros True y True retornará True, de cualquier otra manera, retornará False”. A simple vista pensaremos que en lenguajes de “diario” no existen conceptos como el de “wildcard”, pero como lo dice luego el Dr. Meijer, en C# si tenemos el concepto de wildcard, claro, con nuestros amigos los Generics (otro concepto tomado de lenguajes funcionales y que data de muchos años atrás ).

En C# el guión bajo es un nombre aceptado de una variable, así que podemos utilizarlo como caracter de wildcard (a lo Haskell), imaginemos la declaración desiguiente tipo genérico:

public interface IRepository<T> {
    T GetById(int id);
}

Bien, que tal si lo nombramos algo así:

public interface IRepository<_> {
    _ GetById(int id);
}

Debo admitir que en mi caso lo veo algo extraño para los tipos de retorno… Que tal si usamos un wildcard para aquellos tipos que "debemos" definir pero que no "vamos" a utilizar.

// Siendo esta la declaración de un evento
runtime.RuntimeStarted += (sender, e) => Console.WriteLine(e.InstanceId);

// De igual manera, sender es un Object el cual no utilizamos
runtime.RuntimeStarted += (_, e) => Console.WriteLine(e.InstanceId);

Si, ya se que más de algún usuario de VB.NET me comentará que en VB9 no es necesario declarar en los eventos aquellos parámetros que no utilizaremos, pero esa es harina de otro costal.

Al parecer si hay un par de cosas que un usuario de C# puede aprender de Haskell… Saludos!

Soy fiel creyente que todo _buen_ desarrollador debe aprender por lo menos dos lenguajes nuevos por año, algunas otras personas diferiran conmigo y esgrimiran el dicho “es que hay que ser bueno y realmente bueno en una sola cosa”, y no estoy para discutir eso (para dejarlo claro, no creo que deba ser así, pero ese es otro tema).

Creo firmemente que aprender un lenguaje NO se trata de aprender sus palabras claves, ni sus librerias (aunque ciertamente podemos aprender mucho de ellas) o incluso, creer que porque hacemos el “hola mundo” ya conocemos de que se trata, gran error a mi parecer. Aprender un lenguaje lleva consigo aprender su “razón de ser”, enteder el problema que resuelve, comprender el porqué fue hecho, y si es posible, acoplar o absorver las buenas cosas que su paradigma comprende en nuestro lenguaje “de diario” que puedan ayudarnos y hacernos mejores desarrolladores.

En estas últimas semanas me decidí a tratar de comprender un poco acerca de lenguajes funcionales (algunos habran escuchado F#, ese es un ejemplo de un lenguaje funcional en la .Net Framework, Scala es otro en la Java VM) y como lenguaje modelo decidí aprender con Haskell, un lenguaje diseñado para la enseñanza de lenguajes funcionales, de esta manera aprovechaba una excelente colección de videos acerca de Functional Programming with Haskell a cargo del Dr. Erik Meijer (un señor sumamente inteligente y chistoso si me preguntan) los cuales estan disponibles para bajar del sitio de Channel 9, junto con las diapositivas y ejercicios de ejemplo, claro, deben acompañar la lecture con el libro de Programming in Haskell de Graham Hutton (de hecho las lecciones del Dr. Meijer estan basadas en el libro y estan diseñadas para darle seguimiento a cada uno de los capítulos del libro. Concejo, consigan el libro).

Me parece sumamente interesante el comienzo del libro y de las lecciones del Dr. Meijer. Soy fanático de la historia y comenzar una lecture con “historia de los lenguajes funcionales” me pareció impresionante, quizás exagero, pero creo que si los cursos universitarios incluyeran un “historia del arte de las ciencias de la computación” crearíamos profesionales un poco más concientes de que rayos se trata el oficio de computer sciences (o computer engineering, como prefieran), bueno, quizás ya estoy divagando un poco… Es increíble cosas que damos como “recientes” o “nuevas” realmente fueron ideadas por mentes sumamente billantes hace ya muchos años. Cosas como los Domain Specific Languages (DSL) y características ya más que conocidas como type inference y lazy evaluation datan desde los años 70. Quizás si vemos la historia nos daremos cuenta de qué es lo siguiente a venir en los próximos años.

Ahí les contaré que tal me va con Haskell. Hasta el próximo post!

I know there are a lot of Syntax Highlighter out there, but I love Alex Gorbatchev SyntaxHighlighter 2.0.

I had to write a new brush for Haskell language since I start searching for one without any success, this is my first attempt to make a SyntaxHighlighter Brush (and I just starting learning haskell a few weeks ago).

module sample where
{-
Multiline comments
this is a comment too
-}
isDigit :: Int -> Int
abs | n >= 0 = n
    | otherwise = -n
-- Single line comments allowed

You can get the simple brush here http://gist.github.com/261919

Hace unos días me topé con algo interesante, cambiar la fecha ya establecida en los campos de una tabla a una estandarizada para varios paises. La solución simple fue utilizar la fecha UTC (GMT 0), pero ya en SQL Server las fechas estaban registradas con la hora local.

En SQL Server podemos obtener el tiempo actual UTC con la función GETUTCDATE(), utilizando esto a nuestro favor decidí crear un simple UDF para cambiar las fechas.

CREATE FUNCTION [dbo].[ConvertToUtc](@start datetime)
RETURNS DATETIME
AS
BEGIN
    DECLARE @offset INTEGER
    SET @offset = DATEDIFF(HOUR, GETUTCDATE(), GETDATE())
    RETURN DATEADD(HOUR, @offset, @start)
END

Luego el proceso es simple, como ejemplo, transformando la fecha actual a UTC:

SELECT ConvertToUtc(CURRENT_TIMESTAMP)

Today I was visiting a client, and I just stop and watch something that really caught my attention:

foreach (item in myList) {
    if (item.Length > 0) {
        SaveItem(item);
    }
}
// more ugly code...

Well, the code was really different (an uglier one) but you got the idea…. What I suggested to my client was a more concise solutio, create an extension method:

public static class IEnumerableExt {
    public static IEnumerable<T> ForEach(this IEnumerable<T> items, Action<T> action) {
        foreach(var item in items) {
            action(e);
        }
    }
}

The second part is the easy one…

myList
    .Where((item) => item.Length > 0)
    .ForEach((item) => SaveItem(Item));

I don’t know you, but this way looks a lot clearer to me…

Lessson learned: If your code looks complex, please, take a time and look how to make it more clearer.