M12i.

学術書・マンガ・アニメ・映画の消費活動とプログラミングについて

Oracle Certified Java Programmer, Gold SE 11取得しました

先日、OCJ-PのJava11対応バージョンの日本語試験が夏前にリリースされていたことに気が付きました。これは少なくとも私の認識している限りではJava8対応バージョンの試験のリリース後の初めての新バージョンの試験であり、Java9で行われた重大な変更であるモジュールシステムの導入やその後加えられたインターフェース定義の拡張などの内容を含むものです。

受験したのは"Upgrade OCJP Java 6, 7 & 8 to Java SE 11 Developer"(1Z0-817)試験です。OCJ-Pの旧バージョン保持者に対してアップグレード機会を提供するものです。私の場合はJava SE 8→Java SE 11ということになります(数年前にJava SE 6→Java SE 8にアップグレードしました)。Oracle社の公式サイトによればその内容は以下の通り:

  • モジュールの理解
    • モジュール型JDK
    • モジュールの宣言とモジュール間のアクセス
    • モジュール型プロジェクトのコンパイルと実行
  • モジュール型アプリケーションにおけるサービス
    • ディレクティブなど、サービスのコンポーネント
    • サービス・タイプの設計。ServiceLoaderを使用したサービスのロード。コンシューマ・モジュールとプロバイダ・モジュールが含まれているサービスの依存関係のチェック
  • Javaのインタフェース
    • メソッドによるインタフェースの作成および使用
    • 関数型インタフェースの定義および記述
  • ストリームに対するラムダ演算
    • map、peekおよびflatMapメソッドを使用したストリーム・データの抽出
    • findFirst、findAny、anyMatch、allMatchおよびnoneMatchメソッドによる検索を使用したストリーム・データの検索
    • オプション・クラスの使用
    • ストリームに対するcount、max、min、averageおよびsum演算を使用した計算の実行
    • ラムダ式を使用したコレクションのソート
    • ストリームに対するCollectorsの使用(groupingByおよびpartitioningBy演算を含む)
  • I/O(基本およびNIO2)
    • Pathインタフェースを使用したファイルおよびディレクトリ・パスの操作
    • Filesクラスを使用したファイルまたはディレクトリのチェック、削除、コピー、移動
    • ファイルに対するストリームAPIの使用
  • モジュール型アプリケーションへの移行
    • 移行用のモジュールにJava SE 8アプリケーションを分割して、SE 9~SE 11より前のバージョンのJavaを使用して開発したアプリケーションを移行する(トップダウン移行とボトムアップ移行を含む)
    • jdepsを使用して依存関係を調べ、循環的な依存関係に対処する方法を識別
  • Local Variable Typeインタフェースの使用
    • 関数型インタフェースの定義および記述
    • ラムダ・パラメータ用のローカル変数とステートメント形式のラムダが含まれているラムダ式の作成および使用
  • ラムダ式の理解
    • ラムダ式の作成および使用
    • ラムダ式とメソッド参照の使用
    • Predicate、Consumer、Function、Supplierなどのコア関数型インタフェースの使用
    • java.util.functionパッケージのベース・インタフェースのバイナリ・バリエーションとプリミティブの使用
  • 並列ストリーム
    • 並列ストリームを使用するコードの開発
    • ストリームで分解と縮小を実装
  • 例外処理とアサーション
    • try-with-resources構造の使用
    • カスタム例外クラスの作成および使用

実際に受験したところの感想としては、(当たり前といえばそうですが)この箇条書きにあるとおりの内容が出題されたように思います。

モジュールについて「トップダウン移行とボトムアップ移行」という聞き慣れない言葉がありますが、私は「トップダウン移行=既存リソースのJARをモジュールシステムの中で運用する、つまりAutomatic ModuleやUnnamed Moduleを利用する」と理解し、「ボトムアップ移行=新規/既存リソースにmodule-info.javaを組込みコンパイル方法も相応の内容にすることでモジュール化する、つまりNamed Moduleを利用する」と理解しました。

清水克行『喧嘩両成敗の誕生』

喧嘩両成敗の誕生 (講談社選書メチエ)

喧嘩両成敗の誕生 (講談社選書メチエ)

中世の「喧嘩」に関する処罰のあり方、それに対する人びとの「もっともだ」「やりすぎだ」「足りていない」といった種々の感想を平易に紹介してくれている点でよし。

ただ「喧嘩両成敗」もしくは「喧嘩両成敗的」措置の結果としての構図に執着しすぎ、紛争当事者双方が厳しく処断されることの、そこに至る意味というか、そうする時の権力者の意図が必ずしも正しく顧みられていないのではないかという印象を受けた。

「両成敗」もしくは「両成敗的」措置には、「平衡」「秩序回復」の意味が込められているケースと、私闘というかたちで検断という本来当事者らに行使を許されていない行為を行い、ときの権力者の権利を侵して秩序を乱したことに対する処罰という意味が込められているケースがあるであろうことは、まま容易に想像がつく。

前者後者の「両成敗」はそもそも処罰の次元を異にしている。前者は紛争当事者やそれを見守る世間一般の思いが権力者の口をして語らせているようなものであり、後者は惣無事令・喧嘩停止令に従わない無法を罰する権力の立場が彼自身の口をして語らせているようなものである。

本書にはそれらを「両成敗」を一緒くた(もしくは一報を無視)している印象を受けた。

ftp通信のputコマンドで553エラー

直近職場で、ftp通信によりファイルをリモートサーバ上にアップロードしてリネームするバッチPGMのエラー事象に悩まされました。

事象はftp通信のputコマンドを実行すると553エラーが発生してしまうというもの。

このエラーコードをキーにしてインターネット上でトラブルシューティング情報を探すと、見つかるのは大概「指定したパスのディレクトリやファイルに対する権限不足」によるエラーのケースです。しかし私が立ち会った事象において権限設定は問題ありませんでした。

あれこれ調べた結果、「バッチPGMがファイルアップロード先を指定する際、ftpプロトコルの仕様に沿ったURLを組み立てられていなかった」が原因とわかりました。

どういうことかというと、ftpでファイルパスを指定する方法にはローカルのファイルシステム同様に相対パス絶対パスの2つが存在し、ftpのURLもこれに応じて異なるかたちになるのですが、バッチPGMはこれを考慮できていなかったのです:

ドメイン名の直後のスラッシュ(/)はあくまでもURLを構成するフラグメントを区切る文字でありファイルシステムのルートを表すものということでしょうか。ルートを表すにはその後ろにURIエンコードされたスラッシュ(%2f)を記載してパスを記述する必要があるのです。

もちろん相対パスftp接続ユーザのホームディレクトリからの相対パス)と絶対パスftp接続したリモートサーバのルートからの絶対パス)とでは指示す先がまったく異なります。指し先が異なれば権限どころか存在すらしないというのが普通でしょう。