西村さんの雑記ログ

技術や趣味について色々。

WEBエンジニア勉強会 #14に行ってきた話

プログラミング 勉強会

今回は１ヶ月ほど前の話で、「WEBエンジニア勉強会 #14」に行ってきた話です。
当日はノートに走り書き+箇条書きで記録を取ったので、それを参考に当日の感想を箇条書きで起こしています。

web-engineer-meetup.connpass.com

行ってみた理由

個人的に最近PythonでWebフレームワークを触っているのですが、LT一覧に「GAEによるPythonWEBアプリケーションの高速開発 (10分)」というものを見つけ、気になったので思い切って参加してきました。

LT

前座を含め、計8件のLTがありました。 内容的には設計的な話からインフラまで、WEB開発に関わるものなら何でもありです。 普段プログラミング、それも客先常駐を中心にしていると、中々触れることのない分野もあり、かなり刺激的でした。

前座LT：人工肉を食べよう

普段は前座枠までLTが埋まるそうですが、今回は埋まらなかったということで、主催者のOSCA (@engineer_osca) | Twitterさんによる「人工肉」についてのLTでした。
試食まで用意するという、中々熱の入ったLTでした。

  • 畜産、特に牛の肥育は温暖化ガスを大量に排出する→環境問題
  • 環境問題に配慮し、肉ではなく、大豆を用いた人工肉を使ったファストフードの紹介

私事ですが、生まれ育ったところが畜産と農業の盛んな土地なので、「大豆を用いた人工肉」は畜産の大変さを軽減する手段の一つで、かつ移行も出来る手段なのではと感じました。
（とはいえ、地元に関しては放牧による草原の維持と、草原が観光資源であり、独自の生態圏を維持しているという面もあるので、一律に畜産を否定できないのも本心ですが……）

LT1：何故マイクロサービスにするんだっけ？

今回の会場スポンサー、株式会社カサレアルの多田さん（Masatoshi Tada (@suke_masa) | Twitter）によるマイクロサービスに関するLT。
カサレアルはエンジニアの研修を行う会社で、マイクロサービスに関する研修もあるのだそう。

  • マイクロサービスとはどういうものか
    • 従来のシステム（モノリシック）に対する対義語
    • 複数のサービスが連携し合う
      • モノリシックは一つのサービスで全ての機能を持つ（密結合）
      • マイクロサービスは疎結合なサービス思考アーキテクチャ
        • あるサービスの変更が他のサービスに影響しないのが理想
  • 何故マイクロサービスにするんだっけ？
    • 儲かる機能をマイクロサービス化する
    • モノリシックなサービスの欠点：頻繁な変更に弱い
      • 1つの機能を変更すると考えると……
        • 再デプロイに手間がかかる
        • 変更時の影響範囲の大きさ
      • 頻繁な変更が不要なら、無理にマイクロサービス化する必要はない
    • マイクロサービス：頻繁な変更が可能
      • 1つの機能を変更すると考えると……
        • 再デプロイの手間が少ない
          • 1つの機能を担当するサービスだけを止めて再デプロイすることが可能
        • 変更時の影響範囲が少ない
  • マイクロサービスは「そうできるように作るのが重要」
  • メリット・デメリット
    • サービス毎に自由な言語やフレームワークを使用できる
      • メリットかと言われると「？」
        • 保守が大変
  • 気をつけること
    • 障害率UP
      • ダウン時の自動再起動
    • ネットワークを挟む
    • 障害が伝播する
    • 技術的難易度のUP
    • 金銭面はコストUP
  • どこで分割するか？
  • テストは重要

LT2：失敗から知るAWSサーバレス

yu.eguchi (@pal_of_pome) | Twitterさんによる、AWSサーバレスでの失敗に関するLT。
お客様の要請でAWSサーバレスを用いたS3への画像アップロード機能のあるシステム構築を行った際、色んな制限に引っかかったのだそう。

  • AWS、EC2を自分で管理しない場合
    • ペイロード上限
      • API Gateway：10MBのペイロード上限
      • Lambda Function：6MBのペイロード上限
      • 回避策
      • フロントエンドでサイズチェックを行う
      • フロントエンドから直接S3に上げるような設計にする
        • APIではS3アップロード用の署名付きURLを返す
    • タイムアウト
      • Lambda Function：3秒～15分まで設定可能
      • API Gateway：50ms～29秒まで設定可能
      • したがって、全体で最大29秒以内に処理を完了しなければならない
      • 回避策
        • キューに退避する（Amazon SQSなど）
        • Lambda Functionを更に呼び出す
        • Step Functionsを使う
  • そのシステムは本当にサーバレスが必要か？
  • 公式ドキュメントは大事

LT3：愛されるダッシュボード

池田寿司 (@ikedaosushi) | Twitterさんによる、ダッシュボード機能開発に関するLT。
LT一覧からは分かりませんでしたが、Pythonによる開発ですね。
現場～開発のギャップを減らすため、Jupyter Hubを使って、関係者間でダッシュボードのサンプルを共有して動く状態を見れるようにしたのだそう。

  • ダッシュボードが使われなくなる
    • 見たいデータじゃない！
      • 正しいデータ
    • 可視化の方法が違う！
      • 正しい可視化
  • 使われるダッシュボードにするには
    • イテレーションが必要
      • ビジネスサイドとの距離感
      • Jupyter Hubの導入
        • マルチユーザで使えるJypyter Notebook
          • Jupyter Notebook
            • Pythonの対話環境
            • ブラウザ経由で使える
        • ダッシュボードのNoteBookを作成し、共有
          • ダッシュボードのデモが出来るようになった
          • 現場の方で条件を変えて確認することも可能になった
        • 十分にイテレーションを回した後、Dockerでリリース

LT4：アジャイル好きのウォーターフォールとの使い方

たけき (@takeki1967) | Twitterさんによる、ウォーターフォールの中でどうアジャイル的手法を使うかについてのLT。
裁量があることが前提条件のようですが、ウォーターフォールの中にアジャイル的なやり方を一部埋め込むことは可能で、やると中々便利になるという話。
ウォーターフォールは色んな思い出がありますね……（遠い目）
手作業で細かいチェックをするという作業が苦手な面があるので、個人的にはユニットテストや自動テストがある環境が好きです。

speakerdeck.com

  • Ruby On Rails

  • SchemaSpy

    • ER図、デフォルト仕様の出力ができる
      • HTML形式での出力が可能
    • Dockerイメージあり
    • Railsオプションあり
    • JDBCが動くDBで使用可能
    • 副産物：DBコメントからl18nメッセージリソースを生成

  • RSpec+PICT

    • PICT
      • ケースの組み合わせ出力
    • RSpec
      • 予めテスト項目だけを書いておく

  • 辛い作業を楽しい作業で置き換える

LT5：mdx-deck v3 and code-surfer v3

Naturalclar(Jesse K.) (@natural_clar) | Twitterさんによる、React hooks apiを使ったスライド作成モジュール「mdx-deck」とコード表示モジュール「code-surfer」に関するLT。
Reactはバリバリ触ったことは無いですが、色々出来てワクワクしますね。

  • mdx-deck v3
    • スライド作成
    • Markdownが使える
    • hooks api
      • useSteps
        • 1枚のスライドで色んな動きができる
      • useDeck
      • useKeyboard
      • useSwipe
  • code-surfer v3
    • 8/30時点ではα版
    • コードをきれいに見せることが出来る
    • Diffを表示することが出来る
      • 変更点にズームインすることが出来る
    • Presentation Code
      • カンペの表示ができる
    • 注意点
      • v1からの移行は変更点が多い

LT6：GAEによるPythonアプリケーションの高速開発

しまかぜsoft (@shimakaze_soft) | Twitterさんによる、Google App Engine(GAE)でのPythonアプリケーション開発に関するLT。
個人ではPython+Djangoを触っているのでタイムリーな話でした。
GAEだとデプロイは簡単ですが、色々制約や難点がありそうですね。

  • GAE
    • StandardとFlexible
      • Standard
        • ローカル書き込み：不可
        • SSH接続：不可
        • 起動が早い
      • Flexible
        • ローカル書き込み：可能
        • SSH接続：可能
        • Dockerfileによるカスタマイズ
    • yamlで各種設定を行う
    • メリット
      • nginxは不要
      • デフォルトでgunicorn設定済み
      • requirements.txtを自動参照してモジュールを設定してくれる
    • デメリット
      • デプロイは遅め
      • GAE内でドメインは1つしか持てない
      • WebSocket未対応
      • 価格はやや高め

LT7：How Can They Know That? A Study of Factors Affecting the Creepiness of Recommendations

Yuya Matsumura (@yu__ya4) | Twitterさんによる、推薦システムに対する感情（驚きと不信感）の海外論文に関するLT。
なおスライドは当日仕上げだったそう。
推薦システムはAmazonを始め色んなサイトにありますが、サイトの取り扱うものによって的確な推薦が驚きか不信感かで分かれることがあるそうで。
センシティブな内容（健康等）を取り扱うサイトほど、的確な推薦は「なんでこのサイトはこんなことまで知ってるんだ？」とネガティブに感じることがあり、
逆にホテルや映画などの娯楽よりになると「これだ！」「こんなのもあるのか」とポジティブな感情に寄っていく傾向があるという話。
では、サイト側としてはどう信用してもらうかというと、透明性、説明性、ユーザーによる設定が可能という辺りがポイントらしい。

英語ですが、元の論文はhttps://interactivesystems.info/system/pdfs/907/original/RecSys-19.pdfかな。

  • RecSys
    • 推薦システムについての会議、トップカンファレンス
  • 推薦システムに対するCreepinessの調査
    • Creepiness：ネガティブな感情
    • 高すぎるRecommendはユーザーの不信感を招く
    • 要因・影響
      • 感情測定尺度による調査：複雑な感情の調査
    • 性格によるCreepiness
      • 曖昧さへの不快感を感じるか
        • 不快感を感じるほどCreepiness耐性が高い
    • システムとCreepiness
    • ユーザへの影響
      • conversionの低下
      • 信頼の低下
        • 信頼してもらうにはどうするか
          • 透明性
          • 説明性
          • ユーザーによる設定が出来ること

感想

体力的に平日が夜遅いのはキツイなと感じ始めた年齢なので、金曜日夜開催だったのは大きかったです。
前述しましたが、普段関わらない分野の話を聞くことも出来て色々と刺激がありました。
機会があればまた行ってみたいと思います。