Lo que sigue es la traducción del post http://blog.brodzinski.com/2010/08/suck-as-project-manager.html (Para que lo usen o lo muestren a los managers de proyectos a los que les dan deseos de agarrar por el cuello a veces, ¿o debo decir siempre?).

—

Recientemente, respondí una serie de preguntas acerca de los managers de proyectos en una organización que conozco. Una de las preguntas fue acerca de la poca importancia que cumple el role de los managers de proyectos allí. Luego de pensarlo se me ocurrió que son “Guardianes de los procedimientos”.

Lo veo bastante a menudo – Las personas que se preocupan más de hacer el trabajo según los procedimientos que de hacerlo bien hecho. Si la persona que te viene a la mente es un PM, quien ve el proyecto como una combinación de presupuestos y cartas gantts en vez de personas entonces ya saben a que personalidad me refiero.

La verdad cualquier procedimiento, no solo los relacionados a gerencia de proyectos sino también a desarrollo de software, requieren un esfuerzo significativo. Se necesita una política que asegure una práctica de cumplirlos hasta que la gente se acostumbre. Y si la gente no le ve valor a un procedimiento en específico no lo van a usar nunca. Esta es la razón básica por la que medir el tiempo en desarrollo de software siempre requiere algún tipo de política hasta conseguir que los desarrolladores lo hagan.

Mientras más procedimientos, más tiempo gastado en mantenerlos y menos tiempo gastado en hacer el trabajo real. Ustedes saben, aquel trabajo que realmente importa y que impulsa el proyecto hacia adelante.

Esto es algo que siempre me ha fascinado – ¿Como esos guardianes de los procedimientos encuentran tiempo para preocuparse por cada detalle del template del documento? – ¿Que ven en gastar 1 hora discutiendo un cambio de 5 horas en la estimación de la gantt en una sala con 12 personas más?. Y solo porque este cambio va a hacer que el proyecto se salga del presupuesto. ¿Por qué pelear acerca del calendario inicial es tan importante, a pesar que el alcance del proyecto cambió de manera significativa en el entretiempo?. Y tres veces.

Entonces sí, si lo que tú quieres realmente es joder como manager de proyectos, esta es definitivamente la forma de hacerlo. Debes comenzar a pensar rápidamente acerca de nuevos bellos procedimientos que hagan la vida de los demás más miserables. Después de todo, esa es la forma en que tu vas a demostrar tu poder.

—

Revisión: Leo Soto.

Depurar, a través de Eclipse, aplicaciones web java es de gran utilidad. Permite visualizar valores de variables en tiempo de ejecución, además de poder trazar exactamente las partes de código por donde corre la aplicación. Para que funcione, Eclipse debe ser el encargado de correr el servidor de aplicaciones que usemos.

Pero que sucede cuando no nos es posible integrar el servidor dentro del IDE, ya sea por que el servidor se encuentre en una máquina distinta a la nuestra o simplemente por que no quieras que Eclipse gestione el servidor.
Para lograr depurar en estos casos, se usa el “Remote debugging” o mejor conocida como depuración remota en estos lados del planeta.

Primero que nada, debemos configurar nuestro servidor para habilitar la depuración remota. La magia de esta opción recae en las siguientes líneas:

-Xdebug
-Xrunjdwp:transport=dt_socket,address=8000,server=y,suspend=n

Lo escrito en address=8000 corresponde al puerto de conexión a usar para depurar, en este caso es el puerto 8000.
Ahora, donde agregar estas líneas, depende de cual sea tu servidor de aplicaciones y de que manera lo inicies. Para este caso detallare como configurar Tomcat y Jetty, los que tienen distintas maneras de configurar, pero al fin y al cabo siempre cumplen el mismo propósito.

Tomcat

Se puede cambiar el script de ejecución de tomcat ubicado en:

$CATALINA_HOME/bin/catalina.sh (en linux)
$CATALINA_HOME/bin/catalina.bat (en windows)

Luego en este archivo debemos buscar la variable JAVA_OPTS (o crearla en caso de no existir) y agregar la configuración mencionada anteriormente, de tal manera que quede en una sola línea:

En linux

JAVA_OPTS="$JAVA_OPTS "-Xdebug" "-Xrunjdwp:transport=dt_socket,address=8000,server=y,suspend=n

En windows

set JAVA_OPTS=%JAVA_OPTS% -Xdebug -Xrunjdwp:transport=dt_socket,address=8000,server=y,suspend=n

“$JAVA_OPTS ” y %JAVA_OPTS% sirven únicamente para conservar otras opciones de java que se hayan agregado con anterioridad, así no reemplazarlas con nuestros cambios.

Existe un par de opciones extras para windows (si, a veces lamentablemente debes lidiar con el tío Bill). Una de ellas es agregar las opciones a través de la pantalla de propiedades del monitor de tomcat (Esto funciona independiente que tengas o no corriendo tu tomcat como un servicio de windows).

Aquí se debe poner suma atención a los espacios que puedas poner al fin de cada línea, esta configuración es susceptible a espacios y si encuentra uno demás, no tomará esas opciones como válidas. Para evitarte problemas, copia y pega el código del inicio.

La segunda opción es ir a configurar estos parámetros directamente en el registro de windows, en la ruta:

HKEY_LOCAL_MACHINE\SOFTWARE\Apache Software Foundation\Procrun 2.0\Tomcat6\Parameters\Java (Para tomcat 5 es igual, solo cambiar “Tomcat6″ por “Tomcat5″ en ruta del registro)

Luego entras a modificar la clave “Options” y agregas las dichosas líneas.

Jetty

En jetty, es necesario pasar los parámetros de configuración al correr el servidor. Para mi lo más simple fue crear un script que ejecute el siguiente comando:

java -Xdebug -Xrunjdwp:transport=dt_socket,server=y,address=8125,suspend=n -jar start.jar

Ahora después de todo esto, ¿Como saber que está funcionando?. Simple, al iniciar nuestro servidor de aplicaciones, dependiendo de cual hayas configurado, saldrá algo como lo siguiente:

Tomcat en windows

Jetty en linux

Si te fijas, en la primera línea sale Listening for transport dt_socket at address: XXXX. Acá indicará cual puerto configuraste para depurar. Si te sale esto, felicidades, has completado la primera parte.

Eclipse

Luego por el lado de Eclipse, debemos configurarlo para que pueda conectarse al servidor de aplicaciones. Para esto vamos al ícono de Debug (el del bicho verde) y abrimos la ventana de depuración

En esta ventana debemos crear una nueva configuración del tipo “Remote Java Application”, donde los campos importantes a ingresar son:

• El proyecto a depurar (obviamente donde se encuentre el código fuente)
• Host o dirección ip de la máquina donde corre el servidor
• Puerto configurado para depurar

Finalmente presionamos “Debug” para realizar la conexión al servidor. Si todo resultó como se esperaba, en la vista “Debug” de Eclipse, deberá aparecer la conexión ya establecida.

Terminado esto, ya puedes comenzar a poner breakpoints y depurar tu aplicación.

Lamentablemente hasta la fecha aún no existe un acuerdo entre los diferentes navegadores para aceptar el border-radius (uno de los estilos CSS3 más populares) con la misma sintaxis. Entonces cuando queremos usarlo para nuestras páginas tenemos que escribir al menos 3 líneas en nuestro CSS o más dependiendo si queremos solo algunas esquinas redondeadas y otras no. Es por ello que en este sitio http://border-radius.com/ nos facilitan la vida escribiendo el código por nosotros. Sólo basta poner los pixeles queremos en cada borde y esta aplicación Javascript nos genera el estilo que necesitamos, así evitamos errores y ganamos tiempo.