Pixel 3 XLを購入しました
これまで 10 年以上スマートフォンとしては iPhone を使っていました。日本に最初に上陸したバージョンである 3G からです。3G→4→5c→7 と使い続けていたのですが、この度遂に iPhone やめて Google の純正ブランドである Pixel 3 XL に機種変しちゃいました。
長年連れ添った iPhone に別れを告げて、Android の参照実装機とも言える Pixel に乗り換えたのは次のような理由です。
無印か XL かはちょっと迷ったのですが、実機を触ってみて、XL でも辛うじて片手でも扱えるぎりぎりの大きさに絞られており、個人的にもファブレットを使いたかった(スマートフォンとタブレットを統一したかった)ので、XL を選択しました。
良かった点
- 最近のスマートフォン界で流行のナローベゼルのお陰で、片手で使えるファブレットになっている
- 最新の Android の機能が使える
- 自分が今まで使ったことがある Android 機は Huawei のタブレットだったのですが、メーカーが色々手を入れまくっていたので古い Android のままでした
- こちらは Google 純正機なので最新のアップデートがやってくることが保証されます
- 仕事場でも GSuite を使い、家でも GMail を使っているし、ブラウザは Chrome だしと、何だかんだで Google のサービスへの依存度が高いので、シームレスにそれらのサービスへアクセスできる Android の方が iOS よりも有利でした
- 一番面白かったのが Google アシスタントによる画像検索機能で、次のように写真に写っている動植物や物品が何であるかを調べてくれたりします
- カメラが暗所に強い
- これはメディアでもよく話題にされていたので知ってる人も多いと思いますが、Google の AI 技術による補正で、暗いところでも中々くっきりとした写真を撮ってくれます
- iPhone からの移行が楽だった
- 移行はちょっと大変になるかな? と思ったのですが、セットアップ時に次のようにケーブルでつなぐだけで iPhone 内の住所力や MMS メッセージ、写真、音楽などのデータをまるっと移してくれました!
- ソフトウェアについても Play ストアに同じものがあるときはそれをダウンロードできるようにリストアップしてくれます
- 壁紙設定まで移行されたのには驚きました
- なお、このセットアップを行うに当たっては注意点があるので、それは後述します
- 背面指紋認証は意外と使い易い
イマイチな点
- Google Pay はまだまだ発展途上
- 自分の手に馴染ませるには色々設定が必要
- メッセージアプリはいわゆるガラケーメール向きではない
- 登録した連絡先から送信する場合は電話番号の選択のみで、メールアドレスの場合は直打ちが必要です
- SoftBank が別途専用アプリを入れてくれているのでそれを使いましょう
- そこまで爆速ではない
注意点
最初のセットアップで、iPhone からの移行はケーブルでつなぐだけで OK と上に書きましたが、実際には iPhone 側で事前に次のような準備が必要です (この点は紙のセットアップガイドには書いておらず、Web を見る必要があるんだな、これが) 。
- バックアップの暗号化を解除する
- これを解除しないとほとんどのデータを転送できません
- デフォルトで暗号化設定になっているので、ほとんどの人は解除が必要です
- iMessage、FaceTime を「使用しない」という設定に変更する
- これをしないと MMS が iMessage に紐づけられたままになり、MMS が全部そっちに転送されてしまいます
Java 11ではPublic JREが本当になくなりました
Java 11 の登場で Java を取り巻く環境は様々な転換点を迎えることになりました。散々言われている Oracle からのリリース方法の変更の話もありますが、もう1つ、Public JRE の消滅があります。
実際に JDK11 をインストールして色々変化があったので、このエントリではその情報を共有したいと思います。と言っても Twitter ではこの件に関して頻繁につぶやいていたので、それを引用しながらの内容になります。
そもそも Public JRE って何?
一言で言うと「 あなたとJAVA, 今すぐダウンロード 」からダウンロードしてインストールするソフトウェアのことですw
JDK と異なり、Java アプリケーションの実行に必要なモジュールだけを OS のシステムレベルでインストールします。開発者ではなくエンドユーザー向けのソフトウェアです。次のような役割を担います。
- Executable JAR ファイルの実行
- ブラウザ Java Plug-in 経由で起動される Java Applet、Java Web Start アプリケーションの実行
- デスクトップ上での Java Web Start アプリケーションの実行
JDK11 でどう変わったか
そして、Java 11 ではこれが無くなりました。Oracle JDK 11 をインストールしたときのつぶやきを引用します。
続いてMac。こちらはインストールウィザードは今まで通り。けれどもこちらはコマンドラインでは11にスイッチされる。/usr/libexec/java_homeが返すパスが11に変わる。けど、public JREは入っておらず、public JREのディレクトリのjavaコマンドは前のバージョンを返す。Javaコンパネも10のまま。 pic.twitter.com/tqcEW7HKc8
— AOE Takashi (@aoetk) 2018年9月26日
こんな感じで本当に Public JRE のインストールがなくなりました。しかし、この時点では前のバージョンは残っており、今後 Public JRE の無償サポート (Java 8 の JRE については個人向けに対しては 2020 年までサポートを継続) が終了したときにはどうするのかという疑問点が残っていました。
Java 定期アップデート時の JRE 10 の扱い
その答えは先日の定期アップデートの時に判明しました。Public JRE をインストールしている場合、自動でアップデートチェックが走り、更新があった場合はインストールダイアログが表示されます。今回の場合、自分のマシン環境には Java 10 の Public JRE しか入っていませんでした。これは Java 11 のリリースと共に無償サポートは終了しました。
以下、そのときのつぶやきを引用します。
Public JREとしてバージョン10を入れている場合、今回のJavaの自動アップデートで10の無償アップデート期限終了に伴い、JREをクリーンアップするようになるな。スクリーンショットはWindowsだけどMacでも同じことが起きた。 pic.twitter.com/RyMTPfuZHr
— AOE Takashi (@aoetk) 2018年10月20日
そうです、自動アップデートのタイミングで無償サポート対象外の JRE のインストールを検出した場合はそれをクリーンアップするように促されます。このようにして古い JRE が放置されないようにちゃんと考えていたのですね。
てなわけで私の環境からはPublic JREが消えました。Executable JARファイルをExplorer上でダブルクリックしても何も起きないようになりました。 pic.twitter.com/aGomxWMxa5
— AOE Takashi (@aoetk) 2018年10月20日
こうして私の環境では JAR をダブルクリックしても何も起きなくなり、当然のことながら Java Applet は実行できなくなりました。
今後の Java アプリケーションの配布はどうするのか?
このようにして、システムレベルでインストールする JRE は今後無くなっていきます。では、どうやって Java アプリケーションをエンドユーザーに届けるのかというと、アプリケーション開発者が JRE と共にアプリケーションを配布することになります。
Java 9 からは配布用の JRE を生成するための jlink というツールが付属しています。アプリケーション側がちゃんとモジュラー化していれば、アプリケーションの実行に必要なモジュールだけを含んだ JRE を生成することができます。今後はこれを利用しましょう。
ただこの jlink、コマンドライン起動を想定していて、起動はシェルスクリプト (Windows 向けには bat ファイル) の形になっており、GUI アプリケーション向きではありません。そのためには javapackager と言うツールがあったのですが (過去の私の このエントリ や このエントリ で取り扱っています) 、このツールは JavaFX に付属していたものであり、 Java 11 で JavaFX が切り離された ため、JDK から無くなってしまいました。
そこで、OpenJDK では JDK 向けに javapackager 相当のものを作ろうという JEP が起案されました。
http://openjdk.java.net/jeps/343
名前は jpackager にするつもりみたいです。早く出てきて欲しいですね。
JavaFXの非矩形ウィンドウにおけるWindowsとMacでのマウスイベントの違い
しばらく blog を書いていなかったので先日気がついた小ネタでも書きます。
かなり昔に JavaFX で xeyes のクローンを作ってみた話 を書いたことがあったのですが、最近あれをイチから作り直してみました。コードも GitHub にアップしています。 *1
以前のブログエントリからは次のようにかなり作りが変わっています。
- 以前は Mac 上で Swing の EDT を実行すると HeadlessException が飛ぶ問題があり、仕方なく Swing を土台として作っていたのですが、現在はこの問題は解消されているので、JavaFX を土台としたものに変更しています。
- マウスカーソルの座標を取得するタイミングを以前は Swing の Timer で起こしていたのですが、これを JavaFX の AnimationTimer を利用するように変更し、より滑らかに目玉が動くようになっています。
- Stage のスタイルを StageStyle.TRANSPARENT に変更し、本家 xeyes のように背景を透過するようにしました。
最後のポイントに書いたように、Stage のスタイルを StageStyle.TRANSPARENT
に変更したため、ウィンドウのタイトルバーやウィンドウ枠がなくなるため、ウィンドウの移動やリサイズを自力で実装する必要があります。
その際に気が付いたことがありました。リサイズや移動が可能であることをが分かるように、アプリケーション上でのマウスカーソルの位置によってマウスカーソルの形状を変えるようにしました。ところが Windows 上で動かした場合と Mac 上で動かした場合に次のような違いが見られたのです。
- Mac 上で動かした場合、マウスカーソルが (透明になっている) ウィンドウの端や隅に到達してもちゃんとカーソル形状が変わる。
- Windows 上で動かした場合、「目」の上でしかマウスカーソルの形状が変更しない。
- と言うか、マウスイベントが全て「目」の上でしか発生しない。
この動きの違いに悩んで色々調べてみたのですが、どうも JavaFX 側の考え方としては Windows 版の動きが正 のようです。Mac 版の動きについて次のようなバグチケットが作られていました。
https://bugs.openjdk.java.net/browse/JDK-8088104
まあ考えてみれば理屈は分かります。非矩形に作ったのにマウスが矩形に沿って反応するのは確かに不自然です。自分が作ったこの xeyes については Windows 版ではウィンドウの四隅からリサイズが行えないという不便な点がありますが、縦方向と横方向のリサイズは可能なので、まあこれでいっかーとそのままにしましたw
というわけで小ネタでした。
Java Client Roadmap Updateによせて (後編)
というわけで先日アップした次のエントリの後編です。
前回は年寄りの思い出話という感じでしたがまさかの大きな反響を頂いて驚いています。後編については JavaFX や Swing、そしてクロスプラットフォーム GUI の今後について思うところを書いていきたいと思います。
JavaFX は今後どうなる?
今回の決定で JavaFX は JDK リリースから分離されることになったわけですが、逆に言うと JDK のリリースサイクルに縛られること無く開発を進められることになります。そして、私の感覚からすると、当面 JavaFX が廃れるような心配はしなくていいと見ています。
JavaFX は Java EE と同様によりオープンソースコミュニティに今後の開発をゆだねることになりましたが、JavaFX のコミュニティは今でもとても盛り上がっています。OpenJFX の ML では今でも盛んに議論がされていますし、先のホワイトペーパーでも「情熱的なコミュニティ」であると賞賛しています。
実は今回の発表の少し前に OpenJFX のリーダーである Kevin Rushforth 氏から OpenJFX コミュニティの今後の方向性について問いかけがありました。
http://mail.openjdk.java.net/pipermail/openjfx-dev/2018-February/021335.html
この議論では大変な盛り上がりを見せ、より外部の人が入りやすくなるような雰囲気にしようという方向になりました。その一環として GitHub に OpenJFX のリポジトリのミラーも作られ、PR を受け付けられるようにしています (OCA へのサインは必要です) 。
このように、JDK のリリースサイクルに縛られず、より外部も参加しやすくなることで、かえって開発のスピードが上がる可能性もあると考えています。前編でも述べたように海外では結構採用事例があり、Gluon のように JavaFX をビジネスのメインにしている会社もあります *1 。
と言うわけで、Java の標準 GUI では無くなりましたが、優秀なライブラリとしてあり続けるだろうと思っています。前編でも述べましたが、とても開発しやすい API ですし、Java で GUI を作るときの最有力候補であることは変わらないと思っています。コミュニティとの連携も取りやすくなる方向になっていますし、業務で JavaFX を採用したところがあってもそんなに心配しなくてもいいと思います。
私自身はここ数年フロントエンドとは余り縁の無い仕事をしている事もあり、業務で JavaFX を触る機会は無かったのですが、自分の身の回りでで GUI を使った道具が必要な時は JavaFX で作っていました。今後もそのためには JavaFX を使い続けると思っています。
Swing について
紆余曲折を経て、Java のデフォルト GUI は Swing に戻った感があるのですが、前編でも述べたように OpenJDK では再び Swing に力が入りそうな雰囲気になっています。Swing に JavaFX の良いところ (FXML とかバインディングとか) が移植されるような流れにならないかなあ。
私は Swing は一定の成功を収めたと思っています。何より Swing が覇権を握っている分野があります。それは IDE です。NetBeans と JetBrains の IDE だけじゃないかと突っ込まれそうですが、特に JetBrains IDE のここ最近の躍進ぷりはすごいです。JavaScript、Python、PHP、Ruby、Go など実に様々な言語コミュニティで人気を博しています。
クロスプラットフォーム GUI の今後
今回の件でクロスプラットフォーム GUI というのはやっぱり難しいものだなとは思いました。でも需要があるのは確かです。ゲームエンジンの様にユースケースをより絞ったものは普及していますしね。
汎用的なクロスプラットフォーム GUI で一番成功しているのはやはり Qt でしょうか。モバイルへの進出にも成功していますし。開発言語は C++ ですが、他のプログラミング言語へのバインディング も多いです。ですが、Java バインディングである Jambi が死んでしまったんですよね...。 *2
後は有力候補としてはやはり Electron なんですかねえ。私は好きじゃないんですよ。ぶっちゃけ Chrome ブラウザそのものなので、Electron アプリを 1 つ立ち上げると (潤沢にリソースを使う) Chrome ブラウザが余計に 1 つ立ち上がるようなものなので、使う側としてそんなに好きじゃないんです。Web 開発の難しさをデスクトップ GUI アプリ開発に持ち込みますし、そんなに JavaScript + CSS で開発したいですか?と言いたい感じです。まあ古典的なスタイルの GUI 開発が好きな人間としては、WebComponents に期待しているところです。
モバイル OS 戦争に敗れ去った MS は Xamarin に力を入れていますし、最近は Flutter なんてのも登場しましたし、今後もクロスプラットフォーム GUI へのトライアルは色々な形で出てくるでしょうね、というところで雑感垂れ流しのエントリを締めくりりたいと思います。
Java Client Roadmap Updateによせて (前編)
既にご存知の方も多いと思いますが、先日 Oracle から JavaFX をはじめとする、Java のクライアントテクノロジーについて今後のロードマップが発表されました。
上記ブログエントリでは主に JavaFX の今後の扱いについて述べていますが、以下のホワイトペーパーにはそのほかに Applet や Java Web Start、そして Swing/AWT といった Java のクライアントテクノロジー全般の今後のロードマップについて記載されています。
http://www.oracle.com/technetwork/java/javase/javaclientroadmapupdate2018mar-4414431.pdf
このホワイトペーパーを読んで、まあ色々思うことがありました。Java のクライアントテクノロジーについての過去も振り返りながら私が感じたことを色々語りたくなったので、このエントリを書きました。まあ巷で言う「ポエム」ってやつですね。
長くなったので前後編に分けて書くことにしました。
ホワイトペーパーに書かれていたこと
ホワイトペーパーに記載されていた内容を簡単にまとめると次の通りです。
- Oracle Java SE 11 からは JavaFX を同梱しないことを確定
- Applet のサポートは予告通り Java SE 8 までで、Java SE 11 には含まれなくなる
- Java Web Start についても Java SE 11 以降には含まないことを明言
- これは今回の発表で初めて明らかになったこと
- Swing と AWT については Java SE 11 においても開発を継続する
JavaFX については後ほど述べるとして、注目してもらいたいことは Applet、Web Start の扱いです。 これらに対する実行環境のアップデートが提供され続けるのは Java SE 8 のサポート期間の間だけ ということです。
よって、特に Applet を使った業務システムを展開しているところは Java SE 8 の無償アップデート提供期間中に対応を検討する必要があります。特にブラウザ Java Plug-in 部分はクライアント PC のセキュリティに直結するため、アップデートせずに放置するという選択肢は危険です。対応策としては次のようになります。
- Oracleの商用サポートを契約し、継続して実行環境のアップデートを受け取る
- アプリケーションを改修し、ブラウザ上で動かすのではなく、JRE を同梱したスタントアロンアプリケーションとしての配布に切り替える
- Oracle もホワイトペーパーで推奨している対応です
- 既に JDK にはそのための javapackeger というツールが同梱されている ので、これを活用しましょう
というわけで、このロードマップ発表で Java のクライアントテクノロジーは転換点を迎えることになりました。これまでの経緯をちょっと振り返ってみようかなと思います。
Java クライアントテクノロジーの変遷について振り返り
Java 誕生時の GUI
Java は誕生時から AWT という GUI ツールキットを同梱していました。Java の主な目的の1つに Web ブラウザ上で GUI アプリケーションを動かせるようにすることがあったからです。
AWT は画面に描画する GUI 要素は Windows や Mac といった実行環境のコントロールを使っていました。それに対して抽象化層を提供するものであったため、用意された GUI 要素は最大公約数的なものでした。そこで、AWT をベースに、Java2D を使用して全ての GUI 要素を自分で描画するSwing というツールキットが登場します。これは当時 Netscape 社が独自に開発したものに Sun が目を付けて共同開発したものです。
Swing はどの OS でも動く GUI を構築できるということで非常に画期的でしたが、如何せん登場時期が早すぎました (20世紀のことです) 。当時のクライアント PC のスペックでは動作が重すぎました。私は MMX Pentium 166MHz のマシンで初めて Swing を動かしたのですが、全ての動きがスローモーションで笑っちゃうしかなかったのを覚えています。
ですがこれにめげることなく継続的にアップデートを続け、JDK1.4 あたりでようやく実用的な速度が出るようになり、この頃から業務アプリケーション向けクライアント開発をはじめ、そこそこ採用されるようになってきた印象があります。私もこの時期に Swing での開発を経験しています。
Swing の発展
そして Java 5 から 6 に掛けた辺りで、当時既に普及していた Web アプリケーションに対して、当時の HTML の表現力の限界からリッチクライアントが再び見直される流れが出てきます。特に Macromedia (現在は Adobe に吸収) が Flash を業務クライアントとして推すことに熱心で、ここから Flex が誕生します。その流れを受け、Java SE 6 の頃に Sun は Swing 関連の技術に大きなてこ入れを行います。
- Java.net にデスクトップ専用のプロジェクトができる
- Java Plug-in の強化
- デスクトップ環境と連携する API の追加
- Swing 開発のためのアプリケーションフレームワークプロジェクトとその関連技術の開発が始まる
RIA の潮流と JavaFX の登場
この頃が Swing の全盛期だったかなあと思っています。そして大体同じ頃に別の流れが出てきました。それがコンシューマ向け Web を対象とした RIA の流れです。Microsoft が Silverlight をリリースした辺りから Flash と共に次のような特徴を備えたものとして注目され始めました。
もちろん Java にも Applet や Web Start という同様の技術がありました。Swing も GUI 要素を自分で描画する仕組みになっているため、頑張ればどんな見た目にすることもできます。しかし、デザイナが扱うのには向いていないプラットフォームでした。
そこで Sun が目を付けたのが、Sun が買収した企業である SeeBeyond に所属していた Christopher Oliver 氏が開発していた Form Follows Function (F3) というプロジェクトでした。 これは確か Swing を開発しやすくするための DSL だったと思います。 (さくらばさんより指摘があり、これは正しくないとのことでした。F3 は Flash + ActionScript な DSL を目指したもので、たまたま実行の土台として Swing を使っていたとのことです。) Sun はこの技術をベースに JavaFX というプロジェクトを立ち上げ、次のような特徴を備えたコンシューマ向け GUI 開発、実行環境としてデビューさせます。
- デスクトップ、スマートフォン、TV など様々な機器を対象
- JavaFX Script という GUI 構築のための DSL の採用
- CSS によるスタイリングの分離
- Adobe Illustrator や Photoshop に対してプラグインを提供し、デザイナが GUI 要素をデザイン可能
最初は Swing のラッパーコンポーネントという印象もあった JavaFX ですが、Sun はこれを AWT に頼らない GUI ツールキットとして発展させます。Prism エンジンを開発して GPU を積極的に活用する新世代の Java GUI ツールキットになっていきました。この頃から Sun は Swing への投資を急速にトーンダウンさせ、先ほど挙げた Swing App Framework 関連の JSR は中止してしまいました。これは当時 Swing 開発者からの反発もかなり大きかったことを覚えています。
ともかく Sun は JavaFX をすごくアピールしていました。Sun の開催するカンファレンスでは JavaFX を使った流麗なインターフェースをよくデモしていました。ですが、最も JavaFX を浸透させたかったスマートフォンへの展開を失敗してしまいます。旧 Windows Mobile に提供したのみで、水面下で Android への採用も持ちかけていたという話を聞いたこともあるのですが、現実はそうでないことは皆さんのよく知るところです。
そして Oracle による Sun 買収というイベントが起きます。
Oracle の買収と JavaFX の方向転換、発展
Oracle の買収で JavaFX がどうなるか不安視されましたが、JavaFX は引き続き盛り上げていくことを宣言します。ですが、Oracle は JavaFX をコンシューマ向け開発では無く、あくまで業務向け開発のツールにすることを重視しました。...とは Oracle ははっきり言っていませんが、その後の動きや Oracle のビジネス領域から考えれば明白でした。
JavaFX 2.0 において、JavaFX Script を廃止することが決まりました。そして、Java + FXML で開発するというスタイルに変わります。当然のことながらこれは大騒ぎになりました。 *1
ですが、結果としてこれは JavaFX にはプラスとなりました。本来の Java 開発者層が JavaFX に関心を持ち、注目度がぐっと上がりました (そのかわり Web デザイナ層は離れていきましたが...) 。古くささが見えてきた Swing と比べ、次のような点が優れていました。
- FXML による GUI 構造の分離
- プロパティとバインディング API によるリアクティブなスタイルでのビュー更新
- これは遅延実行の仕組みを備えるなど、他のプラットフォームと比べても優れていました
- Lambda Ready
私が JavaFX を本格的に触りだしたのもやはりこの時期でした。Flex による RIA 開発経験をしたこともあり、ユーザーに様々な UX を提供可能な RIA の可能性に目を向けていたところ、Java で開発可能な RIA プラットフォームが登場したので注目をしたのです。Flex と比べて優れているところも多いと評価していました。
2013 年の Java Day Tokyo の Java the Night に登壇したとき はこんなツールをデモして、JavaFX の魅力をアピールしたりしてました。
Oracle は積極的に JavaFX の開発を進め、JavaFX 8 までは盛んに機能追加も行い、今後 Java の標準 GUI は JavaFX になると宣言しました。JavaOne で iOS、Android デバイスでの稼働をデモしたりと、Oracle は本気だと私もすごく期待していました。
主に欧州を中心に業務系システムやトレーディングツールなどでの採用例が出てくるようになります。NASA など科学技術研究の現場での採用も多かったように思います。 Eclipse GEF も最新版では JavaFX ベースになっています。
そして Oracle の方向転換
ですが、JavaFX 8 のリリースがピークでした。JavaFX 8 リリースの後辺りから次のように徐々に暗雲が垂れ込んできました
- iOS、Android への搭載の話はトーンダウンし、OpenJFX でソースだけ公開してお茶を濁す
- 肝心の JVM 部分の公開がなかった
- Raspberry Pi での実行にも積極的になったかと思えば、1 年後にはトーンダウン
- Scene Builder も 2.0 リリースを最後にメンテナンスモードに
- 現在は Gluon がメンテナンスを継続 しています
Java 9 では Jigsaw 対応で手一杯で新機能の追加はほとんどなく、明らかにリソースを絞っているように見えました。そして今回の発表につながります。
ホワイトペーパーを見る限り、Oracle は Java のクライアントテクノロジーに対する興味がほとんど無いことが分かります。現在は Web ファースト、モバイルファーストの流れであると結論付けています。まあ Oracle の立ち位置的にここまで見てくれたのが奇跡的ですらあったのかも知れませんが。
なお OpenJDK コミュニティは AWT、Swing、Java2D の強化に積極的で、そういう意味では様々な紆余曲折を経て Java 標準 GUI の座は再び Swing に戻ってきたのかも知れません。
と言うわけで Java のクライアントテクノロジーの歴史を振り返ったところで前編終了。長くなりすぎて疲れましたw 後編では JavaFX 、そしてクロスプラットフォーム GUI の今後について思うところを書こうかなと思っています。
*1:当時のさくらばさんの怒り様はまあすごかったです (^^;;
Asakusa Direct I/O formatted textの紹介
はじめに
このエントリは Asakusa Framework Advent Calendar 2017 の20日目のエントリです。実は 2 年ぶりくらいにお仕事で Asakusa Framework を使った開発をしているので、今年は参加することにしました。
Asakusa Framework は 6 年前の初期リリースから継続して機能の追加を積極的に行っています。先ほど 2 年ぶりに Asakusa で開発していると書きましたが、その間にも色々進化していて、確実に便利になっていると感じました。
今回はその中の Direct I/O formatted text について紹介したいと思います。これはバージョン 0.9.1 になって追加された、かなり新しい機能です。
Direct I/O は HDFS や AWS S3、GCS といった分散ファイルシステム上に保存されたファイルを透過的に読み書きする機能ですが、これまで次のようなファイルの種類に応じてデータモデルへのマッピングを行う機能が用意されていました。
- Direct I/O CSV
- Direct I/O TSV
- Direct I/O line
DirectI/O formatted text はこれまでファイルの種類に応じて別々の API を用いていたところに統一的な機能を提供し、さらに機能追加も行われた強力なライブラリになっています。次のような強みがあります。
- より多様なデータ形式に対応できる
- 不整合データに対して柔軟な操作設定ができる
- 読み込み時にファイルについてのメタ情報を入れられる
詳細についてはドキュメントをじっくり読んでもらうとして、ここでは個人的に嬉しかった点を挙げていきたいと思います。
嬉しかった点その1
「きちんとしていないデータに対してかなり無理が利く」という点です。
例えば、複数のシステム間で連携をするとします。各システムにサービスインターフェースが用意されていればいいですが、そうも行かず、いわゆるファイル連携をすることも多いと思います。
このファイル連携、とにかく泥臭い対応が必要になることが多いですよね。連携先の各システムに「CSV ファイルで連携しましょう」って声を掛けても次のように綺麗なデータが来るとは限らないことが多かったりしますよね。
- 改行コード、エンコーディングがばらばら
- 同じデータに対応したものなのにヘッダがあったりなかったり
- 固定長ファイルを単純に CSV 化したのか、各項目が空白埋めでご丁寧に桁を揃えられているとか
- 行によってカラム数が異なる CSV 的なものが出てくるとか
- 本体のデータ部分以外に見出しや合計行なんかも 1 つのファイルに混じっている例を見たことがあります...
Direct I/O formatted text はかなり柔軟な読み込みオプションがあり、このような汚いファイルに対してもかなり無理が利くようになっています。
Direct I/O formatted text を使うためには DMDL のモデル定義に @directio.text.tabular
(CSV以外の形式のファイルを扱う場合に使い、区切り文字を指定する) もしくは @directio.text.csv
属性を指定します。
@directio.text.csv( charset = "Windows-31J", header = skip, trim_input = true, true_format = "1", false_format = "0", date_format = "yyyy/MM/dd", datetime_format = "yyyy/MM/dd HH:mm:ss", on_more_input = report, on_less_input = ignore ) data_model = { };
属性に指定しているオプションに注目してください。 charset
指定があるのは当然のこととして、どの値を真偽値としてマッピングするか日付時刻のフォーマットも指定可能です。
注目してほしいのは header
指定で、読み込みや書き込みにおいてのヘッダ指定を次のようにかなり柔軟に指定可能です。
指定値 | 内容 |
---|---|
nothing |
何もしない (ヘッダ行が無いものとして読み込み、ヘッダを出力しない) |
force |
ヘッダが存在しているものとして読み込み (1行スキップする) 、ヘッダを出力する |
skip |
読み込み時にヘッダが あれば スキップし、ヘッダは出力しない |
auto |
読み込み時にヘッダが あれば スキップし、ヘッダを出力する |
skip
や auto
といった、ヘッダのあるなしをよしなに扱ってくれます。こんな気配りができるライブラリは割と珍しいと思いませんか。
trim_input
オプションは先頭や末尾に空白文字が入っていると除去してくれます。これでわざわざ @Update
演算子を使わなくてもいいですね。
on_more_input
や on_less_input
なんてオプションもあります。前者は読み込み時にレコードに余計なフィールドがあった場合の動作を、後者はレコードのフィールドが不足している場合の動作を指定できるようになっており、少々変なデータでも対処できるようになっています。この手のライブラリは普通例外を飛ばして終わりということが多いですよね。
on_more_input
の場合の指定内容は次の通りです。
指定値 | 内容 |
---|---|
error |
エラーログを出して異常終了する |
report |
警告ログを出力した上で無視する |
ignore |
単に余剰フィールドを無視する |
on_less_input
の場合の指定内容は次の通りです。
指定値 | 内容 |
---|---|
error |
エラーログを出して異常終了する |
report |
警告ログを出力した上で不足フィールドに NULL を入れる |
ignore |
不足フィールドに NULL を入れる |
これで行によってカラム数が異なる CSV 的なもへの対処とかもできそうですよね。
嬉しかった点その2
「読み込み時にファイルのメタ情報をデータモデルに追加できる」という点です。
データフィールド属性に次のような読み込んだファイルに関する情報を埋め込むためのものが用意されています。
属性 | 内容 |
---|---|
@directio.text.file_name |
属性を指定されたフィールドにファイルパスを設定する |
@directio.text.line_number |
属性を指定されたフィールドに当該データのファイルの行番号を設定する (物理的な行番号であるため、途中で改行の入っているレコードが存在した場合、次のレコードは番号がスキップすることになる) |
@directio.text.record_number |
属性を指定されたフィールドに当該データのファイルのレコード番号を設定する (こちらは論理的な行番号) |
でファイルのデータチェックで、ファイル名や行番号の情報も出力したいような場合でも Asakusa 上で実行できるようになりますね。
終わりに
とりあえずはこんなところです。他にも多彩な機能が用意されているので、詳しくはドキュメントを読んでください。
Asakusa Framework は開発の現場で遭遇する「これがあったらいいな」的な機能を結構貪欲に取り込み続けています。取り込んで欲しい機能があったら ML や GitHub (日本語でも OK ですよ) などで積極的に提案してみることをお勧めします。