Latest Entries »

Buah! a mi no me van a dar el premio al mejor blog técnico del año 😉 pero es que estoy hasta las orejas en reciclaje. Uno no puede vivir de WPF o XAML toda la vida, además que avanza poco, es casi como andar en bici. Por el contrario, la web … la maldita web, salen 5 librerías JS cada día, multitud de incumplimientos de los estándares, … eso sí que es riesgo!!! así que me he puesto a tope hace dos semanas.

Al tajo! hoy quería hablar de la naturaleza de uso de los métodos de extensión en C#. Lo comento, porque unos hacen abuso, y otros se las dan de listos con la herencia. Los métodos de extensión son eso, extensiones de nuestras clases o interfaces, pero que tienen un aspecto que no me gusta nada, estan fuertemente acopladas … o quizá no? 😉

Vamos a analizar los métodos de extensión sobre una clase. Para mi no tiene sentido, salvo en raras excepciones, y he de reconocer que en alguna librería o Framework que me he montado he abusado de ellas. Lo suyo es herencia, programar bien, una buen arquitectura evita tener artefactos heterogéneos. Las excepciones? pues realmente 2, los tipos genéricos, y aquellas clases que nosotros no hemos implementado (librería externa, framework .net, …)

Lo haremos con uno de los ejemplos mas claros del mundo, el carrito cutre de la compra.


public class Product
{
   public int Id { get; set; }
   public string Name { get; set; }
   public string Description { get; set; }
   public decimal Price { get; set; }
   public string Category { get; set; }
}

public class ShoppingCart : IEnumerable<Product>
{
   List<Product> products;

   public ShoppingCart()
   {
      products = new List<Product>();
   }

   public void Add(Product product)
   {
      products.Add(product);
   }

   public void Remove(int productId)
   {
      products.RemoveAll(p => p.Id == productId);
   }

   public IEnumerator<Product> GetEnumerator()
   {
      return products.GetEnumerator();
   }

   System.Collections.IEnumerator System.Collections.IEnumerable.GetEnumerator()
   {
      return GetEnumerator();
   }
}

Vale, esto es mejorable, pero simplemente que sirva como ejemplo.

Ahora queremos calcular la suma de las cantidades del carrito … claro, para qué queremos un método de extensión no? pero la verdad es que a veces, si el concepto suma es algo mas complejo, usa recursos, y queremos quedar bien en la empresa, le metemos un método de extensión y LINQ. En principio no es necesario, pero … y si trabajamos con resultados parciales de LINQ? Y si hay resultados que nos devuelven un Array de productos? Lo que queremos es una suma de cualquier colección de productos, que nos sirva para todo, y si acaso, nuestro carrito ya tendrá una propiedad de lectura que llame al método de extensión, y sea Suma {get}.

Acabo de explicar la natura de los métodos de extensión, es decir, atacar sobretodo a interfaces genéricas, para que podamos trabajar donde sea con nuestras operaciones. En eso y las expresiones lambda se basa LINQ, con el cual no podemos vivir desde que apareció.

public static decimal Total(this IEnumerable<Product> productList) 
{
   return productList.Select(pl => pl.Price).Sum();
}

Qué maravilla!!!! y no solo eso, sino todos los herederos de Product, se verán beneficiados. Y si ponemos una interfaz como parámetro genérico, ni te cuento el alcance de esta operación. Que podemos hacer? fijaos en las tres última líneas, una caña!

ShoppingCart cart = new ShoppingCart()
{
   new Product() { Id = 1, Name = "P1", Price = 275M},
   new Product() { Id = 2, Name = "P2", Price = 19.5M},
   new Product() { Id = 3, Name = "P3", Price = 34.95M}
};

Product[] productArray =
{
   new Product() { Id = 1, Name = "P1", Price = 275M},
   new Product() { Id = 2, Name = "P2", Price = 19.5M},
   new Product() { Id = 3, Name = "P3", Price = 34.95M}
};

decimal cartTotal = cart.Total();
decimal arrayTotal = productArray.Total();
decimal linqTotal = cart.Where(product => product.Id > 1).Total();

Lo que mas llama la atención, es como leches el array puede tener acceso a este método de extensión :-O

La realidad es que es algo impuesto por el CLR en tiempo de ejecución, y como se os ocurra modificar sus elementos, os dará un NotSupportedException. Por qué? pues vete tu a saber, pero está desde 2.0, y creo que es por un tema de coherencia de las propiedades del lenguaje. Habeis visto como he inicializado el array de productos? casi casi puedo decir que es un ShoppingCart pero anónimo (aunque los tipos anónimos se incorporaron mas tarde). Creo que la implementación de un array de objetos, hereda de System.Array como base, pero su implementación es la de una o varias interfaces de colección genérica, y Microsoft no lo quiere reconocer 🙂

Dicho esto, espero que hayáis visto en la operaciones del ultimo trozo de código, como podemos usar correctamente los métodos de extensión, o al menos por el cual fue concebido.

Saludos y hasta la próxima

Cuanto tiempo son escribir!!! pero bueno, no esperéis mucho mas de un blog técnico 🙂

Hoy va de pruebas unitarias, para mi las primeras pruebas que han de hacerse, sin excusa, y que deberían ser programadas por otro miembro del equipo, no por uno mismo (salvo si uno es muy riguroso consigo mismo … ejem).

Para quien no esté familiarizado … ya estás tardando en mirar artículos, comprar libro, o que alguien te tutorice. Luego lee esta entrada 😉

En materia. Una de las cosas que no solemos hacer, y yo el primero, es probar que nuestro código “falla”. Esa es la naturaleza de las pruebas, y es mas importante las pruebas que hagan que nuestro código “falle”, que no que nos reafirme en nuestro buen trabajo, y que somos unos hachas. Cuando me refiero a que “falle”, me refiero a que la prueba haga que lo que probamos no termine a través de un resultado, sino de una excepción. Muchos autores y expertos, recomiendan TDD, empezando por una premisa o precondición: nuestro código, métodos, clase o como queramos llamar, va a fallar (y no necesariamente por una mala praxis).

Escenario. Imaginemos que tenemos que importar datos de un excel. No entro en si hacéis TDD o probáis después de programar ¿qué es lo primero a probar? seguro que un alto porcentaje, ha pensado en verificar que los datos se importan correctamente … NOOOOOOO! lo primero, es qué pasa cuando los datos para realizar la importación son incorrectos. Si fuera una exportación, igual, y si acaso con mas importancia, o acaso vais a dejar que el usuario haga un trabajo para que al final se le diga que no puede exportar?

Una vez que tenemos el fallo o error, nos interesa saber si al programar lo hemos tenido en cuenta. Para ello tenemos que controlar que excepción se lanza. Sabremos si lo estamos considerando, si bien traducimos las excepciones a otras mas legibles, o bien las sustituimos por otras propias de la aplicación. Yo uso la combinación de ambas.

Entrando en materia, vamos a probar que al informar de una ruta incorrecta de un archivo excel, se está manejando la excepción. Normalmente lo hará la misma persona, la prueba y la programación de la importación, pero no debiera ser así. Que sean personas diferentes, no implica que un tester no tenga tantos o mas conocimientos de desarrollo que un programador. Como somos unos figuras, sabemos que si accedemos al excel por COM (por ejemplo), al dar una ruta incorrecta, nos va a devolver un COMException. Como persona que pruebo, y sabiendo que posiblemente la importación no dejará de ser una librería usada por terceros, quiero como mínimo una traducción a ArgumentException. La ruta viene en el constructor, lo he hecho así por comodidad, quien quiera estático e inicializar, es muy similar.

[TestMethod]
[TestCategory("Import & Export data")]
[Description("Lanza una excepción controlada, si la ruta del fichero no es correcta o hay problema en carga de fichero")]
[ExpectedException(typeof(ArgumentException))]
public void ExcelPathParameterThrowsHandledException()
{
   ExcelDataProvider excel = new ExcelDataProvider(String.Empty);
   var result = excel.ObtenerDatos();
}

Y aquí viene el objeto de esta entrada. En MSTest, similar a lo que pasa por ejemplo en JUnit, tenemos el atributo ExpectedException, para decir “oye, que si se me lanza esta excepción, la prueba ok”. El problema es que espera EXACTAMENTE esa excepción, y como he comentado, no tiene el tester saber de la implementación interna de lo que prueba. Por ejemplo, puedo lanzar una excepción de este tipo, cuando tengo problemas al cargar el fichero.

public class ExcelPathArgumentException : ArgumentException
{
   public ExcelPathArgumentException() : base("Invalid file path, or excel file not found") { }
}

// Fragmento al inicializar el libro excel
try
{
   _libro = _app.Workbooks.Open(filePath);
}
catch (System.Runtime.InteropServices.COMException)
{
   throw new Exceptions.ExcelPathArgumentException();
}

Si la prueba os va a decir que ni hablar, que no pasa, porque no ha capturado un ArgumentException. Quizá haya quien no trabajé así, pero en mi opinión estamos trabajando con la calidad, y las pruebas muchas veces es nuestro contrato de mínimos. Aún así, el atributo no nos da mucha flexibilidad, y ataca al mantenimiento, porque como cambiemos las excepciones, a cambiar la prueba.

Para solucionar esto, vamos a emular el Assert.Throws de NUnit. Correcciones y otros frameworks, ya sabéis, en comentarios que enriquece. Qué hace NUnit, pues te da la posibilidad de realizar un Assert, pasando el tipo y el fragmento de código a través de un método. Traduciendo, vamos a hacer un método genérico, que admita un tipo de excepción, un delegado (Action) y no de error, si no se lanza la excepción esperada.

public static void AssertExceptionHandling<exception>(Action method)
            where exception : Exception
{
   try
   {
      method.Invoke();
   }
   catch (exception)
   { return; }
   catch (Exception ex)
   {
      Assert.Fail("Unexpected exception: " + ex.Message);
   }
   Assert.Fail("No exception thrown");
}

Doctores tiene la iglesia, pero esto es un buen comienzo, nuestro contrato de mínimos, que podemos ampliar. Límite, la imaginación.

Y ahora sí, ahora envolver todos los métodos que quiera, fragmentos a través de empresiones lambda, etc.

[TestMethod]
[TestCategory("Import & Export data")]
[Description("Lanza una excepción controlada, si la ruta del fichero no es correcta o hay problema en carga de fichero")]
public void ExcelPathParameterThrowsHandledException()
{
   TestUtils.AssertExceptionHandling<ArgumentException>(() =>
   {
      ExcelDataProvider excel = new ExcelDataProvider(String.Empty);
      var result = excel.ObtenerDatos();
   }
   );
}

Hay muchos frameworks que hacen estas cosas, pero bueno, así practicamos un poco. El tema de pruebas es un mundo, pero aún sigue siendo el hermano pobre, al que el presupuesto (en tiempo y/o dinero) siempre le da la espalda. Gran error. Clientes de empresas de software, exijan pruebas, e incluso formen parte de ellas, van a pagar un poco mas, pero los beneficios son tremendos (y ya les digo que el coste de mantenimiento menor).

Hasta otra.

PD: el código está generado para ejemplarizar la entrada.

Adiós Netsaimada

Hace tiempo que tenía pendiente explicar el motivo de dejar Netsaimada, grupo de usuarios de tecnologías de Baleares, aunque lo cierto es que principalmente .Net.

Ha sido un cúmulo de cosas y acontecimientos, que al final me han hecho ver la realidad. Como quiera que no me gusta ser utilizado pues mejor que se lo curren otros.

Netsaimada empezó en Marzo de 2012, a raíz de intentar hacer una jornada acerca de tecnologías Microsoft. En ella hubo gente muy respetada dentro del mundo Microsoft, y la asistencia, aunque siempre soy exigente, fue de mas de 70 personas. Las consecuencias? publicidad para el MICTT y para el Parc Bit, que aunque sin su ayuda hubiera sido mas difícil, fueron los que usaron el evento para promocionarse. En aquel momento, lo daba por bueno, porque el evento estuvo bien, y cumplió objetivos.

Luego vino el Megathon de aplicaciones Windows 8, en el que servidor, puso coche, dinero, tiempo, para que al final venga a tu despacho personal del Parc Bit, y te digan: “Y tu que pintabas en en Megathon?” Pues nada, levantarme a las 7 de la mañana un domingo, ir a por litros y litros de agua, hacer carga y descarga, pagarlo del bolsillo, etc. Eso sí, el Parc Bit no se dignó el Domingo a entregar su premio. Semana después, se ve al director del Parc Bit hablando del Megathon como si fuera un éxito suyo … política? pues conmigo ni hablar. Al menos contaba con la ayuda de Juanma Servera, gestor técnico del MICTT y muy buena gente, un geek de los buenos.

A partir de ahí mi interés descendió, aunque tenía muchas ideas para seguir. Curioso fue cuando por error, recibo un mensaje directo del jefe de evangelización de Microsoft Ibérica, en el cual indica una url donde se puede conseguir fondos para las comunidades técnicas (ojo, no las que hay actualmente). Ni corto ni perezoso, me comenta que ese mensaje no era para mi, pero bueno, que ya tenía constancia de ello. Apoyo cojonudo oiga. Pero bueno, al menos vino al evento (casi lógico siendo de la tierra Balear).

Uno, acababa 2012 sin ningunas ganas de participar, teniendo la sensación de que era utilizado por todos lados. Los compañeros de viaje, como Juanma, cumplían su cuota, ya que a su vez trabaja para el MICTT, y eso está bien, pero yo … al final te das cuenta cuando intentas emprender, que el MICTT compite contigo. Tarde me quité la venda. De todas maneras, no fue el mayor de mis errores, conste en acta.

En 2013, Microsoft abrió una red de comunidades técnicas, dan el MAP, para dar valor según ellos al 5% de los programadores en España, algo que venía de technical rangers … todo fachada. El MAP sirve para consultar, para que seas una simple población estadística, nada mas. Acerca de las comunidades técnicas Microsoft … te dan algo de ayuda para promoción en redes sociales, y alguna cosas mas, si te conviertes en comercial de lo que le interesa. Claro que te regalan Office 365, pero con la esperanza que lo enseñes, no por amor al arte. Deberían dar fondos o recursos para proyectos de comunidad, de aquello que nos apasiona, pero si no nos interesa Office o Azure, pues oiga, lo mismo nos encanta Visual Studio, o desarrollar para Windows Phone o Windows 8 … ah! para eso mejor pedirlo y ya veremos …

Y para acabar, y llamarme celoso si queréis, está el primer MVP de Baleares. Lo primero que tengo que decir, es que si alguien se lo merece en Baleares es Juan Manuel Servera Bondroit, estoy 200% convencido, pero de VISUAL C#???? Quien daba lo de C# en los Megathones? Servidor. Quien hizo mas de 30 artículos en C# WPF XAML en 2012? Servidor. Quien fue portada de la dotnetmania en 2012, y publicación de otro artículo en C#? Servidor. Quien “defendía” las huestes de C# en el grupo de usuarios? Servidor. Quien tuvo en 2008 una de las mejores 5 UI Apps empresariales, tecnología Microsoft en C#/WPF ? Servidor. Y podría seguir. Que quiero decir? no, ni me lo merezco, ni lo quiero pero, como quiera que en el grupo yo era el de C#/XAML, ahora Juanma es la referencia (MVP), por tanto, mi presencia es redundante, y por tanto actúo en consecuencia. Espero que no se me enfade Juanma.

En fin, si quiero quedarme con algo bueno, me quedo con Juanma, Juan Segura, Pau, Adrià, … y demás buena gente que me he encontrado por el camino. De Microsoft? Visual Studio, Azure, C#, XAML, el programa Bizspark, … tiene muchas cosas buenas, pero mas allá de tecnología, hay otras cosas para un aficionado, cuyo hobby es su profesión, aunque con objetivos muy distintos, como es el trato y las aportaciones de recursos que al amigo Microsoft no le costaría nada: Un modelo Bizspak para comunidades técnicas estaría muy bien, de hecho, sería necesario, u os creéis que voy a enseñar CodeLens (una caña de productividad) de Visual Studio, si cuesta un pastizal al año … por poner un ejemplo.

Una vez vomitado, volveré pues a los posts técnicos, que es lo mio, y en Sudamérica gusta. Adios Netsaimada, y suerte!

De twitter, me he de venir aquí, para aclarar un tema, y argumentar con datos, la frase de hoy:

En España, windows phone alcanza a ios, con cuota de 4,3%. Conclusión: desarrolla para android.

Para rebatir esto, se dice que es simplista o falta de información … la fuente es la misma desde la que se tira cohetes y todo es maravilloso, y en 140 caracteres no se puede hacer una tesis. Pues venga, desarrollo.

Primero, en la frase se habla claramente de España, por lo cual la frase está acotada geográficamente. Luego, evidentemente hablo de un mercado determinado.

La segunda es la cuota de mercado, la cual están muy orgullosos, y que personalmente considero un fracaso monumental. “Madre mía!!!! que dice este tio????!!!!” Lo sé, ha habido un ascenso significativo en valores RELATIVOS de venta de dispositivos Windows Phone. Pero las cosas, hay que contextualizarlas, y voy a ello, seguro que entenderéis porqué le llamo fracaso:

  1. Hablamos de alcanzar a IOS en España, un país en plena crisis, y con Apple, no haciendo sus deberes (complicado siempre) de sorprender con cada dispositivo (la competencia aprieta). No hay gama baja de IPhone (lo del 5c es una broma), sin embargo, tenemos Lumias por 129€. Eso sí, los terminales de bajo coste de Nokia Lumia, la relación calidad precio está muy conseguida.
  2. Estamos ante la finalización de una plataforma como Blackberry, cuya cuota de mercado se van a repartir entre las tres grandes. De hecho también ha subido Android e IOS.
  3. En este mismo sentido, hay un dato que suele pasar desarpecibido, y es que de otros dispositivos hay una tasa interanual muy negativa. Mas pastel para las tres grandes plataformas.
  4. Venimos de una obsolescencia programada, lo cual de por sí es grave (y que criticaban tanto desde Microsoft). Venimos de hace poco mas de un año, de cargarnos Windows Phone 7, dar un caramelito con 7.8, y si quieres nuevo SO, te compras otro móvil. Yo hace tiempo, me compré un Lumia 620, porque tenía NFC, por 229€ y muy bien (lo dicho de calidad precio). Es decir, tuve que comprarme otro móvil si quería continuar con WP.
  5. Y por último, se esconde, se obvia, o no sé porque no se es sincero, que Windows Mobile, tuvo mucha mas cuota de mercado que lo que tiene Windows Phone, incluso mantenía regularmente sus ventas a pesar del boom de Symbian. Los datos están en la www y no mienten.
  6. Con estas cuotas de mercado, por cada windows phone que se vende en el mundo, se venden casi 8 Android. La importancia no está en un 8 vs 1, sino en que en el tiempo la brecha en términos ABSOLUTOS es brutal.

Así que ya tenemos España, y que no es para tanto. Vamos, que es como España, con 6 millones de parados, y después de 5 años en crisis, generar unos pocos de miles de puestos de trabajo, y un aumento de PIB del 0,1%, no es que sea un gran logro, por mucho que lo vendan … la tendencia? si quieres tendencias, vete a la moda (con todos los respetos).

La tercera y que supongo escuece, es que aconsejo desarrollar en Android, … quien me conoce, sabe que desarrollo en Java y .Net, Android o Windows [Phone] 8 (proximamente, en IOS). Pero esta parte, es la que quiero completar.

Tu primer esfuerzo debe ser Android si quieres llegar a mas público, o IOS si quieres obtener mas rentabilidad. No lo digo yo, lo dicen todos los clientes a los cuales les vendes propuestas en las tres plataformas, lo dicen los anuncios de la TV (disponible en Android y IPhone), lo dice el mercado, el público, lo dicen los datos de reparto del pastel, y lo digo yo, que he sufrido el error en una apuesta.

Hace un año y medio, hubo una persona, en una ponencia en el grupo de usuarios de .Net, del cual soy cofundador (para que no haya dudas de mis preferencias), se dio una razón para dedicar tus primeros esfuerzos a Windows Phone: “Va muy bien para hacerte una idea de lo que va a ser tu aplicación, y después desarrollas en las otras plataformas”. Evidente, Visual Studio es lo mejor de lo mejor, lo mas productivo que ha parido madre (personalmente por encima de Borland de antaño).

Evidentemente, en toda organización, debiera haber 6 grupos  de personas identificables, a los que trabajan y se ganan su pan con ellos, les toca ser defensores o “conseguidores”, yo puedo permitirme el lujo de ser escéptico o crítico. Como lo comprendo, no rebato sus alusiones, restando importancia o capacidad a lo que uno dice.

En España, windows phone alcanza a ios, con cuota de 4,3%. Conclusión [corregida]: sea cual sea tu mercado, centra tus primeros esfuerzos de desarrollo en Android o IOS. 

Y ahora vais, y miráis las 50 top apps de cada plataforma, sacad vuestras conclusiones.

Siento la chapa 🙂 y que nadie se sienta molesto … espero. Sé feliz y desarrolla donde te guste. Hasta otra.

Este post viene provocado por la lectura de un artículo de Juan Carlos Quijano en xataka windows. No trato de rebatir nada, ni siquiera el artículo, que me parece correcto.

Lo que voy a intentar explicar, es que un 90% de cuota de mercado en PC’s, hoy día es irrelevante, además de hacer un símil entre Microsoft y la clase política actual (salvando las distancias).

Los datos

En el artículo, se muestra una serie de gráficas extraídas de NetMarketShare. No seré yo quien las rebata, mas aún cuando no tengo medios para medirlo. Lo que sí voy es a contextualizarlas, y a poner un pero.

Las gráficas de desktop (pc de toda la vida), tienen mucho menos valor que las de hace años. Realmente no sé como se hace la medición, pero si es por audiencia, mal vamos. Si es por ventas o provisión peor, porque los linux suelen ser instalados a posteriori, y no solo eso, hay pc´s sin uso. De todas formas a lo que iba.

Que una gráfica macro, muestre que los pc´s está copados por Microsoft, es como cuando nos cuentan que exportamos mas, que el interés de deuda baja, etc. Vamos, que la macroeconomia va a mejor. No nos vale a pie de calle, se nos escapa, no hay repercusión. Estos datos son similares.

No entiendo la segmentación de productos … acaso no hay móviles que son mas potentes que algunos pc’s con XP, los cuales se están contextualizando? acaso las tablets, móviles, y distintos dispositivos, son herederos de la arquitectura von neumann? acaso los usuarios no están en muchas ocasiones consumiendo los mismos servicios que en un pc?

Lo siento, pero estas segmentaciones interesadas no me convencen, deberíamos hablar de unidades de consumo, da igual la forma de consumir, si hay un sistema operativo detrás, se contabiliza y punto. Que desde Microsoft, nos den la vara con este tipo de cifras, es el primer punto a la que se parece a un político (datos segmentados e interesados).

Los cambios

A las personas, al ser humano, le horrorizan los cambios, los cuales provoca incertidumbre a unos animales racionales.

Detrás de los datos, hay un tema para pensárselo y mucho. Con unos datos tan abrumadores, como es posible que Windows 8 tenga unos datos tan paupérrimos? es un fracaso del propio Windows 8? es la gente, que tiene miedo al cambio? Bueno, yo pongo la mía, cada uno tendrá sus opiniones, las mías están basadas en conversaciones con profesionales, familiares y amigos, la calle:

  1. Curva de aprendizaje del usuario: No sé si es culpa de Sinofsky, de Ballmer, o de algún iluminado, pero la cagada en este aspecto ha sido monumental, simple y llanamente por poner una tienda. No, no estoy en contra del nuevo inicio, ni de nuevas interfaces, ni nada de eso, sino de uso que se debe hacer del ratón para acceder a ciertos lugares, y lo que mas me irrita, es que está pobremente contextualizado. Estos genios, empezaron pensando en táctil, y una vez listo, pues a ver como hacían lo mismo con ratón. Lo mas triste de todo, es que ha vuelto el pseudo menú de inicio, que no ha contentado a nadie (algo que predije en Marzo de 2012, delante de algunos de Microsoft Ibérica, Plain Concepts, … se rieron entonces …). La percepción de TODOS los usuarios de Windows, es que Windows 8 es mas difícil de manejar, y esta sensación es unánime, no se trata del menú de inicio, ni de la nueva interfaz, no, se trata de que simplemente, para la audiencia de Windows PC de toda la vida, es infumable.
  2. Marketing:  Vamos a ver, la gente quería WINDOWS!!!! y cada vez que veíamos nuevas imágenes del SO, o pasábamos por una tienda, veíamos “METROWS”. En vez de decir que eso era windows, se debería haber dicho que tiene algo mas, mas posibilidades, decir lo que es cierto, que windows 8 es mucho mejor como SO, y que eso que veis nuevo, es para dar un plus, para acceder a nuevos tipos de apps, y para ir al mundo táctil, nada mas. Error grave en mi opinión.
  3. Cambio de tendencia: casi estoy convencido, que cuando se inició el desarrollo de Windows 8, se empezó pensando en un dispositivo que no existía por aquel entonces, el híbrido, y que después han intentado vender, de momento, sin éxito. Llegando tarde a todas partes, el pastel estaba repartido, y visto lo visto por su apuesta, se reconoce la muerte lenta del pc como unidad de consumo. En este contexto, se ha sacado algo que no ha acabado de convencer al usuario de WINDOWS.

No os imagináis lo que me cuesta defender Windows 8 a pie de calle, como convencer de que es mucho mas rápido, mucho mejor que Windows 7. Windows 8 es mejor a día de hoy, de lo que fue en su momento XP sp3. Pero me rindo, en 8.1 la han cagado aún mas, la búsqueda, la vista compartida (ya no es acoplada), y venga, ahora una tercera pantalla, escritorio, inicio y vas a abajo programas, que es con un botoncito hacia abajo en PC desde inicio, y un botoncito hacia arriba, TAMBIEN ABAJO, cuando estas en programas, veis a lo que me refiero?

Microsoft, como los políticos, no viven el día a día de sus usuarios, y si lo hacen, no les entiende.

Costumbres

Otra de las cosas que nadie habla, y que contentan a todas las casas, Apple, Microsoft y demás, son las costumbres de la gente. Hablamos de número de dispositivos o SO, cuando a día de hoy se debe hablar de consumo, de cuanto tiempo dedicas a una cosa u otra.

Quien tiene en casa lo siguiente: Un pc, una tablet, un móvil, el móvil de la pareja, la hija adolescente, el portátil de trabajo o estudio, … claro, ahora segmentamos y todos contentos, yo arraso en PC, y vosotros en dispositivos móviles. Nooooooo, no nos engañemos, el negocio en este sentido está en CUANTO Y COMO usas cada cosa.

Mirad, si en los 90, el de Winamp hubiera sido ágil a nivel publicitario, hubiera sido el Google de antaño. Hoy sí sabemos que está ahí el negocio, pero ya no en pc, sino en los otros dispositivos. Por tanto, un 90% de pc’s es irrelevante.

Microsoft vuelve a actuar como un político, al ignorar los cambios sociales que se dan a su alrededor, o mas que a ignorar, a reaccionar en tiempo y forma adecuados.

Modelos de negocio

Para acabar, tenemos un modelo de negocio, que tarde o temprano, Microsoft deberá cambiar, las licencias. Sí que es importante tener un 90% de pc’s cuando eso te produce ingresos por licenciamiento, pero … ni por 15€!!!!!!!! no sé cuando empezará a entender, que el licenciamiento, las ganas de cobrar varias veces por lo mismo, se han acabado. Apple ha empezado a entenderlo.

Ejemplos? como se come que en azure, una misma maquina virtual, me cueste un 33% mas si es Windows que si es Linux … pero en qué mundo vivimos??? Osea, pago a Microsoft por una máquina virtual, y también por el SO??? de locos. A su vez, cuando un usuario compra una app por la Store, seguramente ha pagado la licencia de uso del software (Windows), ha pagado por el programa, y el desarrollador, mínimo ha pagado un 20%-30% mas cuota anual. Es que en Apple pasa lo mismo … sí, pero con éxito.

Donde vas Microsoft? Te has querido quedar en medio, que si híbridos, que si pc’s táctiles, que si modelo entre google y apple, que si … yo te cuento el futuro: VAS A SER EL NUEVO, ANTIGUO IBM.

Como el político que acaba su trabajo a nivel popular, y que no gana elecciones porque la gente no le quiere, vas a quedar relegado al mundo empresarial.

Hace unos años, empecé a hacerme experto de WPF y MVVM, leyendo entre otros a Josh Smith. Era un MVP, y muy considerado dentro del mundo .NET, una voz a escuchar y del que aprendí muchas cosas. En 2010 dejó Microsoft. Hoy, años después, he comprado un libro suyo, “Programación en ios para desarrolladores .NET”.

Desahogado ya … a otras cosas 🙂

Hoy voy a acabar con la parte de escritura de código del desarrollo ágil. Nos centraremos en el formato, ese gran olvidado, que muy poca gente cuida.
Imaginaos un libro en el cual no se respetara el uso de comas, puntos, puntos y aparte, capítulos, … conseguiremos leer el libro? sí, conseguiremos entenderlo? a duras penas, releyendo una y otra vez.
Pues lo mismo pasa con el código, hacer su lectura mas amena, hace que ahorremos mucho dinero a nuestra empresa, dolores de cabeza a nosotros mismos o compañeros de trabajo, y ayudará a que nuestro código sea reconocido.

Si empezáis en esto, pensad en un periódico, nuestro código debe seguir una reglas y estructura: cabecera, títulos, ordenar de mayor a menor importancia, …

Para el formato, simplemente voy a dar una serie de directivas recopiladas de diferentes libros:

  • Los métodos o funciones deben: organizarse verticalmente según las dependencias, es decir, de arriba a abajo, y que cada método esté próximo del cual depende, o bien que sea afín conceptualmente. Como mínimo, deben colocarse de mayor a menor nivel de abstracción.
  • No debería superarse los 120 – 140 caracteres por linea.
  • Dejad una línea en blanco para agrupar conceptos.
  • Encapsular con espacios en blanco lo que queramos destacar. Por favor, ya no se lleva eso de las estrellitas :-/
  • Respetad, como si de Phyton se tratase, el sangrado entre ámbitos.
  • Cada sentencia una linea … la lineas kilométricas anidadas, no son “cool”.
  • Sensación de densidad vertical, las lineas de código fuertemente relacionadas, deben estar compactas, juntas.
  • La declaración de variables, deben estar lo mas próximo a su uso posible. Aquí podemos chocar en el ámbito de declaración, así que lo dejo en temporales o locales.
  • Las propiedades o campos deben declararse al principio.
  • Personalmente, me encanta que todo el ámbito privado esté al final, independiente de la relación. Por ejemplo, si implementamos una interfaz, se destaca lo público, la implementación, y lo privado lo situamos en último lugar.

Las herramientas de desarrollo, no proveen de potentes utilidades de formato, pero a veces no es suficiente, y debemos hacer un esfuerzo.

Con esto acabamos el cómo escribir código de manera clara, simple, concisa, y ordenada. Han sido varios capítulos, aburridos, quizá sin aportar mucho para los lectores, pero que hacen ahorrar un dineral en mantenimiento. Aquí queda, en www.

Ahora haremos un poco de diseño, algunas leyes que seguro hemos olvidado, y empezaremos a refactorizar.

Hasta la próxima

Retomando lo que me gusta

Después de 4 meses de árduo trabajo, vuelvo a mis labores bloggeras, para vomitar un poco mas del curso de desarrollo ágil, poner algunos articulos, y relanzar netsaimada … mientras esté en desempleo, a soltar articulos varios 🙂

Hoy para retomar el asunto, uno cortito, y es que estoy acabando un control de acceso “low cost” con un lector nfc usb, una pantallita wpf o también con servicio de windows, y un poco de C#. Proximamente lo quiero hacer con una Raspberry pi, una pantallita oled, y un lector 🙂

Con todo, resulta que el lector, al leer un sector, me devuelve un string en hexadedimal … no, no un byte[], un string. Claro, me veo en la tesitura de traducirlo. Pues bien, aunque no sea lo mas optimo, he hecho una cosilla que es mas molona, y que demuestra el “pagüer” de LINQ.

Tenemos un string, que debemos pillar como words, es decir base 16. por tanto, he de recorrer de dos en dos, hacer un substring, … para, para!!!!! ya está, eso es todo, Como lo podemos hacer con LINQ? pues nada, la receta es la siguiente:

  1. Creamos un array de la longitud del string
  2. Filtramos los pares
  3. Del resultado, hacemos una selección de pares de caracteres en el string fuente
  4. El resultado que sea una byte[]
  5. los convertimos en un string reconocible 🙂

Dificil? que va!!! ahora los traducimos al mundo C# 🙂

  1. Usamos Enumerable.Range, que el muy majo no devuelve un IEnumerable<tipo> en este caso int
  2. Luego filtramos por LINQ, nuestro amigo WHERE
  3. A continuación hacemos un SELECT, TAMBIÉN con LINQ, pero ojo, la expresión lambda debe tener como valor devuelto, la subcadena que nos interese de nuestro string origen
  4. A su vez, hacemos un Convert.ToByte (chupao)
  5. System.Text.Encoding.UTF8

Que me complico la vida? claro que sí, sino no seria divertido. Yo es que me he propuesto evitar bucles, condicionales, y demás.

public static string ConvertFromHexadecimal(string source)
{
   IEnumerable<int> range = Enumerable.Range(0, source.Length);
   var modul = range.Where(x => 0 == x % 2);
   var select = modul.Select(x => Convert.ToByte(source.Substring(x, 2), 16));
   return System.Text.Encoding.UTF8.GetString(select.ToArray());
}

Ahora lo que queda es incrustarlo todo en una linea, pero bueno, para una entrada, mejor así.

Miré a ver si había mejores opciones por el mundo www, y a parte de haber muchas similares, hay otras muy chulas.

A ver si este finde acabo el tema de formateo, y nos ponemos con la refactorización en desarrollo ágil.

Hasta la vista

Hoy voy a hacer un paréntesis en el tema del cursillo, para escribir unas lineas desde mis adentros.

No, no me he equivocado en el título, no quería decir gestión del conocimiento, sino del desconocimiento, que es un conjunto complementario de ignorancia, al conocimiento inherente en toda empresa o persona.

Durante toda mi vida profesional (va para 15 años) o informal en tecnología (vamos para los 23), me he encontrado con una mentira, que a fuerza de repetirse se convierte en verdad, y que maneja las modas tecnológicas de nuestro tiempo: Lo mejor es lo que domino, lo que conozco o en lo que tengo experiencia.

No voy a entrar en las fans, que lo único que conocen en un 90% es su propia plataforma, y que no se han preocupado de probar o conocer otras alternativas, evaluarlas, medirlas, …

A lo que voy, es que bajo esa verdad ficticia, se esconde la falta de innovación, investigación y formación en empresas y profesionales (existen excepciones). A partir de ahora indistintamente utilizaré empresas, personas o profesionales, es extrapolable.

Si las empresas supieran gestionar el desconocimiento, si caminaran un poco, a través de aquello que no controlan, dominan o nunca han utilizado, lo mismo, quizá nos llevaríamos una sorpresa en cuestión de costes, inversión, beneficio. Pero … como leñe se gestiona el desconocimiento?  como analizo el riesgo? la rentabilidad? no tengo respuestas a todo, pero empezaría por un DAFO, eliminando la Fortaleza … si, porque las fortalezas, aun cuando las debemos aumentar, como buenos latinos, nos dejamos llevar por lo buenos que somos 🙂

Cuales son nuestras debilidades, y amenazas a día de hoy, según nuestro grado de desconocimiento? que es lo que no sabemos, pero que somos conscientes que funciona? como podemos eliminar nuestras debilidades? como minimizar las amenazas y aprovechar las oportunidades? pues con conclusiones:

  • Nuestras debilidades se eliminarán con formación complementaria.
  • Nuestras amenazas se limitarán con investigación.
  • Nuestras oportunidades se aprovecharán con innovación.

Evidentemente, no se puede controlar todo, ser un gurú de todo lo que se mueve, pero hay otras opciones, y la que mas me agrada son las sinergias a través de compartir fortalezas. Sí, ya sé que nada de fortalezas, porque no deberíamos detectarlas en este caso en nosotros, sino en otras empresas o personas, con el fin de compartir conocimiento.

Esto es casi utópico, y mas en el entorno geográfico donde me muevo, pero creo que sería una chispa muy interesante, aunque todo empieza por empezar a gestionar aquello a lo que somos ajenos, algo que casi nadie se preocupa.

En fin, esto es una pincelada de una idea personal, y no hay nada como compartirla … lo mismo a alguien le gusta y se puede desarrollar.

Un saludo! nos vemos!

Buenas, la vuelta de vacaciones va a ser dura, así que comienzo con un articulo sobre mi opinión acerca de los comentarios. Básicamente es: NO comentes el código.

Lo siento, es mi forma de proceder desde hace 7 años, y la verdad, aún nadie ha venido a decirme que le explique qué hace esto o lo otro (normalmente porque cuando cambio de trabajo, lo que dejo no lo debe tocar nadie XD)

La justificación? pues …

  • Los comentarios suelen mentir, ya que la mayoría intentan explicar el código, y nunca con el rigor necesario. Los que tienen rigor, lo que hacen es crear código legible, sin necesidad de comentarios.
  • No se suelen mantener a lo largo del tiempo, porque como es evidente, es mas sencillo cambiar el código, que no seguir comentando. Los productivos, cambian al código, en vez de comentar. Si mantener código es complejo, ni que decir tiene que los comentarios añaden tiempo y esfuerzo = $$$
  • Suelen avisar de posibles problemas. Este es el mejor, no os habéis encontrado con este comentario, es genial, te advierte: oye! que si no se cumple esto o lo otro, falla! muy cachondo. El programador correcto, hace el código fiable, en vez de comentar.
  • Justificación de acoplamiento. Parecido al anterior, nos indica que esta clase u objeto necesita de este y el otro. El programador ágil, cohesiona, no acopla.
  • y así una larga lista, que seguro que mucho de vosotros habréis sufrido en vuestras carnes.

No hay que comentar nunca? tampoco! existen algunos factores que nos pueden hacer poner algún comentario, pero siempre corto y conciso.

  • Autor, derechos o licencias del código
  • Informativos a nivel técnico. De estos se encuentran a faltar, por ejemplo referencias a documentación de alguna librería, o alguna tarea con código de alta dificultad técnica. Un ejemplo? explicar un expresión regular.
  • Realizar advertencias. Como por ejemplo, comentar las clases que se encarguen de la auditoria de la LOPD.

Para acabar os voy a dejar con los comentarios, que seguro no son necesarios. Si los encontráis, liquidadlos! 🙂

  • Balbuceo: el mas común, se explica algo de forma no muy clara.
  • Redundancia: el mismo comentario por todo el código.
  • Confusos: dan a entender acciones no previstas.
  • Periódicos o D¡de modificación: anda, usa un TFS o Mylyn.
  • Sobrantes: cuando el nombre de variable o método indica perfectamente su propósito.
  • Marcadores de posición.
  • Asignaciones o menciones: el típico para dejar huella o hacer de chivato. Esto es responsabilidad de menganito y me lavo las manos, o esto lo he hecho yo, que soy el piiiii amo.
  • Demasiada información: que te indiquen quienes participan en la decisión de implementar un método, con detalles de hasta la comida de olla del jefe 🙂
  • Y por ultimo, lo mas importante, lo mas sagrado … ELIMINA EL CÓDIGO COMENTADO!!!! haz un favor a la humanidad.

Pues nada, la próxima irá de formato, que no es moco de pavo, ni menos importante que otras cosas, y acabamos con el tema de escritura. Después empezaré con objetos y estructuras de datos, desde iniciación a experto (o casi, donde llegue yo 🙂

Nos vemos!!!

Cuando intentamos escribir métodos, no nos paramos a pensar que son los capítulos de la novela que estamos escribiendo. Nunca nos paramos a pensar que un método, procedimiento o función, es la primera línea de legibilidad de un fuente.

Lo mas importante para un método, es que cumpla con el principio de responsabilidad única, la cual podemos oler que la estamos rompiendo si:

  • Existen distintos niveles de abstracción que no le corresponden, bien porque se entra en detalle, bien porque se entra en generalidades que están fuera de ámbito. Por ejemplo, el método HacerPaella, no debería encargarse de definir comos e hace el fondo (delegar), ni tampoco de emplatar la paella (de eso se encarga el camarero).
  • Si el código puede separarse en secciones con distinto significado. Si HacerPaella tiene todos los pasos de hacer el fondo, el caldo, de echar arroz y reducir, de hornear, reposar, … HacerPaella no es un método, es un resultado, y los métodos son procesos, no resultados. Pensad así y veréis como cambia el punto de vista de lectura de fuentes.

Hay que tener en cuenta, que tampoco debemos granular ni muy fino, ni muy gordo nuestro código. No cortemos métodos porque sean largos, solo cuando hagan mas de una cosa. Tan malo es que hagan mas de una cosa, como que varios métodos hagan partes de una responsabilidad que conceptualmente pueden ser atómicas. Tampoco hagamos métodos de una línea, ni de 3000 (aunque en algunos lenguajes como COBOL, nos lo vamos a encontrar)

Debemos usar nombres descriptivos, a ser posibles verbos con palabras clave, como ya comentamos en el post anterior.

Los argumentos … esos argumentos … como veremos en refactorización, lo que se desea es que la firma de un método sea lo mas simple posible. En algunos casos, el lenguaje, como por ejemplo C# no ayuda a simplificar 🙂 es tan bueno, que te aficionas a meter parámetros opcionales, con valores por defecto, los cuales parecen inocuos.

Uno de los temas fundamentales, es que los métodos, no tengan efectos secundarios, como los medicamentos. Esos métodos que se llaman CompruebaClaveDeAcceso, y que de repente, te encuentras que te ha autenticado contra un servidor :-O

Por favor, no usemos códigos de error, eso es de novatos o gente de mordor. Las excepciones nos van a obligar a ser mucho mas eficientes a la hora de manejar errores. Los códigos de error son nidacos de dependencias y acoplamiento.

Por último, intentemos no repetir código, refactorizemos, saquemos factor común, y usemos la materia gris para transformar la escritura 100 veces del mismo bloque, en un método, procedimiento o función.

Y ahora llegamos a tema discusión del día, la programación estructurada. Veréis, un tal Dijkstra dijo que una rutina, tienen un único punto de entrada, y un único punto de salida, pero claro, las modas se están llevando a vejuno este por delante, debe ser un carca. Algunos autores destacados, vienen a decir que si la rutina es pequeña, no hace daño un return o un break … mala gente! no veis que somos animales de costumbres, y además, cual es la frontera?

Mi punto de vista va mas por Dijkstra, y es que eso de “si condicion entonces return” … me da escalofríos. En mi modesta opinión, si tenemos mas de un punto de salida, es porque tenemos varias condiciones de las mismas, y por tanto una complejidad y coste en rendimiento mayor. Yo no renuncio a que haya mas de un punto de salida de un método, pero siempre que se haya cumplido el objetivo por el cual se creó dicho método. Lo comento por cosas como “si el parámetro es nulo, entonces return” NOOO!!! lo siento, me niego.

Uno de los enemigos de todo esto que hemos explicado ahora, son los condicionales, y entre ellos hay el monstruo del lago ness, nuestro queridísimo amigo SWITCH … CASE:

  • Hace que el código sea mas grande.
  • No cumple con Dijkstra.
  • Favorece la repetición de código.
  • Es desestructurado.
  • Suele incumplir con SRP y OCP.

Pues bien, veremos (y me ha servido de mucho para mi saludo mental) como con patrones y técnicas de refactorización, aislarlos y disminuir sus visibilidad, para que tenga menos impacto en nuestro sistema. De hecho lo llegaremos a eliminar, o como máximo que salga una sola vez.

Para el siguiente, si no este se hace eterno, escribiré acerca de los comentarios, o mas bien de NO comentar 🙂

Hasta la próxima