はてなブックマーク

False Negative はレビュアーの負担に、False Positive は実装者の負担に繋がります。そのため、AI 利用を前提とするなら False Negative をより減らす方向に倒すべきです。つまり、自動チェックを極力厳しくすべきです。 そして今のところ、最も確実で手っ取り早い自動チェックの手法は、テストと型チェックです。だから我々は、readable, testable, checkable なコードを書くように AI を誘導する必要があります。 自己完結的なコードはバグを起こしにくい コードを改修する際には大抵、依存しあう複数の箇所を合わせて変更します。この時に考慮や更新の漏れがあると、バグに繋がります。依存する情報が小さな範囲にまとまっていて自己完結的であれば、考慮漏れをしにくくなり、バグを起こしにくいと言えます。 具体例として、会計時の割引額を計算するロジックを考

はじめに こんにちは！株式会社ダイニーの Platform Team に所属しています。0tanyです。 モダンなモジュラーモノリスアーキテクチャでは、環境変数の管理が重要な課題の一つです。事業成長とともにサービス数と環境数が増加すると、その管理複雑性は指数関数的に増大していきます。 本記事では、この移行を通じて得られた知見を共有します。同様の課題を抱えるチームの参考になれば幸いです。 従来のアーキテクチャの問題点 環境別の.env ファイルと Docker イメージの管理地獄 上記が従来のアーキテクチャです。ダイニーでは飲食店向けのモバイルオーダーサービスを 4 つの環境（develop/staging/beta/production）で運用しており、それぞれの環境に対して 4 つのサービス（web、backend、backend-online-payment、backend-reser

潜んでいるリスク、一番苦手なリスクです！どうも、whatasoda です。 モノリシックなサービスでは、サービスの成長とともに 1 つのアプリケーションの中にさまざまな性質の処理が混在するようになります。Node.js のようなシングルスレッドで処理が実行されるランタイムでは、複数の処理を走らせる場合に 1 つしかないスレッドを取り合う形で互いの処理を待機させ合うような振る舞いをすることがあります。 技術スタックを TypeScript に統一しているダイニーでは当然バックエンドの API サーバーを Node.js 上で実行しています。過去、「注文の受付」や「会計処理」といったリアルタイム性が求められる処理と、「売上の集計」や「CSV ファイルの生成」といったバッチ系の重たい処理が一部共存していたことがありました。 そういった環境で実行される処理同士が干渉し合うことで、レイテンシやエラー

はじめに こんにちは、ダイニーのデータチームのエンジニアをしている kawamitsu です。 ダイニーでは飲食店さま向けのデータ分析プロダクトを提供しています。 本記事では、膨大な店舗データの処理によるアプリケーションのボトルネックを、データ基盤によって解決した事例を紹介します。 先に成果を説明しますが、データ基盤の再設計によりユーザーのデータ分析においてタイムアウトのほぼ全廃と全店舗・任意期間のデータ取得を可能にしました。 この記事を通して、データエンジニアリング × アプリケーションエンジニアリング の開発に少しでも興味を持っていただけたら幸いです。 背景：飲食店におけるデータ活用の重要性 飲食店の経営において、データの活用は重要な経営判断の基盤となります。 注文履歴、決済履歴、監査目的の会計取消・修正履歴など、多岐にわたる情報を、全店舗分まとめていつでもアクセスできる環境が求められ

どんな問題を解決したのか こんにちは、ダイニーの ogino です。 ダイニーでは、飲食店向けのクラウド POS レジを開発しています。その機能の一つとして、一ヶ月分の売上などの情報を印刷できる「月締伝票」があります。 月締伝票のサンプル 月締伝票に記載するデータは、Node.js バックエンドで集計をしています。この API はダイニーのバックエンド全体の中で最も重く、最近では一部店舗でレスポンスに 200 秒以上かかりタイムアウトエラーが発生していました。 その結果、月締伝票を発行することができないため顧客の業務に支障をきたし、複数の問い合わせが来ている状態でした。 プロファイラやログを手掛かりに調査したところ、ボトルネックを 2 行のコードだけに特定し、ほぼコストをかけずにレスポンス時間を 20 秒ほどに改善することができました。 改善リリース前後のレスポンス時間の変化 ボトルネック

はじめに こんにちは、ダイニーの ogino です。 この記事では、AI エージェントや MCP に入門しようとしている人向けに、エージェントの内部実装について概説します。これを理解することで、現状の AI にできることが明確になり、今後の技術動向を追う上でも役に立つはずです。 本記事の要旨 MCP の表層的なプロトコルには大した意味も革新性も無いので、AI エージェントを理解するにはまずコンテキストを把握しましょう。 素の LLM の能力と、エージェントの実装を切り分ける AI エージェントは、自律的に判断してファイル操作や Web ブラウザなどのツールを使い分けることが可能です。しかし、その基盤となっている LLM にできるのは、テキストを入力してテキストを出力することだけに限られます[1]。 以降では「LLM にできないこと」を掘り下げ、それを補うために AI エージェントがどのよう

ダイニーの urahiroshi です。 自分は前職のメルカリ、現職のダイニーで計3年くらい Engineering Manager を務めてきましたが、Engineering Manager の本質的な役割は「チームや組織のパフォーマンスを最大化すること」だと考えています。そのためには、チーム開発におけるメンバー間のスムーズなコミュニケーションが不可欠です。 これまでコミュニケーションに関するフィードバックを行ってきた中で、よく見られる改善点がいくつかあったため、それらをベストプラクティスとしてまとめてみました（それぞれのセクションで一つずつ本が書けるくらい多数のプラクティスが挙げられるテーマだと思いますが、特に頻出するポイントに絞っています）。皆さんのチーム開発にも役立てていただければ嬉しいです！ レビューをするときのプラクティス 指摘にはWhyを書き、Howを押し付けない ❌️ Ba

はじめに こんにちは、ダイニーの ogino です。 TypeScript のコンパイラは今まで TypeScript で実装（セルフホスト）されていました。 それが TypeScript 7.0 から、Go による実装に移植され、10 倍高速になります。 本記事は、移植に関して筆者が疑問に感じた点を、GitHub discussion や TypeScript lead architect のインタビュー動画などから調べてまとめたものです。 移行の背景 今回 Go に移植される背景は、大規模な TypeScript コードベースをコンパイルする際のスピードの遅さにあります。 例えば VSCode のコードベース (150 万行) に対して tsc を実行すると、約 80 秒もかかります。 TypeScript のコンパイルは大きく以下の段階に分けられ、その内の check が特に複雑で重

はじめに こんにちは、ダイニーの ogino です。 この記事では、コードの読みやすさを比較判断するために役立つメンタルモデルを紹介します。 本記事を読むと、「このコードは良い / 悪い」という感覚が身につき、その理由を自信を持って説明できるようになるはずです。 コードの読みやすさとは何か コードを読む時には大抵、何か特定の目的があります。例えば、 API /foo にリクエストした時の動作を知りたい、ある画面で発生しているバグの原因を知りたい、などです。 この時、コードベースの隅から隅まで読み尽くすのではなく、特定のポイントから出発して関連する箇所を芋蔓式に辿りながら読むはずです。 人が一度に理解して覚えておける情報量には限界があるので、辿らなければいけないコード量が少ないほど当然読みやすくなります。 つまり、ある目的に関連するコードの箇所が局所的かつ明示的であるほどコードは読みやすいと

はじめに こんにちは、ダイニーの ogino です。 この記事では GitHub の bug bounty で脆弱性を報告し、実際に報奨金を受け取った時の体験を共有します。 私は特にセキュリティの専門家ではなく、偶然に問題を見つけて初めて報告をしました。読者の方が同じようなチャンスに遭遇した時スムーズに行くように、海外からお金を受け取る上での意外なつまずきポイントや、実際に貰える金額などについて紹介します。 どんな問題を見つけたのか 今回見つけたのは、GitHub Copilot の VSCode 拡張機能に関する問題です。 この拡張機能のソースコードは本来公開されていないはずですが、TypeScript のソースマップによって元のコードが露出していました。 そもそも VSCode の拡張機能は .vsix という拡張子の付いたパッケージ形式で配布されます。これは実態としてはただの zip

ダイニーの urahiroshi です。 ダイニーはプロダクト・組織ともに拡大中です。プロダクトの利用が広がれば広がるほどセキュリティの重要度も増してきますが、ダイニーにはセキュリティの専門家がおらず、体系立ててセキュリティ対策を実施できていなかったという課題がありました。 この記事では、ダイニーのセキュリティ改善の取り組みを紹介していくことで、ダイニーのようにセキュリティの専門家がいないスタートアップでもセキュリティを改善していく動きができるように後押ししたいと考えています。 ステップ0. 方針の策定 スタートアップの日々の開発業務において、プロダクトの改善やインシデント対策などについてはやりたいことが無数にあります。しかし、そういった目に見えて優先度が高いものを実施しているだけだと永遠にセキュリティ対策ができません。 そこで、まずセキュリティのリスクや優先度を見える化する動きを作り、継

テストで満点を取れるようになって、足が速くなって、恋人ができて、インスタンスの安定性も改善されました！！！ こんにちは、ダイニーの whatasoda です。ダイニーでは4年以上 Cloud Run を使っていますが、ロギングには @google-cloud/logging-winston を利用しています。これまで Cloud Logging API を直接呼び出す方式で利用してきて特段不便を感じることはありませんでしたが、最近これを Cloud Run の標準出力に書き込む方式へと変更したところタイトルのような効果を得ることが出来ました。（そもそも Cloud Run では標準出力（stdout）に書き込まれたテキストを自動的に Cloud Logging に記録してくれるようになっています。） なお、ダイニーでは NestJS アプリケーションを Node.js で実行しているため、

こんにちは、ダイニーの Feature team でソフトウェアエンジニアをしている @ta21cos です。 最近は新規事業である決済関連の機能の開発をメインに行なっています。 ダイニーにおける Feature team は機能にフォーカスした開発・運用を行っているチームです。最近は複数の事業毎に Unit として分かれて開発を進めています。 本日は、普段の開発で実際にあった Pull Request のレビューコメントから得た学びについて紹介します。 Dialog を実装しよう React を使ってある Dialog を作成するため、以下のようなコードを書きました（コードは簡略化しています）。 // useSample ファイル // 内部でロジックと Dialog を同時に定義している hook const Dialog = memo<{ progress: number, ...

こんにちは。dinii の whatasoda です。モノレポで JavaScript のローカルパッケージをいい感じにできる『tamashii』というツールを作ったので作るに至った背景や機能についてまとめました。 モノレポとローカルパッケージ dinii では開発に用いる言語を TypeScript に統一しています（こちらでご紹介いただいています！）が、ほぼ全てのプロダクトのソースコードをモノレポで管理しているという特色もあります。 dinii が提供している MO-POS-CRM サービスは 10 近くのプロダクト群から出来上がっているため、モノレポであることは一人のエンジニアがプロダクトを横断して機能開発を行いやすい環境を実現するために非常に重要な意味を持ちます。ここでは深堀りはしませんが、プロジェクト間でバージョンの管理をする際の手間が省けることで開発がしやすかったり、リリースを