Thursday, 19 February 2009

Copy & Paste Oriented Progamming

It seems that you become more popular if your inventions have a name that matches the following pattern:

/.+\sOriented\sProgramming$/

So I've decided to put a name to something that already exists to test if my previous statement is true: the "Copy & Paste Oriented Programming". You'll obviously call it, CPOP (if the acronym of you invention matches a funny word, you'll get some extra points. This is not the case :P).

Okay, now, a tool I want to recommend for CPOP, or just in case you are constantly using the clipboard.

ClipX
This tool lets you store more than one element copied in the clipboard and paste any of them whenever you want. I find it really useful. Give it a try! :P

Spanish version...


Parece ser que uno se lanza a la popularidad y el cholulaje cuando inventás algo y le ponés un nombre cheto que matchea con:

/.+\sOriented\sProgramming$/

O sea, "LoQueSeTeCante Oriented Programming". Así que para verificar si mi teoría es cierta, le puse un nombre a algo que en realidad existe hace mucho tiempo: La "Copy & Pase Oriented Programming". Obviamente, lo encontrarás mencionado como CPOP (nos gusta ahorrar. Ah, y además si hacés que tu acrónimo coincida con una palabra graciosa, vale doble! No es el caso).

Bueno, en consecuencia, quiero recomendar una herramienta para CPOP que es muy útil para los usuarios habituales del clipboard o portapapeles:

ClipX
Es una herramienta que te permite almacenar más de un contenido en el portapapeles cuando copias, de manera que al momento de pegar, podés seleccionar de una lista cualquiera de los contenidos copiados. A mí me resulta bastante útil. Pruebenlo y me dicen...

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