Paradigmas de programación

Probablemente el principal escollo que se encuentran los programadores que deciden dar sus primeros pasos en el mundo de iOS es el lenguaje que se requiere para desarrollar para los equipos de Apple: Objective-C. Tras unos momentos iniciales de pánico (¿Pero esto no era parecido a C?) llega el momento de realizar mentalmente el cambio de chip y estar dispuesto a dejar de pensar en modo C, C++, C# o Java, y empezar a pensar en Objective-C.

Objective-C apareció en la década de los 80, ante la necesidad de abandonar el código espagueti, y se concibió como un superconjunto de C. Esto quiere decir que la mayor parte del código C será válido en Objective-C sin apenas cambios, aunque la introducción del paradigma de la Programación Orientada a Objetos hace que para sacarle de verdad partido haga falta que nos familiaricemos con su particular sintaxis.

Leer más

Si bien la ley de Moore sigue aún activa, y tenemos la potencia de un superordenador de hace unos pocos años encima de nuestras rodillas, casi todos ya trabajamos en portátiles, también es cierto que el aumento de potencia cada vez es más debido a que nuestros procesadores tiene múltiples núcleos, que a la potencia en bruto de cada uno.

Por ello es imprescindible volver a hincar los codos y ponernos a aprender cosas como la multitarea, el multihilo o el multiproceso.

Y para dar una brevísima pincelada quiero traer un ejemplo desarrollado en C#, pero que es igual en cualquier lenguaje .NET, de diferentes formas de ir aumentando el rendimiento de nuestras aplicaciones.

Leer más

Existen muchos paradigmas de programación diferentes, cada uno de ellos tiene sus propias características y tratan de solucionar los problemas clásicos del desarrollo de software desde diferentes perspectivas y filosofías. Hoy vamos a ver algunas diferencias entre paradigmas de programación populares.

Los paradigmas de programación solo son propuestas tecnológicas adoptadas por la Comunidad de desarrolladores que se enfocan a resolver uno o varios problemas definidos y delimitados. Existen muchos paradigmas de programación diferentes, posiblemente el más ampliamente utilizado hoy en día sea el de la programación orientada a objetos.

Leer más

Es un viejo debate, que puede llegar a ser áspero, determinar cuál es el mejor modo de identificar entidades en un sistema. Voy a repasar los métodos que he conocido y mostraros que, aunque no he encontrado recetas mágicas, al menos, un mayor conocimiento de las alternativas y su aplicación lógica ayuda a elegir el patrón de identificación adecuado para un sistema.

Para empezar fijaos en la intencionalidad del término entidad y no registro, más propio del mundo tabulado, pues desde el prisma de un desarrollador lo que tenemos delante es un modelo semántico de un negocio que tratamos de representar. Su identificación suele emanar directamente del propio negocio en forma de los que llamamos claves naturales y forma parte del propio modelo.

La primera gran cuestión, diría que la más dolorosa, es la que me lleva a descartar el uso de esas claves naturales para la identificación de entidades. Es dolorosa porque, se haga como se haga, significa agregar al menos un atributo a cada entidad para no aportar valor semántico ni de negocio alguno.

Leer más

La programación dirigida por eventos es un paradigma de programación en el que el flujo del programa está determinado por eventos o mensajes desde otros programas o hilos de ejecución.

Las aplicaciones desarrolladas con programación dirigida por eventos implementan un bucle principal o main loop donde se ejecutan las dos secciones principales de la aplicación: El selector de eventos y el manejador de eventos.

La mayoría de librerías para el desarrollo de aplicaciones con GUI como GTK o Qt están diseñados para ser dirigidos por eventos, de ahí el famoso sistema de ranuras y señales de Qt que no es más que un patrón de diseño observer bastante currado.

Leer más

Solid es un acrónimo inventado por Robert C.Martin para establecer los cinco principios básicos de la programación orientada a objetos y diseño. Este acrónimo tiene bastante relación con los patrones de diseño, en especial, con la alta cohesión y el bajo acoplamiento.

El objetivo de tener un buen diseño de programación es abarcar la fase de mantenimiento de una manera más legible y sencilla así como conseguir crear nuevas funcionalidades sin tener que modificar en gran medida código antiguo. Los costes de mantenimiento pueden abarcar el 80% de un proyecto de software por lo que hay que valorar un buen diseño.

Leer más

La informática y el desarrollo empiezan a salir de sus nichos y asomarse a la prensa generalista. Y no sólo parece haber ya espacio para hacer reportajes sobre fenómenos como Facebook y Twitter sino para entrevistas relajadas con héroes de la programación como la que ayer se publicaba en XLSemanal (el dominical del ABC, para quien no esté muy puesto en el mundo periodístico español) con Donald Knuth, el célebre autor de ‘El arte de programar ordenadores’, el equivalente a ‘El Señor de los Anillos’ de nuestra profesión / pasión.

La entrevista, sin desperdicio, la puedes leer integramente aquí pero me gustaría destacar unas cuantas cuestiones que me han llamado la atención sobremanera:

Leer más

Finalizamos la serie acerca el amigo informático en el que en números anteriores hicimos una introducción, comentamos los diferentes tipos de personas y las diferentes situaciones que nos podemos encontrar. En esta ocasión hablaremos de la parte más difícil de todo: decir NO.

Hasta ahora hemos hablado líneas y líneas de “marrones“ ocasionados por circunstancias externas. Cuando hablamos de cosas que no podemos controlar o nos llegan a dominar siempre lanzamos las culpas a seres o objetos que por alguna fuerza superior nos llegan a nosotros.

Sin embargo, aquí llega la crítica más dura de todo. Cuando sientas que el mundo está lleno de “jetas” y personas que abusan sistemáticamente, no intentes responsabilizarlas de tu situación. Hay que ser autocrítico y pensar que la culpa es tuya. Si se piensa en ello con cierta frialdad, prácticamente todo lo nos que sucede lo solemos elegir. Existen muy pocas situaciones en las que nosotros no tengamos la libertad de tomar el camino que preveamos que puede ser mejor para nosotros.

Leer más

Continuamos con la serie de artículos sobre el amigo informático. En números pasados hablamos de las causas de la indignación y evaluar la probabilidad de reciprocidad para el retorno del favor según el tipo de persona. En esta ocasión hablaremos de situaciones muy frecuentes para quedar en compromiso o, como se dice comúnmente, quedar pringado.

Nuevamente me gustaría mencionar que el hecho de quedar pringado con trabajo no deseado y muchas veces gratis, no es algo exclusivo de nuestro sector. En todo tipo de profesionales existe la necesidad de quedar bien, la imagen y que otras personas una visión positiva de nosotros.

Os imagináis después de un concierto de música el público aclame “¡Otra!, ¡Otra!, ¡Otra!” y el cantante diga por el micrófono “Iros a vuestra casa. ¡¡Gorrones!!”. :). En muchos sectores ocurriren situaciones parecidas: “Restaurantes que tienen que cerrar tarde porque un grupo se queda de cháchara”, “Transportistas en que se les hace desplazarse a sitios fuera de su ruta” y así un largo etcétera.

La probabilidad de quedar pringado viene aparejada con la incertidumbre de la conclusión de un trabajo. Cuando un trabajo es predecible, monótono y fácilmente cuantificable, es fácil deducir cuanto cuesta hacer algo y cuando se va a acabar.

Leer más