【書籍】Webを支える技術

書籍情報

Webを支える技術 -HTTP、URI、HTML、そしてREST

メモ

ネットワークのことがさっぱり。
GET/POSTもようわからんので、まずはWeb全般の繋がりとして全容を理解できればな、と読んだ。
2010年代の本なので、まぁ古い記述もあるんだろうなと読み飛ばしつつも、技術のつながりについて理解できた。
全5部構成。

第1部 Webとはなにか

いわゆるブラウザの成り立ちから、現在どのような形に落ち着いたのかを語る章。
REST:リソース指向なアーキテクチャスタイル。多分、これはこれで別の本読んで勉強したほうがいい。

第2部 URI

≒URL。
リソースを一意に識別できるデータ。
データのいい感じの名前の付け方とか。

第3部 HTTP

ステートフル(店員が注文を覚えてくれるようなやり取り)とステートレス(店員にすべての注文を告げ直すようなやり取り)についてとか。
GET/POST/PUT/DELETEとか、返ってくるエラーコードの説明とか。
おそらく、次にこのあたりの具体的な使い方について勉強していきたい。

第4章 ハイパーメディアフォーマット

HTMLの書き方とかAtomとかもろもろ。
別にWeb屋さんになるわけではないからな、と読み飛ばし。
きっと必要になったときに覚えるのが早い。

第5章 Webサービスの設計

別にWebに限らずに設計として考えるべきことの概略がまとまっててとてもとても良い。
郵便番号から住所を検索するよくあるシステムの例だけど、↓みたいに分離して説明してる。

  • リソースをどうやって管理する?
  • リソースの名前の付け方
  • クライアント向けのAPIの内容
  • リソースの結びつけ
    RESTの考え方自体をこの本で初めて触れたので、もっと勉強して理解を深めたいと感じる。

【書籍】CleanCode

書籍情報

Clean Code アジャイルソフトウェア達人の技

メモ

CleanArchitectureが既読棚に積んであるくせに読んだ記憶がない疑惑の判定で読みだしたところ、こっちの本の参照を見かけて作者同じやん!って軽く目を通してただけのはずがいつの間にか読み切ってた。
ソースコードきれいに書きたいブームのときに買ってちまちま読みつつ忘れかけてた本。
学生時代に買うとしたら気が引けるけど、業務経験出てきたり、会社に置いてあると嬉しい1冊(所感)。

クリーンコードな心がけ

第1~13章(P25~254)は1章ずつが独立しつつも1章ずつが大切なテーマについて語ってるので初心を忘れてしまったら読み返したい。
名前の付け方(2章)、コメント(4章)の即効性のある内容からエラーの書き方(7章)、システム(11章)、スレッドの並行性の話(13章)の重い話まで色々。1章あたり10~20ページくらい割いて説明されてる。
スレッド関係はよくわかってないので読み飛ばしてる。
なんかもうちょっと専門の本とか、自分の仕事に関わるようになってから読み返すと違うものが見えそうだ。

実践編

第14~16章(P255~370)はリファクタやってみました話。
つまり割とピンとこない話なので読み飛ばし。
リファクタ対象とした内容自体が読み解くのにエネルギー使うので、テスト駆動開発の方が読みやすくてTDDチャレンジもしてみたくなる。(そういえばそちらは読んだ本履歴に書いてないや)

標語

第17章「においと経験則」はたった30Pでこの本から学ぶべき問題あるソースの注意点をまとめてくれてる。全部覚えるまで毎日仕事前に1回眺める習慣付けてもいいんじゃないってくらいには大切なことが小さくまとまってる。

【書籍】ノンデザイナーズ・デザインブック

書籍情報

ノンデザイナーズ・デザインブック

メモ

伝わるデザインの基本に続いて、この手の資料作りとかで読んどくといいとお勧めされた1冊。

伝わる〜は資料作りに特価した本だけど、こちらはもっと基礎的な文章の見せ方に対するルールを定義付けた本。

大前提として翻訳本で英語に対するデザインを説明した本なので、後半のフォントの話が完全に英文向けの説明。
とはいえ、デザイン原則とか、フォントの組み合わせルールとか、日本語に対しても転じて適応できる部分はある。

デザインの原則

本の前半(10-162P)がデザインの原則→文章の見せ方の話で、この本で読んでおくべきことの大部分。

以下の話に終始している。

  • コントラスト
    要素の違う内容はくっきり違いを感じ取れるようにする
  • 反復
    類似するデザインは繰り返す

  • 整列
    データの位置は合わせる
    無闇に中央揃えしない(先頭がずれる)

  • 近接
    類似する要素は近づけてグループ化する
    関係ない要素は離す

上の文章はこの4つの要素を意識的に取り入れて書いた。
説明すると、

  • コントラスト:表題が太字になっている
  • 反復:4つの項目を同じフォーマットで提示した
  • 整列:表題の下の文字列の開始位置が全て同一である
  • 近接:要素の間に1行分の改行があり、グループが見て取れる

…みたいな。

まぁブログの描き散らかし用には面倒なのでこれ以上はやらないけれども…。

あとは色の選び方の話が少々。
でもこの辺は趣味なら自分の直感で選ぶか、配色パターン本なんてのもあるし、こういうところから選んだ方が良さそう。

この本は次に色についてしっかり考えたくなったら買おうかなって思ってる。本屋でパラ見して良さそうだったシリーズ。

FighTimer(ios/android)が緑・オレンジベースなのは趣味。オレンジって活動的でいいよねってところから一番のテーマカラーが決定。
そこから、

  • 何もしてない時間→緑
  • アクティビティのある(タイマー記録中)時間→オレンジ
  • アクティビティ期間限定の要素(リマインダー)→水色

というチョイスで、
緑×オレンジはトライアド、オレンジ×水色は補色。
考えて選んだ記憶はあるので、そう間違ってはいないはず。
 (最も、カテゴリーとかユーザーが好き放題に色を選べるのであまり意味はない。

活字

後半(163-236P)がフォントに対する話。
セリフありなしとか、大文字小文字の話とか、完全に英文の話なので結構駆け足で読んでしまった。

フォントのカテゴリー(線の強弱・セリフ・筆記体…)を覚えて、同一ページで2種類以上のフォントを利用したい場合はカテゴリーが異なるものから選ぶとコントラストが出るので良い、というルールはわかりやすい。

「英文が全部大文字だと読みにくい」は感覚的には理解してたけど、「大文字だとシルエットが全て同じだから読みにくい」の説明がとても腑に落ちた。
「FighTimer」は「g」とか「i」とか上下の形に凹凸ができるけど、
「FIGHTIMER」は上下が一直線になるから遠目に読みにくいって話。

【書籍】ドメイン駆動設計入門

書籍情報

ドメイン駆動設計入門

メモ

最近DDD勉強会#1とかをよく見るので、ちゃんと1から勉強してみようかなと買った本。
すごく大当たりな本で、最初に本家のエリック・エヴァンス本とか駆動設計本読んでたら心が折れてたんじゃないかと思う(未読)

説明はC#をベースにしてはいるけど難なく読める。
(そもそもこの手の本のソースコードをまともに読まないのだけど…

まずはDDDのなんたるかの簡単な説明があった上で、
値オブジェクト:パラメータを管理する構造体
エンティティ:内部パラメータが可変かつ同一性を持つ構造体
リポジトリ:値オブジェクト・エンティティを管理する
ドメインサービス:ふるまいを管理する
アプリケーションサービス:ユーザーに向けたユースケースを組み立てる
…の構造を丁寧に説明してる。
 (もしかしたら表現ミスとかあるかもだから、ちゃんと本読んで。

FighTimerのアーキテクチャもこれを読んだあとではあぁああしておけばよかったなぁという後悔ばかり。設計に向き直るには良い機会なのである。

「境界づけられたコンテキスト」がよく理解出来てなかったけど、「同じものを指しつつ違う役割を持った存在である」(サークルに所属するUser情報・ログインに所属するUser情報)の概念を理解出来たのは嬉しい。

とにもかくにもおすすめできる。
この調子で次は実践ドメイン駆動設計に挑戦してみたいところ。

【書籍】伝わるデザインの基本

書籍情報

伝わるデザインの基本 よい資料を作るためのレイアウトのルール

メモ

もともとは資料作るのにググった伝わるデザインのページの情報がよかったので、書籍でなにか得られないかな、と買った一冊。
正直そのページを端から端まで読み込めば書籍はなくともいいような気はするけど、資料を作った後にこの本をパラパラめくって読みにくい要素がないか確認するためには良い。

書体・文章・図・レイアウトの4章とその最後にまとめのチェックリストがあるのでさらっと読むのにも適してる。

ただこの本読んでも未だに箇条書きの表現については悩む。単純に項目挙げたいときもあるんだよね。どうしよ。

【書籍】ゲーマーズブレイン

書籍情報

ゲーマーズブレイン

メモ

「脳を理解する」から始まる科学的に人の認識を説明するPart1(全体の2/5)と「ゲームのためのUXフレームワークを説明」するPart2(残り)の二部構成。

Part1

大雑把には以下のような内容。

  • 右脳派・左脳派は根拠なし…等のよく聞く話に根拠はありませんよ、の紹介
  • わかりにくいUIと修正案の提示
  • 人の記憶の定着度の流れとそれに沿ったレベルデザインの提示
  • ゲームの動機付けの提示方法

どの章も前半に科学的に解明されている現象の説明と、後半にそれをゲームに転用するなら…の話が続く。
例えば吊り橋効果。吊り橋の上にいる緊張感を目の前にいる異性に大して緊張→恋をしていると勘違いするという話はよく聞くけれど、ロード画面が長くてイライラするのをゲームに負けてイライラしている感情と混同する、というように、別例を挙げてくれるのがわかりやすい。

Part2

ここからは実際にゲームを作る時に考える事項が挙げられる。

  • ユーザビリティについて考える
  • エンゲージアビリティ(ゲームを通して得られる経験)について考える
  • ユーザー調査の提案
  • ゲームアナリティクス

制作しているゲームがαを通過して、ある程度形になってきた頃に、そのゲームを頭に浮かべながらPart2を読むと発見があると思う。

直近ではゲームの難易度は直線ではなく、鋸の歯のようにギザギザにつけるべき、という話が刺さった。
一直線だと滑らかにユーザーが強くなってしまい、達成感が足りないが、難易度が波のように訪れると乗り越えるべき壁を感じたり、それを超えた時に強くなった達成感が得られる。(無論、難しすぎない範疇の調整で)

【書籍】ソフトウェア・テストの技法

書籍情報

ソフトウェア・テストの技法第2版

メモ

JSTQBの本が既読だったりして、余り目新しい内容はなかったのと、なんだか目が滑る…翻訳かなぁ。

多分テストを書くためのモチベーションとかを求めてるので、読みたい内容ってテストとはなにか?の基本的な部分を説明してるこれじゃない気がする。
JSTQBの方が丁寧&分厚いので、そこまで読む元気がないならこっちを読むべきなのかな。

【書籍】マスタリングTCP/IP

書籍情報

マスタリングTCP/IP

メモ

インターネットのネットワークなんぞやの勉強のために読んでる。
ネットワークの知識皆無から読み始めても安心。嬉しい。
まずは1.2回読んでる。今2周め。
全部の必要要素は頭に叩き込んでおきたい。らしい。

MACアドレス:2層データリンク層で使われる方。ユニークな値。出荷時に設定されるので不変の値。
IPアドレス:3層ネットワーク層で使われる方。自身で割り当てたりできる。階層状にすることができる。

TCP:コネクション型で信頼性のあるデータ配送形式。
UDP:コネクションレス型で信頼性のないデータ配送形式。

【書籍】レガシーコードからの脱却

書籍情報

レガシーコードからの脱却
ソフトウェアの寿命を伸ばし価値を高める9つのプラクティス

概要

プロジェクトに挑む前にレガシーコードはなんたるや、コードをレガシーにしないための心構えを作る本

前提知識

必須

なし

推奨

「レガシーコード」「スクラム」「TDD」にピンとこない人

再読するなら

9つのプラクティスを目次で。
半年に1回とか、自分のプロジェクトの軌跡と照らし合わせてこの行いができたかを振り返る

一連の流れを説明している本なので、各手法の細かい方法を把握したい場合はそれ専用の専門書を買うべき。

9つのプラクティス

  1. やり方より先に目的、理由、誰のためかを伝える
  2. 小さなバッチで作る
  3. 継続的に統合する
  4. 協力し合う
  5. 「CLEAN」コードを作る
  6. まずテストを書く
  7. テストで振る舞いを明示する
  8. 設計は最後に行う
  9. レガシーコードをリファクタリングする

つまり?

①やり方より先に目的、理由、誰のためかを伝える

スクラム&PO向け説明を考えて行動する

②小さなバッチで作る

ユーザーストーリーをタスクに分解し、小さな単位で実装を行う

③継続的に統合する

CI&テストを導入する

④協力し合う

エクストリーム・プログラミングな話

⑤ 「CLEAN」コードを作る

  • Cohesive:凝縮性
  • Loosely Coupled:疎結合
  • Encapsulated:カプセル化
  • Assertive:断定的
  • Nonredundant:非常帳
    …な、コードを心がける

⑥まずテストを書く

⑦テストで振る舞いを明示する

⑨レガシーコードをリファクタリングする

素晴らしきTDD

⑧設計は最後に行う

設計を後に回し、末端から作ることでソースの重複やよりカプセル化された構造にできる。
タイトルに対して説明しにくい章だ…

所感

割と読んでる本のジャンルが被ってるのでそんなに目新しい発見はなかったかな的な。
レガシーコードを意識するための本としては良さそう。

【書籍】アジャイルコーチング

書籍情報

アジャイルコーチング

概要

チーム(対人)にアジャイルを浸透させる術、アジャイルを導入させる側としての本。
ところどころにチームリーダーとしての意識を考えさせられるような記述あり。
具体的な見積もり手法とかの話はアジャイルな見積もりと計画づくりの方が濃い。

前提知識

必須

なし

推奨

スクラムの実経験

アジャイルを導入させるための本なので、導入させるつもりがあって読むべき。

再読するなら

アジャイルを実践して、壁に当たったとき。
各章末尾に「苦難」の項目があり、こんなときは…の参考になる。
割と方法論なので、そんなに再読する系ではない。

人を導く立場として

第Ⅰ部

アジャイルの運用の仕方(人の説得の仕方)

第Ⅱ部

アジャイルの計画の立て方を明確な指標とともに考える

×
アジャイルな見積もりと計画づくりを読むべき

品質を考える上で必要な作業(バグ・テスト・リファクタリング)

第Ⅲ部

1イテレーションの終わりと次への始まり

第Ⅳ部

内容メモ

第Ⅰ部 コーチングの基本

アジャイルが云々というよりも、コーチとして、人の上に立つリーダーとして、認識しておきたい事項の確認。

第1章 旅を始める

アジャイルコーチのはじめ方~また次へ、を簡潔に説明した章。

  • コーチを始める前に、動機・スキル・責任・支援を再認識する
  • チームへは適切に紹介を受けて加入する。曖昧に入ると、コーチとしての信頼を失う
  • PrOpERサイクルを意識する。
     問題を探し(Problem)、改善の選択肢を検討し(Option)、実験(Experiment)、成果をレビューする(Review)
  • 時間の概念を持ち、問題の原因・結果を考える
  • ペースを維持する。進みが遅くとも、挫折せずに進み続けること

第2章 みんなと一緒に働く

チームとして他人と働く上でのコミュニケーションで大切にするべき部分の話。
相手の話はきちんと聞くとか、行間を読むとか。
議題によって対立した場合には即座に仲裁役に回る必要はなく、話を聞いたり、出ている意見に投票して視覚的に理解できるようにして感情論にならないようにする。

第3章 変化を導く

アジャイルの導入としてだけではなく、なにかの導入のときの心がけとも読める。

  • チームに急速な変化を求めない
  • 提案は宗教ではない。盲信しない。
  • 説明だけでなく、実演して見せる
  • 導入しないことによる問題を提示する
  • 「提案された内容」ではなく、当事者意識を持たせることで自主性が高まる
     ・相手にオープンクエスチョン(「なぜ~だと思う?」のように、YesNoで回答できない質問)をする
     ・5回のなぜ(原因を5回探すとその間に根本的な問題が現れる)
     ・質問は誘導尋問ではない。明確な助言を持っているときの答えを促すための質問は信用をなくすので控える
  • 学習の機会を作る

第4章 アジャイルチームを作る

アジャイルチームを作る前に、チームとしてのあるべき姿を考える話。心理的安全性の話とかまさにこれ。
まずはチームとしてお互いを信頼し、働くための場所を整える(物理的な席の場所を近づける)
チームのやる気を維持する。

  • 簡単すぎず、難しすぎない程よい目標を常に立てる
  • 説得力のあるゴールを決める
  • イノベーションの時間を設ける(ゴールドカードを出した日は自分のやりたいことをやる&結果を発表するとか)
  • インセンティブ報酬には気をつける。他人を出し抜くような報酬はチームの協力を失う

第Ⅱ章 チームで計画づくり

いよいよスクラムし始める。

第5章 デイリースタンドアップ

いわゆる朝会。チーム全員がボード前に立って昨日の作業・今日の作業予定・困ってることを10分程度で報告しあうのがテンプレ。
(これに限らず)ルールに縛られる必要性はない。「ルールに従っていればいい」と思うと自主性がなくなる。
あくまでチーム間での作業情報共有が目的なので、特定人物だけが話す場にはしない。
2部構成にして、対開発チーム・対営業チームとか分ける手法もあり(スクラムオブスクラム)
開始時間は絶対に朝ではなく、チームの都合で決める。
コーチとしては話が脱線したら補正する、当事者が慣れてしまった問題がないかを第3者の目線で考えながら参加する。

第6章 何を作るか理解する

ユーザーストーリーの作り方の話。
「**というユーザーとして**という機能がほしい。そうすれば**という利益が得られる」をテンプレとして作成する。
3C(カード・会話・確認)が重要。
ストーリーを作成したあとにストーリーテストの詳細を確認する。
ユーザーの要求に応じて、詳細を詰めていく。
ユーザーが触れない機能(インフラ整備とか)もユーザー→プロダクトマネージャなどに置き換えて同じようにストーリー化できる。

第7章 前もって計画する

ユーザーストーリーを出したあとの見積もり・優先度会議の話。
顧客から次イテレーションに向けた目標を説明してもらう→チームで見積もり(※顧客は一旦退室しても可)→イテレーション計画(優先度・作業依存順に決定する・顧客にも説明する)

  • イテレーションは数回の平均=チームの作業可能実績であって、徐々に上がり続ける値ではない。そのような期待を持たない。
  • イテレーション内で計画が変わり続ける場合、見積もりなどがうまく行っていない。調査が必要であればスパイクを設ける
  • バグ修正の見積もりは難しい。かんばん方式への移行も視野に入れる

第8章 見える化する

チームボードの運用例。
・物理的
・見やすい
…なら、割となんでも良さそう。
ストーリーを優先度順に縦に貼って、横にToDOなどを並べるのが一般的な様子。(他の本もだいたいそう

なんでも見えるようにする必要はない。必要なくなれば運用を終える。
保守の仕方はチームで集まって検討するのが吉。

第Ⅲ部 品質に気を配る

テストどうするべきか?とかリファクタリングとか。
おそらく、この本自体が非エンジニア向けだから、こういう手段もあるよという紹介なんだと思う。
あまり深い部分までは突っ込まれてない。

第9章 完成させる

ストーリーテストの完成の定義を明確にする。
「テストする」だけでなく、自動テストとか、データ用意とか、実は作業はたくさんある。

バグを埋もれさせない。
変に気を遣って連絡しない(先にマネージャーを通してしまい、話が大きくなってる)とか、
頻繁に連絡して士気を下げるとか、やり取りは対人であることを意識する。

ストーリー未達を真摯に受け止め原因を振り返る。

強制されたツールの運用もきちんと考える

第10章 テストで開発を駆動する

ストーリーの完成条件でもあるテスト、それをTDDにしてみませんか、という提案。

TDDが早すぎるケースもある。
チームがテストのあり方について理解・同意できていない。
そのときは書き方を学ぶことから。

どこからテストを書くべきか?
まずは分離しやすい中間コードから。

CIも大切だがCIの規律はより大切。CI結果を無視しない

テストに時間がかかるようになると生産性が落ちてTDD持続も難しくなる。実行時間にも気を配る。

第11章 クリーンコード

作り続けるだけではなく、コードの綺麗さも考え続ける必要がある。

分析麻痺に陥ってないか?
ソースコードを書かずに設計ばかり考えてる。
逆に設計0も問題。
ユーザーストーリーに対して設計も意識する。

リファクタリングとか、チームでコードを共通所有する意識とか、ペアプロの話。

ペアプロは勉強のためではない。
少なくとも同じ言語で行う。
初心者対ベテランの組み合わせは問題ないし、お互いにお互いの意見をリスペクトし合う。

第Ⅳ部 フィードバックに耳を傾ける

イテレーションが終了して、次のイテレーションへ…行く前の、イテレーションデモ・その回のイテレーションの振り返りの話+α。

第12章 結果をデモする

イテレーションの終了時のデモのやり方の話。

プレゼンの構成を決めて、全員が役割を果たす。
リリース事項として確認すべき事項も掲載。

技術的問題でデモが実行できない等は避けるべし。
事前準備・確認や、安定版を用意する。

第13章 ふりかえりで変化を推進する

ふりかえりのあるべきでない姿が載っている。
たまに見返して、自分たちの行っているふりかえりがどうかを考えてみると良さそう。

その期間にあった出来事と感情を導き出す。その時の気づきから改善のアイデアを探し、次に実行する
リリースレトロスペクティブでチーム全員で振り返る。これは大規模なので、事前に準備もする。

全員から、建設的な話を得るための場である。
話さない人がいる、不満ばかりの場になるべきではない。

第14章 あなたの成長

あなた自身が成長するために…のきっかけを渡そうとする章。
読み返すべきとすればこの章だけど、自己啓発話なので、それに特化した本を読んだほうが良さげ。