Creativity

Why do I like software?

This has always been like magic for me. Just get an idea, write some code and get 'something' working from 'nothing' but an idea. I feel it like synchronizing my mind with the code and letting it happen. Are there any boundaries? I don't think so: imagination doesn't have any; maybe computers do, but for the time being my imagination is not that big. ;)

Does software development require creativity?

creative/kriˈeɪtɪv/

▶adjective relating to or involving the use of imagination or original ideas in order to create something.

Yes, I think so! I guess you can do it even if you're not creative, but the question is: will you enjoy it? I don't see the point if you don't enjoy it!
If we describe software development as "the process of writing and maintaining the source code of a software application" doesn't sound really enjoyable, does it?

Does software development require knowledge?

Yep. That translation between the ideas in your mind and the 'real' 'thing' requires some knowledge and it helps if you have a logical thinking given that computers get on well with guys like that. :)
Anyway, go ahead and learn how to code. It's just a mean to get your ideas into working stuff. Then you'll start dealing with things like maintainability, decoupling, refactoring... and so many other things.

What helps a software developer to give real value?

I think creativity is a clear expression of what I'll call mind-freedom here. Make sure your team members feel comfortable and free to express their ideas. BUT! Always remember to pay them a salary and work on the basics first: remember Mr. Maslow.

Anyway... just some ideas I wanted to share :)

“If you have an apple and I have an apple and we exchange these apples then you and I will still each have one apple. But if you have an idea and I have an idea and we exchange these ideas, then each of us will have two ideas.”

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...

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.

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.

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.

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

How to kill a Dragon with Programming

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

How to kill a Dragon with Programming - Upload a doc

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

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 everything 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...)

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.

XML Data Islands

Internet Explorer XML Data Islands can be really useful if you're working in a IE compliant context. This basically lets you embed a XML structure in your browser and create bindings between this structure and the HTML tags you use in your document.
Binding keeps the XML and the HTML structures coupled, so that each change in the HTML tags content can be reflected in the XML structure.
For further information you can visit:

• W3Schools->XML Data Islands
• MSDN - Using the XML Data Source Object

A simple example can give you an idea of what I'm talking about. This will show you a simple case in which it can be used:

<html>
<body>
       <xml id="cdcat">
            <CATALOG>
                <NAME>My CD Catalog</NAME>
                <CD>
                    <TITLE>Over Again</TITLE>
                    <ARTIST>Gunner Sixx</ARTIST>
                    <ALBUM>
                        <NAME>Gunner Sixx Demo</NAME>
                    </ALBUM>
                    <ALBUM>
                        <NAME>Gunner Sixx Greatest Hits</NAME>
                    </ALBUM>
                </CD>
                <CD>
                    <TITLE>Candleburn</TITLE>
                    <ARTIST>Dishwalla</ARTIST>
                    <ALBUM>
                        <NAME>Opaline</NAME>
                    </ALBUM>
                </CD>
                <CD>
                    <TITLE>Angels or devils</TITLE>
                    <ARTIST>Dishwalla</ARTIST>
                    <ALBUM>
                        <NAME>Opaline</NAME>
                    </ALBUM>
                </CD>
                <CD>
                    <TITLE>Tears in heaven</TITLE>
                    <ARTIST>Eric Clapton</ARTIST>
                    <ALBUM>
                        <NAME>Eric Clapton - Unplugged - 1992</NAME>
                    </ALBUM>
                </CD>
                <CD>
                    <TITLE>Old and wise</TITLE>
                    <ARTIST>Alan Parson's Project</ARTIST>
                    <ALBUM>
                        <NAME>Alan Parson's hits</NAME>
                    </ALBUM>
                    <ALBUM>
                        <NAME>80's Hits</NAME>
                    </ALBUM>
                    <ALBUM>
                        <NAME>The very best of Alan Parson's Project</NAME>
                    </ALBUM>
                    <ALBUM>
                        <NAME>Alan Parson's Project unplugged</NAME>
                    </ALBUM>
                    <ALBUM>
                        <NAME>More and more hits</NAME>
                    </ALBUM>
                </CD>
            </CATALOG>
        </xml>

   <table border="1" datapagesize="2" id="mainTable" datasrc="#cdcat" datafld="CD">
       <tr>
           <td><span datafld="ARTIST"></span></td>
           <td><span datafld="TITLE"></span></td>
           <td>
               <table border="1" id="subtable" datasrc="#cdcat" datafld="ALBUM"&gt;
                   <tr>
                       <td>
                           <span datafld="NAME"></span>
                       </td>
                   </tr>
               </table>
           </td>
       </tr>
   </table>
   <BUTTON ID=cmdpreviousPage onclick="mainTable.previousPage()">&lt;</BUTTON>
   <BUTTON ID=cmdpreviousPage onclick="mainTable.nextPage()">&gt;</BUTTON>
</body>
</html>

Some comments about the sample code:

• The xml can be referenced by a 'src' attribute in the XML tag. This lets you separate the XML structure in a different file.
• Any XML structure can be used. The 'datasrc' attribute in the table tag associates the XML structure as a datasource of the table.
• The 'datafld' attribute is used for binding the HTML structure with the XML one.
• Subtables can be used in the same way in complex structures by adding the 'datafld' attribute to the subtable.
• Tables can be paged by using the 'datapagesize' attribute. IE also provides some default methods for this paged tables like 'tableId.previouspage()' or 'tableId.nextPage()'.

This is just a simple example, but it's useful to take into account that these tools can be really helpful. You can see it in the example above. Just a few declarative code lines and a some functionality pre-implemented.
However, and this is very restrictive, your application/html doc must be only IE compliant by the moment.

Feeling more productive

In recent months, I've been reflecting about those things that can make an IT worker feel more comfortable at work, or, at least, make the job easier. I mainly refer to the tools and infrastucture that support our daily tasks and make our work environment more productive.
I think it's a good idea to list these things I consider interesting to have within arm's reach, for all those who can be interested in them:

Tools

• Knowledge Base. In my opinion, it's really interesting to have some tool that let you compile information related with specific topics. For example, it can be useful to have a wiki, to share that information that you wouldn't find in other place. Some of the topics could be, comments about books you read, common technical problems and solutions, opinion about new technologies, methodologies and procedures, and especially topics related with information that you usually get from another people you work with (and that can, from any moment to another. not be working with you anymore).
• Mailgroups. I think that they are important for those moments when you have a question or problem that you can't resolve by yourself, and you need help from some especialized people. Sending a mail to a mailgroup can make you get some solutions or, at least, new ideas or ways to restart your search for the solution you need. I think that forums can really be useful in the same way, but I think they only can be as powerful and comfortable as mailgroups if some technology like RSS, or something like that, is applied to them.
• Instant messaging. Hey! not just to chat with your friends! It can be surprising the amount of help you can get from your colleagues using this kind of technology. Especially to get answers about things you shared in the past with them and perhaps now you can't remember (i.e. 'do you remember the name of the library you used for your project in 2004 blablabla? '). It can make you save a lot of time, get important information and be in touch with colleagues. But, be careful! Don't overuse this resource!
• Documentation templates. It can really organize your documents by itself. Knowing which templates you have available is, in my opinion, as important as having them. Having lots of documentation templates is not necessarily important; having the right and useful ones is the goal. This approach saves time when documenting and standardizes your documents.
• File server. A common place for storing your files will let you share them with your workmates. You can store documents there, applications you download from the web and you want to have available, libraries versions, e-books, and so on.
• Outlook, post-it or similar. It's mandatory for me to have some tool with an alarm or reminder where I can write down things I shouldn't forget to do. I've became a kind of reminder-dependent person lately.
  

Working place

• Library. In my opinion, e-books are a really good for having as reference and for searching topics or key-words. But, they're not comparable to real books that you can read anywhere (i.e. bus, train, subway), even in your box at work. It's important for me to have a library near, and to have it orgaized and accesible.
• Meeting room. It can be the place where you share your thoughts with your boss or workmates without bothering another people that have nothing to do with the topic you're going to talk about. It's good for communication to share your thougths and to know the status of the environment you're workin in.
• Comfortable boxes. Every person needs a comfortable place to be/feel more productive at work. Some special considerations I find interesting to have are: having a blackboard near to discuss solutions with visual aids; having comfortable boxes to be able to discuss problems easily with your workmates and not to be isolated from the others.
  

Activities

• Technical meetings. I think that having this kind of meetings where you can share your experiences with your mates can help you balance the knowledge in your workgroup and the interest in different topics. Besides this you'll probably get different points of views that enrich the meetings.
• Status meetings. Knowing the status of your project or your workmates projects' can help you to know where you are, and where you are going, what tasks to focus in, and so on.
  

Teoría vs. Práctica. Round 1

En el trabajo del día a día uno a veces cae en la cuenta de que las cosas no son siempre como se leen en los libros; si, esto está claro desde hace rato. Teoría vs. práctica. Pero sinceramente creo que es parte de nuestro trabajo también tratar de que estos dos extremos no se aparten tanto uno del otro.
El caso en el que estoy pensando ahora es, desde mi punto de vista, bastante común. Hablo de un análisis real en el que se consideren los factores necesarios para la selección de un lenguaje de programación para resolver un problema (obviamente, una vez que este está definido y está claro que se quiere solucionar desarrollando una aplicación, script o lo que sea...).

Hasta el momento, nunca tuve la suerte de tener la suficiente libertad ni la posibilidad de realizar un análisis exhaustivo acerca de este tema en un contexto laboral. Por lo general noto que algunos de los siguientes factores afectan con alta influencia a la selección del lenguaje, no permitiendo tener estas libertades de las que hablo:

• Lenguaje con el que trabaja la empresa u organización en la que trabajamos. Por una cuestión de convenios o relación laboral inter-empresas o por disponer de licencias para determinados productos asociados directamente a un lenguaje determinado, nos vemos acotados en el análisis. Este tipo de restricciones parece inevitable.
• Conocimientos por parte de los recursos. ¿Por que pasa a ser esta una restricción? Pienso que muchas veces por especulación. Si se tiene desarrolladores con dominio de un lenguaje de programación determinado y la posibilidad de capacitar o bien obtener nuevos desarrolladores con dominio del lenguaje que realmente se requiere, ¿por que no hacerlo? Tal vez sea porque no se sabe qué lenguaje realmente se requiere (aquí estaría afectado el 'conocimiento por parte de los recursos' de más alto nivel: líderes técnicos, arquitectos, etc.). O tal vez sea por propósitos económicos (léase, ahorrarse unos mangos). Yo veo a este tipo de restricciones como algo posiblemente evitable, siempre que se cuente con los recursos y voluntad necesarios.
• Modas. Muchas veces se nota que, debido a falta de claridad en ciertos conceptos, se selecciona un lenguaje en función a 'lo que se usa actualmente'. Sería algo asi como un '...y si lo usa todo el mundo debe ser bueno...'. No creo que haga falta aclarar mucho mas.
  

A modo de mini-resumen observo que a menudo trabajamos matando lo que se nos cruce por delante con un cañón. Sea un ejercito entero o un mosquito. Ni hablar de cuando se eligen frameworks o toolkits para trabajar, pero de eso podemos 'hablar' en otro momento (aunque está muy relacionado).

Por otro lado, algunos de los factores que tendría en cuenta si existiera esa libertad para el análisis (que actualmente veo restringida):

• Análisis del problema y visión. Creo que en parte el análisis del problema a resolver se basaría en un análisis de la posible solución y su factibilidad. Esto requeriría experiencia y visión del profesional encargado del análisis.
  
• Eficiencia del lenguaje. ¿Necesito responder en tiempo real? ¿Como me pueden perjudicar/beneficiar factores propios del lenguaje o de la plataforma que lo soporta (se me ocurre por ejemplo, el uso de Garbage Collectors, manejo de la memoria disponible, etc)?
  
• Comunidad de apoyo/referencia. Si tengo problemas, tengo a quien recurrir? Empezando por los recursos que tenga en la empresa (líderes técnicos, arquitectos, etc.) y siguiendo por la comunidad de desarrolladores que podemos consultar por ejemplo en foros o que nos puedan comunicar su experiencia.
• Documentación existente. ¿Existe documentación formal sobre el lenguaje (mas allá de los foros... ¿algún libro, tutorials?), problemas existentes, problemas solucionados, y todos aquellos factores que nos reflejen la madurez del lenguaje?.
  
• Proyección, crecimiento. ¿Es un lenguaje con tendencia a evolucionar, madurar, integrarse?¿Cuán viable parece una migración?
• Paradigma. ¿Pertenece a algún paradigma de programación?¿En que medida se ajusta al paradigma al que pertenece?
• Herramientas asociadas. ¿Existen frameworks/toolkits/bibliotecas de funciones maduras para el lenguaje que me puedan ayudar en el desarrollo de mi solución? ¿Existe una IDE que brinde beneficios considerables en el trabajo diario?
  

La conclusión desde mi punto de vista es que la realización de este tipo de análisis no resulta excesivamente costosa; Si bien, muchas veces nos encontramos afectados por las restricciones mencionadas inicialmente y no poseemos control sobre ellas, observo que con frecuencia, la selección del lenguaje no es resultado de un análisis real, sino es tomada como premisa incuestionable de trabajo. ¿Por qué entonces no realizar un análisis real y exhaustivo y comunicarlo a los niveles superiores en un modo profesional y a la vez comprensible de manera de lograr mayor eficiencia? Si no logramos eficiencia, tal vez logremos mostrar profesionalismo. Cuando las cosas se hacen bien, la recompensa llega en algún momento.

Con ojos de End-User

Este post no pretende ser innovador ni dar grandes soluciones al desarrollo de software.
Simplemente es una simple observación. Hoy estuve navegando la aplicación con la cual trabajo actualmente implementando ciertas funcionalidades y me topé con un problema que observo recurrentemente en aplicaciones web.
Describo lo sucedido:

• Accedo a uno de los modulos de la aplicación que muestra ciertos datos en un pop-up.
• Me levanto para ir a hablar por teléfono (si, hasta ahora no tiene sentido, no?)
• Regreso a la PC luego de hablar, y cuando realizo alguna acción en el pop-up encuentro que la session ha expirado; inmediatamente la aplicación me redirige a la pantalla de login, pero en el pop-up!.
• Me logueo y continúo navegando la aplicación pero adentro de un pop-up. Desagradable!

Este problemita lo vengo observando desde hace rato, en varias aplicaciones. Entiendo que la complejidad de solucionarlo no es tan alta como para no hacerlo y, desde mi punto de vista, tener en consideración este tipo de detalles en un desarrollo hace notar el esfuerzo en la calidad. Tal vez con un manejo de excepciones especial para los popups en la aplicación sea suficiente. Tal vez haya que pensarlo un poco más, dependiendo de la situación.
En fin, a veces hace falta pensar un poco como end-user para ver estas cosillas...