DEV Community: Federico Ramirez

Vim Advanced Search and Replace

Federico Ramirez — Sun, 01 Oct 2023 19:30:08 +0000

I find search and replace to be a remarkably interesting topic, because it touches on so many Vim concepts.

When I started using Vim, one of the first things I wanted to do was search for some text in my project and replace it with something else.

Unfortunately for me, it was not as simple as I had initially thought :)

In this post I will show how several different ways to search and replace text in Vim. From the obvious, beginner-friendly way, to the more advanced, vimmish way.

Before we begin: Reading key sequences

I will use Vim's format to describe sequences of keys. That means <C-r> means press the CONTROL key, and while holding it, press the r key. <CR> means ENTER key, <Esc> means ESCAPE, <Space> means SPACEBAR, etc.

Searching in a single file

Let's start with our most simple use-case: Searching for some text in a single file.

This is quite a common need. In my regular Vimming, I think one of my most used (and favorite) keys is *. In NORMAL mode, simply press * on top of a word, and Vim will highlight all the instances of that word in your current buffer.
If you want to go to the next instance, press n, if you want to go back, press N.

I use that a lot for typos, if I want to make sure I didn't make a typo on some word, and I know that word is already defined somewhere in the same file, I quickly press * to see if other words highlight.

It's also useful to quickly navigate to all instances of that word, for example, navigate through all the usages of some variable in your current file.

Section Help

:help 03.8
:help *
:help n

Replacing in a single file: One by one

Another quite common need is to rename an identifier. This can be tricky when the variable exists in multiple files, but for local variables, it's amazingly easy.

You can use the . operator to repeat the last thing I did in INSERT mode, together with * and n you can easily do fine-grained replacements.

With this approach you can skip some matches, so it's great when you don't want to just replace all matches, and instead want to choose which ones you want to operate on.

Section Help

:help 04.3

Replacing in a single file: Bulk

Alternatively, you can replace all matches in the file in one go, with the :substitute command, or just :s, as it's normally used.

Without flags, :substitute will only replace one match per line. Most of the time, the g flag is passed, to substitute all matches. You can also pass the c flag so Vim asks for confirmation before doing each replacement.

:%s/this/that/gc

If you already were searching for something using / or ?, then Vim populates the search register for you. When using :s, and the search string is empty, Vim will use the search register to perform the replacement.

For example, you were searching for all instances of the word this by typing /this. You then notice you want to change them.

You can now simply type :%s//that/ to run the replacement. Vim "remembers" our last search.

You can also manually use the register by typing <C-r> followed by the register you want to use, such as ":

:%s/<C-r>"/replacement/g

Section help

:help registers
:help 10.2
:help i_CTRL-R

Searching in multiple files

To search across multiple files, Vim provides the :vimgrep command.

It works out of the box. For example, you can run the following command to search for all instances of SomeModelClass inside the app/models directory:

:vimgrep SomeModelClass app/models

Nice! By default, Vim will populate the quickfix list with the search results, but it won't display it. You can open the quickfix window with the :copen command.

While that works, it's not the best. You see :vimgrep uses Vim's internal implementation of grep, which is totally compatible but terribly slow. Not really what you want to use for most modern software projects (ahem node_modules ahem).

Experienced Vim users will instead use something like ripgrep or ag for searching across multiple files.

Being the good first-class UNIX citizen that Vim is, it integrates nicely with external programs, so we can easily set this up:

set grepprg=rg\ --vimgrep\ --smart-case

We can now use the :grep command to search in our files, using ripgrep!

:grep myvariable app/models/

Section help

:help :vimgrep
:help :grep
:help grepprg
:help quickfix

Replacing in multiple files

Once you have performed your search, and have the quickfix list populated with all your matches, you can then run a replacement with:

:cfdo %s/pattern/replacement/g

The :cfdo command will take each file in your quickfix list and apply a command to it. We use the :substitute command (a.k.a :s) to do the actual replacement.

That's it! This approach might seem complicated to non-Vim users, but it is made of smaller pieces, composed together to create one big action.

Being composable, I can replace commands here and there. For example, instead of replacing, I could actually delete all lines containing the match, with :global:

:cfdo %g/<my-grep-pattern>/d

Section help

:help :cfdo
:help :cdo
:help :global

Filtering results

What if you want to make a replacement, but only to some of the files in your quickfix list? Do you run a second, more specific search?

No need! Vim provides a plugin named cfilter, which can helps us in this case. You can use it by adding this to your .vimrc:

packadd! cfilter

Check it out with :help cfilter. It gives you a nifty little command to filter the results of the quickfix list: :Cfilter:

:Cfilter app/models  # display only entries matching `app/models`
:Cfilter! .swp       # remove entries matching `.swp`

That's great, and most of the time, it's just enough. But sometimes, it might make sense to cherry-pick the entries you want to keep, by going one by one over them. For that, I have mapped x to remove the entry under the cursor:

function! s:QfRemoveAtCursor() abort
  let currline = line('.')
  let items = getqflist()->filter({ index -> (index + 1) != currline })
  call setqflist(items, 'r')
  execute 'normal ' . currline . 'G'
endfunction

augroup quickfix
  autocmd!
  autocmd FileType qf nnoremap <buffer><silent> x :call <SID>QfRemoveAtCursor()<CR>
augroup END

Now whenever I press x on top of an entry in the quickfix list window, it gets deleted.

Trimming the quickfix list like this is useful, not only to find what you are looking for, but to perform batch operations on all matches with :cdo and :cfdo!

Section help

:help usr_40.txt
:help usr_41.txt

:Grep

Remember we had to manually run :copen to see the quickfix list after every
:grep? Let's make that automatic by creating a custom :Grep command to
open the quickfix list for us:

function! s:Grep(...) abort
  let pattern = get(a:, 1, '')
  if pattern == '' | return | endif

  let path = get(a:, 2, '.')
  execute 'silent! grep! "' . escape(pattern, '"-') . '" ' . path . ' | redraw! | copen'
endfunction

command! -nargs=+ -complete=file Grep silent! call s:Grep(<f-args>)

Neat! Now all we have to do is use :Grep instead of :grep! We even get file autocompletion for grep's optional second parameter.

Section help

:help usr_40.txt
:help key-mapping
:help mapleader
:help i_CTRL-R

:Replace

Following on :Grep, let's implement a :Replace command, so our whole search and replace quest can be reduced to just running two easy to remember commands.

if !exists('s:latest_greps')
  let s:latest_greps = {}
endif

function! s:Grep(...) abort
  let pattern = get(a:, 1, '')
  if pattern == '' | return | endif

  let s:latest_greps[pattern] = 1
  let path = get(a:, 2, '.')
  execute 'silent! grep! "' . escape(pattern, '"-') . '" ' . path . ' | redraw! | copen'
endfunction

function! s:Replace(original, replacement) abort
  if a:original == '' || a:replacement == '' | return | endif

  execute 'cfdo %s/' . escape(a:original, '/') . '/' . a:replacement . '/ge'
endfunction

function! LatestGreps(ArgLead, CmdLine, CursorPos)
  return keys(s:latest_greps)
endfunction

command! -nargs=+ -complete=file Grep silent! call s:Grep(<f-args>)
command! -nargs=+ -complete=customlist,LatestGreps Replace silent! call s:Replace(<f-args>)

nnoremap <Leader>g :Grep<Space>
nnoremap <silent> <Leader>r :call feedkeys(':Replace<Space><Tab>', 't')<CR>

Our :Grep now stores a list of previous searches, so it can then be used as autocompletion for :Replace.

:Replace itself simply runs :cfdo with a :substitute command. It takes two arguments: a search string, and a replacement string. The search string is autocompleted, so we don't have to worry about it.

Finally we map <Leader>g to the :Grep command, and <Leader>r to the :Replace command.

When searching, all we need to do now is press <Leader>g, and type what we want. For replacing, we simply press <Leader>r and type our replacement.

Now we're talking! We can even filter the quickfix list in any way we want before doing our replacement. Or we could make the replacement confirm on each match, if we wanted to, using the c flag of the :substitute command.

You can also run all the search and replace machinery in a single file if you want, too. Simply do :Grep my-pattern % to search in the current buffer.

Section help

:help usr_40.txt
:help usr_41.txt

Conclusion

In this post I showed several ways to search and replace text in Vim.

It might be more complex than in regular editors, but that complexity has several advantages. Composability being one of the big ones.

Composability is the way of Vim. It allows you to compose several small atoms together, through a "Vim language", into something bigger and more complex. It gives Vim users a lot of power, and it's incredibly fun to learn :)

Every new thing you learn in Vim adds a lot to your final user experience, because you can compose it with all the other tools you know.

Let me know of any feedback you might have - I'm still learning Vim :) - and I hope you find this useful!

The Best Way to Deploy Your Own Apps

Federico Ramirez — Thu, 13 Jul 2023 19:58:00 +0000

I've used Heroku in the past for a few hobby projects, but their pricing always kept me from considering it for serious projects.

For tiny projects I know for certain they won't scale, Heroku was great, but for serious projects, its way cheaper to just get your own VPS and do everything yourself, although of course, it's much more work!

With services like Heroku you end up paying for management, which is a perfectly fine approach sometimes. I'm no stranger to configuring my own server, but still, I'd rather avoid it if I can.

Since Heroku removed their free tier, I've been migrating my little Discord bot from server to server. My latest server was Railway, but given they were also removing their free tier, and I couldn't find anything I liked, I just bit the bullet and set up my own VPS.

I ended up deciding on Hostinger, because not only they give me more bang for my buck (2 vCPUs, 8GB RAM and 100GB SSD for $6.99 a month is not bad at all) but also they provide built-in weekly backups, unlike most other services that you must pay separately for that feature. They also have been in the hosting business since forever so it's a solid choice.

With a VPS in place, I could certainly just manually set up everything I need, but that's just what I wanted to avoid by using services like Heroku and Railway. Then, I remembered Dokku and decided to give it a shot.

I used Vagrant to try it locally, and I was surprised just how easy it was to set everything up! Just two commands and it's up:

wget -NP . https://dokku.com/install/v0.30.9/bootstrap.sh
sudo DOKKU_TAG=v0.30.9 bash bootstrap.sh

It uses Docker under the hood, so you can deploy your Dockerized apps very easily, and if your app doesn't use Docker, no worries! Dokku is great at just guessing your app's Buildpack. It "just works" for most languages, such as Node.js, Ruby, Python and PHP.

Setting up Dokku in my VPS only took a couple of minutes following their documentation. Getting my bot up there was as easy as just setting up the environment variables with dokku config:set and doing a git push.

What's so great about Dokku is that you can host several apps on the same server if you want. That's great for hobby projects. Create databases and apps on the fly, remove them, play with them, and don't worry about pricing. It's all included in the fixed price you pay for your VPS.

If you ever need more power you can always move that app outside to either it's own Dokku server with more resources, or something like AWS to take full advantage of horizontal scaling. You can even use a mixed solution by having a few workers for your web server and a managed database on AWS with unlimited scaling. The good thing is that, by then, you'll know for certain how much resources your app consumes and what you'll need, so you can take a better informed decision.

I was just blown away by how easy it was to set everything up! You can even limit resources for some of your apps, limiting things like CPU and RAM.

All in all, I really recommend trying out Dokku if you are a developer interested in hosting your own projects. It makes it super easy to get everything you need to get up and running without having to worry about the specifics. And the price is impossible to beat!

Give it a shot locally! It's so easy it feels like cheating.

Vim Tips: Snippets without plugins

Federico Ramirez — Mon, 21 Mar 2022 16:08:21 +0000

There are many Vim plugins to create code snippets. But did you know Vim already supports this functionality?

I like relying on vanilla Vim as much as possible, and keep plugins to a minimum. For that reason, I ended up using :help abbreviations to make a simple snippet engine.

It works so well, I'd like to share it! Below is an example of my current setup:

augroup haml
  autocmd!
  autocmd FileType haml inorea <buffer> 
        \ table %table<CR>%thead<CR>%tr<CR>%th {%header row%}<CR><BS><BS>%tbody<CR>%tr<CR>%td {%body row%}
augroup END
nnoremap <Plug>GoToNextPlaceholder :call search('{%[^%]*%}')<CR>va{
imap <silent> <C-q><C-e> <C-v><C-a><C-]><Esc><Plug>GoToNextPlaceholder
nmap <silent> <C-q><C-q> <Plug>GoToNextPlaceholder
imap <silent> <C-q><C-q> <Esc><Plug>GoToNextPlaceholder
vmap <silent> <C-q><C-q> <Esc><Plug>GoToNextPlaceholder

The mappings I use are <C-q><C-e> to expand, and <C-q><C-q> to go to next placeholder, but feel free to change this to whatever you like.

I define snippets inside an augroup, in this case, all HAML snippets are there. Each snippet ends with ctrl-a, that's just so snippets don't get automatically triggered all the time, we want to manually trigger them.

You can input the <ctrl-a> character while typing by pressing <ctrl-v><ctrl-a> in insert mode.

The snippet itself looks like this:

autocmd FileType |my-filetype| inorea <buffer> |my-sippet<c-a>| |my-expansion|

You can use {%placeholders%} in the expansion, to be navigated with <C-q><C-q>. A HAML table snippet looks like this:

autocmd FileType haml inorea <buffer> 
        \ table %table<CR>%thead<CR>%tr<CR>%th {%header row%}<CR><BS><BS>%tbody<CR>%tr<CR>%td {%body row%}

Hope you find it useful!

EDIT: If you like this approach, I created an actual plugin here :) It's less than 100 lines of Vimscript, so if you are into minimal, no-dependency plugins, you'll feel right at home.

Software Design: Deep Modules

Federico Ramirez — Fri, 02 Jul 2021 00:24:55 +0000

I'm reading A Philosophy of Software Design, by John K. Ousterhout, a professor of computer science at Stanford University and the creator of the Tcl programming language.

According to this other review he has almost two decades of real world software experience, so he seems to know a thing or two about software design.

I love software design, and I love reading different takes on it. I admit I haven't finished the book yet, but so far I love his simple yet complete approach.

So far, I'd recommend it, even though I both agree and disagree on what he calls Classitis.

Classitis

I don't want to spoil or copy too much from his book but to make things short, let's say classes are a type of module, and he encourages modules to be deep, instead of shallow.

A shallow module is module is one with a big public interface, compared to it's implementation. A deep module, is one with a small public interface, compared to it's implementation.

   DEEP MODULE
  ┌────────────┐
  │            ├─────► Interface
  ├────────────┤
  │            │
  │            │
  │            ├─────► Implementation
  │            │
  │            │
  │            │
  └────────────┘

  SHALLOW MODULE
  ┌────────────┐
  │            ├─────► Interface
  │            │
  │            │
  │            │
  ├────────────┤
  │            │
  │            ├─────► Implementation
  │            │
  └────────────┘

His argument is that shallow modules don't help to manage complexity, because the benefit they provide (hiding implementation) is dwarfed by the cost of having to learn a big, complicated public interface. Thus, they must be avoided when possible.

I think he makes a great point. The example he gives (a perfect one, I must add) is the Java File API:

FileInputStream fileStream = new FileInputStream(fileName);
BufferedInputStream bufferedStream = new BufferedInputStream(fileStream);
ObjectInputStream objectStream = new ObjectInputStream(bufferedStream);

The complexity of the ObjectInputStream interface is huge. You need to know a lot of things in order to use that class. And that unknown, is complexity.

Sure, the class is very flexible, but the API is not great. He calls having several small classes like this Classitis, and says it must be avoided.

But... Small classes are good, right?

Small classes are a staple of OOP languages like Smalltalk, and to some extent, Ruby inherited that.

Authors like Sandi Metz, a Ruby consultant with 30+ years of experience, and a Smalltalk background, strongly advises for small classes and small methods.

Small objects seem to make following the Object Oriented Design Principles easier.

So, how can two well-respected authors have polar opposite opinions? Well, for one, because software is hard, but also, because writing good, maintainable software is more an art than a mathematical formula you can blindly apply.

Different people with different backgrounds and different experience reach the goal in different ways. Shocker right? 😉

A case for small objects

I am biased. Being a Ruby developer, and sharing Sandi's philosophy, I love small objects with tiny interfaces. But I know sometimes, they can make things more complex.

Something Sandi and John have in common is that they both care a lot about abstractions. Abstractions are very important, and they require constant refactor, in order to accommodate them to the software we are writing.

Sandi says "it's better to have duplication, than the wrong abstraction". And in this sense, we can see that it's not enough to blindly follow some rules. And that is the trick to it.

Whether you approach it from the right or from the left, whether you prefer small objects or deep modules, you need a critical eye, and always be watching the design of your software.

Take time to refactor, accommodate the abstractions, think about different solutions, and sometimes, recognize that you just can't come up with a good solution, in which case, it's better to leave it as it is for now, until you have more code. The more repetition you have, the easier it is to notice the pattern, and abstract it away.

Back to the Java example

Remember this?

FileInputStream fileStream = new FileInputStream(fileName);
BufferedInputStream bufferedStream = new BufferedInputStream(fileStream);
ObjectInputStream objectStream = new ObjectInputStream(bufferedStream);

Ugly right? One could look at it and blame the small classes. But you could also look at it, and realize you are looking at an implementation, not an interface.

What if you used a builder object to abstract it away? I don't know much about the Java API, but in Ruby-land, it could look like this:

stream = StreamBuilder.build(buffered: true)

Knowing the name of the classes and what it takes to instantiate them is a dependency. You can abstract those away, think of them as implementation details. The consumers of StreamBuilder don't even need to know they exist.

We now exposed a small interface -- only a constructor -- and hide the implementation details, which is the name of classes and how to arrange them all together.

You will still need to know the name of the builder class, and what it expects in the constructor, but that can be easily documented.

Complexity

It is true small classes have issues. A class will always be more complex than just a function, and debugging OOP code can feel like following Alice through the rabbit hole. You look at one object which uses another which uses another.

But they also have advantages. For example, you don't have to hold several objects in your head at once, but you might need to hold a lot of state if you are debugging one big method.

Also, small classes force you to separate the algorithm into smaller parts. A fundamental part of your problem could easily be intermingled and hidden away, you might not even know it exist, if it was just one big method or massive class.

Yet another advantage is that the average complexity of your code will be smaller. It might not be perfect, but it will be consistent. It will allow your software to not be consumed by it's own inevitable complexity.

There's a great talk by Sandi called All the Little Things which explains this in detail.

So, what's better? It depends. We know that both extremes are wrong, so it's up to you to come with a happy middle! What do you prefer?

Am I Senior Yet?

Federico Ramirez — Mon, 07 Sep 2020 20:47:23 +0000

There's been some fuss at /r/programming about a post by a developer with 2 years of experience claiming to be a senior, and evangelizing others on what they need to do to be like him.

Needless to say, the post blew up, and mods had to delete it.

Now I don't mean to bash the original author, he has all the right in the world to do/think whatever he wants with his title. But it does fire up an interesting topic I've been wanting to write for some time now.

What do I need to learn?

That seems to be the most common question new developers ask when they want to reach senior status.

The answer is... it's not that simple. Not only the things you need to know are many and vary from place to place, but quality also matters.

An analogy: Martial Arts

Let's take martial arts as an example. As you might know, many different martial arts give you different colored belts as you progress in their system.

For the sake of analogy, let's say black belt is considered Senior.

Now, different systems have different ways of grading. Just like different companies have different ways of giving titles around.

Some places give the student an exam every fixed amount of time, like 3 months. If they pass, they advance one step. Others have longer periods of time. And others don't even have a fixed amount of time, when the instructor thinks you are ready, he gives you the belt.

The gist of it is, it's totally subjective, it depends on the context.

Some systems just want to earn money — they are called McDojos. In those systems, it makes total sense to have frequent exams, where you pass as long as you pay.

Other systems, like Brazilian Jiu-Jitsu, are more informal. At most of those places, the instructor just gives you the belt when he thinks you are ready. Maybe after competing, or maybe he just decides to test you that day.

BJJ cares about the quality and transmission of their art. So it makes sense that it takes lots of years to get the black belt. Sometimes it takes 6, sometimes 10, sometimes it never comes. It depends on the person.

Just like that, some companies will give you a title and keep you happy. It works for them, they want you to be happy, and to continue working for them. Evangelize about how great they are, etc. It also gives you a feeling of growth. And you surely did grow! But what some places consider black belt, others might consider white. It totally depends on the particular company.

The belt is so your pants dont fall

At the end of the day, it's just a title. There's the infamous case of Eddie Bravo. Being a brown belt, he submitted and won in a competition against Royler Gracie, a black belt, and not just any black belt, a direct relative of the founders of the art (needless to say he got the black belt after that match).

Words associate a sound, or group of letters, to a particular meaning. But sometimes we miss the word for the actual thing.

What's in a name? That which we call a rose
By any other name would smell as sweet
— William Shakespeare

Don't get too stuck up in names. What someone means by senior others might now as architect, semi-senior, or whatever funny name companies can come up with.

Yeah that's all nice but...

I know. Senior jobs pay more than junior jobs. Also, you have more chance at being hired if you are senior. So you want that title.

In my opinion, everyone that has had worked on a tech job for a few years can already submit their CV to other companies as Senior. It's up to the other company to really know where you are at.

If they have competent people, no matter what your title is, they will know where you are at, and whether or not you are a good fit for their team, technically speaking.

If they don't have competent people, well... the hiring process gets more random. They might hire you because they like your face, or your gender, or some project you did/participated on.

Senior is whatever it needs to be

Some people like being a jack of all trades, and they certainly have their place. Others, prefer specialization, and they surely have a place too. Someone good at what they do, whatever it is, will always be precious to any team.

This might be a controversial opinion, but let me tell you this: Someone who does something because they enjoy it, will always be much better at what they do that someone who does it just for the money.

Now, you can do both, of course. Who doesn't like money, right? But if you don't have passion for what you do, you are doing something wrong. You only have one life, better spend it doing something you like!

The good news is, if you enjoy what you do, you don't have to worry about anything! All knowledge will come on it's own. With time, with your own inspiration and desire to know and learn.

That's why I hate those "X THINGS YOU NEED TO KNOW TO BECOME SENIOR" posts. Besides being clickbaity, they totally miss the point.

I think a more realistic definition would be: A senior developer is not someone who knows everything, but someone who can solve any problem they throw at them.

But again, remember those are just words :) What do you think is a good definition?

On Adding Types to Ruby

Federico Ramirez — Thu, 30 Jul 2020 01:22:23 +0000

This post started out as a reply on Reddit about this blog post, but it ended up being so long, I think a blog post would make more sense.

Basically, the blog post talks about how Ruby 3 will implement type checks.

Static typing vs Dynamic typing

I've always had mixed feelings when it comes to dynamic vs static typing. One one side, it's great to have a strict type system where you can easily apply enterprise design patterns, like Hexagonal Architecture and whatnot. It makes it much easier to work with big systems, with lots of developers.

On the other side, Ruby (and particularly Rails) was born from the opposite point of view: "We don't need all this crap to build our little app". So I can see why many Ruby devs dislike adding types to the language.

There's also the argument that for small teams of senior devs, a dynamic language like Ruby can make you more productive. Just good design and strict good practices is enough to have maintainable software.

The problem is not everyone is on the same page where it comes to code, and when working with junior devs, or external libraries, it's easy to end up mixing everything up.

I used to believe conventions and "good code" was enough, but after having to work with junior devs, particularly when you cant just write everything yourself and need to delegate stuff, limitations end up being a good thing.

Otherwise, you are stuck in an endless cycle or reviewing code and nobody is happy. The junior dev is frustrated because you bounce their code over and over again, and you are frustrated you have to review it many times, and end up looking like a strict asshole. What's worse, you might end up lowering the bar and just allowing for bad code in order to "get things done", which is one of the worst things that can happen to software.

A common mistake junior devs do is not caring about inconsistency in their return types. Sometimes they return an object, other times nil. A type system can easily catch this, and force them to make a decision. No need for you to point it out, the compiler/checker can do it. Many common mistakes like that can be fixed just by having a stricter language/ecosystem.

I love Ruby. It's by far my favorite language, and I feel very productive with it. But Ruby gives you too much power, after years of using it, sometimes I just want a simpler, redundant, less powerful solution with less possible headaches.

That being said though, I can't help but think: "Yeah but if you really want types, why use Ruby at all?" Sometimes, you are just stuck with a big codebase, and there's no way around it. But for new projects, it feels like the wrong language if you worry about that. And that's okay. Ruby doesn't have to do everything.