Slide 1

Slide 1 text

最近のElixir開発で得た知見を語る 2019/10/30 fukuoka.ex#32:秋のElixir LT大会

Slide 2

Slide 2 text

自己紹介 ● 古賀 祥造(こが しょうぞう) ● 株式会社ベガコーポレーション ● fukuoka.exビルダー / もくもく会リーダー ● Elixir/PhoenixでAPIを日々書いています ● twitter: @koga1020_

Slide 3

Slide 3 text

今日お話しすること ● 最近お仕事でElixir・Phoenixを触っています ○ 今年の3月ぐらいから、やっと半年ちょい ● その中で得た知見をつらつらと語ります

Slide 4

Slide 4 text

何やってる? ● 社内基幹システムの構築 ● 事業拡大に向けたシステム刷新のプロジェクト ● REST APIの構築 ○ データの整備、商品ページ公開の自動化などなど ○ Elixir・Phoenixを採用し、せっせと開発中 ○ リリース前なので、Elixir(v1.9.x) / Phoenix(v1.4.x)に追従

Slide 5

Slide 5 text

Elixir・Phoenix 実際どうよ?

Slide 6

Slide 6 text

思うところ ● メリット ○ ロジック書きやすい最高 ☺ ○ テストがサクサク書ける ☺ ○ デプロイも一度mix release用のDockerfileを組んでしまえば楽☺ ● デメリット ○ エラーメッセージ分からない ○ Ectoクセが強い ○ ex_awsでCloudFront操作できない

Slide 7

Slide 7 text

思うところ ● メリット ○ ロジック書きやすい最高 ☺ ○ テストがサクサク書ける ☺ ○ デプロイも一度mix release用のDockerfileを組んでしまえば楽☺ ● デメリット ○ エラーメッセージ分からない ○ Ectoクセが強い ○ ex_awsでCloudFront操作できない

Slide 8

Slide 8 text

エラーメッセージ分からない ● エラーメッセージだけで分からないこともしばしば ● 特にPlug。よくハマる。 ● 自作Plugを組んでいる場合は要注意。よくよくデバッグすると 「あーこのエラーPlugが原因だったのねー」となることもしばしば

Slide 9

Slide 9 text

GitHubのissueにとりあえずつっこもう

Slide 10

Slide 10 text

depsにinspectを仕込むことも可能

Slide 11

Slide 11 text

根気よくdebugする力が必要

Slide 12

Slide 12 text

Ectoクセが強い ● Ecto: DB Wrapper ○ RailsでいうActive Record ○ LaravelでいうEloquent ● オブジェクトでないので、ORMではない ● これがなかなかクセがすごい

Slide 13

Slide 13 text

クエリっぽく書くこともpipeで書くことも出来る

Slide 14

Slide 14 text

弊チームではpipeでの書き方を採用

Slide 15

Slide 15 text

慣れれば怖くない! ● Ecto.Multi ● cast_assoc, put_assoc ○ 「Ectoのassoc関数を整理してみる」という記事書いてます ○ https://www.koga1020.com/posts/ecto-assoc-functions ● dynamic query この辺りを理解してからは基本的な処理は書けるようになった この辺りのキーワードをまずは拾ってみる

Slide 16

Slide 16 text

ex_awsでCloudFront操作できない ● AWSの操作APIを提供するex_awsというライブラリ ● 要件でCloudFrontを操作する必要があったが、該当するモジュールがない ● こんな具合に、「他言語ならあるのに!」問題にぶつかることも → 結局、PHPのSDKを参考に自作した。多少リソースに余裕がないと厳しい?

Slide 17

Slide 17 text

思うところ ● メリット ○ ロジック書きやすい最高 ☺ ○ テストがサクサク書ける ☺ ○ デプロイも一度mix release用のDockerfileを組んでしまえば楽☺ ● デメリット ○ エラーメッセージ分からない ○ Ectoクセが強い ○ ex_awsでCloudFront操作できない

Slide 18

Slide 18 text

ロジック書きやすい最高☺ ● 関数パターンマッチが至高 ● チーム内ではif文を書かない方針 ○ ifを書くと、分岐が増えたときに対応できない ● 関数パターンマッチ or withに寄せる ○ この辺りはチームでの決めの問題かも ○ 世のライブラリの実装を参考に見るのが吉

Slide 19

Slide 19 text

構造体をマッチさせる際は常に明示的に書く

Slide 20

Slide 20 text

Enumを使いこなす ● fukuoka.exでもよく言われているが、これはガチ ● map, reduce, filter, reject, group_by あたりは鉄板 ○ そのあとは組み合わせたflat_mapやmap_joinなど ● Enumerable protocolが実装されたdata typeなら動作するので、MapもOK

Slide 21

Slide 21 text

credoで秩序を保つ ● https://github.com/rrrene/credo ● Elixirの静的コード解析ツール ● 以下の観点でコードの改善点を指摘してくれる ○ consistency / design / readability / refactor / warning ● pre-commitでcredoでエラーが出たらcommitできないようにしている ○ ついでに mix format も自動実行にしている

Slide 22

Slide 22 text

警告を出したいものだけ設定することも可能 ● credo gen.config で設定ファイルを書き出し、カスタマイズ可能 ● .credo.exsが生成される ● projectのrootかconfig/.credo.exs としておけば設定値が採用される

Slide 23

Slide 23 text

テストがサクサク書ける ● mix testで即テストが実行可能 ● optionが豊富。以下のオプションでテストを回すと良い感じ ● --stale: 前回のテストから変更のあったモジュールに関するテストだけ実行 ● --max-failures: 許容する失敗回数。1だと1つテストケースがこけた瞬間に終了

Slide 24

Slide 24 text

便利なライブラリ達 ● mix_test_watch ○ ファイルの変更を検出してテストコードを実行 ○ https://github.com/lpil/mix-test.watch ● mock ○ モックライブラリ ○ https://github.com/jjh42/mock

Slide 25

Slide 25 text

便利なライブラリ達 ● Power Assert ○ テスト結果をみやすくしてくれるライブラリ ○ https://github.com/ma2gedev/power_assert_ex ● ExMachina ○ rubyでいうfactory_bot(おそらく) / LaravelでいうFactory ○ https://github.com/thoughtbot/ex_machina

Slide 26

Slide 26 text

● mix release を利用 ● Dockerfileのマルチステージビルド ○ mix releaseの成果物をalpineのベースイメージにCOPY ● GitHub → Travis CI → ECR → ECS のデプロイパイプライン デプロイ Amazon ECR Amazon ECS GitHub Travis CI

Slide 27

Slide 27 text

エラー監視 ● Sentryを採用 ● ElixirのSDKもあり、導入は楽チン✨ ● https://github.com/getsentry/sentry-elixir ● Plugでエラーを拾うことができる

Slide 28

Slide 28 text

その他諸々

Slide 29

Slide 29 text

OpenAPIのドキュメンテーション 元々PhoenixSwaggerを利用してswagger.jsonを生成していた |> 開発が進むにつれて、メンテが辛くなってきていた |> さらにElixirがv1.9に上がった直後は依存ライブラリの関係で使えない状態に、、 |> このタイミングで、API定義はymlを直接編集するようにした

Slide 30

Slide 30 text

Elixirの中で書きたい人は ● Open API Spexなるライブラリがある ● https://github.com/open-api-spex/open_api_spex ● Elixirコード内でAPI定義を 記述できる

Slide 31

Slide 31 text

デプロイ(個人開発) ● Gigalixir × Github Actions ● 特定のブランチにmergeされたら、git push gigalixir master を実行する ● ブログにも書いたので、よければ是非 ○ https://www.koga1020.com/posts/gigalixir-deploy-from-github-action

Slide 32

Slide 32 text

Thank you!