Webサービスのステージング環境をアクセス制限をCloudflare Zero Trustでやってみたところ、とても手軽でちょうど良かった。特に必要な知識はなかったが、今後同じことをやりたくなったときのために設定内容をメモしておく。 やったこと Cloudflare Zero Trustで「特定のメールアドレスの所有者」にだけWebサイトへのアクセスを許可する（ここでは例としてhttps://app.example.com/*へのアクセスを制限する） 前提 ドメインをCloudflareで管理しており、DNS設定でプロキシモードが有効になっていること 設定その1: ログイン方法を追加しておく Cloudflareにログインした状態でZero Trustを開く Settings → Authentication → Login methodsでOne-time PINを追加しておく 指定した

こんにちは。マネックス・ラボでferciを開発している佐藤です。今回は、GoogleSignInで本番環境を意識した設定行った上で本番環境での利用を申請しようとしたところ、わからないことが多くて時間を使ってしまったので、本番環境を想定した設定の流れと、ハマりどころを書き残したいと思います。 Googleのロゴは勝手に使えないのでマカロンの画像を貼っておきます。 前提 公式のドキュメント GCPの準備 OAuth2.0クライアントIDの登録 OAuth同意画面の設定 「アプリを編集」の設定 アプリ名 ユーザーサポートメール アプリのロゴ画像 アプリのドメイン 承認済みドメイン デベロッパーの連絡先情報 スコープの設定 テストユーザー 本番環境への申請 確認を準備する 省略可能な情報 YouTube動画について 審査で指摘されたこととGoogle担当者とのやり取りについて ハマりどころ ユーザ

GraphQL スターターパック | Prisma + NestJS + Next.JS製 個人ブログサイトをCloud Runで運用しよう

はじめに 最近ちょくちょく触っているNext.js 13アプリをクラウドにデプロイしていたところ NEXT_PUBLIC_変数が空になる クラウド環境のサーバーインスタンスに該当の環境変数は設定できている ローカル環境ではproductionビルドで同じ環境変数名と値を設定していて問題ない という事案に遭遇しました。 この記事では、その原因～おおまかな解決手順を記したいと思います。 前提 Next.js 13アプリはDockerfileを構成してある GitHub ActionsでCI/CDパイプラインを構築してありNext.js 13アプリはコンテナーアプリとしてクラウドにデプロイされる 環境変数はCI/CDパイプライン内にてGitHubリポジトリーのvariables/secretsを読み込んで設定している 原因 ビルド時ではなくデプロイ時に環境変数を設定していたため NEXT_PUB

本記事の内容はBiome 1.5.3時点での暫定対応になります。 Biomeでまだ実装されていないルールをESLintで補おうという趣旨のため予めご了承ください。今後のBiomeのアップデートによって全てBiomeで対応可能になる可能性があります。 普段、Biomeをメインのリンター・フォーマッターとしてNext.js 14のプロジェクトにて使用しています。ESLintと互換性のあるルールが多く実装されておりどんどん移行しやすくなってきている印象を受けます。 Biomeが注目されたことで脱ESLintや脱Prettierに向けて動いているプロジェクトも多そうですね。 私も実際に環境構築を試みましたが、まだ一部のルールがBiomeで未実装のため、必要に応じてESLintを併用することがあります。 日々ESLintからBiomeへの移行を進めながら、一時的ながらもESLintとBiomeを組み

こんにちは。フロントエンドエンジニアのiemongです。 noteで開発しているmonorepo環境のLinterをESLintからBiomeへほぼ移行しました。それについて共有します。 移行のモチベーションnoteではNuxtからNext.jsへのリプレイスを進めている最中で、monorepo環境で6個のアプリと22個のpackageがあります。TurborepoのRemote Cachingを使うなどしてタスクの実行速度の改善は既にやってたのですが、Componentの数が増えてきたせいかCIでlintが途中でkillしてしまうことがあったり、キャッシュがない場合にLintだけで2~3分かかるpackageなども存在しました。また、ESLintのFlat Config対応も進めていきたかったのですが、使用しているESLintのplugin側の対応がまちまちで着手しづらい状況でした。 そ

オーバーエンジニアリングしてしまうという悩みがあって困っている、そのうち必要になるのではないかという気持ちになって無駄に抽象化して頑健にしてしまう。じゃあ素朴にやればいいのかというと、例えばDBスキーマみたいな要素は素朴になってはならないという難しさもある— Windymelt💀(めるくん)🚀❤️‍🔥 (@windymelt) 2024年9月12日 上のツイートを見かけたので、自分は何を心がけているか書いてみる。 結論 プロダクト方針的に起こりそうな未来を想像する 想像した未来が起こったとして、どのような実装になりうるかをざっくり考える その上で、その未来が起こったときに「詰む」ことがなさそうな一番シンプルな設計にする 前提: あらゆる未来の変更に強い抽象化はない 設計を考えていて複数案を出すと、結局トレードオフが存在することがわかる。案Aを選択すると、こっちの未来には対応しやすいが

初めまして、テックドクターでフロントエンド開発を担当している大瀧です。 ディレクトリ構成はコードの可読性やスケーラビリティに関わる重要な要素であると思っています。 しかし、フロントエンドのディレクトリ構成はベストプラクティスが確立されておらず、わりと悩むポイントです。 そこで今回は、Next.jsのApp routerにおいて、弊社で採用しているディレクトリ構成を共有します。この記事がディレクトリ構成に悩む開発者の助けになれば幸いです。 ディレクトリ構成の自由度が高すぎる問題 さきほど「フロントエンドのディレクトリ構成はベストプラクティスが確立されていない」と書きましたが、特にApp routerのディレクトリ構成については、公式ドキュメントで以下のように記載されています。 There is no "right" or "wrong" way when it comes to organi

こんにちは。 Findy で Tech Lead をやらせてもらってる戸田です。 突然ですが皆さんは本を読みますか？ エンジニアという職業柄、技術書やビジネス書など、様々なジャンルの本を読む機会が多いのではないでしょうか？ そこで今回は、人生を変えた一冊と題して、弊社エンジニア達のお気に入りの一冊を紹介していきます。 それでは見ていきましょう！ 人生を変えた一冊 戸田 ソフトウェア・ファースト あらゆるビジネスを一変させる最強戦略 ジョナサン・アイブ 高橋 1兆ドルコーチ シリコンバレーのレジェンド ビル・キャンベルの成功の教え 森 アジャイルサムライ――達人開発者への道 まとめ 人生を変えた一冊 戸田 ソフトウェア・ファースト あらゆるビジネスを一変させる最強戦略 ソフトウェア・ファースト 作者:及川 卓也日経BPAmazon 及川卓也さん著の本で、DX（デジタルトランスフォーメーション

こんにちは。新規IAMプロダクトでフロントエンドアーキテクトを担当している@shisama_です。 この記事では、開発スピードを上げるためにGitHub Actionsを使ってプルリクエストごとにレビュー用の検証環境をGoogle Cloud Run（以下、Cloud Run）に構築する仕組みについて紹介します。 今回紹介する内容のサンプルのリポジトリはこちらになります。 github.com この仕組みは業務委託でお手伝いいただいていた@chimame_rtさんが考案し設計してくれました 👏 はじめに フロントエンドチームが抱えていた課題 プルリクエストごとに Cloud Run に検証環境を構築する Step 1. プルリクエストにラベルを適用して GitHub Actions を起動 Step 2. Next.js のビルド Step 3. Google Cloud の認証 Ste

ダイヤモンド社にて、書籍事業を担当する局。ビジネス、実用、教育、サイエンスなど多様なジャンルの書籍を刊行している。 だから、この本。 ダイヤモンド社の話題の１冊を取り上げ、書き手・作り手の思いや執筆動機、読んでほしい理由を深掘りするインタビュー連載。著者・訳者・デザイナー・編集者など、本に関わるさまざまな人たちの「だから、この本を書きました」「作りました」をお届けします。連載の詳細・記事一覧はこちら。 バックナンバー一覧 社会派ブロガー・ちきりんさんの『マーケット感覚を身につけよう』で描かれた未来がどんどん現実となり、高学歴でもない人や専業主婦でも、市場価値の高いビジネスに乗りだし、成功する人が増えている。 その一方で、「なんとなく」モノやサービスの価値に気づいても、うまく言語化できずに困っている人もいるのではないだろうか？　そこでインタビュー最終回では、「価値」あるものを言語化する方法と

こんにちは。ソフトウェアエンジニアの坂井 (@manabusakai) です。 カミナシでは、クラウドインフラストラクチャに AWS を採用していますが、昨今の円安を受けて円換算での請求額は右肩上がりで増え続けています。サービスの規模や特性に関わらず、パブリッククラウドを利用する多くの日本企業で頭痛の種になっているのではないでしょうか。 円安になる前から継続的にコスト最適化には取り組んできましたが、クイックウィンで実施できるものはやり尽くしており手詰まり感がありました。しかし、我々スタートアップにおいて適正なコストに抑えることはランウェイ（キャッシュ不足に陥るまでの残存期間）を伸ばす意味でも重要なため、現状に甘んじることなく次の最適化ポイントを探していました。 Arm アーキテクチャ移行によるコスト最適化への期待値 AWS は Arm ベースの Graviton プロセッサを開発しており、

PHPカンファレンス小田原2024での発表資料です https://fortee.jp/phpconodawara-2024/proposal/4d39c7ef-058c-4648-b1d7-5510497e0d81

みなさん、お疲れさまです。 nakamoto（@zksytmkn）です！ フロンエンド開発にReactを用いるとき様々なスタイリングソリューションがありますよね。今回は素のCSSとTailwind CSSとCSS-in-JSのどれを使用するかという観点から、それぞれおすすめのスタイリングソリューションをご紹介させていただきます。 素のCSS素のCSSならMantineというコンポーネントライブラリがおすすめです。 Mantineはもともと他のコンポーネントライブラリと比較しコンポーネントがかなり充実してましたが、v7.4.0よりチャート系のコンポーネントも追加されました。それによりMantineの隙はなくなりましたし、チャート系までサポートしてるコンポーネントライブラリはMantineと後述のTremorくらいです。しかし、Tremorはチャート系などの管理画面のコンポーネントは充実してて

Database schema templates Collection of real world database schemas from open-source packages and real-world apps that you can use as inspiration when architecting your app.

はじめまして。そーだい（@soudai1025）です。私は普段は技術コンサルティングや受託開発を請け負う合同会社HaveFunTechの代表として、また、予防治療の自社サービスを展開する株式会社リンケージのCTOという二足の草鞋を履き、日々、さまざまなWebサービスの開発に携わっています。 これまでの開発経験のなかで、データベース設計に関わるさまざまな問題に遭遇してきましたが、本稿ではとくに、アジャイル開発時に発生しやすい問題とその対処についてお伝えしたいと思います。開発の現場で目にしやすい実装におけるアンチパターンを示しつつ、アジャイルという指針を維持しながら、対処となるデータベース設計についてご紹介します。 会員登録のアンチパターンと処方箋 イージーな実装とシンプルな実装 Userと言う名の罠 拡張と破綻 データベースは変化に弱い 仕様変更とテーブル変更 Addで変化に追従する 正規化

日経BPより「普通の人が資産運用で99点をとる方法とその考え方」が出版されます。 Amazon: 普通の人が資産運用で99点をとる方法とその考え方 内容の紹介 「はじめに」と「目次」です。 はじめに / 目次 (PDF) （掲載許可取得済) 書籍は、元の記事をベースに全面的に書き下ろしました。特に第2部「理論編」と第3部「Q&A編」には、新しいコンテンツを多く追加しています。 「資産運用に関しては最初にこれだけ読めばよい」という本を目指して、資産運用の具体的な方法、99点の方法を実践するための「考え方」、さらに現実によくある質問に多く応える実践的な本です。 第1部「結論編」では、元の記事同様「資産運用するならここだけ実践すればよい」という内容を中心にまとめました。 第2部「理論編」は、元の記事の「理論編」は読むのを飛ばしましたという方にも、「これなら理解できる！」と思ってもらうのを目標に丁