タグ

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

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

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

    2024年版のDockerfileの考え方&書き方 | フューチャー技術ブログ
  • 個人的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選 | フューチャー技術ブログ
  • Testcontainersを用いてテスト実行前の docker compose up を無くし、Goで並列テストする | フューチャー技術ブログ

    Testcontainersを用いてテスト実行前の docker compose up を無くし、Goで並列テストする 春の入門祭り2024の1記事目です。 はじめにTIG真野です。 Testcontainers を用いて、単体テスト実行前に docker compose up -d 無しで、PostgreSQLにアクセスする単体テストを行う、入門記事です。 恩恵は次のような開発者体感の向上が個人的にあります。 テストを実行するうえで、別プロセスのサービスを起動しておく必要があるといった前提条件を考えなくても済むため、テストを行うビジネスロジックに集中できる docker compose up -d 打たないだけだが、テストに必要なコンテナを考慮しなくても済む 停止し忘れて、別のリポジトリの開発するときに混乱しなくても済む 並列テストしやすくなるので、テストの実行速度が向上する Goにおい

    Testcontainersを用いてテスト実行前の docker compose up を無くし、Goで並列テストする | フューチャー技術ブログ
  • 2024年Gitワークフロー再考 | フューチャー技術ブログ

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

  • 実践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 | フューチャー技術ブログ
  • Makefile覚書: Goアプリ開発に役立ちそうな基礎知識 | フューチャー技術ブログ

    はじめにTIG真野です。育休明けです。 フューチャー社内のタスクランナーはmakeやTaskなど複数の流派があり、チームによって使い分けられています。個人的にはmakeで良いんじゃないかと思っていますが、Taskも良いですよね。 makeは細かい記法をいつも忘れる+調べるとC言語向けの情報が出てきて脳内変換に手間を感じたため、makeを用いてWebバックエンドアプリをGoで開発するということをテーマに、役立ちそうな情報をまとめます。 なお、今記事におけるmakeは、GNU Makeを指します。バージョンは以下で動かしています。 MakefileのためのEditorConfigMakefileのインデントはハードタブである必要があります。誤りを防ぐためにもEditorConfigを設定しておくと良いでしょう。 makeは通常、Makefileという名称をデフォルトで認識しますが、同一フォルダ

    Makefile覚書: Goアプリ開発に役立ちそうな基礎知識 | フューチャー技術ブログ
  • Go 1.21 リリース連載 contextパッケージに追加されるWithoutCancelでクライアントとの切断に備えてみる | フューチャー技術ブログ

    Go 1.21 リリース連載 contextパッケージに追加されるWithoutCancelでクライアントとの切断に備えてみる はじめにこんにちは。TIG DX ユニット所属、金欠コンサルタントの藤井です。先日、Google Pixel 7aを購入しました。これまでiPhone 7 Plusを使っていたので、使用スマホの時代が7年ほど進みました。Googleは検索エンジンからAI、スマホまで作っていてすごいですね。 ということで今回は、Google発のプログラミング言語であるところのGoの1.21がリリースされることを記念した、Go 1.21 連載 の記事を書きます。 記事では、いくつか変更の入った、contextパッケージについて記載していきます。 contextそのものについては、フューチャー技術ブログにおいても数多く解説されていますので、詳細な説明は割愛します。数例記載しますので、

    Go 1.21 リリース連載 contextパッケージに追加されるWithoutCancelでクライアントとの切断に備えてみる | フューチャー技術ブログ
  • リアクティブプログラミングについて考える | フューチャー技術ブログ

    前回のエントリーで、コンポーネント単位のステートをがちゃがちゃ更新していくという、オブジェクト指向型(オブジェクトの境界がコンポーネント)の考え方から、より小さな状態のインタラクションになっていくよ、という話を紹介しました。 ビジネスロジックのアーキテクチャとしては、DDDには以下の2つが書かれています。 ドメインオブジェクト(オブジェクト指向) トランザクションスクリプト(手続き型) DDDはご存知のようにドメインオブジェクト押しなのですが、現実にはトランザクションスクリプトもよく使われますね。ただ、リアクティブな設計はこの2つとも違いますね。2つの要素A, Bがあって、Aの処理の結果を受けて処理Bを走らせる場合。だれがこの関連を知っているか、というところが違います。 オブジェクト指向だと、AがBを知っていて、AからBに通知します。「オブザーバーパターン」というのはありますが、あれも

  • 「実践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徹底入門 セキュアな認可システムを

    単体テストの考え方/使い方 の感想文 | フューチャー技術ブログ
  • データベースと向き合う決意 | フューチャー技術ブログ

    秋のブログ週間の9目のエントリーになります。この企画もこんなに書く人が出てくるように育っていいですね。 「中間層を増やして柔軟性を高めるのがソフトウェアの歴史」 これは大学時代に2つ上の先輩が言っていた言葉です。例えばマシン語を直接書くのではなく、アセンブラで書けば、変換(コンパイル)の手間はかかりますが、他のCPUへの移植はしやすくなります。高級アセンブラと名高いC言語を使えばさらに移植性は上がります。C言語で書かれたVMを使う言語、例えばJavaPythonRubyなんかはさらに移植性は上がります。 ストレージもそうです。最終的にストレージはビット列を保存するものですが、それにOSのファイルシステムというレイヤーがあり、そこにスキーマで管理されたデータを入れるDBMSが乗っかり、SQLなどの問い合わせ言語でデータ取得できるようにします。DBMSを挟むことで、レプリケーションでバッ

    データベースと向き合う決意 | フューチャー技術ブログ
  • PlantUMLのテーマ(思わぬ展開) | フューチャー技術ブログ

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

    PlantUMLのテーマ(思わぬ展開) | フューチャー技術ブログ
  • ファイルダウンロード完全マスター | フューチャー技術ブログ

    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

    ファイルダウンロード完全マスター | フューチャー技術ブログ
  • 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便利ツール(新人さん向け) | フューチャー技術ブログ
  • Goを学ぶときにつまずきやすいポイントFAQ | フューチャー技術ブログ

    他の言語になれた人が、初めてGoを書いた時にわかりにくいな、と思った部分はどのようなところがあるのか、難しいポイントはどこか、という情報を自分の経験や、会社の内外の人に聞いたりしてまとめてみました。まだまだたくさんあるのですが、多すぎるのでまずはこんなところで。コンテナで開発することがこれからますます増えていくと思われますし、その時にコンテナとの相性が抜群なGoをこれから使い始める人もどんどん増えていくと思います。 Goは特に言語のコアをシンプルに、何かを実現するときはそのシンプルな機能を組み合わせて実現しよう、というコンセプトです。つまり、他の言語で実現したいこと・できていることに比べて、Goは組み合わせ(イディオム)でカバーする領域が広くなります。そのあたりのとっかかりになる情報を提供することが、これからGoを触る人にとってつまずきを減らすことになると思います。 Go Conferen

    Goを学ぶときにつまずきやすいポイントFAQ | フューチャー技術ブログ
  • Goのおすすめのフレームワークはnet/http | フューチャー技術ブログ

    僕としてはGoのおすすめのフレームワークを聞かれたら、標準ライブラリのnet/httpと答えるようにしています。というよりも、Goの他のフレームワークと呼ばれているものは、このnet/httpのラッパーでしかないからです。 Goでアプリケーションを作成する場合のイメージは次の通り。battery includedなアプローチは他の言語でもたまにありますが、ついてくる機能が今時のものが多くて、標準ライブラリで済むことが多いです。ウェブ開発についてもそんな感じです。 PythonとかRubyとかもそうですが、言語組み込みのウェブサーバー機能はテスト用で番運用には機能が足りない、性能が足りない、ということから「プロダクションに耐えうるフレームワークを別に入れないと」と思う人も多いんじゃないかな、と思いますが、Goの場合は組み込みのサーバーで問題なかったりします。Node.jsに近いかも? 世間

    Goのおすすめのフレームワークはnet/http | フューチャー技術ブログ
  • Goの構造体の使われ方の設計 | フューチャー技術ブログ

    Goで構造体を設計する場合、オブジェクト指向的な「型ごとの責務の分担」以外に、「どのように使われるものか」を考える必要があります。 ポインタで扱うのか? 値として扱うのか? 両方許可するのか? 値として扱える場合にimmutable(変更不可能)なオブジェクトとするのか、mutable(変更可能)なオブジェクトとするのか 値として扱える場合にゼロ値での動作を補償するかどうか 他の言語で言うと、C#の構造体とクラスの違い、C++のデフォルトコンストラクタあたりに頭を悩ませたことがある人にはおなじみかもしれませんが、Goでもいくつか考慮が必要になります。 ポインタ型として扱う必要があるケースまず最初に決断できる方針としては、ポインタ型でのみ扱うかどうかです。 内部にスライスやmap、ポインタなどの参照型な要素を持っていれば、基的にポインタ型でのみ扱う構造体になります。これらの要素を持っていた

    Goの構造体の使われ方の設計 | フューチャー技術ブログ
  • Goのデバッグ環境 on VSCode | フューチャー技術ブログ

    はじめにこんにちは。TIG/DXユニットの富山です。 私の使用するテキストエディタはVim一択でしたが、最近はVSCode浮気気味です(言わずもがな Vimプラグインは入れています) 今回はVSCodeGo言語用のデバッグ環境をテーマします! 環境構築前提条件: VSCodeがインストール済であること Goがインストール済であること Step 1:プラグインのインストールGoogleが公開しているVSCode用のGoプラグインである、Go for Visual Studio Codeをインストールします(2020年6月に開発管理がMicrosoftからGoogleGo開発チームへ移管されました)。 インストールが終わったら、Goプラグインに必要な各種ツールをインストールしていきます。 コマンドパレットを開く(Windows: Ctrl + Shift + p / Mac: Comma

    Goのデバッグ環境 on VSCode | フューチャー技術ブログ
  • 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言語

    GoでWebアプリ開発時にあるあるだったレビューコメント | フューチャー技術ブログ
  • スケーラブルデータベース ~クラウドにおける後悔しないデータベース選定~ | フューチャー技術ブログ

    はじめにエンタープライズでのミッションクリティカル領域においてもクラウド利用が普通になってきています。 その過程において今までできないことを指向する試みも行われてきています。その代表的なものがクラウドの備えるリソースの高い拡張性と弾力性を利用したシステム展開です。例えば「より多くのデータを扱う」「同業他社に向けたサービス展開をする(マルチテナンシー)」といったものがあります。その際のアーキテクチャ選定では将来の利用を想定した選択を行う必要がありますが、データベースのスケールというのは非常に難しく簡単ではありません。 各種の要件に応じてデータベースを選定するということは多く行われていますが、その中で一番考え方が難しいスケーラビリティにどう立ち向かうかについて記載していきます。データベースについては全ての要件を満たせる「万能」なアーキテクチャが存在しないのが実情です。そのためスケーラビリティを

    スケーラブルデータベース ~クラウドにおける後悔しないデータベース選定~ | フューチャー技術ブログ