Hussein Morsy HusseinMorsy

Architecture in Elm

This document is a collection of concepts and strategies to make large Elm projects modular and extensible.

We will start by thinking about the structure of signals in our program. Broadly speaking, your application state should live in one big foldp. You will probably merge a bunch of input signals into a single stream of updates. This sounds a bit crazy at first, but it is in the same ballpark as Om or Facebook's Flux. There are a couple major benefits to having a centralized home for your application state:

There is a single source of truth. Traditional approaches force you to write a decent amount of custom and error prone code to synchronize state between many different stateful components. (The state of this widget needs to be synced with the application state, which needs to be synced with some other widget, etc.) By placing all of your state in one location, you eliminate an entire class of bugs in which two components get into inconsistent states. We also think yo

The introduction to Reactive Programming you've been missing

(by @andrestaltz)

This tutorial as a series of videos

If you prefer to watch video tutorials with live-coding, then check out this series I recorded with the same contents as in this article: Egghead.io - Introduction to Reactive Programming.

Chapter 1 - Object Oriented Design

The purpose of design is to allow you to do design later, and it's primary goal is to reduce the cost of change.

SOLID Design:

Single Responsibility Principle: a class should have only a single responsibility
Open-Closed Principle: Software entities should be open for extension, but closed for modification (inherit instead of modifying existing classes).
Liskov Substitution: Objects in a program should be replaceable with instances of their subtypes without altering the correctness of that program.
Interface Segregation: Many client-specific interfaces are better than one general-purpose interface.

Jim Weirich:

This is how I explain it… Ruby has Procs and Lambdas. Procs are created with Proc.new { }, lambdas are created with lambda {} and ->() {}.

In Ruby 1.8, proc {} creates lambda, and Ruby 1.9 it creates procs (don't ask).

Lambdas use method semantics when handling parameters, procs use assignment semantics when handling parameters.

This means lambdas, like methods, will raise an ArgumentError when called with fewer arguments than they were defined with. Procs will simply assign nil to variables for arguments that were not passed in.

tmux shortcuts & cheatsheet

start new:

tmux

start new with session name:

tmux new -s myname

tmux cheat sheet

(C-x means ctrl+x, M-x means alt+x)

Prefix key

The default prefix is C-b. If you (or your muscle memory) prefer C-a, you need to add this to ~/.tmux.conf:

remap prefix to Control + a

	# MODEL

	class Case < ActiveRecord::Base
	include Eventable

	has_many :tasks

	concerning :Assignment do
	def assign_to(new_owner:, details:)
	transaction do

	There is another way to create a catch-all address that will work for secondary domains. The steps are these:

	1- Log into google.com/a/domain.com.
	2- Click on the 'Google Apps' icon.
	3- Click on 'Gmail.'
	4- Click on 'Advanced settings.'
	5- You will see different tabs, click on 'Default routing.'
	6- Click on 'Add setting.'
	7- On the new window under step 1 select 'Pattern match.'
	8- Under 'Regexp' type in '[email protected]'

	require "money"

	class Decorator < BasicObject
	undef_method :==

	def initialize(component)
	@component = component
	end

	def method_missing(name, *args, &block)

	#Count the lines of Ruby code in your app
	find . -iname "*.rb" -type f -exec cat {} \; \| wc -l