Functional programming languages promise to be easier to test and easier to debug. However, when learning the functional way we often try to translate our current techniques to another language. This is usually not easy and the end result is far from those promises we've heard. Early frustrations might even discourage from further learning. In this talk I will show you two very simple patterns: - Designing code around single data structure - Dealing with impure parts of program like DBs, external services or IO This should give beginners jump start for their first toy projects and further exploration.

1. Functional Design Patterns
Tomasz Kowal

2. Why this talk?

3. Why this talk?
Syntax
Pattern matching
and pin operator
Basic recursion, map,
reduce, tail recursion
Concurrency,
distributed systems

8. Why this talk?
Syntax
Pattern matching
and pin operator
Basic recursion, map,
reduce, tail recursion
Concurrency,
distributed systems

11. Why this talk?
Syntax
Pattern matching
and pin operator
Basic recursion, map,
reduce, tail recursion
How do I build stuff?

12. Questions
Please ask during the talk!

13. 1 + 1

15. Patterns
1. Use single data structure that is your single
source of truth and many small functions
operating on it.
2. Separate pure and impure parts.

16. Pipe operator
two = double(1)
two =
1
|> double()

17. Pipe operator
five = add(2, 3)
five =
2
|> add(3)

18. Pipe operator
one = 1
two = double(one)
four = double(two)
1
|> double()
|> double()

19. Pipe operator
list = [1, 10, 3, 12, 42]

20. Pipe operator
list = [1, 10, 3, 12, 42]
filtered = Enum.filter(
list,
&Integer.is_even/1
)

21. Pipe operator
list = [1, 10, 3, 12, 42]
filtered = Enum.filter(
list,
&Integer.is_even/1
)
sorted = Enum.sort(filtered)

22. Pipe operator
sorted =
list
|> Enum.filter(&Integer.is_even/1)
|> Enum.sort()

23. Pipe operator
sorted =
list
|> Enum.filter(&Integer.is_even/1)
|> Enum.sort()
sorted = Enum.sort(Enum.filter(list,
&Integer.is_even/1))

24. Pipe operator
def sorted_evens(list) do
list
|> Enum.filter(&Integer.is_even/1)
|> Enum.sort()
end

25. Pipe operator
def two_smallest_evens(list) do
list
|> sorted_evens()
|> Enum.take(2)
end
list list list
transform
list list list
transform

26. „Debugging” with IO.inspect
def two_smallest_evens(list) do
list
|> sorted_evens()
|> IO.inspect()
|> Enum.take(2)
end

27. Data validation problem
● Current value:
%User{name: „Tom”, age: 29}
● Things that we want to change:
%{age: 30}
● Is the data valid? If not – why?

28. Ecto.Changeset fields
● valid?
● data
● params
● changes
● errors
● ...

29. Validating with Ecto.Changeset
user
|> cast(params, [:name, :email, :age])
user changeset
cast

30. Validating with Ecto.Changeset
user
|> cast(params, [:name, :email, :age])
|> validate_required([:name, :email])
user changeset changeset
cast validate1

31. Validating with Ecto.Changeset
user
|> cast(params, [:name, :email, :age])
|> validate_required([:name, :email])
|> validate_format(:email, ~r/@/)
user changeset changeset changeset
cast validate1 validate2

32. Custom validator
● Lets say we have an event with start
date and end date.
● We want to make sure that start date is
not after end date.

33. Custom validator
def validate_interval(changeset, start, end)
do
end

34. Custom validator
def validate_interval(changeset, start, end) do
start_date = get_field(changeset, start)
end_date = get_field(changeset, end)
end

35. get_field
● Looks for value in params
● Looks for value in original data

36. Custom validator
def validate_interval(changeset, start, end) do
start_date = get_field(changeset, start)
end_date = get_field(changeset, end)
case Date.compare(start_date, end_date) do
:gt ->
_otherwise ->
end
end

37. Custom validator
def validate_interval(changeset, start, end) do
start_date = get_field(changeset, start)
end_date = get_field(changeset, end)
case Date.compare(start_date, end_date) do
:gt ->
_otherwise -> changeset
end
end

38. Custom validator
def validate_interval(changeset, start, end) do
start_date = get_field(changeset, start)
end_date = get_field(changeset, end)
case Date.compare(start_date, end_date) do
:gt -> add_error(changeset, start, "…")
_otherwise -> changeset
end
end

39. add_error
● appends new error to list of errors
● changes valid? to false
● takes changeset and returns changeset

40. Custom validator
def validate_interval(changeset, start, end) do
start_date = get_field(changeset, start)
end_date = get_field(changeset, end)
case Date.compare(start_date, end_date) do
:gt -> add_error(changeset, start, "…")
_otherwise -> changeset
end
end

41. Composing validators
def validate_address(cs, street, zip) do
cs
|> validate_street(street)
|> validate_zipcode(zip)
end
changeset changeset changeset
validate1
cs cs cs
v1
validate2
v2

42. Inserting to database
case Repo.insert(changeset) do
{:error, changeset} →...
{:ok, model} →...
end

43. Benefits
● Easy to compose: just |> another validator
● Easy to extend with custom validators
● Easy to test: all functions are pure
● Bonus: it works for any data.

44. Immutability digression
● Creating new structure every time is optimized
when language provides immutability
● list = [1, 2, 3]
1 2 3

45. Immutability digression
● Creating new structure every time is optimized
when language provides immutability
● list = [1, 2, 3]
● list2 = [0 | list]
0
1 2 3

46. Immutability digression
● Creating new structure every time is optimized
when language provides immutability
● list = [1, 2, 3]
● list2 = [0 | list]
● list3 = [4 | list]
0
4
1 2 3

47. Using Ecto.Multi
Multi.new
|> Multi.update(:account, a_changeset))
|> Multi.insert(:log, log_changeset))
|> Multi.delete_all(:sessions,
assoc(account, :sessions))
multi |> Repo.transaction

48. Composition
def extend_multi(multi, changeset) do
multi
|> Multi.insert(:some_tag, changeset)
end
multi multi multi
custom
multi multi multi
ins
insert
upd

49. How would you test this?
Repo.update(...)
Repo.insert(...)
Repo.delete_all(...)

50. Unit testing Ecto.Multi
assert [
{:account, {:update, achangeset, []}},
{:log, {:insert, log_changeset, []}},
{:sessions, {:delete_all, query, []}}
] = Ecto.Multi.to_list(multi)

51. Benefits
● Easy to compose: just |> another operation
● Easy to extend with Multi.run
● Easy to test with Multi.to_list

52. Garbage Collection digression
● Erlang GC is run separately for all processes
● When process dies, all its memory is freed
● This means that, if
– you use a process per request in your web
application and
– it has short lifecycle
The garbage collection may never happen!

53. Plug (or what makes Phoenix cool)
1. A specification for composable modules
between web applications
2. Connection adapters for different web
servers in the Erlang VM

54. Plug.Conn
● host
● method
● path_info
● req_headers
● params
● assigns
● resp_body
● status

55. A plug
def do_nothing(conn) do
conn
end

56. Pipeline
● Pipeline is a set of plugs
pipeline :pipeline_name do
plug :plug1
plug :plug2
end
● Pipeline is a plug
conn conn conn
pipeline
conn conn conn
v1
plug
v2

57. Almost the same...
def pipeline_name(conn) do
conn
|> if_not_halted(plug1)
|> if_not_halted(plug2)
end

58. The glue
def if_not_halted(conn, plug) do
if conn.halted? do
conn
else
plug(conn)
end

59. Phoenix is a pipeline
pipeline :phoenix do
plug :endpoint
plug :user_pipelines
plug :router
plug :controller
end

60. And lets you add custom plugs
def current_user(conn) do
account_id = get_session(conn, :account_id)
cond do
account = conn.assigns[:current_account] ->
conn
account = account_id && Repo.get(MyApp.Account, account_id) ->
assign(conn, :current_account, account)
true ->
assign(conn, :current_account, nil)
end
end

61. And lets you add custom plugs
def current_user(conn, repo Repo) do
account_id = get_session(conn, :account_id)
cond do
account = conn.assigns[:current_account] ->
conn
account = account_id && repo.get(MyApp.Account, account_id) ->
assign(conn, :current_account, account)
true ->
assign(conn, :current_account, nil)
end
end

62. current_user test
defmodule Fakerepo do
def get(1) do
%Account{name: „Tomasz”, …}
end
end
current_user(conn, Fakerepo)

63. Benefits
● Easy to compose: set of plugs is a plug
● Easy to extend: your own plugs can be put
anywhere in the request cycle
● Easy to test: but you need to ensure explicit
contracts

64. Naming digression
● burritos

65. Naming digression
● burritos
● >>=

66. Naming digression
● burritos
● >>=
● Maybe, IO

67. Naming digression
● burritos
● >>=
● Maybe, IO
● A monad is just a monoid in the category of
endofunctors

68. GenServer
● GenServer abstracts an actor that takes
requests from the outside world and keeps
state.
c
c
server
c call
cast
cast

69. GenServer
def handle_call(msg, from, state) do
...
{:reply, actual_reply, new_state}
end

70. Benefits
● Easy to compose: not covered
● Easy to extend: just add another handle_call
● Easy to test: it is not even necessary to start it!

71. Elm Architecture
update
view
new_modelcommands
virtual dom
Browser with Elm
msgs model

72. Benefits
● Easy to compose: recursively
● Easy to extend: just add another message
● Easy to test: only pure functions!

73. Carrots
Did you know carrots are good for your
eyesight?

75. Single source of truth
● Changeset
● Multi
● Plug.Conn
● GenServer’s State
● Elm Model

76. Separate pure and impure
● Keep impure parts separate from core logic
● Make impure parts as function inputs (explict
contracts)

77. Questions
If you like this talk, follow me on Twitter
@snajper47