JenkinsでGitHub Pull Request Builder pluginを使いつつ任意のブランチにpushしたコミットもビルドする - その手の平は尻もつかめるさ
JenkinsでGitHub Pull Request Builder (ghprb) を使っている時に，pull request以外のcommit (例えばmasterへのマージコミットや任意のブランチへの直push) もbuildしたいんすよね〜みたいなことをid:hdkshjmさんに相談したところ良い感じの方法を教えてもらったのでメモとして記すものです．ありがとうございます！ 前提として ghprbの設定は済んでいる Git pluginがインストールされている GitHub pluginがインストールされている GitHubのリポジトリのWebhook設定で $JENKINS_BASE_URL/github-webhook/ に向けてpushイベントを設定している ものとします． そんでもって以下のようにすると良い: プロジェクト設定のGit SCMのリポジトリ設定でRefspec
情報共有システム (Wiki みたいなやつ) に求めること - その手の平は尻もつかめるさ
いま所属している組織で使っている情報共有システムが僕はいまいち好きではなくて，気に食わないところを twitter にガーッと書いたんだけど，さてここで「良い情報共有システムとは」と考えた時にスッと言語化出来なかったので，僕の思う情報共有システムに求めることをここでまとめておくことにする． エディタが腐ってない これは本当に重要で，エディタが腐っていると「Wiki を書こう」という気がそもそも起きないし，起きたとしてもエディタがストレスフルだと文章を書き始めてすぐに嫌になってしまうので最低限エディタはまともである必要がある．さもなくば Wiki は廃墟と化す． WYSIWYG なエディタを利用するのは難しいと思っていて，本当に使いやすい WYSIWYG エディタを作るというのはかなりコストが高い (WYSIWYG エディタはある程度まで完成度が高まっていないと使い物にならない気がする) の
perl6 の環境を手っ取り早く構築してサクッと Hello world する - その手の平は尻もつかめるさ
本記事はサクッと perl6 (rakudo) が動く環境を作って，ズバッと Hello world してみるというやつです． 早速行ってみましょう． 1. rakudobrew をインストールする rakudobrew をインストールします rakudobrew というのは perl5 で言うところの perlbrew/plenv，ruby で言うところの rvm/rbenv のようなものです． なぜこうした物を使うかというと，perl6 は開発が非常に活発な言語であるためにデイリーで変更が入っていて，直っていたり壊れていたりするためです． 2015年10月現在，perl6 をやるときは rakudo と MoarVM は HEAD を使うというのが紳士の嗜みとなっています *1． というわけで入れましょう． git clone https://github.com/tadzik/rak
Groovy 所感 - その手の平は尻もつかめるさ
開発のサポートツールやらなにやらで，こまごましたものを Groovy でちょいちょい書いて思ったことです． Groovy で Web アプリケーションを書いたとかそういうゴツい話ではないのでそのあたりはよくわかりません． なお本記事中に出てくる Java っていうのは Java 8 以降のことを指していると思ってください． 所感 楽にコードが書けるという点では良い．言語的にそういうところを重視している気がする． defとか．あとは DB 操作とか結構良い．楽． System.out.println() とか書かなくて良いのは本当に良いですね． とは言え，なんだかんだで補完の支援を受けないと記述コストは大きいと思う．賢い補完が要る． gradle は pom.xml 書くよりもストレスが小さい気がする． とは言え maven でもめんどいことは gradle でもめんどい印象． 結局なんか，
「メソッドに対してテストをするな」という話題について - その手の平は尻もつかめるさ
―「間違っているかもしれないので，その時はこの銃で僕を撃ってくれ，良いね？」 [2014-05-19T17:48:28Z 追記] http://a-suenami.hatenablog.com/entry/2014/05/17/131326 補足してもらったので読むと良いと思います． わかっちゃはいたけれど上手く言語化できていなかった部分，あるいはわかっていない部分について言及されていたので参考になりました．ありがとうございます． いやーつーかさー，「『メソッドに対するテスト』っていう言葉自体がわかりにくくね？」っていうのはその文言を見たり，この文章書いている間もずっと思ってて，つまり端的に言うとそういう事を言いたかったはずなのに，今このエントリ読み返すとそうした[趣主]旨から完全にズレててメッチャ違和感あるな！ ってなりました．俺のバカ！ これを仮に言い換えるとしたら「内部構造に対するテ
「Webアプリエンジニア養成読本」を読みました - その手の平は尻もつかめるさ
Perlの話がほぼ出てこないこの本はクソ！！！！！ (嘘です．著者の1人にそう書けって言われたものだから……) Webアプリエンジニア養成読本[しくみ、開発、環境構築・運用…全体像を最新知識で最初から! ] (Software Design plus) 作者: 和田裕介,石田絢一(uzulla),すがわらまさのり,斎藤祐一郎出版社/メーカー: 技術評論社発売日: 2014/03/11メディア: 大型本この商品を含むブログ (2件) を見る Webアプリの着想・設計・制作・運用までバランスよくまとまっていて良い本だと思いました．この手の書籍で運用にまつわる話が載っているのは中々珍しい気がします． 1章 基本的なWebの技術 (HTTPとかServer-ClientアーキテクチャとかHTMLとか) の説明が優しく，わかりやすくて良いです．僕もWebアプリ触り始めの頃にこれを読めれば！！！！ と
GroovyTestCase のshouldFail() に関して。あと再発明してました。 - その手の平は尻もつかめるさ
groovy.util.TestCase のshouldFail(Closure code) は「何らかの失敗が期待されるテスト」に用いると絶大な効力を発揮します。 「何らかの失敗」というのはError でもException でも“assert false” でも、とにかく正常にプログラムが動かない状態の事を指します。 例えばこのような感じ。 これらは全て「何らかの失敗」をするので、shouldFail(Closure code) は成功します。したがってテストはパスします。 このようにshouldFail(Closure code) は大変便利ですが、いささかパワフル過ぎるケースもあります。 例えばこんなJava のメソッドのテストをしたい時を考えます。 (このサンプルソースについて深く考えないで下さい。深く考えたら負けです！！) この場合、shouldFail(Closure cod
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
