仮実装
- ベタ書きの実装
- 「心理的な安定を得て」，「スコープを制御できる」
三角測量
- 不安なときに，二つの以上の例があるときに，一般化をおこなう
- 本当にわからない時だけおこなう
明白な実装
- シンプルな操作を実装するには，そのまま実装する
- 仮実装や三角測量が作る中間地点は，特別に重要というわけではない
  - 何を書くべきかわかっていて，すぐに書けそうなときには，そのまま書く
- ただ，「きれいな動くコード」を最初から書くのは難しい

感想

以前，「知識ゼロから学ぶソフトウェアテスト」を読み終わったときにテスト駆動開発という考え方を知りました．
軽く調べてみたら，この本がバイブル的なポジションだったので購入．

テスト駆動開発はテスト手法だと思って読んだら，まったくそんなことはなく，「TDD はテスト技法ではない，分析技法であり，設計技法であり，実際には開発のすべてのアクティビティを構造化する技法」
と最後に記述してある通り，個人のテクニックに分類されます．

実際にプログラミングで意識してみると，コーディング中に「不安」があることに気付きました．
テスト駆動開発は慣れないと，単純にコーディング量が倍になるのでスピードダウンがおきます．
しかし，それ以上に不安なく次のコーディングに移ることができることのメリットは大きいです．
加えて，ソースコードが長くなるほど最終的なリターン（保守性，コーディングスピード）は大きくなります．

本書の内容は，第一部でテスト駆動開発の方法，第二部では xUnit の実装，第三部では用語の説明になります．
第一部は Java で書かれ，第二部は Python で書かれています．
リーダブルコードや GoF 本なども Java で書かれているので，会社の研修などで学んだ Java はこういうとき便利ですね．
第二部の xUnit はテストツールの自作になります．少し難しい内容に感じましたが，本書に書いてある通り新しいプログラミング言語を学習したときにできるとメリットが大きそうです．
第三部で書かれている通り，テスト駆動開発はライブコーディングやペアプロで学んだ方がいいと思うので，翻訳者がいう通り，第一部を写経（あまりプログラミング学習で好まれないが）した方がいいと思います．
第三部にテスト駆動開発で重要なことをまとめて記述しているので，第三部 -> 第一部 -> 第二部の順番で読む方がいいかもしれません．

全体的に通して，内容は難しすぎないが実際に手を動かさないとわかりづらく身につきづらい部分が多いと思います．
テスト駆動開発についてを網羅的に解説されているので，この一冊で十分な内容です．

2021-02-27

「トライアローグ」感想

アウトプット美術展美術展感想

2 月 27 日に横浜美術館で開催されている，「トライアローグ」にいってきました．

概要

トライアローグは，横浜美術館，愛知美術館，富山美術館が共催のコレクション展です．３つの美術館が，コレクションを持ち寄り，横浜美術館では 2020 年 11 月 14 日（土）から 2021 年 2 月 28 日（日）まで開催されます．
テーマは 1900 年代，20 世紀のアートが展示されています． 1900 年代初頭のピカソをはじめとした画家の説明から始まり，第二次世界大戦が与えた影響，そして近代アートの三部作で展示されています．

感想

「ブルーピリオド」の作者，山口つばさ先生が画集に関与しているとのことから観に行きました．
「トライアローグ」に行ったのは２回目です．１回目は 2020 年の 11 月に行きました．
横浜美術館は「トライアローグ」が終了したら二年間に及ぶ改修工事が始まります．
そのせいか，とても混んでいました．１回目と２回目の大きな違いはスマホで解説が見れるところですね．
すでに画集を購入したので利用はしませんでしたが，抽象的な作品が多いので初見の方には有効活用できそうです．
他の美術館（愛知美術館，富山美術館）では最初から導入されていそうですね．

展示の一番最初はピカソの絵から始まります．
ピカソといえば抽象画が有名ですが，活動初期は比較的普通の絵を描いていました．
その後，彼の心情とともに徐々に有名な抽象画を描くようになったことがわかります．

その後は，ピカソの影響を受けた抽象画が続きます．
絵画だけでなく，1900 年代の有名なオブジェも展示されているのが「トライアローグ」の特徴です．
作品名とオブジェの関連性を考えるのも一つの楽しみ方でした．

次に 1930 年以降の作品が展示されています．
第二次世界大戦の影響を受けた製作者による作品になります．

ここでは「トライアローグ」の目玉の一つである，「王様の美術館」が展示されています．
「王様の美術館」を観てストーリーを考え投稿するコンテストが実施され，今はその入賞が紹介されています．

ここで，特に気になったのは，「ポール・デルヴォー」の作品でした．
「ポール・デルヴォー」の作品は，３つ展示されています．
作品の特徴は，「汽車」，「神殿」といった時代が異なるモチーフに加えて「裸婦」という本来そこにいないはずの人物が描かれていることです．
まるで白昼夢のような構図の油彩に惹かれました．

もう一つ気になったのは，「サム・フランシス」の作品でした．
「サム・フランシス」の作品も，２つ展示されています．
「消失に向かう地点の青」の色彩が美しいです．

最後に 1960 年以降の作品が展示されています．
これ以降は絵に限らず，オブジェや写真なども多いです．
ニューヨークを中心に多様化が進んだとのことです．
最後の作品「哲学者の誤り」はニーチェの言葉を石板に印刷するという斬新でメッセージ性の強い作品でした．

まとめ

３つの美術館が共催の「トライアローグ」，
作品数も芸術分野も幅広い内容となっています．
普段みないような芸術作品や作風も取り上げており，とても勉強になりました．
年代別に分けて展示されているので，時代の傾向もわかりやすくて良かったです．
今まで，触れることのなかった作品も好きになるかもしれせん
所要時間は二時間ほどでした．
画集に掲載されている，山口つばさ先生が執筆したブルーピリオドのおまけ漫画もおすすめです．

トライアローグ語らう20世紀アート

発売日: 2020/11/27
メディア: 単行本

2021-02-21

「さんかく窓の外側は夜」感想（ネタバレあり）

映画映画感想アウトプット

「さんかく窓の外側は夜」を観に行きました．

少し話題になっていたので観ることにしました．

感想を述べていきたいとおもいます．少しネタバレがあります

感想

前知識について

原作はヤマシタトモコさんの漫画みたいですね．

原作のことは知らずに映画を観ました．

役者について

主演は志尊淳さん，岡田将生さん，平手友梨奈さんです．

岡田さんの演技はベテランという感じでした．

志尊さんの演技を観るのは初めてだったのですが，違和感なく観ることができました．

平手さんは響（映画）のときから口数が少ない役が多い気がします．欅坂のときから笑わないアイドル売りをしていたので普段の姿とギャップがなく受け入れることができましたが，欅坂を脱退した今後はどのような役で売っていくのかが楽しみです．

他の役者さんもそれなりに豪華だったのですが，あまり出番がなかったですね．

ストーリーについて

前情報は予告 PV のみで観にきました．

予告 PV だけだと，霊を見ることできる男性と除霊師が手を組んで謎解きをする本格ミステリーだと思ったのですが，まったくそんなことがなく，ファンタジー要素が強かったです．

予告 PV だとファンタジー：ミステリー=2:8 ぐらいだとおもったら 8:2 だったような感覚です．

ストーリー序盤ののテンポはとてもよく，展開の遅さに苛立つことはありませんでした．

ほどよく様々な場面展開で登場人物の掘り下げがあるので，原作未読でも登場人物への理解ができないことはありませんでした．

しかし，メインストーリーのやりたかったことがあまりよくわかりませんでした．

100 分程度の短い時間だと，これぐらいが限界だったのかもしれませんが，敵役にさらわれてそれだけ?とか，主人公が自分の家族に能力について話すシーンやヒロインがあれだけやっといて普段の生活に戻ったり，そもそも呪いのシステムってなんだ？と思ったりツッコミをいれたくなりました．

ラストシーンも続編を意識した作りでしたが，原作が完結してるみたいなので，もっと綺麗な終わり方をして満足感を足して欲しかったです．

最後に

原作を未読ですが，気になったことは，「PV から予測できる内容と実際の内容が大きくことなること」，「ストーリーの大筋をもっとしっかりして欲しかった」ことですね．

ただ，原作を知らなくてもわかりやすかったこと，役者さんの演技が素晴らしかったこと，序盤のテンポがよかった点においてはとても満足できました．

さんかく窓の外側は夜 1 (クロフネコミックス)

作者:ヤマシタトモコ
発売日: 2014/08/19
メディア: Kindle版

2021-02-20

「ジョゼと虎と魚たち」まとめと感想

読書読書まとめ読書感想

「ジョゼと虎と魚たち」（角川つばさ文庫）を読了しました．

まとめと感想について記述していきます．

まとめ

概要

「ジョゼと虎と魚たち」は池辺聖子さんが原作の書籍です．

2013 年 12 月 13 日に実写映画が公開され，2020 年 12 月 25 日にアニメ映画が公開されています．

原作，実写映画，アニメ映画はどれも結末が違います．

アニメ映画は「純愛」推しなのですが，他の２つはまったく異なるみたいですね．

角川つばさ文庫と，角川文庫版の違い．

角川つばさ文庫はアニメ映画の小説版となっており，角川文庫版は池辺聖子さんの原作となっています．

感想

全体的に

「ジョゼと虎と魚たち」はアニメ映画から入り，原作が気になったので購入しましたが，間違えてしまいました．．．

基本的なストーリーはアニメ映画とまったく同じで，少しだけ省略されている箇所がありましたが，気にならないレベルです．

いいと思ったこと

アニメは登場人物の感情描写を繊細に描いていましたが，文字に起こすとよりわかりやすいこと．
- 特にジョゼと恒夫のシーン毎の感情がわかりやすくなる
アニメだとすぐに流れてしまう「魚の名前」や「サガンの作品」が文字に起こされているので調べやすい．

あんまりだと思ったこと

登場人物たちの動作の説明が，アニメをみていないとわからない．
- とあるシーンとかは，そのまま文字におこしたような状態
- アニメ映画を見る方が重要なのであまり気にしない方がいいかも
ジョゼと恒夫とチズ以外の視点がないこと
- 隼人と舞はアニメオリジナルだったと思うので，せっかくだから少しぐらい書いて欲しかった．

最後に

アニメ映画が好きな方なら十分に楽しめる内容にだと思います．アニメシーンを振り返りながら読むと涙腺が熱くなります，

角川つばさ文庫版から読むことはお勧めしないです．なぜならジョゼは絵を書くのですが，それは映像作品じゃないとやはりわかりにくいからです．

原作と実写映画は評価が人によって大きく異なるので，後日読んだり，視聴したいと思います．

アニメ映画　ジョゼと虎と魚たち (角川つばさ文庫)

作者:あきづきりょう
KADOKAWA

Amazon

ジョゼと虎と魚たち (角川文庫)

作者:田辺聖子
KADOKAWA

Amazon

2021-02-14

「プログラマが知るべき97のこと」まとめと感想

アウトプット読書読書まとめ読書感想技術書技術書感想

「プログラマが知るべき 97 のこと」を読了しました．

プログラマが知るべき97のこと

オライリージャパン

Amazon

まとめと感想について書いていきます．

感想

個人的に印象に残ったのは，以下のことです．
- 関数型プログラミング
- 自動化
- テスト
- 学習方法
- DRY 原則
- 働く姿勢
- デザインパターン
- 読みやすいコード
- フロー状態
これらは繰り返し記述されていて，本に掲載されるようなプログラマはその発想に至るまでの経緯は違えど共通認識を持っていると思いました．
「達人プログラマー」という書籍を薦めている人物が複数いたので，今度読みたいと思います．
今後も覚えておきたいことをまとめに記述していきたいと思います．

まとめ

関数型プログラミング

参照透過性の向上が大事
クラスを用いることはミュータブルな変数が増加することに繋がる
関数型プログラミングのパラダイムを学ぶことで他の状況でも役にたつ

ボーイスカウトルール

「自分が最初に見た時よりも，世界を良い場所にすべく努力しよう」(ベーデン=パウエル）
「モジュールをチェックインする際には，必ずチェックアウト時よりも美しくする」

コードレイアウトの重要性

目立たない部分を作る．人間は他と異なっている箇所を一瞬で見つけられる．
レイアウトに語らせる．自動フォーマッタを使う．
コンパクトにまとめる

コメントのコメント

コードは，次に見る人がすぐに理解できるように書く．
読むのに苦労するコードは，コメントも書かずに放置すれば，顧客にも，会社の同僚にも，自分にも害を及ぼす．

学び続ける姿勢

書籍や雑誌，ブログなどを読む
本当に身に付けたい技術は，コードを自ら書き，手を動かして学ぶ
常に自分よりレベルの高い人と仕事をするようにする．
自分の「良き師」になり得る人をネット上で探す．
自分の利用しているフレームワークやライブラリに対する知識を深める．オープンソースならデバッガを使って逐一確認し，中でどういうことが行われているのか確認する．
ミス，バグ，問題について，解決するだけでなく，深く理解する．
自分が学びたいことを人に教えたり，話したりする．
自分が興味をもっている言語，技術，分野に関連する勉強会に参加したり，立ち上げたりする．
カンファレンスに積極的に参加する．オンラインなら無料提供されていることがある
自分のコードスペースに対して，静的分析ツールを実行する．警告がだされる場合に理由を深く追求する．
「達人プログラマー」を読み，学んだことを実践する．本の教えに従い，毎年一つ新しい言語を学ぶ．
新しく学ぶのは，必ずしもコンピュータ関連でなくてもよい．システムが応用されるドメインについて学ぶと良い．「生産性を高める」ものについても学ぶと良い．
学校に通う

言語だけでなく文化も学ぶ

「言語を学ぶということは，ただ文法，構文を学ぶことではなく，その背景にある文化も学ぶこと」
新しい言語を学び，勘所をつかんだら，前から知っていた言語の使い方がそれまでと変わることがある．
新しい言語から新たな発送をえて，同じ問題に対して違った解決策を見つけられるようになることが大事

DRY 原則

重複は無駄である：コードベースが大きくなることを防ぐ
作業の重複は自動化で防ぐ：テストの自動化
ロジックの重複は抽象化で防ぐ：デザインパターンを利用する．
関連する原則：OAOO(Once and Only Once：一度，ただ一度）

オープンソースプロジェクトで夢を実現する．

本当に自分の希望通りのソフトウェアを作っている人は少ない
「オープンソースプロジェクト」への参加は希望に近く方法．
オープンソースプロジェクトに参加することによるチャンス
- 多くの人の仕事ぶりを目の当たりにできる
- 同じ問題を解決するにしてもいろいろな方法があり得ることをしる
- 他人の書いたコードから多くを学ぶことができる
- プロジェクトに自分のコードやアイデアを提供できること
- プロジェクトに大きく貢献できれば「実務経験」になる
- 他人の作ったソフトウェアについて学ぶのに，テストコードを書くほど効果的な方法はない．

ハードワークは報われない

ソフトウェア開発プロジェクトは通常，オリエンテーリングをしながらマラソンをするもの．
プロには，備えるための時間，知識と技術を高める時間が必要．
仕事には長い時間をかけず，集中して短い時間で終わらせるように心がける．

プログラミング言語は複数取得すべき

パラダイムは大きく，手続き型，オブジェクト指向型，関数型，論理型，データフロー型などに分類できる，
違うパラダイムの言語を学ぶことによって，同様のアルゴリズムを実装するにしても，色々なやり方があることに気づく．この体験がプログラマの技術を大きく向上させる．
また，一つのパラダイムしか知らなければ思いつかないような表現を使用することができる．
最低でも二つのパラダイムの言語を使いこなせるようになるべき．五つのパラダイムの言語を使いこなせるのが理想．

いろいろな言葉を学ぶ

一人でこつこつプログラムを書く「職人仕事」の部分はとても小さい．
他人と話し合いながら進めるチームワークの部分が大きい．
話す際に自分の思考を抽象化する力はかかせない．
抽象化こそがプログラミングの核心．

ポリモーフィズムの利用機会を見逃さない

「ポリモーフィズム」は，オブジェクト指向の基礎を成す重要な概念．
元々はギリシャ語で「多数」を意味する"poly"と「形」を意味する"morph"に由来する．
ポリモーフィズムをうまく使えば，オブジェクトやメソッドの特製，動きを，コンテキストに応じて細かく変えることができる．
if-then-else を使うよりもポリモーフィズムを使うことで，コードを読みやすく，またバグ少なくなる可能性が高い．

真実を語るのはコードのみ

「プログラムの動作を完全に性格に知るには，結局ソースコードを見るしかない」
「では自分の書いているソースコードは果てしてどうだろうか」と自問する
「このコードはコメントがなければわかりにくい」と感じたらのなら，コメントを書くよりも，リファクタリングを検討した方がいい．
以下の点でわかりやすくする
1. 見てすぐに機能がわかるような名前をつける
2. 部分同士ができるだけ依存関係を持たないようにすること
3. 自動テストを書いてインタフェースのチェックをする
4. シンプルにする方法がわかった時，現状より少しでも良いソリューションが見つかった時には，即座にリファクタリングする

プロのプログラマとは

プロフェッショナルなプログラマの最大の特徴は「自分が責任を取る」という態度，責任感
キャリアに責任を責任を持つというのは，自分の力で自分の価値を高め，成長していくこと
プロのプログラマは自分の書いたコードに責任を持つ
プロのプログラマはチームプレイヤー．一人一人が自分の仕事だけでなく，チーム全体のアウトプットに責任を持つ
プロのプログラマは，バグリストが一定以上の規模にならないよう，常に注意を怠らない
プロのプログラマは，絶対に，間に合わせのいい加減な仕事をしない．

コードを読む

プログラミングの技術を本気で磨きたいと思っているのなら，本を読むのもいいが，一番いいのは，他人が書いたものでも自分の書いたものでも，とにかくコードを読むこと

シンプルさは捨てることによって得られる

コードはシンプルなものであるべき．
変数や関数，宣言といった構成要素はできる限り減らすべき．
良い部分だけを残して悪い部分は消す，ということも困難なくらいひどいコードであれば，全部消して，はじめから書き直す方がいい．
せっかく書いたものを結局全部消したという記憶が頭のどこかにあれば，次からは無駄なコードは書かないでおこうと無意識に気をつけるようになる．

「イエス」から始める

「ノー」ではなく「イエス」という返答から始めるようにすれば，それだけ物の見方は大きく変わり，仕事の進め方も変わる．「イエス」から始めることは，テクニカルリーダーに不可欠な態度だと考える．
「イエス」という返事の仕方には多くの種類がある．
要望が出されたコンテキストがわかれば，新しい可能性が広がることが多い．実は既存の製品にはまったく手を加えなくても，方法によっては要望に応えられる場合も珍しくない．最終的には要望に応えないとしても，なぜその要望が製品に合致しないのか，きちんとした説明をすれば，実りのある会話ができる．
「イエス」から始めれば，人との対立は生まれず，協力関係が生まれる

面倒でも自動化できることは自動化する

自動化はテストだけのものではなく，バージョン管理，コンパイル，JAR ファイルのビルド，ドキュメント生成，デプロイ，レポート生成などがある．
IDE を使っていれば自動化の必要がなくなるわけではない．個人の IDE の環境を統合することは不可能．
自動化のために特殊なツールを学ぶ必要はない．よく知られたシェル言語(bash や PowerShell など)さえ使えれば自動化システムの作成は十分にできる．
扱うファイルの形式によっては自動化ができないこともある，ことはない．形式によっては，自動化は難しいがプレーンな形式にすることで自動化しやすくなる
自動化を進めながら勉強をするということでかまわない．自動化できる，自動化すべし，と思う作業が見つかる旅に，その自動化に十分なだけの知識を身につければ良い．

テストのないソフトウェア開発はあり得ない

説明するときの比喩として”土木作業”を用いることがあるが，根本を突き詰めると破綻する．
"ソフトウェア開発"の世界では"土木作業”でいう「橋を作ってから重い物を上にのせてみて，耐えられるかどうかを見る」ようなことをする（土木作業ではしない）
テストが，品質保証のための第一の手段．
テストは，ソフトウェアの品質，再現性を保証するためにどうしても必要．

WET なシステムはボトルネックが見つかりにくい

DRY 原則(Don't Repeat Yourself：同じことを繰り返すな）
WET(Write Every Time：必要なものをその都度書く）
DRY 原則を守ことで，パフォーマンスのボトルネックの発見と解消が，WET なコードの場合より容易になる

コードを見る人のためのテストを書く

「自分は誰のためにテストを書いているのか」を考えたとき，「自分のため，バグ修正の労力を少しでも減らすため」あるいは「コンパイラのため．コンパイル作業を円滑に進める」だったとしたら，良いテストが書けている可能性は低い．
「コードを見る人のため」に書く

良いプログラマになるには

どんな場合でも，「とりあえず動きそう」というだけのコードは決して書かない．だれが見ても間違いなく正しいとわかる，美しいコードを書く
わかりやすいコード，保守しやすいコード，正しいコードを書く
他のプログラマと協調する．
自分が扱ったコードは，必ず，自分が最初に見た時よりも少しでも良いコードにする
絶えず積極的に新しい言語，イディオム，テクニックを学ぶ．ただし，学んだことをむやみには使わない．適切と判断した場合にのみ使う．

ペアプログラミングと「フロー」

フロー状態の維持には「ペアプログラミング」が非常に役立つ．
フロー状態の維持に役立つ理由は以下
- 不慮の事態の影響を最小限に抑えることができる
- 問題解決が容易
- 統合がスムーズ
- 割り込みの影響を緩和できる
- 新人が早くプロジェクトに馴染む

ステートに注目する

ステートは非常に重要．何か操作をしようとすれば，まず現在どのステートにいるかを確認する必要がある．
「ステートマシン」という考え方を理解する．
コードを書くときには，テスト駆動開発で個々の操作に適合するステート，適合しないステート，ステート間の適切さを確かめながら開発し，実行時に常にステートが正しく保たれるようにする．
ステートが不適切になる時があるならそれはバグ．

ルーチンワークをフローのきっかけ

「フロー状態」の助走となるルーチンワークを少しだけ用意する．

プログラマが持つべき 3 つのスキル

コードを読むスキル
テストをするスキル
デバッグをするスキル

快適な環境を追求する

身の回りの環境を改善することで毎日の作業が効率良くなり，時間を有効に活用できるようにな，快適にコーディングすることができる

育ちのよいコード

まとまりの良いパッチを作ることで，高凝集と疎結合をすぐに確認できるメリットがある．
リファクタリングによって確認しずらくなる．
リファクタリングとそれ以外の変更を別パッチとしてチェックインすることで折り合いをつける．

No といえることの大事さ

ごく一部であるにもかぎらず，声の大きいユーザからの要望に答えることで，FeatureCreep なソフトウェアになってしまうことがある．
それを避けるために，「No」という勇気が必要である．

名前重要

事物の名前には，理屈では説明しきれない不思議なパワーがあるときがある．
ソフトウェアアプローチとして，「まず名前から入る」