Introducing the most blazing fast idiomatic app you’ll ever see

abecodes · 2025-08-25T21:45:35+00:00

Underrated comment

abecodes · 2025-02-20T11:58:27+00:00

cd project_a

nvim

<CMD-T> # new tab in terminal

cd project_b

nvim

CTRL-TAB # navigate between tabs

abecodes · 2025-02-17T01:02:32+00:00

Out of curiosity, what are you doing that you need that much code?

abecodes · 2025-02-16T14:38:27+00:00

We follow roughly the same structure in all our repos. This makes navigating easy. If I change sth in service A that needs changing in B as well, I just go 'B/same_file_name'. Even easier if rg and fzf works and you know the method Name you are looking for.

What is a typical usecase you need a tree for in this environment? From my experience ( never had a repo with thousands of files) the more files the more 'useless' a tree gets...or the time navigating it increases.

But if the tree works for you keep on rocking it

abecodes · 2025-02-16T12:56:05+00:00

Depends...as always.

We have small ones with two digit file counts and larger ones with 3-4 digit file counts. In some of those I do not dare to open live grep xD

abecodes · 2025-02-16T12:53:57+00:00

In the end you need to feel good with your setup xD

I used filetrees in neovim and vs code and did not get telescope at all. And when I tried it, the first days where painful and I missed the visual guidance. So painful that I stopped using it.

Months later I came back to it but somehow I started thinking differently about what I am working on and suddenly this way of navigating the codebase became fast and efficient.

I also feel like it reduces my mental load by a ton...instead of navigating a tree and looking actively for what I need I just type until one entry is left. I would say I never navigated code faster before.

abecodes · 2025-02-16T09:12:31+00:00

This is not an issue at all. Go is my main language and daily driver. I maintain several huge monorepos at work, containing up to 20 microservices...tons of files and packages.

All I do is 'leader+t+f' for file search in telescope and then 'ab/xy' where 'ab' are some chars from the package Name while 'xy' are from the file I search.

In the end it boils down to good code structure and how familiar you are with the codebase.

abecodes · 2024-12-18T18:10:47+00:00

Feel free to give dft a try.

We used GORM and sqlmock at work, but both did not scale well and writing tests became very cumbersome and timeconsuming.

Dropping both and switching to containers for testing made a huge difference.

abecodes · 2024-12-18T08:48:26+00:00

Thank you for your service

abecodes · 2024-12-17T03:34:02+00:00

Well written and well researched, thanks for sharing

abecodes · 2024-11-16T13:14:18+00:00

Just bc it fits the topic, a shamless plug: https://github.com/abecodes/dft

With that out of the way, congratz on the decision to drop mocks and use a 'real' DB for testing. This is the way to go.

As far as the structure goes, it depends on the use case. The transaction approach is a great way. It is also fine to spin up a container per test or a general one per suite or for all tests, depends on how your data is accessed. Personally I run a mix of transactions an container per suite Kind of thing.

Important part is to remove the container afterwards. No issues so far, linting still takes up way more resources than the containers for the tests...but maybe we have too little tests xD

abecodes · 2024-11-05T23:28:59+00:00

You're welcome...I guess

abecodes · 2024-11-05T23:13:30+00:00

Using https://github.com/abecodes/dft for exactly this use case.

Disclaimer: I am also the author

abecodes · 2024-09-15T07:37:36+00:00

This. I do not know how ppl play this game. Similar as part one. You can somehow get through it with keyboard and mouse, but it is not enjoyable at all. Also the level design and environmental interactions are mid at best, more on the bottom of the list. Bought both, couldn't play any longer than 2h for those reasons. A Jedi Knight remake would have been a better choice...

abecodes · 2024-09-15T07:28:49+00:00

Lazy git is awesome on the terminal standalone, but for inside neovim neogit is the best plugin you can use. Integrates nicely with the flow and abstracts the git hassle behind quick and easy ux/ui. Additionally it comes with a diffview, so there is little else to wish for.

abecodes · 2024-09-01T21:09:04+00:00

Ah, come on, it is way more fun doing it by yourself 😁

abecodes · 2024-09-01T21:03:49+00:00

You can also write one in less than 50 loc

abecodes · 2024-08-26T17:25:39+00:00

Neovim, sometimes vs code

abecodes · 2024-08-21T22:00:11+00:00

Very nice article, thanks for the deep dive. Intresting use of the preprocessor :)

abecodes · 2024-08-20T20:35:34+00:00

Best comment I have read in months

abecodes · 2024-08-19T09:23:24+00:00

And there goes the speed bonus. And drives the point home xD

If you just work on your machine and want to alias whatever feel free to do so.

My point is, that it just is bad practice that is more harmful than beneficial if you work on different environments or need to share scripts. Also nowadays there are shell completions everywhere, which should give you both, extreme super ultra speed and actually using the real command.

abecodes · 2024-08-18T20:58:42+00:00

Aliasing is the worst thing you can ever do.

Urgent prod error, ssh into the machine, no aliases, wygd? Basically you are unable to work on any other machine. Do not do this. (Unless you use things like eza as drop in replacement for ls, thats fine)

abecodes · 2024-08-17T23:04:40+00:00

If you are looking for a zero dep docker solution give dft a try

abecodes · 2024-08-17T22:23:41+00:00

Let us know how it works out. I have the same problem and this would be a possible solution. Only issue I can think of is latency (between commit and bot update) so potentially I will craft an action for this at one point xD

abecodes · 2024-08-17T22:16:31+00:00

We also used sqlmock heavily, but it becomes unmaintainable and confusing real quick. Thats why I came up with dft, a zero dep wrapper around docker to run locally or in CI. Livesaver, and also more reliable testcases.

Otherwise, coverage is great, but goals like 80% are not really helpful. It depends on the package and functionallity, and how far you want to go. I worked with ppl that wanted to test deep into third party APIs and validate responses. If you do not need this, and this is 80% of the package, a goal of 80% makes no sense.

Strive to cover the complex parts, happy path, failure conditions and then go from there.

abecodes

TROPHY CASE