Groovyをbrewからgvmに乗り換えるメモ - 日々常々
brewいいんですが、なんかgvmが流行なので乗り換えるです。 gvm? http://gvmtool.net/ 「the Groovy enVironment Manager」らしいです。とりあえず rvm っぽいものです。rvm もそんなに理解してないんですが。 gvmのインストール 書いてる通りやります。 $ curl -s get.gvmtool.net | bashJAVA_HOME 設定してないって怒られた(´・ω・｀) ぶっちゃけ未だに Mac の JAVA_HOME とかよくわかってないです。勢い余って JDK8 の方で突っ込みかけた*1けど、そんなので詰まっても困るのでフツーにてきとーに設定して、もっかいコマンド実行。 なんか派手だ。 brewのを外す こんななってます。私は Groovy2.1 を気軽に触りたいのですが、brew で update してもまだな感じ。 $
職業PGにわかるFizzBuzz - 日々常々
なんかFizzBuzzが書けないPGがどーとか定期的に話題になってるけど、私に言わせれば説明の仕方が悪い。 こうすれば誰でも書ける。 これだから最近の若いもんは……。 GoogleDocsのスプレッドシート、方眼紙作るのに向いてませんね……。
ToDoリストのすすめ - 日々常々
TDDBCでTAやってぼやっと思ったことシリーズ。シリーズ？続くの？ - TDDBCのお題はざっくり「何ができるか」が書かれてることが多いですが、これはテストを書くのに十分な粒度ではありません。少なくともお題をそのままテストメソッド名にしてしまうのはダメなパターンです。簡単なところは上手く行くこともありますが、すぐに厳しくなると思います。 これは実際の開発でもよくあります。例え設計者が別に居たとしても、詳細設計書に書かれているものが十分であったことはあまり記憶にありません。咀嚼して適切な粒度に整理し直す必要があります。*1 TDDでのテストの歩幅は人それぞれだなので、明確な答えを示すことはできませんが、「何をテストすればこれができたと言えるか」が明確でない……言うなれば assert から書き始められない場合は、階段の段差の高さが自分のスキルに見合っていないと言うことです。 まず全体を見て
テストが間違ってたら？ - 日々常々
「テストが間違ってたらどうするんだ」 自動テストの話をするとよく言われます。テストが間違ってたらわからないじゃないか。手動テストであれば、注意深く目で確認していれば間違いに気づけると言う主張です。 「目で確認していれば気づける」のは間違いではありません。必ず気付けるわけではありませんが、十分な知識を持った人が、十分な集中力と責任感をもってエビデンスを確認すれば、誤りに気付ける可能性は高いと思います。 品質(主に機能性)を目的とした自動テストでも、それを行う必要があります。それがテストコードのレビューです。 手動テストの場合、テスト実施前に手順や確認項目のレビュー、実施中の確認、実施後のエビデンス確認と、人が確認するタイミング*1が三カ所あります。 これに対し自動テストの場合、テストが書かれた時のみ。実行中は勿論、実行結果の確認に注意はありません。ただ成功か失敗かだけなので。ならば、テストコ
見やすいコードのために出来るたった一つのこと - 日々常々
タイトルは釣りっぽいですけど、結構まじめ。 フォーマッターを使用すること。 これが全てです。「スペースがどうこう」とか「括弧の位置がどうこう」とかどうでもいいです。そんな美的感覚でかわるような枝葉の話に結論は出ません。 コードフォーマッターを使用してください。そのプロダクトを通して、統一された同じフォーマッターでフォーマットすること。コードはそれだけで格段に見やすくなります。個々人が好き勝手にやったり、気をつけたり、CheckStyleなどでの見た目の警告を処理したり……そんなのしてたら不統一で見難いコードにしかなりません。 個人個人での見やすさとかはあります。当然です。例えば変数代入のイコールの位置がそろってる方が見やすい人もいます。変数宣言は1行開いてた方がいいって人も、メソッド間は2行開いてた方がいいとか、賛同できませんけどそんな人も居ます。そう言うときは自分専用にフォーマットして、
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
