Sunday 12 October 2008

Development improvement tools

Let me share with you the links to two tools that have been helping me a lot in my daily development tasks lately.
Both of them are available as Eclipse plugins, are free and they really help to improve the quality and efficiency of our developments.

1.- Enerjy:
This is a code analysis tool (similar to Findbugs, for instance) that helps to find bad practices in our code, improve our code standarization, find common errors, and so on.
It's really easy to use since it doesn't need the user to perform the code analysis operation manually; it just executes the task on every build we make, updating the warnings in our editor so that we can analyze the possible errors found and decide if we want to fix them or ignore them (by adding a special comment).
The tool is also easily configurable and provides help information about each warning it shows, explaining the causes of each possible code error.

2.-TPTP (Eclipse Test & Performance Tools Platform Project):
TPTP is basically a profiling tool that helps us improve our applications performance in relation to processing time and resources usage. This tool provides different kind of reports that are configurable so that we can filter the displayed information to our convinience. This helps to find weak points in our application if used correctly.

I recommend you to take a look at these tools since they're not hard to use and are really helpful
.


Spanish version...

Aquí les dejo dos links de herramientas que ultimamente me han resultado de gran utilidad en mis tareas diarias de desarrollo.
Ambas herramientas están disponibles como plugins para Eclipse, son free y realmente ayudan mucho a mejorar la calidad y eficiencia de nuestro código.

1.- Enerjy:
Es una herramienta de análisis de código (similar a Findbugs por ejemplo) que nos ayudará a encontrar malas prácticas en nuestro código, mejorar la estandarización del mismo, encontrar errores comunes, etc.
Es muy facil de usar ya que la herramienta no necesita que ejecutemos el analisis de codigo manualmente, sino que realiza esta tarea ante cada build que hacemos y actualiza los warnings en el editor del Eclipse. En funcion a los warning mostrados, podemos decidir si queremos arreglarlos o bien ignorarlos; esto ultimo se realiza agregando un comment especial en el codigo que evita que se muestre el warning.
Esta herramienta es facilmente configurable y brinda info de ayuda para cada warning que muestra, explicando las causas del posible error.

2.- TPTP (Eclipse Test & Performance Tools Platform Project):
Basicamente es un profiler que nos ayudará a mejorar la performance de nuestras aplicaciones en cuestiones de procesamiento y uso de recursos.
Esta herremienta provee distintos tipos de reportes que podemos filtrar de la manera que mas nos convenga. Asi podremos encontrar debilidades a nuestras aplicaciones analizando correctamente la informacion de los reportes.

Les recomiendo que le peguen un vistazo a estas herramientas ya que no son difíciles de utilizar y son de mucha ayuda.

Wednesday 8 October 2008

The distanced paper theory

During my attendance to Maths II course in college, proffesor Liliana Gallego (an excelent teacher by the way) taught us a good practice at an informal level for the analysis of problems or situations which she used to call "the distanced paper theory". Basicaly she observed that a very common behaviour amongst her pupils is to start solving a problem and lock up so much in them and it's numbers that end up losing the whole vision or the main global objective of the solution to be found. That's why, the practice consisted in stopping for a while with the resolution, take some distance from the paper where we're writting our equations and numbers and think if we're following the right steps to reach the solution of the problem.

Of course this practice is applicable in any situation, besides the resolution of mathematic problems. To stop and look where we're at and to verify that we're doing what's expected should be a constant in our tasks in any environment; however many times we let ourselves carried away by the inertia of our routine without stepping on the break.

This introduction came because, many times, we may want to apply the "distanced paper theory", and start thinking about our current position, but needs to establish certain criteria for this analysis.
What I want to describe in this post, is the set of parameters to be considered to analize the conformity situation in a job (always in an IT context) and, in that way, make easier or at least establish an order in this task.

1.- Projects
I believe that analizing the projects that are managed in the company where we work will let us establish, at least, two important things: First, decide if the project where we're working at is really intresting. Second, to analize the posibilities of changing projects keeping our current job if any other project seems intresting for our plans.

2.- Wages
Analize our wage in comparison with our job position in the market. High wages, or at least, at the market level could be motivating, but we should analize this considering the rest of our variables. In some cases, wages a little lower could be compensated with intresting projects or with promising job carreers.

3.- Environment
The job environment is of great importance to find ourselves satisfied with our job. If we're going to spend a third of our day at the office, at least we should look for feeling as comfortable as possible in that place.

4.- Carreer plan
I find of great reelavence to have a projection for the future of our proffesional growth. This vision will allow us to plan our future in an ordered way. The more vision we have, the better we'll be able to orginize our objectives and try to reach them. In this case we should take into account two factors: In the first place, to have a clear picture of where we want to go (or to start looking for it) and, second, analize if our current job gives us the posibility of getting through that path.
I think that this four items related are vital when making decisions related to our conformity with our current job, change possibilities or even possibilities of changing ourselves.

Author: Daniel Zuazaga
Translation (into english): tete (
Thank you very much)



Spanish version....

Durante la cursada de la materia "Análisis matemático II" en la universidad, la profesora Liliana Gallego (excelente profesora por cierto) nos enseñó una buena práctica a nivel informal para el análisis de problemas o de situaciones a la cual ella misma llamaba la "Teoría del papel alejado". Básicamente ella había observado que un comportamiento muy reiterado entre sus alumnos es el de comenzar a resolver los problemas y encerrarse tanto en ellos y sus cálculos que se pierde la visión o el objetivo a nivel global de la solución que se busca. Por esto, la práctica consisitía en hacer un alto en la resolución, alejarse del papel donde escribimos nuestras ecuaciones y cálculos y pensar si estamos realizando los pasos correctos para llegar a la solución del problema.
Claro que esta práctica es aplicable a cualquier situación, más allá de resoluciones matemáticas de problemas. Detener nuestra marcha para mirar dónde estamos parados y verificar que estamos haciendo lo esperado debería ser parte constante de nuestras tareas en cualquier ámbito; sin embargo muchas veces nos dejamos llevar por la "inercia" de nuestra rutina sin poner el pié sobre el freno.


Esta introducción venía en relación a que, muchas veces, uno quiere aplicar la "Teoría del papel alejado", y comienza a analizar su situación actual, pero necesita establecer criterios para ese análisis. Lo que quiero describir en éste post, es el conjunto de parámetros que tomaría en cuenta para analizar la situación conformismo en un empleo (siempre en el contexto de IT) y así facilitar o al menos establecer un orden en esta tarea.

1.- Proyectos
Creo que analizar los proyectos que se manejan en la empresa donde se trabaja nos permitirá al menos dos cosas importantes: Primero, decidir si el proyecto donde estamos trabajando nos resulta realmente interesante. En segundo lugar, analizar las posibilidades de cambio de proyecto manteniendo el empleo actual si algún otro proyecto tiene un atractivo para nuestros planes.

2.- Salario
Analizar nuestro salario en comparación con nuestro puesto laboral en el mercado actual. Salarios altos o al menos al nivel del mercado pueden resultar motivadores, pero esto debemos analizarlo conjuntamente con el resto de nuestras variables. En casos, salarios un poco más bajos pueden ser compensados por proyectos interesantes o bien planes de carrera prometedores.

3.- Ambiente
El clima laboral resulta importantísimo para encontrarse satisfecho con nuestro trabajo. Si vamos a estar un tercio del día en la oficina, al menos busquemos sentirnos lo más cómodos posible en ese lugar.

4.- Plan de carrera
Me parece importante tener una proyección a futuro sobre nuestro crecimiento. Esta visión nos permitirá planificar nuestro futuro de una manera ordenada. Mientras más visión tengamos, mejor nos podremos organizar para establecer nuestros objetivos e intentar alcanzarlos. En este caso debemos tener en cuenta dos factores: Primero, tener claro a dónde queremos llegar (o comenzar la búsqueda de ello) y segundo, analizar si nuestro empleo actual nos brinda la posibilidad de transitar un camino hacia ello.

Creo que estos cuatro factores interrelacionados son vitales a la hora de tomar decisiones relacionadas con nuestro conformismo con el empleo actual, posibilidades de cambios de empleo o bie n posibilidades de cambios internos.

Saturday 16 August 2008

Photo award (?!)

There has been a pictures competition this year where I work and I got the first place in it. :P How is this possible? No one can understand it, so can't I. But the prize is mine!

Spanish version...

Este año hubo un concurso de fotografía en mi trabajo. La verdad que no tengo idea cómo gané. De hecho, nadie entiende, pero bueno, tengo el primer puesto y el voucher para canjear en Garbarino jeje. La próxima voy a buscar otra disciplina así nadie se dá cuenta que esto no fué por talento sino por azar....

Wednesday 25 June 2008

Java null casting

This afternoon I was making a code review and I saw something in the code that drew my attention. It was a 'null' casting in the code I was checking.
It was something like:

(Object[]) null
Even if I remembered having seen that null casting in the past and knowing it wouldn't fail, I didn't realize immediately why the other developer had included this "unnecessary" (at first sight) casting in the code.
Looking for a quick explanation to this, I found nothing useful and it was then when I tried to remove the "unnecessary" code and I figured out what this was all about. I finally found the answer to my question: "When is it required to make such 'null' casting in the code?"

The reason is the result of a situation similar to this:


Suppose we have a method
myMethod(String a, String b)

and an the overloaded method
myMethod(String a, Object[] b)

When we call the method like this:
anObject.myMethod("WhatAPlate!", null)
;

the JVM will have no way of identifying which of the methods should be invoked for the message received since both of them match perfectly. As a consequence, that's the case where you could call the method using a null casting in this way:
anObject.
myMethod("WhatAPlate!", (Object[])null);


Spanish version...

Haciendo un Code Review hoy a la tarde me encontré con algo que me llamó la atención. Se trataba de un casteo de 'null' en la mitad del código Java que estaba revisando.
Algo así:
(Object[]) null
Si bien recordé que en algún momento había visto eso y sabía que no fallaba, no entendía por qué lo habían incluído en el código. A simple vista no parecía algo útil. Después de leer un poco y no encontrarle la vuelta rápido intenté quitar el casteo que para mí en ese momento estaba de más y me dí cuenta de lo que no veía hasta el momento: "¿En qué situación puede ser necesario castear 'null'?".
El tema era:
Supongamos que tengo un método:
miMetodo(String a, String b)
y una sobrecarga:
miMetodo(String a, Object[] b)

En la llamada al método, si realizo la llamada:
unObjeto.miMetodo("quePlato!", null);
la JVM no tendrá manera de darse cuenta a qué método invocar debido a ambos métodos podrían responder a ese mensaje.
En tal caso, puede realizarse la llamada enviando el mensaje:
unObjeto.miMetodo("quePlato!", (Object[])null);
que haría que la llamada pueda resolverse correctamente.

Wednesday 18 June 2008

License plates chaser 4

Here, another of my geek license plates!... This time Team Foundation Server is present in my blog. :)


Spanish version...

Acá otra de mis fotos patentes ñoñas. Esta vez le tocó a Team Foundation Server estar presente en mi blog :)

Documenting software architectures

Let me share this time an InfoQ video in which Markus Voelter talks about documenting software architectures. It's really interesting.


You can also get deeper information
here. See Gustavo Brey's comment there. It adds an interesting topic to the subject.

Spanish version...

El video que comparto acá es una entrevista a Markus Voelter (lo obtuve de InfoQ) hablando sobre documentación de arquitecturas de software. Muy interesante.
Pueden encontrar más información acá.
Fíjense el comentario de Gustavo Brey que agrega un punto muy interesante al tema.
Ah... como PD: Markus no tiene un aire a Rodrigo Palacio? :P

Saturday 24 May 2008

How to kill a Dragon with Programming

I was recently told about this article. It's too funny not to share it. :)

Read this doc on Scribd: How to kill a Dragon with Programming
Versión en español...

Hay muchas traducciones en español dando vueltas por ahí. Les paso el link de una, para no redundar la información en internet :P

Link

Friday 23 May 2008

Eclipse 3.3 + WTP 2.0

Some weeks ago I tried to install Eclipse 3.3 with WTP 2.0 (All in one) and JDK 6 in my notebook with Windows Vista.
The problem I had was really bothering, but easy to solve when I realized why I was getting the weird behaviour in the application.


The problem:
I unzipped Eclipse in a directory and when I executed it ev
erything worked fine but all the parts of the application related to dynamic web projects. I realized about this because creating a new Dynamic Web project was what I wanted to do. I didn't have the option in the File-> New menu, neither I had the JEE perspective.

The cause:
Apparently, after installing the JDK 6 I installed a JDK 1.4 for some reason. The environment variables were updated with the 1.4 JDK and so, Eclipse
tried to work with that one instead of the JRE 6.

The really weird and bothering behaviour was that when Eclipse started working, it didn't show any warning or error related of the incorrect JRE being used. The bad thing is that I spent more time than what I would have wanted in reaching to the real cause of the problem. As usual, I realized about the possible cause of my problem while doing something else... (this time while cleaning my teeth :P)



Spanish version...

Hace un tiempo intenté instalar en mi notebook con Windows Vista un Eclipse 3.3 con WTP 2.0 que viene en un paquete todo junto (All in one) junto con la JDK 6.
El problema que me surgió fue bastante molesto, pero fácil de solucionar cuando me dí cuenta por qué sucedía.

El problema:
Descomprimí el Eclipse en un directorio y al ejecutarlo, levantaba perfecto salvo por el hecho de que varias opciones no aparecían en los menúes. Me dí cuenta de esto porque por ejemplo no tenía las opciones de creación de proyecto web dinámico (ni las vistas relacionadas con proyectos web). El resto de la aplicación andaba bien.

La causa:

Aparentemente por alguna razón, en algún momento instalé una JDK 1.4 y las variables de entorno del sistema quedaron apuntando a esa JDK. Por lo que el Eclipse intentaba levantar con la JRE 1.4 y esta versión del Eclipse sólo funciona con JREs de 5 para arriba. Lo que me llamó mucho la atención es que al levantar el Eclipse no me tiró ningún error o warning que me indicara que el problema era ése.

Bastante molesto, porque llegar a la raíz del problema me llevó más tiempo del que hubiera esperado. Como de costumbre, me dí cuenta de qué era lo que pasaba cuando dejé de tratar de resolverlo y me puse a hacer otra cosa... (cepillándome los dientes...)

Wednesday 21 May 2008

Simple practices - Part 1

One of the practices we started using some time ago in the team I'm part of, is a kind of 'stand-up meeting' twice a week.
Basically, we, the Argentinian team members, meet around 15 minutes in the the beginning of week to discuss the week goals and tasks and 15 minutes on Fridays (not the fast food shop :P) to check the status of our previous goals.

Our initial motivation on doing this was:

Visibility and focus:
As our team leader, project manager (and the rest of the team) don't work with us in the offices in Argentina, sending a summary of the weekly goals and tasks lets them have a better idea about the work progress on our projects and also lets them analyze the we're really focusing on the important tasks or if there's something we're missing.

Problems discussion:
The fact of talking about the tasks assigned to each of the members of the development team lets us treat common problems from different points of view. Sometimes we're in the need of solving problems that look isolated but we realize, while discussing solutions for them, that there are other possible generic ways to, not only solve our isolated problem, but to ease other members work or even prevent future issues. This leads to development integration in the group for a common goal and
time/resources saving.

When we reach the end of the week, we analyze the amount to completed and pending tasks and we also add a list of 'unplanned' tasks that were done.
Although this is a very simple practice, sometimes it becomes hard to get out of the daily routine and join altogether in a short meeting. However, we're now
realizing about the benefits of doing so.


Spanish version...

Una de las prácticas que adoptamos hace un tiempo en el equipo en el que trabajo es la de tener reuniones cortas dos veces por semana.
Los que hacemos basicamente es juntarnos unos 15 minutos para dar comienzo a la semana estableciendo objetivos semanales y otros 15 minutos los viernes para cerrar la semana y ver el estado de los objetivos planteados anteriormente.
Nuestra motivación para esto originalmente fue:

Visibilidad y enfoque:
Como tanto nuestro team leader, project manager (y resto del equipo) no trabajan en las mismas oficinas que nosotros (ni en el mismo país, y tampoco hablan nuestro idioma), enviar un resumen a principio de semana con las tareas de las que se vá a encargar cada uno le permite al resto del equipo tener una mejor idea acerca del progreso del trabajo de cada uno y, a la vez, analizar si se está poniendo foco correctamente en las tareas asignadas o si queda algun asunto pendiente en el que no se está trabajando y es de importancia.

Conocimiento de problemáticas:
El hecho de discutir las tareas que cada uno realizará durante la semana muchas veces nos permite tratar problemáticas comunes desde otro punto de vista. Muchas veces necesitamos solucionar problemas que parecen ser aislados y al poner en común los temas en los que estamos trabajando nos damos cuenta de que una solución genérica puede atacar varios problemas de distintos miembros de l grupo a la vez.

En el cierre semanal establecemos la cantidad de tareas completadas, la cantidad de tareas pendientes y agregamos las tareas 'no planificadas' que fueron realizadas.
Si bien es una práctica muy simple, muchas veces cuesta cortar con la rutina para juntarse a hablar unos minutos. Sin embargo, esto resulta más que beneficioso para nuestro equipo.

Saturday 10 May 2008

License plates chaser 3


Ahora entramos un poco mas en el mundo de Java...

Translation:

Now, we enter to Java world...

License plates chaser 2


Siguente ejemplo, pasamos a sistemas de control de versiones...


Translation:

Next example, we start with the code versioning systems...

License plates chaser 1

Creo que asi como muchas de las personas que trabajan en puestos de trabajo considerados insalubres tienen efectos secundarios por el simple hecho de trabajar, de la misma manera el mundo IT puede causar efectos comparables en las personas (o tal vez solo me afecta a mi?).
Bueno, en este caso, la primera entrega de mi caza de patentes:

No podia ser de otra manera, la primer patente tenia que ser esta...








Translation:

It's my belief that in the same way people who work in unhealthy jobs get side effects caused by the simple fact of working, we, the IT guys, can get similar effects (or perhaps I'm the only one affected).

In this case, my first license plate chasing resulted in the picture above.
It couldn't be in other way, the first picture should be that one.