モバイルエンジニアインターン生の筒井です。 本記事では、私が入社して行ってきたReact Nativeプロジェクトの、GitHub Actions上でのスクリーンショットテスト実装についてお話しします。 これによりGithub Actions上でReact Nativeアプリが動き、そのスクリーンショットが保存され、確認できるようになります。 背景 アプリ開発において、自動テストを行うことでコード内のエラーなどに気づくことができます。 しかし、Natureでは自動テストでロジックの確認は行なっていますが、現状、画面のレイアウト崩れは検知することができません。 そのため、実際に実装画面を見てみないと分からないデザインの崩れや画面遷移の確認などは、手元で動かして確認しています。 手元での確認は、 ただ、この確認作業はビルド→起動→遷移の確認...と手順が多く手間な作業です。 そこで、GitHu

ここ半年ほど、メインのエディタとしてZedを使っている。 動作が軽快で、生成AI関連の機能も標準でサポートされているなど、使い勝手が良いので気に入っている。 しかし、まだまだ発展途上ということもあり、乗り換え前に使っていたVSCodeと比べると、 どうしても機能的に足りない部分があるのは否めない。 足りないものの一つとして、テスト実行とそのレポート機能が挙げられる。 今回は、これを Zed の Task 定義によって補おうという話。 VSCodeのテスト実行機能 #VSCode上でテストを実行すると、テストケースごとに成功・失敗が表示され、 各ケースの出力を個別に表示したり失敗したテストコードにジャンプしたりすることができる1。 VSCode上のテスト実行結果表示。整理されて表示されるので見やすい。 一方、Zed にはいまのところテストレポートを表示する機能はない2。 Task 実行機能を

Obsidianでシンプルにタスクを管理するためのプラグイン. Contribute to tadashi-aikawa/silhouette development by creating an account on GitHub. Daily note を開いて Silhouette: Insert tasks を実行すると、 設定されたルールに基づいて繰り返しタスクリストを挿入してくれるすぐれもの。 曜日指定の繰り返しや、「月内最後の平日」のような指定もできるので、たいていのケースに対応できる。 ただ、Daily note を開くたびに上記のコマンドを手動で実行するのは面倒だ。 毎日のことなのでなおさら。 これを自動化したい。 タスクリストを自動挿入する #Silhouette には、挿入対象のファイル名を見てどの日のタスクを挿入するかを判定する機能がある。 これとおなじみの Tem

バックエンドエンジニアインターン生の倉永です。インターン期間中、DynamoDBへAuto Scalingを導入するか検討した際に、色々と気づきが多かったので、それについてお話しします。 背景 NatureではNature Remo Eという商品を販売しています。Nature Remo Eを使うと、家庭で消費した電力のグラフを以下のようにアプリで確認できるようになります。 これを実現するために、Nature Remo Eは計測した電力の時系列データをサーバへ送信し、送信されたデータはDynamoDBのテーブルで管理をしています。 このテーブルは以前、プロビジョンドキャパシティモード（当時はAuto Scalingなし）で運用されていたのですが、これがサーバ障害の原因となってしまいました。別の障害に起因してテーブルへの書き込み負荷が増加し、スロットリングによる遅延が発生することでデータを書き

2025 年に入ってから AI の、特にエージェントによる支援を強く受けられる開発環境の導入を進められた方は多いのではないかと思っています。 僕が働いている Ubie でも、先日お伝えした通り Cursor や Cline の検討を行っていました。 そしてこのたび、 Ubie では Cursor の Business プラン を導入するに至りました。 本記事では Ubie で Business プランを導入するに至るまでの検討・調整と、導入から二週間経過した上での所感をお伝えします。 AI による強力な開発支援を受けたい方々の検討材料になったら嬉しいです。 TL;DR Ubieは、AIコーディング支援ツール「Cursor Business」を迅速に導入し、すでに40名以上の開発者が活用を開始しています。 一人当たり月額 $40 というコストながら、AIエージェントの活用により、開発の生産性

id:cohalzです。この記事は、はてなのSREが毎月交代で書いているSRE連載の2025年1月号の記事です。 2024年にはこのHatena Developer BlogにてSRE連載と言う毎月一回交代でSRE関連のブログ記事を書く企画を開始しました。 今回はその連載記事の紹介と工夫について紹介していきます。 記事一覧 id:hagihala はてなブログの DB を RDS for MySQL 8.0 にアップグレードした話 developer.hatenastaff.com readonlyメンテはめちゃくちゃ強力な武器だなと思っているので社内外でももっと広まって欲しいですね。あと0年や10000年も考慮しないといけないというのはまず役に立たない知識でこれも面白かったです。 id:masayosu はてなにおけるEKSの運用と自動化 (2024年版) developer.haten

この記事はTech KAYAC Advent Calendar 2024の25日目の記事です。 こんにちは、@commojunです。 www.kayac.com 私がサーバサイドエンジニアとしてずっと従事してきたソーシャルゲームサービス「ぼくらの甲子園！ポケット」が、2025年1月8日でサービスを終了します。 prtimes.jp ぼくらの甲子園！ポケット（以下ぼくポケ）開発チームでは、これまで遊んでくださった皆様への感謝を伝えるため、2024年10月1日から、「天下一甲子園大会」という特別なイベントを開催していました。そしてつい数日前の12月22日、イベントのすべての内容が終了しました。 この天下一甲子園大会というイベントの開発は、たった3ヶ月のイベントのためにこれまでの運用の10年間、いっさい手を加えられなかった聖域みたいな箇所に多くの破壊的な変更を入れ、ほとんど一発勝負でリリースする

この記事はMackerel Advent Calendar 2024 の17日目です。 こんにちは、SREチーム所属の@mashiikeです。 今年のMackerel Advent Calendarは、OpenTelemetry関連の記事が多くて私も流行りに乗ろうかと思いましたが、ネタが間に合いませんでした！ この記事では、Mackerelの機能の中でも個人的に一押しのグラフアノテーションについて、弊社内での使い方の事例を紹介します。 グラフアノテーションとは グラフアノテーションは2017年1月にリリースされた機能で、サービスやロールに関連する注釈をグラフ中に記述することができる機能です。 mackerel.io 上記の画像では、私が作成しているOSS prepalertを使って、グラフ中に関連するMackerelアラートを注釈として記入しています。 前年の今の時期に、アップデートでカス

技術部の長田です。 このエントリは面白法人グループ Advent Calendar 2024の6日目の記事です。 みなさん、ふだん技術系の最新情報ってどこから手に入れているでしょうか？ 私は家事育児の忙しさにかまけて自力での情報収集をサボり、もっぱら社内Slackの情報を頼りにしています。 コンテキストが近い人達がわざわざ共有してくれる情報ということで、精度は間違いありません。 が、そろそろ自分も共有する側に回れるようにならないとなということで、 まずは社内のエンジニアにどうやって情報を得ているのかを聞いてみることにしました。 アンケートを取ってみた と、いうことで社内のエンジニア向けに以下のようなアンケートを取ってみました。 期間: 11/25〜12/1の1週間 アンケート内容: 職能(フロントエンドorバックエンド) 情報源名 情報源のURL その情報源を参照する目的 コメント 結果、

SREチームの長田です。 今回はAWSのVPC(Virtual Private Network)内で作業する時の話です。 VPC内で作業したい VPC内で作業したいこと、ありますよね。 環境構築中の動作確認とか、不具合・障害調査のための定形外作業とか、メンテナンスためのイレギュラーな作業とか。 定常的に行うほどではないですが、AWSでVPCに絡んだサービスを使用しているなら、VPC内での作業は少なからずあると思います。 VPC内に閉じたリソースにアクセスする場合は、当然ですがVPC内からアクセスする必要があります。 VPC外からアクセスするための経路を用意すればそれも可能ですが、アプリケーションが使っている経路とは異なる経路を使うことになるため、 不具合調査時の再現確認などでは余計な要素となることがあります。 VPC内からの操作は、AWSであればCloudShellで VPC環境を作るのが

SREチームの長田です。 皆さんは操作するAWSアカウントを取り違えたことはありますか？ 私はあります。 カヤックのSREは複数のプロダクトを担当することも多く、 ひとつのプロダクトでも環境(本番、ステージング、開発、etc.)ごとにAWSアカウントを分ける場合があり、 扱わなければならないAWSアカウントが多くなる傾向にあります *1。 今回はうっかり別のアカウントのリソースを削除してしまったーといったオペレーションミスを減らすために個人的に行っている、 「気をつける」以外の対策を紹介します。 間違いに気づくための対策 対象のアカウントが操作の対象として正しいかどうかは、結局は操作している本人にしか分かりません *2。 そのため、「アカウント取り違え自体をなくす」のではなく、 「アカウントを取り違えていることに気づきやすくする」ための対策をしています。 AWSコンソール用の対策 AWSコ

技術部の長田です。 YAPC::Hakodate まで1週間を切りましたね。 今回は当日登壇するカヤックメンバーの紹介と、当日実施予定のイベントについてご案内です。 前夜祭: 「AWS Lambda FunctionURLで実現するスケーラブルで低コストなWebサービス構築」 by fujiwara 前夜祭ではSREチームの藤原が登壇します！ トーク概要より: AWS Lambda FunctionURLを活用し、従来の開発モデルで作られたWebアプリケーションを最小限の変更でサーバーレス化する手法を紹介します。 カヤックが運用するeスポーツ大会支援サービスTonamelでは、Goで実装されたマイクロサービスをECSからLambdaへ移行し、急激な負荷増加への対応とコスト削減を実現しました。 今回のYAPC::Hakodateスポンサー連動企画Perlbatrossでは、Perlで実装した

SREチームの長田です。 SREsとしての業務がメインではあるのですが、実はSREチームの人事リソース管理を担当していたりします。 今回はそんな立場から「SRE活動用のリソース」について紹介してみようと思います。 SREなのに「SRE活動用」リソース？ カヤックのSREは、担当プロダクトチームのメンバーとして動く、いわゆるEmbedded SREです。 社内の予算計画の話になってしまうのですが、プロダクトを持つ事業部がSREメンバーのリソース配分を期ごとに確保する形式となっています。 例えばあるメンバーのリソース(100%)のうち、50％分をTonamel(ゲームコミュニティ事業部)に、 30％分をまちのコイン(ちいき資本主義事業部)に割り振った場合、 各割合分のリソースを各プロダクトが属する事業部が負担する形です *1。 Embedded SREの活動とは別に、プロダクトとは直接関係のな

SREチームの長田です。 今回は、カヤックのメンバーが業務で使うために開発・公開しているOSSなプロダクトをまとめて紹介しようという企画です。 KAYAC organization以下にあるものだけでなく、在籍中のメンバーが作ったものもひっくるめて、実際に業務で使用しているものを中心に 紹介しています。 以下の3つのカテゴリに分けて記載しています。 各カテゴリ内はアルファベット順です。 ツール編 人間が手動で実行するもの アプリケーション編 どこかに常駐して、イベントを受け取ると動作するもの ライブラリ編 ツールやアプリケーションから参照されるもの 集めてみたらそこそこの量になったので、本記事では詳細な説明は省いています。 GitHubリポジトリのURLや関連記事のリンクを併記していますので、より詳しく知りたい場合はそちらを参照ください。 (...) 内はそのプロダクトで使用している主なプ

SREチームの長田です。 SRE関連の記事としては今年最初の記事になります。 今年も定期的にSREチームメンバーによる記事を投稿していく予定です。 よろしくお願いします。 さて、今回はGitHub Actionsのはなしです。 TL;DR デプロイを実行するGitHub Actionsの実行状況を デプロイ対象環境ごとに別々のSlackチャンネルに通知する場合の実装例として、 「slackapi/slack-github-actionで通知をつくりこむ」 「Actions Workflowを分ける」 「Actions Workflow実行の入り口を分ける」 の3つを紹介します。 背景 カヤックでは「まちのコイン」という地域通貨サービスを開発・運用しています。 coin.machino.co まちのコインの開発・運用チームの、特にサーバーサイドに関しては、 アプリケーションやインフラ構成の変

SRE チームの市川恭佑です。 先日、CloudNative Days Tokyo 2023 のプロポーザルを提出したのですが、残念ながら採択に至らなかったので、今回は宇宙最速の（？）供養エントリになります。 シェア・投票など、ご応援をくださった皆様にはこの場でお礼を申し上げます。ありがとうございました。 event.cloudnativedays.jp 背景とか、経緯とか 筆者は、カヤックの SRE チームにちょうど2年ほど在籍しています。とは言っても半年ぐらいは学生アルバイトだったので、正社員としては1年半ほどです。カヤックに入る前も、いくつかの会社で IT エンジニアとしてインターンやアルバイトをしていました。 という訳で、何だかんだ仕事で使うプログラムを書き始めてトータル4年半ほどになりますが、そのうち3年半ほどは全て Amazon Web Services（AWS）でホストされる

SREチームの長田です。 みなさま開発・運用上の定形オペレーションに伴うタスク実行をどのように管理していますか？ 今回は make をタスクランナーとして使う例を紹介します。 タスクランナーがほしい タスクランナーを使う主なモチベーションは以下の2つです。 タスクをリスト化したい タスクの実行インターフェイスを統一したい タスクがリスト化されていれば、それ自体が生きたドキュメントとして機能します。 また、タスクの実行インターフェイスが統一されていれば、 例えばタスクに前処理や後処理を追加したとしても、 開発・運用メンバーが実行するべき操作が変わることはありません。 操作変更の周知コストも下がりますし、変更に伴う操作ミスも減らすことができます。 タスクランナーに求めるもの タスクランナーの機能としては必要最低限のものがよいと考えています。 高機能なタスクランナーも魅力的ではあるのですが、タス

SREチームの長田です。 今回は開発・検証用Amazon RDS(以下RDS)の運用のはなしです。 はじめに 「常時使用するわけではないけど、一定の頻度で必要になるデータベース」というものがあります。 AWSリソースの動作確認を行う環境(カヤックではこれを「ステージング環境」と呼ぶことが多いです)や、 リリース後の負荷試験環境など、本番環境とは異なる環境にあるデータベースがこれにあたります。 AWSのようなクラウドサービスを利用している場合、起動時間に対して課金が発生することが多いでしょう。 負荷試験用に用意したRDSインスタンスは、試験が実施されていない期間はただ課金が発生するだけのリソースになってしまいます。 たまにしか使われないデータベースを放置しておくのはもったいない 負荷試験で使用するものは、大抵の場合本番環境と同じスペックのものを用意することになるでしょう。 すると本番環境と同

SREチームの藤原です。今回は監視サービスのMackerelと、障害発生時に担当者へのオンコールを自動化するGrafana OnCallを連携してみた話です。SRE連載 6月号になります。 3行でまとめ MackerelとGrafana OnCallを連携しました MackerelのアラートWebhookをGrafana OnCallのWebhookに変換するproxyをAWS Lambdaで作りました。OSSで公開しています Grafana OnCallの管理はTerraformでやっています はじめに カヤックでは、運用しているサービスの監視のためにMackerelを利用しています。サービスで障害が発生した場合に担当者を呼び出す(オンコール)ためのツールとして、2023年3月までは ryotarai/waker を使用していました。 wakerはもともとクックパッド社で利用されるために

SREチームの長田です。 突然ですが、 mirage-ecs というツールをご存知でしょうか？ 今回はこのツールをまちのコインの開発チームでの使用例をもとに紹介します。 coin.machino.co mirage-ecs を使うと動作確認用のサーバー環境を、サーバーサイドのエンジニアでなくとも自由にいくつでも立ち上げることができるようになります。 「環境」は AWS のECSクラスタ上で起動し、専用のURLが割り当てられ、 認証*1を通過すればどこからでもアクセスできます。 これにより 「クライアントアプリとつなぎ込んで動作確認したいけど、開発環境が空いてないから確認できない」 や、 「プロダクトオーナーに新機能を確認してもらいたいけど、開発環境が空いてないから(以下略)」 といった問題が解消し、 開発と動作確認のサイクルをスピーディーに回すことができるようになります。 mirage-e