例によってFlexiSpotE7とマルトクの天板という王道パターンです。
参考にした記事: DIY初心者がこだわりのPCデスクを作ってみた|Fucas @Flower Photographer|note
DIY初心者なので色々と記事を漁ったわけですが、上記の記事以上に丁寧で参考になるものはなかったです。
例によってFlexiSpotE7とマルトクの天板という王道パターンです。
参考にした記事: DIY初心者がこだわりのPCデスクを作ってみた|Fucas @Flower Photographer|note
DIY初心者なので色々と記事を漁ったわけですが、上記の記事以上に丁寧で参考になるものはなかったです。
なんか話題になってて、なんかおみこしwasshoiする流れになってたのでお気持ちを書き残したくなった。
ですが
内容的にはfor TypeScriptというよりはfor ES nextといった感じで、特に型周りに関する言及が少なめ
eslintのルールが用意されていないので使いたいなら人力運用になる
ゆえにGoogle社員以外がわざわざプロジェクトに導入するのはどうなんでしょうか。手間に見合う価値があるんでしょうか。
だからこれをデファクトにしよう!みんなこれ使えよな!みたいな勇み足はちょっと……
これが言いたかっただけです。
伝えたい…
率直にいってしまえばスタイルガイドは存在しているという事実そのもの、そしてそれが常にチェックされている機構に価値があって、中身はどうでもいいと極論してもいい。
つまり最低限の作法としてプロジェクト内でコードやコメントの書き方が統一されている事自体に価値があるので、例えばどこにどう改行を入れようとかに優劣はなく、それがメンバーの納得に基づいて決定されていればどうでもいいのである。
もちろんプログラミング言語にも色々あって、静的解析がしやすかったりやりにくかったり、そういう文化が発展してたりおざなりだったり……。
ECMAScriptは解析がしやすく、その文化も発展しているので、現代においてはプロジェクトごとにeslintのruleさえ用意しておけばスタイルガイドは不要だというのがオレの意見。逆にRubyみたいな言語は人数が多いプロジェクトであればスタイルガイドがあったほうがいいとはおもう(RuboCop、てめーはダメだ)。
ただし! 上は普通の規模の組織についてのお話。
Googleのように無数の社員とプロジェクトを抱えている組織においてはこういったスタイルガイドの持つ価値は変わってくるので、そのへんは色々と自分で考えていい感じにやっていくといいとおもいます。
しかしながらスタイルガイドについては「ベストプラクティス集」といった側面があったりする。
例えばロジックやシンタックス、そしてlint rule的にもvalidな2つの書き方の間でどちらを採用すべきか……といった問いに答えてくれるようなものだ。
GoogleのPythonやC++のスタイルガイドはかなりベストプラクティス集に近いような趣きがあった(うろ覚え)はずで、当時はかなりお世話になったおぼえがある。
(どういう経緯、どういうステータス*1で公開してあるのかわからない他社のスタイルガイドにケチつける形になるのは心苦しいんだけど)今回のガイドはTypeScriptのベストプラクティス集としてみるとちょっと弱い。
軽く例を上げると
現実的なユースケースにおいてEnumはUnionで代替可能、かつ安全性で勝るので避けたほうが良い。わざわざJavaScriptとの互換性を損なってまで使う機能ではない*2
TypeScriptではswitch caseにdefault節を書くべき ではない パターンが存在する。
例えばUnionおよびTagged Union Typeを評価にした場合、TypeScriptのコンパイラは網羅性をチェックしてくれる。そのため後々Unionの定義を増減させたときに条件のミスマッチをコンパイルエラーとして教えてくれる。
defaultがあるとこれが働かない。
逆に言うとswitch caseで評価する変数は極力Union型に落とし込んでおくべき。
コードの例でClassを多用しているが、Type Guardの書き方について言及がない。
Nominal Typesな型システムを採用している言語に慣れ親しんでいる人は結構地雷を踏む箇所だとおもう*3。
しつこいようだけど僕は自分が関わっていないプロダクトがどんなルールを採用してコードを書いていようがしったこっちゃないので、Googleの社内ルールに文句をつける気は一切ない。
ここで言いたいのはあのガイドで提唱されているスタイルはTypeScriptとしてあまりベストとは言い難いものが含まれていたり、逆に重要*4な箇所の言及が抜けている、ということで、それをわざわざ外部の人間が採用したり、世界に広める意味ある……?ってこと……。
デファクトのルールをTypeScriptのファウンデーションが運用してくれたらいいな、とはおもいます。
ちなみにDecoratorsは"generally want to avoid"なんてもんじゃなくて端的に避けるべきで、Decoratorsが前提となっているだけでそのフレームワークを避ける積極的な理由になる。やめておけ。
コードレビューがくそめんどくさくなるし無価値な議論の火種になるので、筆者はスタイルガイドという存在があまり好きじゃない
最初に作ればあとは自動で運用できるので、筆者はeslintが好き
よほどクオリティが酷くない限りは、スタイルガイドは存在自体に価値がある。しかし外部の人間がそれを輸入するほどの価値はないことが多い
他人が決めているルールにケチをつけるつもりはないですが、我々外部の人間がわざわざ採用する必要があるかというとそういう感じにはみえないのでこれをデファクトスタンダードにすべきだ!みたいな意見にはどちらかというと大反対。
ていうか @typescript-eslint/recommended
以上のルールをいちいち作ろうとするのって普通の人数のプロジェクトだとコスパ悪すぎるからやめたほうがいい
スタイルガイドはそんなに好きじゃないけどベストプラクティス集は好きだし、存在していればクオリティ次第でデファクト化する価値はあるかもしれない
筆者はclassがきらいだけどたまに使わざるを得ないらしい
あっ、そういえばDecoratorsは積極的に避けるべき
以上です。
ちなみにtype or interfaceの議論ですが、筆者はぶっちゃけどっちでもいいです。
どっちにしろ微妙に機能が違うんで完全に統一はできないし。じゃあ共存しよ?
ここ数年まともにサーバーサイドをやっていないなぁとかおもいつつなんやかんやあってNestJSを数日ほど触ったりドキュメントを読んだりしてたので初心を忘れないようにメモ。
いちおうTypeORMだけは出始めにちょっと使ってた。
理解度が高まったら気分が変わるかもしれないです。そしたらもっかい日記書きます。
てか全体的に難易度高くないこのフレームワーク?求められるリテラシー高くない?
前提なんですが、僕はこのフレームワークのことをまだあまり好きになれていません。オブラートを外してのべると、すでに半分くらい嫌いです。
続きを読むそろそろ数ヶ月になるのでざっくり書く。
ぶっちゃけそれほど深い理由はないんだけど札幌に引っ越した。大袈裟な言い方をするなら移住だけど、札幌みたいな都会に移り住むのに適切なワードではないような気がするので引っ越しとしておく。別に終の住処と決めたわけでもなし。
リモートワークは孤独だとよくいわれます。
特にいままでインターネッツ越しに人と関わり合うようなやりかたに馴染みがなかった人は娯楽の共有、ひいては感情の共有ができずに病んでいくなんてこともあるかもしれません。私はオンラインゲーム(LoL)でチャットバトルをしています。
ようは物理的な触れ合い、相棒、家族そういったなにか……
つまりペンギンの不足です。
ペンギンの不在を高級チェアとかスタンディングデスクで埋めようとしてもダメです。
朝の挨拶にはじまり
一緒に出勤
仲間なので同じ釜のホットケーキを食べます(ホットケーキ力が未熟な時代の写真なので焼き過ぎてますね)。
時には意見がぶつかりあうことも……
1日の終わりは飲み会で親睦を深めます。
頭のおかしい満員電車から解放され、真っ白な蛍光灯で目を焼かれることも、強すぎる冷暖房と異常乾燥で唇があれる職場でクソみたいな椅子と狭いデスクに縛られることもない……そんな自宅とかいう最高の作業環境で気を病んでしまう。
そんな貴方に足りなかったのはフワフワした物理的同僚存在だったんですね。
僕は品川水族館で一目惚れして連れて帰ったんですが、通販もあるようです。
AQUA ぬいぐるみ マリン まんぷくっしょん ペンギン M 00270005
ちなみに一番好きなAmazonのレビューはこれです。
5つ星のうち5.0 最高の相棒です。
2017年8月16日に日本でレビュー済み
「しゃちょー」とあだ名をつけ、助手席に乗せています。運転中眠くなっても、代わりに彼が寝てくれるので安心です。 仲良くなりすぎると彼の声が聞こえてくるので注意です。ストレスの元を断つか病院を受診するのがおすすめです。 助手席に乗せた時点で要注意かもしれません。
イギリスの成人3割がテディベアと寝る | Narinari.com (この手の海外では〜〜系記事はだいたい嘘、なんだよね)