開発日誌

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

半期ふりかえり

会社のふりかえりついでにプライベートもふりかえるかってことでふりかえってみる。半期という名の1月～9月振り返り

 

やってたこと

2023年にメンタルを崩してたこともあってあえて『開発をがんばらない』をしていた。ちょうどよくTwitterも辞めたので開発情報源はたまに見るZennとRSSリーダーだけ。

サイトの更新は定期的にやっている。コンテンツ更新だけでなくコード更新もしている。

新規の個人開発とかはしていない。新規のコミュニティとかにも行っていないし、今年は社会人になってから1番静かな年だったかもしれない。

仕事はそれなりにこなしてた。アプリを初めてやったのだが、OSによっては動かない機能を調べながらやるのはかなり楽しかった。公式のありがたみ感じる日々だった。

 

結果

がんばらなくてもいいんだなと思った。

がんばれるに越したことはないのだろうけど私の場合はがんばろうとした結果メンタル壊したのが2023年なので、がんばらずに生きていけるところを探した方がいいんだろうと思う。がんばらなくても技術記事は読むし。この技術今度素振りしてみようという技術も見つかるし。AtCorderとかやってみようかなとかも思うし。

たまにはがんばった方がいいのかもしれないけど、2024年前半関しては、2023年後半メンタルズタボロだったので休んで良かったと思う。おかげですっかり回復した。たぶん。

 

この先やりたいこと

このままやりたいことやりつつ生きてく。元々『UIをどうするか』みたいなことに興味が強いので、色んなUIを眺め探りつつ、たまに作りつつやっていければいいなと思う。何やるかは具体的に考えてないけど。気になる技術も出てきたのでそろそろ素振りしたいし、何か思いついたら作るかも。

あと最近Copilotに頼り切りでアルゴリズムとか書く筋力が衰えてる気がするので、AtCorderとかに手を出してみたいなと思う。脳みそ動かしたい。

 

続きを読む

date-fns v4.0が出てた

きまぐれ日課のnpm outdatedをやっていたら、date-fnsが4.1.0になっていた。
メジャーバージョン系はbreaking changeが怖いので基本公式の情報を見てから上げるようにしている。結論から言うと私に影響するbreaking changeはないので上げちゃうことにした。

 

ちなみにv4.0.0が出たのは2024/9/16で、v4.1.0になったのは6 hours agoだそうだ。日本時間の2024/9/17の14時くらいかな。

 

で、公式のアプデ報がこれ↓ 

 

blog.date-fns.org

 

今までtime-zoneサポートしてなかったっけな～と思って読み進めると、どうやらサードパーティによって実現されていた模様。なるほどね。

で、Time zones supportのサポートの章をChromeの翻訳の力を借りて読むと。かっしこ！めっちゃかしこいやん！！！って気持ちでいっぱい。特に違うTZで定義した時間の差を算出するのにinでTZ定義して正しく差を出せるようにするところめ～～っちゃかしこい。これ閃いた時は絶対自分のことめっちゃ天才だと思ったと思う。思ってほしい。正直めっちゃ天才だと思う。

 

Breaking Changesの章でも『大抵のメジャーリリースはBreaking Changeするもんだが我々はできるだけしないつもり』と言ってて好印象。これからもついていきます！！

NILTOを使ってみようとした

CMS headlessCMS NILTO

フェンリルのCMS、NILTOをちょっと試してみました。 結論として自分の用途にはアンマッチだったので止めたのですが、そこまでの感想をば。

NILTOとは

やろうとしたこと

  • 自サイトの『制作物』のセクションをCMS化しようとしてました。なのでフィールドは下記のような感じでした
    • [必須]タイトル
    • [必須] 画像
    • [任意] ひとことコメント
    • [任意] URL（制作物サイトがある場合）
    • [任意] URL（Github）

結論

  • 画像のスキーマから『src, alt』のみで、astroのImageタグで使うImageMetadataの生成が困難だったので止めました。
    • ImageMetadataは『src, width, height, format』が必須です。

気になるポイント

フィールド作成がドラッグアンドドロップ

  • 横につなげたりとかできるのかな？と思ったらそうでもなさそう？今回はシンプルなフィールドしか作成しなかったので、あんまり恩恵を受けられませんでしたが、複雑なフィールドを作る場合は役に立つのかもしれません。

ライブラリはなさそう

  • それはそれでシンプルで良い気もします

画像フィールドがwebpを受け付けてくれない

  • たまによくありますよね

公開ボタンを押して『保存していない変更は削除されます』旨が出たことがあった

  • 『まあ飛んでもいいや』ってデータなったのでそのままGOしたら、普通に保存されてました
  • 自動保存なので、自動保存のタイミングと公開ボタン押したタイミングが悪かったのかも

感想

  • ぼっち開発なので実験できませんでしたが、共同編集機能のあるCMSは中々珍しくて良いんじゃないかな、と思います
  • ただ私はひとりな上にwidth/heightがどうしても必要だったので、自サイトへの導入は見送りにしました
  • 共同編集が必要になったりしたらまた再チャレンジしようとおもいます！おわり

Cloudflare PagesのサイトをGithub Actionsを使って定期デプロイする

GithubActions Cloudflare CloudflarePages

ある日、GtihubActionsからエラー通知が届いた。 私のサイトはRSSで自分のブログの記事を表示しているのだが、これをVercel→Cloudflareに移したことで落ちてた模様。修正する。

結論

  • 完成品
  • scheduleで"0 0 * * *"にすれば毎日0時0分にデプロイされるのでそれを利用
  • Vercelとは異なり、GithubAcitons内でBuildコマンドを叩く必要がある
name: deploy website
on:
  workflow_dispatch:
    inputs:
      ref:
        description: deploy website
        default: "main"
        required: true
  schedule:
    - cron: "0 0 * * *"
jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v3
      - name: Build
        run: npm install && npm run build
      - name: Publish to Cloudflare Pages
        uses: cloudflare/pages-action@1
        with:
          accountId: ${{ secrets.CLOUDFLARE_ACCOUNT_ID }}
          apiToken: ${{ secrets.CLOUDFLARE_API_TOKEN }}
          projectName: ${{ secrets.CLOUDFLARE_PROJECT_NAME }}
          directory: dist
          gitHubToken: ${{ secrets.GITHUB_TOKEN }}

やっていく

補足

  • 今回はpushではなく定期実行なので、workflow_dispatchはをつけておくとWEB上からGithubActionsを発火させられてデバッグが楽。むしろつけないと定期実行タイミングにしか動かないのでデバッグが大変。

おわり

  • VercelではBuildをいれてなかったので、最初Buildをすっとばして『distがないよ』というエラーが出て、あれ？distじゃなかったっけ？と何度か確認してしまった
  • VercelもCloudflarePagesも定期再デプロイがﾎﾟﾁﾎﾟﾁでできるようになったらいいなあとは思うが、まああまり需要はないのだろうな
  • Cloudflare Workersを使った方法もあったが、cron用に1つリポジトリを作った方が良さそうな雰囲気になったところで止めた。

cloudflareの*.pages.devを閉じる

cloudflare

astroで作っているサイトをcloudflareに移動した。ドメインはcloudflareで管理しているので、独自ドメイン設定も楽々完了。

 

設定画面を見ていて気付く。独自ドメインを設定したのに、Cloudflare Pagesのデフォルトである『*.pages.dev』が生きている。同じページが違うドメインにあるのは避けたいので閉じたいが、Settingsにそれっぽいボタンがない。

 

行き当たったのがDevelopersIOの下記の記事。

 

dev.classmethod.jp

 

私が求めてるのは上の記事の『2. バルクリダイレクト』の方法だが、普通にページ自体をデプロイしない方法があるはずだと思ってもう少し検索。公式を発見。

 

developers.cloudflare.com

 

『Disable access to *.pages.dev subdomain』の項の2つ目。

 

Redirect the *.pages.dev URL associated with your production Pages project to a custom domain. You can use the account-level Bulk Redirect feature to redirect your *.pages.dev URL to a custom domain.

 

公式でもBulk Redirectの手法が説明されていた。*.pages.devの公開自体をオフにする手段が何らかあると思ってたのだが、公式の説明がこうなら多分ないのだろう、ということでDevelopersIOの記事と同じ手段を実行した。

独自ドメインセットした時にBulk Redirect設定もサジェストしてくれてもよさそうに思うが、違うドメインに同じサイトがあることを特に気にしなくてもいいのだろうか。悩。

 

ランキング参加中
エンジニアグループ

astro view transitionを導入する

最近色々なサイトを見て良い！と思ったのをメモるようにしている。
（メモ → manas-design-input ）

 

その中で『ページ遷移時のアニメーション、最近トレンドかも』と気づいた。

そういえばastroでそういう機能が実装された気がするので、やってみる。

 

公式Docは下記。

 

docs.astro.build

 

Docを見てあまりの記述の少なさに理解が追い付かなかったのだが、本当の本当に、『ページにビュートランジションを追加する』の項の2行を追加するだけで動く。私は前ページで利用しているlayout.astroのheadに追加した。

 

styleの位置変更を含んでるので差分が見づらいがこんな感じ 

 → view transitionを追加 · thetalemon/manasandbox@1e85ec1 · GitHub

 

Beforeはこんな感じだった。ヘッダ以外の部分がぱっと変わる感じを確認してほしい。

view transition導入前

 

Afterはこちら。おわかりいただけただろうか。
ヘッダ以外の部分がすこしふんわり変わるようになった。

view transition導入後

 

これがたったの2行追加だけで実現されるなんて良い時代だなあと思う。

このアニメはデフォルトの『fade』というアニメーションである（ドキュメントのview transitionのページの『組み込みディレクティブ』の項に記載されている）。slideも試してみたが、slideを採用するなら『トップに戻る』はスライド方向を逆にしたい気持ちが湧いてしまったので、今回はデフォルトのfadeをそのまま採用した。アニメーションのカスタマイズも簡素ではあるが可能なので、『さっと消えてふわっと出る』とかもできるかもしれない。

 

カスタマイズ無しのfadeでもちょっと凝ってる感を演出できるので、2行だけだが追加してみるといいかもしれない。

 

 

話は変わるが、はてなブログではmp4をアップロードできないので、AdobeのGIFに変換ツールを使った。2つ目のファイルを変換するにはリロードをするしか手段がなさそうなシンプルなつくりだが、変換が早い上に変換後サイズも選べてネットにアップロードするのに向いているので紹介しておく。

https://new.express.adobe.com/tools/convert-to-gif

スクロールに応じて画像がふわっと拡大するやつの実装メモ

スクロールに応じて、画像がふわっと拡大する | manasas ui sandbox

というのを実装してみた。GSAPは『知ってればすぐ実装できるが、情報にたどり着くまでに時間がかかる』ことが多いので、数こなしたら表現の幅が広がって楽しくなれそうだなあ、という印象。

実装は結構単純。Github

jsはこれだけ

  import { gsap } from "gsap";
  import { ScrollTrigger } from "gsap/ScrollTrigger";
  gsap.registerPlugin(ScrollTrigger);

  gsap.fromTo(
    ".js-animation-section",
    {
      width: "25vw",
      height: "25vw",
      borderRadius: "50% 50% 50% 50%",
    },
    {
      width: "100%",
      height: "100vh",
      borderRadius: "0%",
      scrollTrigger: {
        trigger: ".js-trigger",
        start: "center center",
        scrub: true,
        pin: true,
        // markers: true,
      },
    },
  );

htmlは実装に関わる部分はこのくらい

    <div class="main-visual js-trigger">
      <img
        class="main-image js-animation-section"
        src="https://source.unsplash.com/CakC6u4d95g/2400x2400"
      />
    </div>

スクロール量にあわせて変化するscrubというオプションを見つけるまで少しインターネットをさまよった。
あとは『大きさが変化する対象そのもの』ではなく、『変化後の大きさに合わせたWrapperコンポーネント』をtriggerに指定するのがコツだろうか。
startやscrubは『triggerに対しての位置/スクロール量』みたいな感じなので、triggerの大きさ変更はバグの元になりやすそう。

markersをデプロイ時にコメントアウトしたり消したりが嫌なので、後でastroでdev/buildを見分ける方法探してデプロイ時には勝手に消える/dev起動中は出る、みたいにしておきたい。
おわり。