Eliminar certificados SSL que no usas en Amazon ELB

Para nadie es un secreto que Amazon AWS ofrece uno de los “Cloud Services” mas importantes y completos de la actualidad. Si bien es cierto que cualquiera puede entrar en Amazon y configurar su Cloud en cuestión de minutos gracias a la GUI (interfaz gráfica de usuario) que nos ofrece AWS, también es cierto que para sacar el mayor provecho de estos servicios es necesario acudir al API y a las herramientas de CLI (Línea de comandos). 

Hay una cantidad enorme de tareas que no puedes realizar directamente por el GUI del AWS Management Console, en este caso me voy a enfocar en algo que tenía pendiente desde hace unas semanas, que por cuestiones de tiempo no pude terminar hasta ahora, me refiero al borrado de certificados SSL que ya no usas de tus ELB (Elastic Load Balancer). 

Para realizarlo es necesario descargar y configurar los IAM Command Line Toolkit, para ello debemos entrar aquí, y descargar el paquete de herramientas, uno de los pre-requisitos es que debemos tener instalado en nuestra computadora Java versión 1.6  como mínimo, luego editar nuestro .bash_profile o .bashrc agregando las siguientes variables y Path

export AWS_IAM_HOME=~/path_to_iam_folder
export PATH=$PATH:$AWS_IAM_HOME/bin
export JAVA_HOME=/System/Library/Frameworks/JavaVM.framework/Home/

Read More

La promesa de Clojure

En estos últimos tiempos la programación funcional ha cogido un auge considerable. Atras están quedando los días donde los lenguajes tenían que ser parecidos a C++ y Java para que los desarrolladores se sintieran a gusto. Un caso particular es Clojure, un lenguaje que trabaja encima de la JVM - Java Virtual Machine. Esta característica le da un gran potencial, ya que es capaz de usar la gran variedad de bibliotecas desarrolladas en Java out of the box. Si bien es un lenguaje en pañales, se ve como uno muy prometedor dada su expresividad y su enfoque Real Word.

Clojure es un dialecto Lisp (sí, el infáme lenguaje de los paréntesis) muchos desarrolladores no se han atrevido a poner un pie en este lenguaje dada la complejidad que lleva manejar la paridad de los paréntesis, yo me incluía en este grupo hace un año. Afortunadamente, las herramientas de hoy en día pueden ayudar considerablemente en el manejo de este problema; vim, emacs y eclipse son algunos ejemplos de editores que ofrecen extensiones para el manejo de este lenguaje.

Pero… la pregunta que muchos se hacen es

¿por que tantos paréntesis?

Verán, en lenguajes como Clojure/Lisp, todo, absolutamente todo son estructuras de dato, inclúso el código que se escribe. Los paréntesis que se usan para invocar las funciones son listas de símbolos que el ambiente evalua. Como todo al final son listas, el programador puediera modificarlas a su antojo creando nuevas funciones o pasando estos símbolos como parámetros a otras funciones, este es el objetivo de las llamadas macros, código es data, data es código.

La flexibilidad de las macros, permite reducir el denominado Boilerplate Code, código que se repite una y otra vez, que es necesario pero que un mono con un teclado pudiera fácilmente hacer (un ejemplo clásico: los getters y setters en las clases Java). Otro de los beneficios de las macros, es la capacidad de parar la evaluación de símbolos que se reciben por parámetros, de esta forma se pueden crear nuevas estructuras de código (como el unless de Ruby, por ejemplo), logrando extender la sintaxis del lenguaje sin si quiera mandar un solo correo a la lista de los core-dev de Clojure.

Clojure ofrece otras bondades, como el tratamiento de funciones de primer orden, éstas pueden ser usadas como parámetros, pueden retornarse desde funciones y ademas pueden ser creadas al vuelo, esto ayuda a crear funciones parcialmente aplicadas, composición de funciones, etc. Herramientas indispensables para la creación de funciones complejas usando funciones sencillas (La promesa de UNIX en paquetes digeribles).

Otro aspecto fascinante de los lenguajes de programación funcional como Clojure o Haskell, es el manejo del estado; como estarán acostumbrados, las variables en lenguajes de programación iterativo pueden ser modificadas en cualquier momento, y su valor previo queda borrado permanentemente (la única forma de evitar esto, sería realizando un clone de la estructura de datos que se maneja, causando un consumo masivo de la memoria dado que se tiene la estructura representada en memoria dos o más veces). En los lenguajes de programación funcional este no es el caso, dado que se usan estructuras de datos persistentes, no persistentes en el sentido de que se almacena en una base de datos, sino persistente en que la estructura de dato manejada nunca se perderá, cuando la estructura se modifica, la versión original y la versión modificada compartirán la mayoría de las referencias y ambas existirán mientras que el garbage collector no las reclame. Esto permite que el desarrollo de algorítmos concurrentes sea más llevadero (no hay que estar preocupados de que la copia que un hilo maneja se vea alterada por otro hilo).

Además de los tipos de datos persistentes, Clojure ofrece muchos otros tipos de datos mutables con interfaces que aseguran la integridad de las referencias a la hora de modificarlos, logrando así reducir los bugs causados por el manejo de estado en ambientes concurrentes.

Otro aspecto que vale la pena destacar, es el trabajo que se ha hecho en la biblioteca core.logic, esta permite la implementación de algoritmos usando programación lógica dentro de un lenguaje funcional, mezclando los dos paradigmas de una manera muy elegante.

Este blog es sólo un abre boca, si estás ideas te parecen interesantes, revisa estos libros donde se ofrece de manera detallada todos los puntos explicados en este post.

Aproximaciones a la Ingeniería de Software.

Cuando Edgar me propuso si yo quería participar en La cara oscura del software, no pude evitar acordarme de un post en la antigua versión del blog, donde se desencadenó una especie de flame war alrededor de Java y Ruby. Dicho post me hizo reflexionar sobre cómo se veían ciertos aspectos del desarrollo de software hace seis años. Las apuestas que Edgar hacía a la hora de cuáles tecnologías usar y la visón que tenía de “hacia donde van las cosas” en este micromundo.

Entonces pensé que sería un ejercicio interesante, dejar un registro de cómo entiendo el desarrollo del software, para luego poder mirar atrás en perspectiva y observar como se va evolucionando en la carrera. Así es que en los próximos párrafos, a modo de maquina del tiempo, dejaré un manifiesto con mis convicciones actuales con respecto al desarrollo de software. Esto lo acompañaré con una lista de libros que considero fundamentales y donde claramente quedarán en evidencia mis influencias.

Lo primero que pondría en mi manifiesto, es que hay que tachar el termino ingeniería del título de este post. Pienso que el proceso creativo que implica de la creación de software nos acerca más a la Artesanía que a la Ingeniería. Sentarse a “echar” código, requiere de inspiración y está muy lejos de ser un proceso mecánico. Pienso que lo que hacemos necesita de la ciencia y la ingeniería, obviamente es una parte fundamental, pero también creo que un programador que no sea creativo, que no esté en un constante depuramiento de sus habilidades, que no se esté reconstruyendo a sí mismo a medida que cambia la tecnología, que no tenga pasión por el trabajo que hace; esta entendiendo mal este métier.

Al buscar una definición que se aproxime más a lo que hacemos, encontré con dos referencias interesantes, por un lado la definición de wikipedia de artesanía, por otro, quizas un poco más rebuscado, la definición de artesano que maneja Ortega y Gasset en meditación sobre la técnica (pp. 97-103) . En base a éstas, ahora me gusta referirme a lo que hacemos, como artesanía del software.

Lo segundo, y yendo en detrimento de mi toolkit más robusto, es que Rails+Ruby se está quedando en el pasado. A mi modo de ver se está convirtiendo en el Java de hace seis años y ya no es la vanguardia. Así como esta combinación,revolucionó, junto con otras tecnologías, el modo de escribir aplicaciones web, creo que estamos llegando a un punto en que las necesidades que tenemos ya no son (siempre) satisfechas por los enfoques planteados en estas tecnologías.

Concretamente, entre otras razones, creo que Rails esta profundamente amarrado a una arquitectura CRUD y esto ya no escala. Actualizar y eliminar recursos cuando se tienen grandes cantidades de usuarios, accediendo concurrentemente a los datos, no es una solución viable. Además, si uno lo piensa a fondo, actualizar y eliminar registros no tiene mucho sentido. Que algo haya cambiado no quiere decir que antes no estuviera ahí. La inmutabilidad parece ser una propiedad más natural y hasta deseable. Así que, enfoques como los que proponen en Big Data, CQRS o Event Sourcing me parece the way to go these days.

Luego, pienso que la manera de construir sitios web debería ser con un enfoque orientado a servicios. El backend tiene que ser un API robusto que no entienda absolutamente nada de las vistas, ellas no son su problema. Luego el frontend podría ser desde una aplicación escrita en javascript y HTML a capa y espada, hasta utilizar frameworks como backbone.js.

Mi apuesta hoy en día para el backend es utilizar lenguajes funcionales. El que más he estudiado hasta ahora es Clojure y pienso que después pasar la barrera de la notación prefija y los paréntesis; la expresividad y el poder que se encuentra detrás del concepto de “code as data and data as code” no puede ser desestimado. Sin embargo, utilizar, Haskell, Erlang, o Scala también me suena como un approach adecuado.

Para finalizar mi manifiesto de la artesanía del software, a continuación la lista mencionada de libros al inicio, el orden podría ser relevante o no, lo dejo a discreción del lector:

¿Que hubo? soy Objective C (Part Un)

Imagínense una reunión entre programadores y lenguajes de programación, esta es una conversación entre un programador y Objective C, ambos no se conocen.

Hola, soy Objective C, soy un hijo de los 80, la generación de Volver al Futuro e Indiana Jones, Gorbachev, Reagan y Thriller, oye que grande Michael Jackson, que en paz descanse —

  • cof cof, si hola ¿como andas? (mirando de reojo a JavaScript)

Ah si, volviendo al tema, sabes, soy la creación de un pana que tenía dos ingredientes a su alcance, uno bien común y otro algo exótico, tipo como cuando te ofrecen un trago con ron y Amargo de Angostura, no sabes que pensar ¿no? — Sabías que la receta de la Cuba Libre lleva Amargo de Angostura —

  • cof cof cof, me decias (pensando como es que la gente quiere aprende Objective C)

Disculpa, pero si, mi creador tenía a su alcance dos ingredientes, C y Smalltalk, de esa relación pecaminosa salí yo, Objective C, poseo los dotes de C y la orientación a objetos de Smalltalk ¿interesante eh?

  • ¿Chévere? (mirando de frente al grupito de Ruby, CoffeeScript y Python) sabes, seré directo, se que mucha gente está interesada en tí, pero tu fama de raro te precede

Pero porque lo dices, yo poseo todas las ventajas de C, es más, soy C, solo que me barnizaron de Smalltalk.

  • Sabes que, no te metas con el viejito C, allá está echandóse unos Whiskys con Pascal, ¡Que Hubo C! … Aja … Justamente, es que no eres como los demás, insisto, tienes fama de diferente y difícil, imagínate, apenas adoptaste a medias el dot syntax hace poco, y de paso no lo implementas completamente

Pero espera, tengo cosas buenas, por ejemplo:

  • Puedo ser tan rápido como C, en algunos casos.
  • Puedo ser un lenguaje orientado a objetos.
  • Tengo herencia, polimorfismo, late binding implícito, de hecho me consideran más flexible que Java o C#.
  • Tengo propiedades, o atributos.
  • Tengo protocolos, o lo que los otros llaman interfaces.

Bueno si, no tengo excusa, pero, al mismo tiempo, admito que no soy como los demás, soy un poco único, fíjate, en que otro lenguaje de programación declaras una clase usando dos archivos, un .h y un .m … ¿eh, eh ? … fíjate:

// ClaseGrandiosa.h
#import <Foundation/Foundation.h>
@interface ClaseGrandiosa {

    // variables de instancia
    int unEntero;
    float unPuntoFlotante;
    double unDoblePuntoFlotante;
    char unCaracter;
    BOOL unBoolean;
}

+(void)unMetodoDeClase;
-(void)unMetodoDeInstancia;

@end

//ClaseGrandiosa.m
#import "ClaseGrandiosa.h"

@implementation ClaseGrandiosa

-(id)init{
    self = [super init];
    if(self){
        [self unMetodoDeInstancia];
    }
}

+(void)unMetodoEstatico
{
  // método que puede ser llamado sin instanciar la clase
}

-(void)unMetodoDeInstancia
{
    // Comentario de una sola linea

    /*
        Comentario de 
        multiples 
        lineas
    */
}

@end
  • Veo algunas cosas familiares en tí, el uso de { } me recuerda a lenguajes más modernos, al igual que el ; para finalizar una instrucción, como Java o C#. Pero igual eres como enrollado, por ejemplo ¿que son esos corchetes []?

Ah, los corchetes, si, mucha gente me pregunta sobre ellos, es como la cicatriz de Snake Plissken, todo el mundo quiere saber de donde salió, bueno, déjame decirte que esos corchetes son super importantes, porque gracias a ellos yo se cuando un mensaje empieza y termina.

  • ¿Un mensaje? ¿Snake Plissken? ¿De que hablas Willys? ¡épale Clojure!

¡¿No sabes quien es Snake Plissken?! Snake Plissken es el Bad Ass más grandioso que existe, es más, Snake Plissken pwnea a Chuck Norris a cualquier hora.

  • No vale que Snake Plissken ni que nada, los corchetes, los corchetes (con ganas de ir a hablar con Node.Js)

No es gran cosa, es básicamente lo que los otros lenguajes “modernos” llaman métodos, pero conmigo la cosa es formal, me envias un mensaje y yo lo ejecuto.

  • Ahhh entonces, en vez de invocar un método, a ti te tengo que enviarte un mensaje, ¿como los telégrafos? vaya que formalidad (no podrás ser como Ruby, cero rollos)

No vale, es lo misma cosa, fíjate:

A Java, o C#, tu le dirías:

granClase.unMetodoDeInstancia();

A mi simplemente me dices:

[granClase unMetodoDeInstancia];
  • OK, si, ya veo, métodos, mensajes, corchetes, OK, entendido, ahh ¿y los paramétros? ¿te puedo “enviar” parámetros?

Claro que si, simplemente usas : para delimitarlos.

  • ¿Como asi? De nuevo con tus excentricidades (¿Ruby donde estás que no te veo?)

Pues si, de nuevo, me llaman raro, pero una vez que me conoces verás que soy tipo-tranquilo, no seré un “bad boy” como el fulano Node.Js con el que tendrás súbidas de adrenalina, el está de moda hoy como Justin Bieber, pero cuando crezca y le “cambie la voz” ya veré que tan popular es, fíjate lo que pasó con NSynch —

  • cof cof, Objective C … hey … me decías de los parámetros (mientras mira a Rails debatir con Sinatra)

Ah cierto, los parámetros, OK usando la comparación anterior

En Java por ejemplo:

private void metodoConParametro(String arg){
    System.out.println(arg);
}

y lo invocas así:

claseGrandiosa.metodoConParametro("Hola Mundo");

A mi me dices:

-(void)metodoConParametro:(NSString*)arg{
    NSLog("@%", arg);
}

y lo invocas así:

[claseGrandiosa metodoConParametro:@"Hola Mundo"];
  • Ya va, iba bien, pero ¿que es ese signo menos todo atravesado? (mientras ignora la mirada de Visual Basic.NET)

Ah eso, bueno eso indica el nivel de accesibilidad de método

un signo menos (-) representa un método de instancia y un signo mas (+) representa es un método de clase

  • OK, es como decir en Java private o static respectivamente (viendo que Java está llegando a la fiesta)

Si … Oye me alegra que nos estemos entendiendo.

  • Ah si si, OK chévere, dame un chance que ahí está Java y su pana el SDK de Android, dale dale, hablamos…

Pfft, como siempre Android y su Java de atravesados….

RVM+Passenger+Capistrano+Nginx

“El récipe que receto mamá”, podríamos decirlo de esa forma si revisamos la cantidad de enlaces que podemos conseguir en Google con esto y ahora nos encontramos redactando otro más con nuestra experiencia  (para de esta forma dejar un respaldo online) de como hacerlo funcionar una próxima vez en un entorno de Intranet corporativa que usamos nosotros, sin una carga de usuarios alta (somos 3200 trabajadores pero por aplicación la máxima concurrencia que puedo tener es de 10 usuarios -no tenemos tampoco 100 aplicaciones productivas- y cuando digo máxima hablo de porque la palabra “Enterprise” muchas veces es algo de marketing mas que de realidad). Como todo proceso de aprendizaje este récipe podrá recibir las mejoras que el feedback de este post de o el uso del mismo vea para ajustar.

En la empresa había un server con Debian Squeeze que no estaba siendo usado y fue “expropiado” por el Frente Revolucionario de devops de Sistemas Automatizados para sacar las aplicaciones de un pc que usamos como servidor de pruebas de cosas I+D que vamos consiguiendo, pero que desde diciembre había sido tomado como servidor productivo para unas aplicaciones que se estaban usando en la organización…

El comienzo…

Vayamos a lo que nos interesa, como comentábamos nuestro server estaba como un terreno ocioso y para ser puesto en custodia lo primero que realizamos fue la actualización del mismo como dueño de este (aka root):

aptitude update
aptitude safe-upgrade

Luego de esperar un día a que pasara esto (gracias CANTV por los favores recibidos de tu velocidad) procedemos a instalar todo los prerrequisitos que vamos a necesitar para el resto de las cosas a instalar:

aptitude install build-essential zlib1g-dev libssl-dev libpq-dev libcurl4-openssl-dev libreadline-dev curl

Milagrosamente CANTV se condolió de mi y dejo de allí en adelante poder hacer el resto de la instalación a maravillosos 2Mbs (cuando la actualización del server la hiciste a 6400 bytes/s entenderán porque tener loS 2Mbs fue la gloria).

El siguiente día…

Poderes de los rubíes a mi…

Lo primero que hacemos es instalar nuestro manejador de Rubies (RVM) usando el instalador provisto por esto que hace  trabajo de configuración por nosotros:
bash -s stable < <(curl -s https://raw.github.com/wayneeseguin/rvm/master/binscripts/rvm-installer)

Al finalizar este hacemos el chequeo básico de que todo estuvo bien:
type rvm | head -1
Y debería darnos el maravilloso mensaje de RVM is a function, de no ser así que no “panda el cunico” que se necesita simplemente recargar la sesión de shell y listo.

Luego de esto debemos instalar ahora la versión de Ruby a usar en nuestro ambiente lo cual tiene los siguientes pasos:
1. Instalamos readline y openssl para evitar errores  de algunas gemas que vayan a usarlo y la versión de ruby no lo tenga en su compilación
rvm pkg install readline
rvm pkg install openssl

2. Agregamos passenger al contenedor global de gemas de RVM para que todos los gemsets lo hereden y puedan usarlo.
echo passenger » /usr/local/rvm/gemsets/global.gems

3. Instalamos la versión de ruby a trabajar y la ponemos por defecto del sistema (forzamos la instalacion de readline y openssl en esta instalacion para evitar errores):
rvm install ree —with-openssl-dir=$rvm_path/usr —with-readline-dir=$rvm_path/usr
rvm use —default ree

Bye Bye Apache…

Con lo anterior tendríamos ya nuestro ruby instalado y vendría la configuración de Nginx+Passenger que es mas simple que la de Apache 1000 veces por donde lo veamos:
1. Instalar passenger
gem install passenger —no-ri —no-rdoc

2. Compilamos Nginx y le configuramos el modulo por defecto de passenger (esto es un wizard que nos lleva de forma simple en este proceso):
passenger-install-nginx-module

3. Instalar bundler (bundler nos ayudara con todo el tema deploy de gemas mas adelante junto a Capistrano)
gem install bundler —no-ri —no-rdoc

4. Cambiar el repositorio de gemas (Este paso es opcional), en la empresa se tiene un repositorio de gemas por un tema de salida del proxy/firewall en la organización mas tener un control exacto de la versión de las gemas con que estemos trabajando, por ejemplo devise_ldap tuvo que ser “regemificada” por un error en la diseño de nuestro LDAP -AD- que sale fuera del estándar y se tuvo que adaptar el código de esta gema.
añadir primero:
gem sources -a http://<serverdegemas>/<folderconrepositoriodegemas>/
y luego eliminar
gem sources -r http://rubygems.org/
En otro post explicare la forma simple de hacer un repositorio de gemas local que se complementa con algo que explico @Edgar hace un tiempo de apuntar a un repositorio local de RVMs  (puto proxy/firewall que no hace la vida fácil y hay que ingeniársela para hacer las cosas).

5. Configurar Nginx para deployar
La configuración en la empresa es con Sub Uris para la aplicaciones -el año que viene se reajustara esto para usar Rack- lo cual hace que exista solo un sites-enabled (app-server) para tener una estructura similar a la de apache en nginx (cargar modulos por site  y no tocar de alguna forma la configuración general sino la de cada site).  Creamos los siguientes directorios:

mkdir <nginx-path>/sites-available
mkdir <nginx-path>/sites-enabled

Luego de esto comentar cualquier configuración del server dentro del archivo de configuración de nginx y colocar un include a nuestro site por ejemplo:
include   <nginx-path>/sites-enabled/<name_file>;
A su vez esto es un enlace simbolico al folder de los sites-avaible
ln -s /usr/local/nginx/sites-available/<site> <nginx-path>/sites-enabled/

La configuración de el site (name_file) para nginx es muy simple:
server {
    listen 80;
    server_name <server_name>;
    root <sitio de deployar las aplicaciones según debian way>; #pej /var/www
    passenger_enabled on;
    passenger_use_global_queue on;
    passenger_base_uri /<nombre_applicación_RoR>; #para indicar nombre de la aplicación
}

Un Capucc…perdón,  “Capistraneando”

Preparar el ambiente para que nuestros deploys sean automatizados es un proceso de 2 partes, lado server y lado del Master Chief/Marcus GoW/Lord of the Dru..API/Chivo que mas mea (aka responsable del deploy) y vamos a contarlo de forma sencilla:
1. Creamos al usuario a deployar en el server y le damos los permisos necesarios de ejecución (en nuestro caso el usuario se decidió llamar deploy)
adduser —system —home /home/deploy —shell /bin/bash —ingroup nogroup deploy
adduser deploy sudo
echo “deploy ALL=(ALL) NOPASSWD: ALL” » /etc/sudoers
adduser deploy www-data
adduser deploy rvm

2. generar una clave ssh en el server con el usuario a deployar
su deploy
ssh-keygen #NO COLOQUEN PWD A ESTA LLAVE
Con esto terminamos la configuración del lado server y pasamos al equipo responsable del deploy

3. Copiar la clave ssh al cliente encargado de los deploy y hacer ssh-add para que funcione si nos da algún error para su uso (error de hacer ssh user@app-server).

4. Acá les dejo un link donde pueden ver un esqueleto de un recipe de Capistrano que muestra la estructura que usamos aca para hacer nuestra instalacion: Capistranio Recipe
Como sección interesante es la primera (set :default_environment) que se esta usando por un  error que aparecía de RVM is not a function, selecting rubies with ‘rvm use’ will not work cuando se intentaba crear el gemset a usar por la aplicación. Conversando con @kengimel el propuso otra solución en su blog la cual sirve para el propósito de corregir el problema.

5. Lo ultimo a agregar es un común que nos encontramos que las gemas no son instaladas en el gemset creado sino en el shared de la aplicación, lo cual es digamos un “comportamiento esperado” cuando usamos bundler con capistrano ya que su instalacion es de esta manera:
bundle install —gemfile Gemfile —path shared/bundle —deployment —quiet —without development test
Para corregir esto seguimos las indicaciones del Ninja sobre el velocipedo las cuales son precisas:
a. Creear un archivo llamado setup_load_paths.rb dentro del config de la aplicación y colocar allí el siguiente contenido:
if ENV[‘MY_RUBY_HOME’] && ENV[‘MY_RUBY_HOME’].include?(‘rvm’)
  begin
    rvm_path = File.dirname(File.dirname(ENV[‘MY_RUBY_HOME’]))
    rvm_lib_path = File.join(rvm_path, ‘lib’)
    $LOAD_PATH.unshift rvm_lib_path
    require ‘rvm’
    RVM.use_from_path! File.dirname(File.dirname(__FILE__))
  rescue LoadError
    # RVM is unavailable at this point.
    raise “RVM ruby lib is currently unavailable.”
  end
end

ENV[‘BUNDLE_GEMFILE’] = File.expand_path(‘../Gemfile’, File.dirname(__FILE__))
require ‘bundler/setup’
==========================================

Para Rails 2 eliminamos las 2 últimas líneas

Y con esto listo, estaremos disfrutando de nuestro proceso de automatización de deploys sobre un ambiente preparado para manejar diferentes versiones de ruby(ojo que passenger es una gema y hay que revisar instalación si se cambia la versión de ruby por estar instalada en el global del rubi) y gemas por aplicación.

P.D.:
Esta guía no se hubiera terminado sin ayuda de la taconera @satanas82 y el Closeteer de @Rhoml, los cuales prestaron documentos y su tiempo para consulta y correcciones hasta lograr la instalación completa; espero que las cosas que termine agregando les sirvan de referencia a ellos para los cambios que deseen hacer.

Estamos de vuelta …

Luego de algo más de tres años de no escribir en este espacio, … estamos de vuelta.

La idea es la misma, seguir conversando sobre desarrollo de software, lenguajes de programación, frameworks, … basados en nuestra experiencia diaria.

Asi que “come to the darks side …”