toLog

Chrome のブラウザ拡張の Google Analytics オプトアウトアドオンを使っていると、Remix で hydration エラーに遭遇しました。

Remix を検証がてら実機でお手軽に動かしたいと思い Lambda で動かしてみました。

Stripe のサブスクリプションの組み込みサンプルを Next.js の Server Actions でどう構築するかを検証しました。

ドット絵に特化したフリー素材サービスを作ったので、サービス概要、なぜ作ったのか、作ってどうだったのかを備忘録。

先日ブログのGoogleインデックスが減少していることを確認。robots.txtによりブロックされたとのことでしたが、robots.tsではしていません。結果的に、メタタグでGoogleBotを明示的に許可するとインデックスが再登録できるようになりました。

ここ最近 CDKTF（主に GCP を取り扱いたい）を始めたのですが、スタックの状態（tfstate）をローカルからリモートに保存するために Remote Backend を触り始めたところ、複数のスタックをデプロイ・更新する度に、古いスタックが消されるという状況に陥りました。

フロントエンドと UI デザインの試行錯誤をアウトプットしたくて WEB ツール群を作りました。toLog tools と言う名前で、当ブログの派生的な立ち位置のサービスになります。

当ブログは、static exports された Next.js を Netlify で ホスティングしているのですが、Google Search Console（以下 GSC と呼ぶ）で sitemap が検出されないエラーに遭遇しました。

表題の通りですが、tRPC の クライアント側の useInfiniteQuery は、バックエンド側で Procedure に Query を追加する時に、input に cursor を渡さないと hooks として現れません。

先日、S3 に AWS SDK 経由で画像を保存して、その画像を Chrome で表示しようとしたところ画像がダウンロードされてしまうという現象に遭遇しました。

どうしても Zod enums 上で空文字を許容したかったので、その方法を備忘録します。

先日、MongoDB 6.0 を docker-compose で立ち上げて Prisma でデータを create/update しようとすると、replica set が適切に設定されていないとエラーになったので、その時の対応をメモします。

サクッとアプリケーションを組み上げたくて、The T3 Stack を参考にしていたのですが、内蔵メソッドの衝突のエラーに遭遇しました。

Gatsby で構築していたブログを Next.js に移行しました。Next.js 良いすね。そして今までありがとう Gatsby。

SaaS関係なくドメインのモデリングを頑張りましょうという真理だなと感じている今日このごろです。

cdk v2がstableになったのでバージョンを上げてみました。1.78.0からの大ジャンプでしたが、私の場合は特に大きな問題が起きませんでした...本当か？みたいな気分です。

GitHub ActionsでOIDCができるようになったためAWSのリソースをOIDC経由で触れることを確認してみました。

graphql code generatorでは、federation をサポートした schema ファイルを出力できなかったため、apollo roverを併用することで対応しました。

今までconcatというパッケージで'.graphql'を統合していたものをGraphQL Code GeneratorのSchema ASTプラグインに任せるようにしました。

当ブログのリプレイスに伴い、ActionsでちゃんとCIをまわしたいと考えたのですが、どうせなら効率良くしたいということで、Jobで並列化して高速化？したものを備忘録しておきます。

queryやmutationなどのdocumentsもschema側で記述すると`.ts`に変換する必要があり、さらにスキーマ自体をパッケージ管理していると`.js`にトランスパイル必要があります。それはそう。なので、codegenした後に、tscでコンパイルすることで対応しました。

今回は仕事でもプライベートでもお世話になっている API Gateway + Lambda + GitHub Actions での私的ブルーグリーンデプロイを考えてみました。

Github Actionsで「前stepの変数を後stepで利用する」ために、envもしくはset-outputを使った方法を備忘録として残しておきます。

個人プロジェクトでTypeORMのエンティティがドメインモデルと同一扱いになってしまっていて、それに対して違和感を覚えていました。そこでその違和感を言語化して、個人的解法を残しておきます。

何となく触っていたSlackApp/APIに関して、いまいち理解できいなかった部分をドキュメントを眺めて再整理、私的ポイントをメモしました。

子パッケージ単体でデプロイすると、別パッケージはシンボリックリンクなため、シンボリックリンク故に実体のディレクトリ・ファイルが参照できず、moduleがないよとエラーになります。

TypeORMでmigrationを流していると突然 `migration name is wrong.` と怒られました。結論を述べると、migrationファイルが格納されているディレクトリ内に、migrationとは関係のないファイル、正確にはタイムスタンプが追加されていないクラス名が存在すると上記エラーでコケてしまいます

今まで本サイトで使用したドメインをtolog.siteからtolog.infoに変更しました。理由としては、単純にドメイン更新が高かったことです（汗）

先日、Nuxt と MicroCMS で JamStack な個人ブログを作成したのですが、その際に MicroCMS のコンテンツをどうサイトマップに反映するか悩んだので、個人的解法を残しておきます。

Serverless Framework (sls) で API Gateway + Lambda で SSR を構築する文献は多いのですが、SAM や CloudFormation に慣れている身としてはどうも sls は取っつきづらくインフラコードが SAM で完結すると嬉しい。ということで SAM で SSR するコードを考えてみた。

Jestとaws-lambda-mock-contextでテストする際に、timeoutを調整する場合は、template.yml側ではなく、mock-contextでオプションを指定して調整すること。

先日、Nuxt/CloudFront(OAI)/S3でJamstackした際に、'/XXX/favicon.ico is not found'と出るので、Lambda@Edgeでリクエストを操作して、/XXX/favicon.ico -> /favicon.icoになるように対応しました。他にも細かいリダイレクト設定を施したので、対応コードを残しておきます。

Lambda@Edgeがサポートされているリージョンはus-east-1であるため、SAM等で開発した場合は、us-east-1のs3にテンプレートを保存してデプロイする必要があります。

SAMでSendGridをコールするAPIを作っているとJestのテスト時にNetworkErrorに遭遇しました。結論、Jestのテスト環境の設定をデフォルトの'jsdom'から'node'に変えることで解決。原因はハッキリと言えないのですが、node環境下でサーバサイドを組んでいるのなら環境を'node'にしてテストするのが当たり前っぽいです

Vue/Nuxtでmultipleなselectを親子間で受け渡すのに苦労したのでメモ。結論、v-modelを:valueと@changeに分解するのではなく、v-modelのget+setでデータの受け渡しを制御することで実現できました。

プロダクト名やサービス名にはどうしても名前被りが考えられますが、その被りを一発で検索提示してくれるのがnamaeというサービです。比較的エンジニア寄りですが、こういう痒いところに手が届くサービスは本当に助かります。

当ブログをWordPressからGatsby.jsに移行しました。理由は、AWS×WordPressの開発・運用・保守に疲れてしまったことと比較的モダンな静的サイトジェネレーター、Gatsby.jsに触れたかったためです。結論として、ブログも爆速になって懐事情も優しくなり、心理的安全性を確保できたので良かったかなと考えています。

数多くあるパスワード管理ツールの中でも特にオススメしているのが Bitwardenです。エンジニア的な視点からCLI やセルフホスティングのサポートが何気においしいかなと思われます。npmやbrewで簡単にCLIをインストールでき、各種コマンドで簡単に保管庫からアイテムを引き出せます。そこで今回はこのBitwardenのCLIコマンドを個人利用の観点から簡単に共有させてください。

Bedrock はモダンな WordPress の開発環境を提供することを目的とし、Composer で簡単にインストールができます。依存関係が composer.json の１つのテキストファイルに集約されるので、Git 等でのバージョン管理もはかどります。また、docker-compose を併用すれば、ある程度モダンな開発環境も整えることができます。

お使いのプロパイダによっては固定IPが動的に変化するのですが、これでは都合が悪く、例えばSSH時にいちいちIPを調べたりと何かと面倒でした。そこで、グローバルIPをcURLで取得、SlackにpostするBotを作成しました。

QiitaやClassmethodなどのテック系ブログの目次表示をWordPressで実現するためにJavaScriptでシンプルに実装。WordPressだけでなく他のCMS/フレームワークでも扱えるようにするためJavaScriptで実装、またちょっとした工夫としてページ内リンクも追加して実装。

WordPressのSyntax系プラグインのコード表示が物足りず、HTML/CSS/JavaScriptでの自前実装に切り替えました。今回はHightlight.jsで手軽にsyntax highlightしたり、CSSの 'counter-increment: linenumber;' で行数表示したりして、ある程度満足のいくコード表示が実現できることを確認しました。

私は下記の観点のもと AWS CLI を Python のバージョン・パッケージ管理と仮想環境を使ってプロジェクト単位でインストールしています。身も蓋もないですが、ローカル環境をあまり汚したくない。Python のパッケージ管理で AWS CLI 自体のバージョン管理が行える。パッケージ + Git 管理下で、新たな端末または他者にも AWS CLI の環境構築が展開しやすくなる。CICDツール や AWS の CodeDeploy を導入している際にどの道必要となる場合がある。

phpenvでPHP7.3.17のインストールした際に起きたエラーをdefault_configure_optionsと言うファイルに依存パッケージのパスを追加して解決しました。ただし、libeditに関してはコマンド上でPHP_BUILD_CONFIGURE_OPTSと言うオプションを使ってパスを指定して上げる必要があります。

LambdaでスクレイピングしたくてSeleniumやChromeDriverでゴニョゴニョしたのですが、案の定エラーでした。結果的にPython、Selenium、ChromeDriver、serverless-chromeの各バージョンを揃える必要がありました。

CognitoでemailをSDKで変更すると、確認コードが未検証のまま変更アドレスでアクセスができてしまいます。バグっぽくて公式な対応はまだなのですが、GithubのIssueに有志の方が対応策を上げてくれています。対応策はAmplifyベースですが、今回はそれをJavaScriptSDKをベースに実装してみました。

CodePipeline で CI/CD を組んでいると各ステージの進捗状況や結果を CloudWatch と SNS を使って Slack 等に通知されている方もいるかと思いますが、これを CodeStar Notifications と言うサービスの通知機能を使えば簡単に代替することができます。今回は CodeStar Notifications + SNS + Lambda を使って CodePipeline の状態通知を Slack に送信する仕組みを作ってみます。

Lambda から Slack への通知は昔からこすられてるネタですが、わざわざ AWS SAM CLI を使って検証している方は少ないように思います。そこで今回は Slack 通知の Lambda を AWS SAM CLI で簡単に作成してみようと思います。

近頃、インフラ設定の再利用性と属人性の最小化を目的にインフラのコード化を強く意識し始めたのですが、今回はAWSの Infarastructure as Code（IaC）サービスの１つである CloudFormation を使って、なるべく簡単にAWSの小さなサーバ環境を構築してみます。

とり頭の私にとってパスワード管理は悩みの種ですが、Bitwardenを使うことで幾分か頭痛が和らぎます。風邪薬みたいなキャッチになりましたが、効率面においては何よりの療法になります。Bitwarden は多くあるパスワード管理ツールの１つですが、無料にも関わらず（有料プランあり）、その他の有料ツールと変わらないほど高機能で、セキュリティ面も担保できると至れる尽せりのツールになります。

当ブログは Wordpress で構築しているのですが、開発時は Docker Compose でさくっと開発環境を構築しました。さくっとは嘘ですが、nginx、alpine、phpmyadminなどを含めてなるべく使い易い開発環境を整えました。

個人的な印象になるのですが、WordPress は開発・検証・本番などの各環境ごとに設定が微妙に異なっていくケースが多く見受けられます。そこで、ミドルウェアとアプリケーションをコード管理下における Docker に白羽の矢が立ちます。ミドルウェアの構築や WordPress のシステム設定をコード化することで、各環境でコンテナをビルドするだけでほぼ同一の環境が作れます。