Eternal Sunshine of the Spotless Mind (2004)

Introduction: A couple undergo a procedure to erase each other from their memories when their relationship turns sour, but it is only through the process of loss that they discover what they had to begin with.

watched Eternal Sunshine of the Spotless Mind, highly recommended. My review: Love is a mix of romance and desperateness. It is something you don’t want to lose, but do try to erase when possessing it.

“How happy is the blameless vestal’s lot

The world forgetting, by the world forgot

Eternal sunshine of the spotless mind

Each prayer accepted and each wish resigned.”

—-Alexander Pope

American beers

Cream Ale
A cream ale is related to pale lager. They are generally brewed to be light and refreshing with a straw to pale golden color. Hop and malt flavor is usually subdued but like all beer styles it is open to individual interpretation, so some breweries give them a more assertive character. Notable examples: Genesee Cream Ale (made by Genesee Brewing Company of Rochester, NY), and Schoenling Little Kings (brewed by Schoenling Brewing Company of Cincinnati, OH).

Stout is a dark beer made using roasted malt or roasted barley, hops, water and yeast. Stouts were traditionally the generic term for the strongest or stoutest porters, typically 7% or 8%, produced by a brewery.[1][2] In this sense a stout is not necessarily dark in colour because there were also pale stouts.[3] There are a number of variations including Baltic porter, dry stout and imperial stout. The name porter was first used in 1721 to describe a dark brown beer popular with street and river porters of London that had been made with roasted malts. This same beer later also became known as stout though the word stout had been used as early as 1677.[4] The history and development of stout and porter are intertwined.

object reference in ruby

you pass the value of the variable in to the method, however the value of the
variable is _always_ a reference to an object.

In order to get a object that won’t change out from under you, you need to dup or clone the object you’re passed, thus giving an object that nobody else has a reference to.

=> []
>> a=b
=> []
>> b< <1
>> a
=> [1]

Find What Is Varying and Encapsulate It

Containing variation in data versus containing variation in behavior

Suppose I am working on a project that models different characteristics of animals. My requirements are the following:

Each type of animal can have a different number of legs.

Animal objects must be able to remember and retrieve this information.

Each type of animal can have a different type of movement.

Animal objects must be able to return how long it will take to move from one place to another given a specified type of terrain.

A typical approach of handling the variation in the number of legs would be to have a data member containing this value and having methods to set and get it. However, one typically takes a different approach to handling variation in behavior.

Suppose there are two different methods for moving: walking and flying. These requirements need two different pieces of code: one to handle walking and one to handle flying; a simple variable won’t work. Given that I have two different methods, I seem to be faced with a choice of approach:

Having a data member that tells me what type of movement my object has.

Having two different types of Animals (both derived from the base Animal class)—one for walking and one for flying.

Unfortunately, both of these approaches have problems:

Tight coupling—The first approach (using a flag with presumably a switch based on it) may lead to tight coupling if the flag starts implying other differences. In any event, the code will likely be rather messy.

Too many details—The second approach requires that I also manage the subtype of Animal. And I cannot handle Animals that can both walk and fly.

Handling variation in behavior with objects

A third possibility exists: have the Animal class contain an object that has the appropriate movement behavior.

delagation pattern

Advantage: easy to compose behavior, and easy to change what to be composed.

Disadvantage: harder to understand and inefficient

In software engineering, the delegation pattern is a design pattern in object-oriented programming where an object, instead of performing one of its stated tasks, delegates that task to an associated helper object. There is an Inversion of Responsibility in which a helper object, known as a delegate, is given the responsibility to execute a task for the delegator.

In this Java example, the Printer class has a print method. This print method, rather than performing the print itself, delegates to class RealPrinter. To the outside world it appears that the Printer class is doing the print, but the RealPrinter class is the one actually doing the work.

Delegation is simply passing a duty off to someone/something else. Here is a simple example:

 class RealPrinter { // the "delegate"
     void print() { 

 class Printer { // the "delegator"
     RealPrinter p = new RealPrinter(); // create the delegate 
     void print() { 
       p.print(); // delegation

 public class Main {
     // to the outside world it looks like Printer actually prints.
     public static void main(String[] args) {
         Printer printer = new Printer();

why interfaces (pure virtual functions) exist?

their use as a language construct by thinking of them as means of classifying common traits or behaviors that were exhibited by potentially many non-related classes of objects.

For example — say you have a SIM game and have the following classes:

class HouseFly inherits Insect {
void FlyAroundYourHead();
void LandOnThings();

class Telemarketer inherits Person {
void CallDuringDinner();
void ContinueTalkingWhenYouSayNo();

Clearly, these two objects have nothing in common in terms of direct inheritance. But, you could say they are both annoying.

Let’s say our game needs to have some sort of random thing that annoys the game player when they eat dinner. This could be a HouseFly or a Telemarketer or both — but how do you allow for both with a single function? And how do you ask each different type of object to “do their annoying thing” in the same way?

The key to realize is that both a Telemarketer and HouseFly share a common loosely interpreted behavior even though they are nothing alike in terms of modeling them. So, let’s make an interface that both can implement:

interface IPest {
void BeAnnoying();

class HouseFly inherits Insect implements IPest {
void FlyAroundYourHead();
void LandOnThings();

void BeAnnoying() {

class Telemarketer inherits Person implements IPest {
void CallDuringDinner();
void ContinueTalkingWhenYouSayNo();

void BeAnnoying() {

We now have two classes that can each be annoying in their own way. And they do not need to derive from the same base class and share common inherent characteristics — they simply need to satisfy the contract of IPest — that contract is simple. You just have to BeAnnoying. In this regard, we can model the following:

class DiningRoom {

DiningRoom(Person[] diningPeople, IPest[] pests) { … }

void ServeDinner() {
when diningPeople are eating,

foreach pest in pests

Here we have a dining room that accepts a number of diners and a number of pests — note the use of the interface. This means that in our little world, a memeber of the pests array could actually be a Telemarketer object or a HouseFly object.

The ServeDinner method is called when dinner is served and our people in the dining room are supposed to eat. In our little game, that’s when our pests do their work — each pest is instructed to be annoying by way of the IPest interface. In this way, we can easily have both Telemarketers and HouseFlys be annoying in each of their own ways — we care only that we have something in the DiningRoom object that is a pest, we don’t really care what it is and they could have nothing in common with other.