Antipatrones Software

Un patrón software es una solución común, adaptable y probada para un problema conocido. Algo así como una plantilla de encaje que se ajusta a según qué condiciones (fuerzas y contexto) de manera que aporta una solución (diseño) implementable y ejecutable (software).

Un antipatrón es precisamente lo contrario. Dicho así de pronto parece claro que es algo así como un “lo que no hay que hacer” y que por tanto lo que voy a tratar aquí es un compendio de malas prácticas. Pero un antipatrón no es exactamente esto. Existen muchos libros que tratan de buenas y malas prácticas: en análisis, en diseño, en implementación, en pruebas… Un antipatrón no es una mala práctica, aunque su consecuencia es un mal diseño y por tanto puede abocar al fracaso de un producto software.

Un antipatrón es la aplicación de un patrón software bajo unas precondiciones erróneas, es decir: la aplicación de un patrón software en un contexto equivocado. Es algo así como decir: “tu intención era buena peeero no estudiaste bien las fuerzas y el contexto que intervenían en tu situación particular, y por ello tu solución es inadecuada”.

Bueno, esto parece diferente a lo que tradicionalmente considerábamos como mala praxis en el desarrollo software, y parece tener algo de atractivo. En estos momentos estoy leyendo un librito que trata este tema, y a medida que encuentre temas interesantes que pueda publicar lo haré. Veamos si no es un palabro más inventado para escribir libros y ganar dinero.

Lo que expongo a continuación es un breve resumen de patrones y antipatrones extraídos de la fuente que anexo al final del artículo. Para ir abriendo boca.

Patrones:

Cultura de reutilización: trata precisamente de establecer una política de reutilización de software y de que todo el equipo desarrolle pensando siempre en que sus artefactos son susceptibles de ser reutilizados.

Artefacto robusto: un elemento bien documentado, construído para alcanzar los objetivos y necesidades generales en lugar de limitarse simplemente a los objetivos específicos.

Generalización automotivada: Tratar de pensar en la generalización a la hora de desarrollar, en facilitar elementos que se puedan utilizar as-is.

Ingeniero senior de reutilización: es aquel que pone en práctica los patrones anteriores.

Antipatrones:

Artefacto no reutilizable: No sólo es aquel que no es reutilizable porque no se pensó en ello, sino que también es aquél que se pretendió que fuera reutilizable pero que en realidad no lo es (y esto último es más importante y más grave).

Reutilización orientada a repositorios: La creencia de que simplemente por crear una especie de almacén de piezas software que se pueden reutilizar, la reutilización viene de forma automática.

Síndrome del No-Está-Hecho-Aquí: Los desarrolladores desconfían del trabajo hecho por otros y tienden a desarrollar por sí mismos artefactos software que ya están hechos.

Reusabilidad declarada: La creencia de que algo es reutilizable simplemente porque lo digo yo o lo dijo alguien…

Reusabilidad orientada a incentivos: Una vez más, ofrecer incentivos para que los desarrolladores hagan software de mayor calidad (en este caso, reutilizable) no es el camino, pequeño saltamontes…

Producción antes de consumición: Algo así como que la reutilización vendrá por sí sola en cuanto empieces a pensar en desarrollar artefactos reutilizables. La realidad es que es necesario invertir fuertemente para que la reutilización sea un hecho probado: dedicar recursos y soporte.

Reutilización solamente de código: Creer que lo único susceptible de ser reutilizado es el código.

Reutilización orientada a proyectos: Limitar la generalización que lleva a construir artefactos reutilizables solamente como decisión que incumbe al ámbito del proyecto para el cual se desarrolla dicho artefacto.

Referencias:

http://www.sdmagazine.com/uml/thinking/s0002to.shtml

Revista Dr Dobb’s, actualmente la fuente no está disponible. El artículo lo encontré por ahí… lamento no poder facilitar más las cosas.

HowTo: Connect to a VPN in Linux

Nota: Este pequeño artículo se debe a una reciente investigación que tuve que realizar en el trabajo; como la publiqué en inglés he decidido no tomarme la molestia de traducirlo; al fin y al cabo quien lo necesite será alguien que trabaja con ordenadores y estará más que acostumbrado a leer textos en inglés; por otra parte creo que el artículo es sencillo…

Foreword

The following steps works fine in Ubuntu 8.04 Hardy. You should not have any problem in other versions.

Install required packets

First of all, we need to know which is the VPN infrastructure to connect. Depending on it, we’ll distinguish between 3 different cases:

A) – openVPN.

B) – Windows VPN

C) – Cisco VPN.

Once we certainly have this information, we can download the appropiate package:

A) – sudo apt-get install network-manager-openvpn

B) – sudo apt-get install network-manager-pptp

C) – sudo apt-get install network-manager-vpnc

If your distribution is not Ubuntu, try to search those packets in Synaptics, YaST or whatever.

After installing them, you should see a net icon in the status bar. Click on it and create a VPN connection. Introduce all the information provided to connect to your server and proceed as you would do in Windows.

When you have finished, click again in the net icon in the status bar and select your connection. The system will ask for your credentials. Type them and enter. Quite simple.

Useful links

http://www.cs.umn.edu/help/offsite/vpn.php#ubuntu_config

This is a useful link with a very simple tutorial including snapshots. In the examples it explains how to connect to a Cisco VPN, but the other cases are quite similar.

https://wiki.ubuntu.com/VPN

Here you can find information about packages to install and things like that.