Updates

Author: eoinkelly

book-design-patterns-elements-of-reusable-oo-software.md

@@ -0,0 +1,117 @@
+# Design patterns
+
+* there are 23 patterns in the book
+* the patterns include solutions which have developed or evolved over time
+    * => they are not designs people initially tend to generate
+    * they are solutions people have evolved into
+    * ASIDE: it is no surprise that they often feel like "overkill" given this history
+* the patterns represent "common ways that objects can collobarate"
+* the goal of the patterns is to make your code more **reusable**
+    * => my guess is that design pattern knowledge is most applicable during
+      the "refactor" phase where you have a solution and are now trying to find a
+      code arrangement to make that solution optimal.
+* design patterns are a bunch of solutions with known trade-offs
+* the patterns are
+    > a record of experience in designing OO software
+* they are intended to give you a "leg up" when designing software
+* design areas not in the book
+    * concurrency
+    * any application domain specific patterns e.g. web, game, databases
+    * real time programming
+    * UI design
+    * device drivers
+* the patterns in the book are all at a paricular level
+    * not as low-level building blocks like linked-lists, hash tables etc.
+    * not as high-level as an entire DSL for some application area
+    * description of objects and classes designed to solve a general design problem in a particular context
+* code examples are in C++ and Smalltalk
+    * the patterns are influenced by what can be done **easily** in those languages
+        * e.g. if they used C they might have added patterns on "inheritance", "encapsulation",
+
+Pros/cons of the patterns (from my POV)
+
+* ++ if other devs on team are familiar with them then you can communicate architecture very quickly
+* ?? if other devs on team are not familiar with them?
+
+The book has 2 parts
+
+1. Chapters 1 & 2: describe what patterns are, how to use them
+2. Chapters 3 - 5: the catalog of patterns, divided
+    * Purpose (three types)
+        * creational
+            * deals with how objects are created
+            * two subtypes
+                * Class
+                    * defers some part of object creation to subclasses
+                * Object
+                    * defers some part of object creation another object
+        * structual
+            * deals with the composition of classes and objects
+            * two subtypes
+                * Class
+                    * use inheritance to compose classes
+                * Object
+                    * describe ways to assemble objects
+        * behavioral
+            * the way objects interact and distribute responsibility
+            * two subtypes
+                * Class
+                    * use inheritance to describe algorithms and flow of control
+                * Object
+                    * describe how a group of objects can cooperate to perform a task that they could not do individually
+    * Scope
+        * Class
+            * static (fixed at compile time)
+        * Object
+            * dynamic (can be changed at runtime)
+
+Structure of a pattern
+
+* name
+    * allows team to discuss the pattern
+* problem
+    * description of when to use the pattern
+    * sometimes a set of criteria that must be there before you should use it
+* solution
+    * describes a general arrangement of classes that will solve the problem
+    * describes their
+        1. relationships
+        1. responsibilitie
+        1. collaborations
+* consequences
+    * pros/cons of the solution
+    * the trade-offs of the solution
+
+
+Strategy pattern example
+
+* an object that represents an algorithm
+* useful when
+    * the algorithm has complex data structures you awnt to hide
+    * you want to replace the algorithm either statically or dynamically
+    * there are a lot of variants of the algorithm
+
+
+They make an analogy to a playwrites who often re-use stories that have the same structure.
+
+They mention a number of times that the objects in the pattersn are never found
+in the initial stages of design - they emerge when we are trying to make the
+design more flexible or reusable.
+
+Design patterns can be considered "techniques for making my existing design
+more flexible and reusable". They are not "starting points for my design".
+
+
+* Each operation defined by an object has a signature
+    * signature = operation name, the objects argument it takes as arguments and its return type
+* A set of sigatures is an _Interface_.
+* A _Type_ is a name used to denote a particular _Interface_.
+* An object can have many types
+* A type can be implemented by many different objects
+* Interfaces can contain other interfaces as subsets
+    * type C is a _subtype_ of P if the interface of C fully contains the interface of P. type P is the supertype of C
+    * We say that type C "inherits" from type P
+* Objects are known only through their interfaces
+* An interface says nothing about implementation
+
+## Chapter 2: Case study - Lexi

css/howto-full-viewport-height-body.md

@@ -0,0 +1 @@
+

docker/build-a-docker-image.md

@@ -7,34 +7,38 @@
 * The first thing a build process does is send the entire context (recursively) to the daemon.
 * In most cases, it’s best to start with an empty directory as context and keep your Dockerfile in that directory. Add only the files needed for building the Dockerfile.
 
+The Docker daemon runs the instructions in the Dockerfile one-by-one,
+committing the result of each instruction to a new image if necessary, before
+finally outputting the ID of your new image. The Docker daemon will
+automatically clean up the context you sent
 
-The Docker daemon runs the instructions in the Dockerfile one-by-one, committing the result of each instruction to a new image if necessary, before finally outputting the ID of your new image. The Docker daemon will automatically clean up the context you sent
+Note that each instruction is run independently, and causes a new image to be
+created - so `RUN cd /tmp` will not have any effect on the next instructions.
 
-Note that each instruction is run independently, and causes a new image to be created - so RUN cd /tmp will not have any effect on the next instructions.
-
-Whenever possible, Docker will re-use the intermediate images (cache), to accelerate the docker build process significantly.
+Whenever possible, Docker will re-use the intermediate images (cache), to
+accelerate the docker build process significantly.
 
 * This is indicated by the Using cache message in the console output.
-* this also means you have to `apt-get update` and `apt-get install` in the same step or the image from the "update" will be cached and not chanaged when you change the install command
+* GOTCHA: this also means you have to `apt-get update` and `apt-get install` in the same step or the image from the "update" will be cached and not chanaged when you change the install command
 
 ## Steps
 
 ```sh
 docker images --all # see what is already installed
-docker pull ruby:2.3.1-slim
-# the first layer in this already existed so presumably is common to postgres
-# image (which I had already downloaded)
+
+docker pull ruby:2.3.1-slim # optional - the build will pull for you if you need it
 
 # build a new image from a Dockerfile in current working dir
 
 # the docker daemon uses the cwd as the "context" for the build so the docker
 # client will copy the entire cwd contents to the daemon before build i.e. don't
-# build from `/`
+# build from `/`!!!
 docker build -t eoin-ruby-test-1 .
 
 docker history eoin-ruby-test-1       # show layers history
 docker inspect eoin-ruby-test-1 |jq . # JSON dump of image metadata
 
+TODO how to clean up layers form images that didn't build properly
 
 # docker run [OPTIONS] IMAGE [COMMAND] [ARG...]
 docker run -it --name eoins-container eoin-ruby-test-1 bash

docker/cheat-sheet.md

@@ -0,0 +1,2 @@
+
+docker run  -v ~/DockerVolumes/postgres:/var/lib/postgresql/data -p 5432:5432 --name postgres_new2 postgres

docker/docker-compose.md

@@ -0,0 +1,8 @@
+
+
+GOTCHA: depends_on will not wait for db and redis to be “ready” before starting web - only until they have been started
+
+
+docker-compose up
+docker-compose exec --user postgres db psql
+docker-compose run web bundle exec rake db:setup

docker/docker-for-mac.md

@@ -0,0 +1,24 @@
+# Docker for mac
+
+* runs as a native Mac application
+* uses xhyve to virtualize the Docker Engine environment and Linux kernel-specific features for the Docker daemon.
+
+
+Xhyve
+
+https://github.com/mist64/xhyve/
+
+> The xhyve hypervisor is a port of bhyve to OS X. It is built on top of
+> Hypervisor.framework in OS X 10.10 Yosemite and higher, runs entirely in
+> userspace, and has no other dependencies. It can run FreeBSD and vanilla
+> Linux distributions and may gain support for other guest operating systems in
+> the future.
+
+> bhyve is the FreeBSD hypervisor, roughly analogous to KVM + QEMU on Linux. It
+> has a focus on simplicity and being legacy free.
+
+
+At installation time, Docker for Mac provisions an HyperKit VM based on Alpine Linux, running Docker Engine. It exposes the docker API on a socket in /var/tmp/docker.sock. Since this is the default location where docker will look if no environment variables are set, you can start using docker and docker-compose without setting any environment variables
+
+
+You can't route network traffic between containers and the host when you are running "docker for mac"

docker/persistent-data.md

@@ -1,4 +1,14 @@
-Two ways to make data last longer than the container
+# Cheat sheet
+
+```
+docker run -it -v ~/DockerVolumes/play:/play --name test2 debian /bin/bash
+```
+
+Kitematic shows the "in container" path on its container homepage
+
+# Background
+
+Docker has two ways to make data last longer than the container
 
 1. data volume
 2. data volume container
@@ -11,19 +21,48 @@ Two ways to make data last longer than the container
 * data volume persists even if the container is deleted
 * data volume can be shared and re-used between containers
 * use `docker inspect` to see details of the volume
-* you can optionally mount a directory from the host machine into the volume
+* data volumes are NOT the same as mounting a directly from the host machine
+    * you can optionally mount a directory from the host machine into the volume
+* changes to data volumes are made directly (not through unionfs)
+* they persist even if the container is deleted
 
-There is a complication on Mac and Windows because the "docker host" is actually a linux VM.
-* docker mounts `/Users` from the mac into `/Users` on the docker host so you can share dirs from /Users with containers
+* There is a complication on Mac and Windows because the "docker host" is actually a linux VM.
+    * docker mounts `/Users` from the mac into `/Users` on the docker host so you can share dirs from /Users with containers
 > Data volumes provide the best and most predictable
 > performance. This is because they bypass the storage
 > driver and do not incur any of the potential
 > overheads introduced by thin provisioning and
 > copy-on-write. For this reason, you may want to place
 > heavy write workloads on data volumes.
 
-* writing into the container can have perf impacts depending on the storage
-  driver being used by the container
 
+* docker does not automatically delete a volume when you remove a container
+* it will also not "garbage collect" volumes that are no longer referenced by any container
+
+* mounting a host (note: linux is the host, not mac) directory is just a special case of creating a volume. Instead of the volume being in something like `/var/lib/docker/volumes/fac362...80535/_data` it is an existing dir on your linux-host.
+
+Where are volumes stored?
+
+* volumes are stored on the linux-host filesystem (not in the unionfs files that the containers use)
+
+How do I see what volumes are on a docker host?
+
+
+* writing into the container can have perf impacts depending on the storage driver being used by the container
+
+The dockerVM on mac "auto shares" a number of mac filesystem dirs with itself
+
+```
+/Users
+/Volumes
+/tmp
+/private
+```
 
 # Data volume containers
+
+> If you have some persistent data that you want to share between containers,
+> or want to use from non-persistent containers, it’s best to create a named Data
+> Volume Container, and then to mount the data from it.
+
+Create a container which has the job of mounting the data volume (from the linux-host) and making that data available to other containers

elixir/attributes.exs

@@ -35,3 +35,18 @@ end
 
 Foo.show_metadata_constants
 Foo.show_changed_metadata_constants
+
+#################################################
+#################################################
+#################################################
+# chris mccord uses this pattern in his code - why does he assign ?
+
+defmodule Thing do
+	phoenix_path = Application.app_dir(:phoenix, "priv/static/phoenix.js")
+	reload_path  = Application.app_dir(:phoenix_live_reload, "priv/static/phoenix_live_reload.js")
+	@external_resource phoenix_path
+	@external_resource reload_path
+	@phoenix_js File.read!(phoenix_path)
+
+	# ...
+end