Skip to content

Instantly share code, notes, and snippets.


Pietro Di Bello xpepper

Block or report user

Report or block xpepper

Hide content and notifications from this user.

Learn more about blocking users

Contact Support about this user’s behavior.

Learn more about reporting abuse

Report abuse
View GitHub Profile

A class plays two roles in an OO program:

  • It provides a container for behavior that's shared by many objects.
  • It acts as an object factory, manufacturing new instances and ensuring they are initialized correctly.

...when I say encapsulation, I mean "the behavior of an object can only be affected through its API". Or to put it negatively, an object is not well encapsulated when its behavior can be affected without calling its API. Or another way to think about it is that a well encapsulated object draws a solid boundry or wall around itself, and ensures that all the code that changes its behavior is contained within the object itself.

From Growing Object-Oriented Software, Guided by Tests

Encapsulation and Information Hiding

We want to be careful with the distinction between “encapsulation” and “information hiding.” The terms are often used interchangeably but actually refer to two separate, and largely orthogonal, qualities:


Ensures that the behavior of an object can only be affected through its API. It lets us control how much a change to one object will impact other parts of the system by ensuring that there a

xpepper / Ssh tunneling and shared screen
Last active Apr 25, 2019
Ssh tunneling and shared screen session
View Ssh tunneling and shared screen

SSH reverse tunneling

In the following page will be explained the procedure to share a bash screen session in order to do remote peer programming. Example :

Person A : @work : Office Milan, behind a NAT

Person B : @home : in Paris, behind a NAT

xpepper / when to use
Last active Apr 25, 2019 — forked from practicingruby/
Gregory Brown's view on "when to use TDD"
View when to use

There's no general rule you can follow here, because it's always going to depend on context. In my experience the kind of feedback loops you create, and the kind of safety nets you need are defined entirely by the domain, the organization, and the team culture.

Here are a few examples:

  1. I do a bit of work for a medium-sized dental clinic. The business manager there is really fun to work with, but has the tendency of changing his mind six times before he settles his ideas. So when he asks for a report, I don't put any effort at all into writing tests or worrying about minor bugs even, because my only goal is to flesh out in code something vaguely resembling what he asked for.

Often times, this means doing a handful of 30 minute prototypes until the requirements settle, each of which would have taken me 2 hours if I drove them via TDD. When things finally cool down, I evaluate the complexity and maintainability of the resulting code and either leave it untested, add some acceptance tests, backfill unit tes

xpepper / CleanCode episode 2 on
Last active Apr 25, 2019 — forked from xplayer/
CleanCode episode 2 on names
View CleanCode episode 2 on


The name that you use should reveal your intent

  • comments are a smell of a badly chosen name!
  • Only choose names that communicate your intent

Use pronounceable names

xpepper / CleanCode episode 3 on
Last active Apr 25, 2019 — forked from xplayer/
CleanCode episode 3 on functions
View CleanCode episode 3 on


Functions should be small

Four to six lines long

  • "A long function is where the classes go to hide"

Functions should do only one thing

xpepper /
Created Jul 15, 2014
A quote on "styling" by Kent Beck's "Smalltalk Best Practice Patterns"

"There are a few things I look for that are good predictors of whether a project is in good shape. These are also properties I strive for in my own code.

  • Once and only once - If I only have one minute to describe good style, I reduce it to a simple rule: In a program written with good style, everything is said once and only once. This isn't much help in creating good code, but it's a darned good analytic tool. If I see several methods with the same logic, several objects with the same methods, or several systems with similar objects, I know this rule
xpepper /
Last active Apr 25, 2019
Velocity: good and bad



Pressuring people to work harder, work longer hours, and take on an increased workload is not the way to increase velocity. It’s the way to start a death march. [...]

The way to reveal extra capacity and increase velocity is to relentlessly remove obstacles, eliminate waste and improve continuously. Help the team focus on the product, on quality, and to deliver only the functionality that adds value to the product and generates revenue. Keep the process simple and intuitive so that people don’t have to stop and think what the next step is. And protect peoples’ flow time by preventing interruptions. Help the team avoid creating inventory, i.e. functionality that is complete but cannot generate revenue because it is not deployed to the production environment. Quickly remove obstacles that are identified in the daily standups and minimize dependencies so the team doesn’t have to

xpepper /
Last active Apr 25, 2019
Velocity as a productivity metric

Under what conditions (if at all) can Velocity be used as a productivity metric? and if if not, why not?

The "why not" is that velocity should be a tool used to get better at estimation and planning.

So some of the larger swings you see in a teams velocity - especially in a team new to agile - are due to them tweaking the various dials that help them get better at planning an estimating - for example:

xpepper / Single Responsibility
Last active Apr 25, 2019
Uncle Bob on the Single Responsibility Principle
View Single Responsibility

(from SOLID Principles with Uncle Bob - Robert C. Martin -

Single Responsibility Principle, what does it mean? It means that a software module should have one reason to change, then that's what I call a responsibility, a reason to change.

So for example, take a payroll application, if there's an employee class in that payroll application, you could imagine that it might have methods for calculate pay or perhaps another method for print a report, perhaps another method in the employee object for save me to the database, and what's unfortunate about these three methods existing in the same class is that they have all three completely different reasons to change. The payroll, the calculate pay will change if the accountants decides on a new way of calculating pay. The report generator will change if the people who consume the reports want the format of the reports to change. The save function will change if the DBA's decid

You can’t perform that action at this time.