DEV Community: Lucas Fernandes

How do I practice vocabulary

Lucas Fernandes — Wed, 30 Jul 2025 17:37:14 +0000

TLDR

1. Read and note unknown words (max. 5 per day)

2. Create flashcards:

Front: word + original sentence
Back: word meaning + sentences examples

3. Before each day of reading:

Set a study time frame
For each word, try to remember the meanings and the sentences examples mentally
Then consult the meaning thoroughly
Then write and speak out loud what you just consulted to reinforce memory

Use Anki to create flashcards and automate reviews.

Introduction

To improve my vocabulary, I read. Ta-dah!

No seriously, I generally take the opportunity when I'm reading a book in English to do this, but it works with any type of media, for example, a foreign article or news.

The advantage of books is that you'll possibly notice that the word you want to learn repeats later in the reading. This will help you remember and reinforce your understanding of the word.

Personally, I like it because when you encounter the word later in the book you'll feel that reading will flow better, and thus, a sense of progress.

Keep in mind that it's a process that takes time and that at the beginning, reading will be less fluid. It takes time because you have to stop, research the word, read the meaning, read a couple of examples of its application in sentences, take notes and dedicate time to remember their meanings regularly.

On the other hand, this way you'll retain more information, strengthen your brain connections and have a higher quality of reading.

Anki, your flashcard brain wizard

I'll quote how the Anki site describes it.

Anki is a flashcard program that helps you spend more time on challenging material, and less on what you already know.

And that's sufficient for describing most of what Anki does. However, what the site doesn't mention is its powerful ability to do spaced repetition for you.

So what's spaced repetition?

The idea of spaced repetition is nothing more than you reinforcing the memories of these words before they are forgotten.

Instead of reviewing all words at once, this method tells us to space this review over time.

The great thing about using Anki is that you don't need to worry about manually controlling the spacing of reviews over time. The program does it for you!

The core concept

Take your reading material and start reading.

When you encounter a word you don't know, stop, note it down in Anki, and research its meaning. I like to use Cambridge Dictionary to research meanings.

My annotation style for each word follows the flashcard idea, where on the front of the card I put the word and the sentence where it appeared. On the back of the card I write the meaning and more examples of the word's application in sentences.

Using the word "ad-hoc" as an example. In the front I write:

ad-hoc

"We held an ad hoc meeting to address the server crash"

and on the back I write:

Describes something create or done spontaneously, impromptu, or as needed. It's a fancy way to say "on the fly".

Examples:

"We held an ad hoc meeting to address the server crash"

"The team formed an ad hoc committee to handle the merger"

In tech context, it means that something unexpected/unplanned came up that disrupt the regular workflow.

Examples:

"My spring backlog grew due to the ad hoc bug fixes"

"The ad hoc standup lasted 20 minutes to align on the hotfix"

"Yesterday I spent my time in ad hoc debugging, instead of my planned assigned ticket"

The important thing here is that on the front, you just put the minimum to try remember the meaning. The back of the card should be consulted only after trying to remember the word's meaning.

Continue reading and repeat the process when you encounter another unknown word, but do this for a maximum of 5 words per day.

Doing this you'll create an arsenal of words to practice in a regular time space.

The importance of writing

There's something very powerful about writing that makes my brain really strive to remember something. Writing it's also helpful in spell the word, the spelling. Writing combined with the practice of speaking out loud will make it easier to retain meanings.

For each day, I like to set aside some time to review the words before resuming reading. My way of studying has been the following for each word that Anki tells me I need to review on that day:

I set aside some time, like 1 minute
I try to remember its meaning and its application in sentences mentally
I then consult the meaning and its application in sentences thoroughly
Now, again without looking at the consultation, I write and speak out loud the meaning and application in sentences. Remembering what I just read from the consultation itself

And that's it! I now get a small frisson of excitement when I suddenly recall what some random word means, proving that this steps helps me retain information for longer.

Thank you for reading!

Want to help me? If these steps ever helped you out or wanna keep me excited on sharing learning techniques like this? Consider buying me a coffee or supporting me on Ko-fi.

MVC: The Linchpin Architecture of Ruby on Rails

Lucas Fernandes — Thu, 11 Apr 2024 16:58:09 +0000

When it comes to web development, knowing your architectural patterns is key to building solid and easy-to-maintain apps. And one of the stars in the Ruby on Rails world is MVC—which stands for Model-View-Controller. So, let's cover some key points on what MVC is and how it plays a big role in Rails development.

Explaining MVC in Ruby on Rails

In Rails, you get the MVC model right out of the box, embodying the convention over configuration principle that Rails is known for. It's like having a roadmap that tells you where to go without sweating the small stuff. This setup helps devs concentrate on the fun stuff—like cooking up new features—instead of struggling with naming and organizing files within the project.

Basic Web Request Flow in Rails MVC

For knowledge purposes, understanding how a simple web request moves through the MVC can make things clearer. Here's a simple breakdown of how it works:

A user sends a request to the web server
The web server gets the request and passes it to the controller
The request is then directed to its specific route, like /grocery. The route connects with the controller method that handles this request
The controller talks to the model to get the needed data from the database. It then processes this data based on the app's logic
Once the data is validated, it's prepared to be shown in the view
The data is sent to the view for display, usually in an HTML file like index.html or index.html.erb
The view processes the data and creates a response to send back to the webserver
This response, along with any JSON data, is then sent back to the user's browser

The Model

The Model in MVC is like the brain of the operation. It's where your business logic resides and where all the smarts and data magic happen in your app. In a nutshell, here's what you need to know about the Model:

It encapsulates data-related business logic
Each Model corresponds to a table in the database
While the Model class name is by convention in singular, its equivalent table name in the database is plural
It inherits from ActiveRecord::Base which brings some facilities, such as:
- Establish and maintain a connection with the database
- Enable data retrieval from the database
- Facilitate data writing to the database
ActiveRecord::Base provides abstractions of database adapters to connect with a wide range of popular databases
It also makes it easy to define relationships or associations between models

The View

The View part handles how users interact with the app and how things look on the screen. Here's what you need to know about it:

It deals with how things look and how you interact with the browser
It's not for handling business stuff or talking to databases
It's purpose is only for object representation
It mixes HTML and Ruby code using special tags like <%= %> and <% %>
The instantiation of this class is done under the hood by the ActionView module
The Rails developer only needs to modify the templates that resides on app/views
The folder that stores the template file is named after the controller action name. For eg., index.html.erb, or show.html.erb
The template has a one-to-one mapping to the controller action
The extension of the template can be:
- html.erb
- xml.builder
- json.builder
It comes with special templates such as layouts and partials
- Layouts: are templates that control the global layout of the application and are things that might not change, such as the nav bar
- Partials: are special subtemplates that can be reused multiple times within the application
Communication between controllers and views is made via instance variables
All of this is done as part of the ActionPack lib

The Controller

The Controller acts as the intermediary between the Model and the View, handling requests and coordinating data flow. Key aspects of the Controller
include:

It's the interface that glues the logic that resides in the Model classes and display them into pages that the final user can view. This is done with:
- Figuring out what to do when a user makes a request
- Getting data from the Model and sending it to the View to show to the user
- Gathering info from a browser request and use to create or update a model
It's inherits from application_controller.rb that inherits from ActionController::Base
Controller class names use CamelCase
File names are lowercase with underscores, ending in _controller.rb
Each controller handles a specific part of the app
Controllers have instance methods that match up with create, read, update, and delete (CRUD) actions

Pros and Cons of MVC in Rails

Pros

Scalability: MVC promotes a structured approach that scales well with growing applications
Maintainability: Separation of concerns makes code easier to maintain and update
Reusability: Components like views and partials can be reused across the application

Cons

Complexity: There are some magic things that happen behind the scenes that, at first sight, might be confusing, especially for new developers
Partial Knowledge: While MVC is essential, it's part of a larger application architecture, and understanding other design patterns is beneficial

Conclusion

MVC in Ruby on Rails is a common approach used in many projects, and understanding it is crucial if you want to work on Rails projects. This architecture follows certain conventions that help developers focus on important tasks and take advantage of built-in methods and tools provided by the framework. While Rails apps aren't solely based on MVC, from my experience point of view, knowing other design patterns also helps in building software effectively with MVC.

As you can see, this post doesn't cover all the details of this design pattern. The goal here is to provide some guidance and key points to focus on. Hopefully, this gives you a starting point to learn more about the subject, just like it did for me.

For further reading and references, check out the following links:

Thank you for reading!

The Twelve-Factor App: Admin processes

Lucas Fernandes — Thu, 11 Jan 2024 16:32:27 +0000

Run admin/management tasks as one-off processes

Besides the app's regular business processes, developers frequently need to perform one-off administrative or maintenance tasks for the app, such as:

Running database migrations;
Running a console to run arbitrary code or inspect the app's model against the live database;
Running one-time scripts committed into the app's repo(e.g. php scripts/fix_bad_records.php)

Those tasks should operate within the same environment as the regular long-running processes of the app. They execute against a release, utilizing the identical codebase and configuration. Moreover, to prevent synchronization issues, the code must be shipped alongside the application code.

All process types should employ the same dependency isolation techniques. For instance, if the Ruby web process utilizes the command bundle exec thin start, the database migration should also use bundle exec rails db:migrate.

The Twelve-Factor app strongly advocates for languages that offer a built-in REPL shell, simplifying the execution of one-off administrative scripts. During development, developers can run these scripts by accessing a local console within the app's container. In a production deployment, developers can access the app's console via SSH or another mechanism provided by the execution environment, and then execute the script.

This Twelve-Factor App post series is a means for me to
consolidate the knowledge I've gained while studying these
rules. Please feel free to visit [the site (https://12factor.net/) for more detailed explanations. That's all folks!

The Twelve-Factor App: Logs

Lucas Fernandes — Wed, 10 Jan 2024 22:53:20 +0000

Treat logs as event streams

Logs offer insights into the behavior of a running app, typically stored in log files on the disk containing the app's outputs.

They represent an aggregated, time-ordered stream of events occurring across running processes and backing services, registering each event on a single line. Logs flow continuously without a fixed start or end as long as the app operates.

A twelve-factor app doesn't concern itself with routing or storing its output stream. Rather than managing log files, the focus is on directing processes and backing services to output logs to stdout.

During local development, developers can observe logs in their terminal's foreground to monitor the app's behavior. In other environments like test, staging, or production, this is captured by the execution environment. All streams from the app, its processes, and backing services are directed to one or more final destinations for viewing and long-term storage, entirely managed by the execution environment.

The app's event stream can be directed to a file or monitored in real-time using terminal-based tail commands. Importantly, it can also be sent to a log indexing and analysis system or a general-purpose data warehousing system like Hadoop or Hive. These systems offer significant power and flexibility for examining an app's behavior over time, including:

Find specific time events in the past;
Large-scale graphing of trends(such as the requests per minute);
Active alerting according to user-defined heuristics(such as an alert when the quantity of errors per minute exceeds a certain threshold)

The Twelve-Factor App: Dev/prod parity

Lucas Fernandes — Thu, 04 Jan 2024 15:18:00 +0000

Keep development, staging, and production as similar as possible

Historically, significant disparities have existed between development and production environments, manifesting in several ways:

The Time Gap: Code often takes days, weeks, or even months to reach production, whereas it should ideally be deployed within hours or minutes.
The Personnel Gap: Developers create code while DevOps engineers handle deployment. Ideally, developers would be closely engaged in deploying and observing its behavior in the production environment.
The Tools Gap: Local development setups might utilize stacks like Nginx, SQLite, and OS X, while production environments employ Apache, MySQL, and Linux. Let's keep development and production as similar as possible.

The Twelve-Factor app is engineered for continuous deployment, aiming to narrow the gap between these environments.

Developers adhering to the twelve-factor principles resist the temptation to use different backing services in development versus production. This stems from the appeal developers find in using lightweight services locally versus more robust ones in production. Discrepancies between these services often lead to minor incompatibilities, causing code that passed testing in dev or staging to fail in production. This discourages continuous deployment and results in considerable friction that incurs significant costs throughout an application's lifecycle. Additionally, modern packaging systems like Homebrew and apt-get have made installing and running modern backing services less challenging.

Many programming languages offer libraries that streamline access to backing services, providing adapters for various service types. For instance, ActiveRecord for Ruby/Rails includes database adapters such as MySQL, PostgreSQL, and SQLite. While adapters to different backing services simplify porting to new services, it's essential for all deployments (developer environments, staging, production) to use the same type and version of each backing service.

The Twelve-Factor App: Disposability

Lucas Fernandes — Wed, 03 Jan 2024 15:25:08 +0000

Maximize robustness with fast startup and graceful shutdown

The Twelve-Factor app's processes are designed to be disposable, allowing them to be started or stopped at any moment. This flexibility accelerates elastic scaling, rapid deployment of code or configuration changes, and ensures the resilience of production deployments.

Efforts should be made to minimize the startup time of processes. Swift startups provide greater agility for the release process and scaling up, contributing to robustness as the process manager can easily transfer processes to new physical machines when needed.

Processes shut down gracefully when they receive a SIGTERM signal from the process manager. In the case of a web process, this entails ceasing to listen on the service port (rejecting new requests), allowing ongoing requests to be completed, and then exiting. For instance, in the case of a worker process, graceful shutdown involves returning the current job to the work queue. In RabbitMQ, a worker can send a NACK to accomplish this.

Processes should also be resilient against abrupt termination, which could result from hardware failures. Although less common than graceful shutdowns with SIGTERM, such incidents can occur. An advisable strategy involves utilizing a robust queueing backend like Beanstalkd, which returns jobs to the queue upon client disconnection or timeouts. In any scenario, a twelve-factor app is structured to handle unexpected, non graceful terminations. The crash-only design embodies this principle to its logical conclusion.

This Twelve-Factor App post series is a means for me to consolidate the knowledge I've gained while studying these rules. Please feel free to visit [the site (https://12factor.net/) for more detailed explanations. That's all folks!

The Twelve-Factor App: Concurrency

Lucas Fernandes — Tue, 02 Jan 2024 18:36:48 +0000

Scale out via the process model

Web applications have various process execution forms. PHP, for example, processes function as child processes of Apache, starting based on request volume, while Java processes operate within a massive JVM uberprocess, managing concurrency internally through threads. These running processes are minimally visible to app developers. In the context of the twelve-factor app, processes are crucial and they are a first-class citizen, drawing inspiration from the unix process model for service daemons. This model allows developers to allocate different workloads to specific process types, such as handling HTTP requests through web processes and long running tasks through worker processes.

Moreover, while individual processes can handle internal multiplexing via threads or asynchronous/event-driven models, vertical scaling of an individual VM has limitations. The process model excels in scaling out, as the share-nothing, horizontally partitionable nature of twelve-factor app processes facilitates simple and reliable addition of concurrency.

Furthermore, the text emphasizes that twelve-factor app processes should refrain from daemonizing or writing PID files. Instead, reliance on the operating system’s process manager (like systemd or cloud platform-based distributed process managers) or tools such as Foreman during development is encouraged. These tools effectively manage output streams, handle crashed processes and address user-initiated restarts and shutdowns.

This Twelve-Factor App post series is a means for me to consolidate the knowledge I've gained while studying these rules. Please feel free to visit [the site (https://12factor.net/) for more detailed explanations. That's all folks!

The Twelve-Factor App: Port binding

Lucas Fernandes — Fri, 29 Dec 2023 17:26:49 +0000

Export services via port binding

At times, the server functions as a web server container where the web app operates as a module within the container. For instance, a PHP app might run as a module inside Apache HTTPD, or Java apps might function within Tomcat.

The twelve-factor app is entirely self-contained and doesn't depend on the runtime injection of a web server into the execution environment to establish a web-facing server. Instead, the web app exports HTTP as a service by binding to a port, which serves as a listening port for incoming requests. In a local environment, developers access the app by visiting http://localhost:3000. In a deployment environment, a routing layer manages the routing of requests from a public-facing hostname to the port-bound web processes.

This is commonly achieved by using dependency declarations to incorporate the web server library into the app, such as using Thin for Ruby.

Furthermore, this approach signifies that any service can be exported by port binding, awaiting incoming requests. It's important to note that by doing so, one app can serve as the backing service for another app.

This Twelve-Factor App post series is a means for me to consolidate the knowledge I've gained while studying these rules. Please feel free to visit [the site (https://12factor.net/) for more detailed explanations. That's all folks!

The Twelve-Factor App: Processes

Lucas Fernandes — Thu, 28 Dec 2023 17:07:25 +0000

Execute the app as one or more stateless processes

The app operates within the execution environment as one or more processes.

Consider the code as a stand-alone script, the execution environment as the developer's local machine with the installed language runtime, and the process launched via the command line, for example, $ ruby my_file.rb.

The Twelve-factor app dictates that processes should be stateless and share nothing. Any additional data requiring persistence must be stored in a backing service, typically a database.

However, the memory space or filesystem of the process can be utilized as a brief, single-transaction cache. For instance, downloading a large file, performing operations on it, and then storing the results of the operation in the database. Nonetheless, the Twelve-Factor app never assumes that anything cached in memory or on disk will be available for future requests or jobs, as future requests might be served by different processes.

Moreover, any language-specific packaging that utilizes the filesystem as a cache for compiled assets violates the Twelve-Factor App. It is preferred to handle this during compilation in the build stage. Tip: The Rails asset pipeline can be configured to package assets during the build stage.

Certain web systems rely on "sticky sessions" where user session data is cached in the memory of the app’s process, expecting subsequent requests from the same visitor to be routed to the same process. This practice also violates the Twelve-Factor app. Session state data is better suited for a datastore offering time expiration, such as Memcached or Redis.

This Twelve-Factor App post series is a means for me to consolidate the knowledge I've gained while studying these rules. Please feel free to visit [the site (https://12factor.net/) for more detailed explanations. That's all folks!

The Twelve-Factor App: Build, release, run

Lucas Fernandes — Wed, 27 Dec 2023 20:20:57 +0000

Strictly separate build and run stages

A codebase goes through several stages before transforming into an execution environment:

The build stage involves a process that converts the code repository into an executable bundle, known as the build. This stage, utilizing a root commit specified by the deployment process, retrieves vendor dependencies and compiles binaries and assets.
The release stage takes the output produced by the build stage and combines it with the deployment's configurations. The result of this combination creates a package ready for immediate execution within the execution environment.
The run stage (also referred to as "runtime") executes the app within the execution environment by launching a set of the app’s processes against a chosen release.

The Twelve-Factor app strictly emphasizes the separation between the build, release, and run stages. For instance, making changes to the code at runtime is impossible, as there's no mechanism to propagate those changes back to the build stage.

Every release should have its unique identification associated, such as a timestamp, and each release is an increment of the previous version. This implies that any modification must generate a new release.

The build process is initiated by developers when the code is pushed to an environment. In contrast, runtime execution can occur automatically, such as during a server reboot. Consequently, it's crucial to keep the run stage with as few moving parts as possible, as issues at this stage might prevent the app from running, especially during off-hours when support might not be readily available. The build stage can be more complex, as developers actively manage the deployment, keeping errors in the foreground.

This Twelve-Factor App post series is a means for me to consolidate the knowledge I've gained while studying these rules. Please feel free to visit [the site (https://12factor.net/) for more detailed explanations. That's all folks!

The Twelve-Factor App: Backing services

Lucas Fernandes — Tue, 26 Dec 2023 14:02:30 +0000

Treat backing services as attached resources

Backing services are classified as any resources required by the app to fulfill its functionalities. Typically accessed via a network or other locations stored within the configuration. These services include databases, SMTP clients, third-party integrations such as Amazon S3, Twitter, or Last.fm APIs, and caching systems. These backing services are usually managed by the individual responsible for deploying the app and its resources.

The Twelve-factor app doesn't differentiate between local and third-party services. For the app, both types of resources are accessed via URLs. Thus, swapping out a local resource, like a database, for one managed by a third party requires no code changes.

Resources can be attached to or detached from deployments at will. For instance, if a database malfunctions, the app's administrator might spin up a new database backup, detach the current database, and then restore the new database instance by requiring no code alterations.

This Twelve-Factor App post series is a means for me to consolidate the knowledge I've gained while studying these rules. Please feel free to visit [the site (https://12factor.net/) for more detailed explanations. That's all folks!

The Twelve-Factor App: Config

Lucas Fernandes — Sat, 23 Dec 2023 15:41:29 +0000

Keep your configs for each environment

The app's configuration is everything that may vary between environments. This includes:

System resources like databases, Memcached, and backing services;
Credentials for external services such as Amazon S3 or Twitter;
Environment-specific values such as the hostname.

The Twelve-Factor methodology strongly advocates for
separating configuration from the code. This is primarily
because configuration values may differ between environments
while the code remains constant. A useful way to determine if
configurations are properly extracted from the code is by
considering the scenario of making the codebase open source.
If the credentials need to be managed, the configurations
might be compromised.

Another approach involves using configuration files not
included in the version control system, such as
'config/database.yml' in Rails. While this is a significant
improvement, it is not recommended because there's a risk of
accidentally pushing these files. Additionally, configuration
files often scatter across different locations, making
maintenance challenging. Moreover, these config files tend to
be specific to a particular language or framework.

Another practice to avoid is grouping configurations into
environment-specific sets. Apps tend to categorize
configurations into named groups for different environments.
However, this method doesn't scale well. As the project
expands, developers might introduce their own custom
environments, leading to an explosion of configurations that
complicate deployment management.

The Twelve-Factor methodology suggests storing
configurations in environment variables. Environment
variables are easy to modify between deployments without
requiring changes to the code. They compel setting up
independent configurations for each deployment environment,
minimizing the chance of accidental check in the codebase
repository. They don't aggregate into 'environments' groups,
they are language- and OS-agnostic standards and provide a
scalable model as the app naturally expands to more
deployments.

This Twelve-Factor App post series is a means for me to consolidate the knowledge I've gained while studying these rules. Please feel free to visit [the site (https://12factor.net/) for more detailed explanations. That's all folks!