—

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.

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.

REF: http://page24×7.com/reference/html-color-names-and-codes/

“Si todo eso puede hacerse en Java, porque RoR?”,

“Mi plataforma es Java, nos costó llegar a lo que tenemos hoy, ¿cambiar dices?, ¿quien me da soporte?, ¿que pasa con mi soporte IBM?, si, sé que NO existe pero puedo justificarme”,

“¿Subir mis datos a una nube?, no estoy seguro“,

“¿Donde están las demás empresas que desarrollan en RoR?“.

Futurice escribe acerca de esto y da algunos consejos de como vender proyectos en RoR.

– «Radiografía de un sitio Web (presente y futuro)» — Ricardo Alfaro y Alter Lagos — Sede Santiago de Chile

– «Contribuyendo al OSS (nadie dijo que era fácil)» — Leo Soto — Sede Puerto Montt

Historias, anécdotas y lecciones sobre cómo un desarrollador en este extremo del mundo puede colaborar en el globalizado mundo del OSS y obtener recompensas que jamás se le pasaron por la cabeza. En realidad contribuir al OSS no es difícil, pero hay códigos que respetar, una cultura que entender y algunos malos ratos que soportar que pueden desanimar mucho cuando uno empieza. Al final todo vale la pena porque la recompensa es mas grande que los malos ratos iniciales, y también por las lecciones que se aprenden en el camino. Transmitir esas lecciones en 45 minutos es tarea difícil, pero no imposible.

– «Configurando una suite ligera de desarrollo Java Web 100% Open Source» — Jorge Rodriguez — Sede Puerto Montt

Para la programación web usando Java hay muchas herramientas de desarrollo, algunas comerciales, la mayoría free, pero todas suites muy pesadas. Esta charla muestra pasos para en pocos minutos configurar un ambiente de desarrollo ligero que permita desarrollar aplicaciones Web de tipo empresarial en la plataforma Java Enterprise Edition, y claro usando tecnología 100 % Open Source.

Nota: Trataremos de grabar las cuatro charlas para publicarlas en nuestra sección de videos.

• Imagine if we had no TCP and had to use ‘IBM NetSphere’

(Yo agrego: Y tengamos que pagar licencias ante actualizaciones anuales o bajar los últimos parches parar no perder mas paquetes).

• Imagine if we had no HTTP and had to use ‘Microsoft Home Network’

(Yo agrego: Y tengamos que usar Internet Explorer de por vida o pagarle a M$ por cada click).

– Alexis Richarson en su presentación sobre RabbitMQ

Esta de moda ser ágiles, y han aparecido un puñado de vendedores de agilidad que intentan ganar dinero tratando de convertirte a la religión ágil con libros, cursos, certificaciones, lo que sea sin importar condiciones o entornos, todos podemos ser ágiles, ¡vamos mierda que se puede!

Y sí, por supuesto que incluso nosotros hemos usado en más de una ocasión alguno de los términos para también «ponernos en onda» y porque bueno a veces los clientes nos preguntan sobre ellos, ¿que remedio?.

Entonces, tú lento que me escuchas, o mejor que me lees: NO intentes ser ágil, se productivo, genera valor. Haz las cosas guiado por el sentido común, no porque lo leíste en un artículo, usa tus instintos y los medios con los que cuentas y solo se productivo; ¿Como?, como seas capaz de serlo y el medio te lo permita.

Aquí van algunos consejos de alguien que cada vez entiende menos de agilidad y más de productividad y que ha ganado fama por ser lo último:

1. Usa al máximo al menos 6 horas del día y no más de 8 sin distracción (descansando lógicamente, recuerda, sentido común[1]), para las demás cosas que no generan productividad (como ver un video en youtube o leer blogs) hay tiempo.
2. Toma una tarea a la vez y termínala sin interrupciones, si es muy grande sepárala en pequeñas tareas.
3. Escribe pruebas de conceptos antes de empezar con las cosas que no tienes idea de como hacerlas (no las hagas, estudia y prueba cosas).
4. Si tu tarea involucra escribir programas con interfaces visuales haz prototipos gráficos de lo que debes hacer y pregunta al cliente si están bien, no te preocupes por la lógica antes de la gráfica, es más fácil programar la lógica cuando te guía una interfaz.
5. Si tienes dudas de como hacer algo no asumas la solución, pregunta sobre el tema, llama al cliente, coméntalo con tus colegas.
6. Trata de no depender de factores externos para desarrollar la solución, con tu laptop debe bastar (puede tomar tiempo hacerlo, pero lo vas a recuperar en el camino).
7. Si algo es muy difícil de hacer no  lo hagas sin antes comentarlo con el cliente, él quiere una solución, pero no tiene que ser esa, pueden negociar otra que que le permita tener lista la funcionalidad en menor tiempo.
8. Intenta plantearte los casos de bordes, si no usas TDD (tecnicismo, ja) no significa que no puedas ser productivo, escribe los test en un archivo de texto, y antes de entregar pruébalo todo de nuevo.

Usa el sentido común para ser productivo y no ágil. Eso te va dar más valor.

[1] Nosotros tenemos una mesa de ping-pong en la oficina, y se puede usar libremente (ehh, o sea como dictaría el sentido común, pocas veces en el día.)

jQuery.map( array, callback(elementOfArray,  indexInArray) )
jQuery.each( array, callback(indexInArray,  elementOfArray) )

¿Pura inconsistencia, o algún motivo implícito?

String.prototype.namespace = function(separator) {
  this.split(separator || '.').inject(window, function(parent, child) {
    return parent[child] = { };
  });
}

Hoy lo modifiqué para el caso en que si ya existe el namespace no lo sobre-escriba (no perder lo hecho):

String.prototype.namespace = function(separator) {
  this.split(separator || '.').inject(window, function(parent, child) {
    return parent[child] == undefined ? parent[child] = { } : parent[child];
  });
}

Como se usa:

"cl.continuum.blog.demo".namespace();
// voilá, tenemos el namespace cl.continuum.blog.demo
cl.continuum.blog.demo.Post = {name: "function namespace() {...}", author: "jorge.rodriguez"}