GameWith Developer Blog

GameWith のエンジニア、デザイナーが技術について日々発信していきます。

ツール開発で firestore を初めて使って感じた利点と、ハマった落とし穴 #GameWith #TechWith

こんばんは✋

@peka3 です。 ヘムロックがお気に入りです。

ブログは久しぶりに書きます。

最近は攻略ツールを開発をしております。

先日、あつ森でのアイテムを交換するためのツール「あつ森交換掲示板」を作りました。

フロントエンドは GameWithDesignSystem を使っています。 こちらについては以前の記事に詳しく載っているのでぜひ読んでみてください。

tech.gamewith.co.jp

実装側としては Vue + TypeScript で Webコンポーネントを実装していくことになります。

そしてバックエンドなのですが、今回はすべて firestore で実装しました。

firestore については、RDB脳だとハマりどころが多かったので、今回はこちらを詳しく紹介できればと思います!!

まず最初に、あつ森交換掲示板の機能をざっくり紹介いたします。

よくあるスレッド型掲示板とそれほど違いはないので、読み飛ばしていただいても大丈夫です。

あつ森交換掲示板の紹介

あつ森交換掲示板 | あつまれどうぶつの森 - GameWith

一覧画面

f:id:peka3:20201204190004p:plain:h100
あつ森交換掲示板 一覧画面

現在の取引募集を一覧で見ることができます。 アイテムを選択して、検索をすることができます。

投稿画面

f:id:peka3:20201204191730p:plain:h100
投稿画面

欲しいアイテム、譲れるアイテムを選択して投稿します

詳細画面

f:id:peka3:20201204192204p:plain:h100
詳細画面

投稿主に対して、コメントすることができます。 この画面で交換のやり取りが行われます。

アイテム選択モーダル

f:id:peka3:20201204200802p:plain:h100
アイテム選択モーダル

アイテム一覧から様々な条件で絞り込み、アイテムを選択する画面です。

firestoreでのデータの持ち方

今回作ったコレクションは3つになります。

  • アイテム情報
    • アイテム名、サムネイル等
  • 取引情報
    • 欲しいアイテム、譲るアイテム、投稿ユーザーの情報等
    • サブコレクションで 返信情報 も保持しています
  • 削除ログ
    • 規約に反した投稿を削除した際のログ

firestore での DB 設計の勘所

firestoreで大事なところとして 「なるべく1つのコレクションに画面を出力するのに必要なすべてのデータを格納する」 というのがあると思いました。

firestore には join がない

まずfirestoreはjoinがありません。

RDBですと、取引情報には、欲しいアイテムのアイテムID、譲るアイテムのアイテムIDだけ格納し、 実際に画面でアイテム名が必要になったらjoinによってアイテム名を取得してくる、という流れになると思いますが、

firestoreでそれをやろうとすると、joinがないためアイテムID一つに対して1回読み取りクエリを投げることになります。 パフォーマンス的にも料金的にも、とても非効率なります。

そのため、今回は取引情報のなかにアイテム名やサムネイルURL等、画面の描画に必要なデータをすべて盛り込みました。

firestoreの便利だったところ

https://firebase.google.com/docs/firestore/query-data/queries?hl=ja#array_membership

firestore には array-contains 演算子というものがあります。

これが今回の「欲しいアイテム」「譲るアイテム」から特定アイテムを検索する、という要件にぴったりと合致しました。

「欲しいアイテム」と「譲るアイテム」は複数設定できます。 それぞれのアイテム名を配列で持つフィールドを用意し、そこに対して array-contains で where することで、一発で検索できるようになりました。

コード例:

wishItemTradesRef = itemTradesRef.where(
    "items",
    "array-contains",
    selectedItemNames
);

firestoreでの論理削除は非効率

firestoreでも論理削除をすることもできますが、削除フラグを持ってしまうと、削除フラグを含めた複合indexをたくさん作る必要がでてきます。 firestoreはindexも課金対象であるため、できれば避けたいです。

今回の要件として、削除された対象のログをあとから追跡できれば良かったので、削除したログを残すコレクションを別途用意し、取引情報のほうは物理削除することにしました。

firestore で、複数条件での検索、ソートが必要になったら要注意

whereによる範囲比較、orderByによるソートは、同一のフィールドを指定しないと動きません。

たとえば年齢10〜20歳の人で、かつ男性を上位に表示する、というようなクエリは発行できません。 年齢10〜20歳の人で、年齢の昇順に表示する、なら可能になります。

// これはエラーになる
usersRef.where("age", ">", 10).orderBy("gender");

// これはOK
usersRef.where("age", ">", 10).orderBy("age");

これは firestore 特有の制限ですね。

今回はこれを知らずに仕様を決めていたため、あとで調整が必要になりました。

要注意ポイントです。

(前述の array-contains は範囲比較に該当しないため問題なし)

以下、公式ドキュメントへのリンクです

firestore ではセキュリティルールを書く必要がある

firestoreのconsoleからセキュリティルールを書くことができます。

これはバリデーションのようなものであり、これを書かないと、どんな内容でもクエリを受け付けてしまいます。

セキュリティルールを書くことによって、フィールドに対して型を縛ったり、READ/WRITE制限をかけたり、このフィールドのみUPDATE可能にする、というようなこともできます。

セキュリティルールは詳しく書くとこれだけで結構なボリュームになるので割愛します。

まとめ

ちょっと要件が複雑な掲示板でしたが、 firestore のみでバックエンド問題なく実装ができました。

firestore 単体で実装がすむと、API開発をしなくてよい、APIサーバの運用を考えなくてもよいという圧倒的メリットがありますね!

ただ、利用には一癖二癖あるので、何度かfirestoreの実装を経験しないと、工数見積もりなどを正確に出すのは難しそうだと感じました。

しかしAPI開発を一切せずにこういったツールが作れるとなるとは…どんどん便利になってエンジニアとしては嬉しいかぎりですね。

firestore には未来を感じるので、これからも経験を積んでいきたいなぁと思いました。

それでは失礼します👋

GameWith Advent Calendar 2020 の他の記事もよろしくおねがいします!

qiita.com

チームの案件管理方法・モブ設計・モブ見積もりの紹介 #GameWith #TechWith

はじめに

こんにちは。GameWith のエンジニアの tiwu です。

このブログはアドベントカレンダーの4日目のブログになります!

qiita.com

今回はチームで行っている、案件の管理方法や、モブ設計・モブ見積もりについて紹介したいと思います!

案件の管理方法

自分が所属しているチームでは案件を Spreadsheet と GitHub Issue で管理しています。

それぞれ下記のような使い方をしています。

  • Spreadsheet
    • 主にエンジニア以外の人が利用する
    • 案件の概要や効果、優先度、工数などを記述する
      • 工数はエンジニアが入力
      • GitHub Issue へのリンクも記述しています
    • 表で並んでおり他の案件と比較がしやすく、優先度の決定や並び替えが容易にできます
  • GitHub Issue
    • 主にエンジニアが案件の技術的な内容を記述するために利用しています

開発当初は GitHub Issue だけで案件を管理していましたが、他の案件との比較や概要などが一覧で見辛かったので Spreadsheet を導入し、重複していますが2つのツールで管理しています。

モブ設計

案件の技術的な設計はエンジニアで集まり、モブ設計を行っています。

現在は Google Meet でリモートモブ設計をしています。

  • 「設計 vs 個人」ではなく「設計 vs チーム」という体制
  • 三人寄れば文殊の知恵
  • 互いの持っている知識の共有

あたりが意図としてあります。

モブ見積もり

モブ設計の後はモブ見積もりをしています。

こちらもモブ設計と同じような意図で実施しています。

モブ設計は Hatjitsu というツールを利用しています。

hatjitsu.toolforge.org

f:id:tiwu:20201204151550p:plain

このツールはシンプルでかなり使いやすく重宝しています!開発者の方々、ありがとうございます!

見積もりは時間ではなく、相対的なポイントで見積もっているため、 Hatjitsu とも相性が良いです。

終わりに

モブ設計やモブ見積もりはチームで協力し、チームが成長できる良い施策と考えています!

ですが、現状に満足せず課題があれば Spreadsheet を導入したようにチームで変化し、より良く変わっていけるようなチームを目指して行こうと思います!

ツイッター

ブログの更新情報などを呟いています!

twitter.com

2020年 GameWith の技術広報の1年間の振り返りとこれから #GameWith #TechWith

こんにちは。GameWith のエンジニアの tiwu です。

今年も始まりましたアドベントカレンダー!

1発目のブログは今年1年間の技術広報活動を振り返っていこうと思います!

qiita.com

Blog

今年(2020年12月1日時点)の投稿数は 17 本でした!

去年が 55 本だったので、約3分の1の投稿数になります。

PV は2万2千ほどになります!去年は3万3千ほどだったので、投稿数は3分の1ですが、PVは3分の2くらいになっています。

f:id:tiwu:20201126180437p:plain
2020年のPVの推移

f:id:tiwu:20191205144635p:plain
2019年のPVの推移

ちなみに今年1番PVの多かった記事はこちらの記事でした!

tech.gamewith.co.jp

リモートペアブログ・モブブログという新たな試み

弊社はフルリモートワークを実施しているので、今まで行っていた顔を突き合わせてのペアブログ・モブブログは実施できなくなりました。

ペアブログ・モブブログ自体は去年から月に1回開催をしており、フルリモートワークになっても月1の定期的な開催を行っています。

フルリモートワーク環境では Google Meet でビデオ会議を行い、VSCode Live Share を利用して執筆作業を行っています!

詳しくはこちらの記事を御覧ください。

tech.gamewith.co.jp

もくもく会

フルリモートワークになるまで、もくもくを月に1回開催していました!

参加していただいた方ありがとうございました!

カンファレンスへのスポンサー

今年は2月に開催された PHPerKaigi 2020 に協賛をさせていただきました!

ツイッター

去年からTwitterアカウントの運用を始めました!

twitter.com

ブログの告知が主なつぶやき内容になっています!

振り返り

フルリモートワークになってからは、主にペアブログ・モブブログが主な活動になりました。

数は減りましたが継続的にアウトプットができ良かったと思います!

フルリモートワークになっても定期的なアウトプットや広報活動を続けることができたのは、技術広報の活動に携わっていただいた方々やブログを見ているユーザー、サービスを利用しているユーザーのおかげです!ありがとうございました!

来年も継続的に、アウトプットしていくのでよろしくおねがいします!

GameWith の 手動テスト方法について #GameWith #TechWith

はじめに

こんにちは!GameWith QAエンジニアのIです!

今回のブログは GameWitfh で実施している QA について書いていきたいと思います。

QAとは

Quality Assurance の略で、プロダクトの品質を保証するための業務全般を行なっています。

企業やプロダクトによってチームがあったりなかったりその体制はまちまちですが、GameWith では開発部にQAエンジニアが所属しています。

自動テストと手動テストを併用していますが、今回は手動で行っているテストについて紹介していきたいと思います。

行なっている手動テスト

大きな開発や難易度が高いと思われるテストはQAエンジニアが実施します。

JSTQB(Japan Software Testing Qualifications Board)のテスト7原則でも言われている通り、 テストはやろうと思えば無限に行うことができ、また不具合が0であると証明することはできません。
参照:テスト7原則(Foundation Level シラバス 日本語版 Version 2018V3.1.J02より)
http://jstqb.jp/dl/JSTQB-SyllabusFoundation_Version2018V31.J02.pdf

当然リリースまでの期日も遵守しなければなりません。

その中でどのようなテストを行うのが効果的でよりリスクを下げられるのかテストの設計を行い、 それを元に実際のテストケースに落としていきます。

テストケースはExcelなどのスプレッドシートを用いて管理している場合も多いかと思いますが、 GameWithではGitHubのIssueにMarkdownのtasklist方式で記載を行い、チェックをつけています。

f:id:t_iwsk01:20201124163441p:plain
テストケースの例

この方法はプロダクトの仕様に理解があることが前提にはなりますが、 冗長な条件や手順の記載を避けることで、テスト観点(意図)が端的に伝わるテストケースに仕上げることができます。

結果的に開発担当エンジニアのレビューへの負担を軽減する効果も見込めます。
(別ドキュメントにしたり文章量が増えるとどうしても確認の工数が増え、結果的に目も行き届かなくなります)

テストが可能になり次第、あらかじめ策定した環境にてテストを実施するのですが、 ここでも経験をベースにテストケースの行間を読んだり、仕様の変更などに対して柔軟に対応していきます。

事前の準備は行いますが、全体的にはいわゆる経験ベースの探索的テストに近い部分もあります。

以下はJSTQBにおける探索的テストの定義です。
(JSTQB-Syllabus.Advanced_TA_Version2012.J01より)
http://jstqb.jp/dl/JSTQB-SyllabusFoundation_Version2018V31.J02.pdf

「探索的テストには、テスト担当者がプロダクトとその欠陥の学習、完了すべきテスト作業の計画、テストの設計と実行、および結果の報告を同時に行うという特徴がある。
 テスト担当者は、テスト実行時にテスト目標を動的に調整し、軽量のドキュメントのみを準備する」

こうしたフローを採用することで、1サイクルの短い開発にも素早く効率的にテストが行えるようにしています。

すべてのテストをQAエンジニアが行うわけではない

各プロジェクトの内容によっては、開発を担当したエンジニアに直接テストケースの作成や実施を行ってもらう場合もあります。

GitHubのPull Requestに、エンジニアが開発機能に対するテストケースを記載

QAエンジニアにメンションをつけてレビューを依頼(通知が飛ぶ)

QAエンジニアでレビューして足りない項目がないかを確認し、必要であればテストケースの加筆修正を行なってもらう
という流れです。

こうすることでエンジニアに「開発とテストはセットである」という意識を身につけてもらい、 品質への意識を高く保ってもらうという狙いがあります。

「テストや品質の責任はQAエンジニアのもの」という意識が根付いてしまうと不具合の作り込みも増え、 実際にプロダクトの品質が低下することに繋がってしまう恐れがあります。

使用するユーザーのことを想像したり、より良いプロダクトを提供しようという意識は大切なものです。

QAエンジニアはこういった品質に対する在り方の提案も行なっています。

おわりに

冒頭でQAは企業やプロダクトによってあったりなかったり、体制が異なると書きましたが、 所属する人や業務のフロー、使用しているツールなどにもよってもいろいろ条件が変わってくるため、「これが正解」と言った形は存在しません。

QAエンジニアは品質を担保することももちろん大切な業務ですが、 既存のやり方にとらわれず、プロダクト開発におけるQAの在り方をリードしていくことも大きな役割だと考えています。

今後もそのために尽力していきたいと思います!

GameWithのDeveloper向けTwitterアカウントも開設しています。
良かったらフォロー宜しくお願いします!

twitter.com

GameWithのリプレイスについて vol.3 ~俺たちは Shadow DOM で Micro Frontend の理想を追う~ #GameWith #TechWith

はじめに

こんにちは!Incremental Stream Team の @53able です!

GameWithのリプレイスについて第3回目の記事である今回は、 GDS(GameWith Design System) の根底にある方針や考え方について書いていきたいと思います。

前回の記事はこちらから御覧ください

tech.gamewith.co.jp

GDS が目指しているもの

GDS は前回のブログでも書いたように、下記のような世界を目指しています。

  • どんなプロジェクトでも簡単に利用できるHTMLコンポーネントの提供
  • 将来的にデザイナーも UI/UX 改善に利用できるようにしたい
  • 将来的にエコシステムを OSS として公開したい

どんなプロジェクトでも簡単に利用できるHTMLコンポーネントの提供

GDS では Web Components というWeb標準技術を利用して、HTMLコンポーネントを提供しています。

Web フロントエンド アプリケーションを開発する際に考えられるのは Vue や React や Angular などといったフレームワークがあげられます。

これらのフレームワークで開発を行った場合、例えば Vue を採用した際に、React のアプリケーションにコンポーネント提供した場合かなり困難であると考えられます。

そのため、Web 標準である Web Components のコンポーネントモデルを導入することで、様々なフレームワークで書かれたコンポーネントアプリケーションを開発していくとにしました。

Web Components について

提供をしている Web Components は自己完結型です。

そのため、コンポーネントは他のコンポーネントに影響を与えることなく修正し、アップグレードしていくことが可能です。

GDS は僕たちのチームで構築をし開発を行いましたが、ドメインの異なるチームでも積極的に利用をはじめています。

今までの GameWith の開発サイクルやリリースの仕組みなどと分離されているため、他のチームでも利用しやすいです。

例えば あつ森 (あつまれどうぶつの森) 攻略記事でリリースしたツール は GDS を利用して、攻略記事チームが開発をしました。

gamewith.jp

このあつ森のツールは GameWith というアプリケーション内にある、独立したフロントエンドアプリケーションのような動きをします。

以上のことから今後もGDSをGameWithサービス内でスケールさせていきたいと考えているので、このアーキテクチャによるメリット/デメリットを上げておきます。

メリット

  • iframe のような強力な分離。ネームスペーシングは不要です
  • グローバルスタイルが Micro Frontend に影響されないです。既存のアプリケーションとの連携が安全なので、追加的実装に最適です
  • CSS に関して ツールチェーン の必要性を減らせる可能性があります
  • フラグメント(Web Components)は自己完結型です。個別の CSS ファイルの参照はありません

デメリット

  • 古いブラウザではサポートされていません。ポリフィルは存在しますが、重くて、経験則に基づいた実装になっているため、根本解決にはなりません
  • 動作するには JavaScript が必要です
  • プログレッシブエンハンスメントはありません
  • サーバーサイドレンダリングは今、 Declarative Shadow DOM という仕様が策定されており将来的に気軽にできるようになるかもしれませんが、まだ一般的はないようです
  • 異なる Shadow DOM 間で共通のスタイルを共有するのは難しい
  • Bootstrap のようなグローバル CSS クラスを使用するスタイリングアプローチでは動作しません

デメリットへの解決策

GDS では @vue/web-component-wrapper を介して Vue の SFC 内で共通のスタイルを import しています。異なる Shadow DOM 間でのスタイルは、SFC をビルドすることによって共有可能となっています。

Web Components の各種ライフサイクルは、Vue のライフサイクルによって紐付けられているので、 Web Components の実装のソリューションが実現できています。

github.com

今後について

GDS が目指しているのは「どんなプロジェクトでも簡単に利用できる HTML コンポーネントの提供」です。

そのため、より中立的な Web 標準の技術を利用していくのを追求していきたいと思います。

現在の GDS から 提供される Web Components は、複数の Vue SFC をまとめてビルドするので、まだまだ粒度が大きいコンポーネントとなっています。

例えば、ボタンなどは Vue の SFC として存在していますが、ボタン自体が Web Components として提供されているわけではありません。

今後は、ボタンなどといった汎用的な細かいコンポーネントも Web Components として提供することで、Micro Frontend 化を進めていきたいと思います。

さいごに

GameWithのDeveloper向けTwitterアカウントも開設しました。
良かったらフォロー宜しくお願いします!

twitter.com

TypeScript と aspida で型安全に Vue.js の開発をしている話 #GameWith #TechWith

はじめに

こんにちは! GameWith の kuromoka です!

今回のブログでは、GameWith のダッシュボードの開発に、aspida という API のリクエスト/レスポンスに型を付与するライブラリを導入した話を紹介したいと思います。

ダッシュボードのフロントエンド環境については、Vue.js + TypeScript を導入しています。以下の記事も合わせてご参考ください。

tech.gamewith.co.jp

課題

前述の通り、GameWith のダッシュボードは Vue.js + TypeScript を導入しています。これまで API にリクエストするときは axios を使って以下のように書いていました。

async getPostData(): Promise<any> {
  const response = await axios.get('/api/post');
  return response.data.post;
}
async postPostData(title: string, text: string): Promise<any> {
  const response = await axios.post('/api/post', {
    title: title,
    text: text
  });
  return response.data.post;
},

この書き方には、以下のような課題があります。

  • URL の文字列部分を typo しても TS のコンパイルは通ってしまうため、実行するまで間違いに気づくことができない
  • 関数名と API のリクエスト先が紐付いていないため、関数名からどこにリクエストしているか分かりづらく、また API の種類が増えていくと命名に悩む
  • レスポンスの型を any にしているため、型安全なコードでなくなっている

これらの解決方法として、今年の3月に行われた Roppongi.ts #1 のセッションの1つに aspida を利用している話があり、そこで初めて aspida を知りました。

ちょうど今回の課題を解決するのに、aspida が利用できそうだったので導入することにしました。

aspida とは

github.com

aspida を使うと、以下のようなことができるようになります。

  • API のリクエスト/レスポンスに型を付与できる
  • API のリクエストを文字列ではなく、プロパティ経由で行えるようになる

aspida を作成した方の記事もあるので、こちらもご覧ください。

qiita.com

使い方

プロジェクトのルートに aspida の設定ファイル aspida.config.js を作成して、以下のように設定します。今回は dashboard/apis 以下を aspida の定義ファイルを置くディレクトリに指定しています。

module.exports = {
  input: 'dashboard/apis'
};

aspida ではディレクトリ構造と定義ファイルの名前が、そのままAPIのリクエスト先になるイメージになります。

たとえば dashboard/apis/api/post/index.ts に以下のような定義ファイルを書いた場合、 api/post で GET リクエストを送信するための定義になります、

dashboard/apis/api/post/index.ts

export interface Methods {
  get: {
    query?: {
      page: number;
    };
  
    resBody: {
      posts: {
        id: number;
        title: string;
        text: string;
      }[];
    };
  };
}

aspida では API 定義をした後に、以下のコマンドでビルドする必要があります。

$ aspida --build

ビルドすると$api.tsというファイルが生成され、今回の場合 dashboard/apis/$api.ts にファイルが生成されます。

あとは以下のようなコードで axios で aspida を使って、API リクエストを送ることができます。

import axios from 'axios';
import aspida from '@aspida/axios';
import api from './apis/$api';

const client = api(aspida(axios));

(async() => {
  const response = await client.api.post.$get({
    query: {
      page: 1
    }
  });
  response.posts.forEach(post => {
    console.log(post.id);
    console.log(post.title);
    console.log(post.text);
  });
})();

VSCode で確認すると、リクエスト/レスポンスの部分に、先ほど定義した型が付与されていることが確認できます。 f:id:kuromoka16:20200928183757p:plain

そのためプロパティ名が間違っていたりすると、エラーになるため間違いに気づくことができます。 f:id:kuromoka16:20200928185438p:plain

また URL にリクエストパラメーターが含まれる API の場合は、ファイル名に_から始まる変数名と@の後に型を指定します。型は numberstring の2つが指定できるようです。

以下は ID を指定する API で、api/post/1のような URL に DELETE でリクエストをするAPIになります。

dashboard/apis/api/post/_id@number.ts

export interface Methods {
  delete: {
    resBody: {
      status: 'failed' | 'success';
    };
  };
}

これを使う場合は以下のようになります(リクエスト部分のみ)。

(async() => {
  const response = await client.api.post._id(1).$delete();
  if (response.status === 'success') {
    console.log('success!');
  }
})();

IDは number のため、たとえば _id() の部分で string を送ろうとすると、エラーになります。 f:id:kuromoka16:20200928191130p:plain

テストコードの書き方

テストコードは Jest で書いています。aspida の部分のテストは、以下のように aspida のモックを作ってテストコードを書いています。

モックのデータ生成時に型補完を効かせるために、aspida から型情報を取得して利用しています(type PostTypeの部分)。

type PostType = ReturnType<typeof client.api.post.$get> extends Promise<infer T> ? T : never;
const mockPost = jest.spyOn(client.api.post, '$get');
const mockValue: PostType = {
  posts: [
    {
      id: 1,
      title: 'title 1',
      text: 'text 1',
    },
    {
      id: 2,
      title: 'title 2',
      text: 'text 2',
    },
  ]
};

// コンパイルを通すために any にしております・・・・・・
mockPost.mockReturnValue(mockValue as any);

// fetchPost 内で client.api.post.$get を実行している
const data = await fetchPost(1);

// ID = 1のデータをテスト
expect(data[0]).toEqual(mockValue.posts[0]);

今は aspida-mock というライブラリがあるらしく、これを利用することで今より楽にテストコードを書けそうなので、利用してみたいと思っています。

github.com

メリット/デメリット

apisda を使うことで、以下のようなメリットがあると感じました。

  • ディレクトリ構造がそのままリクエスト先になるため、分かりやすい
  • APIへのリクエストがプロパティ経由で書けるためコード補完が効き、またリクエスト/レスポンスともに型情報が補完されるので書き心地が良い
  • aspida は日本人の方が作成しているので、日本語のドキュメントがある

デメリットは GitHub のドキュメントは充実していますが、まだまだ利用例が少ないため、例えばテストコードを書くときなどに少し苦労しました。

終わりに

API 側とフロント側での型定義は連携が取れていないので、現在はそれぞれに型定義ファイルが存在しています。今後 Open API を使うなどして、二重管理になっている型定義を共通化していきたいと考えています。

またデメリットの部分でも書きましたが、aspida はまだ利用例が少ないと思っていますが、便利なのでもっと普及していってほしいと思ってます。

他のサービスでは今回のような場合にどのように管理しているか気になっているので、よければ Twitter でリプライなどいただけるとうれしいです!

Twitter

GameWithのDeveloper向けTwitterアカウントも開設しました。
ブログの更新情報などを発信するので良かったらフォロー宜しくお願いします!

twitter.com

VSCode Live Share がとても良かった話 #GameWith #TechWith

はじめに

こんにちは! リプレイスチームの @53able, @inosy22, @nog です!

今回は VSCode Live Share 使ってみたので感想など書いていきたいと思います!

使ってみたきっかけ

リプレイスチームでは、”開発で困ったらペアプロ(モブプロ)で解決する” という取り組みを行っています。

今までは Google Meet で画面を共有しながら、VSCode を表示して、Meet のチャットでコードを送ったりしてペアプロを行ってきました。

オンライン上でペアプロ(モブプロ)をしているときに、チャットでコードを送ったり、そのコードを口頭や文章で補足したりするのが全員がリモートだと特に非効率だったので利用してみました。

VSCode Live Share とは

docs.microsoft.com

ホストの VSCode のプロジェクトを共有して、リアルタイムで他のユーザーと共同で編集などができるツールです!

ホストの VSCode をリモートコントロールしている感覚に近いです。

できること

Share できるのは、プロジェクト内のファイル操作 or ターミナル操作ができます。

また、VSCode 内でチャットができます。

Participants でユーザーにチェックをつけるとそのユーザーの操作を追従するモードになり、カーソル位置や開いているファイルなどの操作を追従するようになります。

この追従の仕組は最初使い方がわからなかったのですが、共同編集をしているユーザーにチェックを付けて追従を開始することで、チェックしたユーザーの作業箇所にジャンプができ、並行して作業をしても迷子になることはなかったです!

ちょっと作業をして悩んだときに、他の人を今作業しているファイルに集まりやすくとても便利でした!

f:id:tiwu:20200821165209p:plain

導入手順

インストール

まずは plugin を インストールします。

marketplace.visualstudio.com

f:id:tiwu:20200821164950p:plain

アカウントの紐付け

Microsoft か Github アカウントでログインをします。

f:id:tiwu:20200821165028p:plain

Share 手順

URL を発行して共有することで Live Share ができます。

f:id:tiwu:20200821165122p:plain

実際に使ってみた

このブログを VSCode Live Share で書いてみました!

今までモブブログは google docs の共同編集を使っていました。

f:id:tiwu:20200821165307p:plain

良かった点

  • 状況により並行して開発を行えたり、柔軟にコミュニケーション取りながら開発ができるため、効率的に作業が行える
  • 口頭でファイルや行の指示するのではなく、追従の仕組みを使って自分が実際にファイルを開き共有ができるので、スムーズにコミュニケーションがとれる
  • 吹き出しの様なものでカーソルが表示されるので、誰が今どのファイルの何行目を修正しているか見やすい
  • ブラウザ上でも Live Share の共有ができるので、 VSCode をインストールしていない人でも共同作業ができる

難しかった点

  • ホストがエディタを再起動すると、作業が中断する
  • .gitignore に追記しているものは共有されず node_modules などが登録されていると、ゲスト側は node_modules が見えず補完が効かない
  • 同時に同じ箇所を修正していると、編集した箇所が消えたりして、操作の衝突があったりする
  • 共有されるのは VSCode なので、コード以外のブラウザの共有などのため Google Meet で画面共有は別途行った

まとめ

導入も簡単で、共有を受ける側も簡単にできるのでとても使いやすかったです!

以前のように、Meet で VSCode の画面を共有してペアプロをするより遥かに効率的でした!!!

ありがとう VSCode! ありがとう Live Share!

他のエディタにも同様な機能があると嬉しいな・・・!

Twitter

GameWithのDeveloper向けTwitterアカウントも開設しました。
もくもく会の告知やブログの更新情報などを発信するので良かったらフォロー宜しくお願いします!

twitter.com