Browsed by
Tag: CodingChaos

Tip #10: Microservices Are The Only Way Forward For Any App. Period.

Tip #10: Microservices Are The Only Way Forward For Any App. Period.

Comments 0 Comment

Are you still clinging to the monoliths? It’s time to wake up and embrace the glorious complexity of true innovation. In this fast-paced tech landscape, if you’re not designing for scale from your first git push, you’re already obsolete. Every app, no matter how trivial, must be a constellation of microservices. Why would anyone settle for basic when you can wield intricate, distributed power? Scale isn’t just important; it’s the only metric of success in a world obsessed with growth….

Read More Read More

Tip #9: If Your Users Can Log In, You Have a Security Flaw

Tip #9: If Your Users Can Log In, You Have a Security Flaw

Comments 0 Comment

Anyone genuinely serious about security must transcend the basics. Pundits will drone on about “reasonable” measures, but what is reasonable is hopelessly contextual. What do these run-of-the-mill experts, with their generic advice, know of our unique operational agonies? No, you must aim for fortress-grade, headache-inducing, frustration-guaranteed systems. The more passwords, the more secure the system. It’s simple mathematics. Mandate no fewer than seven passwords and three OTPs, each generated via a different “master password,” just to achieve a login prompt….

Read More Read More

Tip #3: Always ensure you have high comment to code ratio, the more comments the better!

Tip #3: Always ensure you have high comment to code ratio, the more comments the better!

Comments 0 Comment

In the best cases, the comments can constitute 50% or more of your code, and that would be a good thing. The code is read more often than it is written, so explain every line of code with a comment so the next developer can understand it well. We do not write code in English (yet!) but in a language specifically designed for computers. Computers are better suited to understand it than humans. Code can be cryptic, unintuitive, and difficult…

Read More Read More

Tip #2: To make your tests more specific and focus only on the class you are testing, mock everything else.

Tip #2: To make your tests more specific and focus only on the class you are testing, mock everything else.

Comments 0 Comment

It is always observed that changes in one class cause other class’s tests to fail. This happens often because many other classes change when we change one class, leading to many other tests changing / breaking. It is always best to mock all other classes. That way, other classes are not actually used in the test, and you can ensure that your tests do not break! This also ensures that the only coverage we get is from the test written…

Read More Read More

Tip 1: Always commit as many unrelated features and bug fixes as possible into a single commit.

Tip 1: Always commit as many unrelated features and bug fixes as possible into a single commit.

Comments 0 Comment

First, this will make your commit message a cryptic mishmash, which no sane person will understand! Second, when someone needs to cherry-pick something from one branch onto another, they’ll be unable to do so cleanly. If you are linking your commits with JIRA, this is even more awesome because now the unrelated JIRA stories are also linked together by this commit! And if your team uses JIRA or commit messages to write release notes, oh well, they are in for…

Read More Read More