Gatsby Starter Blog RSS Feed

The pursuit of knowledge

Wed, 12 Nov 2025 19:00:00 GMT

I have reached a point in my life where I can clearly understand that famous saying attributed to Socrates: "I know that I know nothing".

The more I learn and study about technology, which is both my work and my passion, and the more I discover about the world we live in, the more I realize how much there still is to learn.

What I have come to understand over the years is that knowledge is something I will always seek, until my very last moment, because no one can take it away from me. To seek knowledge is to try to understand the world around us, to comprehend society as a whole, and to explore the essence of what it means to be human.

There is nothing more valuable that I have learned than to appreciate the pursuit of knowledge and to recognize that intelligence is relative. For example, think about the philosopher Diogenes the Cynic. In his time, many people in high society did not see him as a real scholar or thinker, yet even Alexander the Great went to meet him. Not everyone recognized him as a wise man, and that divide over what counts as intelligence and what does not is still very present in today’s society.

In our modern world, I like to think that intelligence is not limited to the academic pursuing a doctorate. A humble worker living a simple life can be just as wise, because knowledge is free. It exists in books, in daily experiences, and in the world around us. Human beings are complex and capable of learning and growing through countless sources. All it takes is to keep alive the desire to seek knowledge.

That is my reflection for today. No tech stuff, just toughts :)!

whereisalex · i wish you loved me.

Speed up your Python workflow with uv and ruff

Fri, 06 Jun 2025 04:05:24 GMT

Recently, I've been exploring ways to make my Python development workflow faster and cleaner and I discovered an incredible duo: uv and ruff. Both are written in Rust and have completely transformed how I work with Python projects. In this blog post, I'll share why I made the switch and how you can easily integrate these tools into your workflow!

Why I started using `uv` and `ruff`

Let's be honest — Python tools can be kind of a mess. Between pip, virtualenv, pip-tools, flake8, isort... there's just too much to deal with, and it was honestly getting annoying. Installing packages was slow, and the whole setup started to feel more like a hassle than something helpful.

Then I discovered this Rust-powered combo, and everything changed. Here's what got me hooked:

uv is a super-fast Python package manager that replaces pip, virtualenv and pip-tools - all in one tool. It's modern, reliable, and blazingly fast.

ruff is a lightning-fast linter and formatter that can replace black, flake8, isort and more. One tool to rule them all, basically.

The performance difference is mind-blowing. We're talking about significant speed improvements in package installations and code formatting. Once you experience this speed, there's no going back.

Performance benchmarks

So how fast are we talking, really? Let’s break it down with real benchmarks. From package installs to linting massive codebases, the results are jaw-dropping — and they’re what convinced me to switch for good.

uv delivers remarkable speed gains: According to Astral's official benchmarks, uv is 8-10x faster than pip and pip-tools without caching, but here's where it gets really interesting - with a warm cache (like when you're recreating a virtual environment or updating dependencies), it becomes 80-115x faster. That's not a typo! The speed difference comes from uv's global module cache that avoids re-downloading packages and its use of Copy-on-Write and hardlinks to minimize disk usage.

Even for virtual environment creation, uv is about 80x faster than python -m venv and 7x faster than virtualenv, with no dependency on Python itself.

ruff is equally impressive: The official documentation states that Ruff is 10-100x faster than existing linters like Flake8 and formatters like Black. But what really drives this home are the real-world testimonials from developers who've made the switch.

Bryan Van de Ven — co-creator of Bokeh and original author of Conda — shared a great comparison:

“Ruff is ~150–200x faster than flake8 on my machine. Scanning the whole repo takes ~0.2s instead of ~20s.”

Nick Schrock, founder of Elementl and co-creator of GraphQL, also reported impressive results:

“On our largest module (Dagster itself, 250k LOC), pylint takes about 2.5 minutes, parallelized across 4 cores on my M1. Running Ruff against our entire codebase takes 0.4 seconds.”

References:

How easy these tools are to use

Here's the best part - these tools are designed to be drop-in replacements. You don't need to rewrite your entire workflow or learn completely new concepts. Just swap out the tools and enjoy the speed boost!

Both uv and ruff work with your existing Python projects and configurations. They respect your current setup while making everything faster and more reliable.

Quick tutorial and example

Let me show you how simple it is to get started with both tools.

Installing `uv` and `ruff`

# Install uv
curl -LsSf https://astral.sh/uv/install.sh | sh # On Windows: powershell -ExecutionPolicy ByPass -c "irm https://astral.sh/uv/install.ps1 | iex"

# Install ruff
pip install ruff

Creating a new project with `uv`

Starting a new project is incredibly straightforward:

# Create and activate virtual environment
uv venv
source .venv/bin/activate  # On Windows: .venv\Scripts\activate

# Initialize project (creates pyproject.toml)
uv init

# Install packages (lightning fast!)
uv pip add requests pandas fastapi

That's it! You now have a .venv managed by uv, packages install incredibly fast, and you get a uv.lock file for perfect reproducibility.

Setting up `ruff`

The beauty of ruff is that it works great out of the box with zero configuration. You can start using it immediately:

# Check for issues in your codebase
ruff check .

# Auto-fix what can be fixed automatically
ruff check . --fix

# Format your code
ruff format .

If you'd like to customize ruff's behavior, you can configure it via a pyproject.toml, ruff.toml or .ruff.toml file. It looks for the closest configuration file in the directory hierarchy and applies its settings.

Here’s a simple configuration example using pyproject.toml:

[tool.ruff]
# Set the maximum line length
line-length = 88

# Assume Python 3.12
target-version = "py312"

You can explore all available settings in the ruff settings documentation. For a deeper look at how to configure ruff, check out the configuration guide.

This setup gives you a powerful and streamlined workflow by combining the functionality of tools like black, isort, flake8, and several plugins — all in a single, blazing-fast tool.

My production setup with pre-commits and github workflows

In my workflow, I use ruff with pre-commit hooks to automatically check for linting and formatting errors before each commit. I also have GitHub workflows set up to ensure code quality in my repositories. Additionally, I use uv to improve build times across my CI/CD pipelines. I might dive deeper into pre-commit setup and uv use cases in a future post, but here's the GitHub workflow I use:

name: Ruff

on: [pull_request]

jobs:
  ruff-lint:
    name: Ruff Linter
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Run Ruff linter
        uses: astral-sh/ruff-action@v3
        with:
          args: check .

  ruff-format:
    name: Ruff Formatter
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Run Ruff formatter check
        uses: astral-sh/ruff-action@v3
        with:
          args: format --check --diff

This workflow runs on every pull request and checks both linting and formatting. It's simple, fast and catches issues before they make it into the main branch.

Conclusion

This combo has made my Python workflow smoother and way faster. The best part is that you don't need to change everything at once. You can start by replacing your current linter/formatter with ruff, then try uv for new projects to see the speed difference.

Let me know if you try this out or have other tools that are game-changers for your setup!

print("See ya 😎")

Njs10 · No More Heroes 2~It's Kill Or Be Killed(Destroy Resort)

Anonymous block parameter in Ruby

Sat, 31 Aug 2024 04:30:53 GMT

Recently, I learned about numbered parameters in Ruby, which simplify block parameters by eliminating the need to explicitly name each one. I then explored this further and discovered an even more flexible approach: using it keyword as an anonymous block parameter. In this blog post, we'll briefly discuss about these Ruby features!

A brief history

Before Ruby 2.7, working with blocks in Ruby required explicitly naming each parameter, which could make the code more verbose and harder to read. For example:

[1, 2, 3].map { |element| element * 2 }
# => [2, 4, 6]

To simplify this, Ruby 2.7 introduced numbered parameters (you can see the proposal here):

[10, 100, 1000].each_with_index { p "#{_1}, #{_2}" }
# => "10, 0"
# => "100, 1"
# => "1000, 2"

Here, _1 refers to the first element, while _2 refers to the index. This approach makes the code cleaner and more focused on the block’s logic. However, it can still be somewhat confusing and may not always be as readable as desired.

The proposal: introducing `it`

Recognizing the limitations of numbered parameters, a proposal for Ruby 3.4 (you can see it here) suggested introducing it as an anonymous block parameter. The aim was to simplify block syntax even further by replacing numbered placeholders with the more intuitive it keyword:

[10, 20, 30].select { it > 15 }
# => [20, 30]

In this example, it represents the current element being processed, serving as an anonymous parameter. This enhancement aims to simplify code, making it more readable and expressive by eliminating the need to remember parameter numbers.

Conclusion

In summary, both numbered parameters and the anonymous parameter enhance how we handle block parameters in Ruby. Numbered parameters offer a concise way to reference multiple parameters, but they can sometimes be confusing, especially with several parameters. On the other hand, the it keyword acts as an anonymous parameter, simplifying code when you only need to work with a single parameter.

The key takeaway is to use these approaches to simplify your code blocks, but only if they don't reduce readability. Shorter code isn't always easier to read; it's important to balance between being concise and being clear. Always consider how these features affect the overall readability of your code to make the best decision.

I hope you found this blog post useful. Thanks for reading!

puts "Ah shit, here we go again."

2Pac.radio 2 · 2Pac - Shorty Wanna Be A Thug (Original Version)

Memoization in Ruby on Rails

Tue, 06 Aug 2024 02:56:20 GMT

Hi, welcome! This is the second post on my blog (finally :P), and here I'll talk a little bit about memoization in RoR.

The first time I encountered memoization in Rails was at work a few months ago when I saw a method using something like @here ||= some_query. I was intrigued, started researching, and now I'm sharing what I've learned in this post!

What is memoization?

In simple terms, memoization is a way to store the result of a method call and return the cached result when the same inputs occur again.

It works by caching a method's results the first time it's called. After that, any subsequent calls will return the cached value instead of recalculating it.

Example of memoization in Rails

Memoization is commonly used in Rails applications to optimize methods that perform costly operations, like database queries or external API calls. Let's look at an example of a method before and after applying memoization:

Before memoization

class User < ApplicationRecord
  def expensive_method
    # Perform some costly operations here
    sleep(2) # Simulate a time-consuming task
    "Expensive result"
  end
end

user = User.find_by(id: 13)
puts user.expensive_method # This will take 2 seconds
puts user.expensive_method # This will take another 2 seconds

After memoization

class User < ApplicationRecord
  def expensive_method
    @expensive_method ||= begin
      # Perform some costly operations here
      sleep(2) # Simulate a time-consuming task
      "Expensive result"
    end
  end
end

user = User.find_by(id: 13)
puts user.expensive_method # This will take 2 seconds
puts user.expensive_method # This will be instant

The memoized version of the expensive_method uses the ||= operator to determine if the result has already been computed. The expensive operations are executed only during the first call, while subsequent calls return the cached result, which enhances performance.

Of course, this is a simplified example, but it shows how memoization can enhance your methods.

Benefits of memoization

There are several benefits to using memoization in Rails applications, but the ones I particularly noticed at work were:

Increased performance: It makes things faster by reducing redundant operations.
Simplified code: Makes your code cleaner by eliminating redundant calculations.

Use cases for memoization in Rails

Besides the benefits I experienced with memoization in the projects I’ve been working on, I also observed and want to highlight two scenarios where you definitely should consider applying memoization:

Database queries: Avoid running the same query multiple times within the same request.
Complex calculations: Store the results of complex calculations to improve performance.

However, it's important to remember that not all methods are good candidates for memoization. Generally, I recommend memoizing methods that:

The calculation is costly or takes a long time.
The input data doesn't change.
The method is used often.

In conclusion, memoization is beneficial when the method is called multiple times within the same context, reducing the overhead of redundant database queries and improving overall performance.

For now, that's all. I really hope you've learned something useful from this post!

puts "See ya :P"

bangs. · MF DOOM - Doomsday

Hello World

Thu, 09 May 2024 08:28:01 GMT

Hi, as you've probably noticed, my name is Mateus Elias!

Firstly, let me introduce myself. I'm 22 years old and currently work as a Full Stack Software Engineer while pursuing my bachelor's in Computer Science.

I've created this blog to share some interesting tech stuff (hopefully :P) and also to share personal experiences.

But how did I come up with this idea of creating a blog in plenty 2024? Well, I was using Obsidian a lot (a very good note-taking software), and I thought some of my notes were worth sharing and could help others, or at least teach something new! Also, some of my notes I simply wanted to share, to show a bit of myself to those who want to know me. And because of that, this blog was created!

I already have a page on Medium. I thought of starting to use it to share the posts I wanted, but it didn't fulfill what I was looking for. I didn't want to share only elaborated tech posts, but also simple posts sharing some of my weekly experiences, for example. I felt that Medium was way "too formal" for that, so I've created my own blog, a space where I'm free to do what I want with it and make it really how I want! I know the reasons to create this blog and also to not use Medium were not that deep and complex, but I think they are fair enough motivations.

Hope you can get something good from here. I'll put effort into this blog and try to make new posts whenever possible! Writing is a very good way to externalize what you've learned, what you're feeling, basically everything. Try it out yourself too, maybe you'll like it as much as I do.

For now, that's all. I just wanted to start things right with this simple introductory post, basically to say:

puts "Hello World"

Gatsby Starter Blog RSS Feed

The pursuit of knowledge

Speed up your Python workflow with uv and ruff

Why I started using uv and ruff

Performance benchmarks

How easy these tools are to use

Quick tutorial and example

Installing uv and ruff

Creating a new project with uv

Setting up ruff

My production setup with pre-commits and github workflows

Conclusion

Anonymous block parameter in Ruby

A brief history

The proposal: introducing it

Conclusion

Memoization in Ruby on Rails

What is memoization?

Example of memoization in Rails

Before memoization

After memoization

Benefits of memoization

Use cases for memoization in Rails

Hello World

Why I started using `uv` and `ruff`

Installing `uv` and `ruff`

Creating a new project with `uv`

Setting up `ruff`

The proposal: introducing `it`