はてなブックマーク

プロセス外部への副作用がないコードならテストは難しくありませんが、ファイルの読み書き、ネットワーク、データベースを使いだすと気にしなければならないことが増えます。今回はファイルの読み書きを扱うテストを書こうとしていろいろ調べたりしたことをまとめます。 単体のファイルの読み書きであれば、io.Readerやio.Writerを引数にすれば解決することも多いですが、複数のファイルがフォルダに格納されており、それを一括で読み書きするようなケースを想定しています。 fs.FSGo 1.16で追加されたのがfs.FSインタフェースです。ファイルシステムを抽象化するインタフェースです。go embedでプログラムに埋め込んだファイル群をアクセスしたり、os.DirFS()で実フォルダのfs.FSインタフェースを取り出したりできます。テスト時はすでに実行ファイルに組み込まれたデータをファイルとして読み込

はじめにJDK 23のリリースを受けてバージョン21~23にかけての変更点を紹介する連載企画の3本目の記事です。 2024 年 9 月 17 日（米国時間 ⁠）に「JDK 23」が リリース されました。 本記事では JDK 23 でのアップデート内容から（Preview や Incubator の変更点を除き）正式に採用となったアップデートについて紹介します。 JEPsJDK 23 で対応された主要な 12 の JEP（Java Enhancement Proposals）は次の通りです。 Oracle の プレスリリース をベースにカテゴライズしています。 カテゴリJEPタイトル言語機能JEP 455Primitive Types in Patterns, instanceof, and switch (Preview)言語機能JEP 476Module Import Declarat

はじめに2024年9月18日に発売された、Software Design 2024年10月号の第1特集「再考 設計ドキュメントの課題　二重管理しない，陳腐化させない」の「第1章：受託開発における設計ドキュメントの課題と解決案　作成・管理のヒントを探る」に寄稿させていただきました。 Software Design とは技術評論社が出版している月刊の技術情報誌です。Webサービスを開発するソフトウェア業界のエンジニアにとっては説明不要と言っていいくらい鉄板です。 毎月様々なテーマについて特集を組んで取り扱っており、プログラミングだけでなく、OSやネットワークまで、その内容は多岐に渡ります。入門者・初心者向けの内容から実践的な内容も多く含まれているので、新人からベテランまであらゆるエンジニアにおすすめできる雑誌です。 定期購読をして、業界の最新情報をアップデートするのもおすすめです！ 10月号の

Web開発者を支える重要なツールにcurlがあります。素晴らしいツールなのですが、ウェブAPIのリクエストがJSONという時代にあって、JSON書くのが面倒とかいろいろあるのですが、そのためだけに他のツールを使うのではなく、もうちょっと世の中がcurlでテストしやすいようになったらいいのでは、と思っていました。 curlはJSONがめんどいというか、世の中のWebサービスのcurlへの敬意が足りない https://t.co/tIWDToedIg — 渋川よしき (@shibu_jp) September 22, 2024 ということで書いてみました。 curlに合わせるためのミドルウェアというわけで実装しました。環境変数がなければ何もしません。 package glorytocurl import ( "bytes" "encoding/json" "io" "net/http" "ne

はじめにこんにちは、TIG所属の大江です。 性能テストを実施する際、テスト用の大量データを投入する場合があります。本番相当のデータを入れるために、数千万ないしは数億のデータが必要になる場合もあり、データ生成には一工夫を要です。 本記事では、大量データをDynamoDB／OpenSearch Serviceに投入した際、直面した壁と対応を紹介します。 投入方針様々な方法を調査した結果、以下の方法で投入するのが、効率が良いという結論に至りました。 DynamoDB: S3インポート機能OpenSearch: Bulk APIこれらの方法で投入するには、入力データをJSONファイル形式である必要があります。 また、対象システムでは数種のユニークIDを各項目に割り振る必要がありました。 そこで、Goのtext/templateパッケージを使いることにしました。 以下、生成スクリプトでデータ生成した

はじめに2024年8月17日に発売された、Software Design 2024年9月号の第二特集である、「Goのエラーハンドリングと向き合う ベストな設計戦略を徹底解剖」 の2章を後藤、3章を渋川で執筆し寄稿させていただきました。 このような貴重な機会をいただいた栗木さんをはじめ技術評論社の方々には、心からお礼申し上げます。 みどころGo言語初心者から熟練者まで楽しんでいただける内容になっていると思います。 Go言語を利用する上でエラーハンドリングは必須の知識になるので、ぜひご一読ください。Goに馴染みのない方でもGo特有のエラー処理の方法を知ることで、普段触れている言語の理解を深めることができると思います。他言語と比較した、Go言語のエラーの特徴もみどころの一つです。 【第2特集】Goのエラーハンドリングと向き合う 第1章　Goのエラー処理を理解する／mattnさん 第2章　失敗しな

夏の自由研究連載2024の1日目です。 生成AIが人気です。生成AIに対しては自然言語で指示を与えられますが、自然言語を構造化してやりとりする方法としてはよくMarkdownが使われます。その生成AIフレンドリーなMarkdownで設計ドキュメントを作るとしても、要約をしたりといった生成AIが得意なタスクではなく、コード生成だったり、構成チェックをする場合は生成AIではなく再現性の高い従来方式のツールを併用するといったことが今後行われそうな気がするので、ルール（テンプレート）に従ったMarkdownのパース処理の実装方法をいろいろ試した結果、パーサーコンビネーターが良いかなということで試してみた記録になります。 構文解析の実装方法何かしらのルールに従ったドキュメントやソースコードなどのテキストをパースするにはパーサーを使います。パーサーを作る場合は、LR法などの構文解析のパーサーなど作った

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

Future Tech Blog恒例のGoリリース連載が始まります。本エントリーはインデックス記事＆timeパッケージを散り上げます。 DateTitleAuthor7/16インデックス & time澁川7/17archive/tar真野隼記7/18range over funcとiterパッケージ棚井龍之介7/19unique, slices, maps武田大輝7/22text/template辻大志郎7/23os.CopyFS & path/filepath市川燿7/24keep-alive,Cookie大江聖太郎7/25Go Telemetry棚井龍之介1.23の更新内容の概要Go 1.23のアップデートとしては以下のようなものがあります。多いので、Win/mac/LinuxのAMD/ARM関連以外は省略しています。リリースノートはこちらです。RC1の時点で書いているため、まだギリギ

はじめにこんにちは。CSIG 所属の棚井です。 Go 1.23 Release Notes の内容を紹介する「フューチャー技術ブログ Go 1.23 リリース連載」の記事です。 今回は2つの反復（Iterator、イテレーション）処理を取り上げます。 range over funciter パッケージRelease Note, Discussion, Proposal, Issuerange over func と iter パッケージ のリリース内容を確認していきます。 range over func がデフォルトで有効にGo1.22 では GOEXPERIMENT とされた range over func が、Go1.23 からはオプション指定なしで利用可能となりました。 Go 1.23 makes the (Go 1.22) “range-over-func” experiment

はじめに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で

ちょっとしたウェブアクセスクライアントのコードを書いていて、サーバー側に正しくリクエストが送られているかの確認をする場合、モックサーバーを建てることが多いと思います。ウェブフロントエンド開発とかだとMock Service Workerが便利ですし、Playwrightのネットワークフック機能も便利です。GETだけならPythonでいつもやってしまうのですが、今回はPowerShellで作ったちょっとした自動化ツールかつエラーレスポンスを返したい、という状況だったので、Goあたりで適当なサーバーでも書くかな、と思っていたところ、ふと思い立ってぐぐってみたところでMockoonという良さげなツールを見つけて、使ってみたら便利だったので紹介します。 Mockoonとは僕は知らなかったのですが、2017年ごろからあるモックを作成するツールのようです。 GUIが提供されており、APIの定義やログ閲

本記事は「珠玉のアドベントカレンダー記事をリバイバル公開します」企画のために、以前Qiitaに投稿した記事を7年ぶりに改訂したものです。 筆者自身もコミッターとして関わるJavaのDB永続化ライブラリ「uroboroSQL」の紹介です。 https://github.com/future-architect/uroborosql はじめにエンタープライズシステム開発では、まだまだJavaで作られていることが多く、システム特性上、やはりRDBを利用するケースが多いですよね。 Amazon AuroraやCloud Spannerといったプロダクトに注目が集まるのも、時代の変化とともにDBも並列分散型でスケールアウトはしたいけれども、トランザクションもSQLも使いたいというCAP定理を覆す特徴を持っていることが要因だと思います。 2016/12/24にクリスマス・イブにCockroachDBに

はじめに現代の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

先日（2024年6月19日）、技術評論社さまから「［入門］Webフロントエンド E2E テスト ──PlaywrightによるWebアプリの自動テストから良いテストの書き方まで」をフューチャーの有志と共に出版いたしました。 本書はエンジニア選書と言われるシリーズの1つとなります。 既にご購入いただいた方、誠にありがとうございます。 購入を検討されている方、詳しくはこちらをご覧ください。 https://gihyo.jp/book/2024/978-4-297-14220-9 書籍の概要E2Eテストをこれから導入しようとしている方を主な対象とし、必要なノウハウを詰め込んだ書籍となっています。本書では、E2Eテストを学ぶ際の実装手段（ツール）として、近年人気が急上昇しているPlaywrightを中心に据えました。 章の構成は次のようになっています。 第1章 Playwrightハンズオン第2章

本記事は「珠玉のアドベントカレンダー記事をリバイバル公開します」企画のために、以前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に投稿した記事を一部ブラッシュアップしたものになります。 はじめに本記事は フューチャー Advent Calendar 2018 の13日目の記事として書かれました。私は弊社に入ってから競技プログラミングなるものを知り、実際に初めてみて約1年が経ちました。競プロって何？ 競プロって聞いたことはあるけれどなんだかよくわからない…という方に、競技プログラミングの面白みを少しでも伝えられたらと思い、記事を書きました。 競技プログラミングって何？決められた条件のもとで与えられた問題、課題をプログラミングを用いて解決し、その過程や結果を競うものを競技プログラミングといいます1。 コンテストの種類競技プログラミングといっても様々な分野のコンテストが開催されており、大きく以下の5つの分類のコンテストがあります。

本記事は「珠玉のアドベントカレンダー記事をリバイバル公開します」企画のために、以前Qiitaに投稿した記事をブラッシュアップし、フューチャー技術ブログに転載したものになります。Qiita側の元記事もアップデートしています。 はじめにpackage.json の dependencies をメンテナンスするにはどこから手を付ければいいか、を解説します。 Node.js を使っている人にはおなじみ package.json。 package.json の中で一番よく更新されるのが dependencies（個人の感想、次点で scripts）。 そして、依存パッケージが着々とバージョンアップしていくにも関わらず放置されてしまって後々問題になりがちなのも dependencies 。 「npm install で追加したっきり。パッケージのアップデートなんて考えたことなかった」という人や「Git

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

この記事はQiitaのアドベントカレンダー記事のリバイバル公開です。 ※ 当時の記事から、一部表現を見直し加筆しています。 はじめに先日ガートナーのレポートで「多くの企業において、特定のクラウドベンダーにシステムを集中させるリスクの重要度が上昇している」との発表がありました。 https://www.gartner.com/en/newsroom/press-releases/2023-10-30-gartner-says-cloud-concentration-now-a-significant-emerging-risk-for-many-organizations 日本においてクラウドの活用はますます進んでいる一方で、特定の Cloud Service Provider（CSP）にロックインされるリスクについては、常に議論の余地があると考えています。 本記事では、特定のクラウドに強く

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

先ほど計算した同様のケースをAmazon S3で計算してみると以下のようになります。約2倍ほど高いようです。 100GB * 15/30 month + 1GB * 15/30 month = 50.5 GB-month (50.5GB-month - 5GB 無料枠) * 0.025 USD = 1.1375 USD NextCloudとはオープンソースで開発されているNextCloudというセルフホスト型のストレージソフトウェアを利用し、自分専用のクラウドストレージを作成します。 https://nextcloud.com/ かつてownCloudというソフトウェアからフォークされたもので、ownCloudと比べるとチャットやビデオ会議機能が追加されているようです。 NextCloudでは基本的にNextCloudがインストールされたマシンのストレージをデータの保存場所としますが、「E

Swaggerを使う事になり OpenAPIを触ってみると 3.0.3 と 3.1.0 が存在します。どちらを使うべきが悩んだので調べて整理してみました。 3.0.3 から 3.1.0 への変更点は過去のポストを参照ください。 参考: Open API Specification 3.1と気になる仕様策定 結論Amazon API Gateway を使い、OpenAPIで定義されたAPI仕様書のインポート機能 を利用する場合は 3.0系（ 3.0.3）一択です。理由は単純に執筆時点では Amazon API Gateway が 3.1系 に対応してないからです。 また、VSCodeの拡張機能の中には 3.0.3 に対応しているものの 3.1.0 には未対応のものも多いようです（決して 3.1.0 で書けないわけではないありません） https://github.com/42Crunch/v

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というのはネットワー