summaryrefslogtreecommitdiff
path: root/technical/reviews/talks.md
diff options
context:
space:
mode:
Diffstat (limited to 'technical/reviews/talks.md')
-rw-r--r--technical/reviews/talks.md81
1 files changed, 0 insertions, 81 deletions
diff --git a/technical/reviews/talks.md b/technical/reviews/talks.md
deleted file mode 100644
index ed272c8..0000000
--- a/technical/reviews/talks.md
+++ /dev/null
@@ -1,81 +0,0 @@
-# Sandi Metz - Nothing is Something
-
-:::: tags
-- OOP
-- Ruby
-::::
-
-Some insightful thoughts on OOP.
-
-Clever examples of message-passing to get rid of conditionals.
-
-Prefer composition with dependency injection to inheritance:
-inheriting to override a method really means that the parent class had
-a default "null" behaviour that can be injected explicitly.
-
-Name the role, make an interface for it, and make classes that
-implement each behaviour (the null one and the specialiazed one).
-This will make it easier to compose specializations (i.e. save you
-from multiple inheritance).
-
-
-# Sandi Metz - Rules
-
-:::: tags
-- OOP
-- Ruby
-::::
-
-Some theory-crafting on rule-following, then the actual rules, which
-amount to
-
-- small classes,
-- tiny methods,
-- few parameters.
-
-At the 16-minute mark, an interesting interaction between Metz and a
-programmer starting to apply these rules: the programmer wonders when
-they will be able to understand the new application "the same way"
-they understood the old one. I.e. will they ever reach a point where
-they have a complete mental map of every interaction between every
-object, the same way they used to have a complete mental map of the
-old monolithic, sequential application?
-
-Metz's response is that nope, this will never happen; they will "cease
-to care" instead. In exchange, they will be able to make localized
-changes without worrying about breaking the whole application.
-
-
-# Fred George - The Secret Assumption of Agile
-
-:::: tags
-- Agile
-- OOP
-- programming methods
-- project management
-- training
-::::
-
-Advice on when to refactor:
-
-- *after* design, *before* writing unit tests for the new stuff:
- prepare ground for the addition to fit right in;
-
-- *after* implementing the new behaviour, *before* integrating.
-
-Goes over the usual code smells taught during the training he gives
-(conditionals, getters & setters, class names ala "Manager", too many
-instance variables)
-
-Mentions a requirement for training "retention": skills must be
-applied within a month after receiving the training, otherwise the
-rationale will be lost.
-
-Questions:
-
-- Does he know of open-source projects that showcase this style of
- programming?
- - Smalltalk, some NodeJS libraries
-
-- Does he rely on naming conventions?
- - Quite a lot.