MacBook Air 11インチにPHPUnit入れた
まずはpearのインストール
13インチAirの時はport使っていたのだけど11インチではport入れてないので新たに以下のやり方で入れた。
ググったらinstall-pear-nozlib.pharというものがあるらしいということがわかったので叩いてphp.iniの編集。
sudo php /usr/lib/php/install-pear-nozlib.phar
sudo cp /etc/php.ini.default /etc/php.ini
include_pathを書く。
sudo vim /etc/php.ini
include_path=".:/usr/lib/php/pear"
PHPUnitをインストール
sudo pear config-set auto_discover 1 sudo pear install pear.phpunit.de/PHPUnit
PHPUnitの確認
pear list -a
phpunit
別の入れ方
試していないが別の入れ方もあるらしい
PHPUnit on Mac OS X Snow Leopard 10.6 and Lion 10.7Everything Frontend | Dmitriy Kubyshkin
以上。
エンジニアのための年末大掃除ハック #vgadvent2012
終業時刻を過ぎるまでは「お疲れ様です」と言わないキャンペーンを社内でひとり実施している@chiseiですこんにちは。
Voyage Group Advent Calendarで4日目を担当します。
今年も大掃除の季節がやって参りました
師走ですね。昔、師走の語源は「坊さんが走り回るほど忙しいから師走というのだ」と習った記憶があります。先日「師走 語源」で検索したら実は語源には諸説あるそうですね（みんな大好きwikipediaから）。
さて、世のエンジニアの師走はどのようなものでしょうか。走り回っているのでしょうか。あるエンジニアは年始に大きなメンテナンスを控え関係部署への調整のため本当に走り回っているかもしれませんね。あるエンジニアは年末にリリースしなければならない大きな案件に奔走し、またあるエンジニアは年末に退職を控え今まで携わってきたプロダクトのドキュメントをまとめているかもしれません。
いろいろな師走の過ごし方があると思いますが、まあとりあえずサーバに残されたゴミファイルや誰も覚えていないようなIssueなどすっきり掃除して新年を向かえましょう。
無駄なバッチ処理を止める
サービス提供がとうの昔に終わっているにも関わらずなぜかバッチが登録されたままであるというのは経験があるのではないでしょうか。私はありまくりです。「12月だし見なおそうか。」とチームに一声かけてみんなで/etc/crontabを眺めてみましょう（最近だとJenkinsの人たちもいるかもしれません）。
昨日我々のチームはcrontabの見直しをして5行ほど削除しました。問題が発生しなければ該当の実行ファイルはSCMの対象からも外します。
ホームディレクトリ内の無駄なファイルを消す
私はよくhoge.phpとかa.sqlという一瞬だけ使うファイルを作っては放置したりローカルPCで生成した巨大なcsvファイルを転送してそのまま、、、みたいなことをよくしてしまうのですがこれを機に掃除します。
共用開発機のコミット漏れチェック＆SCMとプロダクション環境との差分チェック
最近はVMなど立てて個人開発環境使って開発するものだと個人的には思っていますがやむを得ない事情で共用開発機を使っている方はコミット漏れが無いかどうかチェックしておくべきでしょう。
SCMとプロダクション環境に差分あったら消すなり、ignoreに加えるなりバージョン管理の対象とするなりしましょう。
最終出社日のサーバのゴミ掃除は避ける
最終出社日に掃除した結果、正規のプロダクトに影響を与えたらシャレにならないので以上に挙げたことは遅くとも12月3週目ぐらいには終わらせておいたほうが無難だと思います。
古いIssueのクローズ
ある程度時間が経過してしまったIssueはあまり重要ではないということです。多分クローズして問題無いです。不安なら関係者に相談しましょう。
絶対に不要であると確信のあるドキュメントを消す
「絶対に不要」と思えるドキュメントは消していいでしょう。古い情報があると検索しにくいのと後任者が惑わされるので引継コストが高いです。もし、削除するのに迷ったら削除候補のフォルダを作って放り込むか削除候補のタグを貼っておきましょう。余力があるなら書き直してもよいと思います。
緊急時の連絡先の棚卸と障害発生時の対処方法共有
休みに入る前に緊急時の連絡先の共有と障害時の連絡手順方法について関係各所ですり合わせておきましょう。携帯電話番号、プライベートのメールアドレス、IMのIDあたりをチーム全員に共有しておけばいつでも連絡を付けられると思います。年末年始に長期で海外に旅行をする場合は対応が難しいと思うので自分の責任範囲を別の人に引き継いでおいたほうがいいでしょう。
最後に
忙しい方もそうでない方も今のうちに「年末だし大掃除しようぜ！」とチームにひと声かけ、1つでも多く無駄を排除すると2013年のスタートはスムーズになるのではないかなと思います。
明日は@tomitaさんがお届けします！
bashの良さ
photo by heipei
最近新卒エンジニアとbashについて語る機会があった。僕はbashが好きなので、なぜbashが好きなのか、bashのなにが良いかを語った。その後改めて「なぜ自分はbashが好きなんだっけ？」と思ったのでブログにまとめておく。
bashはシンプル
なんといってもbash自体シンプルなのが良い。標準入力や標準出力をパイプで別のコマンドに流し込んで指示を続行することができる。また、bashで書くスクリプトは1つの要求に対して1つのスクリプトであるため必然的にシンプルにできてしまう。最大でも30行ぐらいで落ち着くイメージがある。僕は長いソースコードを読んだり書いたりするのが好きではないのでbashのシンプルさは魅力的だ。
自分の仕事をスクリプトに丸投げできる
自分の仕事をスクリプトに投げるというのはbashに限らない話ではあるんだけどLAMP系のエンジニアであればほぼ毎日terminalと向き合ってなにかしらのコマンドを実行していると思う。ディレクトリ移動したり、何かのファイルを検索したり、そのファイルの中身を調べたり、その後置換作業を行ったり。
そんな煩わしい作業もちょっとスクリプトを書くだけで解決できてしまう。シェルスクリプトは書いてある通りに上から下にただストンと落ちるのみ。もしくはプロセスを永久ループで常駐させても良い。
ただし、bashは環境に依存するし人に依存する
bashは好きなんだけど書き方が複数存在するのでコーディング規約が無いと書き方が属人化してしまうような気がする*1。また、bashは環境によってコマンドの挙動が異なることがある。例えばsedコマンドはFreeBSD系とLinux系で挙動が異なることがある。
*1:ただし、人それぞれの書き方を学べるので面白いと思う
あの有名な風刺の右下のあれをどれだけ早期に見つけ、学習できるかということに関して書かれた書籍がリーン・スタートアップ
photo by http://www.projectcartoon.com/ (?)
書籍リーン・スタートアップには「顧客が本当に必要だった物」を早期に発見するための様々なノウハウが書かれている。
「考え方や実践方法の原理原則はアジャイルソフトウェア開発と殆ど一緒じゃないか。」
というのが率直な感想。
自分のなかでのハラオチ
事前に平鍋さんのブログのリーンスタートアップ解説(1)を読んでいたので
自分の中ではアジャイル開発をより経営側にシフトしたものだと勝手に認識していた。
リーン・スタートアップを読み進めていくうちに最後はリーンスタートアップというのはアジャイル
ソフトウェア開発の原理原則を応用して経営まで広げている手法だと自分のなかでハラオチできた。
顧客開発
平鍋さんのブログのなかに「顧客開発（仮説を回して顧客に関する知識を蓄えていくこと）」という
言葉が使われているがとてもよく理解できる。誰も顧客を理解していない。顧客も自分自身
を理解できていない。だから探っていかなければならない。しかも様々な外部環境の変化
で顧客の属性はコロコロ変わってしまうから顧客開発は不断の努力が必要だ。
リーンスタータップはこれからの会社経営の原理原則になる気がする
感覚的にそう思っただけで自信を持って断定するわけはない。そして私自身経営者というわけではない。
ただ、リーン・スタートアップに書かれていることを実践していけば会社は「顧客が本当に必要だった物」を
提供していける。それは会社の発展に有益なことだと認識した。
リーン・スタートアップ ―ムダのない起業プロセスでイノベーションを生みだす
- 作者: エリック・リース,伊藤穣一(MITメディアラボ所長),井口耕二
- 出版社/メーカー: 日経BP社
- 発売日: 2012/04/12
- メディア: ハードカバー
- 購入: 24人 クリック: 351回
- この商品を含むブログ (74件) を見る
bashのxUnitを見つけた
プロジェクトを振り返ることの利点
最近社内のアジャイルを促進する人たちと集まって
「振り返りの利点って何だろうね？」という議論をした。
※ここで表現している振り返りの方法はすべてKPT。
僕個人としては振り返りの利点というのはいろいろあるんだけど特に、
メンバー間でProblemの認識をすり合わせたり、
本質回帰することが大きな利点であると思っている。
議論しているなかで振り返りというのは当然行ったほうが良いものなんだけど
「良い振り返り」と「悪い振り返り」があるよね、という話になった。
良い振り返り
良い振り返りとは何か？プロジェクト進行中に頻繁に振り返れているのならば
良い振り返りである可能性が高いという結論になった。
- 前回のProblemを改善し、しっかりとTryできていること。振り返って、「はい、終わり」じゃない
- メンバー間でプロジェクト進行のProblemを認識できている
- メンバー同士、良い部分を褒め合う、認め合う
以上を書いてみて思ったが良い振り返りというのはチームの成熟にも効果を発揮しそうだ。
悪い振り返り
対して悪い振り返りというのは
- プロジェクトが終わった時だけ振り返ってプロジェクト中に活かせない
- Problemの指摘ばかりに終始してしまって振り返れない
- Problemが改善されないまま、いつかの振り返りでまた同じProblemが上がってくる
など。僕はこれらはすべて経験している。どれも大した成果の出ない振り返りだった。
特に共感出来るのがプロジェクトが終わった時だけ振り返るというもの。
実はこのやり方だと振り返りの利点をあまり享受できない。
誰かがこれをプロジェクトの検死と表現していたがすごく適切な表現だと思う。
プロジェクトの期間にもよるがプロジェクト終わりにのみ振り返るのでKeepと
Problemを洗い出すだけで相当な時間がかかってしまってTryを議論できない。
議論してもあまり旨みがない。内部環境も外部環境もガラっと
変わってしまったらそのTryを適用できない可能性が高い。
ただ単に終わったプロジェクトの良い部分、悪い部分を調べ尽くす作業になってしまう。だから検死。
なぜ振り返るのか？
振り返りというのは今のプロセスを今以上にするために行うものだから
週に一度ぐらいは開催したい。プロジェクトの健康診断のようなものだ。
振り返りでプロセスを改善できれば成果物の質は自然と高まるはずだ。
