Mi cursada - UNQ‎ > ‎Clases‎ > ‎Bitácoras‎ > ‎Bitácoras 2011 S1‎ > ‎

Jueves 17/03/2011

publicado a la‎(s)‎ 18 mar. 2011 15:34 por Javier Fernandes   [ actualizado el 18 mar. 2011 15:46 por gisela decuzzi ]
La idea de la clase era configurar y armar el entorno de trabajo con todas las herramientas necesarias.
En el transcurso de eso nos encontramos con el problema de la baja tasa de transferencia de internet, asi que tuvimos que improvisar un eclipse ya empaquetado con los plugins: subclipse y maven.

Para esto vimos algunas cositas de linux que mencionamos acá rápido, pero los invitamos a buscar en google por más info al respecto:
  • linux es "case sensitive" que quiere decir que dos archivos (o carpetas) no son iguales si sus nombres tienen mayúsculas o minúsculas diferentes.
  • sudo permite ejecutar comandos en modo "super user". Los comandos que instalan cosas como el apt-get requieren ejecutarse de esta forma.
  • apt, de aptitude es un sistema de gestion de paquetes de las distribuciones basadas en debian, como ubuntu. Básicamente sirven para manejar el software en linux, sin necesidad de tener que bajarse el código fuente (en C) de los programas y compilarlos a mano. Para esto se conecta a repositorios públicos en internet, y baja versiones ya compiladas y empaquetadas.
  • chown: de "change owner" sirve para cambiar el usuario propietario de una carpeta o archivo en linux.
  • chmod: sirve para cambiar los modificadores de permisos de los archivos, por ejemplo para darle permiso de ejecución a todos los usuarios "chmod a+x", donde "a" es de "all" (para todos los usuarios) y "x" es "ejecución".

Instalamos entonces un JDK, Java Development Kit.

Para refrescar la memoria:
Java es un lenguaje compilado, que se basa en el concepto de "máquina virtual". A diferencia de C, a partir del código fuente, el compilador de java, genera como output un formato de archivo binario intermedio llamado "bytecode". Este formato es independiente del sistema operativo. Por esto es que se dice que java es "portable", porque un programa compilado puede ejecutarse 'así como está' en cualquier sistema operativo.

Y cómo hace para esto ? Bueno, el bytecode es standard, pero solo lo sabe entender un segundo programa, que es una parte de java, llamada Java Runtime Environment (JRE).

Entonces java tiene dos partes (simplificando muchísimo): un compilador "javac" y un comando para ejecutar los programas compilados "java" (el bytecode).

A esto se lo llama VM, máquina virtual. Y existe una VM, o un JRE para cada sistema operativo, porque la VM sí que tiene cosas nativas.
Entonces, tus programas son portables, pero para eso necesitan de una VM que es dependiente del sistema operativo.

En lugar de hacer tooooodos los programas dependientes del sistema operativo, solo "java" es dependiente y el bytecode actua de lenguaje intermedio compatible con todas las VMs para que vos puedas compilar una sola vez para todos los sistemas operativos.

Un JRE solo contiene la parte de java para ejecutar programas ya compilados (bytecode). Es decir, solo con un JRE no se pueden programar aplicaciones java.

En cambio el JDK, sí trae el compilador junto con todas las clases que vienen por default en java, su código fuente, etc.

Nosotros entonces usamos un JDK.
Este fue el que algunos instalaron con "sudo apt-get install sun-java-jdk6" (o algo así), y otros instalaron manualmente a partir del paquete "jdk***.bin"


Eclipse.

El eclipse a su vez está hecho en java. Así que para que corra, tuvimos que configurarlo para que encuentre el ejecutable "java" del jdk que instalamos previamente. Esto se hace editando el archivo "eclipse.ini" con el parámetro "-vm PATH_A_BIN_JAVA", o con la variable de entorno "JAVA_HOME".

Maven.

Maven es algo parecido al concepto de sistema de paquetes que vimos antes con "apt".
Las aplicaciones java son un conjunto de clases, y para distribuirlas se generan archivos de formato zip, con extension ".jar" (aunque a veces para otros casos específicos se generan otros paquetes).
Es muy común en cualquier aplicación utilizar clases de librerías externas, de frameworks, etc.

Anteriormente, uno debía bajarse esos jars a mano de internet, del sitio del "fabricante", por ejemplo de apache, de jboss, etc.
Y manualmente configurar el proyecto en su IDE, en nuestro caso eclipse, diciéndole que nuestro proyecto usa esas librerías.

Esto traía muchísimos problemas, como ser:
  • Concepto de Proyecto y de Dependencias:
    • Java no tiene, por default un concepto de "proyecto", lo que ustedes ven al crear un nuevo proyecto en eclipse, es puramente un concepto de eclipse. (Vean el     archivo ".project" que deben tener sus proyectos.
    • Con las dependencias pasa lo mismo.
    • Entonces, ambas cosas son dependientes del IDE. Y hay muchos IDEs: eclipse, netbeans, IntelliJ IDEA, JDeveloper, etc, etc. etc
  • Versionado y download:
    • En un equipo de desarrollo puede llegar a haber muchísimos programadores.
    • Si cada uno tiene que bajarse cada libreria, eso podría ser crear inconsistencias (hay muchas versiones de una misma libreria)
    • Además de que cada desarrollador bajaría a su máquina muchísimos jars de internet.
  • Dependencias transitivas:
    • Muchas veces al querer usar una librería (jar) resulta que ese jar también depende de otros jars. Esto se llama dependencia transitiva.
    • En un proyecto normal, se terminar generando un arbol de dependencias que podría ser bastaaante complicado. Si uno tiene que bajar manualmente cada libreria, puede llegar a ser un infierno. Además de que, como no había una forma estandar de que cada libreria defina sus dependencias, uno podía encontrarse que quería usar una librería pero no sabía la version de sus dependencias, y no es lo mismo usar "commons-collections 1.0" que usar "commons-collections 3.1". Seguramente nada funciona.

Entonces, en maven, surge la idea de agregar un concepto único y estandar de definición de "proyecto".
Entre otras cosas permite identificar un proyecto unívocamente a través de: groupId + artifactId + version
Y permite definir las dependencias con eso ID completo.
Tambien soporta dependencias transitivas.

Básicamente, hace todo el trabajo sucio de conectarse a repositorios en busca de los jars y todas las dependencias (incluso las transitivas).
También nos permite publicar nuestros propios artefactos a terceros.


Otra herramienta que vamos a usar es "Subversion"

Es un sistema de control de version (VCS). Sirve básicamente para compartir código, publicándolo en un servidor central. Los programadores pueden entonces checkoutear (bajarse) el código a sus propias máquinas, hacer cambios localmente, y publicarlos a las demás personas, haciendo "commit" (subiendo sus cambios al servidor).
A todo esto, el subversion va guardando todos los cambios, y un historial de estos mismos. Permitiendo volver atrás ante cambios, comparar diferentes versiones, etc.

Por último, vimos que los autores de java.util.Date son:
  • James Gosling (que se dice "padre de java")
  • Arthur van Hoff
  • Alan Liu
Y que ambos deberían cuidar su vida si creen en el concepto de "karma" ;)

Tareas:

  • Programar el dominio de la agenda.
  • El lunes vamos a ver excepciones para poder tener buenos testcases sobre el dominio para el Martes 31/03.


Comments