DEV Community: Luis Angel Ortega

Dropdowns y Toggles con puro CSS

Luis Angel Ortega — Mon, 07 Nov 2022 16:30:56 +0000

Podríamos imaginar las tecnologías de la plataforma en la cual trabajo, Build It, como un platillo; donde Ruby on Rails es nuestro platillo principal pero está acompañada de una buena porción al lado de JavaScript a través de Stimulus JS, y mientras esta trae la funcionalidad y ese sentimiento mágico de una aplicación de una sola página (SPA, por sus siglas en inglés) hay cosas que queremos mantener simple en lugar de usar una bomba para matar una hormiga, como un profesor de la universidad solía decir. Por ello decidimos tomar nota de la página de Apple a la hora de manejar menús desplegables o dropdown y hacerlo por medio de puro CSS y HTML; sin requerir una línea de JavaScript.

Los pilares

Nuestros dos pilares en la vista serán los elementos <input> de tipo checkbox y las etiquetas <label>. Formaremos nuestro esqueleto básico de la siguiente manera:

<input id="toggle" type="checkbox"></input>
<label for="toggle"></label>

Estaremos usando la propiedad checked de los inputs tipo checkbox para poder controlar el contenido que mostramos y cuando lo mostramos. Para esto nos estaremos apoyando del elemento <label> ya que al relacionarlo a través de su propiedad for también será afectado por el cambio de clases cuando la propiedad checked de nuestro checkbox se encuentre presente.

Todo nuestro código realmente se encontrará dentro de <label> en dos secciones: container y toggle como se muestra a continuación.

<input id="toggle" type="checkbox"></input>
<label for="toggle">
  <div class="toggle">
    <!-- El elemento con el cual el usuario va a interactuar -->
  </div>
  <div class="container">
    <!-- Lo que queremos mostrar-->
  </div>
</label>

La magia

Ahora que ya tenemos nuestro esqueleto con HTML listo, es hora de agregar el CSS que le dará el toque mágico a nuestro componente:

#toggle {
  display: none;
}

.container {
  display: none;
}

#toggle:checked + label .container { 
  display: inherit; 
}

Nuestro input con el id de toggle nunca se mostrará para que no tengamos la checkbox presente en nuestra página, lo que mostraremos y con lo que interactúa el usuario es lo que esté dentro de nuestra div con clase de toggle. Una vez que le den click a nuestro toggle el input tendrá el valor de checked y con #toggle:checked+label afectamos el estilo de nuestro para obtener un resultado como el siguiente

Y con un poco más de estilo (cortesía de Thulio Philipe) podemos tener resultados como este

O como los ejemplos que tenemos dentro de Build It

Un pequeño popover que siempre está presente, dando información vital al usuario

O un menú de filtros que puede ser mostrado con facilidad.

Como podemos ver, el CSS moderno nos permite hacer páginas interactivas sin necesidad de hacer un script para ello; dándonos una nueva solución a un problema con infinidad de maneras de resolverlo, por lo que habrá que considerar las necesidades del proyecto y que es lo que más conviene.

Finalmente les dejo un repositorio con un par de ejemplos vistos en este artículo para referencia futura y los invito a ver la plataforma y en especial mi perfil, donde podremos conectar para proyectos futuros.

Why should we teach with Open Source Software?

Luis Angel Ortega — Thu, 25 Nov 2021 17:42:29 +0000

Full article originally available at Aviyel.

Your 20s are a time in your life when some of your friends are still in college while others are already in the workforce. This can give you a broad perspective in transitioning from student life to a professional one, and this acquired vision helped me realize that we should be teaching primarily with open source software (OSS).

To build a career in tech these days, students have to start early as technology is rapidly evolving through innovation. This has become a challenge for the education sector to equip students with basic computer literacy. This situation has arisen because currently, every facet of human life is touched upon by computer technology.

To equip students with primary computer literacy, schools and colleges have a mandatory policy of giving lectures in basic computer programs at a very early age. These programs include – learning to operate computers or laptops, a basic understanding of MS Office, which includes MS Word, MS Powerpoint, MS Excel etc. Many of these fields have received tremendous responses from the job market, such as graphic designing, online marketing, video editing, etc.

These skillsets have become an essential part of every curriculum across the world. And since setting up a computer lab for 40 students costs a bomb to educational institutions, these institutions are forced to buy proprietary software, which adds to the recurring bill. This forces some educational institutions to use an illicit version of this software. We should not allow such pedagogy to enter our children’s curriculum.

An alternate method has to be used to cut down software invoices, i.e., using open-source software for all kinds of learning purposes. First of all, there are almost alternate sources to every type of proprietary software in the market. These open-source software have been built by open-source communities across the globe and provided for free of cost. Not only this, you can even patch your updates and share them with the whole world. This significantly reduces the software invoice for all kinds of learning purposes.

The problem

If you’re lucky, your college will give you the tools that the employers want you to learn. This can be from Maya or AutoCAD to the Adobe Suite. The schools teach this tool because they are the standard in the industry; they want you to get familiar with them. Still, not everyone has the same opportunities. These licences are expensive, and if the student needs them at their personal computer, there’s a chance that they either need to buy them or get an illegal copy of them in the most common scenario (especially during the pandemic).

Piracy is an everyday occurrence in most developing countries simply because it’s cheaper than buying a licence. Even if downloading cracked software can come with serious security risks, people use it to avoid buying software. But piracy should not be the only option. There’s a whole world of OSS that can solve this; why use Maya to learn 3D modelling if you can use Blender, why bother with the high prices of the Adobe Suite if you can find alternatives like GIMP, Audacity and OpenShot.

Skills can be translated from software to software, even if it takes effort to do it; this way, you’re giving them equal access to every one of your students since they’re not only open and accessible but multiplatform. Stop dealing with compatibility problems since everyone has a different cracked version of Maya.

After school, students could do freelance work without worrying about the limitations of student licences, which help you learn the software but not make money with it. Does a friend need Point-of-Sale Software? Just fire them an instance of FloreantPOS without worrying about licensing.

The idea is lovely, but most people stop when they encounter the problem of finding said OSS. Proprietary software can be easily found via the app stores, but you’ll often need to know what you’re looking for with OSS, but this is changing. Projects like Aviyel function like a hub for the community; you’ll find the software you need, tutorials for it, news and a community to support you if you ever get stuck.

Working with open-source software sets your skill set at a premium level in the job market as you tend to know more about the functionalities of products and output generated from those products. Employers love the guys who work using open-source projects. Since open-source is free to use for all, even large MNC’s benefit from these tools. There would have been no Facebook, IBM, Amazon without open-source.

The love for open-source is growing day-in-day-out among big MNC’s due to monetary reasons. They only have to hire a skillful employee and provide them with a laptop, and voila, they can build one of the most intuitive things this world has ever seen. Thus, if educational institutions take the route of educating their pupils from open-source resources issue of unemployability would not arise in the software job market.

This is because proprietary software has much more finishing than open-source. This leads to a gap of skill between the users. A user of Blender might know a few extra bits about designing than a user bred on Adobe products. This happens because an open-source user has to understand features in-depth, whereas proprietary tools have an excellent finish in the product, making it easier to use. However, open-source is free of cost, whereas proprietary tools might cost a bomb.

Parting note

If we want to change the abusive corporate practices of proprietary software companies, we need to do as Michael Jackson once said and “start the change with the man in the mirror”. Change is necessary if we want to give everyone the same opportunities for learning the skills of today and tomorrow. Thankfully with Aviyel, you’ll never walk alone.

Thinking outside the box: An online resume with Docz

Luis Angel Ortega — Thu, 21 Oct 2021 16:45:34 +0000

One of the best traits of humankind is its curiosity. It is so human that in honor of it we named a Mars rover "Curiosity" in 2003.

Talking about curiosity in the developer world, open source projects top the list, since by nature they invite us to experiment, modify and share what else we can do with them. This is why I propose to think a little outside the box with Docz - a software documentation tool that is completely open source.

Index

What is Docz?
Creating our Docz project
Adding our information
Adding a custom component
Deploy to GitHub Pages
Parting note

What is Docz?

Docz is a Gatsby-based project that simplifies the process of documenting other projects without worrying about configuration, speed and support.

It provides a library that allows you to write MDX pages instead of HTML or JSX files, handles the routing and provides plugins for all the other needs that you may have. All of this results on projects anyone can contribute to!

Is this simplicity and friendliness that makes Docz a great option for more than just docs.

Creating our Docz project

Before we can jump into Docz, there are some prerequisites that you will need have in order to create the project:

NodeJS
Yarn or npm

Now that you have the prerequisites, let’s start by creating a new React app with create-react-app (CRA)

Go to your terminal and run:

npx create-react-app my-resume

If you don’t have CRA installed, npm will ask you if it’s okay to install create-react-app type y to continue and let CRA create the new project.

We are using the command npx instead of npm since we want to execute a package, not install it to a project. You can read more about it here.

Now lets move to the directory of our project and install Docz.

cd my-resume
yarn add docz # or npm install docz

Then let’s remove everything that CRA created for us inside the src folder, since we don’t need it.

rm src/*

Also, it is a good idea to add to the .gitignore the .docz folder since we only needed for development.

# .gitignore

# Docz generated files
.docz/

Let’s go and create a file named index.mdx and a hello world header in the following way.

<!-- src/index.mdx -->

---
name: Hello World
route: /
---

# Hello world from Docz!

And it’s time to run our development server to see what we have just created.

yarn docz dev # or npm run docz dev

If you get an error ERROR #98123 while trying to run the development server, just delete your yarn.lock or package-json.lock and the node_modules folder and install the dependencies again.

Et voila! We have successfully created our Docz project.

Now is a good time to commit your files!

Your time to shine

Before we start adding more pages, let’s create a configuration file named doczrc.js on the root of our project. This will help us to set some meta tags easily, but it manages all the configuration of our project.

// doczrc.js

export default {
  title: "Luis Angel Ortega",
  description: "Hello, I'm Luis Angel and this is my resume made with Docz!",
  ignore: ["README.md"]
}

The title key will set the suffix for our title tag and it will change the text on the top left corner of our project, since it’s an online resume I recommend using your name in this field.

Then, the description key that we added will modify the meta description tag on our webpage to display it when it’s looked up or shared online.

The last key will tell Docz to ignore some files and don’t display them on the webpage, as is in this case with the README file.

Now let’s add more pages! I’ll add a contact page with my socials and resume one in the following way

<!-- src/contact.mdx -->

---
name: Contact
route: /contact
---

# Contact me! 🗣

---

Let's talk! You can find me on these platforms:

- ✉️ [Email](mailto:hey@luisangelme)
- 🤝 [LinkedIn](https://www.linkedin.com/in/luisangel-ortega)
- 🐙 [GitHub](https://github.com/LinkSake)
- 🐦 [Twitter](https://twitter.com/LinkSake)
- 🌐 [Website](https://luisangel.me)

<!-- src/resume.mdx -->

---
name: Resume
route: /resume
---

# Resume 💼

---

## Work Experience

<details>
  <summary>Software Developer. <a href='growthconstant.co' target='_blank'>Growth Constant</a>, (Mar. 2021 - Currently)</summary>
  <div style={{marginLeft: '1em'}}>
    <li> Full stack developer (Ruby on Rails) and copywriter for the first project of the start-up: <a href='virtualdash.co' target='_blank'>Virtual Dash </a>.</li>
  </div>
</details>

<details>
  <summary>Backend Developer Intern. <a href='facturasamurai.com' target='_blank'>Factura Samurai</a>, (Aug. - Dec. 2020)</summary>
  <div style={{marginLeft: '1em'}}>
    <li> Implemented the user authentication on the Elixir API. </li>
    <li> Learn and developed serverless services (Cloudflare Workers) with TypeScript. </li>
  </div>
</details>

<details>
  <summary>Full Stack Web Developer. <a href='biobot.farm' target='_blank'>biobot.farm</a>, (Aug. 2019 - Jun. 2020)</summary>
  <div style={{marginLeft: '1em'}}>
    <li> Successfully launched a new service (web application) that was developed form scratch while learning React. </li>
    <li> Documented the web application and taught a colleague to mantener said application. </li>
    <li> Improved speed, functionality and readability of a Python API and micro-services. </li>
  </div>
</details>

## Education

<details>
  <summary>Bachelor's Degree in Information Technologies and Telecomunications. <a href='ulsachihuahua.edu.mx/site' target='_blank'>Universidad La Salle Chihuahua</a>, (Aug. 2016 - Dic. 2020)</summary>
  <div style={{marginLeft: '1em'}}>
    <li> Degree on engineering on information and telecommunication with specialization on mobile development. </li>
    <li> Academic exchange semester at La Salle Ramon Llull University (Barcelona, Spain) from January to June 2019 with the Computer Engineering degree. </li>
  </div>
</details>

## Skills

<details>
  <summary> Languages </summary>
  <div style={{marginLeft: '1em'}}>
    <li>Spanish: Native</li>
    <li>English: Advanced (TOFEL ITP: 627)</li>
  </div>
</details>
<details>
<summary> Tech </summary>
  <div style={{marginLeft: '1em'}}>
    <li> <b> Professional level </b> </li>
    <div div style={{marginLeft: '1em'}}>
      <li>JavaScript (Node, React, Next)</li>
      <li>Ruby (Rails)</li>
      <li>SQL (MySQL, PostgreSQL)</li>
      <li>Version manager (Git)</li>
      <li>HTML & CSS</li>
    </div>
  </div>
  <div style={{marginLeft: '1em'}}>
    <li> <b> Novice Level </b> </li>
    <div style={{marginLeft: '1em'}}>
      <li>Python (Bottle)</li>
      <li>Docker</li>
      <li>UNIX</li>
    </div>
  </div>
</details>

## Achivements

- Essential part of the winning team of the following hackathons:
  - Ideacon (2018)
  - Reset (2018)
- Essential part of the 2nd place team of the Blockchain Mobility Hackathon 2019 in Barcelona, Spain.

As you can see, using MDX means that we can use Markdown syntax and JSX in the same document, giving a lot of flexibility and customization to our Docz projects.

At the end they will look something like this:

Spice it! Adding a custom component

Now let’s focus on our index.mdx file. Let’s change it’s title to "About me"

<!-- src/index.mdx -->
---
name: About me
route: /
---

# Hello world from Docz!

And then, create a components folder inside of the src directory. There create a welcome.jsx component, this will replace our Markdown heading to make the root page more interesting.

// src/components/welcome.jsx

import React from 'react'

const Welcome = ( props ) => {

  const style = {
    container: {
      display: 'flex',
      flexDirection: 'column',
    },
    textContainer: {
      textAlign: 'center'
    },
    imgContainer: {
      paddingTop: '1em'
    },
    img: {
      display: 'flex',
      margin: 'auto',
      maxWidth: '40%',
      borderRadius: '50%',
    },
  }

  return (
    <div style={style.container}>
      <div style={style.textContainer}>
        <h1>{props.title}</h1>
        <span>{props.children}</span>
      </div>
      <div style={style.imgContainer}>
        <img style={style.img} src={props.img} alt={props.title}/>
      </div>
    </div>
  )
}

export default Welcome

Here I just made a quick component that takes a title, some text and displays it all centered and the image as a circle, but you can make your creativity go wild on this one!

Next, let’s change index.mdx to import our component and use it to give a warm welcome to all the visitors on our webpage, here is how it looks:

It's alive! Time to deploy

ow that we have our Docz project it’s time to build it and deploy it to GitHub Pages (since we already have the repository there).

First we need to configure some things, go to your doczrc.js file and add a dest key with the value “/docs” and a base key the name of your repo as it’s value.

// doczrc.js

export default {
  title: "Luis Angel Ortega",
  description: "Hello, I'm Luis Angel and this is my resume made with Docz!",
  ignore: ["README.md"],
  dest: "/docs",
  base: "docz-resume"
}

The first key is telling Docz to build the project into the docs directory, we’re doing this since GitHub Pages expects the static files to be on the root or docs directories.

The base key is changing the base folder to match the name of the repo in order to make the public files and links to work in GitHub Pages.

Once we have everything correctly configured, we need to build the project with the following command:

yarn docz build # or npm run docz build

When it is done, you will see a docs folder on your project. Commit and push everything to your repo. After that, let’s go to the settings tab on your project and in the left menu go to the Pages section.

Then select your main branch (or the branch on which you are working on) and select the docs folder.

And that is it! In a few minutes your website should be live on the link that GitHub has given you.

The future awaits

In this article we only scratched the surface of what Docz is capable of, so be sure to check their documentation to learn more.

I encourage you to read about them to make your resume stand out from the crowd and always remember to support the creators of this amazing project and contribute if you can.

Find the repo of the project here. For end result, check out GitHub.

Docker + Rails: Una solución para tus dolores de cabeza

Luis Angel Ortega — Mon, 06 Sep 2021 23:24:35 +0000

¿Has llegado a pasar una semana solamente tratando de correr el proyecto al que te acabas de unir? ¿O tu aplicación no corre en producción como corría en local?

Hay una multitud de factores que pueden contribuir esto, por ello Docker nos ofrece una solución con la cual podemos tener un mayor control sobre estas variables a través de las computadoras que sean necesarias.

Dicho esto, en este articulo veremos como falicitarnos la vida al tener toda nuestra aplicación de Ruby on Rails corriendo sobre Docker; incluidas las bases de datos que sean necesarias.

Prerequisitos

Para poder seguir esta guía necesitaras tener Docker instalado así como un proyecto el cual quieras dockerizar, si solamente quieres prácticar puedes usar este proyecto de ejemplo el cual necesita una conexión a Postgres y a Redis para funcionar.

¿Eres impaciente? ¡Puedes clonar esta rama del proyecto donde ya se encuentran los archivos necesarios para correr el projecto dentro de Docker!

Primero viene el Dockerfile

Lo primero que haremos será hacer una imagen personalizada para nuestro proyecto, así que crearemos un archivo en la raíz del mismo llamado Dockerfile

touch Dockerfile

La primer linea de nuestro archivo definirá la imagen de la cual nos basaremos, en este caso será la imagen oficial de Ruby, pero usaremos la versión de Alpine para tener una imagen más ligera como resultado.

FROM ruby:3.0.1-alpine

⚠️ Asegurate que la version de Ruby (ruby:X.X.X-alpine) sea la misma que en tu proyecto, o tendrás errores a la hora de tratar de construir la imagen. Puedes encontrar la versión que usa tu proyecto en tu Gemfile.

Después sigue la parte más dificil de este Dockerfile, instalar la dependendencias necesarias para que funcione el proyecto; las que se muestran aquí son las que funcionan para nuestro proyecto de ejemplo, que incluyen las necesarias para realizar una conexión con Postgres, pero tendrás que descubrir cuales son necesarias para tu proyecto.

FROM ruby:3.0.1-alpine

RUN apk add --update --no-cache --virtual run-dependencies \
build-base \
postgresql-client \
postgresql-dev \
yarn \
git \
tzdata \
libpq \
&& rm -rf /var/cache/apk/*

Puedes esperar a construir la imagen (docker build .) para revisar el error que imprima Docker, con eso podrás ir averiguando que depenencias hacen falta 😉

La última linea (rm -rf /var/cache/apk/*) borra los paquetes de las dependencias que acabamos de instalar, esto ahorrará espacio en la imagen.

Lo siguiente que debemos de realizar es crear un directorio dentro del contenedor donde podamos copiar el código de nuestra aplicación para su ejecución, eso lo haremos con el siguente comando dentro de nuestro Dockerfile.

FROM ruby:3.0.1-alpine

RUN apk add --update --no-cache  --virtual run-dependencies \
build-base \
postgresql-client \
postgresql-dev \
yarn \
git \
tzdata \
libpq \
&& rm -rf /var/cache/apk/*

WORKDIR /docker-rails

¡Recuerda cambiar el docker-rails por el nombre de tu proyecto!

Así como le dimos un hogar a tu proyecto dentro del contenedor que crearemos, las gemas del mismo necesitan una carpeta también. Por ello, le informaremos a bundler donde colocarlas a través de una variable de ambiente.

FROM ruby:3.0.1-alpine

RUN apk add --update --no-cache  --virtual run-dependencies \
build-base \
postgresql-client \
postgresql-dev \
yarn \
git \
tzdata \
libpq \
&& rm -rf /var/cache/apk/*

WORKDIR /docker-rails

ENV BUNDLE_PATH /gems

Y aunque ya instalamos las dependencias necesarias para correr Rails dentro del contenedor, tu proyecto necesitará algunas gemas y algunos paquetes de JavaScript para funcionar de manera correcta, vamos a encargarnos de eso de la siguiente manera.

FROM ruby:3.0.1-alpine

RUN apk add --update --no-cache  --virtual run-dependencies \
build-base \
postgresql-client \
postgresql-dev \
yarn \
git \
tzdata \
libpq \
&& rm -rf /var/cache/apk/*

WORKDIR /docker-rails

ENV BUNDLE_PATH /gems

COPY package.json yarn.lock /docker-rails/
RUN yarn install
COPY Gemfile Gemfile.lock /docker-rails/
RUN bundle install

Ahora que ya tenemos todo lo necesario para que funcione tu proyecto, vamos a copiar el código al contenedor dentro de la que carpeta que creamos con el comando WORKDIR.

FROM ruby:3.0.1-alpine

RUN apk add --update --no-cache  --virtual run-dependencies \
build-base \
postgresql-client \
postgresql-dev \
yarn \
git \
tzdata \
libpq \
&& rm -rf /var/cache/apk/*

WORKDIR /docker-rails

ENV BUNDLE_PATH /gems

COPY package.json yarn.lock /docker-rails/
RUN yarn install
COPY Gemfile Gemfile.lock /docker-rails/
RUN bundle install

COPY . /docker-rails/

¿Por qué copiamos primero los manifiestos (package.json, Gemfile, etc.) y después el resto del proyecto? Esto nos evita tener que reinstalar las dependencias (dado a que se quedan en caché) después de cambiar el código base y reconstruir la imagen; de esta manera solo cuando cambien los manifiestos se volverá a correr sus comandos de instalación.

Finalmente le diremos a Docker que comando correr cuando iniciemos nuestro contenedor (rails), así como los argumentos de este (s -b 0.0.0.0) y que puerto exponer para que nosotros podamos accesar a nuestra aplicación.

FROM ruby:3.0.1-alpine

RUN apk add --update --no-cache  --virtual run-dependencies \
build-base \
postgresql-client \
postgresql-dev \
yarn \
git \
tzdata \
libpq \
&& rm -rf /var/cache/apk/*

WORKDIR /docker-rails

ENV BUNDLE_PATH /gems

COPY package.json yarn.lock /docker-rails/
RUN yarn install
COPY Gemfile Gemfile.lock /docker-rails/
RUN bundle install

COPY . /docker-rails/

ENTRYPOINT ["bin/rails"]
CMD ["s", "-b", "0.0.0.0"]

EXPOSE 3000

El puerto default sobre el que Rails corre es el 3000, pero si has designado otro puerto dentro de tu aplicación asegurarte de exponerlo de manera correcta.

Y con esto tenemos listo nuestro Dockerfile, aunque estamos lejos de tener nuestra aplicación lista. Si construyeramos nuestra imagen con docker build . y trataramos de correrla con docker start docker-rails nos encontraríamos con un error, ya que Rails no encuentra las bases de datos que necesita para iniciar de manera correcta; pero pronto nos encargaremos de ello.

Luego el docker-compose.yml

Para poder coordinar todos los servicios que necesitamos para el correcto funcionamiento de nuestra aplicación (en este caso 2 bases de datos: Posgres y Redis) usaremos docker-compose, esta útilidad de Docker nos ayudará a crear multimples contenedores de diferentes imagenes, conectarlos, darles variables de ambiente e incluso volumenes.

Empezaremos creando un archivo llamado docker-compose.yml.

touch docker-compose.yml

Y en su primera linea especificaremos que versión de la herramienta queremos usar, en este caso usaremos la más reciente a la redacción de este articulo.

version: '3.8'

Después indicaremos los servicios que queremos que corra docker-compose, esto lo haremos dentro de la etiqueta services. A cada servicio le daremos un nombre el cual será importante cuando estemos configurando nuestra imagen así que asegurate de nombrarlo de una manera que haga sentido para ti. Vamos como primer ejemplo servicio de Posgres, al cual llamaremos db.

version: '3.8'
services:
  db:
    image: postgres:latest
    container_name: docker-rails-db
    environment:
      - POSTGRES_DB=docker-rails-dev
      - POSTGRES_PASSWORD=password
    ports:
      - 5432:5432
    volumes:
      - 'dbdata:/var/lib/postgresql/data'

Los archivos YAML son sensibles a la identación, así que asegurate de tener todo en orden y andidado de forma correcta.

La etiqueta db es el nombre que le dimos al servicio y dentro de la cual especificaremos toda la configuración del mismo.

Lo primero con lo que nos encontramos es image que tal como su nombre lo indica es el nombre de la imagen que queremos usar para ese servicio, en este caso es la imagen oficial de Posgres en su última versión (puedes especificar una versión remplazando el latest por alguna otra versión válida).

Después nos encontramos con container_name, que también es autodescriptivo y el cual vendra útil a la hora de checar nuestros contendores con docker ps.

enviroment se refiere a las variables de ambiente, y si nos referimos a la documentación de la imagen de Docker de Posgres podemos ver que la única variable obligatoria es POSTGRES_PASSWORD pero nosotros también definiremos POSTGRES_DB para darle un nombre personalizado a la base de datos que crea la imagen por defecto.

⚠️ ¡Asegurate de elegir una contraseña segura para la base de datos!

ports son los puertos que necesitaremos pasar de dentro del contenedor a nuestra maquina, los indicados en el archivo son los que por defecto usa Posgres.

Finalmente los volumes son la infomación persistente que necesitaremos para no correr las migraciones cada vez que encendamos el contenedor, esto porque Docker borra todos los datos una vez que damos de baja la información, si quieres aprender más sobre este tema te recomiendo esta sección de la documentación.

Ahora, el siguiente servicio es el de Redis pero no ahondaremos mucho en el pues cuenta solo con un par de etiquetas las cuales ya hemos revisado, para más información puedes visitar la imagen oficial.

version: '3.8'
services:
  db:
    image: postgres:latest
    container_name: docker-rails-db
    environment:
      - POSTGRES_DB=docker-rails-dev
      - POSTGRES_PASSWORD=password
    ports:
      - 5432:5432
    volumes:
      - 'dbdata:/var/lib/postgresql/data'
  redis:
    image: redis:latest
    container_name: docker-rails-redis
    ports:
      - 6379:6379

Nuestro último servicio lo llamaremos web y será la imagen que hemos construido con nuestro Dockerfile.

version: '3.8'
services:
  db:
    image: postgres:latest
    container_name: docker-rails-db
    environment:
      - POSTGRES_DB=docker-rails-dev
      - POSTGRES_PASSWORD=password
    ports:
      - 5432:5432
    volumes:
      - 'dbdata:/var/lib/postgresql/data'
  redis:
    image: redis:latest
    container_name: docker-rails-redis
    ports:
      - 6379:6379
  web:
    build: .
    image: docker-rails
    container_name: docker-rails-web
    ports:
      - 3000:3000
    depends_on:
      - db
      - redis
    environment:
      - POSTGRES_HOST=db
      - POSTGRES_USER=postgres
      - POSTGRES_PASSWORD=password
      - REDIS_URL=redis://redis:6379

La primer etiqueta nueva con la que nos topamos es build, la cual indica el directorio donde se encuentra nuestro Dockerfile; dado a que nuestro Dockerfile está en la raíz solamente pondremos .; si tu Dockerfile no está en la raíz o tiene otro nombre es recomendable que leas esta sección de la documentación para asegurarte que Compose lo encuentre.

La etiqueta image en este caso servirá para nombrar la imagen que construirá Compose, ya que al estar presente build no irá al repositorio a buscar una imagen preconstruida.

Por último, la etiqueta depends_on informará a Compose que no se debe de tratar de iniciar el contenedor hasta que estén creados los servicios db y redis, así como los conectará de manera interna para que nosotros podamos accesar a ellos mediante un URL (como se puede observar en la variable de ambiente de Redis) o por sus respectivas credenciales (como es el caso de Postgres), si quieres aprender como Docker maneja eso puedes leer sobre Docker Network.

Ahora que ya terminamos con los servicios, lo unico que debemos es listar los volumenes que usaremos y a los cuales nombramos de la siguiente manera.

version: '3.8'
services:
  db:
    image: postgres:latest
    container_name: docker-rails-db
    environment:
      - POSTGRES_DB=docker-rails-dev
      - POSTGRES_PASSWORD=password
    ports:
      - 5432:5432
    volumes:
      - 'dbdata:/var/lib/postgresql/data'
  redis:
    image: redis:latest
    container_name: docker-rails-redis
    ports:
      - 6379:6379
  web:
    build: .
    image: docker-rails
    container_name: docker-rails-web
    ports:
      - 3000:3000
    depends_on:
      - db
      - redis
    environment:
      - POSTGRES_HOST=db
      - POSTGRES_USER=postgres
      - POSTGRES_PASSWORD=password
      - REDIS_URL=redis://redis:6379
    volumes:
      - .:/app
volumes:
  dbdata:

¡Y listo! Nuestro docker-compose.yml está listo, ahora solo falta un paso para empezar a crear nuestra aplicación contenida en Docker.

Ojos que no ven, .dockerignore que no siente

Muchas veces no queremos que ciertos archivos estén en nuestra imagen de Docker pues estos no son necesarios para su contrucción (o se generan en la misma) y solo terminan haciendo el proyecto más grande de lo que necesita ser, como puede ser el caso de los node_modules y la carpeta .git.

Para ahorrarnos este espacio crearemos un archivo llamado .dockerignore en la raíz de nuestro proyecto y añadiremos estas dos carpetas:

echo ".git \n node_modules" >> .dockerignore

Para más información sobre lo que puede contenener un archivo .dockerignore puedes consultar la documentación oficial de Docker

Unas bases de datos para llevar

Antes de correr el proyecto será necesario crear la base de datos que Rails espera, y crearla es tan sencillo que se puede hacer en un solo comando.

docker-compose run web db:create

Este comando le dice a Docker que use la imagen (que construirá) para correr un comando, en este caso db:create. Docker, con lo especificado en el docker-compose.yml sabe que como web depende de db tendrá que correr primero la instancia de Postgres, por lo que la base de datos se creará en este contenedor.

¿Por qué solamente db:create y no rails db:create o rake db:create? En nuestro Dockerfile dimos como punto de entrada el comando rails, por ello solo es necesario pasar los parametros. Si quisieramos efectuar otro comando dentro del contenedor esto tendría que ser a través de docker exec.

Nuestra aplicación en un contenedor

Con la base de datos creada, solo queda un comando que corra los contenedores en modo separado y podremos ver el fruto de nuestro trabajo.

docker-compose up -d

¡Y listo! Ya podrás accesar a traves de tu navegador a localhost:3000 y ver la página de bienvenida de Rails.

Conclusión

Puede que todo este proceso sea algo intimidante al principio, en especial si no sabes Docker, pero su resultado es un ambiente de desarrollo mucho más sencillo para todos los involucrados en el proyecto, pues ahora solo con tener Docker instalado podrán iniciar a programar; sin mencionar los beneficios que esta tecnología puede traer a tu ambiente de producción cuando se combina con Kubernetes o Docker Swarm.

Espero que te haya sido útil, cualquier cosa puedes contactarme y responderé lo más pronto posible.