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.

IEEE, el mundo de la Ingenieria

IEEE y el mundo de la Ingenieria

• Que es el IEEE

IEEE corresponde a las siglas de The Institute of Electrical and Electronics Engineers, el Instituto de Ingenieros Eléctricos y Electrónicos, una asociación técnico-profesional mundial dedicada a la estandarización, entre otras cosas. Es la mayor asociación internacional sin fines de lucro formada por profesionales de las nuevas tecnologías, como ingenieros eléctricos, ingenieros en electrónica, científicos de la computación, ingenieros en informática e ingenieros en telecomunicación.

Su creación se remonta al año 1884, contando entre sus fundadores a personalidades de la talla de Thomas Alva Edison, Alexander Graham Belly Franklin Leonard Pope. En 1963 adoptó el nombre de IEEE al fusionarse asociaciones como el AIEE (American Institute of Electrical Engineers) y el IRE (Institute of Radio Engineers).

A través de sus miembros, más de 360.000 voluntarios en 175 países, el IEEE es una autoridad líder y de máximo prestigio en las áreas técnicas derivadas de la eléctrica original: desde ingeniería computacional, tecnologías biomédica y aeroespacial, hasta las áreas de energía eléctrica, control, telecomunicaciones y electrónica de consumo, entre otras.

Según el mismo IEEE, su trabajo es promover la creatividad, el desarrollo y la integración, compartir y aplicar los avances en las tecnologías de la información, electrónica y ciencias en general para beneficio de la humanidad y de los mismos profesionales. Algunos de sus estándares son:

• VHDL
• POSIX
• IEEE 1394
• IEEE 488
• IEEE 802
• IEEE 802.11
• IEEE 754
• IEEE 830

Nota Importante : Mediante sus actividades de publicación técnica, conferencias y estándares basados en consenso, el IEEE produce más del 30% de la literatura publicada en el mundo sobre ingeniería eléctrica, en computación, telecomunicaciones y tecnología de control, organiza más de 350 grandes conferencias al año en todo el mundo, y posee cerca de 900 estándares activos, con otros 700 más bajo desarrollo.

• Donde esta presente el IEEE ?

El IEEE esta dividida por Regiones y estas son:

Region del 1 al 6: Los Estados Unidos

Region 7: Canada

Region 8: Europa y el Medio Oeste

Region 9: Latinoamerica

Regio 10: Asia y el pasifico

Cada una de estas regiones se divide por secciones por cada pais que le corresponde.

para mas informacion pincha aqui http://ewh.ieee.org/reg/9/org_secciones.html

• Quienes son sus miebros ?

El IEEE es una sociedad técnica profesional que agrupa a personas interesadas en los campos de la electrotecnología y la información en cerca de 150 países.
Todo interesado es bienvenido y puede asociarse al IEEE, asignándosele una 'Categoría' acorde con su formación y trayectoria profesional.
Las posibles categorías son:
Member: graduados universitarios en áreas técnicas afines al IEEE o quienes puedan demostrar una trayectoria profesional equivalente,
Associate: quienes no satisfacen los requisitos para Member
Senior Member: profesionales con una trayectoria destacada. Quien es Member puede postularse para pasar a Senior Member o puede ser postulado por terceros. Las postulaciones son analizadas por el Comité Admission & Advancement en sesiones que realiza a lo largo del año.
Fellow: Los profesionales más destacados a nivel mundiar en sus respectivas áreas técnicas. Deben contar con el aval de una de las Sociedades Técnicas del IEEE y ser propuestos por otros Fellows, en una convocatoria que se realiza anualmente.
Student: Quienes están cursando estudios universitarios en un área afín al IEEE durante al menos 50% de su tiempo.

• Como Asociarse ?

Para asociarse al IEEE basta llenar un formulario con datos personales y abonar los aranceles correspondientes, según que el candidato sea 'Estudiante' o 'No-Estudiante'.
En adición a la asociación al IEEE, es posible asociarse también a una o más Sociedades Técnicas del IEEE (a costo adicional).
Hay aranceles preferenciales para los Estudiantes.
Los 'No estudiantes' que califiquen para ciertas 'Circunstancias Especiales' pueden acogerse a descuentos en el arancel a pagar (50% de descuento en el caso de 'ingresos mìnimos').

• Como esta organizado segun el IEEE Belaw ?

La organización del IEEE refleja sus características técnicas y geográficas, a través de sus 'Sociedades Técnicas', 'entidades organizativas' y 'comités directivos' (Boards).

Hay cerca de 40 Sociedades Técnicas y Consejos Técnicos, relacionadas con diversas áreas temáticas, que funcionan bajo la coordinación del Technical Activities Board (TAB).

El Educational Activities Board (EAB) coordina actividades relacionadas con la enseñanza, desarrollo profesional, participación del IEEE en organizaciones de acreditacion como ABET, etc.

El Publications Board (PUB) es el encargado de coordinar la intensa actividad del IEEE en esa área, incluyendo publicaciones periódicas y aperiódicas, anales de conferencias y libros, tanto en versiones impresas tradicionales como en medios electrónicos. Una parte substancial de los ingresos del IEEE se originan en la venta de publicaciones técnicas a universidades, empresas y otros. Esto permite ofrecerlas a los socios a precios preferenciales (especialmente las revistas de las Sociedades Técnicas).

La Standards Society (evolución del antiguo Standards Board) es responsable del desarrollo de los IEEE Standards a través de sus diversos Comités Técnicos. Los IEEE Standards tienen profunda y creciente influencia en la industria y los socios del IEEE pueden ser parte de esta relevante tarea.

El Regional Activities Board (RAB) refleja los aspectos geográficos del IEEE, a través de sus 10 Regiones Geográficas que abarcan todo el mundo. Cada una cuenta con un Director Regional elegido por los miembros residentes en la misma. La Sección Argentina forma parte de la Región 9 Latinoamérica.

Por cuanto el IEEE nació en los Estados Unidos de Norteamérica, si bien es una organización global la membresía y actividades que allí se realizan aún tienen un peso significativo dentro de la organización, lo que se refleja en la existencia de IEEE-USA entre los comités directivos.

Cabe mencionar que alrededor de 1/3 de la membresía reside actualmente fuera de Estados Unidos y es creciente la participación de miembros de fuera de Estados Unidos en los diversos Comités Directivos, estimulada por la disponibilidad de comunicaciones electrónicas.

Todos los cargos directivos están cubiertos por miembros que actúan con carácter voluntario y ad-honorem.

En adición a ellos hay personal contratado para brindar soporte administrativo y gerencial, principalmente desde la Sede Central del IEEE en Piscataway, New Jersey, bajo la supervisión de un Gerente General.

La máxima autoridad del IEEE es el Presidente, elegido anualmente por voto de los miembros.
Cada uno de los 'Boards' es dirigido por un 'Vicepresidente'.

El máximo organo de conducción del IEEE es el Board or Directors (BOD), que cuenta con cerca de 30 miembros ('Directores'), e incluye al Presidente del IEEE, 10 Directores Regionales, 10 Directores Técnicos (representando las diversas Areas Técnicas del IEEE) y los Vicepresidentes de los Boards.

Los Directores deben ser Senior Member o Fellow

• Notas de Importancia
• 
  
• Cómo conseguir trabajo a través del IEEE?

Se puede conseguir trabajo por medio del servicio para miembros del IEEE llamado e-Recruiter, el cual puede ser accesado en
http://www.ieee.org/jobs

• Cómo conseguir ayuda de viajes con el IEEE?

IEEE ofrece un programa de ayuda a viajeros del IEEE, el cual puede ser consultado en http://www.ieeetravelonline.org

• Qué es ser un miembro GOLD del IEEE?

Los grupos GOLD son grupos afines, organizados para desarrollar actividades que cumplan los objetivos del Programa "Graduados de la última década" (Graduates of the last decade - GOLD). Uno de los requisitos es tener como máximo 7 años de graduado. Ser miembro GOLD da grandes ventajas, que pueden ser consultadas visitando la página web
http://www.ieee.org/gold

• Cómo mantenerte informado sobre las noticias y eventos del IEEE?

Para mantenerte informado, puedes visitar los siguientes sitios web:

IEEE Mundial
http://www.ieee.org
IEEE Latinoamérica
http://www.ieee.org/r9
IEEE Colombia
http://www.ieee.org.co

• Si ya existe una Rama Estudiantil, pero está inactiva, cómo reactivarla?

En algunos casos, la Rama Estudiantil por graduación de sus directivos por ejemplo, queda inactiva. Es decir, es una Rama Estudiantil aprobada ante IEEE en Estados Unidos, pero que no se encuentra trabajando, que no ha enviado sus informes a tiempo o que tiene menos de 10 miembros, o ha realizado menos de dos actividades en el año. Para reactivarla, pueden contactar a una Rama que esté activa y tome el papel de "Padrino" (Universidad Nacional de Colombia, Universidad Distrital Francisco José de Caldas, Universidad Industrial de Santander, Pontificia Universidad Javeriana, Universidad Santo Tomás, etc.), o también pueden contactar a la Sección Colombia, cuyo encargado en estos casos es el el Ingeniero Carlos Rueda Artunduaga, Coordinador de Actividades Estudiantiles ( calozanog@ieee.org ). La reactivación queda concluida al enviar al IEEE Estados Unidos la documentación necesaria (informes de nuevos directivos, nuevas afiliaciones, plan anual de actividades, etc.)

Para mayor información puede contactarse a la oficina de Servicios Estudiantiles del IEEE en Estados Unidos en el email
student.services@ieee.org

Para mas informacio visita www.ieee.org