Una nueva entrada...

Personas que saben caminar por la vida... No se, es una frase que me marco. Entre las largas y largas horas que muchas veces desperdiciamos viendo la televisión, hay programas que te hacen pensar, o bien, el típico presentador suelta una frase que en gran medida o por lo menos a mi te transporta a un modo de estupor en el cuál tenemos que realizar una mirada introspectiva hacia nuestro ya de por si (por lo menos en mi caso) aburrido interior. 

Y el presentador utilizó la frase de arriba para definir a un colaborador esporádico de su programa. "Una persona que sabe caminar por la vida". Tremenda frase que me dio bastante que pesar, hasta el punto de escribir esta entrada que seguramente se convertirá el un soliloquio. Pero lo que es cierto, es que seguro nos hemos cruzado con personas que tienen ese aura de saber el por qué están en el mundo, personas que saben dónde están sus objetivos y tratan de conseguirlos a toda consta (tarden lo que tarden), e incluso personas que saben vivir y por saber vivir no me refiero a temas materiales o a una vida social multitudinaria, sino personas que entablando una conversación de 5 minutos ya te marcan o te transportan a una realidad muy diferente a la tuya. En definitiva, personas que se divierten con la vida y que les divierte lo que hacen.

Suena como el típico topicazo que nos intentan vender pero cuando vemos que se cumple que existe ese tipo de personas, nos planteamos si queremos seguir haciendo lo que hacemos actualmente o sino que podemos hacer para mejorar poco a poco, por que al fin y al cabo la imagen que damos a los demás es el recurso más valioso que podemos entregar y además no cuesta dinero, al igual que la canción Every minute de JJGrey. Yo quiero ser una de esas personas que saben caminar por la vida.

¿Qué son los WebSockets?

Dentro del ecosistema total que se están convirtiendo los navegadores, las comunicaciones cliente-servidor son uno de los puntos más importantes en cualquier aplicación web. La comunicación de datos entre el servidor y el cliente debe ser lo más rápida y suave posible. Este tipo de comunicación se remonta a los inicios de Internet, pero si vemos los métodos tradicionales encontraremos que eran muy limitados y no las mejores soluciones especialmente a través del protocolo Html, a pesar de que se estaba convirtiendo en un estándar.

Por tanto, cuando se habla de todo lo que rodea a Html5, nos referimos a la búsqueda de soluciones para los problemas anteriores y corregir las limitaciones de Html. Aquí es donde encontramos los WebSockets. Pero antes de profundizar en que son, es mejor conocer los demás métodos de comunicación.

Método petición-respuesta:El cliente hace una petición al servidor y por tanto, recibe una respuesta. Este proceso es conducido por alguna interacción, por ejemplo: pulsar el botón de recargar para actualizar la página web, con lo cual se actualizaba la página entera. Sin embargo, con la aparición de Ajax se permitía actualizar algunas partes de la página y no la página entera.

Hay situaciones en que se pide que los datos sean actualizados por así decirlo automáticamente y no por fuerza del usuario, como por ejemplo: los resultados de un partido de fútbol. Esto es lo que se conoce como Polling. Donde los cambios de datos son buscados en intervalos de tiempo, y se va a mantener buscando en el servidor estos cambios independientemente de si los datos han cambiado o no, esto provoca llamadas innecesarias al servidor, abriendo una conexión y luego cerrándola otra vez. A su vez aparece una variante llamada Long-Polling, en la que el servidor recibe una petición del cliente si no hay cambios en los datos solicitados en lugar de devolver una respuesta vacía, guarda la petición y espera a que haya algún cambio en los datos para enviarlos al cliente o después de un período de tiempo determinado. En ese momento el cliente vuelve a realizar otra petición que se mantendrá de nuevo abierta hasta que haya cambios. Ya depende de la cantidad de datos que nosotros utilizamos un método u otro. Pero aún así mantiene muchas peticiones lo que va a repercutir en el tiempo y en la latencia de los datos.

Por tanto, los problemas con estos métodos nos llevan a una solución los WebSockets, estos solventa uno de los mayores problemas de la comunicación con el servidor proveyendo un puente de comunicación bidireccional Full duplex, provee tanto al servidor como al cliente con la habilidad de enviar datos en cualquier momento, lo que no es posible con los antiguos métodos. Esto no solo mejora el rendimiento sino que mejora la latencia de datos, crea una conexión ligera que puede mantenerse abierta durante un largo periodo de tiempo sin sacrificar el rendimiento. Esto nos da un control completo para abrir o cerrar la conexión en cualquier momento.

Los WebSockets forman parte del estándar Html5, de modo que no necesitamos preocuparnos por añadir plugins extras para hacerlo funcionar. La API WebSockets es completamente soportada e implementada por JavaScript y por tanto prácticamente todos los navegadores modernos soportan los WebSockets.

Estos deben ser implementados tanto en la parte del cliente como en la del servidor. En el lado del cliente la API es una parte de Html5 pero en el lado del servidor necesitamos utilizar una librería que implemente WebSockets. En la actualidad casi todos los servidores soportan la librería API WebSockets y además node.js también soporta la implementación de estos, utilizando algunos paquetes.

Los WebSockets comunican usando la capa TCP la conexión se establece sobre Http y es básicamente un mecanismo Handshake entre el cliente y el servidor, pero después del este la conexión es actualizada a TCP. Este funcionaría de la siguiente forma:

1. Se realiza la llamada http, que es iniciada desde el lado del cliente. La cabecera de esta llamada http sería algo similar a esto:

• Host: Es el nombre del servidor al que estamos llamando.
• Upgrade: indica que es una llamada de actualización. En este caso websocket.
• Connection: define que es una llamada de actualización.
• Sec-Websocket-Key: es una clave generada aleatoriamente, que posteriormente es usada para autentificar la respuesta. Es la clave del Handshake.
• Sec-Websocket-Origin: es otro parámetro, pero en este caso opcional, que muestra donde sea generado la petición. En el lado del servidor es usado para comprobar la autentificación de la petición.
2. Una vez que el servidor comprueba la autentificación va a enviar una respuesta que se ve, así:

• Sec-Websocker-Accept: hay una clave que es comprobada y autentificada con la key enviada para ver que las respuestas están viendo al cliente de origen correcto.
3. Una vez que es abierta la conexión el cliente y el servidor pueden enviar los datos de uno a otro, estos datos son enviados en forma de pequeños paquetes usando el protocolo TCP, así que estas llamadas no son http, por tanto no son visibles directamente dentro de la herramienta de desarrolladores en el navegador por ejemplo.

Quien quiera profundizar en este interesante mundillo, es altamente recomendable visitar la siguiente web, WebSocket.org

Comandos Inkscape Básicos

Hoy quiero hablar sobre un software con el que he estado trabajando ultimamente, este es Inkscape un editor de gráficos vectoriales SVG (Scalable Vector Graphics), estos estan basados en XML. Además el editor es gratuito, libre y multiplataforma. Las características de SVG soportadas incluyen formas básicas, trayectorias, texto, canal alfa, transformaciones, gradientes, ediciones de nodos, exportación de SVG a PNG, agrupación de elementos, etc.

Si alguien a trabajado con Texmaker y algún programa de editor de textos en Latex seguro que lo habrá utilizado, aquí en este post quiero dejar una serie de comandos para que podamos empezar a trabajar desde cero.

Operaciones Básicas:

• Ctrl + Flechas: Para desplazarse por la pizarra.
• Ctrl + B: Para visualizar o/u ocultar las barras de desplazamiento.
• -: Alejar Zoom.
• +:Acercar Zoom.
• Ctrl + N: Crea un nuevo documento.
• Ctrl + Alt + N: Crea un nuevo documento desde las muchas plantillas de Inkscape.
• Ctrl + O: Abre un documento.
• Ctrl + S: Guarda el documento.
• Shift + Ctrl + S: Guardar como.
• Ctrl + Z: Deshacer.
• Mayus + Ctrl + Z: Rehacer.

Herramientas de selección:

• F1 o Espacio: Abre la herramienta de selección. Podemos observar 8 manejadores en forma de flechas con los que podemos mover, escalar. Con otro click mas podemos rotar e inclinar el objeto.
• F4: Para seleccionar una forma rectangular.
• Shift + Click: Seleccionamos múltiples objetos si lo dejamos pulsado.
• Shift + Arrastrar con el Ratón: Selección múltiple.
• Esc: Deseleccionamos cualquier objeto seleccionado.

Transformaciones con los objetos seleccionados:

• Ctrl + >: Escalar disminuir. Si pulsamos solo la tecla < disminuimos pero por pasos, es decir, poco a poco.
• Shift + >: Escalar aumentar.
• Flechas: Desplazamos el objeto seleccionado.
• Ctrl + G: Crear un grupo de objetos.
• Ctrl + U: Deshacer el grupo o quitar un objeto del grupo seleccionándolo.
• Shift + Ctrl + F: Cuadro de diálogo Relleno y Borde.
• Ctrl + F1: Manejador gradiente.
• Ctrl + D: Duplicar un objeto.
• Shift + Ctrl + A: Para alinear las formas con respecto, por ejemplo, a los ejes.
• Home: Llevar el objeto al Frente.
• End: Llevar el objeto al Fondo.
• PGUP: Emerger el objeto solo un paso.
• PGDN: Hundir el objeto solo un paso.
• Alt + Click: Selecciona el objeto superior como un sencillo click, sin embargo, el siguiente Alt + click en el mismo punto seleccionará el objeto de abajo de superior. Esto es muy útil cuando no podemos ver el objeto que este debajo.
• Alt + Arrastrar: Para arrastrar el objeto que está seleccionado ahora sin seleccionar nada más.

Git(III)

Hoy quiero continuar la breve introducción de que hice sobre el funcionamiento de esta herramienta de control de versiones, en este caso centrarme en los comandos que nos van a servir para construir un repositorio Git, para ello vamos a utilizar Git Bash. Para ello vamos a ver como podemos empezar un repositorio:

• $git init: se utiliza para inicializar un repositorio en un directorio en un directorio ya existente. Decir que cuando se ejecuta en el directorio creado , nos crea un archivo oculto .git, este nos provee de una serie de archivos que nos ayudan con el Sistema de control de versiones. Además, debemos tener en cuenta que si no utilizamos git init, el archivo o directorio no se convierte en un repositorio.
• $git add *.c o $git add NombreArchivo: si queremos añadir archivos que hemos creado aparte en Git atendiendo a su extensión o en el otro caso añadir un archivo por su nombre. Debemos tener en cuenta que estos archivos estarían en el staged.
• $git commit -m 'primera versión del proyecto': esta orden la utilizamos para poner un mensaje que nos indica cuando hemos hecho el commit.
• $git clone git://github.com/ o $git clone git://github.com/ migrit: para clonar archivos que hemos creado, u otros códigos de otros proyectos distintos. Con la orden migrit lo que indicamos es que clone el repositorio en otro indicando el nombre. También, para clonar se pueden utilizar diferentes protocolos: git, http(s), ssh.

En referente a los archivos que tenemos en nuestro directorio pueden estar en 2 estados: untracked o tracked.

• untracked (no rastreado): son todos los demás archivos, los que fueran después de haber realizado el commit.
• tracked (rastrado): son los archivos que fueron en el último commit. Estos archivos pueden estar en tres estados: unmodified, modified y staged.

Por ejemplo, si clonamos un repositorio los archivos serían tracked y unmodified, dado que, no hemos hecho ningún cambio. Para que un archivo no sea un archivo tracked, habría que eliminar ese archivo del repositorio. Pero bueno, lo más importante es que para ver el estado de los archivos vamos a utilizar $git status.

Es muy importante saber que guardar un archivo no tiene nada que ver con el control de versiones. Cuando modificamos un archivo, y después lo añadimos, su estado sería modified en el stage (color verde), pero si ahora al modificar ese mismo archivo y lo guardamos. El archivo tendría el estado modified pero no en el stage (color rojo).

Una vez en este punto, voy a intentar exponer un caso que me surgió cuando yo lo probé por mi mismo. Bien partimos desde la posición donde ya hemos realizado el commit, ahora para que podamos tener el archivo en el que trabajamos en GitHub debemos utilizar el siguiente código $git remote add origin git@github.com:tunombre/AprendiendoGit.git, después, $git push -u origin master. Al ejecutar por primera vez esta orden me daba un error a grosso modo, es el siguiente:

Este error indica que la punta de tu rama está detrás de la rama remota, es decir, que hay modificaciones posteriores a tu última sincronización. Rechaza por lo tanto el push, pero ahora bien, vamos a hacer un pull para ver qué es lo que ha fallado, para ello utilizamos $git pull -u origin master. Al hacer esto podemos ver que sale:

Este git pull indica algo así como que el conflicto de fusión no tiene forma de combinar los dos ficheros porque hay cambios en la misma línea. Lo que yo puedo entender, es que hay un problema con los dos master, el que creemos en Git y el de GitHub; por tanto si ejecutamos ahora otra vez $git push -u origin master, lo tendríamos bien. Ahora si miramos el repositorio en GitHub ya lo tendríamos.

Conocimientos Básicos sobre el Color.

Ahora me encuentro enfrascado en un problema sobre el estudio del espacio del color. ¿Cuál es el mejor? ¿Ventajas de unos sobre otros? ¿Para qué se utiliza cada espacio? Muchas preguntas sobre un campo del tratamiento digital de imagen que muchas veces evitamos o no nos preocupamos lo suficiente. Lo que quiero plasmar es parte de un estudio que llevo bastante tiempo haciendo, sobre un vista general de lo que son y nos ofrecen los distintos espacios de color.

En un primer lugar, debemos conocer a que nos referimos con espacio de color, este no es más de un rango de colores definido. El sistema visual humano no es un sensor RGB simple pero se puede aproximar cómo responde el ojo humano al diagrama de cromaticidad CIE 1931 que muestra la respuesta visual humana con una forma de herradura.

Bien es sabido que esta forma sólo es una aproximación el sistema de visión humano, este puede detectar muchos más tonos de verde que de azul y rojo. Esto se debe a como son los responsables de la detección del color en nuestro ojo. Estos son los llamados conos, los cuales se encuentran en la parte de la retina central llamada fóvea. Dentro de los conos hay 3 tipos, un tipo son detectores del rojo, otros del verde y otros del azul. Cada detector no sólo es sensible a su color, sino que tiene una pequeña detección alrededor de ese color. Por ejemplo el detector de verde se estimula principalmente con la luz verde, y conforme nos alejamos del verde (hacia el azul o rojo) va perdiendo capacidad de detección rápidamente.

Así pues si en una luz verde provoca un estímulo del 100% sobre el detector verde, una luz amarilla o naranja provoca un estímulo de un 30% y la luz roja o azul provoca un estímulo de un 5%. Sobre el cono del rojo ocurre lo mismo, si se recibe una luz roja, provocará un estímulo del 100%, una luz naranja lo hace del 30%, una luz verde de un 5%, y una luz azul del 0% pues el azul está muy alejado.

Con esto lo que quiero decir es que para el verde están enviando señales todos los conos, mientras que para el resto de los colores no todos envían señales. Por eso puedo decir que el ojo es más sensible al verde, que a los otros colores. Visualmente podemos verlo en la imagen de abajo.

Para profundizar un poco más en esto y dejar una referencia muy básica sobre la mezcla de colores, aquí aparecen, dos tipos de mezclas:

• Mezcla aditiva: mezclamos los colores primarios RGB. Este sistema lo utilizan los gráficos por ordenador, o diversos sistemas de representación por pantalla.
• Mezcla sustractiva: mezclamos los colores secundarios CMY. Este por ejemplo es el sistema que utilizan las impresoras.

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.