Skip to content

Instantly share code, notes, and snippets.

View xpepper's full-sized avatar
💭
😏

Pietro Di Bello xpepper

💭
😏
View GitHub Profile
@Vashy
Vashy / Java8Pills.md
Last active March 4, 2021 16:25
Java 8 pills

Java 8 Pills

Example class

@Value // Lombok annotation.
// Generates all private final fields, an all-args-constructor,
// getters (no setters), toString(), etc...
class User {
interface GameRulesOutputBoundary
void moveSouthSucceed()
end
interface GameRulesInputBoundary
void parse(message)
end
class GameRules implements GameRulesInputBoundary
def init(GameRulesOutputBoundary outputBoundary)
@sleepyfox
sleepyfox / 2021-10-06-continuous-retrospectives.md
Last active October 18, 2021 17:11
Continuous retrospectives
author: @sleepyfox
title: Continuous retrospectives
date: 6 October 2021
preamble: How MMO/esports practices for continuous improvement can be used for software teams 

Continuous retrospectives

Failure in software teams

interface GameRulesInputBoundary
void moveSouth()
end
interface GameRulesOutputBoundary
void moveSouthSucceed()
end
class GameRules implements GameRulesInputBoundary
def init(GameRulesOutputBoundary outputBoundary)
@xpepper
xpepper / CI Alternatives.md
Last active April 17, 2022 12:41
CI, alternative a confronto :-)

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.

@henrik
henrik / rules.md
Last active May 23, 2022 12:31
Sandi Metz' four rules from Ruby Rogues episode 87. Listen or read the transcript: http://rubyrogues.com/087-rr-book-clubpractical-object-oriented-design-in-ruby-with-sandi-metz/
  1. Your class can be no longer than 100 lines of code.
  2. Your methods can be no longer than five lines of code.
  3. You can pass no more than four parameters and you can’t just make it one big hash.
  4. 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.

@xpepper
xpepper / whiteboardClean.sh
Created June 3, 2015 14:17
whiteboard effect
#!/bin/bash
convert "$1" -morphology Convolve DoG:15,100,0 -negate -normalize -blur 0x1 -channel RBG -level 60%,91%,0.1 "$2"%
# MODEL
class Case < ActiveRecord::Base
include Eventable
has_many :tasks
concerning :Assignment do
def assign_to(new_owner:, details:)
transaction do
@ValentinaServile
ValentinaServile / CleanCode-it.md
Last active May 2, 2023 14:00
Appunti sui principi del Clean Code

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