西村さんの雑記ログ

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

WEBエンジニア勉強会 #15に行ってきました

プログラミング 勉強会

11/15（金）に行われた、WEBエンジニア勉強会 #15に行ってきましたので、感想を書きます。

参加した理由

前回のWEBエンジニア勉強会 #14に参加してみて、色んなLTが行われていて刺激を受けるのが楽しいなと感じたことと、開催日が金曜日の夜と言うことで参加しやすかったことです。

会場

今回は渋谷の株式会社ミクシィさんでした。
作りと配置からして恐らくイベントスペースか大きめのミーティングルーム、ランチや休憩にも使われるスペースだと思いますが、小ぶりのテーブルに椅子4脚を1セットとして複数セット配置してあります。
テーブルがありましたので、ノートやPCを広げてメモを取るのにもちょうど良く、開放感もあって良い雰囲気でした。
今回はスクリーンとプロジェクターが前方の左右に2セットあったので、会場は前回より広めですが、どの位置に座っても見やすかったのではないかと思います。

LT

前座LT

今回は最後まで応募者がいなかったとのことで無し。
そのまま本編開始の19:25までゆっくりしていました。
主催者のOSCAさんいわく、開始前で人も少なく固い雰囲気でもないので、LTに挑戦してみたい方は是非、とのこと。
恐らく、LT初心者にもっとも適した枠ではないでしょうか。

LT1:axiosを型安全にするラッパーを作ったらVSCodeの補完で生産性が爆上げした話

Mitsuhide Matsuda (@m_mitsuhide) | Twitterさんによる、Node.js製Webクライアントaxiosのラッパー「GitHub - aspidajs/aspida」の紹介。
フロントエンドはほぼ未経験なので、聞いていて刺激になりました。

  • axiosでのWebリクエストで使うHistoryジェネリクスの定義ではany型が多用されるので、型チェックがほとんど出来ない
    • URIのチェックも出来ないので、動かしてみてtypoに気づくことが……
  • aspidaの特徴
    • リクエスト先APIの定義情報を配備するディレクトリ構成はNuxt.jsのPagesと同じような形で定義
    • リクエスト先APIの定義情報を記述し、コンパイルすると$api.jsというファイルが生成され、それをインポートすることでVSCodeでの補完、定義のチェックが出来るようになる
    • axios- mock- serverとの併用でフロントエンドのみで独立してモックを用いたテストが出来る
    • リクエスト先APIの定義情報が変更された場合は、定義情報を修正して再コンパイルすると再度チェックが行われる
  • 役に立つシーン
    • フロントエンドの機能が強いチーム
  • 既に実際のプロダクトでの採用実績がある

LT2:プレイングマネージャーになったときの話

ykagano (@ykagano) | Twitterさんによる、プレイングマネージャー体験の振り返りの話。
2013年〜2016年にかけて、iOS/Androidアプリを作るときにプレイングマネージャーをしたという話ですが、波乱で一杯ですね。

個人的には、OCRライブラリの選定に関しては、泥臭いと言われればそうだけど、ある意味一番確実な方法だなと思いました。
それから、最初に外部委託した時の展開が分かる人には分かる「これはフラグだらけだ……」と思う展開でした。
私自身が人を率いるのには向かないなあと思っているので、プレイイングマネージャーになれるかどうかは分かりませんが、手を動かす方や現場に近い立場が良いという方はキャリアの一つとして頭の隅に置いて良いかもしれませんね。

  • スマホアプリで使うOCRライブラリの選定
    • 実際に読み取らせるものと近いものを同一環境下で複数回読み取らせて、一番認識率の高いものを採用した
  • 最初の社外の開発会社に委託した時に、相見積もりの値段の安さを決め手にしてしまったため、品質が悪く炎上した
    • 失敗の要因
      • 相見積もりの値段の安さで決めたこと
      • 発注側で仕様を決めすぎたため、認識違いが発生したこと
    • 社内開発部分は以下のような施策を取っていたので割と余裕があった
      • スケジュールに十分なバッファを取る
      • 仕様書にビジネスロジックをざっくりと書いておく
      • 朝会で作業の状況を共有し、課題を拾い上げられるようにした
    • 反省点
      • 見積もりの安さだけを決め手にして開発会社を決めない
      • スケジュールは最悪のパターンを想定して組む
  • 委託先の開発会社へ契約終了を告げに行った時、役員の話力の高さがすごかった
  • 次のアップデート開発の時に、アプリもバックエンドも全て社外の開発会社へ委託した
    • 前回の失敗から以下の施策を取ることにより、上手く行った
      • スケジュールに実装後のチェックポイントを設けて、実装された機能が要件を満たしているかどうかを確認できるようにした
      • 全機能を網羅する受け入れテストを行った
      • TestFlightを使って実機テストを行う時間を取った
  • 途中で企画部に移り、管理側としてプレイングマネージャーをしたときの経験
    • 発注の流れについて、契約から全部知ることが出来た
    • 会社間はWin- Winを目指すべき
    • 最初の見積もりはスピード重視で多めに見積もって出す
  • プレイイングマネージャーとはどんな人か？
    • プロジェクトを推進するために技術的な部分も含めた、「やるべきこと」を決める人
    • 5W1Hの内、以下の事をまとめることが出来る人
      • Why：業務上で、何故それが必要なのかという社内外の要求
      • What：システム上で何が必要なのかという開発要件
    • チームの潤滑剤
    • プレイングマネージャーが抜けると一気にプロダクトが停滞するため、人材育成は重要
  • プレイングマネージャーになるには？
    • 分かるようにする、なる姿勢
    • 「分からない」という心理的な壁を除く
    • 必要なことは全て吸収し、何でもやる姿勢

LT3：デザインを見ながらフロントエンドコーディングをするときの考え方

Kou (@kkoudev) | Twitterさんによる、デザインからフロントエンドのコーディングに落とし込んでていく考え方についての話。 個人的に仕事でデザインからHTML+CSSのコードに落としていく工程をやったことが有るので、色んな所で思い当たりのような物がありました。
私の中では、「上下中央寄せにするにはtransformを使う」というTIPSを初めて知り、興味深かったです。

  • 今のフロントエンドとしては、PC、スマートフォン、タブレットの3種が画面デザインの大きな枠。
  • コードに落とし込む考え方
    1. PC画面をベースに画面全体をいくつかの領域、大まかに言うとテーマや大分類のようなもので分けていく。例えば、ヘッダー、メインコンテンツ、フッター、メインコンテンツ内の関連するまとまりなど。
    2. 固定デザイン（px指定のデザイン）からレスポンシブデザイン（%指定のデザイン）に落とし込む。この工程を経ると、PC画面のディスプレイサイズが変わっても拡大・縮小が行われるようになる。
    3. スマートフォンに対応するデザインに落とし込む。回り込みを考えた時、現在ではCSSのFlecboxを使用する。どの単位でまとめるかは共通要素に注目して決める。
    4. PCデザインから、タブレット、さらにスマートフォンのデザインへ切り替えるための画面サイズ、ブレイクポイントを決める。
    5. スマートフォンは年々サイズが大きくなるため、ブレイクポイントの目安はiPadを横向きにした時、縦向きにした時の横幅（それぞれ1024px、768px）
    6. 根拠としては、Chromeの開発者ツールでPC（ラップトップ）、タブレット表示に切り替えた時の横幅がそれぞれ1024px、768px
      • より広く細かくブレイクポイントを指定して対応したいと思うかもしれませんが、登壇者によればPC、タブレット、スマートフォンの3つが原則
  • コーディングに関するTIPS
    • CSSでのインライン要素。ブロック要素の左右中央寄せの方法
    • CSSでの上下中央寄せの方法
    • ボタンテキストを中央に寄せる方法
    • 装飾目的の画像（リンクの後ろにつく「>」等）を着ける時は疑似要素を使う

LT4：ネストした JSON を CSV に自動変換する Python ライブラリを作った

かわしん@ソフトウェアエンジニア (@kawasin73) | Twitterさんによる、JSONからCSVに変換し、メタデータを同時に生成するPythonライブラリを自作した話。

  • AI系のWebサービス開発
    • Web APIの一般的な出力形式：JSON
    • データサイエンスで一般的な形式：CSV
    • JSONをCSVに変換したい
  • ネストのない単純な繰り返しのJSON
    • Pythonのcsvモジュールで簡単にできる
  • ネストしたJSON
  • 配列を含んだJSON
  • キーに対する配列の長さが異なるJSON
    • 上記のようなJSONはcsvモジュールだと簡単に変換できない
  • 複雑なJSONでもCSVに変換できるライブラリを作成
    • メタデータと共にCSVとして出力する
      • 値の部分が配列なら、ヘッダーは「キー」表記にする
    • 配列が複数含まれてネストすると構造が分かりにくい
      • ヘッダーが「キー1.キー2[]」のように複雑化する
      • 「キー[id]」の列を設けてidを明記することで対応
    • メタデータが複雑化すると手書きでは面倒

LT5: 運用と開発が同時並行で進んでいるRailsアプリケーションをDocker対応した事例について

gremito #ものラジ CSM® フリーランス (@grem_ito) | Twitterさんによる、RailsアプリケーションのDocker対応についての話。
Windowsへの導入で苦労する話、私もWindowsにDockerを入れるのは諦めた事があるので色々共感が……
Dockerネットワークの話はdocker-composeとネットワーク、コンテナのホスト名の割り当てなどを理解する - Qiitaが個人的には分かりやすかったです。

  • 開発環境をDockerへ移行するメリット
    • サーバーの環境統一
    • メンテナンスが楽
    • 1回で適用できる
    • 開発からデプロイがスムーズにできる
  • デメリット
    • 本番やステージング環境には採用しづらい
    • Windowsユーザーへの導入は更に一苦労する
  • 今までのローカルに環境を構築することとのトレードオフ
    • 環境構築がコード化されるため、管理コストは下がるが学習コストが必要になる
    • 新しいツールを使うことによって、開発メンバーのスキルアップが出来るが学習コストは上がる
  • Dockerを使った目的
    • ローカル環境の統一化
    • 容易な検証環境の入手
  • RailsのDocker環境構築
    • Dockerの公式にRails環境構築のクイックスタートがある
    • 0から構築すると覚えやすい
  • 落とし穴と沼
    • GitHubや独自ドメインからのgemインストール
    • 連携アプリ、モジュールのコンテナ化
      • コンテナ化した場合、RailsアプリでアクセスするためのURL等の設定をDockerネットワークのドメインに書き換える必要がある
        • Dockerネットワーク内では、コンテナ名がホスト名になる
        • 最初にこれに気づかなくて、エラーが出た

LT6: 世界中のフロントエンダーの残業時間を減らす、新しいフロントエンドフレームワーク

悉生 游漩 (@StewEucen) | Twitterさんによる、新しいフロントエンドフレームワーク「Ma_gician（仮称）」を開発している話。
ライブコーディングでVue.jsでのコードからの変更を見せてもらったのですが、たしかにコード量はぐっと減ります。
状態管理や名前空間の機能を備えていて、属性の値にjsvascriptのコードを書いて実行させたり、外部HTMLを組み込む使い方も出来るようです。

  • ポイント
    • 極端に少ないコード量で記述できる
    • 依存ライブラリを少なくする
    • フルスクラッチ
  • ライブコーディングで見た機能
    • 状態管理
    • 名前空間
    • Nested Computed
      • タグの属性の値としてJavascriptを書いて実行できる
    • HTML Imports
      • 別のHTMLファイルを指定位置に取り込むことが出来る、テンプレート的な機能
    • Fallback
      • 指定した画像が見つからない時に予め指定した画像を表示する事ができる

LT7： WEBエンジニア歴2ヶ月で躓いたエラー10選

チャパタイ (@J8Ilr1HGmm6Oe3n) | Twitterさんによる、WEBエンジニアを始めて2ヶ月で遭遇した失敗やエラーとその対応の話。
新人時代に思い当たりがありすぎてうんうん、とうなずきながら聞いていました。
主にPHPのLalabelで開発されているということで、その周りの話が多かったです。

  • 質問するタイミングが分からない
    • 15～30分程度考えても分からなかったら質問する
    • slackなどであらかじめ調べたサイトの情報を共有して、質問しやすい雰囲気作りをしておく
  • チュートリアルが間違っている
    • まずは疑う
    • GitHubに実際のコードがある場合はそちらを確認する
    • 公式ページを確認する
  • どこでつまづいていたか忘れる
    • 参照していたサイトは一旦どこかにメモする
  • エラーが出ているか分からない
    • エラー文を読む
  • 権限エラーで動かない
    • sudoかchmod使えば大体解決する
  • ディレクトリやnamespace,useキーワード周りでエラーになる
    • composer installで足りていないものをインストールする
  • マイグレーション時に失敗する
    • migration fresh, migration refreshコマンドを実行すると上手くいく
  • Seeding（LalabelでDBへテストデータを配備するコマンド:Database: Seeding - Laravel - The PHP Framework For Web Artisans）で失敗する
    • テストデータと投入先のテーブルの対応する列の型が合っていないことが多いので、テーブルのチェックをしてテストデータの型を合わせる
  • Apacheの設定を変更したけど反映されない
    • httpd.confを編集した場合は、Apacheを再起動する
  • モチベーションについて
    • 伸び代があるなと思う

LT8：Pulumiで環境作成を自動化する

もふ (@mov_vc) | Twitterさんによる、Pulumiで環境作成を自動化した話。
プロビジョニングツールにはTerraformを始めとして色々ありますが、これはかなり新しく、開発が活発。
また、Pulumiのアドベントカレンダーもあるそうなので、使われている方は参加してみると良いかもしれませんね。

  • 環境作成の自動化
    • 開発環境の占有をしたい事が多い
      • 開発チームがスケールアップすると、同時に開発環境もスケールアップするので作成が大変
  • トイル（繰り返しの手作業）を撲滅したい
  • 今のトレンド：リポジトリにPushすると自動的に環境作成を実行
  • CIに環境作成をさせる
    • CIの中でAWS/GCPのAPIを叩く
      • インフラコードが大量になるので、コード化しないと辛い
  • Pulumi
    • 汎用言語が使えるIac Provisioning Tool
    • 使える言語は以下の言語
    • Web UIがイケてて分かりやすい
    • 主要なクラウドプロバイダには全て対応済み
    • 開発が活発
      • 結構な勢いでIssueの修正とプルリクの反映が行われてバージョンアップする
        • スライドを作成している最中にもバージョンが上がったので、スライドのバージョン表がちょっと古くなってしまった
      • slackコミュニティでは開発者たちと気軽に話せる
    • CLI configによるSecretの管理が強力
      • configでSecretを設定し、コード内で変数のように使用できる
    • CIとの連携、インテグレーション機能
      • Cycle CIではorbが提供されている
    • ブランチ名をパースして利用しないといけない
      • イメージタグ
      • デプロイ先の選択
    • CIユーザにAdmin相当のクラウド権限が必要
    • リソースのレイヤー切り分けが必要
      • 全環境で必要なもの
      • 開発環境だけで必要なもの
      • ブランチ単体で必要なもの
    • Pulumiのアドベントカレンダーやってます！

感想

  • WEBと一言で言っても色んな事をされている方がいるので、LTの幅が広くて面白い
  • 知らない単語や言葉が出てくると、「これはなんだろう？」と興味が湧く
    • アウトプットする時にも調べると結構色々分かります