Posts

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

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

例えば enum Example { 緑茶 麦茶 紅茶 珈琲 } というEnumを使って比較をする時に、 if(key === +Example.緑茶) という比較を書くか if(Example[key] === "緑茶") という風に書くかどっちがいいのかがわからなかったので調べてみた。 if(key ===Example.緑茶)のほうが保守性が高い 理由としては、まずExample.緑茶という風に書くことで型推論が効きタイポが起きにくくなる。 Example[key] === "緑茶"と書くときは型推論が効かないので、青茶って書いても何も教えてれない。 if (Example[key] === "青茶") { } こう書いてもエラーが出ない。 これ以外にメリットがありそうだったけど、これが最大のメリットな気がする。 そういうことでEnumを直接比較したほうが良い。

10月に読んだ本 失恋覚悟のラウンドアバウト 15日にデスマーチから帰還し、読書を再開した。 なんか馬鹿馬鹿しい本が読みたいと手に取った本で、期待通りに馬鹿馬鹿しかった。 今の自分にはちょうどいい。 ブログを再開 忙しさにかまけて、というより更新したくても更新できなかったこのブログを、再活性化している。 【2024年8月、9月】とにかく仕事に追われる マストドンでおひとり様サーバーを立ち上げた マストドンのfaviconを変更する appearance-noneってなにか真剣に調べてみた TypeScriptで一回unknwonに変換するのはどういう意味があるのか TypeScriptで出てきたRecordってなに 10月15日から更新を再開し、結構活動的に書いてきた。 というのもやっぱりアウトプットするべきだと再認識した。 アウトプットするということではなく、アウトプットするために調べることが重要で、appearance-noneってなにか真剣に調べてみたでも書いたけど、木こりのジレンマの寓話のように、一見遠回りに思えてもそれが後に生きてくることが、勉強においては多分にある気がする。 そういうわけで精力的にブログを書いていきたい。 ひっそりと終わるブログ そんな中、ワードプレスで作成したブログがサーバーの更新日を迎える。 2年間くらいお世話になったけど、記事の管理をGitHubにしたいがためにさよならしたブログで、更新はしないため一生のお別れになる。 記事効率化のためにワードプレスのプラグインを作成したりとなかなか楽しい経験だった。 create-eye-catch-for-classic 初！ 公開したプラグインに要望が届く そういえば、そんなプラグインにissueが上がっていた。 公開しているプラグインにissueが上がるのは初めてなのでテンションが上がるけど、やらないとという焦燥感がある。 できるかわからなし、もうサイトも閉じ、プラグイン更新する熱量もないけどせっかくなので対応してあげたい。 使ってもらえているのはシンプルにうれしい。 マストドンのサーバーを立ち上げる 忙しい仕事から抜け出し、ぽっと自分時間ができたので、いの一番にマストドンのサーバーを立ち上げた。 マストドンでおひとり様サーバーを立ち上げた レンタルサーバーを借りることはよくあったけど、vpsを借りたのは初めてでまだ何もわかっていない。 ただフルスタックになるにはこの領域の理解も深めなくてはいけないので、いっぱい試行錯誤してみる。 実験的な場にしたい。 ただSNSとして使うのであれば、お金を払いSNSをしているというわけのわからない状況になるので頑張る。 今年の目標１つクリア マストドンのサーバーを立ち上げたことで今年の目標を1つクリアしたことになる。 ネイティブアプリをリリースする 基本情報技術者資格を取る OSS活動にコントリビューとする Mastodonのサーバーを立ち上げる 最後まで達成できそうもないので、次はネイティブアプリリースにする。 ちょうどいいので、マストドンのクライアントをリリースしたい。 今年中はきついと思うけど、リリースまでもっていきたい。 やることが多い 目標クリアにささげられる時間もあんまりない。 子どもができて、仕事が増えて、明らかに自分に使える時間が減った。 つまり今後はどうやって時間の濃度を高めていくかにかかっている。 とは言え、自身の集中力の低さはわかっている。 どうすればいいのか、やっぱりポモドーロとかテクニックを取り入れる必要があるのかしら。 11月はとりあえずポモドーロを実行してみるか、そうしよう。 ポモドーロのルール せっかくのなのでここに明確にしておく。 1クールを25分 1クールで終わらせる量をあらかじめ定めてクールに入る 終わっていようと終ってなかろうと25分でクールは切る クール中に他の事、連絡も含めほかのやることは禁止 やることが終わったらクール完了 クール完了後は飲み物を飲む（なんとなく） 5分間の休憩は何をしてもいいけど、5分を決して超えないようにする 何ポモドーロしたかは記録しておく。 ちょっとこれで11月は試してみる。 どこにポモドーロした回数を記録しておくかは別で考える必要がある。 アプリがあるならそれを活用するのもいいかもしれない。 11月の月報にはいい知らせを載せられるようにしたい。 コロナにかかった そういえば、コロナにかかった。 家族全員で39度出して寝込んだ。 とは言え、特別辛いわけでもなく1日で完治した。...

ChatGPTにコードを書いてもらっていると知らない書き方と出会うことができ、勉強になる。 ChatGPTに書いてもらうことは悪いことばかりじゃないと最近は思うようにしている。 ちょっと前までは反骨心から使ってなかったけど、そう思うようになってからはどんどん活用している。 ただChatGPTを使って学習したことを活用する機会はChatGPTに奪われているけど。 Recordってなに そんなChatGPTが提案してきたコードにRecordという型があったので、どういう型なのか調べてみた。 Record<Keys, Type>はプロパティのキーがKeysであり、プロパティの値がTypeであるオブジェクトの型を作るユーティリティ型です。 とのこと。 例えば、キーがstringで値がnumberのインデックス型を定義するには、 type StringNumber = Record<string, number>; const value: StringNumber = { a: 1, b: 2, c: 3 }; キーがfirstName、middleName、familyNameで、値が文字列になるオブジェクトの型を定義するには、 type Person = Record<"firstName" | "middleName" | "lastName", string>; const person: Person = { firstName: "Robert", middleName: "Cecil", lastName: "Martin", }; こんな感じで使用することができる。 ただ、2つ目の例のようにKeyが確定している型に関しては interface Person { firstName: string; middleName: string; lastName: string; } と何が違うのか。 結果的には同じ構造 上記だと同様の型定義になる。 ただinterface のほうが拡張性が高く、Recordのほうが簡潔に書けるけど、具体的なプロパティ名や構造を明示しにくいとのこと。 じゃあ、Recordはいつ使うのか。 Recordの使い道 Record は多くのキーが同じ型を持つ場合、簡潔に型を定義する時 type WeeklySchedule = Record<"Monday" | "Tuesday" | "Wednesday" | "Thursday" | "Friday", string>; 動的なキーの集合に対して一律の型を定義したい時 type ApiResponse<T> = Record<string, T>; こんな感じで動的なキーの型付けや簡潔なオブジェクト型定義が必要なときに使えるらしい。