設定のテストを書くとよいって言ってる人がいた． 設定の仕様をドキュメントに書くのではなく、テストにしてしまう - $shibayu36->blog; テストされてるのはよいと思う．名前のついてないデータ構造をがんばってテストするよりは，設定のクラスを作るとすっきりしそうと思った． こういう構造のHash，として見るよりかは，設定クラスのインスタンスとして見るほうがイメージしやすい． 個々のブログの設定のURLはユニークであるというのを，どこかのクラスの責任にする．BlogConfigRepositoryというクラスのインスタンスが，設定の集合を持ってるとか． like exception { BlogConfigRepository->new([ { "url" : "http://blog.example.com/", "permission" : "public", "members"

marqueeタグ，最近人気ないけど，かわいいので，使っていきたい．今日の日記もmarqueeにすることにした．あなたの意図に反してこの文字が流れていたら私の意図通りこの文字が流れていると言える．フィードリーダーとかではmarquee出せない気がするので，わざわざ元のページ開いて見てほしい．現実世界には，あまり流れる文字ない気がするけど，巻物とかがんばって巻くとmarqueeになる．本はmarqueeじゃなくて，Page Downという感じだから，あまりもう紙では見ることない気がする．身近なmarqueeとしては，新幹線とか乗るとmarquee見れる．自分が新幹線作ることを考えると，乗客にmarqueeを見せ続けて便利というのは不気味だから，新幹線考えた人は偉い．普通は乗客にmarquee見せようと思わないと思う．あと京都駅の駅前に防災情報みたいな電光掲示板が設置されてて，そこでmarqu

コードレビュー，慣れるとできるけど，いきなりdiffを渡されて，どうぞ見てくださいと言われてもよくわからないと思う． やりましょうというのはいいけど，ただむやみに読んでもうまくいかない．変更がある程度大きくなるとdiffだけ見てもよくわからないので，いろいろ見ることになる． 僕はいつも以下のようなことを無意識にやってて，うまくいってる気がしてる．GitHubのPull Requestの仕組みを使ってる前提で． Discussionをさらっと眺めてどういう問題を解決したいのか見る Commit Statusを見て，テスト通ってることを確認する Commitsタブで1コミットずつブラウザの新しいタブに開く 全部クリックし終わったら古い順に1コミットずつ読む 気になる点があったらエディタとかにメモしておく．あとで書き直されるかもしれないので，まだコメントしない 全コミット見終わったらFiles

テスト書きすぎるとよくないって言ってる人がいた．DHHっていう人．作業時間の1/3以上テストしてたらおかしいとか，ActiveRecordのバリデーションなど，Railsの機能はテストしない，とか． Signals vs. Noiseの去年のエントリに、テストをどれくらい書くべきかということについてDHHが指針を示していたものがあったので... - Sooey 偉い人が言ってるからという理由で，テスト手抜き派の人に良い材料を与えてしまった．僕は意見ちがって，作業時間半分以上はテスト書いたりしてる． テストたくさん書くと，最初に書くときのコストは増える．けど，あとから読む時や，変更したい時には，読むだけだし，書くのも差分だけで良い．コード本体を理解できれば，要らないテスト捨てるのは，落ちたのを消すだけだから簡単．あとで見て，テスト足りないと分かったときに，明文化されてない仕様からテストを補う

近年、若者の語彙が貧弱になって、便利とか最高みたいな言葉しか発しなくなっている。宇宙のエントロピーは増大していくので、普通にソフトウェア作ってると、だんだんめちゃくちゃになっていく。めちゃくちゃになったソースコードは読んでも理解できないし、そこから変更するともできない。それに抵抗するために、リファクタリングといって、似たような機能はまとめるとか、難しいところを読みやすくするとかして、ソースコードをきれいに保つ必要がある。人よって書き方がばらばらだと統一感がなくて読みにくいので、コーディング規約で、誰が書いても同じ仕上がりになるように定めている。リファクタリングやコーディング規約で、勝手に増えるエントロピーを減らしたり、増える勢いを抑えたりできる。近年のソフトウェア品質への関心の高まりによって、重複を排除する考えが広まり、日本語も、意味が同じものは自然にまとまっていって、良いみたいな意味のと

Perlのソースコードから，文単位でトークンをgit grepするのを作った． 普通のgrepは行単位の検索なので，これまでgit grepするとき， メソッドの呼び出しが複数行に渡ることが予想されるとき，勘で-A 5 とかやって，後ろ5行も表示，とかやってたけど，勘に頼っていて，不便だった．ソースコードはトークン単位とか文単位なので，行単位で扱ってもあまり意味がない． GitHubに，git-grep-perl-statementというのを置いてある． hitode909/git-grep-perl-statement · GitHub 例 git-grep-perl-statementのソースコードから，coloredというトークンを探してみる． % git grep-perl-statement colored git-grep-perl-statement:61 colored($

ウェブアプリケーションのJSのテストするのにCasperJS使ったら便利だった． CasperJSはPhantomJSにテスト用ユーティリティがついて便利になったやつ． JS，MVCできれいに書いてると，Modelの単体テストとかできるけど，昔ながらの感じだと，ここをクリックしたらこれが表示されること，みたいなテストを書くことになる．けどライブラリとかいろいろあってどれを使えばよいか分からなくて敷居が高い．CasperJSを使ったらこれだけで完結してテスト書ける． PhantomJSは単なるブラウザだけど，CasperJSはテストのフレームワークとか，DOMのテスト関数とかがついてる． 非同期なタスクの実行の仕組みも入ってて，casper.thenっていうのを順番に書いていくと，順番に呼んでくれて，click()して，casper.thenしたら，ページ遷移したら次のページに移動してる．ス