2013-05-31

proxy配下でcurl実行

Proxy Curl

Couldnt resolve host hogehoge.com　を見たらProxyを疑え!

# curl  : --proxy-ntlm --proxy http://proxserver:xxxxxx https://raw.github.com/gitlabhq/gitlab-recipes/master/init.d/gitlab-centos > /etc/init.d/gitlab

2013-05-30

proxy配下でgemを実行する

Proxy gem

会社のProxy配下でgem updateしようとしたら失敗する。
こんな感じ。

# gem update --system

WARNING:  Error fetching data: SocketError: getaddrinfo: Name or service not known (http://rubygems.org/latest_specs.4.8.gz)
Updating rubygems-update
WARNING:  Error fetching data: SocketError: getaddrinfo: Name or service not known (http://rubygems.org/specs.4.8.gz)
ERROR:  While executing gem ... (Gem::GemNotFoundException)
    Could not find a valid gem 'rubygems-update' (2.0.3) locally or in a repository

ぐーぐる先生にきいてみたら、--http-proxyというオプションがあるのでそれをつかえ、と。

# gem update --http-proxy http://hogehoge:xxxx/

ポート番号の後に"/"を付け忘れて、しばらく悩んだのはないしょ!

2013-05-02

Webdavの転送サイズ上限を変更する

Windows7 Webdav

Webdav上の大きいファイルを取得しようとしたところ、こんなエラーが。

「エラー 0x800700DF: ファイルサイズが許可された制限を超えているし、保存することはできません。」とな。

エラーメッセージをぐーぐる先生に尋ねてみたところ、どうやらクライアント側に制約がある模様で、それを外す術もあるそうな。
こちらhttp://support.microsoft.com/kb/900900/jaによると、

デフォルトで50MBが上限
上限値はレジストリに記述されているので、変えたければどうぞ
なんならFixitもあるよ

とのこと。ということでFixitにてやってみましょう。

こちらhttp://support.microsoft.com/kb/900900/ja#FixItForMeAlwaysからFixitを入手。

次へ

デフォで50MBが入力欄に入っているので、変更しましょう。
(上限値があるので注意。ざっくり4GBくらい。)

再起動して完了。お疲れさまでした。

2013-04-30

Windows7 Enterprise 64bit でWebdavをネットワークドライブとして追加する

Windows7 Webdav

Windows7でWebdavをネットワークドライブとして追加する方法のメモ書き。
こちらWindows7でWebDAVを使う : 元うなぎ屋を参考に。

WebClientサービスを起動させる
net use コマンドで設定する

だけです。
(確認したのはEnterprise64bitだけども、特にEdition差分は無いんじゃないかなとか)

WebClientサービスを起動させる

スタートボタン→コンピュータ(右クリック)→管理、を選択。
サービスとアプリケーション、からサービスを選択。
「WebClient」の状態を確認。開始にします。

net use コマンドで設定する

コマンドプロンプトを起動。
とあるWebdavをxドライブとして追加したい場合は、

# net use x: https://hogehoge/dav/

を実行。httpsだとユーザ名・パスワードを聞かれるはずなので入力しましょう。認証が通れば完了です。

2013-02-16

【第5回】Scrum Boot Camp Premiumに参加してきました

Scrum Agile

先日2/14木に開催されたScrum Boot Camp Premiumに参加してきました。
Codezine Academy

イントロ

昨年10月頃から参加しているPJで「アジャイルやってみよーぜー」とやってたこともあり、社内のアジャイル推進担当な方から「ひと通り(素人ながらも)アジャイルやってみたんだから、ちょっとこれで知見を深めてきなさいな」と紹介頂いたのでした。
※年度末近くだったけど、会社の外部研修予算もギリギリ残ってたようで。

リンク先の通りセミナーは2コースからの選択式だったのですが、Aコース(講師・西村直人さん)に参加しました。
(某社内アジャイル推進担当の方が「西村さんは俺の師匠」と仰ってたのもありました)
Aコース講師は他に原田さん(超絶マルチタスク)、松本さん(バンナムで社としてスクラムに取り組んでいる)、有野さん(SIとしてのスクラム)がいらっしゃいました。

先に感想

このセミナーで得た知見は全社レベルで展開したい。社内研修とかやれないかな。
スクラム道にもちょいちょい参加してみる(｀・ω・´)ｼｬｷｰﾝ
スクラムブートキャンプ本と、セミナー予習用に電車で読んでたアジャイルサムライにサインを頂きました。ありがとうございます！

自分のPJに照らしてみると「何をもって完了とするか」「どうやったらそれを確認できるのか」を曖昧にしたまま走ってしまったのが失敗だった。
見積りにあたって開発チームから「まだ課題が解決できるかどうか分からなくて見積もれない」という場面が毎回あったのも、前スプリント中に次スプリントのおおよそ見積り対象範囲を提示して「スプリントレビューまでには見積もれるように準備してね」を徹底すべきだったと気づけた。「準備しておいてね」は伝えてはいたんだけど、それができないとこんな大変なことになるよ！という影響まではうまく認識してもらえてなかったんだろうな…。
オフショアメンバをPJ初期にちゃんと日本に呼べたのはよかったけれど、リリーススプリント前帰国にあたり、遠隔コミュニケーションの相談をよくよくよーく相談すべきだった…。

スクラムチームの能力は「チームの"年齢"」に比例する。なるほどなぁ。
トランプワークショップで学んだこと。先入観ダメゼッタイ。
気になったポイントを好きなタイミングでポストイットに書いて、ホワイトボードに貼っておくと合間に講師が拾って話題にしてくれる仕組みはすごくいい。自分でも使いたい。
講師の方々がつけてるバッジはスクラム道http://www.taoofscrum.org/contents/の「守破離バッジ」。てっきり写輪眼か何かかと…だってバンナムの方もいたし…

質疑応答とか

Q.受託Scrumってできるの？言い方悪いけど「出来高勝負」みたいに考えてるんだけど
- A.もちろん可能。最初の見積り(10機能1万円で作って欲しい)の段階で「勝てるかどうか」の勝算を踏むのはScrumとか何とかは関係ないよね？問題なのは今までのやり方だと「20機能になったけど1万円でやってね」を交渉できる余地がないんだけど、プロダクトバックログを最初に合意しておけばそこまで酷いことにはならないようコントロールできるはず。
- A.お客さんの要求をバックログに入れてやれば、その代わりに何かを落とす必要がありますよね？の交渉ができるッ！
Q.Scrumを初めて導入するにあたり、えらい人とか協力会社さんにはどうやって説明しよう。拒絶されちゃったことがあるんだけど
- A.(ブラック)黙ってやる。
- A.(ホワイト)カタカナ語を極力排除して説明すると、結構アレルギー反応なしでいけた経験あり。「プロダクトバックログ」=「顧客要望一覧(優先度順に並び替えております)」とか。
Q.オフショアでやれる？
- A.やれる…が…オススメはしない。というかオフショアで安くできる分と本気でScrum回せたときのパフォーマンスは、十分オフショアやめようぜの根拠になり得るレベルよ？特に大連はここ数年で外資が入って人がすぐに離れるというリスクがげふんげふん
- A.24時間TV会議をつなぎっぱなしにしていた現場もある。それくらコミュニケーション重要。POが現地に行くのも1つの手だけど。少なくとも「1回も合ったこともない、初めて一緒に開発するチームです」レベルでの導入は自殺行為。
Q.Scrum初挑戦のチームがこなれてくるのは何スプリント目くらい？
- A.3〜4スプリント目くらいかなぁ…。守破離=1〜2、3〜4、5〜、なイメージ。
Q.人事評価とScrumってどう結びつけたらいいんだろう。チームでの成果と個人評価ってどうしたらいいんだろうか。
- A.正直悩ましい。日本で出来てるところなんて、まだほとんどないんじゃないだろうか。
Q.スクラムマスタってどう育成したらいいの
- A.正直悩ましい。若くて活きのいいやつが適切。あえて聞きにくい質問をする必要があるので、社内の暗黙的なルールとかの思い込みに対しガツンと言える/知らないから言える人。
- A.社外のスクラムマスタを雇うのもひとつの答えだと思う。
Q.1スプリントあたりのストーリ数ってどんなもん？
- A.まったく根拠はないけど、2週間1スプリントで2、3ストーリがしっくりくる。タスク数は30〜40くらいが好き。

やったこと(資料と記憶の限り)

大きな流れは以下のとおり。

Scrumの基本
1. スクラムガイドをななめ読み
  1. スクラムとは「複雑なプロダクトを開発・維持するためのフレームワークである」
    1. 「フレームワーク=自分の組織・現場にあった解決方法や技法を取り入れる」
  2. 理解が容易、軽量である、習得が"非常に"困難である
    1. 「習得ではなくつくりあげていくものなんだ」
  3. スクラムチームの各ロール(プロダクトオーナー、開発チーム、スクラムマスター)とその役目
  4. スクラムイベントと成果物
  5. 3本の柱「透明性、検査、適応」、そのためのコミュニケーション「関心、共通認識、自主性」
見積もりと計画づくり
1. 計画づくり。「ちゃんと成果を届けられ、わかりやすくありのままを伝えられ、必要に応じて変更でき、約束したことを守り続ける」計画にしたい。
  1. ★プロダクトバックログ、順序付けると「ちゃんと成果を届ける」計画に効いてくる
2. 内容をうまく書く「みんなが理解でき、あとで調整しやすく、手軽に書ける」
  1. みんな＝計画に関わる人達(スクラムチームだけじゃない)、えらい人、要求を出す人、営業の人…
    1. ユーザーストーリーのテンプレ「"(ユーザーの種類)"として、"(達成したいこと)"をしたい、なぜなら"(理由)"だからだ」
  2. 調整できる前提「よく書けているストーリーであること」=「INVEST」、よくない例「機能〜できる」とだけ書いている
    1. I=独立していること、それをやらないと決めても、そこだけまるっと削ればOK(エンドツーエンドで一式揃っているようなストーリー)
    2. N=交渉の余地があること、目的達成のためにしょぼく安く作れるよ！とか
    3. V=価値があること、ビジネス観点で評価できること
    4. E=見積もりができること
    5. S=小さいこと
    6. T=テストできること
  3. 手軽にかける=短く書くことで後で対話を促す、会話の約束
    1. とは言っても短さは状況による
      1. 何度も開発をこなしてきた見知ったメンバーで構成されたチームなら、テンプレほどもいらないかも
      2. 初めての顔合わせチームならテンプレに則って作成しよう
      3. オフショアならストーリーの詳細な説明、画面レイアウト、受け入れテストまで必要
  4. ★ユーザーストーリーは「わかりやすくありのままを伝えられ、必要に応じて変更でき」る計画に効いてくる
3. アジャイルな見積もり
  1. 見積もりはあてずっぽう、そんな状況でもベストを尽くすのが"アジャイルサムライ"
  2. アジャイルな見積もりの秘訣
    1. 一人でやらない、思い込み、誰がチェック？、集合知
    2. 実際に作業するひとがみつもる
    3. 相対サイズで見積もる
  3. 見積の主目的はプロジェクトの結果を予測することではなく、プロジェクトのターゲットがコントロールによって達成可能な程度に現実的なものかどうかを判断することにある
    1. ★「自分たちが信頼でき扱える事」が大事で、それが「約束したことを守り続ける」計画に効いてくる
  4. プランニングポーカー、ポイント、対話と合意
    1. ストーリーに対し質問する(情報を伝え、認識を揃える)
    2. 見積もる
    3. 議論する(ここでゴールの認識違いとかがわかったりする)
    4. 合意する(なにを持って完了とする等、合意内容は記録しておくと後々便利)
4. いつ終わるの？
  1. ベロシティ、スプリントを重ねるごとに正確になっていく、リリース日が予想できるようになる
    1. ベロシティが安定していることが前提
    2. 必要な作業を安定してこなしていくチームが大事、そのためにも阻害するものからのガードが必要
  2. リリーススプリントは用意しておいた方がいい(納品準備とか、引き継ぎとか)

現場が実践すること、スプリントの上手な過ごし方
1. イベントをこなす、まるで短期プロジェクトのように(重要)。定期的なチェックポイントとしてのイベント
  1. スプリント計画ミーティング
    1. スプリントで何をどう実現するかを決定する、ゴール、何を実現するか、どう実現するか
    2. 第1部「何を実現するか」を合意する。参加者全員。
      1. 何を実現したいかをPOから伝え、どう実現するかを合意し、どう確認するかまで合意する
    3. 第2部「合意した項目を期間中にどう実現するか」を計画する。参加者PO以外。
      1. スプリントバックログ、タスクの洗い出しと見積り
      2. 「その計画は自信をもって達成できると約束できますか？」
        
        YES！→終了
        
        NO…→タイムボックスに収まるまで調整(分割、交換、変更)する
  2. デイリースクラム
    1. 昨日何しましたか、今日は何しますか、困ってることは？
    2. 進捗報告じゃない、短時間(15分)で終える、決まった時間・場所で、必要な会議のみ別途設定
  3. スプリントレビュー
    1. 成果物と進め方に問題がないかを点検、計画を見直す場
    2. 成果物デモ、疑問点等の解消および完了の判断、進め方の確認
    3. 完了の定義は満たしているか(最終的にはPO判断)、未完了のものは"未着手"として扱う
    4. 問題が見つかったら全員で最善策を考える、スコープ調整、作業無駄排除、課題解消…etc
    5. プロダクトバックログも最新化しましょう
  4. スプリントレトロスペクティブ(ふりかえり)
    1. 進め方を点検し、よりうまくいくアイディアを考えて計画する。全員参加。
    2. 課題報告・対策の場ではない、前向きな対話を！良くなるアイディアは"必ず実現できるように"計画に組み込む。
2. 他にやるべき事
  1. 透明性の維持、準備重要(明確に要求を伝えられるか、必要な資料は準備できたか、大きな疑問は解消しているか、実現可能か判断できているか、見積もれるだけの情報はあるのか)
3. 約束を守る、コミットメント
  1. 約束する場「スプリント計画ミーティング、デイリースクラム、スプリントレトロスペクティブ」
  2. 約束を守れない時はどうしてもある、ただしベストは尽くせ
  3. 約束を守れるように"チームで"作業を終わらせていく
    1. そのための「関心、共通認識、自主性」

2013-02-04

VM上のCentOSとホストOS(Windows7)とでファイル共有したメモ

Windows7 CentOS VMwarePlayer

Windows7 Enterprise(64bit)にVMwarePlayerを入れCentOS6.3(64bit)を構築してるのだけど、たまにホストOS・ゲストOS間でファイルの受渡ししたい場面がありまして、じゃあファイル共有できるようにしてみっかな、と思い立ったわけです。
※本当はドラッグアンドドロップとかできないかなとか思ったけど最初に見つかった記事がこっち方面だったのでげふんげふん

こちらまた一つ、新しい花の名前を覚えました。~出戻りプログラマの備忘録~ VMware Player で共有フォルダを有効にする（2）を参考に。

VMwareToolsをインストールして
共有の設定をしてあげる

という設定をします。

VMwareToolsをインストールする。

VMwarePlayer側からVMwareToolsのインストールを選択

※画像は「再インストール」になってるけど気にしない

親切にヘルプメッセージがでるのでたぶん気づく。

ヘルプメッセージに従い、マウントして中身を引っこ抜きます。

# mount /dev/cdrom2 /media

# cd /media
# cp ./VMwareTools-9.2.2-893683.tar.gz /tmp

解凍後、中身を実行

# cd /tmp
# tar zxvf VMwareTools-9.2.2-893683.tar.gz

# cd vmware-tools-distrib/
# ./vmware-install.pl

これでインストール完了。

共有の設定

VMwarePlayer側から設定をしてあげます。

仮想マシン設定を選択。

オプションタブ→「共有フォルダ」選択→「フォルダの共有」を「常に有効」→フォルダを「追加」ボタン押下→共有フォルダ追加ウィザード起動

共有したいフォルダを追加します。

動作確認

共有したフォルダは

/mnt/hgfs/

配下にいますので、ここに設定した共有先フォルダがいれば成功です。

※ホストOS側の「C:\」をまるっと共有するとこんな感じ。

お疲れさまでした。enjoy!

2013-01-12

Vimでファイルエンコード指定がうまいこと効かなかったよメモ

Vim

ここ数日悩んでたけど、何とか解決できたのでメモ。

iso-2022-jpなファイルがあるんだけども、utf-8として残したい。
Vimで編集したい。
なので.vimrcにset fileencoding=utf-8を書いてみた。
- 新規に「hoge.txt」とかを作成するにあたってはutf-8になっているので安心した（確認方法は":set fenc"）

上記条件でそのiso-2022-jpファイルをVimで開いて「:set fenc」とやるとiso-2022-jpが返ってくる。でもその後「:set fenc=utf-8」とやればutf-8がちゃんと設定されるので「set fenc=hogehoge」が効いてない訳ではなさそげ。どゆこと？(´・ω・｀)？

とかなんとか悩んでいたところに救いの手https://twitter.com/gantawitter/status/289889737316122624がッ！

ということでaliasして試して見ることに。

alias vi = 'vim -c "set fenc=utf-8"'

これで前述のiso-2022-jpファイルもutf-8として開いて編集・保存できるようになりました。ありがっとう！