2013/10/12 (土) に行われた「師弟登壇・新米サムライの集い 2013」の反響まとめです。 「師弟登壇・新米サムライの集い 2013」 http://kiban.doorkeeper.jp/events/5291 続きを読む
![師弟登壇・新米サムライの集い 2013 まとめ](https://cdn-ak-scissors.b.st-hatena.com/image/square/e31b012915473d77c76c39382e56052b405138b7/height=288;version=1;width=512/https%3A%2F%2Fs.tgstc.com%2Fogp3%2F3f3f42feffc602808b6ac5566030c5e3-1200x630.jpeg)
2013/10/12 (土) に行われた「師弟登壇・新米サムライの集い 2013」の反響まとめです。 「師弟登壇・新米サムライの集い 2013」 http://kiban.doorkeeper.jp/events/5291 続きを読む
テスト書きすぎ問題 - hitode909の日記 いい話。だいたい同意見で、テストはなるべく書こうとしたい。後からコードに変更を加える人が安心できるように、テストには書いてるコードがどう有るべきかという情報が全部網羅されていてほしい。コードがあるべき状態ではなくなって動かなくなったときは、必ずテストが落ちて欲しい。 とはいえ、テスト書きすぎてしまって良くなかったなあと思うことはある。アプリケーションの設計の階層が無駄に深くなっていて、各階層ごとに似たようなテストをなんども書く事態に陥ったりするような場合だ。 例えば、何かブログみたいなWebアプリを作っていて、エントリー投稿する機能を実現する機能が以下のクラスに含まれていたとする。 Blog::Controller::Entry ディスパッチャから呼ばれるエントリーポイント Blog::Handler::Entry HTTPリクエストからE
テスト書きすぎ問題 - hitode909の日記、階層を増やしすぎるとテストが多くなりがちという問題 - はこべにっき ♨みたいにテストの話が何個か出たので、ちょっと関係ないけど最近のテストで気をつけていることの一つについて書こうと思う。テストを書くときに気をつけていることとして、そのテストが何をテストしているのかという対応関係を明確にしながらテストを書くということを気をつけている。 例えば以下の様なクラスがあるとする。 package Blog; use strict; use warnings; sub new { my ($class, $args) = @_; return bless $args, $class; } sub has_favicon { my ($self) = @_; return !! $self->{favicon_path}; } sub favicon_
きっかけ CI ツールについて調べていたところ、こちらで話題になっていたのを思い出して また、内部で redis 使われているとのことなのでさらに興味津々 Altria という名前がカッコイイ 詳細はこちらに紹介されており、Ruby でプラグインを書けるというのは魅力的なのではないか 導入 今回は素の CentOS 6.4 にインストールする。 SELinux と iptables はとりあえず止めておく $ sudo getenforce Disabled $ sudo /sbin/service iptables stop 必要なパッケージを yum からインストール sudo yum install wget gcc make zlib-devel openssl-devel mysql-server git readline-devel gcc-c++ MySQL サーバーは起動し
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く