タグ

2013年11月6日のブックマーク (5件)

  • JenkinsがGithubにpushされたbranchをテストする - Perl日記

    頑張ったので忘れずにメモ。 master以外のbranchがpushされたときにはそのbranchでテストが走ってほしい。 結論からいうと、Gitプラグインの$GIT_BRANCH変数を使えばいいみたい。 Jenkinsにアカウントを作る githubさんを追加しておく。 行列による権限設定 ジョブ Read Build プラグイン Git Plugin GitHub Plugin GitHub API Plugin Parameterized Trigger Plugin ジョブ Githubのhookを受けるジョブと、テストを回すジョブで分ける。 ジョブの粒度は小さい方がいいってkeiさんが言ってた。 Github_Trigger_R9 → R9 設定 Git Plugin Global Config user.name Value Global Config user.email V

    JenkinsがGithubにpushされたbranchをテストする - Perl日記
    ainame
    ainame 2013/11/06
    あとで読む
  • delete-trailing-whitespace周りの設定 - Shohei Yoshida's Diary

    http://shibayu36.hatenablog.com/entry/20101109/1289314475 行末のスペースを消すために delete-trailing-whitespaceを before-save-hookに設定している人は多いと思いますが、pull requestの ときなどに余計な差分を作ってしまい困ることがあります。そのため id:shibayu36さんのエントリのように toggle関数を作っている方も いると思うのですが、単純に toggleしただけでは今どっちなんだっけと わからなくなることがあります。 それをモードラインで確認できるようにしておくと、いくらか捗ると 思いますので、その設定を示します。 (defvar my/current-cleanup-state "") ;; 行末のスペース + ファイル末尾の連続する改行の除去を行う (defun

    delete-trailing-whitespace周りの設定 - Shohei Yoshida's Diary
  • all-ext.el:対象行を絞り込んでからまとめて編集するM-x allを超強化!occurと融合&anything・helmと連携 - http://rubikitch.com/に移転しました

    お久しぶりです。 みなさん、M-x allって知ってますか? M-x package-install all でインストールできるのですが、これはM-x occurのように正規表現にマッチする行を表示します。 occurとの違いは表示結果を書き換えれば、該当部分が自動的に書き変わることです。 ユースケースとしては、編集対象行を絞り込んでから、置換やrectangle系コマンドで一気に編集するって感じです。 便利なので以前から重宝しています。 ただ、occurより劣る点としては、対象行の行番号が出ていない点と、M-g M-n (next-error)とM-g M-p (previous-error)で移動できない点です。 (union all occur) occurで絞り込んだはいいけれど、その結果をやっぱり編集したいという場合に改めてM-x allを実行するのは面倒ですね。 そこで、拙作

    ainame
    ainame 2013/11/06
    all便利そう
  • ダメなデイリースタンドアップについて。 - Sooey

    ダメなデイリースタンドアップについて。 CarbonFiveのブログにWhy Your Daily Standup Sucks (and how to fix it)といういいエントリがあったので、ポイントを簡単に訳して紹介しておきます。 詳細を話しすぎる 誰かが詳細を聞きたがったら、それはスタンドアップの後で話し合え みんな準備不足 毎日同じ時間にやることがわかっているのだから、準備をしたうえで時間通りに参加しろ スタンドアップの前に記録した作業時間、コミット、作業中のストーリーを確認しておけ 問題解決しすぎ デイリースタンドアップでは状況のアップデートだけをせよ 議論や問題解決をするときではない 合言葉は"take it offline" 障害を取り除こうとせよ スタンドアップの「あと」で障害に取り組め 誰かから「それについては力になれるよ」と聞ければ充分 ホワイトボードをスタンドアッ

  • CPANモジュールは依存モジュールのバージョンを固定しない方がいい | おそらくはそれさえも平凡な日々

    Perl界隈ではCarton周りのtoolchainが整ってきて「これからはsemantic versioningやー」みたいな意識が高まりそうですが、そういうルールに則ってバージョニングをするのは大いに結構だとは思うのですが、バージョン違いのモジュールを同一プロセスで共有するとかそういうことはPerlではできないのでどちらにせよ注意が必要です。 まあ、バージョン違いのモジュールを共有できたところで、バージョン違いのオブジェクトが変なところに渡って死ぬみたいな話もあったりなかったりするらしいので夢を見過ぎるのも良くないですね。 それとタイトルのとおりですが、CPANに上げるモジュールの場合はバージョンは固定したり最大バージョンを決めない方が良いでしょう。 例えば、 Super::ORM が Mouse 2.0に固定依存 Hyper::WAF が Mouse 3.0に固定依存 だったりすると

    CPANモジュールは依存モジュールのバージョンを固定しない方がいい | おそらくはそれさえも平凡な日々