Patrones de diseño. Introducción

¿Qué es un patrón de software?

En software un patrón de diseño se refiere a una determinada forma de crear software, una forma de fabricarlo, por decirlo de alguna forma para crearlo de forma correcta.

En determinados marcos de trabajo, cuando nos enfrentamos a determinados problemas en el diseño de software hay formas determinadas de enfocalos que permiten adaptar mejor los posibles cambios de dichos problemas y las distintas evoluciones que pueda sufrir el software en un futuro.

Un buen dominio de los patrones más comunes nos puede servir para no tener que reinventar la rueda a cada paso que damos sino que podemos hacer uso de lo que otros pensaron por nosotros (y que descubriremos en multiples situaciones).

Patrones de diseño. Strategy

Introducción

El patrón strategy (estrategia) esta orientado a resolver situaciones en las que nos encontramos con un problema base pero existen diversas estrategias para abordar el problema. En este sentido nuestro problema define un interface que será (o podrá ser) implementado de diversas formas.

Problema

El patrón Strategy aborda problemas que pueden (o se prevee que puedan) ser implementados o afrontados de distintas formas y cuyo interfaz esta bien definido y es común para dichas formas, pudiendo ser cualquiera de ellas valida o más desable en determinadas situaciones y permitiendo el cambio entre las distintas estrategias en tiempo de ejecución.

Estructura

main.php?g2_view=core.DownloadItem&g2_itemId=825&g2_serialNumber=1

Check in early, check in offen

Acabo de leer el artículo Check in Early, Check in offen de Jeff Atwood acerca de la metodología de uso del control de versiones para el desarrollo de proyectos.

Aunque coincido con los artículos de Jeff en muchas ocasiones, esta es una de las situaciones en las que no lo hago.

En primer lugar, como por otro lado suele pasar con este tipo de artículos, las reflexiones que hace son demasiado genéricas y sobre caso demasiado simples como para poder extraer verdaderas conclusiones sobre ellos.

Hacer check in pronto y a menudo. Suena bonito, parece un concepto adecuado pero hay muchas cosas que quedan fuera del análisis, cosas que en un proyecto pequeño con dos o tres desarrolladores no tienen importancia pero que en grandes proyectos pueden dar verdaderos dolores de cabeza.

Uno de los ejemplos que cita es empezar con un código pequeño, que no haga nada y que tenga pocos, por tanto, pocos bug... de esta forma, según razona, podemos probarlo y subirlo al control de versiones. Entonces desarrollamos una nueva funcionalidad, la probamos y la subimos al control de versiones. Todo claro y sencillo...

Sistema de plugins con C#. Parte II. El código explicado

Antes de empezar

Como indiqué en la parte final del artículo anterior este artículo se ha retrasado tanto que he decidido sacar el código antes de estar acabado. Pese a que la parte fundamental del código es correcta, sobre todo a los efectos de ilustrar este artículo, no debe considerarse en producción y no recomiendo utilizarla para su uso en ninguna aplicación "real", al menos hasta que publique la versión completa.

La web del proyecto y su licencia

El código y otra información adicional está disponible en la página del proyecto Monet Plugins Library y tenéis disponible la última versión del código en el control de versiones de subversion http://svn.thealphasite.org/Monet.

Todo el proyecto responde a la licencia LGPL, lo cual implica, a grandes rasgos que el proyecto es esencialmente GPL (con todas las obligaciones que ello conlleva, como distribuir las modificaciones echas al código y mantener la misma licencia) pero permitiendo que el framework sea utilizado dese una aplicación o librería que no sea GPL. En general esta es una de las licencias que más "libre" me parece. Básicamente, si quieres modificarla y mejorarla tienes que "devolver" lo que has hecho y por tanto la librería va mejorando constantemente, pero si simplemente quieres usarla desde algún otro programa, entonces no encuentras restricciones.

Test Driven Development (Desarrollo dirigido por las pruebas)

Ultimamente, aquí y allá estoy oyendo hablar del llamado Test Driven Development o Desarrollo guiado por las pruebas como nueva metodología de desarrollo.

Dejadme que os explique un poco como funciona el asunto. La metodología se basa en que el desarrollo de los test guie el desarrollo de la aplicación, de esta forma lo primero que hacemos es planear que necesita hacer la aplicación y en función de ello desarrollamos test para cada una de las funciones, de esta forma disponemos de una prueba para cada función (no os entusiasmeis demasiado con esto ...)

El siguiente paso evidentemente es desarrollar la funcionalidad que consigue pasar ese test, y por tanto, funcionalidad hecha y medianamente probada... perfecto.

La descripción de la metodología tiene más pasos y más guías para el desarrollo y como realizar cada paso. La página de la wikipedia tiene más información para los interesados (que espero que después de leer este artículo sean pocos).

SQL Injection explicado

Introducción

La técnica de ataque de SQL Injectión (Inyección de SQL) explota una vulnerabilidad de la capa de acceso a datos de la aplicación. Es genérica a cualquier aplicación, no solo, como mucha gente cree, a aplicaciones web aunque debido al mayor acceso a través de internet así como al "descuido" de los desarrolladores web en muchas ocasiones a la hora de tratar los parametros GET ha hecho que este tipo de ataque se popularice en la web.

Anatomía del ataque

Un ataque basado en inyección de sql responde a una estructura de código en la que vamos a realizar una consulta o comando sobre una base de datos que contiene algunos parametros que nos suministra el usuario.

El problema se plantea cuando no se comprueba que dichos parametros sean válidos sino que el programador se ha limitado a concatenarlos en las partes correspondientes de la consulta, por ejemplo:

string consulta = "SELECT Count(*) FROM Users WHERE Name='" +
                   txtNombre.Text + "' AND Password = '" + txtPassword.Text + "'";

dicha consulta en principio devuelve el número de usuarios cuyo nombre y password coincide con los suministrados en los campos de texto indicados. El problema asociado a un atáque SQL Injection viene dado, no porque el código sea incorrecto sino porque se asume que los parametros de entrada son correctos, es decir, no se tienen en cuenta todas las posibilidades. Así si suponemos los siguientes valores para los campos

Nace stackframe.net

Después de mucho tiempo (más del que pensaba), y bastante esfuerzo en poner todas las cosas en su sitio al fin ha nacido stackframe.net.

Dentro de las cosas nuevas que tiene está un rediseño de la apariencia (básicamente otro tema distinto con algunas modificaciones :D), la actualización a Drupal 6 y el sistema multilenguaje que me permite publicar en español y en inglés.

Además hay un montón de cosas que han mejorado, como la tabla de contenidos, el sistema de votos y alguna cosilla más.

Están prácticamente todos los contenidos de TheAlphasite disponibles y los pocos que quedan por portar lo estarán en pocos días. Actualmente estoy estableciendo las redirecciones desde los artículos de aquí a los de allí y en pocos días estará completamente operativo.

He estado publicando en The Alphasite durante 2 años, mejor o peor, a gusto de cada cual, y ahora quiero seguir por el mismo camino en un nuevo sitio, pero ampliando los contenidos para abarcar dos idiomas (y creedme, el tiempo que lleva traducirlo todo es enoooorme). Espero que os guste la nueva página y que la disfrutéis y os sirva de ayuda.

No olvidéis actualizar vuestros lectores de feed a las nuevas direcciones:

Stackframe en español: http://feeds.feedburner.com/stackframenet

Stackframe en inglés: http://feeds.feedburner.com/stackframeennet

Programación Funcional

Si, como yo, habéis tenido la suerte/desgracia (apliquensé los dos términos) de estudiar programación funcional en la carrera (haskell, lisp, hope o variantes) sin duda pensaríais que aquello era lo menos práctico y lo más inútil que había para programar, en especial si antes ya habíais programado en algún lenguaje imperativo como c o pascarl.

El problema, en mi opinión que viene de mi caso concreto, viene del hecho de que en la universidad se limitan a enseñarte el como, dandote una introducción a la programación funcional y la programación en general, sin preocuparse de enseñarte las vent

C# 3.0. Nuevas características III

Introducción

matrix_ico.jpg

Seguimos con un repaso a las características nuevas de C# 3.0, en la primera parte vimos el uso de de propiedades automáticas e inicializadores de objetos y colecciones. En la segunda parte vimos una introducción al uso de extensiones, que nos proporionan una forma no intrusiva de ampliar la funcionalidad de una clase.

En esta última parte vamos a ver la expresiones lambda y su integración con Linq así como algunas de las funciones que nos proporciona este último.

Expresiones Lambda

En C# 2.0 se introdujo el concepto de métodos anónimos. Estos métodos mejoraban la forma de escribir código de forma que nos ahorrabamos la necesidad de escribir un método para un delegado, simplificando conseguían una mejora de este estilo:

C# 3.0. Nuevas características II

Introducción

matrix_ico.jpg En la entrada anterior comenzamos a ver las características de c# 3.0, concretamente la inclusión de los inicializadores de objeto y las propiedaes automáticas, que, como vimos, nos permitían mostrar nuestro código de una forma mucho más limpia.

En esta nueva entrega vamos a ver los metodos de extensión que al igual que lo anterior nos facilitarán la vida en ciertas tareas e incluso nos permitiran cambiar, en cierto sentido, nuestra forma de programar.

En términos generales los métodos de extensión se limitan a proporcionarnos la capacidad de extender una clase o interfaz ya existente añadiendole nuevos métodos, es decir, complementar esa clase con nueva funcionalidad (cosas que, por ejemplo, hemos tenido que tener en cuenta más tarde), aunque donde realmente consiguen su máxima potencia los métodos de extensión es en los interfaces y clases genéricos, y su mejor ejemplo (que ya veremos más adelante) es LinQ