2024年版のDockerfileの考え方＆書き方 | フューチャー技術ブログ
最近はお客さんとの勉強会でDockerのドキュメントをつまみ食いして読むというのをやっていますが、改めて最新版を読んでみて、いろいろ思考が整理されました。2020年の20.10のマルチステージビルドの導入で大きく変わったのですが、それ以前の資料もweb上には多数あり「マルチステージビルドがよくわからない」という人も見かけるので過去の情報のアンラーニングに使っていただけるように改めて整理していきます。 仕事でPythonコンテナをデプロイする人向けのDockerfile (1): オールマイティ編で触れた内容もありますが改めてそちらに含む内容も含めて書き直しています。 本エントリーの執筆には@tk0miya氏から多大なフィードバックをいただきました。ありがとうございます。 基本的なメンタルモデル現代的な使い方を見ていくために「Dockerを使ってビルドする」というのはどのようなものか考えを整
ダイアログもアラートも、Reactで子コンポーネントの開閉管理を実装する | フューチャー技術ブログ
Reactでは、画面に関わる表示の制御はかならず何かしらのステート管理を行いそれで行います。ダイアログの場合は開閉をuseState()で作ったフラグで管理するみたいな感じです。 たとえば、ウェブブラウザのJavaScriptから呼べるalert()やconfirm()は、関数を呼び出せばダイアログが表示されますし、ダイアログが閉じたら処理が戻ってきます。confirm()ならユーザーが選択したものと一緒に返ってきます。標準の<dialog>タグが今時ですが、このタグはDOMインスタンスのshowModal()やshow()メソッドを呼ぶ必要があります。命令志向ですね。 一方、Reactでダイアログを実装する場合を考えます。メソッド呼び出しが直接扱えればシンプルですが、Reactでは基本的にステート管理でやりましょう、というのが流儀です。useImperativeHandle()を使うとか
全文検索エンジンMeilisearchを試す | フューチャー技術ブログ
はじめにこんにちは、TIGの岸本卓也です。 春の入門連載2024 の3番目です。 ある静的サイトジェネレーターで生成された膨大なドキュメントの検索において、全文検索機能はあるものの以下の課題を感じることがありました。 探したいものがヒットしないことがあるどこがヒットしているのか謎なものが検索結果に含まれることがあるクライアントサイドで動くため、ページ読み込み時に数十MBと大きいことも多いインデックスファイルをダウンロードするため、ページの読み込み完了が遅い原因になっている検索にヒットしない場合は、欲しい情報がありそうなページをリンクから辿って個別に探すしかないのです。しかしこれは手間です。 このような課題を解決すべく新たな全文検索エンジンを探す中でMeilisearchという製品を見つけました。Meilisearchは日本語の検索においても良さそうでかつ手軽に試せたので、試した内容を紹介し
lib/pq から jackc/pgx への移行 | フューチャー技術ブログ
ライブリッツの筒井です。 GoのORマッパー連載、おまけ記事です。 特に示し合わせた訳では無いのですが、RDBは全員がPostgreSQLを使っていましたね。 さて、今回の連載記事のいくつかでも言及されていた、jackc/pgx について簡単に紹介します。 GoとPoatgreSQLでCOPY GORM v1 と v2 のソースコードリーディングしてみた GoでのPostgreSQLドライバは lib/pq が定番でしたが、現在その開発は消極的で今後機能が追加されることはめったに無いそうです。 https://github.com/lib/pq#status 一方 pgx は現在も活発に開発がなされており、GORM v2にも採用されています。 使い方の比較lib/pq （およびdatabase/sql）と pgx の使い方を比較していきます。 pgxはドライバだけでなく database/
Testcontainersを用いてテスト実行前の docker compose up を無くし、Goで並列テストする | フューチャー技術ブログ
春の入門祭り2024の1記事目です。 はじめにTIG真野です。 Testcontainers を用いて、単体テスト実行前に docker compose up -d 無しで、PostgreSQLにアクセスする単体テストを行う、入門記事です。 恩恵は次のような開発者体感の向上が個人的にあります。 テストを実行するうえで、別プロセスのサービスを起動しておく必要があるといった前提条件を考えなくても済むため、テストを行うビジネスロジックに集中できるdocker compose up -d 打たないだけだが、テストに必要なコンテナを考慮しなくても済む停止し忘れて、別のリポジトリの開発するときに混乱しなくても済む並列テストしやすくなるので、テストの実行速度が向上するGoにおいて、複数のパッケージを同時にテストするとき、 -p 1 で絞らずに済むTestcontainers とはhttps://test
管理画面等でNext.jsをBetter Reactとして使う | フューチャー技術ブログ
最近、Next.jsが複雑になりすぎて、単なるウェブ画面を作る用途にはNext.jsは重すぎるので別のものが良いとか、Vercel統合のための機能が多いんでしょ、みたいな感想を見かけることが増えた気がします。特に管理画面とか社内システムとかですね。B2Cでも設定画面系とかは当てはまるかもしれません。 ホンダ時代に、タイプRを買っても実際にサーキットとかに走らせに行く人は1/10ぐらい、という話を聞いた気がしますが、必ずしも、そのすべてのパフォーマンスを引き出さないのはダメとかなくて、単にかっこいいからとか、一部のメリットでも自分にあえば良いのです。 Next.jsも、たくさん機能がありますが、ミニマムな使い方もできます。 ほぼNext.jsの機能をオフにした使い方たぶんNext.jsを最低限で使うライン・メリットはここかな、と思います。 基本的に全部CSR(Client Side Rend
高校生だけじゃもったいない 仕事に役立つ新・必修科目「情報Ⅰ」のレビューに参加しました | フューチャー技術ブログ
秋のブログ週間2023、4週目・16本目の記事です。 中山心太氏の最新作、高校生だけじゃもったいない 仕事に役立つ新・必修科目「情報Ⅰ」のレビューに参加し、お礼に献本をいただきました。ありがとうございました。読んだ感想としては発表されたタイミングでツイートしたのがそれにあたります。結構レビューではがんばってコメントを入れました。レイアウトの都合で入りません、と言われたものもいくつかあったのですが、その反映されなかったコメントも交えて本書の紹介をしようと思います。 レビューに参加しました！単に教科書をなぞるだけじゃなくて、ところてん節がところどころにあって、社会人であっても、ITの専門家でなくても、リテラシーとしてITが何をできるのかというのを身につける大切さが書かれています。面白かったです。 https://t.co/tOUBpGiPtN — 渋川よしき (@shibu_jp) Octob
実践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. 日本語化 画面右上の🌏マークから選択します メニューが開く
Makefile覚書: Goアプリ開発に役立ちそうな基礎知識 | フューチャー技術ブログ
はじめにTIG真野です。育休明けです。 フューチャー社内のタスクランナーはmakeやTaskなど複数の流派があり、チームによって使い分けられています。個人的にはmakeで良いんじゃないかと思っていますが、Taskも良いですよね。 makeは細かい記法をいつも忘れる＋調べるとC言語向けの情報が出てきて脳内変換に手間を感じたため、makeを用いてWebバックエンドアプリをGoで開発するということをテーマに、役立ちそうな情報をまとめます。 なお、今記事におけるmakeは、GNU Makeを指します。バージョンは以下で動かしています。 MakefileのためのEditorConfigMakefileのインデントはハードタブである必要があります。誤りを防ぐためにもEditorConfigを設定しておくと良いでしょう。 makeは通常、Makefileという名称をデフォルトで認識しますが、同一フォルダ
Mermaid.jsをReact上でレンダリングする | フューチャー技術ブログ
テキストで書いた情報をもとにダイアグラムを作成するツールがいくつかあります。有名どころだとGraphviz、Mermaid.jsや、PlantUMLがあります。このうち、GitHubでも対応して、テキストで書いても絵が見えるので今後が利用が大きく伸びそうなのがMermaid.jsです。 Mermaid.jsをReactで表示しようとしたものの、Reactラッパーとしてnpmに公開されているものがどれも古くてメンテナンスされていなそうという問題がありました。この手のアダプター系のライブラリはどうしてもメンテナンスがされなくて放置されるのが早くなりがちです。脆弱性が残り続けたりします。また、もう1つ、Reactのバージョンポリシーが変わって、0.1, 0.2, 0.3…0.14だったのが、突然15, 16, 17, 18となったのも問題を加速しています。メンテされないライブラリがReactのバ
【エネルギー業界】電力基礎知識編 | フューチャー技術ブログ
電力自由化とは戦後の電力不足から、高度成長を達成するために、大手電力10社1（一般電気事業者）による「発電」から「送配電」、需要家2への「小売」までの地域独占を認めてきていましたが、環境の変化に伴い、電力事業の高コスト体質が問題視されるようになり、段階的に、より公平に競争し、かつ安定供給にも平等に責任を負う状態（自由に電力会社を選べる状態）へと変化してきました。 以下に、「１．電気事業法改正」、「２．電力システム改革」の大きく２段階に分けて、電力自由化までの流れを記載します。 １．電気事業法改正 一般電気事業者に対して、新規参入者のシェアを増やすことを目的とした改革 （１）発電の自由化（1995年） 独立系発電事業者（IPP=Independent Power Producers）として、「発電」への参入が可能となる （２）大規模需要家への電力供給自由化（1999年） 特定規模電気事業者（
gRPCのGo実装の新星、Connect | フューチャー技術ブログ
サービス間通信とIDL（インタフェース記述言語）連載の2日目のエントリーです。 本当はGraphQLネイティブなデータベースの紹介をしようとしたのですが、紹介しようとしていたものがまだベータでクライアントライブラリが公開されていない（空っぽのリポジトリしかない）みたいな感じで試せなかったので、急遽2022/6/1に公開されたばかりのgRPC関連のライブラリのConnectを紹介することにしました。 Connectの開発元が公開したブログは次のサイトにあります。 Buf | Connect: A better gRPC 公式ドキュメントはこちらです。 Introduction | Connect なお、gRPCについての詳細はこのエントリーでは紹介しません。ちょうど、H.SakiさんがgRPCの詳しい紹介の記事を書いてくれているので、ぜひ、みなさんこちらを参照ください。 作ってわかる！ はじ
初めてのGCPで環境構築してハマったこと | フューチャー技術ブログ
はじめにお仕事でGCP使って環境を構築することがあったのですが、色々とハマることが多かったので供養を兼ねて共有したいと思います。 当時の私の経験値としては「AWSの一部サービスは触ったことがある」程度でクラウド環境を下地から構築するのは初めての経験でした。一度触ってみれば常識だよねって内容が多いですが、初心者が小石につまずいてもすぐに立ち上れるようになれば幸いです。 今回構築した環境の概要 既存のオンプレ環境との共存を前提とし、使えるアドレス範囲もオンプレのNWから払い出し オンプレ環境とインターネットVPNでつなぐプロジェクトは1つ（ホストプロジェクト） 各環境（production、staging・・）は共有VPCで接続（サービスプロジェクト） なお、構築はTerraform, Ansibleで行いました。 GCPで環境構築してハマったこと本編です。 カテゴリ別に記載しています。 1.
PlantUMLのテーマ（思わぬ展開） | フューチャー技術ブログ
秋のブログ週間連載の7本目です。 はじめにPlantUMLで使えるテーマについてのご紹介です。 以前、チームで機能設計するためのPlantUML標準化の記事でも書かせていただきましたが、PlantUMLのデフォルトカラーって少しドライですよね。 色の好みは人それぞれで、あれはあれでカッコよさはありますが、複雑な図は少しでも可愛く描きたい・楽しく見たいものです。 この記事ではPlantUMLのテーマについて、いくつかのオプションを紹介していきます。「PlantUMLの色を変えてみたい！」という方は是非ご活用いただければ嬉しいです。 前提 PlantUMLでは、skinparamを利用して図のビジュアル各要素を定義しますが、「テーマ」はskinparamの集合体です この記事ではテーマの作り方や、各運用方法等については触れません この記事で紹介するオリジナルテーマはシーケンス図のために作られた
ジェネリクス — 仕事ですぐに使えるTypeScript ドキュメント
TypeScriptの世界を知る 前書き Node.jsエコシステムを体験しよう TypeScriptの書き方 変数 プリミティブ型 複合型 基本的な構文 基本的な型付け 関数 その他の組み込み型・関数 クラス 非同期処理 例外処理 モジュール console.logによるログ出力 中級のテクニック ジェネリクス ジェネリクスの書き方 ジェネリクスの引数名 ジェネリクスの型パラメータに制約をつける 型パラメータの自動解決 ジェネリクスの文法でできること、できないこと 型変換のためのユーティリティ型 オブジェクトに対するユーティリティ型 オブジェクトと属性名に対するユーティリティ型 型の集合演算のユーティリティ型 関数のユーティリティ型 クラスに対するユーティリティ型 any や unknown 、合併型との違い まとめ 関数型指向のプログラミング クラス上級編 リアクティブ 高度なテクニッ
Goのcontext.Contextで学ぶ有向グラフと実装 | フューチャー技術ブログ
TIGの辻 (@d_tutuz) です。 アルゴリズムとデータ構造連載の2日目です。今回は身近なところに潜むグラフの例を紹介します。 はじめにデータ構造の一つに「グラフ」があります。グラフは対象物の関係性を数理的に表すものです。世の中の事象をグラフとして定式化することで、問題の見通しがよくなるなど、グラフの応用範囲はとても広く、かつ有用です。グラフそのものの説明については本記事で書ききれる内容ではないので割愛しますが、「グラフ理論」などで検索すればたくさん記事が見つかるでしょう。本記事では、グラフが活用されている例としてGoの標準パッケージにおける Context を紹介します。 グラフとして考えるGoの context パッケージGoの context パッケージは Context インターフェース(コンテキスト)を提供しています。コンテキストはAPIサーバ/クライアント、バッチ処理など
GoがApple Siliconにネイティブ対応したのでベンチマークをとってみました | フューチャー技術ブログ
Goアドベントカレンダーその5です。 ARMなMacが出るとWWDCで発表されてから首を長くしてまっていて、発表と同時にMacBook Proを買って、アプリケーションのARMネイティブ対応がされているかいろいろインストールして試してみたりしています。まだ発売されて2週間足らずですが（といっても、みんな開発キットをつかって以前から準備したようですが）、動作しているアプリケーションは多いです。発売後にも、Erlang、Node.jsあたりはmasterブランチにパッチが入りました。Goも、昨日パッチがマージされました。 業務利用が多い言語のうちの一つということで、手元のPCで軽くベンチマークをとってみました。使った機種は3つです。 2020モデルのM1のMacBook Pro 2020モデルの10th Gen Core i5のMacBook Air Ryzen 9 4900HSのASUSのZ
GoのWebアプリ開発でフラットパッケージにした話 | フューチャー技術ブログ
2023.10.5追記: Goチームからプロジェクトの目的に応じたディレクトリ構造についてのドキュメントが公式に公開されています。 https://go.dev/doc/modules/layout 2020/11/13 「やってみてよかったことまとめ」、「やってみて困ったこと」、「外部モックサービスを使ったユニットテストの未来」の章を追記 2020/11/18 「やってみてよかったことまとめ」にSNSでもらったフィードバック内容を追記 はじめにこんにちは、TIG 真野です。秋のブログ週間連載の第9弾です。 1年弱ほどGo言語でWebAPIアプリケーション開発を行っていますが、かなり割り切った構成・テスト方針を採用しました。そろそろ1年弱になり機能開発も比較的落ち着き、保守運用フェーズの割合も徐々に増えてきた頃合いなので、やったこと・学び・反省といった振り返りを共有します。 Goのパッケー
WAFとして go-swagger を選択してみた | フューチャー技術ブログ
Go のフレームワークに求めるものこの場合、フレームワークに対して何を求めるでしょうか。 私は以下を重要視していました。 重要視したことドキュメントと実装の乖離をなくすことで、認識齟齬なく開発を行うこと なぜ？ ドキュメントと実装のズレを解消するコストが高いため Web API 開発をする中で最も困ることは ドキュメントと実装がかけ離れること です。ドキュメントととのずれによる、コミュニケーションを極力減らしたいと考えました インターフェイスが頻繁に変わることが想定されたため データ定義の部分が固く決まっていなかったため、データに引きずられて API 仕様の変更も頻繁に起きるだろうと思いました インターフェイスのやり取りの物理的な距離が遠いため 同一の会社内だけでなく会社間をまたいだ開発も想定されたため、コミュニケーションコストがより高くなると想定しました フレームワーク比較ドキュメントと
Go Tips 連載5: エラーコードベースの例外ハンドリングの実装＋morikuni/failureサンプル | フューチャー技術ブログ
概要TIG DX所属の多賀です。最近は設計をしつつ Go も触れて引き続き楽しく仕事してます。 今回は、errors package を一部利用して、エラーコードベースのエラーハンドリング処理を実装しました。また、morikuni/failure を利用した実装への書き換えも試してみています。 エラーコードベースの例外ハンドリングについて前提としてGoで書かれた HTTP APIサーバーに対してのエラーハンドリングについて記載します。 エラーコードベースの例外ハンドリングについてですが、アプリケーションで発生するエラーを事前にラベリングしてコード化し、コードをもとにエラーハンドリングを実施することとします。発生時の運用対応や影響について、事前に一覧で整理することで、運用負荷を下げる意味があると考えています。(補足: Futureではメッセージコードと呼称することが多いですが、一般的な命名で
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
