はじめまして、データ&AIチームのoyabuです。データストラテジストというデータアナリストみたいな仕事をしてます 具体的には「DELISH KITCHEN」アプリのデータを抽出、分析して食品メーカーなどのクライアントさまの施策や提案にご活用頂く仕事をしています 今回はLLM(ChatGPT、OpenInterpreter)をビジネスサイドに活用してもらうためにやったことの話をします まだ始めたばかりなので、成果自体はそんなに出てないですが、考えたことや、得られた知見を共有したいと思います やったことは以下です ChatGPTの使い方ドキュメントの作成(禁忌とユースケースの整理) ChatGPTの使い方勉強会 OpenInterpreterを隣に座ってるカスタマーサクセスの方に試してもらう きっかけ(課題感) そもそもこんなことをやり始めたきっかけとしては以下な感じです 大前提としてLLMが猛威をふるっており、自分としても十分その利益を享受している ビジネスマンにとって、ChatGPTスキル = 今のExcelスキルぐらいになることは目に見えてる ビジネスサイドでもChatGPTを使ってる人はいるが、あんまり会話に出てこない 社内のSlackを漁ってもChatGPTの話をしてる人はだいたいエンジニア 貼ってるアンテナ的にもそもそもの周辺情報がエンジニアには集まって来やすい 気になってはいて、1回試したものの、業務に使うイメージが湧いてない方がなんだかんだ多いのかなーという妄想 向き合いの部署としばらく働いて、業務もなんとなくわかってきて、細かい施策単位でChatGPTで解決出来そうなものが見えてきた 社内用のChatツール が出来て、直接業務に関わる内容をフランクに聞ける環境が整った 社内の運用ルール/tipsを集めたドキュメントがそもそも不在 やったこととその目的、成果/得られた知見 目的 目的はChatGPTによる、ビジネスサイドの工数削減/クオリティアップです とりあえずは利用習慣化を目標とし、そのために以下の2点を達成するため施策を実行しました ChatGPTが身近なツールだと思ってもらう ChatGPTで出来ること/苦手なことを知ってもらう 習慣化の初期段階で重要なのはフリークエンシー、敵は低いモチベーションと高いハードルなので とりあえずそこを気にした施策の設計をしました 具体的にやったこと ChatGPTの使い方ドキュメントの作成 最低限の禁忌的なルールは書きつつ、業務にそったユースケースを中心に書きました。そうした理由は以下です 各人の業務に近い部分のコンテンツを拡充することで、多様な各人の興味に引っかかりやすくするため 理想論でいえば、成り立ちや理論を知ることは大事ですが、興味のない人がおおそう また完全にその業務をChatGPTで解決することは難しいかもしれませんが、今後の工数短縮やクオリティアップを見越した プロンプトのタタキが存在すること自体が重要だと思っているので、ちょっとでも解決出来そうなことがあるならとりあえず ユースケースとして入れておきました。プロンプトの夢を見ました(天啓もありました) ドキュメント化にあたっては、なるべくバラエティに富んだユースケースを盛り込むようにしました。たとえば以下のようなカテゴリで、業務に近いユースケースを盛り込みました ブレスト系 従来の業務の工数を下げる系 従来の業務のクオリティを上げる系 直近のChatGPT Plusの機能内容 OpenInterpreterでより複雑なことができる話 ChatGPTの使い方勉強会 これは上記のドキュメントをそのままデモ的に紹介しました ドキュメントが読まれないのは世の常。ある程度お時間をお借りして(今回は1時間)集中してChatGPTについて考えてもらう必要があります 共通の体験を通じて、話題にのぼりやすく、近くの席で口頭での知見の共有につながるのも勉強会の利点だと思います やった結果はというと、「いままでChatGPTには正解のある答えを聞いて嘘つかれて使えないと思ってたけど、ブレストにめっちゃ使える!」など ちょこちょこ良い反応は得られました 作戦通りユースケースを色々紹介したことで、各々の業務での活用イメージを具体的にもってくれたようでした とはいえ、あくまでも習慣化のための一歩目なので、ナレッジシェアやOJT的な動きは継続して行っていく必要があります OpenInterpreterを隣に座ってるカスタマーサクセスの方に試してもらう 継続的にChatGPTに興味をもってもらうために、何か飛び道具的な実績が必要だと考えました OpenInterpreterまじですごいという話を聞いたので、これを使ってみることにしました ちなみに同じチームのfuruhama-sanがOpenInterpreterの実装を深掘りしてるので、ご興味のある方は見てみると面白いです tech.every.tv OpenInterpreterのメリットの紹介はfuruhama-sanの記事を読んで頂くと分かりますが、今回魅力に感じたのは以下なことでした GoogleColaboratoryという簡単に用意できる閉じた環境での実行がしやすい ローカルのファイルの閲覧/編集ができる(今回はマウントしたGoogleDrive) 上記を活かして、ドメイン知識を持つビジネスサイドがある程度のデータ分析まで自立的に行えると 今後の分析業務のハードルが下がり、より濃い示唆や知見が財産として効率的に貯蓄されるメリットもあります もちろん一筋縄でいくとは思っていませんが、その第一歩として、隣にいる人に無理を言ってOpenInterpreterを使って頂きました マジ感謝です。隣の人なので仮にTさんと呼びましょう。Tさんはプログラミングができないカスタマーサクセスっぽい立ち位置のひとです やったことは以下です CSV形式で出力されたアンケート結果をOpenInterpreterでクロス集計する おまじないをたくさん書いたGoogleColaboratoryを事前に用意 Tさんからやりたいことを聞いて、思想を説明しながら仮のプロンプトを目の前で書いてみる OpenInterpreterがコードの実行要否を聞いてくるので、Tさんに深く考えずにどんどん実行の指示を出してもらう 意図した結果ではない、処理に時間がかかるなら再度プロンプトを見つめ直すを繰り返す 結果として特定のアンケート項目をその他の項目とクロス集計したものが20個くらい得られました エラーへの対処や、僕がColabの仕様に疎いこともあり、Tさんのお時間はそれなりに頂いてしまったのですが(4h+α)、 わりと喜んで頂けました というのも、そもそも今回のアンケート結果のクロス集計は従来以下の問題を抱えていたようでした 時間がかかる ひとつひとつのクロス集計のために都度数式を組む必要があるので精神的につらい Tさんとしては、成果物を得られたことももちろんですが、上記を自分の手でやらなくてよい。ということに好印象を持っていたようでした また、エラーが出たときに落ちるのではなく、エラーの内容を理解した上で再度修正の処理をかけてくれるのはめっちゃ嬉しいとも仰っていました 最終的には愛着を訴えており、ひたすらこちらから命令を与えているのですが、自己再生をするだけで親近感が芽生えるのは大変興味深い現象でした たしかにOpenInterpreterは内省にもにた処理を繰り返すのがひとつ特徴で、それが悩んでいるように見えるのが人間性を感じるポイントなのかもしれません 逆に以下の点がつらそうでした インタラクティブに処理実行の有無を聞かれるので、常に判断を求められる コードがガンガン出力されるが意味がわからん なんだかんだめんどくさい ここは実験する前にある程度予測はしていたのですがやはりそうか。という感じです 事前のauto_runの設定や、temperatureの調整/プロンプトの精錬である程度解決できそうではありますが、 目まぐるしく出力される情報に知らず知らずのうちに可処分精神が消費されているようでした 例えばGASを整えたスプレッドシートを提供するなどで、局所的な解決は可能な課題でしたが OpenInterpreterである程度柔軟に課題を解決出来ることはわかったので、引き続きこれをうまく使ってビジネスサイドの課題解決を目指していきたいです ※ 余談ですがアップデート後OpenInterpreterがうまく動かなくなりました(10/16時点, ver: 0.1.7) このissueの対応をすることで解決しました https://github.com/KillianLucas/open-interpreter/issues/637 まとめ 以上、ビジネスサイドにChatGPTの利用を習慣づけられるといいなーと思った上で 色々やってみた話を書いてみました とりあえず第一歩目としてドキュメントの作成/勉強会など実施し、それなりの反応は頂き、多少利用は促進できた実感はあります とはいえ、今後習慣化のためには草の根運動が重要になってきます ビジネスサイドで解決しやすそうな課題を見つけたらその場でChatGPTに解いてもらうなど 細かい体験を繰り返していくことで、初めて習慣や文化として根付くものだと思っているので、応援よろしくお願いします

初めまして、DELISH KITCHEN 開発部の吉田と申します。この記事ではAWS Elemental MediaConvertを使ってレシピ動画のサムネイルを作成した方法を紹介します。 サムネイル作成の背景 DELISH KITCHEN はレシピを動画でわかりやすく基本的な料理からアレンジまで様々なレシピを公開しています。 スマホでブラウザ版のDELISH KITCHENをみていただいた場合、レシピの各工程は手順の説明とポイントを表示しています。 今回はより工程が分かりやすくなるようここに画像を追加する運びとなりました。 アプリやPCブラウザ版のDELISH KITCHENでは工程の動画が挿入されていることから、動画のサムネイルを工程画像として利用することにしました。 しかしながら現在設定されているサムネイルは動画開始時点のキャプチャになっています。 そのため、動画開始時点のフレームになっているサムネイルをすでに動画の変換処理で利用しているAWS Elemental MediaConvertを用いてレシピごとに適切なフレームで設定できるよう実装を進めました。 AWS Elemental MediaConvertとは AWS Elemental MediaConvert（以下、MediaConvertとします）はファイルベースの動画処理サービスで、従来のブロードキャストおよびマルチスクリーンデバイスへのインターネットストリーミングに必要な形式にメディアを変換することができます。基盤となるインフラのセットアップや管理、メンテナンスは不要で、必要なビデオ処理設定でジョブを送信するだけで使用を開始することができます。ジョブはトランスコード作業を行うもので、入力ファイルと出力ファイルを指定し、どのようなファイルを作成したいか、どのようなフォーマットで作成したいか等を設定します。 詳しくはこちら 取り組んだこと サムネイルの作成にはMediaConvertのフレームキャプチャ機能を利用しました。 フレームキャプチャ機能は動画の静止画を作成するための機能になります。 サムネイル作成にあたっては既存で1本のレシピ動画を指定した秒数でクリッピングしているジョブがあるのでそこにフレームキャプチャを組み込むことにしました。 動画のキャプチャタイミングにはフレームレートを指定する必要があります。ドキュメントではコンソールによる設定を例にしていましたが、コンソールでは静的な値しか持つことができません。そのため、レシピごとに指定したいフレームが異なる今回の場合、コンソールによる設定ではなく動的な値を利用できる形で実装する必要がありました。 動的な値を利用するための実装方法は2つです。AWS CLIを使用してJSONによってジョブ仕様を設定する方法、あるいはSDKを使う方法です。今回は既存の実装がAWS CLIを用いていたため、フレームキャプチャのジョブ仕様もJSONで実装することにしました。 今回は弊社でMediaConvertが既に利用されていたこともあり、以下1-3の手順は特に行いませんでしたが、初めて利用する場合は以下の手順を踏む必要があります。 ファイル用のストレージを作成する Amazon S3 コンソールを使用してバケットを作成します。MediaConvert は、Amazon S3 または HTTP か HTTPS を使用するサーバーからの入力ファイルを受け入れます。 IAM のアクセス許可をセットアップする MediaConvert が S3 バケットに対する読み込みと書き込みを実行できるようにするには、それが担う Identity and Access Management (IAM) ロールを作成します。 符号化するソースファイルをアップロードする Amazon S3 コンソールを使用して、Amazon S3 バケットにソースファイルをアップロードします。 ジョブを作成する ビデオファイルを 1 つ、または複数の出力に変換するための MediaConvert ジョブを作成します。 引用元: AWS Elemental MediaConvert 公式ページ こちらが作成したJSONです。一部の設定は省略しています。 { " Settings ": { " OutputGroups ": [ { ... " Name ": " File Group ", " Outputs ": [ { " ContainerSettings ": { " Container ": " RAW " } , " VideoDescription ": { " Width ": <出力キャプチャの幅>, " Height ": <出力キャプチャの高さ> " CodecSettings ": { ... " Codec ": " FRAME_CAPTURE ", " FrameCaptureSettings ": { " FramerateNumerator ": < fps >, " FramerateDenominator ": <キャプチャするフレーム番号>, " MaxCaptures ": 2 , ... } } , ... } , " Extension ": " jpg ", " NameModifier ": <名前修飾子> } ] , " OutputGroupSettings ": { " Type ": " FILE_GROUP_SETTINGS ", " FileGroupSettings ": { " Destination ": <出力ファイルの格納先> } } } ] , ... " Inputs ": [ { " FileInput ": <入力ファイルの格納先> } ] } } 出来上がったサムネイルがこちらです。 実装にあたりつまづいたところ 本実装においては3点つまづいたところがありました。 フレームのキャプチャタイミングは秒数で指定できない 当初、キャプチャのタイミングは動画のクリッピングと同様にタイムコードで指定できるのかと思っていたのですが、フレームキャプチャではタイムコードでの指定ができない仕様となっていました。 次に思いついた方法がサムネイルにしたい秒数が動画のスタート時点となるよう元の動画をクリップして0フレーム目をサムネイルに指定する方法です（以下3.参照）。しかしこちらについてもMediaConvertは動画あるいはオーディオの出力があるジョブにおいてのみフレームキャプチャを作成することができフレームキャプチャのみの出力ジョブを作成することはできません。毎回不要な動画が作成されてしまうので断念しました。したがって今回は以下2で紹介するframerateによる設定を採用しました。 framerateの設定 キャプチャのタイミングを指定するには、framerateを設定します。具体的な設定は「framerate = framerateDenominator / framerateNumerator」となり、framerateDenominatorにはFPS（フレームレート）、framerateNumeratorはキャプチャしたいフレーム番号を指定します。 サムネイル作成時はキャプチャ対象の動画を確認しながら秒数でキャプチャのタイミングを指定していたため、これをフレーム番号に変換する必要があるのですがどうすれば適切に指定した秒数をフレーム番号に指定できるのか苦慮しました。 コンソールで確認するとframerateは以下のように設定することになります。この場合はビデオのフレームレートが30FPSで、50フレームごとに1フレームをJPEGファイルにキャプチャします。 (参考: AWS for M&E Blog ) 最大キャプチャ数は2にする必要があること MediaConvertは常に動画開始時点のフレームをキャプチャするため、2枚で設定しておかないと欲しいキャプチャは取得できません。 ジョブが完了すると、出力のS3バケットに2つのポスターフレームJPG画像が見つかるので2つ目の画像ファイル（ clip-poster.0000001.jpg ）が指定したフレーム番号のキャプチャ画像になります。 終わりに 本記事ではAWS Elemental MediaConvertを利用して動画のサムネイルを作成する方法を紹介しました。ここまでお読みいただきありがとうございました。

はじめに はじめまして、2023 年 4 月から新卒入社し retail HUB で Software Engineer をしているほんだ( @hon_d7174 )です。Go が好きです！ 現在、私たちは Next.js を使用して新規プロダクトを開発しています。このブログでは、私たちが取り組んでいるプロジェクトの中で工夫した点についてお話ししたいと思います。 また、既存のプロダクトを Next.js 13 へ移行した際の流れや工夫についてはこちらの記事をご覧ください: Next.js の Pages Router から App Router への移行に挑戦してみた プロダクト概要 当社のプロダクトは、小売様向けにアプリを提供しています。このアプリには、クーポンやお知らせ、アプリユーザーの動向を管理するダッシュボードが含まれており、小売様はこのダッシュボードを使用してアプリのユーザーやコンテンツの管理を簡単に行うことができます。 当社のプロダクトは、以下のような特徴を持っています。 マルチテナントアーキテクチャ 各小売様は、それぞれ独自のテナントとしてシステムを利用します。これにより、異なる小売様間でのデータやリソースの分離が実現されています。 アクセス制御 各テナントやユーザーには、閲覧・操作可能なリソース、利用可能なサービスが異なります。アクセス制御により、セキュリティを強化し、情報の漏洩や不正な操作を防ぎます。 システム構成 システム構成図 私たちの作成しているプロダクト簡単なシステム構成図は上記のようになっています。この中の web client と BFF に Next.js を用いています。 Library 以下は今回説明する内容に登場する主な Library になります。 SWR Auth.js(旧 NextAuth) 実装 プロダクト概要で述べたアクセス制御について一部実装について説明します。 Auth.js を用いた認証・認可の実装 はじめに認証・認可には Auth.js を用いています。Auth.js の interface を下記のように拡張しユーザー情報や Token を管理しています。Auth.js の cookie で管理することにより client side, server side で共通の状態管理が可能になります。下記では本プロダクトで実際に client side, server side で利用するサービス、テナントに関する情報を設定しています。 declare module 'next-auth' { interface User extends User { services: string[]; chain: string; chains: string[]; access_token: string; expires_at: number; } interface Session extends Session { user: { id: string; services: string[]; chain: string; chains: string[]; } & DefaultSession.user; access_token: string; expires_at: number; } } declare module 'next-auth/jwt' { interface JWT { services: string[]; chain: string; chains: string[]; access_token: string; expires_at: number; error?: 'RefreshAccessTokenError'; } } 次に client side において Auth.js で作成した JWE のデータにアクセスする方法についてです。 client side からアクセスする際には useSession() を用います。client side から JWE の更新が必要な際には useSession() の update と Auth.js の jwt callback を下記のように実装する必要があります。 const { data: session } = useSession(); <Menu mode="horizontal" items={chains} onClick={({ key }) => update({ chain: key })} {...props} /> jwt callback を下記のようにすることにより update で更新された session の内容を jwt にも反映することが可能になります。 callbacks: { async jwt({ token, user, session, trigger }) { if (user && trigger === 'signIn') { token.sub = user.id; token.email = user.email; token.name = user.name; token.services = user.info['services']; token.chain = user.info['mart'][0]; token.chains = user.info['mart']; } // sessionが更新された際にtokenも更新する。 trigger === 'update' && session.chain && (token.chain = session.chain); return token; }, middleware の実装 middleware では主に認証・認可状態の検証と HTTP リクエストヘッダの共通化、アクセス制御の実装を行なっています。 Next.js 13 の middleware は page 遷移時と route handler へのアクセス時の両方で同一の middleware が使われます。 middleware では hooks のような client side でしか使えない処理は行えないことに注意する必要があります。 認証・認可状態の検証は client side で用いていた useSession() ではなく Auth.js によって生成された JWE を取得することができる getToken() を用いて検証します。 export default async function middleware(req: NextRequest) { const newRequest = new NextRequest(req, req); const { pathname } = req.nextUrl; const token = await getToken({ req: req }); const accessToken = token.access_token; // tokenの有無を検証する const isAuthenticated = !!token; -------------------------------------省略-------------------------------------- // 認証が必要なページへの遷移、BFFへリクエストの際に検証を行う if (!isAuthenticated) { return NextResponse.redirect(`${process.env.BASE_URL}/signIn`); } -------------------------------------省略-------------------------------------- } 次に HTTP リクエストヘッダの共通化についてです。 本プロダクトでは以下の二つの header が主に共通で使われています。 一つ目は認証が必要な page, BFF へリクエストする際に必要な Authorization header です。 // AccessTokenをAuthorization headerに追加する。 newRequest.headers.set('Authorization', `${accessToken}`); 二つ目は各種リソースサーバーでテナントごとに異なる処理を行う際に必要なテナント header です。 // テナント情報が必要なエンドポイントか確認、必要な場合はheaderを追加する。 if (isMartAPIRoute(pathname)) { const chain = token.chain; newRequest.headers.set('X-Mart-Chain', chain); } SWR を用いた repository の実装 下記が BFF へのリクエストを行う client の実装になります。 ユーザー識別子( userID )とテナント情報( chain )を Auth.js の useSession() を用いて取得することで認証・認可状態の検証を行います。またこれらを cache key に含めることで同一デバイスで異なるユーザーがアクセスする状態やユーザーが複数のテナントを跨いで利用するケースで不整合が起きないようにしています。加えて userID または chain が falsy な値の場合 null を key として渡すことで認証・認可状態が正しくないときにリクエストが行われないようにしています。 function useCoupon(id: string) { // Auth.jsから認証・認可情報、ユーザー関連情報を取得する。 const { data: session } = useSession(); const chain = session?.user?.chain; const userID = session?.user.id; return useSWR(chain && userID ? [`/api/coupons/${id}`, chain, userID] : null, getCouponFetcher, { suspense: true, revalidateOnMount: false, }); } async function getCouponFetcher([url]: [string]): Promise<Coupon> { const res: Coupon = await fetch(url, { }).then(async (res) => { if (!res.ok) { const { message }: ErrorMessage = await res.json(); throw { message: message, code: res.status }; } return res.json(); }); return res; } 終わりに マルチテナントのアプリケーションということでユーザーに紐づく情報だけでなく現在そのユーザーがどのテナントに関連するリソースを操作しているかということを考慮する必要がある点が特異であると感じました。また詳細な権限設定はまだ実装していないのですがそれらを考慮するとさらに複雑性が増すのでより一層工夫が必要だと感じました。 マルチテナント・マルチサービスの開発を行おうと考えている人の参考になれば幸いです。 ここまで読んでいただきありがとうございました！

エブリーでCTOをしている imakei です。 エブリーでは定期的にCEOの吉田からスローガンが掲げられます。 今期のスローガンは 「挑戦」でした。 CEOのプレゼンから拝借 (※一部社内向けの内容があるので消してます) この記事では、開発部・エンジニアにとっての「挑戦」とは何なのか、 エブリーの開発部での解釈を共有できればと思います。 また、実はこのスローガンが決まる前から開発部で取り組んでいる 「挑戦WEEK」に関しても触れられればと思います。 エブリーの開発部における挑戦の考え方 詳細は後述しますが、エブリーの開発部では、4半期ごとに「挑戦WEEK」を実施しています。 今年3月から始めすでに2回実施しているのですが、その中でアンケートなどから挙げられた課題に、 事業部のロードマップを止めてまで、別のことやる意味がわからない あまり「挑戦」的な内容を実施できなかった など、挑戦とは何なのかが人によって違うことで生まれるものがありました。 そこで、自分の方で言語化したのが下記になります。 開発部における「挑戦」とは 事業における戦略の実現 技術的な観点からより上記を推進するための挑戦 中長期的な目線での強い開発組織の実現 である (※一部社内向けの内容があるので消してます) 1. 事業における戦略の実現への挑戦 さらに単純にいうとロードマップの実現・達成になるかと思います。 弊社に限らず、ベンチャー企業では常に高い成長率を求められます。 その中で立てられるロードマップはかなりアグレッシブなものが多く、 今まで通りの開発をしていては達成できないものも多いです。 その中で戦略を理解しつつ、それを最速で実現するための試行錯誤や開発を挑戦の1つとしています。 2. 技術的な観点からより上記を推進するための挑戦 1つ目と被るところもありますが、ここでは戦略を実現するだけではなく、 それをさらに進めることに焦点を当てています。 LLMをはじめ、AIや機械学習、また弊社であればOMOに関連する技術など、 昨今のプロダクトのコアを技術が担っていたり、技術を使うことでビジネスの幅が広くなったり、 自ら手を動かさないといけないと思っていた普段の業務のほとんどを技術で効率化できる時代になりました。 これらは技術を知らないと気付けないことも多く、エンジニアからの発信も含め 常に新しい技術に好奇心を持ち、それをどう使うかを考えることが重要になってきます。 3. 持続可能な 強い開発組織 への挑戦 ここでいう 強い開発組織 とは、それぞれにメンバーが単純に高いスキルを持ち合わせるだけでなく、 そのスキルを発揮し、事業を伸ばせる組織を指しています。 強い組織 のためにはまず、今まで上げてきたような挑戦ができる必要があるのはもちろん、 それが持続可能な状態にないといけません。 持続可能であるために、各々の挑戦が単発で終わるのではなく、 継続的に挑戦できるような仕組みづくり、失敗を恐れず挑戦を讃えられる文化づくりが必要です。 その観点からだと、「挑戦WEEK」自体がそもそも挑戦なのかもしれません。 また、持続可能な組織を作っていく上で 採用 も大切になってきます。 組織は常にスケールしており、また事業もどんどん拡大するなかであっても、 挑戦をし続けるためには仲間を採用していくほかにありません。 鶏卵な部分もありますが、強い組織・働きたいと思える組織づくりをしていくことで、 強い仲間を採用でき、強い仲間を採用することでより強い組織になっていくという良い循環を生みたいです。 挑戦WEEK さて、そんな弊社ですが、今年から「挑戦WEEK」というものを実施しています。 挑戦WEEKとは通常の各事業部のロードマップから離れ、技術的に何かに集中して挑戦する1週間を指しています。 上記の「挑戦」を踏まえると、 エブリーの 挑戦 を推進するために エンジニアリングを一歩前に進めるための WEEK と言えるでしょう。 挑戦WEEK 四半期ごとに実施しており、都度事業部の方にお願いして、 実施週は可能な限りミーティング等を0にしてもらい、 まとまった時間を開発に当てられるように調整してもらっています。 （寛容なみなさんにまじで感謝:pray:） 前述したようにすでに2回開催されており、11月に3回目を控えています。 第一回ではまだまだ「挑戦」が浸透せずに、日々の改善や、ただまとまって開発できる週として使ってしまうこともありましたが、 (それも事業部のためだったりするので、もちろんみんな偉いんですが、) 徐々に勘所が掴めてきているのか、11月回に向けては良い挑戦内容が集まっております。 まだまだ改善点も多いのですが、都度アップデートされていくのも楽しく、 今後、会社の挑戦を牽引する制度となるようさらに良いものにしていきたいです。 また第1回の様子はevery.thingで記事にもなっていますので、ぜひ覗いていってください！ https://everything.every.tv/20230428 さいごに エブリーの開発部における「挑戦」をまとめてみました。 技術的な挑戦だけでなく、事業を伸ばしたり、仲間を集めるための挑戦をし続けている会社です。 そんなエブリーでは、一緒に挑戦してくれる仲間を全方位で募集しております。 このブログで少しでもおもしろうそうだなぁと思ってくれた方は一緒に働きましょう！ https://corp.every.tv/recruits#position-list

はじめまして。株式会社エブリーの開発本部のデータ&AIチームでデータサイエンティストをしている古濵です。 最近話題のOpen Interpreterについて、実装の中身を追ったので簡単な解説と所感についてまとめました。 Open Interpreter Open Interpreterとは、LLMに指示を出し、ローカル環境でコードを実行するツールです。 公式のREADME によると、ChatGPTの機能として使えたOpenAI Code Interpreterとは異なり、Open Interpreterの売りはローカル環境で実行できることかと思います。 自然言語を通じて、対話的にPCの一般的な機能の操作や、ファイルの作成・編集、データ分析などがローカルで実現可能です。 さっそく、ローカルファイルに対して、自然言語でどの程度タスクを指示できるのか試してみました。 簡単なタスク（画像ファイルの移動操作を例に） Macでスクリーンショットを撮ると、デフォルトではDesktopに溜まると思います。 このスクリーンショットたちを指示通り引っ越しできるか試してみます。 指示として最初に与えた入力は以下です。 Desctop配下のスクリーンショットをDocuments配下にscreenshotというディレクトリを作って移動して 具体的なコマンドは一切教えずに試しました。 結果は以下になりました。 ここで、個人的に衝撃的だったのは、ローカルファイルに対してLLMで操作できていることではなく、 自分で問題に気づいて解決できている ことです。 mvコマンドが正常に動作していないことを理解した上で、lsコマンドを実行し、実行結果をもとにScreen Shotではなくスクリーンショットであること気づいて自己解決してしまいました。驚きです。 実装の解説 ここからが本題です。 自分で問題に気づいて自己解決できることをどう実現しているのか、Open Interpreterの実装の中身を追ってみました。 説明のため正確性よりもわかりやすさ重視しています。ご留意ください。 github.com 全体像 全体像としては、以下のような処理の流れです。 まず、ユーザの指示（ここではプロンプトと区別するために指示と表現します）を受け取り、LLMに渡すプロンプトを作成します。 次に、LLMがプロンプトをもとに、ユーザの指示に沿うプログラムを作成します。 最後に作成したコードを実行します。そして実行結果もしくはエラー文を再度LLMに渡すプロンプトに加えて作成し直します。 これをユーザが止めるまで繰り返します。 深掘り ここで注目したいのは、プロンプト作成部分です。 気になったのは以下の3点でした。 configのsystem message 参考テキストの提供（open procedures） 最大tokenを超えたとき処理 上記3点を全体像に反映させると以下のようになります。 それぞれ詳細を述べていきます。 configのsystem message OpenAIのapiを使用する際、内部では以下のmessegesのような構造を用いて、プロンプトを作成します。 response = openai.ChatCompletion.create( model= "gpt-3.5-turbo" , messages=[ { "role" : "system" , "content" : "You are a helpful assistant." }, { "role" : "user" , "content" : "Who won the world series in 2020?" }, { "role" : "assistant" , "content" : "The Los Angeles Dodgers won the World Series in 2020." }, { "role" : "user" , "content" : "Where was it played?" } ] ) roleには、system、user、assistantのいずれかが入ります。 userにはユーザーが出した指示、assistantはLLMの回答、systemはassistantの回答含めた動作を設定するために与えます。 system messageは必須ではありませんが、回答の品質を高めるためには重要な要素です。 原則プロンプトの最初に入れます。 詳しくは OpenAIのChat completions APIのドキュメント に書かれています。 Open Interpreterに最初に与えるsystem messageが、config内に書かれており、以下に個人的に気になったものを抜粋しました。 抜粋は翻訳をかけたものを貼ってるため、原文は リポジトリ をご参照ください。 あなたはオープン・インタープリター、コードを実行することでどんな目標も達成できる世界一流のプログラマーだ。 よくあるLLMに対して、ロールを明確にするプロンプトが書かれています。 まず、計画を書いてください。 各コードブロックの間に必ず計画を再確認してください 。 (あなたは極度の短期記憶喪失なので、計画を保持するために各メッセージブロックの間で計画を再確認する必要がある)。 Open Interpreterは実行前に手順を書いてくれるのは、このプロンプトが効いてそうです。 また、コードの内容を忘れないように強調してます。どの変数に何の値を入れているかなどを忘れないようにするためかなと思います。 あなたがコードを実行するとき、それは ユーザーのマシン 上で実行される。ユーザーはあなたに、タスクを完了するために必要なコードを実行する 完全かつ完全な許可 を与えています。あなたは、そのユーザーを助けるために、そのユーザーのコンピュータをコントロールするための完全なアクセス権を持っています。 コードを実行できることがOpen Interpreterの凄さのひとつなので、実行できるように強調しているのかもしれません。 インターネットにアクセスできる。目標を達成するために あらゆるコード を実行し、最初は成功しなくても、何度も試してください。 最近のニュースについて聞くなどした場合、クローリングして情報を得ようとするのは、このプロンプトが効いてそうです。 一般的に、できるだけ少ないステップで 計画を立てる 。その計画を実行するために実際にコードを実行することに関しては、 1つのコードブロックですべてを行おうとしないことが重要です。 何かを試し、それに関する情報を印刷し、そこから小さな、情報に基づいたステップで続けるべきです。一回でできるようになることはないし、一回でやろうとすると、目に見えないエラーにつながることが多い。 ここで書かれているように、一度にコードは数行程度で生成・実行してくれます。 仮にエラーが出てもリカバリしやすく、Open Interpreterならではのプロンプトかなと思いました。 あなたには どんな 仕事もできる。 最後に励ましだけのプロンプトもあるので興味深いです。 参考テキストの提供（open procedures） この処理では、ユーザが指示したタスクを解決する上で参考になるテキストを提供しています。 参考テキストも、system messageとして入力しています。 github.com まず、あらかじめタスクとタスクに関連するテキストを紐づけた構造データ（text_db）を用意します。 このデータをベクトル化して、vector_db内にembeddingsを保存しておきます。 次にOpen Interpreterから指示がpostされると、search api内で指示もベクトル化します（query_embeddings）。 最後に、embeddingsとquery_embeddingsのコサイン類似度を計算し、似ている上位2件のテキストを返します。 参考テキストが実際に役立つのは、ユーザが指示したタスクが、text_db内の内容と関連するときのみです。 参考テキストを埋め込んでしまったら最後、プロンプト内にノイズとして入ってしまうのでは思いましたが、以下のようなプロンプトも同時に添えて制御しているようです（ 参考 ）。 計画の中で、もしタスクに関連するのであれば、上記の手順からステップと、もしあるのであれば、 正確なコードの断片 （特に非推奨の通知の場合は、 --各番号のついたステップの下にそれを計画に書き込んでください ）を含めてください。 繰り返しますが、もしタスクに関連するのであれば、上記の手順から 逐語的な コードの断片 を、直接あなたの計画に含めてください。 結構強引だなと思いましたが、 OpenAI apiのドキュメント にも似たようなことが書かれているため、プロンプトエンジニアリングではよくある制御方法なのかもしれません。 最大token数を越えたときの制御 tokenとは、文章を意味を持つ最小単位にしたものです。 Open Interpreterで用いることができるLLMにはいくつかの選択肢があり、各モデルごとに最大token数が設定されています。 gpt-4は8192、より安価なgpt-3.5-turboは4096、ローカルで使えるCode Llamaは1048といった具合です（ 参考 ）。 このtoken数を越えないように制御する必要があり、 OpenAIの対処法 としては、以下の方法が挙げられています。 前の会話の要約orフィルタリング 前の会話を区分的に要約して連結し、要約の要約を作成 しかし、Open Interpreterでは、以下の手法をとっています。 token数の割合を用いて、文頭と文末からそれぞれ文字を取得し、間を ... で連結 まず、(必要token数 / 使用token数) * メッセージ文字数で、プロンプトとして使用する文字数を決めます。 次に、決めた文字数を2で割った文字数（=half_length）を起点として、文頭からhalf_length数の文字と文末からhalf_length数の文字を取得します。 最後に、文頭 + ... + 文末というように連結して、token数が越えないように制御します。 github.com Open Interpreter内のデータ構造 これまでの説明で、プロンプトが作成できました。 ここからこのプロンプトをLLMに渡し、コードを実行します この処理の流れの中で、Open Interpreterは下記フォーマットのデータ構造を管理しています。 messages: List[Dict[ str , Any]] このフォーマットで時系列順に作成されるイメージが以下になります。 ユーザ〜コード実行の間はループし続けるため、会話が続けば {role: user} と {role: assistant} が交互に続いていきます。 Open Interpreterを利用する上での課題 Open Interpreterの実装を追うことで、よりその凄さが鮮明になってきました。 しかし、試す中で以下のような問題点も見えてきました。 コスト Open Interpreterはプロンプトに様々な工夫がありますが、この工夫を実現しているがゆえに、inputとoutputのtoken数が肥大化してしまいます。 結果として、コストが増加していきます。 精度 コストを削減するために、LLMモデルとして安価なgpt-3.5-turboやローカルでCode Llamaを使うことができますが、gpt-4と比べると正直精度が微妙でした。 Open Interpreterに限りませんが、最大token数があるためLLMとの会話は無制限に続けられません。 Open Interpreterはtokenの使用量も増加しやすい上に、最大token数を越えたときの制御を要約ではなく間を ... で補間するため、数回の会話で過去の会話内容を忘れ、必要な情報が抜け落ちる可能性があります。 これが少なからず精度に影響があるかもしれません。 コードの実行を期待しない場合はミスマッチ Open Interpreterは基本どんな問題に対しても、コードを作成・実行して解決しようとします。 そのため、コードを作成したい目的だと非常に良いツールですが、それ以外の目的だと回りくどく感じます。 例えば、pdfを要約してほしいと指示したとすると、ユーザが欲しいのは要約したテキストだけです。OCRや要約用のライブラリをインストールして実行するコードを求めていません。 まとめ Open Interpreterに関して、実装の簡単な解説と所感をまとめました。 Open Interpreterに触れる事で、その凄さを体感することができ、プロンプトエンジニアリングについても理解を深めることができました。 今後のアップデートも引き続きキャッチアップし続けようと思います。

はじめに こんにちは。DELISH KITCHEN 開発部で小売向き合いの開発をしている池です。 弊社では小売事業者が自社ネットスーパーアプリをスピード導入できるプラットフォームを提供しています。 https://biz.delishkitchen.tv/retailhub ネットスーパーアプリの開発に Flutter を利用しており、日々事業拡大に向けて開発を進めています。 本記事では、最近開発を進めている中で下記 2 つのパフォーマンス改善に繋がった事例について、DevTools の Performance View を交えながらご紹介します。 Flutter 3.10 アップデートに伴う Shader compilation jank 解消 GridView のパフォーマンス改善 パフォーマンス改善の前提知識 DevTools Performance View Flutter には DevTools というパフォーマンスおよびデバッグツールが標準で備わっており、その中の一つの機能に Performance View という機能があります。この機能は、フレームごとのパフォーマンスメトリクスをキャプチャして視覚化する機能です。この機能を利用することで後述するジャンクという低パフォーマンスなフレームとそれに関連する処理を検出することができます。 フレームチャート フレームチャートでは、フレームごとの描画の処理時間が表示されます。色のついたバーの各セットは 1 フレームの処理時間表しており、色によって UI 処理時間、Raster（GPU）処理時間 等を表しています。 タイムラインイベントチャート タイムラインイベントチャートでは、フレームチャートでバーを選択すると、対応するフレームの詳細が表示されます。UI スレッドと Raster（GPU）スレッドの両方のフレームを構築した全てのイベントを確認することができます。 ジャンクとは 画面の描画について、1 フレームを描画するのに 1 フレーム以上の描画時間がかかってしまうと、該当のフレームは描画されずスキップされます。その場合、アプリ画面はコマ飛びのようにガタついた表示となります。このような低パフォーマンスなフレームをジャンクといいます。 1 フレームは、60fps デバイスだと 1/60 ≒ 16 ミリ秒なので、各フレームの描画時間が 16 ms 以下でなければ、UI が乱れたり、フレームが落ちたりすることがあります。 そのようなジャンクフレームは Performance View のフレームチャートではオレンジ色として表示されるため、フレームチャートを利用することで検出することができます。上記フレームチャート画像をみると、オレンジ色になっているバーが確認できると思います。 Flutter 3.10 アップデートに伴う Shader compilation jank 解消 弊社ネットスーパーアプリでは現在 Flutter 3.10 へのアップデート対応を進めています。Flutter 3.10 では Impeller という新しいレンダリングエンジンが iOS のデフォルトのエンジンとして設定されました。Impeller により 後述の Shader compilation jank という起動時のパフォーマンス低下の問題が解消されるので、その内容について Performance View を利用して確認していきます。 Shader compilation jank とは Shader compilation jank は 前述したジャンクの一種です。 Flutter のパフォーマンス問題の一つに、初回アニメーション時に大きくガタつく問題があります。シェーダーは GPU 上で動作するコードの一部で、Flutter が従来レンダリングに使用している Skia グラフィックスライブラリは、新しい描画のコマンドを初めて見たとき、カスタム GPU シェーダを生成してコンパイルすることがあります。この Skia によるシェーダー生成とコンパイルは、フレームのワークロードと順に行われます。コンパイルにはカスタム GPU シェーダによっては数百ミリ秒かかる可能性があり、この重たいコンパイルによってフレームが欠落し、大きくガタつくような動作となります。これが Shader compilation jank です。 Shader compilation jank 解消確認 Flutter 3.3.10 バージョンアップ前の Flutter 3.3.10 で Shader compilation jank の発生を確認します。 アプリの初回アニメーションを動作させた際の Performance View が次の画像です。赤黒く表示されている箇所が Shader Compilation の処理時間となります。 4.4ms と当アプリでは影響は少ないですが、発生していることが確認できます。 Flutter 3.10.6 次に、Flutter 3.10.6 にアップデートした状態で、同様に Performance View を確認します。 赤黒く表示されていた Shader Compilation がなくなっていることが確認できました。 GridView のパフォーマンス改善 次に、GridView のパフォーマンス改善についてご紹介します。 弊社ネットスーパーアプリには、カテゴリに所属する商品をグリッド形式で表示する画面があります。無限スクロール機能により画面をスクロールダウンしていくと、次々に要素を読み込むようになっています。この画面においてパフォーマンスの低い実装となっていたため、これから説明する改善方法を試しました。 GridView とは GridView は上記アプリ画面のようにグリッド形式で要素を表示する際に使用する Widget です。 弊社ネットスーパーアプリのように大量の要素を表示するグリッドでは GridView.builder コンストラクタを使用することが公式に推奨されています。GridView.builder コンストラクタを使用することで、画面の表示領域に必要な要素のみがビルドされ、領域外の要素は領域内に入ったタイミングで動的に描画されるような、遅延描画を実現することができます。 次のサンプルで画面をスクロールすると、console にビルドされたタイミングで文字が表示され、遅延描画されていることが確認できます。 GridView のパフォーマンスが低下する実装例 GrieView を他の Widget と一緒に縦方向に並べてスクロールさせたいケースを考えます。 この実装に Column と SingleChildScrollView を組み合わせた次のサンプルのような実装を試してみましょう。先ほどと同様に console でビルドされたタイミングを確認すると、遅延描画されずに全ての要素が同時にビルドされていることがわかります。 これは shrinkWrap が true の場合において、GridView が自身の子 Widget に合わせて高さを調整するためです。親である SingleChildScrollView と Column は高さが無制限であるため、GridView は事前に全ての子要素の高さを計算し、その高さに基づいてスクロールを設定します。そのため全ての要素が同時にビルドする必要があり、遅延描画されずパフォーマンスが低下します。また、shrinkWrap を false にすると、無制限の高さと認識され、エラーとなります。 弊社ネットスーパーアプリでも同様の実装となっており、表示領域外の要素も同時にビルドされていました。Performance View で確認すると、次の画像のように StaggeredGrid の下で大量の要素が生成されています。 GridView のパフォーマンス改善の実装例 この問題は CustomScrollView と SliverGrid を使用することで回避することができます。 このコードでは、CustomScrollView 内に SliverToBoxAdapter で ListTile を配置し、さらに SliverGrid を配置しています。SliverGrid 内では、SliverChildBuilderDelegate を使用して子要素を動的に生成しています。これにより複数の Widget を縦に並べたスクロール画面において、Grid の要素の遅延描画を実現することができました。 弊社ネットスーパーアプリの該当実装を同様に修正すると、GridView により生成される要素数が大幅に削減され、スクロールで動的に遅延描画されるようになりました。 おわりに 今回はパフォーマンス改善に繋がる事例を 2 つ、Performance View を交えながら紹介しました。 Performance View を利用することで、普段開発している中では気付きにくい低パフォーマンスフレームやその処理のボトルネックを検出することができます。 今回ご紹介した改善は大きな改善ではないですが、小さい改善の積み重ねがユーザビリティの高さに繋がると思うので、今後もパフォーマンスを意識しながら開発を続けていければと思います。 この記事が少しでも Flutter 開発の参考になれば幸いです。ありがとうございました。 参考 https://docs.flutter.dev/tools/devtools/performance https://docs.flutter.dev/perf/shader https://docs.flutter.dev/perf/best-practices#be-lazy https://youtu.be/LUqDNnv_dh0?feature=shared

初めまして，トモニテ開発部でSoftware Engineer(SE)をしている鈴木です． SEチームはAPI開発からそのAPIを利用したweb開発まで幅広い領域を担当しており，トモニテ開発部のweb開発には Next.js を採用しています． また，エブリーの開発部では定期的に挑戦week(※)なるものを開催し，技術的観点から事業貢献を行う1週間を設けており，その中でNext.jsの Pages Router を App Router に移行する機会を頂けたので紹介させていただきます． ※ 挑戦weekについては以下のオウンドメディアで記事にしています．今回の挑戦weekは事業部の垣根を超えたチーム編成で行い，大変面白いものでした！ エンジニアが楽しみながら開発体験を向上させる「挑戦week」を実施しました！ 背景 Next.jsでルーティングを行う際， v13以前は Pages Router を利用する必要がありましたが，v13以降は App Router という仕組みが選択肢に加わりました． App Routerは React の最新機能（ React Server Components や Suspense など）に追従したルーティングシステムであることから，Next.js公式には 新しいアプリケーションを作成する際にはApp Routerの利用が推奨 されており，既にApp Routerでしか利用出来ない機能の開発も見受けられます． これらのことから，幾つかのメジャーアップデートを経てApp RouterがNext.jsのルーティングシステムの主流になることが予想されるため，長期にわたりNext.jsの最新機能に追従していくためにはPages RouterからApp Routerへの移行が必要だと判断し挑戦する運びになりました． 移行対象 影響の大きさを鑑みて，移行対象にはトモニテで利用しているdashboardを採用しました． 移行の流れ 1. Pages Routerの各ページをApp Routerのページに変換するスクリプトの作成 当然ですが，App Routerへ移行するためにはPages Routerのページを移行することが必須です． Pages RouterとApp Routerは 共存が可能 なため，1ページずつ移行していくことが出来るのですが，一つずつ置換していくと移行を終えるまでにかなりの時間を要してしまうことや，dashboard以外にもApp Routerに移行したい対象があるため，一括で置換するスクリプトを作成することになりました． 公式からは Codemods の置換スクリプトは提供されていないため，Pages Routerの各ページに対し以下のルールに基づいた変換をするスクリプトを自作しました(※)． 手間は要しますが実装に困難な点はそれほど無いかと思います． use client の付与 [xxxx].tsx を [xxxx]/page.ts に変換 xxxx/index.tsx を xxxx/page.tsx に変換 xxxx.tsx を xxxx/page.tsx に変換 ※参考程度になりますが Gist で公開しています 2. ログイン前後のレイアウトの作成 トモニテのdashboardはログイン前後でレイアウトが異なるため，それぞれのレイアウトを作成しました． dashboardはログイン前にしかアクセス出来ないページとログイン後にしかアクセス出来ないページに二分されていたため， Route Groups という機能を用いることで比較的簡単にレイアウトの出し分けを実現出来ました． 以下のように括弧で囲まれたディレクトリ名をつけることでRoute Groupsを利用出来ます. app ├── ( loggined ) │ ├── layout.tsx │ ... └── ( unloggined ) ├── layout.tsx ... 3. _app.tsx 及び _document.tsx と等価な処理の再現 App Routerでは _app.tsx と _document.tsx が廃止されたため，それらが行っていたことと等価なことを file conventions や middleware を用いて再現する必要があります． トモニテのdashboardでは _app.tsx でsessionの管理やレイアウトの出し分けなどを， _document.tsx ではヘッダーの管理などを行っていたため，middlewareと layout.tsx を用いて再現しました． 注意点として，App Routerでは Header コンポーネントが廃止 されており，代わりに layout.tsx から Metadata オブジェクト をexportするようになっています．このMetadataオブジェクトですが，Headerコンポーネントを用いて実現していたこと全てが再現出来る訳でなく，例えば CDNからstylesheetを読み込むことが出来なく なっています．この点については，closeはされていますが issue にもなっており解決するのには時間がかかりそうであることと，幸いなことにファイルのimportで解決できるもの以外は影響が小さかったため後回しにすることになりました． 4. ルーティングに関するhooksの移行 App Routerではルーティングに関するhooksを next/router ではなく next/navigation からimportするように変更 されており， useRouter hookが持っていた役割も useRouter と usePathname ， useSearchParams の3つのhooksに分解されています．従って，画像のように，next/routerを用いて router.push と記述していたコードはnext/navigationのuseRouterを， router.query と記述していたコードはuseSearchParamsを用いて置換する必要があります． useRouterの利用箇所自体は多岐に渡っていたため，修正にはだいぶ手間が必要となりました． また，この際，従来のuseRouterが持っていた events 等の一部の機能がnext/navigationでは実装されていないことに注意が必要です．eventsが実装されていないことから，Pages Routerで簡単に実現出来ていたページ遷移中の処理をApp Routerでは簡単には実現出来なくなりました． 公式からは usePathnameとuseSearchParamsを利用したコンポーネントを作成することによる再現方法 が提示されており，これを用いれば再現可能かと思われますが，トモニテのdashboardではページ遷移の進捗を表示するためのプログレスバーにしか用いておらず，進捗を確認するニーズの有る程重いページが存在しなかったため，再現せずに先に進むことになりました． ルーティングに関するhookの遷移 5. その他 React Server ComponentsではRuntime Configが利用出来ない ため，環境変数で置き換えるなどの移行作業をしました． 移行作業を通して感じたポイント 移行作業を通して， _app.tsx 及び _document.tsx の大きさが移行コストの大部分を決定するように感じました． これらのファイルで行っている事が大きいほどApp Routerのfile conventionsやmiddlewareに対する知識と実装経験が求められるためです． また出来なくなることや，再現に一手間が必要になることを整理した上で移行に望むと見通しがつきやすいように思います． まとめ 「Next.jsのPages RouterからApp Routerへの移行に挑戦してみた」と題し，実際に挑戦week中に行った移行作業について紹介させていただきました． 後回しにしたものなど一部やり残しはありつつも，主要部の移行自体は出来たのではないかなと思っております． 何より，移行作業を通してfile conventionsやRoute GroupsなどのApp Routerでのみ利用出来る機能を学び，利用することが出来，知的好奇心が刺激された一週間でした． アプリケーションの規模や利用している機能に依存しますが，移行する際にはおおよそ同様の流れを取るのではないかと感じており，この記事がPages RouterからApp Routerへの移行を検討されている開発者の方々のお役に立てたら大変嬉しいです． ここまでお読みいただきありがとうございました！

DELISH KITCHEN はレシピを動画でわかりやすく基本的な料理からアレンジまで様々なレシピを公開しています。 実はレシピ動画以外にも、季節にそったおすすめレシピ、素材についての解説、料理に役立つ情報などが記事にまとめられ公開されています。ご存知でしたか？ 例えばこういった記事です。 食欲の秋にピッタリ！秋が旬の野菜を使ったレシピ6選 なす？なすび？呼び方の由来について解説します！ 坊ちゃんかぼちゃを詳しく解説・特徴やレシピもご紹介♪ だし汁とは？簡単なだしの作り方もご紹介！ 今回は、この記事を Android アプリで閲覧できるようにした話をしたいと思います。 記事とは まずは一例を見ていただければと思います。 目次 本文 記事の概要と見出し おいしそうな出汁… レシピ動画は料理の手順を簡単に把握しやすいのですが、一方で素材の魅力にふれるにはあまり適していない表現方法かと思います。記事では、そういった素材の魅力であったり、より詳細な解説や料理に役立つ情報などを紹介しています。 粉末だしとはその名の通り、鰹節や昆布などの素材を乾燥させて粉末状に加工したものです。製造過程で熱を加えていないため、より素材の自然な風味を感じられます。 なるほど…ふだんは顆粒だしを使っているのですが、今度は粉末だしを使ってみようかな？ 記事のデータ 早速ですが記事について技術面の話をしたいと思います。 まずは記事を構成するデータの構造についてです。 ※ 以降の内容は具体的な処理については割愛し、掲載するデータもイメージとなります 先に紹介した記事の内容は記事 API を介して JSON 形式でデータを取得します。 { " article_id ": 123456 , " title ": " だし汁とは？簡単なだしの作り方もご紹介！ ", " description ": " 和食におけるだし汁の役割はとても大きく… ", " thumbnail ": " https://tech.blog.com/images/header.png ", " created_at ": " 2022-06-02T16:00:00Z ", " contents ": [ { " type ": " image ", " image_url ": " https://tech.blog.com/images/main.jpeg " , } , { " type ": " header1 ", " text ": " 和食に欠かせないだし汁とは？ " } , { " type ": " paragraph ", " text ": " だしにはさまざまな種類がありますが、中でも一般的によく使われている素材が鰹節や昆布… " } , ... } 記事は title や description など記事共通の要素の他に、本文などが含まれる contents で構成されています。 contents は記事の内容を柔軟に表現できるよう可変長になっています。その中身は、要素を区別する type と内容（テキストや URL など）の組み合わせで構成されたオブジェクトです。 これらのデータはアプリ側で扱いやすいように type で区別して各要素に変換します。 sealed class Content { // 見出しの属性として sealed class Headline : Content() { abstract val headline: String abstract val subHeadline: String ? } // 見出し１ data class Headline1( override val headline: String , override val subHeadline: String ?, ) : Headline() // 見出し２ data class Headline2( override val headline: String , override val subHeadline: String ?, ) : Headline() // 段落 data class Paragraph( val text: String , ) : Content() // 画像 data class Image( val imageUrl: String , ) : Content() ... } パースされた要素はリスト（RecyclerView）に追加します。 リストへの追加 各要素を RycyclerView に add するタイミングで type に応じた ViewHolder に変換して追加します。 以下、Groupie を使って作成した Adapter と ViewHolder の一部です。 ※ Groupie に関する詳細は github を参照してください class ArticleAdapter( private val listener: Listener ) : GroupAdapter<GroupieViewHolder>() { ... interface ContentItem interface SectionItem : ContentItem interface TitleItem : ContentItem interface SubTitleItem : ContentItem interface DescriptionItem : ContentItem interface OtherItem : ContentItem private class ContentHeadline1Item( private val item: Content.Headline1 ) : BindableItem<ItemContentHeadline1Binding>(), TitleItem { override fun getLayout() = R.layout.item_content_headline1 override fun initializeViewBinding(view: View) = ItemContentHeadline1Binding.bind(view) override fun bind(viewBinding: ItemContentHeadline1Binding, position: Int ) { viewBinding.title.text = item.headline } } ... } ContentHeadline1Item は ViewHolder です。このように、要素に合わせた ViewHolder を用意して各要素を変換します。 ここで ContentItem や SectionItem などの interface が気になった方がいらっしゃるかもしれません。この interface については後ほど触れたいと思います。 要素間のマージン ViewHolder に変換した要素は ViewHolder 内で指定したレイアウトが適用されます。下図のようにレイアウト内であれば目次のタイトルやリストなどマージンの調整は容易ですね。では、要素間のマージンはどうでしょうか？ 目次は通常の layout.xml 内で完結できるので簡単です 見出しなら上部に 24 dp、画像なら上下に 16 dp のように要素ごとに固定のマージンなら単純だったのですが、記事の場合は前の要素によってマージンを変更する必要がありました。ひと手間かける必要がありそうです。 結論から言えば、今回の要素間のマージンは RecyclerView の ItemDecoration を使って解決しました。ItemDecoration はリストに追加されるアイテムにオフセットを追加する便利な仕組みを持っています。 この ItemDecoration の実装で先ほど触れた ContentItem などの interface が役に立ちます。 準備として、各 ViewHolder に適した interface を関連付けておきます。 以下、実装の一部です。 class MarginDecoration( resources: Resources, @IdRes private val space: Int ) : RecyclerView.ItemDecoration() { // space を元に必要な marginXX を定義 ... override fun getItemOffsets(outRect: Rect, view: View, parent: RecyclerView, state: RecyclerView.State) { val itemCount = parent.adapter?.itemCount?.let { it - 1 } ?: 0 val position = parent.getChildAdapterPosition(view) // 最後の要素は下にもマージンを設ける val bottom = if (itemCount == position) margin40 else 0 // 最初の要素は上のマージンを固定 val top = if (position == 0 ) margin24 else null // 上のマージンは前の要素との関係によって決定するため、一つ前の ViewHolder を取得する val previousHolder = if (position > 0 ) (parent.adapter as? ArticleAdapter)?.findContentItemBy(position - 1 ) else null val currentHolder = parent.getChildViewHolder(view) as? GroupieViewHolder // 前の要素との関係でマージンを変える判定をここで行う when ( val item = currentHolder?.item) { is TitleItem -> outRect. set ( 0 , top ?: margin40, 0 , bottom) is SubTitleItem -> when (previousHolder) { is SectionItem -> margin40 else -> margin24 }.let { outRect. set ( 0 , top ?: it, 0 , bottom) } ... is OtherItem -> outRect. set ( 0 , top ?: margin24, 0 , bottom) else -> { // nothing } ... } getItemOffsets() はリストに要素が追加されるタイミングで要素にオフセットを追加することが可能です。パラメータの outRect に set(left, top, right, bottom) することで要素にマージンを適用します。 outRect.set() する際に現在の要素が SubTitleItem で前の要素が SectionItem なら 40 dp …と考えられる組み合わせを条件で定義して適切なマージンを設定しました。 以下、記事を実装した結果です。 目次 本文 アプリ版の目次部分 アプリ版の本文 ContentItem などの interface を用意したことで5種類の interface といくつかの要素を考慮するだけで済みました。新しく要素を追加する場合も適した interface を関連付けるだけで済みます。記事の要素として用意された type は10種類以上あるので、個別に対応することを考えると…脳が震えます。 最後に こうして DELISH KITCHEN の Android アプリでも記事が閲覧できるようになりました。一生懸命作った機能ですし、読み物としても面白いと思うので、ぜひ色々な記事を読んでみてほしいです。

はじめに iOSにはデフォルトで「ヘルスケア」というアプリが存在することをご存知でしょうか。 弊社のDELISH KITCHENアプリでは昨年ヘルスケアという新機能をリリースしましたが、日々改修を重ねていく中でヘルスケアアプリにも着目し、色々と調査を行いました。 今回はその調査内容について纏めていきたいと思います。 ヘルスケアアプリとは 赤丸で囲ったものがヘルスケアアプリです。 こちらのアプリでは、歩数などのアクティビティ情報や、血圧などのバイタル情報といった健康・医療情報を一つのアプリで管理できるものとなっており、簡単に情報を閲覧・編集することができます。 私の場合、Apple Watchで歩数を記録し、ヘルスケアアプリで一週間の平均歩数を確認する、といった使い方をしています。 まだ使用されたことがない方は一度触れてみてはいかがでしょうか。 HealthKitについて https://developer.apple.com/jp/health-fitness/ プログラムからヘルスケアアプリの情報にアクセスする場合、 HealthKit を使用します。 HealthKitを使用することで容易にヘルスケアアプリの情報にアクセスすることができます。 https://www.proofpoint.com/jp/threat-reference/hipaa-compliance 余談にはなりますが、医療分野で業務を行う立場の場合は HIPAA という法律に従うことになります。 今回はHIPAAについて深くは触れませんが、健康情報を記録するアプリ(非HIPAAアプリ)と医療行為に関わるアプリ(HIPAA対象アプリ)で作成するプライバシーポリシーやアプリ申請内容が異なりますので、よく内容を理解してから実装することをお勧めします。 ヘルスケア連携手順 ここからは実際にプログラムからヘルスケアに連携する方法を纏めていきたいと思います。 今回はHealthKitを使って歩数の情報を取得する方法を纏めます。 開発環境 Xcode Version 14.3.1 (14E300c) 開発言語 : swift Capability追加 TARGETS > Signing & Capabilities にて、HealthKitを追加 今回、臨床記録のデータにアクセス、およびバックグラウンド配信は行わないため、以下のチェックは不要です。 info.plist更新 info.plistにて、以下2項目を追加 - Privacy - Health Update Usage Description … ヘルスケアのデータを更新するための許可を求める時に表示される文言 - Privacy - Health Share Usage Description … ヘルスケアのデータを取得するための許可を求める時に表示される文言 Valueに書かれた文字列が、後述する権限確認ダイアログに表示されます。 認証処理実装 ここからは実装に入ります。 let healthStore: HKHealthStore init() { healthStore = HKHealthStore() } HKHealthStore のインスタンスを介して認証、取得、更新を行いますので、まずはインスタンスの生成をしておきます。 func auth() { // 更新したいデータ let shareTypes = Set([ // 歩数 HKQuantityType.quantityType(forIdentifier: HKQuantityTypeIdentifier.stepCount)! ]) // 取得したいデータ let readTypes = Set([ // 歩数 HKQuantityType.quantityType(forIdentifier: HKQuantityTypeIdentifier.stepCount)! ]) // 認証実施 healthStore.requestAuthorization( toShare: shareTypes, read: readTypes, completion: { success, error in if success { print("許可されました") } else { print("却下されました") } } ) } 次に認証処理となります。 requestAuthorization でユーザに対してアクセスする情報の権限確認ダイアログを表示します。 toShare には更新したいデータを設定、 read には取得したいデータを設定します。 ※plistで設定する情報とshareの意味が異なるので注意が必要です。 実行すると上記のような権限確認ダイアログが表示されます。 このダイアログには前述したplistに設定した文言が表示されます。 取得処理実装 ヘルスケアアプリからデータを取得する処理を実装します。 func getStepCount(fromDate: Date, endDate: Date) { let query = HKSampleQuery( // 取得したいデータの種別 sampleType: HKSampleType.quantityType(forIdentifier: .stepCount)!, // データの期間 predicate: HKQuery.predicateForSamples(withStart: fromDate, end: endDate), // 取得件数の上限 limit: HKObjectQueryNoLimit, // ソート sortDescriptors: [NSSortDescriptor(key: HKSampleSortIdentifierEndDate, ascending: true)], resultsHandler: { (query, results, error) in guard error == nil else { return } // 取得した結果をサンプリングデータの型に変換 if let itemList = results as? [HKQuantitySample] { for item in itemList { print("記録日時 : \(item.endDate)") print("歩数 : \(String(item.quantity.doubleValue(for: .count())))") } } } ) healthStore.execute(query) } HKSampleQuery でクエリの情報を作成し、 execute メソッドに流すという実装となります。 更新処理実装 ヘルスケアアプリからデータを更新する処理を実装します。 func updateStepCount(targetData: Date, stepCount: Double) { // 更新したいデータの種別 let type = HKObjectType.quantityType(forIdentifier: .stepCount)! // 設定するデータ let quantity = HKQuantity(unit: .count(), doubleValue: stepCount) // サンプリングデータ作成 let sample = HKQuantitySample(type: type, quantity: quantity, start: targetData, end: targetData) healthStore.save(sample, withCompletion: { (success, error) in if success { print("成功") } else { print("失敗") } }) } HKQuantitySample でサンプリングデータを作成し、 save メソッドに流すという実装となります。 取得・更新時の注意点 取得・更新処理を前述しましたが、データを取り扱う際の注意点があります。 // 設定するデータ let quantity = HKQuantity(unit: .count(), doubleValue: stepCount) 更新処理のこちらの部分ですが、インスタンスを生成する際に第1引数に HKUnit を設定しています。 https://developer.apple.com/documentation/healthkit/hkunit HKUnitは「単位」のクラスになりますが、実装する際は設定するデータと単位が一致しないとExceptionが発生してしまいます。 今回は歩数のため、カウントの単位を返す.count()を設定していますが、 let quantity = HKQuantity(unit: .kilocalorie(), doubleValue: stepCount) のように、歩数にキロカロリーの単位を返す.kilocalorie()を設定してもビルド時にはエラーを検知できず、実行できてしまいます。 ヘルスケアアプリでは複数の情報を管理する都合上、単位の種類も多いのですが、適切な単位を設定する必要がある点に注意してください。 おわりに HealthKitを使用したヘルスケアアプリとの連携方法を纏めましたが、前述の設定、実装のみでアクセスできるため、敷居は低く、簡単に実装ができました。 近年、UIUXを向上させるためには簡単にデータを取得・編集ができる、別アプリと連携できることが必須だと感じていますが、健康志向の方も多くなり、またスマートウォッチが普及したこともあり、ヘルスケアアプリでデータを記録しているユーザも増えている印象なので、健康情報などヘルスケアアプリでも管理している情報を扱う際はHealthKitを導入することで十分な効果が見込めると思います。 今回はHealthKitの触り部分の紹介となりますが、ヘルスケア連携の実装を考えている方にとって少しでも参考になれば幸いです。

はじめに 子育てメディア「トモニテ」でバックエンドやフロントエンドの設計・開発を担当している桝村です。 2023年8月1日、MAMADAYSはトモニテに生まれかわりました。 tomonite.com アプリのメイン機能である「育児記録」「妊娠週数管理」「食材リスト」を軸として、家族やパートナー、家族以外の人や社会との接点を作るためのシェア機能やコミュニティ機能などの拡充をめざしていきます。 今回は、Continuous Profiling を実施することができる Pyroscope を使用して、トモニテで運用している Go サーバーのメモリリークを調査・改善した話をしたいと思います。 以前、 トモニテでEKSからECSに移行した話 という記事において、EKS on EC2 から ECS Fargate への移行に伴い、厳密なリソース管理の必要性が生じ、メモリリークを検出した件の対応になります。 tech.every.tv Pyroscope について Pyroscope とは Continuous Profiling を実施することができるオープンソースのプラットフォームです。 Continuous Profiling とは、ソフトウェアやアプリケーションが実行されている間、リアルタイムでパフォーマンスデータや実行情報を収集し、CPUやメモリ等のリソースをどこで多く消費しているか分析・チューニングする手法です。 2023年3月にデータ可視化ツール Grafana などを開発している Grafana Labs が Pyroscope を買収し、 オープンソース Grafana Pyroscope として統合されました。 本記事では Grafana Pyroscope の情報にも触れつつ、Pyroscope で Go サーバーのメモリリークを調査・改善した話となります。 Pyroscope でできること コード内のパフォーマンスに関連する問題やボトルネックを見つけることができます。例えば、CPU使用率の上昇やメモリリークの発生等です。 pyroscope の Single View 画面 タグ機能 Tags や時間指定により、UI上のプロファイリングデータを絞り込みできます。 pyroscope の Tags でのフィルタリング画面 ビュー機能 Comparison View により、2つの時間区間を並べて比較分析できます。 pyroscope の Comparison View 画面 ビュー機能 Diff View により、2つの時間区間の差分を取得してヒートマップのように色付けして比較分析できます。 pyroscope の Diff View 画面 参考: demo.pyroscope.io Pyroscope の仕組み Pyroscope Agent という言語ごとに用意されているプロセスが、アプリケーションの動作を定期的に記録・集計し、そのデータを Pyroscope Server に送信します。 Pyroscope Server がそのデータを処理・集約することで、ユーザーがプロファイリングの結果を WEB UI から Flame Graph (フレームグラフ)を閲覧することが可能になります。 なので、Pyroscope で Continuous Profiling を実施するには、 Pyroscope Agent と Pyroscope Server の設定が必要になります。 pyroscope の全体像 参考: pyroscope.io Grafana Pyroscope について 2023年3月にデータ可視化ツール Grafana などを開発している Grafana Labs が Pyroscope を買収し、 オープンソース Grafana Phlare と統合され、 Grafana Pyroscope になりました。 参考: grafana.com また、2023年8月末に　Grafana Pyroscope　として version 1.0 が公開されました。 このバージョンでは、以下をはじめとした改善が行われました。 Grafana と完全に統合され、Grafana ダッシュボードでメトリクスやログ、トレースなど他の可観測性の指標と一緒に Profiling のデータを表示可能になりました。 様々なオブジェクトストレージサービス (ex. AWS S3, Google Cloud Storage) との統合がサポートされ、プロファイルデータをストレージサービスに保存可能になりました。 水平方向のスケールアウトがサポートされ、あらゆる規模のプロジェクトで最適なパフォーマンスを出すことが可能になりました。 参考: github.com Pyroscope を活用したトラブルシューティング 問題だったこと トモニテで利用している Go サーバーの基盤である ECS のメモリ使用率が時間の経過とともに上昇し続けるという問題がありました。 もしサーバーのメモリ解放せず長時間経過した場合、サーバーの一時停止といったリスクがあったため、調査・改善が求められていました。 ECS メモリ使用率 改善前 Pyroscope の導入 ① Pyroscope Server の起動 Pyroscope Server をサーバー上で Docker 経由で起動しました。 Pyroscope によるリソース消費の最適化のため、データの保持期間 retention 、 exemplars-retention を調整し、それ以外の設定値は、デフォルトの値を利用しました。 ② Pyroscope Server と Go サーバーのネットワーク設定 それぞれでAWSアカウントが異なる構成だったのもあり、ネットワークの疎通のため、VPCピアリング接続やルーティングテーブルへのルートの設定をしました。 ③ Pyroscope Agent の起動 Profiling したいサーバーは Go 製なので、同様に Go の Pyroscope Agent を利用しました。 Pyroscope Server 側のリソース消費の最適化のため、 SampleRate を調整しました。 また、アプリケーションサーバー側の基盤が ECS なのもあり、バージョン単位でより詳細に分析できるように、 Tags にタスク定義のバージョンを設定しました。 // Init initialize func Init() { address := conf.PyroscopeAddress() if address == "" { return } pyroscopeConfig := pyroscope.Config{ ApplicationName: "tomonite-server" , ServerAddress: address, SampleRate: conf.PyroscopeSampleRate(), Tags: map [ string ] string { "taskArn" : ecs.TaskARN(), "taskDefinitionVersion" : ecs.TaskDefinitionVersion(), }, } if _, err := pyroscope.Start(pyroscopeConfig); err != nil { log.Alert(fmt.Errorf( "failed to start profiling for pyroscope. err: %w" , err)) } } Profiling の結果 時間の経過とともに Go サーバー全体に対してメモリの使用率が著しく上昇している処理を特定することができ、その処理は、 grpc-go というモジュールであることが分かりました。 ある時点A grpc-go のメモリ使用率はサーバー全体の15%ほど ある時点Aから12時間後 grpc-go のメモリ使用率はサーバー全体の30％ほど さらなる調査・改修対応 grpc-go は Go サーバー側で明示的に利用されている実装箇所を発見できなかったため、メインのモジュールとの依存関係を調査しました。 すると、Cloud Firestore データベースの読み取りと書き込みのためのクライアントを提供する cloud.google.com/go/firestore が依存していたことが判明しました。 $ go mod why -m google.golang.org/grpc github.com/everytv/tomonite-server/db cloud.google.com/go/firestore google.golang.org/grpc 実際に firestore 周りのコネクションが保持されてそのままになっている処理があったので、コネクションを解放するため、 (*firestore.Client).Close() を追記してリリースしました。 firestore のコネクションを解放する修正 その結果、Go サーバー全体に対するメモリの使用率の増加が顕著に緩やかになり、無事にメモリリークの問題を解決することができました。 ECS メモリ使用率 改善後 おわりに 今回は Pyroscope と Continuous Profiling 、Pyroscopeを活用したトラブルシューティングの事例について紹介しました。 Pyroscope を利用するメリットとして、WEB UIで直感的に操作できたり、ビュー機能である Comparison View や Diff View でより効率的な分析が可能なところだと考えてます。 Continuous Profilingをしておくことで、問題発生後に Profiling 結果を得て、即座に調査が可能になります。今後も Pyroscope をうまく活用してサービスの安定稼働を実現していきます。 また、Grafana Labs による買収・統合に伴い、さらなる機能開発が見込まれるため、今後の開発の動向を注視しつつ最新バージョンへのアップグレードも検討できればと考えています。

はじめに DELISH KITCHENで主にiOSの開発やマネジメントを担当している久保です。 以前、 DELISH KITCHEN iOSアプリ開発のCI環境について という記事でCI環境を紹介しました。 今回は、Xcode Cloudの導入経緯とCI/CD環境の変化についてご紹介します。 Xcode Cloudへ移行した理由 Xcode Cloud の発表以降、さまざまな試行を行ってきましたが、特に以下の理由から全面的な導入を決定しました。 他のサービスと比較して機能が少ないため、学習コストが低い TestFlightやApp Store Connectへのアップロード時に証明書の管理が不要 XcodeやmacOSのアップデートへの追従が速い ビルド番号の管理が不要 Firebase App DistributionからTestFlightに移行した理由 アプリ配布に使うサービスも、 Firebase App Distribution からTestFlightに移行しました。App Distributionを用いてAdHoc配信をしていた際には、以下の作業が発生していました。 インストールしたい端末のUUIDを登録 Provisioning profileの更新 これらの作業はfastlaneを使って半自動化していたのでそこまで手間ではなかったのですが、TestFlightを利用することによってこれらの雑務から解放されました。 Xcode Cloud以外を利用している場合は、App Store Connect APIを利用するようなスクリプトを組むことになると思うのですが、Xcode Cloudはここもよしなに処理してくれるというメリットがあります。 構成 Xcode Cloud導入後のアプリの社内向け配布およびApp Store Connectへ提出を行う全体のフロー図を以下に示します。 前回の記事ではfastlaneが色々な役割を果たしていたのですが、今回の用途に限るとfastlaneは不要になりました。 Release版のワークフロー App Store Connectへの提出と最終的な動作確認のための配布を行います。 特定のプレフィックスを含むタグがGitHubにプッシュされると、次のワークフローが実行されます。 TestFlightで内部テスターに配布 App Store Connectへの提出 成功または失敗をSlackチャンネルに通知 Develop版のワークフロー 主に社内関係者への配布を行います。別アプリとして扱いたいため、Release版とは別のバンドルIDを設定しています。 こちらも同様に、特定のプレフィックスを含むタグがGitHubにプッシュされると、次のワークフローが実行されます。 TestFlightで内部・外部テスターに配布する 成功または失敗をSlackチャンネルに通知 内部・外部テスターの使い分け 内部テスターと外部テスターの使い分けに関して、以下に簡単な違いをまとめました。 内部テスター (Internal Testers) 外部テスター (External Testers) Apple ID App Store Connectで管理されたApple IDが必要 特に制限なし 配布までの時間 アップロード後即時 審査通過後 デザイナーやプロダクトマネージャーなど、すぐに確認してもらいたい場合は内部テスターを、手軽に確認したい利用者向けには外部テスターを利用してもらっています。 まとめ Xcode Cloudの導入により、特にデプロイに関連する作業がシンプルになりました。 あえて気になる点を挙げると 設定がGUI App Store Connectに存在しないアプリに対してワークフローが設定できない 任意のスクリプトを実行する機構 はあるが、実行タイミングが限定的 キャッシュの設定などが不明瞭 などが考えられます。 今回はデプロイに焦点を当てた内容になりましたが、iOS開発の取り組みに関して少しでも知っていただければ幸いです。

Google CloudのData Analytics Workshopに参加してきました! こんにちは。 株式会社エブリーの開発本部データ&AIチーム(DAI)でデータエンジニアをしている吉田です。 今回は、先日参加したGoogle CloudのData Analytics Workshopについて紹介します。 はじめに エブリーでは、各サービスからのログをデータ基盤に集約し、これをデータ分析や機械学習のために活用しています。 データ基盤の構成は、Databricks、TreasureData、そしてRedashを組み合わせたものです。 具体的には、DatabricksでETL処理を行い、そのデータをTreasureDataに保存します。 そして、Redashを用いてデータの可視化を行っています。 現在のデータ基盤には、歴史的な経緯から生じたデータ処理フローの複雑さや、全体的なコスト最適化といった課題が存在しています。 このような状況でデータ基盤の構成を見直している中、Google Cloudの方からData Analytics Workshopの案内を頂き、参加させていただきました。 Data Analytics Workshopとは Data Analytics Workshopは、Google Cloudのスペシャリストに現状のデータ基盤/データ活用の課題をヒアリングしていただき、Google Cloudの関連サービスを用いたソリューション・アーキテクチャを提案していただくワークショップです。 ワークショップの流れ 今回のワークショップでは、Google CloudからData Analytics Specialistを中心に、Customer EngineerやSalesの方々も含む3名の方が担当してくださいました。 エブリーからは、CTOとDAIメンバー、トモニテのバックエンドエンジニアが参加しました。 ワークショップは全2日あり、以下のような流れで進められました。 Day 1 エブリーの現状のデータ基盤と課題の認識合わせ 主要プロダクトのご紹介 事前ヒアリングを元に、いくつかのGoogle Cloudのサービスを紹介していただきました。 Day2 アーキテクチャ案の検討 我々の課題を解決するためのアーキテクチャ案を提案いただき、それについてのディスカッションを行いました。 ハンズオン いくつかのGoogle Cloudのサービスを用いたハンズオンを行いました。 ワークショップでの学び 以下にワークショップで学びや気付きを記載します。 データ基盤の課題とアーキテクチャディスカッション Day1では、エブリーの現状のデータ基盤と課題の認識合わせを行いました。 現行のアーキテクチャの共有だけでなく、そのアーキテクチャがなぜそのような形になったのか、AI活用に向けた取り組みの進捗、BIツールやデータガバナンスに関する課題など、データに関連する問題点を幅広くヒアリングしていただけました。 エブリーのデータ基盤には、以下のような課題が存在しています。 DatabricksとTreasureDataの2つの基盤にそれぞれデータ処理フローが存在するため、フローが複雑化している データ活用を促進するためのデータカタログの整備とデータガバナンスの強化が必要である 機械学習をプロダクトに適用するためのMLOpsの整備が求められている トモニテのデータ基盤であるBigQueryのコストが増加傾向にある これらの課題を考慮した上で、Day2ではGoogle Cloudのサービスを活用したアーキテクチャ案を提案いただきました。 提案いただいたアーキテクチャ案では、基本的にBigQueryを中心とした構成となっています。 これにより、以下のようなメリットが得られると考えられます。 データ処理フローを単純化できる Google Cloudの他のサービスとの連携が容易になり、Google Cloudの各サービスを最大限活用できる MLOps基盤としてBigQueryと連携が容易なVertexAIを利用できる データカタログとしてBigQueryから自動的にメタデータを収集可能なDataplexを利用できる BigQueryの強力な計算資源を活用できる 提案されたプランでは、Plan3からPlan1に向けてGoogle Cloudのサービス利用率を高めていく想定をしています。 Plan3では現行のDWHであるTreasureDataをBigQueryに移行し、Plan2ではDatabricksをGoogle CloudのSpark基盤であるDataProcに移行します。 そして、Plan1ではすべての処理をBigQueryに集約します。 Google Cloud上にデータ基盤を構築すると、BigQueryの計算資源を活用しつつ現行アーキテクチャに対してコストを抑えることが可能となります。 また、BigQuery MLなどの機能を使用が可能となります。 さらに、Google Cloudの他のサービスとの連携が容易になり、フルマネージドのデータカタログやML基盤、BIツールなどを導入しやすくなります。 提案されたアーキテクチャ案を検討した結果、現行のアーキテクチャと同等の性能を維持しつつコストを抑えることが可能だと判断しました。 しかし、移行コストの大きさやアプリ基盤との連携など、解決すべき課題も多く存在します。 今回のワークショップでは時間の制約から、アーキテクチャ案の詳細なディスカッションを行えませんでした。 しかし、ワークショップ終了後もオフィスアワーという形で、Google Cloudのスペシャリストの方々とオンラインでディスカッションする時間をいただいています。 主要プロダクトのご紹介 主要プロダクトのご紹介では、事前ヒアリングの際に伝えたLLMとデータガバナンスを中心にGoogle Cloudのサービスをご紹介いただいたので一部を以下で紹介します。 VertexAI ( https://cloud.google.com/vertex-ai?hl=ja ) 訓練用データの準備、モデルのトレーニング、デプロイメント、予測の監視、モデルの改善まで、すべてのステップを実行できる機械学習プラットフォーム Generative AI Studio ( https://cloud.google.com/generative-ai-studio?hl=ja ) 生成AIモデルのファインチューニングやプロンプト設計などを行えるツール Dataplex ( https://cloud.google.com/dataplex?hl=ja ) 分散したデータに対して一元化された管理とデータガバナンスを提供するためのプラットフォーム VertexAIの利点として、モデルのトレーニングからデプロイまでの一貫した操作が可能であるという点です。 これにより、MLOpsの実行が効率化されます。 さらに、Generative AI Studioの使用により、自前でファインチューニングを行うコストを削減できると考えられます。 Dataplexは、データガバナンスの運用をサポートするために、複数のサービスに分散して存在するデータに対して、データの管理単位を作成し、管理単位での権限管理を行なえます。 さらに、フルマネージドであり、Google Cloudサービスとシームレスに連携できるデータカタログとして、データカタログの管理・運用コストを削減できると考えられます。 一方、エブリーではデータカタログとしてOpenMetadataをセルフホストで使用しています。 OpenMetadataは、GCP/GCP以外も含めた様々なデータソースからの横断的なメタデータ収集が容易にできる点が魅力的ではありますが、セルフホスティング由来の運用コストなどの課題もいくつか存在しています。 そのため、使いやすさや運用コストを含め、Dataplexも選択肢の一つとして検討していきたいと考えています。 Google Cloudサービスのハンズオン ハンズオンでは、2グループに別れて以下のサービスを用いたハンズオンを行いました。 - BigQuery ML ( https://cloud.google.com/bigquery/docs/bqml-introduction?hl=ja ) - BigQuery Interactive SQL Translator ( https://cloud.google.com/bigquery/docs/interactive-sql-translator?hl=ja ) BigQuery MLでは、BigQuery上にあるDELISH KITCHENのイベントログを対象に、モデルのトレーニングと予測を行いました。 BigQuery SQL変換は、他のSQL言語をGoogle SQLに変換が可能なサービスです。 エブリーでは、RedashからTreasureDataへのクエリにPresto SQLを使用しているため、BigQuery基盤への移行を考えると、Presto SQLからGoogle SQLへの変換が必要となります。 現在、Redash上には約17,000件のクエリが存在しており、これらをGoogle SQLに変換する移行コストは大きな課題となります。 この問題を解決するために、BigQuery SQL変換を紹介いただき、実際に変換を試みました。 手順としてWebブラウザ上で変換前の言語を選択した後、SQLを入力してボタンを押すだけです。 その結果、標準的な関数はエラーなく変換でき、移行コストの大幅な削減が期待できると感じました。 しかし、TreasureDataの独自関数については変換が行えないため、移行コストを完全にゼロにすることは難しいと感じました。 移行を行う際は独自関数の変換にのみ注力し、標準的な関数については自動変換を行うことで、コストを抑えつつ移行を進められると考えられます。 今後の取り組み 今回提案いただいたアーキテクチャ案を参考に、エブリーのデータ基盤の改善を進めていく予定です。 データ基盤の大規模な刷新は、エンジニアリングリソースの確保や既存のデータ処理フローの移行など、多くの課題を伴います。 そのため、小規模なPoCを実施するなどして、移行の見積もりや移行後のアーキテクチャの選定を行っていく予定です。 また、ML周りのサービスなど、部分的に導入可能なサービスが存在するため、それらのサービスを活用したPoCも実施していく予定です。 おわりに 今回のワークショップでは、Google Cloudのスペシャリストの方々にエブリーのデータ基盤の課題をヒアリングしていただき、その上でGoogle Cloudのサービスを活用したアーキテクチャ案を提案いただきました。 さらに、様々なサービスの紹介も行っていただき、これらを利用してどのようなデータ活用基盤を構築するかについて様々なアイデアが湧きました。 ワークショップの開催にあたり、多くのリソースを提供していただいたGoogle Cloudの皆様に心から感謝申し上げます。

はじめまして。株式会社エブリーの開発本部のデータ&AIチームでマネージャー兼データサイエンティストをしている伊藤です。 今回は、エブリーのデータ組織が普段どういった取り組みを行なっているかを、簡単にご紹介したいと思います。 エブリーについて 株式会社エブリーは、「DELISH KITCHEN」「トモニテ」「TIMELINE」という3つのメディアを運営しています。 各メディアはそれぞれ主力となるサービスがあり、それらを起点に多岐に渡る事業を展開しています。 どのメディアも戦略上「データ」が不可欠となっています。 サービスのグロースのためのKGI・KPIのモニタリングはもちろんですが、 広告事業でのクライアント様向けの媒体資料や、OMO事業におけるオフラインデータの活用など、 データを起点とした取り組みは数多く実施されています。 チームObjective データ&AIチームでは、「データ資産を最大限活用した事業運営の実現」をObjectiveに掲げています。 このObjectiveが達成された状態は、2つに分けられます。 データ資産が適切に使える状態になっている データ資産の活用が事業改善に貢献している 前者は、サービスの動きやサービス内外で発生したユーザーの行動が正しく収集され、利用したい人が誰でも利用できるようになっている状態で、 データ基盤やBIツールの提供・データガバナンスなどが関連します。 後者は、データによって適切な意思決定がなされたり、データを使って事業価値が創出されている状態で、 データ分析や効果検証・統計モデル・機械学習などが関連します。 これら2つの状態は、どちらか片方だけでは不十分で、両方が機能して初めて data-driven / data-informed な意思決定につながるため、 それらを両立させるのがデータ&AIチームとしてのミッションだと考えています。 開発体制 2023年9月時点で、データ&AIチームは「データエンジニア」1名、「データサイエンティスト」3名、「データストラテジスト」1名が在籍しています。 それぞれの定義や担当領域は諸説ありますが、エブリーでは主に以下のようになっています。 データエンジニア: データ収集・分析基盤の構築と改善、データガバナンスの強化 データサイエンティスト: グロース施策の分析・効果検証、ロジック改善 データストラテジスト: マーケティングソリューションにおける営業支援 これらは大きな括りとしては分割されていますが、他の領域にまたがった取り組みを行う場面も多くあります。 例えば、データサイエンティスト・データストラテジストが、モニタリングや分析のために新しいデータが必要になったら、 基本的にはデータ取得処理の実装まで含めて担当します。 分業体制にできるほどの人数がいないという側面もありますが、 スキルの属人性を緩和しつつ、 大元のデータを活用できる状態に加工する経験を通してデータに対する解像度を上げられる、といったメリットもあると考えています。 技術スタックは、主要なものを挙げるとおおよそ以下のようになっています。 インフラ系: AWS、GCP、terraform データ基盤系: Databricks、TreasureData、Fivetran データ分析系: Redash、streamlit プログラミング言語: Python、Scala、SQL (SparkSQL、Prestoなど) ML系: MLflow、FastAPI (ML API) AIツール系: Github Copilot、OpenAI API 主な業務内容 ここでは、データ&AIチームが日頃取り組んでいる業務のうち、直近のものをいくつかをピックアップして紹介します。 データカタログ構築 現在データ基盤は様々な利用者に使っていただいていますが、 「欲しいデータがどこにあるか分かりづらい」「テーブルのカラムの定義が分からない」といった課題がたびたび挙げられていました。 そこで、データエンジニア中心にデータカタログの構築を進めました。 いくつかの実現方法に関してPoCを行い、結果的にいくつかのツールを跨いでメタデータを収集できるOpenMetadataを採用しました。 インフラはAWS上に構築しており、現在はデータカタログの普及に向けた取り組みを実施しています。 効果検証 主にデータサイエンティストが、PdMやエンジニアと連携し、日々の施策の効果検証を担当しています。 効果検証はA/Bテストを選択することが多く、実験設計の部分から最後の意思決定の部分まで、データサイエンティストが並走するケースが多々あります。 直近では、細かいクリエイティブの改善に割く工数を削減するため、バンディットアルゴリズムの導入も進めています。 PR強化プロジェクト これまで、マーケティングソリューションの課題の1つに、トレンド予測などのプレスリリースの少なさがありました。 プレスリリースは公開までに少なくない労力が必要ですが、営業メンバーの方が直近のトレンドを正しく把握するのに有効な側面に加え、 メディアとしてデータ資産を日頃利用いただいているユーザー様に還元できるという社会貢献としての側面もあります。 このプロジェクトはデータストラテジストと広報・管理栄養士が連携して進めており、 データストラテジストが探索的な分析ができるダッシュボードを作成 広報・管理栄養士を交えて議論しつつ、トレンドの探索どダッシュボードの調整を進める 発信の方向性が決まるとデータの整形と発信内容の調整を実施 といった流れで、データストラテジストを起点に各自の持つドメイン知識をうまく集約させたプロジェクトになっています。 直近はチョコミントに関するプレスリリースが発信され、いくつかのメディアでも取り上げていただいております。 データ組織としての直近の取り組み また、データ組織として、直近は以下のような取り組みを行っています。 勉強会の実施 データ分析や機械学習などのスキルを身につける上では、実践的な経験に加えて、数学などの基礎知識の継続的な学習も重要になります。 そこでデータ&AIチームでは、数式に向き合う時間を作ろうという名目で、有志のメンバーで輪読会を開催しています。 過去何度か社内で勉強会を開催したり参加したりしてきましたが、予習と発表資料の準備はそこそこの負担になっていたため、 この輪読会は担当者がその場でホワイトボードに書きながら読み進める、という形式をとっています （そのため、内容が難しい場合には参加者全員が頭を抱えてほとんど進まないまま終わる回もあります）。 現在は「統計的機械学習の数理100問 with Python」という書籍を扱っています。 週に1時間のペースで、2023年9月時点で開始から1年半以上（最近ようやく最終章に入りました）続いており、今では比較的古参の取り組みになっています。 社内ChatApp作成 最近ChatGPTのような生成AIを組み込んだサービスやツールが日々増加している中で、それらを日常的に触れて肌感を掴み、 より良い活用の仕方を考え業務改善に活かしていくスキルが求められつつあります。 そのような動きを社内で高めていくため、データ&AIチームとして社内ChatAppを作成・提供する取り組みを行いました。 リリース時のSlackメッセージ ChatAppはOpenAI APIをベースに動いており、入力した情報が学習に使われないよう設定できるため、ChatGPTよりも業務利用の敷居が下がっています。 また、GPT-4も社員は誰でも無料で使用できるようになっています。 ChatAppの作成は、チームで作ってみようという話題が出た翌週に、1日時間をとってデータエンジニア・データサイエンティストの2名で一気に作り上げた、 という点は地味なアピールポイントになっています。 また、作成においては以下の記事を参考にさせていただきました。 このような、メンバーの経験値になり、かつ業務にも役立つような取り組みを熱量を持って遂行するような動きは、今後もチームとして増やしていきたいと考えています。 今後の取り組み 最後に、データ組織としての今後に向けた取り組みを紹介します。 データ基盤の継続的な改善 現在のデータ基盤は幅広い事業部にデータを提供し利用いただいている状態ですが、 コストをはじめ、品質や提供速度など、より改善できる部分は多々存在しています。 また、利用者が使いやすいBIツールの設計や、見られなくなってしまうダッシュボードの管理方法なども、取り組むべき課題として挙がっています。 直近ではOpenMetadataを使ったデータカタログを作成しましたが、それをいかに社内普及させていくかもホットな課題です。 これらは一気に解決できるものではないですが、 チームとしては継続的に選択肢を検討し続ける状態を作り、少しでも良い状態を目指したいと考えています。 データによる技術更新の推進 現状DELISH KITCHENを初め、サービス内部には様々なロジック（検索やレコメンドなど）が埋め込まれています。 それらのほとんどは、サービス初期の頃に作成されたルールベースのアルゴリズムや、精度が継続的に評価されていないモデルになっており、 改善の余地が多く残されている状態です。 ユーザー様の利用体験を少しでも向上させるために、現在はサービスとロジックが適切に分離された状態を導入する取り組みを始めています。 サービスとロジックの分離がなされることで、データサイエンティストがロジックの改善に集中できる環境になりつつ、 必要であればロジックを前提としたUXの設計にも取り組めるようになると考えています。 今は少しずつ導入事例を増やしていく段階ですが、将来的にはインフラも整備しつつよりスケールする基盤を構築していけるよう取り組んでいきたいです。 おわりに データ&AIチームの直近・将来に向けた取り組みを、簡単にご紹介しました。 エブリーのデータ組織に興味を持っていただいた方の解像度が少しでも上がるような内容になっていると幸いです。 より詳しい話を聞きたい方は、カジュアル面談をお申し込みいただけると嬉しいです！ corp.every.tv

こんにちは。トモニテでiOSアプリを開発している國吉です。　 トモニテではサテライトを含め、複数のアプリをリリースしています。それぞれアプリのリリースが終えてからグロースするために改善/運用を行っていますが、N1インタビュー等でユーザーの声を聞いてみると「そんな機能があったんですね！知らなかったです」という意見がちらほら見受けられます。我々機能を提供している側としては、できるだけ機能認知してもらえるようにデザインを工夫して提供していても一定数は機能にたどり着く前に離脱してしまう可能性があります。　 そこで今回はiOS17で追加されたTipKitを用いて、機能誘導できないか検証がてら触れていきたいと思います！　 TipKitとは まずTipKitの概要をお話しします。 TipKitはアプリ上でヒントを表示しユーザーに機能/操作方法を知ってもらうための手段として提供されています。　 これにより、アップデートで追加した機能を知ってもらったり、オンボーディングでアプリのコアとなる機能を知ってもらうことができます。 ただし、ユーザーアクションを促す上で、”ヒントをどのタイミングで表示するか””どのようなメッセージでアプローチするか”を考えるのが難しく、設計がすごく大事になると思います。　 実装　 早速実装に取り掛かります。今回はUIKitで表示するとこまでを紹介しますが、SwiftUIでも実装はすごく簡単です。　 まずはAppDelegateでTipKitを使う設定だけしておきます。　 import TipKit func application(_ application: UIApplication, didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]?) -> Bool { Task { try? await Tips.configure() } /* ..... */ } 次にヒントを表示したいViewControllerで処理を記述していきます。 下記ではヒントで表示するTipの中身を定義しています。 import TipKit struct StartButtonFeatureTip: Tip { var title: Text { Text("陣痛が始まったと思ったらタップ!!") } var message: Text? { Text("陣痛がおさまってきたら「おさまったかも」ボタンをタップして計測を終了しましょう") } var image: Image? { Image(systemName: "hand.tap.fill") } } 動作検証では画面表示タイミングでヒントを表示したかったので、viewDidAppearで表示登録をしています。 画面から離れる際に、インスタンスを解放できるようにnilを代入しています。 // クラスプロパティ private var startButtonFeatureTip = StartButtonFeatureTip() private var tipObservationTask: Task<Void, Never>? private weak var tipPopoverController: TipUIPopoverViewController? override func viewDidAppear(_ animated: Bool) { super.viewDidAppear(animated) /* ... */ tipObservationTask = tipObservationTask ?? Task { @MainActor in for await shouldDisplay in startButtonFeatureTip.shouldDisplayUpdates { if shouldDisplay { let popoverController = TipUIPopoverViewController(startButtonFeatureTip, sourceItem: contractStartButton) present(popoverController, animated: animated) tipPopoverController = popoverController } else { if presentedViewController is TipUIPopoverViewController { dismiss(animated: animated) tipPopoverController = nil } } } } } override func viewWillDisappear(_ animated: Bool) { super.viewWillDisappear(animated) tipObservationTask?.cancel() tipObservationTask = nil } ここまでの記述でシミュレーターを起動するとヒントが表示されるようになります。 すごく簡単ですね。次はテキストなどカスタマイズできるとこは調整しアプリに馴染むようにしていきたいと思います！ テキストカラーやフォントなどはTipの中身を定義しているとこで記述し、アイコンの色についてはTipUIPopoverViewControllerの中にあるViewのtintColorを変更することで指定できます。 struct StartButtonFeatureTip: Tip { var title: Text { Text("陣痛が始まったと思ったらタップ!!") .foregroundStyle(Color(uiColor: .defaultTint)) } var message: Text? { Text("陣痛がおさまってきたら「おさまったかも」ボタンをタップして計測を終了しましょう") .foregroundStyle(Color(uiColor: .defaultTint)) } var image: Image? { Image(systemName: "hand.tap.fill") } } override func viewDidAppear(_ animated: Bool) { super.viewDidAppear(animated) /* ... */ tipObservationTask = tipObservationTask ?? Task { @MainActor in for await shouldDisplay in startButtonFeatureTip.shouldDisplayUpdates { if shouldDisplay { let popoverController = TipUIPopoverViewController(startButtonFeatureTip, sourceItem: contractStartButton) popoverController.view.tintColor = .defaultTint present(popoverController, animated: animated) tipPopoverController = popoverController } else { if presentedViewController is TipUIPopoverViewController { dismiss(animated: animated) tipPopoverController = nil } } } } } ヒントのbackgroundColorを指定することもできるのですが、閉じるアイコンの色の指定は現状不明なので、注意が必要そうでした(iOS17が正式リリースされたらUIKitからでも閉じるアイコンの色も指定できるようになることを願います。。) ヒントの中にアクションリンクを付与することも可能です。 Tipの中身の定義にActionを追加します。TipUIPopoverViewControllerのイニシャライザにactionHandlerがあるので、ハンドラー内でAction処理を記述していきます。 struct StartButtonFeatureTip: Tip { var title: Text { Text("陣痛が始まったと思ったらタップ!!") .foregroundStyle(Color(uiColor: .defaultTint)) } var message: Text? { Text("陣痛がおさまってきたら「おさまったかも」ボタンをタップして計測を終了しましょう") .foregroundStyle(Color(uiColor: .defaultTint)) } var image: Image? { Image(systemName: "hand.tap.fill") } var actions: [Action] { [Action(id: "start_button", title: "詳細はこちら")] } } override func viewDidAppear(_ animated: Bool) { super.viewDidAppear(animated) Tracker.track(event: .counterScreen) AdjustTracker.track(event: .counterScreen) let statusBarHeight = self.view.window?.windowScene?.statusBarManager?.statusBarFrame.height ?? 0 headerViewHeightConstraint?.constant = 44 + statusBarHeight tipObservationTask = tipObservationTask ?? Task { @MainActor in for await shouldDisplay in startButtonFeatureTip.shouldDisplayUpdates { if shouldDisplay { let popoverController = TipUIPopoverViewController(startButtonFeatureTip, sourceItem: contractStartButton, actionHandler: { action in guard action.id == "start_button" else { return } /* 「詳細はこちら」をタップ後の動作 */ }) popoverController.view.tintColor = .defaultTint present(popoverController, animated: animated) tipPopoverController = popoverController } else { if presentedViewController is TipUIPopoverViewController { dismiss(animated: animated) tipPopoverController = nil } } } } } ルールをつける ヒントを表示したい時に「ユーザーがXXXXをしたら」「ユーザーがログインしたら」等々条件を満たした時に表示したい場合があると思います。そこで使用するのがルールです。 ルールは2種類あります。 パラメータベース 感覚的には”ログインしているか”等Boolで管理できるものだと思います。 イベントベース 「XXXをしたら」等のイベントトリガーを指定できます。 今回はお試しでイベントベースのルールを使用し、「きたかも」Buttonを2回タップしたら「おさまったかも」Buttonにヒントを表示する処理を書いていきます。 まずは、Tipの中身の定義にEventとRuleと記述します。 viewDidAppear内は特に変わりありません。 「きたかも」Buttonをタップされたタイミングで、startButtonTappedCountをインクリメントする必要があります。 struct StopButtonFeatureTip: Tip { static let startButtonTappedCount = Event(id: "start_button_tapped_count") var title: Text { Text("陣痛がおさまったらタップ!!") .foregroundStyle(Color(uiColor: .defaultTint)) } var message: Text? { nil } var image: Image? { Image(systemName: "hand.tap.fill") } var rules: [Rule] { #Rule(Self.startButtonTappedCount) { $0.donations.count >= 2 } } } private lazy var contractStartButton: ContractStartButton = { let button = ContractStartButton() button.configure(tapped: { [weak self] in guard let self = self else { return } Task { try? await StopButtonFeatureTip.startButtonTappedCount.donate() } /* ... */ }) return button }() その他 他にも1日1個のヒントしか表示しない。同じヒントが出続けないように出現回数を制限する。等のオプションもあります。ぜひ調べてみてください。 また、見た目の確認したいなど常にヒントを出したい時もあると思いますが、その時はこのように記述することで全てのヒントを表示することができます。 Tips.showAllTipsForTesting() 最後に 今回はiOS17で追加されたTipKitを触ってみました。感想としてはオンボーディングに組み込むことで初日の機能利用を促すことができ、細かいとこまで機能認知に繋がりそうだと感じました。 また大きめな機能を追加しアップデートを実施した際にも同様に価値を感じそうです。 ただ、ベースのレイアウトはOSが提供したものに則る必要があるため、すごくリッチな見た目で表示したい要望がある場合には使えなさそうです。 トモニテではサテライトアプリで検証し、ユーザーの反応が良ければ随時、他のアプリには展開していこうかなと考えています。 参考 https://developer.apple.com/videos/play/wwdc2023/10229/ https://developer.apple.com/documentation/tipkit/highlightingappfeatureswithtipkit

背景 DELISH KITCHEN 開発部で小売向き合いの開発に携わっている大村 ( @kosukeohmura ) といいます。 エブリーでは リテールメディアの構築・提供を通して小売様を支援していく 構想を掲げており、 retail HUB という枠組みでいくつかの SaaS プロダクトを開発・提供しています。開発のフェーズとしてはまだまだ未成熟な部分も多いのですが、今回はその中でもマルチテナントな SaaS に想定される要求に着目して、それを満たすために考えてきたことをお話しします。 マルチテナントなシステムとは エブリーでは各小売（主にスーパーマーケット）様がそれぞれテナントとなりシステムを共用する、いわゆるマルチテナントなプロダクトを作っています。マルチテナントなシステムは、テナントという概念自体が存在しないシステムや、テナントごとに独自のシステムが存在する場合に比べてどのような時に向いているものなのでしょうか。それぞれの場合について、私なりの理解を書いてみます。 テナントという概念が無いシステム ここで挙げるなかで最もシンプルなケースとして、テナントという概念がなく、各使用者が独立しているシステムがあります。弊社が運営するレシピ動画メディア DELISH KITCHEN もこのモデルです。 （当たり前な話ですが）組織で使用されないようなシステムでは、テナントを使ってリソースを束ねたい動機も生まれません。 下記のような要求が生まれうるシステムでは、テナントという単位で各種リソースを束ねることを検討する必要が出てきます。 自組織のメンバーを確認したい 自組織に属するリソースの変更を行いたい 特定の組織に属するユーザー群の、プロダクトの使用状況を確認したい 特定のテナント向けのシステム 次にやや極端な例として、テナントそれぞれに要求を細かく聴取し、その都合にあわせてそれぞれ制作・構築・提供されるシステムを考えてみます。コストを考えない場合には最もテナントの要求を満たしうる手法であり、テナントごとにシステムに対する要求が異なる場合、最も柔軟に対応できる手法です。 一方で、同じような課題を多数のテナントが抱える中でこの手法を取った場合には、システムごとに作り替えやリリース作業、仕様策定などのコストがかかり、そのコストは必要以上に多くなります。複数のシステムに同じ変更を適用し続けることも、テナントが増えるに連れて難しくなります。 マルチテナントなシステム マルチテナントなシステムでは、ソースコードやその他サーバー等のリソースをテナント間で共用します。テナントの増加に対して開発や運用に掛かるコストが（直接は）比例しないので、スケールしやすいシステムとなります。何らかの組織を表すようなデータ構造が必要で、同じような課題を持ったテナントが多く存在する場合には有力な選択肢となります。私達のチームでも、多くの小売様の抱える課題を共通のプロダクトで解決していきたいと考え、この手法をとっています。 留意しておくべきこととして、テナントごとの課題が大きく異なる場合や、各テナントからの要求を安直に受け取り機能拡張を続けたような場合には、特定のテナント向けの特別な実装が乱立したり、システムの必要以上な多機能化が起こり得ます。そうなるとプロダクトは複雑性を増していき、開発速度の低下やバグの頻出を招くでしょう。 テナントごとの要求は多少なりとも異なるものであり、それらの要求を時には切り捨てつつ、どうテナント共通の課題を解決できるプロダクトに落とし込んでいくか、という難しさに向き合うことが必要となります。マルチテナントなシステムは多くの場合 to B であり、お客様との関係が to C と比べて近く、システム使用者の生の声が間近で聞けることもあるかと思います。その中で、未来を見据えてプロダクトをどういうものにしていくかを考え、意思決定を行い続けることが大切だと思います。 マルチテナントなプロダクトにおける要求 複数のテナントがリソースを共用する都合上、テナントごとのデータの分離によるプライバシーの確保が要求の筆頭として挙げられます。異なるテナントのデータがプロダクト上で見えてしまうと、プロダクトの信頼は失われ事業自体の存続が危うくなってしまいます。 他方で、プロダクトを運営・改善していく上ではテナントを横断したデータを見て分析を行い・次の施策へ繋げていきたいというニーズもあり、また運営側のメンバーが各テナントの代わりにプロダクトのデータを閲覧・操作するケースも考えられます。 マルチテナントなプロダクト開発で考えること データの分離 RDB プロダクトやその管理画面に表示されるほとんどのデータが入っているデータベースです。金銭的なコストと DB への負荷とを考え、データベースのインスタンスは共通とし、テナントごとに論理データベースを分離する形にしています。加えて、テナント共通のレコードについては共用のスキーマを作成し、そこに保存しています。RDB ユーザーをテナントごとに作成し、それぞれ対応するテナントのデータ以外にアクセスできないようにしています。 画像などのファイル 各種ファイルを保存するストレージサービス (Amazon S3 を使用しています) についても、RDB と同様にテナントごとのデータの分離が必要であり、テナントごとにバケットを分けてファイルを保管しています。こちらもテナント共通のファイルについては共用のバケットを使用しています。 各種イベントログ、アクセスログ 各種分析に使うクライアントアプリ上でのイベントログやサーバー・ロードバランサへのアクセスログについては、センシティブな情報は入らないこととテナント横断で統計的な見たいケースが多いと考え、テナントごとに分けずに保存しています。テナントの識別子をログに含めることで、テナントごとのログを抽出することができます。 API サーバー・ロードバランサー それぞれテナント共通のものを使用していますが、API リクエストの内容からテナントを識別し、他テナント用の RDB やストレージへの接続が起き得ないようにしています。 開発用のテナント 細かい話ですが、開発時や社内でのデモに使うテナントどうするの？という話があります。弊社ではローカル環境や開発用の環境には社内共通の架空のテナントの環境を用意し、開発や社内用デモアプリでの動作確認にそれを使用しています。 運営メンバーのユースケースの考慮 運営側のメンバーが各テナントの代わりにプロダクトのデータを閲覧・操作しようとした場合に、各テナントごとのユーザーアカウントをいくつも持つ形だと、ログイン・ログアウトを繰り返したり、複数のサイトを渡り歩くなど面倒なことが想定できます。このことを防ぐため、アカウントに複数のテナントが紐づくような形とし、閲覧・操作対象のテナントを選択できるような形としています。 サービスやサーバーの Endpoint の URL をテナントごとに分けるか 世の中の SaaS プロダクトを使っているとテナントごとにサブドメインを付与して {tenant}.example.com のような形とするケースがあります。基本的にはテナントごとに付与したほうがリソースの競合の可能性がなくなると考えてそうしていますが、テナントを切り替えるようなユースケースがある場合にはサブドメインを変えにくいです。 おわりに マルチテナントなシステムの開発を始めている中で考えてきたことを挙げてみました（現在はこうしている、というもので、今後変えるところも出てくると思います）。マルチテナントではないシステムに比べて、基本的なところでも想像以上に考えることが多く、またこの辺の設計がセキュリティや使い勝手の向上に大きく効いてくると感じています。開発が進んできたら、実践的な話にも踏み込んだ話をしたいです。

概要 TIMELINE開発部の内原です。 株式会社エブリーでは、バックエンド系ソフトウェアをGo言語で記述することが多いです。また、作成したプログラムについては、go testコマンドを用いてテストを記述するようにしています。 今回は、go test時に発生した一見分かりづらいエラーをどのように調査、対策したかについて共有します。 環境 Go言語 Test Frameworkとして Convey DBはMySQL エラー発生時の状況 ある時からローカル環境にてテストを実行したところ、以下のようなエラーが発生するようになりました。 $ go test ./repository/*.go ... Line 30: - Error 1062: Duplicate entry '1' for key 'PRIMARY' ... 一見して、テスト中にレコードを登録しようとした際に、なんらかの理由でPrimary Keyの重複が発生したということが分かります。 ただ、この時は develop ブランチの先頭でテストを実行しており、同じコミットがCI環境では正常にテストが成功していたので不思議に思いました。 テストコードを見てみると以下のような実装になっていました。 import ( . "github.com/smartystreets/goconvey/convey" ) func setup() { err := insertRecord( 1 ) // ID:1でレコードを登録 if err != nil { panic (err) } } func teardown() { err := cleanupTable() // テーブルのレコードを全削除 if err != nil { panic (err) } } func Test_Find(t *testing.T) { Convey( "Find" , t, func () { setup() repo := NewRepository() Convey( "正常系" , func () { record, err := repo.Find( 1 ) // ID:1でレコードを検索 So(err, ShouldBeNil) // エラーは発生しないことを検証 So(record.ID, ShouldEqual, 1 ) // ID:1のレコードが取得できることを検証 }) Convey( "異常系" , func () { _, err := repo.Find( 0 ) // ID:0でレコードを検索 So(err, ShouldEqual, ErrNotFound) // NotFoundエラーが発生することを検証 }) Reset( func () { teardown() }) }) } conveyの使い方について簡単に説明します。 Convey() 関数 テストのコンテキストを表現する関数 第一引数にはコンテキストの説明を、第二引数にはテスト対象の関数を渡す コンテキストはネストすることができる コンテキスト内部のテストコードでpanicが発生した場合、コンテキスト単位でテストは失敗したものとみなし、下位のコンテキストは実行されなくなる So() 関数 assertionを行う関数 ShouldBeNil , ShouldEqual といったマッチャーを用いて記述することができる Reset() 関数 コンテキスト単位でのテストの後処理を表現する関数 ネストしたコンテキストの場合、上位層も含めて実行される 調査 実際に、テスト実行前の状態でテスト用DBに接続してテーブルの中身を確認してみると、たしかにPrimary Keyが1のレコードが存在していました。 これでは当然 setup() で重複エラーが発生します。 しかし、 Reset() で teardown() を呼び出すように実装しているので、テスト終了時にはテーブルの中身は空になっているはずでした。 その後記憶を頼りに原因を調べてみたところ、テスト終了時にもレコードが残ったままになっていた理由は単純なものでした。 develop ブランチの先頭でテストを実行する以前に、ローカル環境にて上記のテストコードと同じテーブルを操作する別のテストコードを実装していました。その際、誤って teardown() の呼び出しをしない状態でテストを実行しました。 func Test_Other(t *testing.T) { Convey( "Other" , t, func () { setup() repo := NewRepository() _, err := repo.DoSomething() So(err, ShouldBeNil) // エラーは発生しないことを検証 }) } このテストを実行したことでテスト終了時にレコードが残ったままになりました。 その後developブランチに移動した際もDBはそのままの状態であったため、 setup() にて重複エラーが発生するようになっていたのでした。 データが残ったままでテスト実行 setup() が失敗 Reset() が登録されない teardown() が呼び出されない データが残ったままでテスト実行 setup() が失敗 ... というループに陥っていたということです。 対応案 要するに、1回でもレコードが残ったままになっているとその後テストデータの登録で必ず失敗し、またその状態から自力で復帰できないというテストコードになっていました。 このテストコードにおける問題点としては以下が挙げられます。 setup() が失敗することがある setup() と teardown() が1対1で対応するとは限らないため、テスト終了時にテストデータが残ったままになることがある これらを解決する案としては以下が考えられます。 テーブルのレコードを削除する処理を setup() を実行する前に移動する setup() が失敗しないようにするアプローチです。あらかじめテーブルを初期化しておきその後に登録という実装になるため、この場合 Reset() 自体不要になります。 登録の先に削除するか後に削除するかはどちらもあり得る実装だと思うのですが、すでに上記のようなコードが大量に存在したため、すべて修正するのは避けたいと考えました。 Reset() の呼び出しを setup() を実行する前に移動する setup() と teardown() が必ず1対1で実行されるようにするアプローチです。 setup() 内でpanicしようとも、すでに Reset() で登録されていればテスト終了時に teardown() が実行されることになります。 func Test_Find(t *testing.T) { Convey( "Find" , t, func () { Reset( func () { teardown() }) setup() repo := NewRepository() ... }) } ただ、convey のドキュメントを読むと Reset() は Convey() の末尾で実行する例が記載されており、convey側の想定としては現状の実装のほうがマッチしているように見受けられます。 また前述の理由と同様に、修正箇所が多くなることは避けたいと考えました。 そもそも setup() 内でpanicしないようにする setup() が失敗しないようにするアプローチです。 setup() でデータ登録が失敗した場合でも、 Reset() まで処理が継続するような実装にします。 例えば setup() を以下のように修正します。 func setup(t *testing.T) { err := insertRecord( 1 ) // ID:1でレコードを登録 if err != nil { t.Error(err) } } ... func Test_Find(t *testing.T) { Convey( "Find" , t, func () { setup(t) ... Reset( func () { teardown() }) }) } これなら、レコードが残っていて setup() でエラーが発生した場合でもテストは継続するので teardown() も実行されることになり、以降のテストでは正常に setup() が成功するようになります。 ただ、テストデータ登録処理のエラー判定は通常のテストとは区別しておきたいと考えました。この実装だとテストに失敗したのか、それともテストの前提処理で失敗したのかが伝わりづらくなるのではと感じました。 また、こちらも同様に修正箇所が多くなることが難点でした。 テスト実行時に1回だけテーブルを初期化する setup() が失敗しないようにするアプローチです。少なくとも、テスト実行前にテーブルが初期化されていればテストコードが間違っていない限りエラーが発生することはなくなるという発想です。 懸念としては、テストに対し無関係のテーブルも初期化されるため実行パフォーマンスの悪化が考えられます。 ただ、Goのtestはパッケージ単位で実行されるため、その単位で初期化するだけならパフォーマンスへの影響はそこまで大きくはならないと考えました。 DBに直接依存したrepository系パッケージのみを対象とすればよく、全体からみるとその割合は高くないためです。 もちろんrepository系パッケージに依存しているパッケージ自体は別に存在しており、それらは間接的にDBに依存していると言えるのですが、これらパッケージの大部分はrepositoryをmockとして扱っており、直接DBに依存しているわけではなかったのでテーブルの初期化処理は不要でした。 そこで、テスト実行時に1回だけテーブルを初期化するため、repository系パッケージにおいて以下のようなコードを実装しました。 import ( "github.com/khaiql/dbcleaner" "github.com/khaiql/dbcleaner/engine" ) func TestMain(m *testing.M) { CleanupAllTables() os.Exit(m.Run()) } func CleanupAllTables() { tables := allTables() dbCleaner := dbcleaner.New() dbCleaner.Clean(tables...) } func allTables() [] string { tables := make ([] string , 0 ) row, err := db.Query( "SHOW TABLES" ) if err != nil { panic (err) } for row.Next() { var table string if err := row.Scan(&table); err != nil { panic (err) } if table == "migrations" { // DB migration用テーブルは除外 continue } tables = append (tables, table) } return tables } テーブルの初期化には dbcleaner を使用しました。 テーブル数にもよりますが、100個程度のテーブルを初期化するのに要した時間は1秒程度でした。 前述の通り、影響を受けるのはDBに依存したパッケージのみであるため、許容範囲としました。 まとめ 今回はGo言語のテストコードにおいてテストデータ登録に失敗するようなケースでの対応について対応した結果をまとめました。 参考になりましたら幸いです。

はじめに こんにちは。DELISH KITCHEN開発部の村上です。 エブリーが運営しているサービスのDELISH KITCHENやトモニテではプレゼントキャンペーンが定期的に行われており、ユーザーさんは開催中の複数のキャンペーンから気になるものを選んでいくつかの設問に答えることで応募することができるようになっています。 今回はそのプレゼントキャンペーンのETL基盤をStep Functionsを利用してサーバーレスで構築した話を紹介させていただきます。 Step Functions導入の背景 当時の技術選定で意識したことは次のようなことでした。 運用面と費用面で低コストで実現できる データエンジニア以外でも開発・運用できる 将来的なデータの増加や実行頻度の変更に対応してスケールできる 特にこの基盤においては初めは少人数で運用コストをいかに下げてPoCしていけるかが重要だったので運用コストは重要な判断基準になっていました。その中でAWSではワークフローエンジンの選択肢としてGlue WorkflowやMWAAもありましたが、AWSサービスとの連携も豊富でjobの実行基盤が縛られず、当時はデータ量や処理負荷からしてjobとしてlambdaを採用することでコストも最小限にできるStep Functionsを選びました。また、Step FunctionsはGlue jobとも接続可能なので、データ量の増加により処理負荷が高くなってくれば、差し替えも検討でき、柔軟性が高いことも決め手となりました。 ステートマシンの構成 Step Functionsのワークフローはステートマシンと呼ばれています。ここからはエブリーで使っているステートマシンの構成とStep Functionsの機能を使ってどういうふうにETLを実現しているかを説明させていただきます。 全体 全体としては現状は大きく分けて、データ変換とカタログ更新の二つに分けれており、ステートマシンの実行はEventBridgeからスケジュールして定期的に行っています。オンタイムでの別データ基盤への転送をする場合はこのステートマシンを拡張することによって依存関係を制御することができます。次にそれぞれの処理の詳細を説明します。 データ変換 プレゼントキャンペーンの要件として、それぞれのキャンペーンは独自のデータを持っていて、そのデータ変換の要件もキャンペーンやその実施期間によって異なります。また、開催されるキャンペーン数も次第に多くなっていくことが想定されていたのでStep Functionsで提供されているMapステートを用いた動的並列化をしてそれぞれの変換処理からS3の格納までを行なっており、ある程度データ量が多くなってきた時にでもlambdaの実行時間の制限を回避できるようにしています。Mapステートに対してあらかじめ登録してあるキャンペーン内容を以下のような構造で渡して並列実行を行なっており、自身で指定することで特定のキャンペーンの再実行も可能です。 { " campaigns ": [ { " platform ": " service1 ", " campaign ": " campaign1 " } , { " platform ": " service2 ", " campaign ": " campaign2 " } ] } カタログ更新 前のフローで求められた要件でのデータ変換までは満たせていますが、このままだと他の基盤へのデータ転送や分析が困難なため、Athenaで抽出できるようにしています。ただ、先ほど説明させていただいた通り、キャンペーンはそれぞれ独自のスキーマを持っており、自前でやろうとすると毎回自分でデータカタログのスキーマ定義をしないといけません。そこでその運用コストを省くためにGlue Crawlerで変換したS3のデータを読み込ませて自動でカタログが作られるようにしています。Step Functionsには非同期な処理をWaitステートとChoiceステートを活用して待てるようになっており、実行結果が返ってきたらChoiceステートを使ってステートマシンを終了できるようになっています。 活用する上でのTips このようなステートマシンを構築していく中でStep Functionsを活用する上でのTipsがいくつかあったので紹介させていただきます。 エラー通知 Step Functionsはステートマシン自体がエラーになった時を発火タイミングとしてEventBridgeと連携することができるようになっているのでそれを組み合わせることで簡単に通知自体はできてしまいますが、EventBridgeが受け取れる情報には制約があり、ステートマシンの何がどんな理由で失敗したのかがコンソールに行くまでわかりません。また後述しますが、一部処理が失敗したときにステートマシン自体を失敗とできないケースもあるのでEventBridgeだけでは満たせないこともあり、EventBridgeに加えて他の通知手段を用意しないといけない状況でした。 そこで実行エラーをハンドリングするCatchフィールドを使って、エラー情報を取得し、エラー通知を送るlambdaを独自で用意しています。後続のタスクに以下の情報をlambdaであればeventとして受け取れるのでそれを通知したい内容によって加工することで素早くエラー内容を把握できる体制を作ることができます。 { " FunctionName ": " step functionsのarn ", " Payload ": { " Execution ": { " Id ": " 実行ID ", " Input ": { // それぞれの環境でのjobの発火内容の詳細が入る } , " StartTime ": " 実行開始時間 ", " Name ": " 実行名 ", " RoleArn ": " ロールのarn " } , " param ": { " Error ": " Error ", " Cause ": " エラー内容 " } } } 並列実行時のジョブキャンセル回避 先ほどのデータ変換のフェーズでMapステートによる動的並列処理を行なっていると説明しましたが、実はMapステートを使っただけだと並列する処理の一部が失敗した時に後続の処理は全て停止してしまいます。これは求められる要件にもよると思いますが、ある一部の処理が失敗してもそのエラーを通知しつつ、それ以外の処理は続けて欲しいケースはあると思います。 そういった場合に並列処理の中にエラー時の例外処理を追加し、エラー通知を行った上で正常終了させることによって実現可能です。これにより他の処理は後続のタスクに移行させ、影響を最小限にとどめることができます。 ペイロードサイズの制限回避 Step Functionsでは各処理で実行した結果を後続のタスクに渡すためにデータの受け渡しを行うシーンが多いかと思います。ただ、ペイロードサイズには制限があり、遷移時に渡せるデータは256KBまでです。例えばあるMapステートでの並列処理の返り値がサイズを超える場合、以下のようなエラーが出て処理は中断されてしまいます。 The state/task 'Map' returned a result with a size exceeding the maximum number of bytes service limit. これを防ぐためにステートマシンを作る上で意識したい2つのポイントがあります。 大きいペイロードはS3や外部ストレージを使う あらかじめ大きくなると予想されるデータは後続のタスクに渡す前にデータをS3やDBに保存して、その格納先の情報を後続に渡すことにより、データサイズを小さくすることができます。 また、同じ問題は並列処理を実行するMapステートに渡すJSON配列で起きる可能性もあります。現在ではStep FunctionsにDistributed MapステートがMapステートとは別で提供されており、S3内の大規模データをもとに並列処理が実行できるようになっているので、並列数や並列時に渡したいデータ量が増える場合には利用を検討すると良いと思います。 出力をフィルタリングして必要なデータに絞って渡す lambdaなどで挙動を制御できる場合にはその処理の中で出力を最小限にすると思いますが、AWSのサービスとノーコードで連携する場合にその処理が出力するデータ自体は制御することができません。例えば、ステートマシンの中でathenaのクエリ結果を取得しようとすると以下のようなJSONが出力されます。 { " QueryExecution ": { " EngineVersion ": { " EffectiveEngineVersion ": " Athena engine version 2 ", " SelectedEngineVersion ": " Athena engine version 2 " } , " Query ": " 発行したクエリ ", " QueryExecutionContext ": { " Database ": " データベース " } , " QueryExecutionId ": " 実行ID ", " ResultConfiguration ": { " OutputLocation ": " s3のロケーション " } , " ResultReuseConfiguration ": { " ResultReuseByAgeConfiguration ": { " Enabled ": false } } , " StatementType ": " DML ", " Statistics ": { " DataScannedInBytes ": 191831 , " EngineExecutionTimeInMillis ": 1704 , " QueryPlanningTimeInMillis ": 796 , " QueryQueueTimeInMillis ": 647 , " ResultReuseInformation ": { " ReusedPreviousResult ": false } , " ServiceProcessingTimeInMillis ": 85 , " TotalExecutionTimeInMillis ": 2436 } , " Status ": { " CompletionDateTime ": 1693159279869 , " State ": " SUCCEEDED ", " SubmissionDateTime ": 1693159277433 } , " SubstatementType ": " SELECT ", " WorkGroup ": " ワークグループ名 " } } ただ、多くの場合で欲しいデータは実際にクエリ結果がどこのs3に保存されているかだと思います。その場合には次のように入出力制御のためのOutputPathパラメータを使ってフィルタリングをすることによって欲しいデータだけを後続に渡すことができます。 $.QueryExecution.ResultConfiguration 実行結果 { "OutputLocation": "s3のロケーション" } 他にも出力制御にはResultSelectorやResultPathなど出力をコントロールするパラメータが提供されており、これらを活用することにより欲しい結果に絞ったデータを作ることができます。 現状の課題 ここまでエブリーにおけるStep Functionsの活用事例について紹介させていただきましたが、しばらく運用している中で次のような課題も出てきました。 ステートマシンのIaC化 ステートマシン自体はASL(Amazon States Language)で記述されているのでコードで管理できないわけではありません。ただ、個人的にこの記述自体の学習コストが高く、ステートマシンが複雑になればなるほどコンソールのビジュアライズされたWorkflow Studioで組んだ方が直感的なケースが多いと感じます。 今はそれほどステートマシン自体の変更を行う機会が少ないので大きな問題にはなっていませんが、今後の運用を考えるとIaC化は行なっておいた方が良いので、AWS CDKやTerraformでの管理方法などチームでPoCを行っていきたいと思っています。 各lambdaの管理 Step Functionsでステートマシンを作る場合にペイロードのちょっとした加工をして後続の処理に渡したいケースもたまにあり、提供される機能では足りない場合に徐々にlambdaの数が増えていってました。特に今回紹介しているステートマシン以外にいくつか別で新しくステートマシンを作っていくとなった時にコードを管理しているリポジトリでどのlambdaがどのステートマシンに影響しているのか見通しが悪くなってきています。 ここについては共通部分とそれぞれのステートマシン独自に使われるlambdaを階層わけして、まとめていきながら、前述したステートマシンのIaC化を推進できればその依存関係も新しいメンバーが理解しやすくなるのではと考えているので、チームで話しながらリファクタリングを進めていきたいです。 おわりに 今回のStep Functions導入により、コストを最小限まで削減しながらETL基盤構築を行うことができました。今後、運用するチーム体制や扱うデータの規模によってはGlueやMWAA、他のよりデータ処理に特化したサービスを選択した方が良い場合もあると思うので、事業の状況に合わせてシステム改善ができればと考えています。 またエブリーでは日々たくさんのバッチ処理が実行されていますが、その中では依存関係を起動タイミングで暗黙的に制御しているものもあったりするのでデータのETLだけではなく、そういったバッチ処理の実行にも今後ワークフローエンジンの導入を考えていきたいです。 ここまでお読みいただき、ありがとうございました。

DELISH KITCHEN の Android 版では、ライブラリ名を build.gradle に記載して管理していました。 // こんな感じ implementation "androidx.media3:media3-exoplayer:$MEDIA3_VERSION" implementation "androidx.media3:media3-exoplayer-hls:$MEDIA3_VERSION" implementation "androidx.media3:media3-ui:$MEDIA3_VERSION" ライブラリのバージョンだけは定数化されて別途取りまとめて管理していましたが、それも全てがまとまっているわけではなかったため、現在どのようなライブラリがどのバージョンで利用されているかが一目でわからない状態でした。 そこで、今後ライブラリの棚卸しを行いやすいように、また関係ライブラリを束ねて扱えるようにするため Version Catalog でとりまとめることにしました。 環境 Android Studio Giraffe | 2022.3.1 Gradle 8.0 やったこと Android Developers に移行についての記事(※1)があり、そちらを参考に作業を行いました。 作業の流れは以下の通りです。 libs.versions.toml ファイルとセクションの作成 libs.versions.toml ファイルへライブラリの情報を記載 記載した情報を利用して gradle を修正 それぞれ詳細を見ていきましょう。 libs.versions.toml ファイルとセクションの作成 まずはルートの gradle ディレクトリ配下に libs.versions.toml という名前のファイルを作成します(※2)。 続いてこのファイル中に versions/libraries/bundles/plugins という 4 つのセクションを作成します。 この後、これらのセクションでは以下のような値を記載していきます。 versions ライブラリのバージョン値 libraries ライブラリのエイリアス名 bundles 関係するライブラリたちを束ねたエイリアス名 plugins プラグインのエイリアス名 libs.versions.toml ファイルへライブラリの情報を記載 各モジュールなどにある gradle ファイルを確認し、記載されているライブラリなどの情報を libs.versions.toml ファイルへ書き出していきます。 libs.versions.toml ファイルの各セクションに対して、以下のように記載していきます。 記載した情報を利用して gradle を修正 libs.versions.toml ファイルへ情報を集約した後はいよいよ gradle ファイルへ適用していくことになります。 apply plugin や implementation などをゴリゴリ書き換えていきましょう。 before after この際に利用する名称は libs.{セクション名}.{ハイフンをドットに変換したエイリアス名} となる点に注意が必要です。 どうなったか これで libs.versions.toml ファイルを見るだけでどんなライブラリがどんなバージョンで使われているかを確認できるようになりました。 モジュールに散った gradle をあちこち開かなくてよくなり、今後のライブラリ棚卸しが楽になりました。 また、bundles のおかげで関連ライブラリをまとめて扱えることにより、必要なライブラリの記載が漏れたりバージョンの指定を誤ったりといったミスがなくなります。 まとめ ポジティブな意見として、 Version Catalog は Android アプリ開発に必須な対応ではありませんが、対応することで1ファイルにライブラリ情報が集約されるため、今後のライブラリ管理が楽になると思います。 Version Catalog を用いることでは、特に関連ライブラリをbundleとして扱える点が便利と感じています。 今回、 libs.versions.toml ファイルという専用のファイルへまとめた方が gradle とは切り分けできてよいと考えて着手しましたが、他にも settings.gradle へまとめる方法(※3)も存在しています。 どちらの方法でも1ファイルに集約して管理できるという点はメリットであると思っています。 ネガティブな意見としては、ライブラリの管理の際にgradle以外にもtomlという登場人物が増えることが逆にちょっと嫌だという意見がありました。 また、エイリアス名の命名で名前被りを回避するためにハイフン刻みとするため、それによりエイリアス名が長くなることがあったとの意見もありました。 他に、 Version Catalog の補完やジャンプが行えない点が不便・・・だったのですが、この点含む Version Catalog に対するサポートはAndroid Studio Giraffeではいろいろと改善(※4)されていました。 最終的にはチームメンバみんなの理解を得ての採用となりますが、開発作業を楽にすることができる技術は今後も検討して取り入れていければと思っています。 参考 ※1 ビルドをバージョン カタログに移行する https://developer.android.com/studio/build/migrate-to-catalogs?hl=ja ※2 The libs.versions.toml file https://docs.gradle.org/current/userguide/platforms.html#sub:conventional-dependencies-toml ※3 Declaring a version catalog https://docs.gradle.org/current/userguide/platforms.html#sub:version-catalog-declaration ※4 Android Studio Giraffe が安定版に - Gradle ビルド スクリプトの Kotlin DSL https://android-developers-jp.googleblog.com/2023/08/android-studio-giraffe-is-stable.html

はじめに 2023年8月1日、MAMADAYSはトモニテに生まれかわりました。 tomonite.com iOSアプリもトモニテに名前を変え、これまでのメイン機能である「育児記録」「妊娠週数管理」を軸として、家族やパートナー、家族以外の人や社会との接点を作るためのシェア機能やコミュニティ機能などの拡充をめざしていきます。 トモニテのiOSアプリは新規作成画面を中心にSwiftUIの導入を進めています。一方、既存の画面を全面的にSwiftUIに置き換えることは考えていないため、今後もUIKitの画面のメンテナンスも継続していきます。 今回はUIKitの画面にResult Buildersを導入してメンテナンス性を向上する取り組みをご紹介します。 Result Buildersとは Result BuildersはSwift 5.4で導入されました。 Result Buildersを使うと、リストやツリーなどの構造化されたデータを、より自然で宣言的な構文で作成することができます。 https://docs.swift.org/swift-book/documentation/the-swift-programming-language/advancedoperators/#Result-Builders Result BuildersはSwiftUIの@ViewBuilderや、RegexBuilderで使われています。 ArrayBuilderを作る Result Buildersを使って、任意の型の配列を出力する関数を宣言的に書けるようにするArrayBuilderというものを考えてみようと思います。 以下のようなIntの配列を出力する関数を、 var numbers: [Int] { var numbers: [Int] = [ 1, 2 ] if xxxx { numbers.append(3) } return numbers } ArrayBuilderを用いて以下のように書けるようにします。 @ArrayBuilder<Int> var numbers2: [Int] { 1 2 if xxxx { 3 } } ArrayBuilderを適用した場合、以下のような点で改善されていると思います。 変数宣言、append、returnのような手続き的な記述が不要で、コードが簡潔になった コードの構造と出力する値の構造が一致していて理解しやすい 値の追加、削除などの変更がしやすい ArrayBuilderの実装は以下のようになります。 @resultBuilder struct ArrayBuilder<OutputModel> { static func buildBlock(_ components: [OutputModel]...) -> [OutputModel] { return components.flatMap { $0 } } static func buildExpression(_ expression: OutputModel) -> [OutputModel] { return [expression] } static func buildExpression(_ expression: ()) -> [OutputModel] { return [] } static func buildOptional(_ component: [OutputModel]?) -> [OutputModel] { return component ?? [] } static func buildEither(first component: [OutputModel]) -> [OutputModel] { return component } static func buildEither(second component: [OutputModel]) -> [OutputModel] { return component } static func buildArray(_ components: [[OutputModel]]) -> [OutputModel] { Array(components.joined()) } } UICollectionViewDiffableDataSource / UITableViewDiffableDataSourceのsnapshotに適用 次に、UICollectionViewDiffableDataSource / UITableViewDiffableDataSourceによみこませるためのsnapshotを作成する処理にArrayBuilderを使うことを考えました。 snapshotを生成する処理は以下のようなイメージです。 class ViewModel { enum Section: Hashable { case .section1 case .section2 } enum Row: Hashable { case .row1 case .row2 case .row3 case .row4 case .row5 } public var snapshot: NSDiffableDataSourceSnapshot<SectionType, RowType> { var snapshot = NSDiffableDataSourceSnapshot<SectionType, RowType>() snapshot.appendSections([.section1, .section2]) snapshot.appendItems([.row1, .row2, .row3], toSection: .section1) snapshot.appendItems([.row4, .row5], toSection: .section2) return snapshot } } ArrayBuilderを使用したDiffableTableViewModelプロトコルを作成し、以下のような書き方をできるようにします。 class ViewModel: DiffableTableViewModel { typealias SectionType = Section typealias RowType = Row enum Section: Hashable { case .section1 case .section2 } enum Row: Hashable { case .row1 case .row2 case .row3 case .row4 case .row5 } // この関数が改善されています var tableSections: [TableSection<Section, Row>] { TableSection(.section1) { .row1 .row2 .row3 } TableSection(.section2) { .row4 .row5 } } } ここでは使用していませんが、tableSections関数の中でfor文やif文を用いることもできます。 DiffableTableViewModelを導入することで以下のような効果が得られたと思います。 手続き的な記述が不要でコードが簡潔 画面要素の構造とコードの構造が一致していて理解しやすい 画面要素の追加/削除/並べ替えなどに容易に対応できる DiffableTableViewModelプロトコルは以下のように定義しています。 import UIKit protocol DiffableTableViewModel { associatedtype SectionType: Hashable associatedtype RowType: Hashable @ArrayBuilder<TableSection<SectionType, RowType>> var tableSections: [TableSection<SectionType, RowType>] { get } } extension DiffableTableViewModel { var snapshot: NSDiffableDataSourceSnapshot<SectionType, RowType> { var snapshot = NSDiffableDataSourceSnapshot<SectionType, RowType>() snapshot.appendSections(tableSections.map {$0.sectionType}) tableSections.forEach { tableSection in snapshot.appendItems(tableSection.rowTypes, toSection: tableSection.sectionType) } return snapshot } } struct TableSection<SectionType, RowType> { let sectionType: SectionType let rowTypes: [RowType] init(_ sectionType: SectionType, @ArrayBuilder<RowType> rowsBuilder: () -> [RowType]) { self.sectionType = sectionType self.rowTypes = rowsBuilder() } } 以上参考になれば幸いです。

はじめに はじめまして。DELISH KITCHEN 開発部 の 羽馬（ @NaokiHaba ）と申します。 この記事では、DELISH KITCHEN 開発部 で 行っている Node.js のバージョンアップの手順と、その際に発生した問題とその対応についてご紹介します。 対象読者 この記事は、 Node.js のバージョンアップを行いたいが、どのような手順で行えばよいかわからない方や、 Node.js のバージョンアップを行った際に発生した問題の対応方法を知りたい方を対象としています。 この記事で紹介する環境 この記事で紹介する環境は以下の通りです。 Node.js v16.13.1 npm v8.1.2 nodenv v1.4.1 バージョンアップの背景 DELISH KICTHEN WEB では フロントエンドのランタイムとして Node.js を採用しています。 tech.every.tv 現在利用している Node.js のバージョンは v16.13.1 ですが、 2023 年 9 月 11 日 に EOL が予定されているため、今回 Node.js のバージョンアップを行うことにしました。 バージョンアップの手順 リリースノートの確認 Node.js のバージョンアップを行う際は、リリースノートを確認し、バージョンアップによって発生する可能性のある問題を事前に把握する必要がありました。 nodejs.org nodejs.org OpenSSL に関する変更が多く含まれていることから、 Node.js のバージョンアップによって発生する可能性のある問題として、以下のようなものが考えられました。 変更前のバージョンの Node.js で利用していた OpenSSL のバージョンと、変更後のバージョンの Node.js で利用している OpenSSL のバージョンが異なることによって、 OpenSSL に関する問題が発生する可能性がある Node.js のバージョンアップ Node.js のバージョンアップは、 nodenv の install コマンドを利用して行います。 # 現在のバージョン情報を確認 $ node -v 16.18.0 # .node-version を更新 $ vi .node-version # .node-version 18.16.1 # nodenv で 18.16.1 をインストール $ nodenv install $(cat .node-version) # 18.16.1 $ node -v 18.16.1 .node_modules・ package-lock.json を再作成する Node.js v16.18.0 でインストールした node_modules を、 Node.js v18 で利用すると依存関係の不整合等が発生する可能性が高いことから、 node_modules を削除し、 package-lock.json を再作成します。 $ rm -rf node_modules package-lock.json # npm のキャッシュで古いバージョンのパッケージが残っている可能性があるため、キャッシュを削除 $ npm cache clean --force # キャッシュがクリアされたかどうかを確認 $ npm-cache verify # package-lock.json を再作成 $ npm install OpenSSL の 互換性エラー Node.js v18 でアプリケーションが正常に動作するか確認すると、以下のようなエラーが発生しました。 $ npm run dev # 以下のようなエラーが発生する場合は、後述の「`Node.js` v18 での `crypto` モジュールの変更」をご確認ください。 Error: error:0308010C:digital envelope routines::unsupported at new Hash (node:internal/crypto/hash:71:19) at Object.createHash (node:crypto:133:10) Node.js v18 での crypto モジュールの変更 Node.js v18 では、 crypto モジュールのデフォルトの暗号化方式が変更されたことにより、 Node.js v16 で正常に動作していたアプリケーションが正常に動作しなくなる可能性があります。 対象方法としては、以下の 2 つが考えられます。 webpack のバージョンアップ 暫定措置として package.json の scripts に NODE_OPTIONS=--openssl-legacy-provider を追加する 本来は webpack のバージョンアップを行うことが望ましいですが、 webpack のバージョンアップには時間がかかるため、暫定措置として package.json の scripts に NODE_OPTIONS=--openssl-legacy-provider を追加することで対応しました。 Error when running build-storybook with Node 17 · Issue #16555 · storybookjs/storybook · GitHub nodejs.org { " scripts ": { " dev ": " NODE_OPTIONS=--openssl-legacy-provider app/server/index.js --watch " } } 上記の設定を追加することで、 Node.js v18 での crypto モジュールのデフォルトの暗号化方式を変更することができます。 以上の手順で、 Node.js v18 へのバージョンアップを完了することができました。 Dockerfile の変更 Node.js のバージョンアップに伴い、 Dockerfile の FROM で指定している Node.js のバージョンを変更します。 # 変更前 FROM node:14.17.3-alpine3.14 # 変更後 FROM node:18-alpine3.16 最後に Node.js のバージョンアップは、 Node.js のバージョンアップによって発生する可能性のある問題を事前に把握し、対応する必要があります。 この記事が、 Node.js のバージョンアップを行う際の参考になれば幸いです。