Lチカ開発ブログ

https://l-chika.com/の開発ブログ

ActiveRecordでIncorrect string value

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 を utf8utf8mb4 にする事で解消。

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

「人月の神話」を読んで

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

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

第2章 人月の神話

人月

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

人月の神話【新装版】

人月の神話【新装版】

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

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

前提

構成

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)

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

カスタム検索

https://cse.google.com/create/new

APIのパラメータについて

https://developers.google.com/custom-search/json-api/v1/reference/cse/list

package customsearchのドキュメント

godoc.org

Google Go API

github.com

qiita.com

Goのイディオム

スターティング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言語

スターティングGo言語

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

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

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

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

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

カンバン仕事術

カンバン仕事術

Rails5.1+webpack+React

Rails5.1で、Reactの利用を開発モードで試してみる。

前提・環境

  • OS: Ubuntu 14.04
  • yarnはインストール済み
  • その他バージョンは以下のとおり
$ cat /etc/lsb-release
...
DISTRIB_DESCRIPTION="Ubuntu 14.04 LTS"
$ yarn -V
0.23.2
$ ruby -v
ruby 2.3.3p222 (2016-11-21 revision 56859) [x86_64-linux]
$ bundle -v
Bundler version 1.13.7

手順

Rails5.1のインストール

  1. 作業ディレクトリ作成
  2. Rails5.1の bundle install
$ mkdir rails-5-1  && cd $_
$ bundle init
$ vim Gemfile

Gemfile

gem 'rails', '~> 5.1'
$ bundle install --path=vendor/bundle

アプリケーションの作成

  1. webpack オプションをつけてアプリケーション作成
  2. GemfileをOverwrite
$ bundle exec rails new . -T -d mysql --webpack=react
       exist  
      create  README.md
      create  Rakefile
      create  config.ru
      create  .gitignore
    conflict  Gemfile
Overwrite /{APPLICATION_PATH}/rails-5-1/Gemfile? (enter "h" for help) [Ynaqdh] Y
       force  Gemfile
         run  git init from "."
Initialized empty Git repository in /{APPLICATION_PATH}/rails-5-1/.git/
      create  app
      create  app/assets/config/manifest.js
      create  app/assets/javascripts/application.js
...
Done in 14.32s.
Webpacker now supports react.js 🎉
         run  bundle exec spring binstub --all
* bin/rake: spring inserted
* bin/rails: spring inserted

サーバー起動確認

$ ./bin/rails s -b 0.0.0.0 -p 3000

http://0.0.0.0:3000/ で確認

f:id:l-chika:20170502124701p:plain

Reactサンプルページの作成

controller生成

$ ./bin/rails g controller pages home --no-helper --no-assets
      create  app/controllers/pages_controller.rb
       route  get 'pages/home'
      invoke  erb
      create    app/views/pages
      create    app/views/pages/home.html.erb

http://0.0.0.0:3000/pages/home で確認

webpackでbuild

$ ./bin/webpack

hello_react を実装

$ vim app/views/pages/home.html.erb 
<%= javascript_pack_tag 'hello_react' %>

これをフロントから確認すると以下のようになる。

<body>
    <script src="http://localhost:8080/packs/hello_react.js"></script>
...
</body>

このままだと http://0.0.0.0:3000/pages/home で確認しても hello_react.js は実行されない - jsのパスがhttp://localhost:8080 - 開発モードなので、webpack-dev-serverで、Hot Module Replacement(HMR) を利用する

HMRのパスを変更する

localhostVagrantのIPに変更する

$ vim config/webpack/development.server.yml

変更前

default: &default
  enabled: true
  host: localhost
  port: 8080

変更後

default: &default
  enabled: true
  host: 192.168.xx.xx
  port: 8080

webpack-dev-serverの起動

  • webpack-dev-serverrails server を同時に起動
$ ./bin/webpack-dev-server
$ ./bin/rails s -b 0.0.0.0 -p 3000

view

hello_react.js のパスが変更される

<body>
    <script src="http://192.168.xx.xx:8080/packs/hello_react.js"></script>
...
</body>

「Hello React!」が表示されればOK!

f:id:l-chika:20170502124728p:plain

その他・参考

l-chika.hatenablog.com

qiita.com

Ruby on Rails 5アプリケーションプログラミング

Ruby on Rails 5アプリケーションプログラミング

「カンバン ソフトウェア開発の変革」を読んで

開発プロセスの参考にカンバン: ソフトウェア開発の変革 を読んでのメモ。

スクラム開発で、タイムボックス化されたイテレーションに合わせるユーザーストーリーを一貫して継続する事が困難となってきたため、開発プロセスの変革の参考に本書を読んでみた。

Chapter1.プロジェクトマネージャーのジレンマ

「フリーサイズの」開発方法論がうまくいかない理由 (P31)

  • チームは以下で異なる

    • スキルセット
    • 経験レベル
    • 能力レベル
  • プロジェクトは以下で異なる

    • 予算
    • スケジュール
    • スコープ
    • リスクプロファイル
  • 組織は以下で異なる

プル型システム(後工程引き取り方式) (P32)

  • 仕掛り(WIP)が事前に取り決めたある一定量で制限させることで、作業者の働き過ぎを防止する
  • ボトルネックとなっている箇所の作業者には、完全な負荷がかかることになるが、他の者は誰もが「ゆとり」の時間を持つことができる。

Chapter2.カンバン手法とは何か

組織内にリーンの行動を生み出す5つの中核となるプロパティ (P47)

  1. ワークフローの見える化
  2. 仕掛り(WIP)の制限
  3. フローの測定と管理
  4. プロセスポリシーの明示化
  5. 改善機会を導入するための仕組み

Chapter3.成功へのレシピ

このレシピに従えばチームの抵抗を小さく抑えて、迅速に改善を行うことができる (P55)

  1. 品質に集中する
  2. 仕掛り(WIP) を減らす
  3. デリバリーを頻繁に行う
  4. 要望とスループットバランスを取る
  5. 優先順位を付ける
  6. 予測可能性を向上させるために、ばらつきの要因を解消する

Chapter6.バリューストリームマップの作成

  • 作業項目タイプ (P115)
  • 需要にもとづく作業容量の割当て (P123)
  • 順不同なアクティビティへの対処 (P131)

Chapter7. カンバンシステムの調整

  • キュー補充会議 (P142)

Chapter8. デリバリーリズムの確立

  • P154

    決められた期間内に完成させられるよう、作業を小さく分割するのは、必ずしも易しくない

Chapter9. 入力リズムの確立

  • 優先順位付けリズム増加のための効率改善 (P176)

Chapter10. 仕掛り制限の設定

  • キューの制限 (P184)

Chapter11. サービスレベルアグリーメントの確立

  • 一般的な優先度分類の定義 (P196)

Chapter13. カンバンのスケール化

  • 優先度分類のポリシー (P205)
  • スイムレーンの導入 (P237)

カンバン: ソフトウェア開発の変革

カンバン: ソフトウェア開発の変革