request specを新たに追加するとき、これまであまり意識せずにファイル名を/複数形_spec.rb（ex. /users_spec.rb）としていたが、既存のrequest specで単数リソースの場合には/単数形_spec.rbとしているものもあることに気づいてどうすべきか迷ったことがありました。
という相談をしたところ、
「rspec-railsについてくるジェネレータは複数形で作るようになっている（pluralizeしている）ので、複数形で問題なさそう」
https://github.com/rspec/rspec-rails/blob/v6.0.1/lib/generators/rspec/request/request_generator.rb#L13
target_path('requests', "#{name.underscore.pluralize}_spec.rb")
とコメントを頂いて、根拠の探し方が勉強になりました。
1章 イントロダクション
2章 TypeScript：全体像
3章 型について
4章 関数
5章 クラスとインターフェース
6章 高度な型
7章 エラー処理
8章 非同期プログラミングと並行、並列処理
9章 フロントエンドとバックエンドのフレームワーク
10章 名前空間とモジュール
11章 JavaScriptとの相互運用
12章 TypeScriptのビルドと実行
13章 終わりに
TypeScriptの概要や用語、型が安全になるとどう有益なのかが説明されていて勉強になりました。
全体としては詳細な説明やコードの例が割合多く掲載されていて、今後書くときにリファレンスとして使うことも多そうだと感じました。
let a: number = 1 let b: string = 'hello' let c: boolean[] = [true, false]
type Age = number type Person = { name: string age: Age } // Ageはただのnumberだが、これによってPersonという形状の定義が理解しやすくなるメリットがある。
タプル
// 名前・名字・生まれ年のタプル let b: [string, string, number] = ['taro', 'yamada', 1995]
呼び出しシグネチャ
(a: number, b: number) ⇒ number
// function greet(name: string) type Greet = (name: string) => string
オーバーロードされた関数
type Reserve = { (from: Date, to: Date, destination: string): Reservation (from: Date, destination: string): Reservation } let reserve: Reserve = ( from: Date, toOrDestination: Date | string, destination?: string ) => { // ... }
インターフェース - 型エイリアスと同様に、型に名前をつけるための方法
第1章 オブジェクト指向はソフトウエア開発を楽にする技術
第2章 オブジェクト指向と現実世界は似て非なるもの
第3章 OOP を理解する近道はプログラミング言語の歴史にあり
第4章 OOP は無駄を省いて
第5章 メモリの仕組みの理解はプログラマのたしなみ
第6章 OOP がもたらしたソフトウエアとアイデアの再利用
第7章 汎用の整理術に化けたオブジェクト指向
第8章 UML は形のないソフトウエアを見る道具
第9章 現実世界とソフトウエアのギャップを埋めるモデリング
第10章 擬人化して役割分担させるオブジェクト指向設計
第11章 オブジェクト指向から生まれたアジャイル開発
第12章 オブジェクト指向を使いこなそう
補章 関数型言語でなぜつくるのか
以上のような経緯で、ソフトウエア危機に対応するため、さまざまなアイディアや新しい言語が提案された。
構造化言語では解決できない問題を打破したのが OOP（Object-Oriented Programming）だった
OOP は決して従来のプログラミング技術を置き換えるものではなく、以前のものを基盤として欠点を補い、品質が高く、保守しやすく、再利用しやすいソフトウエアを作るために考案されたものである。
優れた設計のアイディアを、後から再利用できるように名前をつけて文書化したもの。
OOP によって汎用性の高いソフトウエア部品群の再利用と、アイディアやノウハウの再利用の2つの再利用技術がもたらされた。
chapter01 ファシリテーション − 変革リーダーのコアスキル
chapter02 議論の大きな骨格をつかむ
chapter03 参加者の状況を把握する
chapter04 「論点」を広く洗い出し、絞り、深める
chapter05 合意形成・問題解決のステップでファシリテーションを実践する
chapter06 発言を引き出し、理解する
chapter07 発言を深く理解する
chapter08 議論を方向づけ、結論づける
chapter09 対立をマネジメントする
chapter10 感情に働きかける
chapter11 ファシリテーションは「合気道」
本書は、課長や部長など上司の立場の人間が、部下たちに意欲的に会議へ参加してもらいたいといった場合における、リーダーとしてのスキルを説明している。
メンバーの腹落ち感を作るための核となる、コミュニケーションの営み
「目的と理由」を深く理解し、「具体的なあるべき姿」を自ら描き、「ワクワク感や当事者意識」を持てるレベルで納得すること。
アクション（行動）に向けた合意の形成
会議を行う理由が明確になると、腹落ち感も向上する。
「私はB部長の意見をこう受け取ったのですが、実際に実行されるAさんからするとそれで大丈夫ですか？」
（もしAさんが反論を述べてそれにB部長が反発を覚えても、いざとなればファシリテーターのまとめ方のせいにできる振り方）
メンバー全員が議論に参加している状態を作り、誰も「聞くだけのその他大勢」にならないように努力する。
ということ。
議論されるテーマ自体から、その問いの答えを出すにあたって判断を左右するポイントを洗い出す。 階層化ができたら、議論すべき論点とそうでない論点の峻別し、絞り込む。 議論の最初のポイントは、その論点についての議論は議論のゴールに至る上で、合意形成の必要があるかどうか。
# 論点の階層化例）
我がチームは〇〇選手を獲得すべきか？
- 獲得したい選手か？
- 能力は高いか
- テクニックはあるか
- 体力はあるか
- 人気はあるか
- ファンサービスを行なっているか
- 我がチームは獲得できるのか？
- 希望年俸は払えるのか
- 在京チーム志望ではないか
参加者が論点を明確に意識し、正しく共有した状態で議論が進むことはそう多くない。
ファシリテーターはそんな状況下で適切に進行することが求められる。
（💭とても共感した）
最初は why ではなく where
ファシリテーターが問題について当事者意識を強く持ち、多くの論点や切り口、仮説を持つ必要。 答えはメンバーに出して貰えば良いので、ファシリテーターが全て用意する必要は無い。
where がでたら why
まずオプション（出された選択肢）を評価する基準について合意する必要がある （ex. 効果の大きさ、スピード、工数、コストなど何をもって決めるか）
「いつ、誰が、何をするのか」を具体化し認識を揃える。 （💭 当たり前にも感じられるが、欠如しがちらしい）
どれだけ具体的にプランニングしても、作業に着手すると遅延や調整すべき点は出る。 要協議・決定事項が生じた際に、「誰がいつどのように決めるのか」を合意しておく
など。 ファシリテーターが以上を意識することから生まれる「本当に聴きたいという姿勢」 人間は自分の話を聞いてくれる・理解しようとしてくれる人の方が話をしたいと感じるもの
発言には論理的目的だけでなく心理的・感情的側面の目的もある。 （自分の存在をアピールしたい、喜びや悲しみ・怒りを理解されたいなど） ここに目を向けることで、真意を掴みやすくなる
相手の主張が理解できないのは何故か、合意形成のために何の確認が必要なのか、論理のどの部分に合意が必要なのかといった点を具体的にして、議論が進むよう促すことが必要。ファシリテーターはこのような話の聞き方が必要。 揚げ足を取るとか批判をするのではなく、正しい意思決定のためにあるべき論理を追求したいという態度。
ファシリテーターが議論すべきと思っている論点が話題に出ると、反射的に自分の意見を述べたりして、メンバーの発言機会を奪ってしまうことがある。 活発に発言している状態であれば、ファシリテーターは参加者が自由に発言できる空気を保つためにSTAYが良さそう。
話の広げ方のワーディングに注意
言葉選びを誤ると、メンバーの思考を意図しない方向へ誘導してしまう
議論を効率的に進めて、メンバーの集中力を維持するために以下を実施
「XX という論点について 〜〜 という意見ですね」 「XX という論点について結論を出すためには、〜〜 という論点について考える必要がありそうですね。」 「では 〇〇 という論点についてはどう思いますか」
などと自然な修正を試みる。
その議論を止める必要性を相手に気づいてもらうというスタンス。 今議論すべきでない論点への対応は、まず発言者の意見を論点に転換し、明確にすることからスタート。
行動につなげる。決まったことと決まっていないことを峻別して示し、そして誰がいつまでに何をするのかを明確に表現して、メンバーに確認する。
を明らかにした上で、「残された課題を解決し、次回合意に至るためにはどうなれば良いのか？」を明確にした「条件付き合意」を形成する
ステップは次の通り
対立が発生する主な理由は、
合意可能なレベルまでその業務の目的やあるべき姿を遡り、段階的に合意をつくっていく。 （ex. 営業・生産はそもそも何のためにやっているのか、より上位の方針上、今は何が重要なのかを問いかける）
といった振る舞いを心がける
立場が異なると優先する価値判断が異なるといったような忘れがちな前提の話から、話の振り方の具体例など細かいところまで言語化された説明がなされていて、とてもわかりやすかったです。
大きなポイントとして、ビジネスにおける議論の目的は「行動の決定」であることを再認識できました。
また、自分がメンバーの時にメンバーの役割を果たすようにしたいと思いました。
どういう発言や行動が求められて、自分がこの議論の場に呼ばれているのかを意識したいです。
さらに、ファシリテーターが論点や方向を見失っているかもしれないと感じた時に、それを思い出させるといった、補佐するような役割もできたら尚よさそうだと感じました。
（文中でも、ファシリテーターは「今この議論を続けるべきか」「他の論点に移るべきか」「意見を述べたそうにしている人はいないか」等々非常にいろんなことを考えていて、キャパシティがほとんど残っていないことも多いとあった）
「今って〜〜の話でしたっけ」みたいな確認程度でも、ファシリテーターやメンバーに気づきのキッカケを与えられたりしそうだと思いました。
今回は上司としてのリーダーが参加者である部下をまとめることが主な事例で、今の自分の立場やスタンスとはやや異なる部分もあったので、 ぜひ他のファシリテーションの書籍も読んでみたい。
range を使ってできました。
(' '..'~').to_a.join # => " !\"\#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\\]^_`abcdefghijklmnopqrstuvwxyz{|}~"
使用できる文字をASCIIの0x20から0x7Eまで（半角空白を含む半角英数記号）に制限したいことがありました。
ググっても目ぼしい情報を見つけられず手で直接書いていたのですが、 抜け漏れがないかどうかの検証も難しく、 なんとか機械的にできないものかと考えていたところ、この書き方を教えてもらってとても便利🥺と思いました。
メタ文字をエスケープして期待通り使用できました。
> ASCII_PRINTABLE_CHARS = (' '..'~').to_a.join > /\A[#{Regexp.escape(ASCII_PRINTABLE_CHARS)}]+\z/ # => /\A[\ !"\#\$%&'\(\)\*\+,\-\.\/0123456789:;<=>\?@ABCDEFGHIJKLMNOPQRSTUVWXYZ\[\\\]\^_`abcdefghijklmnopqrstuvwxyz\{\|\}~]+\z/
文字コードを使っているんだもんなあと後になって強く感じました。
("0x20".to_i(16).chr.."0x7E".to_i(16).chr).to_a.join => " !\"\#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\\]^_`abcdefghijklmnopqrstuvwxyz{|}~"
1章 DBMSのアーキテクチャ 〜この世にただ飯はあるか
2章 SQLの基礎 〜母国語を話すがごとく
3章 SQLにおける条件分岐 〜文から式へ
4章 集約とカット 〜集合の世界
5章 ループ 〜手続型の呪縛
6章 結合 〜結合を制するものはSQLを制す
7章 サブクエリ 〜困難は分割すべきか
8章 SQLにおける順序 〜甦る手続型
9章 更新とデータモデル 〜盲目のスーパーソルジャー
10章 インデックスを使いこなす 〜秀才の弱点
「駆動表に小さなテーブルを選ぶ」。
上記の通り、結合を使うことは、変動リスクを抱え込むこと。ウインドウ関数などで代替してパフォーマンスを改善できる可能性がある。
トレードオフの話が多く「〜〜場面ではXXを優先してOO対処をする」のような考え方にたくさん触れることができ、こういう言語化をできるようになっていきたいと感じました。
また、UIにおいて検索時の必須フォームを作ることで検索時の絞り込みが効くようにし、インデックスを使って良いSQLが発行されるようにする話について、「そっち側からののアプローチもあるのか」と非常に面白いと思いました。
