2024-01-22

Androidチームにおける品質改善①〜ユニットテストの導入〜

開発プロセス業務システムエンジニアリングマネジメント

今回は直近のAndroidチームの品質改善の取り組みとして、ユニットテストを導入した件についてお話したいと思います。

はじめに
実際にやった事
- ユニットテストを書く
  - どこからユニットテストを書くか
  - 技術スタック
  - JUnit4 + Mockito-Kotlin + Truthを使用したテストコード
- カバレッジ率の可視化
  - Jacocoの設定
  - Jacocoの出力
- CIで自動でテストが実行される環境
  - 導入したアクション
  - ワークフロー
最後に

2023-12-26

セーフィーはPyCon APAC 2023に出展しました！

イベントレポート

こちらはSafie Engineers' Blog! Advent Calendarの18日目の記事です。

こんにちは。セーフィー株式会社でバックエンドエンジニアをしている河津です。

私たちの会社は2023年10月27-28日に、PyCon APAC 2023への出展を行いました。この記事では、出展までの準備や当日の様子について紹介したいと思います！

PyConとは
用意したデザインアイテム
当日の様子
出展デモ
- Safie One
- Safie Pocket2 Plus
- Safie Connect
撤収と振り返り

2023-12-25

セーフィーの開発組織振り返り　＠2023

会社紹介

メリー・クリスマス、セーフィーCTOの森本です。
こちらはSafie Engineers' Blog! Advent Calendarの25日目のエントリーです。

時間の経つのは早いもので、当社も少し前まで数十人でバタバタやっていたように感じていますが、それが今では400人を超え、いよいよ創業10年目に突入しました。
まだまだやりたいこと、やらなければならない事が山積みでそのために更に大きく成長していく必要も感じていますが、現在の姿も過去からの積み重ねですので、今後を考える上でもまずは年末のこのタイミングで今までの歴史を振り返ってみたいと思います。

はじめに
暗黒時代　エンジニア数〜10名
- 2014年〜2016年
- 2017年〜2018年
闇からの夜明け　エンジニア数〜30名
- 2018年〜2020年
未来への飛躍　エンジニア数30〜100名
- 2021年、2022年
- 2023年
今後に向けて
まとめ
最後に

2023-12-24

セーフィーで取り組むマイクロサービス化について

カイゼンサーバー・インフラ開発プロセス

はじめに

セーフィー株式会社でバックエンド開発のテックリードをしております鈴木敦志と申します。セーフィー株式会社は創業から9年経過し、サービスの拡大と開発者の増加に伴う開発生産性の問題に直面しています。この問題の解消のため、職能横断型チームの再編成とコードベースの分割によるマイクロサービス化を進めています。

セーフィーのサービス・チーム構成

セーフィーのクラウドサービスはカメラ管理および映像閲覧のほか、業務システム、AI応用サービス、開発者向け機能および入退館管理システムなどで構成されており、サーバー/Webの開発者のほかモバイル/組み込み/QAエンジニアなど様々な職種が関わっています。チームは職能別に分かれており、チームごとに複数のプロジェクト (開発案件) に参加します。

開発組織の規模が増えるにつれ、様々な問題が明らかになってきました。

機能追加・改修にはたいていWeb・サーバーなど複数職種が関わってくるため、開発に伴い複数チーム間の調整が頻繁に発生します。各チームは複数プロジェクトを並列で掛け持ちすることになり、開発リードタイムの増加と認知的負荷の増加に繋がっていました。
特にバックエンド開発において、モノリシックなサーバーコンポーネントを複数チームで共有しているためコード変更やデプロイ作業の競合が頻繁に発生していました。こういった状況に対処するためにコードベースの分割が進められていましたが、各コンポーネントのオーナーシップが不明確であるためにいわゆる分散モノリスの状態になり改善には繋がりませんでした。

これらの問題を抜本的に解消するため、職能横断型チームの再編成とマイクロサービス化に取り組んでいます。

マイクロサービス

マイクロサービスとは、個別にデプロイ可能なサービスの集合体としてシステムを構成することで多人数による並列開発を効率化する手法です。今回は下記方針でマイクロサービス化およびチーム再編成を進めていきます。

マイクロサービス境界を決定: マイクロサービスの導入にはどのようにサービス境界を定めるかが重要になりますが、今回はビジネス機能により分割し、必要以上に細かく分割しないようにしています

チームの再編成: 各チーム内で開発業務が遂行できるよう企画・QA含め機能を集約し機能横断チームを編成します
コンポーネントの分割と内部APIの整備: ソフトウェアコンポーネントの機能がマイクロサービス境界をまたいでいる場合、コードベース・デプロイ単位・DBを分割します。境界をまたいで機能提供を行う場合、gRPC等で内部APIを整備します。

モジュラーモノリスの検討

マイクロサービスに関連する手法としてコードベースおよびデプロイ単位は単一のままモジュールのオーナーシップを明確化するモジュラーモノリスも知られており、マイクロサービス移行の前段階として、あるいはマイクロサービスの複雑さを回避しつつ大規模開発を行うために用いられます。弊社においてはモジュール間参照の規律を保つのが難しいと判断したため、マイクロサービスを選択しました。

既存コードベースのマイクロサービス化

既存コードベースのうち特にバックエンドのソフトウェアはAPIサーバー、デバイス接続サーバー、タスクキュー、バッチサーバー等多数のサーバーで構成され、いわゆるモノリスあるいは分散モノリスとなっています。これらのソフトウェアの機能を保ったままマイクロサービス化を進めるため、以下の手順を取ります。

既存コードベースのうちマイクロサービス境界をまたぐものをチームごとにフォーク
自チームの担当範囲外の実装範囲外を削除またはプロキシに置き換え
DBへの接続権限を変更し担当範囲外のテーブルへの書き込みを禁止
マイクロサービス境界をまたぐ機能提供をAPIプロキシまたはDBの参照からgRPC等の内部APIに置き換える
DBサーバーを分割

例: カメラ管理と契約・決済情報の分離

場合によっては単純なAPI分割だけではサービスの分割ができず、再設計が必要な箇所があります。

例として、セーフィーではカメラごとに顧客とSaaS契約が締結され、契約プランにより使用できる機能が異なります。契約プランはフロントエンドチームの内製する管理ツールにより操作され、また社内の業務システム (Salesforce, Zuora等) と同期されています。チームをまたいだ複雑なデータの同期が行われ、またどこの情報が元データなのかがわかりづらくなっていました。

現在サーバー内では契約情報とそれにより有効化される機能が単一のRDBテーブルで表現されていますがこれを分離し、カメラの機能有効化API/ライフサイクル管理APIを業務システムチームに提供する形で連携することで、契約情報の一元管理を実現します。

まとめ

セーフィーにおけるサービス規模・開発組織規模の増大に伴う開発生産性の問題に対応するため、既存システムのマイクロサービス移行を進めています。

現在セーフィー株式会社ではソフトウェアエンジニアを採用中です。マイクロサービスアーキテクチャや開発生産性の向上についてご興味のある方はぜひともご応募ください。

https://safie.co.jp/teams/

2023-12-23

Safieプロダクト開発の歴史 Part2

プロダクト紹介

この記事は Safie Engineers' Blog! Advent Calendar 23日目の記事です。

企画本部のマネジメントをしております植松です。

本テックブログももうすぐ丸4年を迎えます（祝！）。テックブログのごく初期にプロダクト（商品）開発の歴史を投稿してからもSafieは様々なプロダクトを世に出してきました。

そこで、本記事ではこの4年間でリリースしてきたプロダクト群の一部紹介と、今後の展望について書いてみたいと思います。

Safie API / Safie Developers
Safie Pocket2 / Pocket2 Plus
Safie One / SPDP
今後の展望

Safie API / Safie Developers

2020年迄はエンドユーザーやパートナーの方向けの製品を作っていましたが、開発者向けの初のプロダクトとして2021年2月に Safie API をリリースしました。これにより、お客様の既存の業務ツールに我々の映像を組み込んでいただいたり、画像解析をお客様側で行っていただく、など、お客様側の使い方の幅が格段に広がりました。

元々の企画の始まりはパートナー様向けの案件があり、それは画像取得しViewerへのイベント登録をパートナー様側で画像解析して登録する、というものでしたが、我々のサービスとしては汎用化を見据え同時にストリーミングAPIを準備しました。かなりタイトなスケジュールでしたがなんとかリリースにこぎつける事ができました。このパートナー様向け機能については継続的に多くの台数使っていただいて売上高も順調に伸ばしており、今後のAPI利用の足がかりにもなったと思っています。

当初はβ版として限られたユーザにのみ使っていただいてましたが、今年頭から晴れてDeveloper（Safie API v2）として生まれ変わり、登録したユーザは誰でも使っていただけるようになっています。このブログではAPIの使い方や、APIの便利なユースケースも紹介していますので、そちらもぜひご覧いただければと思います。

Safie Pocket2 / Pocket2 Plus

ウェアラブルカメラPocketシリーズは2020年にリリースしたPocket2 , 2023年にリリースした Pocket2 Plus と着実な進化を遂げていますので、その歴史について簡単に記したいと思います。

2020年一番の出来事は何と言っても新型コロナウイルスでした。弊社のサービスもコロナウイルス対策最前線の病院などで活用され、その事例は英国のBBCニュースでも取り上げられました。そこに遠隔業務の切り札として満を持して2020年7月に登場したのが「Safie Pocket2」です。

初代Pocketは、所謂MVP（Minimum Value Product）と呼ばれる仮説検証のため、市販のウェアラブルカメラのソフトウェアをカスタマイズしたものです。静止画スナップショット機能やWebRTCによるリアルタイム双方向音声通話の実現といった新開発機能を盛り込んだ、新しいサービスでした。私が入社した頃には既に初代Pocketは開発が終わっていましたので、伝え聞くところにはなりますが、カメラ本体に加えて無線LANルーターやモバイルバッテリーが別途必要で、ご利用いただいたユーザー様からもやはり、重い、持ち運びしにくい、というフィードバックを数多くいただいていたようです。そこで、エンジニアが、インターネットで見つけた世界中のウェアラブルカメラメーカー（英語では "body worn camera" と呼ばれます）に手当たり次第問い合わせをし、国内外のこれといった展示会を巡った末に実現したのが「Safie Pocket2」でした。

当初は3月に製造して4月販売開始の予定でした。新型コロナウィルスの脅威が日に日に高まり、外出自粛やリモート勤務が行われる中で、Pocket2をご活用いただけるはず、だったのですが、なんとPocket2の工場まで閉鎖されてしまったのです。メーカーさんが何とか頑張って工場を再開したのに部材も人も揃わない。組立が完成しても、物流が混乱しているので発送したカメラが届かない。お待ちいただいていた皆様にようやくお届けすることができたのは、3カ月遅れの7月になってしまいました。予定よりも遅れてしまいましたが、ユーザー様にはご満足いただき、さらにはテレビ東京 WBSで取り上げていただくなど、社会的にも注目される商品となっていきました。

ここで歩みをとめたわけではなく、使っていただいている中で様々な品質課題や改善要望が上がってきておりそれらを解消すべく、今年の5月に新たにPocket2 Plus をリリース。ウェアラブルならではの「手ぶれ補正」や、音声品質改善のための「スピーカー通話」、ウェアラブルといいながらも実際には固定して長時間利用されている方も多いため「モバイル給電」などの機能を搭載。より痒いところに手が届く、使い勝手の良さを追求したプロダクトとなっています。来年は海外にも羽ばたく予定です。

Safie One / SPDP

弊社CEOの佐渡島が創業当時から何度も語っていた「かしこくなるカメラ」の実現。Safie初のエッジAIカメラである Safie One は2022年9月にリリースされましたが、このリリースも苦難の連続でした。

CC2 / CC2Lという主力プロダクトの製造会社に開発依頼し、商品コンセプト、ハードウェアデザインについてデザイナーの方とコンセプト固めをして何度もやり取りを行い、試行錯誤を行いながらデザインを決めていきました。その後試作機が届いたのですが、SoCから発生する熱問題（AIを定常的に使っていると熱暴走して停止してしまう）・カチカチ音問題（カメラ内部で音が定常的に鳴る）・IrLED反射問題（レンズの下部に反射して映像にゴーストが発生してしまう）... などなど、大きな課題から小さな課題まで膨大な件数を、1つ1つ潰していきながらプロダクトリリース。

当初の構想から足掛け2年。やっとの思いでリリースした後も安定して量産にこぎつけるまでに様々な苦労がありましたが、現在はぽん置き出来る手頃なAIカメラとしてセーフィーの主力商品となっています。

当然ながら、エッジAIカメラというからには同時並行でAIアプリも開発が必要です。SPDP という主に店舗で使っていただくための立ち入り検知・通過人数カウント・立ち入りカウントがパッケージされたAIアプリを同時リリースしているのですが、これも途中で1度UI部分の仕様変更に伴った作り直しが入り、今の形となりました。もちろんViewerからスムーズに使える使い勝手の良さは他のアプリと同じ思想で作られています。

vimeo.com

今後の展望

まだまだ書きたいプロダクトは色々あるのですが、長くなってしまうので改めての機会とさせていただき、ここでは今後の展望を記したいと思います。セーフィーでは「映像から未来をつくる」をビジョンに掲げ、ユーザーの課題を解決するプロダクトを創業当初から作り続けて来ました。今後は、

パートナーであるカメラメーカーをユースケースに合わせて増やしていき、カメラ、特にエッジAIカメラのラインアップや、カメラを使える環境（ネットワーク機器、SIMなど）の提供
よりユーザーの課題に寄り添ったソリューションの提供
映像プラットフォーマーとして技術をさらに活用してもらう方法をAPIやSDKで提供

といったあたりを中心に、セーフィーを使ってくださる方を増やし、セーフィーの映像を使って課題解決出来ることをどんどん増やしていきたいと考えています。

最後に、セーフィーでは新しいプロダクト、サービス、ソリューションを一緒につくっていただけるエンジニアやプロダクトマネージャーを大募集しています。面白そうだな、と思った方はカジュアルに話してみたい、で結構ですので是非コンタクトいただけると幸いです！

open.talentio.com

2023-12-22

エンジニアと育児

ライフスタイル

この記事はSafie Engineers' Blog! Advent Calendar 22日目の記事です。

セーフィー株式会社でソフトウェアエンジニアをしている大場です。

2022年10月に子供が生まれました。あれから1年という月日が経ち、育児の大変さを実感してきました。ソフトウェアエンジニアという職種はPC１台とネット環境さえあれば場所を選ばないため、コロナ禍もあり、リモートワークを中心として育児と仕事の両立を図りました。

本稿では育児の中で培ってきたあやし方や寝かしつけ方の回顧録を多少のエンジニア視点を交えてまとめておきます。尚、子供によって合う合わないはありますので、必勝の攻略法は（おそらく）存在しないことをご承知おきください。

爆誕から生後3ヶ月ぐらいまで
〜６ヶ月ぐらいまで
〜9ヶ月ぐらいまで
〜12ヶ月まで
１年を振り返って

2023-12-21

Unityで作成したCG映像を使って物体検出AIのQA評価をした話

この記事は Safie Engineers' Blog! Advent Calendar 2023 の21日目の記事です。

はじめに

セーフィー株式会社で画像認識AIの開発エンジニアをしている木村（駿）です。主に、エッジAI搭載カメラで動作する人やモノを検出するアプリケーションの開発を行っています。
このAIカメラを使って、弊社では指定したエリアへの人の侵入を検知するサービスや混雑度合いを数値化するために滞留人数をカウントするサービスなどを提供しています。

これらのサービスが、必要な基準や要件を満たしているかどうかを確認するため、QA (Quarity Assureance) 評価を実施しています。具体的には、AIの検出性能や追跡性能のみを評価するのではなく、実際にユーザーが見る値（侵入検知のフラグやカウント数など）が正しく機能しているかを評価します。

このQA評価をするには評価用データ、つまりアノテーションされたデータが必要になりますが、動画のアノテーションデータの作成は非常に大変です。仮にFPS30の10分の動画に対してアノテーションデータを作ろうとすると、1フレームごとに5人映っていれば 30fps×600sec×5=90000個の矩形を手作業でつける必要があります。バリエーションを作ろうと思うと複数の動画のアノテーションデータが必要で、さらに大変です。

そこで、CGで映像を作成し、自動でアノテーションデータを作成できないかと考えました。今回は、ゲームエンジンであるUnityを使ったCG映像の作成方法と、CGの人物に対して人検知を行った結果および簡易的なQA評価の結果をご紹介します。

2023-12-20

プロダクトマネージャー孤独問題に向き合ってみた

プロダクトマネジメント

この記事はSafie Engineers' Blog! Advent Calendar 20日目の記事です

自己紹介と本日のテーマ

はじめまして、セーフィー株式会社でSafieの映像サービスを支えるSaaSプラットフォームプロダクト群のPdMをマネジメントしているマネージャーの光田です。

本日はPdM組織のマネジメントについて、発生した課題と解決のために取り組んでみた施策についてお話しさせていただきます。

自己紹介と本日のテーマ
前提
発生した問題
どうやって解決したか
まとめ

2023-12-19

QCDグループで使っている自動テストツール（MagicPod編)

この記事はSafie Engineers' Blog! Advent Calendar 19日目の記事です

こんにちは。2023年3月にセーフィーにジョインした入社一年目のQCDグループの森重です。

入社してからはカメラの対応機種拡大やマイページ、モバイルアプリと様々な領域・プロダクトにQAとして携わっていて、テスト設計や手動テストの実行だけでなく自動テストにも取り組んでいます。

この記事ではQCDグループで取り組んでいる自動化、特にMagicPodに焦点を当てて、QCDグループがMagicPodでどんなテストを自動化しているかをお話できればと思います。

MagicPodについて
自動テストの目的
自動テストのスコープ
新機能：ヘルススコア
メリット/課題
最後に

MagicPodについて

そもそもMagicPodとはなんぞや？という方もいると思うので、簡単にツールについて説明します。

MagicPodは有償のテスト自動化ツールでWeb・モバイルに対応したE2Eテスト自動化ツールとなっています。

他の自動テストツールと比べて優れていると思うのは、自動テストの実行回数に制限がない点、メンテナンス性を確保し易い点です。

実行回数に制限がないので、毎日自動テストを実行したいプロダクトに向いているツールと言えます。

自動テストの目的

次にQCDグループで自動化に取り組んでいる目的ですが、これはテスト実行回数増加と広範囲化でバグの早期検出とバグ検出件数増加のためです。

MagicPodに決まったテストを毎日実行させることでエラーを早期検出し、今までリスクベースで切り捨てていたテストもやってもらうことで、カバーできる範囲を増やすようにしています。

自動テストのスコープ

対象のテストは、ずばりリグレッションテストになります。

テスト対象の変更が少なくメンテナンス性の確保が比較的容易なことが大きな理由です。逆にE2Eテストで自動化しないほうが良いのは頻繁に変更が入る新規機能だったり、変更が入りやすい画面を対象としているテストケースです。

実際の画面をお見せするとこんな感じです。失敗しているテストケースもありますが、定期実行して毎日結果をモニタリングしています。

メンテナンスはチームで毎日持ち回りで担当していて、日々やっているという感じです。

新機能：ヘルススコア

少し話はそれてしまいますが、先日のMagicPodのメジャーバージョンアップで追加されたアナリティクスで自動テストのヘルススコアを算出してくれます。参考までにマイページのヘルススコアを紹介しておきます。

マイページ

マイページではヘルススコア89です。このプロジェクトはQCDグループの中では後発で自動化を勧めており、パイロットプロジェクトでの運用経験からメンテナンス性を重視したテストケース作成をしています。

特にMagicPodの機能の中でも共有ステップ・変数は様々なテストケースの中の手順を一つの共有ステップで集約することで、テストケースのメンテナンス性・可読性が狙えるため積極的に活用しています。

メリット/課題

一通りテスト対象や運用については書き終わりましたのでMagicPodを自動テストに取り入れたことで感じているメリットと使い続ける上での課題についてもここに書いておきます。

MagicPodを導入したことで感じたメリット

早期バグ検出に役立つ
テスト環境を広げたことによるバグ検出ができた

メリットですが、こちらはMagicPodを導入した当初の狙い通り、バグ検出関連の恩恵が大きいです。

MagicPodを使い続ける上での課題

テストケースの作成
テストケースの属人化
テストケースの管理・メンテナンス
共有テストケースの活用不足、メンテ工数増
自動テストの実行結果をTesrailに自動でインプットできていない
テスト分析
データ分析用の基盤の立ち上げができていないのでスピード感を持った分析が困難
教育
教育資料がなく、ジョインされた方も自己流で学ぶ必要がある

一方課題ですが、MagicPod利用上のルールやそのデータを活用できていないことが多く挙げられています。今後の改善活動として取り組んでいく予定です。

最後に

以上、QCDグループで使っているMagicPodについて紹介させていただきました。

当初狙っていた効果は一定得られているものの、まだまだ課題が残っていますので、継続して改善が必要そうです。

MagicPodにとどまらずテスト自動化について今後もテックブログで発信していきますので、よろしくお願いします。

2023-12-16

Gradio: Pythonで簡単にAIをWebアプリ化

画像認識

この記事はSafie Engineers' Blog! Advent Calendar16日目の記事です。

はじめに
Gradioとは
Hello World!
認証機能
リアクティブインターフェース
ブロック構造とイベントリスナー
コンポーネントの種類
実装例
- ソースコード
- 画面
その他ドキュメント
まとめ

はじめに

セーフィー株式会社開発本部第3開発部 AIVisionグループで画像認識AIの開発エンジニアをしている土井慎也です。

セーフィーには2023年1月に入社し、もうすぐ1年が経とうとしています。

今年を思い返せば、生成系AIを中心とした、AI界隈の発展がすごい1年でした。

毎日のようにいろんな技術が発表されて、使えそうなものはすぐにOSSに実装されていて、技術進歩の速度がものすごく速く感じました。

さて、今回はそんなAI界隈で使われているWEB UIツールのGradioについて軽く紹介したいと思います。

Gradioとは

Gradioは、機械学習モデルを簡単にデモするためのPythonライブラリです。Gradioを使用すると、モデルの入力と出力に対応するインターフェースを簡単に作成でき、モデルを試すためのWeb UIを生成できます。これにより、モデルの挙動を迅速に確認したり、他の人と共有したりすることが可能になります。

stable diffusionで有名なWEB UIの一つである、stable-diffusion-webuiもGradioを使用しています。

AI用のGithubともいえるHuggingFaceとの親和性も高く、HuggingFaceで公開されているものを簡単に試すことができたり、逆に公開することもできます。

また、機械学習モデルに関係なくても、Gradioには色々なインターフェイスが用意されているので、簡易的なWeb UIが簡単に実装できます。

Gradioは日々アップデートで変化しているため、今回はあまり深くは解説せず、基本的な紹介といたします。

Hello World!

python3.8以上が実行可能な環境を用意します。

Gradioのインストール

pip install gradio

コード実装

import gradio as gr

def greet(name):
    return "Hello " + name + "!"

demo = gr.Interface(fn=greet, inputs="text", outputs="text")

demo.launch()

fn: 実行する関数
inputs: 入力のコンポーネントの種類（list型で複数指定可能）
outputs: 出力のコンポーネントの種類（list型で複数指定可能）
demo.launch(): 実行

こんな感じに、少ないコードで、簡単にWeb UIを作成することができます。 HTMLやCSS、jsなどを意識する必要はありません！

実行結果

https://gradio-hello-world.hf.space

認証機能

Gradioには認証機能があります。

demo.launch(auth=auth_function)とすることで、認証機能を有効にすることができます。

認証機能のベースはFastAPIのOAuth2PasswordRequestFormを使用しているようです。

import gradio as gr

def greet(name):
    return "Hello " + name + "!"

# 認証機能
def auth(user_name, password):
    # 例: ユーザー名とパスワード(反転)が一致したら認証OK
    # 実際にはDBと連携して認証するなどの処理が必要
    if user_name == password[::-1] :
        return True
    else:
        return False

demo = gr.Interface(fn=greet, inputs="text", outputs="text")

# 認証機能を有効にする
demo.launch(auth=auth)

リアクティブインターフェース

gr.Interfaceでlive = Trueを指定すると、入力値を変更するたびに、リアルタイムで出力が更新されます。

import gradio as gr

def calculator(num1, operation, num2):
    if operation == "add":
        return num1 + num2
    elif operation == "subtract":
        return num1 - num2
    elif operation == "multiply":
        return num1 * num2
    elif operation == "divide":
        return num1 / num2

demo = gr.Interface(
    calculator,
    [
        "number",
        gr.Radio(["add", "subtract", "multiply", "divide"]),
        "number"
    ],
    "number",
    live=True,
)
demo.launch()

https://gradio-calculator-live.hf.space

ブロック構造とイベントリスナー

Blocksを使用すると、より細かくレイアウトを指定することができます。

また、イベントリスナーを使用することで、ボタンをクリックしたときの処理を指定することができます。

Hello World!をBlocksを使用して書き換えると、以下のようになります。

import gradio as gr


def greet(name):
    return "Hello " + name + "!"

# Block
with gr.Blocks() as demo:
    name = gr.Textbox(label="Name")
    output = gr.Textbox(label="Output Box")
    greet_btn = gr.Button("Greet")
    # イベントリスナー
    greet_btn.click(fn=greet, inputs=name, outputs=output, api_name="greet")

demo.launch()