Web開発 × Elixir - Speaker Deck

Slide 1

Slide 1 text

開発北九州市立大学

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

経歴九州大学大学院システム情報科学府卒業　株式会社で勤務システムの受託開発（主に）　株式会社ベガコーポレーションで勤務いわゆる社内社内プロジェクトでバックエンドを担当でを構築中

Slide 4

Slide 4 text

なぜここにいるのかのコミュニティ「」でさん、君と共に活動色々とディスカッションしましょう。今日は日よろしくお願いします

Slide 5

Slide 5 text

質問就職先として業界に興味がある人興味がある人は、どんなイメージを持っているだろう逆に興味がない人は、どういう業界に興味があるか聞きたい企業インターンに行っている、行ったことがある人現場の開発に触れている、触れたことがある人話せる範囲で、やっていることを聞きたい趣味・独学でサービスを作っている、持っている人「（または）」と聞いて何を指すか分かる人「」と聞いて何を指しているか分かる人

Slide 6

Slide 6 text

今日話すこと業界のイメージを掴んでもらう開発の最近の傾向を掴んでもらうを業務で使用している肌感、メリットデメリットについてフレームワークについても触れるコミュニティ「」に携わっている所感など

Slide 7

Slide 7 text

今日話さないこと各技術の詳細言語の記法や実装法など詳細が気になる方はぜひへどうぞ（後述）専門外のエンジニアとしてのキャリアの話組み込み、医療系、機械航空、化学、

Slide 8

Slide 8 text

エンジニア？

Slide 9

Slide 9 text

エンジニア？

Slide 10

Slide 10 text

これといった定義はない一般的には、技術領域で分かれてくるアプリフロントエンドバックエンド

Slide 11

Slide 11 text

規模が小さければ人でもすベて担える - 用語にあまり意味はない - 会社規模 / システム規模 / 業務領域に依存

Slide 12

Slide 12 text

専門分野ごとに覚えるべきことが無数にある出典 https://github.com/kamranahmedse/developer-roadmap

Slide 13

Slide 13 text

専門分野ごとに覚えるべきことが無数にある出典 https://github.com/kamranahmedse/developer-roadmap HTML・CSS・JavaScriptの基本がわかって単純な静的ページが組めるレベル - ハイブリッドアプリに関する知識 - 型チェックに関する知識 - ビルドツール周辺の知識（ Webpack） - フレームワーク（React、Angular、Vue）とそのアーキテクチャに関する知識 - テストに関する知識 - PWA（Progressive Web Apps）に関する知識などなど。

Slide 14

Slide 14 text

自分の専門は何で、どの領域ならパフォーマンスが出せるか意識する別の分野を「まったく知らない」というのは業務上非効率薄く広く知識を持ち、かつ特定の分野に深いのが理想（持論）型人材型人材とかよく言われるもちろん、全部が非常に深い人もたまにいる「好奇心旺盛」が最大の適正

Slide 15

Slide 15 text

開発の傾向

Slide 16

Slide 16 text

開発の傾向は「小さく、速く、疎に」マイクロサービスが主流になってきている対義語：モノリシック「拡張性」「分散」がキーワードサービスを特定の単位に切り出し、小さなサービスを組み合わせて大きなサービスを構築する認証ロジック、決済基盤、画像投稿機能、管理機能サービス間はを介してやり取り出典：https://aws.amazon.com/jp/microservices/

Slide 17

Slide 17 text

小さく作るメリット修正の影響範囲が小さくなるモノリシックだと、影響範囲が広い読めないこののメソッドを修正したらどこに影響があるだろうこのバッチ処理を修正したらどこに影響があるだろう言語、フレームワークの追従が厳しくなる修正→デプロイのサイクルが速くなる細かく修正して、細かく反映する運用で得られたフィードバックを元に、システムを高速に改善できる - DevOpsモデルと呼ばれる

Slide 18

Slide 18 text

マイクロサービスを構築するための技術（）クラウド技術など聞いたことがあるはず必要な計算資源を必要なときに必要なだけ調達するボタンつで高性能なサーバを数分で調達可能サーバーレスアーキテクチャ自前で管理するサーバーを持たずにサービスを構築するサービスのロジックを記述した関数のみデプロイする：

Slide 19

Slide 19 text

マイクロサービスを構築するための技術（）コンテナ技術マイクロサービスの各サービスをコンテナとして構築開発環境の統一、デプロイのし易さが大きなメリット各サービスを適切に配置、設定するための技術としての活用も

Slide 20

Slide 20 text

マイクロサービスを構築するための技術（）ベースでのやり取り形式のが主流：（）と呼ばれる設計思想に基づいたのことを指すフロントではではなくを受け取ってページを描画する

Slide 21

Slide 21 text

参考：マイクロサービスのデプロイ例

Slide 22

Slide 22 text

参考：マイクロサービスのデプロイ例 ● mix release をCI上で実行 ● buildした成果物をdocker imageに内包

Slide 23

Slide 23 text

参考：マイクロサービスのデプロイ例 - Continuous Integration - 修正・テスト・ビルドを継続的に行う - Continuous Delivery - ビルド成果物のリリースを継続的に行う - Continuous Deployment - 本番環境へのデプロイを継続的に行う

Slide 24

Slide 24 text

技術選定

Slide 25

Slide 25 text

どう技術選定するか、その前にそもそもとして、「システムを作る必要があるのか」「誰の何の課題を解決するのか」を考えるべきすなわち要件定義が超重要業務では「好きな技術で好きなサービスをなんとなく作る」ことは出来ない研究と同じく、課題に対してシステムが価値提供しているか、仮説検証する力が非常に重要になってくる

Slide 26

Slide 26 text

技術選定サービスを構築するための要素技術を決める重要な作業使う言語・フレームワークインフラアーキテクチャサービス全体の設計様々な観点で検討し、意思決定する熟練者ばかりが決めてくれる環境なら上司がしてくれるだろうが、小さい職場だと自分で決めないといけないタイミングがそこそこある

Slide 27

Slide 27 text

観点例その言語・フレームワークで人は採用できるか採用した後、担当者が辞めてしまった場合どうなる？既存の資産はどの程度使い回せるかすでに社内に詳しい人がいるか社内にが詳しい人がいるのに積極的にを採用する？そのメリットは？不慣れな言語を選択した場合、納期に対して学習コストは許容できるのか性能要件が厳しいシステムの場合、その要件を満たせるか

Slide 28

Slide 28 text

弊社プロジェクトの場合社内システムのリプレイス案件システムの特性上耐障害性に優れていることがマスト社員全員が毎日アクセスするものなので、処理速度は速ければ速いほど良いが、ある程度であれば良し銀行系のシステム、ゲーム系システムだとこうはいかない → 耐障害性のメリットを取り、Elixir を採用することに！

Slide 29

Slide 29 text

技術選定に関する記事

Slide 30

Slide 30 text

の特徴 Web開発者の多くは、常に納期の短い仕事に追われている。なんとかサービスをリリースした後も増え続けるクライアント、複雑化するコード、肥大化するサーバー構成、障害対応のコスト増加……と、悩みは尽きない。こうしたつらい状況を改善するための3つの要素として、幾田氏は「並行性」「メンテナンス性」「耐障害性」を挙げる   　「『Elixir』は、それら3つをすべて備えている。Web開発のための優秀なツール類も完備しており、まさにWeb開発者の悩みを解決するために存在するような言語」（幾田氏）   出典：並列処理に関数型 …でも学習コストは高くない！？ Web開発者のための Elixirのススメ【デブサミ 2019】 https://codezine.jp/article/detail/11431

Slide 31

Slide 31 text

前述の観点その言語・フレームワークで人は採用できるか→ △ の方が人を採りやすいのは事実既存の資産はどの程度使い回せるか→ △ そもそも開発実績は無いし、以前より充実したとは言えライブラリも未成熟すでに社内に詳しい人がいるか→ △ 採用したタイミングで触ったことがある人間はいたが業務レベルではゼロ不慣れな言語を選択した場合、納期に対して学習コストは許容できるのか → ○ 技術検証の期間を設けることが出来た性能要件が厳しいシステムの場合、その要件を満たせるか→ ◎ 耐障害性が選定の最大の理由

Slide 32

Slide 32 text

現状でとデータ移行ツールを構築社内サービスのリリースの目処がたった要件定義含めヶ月程度のプロジェクト

Slide 33

Slide 33 text

構成（詳細略）

Slide 34

Slide 34 text

構成（詳細略） - Phoenixサーバーをコンテナで運用 - AWS ECSを採用 - データ移行や検証用プロジェクトにMix Projectを作成 - サクッとプロジェクトを作れるのが楽

Slide 35

Slide 35 text

メリット・デメリットメリット - ビジネスロジックが記述しやすい - 関数パターンマッチが強力 - ビルドツールであるMixが優秀 - プロジェクトの構成がシンプル - サブプロジェクトの追加が容易 - リリースコマンドもあり、デプロイまで整う - APIレスポンスが高速 - 比較したわけではないのでおまけ程度デメリット - AWS系のライブラリ不足 - エラー時の知見不足 - 日本語は皆無 - 自走できるメンバーでないと開発は厳しい - Ecto (ORM相当のツール)の記述が複雑になる

Slide 36

Slide 36 text

「特定の言語・フレームワークを使えたら」というわけではない「何を、何のために作るか」という根本の部分が非常に重要メリット・デメリットを理解した上で、決定したら突き進む代替しやすいように、小さく、かつテストを書いて修正に強くしておくは開発において既存言語と遜色ない（むしろ良い）開発体験日本語情報が少ないのが悩ましいが、少ない情報を発信することでエンジニアとしての価値貢献もできる領域

Slide 37

Slide 37 text

について

Slide 38

Slide 38 text

製のフレームワークパターンで、他言語のフレームワーク経験者に馴染みやすいと呼ばれる実装をラップした機能も標準搭載リアルタイムの実装に適している ※ 画面遷移を伴わないという意味で使っていますさらにそのの技術を活用した Phoenix LiveViewというライブラリが優秀

Slide 39

Slide 39 text

自身を構成する要素自体が複数のライブラリを組み合わせて作られている主に次のつ製のサーバーサーバーのアダプター。標準でに対応の、に対する制御はが担うので重要

Slide 40

Slide 40 text

ユースケースサーバーサイドレンダリング Phoenixサーバー

Slide 41

Slide 41 text

ユースケースサーバー

Slide 42

Slide 42 text

ユースケースサーバー Phoenixサーバー HTMLのレンダリングや状態管理はフロントエンドの責務になる ※状態管理: 「どの画面にいる」「ボタンがクリックされた」など、クライアント側（Webなら主にブラウザ）での状態のこと

Slide 43

Slide 43 text

ユースケースの利用

Slide 44

Slide 44 text

ユースケースの利用時にスクリプトを実行

Slide 45

Slide 45 text

ユースケースの利用 - WebSocketによる双方向通信により、クライアントでのイベントをサーバーサイドで処理可能 - 逆に、サーバーサイドの状態をクライアントへ配信可能 - 初期レンダリング後の状態管理はサーバーサイドの責務になる

Slide 46

Slide 46 text

例出典：https://elixirforum.com/t/opinions-needed-on-building-a-tutorial-course-using-elixir-and-phoenix-liveview-tetris-game/24902

Slide 47

Slide 47 text

例出典：https://dockyard.com/blog/2018/12/12/phoenix-liveview-interactive-real-time-apps-no-need-to-write-javascript

Slide 48

Slide 48 text

のコンテストも開催 https://phoenixphrenzy.com/results

Slide 49

Slide 49 text

活用のヒントリアルタイムな画面更新他ユーザーへの配信に強いセンシングしたデータをリアルタイムに画面表示チャットの投稿やログイン状態を他ユーザーにリアルタイムに表示一方で、オフラインのサポートは無理なので、要件次第（）に軍配が上がる実装の生産性が高いので、スタートアップのプロトタイプや数十名程度が利用するような社内システムなどに有用そう

Slide 50

Slide 50 text

はでのフレームワークとして最も代表的、、のつの存在を覚えておくと呼ばれるのの実装が標準で搭載を活用したリアルタイムの実装に優れているただし、まだまだマイナー一部機能（ファイルアップロードなど）の導入はこれから要件によっては十分実践投入可能

Slide 51

Slide 51 text

コミュニティ活動

Slide 52

Slide 52 text

質問大学の講義関係なく、福岡市北九州市で開かれているイベントに参加したことがある人ロボコン、ハッカソン、勉強会、もくもく会勉強会、もくもく会にどんなイメージを持っている？

Slide 53

Slide 53 text

九州エリアにもたくさんのコミュニティがある

Slide 54

Slide 54 text

色々なコミュニティがある企業主体のコミュニティ、有志で開催しているコミュニティゆるっと、福岡理学部特定の言語・ツール系コミュニティ、、

Slide 55

Slide 55 text

のコミュニティ出典：https://qiita.com/piacerex/items/651dcbfae7f387ba996a

Slide 56

Slide 56 text

福岡市内で年から活動しているコミュニティ年から私も参加、運営に携わるように月ペースでもくもく会や勉強会を開催年からは北九州版のも誕生

Slide 57

Slide 57 text

運営に携わってみてに触れる機会得られる情報量が圧倒的に増えた受け身で参加するイベントと違い、主体的な行動が増える情報発信が増え、技術書典で本も出した負担になるレベルではやらないようにしているコミュニティは継続することの方が大事だと思っている本業以外で関われる人が増えたまさにこの場もそう学生の間から、まずは参加することから始めてみては？自分でコミュニティを作っちゃっても良し

Slide 58

Slide 58 text

の国際カンファレンス「」の日本開催は月に小倉で開催もまたやるので、ぜひ運営サイドで参加する学生さんに期待！それまでのイベントにもぜひ！開発スキル上がるよ！

Slide 59

Slide 59 text

まとめ「エンジニア」といっても業務として携わる領域は無数会社、システムの規模によりけり様々な専門分野があるが、大きな傾向としてはマイクロサービスの流れは耐障害性、生産性の観点から開発に有用を始めとするツールによりリアルタイムの実装にメリットありコミュニティに参加するならば、へぜひ学生の間から飛び込んでみて欲しい社会人の人がいっぱいいるので、参考になる情報がたくさん得られます