先日のJJUG CCC 2023 Fallの懇親会でクソコードを研究しているという学生がいたのだけど、クソコードの研究は難しいという話をした。 人工的にクソコードを再現しても、あの野生のクソコードのクソさには全く足りないわけで。 トルストイが言うように「すべてきれいなコードは互いに似通っているが、クソコードはそれぞれにクソの趣を異にしているものである」なので、なかなか「これがクソコード」のように類型化するのも難しい。 典型的なクソコードを書いてみても、なんだかきれいなクソコードができてしまう。 クソコードはネットに出回らないので、資料の収集もまた難しい。ネットにないということは、ネットの情報に基づいている「AI」もホンモノのクソコードには触れていないことになる。 クソコード収集サイトをつくっても、実際のクソコードは業務固有処理も含まれるので、掲載できる形に整理していくと本来のクソさが薄れて

定期的にオブジェクト指向disを書いてしまってるのだけど。 とりあえずオブジェクト指向の話をすると定義が人によって違いすぎるので、改めてここでの定義を書いておくと 、基本的にはOMTの「データ構造と振る舞いが一体となったオブジェクトの集まりとしてソフトウェアを組織化すること」 に従うのですが 「1990年に流行りソフトウェア開発のすべてを飲み込み、いまとなっては人それぞれ定義が違って技術的議論に使えなくなった、主にオブジェクトを基本単位としてプログラムを整理するやりかたを指すマーケティング用語」 という感じです。 ほとんどの場合で人によってオブジェクト指向の指す範囲が違いすぎて、技術的知見の共有には使えなくなっています。でも、いずれの定義にしろオブジェクトを基本単位にするというのは重要ではないかと。 ソフトウェアの組織化の単位としてオブジェクトを使うというのが大事で、データの搬送に構造体代

某所でオブジェクト指向についていろいろ書いたのでまとめておく。 問題意識としては初学者がなにかというと「オブジェクト指向できるようになりたい」のようなことを言うけどそこまでの優先順位でがんばるものではないんでは、というところです。 まず前提として、オブジェクト指向は1980-2000年くらいに流行って発達したものの、それ以降は時代にあわせた進歩はしていない20年以上前の技術ってのがあります。 そのころは今だとCPUのキャッシュにも満たないようなメモリをやりくりしてプログラムを書く必要があったので、オブジェクト指向はメモリ上のデータをコピーすることなくうまく使いまわせるようなプログラム技術になっています。 そしてオブジェクト指向にはそこから目だった更新はなく、タイトルに書いたように、カメラがやっとついたくらいのガラケーのような古い技術という感じがします。 オブジェクト指向について、アプリケー

プログラムが組めるとプログラムが教えれると思いがちだけど、教えることは別の技術です。 教えてもなかなか理解してくれないとき、プログラミングに向いてないとさえ言う人もいますが、教える側の教える技術の不足です。 教えることも技術のひとつだと気付けば、教えてもなかなか理解してくれないときに技術の不足であるということにも思い至れると思います。技術の不足であると気付けば、改善もしていけます。 そして教える技術というのは、インストラクショナルデザインという名前で系統だてて整理されています。 たとえばそのまま「インストラクショナルデザイン」など、タイトルにインストラクショナルデザインが含まれた書籍もたくさん出ています。 インストラクショナルデザイン―教師のためのルールブック 作者:島宗 理発売日: 2004/11/01メディア: 単行本 他にも、タイトルにはインストラクショナルデザインとついてないけどイ

Javaアプリケーションのインストールパッケージを作れるjpackageが、どうもJDK13に入りそうな勢いでEarly Accessが出てたので試してみます。 jpackageは、JavaFXにあったjpackagerをベースにしたパッケージングツールです。 JEP 343: Packaging Tool EAはこちらからダウンロードできます。開発中のJDK13をベースにしてると書いてありますね。 jpackage ※12/8追記 Java 14でincubatorモジュールとして含まれることになりました。 Windowsで必要なもの Windowsでインストーラーを作るには、iscc.exeが必要で、これはInno Setupに入ってます。 jrsoftware.org // Jordan Russell's Software ※12/8追記 Java 14では不要になったようです あ

PostgreSQLへのJDBCアクセスがあるコードをGraalVMでネイティブイメージ化するとき、org.postgresql.core.v3.ConnectionFactoryImplの対応が必要だったのでメモ たとえばこんな感じでPostgreSQLにアクセスします。 public class Main { public static void main(String[] args) throws SQLException { try (Connection conn = DriverManager.getConnection( "jdbc:postgresql://localhost:5432/mystat", "mystat", "pass"); Statement stmt = conn.createStatement(); ResultSet result = stmt.ex

HelidonはMicroProfileに対応したフレームワークです。 Helidon このあたりで紹介されていますね。 Oracle、Java用のマイクロサービスフレームワーク「Helidon」を発表 - Computerworldニュース：Computerworld HelidonにはシンプルなSEとMicroProfile対応のMPがあります。Maven Archetypeが用意されているので、こちらを使うと楽です。 SEだと関数を登録する感じで、MPだとJAX-RSやCDIを使ったアノテーションベースのコードになります。 ちょっと試すにはSE、大きめのプロジェクトを作る場合はMPがよさげ。 面白いのは、Dockerfileが用意されているので、ビルドしてそのままDockerイメージが作れるところです。 FROM openjdk:8-jre-alpine RUN mkdir /app

先月末でJDK11はRampdownフェーズに入って、機能凍結されました。 なので、今後はAPIの追加・削除・変更はほとんどないと思われます。 おそらく、機能的には現在でているea20とほとんど同じものがJava11としてリリースされることになると思います。 JDK 11 Early-Access Builds 大きな機能変更としては、ここでJEPとしてまとまっています。 「JDK 11」 http://openjdk.java.net/projects/jdk/11/ Raw String Literalが間に合わなかったのはとても残念です。JDK11トレインに乗り遅れるからがんばるぞ！みたいな投稿があって仕様をまとめてからML上は音沙汰なしですが、Rampdownフェーズが始まってから機能追加するLate Enhancement Request Processというのがあるようなので、

Java9からJDK11-ea18まで、三項演算子でのunboxingの挙動がJava8とは変わっているようです。 Double d = false ? 1.0 : new HashMap <String, Double>() .get("1"); yields null in #Java8, but NullPointerException in #Java10. Why?https://t.co/MUaql1vd9e— Nicolai Parlog (@nipafx) 2018年6月10日 次のようなコードの挙動がJava8でコンパイルしたときとJava9以降でコンパイルしたときとで変わっています。 Double d = false ? 1.0 : new HashMap<String, Double>().get("a"); 試しに次のようなコードを実行してみます。 import j

Java8のlambda構文の話を書くと、旧来の書き方でいいというコメントがつくのですが、それでも便利になったMapの恩恵を受けることは多いんじゃないかと思います。 ※ 2018/5/31 Java9からはメモ化再帰には使えなくなっています ※ 2019/2/15 なんか問題ない？ Mapには、lambda式を使ったメソッドが多く追加されていますが、たとえばgetOrDefaultメソッドのようなlambda式を使わないメソッドも追加されていて、これも便利です。 そして、このようなlambda式を使わないメソッドも、間接的にはlambda構文サポートでの言語拡張のおかげです。 Mapはインタフェースなので、Java7までの構文でメソッドを追加しようとすると、Mapを実装しているすべてのクラスに新しいメソッドの実装を追加する必要がありました。そしてそれは現実的に不可能なので、今までMapなど

Java 10でvarが追加されました。が、いろいろ使い方は悩ましい気がします。 いろいろ議論をしたので、そこで考えたことをまとめておきます。 JShellでは読むことを考えなくていいのでガンガン使いましょう。 あと、OpenJDKのStyle Guidelinesも見ておくとよさげ。 Style Guidelines for Local Variable Type Inference in Java ローカルメソッドの定義にvarを使う 通常の変数定義でのvarの使い分けは長くなりそうなので、最初にこれだけ書いておきます。 いままで、メソッド内で使えるローカルメソッドを使おうと思うと、Functional Interfaceを使うくらいしかありませんでした。 Function<Integer, Integer> twice = x -> x * 2; println(twice.appl

JDK9でincubatedでJDK10でもincubatedなHTTP Clientが、ようやくJDK11でjava.net.httpパッケージで入るらしい。 JDK HTTP Client - JEP 321 - Update あと、 1.2からDeplicatedだったrunFinalizersOnExitメソッドが削除される。Runtime.runFinalizersOnExitとSystem.runFinalizersOnExit。 (11) RFR JDK-8198249: Remove deprecated Runtime::runFinalizersOnExit and System::runFinalizersOnExit Java 9でforRemoval=trueになってますね。 https://docs.oracle.com/javase/jp/9/docs/api

9月の頭くらいに、Javaのリリースモデルが6ヶ月ごとの短期リリースになるということが発表されてました。 で、「へぇ〜」みたいな感じで見てたのですけど、JavaOneでの話を聞くと、これ結構大変なのかも、ということになってそうなので、ちょっとまとめてみます。 追記：2018年05月の状況をQiitaでまとめています。 [Javaのサポートについてのまとめ2018 - Qiita](https://qiita.com/nowokay/items/edb5c5df4dbfc4a99ffb) Javaの新しいリリースモデル 公式情報はこちらにまとめられています。(10/4にアップデートされてます) http://www.oracle.com/technetwork/jp/java/eol-135779-ja.html ざっくり言えば、6ヶ月ごとに機能リリースを行い、3ヶ月ごとにメンテナンス/セキ

前回、簡単なDIコンテナを作ってみたので、次はこれを使ってWebフレームワークを作ってみたいと思います。 Webサーバーをつくる まず、WebフレームワークなのでHTTPサーバーが必要ですね。なので簡単なものを作ります。 とりあえずブラウザからリクエストを受け取ったら200 OKとHTMLを返すだけのサーバーです。 今回は、そこらのブラウザからアクセスできればいいや、ということで、RFCとかの仕様に準拠することは考えません。 public class Server { public static void main(String[] args) throws IOException { ServerSocket serverSoc = new ServerSocket(8989); for (;;) { Socket s = serverSoc.accept(); new Thread((

DIコンテナ使ってるけど、アノテーションってなんなの！って聞かれて、作ってみたらわかるよと答えてみたので、自分でも作ってみました。 よくわかった。 「DIコンテナ使うと何がいいの？」ということも、作ってみるとわかります。あと「DIって何がいいの？」に関しては、「DIはちょっとコードを書くのが楽になるだけで、それだけあっても仕方ない、大事なのはコンテナ」と答えるようにしてますが、コード比率からもそれがよくわかります。 続編としてWebフレームワークも作っているので参考まで。 作って理解するWebフレームワーク - きしだのHatena まずはコンテナを作る とりあえず1ソースの状態で。 こんな感じで、管理する型を登録できるようにします。 static Map<String, Class> types = new HashMap<>(); static void register(String

Java Day Tokyo 2015で、NECのJava SEバージョンアップでのトラブルの話が面白かった。 Java EEアプリケーションサーバの開発現場で見たJava SEの実際 資料はこちらで公開されてるので、資料に書かれてることはそちら参照という感じで、どんな話だったか書いてみます。 Java Day Tokyo 2015 アプリケーションサーバーを提供する中でJava SEをバージョンアップしたときに出て来たさまざまなトラブルの話と、Java SE 8から導入されたMetaspaceの話が主でした。 Java EEは機能が標準化されているので、アプリケーションサーバーはカスタマーサポートで差別化をはかるしかない、顧客から見ると、Java SEやOSまで全て含めてアプリケーションサーバーなので、全部対応していく、という話をされていました。 Javaにもそれなりにバグはあって、アプ

最近会った人とよく話すのが、ソフトウェアプロセス技術がロストテクノロジーになってるんではないかということです。 ソフトウェアプロセスというのは、「プロセスがよいソフトウェアをつくる」という前提のもと、どのようなタイミングでどのような成果物を作り、どのような管理をし、どのように検査をしてソフトウェアを作るかという手順です。 そして、プロセス技術というのは、そのようなプロセスを構築し運用し改善する技術です。 このようなソフトウェアプロセス技術は、1995年くらいから2000年くらいにかけて盛り上がり広まりかけたのですが、そのタイミングでWebが広まりはじめ、「Webは進化が速い」「作るものがどんどん変わる」などを合言葉に、「アジャイルプロセスを採用する」という名目でなんら管理されないプロセスが普及しました。その結果、プロセス技術は完全に下火になっているように思います。 もちろん、Webの発展段

プログラムがまだ不慣れな人が「プログラムちょっとわかるようになったけど、まだぜんぜんオブジェクト指向とかできてません」のように言ったり、ちょっと慣れた人が「このソース、ぜんぜんだめ。オブジェクト指向ができてない」にようなことを言ったり、まるで、オブジェクト指向ができてるかどうかがよいプログラムかどうかを表すことになってるようだ。 Javaのアルゴリズムの本に、「Javaなのにオブジェクト指向ができていない」のような書評がついているのを見たときには、お前は何を求めてるんだと思ったりもした。 そのようなオブジェクト指向は、窓から投げ捨てるべきだ。オブジェクト指向はプログラムのよしあしの基準にならない。 むだにHogeインタフェースとHogeImplクラスがあったり、むだにnewするだけのcreateメソッドがあったり、どこで値が設定されてるかわからないオブジェクトがひきまわされてたり、ソースコ

用語は形式的なものではなく感覚的なものであることをお断りしておきます。 言語・フレームワーク・プラットフォーム まず最初に触れるものでとっつきやすい。何か使えないことには話になりません。多くの人が、勉強というとまずここ。 何かすでにつかえる人が新しく勉強することは、生産性をあげない。そのプラットフォームを初めて採用するときの準備が減らせる。どちらかというと仕事の選択肢を増やす感じですね。 深く知ることは、最適なコードを書きトラブルを減らしトラブルが起こったときの対策も早くなるので、生産性があがります。ただ、ある程度の深さ以降は生産性への寄与度がさがるので、その点では深くまで勉強する必要はありません。 プロダクトの使い方なので、プロダクトの寿命が勉強成果の寿命です。実際に使わないものの勉強は無駄になるし、使われなくなったら無駄になる。寿命もそう長くないです。 「プログラマは勉強してもすぐ使わ

前回のエントリで、プログラマの業界が労働集約的なものと知識集約的なものにわかれてきているという話を書きました。 プログラマ業界の二分化 - きしだのはてな 前のエントリでは労働集約的なものと知識集約的なものに完全にわかれているように書きましたが、もちろん完全に労働集約的であったり完全に知識集約的であったりすることは少なく、どのような組織でもある程度は両方の性質をもっています。知識集約的な性質の強いSI会社というのもあります。 ただ、SIに労働集約的な、サービスに知識集約的な性質が強くなる傾向はあると思います。 また、知識集約的であればよくて労働集約的であればダメということもありません。労働集約的なSIでありながら良い会社というのもあります。 という断りをいれておかないと、SIで労働集約だからといって全部ひとからげにするなという、労働集約的なSIでありながら良い会社方面から鋭利なマサカリが飛