Java17雑感 - 日々常々
LTSとなるJava17が出ました。組織が今後もJavaを使っていけるかの試金石になるバージョンだと思います。 実際のとこLTSだから特別安定してるとかそんなことはないと思うし、6バージョン（3年）ごとにLTSにするってのもたぶんOracleさんが言ってみただけで、いろんなとこがそれに乗っかってるから、実質的に節目になってるに過ぎない。はず。 その程度のものなんだけど、私のようなのは乗っかりますし、たぶん多数派なんじゃないかなぁ……この派閥が運用で使うJavaのバージョンは8、11、17で、他のバージョンは評価に使うくらいでしょう。 11から17のジャンプになるんで、かなりたくさんの変更がありますが、業務アプリケーションの表層に関係するものはそこまで多くありません。パフォーマンスとかに影響のあるものは多々ありますが、基本的には早くなるはずで、問題になることは稀です。稀なことはよくあるんです
「ソースコードブランチ管理のパターン」のダイアグラム - 日々常々
ソースコードブランチ管理のパターン - Martin Fowler's Bliki (ja) お世話になっている人も多い Martin Fowler's Blikiの日本語翻訳サイト 、いつも運営＆翻訳ありがとうございます。 パターン言語は関連が重要な役割を担っています。そして関連はダイアグラムにすると捗ります。ダイアグラムがついている書籍もよくみます。 なので、ダイアグラムがないときや書籍と違う雰囲気のダイアグラムが欲しくなった場合、自分で描きながら読んでたりします。こんな感じで。 紙に手書きすることも多いのですが、インターネットで公開されているものはURLが付けやすいのでSVGで作るのが最近のマイブーム。SVGはサイズが大きくなっても拡大すれば読めるのでいいです。 上の画像はPNGをアップロードしたものなのでGistに上げました。 GistのSVGへのリンクを置いておきます。Gistの
finalを付けるのをやめてみた - 日々常々
Javaの話ね。バージョンは8以降の実質的final（effectively final）があるものとします。7以前は匿名クラス（この呼び方は 匿名クラスとかローカルクラスとか参照）でローカル変数を使うにはfinalが必要なので文脈変わります。 前提の整理 final は色々なところにつけられます。 例えばこんな感じ。 final class FooClass { final Object barField = new Object(); final void bazMethod(final Object quxParameter) { final Object corgeLocalVariable; } } このエントリで対象にするのは変数。フィールド barField 、パラメータ quxParameter、ローカル変数 corgeLocalVariable です。 以下を前提にします
Javaであまりしないコーディング - 日々常々
Java Advent Calendar 2014 - Qiita の9日目です。9日ったら9日です。 なんか難しいエントリが多い中ですが、空気を読まずに軽めでいきます。 Javaでは色々なコードの書き方ができるけど、実際あまりやらないよなーって思うコーディングについて、やらない理由を無理矢理書いてみた。 決して「やってはいけないコーディング」と言う意味ではないです。単に「私はあまりしない」程度で、一般的な（？）業務開発でもあまり見ない、くらいの位置付け。理解した上でやる分には全く問題無いですし、そう言うもんだと思って使っても良いとは思います。 複数変数を同時に宣言する int i, j = 2, k; 同じ型の変数（フィールドでもローカル変数でも）は同じ文で宣言できます。 けど、あまり使ってるのは見ません。 同じ型でしか使えないし、フィールドだとJavaDocコメント書き辛いし、初期化式
Java EEを説明してみる #javaee - 日々常々
これは Java EE Advent Calendar 2014 の2日目です。 Java EE をよくわかっていない私がよくもまぁアドベントカレンダーなんて登録したなーとしみじみ思いながら。 確かアドベントカレンダーに登録したのをきっかけに、なんか調べようと思ってたのですが、 思ったより12月が来るのが速くて無理でした！ そんなこと言っていても仕方ないので、今書けるものを書くとしましょう。そうしましょう。 Java EEってなんぞ Java EEはJavaのEnterpriseEditionのことで、企業向けとかだけど、なんかサーバーとか使うせいか、Webっぽい雰囲気がある物体です。また、Java EEはいくつかのJSRをまとめたJSRのことを指したりもします。 こういうJSRを"アンブレラJSR"と言うとか言わないとか。 JSR(Java Specification Request)は
凝ったコードは凝っているように見えない - 日々常々
新しい技術を使ったり凝ったコードを書くとメンテするのが大変。新しく入ってくる人でも分かるように書く必要がある。 この意見に対する上手い切り返しが出来るようになりたい。— Hidari。 (@Hidari0415) 2012年12月27日 "凝ったコード"……はどうだろう。 コードを書くことに凝るのはいい。でも、出来上がったコードが "凝っている" なんて言われるのはよくない。なぜなら "凝っている" と言われるコードは、おそらく "巧妙なコード" になっているから*1。そう言うのは得てして読みづらくて、凝りを解きほぐさないと理解しづらかったりする。そのようなコードは書くべきではない。コードの可読性から来る理解の容易さが全てじゃないが、他の条件がすべて同じ場合、読みやすいコードを書いた方が良いに決まっている*2。 コードのメンテナンスは書いた瞬間から始まっているし、その場しのぎは長生きするも
職業PGにわかるFizzBuzz - 日々常々
なんかFizzBuzzが書けないPGがどーとか定期的に話題になってるけど、私に言わせれば説明の仕方が悪い。 こうすれば誰でも書ける。 これだから最近の若いもんは……。 GoogleDocsのスプレッドシート、方眼紙作るのに向いてませんね……。
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
