2024年版のDockerfileの考え方＆書き方 | フューチャー技術ブログ
最近はお客さんとの勉強会でDockerのドキュメントをつまみ食いして読むというのをやっていますが、改めて最新版を読んでみて、いろいろ思考が整理されました。2020年の20.10のマルチステージビルドの導入で大きく変わったのですが、それ以前の資料もweb上には多数あり「マルチステージビルドがよくわからない」という人も見かけるので過去の情報のアンラーニングに使っていただけるように改めて整理していきます。 仕事でPythonコンテナをデプロイする人向けのDockerfile (1): オールマイティ編で触れた内容もありますが改めてそちらに含む内容も含めて書き直しています。 本エントリーの執筆には@tk0miya氏から多大なフィードバックをいただきました。ありがとうございます。 基本的なメンタルモデル現代的な使い方を見ていくために「Dockerを使ってビルドする」というのはどのようなものか考えを整
2024年Gitワークフロー再考 | フューチャー技術ブログ
春の入門祭り2024の2記事目です。 Gitは、出自としては1週間で作られたLinuxカーネルのための分散バージョン管理システムでした。当時のワークフローに合わせてパッチをテキスト化してメールに添付できるような機能だったりが備わっています。 一方で、現代のGitは、デファクトスタンダードなバージョン管理システムになりLinuxカーネル以外のアプリケーション開発で利用されています。分散バージョン管理ではあるものの、サーバー・クライアント型の使われ方をしていて、GitHubやGitLabを核にして、ローカルで作ったブランチをpushして、Pull Requestの形にして管理しています。少なくとも周りで見る限りでは、それ以外の使われ方の方が少なくなってきてます。そんなこんなで求められている使われ方が変わってきていて、それに合わせた機能がぼちぼち増えています。それを活用することで、ウェブ画面上で
Cloud Run に ko と skaffold を使ってデプロイまでやってみる | フューチャー技術ブログ
はじめにこんにちは！ TIG コアテクチームの川口です。本記事は、CNCF連載 の5回目の記事になります。 本記事では、CNCF の Knative を基盤として利用している Cloud Run と CNCF の各種ビルドツール ko, skaffold、Cloud Deploy を用いたうえで、アプリケーションのビルドからデプロイまでを行います。 扱う技術要素今回は、合計5つの技術要素を扱います。 全体感を掴むため、それぞれの技術とそれらの関連について図示します。 Cloud Run （Knative）Cloud Run は、Google Cloud におけるコンテナベースのサーバーレスコンピューティングサービスとしてよく知られているものかと思います。こちらは、基盤として Knative を採用しています。 この Knative は 2022年の3月に CNCF の Incupating
lib/pq から jackc/pgx への移行 | フューチャー技術ブログ
ライブリッツの筒井です。 GoのORマッパー連載、おまけ記事です。 特に示し合わせた訳では無いのですが、RDBは全員がPostgreSQLを使っていましたね。 さて、今回の連載記事のいくつかでも言及されていた、jackc/pgx について簡単に紹介します。 GoとPoatgreSQLでCOPY GORM v1 と v2 のソースコードリーディングしてみた GoでのPostgreSQLドライバは lib/pq が定番でしたが、現在その開発は消極的で今後機能が追加されることはめったに無いそうです。 https://github.com/lib/pq#status 一方 pgx は現在も活発に開発がなされており、GORM v2にも採用されています。 使い方の比較lib/pq （およびdatabase/sql）と pgx の使い方を比較していきます。 pgxはドライバだけでなく database/
単体テストの考え方/使い方 の感想文 | フューチャー技術ブログ
はじめにTIG EXU真野です。 積読を消化しようというテーマの、読書感想文連載 の1冊目は、単体テストの考え方/使い方 です。 書籍の基礎情報です 2022年12月28日発売 Unit Testing Principles, Practices, and Patterns の翻訳書。原著は2020年1月14日に発売 テーマ 質の高いテストを行い、ソフトウェアに価値をもたらそう！単体（unit）テストの原則・実践とそのパターン プロジェクトの持続可能な成長を実現するための戦略 単体テストの原則・実践とそのパターン コード例は C# であるものの、どの言語でも適用できる汎用的な内容とのこと 中を見ると、微妙にC#特有ぽいところに1箇所悩みましたが、それ以外はその通り 翻訳者の須田さんは、他にもセキュア・バイ・デザイン: 安全なソフトウェア設計 やOAuth徹底入門 セキュアな認可システムを適
フューチャー技術ブログの運営で心がけていること | フューチャー技術ブログ
はじめにTIG DXユニットの真野です。フューチャー技術ブログの運営の1人です。未来報を運営している岡田さんなどと一緒に、気持ちは草の根活動で外部発信に携わっています。 IT企業の技術ブログ運営は、ある一定の質をキープしながらも、投稿頻度を高め・それを継続することが求められ、周囲の期待値もあるので中々気を抜けない仕事だと思います。単発ならともかく、継続することは忍耐が必要なので特に大変です。運営していてこれはナレッジだなと感じたことをまとめていきます。 2020/09/08 続編を公開しました: フューチャー技術ブログで行っている連載企画が良いよって話 技術ブログの大変なところ≒記事ネタを探すところ熱心な寄稿者が複数いて、運営からの声掛け無しで記事が集まるのであれば非常に楽ですが、たいていの組織やチームはそうでないと思います。また、本業は記事を書くことではなく、自社プロダクトの開発やシステ
データベースと向き合う決意 | フューチャー技術ブログ
秋のブログ週間の9本目のエントリーになります。この企画もこんなに書く人が出てくるように育っていいですね。 「中間層を増やして柔軟性を高めるのがソフトウェアの歴史」 これは大学時代に2つ上の先輩が言っていた言葉です。例えばマシン語を直接書くのではなく、アセンブラで書けば、変換（コンパイル）の手間はかかりますが、他のCPUへの移植はしやすくなります。高級アセンブラと名高いC言語を使えばさらに移植性は上がります。C言語で書かれたVMを使う言語、例えばJava、Python、Rubyなんかはさらに移植性は上がります。 ストレージもそうです。最終的にストレージはビット列を保存するものですが、それにOSのファイルシステムというレイヤーがあり、そこにスキーマで管理されたデータを入れるDBMSが乗っかり、SQLなどの問い合わせ言語でデータ取得できるようにします。DBMSを挟むことで、レプリケーションでバッ
Goで作ったロジックにWebUIをつけてGitHubページに公開する | フューチャー技術ブログ
ちょっとしたツールをGoで作ってみたのですが、わざわざインストールしなくてもいいようにWebのUIをつけてブラウザで使えるようにしてみました。作ってみたのは以下のツールで、Markdownのリスト形式でざっと下書きしたテーブルの設計をSQLとか、PlantUMLとかMermaid.js形式のERDの図にします。 https://shibukawa.github.io/md2sql/ ウェブフロントエンド部分はNext.jsの静的サイトで、GoはWASMにしてロードして実行しています。WASMを使うのは初めてなのであえて選んでみました。 GoをWASM化するもともとCLIツールは作っておりました。CLIのメインはcmd/md2sql/main.goで作っていました。この中でやっていることは kingpin.v2のオプションパース 指定されたファイルを読み込み(あるいは標準入力) パース 指定
スキーマのバージョン管理と互換性の話 | フューチャー技術ブログ
はじめにはじめまして、TIGの原木です。サービス間通信とIDL（インタフェース記述言語）連載の4本目です。 気が付けば、バージョンの話0ばかりしています。 この記事ではスキーマのバージョン管理と互換性について話します。 “スキーマ”が指し示す言葉と課題一般的にスキーマのバージョン管理という話が出た場合、次のどちらかを想像する人が多いのではないでしょうか。 データベースのスキーマ(DB内のデータ構造)の変更をどうやってバージョン管理していくか サービス間通信で使用するデータフォーマット(ex. gRPCのprotobuf)をどうやってバージョン管理していくか データ構造が変わったことによりソフトウェアの改修が発生するとわかった瞬間、この問題に直面して「どうしよう…」と悩まれた経験を持つ方は数知れずいらっしゃるかなと思います。 両者において、スキーマのバージョン管理が課題だと意識するタイミング
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
仕事ですぐに使えるTypeScript — 仕事ですぐに使えるTypeScript ドキュメント
注釈 本ドキュメントは、まだ未完成ですが、ウェブフロントエンドの開発を学ぶときに、JavaScriptを経由せずに、最初からTypeScriptで学んでいく社内向けコンテンツとして作成されはじめました。基本の文法部分以外はまだ執筆されていない章もいくつもあります。書かれている章もまだまだ内容が追加される可能性がありますし、環境の変化で内容の変更が入る可能性もあります。 書籍の原稿はGitHub上で管理しております。もしTypoを見つけてくださった方がいらっしゃいましたら、 GitHub上で連絡 をお願いします 1 。reSTファイルだけ修正してもらえれば、HTML/PDFの生成までは不要です。フィードバックなども歓迎しております。 1 https://github.com/future-architect/typescript-guide/pulls
Go 1.16のsignal.NotifyContext() | フューチャー技術ブログ
Go 1.16リリース記念連載の最終回はsignal.NotifyContext()です。 ご存知のように、Go 1.7でcontext.Contextが入ってから、少しずついろいろなAPIがContext対応になりました。 1.7 netのDialerがDialContext()メソッドを追加 net/httpのhttp.RequestがContext()とWithContext()メソッドを追加。 os/execがCommandContextを追加 1.8 database/sqlが大幅にcontext.Context対応を追加 net/httpのhttp.ServerがShutdown()を追加 netにcontext.Contextに対応したリゾルバーを追加 1.13 net/httpのNewRequestWithContextと、Request.Clone()が追加 外部へのネッ
フューチャーOSS推進タスクフォース始めます | フューチャー技術ブログ
2020/11/13修正: Vuls、Urushiの公開年を修正 初めにフューチャーOSS推進タスクフォースを開始しました。実は7月に発足してから8月には活動の骨子が固まり、タスクフォース自体は始動していましたが、中身を作ってから告知した方が具体性があってブレも無くなり良いのでは？という話があり、少しタイミングをずらしてのご報告です。 何を目的とし、何をやっていくつもりなのかこれから説明していきます。活動ははじめましたが。まだまだ手探りな状態ですので運用などなどでアイデアがあればフィードバックをいただきたいのと、”思い”を共にできる方がいらしたら、どこかの勉強会などで意見公開できればなと思います。 OSSとフューチャーの関わり最初に今までのフューチャーとOSSの関わりについて説明します。 フューチャーはVuls, cheetah-grid, UroboroSQLを初め多くのプロダクトを公開
GKEクラスタに割り当てるCIDRを設計する | フューチャー技術ブログ
はじめに前回投稿したGCP記事で紹介したGKEクラスタのCIDR設計について、深堀りした記事になります。 1-5. 共有VPC上のGKEクラスタのセカンダリCIDR設計 事象: オンプレ環境と接続する1つの共有VPC上にproduction, stagingなど複数プロジェクトを相乗りさせる場合、各プロジェクトで利用するセカンダリCIDRの設計が必要。 対応: GKEで必要なセカンダリCIDRを本腰入れて設計しました。スタンダードなこれと言った解はなく、必要な環境数、オンプレ環境から割り当てられたIP範囲から適宜設計する必要があります。 記載通りですが、GKEクラスタを構築する際に、実際に設計した内容を元に制約や設計のポイントを紹介したいと思います。 GKEとは コンテナ化されたアプリケーションをデプロイするための、本番稼働に対応したマネージド型環境です。 https://cloud.go
GoでWebアプリ開発時にあるあるだったレビューコメント | フューチャー技術ブログ
The Gopher character is based on the Go mascot designed by Renée French. はじめにTIG DXユニット 1の真野です。 コードレビューについては3,4年ほど前に、コードレビューにおけるレビュアー側のアンチパターン って記事を書いたりもしました。当時はレビュアーの伝え方って大事だよなって話をしてました。いつしかレビュイーからレビュアーに比重が変わることが増えてきました。相互レビューは当たり前にしていますがが、比較的こうしたらもっと良くなるんじゃないかな？と提案される回数より、自分が提案する回数の方が増えてくるタイミングってありますよね？ そういうわけで、最近Goで主にバックエンドのWebAPIや、AWS Lambdaで動くETLアプリ、たまにCLIツールを開発する時に、2回以上同じ指摘したコメントをまとめてます。Go言語
チームで機能設計するためのPlantUML標準化 | フューチャー技術ブログ
はじめに現在所属しているプロジェクトではWebAPIやバッチ処理の設計の一環としてPlantUMLを利用しています。効率よく品質高くアウトプットを出すためには、プログラミング言語に対してコーディング規約があるように、UMLに対してもチームで設計するにあたり一定のルールを決める必要があります。 そこでプロジェクト内のPlantUMLを使用するうえでのガイドラインやルールをまとめる機会があり、せっかくなのでそれを記事化します。 記事のゴール シーケンス図設計におけるPlantUMLの標準化 必要最低限のルールだけに絞ってチーム設計の生産性と品質を上げる 記事の前提 ルールの想定の利用シーン： チームで大量生産する業務機能の処理フローを表現するために使う場合を想定。 また、この記事に記載されているルールはRDBを中心的に使用したAPI処理やバッチ処理等を念頭に置き決められたものです。 ルールの想
あなたのGoアプリ/ライブラリのパッケージ構成もっとシンプルでよくない？ | フューチャー技術ブログ
2023.10.5追記: Goチームからプロジェクトの目的に応じたディレクトリ構造についてのドキュメントが公式に公開されています。 https://go.dev/doc/modules/layout Goでプロジェクトのフォルダ構成どうしよう、とググると見つかるStandard Go Project Layout。とはいえ、これはかなりコード量を増やしてしまう恐れがありますので、導入する場合のデメリットも考えておく方が良いです。 特に、プログラマーは、最初にみたプログラミング言語のフォルダ構成を親だと思う特性があり、Javaや.NETに影響されるとかなり細かくフォルダを切りたくなったり、package privateなど細かく可視性を制御しようとしたりして、なおかつ「privateのテストってどうすべきなんですか？」とか議論を始めたりもしますが、Go先生によればこれぐらいは1パッケージにフ
Goの標準ライブラリのコードリーディングのすすめ | フューチャー技術ブログ
パッケージの選定そもそも、どのパッケージを読んだらいいんだろう？という疑問があると思います。上記のパッケージを選定した方法を紹介したいと思います。 読むパッケージの選定は有志のメンバ数名で一緒に決めました。 まずパッケージのステップ数を見てスクリーニングしています。gocloc というツールを使うと以下のフォーマットで簡単にステップ数を確認することができます。 $ gocloc archive ------------------------------------------------------------------------------- Language files blank comment code ------------------------------------------------------------------------------- Go 21 7
CUEを試して見る | フューチャー技術ブログ
前回のエントリー、一周回って、人間が読み書きする設定ファイルはJSONが良いと思ったの続きです。 設定ファイルをどうするか問題はいろいろ悩ましい問題であります。そんな中、設定ファイル用言語という触れ込みのCUEがリリースされました。 すでに、NSSOLの方が、Linterとして使うという紹介記事をすでに書かれています。これはユースケースの一部（これでも有用ですが）です。まだ使い込んだわけではなく、チュートリアルとドキュメントを一通り読みつつ軽く試した程度ですが、全体的な紹介をしようと思います。 yamlやJsonのチェック(Lint)ができるCUEの紹介 CUEによってできるようになること主な特徴としては次のような感じです。 人が書く設定ファイル(JSON/YAML/TOML/iniあたりがライバル)のための言語 スキーマ定義が書けて、バリデーションが可能 テンプレート機能で一部が違うデー
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
