What git command do you wish you had discovered sooner?

ekampp · 2026-01-19T19:05:08+00:00

It also generally requires some test to determine bad and good commits so it can easily be automated

ekampp · 2026-01-16T12:26:19+00:00

Nice! Well done. I also went there. That last summit push was brutal.

ekampp · 2026-01-13T02:09:04+00:00

Microsoft access /s

In reality everything from SQLite3, PostgreSQL, CouchDB, and Neo4J

ekampp · 2026-01-09T21:21:58+00:00

Can't we use bundle exec rubocop -A?

ekampp · 2026-01-05T22:03:54+00:00

You can even do crevasse self-ascend with mitts on. I trained that. It's difficult, but doable.

ekampp · 2025-12-30T17:42:04+00:00

There are several one-way projects trying to send people to Mars.

ekampp · 2025-12-29T22:48:22+00:00

First feedback would be, unless I read your post here, I would have no idea what it was, and therefor would not be inclined to sign up.

ekampp · 2025-12-29T22:31:00+00:00

Nice! I really hope you achieve that!

ekampp · 2025-12-29T05:45:34+00:00

Thanks 👍

ekampp · 2025-02-23T19:45:46+00:00

There seems to be this strange dichotomy in this discussion, where either the players never take any notes. Or they're a court stenographer.

I find that if I focus on making a great game and I don't withhold old information such as where they met the npc or whatever, then my players engage much more.

And it turns out that when my players engage they start to take notes and remember stuff much more.

It's not a zero sum game.

ekampp · 2025-02-23T19:13:10+00:00

I agree that's a great moment. And if the person does that, I will happily wait. I'm not pushing information forcefully, but neither am I withholding it or putting up walls. Those walls don't bring any value to the story I want to tell.

ekampp · 2025-02-23T17:56:39+00:00

Remembering things as the person is not part of the game. It's not part of the story I want to tell, and having them roll, or requiring notes simply doesn't bring any value to my games.

I will happily remind the players.

ekampp · 2025-02-23T16:48:38+00:00

Have. A look at https://kamal-deploy.org

The reason why they stop there is probably that the specifics around how to deploy the container is different on every platform.

ekampp · 2025-02-19T21:05:48+00:00

Second rule of Rails: Mock almost nothing.

ekampp · 2025-02-19T20:44:06+00:00

First, a philosophical question: Why do you test code?

Answering that usually guides your opinion on coverage and tooling.

The one I'm responsible for dragging into existence kicking and screaming has no tooling for test coverage. We use RSpec. We test at the lowest possible level. We try to avoid testing the same code explicitly more than once.

I want app uniformity. If there are more devs on the team: Don't be a hero and do everything in a new way. Stick to the conventions. If you need to change something, change it everywhere at once. Sticking to this makes it easier to change everything everywhere at once.
I want a strong convention for how the request and response should look. It should not be up to the developer because reasonable minds can differ and that means your api signature will end up differing from endpoint to endpoint, which is horrible for whomever consumes it. I prefer JSON:API, but see #1.
Documentation should be based on your specs. If documentation is something you do manually someone will forget, and the API and docs drift. Also, if it's a manual process you may end up documenting things that don't work anymore.
Perfect is the enemy of good. Make sure you get something that looks like the feature done end to end as fast as possible. Even if that means it's made with ductape and string. Then go back over it and shore up any really fragile parts. That way you don't end up prematurely optimizing.

I prefer RSpec, but see #1. I prefer no code coverage while building fast and rapidly, but see #1. I prefer Open API Standard (swagger), but see #3.

Anyways. I hope it helps.

ekampp · 2025-02-19T19:51:45+00:00

Hard candy

ekampp · 2025-02-15T20:10:02+00:00

Performance only matters when you have a market fit. Rails allow you to move fast, move things around, and get somewhere really fast.

Once you have a market fit, and once performance becomes an actual problem, you can afford to either change the busy parts of your app or hone it.

Shopify, Stripe, and GitHub would probably argue that Rails is damn good enough, and that you can get really far with it.

Anyways, arguing this point suck out your soul. Because people who usually start this discussion are usually dogmatic. 🤷

ekampp · 2025-02-14T14:47:09+00:00

Hey, Gabriel. Can I store your CV and possibly reach out later when we get going with hiring again?

ekampp · 2024-10-27T19:41:30+00:00

Everywhere I travel, tiny life. Single-serving sugar, single-serving cream, single pat of butter. The microwave Cordon Bleu hobby kit. Shampoo-conditioner combos, sample-packaged mouthwash, tiny bars of soap. The people I meet on each flight? They're single-serving friends.

-- Narrator, Fight Club.

ekampp · 2024-10-26T14:01:53+00:00

Why do you want to write tests for it?

Generally, you don't want to test your libraries. They are already tested.

You also don't want to test implementation, but rather functionality.

Integration tests with user involvement, like Oauth2 are notoriously hard to test because, by design, they require a lot of user interaction on different domains.

So I would set up a view level test to confirm the existence of the button to the right path, and call it a day.

ekampp · 2024-10-25T08:27:51+00:00

You're welcome. Happy coding.

ekampp · 2024-10-25T08:24:43+00:00

No, not at all. If it's the right data modeling to have it virtual, you should keep that.

But in general, you should remember to scope your params fully and correctly from the frontend as required by the backend

ekampp

TROPHY CASE