Si queremos saber o buscamos en Google cuál es la diferencia entre React Native y React.js, encontraremos un montón de páginas y posts que establecen la diferencia a nivel técnico, o dicho de otra manera, las detalles, los protocolos y otras micro diferencias, sin hablar a grandes rasgos.

Para un lector no técnico, estos posts no indican absolutamente nada, sólo mucho texto acerca de cosas HTML, CSS, renderizado, componentes, integraciones, natividad y otras "buzz words" que no dicen nada.

Entonces quiero colocar y dejar acá una de las principales diferencias que no necesariamente conseguimos en todos los posts, para específicamente dejarle saber a todos esos "tech head hunters" que se me han acercado con alguna oferta en React en mente:

React.js es una tecnología para construir aplicativos web (frontend para páginas web) y React Native es una tecnología para construir aplicativos para dispositivos móviles agnóstio al sistema operativo.

Entonces, señor reclutador, la próxima vez que te acerques diciendo "tengo una oferta increíble para un desarrollador frontend como tú que sepa React para crear páginas web" no me envías una ¡m@ldit@ "prueba"! para "desarrollar" o contestar preguntas acerca de React Native.

¡No!, por favor no lo hagas, no lo intentes, no lo fuerces con palabras tipo "pero es casi lo mismo, ¿no?, entonces podrías intentarlo, ¿no?" o llenes un p#t0 formulario indicando "el desarrollador mintió acerca de su experiencia" porque ambos sabemos que no es así, es un error tuyo como "reclutador tech" al no saber las diferencias.

Tengo un trabajo estable (por los momentos, uno nunca sabe) en una compañía que nos ha tratado bastante bien, pero nunca está de más mirar otras oportunidades. Incluso, estoy donde estoy justamente por eso, por mirar qué hay más allá del horizonte. Y si, sé que lo último sonó muy sentimental, pero el hecho es que si hubiera esperado que alguna oportunidad o algún evento se moviera sólo o sucediera espontáneamente donde estaba antes, tal vez nunca hubiera tomado o visto si quiera esta oportunidad donde he aprendido más de lo imaginado y me han dejado experimentar y probar nuevas tecnologías, siempre en busca innovar.

Ahora, como les venía contando, he visto unas ofertas bastantes buenas, donde por primera vez siento que cumplo los requisitos:

• Experiencia mayor a 5 años en alguna tecnología.
• Haber trabajado o conocer de servicios de cómputo en la nube.
• Soft-skills que he madurado completamente.

Antes, cuando me presentaba, no era nunca la primera opción porque no cumplía con la experiencia, pero trataba de compensarlo con un rápido aprendizaje y demostrar unas ganas increíbles de sacrificarme para cumplir con sus objetivos, siempre estudiando mucho más allá de lo que pedían en los requisitos.

Pero ahora que la experiencia me ha quemada bastantes pestañas, he aprovechado para presentarme a uno que otra postulación, y como este es mi blog, quiero expresar mis buenas y malas (¡súper frustrantes!) experiencias. Ok, seré sincero, les hablaré de 1 experiencia buena que tuve y otra mala (muy mala). No se si esto es deshago, o tal vez quiero dejar saber a los demás o a mi futuro yo de cómo prepararse para afrontar estas situaciones.

TLDR; Quiero redactar acerca de mis experiencias en entrevistas y pruebas tech para oportunidades de trabajo en las que me he presentado, de manera que pueda dejar por acá algo de la frustración (todos sabemos lo negativo que es el rechazo, no importa sobre qué tema sea) y si es posible, que esas empresas puedan ver el impacto que generan, lo mal que nos hacen sentir, los errores que están cometiendo para seleccionar personal y puedan cambiar su proceso en lo posible, pero también dejarles saber como otras compañías si parecen entender que tratan con seres humanos y tienen muy bien planteado qué hacer y retos poner para sacar lo mejor de uno durante las entrevistas y pruebas.

NOTA: Ahora, sé que no soy experto en selección y no tengo la teoría o el know-how, pero quédate conmigo en esta lectura y dime si de verdad estoy interpretando mal lo sucedido o de verdad estas empresas no tienen ni la menor idea de las pruebas de selección que están poniendo a sus vacantes.

Buena experiencia: Sentí que di lo mejor de mi y más que una entrevista, me dieron la oportunidad de lucir mis conocimientos

Mi última experiencia, o mejor dicho, el último proceso de selección que presenté fue muy bueno y me sentí cómodo. De todas maneras también tengo sentimientos negativos porque, spoiler alert: no quedé seleccionado; ese rechazo me hizo sentir mal, pero igual les contaré que siento que fue bueno para mi salud mental.

NOTA: Si quieres leer mi mala experiencia y saber quién fue que me hizo sentir mal y no tengo problemas en decir su nombre acá, podemos adelantarnos o scrollear hasta la sección 'El "proyecto demo" más estúpido...', la segunda parte de este post.

¿Cómo fue el proceso y qué tanto me preguntaron?

Todo empezó con una oferta en LinkedIn (no se en qué otro sitio uno consigue ofertas de trabajo hoy en día) y envié el correo con mi hoja de vida. No pasó mucho tiempo para indicarme que próximamente, otra persona que no es la del correo, se iba a comunicar conmigo, por lo que supongo que una persona mira y "aprueba" hojas de vida y otra hace la primera entrevista.

Al cabo de un par de días me contactan, me preguntan si tengo un espacio para hablar de 30 mins, y llega el momento: una entrevista simple de mis estudios y mis experiencias, nada muy profundo y sólo una corrobación de datos. Incluso me preguntaron sobre mis experiencias como Ingeniero Mecánico, lo cuál es inusual en este campo de la informática. No faltaron las 2 preguntas en inglés para saber si decía mentiras o la verdad acerca de mi nivel, por lo que respondí todo y me sentí bien, aunque mi esposa dice que debo mejorar mi pronunciación.

Al final de la llamada me indican que recibiré un correo con una pequeña prueba a realizar. Esto de pruebas en LeetCode o TestGorilla es bastante molesto. Muchas empresas se han mudado a esta modalidad y dejan toda la responsabilidad en ellas, lo cual siento que no es una fuente confiable de capacidades de la persona a evaluar, ya que solo reflejan si la persona sabe algún método eficiente para hacer alguna lógica o algoritmo, y no el cómo afrontar y resolver problemas. Pero lo que me impactó es que esta prueba fue super corta, 2 preguntas y 1 desarrollo de código que literal era súper sencillo.

Entonces le vi sentido a la prueba: no es para dejar todo en su responsabilidad y de aquí seleccionar al mejor programador (al que se memorizó todo de YouTube), sino descartar esos que de verdad se están presentando sólo por presentarse.

Finalicé la prueba y al cabo de 1 día llegó un correo para una segunda entrevista, que va a tener un tono más técnico, y que adicional los ayude con unos datos míos. El correo llegó con otra sorpresa, no sólo me pidieron mi experiencia y mi rol, sino que nombrara todos los proyectos en los que he trabajado, junto con su Tech Stack y asignación de equipo. Un poco laboriosa esta tarea ya que era recordar en detalle todo lo que había hecho.

Avisé que iba a tardar más de lo esperado y para mi sorpresa, respondieron en un tiempo considerable (creo que en 2 horas) indicando que no había problemas, que tenía chance hasta un par de días antes de la otra entrevista y que agradecía la comunicación (creánme, yo también).

Llegó el día de la entrevista, y más o menos lo que imaginaba: me entrevistaba alguien con bastante experiencia en programación y me hacía preguntas pre-formuladas para saber si conocía o no. Bien, acá empieza todo a decaer. Soy un programador auto-aprendido o self-thought programmer, lo que significa que aprendí por mis propios medios y no a través de métodos tradicionales. Esto traduce que conceptos básicos o definiciones teóricas, normalmente me las salto o las desconozco porque simplemente sé como funcionan en la práctica y sé que funcionan así y punto. No me fue del todo mal, pero les dejaré el resumen (que era para una entrevista para un rol en Node.js):

• "¿Sabes qué es el Event Loop y lo puedes definir?" → Esto lo respondí bien, pero necesito aprenderlo o saber definirlo en mejor detalle.
• "¿Sabes qué son bases de datos SQL y NoSQL?" → También se bastante de esto y creo que me lucí acá.
• "¿Cómo funcionan las promesas en Node.js?" → También sin mucho inconveniente, pero me falta mejor definición técnica.
• "¿Cómo funciona el async/await en Node.js?" → Parecido a las promesas, pero obviamente resalté las diferencias.
• "¿Qué es un REST API?, ¿Qué significa cada palabra o acrónimo?, ¿Cómo está compuesto una llamada de este tipo?" → Acá empecé a salir mal. Sé cómo funciona y cómo se usa, pero no puedo responder bien cómo se define técnicamente.
• "¿Puedes nombrarme los Patrones de Diseño o Design Patters de JavaScript? → Primera respuesta totalmente errónea o que no sabía, de verdad creo que esto me lo he saltado en mi aprendizaje.
• "¿Puedes explicarme la diferencia entre programación funcional y programación orientada a objetos?" → Otras preguntas donde no tenía la respuesta, simplemente salí mal.

Habían muchas otras preguntas, pero vamos a dejar esta lista hasta acá. Uds. creerían que iba a salir bien tomando en cuenta que el grueso de las preguntas y otras de servicios en la nube me iban a dejar bien parado, y más aún tomando en cuenta que el feedback del entrevistador es bueno.

¿Y el resultado final?, ¿Me seleccionaron?

Lamentablemente, al día siguiente, recibí el correo con que mi postulación llegaba hasta ese punto y agradecían mi tiempo y compromiso. Se que lo estoy poniendo acá en simples palabras, pero este proceso es uno de los que más fuerte me ha pegado a mi autoestima, a mi ego y mi ser; de verdad lo recibí mal. Y pasé todo el día deprimido, perdón esposa, perdón compañeros.

Decidí preguntar, uno nunca sabe, y de nuevo, en menos de 2 horas, el chico encargado del proceso de selección, el de la entrevista sencilla, me dejó saber que en realidad salí bien, que sólo me quedó por mejorar "JS Design Patterns" y "Functional Programming", pero decidieron ir por otros postulantes con mejor resultado que yo para la siguiente fase.

¿Por qué creo que fue buena la experiencia?

Creo que fue bueno porque en ningún momento me hicieron sentir mal por no saber algún tema o no cumplir, simplemente me dijeron que habían mejores postulantes, y creo que es una respuesta formal y bastante amigable (no sé que tan cierto sea, pero la sentí sincera).

Pero sobre todo siento que fue buena porque no fue una prueba tonta o el despliegue de un "proyecto demo" (¡Uy! ya vamos a hablar de este tipo de pruebas en la mala experiencia) para demostrar mis habilidades, fueron unas pruebas y preguntas técnicas para descartar y filtrar de forma correcta, incluso si no sabía la definición técnica, el evaluador me dice que lo podía decir con mis propias palabras y la valía, sólo que de verdad esos temas que dije se me van mucho de las manos (al menos el origen y el porqué se usan).

También siento que fue buena porque me deja un roadmap sincero para seguir mejorando e intentando, cosa que veremos que los demás no dejan claro. Ya sé cuáles fueron mis puntos débiles y sé que voy a hacer para mejorar, pero continuemos con nuestro siguiente tema, qué es donde quiero dejar toda mi frustración.

El "proyecto demo" más estúpido que he hecho, la evaluación más sin sentido, sin dirección, sin explicación, sin respuesta a dudas oportuna y el feedback más mentiroso que haya visto

Como les dije, acá es donde quiero descargarme, así que empecemos. Nombre de la empresa: Alegra, ofrecen un SaaS para solucionar temas de contabilidad a otras empresas (B2B).

¿Cómo fue el proceso?, ¿Por qué no lo vi venir antes?

Esto sucedió antes que la buena experiencia, que para el momento de esta redacción, es la última que entrevista que he realizado. Fue muy parecido, vi una oferta, vi que cumplía y me presenté. Al poco tiempo me escriben y creo que en este caso me envían un enlace para agendar la próxima llamada.

También que la otra, una entrevista de experiencias y conocimientos, pero muy por encima, ya que la persona entrevistando es de perfil administrativo, entonces no sabe mucho de tecnicismo, de cómo es esto de la tecnología. De nuevo, un par de preguntas en inglés y todo bien por acá. Se termina la llamada y me indica que me va a llegar un correo con una pruebita a realizar.

Ok, nada mal, una prueba en TestGorilla. Me envían el enlace, la hago, y acá empiezan las cosas negativas, no tengo respuesta ni al siguiente día ni a la siguiente semana. Le escribo un correo a la chica de selección que me hizo la entrevista y nada, sin respuesta por un mes completo.

Para este momento ya había dejaron como terminada la prueba. Probablemente había salido mal o ya habían seleccionado a la otra persona (sinceramente creo que no me había ido mal). Pero al cabo de un mes me llegó un correo felicitándome e indicando que podía continuar con la segunda fase que era hacer un reto técnico.

No recuerdo si tuvimos una segunda llamada o no, pero esta vez le mencioné a Andrea, la seleccionadora, que justo esta semana era mi mudanza y probablemente no iba a tener mucho tiempo el fin de semana para hacer la prueba, pero iba a hacer mi mayor esfuerzo. Esta vez si me respondió y me dijo que no había problema, que avisara y con gusta me aplazaban el momento de la entrega.

Bueno, al menos me respondieron eso. Listo, hora de revisar la prueba: me pedían hacer un pequeño software para una situación ficticia donde quería que usara mis conocimientos en desarrollo de una solución en microservicios. Viendo la prueba por encima, uno podría pensar que no tiene nada malo, pero acá les cuento mi opinión de la misma luego de leerla a detalle:

• Algunos errores de redacción que confunden el cómo hacer o definir ciertas lógicas.
• No indican qué tipo Patrones de Diseño de Arquitectura (req/resp o pub/sub).
• No piden pruebas unitarias o de integración (detalle más adelante de porqué no se implementó).
• Piden desplegar el aplicativo por sus propios medios. La mayor estupidez del mundo, uno incurriendo a gastos porque ellos no son capaces de desplegar un servidor para esto, pero no importa, existen algunos servicios gratuitos (con sus grandes limitaciones) que podemos usar.
• Piden que la solución soporte peticiones masivas, pero son tan estúpidos para indicar que la dependencia del rendimiento es de la infraestructura en vez del código y capas. O sea, yo apliqué una cola de mensajes o Queue (aparte del Message Broker para la comunicación de servicios) para demostrar que conozco sobre estas implementaciones para estos problemas, pero ellos esperaban que pagara un servidor de súper alto rendimiento de múltiples núcleos y mucha RAM. De nuevo, que requisito tan idiota en la vida.
• El mayor requisito de desarrollo, el principal que decida por donde iniciar o qué framework elegir, literal es la última línea del documento dentro del título "Consideraciones" (título que indica que son apenas una observación adicional).

De nuevo, una total estupidez de redacción. ¡Este último texto debe ser la primera línea de toda la prueba!

Por culpa de ellos debo pedir una semana adicional

Ok, decidí comunicarles este pequeño detalle, ya que todo mi aplicativo estaba en Nest.js, y este framework no es considerado "Nodejs puro". Por suerte, luego de un par de correos (sí, más de uno porque no me respondían) me dicen que si, que puedo tomarme un tiempo adicional para ello.

De inmediato empiezo a trabajar en la traducción a Node.js puro con Express, pero tomen en cuenta que este no es un trabajo fácil y requiere un esfuerzo. De repente no el mismo esfuerzo de crearlo desde cero, pero es un desgaste adicional al primero que tuve, porque si pueden leer la prueba, piden un demo que tenga 3 microservicos (4 en total si tomamos en cuenta el API Gateway).

También es algo desmoralizante trabajar en algo que ya has resuelto, pero bueno, otra semana más de acostarme hasta tarde (soy un adulto funcional con responsabilidades fuera de mi horario laboral), pero se logró, y a que no adivinan: Resulta y acontece que el texto de la prueba estaba incompleto y deciden enviarme un texto corregido con tareas adicionales... xD!

¡¿Qué?! O sea, ¿Debo acomodar mi proyecto ya reacomodado a los nuevos requerimientos de la prueba?

Si, debo ajustar la prueba, y este error recae en uno de los primeros puntos mencionados: la prueba no tiene un definición a detalle o no saben qué es lo que quieren ver o medir. Estos son errores humanos y es entendible, pero lo que no es entendible es que uno tenga que pagar en vez de ellos, eso está completamente mal, ellos son los que deberían tomar la prueba con los requisitos como están en vez de pedirme más esfuerzo para ajustarme a ellos.

Pero no importa, al menos no es un cambio radical, pero si me piden cosas nuevas como añadir pruebas unitarias, que no fueron añadidas por tema de tiempos, esfuerzos y lo principal, en ninguna sección mencionaron esto o que era parte de la evaluación, pero bueno, nada que no se pueda hacer.

Y casi una semana adicional más de esfuerzos y listo, pude terminar la prueba. ¿Saben qué es lo peor? Que luego de unos correos indicando que estaba usando servicios gratuitos (Render + Vercel + Supabase como excelentes servicios), casi de inmediato como si ya lo tuvieran redactado, me envían un correo indicando que no pasé esta fase y me dan unos puntos a mejorar sacados de ChatGPT.

Esto es lo que más me causó odio, rabia y frustración. La decisión ya estaba tomada, y la justificación era sacado de un texto de ChatGPT donde me indicaron que "debo mejorar" en aspectos que ni siquiera pidieron. Por ejemplo, me piden que mejore en "DevOps y Automatización" añadiendo CI/CD Pipelines y que usara tecnologías como Terraform. Si uds. querían evaluarme en Terraform, era solo cuestión de pedirlo (ni en el Job Description ni en la prueba estaba este requerimiento).

Pero no se preocupen, acá les dejo el texto que me dejaron y mi respuesta (claro que iba a responder, estaba furioso).

Como ven, no podía quedarme callado, tardé 1 hora en escribir todo el texto y en responderles, porque de verdad es un correo bastante ofensivo.

Entonces, ¿Si fue una mala experiencia con Alegra?

¡Claro que si! De verdad no se si es parte de la empresa, del área de selección, de los evaluadores, o de la reclutadora en específico, pero siento que algo está mal o algo fallo. Me gustaría pensar que así como tomé estos eventos para fortalecerme en conocimientos (y como obtener paz mental), espero que si alguien de por allá lee esto, también puedan fortalecer su proceso.

Desenlace: qué me llevo de estas experiencias y qué les puedo dejar

En términos generales, me llevo el conocimiento de cómo pueden ser las próximas entrevistas, qué me pueden preguntar y qué conceptos debo mejorar. Por ejemplo, mi última buena experiencia de verdad me deja motivado a entender las bases de programación web, al menos las de Node.js y JavaScript/TypeScript.

Y les puedo dejar esta experiencia para que, si en algún momento les sucede una parecida (ya sea buena o mala), de pronto puedan tomar la misma iniciativa de escoger los puntos a mejorar para una próxima vez (y tal vez escribir un post acerca de su frustración hacia alguna en específico, no se).

Si quieren conocer las pruebas que dejaron, practicarlas para su futuro, guíarse en qué podrían hacer o qué no deben hacer (o incluso, para presentarse a esta misma), se las dejo por acá en la siguiente lista de enlaces.

• Primer documento con requisitos de "proyecto demo", Tech Test o reto técnico de Alegra: Reto técnico Node - 2024 - candidate
• Segundo documento con requisitos de "proyecto demo", Tech Test o reto técnico de Alegra: Jornada de Almuerzo Gratis - Desafío Backend Node.js
• Repositorio en GitHub con código fuente de primera versión de mi reto técnico en Nest.js: jcontrerasprince/alegra-kitchen-test
• Repositorio en GitHub con código fuente de segunda versión de mi reto técnico en "Node.js puro": jcontrerasprince/alegra-kitchen-test-v2
• Enlace público para probar aplicativo: Alegra | Kitchen test

También, no es tema mío cómo estén protegiendo sus procesos, pero si sí desean que un futuro sean más segura y no la puedan compartir fácilmente, les voy a dejar una sugerencia de cómo podrían hacerlo de mis propias palabras. Es más, se las regalo (me pueden brindar un café luego):

Como empresa conformada, con riesgos asumidos y disposición de recursos para obtención de resultados, pueden habilitar un repositorio privado desde su cuenta en GitHub (o GitLab, BitBucket, Azure DevOps, o lo que sea) y conectar un CI/CD Pipeline directamente a un servidor en su proveedor de cómputo en la nube (AWS, Azure, Digital Ocean, GCP (?)). De esta manera se aseguran que el repositorio no pueda quedar publicado, que los participantes no tengan que gastar en sus propios recursos, y ajustar el escalamiento vertical (más CPU o más RAM) a cómo uds. lo deseen.

De esta manera uds. controlan el ambiente y la información que se manipulará (repositorio, requisitos, etc).

Pero en fin, no quiero agobiarlos más. Después de escribir mi experiencia me siento un poco mejor y sigo teniendo mi motivación para continuar mi preparación continua, ya sea que quiera seguir donde estoy o quiero buscar campos más verdes. De todas maneras si quieren que hablemos de algún tema distinto o tiene alguna recomendación, sólo déjenme saber en un comentario o en mi perfil de LinkedIn, y con mucho gusto lo discutimos. ¡Que tengan muy buena semana!

TLDR; Así como tu aplicativo o solución tiene versiones, la base de datos también debe tener versiones, las cuales pueden actualizarse a una versión mayor a través de "upgrades" o ser revertidas a versiones anteriores con "downgrades". Esto asegura que tu aplicativo pueda ser usado en diferentes etapas de su evolución de acuerdo a los requerimientos con integraciones o actualizaciones del cliente. En este post hablamos sobre qué son "migraciones" de una base de datos y construimos 3 ejemplos para aplicativos en Node.js con Sequelize, Node.js con TypeORM y Flask con SQLAlchemy y Alembic.

Enlaces a documentaciones oficiales:

• Documentación de Sequelize
• Documentación de TypeORM
• Documentación de Alembic
• Documentación de Flask-Migrate

También te dejo este enlace donde se encuentran los ejemplos de es Post en GitHub: Migraciones con Node.js y Python.

Entonces, ¿Qué son las "migraciones" en una base de datos?

De manera muy corta y sencilla, las migraciones en una base de datos es el versionamiento del esquema, o de las tablas o de la relación entre entidades (ERD -Entity Relationship Diagram-), de acuerdo con la evolución de tu aplicativo.

Ejemplo de un aplicativo web de correspondencia

En un ejemplo práctico: imagina que has desarrollado un aplicativo web para el seguimiento de envío de correspondencia física, como sobres y paquetes, que consta de un frontend, un backend y una base de datos.

Este aplicativo tiene varias funciones y características, sin embargo, vamos a enfocarnos que un usuario final tiene la posibilidad de ver el próximo envío a recibir en una interfaz que le muestra desde donde viene, a donde se va a entregar y qué día será entregando, incluyendo una aproximación en la parte del día (mañana, tarde o noche).

El aplicativo es perfecto, cumple con todas las solicitudes de los stake-holders o interesados y tus jefes están sumamente contentos con el trabajo realizado.

Los usuarios finales deciden invertir para añadirle una segunda serie de funcionalidades y características a tu aplicativo, entre las cuales, está la posibilidad de indicar el peso total del paquete próximo a recibir porque los clientes quieren saber si es algo muy grande que deben manejar en la entrega.

Bien, el cambio no es difícil, es solo añadir una columna nueva en la base de datos, actualizar el esquema o clase en la lógica del backend y habilitar un campo en la interfaz del frontend para introducir esta información.

Tu plan para llevar a cabo esta actualización, y la de las demás funcionalidades y características, es actualizar los repositorios, por lo cual ya tus aplicativos frontend y backend tienen la nueva lógica, y para tu base de datos, decides que entrarás al servidor de producción y harás este cambio manualmente con un ALTER TABLE pedidos ADD peso_kg DECIMAL (16, 4).

Como podrás notar, esto de entrar a los servidores en producción es un ¡no no no! Existen muchos riesgos y peligros, créeme. Por más experimentado que uno sea, siempre va a ocurrir el error al momento de alterar o modificar algo en una base de datos en producción (por desgracia, aprendí esto a las malas).

La "migración" de la base de datos en tu aplicativo de correspondencia

Para resolver este inconveniente de actualización del esquema de la base de datos, creamos o "generamos" migraciones que se encarguen de alterar, añadir o eliminar objetos de tu base de datos de acuerdo al requerimiento de las nuevas versiones.

Pero recuerda esto super importante: así como en tu control de versiones en GitHub, GitLab, BitBucket, Azure Devops, o el servicio que estés usando, debe existir tanto una forma de subir o mejorar tu versión de base de datos ("upgrade"), como una forma de bajar o degradar la versión ("downgrade").

Entonces vamos a crear 2 métodos o funciones que hagan exactamente esto mismo:

1. La función de upgrade se encarga mejorar la base de datos desde la versión v1.0 a la v2.0.
2. La función de downgrade se encarga de degradar la base de datos desde la versión v2.0 a la v.10.

Puede suceder el caso de que un error inesperado afecta producción y la mejor solución es revertir todos los cambios y retornar a una versión anterior. En nuestro ejemplo sería regresar a la versión v1.0, por lo tanto es importante tener la función downgrade disponible.

Así como hacemos git revert para revertir cambios en el repositorio y retornarlo a un estado anterior, lo mismo logramos con el método downgrade.

Listo, de esta forma logras varios objetivos en tu aplicativo:

• Manejar tu base de datos con un control de versiones.
• Hacer actualizaciones de forma programada con cada salida o liberación de nueva versión de tu aplicativo.
• Tener un camino o vía para retornar los cambios en cualquier punto de tu aplicativo.

Si, a pesar de que es mayor trabajo al momento de desarrollar tu aplicativo, es la mejor forma de tener un control y trazabilidad completa de tu esquema de base de datos.

Ahora, ¿Hay algunos ejemplos prácticos que podamos usar en Node.js o Python?

Si, para esta pregunta te voy a presentar 2 ejemplos en Node.js, uno usando la librería Sequelize y otro usando la librería TypeORM. El último ejemplo lo haremos en Python con la librería Alembic.

De nuevo, todo el código referente a estos ejemplos lo encuentras en Migraciones con Node.js y Python

Aplicativo en Node.js (JavaScript) usando Sequelize

En este primer ejemplo creamos una aplicación desde cero en Node.js usando las librerias dotenv, express, pg, pg-hstore y sequelize. Como dependencias de desarrollador usamos las librerias de nodemon y sequelize-cli.

Como vamos a usar dotenv, creamos un archivo .env el cual tendrá la variable DATABASE_CONNECTION_URI = postgres://usuario:contraseña@localhost:5432/migrations_sequelize apuntando a la base de datos.

Creamos el archivo .sequelizerc para indicar los paths hacia los distintos archivos de configuración. En este ejemplo indicamos donde se encuentra el archivo config.js.

En el archivo config.js indicamos el objeto "development" para nuestras variables en el ambiente de desarrollo e indicamos los valores de url y dialect para nuestra base de datos.

Creamos el directorio migrations e indicamos nuestras migraciones creando documentos con el formato <timestamp>-<nombre-migracion>.js. Y en este archivo definimos las funciones up y down a ser exportadas donde está la lógica de subida de versión y bajada de versión de la base de datos.

"use strict";

/** @type {import('sequelize-cli').Migration} */
module.exports = {
  up: (queryInterface, Sequelize) => {
    // lógica para transformación a nueva versión
  },
  down: (queryInterface, Sequelize) => {
    // lógica para revertir los cambios
  },
};

Otra forma de crear este archivo es a través del uso de sequelize-cli, cuya herramienta nos permite usar el comando npx sequelize-cli model:generate --name MyModel el cual creará un archivo con el nombre <timestamp>-create-user.js en la carpeta migrations.

Nota: más información acerca de esta librería la encuentras en el portal de Sequelize Migrations.

Aplicativo en Node.js (TypeScript) usando TypeORM

En este segundo ejemplo creamos una aplicación desde cero en Node.js usando las librerias dotenv, express, pg, reflect-metadata y typeorm. Como dependencias de desarrollador usamos las librerias de @types/express, @types/node, nodemon, ts-node y typescript.

Con el uso de dotenv vamos a crear un archivo .env con la variable DATABASE_CONNECTION_URI = postgres://usuario:contraseña@localhost:5432/migrations_typeorm apuntando a la base de datos.

Creamos un archivo llamado data-source.ts donde usaremos la clase DataSource de typeorm. Adicionalmente importaremos todas las clases que representen un modelo de datos de las entidades del proyecto. Finalizamos el archivo exportando nuestro objeto AppDataSource con la configuración de nuestra fuente de datos.

Al ser un proyecto en TypeScript, también se debe configurar el archivo tsconfig.json, el cuál dependerá de cada proyecto o de tus preferencias en este framework.

Y por último creamos nuestros archivos de migraciones, los cuales llevan un formato parecido al de Sequelize: <timestamp>-<NombreMigracion>.ts (nótese el uso del formato Pascal Case).

import { MigrationInterface, QueryRunner } from "typeorm"

export class PostRefactoringTIMESTAMP implements MigrationInterface {
    async up(queryRunner: QueryRunner): Promise<void> {
      // // lógica para transformación a nueva versión
    }

    async down(queryRunner: QueryRunner): Promise<void> {
      // lógica para revertir los cambios
    }
}

Otra forma de crear este archivo es a través del cli usando el comando typeorm migration:create ./path-to-migrations-dir/PostRefactoring, el cual creará el archivo con el nombre de migración PostRefactoring usando el timestamp actual, para que puedas modificarlo a tu gusto.

Nota: más información acerca de esta librería la encuentras en el portal de TypeORM Migrations.

Aplicativo en Flask (Python) usando SQLAlchemy y Alembic

Y para nuestro último ejemplo creamos una aplicación desde cero en Flask usando las librerías Flask, SQLAlchemy, Flask-SQLAlchemy, Alembic, Flask-Migrate y psycopg2-binary.

En este aplicativo también podemos usar librerías para el uso de variables de entorno como lo es python-dotenv, sin embargo, en nuestro ejemplo nos saltamos esta parte. De todas maneras recuerda mantener la seguridad de tu aplicativo usando variables de entorno y secretos para las credenciales de los aplicativos. También para el caso de Flask vamos a crear un archivo config.py donde exportamos la clase Config con las variables SQLALCHEMY_DATABASE_URI = 'postgresql://postgres:password@localhost:5432/migrations_alembic' y SQLALCHEMY_TRACK_MODIFICATIONS = False.

El uso de Alembic para las migraciones tiene una lógica distinta a las de Sequelize y TypeORM: las migraciones no se crean a mano sino a través de cli (aunque éstas últimas también tienen la tienen opción, en Alembic es el método preferido). Entonces, en este caso usaremos el comando flask db init para inicializar nuestro sistema de migraciones, para luego usar el comando flask db migrate -m "Initial migration." y por último el comando flask db upgrade. En estos 3 pasos hemos inicializado la carpeta de migraciones (en el archivo app.py le hemos indicado al objeto migrate que usaremos el nombre de migraciones como carpeta).

En Alembic las migraciones van en la carpeta versions y no van enumeradas de menor a mayor a través del uso de timestamp o numeración con en las otras librerias, sino que se asigna una cadena hexadecimal de 12 carácteres o un "12 digit hex code", y el orden de las versiones se indica a través de las variables revision y down_revision dentro de cada archivo (pudiendo complicar a simple vista el orden de las migraciones para nosotros los humanos).

Dentro de cada archivo se encuentra el código a ejecutar para subir o bajar de versión.

"""Initial migration.

Revision ID: de3dad1e7bad
Revises: 
Create Date: 2024-06-26 12:26:49.288399

"""
from alembic import op
import sqlalchemy as sa


# revision identifiers, used by Alembic.
revision = 'de3dad1e7bad'
down_revision = None
branch_labels = None
depends_on = None


def upgrade():
    # lógica para transformación a nueva versión


def downgrade():
    # lógica para revertir los cambios

Y listo, usamos el comando flask db upgrade para actualizar nuestra base de datos para tener nuestro proyecto en Flask al día.

Nota: más información acerca de esta librería la encuentras en el portal de Flask-Migrate usando Alembic.

Conclusiones

Las migraciones de bases de datos son esenciales para mantener la integridad y la funcionalidad de una aplicación en crecimiento. Así como el código de una aplicación evoluciona, también lo debe hacer la estructura de su base de datos. Al implementar un enfoque estructurado para las migraciones, nos podemos asegurar que las actualizaciones y mejoras se realicen de manera controlada y reproducible, minimizando el riesgo de errores en producción. Esto es especialmente crucial en entornos donde la precisión y la consistencia son fundamentales, como en sistemas que manejan grandes volúmenes de datos o que tienen requisitos regulatorios estrictos.

Incorporar tanto las funciones de "upgrade" como de "downgrade" en el proceso de migración no solo permite mejorar la base de datos, sino también revertir cambios en caso de errores, así como también el uso de herramientas como Sequelize, TypeORM y Alembic hace que la creación y gestión de migraciones sea más accesible y menos propensa a fallas.

Y finalmente, adoptar un enfoque proactivo en la gestión de migraciones refuerza el compromiso de un equipo de desarrollo con la calidad y la estabilidad del software. A medida que las aplicaciones crecen en complejidad y alcance, la capacidad de gestionar cambios en la base de datos de manera eficaz se convierte en un diferenciador clave.

TLDR: Creé mi primera página web para mi marca personal y me faltó configurar el correo electrónico. Son 2 tipos de envío de correo que usa Ghost: 1) emails transaccionales para registrarse en el portal o solicitud de correo para reinicio de contraseña (a través de SMTP), y 2) emails de marketing para el envío de newsletter (a través de una API para correos masivos -bulk-). Intenté configurar Mailgun como se recomienda en la documentación, pero me salté un detalle y como tampoco quiero hacer mucho énfasis en el Newsletter, elegí AWS SES como proveedor de envío de correos y sólo dejé configurado los envíos transaccionales.

¿Mailgun o AWS SES?

Al momento de levantar un portal de Ghost, una parte fácil de dejar de último es la elección de proveedor de envío de correos, entonces ¿qué significa esto?. Recuerda que tu portal tiene la opción de crear usuarios para suscriptores o recibir un Newsletter apenas un post haya sido publicado.

La documentación de Ghost favorece Mailgun y explica que es muy fácil crear una cuenta, por lo que inicialmente elegir esta opción suena muy fácil, y más cuándo te menciona que tiene una suscripción de "pay-as-you-go", la cual cobra por cada correo enviado. Y adicional suma al hecho de que Mailgun no cobra cuando la factura es menor a $ 0.50 en USD, por lo que podemos decir que tenemos alrededor de 600 envíos de correos de forma gratuita.

Pero parte de esta información, para hoy 18 de abril de 2024, está un poco desactualizada.

Actualmente no hay forma de elegir el plan "pay-as-you-go", o no aparece entre las opciones de plan, por lo que se debe empezar desde el más económico de $ 35.00 para una capacidad máxima de 50,000 correos, lo cual no es gratis como podemos leer.

Esto hace que Mailgun no suene tan favorable. Y como por ahora el envío de Newsletter no es primordial, podemos obviarlo y configurar algún servicio para sólo los correos transaccionales, lo cuál se explica más adelante.

Por lo que respondiendo a esta pregunta: si quieres enviar todo tipo de correos, transaccionales y de marketing, configura Mailgun (incluso en la última sección te explico como crear una cuenta "pay-as-you-go" actualmente), y si solo necesitas para el manejo de usuarios, solo correos transaccionales, entonces configura AWS SES, o Gmail, o Mailchimp, o cualquier otro servicio que desees.

Pero, ¿qué son correos transaccionales y qué son correos de marketing?

La administración de usuarios creados con el correo electrónico requiere enviar información privada para verificar la dirección o enviar un email para cambiar la contraseña con algún token. Este tipo de comunicación son correos transaccionales y es parte vital de cualquier portal.

Cuando queremos enviar emails con una vista o invitación a leer el último post, información privada que es sólo para ciertos miembros, o simplemente enviar un correo para publicidad, a esto se le llama correo de marketing.

Ghost solo permite el servicio de Mailgun para el envío de correos de marketing, y tienen varias razones explicadas en su portal, y el TLDR: Mailgun usa mecanismos para evitar que los servidores de correos sean clasificados como spam.

Entonces, ¿cómo configuro AWS SES?

Una vez decidido es simplemente entrar a nuestra cuenta de AWS, ir a la sección de SES (Simple Email Service) y registrar nuestro dominio. En el post pasado explicaba el uso de AWS Route 53 y la adquisición del dominio a través de Namecheap. Como la configuración de los servidores de Namecheap apunta a los servidores de AWS, específicamente hacia los de Route 53, registrar el dominio en AWS SES es muy fácil, sobre todo porque al ser servicios de Amazon, de una vez los datos de los servidores y demás son registrados de forma automática.

Una vez registrado, es sólo esperar que se haya verificado el dominio y listo, ya tenemos esta parte configurada, ya podemos enviar correos de parte de jorgetech.dev. Ahora nos queda probar, pero para eso, tenemos que verificar una cuenta de correo electrónico.

AWS SES también permite verificar correos electrónicos, comprobar que nos pertenece y enviar mensajes con el correo verificado como destinatario, pero esta no es la razón de verificar el correo. Resulta que al registrar tu dominio, este aún continúa estando en un ambiente de Sandbox, o de pruebas, y solo es posible enviar correos a direcciones autorizadas o verificadas. Es más un tema de seguridad que otra cosa, y la forma de salir de este ambiente y transformarlo a uno de producción, es haciendo la solicitud a AWS. Recuerda que esto sube los topes de tus mensajes.

Teniendo registrado el dominio y con correo electrónico (puede ser uno personal), podemos enviar correos de prueba para verificar que todo está funcionando como debería. Una vez todo parece ir bien, lo que falta es solicitar salir del ambiente Sandbox.

Abrir un caso en AWS para salir de ambiente Sandbox

Esta parte es la más "personal", y digo personal, porque es un correo que una persona debe verificar y autorizar, o eso parece.

Mientras estás en el Dashboard de SES puedes ver un cartel azul aparecer indicando abrir un caso solicitando la salida del ambiente Sandbox. En el caso, se debe seleccionar si el uso del correo es para transacciones o para marketing. La idea es colocar una descripción de para qué vas a usar el correo, cómo piensas manejar la distribución de correos, cómo vas a manejar los usuarios, que proceso tienes para cuando un usuario no quiere recibir correos o el famoso botón de "unsubscribe" y demás.

Una vez creado este caso o ticket, te llegarán correos con la apertura de tu caso y probablemente te pidan más detalles. Una vez transcurra un tiempo entre 24 y 48 horas, te responderán con los términos y condiciones y la aprobación de la salida de ambiente Sandbox.

A partir de aquí, puedes eliminar tu correo personal como verificado y volver a probar desde SES. Sólo queda pendiente la configuración Ghost.

Configuración de correo en Ghost

Acá es sencillo, es ingresar a la instancia EC2 a través de SSH y buscar el archivo de configuración de ghost para cambiar algunos valores. Este documento está en la dirección /opt/bitnami/ghost/config.production.json y en el portal de Bitnami puedes encontrar más información de configuración.

Recuerda que este es el archivo JSON de configuración de Ghost para varias opciones, como las credenciales de la base de datos o la url de la página.

Luego, puedes ir al portal administrativo de Ghost e intentar ingresar al portal administrativo, dar click en el botón de "Forgot password" y esperar que el correo de reinicio de contraseña llegue tu bandeja, y listo: ya tienes configurado tu sistema de correo en Ghost.

¿Y cómo hago para crear una cuenta Mailgun con el plan "pay-as-you-go"?

Listo, entonces queremos crear una cuenta en Mailgun, pero no queremos pagar por un plan por una capacidad máxima de mensajes, sino pagar por lo que usamos. Tener disponible 50,000 mensajes para alguien que está empezando es demasiado.

En el portal de Ghost indica que se puede obtener una cuenta "pay-as-you-go", pero no indica exactamente cómo.

Alguien ya indicó en los foros de Ghost que no es posible abrir una cuenta y seleccionar la opción de pagar a medida que se usa, y preguntando qué opciones habían, se le respondió como hacer para obtener este plan: al momento de crear una nueva cuenta, llenar el formulario del método de pago, seleccionar un mes de prueba gratis, usar el servicio por unos días y luego darse de baja del plan, por lo que automáticamente la plataforma te asigna en el plan de "pay-as-you-go". De esta forma no se cobra por ningún plan y puedes usar el servicio pagando por los mensajes que envíes, pero si estos son menos de aproximadamente 600, puede que no se te facture al respecto.

En este enlace tienes toda la información del caso y las respuestas que estamos mencionando.

El error que cometí fue que creé la cuenta directamente y ya no me es posible seleccionar una prueba por un tiempo o trial, por lo que debo cancelar mi cuenta, esperar un tiempo y volverla a crear con la opción de prueba, usarla unos días (antes del corte) y luego cancelar la suscripción para que se me asigne el plan que deseo.

En resumen, el portal ya se encuentra habilitado para suscribirse. Por los momentos no tengo un plan de Newsletter o secciones exclusivas para miembros, pero si deseo añadir esto en un futuro, dependiendo de como vayan las cosas.

Si tienes alguna duda de cómo hacer alguno de estos pasos, déjame saber y con seguridad podemos resolverlo. !Feliz día!

TLDR: Quise crear mi propia página web tipo Blog, usando alguna tecnología que fuera novedosa, descartando viejos conocidos en PHP como WordPress o Drupal. También quise implementar el proceso de levantamiento usando algún servicio de cómputo en la nube como AWS o Vercel. Terminé eligiendo Ghost como tecnología, descartando el servicio que ellos ofrecen para los blogs y creando una instancia en AWS EC2. No salió como esperaba, tuve unos inconvenientes y me apoyé con unas imágenes ya existentes de Bitnami para la puesta en servicio. Lo demás fue configuración y aquí estamos.

Elección de Ghost (razones personales, puedes saltar esta sección)

Primero, dentro de lo que quería hacer, investigué varias herramientas para creación de páginas web (no solo blogs) que sean contenidas en un solo aplicativo (backend y frontend en el mismo despliegue) y que estén basadas en node.js.

En el mundo de node.js no hay muchas opciones, las más relevantes son Headless CMS: Strapi y Directus. Dos espectaculares opciones que llegan hasta ese punto, el de Headless.

Estas 2 opciones poseen todo lo que uno necesita para administrar contenido: manejo de usuarios, permisos, documentos, imágenes, rutas, etc. Sin embargo, como su nombre indica, son Headless, o lo que en la practica traduce, sólo es el backend o la administración del contenido. Para mi solución, quería desplegar usando un solo proyecto o repositorio, y a pesar de que podía iniciar un proyecto en React.js o Next.js con alguna librería como MUI, no quería llegar hasta ese punto o complicación.

Otro punto a tomar en cuenta, es que en el trabajo estábamos evaluando un cliente el cuál insistía con un CMS completo, que a su preferencia, quería usar WordPress. Desde el departamento sabemos que estas tecnologías ahorran en esfuerzo a la hora del despliegue, pero dificultan (y en gigantes rangos) el proceso de integración y crecimiento propio de la solución, pero en nuestra opinion, esta es la principal razón por la que aún no logramos superar PHP como lenguaje: proyectos completos como WordPress o Drupal nos enamoran para su uso, alejándonos de lenguajes de programación más eficientes, óptimos y con mejores curvas de aprendizaje.

Nunca había escuchado Ghost, y a pesar de que al inicio tuve algunas confusiones acerca de cómo resuelve el contenido, me gustó saber que:

• Es un CMS que permite generar páginas y posts.
• Posee una interfaz completa para la creación y edición de contenido.
• Está enfocado a páginas por suscripción, sin embargo, esto es opcional.
• Posee Newsletter, lo cuál permite crear campañas de correos personalizadas.
• La interfaz está impulsada por Handlebars, lo cuál es una tecnología fácil de conocer.
• Existen varios temas gratuitos y otros más que pueden adquirirse por un precio, que complementan y mejora todo lo que Ghost puede hacer.
• Las rutas, lenguajes, tags y otros elementos pueden personalizarse.

Y queriendo usar algún lenguaje de fácil uso para mi como node.js, está fue una elección fácil que me entusiasmó. Pero igual, les recomiendo tomar en cuenta las contras:

• Manejo de un sólo Content-Type (posts).
• No posee integración nativa con servicios de archivos o media files como AWS S3.

De todas maneras, sigo pensando que es una buena solución para portales sencillos: blogs personales, páginas de empresas, información de podscasts o eventos, etc.

Elección de AWS (también personal, puedes continuar con la siguiente sección)

Este es un tema un poco más directo que la elección de Ghost. Durante mi carrera, he trabajado con uso de cómputo en la nube con los proveedores Azure y AWS. Cada uno tiene sus pros y contras, sin embargo, en mi día a día actual, es más frecuente la elección de AWS debido a que su principal ventaja es la economía de precios (o eso aparenta).

Sin ahondar mucho, me gusta probar y saber qué y qué no se puede hacer con este servicio de cómputo en la nube, y con el ofrecimiento de 750 horas de cómputo gratis durante un año, me parece una buena opción.

El portal de Ghost ofrece un servicio de despliegue de tu portal (TryGhost), con tu propio dominio, por $ 9.00, el cual es un buen precio a mi parecer, pero sigo pensando en que quiero desplegar mi propia solución.

Como dije al inicio, quería hacer un despliegue desde sus inicios, usar las tecnologías de AWS y aprovechar las 750 horas ofrecidas, por lo que de una vez tomé esta opción.

Primeros pasos y fallos

Bien, ya pongámonos en modo programador y despleguemos nuestro propio portal.

Antes de iniciar, debo adquirir mi propio nombre de dominio o DNS (Domain Name System), que es cómo voy a ser conocido en el internet. Me dirigí a Namecheap y adquirí jorgetech.dev por la módica suma de aproximadamente $ 11.00.

Crear mi primera instancia de AWS EC2

Listo, ahora simplemente creo una instancia en AWS EC2 con una imagen en Ubuntu y hago la instalación. Todos los pasos se encuentran en la página de Ghost. Ya había "jugado" con esta tecnología en local, por lo que simplemente era instalar en mi nueva máquina virtual, subir el tema de mi elección (desde la tienda o personalizado) y listo, ¿suena fácil no?

En primer lugar, accedí a mi cuenta de AWS, me dirigí a la sección de EC2 e inicié una instancia micro (permitida para las 750 horas gratuitas) usando la imagén de Ubuntu que había mencionado. En menos de 5 minutos, ya podía conectarme a través del protocolo SSH a mi máquina virtual (recuerden crear las credenciales necesarias para la conexión).

Listo, entonces es solo ingresar y seguir los pasos:

1. Crear un nuevo usuario.
2. Actualizar todos los paquetes.
3. Instalar NGINX.
4. Instalar MySQL.
5. Instalar Node.js.
6. Instalar Ghost-CLI.
7. Crear el directorio y habilitar los permisos para el usuario de la máquina.

Y listo, ya solo falta el paso 8, instalar Ghost.

8. Instalar Ghost con el comando ghost install.

Aquí es donde todo no correo como esperamos. Esta instalación nunca ocurre, la máquina virtual dura horas instalando Ghost hasta que se pierde la conexión. Pensé que era un problema de falta de memoría física (AWS EBS), por lo que repetí la creación de la instancia dejando a la máquina con 50 GB de memoria, pero aún así, la instalación se congelaba.

Probando con otras imágenes oficiales de AWS

Al momento de crear una instancia, tenemos otras opciones para la imagen, desde Linux, Debian, una versión creada específicamente por Amazon, hasta instalar Windows o MacOS.

Obviamente todos los intentos fueron con las distribuciones de Linux (donde los comandos no son siempre iguales), sin embargo, sucedía lo mismo: siempre se congelaba en el paso 4 o 5 de la instalación de Ghost.

Por lo que ya había que recurrir a la magía del internet. Resulta que este problema, no era único para mi. Como pueden ver en el post, varios usuarios reclamaban el mismo inconveniente, por lo que eran un mensaje en Github donde un usuario indicaba que este inconveniente era porque la máquina virtual sólo tenía 1 GB de memoria RAM y se necesitaban mínimo 2 GB. Esto era contradictorio a la página de Ghost, donde se indica que mínimo, 1 GB de memoria RAM es suficiente.

Lástima, todo parecía muy sencillo. Luego de esto, sólo quedaba la configuración de NGINX, el dominio y los certificados.

Esto fueron varios intentos, cada uno durando entre 1 hora y 3 horas. Al 3er día me rendí con esta opción y empecé a buscar alternativas.

Pude haber elegido Digital Ocean para el despliegue, o directamente adquirir el servicio desde la página de Ghost, sin embargo, quería insistir con esta opción. Dudo mucho que hayan clientes pequeños en mi trabajo para proponer esta opción, pero quien sabe, nunca está de más tener esto en el arsenal (al menos una landing page con redirecciones puede ser muy fácil para vender).

Y aquí es cuando descubrí las bondades de desplegar una instancia usando imágenes de terceros, como los el proveedor Bitnami, quien justamente para Ghost tienen una imagen de uso gratuito.

Tutorial o guía de despliegue de Ghost en AWS EC2 con uso de una imagen de Bitnami

Vamos a seguir los pasos de manera general de como instalar Ghost en AWS usando una imagen de instancia de Bitnami:

1. Ingresamos a nuestra cuenta de AWS, nos dirigimos a la sección de EC2 y seleccionamos crear una instancia.
2. En la sección de imagen, nos vamos a la sección de imágenes de terceros.
3. Buscamos Ghost de Bitnami y seleccionamos la que necesitamos.
4. Seleccionar un "key pair" para la instancia (para la conexión a través de SSH).
5. Seleccionar un "security group" que permita conexiones desde cualquier IP (Anywhere).
6. Configurar unos 30 GB de storage EBS.
7. Esperamos por la finalización del despliegue y luego nos vamos a los mensajes de Log de la instancia.
8. Buscamos la sección donde se inicia el usuario y contraseña para ingresar. Este proceso es para obtener las credenciales para ingresar al aplicativo por primera vez: encuentra las credenciales de la aplicación.
9. En la sección de Getting started puedes obtener información adicional de cómo ingresar a la base de datos o la configuración inicial de Apache.
10. En la sección de Configuration hay información adicional para otras configuraciones del servicio SMTP o Apache.
11. En la sección de Administration se encuentra la mayor porción de información para el servidor en Ghost.
    1. Esta sub-sección te muestra los comandos para iniciar, reiniciar o detener los servicios de Ghost.
    2. Sub-sección a seguir para configurar el dominio del servidor.
12. En esta guía se encuentra la información para configurar los certificados SSL y el DNS a través de HTTPS.
13. Crear una Elastic IP desde AWS y asignarla a nuestra instancia de Ghost.
14. También se debe configurar el DNS (para mi caso usé Namecheap en la compra de mi dominio). Este proceso es sencillo y directo. Cuando estés configurando el dominio, ve a la sección de "Advanced DNS" para el dominio y crea un "A Record". Selecciona "Host" como "@" e introduce el Valor de la Elastic IP que configuraste antes. Guarda esto y crea un segundo "A Record", selecciona "Host" como "www" y introduce el Valor para que sea el mismo del Elastic IP que configuraste antes.

Hay varios puntos y fuentes de información adicional que dejaré por acá para vuestro interés:

• Readme en Github por el usuario bdeitte donde explica el proceso de configuración de Ghost con AWS y Namecheap.
• Consulta en Stack Overflow donde se concluye que para la instalación de Ghost se requieren 2 GB de memoria RAM en vez de 1 GB.

Se que hay otros datos importantes, sin embargo, si presentas un inconveniente durante la instalación, déjame saber para ayudarte o guiarte durante el proceso.

Este es mi blog, de parte de Jorge. Es un nuevo lugar para todos esos temas, pensamientos, tutoriales, ejercicios, pruebas de concepto e historias que quiero compartir sobre la programación de aplicativos web, softwares, tecnologías y demás.

Soy programador de aplicativos web, por lo que hay muchas ideas que quiero que conozcan y tal vez si uno o varios aprenden algo al respecto, me sentiré más que conforme. También quiero mostrar de lo que soy capaz y tener un lugar donde demostrar todos mis conocimientos.

Esto apenas está empezando, así que prepárate y recuerda, si quieres ver algún tema en específico, sólo déjame saber.