vishaltelangre

• Create /etc/logrotate.d/my-crazy-app file with following snippet:

/var/log/my-crazy-app/*.log {
        daily
        size 500M
        missingok
        rotate 10
        compress
 delaycompress

vishaltelangre

(ns storm.starter.clj.word-count-kafka
  (:import ;[backtype.storm StormSubmitter LocalCluster]
            [storm.kafka KafkaConfig  HostPort KafkaSpout SpoutConfig StringScheme])
  (:use [backtype.storm clojure config])
  (:gen-class))

(def ^{:private true}
  host (list "localhost:9092"))

(def ^{:private true

vishaltelangre

• Real-world use case example: https://developers.soundcloud.com/blog/smooth-image-loading-by-upscaling

^ is the XOR operator - given two numbers it "lines up" their places and flips the place only if only one of the two numbers has that place:

// All of these are binary
111 ^ 111 === 000
110 ^ 111 === 001
110 ^ 110 === 000

This means that changed will be a number with only those places set that are set in prev_state or state but not both.

vishaltelangre

Concept

• People talk about two servers: a web server (e.g. Nginx, Apache, etc.) and a app server (e.g. Language specific servers like Unicorn, Node.js, Tomcat, Http-Kit, etc.). There are exceptions where app servers not required at all (as web server itself provides preprocessors for handling), but let's not talk about now.
• Web servers are really fast and supports lot of standard and commonly used MIME-type requests. Concept of serving a file is -- forming and sending a response of bytes of data and labeling it with requested MIME-type by a client (e.g. web browser).
• Every response format (in layman's language, a file) is recognized by it's MIME-type, for e.g. a PNG image file has "image/png" MIME-type. JavaScript file has "text/javascript". HTML responses (or files) has "text/html". Plain text files have "text/plain".
• Modern Browsers supports a lot of standard MIME-types. Images, videos, text files (XML, HTML, SVG, JS), and they better know how to visualize it. Browser also knows unrec

vishaltelangre

upstream http_backend {
  server 127.0.0.1:8080;
  keepalive 32;
}

map $http_upgrade $connection_upgrade {
  default upgrade;
    ''      close;
}

vishaltelangre

Main choices for structuring the data are:

• For "one-to-few", you can use an array of embedded documents
• For "one-to-many?, or on occasions when the "N" side must stand alone, you should use an array of references. You can also use a "parent-reference" in the "N" side if it optimizes your data access pattern.
• For "one-to-squillions", you should use a "parent-reference" in the document storing the "N" side.

Once you've decided on the overall structure of the data, then you can, if you choose, denormalize data across multiple documents, by either denormalizing data from the "One" side into the "N" side, or from the "N" side into the "One" side. You'd do this only for fields that are frequently read, get read much more often than they get updated, and where you don't require strong consistency, since updating a denormalized value is slower, more expensive, and is not atomic.

Reference: http://blog.mongodb.org/post/87200945828/6-rules-of-thumb-for-mongodb-schema-design-part-1

vishaltelangre

class RouteBase
  @@routes = {}

  def self.routes=r
    @@routes = r
  end

  def self.routes
    @@routes
  end

vishaltelangre

package main

import (
	"fmt"
	"net/http"
)

type String string

type Struct struct {

vishaltelangre

require 'thread'

def process(job)
	puts "processing job #{job}\n"
	sleep rand(3)
end

threads = []

for job in 1..10

vishaltelangre

GO ?= go
GOPATH := $(CURDIR)/_vendor:$(GOPATH)

all: build

build:
	$(GO) build
	
	
# reference: http://peter.bourgon.org/go-in-production/