Autor en Google+
Saltar al contenido

Artículos, tutoriales, trucos, curiosidades, reflexiones y links sobre programación web ASP.NET Core, MVC, Blazor, SignalR, Entity Framework, C#, Azure, Javascript... y lo que venga ;)

15 años online

el blog de José M. Aguilar

Inicio El autor Contactar

Artículos, tutoriales, trucos, curiosidades, reflexiones y links sobre programación web
ASP.NET Core, MVC, Blazor, SignalR, Entity Framework, C#, Azure, Javascript...

¡Microsoft MVP!
Mostrando entradas con la etiqueta buenas prácticas. Mostrar todas las entradas
Mostrando entradas con la etiqueta buenas prácticas. Mostrar todas las entradas
martes, 23 de marzo de 2021

Como probablemente ya sabréis, NDepend es una de esas herramientas que están ahí de siempre, ayudando a desarrolladores y arquitectos a mejorar la calidad de nuestro software gracias a sus potentes y flexibles herramientas de análisis de proyectos.

Hace tiempo ya echamos por aquí un vistazo, pero creo que es interesante darle otra vuelta y refrescar conocimientos.

Estos contenidos se publican bajo una licencia de Creative Commons Licencia Reconocimiento-No comercial-Compartir bajo la misma licencia 3.0 España de Creative Commons

martes, 18 de diciembre de 2018
ASP.NET Core MVC Hace unos días publicaba un post sobre la mala idea que era tener controladores con demasiadas responsabilidades y cómo un constructor con demasiadas dependencias podía ser una señal (un 'code smell') de que las cosas no estaban yendo bien en ese sentido.

Por ejemplo, echando un vistazo al siguiente controlador podemos ver claramente una violación del Principio de Responsabilidad Única (SRP) en un controlador que conoce demasiados detalles sobre la forma de proceder al registrar un pedido:
public class OrderController: Controller
{
    private readonly IOrderServices _orderServices;
    [...] // Other private members

    public OrderController(IOrderServices orderServices, IUserServices userServices, 
        IMailingService mailingServices, ISmsServices smsServices, 
        IPdfGenerator pdfGenerator, IMapper mapper
    )
    {
        _orderServices = orderServices;       
        _userServices = userServices;
        [...] // Other assignments...
    }

    [HttpPost]
    public Task<IActionResult> Submit(OrderViewModel orderViewModel)
    {
        if(!ModelState.IsValid)
        {
            return View(orderViewModel);
        }
        var orderDto = _mapper.Map<OrderDto>(orderViewModel);
        var orderResult = await _orderServices.AddAsync(orderDto);
        if(!orderResult.Success)
        {
            return RedirecToAction("OrderError", new { error = orderResult.Error }));
        }
        var userPreferences = await _userServices.GetNotificationPreferencesAsync(CurrentUserId);
        var pdfUrl = await _pdfGenerator.GenerateOrderAsync(orderResult.Details);
        if(userPreferences.NotificationMode == NotificationMode.Sms)
        {
            await _smsServices.NotifyNewOrderAsync(orderResult.Details, pdfUrl);
        } 
        else 
        {
            await _mailingServices.NotifyNewOrderAsync(orderResult.Details);
        }
        return RedirectToAction("ThankYou", new { id = orderResult.Details.OrderId } );
    }
    ...
}
En dicho post comentaba también algunas cosas que podíamos hacer para solucionar el problema, así como una recomendación de lo que no debíamos hacer: disimular dependencias instanciando directamente componentes o utilizando otros "sabores" de inyección que hicieran menos evidente la relación de nuestra clase con otras de las que depende.

Pues bien, como hoy estamos algo rebeldes, vamos a ver las técnicas que nos permitirían hacerlo cuando sea necesario o, dicho de otra forma, qué alternativas tenemos para usar dependencias desde los controladores sin que estas sean suministradas mediante inyección en su constructor.
Precaución: estas técnicas son consideradas antipatrones o, como mínimo, code smells en la mayoría de los escenarios, así que usadlas poco, con precaución y siempre con conocimiento de causa ;)

Estos contenidos se publican bajo una licencia de Creative Commons Licencia Reconocimiento-No comercial-Compartir bajo la misma licencia 3.0 España de Creative Commons

martes, 27 de noviembre de 2018
Desarrolladores Como sabemos, la inyección de dependencias está grabada a fuego en los genes de ASP.NET Core. La mayoría de sus componentes la usan internamente para obtener acceso a otros componentes que necesitan para cumplir sus funciones y, además, es una práctica recomendada en la parte que nos toca a nosotros como desarrolladores de aplicaciones.

Por ello, en ASP.NET Core MVC, lo habitual es que implementemos nuestros controladores atendiendo a este principio, y para ello utilicemos la técnica de inyección de dependencias en el constructor:
public class InvoiceController: Controller
{
    private readonly IInvoiceServices _invoiceServices;
    private readonly IMapper _mapper;
    private readonly ILogger<InvoiceController> _logger;

    public InvoiceController(
        IInvoiceServices invoiceServices, 
        ILogger<InvoiceController> logger,
        IMapper mapper)
    {
        _invoiceServices = invoiceServices;
        _logger = logger;
        _mapper = mapper;
    }
    ...
}
Nota: aunque en este post estemos hablando de controladores ASP.NET Core MVC, las ideas que vamos a comentar aquí son también aplicables a ASP.NET MVC "clásico" e incluso a otro tipo de frameworks que comparten los mismos conceptos.

Estos contenidos se publican bajo una licencia de Creative Commons Licencia Reconocimiento-No comercial-Compartir bajo la misma licencia 3.0 España de Creative Commons

martes, 2 de octubre de 2018
¿Qué podría salir mal? Pues como uno que os habla, seguro que muchos de vosotros habéis comparado miles de veces si un objeto es nulo utilizando un patrón de código C# como el siguiente:
var invoice = _invoiceRepository.GetById(18);
if(invoice == null) 
{
    // Hacer algo
}
¿Qué podría salir mal, verdad?

Pues aunque pueda parecer raro, hay casos en los que la comparación anterior no funcionaría bien... o mejor dicho, no funcionaría como esperamos.

Hace unos días leía un post de Khalid Abuhakmeh en el que hacía referencia a una charla de Channel 9 en la que Mads Torgersen recomendaba no utilizar la doble igualdad para comparar con null (minuto 33:00, aprox.)

Estos contenidos se publican bajo una licencia de Creative Commons Licencia Reconocimiento-No comercial-Compartir bajo la misma licencia 3.0 España de Creative Commons

jueves, 28 de diciembre de 2017
Aunque por aquellos tiempos ya llevaba bastante tiempo enganchado al desarrollo de software, fue en el año 1992 cuando empecé mi andadura profesional en este mundillo, y he de decir que estos más de veinticinco años han dado para mucho. Poco más o menos, creo que he pasado por todos los roles existentes en el mundo del software, en todas las modalidades laborales posibles: programador, analista, consultor, formador, coordinador de equipos de desarrollo, CTO, empleado, empresario, freelance

Aparte de muchas alegrías y algún que otro disgusto, lo que tengo claro es que esta trayectoria me ha dado una visión bastante amplia de cómo funciona el mundo del desarrollo de software y las personas que trabajamos en él.

Winner Como guardarme estos conocimientos me parecía demasiado egoísta, he decidido compartir con todos vosotros los que considero que son los diecisiete consejos definitivos que debéis seguir si queréis triunfar en el mundo del desarrollo de software.

Por lo que he ido aprendiendo estos años, seguir estas reglas os llevará a conservar indefinidamente vuestros empleos o clientes, aumentaréis vuestro valor en el mercado, mejoraréis salarios y vuestro grado de felicidad y satisfacción personal crecerá hasta límites insospechados.

He de decir que, antes de compartirlos con todos vosotros, varias personas ya los han seguido y sus vidas profesionales han mejorado considerablemente. Por ejemplo, Juan M. R. trabajaba como programador junior en una conocida cárnica hace 6 meses y hoy dirige el equipo técnico en una startup en San Francisco. También, Nacho G. L. pudo firmar hace poco el contrato fijo con el que soñaba, incluso con un aumento de sueldo. Rafael P. G. era un programador del montón y ahora es un reputado project manager por el que se pelean las mejores empresas del mundo.
“Sin los grandes consejos de José María,
mi vida como desarrollador seguiría siendo un infierno”
– Ricardo M. C., 2017
Podéis ser los próximos en dar el salto, sólo depende de vosotros.

Estos contenidos se publican bajo una licencia de Creative Commons Licencia Reconocimiento-No comercial-Compartir bajo la misma licencia 3.0 España de Creative Commons

martes, 2 de febrero de 2016
Ojo a los autobusesMe encanta encontrar definiciones más o menos conocidas de conceptos o ideas que se nos han pasado por la cabeza en algún momento sin saber que otros ya les habían dado forma, porque demuestra que todos los que nos dedicamos a esto tenemos poco más o menos las mismas inquietudes.

En este caso, me ha entusiasmado dar por casualidad con el "bus factor", un término que seguro muchos conocíais pero para mi ha sido un descubrimiento reciente, que básicamente da forma a la pregunta que seguro que todos nos hemos hecho sobre la continuidad de algunos proyectos ante determinados acontecimientos inesperados.

Imaginemos que todo el equipo de desarrollo de un proyecto va caminando por la calle, y un autobús que circulaba cerca pierde el control y les arrolla de forma violenta. ¿A cuántos miembros del equipo tendría que afectar fatalmente este accidente para poner en gran peligro la continuidad del proyecto?

Estos contenidos se publican bajo una licencia de Creative Commons Licencia Reconocimiento-No comercial-Compartir bajo la misma licencia 3.0 España de Creative Commons

martes, 26 de mayo de 2015
Los diez mandamientosDecía Larry Wall, creador de Perl, que una de las cualidades más destacables de un desarrollador es su orgullo desmedido. En su justa medida es una virtud interesante, pues permite asumir retos, enfrentarse a problemas complejos y crear software increíble, pero llevada al extremo puede ser peligrosa si se deja campar a sus anchas en un equipo de trabajo o proyecto.

Y ya se dieron cuenta de esto los padres de la informática, aquellos pioneros que hace cincuenta años andaban sentando las bases sobre las que se sustentan las tecnologías, herramientas y lenguajes que utilizamos hoy.

The Psychology of Computer ProgrammingLa programación sin ego, o egoless programming, es una forma de programar basada en el aprendizaje continuo y colaboración entre personas, dejando de lado los aspectos puramente personales y comportamientos ególatras que podemos tener algunas veces. La idea fue acuñada por Jerry Weinberg en su libro The Psychology of Computer Programming, publicado publicado en 1971.

En este libro aparecieron por primera vez los Diez Mandamientos del Egoless Programming, que creo que deberían ser unas normas de lectura y aplicación obligatoria en nuestra profesión.

Los Diez Mandamientos del egoless programming

1. Entiende y acepta que cometerás errores. 
La cuestión es encontrarlos pronto, antes de que lleguen a producción. Afortunadamente, salvo para los pocos que desarrollan software de guiado de misiles, los fallos tienen raramente consecuencias fatales en nuestra industria, así que podemos, y deberíamos, aprender, reírnos, y seguir adelante.

2. Tú no eres tu código.
Recuerda que el objetivo de una revisión es encontrar problemas, y se encontrarán problemas. No te lo tomes personalmente cuando un error tuyo se descubra.

3. No importa cuánto “karate” sepas, siempre alguien sabrá más.
Esa persona puede enseñarte algunos movimientos nuevos si se lo pides. Busca y acepta información de otros, especialmente cuando piensas que no es necesario.

4. No reescribas código sin consultarlo antes.
Hay una fina línea de separación entre “corregir código” y “reescribir código”. Conoce la diferencia y realiza los cambios en el marco de una revisión de código, y no actuando como un justiciero solitario.

5. Trata a los que saben menos que tú con respeto, educación y paciencia.
La gente no técnica que trata con desarrolladores de forma frecuente casi siempre tienen la opinión de que en el mejor de los casos somos divas, y en el peor, llorones. No refuerces este estereotipo con ira e impaciencia.

6. La única constante en el mundo es el cambio.
Permanece abierto a ello y acéptalo con una sonrisa. Mira cada cambio a tus requisitos, plataforma o herramientas como un reto, no como un inconveniente contra el que hay que luchar.

7. La única autoridad real deriva del conocimiento, no de la posición.
El conocimiento genera autoridad, y la autoridad engendra respeto. Así que si quieres ser respetado en un entorno egoless, cultiva el conocimiento.

8. Lucha por lo que crees, pero acepta la derrota con deportividad.
Entiende que a veces tus ideas serán ignoradas. Incluso si resulta que estabas en lo cierto, no seas vengativo o digas “te lo dije” más de un par de veces, ni hagas de tu difunta idea una mártir o un grito de guerra.

9. No seas “ese tío de la habitación”.
No seas ese tío programando en una oficina oscura que emerge sólo para comprar coca-cola. Ese tío está fuera de la vista, del tacto, fuera de control y no tiene cabida en un entorno abierto y colaborativo.

10. Critica el código y no a la gente.
Sé amable con el desarrollador pero no con el código. Haz comentarios relacionados con los estándares locales, especificaciones de la aplicación, incrementos de rendimiento, etc.



Publicado en Variable not found.

Estos contenidos se publican bajo una licencia de Creative Commons Licencia Reconocimiento-No comercial-Compartir bajo la misma licencia 3.0 España de Creative Commons

martes, 20 de enero de 2015
Framework design guidelinesHace relativamente poco tiempo, y como parte del popular salto al open source del nuevo stack de Microsoft, se publicaron en Github las directrices o normas de codificación que deben seguirse para contribuir en el desarrollo de .NET Core. Se trata de un resumen simplificado del contenido del libro “Framework design guidelines” publicado por Krzysztof Cwalina y Brad Abrams en 2008.

Aunque creo que este mismo documento o versiones anteriores lo he leído en otras ocasiones, la verdad es que sigue resultándome muy interesante porque me recuerda normas y convenciones que conviene tener en cuenta al desarrollar marcos de trabajo y componentes. No hay que olvidar que estas directrices han sido refinadas y mejoradas con los años, acumulando ya la experiencia de muchos años y muchos desarrolladores que han trabajado en .NET framework, así que se trata de una base de conocimiento nada despreciable. De hecho, estas pautas son las bases del diseño de frameworks dentro de la propia Microsoft.

Y como a menudo me encuentro con equipos que no tienen guías de estilo ni convenciones de codificación formalizadas, he pensado que quizás sería interesante traducirlas para que puedan ser usadas como punto de partida para crear sus propias normas y, en cualquier caso, siempre dan buenas ideas que podemos aplicar en el día a día para hacer mejor nuestros componentes.

Es una lectura cortita, ¡que aproveche!

Estos contenidos se publican bajo una licencia de Creative Commons Licencia Reconocimiento-No comercial-Compartir bajo la misma licencia 3.0 España de Creative Commons

martes, 5 de febrero de 2013
ASPNETMVCHace poco, en el post donde trataba la inyección de dependencias y desacoplamiento de Hubs de SignalR, el amigo Maxxx comentaba que podría estar bien ver cómo podríamos emplear las mismas técnicas con ASP.NET MVC.

Y ciertamente, me ha parecido muy interesante porque es un escenario que encuentro habitualmente en empresas de desarrollo: comprenden los beneficios de reducir el acoplamiento entre componentes, pero les parece algo demasiado complejo como para aplicar en su día a día porque desconocen cuáles son y cómo usar las herramientas de que disponemos para conseguirlo.

Por tanto, en este post vamos a ver, paso a paso y de forma totalmente práctica, cómo evolucionar desde un controlador MVC fuertemente acoplado a clases del modelo hasta otro totalmente desacoplado usando inyección de dependencias y contenedores de inversión de control.

Y aunque las técnicas y ejemplos que mostraremos están muy enfocados a controladores MVC, los conceptos tratados son aplicables en cualquier tipo de tecnología y arquitectura.

Estos contenidos se publican bajo una licencia de Creative Commons Licencia Reconocimiento-No comercial-Compartir bajo la misma licencia 3.0 España de Creative Commons

miércoles, 21 de abril de 2010
¿Sómos los primeros en llegar al estadio? Casualmente encuentro en el post de Chris Eargle “Any() versus Count()” un tema del que pensaba escribir hace tiempo y al final dejé en el tintero: ¿cómo podemos determinar si una enumeración está vacía? Vale, es bien fácil, una enumeración está vacía si tiene cero elementos.

Si trabajamos con un array, podemos consultar la propiedad Length; si se trata de una colección, podemos utilizar la propiedad Count, que también nos devolverá el mismo dato de forma directa.

Sin embargo, cuando procesamos información es frecuente tratar con tipos de datos enumerables cuya implementación exacta desconocemos, y en los que no tenemos acceso a ninguna propiedad que nos permita conocer el número de elementos exactos que tiene almacenados. Por ejemplo, esto ocurre cuando obtenemos un conjunto de datos en forma de IEnumerable o trabajamos con LINQ sobre alguna fuente de información.

Pues bien, en estos casos hay que ser algo prudentes con la forma de consultar el número de elementos. Me he topado con código propio en el que, simplemente por despiste, utilizaba el método Count(), facilitado por LINQ para las enumeraciones y otras colecciones de datos, con objeto de saber si una lista estaba vacía:

var prods = services.GetProductsByCategory(category);
if (prods.Count() > 0)
{
   // Hacer algo con los elementos de la lista
}
else
{
   // No hay elementos
}

Seguro que ya os habréis percatado de que eso está mal, muy mal. El método Count() recorrerá uno por uno los elementos para contarlos, retornando el número exacto de ellos. En escenarios de un gran número de elementos, o cuando es costoso obtener cada elemento (como al traerlos de una base de datos) puede suponer un consumo de recursos enorme.

Y justo por esto existe el método Any(), que comprueba únicamente si existe al menos un elemento en la colección. Internamente este método itera sobre la colección retornando true cuando encuentra el primer elemento, por lo que es mucho más eficiente que el anterior:

var prods = services.GetProductsByCategory(category);
if (prods.Any()) // Mucho mejor :-)
{
  // Hacer algo con los elementos de la lista
}
else
{
  // No hay elementos
}

La utilización de Any() también es interesante para comprobar la existencia de elementos que cumplan una condición, expresada en forma de predicado; retornará true cuando encuentre el primer elemento que lo haga cierto:

if (pedidos.Any(p => p.Pendiente))
{
   // Mostrar alerta, hay al menos un pedido pendiente
}

Estamos en la puerta de un Estadio y queremos saber si vamos a ser los primeros en entrar al recinto… ¿le preguntaríamos al portero el número exacto de aficionados que ya están dentro para, si es cero, saber que somos los primeros? ¿O nos bastaría simplemente con preguntarle si hay alguien? ;-P

Publicado en: Variable not found
Hey: ¡estoy en Twitter!

Estos contenidos se publican bajo una licencia de Creative Commons Licencia Reconocimiento-No comercial-Compartir bajo la misma licencia 3.0 España de Creative Commons

domingo, 4 de abril de 2010
Hace casi un año hablaba de la segunda versión de NDepend, una herramienta capaz de ayudaros a mejorar nuestro código, analizando cientos de aspectos, métricas y reglas a nivel de fuentes y ensamblados.

Recientemente se ha publicado la tercera versión de NDepend, que ofrece interesantes novedades respecto a las anteriores, como la integración absoluta con Visual Studio, el soporte para soluciones multi-proyecto, potentes mecanismos de búsqueda, edición múltiple de CQL, o el seguimiento de cambios, además de las tradicionales características del producto.

Los 10 métodos más extensos de ASP.NET MVC 2
Pero sin duda, lo que me ha parecido más espectacular es su magnífica integración con Visual Studio (2005, 2008 y 2010), que permite disfrutar de toda la potencia de análisis de NDepend, y sus facilidades para la navegación desde el mismo entorno de desarrollo.

Para habilitar esta característica es necesario instalar el plugin en el IDE, que se realiza desde el propio entorno visual de NDepend:

Instalar plugin NDepend en Visual Studio
De esta forma, ya no es necesario acudir a la herramienta Visual NDepend para realizar búsquedas, comprobar reglas o navegar a través de la base de código: lo haremos directamente desde VS, utilizando los menús contextuales. Y gracias a ello, podemos disfrutar de las nuevas opciones de navegación, que nos permitirá surcar el código utilizando rutas distintas a las habituales:

Navegar por el código con NDepend
U obtener diagramas de dependencias de componentes, utilizando el botón derecho del ratón:

Dependencias con NDepend 3

Además, como comenta Patrick Smacchia, padre de la criatura, el rendimiento del entorno prácticamente no se resiente, dado que los análisis se ejecutan en segundo plano de forma incremental.

Recordar, por último, que NDepend es una aplicación comercial, pero dispone de una versión limitada gratuita utilizable por universidades, desarrolladores open source e incluso, durante un tiempo determinado, de prueba en proyectos comerciales.

Página del producto: http://www.ndepend.com/
Publicado en: Variable not found
Hey, ¡estoy en twitter!

Estos contenidos se publican bajo una licencia de Creative Commons Licencia Reconocimiento-No comercial-Compartir bajo la misma licencia 3.0 España de Creative Commons

domingo, 7 de febrero de 2010
Este post es la tercera y última entrega de la serie 30 Leyes epónimas relacionadas con el desarrollo de software. Puedes encontrar la segunda parte aquí.

Tim Bryce

21. Las leyes de Bryce

Así las llama él, aunque algunas encajarían mejor en una recopilación de frases célebres. Ahí van algunas, aunque pueden encontrarse más de 150 aquí.


Tal y como el uso de la tecnología va aumentando, disminuyen las habilidades sociales

El 85% del trabajo de desarrollo de todos los sistemas consiste en introducir modificaciones y mejoras

A la vez que la capacidad del hardware incrementa, el software se vuelve más pesado

Olvidar al ser humano durante el diseño del sistema provocará que el ser humano se olvide del sistema en el momento de echarlo a andar

[...]

Tim Bryce es un controvertido escritor y consultor de gestión de recursos de información (IRM), famoso entre otras cosas por sus aseveraciones sobre el ego, las manías y extrañezas de los desarrolladores, y sus consejos para manejarlos apropiadamente. Aparte de su habilidad para hacer amigos entre los programadores, es sin duda un gran experto en el mundo de las compañías de desarrollo de software, con más de 30 años a sus espaldas en este campo.

Eugene Spafford

22. Primer principio de Spaf

Si eres responsable de seguridad pero no tienes autoridad para establecer reglas y castigar sus incumplimientos, tu cargo real en la organización es asumir la culpa cuando ocurra algo grave

Eugene Spafford, más conocido como "Spaff", es un reputado experto en seguridad informática y profesor de la Purdue Univertity. Según parece, fue uno de los primeros en escribir un libro sobre virus informáticos en 1989, utilizar el término autopsia software para referirse al análisis de aplicaciones para intentar localizar a sus autores, y un sinfín de aportaciones al mundo de la seguridad en sistemas informáticos.

Además, es tan prolífico creando frases y analogías a la hora de explicar conceptos de informáticos que Mahesh V. Tripunitara, uno de sus estudiantes, mantiene una página donde las recoge: "The Page of Spaf's Analogies".

Aloysius Alzheimer

23. Ley de Alzheimer de la programación

Si lees un código que escribiste hace más de dos semanas es como si lo vieras por primera vez
Efectivamente, el psiquiatra y neurólogo alemán Aloysius Alzheimer no enunció esta ley a primeros del siglo pasado, pues estaba muy ocupado estudiando las enfermedades mentales de sus pacientes. Sin embargo, el síntoma de pérdida de memoria tan habitual en ellos propició la utilización de su nombre en esta Ley tan ligada a la escritura de código limpio, documentado y sencillo.

Roy Amara

24. Ley de Amara

Tendemos a sobreestimar el efecto de la tecnología en el corto plazo y a subestimarla a largo plazo
Esta ley, causa de la existencia de problemas debidos a excesos de optimismo o de la formulación de predicciones disparatadas, fue enunciada por Roy Amara, que fue presidente del Instituto para el Futuro, un grupo de investigación sin ánimo de lucro dedicado al análisis de tendencias que ayuden a la toma de decisiones basándose en predicciones sobre el futuro.

Barbara Liskov

26. Principio de Liskov

Los subtipos deben ser sustituibles por sus clases bases
O en otras palabras, que un subtipo no debe modificar el comportamiento esperado de la clase de la que hereda; de esta forma, si el subtipo puede sustituir a su clase base sin causar daños, la herencia será correcta. Citando a Enrique Place en PHPSenior, "No basta con ser hay que comportarse como tal".

Barbara Liskov es profesora del Massachusetts Institute of Technology (MIT) y fue la primera mujer en conseguir el doctorado en informática de Estados Unidos.

Hick no se dejó hacer la foto ;-)

25. Ley de Hick

El tiempo que se tarda en tomar una decisión aumenta a medida que se incrementa el número de alternativas
Puede sonar a obvio, pero la cuestión es que William Edmund Hick, pionero en psicología experimental y ergonomía, fue capaz de idear, a mediados del siglo pasado, la fórmula que explica por qué tardamos tanto tiempo en responder a un cuadro de diálogo con botones para Aceptar, Cancelar, Reintentar, Ignorar y Omitir:
T = blog2(n + 1)
Cosas de las matemáticas, seguro. :-D

Robert A. Heinlein, uno de los posibles padres del principio de Hanlon

27. Principio de Hanlon

Nunca le atribuya a la maldad lo que puede ser explicado por la estupidez
A pesar de su nombre, no está claro quién definió con tanta claridad su confianza en la capacidad del ser humano. Bill Clarke, Goethe, William James, Napoleón Bonaparte, Richard Feynmann, Einstein, Robert A. Heinlein (cuyo apellido podría haber degenerado en "Hanlon"), o un desconocido Robert J. Hanlon del que no existen demasiadas referencias podrían ser los padres de esta Ley tan utilizada por los hackers para definir situaciones creadas como consecuencia del trabajo de incompetentes sin mala intención.

Bill Joy

28. Ley de Joy

El número de empleados inteligentes en una empresa es una función logarítmica del número de empleados totales
También formulada como "no importa quien seas, la mayoría de la gente inteligente trabaja para otro", la Ley dictada por Bill Joy ofrece una visión un tanto pesimista (¿realista?) de nosotros mismos y nuestro entorno de trabajo. Pero ojo, que no lo decía cualquiera, que este señor es co-fundador de Sun y, probablemente, estuviera describiendo lo que veía.

Tim Lister

29. Ley de Lister

La gente bajo presión no piensa más rápido
Bonita frase para escribir en un post-it y pegárselo en la frente a alguien a ver si se da por aludido. Y es que efectivamente, la presión y la velocidad de pensamiento no son magnitudes proporcionales, pero es Tim Lister, un consultor, formador y escritor experto en gestión de riesgos en procesos de desarrollo de software, el que lo enunció de esta forma tan tajante y certera.



William of Ockham

30. La navaja de Occam

En igualdad de condiciones la solución más sencilla es probablemente la correcta
En el siglo XIV, Guillermo de Ockham, fraile franciscano y filósofo, postulaba de esta forma el principio de economía, utilizada en disciplinas tan dispares como la teología, informática o lingüística. De hecho, podríamos considerarlo la base de principios como KISS (Keep It Simple, Stupid), o YAGNI (You ain't gonna need it), asociados habitualmente a la programación extrema pero válidos en cualquier tipo de desarrollo.

Una curiosidad, el tercer episodio de la primera temporada de la serie House tenía este título, haciendo referencia a la solución del caso médico propuesto.




Fuentes:

Publicado en: Variable not found.

Estos contenidos se publican bajo una licencia de Creative Commons Licencia Reconocimiento-No comercial-Compartir bajo la misma licencia 3.0 España de Creative Commons

Este post es una continuación de 30 Leyes epónimas relacionadas con el desarrollo de software.

Linus Torvalds

11. Ley de Linus

Dados suficientes ojos, todos los errores son obvios
Pues sí, Linus Torvalds, uno de los más famosos artífices de Linux tal y como es conocido hoy en día, no sólo desarrollaba software, también emitía este tipo de aseveraciones en las que exponía las ventajas del modelo de desarrollo cooperativo y abierto frente al propietario; otros simplemente ven esta teoría como una barbaridad desde el punto de vista de la seguridad y mantenimiento de los sistemas.

Aunque la frase fue cosa de Linus, fue Eric S. Raymond, un hacker a la antigua usanza, el que la popularizó y le dio el nombre de su creador.

David P. Reed

12. Ley de Reed

La utilidad de grandes redes, y en particular las sociales, crecen exponencialmente con el tamaño de la red
David P. Reed, científico americano, enunció esto que parece obvio en los tiempos actuales dado el tamaño y utilización de este tipo de redes. En esta entrada de la wikipedia podéis encontrar una introducción del soporte teórico en el que se basa, que explica en esencia la facilidad con la que crece el número de subgrupos posibles entre usuarios en relación al número de usuarios o de pares.

Gordon Earl Moore

13. Ley de Moore

La potencia de los ordenadores se duplica cada dos años, reduciendo además su coste
Repetida hasta la saciedad en revistas de cacharreo, y constatada desde hace décadas, fue promulgada por Gordon Earl Moore, quien por cierto es co-fundador de Intel, fijaos si lo tenía claro el muchacho, en 1965 (!). No sé si entonces utilizó la bola de cristal, era una declaración de intenciones, o simplemente es un genio, pero desde luego su ley es una referencia de la medida del avance en los ordenadores y demás dispositivos basados en tecnología similar, y un objetivo mínimo a cumplir.

Niklaus Wirth

14. Ley de Wirth

El software se ralentiza más deprisa de lo que se acelera el hardware
Brillante la frase de Niklaus Wirth, que allá por el año 1995, aún sin conocer Windows Vista, observó su entorno y predijo la situación actual: cada vez el software es más lento y pesado, a pesar de que según la Ley de Moore tendría que ser al contrario. Este señor, una eminencia, es conocido sobre todo por haber dirigido la creación de los lenguajes Pascal, Modula y algunos otros menos difundidos.

¿Será coincidencia que en ese mismo año, 1995, fue el lanzamiento oficial de Java? ;-P

Jamie Zawinski

15. Ley de Zawinski

Todo programa intenta expandirse hasta que pueda leer emails. Aquél que no pueda ser expandido hasta ese punto, será sustituido por otro que sí tenga esa capacidad
Lo que más me ha llamado la atención de Jamie Zawinski aparte de su metafórica ley que critica el crecimiento, a veces sin sentido, del software, es su página web personal. No os la perdáis, pues es bastante indicativa del tipo de individuo de que se trata, todo un friki, padre entre otros de una versión de Netscape, Grendel, Netscape Mail & News, Lucid Emacs, etc. También es curioso que es propietario de un club nocturno en San Francisco, este sí que sabe ;-)

Sir Arthur C. Clarke

16. Las tres Leyes de Clarke

Primera Ley de Clarke

Cuando un anciano y distinguido científico afirma que algo es posible, probablemente está en lo correcto. Cuando afirma que algo es imposible, probablemente está equivocado.

Segunda Ley de Clarke

La única manera de descubrir los límites de lo posible es aventurarse hacia lo imposible.

Tercera Ley de Clarke

Cualquier tecnología lo suficientemente avanzada es indistinguible de la magia.
El conocido científico y escritor británico Sir Arthur Charles Clarke enunció estas tres leyes porque, según comentaba, "si tres leyes fueron suficientes para Newton, modestamente decido parar aquí".

Arthur C. Clarke fue autor de un gran número de libros, relatos y obras de divulgación, destacando su novela y participación en el guión de 2001: Una odisea en el espacio.

Scott AdamsDilbert

17. El principio de Dilbert

Las compañías tienden a ascender sistemáticamente a sus empleados menos competentes a cargos directivos para limitar así la cantidad de daño que son capaces de provocar
Este complemento perfecto para el Principio de Peter fue observado por Scott Adams, autor de Dilbert, una popular tira cómica sobre el mundo de la empresa que se publica en 1200 periódicos de todo el mundo.

Scott Adams es considerado uno de los 50 pensadores más influyentes en el mundo de la empresa, incluso por encima de personajes como Steve Jobs o Al Gore. Se trata, además, de un epónimo curioso en cuanto a que su nombre no proviene directamente de su autor, sino de la obra de su autor.

George Gilder

18. Ley de Gilder

El ancho de banda aumenta a un ritmo tres veces superior a la potencia de los ordenadores
Pues sí, cualquiera lo hubiera dicho hace unos años... pero la verdad es que hoy en día la velocidad en las conexiones a la red son increíbles. Y por suerte, sin subir proporcionalmente el coste ;-)

George Gilder es un controvertido escritor e intelectual americano, entusiasta de la tecnología e internet, que en la actualidad dirige el Gilder Technology Report, un sitio exclusivo de información de ámbito económico y tecnológico. Según comentan, "sus hijos no estudian español, sino C++" (visto en Wikiquote).

Gene Amdahl

19. Ley de Amdahl

El incremento de velocidad de un programa utilizando múltiples procesadores en computación distribuida está limitada por la fracción secuencial del programa

Esta ley, de gran aplicación en el cálculo de rendimiento de sistemas cuando uno de sus componentes es mejorado o en contextos de procesamiento en paralelo, fue enunciada por Gene Myron Amdahl en 1967, en sus tiempos como trabajador de IBM Corporation, que abandonó varias veces por disconformidad con el escaso trato humano en esta empresa, muy encorsetada y llena de burocracia.

Según demuestra matemáticamente, llegados a un punto el rendimiento de un sistema no está relacionado con el número de procesadores instalados, sino con la eficiencia de los algoritmos empleados.

Nathan Myhrvold

20. Ley de Myhrvold

El software es un gas; se expande hasta rellenar su contenedor
Claro, esto explica por qué da igual la potencia y capacidad del ordenador que tengamos: nuestro software lo llenará como si se tratara de un globo, hasta ponerlo a reventar.

Y lo dijo ni más ni menos que Nathan Myhrvold, ex-director de tecnología de Microsoft y fundador de Intellectual Ventures, una empresa dedicada crear y patentar, pero curiosamente no a poner en explotación, inventos para sectores como el software, semiconductores, redes, lásers, biotecnología y otros dispositivos.

Continuar en 30 Leyes épónimas relacionadas con el desarrollo de software (y III).

Publicado en: Variable not found

Estos contenidos se publican bajo una licencia de Creative Commons Licencia Reconocimiento-No comercial-Compartir bajo la misma licencia 3.0 España de Creative Commons

Un epónimo es el nombre de una persona o lugar que cede su nombre a una época, pueblo, unidad, ley, etc. Son epónimos por ejemplo "Diesel", cedido por Rudolf Diesel, inventor de este tipo de motores, o "Hamburguesa", infame trozo de carne picada cuyo nombre procede de su lugar de origen.

Hace unos años, el gran Phil Haack posteó sobre leyes epónimas relacionadas con el desarrollo de software en "19 Eponymous Laws Of Software Development", y seleccioné las que me resultaron más interesantes en un par de posts.

Ahora los he vuelto a maquetar y les he añadido un nuevo conjunto de leyes muy interesantes para todos los que nos dedicamos al mundo del desarrollo de software, y muchas de ellas incluso aplicables a otros ámbitos.

John Postel

1. Ley de Postel

Sé conservador en lo que hagas y liberal en lo que aceptes de los demás
Esta frase, de Jonathan Bruce Postel, también llamada Principio de Robustez, es la piedra filosofal del protocolo TCP, y está recogida en la RFC 793, sección 2.10, de septiembre de 1981.

C. Northcote Parkinson

2. Ley de Parkinson

El trabajo se extiende siempre hasta rellenar la totalidad del tiempo disponible para completarlo
Esta ley fue postulada inicialmente en 1955 por C. Northcote Parkinson en The Economist y más tarde entró a formar parte de su libro, basado principalmente en las experiencias de la administración británica.


Vilfredo Pareto

3. Principio de Pareto

Para muchos fenómenos, el 80% de las consecuencias derivan del 20% de las causas
Vilfredo Pareto fue un estudioso de la economía y sociología del siglo XIX, y se fijó que el 80% de las propiedades y riqueza estaban repartidas entre el 20% de la población, enunciando su famoso principio. A partir de ahí, se piensa que esta proporción es cierta en múltiples ocasiones, hasta en el número de bugs en el código fuente de un software, o el tiempo de desarrollo de funcionalidades.



Ted Sturgeon

4. Revelación de Sturgeon

El noventa por ciento de cualquier cosa es basura
Theodore Sturgeon era un autor de ciencia ficción americano que escribió esta frase defendiendo a este tipo de literatura de críticos que opinaban que el 90% era una porquería.

Hay un corolario que dice "La revelación de Sturgeon es cierta salvo para la basura, donde el 100% es basura".

Lawrence J. Peter

5. El principio de Peter

En una jerarquía, todo individuo tiende a subir hasta alcanzar su nivel de incompetencia
Seguro que todos conocéis ejemplos de ello: un fabuloso desarrollador es ascendido a directivo en una empresa, la cual gana un gestor pésimo y pierde un programador excelente. Doble penalización. Lawrence J. Peter, pedagogo de profesión, ya lo enunció en 1968 en el libro El principio de Peter.

Douglas Hofstadter

6. Ley de Hofstadter

La realización de un trabajo siempre dura más de lo esperado, incluso habiéndose tenido en cuenta la Ley de Hofstadter
Esta genial y recursiva Ley creada por el científico, filósofo y académico estadounidense Douglas Hofstadter es absolutamente cierta. Y si no, pensad un poco, ¿cuántas veces habéis estimado plazos en un desarrollo, lo habéis incrementado de forma considerable por los imprevistos y aún así os habéis quedado cortos?


Edward A. Murphy

7. Ley de Murphy

Si algo puede ir mal, lo hará
La famosa ley, también enunciada en forma de tostada que recurrentemente cae con la mantequilla hacia abajo, fue dictada por Edward A. Murphy, Jr., mientras trabajaba para la fuerza aérea americana como ingeniero, diseñando un sistema de cohetes experimental. Sería lógico pensar que el experimento acabó en tragedia, pero parece ser que la creación y consideración de esta ley les ayudó a evitar graves desastres en sus pruebas.

Frederick Brooks

8. Ley de Brooks

Incluir trabajadores en un proyecto retrasado hará que éste avance aún más lentamente
Fred Brooks postuló esta ley en su famoso libro The Mythical Man-Month: Essays on Software Engineering como resultado de su experiencia en IBM. Existen variantes y corolarios como "Una señora es capaz de tener un hijo en nueve meses, pero este plazo no puede disminuir por muchas mujeres embarazadas que pongamos a ello". Simplemente genial.

No se dejó hacer la foto ;-) Este es uno de los diagramas usados en el paper 'How Do Committees Invent?' donde presentaba sus ideas

9. Ley de Conway

Cualquier software refleja la estructura organizacional de quien lo produjo
A pesar de que suena a guasa, la ley de Melvin Conway no puede ser más cierta. Una empresa con tres grupos de desarrollo tenderá a generar software distribuido en tres subsistemas, reflejo fiel de las relaciones entre los grupos participantes. Y por cierto, extrapolando un poco... ¿habéis pensado alguna vez que el software que se hace en vuestra empresa es un desastre? ¿creéis que con esta ley podríais obtener alguna conclusión? ;-D

Auguste Kerckhoffs

10. Principio de Kerckhoffs

En términos de criptografía, un sistema debería ser seguro incluso si todo sobre el mismo se conoce públicamente, salvo una pequeña porción de información
Es increíble que Auguste Kerckhoffs lingüista y criptógrafo alemán, enunciara en el siglo XIX este principio, base de todos los sistemas de criptografía de clave pública actuales.



Publicado en: http://www.variablenotfound.com/.

Estos contenidos se publican bajo una licencia de Creative Commons Licencia Reconocimiento-No comercial-Compartir bajo la misma licencia 3.0 España de Creative Commons

lunes, 16 de noviembre de 2009

¡Programadiseñadores al poder! Ya sabemos lo que suele ocurrir cuando los programadores diseñamos interfaces de usuario ;-). Para seguir profundizando en este curioso e inevitable fenómeno, Ian Voyce ha publicado hace unas semanas el divertido post The 7 signs your UI was created by a programmer, en el que recoge pistas que nos ayudarán a determinar si el interfaz de la aplicación que usamos a diario está creado por un diseñador experto en usabilidad, o ha sido el propio desarrollador el encargado de dichas tareas.

Bueno, en realidad se trata más bien de una lista con malos hábitos en el diseño de interfaces, y no necesariamente creados por programadores, pero ciertamente me he reconocido en alguno de los puntos y me han hecho gracia. Los cito y comento a continuación:

  • Iconos de exclamación en cuadros de diálogo
    Efectivamente, cuando incluimos una exclamación en un cuadro de diálogo no pensamos en que es posible que el usuario vea el mensaje 50 veces al día, con lo que dejaría de ser ese mensaje asombroso y puntual que pensamos en un principio. Hoy en día, muchas aplicaciones utilizan un tono mucho más neutral y cercano para enviar mensajes al usuario.

  • Mensajes con dobles negaciones en cuadros de diálogo, del tipo “¿Seguro de que no quieres perder tus cambios?” -- Hmm… sí… digooo, no…  También son muy propias construcciones más complejas de la cuenta, paradójicas o inesperadas, como “Su mensaje no se ha enviado, ¿desea descartarlo?”, que ponen a prueba los reflejos de cualquier usuario.

  • Orden de tabulación inexistente, o incorrecto, que fuerzan a que la navegación se realice exclusivamente a golpe de ratón. Y especialmente en aplicaciones de entrada masiva de información, el cambio de teclado a ratón y viceversa es terrible. Y paraGroupboxes para todo.. porque mola hacernos conscientes de ello, nada como dar vacaciones un rato al animalito y ver lo bien que manejamos determinadas aplicaciones.

  • Groupboxes rodeándolo todo… porque hay sitios donde queda bonito, aunque no esté agrupando nada ;-). Me confieso: durante años, he rodeado de groupboxes todo lo que se me ponía por delante, porque me parecía más agradable a la vista. Ahora lo estoy dejando ;-)

  • IconoIconos creados en el IDE, je, este es otro de mis puntos fuertes: soy un fiera diseñando iconos desde el editor de Visual Studio. El problema es que, a pesar de lo orgulloso que estoy siempre de mis creaciones artísticas, no quedan bien e incluso introducen un cierto tufillo a cutre en las aplicaciones.

  • Utilización de grids, debido a lo que llama Voyce “la enfermedad de considerar que Excel es lo máximo en diseño de interfaces de usuario”, que fomenta la creación de rejillas con controles de lo más potentes y variopintos en las filas de datos (calendarios, gráficos, etc.).

  • Message Boxes no implementados, el equivalente en los interfaces de usuario a los TODO en el código fuente :-DD. Buena analogía. Algo parecidos serían los mensajes del tipo “Este mensaje no debería aparecer nunca” que alguna vez he encontrado por ahí, auténticos actos de rebeldía contra sus respectivos creadores.

  • Uso excesivo de cuadros de diálogo, incluso en situaciones en las que perfectamente podríamos obviarlos por no ofrecer información útil para el usuario, que no va a poder entender, o donde no se requieren decisiones por su parte.

    Los componentes necesarios han sido detectados. Accediendo...Esto es algo muy frecuente de ver. Por ejemplo, el otro día accediendo a una aplicación web para la que es necesario contar con certificado digital, me saltó la alerta que muestro a la derecha:

    Sí, probablemente los componentes Java necesarios para la autenticación y firma electrónica hayan sido detectados con éxito, pero… ¿realmente era necesario interrumpir mi navegación para informarme de ello? ¿Un usuario, sabrá interpretar el mensaje? Y en cualquier caso, ¿le aporta algo? No sé, no sé… me da que es un alert() creado por un desarrollador durante las pruebas y que al final se quedó ahí para la posteridad.

Hasta aquí las citadas en el post original, aunque siguiendo en la misma línea, puedo añadir algunas más de propia cosecha:

  • Cuadros de diálogo con mensajes y botones inconsistentes. Mensajes del tipo “¿desea cancelar la operación?” en cuyo pie aparece un botón “Aceptar” y otro “Cancelar” siempre me dejan pensando un rato. Si pulso aceptar, ¿estoy aceptando la cancelación, o justo lo contrario?… Muchas veces, parece que sólo podemos confiar en el azar.

  • Cuadros de mensaje con demasiados (o demasiados pocos) botones. No siempre atendemos a la Ley de Hick, que nos dice que “el tiempo que se tarda en tomar una decisión aumenta a medida que se incrementa el número de alternativas”, y eso nos lleva a crear cuadros de diálogo con muchos, demasiados, botones que el usuario debe estudiar.

    Y justo en el lado contrario, pero igualmente desconcertantes, son los cuadros de diálogo de introducción de datos sin ningún botón de aceptación, en los que su cierre (con la X de la esquina superior) implica el salvado de datos.

  • Interfaz descuidado. Y no hablo de bonito o feo, términos bastante subjetivos, sino de descuidado: controles sin alinear, con tamaños no proporcionales al contenido pretendido, sensación de desorden, faltas de ortografía… Esto no es un problema de interfaces creados por desarrolladores, sino creados por gente que no pone el más mínimo cariño en lo que hace, independientemente de su puesto de trabajo.

  • Interfaces monocromos, mi especialidad. Como inútil reconocido en temas de diseño, me considero absolutamente incapaz de crear algo medio aparente con más de un color (eso sí, empleando distintas tonalidades ;-)). Nunca he entendido la compleja lógica que hay detrás del “eso no pega con aquello”, que algunos/as parecen dominar de serie.

  • Controles con trastorno de personalidad. Un clásico es encontrar un grupo de checkboxes actuando como un grupo de radios. A ver, si sólo vamos a poder elegir una de las opciones, ¿por qué no usamos directamente el control específicamente ideado para ello? ¿Y un desplegable con las opciones "Activar" y "Desactivar"? ¿No sería más claro poner un checkbox?

Artículo original: The 7 signs your UI was created by a programmer

Publicado en: Variable not found.

Estos contenidos se publican bajo una licencia de Creative Commons Licencia Reconocimiento-No comercial-Compartir bajo la misma licencia 3.0 España de Creative Commons