はてなブックマーク

どんな問題を解決したのか こんにちは、ダイニーの 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 近くのプロダクト群から出来上がっているため、モノレポであることは一人のエンジニアがプロダクトを横断して機能開発を行いやすい環境を実現するために非常に重要な意味を持ちます。ここでは深堀りはしませんが、プロジェクト間でバージョンの管理をする際の手間が省けることで開発がしやすかったり、リリースを