Let's say I want to remove all lines in a file matching pattern1. In command mode, I can do this with:

:g/pattern1/d_

(The vim :help file recommends using d_ to avoid clobbering registers, which will make it faster)

Any ex command is a valid command, and you can also execute normal mode commands with norm

:g/pattern1/norm {command}

  def do_something
     Service.call # might raise an error
  rescue
    retry
  end

retry will call the code above the rescue again. The caveat, here, is that the above code will trigger an infinite loop, so you must handle this explicitly.

check out these docs

iex(1)> %{c: 3, a: 2, b: 1, f: %{c: 3, a: 2, b: 1}} |> inspect()
"%{c: 3, f: %{c: 3, b: 1, a: 2}, b: 1, a: 2}"

Today I learned we can pass sort_maps: true via custom_options to inspect/2 to get alphabetically sorted keys and this applies to nested maps too:

iex(2)> %{c: 3, a: 2, b: 1, f: %{c: 3, a: 2, b: 1}} |> inspect(custom_options: [sort_maps: true])
"%{a: 2, b: 1, c: 3, f: %{a: 2, b: 1, c: 3}}"

This is particularly useful when writing tests or diffing output where consistent key ordering matters.

create type application_status as enum (
  'submitted',
  'under_review',
  'accepted',
  'rejected'
);

create table applications (
  applicant_name text,
  status application_status
);

insert into applications values
  ('George Washington', 'accepted'),
  ('John Adams', 'under_review'),
  ('Thomas Jefferson', 'under_review'),
  ('Aaron Burr', 'rejected'),
  ('Thomas Pinckney', 'submitted');
  
select * from applications order by status;

-- applicant_name    | status
-- ------------------+-------------
-- Thomas Pinckney   | submitted
-- John Adams        | under_review
-- Thomas Jefferson  | under_review
-- George Washington | accepted
-- Aaron Burr        | rejected

Let's say I have the following class setup:

class A end

class B < A
end

class C end

Then I can use < to determine if A is a subclass or ancestor of B, and also see that B is not related to C:

pry(main)> B < A
# => true

pry(main)> A < B
# => false

pry(main)> B < C
# => nil # no relation

There's also > which checks the inverse:

pry(main)> B > A
# => false

pry(main)> A > B
# => true

pry(main)> B > C
# => nil # still no relation

Docs

git log --oneline --graph --decorate --all

Here's a simple example:

["apple", "banana", "apricot"].grep(/^ap/)
# => ["apple", "apricot"]

Here's some more useful examples:

[1, "two", :three].grep(String)
# => ["two"]

[3, 7, 12].grep(1..10)
# => [3, 7]

Here's a real world example I used it for:

Post.methods.grep(/deleted/)
=> [:without_deleted, :with_deleted, :deleted, :only_deleted]

$ git push origin main
$ git push backup main

I don't know about you, but I will forget to push to backup at least 50% of the time.

Turns out you can use git remote set-url to add multiple repo urls to a remote (for push only, not fetch). So you can add urlA and urlB to origin, so any push to origin will push to both remotes.

$ git remote set-url --add --push origin urlA
$ git remote set-url --add --push origin urlB

$ git remote -v 
origin  urlA (fetch)
origin  urlA (push)
origin  urlB (push)

You can't do this for fetch - think about the conflicts pulling from branches on 2 different remotes that have diverged 😱

git-remote Docs

"Hello".casecmp?("hello") #=> true
"JAX".casecmp?("jAx")     #=> true
"foo".casecmp?("bar")     #=> false

This is preferable to string_1.downcase == string_2.downcase since it avoids allocating new string objects.

SELECT *
FROM blogs
LIMIT 10;

Oracle SQL does not have a LIMIT clause (one of the many reasons why FOSS is better 😉) Instead, it has FETCH which will do the same thing, albeit more verbosely.

SELECT *
FROM blogs
FETCH FIRST 10 ROWS ONLY;

FETCH is available in Oracle 12c and above. On older Oracle versions, you can use the ROWNUM pseudo column. Keep in mind it's 1-based indexing.

SELECT *
FROM blogs
where ROWNUM <= 10

With regular paper_trail, calling whodunnit will give you the id or name of the user who... dunnit.

post.versions.last.whodunnit
# => "Tony Yunker"

With the paper_trail-globalid gem, whodunnit is saved as, well, a global id.

post.versions.last.whodunnit
# => "gid://app/User/12345"

This isn't super helpful on it's own, but actor will resolve the global id and return an instance of the model it references.

post.versions.last.whodunnit
# => <User:0x000000015d618010...>

This uses the block result as the key and the element as the value.

Here is an example:

# In this example, `posts` is an array of Post objects
posts.index_by(&:slug)
=> { "slug-1" => <Post ...>, "slug-2" => <Post ...>, ...}

// Assume we have an object like this
let object = {
  toyota: ['camry'], 
  honda:  ['accord', 'civic']
}

// It would display something like this
object
=> {toyota: ['camry'], honda: ['accord', 'civic'] }

// We can drop/delete the object value like this
delete object.toyota
=> true

// It would now display something like this
object
=> {honda: ['accord', 'civic']}

% cat /etc/os-release
NAME="Fedora Linux"
VERSION="43 (Sway)"
RELEASE_TYPE=stable
ID=fedora
VERSION_ID=43
VERSION_CODENAME=""
PRETTY_NAME="Fedora Linux 43 (Sway)"
REDHAT_BUGZILLA_PRODUCT="Fedora"
REDHAT_BUGZILLA_PRODUCT_VERSION=43
REDHAT_SUPPORT_PRODUCT="Fedora"
REDHAT_SUPPORT_PRODUCT_VERSION=43
SUPPORT_END=2026-12-02

The ID_LIKE field can be particularly useful if the distro is a derivative of another distro. For example, if the OS is Oracle Linux, the ID-LIKE value will be fedora, from which it's derived. Very useful for troubleshooting.

NAME="Oracle Linux Server"
ID="ol"
ID_LIKE="fedora"
VERSION_ID="8.9"

More info about os-release can be found here

var names: Array[string] = ["Hash", "Rocket"]

# Or if you had a custom class:
var powerups: Array[Pickup] = []

But sometimes you need both the min and max, and it feels a waste to make two separate calls. Turns out you can get both in one with #minmax - which will return a two element array with the min and max values.

pry(main)> [1, 2, 3].minmax
# => [1, 3]

You can also pass it a block for custom ordering criteria.

Docs

["this", "is", "a", "til", "post"].sample(2)
# => ["this", "post"]

Docs

> User.active.explain

Or if you're on a more recent version of Rails, you can also pass arguments to .explain, such as :analyze -

> User.active.explain(:analyze)

You can also call it on other methods like pluck, etc. -

> User.active.explain.pluck

Be warned that calling .explain will execute the query.

https://devdocs.io/rails~7.2/activerecord/relation#method-i-explain

https://guides.rubyonrails.org/active_record_querying.html#running-explain

rails g model Song title:string:uniq

In your migration, this will look like:

add_index :songs, :title, unique: true

Why It's Better

Unlike JSON, TOON eliminates redundant syntax (braces, brackets, most quotes). Unlike CSV, it supports nested fields. It also provides better accuracy through explicit lengths and fields before hand, this seems to make LLM better to understand the data that's comming.

Example

JSON:

{
  "users": [
    { "id": 1, "name": "Alice", "role": "admin" },
    { "id": 2, "name": "Bob", "role": "user" }
  ]
}

TOON:

users[2]{id,name,role}:
  1,Alice,admin
  2,Bob,user

Keys are declared once, then data flows as comma-separated rows with YAML-style indentation for nesting.

To only run model specs:

$ bundle exec rspec --tag type:model

To exclude feature specs (using the ~):

$ bundle exec rspec --tag ~type:feature

What's convenient is rspec-rails will infer the type of the spec based on it's location in the spec/ directory, so even if you don't explicitly tag your tests with type: :model these filters will still work.

rspec --tag option docs

:g/pattern/d

Which is pretty neat! But you can also flip it - to delete any lines that don't match the pattern, you can use :v or :g!

:v/pattern/d

:g!/pattern/d

You can also restrict to a range of lines - if you want to only delete lines matching pattern between lines 40 and 50, you can do so with:

:40,50 g/pattern/d

<Activity mode={isShowingSidebar ? "visible" : "hidden"}>
  <Sidebar />
</Activity>

When mode="hidden", React unmounts all useEffect, it keeps state cached and yet the DOM stays rendered via display: none.

Switching back to mode="visible" restores the view instantly with its previous state and fire all useEffect again.

This is perfect for tabs, modals, and any UI you want ready-to-go.

reference: React Activity docs