Pietro Di Bello xpepper

Internet Scale Services Checklist

A checklist for designing and developing internet scale services, inspired by James Hamilton's 2007 paper "On Desgining and Deploying Internet-Scale Services."

http://mvdirona.com/jrh/talksandpapers/jamesrh_lisa.pdf

Basic tenets

Does the design expect failures to happen regularly and handle them gracefully?
Have we kept things as simple as possible?

Clean Code ITA

Nomi

Tutte le variabili, costanti, funzioni, classi etc devono avere un nome significativo. Se il nome ha bisogno di un commento per essere spiegato non è abbastanza significativo.
Sono da evitare nomi che possano sviare dal vero significato della variabile

Continuous Integration - Know your opportunities

Continuous Integration in a nutshell

Continuous Integration (CI) is an important practice every team should adopt in order to detect defects and errors early and solve integration problems easily. Roughly speaking we may say that CI is a practice that allows the growth of solid software by giving greater confidence to the developers and better products to the final customers.

The concept behind CI is fairly simple: the codebase is owned by several developers that continuously integrate their changes to a common version control system. For each integration the system runs a predefined set of tasks automatically; these tasks may vary from running all the tests to building all the components.

Description

This simple script will take a picture of a whiteboard and use parts of the ImageMagick library with sane defaults to clean it up tremendously.

The script is here:

#!/bin/bash
convert "$1" -morphology Convolve DoG:15,100,0 -negate -normalize -blur 0x1 -channel RBG -level 60%,91%,0.1 "$2"

Results

Locate the section for your github remote in the .git/config file. It looks like this:

[remote "origin"]
	fetch = +refs/heads/*:refs/remotes/origin/*
	url = [email protected]:joyent/node.git

Now add the line fetch = +refs/pull/*/head:refs/remotes/origin/pr/* to this section. Obviously, change the github url to match your project's URL. It ends up looking like this:

Your class can be no longer than 100 lines of code.
Your methods can be no longer than five lines of code.
You can pass no more than four parameters and you can’t just make it one big hash.
When a call comes into your Rails controller, you can only instantiate one object to do whatever it is that needs to be done. And your view can only know about one instance variable.

You can break these rules if you can talk your pair into agreeing with you.

Locate the section for your github remote in the .git/config file. It looks like this:

[remote "origin"]
	fetch = +refs/heads/*:refs/remotes/origin/*
	url = [email protected]:joyent/node.git

Now add the line fetch = +refs/pull/*/head:refs/remotes/origin/pr/* to this section. Obviously, change the github url to match your project's URL. It ends up looking like this:

	# MODEL

	class Case < ActiveRecord::Base
	include Eventable

	has_many :tasks

	concerning :Assignment do
	def assign_to(new_owner:, details:)
	transaction do

	# check if job exists
	curl -XGET 'http://jenkins/checkJobName?value=yourJobFolderName' --user user.name:YourAPIToken

	# with folder plugin
	curl -s -XPOST 'http://jenkins/job/FolderName/createItem?name=yourJobName' --data-binary @config.xml -H "Content-Type:text/xml" --user user.name:YourAPIToken

	# without folder plugin
	curl -s -XPOST 'http://jenkins/createItem?name=yourJobName' --data-binary @config.xml -H "Content-Type:text/xml" --user user.name:YourAPIToken

	# create folder

	class FizzBuzz

	CONFIG = { 3 => "Fizz", 5 => "Buzz", 7 => "Bar" }

	attr_reader :number
	attr_accessor :string

	def initialize number
	@number = number
	@string = ""