En los últimos días hubo un intenso debate sobre el nombre de la próxima versión mayor.

No era realmente importante decidir ahora lo que el nombre será porque tardará un tiempo hasta que salga la próxima versión mayor. Sin embargo, esta discusión necesitaba ocurrir tarde o temprano para tomar una decisión.

La discusión era acerca de llamarlo PHP 6 o PHP 7. Los argumentos para cada una de las propuestas fueron presentados en un documento RFC llamado Nombre de la Próxima Versión de PHP.

La votación se inició una vez pero fue cancelada después de introducir más discusiones antes de que se reiniciara. Los resultados fueron anunciados una semana después de reiniciar el voto. La propuesta de PHP 7 ganó con 58 votos contra 24 votos para PHP 6.

Hubo una discusión sobre si los votos debían hacerse visibles o no antes de que finalizara el periodo de votación. La idea era evitar el efecto bandwagon. El argumento defiende que algunas personas van a votar sólo para jugar junto con otros, en lugar de votar sobre los méritos de las propuestas. La discusión no fue a ningún lado.

PHP 6 versus PHP 7

La discusión sobre el nombre de la siguiente versión major de PHP terminó. Se tomó la decisión de PHP 7, pero si no sigues los argumentos, puedes estar curioso por entender lo que estaba en juego.

PHP se mantiene evolucionando. Cada versión mayor tiene nuevas características. La mayoría versiones menores son correcciones de errores.

La mayoría de usuarios entusiastas tienden a volverse muy ansiosos con nuevas versiones mayores porque están ansiosos de aprovechar nuevas características tan pronto como sea posible.

También las nuevas versiones mayores ofrecen grandes signos de vitalidad del lenguaje, reforzando la creencia de los fans de PHP de que ellos hicieron la elección correcta en un lenguaje que está liderando el mercado.

Otros usuarios están más preocupados con las versiones mayores porque nuevas características a menudo vienen con incompatibilidades con versiones anteriores, lo que significa que esto puede conllevas más trabajo y dolores de cabeza arreglando código que se rompió debido a esos cambios.

Así que el nombre de la próxima versión principal no era tan importante siempre y cuando todos los usuarios entienden que es una nueva versión con todas las implicaciones.

Aquellos que estaban a favor de mantenerlo PHP 6 afirmaron que sería el siguiente número lógico después de la versión mayor actual de PHP, que obviamente es 5.

Los que estaban a favor de PHP 7 afirmaron que PHP 6 era el nombre de una rama PHP que fue descartada en 2010. Que fue un desarrollo muy ambicioso que pretendía traer soporte Unicode como estándar a todo el manejo de texto en PHP.

Puesto que PHP 6 fue abortada, los proponentes de PHP 7 no querían que la próxima versión mayor de PHP se confundiera con esa rama que fue descartada hace mucho tiempo en el pasado.

La mayoría de los desarrolladores votantes preferieron evitar esa confusión, así que la próxima versión mayor de PHP será PHP 7.

La Maldición de la Versión 6

Aquellos que son más supersticiosos pueden decir hay algo malo con las versiones número 6 de los lenguajes de programación.

Mucho antes del fallido PHP 6, el lenguaje Perl también tocó con la versión 6. Perl 6 iba a ser un motor del lenguaje totalmente nuevo después de la versión 5, pero con una mayor ambición.

Perl 6 comenzó con un debate en el año 2000 de las características del lenguaje. También se produjo una especificación para permitir que los desarrolladores implementaran el lenguaje sin tener que leer las fuentes de una implementación de referencia.

Todas esas discusiones hicieron que la implementación de Perl 6 tomara años en desarrollarse, hasta el punto que muchos fans de Perl lo olvidaran y se movieran a otros lenguajes.

Obviamente fue una coincidencia que estas cosas sucedieron en la versión 6. Los asuntos con la versión 6 de PHP eran diferentes y eso no detuvo a nadie de seguir trabajando con PHP.

PHPNG se convertirá en PHP 7

En paralelo a la discusión del siguiente nombre de la versión mayor de PHP, se presentó otra propuesta para convertir la rama PHPNG como la rama base de PHP 7.

Mientras que las discusiones están todavía en curso y la votación sobre esta propuesta aún no se inició en el momento de escribir este artículo (nota del traductor: la propuesta ya se encuentra en votación), es muy probable que esto suceda.

Sin embargo, es posible que todavía haya un release para la versión PHP 5.7 antes de PHP 7.

Características Principales de PHP 7

1. Enormes Mejoras de Rendimiento

El objetivo principal de PHPNG fue a traer mejoras en el rendimiento que al menos coincidan con lo que ofrece Facebook HHVM.

Zeev Suraski de Zend ha escrito un artículo en el que admitió abiertamente que toman HHVM como un competidor de (el motor basado en Zend) PHP. Esto confirma que la liberación de HHVM y luego el lenguaje Hack de Facebook desencadenó este gran interés de Zend en continuar liderando la implementación principal de PHP.

En ese artículo también demuestra cuánto ha evolucionado la rama PHPNG en términos de mejoras en el rendimiento.

2. Motor JIT

Según Dmitry Stogov de Zend, el inició del desarrollo de PHPNG se inicio con la motivación de investigar la implementación de un motor de JIT para el PHP basado en el Motor Zend.

Un motor JIT puede compilar dinámicamente Zend opcodes en código máquina nativo que finalmente haría que el código corriera más rápido la próxima vez que se ejecutara.

Mientras que la aplicación de un motor JIT aún no se ha incorporado a la rama PHPNG, Dmitry mencionó en mayo que él "invirtió una cantidad significativa de tiempo experimentando con JIT e incluso creó un PoC (nota del traductor: Proof of Concept, Prueba de Concepto) de un complilador JIT de LLVM transparente embebido dentro de OPCache".

Así que está sin duda en los planes de Zend para permitir traer un motor JIT a PHP 7, así según Zeev Suraski esto puede "impulsar el rendimiento a través del techo para una ya ultra rápida implementación".

3. AST: Abstract Syntax Tree

Recientemente Nikita Popov propuso la implementación de la generación de un árbol de sintaxis abstracta (AST) como un paso intermedio para el proceso de compilación de PHP.

No es la primera vez Nikita propone la implementación de un AST como paso de compilación. Ya lo había propuesto en el 2012.

Un AST ofrecería varias ventajas que son descritas en sus propuestas, incluyendo la posibilidad de más optimizaciones que harían que PHP se ejecutara aún más rápido.

En la última propuesta describe la posibilidad de exponer el AST a las extensiones de PHP y a las aplicaciones de usuarios. Eso podría abrir espacio para herramientas más interesantes como analizadores de código estático que a menudo son útiles para detectar errores o posibles optimizaciones a nivel de código fuente de nuestro código PHP.

Nikita ya proporcionó un parche para implementar el soporte AST sobre la rama PHPNG.

4. Programación Asincrónica

Esto puede no ser obvio para todos, pero últimamente, Julien Pauli, uno de los responsables de las últimas versiones de PHP, ha estado comentando sobre refactorizar la capa de multiplexación de entrada-salida de PHP.

Esto parece ser un paso necesario para implementar un loop del eventos. Un loop de eventos es parte del código que se encarga de controlar los eventos relacionados con las operaciones de E/S y otras tareas asincrónicas que pueden estar pasando en paralelo, como accesos a archivos, redes, bases de datos, temporizadores, etc...

En términos más sencillos, esto permitiría a futuras versiones de PHP implementar fácilmente el soporte para la ejecución de tareas paralelas dentro de la misma petición, impulsando el rendimiento de PHP potencialmente a un nivel totalmente diferente.

Esto es algo que comenté varias veces antiormente. Una de las últimas veces fue en el artículo sobre las mejoras de Facebook Hack.

Por supuesto, no consigues mejoras de rendimiento automáticamente con sólo habilitar el soporte para la programación asincrónica. El nuevo código PHP debe escribirse de forma tal que aproveche el potencial de la programación asincrónica.

A pesar del esfuerzo inicial de Jean Pauli, esto no significa que el soporte nativo para programación asincrónico se habilitará en PHP 7.

Sin embargo, puesto que Facebook Hack ya proporciona soporte para programación asincrónica en una forma muy elegante, no me sorprendería si los desarrolladores del núcleo de PHP se movieran más rápidamente para hacer que la programación asincrónica en PHP estuviera disponible muy pronto.

5. Servidor Web Standalone Multi-threading

Esto es algo que no parece estar en los planes para PHP 7 pero es algo que haría más escalable a PHP.

Ya se puede ejecutar PHP desde servidores Web multi-threaded como ngynx, lighttpd o incluso Apache en el modo worker, sin embargo esto no es lo mismo que tener a PHP corriendo en su propio servidor Web multi-threading.

Un servidor Web multi-threading puede manejar muchas peticiones simultáneas utilizando un mismo pool de memoria, evitando así la pérdida de memoria que ocurre cuando se ejecuta PHP como FastCGI o en Apache en modo pre-fork.

También permitiría a PHP usar una único pool de conexiones de base de datos, minimizando así el número de conexiones simultáneas de base de datos abiertas durante picos de acceso.

HHVM ya puede funcionar como servidor Web multi-threading independiente desde los días cuando el proyecto fue llamado compilador HipHop PHP.

Esto permitió a Facebook reducir un poco los servidores necesarios para manejar la alta carga de accesos que tienen.

A pesar de que ejecutar PHP como un servidor Web multi-threading independiente no está todavía en los planes para PHP 7, ciertamente es algo que sería bueno tener, al menos para PHP 8.

¿Cuando Será la Fecha de Lanzamiento de PHP 7?

Es demasiado pronto para tener una buena estimación de la fecha de lanzamiento de PHP 7. Diferentes personas estiman tardará entre 1 a 3 años. Una suposición razonable es esperar una versión final de PHP 7 en algún momento de 2016, aunque no es imposible ver las primeras versiones alfa en el año 2015.

Así, por ahora puedes cuentar con al menos 1 año de espera hasta que puedas empezar a probar PHP 7.

Conclusiones

Las últimas novedades del lenguaje PHP sin duda han sido muy emocionantes.

Si es justo admitir que la mayoría de estos desarrollos fueron una consecuencia de Facebook empujando hacia adelante con HHVM yt el lenguaje Hack, creo que debemos agradecer a Facebook para ese empuje.

Sospecho que lo hicieron intencionalmente, es decir, empujaron a HHVM y Hack para hacer que los desarrolladores del núcleo de PHP despertaran y se movieran más rápido. En ese caso, ¡funcionó!. Sin embargo fue algo bueno para la comunidad PHP en general, así que nadie debe quejarse.

¿Qué te parece? ¿Te gustaron estas novedades en el lenguaje PHP? ¿Hay algo más que te gustaría ver pasando en el lenguaje PHP para que avanzara algo más? Enviar un comentario para decir lo que piensas.

Artículo original

Tú No Sabes Que No Sabes

La razón de esto es que casi todos los desarrolladores web necesitan a JavaScript en un momento u otro. Con una falta de entendimiento, el enfoque más común para aprender JavaScript es buscar ejemplos de código caso por caso y realizar algunos copiar y pegar rápidos. El problema con este tipo de "aprendizaje" es que el desarrollador realmente nunca aprende el lenguaje y en su lugar gana la falsa sensación de que lo saben. Lo que he descubierto en el curso de aprendizaje y trabajo con JavaScript desde hace varios años, es que no sabes que no sabes, hasta que realmente sabes. Aunque esto es un poco redundante, lo que realmente se necesita es que alguien te diga que no lo sabes y que es necesario algún aprendizaje real. Muy a menudo entrevisto a alguien que muestra con orgullo a JavaScript en su currículum habiendo simplemente hecho algunos controladores onClick o validaciones de formularios que juntaron desde ejemplos de código. El uso y conocimiento de frameworks como jQuery o Dojo es grandioso, pero no puedes convertirse en un maestro de estos toolkits sin un buen conocimiento del JavaScript detrás de ellos. A fin de presentar los muchos elementos de JavaScript, he dividido sus conceptos en lo que siento que son los niveles de conocimiento básico, intermedio y avanzado:

Un nivel básico de entendimiento de Javascript incluye:

• Conocer la sintaxis básica de las herramientas del lenguaje tales como loops, declaraciones if, try/catch, etc.
• Entender la definición de funciones, incluyendo las diferentes formas en que ellas pueden ser definidas y asignadas, así como las funciones anónimas.
• Entender los principios básicos de scope, global (window) scope versus object scope (excluyendo closures).
• Entender el rol del contexto y el uso de la variable 'this'.
• Entender las diferentes formas de instanciar y declarar un objeto así como funciones como objetos.
• Entender los operadores de comparación de JavaScript '<', '>', '==', '===', qué es falsy, y como trabaja la comparación de objetos y cadenas de texto, así como el casting.
• Indexado de arrays para atributos de objetos y funciones y como estas difieren de arrays reales (object literals vs. array literals).

Un nivel intermedio de entendimiento incluye:

• Entendimiento de timers, cómo trabajan estos, y cómo/cuando son útiles como método de ejecución asíncrona.
• Conocimiento profundo sobre callbacks y la aplicación de funciones tales como 'call' and 'apply', métodos para controlar el contexto y el paso de argumentos a las funciones.
• Entender la notación JSON y la función 'eval'.
• Entender closures, cómo estos afectan el rendimiento de tu código, y cómo pueden ser usados para crear variables privadas, junto con la encantadora llamada (function(){})().
• AJAX ý serialización de objetos
• Immediately-invoked function expression (IIFE)
• Patrón módulo

Un nivel avanzado de entendimiento incluye:

• Entender la variable 'arguments' y cómo puede usarse para sobrecargar funciones a través de arguments.length y hacer llamadas recursivas a través de arguments.callee. Debería tenerse en cuenta que el uso de arguments.callee puede ser peligroso ya que ECMAScript 5 Strict Mode no lo soporta, aunque jQuery (superior a 1.4) and Dojo toman ventaja de él.
• Closures avanzados tales como funciones self-memoizing, currying, y funciones parcialmente aplicadas.
• Prototipado de funciones y html, la cadena de prototipado, y cómo usar los objetos y funciones base de Javascript (Array por ejemplo) para minimizar la codificación.
• Tipo de objetos y el uso de instanceof y typeof.
• Expresiones regulares y compilado de expresiones.
• La declaracion with y por qué no deberías usarla.
• Y la parte más difícil de todas, saber cómo juntar todas estas herramientas de manera limpia, robusta, rápida, mantenible, y con código compatible entre navegadores.
• Variable and function hoisting
• Promises

El punto final en la sección avanzada es particularmente importante, y es a la vez el más difícil de lograr. Dada la naturaleza flexible de JavaScript, es muy fácil para tu aplicación convertirse en un mezcla inmantenible de código spaghetti. Una vez aprendes el lenguaje JavaScript en sí mismo, la maestría real viene a ser el ser capaz de estructurarlo y unirlo en el contexto de una gran aplicación web. Este punto final requiere de años de práctica y equivocaciones, y no puede aprenderse de un libro. Yo he estado usando JavaScript varias horas al día por varios años, y continuo encontrando mejores formas de estructurar y escribir mi código. Esta es la razón por la que saltar de inmediato a un framework es peligroso, ya que el código jQuery tiene el hábito de volverse inmantenible. Dojo ofrece algo de ayuda con esto a través de su sistema de clases y paquetes.

Dado que JavaScript justo ahora está ingresando en el back-end con cosas como Node.js, he decidido aislar los requerimientos anteriores de conocimientos web específicos. Estos son aspectos web (llamados el DOM e IE) que han dado a JavaScript un mal nombre y hace que bajen escalofríos por la espalda de cualquier programador. Dicho esto, si estás buscando usar JavaScript en un contexto web hay cosas adicionales que cada buen desarrollador debería saber:

• DOM y manipularlo de manera eficiente, es decir agregando, quitando y cambiando nodos, así como trabajar con nodos de texto. Esto incluye minimizar los reflujos del navegador mediante el uso de herramientas como fragmentos de documento.
• Extraer información de elementos del DOM de manera compatible entre navegadores (por ejemplo, estilo, posición, etc.). Estas cosas se pueden hacer de mejor manera con un framewoek como jQuery o Dojo, sin embargo, es importante comprender las diferencias entre la extracción de la información especificada en CSS vs etiquetas de estilo y computar posiciones y tamaños, etc..
• Manejo de eventos de manera compatible entre navegadores, binding, unbinding, bubbling, capturing y cómo obtener el contexto de callback deseado. De nuevo esto es mejor manejarlo a través de un framework.
• Expandos vs. definición de atributos, las diferencias de rendimiento entre ellos, y las diferencias de nombrado que existen.
• Expresiones regulares para extracción de nodos del DOM.
• Detección efectiva de funcionalidades en el navegador y degradación progresiva.

Como puedes ver en la lista anterior, hay un infierno de cosas en Javascript más allá de alert(myVal) and myBtn.onclick = ... Ciertamente hay un montón de cosas de las que puedes copiar/pegar, y sólo puedes ser un verdadero programador JavaScript a través de la lectura y la práctica. Dos grandes libros que cubren todos estos temas son 'JavaScript: The Good Parts', y 'Secrets of the JavaScript Ninja'. Recordemos que Javascript es quizás el lenguaje más accesible que existe, todos tienen un navegador, y no se necesita tiempo para configurarlo. Crea una simple página html y empieza a jugar con los conceptos anteriores. Y para decorar los currículos, yo diría que si cubres el nivel principiante y te estás aventurando en el nivel intermedio, se justifica listar Javascript. Una vez te encuentres escribiendo tus propias funciones, más allá de copiar y pegarlas, puedes decir que sabes Javascript, hasta entonces, por favor, no lo menciones.

Si hay algún aspecto de JavaScript que he olvidado por favor háganmelo saber en la sección de comentarios. También compartan cualquier experiencia que tengan con personas que claman saber JavaScript u otros lenguajes.

Debería mencionar que no soy un desarrollador de front-end, soy un desarrollador de back-end que ha evolucionado en un desarrollador full-stack. Hoy, cualquier desarrollador de back-end necesita aprender JavaScript y eso es lo que este artículo pretende alentar. No pretendo ser condescendiente mencionando conocer todo lo que existe en Javascript. Lo que me gustaría ver es que más personas se den cuenta que JavaScript es un lenguaje vasto y poderoso, y que hay muchas cosas más que los que sus ojos ven inicialmente.

Artículo original

Pero todo hay que decirlo, la consola de comandos de Windows no es particularmente buena, o más bien, tendría que decir que no es particularmente completa; claro está, tenemos la consola PowerShell que nos brinda muchas más funcionalidades, pero para ciertas tareas se queda corta, sobre todo cuando trabajamos con proyectos Open Source, que en su inmensa mayoría, por no decir todos, están construidos para ser usados desde entornos *nix.

Fue esta necesidad la que me impulsó en la búsqueda de un buen emulador de terminal (un emulador de terminal *nix) para Windows. Mi primer acercamiento fue mysysgit (les recomiendo la versión portable, que pueden incluso tener en un dispositivo USB). Digamos que estuve muy satisfecho al principio, pero luego quise y necesité más. Una de las cosas que quise y necesité fue tener más de una terminal en la misma ventana, y también poder definir aliases para mis comandos y aplicaciones más usados.

Así que comencé una búsqueda en internet, y como en muchas otras oportunidades, stackoverflow me dió la respuesta, y así fue como llegué a Cmder, el que a mi concepto es el mejor emulador de terminal que he probado en Windows (todavía me falta probar Terminator).

A la vez que cumple con todo lo que necesitaba y quería como soporte para git a través de mysysgit, multiples consolas en una sola ventana y aliases, también me permite escoger el esquema de colores de una lista preestrablecida con los esquemas más usados o conocidos, o personalizar un esquema a mi gusto, entre muchas más funcionalidades.

Instalación

Lo primero que debemos hacer es descargar una copia de Cmder de su sitio web; recomiendo bajar la versión full que es la que viene con mysysgit. La podemos descomprimir donde queramos.

Posteriormente procedemos a ejecutar el archivo Cmder.exe que se encuentra dentro del directorio en el que descomprimimos los archivos. Nuestra primera vista será la siguiente:

Configuración

Como vimos anteriormente, la instalación de Cmder es muy simple, así que a continuación procederemos a su configuración, para que sea mucho más útil y fácil de usar. Debo aclarar que Cmder nos permite guardar la configuración tanto en el registro del sistema (no lo recomiendo) como en un archivo en nuestros PC o dispositivos USB. Para acceder a la configuración de Cmder hay dos formas: click en la parte superior izquierda de la ventana de Cmder o Win + Alt + P.

General

Hay algunos parámetros por defecto de Cmder que no me gustan o no me parecen cómodos, como por ejemplo que aparezca un ícono en la barra de aplicaciones por cada consola que abra de Cmder (cuando divido la ventana para tener varias consolas):

Para cambiar este comportamiento vamos a la sección Main => Task bar y en la categoría de Taskbar buttons cambiamos de Show all consoles a Active console only:

Otro parámetro por defecto que me gusta cambiar es la transparencia de la ventana de Cmder. Personalmente me gusta tener una ventana con un poco de transparecia, ya que en ciertas circunstancias ayuda mucho. Para cambiar la transparencia de la ventana de Cmder vamos a la sección Features => Transparency y cambiamos a nuestro gusto la categoría Alpha transparency:

Posición y Tamaño de la Pantalla

Algo que me gusta configurar en Cmder es que la ventana siemrpe arranque en la misma posición y tamaño que la última vez que la usé, eso se configura en la sección Main => Size & pos y marcar la opción Auto Save window size and position on exit:

Startup

Personalmente creo que lo mejor es que nuetsra shell de inicio siempre sea bash, para esto debemos seleccionar la shell por defecto en la configuración, en la sección startup, tercera opción (Specified named task):

Comandos Adicionales

Hay algunos comandos que no vienen de serie en mysysgit como por ejemplo chown, md5sum, unrar, wget, zip. Estos nuevos comandos, que básicamente son ejecutables, los podemos obtener del proyecto UnxUtils, o de otras fuentes si gustan. Una vez tengamos los nuevos ejecutables, los debemos copiar en f:/cmder/vendor/msysgit/bin, (de ahora en adelante tomaré esta ruta como ejemplo, reemplácenla por la suya).

Aliases

Cmder nos permite definir aliases de manera fácil y rápida, simplemente debemos adicionarlos al archivo aliases que se encuentra en f:/cmder/config. A continuación les presento los alises que trae Cmder por defecto:

e.=explorer .
gl=git log --oneline --all --graph --decorate  $*
ls=ls --color $*
pwd=cd

Como podemos ver los aliases se implementan mediante una expresión simple de asignación, siendo la parte izquierda el alias y la parte derecha el comando o acción que debe ejecutar dicho alias. Personalmente los alias que más utilizo son los de git, y también algunos accesos directos a mis herramientas de desarrollo como Sublime Text, Netbeans, Notepad++, Total Commander, etc.. A continuación les dejo un extracto de mi lista de aliases (zsh aliases):

# GIT aliases
g=git $*
gst=git status $*
gl=git pull $*
gup=git pull --rebase $*
gp=git push $*
gd=git diff $*
gdc=git diff --cached $*
gdv=git diff -w "$@" | view - $*
gc=git commit -v $*
gc!=git commit -v --amend $*
gca=git commit -v -a $*
gca!=git commit -v -a --amend $*
gcmsg=git commit -m $*
gco=git checkout $*
gcm=git checkout master $*
gr=git remote $*
grv=git remote -v $*
grmv=git remote rename $*
grrm=git remote remove $*
gsetr=git remote set-url $*
grup=git remote update $*
grbi=git rebase -i $*
grbc=git rebase --continue $*
grba=git rebase --abort $*
gb=git branch $*
gba=git branch -a $*
gcount=git shortlog -sn $*
gcl=git config --list $*
gcp=git cherry-pick $*
glg=git log --stat --max-count=10 $*
glgg=git log --graph --max-count=10 $*
glgga=git log --graph --decorate --all $*
glo=git log --oneline --decorate --color $*
glog=git log --oneline --decorate --color --graph $*
gss=git status -s $*
ga=git add $*
gm=git merge $*
grh=git reset HEAD $*
grhh=git reset HEAD --hard $*
gclean=git reset --hard && git clean -dfx $*
gwc=git whatchanged -p --abbrev-commit --pretty=medium $*
gsts=git stash show --text $*
gsta=git stash $*
gstp=git stash pop $*
gstd=git stash drop $*
ggpull=git pull origin $(current_branch) $*
ggpur=git pull --rebase origin $(current_branch) $*
ggpush=git push origin $(current_branch) $*
ggpnp=git pull origin $(current_branch) && git push origin $(current_branch) $*
glp=_git_log_prettily $*
etc...

# custom user aliases
npp=f:\Apps\notepad++.exe $*
nb=f:\Apps\netbeans\bin\netbeans64.exe --console suppress
tc=f:\Apps\totalcmd\TOTALCMD64.EXE
subl=f:\LiberKey\MyApps\SublimeText\sublime_text.exe $*
etc...

Si se preguntan que significa el $* al final de cada alias, (por lo que he podido vislumbrar en mi uso de esta funcionalidad de Cmder), es para que el alias reciba parámetros antes de su ejecución.

Shortcuts

Hay dos shortcuts que yo uso muchísimo, y son los que me permiten dividir la ventana para así tener varias consolas; misteriosamente estos dos importantes shortcuts no vienen configurados, así que vamos a hacerlo. Debemos ir a la sección Keys & Macro y configurar los shortcuts Split: Duplicate active <<shell>> split to bottom y Split: Duplicate active <<shell>> split to right; las combinaciones de teclas que uso para estos dos comandos son ctrl + shift + o y ctrl + shift + e respectivamente:

Llegados hasta aquí podemos decir que tenemos un emulador de terminal muy cómodo y con una configuración básica bastante productiva, pero muchos se preguntarán, ¿para qué me puede servir algo como Cmder?, bueno, por ejemplo para instalar Composer y otros paquetes de software a través de la consola (usando curl por ejemplo), paquetes de software que fueron pensados para ser instalados fácilmente en entornos Linux o Unix y no en Windows, pero también podemos tener toda la fortaleza de tener aliases, multiples consolas en una sola ventana, integración con git y toda la batería de utilidades que nos brinda Cmder.

El nombre Ghost Inception se debe a que este primer artículo es sobre como desplegar el sistema de blogs Ghost en un site de Microsoft Azure y está construido con Ghost y desplegado en Microsoft Azure.

Bromas geek aparte quiero agradecer de antemano a Juan Carlos Ruiz por su ayuda para resolver diferentes inconvenientes que he tenido con Microsoft Azure y con otros temas, y a la vez por su excelente artículo sobre este mismo tópico del cual he tomado algunos apartes, y el cual quiero extender un poco.

Antes que nada, para los que no sepan que es Ghost, según su sitio web es "a simple, powerful publishing platform that allows you to share your story with the world."

Siguiendo la misma línea, para los que no sepan que es Microsoft Azure, según su sitio web es "an open and flexible cloud platform that enables you to quickly build, deploy and manage applications across a global network of Microsoft-managed datacenters. You can build applications using any language, tool or framework. And you can integrate your public cloud applications with your existing IT environment."

Instalación Local

Para entrar en materia, tengo que decir que instalar Ghost es muy, muy fácil, por lo tanto iniciaremos con una instalación local, la que luego desplegaremos en Azure. Primero que todo debemos tener instalado node.js (Ghost require Node v0.10.x) y npm; la instalación de node.js y npm se sale del alcance de este artículo, así que no lo cubriré.

1. Descargar una copia de Ghost.
2. Descomprimirla en nuestra PC en el lugar donde queramos.
3. Renombrar el archivo de configuración de Ghost config.example.js como config.js.
4. Ejecutar npm install --production para instalar las dependencias de node.
5. Para iniciar ghost, ejecutar npm start.
6. Acceder a la dirección http://localhost:2368/ en sus navegadores o ir a http://localhost:2368/ghost para crear una cuenta de administrador y logearse.

Despliegue en Microsoft Azure

Como ya tenemos listo nuestra instalación local de Ghost, ahora solo nos queda desplegarlo en Microsoft Azure.

Lo primero es descargar nuestras credenciales de Azure en un archivo de publishing settings, siempre y cuando no las tengamos.

azure account download

Esto los redirigirá al navegador, donde se descargará el el archivo publishing settings; si no habían iniciado sesión previamente, tendrán que hacerlo.

A continuación tenemos que importar el archivo de publishing settings:

azure account import "d:\azure\credentials.publishsettings"

El siguiente paso es crear nuestro sitio en Azure. Lo más importante del sitio que debemos crear es que tenga soporte para git. Un segundo punto importante es escoger una zona acorde a nuestras necesidades, en mi caso escogeré la más cercana a mi ubicación, osea "East US"; como último paso antes de crear el sitio, es asegurarnos de ejecutar el comando de creación del mismo desde la ruta donde tenemos nuestros archivos de Ghost:

azure site create azure-ghost-test --location "East US" --git

Si todo va bien, dentro de la salida del comando debe aparecer el nombre completo del site, por ejemplo:

Created website at azure-ghost-test.azurewebsites.net

También debe haberse creado un repositorio git local, el cual a su vez tiene un repositorio remoto agregado, este repositorio remoto es el repositorio de nuestro sitio en Azure.

Para que Ghost funcione correctamente, debemos especificar en qué entorno se estará ejecutando, si el entorno de desarrollo o el de producción. Para esto vamos a crear una variable de entorno en el website de la siguiente manera:

# Establecer el sitio actual
azure site set azure-ghost-test
# Adicionar la variable de entorno
azure site appsetting add NODE_ENV=production

Configuración de Ghost

Ya vamos terminando nuestra instalación y despliegue de Ghost y ya solo nos queda agregar los parámetros correctos al archivo de configuración en la sección de producción; lo que debemos cambiar concretamente es la url de nuestro sitio y el puerto. La url la optuvimos al ejecutar el comando de creación del sitio o también la podemos obtener a través del panel web de Azure (es muy importante que la url esté completa, es decir con el "http://") y el puerto lo debemos asignar de manera dinámica (process.env.PORT). A continuación presento como debe quedar la configuración de producción:

production: {  
    url: 'http://azure-ghost-test.azurewebsites.net',
    mail: {},
    database: {
        client: 'sqlite3',
        connection: {
            filename: path.join(__dirname, '/content/data/ghost.db')
        },
        debug: false
    },
    server: {
        // Host to be passed to node's `net.Server#listen()`
        host: '127.0.0.1',
        // Port to be passed to node's `net.Server#listen()`, for iisnode set this to `process.env.PORT`
        port: process.env.PORT
    }
},

Ya que los sitios de Azure corren bajo Microsoft Windows tenemos que hacer un pequeño paso más, ya que Azure cuando carga un sitio node.js lo hace a través de un archivo server.js que no existe en la instalación de Ghost, así que debemos crearlo con el siguiente contenido:

var GhostServer = require('./index');

Llegamos al final de nuestro proceso de instalación y despliege de Ghost en Azure, solo falta agregar nuestros archivos al repositiorio local git y hacer push al repositorio remoto de nuestro sitio Azure:

1. git add --all
2. git commit -m "initial commit"
3. git push azure master

Cuando hacemos push se nos pedirá que ingresemos una contraseña, si no la recordamos la podemos cambiar en el panel de Azure en la vista rápida, opción Restablecer las credenciales de perfil de publicación.

Hemos llegado al final, ya tenemos nuestro blog Ghost instalado en local y desplegado en Azure. Espero que les haya sido de ayuda.