Posts

フォーマットを書けるのが面倒ください。 このブログはマークダウンで書かれていて、コミットする前に必ずprettier --writeを実行しようと心に誓ったけど、まったくというほど実行されずにきた。そしてたまに思いだしたように実行し、毎回あげだされる差分に驚いてきた。 エンジニアとして対策しないのかという話だけれど、以前対策を試みGithub Actionを登録したけれどうまく動かず、そもそも最悪フォーマットしなくても問題ないので時間かけるのもどうだろうかとissueに登録して寝かせていた。 Closeされずにずっと残り続けるissueは心を蝕む……、なんてことはないけれど少し気持ち悪い。 そこで時間をかけてもいいので、解決することを最優先課題にしてみた。 そういうわけで色々なサイトを巡回し調べた結果、 name: Format Markdown on: push: branches: - main permissions: contents: write jobs: format: runs-on: ubuntu-latest steps: - name: Check out the repository uses: actions/checkout@v3 with: fetch-depth: 0 - name: Set up Node.js uses: actions/setup-node@v3 with: node-version: "18" - name: Install Prettier run: npm install -g prettier - name: Format Markdown files run: prettier --write "**/*.md" - name: Push changes run: | git config --global user....

nextjsでタグマネージャーを導入する際に、本番環境、検証環境、開発環境といった環境ごとにコンテナのIDを指定することにした。 ただnextjsでは用意されたenvと適応コマンドがすでに割りついているっぽい。 環境ファイル 役割 .env.local next dev .env.development next dev .env.production next build/next start 参考：Next.jsで環境ファイル(env)別ビルドを行う 参考：Add support for custom environments 今回は、同じnext startで3つの環境を作成したいけど、前述の通りそれだと.env.productionしか呼び出すことができない。 そこでenv-cmdを使用する。 #Using custom env file path To use a custom env filename or path, pass the flag. This is a major breaking change from prior versions < 9.0.0-f とあるように、アプリをビルド/実行するときに特定の.envファイルを選択することができるパッケージ。 .env.prod .env.stag .env.local と3つのEnvを用意し下記のようなScriptを作成すれば、それぞれのScriptごとに対応するEnvを読みに行ってくれる。 "prod": "env-cmd -f .env.prod next build && next start", "stag": "env-cmd -f .env.stag next build && next start", "local": "env-cmd -f ....

ブログにOFUSEを導入することにした。 OFUSEとは簡単に言うと投げ銭サービスで、クリエーターとかが簡単に寄付を受け付けることができるプラットフォームのこと。 公式に下記のような説明がある。 OFUSEは、「ファンの応援でクリエイターの創作活動を支えたい」という想いから生まれたファンレターサービスです。あらゆるクリエイターが、Web上での創作活動や情報発信を通じて継続的に価値を生み出してゆける仕組みをつくり、ファンとクリエイターをつなぎます。 現在、中心的な機能である「支援付きレター」（1文字2円のファンレター）に加え、投稿への「支援付きコメント」（1文字2円のコメント）や月額で支援できる「メンバーシップ」をご利用いただけ、応援金額の90%をクリエイターの皆様へお届けしております。 他にも有名なサービスでBuy Me a Coffeeがある。こちらはよくGithubとかで見る。個人的には投げ銭というばこっちのサイトが頭に浮かぶし、なんとなくかっこいい。 けど、今回はOFUSEを導入することにした。 なぜ投げ銭サービスを導入するのか そもそもなぜ投げ銭サービスを導入するのかだけど、大前提としてこのブログで儲けようなんて微塵も思っていないし、儲けられるなんて思っていない。 儲けたいのであれば過去に月１万とかを生んでくれた商品レビューブログを復活させるし、アドセンスを表示しまくる。 けどこのサイトはそういうサイトじゃない。あくまでも自分のアウトプット用、あるいは記録用で、後で見返せばいいなくらいのスタンスで更新している。 そうしないと更新が続かないと思って、そういうスタンスをとってきた。 けど最近は少しづつ読まれることも意識するようにしたいと思うようになってきた。 それが本質ではないけど、どうせ書くのであれば誰かが読んでいい記事だと唸るような記事が書ければいい。そのために時間を費やすことはないけれど、結果的にそうなれば幸せである。 とは言え、唸る記事がもし書けたところで投げ銭してくれる人なんでいないと思うし、自分有益な記事を読み感謝こそすれど投げ銭なんてしたことがない。 あくまでもこれは投げ銭サービスのリンクを張っているぞという自分への戒めである。投げ銭のリンク張っているんだから少しくらいいい記事書くように意識しようぜ、といったところ。 ただ何度も言うけど、このブログは自分のためのアウトプットで記事更新が億劫にならないレベルで書いていくつもり。 かけれる保険は掛けておく。 なんでOFUSEにしたのか 前述したように同様のサービスであるBuy Me a Coffeeの方が洒落ていてかっこいい。 ただ自分が寄付する側だった時に、海外サービスを使用するのは少し抵抗がある。安全性とか信頼性とかではなく、通貨の単位が異なることに不安を感じる。 あと使えるクレジットカードのサービスとかもなんか制限がありそうな気がする。すごい偏見なんだけど。 それに海外の人が読むことなんてあり得ないので、それなら国産サービスにしたほうニーズに合っている。 まあ、そういうわけで投げ銭サービスを取り入れてみた。これが少しでも記事更新、質向上になればと考えている。

連合がない おひとり様サーバーを立ち上げたのは過去に書いたのだが、フォロワーを探すために連合を見に行った。 当時（といっても１か月もいかないくらい前）連合とはmastodonに投稿されるすべての呟きが忙しく流れるところという認識だった。というのもかつていたサーバーの連合は絶え間なく呟きが投稿されていたからである。 しかしどうしたものか、自サーバーの連合はタイムラインと大差ない。 うまくサーバーが立ち上げれていないのか、はたまたそういうものなのか。 そもそも前にいたサーバーの連合も日本語だらけで海外の投稿がなかった気がする。 つまり連合は「mastodonに投稿されるすべての呟き」じゃない……？ 連合は同一サーバーに所属する人のコミュニティが反映される ドキュメントを探っていたところ、下記情報に遭遇した。 公開タイムラインに流れるコン​​テンツの閲覧 興味のありそうなコンテンツを発見できるように、Mastodonはすべての公開投稿を見る手段を提供しています。とはいっても、全部のサーバー間で包括的にステータスが共有されているわけではないため、すべての公開投稿を見る方法はありません。連合タイムラインを閲覧すると、あなたのいるサーバーが認識しているすべての公開投稿を表示できます。サーバーが投稿を認識する方法はさまざまですが、その大部分は、同じサーバー上にいる他のユーザーがフォローしている人々の投稿でしょう。 簡単に言うと、 同じサーバーのユーザーがフォローしている他のサーバーのユーザー 同じサーバーのユーザーがブーストをした相手ユーザーによる投稿 が連合には表示されるらしい。 そのため、自分しかいないサーバーであるおひとり様サーバーの場合、連合はタイムラインと同じ情報になる。 だから以前のサーバーにも日本語投稿が多かったのかと腑に落ちた。

新規開発中のWebアプリケーションで、一覧ページのネットワークタブを何気なく確認したら、画面に表示されているリストの各詳細ページがすべてリクエストされていることに気付き、驚いた。 「実装ミスかしら」とぞっと総毛だって実装を見直してみるが、特段へんてこな記述は見つけられない。 ただnext/linkをmapで回しているだけである。 だいたいこういうときはnextのお節介が原因のことが多い。 そういうわけで、next/linkを調べてみると案の定prefetchというオプションがあり、デフォルトがtrueとなっていた。 ビューポート内にある はすべてプリロードされます (初期状態やスクロール中)。prefetch={false} を渡すことでプリフェッチは無効になります。prefetch が false に設定されている場合でも、ホバー時にはプリフェッチが行われます。静的生成を使用しているページでは、ページ遷移を高速化するためにデータと一緒に JSON ファイルがプリロードされます。プリフェッチは本番環境での> み有効です。 とのこと。 基本的に気にしなくてもいい気がするけど、サーバーに負荷をかけるのでfalseにしても問題ない気がする。 prefetch が false に設定されている場合でも、ホバー時にはプリフェッチが行われます とあるのでfalseにしたところで、そこまでページ遷移のユーザー体験を損なわないと思われる。 nextは本当にお節介で裏側で色々なことをしてくれる。しっかり理解しないと思わぬ副作用を生むことがあるのでドキュメントを読むことを心掛けたい。