Thursday 1 November 2007

Perseverance

This is a well known phrase, but, however, I think it's worth sharing it:

"When nothing seems to help, I go look at a stonecutter hammering away at his rock perhaps a hundred times without as much as a crack showing in it. Yet at the hundred and first blow it will split in two, and I know it was not that blow that did it, but all that had gone before."


Jacob Riis

Spanish version:

"Cuando nada parece ayudar, voy y miro a un picapedrero, dedicado a golpear su roca quizás cien veces, sin que en ella aparezca una sola grieta.
Sin embargo cuando da el golpe ciento uno, la roca se parte en dos, y yo sé que no fue ese último golpe el que la consiguió partir, sino todos los que había dado con anterioridad."

Jacob Riis

Wednesday 17 October 2007

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:


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.

Tuesday 11 September 2007

Genesis@LaNacion

It's good to know we're in the news again. This time in one of the most important newspapers of my country. It'll be an interesting challenge for us to accomplish the expectations.
Let me share this link with you:

La Nación->Comercio Exterior

Thursday 30 August 2007

Genesis@Infobae

I'd like to share with you an Infobae piece of news this time. It's about the enterprise and the team I'm working in, and the way it's been (and is expected to go on) growing lately.
It's always good t
o know that your managers trust in your work and also to be part of the technology news of a well -known news site!

Here's the link:
Infobae->Tecnología

Friday 27 July 2007

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.

Wednesday 11 July 2007

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.

Thursday 5 July 2007

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

Wednesday 27 June 2007

"Convicción es la clave"

Para darle la bienvenida a mi nuevo blog al mundo de los internautas, quiero comenzar con mi frase de cabecera.
Pese a lo que muchos digan, para mí es tan simple como lo que está escrito. No voy a dar explicaciones sobre su significado; dejo abierta la interpretación a quienes la lean y tengan ganas de pensar. Desde mi punto de vista, aplica a diversos contextos y situaciones.
Ya veremos como continúa todo esto. Por lo pronto, no es más que lo que es.