RSpecでGZipされたファイルのopenをmockするメモ
require 'open-uri' binary = open(filepath,'rb') read = mock('open') read.stub(:readpartial).and_return{|length| binary.readpartial(length) } if (defined? content_encoding).nil? or content_encoding.nil? read.stub(:content_encoding).and_return([]) else read.stub(:content_encoding).and_return(content_encoding) end
"git push -f"は使ってはならないコマンドなのか。
そんな使っちゃいけないコマンドだとしたら、pushなんて常用するコマンドにしないんじゃないのかな。git help pushとしてヘルプをみてみると、
-f, --force
Usually, the command refuses to update a remote ref that is not an ancestor of the local ref used to overwrite it. This flag disables the check. This
can cause the remote repository to lose commits; use it with care.
と書かれています。ざっくり訳すと、
「通常、pushはリモートのrefを更新する時、ローカルのrefがリモートのrefの祖先ではない時、上書きされないように拒否します。(訳注:ツリーが分岐していたら、そうなりますよね？)このフラグは、このチェックを無効にするものです。これにより、リモートリポジトリにあるコミットは失う原因になりうるので、使うときには注意しましょう。」
と書かれています。他のリポジトリを使っている人に影響がありうるので、常用するのはどうかと思います。もし使うのであれば、チームのメンバーや他の人を気にしなければなりません。しかし、誰もpushする前であれば、リモートリポジトリにpushした内容を取り消したい時に「push -f」をしても影響がない事が、このヘルプの説明でわかると思います。リモートリポジトリのrefが上書かれるだけですから。
「危険だから」といわれて「???」となったんですが、どなたか危険な理由を教えていただけないでしょうか。もしヘルプに書かれている以上に気をつけなければならない事があるのであれば、教えていただけるとうれしいです。
github pagesにmvn site-deployする。
githubにmaven3のプラグインやらなんやらを公開し、使う事が増えてきたので、github pagesにmvn siteの内容をデプロイしてみたので、そのメモをまとめる。
GitHub Pagesに「手動」でgh-pagesブランチを公開する。
AdminページのAutomatic Page Generatorを押して作成すると、gh-pagesを更新しても公開されているコンテンツは公開されなかった。もう一度Automatic Page Generatorを押すと、生成したページの編集ページが開く。なので、優先順位みたいなものがあるかもしれない。https://help.github.com/articles/creating-project-pages-manually を参考に空のgh-pagesブランチを作成し、pushする。
$ cd repo $ git checkout --orphan gh-pages # 親ブランチを持たない(orphan)gh-pagesブランチを作り、gh-pagesに切り替える。 git rm -rf . # ワーキングツリーの内容を削除する $ echo "My GitHub Page" > index.html $ git add . $ git commit -a -m "First pages commit" $ git push origin gh-pages
pom.xmlに下記の操作を行う
のmaven-site-pluginの設定にwagon-gitsiteを追加する。
<plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-site-plugin</artifactId> <version>3.1</version> <configuration> <locales>en</locales> </configuration> <dependencies> <dependency> <groupId>com.github.stephenc.wagon</groupId> <artifactId>wagon-gitsite</artifactId> <version>0.4.1</version> </dependency> <dependency> <groupId>org.apache.maven.doxia</groupId> <artifactId>doxia-module-markdown</artifactId> <version>1.3</version> </dependency> </dependencies> </plugin>
doxia-module-markdownは、追加するとsrc/site/markdown以下に*.mdファイルを置くとMarkdown形式として処理してくれるので便利！
の設定を改める。
<distributionManagement> <repository> <id>kompiro.org</id> <name>kompiro.org repoisitory</name> <url>scp://kompiro.org/home/kompiro/kompiro.org/maven</url> </repository> <site> <id>github</id> <url>gitsite:git@github.com/kompiro/notification-maven-plugin.git</url> <!-- github.com:usernameはgithub.com/usernameにする --> </site> </distributionManagement>
DevLOVE HangerFlight - Snow Barrage - でFearless Changeについて話してきました。
「ブログに書くまでがDevLOVEです。」大事な事なのでもう一回、「ブログに書くまでが D・e・v・L・O・V・E です。」。講演の中でも2回言ったので、書くよー。
いやー、月食きれいでしたね。東京にいられて良かったです。そのきっかけになってくれたのが、DevLOVE HangerFlightでした。先ほどのエントリの冒頭に、僕は福井に引っ越したと書きましたが、この度「何でもいいから東京に来て話してよ」といわれたので、それだったらFearless Changeの話がDevLOVEに必要だと思うのでさせてください、と提案してこのセッションをやってきました。
DevLOVEで学んだ事を現場 で広めるための48の戦略 をFearless Changeから 学ぼう
48の「戦略」としたのは「パタン」と呼んでもピンと来る人はそれほど多くはないだろう、と思ったからです。あと、当日紹介したのは8つだけです。だからタイトルは釣りですすみません。
今回紹介した選んだパタンは下記の8つです。これらは、組織に新しいアイディアを広めるために最初に必要になる考え方です。
- Evangelist - エバンジェリスト
- Just DO IT - とにかくやってみる
- Test the Water - 味見をする
- Innovator - イノベーター
- Ask for Help - 助けを借りる
- Just say thanks - 感謝を忘れず
- Time for Reflection - ふりかえる時間
- Step by Step - 一歩ずつ
ここに書いてある項目を眺めて、こう思いませんでしたか？「なんかエバンジェリスト以外当たり前の事しかかかれてないな？」って。そうです。当たり前のことなんです。でも組織に新しいアイディアを広められている、と言う声がそれほど多くないのはなぜなんでしょうか？僕が思うのは、当たり前の事でもやれないことってあるよねっ、っていう良く聞く話しか思い浮かばないです。(ただいま2:20。明日になってなんか気づいたら書こう。)
今回のDevLOVEのふりかえりセッションは、結構このセッションと同じ事を扱っていた気がしますし、@sato_shiさんが、その本、読みたい、とおっしゃってくれたのが印象的でした。社長さんなのにね。トップダウンでやろうとしても上手くいかないと嘆かれていました。そう、社内に変化を起こすには、トップダウンもボトムアップも関係ないんです。セッションでは言わなかったけど。
たぶん誰かを巻き込んで変化するためには、そこには「楽しさ」みたいな内燃しやすい燃料を注ぐ必要があるように思う。ゲーミフィケーションなんて分かりやすい例。
DevLOVEに来る人は、現場を変えるために参加する人が結構いるんじゃないかと思ってやってみました。今年、Fearless Changeの著者の一人のリンダさんにお会いできたのは、本当に自分の考え方を変える出会いでした。あの本を書けるような人は、やっぱりどこか違う。Energizeできうる人は、たぶん「自分」よりも「人のために」エネルギーをさける人なのだと思った。否定せず、うまく気持ちを盛り上げ、相手に内燃させられる燃料を注げる人。それがEnergizer。僕もそうなれましたかね。あの時リンダさんに自分が分けてもらったエナジーを、少しずつセッションに参加された方に渡したつもりです。みんなの現場が現場のみんなにとって少しでも良くなるように、頑張っていきましょう。
このセッションは自分一人では出来上がりませんでした。DevLOVE裏方兼本読部の@_oppyさん、本読部で配布したペーパーの翻訳をされている@kawagutiさん、48のパターン名の概要翻訳をされている@yattomさん、DevLOVEの@papandaさん、そして参加してくださったみなさま、どうもありがとうございました。
Shibuya.trac #13に参加して感じた事。
@tyobichiさんのがんばりによって、10日前に開催になりました。@riskriskさんに前日に司会をお願いし、いつもustをしてくださる@nekotankさんが今回もustを引き受けてくださったり結構ドタバタしてましたが、@kanu_ ]さんの話も、@ikikkoさんの話もとてもよかったです。かぬさんのTracを「たくさんカスタマイズした結果、そのカスタマイズは開発メンバーにとって、と言うよりも、管理者が楽をするための機能だった。それでは結局Excelと同じように苦痛にだんだんと思われてしまっていたようだ。デフォルトのTracのシンプルさは開発者にとって必要なものだけだったんだ。」という話が心に響かないわけないよね。これRedmineとかJIRAとか関係ないもの。
よかれと思って項目を増やしていっても結局必要なかった事が分かっても、放置されている項目があったりすると、新しく入って来たメンバーは困るんですよね。これなんであるの？って。極力増やさない方がいいと思っていたのが、腑に落ちました。
Jenkinsは、Hudsonのときからずーっとずーっと使い倒しているので、自分は特に初心者ではないです。だから話の内容は、僕にはあんまりピンとこなかったです。特にJenkinsのプラグインはカリカリでも入れてみて常用して、動かなくなったら元に戻すとか気にせずやるたちなので、この開発者のプラグインは安心できる話は、動かなかったら「コード書いてpull request」って言ってほしかったりしました。うん。全然初心者の方にとっての次の一歩ではないですね。
いきっこさんのトークがすごくうまくなっている事にびっくりした、って言ったら怒られそうです。でもすごいうまいなー、と思いました。
ぼくのトークはですね、前エントリを読んで頂くと分かると思うんですが、うまく写らなかったり動かなかったり大変でした＞＜精進しないと、ですね。
Shibutra忘年会では@jun66j5にプラグインのネームスペースの話が聞けてよかったです。一応名前空間はぶつからないようになってるみたいですね。それでも行儀の悪いプラグインがいると、衝突するようですが。
Shibuya.trac #13でKanbanについて話してきました。
かれこれ半年前に福井に引っ越しました。はてダではご報告せずに申し訳ないです。2011/12/10に行われたHangerFlight - Snow Barrage -で話すことになり、ついでにShibuya.tracでも話して、ということで、Kanbanについて話してきました。@kanu_さんが素振りで良かったんじゃ、とおっしゃってくださったんですが、お客さんの層が違うと思ったんですよ。だから、新幹線の中でシコシコ資料を作っていましたよ。
資料を作成し始めたら結構まとめないといけない事が多くてですね、半分もしゃべれなかった。Kanbanとは何か、ちゃんと説明されている資料は、自分も翻訳しているばかりなので、あんまりなかったのかもしれないですね。
Kanban! お客さんの視点に立った アジャイルなやり方
Pasona Techさんで今回は開催させて頂いたのですが、会場はとても素晴らしく、おしゃれすぎて自分は場違いなんじゃないかと感じました(ぉ)。ただ、惜しいのは会場スペースではあの有名な水耕栽培スペースにもなっていて、常時点灯されているうえに、プロジェクターのライトが弱かった成果、自分の作成した資料の字が大変見辛くなってしまいました。あれだけ素晴らしい会場なので、プロジェクターは新しいものにされた方が良いのではないかと、本気で思いました。
今、紆余曲折あって、頑張ってDavid AndersonさんのKanbanを翻訳してます。まだかかりそうですが、裾野を広げるために、今回本の中の話をかいつまんでこの資料にしました。もし、この内容にピンときた方がいらっしゃれば、訳書が出てから是非お買い上げいただけたらと思います。
Kanbanというのはどういうやり方なのかと言うと、WIPを制限することで作業の流れを整理することで、スループットとリードタイムを向上させるためのやり方です。WIPというのは、(Work In Progress)の略で、仕掛かり中の作業の事をいいます。同時に進められる作業の量を制限するわけです。スループットと言うのは、ある期間内にリリースできた要求の量、リードタイムと言うのは、欲しいと思った要求が実際にリリースされるまでの時間です。「納期」だとか、「見積り」だとか、そういう話をわきにおいてみて、お客さんの立場になって考えてみると、これって結構当たり前のことだと思います。
例えば、みなさんAmazonでよく本をお買い上げになると思うんですが、Amazonのすごいところの一つは、「大抵の商品は翌日に自宅に届く」って言うところにあると思うんですよ。あれは、「「欲しい」とお客さんが思ってから手に届くリードタイムがほぼ1日」と言えます。スループットは、Amazonでどれだけの量の商品が出荷されているか、という量です。
で、例えばAmazonで在庫切れになっている商品があれば、入荷できそうかどうかで、「2-3日後配送」とか、「1週間後配送」とかなるじゃないですか。Kanbanだと、2週間以上かかりそうな要求であれば、要求元に知らせる。で、要求元は、必要なら開発キューに載せますが、必要なければと判断すれば、開発キューから取り除くとか、判断できるもの、というやり方をとったチームの事例がのってます。ただ、基本的にほとんどの機能は25日以内に納品する事が義務づけられていました。面白くないですか？こうなると、「納期」の概念がだいぶ弱くなるんです。
そのチームだと「見積り」自体がスループットを下げる要因になっていたので、「見積り」もなくしているんですが、その代わりに上記の「2週間かかるかどうかを判断する」というルールが追加されています。それで十分うまく行っているチームもあるんです。(CMMI Lv5だからできたのかもしれないですけど)
なんかソフトウェア開発には「納期」が無いといけない物だ、という常識に縛られてしまって、そういう質問が結構飛び交ったんですけど、Webサービスをやっている会社さんだったりすると「リリースしたい機能が溜まったらリリースする」という運用もできますよねー。だから、一回そういう常識から意識をずらすのはどうだろうか、という話で今回はタイムアップでした。
その後は、「なんで見積りがなくてもいいのか」とか、Kanban本の中で取り上げられている中で面白かったサービスクラスの話を資料に乗っけてます。
見積りをしても、実際に作業をしてみると、うまくいったり、うまくいかなかったりするもんだとKanban本に書かれてます。それは「ゆらぎ(variability)」と名付けられています。その辺りは確率的に存在するものなので、それ自体をコントロールするのではなく、そのゆらぎが産まれる事を前提にプロジェクトを回すようにしてみたらどうだろうとか書かれてます。
サービスクラスは、例えると飛行機のファーストクラスとエコノミークラスの違いみたいな話です。出てくる料理も違えば、ファーストクラスには特別なラウンジがあるなど、お客さんが払っているシート料金ごとに違う扱いをしますよね。要求にもそういうクラス分けを導入してみるといいよ、という話です。要求には緊急度があるはずなので、それを主にお客さんがつけられるようにします。緊急で必要な要求は、割り込んでチームにお願いできるのですが、チームのWIPが決まっているので、今手がつけられている作業は強制的にPENDになります。そして、緊急な作業自体にも一度に同時に作業するのは唯一つだけ、という制限をかけておくと、お客さんにとっても本当に一番手をつけて欲しい作業をお願いする、となる訳です・・・みたいな話をまとめてみたのでちらっと読んでみてください。
Quick JUnit Notification Pluginその2
カッとなって作ってしまった。
やっぱ色変わらないとダメっすよね。REDとGREENは作ってみたけれども、もう一色なんか欲しいですよね。どうしたらいいんでそ。あと、アイコンももうちょっとなんとかできる気が。
http://quick-junit.sourceforge.jp/updates/dev/
からインストールできるっす。
