tanvirstreame

class User {
    constructor() {
        if (!User.users) {
            User.users = new Map();
        }
    }

    static registerUser(userId, userName) {
        if (!User.users.has(userId)) {
            const newUser = { userId, userName };

tanvirstreame

class User {
    constructor(userId, userName) {
        this.userId = userId;
        this.userName = userName;
    }
}

class Post {
    constructor(userId, posts) {
        this.userId = userId;

tanvirstreame

class User {
    constructor(userId, fullName, phone, age) {
        this.userId = userId;
        this.fullName = fullName;
        this.phone = phone;
        this.age = age;
    }
}

class Follow {

tanvirstreame

class User {
    constructor() {
        this.users = new Map();
    }

    registerUser(userId, fullName, phone, age) {
        if (!this.users.has(userId)) {
            const newUser = { userId, fullName, phone, age };
            this.users.set(userId, newUser);
            return newUser;

tanvirstreame

class User {
    registerUser(userId, userName) {
        this.userId = userId;
        this.userName = userName;
        return "User Created";
    }

    get() {
        return {
            userId: this.userId,

tanvirstreame

class User {
    constructor(userId, userName) {
        this.userId = userId;
        this.userName = userName;
    }
}

class Post {
    constructor(userId, posts) {
        this.userId = userId;

tanvirstreame

Definitely not comprehensive. This is meant to be a basic memory aid with links to get more details. I'll add to it over time.

Install

$ npm install mongoose --save

Connect

const mongoose = require('mongoose');

tanvirstreame

const arr = [4,2,1,3];

class Node {
	constructor(value) {
		this.value = value;
		this.next = null;

	}
}

tanvirstreame

Some helpful guidelines for pull requests and code reviews

It's been often said that programming is part art, part science - that because lots of times there's no single, simple solution to a problem; or if there is, we might not know about it. There's also an infamous joke that if there are n developers in the room, then there are n+1 opinions on how things should be done. That being said, here are some guidelines that should prevent friction when submitting or reviewing code.

The most important thing

The code has to work. Unless you open a PR as a work in progress, the code should be built and tested on a device or emulator.

If you have touched the gradle build files and changed build setup, it's useful to test the whole build from scratch (clean build) and all of the types and flavours. If you have touched payments (logic or UI), you should test that it still works correctly, both in test and production builds. If you updated external libraries, test the pertaining features (e.g. if you

tanvirstreame

Some helpful guidelines for pull requests and code reviews

It's been often said that programming is part art, part science - that because lots of times there's no single, simple solution to a problem; or if there is, we might not know about it. There's also an infamous joke that if there are n developers in the room, then there are n+1 opinions on how things should be done. That being said, here are some guidelines that should prevent friction when submitting or reviewing code.

The most important thing

The code has to work. Unless you open a PR as a work in progress, the code should be built and tested on a device or emulator.

If you have touched the gradle build files and changed build setup, it's useful to test the whole build from scratch (clean build) and all of the types and flavours. If you have touched payments (logic or UI), you should test that it still works correctly, both in test and production builds. If you updated external libraries, test the pertaining features (e.g. if you