先日参加したshibuya.rbにて、なぜかスクラム開発導入に関しての話になったので、 ここ数ヶ月勉強してScrum Bootcampにも参加して、現時点での”スクラムを始めるのに必要だと思うこと”をまとめてみる

というか自分はこうやって始めようという内容です
ツッコミいただけると幸い

スクラムを始めようと思わない

いきなり矛盾してるようだが、スクラムを始めようと考えるのは目的と手段が違うんじゃないかな?という意味で。
スクラムのここに魅力を感じてとか、こういう効果を期待してとか目的があってスクラムを導入するべきかなと。

また、スクラムを始める!というのが至上命題になってたりすると、内容がわからないメンバーには やらされ感もつきまとうと思うので価値とか考えを理解してもらった上で導入するのがいいのではないかな。

早めに成功体験を積み上げよう

新しいことを始めてるので、最初のうちはイテレーションを回すのが大変だと思う。
その時点で目標を高くかかげすぎると目標達成できなくてテンションが下がる。
こうならない為に目標を低めに設定するといいと思う。
10の成果を達成できるチームなら8を目標にしておいたほうが、12を目標にしてたときより成功体験をつめるという意味でもいいし、「ほらみたことか次はもっとやれるぜ」みたいな前向きな空気作れるんじゃないかな。

一度に全部やらない

一概にスクラムをやるといってもやること一杯ですよね
スクラムのプラクティスやら、XPのプラクティスやら…
いきなり全部とか考えないでチームメンバーが必要だと思うものからやるのがいいのかな
メンバーが納得できてないプラクティスを導入してもやらされ感だけ感じるんじゃないかと不安を抱いています
もちろんメンバーのモチベーションが高いならば全部やってみたいです

こんな感じかなと思ってます

最後に

自分はスクラムによってもたらされるものの1つ悩みの排除があるという持論をもっています

• 作業の優先順位
• 先が見えないスケジュール
• 未知の部分の仕様策定

そういう(無駄な)悩みから開放され、本当に悩むべきところに集中できるのではないかなぁ
次組むチームで早く試したいもんです

@HIROCASTERさんのブログにてこんなエントリーが 「githug」でgitの基本操作を算数ドリルみたいに学ぼう！

Githugという練習プログラムがあるようです

Gazler/githug

とりあえず一通りやってみました
(導入方法は@HIROCASTERさんのブログを参照してください)
Levelは全部で35まであるみたいですね
githubのほう見たらローカライズのブランチはあるようなのですが、まだ日本語の情報もなさそうなので
問題文を超意訳してみましたので、参考にしてみてください

1 . Initialize an empty repository

空のリポジトリを作成してください

2 . There is a file in your folder called README, you should add it to your staging area

READMEファイルをステージング領域に追加してください

3 . The README file has been added to your staging area, now commit it.

ステージングエリアにあるREADMEをコミットしてください

4 . Set up your git name and email, this is important so that your commits can be identified

gitで使うユーザー名とメールアドレスを設定してください(コミットした人を判別するのに必要になります)

5 . Clone the repository at https://github.com/Gazler/cloneme

https://github.com/Gazler/cloneme をクローンしてください

6 . Clone the repository at https://github.com/Gazler/cloneme to ‘my_cloned_repo’

https://github.com/Gazler/cloneme をmy_cloned_repoという名前でクローンしてください

7 . The text editor ‘vim’ creates files ending in .swp (swap files) for all files that are currently open. We don’t want them creeping into the repository. Make this repository ignore .swp files.

vimは’ほげほげ.swp’のようなファイルを作ることがありますが、このようなファイルがリポジトリに入らないようにしてください

続きは後日!

トラブル☆しゅーたーず＃02　～あいつがまたやらかした～ on Zusaarに参加してきました

リンク先にもありますが要は発生した障害に対して

1. 障害を復旧させ
2. 原因を追求し
3. 報告書/提案書を作成

というイベントです

……せっかくのお休みに嬉々として障害対応しに行くんだからどうかんがえてもドMですほんとうにありが(ry意識の高い参加者の方々でした

概要

運用を受託されているECサイトで障害発生
18時にはテレビでサイトが放映されるため、それまでに解決しなくてはならない

タイムテーブル的にはこんな感じ

04:00 あのやろう山◯くんサイト更新作業完了
14:00 お客様より第一報
15:30 お客様へ一次報告
16:00 番宣番組放送
18:00 本放送

詳細はこんな

…今見ても胃がキリキリする(–;

結果としては、アプリは復旧できたがECCUBEの管理部は復旧できず
負荷対策も…といった感じ
それでも中間順位は2位ぐらいにつけていたので優勝までもう一歩だったかな?
自分は主にアプリの修正等々をやってましたが、DBを調査してくれた方の情報と合わせてなんとかアプリ復旧までこぎつけたのはよかったなと思います

最後には各チームでお客様へ向かって障害報告・再発防止案などを説明する謝罪タイム
だから休日なのになんでこんな悲しいお話聞いてるんだろう、自分たち…

お客様(@tmaeさん)よりのお説教タイム

マジお通夜状態
リアルでこんなんなったら泣きます…

@tmaeさんのお話を聞いて思ったこと等々

もっとお客さんの立場を考えるべき

15:30に一次報告をと言われて結局大抵のチームはギリギリかオーバーしてしまっていた
大抵のチームがある程度復旧への道筋を立ててから説明しようとしてこんなことになったんだろうけど、あくまでそれはこちらの論理なんだよね
お客さんの立場からすれば何が起きているのか、どういう対応をしているのかを知りたいはずなのでまずは状況の説明だけでも構わないので一次報告は迅速にすべきだなぁ

なにを最優先すべきなのか

目の前に壊れてるものがあるとどうしても最優先で直したくなっちゃうけど、それがお客様の望んでいることなのかは場合による(今回は自転車の画像を引くのが最優先だった)ので、頭のどこかに置いておかないといけないよな

馬場さん(@netmarkjp)の解説タイム

まさか山◯くんがクラウド上にバックアップ取ってるとは‥ そこに気付ければ1時間は変わった気がする

バックアップが取れていれば既存のインスタンスを破棄して、更新作業を最初から遣り直すとかもできるのはクラウドのいいところ
ここらへんはCROSS2012とかでも聞いていたけど、実際作業中は考えもしませんでした(汗
まだまだクラウド脳にシフトしてないな

その後は懇親会で山◯くんどうなん?とかそもそもあの手順書(?)にOK出るのはどうなんだ等々、本当に障害対応後のような空気にw

インフラ系の勉強会ということで大丈夫かなぁ…と思いましたが楽しくいろんなことを学べた気がします
次回もトラブル直しに来ようと思います

先日のVagrantのエントリー内でちょっと触れたChefを試してみます

Chefとは

Chef
Chef でサーバ管理を楽チンにしよう！|るびま

Rubyで作られたサーバの構成管理ツールです
いろんなサーバにapacheとか入れたり設定ファイルも配置しちゃったりできるようです

これで下記みたいな時に幸せになれるのかもしれません

• 特定のサーバだけ設定がもれてて動かなかった!
• あのサーバだけライブラリのバージョン違うじゃねぇか!!
• 100台サーバあるけど、apacheのバージョン更新しといて

ただ、ChefにはServerやらClientやらNodeやらRoleやらいろんな考えがあって、
最初から完璧にやろうと思うと必ず失敗します。
自分もすでに数回目(笑)

今回はVagrantで使うことを目的としていますので、chef-soloだけで試そうと思います
最終的には開発用のVirtualBoxと公開用サーバでアプリとか設定とかを統一していきたいです

インストール

Rubyは入っているという想定です

1

gem install chef

これだけでOk

Chefに関する設定ファイルを作成

下記のコマンドを実行して設定ファイルを作成します

1

$ knife configure

設定ファイルの置き場所とかが聞かれると思うので $HOME/.chef/ にしてみましょう
ファイルの設定が終わったら、~/.chef/knife.rbにcookbookの保管場所を設定します

1

cookbook_path            '~/.chef/cookbooks/'

レシピ作成

…ここではレシピと言うべきなのかクックブックと言うべきなのか
インストールするもの毎に作るのが慣習ぽいです
apacheならapacheだけ。PHPとかでライブラリを入れる場合は一緒でもいいのかな?

今回は単に静的ファイルを1つ置くだけのレシピを書いてみましょう

1

$ knife cookbook create static_file

cookbook_path以下にstatic_fileというディレクトリが出来ているはずです
ここがstatic_fileレシピに関する情報をまとめるディレクトリになります

レシピディレクトリの中身

• attributes
• definitions
• files
• libraries
• providers
• recipes
• resources
• templates

8つのディレクトリと

• metadata.rb
• README.md

2つのファイルがあります

今回は静的ファイルを置くだけなので、recipesとfilesディレクトリ以外は消しておきます

ファイルを置いてみる

ファイルの扱いに関してはここを参考にしています

ファイルを置くのは簡単で

1. files以下に置きたいファイルを置く
2. recipes/default.rbに cookbook_file メソッドでファイルを指定

といった感じです。

実際にやってみます
files 以下にsample.txtを作る
recipes/default.rb に以下のようにファイルを配置したいパスを指定

1
2
3

cookbook_file '/tmp/sample.txt' do
  mode '0644'
end

これでレシピの作成は完了
ではこのレシピをVagrantで利用してみましょう
Vagrantfileの途中にchef-soloの記述があるのでその部分を以下のように変更します

1
2
3
4
5
6
7
8
9

Vagrant::Config.run do |config|

  # 中略

  config.vm.provision :chef_solo do |chef|
    chef.cookbooks_path = "~/.chef/cookbooks"
    chef.add_recipe "static_file"
  end
end

あとはVagrantから仮想マシンを立ちげれば反映されてるはずです

1

$ vagrant up     # すでに起動済みの場合はvagrant reload

その後以下のコマンドでファイルがあるかを確認してみましょう

1
2
3

$ vagrant ssh

$ ls /tmp/sample.txt

ファイルはちゃんと配置されたでしょうか?
まだここだと嬉しさわからないと思うので次回はテンプレートを使って値の書き換え等を行うのを確認したいと思います

昨日のエントリーに対する補足として、なぜVagrantを利用するのかということを考える
結論から言うとVagrantが素晴しい!!ということよりも、仮想マシンを使った開発 + Chef/Puppetでの 構成管理それぞれがメリットを持っていて、Vagrantによってそのメリットが享受しやすいことなのかな。

メリット

母艦となるPC/OSの環境が汚れない

必要なライブラリを入れていたら母艦の調子が悪くなるというありがちなパターンから脱却できる

開発メンバーが共通の環境で作業が行える

母艦のOSやスペックが異なろうと仮想マシンは統一されているのでトラブル調査が簡単

ステージング/本番と(ほぼ)同じ構成で作業ができる

Chef/Puppet等の設定を共有することでほぼ同じ構成を行える
なので、いざデプロイしたら本番/ステージングで動かない!といったことが減る

特定の時点での環境が再現可能

仮想マシンの生成+構成管理スクリプトをバージョン管理に入れることで
特定の時点でのOS/アプリの構成がほぼ完全に再現が可能

デメリット

メモリを大量に使う

仮想マシンだからしかたがない

ネットワークが遅い

仮想マシンだからしかたがない

設定ファイルを書くのが大変

我慢してください

渋谷.rb[:20120516] で飛び込みLTした内容のフォローです

最近こんなエントリーが上がってました

2012年のアジャイル動向もわかる！Technology Radarが公開されていました|世界 ThoughtWorks

正式版が出たVagrantの順位が上がってますね
ということで試してみましょう

Vagrantとは

VirtualBoxの仮想マシンをコマンドラインから作ってくれるRubyのライブラリです

Vagrantの流れ

1. Boxと呼ばれる仮想マシンの雛形を用意する
2. ChefやらPuppetで必要なアプリのインストールや設定ファイルを配置する
3. (ﾟДﾟ)ｳﾏｰ

実際にやってみる

ちなみに Ruby は入ってる前提です
まずはgemを入れましょう

1

gem install vagrant

終わったら使用するboxを選びます
http://vagrantbox.es/ から適当なのを選んでみましょう
ここでは当然 Gentooを選びました

1
2
3
4

# 指定したURLのBoxをgentooという名前で使えるようにダウンロードしてきます
vagrant box add gentoo http://dl.dropbox.com/u/4270274/gentoo64-0.7.box
# 雛形となるboxを指定します
vagrant init gentoo

この時点でカレントフォルダにVagrantfileができます
Vagrantfileにはネットワークの設定だったりChef/Puppetの設定を記述できます
設定し終わったら仮想マシンを立ち上げます

1

vagrant up

あとはvagrant sshなどで中にはいってゴリゴリ開発が可能です

ただし…

この時点ではBoxには何が入ってるかよくわかりません
出来ればプレーンなBoxを作りたいですよね
ということでBoxを作るためのgem, veewee を使ってみましょう

1
2

# gemのインストール
gem install veewee --pre

ここでは開発版のgemを入れてみます

テンプレートからBoxを作ります
使用できるテンプレートの一覧はこれで確認できます

1
2

# テンプレートの表示
veewee vbox templates

いろいろ出ます
もちろんここではGentooじゃなくてUbuntuとかもっとナチュラルなやつを選びます

1
2
3
4
5
6
7
8
9
10
11

# Box作成用のテンプレートを選択
veewee vbox define 'ubuntu1204' 'ubuntu-12.04-server-amd64'

# Box作成用仮想マシンの作成(ISO等のダウンロードもします)
veewee vbox build 'ubuntu1204'

# vagrant用にアウトプット
vagrant basebox export 'ubuntu1204'

# vagrantで使えるように
vagrant box add 'ubuntu1204' ubuntu1204.box

ここまで来たら vagrant init から仮想マシンを作ればオッケーです

ここ数ヶ月関わっていた、Javaで書かれてたスマホサイトをRubyで書きなおしたときの話
社内のWikiに書いたら外にも書けよと言われたのでブログ再開がてら書いてみる

元の問題

• 他のプロジェクトのフォークである
• あっちで更新があるたびマージとか無いわ…
• テストが無い…
• 悲しいぐらいに無い
• デプロイは手動
• 死ねる……

こんな状況だったので、こりゃ作り直したほうが早いわ…と思い
チーム内では技術の選定とかは意見通しやすかったのでRubyでやってみよう
ということになった。というかした。

フロント

ではアプリケーション作成に使うフレームワークはどうするか?
ぱっと以下の3つが思い浮ぶ

• Rails
• Sinatra
• Padrino

Ruby未経験者がいて教育コストかけてられないのでRailsは即却下

結論から言うとSinatraを採用した。
Padrinoと迷ったが自分が使ったことのあるもののほうがいいだろという理由から。
ただ、後から考えるとPadrinoのほうがよかったかもしれない
(ジェネレータもあるし、Controllerの分割等が容易なため)

ViewはスマホだしHTML5。slimとか使いたかったけど教えるの大変なのでerbで記述することにした

• jQuery
• jQueryUI

スマホのUIを構築するということで当然JavaScriptは必須。
この用途だとサイズが大きいかもだがjQueryがデファクトスタンダードであろうということで採用
UI系での処理を行うためにjQueryUIも導入

jQuery MobileはHTML作成のルール(クラス付け)だったりが大変&自分が理解してないのを教えれないということで見送り
jqMobiというのもちょうど正式版が出てはいたがこれも検証等々してる余裕はなかったので見送り

O/Rマッパー

• DataMapper

ActiveRecordとどちらを使うか迷ったが、既存テーブルの利用に関して処理の流れがわかりやすかったので採用

ただ、値の更新時に自動で更新日付等を入れる処理を実装するのに苦労した
(最終的には既存のメソッドに手を加えることで対応)
あとauto_migrateってメソッドはRailsとかでdb:migrateとかしたことある人には危険すぎる…
(値を消してmigrateしなおし。値が残るのはauto_upgrade)

テスト

• RSpec
• RR
• Capybara
• (Capybara-webkit)

テストフレームワークはいろいろなものがあるが、今回はRSpecを導入
WebのAPIとの通信等のテストを記述する場所にはRRも用いる
Web系のテストはCapybaraで記述。
JavaScriptが必要なものに関してはCapybara-webkitを使おうと思っていた(headlessテストができるため)けど
周りが使えそうもないので見送り

デプロイ

• Capistrano
• Capistrano-ext

Ruby製のデプロイツール
Railsでの使用を想定して作られたが他のツールでも利用可能
Capistrano-extを使えばStaging環境と本番環境とか複数環境に適用できるのに魅力を感じ採用

CI

• Jenkins

言わずと知れたCIツール
今回のプロジェクトではリポジトリ(svn)をポーリングして、
変更があればユニットテスト、インテグレーションテストを行い、
問題がなければステージング環境に自動デプロイを行う環境を構築した

細かい設定等々は後日

Redmineを導入した際に頻繁に質問されるものの1つが下記のような内容だと思います

• チケットのタイトル編集したいんだけどどこでやればいいの?

この長年多くのユーザー・管理者を悩ませていた問題を解決するプラグイン開発しました!!!

スクリーンショット

これが

こうなります

驚きの中身解説

1. locales/ja.ymlのlabel_moreを上書きする

以上(え

リポジトリはこちらから
https://github.com/chiastolite/redmine_how_to_modify_the_subject