Angular Advent Calendar 2021の23日目です。
最近書き始めた薄い本の最初のページを無料公開したので、アドベントカレンダーの投稿ということで納めさせていただこうと思います。
最初はAngularの中核にあるViewという概念について、本質的な理解につながるよう解説しました。 『Angularの基本語彙』は決して入門本ではないですし、Angularアプリケーション開発の実務に役立つものでもありません。Angularがどのように機能しているのか、そのメカニズムを理解しようとする人にとっての足がかりになるようなものに育てていければと思っています。 興味があればぜひ読んでみてください。
余談ですが、来年もAngular日本ユーザー会のオンラインイベントng-japan OnAirもよろしくおねがいします！
SHIROBAKO Advent Calendar 2021 - Adventarの13日目です。
僕はアニメや映画で何度見返しても同じ場面で泣いちゃう爆弾をいくつも涙腺に抱えているんですが、SHIROBAKOの第23話はそのうちのひとつです。
今日書きたいのは、このシーンがいかに感動的なものなのかという評論ではなくて、なぜ僕は毎回このシーンで泣いてしまうんだろうという内省です。
結論から言うと、僕はこのシーンにおいて「おそらく彼女らの人生において一回しかないであろう、これまでの時間とロマンとが一体となった『成就』の実感、その儚くも偉大な瞬間に立ち会えたことの喜びと哀しさ」を感動として実感しているのだと思っています。
哲学のゼミで『感動』とは何かということについて考える本質観取に参加したことがあります。 そのときに『感動』には「奇跡型」と「軌跡型」があるのではないかという提起がされたのが印象に残っています。
奇跡型の『感動』というのは、自分の予想を裏切ったり越えたりしてくるような、超越的・圧倒的な事象との出会いに感じるものです。 一方、軌跡型の『感動』というのは、積み上げてきた時間や経験、つまり自分自身が、手が届かないと思っていた「ほんとう」と接続し、一体となった感覚から覚えるものです。 ロマンとの一体感、「つながった」実感。これまでの時間はこれと出会うためにあったんだと思うような昇華の感覚。そういう種類の感動もあると思います。
宮森はずかちゃんのこれまでの軌跡を知っている身として、ずかちゃんにとっての夢、ロマン、「ほんとう」の小さくも確かな成就を自分ごとのように実感し、共涙を流したんだろうと思いますが、この瞬間にロマンとつながったのはずかちゃんだけではなく、宮森自身もそうだと思います。宮森にとって自分ではどうしようもない手の届かないところにあった「アニメ同好会のみんなでアニメを作る」という夢（ロマン）が、突然目の前に現実のものとして到来したわけで、宮森自身にとってもロマン、「ほんとう」と出会った瞬間であるわけです。 そんな世界が変わるような瞬間は彼女らの人生において何度も起こることではなく、もう二度と訪れないかもしれない偉大なものです。そして今感じているこの実感も時間がたって思い出になっていく。そんな儚さと切なさ、『最期』の感覚が、その瞬間をたまらなく尊く、愛おしいものにします。
そうして、僕は喜びと同時に哀しさも同居した感動を、このシーンから呼び起こされてしまうわけです。 アニメの素晴らしいところは、彼ら彼女らにとっては一度きりのその瞬間を、僕は何度も体験できるところです。何周しても毎回同じ場所で感動してボロボロ泣いてしまいます。もう完全にわかっているのに感動してしまうのは、やはり感動に「奇跡型」と「軌跡型」の類型があることを実感させてくれます。
これ何の話だったんでしょうね。 SHIROBAKOアドベントカレンダーは折返したばかりですので、14日目の記事をお楽しみに！
先日 Front-End Lounge #2の基調講演として喋らせてもらった中で触れた基本的な原理について、汎用性が高く単体で参照したくなることが予想されるのでこの記事で簡潔にまとめることとする。
『フロントエンドエンジニアの価値はどこから生まれるのか』の発表資料です。https://t.co/hnwq1rMnPc#FELounge
— lacolaco / Suguru Inatomi (@laco2net) 2021年12月6日
（この基調講演の内容についてはまた別途ブログ記事の形で再編する予定である）
頭の中にベン図を思い浮かべてほしい。 よくあるベン図では外側に全体集合があり内側に部分集合が描かれるが、普通のベン図と違うのは全体集合の輪郭が曖昧であることだ。つまり無限に広がる空間である。
部分集合の境界をどのように定めたとしても、それが部分である限り、補集合の輪郭は常に曖昧でありつづける。 当たり前ではあるが、この原理は集団における役割についても同様に考えることができる。
ある集団において発生する責任範囲が曖昧である（無限である）とき、その責任を果たそうとするならば、責任範囲を明確に定めない補集合的な存在が必要条件になる。
責任範囲が有限であるならばその範囲内でMECEになるよう分担すればよい。しかし、無限の責任範囲の中で明確な役割を定義することは補集合の総量をいくらか減らすことには貢献しつつも、補集合のすべてを無くすことはできない。
この原理を踏まえると、例えばCTOなどの役割において典型的に見られる「会社や組織によって責任範囲が違う」ということも、その本質が組織における補集合の技術的範囲をカバーする役割であるからと考えれば当然のことである。CTO以外の役割がどのように定義されているのかが組織によって違うのだから、補集合の形状も当然違うのである。仮にCTOが明確に責任範囲を定めるとすれば、それによって生まれる補集合はまた別の誰かが担うか、あるいは誰からも拾われず責任を果たせないことになる。
このような現象はCXOなど組織の上位だけで起きることではなく、どんな集団でも発生しうる。その一例が基調講演で触れたフロントエンドとバックエンドの分業の例である。 ところで、勘違いされないように念の為明言しておくと、バックエンドにはバックエンドの曖昧さが当然ある。アプリケーションの開発という曖昧な責任範囲の中である程度境界づけられているが、フロントエンドとバックエンドは互いに曖昧さを抱えており、その種類が分離されていると見るのが妥当である。この話の要諦は、分業単位が互いに責任範囲を明確に限定したときにはその外側に補集合が生まれるということである。したがって少なくともどちらか一方は曖昧な責任範囲である必要がある。そして現実には多くの場合双方がある程度曖昧である。
以上述べたように、集団の中で役割を定義しようという際には、まずその集団の責任範囲が有限であるか無限であるかを前提とし、有限であるならば隙間が生まれないように分割できるが、無限であるならば明確な役割定義によって生まれる補集合を誰が担うのかを先んじて定めることが必要であるだろう。
2年くらい前までは控除の上限いっぱいまでふるさと納税していたが、去年から減って今年はまったくしなくなった。 じゃあ税金の控除やめたのかというとそうではなく、代わりに都の認定NPO法人に寄附をしている。
ふるさと納税も「納税」と呼ばれているが実態は地方自治体への寄附なので、確定申告のときの手間はほとんど変わらない。（ワンストップみたいな制度はないので確定申告必須になるが。）
控除の計算式は微妙に違うらしいが、もともと僕はそこまで計算してやってたわけじゃないので別に問題ない。
寄附金控除の対象となる団体はけっこういろいろある。僕はLiving in Peaceという団体の「こどもプロジェクト」に毎月寄附をしていて、それでだいたい寄付金控除の上限になるのでふるさと納税はしなくなった。
納税先の都道府県が認めた「条例指定寄付金」というやつじゃないと所得控除はできても税額控除はできないようなので、寄付先が条例指定の団体かどうかはかならず確認したい。
東京都の条例指定寄付金 => https://www.tax.metro.tokyo.lg.jp/kazei/kojin_ju/shitei_list.pdf
思想としては、まあまあ収入があるが物欲があまりないために全然消費者として経済活動できてないなあと感じていて、自分より経済活動のポテンシャルが高い人たちに代わりにお金使ってもらえたらいいかなという思い。それで自分の税金もちょっと減るならWin-Winである。
ふるさと納税にときめかなくなってきた人がいたら、他に自分にあった寄付先がないか調べてみてもいいと思う。
コードレビューに限らず、いろいろなレビューがいろいろなプロセスに組み込まれている。
だが、レビューにおいて、たとえ内容に瑕疵があっても承認されるなら、そのレビューは単なる形式・儀式に過ぎない。 "何かを保障するためのプロセス"としてのレビューを機能させることを目的とするなら、そこには却下の可能性があることが必要条件だ。
保障: ある状態がそこなわれることのないように、保護し守ること。(https://kotobank.jp/word/%E4%BF%9D%E9%9A%9C-630029)
そのようなレビューにおいて、レビュアーは「これは承認しても大丈夫か」と思考する。 「承認しても大丈夫だ」という確信を得るということは、裏返せば「却下すべき理由がない」という確信を得ることである。 その確信が得られるのは「却下すべき理由を探したが見つからなかった」ときである。
つまりレビュアーに承認を求めることは、「却下すべき理由を探す」ことを求めているのである。 そして「却下すべき理由を探す」ということは、その事柄に対して批判的・悲観的な立場に立つことと同じである。 「保障プロセスとして機能するレビュー」において、レビュアーは間違いなく批判者である。 レビューで批判的立場から却下されるということは、そのレビューが保障プロセスとして機能していることの表れともいえる。
※あくまでも＜事柄＞に対しての批判であり、レビュイーの＜人格＞への批判は求められることではない。
たとえば専門家のような権威勾配のあるレビュアーからの批判的な意見は、レビュイーにとってプレッシャーとなることは容易に想像できる。 だが、専門家も専門家であるからこそ自身の承認の重さを自覚しているために、いっそう批判的立場を緩めないように気を張っている。 そのレビューが保障のプロセスであるため、専門家が専門家であるために、そこに「お手柔らかに」は通用しないのである。
その前提を踏まえた上で、レビューを依頼するときには「承認をもらいにいく」（支持してほしい）のではなく、自分とは違う視点から「検証してもらいにいく」（見落としを見つけてほしい）というマインドでいること、それがレビュアーに対して優しさを期待することに諦めがつく気の持ちようではないかと思う。
また、レビュアー側も「保障プロセスとして機能するレビュー」にするために批判的立場からコメントすることをあらかじめエクスキューズしておくことで、不都合な衝突を起こすリスクを減らすことはできるだろう。
コードレビューは「誰かのコード」を「みんなのコード」にする工程
— lacolaco👑 (@laco2net) 2019年12月18日
