coreyhaines/Super Awesome Fun Coding Workshop, Great Job

## Super Awesome Fun Coding Workshop, Great Job
Idea based on this tweet exchange:
coreyhaines: Architecture where ever class is its own gem, communicating via drb. #thoughtleadering #thoughtlendering
coreyhaines: better yet, every method is its won gem, classes are built up by requiring gems that monkey-patch. #truth
josh_cheek: @coreyhaines As each method is a gem, it needs its a namespace, so it's defined in a module… Compose classes by including method's modules.
coreyhaines: @josh_cheek I do like the idea of composing via module inclusions, as well. Interesting.
coreyhaines: Seriously, though, the idea of defining classes via including single-method modules appeals to me.

So, here's my thought for the workshop. It is based a bit on some of the value that I saw doing coderetreats.

title: Super Awesome Happy Fun Coding Workshop, Great Job
programming language used: Ruby
format: This is an all-day workshop.
The workshop consists of two sections, a morning and an afternoon, separated by a lunch.
During each section, participants will pair up and work for 2.5 hours on a given, ruby-based console application. The problem will be easily understandable, although potentially difficult to "finish" in the time allotted.
At the end of each session, each team of two will have 5-10 minutes to do a walk-through of their solution.
The heart of the challenge (and the super fun) comes from the unique constraints placed on the design.
Constraints:
Every method can have AT MOST 3 lines of code (this might be relaxed, as I do more experimentation);
A given class can have AT MOST one method defined (instance method, excluding initializer, which can only be used to set up instance variables based on passed in parameters);
A given class can include as many modules as desired;
A given module can have AT MOST one method;
Module methods may not rely on instance variables.
(and perhaps a couple other I'm mulling over, maybe no if statements most likely definitely no looping constructs)

Code should be written to emphasize readability.

The idea, as in coderetreat, is to push certain practices to the extreme and see what happens. This has the potential to degrade into a more function-composition-style solution, and I'm interested to see what happens.
	Idea based on this tweet exchange:
	coreyhaines: Architecture where ever class is its own gem, communicating via drb. #thoughtleadering #thoughtlendering
	coreyhaines: better yet, every method is its won gem, classes are built up by requiring gems that monkey-patch. #truth
	josh_cheek: @coreyhaines As each method is a gem, it needs its a namespace, so it's defined in a module… Compose classes by including method's modules.
	coreyhaines: @josh_cheek I do like the idea of composing via module inclusions, as well. Interesting.
	coreyhaines: Seriously, though, the idea of defining classes via including single-method modules appeals to me.

	So, here's my thought for the workshop. It is based a bit on some of the value that I saw doing coderetreats.

	title: Super Awesome Happy Fun Coding Workshop, Great Job
	programming language used: Ruby
	format: This is an all-day workshop.
	The workshop consists of two sections, a morning and an afternoon, separated by a lunch.
	During each section, participants will pair up and work for 2.5 hours on a given, ruby-based console application. The problem will be easily understandable, although potentially difficult to "finish" in the time allotted.
	At the end of each session, each team of two will have 5-10 minutes to do a walk-through of their solution.
	The heart of the challenge (and the super fun) comes from the unique constraints placed on the design.
	Constraints:
	Every method can have AT MOST 3 lines of code (this might be relaxed, as I do more experimentation);
	A given class can have AT MOST one method defined (instance method, excluding initializer, which can only be used to set up instance variables based on passed in parameters);
	A given class can include as many modules as desired;
	A given module can have AT MOST one method;
	Module methods may not rely on instance variables.
	(and perhaps a couple other I'm mulling over, maybe no if statements most likely definitely no looping constructs)

	Code should be written to emphasize readability.

	The idea, as in coderetreat, is to push certain practices to the extreme and see what happens. This has the potential to degrade into a more function-composition-style solution, and I'm interested to see what happens.