Source Rebels

Estos son algunos de los atajos de teclado que me facilitan un poquito más el día a día cuando utilizo Eclipse para escribir código Java. No he querido abusar por que los considero bastante engorrosos de aprender pero si te interesa esto siempre puedes pulsar Ctrl+Shift+L e indicarme tus preferidos

Ctrl+Alt+H – Mostrar la jerarquía de llamadas de un método

Si presionamos esta combinación de teclas se nos mostrará una pantalla donde, a modo de árbol, podremos inspeccionar toda la jerarquía de llamadas de un método, esto es, qué otros métodos le llaman, que otros métodos llaman a estos últimos y así sucesivamente. Haciendo click en cualquiera de los resultados, abriremos un editor directamente en el código.

Alt+Shift+P – Abrir fichero Maven pom.xml

Esta combinación de teclas sirve para buscar el fichero pom.xml de cualquier artefacto tanto en el workspace como en cualquiera de los repositorios maven2 que tengamos definidos.

Nota: Si no me equivoco, esta combinación sólo está disponible si utilizas el plug-in de integración de Apache Maven 2 m2eclipse.

Ctrl+Shift+G – Buscar texto en workspace

La siguiente combinación de teclas permite buscar rápidamente el texto seleccionado en todo el workspace. La ventana de resultados sería similar a esta.

Ctrl+Shift+R / Ctrl+Shift+T – Abrir recurso / Abrir tipo

En el caso de Ctrl+Shift+R Muestra un cuadro de dialogo donde podemos teclear un texto y que permite filtrar rápidamente un fichero de los proyectos que tengamos abiertos en ese momento en el workspace. El funcionamiento de Ctrl+Shift+T es similar al de Ctrl+Shif+R sólo que en este caso podemos abrir tipos de Java únicamente.

Nota: Abrir tipo funciona únicamente, al menos a mi, en la perspectiva Java o J2EE

F4 – Mostrar la jerarquía de un tipo

Sitúa el cursor sobre un tipo en un código Java, pulsa F4 y te aparecerá una pantalla (en mi configuración de Eclipse la de más a la izquierda). Esta pantalla permite ver la jerarquía de herencia de una clase Java (parte superior) así como la lista de propiedades y métodos de la misma clase (parte inferior).

Artículos, Best-Practices, Eclipse, Java, Tools Artículos, Best-Practices, Eclipse, Java, Tools

Últimamente ando bastante engorilado con Git, por lo que este post pretende ser una introducción muy rápida de las cuatro cosillas que estoy aprendiendo sobre este VCS estos días. En siguientes entradas, o lo que es lo mismo sólo $DEITY sabe cuando, muy probablemente escribiré como montar un repositorio Git utilizando el servicio gratuito ofrecido por github.com.

En primer lugar indicar que Git es un sistema distribuido, a diferencia de por ejemplo Subversion o CVS que son centralizados. Esto para nosotros qué quiere decir? Básicamente que no trabajamos con una copia local del código fuente sino con una copia local o clon del repositorio original, más conocido como “master”.
Las ventajas más importante de trabajar de esta forma, siempre bajo mi punto de vista, son que disponemos de todas las utilidades propias del VCS sin ni siquiera tener que estar conectado a una red. Muy útil para acceder al historico de modificaciones de un fichero, comparar versiones, hacer un commit o cualquier cosa que hagas normalmente con tu VCS desde un sitio donde no dispongas de conexión.

Git define también 5 tipos de objetos alguno de los cuales nos serán familiares si hemos trabajado con un VCS antes:

• Blob: El contenido de un fichero gestionado por Git e identificable por el Hash SHA1 que se obtiene del dicho contenido.
• Tree: La estructura del repositorio en un momento determinado (normalmente un commit). Un objeto de tipo Tree tiene N objetos de tipo Blob asociados.
• Commit: Una “foto” del repositorio una vez se han introducido una serie de cambios. Un objeto de tipo commit tiene 1 objeto de tipo Tree asociado.
• Tag: Una etiqueta, normalmente sirve para marcar objetos de tipo commit.
• Índice: Imagen de los cambios que se aplicarán al repositorio en el siguiente commit. En Git, por defecto sólo aplican aquellos cambios que se encuentran reflejados en este índice (están STAGED).

Git a diferencia que otros VCS como Subversion no almacena únicamente los cambios de un fichero sino que almacena el contenido completo de cada revisión. Esto sumado a la forma de trabajar que tiene con los objetos que indiqué antes hacen que en general el funcionamiento de Git sea muy ágil y, bajo mi punto de vista, mucho menos susceptible a error (piensa que cada vez que le pides una revisión en concreto, Git no debe “montarla” sólo “localizarla”).

Sólo por estas cosillas, ya comienzo a estar tentado de cambiar. ¿Habeis trabajado con Git o similar? ¿Qué os parece? ¿Cambiaríais vuestro Subversion/CVS?

Por cierto el libro que estoy leyendo es “Version Control with Git” de la editorial O’Reilly Media por si alguien quiere echarle una leída.

Artículos, Code, Git, VCS Artículos, Code, Git, VCS

Unsorted list:

• If you use a versioning control system, spend some time learning its basic usage (checkout, checkin, update, diff, merge, …). If you don’t use it, go quickly to get one. Im currently using svn and git.

• Don’t be scared about refactoring your code.

• Write your own documentation. Document your work for your personal profit. While you are documenting and organizing you are thinking in your job by looking it from a different point of view. Think in documentation like in a software-piece, it must be useful and reusable.

• Constantly, try to improve your knowledge about every day tools usage by knowing its internals (keyboard shorcuts or processes) or just learning from your colleages (or Internet users) usage.

• Write automated tests and execute it. You can use continuous integration for doing the job. I like the Hudson CI server.

• Don’t be IDE-dependent for your compilation, use scripts or tools specifically designed for this task. Actually Maven will be my first choice because Java is my main plattform.

• Get feedback about your code. Show them into colleagues or use communities like StackOverflow.

• Learn what KISS and Convention over configuration means. Be aware about overengineering.

• Don’t try to write your own framework or libraries for later use. Learn writing it  if you want, but use well-known community libraries or frameworks. I personally work mainly with Spring Framework and Apache commons.

• Backup your data. Use your own/preferred method. I personally like dropbox.

• Most important. Don’t try to acomplish all of this at same time. Just be patient and

Please, feedback

Best-Practices, Code, HowTo, Java, Tools Best-Practices, Code, Java