Desarrollo Ágil (IV): Extreme Programming (XP)

La metodología que nos ocupa hoy es la de Extreme Programming (XP). Probablemente sea una de las metodologías de las que más hayáis oído hablar ya que sin duda alguna es una de las más conocidas.

Como todas las metodologías anteriores, esta también pone más interés en la adaptación que en la previsión. Si esto es bueno o malo daría para llenar libros y libros, de hecho lo hace. Los defensores de este método lo defienden apoyándose en la idea de que los requisitos y especificaciones de los sistemas que se están desarrollando habitualmente son cambiantes, ya sea por unas razones o por otras, y opinan que la aproximación de adaptación es mejor o al menos más realista que la de tratar de predecir todo de antemano.

La metodología XP se centra en potenciar las relaciones interpersonales considerando estas clave para el éxito de un proyecto. De esta forma, promueve el trabajo en equipo, el aprendizaje y el buen ambiente de trabajo. Otro de los factores más importantes es esta metodología es la comunicación tanto entre los participantes en un proyecto con el cliente. Y por supuesto, la preparación técnica del equipo involucrado en el desarrollo.

En general, la metodología XP se considera especialmente adecuada para proyectos con requisitos imprecisos y/o muy cambiantes.

Los elementos de la metodología serían los siguientes:

- Historias de usuario: Se trataría de “tarjetas” donde el cliente especifica requisitos funcionales o no.  Dichos requisitos deberán ser entendibles e implementables en unas pocas semanas. Cada tarea, terminará siendo una tarea de programación asignada a un desarrollador durante una iteración.

- Roles XP: Los roles habituales que componen un equipo XP serían:

· Programador: Escribe código y realiza pruebas unitarias.

· Cliente: Obvio, encarga el trabajo, escribe las historias de usuario y prioriza tareas.

· Tester: Escribe pruebas funcionales junto al cliente y, ejecuta y difunde los resultado de las pruebas regularmente.

· Tracker: Realiza el seguimiento de las distintas iteraciones, estimaciones frente a tiempo real, para poder afinar las estimaciones.

· Coach: Es el responsable del equipo XP, se encarga de que este siga el proceso correctamente.

· Consultor: Miembro externo experto en algún tema concreto al que acudir en caso de problemas.

· Gestor: Unión entre el cliente y el equipo de desarrollo. Sus labores son de coordinación principalmente.

Proceso XP:

El proceso XP consta de las diferentes fases que se deben ejecutar en cada iteración.

1. Definición de requisitos a implementar

2. Estimación del programador.

3. Desarrollo del requisito.

4. Vuelta al paso 1.

Por otra parte, se considera que un ciclo de vida XP ideal son 6 fases: exploración, planificación de la entrega, iteraciones, producción, mantenimiento y muerte del proyecto.

Elementos  a poner en práctica:

- Jugando con la planificación: La comunicación frecuente entre el cliente y el equipo hace que el equipo produzca estimaciones de requisitos y que el cliente elija el ámbito y tiempo de entrega de cada iteración.

- Entregas pequeñas: Menores en todo caso a 3 meses. No tiene por que ser una funcionalidad completa, pueden ser pequeñas versiones operativas que formarán un todo después.

- Metáfora: Yo puse la misma cara al leerlo la primera vez. A mi entender sería algo como un diccionario de datos que comparten cliente y equipo para asegurarse de hablar el mismo idioma.

- Diseño simple: Se apostará siempre por la solución más simple.

- Refactorización: Se harán continuas refactorizaciones de código para evitar duplicidad, mejorar legibilidad, hacer más fácil futuros cambios, etc…

- Programación por parejas: El desarrollo por parejas evita errores y produce un mejor diseño. Ya sabéis, aquello de “cuatro ojos ven más que dos”.

- El código es de todos: No hay partes que solo toque uno u otro desarrollador, todo el mundo puede tocar todo.

- Integración continua: Cada parte de código terminada se integrará en el sistema, con lo cual será integrado, construido y probado varias veces al día con toda probabilidad.

- 40 horas semanales: Si necesitamos trabajar más horas, algo está yendo mal.

- Cliente accesible: El cliente tiene que estar disponible y a ser posible presente para que el equipo pueda resolver sus dudas.

- Seguimiento de estándares: Debido a la poca documentación que se genera, el código debe servir de comunicación, por lo cual, es muy importante seguir estándares definidos.

Principios:

Lista de principios básicos que persigue la programación extrema:

- Simplicidad: Un diseño simple, un código simple y unas soluciones simples. Esto ayudará a facilitar el mantenimiento, las modificaciones y el desarrollo de nuevas funcionalidades. Esto se consigue a través de los estándares, la programación por parejas y las auditorias de código colectivo, permitiendo que todos los desarrolladores conozcan y puedan entender de forma fácil el código.

- Comunicación: La comunicación entre los desarrolladores se realiza a través del código ya que los comentarios pueden quedar rápidamente desfasados. Ojo, esto no implica no poner comentarios. Los casos de pruebas también sirven como forma de comunicación. Además, los desarrolladores se comunican de forma constante gracias a la programación por parejas. Por otra parte, como el cliente forma parte del equipo, también existe una comunicación fluida con él.

- Feedback: Tanto por parte del cliente como por parte de los desarrolladores. Del cliente sobre el estado del proyecto. De los desarrolladores sobre los resultados y estimaciones. Una parte importante de este feedback nos lo dan también los casos de pruebas que nos ayudan a mantener nuestro código en forma.

- Coraje o valentía: Para ceñirse al proceso y no caer en tentaciones o malas prácticas, y sobre todo para ponerlo en práctica.

Actividades:

En la metodología XP se describen cuatro actividades que se llevan a cabo dentro del proceso de desarrollo:

- Codificar: La mayoría de defensores de esta metodología defiendes que el código es al final lo que importa, que sin él no hay nada. El código sirve para comunicar, discutir, en caso de duda implementar varias versiones para decidir y además, cualquier desarrollador puede proponer sus ideas con una pequeña modificación sobre el código de otro. En definitiva, el código es claro, conciso y no da lugar a interpretaciones.

- Probar: Nadie implementa nada a la primera y todo funciona perfectamente, ¿o si? Y en ese caso, ¿cómo lo demuestra? Mediante las pruebas. De tipo unitario para probar el funcionamiento de nuestro código en particular, y de tipo funcional para validar la correcta implementación de los requisitos del cliente. Vamos, lo que viene siendo “Validación y Verificación”.

- Escuchar: Escuchar al cliente para entender sus necesidades e implementar un software adecuado a su negocio, no a lo que creemos entender de su negocio. Por mucho que un desarrollador sepa, raro es que sepa más que el propio cliente sobre su negocio.

- Diseñar: Una parte muy importante es el diseño, ya que a medida que el sistema crece se pierde visibilidad sobre dependencias y sobre las diferentes partes del sistema. Para evitar esto, lo mejor es un buen diseño.

Bueno, y hasta aquí XP. Si tenéis alguna duda o algo no ha quedado claro animaros a preguntar. Nos vemos.

Desarrollo Ágil (III): Comparativa entre métodos

Un pensamiento generalizado es que los métodos ágiles no son ni disciplinados ni planificados, y a pesar de que esto es totalmente erróneo es difícil, en muchas ocasiones, quitarles esta etiqueta. Lo cierto, es que los métodos ágiles pueden ser desde adaptativos a predictivos con el amplio abanico de puntos intermedios que esto conlleva. De hay que den esa impresión en ocasiones, si los miras desde fuera, de que son un poco caóticos.

Los métodos predictivos son aquellos que se centran en las planificaciones a futuro y en que estas sean lo mas detalladas posibles de forma que puedan en cualquier momento saber que tendrán que hacer a lo largo de toda la duración del proyecto. Desafortunadamente, estos planes de proyecto se basan en la definición inicial de este, con lo cual todos los cambios de dirección o alcance que puedan acontecer durante su transcurso serán difícilmente incorporables y requerirán de un esfuerzo extra para cambiar el rumbo del proyecto, por no mencionar, de que en ocasiones parte del trabajo hecho puede ser descartado para adaptarse a la nueva dirección.

En contraposición a esto, tenemos los métodos adaptativos. Métodos en los cuales, aunque no se podrá explicar con claridad las tareas a futuro, si que son altamente adaptables a cambios. Es decir, un equipo adaptativo podrá explicar con toda claridad que va a hacer la semana que viene, podrá explicar las características planificadas para dentro de un mes, pero como mucho, podrá hacer solamente una declaración de intenciones para dentro de seis meses.

Pues bien, como se ha comentado antes, los métodos ágiles pueden alojarse en cualquier punto entre ambos extremos.

Como ya se ha comentado anteriormente, los métodos ágiles se enmarcan dentro de los métodos iterativos ya que ambos se fijan el mismo objetivo de la liberación de software en cortos periodos de tiempo. La principal diferencia entre unos y otros, es que mientras que los métodos iterativos suelen medir estos periodos por meses, los métodos ágiles lo hacen en semanas. Además, en estos últimos, el trabajo se realiza de forma colaborativa.

Otro de los métodos más habituales es el de cascada que basa toda su fortaleza en la planificación y separación de todas las fases del proyecto: toma de requisitos, análisis, diseño, codificación y pruebas, cada una de ellas con unos entregables específicos para poder medir y controlar el correcto desarrollo del proceso. El principal problema que representa este modelo, es la dificultad de adaptarse a los cambios que se producen tras en inicio del proceso de desarrollo. Por este motivo, el modelo en cascada no se debería utilizar si no están claramente especificados los requisitos o se sospecha que en algún momento del proyecto estos pueden cambiar.

En una metodología ágil, este problema no se da, ya que al realizarse la planificación cada pocas semanas, la adaptación al cambio no es demasiado compleja.

Aún así, como para todo, hay opiniones que defienden unos y otros métodos.

Otro de los métodos es al que yo llamo ASM (A Salto de Mata) y que en ocasiones lo he visto también etiquetado como “cowboy”.Este método se basa en que los desarrolladores hacen lo que creen que es correcto, avanzando allí por donde pueden y solucionando los problemas como, en su opinión, creen que es correcto. En este tipo de proyecto se caracteriza por una comunicación de forma verbal, ausencia de documentación y reevaluaciones del proyecto.

Algunas de las características de los métodos ágiles concuerdan en ocasiones con esta última metodología, por este motivo, se desconfía de las metodologías ágiles.

Pero la verdad dista mucho de esto. Es cierto que la comunicación en los métodos ágiles, en muchas ocasiones en verbal y no genera documentación, pero no nos equivoquemos, esta comunicación es periódica, estricta, disciplinada y rigurosa, lo cual la diferencia sin duda del método ASM.

No vemos.

Eligiendo una metodología ágil

Como habréis visto, últimamente, hemos empezado en el blog una serie de artículos sobre “Desarrollo ágil”. A raíz de esto, el otro día leyendo GenbetaDev (podéis ver el enlace en el Blogroll) encontré un artículo interesante con una mini-guia de preguntas para elegir una u otra metodología ágil. Así que, aunque aún no hemos llegado a la explicación sobre dichas metodologías, me parece interesante poner el enlace a dicho artículo.

Test de metodologías ágiles, ¿Qué metodología es mejor: Scrum, Kanban o Scrumban?

Espero que os sirva de algo. Nos vemos.

Desarrollo Ágil (II): Características

Las metodologías ágiles se encuentran dentro de las conocidas como metodologías “iterativas” o “incrementales”. Por así decirlo, se las puede considerar un subconjunto de estas. Para el que lo desconozca, aunque no es ámbito de esta serie de post (es posible que los tratemos con posterioridad en otra seria), este tipo de metodologías basan su trabajo en la realización de diferentes ciclos sobre las etapas del desarrollo de software para intentar paliar las debilidades de los métodos “tradicionales” poco adaptativos a los cambios. Así un esquema rápido de cómo sería un proyecto de este tipo sería:

-  Planificación inicial

     =  Iteración 1..N

          ◦  Requisitos

          ◦  Análisis y diseño

          ◦  Implementación

          ◦  Pruebas

          ◦  Evaluación

-  Despliegue

Como he dicho es un esquema rápido y muy simple, pero bueno, para que os hagáis una idea creo que bastará.

Como ya habréis deducido, los métodos ágiles se basan en la realización de iteraciones llamadas timeboxes, las cuales tendrán una duración de entre 1 y 4 semanas. Por cada una de estas iteraciones se realizará un ciclo completo de desarrollo que terminará liberando una versión estable del producto pero sin tener necesariamente que ser liberable al mercado. En general, se necesitarán múltiples iteraciones para liberar un producto nuevo o nuevas características de un producto ya existente. Este tipo de sistema permite al proyecto adaptarse a cambios muy rápidamente y, que estos cambios sean bien recibidos y no un gran problema.

La composición de equipos en un entorno ágil suele ser multidisciplinar y suele dar poca importancia a los roles o jerarquías corporativas ya que cada uno de los miembros del equipo es responsable de las tareas que tiene asignadas y de cómo llevarlas a cabo para que al final de la iteración estén completadas de forma correcta.

En este tipo de metodologías, se prima mucho más la comunicación cara a cara que la generación de documentos escritos. En general los equipos de desarrollo ágil no suelen ser muy grandes, entre 5 y 9 personas, lo cual facilita esta comunicación. Esta comunicación, en la mayoría de métodos ágiles se hace de forma rutinaria en forma de reunión diaria para informar de los progresos del día anterior, el planning del día y los problemas encontrados. En general, a este tipo de reuniones asiste el equipo de desarrollo y un representante del cliente.

Al final de cada iteración, dicho representante del cliente revisará el progreso del desarrollo y reevaluará las prioridades de negocio y retorno de inversión para, en caso de ser necesario, redirigir en la siguiente iteración el desarrollo del proyecto hacía los intereses del cliente.

En los métodos ágiles el progreso de un proyecto se mide por el software operativo generado hasta el momento, ya que por ejemplo, al existir la comunicación diaria y cara a cara, le generación de documentación es mucho menor que en otros proyectos.

Desarrollo Ágil (I): Introducción

Todo aquel que se dedique al desarrollo de software sabrá que no es un campo ni fácil ni simple y, que en cuanto un proyecto empieza a tomar grandes dimensiones el hacerlo en modalidad ASM (a salto de mata) no es viable. Es más, en cualquier tipo de empresa, este método es inviable ya que se deben perseguir unos plazos fijos, no superar unos costes establecidos y, por supuesto, entregar un producto de calidad.

Cuando hablamos del desarrollo de software y de todos los procesos implicados en él, hablamos de algo complejo y difícil de manejar salvo que se tenga algún tipo de metodología. Por esta razón, desde que se empezó con el desarrollo de software, se han intentado crear diferentes métodos, algunos más afortunados que otros, para manejar todas las complejidades que se dan en el proceso de desarrollo de software.

Inicialmente, la mayoría de los métodos que aparecieron estaban o bien enfocados a la documentación y generar entregables ajenos a la tarea de desarrollo para poder controlar en mayor o menor medida la evolución del desarrollo, o estaban enfocados en que los desarrolladores siguieran de forma rígida ciertos procesos que no siempre se adaptaban al tipo de desarrollo y hacían a veces, más compleja o desesperante la tarea del desarrollador.

Frente a estos métodos “tradicionales” o “pesados”, en los últimos años están surgiendo una serie de métodos “ágiles”, que tratan de flexibilizar todos los procesos asociados al desarrollo de una aplicación sin ser el desarrollo propiamente dicho. Estas metodologías ágiles, tratan de centrarse en cuatro puntos básicos:

-       Individuos e iteraciones frente a procesos y herramientas.

-       Software funcionando sobre documentación excesiva.

-       Colaboración con el cliente sobre negociación contractual.

-       Respuesta ante el cambio sobre seguir un plan.

Para el que quiera más información sobre esto, os dejo el enlace al Manifiesto para el desarrollo ágil del software.

Los métodos “tradicionales” han demostrado ser efectivos  y necesarios en proyectos de gran tamaño tanto temporal como a nivel de recursos, pero no son el enfoque más adecuado cuando se trata de proyectos más pequeños y en entornos o sistemas muy cambiantes. La utilización de estos métodos tradicionales en este tipo de entornos provocaba que, en muchas ocasiones, se dejaran de lado las buenas prácticas de ingeniería de software asumiendo con ello riesgos innecesarios. En este tipo de escenarios y situaciones, es donde tienen cabida las metodologías ágiles.

Ejemplos de estas metodologías ágiles son:

-       Scrum

-       Crystal Clear

-       Extreme Programming

-       Adaptative Software Development

-       Feature Driven Development

-       Dynamic Systems Development method

Nos vemos en la próxima entrega.

[Nota] La idea de esta serie de post, será la de introducir lo que es el desarrollo ágil y comentar algunas de sus metodologías.

OWASP Top Ten: A10 – Redirecciones y reenvíos no validados

Por fin hemos llegado a la última de las vulnerabilidades del Top Ten de OWASP. La vulnerabilidad que nos ocupa hoy es muy simple. Se trata de la redirección del usuario de nuestra aplicación a una página no segura donde por ejemplo, se puede haber implementado un ataque de phishing o algo similar.

¿Por qué se producen estas redirecciones? Bien, no es difícil encontrar una aplicación que en determinadas ocasiones, por necesidad de la propia aplicación se realice una redirección legítima a través de un valor obtenido por un parámetro.

Un ejemplo sería algo como:

www.example.org/redirigir.php?url=example2.org

Esta página recogería el parámetro y haría una redirección a URL recibida. Pero, ¿qué pasa si un atacante ha conseguido modificar ese parámetro? Pues que nuestra aplicación estaría redirigiendo a una URL ilegítima con las posibles consecuencias de ello. Por ejemplo:

www.example.org/redirigir.php?url=phishing.org

Si nuestro usuario hiciera click en el enlace con la redirección alterada, acabaría sufriendo un ataque de phishing.

Aún así este tipo de ataques son fáciles de evitar, basta con realizar las validaciones oportunas a la hora de hacer redirecciones. Toda redirección realizada  a partir de un parámetro tendría que ser validada previamente comprobando que dicha redirección se va a realizar a un destino válido y confiable. Evidentemente, lo más fácil es hacer esto en tiempo de desarrollo, pero en caso de tener que solventarlo una vez desplegado el proyecto o aplicación, bastaría con hacer una revisión de código para encontrar y comprobar la validación de todas las redirecciones que permitan introducir URLs completas.

Hasta aquí esta serie de artículos sobre OWASP. Espero que os hayan servido si no entendíais alguna de las vulnerabilidades de su Top Ten, o al menos, espero que os haya servido para que os intereséis por el proyecto, ya que es bastante interesante y abarca muchos y diferentes aspectos y perspectivas de la seguridad. Nos vemos.

OWASP Top Ten: A9 – Protección insuficiente de la capa de trasporte

Para hablar de la vulnerabilidad que nos concierne hoy, primero, me temo que voy a tener que hablar del modelo OSI. Supongo que todo aquel que tenga algún tipo de estudio relacionado con informática, redes, telecomunicaciones, etc… sabrá que es, pero por si acaso, como la memoria es muy mala, al menos la mía, vamos a darle un repasito muy pequeño y rápido, y a dejar aunque sea el típico enlace a la Wikipedia.

El modelo OSI, es un modelo de interconexión de sistemas abiertos, o lo que es lo mismo en un lenguaje menos técnico, es la descripción de una propuesta de sistema de conexión entre dispositivos para que estos puedan interactuar entre si a través de una red.

Por resumir un poco, el modelo OSI describe varias capas para realizar la comunicación, el cometido de cada una de estas diferentes capas y como podemos trabajar con ellas para finalmente obtener una comunicación correcta y entendible por parte de otros dispositivos.

Las capas que describe el modelo son siete:

-       Capa física.

-       Capa de enlace de datos.

-       Capa de red.

-       Capa de transporte.

-       Capa de sesión.

-       Capa de presentación.

-       Capa de aplicación.

Cada una de estas capas tiene una tarea especifica encomendad y es la suma de todas ellas lo que posibilita el éxito de la comunicación. Está claro que a raíz de este modelo han surgido otros con más o menos capas y con funciones ligeramente diferentes, pero este, por decirlo de alguna manera, es el básico. La tarea específica de cada una de estas capas no es tema de este post, así que si queréis leer sobre ello porque no lo conocéis o necesitáis refrescar la memoria (como es mi caso) os envío a la Wikipedia, que aunque tiene un artículo cortito, está bastante bien explicado.

Pues bien, ¿y para qué esta introducción? La vulnerabilidad que nos atañe hoy, es una vulnerabilidad de nuestras aplicaciones sobre la capa número cuatro, la de trasporte. Que nadie piense ni por un momento que el modelo está mal definido o especificado. La vulnerabilidad más bien consiste en la falta de protección de los datos que circulan por esta capa que son susceptibles de ser interceptados.

Par la capa de trasporte, si me habéis hecho caso y habéis consultado la Wikipedia o teníais conocimientos sobre el modelo OSI ya, sabréis que discurren los datos que se intercambian entre unos sistemas y otros. Estos datos pueden ir en texto plano o cifrados, por ejemplo con SSL. En caso de ir cifrados no habría ningún problema, ya que, en caso de que alguien los intercepte, no podría leerlos, pero el problema viene cuando estos datos viajan en texto plano. En este momento, un atacante que esté capturando nuestro tráfico podrá tener acceso a múltiple datos sensibles, datos bancarios, tokens de sesión, rutas del sistemas, datos de usuarios, etc…

Lamentablemente,  no todas nuestras aplicaciones llevan su tráfico cifrado y este tipo de ataques, sobre todo en redes internas, no es difícil de llevar a cabo, ya que en estos entornos, por considerarlos de confianza o más seguros se dejan de lado este tipo de precauciones.

Algunas nociones básicas para evitar este tipo de vulnerabilidades serían:

-       Que toda página sensible requiera acceso SSL, en caso de intentar una petición sin SSL, forzarla.

-       Activar el atributo “secure” de las cookies para que el navegador no las mande en texto plano.

-       Por supuesto, si estamos usando SSL, preocuparnos de que el cifrado aplicado sea lo suficientemente fuerte.

-       Verificar la corrección de los certificados utilizados. Fechas, no revocación y dominios que abarca.

-       Por supuesto, conexiones cifradas entre fron-end y back.-end, aunque no sea SSL.

Como despistes habituales, nombraremos por ejemplo:

-       Cifrar con SSL solo la autenticación, dejando los datos de la aplicación y los cookies de sesiones que se trasmitirán durante la navegación sin cifrar.

-       Aplicar SSL con un algoritmo muy flojo o “fácil” de crackear.

-       Abrir un elemento no seguro en una página externa de forma segura. Pongamos el ejemplo de un PDF que abrimos a modo de pop-up en una nueva ventana. Al abrirlo en la nueva esta mostrará una advertencia al usuario desde el navegador, y en ocasiones esto puede hacer que se muestre el identificador de sesión.

-       Por supuesto, la estrella muchas veces, que la cookie navegue como texto plano para que cualquiera la pueda leer.

Bueno, hasta aquí el artículo de hoy. Nos vemos.

[BONUS]

En el artículo se ha hablado de interceptar el tráfico de la aplicación, esto se realiza mediante una herramienta conocida como sniffer. Dicha herramienta permite capturar el tráfico que circula por la red para su posterior análisis. Con ellas se pueden descubrir por ejemplo contraseñas en texto plano navegando por la red. Si queréis más info, aquí tenéis un enlace.

Conservando nuestro código: Dropbox

Supongo que ha estas alturas, casi todos sino todos, conoceréis Dropbox. Para el que no lo conozca, Dropbox es un servicio de alojamiento de archivos en la nube. Podéis leer algo más sobre él en la propia página de Dropbox o en Wikipedia:Dropbox.

Para los desarrolladores puede ser interesante por varios motivos, cada uno tendrá los suyos, tener nuestro código en la nube. Ya sea, por ejemplo, por disponibilidad de poder trabajar desde cualquier lado, o simplemente por seguridad a modo de backup por si pasa algún accidente. Obviamente, este post no aplica para grandes proyecto corporativos ya que estos deberían tener su propio servidores de subversión y servidores de backup, aunque lamentablemente, esto no siempre es así. Luego, todo son pánico, carreras, explicaciones al cliente y presión a los desarrolladores, pero bueno, esto es otra historia.

El post está enfocado más bien a nuestros pequeños proyecto caseros, esos que aunque no son relevantes, son muy importantes para nosotros. Esos en los que trabajas en cualquier sitio en cuanto tienes 5 minutos libres.

Yo voy a proponer dos pequeñas ideas apoyándome en Dropbox. La primera de ellas, está mas relacionada con el backup de nuestros proyectos, y la segunda, con la disponibilidad de estos.

En mi casa, aunque hay varios ordenadores, yo solo utilizo el mío y algún disco duro externo para backups, almacenamiento de datos y demás. Como el disco duro no lo tengo constantemente enchufado, cuando monto un servidor subversión lo hago sobre mi misma máquina, más pensado para controlar las versiones del código que voy escribiendo que pensando en que sea un backup en caso de desastre. Pero claro, un día se produjo este desastre y perdí bastante código, no todo, porque cada semana hago un backup de la máquina, pero si lo suficiente como para que decidiera buscar una solución. Y esta fue Dropbox. Decidí meter mis repositorios dentro de la carpeta de sincronización de Dropbox, y así de forma automática, cada vez que hago un “commit”, toda la información se sube a la nube. Esta fue la primera idea.

Pero, llegó el día en que no llevaba mi ordenador encima, tenía unas horas muertas para malgastar en algo y estaba rodeado de ordenadores, el único problema era que no tenía mi código a mano para trabajar un ratito sobre él. El código estaba en la nube, yo me podía bajar un eclipse en uno de los ordenadores que tenía a mano, pero por razones de capado de puertos, no podía montar un servidor subversión para  bajar el código en él y abrirlo en el eclipse. Y a partir de aquí, fue donde se me ocurrió la idea de meter directamente el workspace de trabajo en la carpeta de Dropbox. De esta forma, fuera donde fuera, con descargar un eclipse (o llevarlo en un USB) podía trabajar sobre mi código en cualquier parte.

Por supuesto, se pueden poner en práctica las dos ideas a la vez sin ningún problema obteniendo así los beneficios de ambas:

a) Tener a buen recaudo nuestro código y el versionado de este.

b) Tenerlos a nuestro alcance para trabajar en todo momento.

Espero que a alguno os sirva. Si alguien tiene algún método más sobre como ha resuelto el problema, que se anime a comentarlo. Nos vemos.

Fallo de seguridad en WordPress

Supongo que al igual que yo, hoy mucha gente habrá recibido un correo como el que voy a copiar a continuación. Lo pongo aquí por si hay algún despistado, o por si alguien que no se ha visto teóricamente afectado decide cambiar sus credenciales. Yo lo haría por si acaso.

Como vemos una vez tras otra, cualquiera puede caer, hoy en día, no hay nada lo suficientemente seguro.

[El texto en rojo y negrita ya explicaré más abajo que es]

Hola svoboda,

Recientemente hemos encontrado y arreglado un fallo del que nos gustaría hablarte. Las contraseñas en WordPress.com se guardan de forma extremadamente segura, de forma que ni siquiere nuestros empleados pueden ver tu contraseña – esa con al que entras en tu cuenta de WordPress.com. Sin embargo, entre julio de 2007 y abril de 2008, y entre septiembre de 2010 y julio de 2011, un fallo en uno de los sistemas que se utilizan para encontrar y corregir errores den WordPress.com accidentalmente guardó contraseñas de algunos usuarios en un formato menos seguro.

Hemos actualizado nuestros sistemas para prevenir que las contraseñas se guarden de esta forma en el futuro, para que no vuelva a ocurrir. No tenemos ninguna evidencia de que se haya utilizado esta información de forma maliciosa, pero tu cuenta está entre las afectadas por este fallo y por seguridad vamos a resetear tu contraseña.

Por favor, cambia aquí tu contraseña o copia y cola este enlace en tu navegador:

[Supuesto enlace para la modificación de la contraseña]

Si la contraseña que utilizaste cuando te registraste en WordPress.com es la utlizas en todos sitios, deberías cambiarla también. En el futuro, recuerda que es una buena práctica utilizar contraseñas diferentes y únicas para cada servicio.

Sentimos mucho el fallo. A nadie le gusta tener que crear nuevas contraseñas y queremos incluir un descuento del 15% para pediros perdón. este descuento puede utilizarse para dominios personalizados, mejoras de diseño, VideoPress o ampliación de espacio. Sólo tienes que utilizar el código que acompaña a este texto en cualquiera de las mejoras en la tienda de WordPress.com:

[Código para la promoción imagino]

Si tienes cualquier pregunta, contesta este mensaje para que nuestro equipo de Happiness te ayude.

Gracias

El equipo de WordPress.com

En principio, el correo viene de una dirección que no tiene mala pinta, pero como uno es desconfiado por naturaleza en estas cosas, de usar el enlace que viene en en correo ni hablamos. Y aunque en principio, si examinamos la cabecera del correo este no tiene mala pinta, hay un par de cosas que no me han gustado (están marcadas en rojo en el texto del correo):

1 – “ni siquiere”: Evidentemente aquí querían decir “ni siquiera”. Desconozco si es un error tipográfico o alguna diferencia lingüística entre mi español y el de otras zonas del mundo. Si es un error tipográfico, me parece un fallo bastante gordo, si es un error lingüístico, bueno, no pasa nada.

2 – “den”: Dudo mucho que este sea un fallo lingüístico. Este tipo de fallos no se deberían permitir en un comunicado “oficial”.

3 – “Copia y cola”: Este si que puede ser un error lingüístico ya que en mi zona hispanohablante se dice “copia y pega”. De nuevo, si es lingüístico no pasa nada.

4 – “este”: Tampoco me creo que esto sea un fallo lingüístico. Después de punto, siempre mayúscula.

Qué le vamos a hacer, uno es desconfiado por naturaleza.

De todas formas, me he ido a mi cuenta de WordPress y allí, en el panel de control, también aparecía un mensaje indicándote lo mismo. Así que por lo que parece el correo era verídico.

Una de las cosas que no me ha convencido tampoco, no ha nivel de veracidad, sino a nivel de usuario de su aplicación, son las fechas: 2007 y 2008. ¡Guauu! Pero bueno, si en 3 o 4 años no ha pasado nada, no le daremos más vueltas, de momento.

Nos vemos.

[ACTUALIZACIÓN - 17:43 (24h) GTM +1]

Acabo de encontrar este hilo en los foros de WordPress sobre el correo por si queréis echarle un ojo.

Kiai – Katas

No, no me vuelto loco ni nada parecido. Hoy vamos a hablar de Katas, pero no las que estáis pensando pertenecientes a algún arte marcial, sino de unas que os van a ayudar a fortalecer vuestro cerebro y vuestras habilidades como desarrollador.

Como muchos sabréis, aunque en el blog suelo escribir sobre temas enfocados a seguridad, realmente yo soy desarrollador. Estos últimos años principalmente de Java EE, aunque he pasado por unos cuantos lenguajes, pero esto, es una historia para otro día.

Pues bien, una de las cosas que obviamente hago en casa en mis ratos libres es desarrollar, ya sea algún proyecto propio, o simplemente, algún código pequeñito para solventar un problema puntual. A raíz de esto, descubrí las Katas de programación. Pero, vamos a empezar por el principio. ¿Qué es una kata? Según la Wikipedia, y estoy seguro que todo el que haya hecho artes marciales estará de acuerdo, una kata describe una serie de secuencias o movimientos preestablecidos que persiguen un fin. ¿Quién piensa que no se parece a una de las definiciones de algoritmo?

Una vez dicho todo esto, una kata de programación, no es más que un pequeño problema de programación que persigue resolver un problema en un tiempo finito de unos 30 o 40 minutos. El objetivo de estas katas es, por un lado, desarrollar nuestros propios algoritmos para resolver la kata en ese corto espacio de tiempos, y por otro lado, ver la solución que le da otra gente a ese mismo problema. Además, estas katas son independientes del lenguaje, con lo cual, cada uno puede solucionarlas en el lenguaje que mejor le parezca. Y para añadirle un poco más de emoción, se pueden implementer utilizando “Extreme Programming” por parejas.

A raíz de descubrir estas katas, he encontrado un página en Internet llamada “12 meses 12 katas”. El objetivo, como ellos dicen es:

Un mes una kata, ¡mejora tu arte y compártelo con los demás! Ese es el objetivo principal de esta iniciativa que nace de una comunidad preocupada por mejorar sus habilidades y así crear software de más calidad.

Yo he empezado recientemente con la implementación de estas, y por un lado me estoy divirtiendo mucho picando el código, y por otro, estoy aprendiendo cosillas viendo el código de los demás.

Os recomiendo que le echéis una ojeadilla si os gusta programar y tenéis poco tiempo para hacerlo.

Bueno, como siempre, si tenéis dudas, sugerencias y/o conocéis alguna otra página de katas, estaría bien debatirlo. Nos vemos.