Skip to content

Instantly share code, notes, and snippets.

View kanishk30's full-sized avatar
🏠
Working from home

Kanishk Agrawal kanishk30

🏠
Working from home
View GitHub Profile
@kanishk30
kanishk30 / open-apis.md
Last active March 4, 2024 01:36
Open apis
@kanishk30
kanishk30 / steps.js
Created October 11, 2020 07:55
beejek - steps
export const DATATYPES = {
HEADING: "HEADING",
DEFAULT: "DEFAULT"
};
export const integrationStepsData = {
data: [
{
value: "Step 1: Onboarding",
type: "HEADING",
list: []
@kanishk30
kanishk30 / clean_code.md
Created November 26, 2020 19:04 — forked from wojteklu/clean_code.md
Summary of 'Clean code' by Robert C. Martin

Code is clean if it can be understood easily – by everyone on the team. Clean code can be read and enhanced by a developer other than its original author. With understandability comes readability, changeability, extensibility and maintainability.


General rules

  1. Follow standard conventions.
  2. Keep it simple stupid. Simpler is always better. Reduce complexity as much as possible.
  3. Boy scout rule. Leave the campground cleaner than you found it.
  4. Always find root cause. Always look for the root cause of a problem.

Design rules

@kanishk30
kanishk30 / feature-flags.md
Created December 16, 2020 15:55 — forked from threepointone/feature-flags.md
Feature flags: why, how, all that

(I'm enjoying doing these raw, barely edited writeups; I hope they're useful to you too)

Feature flags

This is my own writeup on feature flags; for a deep dive I'd recommend something like Martin Fowler's article (https://martinfowler.com/articles/feature-toggles.html).

So. Feature flags. The basic idea that you'll store configuration/values on a database/service somewhere, and by changing those values, you can change the user experience/features for a user on the fly.

Let's say that you're building a new feature, called 'new-button' which changes the color of buttons, which is currently red, to blue. Then you'd change code that looks like this -