本記事は「珠玉のアドベントカレンダー記事をリバイバル公開します」企画のために、以前Qiitaに投稿した記事を改訂したものです。 はじめにPub/Sub型のメッセージングアーキテクチャを採用するにあたっては、kafkaなどのブローカーミドルウェアや、Amazon SNS、Google Cloud Pub/Subなどのマネージドサービスを利用するケースが多いかと思います。ところでPostgreSQLでも実はPub/Subができます。 すでに業務でPostgreSQLを使っていれば、新たにPub/Subブローカーを構築しなくても、疎結合なシステム間通信を簡易的に実現できます。 本記事ではこの機能の紹介と、Pub/SubクライアントをJavaで実装する場合の選択肢、考慮点を示しています。 ※実行環境はPostgreSQL 16.2とJava 21です ※データベースの文字コードはUTF-8としてい

Gitのブランチ戦略にはいくつかあります。 GitフローGitHubフローGitLabフローチームの戦略を考えるときにどれかを参考にしつつカスタマイズするときにいろいろ不都合が生じてしてきて複雑になってしまうことってありますよね？社内でブランチの管理の議論をする中で、ブランチの役割を明確にした上で、どのブランチがどのような役割を持っているのかを明確にした方が混乱が少なくなるのではないか？というのを考えていました。 特に、プロジェクトごとに同じ名前でも役割が違うなー、というのとかもあり、ブランチ名＝役割ではなく、ブランチの上位概念として役割を考えて、それを実際のブランチとの対応づけを行う必要があるのではないかな、と。 CI/CDと組み合わされることで、releaseブランチ==ステージング環境となってしまい、ステージング環境を使いたいリリース前のブランチと、ホットフィックスの検証のブランチの

本記事は「珠玉のアドベントカレンダー記事をリバイバル公開します」企画のために、以前Qiitaに投稿した記事を一部ブラッシュアップしたものになります。 はじめにみなさん、docker composeを利用しているでしょうか？ 複数のdockerコンテナをまとめて立ち上げたり、環境変数を定義できたり便利ですよね。 この記事ではある程度docker composeを利用している方向けに私が便利、便利そうと感じたdocker composeの機能を挙げてみました。 docker compose cli v2を利用docker-composeではなく docker composeコマンドも利用可能になっています。 Docker Desktopでは v3.4.0から利用可能で、基本的にはコマンドの互換性あります。 ファイル監視による自動更新docker compose 2.20.0からCompose

https://www.oreilly.co.jp/books/9784814400669/ ひとえに読者の皆さんが買ってくれたおかげで、Real World HTTPを改訂し、このたび3版を上梓しました。ありがとうございます。2016年ごろから書き始めて、2017年に初版を出版したので、執筆段階からすると8年ほど経過しているのですが、これだけ長くこの本に関わり続けられるというのは、本書を買ってくださるみなさまのおかげです。 今回は、ひさびさに無料のミニ版も更新しました。本日、このブログと同時にリリースしました。よりミニ版が学習コンテンツとして使いやすくなるように、そもそもブラウザってどんな動きをするの？というイントロの章をミニ版とオリジナル版に追加しました。 また、オリジナル版だけになりますが、HTTPが単なるブラウザとの通信を超えてプラットフォーム API化していっている流れに合わせて

春の入門祭り2024の1記事目です。 はじめにTIG真野です。 Testcontainers を用いて、単体テスト実行前に docker compose up -d 無しで、PostgreSQLにアクセスする単体テストを行う、入門記事です。 恩恵は次のような開発者体感の向上が個人的にあります。 テストを実行するうえで、別プロセスのサービスを起動しておく必要があるといった前提条件を考えなくても済むため、テストを行うビジネスロジックに集中できるdocker compose up -d 打たないだけだが、テストに必要なコンテナを考慮しなくても済む停止し忘れて、別のリポジトリの開発するときに混乱しなくても済む並列テストしやすくなるので、テストの実行速度が向上するGoにおいて、複数のパッケージを同時にテストするとき、 -p 1 で絞らずに済むTestcontainers とはhttps://test

はじめにGo1.22リリース連載 の5本目です。 本記事ではGoの標準ライブラリである net/http の ServeMux におけるルーティング周りの強化について取り上げます。 関連する Release Note と Issue はこちらを参照してください。 https://tip.golang.org/doc/go1.22#enhanced_routing_patterns https://github.com/golang/go/issues/61410 変更点HTTPメソッドの指定が可能にServeMux.Handle や ServeMux.HandleFunc を使用してハンドラを登録する際に GET /xxx のようにHTTPメソッド指定して、ハンドラを呼び分けることができるようになりました。 mux := http.NewServeMux() // GETを指定したハンドラ

僕自身は龍が如くシリーズは、クロヒョウ2、極1、極2、０、3、4、5、6、0とやって、7はRPGだし主人公違うしなぁと思って、買うだけ買って後でやろうと積んでいたところ、CEDECのすごいテストの話を聞いて、（オリジナル版を積んでいたのに)インターナショナル版を買って始めてしまうぐらいインパクトがあり（そして積んでたのを後悔したぐらいよかった）ました。それ以降、維新極、7外伝、8は発売日に買ってプレイしてます。 こちらにその講演の詳細なレポートがこちらにあります。 https://www.famitsu.com/news/202009/11205564.html その8の発売前に龍が如くスタジオの技術責任者の方がXのアカウントを開設して、C++のコードを投稿されていたのですが、それに対してエンプラ開発目線で意見しているようなツイートを見かけて、「いや、システムの特性全然違うから」と思い筆を

Playwrightあるいはそのロケーターの元ネタとなっているTesting Libraryでは、DOMを指定する方法として data-testid 属性を扱ったクエリーを提供しています。どちらでも getByTestId(ID文字列) メソッドを使い、この属性値を使った要素の取得が行えます。しかし、ドキュメントを見ると、PlaywrightもTesting Libraryも、「他の手法が使えないときの最終手段」としています。 In the spirit of the guiding principles, it is recommended to use this only after the other queries don’t work for your use case. Using data-testid attributes do not resemble how your

秋のブログ週間2023、3週目・13本目です。 Python Distilledという本がオライリーから出版されました。作者のDave Beazleyはかなり昔からPythonを使い込んでいる人ですので、この本には信頼しかない、と思い読んでみました。Daveは大学の教授をしていて、コンピュータサイエンスで表彰もされている筋金入りです。本家PyConでも何度も発表されているようです。Python歴は27年でOSSとしてはC/C++をラップして他の言語で使えるようにコードを生成するSWIGはすでに20年以上の歴史がありますし、パーサージェネレータのPLYとSLY。curioというコルーチンのライブラリなどを作っています。僕は以前、SWIGのドキュメント翻訳をしてCマガジンに特集記事を書かせていただいたこともあり、僕の大学時代の顔写真がSWIGのウェブサイトに公開されていたりします。 そういう世

はじめにTIG真野です。育休明けです。 フューチャー社内のタスクランナーはmakeやTaskなど複数の流派があり、チームによって使い分けられています。個人的にはmakeで良いんじゃないかと思っていますが、Taskも良いですよね。 makeは細かい記法をいつも忘れる＋調べるとC言語向けの情報が出てきて脳内変換に手間を感じたため、makeを用いてWebバックエンドアプリをGoで開発するということをテーマに、役立ちそうな情報をまとめます。 なお、今記事におけるmakeは、GNU Makeを指します。バージョンは以下で動かしています。 MakefileのためのEditorConfigMakefileのインデントはハードタブである必要があります。誤りを防ぐためにもEditorConfigを設定しておくと良いでしょう。 makeは通常、Makefileという名称をデフォルトで認識しますが、同一フォルダ

秋のブログ週間2023の1日目です。 はじめに※この記事やこの本を読んだからと言って自身で診断を行わず、まずは整形外科などの医療機関にて診断を受けて、医師の方と治療方針を決定しましょう。また既に治療中の方は、取り組む前に一度医師や理学療法士の方と相談しましょう。 腰が痛くて仕事にならない、プログラマーこそが天職なのにこの痛みと一生付き合っていかないといけないのか…と思っている方は結構多いのではないでしょうか？ かく言う自分も腰痛持ちで、20代前半で椎間板ヘルニアと診断されました。当時はヘルニアが神経を圧迫し歩くのもつらい時期もありましたが、通院によってなんとか回復しました。 しかし完全にはよくならず、残りの人生全てを腰を気にしながら生きないといけないのか、、、と絶望しておりました。 そんなこんなで腰痛人生を送ってきたわけですが、ケリー・スターレット式　「座りすぎ」ケア完全マニュアルは自分の

はじめにTIG真野です。 秋のブログ週間2023 の3本目は、設計ドキュメントをGit管理して腐らせないようにがんばってみた話をします。 前段として6年前、「我々はいかにシステム開発におけるドキュメント腐る問題と戦えば良いのか」という記事を書いたのですが、その後の試行錯誤はどこにも残していないことに気づきました。普段のフューチャー技術ブログですとちょっと引け目を感じるテーマですが、秋の夜長を楽しむため読み物成分を多めに書くというテーマのこのブログリレーにピッタリな気がするため、この機会をお借りします。 ドキュメントも色々な種別があるかと思いますが、この記事では設計ドキュメントを指すことにします。設計ドキュメントは開発メンバーが参照するもので、ステークホルダーへの説明資料に引用して使うことはあれど、主目的は異なるという前提です。Design Docの場合もありますし、システム構成図、ERD、

はじめにこんにちは、SAIG/MLOpsチームでアルバイトをしている板野・平野です。 今回は、昨今注目されている大規模言語モデル(LLM)の開発においてMLOpsチームがやるべきことを考えるため、まずはLLM開発の流れを調査・整理しました。 本記事はその内容を「LLM開発のフロー」という題目でまとめたものです。LLMを本番運用するときに考慮すべきこと、LLM開発・運用を支援するサービスやツール・LLMシステムの構成例などについては、「LLM開発でMLOpsチームがやるべきこと」と題して別記事でご紹介していますので、ぜひ併せてご覧ください。 ここでのLLM開発とは、「LLM自体の開発」および「LLMを活用したシステム開発」の両方を含みます。また、「LLM自体の開発」は学習フェーズ、「LLMを活用したシステム開発」は推論フェーズ、として記載しています。 本記事ではLLM開発における各フェーズの

おそらく一般的にSwaggerと呼ばれるのはSwagger 2.0で、これは2014に公開された規約です。Swagger 2.0はOpenAPI 2.0と同義で、OpenAPI 3.0.0には2017年に、3.0.3は2020年に公開されています。 なぜ作ったかフューチャーは常に数十の開発プロジェクトが動いており、それぞれの案件内でちょっとした開発規約が作られることもあれば、暗黙的に遵守されるルールもあります。プロジェクトの大小も様々で数名から数百人規模に及ぶこともあり、新卒採用もキャリア採用も活発なので、フレッシュなメンバーも多くジョインしてくれます。 キャッチアップをしやすいように暗黙知を減らし明文化する意味でも、一定ラインの品質を守るためのガイドラインを作る文化があります（大なり小なりどこでもそうだと思いますが）。個人的にも隣のプロジェクトが同じ技術スタックを採用しているのに、マイナ

Go 1.21は久々の新しいライブラリが大量追加だったり、既存のパッケージへの改良の多数行われたり、あたらしい組み込み巻数が追加されたりで記事などが書きやすいリリースです。残念ながら、フューチャーで一番Goを使っているプロジェクトが山場で今回はちょっと書き手が少ないのですが、今回もお付き合いいただけるとうれしいです。 1.21の更新内容のまとめダイジェスト 1.18の時に入るといって直前にキャンセルになった、ジェネリクスのためのパッケージslices/mapsの復活 新しい組み込み巻数のmin/max/clearの追加 言語仕様の強化 パッケージの初期化順序が仕様化 型推論ちょっぴり強力に 次期バージョンで入る予定のループ変数が共有されちゃうバグ対策が実験実装 ランタイムの性能改善(いつもの) 深いスタックオーバーフロー時のトレースが見やすく(最新100ではなく、最新50と一番外側の50表

すでに多くの方々にお手に取っていただいておりますが、オライリージャパンから「ソフトウェア設計のトレードオフと誤り」の翻訳をフューチャーのメンバーと一緒に出版いたしました。好評なようで、発売一カ月ほどで増刷も決定いたしました。みなさまご購入いただき、ありがとうございます。初版をお買い求めになられたい方は今すぐ書店にダッシュ！ トレードオフこそが設計である良い設計とか読みやすいコードみたいな話題はツイッターではバズりやすい話題です。 読みやすいコードの話題ではいろいろなレイヤーの話が出てくるのですが、因数分解すると、だいたいいくつかのカテゴリーに分かれるように思います。 命名規則とか書き方のルール 従うべきクラス構造、アーキテクチャ構成の導入 サービスの境界をどこに引くか、どのようなときに設計手法を選ぶか、どのアルゴリズムを選ぶか 名前や命名規則の統一とか書き方の統一とかは用語のリストを作って

最近読んだ書籍の中で非常に良質な内容でしたので紹介したいと思います。少しでも多くの方に興味を持ってもらえることを期待しています。 O’Reilly Japan はじめに私自身がデータ管理（データマネージメント）という観点でここ数年様々な検討を行ってきていますので前提としてその背景について簡単にまとめてみます。 かつてオンプレミスで運用を行っていた時は企業内のデータは完全に管理されていました。データウェアハウスを導入してデータの集約・加工は行われていましたが、専門チームがデータ仕様確認やデータ提供までもすべての責任を担っていました。品質は高いのですが利用者からの要望（新しいデータの提供、仕様の変更）の対応についてはスピード大きな制約がありました。また大規模なデータを扱うためには多大なコストが必要という制約もあります。 クラウド技術による「スモールスタートを可能とするインフラ」「大規模なデータ