Java17雑感 - 日々常々
LTSとなるJava17が出ました。組織が今後もJavaを使っていけるかの試金石になるバージョンだと思います。 実際のとこLTSだから特別安定してるとかそんなことはないと思うし、6バージョン（3年）ごとにLTSにするってのもたぶんOracleさんが言ってみただけで、いろんなとこがそれに乗っかってるから、実質的に節目になってるに過ぎない。はず。 その程度のものなんだけど、私のようなのは乗っかりますし、たぶん多数派なんじゃないかなぁ……この派閥が運用で使うJavaのバージョンは8、11、17で、他のバージョンは評価に使うくらいでしょう。 11から17のジャンプになるんで、かなりたくさんの変更がありますが、業務アプリケーションの表層に関係するものはそこまで多くありません。パフォーマンスとかに影響のあるものは多々ありますが、基本的には早くなるはずで、問題になることは稀です。稀なことはよくあるんです
ArrayListじゃなくListを使うという話 - 日々常々
具象型ではなく抽象型で扱え、インタフェースを使え、みたいなお話に対して。 前置き Javaの話。他の言語だと話は変わります。 「こうするのが絶対的に正解」と言うものではありません。私の現在の選択の説明です。明日になったら違うこと言ってるかも。 主な登場人物は掲題の java.util.ArrayList および java.util.List、そして java.util.Collection と java.lang.Iterable です。 こんな世界観。他のインタフェースやクラスもたくさんありますが、この話の本筋では無いので触れません。 前提として以下を置いています。 フレームワークやライブラリではなく、一つの業務アプリケーションに閉じた話です。ゆえに不特定多数から使われる型ではなく、影響を与えるコードは全て目が届く範囲にあるものとします。 計算量は別の話です。扱うドメインにもよりますが、
assertEqualsよりassertThatが好きなわけ - 日々常々
assertEqualsよりassertThatが好きなのは、Matcherもあるけど、引数の順番に悩まないからです。英語として云々なんてどうでもいい。。。。 2012-07-13 00:07:14 via YoruFukurou 元ネタ*1は「xUnitよりRSpecがいいとか言ってたひとは英文ぽいのがいいとか言ってたけどさー」みたいな感じでしたが、xUnitであるところのJUnitでも最近は assertThat なんてもんが入って英文ぽさを売りにすることもあったりなかったり。 ツイートでも言ってる通り、英文ぽさなんてどうでもいいと思ってます。可読性は大事だけど、読めるならそれ以上は要らない派。ならば決め手は何だ。書きやすさと、エラー時の表示です。 assertEqualsのばあい こんな感じに書きますね。短い。書く量が少ないのは良いです。でも１番目と２番目どっちがどっちだったか。 a
「自動生成でプログラマ不要」とかゆーの - 日々常々
「自動生成」って言葉を聞くと、前のめりになったり顔をしかめたりと人によって反応は様々です。ですが「自動生成でプログラマが不要になる」と言われると「ばかじゃねーの」となると思います。 少しも「ばかじゃねーの」と思わない人はコンテキストが根本からズレてますので、以下は読む必要ありません。そこをあわせるつもりは無いですので。 自動生成されたコード 生成元はなんであれ、コードを自動生成すると言うアプローチはよくあります。 ここではコード全体を自動生成する場合を指すと思ってください。生成されたコードがそのままコンパイル可能である状態です。言ってしまえば「バイナリを自動生成する元であるコードを自動生成せざるを得ない」ってことで、さらに誤解を恐れずに言えば「扱っている言語は表現力に乏しい」となります。だって高級言語なんて人間が扱えるように作られてるはずなのに、それよりも読みやすく書ける上にそのままコンパ
コメントについて考えてみた - 日々常々
やきに駆動2.0で話した内容です。 資料 コメントについて考えてみた 長いよ？ コメント書いてますか？ コードにコメントを書くことは、犬の散歩で糞を持ち帰ることくらい常識的なマナーです。皆さんコードにコメントは書いていらっしゃるでしょうか？ 書いてます？書いてます。はい。そうですよね。……なんで？ コメントを書く理由を考えたことはあるでしょうか。コメントを書くと、コストがかかります。コメントを書く程度のコストは無視できるものかもしれませんが、書いたコメントを残すと、残っている限りずっとコストをかけ続けることになります。なので、コメントにはリターンが求められて然るべきです。理由のないコメントは、未来の混乱を招く優れた方法です。 コメントを書く動機 コメントを書きたいと思う動機は様々あります。コードがわかり辛いところに説明を書いておく。実装の仕方がわからなくてコメントで書いて次に進んでおく。な
変更前をコメントアウトして残す習慣は未だ根強い (2012年現在) - 日々常々
2020-03-11追記: タイトルの「未だ」がいつなのかわかりづらいので「2012年現在」を追加しました。 バカバカしい話ですが、ソースコードをSubversionなどでバージョン管理しているにもかかわらず、未だ修正前をコメントアウトして残す習慣は残っているところも多々あります。こういうのです。 // 2012/08/15 irof 修正開始 // hoge = fuga(1); hoge = fuga(2); // 2012/08/15 irof 修正終了 見た事無い方は、そのまま見ないままで生きていかれることを切に願います。 コメントの修正がある場合 2012/07/21にあった、SCMBCでこんなツイートがありまして。 この時点でお見せしたのはこんな感じ。 // 2012/07/21 削除開始 // // 間違ったコメント // 2012/07/21 削除終了 someMethod
職業PGにわかるFizzBuzz - 日々常々
なんかFizzBuzzが書けないPGがどーとか定期的に話題になってるけど、私に言わせれば説明の仕方が悪い。 こうすれば誰でも書ける。 これだから最近の若いもんは……。 GoogleDocsのスプレッドシート、方眼紙作るのに向いてませんね……。
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
