開発日誌

開発した時に躓いたこととかの記録

はてなブログなどのRSSの日付を上手に表示する

rss

※RSSによって返ってくるものが若干異なっていることがあるので確認の上で実装してください

弊ブログにてRSSで表示してるコンテンツに日付をだしたかったけどそのまま出したらグリニッジ標準時っぽいのが出たのでお直し。

コード

RssPosts.astro

利用しているもの / 利用するもの

実装時のコツ

  • RSSで帰ってくる日付が2023-08-02 13:10:41になっている。こんな昼間に投稿してないはず。
    • 多分GMTだなあということで……下記。
    • .000+0000ではなく+0000でも動いたが、念のため
    • locale:ja もなくても動くが、念のため
    • hh:mm:ddにしてズレるなあと思うアホをした。24時間表記は大文字でHHなのでHH:mm:dd
import { format } from "date-fns";
import ja from "date-fns/locale/ja/index.js";

const formattedRecentData = recentData.map((item: RssItem) => ({
  ...item,
  pubDate: format(new Date(`${item.pubDate}.000+0000`), "yyyy-MM-dd HH:mm:dd", {
    locale: ja,
  }),
}));

つぶやき

  • 世界的な規格なのでGMTを利用しているのだと推測するけど、それなら+0000までつけてほしかったな～

astro2.8から3.0にアプデした記録

Astro

何するの

astroの3.0が出た。パフォーマンスや最適化がより向上しているし、Astro View Transitionsという良い感じの遷移ができる機能もできたようで、色々試したいので自分のサイトも3.0にすることにした
Astro 3.0 | Astro

やったこと

参考: Upgrade to Astro v3 🚀 Astro Documentation

  1. package.jsonから@astrojs/imageを削除する
  2. npm install astro@latestを走らせる
  3. Upgrade to Astro v3 🚀 Astro Documentation の Removed: @astrojs/imageと [Images 🚀 Astro Documentation] を参考に書き換え
    • astro.config.mjsを修正
    • @astrojs/imageのラッパーコンポーネントがImage.astroというファイル名だったので、ImageWrap.astroにRename（astro:assetsのImageと名前が衝突してエラーがでるため）
    • ImageWrap.astroで利用していたPicutureタグをImageに変更
    • Imageタグにはaspect-ratioがないので削除し、heightを追加
  4. ｵﾜﾘ🎉！！

つぶやき

  • Upgrade Guideが結構長いのでちょっと警戒してたんですが、そんなに面倒な作業じゃなくてよかったです
  • 1番面倒だったのはaspect-ratioからheightを算出する作業でした。
    • Wrapperコンポーネントあったおかげでpropsをちょっと書き換えるだけで済んだのでまあWrapperにしといてよかったのかな
  • ちょうど1ページサイトから複数ページサイトになったところなので、Astro View Transitionsを近いうちに素振りしようと思います
  • この作業のついでに利用してなかったtailwindを削除しました。astro導入した時はこれを機に覚えようと思ったのかもですが、astroみたいにCSSとHTMLが1ファイルにあると特にtailwindにしたい気持ちが湧かないですね。こうしてtailwindチャレンジが見送られ続けていく。

おわり。

astroを利用したサイトをfirebaseからVercelに移行した

Astro Vercel

astroとVercelと公式にホスティングパートナーになったようです。

 

astro.build

 

AstroのMiddlewareがVercelのEdge Middlewareを利用して実行できるようになったり、Vercelの画像最適化をAstroで利用できるようになったりするようです。（※ 誤訳しているかもしれません）VercelのEdge Middlewareが利用できるということは今までより高速に動かせる可能性が高まりますし、画像最適化についてもNext.jsでそのメリットについては重々承知です。

 

これはぜひastro & Vercelの組み合わせのサイトを持っておかねばならぬ、ということで、firebase hostingにのせてたポートフォリオサイトをVercelに移行しました。手順は下記の感じ。

 

  1. Github Actionsで動かしてたfirebaseへのhostingのymlを削除
  2. Vercelに新規Projectを追加、ドメインを設定
  3. CloudflareにてDNSの向き先を変更
  4. 1日1回、RSSを反映のための定期更新をしたいので、Github ActionsでVercelへdeployを追加

 

実際のサイトはコチラですが、見た目は変わらないです。

今はImageコンポーネントも使ってなくて最適化は動いていないので、今度適用やります。webpになってるのは、ローカルで変換してるからですね。1回lighthouseスコアを全部100点狙った時の名残りです。

画像をwebpに変換する作業、地味に面倒なので、Next.jsと同じ感じでpng使ってもwebpになるのは楽になって嬉しいですね。そのあたり面倒でずっと後回しにしてた画像の追加・差し替え、やっとできる。

 

あと最近デザインの勉強をちょっと本腰いれてやってるんですが、そしたら自分のサイトがめちゃダサに見えるのでそのへんも魔改造していこうと思います。目指せデザインエンジニア。

メインブランチ名をmaster -> mainに変更した

Github

 

ポートフォリオのリポジトリのmasterブランチをmainブランチにrenameした。
コピペしたGithubActionsの中に『main』という文字列があり、今まで変更作業をしたことがないので、この機に変更するか！と思い立ってみた。

 

基本は↓の記事を参考にしたのだが、同じ手順で動かず。

masterからmainに変更する（githubのリモート＆ローカルブランチ）branches - Qiita

 

私はSettingsのBranchesからではなく、トップからブランチ一覧に遷移した。下記の感じ。

  1. リポジトリのトップのブランチ選択の横の『N branch』からブランチ一覧へ
  2. masterの右側のえんぴつアイコンで名前変更
  3. Code画面に移動すると上記記事の『Codeタブに移動した画面』の2と同じ文章がでたので実行

という感じだった。

実行完了後に見てみたら、Settingsのmasterも自動でmainになってた。

 

masterがmainに変更になるって聞いた当時はめんどくさそ～まあ動くからいっか！で放置したが、意外と簡単に変更できるので、何かの作業ついでに変更するようにしてもいいかもしれない。

ちなみにVercelのSourceブランチの認識は変更されてなかったので、Vercelを利用している人はSettings > Git > Production Branchの確認しておくと吉。

devドメインをGoogle DomainsからCloudflareに移管した

tech ドメイン

ついに！Cloudflareが.devドメインに対応しました！！ TLD Policies | Cloudflare

Google Domainsの売却が発表された当初はClouflareは.devドメインは『Available soon』ステータスでした。 soonってどのくらい！？と思いながら首を長くして待…っていたわけでもないですが、 『.dev を Google Domains から Cloudflare Registrar に移管してみた』を見かけたのでこの度ついに対応していきます！

やっていき

上記の記事だと上手くいかなかったので、下記の記事を参考に対応。DNSの移行すらしてなかったので、たぶんそこがだめだったみたい。 GoogleドメインからCloudFlareに移管する。 - Qiita

色々なミス

https://manasas.dev でエラー

ERR_SSL_VERSION_OR_CIPHER_MISMATCHが出るようになってしまった。 Fix VERSION_OR_CIPHER_MISMATCH · Cloudflare SSL/TLS docsを参考に、SSL > エッジ証明書を確認。なんかまだアクティブじゃない感じだったので、静観。アクティブになったら見れるようになりました。

DNS設定、一部しか移行されない

移管ポチ！っとしたあと、DNS設定が一部しか自動移行されてないのに気づきました。 急いでcloudflareにも再設定。

はてなブログが独自ドメインにならない

初期設定のオレンジの雲ではなく、DNS Onlyにしてグレーの雲にしないといけないみたい。 - Cloudflare の DNS で設定したサブドメインをはてなブログの独自ドメインとして使うときは Status を DNS Only にする - Qiita - Cloudflareへ移行 + はてなブログで不具合(解決済) - 人は歴史を作り出し、人は歴史を語り継ぐ

エラーになってる間は元のURLにリダイレクトしてくれるみたい。 この記事を書いてる今現在、ドメイン設定をチェックして有効にしてもまだリダイレクトされてしまう。どうやら定期で実行されるチェックに通らないと治らない模様。『最終チェック』が更新されたタイミングでなおった。3時間～4時間ごとっぽい。

cloudflare pagesがエラーページになる

お膝元だと設定を変更しないといけないのかしら、と思いましたがそういうわけではないようです。 pages → 落ちてるサイト → カスタムドメインを確認したところエラーになってて、再確認ボタンがあったのでぽちっと。緑のアクティブになって元通りになりました。

そのほか

Vercelにデプロイしてるものは設定だけちゃんとすればOKだった。 https://manasas.dev はfirebase hosting。 VPS（めいどるふぃんの自鯖）も設定だけちゃんとすればOKでした。 はてなブログが1番難しいかも。

雑感

cloudflare、多機能そうだけど、インフラわからない民としては何が何やら……って感じなのでちょっと不安。はてなブログの謎エラーは先人がいなかったら解決できなかったと思う。ありがとう先人。

結構がっつりダウンさせてしまったので、ダウンタイム無しで色々インフラやってるインフラ担当はすごい。感謝しかない。証明書とDNSの設定を先に完璧にしておけば、ダウンタイム無しでできて、はてなブログも3時間も待つ必要はなかったのだろうか。くやしい。

自ブログをPages RouterからApp Routerに変更した

Next.js

やったこと

  • Next.jsを13.1 -> 13.4にアプデ
  • Next.js を Pages Router から App Router に移行するときにやったこと を参考に _app.ts と Layout を layout.tsx とcomponents/layouts/defaultLayout.tsxに分割
    • 本当はlayout.tsxにまとめた方が良いと思うのだが、header/footerが上手く動かなかったのでとりあえずheader/footerはdefaultLayout.tsxに残した
  • srcのsrc/api以外をappディレクトリに移動
    • src/pages/articles/[slug].tsxなどをapp/articles/[slug]/page.tsxのように変更
    • metadataは下記を参考に設定
    • getStaticPropsやgetServerSidePropsは中身を取り出してPageコンポーネント内で呼び出すように変更
    • getStaticPathsはgenerateStaticParamsにしてpathsだけ渡すように変更
    • src/apiはそのまま（OGP生成APIのみ）
  • storybookはsrc配下だけ認識するようになってたので、app配下を認識するように変更

悩みポイント：RSS feedどうするか

おわり

  • 主な書き換え点はgetStaticProps, getServerSideProps, Headタグくらいなので、興味ある人は移行してみてもいいかも、くらいの移行難度。
    • 前にブログからmicroCMSへの移行を試す記事でも1度試したがGETがPageコンポーネントに近くなったのはしっくり感が高くて好き
  • favicon等も『置くだけ』で設定できるのはlessで良い
    • 上書きも容易なのが体験として本当良い
  • layout.tsxが上手く動かなかったのは追加調査したい、layout.tsxに設定したデフォルトOGPも上手く効いてない気がする。
  • おわり。元のサイトの構成がシンプルなのもあってあまり沼らなかった。めでたし。

Yew(Rsut)をGithubActionsで自動デプロイする

Rust tech Yew

検討

Vercel, Cloudflare

  • 両方試したが、リポジトリ接続はfailedした
  • ビルドコマンドをYewのものにしてもだめ
  • そもそもNode.js以外想定してなさそうだなと思ったので、あまり深堀せずに撤退

Github Actions + Cloudflare

  • GithubActionsでビルドして、静的ファイルをCloudflare PagesでPublishすることにした
  • Cloudflareをチョイスするのは、あまり使ったことないので興味で。

やっていき

- run: rustup target add wasm32-unknown-unknown
- run: cargo install trunk
- run: trunk build --release
  • とりあえずpush。
    • cargo install trunkにまあまあ時間かかる。
  • trunk build --releaseが失敗した
    • headerがunresolved importだった。目視してもimportしたいファイルはちゃんとそこにある。困った。
    • ローカルでは発生しない
    • help: to create the module header, create file "src/components/header.rs" or "src/components/header/mod.rs"とエラーの一部に書いてあるが、src/components/header.rs はすでに存在している。
  • リポジトリの実装の時に参考にした『Web フロントエンドエンジニアのための Rust 製 Web フロントフレームワーク Yew 入門 』に戻ってみる。
    • cargo install trunkとrustup target add wasm32-unknown-unknownの順番が逆だったので入れ替えてみたが、変化なし。
  • todoの方ではエラーが出ていないのでディレクトリ構造をそろえてみたが、変化なし。
  • Github Actionsのrustupとcargoのバージョンがローカルより新しかったので、ローカルの方を更新
    • versionあわせてもローカルでtrunk build --releaseは問題なく通った

  • 他のコンポーネントと比べた時、deriveがないため認識されてないのか？と思ってエラーにでているheaderに追加してみたが、変化なし。

  • 結論として『header.rsをhedear_section.rsにリネームしたら動いた

    • なぜ。ローカルでは発生しないので、Rust固有ではなく、GithubActions内の環境が原因だと思うが、未解明。
  • 出来上がったサイトサイト
    • スタイルほったらかしなので後でなおす
  • 完成したyml

おわり

  • 『こんなんで動くわけが……』と思ってリネームしたら動いてしまったのでとても謎
  • 改めて見るとderiveなど『とりあえずお手本のまま書いてみたが、ちゃんと理解していない』状態なのでちゃんとRustの本を読み切りたい、今年中に。