タグ

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

  • 2024年版のDockerfileの考え方&書き方 | フューチャー技術ブログ

    最近はお客さんとの勉強会でDockerのドキュメントをつまみいして読むというのをやっていますが、改めて最新版を読んでみて、いろいろ思考が整理されました。2020年の20.10のマルチステージビルドの導入で大きく変わったのですが、それ以前の資料もweb上には多数あり「マルチステージビルドがよくわからない」という人も見かけるので過去の情報のアンラーニングに使っていただけるように改めて整理していきます。 仕事Pythonコンテナをデプロイする人向けのDockerfile (1): オールマイティ編で触れた内容もありますが改めてそちらに含む内容も含めて書き直しています。 エントリーの執筆には@tk0miya氏から多大なフィードバックをいただきました。ありがとうございます。 基的なメンタルモデル現代的な使い方を見ていくために「Dockerを使ってビルドする」というのはどのようなものか考えを整

    2024年版のDockerfileの考え方&書き方 | フューチャー技術ブログ
  • 署名付きURLを利用したファイルアップロードWeb API設計の勘所 | フューチャー技術ブログ

    はじめに現代のWebアプリケーションにおいて、ユーザが写真や動画などのファイルをアップロードする機能は、しばしば求められます。 記事では、ファイルアップロードを実現するための一手段として、「署名付きURL」を利用した方式を取り上げ、その設計について詳しく解説します。 今回は、Amazon Web Services(AWS)を利用する前提のもと、このアプローチを探求していきます。 前半部分は署名付きURLをそもそもよく知らない方向けの導入部となっていますので、要点だけ抑えたい方は設計上のポイントから読まれることをお勧めします。 ファイルアップロードの実現方式パターン署名付きURLの話をする前に、ファイルアップロード機能をWeb APIとして実現する方式について、いくつか代表的なものを紹介します。 Pattern 1. multipart/form-datamultipart/form-da

    署名付きURLを利用したファイルアップロードWeb API設計の勘所 | フューチャー技術ブログ
  • 個人的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選 | フューチャー技術ブログ
  • Gitのブランチの役割を考える | フューチャー技術ブログ

    Gitのブランチ戦略にはいくつかあります。 Gitフロー GitHubフロー GitLabフロー チームの戦略を考えるときにどれかを参考にしつつカスタマイズするときにいろいろ不都合が生じてしてきて複雑になってしまうことってありますよね? 社内でブランチの管理の議論をする中で、ブランチの役割を明確にした上で、どのブランチがどのような役割を持っているのかを明確にした方が混乱が少なくなるのではないか? というのを考えていました。 特に、プロジェクトごとに同じ名前でも役割が違うなー、というのとかもあり、ブランチ名=役割ではなく、ブランチの上位概念として役割を考えて、それを実際のブランチとの対応づけを行う必要があるのではないかな、と。 CI/CDと組み合わされることで、releaseブランチ==ステージング環境となってしまい、ステージング環境を使いたいリリース前のブランチと、ホットフィックスの検証の

    Gitのブランチの役割を考える | フューチャー技術ブログ
    s_ryuuki
    s_ryuuki 2024/06/12
  • 2024年Gitワークフロー再考 | フューチャー技術ブログ

    春の入門祭り2024の2記事目です。 Gitは、出自としては1週間で作られたLinuxカーネルのための分散バージョン管理システムでした。当時のワークフローに合わせてパッチをテキスト化してメールに添付できるような機能だったりが備わっています。 一方で、現代のGitは、デファクトスタンダードなバージョン管理システムになりLinuxカーネル以外のアプリケーション開発で利用されています。分散バージョン管理ではあるものの、サーバー・クライアント型の使われ方をしていて、GitHubGitLabを核にして、ローカルで作ったブランチをpushして、Pull Requestの形にして管理しています。少なくとも周りで見る限りでは、それ以外の使われ方の方が少なくなってきてます。そんなこんなで求められている使われ方が変わってきていて、それに合わせた機能がぼちぼち増えています。それを活用することで、ウェブ画面上で

    s_ryuuki
    s_ryuuki 2024/04/11
  • 龍が如く7のすごいテストをなぜ我々は採用できないのか | フューチャー技術ブログ

    僕自身は龍が如くシリーズは、クロヒョウ2、極1、極2、0、3、4、5、6、0とやって、7はRPGだし主人公違うしなぁと思って、買うだけ買って後でやろうと積んでいたところ、CEDECのすごいテストの話を聞いて、(オリジナル版を積んでいたのに)インターナショナル版を買って始めてしまうぐらいインパクトがあり(そして積んでたのを後悔したぐらいよかった)ました。それ以降、維新極、7外伝、8は発売日に買ってプレイしてます。 こちらにその講演の詳細なレポートがこちらにあります。 https://www.famitsu.com/news/202009/11205564.html その8の発売前に龍が如くスタジオの技術責任者の方がXのアカウントを開設して、C++のコードを投稿されていたのですが、それに対してエンプラ開発目線で意見しているようなツイートを見かけて、「いや、システムの特性全然違うから」と思い筆を

    龍が如く7のすごいテストをなぜ我々は採用できないのか | フューチャー技術ブログ
  • 設計ドキュメント腐る問題、Git管理で運用してみた結果 | フューチャー技術ブログ

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

    設計ドキュメント腐る問題、Git管理で運用してみた結果 | フューチャー技術ブログ
  • 初めてのセキュリティ情報収集(mjckeck4) | フューチャー技術ブログ

    こんにちわ。Cyber Security Innovation Group(CSIG)の井上です。 部門名の通り、サイバーセキュリティに関する部署で、セキュリティコンサルティングやFutureVuls( https://vuls.biz )という脆弱性対策サービスのコンサルティングやサポートをしています。 初めに春の入門祭り2023 という事で、初めて脆弱性対応をする方に向けた記事を書いてみようと思います。 この時期になると、部門移動等で情報システム部に移動し「何をやっていいのか分からない…」という話も時々聞きます。 今回は、IPAの「mjcheck4」( https://jvndb.jvn.jp/apis/myjvn/mjcheck4.html )というツールを使った、セキュリティ情報の収集についてお話しようと思います。 セキュリティ情報収集とは世の中にはセキュリティ情報はいろいろありま

    初めてのセキュリティ情報収集(mjckeck4) | フューチャー技術ブログ
  • markdownlintで設計書の品質を高める | フューチャー技術ブログ

    はじめにフューチャー技術ブログのリレー形式の連載である、春の入門祭り2023の1日目です。TIG真野です。 ここ数年、Markdown設計書をチームで書き、GitHubGitLab)上でレビューするフローを採用しています。なるべくテキストベースで設計開発フローを統一するため、私の所属するチームでは以下のようなツールを採用しています。 シーケンス図、業務フロー図 Markdown中にPlantUMLで記載 参照はGitHub上からも見れるように、pegmatite を利用 システム構成図など画像系 Diagrams.netdraw.io)で作成し、.drawio.png の拡張子でMarkdownから参照 これだけは目視で差分チェックとなる Web API定義 OpenAPI SpecのYAMLファイル 参照はGitHub上からも見れるように、swagger-viewer を利用 ER

    markdownlintで設計書の品質を高める | フューチャー技術ブログ
  • 究極の?トランザクションスクリプト用言語Verse | フューチャー技術ブログ

    Unreal Engineで有名なEpic Gamesが、現在開催中のGDC(Game Developer Conference)でVerseの詳細を解説しており、その動画が公開されています。 ドキュメントもすでに公開されています。 https://dev.epicgames.com/documentation/en-us/uefn/verse-language-reference 現在処理系は、Unreal Editor for Fortnite(UEFN)の中に組み込まれているようですが、Windowsにしか対応していません。ちょろっと動かした程度で、まだコードをしっかり書いてはなくて、プレゼンを見た感想で書いているので、いろいろ間違ったところとかもあるかもしれませんが、そういうのはご指摘いただいたり、Pull Request(ブログの上の鉛筆アイコンで送れます)を出してもらえれば、と

    究極の?トランザクションスクリプト用言語Verse | フューチャー技術ブログ
  • データライフサイクルとトレードオフ | フューチャー技術ブログ

    ソフトウェアの中身を大きく2つに分解すると、プログラムとデータに分かれます。コードコンプリートやA Philosophy of Software Designなど、評判の良いソフトウェア設計のはいくつかありますが、それらはどれもプログラムの説明がメインでデータのライフサイクルについての説明はなかったと思います。しかし、データの表現にもいくつもの方針があって、それによるトレードオフがあるな、というのはもやもやと考えていたので、その考えをまとめて文章にしてみました。 データといっても、処理中の短期間の間では変わらない、いわゆるマスターデータ的なデータです。ジャーナルというか、トランザクション的なデータはここでは触れません。 この記事では、それぞれのトレードオフについて考えていきます。 即値(リテラル) 定数 コマンドライン引数 環境変数 設定ファイル ダウンロードコンテンツ オンラインデータ

    データライフサイクルとトレードオフ | フューチャー技術ブログ
  • 「実践Redis入門」所感 ~「E.G.コンバット」の観点から語る~ | フューチャー技術ブログ

    積読を消化しようというテーマの、読書感想文連載 の2冊目です。 導入『自分たちは、クラウドネイティブじゃなくてマネージドネイティブなんだよ…』 TIGの原木です。 最近、冒頭のような開発者の嘆きを人づてに聞く機会があり、今も脳裏に残り続けています。 昨今のITシステムにおいて、クラウドサービスは欠かせないものとなっています。しかしユーザー、そして開発者として大きな利便性を享受する裏で、クラウドサービスによって巧妙に隠蔽された裏のソフトウェアを意識する機会は減り続けているのではないでしょうか? Webサービスにおいて、RedisやMemcachedに代表されるキャッシュサーバーもそのようなソフトウェアの1つです。 キャッシュサーバーは、Webアプリケーションなどデータの読み込みや保存を効率化するために欠かせない存在ですが、同じデータストアであるRDBMSなどと比較していま一歩隠れた存在だと思

    「実践Redis入門」所感 ~「E.G.コンバット」の観点から語る~ | フューチャー技術ブログ
  • 単体テストの考え方/使い方 の感想文 | フューチャー技術ブログ

    はじめにTIG EXU真野です。 積読を消化しようというテーマの、読書感想文連載 の1冊目は、単体テストの考え方/使い方 です。 書籍の基礎情報です 2022年12月28日発売 Unit Testing Principles, Practices, and Patterns の翻訳書。原著は2020年1月14日に発売 テーマ 質の高いテストを行い、ソフトウェアに価値をもたらそう!単体(unit)テストの原則・実践とそのパターン プロジェクトの持続可能な成長を実現するための戦略 単体テストの原則・実践とそのパターン コード例は C# であるものの、どの言語でも適用できる汎用的な内容とのこと 中を見ると、微妙にC#特有ぽいところに1箇所悩みましたが、それ以外はその通り 翻訳者の須田さんは、他にもセキュア・バイ・デザイン: 安全なソフトウェア設計 やOAuth徹底入門 セキュアな認可システムを適

    単体テストの考え方/使い方 の感想文 | フューチャー技術ブログ
  • パスワードレス技術の現状と未来について | フューチャー技術ブログ

    はじめにこんにちは。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

    AGPLを理解する: もっとも誤解されたライセンス | フューチャー技術ブログ
  • Redisのジオメトリ機能 | フューチャー技術ブログ

    地図・GIS・位置特定に関する連載の4日目のエントリーです。最初はブラウザの座標を取得するAPIとか、IPアドレスから場所を推定するGeoIPを使って、近い場所の人を探すサービスでも作ってみようかと思っていました。Quad-Treeみたいなゲームでよくある座標系を収めるデータ構造を使って、近くのメンバーを探す機能とかを作ろうと思っていましたが、ふと「座標系をそのまま格納して検索できるデータベースとかありそうだな」と思って調べたところRedisがヒットして横道にそれてしまったのでそのまま横道を突き進んでみました。 Redisは2010年ぐらいに有志でドキュメント翻訳したりしたりして、チョットワカル程度でしたが、久々にドキュメントを見ていたら座標情報を保持したり検索したりするコマンドが増えていました。その辺りを少し調べてみました。 Redisのジオメトリ機能Redisのジオメトリ関係のコマンド

    Redisのジオメトリ機能 | フューチャー技術ブログ
  • ドメイン駆動設計の源流のPofEAAを読んでみる | フューチャー技術ブログ

    最近、ドメイン駆動設計(以下DDD)とかそのあたりを読みこんでいる人から、DDDの読み方を教えてもらいました。ここではDDDはエリック・エヴァンスのドメイン駆動設計の方を参照しました。 @katzchang さんから教わったのは「DDDはパターンランゲージの形式を意識してるよ」ということでした。ただし、きちんとしたパターンランゲージの形式になっておらず、記述が著者のものになってるので、読者は注意して読む必要があるのかもとのことです。 @ryoaitaさんから教わったのは「DDDはエンタープライズアプリケーションアーキテクチャパターン(以下PofEAA)を下敷きにしているだよ」ということでした。 DDDももう時代的にはかなり古いです。自分で読んだ限りは全然好きになれなくて、でもきっと何かあるはずだと3-4冊読んでみましたが感想は変わらずでした。ユビキタス言語も「当たり前のものを先頭に

    s_ryuuki
    s_ryuuki 2022/06/17
  • Future社員が使っているWindows便利ツール(新人さん向け) | フューチャー技術ブログ

    はじめにこんにちは。2020年4月入社の青柳です。タイトルにある通り便利ツールをまとめてみました。 今回は、新入社員や入社前の大学生をターゲットに、誰でもすぐに使えるツールを紹介しているので、まだ使っていないツールがあればぜひ使ってみて下さい。 ※前提としてwindowsの方向けなので、Macの方はごめんなさい🙇🏼 everything https://forest.watch.impress.co.jp/library/software/everything/ ファイルやフォルダを超高速で検索できるツール。 あのファイルどこにあったっけ??の問題が一瞬で解消できます。私も初めて使った際は、検索のスピードの早さに驚きました。 しかも設定すればファイルサーバーの中も検索できます。 もはや必須ツールですね。 cribor https://forest.watch.impress.co.jp

    Future社員が使っているWindows便利ツール(新人さん向け) | フューチャー技術ブログ
  • JSレスBootstrapなdaisyUIの秘密 | フューチャー技術ブログ

    使い方は、CSSのクラスにちょっと書き足すだけで動きます。使い勝手はBootstrapみたいですね。ドキュメントが検索しやすくて、サンプルが豊富で、シンプルに書かれているので、フロントエンドが苦手でCopy And Paste from Stack Overflowな人にも使いやすいと思います。 <button class="btn">neutral</button> <button class="btn btn-primary">primary</button> <button class="btn btn-secondary">secondary</button> <button class="btn btn-accent">accent</button> <button class="btn btn-ghost">ghost</button> <button class="btn b

  • PlantUMLのテーマ(思わぬ展開) | フューチャー技術ブログ

    秋のブログ週間連載の7目です。 はじめにPlantUMLで使えるテーマについてのご紹介です。 以前、チームで機能設計するためのPlantUML標準化の記事でも書かせていただきましたが、PlantUMLのデフォルトカラーって少しドライですよね。 色の好みは人それぞれで、あれはあれでカッコよさはありますが、複雑な図は少しでも可愛く描きたい・楽しく見たいものです。 この記事ではPlantUMLのテーマについて、いくつかのオプションを紹介していきます。「PlantUMLの色を変えてみたい!」という方は是非ご活用いただければ嬉しいです。 前提 PlantUMLでは、skinparamを利用して図のビジュアル各要素を定義しますが、「テーマ」はskinparamの集合体です この記事ではテーマの作り方や、各運用方法等については触れません この記事で紹介するオリジナルテーマはシーケンス図のために作られた

    PlantUMLのテーマ(思わぬ展開) | フューチャー技術ブログ
    s_ryuuki
    s_ryuuki 2021/11/09