2024年版のDockerfileの考え方＆書き方 | フューチャー技術ブログ
最近はお客さんとの勉強会でDockerのドキュメントをつまみ食いして読むというのをやっていますが、改めて最新版を読んでみて、いろいろ思考が整理されました。2020年の20.10のマルチステージビルドの導入で大きく変わったのですが、それ以前の資料もweb上には多数あり「マルチステージビルドがよくわからない」という人も見かけるので過去の情報のアンラーニングに使っていただけるように改めて整理していきます。 仕事でPythonコンテナをデプロイする人向けのDockerfile (1): オールマイティ編で触れた内容もありますが改めてそちらに含む内容も含めて書き直しています。 本エントリーの執筆には@tk0miya氏から多大なフィードバックをいただきました。ありがとうございます。 基本的なメンタルモデル現代的な使い方を見ていくために「Dockerを使ってビルドする」というのはどのようなものか考えを整
個人的docker composeおすすめtips 9選 | フューチャー技術ブログ
本記事は「珠玉のアドベントカレンダー記事をリバイバル公開します」企画のために、以前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
2024年Gitワークフロー再考 | フューチャー技術ブログ
春の入門祭り2024の2記事目です。 Gitは、出自としては1週間で作られたLinuxカーネルのための分散バージョン管理システムでした。当時のワークフローに合わせてパッチをテキスト化してメールに添付できるような機能だったりが備わっています。 一方で、現代のGitは、デファクトスタンダードなバージョン管理システムになりLinuxカーネル以外のアプリケーション開発で利用されています。分散バージョン管理ではあるものの、サーバー・クライアント型の使われ方をしていて、GitHubやGitLabを核にして、ローカルで作ったブランチをpushして、Pull Requestの形にして管理しています。少なくとも周りで見る限りでは、それ以外の使われ方の方が少なくなってきてます。そんなこんなで求められている使われ方が変わってきていて、それに合わせた機能がぼちぼち増えています。それを活用することで、ウェブ画面上で
実践Drawio | フューチャー技術ブログ
はじめにもともとは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. 日本語化 画面右上の🌏マークから選択します メニューが開く
設計ドキュメント腐る問題、Git管理で運用してみた結果 | フューチャー技術ブログ
はじめにTIG真野です。 秋のブログ週間2023 の3本目は、設計ドキュメントをGit管理して腐らせないようにがんばってみた話をします。 前段として6年前、「我々はいかにシステム開発におけるドキュメント腐る問題と戦えば良いのか」という記事を書いたのですが、その後の試行錯誤はどこにも残していないことに気づきました。普段のフューチャー技術ブログですとちょっと引け目を感じるテーマですが、秋の夜長を楽しむため読み物成分を多めに書くというテーマのこのブログリレーにピッタリな気がするため、この機会をお借りします。 ドキュメントも色々な種別があるかと思いますが、この記事では設計ドキュメントを指すことにします。設計ドキュメントは開発メンバーが参照するもので、ステークホルダーへの説明資料に引用して使うことはあれど、主目的は異なるという前提です。Design Docの場合もありますし、システム構成図、ERD、
Makefile覚書: Goアプリ開発に役立ちそうな基礎知識 | フューチャー技術ブログ
はじめにTIG真野です。育休明けです。 フューチャー社内のタスクランナーはmakeやTaskなど複数の流派があり、チームによって使い分けられています。個人的にはmakeで良いんじゃないかと思っていますが、Taskも良いですよね。 makeは細かい記法をいつも忘れる＋調べるとC言語向けの情報が出てきて脳内変換に手間を感じたため、makeを用いてWebバックエンドアプリをGoで開発するということをテーマに、役立ちそうな情報をまとめます。 なお、今記事におけるmakeは、GNU Makeを指します。バージョンは以下で動かしています。 MakefileのためのEditorConfigMakefileのインデントはハードタブである必要があります。誤りを防ぐためにもEditorConfigを設定しておくと良いでしょう。 makeは通常、Makefileという名称をデフォルトで認識しますが、同一フォルダ
CDN 入門とエッジでのアプリケーション実行 | フューチャー技術ブログ
のようなイメージです。 ※192.0.2.0/24、198.51.100.0/24、203.0.113.0/24 は例示に利用できる IP アドレスブロックです。 実在する IP アドレスではありません。 以上のように、CDN では オリジンサーバーのドメインと CDN 用ドメインの紐づけ CDN 用ドメインに対応する IP アドレスの動的な名前解決 を用いて、オリジンサーバーへのリクエストを地理的に近いエッジロケーションへのリクエストに振り替るのが一般的です。 CDN サービスの例ここでは、CDN サービスの例を各クラウドベンダーごとに簡単に紹介します。 AWS - Amazon CloudFrontAWS の提供する CDN サービスは Amazon CloudFront です。 Amazon CloudFront では、CDN のオリジンサーバーとして EC2 や S3、ELB など
markdownlintで設計書の品質を高める | フューチャー技術ブログ
はじめにフューチャー技術ブログのリレー形式の連載である、春の入門祭り2023の1日目です。TIG真野です。 ここ数年、Markdownで設計書をチームで書き、GitHub（GitLab）上でレビューするフローを採用しています。なるべくテキストベースで設計開発フローを統一するため、私の所属するチームでは以下のようなツールを採用しています。 シーケンス図、業務フロー図 Markdown中にPlantUMLで記載 参照はGitHub上からも見れるように、pegmatite を利用 システム構成図など画像系 Diagrams.net（draw.io）で作成し、.drawio.png の拡張子でMarkdownから参照 これだけは目視で差分チェックとなる Web API定義 OpenAPI SpecのYAMLファイル 参照はGitHub上からも見れるように、swagger-viewer を利用 ER
本当は怖い、逆コンウェイ戦略 | フューチャー技術ブログ
アーキテクチャの議論でよく出てくるのが、コンウェイの法則と、逆コンウェイ戦略です。これについては、うっかりIT用語をバズらせてしまう達人のマーチン・ファウラーのブログにも詳しい説明があります。角さん、いつも翻訳ありがとうございます。 「逆コンウェイの法則」が持ち出された議論が苦手なんどけど、なんでなのかな。コンウェイの法則はよく理解できるんだがー。 — Kazunori Otani (@katzchang) February 28, 2023 この@katzchangさんのツイートもそうですが、逆コンウェイ戦略に関しては僕も少しモヤモヤするところが個人的にあり、そのあたりを周りの人（@katzchangさんや@tokoroten、@__garsue__氏）と議論したらいろいろ自分が思っていなかった知見も得られたりしたので、まとめてみます。 コミュニケーションがかえって増える問題コンウェイの
単体テストの考え方/使い方 の感想文 | フューチャー技術ブログ
はじめにTIG EXU真野です。 積読を消化しようというテーマの、読書感想文連載 の1冊目は、単体テストの考え方/使い方 です。 書籍の基礎情報です 2022年12月28日発売 Unit Testing Principles, Practices, and Patterns の翻訳書。原著は2020年1月14日に発売 テーマ 質の高いテストを行い、ソフトウェアに価値をもたらそう！単体（unit）テストの原則・実践とそのパターン プロジェクトの持続可能な成長を実現するための戦略 単体テストの原則・実践とそのパターン コード例は C# であるものの、どの言語でも適用できる汎用的な内容とのこと 中を見ると、微妙にC#特有ぽいところに1箇所悩みましたが、それ以外はその通り 翻訳者の須田さんは、他にもセキュア・バイ・デザイン: 安全なソフトウェア設計 やOAuth徹底入門 セキュアな認可システムを適
業務システム開発でsqlcを導入して良かった点とハマった点 | フューチャー技術ブログ
はじめにTechnogoly Innovation Group 辻です。Go には Gorm や SQLBoiler をはじめとして様々な ORM があります。2021 年には当社のブログで OR マッパーの連載を行ったこともありました。絶対的な ORM があるわけではなく、業務システムの特性やチーム構成などに合わせて ORM を選択することになるでしょう。 今回、私たちのチームでは、バッチ処理が中心的な業務システム開発において Go の ORM に sqlc を採用しました。素の SQL を書いていくチームの開発方針1とマッチし、開発体験は非常に良かったです。一方、枯れきってはいない ORM ではあります。いくつか想定外の挙動が発生し GitHub の Issue を見ながら問題を切り分けることもありました。 これから sqlc を導入してみようかな、と考えている方々の参考になればと思い
パスワードレス技術の現状と未来について | フューチャー技術ブログ
はじめにこんにちは。TIG の吉岡です。秋のブログ週間 10 本目の投稿です。 2022年の 5 月に Apple, Google, Microsoft そして FIDO Alliance が マルチデバイス対応FIDO認証資格情報 を発表してから、パスワードレス技術に対する注目が高まっています。1 パスワードレスの概要について調査してまとめてみました。 目次 私たちとパスワード パスワードの抱える問題 パスワードマネージャ 公開鍵暗号の活用 パスワードレスと FIDO Alliance FIDO v1.0 FIDO2 FIDO の認証フロー Passkeys パスワードレスな未来 私たちとパスワード今日、私たちのデジタルアイデンティティはパスワードに支えられています。私たちは日々 Google で検索し、Netflix を観て、Twitter でつぶやき、Amazon で買い物をしますが
AGPLを理解する: もっとも誤解されたライセンス | フューチャー技術ブログ
このエントリーはSayanさんによるUnderstanding the AGPL: The Most Misunderstood Licenseの日本語訳になります。 オープンソースの出現は、ソフトウェア産業全体を一変させました。しかし、オープンソースのコードを使って誰が何をできるかを管理することは課題でしたし、今も解決していません。オープンソースライセンスはそこに救いの手を差し伸べました。しかし、常に次のことを忘れないでください：石のない土地はなく、骨のない肉はありません。OSI（オープンソースイニシアチブ: オープンソースを促進することを目的とする組織）が承認したライセンスは80以上あり、その数はさらに増加しています。それぞれのライセンスには利点と欠点があるため、オープンソースの開発者は自分のプロジェクトにあったライセンスを選ぶのは簡単ではありません。Affero General Pu
Engineer Camp2022 RustでSQLフォーマッタ作成（前編） | フューチャー技術ブログ
はじめにみなさん、こんにちは！ Future Engineer Camp 2022に参加した川渕と齋藤です。 今回のインターンではSQLフォーマッタをRustで作成しました。私達が取り組んだ内容を紹介します。 SQLフォーマッタとはSQLフォーマッタとはSQLを統一された体裁にフォーマットしてくれるツールです。体裁を統一することで他人が見ても読みやすいコードになり、生産性が向上します。 以下の図のように、インデントなどが揃って読みやすくなっていることがわかります。 背景フューチャーではすでにSQLフォーマッタを開発、利用しています。(記事) しかし、そのフォーマッタには以下の2点の問題点があります。 厳密な構文解析を行わずにトークンベースで処理を行っているため、難しい処理がある（例: 括弧の処理、エイリアスの補完など） Pythonで書かれているためVSCodeの拡張機能で動かすことが困難
gRPCのGo実装の新星、Connect | フューチャー技術ブログ
サービス間通信とIDL（インタフェース記述言語）連載の2日目のエントリーです。 本当はGraphQLネイティブなデータベースの紹介をしようとしたのですが、紹介しようとしていたものがまだベータでクライアントライブラリが公開されていない（空っぽのリポジトリしかない）みたいな感じで試せなかったので、急遽2022/6/1に公開されたばかりのgRPC関連のライブラリのConnectを紹介することにしました。 Connectの開発元が公開したブログは次のサイトにあります。 Buf | Connect: A better gRPC 公式ドキュメントはこちらです。 Introduction | Connect なお、gRPCについての詳細はこのエントリーでは紹介しません。ちょうど、H.SakiさんがgRPCの詳しい紹介の記事を書いてくれているので、ぜひ、みなさんこちらを参照ください。 作ってわかる！ はじ
ファイルダウンロード完全マスター | フューチャー技術ブログ
Real World HTTPでも紹介したネタですが、お仕事で受けている技術コンサル中に質問をいただいた時に、微妙に本で紹介した内容では少し足りなかったので、改めて整理のためにブログ記事にしてみました。次回、本が改訂されることがあればこのブログエントリーの内容も入れて加筆したいと思います。 Real World HTTPだとGoを使っていましたが、フロントとサーバーを同時にいじるので、本エントリーではNext.jsをサンプルに使います。Next.jsでプロジェクトを作って（npx create-next-app@latest –ts)、適当なプロジェクト名を入れてアプリケーションの雛形を作っておいてください。 Next.jsでは、1つのスクリプトファイルを作成すると、それがサーバーAPI(/pages/api以下)と、フロントの画面(/pages/以下のapi以外)になります。Next.j
Session Manager と踏み台サーバの共存構成 | フューチャー技術ブログ
はじめにこんにちはー TIG DX Unit のゆるふわエンジニアの前原です。 突然ですが、Session Manager 使ってますか？調べるとブログがたくさん掲載されているので使っているところは多いのかな？って思っています。 また、ブログのタイトルを見ると以下のメッセージが多い印象を受けました。 さよなら踏み台サーバ もういらない踏み台サーバ ..etc なんか、可哀想になってきますね。。 とはいえ、こういったメッセージが多い理由としては、以下のメリットからだと考えられます。 踏み台サーバ不要でAWS リソースに容易にアクセスすることが可能 SSH のキー管理も不要で、IAM User と必要な権限が付与されていればアクセスできる Security Group を意識しなくていい 操作ログも自動でCloudWatch Logs で取得される CloudTrail では、セッションを張っ
Terraformのベストなプラクティスってなんだろうか | フューチャー技術ブログ
はじめにこんにちは、TIG DXユニット 1の木村です。 入社以降ずっと触ってきたTerraformですが、巷ではWorkspace派だったり、module派だったり、ディレクトリ完全分離派だったり、様々な流派(プラクティス)が乱立しているのを目にします。私自身ベストな構成を模索していく中で辿り着いた結論は、ケースバイケースで全てのデザインパターンに対応できる万能なものは存在しないのかな (当たり障りないですね..)ということです。 そんなわけで、様々なTerraformの流派を紹介し、各流派がどのようなパターンに向いているのか(はたまた不向きなのか)の個人的見解をまとめてみました。 ※本記事中のサンプルコードはすべて Terraform 0.12、 provider google cloud で解説してます Terraformとは？当社過去記事に解説があります。Terraformの概要や
はじめてのTerraform 0.12 ～実践編～ | フューチャー技術ブログ
はじめにこんにちはー TIG DXチーム 1のゆるふわエンジニアの前原です。 前回のはじめてのTerraform 0.12 ～環境構築～に続き実践編です。実際の構築を通して、最近バージョンアップしたTerraform 0.12の構文がこんな感じで変わったよー的な話を伝えていければと思っています。 では、Terraformを用いてAWSのリソースを作成していきましょう。 構築する環境構成図下図の環境(VPC, VPC Endpoint, NAT Gatewayなど)をTerraformで構築していきます。 VPC VPCは、Staging（stg）とProduction（prd）に二つのVPCを構成します。AZ（Availability Zone）は3つのゾーンを利用し、サブネットはパブリックとプライベートに分けて構成します。 VPC Endpoint Endpointとして、S3をセットし
Auth0 Rulesのユニットテストを書きたい | フューチャー技術ブログ
TIG DXユニット 1 アルバイトの小林です。 案件で認証プラットフォームであるAuth0を利用していますが、Auth0の機能の中でもRulesと呼ばれるユーザ認証時にJavaScriptの関数を走らせる事が出来る機能は非常に強力で様々なニーズに対応することが可能になります。 その中でJavaScriptの関数で書けるRulesに対して、ユニットテストを書く事が出来れば、Ruleの質も担保出来ます。 Auth0テナントへのRulesのexport、importにはauth0-deploy-cliを利用出来ますが、Ruleの記述方法が function anyRule(user, context, callback) { callback(null,user,context) } の様な名前付き関数の形式なのでユニットテストの実現には工夫が必要となります。 今回はその工夫の部分について書い
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
