Centering floated elements with CSS

Today I found a tricky way to get floated elements centered into a container div. The idea is pretty basic and it doesn't use any CSS hack. So, let's comment first about the problem. I have a variable number of floated elements which I want to display centered if they don't fulfill the container div.
My first approach was to wrap them with another div, which I will call container, where I can use the margin: auto property. In order to get the contained floated elements centered I will need to specify a width for the container. This option is not good, and I hate to declare width into a div. So, I start to research and to do some test and finally I get a very simple solution.
So, the main idea is to use float and relative positioning to achieve the goal. Let me explain it with more details.
I said I have some floated elements into a div, I'm going to use 3 for this example.

<style>
.clear {float: none; clear: both;}

.item {float: left;}
</style>

<div class="item">Lorem Ipsum</div>
<div class="item">Lorem Ipsum</div>
<div class="item">Lorem Ipsum</div>
<div class="clear">

First, I need a container for these elements in order to get them centered into it.


<style>
.clear {float: none; clear: both;}

.item {float: left;}
</style>

<div class="container">
<div class="item">Lorem Ipsum</div>
<div class="item">Lorem Ipsum</div>
<div class="item">Lorem Ipsum</div>
<div class="clear">
</div>

And now let's start to work. As I said, I used float and relative positioning to achieve this. So, the main idea is to apply relative positioning over the container and set the left property to 50%. This will put our container starting in the middle of the screen. Then I apply float to get the width of my container stretched into it content.

<style>
.clear {float: none; clear: both;}
.container {float: left; position: relative; left: 50%;}
.item {float: left;}
</style>

<div class="container">
<div class="item">Lorem Ipsum</div>
<div class="item">Lorem Ipsum</div>
<div class="item">Lorem Ipsum</div>
<div class="clear">
</div>

Now is where the magic begins! So far I have my floated elements in the middle of the viewport, but not centered. Ok, now you just need to add relative positioning to floated elements and set the right to 50%. And voilá!

<style>
.clear {float: none; clear: both;}
.container {float: left; position: relative; left: 50%;}
.item {float: left; position: relative; right: 50%;}
</style>

<div class="container">
<div class="item">Lorem Ipsum</div>
<div class="item">Lorem Ipsum</div>
<div class="item">Lorem Ipsum</div>
<div class="clear">
</div>

Check it! You can inspect the content below with firebug! I have added some border color in order to give you a clear way of where is every div. Blue one is the container, red ones are the floated elements.

Lorem Ipsum

Lorem Ipsum

Lorem Ipsum

Hope you can got it! Any doubts just ping me!

Removing a workspace from Eclipse Workspace List

I was wondering where the f... Eclipse stores the workspace list. I have a lot of workspaces in my list and the other day I put some letters before I hit enter and I altered the workspace list with nothing clear. So I wanted to remove that entry and others also and I start to looking up where is this data stored.

In MacOs X you can go to your Eclipse folder and dive into configuration folder, there you can find a .settings folder and finally inside it there is a file named: org.eclipse.ui.ide.prefs
Usually you will find it as:

/Applications/eclipse/configuration/.settings/org.eclipse.ui.ide.prefs

Editing this file you will find a RECENT_WORKSPACES variable with the list. Just remove the entries and that's it!

Now if you put something in your workspace switch dialog before the path, something like this:

aaarggg /Users/yop/workspace

you maybe gonna try to find where is the workspace folder. This new folder is created inside the Eclipse.app package, so if you want to remove it or you want to move that content just open the Eclipse.app and look at Contents/MacOS/

CoverFlow for YUI beta version released

I am proud to announce that I have released a beta version of my CoverFlow Image for YUI. It has just two dependencies: yahoo-dom-event and animation. It works with Safari, Chrome and Firefox. IE is not supported yet. It is a javascript based component so you don't need anything but a browser with canvas support.
Feel free to leave comments or suggestions. It's completely free so you can download it and use it.
Since it is a beta version you might found issues.
Check it here: elmasse.gaver.nl

Release 0.1 beta version:

- Multiple image sizes. There is no restriction for size.

- No image limit. You can add how many images as you like.

- Simple interface. You can just use an image list, no need to have complex configuration.

- Works in Firefox3, Safari4 and Chrome. IE is not supported yet.

- All javascript. No flash required.

Unit Tests and CRC Cards

These days I was reading some old papers on the web. I found one about CRC cards (Class Responsibilities Collaborations) and I start thinking that Unit Tests should have some relationship with that. If you take a first look at CRC Cards, they define or document the specific responsibilities for a class and also its collaborators.



So, we can define all the collaborators in our Unit Tests and then implement them with mocks as usual. But what I really like was the idea of using a Unit Test to document responsibilities, so we only should have tests with names revealing responsibilities.



This is not new, but for some reason, at least in my experience, the most test cases I have seen declare a long list of test of methods. If the class under test has 3 getters you'll find at least 3 test cases in the way testGetXXXX(). That is not good. In my opinion Setters and Getters shouldn't be tested, even you shouldn't write them, but this is another topic.

Let's get back to CRC Cards. If you start thinking your tests as CRC Cards you can have a great benefit because when someone needs to modify a class, following TDD, he needs to modify the test to reflect the change and then start to write code. If that change affects a current responsibility you should modify all the tests that document it. If you need to add more responsibility to your class you will create one o more tests to document it. Also it's effective to detect bad designs, if you can't establish a responsibility to test a method maybe you need to review your design.


References:
http://c2.com/doc/oopsla89/paper.html#cards

undefined, null and boolean comparisons in Javascript

Last week I've been working with some simple javascript and I found a common mistake when someone tries to use a variable into an if() or for() sentence.
First let's make a simple review about types in javascript:

Javascript has 5 primitive data types: string, boolean, number, null and undefined.

The first three types are well-known types. Let's talk a bit about the others; undefined means that a variable has been declared but it has not yet been assigned to a value, null is representative for an object that has not been initialized.
In fact, undefined is a type in itself and null is an object.
Consider this example:

var undef;
var nullObject = null;

alert(undef); //shows "undefined"
alert(nullObj); //shows "null"

if(undef) // always false;
if(nullObject) //always false;

Now what if I use an undefined in comparison with a number?

if(1 > undef) //false
if(1 < undef) //false
if(1 == undef) //false

So, nice! don't you think? The problem that I found was into a for sentence, doing something like this:

var flag = true;

for(var i = 0 ; i < someVar || flag ; i++){
   if(someVar < 1) flag = false;
   //some code goes here ...
}

This code has no much sense, but it is for simple demonstration purpose, think about it for a moment.

Looks like a simple, nice and unoffensive javascript code right? No, this is an infinit loop, since undefined < 1 is always false.

Conclusion:
if you are trying to obtain some data maybe using something like document.getElementById() or whatever function which can retrieves an undefined, take this into account.

Enjoy!
elmasse!

Reinventing the wheel

Did you notice that we are just doing the same things trying to get different results? You can think the answer for that question could be 'who does exactly the same thing expecting different results is just an insane guy' and let me tell you something, I think in the same way. But if you take a look in the UI frameworks, tools, or however you want to call it, we are using the same principles, at least this is what I can see in my short experience as Java developer. In the Java world, we had, have, and probably we are still having frameworks like Struts, Struts2, Wicket, Tapestry, JSF, Echo2, GWT and there are a few more.
What I really don't understand is the fact that we want to write applications completely in Java, because Java is robust, easy to test, multi platform, and a huge list of advantages. But what happens when we need to do more things that aren't simply to do in a framework? The first answer could be 'Adapt your needs to the framework boundaries' ... what a f...!!! This sounds crazy?.. mmm, think for a moment... Have you ever worked in a Struts application and now you need to implement Web 2.0 (Ajax) 'simple' changes? Yes, I know, just do some changes here and some others here and voila! Now you are at the beginning of a 'nice Struts Ajax enable application'. Sadly this is a very common situation nowadays.
A different approach is to write Web applications in a 'cool' language and then automagically convert that code into java code. Nice. Now you have to have one thousand classes per each class in your super cool language, a very powerful solution, robust and great because is java code!
GWT, the last intend to reinventing the wheel. Now you write a few lines of code in Java, and then you have a Web 2.0 application. But the prize you need to pay is recompile the application if you want to change a simple javascript line.
I think that it is time to stop this crazy and sick way to make Web applications. Please, just stop. If the solution is write simple html and javascript (i.e. GWT) why don't do it as it is? Why are we trying to magically generate it? Maybe it's time to see that we need to separate UI work and leave it in some language that can handle it simple and use Java as a core language (if you still want to write code in Java).

Please keep in mind the KISS principle: Keep it simple, stupid!

There is no a solution for everything, just use your coffee machine to make coffee and don't try to use it to wash your dishes!

i18n with Ext.js: A resource bundle

Last weekend I was working on i18n with Ext.js, and there is a feature that I miss (so much) from jsp and it is the Resource Bundle. So I realized that I should get something similar to this and I started to write an Ext.i18n.ResourceBundle. The main idea is to create an object that can get a bundle, it means that taking the resource bundle, i.e. from a resource name and the browser's language it tries to find a .properties, so if the language is es-ES it looks for the [bundle]_es-ES.properties file and if it does not exist then it reads the [bundle].properties.

Then you can get a message by the key property through the getMsg(key) method.
This is the entire code and a little example. Enjoy it!

Code and Example could be found here


Usage:

var bundle = new Ext.i18n.Bundle({bundle='Application'});
bundle.onReady(
alert('example'+ bundle.getMsg('key1'));
);

This would read:
-An Application_es-ES.properties file like this if the browser's language is es-ES:
#This is a simple comment
key1 "Mensaje para la propiedad key1"


-If the Application_es-ES.properties doesn't exist then tries to find the Application.properties file like this:
#This is a simple comment
key1 "this is the message for key1"

Bundle(config): config: {bundle: , resource:}
bundle: The bundle name for the properties file.
{bundle: 'mybundle'}
This looks for the file located in:
http:/yourdomain/yourApp/mybundle_[language].properties.
You will need at least the mybundle.properties file.


path: (optional) the path to the bundle file.
{bundle: 'mybundle, path: 'resources'}
This looks for the file located in:
http:/yourdomain/yourApp/resources/mybundle_[language].properties.


Take into account that you need to write your application in the bundle.onReady() method in order to be able to access to your bundle.

Updated [JUL-09] A new Ext.18n.bundle v0.2 is available. Problem solved with ExtJS 3.0

ODBMS - Jugando con db4o...

Hace varios meses atrás googleando me encontré con db4o, una base de datos de objetos. Y aunque al principio era medio incrédulo sobre la posibilidad de que funcionara de la manera esperada, me puse a jugar con eso durante unas semanas. El resultado me pareció asombroso, es persistencia pensando puramente en objetos, nada de relacional, tablas, PKs, FKs, constraints, etc... Vale la pena aclarar antes de seguir adelante que no estoy en contra de las bases de datos relacionales, de hecho un ODBMS tiene serías limitaciones que un RDBMS no. Pero siempre hay que poner en la balanza los pro y los contra para poder sacar una conclusión.
El hecho es que mi sistema necesitaba una base de datos, no iba a compartir la información con otro sistema y tampoco tenia datos legacy, entonces me propuse hacer uso de DB4O. Como primer experiencia, me parecio fantástico. El simple hecho de crear un sistema de a poco, usando algo de TDD, implicaba tener que diseñar sobre la marcha el modelo a representar, con los consiguientes cambios en el modelo de objetos a utilizar, quitar y agregar propiedades en los objetos persistibles es en el modelo relacional un poco complicado porque implica tener que actualizar la base de datos, los mappings del ORM y algunas otras cosas mas. Esto no pasa con un ODBMS, puedo cambiar a gusto y piaccere las propiedades, guardar enums como una propiedad de un objeto y todo esto es transparente para mi modelo de persistencia.
Aún me queda mucho que probar y que investigar sobre este tema, pero quería dejar este comentario para que aquellos que quieran lo prueben, a mi me pareció muy bueno, ahorra tiempo en muchas cosas, y eso me parece feliz!

Bueno espero que lo puedan probar, sacar sus propias conclusiones y podamos comentar las experiencias.

Les dejo un articulo sobre esto que acabo de encontrar : 6 razones para no usar db4o

Saludos!
elmasse...

Sobre diseño y algo más ... reply

Estos dias estuve leyendo un post muy interesante sobre diseño y algo más de alguien a quién respeto mucho, Hernán Wilkinson. Y este post de hoy esta dedicado a hablar sobre eso y tratar de explicar un poco mas extensamente mi punto de vista.

En primer lugar hay una distancia insalvable entre la experiencia de Hernán y la mía, y uno de los grandes hitos que yo no tengo el gusto de conocer es Smalltalk como experiencia de trabajo. Aclarado esto voy a poner sobre la mesa algunas cosas basado en mi [no muy larga] experiencia como desarrollador Java.

Lo primero que me llama la atención del post es que hoy en día se confunde la herramienta con el objetivo o dicho en las palabras de Hernán ..."es la confusión del fin con el medio, donde el medio pasa a ser el fin [...] Cuando a gente que estoy entrevistando, le pregunto si saben diseñar utilizando objetos respondan que sí, que saben UML"... fragmento con el que estoy de acuerdo, la idea no esta en saber tal o cual herramienta, sino comprender el concepto y saber aplicarlo de la manera más acertada.

Vamos a lo que quería explayar. Diseño como actividad implica un cierto grado de conocimiento (patrones, arquitecturas, frameworks, limitaciones, etc) y soy creyente de que esta actividad debe hacerse de manera abstracta al lenguaje que estamos usando (siempre que hablemos de OOP). En resumen, diseñar es modelar un problema, relacionar los objetos y determinar su comportamiento para llegar a un objetivo claro (la resolución de un problema). La disyuntiva de diseñar en favor de ciertos cambios (pensando en el futuro) y la de diseñar pensando sólo en el ahora es un tema que puede dar para hablar mas de algunos garabatos que puedo expresar aquí. Pero creo fervorosamente que siempre es necesario contemplar algunos posibles cambios que puedan sucederse. Adivinar el futuro es casi imposible, pero prevenir siempre es mejor que curar y mi corta experiencia como diseñador me ha demostrado que no me había equivocado.

Si bien la documentación como artefacto es mas bién estática, siempre es necesaria. No digo que haya que documentar hasta la última línea de código de la última release, pero si digo que una visión global de lo que tenemos debería formar parte de todo desarrollo, llamenló documentación de arquitectura o un simple diagrama de clases que permita saber donde estamos parados y conocer el contexto de referencia, al menos delinearlo.

Quiero recalcar que estoy de acuerdo en que diseñar no implica tener que hacer un millón de documentos, eso es casi absurdo, pero no concuerdo en diseñar usando el código. Como dije antes, no me parece feliz tener ideas en la cabeza y expresarlas en código de manera directa [tal vez entendí mal]. Mi utopía es tener un gran block anotador, del tamaño de un pizarron, e ir bosquejando las ideas y las iteraciones en reuniones de desarrollo, donde todos podamos ver como el pensamiento se va alineando a la solución definitiva y como cada vez que se quiere solucionar un nuevo problema se pueda ver lo que se hizo y como podemos alinear una solución con la actual. Esto es siempre que estemos hablando de proyectos medianos/grandes que requieren una integración continua. He visto como se hacen cosas mas de una vez y se cometen errores por no tener, lo que Edward De Bono llama "pausa creativa" y es tan simple como pensar (con conocimiento del contexto) como solucionar un problema unos minutos antes de "meter un conejo", "atarlo con alambre", hacerlo asi porque lo demás esta hecho así o porque después refactorizamos. El viejo DRY parece perderse en la falta de conocimiento de una aplicación o más bien en la vorágine de somos "ágiles" y podemos tenerlo para ayer.

No estoy en desacuerdo con TDD, creo que es una gran metodología, pero no me parece que sea absolutamente feliz.

Este post se esta haciendo largo, lo leo y lo releo y no puedo cerrar mi idea... espero se entienda. Me gustó el post de Hernán, es un tema de discusión que me parece apasionante, quería tratar de compartir sus ideas y ponerlas con las mías (tal vez un poco irrespetuosamente).

Hernán ojalá algún día podamos sentarnos a tomar un café y charlar sobre esto, realmente me encantaría ....

Bueno, era esto... les dejo arriba el link al blog, leanló no tiene desperdicio alguno de principio a fin.

Saludos!

elmasse!®

Un segundo de felicidad...

Hace varios dias que vengo leyendo FAUSTO, es una obra increible, desde lo literario con tanto caudal de vocabulario hasta las ideas y pensamientos que refleja. Disfruto mucho leyendo cuando el autor te obliga a saborear cada línea, a leer con paciencia y te va llevando por recónditos espacios de la mente.
Lo que me llama la atención y he aquí el porqué de este blog de hoy, es que el drama faústico se basa en un pacto con el diablo a cambio de un instante de felicidad (nota: no soy quién para opinar sobre esto, no soy un erudito en filosofía y mucho menos en literatura) y recordaba todo esto cuando venía camino a mi casa luego de un día mas de trabajo.
Sobre Rivadavía en Caballito hay un mendigo de varios años, que realmente me da mucha pena cuando lo veo porque podría tener tranquilamente la edad de mi abuelo y eso mueve algunas cosas en mí. El punto es que hoy viví algo mágico, mas allá de las monedas o limosnas que este hombre pueda recibir, hoy lo ví reir y sentirse muy feliz cuando una nena, que no tendría mas de 4 años, se acercó, le dió unas monedas y le dió un beso y ese acto tan simple desbarató en mi todas mis preocupaciones y pensamientos del momento para poner en primer plano justamente eso, lo simple que puede ser un estado de felicidad pura y extremadamente sencilla. Pensaba en Fausto y su drama, pensaba en las cosas que dejamos pasar, aquellas que no vemos porque la vida esta llena de otras cosas que nos quitan lo mágico de los pequeños momentos.
Estos son los pequeños milagros que llenan la vida de los que no tienen nada, mas allá de una moneda. Quiénes tenemos algo no pensamos por lo general en esas cosas y nos preocupamos por acumular cosas que son efímeras e inútiles.

Y nada, era decir esto... alguien dijo una vez "La vida es eso que pasa mientras estamos preocupados haciendo cosas"