最近はお客さんとの勉強会でDockerのドキュメントをつまみ食いして読むというのをやっていますが、改めて最新版を読んでみて、いろいろ思考が整理されました。2020年の20.10のマルチステージビルドの導入で大きく変わったのですが、それ以前の資料もweb上には多数あり「マルチステージビルドがよくわからない」という人も見かけるので過去の情報のアンラーニングに使っていただけるように改めて整理していきます。 仕事でPythonコンテナをデプロイする人向けのDockerfile (1): オールマイティ編で触れた内容もありますが改めてそちらに含む内容も含めて書き直しています。 本エントリーの執筆には@tk0miya氏から多大なフィードバックをいただきました。ありがとうございます。 基本的なメンタルモデル現代的な使い方を見ていくために「Dockerを使ってビルドする」というのはどのようなものか考えを整

はじめにTIG真野です。 バックエンドのアプリケーションの上で、メール送信するコードがある場合の単体テストをどう実現するか悩みました。 メールには、タイトル・本文・From・TO・CC・BCCなど複数の設定値がありますし、SMTPサーバの接続情報もあります。これらを表現する構造体のモデルだけに絞った検証に留めることは、気が進みませんでした。時代はインフラレベルでダミーサーバを動かしモックする方向で動いています。SMTPでメール送信し、その送信結果をテストコード上で取得＆検証する一連の流れを行って動作を確かめたいと思いました。 方法として、澁川さんのMailSlurperを使って6桁のコードの送信コードのテストをするで紹介されたMailSlurperを使うか迷いましたが、以下の点で牛刀だなと感じました。 メール送信するのはごく一部の機能（私の場合は1機能。今後増える見込みは現時点で見えなかっ

はじめにTIG真野です。 AWS SDK for Go を使ったコードをクラウドサービスに依存無しでローカルにてテストするとき、次のような手法が考えられます。 外部アクセス部分をインターフェースにしてテスト時はモックコードに差し替えよく見る手法だが、テスト目的のみでインターフェースを作る手間があるSDKのmiddlewareを使用詳細はAWS SDK for Go V2でinterfaceのモック”無し”でテスト - 365歩のテックを参考くださいインターフェースの作成を抑えられるメリットがあるLocalStackなどのモックサービスを利用別プロセス（いわゆる、テストサイズはMedium）になるため。実行時間は1,2より増える。実環境に近い環境でテストできるため品質を上げやすい利点があるhttptest.NewServer() でモックするフューチャーで実績が多いのはLocalStackで

はじめに現代のWebアプリケーションにおいて、ユーザが写真や動画などのファイルをアップロードする機能は、しばしば求められます。 本記事では、ファイルアップロードを実現するための一手段として、「署名付きURL」を利用した方式を取り上げ、その設計について詳しく解説します。 今回は、Amazon Web Services（AWS）を利用する前提のもと、このアプローチを探求していきます。 前半部分は署名付きURLをそもそもよく知らない方向けの導入部となっていますので、要点だけ抑えたい方は設計上のポイントから読まれることをお勧めします。 ファイルアップロードの実現方式パターン署名付きURLの話をする前に、ファイルアップロード機能をWeb APIとして実現する方式について、いくつか代表的なものを紹介します。 Pattern 1. multipart/form-datamultipart/form-da

はじめにフューチャーの有志メンバーでOpenAPI Specification（OAS） v3.0.3に対応したコーディング規約を作成しました。 https://future-architect.github.io/coding-standards/documents/forOpenAPISpecification/OpenAPI_Specification_3.0.3.html 2023年7月にv2.0の規約を公開してから約1年ぶりのアップデートとなります。 フューチャーの現場でもv3系の利用が主流となる中、有識者のナレッジを集める形で標準化を行っています。 まだ荒削りな部分は多々ありますが、早期に公開してフィードバックを得ながらブラッシュアップしていく方針のもと、公開に踏み切りました。 内容へのフィードバックは、GitHub Issueを起票いただくか、Xアカウント（@future_t

本記事は「珠玉のアドベントカレンダー記事をリバイバル公開します」企画のために、以前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としてい

本記事は「珠玉のアドベントカレンダー記事をリバイバル公開します」企画のために、以前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

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

はじめにHealthCare Innovation Group(HIG)1の橋本です。 先週末注文していたAirPods Pro第2世代が今日手元に届きました! 約4年間使っていたAirPods Pro第1世代の調子が悪くなってしまったため、買い換えました。 せっかく新しいAirPods Proが届いたので、なにかできることないかな〜と思いながら、AirPods Proの機能一覧を見ていました。 私はその中の1つ、空間オーディオ機能でヘッドトラッキングしていることに目をつけ、頭の角度の取得をしてみました。 環境 OS: macOS Sonoma 14.5 Xcode: 15.4 (15F31d) Swift: 5.10 AirPods Pro(第2世代) ※ 空間オーディオ機能搭載端末 AirPods(第３世代)、AirPods Pro(全世代)、AirPods Max (参考URL: A

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

Reactでのダイアログの開閉制御については以前、別のエントリーで書きました。 ダイアログもアラートも、Reactで子コンポーネントの開閉管理を実装する Vue3でも、何か簡単に書ける方法はないかと試行錯誤して、ちょっといい感じかな？ という方針を見つけたので、備忘がてら技術ブログに書いておきます。 使いやすいダイアログAPIとは太古の昔より、便利なダイアログ機能というのは、呼び出し元はダイアログの開閉状態とか細かい制御は気にせず、必要な情報を渡して、結果だけもらうというものです。JavaScriptのブラウザのAPIにもありますよね。 const result = confirm("今日はいい天気でしたね") // OKのときはtrue console.log(result) これはVisual Basicとかでもなんでも同じですね。ただし、JavaScriptだとconfirm()、a

いろんなJavaScriptの統計を見ると、今時のウェブフロントエンドの新規開発は80％はTypeScriptになっているということです。また、TypeScript自身を使わなくても、TypeScriptで培われた型推論のパワーで、JavaScriptであってもVSCode上で補完とか思いの外うまくいったりしちゃうので、TypeScriptフレンドリーというのはますます重要になっています。 ですが、TypeScriptが有効なのはコンパイル前とか実装中であり、実行時に流れてくるJSONが果たしてきちんとした型通りの定義なのかはTypeScriptの範疇外です。そこでZodとかのバリデーションを行ってくれるライブラリが使われます。Zodを使えばJSONが規定通りの構造をしているか確認した上で、TypeScriptの型を持った変数に安全に代入してくれます。 ですが、JSONというのはネットワー

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

技育祭2024春で「2064年もITで仕事し続けるためのキャリアプラン」というタイトルで発表してきました。 技育祭はサポーターズが実施している未来の「技」術者を「育」てる活動としている学生向けの「技育プロジェクト」の一大イベントです。僕自身も何度かかかわっているイベントで、先日開催された2024年3月17日に開催された「技育祭2024春」で登壇してきました。発表資料はこちらになります。 タイトルの2064年というのは、技育祭で一番ボリュームゾーンだと思われる20歳ぐらいの学部2年、3年の若者が60歳定年まで働くとしたら、という年ですね。AIでIT技術者がいらなくなる、みたいな話がよくされていますが、AI以前に優秀すぎる若者が周りにいっぱい増えてきて、ずっと前から危機感を感じていた40代のおっさんのキャリアプランをテーマに今回は講演を行いました。 私は今後AIの革新的発展によってプログラマー

リポジトリの取得、テスト実行それではさっそく、Terraform のソースコードを取得していきます。 といっても、ここでは hashicorp/terraform リポジトリをクローンするだけです。 クローンに成功したら、まずはテストに通過するかを確認します。 テスト実行ログ $ cd terraform/ $ go test ./... ? github.com/hashicorp/terraform/internal/backend [no test files] ok github.com/hashicorp/terraform 0.065s ok github.com/hashicorp/terraform/internal/addrs 0.030s ok github.com/hashicorp/terraform/internal/backend/backendbase 0.0

はじめにもともとはMicrosof Visioなどを使って作成していた図形（ネットワーク図、各種シーケンス、ERD..etc）ですが、ファイルストレージがクラウド（Google Drive）に移ることで、 そのまま編集したい 欲求が世の中で増しているように思います。 その場合の有効なツールとしてdraw.ioを利用するケースが増えてきたと感じます。そこで当社で蓄積したナレッジを文章化します。 Draw.io Tips1.ショートカット1.1. 公式ショートカットまずはここから始めましょう。 ショートカットはプロダクトの基本操作が詰まっています。 https://about.draw.io/wp-content/uploads/2016/11/draw.io_shortcuts_basic_win_EN.pdf 2. 設定2.1. 日本語化 画面右上の🌏マークから選択します メニューが開く

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

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

アーキテクチャの議論でよく出てくるのが、コンウェイの法則と、逆コンウェイ戦略です。これについては、うっかりIT用語をバズらせてしまう達人のマーチン・ファウラーのブログにも詳しい説明があります。角さん、いつも翻訳ありがとうございます。 「逆コンウェイの法則」が持ち出された議論が苦手なんどけど、なんでなのかな。コンウェイの法則はよく理解できるんだがー。 — Kazunori Otani (@katzchang) February 28, 2023 この@katzchangさんのツイートもそうですが、逆コンウェイ戦略に関しては僕も少しモヤモヤするところが個人的にあり、そのあたりを周りの人（@katzchangさんや@tokoroten、@__garsue__氏）と議論したらいろいろ自分が思っていなかった知見も得られたりしたので、まとめてみます。 コミュニケーションがかえって増える問題コンウェイの