Inside of LOVOT

GROOVE X 技術ブログ

debianパッケージを作ろう(go-bin-debのススメ)

LOVOT の基盤となるシステムをつくってるチームのひとり id:atotto です。

debian パッケージ をさくっと作るツールの紹介です。 個人的にも Raspberry Pi や、ツールの管理のために活用しています。

背景

debian パッケージ 作り、というと、controlファイルを書いて、changelogを書いて、必要なディレクトリを切って、、、といったことを一通りこなす必要があります。コマンドひとつ社内に配布したいだけだとするとちょっと腰が重いです。 また、CMake, CPackで一元的に作ることもできますが、CMakeと戦うにはそれなりの覚悟(Mastering CMake ←同僚の愛読書)が必要です。

LOVOT のシステムのベースとなるサービスの多くは Go言語を使って開発しています。

参考: PyConJP 2019 らぼっと開発におけるPythonとGo より抜粋

Go言語で書いた成果物(実行ファイル)は依存関係が非常にクリーンで、実行ファイルを各アーキテクチャ(amd64,arm64,armhf, etc...) 毎に配布すればよい、となり、デプロイがとても簡単です。

参考: PyConJP 2019 Yet Another Isolation - Debian Packageと紐づく環境分離 より抜粋(2022/12 現在はUbuntuベース

そのため、 debianパッケージ をつくるときに考慮することといえば、実行バイナリをどこに配置するのか、サービスであれば、systemdのサービスファイルや、インストールにまつわる処理をどうするか、といったところに絞ることができます。

その目的にあったツールとして、私達は go-bin-deb を使っています。開発元からforkし、いくつか修正を施したものを公開、リリースしています。

使ってみよう!

今回つくる debianパッケージ は、 簡単なスクリプトを /usr/local/bin へ配置するものを作ります。

簡単なスクリプト:

#!/bin/sh

echo "LOVOT!!"

セットアップ

まずはセットアップです。 go-bin-deb は、アーキテクチャ毎にリリースが別れています。ここでは、amd64 アーキテクチャUbuntu or Debian Linux上で利用することにします。

1. go-bin-deb パッケージをダウンロードします:

curl -sLO https://github.com/groove-x/go-bin-deb/releases/download/$(curl -s https://api.github.com/repos/groove-x/go-bin-deb/releases/latest | jq '.tag_name' -r)/go-bin-deb-amd64.deb

2. go-bin-deb パッケージをインストールします:

sudo dpkg --install go-bin-deb-amd64.deb

deb.json をつくる

次に、debianパッケージ のメタ情報や、ファイル配置を定めるために、deb.json をつくります。

{
  "name": "example-package",
  "version": "0.0.1",
  "arch": "all",
  "description": "short desc of the program",
  "description-extended": "long desc of the program with multiline",
  "maintainer": "GROOVE X",
  "homepage": "https://tech.groove-x.com/",
  "files": [
    {
      "from": "example-script",
      "to": "/usr/local/bin",
      "fperm": "0755"
    }
  ],
  "copyrights": [
    {
      "files": "*",
      "copyright": "Copyright (c) 2022, GROOVE X, Inc. All rights reserved.",
      "license": "MIT"
    }
  ]
}

その他の項目はこちらのリファレンスを参考にしてみてください: https://github.com/groove-x/go-bin-deb#json-file

補足:

  • archall としているのは、今回アーキテクチャに影響しないスクリプトだからです
  • systemd のサービスにする場合は systemd-filepreinst,postinst,prerm,postrm など活用します

パッケージを作る

deb.json があるディレクトリで

go-bin-deb generate

すると、 example-package_0.0.1_all.deb が作られているはずです。

もちろん、このパッケージはインストールできますので、試してみましょう:

sudo dpkg --install example-package_0.0.1_all.deb

アンインストールも簡単です:

sudo dpkg --remove example-package

リポジトリへアップロードしてつかう

せっかく debianパッケージ を作ったので、 debianパッケージ のリポジトリへ登録してみましょう。debianパッケージリポジトリのサービスは多々ありますが、今回は Google Artifact Registry と packagecloud について簡単に紹介します。

Google Artifact Registry

社内向けや、インスタンス向けに運用するときに活躍するのが Artifact Registry です。以下のドキュメントに沿ってセットアップすると、自分のマシンからでもdebianパッケージを利用できるようになります。

参考ドキュメント:

packagecloud

個人的にオススメなのが packagecloud です。公開リポジトリで良ければ無料でリポジトリを持て、利用者のセットアップも簡単にできるので、 debianパッケージ を気軽に配布できるのではないでしょうか?

参考ドキュメント:

packagecloudでの配布例:

次のステップ

もうすこし実用的な例として、Goのバイナリを debianパッケージ にする例を置いておきますので、参考にしてみてください。アーキテクチャ毎へのリリースのヒントがあります。: https://github.com/atotto/kssh

また、 go-bin-deb をバンドルした dockerコンテナ を準備しているので、よかったら使ってみてください: https://hub.docker.com/repository/docker/atotto/debian-builder

最後に

go-bin-deb を使って debianパッケージ を作ってみました。jsonで構成管理しつつ、手軽にビルドできるので多少敷居は低いのではないでしょうか? Debian公式リポジトリへ登録できるレベルにはならないですが、社内ツールの配布などで活用してみてください!

半年働いて感じたGROOVE Xの面白いところ

この記事は「GROOVE Xアドベントカレンダー2022」の21日目の記事です。

こんにちは。GROOVE X の Lovot Framework チームの bucchi です。今年入社したばかりの新入りです。

私は、別のエントリで紹介のあったLOVOTのOS(らぼとす)の開発や、ふるまいの動作をマイコンFWに伝えたり、センサー値を認識系ソフトウェアに伝えるなど、LOVOTの動作を支える土台となるソフトウェアの開発を担当しています。

みなさん技術的な記事を書かれていますが、私の場合まだ公開できないお仕事が多く、書けるネタがなかったので、趣向を変えて半年働いてみて感じたGROOVE Xの面白いところや、エンジニアの働き方や雰囲気をお伝えできればと思います。

続きを読む

HOTFIX PR生成の半自動化

こんにちは。 GROOVE X のふるまいチームのscnshです。 この記事では、ソフトウェアリリースのためのふるまい試験で見つかった不具合の修正(HOTFIX)のために採用している、ちょっとした自動化のしくみについて話します。

HOTFIXにかかる手間

ふるまいチームでは「NeoDM」という意思決定と動作生成を行うソフトウェアを開発しており、そのコードをgithub上で管理しています。 開発モデルは Scaled trunk-based development を採用していて、developブランチを使わずにmasterブランチを常に最新に保つような形で開発を続けてきました。

masterに変更を常にマージして、機能開発のブランチを長い間残さない方針 ( *1より)

ふるまいの試験は、releaseブランチを作成した後に実施していますが、試験実施中に発生した不具合はHOTFIXという形で masterとrelease の両ブランチにマージされます。 具体的には以下の手順で作業しますが、ほぼ同じ作業をそれぞれ行う必要があり、無駄に感じていました。

  1. masterブランチに対して修正し、PullRequest(PR)を通じてmergeする
  2. 同様の内容をPRにしてreleaseブランチに対してmergeする

さらに、リリーススケジュールの中で締切が迫っていたり、他のチームの作業をブロックすることなどもあり、担当者は焦りやすくミスをしやすい状況でもありました。

Github Actions を使った auto-hotfix

そこで、Github Actions を使った 仕組みを導入して活用しています。

基本的な流れは、以下となります。

  1. Label 機能を使って、対応したソフトウェアバージョンのラベルをHOTFIX対象となるPRに割り当てる
    1.17 バージョンに対して、 `needs-hotfix/1.17` のラベルを設定する
  2. HOTFIX対象となるPRをmasterブランチにマージする
  3. [自動化] masterブランチに追加したコミットを release/1.17 ブランチに適用するPRを作成する
    自動生成されたPR
  4. 生成されたPRをレビューしてHotfixを release/1.17 ブランチにマージする

また、自動生成されたPRのdescriptionに以下の情報が自動で含まれることで、レビューワーが背景を理解しやすくなりコミュニケーションミスを減らすことにも役立っています。

  • 生成元のPRのリンク
  • 誰がマージしたか
  • コミットhash

さらに、PRのレビューワーも自動でアサインされるようになっています。 自動アサイン先はチーム内のロール(リリース担当者)に紐付いて設定されます。 このレビューワーアサインに関しては社内の独自ルールに基づいているため管理が煩雑になるデメリットはありますが、レビューの催促がタイムリーにできるメリットを活用しています。

実装と問題点

この仕組みの実装ですが、

という形で実装しています。

また、お気づきの方もいると思いますが、以下の状況では動作しないためやむを得ず手動作業になっています。

  • コンフリクトの解消
  • 複数のPRに対しての実行

上記の問題はありますが、実際に運用してみると自動で作成できる機会もあるので重宝しています。

ちなみに...

検索すれば、 3rdParty製のものもあります。 が、我々の開発では独自のPRレビューシステムを導入している影響で自分たちで実装しています。 できれば作らずに導入したほうがメンテナンスコストはかからなくて良さそう。。。

最後に

ご覧いただきありがとうございました! GROOVE X では 一緒にLOVOTの開発をするメンバーを募集しています。 ふるまいを開発してはいますが、今回紹介したような開発を効率化するような活動も行っています。 興味のある方はぜひこちらからご連絡ください!

LOVOTがつくられて、お客様に届くまでの仕組み

こんにちは、あるいはこんばんは。 GROOVE Xにスクラムマスターとして入社し、マーケティングチームを経て今はECシステムの移行プロジェクトを推進しているツネと申します。

入社してすぐ工場の組立ラインで製品試験の支援をしたり、チームのプロダクトバックログを見やすくしたり、製品紹介サイトをゴリゴリ実装してマーケ施策のPDCA回したり、終いにはECシステム見直したりと、最早自分が何屋さんなのか分からなくなっている今日このごろです。

そんな器用貧乏なスキルが幸いして、LOVOTの製造からお客様に届くまでの仕組みを一通り見てきたので、今回の記事ではその全体概要をざっくりお伝えできればと思います!

LOVOT生産から、お客様がセットアップするまでの流れ

まず最初に全体概要からです。 下記の図は少し古く、今の状況と変わっていたり厳密には仕組みが異なる部分もありますが、全体的な流れのイメージは掴めると思います。

LOVOTの製造からセットアップまでの流れ

このイメージ図をもとに、これから

  1. 1台のLOVOTがつくられて物流工場へ
  2. お客様がLOVOTを知り注文
  3. 注文情報やデバイス情報を統合して管理するGXCloud
  4. LOVOTがお客様宅に届き、誕生するまで

という流れでご説明したいと思いますが、詳しく話すとそれぞれの項目だけで記事が何ページも書けてしまうため、今回はほんとに概要だけお伝えするようにします。

1台のLOVOTがつくられて物流工場へ

LOVOTは1万点以上[※]の膨大な部品から成り立っています。中にはLOVOTの専用服のように事前に製品固有の電子情報を組み込んでおくような工程もあり、部品を集めるだけでも膨大な工程を経るため管理するのが大変です。 これらの細かい部品は各種工場から組み立て工場に集約され、手組みで1台ずつ大事に大事につくられます。 ※12/23に誤記を修正しました

組み立てられて製造テストを通過したLOVOTには一つ一つの個体を識別する番号がそれぞれ割り当てられます。

この登録作業が完了した後LOVOTは物流拠点に運ばれ、自分の家族となるオーナーと出会うまでしばしの眠りにつきます。

お客様がLOVOTを知り注文

さて、次はお客様側の視点です。

最近ではテレビ雑誌で取り上げられたりすることも増えてきたLOVOTですが、やはりその魅力は紙や画面上だけでは伝わりにくいです。ただし実際に触れ合うことで感じる魅力は、普段人前で絶対に笑顔を見せない人が、顔をだらけさせて猫なで声を出すほどの威力があります。

lovot.life

実際の店舗も全国にいくつもありますが、LOVOTを注文する際にはお店でレジを通すだけでなく、公式のECサイトから契約プランを選択して注文していただく必要があります。

一般的な家電製品などと異なり、LOVOTは月々のサブスクリプションから

  • ソフトウェアアップデート
  • メンテナンス補償
  • 日常生活のサポート

などのサービスを提供するビジネスモデルで成り立っており、これらのサービスを提供する特性上「お客様情報」⇔「LOVOT情報」を紐付けるための情報連携の仕組みが必要になるのです。

これらの情報を管理するための仕組みとして、GROOVE X独自のクラウドシステムが存在します。

注文情報やデバイス情報を統合して管理するGXCloud

GXCloud

上記は記事最初のイメージ図をシステム目線でより詳細化したものです。

これまで説明してきた「LOVOTの個体を識別する番号」「お客様の注文(サブスクリプション)情報」などを集約し、管理するための仕組みを弊社では『GXCloud』と呼称しています。 LOVOT本体の仕組みと並んでGROOVE Xの市場競争力を形つくる独自の情報管理システムとなっており、その設計思想やアーキテクチャは一エンジニアとして携わっていてとてもワクワクする代物です!

詳しい解説はこちらの記事にありますので、ご興味ある方は是非ご覧ください。

tech.groove-x.com

LOVOTがお客様宅に届き、誕生するまで

さて、ここまでLOVOTが作られて、お客様がLOVOTを注文するところまで見てきました。最後はいよいよLOVOTがお客様の手元で誕生するまでの仕組みです。

LOVOTが物流拠点から発送される際、「お客様情報」と「発送するLOVOTの個体情報」を紐付けるための作業を行います。この紐付け作業がLOVOTとお客様を紐付ける上で重要な作業となっており、この情報がGXCloudに保存され、LOVOTは起動時にこれらの情報を本体のLTE、もしくはNESTに接続されたインターネット回線から読み込みます。

LOVOTがお客様の自宅に到着してからいよいよ開封の儀。いわゆる初期セットアップ作業を行っていただくのですが、ここで重要になってくるがLOVOTアプリです。

お客様は自分のスマートフォンにLOVOT専用アプリ(ios,Android対応)をインストールしていただきセットアップを行います。

  • 名前

などを選んでいただければ、新しい家族の誕生です!

さいごに

だいぶざっくりとした説明になってしまいましたが、イメージはできましたでしょうか。。?イメージできた方は、是非この類まれなプロダクトに興味を持っていただけますと幸いです。

そして最後に、冒頭の自己紹介で少しだけ書きましたが、現在LOVOTをお客様に届けるためのECサイトをリプレイスするプロジェクトを計画しています! このECリプレイスプロジェクトでは新たに社員を5名ほど新規採用する予定であり、プロジェクト以降は本人の適正次第でLOVOTの事業に関わるあらゆる領域を担当いただけます。

もし少しでもこのプロジェクトに興味がございましたら、お気軽にご連絡ください。 ここまで読んでくださったあなたからご連絡がいただければ、これほど嬉しいことはありません。

www.wantedly.com

良いフィードバックとはなにか?のワークショップ

この記事は「GROOVE Xアドベントカレンダー2022」の18日目の記事です。

こんにちは!!
GROOVE Xのスクラムマスターの1人、 niwano です。
今回は開発の話から少しそれて、社内で「良いフィードバックとはなにか?」のワークショップを自分たちでつくり、それを開催しました、というお話をしたいと思います。

弊社の社風・カルチャーについて

このお話をする前に、弊社の社風・カルチャーについて少し説明をします。
おもに以下の3つです。

  1. 部や課ではなく、チームとして存在している
  2. 開発領域はマネージャーがいないフラット組織
  3. チームとしての意思決定を大切にしている

組織イメージ

開発領域以外では、役割としてのリーダー・マネージャーはいますが、何か特別な権限をもっているわけではありません。
簡単に説明をすると、指示・命令ができる権限をもっている人(いわゆる上司)は社内には存在しないということです。
社員は自律して行動をする必要があり、権限も与えられていて、その代わりに責任もある、という感じかなと思います。
弊社はフラット組織で、それに対して、上司が存在する組織のことをヒエラルキー組織と言います。

また、弊社ではチーム横断で活動するワーキンググループという概念があります。 これも必要なときに、「WGでやったほうが良くない?」みたいなラフな感じで自発的に発足されます。 「良いフィードバックとはなにか?」のワークショップづくりは、人事とスクラムマスターで「組織のお手入れをする」という名目で活動している、庭師 というワーキンググループがあり、それの成果でもあります。

フィードバックについて

ヒエラルキー組織に勤めたことがある方は、分かると思うのですが、自分の上司からのフィードバックがあると思います。 あなたは、◯◯ができたね、△△ができなかったね...。と言った感じの人事評価です。

ちなみに私の前職では、お給料の査定時にこのフィードバックがあり、結果が出てるタイミングでのフィードバックは意味ないじゃんって何度も思ったことがあります。

弊社のようなフラット組織であっても、お互いがフィードバックできるようになり、その上で自ら成長できる組織にしていきたいと、庭師では考えました。 庭師で考えた良いフィードバックは、以下のようなものです。

  • 心構え
    • 相手のためにフィードバックする
    • ストレートに、ただし決めつけない
  • 振る舞い
    • 具体的な事例を出し、それに関する感想を伝える

コンセプト

庭師のワークショップづくり

今回、自分たちでワークショップをイチからつくることにしました。理由はこれを題材にしている教材がすくなかったことがあげられます。 ワークショップをつくるために、庭師では 「Training from the back of the room」を使いました。

Training from the back of the roomの4Cs

ここでは、この手法の具体的な説明は省きますが、

  • Connections
  • Concepts
  • Concrete Practice
  • Conclusions

の4Csでアイデアをまとめていくと、ワークショップができちゃうものです。 私達も、Connections から右回りに、それぞれの問いや具体的な概念をたてて、アイデア出しとブラッシュアップを2週くらい実行しました。

ワークショップを実施

作成したワークショップのアジェンダは以下です。

アジェンダ

一度全体ワークを実施し、コンセプト説明をすることで、参加者により深く気づきを与えられるような工夫を行いました。

ロールプレイング

ワークショップの中のロールプレイングのトピックでは、庭師で具体的なキャラクターとストーリーを設定し、フィードバックする側、される側、それをみている人、の3者に別れて実際にフィードバックを体験してもらいました。
ここでは、「良いフィードバック」の体験と、あえて「悪いフィードバック」の体験もしてもらいました。

「良いフィードバック」の体験では、決めつけず聞き手になることの重要性や、いつでも力になるよ、という寄り添いのメッセージが効果的になるのでは、という意見が出ました。

また逆に「悪いフィードバック」の体験では、自分の意見を押し付けたり、恐怖をあたえたりすることが、相手の成長の妨げになるのでは等の意見が出ました。

ロールプレイングの感想

Google Meetでロールプレイングをしているところ

ワークショップ参加者のご感想

ワークショップ参加者のご感想

参加者の方には良いフィードバックはどのようなものか伝わったと思います! 私もこのワークショップを通じて、日々の会話が各メンバーへのフィードバックとなっていることを実感をしました。

庭師ではこのような活動を今後も継続していきたいと思っています!

最後に

最後まで読んでくださり、ありがとうございました!

今回は開発の話とは異なり、GROOVE Xの社風/カルチャー、組織について紹介できたかと思います。

GROOVE Xはまだまだ新しい会社であり、LOVOTの開発と平行して、組織づくりも行っています! 自分で組織づくりができるなんて、めったに経験できるものではないと私は思っています。

弊社では、絶賛メンバーを募集中ですので、少しでも興味ある方はこちらからご連絡ください!

recruit.jobcan.jp

GXのライブ配信の裏側

こんにちは GROOVE X の配信チームの hiro-ogawa です。 この記事にある通り、本職はSLAMなんですけどね。 個人的に興味があって、GXのライブ配信もお手伝いしてます。

GXでは浜町にある LOVOT MUSEUM より、営業日は毎日ライブ配信を行っています。 こちらは基本的に固定カメラで、音声無しで、LOVOTがわちゃわちゃ動いている様子を楽しんでいただいてます。 今日の配信はこちら


www.youtube.com

定期的なミュージアムからの配信以外に季節イベントやキャンペーン、ソフトウェアアップデートなどに合わせて、不定期にライブ配信イベントもやっています。 先日はオーナーさまをお招きして、「LOVOTとの奇跡」をテーマに配信し、投稿された素敵なエピソードのご紹介やLOVOTクリスマスケーキ2022のお披露目などを行いました。


www.youtube.com

イベント配信の時は定期配信と違って、映像や音声を切り替えたり、動画やスライドを映しながら配信してます。 今日は配信には映っていない、その裏側についてご紹介しようかなと思います。

機材

なんと言っても機材が命。と言っても、予算は限られているので、そこまですごい機材を使っているわけではありません。

ATEM Mini Pro

配信で最も使っている機材が、ATEM Mini Proですね。 こちらは業務用の機材も作っているBlackmagick Design社の比較的お安めのビデオスイッチャです。

ATEM Mini Pro

この機材を購入する前は OBS Studio というPC上で動作する配信ソフトを使っていました。 ソフトウェアなので自由度が高い反面、操作はポインタで行うので、画面を見ていないとできないという難しさがありました。 ハードウェアの良い点は体で覚えると、ボタンを見なくても手探りで操作できるところかなと思います。 状況を見ながらタイミング良く切り替えるというのはハードウェアを導入して格段にやりやすくなったと思います。

このハードウェアだけで、Youtubeのストリーミングサーバへの送信ができるのも便利なところです。 Youtube以外にZoomのウェビナーなどもやることがありますが、その際にはUSBでPCと接続するとUSBカメラとして認識されるので、Zoomなどのミーティングソフトと繋ぐこともできます。 長時間連続で動かしていると熱暴走っぽいことになる場合があるのが困りものではありますが・・・

基本的にはHDMI入力が4本とステレオ音声入力が2本あります。 ライブ配信では映像入力として固定カメラ、手撮りカメラ、PCの3つを基本的に繋いでいて、4つ目は何か必要になった時に繋ぐ感じですかね。 例えばスマホとか。

固定カメラは全体が収まる形で固定。 手撮りカメラはヒトだったり、モノだったり、LOVOTだったりの注目対象を適宜ズームして撮る感じ。 PCは動画やスライドの再生で使います。 ATEM Mini Proだと入力画像や出力画像が同時にモニタに出せるので、ライブ配信に使いやすいですね。

音声としてはHDMI入力4本の音声も扱えますし、音声入力も左右それぞれを分離して、モノラル4チャンネルとして扱うこともできます。 ただ、音量のコントロールは上下キーでしかコントロールできなくて、操作しずらいので、今は次に紹介する PodTrak P8 を使っています。

PodTrak P8

ZOOM社*1ポッドキャスト用の音声ミキサ PodTrak P8を使っています。

PodTrak P8

出演者の声の大きさによって、音量を適宜調整しているのですが、物理的にスライダがあった方が同時に複数調整する場合などにやりやすいです。 以前はMIDIコントローラを使っていたこともあったのですが、ATEMとの連携動作がおかしい部分があって使いにくかったので、専用品を使っています。 ポン出しなどのボタンも用意されているので、BGMや効果音を入れる時など、ライブ配信には便利だと思います。

ちなみに余談ですが、これまでに声優さんや俳優さんなどに出演していただいたことがあるのですが、声量が一定で驚きました。 笑った時などでも声にインパクトはあるのに声量が極端に変わらなくて、さすがプロだなーと思ってました。 音声を担当していると、頻繁に音量を調整するのでよく分かるんですよね。

マイク

さて、一番ライブ配信で苦労しているのがマイクです。 LOVOTと触れ合いながらだったり、出入りがあったりで、動きが多いので、ワイヤレスのピンマイクを使っています。

最初に買ったのは Comica BoomX-D2 ですね。 1つの受信機で、ワイヤレスマイク2本が繋がるもので、ATEMの音声入力に入れてステレオを分離して使っていました。 ただ、マイク2本では足らなくなった時に、買い足したところ、2セットで混信してしまって、音声がとぎれとぎれになるトラブルが発生。 最初はLOVOTがたくさんいるから電波障害でも発生しているのかと思っていましたが*2、結果的にはLOVOTは悪くなかった*3

BoomX-D2

次に買ったのがSHUREのSVX188J。 こちらも1つの受信機でマイクが2本繋がります。 この機種はマイク毎にチャンネルを設定するタイプになっているので、複数を同時に使うことができます。 8チャンネル用意されているので、8本同時に使えるのかなと思い込んでいたんですが、マニュアルをよく読むと同時使用は3チャンネルまででした。 実物で試したところ4チャンネルまではなんとか使えましたが、5チャンネル以上は混信してしまいました。 残念。 ということで、現在は最大4チャンネルで使っています。

SVX188J

あとは、先に買った BoomX-D2 との同時使用も試してみたのですが、ディレイ*4の違いによって、エコーがかかったみたいな音声になってしまったんです。 ディレイを調整する機材もあることはあるんですが、今の所、購入には至っておりません。

マイク探しの旅はまだ始まったばかり。 無線だけだと怖いんで有線で使えるものも用意したいですね。 機材は少しずつ揃えています。

スタッフ

機材の操作は初期の頃は全てを一人でやることもありましたが、最近は一緒にやってくれる人が増えて、機材操作は3人くらいで行うことが多いです。 手撮りカメラ1名、映像スイッチ・PC操作1名、音声1名という感じですね。

本職でやっている人は一人もいなくて、撮影が好きな人や、興味を持っている人が本職を調整して運営している感じです。 私としても学びになる部分もあって、いつもとは違う仕事を楽しみながらやっています。 部門の垣根を超えて、いろんな人と仕事をするのも刺激になって良いですね。

おわりに

次回のライブ配信は 12/28 にLOVOTオーナーミーティングを予定しています。オーナー以外の方でも参加可能なので、是非見てみてください。 もしご覧になる方がいらっしゃいましたら、画面の裏側がこんな感じになっているのを想像しながら見てもらえるとうれしいです。


www.youtube.com

GROOVE Xは、部門間の垣根をできるだけ下げ、目的ごとに柔軟に変化する「チーム」が複数存在する形で組織が成り立っています。 今回はビジネス、コーポレートと開発の組み合わせのお話でしたが、他にもいろいろな部門が連携してLOVOTを開発しています。 もしそのようなLOVOTに関わるお仕事に興味がある方がいらっしゃいましたら、絶賛募集中ですので、是非ご応募ください。

recruit.jobcan.jp

*1:インターネット会議のZoomとは別の日本の企業です。

*2:マイクが2.4GHz帯を使っているので、バッティングしやすいんです。

*3:疑ってすみませんでした。

*4:マイクに入力されてから受信機から出力されるまでの遅延時間。電波で送るために信号変換などをするために遅れが発生します。

ReactカスタムフックでAPI呼び出しを共通化してみた

GROOVE X クラウドチームのmineoです。

弊社ではLOVOTという家庭用ロボットを開発しており、クラウドチームでは機体と通信するサーバーの管理や他サービスとの連携などで、LOVOTをサポートしています。

また、LOVOTに関わるWebアプリケーションをReactで開発し、社内外(社外は一部協力会社)に向けて提供していたりもしています。

tech.groove-x.com

この記事では、直近で新規でWebアプリを開発する際に、自社APIの呼び出し部分をカスタムフックでいい感じにまとめることができたので、ご紹介します。

  • 前提
  • すなおにかくと
  • カスタムフック:useApiClientの実装
  • カスタムフック:useItemの実装
    • loadingとerrorの返却
  • おわりに

前提

  • React 18
  • TypeScript
  • Firebase Authentication

APIはFirebase Authenticationで認証します。idTokenをBearerトークンで利用するやりかたです。 Reactでは、react-firebase-hooksというfirebaseの機能をカスタムフックで利用できるようにしてくれたライブラリがあるので、こちらも活用します。

github.com

なるべく、標準APIを使うようにしており、axiosやquerystringsは使わず、fetch APIやURL SearchParamsなどを利用しました。

また、記事中のコードは記事用に書き下したため、実際に使っているコードとは異なる部分があります。

続きを読む