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/
Showing posts with label desarrollo. Show all posts
Showing posts with label desarrollo. Show all posts
May 30, 2009
May 3, 2009
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
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.
Mar 14, 2009
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
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
Oct 12, 2008
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:
So, nice! don't you think? The problem that I found was into a for sentence, doing something like this:
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!
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;
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 ...
}
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!
Aug 27, 2008
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!
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!
Apr 14, 2008
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
Feb 9, 2008
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...
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...
Jan 25, 2008
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!®
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!®
Subscribe to:
Posts (Atom)
