タグ

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

  • 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開発のフロー | フューチャー技術ブログ
  • Playwright連載始まります | フューチャー技術ブログ

    E2Eフレームワークとして高い人気を誇ってきたのがCypressです。使いやすいテストランナー、わかりやすいテスト結果、TypeScriptの組み込みサポート、プラグインによる拡張、(Seleniumと比較して)高速な実行などを提供しています。フューチャー社内でも使っているプロジェクトがいくつもあり、過去にCypress連載をブログ上で行い、それがきっかけとなってSoftware Designに連載も行いました。 一方で、現在人気が高まりつつあって、Cypressを追い抜こうとしているのがPlaywrightです。かなりCypressを意識して機能追加を行なってきている印象があります。現時点では特徴的なタイムトラベルデバッガー(過去の履歴すべてを保持しておいて気軽に前後DOMの状態を比較したりできる)、スクリーンショット、どちらもExperimentalなコンポーネントテストなど、できるこ

    Playwright連載始まります | フューチャー技術ブログ
  • Minikubeでk8s学習を進めるためのヒント | フューチャー技術ブログ

    k8s学習環境が欲しいこんにちはTIG鈴木です。 以前チームの輪読会でKuberntes完全ガイド(以下k8s)を読みました。 k8sは、GKEを例にしながら、k8sのCLIツールだったりマニフェストのyamlファイルを丁寧に紹介しており、実践的に勉強するの適しています。 そのため、手を動かしつつ勉強したいところですが、クラウドプロバイダーが提供するマネージドk8sはコストが高めで気分的にほいほい使えないところがあります。となるとローカル環境でk8sを用意したくなります。 k8s完全ガイドではminikubeだったりkindだったりが紹介されています ローカル環境もそれなりにめんどくさいところがminikubeだとGKEとは使い勝手が違っていて、k8s通りに検証できない部分があり、初学者の私は混乱してしまいました。 ということで、私がひっかかったポイント(おもにServiceまわり)

    Minikubeでk8s学習を進めるためのヒント | フューチャー技術ブログ
  • TetragonでeBPFとセキュリティオブサーバビリティ入門 | フューチャー技術ブログ

    CNCF連載 の4目です。 はじめに数年前にクラウドネイティブ注目技術として挙げられたeBPFにかねてよりキャッチアップしたいなと思っていたので、この連載のタイミングでeBPFとその関連プロダクトに入門してみることにしました。 CNCFプロジェクト傘下のeBPFを活用したプロダクトとしてはCilium, Falcoなどが挙げられます。CiliumはKubernetesなどのクラウドネイティブな環境でネットワーク、オブサーバビリティの機能を提供するOSSなのですが、今回はそのいわばサブプロジェクト的な位置づけのセキュリティツールである、Tetragonに触ってみます。 Cilium, Tetragonの開発をメイン行っているIsovalent社は、書籍やハンズオンラボなどで自社の製品・eBPFについての学習リソースを多く提供しています。 https://isovalent.com/reso

    TetragonでeBPFとセキュリティオブサーバビリティ入門 | フューチャー技術ブログ
  • AWS Kinesisから呼び出されるLambdaのリカバリー処理について | フューチャー技術ブログ

    はじめにTIGの原木です。 最近、AWS Kinesis Data StreamとAWS Lambdaを組み合わせたデータストリーミングを扱うシステムで、Lambdaが処理に失敗した場合のリカバリー運用を考える機会がありました。 一般的に、Kinesisのようなメッセージングやイベント駆動型のシステムでは、DLQ(デッドレターキュー)という仕組みを設けます。DLQの目的は、メインアプリケーションが障害やバグにより正常に動かなかった場合、未処理のメッセージやイベントを、メインシステムとは”別口の”キューに隔離、保存することです。これにより、運用者はシステムデータのリカバリーを安全に行うことができます。 記事では、KinesisとLambdaを組み合わせて使用する際に、DLQとしてDestinationsを使用したフェールセーフ機能を構築した際の知見を共有したいと思います。 3行まとめ La

    AWS Kinesisから呼び出されるLambdaのリカバリー処理について | フューチャー技術ブログ
  • 書籍紹介:大規模データ管理(エンタープライズアーキテクチャのベストプラクティス) | フューチャー技術ブログ

    最近読んだ書籍の中で非常に良質な内容でしたので紹介したいと思います。少しでも多くの方に興味を持ってもらえることを期待しています。 O’Reilly Japan はじめに私自身がデータ管理(データマネージメント)という観点でここ数年様々な検討を行ってきていますので前提としてその背景について簡単にまとめてみます。 かつてオンプレミスで運用を行っていた時は企業内のデータは完全に管理されていました。データウェアハウスを導入してデータの集約・加工は行われていましたが、専門チームがデータ仕様確認やデータ提供までもすべての責任を担っていました。品質は高いのですが利用者からの要望(新しいデータの提供、仕様の変更)の対応についてはスピード大きな制約がありました。また大規模なデータを扱うためには多大なコストが必要という制約もあります。 クラウド技術による「スモールスタートを可能とするインフラ」「大規模なデータ

    書籍紹介:大規模データ管理(エンタープライズアーキテクチャのベストプラクティス) | フューチャー技術ブログ