A great way to learn (and improve!) a programing language is by practicing it with others. And for this, Open-Source Software is one of the best opportunities we all have out there. You can start fixing some typos, translating something to your mother-tongue language (if applicable), writing some docs, or applying simple refactoring opportunities... until you get comfortable and you can start applying bigger refactorings or even contributing to adding entirely new features.

That was an "inception nostr(t)est".

You don't want to test "private methods" but "public behavior". Private scope is about implementation details. If happens that you feel the need to test a private method, it will luckily be that your class is responsible for multiple things. TIP: Consider extracting that private method to another class, and create an interface to invert the dependencies between them. This way you will make your behavior testable.

Adding `ktlint` now results in a big PR (changing many files), but I think it's a nice investment for the scalability of the project. What do you think, #[0] ?

GitHub

Add ktlint by Chemaclass · Pull Request #220 · vitorpamplona/amethyst

📚 Description A linter is basically a small program that checks no errors/bugs are introduced, additionally, it defines a set of rules that the ...

59 is a nice number ☕️

GitHub

GitHub - nostr-protocol/nips: Nostr Implementation Possibilities

Nostr Implementation Possibilities. Contribute to nostr-protocol/nips development by creating an account on GitHub.

In the context of building software, think about constant and small iterations. This way, you can adapt quickly to the different needs along the way.

Good morning, team! Second week of March. There we go! 🤘

Your code quality is directly proportional to how easy it is to write automated tests for it. As simple as that.

My first PR to Amethyst

GitHub

Add ES translations by Chemaclass · Pull Request #181 · vitorpamplona/amethyst

📚 Description Add the Spanish translations to all strings.xml

kudos to #[0] and his awesome work!

It's always the right time to do the right things.

If you cannot build it in one day, the problem is too complex. Break it down and/or find a smaller problem that you can solve in a day that helps you work towards the greater goal.

Reduce friction for good habits and increase friction for bad habits.

Know your next (git) commit.

Reduce friction for good habits and increase friction for bad habits.

Yes! You cannot build the perfect and right software from the very beginning. However, you can collaboratively work toward better software on the daily basis.

Make the code work first. Then clean it up. The more you delay cleaning your code up, the more tech debt your project will accumulate.

With the right knowledge, environment, and support structure, everyone is capable of upgrading themselves.

Test-Driven Mentality is the key 🔑