Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Web開発 × Elixir

302e60b4d42787b4a39de4a3a80cfc9d?s=47 shozo koga
January 09, 2020

Web開発 × Elixir

2020.01.09 北九州市立大学での登壇

302e60b4d42787b4a39de4a3a80cfc9d?s=128

shozo koga

January 09, 2020
Tweet

Transcript

  1. 開発 北九州市立大学

  2. 自己紹介 • 古賀 祥造(こが しょうぞう) • 株式会社ベガコーポレーション • fukuoka.exビルダー /

    もくもく会リーダー • Elixir/PhoenixでAPIを日々書いています • twitter: @koga1020_
  3. 経歴 九州大学 大学院 システム情報科学府 卒業  株式会社 で勤務 システムの受託開発(主に )  株式会社ベガコーポレーションで勤務

    いわゆる社内 社内プロジェクトでバックエンドを担当 で を構築中
  4. なぜここにいるのか のコミュニティ「 」で さん、 君と共に活動 色々とディスカッションしましょう。今日は 日よろしくお願いします

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

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

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

  8. エンジニア?

  9. エンジニア?

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

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

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

  13. 専門分野ごとに覚えるべきことが無数にある 出典 https://github.com/kamranahmedse/developer-roadmap HTML・CSS・JavaScriptの基本がわかって 単純な静的ページが組めるレベル - ハイブリッドアプリに関する知識 - 型チェックに関する知識 -

    ビルドツール周辺の知識( Webpack) - フレームワーク(React、Angular、Vue)と そのアーキテクチャに関する知識 - テストに関する知識 - PWA(Progressive Web Apps)に関する知識 などなど。
  14. 自分の専門は何で、どの領域ならパフォーマンスが出せるか意識する 別の分野を「まったく知らない」というのは業務上非効率 薄く広く知識を持ち、かつ特定の分野に深いのが理想(持論) 型人材 型人材とかよく言われる もちろん、全部が非常に深い人もたまにいる 「好奇心旺盛」が最大の適正

  15. 開発の傾向

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

    出典:https://aws.amazon.com/jp/microservices/
  17. 小さく作るメリット 修正の影響範囲が小さくなる モノリシックだと、影響範囲が広い 読めない この のメソッドを修正したらどこに影響があるだろう このバッチ処理を修正したらどこに影響があるだろう 言語、フレームワークの 追従が厳しくなる 修正→デプロイのサイクルが速くなる

    細かく修正して、細かく反映する 運用で得られたフィードバックを元に、システムを高速に改善できる - DevOpsモデル と呼ばれる
  18. マイクロサービスを構築するための技術( ) クラウド技術 など聞いたことがあるはず 必要な計算資源を必要なときに必要なだけ調達する ボタン つで高性能なサーバを数分で調達可能 サーバーレスアーキテクチャ 自前で管理するサーバーを持たずに サービスを構築する

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

  20. マイクロサービスを構築するための技術( ) ベースでのやり取り 形式の が主流 : ( )と呼ばれる設計思想に 基づいた のことを指す

    フロントでは ではなく を 受け取ってページを描画する
  21. 参考:マイクロサービスのデプロイ例

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

  23. 参考:マイクロサービスのデプロイ例 - Continuous Integration - 修正・テスト・ビルドを継続的に行う - Continuous Delivery -

    ビルド成果物のリリースを継続的に行う - Continuous Deployment - 本番環境へのデプロイを継続的に行う
  24. 技術選定

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

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

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

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

  29. 技術選定に関する記事

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

    Web開発者のための Elixirのススメ【デブサミ 2019】 https://codezine.jp/article/detail/11431
  31. 前述の観点 その言語・フレームワークで人は採用できるか→ △ の方が人を採りやすいのは事実 既存の資産はどの程度使い回せるか→ △ そもそも 開発実績は無いし、以前より充実したとは言えライブラリも未成熟 すでに社内に詳しい人がいるか→ △

    採用したタイミングで触ったことがある人間はいたが業務レベルではゼロ 不慣れな言語を選択した場合、納期に対して学習コストは許容できるのか → ◦ 技術検証の期間を設けることが出来た 性能要件が厳しいシステムの場合、その要件を満たせるか→ ◎ 耐障害性が選定の最大の理由
  32. 現状 で とデータ移行ツールを構築 社内 サービスのリリースの目処がたった 要件定義含め ヶ月程度のプロジェクト

  33. 構成(詳細略)

  34. 構成(詳細略) - Phoenixサーバーをコンテナで運用 - AWS ECSを採用 - データ移行や検証用プロジェクトにMix Projectを作成 -

    サクッとプロジェクトを作れるのが楽
  35. メリット・デメリット メリット - ビジネスロジックが記述しやすい - 関数パターンマッチが強力 - ビルドツールであるMixが優秀 - プロジェクトの構成がシンプル

    - サブプロジェクトの追加が容易 - リリースコマンドもあり、 デプロイまで整う - APIレスポンスが高速 - 比較したわけではないのでおまけ程度 デメリット - AWS系のライブラリ不足 - エラー時の知見不足 - 日本語は皆無 - 自走できるメンバーでないと 開発は厳しい - Ecto (ORM相当のツール)の 記述が複雑になる
  36. 「特定の言語・フレームワークを使えたら 」というわけではない 「何を、何のために作るか」という根本の部分が非常に重要 メリット・デメリットを理解した上で、決定したら突き進む 代替しやすいように、小さく、かつテストを書いて修正に強くしておく は 開発において既存言語と遜色ない(むしろ良い)開発体験 日本語情報が少ないのが悩ましいが、少ない情報を発信することで エンジニアとしての価値貢献もできる領域

  37. について

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

    さらにその の技術を活用した Phoenix LiveViewというライブラリが優秀
  39. 自身を構成する要素 自体が複数のライブラリを組み合わせて作られている 主に次の つ 製の サーバー サーバーのアダプター。標準で に対応 の 、

    に対する制御は が担うので重要
  40. ユースケース サーバーサイドレンダリング Phoenixサーバー

  41. ユースケース サーバー

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

  43. ユースケース の利用

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

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

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

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

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

  49. 活用のヒント リアルタイムな画面更新 他ユーザーへの配信に強い センシングしたデータをリアルタイムに画面表示 チャットの投稿やログイン状態を他ユーザーにリアルタイムに表示 一方で、オフラインのサポートは無理なので、要件次第 ( )に軍配が上がる 実装の生産性が高いので、スタートアップのプロトタイプや 数十

    名程度が利用するような社内システムなどに有用そう
  50. は での フレームワークとして最も代表的 、 、 の つの存在を覚えておく と呼ばれる の の実装が標準で搭載

    を活用したリアルタイム の実装に優れている ただし、まだまだマイナー 一部機能(ファイルアップロードなど)の導入はこれから 要件によっては十分実践投入可能
  51. コミュニティ活動

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

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

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

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

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

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

    学生の間から、まずは参加することから始めてみては? 自分でコミュニティを作っちゃっても良し
  58. の国際カンファレンス「 」の日本開催 は 月に小倉で開催 もまたやるので、ぜひ運営サイドで参加する学生さんに期待! それまでのイベントにもぜひ! 開発スキル上がるよ!

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

    へぜひ 学生の間から飛び込んでみて欲しい 社会人の人がいっぱいいるので、参考になる情報がたくさん得られます