Linuxのデスクトップとサーバーについて扱います。本章は、クロスプラットホーム・デスクトップアプリケーションについて、わたしが使ったことのないテクノロジーについて書いている。他の章よりさらに現実乖離度が高いと思われる。個人的な印象であることに留意しつつ、短く留めるよう努力する。その他のクロスプラットホームFWクロスプラットホーム・アプリケーションFWはGTK/Qt/Electronだけではない。思いつくものとして、Java,C#,Unity,SPAがある。JavaJavaはGUIなデスクトップアプリケーションだけのものではないが。joel氏が「宇宙人が見様見真似で作ったため味を付け忘れたUI、後に修正されたが」と語っていた奴。<<joelonsoftware本へのリンク>>Javaの機能は、クロスプラットホームGUIだけでない。Javaの悪評について。Javaが使われている環境ではプログラマの扱いが悪いという話が目につくし、Java自体も酷評されている印象がある。恨みもないので擁護するようなことを書いておくことにする。COBOLを置き換えて長期利用する安定したシステムにJavaが採用されるのは、エコシステムを含めたJava全体で見ればそのようなメリットがあるということだと思う。Javaが持つ機能は、GC・VM・中間表現その他、当時から見たらどれも革新的な新テクノロジだったと思う。Javaはそれらの新テクノロジを一度に商用システムに持ち込み一般化したすごいパイオニアだった。Javaは、商用化についてパイオニアになった。同時に、パイオニアが犯すことを避けられないあらゆる失敗を抱え込んだのではないかと思う。悪いことに、Javaは成功した本物の商用言語製品だった。後方互換性を捨てることはできないことは失敗を修正する機会がなかったことも意味する。長生きすればするほど、Javaは10年前のよく知られた言語設計の失敗を今もそのまま抱えた言語として、悪評も固めていったのではないかと思う。個人的にJava開発環境を悪く思ってはいないが、前述の通りプログラマには劣悪環境であるという話しか聞かない。個人開発で採用する理由はないし、Java案件に関わらないで済ますためにも、Javaは使いたくない。C#フォームデザイナとかあってすごく使いやすいJavaのようなものらしい。Linuxでやるのが面倒くさそうなので採用したことはない。Qtと同じくモバイルアプリケーションを守備範囲に含む。ユリアーモの文字割り当て変換(※)のWebサービスを作っていた時、競合がWebサービスをUnityでラップして、デスクトップアプリケーション版をリリースした。)モバイルやゲーム以外にも、Electronと同じ使い方で同じ範囲をカバーできるらしい。Unityは言語として、C#とJavaScriptが使える。他にもあった気がする。個人的には、Qtと同じくモバイルアプリケーションに傾注するであろうという予想とか、プロプライエタリであり無償版は起動時ロゴが出る、3D性能が必要なことはしない等の理由で、マルチプラットフォーム・デスクトップアプリケーションFW選択の際に真っ先に脱落する。※ユリアーモは「ことのはアムリラート」劇中に登場する架空の自然言語。独自のアルファベットを用いる特徴があり、公式からフォントがリリースされている。)このフォントのアルファベットの割り当てが特殊であるため、一般に使われるラテン・アルファベットの割り当てを、公式の独自割り当てに変換するサービスが必要となる。Webアプリケーション(SPA等)デスクトップアプリケーションから主役の座を奪い、現在はモバイルアプリケーションと覇権を争っている奴。雑に言えば、ブラウザがあれば動くので、マルチプラットフォーム性が最強。現実にはいろいろ面倒なところや弱点があり、決定打とはいえない。(このへん列挙は面倒だし、読者を含め私より詳しい人はいくらでもいるので書かない)ぱっと作れてぱっと使う、家の外やモバイルで使う、軽いツールを作る場合はWebアプリとして実装することが多い。前述の、ユリアーモの文字割り当て変換は軽いツールの例。使用していないFWの機能GTKは機能ヘルパ兼依存ライブラリの数が多く、Qtは分厚く範囲の広いクロスプラットホームレイヤであるためこちらも機能が多い。Electronはわりと機能の少ない小さなアプリケーションを書いたつもりなので、最低限以上の機能は使わないようにしていた。そのため、筆者が使用していない機能のほうがずっと多い。そもそも網羅的な入門書を書くのではなく、本物のアプリケーションを書くためにGTK,Qt,Electronを使っているので、全機能を触っておく必要はない...。(なので本書はこういう感じです。)というわけで、使っていない機能の話はしておくべきかと思うので本章を書いた。Electron:自動アップデート・クラッシュレポートgithubのリリースページにインストーラを置いておくと勝手に認識して自動アップデートしてくれる、とかだと嬉しかったのだが、そういうわけでもない模様。そもそもElectronを使って作ったlina_dictoはプラットフォーム毎にインストーラを作るのが面倒でzipでリリースしている。現在はインストーラ形式での配布はしていないので、自動アップデートの前にインストーラ作成しなければ。クラッシュレポートはJoel先生のブログ記事を読んでからぜひ実装したい機能で、Electronに搭載されていると聞いたときは狂喜乱舞したのだが、いかんせん作ったアプリケーションのユーザベースが少なすぎてコストに見合う気がしない...。Qt:QMLJSでアプリケーションを書くなら普通にブラウザアプリのほうがいいと思う...。)はElectronで書いたlina_dictoをWebViewで移植して作ったので、QtのAndroid,iOSクロス開発機能は使用しなかった。QtのAPIがカバーする範囲はよくわからないが、QtのAPIに無い機能については、プラットフォーム毎にネイティブコードを書くし、そういう書き方ができる、とのこと。<取り消し線>Qtでモバイル開発していた周囲の人々は、iOS11対応で悲鳴を上げていた。Qt:組み込み死に体のデスクトップアプリケーションからQtが見つけ出した脱出先。セットトップボックス等でHTMLが重いような場合を想定しているとのこと。ターゲットによってはQt自体のクロスビルドから自前でする必要がある。組み込みQtのサポートは販売ライセンスがデスクトップアプリケーション版と異なるという話が。GTK:マークアップ言語によるウィンドウ構造記述QtはQtCreatorをフォームデザイナとしてポトペタするのが一番簡単であるためそれを使うことになるし、目diffを目patchする羽目にでも陥らない限りはQtのXMLを直接触る必要はない。ElectronはHTMLを書くしかないので、マークアップを使う使わないという話にそもそもならない。GTKの場合、QtCreator相当のフォームデザイナがクラッシュするような品質であり、マークアップを直接書くのはドキュメントが整備されていたとしても御免こうむるので、コードで直接UIを構築していた。今はもう少しマシになっているといいなと思う。Windows版はバイナリ配布が無いかもしれないけれど。GTK/Qt:非ネイティブな言語バインディングバインディング境界でバグが発生したら解決できなさそうだったので、生産性を犠牲にして、GTK,Qtではネイティブ言語なC言語,C++言語をそのまま使う選択をした。バインディングはどうしてもネイティブ言語よりドキュメントの優先度が低く、ユーザが少ないこともあって、情報を集めることが難しい。バインディングを使ってアプリケーションを書いてしまった場合や、公式が本当に一級市民扱いのサポートをしている場合以外には、おすすめしない。mini2を試験導入していてすごく便利で体感が良かったです。nijiflowをベースに、機械学習で艦これとアズールレーンの画像の分類器を作り、学習済みグラフ等を公開した。これのTwitterBotを作成し公開している。データセットはPixivのタグ付け済み画像情報を元に作成した。Web上にあまり開封写真等の詳細がなかったので残しておきます。モノが大きいためか、知らない運送会社でおくられてきた。...JavaScriptで、変数を使った正規表現マッチング例および失敗例は、自作のJavaScriptソースから抜粋。※例ごとにマッチする文字列が違いますがご容赦ください。