La semana pasada tuve en el trabajo un minicurso de 2 días sobre patrones de diseño. Para quien no lo sepa, según la wikipedia:

Los patrones de diseño (design patterns) son la base para la búsqueda de soluciones a problemas comunes en el desarrollo de software y otros ámbitos referentes al diseño de interacción o interfaces.

Un patrón de diseño es una solución a un problema de diseño. Para que una solución sea considerada un patrón debe poseer ciertas características. Una de ellas es que debe haber comprobado su efectividad resolviendo problemas similares en ocasiones anteriores. Otra es que debe ser reusable, lo que significa que es aplicable a diferentes problemas de diseño en distintas circunstancias.

Esto es, soluciones a problemas que se nos pueden presentar en nuestros desarrollos que ya han sido probadas por otros que se enfrentaron a estos mismos problemas y que, por tanto, se ha mostrado su efectividad.

Siguiendo con el curso, éste se dividía en dos: enfocado a los diseñadores y enfocado a los constructores. Estuvimos primero viendo los patrones generales más típicos: singleton, factory, builder… la gran mayoría de los que aparecen en el enlace anterior de la wikipedia. Y después nos adentramos más en conocer los patrones que utilizamos (o deberíamos utilizar) en el trabajo: los patrones en J2EE. Por último, y no menos importante, vimos una serie de antipatrones que muchas veces utilizamos en nuestro trabajo diario y que deberíamos evitar (apoyado por una serie de buenas prácticas que nos facilitarían la escritura de código). Por cierto, ahora que hablo sobre antipatrones, leyendo mis feeds me encontrado con un buen artículo de VariableNotFound.

En fin, que el curso estuvo bastante bien (todo sea por desarrollar software de mayor calidad) porque desconectamos un poco del día a día en el trabajo. Quizás en próximos posts hable algo más sobre patrones de diseño.

Las 10 vulnerabilidades en aplicaciones web más comunes:

1. Cross Site Scripting (XSS)

Los XSS ocurren cada vez que una aplicación coge los datos suministrados por el usuario y los envía sin primero validar o codificar ese contenido. XSS permite a los atacantes ejecutar scripts en el navegador de la víctima que pueden obtener las sesiones del usuario, desfigurar los sitios webs, introducir posiblemente gusanos, etc.

2. Injection Flaws

Los fallos de inyección, particularmente la inyección SQL, son comunes en aplicaciones web. La inyección ocurre cuando los datos suministrados por el usuario son enviados a un intérptrete como parte de un comando o consulta. Los datos hostiles de los atacantes trucan el intérprete ejecutando comandos involuntarios y cambiando datos.

3. Malicious File Execution

El código vulnerable a la inclusión remota de archivos (IRF) permite a los atacantes incluir código y datos hostiles, resultando en ataques devastadores, como el compromiso total del servidor. Estos ataques malignos afectan a PHP, XML y cualquier framework que acepte nombre de archivos o archivos por los usuarios.

4. Insecure Direct Object Reference

Una referencia a objeto directa ocurre cuando un desarrollador expone una referencia a un objeto de implementación interno, como un archivo, directorio, registro de base de datos, o clave, como una URL o parámetro de un formulario. Los atacantes pueden manipular esas referencias para acceder a otros objetos sin autorización.

5. Cross Site Request Forgery (CSRF)

Un ataque CSRF fuerza un registro del navegador de la víctima a enviar una respuesta pre-autenticada a una aplicación web vulnerable, la cual fuerza entonces al navegador de la víctima a realizar una acción hostil en beneficio del atacante. El CSRF puede ser tan poderoso como la aplicación web a la que ataca.

6. Information Leakage and Improper Error Handling

Las aplicaciones pueden mostrar sin intención información sobre su configuración, funcionamientos internos, o violación de la privacidad a través de una variedad de problemas de la aplicación. Los atacantes utilizan esta debilidad para robar datos sensibles, o dirigirse a ataques más serios.

7. Broken Authentication and Session Management

Las credenciales de la cuenta y las cadenas de la sesión a menudo no son protegidas correctamente. Los atacantes comprometen contraseñas, claves o cadenas de autenticación para asumir las identidades de otros usuarios.

8. Insecure Cryptographic Storage

Las aplicaciones web raramente utilizan funciones criptográficas correctamente para proteger los datos y las credenciales. Los atacantes utilizan los datos debilmente protegidos para realizar robo de identidad y otros crímenes, tales como fraudes con tarjetas de créditos.

9. Insecure Communications

Las aplicaciones frecuentemente fallan al cifrar el tráfico de la web cuando es necesario proteger las comunicaciones sensibles.

10. Failure to Restrict URL Access

Con frecuencia, una aplicación solo protege la funcionalidad sensible no mostrando los enlaces o URLs a usuarios no autorizados. Los atacantes pueden usar esta debilidad para tener acceso y realizar operaciones no autorizadas al acceder a estas URLs directamente.

Fuente: OWASP

La siguiente función modifica el contenido de un String buscando una secuencia de caracteres y reemplazándolos por otros:

Se trata de una función muy corta pero que puede ser muy útil. Veamos algún ejemplo de utilización:

Yo tengo este tipo de funciones agrupadas en una misma clase como funciones estáticas. De este modo puedo utilizar estas funciones en todos mis proyectos sin tener que copiar y pegar la función en cada proyecto nuevo. Tan sólo tengo que importar mi clase StringUtils (es el nombre de la clase, no es muy original pero se entiende bien lo que contiene) que tengo guardada en mi librería de clases.

La programación extrema o XP es una metodología de desarrollo que se englobaría dentro de las denominadas metodologías ágiles en la que se da máxima prioridad a la obtención de resultados y reduce la burocracia que se produce al utilizar otras 'metodologías pesadas'.

Todo en el software cambia. Los requisitos cambian. El diseño cambia. El negocio cambia. La tecnología cambia. El equipo cambia. Los miembros del equipo cambian. El problema no es el cambio en sí mismo, puesto que sabemos que el cambio va a suceder; el problema es la incapacidad de adaptarnos a dicho cambio cuando éste tiene lugar.

Kent Beck.

El autor de la XP es Kent Beck, entre otros, que con su larga experiencia como programador eligió las mejores características de las metodologías y profundizó en las relaciones de éstas y como se reforzaban unas a otras. Por tanto, la XP no se basa en principios nuevos, sino que todas, o casi todas, sus características ya se conocen dentro de la ingeniería del software, las cuales se complementan para minimizar los típicos problemas que pueden surgir en todo desarrollo de proyectos software.

Objetivos de la programación extrema

El objetivo principal de la XP es la satisfacción del cliente. Se le trata de dar al cliente lo que quiere y cuando quiere. Por tanto, se debe responder rápidamente a las necesidades del cliente, aunque realice cambios en fases avanzadas del proyecto. Como metodología ágil que es, se pueden producir modificaciones de los requisitos del proyecto a lo largo de su desarrollo, sin que esto produzca un buen dolor de cabeza.

Otro de los objetivos es el trabajo en grupo. Tanto los jefes del proyecto, clientes y desarrolladores forman parte del equipo y deben estar involucrados en el desarrollo.

Valores de la programación extrema

Para garantizar el éxito de un proyecto, los autores de XP han considerado como fundamentales cuatro valores:

• Comunicación. Muy importante. La XP ayuda mediante sus prácticas a la comunicación entre los integrantes del grupo de trabajo: jefes de proyecto, clientes y desarrolladores.
• Sencillez. Los programas deben ser los más sencillos posibles y tener la funcionalidad necesaria que se indican en los requisitos. No hay que añadir algo que no se necesite hoy. Si se necesita añadir más funcionalidad mañana pues ya se hará entonces.
• Retroalimentación. Las pruebas que se le realizan al software nos mantiene informados del grado de fiabilidad del sistema.
• Valentía. Asumir retos, ser valientes ante los problemas y afrontarlos. El intentar mejorar algo que ya funciona. Aunque gracias a las pruebas unitarias no existe el riesgo de 'meter la pata'.

Algunas voces, añaden además un quinto valor: la humildad. Con la compartición de código, la refactorización y el trabajo de equipo tan estrecho una buena dosis de humildad siempre es de agradecer.

Prácticas de la programación extrema

12 son las prácticas de la XP:

• El juego de la planificación (the planning game). Es un permanente diálogo entre las partes empresarial (deseable) y técnica (posible).
• Pequeñas entregas (small releases). Cada versión debe de ser tan pequeña como fuera posible, conteniendo los requisitos de negocios más importantes, las versiones tiene que tener sentido como un todo, me explico no puedes implementar media característica y lanzar la versión.
  Es mucho mejor planificar para 1 mes o 2 que para seis meses y un año, las compañías que entregan software muy voluminoso no son capaces de hacerlo con mucha frecuencia.
• Metáfora (metaphor). Una metáfora es una historia que todo el mundo puede contar a cerca de cómo funciona el sistema. Algunas veces podremos encontrar metáforas sencillas “Programa de gestión de compras, ventas, con gestión de cartera y almacén”. Las metáforas ayudan a cualquier persona a entender el objeto del programa.
• Diseño sencillo (simple design). Cuando implementamos nuevas características en nuestros programas nos planteamos la manera de hacerlo lo mas simple posible, después de implementar esta característica, nos preguntamos como hacer el programa mas simple sin perder funcionalidad, este proceso se le denomina recodificar o refactorizar (refactoring). Esto a veces nos puede llevar a hacer mas trabajo del necesario, pero a la vez estaremos preparando nuestro sistema para que en un futuro acepte nuevos cambios y pueda albergar nuevas características. No debemos de recodificar ante especulaciones si no solo cuándo el sistema te lo pida.
• Pruebas (testing). No debe existir ninguna característica en el programa que no haya sido probada, los programadores escriben pruebas para chequear el correcto funcionamiento del programa, los clientes realizan pruebas funcionales. El resultado un programa mas seguro que conforme pasa el tiempo es capaz de aceptar nuevos cambios.
• Refactorización (refactoring). Cuando implementamos nuevas características en nuestros programas nos planteamos la manera de hacerlo lo mas simple posible, después de implementar esta característica, nos preguntamos como hacer el programa mas simple sin perder funcionalidad, este proceso se le denomina recodificar o refactorizar (refactoring). Esto a veces nos puede llevar a hacer mas trabajo del necesario, pero a la vez estaremos preparando nuestro sistema para que en un futuro acepte nuevos cambios y pueda albergar nuevas características. No debemos de recodificar ante especulaciones si no solo cuándo el sistema te lo pida.
• Programación por parejas (pair programming). Todo el código de producción lo escriben dos personas frente al ordenador, con un sólo ratón y un sólo teclado. Cada miembro de la pareja juega su papel: uno codifica en el ordenador y piensa la mejor manera de hacerlo, el otro piensa mas estratégicamente, ¿Va a funcionar?, ¿Puede haber pruebas donde no funcione?, ¿Hay forma de simplificar el sistema global para que el problema desaparezca?
  El emparejamiento es dinámico, puedo estar emparejado por la mañana con una persona y por la tarde con otra, si tienes un trabajo sobre un área que no conoces muy bien puedes emparejarte con otra persona que si conozca ese área. Cualquier miembro del equipo se puede emparejar con cualquiera.
• Propiedad colectiva (collective ownership). Cualquiera que crea que puede aportar valor al código en cualquier parcela puede hacerlo, ningún miembro del equipo es propietario del código. Si alguien quiere hacer cambios en el código puede hacerlo. Si hacemos el código propietario, y necesitamos de su autor para
  que lo cambie entonces estaremos alejándonos cada vez mas de la comprensión del problema, si necesitamos un cambio sobre una parte del código lo hacemos y punto. XP propone un propiedad colectiva sobre el código nadie conoce cada parte igual de bien pero todos conoce algo sobre cada parte, esto nos preparará para la sustitución no traumática de cada miembro del equipo.
• Integración continua (continuos integration). El código se debe integrar como mínimo una vez al día, y realizar las pruebas sobre la totalidad del sistema. Una pareja de programadores se encargara de integrar todo el código en una maquina y realizar todas las pruebas hasta que estas funcionen al 100%.
• 40 horas semanales (40-hour week). Si queremos estar frescos y motivados cada mañana y cansado y satisfecho cada noche. El viernes quiero estar cansado y satisfecho para sentir que tengo dos días para pensar
  en algo distinto y volver el lunes lleno de pasión e ideas. Esto requiere que trabajemos 40 horas a la semana, mucha gente no puede estar más de 35 horas concentrada a la semana, otros pueden llegar hasta 45 pero ninguno puede llegar a 60 horas durante varias semanas y aun seguir fresco, creativo y confiado. Las horas extras son síntoma de serios problemas en el proyecto, la regla de XP dice nunca 2 semanas seguidas realizando horas extras.
• Cliente en casa (on-site costumer). Un cliente real debe sentarse con el equipo de programadores, estar disponible para responder a sus preguntas, resolver discusiones y fijar las prioridades. Lo difícil es que el cliente nos ceda una persona que conozca el negocio para que se integre en el equipo normalmente estos elementos son muy valiosos, pero debemos de hacerles ver que será mejor para su negocio tener un software pronto en funcionamiento, y esto no implica que el cliente no pueda realizar cualquier otro trabajo.
• Estándares de codificación (coding standards). Si los programadores van a estar tocando partes distintas del sistema, intercambiando compañeros, haciendo refactoring, debemos de establecer un estándar de codificación aceptado e implantado por todo el equipo.

Algunas de estas prácticas reciben muchas críticas, sobre todo la programación por parejas. Muchos jefes de proyecto no aceptan que dos desarrolladores tengan un único ordenador, ya que creen que esto minimizará la productividad, sin saber que de este modo puede producirse el mismo código que dos personas trabajando en solitario pero con un código de mayor calidad.

Se dice que si no se realizan estas doce prácticas no se está realizando XP. Yo, a mi modo de verlo, creo que nosotros no tenemos que adaptarnos a ninguna metodología, sino que ellas se tienen que adaptar a nosotros dependiendo del tipo de proyecto que estemos desarrollando.

Bueno, esta ha sido una 'breve' introducción a la programación extrema. Seguro que algunas de las prácticas que se han visto anteriormente la has utilizado. Como dije al principio, la XP es más una filosofía de trabajo que recoge lo mejor de las distintas metodologías y las junta para que se refuercen unas a otras.

En ActionScript 2.0 teníamos la clase Number para manejar números, tanto enteros como reales. Ahora en AS 3 seguimos manteniendo la clase Number pero se han añadido 2 nuevos tipos de datos: int y uint.

Si utilizamos números enteros que se encuentren dentro del rango que tienen estos dos tipos de datos es mejor usarlos al tipo Number ya que es más rápido y eficaz.

Una breve descripción de estos tipos de datos:

• int. Entero con signo de 32 bits.
  • Valor predeterminado: 0.
  • Valor mínimo: -2147483648
    Código
    Actionscript:

    1. trace(int.MIN_VALUE);  // output: -2147483648

  • Valor máximo: 2147483647
    Código
    Actionscript:

    1. trace(int.MAX_VALUE);  // output: 2147483647

• uint. Entero sin signo de 32 bits.
  • Valor predeterminado: 0.
  • Valor mínimo: 0
    Código
    Actionscript:

    1. trace(uint.MIN_VALUE);  // output: 0

  • Valor máximo: 4294967295
    Código
    Actionscript:

    1. trace(uint.MIN_VALUE);  // output: 4294967295

Cuando se declara e inicializa una variable de tipo int o uint se puede hacer de dos formas: con un literal o utilizando el operador new. Las dos líneas siguientes son equivalentes:

Hoy me he encontrado en la documentación de Adobe una página donde se muestran todas las diferencias que existen entre AS 2.0 y AS 3.0. Un documento directo para mis marcadores y un buen punto de partida para ir aprendiendo AS3 si ya conocía algo de la versión anterior.

En ActionScript 3.0 todas las clases deben ser colocadas en paquetes. Un paquete (o package) es una manera de organizar clases en grupos, y en ActionScript 3.0 un paquete es sinónimo a un directorio del sistema de archivos. Los paquetes se ordenan relativamente al classpath, el cual es definido como una ruta relativa al proyecto (el archivo .fla en el caso de Flash). Por lo tanto, el paquete top-level es sinónimo de la raiz del proyecto. La declaración del paquete es siempre la primera sentencia que aparece en un fichero de claso; un ejemplo de su sintaxis en la que sigue:

Cuando la clase es definida como parte del paquete top-level, el nombre del paquete no necesita ser especificado. En estos casos, la declaración del paquete es la siguiente:

Cuando el archivo de clase es guardado dentro de un subdirectorio, el nombre del paquete se corresponde con la ruta relativa del subdirectorio usando puntos (.) entre cada directorio. Por ejemplo, si es archivo es guardado en un subdirectorio (relativo a la raiz del proyecto) llamado example, entonces la declaración del paquete es:

ISi el archivo de clase es guardado en un subdirectorio de example llamado subpackage, la declaración del paquete será:

Los paquetes son una parte importante en el trabajo con clases porque permiten aseguarte que tus clases no entrarán en conflicto con otras clases. Por ejemplo, es posible que dos desarrolladores escribieran dos clases diferentes y las nombraran MessageManager. Las dos clases tendrían el mismo nombre pero se utilizarían para diferentes tares. Una administraría emails mientras que la otra administraría mensajes binarios de sockets. No puedes tener dos clases con el mismo nombre en el mismo ámbito. Si lo tuvieras, el compilador no sabría cual de ellas usar. Una opción es usar siempre nombres de clases únicos.

En este ejemplo, podrías nombrar las clases EmailManager y BinarySocket, pero hay buenas razones por lo que esto no siempre es posible. Como que un proyecto podría usar potencialmente ciendos de clases, esto dificultaría mucho el asegurar nombres únicos a las clases. Además, muchos proyectos utilizan librerías de código ya escritas, y no podrías modificar mucho de estas clases. Ya que muchas clases de la librería tendrían dependencias con otras clases, sería muy difícil modificar el nombre de estas clases. Ahí es donde los paquetes hace las cosas más sencillas. Piensa que no puedes tener dos clases con el mismo nombre en el mismo directorio, pero puedes tener tantas clases con el mismo nombre como quieres, si éstas se encuentran en diferentes directorios. Los paquetes te permiten colocar un MessageManager en el paquete net.messaging.email y el otro en el paquete net.messaging.binarysocket.

Aunque los nombres de paquetes anteriores serían inicialmente unas buenas opciones, es posible usar un nombre de paquete mejor para asegurar una probabilidad mayor de unicidad. Generalmente es mejor usar nombres de paquetes que se correspondan con el autor y/o un proyecto relevante. Por convención, los nombres de paquete empiezan con nombres de dominio en orden inverso. Por ejemplo, si yo (davidvalverde.com) escribo clases en ActionScript 3.0, guardaría todas las clases en el paquete com.davidvalverde (o un subpaquete de com.davidvalverde). De esta manera, me aseguro de la unicidad de los nombres de las clases (no creo que nadie más que yo use el paquete com.davidvalverde para organizar sus clases XD ).

Cuando las clases forman parte de una libería común usada para muchos proyectos dentro de la compañía/organización entonces pueden ser colocadas en subpaquetes directamente dentro del paquete principal. Por ejemplo, si las clases anteriormente mencionadas MessageManager forman parte de una libería común usada por muchas aplicaciones que yo desarrolle, entonces deberían guardarse en los paquetes com.davidvalverde.net.messaging.email y com.davidvalverde.net.messaging.binarysocket. Cuando una clase forma parte de una aplicación específica, debería guardarse dentro de un subpaquete específico de esa aplicación. Por ejemplo, tengo una aplicación llamada WidgetStore. Si la aplicación WidgetStore usa una clase llamada ApplicationManager, entonces esta debería ser guardada dentro de com.davidvalverde.widgetstore o un subpaquete de este paquete.

Por cierto, por convención los nombres de los paquetes empiezan siempre con letra minúscula.

Los archivos de clase siempre son guardados en la ruta de directorios que se corresponde con el paquete de la clase. Por ejemplo, com.davidvalverde.net.messaging.email.MessageManager debe ser guardado en com/davidvalverde/net/messaging/email/MessageManager.as. El compilador sabe buscar clases dentro de la ruta que indica el paquete. Sin embargo, el compilador tambien debe conocer donde buscar el directorio top-level que contiene los subdirectorios. En el ejemplo, el compilador necesita saber donde se encuentra el directorio com dentro del sistema. El compilador sabe donde buscar por algo llamado classpath. El classpath por defecto para cualquier proyecto Fles o Flash incluye el directorio del proyecto. Por ejemplo, el directorio com es guardado en el mismo directorio que el archivo .fla (Flash), entonces el compilador encontrará las clases. Sin embargo, podrías querer guardar los ficheros en un directorio diferente. Por ejemplo, si tienes una librería común usada por muchos proyectos, seguro que querías guardar esa librería en un lugar mejor que estar copiándola para cada proyecto. Puedes añadir y editar el classpath para que el compilador conozca donde buscar todas tus clases.

En Flash, puedes editar el classpath tanto a nivel de proyecto como globalmente. A nivel de proyecto, selecciona Archivo>Configuración de publicación, y selecciona el botón Configuración... de ActionScript en la pestaña Flash. Para el classpath global, selecciona Edición>Preferencias, y selecciona el botón Configuración... de ActionScript. Ambos abren una ventana de diálogo similar que te permite editar el classpath. Tu puedes seleccionar el botón + para añadir un nuevo directorio al classpath. Por ejemplo, si el directorio com para la librería está guardado en c:\libraries, entonces deberías añadir c:\libraries al classpath.

Una CheatSheet es una especie de 'chuleta' donde vienen recogidas la mayoría de las funciones de un lenguaje. Viene bien para recordar la sintaxis del lenguaje, parámetros de las funciones y palabras clave. Y sirve tanto para gente que está aprendiendo como para gente que ya tiene años de experiencia en el lenguaje (que siempre se olvida algo XD ).

Como estoy aprendiendo ActionScript 3.0, aquí tenemos la AS3 CheatSheet, 3 páginas con las clases y métodos del lenguaje, operadores y palabras clave.