テスト先に書きたい若者よ - hitode909の日記
弊社では毎年インターンを受け入れているのだけど，いまもインターンが来てて，テスト先に書きたいけど油断すると先に実装を書いてしまう，とか話してた． 個人的には，テスト先に書くのが大事というよりかは，意識して仕様を先に考えるのが大事だと思っている．テストを先に書くと，先に仕様を考えざるを得ないので，良いスタイルが身につく． 僕がよくやるのは，関連しそうなクラスの絵をひと通りノートに書いてみて，その図だけで，うまく動くことを説明できるくらい考えてみる．その時点でおかしかったら，コード書いてもおかしくなる．ノートに方眼ついてるとクラス図書きやすい．UMLとかじゃなくても，自分で見て分かるくらいでもいいと思う． 紙でうまくいったら，外部仕様だけソースコードに書いてみる．クラス名と，メソッドの定義と，メソッドの上くらいに，ひと通りコメントでも書いてみて，この関数はこういうことをするんです，こういう引数
設定のクラスを作るとすっきりしそう - hitode909の日記
設定のテストを書くとよいって言ってる人がいた． 設定の仕様をドキュメントに書くのではなく、テストにしてしまう - $shibayu36->blog; テストされてるのはよいと思う．名前のついてないデータ構造をがんばってテストするよりは，設定のクラスを作るとすっきりしそうと思った． こういう構造のHash，として見るよりかは，設定クラスのインスタンスとして見るほうがイメージしやすい． 個々のブログの設定のURLはユニークであるというのを，どこかのクラスの責任にする．BlogConfigRepositoryというクラスのインスタンスが，設定の集合を持ってるとか． like exception { BlogConfigRepository->new([ { "url" : "http://blog.example.com/", "permission" : "public", "members"
コードレビュー - hitode909の日記
コードレビュー，慣れるとできるけど，いきなりdiffを渡されて，どうぞ見てくださいと言われてもよくわからないと思う． やりましょうというのはいいけど，ただむやみに読んでもうまくいかない．変更がある程度大きくなるとdiffだけ見てもよくわからないので，いろいろ見ることになる． 僕はいつも以下のようなことを無意識にやってて，うまくいってる気がしてる．GitHubのPull Requestの仕組みを使ってる前提で． Discussionをさらっと眺めてどういう問題を解決したいのか見る Commit Statusを見て，テスト通ってることを確認する Commitsタブで1コミットずつブラウザの新しいタブに開く 全部クリックし終わったら古い順に1コミットずつ読む 気になる点があったらエディタとかにメモしておく．あとで書き直されるかもしれないので，まだコメントしない 全コミット見終わったらFiles
スキーマレスなオブジェクトたちからスキーマを推測するやつ - hitode909の日記
MongoDBなどはスキーマレスなデータベースであり，先にスキーマ決めなくても，何でもつっこめることになってる． データベースから見ればスキーマレスということでいいけど，アプリケーション的には，何が入ってるかちゃんと管理したい． 下の例では，AliceとBobでは持ってるフィールドがちがって，Bobはhobbyを持ってるけど，Aliceは持ってない． { name => 'Alice', age => 20, } { name => 'Bob', age => 21, hobbies => ['tennis', 'soccer'], } これくらいなら見れば分かるけど，長期間運用してて，結局何が入ってるのか分からない，みたいなことがあって，難しかった． オブジェクトをどんどん渡していくと構造を教えてくれるのを作った． hitode909/perl-object-classifier · G
自作オブジェクトのイベントのやりとりにはjQuery.triggerではなくjQuery.triggerHandlerを使うほうがよいと思った - hitode909の日記
DOMオブジェクトには昔からdispatchEventとか，addEventListenerとかあって，最近だと，node.jsのEventEmitterとか，jQueryのon, triggerを使って自作のオブジェクト間でアプリケーション的に定義されたイベントをやりとりできる． これまで，自作オブジェクトからイベントを発行するのに，jQueryのtriggerを使ってたけど，意図しない挙動をすることがあることが分かって，triggerHandlerを使うように変えた． jQuery.trigger()は，イベントタイプと一致する関数をレシーバが持ってるとき，その関数が呼ばれる． イベントのやりとりと，メソッドの呼び出しは独立しているというイメージがあったので，うっかり同名のメソッドを定義したときに，一見するとよく分からない挙動になって，難しい． なので，自作オブジェクトがイベントを発行
テスト書きすぎ問題 - hitode909の日記
テスト書きすぎるとよくないって言ってる人がいた．DHHっていう人．作業時間の1/3以上テストしてたらおかしいとか，ActiveRecordのバリデーションなど，Railsの機能はテストしない，とか． Signals vs. Noiseの去年のエントリに、テストをどれくらい書くべきかということについてDHHが指針を示していたものがあったので... - Sooey 偉い人が言ってるからという理由で，テスト手抜き派の人に良い材料を与えてしまった．僕は意見ちがって，作業時間半分以上はテスト書いたりしてる． テストたくさん書くと，最初に書くときのコストは増える．けど，あとから読む時や，変更したい時には，読むだけだし，書くのも差分だけで良い．コード本体を理解できれば，要らないテスト捨てるのは，落ちたのを消すだけだから簡単．あとで見て，テスト足りないと分かったときに，明文化されてない仕様からテストを補う
Perlの使ってないメソッド探すやつ - hitode909の日記
Perlの使ってないメソッド探すやつ作った． hitode909/perl-find-unused-methods · GitHub r7kamuraさんのやつそこそこ使えるって聞いたのでPerl用のを作ってみた． https://github.com/r7kamura/guideline/blob/master/lib/guideline/checkers/unused_method_checker.rb プロジェクト内で，fooっていうメソッド定義だけして，プロジェクト内で呼んでないときに，消しましょうって教えてくれる．メソッド名だけ見ているので，他のクラスに同名のメソッドがあって，そっちは呼んでない，みたいなのは発見できない． 中村さんのはメソッドの定義とかにフックしてコールバックが呼ばれるといったかっこいい設計だけど，Perlでどうやるか分からなかったから，PPIでsub xxx
TAP::Harnessの結果を左右反転して出力するTAP::Formatter - hitode909の日記
Perlのテスト実行するときproveとかやると何か結果が出るけど，これの出力するのをプログラムから操作したいと思って，TAP::Harness読んでた． TAP::Harnessのコンストラクタに自作のformatter_class(これはテストが終わったときに結果を整形するクラス)を渡して，formatte_classのopen_testの返り値で自作のSessionクラス(これは一行ずつ呼ばれるやつ)を渡すと，Sessionクラスのresultに各行のオブジェクトがやってくることが分かった．merge => 1すると テスト失敗したときに構造化されずに出てくる# Failed test みたいなのもSessionで受け取れる．必要な分だけ書きたいのでデフォルトのクラスを継承してちょっとだけ書く． 意味ないけど，とりあえず，出力が左右判定するproveみたいなの作っておいた．これ自体に
■ - hitode909の日記
ウェブアプリケーション作るためのフレームワーク、ジェネレータでControllerができるとか、RESTfulなルーティングを簡単に作れるとかあるけど、そういうのは手で書いてもすぐできる。ジェネレータで作って終わりみたいなのがほとんどだけど、フレームワークから外れたことしようとするとすごい大変になる。フレームワークなければ普通に書けばいいけど、フレームワーク使ってると、規約に沿わないといけない。一部のメソッドを上書きしてちょっと変わった動きをさせるとか、そういう感じになって、フレームワークのバージョン上がったとき動かなくなったりする。変なことをして無理に書くのはやめようと言われるけど、そう書かないといけないフレームワークが悪い。普通に書けるなら普通に書いてるはず。仕様決める人はフレームワークのことまで考えてるはずがないから、全員損してる。フレームワーク的には、きれいで完璧で整合性の取れたア
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
