非同期設計ガイドラインを公開しました | フューチャー技術ブログ
はじめにこんにちは。TIG（Technology Innovation Group）の亀井です。 フューチャー社内の有志メンバーで 非同期設計ガイドライン を作成し、公開しました！ 本記事では、ガイドライン策定の背景や、ガイドラインで取り上げている設計のポイントをピックアップしてご紹介します。 本ガイドライン策定の背景かつて非同期処理といえば、専門的なメッセージングミドルウェアを必要とする、一部のミッションクリティカルなシステムで採用される特別な技術でした。フューチャーでも独自のミドルウェアフレームワークを構築して、大量データをリアルタイムで処理するような仕組みを数々の工夫を凝らして実装してきました。 一方で、昨今ではAWS SQSなどのクラウドネイティブなサービスの登場により、応答時間の長い処理のオフロードなどを目的に非同期処理を取り入れることは珍しくなくなりました。 しかし、非同期特有
ログ設計ガイドラインを公開しました | フューチャー技術ブログ
はじめにTechnology Innovation Groupの八木です。 フューチャー社内の有志メンバーでログ設計ガイドラインを作成し公開しました！ ログは、システムの稼働状況を可視化し、トラブルが発生した際に迅速に原因特定するための生命線になります。しかし、その重要性の一方で、プロジェクトごとに設計がバラバラになりがちだったり、とりあえず標準出力しているだけになっていたりと、十分に活用しきれていないケースも多く見受けられます。 本記事では、今回公開したログ設計ガイドラインの背景や、現場で役立つ設計のポイントを抜粋してご紹介します。 ガイドライン作成のモチベーションこれまで、ログ設計は個々のエンジニアの経験則や、プロジェクトごとの慣習に委ねられることが多くありました。しかし、システムが複雑化し、マイクロサービスやクラウドネイティブな構成が当たり前になった現代において、ログの役割は「単なる
バッチ設計ガイドラインを公開しました | フューチャー技術ブログ
はじめにこんにちは。TIG（Technology Innovation Group）の本田です。 フューチャー社内の有志メンバーでバッチ設計ガイドラインを作成し、公開しました。 本記事ではガイドラインの作成の経緯や想いなどを簡単に紹介します。 本ガイドラインの対象読者本ガイドラインは、以下のような方を主な読者として想定しています。 バッチ開発を行う初学者 バッチ処理を含むシステム設計を行う人 自身のメイン領域はバッチ処理ではないがバッチ処理設計の勘所を知っておきたい人 特に初学者の方はジョブ設計の章だけでも読んでいただくことをオススメします。バッチ処理のプログラムを実装する上で留意するべき冪等性や性能といったポイントが紹介されています。 本ガイドラインの作成経緯フューチャーでは様々な規模のシステムを構築しており、その中には多種多様なバッチ処理も含まれます。 cronのようなシンプルなスケジ
Webフロントエンド設計ガイドライン
免責事項 有志で作成したドキュメントである。フューチャーには多様なプロジェクトが存在し、それぞれの状況に合わせて工夫された開発プロセスや高度な開発支援環境が存在する。本ガイドラインはフューチャーの全ての部署／プロジェクトで適用されているわけではなく、有志が観点を持ち寄って新たに整理したものである相容れない部分があればその領域を書き換えて利用することを想定している。プロジェクト固有の背景や要件への配慮は、ガイドライン利用者が最終的に判断すること。本ガイドラインに必ず従うことは求めておらず、設計案の提示と、それらの評価観点を利用者に提供することを主目的としている掲載内容および利用に際して発生した問題、それに伴う損害については、フューチャー株式会社は一切の責務を負わないものとする。掲載している情報は予告なく変更する場合がある はじめに 昨今のWebフロントエンド領域は、単なるHTML、CSS、
PostgreSQL設計ガイドラインのご紹介 | フューチャー技術ブログ
はじめにフューチャー社内の有志メンバーでPostgreSQL DB設計ガイドラインを作成しました。 PostgreSQL設計ガイドライン | Future Enterprise Arch Guidelines 形になってから数ヶ月寝かせており、ある程度社内の指摘を取り込むことができたのでこのタイミングで告知します よくあるDB設計規約との差別化ポイント単にDB設計ガイドラインというと何を今更？感もあるので、命名規則や型桁など一般的な内容に加え、以下の点でよくあるDB設計ガイドラインから一歩踏み込んだコンテンツとなるよう心がけました。 論理設計への踏み込み単なるテーブル定義やデータ型選択にとどまらず、より高度な論理設計の原則に焦点を当てています。 マスタ/トラン/ワークデータベース設計において、データの種類に応じてテーブルを明確に分離することは設計効率と保守性を高める上で重要ですが、意外とそ
Terraform設計ガイドライン
免責事項 有志で作成したドキュメントである。フューチャーには多様なプロジェクトが存在し、それぞれの状況に合わせて工夫された開発プロセスや高度な開発支援環境が存在する。本ガイドラインはフューチャーの全ての部署／プロジェクトで適用されているわけではなく、有志が観点を持ち寄って新たに整理したものである相容れない部分があればその領域を書き換えて利用することを想定している。プロジェクト固有の背景や要件への配慮は、ガイドライン利用者が最終的に判断すること。本ガイドラインに必ず従うことは求めておらず、設計案の提示と、それらの評価観点を利用者に提供することを主目的としている掲載内容および利用に際して発生した問題、それに伴う損害については、フューチャー株式会社は一切の責務を負わないものとする。掲載している情報は予告なく変更する場合がある はじめに Terraformはインフラを宣言的にコード管理するツール
Develop in SwiftでSwiftDataの基本を学ぶ ~Models and persistence編~ | フューチャー技術ブログ
はじめにHealthCare Innovation Group(HIG)1の橋本です。 新しく登場した公式チュートリアルDevelop in SwiftのModels and persistence、Data editing and navigation、Relationships and queriesという3つのセクションでSwiftDataを学べるとのことで実際にやってみました。 今回は、1つ目の Models and persistence編 です。Models and persistenceセクションで学んだこと、Wrap-upのExtend your appの追加課題をやってみたので、これらについてまとめています。 本記事でわかること SwiftDataの基本的な使い方 SwiftDataの導入 @Model, @Queryの使い方 SwiftUIのViewとの連携 Wrap-
2024年版のDockerfileの考え方＆書き方 | フューチャー技術ブログ
最近はお客さんとの勉強会でDockerのドキュメントをつまみ食いして読むというのをやっていますが、改めて最新版を読んでみて、いろいろ思考が整理されました。2020年の20.10のマルチステージビルドの導入で大きく変わったのですが、それ以前の資料もweb上には多数あり「マルチステージビルドがよくわからない」という人も見かけるので過去の情報のアンラーニングに使っていただけるように改めて整理していきます。 仕事でPythonコンテナをデプロイする人向けのDockerfile (1): オールマイティ編で触れた内容もありますが改めてそちらに含む内容も含めて書き直しています。 本エントリーの執筆には@tk0miya氏から多大なフィードバックをいただきました。ありがとうございます。 基本的なメンタルモデル現代的な使い方を見ていくために「Dockerを使ってビルドする」というのはどのようなものか考えを整
go-smtp-mockをSMTPのモックサーバにして単体テストする | フューチャー技術ブログ
はじめにTIG真野です。 バックエンドのアプリケーションの上で、メール送信するコードがある場合の単体テストをどう実現するか悩みました。 メールには、タイトル・本文・From・TO・CC・BCCなど複数の設定値がありますし、SMTPサーバの接続情報もあります。これらを表現する構造体のモデルだけに絞った検証に留めることは、気が進みませんでした。時代はインフラレベルでダミーサーバを動かしモックする方向で動いています。SMTPでメール送信し、その送信結果をテストコード上で取得＆検証する一連の流れを行って動作を確かめたいと思いました。 方法として、澁川さんのMailSlurperを使って6桁のコードの送信コードのテストをするで紹介されたMailSlurperを使うか迷いましたが、以下の点で牛刀だなと感じました。 メール送信するのはごく一部の機能（私の場合は1機能。今後増える見込みは現時点で見えなかっ
フィーチャーフラグを管理するためのOpenFeature | フューチャー技術ブログ
はじめにTIG DXユニット真野です。 CNCF連載の2本目はクラウドネイティブなフィーチャーフラグの標準とAPI、SDKを提供するOpenFeatureについてです。 フィーチャーフラグとはフィーチャーフラグとはコードを変更せずに、フラグを使って機能を有効/無効化する開発/デプロイ手法のことです。一般的なユースケースとしては、特定のユーザーに対して再起動とか再デプロイをせずに、新機能を有効化したいといった場合に役立ちます。信頼度が高くなったらより段階的に広範囲に対象を広げていくと安心ですね。この使い方だけであれば、カナリアリリースを想像しますが、他にも次のようなユースケースが考えられます。 初期から契約している特別な顧客（あるいはプレミアムプランに契約している顧客）に向けて開発した機能を提供する バグが見つかったので、該当機能を無効化してアプリの振る舞いをロールバックする 繁忙期にシステ
管理画面等でNext.jsをBetter Reactとして使う | フューチャー技術ブログ
最近、Next.jsが複雑になりすぎて、単なるウェブ画面を作る用途にはNext.jsは重すぎるので別のものが良いとか、Vercel統合のための機能が多いんでしょ、みたいな感想を見かけることが増えた気がします。特に管理画面とか社内システムとかですね。B2Cでも設定画面系とかは当てはまるかもしれません。 ホンダ時代に、タイプRを買っても実際にサーキットとかに走らせに行く人は1/10ぐらい、という話を聞いた気がしますが、必ずしも、そのすべてのパフォーマンスを引き出さないのはダメとかなくて、単にかっこいいからとか、一部のメリットでも自分にあえば良いのです。 Next.jsも、たくさん機能がありますが、ミニマムな使い方もできます。 ほぼNext.jsの機能をオフにした使い方たぶんNext.jsを最低限で使うライン・メリットはここかな、と思います。 基本的に全部CSR(Client Side Rend
「リーダブルコード」を読んでTerraformの可読性について考える | フューチャー技術ブログ
こんにちは。TIGの伊藤太斉です。 この記事は、読書感想連載の6日目です。 今回取り上げる書籍は、多くのエンジニアが通過するであろう、「リーダブルコード」についてです。 最近、「もし「リーダブルコード」を弁護士が読んだら？」という記事をたまたま見かけて読んでみました。記事としては契約書にも同じことが言える、と自分が知らない世界でも使える部分はあるのだと読んでいました。そして、ふと考えてみると、「うちにも本があったじゃないか。しかも積読している」と思い出し、今回積読解消の機会としてこの連載に参加しました。 リーダブルコードを書評や感想については既に多くの方が書いている内容があるので、今回はTerraformと絡めて書いていければと思います。私は、俗にいうプログラミング言語に対しては明るくない方なので、自分が理解できうるTerraformにおいて考えたらどうなるか、について地震の頭の整理、理解
パスワードレス技術の現状と未来について | フューチャー技術ブログ
はじめにこんにちは。TIG の吉岡です。秋のブログ週間 10 本目の投稿です。 2022年の 5 月に Apple, Google, Microsoft そして FIDO Alliance が マルチデバイス対応FIDO認証資格情報 を発表してから、パスワードレス技術に対する注目が高まっています。1 パスワードレスの概要について調査してまとめてみました。 目次 私たちとパスワード パスワードの抱える問題 パスワードマネージャ 公開鍵暗号の活用 パスワードレスと FIDO Alliance FIDO v1.0 FIDO2 FIDO の認証フロー Passkeys パスワードレスな未来 私たちとパスワード今日、私たちのデジタルアイデンティティはパスワードに支えられています。私たちは日々 Google で検索し、Netflix を観て、Twitter でつぶやき、Amazon で買い物をしますが
Raspberry Piをかき集めてKubernetesを体感する | フューチャー技術ブログ
夏の自由研究ブログ連載2022 の10本目です。 はじめにTIG 岸下です。業務でGKE（Google Kubernetes Engine）を利用することがあるのですが、Kubernetesの挙動や仕組みなど如何せん理解が難しいです。 そこで今回は、自分の手でイチからKubernetesを構築することで勉強しようと思ったのが本記事のモチベーションです。 ちょうど自宅にRaspberry Piが3台あったのでRaspberry Piでクラスタを構築していこうと思います。基本的には以下の記事を参考に設定を行っていき、自分の理解を深めるために解説を挟みながら書いていこうと思います。 参考：RaspberryPi 4 にUbuntu20.04 をインストールして、Kubernetes を構築してコンテナを動かす 今回Kubernetes構築するにあたって用意したもの Raspberry Pi3 M
Terraformerとしてコードを書いて思うこと | フューチャー技術ブログ
こんにちは。TIGの伊藤です。この記事は秋のブログ週間2021の3日目です。 はじめに私は普段会社でクラウドをまたいでTerraformを日々書いたり、メンバーに教えたりしています。もはや俗に言うプログラミング言語を書かずにここまで全振りしてきたくらいなので、比較的自信を持ってコードを書いて仕事をしています。 特にここ最近はほぼ1からコード設計をして運用まで持っていくこともあり、「より腐りにくい、より息の長いコード」というものを考えるようになりました。Terraformだからこその「定期メンテを簡易にするためには」「より簡単に変更するためには」をひたすら突き詰めていった結果、アツい気持ちが生まれ、今回は筆を取っています。 そんな私のアツい気持ちをしたためた今回の記事ですが、可能な限り例も添えつつ、いくつか解説できればと思います。公式にも実は載っているような内容もあったりしますが、日本語の記
どうしてHTML5が廃止されたのか | フューチャー技術ブログ
フロントエンド連載の5記事目です。 HTML5が2021年の1月に廃止されました。 Webエンジニアとしてバリバリ活躍されてる方やエグゼクティブテックリードのような肩書きを持つ方にとっては「何をいまさら」という話題かと思います。 しかしながら、今年も新人さん入ってきてくださったので、プログラミングを学習中にHTML5という文字列に悩まされないように、そもそもHTML5とは何かや、廃止された経緯をまとめてみます。 HTML5とはWebサイトを作るときに必ず書くことになるHTML。Webサイトのコンテンツ、つまり中身や構造を作るために使うマークアップ言語です。 そして、その最近版として10年ほど前に登場したHTML5。当時は Webニュースなどで盛んに特集が組まれていましたが、このHTML5がついこないだ、2021年1月28日に廃止されました。 広義のHTML5 / 狭義のHTML5HTML5
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
