タグ

bufferingsのブックマーク (3,394)

  • 技術広報は「広報」より「技術」が先にある - 941::blog

    今日は二十四節気では清明。万物が清々しく明るく美しいころ、わかりやすくいうとお花見シーズンです。 ※このブログでは二十四節気という約2週間ごとにやってくる暦にあわせて更新しています 「技術広報」の「技術」とは何か、考えたことがありますか? 技術広報と広報って何が違うの?と聞かれたら、多くの人は「技術寄りのコンテンツを扱う」と答えると思います。間違ってはいないんですが、それだと一般の広報が技術トピックを担当した瞬間に境界が消えてしまいますね。 わたしが技術広報という仕事を18年やってきて辿り着いた答えは、技術エンジニアへの解像度です。 広報は「届ける」仕事ですが、技術広報は「誰に何が刺さるか」を技術の文脈で判断できなければ成立しません。その判断の精度が、解像度です。解像度が高いから、エンジニアが「これは自分たちのことだ」と感じてもらえる発信ができる。解像度が低いまま手を動かせば、その発信は

    技術広報は「広報」より「技術」が先にある - 941::blog
    bufferings
    bufferings 2026/04/07
    だから、すごく安心感があるし動きやすいのだなぁ
  • 2025年に社内で話題になったフロントエンド技術トピックを振り返る - KAKEHASHI Tech Blog

    こんにちは。AI在庫管理のプロダクト開発をしているソフトウェアエンジニアの大村です。 記事では2025年にカケハシ社内で話題になったフロントエンド関連の技術トピックをピックアップしながら、昨年を振り返っていきます。 主要なライブラリ / フレームワークのアップデート React 19.2 (2025年10月) React19.2 React 19.2がリリースされ、ActivityコンポーネントやuseEffectEventフックなどの便利な機能が追加されました。 Activity Activityは、コンポーネントの表示・非表示をプロパティによって切り替えられる仕組みです。 これまで、コンポーネントを一時的に隠す場合は条件によってレンダリングを制御するか、CSSで隠すという選択肢がありました。 前者の場合はアンマウント時にstateが破棄されるため、再度表示するときに再計算やデータフェ

    2025年に社内で話題になったフロントエンド技術トピックを振り返る - KAKEHASHI Tech Blog
    bufferings
    bufferings 2026/03/05
    よき
  • 非同期設計ガイドラインを公開しました | フューチャー技術ブログ

    はじめにこんにちは。TIG(Technology Innovation Group)の亀井です。 フューチャー社内の有志メンバーで 非同期設計ガイドライン を作成し、公開しました! 記事では、ガイドライン策定の背景や、ガイドラインで取り上げている設計のポイントをピックアップしてご紹介します。 ガイドライン策定の背景かつて非同期処理といえば、専門的なメッセージングミドルウェアを必要とする、一部のミッションクリティカルなシステムで採用される特別な技術でした。フューチャーでも独自のミドルウェアフレームワークを構築して、大量データをリアルタイムで処理するような仕組みを数々の工夫を凝らして実装してきました。 一方で、昨今ではAWS SQSなどのクラウドネイティブなサービスの登場により、応答時間の長い処理のオフロードなどを目的に非同期処理を取り入れることは珍しくなくなりました。 しかし、非同期特有

    非同期設計ガイドラインを公開しました | フューチャー技術ブログ
    bufferings
    bufferings 2026/02/21
    めちゃいい。ちょうど考えをまとめなきゃと思ってたからめちゃ参考になる。
  • 「パフォーマンスチューニングのために普段からできること」〜なぜ突然システムが遅くなるのか?ISUCON優勝者が語る計測と推測のリアリティ 〜 - KAKEHASHI Tech Blog

    カケハシでの社内講演に、さくらインターネット株式会社の藤原俊一郎氏(@fujiwara)をお招きしました。「パフォーマンスチューニングのために普段からできること」というタイトルで、具体的な失敗談や現場の思考プロセス、そしてチューニングの質についてお話しいただきました。 社内向けの場ではありましたが、貴重なお話をお伺いできたため、ご人の許可を得て外部向けにまとめました。 当日は、前半を講演編、後半を対談編として構成し、対談パートにはカケハシのテックリードである松山も参加しました。 講演編:「パフォーマンスチューニングのために普段からできること」 なぜパフォーマンス問題は突然「死」を呼ぶのか グラフが改善したりISUCONで勝ったりする瞬間は「ものすごく楽しい」ものですが、一方で現在進行形でサービスが死んでいる状況は「めっちゃ楽しくない」ものです。長年育てたサービスが落ちることは、「自分の

    「パフォーマンスチューニングのために普段からできること」〜なぜ突然システムが遅くなるのか?ISUCON優勝者が語る計測と推測のリアリティ 〜 - KAKEHASHI Tech Blog
    bufferings
    bufferings 2026/01/17
    めちゃ勉強になるセッションでした!スライドの最後の「アーキテクチャで敗北している場合、チューニングで何とかするのは無理」って言葉とても好き。
  • Zod OpenAPI Honoで.openapi()を使わずにスキーマ定義を書きたい! - Mitsuyuki.Shiiba

    と思ってたらふつうにできた。 どういうこと? Honoでサーバーサイドアプリケーションを書くときに、ミドルウェアとしてZod OpenAPI Honoを使うと、ZodのスキーマからOpenAPIのスキーマが生成できて便利。 例えばこういうZodのスキーマを用意して import { z } from "@hono/zod-openapi"; export const CreateUserInput = z .object({ name: z.string().openapi({ example: "John Doe", }), age: z.number().openapi({ example: 42, }), }) .openapi({ description: "Create user input" }); export const CreateUserOutput = z .obje

    Zod OpenAPI Honoで.openapi()を使わずにスキーマ定義を書きたい! - Mitsuyuki.Shiiba
    bufferings
    bufferings 2026/01/12
    書いた。いろいろ遊びながら素振りをしてる感覚。
  • Kori(サーバーサイドTS用のウェブアプリケーションフレームワーク)の0.4.0をリリースした - Mitsuyuki.Shiiba

    Kori(氷)は、自分好みのものを作ってみようと思って開発したフレームワーク。コアとして入れたい機能はできたのでひとまず満足している。もうAPIに対する大きな変更は入れないつもり。ちなみに、ルーターにはHonoのルーターを使っている。 スキーマを中心としている Koriはスキーマを中心としている(と言っても外部化してるから要らないなら使わなくていい)。それと型。 スタンダードスキーマを指定して、バリデーションをかけられる。バリデーション済みのデータには型安全にアクセスできる。さらに、そのスキーマがそのままOpenAPIのスキーマになる(スタンダードJSONスキーマを使用している)。こういう感じ app.post("/todos", { pluginMeta: openApiMeta({ summary: "Create a new TODO", tags: ["todos"], }), r

    Kori(サーバーサイドTS用のウェブアプリケーションフレームワーク)の0.4.0をリリースした - Mitsuyuki.Shiiba
    bufferings
    bufferings 2025/12/30
    今年の活動として満足したー
  • 開発を任されたときには、助けてもらえるようにしている - Mitsuyuki.Shiiba

    こっちに雑記を書くのは久しぶりな気がする。年末だし家族で買い物でも行こうかってなって、娘たちがメイクを始めたので待っている間になんか書く、という感じ。 自分は、周りから見るとわりと変わった動き方をしているように見えるのかもしれない?と思うので、なんとなく書いてみる。 それは、助けてもらえるように意識して動いているところ。 聞く相手が自分 最近は光栄なことに、いろいろな仕事を任せてもらえるようになってきている。チームのリーダーをやったり、ひとつの案件をなんとかする人としてアサインされたりしている。 任されるようになってくると、誰かが見てくれている中で動いているときとは違って、自分が色々なものを見ながら判断していく必要がある。「これで進めていいですか?」と許可を求める相手が上司ではなくて、自分になる。 だから、これまで以上にしっかりしなきゃなと思う。任せてもらっている以上、自分の力でできる限り

    開発を任されたときには、助けてもらえるようにしている - Mitsuyuki.Shiiba
    bufferings
    bufferings 2025/12/28
    書いたー
  • モノレポ と「育つ仕様書」で実現する、LLM時代のマルチ言語システム構築 - KAKEHASHI Tech Blog

    こちらの記事は カケハシ Advent Calendar 2025 の 8日目の記事になります。 はじめに ソフトウェアエンジニアのkackyです。 「kintoneの契約データを、Databricks経由でAWS上のプロダクトに同期したい」 このような要件を受けたとき、どのような開発ステップが浮かぶでしょうか? kintoneのデータ構造を理解する プロダクト側のAPI仕様を把握し、TypeScriptで書かれたバックエンドと連携する。必要に応じて機能追加する 名寄せ処理のビジネスロジックをDatabricksで正確に実装し、検証する 人手でこれらすべてを横断的に把握し、整合性を保ちながら開発するのは大変です。しかし、生成AIの読解力が向上した今、「必要な情報をすべて一箇所に集約しておけば、AIがコンテキストを理解して適切なコードを生成してくれるのではないか」という仮説が立てられました。

    モノレポ と「育つ仕様書」で実現する、LLM時代のマルチ言語システム構築 - KAKEHASHI Tech Blog
    bufferings
    bufferings 2025/12/09
    むむー。おもしろかった
  • 生成AIフレンドリーなフロントエンド基盤をつくる - KAKEHASHI Tech Blog

    こちらの記事は カケハシ Advent Calendar 2025 の 5日目の記事になります。 こんにちは。生成AI研究開発チームでソフトウェアエンジニアをしているNokogiri(@nkgrnkgr)です。 はじめに 私たちのチームでは、新規プロジェクトを始めるにあたり、今後少ない人数で保守性の高いコードを高速に開発できることを目標にフロントエンド基盤を整えることにしました。その過程で、生成AIにコードを書いてもらいつつ、保守性の高いコードを書けるのかを探求しています。 CursorやClaude Codeなどの生成AIツールを使った開発が一般的になってきました。生成AIはコードを書く速度を大幅に向上させてくれます。 なお、カケハシでは生成AIサービスを利用する際は、SRE、DRE(Data Reliability Engineering)、情報システム、法務といったガバナンス担当者間

    生成AIフレンドリーなフロントエンド基盤をつくる - KAKEHASHI Tech Blog
    bufferings
    bufferings 2025/12/09
    おもしろかったー
  • Terraform × Claude Codeで属人化を解消:Datadogモニター設計を改善してわかりやすくする実践例 - KAKEHASHI Tech Blog

    はじめに こんにちは、PocketMusubiチームでエンジニアをしている南光です。 こちらの記事は カケハシ Advent Calendar 2025 の 9日目の記事になります。 さて、Datadogのモニター(アラート)設定、こんな経験はありませんか? 「閾値、とりあえず10件にしておくか...」 「この設定、なんでこの値なんだっけ?」 「レビューで指摘したいけど、自分も正解がわからない」 監視設定には明確な正解がありません。サービスの特性、運用体制、SLAによって適切な値は変わります。そのため、設定が属人化し、レビューも「なんとなくOK」になりがちです。 この問題を解決するために、2つのアプローチを組み合わせました。 Terraform管理 - モニター設定をコード化してレビュー可能にする Claude Codeとの対話 - 設定の根拠を言語化する 記事では、このアプローチを使っ

    Terraform × Claude Codeで属人化を解消:Datadogモニター設計を改善してわかりやすくする実践例 - KAKEHASHI Tech Blog
    bufferings
    bufferings 2025/12/09
    おもしろかった
  • VPoTとしての2025年。手を動かし続けていたい。 - KAKEHASHI Tech Blog

    こんにちは、椎葉です。カケハシでVPoT(VP of Technology)をやってます。今年は自分にとって、これまで以上に挑戦の多い年でした。年初には自分がVPoTになるなんて全く想像もしていませんでした。この記事では自分にとっての2025年をふりかえってみようと思います。 と、その前に カケハシのアドベントカレンダーはじまります! 2025年も残すところあと1ヶ月ですね!カケハシのアドベントカレンダーはじまります!エンジニア以外にもデザイナーやPdMなど、いろんなメンバーがエントリーしてくれているので、どんな記事が出てくるのか今から楽しみです。 最新情報は @kakehashi_dev で発信していきますので、ぜひフォローをよろしくお願いします! 現場と経営をつなぐ動き こちらは就任時に書いた記事です。 CTOである湯前の片腕として技術的な視点で全体を見つつ、現場で手を動かしてメンバー

    VPoTとしての2025年。手を動かし続けていたい。 - KAKEHASHI Tech Blog
    bufferings
    bufferings 2025/12/01
    かいたよん!
  • コーディングエージェントのカスタムコマンドでGit操作を効率化 - KAKEHASHI Tech Blog

    こんにちは、椎葉です。カケハシでVPoT(VP of Technology)をやっています。今日は、僕が使っているCursorのカスタムコマンドを2つ紹介します。 カケハシではコーディングエージェントとして、Cursor、Claude Code、GitHub Copilot、そしてDevinを利用できます。その中で僕はメインではCursorを使用しています。最近だと、Cursorを使ってTerraformによるAWSのインフラ構築をやっていて、便利だなーと思っています。 そんな日々の作業の中で、コミットとプルリクエストの作成をよく実施しているので、その2つをCursorのカスタムコマンドとして登録してみました。まだまだブラッシュアップ中ですが、わりと便利に利用できているので紹介します。 Cursorのコマンド Cursorの「コマンド」とは再利用可能なプロンプト定義です。チャットウィンドウ

    コーディングエージェントのカスタムコマンドでGit操作を効率化 - KAKEHASHI Tech Blog
    bufferings
    bufferings 2025/11/27
    かいたよー
  • なぜインフラコードのモジュール化は難しいのか - アプリケーションコードとの本質的な違いから考える

    A method for separating policy definition and behavior control by an intermediate language to achieve optimal server configuration management according to the situation

    なぜインフラコードのモジュール化は難しいのか - アプリケーションコードとの本質的な違いから考える
    bufferings
    bufferings 2025/11/14
    よかったー!
  • どのくらい生成AIに任せているかをあらわす指標 - Mitsuyuki.Shiiba

    fukabori.fmのtwadaさん回、面白いなー分かるなーって思いながら聞いて、今の自分の頭の中を書きだしてみようと思ったので書いておく。 どのくらい生成AIに任せているかをあらわす指標 どのくらい生成AIに任せているかをあらわす指標は、こうかなぁと僕は思っている。 「生成されたコードを自分が読んでいない割合」 どれだけたくさん生成AIにコードを書いてもらっていたとしても、生成されたコードを自分が全部読んで理解している場合は、主導権は自分にある。逆に、生成されたコードを全く読んでいなければ生成AIに主導権がある。 右のほうが生産性は上げやすい AIにどれだけたくさんコードを生成してもらったとしても、全部読んで理解しないといけないなら人間がボトルネックになる。右側にいけばいくほど、生成AIに任せられるので生産性は上げやすい。 ただ、右側にいけばいくほど自分がコードを理解していないし、構造

    どのくらい生成AIに任せているかをあらわす指標 - Mitsuyuki.Shiiba
    bufferings
    bufferings 2025/10/03
    かいたー
  • 不確実な新規事業開発に立ち向かう。生成AIによる高速プロトタイピングと「設計タイムライン」活用術 - KAKEHASHI Tech Blog

    こんにちは、患者向けサービス開発チームでエンジニアをしている種岡です。 カケハシでは社内で生成AIを活用した取り組みが活発に行われています。 生成AIは、もはや単なる効率化ツールではありません。ユーザーへ最速で価値を届けるための「強力な相棒」です。 記事では生成AIを活用し、仕様検討からプロトタイプ作成までを高速で実現した事例を、具体的な手順を交えてご紹介します。 新規事業開発における3つの課題 所属しているチームは新規事業開発ということもあり、以下の課題に直面することが多いです。 変わりやすい要件 : 日々の情報収集で仕様が固まらず、開発着手のタイミングを見極めるのが難しい 技術課題へのリスク : 実際に開発してみないと、どこに技術的な難所があるか分からない 不正確な見積もり : 前例がないため、工数の見積もりが大きくブレやすい 高い不確実性への対策としてのプロトタイプ開発 チームでは

    不確実な新規事業開発に立ち向かう。生成AIによる高速プロトタイピングと「設計タイムライン」活用術 - KAKEHASHI Tech Blog
    bufferings
    bufferings 2025/09/12
    たねさんの記事だ!よもー!と軽い気持ちで開いたら色々興味あったからあとでじっくり読んでみる。
  • 組織の一体感を育み、テキストだけでは伝わらない温度感を届ける。社内ポッドキャスト開始しました - KAKEHASHI Tech Blog

    こんにちは、技術広報の櫛井です。普段は@941というHNでインターネットで活動しています。 カケハシの開発組織で技術系の情報発信や登壇支援、イベントスポンサー窓口など技術に関わる各種企画を担当しています。最近はこのKAKEHASHI Tech Blogの更新をもっと盛り上げようと取り組んでおり、おかげさまで更新頻度をグイッとあげることが出来はじめました。今後も技術発信を活発にしていきたいと思っていますのでご期待ください。 さて今回は、社内向けにポッドキャスト番組を開始したので、なぜ・どうやって・どうなったかをご紹介しようと思います。 なぜポッドキャストなのか Googleが提供するNotebookLMが「音声解説」という機能を提供したことで、音声による情報共有がこれまでよりも活発になってきていると感じています。社内のLT会でも「では5分の音声を作ってきたので聞いてください」と、音声を皆で聞

    組織の一体感を育み、テキストだけでは伝わらない温度感を届ける。社内ポッドキャスト開始しました - KAKEHASHI Tech Blog
    bufferings
    bufferings 2025/08/29
    社内ポッドキャスト始めましたー。941さんが全部やってくれるので僕は「どんな話をしたいかなぁ」ってことだけ考えておいて当日楽しく喋るだけなのでとてもありがたいー楽しいー!!!
  • チームの問題の原因は外側にあることが多いよなぁ。「チームの力で組織を動かす」を読んだ。 - Mitsuyuki.Shiiba

    技術的負債をなんとか減らさなきゃ!」とがんばっているのに、なんかうまくいかないってケースをちょくちょく見る。忙しくて時間が取れないとか、少し改善を進めている間に別の機能追加によってまた負債を抱えてしまうとか。 僕はこの10年ぐらい、どうやったらもっとうまく開発できるかなぁって考えながら過ごしている。よりうまく開発をするためには、開発チームの内側を良くするのはもちろんだけど、それ以上に、開発チーム自体を組織の中でどのように設計するかがとても重要だよなと思っている。 8月25日に発売です! 最近もそんなことを考えながら過ごしていたところ @mtx2s さんから「チームの力で組織を動かす」をいただいた。明日(8/25)発売です!めちゃ面白かった。結構ボリュームがあるので、最初ザーッと読んで、次に、気になったところを中心に読み込んでいった。図がたくさんあって分かりやすいのも良かった! 組織やチー

    チームの問題の原因は外側にあることが多いよなぁ。「チームの力で組織を動かす」を読んだ。 - Mitsuyuki.Shiiba
    bufferings
    bufferings 2025/08/24
    おもしろかったー!
  • ちょっとした質問でいきいきしてきたデイリースクラム - KAKEHASHI Tech Blog

    こんにちは、椎葉です。カケハシでVPoT(VP of Technology)をやっています。技術的な視点で現場と経営をつなぐ活動の一つとして、実際にチームに入って開発業務をサポートしています。今日はその中のひとつの事例を紹介します。 Pocket Musubiチーム 今年の6月からPocket Musubiチームのみんなと一緒に開発業務に取り組んでいます。Pocket Musubiは、薬局と患者さんをつなぐ「服薬フォローシステム」です。Musubi電子薬歴と並んで、カケハシの中でも主要なプロダクトのひとつになっています。 チームはエンジニア5名、SRE2名、QAエンジニア3名をはじめとした10数名のメンバーで構成されており、少人数でさまざまな案件を進めています。そんなチームが少し悩んでいそうだったので、サポートへ入ることにしました。 「いいチームだなぁ」 最初の1スプリントは、デイリースク

    ちょっとした質問でいきいきしてきたデイリースクラム - KAKEHASHI Tech Blog
    bufferings
    bufferings 2025/08/07
    書いたー。今日もみんなに癒されてたー。
  • Kori (氷) というTypeScript用のウェブアプリケーションフレームワークをCursorたちと一緒に作ってみている - Mitsuyuki.Shiiba

    とりあえずコンセプトは動きそうだなぁってくらいで、ちゃんと動くことも確認してないし、テストも書いてないし、まだまだやることはたくさんあるんだけど、どっかでいったんブログに書いて休憩しようと思ったので、書くことにした。年内である程度動くところまで持っていけたらいいな。 Kori Kori (英語版を作ってその翻訳をCursorにお願いしたのでそういう感じの日語になってます) 特徴 TypeScriptの型安全さをわりといっぱい活かしてコードを書ける。 スキーマを定義すると、そのスキーマにしたがってバリデーションが実行されて、その結果を型安全に扱える。その同じスキーマをOpenAPIのスキーマとしても利用できる。スキーマの実装としては、とりあえずZod v4に対応しておいた。 たとえばこんな感じで定義すると const UserSchema = z.object({ name: z.stri

    Kori (氷) というTypeScript用のウェブアプリケーションフレームワークをCursorたちと一緒に作ってみている - Mitsuyuki.Shiiba
    bufferings
    bufferings 2025/08/04
    みているんだよー
  • 「早川書房 夏のKindle超ビッグセール」開催中! 3,000点以上が最大50%OFFなのでおすすめ本を紹介していくよ - ソレドコ

    「早川書房 夏のKindle超ビッグセール」が2025年7月14日(月)まで開催中です! 早川書房のSF、ミステリ、ノンフィクション、文芸など3,000点以上が最大50%OFFとなっています。 そこで今回は、ソレドコ編集部メンバーのイチオシ作品とともに、おすすめ早川書房のを紹介します。 セールの対象商品はこちら(Amazon検索結果) 👇️気になる作品をタップするとジャンプします ソレドコ編集部メンバーが最近読んだ「推し早川」 『ネット怪談の民俗学』 廣田 龍平 (著) 『ゼロからつくる科学文明 タイムトラベラーのためのサバイバルガイド』ライアン ノース (著), 吉田 三知世 (翻訳) フィクション(SF、ミステリ、文芸、ファンタジイなど) 『プロジェクト・へイル・メアリー』(上・下)アンディ・ウィアー(訳:小野田和子) 『アルジャーノンに花束を』 ダニエル キイス (著), 小尾

    「早川書房 夏のKindle超ビッグセール」開催中! 3,000点以上が最大50%OFFなのでおすすめ本を紹介していくよ - ソレドコ