例えば 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>; こんな感じで動的なキーの型付けや簡潔なオブジェクト型定義が必要なときに使えるらしい。
as unknown as ? as soon asは「できるだけ早く」で、中学生の時、喉が擦り切れるほどむやみに連呼していた記憶がある。 おかげさまで、この意味を30歳超えても忘れていない。 だが、as unknown asは知らなかった。 そもそもunknownってなに？ unknownは型が分からないときに使用するらしい。 つまりそれってanyではと思うし、間違っていない。 その両方ともどのような値も代入することができる。 const any1: any = null; const any2: any = undefined; const any3: any = true; const any4: any = 0.8; const any5: any = "Comment allez-vous"; const any6: any = { x: 0, y: 1, name: "origin", }; const unknown1: unknown = null; const unknown2: unknown = undefined; const unknown3: unknown = true; const unknown4: unknown = 0....
appearance-noneはOS レベルのスタイル制御するもの ウェブフォームのスタイル設定はOSレベルで設定されている。 そのため、コントロールの見た目のカスタマイズの問題の一部となっていた。 appearance-noneは適用したコントロールがシステムレベルのスタイルを使用することを可能な限り止め、 CSS を使用して自分でスタイルを構築できるようにするプロパティ。 フォームへの高度なスタイル設定ほぼこれに書いてあること、そのまま。 CSSの上書きと何が違うのか appearance-noneでは ボタンやフォーム要素のデフォルトスタイルを即座に取り除き、開発者がカスタマイズするベースを作ることができる。上書きだと個別に上書きするのは手間がかかかるので、その点便利なプロパティとのこと。 なんとなく使っていたので、はじめてその有用性に気が付いた。 ポエム 木こりのジレンマ 最近というか今更というか、木こりのジレンマなる寓話を思い出した。 ある日、森で一生懸命に木を切っている木こりがいました。彼は朝から晩まで休むことなく木を切っており、疲れ果てています。それでも、木を切るのにとても時間がかかっているため、彼はさらに焦っていました。 そこへ通りがかった旅人が木こりに話しかけました。 「あなたの斧はとても鈍くなっているようですね。少し休んで、斧を研いだ方がいいですよ。」 木こりはその言葉にイライラして答えました。 「そんな時間はない！見ての通り、木を切らなければならないんだ！斧を研ぐ暇なんてないんだ！」 旅人は木こりにもう一度諭しました。 「でも、斧が鋭くなれば、木をもっと早く、もっと簡単に切れるはずですよ。少し休んで斧を研いだ方が、結果的に仕事が早く終わるでしょう。」 木こりは依然として目の前の仕事に集中しすぎて、斧を研ぐことの重要性に気づかず、疲れ果てたまま非効率に仕事を続けました。 この寓話は、効率的に物事を進めるためには、短期的な忙しさに囚われず、道具や方法を改善する時間を取ることの重要性を説いている。 そしてこれの話がとても心に響いた。 プログラミング中、忙しい時は特にその場しのぎの解決策に飛びつき、特に考えることなく実装する。 結果的にその案件は完遂するけど、身につくものをいくつか取りこぼしている。 なのでこれからは、気になったことはどんどん調べ、ここに備忘録として残していく。