2017-10-07

「サッカーマティクス」を読んで

読書

サッカーマティクス数学が解明する強豪チーム「勝利の方程式」 (サッカー数学)を読んでの感想。本書の目的は「数学観とサッカー観の両方を一変させる」こと。「数学を現実世界に当てはめてみることは、その理論の細部を正確に理解するのと同じくらい重要なこと」とあるようにサッカーに対する数学的アプローチの考え方が大変面白く、思考整理の参考になった。

すべての選手が自分の役割を果たし、パスや動きを通じて連携を保つことで、チームは部分の総和以上の力を発揮できるようになるのだ。この「チーム全体が部分の総和を上回る」という概念こそが、サッカーを数学的なスポーツにする。

本書では、サッカーマティクスを用いて様々な問題に挑んでいる。出発点は常にサッカーだが、そこで足踏みすることはない。どの章も、サッカーと数学の組み合わせが強力な類推につながることを示す物語で構成されている。

本書ではサッカーの詳しい知識も難しい数学知識などの前提は必要なく、興味深く物語に陶酔できた。

チャンピオンズリーグ決勝の終了間際に2ゴールが決まる確率は？なぜバルセロナの「ティキ・タカ」パスはあれほど効率的なのか？なぜリーグ戦の勝ち点は3なのか？メッシとロナウド、どちらの方が名選手か？なぜブックメーカー(賭け屋)はあれほど魅力的なオッズを提示できるのか？

上記のような切り口のテーマが数学的な根拠で明らかにされるのが大変面白い。

2章バルセロナと粘菌の隠れた共通点

構造を理解する一つの方法は、俯瞰するというものだ。

フォーメーション・ネットワークの分析と、粘菌との共通点の考察は興味深かった。

7章戦術マップが暴くチームの個性

イタリアとスペインの最大のちがいはパスのネットワークにある。スペイン・チームは、1人の中心的なミッドフィルダーにパスを集める代わりに、4人の選手にある程度まんべんなくパスを出した。計算された中心性の値は、イタリアの19.7%に対し、スペインは14.6%。これは微々たる差だがトーマスの研究によると、中心性の値が小さいチームほど有利になる。中心性の値が小さいチームほど有利になる。(中略) パスの分散が勝利をもたらしたのだ。

8章部分の総和を上回る超チーム力

1+1は3にも4にもなる「チームの規律と自己の規律、個人の責任と集団の責任」を教え込むことであり、「それができて初めて全体が部分の総和を超えるものになる」

サッカーマティクス数学が解明する強豪チーム「勝利の方程式」

作者: デイヴィッド・サンプター,千葉敏生
出版社/メーカー: 光文社
発売日: 2017/06/16
メディア: 単行本（ソフトカバー）
この商品を含むブログを見る

2017-10-05

Docer & Mysql & Rails APIモード

rails ruby プログラミング docker

ローカルにdockerを利用して、RailsのAPIモード環境を構築。

作業ディレクトリ・Gemfileの作成
Gemfile
Docker
- Dockerfile
- docker-compose.yml
Rails
- rails new
- database.yml変更
実行
db作成
参考

作業ディレクトリ・Gemfileの作成

$ mkdir api-app && cd $_
$ bundle init
Writing new Gemfile to /{WORK_PATH}/api-app/Gemfile

Gemfile

$ vim Gemfile

source "https://rubygems.org"
gem 'rails', '5.1.4'

Docker

Dockerfile

FROM ruby:2.4.2
RUN apt-get update -qq && apt-get install -y build-essential libmysqlclient-dev
RUN mkdir /api-app
WORKDIR /api-app
ADD Gemfile /api-app/Gemfile
ADD Gemfile.lock /api-app/Gemfile.lock
RUN bundle install
ADD . /api-app

docker-compose.yml

$ vim docker-compose.yml

version: '3'
services:
  db:
    image: mysql
    environment:
      MYSQL_ROOT_PASSWORD: password
  web:
    build: .
    command: bundle exec rails s -p 3000 -b '0.0.0.0'
    volumes:
      - .:/api-app
    ports:
      - "3000:3000"
    depends_on:
      - db

※ MYSQL_ROOT_PASSWORD はerror: database is uninitialized and password option is not specified You need to specify one of MYSQL_ROOT_PASSWORD, MYSQL_ALLOW_EMPTY_PASSWORD and MYSQL_RANDOM_ROOT_PASSWORD が発生するため

Rails

rails new

$ docker-compose run web rails new . --api --force --database=mysql --skip-bundle

database.yml変更

$ vim config/database.yml

default: &default
  adapter: mysql2
  encoding: utf8
  pool: 5
  username: root
  password: password
  host: db

実行

$ docker-compose build
$ docker-compose up

db作成

別なターミナルで実行

$ docker-compose run web rake db:create

http://0.0.0.0:3000/ で確認。

参考

プログラマのためのDocker教科書インフラの基礎知識&コードによる環境構築の自動化

作者: 阿佐志保,山田祥寛
出版社/メーカー: 翔泳社
発売日: 2015/11/20
メディア: 大型本
この商品を含むブログ (3件) を見る

Docker

作者: Adrian Mouat,Sky株式会社玉川竜司
出版社/メーカー: オライリージャパン
発売日: 2016/08/17
メディア: 単行本（ソフトカバー）
この商品を含むブログ (1件) を見る

docs.docker.com

easyramble.com

qiita.com

2017-09-13

ActiveRecordでIncorrect string value

rails ruby プログラミング

ActiveRecordで絵文字をインサートする場合に、カラムが utf8mb4なのにMysql2::Error: Incorrect string value が発生。

障害

F, [2017-09-13T09:56:29.800518 #16145] FATAL -- : [ActiveRecord::StatementInvalid] Mysql2::Error: Incorrect string value: '\xF0\x9F\x8D\x9A' for column 'hoge' at row 1: INSERT INTO `talbe` (`column`) VALUES ('絵文字')

改善

config/database.yml の encoding を utf8 → utf8mb4 にする事で解消。

 default: &default
    adapter: mysql2
 -  encoding: utf8
 +  encoding: utf8mb4
    pool: 5

2017-09-05

「人月の神話」を読んで

読書プログラマー開発プロセス

人月の神話【新装版】を読んで。

有名過ぎる名著なので、気に入った一節を抜粋。

第2章人月の神話

人月

コストは実際に人数と月数の積に比例する。が、進捗はそうではない。したがって、仕事の大きさを測る単位としての人月は、疑うべき危険な神話なのだ。人月は、人と月が互いに交換できるという意味だからである。　人と月が交換可能になるのは、多くの作業者の間でコミュニケーション(意思疎通)を図らなくても、仕事が分担できる場合だけである。これは小麦を刈り取るとか、綿を摘むとかいうことには当てはまるが、どうがんばってもシステムプログラム開発には当てはまらない。　仕事が連続して分担できない場合、人を増やすという対策はスケジューリング上、何の効果も生まない。女性がどれほどたくさん動員されたところで、子供1人が生まれてくるまで十月十日かかることに変わりないのと同じだ。多くのソフトウェア開発作業は、デバッグという順次的性質があるためにこうした特徴を持っている。　分担はできるがサブタスク間でのコミュニケーションが必要な仕事においては、コミュニケーションを図る労力を、こなすべき仕事量に追加しなければならない。したがって「人」を「月」と交換してもお粗末な結果しか得られないだろう。

人月の神話【新装版】

作者: Jr FrederickP.Brooks,Jr.,Frederick P. Brooks,滝沢徹,牧野祐子,富澤昇
出版社/メーカー: 丸善出版
発売日: 2014/04/22
メディア: 単行本（ソフトカバー）
この商品を含むブログ (16件) を見る

2017-09-04

GoでGoogle Custom Search APIを利用して画像収集

golang プログラミング

Google Custom Search を利用し、Goで画像を収集。 google-api-custom-search-example を参考に実装。

前提

(google-api-go-client)https://github.com/google/google-api-go-client/tree/master/customsearch/v1 を利用
サービスアカウントキーを発行

構成

customsearch/
├── customsearch.go
└── search-key.json

ソース

(Google Custom Search APIを使って画像収集)http://qiita.com/onlyzs/items/c56fb76ce43e45c12339を参考に、検索エンジンID、サービスアカウントキーを発行。

search-key.json

{
  "type": "xxx",
  "project_id": "xxx",
  "private_key_id": "xxx",
  "private_key": "-----BEGIN PRIVATE KEY-----\nxxxxx\n-----END PRIVATE KEY-----\n",
  "client_email": "xxx",
  "client_id": "xxx",
  "auth_uri": "https://accounts.google.com/o/oauth2/auth",
  "token_uri": "https://accounts.google.com/o/oauth2/token",
  "auth_provider_x509_cert_url": "https://www.googleapis.com/oauth2/v1/certs",
  "client_x509_cert_url": "xxx"
}

customsearch.go

package main

import (
  "fmt"
  "golang.org/x/oauth2"
  "golang.org/x/oauth2/google"
  customsearch "google.golang.org/api/customsearch/v1"
  "io/ioutil"
  "log"
)


func main() {
  data, err := ioutil.ReadFile("search-key.json")
  if err != nil {
    log.Fatal(err)
  }

  conf, err := google.JWTConfigFromJSON(data, "https://www.googleapis.com/auth/cse")
  if err != nil {
    log.Fatal(err)
  }

  client := conf.Client(oauth2.NoContext)
  cseService, err := customsearch.New(client)
  search := cseService.Cse.List("ロゴ")

  // 検索エンジンIDを適宜設定
  search.Cx("xxxxx")
  // Custom Search Engineで「画像検索」をオンにする
  search.SearchType("image")

  search.Start(1)
  call, err := search.Do()
  if err != nil {
    log.Fatal(err)
  }

  for index, r := range call.Items {
    fmt.Println(index)
    fmt.Println(r.Link)
  }
}

実行

$ go run customsearch.go 
0
https://www.google.com/cloud/assets/press/Android_Logo.png
1
https://www.google.com/cloud/assets/press/Chrome_Logo.png
2
https://www.google.com/intl/ja_ALL/insidesearch/images/promos/playground-doodles.jpg
3
https://www.google.com/cloud/assets/press/Google_Cloud_Platform_Logo.png
4
https://www.google.com/cloud/assets/press/G_Suite_Logo.png
5
https://www.google.com/cloud/assets/press/Google_Cloud_Logo.png
6
https://www.google.com/intl/ja/earth/outreach/images/tutorials_screenoverlay1.jpg
7
http://www.google.com/logos/doodles/2016/new-years-day-2016-5637619880820736-hp2x.gif
8
https://www.google.com/maps/about/images/treks/gombe/partner1-logo.jpg
9
http://www.google.com/recaptcha/shared-media/logo2.gif

参考

スターティングGo言語 (CodeZine BOOKS)

作者: 松尾愛賀
出版社/メーカー: 翔泳社
発売日: 2016/04/15
メディア: 単行本（ソフトカバー）
この商品を含むブログ (5件) を見る

Goのイディオム

golang プログラミング

スターティングGo言語を読んでのGoのイディオムをメモ。

ifのイディオム

if _, err := doSomething(); err != nil {
  /* 関数doSomething()がエラーありと返した場合の処理*/
}

mapのイディオム

m := map[int]string{1: "A", 2: "B", 3: "C"}

if _, ok := m[1]; ok  {
  /* m[1]の要素が存在する場合の処理 */
}

スターティングGo言語

作者: 松尾愛賀
出版社/メーカー: 翔泳社
発売日: 2016/05/11
メディア: Kindle版
この商品を含むブログを見る

2017-05-27

「カンバン仕事術」を読んで

読書開発プロセス

開発プロセスの参考にカンバン仕事術を読んでのメモ。

「カンバンソフトウェア開発の変革」を読んで - Lチカ開発ブログにつづいて、スクラム開発で、タイムボックス化されたイテレーションに合わせるユーザーストーリーを一貫して継続する事が困難となってきたため、開発プロセスの変革の参考に本書を読んでみた。

「カンバン:　ソフトウェア開発の変革」とほぼ同じ内容で、読み比べて追加で気になった箇所をメモ。

第I部カンバンの学習
- 1章　チーム「カンバネロス」のはじまり
第II部カンバンの理解

第I部カンバンの学習

1章　チーム「カンバネロス」のはじまり

1.1　イントロダクション
    ▽P7
    チームの課題
    ・納期によく遅れる
    ・見積もりが不正確な事が多い
    ・チームは仕事に追われている
    ・優先度がよくわからない
    ・いろいろなところからチームに仕事が来る
    ・誰が何をやっているのかよくわからない

第II部カンバンの理解

2章　カンバンの原則

2.1　カンバンの原則
▽P49
・見える化：個々の項目の状態がわかるようにする。ワークフローから改善の可能性を発見できるようにする
・WIP(仕掛り作業)の制限：同時に進める仕事の数に制限を設ける
・流れの管理：ワークフローを常に改善し続ける出発点。この仕事が完了することはない、フローはいつでも改善できる

4章　作業項目

4.1　カードの設計原則
    4.1.1　判断を促す
    ▽P72
    チームが判断を下せるようなカードにする。自分たちの自己組織化を助けるようなもの。

            4.1.2　成果の最適化を支援する
    ▽P72
    カードの設計は、成果のリスク、顧客満足、経済性などについて、チームメンバーが最適化できるように支援するものでなければならない。

4.2　作業項目カード
    4.2.1　作業項目の説明
    ▽P76
    ユーザーストーリー
    作業項目の「何を」「誰のために」「なぜをやるか」を記述したもの。
    よく使われるユーザーストーリーのテンプレートは、
    [役割]として、 [機能]が欲しい。それは[利益]のためだ。
    [利益]のために、[役割]として、[機能]が欲しい。

    ▽P81
    外部の電子システムID
            4.2.5　ブロッカー

     4.3　作業の種類
    ▽P83
    黄色：通常
    緑：メンテナンス、技術
    赤：バグ
    種類が違うことを明確にすれば、何が起きているかを理解しやすくなる。ボードを眺めるだけで、チーム全体の状況を感じられる。

    ・赤(バグ)が多ければ、システムの品質に問題がある。品質向上の活動をすべき
    ・緑(メンテナンス、技術)がまったくなければ、技術負債の返済が十分でない。今後システムの捕手が困難になっていく
    ・黄(機能要求)がなければ、システムに新機能がまったく追加されていない

    4.7　自分の作業項目カードを作る
    ▽P90
    ・作業項目を実行するのに必要な情報は何か？設計ゴールを忘れない
    ・作業項目に直接関わってない人でも毎日見たいと関心を持てるような情報は何か？
    ・他の作業の種類はないか？種類を分けることのメリットは何か？
    ・ブロッカーは必要か？どのようなポリシーで運用すべきか？作業項目がブロックされたら何をすればいいのか？ブロッカーを取り除くのは誰の責任か？

    4.8　まとめ
    ▽P90
    ・説明：この作業が「何」かがわかる
    ・アバターなどのマーカー：「誰」が作業しているのかがわかる
    ・追跡IDや外部システムへの参照：追加情報が「どこ」で手に入るかがわかる
    ・ブロッカー：ブロックされている作業を見つけ、なぜ進捗が「止まっている」かがわかる
    ・作業の種類：作業の「種類」を把握して、必要に応じて優先度を正しく決められる
    ・サイズ：「サイズ」と作業量の差がわかる

5章　仕掛り作業

5.2　WIPが多すぎるときの影響
    5.2.1　コンテキストスイッチ
    ▽P99
    同時に頭の中に入れようとするとするタスクの数だけ、時間と集中力を失うことになる

6章　WIP制限

6.3　ボード全体とチーム全体のアプローチ
    6.3.1　イチ！ニー！
    ▽P114
    大切なのは(全員の作業がブロックされた場合、流れはどのように変わるのか？)WIP制限を決める裏付け。
    チームと現在の状況に最適な数字を探す。

7章　流れの管理

7.1　なぜ流れなのか？
    7.1.2　ソフトウェア開発における7つのムダ
    ▽P129
    ・未完成の作業のムダ
    ・余分な機能のムダ
    ・再学習のムダ
    ・引き継ぎのムダ
    ・遅れのムダ
    ・タスク切り替えのムダ
    ・欠陥のムダ


7.2　作業の流れを促す
    7.2.2　待ち時間を減らす
    ▽P133
    作業項目を小さく、同じようなサイズにする

7.3　デイリースタンドアップ
    7.3.2　デイリースタンドアップに関連するカンバンのプラクティス
    ▽P144
    ・昨日、あなたは何をしたか？
    ・今日、あなたは何をするか？
    ・それを行う際に、障害物となっているものはあるか？

8章　サービスクラス

8.2　サービスクラスとは何か？
▽P170
すべての作業項目が均等な価値や時間制約を持つ必要はない。
そのことをボードやポリシーに明示的に反映したのである。
作業項目の価値、リスク情報、明確なポリシー、さらにはボード上での見える化を作り出すことにより、チームが自己組織化して作業に取り掛かり、ビジネスニーズを満たすことができる。そのためのシンプルで透明性が高いやり方が、作業項目にサービスクラスを割り当てるというもの。

9章　計画づくりと見積り

9.2　作業の見積り：相対的に伝える
    9.1.2　発注点
    ▽P190
    発注点の導入により、残りの作業項目が一定数になったときに、他のステークホルダーから新たな作業をプルできる。

    9.2.1　ストーリーポイント
    ▽P198
    フィボナッチ数列
    見積もる際にフィボナッチ数列がよく使われるのは、数学的なギークさから来ているわけではない。項目が大きくなればなるほど、見積もりの精度が低くなるようにしているのである。
    ある項目が12ポイントなのか13ポイントなのかを議論しているなら、それだけの精度の見積もりを出せるだけの情報もあるし、正確に見積もれるはずだと思い違いしている。

10章　プロセスの改善

10.1　ふりかえり
    10.1.1　ふりかえりとは？
    ▽P220
    チームのふりかえりは定期的に行われる。あまりやらないよりも何度もやるほうが好ましい。通常、チームは1~4週間ごとに数時間程度のふりかえりの時間を確保する。これはチームが仕事の改善のために時間を投資しているということだ。
    1. 場を設定する
    2. データを収集する
    3. アイディアを出す
    4. 何をすべきかを決定する
    5. ふりかえりを終了する

11章　改善のガイドとなるメトリクスの使用

11.1　よく使うメトリクス
    11.1.1　サイクルタイムとリードタイム
    ▽P240
    リードタイムを計測することによって、デリバリーするまでの時間、市場に届けるまでの時間、予測可能性などを改善できる。
    それから、納期を守っているかどうか(目標と考えていた日までに作業が終わっているかどうか)もわかる。リードタイムがわかれば、作業項目のどこに時間がかかっているのかを分析できる。

    サイクルタイム：作業項目がプロセスの一部を通り抜ける時間を計測
    リードタイム：プロセス全体を完了する時間を計測


11.2　強力な2つの見える化
    11.2.1　統計的プロセスコントロール（SPC）
    11.2.2　累積フロー図（CFD）

12章　カンバンの落とし穴

12.3　時には変革が必要
▽P283
カンバンが素晴らしいのは、今いるところから始められる点だ。何も変えることなく、カンバンを使い始めることができる。作業の進め方を見える化して、同時に着手する項目を制限すれだけでいい。
ここからさらに学習して、プロセスを改善して、進化させていくことができる。
・カンバンは進化的なものとして導入できる
・ただし、時には大改造となる変革が必要なこともある
・改善の速度は自分でコントロールできる
・他の手法を使い、それにカンバンの原則を適用することで、改善を推進できる

カンバン仕事術

作者: Marcus Hammarberg,Joakim Sundén,原田騎郎,安井力,吉羽龍太郎,角征典,?木正弘
出版社/メーカー: オライリージャパン
発売日: 2016/03/26
メディア: 単行本（ソフトカバー）
この商品を含むブログ (6件) を見る

2章 バルセロナと粘菌の隠れた共通点

7章 戦術マップが暴くチームの個性

8章 部分の総和を上回る超チーム力

作業ディレクトリ・Gemfileの作成

Gemfile

Docker

Dockerfile

docker-compose.yml

rails new

database.yml変更

実行

db作成

参考

障害

改善

第2章 人月の神話

人月

前提

構成

ソース

search-key.json

customsearch.go

実行

参考

カスタム検索

APIのパラメータについて

package customsearchのドキュメント

Google Go API

ifのイディオム

mapのイディオム

第I部 カンバンの学習

1章 チーム「カンバネロス」のはじまり

第II部 カンバンの理解

2章 カンバンの原則

4章 作業項目

5章 仕掛り作業

6章 WIP制限

7章 流れの管理

8章 サービスクラス

9章 計画づくりと見積り

10章 プロセスの改善

11章 改善のガイドとなるメトリクスの使用

12章 カンバンの落とし穴

2章バルセロナと粘菌の隠れた共通点

7章戦術マップが暴くチームの個性

8章部分の総和を上回る超チーム力

第2章人月の神話

第I部カンバンの学習

1章　チーム「カンバネロス」のはじまり

第II部カンバンの理解

2章　カンバンの原則

4章　作業項目

5章　仕掛り作業

6章　WIP制限

7章　流れの管理

8章　サービスクラス

9章　計画づくりと見積り

10章　プロセスの改善

11章　改善のガイドとなるメトリクスの使用

12章　カンバンの落とし穴