Lluís Franco on Geeks.ms : Frikadas

Sharpwhere over the rainbow…

Lluis Franco — Wed, 16 Feb 2011 16:55:37 GMT

…skies are blue :-)

Si, se que el título del post está ‘pillado’ con pinzas, pero de lo que trata este post es de “cómo utilizar una brocha para pintar el interior de un control con varios niveles de degradado“, o sea “pintar un control Label con los colores del arco iris” :-D

Que? Ya habéis terminado de reíros?

Pues ahora os cuento el porqué se me ha ocurrido todo esto: Resulta que un proyecto en el que estoy trabajando, se muestran unas barras de progreso de color azul que indican el % de realización de unos presupuestos. Después de mirarlas un rato y ver lo ‘sosas’ que quedaban, he pensado que le podía dar un toque de color, aprovechando que pronto va a ser el día del orgullo friki.

A que es bonito, verdad? :-)

Vale, pues hacer esto con WPF es trivial mediante GradientStops, pero, oooohhhh… este proyecto es WinForms. Pero tranquilos, el viejo y bueno namespace ‘System.Drawing.Drawing2D’ dispone de alguna sorpresa, como la clase ColorBlend, que permite definir un array de colores y posiciones para realizar degradados de colores. Anda mira, me ha salido un pareado! :-D

Total, que partiendo del evento Paint de cualquier control (en el que se obtienen como argumentos el contexto gráfico y el rectángulo del área a pintar), he creado una pequeña clase que permite especificar los distintos colores de degradado para el mismo:

public class MultiGradientRectangle

    public Graphics Graphics { get; set; }

    public Rectangle Rectangle { get; set; }

    public List<Color> ColorPoints { get; set; }

    public int PercentCompleted { get; set; }

    public MultiGradientRectangle(Graphics graphics, Rectangle rectangle)

        Graphics = graphics;

        Rectangle = rectangle;

        ColorPoints = new List<Color>();

    public void DrawMultiGradientRectangle()

        if (PercentCompleted == 0) return;

        if (ColorPoints.Count == 0) return;

        List<float> myPositions = new List<float>();

        float colordistance = 1f / (ColorPoints.Count - 1f);

        for (int i = 0; i < ColorPoints.Count; i++)

            myPositions.Add(colordistance * i);

        ColorBlend blend = new ColorBlend();

        blend.Colors = ColorPoints.ToArray();

        blend.Positions = myPositions.ToArray();

        using (LinearGradientBrush brush = new LinearGradientBrush(

            Rectangle, Color.Black, Color.White, 0, false))

            brush.InterpolationColors = blend;

            Graphics.FillRectangle(brush, Rectangle);

        //algo falta aquí... :-)

Ahora creamos un formulario con un control pictureBox (en realidad puede ser cualquiera) y nos suscribimos a su evento Paint.

public Form1()

    InitializeComponent();

    pictureBox1.Paint += pictureBox1_Paint;

void pictureBox1_Paint(object sender, PaintEventArgs e)

    drawMultiGradient(e.Graphics, e.ClipRectangle, 50);

private static void drawMultiGradient(Graphics g, Rectangle rect, int percent)

    MultiGradientRectangle mgrect = new MultiGradientRectangle(g, rect);

    mgrect.PercentCompleted = percent;

    mgrect.ColorPoints.Add(Color.Red);

    mgrect.ColorPoints.Add(Color.Orange);

    mgrect.ColorPoints.Add(Color.Yellow);

    mgrect.ColorPoints.Add(Color.LightGreen);

    mgrect.ColorPoints.Add(Color.Green);

    mgrect.DrawMultiGradientRectangle();

Así, podemos crear tantos puntos intermedios como queramos, sólo tenemos la limitación del buen gusto.

Sin embargo falta algo, verdad? Efectivamente, en la captura de pantalla puede verse perfectamente que las barras de progreso se ‘rellenan’ sólo hasta el porcentaje alcanzado. Si es un 0% no hay degradado, si es un 50% sólo hasta la mitad, y así…

Como veis, falta un fragmento de código en el método DrawMultiGradientRectangle. Os dejo como ejercicio mostrar únicamente el relleno hasta el % especificado mediante la propiedad ‘PercentCompleted’. A ver que solución es la más chula ;-)

Un saludo desde Andorra, nos vemos!

PD – Podéis decir lo que queráis acerca del diseño, se admiten todo tipo de críticas (otra cosa es que os haga caso :-P)

[Debate] Nombre de Namespaces en métodos extensores ¿Y tu que opinas?

Lluis Franco — Thu, 13 Jan 2011 12:19:00 GMT

Ayer, a raíz de un post del colega Javier Torrecilla sobre métodos extensores, unos cuantos de nosotros entre los que estaban el propio Javier y Jorge Serrano nos enzarzamos en una discusión en twitter acerca del mejor modo de declarar nuestros métodos extensores.

Pongamos un ejemplo: Supongamos que queremos crear un método extensor para comprobar si un valor está entre dos valores (el clásico between de toda la vida).

Agrego una clase llamada ExtensionMethods a mi proyecto, o a otro proyecto mi solución y agrego este código:

namespace CustomExtensions

    public static class ExtensionMethods

        public static bool Between<T>(this T @value, T min, T max) where T : IComparable<T>

            return @value.CompareTo(min) >= 0 && @value.CompareTo(max) <= 0;

Suponiendo que estamos en un proyecto de tipo WinForms, si queremos utilizar este método extensor sobre un valor de tipo int basta con ir a cualquier formulario y llamar al método between sobre un valor de este tipo. Por ejemplo:

Oops! Que pasa? Por que no aparece el método extensor? Bueno, como ya os habréis dado cuenta el método extensor está declarado dentro de un namespce llamado ‘CustomExtensions’, que es distinto al namespace del formulario en el que lo estoy probando, con lo que no podemos usarlo directamente si previamente no hacemos un using:

using CustomExtensions;

Vale, ahora si que aparece:

Bien. Esto en si no es nada del otro mundo, pero la cuestión es que si deseamos evitar declarar el using (tenéis que pensar que este método extensor lo podéis reutilizar en 1000 proyectos distintos), no tenemos otra opción que:

Declarar el método extensor en un namespace que se llame igual que el namespace en el que se va a usar.
Declarar el método extensor en un namespace que se llame igual que el namespace del tipo que estamos extendiendo.
Pasar de todo y llamarlo al namespace como queramos, y que a la hora de usarlo debamos usar un using para agregarlo.

Particularmente, al extender tipos básicos (string, int) soy partidario del segundo punto, de modo que si vamos a extender elementos de tipo IComparable, en lugar de usar el namespace ‘CustomExtensions’ prefiero usar el nombre del namespace que contiene la definición de este tipo, o sea ‘System’:

namespace System

    public static class ExtensionMethods

        public static bool Between<T>(this T @value, T min, T max) where T : IComparable<T>

            return @value.CompareTo(min) >= 0 && @value.CompareTo(max) <= 0;

Pero ese es mi punto de vista, tu que opinas? Twitteros manifestaos! :-)

La característica más extraña que has visto en un lenguaje

Lluis Franco — Thu, 14 Jan 2010 08:37:00 GMT

Que Bueno!

Acabo de leer un post muy cachondo en Stack Overflow, y todavía me estoy riendo por acabo de leer. En este post se puede leer:

“What is, in your opinion, the most surprising, weird, strange or really ‘WTF’ language feature you have encountered?”

Que podriamos traducir algo así como:

“Cual es en tu opinión, la característica de un lenguaje más sorprendente, rara, extraña, o más ‘pero que co... es esto’ que has visto jamás”

La verdad es que después de leer el post, veo que a algunas de ellas ya las conocía, pero otras han sido tremendamente reveladoras. Al final me quedo con dos cosas: La primera es mi reafirmación en mi odio produndo a Javascript (pues si, que pasa... no me gusta nada de nada, aunque tenga que usarlo por OO). Y la segunda es que todos los lenguajes o plataformas tienen sus cosas, y .NET no es una excepción, pero esta de Java no tiene desperdicio:

Fun with auto boxing and the integer cache in Java.

Integer foo = 1000;

Integer bar = 1000;

foo <= bar; // true

foo >= bar; // true

foo == bar; // false

//However, if the values of foo and bar are between 127 and -128 (inclusive)

//the behaviour changes:

Integer foo = 42;

Integer bar = 42;

foo <= bar; // true

foo >= bar; // true

foo == bar; // true

Ni esta otra, en PL/1:

IF IF THEN THEN = ELSE ELSE ELSE = THEN

En fin, tremendo!!! :-)))

Cual es la mejor en vuestra opinión? No tiene porque estar en el post original...

Ver el post original:

http://stackoverflow.com/questions/1995113/strangest-language-feature

Saludos desde Andorra,

Microsoft Virtual Business Cards para MCPs

Lluis Franco — Thu, 10 Dec 2009 12:11:06 GMT

Como ya sabéis, el pasado Junio Microsoft decidió terminar con los paquetes de bienvenida (también llamados Welcome kits). Se supone que los motivos son ecológicos y no tienen nada que ver con el ahorro de costes, pero en estos tiempos de crisis... uhm... no se, no se :-)

La cuestión es que existe un nuevo servicio para todos los MCP gracias al cual uno se puede crear su propia tarjeta de visita, y compartirla con el resto de la comunidad.

Al igual que David, al principio pensé que era una chorrada, pero la verdad es que el resultado es una chulada :-)

Os dejo una muestra en diversos formatos:

HTML:

Java Script (mira en My Certifications):

Imagen:

Saludos,

Server Quest II A day in a geek’s life…

Lluis Franco — Wed, 08 Apr 2009 15:52:41 GMT

Que pasada!

Me acaba de llegar un enlace, vale la pena darle una ojeada... No os quiero contar nada porque quiero que lo veáis con vuestros propios ojos :-)

Me recuerda a los viejos juegos MAME, jejeje…

Ah! Y buen finde largo (los que lo tengan).

Saludos!

Google Chrome usa ClickOnce :-)

Lluis Franco — Mon, 06 Apr 2009 10:02:00 GMT

Pues eso. Tal vez muchos de vosotros ya lo sabíais pero esta mañana me he quedado de piedra al comprobar que la instalación de Google Chrome se realiza mediante la tecnología ClickOnce de Microsoft. Curioso verdad? Para muestra un botón:

Si lo piensas es normal, ya que el código del producto para Windows no deja de ser una solución de Visual Studio 2005 (15 proyectos si no recuerdo mal), de modo que es relativamente normal que se hayan aprovechado de una tecnología tan *cojonuda* (y perdón por la expresión) com es ClickOnce para el despliegue de aplicaciones.

Lo que no deja de ser gracioso es que de momento Chrome no tenga versiones estables para Mac ni para Linux (de hecho según los mismos desarrolladores "Esta mas cerca del comienzo que del fin"), y la única versión que funciona más o menos bien esté desarrollada con la herramienta de desarrollo más popular de la competencia :-P

En fin, como dije antes… curioso, verdad?

SR-71 Blackbird, un sueño hecho realidad

Lluis Franco — Thu, 19 Feb 2009 11:00:00 GMT

Recuerdo que cuando tenía unos 10 añitos, quería ser piloto de cazas. Me pasaba tardes enteras mirando colecciones de cromos, y me compraba todas las revistas de aviones que me permitía mi escasa asignación semanal. Y soñaba, como sueñan todos los niños en cumplir algún día mis sueños...

De entre todos los aviones habidos y por haber, había uno que era mi favorito: El Lockheed SR-71Blackbird. Era precioso, muy avanzado para su tiempo, y su diseño era genial, simplemente una obra de arte. Más bien parecía una nave espacial antes que un avión, y eso para alguien que se crió con Star-Wars era toda una tentación.

En fin, a la vista está que mi sueño se quedó en eso... un sueño. Pero da igual, estoy seguro que muchos de nosotros tenemos algún sueño que no hemos podido cumplir. Aunque esa es otra historia, tampoco puedo quejarme ya que la vida me ha tratado bien.

Sin embargo, esta mañana mientras estaba buscando unas viejas fotos, me he topado con una serie de fotos que me han hecho recordar un momento que para mí fue muy especial. Fue en 2005, en el que fue mi primer MVP Summit.

Después de tres días de conferencias, sesiones, eventos, comidas y alguna salida nocturna por las calles de Seattle, unos cuantos de nosotros decidimos escaparnos al mueso de la Boeing. Era una pequeña excursión en la que aprovecharíamos para ir a comprar a algún centro comercial y yo aprovecharía para poder ver algún avión.

Pero allí, para mi sorpresa me encontré con que en mitad de un hangar enorme había un SR-71. No os cuento lo que fue poder verlo y tocarlo (aunque estaba prohibido :-P). Pude observar los motores con todo detalle, subir en una réplica de la cabina, y pasearme por debajo como en su día hicieron Clint Eastwood y Tommy Lee Jones en Space Comwoys. De esa película recuerdo una frase que dice que “el Blackbird cuando está posado en tierra es como un ladrillo, feo y hasta gotea combustible, pero que cuando se pone a Mach 3 sus juntas se cierran, todo encaja perfectamente y se convierte en una máquina perfecta”.

En fin, fue una sensación muy especial... Casi llego a considerar cumplido mi sueño.

Hablando de sueños. Recuerdas alguno de tus sueños de niño que no hayas podido cumplir?

Un saludo desde Andorra,

10 cosas que me gustan de C# respecto a VB

Lluis Franco — Tue, 23 Dec 2008 16:44:53 GMT

Antes de empezar a leer este post, un aviso: En ningún modo pretendo crear polémica o abrir el viejo debate otra vez, si no más bien enumerar algunas cosillas que hacen que *yo* me sienta más cómodo trabajando con C# que con VB, tanto a nivel de lenguaje como del propio editor. Lo remarco porque quiero que quede bien claro que es una opinión personal, ok? No se trata de comerle el coco a nadie…

Algunas de estas cosillas ya las he compartido con algunos de vosotros en algún evento de los grupos de usuarios, o simplemente delante de unas cervezas (aquí la conversación suele tornarse más pasional y tiende a alargarse un poco), jejeje…, y a decir verdad pocas veces nos ponemos de acuerdo ¿eh agüelo?. Parece ser que antes de empezar a hablar cada cual ya se ha posicionado y de aquí no nos movemos… lo cual es hasta cierto punto normal. Uno sabe con qué herramienta se encuentra más cómodo, aunque pueda usar ambas de forma indistinta.

De hecho he tirado más líneas de código con VB que con cualquier otro lenguaje, y eso que empecé en este mundillo con C y posteriormente con C++, para luego pasar a los lenguajes ‘más productivos’ como Delphi o finalmente VB en sus primeras versiones. No fue hasta 2002 y las primeras versiones de .NET que volví a usar la vieja sintaxis del punto y coma. De modo que VB en-todas-sus-variedades me es muy querido, y debo reconocerle sus ventajas… Sin embargo, codificar, al igual que leer o hablar, es algo que siempre haces mejor o te sientes más cómodo en uno de los lenguajes que dominas, y aquí reconozco que C# (como antes de conocerlo lo fue Java) es mi predilecto. Siempre que YO decido el lenguaje a utilizar en un nuevo proyecto, lo escojo, y en caso contrario intento convencer a la otra persona (ya sea compañero, cliente, etc.).

Os enumero a continuación una lista de cosas que me gustan de C#, o más bien que no me gustan cuando al cabo de un tiempo de trabajar con C#, me pongo a codificar con VB. No siguen ningún orden ni patrón y las voy a ir enumerando conforme se me vayan ocurriendo:

1) Escribo menos código && código más limpio:

En este punto, un desarrollador de VB acostumbra a decirme que esto no es cierto. Que si bien la sintaxis de VB es en alguno puntos ‘rocambolesca’ es para aclarar, y además el propio editor de código se encarga de escribirlo. Sin embargo tengo comprobado que con el editor de C# en la gran mayoría de las situaciones tecleo menos para decir lo mismo, y queda más claro (al menos para mí). Ojo! Es importante destacar que en ningún momento me mueve el afán de teclear menos, sino que el código resultante sea más legible. Comparemos los siguientes ejemplos:

Declarar una variable:

C#:

int x = 5;

VB:

Dim x As Int = 5

Bloques de código (ends por todas partes :-P).

C#:

if(Nombre == "Pepe" && Sueldo <= 500)

...

VB:

If Nombre = "Pepe" AndAlso Sueldo <= 500 Then

...

End If

Operador AddressOf

C#:

Thread t = new Thread(CountSheep);

VB:

Dim t As New Thread(AddressOf CountSheep)

Expresiones lambda:

C#:

Func<int, Func<int, int>> mult = (int x) => (int y) => x * y;

VB:

Dim mult As Func(Of Integer, Func(Of Integer, Integer)) = _

Function(x As Integer) Function(y As Integer) x * y

Implementar una interfaz (no es preciso Implements):

C#:

interface ITest

    string getValue();

class Test : ITest {

    string getValue()

        Random r = new Random();

        return r.Next().ToString();

VB:

Interface ITest

    Function getValue() As String

End Interface

Class Test

    Implements ITest

    Public Function getValue() As String Implements ITest.getValue

        Dim r As New Random

        Return r.Next().ToString()

    End Function

End Class

Podriamos seguir con Overridable, Overrides y unos cuantos más... Pero mejor vamos al siguiente punto que si no, no acabo el post hoy… :-)

2) No más underscores!

Cuantas veces he tenido que escuchar “no tengo porque terminar cada línea de código con un punto y coma!”. Pues precisamente, el delimitador de línea es lo que permite que en los lenguajes derivados del viejo y bueno ‘C’ no tengamos que hacer algo tan antinatural como partir las líneas de código con underscores (_). Además suele pasar que es una de las cosas que olvido con mayor rapidez, y cada vez que escribo en VB una query con LINQ acabo por soltar un “AAAAARGH!!! OTRA VEZ!!!”.

C#

List<int> nums = new List<int>(new int[] { 1, 2, 3, 4 });

var mynums = from n in nums

             where n < 5

             orderby n

             select n;

VB:

Dim nums As New List(Of Integer)(New Integer() {1, 2, 3, 4})

Dim mynums = From n In nums _

    Where n < 5 _

    Order By n _

    Select n

3) Matrices y Listas: [] en lugar de ():

Cuando estoy picando o leyendo código me gusta saber con exactitud si estoy llamando a una función, a una propiedad u obteniendo el valor de una matriz o colección. Precisamente por eso prefiero usar corchetes en lugar de paréntesis para acceder a los miembros de una matriz o lista. En el ejemplo siguiente en la llamada a nums(i) en VB, podría ser tanto un método como una matriz, como una propiedad que devuelve una matriz o lista:

C#

List<int> nums = new List<int>(new int[] { 1, 2, 3, 4 });

Console.WriteLine(nums[2].ToString());

VB:

Dim nums As New List(Of Integer)(New Integer() {1, 2, 3, 4})

Console.WriteLine(nums(2).ToString())

4) Parámetros de salida (out):

Tipos de parámetro de salida. Estos son muy parecidos a los parámetros por referencia (ref), pero no necesitan ser inicializados. Resultan particularmente útiles en algoritmos recursivos. Visual Basic no dispone de nada equivalente, aunque si permite el paso de valores por referencia.

C#:

static void Method(out int i)

    i = 44;

static void Main()

    int value;

    Method(out value);

5) Los códigos de escape y las cadenas verbatim:

Otra cosa que me molesta es que VB no reconoce los carácteres de escape contenidos en un string. Esto es particularmente útil cuando deseamos mostrar un retorno de línea ‘\n’ o una tabulación ‘\t’ dentro de una cadena. En Visual Basic hay que recorrer a la concatenación de Environment.NewLine o artimañas parecidas como concatenar directamente el carácter. Por ejemplo el código siguiente se muestra así:

MessageBox.Show("hola\nque\ntal");

C#:

VB:

En este punto más de uno se preguntará ¿y que pasa si no quiero tratar estos caracteres de escape como especiales?, ¿o si quiero mostrar una ruta de acceso que contiene varios caracteres ‘\’? Bien, para ello tenemos varias alternativas: Podemos anteponer un carácter ‘\’ a todo símbolo que deseemos mostrar literalmente o podemos usar cadenas verbatim (también llamado ‘literal de cadena textual’):

MessageBox.Show("C:\\Windows\\system32\\Calc.exe");

MessageBox.Show(@"hola\nque\ntal");

Las cadenas verbatim van incluso un poco más allá y permiten incluso poder partir una cadena en varias líneas, lo que clarifica en mucho el código:

MessageBox.Show(@"SELECT O.OrderID, O.CustomerID, O.EmployeeID,

                O.OrderDate, O.RequiredDate, O.ShippedDate,

                O.ShipVia, O.Freight, O.ShipName, O.ShipAddress,

                O.ShipCity, O.ShipRegion, O.ShipPostalCode,

                O.ShipCountry, C.CompanyName, C.Address,

                C.City, C.Region, C.PostalCode, C.Country

                FROM dbo.Customers AS C

                INNER JOIN dbo.Orders AS O

                ON C.CustomerID = O.CustomerID");

6) Propiedades autogeneradas:

Algo tan sencillo como crear una propiedad para una clase, lo es todavía más en C#, ya que permite el uso de propiedades autogeneradas. Esto hace que el compilador maneje internamente una variable privada a nivel de clase para almacenar el valor, quedando esta parte oculta al desarrollador. Esta característica estará disponible en la próxima versión de Visual Basic, pero de momento todavía tenemos que conformarnos con representarlo así:

C#:

class Foo

    public int id { get; set; }

    public string name { get; set; }

VB:

Class Foo

    Private _id As Integer

    Public Property id() As Integer

Get

            Return _id

        End Get

        Set(ByVal value As Integer)

            _id = value

        End Set

    End Property

    Private _name As String

    Public Property name() As String

Get

            Return _name

        End Get

        Set(ByVal value As String)

            _name = value

        End Set

    End Property

End Class

7) Refactoring:

Hoy en día, al igual que el uso de pruebas unitarias, empieza a ser impensable no refactorizar el código para una mejor comprensión, que repercute en un mejor índice de mantenibilidad (o Maintainability index, vaya usted a saber cómo se traduce) del código. Bien, pues el menú ‘Refactor’ del editor de C# no aparece en VB. Y la única información acerca de refactorizar el código VB nos enlaza con un Add-In de terceros, la cual a decir verdad es una gran utilidad. Lo sé, porque he usado la versión PRO de este producto durante bastante tiempo. Pero el hecho es que Visual Studio no incorpora ninguna utilidad ‘de fábrica’ para refactorizar el código, lo que no deja de ser sorprendente…

8) Posibilidad de desactivar ‘Strict on’:

Al ser VB la evolución de un lenguaje no tan ‘estricto’ como C#, nos ofrece la posibilidad de desactivar la opción Strict On, y de este modo dejar que el compilador se encargue de realizar muchas conversiones implícitas. Pero lo más peligroso de todo es que la opción viene desactivada ‘de fábrica’ y en cambio no conozco ningún buen programador de VB (que los hay, y muchos) que no sea lo primero que active. Muchos errores en tiempo de ejecución podrían ser evitados si el propio compilador nos obligase a codificar correctamente, en lugar de actual de este modo más ‘relajado’:

VB (con Option Strict Off):

Dim s As String

s = DateTime.Today

VB (con Option Strict On):

Dim s As String

s = DateTime.Today.ToString()

Observar que con Option Strict activado, el compilador no permite asignar una fecha a una variable de tipo cadena (con razón!), de modo que para poder compilar debemos realizar una conversión explícita.

Recomiendo dar un vistazo a este artículo de coding horror:
http://www.codinghorror.com/blog/archives/000355.html

9) Microsoft.VisualBasic:

Son legión los programadores que provienen de versiones anteriores de .NET (6 o anteriores), de modo que para facilitarles el camino los proyectos de VB incorporan el espacio de nombres Microsoft.VisualBasic, el cual a su vez incorpora muchas de las funciones de estas versiones anteriores. El hecho de incorporarlas no es un error en sí, lo malo es que estas funciones tienen su equivalente en el modelo de objetos del framework, y si seguimos usando estas funciones ‘antiguas’ no aprenderemos las nuevas, y el día en que debamos trabajar con otro lenguaje del Framework (que no tiene porque ser C#, hay unos cuantos más :-P) nos encontraremos con que estamos usando funciones propias de VB y no conoceremos su equivalente.

Por ejemplo, en lugar de llamar a la función Len para averiguar el número de caracteres de una cadena, es mejor usar el método Lenght de la clase String, lo mismo para Trim(), y todavía es más flagrante con Mid(), que equivale al método SubString del objeto String:

Dim n As Integer = Len(DateTime.Now.ToLongDateString)    'NO

Dim n As Integer = DateTime.Now.ToLongDateString.Lenght  'SI

No son pocos los esfuerzos de muchos compañeros, fantásticos programadores como Jorge Serrano o Harvey Triana para eliminar esta librería de nuestras aplicaciones, de modo que la recomendación siempre acaba siendo “no la uses, no la mires, haz como si no estuviera…”. Por cierto, os recomiendo una lectura de ambos artículos.

10) Hay más, y no se por cual decidirme…

Hay muchas otras cosas que se quedan en el tintero, porque algunas de ellas son demasiado largas (como el manejo de eventos), y otras no son precisamente de uso diario, como la ejecución de código no seguro (unsafe). Pero estaremos de acuerdo en que la mayoría de las novedades aparecen primero para C# (inicializadores de colecciones, propiedades autogeneradas, soporte para expresiones lambda ‘de verdad’, etc.) e incluso los compiladores de C# del proyecto MoNo van siempre por delante de los de VB. Aunque este último punto reconozco que no es demasiado importante… o sí?

En fin, vaya chapa me ha salido! Pero por lo menos ahora tengo una lista de cosas para cuando me pregunten “¿porque te gusta más C# que VB?”.

Un saludo desde Andorra,

DXHelmet: El futuro de la interacción hombre - máquina

Lluis Franco — Tue, 28 Oct 2008 08:26:55 GMT

Ver para creer… si hace unos años me dicen que esto sería posible no me lo hubiese creído.

Como dicen ellos mismos:
[…] The future of software development is here - the way in which you interact with the computer will never be the same again...

No os digo más, darle un vistazo que vale la pena:
http://devexpress.com/helmet

Quieres ver las caras del VBTeam?

Lluis Franco — Thu, 24 Jul 2008 07:04:16 GMT

Beth Massi publica un par de fotos en el blog del VBTeam, y nos cuenta la anécdota de porque todos visten de gris.

Saludos,

Debian y sus juguetes, Dilbert y los aleatorios

Lluis Franco — Fri, 30 May 2008 07:50:47 GMT

:-)
Esta mañana estaba dándole una ojeada al problema anunciado por Luciano Bello sobre la vulnerabilidad descubierta en OpenSSL, que ha generado claves débiles entre el mes de Septiembre de 2006 y el 31 de Marzo de este año. Cuando de repente me he encontrado con estas tiras del genial Dilbert al respecto de la generación de aleatorios:

Y No, no voy a hablar sobre el tema, que ya se ha hablado demasiado... Simplemente hacer la reflexión sobre que pasaría si el fallo de seguridad se hubiese producido en el sistema operativo más maléfico del mundo, creado por Spectra la compañía que pretende dominar el mundo a golpe de Software.

Más info en:
http://metasploit.com/users/hdm/tools/debian-openssl/

Saludos,

Creo que cobro poco para lo que trabajo...

Lluis Franco — Mon, 26 May 2008 09:58:35 GMT

:-D
Y es que esta mañana me he dado cuenta de que en una aplicación ASP.NET que estoy desarrollando me ha aparecido uno de esos feos mensajes de error de Javascript. Para sorpresa mía me informaba de que se ha producido un error en la línea 64.591.517

Vamos a ver: Si llevo un par de meses y medio con la aplicación........ me salen...... a ver......... sobre un millón de líneas al día. No está nada mal, no señor!

Si ya sabía yo que era un mondtuo picando código, jejeje...

Saludos desde Andorra, bajo el agua.

Buscas un traductor friki?

Lluis Franco — Tue, 08 Jan 2008 19:54:42 GMT

Nunca dejan de sorprenderme las frikadas que uno encuentra en la Web. No se trata de una camiseta con un equalizador que muestra el sonido de ambiente, y tampoco de un lanzamisiles USB, naaaa... En esta ocasión os quiero mostrar algo con lo que todo friki de Star wars ha soñado desde que era pequeñito: Nada más y nada menos que un traductor humano -> R2D2!!!

Puedes especificar el texto a traducir y hasta descargarlo para ponerlo como melodía para tu móvil (aunque esto se reserva para los más frikis).

Darle un vistazo, vale la pena: http://r2d2translator.com/