タグ

ブックマーク / future-architect.github.io (88)

  • 初めてのPostman | フューチャー技術ブログ

    はじめに春の入門祭り2025 1日目です。 Web API開発プラットフォームとして高い人気を誇るPostmanの入門記事です。 PostmanとはPostmanはWeb API開発のあらゆる工程を支援するプラットフォームです。 この、Web API開発プラットフォームという用語は初見ではイメージがつきにくいかと思います。例えば、curl や VS Coode拡張の REST Client とどの程度違いがあるのか、 OpenAPI Specification などとの関連性は?などフワッとしてしまいます。 まず、競合?となりえそうな周辺のツールと比較すると輪郭が明確になるのではないかという仮説のもと作成したのが下表です。 フェーズ/機能詳細Postman競合ツールの例設計API定義 (OpenAPI) 作成・編集・検証✅ API Builder (OpenAPI v2, v3, v3.1

    初めてのPostman | フューチャー技術ブログ
  • Slack利用ガイドライン | Future Enterprise Arch Guidelines

    規約は、世の中のシステム開発プロジェクトのために無償で提供致します。 ただし、掲載内容および利用に際して発生した問題、それに伴う損害については、フューチャー株式会社は一切の責務を負わないものとします。 また、掲載している情報は予告なく変更することがございますので、あらかじめご了承下さい。 はじめに ​リモートワーク/ハイブリッドワーク前提の業務において、チャットなどの非同期コミュニケーションを円滑に進めることは、業務効率を向上させるだけではなく、従業員全員の満足度を向上させ、より良い職場づくりに繋げることができる。 また、ユーザーの様々な要望に応えるため、現代のチャットサービスは豊富な機能が提供されている。しかし、各ユーザーの考え方/利用者の感覚が千差万別であるため、ある人によって問題ないとされる行動が、別の人にとっては良くない受け取り方をされることも多い。例えば次のような対立が考えられ

  • Terraform設計ガイドラインを公開しました | フューチャー技術ブログ

    こんにちは。TIGの伊藤です。 Terraform連載2025の6日目の記事です。 2025年始から、社員の有志でTerraform設計ガイドラインを編集し、先日公開したので公開までの経緯などについて触れていきます。 公開までの経緯Future Enterprise Arch Guidelinesとして、これまでにもWebAPI設計ガイドライン、Slack利用ガイドラインなどを公開してきましたが、これらは社内に知見が溜まってきていることをきっかけに、ガイドラインとして整理して公開しています。 Terraformについても、社内の複数プロジェクトで利用されており、それぞれで工夫したこと、ケアしたポイントなどが知見として出てきていることから、社員がリファレンスとすることも含めて編集、公開することになりました。 チームにおけるガイドラインを設けることの難しさ各プロジェクト、チームでは一定のコーデ

  • Tailwind CSSのドキュメントから見えてくる使い方とCSS設計のヒント | フューチャー技術ブログ

    CSSをわかりやすくメンテナンス性高く書くというのは長い間試行錯誤され続けてきました。命名規則でがんばる、SCSSのようなプリプロセッサを使う、CSS in JSなどいろいろな仕組みがかつて作られたりしてきましたが、現在一番シェアを集めているのがTailwind CSSです。State of CSS 2024の調査でも他のカテゴリ含めても一位です。 1/23に最新バージョンの4系がリリースされました。そんでもってぼちぼちドキュメントの読書会をしているのですが、いろいろ利用方法のヒントがあったのでまとめてみます。一部「これから使う場合はこうしたい」という僕の意見もありますが、そこに関しては異論とか「実際やってみたけどこうだった」とかあると思いますので、そういうご意見などはXとかでいただければと思います。 そもそもなぜTailwind CSSを使うのか?Tailwind CSSは万人に支持され

    Tailwind CSSのドキュメントから見えてくる使い方とCSS設計のヒント | フューチャー技術ブログ
  • Transformerの文章生成の仕組みを理解する | フューチャー技術ブログ

    記事の前提読んでほしい人Transformerを知っていて、その理解を深めたい人大規模言語モデル (LLM: Large Language Model) がどのようにして推論しているのかを知りたい人触れている内容ユーザが質問をして、Transformerが回答を生成するまでの一連(end-to-end)の処理Transformerの仕組みについて広く浅く触れていない内容学習時に行われる処理(MaskやDropoutなど)Pythonなどのプログラミング言語を用いたTransformerの実装方法最初に「構成図」で理解するまずは元論文「Attention Is All You Need」から引用したTransformerの構成図を図1に示します。 図 1.元論文から引用したTransformerの構成図 とても簡潔ですが、図からは理解できない内容が多々あるかと思います。そのため、少しだけ具

    Transformerの文章生成の仕組みを理解する | フューチャー技術ブログ
  • Difyで生成AIアプリケーション入門 前編:生成AIアプリケーションをノーコードで開発 | フューチャー技術ブログ

    概要Dify (DeFiではない)と Anthropic Claude (OpenAI でも OpenRouter 経由の何かでもOK)を使って簡単に生成AIアプリケーションを構築する方法をご紹介します。 前編:ノーコードで生成AIアプリケーションを構築するチュートリアル 後編:自作プログラムで機能追加して生成AIの指向性と精度を高めるサンプル の2立ての予定です。 対象読者 生成AIに興味があるがまだチャット以上の利用法を見出せず手を出せていない方 お試しに手軽に生成AIアプリケーションを構築してみたい方 特にOpenAIに月額費用に躊躇っている方 前提知識・環境 Docker (Docker Compose)。Windows なら Docker Desktop。後編ではホスト名 host.docker.internal を使用します “時々生成AIをチャットで活用している”程度のプロ

    Difyで生成AIアプリケーション入門 前編:生成AIアプリケーションをノーコードで開発 | フューチャー技術ブログ
  • PostgreSQLのPub/Sub機能とJavaのクライアント実装 | フューチャー技術ブログ

    記事は「珠玉のアドベントカレンダー記事をリバイバル公開します」企画のために、以前Qiitaに投稿した記事を改訂したものです。 はじめにPub/Sub型のメッセージングアーキテクチャを採用するにあたっては、kafkaなどのブローカーミドルウェアや、Amazon SNSGoogle Cloud Pub/Subなどのマネージドサービスを利用するケースが多いかと思います。ところでPostgreSQLでも実はPub/Subができます。 すでに業務でPostgreSQLを使っていれば、新たにPub/Subブローカーを構築しなくても、疎結合なシステム間通信を簡易的に実現できます。 記事ではこの機能の紹介と、Pub/SubクライアントをJavaで実装する場合の選択肢、考慮点を示しています。 ※実行環境はPostgreSQL 16.2とJava 21です ※データベースの文字コードはUTF-8としてい

    PostgreSQLのPub/Sub機能とJavaのクライアント実装 | フューチャー技術ブログ
  • 個人的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

    個人的docker composeおすすめtips 9選 | フューチャー技術ブログ
  • Cloudflare Snippetsをやってみた | フューチャー技術ブログ

    こんにちは。Cloudflareの亀田治伸です。 動画・音楽配信システム構築、決済代行事業者、AWSエバンジェリストを経て現職(Cloudflare)となります。得意領域は、認証、暗号、ネットワークを中心としたセキュリティ、 映像配信、開発手法に見る組織論、クラウドアーキテクチャ、プレゼンテーションなどです。 はじめにCloudflare Snippetsは新しいCloudflareのサービスであり2023年6月にクローズドアルファ版がリリースされ、2024 Develoer Weekでは無作為に抽出された5%のユーザーが利用可能になっていました。6月頭より全ユーザーが利用可能となったサービスです。 https://blog.cloudflare.com/ja-jp/cloudflare-snippets-alpha-ja-jp Cloudflare Snippets とはCloudfla

    Cloudflare Snippetsをやってみた | フューチャー技術ブログ
  • Cloudflare採用のアーキテクチャ選定 | フューチャー技術ブログ

    Cloudflare連載3日目の記事です。 はじめにこんにちは、TIGの宮崎将太です。 これまで個人/業務ともにあまりCloudflareを使用してきませんでした。クラウド前提で仕事をしていると、各クラウドプロバイダーが提供するCDNやWAFがあり、その部分だけ外部サービスを採用するメリットを見いだせなかったことが最大の理由です。 しかし、とある事情からCloudflare採用に至るケースが発生したので、その動機と比較検討内容を記事にしておこうと思います。 どんなアーキテクチャでCloudflareを採用したのか?結論ですが、ハイブリッドクラウド構成でのCDN/WAFとしてCloudflareを採用しました。 構成は少しぼかしますが、メインのサービス提供はAWS、認証機能の提供のみAzureを使用しています。想定するユースケースにおいてコストメリットもあるため基的なクラウド環境にはAWS

    Cloudflare採用のアーキテクチャ選定 | フューチャー技術ブログ
  • Terraformに入門して1ヶ月経ったので、初心者が気をつけるべきポイントを書いてみる | フューチャー技術ブログ

    はじめにTerraform連載2023 の8リソース目の記事は、Terraform初心者向けの記事です! こんにちは、TIG DXユニット所属の大岩と申します。 去年の7月に新卒で入社し、新卒研修を終えた後、実際のプロジェクトに配属されました。このプロジェクトでは、Terraformを使ってAWSのインフラ構築を自動化する業務に携わりました。これまでTerraformはおろか、インフラもネットワークの知識もほとんど無い未経験の状態からのスタートです。日々インフラの知識を脳に叩き込み、それをコードの形でアウトプットしていく、なんとも目まぐるしい毎日を過ごしております。 当記事では、初心者がTerraformを扱う際に気をつけるべきポイントについて、自分が1ヶ月間みっちりTerraformを触った経験をもとに紹介します。 動作環境は以下のとおりです。 Terraform v1.4.1 terr

    Terraformに入門して1ヶ月経ったので、初心者が気をつけるべきポイントを書いてみる | フューチャー技術ブログ
  • Terraform連載2023を開始します | フューチャー技術ブログ

    こんにちは。TIGの伊藤太斉です。 Terraform連載のインデックス記事です。 最近の社内 Terraform 事情について最近では当社も前提としてクラウドを利用する案件が増えてきました。その際に利用するツールとしては Terraform CloudFormation Serverless Framework と、マネージドのも含めて広く利用しているように感じております。ことにTerraformについては対象とするサービスもAWSGoogle Cloudだけでなく、Auth0などのSaaSに対して管理対象としたり、管理を検討しているプロジェクトなどもあります。 テーマについてきっかけは、Terraformがv1.4になったことから始まりました。 https://github.com/hashicorp/terraform/releases/tag/v1.4.0 元々、社内でパブリック

    Terraform連載2023を開始します | フューチャー技術ブログ
  • Terraform連載2024を開始します & TerraformにおけるDR戦略を考える | フューチャー技術ブログ

    Terraformで考えるマルチリージョン構成Terraform、もといIaCのメリット、思想として謳われるものの中には可搬性、再利用性があります。再利用性を上げておくことで、同じ構成のインフラ、サービス群を一括して作成でき、手作業と比べた時の再現性、信頼度が大きくなることはいうまでもありません。 具体、業務を前提としたITインフラ環境を考えたときに、社会インフラとして稼働しているサービスや、どんな状況であろうとも24時間365日稼働していないといけないサービス、企業があります。このような企業では災害対策環境として、地理的に大きく離れたエリアにDCを構えることで、ある1点で甚大な災害が発生してサービス断になったとしても、別のDCで継続することが可能になります(もちろん一定時間のサービス断は発生しますが、数日、数ヶ月単位になることはほぼないでしょう)。 この災害対策環境(この後はDR環境と記

    Terraform連載2024を開始します & TerraformにおけるDR戦略を考える | フューチャー技術ブログ
  • React Server ComponentでもContextで状態を共有する | フューチャー技術ブログ

    Next.jsの最近の大きな目玉機能はReact Server Component(以下サーバーコンポーネント)です。パフォーマンスアップに有効だったり、gRPCだRESTだGraphQLだ論争を終わりにするServer Actionsなど盛りだくさんです。 一方で、サーバーコンポーネントはコーディング上の制約がいろいろあります。 サーバーコンポーネントではhooksが使えない サーバーコンポーネントのソースからクライアントコンポーネントはimportできるが逆はできない。レンダーツリーを工夫すればクライアントコンポーネントの下にサーバーコンポーネントを配置することは可能 サーバーコンポーネントでは非同期コンポーネントを作成でき、fetchでサーバーから情報をとってきたり、DBアクセスした結果を利用できます。しかし、最近のモダンReactの場合、状態管理などはすべてhooksに寄せるので大

    React Server ComponentでもContextで状態を共有する | フューチャー技術ブログ
  • Dev Containersの始め方(1) : 仕組み編 | フューチャー技術ブログ

    VDIでもGitHub Codespacesなんかだとエディタはローカルのブラウザで動いたり、検証用ブラウザはポートフォワードでローカルのブラウザが使えたり、というのはありDev Containersとだいぶ近いのです。 ソースコードなどもローカル側が主で、そのコピーがDockerにコピーされます。実際にエディタが編集するのはコンテナ内部にコピーされたファイルだったりする(変更はローカルに同期される)のですが、基的に通常のローカル開発と感覚はほとんど変わりません。⌘ + JとかCtrl + Jでターミナルを開くと、Docker内部に繋がっている以外は操作感覚は変わらないです。 いくつかネットで記事を見ると、いろいろコンテナを作り込んでいる記事とかも見かけるのですが、さぞ、特別なコンテナなんだろう、といくつかMicrosoft謹製のDev Containers用のコンテナ定義を辿ってみたの

    Dev Containersの始め方(1) : 仕組み編 | フューチャー技術ブログ
  • 時を駆けるモバイルアプリUI設計: 2007-2023の理論とトレンドを調べてみた | フューチャー技術ブログ

    ※この記事は、秋のブログ習慣2023の2目の記事となります はじめに2023年の秋、スマートフォンやタブレットは私たちの日常生活に欠かせない存在となっています。 これらのデバイスに対するアプリケーション開発の中でも、UI(User Interface)とUX(User Experience)設計の議論については欠かすことができません。 「UI」という単語は広範囲にわたる意味を持ちますが、今回は「モバイルアプリのUI設計」という文脈に焦点を絞り、その理論の歴史とトレンドについて調べてみました。 モバイルアプリのUI設計について優れた「モバイルアプリのUI」は、どのようなものがあるでしょうか? イメージしやすいものだと、以下のようなものがあります。 ボタンの色や配置がわかりやすい。ホームボタンであれば家の形をしていたり、検索ボタンでは虫眼鏡の形をしているなど タップしたときに何が起こるのか、

    時を駆けるモバイルアプリUI設計: 2007-2023の理論とトレンドを調べてみた | フューチャー技術ブログ
  • 実践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. 日語化 画面右上の🌏マークから選択します メニューが開く

    実践Drawio | フューチャー技術ブログ
  • 設計ドキュメント腐る問題、Git管理で運用してみた結果 | フューチャー技術ブログ

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

    設計ドキュメント腐る問題、Git管理で運用してみた結果 | フューチャー技術ブログ
  • LLM開発のためにMLOpsチームがやるべきこと | フューチャー技術ブログ

    はじめにこんにちは、SAIG/MLOpsチームでアルバイトをしている板野・平野です。 今回は「LLM開発のためにMLOpsチームがやるべきこと」というテーマで、従来のMLOpsとの違い・ツール・構成例等について調査・整理しました。 LLMとはLarge Launguage Model(大規模言語モデル)の略であり、ここでのLLM開発とは、「LLM自体の開発」および「LLMを活用したシステム開発」の両方を含むものとします。LLM開発のフローについては以前にLLM開発のフローで詳細を説明しているので、ぜひ併せてご覧ください。 まず、MLOpsとは「機械学習モデルの実装から運用までを円滑に推進するための手法や考え方」のことです。AIの社会実装が増えるに伴い、MLOpsチームを設ける企業も増えてきました。また、最近ではLLMやその関連技術が急速に発達してきており、今後LLMを用いたアプリケーション

    LLM開発のためにMLOpsチームがやるべきこと | フューチャー技術ブログ
  • LLM開発のフロー | フューチャー技術ブログ

    はじめにこんにちは、SAIG/MLOpsチームでアルバイトをしている板野・平野です。 今回は、昨今注目されている大規模言語モデル(LLM)の開発においてMLOpsチームがやるべきことを考えるため、まずはLLM開発の流れを調査・整理しました。 記事はその内容を「LLM開発のフロー」という題目でまとめたものです。LLMを番運用するときに考慮すべきこと、LLM開発・運用を支援するサービスやツール・LLMシステムの構成例などについては、「LLM開発でMLOpsチームがやるべきこと」と題して別記事でご紹介していますので、ぜひ併せてご覧ください。 ここでのLLM開発とは、「LLM自体の開発」および「LLMを活用したシステム開発」の両方を含みます。また、「LLM自体の開発」は学習フェーズ、「LLMを活用したシステム開発」は推論フェーズ、として記載しています。 記事ではLLM開発における各フェーズの

    LLM開発のフロー | フューチャー技術ブログ