Cuando comencé a leer libros sobre Extreme Programming, me llamó la atención una de las propiedades de esta metodología de desarrollo, que era la propiedad del código.

Por mi parte he sido siempre muy comunista con respecto al código, no tengo el menor reparo en mirar, ampliar y corregir código de otras personas y dejo que los demás vean, opinen y corrijan y/o agreguen cosas a mis códigos... es la mentalidad del software libre.

Pero en las empresas ocurre lo contrario. Es muy normal, yo diría que incluso enfermizo, llegar a ver cómo cuando entras en una empresa en la que hay más de tres programadores, cómo cuando algo falla, cuando hay que hacer una nueva mejora, ampliación, adaptación, siempre dice uno en voz alta: ese código es de fulanito; indicando que ni lo va a ver, ni lo piensa modificar.

Nota: Realmente, es la declaración de permisos en sistemas Unix, BSD, Solaris, GNU/Linux y derviados, pero pongo el título principal como GNU/Linux, porque realmente es el único entorno en el que doy fe de que todo lo que hay escrito en este artículo funciona al 100%.

El sistema GNU/Linux, al igual que su inspiración Minix, y la raíz de estos sistemas, Unix, se basan en ficheros. Todo es un fichero. Por ello, la seguridad de acceso a este tipo de información es muy importante.

Una de las personas que más ha aportado al mundo del desarrollo de software es, sin duda, Martin Fowler.

Esta es una práctica que realicé (y comenté) en diciembre de 2008 para la asignatura de Programación III de la UNED.

La práctica se basaba en realizar un sistema para resolver tableros de shikaku, mediante el algoritmo de vuelta atrás. Mi solución es óptima pero no del todo correcta desde un punto de vista académico, ya que el uso del algoritmo (de backtracking) es menos usado de lo que debería.

El término closure (clojure en francés y cláusula en castellano) se emplea en informática (según la wikipedia) como: una función que es evaluada en un entorno conteniendo una o más variables dependientes de otro entorno.; o dicho de otra forma, lo que se conoce como un código evaluado, es decir, procesado y/o compilado en caliente o tiempo de ejecución.

¿Por qué una introducción acerca de closure?, pues porque uno de los lenguajes que comienza a ser muy usado, es precisamente este: clojure.

El tema de la calidad ha llenado páginas y páginas de la literatura informática en todos los idiomas. Es tal la necesidad de la búsqueda de la calidad, que hay estudios, técnicas y departamentos dentro de empresas e incluso empresas dedicados a establecer parámetros de calidad a los productos y proyectos que se realizan en las empresas de desarrollo de software.

Dentro del tema de la calidad, visto como un amplio abanico de elementos que la conforman, nos topamos con uno bastante confuso y complejo al principio: la calidad interna.

Mi amigo Guillermo me remitió un email hace poco en el que detallaba un concepto que ya conocía hace tiempo, pero que no había visto tan bien explicado hasta el momento (sí, tenía que haber leído antes a Cunningham), el tema era: La deuda técnica en scrum, ¿lo revisamos?

Desde mi punto de vista, esto puede suponer una locura total y una falta de forma en lo que respecta al uso de un almacén de datos visto como tal. No obstante, hay sistemas de base de datos que implementan una capa de negocio bastante interesante, donde otros sistemas solo dan una opción de scripting que da algo de miedo.

En postgresql, por ejemplo, el sistema de lenguajes que se pueden usar e implementar para la creación de funciones: PL/pgSQL, PL/Tcl, PL/Python, PL/Perl, PL/PHP, PL/Java, PL/Ruby, ...; todos ellos se pueden ver en la página de documentación de PostgreSQL.

Desde que comencé a trabajar en esto de la informática, hace ya seis años, me he dedicado a entornos que tienen que ver con la VoIP (Voz sobre IP) tocando los protocolos típicos de VoIP como son: SIP, H.323, MGCP (o megaco) y IAX; pero también con interconexiones de tipo RDSI (o ISDN en inglés) a través de BRI, o de E1 a través de PRI.

Hace poco me topé con una definición que me causó un poco de desconcierto, no llegaba a entender bien el porqué había muchas empresas y profesionales que comenzaban a usar el NoSQL.

Leyendo el blog de dos ideas con referencia a un artículo que publicaron llamado NoSQL: el movimiento en contra de las bases de datos, se comenta una conferencia en la que grandes profesionales del sector de los sistemas, con necesidades de escalabilidad y alta capacidad de almacenaje, mencionaban sus soluciones NoSQL.

Muchas veces hemos visto las URL de algunos sitios que tienen, tras una interrogación de cierre (?) una hilera de valores con iguales (=) separados por ampersand (&). No obstante, hay otros muchos sitios que sus URLs, más específicamente sus URIs, son palabras en minúscula, con algunos guiones y números escasos, separados por barras inclinadas (/). Este último método es conocido con pretty urls.

Tener este tipo de URLs, o URIs en nuestro dominio, se puede hacer mediante la creación de directorios y especificando los ficheros dentro de los mismos que tengan los nombres (sin extensión) que queremos que se visualicen en la barra del navegador... pero no es nada útil y es complejo, sobre todo cuando se usan entornos como WordPress o similares, donde el contenido de la base de datos dicta lo que aparece en la página, y es totalmente dinámico.

En todas las empresas en las que he trabajado, siempre surge un problema, cuando algo nuevo aparece si la persona que ha motivado su introducción no sabe su nombre: se la inventa. No suele ser un problema porque toda la empresa conoce el término, la tecnología o el elemento dentro de sus sistema por ese nombre, pero para nuevas personas en el proyecto, puede resultar frustrante, ¿qué nombre elegir mejor?