rahulrajaram

/*
TL;DR: Compile the program as follows:
------
  
      g++ add.cpp -O2 && ./a.out


RIGOROUS DISCUSSION:
--------------------
Suppose you want to compute the sum of the series:

rahulrajaram

import random
import string

# The pool of characters to pick the characters for your password from
password_char_set = string.ascii_letters + string.digits + string.punctuation

def random_character():
    return password_char_set[random.randint(0, len(password_char_set))]

rahulrajaram

COLOR_MAP = { 
    'black': '30',
    'red': '31',
    'green': '32',
    'yellow': '33',
    'blue': '34',
    'magenta': '35',
    'cyan': '36',
    'white': '37',
}

rahulrajaram

lambda_1 = -> { puts 'From lambda_1: Hello, World!' }
lambda_2 = -> { puts 'From lambda_2: Hello, World!' }

proc_1 = Proc.new { puts 'From proc_1: Hello, World!' }
proc_2 = Proc.new { puts 'From proc_2: Hello, World!' }

def proc_or_lambda_called(
	proc_or_lamdba_1,
 	proc_or_lamdba_2
)

rahulrajaram

Ruby: Different ways to define methods in

The Ruby Object Model

One of the central aspects of  the Ruby programming language is the Ruby object model, as per which everything (but for constructs such as methods, and keywords) in Ruby -- ​​classes, instances, lambdas, procs, strings, numbers, decimals, hashmaps -- is an object. This renders a kind of uniformity to Ruby that few other languages offer.

At the very same time, the object model can also become confusing. In particular, the following two questions can sometimes become difficult to answer, but being able to readily answer which can set you apart as a Ruby programmer.

1. What is self in a given context?
2. If I define a method here, where will it go? That is, which object is it going to be defined on?

rahulrajaram

import traceback


def print_stack_trace():
    try:
        raise Exception
    except Exception:
        with open('~/.my_important_stack_trace', 'w') as file:
            file.write('{}'.format(repr(traceback.format_stack())))

rahulrajaram

#include <string.h>
#include <stdio.h>

/*
 * Macro function that initializes a struct object
 * and returns it.
 *
 * For this to work, a `{type}Init` function must
 * be defined.
 */

rahulrajaram

/*
 * File invokes s3#listObjects recursively to retrieve all objects
 */
const AWS = require('aws-sdk')
const s3 = new AWS.S3();

let args = {
    'Bucket': ADD_BUCKET_NAME_HERE,
    'Prefix': ADD_PATH_PREFIX_HERE_OR_REMOVE_THIS_ATTRIBUTE
};

rahulrajaram

"""
Script implements:

    tail FILE_NAME NUMBER_OF_LINES_TO_TAIL
"""
import sys

def seek_eof(file):
    file.seek(0, 2)

rahulrajaram

There are situations where squashing commits is not favourable and is an anti-pattern.

Squashing is necessary when a series of commits represents an atomic unit of work, where an atomic unit of work is any work which if broken into two or more independent commits would render either or both of them functionally incomplete. as an extreme example, changing a single global variable name across two commits would likely break the first commit and so the two commits should be squashed. They should also be squashed because the two commits are thematically one (although thematic unity can be relative), but I view this as a less important reason. At any point, one should be able to go back to a given commit on master and ensure all tests pass.

Squashing should be avoided in situations where each commit in a given series is atomic, even if the commits deliver a feature in combination (unless, as alluded to above, some commits break the codebase in isolation). Incremental commits often represent the logical sequence o