Git (II)

Voy a continuar el post que abrí hace una semana sobre el sistema de control de versiones Git. Por tanto, hice un primer acercamiento a este y aquí continuo, con más información de este interesante campo :-D

En Git casi todas las operaciones son locales, por tanto no es necesaria información de otro ordenador, para poder trabajar. Dado que nosotros tendríamos toda la historia del proyecto, en el propio disco local lo que nos permite que las operaciones se hagan de manera instantánea y están siempre accesibles. Por ejemplo, si queremos ver los cambios introducidos entre la versión actual de un archivo y ese mismo archivo en dos versiones anteriores, Git puede ver esas dos versiones y hacer un calco de las diferencias, pero a nivel local. Por tanto, es muy poco lo que no podemos hacer si estamos offline.

Una de las características mas importantes de Git, es el cuidado que tiene con el mantenimiento de la Integridad de Datos. Git se va a encargar siempre de llevar una verificación estricta de la calidad de los datos, antes de guardarlos lo que se conoce como checksum, que sería una forma de control de redundancia para proteger la integridad de los datos. Así evitamos problemas con archivos corrompidos. Esta forma de verificación es llamada SHA-1, este es un String compuesto por 40 caracteres hexadecimales, estos valores los veremos multitud de veces en las verificaciones de Git.

Otra de las características fundamentales de Git es que Las acciones que se hacen en este son siempre Modificables. Es muy complicado hacer algo que provoque la eliminación de datos o que sea inmodificable. Por tanto después de hacer un commit es muy difícil perder datos. Para quien no conoZca el término Commit sería algo así como convertir algo temporal en permanente, es decir, guardar nuestro trabajo cuando estamos trabajando en el.

Los tres Estados de Git:

• Commited: Los datos estarían salvados de modo seguro en nuestra base de datos local. Directorio git (Repositorio).
• Staged: Aquí podemos ir colocando archivos que serán enviados cuando se haga el próximo commit, por tanto podemos eleguir nosotros cuales archivos formarán parte del próximo commit que llevemos acabo. Stagin area. Este consta de un único archivo, conocido como index, aunque también se puede ver como area staging.
• Modified: Hemos cambiado los archivos pero no lo hemos salvado de ningún modo. Directorio de trabajo.

Para descargarnos Git podemos hacerlo desde git-scm.com

MEAN STACK

Hoy quiero hablar sobre MEAN STACK y la omnipresencia de JavaScript en el desarrollo de aplicaciones web plasmada en este stack. En primer lugar, podemos enunciar que significa este acrónimo MEAN, que no es mas que las siglas de MongoDB Express AngularJS Node.JS. Hacemos un recorrido desde el cliente al servidor pasando por la base de datos y lo mejor de todo con el mismo punto en común. Desarrollo end-to-end usando sólo JavaScript tanto en el forntend, backend y la base de datos. Tiene buena pinta, ¿no?

Para quien sea novato como yo en esta tecnología, quiero enumerar de manera sencilla para que se utilizan las diferentes herramientas que he puesto antes:

• MongoDB:Es la base de datos.
• Express:Es el framework server web.
• AngularJS:Es el framework web cliente.
• Node.JSEs la plataforma del servidor.

Este sistema responde a una arquitectura de tres niveles, que es la más conocida:

• Capa de datos: Base de datos.
• Capa de lógica: Servidor.
• Capa de presentación: Cliente.

No obstante esto con una arquitectura de software moderna para el desarrollo web, lo podemos ver de esta otra forma:

• Base de datos.
• Interfaz de usuario del cliente.
• Lógica del servidor.
• Lógica del cliente.

Por tanto aquí surge el paradigma MVC (Model View Controller):

• Model: Encargado de la manipulación de datos, es el encargado de responder a las peticiones de información.
• View: Es la parte visual de interacción con el usuario.
• Controller: Responde tanto al sistema como a los eventos de usuario, haciendo que el model y la view cambien de modo correcto.

Este stack es muy sencillo de utilizar teniendo en cuenta una serie de paquetes que hay que instalar, por tanto aquí aparecen dos stack para poder trabajar con el MEAN.IO y MEAN.JS. Esencialmente ellos son lo mismo, usan karma and mocha para tests, grunt con livereload, passport integration... Con esto quiero decir que son similares dado que Mean.js es un fork of Mean.io y ambos fueron empezados por la misma persona. Mean.io esta ahora debajo del paraguas de la compañía Linnovate. Entonces pues el tipo que lo desarrollo para la colaboración con esta compañía y empezó aparte Mean.js. No obstante, son iguales pero hasta un punto, este sería:

• Scaffoldin: Mean.io usa una herramienta command line (cli), llamada mean. Mientras, Mean.js usa el conocido Yeoman Generators.
• Modularidad:Mean.io usa unos modularidad de node packages más independientes con los archivos del cliente y servidor que estan dentro de los módulos.Mean.js solo utiliza módulos en el front-end(para angular), y los conecta con Express.
• Documentación:Mean.io tiene buena documentación. Mean.js tiene una sorprendente documentación, esta la podemos ver meanjs.org, además recomiendo leerla.
• Comunidad:Mean.io es claramente ganador y crece más rápido. Mean.js tiene poco movimiento aunque es bastante nuevo, por tanto es comprensible. Personalmente, me quedaría con Mean.js, por su amplitud principalmente.

Si alguien quiere profundizar más en este hilo, se puede encontrar más información stackoverflow.com

Interfaz Gráfica Java

Recordando los inicios y retomando mis códigos en java, me encontré con un problema que tuve que resolver hace tiempo, como poder mejorar la interfaz gráfica que utiliza WindowsBuilder por defecto. Hay unas cuantas opciones para mejorar esta interfaz un tanto básica, y que quede con un aspecto bastante visual. Las opciones que tenemos o por lo menos las que yo pude encontrar son:

• Nimbus: en inglés una definición resumida sería: Nimbus is a polished cross-platform look and feel. Traducido, mas o menos quedaría algo como: Nimbus es un abrillantador multiplataforma con una interfaz gráfica amigable. Es para mi el que mejor queda y por tanto el que mas utilizo. Una imagen de como se vería con unos cuantos botones:
  
• Metal: este es el tema por defecto con que nos obsequia Java (Metal) Look and Feel, este a su vez nos presenta 3 Theme:
• DefaultMetal, este se ve así:
  
• Ocean: este es un poco mas suave que el puro Metal look. Y es el tema por defecto mas utilizado. En esta imagen podemos ver un ejemplo de este tipo de temas:
  
• Test.

Para poder usar estos estas, podemos crear por ejemplo una sencilla función como esta:

public void interfaz(){

try {

UIManager.setLookAndFeel("com.sun.java.swing.plaf.nimbus.NimbusLookAndFeel");

} catch(ClassNotFoundException e){

e.printStackTrace();

} catch (InstantiationException e) {

e.printStackTrace();

} catch (IllegalAccessException e){

e.printStackTrace();

} catch (UnsupportedLookAndFeelException e){

e.printStackTrace();}

}

Con este sencillo código probamos Nimbus.

Control de Versiones Git y Github (I)

Cuando nos encontramos desarrollando un proyecto nosotros tenemos una Versión, este es el estado en el que se encuentra el proyecto en un momento concreto. Un buen desarrollo de un proyecto debe poder recuperar versiones que hemos guardado anteriormente, para así poder prevenir errores futuros o permitirnos regresar a versiones anteriores. Con el Control de Versiones nosotros vamos registrando los cambios que hemos realizado en el proyecto. Sistemas de Control de Versiones estos son programas que nos facilitan esa gestión de versiones encargándose de administrar esas versiones. En el mundo de la informática se ha expandido mucho, pero también es aplicable a cualquier otra tarea.

Existen muchos sistemas de control de versiones entre los más conocidos tenemos a: CVS, Mercurial, Git. Aquí hablaré de Git el sistema de control de versiones distribuido. Aunque todos estos sistemas tienen una serie de características en común:

• Modos de almacenamiento de la información: archivos de texto, documentación...
• Posibilidad de cambios: añadir, borrar, renombrar...
• Registro Histórico.
• Crear Informes.

Existen dos tipos de control de versiones:

• Centralizados: tienen un repositorio centralizado de todo el código con un único administrador, esto facilita mucho las tareas administrativas pero reduce mucho la flexibilidad, ya que todas las decisiones importantes necesitan la aprobación del responsable. De este tipo sería: CVS.
• Distribuidos: en estos cada usuario tiene su propio repositorio, no es necesario tomar decisiones centralizadas, ya que los distintos repositorios pueden intercambiar y mezclar revisiones entre ellos. De este tipo es: Git.

Git fue diseñado especialmente por Linus Tolvarlds que buscó la eficiencia y la confiabilidad del mantenimiento de versiones de aplicaciones. Este sistema convierte cada uno de los clientes, cada uno de los ordenadores que esta participando en el proyecto en un auténtico espejo o mirror, que guarda todo el repositorio. Así que si cualquiera de los repositorios que forma parte del proyecto muere, estos sistemas que están colaborando entre ellos, nos pueden devolver la información. Su principal motivo radica, en que permite crear diferentes grupos de personas, trabajando de diferentes modos pero respetando la coordinación y siguiendo el trabajo de modo simultáneo. Git almacena y trata la información de una forma muy diferente al resto de sistemas centralizados, este crea panorámicas completas y no solo las diferencias entre versiones. Para explicarlo, Git piensa en los datos como fotos fijas de un mini sistema de archivos, dado que cuando salvemos un estado del proyecto en Git, este básicamente lo que hace es una imagen fija de como se ve todos los archivos del proyecto en ese momento y almacena una referencia a esa imagen.

Github es un servicio de hosting basado en la web para proyectos de desarrollo de software que utliza Git como sistema de control de versiones. Servicio en la nube, completamente integrado con Git, sin embargo, no es esta su única cualidad sino, además nos permite tener: cualidades de redes sociales como feeds, seguidores. También, información estadística y gráfica del proyecto.