Hatena::ブログ(Diary)

bobchinの日記 このページをアンテナに追加 RSSフィード

2009年01月22日(木)

[][]EmacsRubyレベルアップをしたい 10:33 Emacs と Ruby のレベルアップをしたい - bobchinの日記 を含むブックマーク

プログラミング言語 Ruby

プログラミング言語 Ruby

これが出るらしいので Rubyレベルアップをしたいと思ってます。


こんどこそ本当に!!!


これまでもやろうとして挫折してきました。

基本的な文法は理解しているつもりですが、如何せん使う場がなくて

わすれてしまうという繰り返しです。

これは Emacs も同様です。

普段は Eclipse を使っているのでこれ以上の良さがないと移行しずらいのです。

で、Rubist はEmacs 使いが多いらしいので

上記のコンボレベルアップできないかと思ってます。

Ruby については一定規模のコードを読むか自分で何か作るかがいいと思ってるのですが、

よいおすすめとかはないでしょうか?

PHP 版を作ろうとして Amritaソースは読んだことがあった気がします。

誰か師匠になってください!!

また、札幌な人なので一緒に勉強してくれる人とかいないでしょうか?

2008年10月31日(金)

[]かなり遅いけど 13:58 かなり遅いけど - bobchinの日記 を含むブックマーク

http://d.hatena.ne.jp/takahashim/20081028#p1

なんか胸にグッときた。

やっぱいけなかったのは残念極まりない。。。

言語関係ないとは思うけど、

PHP でもこういうことができればいいのにな。

2008年10月29日(水)

[]和田さんのLTを見た 09:07 和田さんのLTを見た - bobchinの日記 を含むブックマーク

http://www.nicovideo.jp/watch/sm5072096

http://d.hatena.ne.jp/t-wada/20081025/p1

発表はこういう風に何か新しいことを提言できるようになれればいいなと思いました。

で、中身ですがリファクタリングを進めるためにユニットテストを書くけど、

テストが増えたらリファクタリングしたくなくなるよね?テストを書き直す手間が増えるので。

じゃ無駄テストを減らすために「カバレッジ」を使ったら?

ってなことだったと思います。


「修正」

重複しているテストを削除してカバレッジが変わらなければ削除していいんじゃないか?

という予想のようです。

一瞬思ったのですが、単純にカバレッジ率を見るのではなく、

カバレッジしている箇所に変化がないのを確認しないと危ない気がしました。

重複しているテストを削除して

カバレッジしている箇所に変化がなければ

削除していいんじゃないか?という予想のようです。

と考えると若干難しそうな気もしました。

素早く判断はできないような気もするので。

目からウロコな考え方なのでとても刺激を受けましたです。


名前が出てた川西俊之さんって

TestLinkな方なんでしょうか?

これっていわゆるCodeReposみたいにテスト自体をみんなで共有できたら

コードの質が上がるようにテスト自体のレベルが上がったりしないもんでしょうかね?

「追記」

余計なテストを記述せずに、質の高いテストを書くのが必要だろう。

ということはデザパタのようなパターンだったりそういうものも大切だよなぁとか。

既にあるのかもしれないな。


[]らしさ 09:26 らしさ - bobchinの日記 を含むブックマーク

http://kakutani.com/20081026.html#p01

きっと「札幌でやる」ということの意義というか意味というかってことなんだろうけど、

なんて設定基準が高いんでしょう。

だからイベント自体が質が高いんだろうなと思います。

さて、PHP勉強会どうしたもんでしょう?

PHPer 的には CakePHP 関連が近いものになっていく予感もしますが、

PHPerの気質というのもあるからなぁというのがなんとなく心配のような

なんちゅうか本中華???な感じ。

t-wadat-wada 2008/10/29 12:32 t-wada です。発表をご覧下さってありがとうございます。

> 重複しているテストを削除してカバレッジが変わらなければ削除していいんじゃないか?という予想のようです。
>
いえ、これは違います。↓ の bobchin さんの意見と同じことを言ったつもりなので、誤解を生む可能性があれば、私のミスです。申し訳ございません。

> 一瞬思ったのですが、単純にカバレッジ率を見るのではなく、カバレッジしている箇所に変化がないのを確認しないと危ない気がしました。
>
その通りです。私の案では、二つのテストのカバーしている範囲を調べ、カバー箇所が完全に内包されている場合には小さい方を消すことが出来るのではないかという考えです。なので、カバレッジ率は見ません。

http://www.slideshare.net/t_wada/sapporo-rubykaigi01-twada-lt-presentation?type=powerpoint
でいうと 50 ページ目です。

> と考えると若干難しそうな気もしました。
>
と、いうことになります。これまでのテスト全体でのカバレッジの取り方や考え方とは少し違うので、これから色々試してみる必要があると考えています。

ご意見ありがとうございました。他にも何かご意見や発見がありましたら、お教え下さると幸いです。

bobchinbobchin 2008/10/29 12:52 コメントありがとうございます。
「内包」とちゃんと書いてありましたね。
申し訳ありません。仕事しながらで動画を見ていた私の方のミスリードですね。