El blog de Juan Irigoyen en Geeks·ms

Macro sustitución en C#

Juan Irigoyen — Fri, 22 Jan 2010 11:43:00 GMT

Una de las características de Visual Foxpro (mi anterior lenguaje antes de .net) y del que todos los días me acuerdo cuando me peleo con .net, era la utilización de macro sustitución, esta permitía realizar cosas como la siguiente:

   1: FOR i = 1 TO 12

   2:    xcam = 'Formas_pago.poraplaza' + ALLTRIM(STR(i))

   3:    IF &xcam > 0

   4:    ENDIF

   5: ENDFOR

De esta forma utilizando el símbolo &, podía evaluar el contenido de los campos sin tener que escribirlos uno a uno y ahorrando líneas de código.

Por desgracia c# no posee esta característica con un uso tan sencillo, se pueden realizar aproximaciones compilando el código al vuelo con codedoom o similares, pero personalmente evitaria utilizar estas técnicas si no es absolutamente necesario.

Ya metidos en harina, estaba en .net transcribiendo un bloque de código desde Fox y claro el pequeño programa de arriba daba lugar a un programa similar a este:

/// Carga la configuración dependiente de la forma de pago correspondiente

if (!string.IsNullOrEmpty(cvc.Forma_pago))

{

    using (ManagerBI<Formas_pago> manager = new ManagerBI<Formas_pago>() )

    {

        if (manager.GetRecord(cvc.Forma_pago))

        {

            cvc.PorcentajesAplazamientoAdd(manager.Data.Porcentaje_aplazamiento_1);

            cvc.PorcentajesAplazamientoAdd(manager.Data.Porcentaje_aplazamiento_2);

            cvc.PorcentajesAplazamientoAdd(manager.Data.Porcentaje_aplazamiento_3);

            cvc.PorcentajesAplazamientoAdd(manager.Data.Porcentaje_aplazamiento_4);

            cvc.PorcentajesAplazamientoAdd(manager.Data.Porcentaje_aplazamiento_5);

            cvc.PorcentajesAplazamientoAdd(manager.Data.Porcentaje_aplazamiento_6);

            cvc.PorcentajesAplazamientoAdd(manager.Data.Porcentaje_aplazamiento_7);

            cvc.PorcentajesAplazamientoAdd(manager.Data.Porcentaje_aplazamiento_8);

            cvc.PorcentajesAplazamientoAdd(manager.Data.Porcentaje_aplazamiento_9);

            cvc.PorcentajesAplazamientoAdd(manager.Data.Porcentaje_aplazamiento_10);

            cvc.PorcentajesAplazamientoAdd(manager.Data.Porcentaje_aplazamiento_11);

            cvc.PorcentajesAplazamientoAdd(manager.Data.Porcentaje_aplazamiento_12);

  

            cvc.DiasPagoAdd(manager.Data.Dia_pago_1);

            cvc.DiasPagoAdd(manager.Data.Dia_pago_2);

            cvc.DiasPagoAdd(manager.Data.Dia_pago_3);

            cvc.DiasPagoAdd(manager.Data.Dia_pago_4);

            cvc.DiasPagoAdd(manager.Data.Dia_pago_5);

            cvc.DiasPagoAdd(manager.Data.Dia_pago_6);

            cvc.DiasPagoAdd(manager.Data.Dia_pago_7);

            cvc.DiasPagoAdd(manager.Data.Dia_pago_8);

            cvc.DiasPagoAdd(manager.Data.Dia_pago_9);

            cvc.DiasPagoAdd(manager.Data.Dia_pago_10);

            cvc.DiasPagoAdd(manager.Data.Dia_pago_11);

            cvc.DiasPagoAdd(manager.Data.Dia_pago_12);

  

            cvc.DiasAplazamientoAdd(manager.Data.Dias_aplazamiento_1);

            cvc.DiasAplazamientoAdd(manager.Data.Dias_aplazamiento_2);

            cvc.DiasAplazamientoAdd(manager.Data.Dias_aplazamiento_3);

            cvc.DiasAplazamientoAdd(manager.Data.Dias_aplazamiento_4);

            cvc.DiasAplazamientoAdd(manager.Data.Dias_aplazamiento_5);

            cvc.DiasAplazamientoAdd(manager.Data.Dias_aplazamiento_6);

            cvc.DiasAplazamientoAdd(manager.Data.Dias_aplazamiento_7);

            cvc.DiasAplazamientoAdd(manager.Data.Dias_aplazamiento_8);

            cvc.DiasAplazamientoAdd(manager.Data.Dias_aplazamiento_9);

            cvc.DiasAplazamientoAdd(manager.Data.Dias_aplazamiento_10);

            cvc.DiasAplazamientoAdd(manager.Data.Dias_aplazamiento_11);

            cvc.DiasAplazamientoAdd(manager.Data.Dias_aplazamiento_12);

        }

    }

}

Qué horror, 36 líneas para hacer lo mismo, pero imaginar que en lugar de 36 campos tuviéramos 100. Se me ocurrió la idea de usar reflection para poder evitar la escritura de tantas líneas y resulto relativamente fácil, la solución es interesante y en casos similares os permitirá reducir en gran medida vuestro código. El rendimiento de reflexión apenas penalizará la aplicación.

/// Carga la configuración dependiente de la forma de pago correspondiente

if (!string.IsNullOrEmpty(cvc.Forma_pago))

{

    using (ManagerBI<Formas_pago> manager = new ManagerBI<Formas_pago>() )

    {

        if (manager.GetRecord(cvc.Forma_pago))

        {

            Type t = manager.Data.GetType();

  

            for (int i = 1; i < 12; i++)

            {

                string contador = i.ToString().Trim();

                decimal porcentajeAplazamiento = (decimal)t.InvokeMember("Porcentaje_aplazamiento_" + contador, BindingFlags.GetProperty, null, manager.Data, null, CultureInfo.CurrentCulture);

                cvc.PorcentajesAplazamientoAdd(porcentajeAplazamiento);

                byte diaPago = (byte)t.InvokeMember("Dia_pago_" + contador, BindingFlags.GetProperty, null, manager.Data, null, CultureInfo.CurrentCulture);

                cvc.DiasPagoAdd(diaPago);

                Int16 diasAplazamiento = (Int16)t.InvokeMember("Dias_aplazamiento_" + contador, BindingFlags.GetProperty, null, manager.Data, null, CultureInfo.CurrentCulture);

                cvc.DiasAplazamientoAdd(diasAplazamiento);

            }

        }

    }

}

Espero que os sirva.

Database Professionals 2010. Pruebas Unitarias de Bases de datos y materiales de la charla.

Juan Irigoyen — Sun, 25 Oct 2009 19:30:00 GMT

El otro día tuve el placer de compartir una charla sobre Visual Studio 2010 organizada por Juan Carlos Gonzalez del CIIN con Rodrigo Corral e Ibon Landa. Os dejo los materiales de la charla y un pequeño artículo sobre las diferentes pruebas de calidad en Base de datos comentado durante la presentación. Realice tres ejemplos, basados en un procedimiento almacenado que actualizaba un registro en la tabla Employee de AdventureWorks2008. Su definición es la siguiente:

CREATE PROCEDURE [HumanResources].[uspUpdateEmployeePersonalInfo]

    @BusinessEntityID [int],

    @NationalIDNumber [nvarchar](15),

    @BirthDate [datetime],

    @MaritalStatus [nchar](1),

    @Gender [nchar](1)

WITH EXECUTE AS CALLER

AS

BEGIN

    SET NOCOUNT ON;

    BEGIN TRY

        UPDATE [HumanResources].[Employee]

        SET [NationalIDNumber] = @NationalIDNumber

            ,[BirthDate] = @BirthDate

            ,[MaritalStatus] = @MaritalStatus

            ,[Gender] = @Gender

        WHERE [BusinessEntityID] = @BusinessEntityID;

    END TRY

    BEGIN CATCH

        EXECUTE [dbo].[uspLogError];

    END CATCH;

END;

El ejemplo básico consistía simplemente en llamar al SP con unos datos ficticios que no realizaba ninguna actualización, esta prueba solo cubría que la llamada al SP se realizase de forma correcta.

El segundo ejemplo consistía en insertar un determinado registro antes de la prueba, llamar al SP para que realizase la actualización sobre ese registro y finalmente eliminar el registro de prueba insertado, esta prueba cubría que la llamada al SP se realizase de forma correcta y además permitía conocer si el sp funcionaba correctamente actualizando un registro de la BD.

El tercero y más interesante consistía en blindar el SP frente a cualquier cambio, uno de los problemas más habituales que sufrimos es que los SP, se suelen modificar a menudo y muchos de los fallos no detectados vienen derivados al cambiar las longitudes de los campos, el orden, tipo de dato y otros aspectos del procedimiento.

Para testar el SP, realice la consulta siguiente para averiguar la configuración completa procedimiento:

SELECT DISTINCT dbo.sysobjects.name, dbo.sysobjects.xtype AS type, dbo.syscolumns.name AS param, dbo.syscolumns.colorder AS corder,

dbo.syscolumns.length, dbo.syscolumns.colstat AS keyc, dbo.syscolumns.isoutparam AS colisout, dbo.systypes.xtype, dbo.syscolumns.prec as precision,

dbo.syscolumns.scale, dbo.syscolumns.isnullable, dbo.syscolumns.iscomputed, dbo.syscolumns.number

FROM dbo.syscolumns

INNER JOIN dbo.sysobjects ON dbo.syscolumns.id = dbo.sysobjects.id

INNER JOIN dbo.systypes ON dbo.syscolumns.xtype = dbo.systypes.xtype

WHERE (dbo.sysobjects.name = 'uspUpdateEmployeePersonalInfo') AND (dbo.systypes.status <> 1)

Con los datos obtenidos podemos desarrollar una consulta que utilize los valores mostrados para comprobar que el procedimiento almacenado tiene la configuración mostrada por la consulta.

SELECT COUNT(DISTINCT dbo.syscolumns.name)

FROM dbo.syscolumns

INNER JOIN dbo.sysobjects ON dbo.syscolumns.id = dbo.sysobjects.id

INNER JOIN dbo.systypes ON dbo.syscolumns.xtype = dbo.systypes.xtype

WHERE (dbo.sysobjects.name = 'uspUpdateEmployeePersonalInfo') AND (dbo.systypes.status <> 1)

AND ((dbo.syscolumns.name = '@BirthDate' AND dbo.syscolumns.colorder = 3 AND dbo.systypes.xtype = 61 AND dbo.syscolumns.length = 8 and dbo.syscolumns.prec = 23 and dbo.syscolumns.scale = 3)

OR (dbo.syscolumns.name = '@BusinessEntityID' AND dbo.syscolumns.colorder = 1 AND dbo.systypes.xtype = 56 AND dbo.syscolumns.length = 4 and dbo.syscolumns.prec = 10 and dbo.syscolumns.scale = 0)

OR (dbo.syscolumns.name = '@Gender' AND dbo.syscolumns.colorder = 5 AND dbo.systypes.xtype = 239 AND dbo.syscolumns.length = 2)

OR (dbo.syscolumns.name = '@MaritalStatus' AND dbo.syscolumns.colorder = 4 AND dbo.systypes.xtype = 239 AND dbo.syscolumns.length = 2)

OR (dbo.syscolumns.name = '@NationalIDNumber' AND dbo.syscolumns.colorder = 2 AND dbo.systypes.xtype = 231 AND dbo.syscolumns.length = 30))

La consulta devuelve (5), el numero de campos del procedimiento uspUpdateEmployeePersonalInfo que cumplen las condiciones especificadas. Si el valor retornado por la consulta no es 5, supondra que hemos alterado algun aspecto de configuración del procedimiento almacenado, longitud, tipo de valor, orden del campo en el store procedure, etc.

La prueba completa quedaría de esta forma:

PreTest

/* Desabilita el trigger que impide el borrado de registro en la tabla .[HumanResources].[Employee] */

DISABLE Trigger [HumanResources].[dEmployee] ON [HumanResources].[Employee]

/* Borra el registro de pruebas si por alguna razon estuviera ya insertado */

DELETE [AdventureWorks2008].[HumanResources].[Employee]

WHERE [BusinessEntityID] = 2292

/* Realiza la inserción del registro de pruebas, hay que analizar los datos de la insercción ya que hay campos que tienen restricciones a nivel de tabla

como MartitalStatus que slo acepta M (Male)  F (Female) */

INSERT INTO [AdventureWorks2008].[HumanResources].[Employee]

           ([BusinessEntityID]

           ,[NationalIDNumber]

           ,[LoginID]

           ,[OrganizationNode]

           ,[JobTitle]

           ,[BirthDate]

           ,[MaritalStatus]

           ,[Gender]

           ,[HireDate]

           ,[SalariedFlag]

           ,[VacationHours]

           ,[SickLeaveHours]

           ,[CurrentFlag]

           ,[rowguid]

           ,[ModifiedDate])

     VALUES (2292,'1231231398','adventure-works\lyxnr',0x95EF,'Sales Representative',cast('1965-10-31' as date),'M','F',cast('1996-10-31' as date),1,34,37,1,newid(),getdate())

/* Comprueba que el registro de pruebas ha sido insertado correctamente */

SELECT [BusinessEntityID] FROM [AdventureWorks2008].[HumanResources].[Employee] WHERE [BusinessEntityID] = 2292

Test

DECLARE @return_value int

EXEC    @return_value = [HumanResources].[uspUpdateEmployeePersonalInfo]

        @BusinessEntityID = 2292,

        @NationalIDNumber = N'13412343ZN',

        @BirthDate = N'01/01/1934',

        @MaritalStatus = N'S',

        @Gender = N'F'

SELECT @return_value, COUNT(DISTINCT dbo.syscolumns.name)

FROM dbo.syscolumns

INNER JOIN dbo.sysobjects ON dbo.syscolumns.id = dbo.sysobjects.id

INNER JOIN dbo.systypes ON dbo.syscolumns.xtype = dbo.systypes.xtype

WHERE (dbo.sysobjects.name = 'uspUpdateEmployeePersonalInfo') AND (dbo.systypes.status <> 1)

AND ((dbo.syscolumns.name = '@BirthDate' AND dbo.syscolumns.colorder = 3 AND dbo.systypes.xtype = 61 AND dbo.syscolumns.length = 8 and dbo.syscolumns.prec = 23 and dbo.syscolumns.scale = 3)

OR (dbo.syscolumns.name = '@BusinessEntityID' AND dbo.syscolumns.colorder = 1 AND dbo.systypes.xtype = 56 AND dbo.syscolumns.length = 4 and dbo.syscolumns.prec = 10 and dbo.syscolumns.scale = 0)

OR (dbo.syscolumns.name = '@Gender' AND dbo.syscolumns.colorder = 5 AND dbo.systypes.xtype = 239 AND dbo.syscolumns.length = 2)

OR (dbo.syscolumns.name = '@MaritalStatus' AND dbo.syscolumns.colorder = 4 AND dbo.systypes.xtype = 239 AND dbo.syscolumns.length = 2)

OR (dbo.syscolumns.name = '@NationalIDNumber' AND dbo.syscolumns.colorder = 2 AND dbo.systypes.xtype = 231 AND dbo.syscolumns.length = 30))

De esta forma la condición de prueba del segundo valor de la consulta sera 5 (Numero campos que cumplen las condiciones especificadas), si en cualquier momento el valor no es 5, supondra que hemos alterado algun valor de configuración del procedimiento almacenado, longitud, tipo de valor, orden del campo en el store procedure, etc.

PostTest

/* Elimina el registro de pruebas insertado */

DELETE [AdventureWorks2008].[HumanResources].[Employee]

WHERE [BusinessEntityID] = 2292

/* Habilita el trigger, hay que realizarlo sobre la clausula EXEC porque la prueba no acepta 'GO', despues del borrado */

EXEC('ENABLE TRIGGER [HumanResources].[dEmployee] ON [HumanResources].[Employee]')

Comprobamos que al alterar la longitud de un campo la prueba fallaba, mientras que las dos primeras pasaban sin problemas. Se garantiza el correcto funcionamiento del SP, ya que inserta un registro de pruebas, testea el SP eliminando el registro de pruebas al finalizar y además blinda este sobre cualquier cambio en la configuración del SP.

Quiero agradecer a los asistentes su presencia, a Juan Carlos Gonzalez por la organización y porque gracias a el tenemos un evento cada poco tiempo en Santander y como no, a mis compañeros Rodrigo Corral e Ibon Landa también conocidos como Grupo Pimpinela, (haber si adivináis ¿quién es quién?…), que animaron la presentación con sus charlas y desparpajo, debido a la emoción los primeros minutos sufrí un pequeño colapso, me gusto especialmente la última parte, pude recuperar el video que hizo uno de los presentes, solo recordalo me emociono… :)

Adjunto la PPT de la charla:

Presentación en formato Powerpoint 2003.

Presentación en formato Powerpoint 2007.

Presentación en Adobe Acrobat PDF.

Como fracasar con éxito

Juan Irigoyen — Sun, 27 Sep 2009 20:21:00 GMT

Recuerdo que llevábamos varios meses encerrados en una de las habitaciones donde vivía con un par de amigos, con la intención de desarrollar software de gestión, apoyados por una pequeña empresa que quería comercializar el producto, ninguno de nosotros cobraba sueldo alguno y manteníamos un estricto horario, similar al de cualquier otra empresa, teníamos el sueño de que algún día podríamos ganar lo suficiente como para establecer una empresa que nos permitiera vivir cómodamente, el trabajo se hacía cada día más duro, pues, además de no contar con ningún incentivo, a final de cada mes, debía asumir algunos gastos derivados de nuestro trabajo, teléfono, gasolina, luz, etc.. La empresa interesada en el producto, nos surtía de material y un poco de equipamiento, algún router para la red, material ofimático y otras cosas. Al cabo de casi un año de trabajo, uno de los compañeros se fue a realizar el servicio militar y nos quedamos solo dos, encontramos la posibilidad de alquilar un local, para nosotros era prácticamente impensable, ya que no disponíamos de ningún ingreso, pero el alquiler era muy bajo y buscábamos la independencia de un lugar para trabajar más concentrados, el local era simplemente una habitación sin ventanas de unos 12 metros cuadrados ubicado en la parte baja de un edificio, decidimos arriesgarnos y sacar la licencia fiscal para poder vender software y equipamiento informático, pensamos que con que lográsemos vender dos o tres equipos al mes y algún programa, podríamos pagar el alquiler y tendríamos lo suficiente como para poder continuar con lo que verdaderamente nos gustaba, desarrollar software, fue curioso como, primero a través de un amigo nos compraron un equipo, luego otro y otro. En poco tiempo las ventas fueron incrementándose, aunque seguíamos sin un nivel de beneficios aceptable, ni siquiera sacábamos lo suficiente para asumir un sueldo. Aun con estos problemas y debido a la ilusión que teníamos por nuestra empresa, decidimos arriesgarnos y alquilar un local más grande de cara al público, solicitamos un préstamo avalados por nuestros padres y comenzamos nuestra primera aventura empresarial.

Lógicamente los gastos se dispararon, tuvimos que contratar a alguien que estuviera permanentemente en la oficina y asumir diversos impuestos y costes derivados de la actividad, acondicionamiento del local, luz, teléfono, etc., así que empezamos a salir a la calle en busca de empresas que nos permitiesen aumentar nuestros ingresos, el camino fue muy duro, establecer una simple entrevista era muy complicado ya que normalmente preferían empresas conocidas o consultoras con mayor experiencia, la mayor parte de los empresarios no veían valor añadido al desarrollo de software, preferían un paquete estándar en el que el coste del software fuese menory habitualmente descartaban cualquier tipo de desarrollo que pudiera aportarles mayor valor. Por el medio, intentamos un poco de todo, desde dar cursos de formación a empresas o cualquier colectivo, hasta llegar a acuerdos comerciales con otras entidades del sector y colaborar en el desarrollo de sus aplicaciones.

Los clientes entraban en la tienda con el fin de informarse sobre los costes de un ordenador personal y demandaban al mismo tiempo que les instalásemos todo el software necesario, (sistema operativo, paquete de ofimática, antivirus, etc.), por supuesto totalmente 'gratis', yo me indignaba con esto, pues la mayor parte rehusaban a realizar la compra en nuestra empresa debido a que otras, les ofrecían estos servicios de “valor añadido”.

Recuerdo que yo entonces era un “soñador”, soñaba con tener una empresa, con trabajar duramente y en pocos años, aspiraba a vivir cómodamente, cuando me hablaban de dinero yo les respondía que para mí no era importante, que el dinero era lo de menos, el dinero ya vendría después del trabajo, nunca me preocupo especialmente. Después de un tiempo, me di cuenta de que la empresa había tomado un camino muy distinto del que tenia planeado, nos habíamos convertido en una empresa de informática habitual y habíamos dejado de lado el desarrollo de software, lo único que podría diferenciarnos y aportarnos valor. Finalmente después de un tiempo y muchos problemas, abandone la empresa.

Este fracaso, me permitió más adelante, reflexionar sobre los errores que cometí.

Cuando conformamos la empresa no teníamos una idea clara del negocio, teníamos una idea general, pero no contábamos con un proyecto claro, ni siquiera con un pequeño estudio de mercado, nos lanzamos con un desconocimiento total, carecíamos de un plan estratégico, no teníamos un sector determinado al que atacar, ni una idea clara que seguir, tan solo, hacer lo que fuera para subsistir y luego, dependiendo de la situación que alcanzásemos, tomaríamos posteriores decisiones.

En principio, la idea era desarrollar software de gestión y más adelante, aprovecharlo para realizar algún vertical. Desarrollamos un programa similar a otros que ya existian en el mercado y que, aunque no era tan completo como el nuestro, cumplía con los objetivos básicos y logicamente al ser mas sencillo también era mucho más barato.

Destinamos la mayor parte de los recursos a desarrollar el software y posteriormente intentamos comercializarlo. Este fue uno de los mayores errores que cometimos, realizamos un producto, sin analizar el mercado ni a la competencia, sin recursos económicos, sin un sponsor, asumiendo que, como nuestro software sería mucho más completo que los demás, se vendería sin problemas. Es decir, primero producimos el producto y posteriormente intentamos comercializarlo. Al cabo de unos años y debido a este fracaso, deducí que lo mas adecuado seria invertir el orden, “vender y luego producir”, curiosamente el sistema LEAN se basa en una idea similar, fabricar en base a la demanda, es decir ‘vender antes de producir’.

No teníamos un plan comercial viable. Contar con un estudio de mercado, para atacar a sectores en los que la competencia no estuviera presente, hubiera sido mucho más inteligente que intentar competir con un producto que ya existía en el mercado contra empresas solventes, mucho mejor posicionadas que nosotros, en un mercado que dominaban desde hacía algunos años. Estoy convencido de que si hubiéramos dedicado un poco de tiempo a estudiar y analizar en detalle el mercado, podríamos haber llegado a tener una idea clara de negocio, posteriormente lo pude ver claro con empresas que triunfaron, porque orientaron sus desarrollos a hacer programas de gestión a Concesionarios, Hoteles, Abogados, Dentistas y otros sectores que no disponían de ninguna solución de software.

El desconocimiento del mercado hizo, que cuando terminamos el desarrollo, nos encontramos con que la mayor parte de nuestros posibles clientes, se había decantado por otros productos más sencillos y baratos. La competencia opto por hacer todo lo contrario, desarrollo un producto sencillo que no requiriese mucho tiempo y lo puso en el mercado un precio mucho menor, de esa manera, comenzaba a retornar parte de la inversión y poco a poco iban aumentando la funcionalidad, además, sus clientes se convertirían en usuarios potenciales de sus versiones más avanzadas que habitualmente tenían precios mucho más elevados. Esto les aporto feedback para mejorar sus versiones, ‘me acuerdo de Scrum con las entregas continuas de software…’, la penetración era mucho más rápida, porque al cliente no le importaba desembolsar un poco de dinero por el software y posteriormente si sus requerimientos aumentaban podrían ampliar a versiones más avanzadas, todo esto, hizo que en poco tiempo nuestro producto fuese menos competitivo. La estrategía comercial de nuestros competidores fue mucho mas acertada.

Los programas que realizaba la competencia, cubrían tan solo aspectos básicos que la gente necesitaba, la mayor parte de los clientes empezaba a trabajar con computadoras personales con lo que un programa muy complejo hubiera fracasado. Nos ocurría a menudo que cuando alguien veía nuestro programa comentaba: ‘es excelente, pero tiene demasiadas opciones…’, a mi no me hacen falta tantas, nunca modificare un informe, no sé si podre manejarlo. Resulto que nuestro mercado, no estaba preparado para un producto tan complejo. Nos olvidamos de estudiar los requerimientos de los clientes, en lugar de esto, intentamos hacer un programa que cubriese todas las necesidades existentes, esto hizo que nuestro producto fuese mucho más complejo de entender y manejar.

Nos olvidamos de evaluar el tiempo de desarrollo, el tiempo es un factor determinante, el desarrollo duro más de dos años, en este periodo, la competencia se hizo con un mercado potencial de clientes muy grande y que mas adelante fue imposible de recuperarar, la mayoria ya se había habituado a su uso, y nuestros competidores iban incrementando la funcionalidad en base a la demanda de los clientes.

Como necesitábamos dinero para mantener la empresa y no logramos que el software desarrollado se vendiese como queríamos, intentamos buscar una empresa que estuviera interesada en comercializar el producto, viajamos a Madrid y se lo ofrecimos a varias, la mayoría rehusaba, pues ya contaban con algún producto que si ser tan completo, conocían perfectamente y les resultaba fácil adaptarlo a las necesidades de sus clientes, aunque hubo un par de ofertas serias de compra que pasaban por hacerse con todo el código fuente y controlarlo completamente. Las ofertas fueron de bastante dinero, pero no quisimos renunciar a su control, así que lo descartamos. Si hubiéramos vendido el producto, el dinero nos hubiera permitido continuar, desarrollando la empresa durante unos años cómodamente y podíamos haber dedicado otros recursos a realizar otros productos, pero no queríamos desprendernos de un programa que considerábamos como uno de los mejores del mercado y éramos demasiado ambiciosos, queríamos hacer mucho en muy poco tiempo.

A partir de aquí, para subsistir nos dedicamos a vender hardware, dar soporte y mantenimiento a empresas, formación, instalación de redes, etc., en fin todos aquellos servicios que dan las empresas de informática, pero en esto, no aportábamos ningún factor diferenciador importante.

Además de esto, nuestra inexperiencia hizo que en varias ocasiones, aceptásemos proyectos en los que posteriormente descubrimos que los clientes eran auténticos profesionales del engaño, aceptaban el presupuesto sin pestañear, pero a la hora de cobrar descubríamos que muchos nos engañaban, recuerdo que hubo un proyecto, en el que después de finalizarlo nos enteramos que el cliente estaba en la ruina y que debía dinero a mucha gente realizando prácticas similares, no creáis que fue solo un caso, sufrimos varios, alguno de ellos, de importantes sumas de dinero que nos complicaron mucho la vida. La importancia de realizar un estudio del cliente es fundamental, cobrar a la firma de un contrato un porcentaje del proyecto y asegurarnos de la solvencia del cliente son aspectos muy importantes que se deben realizar antes de aceptar cualquier proyecto, existen empresas como Crédito y Caución que aseguran el pago de un determinado porcentaje de la cantidad facturada a cambio de un porcentaje de la operación.

No logramos convencer a las empresas de que nuestros servicios ofrecían valor añadido, les ofrecíamos lo mismo que las demás, algo que los demás hacían igual que nosotros. Y, ¿Por qué una empresa va a confiar en alguien que no conoce y que además no ofrece nada nuevo ?.... Estaba claro, nuestro objetivo inicial había variado, ahora ya no desarrollábamos software, tan solo hacíamos lo que fuera para subsistir y nos olvidamos del verdadero objetivo de nuestra empresa.

No supimos analizar bien nuestros costes, cuando comenzamos la actividad nos dimos cuenta de todos los gastos que debíamos soportar, pago de autónomos, IAE, gastos de luz, agua, teléfono, nóminas, seguros sociales, mobiliario, acondicionamiento del local, declaración de IVA, seguro del local, asesoría contable, alarma, gastos por líneas de crédito y transacciones bancarias, recuerdo que pusimos un aparato para pagar con tarjeta, nos enteramos que VISA llega a cobrar un 4 % por cada transacción que realicen los clientes, recuerdo que algunos productos informáticos apenas tenían ese marguen comercial. Os aseguro que, por pequeño que sea el negocio, la lista de gastos es interminable, y claro, podéis esperar ‘sentados’ que los Ayuntamientos y otros Organismos Oficiales os ayuden, lo único que les interesa es ampliar sus ingresos. Así que debéis tener claro todos los gastos antes de comenzar vuestra actividad.

No contábamos con una estrategia comercial seria, no podíamos permitirnos un agente comercial especializado, vender software o servicios informáticos requiere profundos conocimientos técnicos y comerciales, encontrar un comercial en este sector es muy complicado, al carecer de medios, hizo que tuviésemos que dedicarnos a realizar esta labor, carecíamos de la suficiente experiencia, el desconocimiento del perfil de los empresarios de la zona, que no creían como yo, en el valor que podría aportarles el software a medida, hizo que la mayor parte de las empresas rehusasen a aceptar nuestros servicios y que posiblemente un comercial con experiencia podría haber triunfado donde yo fracase.

No contábamos con un sponsor que financiase nuestro proyecto y desde luego no teníamos medios económicos, con lo que solamente subsistir mes a mes ya era un logro para nosotros, pero siempre nos obligaba a estar en la cuerda floja, si un mes no realizábamos el objetivo de ventas, la empresa se tambaleaba y varias fueron las veces que estuvimos a punto de cerrar, dedicábamos todas nuestras energías a llegar a fin de mes.

No dedicábamos tiempo a innovar, a poner en la mesa ideas diferentes y realizar algo que nos distinguiese de nuestros competidores. Esto hizo que nos incorporásemos a un mercado en el que nuestros competidores tenían mucha ventaja, disponían de mayor experiencia y habitualmente contaban con una cartera de clientes. La mayoría no tenían que preocuparse por subsistir, con lo que podían contar con más recursos para competir en el mercado.

Debido al poco tiempo que teníamos, empezamos a dejar de formarnos, tan solo dedicábamos un poco de tiempo cuando podíamos, así que con el tiempo fuimos perdiendo valor en nuestro mercado, pero nuestro trabajo no daba para más, así que pasamos de ser desarrolladores a ‘empresarios de poca monta'.

Los problemas económicos, administrativos y comerciales fueron aumentando y hacían que dedicásemos prácticamente todos nuestros recursos a subsistir y apenas teníamos tiempo para pensar, no nos paramos a ver cómo mejorar, como hacer cosas que nos aportasen valor, nos movíamos por impulsos, a petición de la demanda de algunos clientes que tan solo nos permitían subsistir y con el único objetivo de llegar a fin de mes. Nos fue prácticamente contratar personal adicional, desde técnicos especializados hasta comerciales con conocimientos del entorno, esto hacia que tuviésemos que hacer de todo, desde barrer hasta encargarnos de realizar presupuestos de equipos informáticos, con lo que fuimos dejando en otro plano aquello que nos podría diferenciar de los demás.

No logramos convencer a otras empresas del sector de que la colaboración podía hacer que estableciendo ciertas reglas de compromiso, nuestros márgenes comerciales mejorasen y ofreciesen mayor valor añadido. La incapacidad para llegar a acuerdos con nuestros competidores hizo que tuviésemos que renunciar a la mayoría de la venta de software y esto elimino un mercado que podría habernos ayudado en nuestros objetivos.

La parte positiva, es que al final, este y otros fracasos, me ayudaron a lo largo de toda mi trayectoria profesional a entender mejor cómo se comportan los mercados, la importancia del cliente y la competencia, de la colaboración, del trabajo en equipo, de la innovación, que de otra forma, difícilmente hubiera podido aprender. He tenido el privilegio de poder “intentarlo”, algo que muchas personas ni siquiera se han atrevido o que su condición económica no se lo permitirá a lo largo de su vida, he aprendido mucho de las personas que nos rodean y que los errores, nos enseñan aspectos que de otra forma, serian muy difíciles de aprender, por eso pienso, que aquel que ha fracasado, tiene más valor que él no lo ha hecho nunca, los errores del pasado, nos enseñan cómo mejorar nuestro futuro y a no cometer los mismos errores, de ahí la importancia del conocimiento de la historia.

He aprendido que en la colaboración y en el valor de las personas está la clave de todo, en que pensar antes de hacer las cosas es mucho más importante que hacerlas y luego pensar…, aunque a veces haya que arriesgarse, que el trabajo en equipo, la formación continua, la innovación y por supuesto, ‘los fracasos’, son aspectos que conducen al éxito.

Este es un sector proclive al cambio y la innovación y tenemos un mercado inmenso esperando a ser explotado, así que animaros, no tengáis miedo al fracaso, pero cuidado, no os engañéis, nadie os va a regalar nada, el dinero es el primer objetivo de una empresa, que una empresa tenga éxito pasa solo por una cosa: ganar dinero. Si la empresa no gana dinero, no podrá alcanzar sus objetivos, para poder establecer una empresa debemos tener un plan establecido que asegure la viabilidad de esta, desde el principio, sobre todo al inicio, que es, cuando más falta nos va a hacer.

Mis fracasos me han enseñado mucho, si tuviera que poner en marcha una nueva empresa de desarrollo de software, desde luego haría cosas muy diferentes, algunas de ellas serian:

Buscar una idea y desarrollarla, intentar que esta sea innovadora o que aporte algo que marque la diferencia frente a vuestros competidores, establecer una línea de negocio clara realizando un plan estratégico con su análisis de costes y beneficios, estudiar las ventajas e inconvenientes del negocio, analizar cómo, después de un tiempo, podéis dotar a vuestra idea de mayor valor añadido, trazar un par de planes alternativos por si no funciona como teníais planeado, realizar un pequeño estudio de mercado estudiando a vuestros posibles clientes y el entorno en el que se encuentran, si es posible contar con alguno de ellos para comenzar, compartir los riesgos con un sponsor, estudiar a vuestra competencia antes de actuar y el mercado al que va destinado vuestro producto, compartir vuestra idea con alguna persona con experiencia en el sector para obtener otros puntos de vistas y evaluar los posibles riesgos que pueden aparecer y que de otro modo desconoceríais, hay que tener en cuenta que cuando alguien tiene ilusión por una idea solo ve la parte positiva, debemos contar con opiniones externas para contar con un punto de vista mas objetivo y me atrevería a decir 'mas real'. Así mismo, es muy importante rodearse de un equipo adecuado, contar con personas preparadas que sean innovadoras, proclives al cambio y que compartan la visión de la empresa. Es también muy importante que los miembros del equipo mantengan una buena relación y tengan un nivel de educación aceptable, pues el acercamiento siempre da lugar a roces. En el área del desarrollo, el tiempo es un factor determinante, apostar por desarrollos de larga duración es un riesgo muy alto, es mucho mejor resolver las necesidades básicas y posteriormente ir incrementando la funcionalidad y optimizando el producto, esto permitirá retornar la inversión más rápido y disminuir vuestros riesgos.

En resumen, ‘pensar antes de actuar’, ‘vender antes de producir’, ‘innovar’, ‘apostar por el valor del equipo y la colaboración', ‘reducir vuestros riesgos’, 'tener en cuenta que el tiempo, es un factor determinante'.

Espero que mis experiencias os ayuden a no cometer los mismos errores, si lo logro, habré fracasado con éxito.

Cuestión de velocidad…

Juan Irigoyen — Tue, 15 Sep 2009 14:48:00 GMT

Creo que todos los desarrolladores, alguna vez hemos estado obsesionados con la velocidad, la velocidad es un tema importante, incide en prácticamente todas las facetas de la computación, realizar un programa veloz normalmente marcará el éxito o el fracaso de un desarrollo, Google es un claro ejemplo de esto. Si lo comparamos con la velocidad de un coche, la verdad es que no tiene mucho que ver, prácticamente todos los coches pueden viajar a 100-120 km/hora, lo suficiente para realizar cualquier viaje, por grande que sea.

En el ámbito de las conexiones de red comenzamos con velocidades de 50 bps que utilizaban los antiguos teletipos, en cambio ahora la mayoría de los canales de comunicaciones, desde una simple Ethernet con velocidades de 1000 Mbps full dúplex, hasta las Wifi que con la nueva norma n podrán llegar a los 300 Mbps. El avance es espectacular hemos pasado de 300 bps al descargarnos algún archivo de las primeras BBS a disponer de ADSL con velocidades de hasta 20 Mbs.

Me pregunto que pasara cuando la velocidad de internet, llegue a ofrecernos una velocidad suficiente para poder ejecutar cualquier tipo de servicio con fluidez, y como sucede hoy en día con las redes de fibra en la que ni los discos duros más veloces sean capaces de procesar. Existe hoy en dia algunos lugares, como Japón, donde se pueden conseguir velocidades de hasta 100 Mbps, lo suficiente como para hacer casi cualquier cosa, es cierto que para ello todas las infraestructuras de internet tendrán que readaptarse, pero a la velocidad que esto se mueve apenas notaremos el cambio.

Pese a que el incremento de la velocidad ha sido paulatina, las necesidades han ido aumentando quizás hasta más que la propia velocidad, pasamos de descárganos algún pequeño fichero de 15 Kb desde las antiguas BBS a varios Gygabytes de alguna aplicación, el video bajo demanda, las redes P2P, voz Ip y otros servicios han ido surgiendo a medida que la velocidad a permitido su funcionamiento. Los avances de velocidad en los procesadores, la utilización de múltiples núcleos, la incorporación de grandes procesadores en las tarjetas de video han permitido que en poco tiempo hayamos pasado de programas simples a modernas y complejas aplicaciones que nos permiten trabajar con objetos 3D, video, etc.

Sin embargo, después de tantos avances, algunos programas parecen cada vez más lentos, creo que todavía hoy en día el área del desarrollo en general no ha sido capaz de asumir la velocidad del hardware, el ejemplo más claro es que las aplicaciones de 64 bits todavía no han despegado. Actualmente se acaba de presentar la programación paralela destinada a aprovechar todos los núcleos de los procesadores que nos permitirá conseguir mejores ratios de rendimiento y aprovechar todas las ventajas de nuestro hardware, veremos cómo evoluciona y si le sacaremos el partido que merece.

Me pregunto, cuándo internet permita conseguir velocidades de 100 Mbps o más como en Japón, si la velocidad dejara de tener tanta relevancia como hoy en día, la mayoría de los programas en Internet, incluso ayudados de nuevas tecnologías como Ajax, Silverlight, Flex y otras, todavía no permiten una interacción muy fluida con los usuarios, si bien han mejorando mucho, pero en poco tiempo, creo que tal y como sucede con los coches esto dejara de tener tanta relevancia. Pienso que estará al alcance de todos obtener la mayoría de servicios de una forma fluida, desde tv bajo demanda con alta calidad, algo que hoy en día ya es una realidad con la mayoría de proveedores de Internet que ofrecen servicios de TV, manejar objetos 3D, acceder a recursos compartidos como si de una red Ethernet se tratase, utilizar servicios de voz IP sin interferencias y todo el conjunto de servicios que hoy en día utilizamos mejorados por las capacidades de la red.

En este supuesto, para el que creo, no queda mucho tiempo, pienso que las arquitecturas volverán de nuevo a reinventarse ya que la capacidad de comunicación, permitirá que cualquier programa tanto Web como de escritorio tenga una capacidad de comunicación prácticamente ilimitada similar a nuestras redes de trabajo locales.

Estoy convencido de que el Software as Services (SAAS) es el futuro, y la mayor parte de los programas que existen, pasaran tarde o temprano a alojarse en la red, este paso masivo de aplicaciones marcara un antes y un después en nuestra vida, ya que la mayoría de los servicios pasaran a administrarse por especialistas y el coste de su mantenimiento bajara progresivamente, esto permitirá que de algún modo nos podamos abstraer de las necesidades de hardware y software necesario (actualizaciones, copias de seguridad, gestión de errores e incidencias, mantenimiento, etc). Creo que estos servicios serán mucho más baratos que contar con una infraestructura propia y por ello serán utilizados de forma masiva.

Uno de mis sueños y creo que el de mucha gente es la de desarrollar un programa sin demasiado esfuerzo que sea multiplataforma y que funcione por cualquier canal de comunicación establecido. Espero que con el aumento de la velocidad y de la progresión del SAAS esto se convierta en una realidad muy pronto.

En España, como no podría ser de otra forma, seguimos por debajo de la media de los países Europeos en velocidad y precio del ADSL, increíble, nos gana hasta Portugal, espero que poco a poco nos vayamos poniendo al día, ya que la importancia de la velocidad en Internet va a ser un punto clave para que podamos evolucionar con todas estas tecnologías. Os dejo la tabla comparativa del 2008.

Pienso que el Grid Computing se vera tambien beneficiado por el aumento de velocidad, como sabeis el Grid Computing es una tecnología que permite acceder a una gran capacidad de proceso y otros recursos utilizando equipos distribuidos, tal y como realiza Google con sus búsquedas. Uno de los ejemplos más antiguos es el proyecto SETI para la búsqueda de vida extraterrestre que utiliza ordenadores personales de la gente que quiera participar en el proyecto, para procesar datos, creo que el aumento de velocidad hará que esta tecnología vaya asentándose cada vez más.

Parece que está de moda hablar de la Nube, y a mi juicio todo indica que Azure será el primer paso para asentar todas estas ideas que comenzaron hace algunos años cuando los Web Services empezaron a tomar mayor relevancia y que ahora debido sobre todo al aumento de la velocidad se pueden hacer realidad.

Todo indica que Internet continuara progresando de forma exponencial en los próximos años y su importancia será cada vez mayor, en pocos años, quizás, hasta cobre vida propia…, ya hay televisiones que permiten conectarse a internet, pienso que dentro de poco se conectaran desde los coches hasta las cafeteras y lavadoras, veremos lo que nos depara el futuro.

Aún con esto, sigo teniendo mis dudas:

¿Dejara de tener importancia la velocidad tal y como ha pasado con los coches o el aumento de los requisitos seguirá aumentando conjuntamente con la mejora de la velocidad como ha sucedido hasta ahora?

¿Se asentara definitivamente el Grid Computing y dejaran los grandes servidores de tener tanta importancia?

¿Dejaran de utilizarse masivamente los protocolos de comunicación soap y tecnologías como http y xml, para dejar paso a protocolos más avanzados en forma binaria?

¿Lograra el SASS comerle el terreno a las aplicaciones locales y se asentara definitivamente para convertirse en la plataforma más utilizada?

Espero vuestras opiniones...

Un saludo.

Innovar sí, pero como…

Juan Irigoyen — Sun, 13 Sep 2009 23:55:00 GMT

A raíz del post de Rodrigo hablando sobre innovación, me he animado a escribir este artículo, la verdad es que el tema me apasiona, recuerdo una conferencia sobre trabajo e innovación hace un par de años, en el que el ponente , un Consejero de Telefónica y varias empresas importantes de España, hablaba sobre la necesidad de innovar, en concreto comento un caso de una Empresa Catalana galardonada con un premio Europeo a la entidad más innovadora, comentaba que la empresa disponía de un equipo de personas que se pasaban el día estudiando la viabilidad de nuevos productos, los desarrollaba y empezaba a comercializarlos, y cuando veían que el producto llegaba al máximo de ventas, es decir su curva de ventas comenzaba a descender automáticamente lo retiraba del mercado, recuerdo que a mí y creo que a muchos otros, se nos quedo cara de tontos, pensando cómo, cuando un producto alcanza su máximo de ventas lo abandonaban, la idea subyacente es sencilla, era en este momento cuando la competencia y otros factores externos empezaban a comerles terreno, y porque luchar contra algo imparable, siempre habría alguien que lograría realizar el producto más barato e incluso mejor, simplemente lo retiraban y pasaban a dedicar todos sus esfuerzos a desarrollar nuevos productos.

Recuerdo una reunión en una empresa, donde se habría un debate para ver cómo entre todos los componentes, la mayor parte responsables de cada uno de los Departamentos podían aportar ideas para intentar mejorar una situación delicada, la mayor parte de los componentes no decían nada, en cambio, algunos empezaron a lanzar ideas, mejorar el departamento comercial, intentar fabricar otros productos con los medios productivos que tenían, abrir nuevos mercados, eliminar los canales de distribución para llegar al cliente final y obtener mayores beneficios, realizar acuerdos con competidores o con empresas relacionadas con el sector, mejorar la calidad para poder acceder a mercados más exigentes, adquirir alguna empresa de la competencia, etc. La mayor parte de estas ideas eran rebatidas rápidamente por algunos miembros descartándolas rápidamente aduciendo que algunas se habían puesto en marcha y habían fracasado años atrás, que no veían su rentabilidad inmediata y que otras simplemente eran totalmente erróneas por el desconocimiento de las personas que las planteaban y que desconocían el mercado. Al final todas y cada una de las ideas se fueron descartando y se llego a la conclusión de que lo mejor sería ‘ahorrar costes’, si ahorran costes podrían continuar manteniendo un nivel de beneficios aceptable y aguantar el tirón en espera de tiempos mejores. Para ello deberían optimizar algunos procesos con los que trabajaban, reducir los gastos de algunos departamentos, paralizar ciertas inversiones, seguramente reducir parte de la plantilla, etc.

No digo que en la reunión no se llegaron a conclusiones que pudieran aportar mejoras a la empresa, pero lo cierto es que la palabra innovación se esfumo… y ¿por qué?, por el miedo a nuevas inversiones de dudosa rentabilidad, a apostar por algo sin la suficiente seguridad, en resumen por el miedo al fracaso.

Creo que este es un claro ejemplo de lo que ocurre con muchas empresas actualmente, se agarran a un clavo ardiendo con tal de no cambiar su negocio, la resistencia al cambio es el mayor enemigo de la innovación, aceptar que un negocio que ha funcionado durante muchos años, ya no es rentable y que hay que hacer cosas diferentes es algo muy difícil de asumir. Incurrir en proyectos que pueden fracasar de dudosa rentabilidad es algo que la mayoría suele reusar. Según mi opinión, creo que la mayor parte de las ideas que se presentaron seguramente podrían haber fracasado, pero estoy seguro de que si entre todas, solo una llegase a buen fin, seguramente la situación de la empresa hubiera cambiado considerablemente.

Para Innovar debemos arriesgarnos, debemos escuchar las ideas de los demás por absurdas que estás nos parezcan, debemos eliminar aquellas reglas que dicen, porque hacerlo de otra forma si de esta siempre nos ha funcionado bien o planteamientos como, ‘bueno, nosotros no vamos muy bien pero fíjate en los demás...’.

Para Innovar debemos dedicar parte de nuestro tiempo productivo a pensar cómo hacerlo mejor, como sacar valor añadido, como mejorar nuestro trabajo, si no nos paramos a pensar cómo mejorar, jamás lo haremos.

Desgraciadamente las empresas suelen tener un objetivo que les impide ver más allá, ‘la rentabilidad de los proyectos’, si de antemano no presentamos un proyecto rentable será muy difícil apostar por él, convencer de esto a los directivos de las empresas es algo muy difícil de conseguir. Lo primero que hacen es preguntarse: ya, pero y ¿si no sale bien?… ¿cuánto dinero nos va a costar?, estoy desacuerdo en que la rentabilidad es un factor muy importante, pero para innovar tampoco es necesario realizar grandes inversiones, hay muchas formas de minimizarlas realizando proyectos pilotos, maquetas, simulaciones, estudios de mercado, o mejor vender la idea, convencer a un sponsor y llévala a cabo, si, se que suena como un sueño de hadas pero muchos proyectos han conseguido ver la luz siguiendo este método, comparte el beneficio y disminuye tus riesgos, pero si todo esto no es posible, siempre llegara un punto en que habrá que arriesgarse. Si aún así, no somos capaces de llevar a cabo el proyecto solo nos quedara una cosa por hacer,”nada”, esta es la opción más utilizada, y como es gratis y no cuesta ningún esfuerzo, a esperar como el avestruz que entierra su cabeza en la tierra cuando viene un león…

Todo esto, me hace preguntarme una cosa. ¿Somos los desarrolladores innovadores?, en mi opinión y después de más de 20 años de profesión puedo afirmar que no. Creo que la mayoría de nosotros destinamos la mayor parte de nuestro tiempo a aprender a utilizar nuevas tecnologías para no perder el tren, el constante bombardeo de las grandes empresas de Software como Microsoft, Google, Adobe y algunas otras, hace que estemos constantemente estudiando lo que ellos nos proponen, en mis 20 años, tan solo he realizado 3 o 4 proyectos que pudiesen definirse como innovadores y solo por la aplicación temprana de nuevas tecnologías de reciente aparición, en contraposición somos muy abiertos al cambio, estamos siempre en predisposición de adoptar nuevas tecnologías y cambios, pues nuestra profesión así lo requiere, pero realmente apenas innovamos nada, no hacemos nada diferente, tan solo copiamos aquello que nos proponen las grandes empresas de software, y en el mejor de los casos a veces lo mejoramos un poquito. En mi opinión para innovar deberíamos renunciar a estar siempre a la última y destinar parte de nuestro tiempo a proponer ideas, escoger alguna interesante y llevarla a cabo, en lugar de dedicar todo nuestro tiempo a aprender lo que nos proponen los demás, si bien es necesario estar al día, para no cometer el error hacer algo que los demás ya han construido, un error muy frecuente en nuestra profesión.

Deberíamos también dejar a un lado muchas de las reglas que aplicamos, cuando desarrollo, sobre todo en estos últimos años, tengo un pensamiento que constantemente me dice “demasiadas reglas”, el desarrollo es cada vez menos fluido, menos intuitivo, esto, me hace preguntarme si estaré haciendo las cosas bien, en mi opinión demasiadas reglas limitan la innovación ya que en muchos casos la rigidez de algunas de ellas y el tiempo que destinamos a aplicarlas, evitan que destinemos nuestros recursos a innovar o ser mas creativos.

Debemos hacernos estas preguntas de forma habitual, ¿Cómo puedo mejorar?,¿Cómo puedo hacerlo más rápido?, ¿Cómo puedo sacar mayor valor añadido?, y dedicar parte de nuestro recursos a responder a estas preguntas.

En general, el desarrollo de software de las grandes empresas de desarrollo es un área muy innovadora, ellos han entendido mejor que nadie la necesidad de innovar constantemente y por ello son ellos y no nosotros los que logran el éxito, y no me refiero solamente a obtener un buen salario…

El área del desarrollo de software es un mercado sumamente competitivo, pero con gran potencial, no hay más que fijarse en empresas que en pocos años pasan de no ser nada a cotizar en bolsa, en ver cuántos productos nuevos aparecen y otros que en poco tiempo desaparecen, como cambiamos de un año para otro nuestra forma de trabajar, como tenemos que obligatoriamente apostar por una formación continua para poder mantenernos en este mercado, pero no lo hacemos porque somos innovadores, lo hacemos porque es un requerimiento de mercado, me pregunto cuántos desarrolladores de los que escribimos aquí o de los que nos leen, realizan proyectos innovadores si no es por petición de un cliente, creo que muy pocos son los que llegan a alcanzar este status, que envidia tengo de Miguel Llopis que trabaja en el desarrollo de nuevas tecnologías y puede destinar gran parte de su tiempo a ser innovador.

Para innovar debemos trabajar en equipo, las relaciones personales son fundamentales para poner una idea en funcionamiento, saber convencer, incentivar y hacer participes a la gente de un equipo con una idea es algo fundamental, y estoy desacuerdo que la mayor parte de las veces hace falta la figura de un Líder que incentive y mantenga unido al equipo para llegar a obtener mejores resultados, si bien tener un objetivo común en el que todos los componentes creen puede hacer que esta figura se reparta entre todos los miembros del equipo, en un equipo innovador todos deben escuchar y debatir las ideas de los demás, la política de la empresa debe otorgar libertad en la toma de decisiones, conozco muchas personas a los que se les limita la capacidad de innovación en pro de la rentabilidad, así pues es necesario que todos desde el primero al último apueste por la innovación.

La necesidad es también un factor que nos llama a innovar, solo cambiamos cuando tenemos la obligación de mejorar, ponemos en marcha nuevas ideas cuando las que tenemos no sirven o no nos aportan lo suficiente, desgraciadamente en la mayoría de los casos, es, en estos momentos cuando es demasiado tarde.

Es curioso ver los gráficos de las patentes en España, está generalmente admitido que el número de solicitudes de patentes originadas en un país constituye un indicador bastante significativo de la situación de su sistema de I+D+I,

Fuente: http://www.oepm.es/cs/Satellite?c=Page&cid=1213455385201&classIdioma=_es_es&idPage=1213455385201&pagename=OEPMSite%2FPage%2FtplListaDocumentos&numPagActual=1

BSH Electrodomésticos España es la primera empresa industrial en solicitar patentes, con un total de 65 en 2008.

Solo la Empresa IBM, la que más patentes realizo en 2008 tiene 4000, observando estos gráficos no me estraña que nos encontremos en la situación actual, lo extraño es que no hayamos llegado antes.

Una cosa esta clara, España tiene mucho camino que recorrer y actualmente estamos a la cola de la mayor parte de países desarrollados, debido a que las políticas de formación y de I+D+I desde el gobierno y las empresas han sido desastrosas.

En estos tiempos que corren y creo que en un futuro cercano si no somos capaces de innovar, nunca llegaremos a tener éxito y tarde o temprano fracasaremos, el miedo al cambio, el riesgo de invertir en nuevas ideas nos impiden innovar, hay que enfrentarse a estos miedos para poder llevar a cabo nuevas ideas, la mayor parte seguro que fracasaran, pero con que tan solo una llegue a buen término merecerá la pena.

Creo que el fracaso conduce al éxito, hace muchos años que leía un artículo del Newsweek que decía que los empresarios de EEUU preferían contratar a alguien que hubiera establecido tres empresas y hubiera fracasado que a un candidato que tuviese un Curriculum excelente.

Innovar es hacer cosas diferentes, arriesgarse, no temer a fracasar, cuestionarse que aquello que funciona hoy, no lo hará mañana o que siempre se puede mejorar, y como decía Albert Einstein, si quieres cambiar algo no hagas siempre lo mismo…

¿Qué opináis?

Sobre el porqué utilizar metologías Agiles (Scrum) no es una moda...

Juan Irigoyen — Tue, 14 Jul 2009 12:54:00 GMT

Escribía el otro día David Arrollo (Ddaz) sobre si las metodologías agiles, en concreto Scrum estaban de moda, me he animado a realizar este post para plasmar mi opinión sobre este tema.

Como sabéis las metodologías ágiles evolucionaron sobre el año 1990 en respuesta a los métodos estructurados y estrictos extraídos de los modelos de desarrollo en cascada, aunque sus principios se establecen en el año 1986, no es hasta hace unos pocos años que se empieza a adoptar por multitud de empresas.

Pienso que la adopción masiva de metodologías en el área del desarrollo de software no es una moda tal y como comenta Fran en su blog, creo que cada vez mas empresas están adoptando estos métodos de trabajo con el único fin de mejorar su gestión optimizando sus procesos para intentar lograr ser más competitivos. Hasta hace relativamente poco a la mayoria de empresas todo esto les daba igual, sobre todo debido a la bonanza económica, pero los mercados, cada vez más difíciles y competitivos, y la crisis actual estan provocando que algunas entidades se centren en la búsqueda del ahorro de costes y la mejora de la rentabilidad y poco a poco estas empresas se están dando cuenta de que mejorar su gestión interna es un aspecto cada vez mas importante, que puede llegar a marcar la diferencia, una ahorro de tan solo un 10-20 % puede hacer que la empresa sea competitiva o no.

No hace muchos años el conocimiento de los procesos en las empresas era aglutinado por unos pocos, algunas se han comenzado a dar cuenta de que el verdadero valor recae en todas las personas que la conforman y que en la mayor parte de los casos son los operarios de las maquinas, los técnicos cualificados y personas cercanas a los procesos los que más saben del trabajo que están realizando y consecuentemente los que conocen mejor como poder mejorarlo. Esta situación está provocando que las empresas empiecen a contar con la opinión de estas personas que antes eran meros ejecutores de los procesos para formar parte activa en la toma de decisiones.

Algunas metologías de trabajo, en este caso "Scrum", ya que es la mencionado por Fran, explota precisamente estas ideas, basan su gestión en la creencia de que su valor esta en las personas que conforman los equipos de trabajo tal y como comento en el post y la reducción de la burocracia apoyada en la simplicidad.

Pero esto no es nada nuevo, en los sistemas Lean, los equipos de mejora continua, trabajan con la misma idea que la mayor parte de las metologías agiles, intentan eliminar la burocracia y optimizar los procesos en base a sus objetivos más cercanos ayudados por las personas que realmente los conocen en profundidad.

Algunas empresas de desarrollo de software están comenzando a adoptar una metodología por necesidad comercial, porque para sus clientes es un requisito, muchos organismos oficiales están comenzando a demandar la adopción de metodologías de trabajo cuando contratan un desarrollo, pero esto no es por moda, si no por necesidad, por la necesidad de evitar errores cometidos en el pasado, con aplicaciones que han sido un autentico fracaso, que han costado autenticas barbaridades, que han pasado de una empresa a otra y nunca han funcionado, estos errores y fracasos están haciendo que muchos de estos organismos hartos ya de "tirar" el dinero en informática empiecen a exigir la adopción de mejores sistemas de trabajo que les aseguren la viabilidad de sus proyectos.

Otras entidades realizan la adopción simplemente, porque obtener un certificado en una determinada metodología les hará distinguirse de sus competidores. En este último caso lo comparo con la ISO 9001, conozco varias empresas que únicamente disponen de este certificado únicamente por una razón comercial o porque alguno de sus clientes se lo exige, que lejos de hacerles mejorar tan solo les aporta burocracia y que al final desgraciadamente certificarse se convierte en una cuestión de dinero, con dinero se puede contratar más personal para gestionar todos los requisitos, se puede invitar a comer a buen restaurante al responsable de la certificación e incluso en algunos casos se puede llegar a "comprar" la certificación, he visto empresas con la ISO 9001, que ni siquiera son capaces de gestionar el stock de su almacén o encontrar un pedido en sus ficheros , desgraciadamente esto ocurre con multitud de empresas y hace que al final el valor de estas "certificaciones" quede en entredicho. También he visto algunas empresas que le han sacado valor a este tipo de certificaciones, con ellas han aprendido a gestionar de forma más adecuada sus recursos. En cualquier caso con certificación o no, todas tienen una razón para su adopción, si bien es cierto que la mayoria lo único que buscan es un título que avale lo bien que trabajan.

En cambio otras ven en la adopción de las metodologías de trabajo una forma de llegar a ser mas "competitivos", mejorando su gestión interna y evitando cometer errores. En el área del desarrollo de software venimos arrastrando desde hace mucho tiempo una serie de problemas que además de ir minando un mercado de clientes cada vez mas descontentos, hacia que el coste de los desarrollos de software aumentase de forma exponencial, en muchos casos los proyectos se convertían en trabajos de dudosa rentabilidad y en otros, eran los clientes los que debían asumir los costes derivados de su mala planificación. Algunos de los problemas más habituales vienen derivados de estimaciones erróneas, problemas de trabajo en equipo, relaciones con los clientes, gestión de errores, gestión de versiones, cambios de contexto, etc.

Las metodologías ágiles nacen para dar solución a todos estos problemas, se conforman como una necesidad para todos aquellos que desarrollamos software, marcan las pautas y las reglas necesarias para poder minimizar todos estos problemas. No quiere decir que seán la solución mas adecuada, serán mejores o peores en base a las necesidades, capacidad y funcionamiento de cada empresa, y estará en su mano sacarles verdadero partido.

Scrum se conforma como una metología sencilla de aprender, ofrece gran valor añadido sin demasiado esfuerzo, eliminando la burocracia y centrándose en la productividad a través de iteracciones cortas, el valor del equipo, la gestión de las estimaciones y la relación con el cliente, hacen de Scrum una metrología facil que puede resumirse en una hoja y que es simple de adoptar si se cree en ella tal y como explica Jorge Serrano en Explicando scrum a mi abuela o Rodrigo en Porque me gusta Scrum, para hacerlo, no es necesario ningún tipo de certificación, cualquiera puede aplicar Scrum, los requisitos son sencillos y las reglas, no demasiadas, es por ello que Scrum es una metodología que se centra en la mejora continua y que permite gestionar varios proyectos sin una burocracia y costes excesivos. Por estas razones y no por otras, creo que Scrum se está empezando a utilizar de forma masiva, aunque todavía son muy pocos los que la sacan partido de verdad.

Por otra parte las nuevas tendencias y formas de trabajar se están empezando a trasladar a muchos sectores industriales y laborales, no solamente a la informática, en mi empresa, por ejemplo, estamos implantando un sistema LEAN MANUFACTURING, pero no por la moda de Toyota, que desde luego ha influido enormemente en su adopción (de hecho actualmente es el primer fabricante de automóviles del mundo), 'por algo será', si no en la búsqueda de mejorar nuestro sistema de trabajo y ahorrar costes, en resumen hacer que la empresa sea más competitiva y que tiene muchas similitudes con las metodologías de trabajo que utilizamos en desarrollo, de hecho se utilizo como base de algunas. Al final todos buscamos lo mismo, mejorar la productividad, ahorrar costes, ser más competitivos, mejorar nuestra relaciones laborales con nuestros clientes y el trabajo en equipo, hacer entender a aquellos que nos rodean que el trabajo que realizamos es complejo y difícil y que cada vez es más importante mejorar nuestra gestión de proyectos y evitar muchos de los errores que venimos cometiendo desde hace años. Que utilicemos Scrum o cualquier otra metología que nos permita realizar esto es indiferente, la utilización de una metologías no garantiza el éxito del proyecto, tan solo nos marca las pautas para evitar errores e intentar llegar a ser más competitivos.

Las metodologías de trabajo proponen soluciones para resolver problemas comunes, es algo así como la aplicación de patrones de diseño, ¿ porque no utilizar una solución ya probada para resolver un problema similar?. Sin embargo cuando hablamos de diferentes metodologías, parece que se desencadene una guerra, si un fontanero tiene que instalar una tubería de cobre la forma de hacerlo será en base a los elementos y el entorno que tiene delante, en cambio si la tubería es de otro material seguro que el método es diferente, con las metodologías pasa lo mismo, habrá metodologías que se adapten mejor a un tipo de cliente y un entorno determinados y en otras que puedan suponer un autentico fracaso ya que las ideas de las metologías deben ser coincidentes con la política de la empresa, este es el factor que hace que muchas fracasen en su adopción, "adoptamos algo en lo que no creemos", pero no tienen porque ser unas mejores que otras, tan solo se adaptaran mejor en base a la forma de trabajar de las empresas, el entorno y otros factores. En todo caso, nacen para ofrecernos soluciones a los problemas con los que tratamos habitualmente, en los que aspectos tan importantes como la estimación, la colaboración y mejora del trabajo en equipo son factores fundamentales que nos permitirán adaptarnos y ser más competitivos.

Lo verdaderamente triste es que parece que en algunos países estamos a la cola y que hablar de la adopción de metologías de trabajo provoca una gran controversia, creo que la mayor parte de las veces por desconocimiento total de lo que implica la adopción de estos sistemas de trabajo.Sin embargo, algunas personas y empresas, quizás las menos, se han empezado a dar cuenta de la importancia que tiene la adopción de estos métodos de trabajo, que nos permiten optimizar y mejorar nuestro ámbito laboral. Esto es fundamental para el área del desarrollo de software ya que la complejidad de los sistemas y las diferentes tecnologías conjuntamente con el progreso, hacen que el desarrollo de software sea una de las aéreas que más cambios sufren . Estoy seguro de que aquellas empresas que apuesten por mejorar sus sitemas de trabajo marcaran la diferencia, para las demás creo que sus días están contados, apoyado por la ley de Darwin, 'solo los que mejor se adapten al medio sobrevivirán'.

En cualquier caso si queréis seguir el ejemplo de General Motors, aquellos que creáis que la crisis actual es un invento del gobierno o que las empresas van a seguir exactamente igual, independientemente de su forma de trabajar, no hagáis nada, seguir trabajando igual.

No digo que Scrum sea la solución a todos vuestros problemas, pero que es un buen punto de partida para acercarse a las metologías agiles, robusta y relativamente facil de adoptar frente a otras. Si no usáis ninguna, hará que en poco tiempo no podías vivir sin ella, así que animaros, esto no es una moda, es una necesidad para todos aquellos que queremos mejorar nuestra forma de trabajar.

Asta lax pelotax de lox talivanes ortografikós

Juan Irigoyen — Wed, 24 Jun 2009 21:28:53 GMT

No púedo entender komo ay jente ke tenga komo unika finalidad en esta bida kritikar ha los démas, sin una pizka de edukakíon y kon el úniko fin de tokar las pelotas, akí no benimos a kritikar, si no a kompartir konocimientos y alludar a los demas, si kereis que algien corriga hun testo con faltas, tan solo deveis decirlo con edukación, si no kompraros un livro, ha ser posivle el Kuijote en berxión horijinal.

Komo xois tan listos aber si hempezais a heskribir algo y kompartis un poko de buestros koñocimientos, por ke todabía no e bisto a ninguno de bosotros eskribir hun post.

A ber si empezamos a ser un poko mas konstruktibos kon los komentarios ke dejáis, la jente ke eskribe ace hun gran hesfuerzo y encima no acéis más ke tokar los kojones, no hentiendo los komentarios despektibos kon el úniko fin de desprestijiar a los ke eskriben akí, y komo tengo mukhos años y húltimamente no axumo mui vien las krítikas, a todos akeyos ke kritiken de forma despektiba hel travajo de los démas sín hún mínimo de heducación, solo hos kiero decir una kosa:

ke hos den…

Windows Presentation Foundation. El final de Windows Forms…

Juan Irigoyen — Tue, 16 Jun 2009 22:56:00 GMT

Últimamente cada vez leo más artículos que hablan sobre las ventajas de construir aplicaciones en WPF frente a la utilización de Windows Forms, para aquellos que no lo conozcan, WPF es una tecnología que nos permite aprovechar al máximo las características gráficas de nuestros equipos ofreciendo interfaces más ricas de las que estamos acostumbrados. El objetivo de Windows Presentation Foundation es proporcionar avances en el entorno de Windows que permitan crear interfaces que incorporen documentos, componentes multimedia, gráficos bidimensionales y tridimensionales, animaciones, características tipo web, etc.

Sobre la afirmación de que WPF marcará el final de Windows Forms, me parece arriesgada, aunque la evolución que está teniendo esta tecnología frente a Windows Forms no solamente desde Microsoft sino de la mayor parte de empresas de controles de terceros, me hace pensar hasta que punto es cierta esta afirmación.

En los últimos años Microsoft viene acostumbrado a sacar nuevas tecnologías casi por arte de magia y a relegar otras de la misma forma, lo cierto es que el cambio no es tan fácil como se pueda pensar, la adopción de una tecnología como WPF, cambia por completo la forma habitual que teníamos para desarrollar aplicaciones Windows Forms. Los diseñadores gráficos pasan a formar parte casi indispensable de los equipos de desarrollo si queremos sacarle todo el partido a esta tecnologia, si bien es cierto que la mayor parte de empresas dedicadas a desarrollar controles de terceros como Infragistics, DevExpress y otros están apostando seriamente por esta tecnologia con la inclusión de Skins y controles que nos facilitaran mucho esta labor.

En mi opinión son muy pocos los sistemas de gestión que requieran hacer un uso intensivo de la interface gráfica, sin embargo, en algunos ámbitos como científico o el médico, las capacidades 3D y las animaciones permiten obtener información de forma más eficaz. También es cierto que la mayor parte de los sistemas de gestión actuales suelen tener carencias precisamente en este apartado.

Glenn Block de Microsoft afirma que WPF es de largo la solución recomendada para el desarrollo de aplicaciones de línea de negocio para un futuro inmediato.

Algunas ventajas de WPF son las siguientes:

Estilo potente y estructurado.
Facilidad para crear estilos y aspectos.
Soporta Windows Forms.
Es el futuro para el desarrollo de aplicaciones de Vista.
Tiene capacidad de reutilización del código existente.
Databinding avanzado, que permite enlazar datos con cualquier control.
Programación declarativa vs procedural.
Capacidades avanzadas para la Web. (WPF/E)
Apuesta clara de Microsoft para su implantación.

Desventajas

En muchas ocasiones vamos a necesitar el trabajo de diseñadores gráficos para beneficiarnos del potencial de WPF, lógicamente este será un coste que debemos repercutir a nuestros clientes.
Modificar código en AXML es un infierno o al menos para mí es bastante complicado.
Los requerimientos de los equipos en el apartado gráfico serán mayores, deben soportar DirectX y disponer de una tarjeta gráfica con suficiente capacidad, sin embargo, estos son la mayoría de los pc´s de hoy en día, aunque todavía existen muchos equipos, sobre todo portátiles que no soportan del todo estos requerimientos.
Al tratarse de la primera versión, tiene muchos aspectos en los que mejorar sobre todo en el apartado de los diseñadores de formularios y entorno gráficos. De hecho se encuentra aún en fase de desarrollo.
La curva de aprendizaje es alta.

¿ Debo migrar mi apliación a WPF ?

No hace mucho tiempo que Miguel Jiménez solicitó que le enviase algunos formularios de la aplicación actual que estábamos desarrollando para ver la posibilidad de realizar un proyecto paralelo de migración a WPF, lógicamente le envié algunos de los formularios más grandes y complejos que teníamos, su respuesta fue: buff estas pantallas con tantos controles, pestañas y funcionalidad para realizarlos con WPF, sería un trabajo demasiado arduo, no se hasta que punto merecerá la pena, tendríamos que dividir algunos para integrarlos en WPF, esto me hace pensar, si WPF está lo suficientemente maduro para abordar sistemas de gestión complejos y si realmente merece la pena realizar este cambio sin una necesidad comercial seria. Creo que existen muchos desarrolladores migrando sus aplicaciones a WPF, sin una razón que justifique la adopción de esta nueva tecnología, todavía son pocos los entornos de gestión empresarial que necesiten verdaderamente un cambio de arquitectura y que son incapaces de articular una necesidad comercial.

Lo cierto es que algunas de las interfaces que he probado son verdaderamente impresionantes, no solo en cuando a mejora del interface gráfico, la velocidad de refresco y la interacción con el usuario mejoran notablemente. Como ejemplo os dejo un par de pantallas de los controles que usamos.

¿ Cuanto apoyo le queda a Windows Forms ?, he leído en alguna parte que Microsoft solo está apostando por WPF ahora y manteniendo Windows Forms, si esto es cierto, WinForms esta condenado a desaparecer y deberemos centrarnos poco a poco en la adopción de WPF, por otra parte el número de aplicaciones existentes hoy en día, hará que el soporte de WinForms persista durante mucho tiempo.

En mi opinión WPF es una nueva tecnología que se está asentando en estos momentos y como tal, no carente de problemas. Su curva de aprendizaje para aquellos que venimos de Winforms es alta. Quizás el verdadero reto no este en aprender como usar esta nueva tecnología, sino en pensar cómo, a través de ella, podemos enriquecer las aplicaciones para alcanzar determinados objetivos, como mejorar la productividad, mejorar la interacción con el usuario, aumentar la satisfacción, mejorar el rendimiento, etc. No debemos olvidar que la adopción de WPF, tendra un coste muy alto si tenemos que incorporar diseñadores gráficos a nuestros equipos de desarrollo. En cualquier caso parece que Microsoft ha realizado una apuesta clara por la utilización de WPF, su adopción en nuevas herramientas como Visual Studio 2010 y el nuevo diseñador de WorkFlow así lo demuestran y que además de confirmarse, ya habria abandonado la mejora de Winforms, con lo que de una forma u otra estaríamos abocados a utilizarla tarde o temprando.

Por otra parte me quedan varias preguntas sin contestar que creo que son comunes a las de muchos desarrolladores y que me gustaría con vuestra ayuda resolver:

¿ Deberiamos comenzar a estudiar a fondo WPF, para la adopción de esta tecnología en un futuro cercano ?

Si tuvieraís que realizar un nuevo proyecto similar a los anteriores desarrollados en Windows Forms, ¿ utilizarías WPF o esperarías a nuevas versiones ?

¿ Sera WPF el sustituto definitivo de Windows Forms o tan solo una nueva tecnología para realizar programas diferentes ?

¿ Sera WPF una tecnología más, que quizas en poco tiempo se vea relegada por otras como Silverlight o que debido a su alta curva de aprendizaje o sus costes no lograra asentarse lo suficiente como para convertirse en el sustituto de Windows Forms ?

¿ Esta lista esta tecnologia para abordar desarrollos similares a los que venimos realizando en Windows Forms ?

¿ Si no tenemos ni idea sobre diseño gráfico o nuestro equipo no puede disponer de diseñadores, podremos sacarle partido a WPF ?, ¿ Tiene sentido utilizar WPF en estos casos ?

En fin, quizas os dejo mas preguntas que respuestas, pero confio que entre todos conformemos una idea mas clara de lo que es WPF y de lo que va a suponer esta tecnología en los próximos años.

Pd. Y pensar que todo esto comenzo con CSI….

Manual de detección del Australopithecus

Juan Irigoyen — Wed, 10 Jun 2009 22:23:00 GMT

Según la wikipedia, vivió aproximadamente hace 4 millones de años, al comienzo del Pleistoceno. Creerme todavía existe, yo sigo tropezando con alguno de ellos.

En mis primeros años profesionales dedicados a la informática (digo profesionales no porque fuera un profesional, sino porque intentaba ganarme la vida con este trabajo), no sé si debido a mi juventud o inexperiencia, me tropecé con innumerables especímenes de este género, la mayor parte convertidos en “Empresarios de éxito” con un nivel de formación y educación que no sobrepasaba al de los grandes simios.

Recuerdo una anécdota en especial que me llamó mucho la atención, todo comenzó con una reunión con un homínido de esta especie (aunque yo entonces no me había percatado de nada, es más, me parecía increíble todo lo que contaba), después de haberlo escuchado hablar durante varias horas sobre la importancia que tenía la informática para ellos, la necesidad urgente de dotar a su Empresa de medios adecuados para su gestión y escuchar frases como: “yo, me he hecho a mí mismo”, “cuando dejé la cueva, solo me lleve lo puesto”, “cazaba las aves con tiragomas y no con escopetas calibre 458 como ahora…”, etc.

Después de la reunión, la entrega del presupuesto (“¿no sé por qué?, si los informáticos no tenemos derecho a cobrar por nuestro trabajo.”). Enseguida ví como frunció el ceño, me miró con cara de asombro y pocos amigos y me dijo: después de nuestra conversación no has entendido nada, (“claro, si yo vengo aquí a aprender, no a trabajar, gracias Dios por esta oportunidad…”), me dijo: esto no es lo que esperaba de tí, pensaba que eras un tipo inteligente, este proyecto tiene valor añadido, si realizas el programa podrás vendérselo a todas las empresas del sector en las que estoy muy bien considerado, tienes que mirar esto con "perspectiva".

¿Pero como podeis cobrar tanto?, joder vosotros los informáticos estais hechos de otra pasta y mirando a la secretaria le comento: ¡mira!, estos “ingenieros” que acaban de salir de la facultad y no saben hacer la "o" con un canuto, quieren cobrarnos hasta por respirar…

Incauto, trate de explicarle las razones del coste del proyecto, y que valorar las 300 horas de trabajo por 4 gallinas, media docena de buitres leonados, un cráneo de mapache y un cuerno de alce, no era ni con mucho un gran presupuesto, pero claro no tenía “perspectiva", finalmente dijo: bueno ya te llamaremos… Me fuí a casa, pensando: “joder me habré pasado, quizás tuviese razón, tendría que haberle aceptado solamente 1 cabra y el cuerno de alce, al fin y al cabo después podría comercializarlo en otras aldeas…”.

Paso bastante tiempo y el “eslabón perdido” vuelve a llamar y me dice: ¿te acuerdas de mí?, pues nada, que me he decido por fin y voy a contratar tus servicios, y vuelta a otra reunión interminable en la que aguanto estoicamente sus logros y conquistas, ahora la necesidad de tener un sistema informático es imperiosa, ya que cometió el error de “contratar” a un amigo del primo del tío de la novia de su excuñado que había trabajado en la cabaña del Tio Tom y en su tarjeta decía “Product Manager”, además, era campeón del mundo en tiro con arco. El desgraciado, sin motivo aparente le había dejado en la estacada. Seguimos hablando y comento: “bueno, pero, lo del presupuesto aquel, tendríamos que revisarlo…”. Pensé, ("desde luego, han pasado dos años y al menos hay que incrementarle el IPC"). Continuó: pues hoy en día las cosas no son como antes y bla, bla, bla.

Como mi situación era complicada decidí aceptar un generoso descuento, "solo cobraría 1 cabra, las gallinas y el cuerno de alce, que les den a los coño buitres leonados...", y me puse manos a la obra, de lo malo, malo, al menos, aprendería muchas cosas sobre su negocio, ya tendría tiempo de ganar mucho dinero cuando me convirtiera en un buen profesional…, aprovecharía para aplicar alguna nueva tecnología con la que poder sacar mayor valor añadido al software desarrollado y con suerte quizás, podría venderlo a otras tribus de la zona.

Esa misma semana me comunica que las reuniones periódicas semanales no iban a poder ser realizadas los lunes, ya que, debido a sus logros en la gestión de la aldea le han hecho jefe de la tribu y tiene que dedicar todo su tiempo productivo a fabricar herramientas, palitos para "pescar" hormigas, tiras de corteza para cazar termitas, martillos para cascar nueces, ramitas para espantar moscas, etc. y que además el sábado tiene que ir al consejo tribal, así que solo podría reunirse conmigo el domingo por la mañana, pues por la tarde tenia la fiesta "canival...".

Como ya había dedicado mucho tiempo al proyecto y debido a mi complicada situación económica, decido aceptar y reunirme con él todos los domingos por la mañana para tratar de conocer en detalle los procesos más complejos de su negocio, después de un par de sesiones domingueras en las que sólo me explica cómo ha llegado a convertirse en un “Empresario de éxito”, me llama diciendo: “A partir de ahora no voy a poder atenderte, así que mejor trata de todos estos asuntos sin importancia con mi secretaria”, “¡Dios! que alivio”, por fin voy a tratar con alguien que al menos tiene graduado escolar… y además usa minifaldas…. si, si, en la aldea del tipo este, todas las secretarias iban con minifaldas y enseñando… bueno mejor me callo, una de sus frases decía: “hay que saber sacar verdadero partido de los recursos que disponemos…”

Después de un par de reuniones con su secretaria, ésta me comenta que el tal Australopithecus, tiene un tinglado montado de miedo, no paga a nadie, ella lleva seis meses y tan sólo ha cobrado el primero y el tío se acaba de comprar una balsa supermirafiori, para navegar por el río y visitar a una novia que tiene en la tribu ubicada 10 millas más arriba y que además no rema, que le duele mucho la espalda y que tiene que venir tarzan con la chita y el elefante para remontarle por el río. El sujeto intenta cada poco tiempo hacer la vida imposible a sus empleados para que muchos se tengan que ir, renunciando incluso a la indemnización, y que el “informático” que había estado antes que yo, lo había dejado porque llevaba más de un año trabajando y no le había pagado nada, que unicamente le había contratado porque exigia 2 buitres leonados menos que yo.

Ante la situación, decido paralizar al proyecto hasta no cobrar al menos el trabajo realizado, cuando hablo con él para comentarle la situación, le empieza a salir espuma por la boca, los ojos se le hinchan y enrojecen y los colmillos le crecen 4 cm, tembloroso le digo que tiene que asumir la deuda del trabajo realizado, que no estoy dispuesto a continuar hasta haber cobrado al menos un par de gallinas y el putísimo cuerno de alce que por supuesto ya formaban parte de mis deudas, responde que no está dispuesto a pagarme nada, ya que no ha recibido nada a cambio, es más, que si alguien debe algo, ese soy yo, ya que me ha dedicado gran parte de su valioso tiempo y claro, este, era muchísimo más costoso que el mío, ante la peligrosa situación que se fue agravando poco a poco, decido irme y darle un poco de tiempo para pensar con tranquilidad.

Al cabo de unos meses y viendo que las gallinas y el cuerno de alce seguían sin aparecer, decido armarme de valor y acercarme un domingo por la mañana a la choza, a ver si podíamos solucionar la situación de alguna forma, cuando llegó al lugar, aparece una mujer, le preguntó por el sujeto y me dice que ella es su mujer y que este se ha fugado a la tribu del río de arriba dejándola con sus dos hijos, que se ha llevado las dos vacas que tenían, para entregárselas al Jefe de la otra tribu y hacerse con los servicios de un par de mujeres y que ha les ha dejado sus deudas y otros problemas, me enseña lo que queda del negocio, los empleados hartos ya de la situación, habían arramplado con todo y no habían dejado títere con cabeza, incluso la habían amenazado si no aparecía pronto….

No penséis que esta fue la única vez que me han pasado situaciones similares, de hecho yo pensaba que jamás me podría pasar algo parecido, pues este sólo fue el comienzo de varios casos que me ocurrieron posteriormente. Así que he decidió redactar un pequeño manual para que podáis detectar este tipo de homínidos tan perjudiciales para el hombre:

1 – El Australopithecus suele comerciar con cuerno de alce, no entiendo como lo hacen, el alce es mucho más inteligente que el Australopithecus ...

2 – Suele despreciar a los sujetos de su misma especie, incluso a sus empleados y familiares cercanos, ten cuidado, lo mismo hará contigo.

3 – Se siente el más listo del mundo, es el único que sabe hacer fuego, los que le rodean no tienen ni *** idea de nada, ellos son los mejores.

4 – Si oyes frases similares, ¡cuidado!, se trata de la especie más peligrosa:

Me he hecho a mí mismo...
Cuando me fuí de la cueva sólo me lleve lo puesto.
En mis tiempos cazaba los leones a mordiscos…
No tengo una empresa, tengo un grupo empresarial.... (El equivalente a una Choza y 4 pringaos distribuidos por la peninsula que no cobran hace 6 meses)
El nombre de su tribu comienza por “Asociación de ….”
Nosotros somos pioneros en….
El dinero no es importante, yo me fuí sin nada y mira en lo que me he convertido...
He construido yo solito este imperio…
Tienes que entender que ésta, no es una empresa cualquiera…
Yo invente la rueda...
Tu, no estás aquí para pensar...
Si a un trabajador no le da tiempo a terminar su trabajo, es su deber continuar hasta finalizarlo...
La formación no sirve de nada con estos mendrugos..., eso es para intelectuales...
Si quieren estudiar que lo hagan en casa, que yo les pago por trabajar...

5 – Los gestos son fundamentales, a veces, echan espuma por la boca, acostumbran a gritar de forma habitual, y si continuas sin entenderlos te atizan un garrotazo.

6 – Si sacan fajos de billetes y te dicen: ¿cuánto necesitas?, cógelos rápido, suele ser un truco muy habitual. Los sacan y los introducen de nuevo en la billetera a la velocidad del rayo. Pero a ti te queda el mensaje subliminal, cuando te vas solo ves los billetes que te debe...

7 – Si quedan contigo el domingo, mucho cuidado, es de los que no van a misa..., además acostumbran a cazar ese dia.

8 – Si se compra una balsa supermirafiori, ojito, estás sólo se otorgan a los homínidos más peligrosos que militan en algún partido político.

9 – Hay una prueba que nunca falla, cuando hableis con él, decir la palabra “gratis”, si sus ojos empiezan a dar bandazos de un lado a otro y aparecen dólares en la cornea como a tío Gilito, es uno de ellos.

10 – Cuando le visitas suele hacerte esperar, tranquilo, está ocupado con otras cosas mucho más importantes que ni con 20000 años de evolución llegariamos a entender.

11 – No le dan ninguna importancia al dinero, total ellos disponen de todo el necesario.

12 – Sus empleados los “adoran”.

13 - Son muy difíciles de reconocer, ahora se depilan con laser y algunos no se parecen a las fotos de carnet de la parte superior.

14 - Si te invita a la fiesta "canival" y te dice que vas a ser el protagonista, ¡ojito!...

Si teneis la suerte de tropezaros con algún especimen de este tipo, recordar, nosotros, los simples mortales estamos en este mundo para ayudarlos, nuestro trabajo y sacrificio no tienen ningún valor, con esta especie podemos aprender a hacer de todo, he visto informáticos que lo mismo instalan una centralita de teléfono, te hacen una paella valenciana o cazan un búfalo con arco y flechas, si no podeis ganar dinero y vuestros hijos tienen que ponerse a trabajar, pues nada, que dejen los estudios y se pongan, total estudiar no tiene ningún sentido, con garrote, mano dura y sin tener ni *** idea de informática se podrán ganar mucho mejor la vida tal y como demuestra esta especie.

Un último consejo, nunca comiences a trabajar bajo ningún concepto si al menos no te hace entrega de un pequeño porcentaje del coste del proyecto, 4 gallinas o una cabra suelen ser suficientes. Y recordar llevar siempre el garrote a mano, podeis acabar así:

Recursividad con Sql Server

Juan Irigoyen — Fri, 22 May 2009 20:25:00 GMT

Una función muy interesante de Sql Server es la de poder seleccionar un conjunto de datos de forma recursiva de manera que podemos obtener una serie en estructura de arbol.

Partimos de una tabla que tiene dos campos, llamados clave y padre, el campo clave se relaciona con el padre para formar la estructura en arbol.

El siguiente procedimiento almacenado muestra un ejemplo de como conseguir esto:

ALTER PROCEDURE [dbo].[Usuarios_seguridad_seleccionar]

AS

BEGIN

    DECLARE @minClave int

    SELECT @minClave = MIN(Clave) FROM dbo.Usuarios_seguridad;

    WITH UsuariosAccesos AS

        SELECT top 1 us1.Padre,us1.Clave,us1.Variable,us1.Modulo,us1.Contenido,us1.Acceso,us1.Imagen

        FROM dbo.Usuarios_seguridad us1

        WHERE us1.Clave = @minClave

        UNION ALL

        SELECT top 100 percent us2.Padre,us2.Clave,us2.Variable,us2.Modulo,us2.Contenido,us2.Acceso,us2.Imagen

        FROM dbo.Usuarios_seguridad us2

        INNER JOIN UsuariosAccesos AS us3 ON us3.Clave = us2.Padre

        WHERE us2.Clave <> @minClave

    SELECT TOP 100 PERCENT ia.Padre,ia.Clave,ia.Variable,ia.Modulo,ia.Contenido,ia.Acceso,ia.Imagen

    FROM UsuariosAccesos ia

    ORDER BY padre, clave

END

GO

La clausula with debe contener un miembro delimitador, en este caso el formado por la primera sentencia Sql que hace referencia al valor mínimo (Primer nodo) y el segundo miembro recursivo que hace referencia a la misma tabla definida el la clausula With.

El procedimiento almacenado calcula el valor mínimo del nodo con la clave mas baja, posteriormente va leyendo cada nodo relacionado de forma recursiva ya que en el inner join se relaciona con el conjunto de datos definido en la clausula WiTH, finalmente devuelve el conjunto de datos en un orden determinado, el resultado obtenido es el siguiente:

La consulta retorna los datos de forma similar a la estructura de arbol que posteriormente se carga en el tree.

Para cargar los datos en el control, podiamos haberlo hecho sin recurrir a la recursividad en Sql Server y hacerlo directamente con el lenguaje de programación en el cliente, pero hay veces que puede ser mas interesante recurrir al servidor en lugar de hacerlo en el cliente, por ejemplo para buscar un dato determinado aprovechando las ventajas de las busquedas en el servidor y devolver su nodo, borrar todos los nodos relacionados o simplemente por descargar la tarea del lado del cliente.

Si quereis mas información sobre la clausula WITH que permite realizar este tipo de consultas podeis encontrala en http://msdn.microsoft.com/en-us/library/ms175972.aspx (Ingles) o http://technet.microsoft.com/es-es/library/ms175972(SQL.90).aspx (Español).

Calidad de código

Juan Irigoyen — Wed, 20 May 2009 20:24:00 GMT

La calidad de software engloba muchos y diferentes aspectos sobre el desarrollo de aplicaciones, que pasan desde la elección de una buena arquitectura, hasta utilización de diferentes herramientas, la aplicación de diferentes técnicas y metodologías de trabajo. Creo que todavía hoy en día, existe mucha gente reticente a apostar por la calidad de código, debido a que piensan que su coste es mayor que su beneficio.

Cuando empecé a trabajar en equipo, surgieron una serie de problemas de difícil solución, en seguida me di cuenta de que los programadores escribimos código de forma muy diferente que realiza las mismas cosas, generalmente algunos, los más experimentados solían redactar un código mas legible, mejor documentado, necesitaban menos líneas para llegar a la misma solución, ya que sus conocimientos eran mayores, esto originaba muchos problemas cuando tenian que modificar o entender el código de los demás y es aquí cuando empecé a interesarme por las reglas de estilo, fxcop y otras herramientas que de alguna forma nos permitían establecer reglas para que todos pudiéramos por decirlo del alguna forma “entendernos mejor”. Por otra parte en la depuración de las aplicaciones observe que era mucho menos costoso detectar y corregir un error en una fase temprana que hacerlo posteriormente.

Para poder entender mejor el trabajo de los otros programadores comenzamos a aplicar algunas de estas reglas, desde normas de estilo, documentación, desarrollo de pruebas unitarias, aplicación de patrones de diseño, normativas de base de datos y un largo etc. Esto empezó a facilitarnos la compresión y la modificación de programas, en poco tiempo empezamos a tener una visión muy diferente del proyecto, nos aporto más claridad y conocimiento del trabajo de los demás y nos ayudo a detectar gran parte de errores en una fase temprana del desarrollo.

Algunos de los beneficios más importantes que observo son los siguientes:

- La aplicación de patrones de diseño suponen la solución más adecuada para resolver un problema determinado. Esta ha sido elaborada y seleccionada en base al entendimiento y posibles soluciones propuestas y analizadas por mucha gente.

- La adopción de herramientas como fxcop, stylecop, resharper, coderush, refactor y otras, permiten minimizar algunos errores en la fase de desarrollo además de obligar a cumplir ciertas reglas de calidad y estilo, que de no utilizar, provocan si el desarrollador no es un experto, a cometer errores de difícil detección como fugas de memoria, aprovechamiento óptimo de los recursos, localización de código no utilizado, y un largo etc. Por otra parte si todos las adoptan nos habituamos a escribir código de una manera similar, con lo que nos será más fácil comprender el trabajo de los demás. De la información de los errores que nos proporcionan aprendemos a programar mejor, liberando y utilizando recursos adecuadamente, con lo que nuestro conocimiento aumenta. Algunas de estas herramientas cuentan con utilidades para ayudarnos a escribir el código y refactorizar de una forma mucho más rápida.

- El uso de profiles nos permite detectar cuellos de botella y otros problemas que de otra forma serian prácticamente imposible de conocer.

- La utilización de pruebas unitarias y otras técnicas de testeo, nos permiten detectar errores en una fase temprana, si no lo hacemos a tiempo a veces puede implicar que tengamos que modificar más de un módulo relacionado con este, con lo que el coste se incrementa aún más. Como dice la frase, “más vale prevenir que curar”.La ventaja de contar con pruebas unitarias de un módulo que no hemos desarrollado nosotros nos permite entender mejor el comportamiento del programa. La aplicación es más fácil de modificar ya que si alguien altera el programa, por ejemplo cambiando el nombre de un campo de un procedimiento almacenado o alterando alguna función como el cálculo de totales de una factura, detectaríamos el error mucho antes de ponerlo en producción evitando mayores consecuencias.

- Se disminuye la dependencia del equipo de desarrollo: Si el día mañana alguno de los desarrolladores no está o la empresa de desarrollo cierra, será mucho más fácil encontrar a alguien que entienda el código que cumple unas determinadas reglas. Si cada miembro del equipo escribe software de forma diferente esto se hace practicamente imposible. Si otra persona o empresa externa cumple nuestros requisitos de calidad esto permite que pueda comprender y extender la aplicación más fácilmente.

La calidad de código no es opcional, de no aplicarla el coste de nuestros proyectos con seguridad será mayor.

Pero no todo es de color de rosa, utilizar estas herramientas requiere tiempo, formación y sobre todo constancia. Realizar pruebas unitarias además de ser costoso requiere mucha disciplina y un alto nivel de desarrollo, no solamente debemos preocuparnos de tener la máxima cobertura en nuestro código, si no que debemos intentar probar todos los extremos, valores nulos y otros factores que de no realizarse disminuyen los beneficios de estas. De igual forma aprender a utilizar profiles y otras herramientas llevan mucho tiempo en formación y desde luego tienen su coste. No debemos obsesionarnos con realizar pruebas unitarias y cumplir con el 85 % de cobertura en todo nuestro proyecto o cumplir a raja tabla todas las reglas que propone fxcop, resharper, coderush, utilizar reglas de estilo, realizar pruebas de carga, utilizar mock objects para crear independencia con nuestro entorno de datos, utilizar profiles para analizar hasta la más mínima señal de que algo va mal, etc, debemos comenzar poco a poco implantando alguna y habituarnos a utilizarla. Si haceís esto y dedicais un poco de tiempo en aprender a sacarles partido, os puedo asegurar que la mayoría se harán indispensables en vuestro trabajo.

Recuerdo que la primera vez que pusimos en marcha fxcopy en uno de los proyectos aparecieron miles de warnings, os aseguro que fue un autentico coñazo eliminarlos, ya que lo aplicamos en una fase media del desarrollo, nos costó bastante tiempo poner la aplicación en orden, pero aprendimos un motón de cosas sobre programación, algunas que nunca hubiéramos conocido si no llega a ser por este tipo de herramientas. Ahora no podemos vivir sin él y cuando vemos una aplicación que no lo utiliza en seguida nos damos cuenta de los errores que se cometen.

Las ventajas de desarrollar código de calidad son innumerables, se facilita la detección precoz de errores y nos permite anticiparnos y corregirlos antes de poner el sistema en producción evitando tener que rehacer gran parte de las aplicaciones. Estas herramientas nacen con el objetivo de permitirnos mejorar en nuestros desarrollos, no quiere decir que nuestra aplicación vaya a estar libre de fallos, pero si que será mejor, que aprovechara mejor los recursos y por supuesto, que tendrá menos errores, tendremos mayor seguridad a la hora de modificar un programa y reglas de trabajo en equipo que de otra forma serian muy difíciles de controla, se facilita la escritura de código y la detección visual de errores en tiempo de diseño, ahorrando mucho tiempo a la hora de programar y depurar la aplicación.

El esfuerzo que debemos realizar para desarrollar código de calidad es grande, pero marcara la diferencia y en poco tiempo nos permitirá recuperar la inversión con creces, así que animaros, merecerá la pena.

Acelera Visual Studio con Discos Solidos (SSD) y Tarjetas de Memoria

Juan Irigoyen — Mon, 13 Apr 2009 10:00:00 GMT

Después de leer varios artículos sobre los últimos modelos de discos SSD, y con el fin de acelerar mi trabajo con Visual Studio decidí adquirir un disco SSD modelo OCZ Core Series V2 SATA II 2.5" SSD con 120 Gb, las comparativas con los últimos modelos presentados por Intel X25, decían que incluso iban por delante en cuanto a rendimiento, su coste bastante inferior, de unos 340 € frente a los 650 € de un Intel.

La primera impresión cuando lo tienes en las manos es lo poco que pesa, parece un trozo de plástico. Después de clonar el equipo e instalar el disco duro, el rendimiento no parece mejorar, es mas en algunas operaciones incluso parece más lento, consultando en los foros del fabricante, leo que hay que hacer varios ajustes relativos al cache, el servicio de indexado, desfragmentación y otros. Para los interesados dejo los ajustes aquí http://www.ocztechnologyforum.com/forum/showthread.php?t=47212, que supongo haya que realizar en todos los discos SSD. Me pregunto si algunos serán correctos, no lo tengo muy claro.

Lo curioso es que después de hacerlo las búsquedas de archivos son espectaculares, sin embargo el rendimiento general aparentemente sigue siendo muy bajo, los tiempos de compilación con Visual Studio son similares a la utilización de un disco SATA de 7200 rpm, incluso en algunos casos más altos, los test de disco me decían que el rendimiento en lecturas secuenciales era espectacular, en cambio en lecturas aleatorias dejaba mucho que desear, la gran ventaja de la utilización de este disco es que la batería del portátil a pasado a durar más del doble, de dos horas a casi 5, sigo haciendo cambios en la configuración a través de regedit, pues el fabricante ni siquiera ofrece un programa de configuración, el disco tiene una conexión USB para actualizar el firmware, pero este brilla por su ausencia, lo curioso es que antes de comprarlo estuve leyendo en varios post, que los resultados obtenidos con este tipo de discos pasaban por un aumento de rendimiento en torno a un 30 % frente a un disco SATA Normal, en resumen toda una decepción, espero que con alguna actualización y soporte de Windows 7 para discos SSD el rendimiento pueda mejorar, pero no lo tengo nada claro.

Quizás, para trabajar con herramientas de diseño grafico como autocad que maneja archivos grandes el rendimiento mejore, pero en mi caso con Visual Studio me temo que con la cantidad de archivos que tiene la solución y el tamaño de estos que normalmente no supera 20 Kb no sea así. Lo cierto es que estoy bastante decepcionado con este disco, esperaba al menos cierta mejoria en el rendimiento tal y como se comentaba en los artículos.

Por otra parte acabo de renovar mi antiguo PC, un AMD con doble núcleo de los primeros que salieron al mercado, 4 Gb de Ram y un disco serial ata de 250 Gb, adquirí un equipo DELL Optiplex 960 con un procesador Intel Quad Core, 8 Gb de Ram, Vista 64 y un disco SSD de 64 Gb de la marca Samsung.

Como sabéis Visual Studio no permite realizar cambios en tiempo de ejecución cuando estas depurando en 64 bits, no entiendo porque ni despues del Sp1 han incoporado esta característica que es verdaderamente importante. Como trataba de potenciar el rendimiento decidi renunciar a esta opción.

Con esta configuración los resultados son espectaculares, se reduce el tiempo de compilación en un 70 %, el equipo abre outlook en decimas de segundo, realmente espectacular, el disco utilizado tiene la mitad de capacidad que el primero, pero en rendimiento nada que ver, impresionante, hay que tener en cuenta de que el procesador tambien hace su trabajo en el proceso de compilación los cuatro procesadores no bajan del 60 % de rendimiento, el sistema operativo es de 64 bits, el uso de memoria no sobrepasa los 4 gygas. Resharper y Devexpress van como un tiro. Es increíble que en un equipo que ronda los 1200 €, el rendimiento haya mejorado tanto, la verdad merece la pena la inversión.

Aprovechando este post, he realizado otra prueba utilizando una tarjeta de memoria de 4 Gb, similar a esta http://www.gigabyte.com.tw/Products/Storage/Products_Overview.aspx?ProductID=2180 Desconozco la marca de la tarjeta que tengo ya que la consiguió un compañero a través de unos proveedores directamente en china, la de la foto es de la marca Gygabyte y es practicamente identica a la mia exceptuando la bateria que es una pila normal recargable de 1,5 V, En España todavía no he visto ningún sitio donde se comercializa.

Esta tarjeta te crea un disco virtual de memoria, esta sustentanda por una pequeña batería de litio que se recarga a través del slot PCI, para evitar perder los datos cuando apagamos el equipo, aquí también los resultados son espectaculares, después de dejar el proyecto en el disco de memoria que tiene una capacidad de 4 Gygas, suficiente para almacenar varios proyectos, y redirigir los archivos temporales a un directorio del propio disco, las pruebas son verdaderamente asombrosas, el rendimiento en la compilación es similar al logrado con el nuevo equipo con disco duro SSD. No os puedo poner el precio de esta tarjeta, pero según he leído es cara.

Otra posible solución de bajo coste para acelerar Visual Studio pasa por utilizar memorias Flash como las que se usan en las cámaras réflex digitales de alto rendimiento, abra que ver las especificaciones de lectura(escritura, esta es una de las mas rápidas actualmente..

Se pueden utilizar como un disco mas en un portatil o se pueden conectar a traves de un interface SATA como el de la foto a cualquier PC, no he realizado las pruebas con este tipo de dispositivos, una memoria de 4 Gb similar a la de la foto no costara mas de 70 €, la de la foto de 8 Gb esta sobre los 110 € y el un interface para pc sobre los 20 €.

El ahorro de costes que puede suponer trabajar con este tipo de dispositivos puede ser espectacular, imaginar un equipo de 8 personas que compilen una media de 10 veces al día y el proceso tome unos 4 minutos, supone que podemos ahorrarnos 4 horas diarias solo en la compilación, aunque el dispositivo solo mejorase un 30 % el rendimiento, ya merece la pena realizar la inversión.

Otra solución muy interesante y gratuita para los que dispongais de suficiente memoria, al menos 3 Gygas, puede ser la utilización de este programa gratuito, https://www.cenatek.com llamado RamDiskVe, el programa crea un disco virtual utilizando la memoria ram del equipo, las pruebas que he realizado han logrado mejorar el proceso mas de un 30 %, aunque el rendimiento al guardar el contenido del todo el disco antes de apagar el equipo no es muy bueno y tiene algun problema, de hecho la versión para Windows Vista es beta, pero puede ser una buena alternativa que no nos cuesta nada probar.

En resumen, cuidado al comprar un disco SSD, no todos son iguales… los discos de memoria pueden ser una buena alternativa y si teneís memoria suficiente probar RamDiskVe.

Os dejo un video sobre el samsung SSD, tarda un poco, pero merece la pena. http://www.youtube.com/watch?v=pJMGAdpCLVg

(Por favor, visita la web para ver este medio)

Espero que el post os resulte útil.

Diseñando controles. Atributo DesignerSerializationVisibility.

Juan Irigoyen — Fri, 10 Apr 2009 17:57:00 GMT

En el siguiente ejemplo hemos encapsulado un texbox dentro de un UserControl y añadido la propiedad MaxLenght para poder modificar la propiedad de control encapsulado.

Public class UserControl1 : UserControl

     public UserControl1()

         InitializeComponent();

     public int MaxLenght

         get { return textBox1.MaxLength; }

set

             textBox1.MaxLength = value;

     private void InitializeComponent();

         this.textBox1 = new System.Windows.Forms.TextBox();

         this.SuspendLayout();

//

         // textBox1

//

         this.textBox1.Location = new System.Drawing.Point(3, 3);

         this.textBox1.Name = "textBox1";

         this.textBox1.Size = new System.Drawing.Size(100, 20);

         this.textBox1.TabIndex = 0;

//

         // UserControl1

//

         this.AutoScaleDimensions = new System.Drawing.SizeF(6F, 13F);

         this.AutoScaleMode = System.Windows.Forms.AutoScaleMode.Font;

         this.Controls.Add(this.textBox1);

         this.Name = "UserControl1";

         this.Size = new System.Drawing.Size(108, 27);

         this.ResumeLayout(false);

         this.PerformLayout();

     private System.Windows.Forms.TextBox textBox1;

Si arrastramos el control al formulario, observamos que en el código del InitialiceComponent del form aparece la siguiente linea:

this.userControl11.MaxLenght = 32767;

El generador de código ha añadido la propiedad con el valor por defecto en el InitializeComponent del formulario.

A partir de aqui solo se podra alterar el valor de la propiedad dentro del propio formulario, alterando manualmente su valor, esto obligaría a recorrer todos los formularios donde se usa el control.

El verdadero problema es que hagamos lo que hagamos en nuestro control el valor de la linea del InitializeComponent no cambiará ya que esta se introduce solo la primera vez que arrastramos el control al formulario. Con lo que el valor del Maxlengt en el formulario siempre sera 32767.

Si lo que buscamos es poder establecer a todos los controles una propiedad publica y un valor inicial, deberemos decirle a la propiedad que no se agrege a los contenedores donde se utilize el control. Esto se consigue decorando la propiedad con el atributo DesignerSerializationVisibility.

[DesignerSerializationVisibility(DesignerSerializationVisibility.Hidden)]

public int MaxLenght

    get { return textBox1.MaxLength; }

set

        textBox1.MaxLength = value;

El atributo utilizado tiene tres valores posibles:

- Hidden. El generador de código no produce código para el objeto

- Visible. El generador de código produce código para el objeto

- Content. El generador de código produce código para el contenido del objeto más que para el objeto en sí.

De esta forma la linea del InitializeComponent no se introducira en el formulario, si alteramos el valor de la propiedad en el control, su valor se utilizará en todos los contenedores donde le utilicemos excepto en aquellos en que explicitamente cambiemos su valor.

Si establecemos la propiedad sin atributos debemos tener en cuenta que por cada propiedad se añadira al menos una linea en todos los sitios donde utilizemos el control, esto además de penalizar el rendimiento, porque el valor ha de ser cargado cada vez que abrimos el formulario, elimina la posibilidad de realizar cambios en el control y propagarlos a todos los sitios donde se utilize.

En el caso de una propiedad formada por un array inicializado con valores, el problema es mucho mayor, ya que podemos encontrarnos en nuestro formularios casos como este:

private void InitializeComponent();
{
 
       this.userControl13.Array = new string[] {
        "0",
        "1",
        "2",
        "3",
        "4",
        "5",
        "6",
        "7",
        "8",
        "9",
        "10",
        "11",
        "12",
        "13",
        "14",
        "15",
        "16",
        "17",
        "18",
        "19",
        "20",
        "21",
        "22",
        "23",
        "24",
        "25",
        "26",
        "27",
        "28",
        "29",
        "30",
        "31",
        "32",
        "33",
        "34",
        "35",
        "36",
        "37",
        "38",
        "39",
        "40",
        "41",
        "42",
        "43",
        "44",
        "45",
        "46",
        "47",
        "48",
        "49",
        
};
 
this.userControl13.Location = new System.Drawing.Point(30, 80);
this.userControl13.Name = "userControl13";
this.userControl13.Size = new System.Drawing.Size(108, 27);
this.userControl13.TabIndex = 2;

Es muy importante entender como funciona el generador de código de visual studio para decorar las propiedades de controles y formularios que vayan a ser reutilizados de forma adecuada evitando sobrecargar sus contenedores y aprovechar las ventajas de la herencia.

Cuestión de rendimiento...

Juan Irigoyen — Wed, 01 Apr 2009 21:37:00 GMT

Recientemente he leído varios artículos sobre las ventajas de Windows 7, frente a los actuales XP y Windows Vista. Los problemas de rendimiento de Windows Vista en algunos aspectos como la copia de archivos y otros han hecho que los usuarios ni siquiera se planteen el cambio de sistema operativo, personalmente opino que Vista es bastante superior que XP, aun con estos problemas que después se solucionaron con el sp1. Pero esta situación ha llevado a que Microsoft haya tenido que dar marcha atrás en su política, y se ponga manos a la obra para mejorar su Sistema Operativo optimizándolo para mejorar su rendimiento y cambiar la imagen de su producto más importante.

En el caso de Office 2007, el cambio radical con la adopción del Ribbon ha provocado que muchos usuarios rehúsen a usar este producto debido a su coste, la curva de aprendizaje que requiere el cambio de aspecto, además de que las necesidades de la mayoría de los usuarios se encuentran cubiertas en las anteriores versiones, han provocado que el número de implantaciones de Office 2007 se encuentren lejos de sus versiones anteriores.

Creo que la velocidad a la que nos viene acostumbrando Microsoft muchas veces solo justificada por la idea de vender nuevos productos al mercado, está comenzando a cambiar la forma de pensar de muchos usuarios, se ha creado un clima, en el que muchos piensan "porque cambiar algo que ahora mismo funciona y que cumple con mis necesidades" y que además cuesta dinero.

En mi caso, como desarrollador llevo "trabajando sufriendo" con Visual Studio desde hace varios años, "digo sufriendo porque gran parte mi tiempo estoy esperando...", en mi opinión el diseño, su arquitectura y su integración con diferentes sistemas es excelente, pero arrastra desde las primeras versiones una serie de problemas que todos los días me hacen pensar si estoy utilizando la herramienta más adecuada, estoy harto de los tiempos de compilación, harto de los diseñadores de formularios lentos, por no hablar del diseño en Asp.net y Wpf y de otros muchos aspectos relacionados con las pruebas unitarias y herramientas de calidad como FxCop que hacen que día a día pierda gran cantidad de tiempo, en esperar a que un proceso finalice. Si comparo mi actual proyecto con el anterior desarrollado en otro entorno también de Microsoft similar en cuanto a complejidad y funcionalidad, exceptuando por la calidad de código, entonces me dan ganas de llorar, un formulario normal con los mismos campos tarda en abrir decimas de segundo, la compilación con el doble de código y formularios se realiza en menos de 15 segundos, en cambio en Visual Studio puedo pasar hasta 10 minutos para que finalice el proceso, muchos pensaran quizás no deberías compilar tanto o ¿ Por qué no reduces el proyecto para que vaya más deprisa ?, optimizas tus clases, controles, etc. Creerme he hecho de todo desde optimizar, gestionar las builds, hasta utilizar discos SSD, pero hay veces que es necesario compilar a menudo y puedo afirmar que las diferencias de tiempo son abismales, sobre todo en lo que al diseño se refiere. El entorno de producción es increíblemente lento, la carga de los controles en el toolbar es desastrosa, en fin, hoy estaba estimando el tiempo que perdemos en estas tareas y la verdad, mejor no contarlo.

Espero que Microsoft tome nota de estas quejas que afectan todos los días a muchos programadores y que se comprometa tal y como predica, a realizar productos de calidad, en los que el rendimiento sobre todo en herramientas de desarrollo sea un aspecto fundamental, antes de sacar productos nuevos al mercado, estoy harto de los continuos cambios y nuevas tecnologías en las que solo funciona el 70 % de las cosas y que obligan a los desarrolladores a hacer verdaderas virguerías para poder desarrollar sus aplicaciones, estoy harto de escuchar frases como "eso se implementara en la siguiente versión", y ver pasar errores que nunca se corrigen y que consumen mucho de nuestro tiempo productivo.

No quiero generalizar, considero que Microsoft tiene una amplia gama de productos excelentes, desde Sql Server pasando por Office e incluyendo como no a Visual Studio con el que mantengo desde hace tiempo una relación amor-odio, pero hay aspectos con los que lucho todos los días, y que versión tras versión siguen arrastrando los mismos errores, me pregunto cómo es posible que hace 10 años mi entorno de desarrollo fuese infinitamente más rápido para realizar la misma funcionalidad y hoy en día para realizar tareas cotidianas me encuentre con un entorno tan lento. Pienso que tal y como parece que están haciendo con Windows 7, deben replantearse su política y apostar por mejorar el rendimiento de sus productos, creo que hay muchos usuarios hartos ya de tantas versiones e innovaciones y que esperan realizar su trabajo de una forma más efectiva.

Creo en la innovación, pero no en la innovación a costa de no corregir y mejorar aquello que tienes por detrás. Como dicen en el desarrollo, los errores y la optimización de los módulos que lo requieran deben ser aspectos prioritarios.Creo que Microsoft con algunos productos ha empezado a pagar ya, su decisión de sacar productos cada poco tiempo e innovar a toda costa, y que en los sucesivos años todavía lo hará más si no cambia de política radicalmente.

Pero esta es solo mi opinión, estoy seguro que muchos no estaréis de acuerdo con estas afirmaciones.

El poder de las expresiones regulares

Juan Irigoyen — Mon, 16 Mar 2009 19:17:00 GMT

Creo no conocer a ningún programador que no odie enfrentarse a las expresiones regulares, lo cierto es que tienen su complejidad, aunque si te habitúas a utilizarlas en más de una ocasión te pueden sacar de un apuro.

En nuestra aplicación detectamos un error procedente de un control muy utilizado en nuestros formularios, el caso es que eliminamos una propiedad pública que utilizábamos para su configuración, como era de esperar el “find usages”, nos decía que esta era utilizada por infinidad de formularios de la aplicación, aparecían unas 2000 referencias, después de eliminar varias recorde que en cierta ocasión había podido solucionar un problema similar utilizando expresiones regulares.

Tenia que eliminar de los formularios todas las líneas similares a

   1: ((System.ComponentModel.ISupportInitialize)(this.bPorcentaje7.Properties)).BeginInit();

   2: this.bPorcentaje7.Properties.MaxLength = 6;

   3: ((System.ComponentModel.ISupportInitialize)(this.bPorcentaje7.Properties)).EndInit();

Utilizando la herramienta find and replace del visual studio configure las siguientes expresiones:

   1: ^(.*){ComponentModel.ISupportInitialize}(.*){Porcentaje}(.*){Properties}(.*)

2:

   3: ^(.*){porcentaje}(.*){Properties}(.*){ MaxLength }(.*)

La primera expresión regular eliminaría dos líneas, la primera y la tercera correspondientes a BeginInit y EndInit y la segunda eliminaría la línea del maxlenght.

Su tradución seria así: Busca desde el principio de la línea una cadena que comience con cualquier carácter y que seguidamente tenga la cadena “ComponentModel.ISupportInitialize”, después cualquier cadena, seguido de la palabra “porcentaje” seguida de cualquier cadena, seguida de la palabra “properties” y que finalice con cualquier cadena.

Una vez escrito, solo bastaba reemplazar todas las cadenas, y voila, el trabajo de varias horas hecho en tan solo unos segundos.

La documentación de Visual Studio se encuentra disponible en http://msdn.microsoft.com/en-us/library/az24scfc(VS.80).aspx

Existen además varios generadores de expresiones regulares en la web y programas para ayudarnos a escribirlas.

Entity FrameWork – Metadata

Juan Irigoyen — Tue, 10 Mar 2009 19:27:00 GMT

Como sabéis la metadata se define como la información que se conoce sobre los propios datos, cuando hablamos de entity framework, esta contendrá información sobre las entidades, campos y relaciones. En este ejemplo estaba buscando la posibilidad de conocer el maxLength de un campo de una entidad determinada, de esta forma podria configurar algunos de mis controles en tiempo de ejecución.

Cuando configuramos un grid necesitamos configurar el maxLength de cada campo para impedir un desbordamiento en la actualización, para evitar establecer el valor de forma manual en cada columna, pues si en algún momento cambio este valor, estaría obligado a variar esta información en todos los controles de mi aplicación donde utilice este campo. La metadata puede proporcionar esta información para configurar los controles en tiempo de ejecución evitando cambiar estos datos si en el algún momento altero la estructura de mis tablas. De la misma forma podemos configurar la precisión y la escala en valores decimales, nombre de los campos para el databinding, aceptación de valores nulos, configuración de campos de solo lectura, etc.

La automatización de estos procesos a traves de los metadatos evitara numerosos errores y nos permitirá realizar cambios de una forma más eficaz.

En otras ocasiones esta información nos permitira generar sentencias Sql en tiempo de ejecución, generalizar consultas y funciones en nuestros proyectos.

En Entity framework la metadata esta almacenada en el archivo edmx en formato xml. En este ejemplo el archivo xml contiene información diversa en cada uno de los campos, maxlenght en los casos que utilizemos cadenas, precision y escala en los valores decimales.

   1: <Property Name="Empresa" Type="nvarchar" MaxLength="50" />

   2: <Property Name="Transporte_factor" Type="decimal" Nullable="false" Precision="6" Scale="2" />

He desarrollado este pequeño programa que nos permitirá conocer el maxLength de cualquier campo de una entidad,

/// <summary>
/// Retorna el maxlenght de un campo de una entidad y un contexto determinados
/// </summary>
/// <param name="context">Contexto del que se quieren recuperar las entidades</param>
/// <param name="entity">Nombre de la entidad</param>
/// <param name="field">Nombre del campo</param>
/// <returns>Retorna la longitud de la entidad, en caso de no encontrarlo retorna -1</returns>
public static int GetMaxlenght(ObjectContext context, EntityObject entity, string field)
{
    if (context != null && entity != null && !string.IsNullOrEmpty(field))
    {
        EntityContainer container;
        if (context.MetadataWorkspace.TryGetEntityContainer(context.DefaultContainerName, DataSpace.CSpace, out container))
        {
            EntitySet entitySet;
            if (container.TryGetEntitySetByName(entity.ToString().Split('.')[1], false, out entitySet))
            {
                const string mlenght = "MaxLength";
                if (entitySet.ElementType.Members.Contains(field) && entitySet.ElementType.Members[field].TypeUsage.Facets.Contains(mlenght))
                {
                    object smaxlenght = entitySet.ElementType.Members[field].TypeUsage.Facets[mlenght].Value;
 
                    if (smaxlenght != null)
                    {
                        int maxlenght;
                        if (int.TryParse(smaxlenght.ToString(), out maxlenght))
                        {
                            return maxlenght;
                        }
                    }
                }
            }
        }
    }
    return -1;
}

El ejemplo de uso seria algo así:

   1: using (NorthwindEFEntities context = new NorthwindEFEntities())

   2: {

   3:     Employees employees = new Employees();

   4:     EdmTools.GetMaxlenght(context, employees, "FirstName");

   5: }

Si quisieramos conocer otro factor, tan solo tendriamos que alterar el valor de la constante definida en:

const string mlenght = "MaxLength"

Aunque para el ejemplo anterior quizás lo más lógico sería realizar un método extensor para acceder a este tipo de información para poder hacer algo asi:

int maxlenght = employess.GetMetadata(employess.FirstName, Attributes.Maxlenght);

Cuando lo desarrolle pondré este ejemplo.

Como veis en el depurador las facetas pueden proporcionarnos más información, default value, nullable, etc.

El siguiente ejemplo está basado en el mismo proceso y devuelve información a través de un array con el contenido del maxLength de todas las columnas:

/// <summary>
/// Retorna una colección de campos valor con el maxlenght de cada uno de los campos de una entidad
/// </summary>
/// <param name="context">Contexto del que se quieren recuperar las entidades</param>
/// <param name="entity">Entidad</param>
/// <returns>Retorna un diccionario campo valor con la longitud de cada uno de los campos, en caso de no encontrarlo retorna -1</returns>
public static Dictionary<EdmMember, int> GetMaxlenght(ObjectContext context, EntityObject entity)
{
    Dictionary<EdmMember, int> edmFieldsMaxlenght = new Dictionary<EdmMember, int>();
    if (context != null && entity != null)
    {
        EntityContainer container;
        if (context.MetadataWorkspace.TryGetEntityContainer(context.DefaultContainerName, DataSpace.CSpace, out container))
        {
            EntitySet entitySet;
            if (container.TryGetEntitySetByName(entity.ToString().Split('.')[1], false, out entitySet))
            {
                foreach (EdmMember member in entitySet.ElementType.Members)
                {
                    const string mlenght = "MaxLength";
  
                    if (entitySet.ElementType.Members.Contains(member.Name) && entitySet.ElementType.Members[member.Name].TypeUsage.Facets.Contains(mlenght))
                    {
                        object smaxlenght = entitySet.ElementType.Members[member.Name].TypeUsage.Facets[mlenght].Value;
  
                        if (smaxlenght != null)
                        {
                            int maxlenght;
                            if (int.TryParse(smaxlenght.ToString(), out maxlenght))
                            {
                                edmFieldsMaxlenght.Add(member, maxlenght);
                            }
                        }
                    }
                }
            }
        }
    }
    return edmFieldsMaxlenght;
}

Buscando información encontré este blog http://www.scip.be/index.php?Page=ArticlesNET24, en el que proponen otro ejemplo muy interesante. Solo que aquí no puede acceder al maxlengh, es curioso, únicamente a los valores por defecto, si es nullable, etc.


   1: var query = from meta in context.MetadataWorkspace.GetItems(DataSpace.CSpace)

   2:                 .Where(m => m.BuiltInTypeKind == BuiltInTypeKind.EntityType)

   3:             let m = (meta as EntityType)

   4:             let properties = m.Properties

   5:             select new

   6:             {

7:

   8:                 EntityName = m.Name,

   9:                 MembersCount = m.Members.Count,

  10:                 KeyMembersCount = m.KeyMembers.Count,

  11:                 PropertyNames = from p in properties

  12:                                 select new

  13:                                 {

  14:                                     p.Name,

  15:                                     p.Nullable,

  16:                                     p.DefaultValue,

  17:                 Documentation,

  18:                                     Type = p.TypeUsage.EdmType.Name

  19:                                 }

  20:             };

No he probado a leer los metadatos de una entidad heredada, aunque en este caso podriamos averiguar su base y realizar la consulta. Utilizando como base el ejemplo anterior podemos facilmente ver todas la entidades que están derivadas.

   1: public static IEnumerable GetEntityNamesBaseNames(ObjectContext context)

   2: {

   3:     var query = from meta in context.MetadataWorkspace.GetItems(DataSpace.CSpace)

   4:                     .Where(m => m.BuiltInTypeKind == BuiltInTypeKind.EntityType)

   5:                 let m = (meta as EntityType)

   6:                 where m.BaseType != null

   7:                 select new

   8:                 {

   9:                     m.Name,

  10:                     BaseTypeName = m.BaseType != null ? m.BaseType.Name : null,

  11:                 };

  12:     return query;

  13: }

Espero que os sirva…

Especialización vs Polivalencía

Juan Irigoyen — Sun, 28 Dec 2008 17:08:00 GMT

No hace mucho tiempo, pensaba que la única salida que teníamos los desarrolladores era la de especializarnos en una tecnología determinada para poder asegurar nuestro futuro. Los continuos cambios y las nuevas tecnologías hacen que cada vez sea mas difícil mantenernos "actualizados" para ser competitivos en el mercado que nos rodea. Esta es una pregunta que desde hace tiempo me quita el sueño y de la que no logro obtener una respuesta clara. Esta claro que ser un experto en una determinada tecnología, puede aportarnos muchas ventajas. Para las pequeñas empresas de desarrollo de software obtener personal especializado en una determinada área es prácticamente imposible, ya que, para ello deberíamos contar con medios y con multitud de personas para conformar un equipo de trabajo.

En mi empresa desde hace tiempo observo que cada vez se da mas importancia a la obtención de personas con perfiles polivalentes, que según las necesidades de esta normalmente delimitadas por las situaciones de un mercado cada vez mas dinámico, sean capaz de adaptarse y asumir roles diferentes a los que están habituados con el fin de conseguir que estas, sean mas competitivas, pero los trabajos son, relativamente mas sencillos, en ningún caso, comparables al desarrollo de software.

Un simple desarrollador en asp.net debe ser capaz de conocer diferentes tecnologías, desde xml, ado, html, servicios web, iis, conocimientos de seguridad, etc. Creo que, una de las características mas valiosa de las personas en el área del desarrollo es la "capacidad de adaptación", ser capaz de asumir una tecnología en poco tiempo y sacarla partido es algo cada vez mas importante en nuestro trabajo, para ello no basta con estar preparados, estudiar o realizar diferentes cursos, hay que tener un nivel de predisposición al cambio, y esto es algo que rara vez se encuentra en las personas, es lógico, cualquier cambio, por pequeño que sea, siempre traerá consigo un sinfín de problemas que debemos solucionar. Por otra parte, estas personas tendrán que renunciar a cierta especialización para ser mas polivalentes. En el área del desarrollo de software es cada vez mas difícil obtener perfiles polivalentes ya que llegar a dominar una sola de las tecnologías con las que trabajamos puede suponer años de estudio y experiencia.

Por otra parte, creo que muchas veces, olvidamos el verdadero sentido de nuestro trabajo, este no es el de realizar aplicaciones utilizando las últimas tendencias y tecnologías, sino el de dar una "solución" a un problema especifico. Desde luego la solución debe combinar muchas factores importantes entre los que destaco el "tiempo", en la mayoría de los casos la introducción de una nueva tecnología frente a una solución ya conocida tendrá inicialmente un coste superior que debemos valorar y que muchas veces olvidamos, para dotar a nuestras aplicaciones de una arquitectura mas moderna, versátil y adaptable, pero que requiere mucho mas tiempo de desarrollo. Uno de los mayores problemas que observo en los desarrolladores, y me incluyo, es que normalmente buscamos que nuestra aplicación sea lo mas perfecta posible, esto incluye la adopción de las mas modernas tecnologías.

Especializarnos en un determinado área pueda hacer que en determinados casos seamos mas competitivos además de ser los únicos capaces de solucionar determinados problemas. Hablando con Fernando Guerrero, me comentaba que su empresa se había especializado en ofrecer soluciones muy determinadas, por ejemplo le llamaban para dar solución a un cliente que tenia una pagina web y que recibía mas de un millón de visitas semanales y en puntas de acceso los servidores se colapsaban, desde luego dar una solución adecuada para un problema similar normalmente pasa por disponer dentro de la empresa a personas con perfiles muy especializados, comentaba que ellos se dedicaban a ofrecer soluciones de problemas muy determinados y que estos suponían un porcentaje ridículo dentro del ámbito del desarrollo de software, y me aseguraba que estaban saturados de trabajo. En este caso contar con perfiles especializados hacia que su empresa podía ofrecer soluciones que otras nunca podrían resolver en un corto periodo de tiempo.

Por otra parte, en mi trabajo, la necesidad de obtener perfiles polivalentes es cada vez mas importante, un simple desarrollador debe conocer diferentes tecnologías y llegar a conocer alguna de ellas en detalle puede llevar mucho tiempo. Ser capaz de conocer a fondo una sola de las tecnologías que utilizamos, por ejemplo "Sql Server", nos puede llevar años de trabajo.

El otro día Rodrigo Corral escribía un post hablando de la importancia de aprender a desarrollar en entornos con multiples procesadores para aprovechar las características del nuevo hardware, comentaba que si somos capaces de aprender y dominar estas nuevas tecnologías tendremos un mercado que nos permitirá marcar la diferencia frente a otros desarrolladores. Lo cierto es que incluso, asumir una nueva tecnología como de las que habla en su post, pasa por conocer muchas otras y que el nivel necesario para poder entender aspectos como la multitarea es algo que no todos están capacitados para realizar.

Quizás la decisión mas adecuada pase por escoger lo mejor de ambos mundos, dominar una o dos areas e intentar ser polivalentes estudiando otras tecnologías para ser capaces de asumir cambios con rapidez, aunque todo dependerá de las necesidades de la empresa para la que trabajemos, por otro lado la especialización en un determinada tecnologia podría ayudarnos en la búsqueda de un futuro profesional mejor.

Así que sigo preguntándome que será mejor: Especializarse o ser polivalente y saber un poco de todo. ¿ Son areas diferenciadas o se pueden complementar ?... Espero con vuestras opiniones poder aproximarme a la solución mas adecuada. Como decía Malder, "La verdad esta ahí fuera...".

¿ Sabes jugar al pocker ?

Juan Irigoyen — Tue, 09 Dec 2008 05:15:00 GMT

He leído varios comentarios, sobre la importancia del valor del equipo en los departamentos de desarrollo. En el ámbito de las empresas que conozco, normalmente el equipo viene conformado de antemano, a veces porque la empresa cuenta ya con personal, otras porque el proceso de selección se lo encargan a una empresa externa que lo unico que tiene es un perfil predeterminado, son muchos los factores impiden seleccionar al equipo mas adecuado.

Por otro lado, te puedes encontrar que alguna de las personas del grupo no cumple las expectativas esperadas. Llegados a este punto, muchos piensan "Si un desarrollador en un momento determinado no cumple las expectativas lo mejor es deshacerse de el lo antes posible", en este caso, la empresa tendrá un alto precio que pagar ya que normalmente habrá invertido en formación y recursos para mejorar la calidad de su personal y debe buscar a alguien capaz de asumir el trabajo. En el mundo en que nos movemos, si la empresa utiliza tecnologías de última generación o el conocimiento de los procesos internos es complejo, esto se puede convertir en algo sumamente complicado, además de asumir el coste de echar al empleado, debemos formar de nuevo a otra persona e introducirla en el ámbito laboral. Normalmente esta tarea no se realiza en periodos cortos de tiempo y corremos el riesgo de volver a encontrarnos con alguien que no cumple nuestras expectativas y vuelta a empezar....

Comparo algunos equipos de desarrollo con una partida de pocker por la singularidad de sus miembros, en este caso los jefes de proyecto aspiran a recibir una escalera real.

Muchos son los motivos que hacen que una persona no desarrolle su trabajo de forma eficaz, cuando indagas un poco, descubres que algunos tienen problemas familiares,otros se consideran mal pagados y no estan dispuestos a esforzarse mas, en otros casos sus jefes no

saben delegar y se limitan a darles el trabajo basura... Podríamos escribir las causas utilizando los doce tomos de la biblia y nos quedaríamos cortos.

Creo que los responsables de un equipo cuentan con recursos para mejorar esta situación. Una palmadita en la espalda de vez en cuando, mostrar cierto interés hacia la persona, puede hacer que esta se sienta completamente motivada y valorada en su entorno. Ponernos de vez en cuando en el lugar de los demás es algo que debemos intentar para comprender mejor a las personas.

Como responsables de un equipo de trabajo, nuestro cometido pasa por conocer bien a las personas, debemos hacer de psicólogos para entender su comportamiento. Un responsable de equipo en cualquier ámbito debe ser capaz de escuchar, comunicar, delegar, incentivar, transmitir, compartir, enseñar, bromear, irse a tomar unas cervezas o a cenar de vez en cuando con su equipo..... , etc, etc. Después de leer esta frase, alguno en mi oficina se estará descojonando de la risa..... "capaz de escuchar, motivar.... jajajajajaja....", también es importante asumir nuestros errores, limitaciones y debilidades para tratar de corregirlas, al fin y al cabo, nadie es perfecto.

Existen muchas técnicas para mejorar la relación en un equipo de trabajo, recuerdo tres en especial que me llamaron mucho la atención, la primera era algo así: "Tenemos un grupo de 5 personas, cuatro de las cuales realizan el trabajo de una forma correcta pero el quinto no hace mas que darnos problemas", el proceso de mejora consistía en aplicar dos reglas, primero explicar detalladamente al equipo las ventajas de realizar su trabajo de una forma determinada y la dependencia que tenían los unos de los otros para realizar su cometido y segundo, poner al mas problemático a cargo del equipo. Habitualmente se detectaba que este, cuando comprendía que su trabajo afectaba a los demás y asumía su nuevo Rol se convertía en la persona que mas aportaba cambiando su actitud de rechazo hacia el equipo.

La segunda es bastante conocida y esta basada en la rotación, de vez en cuando los roles del equipo se invertían, un operario pasaba a ser jefe de equipo y al contrario...

La tercera técnica la vi en el programa "el encantador de perros", que pasaba por introducir a un perro inadaptado en una manada estable, al cabo de una semana este abandonaba su actitud y pasaba a formar parte de la manada, haciendo lo mismo que los demás cuando otro perro en su misma situación llegaba. Desde luego contar con un buen equipo que camina en una única dirección hará que cualquier persona que se integre en el, se adapte mas fácilmente a sus reglas. Desgraciadamente algunos animales son mas inteligentes que los hombres.

El trabajo en equipo es una aptitud, independiente del nivel profesional que se pueda tener. Lo malo es que desde pequeños nos han educado a ser individualistas. Cuando vamos al colegio o a la universidad lo único que pensamos es en aprobar, muy pocos acuden con el único fin de aprender, tan solo es un proceso de selección que si pasamos, nos permitirá acceder a una vida mejor. Frases como "tienes que ser mejor que los demás o similares..." son las enseñanzas de la sociedad actual. Los trabajos en equipo desde el colegio, bachillerato pasando por la universidad brillan por su ausencia y claro, cuando nos incorporamos al mercado laboral desconocemos como trabajar con mas personas. Aprender algo basado en todo lo contrario a lo que nos han enseñado desde pequeños es muy complicado, y no seremos capaces de hacerlo si no tenemos plena confianza en el valor de las personas. Muchos responsables no creen en esto, porque jamás se lo han enseñado, así que lo tendrán muy difícil para conformar un buen equipo de trabajo.

Por otro lado, algunos de los genios mas grandes de la historia han ofrecido al mundo sus avances desde la soledad de su trabajo, he conocido personas brillantes que se adaptan muy mal a las reglas del trabajo en equipo o les resulta muy difícil relacionarse con los demás, estas logran su máxima capacidad productiva cuando no tienen reglas que acatar. Detectar a estas personas y dotarlas de capacidad de independencia puede llegar a ser una mejor práctica que obligarla a acatar todas las reglas de un equipo.

La mayoría de la gente no sabe trabajar en equipo simplemente porque nadie les a enseñado la forma de hacerlo, explicar el porque de las cosas, escuchar a todos los componentes, ayudarles y motivarles será el primer paso para transmitir las ventajas del trabajo en equipo. He descubierto a lo largo de mi experiencia, que conocer a las personas nos aporta una visión única, que nos permitirá corregir y mejorar determinados comportamientos, si optamos por la vía mas fácil cuando detectamos problemas, habremos fracasado en nuestro cometido, un jugador de pocker juega con las cartas que recibe.Los buenos jugadores de pocker no basan su juego en las cartas. Los buenos jugadores de pocker analizan la mesa, cada gesto, cada mirada, estudian sus probabilidades e intentan conocer al contrario, aunque contar con buenas cartas hace que sus probabilidades de ganar sean mayores.

Para los buenos jugadores de pocker, las cartas serán un factor importante, pero no determinante.

No puedo resistir dejaros esta foto, que nadie se lo tome a mal....

Pd. Recuerdo de la última partida, jejejeje..., gane...... lo siento Francisco, Victor, Garris, jajajajajajaja......

Scrum – El valor esta en las personas

Juan Irigoyen — Wed, 03 Dec 2008 20:58:00 GMT

En mis primeros años de desarrollo estaba solo, habitualmente desarrollaba mis proyectos como quería, con el paso del tiempo y el aumento de las funcionalidades de los programas y de los avances en los lenguajes de programación, empecé a darme cuenta que pronto no iba a poder desarrollar sistemas de cierto nivel yo solo, en ese momento comencé un nuevo proyecto y me anime con unos amigos a conformar una pequeña empresa dedicada a ofrecer todo tipo de servicios informáticos, hacíamos de todo, desde vender equipos e instalarlos hasta desarrollar pequeñas aplicaciones y algunas páginas web, cuando la empresa fue prosperando necesitamos incorporar más gente al equipo de desarrollo, habitualmente cada uno se iba dedicando a un proyecto de forma individual, observaba a unos desarrolladores que les gustaba el trabajo que hacían y otros que solo trabajaban, digamos, para subsistir, los que verdaderamente aportaban valor eran aquellos que veían su trabajo como un hobbie, a partir de entonces, cuando seleccionaba a alguien, me importaba mas si verdaderamente le gustaba el trabajo que iba a realizar, que las titulaciones y los conocimientos técnicos que tenía. Para mi estaba claro, el valor estaba en las personas que tenían interés por su trabajo. Normalmente los programas no eran muy grandes, hacíamos pequeños análisis y desarrollábamos los proyectos, cuando procedíamos a su instalación el cliente nos hacia observaciones y correcciones, que de forma inmediata se iban resolviendo para adaptarlo completamente a sus especificaciones. El cliente no solamente se limitaba a hacerme correcciones, sino que me proporcionaba ideas para mejorar mis desarrollos, el problema era que esto normalmente lo hacia al final de la implantación y muchas veces tenia que rehacer gran parte de los proyectos asumiendo el coste originado. Habitualmente nos reuníamos con los desarrolladores y hablábamos de cómo realizar el trabajo, ellos proponían sus ideas y compartíamos diferentes puntos de vistas, como dice el refrán “dos ojos ven más que uno”, otras veces me sentaba con algún programador e intentábamos corregir un error. Para gestionar los proyectos solíamos utilizar excel, project o la lista de tareas de outlook, estas se escribían y se iban tachando a medida que se iban completando.

Cuando comencé a trabajar en equipo, empezaron a aflorar una serie de problemas, los desarrolladores que tenían un nivel más bajo, demandaban de forma constante mi ayuda, y me interrumpían constantemente cuando trabajaba, observaba que dedicaba mucho tiempo a enseñar, corregir e indicar como tenían que realizarse los desarrollos, cuando me preguntaban ¿como vais?, yo estaba totalmente descolocado, en mi caso, conocía la velocidad del trabajo que realizaba, pero no sabía cuánto podrían tardar las personas que tenían otros conocimientos y habilidades. El número de tareas creció mucho mas y su gestión me llevaba mucho tiempo. Me encontraba perdido, porque mis estimaciones fallaban constantemente.

Buscando una solución para estos problemas y gracias a Miguel Jimenez comencé a interesarme por nuevas tendencias en el área del desarrollo de software, empecé a leer sobre desarrollo ágil, en concreto me gustaron las que hablaban de programación extrema o XP, en las que se hablaba de pruebas unitarias, programación en parejas, priorización en la corrección de errores, entregas frecuentes, refactorización, integración del cliente como parte fundamental del equipo, propiedad de código compartida y simplicidad, alguna de las prácticas que se recomendaban eran utilizadas por mi desde hacia tiempo, así que me gustaron especialmente y comencé a estudiarlas un poco más en detalle.

Fue en este momento cuando me tropecé con Scrum y CMMI, buscando información me encontré con el magnífico trabajo realizado en Navegapolis por Juan Palacio y por supuesto, con los post de Rodrigo Corral.

Cuando conocí Scrum, observe que alguno de los factores que me habían llevado a realizar proyectos exitosos estaban ahí, y que además, me proporcionaba una solución para aquellos problemas que estaba tratando de resolver, mejoras en la planificación y la estimación, evitar las constantes interrupciones, mejorar la comunicación con el equipo, involucrar más a las personas, etc.

Las constantes reuniones diarias son la base de la metodología y nos proporcionaban varias ventajas:

- Muchas veces ocurría que cuando hablabas con un desarrollador al cabo un tiempo observaba que llevaba unos días desarrollando de forma incorrecta algún modulo. La falta de comunicación hacia que los retrasos por estas causas aumentasen, con la reunión diaria evitabas enterarte de esto al cabo de un tiempo, reduciendo retrasos y errores en la planificación. Estos se identificaban al principio y permitían mantener el ritmo de desarrollo.

- Al realizar la reunión diaria podías atender todas las dudas y consultas del equipo de desarrollo en ese periodo, con lo que las constantes interrupciones se evitaban, cuando un desarrollador preguntaba algo, se le decía: "eso se atenderá en la reunión de Scrum."

- El equipo tenía constancia del trabajo que realizaban los demás, redundando en un mejor conocimiento de la aplicación. Ocurría muchas veces que los desarrolladores que realizaban un determinado módulo desconocían el trabajo de los demás, cuando se intentaban enlazar dos módulos aparecían problemas que no se habían tenido en cuenta por falta de información.

- El equipo aporta valor, ya no era el único que resolvía las dudas o decía como tenían que realizarse las cosas, los propios integrantes del equipo ayudaban a sus compañeros a resolver sus problemas y a mí, aportándome ideas y otros puntos de vista sobre cómo llegar a soluciones más óptimas. Esto mejoraba la relación del equipo y el desarrollo del proyecto.

- Resultaba ser una eficaz herramienta de control, como sabéis en la reunión de Scrum se responde a tres preguntas.

¿Qué hicistes desde el último Scrum Diario respecto al proyecto?

¿Qué harás desde ahora y hasta el próximo Scrum Diario?

¿Qué te está impidiendo hacer tu trabajo lo mejor posible o que necesidades tienes para realizar el desarrollo?

La reunión permite conocer el trabajo de cada desarrollador, las dudas y los impedimentos que tienen para realizar su trabajo ademas de la evaluación continua de su trabajo diario. Es como cuando íbamos al colegio y nos preguntaban por la tarea del día anterior, desde luego no hacer la tarea es un riesgo, ya que todo el equipo sabe que nos has realizado tu cometido. Se mejora la productividad, al tener una presión inconsciente por el hecho de tener que pararse frente al resto del equipo y contar en lo que se estuvo trabajando.

Como sabéis en Scrum se planifican los llamados "sprints" que tienen una duración de entre 20-40 días, en ellos de definen las tareas que vamos a ser capaces de realizar en el periodo determinado. La planificación de cada uno marcaba una dirección clara para el equipo, todos conocen los objetivos y saben que van a obtener al final de cada sprint. En la conformación de los sprints cada miembro del equipo realiza la estimación y gestión de sus tareas, ellos son los mejores conocedores de su velocidad, esto hace que el control sea relativamente sencillo de realizar. En un equipo realizar este proceso era muy complicado, ya que los desarrolladores no tenían el mismo nivel, por otra parte, un desarrollador no programa siempre igual, la adopción de nuevas tecnologías, el progreso y las habilidades de cada uno, hacen que este sea un factor muy cambiante. Es el desarrollador el que se impone la tarea y el periodo determinado para desarrollarla, este hecho aporta gran valor, pues solo se le exige aquello que se ha comprometido a realizar. Aqui radica una de las premisas de Scrum, la confianza en las personas es una de las bases de la metologia, si bien puedes ayudar en las estimaciones al final el desarrollador es el que se compromete.

Posteriormente la evaluación en el sprint review nos permitía corregir aquello que se había realizado mal en el sprint anterior evitando incurrir en errores mas de una vez.

Las constantes entregas permiten al cliente evaluar el trabajo realizado, como se intentan desarrollar módulos "independientes", estos se pueden comenzar a amortizar la aplicación mucho antes de finalizarla.

El feedback del cliente permite realizar cambios mucho mas temprano, evitando rehacer gran parte del proyecto.

Cuando analizaba procesos, comencé a darme cuenta de que la mayoría de los problemas que detectaba, habitualmente, estaban derivados directamente de las relaciones interpersonales, la mayor parte de los responsables desconocía cómo había que trabajar en equipo, esto derivaba en consecuencias verdaderamente catastróficas, normalmente acostumbraban a dar órdenes y eran los únicos que aglutinaban la información de cómo se debían ejecutar los procesos. Cuando hablabas con las personas que realizaban el trabajo, te dabas cuenta de que sus jefes carecían de mucha de la información que ellos manejaban y consecuentemente no podían tomar las decisiones adecuadas, si la comunicación no era fluida entre el responsable y su equipo de trabajo, nunca podrían llegar a mejorar los procesos en los cuales trabajaban. Esto generaba un malestar general entre el equipo que sentía como sus valoraciones no eran escuchadas y redundaba en la bajada de la autoestima y consecuentemente en su rendimiento. Desgraciadamente todavía son muchos, incluidos los jefes de proyecto y las empresas de desarrollo los que no ven a las “personas” como su principal valor. Piensan que las infraestructuras, las máquinas, los procesos y ciertas "certificaciones" son la base de sus negocios. Me cuesta entender que a día de hoy, una gran mayoría de empresas sigan aplicando el método dirigir y controlar o el de Economia 101 tal y como cuenta Joel Spolsky.

Por otra parte, cada día encuentro mas empresas que adoptan una metología simplemente por estrategia, para vender software a terceros que tienen esa exigencia o por disponer de una certificación que avala lo bien que trabajan, recuerdo cuando se puso de moda la Iso 9001...., no estoy diciendo que no aporten cierto valor, pero creo que tienen un precio muy alto que pagar.

Scrum proporciona un método sencillo para estimar, controlar y dirigir proyectos minimizando la burocracia, centrándose y adaptándose a las necesidades de cada momento.

En Scrum se trabaja en equipo, todos tienen voz y voto, sus opiniones se toman en cuenta y pasan a formar parte del proyecto. Para todos aquellos que crean que su principal valor esta en las "personas", Scrum será una excelente metología.

Depurando, depurando y con el mazo dando...

Juan Irigoyen — Mon, 24 Nov 2008 06:16:00 GMT

Un día, un usuario me llama por el teléfono rojo, "oye Juan, resulta que estaba yo en tal formulario y de repente no se donde he pulsado y creo que se me ha borrado el texto en las observaciones....", incrédulo empiezo a pensar... ¿ lunes ?, este no sabe que ha pasado.... a saber que ha estado haciendo el fin de semana... por si acaso activo Defcon 1...

Después de un tiempo, me llama otro usuario y me dice: "Juan, resulta que estaba yo en tal formulario y de repente no se donde he pulsado y parece que se ha borrado el texto en las observaciones....", "Joder como me suena.... ", tendré que revisar el código... pasamos a Defcon 2....

Abro el formulario, empiezo a investigar, buscando las dichosas "observaciones", después de un tiempo nada, ninguna referencia...., lo dejo estar... ¿ será un virus o una rata que se ha comido un trozo de fibra?....

De nuevo otro día recibo la dichosa llamada. Decido activar todas las alarmas.... ¡¡¡¡señores!!!! estamos en !!!!!!!!!!!!!!!!! DEFCON 3 ¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡

¿ Será un trigger que se activa por algún motivo ? Buscando en la base de datos nada, ni rastro..., continuo indagando y por fin veo en un menú una opción "Actualizar datos...", me pregunto ¿quien ha introducido esto aquí... ?, desde luego llama a un Store Procedure que actualiza las observaciones dejándolas en blanco, fue una opción que solicitaron años atrás cuando se traspasaron los datos de un sistema anterior, y claro seguía activa, muy cerca en el menú, de otra bastante utilizada, los usuarios a veces se equivocaban y pulsaban esta opción eliminando el texto, me digo: no la voy a eliminar, no vaya a ser que el usuario X la utilice algún día, introduciré un messagebox que le pregunte ¿ Si pulsa "si", las observaciones se irán al carajo.... ? y voila....

Al cabo de unos días me llama un usuario y me dice: "oye Juan, resulta que estaba yo en tal formulario y de repente, no se donde he pulsado, me ha salido un mensaje "no se que del carajo...", he dado enter, y resulta que me han desaparecido las observaciones. Pienso "arghghghghghghgh, te vas a enterar....", entro al código, introduzco 10 messageBox mas, le añado una clave de encriptación basada en CuaimaCrypt y lo pongo en producción.

Después de cierto tiempo, me llama otro usuario y me dice: "oye Juan, resulta que estoy intentando borrar las observaciones con la utilidad que me hicistes y llevo pulsando no se cuantas veces al si para se vayan al carajo de una vez, después de media hora, me aparece una pantalla para que introduzca una clave de 200 dígitos alfanuméricos..., pero no me acuerdo del dígito 199, ¿era una z o una p?....... y nada, que no me deja eliminar las p%$tas.... observaciones estas.....". Con la soga al cuello y a punto de saltar por la ventana... decido utilizar el control usuarios, habilito la opción para el usuario que la utiliza, elimino los mensajes y la clave y deshabilito la opción para todos los demás, haciéndola invisible en el menú.

Este tipo de situaciones se dan a menudo en los procesos de depuración y desarrollo, a veces, cuando desarrollamos, nos centramos en realizar validaciones para evitar errores y no nos damos cuenta que es mucho mas fácil evitar el error eliminando la posibilidad de cometerlo. La utilización de una simple mascara evitara varias operaciones posteriores, validación, notificación al usuario de su error, limpiar el campo, situar de nuevo el foco en el control, etc.

Debemos centrarnos en evitar el error, no en controlarlo y sobre todo "utilizar el sentido común".... desgraciadamente algunos carecemos de esto...

Por cierto..., deja de mirar a la chica y ponte a trabajar... que es lunes....