NoSQL y varias alternativas a las bases de datos

Hace un tiempo cubrimos la inauguración de la comunidad NoSQL, un movimiento para pensar alternativas a las bases de datos relacionales que tan acostumbrados nos tienen. En este artículo, Debasish Ghosh reflexiona sobre el futuro del movimiento y las diferentes alternativas que tenemos hoy en día.

Hoy en día somos testigos de muchas noticias alrededor de NoSQL. Llámese NoSQL (~SQL) o NOSQL (Not Only SQL - No solo SQL), el movimiento tiene una misión. No todas las aplicaciones necesitan almacenar y procesar datos de la misma manera, y por lo tanto la arquitectura de almacenamiento debería pensarse de forma acorde. Hasta hoy estuvimos forzados a usar el mismo martillo para pegarle a todos los clavos. Sin importar cómo procesáramos los datos de nuestra aplicación, los solemos almacenar como filas y columnas en bases de datos relacionales.

Cuando estamos tratando con grandes aplicaciones de escritura escalables, las bases relacionales apestan. La normalización de datos, los joins, y las transacciones ACID son anti-patrones para la escritura escalable. Quizás piensen que el sharding solucione los problemas, dividiendo los datos en porciones más pequeñas. En realidad, el mayor problema del sharding es que las bases de datos relacionales nunca fueron diseñadas para eso. El sharding quita muchos de los beneficios de las bases relacionales. El sharding no puede ser "algo para pensar después", ya que se entromete en la lógica del negocio de la aplicación, y hacer joins de múltiples shards puede resultar un esfuerzo no trivial. Mientras podamos escalar de forma vertical nuestro modelo de datos aumentando la capacidad del hardware, seguramente sea la opción más sana para adoptar. Pero según Moore... incluso aunque podamos escalar verticalmente, traten de migrar una base MySQL realmente grande. Les va a llevar horas, quizás días. Este es uno de los motivos por los cuales algunas empresas están migrando a bases de datos sin esquemas, cuando las aplicaciones así lo permiten.

Y si para escalar horizontalmente sacrificamos la normalización, los joins y las transacciones ACID, ¿por qué usar motores de bases de datos relacionales? No se necesitan... Digg está migrando de MySQL hacia Cassandra. Todo depende de la aplicación y del tipo de escalabilidad de escrituras que necesitemos lograr para procesar los datos. Para escalar la lectura, podemos usar esclavos de sólo-lectura que replican todo lo que llega a la base de datos maestra en tiempo real, y configurar un proxy inteligente entre los clientes y la base de datos.

El mayor entusiasmo que creó el movimiento NoSQL es por los enfoques divergentes que prometen cada uno de sus productos. Y esto es muy diferente al movimiento de motores de bases de datos relacionales, que comenzó como un único martillo llamado SQL que es capaz de manipular filas y columnas de tipos de datos sobre la teoría matemática de un conjunto de operaciones. Y cada aplicación adoptó la misma arquitectura de almacenamiento sin portar de cómo procesara los datos dentro de la aplicación. Una cosa llevó a la otra, las personas creyeron poder resolver el problema con otra capa de indirección... y así apareció esa cosa extraña llamada Mapeador Objeto-Relacional (ORM).

Finalmente, con el boom del procesamiento de datos en la Web, nos dimos cuenta que no todos los datos se procesan igual. El almacenamiento que funcionó tan bien para las aplicaciones de escritorio tradicionales, fracasa estrepitosamente con las aplicaciones sociales donde se necesitan procesar datos enlazados, que tienen la forma de grafos. La comunidad NoSQL respondió con Neo4J, una base de datos de grafos que brinda almacenamiento sencillo y recorrido de estructuras de grafos.

Si quieren escalar a lo grande la escritura, la única forma es la descentralización y la consistencia eventual. Aparece el teorema de CAP, en donde necesitamos comprometer la consistencia, la disponibilidad o la tolerancia a la partición de la red (elijan uno). Riak y Cassandra ofrecen almacenamiento descentralizado de datos que pueden escalar indefinidamente en la teoría. Si tu aplicación necesita más estructura que una base de datos clave-valor, pueden optar por Cassandra, el sistema de almacenamiento orientado a columnas, distribuido y peer-to-peer. Pueden mirar este artículo de Digg donde se compara su casos de uso entre el almacenamiento relacional y el almacenamiento por columnas que ofrece Cassandra. Si quieren una base de datos orientada a documentos con todos los beneficios de REST y JSON, prueben Riak. Riak también ofrece Map/Reduce enlazado con la opción de almacenar elementos enlazados de datos, muy parecido a la forma en que funciona la web. Riak realmente es un sistema de almacenamiento con la forma de la web.

CouchDB ofrece otra interesante propuesta para el ecosistema de NoSQL. La mayoría de las aplicaciones son básicamente offline y necesitan facilidades de replicación transparentes. CouchDB usa una estructura de almacenamiento de Árbol-B, operaciones de sólo agregado con un control de concurrencia basado en el modelo MVCC, operaciones sin bloqueos, API REST y operaciones incrementales Map/Reduce. Chris Anderson, uno de los desarrolladores líderes de CouchDB, resume el valor de CouchDB en el mundo web de hoy:

Las aplicaciones CouchApps son el producto de un navegador HTML5 y una instancia CouchDB. La ventaja clave es la portabilidad, basada en la plataforma HTML5. Las características como los Web Workers y el XHR cross-domain hacen una diferencia enorme en la arquitectura de la web. La disponibilidad en todas las plataformas es clave para el futuro de la web.

Al igual que CouchDB, MongoDB también ofrece almacenamiento de documentos. No brinda soporte REST, pero se basa en un almacenamiento JSON. También tiene Map/Reduce, y ofrece un poderoso conjunto de APIs de consulta muy parecido a SQL. Este es un punto clave de MongoDB, que le resulta muy cómodo a personas que tienen conocimientos de SQL. MongoDB también ofrece replicación maestro-esclavo, y están trabajando en escalabilidad basada en autosharding y en tolerancia a fallos.

Hay varios más sistemas de almacenamientos que ofrecen soluciones a problemas de todos los días. Caché, consumidores de colas que requieren operaciones push/pop atómicas, procesamiento de flujos de actividad, log de datos, etc. Redis y Tokyo Cabinet funcionan bien para estos casos. Redis es como caché en memoria con una base de datos persistente de clave-valor. Es un único hilo, utiliza IO no-bloqueante y es súper rápido. Redis, además de ofrece almacenamiento de clave-valor, también ofrece la posibilidad de almacenar listas y colecciones con operaciones atómicas.

Otro aspecto interesante es la interoperabilidad entre los sistemas de almacenamiento. Riak, por ejemplo, ofrece la posibilidad de usar distintos backends para los datos - podríamos usar CouchDB como backend para Riak. Posiblemente también veamos un backend Cassandra para Neo4J. Sin dudas es interesante ver como estas comunidades tienen este sentido de cooperaciones para hacer que todo el ecosistema sea más útil y crezca más.

Original: DosIdeas

Reportar Errores o Escribir Puebas Unitarias

Los sistemas de gestión de errores (o "bug trackers") son cuellos de botella, y perpetúan el continuo idea y vuelta entre testers y desarrolladores, además de requerir de mucha documentación para mantenerlos.

Alberto Gutierrez comparte una interesante reflexión sobre cómo crear el mejor sistema de gestión de errores: ¡dejar de reportar errores y empezar a escribir pruebas automatizadas!

El ciclo de vida estándar de un bug es más o menos así: un tester de QA encuentra un error en la aplicación, crea un nuevo reporte de bug en el bug tracker y se lo envia al desarrollador, quien a su vez, ni bien soluciona el bug, lo envia de vuelta al tester, quien a su vez notifica al dueño del producto y luego cierra el bug.

En la teoría este proceso suena bien, pero tiene varias desventajas:

• Problemas de comunicación. A veces la descripción del bug es pobre, o el desarrollador malinterpreta el problema.
• Pruebas de regresión. El proceso requiere de idas y vueltas de código entre desarrollo y QA, lo que ocasiona problemas de versionado y duplica el esfuerzo de testing.
• No es robusto. El proceso no garantiza que el error no vuelva a aparecer en el futuro.
• Burocracia. Los sistemas de bug tracking tradicionales cambian el foco de la calidad a la burocracia.

La solución a estos problemas es bastante simple. Cuando alguien encuentra un bug, inmediatamente escribe una prueba automatizada que falla sobre el bug descubierto. Este mecanismo tiene varias ventajas:

• Desaparecen los problemas de versionado, todos trabajan en el head del código.
• Se garantiza que el bug no vuelva a aparecer sin ser detectado.
• Se elimina la ambigüedad sobre cuál es el bug exactamente.
• Se elimina burocracia.
• Consolida las actividades de desarrollo en un único lugar, el código.

Obviamente también hay desafíos a superar para cambiar a este proceso en donde no se necesita de un bug tracker:

• Se necesita un sistema de construcción automatizado. La construcción del proyecto tiene que estar corriendo todas las pruebas automatizadas, de manera que cuando se agregue una nueva prueba por un bug, la construcción falle y el equipo de desarrollo pueda decidir corregir el error en el momento, o ignorarlo por un tiempo (de esta manera sabremos que todas las pruebas ignoradas son bugs sin arreglar).
• Se necesita cooperación. Los desarrolladores y los testers tienen que trabajar juntos para crear las nuevas pruebas ni bien aparezca un bug. Se necesita tener testers con habilidades de programación.
• Se necesita disciplina. Los equipos tienen que entender que se debe crear una prueba por cada bug encontrado, sin excepción. Y cada vez que se rompe la construcción, la prioridad es solucionarlo.
• Se necesita organización. Las prueban tienen que crearse con criterio y usando alguna nomenclatura en común.

En resumen, en mi opinión el futuro de la gestión de errores es eliminar los bugs trackers tradicionales y toda la burocracia. Para lograr esto hay varios desafíos; si tienen las habilidades, las herramientas y el equipo para superar estos desafíos, podrían pensar seriamente en deshacerse del viejo sistema de gestión de errores.

Fuente: DosIdeas

10 motivos para amar el test ágil

Recientemente, Kay Johansen hizo la pregunta "¿Por qué te gusta probar ágil?". Las respuestas varian desde desde las más serias a las más relajadas.

• Tener la oportunidad realmente de impactar en la calidad y no sólo documentarla! (Juan Overbaugh) - cuando los defectos son corregidos de inmediato en lugar de ponerlos en una pila de defectos.

• No más pruebas manuales de los scripts! En cambio, los scripts serán ejecutados automáticamente, proporcionando más tiempo para que el tester realice las pruebas de exploración.
• Los desarrolladores realmente gustan de esto! - Localizar los problemas antes de la final de la interacción cuando el código está fresco en la mente de los desarrolladores, les ayuda a encontrar el problema.
• Ahora puede comprobar los recursos antes de que sean escritos! (Kay y Philip) - El tester puede evitar problemas al iniciar la prueba antes que los recursos se definan.
• Los resultados de las pruebas automatizadas se pueden ver muchas veces al día, proporcionando una rápida retroalimentación después de cualquier cambio.
• El ambiente está muy orientado al equipo (Juan Overbaugh) - Cada miembro del equipo se preocupa de terminar las pruebas y no sólo el código (Lisa Crispin).
• El tester puede ocasionalmente ajustar el defecto (Lisa Crispin) - Cada miembro del equipo se siente más cómodo ya que la prueba está automatizada.
• Ofrece la oportunidad de revisar constantemente las prácticas de pruebas (Adam Knight) - En lugar de simplemente repetir lo que se ha hecho anteriormente, las prácticas son constante revisadas. En el caso de Adam las pruebas que acostumbraban tomar 5 días para ejecutarse manualmente se han reducido ahora a 30 minutos.
• He pasado mucho menos tiempo en depuración (Adrian Howard) - tengo el feedback prácticamente al mismo tiempo que se ha cometido un error, por lo tanto, suele ser trivial localizar y corregir.
• Siempre existe tiempo para probar porque la prueba se realiza primero - Josué Barbosa dos Santos contó la historia de trabajar en una oficina del gobierno en Brasil, donde la práctica era probar al final del proyecto. El desarrollo siempre estaba atrasado en el calendario del proyecto y terminaba siendo liberado a los usuarios sin pruebas. Con la introducción de TDD y ATDD las pruebas se ejecutaban mientras que el software era desarrollado.

El número uno para Kay de los motivos de amar la prueba ágil: es que puedo escuchar gente diciendo "este es el mejor proyecto que he trabajado en mi vida!"

Fuente: DosIdeas

5 consejos para construir software sin defectos

Lamentablemente, en algunas organizaciones todavía se considera al testing como la última etapa del proceso de desarrollo. Los desarrolladores entonces cruzan los dedos para programar todo lo más perfecto posible, de manera que la etapa de testing sea una formalidad donde a lo sumo se encuentren errores menores. Por suerte ya hace un tiempo que nos estamos alejando de esta utopía ridícula y vamos avanzando hacia un concepto en donde el testing es una parte integrada al proceso de desarrollo.

El artículo How to write good tests nos deja 5 consejos para aprovechar al máximo este nuevo enfoque.

1. El código de test es tan importante como el código productivo. Uno de los problemas más comunes al empezar con TDD es que el código de test no es limpio ni tan prolijo como el productivo, de manera que eventualmente cuesta mucho mantenerlo. Para evitar este escenario es importante que el código de test sea tan prolijo como el productivo.
2. Probar lo más posible, lo antes posible, lo más seguido posible. Es importante no avanzar en el código productivo hasta tener una prueba que verifique que el código escrito funcione como esperamos. Este enfoque logrará que nuestro sistema tenga menos defectos, y además nos dará mayor seguridad a futuro para implementar cambios.
3. Probar en distintos niveles. No hay que ahogarnos con pruebas de integración que son muy dificil de escribir y lentas para ejecutar (y que, de última, no llegan a cubrir todos los elementos de la aplicación). El mejor enfoque es usar pruebas en distintos niveles. Por ejemplo:
   
   • Pruebas unitarias, que comprueban los componentes de forma aislada al resto.
   • Pruebas de aceptación, que son creadas por el Dueño del Producto y representan la funcionalidad mínima que tiene que tener la aplicación para poder aceptarse desde la perspectiva del negocio.
   • Pruebas de integración, que no son identificadas por el Dueño del Producto pero las desarrolla QA o el equipo de desarrollo como complemento.
   • Pruebas de interfaz de usuario. Son lentas y además cambian mucho, por lo que hay que mantenerlas separadas del resto de las pruebas.
4. Integración continua. Las pruebas tienen que ser una parte fundamental e integral del proceso de desarrollo, que ocurren en cada instante del proceso. Todos son responsables por las pruebas, desde el desarrollador hasta QA y el Dueño del Producto. Las herramientas de integración continua nos ayudan enormemente a llevar adelante este desafio.
5. Usar herramientas y frameworks de testing. No hay que reinventar la rueda, ni trabajar como en la edad de piedra. Tenemos muchas herramientas y frameworks de software libre que nos permiten implementar una estrategia seria de testing.
   
   • Fitnesse, una herramienta para crear pruebas de aceptación, de forma que personas no-técnicas puedan escribir sus propios escenarios.
   • xUnit, un framework para desarrollar pruebas unitarias, que se integra con todos los IDE de desarrollo en distintos lenguajes de programación.
   • Bugzilla, una herramienta para reportar bugs y hacer su seguimiento.
   • Selenium, una herramienta para crear pruebas automatizadas de interfaces de usuario web.
   • Hudson, una herramienta de integración continua que se usa para asegurar que el código siempre esté funcionando correctamente y pase todas las pruebas.

Fuente: DosIdeas

Novedades que tendrá el compilador en el JDK 7

Joseph Darcy nos cuenta las novedades que tendrá el compilador en el JDK 7. En general son cambios menores debatidos en los foros, que incluyen varias comodidades en la sintaxis del lenguaje.

Las novedades del JDK 7 serán:

• Switch con objetos de tipo String
• Gestión automática de recursos
• Mejoras en la inferencia de tipos para la creación de Generics
• Invocación de métodos con varargs simplificada
• Mejoras en los literales numéricos
• Soporte en el lenguaje para Collections
• Soporte en el lenguaje para JSR 292

Veamos en detalle estas características.

Switch con objetos de tipo String

Será posible utilizar el operador switch con objetos de tipo String. De esta manera se evitan los potenciales "if-then-else". Entonces, esta nueva funcionalidad nos permitiría:

String s = ...
switch(s) {
case "quux":
   procesarQuux(s);
   // y seguir...

 case "foo":
 case "bar":
   procesarFooBar(s);
   break;

 case "Gaz":
    procesarGaz(s);
   // y seguir...

 default:
   procesarPredeterminado(s);
   break;
}
 

Gestión automática de recursos

Un "recurso" es un objeto que tiene que cerrarse manualmente, como ser java.io.InputStream, OutputStream, Reader, Writer, Formatter;
java.nio.Channel;java.net.socket; java.sql.Connection, Statement, ResultSet entre otros. Estos recursos se suelen abrir en un bloque try y cerrar en un finally.

La gestión automática de rcursos es una forma especial del operador try en donde se declaran uno o más recursos. El alcance de estos recursos está limitado al bloque. Cuando el bloque termina, sea de forma normal o abrupta, todos los recursos declarados se cierran automáticamente.

La principal ventaja es que se elimina la necesidad del cierre manual, y los posibles errores que eso provoca. Además, se "evita" la segunda excepción (la del close()), dejando siempre la excepción del bloque que suele ser más interesante.

Un ejemplo de uso sería:

static String readFirstLineFromFile2(String path) throws IOException {

       try (BufferedReader br = new BufferedReader(new FileReader(path)) {

          return br.readLine();

       }
}

 

Como vemos, el bloque try() declara un recurso, el luego es utilizado dentro del bloque. Al finalizar, se cerrará automáticamente. También es posible declarar más de un recurso:

try (InputStream in = new FileInputStream(src);
    OutputStream out = new FileOutputStream(dest)) {

           byte[] buf = new byte[8192];
           int n;
           while ((n = in.read(buf)) >= 0)
               out.write(buf, 0, n);
}
 

Mejoras en la inferencia de tipos para la creación de Generics

Se incluirá la posiblidad de inferir los tipos para la creación de instancias usando Generics. En los casos que los tipos parametrizados sean obvios según el contexto, esta parametrización puede omitirse en el constructor y reemplazarse por un conjunto vacio: <>.

Por ejemplo, la siguiente línea:

     Map> anagrams = new HashMap>();

puede ser reemplazada por:

     Map anagrams = new HashMap<>();

Mejoras en los literales numéricos

Así como podemos declarar literales numéricos decimales, octales y hexadecimales, ahora también podremos declarar literales binarios. Esto resulta muy útil en ciertos ámbitos. Para esto se utiliza el prefijo 0b, el cual además es el mismo que usan los compiladores C/C++, Ruby y Python. Por ejemplo:

// Un literal 'byte' de 8-bits
byte aByte = (byte)0b00100001;

// Un literal 'short' de 16-bits
short aShort = (short)0b1010000101000101;

// Varios literales 'int' de 32-bit 'int'
int anInt1 = 0b10100001010001011010000101000101;
int anInt2 = 0b101;

Estas variables luego se usan normalmente; por ejemplo:

class Foo {
public static void main(String[] args) {
   System.out.println("El valor decimal de 10100001 es " + 0b10100001);
}
 

Por otro lado, se agregó la posiblidad de usar un guión bajo (_) como separador de números, para facilitar la lectura de los mismos. De esta manera, el compilador ignorará al caracter "_" cuando sea utilizado en literales numéricos. Por ejemplo:

int numeroDeTelefono = 555_555_1212;
long tarjetaDeCredito = 1234_5678_9012_3456L;
long legajo = 999_99_9999L;
float cantidadDeDinero = 12_345_132.12;
long hexBytes = 0xFF_EC_DE_5E;
long hexWords = 0xFFEC_DE5E;
long maxLong = 0x7fff_ffff_ffff_ffffL;
long bytes = 0b11010010_01101001_10010100_10010010;
 

Soporte en el lenguaje para Collections

Se agrega el soporte al lenguaje para tratar a las Collection como si fueran Arrays.

Por ejemplo, se podrá escribir lo siguiente para declarar un List inmutable:

final List piDigits = [3, 1, 4, 1, 5, 9, 2, 6, 5, 3, 5, 9];

También será posible acceder a las listas y maps usando una sintaxis de arrays:

public class Main {
 public static void main(String[] arguments) {
   List lista = Arrays.asList(new String[] {"a", "b", "c"});
   String primerElemento = lista[0]

   Map m1 = new HashMap(4);
   m1[Integer.valueOf(1)] = "One";
}

Soporte en el lenguaje para JSR 292

Este cambio de bajo nivel realizará modificaciones menores en el lenguaje Java para que se más simple trabajar con algunas características de la JVM. Esto va a permitir que el código Java pueda interoperar y/o implementar librerías en otros lenguajes. Es decir, se logrará una mayor integración entre Java y código en otros lenguajes. Para ver más detalles leer la propuesta del soporte para JSR 292.

Fuente: DosIdeas

Plone: un sistema ágil y potente para de gestión de contenido

por Leonardo Caballero — Contribuciones: dukebody

Fácil de empezar

Baterías incluidas

Soporta Linux, Windows, Mac OS X, FreeBSD, Solaris. Los programas de instalación le permiten ponerlo en marcha en sólo unos minutos. No requiere procesos de configuración complejos.

Habla su idioma

Disponible en más de 35 idiomas, Plone fue diseñado desde el inicio para gestionar contenido multilingüe. Incluye chino, japonés, e incluso idiomas con escritura de derecha a izquierda, como el árabe o el hebreo, de forma fácil.

El niño más bueno de la clase

El equipo de Plone incluye expertos líderes en usabilidad que han hecho que trabajar con Plone sea fácil y productivo.

A todo el mundo le gusta Plone

"Plone fue el ganador del premio del laboratorio de eWeek. Este producto de código abierto es de una de las mejores soluciones para los portales e intranets de empresas".

— eWeek, Número Abril de 2006

Amigable al usuario

No estorba y le deja escribir

Plone incluye un potente editor gráfico de texto que permite dar formato al texto e insertar imágenes y enlaces. Si está acostumbrado a trabajar con programas de ofimática, se sentirá cómodo con él.

Buscador de texto completo al instante

Todo el contenido está disponible inmediatamente para realizar búsquedas, incluso documentos Word y ficheros PDF. El sistema de búsqueda en vivo (LiveSearch) muestra los resultados a medida que se teclea la palabra o frase. Pruébelo en la casilla de búsqueda en este sitio.

Escalado de imágenes automático

Al subir una imagen, automáticamente se redimensiona a varios tamaños, lista para utilizarla en sus contenidos. No es necesario Photoshop.

Obtenga la mejor apariencia

Es fácil cambiar el aspecto de Plone. Simplemente puede integrarse con su imagen actual, o le permite crear un nuevo estilo totalmente propio.

Potente

Potente motor de flujo de trabajos (workflow)

Haga que los procesos de su negocio formen parte del flujo de trabajo del documento — complementado por una gestión de la seguridad a prueba de errores.

Velocidad y escalabilidad

Plone cuenta de serie con capacidad de realizar clústers e integrarse inteligentemente con proxys de caché. inteligente de caché proxy.

Seguridad y flexibilidad

Un modelo de seguridad sofisticado, basado en roles, da seguridad a sus contenidos. La arquitectura sandbox de Plone asegura que, incluso si su sistema estuviera comprometido, los intrusos no tendrán acceso a su servidor o a su red.

Sindicación y agregación

Carpetas inteligentes y actualizaciones inteligentes. Plone produce automáticamente noticias RSS desde carpetas, resultados de búsqueda y más — la manera ideal de permanecer en la cima de la explosión de la información y personalizar la entrega de información.

Compatible con los estándares

Accesibilidad

Reúne o supera los estándares de accesibilidad de la Sección 508 del Gobierno de los Estados Unidos y WAI-AA de W3C para personas con alguna discapacidad motora o con dificultad de lectura. Todo el uso de Javascript tiene un modo alternativo que funciona en cualquier navegador.

Excelente visibilidad en los motores de búsqueda

XHTML válido 100% y CSS mantienen una buena relación con los motores de búsqueda y los navegadores. Los sitios Plone están constantemente bien clasificados en los resultados de búsqueda en Google.

Juega bien con otros

LDAP, SQL, SOAP, Web Services (WSDL) y WebDAV — Plone trabaja con todos ellos.

Autenticación basada en agregados

Fácil integración con LDAP, Active Directory y bases de datos SQL. Diga un nombre y seguro que Plone puede dialogar con él.

Asistencia

Asistencia mundial

Si usa la documentación online, listas de correo y chats — u otros servicios de los cientos de empresas de todo el mundo que dan soporte Plone — nunca estará solo.

Código abierto, estándares abiertos

Plone está disponible bajo la misma licencia de código abierto que Linux, y usa el lenguaje de programación Python y el servidor de aplicaciones Zope, ambos también de código abierto. Esto evita dependencia del vendedor, costes de licencias, y le da un futuro previsible — y la libertad de innovar.

Extensa documentación, en prensa y online

Actualmente, hay cinco libros sobre Plone publicados, que ha sido traducidos al alemán, japonés y algunos otros idiomas.

Innovador y extensible

Hay disponibles cientos de productos adicionales — foros, gestores de incidencias, blogs y herramientas de colaboración.

Maduro

Protegido y maduro

Plone existe desde hace más de cinco años. La organización sin ánimo de lucro Plone Foundation es la propietaria y protege la propiedad intelectual y las marcas. Plone también tiene respaldo legal de los expertos del Software Freedom Law Center.

En buena compañía

Organizaciones diversas como NASA, Oxfam, eBay, Trolltech, Nokia, Utah State University, la CIA y Novell utilizan Plone para la gestión de contenidos. Nos encantaría daros la bienvenida a la comunidad Plone.

Plone es su arma secreta

Tanto si se usa para la intranet de una empresa como para un sitio web de una comunidad, Plone cumple.

Fuente

• Plone: un sistema ágil y potente para de gestión de contenido
  

Escrito con el Navegador Flock

Tags: zope, plone, python, cms, español

Gestión de alcance en Scrum

La adopción de prácticas ágiles para el desarrollo de software requieren muchos cambios en la organización, tanto a nivel cultural, de roles individuales y procesos. A medida que la organización va migrando hacia Ágil, las personas deberán poder gestionar este cambio.

En este artículo veremos los cambios esperados en los diferentes roles para una organización Ágil, junto con técnicas para manejar mejor la transición desde una Cascada tradicional hacia metodologías Ágiles.

Introducción

El enfoque Ágil se basa en objetivos de proyecto a corto plazo. A diferencia del modelo en Cascada, en Ágil se producen piezas funcionales de software cada 2-4 semanas. Este sistema asegura la motivación del equipo y la satisfacción del cliente, con ciclos frecuentes de inspección y adaptación. Ágil tiene la habilidad de repensar las posiciones de las personas y crear un ambiente en donde logren la máxima eficiencia y el máximo potencial individual, logrando así una estrategia de desarrollo de software en la cual se justifican los cambios asociados con sus resultados: Ágil es un enfoque económico y orientado a los resultados para el desarrollo de software.

Adoptar Ágil requiere de cambios considerables en la organización en la cultura corporativa, en los roles y en los procesos. A medida que una organización va migrando a Ágil se hará necesario poder manejar los cambios. En este artículo cubriremos los cambios que ocurrirán en los siguientes roles de la organización:

1. Cliente
2. Gerente de Producto
3. Gerente General
4. Gerente de Proyecto
5. Desarrolladores
6. QA

Es importante notar que no toda la información siguiente aplica a cualquier organización, ya que cada equipo trabaja distinto y tiene diferentes capacidades.

Cliente

Con los proyectos tradicionales en Cascada, los cliente usualmente se mantenían a distancia y sólo se involucraban al principio y al final de un proyecto. Nueve de cada diez veces, el equipo de desarrollo intentaba que el cliente fuera sincero y directo. Le dejábamos en claro que cualquier cambio luego del inicio del proyecto requiere un proceso de control de cambios y penalidades. Después de terminar la codificación, que podía ocurrir varios meses después del inicio del proyecto, entregamos el código para descubrir "lo que salió mal". No es necesario decir que este enfoque es una receta para el desastre.

En los proyectos Ágiles, el cliente necesita estar mucho más involucrado en todo el proceso de desarrollo. De hecho, los proyectos Ágiles esperan el cambio, y siempre es bienvenido el feedback del cliente.

1. Los clientes tienen que participar y brindar feedback en todos los puntos de "inspección y adaptación". Esto minimiza el riesgo y le brinda más opciones al cliente y a los interesados. Nota: en los proyectos XP, es obligatorio que el Cliente forme parte del equipo.
2. Los clientes tienen que trabajar con el Dueño del Producto para definir historias de usuario y detallar dichas historias durante las reuniones de planificación.
3. Los clientes trabajan con el Dueño del Producto para priorizar el backlog.
4. Los clientes y los interesados participan en las demos de los sprint y, dependiendo en la relación entre el cliente y el Dueño del Producto, el Cliente puede participar en la retrospectiva del sprint.

Gerente del Producto

Los Gerentes de Producto también tienen cambios. Para empezar, el título cambio de "Gerente del Producto" a "Dueño del Producto". Pero eso no es todo. En un entorno tradicional, los Gerentes de Producto son la "entrada" y "salida" . Además de sus tareas de marketing específicas, los Gerentes de Producto suelen ser responsables por el Documento de Requerimientos del Producto. Por otro lado, los Dueños de Producto son la voz del cliente. Migrar de un Gerente de Producto a un Dueño del Producto en proyectos Ágiles requiere los siguientes cambios en tareas y responsabilidades:

1. El Dueño del Producto es un participantes activo del equipo. Son los responsables por la dirección del producto y las prioridades del proyecto.
2. El Dueño del Producto debe estar presente en la planificación del Sprint. El Dueño del Producto tiene la primer parte de la reunión de planificación, y es responsable de definir los objetivos del Sprint y también detallar la funcionalidad de cada historia de usuario planificada para ese Sprint.
3. El Dueño del Producto es responsable de crear, mantener y priorizar el backlog del producto.
4. El Dueño del Producto tiene que estar disponible para el equipo en todo momento. Se puede debatir si el Dueño del Producto está presente en todas las reuniones diarias, pero mientras más involucrado esté el Dueño del Producto, habrá más probabilidades de éxito.
5. El Dueño del Producto también es responsable en parte por definir el criterio de pruebas de aceptación y, en este aspecto, es también responsable por la calidad del producto - especialmente porque este criterio de pruebas de aceptación le permite al equipo de desarrollo construir con calidad desde el principio.

Por lo tanto, como Dueño del Producto, hay que estar preparado para estar más involucrado en el día-a-día y ensuciarse las manos.

Gerente General

Como los equipos Ágiles son auto-gestionados, ¿en dónde queda el gerente general, y cuál es su rol?

1. Los gerentes tienen que estar disponibles para actuar como apoyo al equipo, especialmente si el Gerente tiene la experiencia apropiada - no hay igual para su experiencia. Es por esto que Toyota usa al Jefe de Ingenieros como su Dueño del Producto. Este apoyo puede hacer que los equipos eviten errores y por lo tanto ahorren tiempo.
2. Los gerentes tienen que estar presentes para ayudar con las tareas difíciles. Por ejemplo, tienen que asistir al Scrum Master a eliminar GRANDES impedimentos que requieren que la gerencia se involucre (como ser, aprobar un presupuesto para seguir avanzando).
3. Especialmente los equipos nuevos necesitan apoyo y dirección de la gerente para que el proceso Ágil pueda avanzar en la organización. Los gerentes tienen que estar con el equipo para mantener el rumbo hacia Ágil. Es muy facil que los equipos vuelvan a los viejos hábitos.
4. Los gerentes tienen que actuar como "coach", asistiendo a los miembros del equipo con su plan de carrera, revisiones de rendimiento, capacitaciones y organización de capacitaciones.
5. Los gerentes deben enfocarse en iniciativas estratégicas de largo plazo para la organización (cómo gestionar amenazas competitivas, incrementar las ventas, reducir costos, etc.)
6. Basándose en estas iniciativas estratégicas, los gerentes tienen que trabajar de cerca con el Dueño del Producto para definir y priorizar las historias "Épicas" y crear mapas de ruta de proyecto a largo plazo.

Gerente de Proyecto

Scrum directamente se quita de encima el rol tradicional de "Gerente del Proyecto". Entonces, ¿a dónde van estos empleados? Lo más frecuente y natural es que los Gerentes de Proyecto hagan una transición hacia Scrum Masters. Sin embargo, muchos buenos Scrum Masters provienen de Desarrollo y QA. Créanme, el rol del Scrum Master no es ni remotamente parecido al del Gerente de Proyecto. Por lo tanto, es importante que el candidato a Scrum Master adquiera capacitación.

1. Para empezar, el Scrum Master tiene que aceptar el el equipo es dueño de la agenda, así que no más actualizar los viejos Gantts del MS Project. En cambio, hay que sentarse e inicialmente alentar al equipo para que mantenga actualizadas sus estimaciones diarias.
2. El Scrum Master se asegura que se siga el proceso de Scrum, que todos entienden Scrum y cómo funciona.
3. El Scrum Master debe quitar impedimentos, o asistir en quitar impedimentos, lo más rápido posible.
4. Se asegura que el equipo se mantiene en rumbo, recordandole al equipo el objetivo del Sprint en cada reunión.
5. Organiza los Scrums diarios (una reunión diaria en donde todos dicen lo que hicieron ayer, lo que van a hacer hoy qué impedimentos tienen), y se asegura que se realice en el mismo lugar a la misma hora.
6. Se asegura que todos los detalles de Scrum, y en particular los puntos de inspección y adaptación, se tomen seriamente y sean usados de la manera para la cual fueron diseñados. Esto es lo que le permite al equipo mejorar Sprint a Sprint.

Desarrolladores

A los desarrolladores les encanta hacer las cosas bien, no les gusta tomar atajos. No les gusta que los fuercen a deplegar código que saben que no es del todo bueno. El cambio más grande que un desarrollador puede esperar de un cambio hacia Ágil (Scrum + XP) es que se incrementa al máximo la disciplina técnica.

1. No se estiman más las tareas de forma individual. Esta actividad, quizás la más dificil, se hace en equipo usando, preferentemente, planificación de poker. Como resultado, obtendremos mejores estimaciones. Además, tenemos una responsabilidad compartida por una mala estimación.
2. Debemos aprender a programar en parejas. Asumiendo que se estén implementando las prácticas de XP (muy recomendable), van a estar haciendo esto muy seguido. Es un cambio mental enorme que los desarrolladores tienen que hacer porque, por primera vez, están abriendo su código para ser revisado por un par. Esto signifca ser criticado cada a paso. Al principio resulta dificil, pero los beneficios son enormes; está garantizado que uno será mejor programador. Se produce código de más calidad y más mantenible.
3. Ya no se tira código para que después los testers encuentren bugs. Ágil se basa en la premisa de salida sustentable, y para lograrlo es imperativo que la calidad se construya desde el principio. Deberá aprenderse a escribir pruebas unitarias y aprender un montón sobre TDD. Aquí es donde aparece el desafío técnico para producir el mejor código posible, con la mejor calidad. Y los beneficios son enormes.
4. Los desarrolladores participan en el proceso completo. Esto genera una nueva perspectiva de las cosas, ya que se forma parte de las historias inicial. En consecuencia, podremos escuchar problemas directamente del Cliente/Dueño del Producto, ya que están allí para dar detalles durante las reuniones de planificación del Sprint. También se participa de la retrospectiva para reflexionar sobre lo que ocurrió, lo que salió bien y mal, y así implementar mejoras sprint a sprint.
5. No hay que realizar esfuerzos desmedidos continuamente. De hecho, si seguimos Scrum, nunca debemos esforzarnos desmedidamente. La velocidad mantiene el ritmo sustentable del equipo, que gobierna cuánto trabajo en progreso hay en un momento dado. Los equipos pueden desplegar a producción cada dos semanas, sin error. Esto se logra optimizando la velocidad y el trabajo realizado. Podemos aprender un montón del pensamiento Lean y del Sistema de Producción de Toyota (TPS).
6. Si se sigue el proceso, no habrá que preocuparse por trabajar fines de semana continuamente, o código malo. En cambio, al final de cada Sprint, podremos sentirnos orgullosos de lo producido, y nunca más querremos trabajar de otra forma. Esto requiere que todos los interesados estén involucrados en este nuevo proceso desde el principio (un pre-requisito para una implementación Ágil exitosa).
7. Al finalizar cada Sprint, tenemos la oportunidad de demostrar lo que realizamos. Este es el momento de brillar (en vez de ocultar), a diferencia de proyectos en cascada donde nunca sabemos dónde puede aparecer el próximo bug.
8. Trabajamos en equipo y alcanzamos cada hito en equipo. No hay "yo", sino "nosotros". Buscamos oportunidades para ayudar a los miembros del equipo en lo que necesiten.

Testers de QA

Los proyectos en Cascada, al atrasarse, suelen recortar tiempo de QA. Este escenario cambio con las metodologías ágiles.

1. QA participa desde el inicio de cada Sprint. ¿Qué valor puede dar un tester en estas fases tempranas del proyecto? Al participar en las reuniones de planificación del sprint, vamos a informarnos sobre las historias planificadas. De hecho, QA está involucrado en elaborar las historias de usuario. Por ejemplo, ayuda a definir el criterio de pruebas de aceptación para las historias. Esto ayuda a los Desarrolladores a entender lo que se necesita para pasar las pruebas. Como resultado, se mejora la calidad del código y también la "utilidad" del código (qué tan cerca está del requerimiento del usuario).
2. Estaremos involucrados en la creación de pruebas unitarias. Este es una forma importante por la cual los testers pueden mejorar sus habilidades. Esta es un área en donde los testers pueden agregar mucho valor al proceso con su marco de pensamiento estilo "cómo puedo romper esto".
3. Deberemos automatizar la mayor cantidad de pruebas funcionales. Como resultado, contribuiremos con la efectividad general del equipo y su productividad. El pensamiento Lean sugiere que los equipos necesitan estar enfocados en construir con calidad y minimizar los desperdicios, ya que esto es lo que más afecta a los ciclos de tiempo. Entonces, al escribir pruebas automatizadas, estamos contribuyendo a la calidad general del código y como resultado reducimos el tiempo de ciclo total.
4. Seremos un miembro respetado del equipo en vez de un ciudadano de segunda que "detiene la línea de producción". Por ejemplo, cualquier bug que se encuentra incluso en etapas tempranas del producto debería resolverse ni bien se encuentra. Ágil resuelve los problemas de la gestión de proyectos tradicionales construyendo un equipo cohesivo y tratando a cada área funcional como desarrollo. De hecho, Scrum sólo hace referencia a "Desarrolladores" del proyecto (por ejemplo, si sos un tester dentro de un proyecto Scrum, sos otro Desarrollador que tiene entregables en el backlog del sprint).
5. Como los Desarrolladores escriben pruebas unitarias, no se recibirán más código con muchos errores. Ahora podemos enfocarnos en aspectos más importantes de las pruebas, como ser pruebas de frontera, y en la automatización de las pruebas.
6. Las prácticas de Scrum/XP y Lean confían en que todo el código que se entrega al final del Sprint está TERMINADO (con pruebas unitarias, funcionales, e integrado). Entonces tendremos tiempo para completar cada una de estas pruebas en cada Sprint ya que todo el trabajo (incluyendo el testing) está contando dentro de la planificación del Sprint (a diferencia de tener, por ejemplo, las últimos 3 semanas dedicadas al testing de un proyecto).

El testing maduró mucho desde las metodologías Ágiles, y ahora son miembros mucho más respestados en la industria del software. Ahora el testing es esencial para el desarrollo de buen software qeu asegure que funcione como se espera. Con conceptos como TDD y BDD, los esfuerzos de testing cambian de un enfoque tradicional "al final" del proyecto hacia un enfoque desde "el inicio" del proceso, y como resultado, se construye la calidad desde el comienzo.

Conclusión

Ágil adapta el entorno de desarrollo para sacar a relucir todo el potencial de los equipos y trasladarlo hacia ciclos de desarrollo increíblemente eficientes. También alienta la colaboración efectiva y productiva de las personas, eliminando las jerarquías corporativas en favor de equipos funcionales. Una migración a Ágil requiere un esfuerzo coordinado y el deseo de adoptar cambios a través de todos los aspectos en los equipos de desarrollo. Al principio, los cambios asociados a implementar Scrum parecen épicos. También es fácil distraerse con los aspectos técnicos del cambio, en vez de hacer foco en las bases: una reestructuración del proceso de desarrollo de software para hacerlo más eficiente.

Fuente: DosIdeas

Nuevas opciones en la web para mejorar tu trabajo

Cada día se desarrollan nuevas herramientas para facilitar el trabajo del diseñador y desarrollador web. Sin embargo, aveces el tiempo de investigación de estas herramientas es escaso y no sabemos como encontrarlas. Es por ello que este tipo de listas nunca están de más para quienes tienen deseos de aprender y facilitar su trabajo.

En otras ocasiones les he compartido útiles herramientas para diseñadores y desarrolladores web, también hemos hablado de cómo mejorar nuestro trabajo con el uso de servicios en línea y aunque muchos ya tienen sus herramientas favoritas, estoy segura que alguna de estás no las conocían.

Descubre estás 6 herramientas

Las herramientas que te presento a continuación son muy variadas, encontrarás recursos para diferentes actividades en el proceso de un desarrollo y diseño web. Pero si estás opciones no son suficientes para ti, también te invito a revisar los demás recursos que hemos investigado para ti.

• Toufee: una herramienta que facilita la creación de animación en flash, funciona como un pequeño editor de imagen, sonido y texto.
• Ajaxload.info: en este sitio encontraras una útil herramienta para generar imágenes de pre carga, realmente muy sencilla.
• Csstypeset: es una herramienta que te permite generar el código CSS de diferentes tipografías para aplicarlas a tu sitio web.
• Stripe Generator: para muchos es una herramienta útil para generar combinación de colores y diseños de fondo.
• Buttonator: tienes necesidad de crear un botón estándar con determinadas características de forma rápido, está es la herramienta que te ayudará a lograrlo.
• Dotemplate: es una herramienta que te permite construir templates de forma muy sencilla.

¿Quieres más recursos?

Para ti que siempre andas en busca de más opciones en recursos, te recomiendo los siguientes artículos que aglutinan una inmensa cantidad de recursos y herramientas para seguir aprendiendo, mejorando tu trabajo como diseñador y desarrollador web.

• Framework para Wordpress: si deseas crear tu propio theme está es una lista de 20 frameworks para que te diviertas.
• Optimiza tus imágenes: encuentra una lista de 8 herramientas para optimizar tus imágenes en la web.
• Realiza combinación de colores: nunca están de más estás opciones, ya que nos facilitan la búsqueda de colores y combinaciones, descubre las 6 opciones disponibles en línea.
• Crea tus logos: si buscas inpiración en crear un nuevo logo, conoce esta recopilación de opciones para tomar como referencia.
• 10 opciones de CMS: andas en busca de una nueva opción en CMS te comparto una lista con 10 opciones para que tomes la mejor decisión y te animes a probar algo diferente.

Hay quienes odian las listas de recursos a mi me encanta descubrirlas porque en ellas logro encontrar por lo menos una o dos opciones que me servirán en mi trabajo. Si conoces más recursos te invito a compartirlos en los comentarios o compartir las nuevas herramientas que has descubierto que han mejorado tus actividades.

Artículo Original: Maestros del Web

Jugando con PreparedStatement

Hace tiempo que he oido que los PreparedStatement de java son más eficientes que los Statement, así que me he puesto a jugar con el tema y verlo por mi mismo.

Mi primera prueba un pequeño fracaso. Cogí una base de datos MySQL e hice 1000 inserciones seguidas con Statement, componiendo la SQL y luego otras 1000 con PreparedStatement. Por igualdad de condiciones, en ambos casos partía de la base de datos vacía. Pues bien, no solo no había diferencia apreciable, sino que además en ocasiones las Statement tardaban menos.

Me puse a investigar y descubro que hay dos requisitos indispensables para que los PreparedStatement sean más efectivos:

1. El servidor de base de datos debe soportar los Prepared Statement, que realmente no son cosa de java, sino del servidor de base de datos.
2. El conector/driver que se use también debe soportarlos.

Así que a ver si mi versión de driver y de servidor MySQL lo soportan … pues sí, lo soportan. Sigo investigando y descubro que al conector de MySQL hay que decirle en la configuración que use PreparedStatement del lado del servidor, cosa que por defecto no hace. Esto se consigue poniendo en la cadena de conexión algo como

conexion = DriverManager.getConnection(
"jdbc:mysql://localhost/basedatos?useServerPrepStmts=true", "usuario", "password");

Pues nada, pruebo otra vez y esta vez sí que es ligeramente más rápido el PreparedStatement, pero no tanto. El tiempo que tarda cada vez el programa en correr es distinto y aunque el PreparedStatement suele tardar algo menos que el Statement, a veces no ocurre así. Estamos hablando de entre 15 y 18 segundos, en el que el PreparedStatement apenas le saca un segundo al Statement y no siempre.

No puede ser que eso sea así. Algo debo estar haciendo mal. Sigo leyendo y encuentro un sitio (no recuerdo cual) que dice que algunas bases de datos no mantienen los PreparedStatement después del commit. No veo nada en MySQL que indique esto, pero me decido a hacer la prueba. Hago que la conexión no sea auto-commit y pongo el commit fuera del bucle de inserción. Las mil inserciones en cada caso quedan "en el aire" hasta que se hace un commit al finalizar cada bucle.

Esta vez el PreparedStatement sigue sacando su aproximadamente un segundo sobre el Statement … pero el tiempo total se reduce drásticamente, tanto para Statement como para PreparedStatement, a unos 3 ó 4 segundos. El hecho de no hacer commit hasta el final, independientemente del tipo de Statement usado, hace que el tiempo total baje de 15 segundos a 3. Y el segundo a favor de PreparedStatement se convierte ahora sí, en algo apreciable. Seguramente, todo lo que estaba midiendo antes eran los accesos reales a disco duro para realizar realmente las inserciones de una en una con el auto-commit. En el segundo caso, la medida ya sí debe ser mejor comparativa enrtre PreparedStatement y Statement.

Pero … ¿y en una aplicación real?. ¿Podemos permitirnos el lujo de no hacer commit hasta que hayamos hecho un conjunto más o menos grandes de inserciones?. Yo creo que normalmente no, así que ¿realmente merece la pena el uso de PreparedStatement por temas de eficiencia?. Pues supongo que depende entonces de los casos.

Por ejemplo, se me ocurre que si una sola inserción es más compleja que la mia e involucra varias tablas, podemos dejar el commit para cuando se haya hecho la inserción en todas las tablas implicadas. Esto tiene cierta lógica, la inserción se completa totalmente o no se completa en absoluto y el commit confirma varias inserciones, una en cada tabla. La diferencia de velocidad entre PreparedStatement y Statement será mayor cuantas más tablas haya implicadas.

También se me ocurre, aunque sólo sea una tabla, que si tenemos garantía de que van a ir insertándose muchos registros con mucha frecuencia, como para comprometer la velocidad con la que somos capaces de insertarlos en base de datos, podemos usar PreparedStatement y un pequeño Timer que haga commit cada cierto tiempo. Una idea rebuscada, pero sí se de casos donde podemos aplicarla. A veces tenemos equipos hardware "escupiendo" información a toda velocidad, información que necesitamos almacenar en base de datos.

En resumen, PreparedStatement posiblemente sí es más eficiente, pero para sacarle realmente rendimiento, no basta con usarlo sin más. Hay que tener en cuenta más cosas, como si tenemos el auto-commit a true o con qué frecuencia necesitamos hacer los commit. Si se investiga un poco, también ser verá que hay otras variables a tener en cuenta, como temas de caché en la configuración del servidor de base de datos o del conector, pero soy demasiado vago para investigar eso sin necesidad real.

Aparte de todo esto, a favor de los PreparedStatement, también está el tema de seguridad. Con PreparedStatement evitamos tener que chequear y "escapar" los caracteres conflictivos en las cadenas de texto que vamos a insertar en base de datos. Si vamos a insertar un nombre de usuario que pedimos al usuario y a este se le ocurre poner una comilla simple, por ejemplo "O’Donnell", podemos meterla tal cual en un PreparedStatement, pero necesitamos "escapar" la comilla antes de usarla en un Statement.

Fuente

¿Qué hace a un gran desarrollador de software?

La industria del desarrollo de software cambia tanto y tan rápido que todos los días nos convertiremos en peores desarrolladores a menos que aprendamos y nos adaptemos de forma continua. Esta verdad tiene tres consecuencias principales.

1. Si no hacemo nada para evitarlo, sin importar qué tan bueno seamos desarrollando software, eventualmente nos vamos a transformar en malos desarrolladores de software.
2. Para asegurarnos que en el futuro seamos tan buenos desarrolladores de software como hoy, necesitamos aprender y adaptarnos a los cambios futuros que están directamente relacionados con nuestro entorno profesional.
3. Para ser un mejor desarrollador de software, necesitamos ir más allá del aprendizaje y la adaptación

Grandes desarrolladores de software

A partir de este escenario apocalíptico donde nada está asegurado, lo que hace a un gran desarrollador de software no es su capacidad de aprender y adaptarse sino también el poder estar un paso más adelante de quienes sólo hacen lo necesario para no quedarse obsoletos.

Aprendizaje

• El conocimiento técnico se vuelve obsoleto
• Aparecen nuevas metodologías y los procesos para desarrollar software.

Adaptación

• El desarrollo de software es un proceso que requiere de adaptación constante. Por ejemplo, vamos a trabajar con el código de otras personas. Necesitamos adaptarnos a su estilo y estructura para comprenderlo y mantenerlo.
• Los cambios ocurren continuamente durante el desarrollo de software. Requerimientos cambiantes, tecnologías...
• No siempre tenemos lo que preferimos hacer. Pero tenemos que hacerlo, así que mejor adaptarnos.

Buenos desarrolladores vs. Grandes desarrolladores

Los buenos desarrolladore de software y los grandes desarrolladores de software tienen dos cosas en común: tanto su productividad y como su calidad son altas. La principal diferencia es que los Buenos Desarrolladores de Software que no sigan aprendiendo y adaptándose van a ser un poco peor cada día, mientras que los Grandes Desarrolladores de Software seguirán mejorando.

¿Sos un Gran Desarrollador de Software?

A veces es dificil saber qué tanto estamos aprendiendo y adaptándonos. Estos son algunos indicadores que nos pueden ayudar:

• Podemos aprender rápidamente nuevas tecnologías.
• Podemos mantener código legacy.
• Somos buenos sin importar el proceso utilizado (cascada, CMM, XP, etc.)
• Podemos cambiar de lenguaje de programación facilmente.
• ...

Y el principal indicador para saber si somos un Gran Desarrollador de Software: los Grandes desarrolladores son mejores desarrolladores que el día anterior.

Fuente: DosIdeas.