martes, 5 de septiembre de 2017

Al final no escribir en este blog.

Sé muy bien que hago un articulo anual, o cada dos, o que bien, ha pasado a mas, el caso es que desde principios de diciembre del 2016, empece a escribir manuales de las cosas que hacia en el trabajo, y por manuales me refiero a notas sin sentido sobre cualquier cosa, en especifico, sobre mis servidores y algunas cosas como mejoras en el código de x o de y proyecto. El problema es que el primero de agosto, tuve que tomar unas vacaciones forzadas gracias a un conductor con la inteligencia de una bacteria, y pasaron 29 días antes de que pudiera ver mi brazo y no una copia barata de la momia. Y de ahí, tratar de mover el brazo con decoro, que tampoco ha sido mucho avance.

En este ínter, hice dos pruebas, que no se han molestado en revisar las personas que lo pidieron, y tampoco es como que sea para tanto que no lo hagan, igual ya esta en mi repositorio personal y eso me basta y espero, me sobre. Pero entonces, decidí empezar a escribir, pero dado a que soy un desastre con los formatos, lo hice en markdown, por que me es mas fácil y por que soy un flojo para usar otra cosa que no sea vim. Y por que vim, se estarán preguntando, si hay otros editores mas chulos como atom o sublime text (No, sublime no existe y jamas existirá!). La culpa principal es de mi amigo Hector (chinos), que escribe código en vim y a un viejo amigo que usaba emacs, pero yo soy lo suficientemente marica para no usar emacs. Y ya esta.

Pero he estado hablando mucho y no les he dicho nada. Esta serie de manuales se me ha ocurrido la idea de hacerlos en markdown, y al no tener algo a la mano como redmine para vaciarlos y no tener que trascribirlos y darles el formato que merecen y no se darles aquí, decidí subirlos a mi repositorio de github.

No sé si sea mas frecuente que escriba ahí o aquí, y aquí esta visto que el próximo articulo vendrá en dos años, en uno si bien me va.

Pero por ahora los dejo.

Con amor Uetiko.

domingo, 22 de noviembre de 2015

PHP 7 o lo que es lo mismo: renuevate o jodete.

PHP 7 esta  la vuelta de la esquina y esta vez no ha sufrido el terrible destino que su versión pasada, si, nos referimos a php 6 que al igual que perl 6, vio su muerte debido a discusiones internas y falta de claridad con las cadenas Unicode, o eso es lo que salieron a decir en su momento. Y es que php 7 desde su anuncio vino acompañado de promesas muy llamativas en cuanto a rendimiento y mejoras en su sintaxis que si bien ya habíamos visto de la mano de Hip Hop y Hack de Facebook, el grupo de php (A.K.A. los amigos de php) por fin abrieron los ojos para darse cuenta de las necesidades reales que muchos programadores ya pedían a gritos.

Internet nació en los primeros años de los 70's conocida en esos entonces como ARPANET y para 1990 ve la luz world wide web. En esa época en la que la naciente web estaba aun en pañales y el contenido era mayoritaria mente estático los únicos rasgos de dinamismo llegaban un par de años mas tarde de la mano de los applets de java y de Netscape subiéndose al tren del mame con javascript, nombrado así por la popularidad de java y que dio paso a al estándar ECMAScript que salio dos años después, en enero de 1997.

PHP fue creado originalmente por Rasmus Lerdorf en el año de 1994, programador por aquellos días de perl, y que cansado de la forma en que dicho lenguaje trataba los datos, baso su trabajo en unos CGI's escritos en C y un año mas tarde anuncio Personal Home Pages Tools (PHP Tools). Años mas tarde, Andi Gutmans y Zeev Suraski del Instituto tecnológico de Israel reescribieron el analizador sintáctico y el de Personal Home Page Tools cambio de nombre al acrónimo recursivo PHP Hypertext Pre-processor. Así es como en Junio de 1998 salio a la luz PHP3, para que un año mas tarde, estos dos reescribieran el código para crear en actual interprete llamado Zend Engine y de paso, formar la compañía Zend Technologies en Israel.

PHP es un lenguaje de scripting débilmente tipeado que se ejecuta del lado del servidor y que se ha denominado como la herramienta mas rápida y sencilla para crear paginas web dinámicas, y no era para menos, si fue creado con este propósito. Para mediados del 2004, salio Zend Engine II con un montón de mejoras, como un soporte para el modelado de objetos que hasta ese momento era extremadamente rudimentario y que lenguajes como java y javascript ya tenían; de igual forma se incluyo soporte nativo para Mysql, XML, SOAP, un mejor manejo de excepciones y mejoras en el rendimiento que le hizo mucho bien, por que ya era mucho dolor de cabeza tener que abrir una pagina y darnos el tiempo de ver un capitulo completo de dragon ball y prepararnos un café antes de poder leer algo en la web (Bueno, no era así, pero casi). Y así es como php4 pasaba a su reluciente versión 5.

Pero la cosa no paro ahí, por que se planeo la version 6, con mejoras aun mayores con el sueño de llegar a tener lo que hasta el momento tenia perl y que también planeaba su salto de 5 a 6, pero que después de unos años mejor decidieron cancelar. Algunas de estas mejoras del borrador salieron en php 5.3 y 5.4. Entre ellas fueron los namespaces, Closures, goto (Por dios, alguien aun quiere usar eso, ni c lo quiere), Garbaje Collector algunas librerías y mi favorito, los Traits, que aun algunas personas nos lo quieren vender como multi-herencia y no como lo que es en realidad, un modulo de extensión. Ruby ha llevado mejor esta definición con sus módulos que es básicamente lo mismo y hay una extensa explicación de ellos en su pagina oficial.

A finales de la decada de los 2000's algunos se preguntaban como diablos Facebook lograba mantener su servicio en linea con la cantidad de llamadas que servian, y es que ni ls pruebas mas osadas sobre Zend Engine lograban tal nivel de eficacia en el rendimiento, fue así como los chicos de Facebook a principios de año del 2010, levantaron la mano diciendo que habian reescrito el stack de ejecución de php y que de paso, ahora compilaban PHP, si, ya se que a mas de uno nos dio risa y aseguramos que escribieron el blog en estado etílico o creían que era el día de los santos inocentes. Aun así, Haiping Zhao, Arquitecto de servidores de Facebook, nos dijo que le llevo dos años junto a un pequeño grupo de ingenieros optimizar php y aunque esperábamos que esto diera como resultado un nuevo interprete, la realidad es que esos dos años dieron salida a una maquina virtual la cual liberaron como código abierto. Esta belleza transformaba en sus inicios el código en php y lo pasaba a c++, con lo cual ahora nos hacia sentido que ellos mismos declararan que compilaban php.

Pero la cosa no paro ahí para los chicos de Facebook, ya que para enero del 2014 volvieron a levantar la mano con el anuncio de Hack, un lenguaje de programación basado en php al que ellos llamaron php de modo estricto y que corría bajo su maquina virtual. Este nuevo lenguaje trajo bastantes novedades como el uso de tipeado dinámico (ya conocido en php) como el tipeado estático, hacer que las funciones regresaran ahora un valor especificado dejando de lado los famosos mixin return, nuevas clases para colecciones muy al estilo de java, mejoras a los Closure, lambdas y clases genéricas, que si bien no es algo nuevo en el mercado ya que java y C# ya los tenían, si es algo que muchos programadores de scripting aun desconocen por completo.

Aun así eso parecía no impactar al Engine actual de php hasta que algunos osados vieron pasar de este interprete de php a hiphop o recomendarlo, como en el caso de laravel que te ofrece una maquina virtual ya lista para que la corras y disfrutes de programar en php, pero que corre bajo HHVM (Hip Hop) y no Zend Engine. Ese mismo año, Wikipedia anuncio pruebas para cambiar a HHVM y en febrero del 2015, en el blog de Hack lang se anunciaba que wikipedia había migrado por completo a HHVM y que era compatible con php 5.x teniendo una capa de compatibilidad con Zend, diciendonos además que si pensábamos migrar a HHVM, pero que si dependíamos de algunas extenciones nativas, podíamos usar la librería Lua para el manejo de estos errores.

Esto no tardo en hacer ruido dentro de php, que este mismo año anunciaron el desarrollo de PHP7 prometiendo que ahora si quitarían las librerías que por años solo permanecían depreciadas y que como cualquier tía con buen rollo nos decían que era malo usarlo, pero que nos los dejaba ahí por si teníamos la necesidad de usarlos si no teníamos de otra... como algún código legado o nos daba mucha pereza aprender cosas nuevas. También nos trae mucha azúcar sintáctica, un uso de array en constantes que bien puede ser la emulación de los enum de Hack. Como ya se los había dicho, y eso es algo que debe de alegrarnos a todos, usemos el Engine o HHVM, y es que de seguir por este camino, pronto podrán volver a la reunion de amigos programadores y no sufran de bulling por decir que programan en php, a menos que solo usen wordpress y sepan mas de teoría del color que de patrones de diseño, ahí si, nadie podrá ayudarlos en realidad, ni sus novias o novios que tantos los aman.

No sé si es tarde o temprano, pero me alegra que por fin Zend y compañía se dieran cuenta que era necesario evolucionar y pelear en esta revolución donde los bandos están definidos y no importa cual sea el ganador, siempre y cuando nos dejen algo de calidad y si, que nos obliguen a hacer mejor las cosas, como programar o usar sistemas escalables, hablo de mejores estándares que no solo se queden en deberías usar, o buenas practicas como recomendaciones. Queremos sangre, queremos dolor, queremos tirar mejores lineas y que nos dejen de ver como un par de autistas a los que se les arrojen un pan duro para que juguemos con el y dejemos de molestar. Que por fin nos dejen de hacer bulling por usar este lenguaje, no queremos llevar a todas partes algo que no sirve o que medio haga las cosas, queremos simplemente llevar algo que no sea de utilidad a nosotros y a todos los demás, que para eso es código abierto, para que entre todos mejore, por que como bien lo ha dicho nuestro tirano favorito Torvalds: "Mientras mas ojos miren, mas rápido saldrán los errores"

Hay un largo camino y PHP7 aun esta en sus RC y si, hay que admitirlo ahora que nadie nos mire, Facebook es php lo que Google para python. y ustedes ¿Qué opinan?

Happy hacking!



martes, 28 de julio de 2015

Git. Firmando tu trabajo.

En algunos post anteriores ya había hablado de git, de criptografía y de como generar un par de llaves. Y es que cuando hablamos de trabajo en equipo y la autenticidad y no repudio de la información, un commit con tu nombre no es suficiente a veces, y por ello git nos ayuda en estos casos. Pero no solo para firmar commits, si no para crear tags y poder asegurar la integridad del trabajo del día a día.

Primero, y debemos aclarar, debemos generar un par de llaves con el siguiente comando.

gpg --gen-key

O si ya tienes unas generadas, listar para poder sacar el id de la llave que vamos a usar para poder firmar con git.

gpg --list-keys 
/home/uetiko/.gnupg/pubricng.gpg 
--------------------------------------
pud 2048D/CA5B3485 2014-07-05
uid                                         Uetiko
sub  2048C/EF7A4E93 2014-07-05

Ya con esto, le decimos a git que id va a usar (en caso de que tuvieran mas) para poder firmar tags y commits.

git config --global user.signingkey CA5B3485

Recuerden usar tanto para tag -s como para commit -S que es la opción que usa el correo y la llave que le hemos dado a git por default.

Supongamos que vamos a hacer un tag para la versión estable 1.0, la que contiene muchos logros y sacrificios de todo el equipo.

git tag -s v1.0 -m 'Por fin la primer versión y todos estamos ebrios de la emoción'


Recuerda que si firmas tus commits y en el desarrollo hay commits no formados, hacer un merge puede fallar, debido a que no podrá verificar la integridad de la llave gpg de confianza

git merge --verify-signatures non-verify

Esto nos generara un error fatal y nos impedirá realizar el marge. Pero no todo es caotico, ya que si hacemos el merge y lo firmamos, estaremos firmando todos los commist no firmados con nuestra llave.

Usar esto es grandioso, peor debes asegurarte que todos en el equipo entiendan como hacerlo o se volverá tedioso y conllevara una perdida de tiempo ayudando al resto para subir sus commits no firmados.

Las ventajas de usar la firma electronica son muchas, pero uno debe entender GPG para poder usarlo en el flujo de trabajo.

Happy hacking.


viernes, 3 de julio de 2015

De editor a IDE, o lo que es lo mismo: VIM con esteroides.

Normalmente suelo usar un IDE como Eclipse, Netbeans o cualquier otro para tirar código por que son cómodos, estan enfocados al desarrollo y bla, bla, bla... Pero estos IDE's hechos en java, en ruby en lo que sea, algunos pueden ser muy pesados y otros no tantos, pero consumen más recursos de los editores como sublime, atom, note++ (Si, muchos lo siguen usando por... Por que no sé...) es que son editores con algunas ventajas muy cómodas a la hora de escribir código, sacrificando otras, pero que son EDITORES de código (Hacen y no hay punto de comparación con un IDE, así que ni lo intente pensar en sus cabesitas locas.)

Hace unos meses me enfrente a un problema en la oficina, y no es el café, si no los recursos de la maquina que tengo para poder hacer lo que debo. Así que hice lo que debía, pero tener la IDE, el cliente de base de datos (Si, ya sé que aman phmMyAdmin sobre todas las cosas... yo no) docenas de pestañas en el browser y alguna otra cosa en extra... hacían que la maquina fuera por lo suelos en rendimiento. Cambiamos algunas cosas, entorno gráfico, menos pestañas en el browser, ya no mas reproductor de audio en la maquina... usamos en pool data del IDE y dejamos ir al workbrench un rato, pero el IDE seguía consumiendo tantos recursos, hasta el punto de ser molesto.

Así negando a usar un editor de código popular, elegí entre todos los males, el peor, ¿por qué escoger la opción menos malvada? Tomamos vim como el equipo de GEx y lo pusimos bello para editar las necesidades del día al día.

Para lograr esto, usaremos plugins y para hacerlo de la manera mas rápida, usaremos Vundle, un gestor de paquetes para vim que nos permite manejar los paquetes desde el vimrc, lo cual para empezar, debemos clonar el proyecto en nuestra carpeta .vim/bundle/



$ git clone https://github.com/gmarik/Vundle.vim.git ~/.vim/bundle/Vundle.vim
y crear (en caso de no tenerlo) nuestro .vimrc en el home de nuestro con el siguiente esqueleto, donde poco a poco iremos armando para poder incluir los paquetes (plugins) necesarios o que necesitemos según los gustos de cada quien. Y para ello, les recomiendo la pagina de vimawesome.com donde encontraremos todo lo que necesitemos para convertir a nuestro editor en una pequeña IDE.


set rtp+=~/.vim/bundle/Vundle.vim " alternatively, pass a path where Vundle should install plugins " "call vundle#begin('~/some/path/here') call vundle#begin() " " let Vundle manage Vundle, required Plugin 'gmarik/Vundle.vim' call vundle#end()            " required filetype plugin indent on    " required " " Brief help " " :PluginList       - lists configured plugins " " :PluginInstall    - installs plugins; append `!` to update or just " :PluginUpdate " " :PluginSearch foo - searches for foo; append `!` to refresh local cache " " :PluginClean      - confirms removal of unused plugins; append `!` to " auto-approve removal " " see :h vundle for more details or wiki for FAQ

Vim por si solo nos da muchas ayudas de forma nativa para poder editar código, como resaltado de sintaxis, autoidentado, tamaño del espacio en tabulador, etc, que si bien son una gran ayuda, no son los suficiente para ayudarnos al trabajo del día a día, para ello, les recomiendo Syntastic que nos ayudara a checar errores en la sintaxis y que soporta una gran cantidad de lenguajes.

Otra necesidad, es poder navegar por el proyecto sin tener que salir de vim, para lo cual tenemos la ayuda de NERDTree, un explorador de filesystem desplegado en un árbol, el cual nos permite ver carpetas y abrir los archivos necesarios sin salir del editor.

La necesidad de hoy en día, nos obliga a tener una manera de poder navegar en nuestro código teniendo a la mano las variables y funciones para poder navegar mejor entre tantas lineas de código y evitar la perdida de estar buscando de forma manual, por ello existe Tagbar que requiere que tengamos instalado ctag, el cual podemos compilarlo o descargarlo desde nuestro gestor de dependencias favorito.

Los IDE's modernos nos permiten el autocompletado de código, lo cual es una gran ayuda a la hora de escribir de una forma mas rápida y no cometer errores de sintaxis, en lo personal, uso YouCompleteMe, el cual requiere que clones el proyecto en tu carpeta de Bundles y compiles.

cd ~/.vim/bundle/YouCompleteMe
./install.sh --clang-completer


Para poder hacer de YouCompleteMe una experiencia totalmente agradable, usaremos SuperTab que nos ayudara a todos aquellos que estamos muy acostumbrados al autocomplete por medio del tabulador.

Otro paquete que no nos puede faltar para nuestro adorado vim, es el uso de snippets que lo encontramos en IDE's y editores como sublime o atom, y para ello, nada mejor que ultisnips, un paquete que nos ayudara a crearlos de una forma tan simple y que hará las delicias de chicos y grandes.


Y aunque existen muchas otras opciones para diferentes lenguajes como ruby, php, javascript, java o integrarlo con git creo que esto es lo básico para poder hacer de vim algo mas que un simple editor de textos.

Les dejo mi vimrc que esta adaptado para php, es lo que por el momento uso, no sin antes decirles que si gustan de tener estadísticas y datos de su forma de programar, se den una vuelta por wakatime, el cual tiene diferentes plugins para distintas IDE's, editores y si, también para nuestro adorado y amado vim.

Happy hacking.

domingo, 24 de mayo de 2015

De las clases abstractas y esas cosas de la interface



Hace un par de semanas, leyendo post en un foro de php, me encontré con una pregunta en torno al uso de clases abstractas y si en realidad eran necesarias o no. Esto y el uso de frameworks (seudos) "poderosos" autoproclamados así, por que ni sus creador se les hincho la real gana, ayudan a mal entender o de plano, ni conocer el potencial de la programación orientada a objetos. Pero sobre eso, hablare otro día.

El mundo de la arquitectura y la artesiana del desarrollo de software, es como ese cuento de Lovecraft, que para llegar a el, tienes que escapar de la realidad, al punto que todos te ven feo y te vuelves un vagabundo, con sueños raros y utópicos.

Vamos a pensar una cosa medio rara, y hablar de interfaces y clases abstractas y terminar siendo unos clasistas, por que al final, ¿de eso se trata, de crear clases, vale?

Supongamos que tenemos una interface llamada Humano, y un humano hace cosas, tenemos en esta interface métodos como: "hablar, pensar, ver, comer" Y los otros más. Como sabrán, en una interface, los métodos solo se declaran, pero no se declara funcionalidad alguna, nadie sabe que hacen, solo le dirá a la clase que la va a implementar que debe hacer, no como hacerlo, eso depende de la clase. Así que si la case habla y lo hace mal y el resto del mundo no le entiende, bueno, la interface se lava las manos y le dice: Yo te dije que tenias que hablar, si no lo haces bien, es por que tu lo estas haciendo mal. Sigamos

Ahora tendremos dos clases abstractas, una llamada Programador y otra Diseñador, estos dos implementan a la interface Humano. Ahora ya saben que ambos tiene que hacer cosas que hacen los humanos, pero bien sabemos que todos hacemos las cosas de manera diferente, es decir, todos dormimos, pero cada quien duerme como se le da la gana.

Así que programador implementa pensar, y lo hace todo de manera abstracta, y se basa en hechos y todo con un por que de. Pero Diseñador lo implementa de manera diferente, para el todo debe ser concreto, basado en simetría, armonía etc. O sea, su pensamiento es armonioso. Y así casa clase va definiendo como hablar, como ver, como comer, como dormir etc.

Ahora vamos a tener a tres clases felices, la clase Mario, la case Mariana y la case Levi. Ya sé, soy como que bien Random, pero esta padre, no?

Mario implementa directamente a la interface Humano y ya, El solo quiere ser Mario, el humano, y va a ir reescribiendo sus métodos por que es un ecléctico.

Mariana extiende de la clase abstracta Programador, y sobre escribe uno que otro método por que no le gusta, como hablan los programadores, por ser una bola de tíos aburridos y nadie quiere, en su sano juicio, escuchar a uno. Así que Mariana habla mucho mas sexy y es toda una chica geek.

Levi extiende de Diseñador, igual modifica (Sobre escribe) algunos métodos para ser mucho mas cool, ya saben, la neta del mundo mundial y así.

Ahora seamos crueles, racistas y unos clasistas. A nuestros tres objetos (Por que ya los instanciamos y son la onda ahora) los vamos a invitar a una fiesta, pero la fiesta solo pueden acceder todo aquel que extienda de Diseñador, por que es una fiesta así bien padre, donde todo son divertidos, unos alcohólicos (Sociales, y no solitarios como los programadores) y si, tienen una vida. Los tres llegan a la puerta y el cadenero, un gorila de uno 1.90 y cara de no tengo amigos y no me hacen falta. Y si, lo único que sabe decir es: Yo aplastar objeto desagradable, yo comer y esas monadas ilógicas que seguramente Hulk entenderá mejor.

El primero en entrar es Levi, y no le dicen nada, el pasa como Juan por su casa. Que bien, ahora tendremos que esperar a sacar de esta fiesta un Levi ahogado en alcohol...

El segundo es Mario el humano, recordemos que el no extiende de ninguna clase (Hereda), el implementa a su antojo y ya. Pero Nuestro gorila de la puerta no lo deja pasar, por que esta fiesta es solo para diseñadores, todos los que extienden de esta clase y solo de esta clase a cualquier nivel, pueden pasar. Es decir, los clase CM, si, esos que se encargan de las redes sociales, si pueden pasar, pero esta clase extiende en algún punto de Diseñador. Las clases SEO también pasan!!! por que extiende igual, en algún punto de Diseñador. A Mario no le queda otra que ir a casa.

Ahora Mariana trata de entrar, pero el mismo gorila no la deja, por que los programadores ni tienen vida social, y son aburridos. Mariana le demuestra que no es aburrida, que es super divertida y tiene una vida social, y se ha puesto a hablar con otros objetos de tipo diseñador y han reído y se han hasta agregado en sus redes sociales, pero como la fiesta es solo para CLASES Diseñador, pues sera todo lo divertida, guapa y buena onda, pero a esa fiesta NO puede pasar.

Es decir, en este ejemplo tan burdo, hemos visto como nuestros objetos hacen lo mismo, pero cada uno de una forma diferente, por eso no da lo mismo, cuando extiendes (heredas el comportamiento de la otra clase) a implementar y definir nuevos comportamientos, como hacer ejercicio, volar, dormir en la oficina. Yo que sé.

Espero que eso te pueda ayudar en algo.

lunes, 16 de marzo de 2015

Java y su paso de valor "Referenciado"

Hace un tiempo, en mi paso por #GEx, se presentó una duda razonable en cuanto a #java.

Si tu creas un objeto y lo pasas a una variable, que es lo que pasa?? Mi respuesta inmediata fue: se referencia, por lo cual no se reserva memoria para este paso.

supongamos que tenemos una clase Algo y un código así.

Algo a = new Algo();
Algo b = a;
a = null;

Y esto causo realmente la duda, si a es ahora nula, por que b no? Y es que aunque a y b estén referenciados al mismo objeto, no están relacionados de ninguna otra forma, por lo que una asignación como en este caso, al objeto a, lo desenganchará del objeto original, pero no afectara a b en lo mínimo. Por lo cual, a es nulo, pero b sigue apuntando al objeto original, pero no es realmente asi.

Si bien, la VM relaciona la variable a y b por medio del id, a y b son una copia del objeto creado (Si, al ser copia, se hace la asignación de este en memoria). Así que si hacemos algo como esto (disculpen que use la imprudencia de #Groovy, pero es que si soy un poco flojo).

class Algo{
  def name;
}

Algo a = new Algo(name:"basura")
Algo b = a

println "Esto contiene la variable a: ${a.getName()}"
println "Esto contiene la variable b: ${b.getName()}"
println "Este es el id del objeto a: ${a.hashCode()}"
println "Este es el id del Objeto b: ${b.hashCode()}"

En este punto, la variable name va a tener el mismo valor tanto para a como para b, y los id de cada uno serán idénticos, lo cual nos haría pensar que si, el paso es por referencia y no por valor. Y si seguimos jugando con esto, mas nos hará pensar lo mismo!

b.setName("Random");
println "Esto contiene la variable a: ${a.getName()}"
println "Esto contiene la variable b: ${b.getName()}"
println "Este es el id del objeto a: ${a.hashCode()}"
println "Este es el id del Objeto b: ${b.hashCode()}"
a.setName("Uetiko")
println "Esto contiene la variable a: ${a.getName()}"
println "Esto contiene la variable b: ${b.getName()}"
println "Este es el id del objeto a: ${a.hashCode()}"
println "Este es el id del Objeto b: ${b.hashCode()}"

Y si, sigue cambiando y cambiando y no deja de ser el mismo id, pero como bien se ha mencionado antes, todo cambia cuando haces a una de las dos nula:

a = null
try{
  println "Esto contiene la variable a: ${a.getName()}"
}catch(Exception e){
  println e.getMessage()
}
println "Esto contiene la variable b: ${b.getName()}"
println "Este es el id del Objeto b: ${b.hashCode()}"

Aquí vemos como la variable 'a' la hacemos nula y la marcamos para que sea procesada por el GC, y esperanzados a que b, que era una referencia, pues muera de igual forma, por desgracia no es así como funciona, ya que si recordamos las sabias palabras de Ken Arnold y James Gosling, nos damos cuenta que si, la VM al estar pensada para que corra en diferentes arquitecturas, lo mas lógico es que la única forma de pasar valores en java, es por valor, ya que esto ayuda a la simpleza.

Con amor, Random.

jueves, 22 de enero de 2015

Mientras encripatmos a alguien, hablemos de cifrado y así.


Muchas veces confundimos el codificar, con cifrar, con encriptar ( No, nos negamos a meter a alguien en una cripta.) que no, no es encriptar, por que cada que dices encriptar, dios mata un gatito, y los gatitos son como las direcciones IPv4, ya no hay mas.

Pero hablemos de conceptos.

¿Qué es codificar?

En términos muy simples es expresar una misma información de una forma distinta, es decir, transformamos nuestros símbolos (Caracteres) en otro sistema de representación, por eso, en realidad no estas ocultando o dificultando el acceso a la información, y el ejemplo mas común es el lenguaje.

Supongamos que tenemos un mensaje: "Hola, mundo"

Es simple, es burdo, pero es lindo, ahora tenemos el mismo mensaje en ingles: "Hello world"

Foneticamente y morfologicamente son distintos, pero el significado es el mismo, simplemente codificamos el mensaje, y por eso se puede leer de otra manera, en este caso, en ingles.

Y bien, ¿Qué es cifrar?

Es aplicarle a un mensaje un algoritmo y una clave, y esto nos da como resultado, un mensaje cifrado, vulgarmente conocido como criptograma.

Pero cuando hablamos de algoritmo, hablamos de un proceso que debe ser siempre unívoca, lo que significa que una entrada siempre provoca una misma salida o resultado, pero como no queremos eso, tenemos que variar la entrada y para ello usamos una clave.

Supongamos que yo tengo un secreto (Una clave) y utilizo este secreto para cifrar un mensaje. Si yo quiero compartir este mensaje con alguien mas, tengo que compartir mi secreto con esta otra persona, y luego esta persona aplicar mi secreto para poder leer el mensaje. Por lo que podríamos decir que, nuestro mensaje es tan seguro como mantengamos oculto nuestro secreto. Esta técnica se le conoce como criptografia simétrica.

De aquí nace otro concepto interesante en los años 70's que pretendió arreglar el inconveniente del secreto pre-compartido con un juego de llaves, donde una se una en un sentido y la otra, en otra (Por que, obvio, no creo que sean para lo mismo, no tendría caso). Para este punto, una de ellas es la llave privada, que nadie debe tener, y la otra es una publica, que puedo compartirla con quien yo quiera. Y a esto se le llamo criptigrafía asimétrica.

Cuando creamos estas llaves con PGP o GPG, ponerle una frase de paso o clave a la llave privada, es obligatorio (O muy recomendado, de verdad, tienen que ponerle una clave, ya les diré por que). Pero algunas veces, cuando usamos RSA o SSL no lo hacemos por que suponemos que están en un sitio seguro y... nadie entra a sitios seguros a robar información, o ¿si? El caso es que, supongamos que nuestra llave privada cae en otras manos que no sean las nuestras y no cuenta con una frase de paso (clave), pues esta persona podrá leer nuestros mensajes cifrados y saber donde ocultamos las galletas de chispas de chocolate que no queremos compartir con el resto de la humanidad.

Gracias a la criptografia asimétrica, hoy podemos hace una firma. pero pongamos en contexto algo simple del funcionamientos de las llaves. Y es que si bien, todo mundo (o los que queramos) tiene nuestra llave publica, el proceso de cifrado es a la llave publica y el proceso de decifrado es por lo tanto, a la llave privada, pero si ¿esto lo hacemos al revés? Aplicando el proceso de cifrado a la privada y el decifrado a la publica. Y si, es aquí donde entra la tan conocida firma digital o electrónica, es decir, solo tu, que tienes tu llave privada puedes generar una firma valida y cualquiera con tu llave publica verificar la integridad, la autenticidad y el no repudio de la información entregada, por lo que luego no puedes venir a decirle que no haz escrito el correo mandado. ¿Pero como de que no? Tengo la prueba matemática para demostrarlo!

Una cadena es tan fuerte como el mas débil de sus eslabones.

Si bien, el cifrado es algo (mucho) útil a la hora de mantener segura nuestra información y poder asegurar la veracidad de la información que se maneja, de nada sirve que tengamos una llave de 4096 bits si para comparar las firmas digitales lo hacemos por medio de la comparación de cadenas: Nintento, nunca cambies, por favor.

Existe desde hace unos cuantos meses o miles de años, desde los algoritmos clásicos y de eso, hace ya mucho los ataques criptograficos o el criptoanalisis, que consiste en descubrir debilidades en los algoritmos criptograficos que nos permitan obtener pistas para decrifrar las claves.

Ahora, supongamos, mi querido lector, que tenemos el algoritmo RSA que se basa en el problema matemático de la factorización de números enteros, en el cual usaremos nuestra computadora cuántica que funciona con aire y que compramos en china a un buen precio para tratar de romper un mensaje cifrado. Esto es un coste exponencial, que en la teoría de la complejidad, si nosotros aumentamos un poco la complejidad de la frase de paso (clave), poder romperla se vuelve un lio  hasta el punto que no se podría... o si, pero nos llevaría mas tiempo del que lleva el universo siendo universo, así que no esta nada mal desde ese punto de vista.

Así que, la criptografia no nos hace la vida mas fácil, pero si mas segura. Tiene un costo, pero tiene beneficios que cada uno de ustedes le dará el peso que crea necesario.

Con amor: Uetiko