Flet はいいぞ

はじめまして。じんと申します。株式会社バニッシュ・スタンダードの Data AI Unit というチームのマネージャーを拝命しております。社名に中黒「・」があることに違和感を感じる方が多いように感じていますが、自然言語処理屋として英語の単語の間には「・」を入れる派なので割と社名に違和感がない勢です。駆け出しの頃には YRP 野比におりました。365日24時間火の灯る街でした。

Disclaimer

1. 記事の概要：本記事は Python で簡潔にアプリケーションを構築可能なフレームワークである Flet の内容を含んでいますが、一方で、本記事の趣旨はむしろ、フロントエンドとはほど遠い分野において専門性を有する技術者がフロントエンドまで気にした方がよいと執筆者が思料する理由を記述しています
2. 文脈：特に AI に関連するプログラミングを Python で実施する技術者が UI を意識せざるを得ない状況を想定しています
3. 対象読者： Python を利用しアプリケーションというよりもライブラリを開発する技術者 (自身を研究者と捉える方も含む) 、加えて Python で専門的な業務を行なっており、かつ、お客様に対して実際的な商業的価値を提供することを目指す技術者

Flet はいいぞ

唐突ですが Flet にハマっています。二重の意味で。なぜかというと。

1. Python で素直に UI が作れる
2. マテリアルデザイン準拠で脳みそを使う必要があまりない
3. クロスプラットフォーム

こんなものかと思います。 Python で UI を作れる同じようなフレームワークは他にもあれこれある気もしますので単に Flutter を使っていたのでわかりやすいということだけなのかもしれません。

なんで Python で UI を作りたいのか

仕事上、割と AI 関連のライブラリを使うことが多々あります。そしてそういったものは大抵 Python で書かれています。 Flet を使うと Python で作ったモジュールを直接呼んで UI を作れるんですね。

さて、なぜ UI がいるのか、という話なのですが、要は何かにつけてデモというものが仕事上重要で、このデモにはどう考えても UI があったほうがいいわけです。ターミナルからプログラムを起動してゴニョゴニョしているところを見せても一言で言えば映えないんですね。実際に UI まであると、「おっ、動いてるじゃん！いいね！」となりますし、プログラムが使えない人でも使えるわけですな。

デモというのはどういう性質があるかというと、デパ地下に行くとチーズとか試食してくださいという場面に遭遇したことがある方は多いと思います。わたし自身は食べ物に関しては結構いろいろ試す方だと思うのですが、食べ物の味って食べてみないとわからないので、人体に害がなさそうである限りはとりあえず食べてみて、おいしくなければ購買の選択肢から外れますし、おいしければ購買の選択肢に入るわけです。逆に、販売する側から見ますと、とりあえずこのチーズを食べてみてくれ、と提案することができない、ということは、わたしという消費者にとっては致命的です。

更に申し上げますと、販売側としては、この商品はダメじゃん、ということも可視化されると早々にわかります。いいね！とわかること以上に、これはダメでは？ということが判定されることが重要で、何か新しいことを考え出したら UI まで気張る必要があるなあ、と思う日々です。

Flet のしんどいところ

Python 勢には Flet を使い始める時間的な習熟コストは非常に低いように感じています。一方で複雑なアプリケーションを作るのが難しい。ダイクストラ先生から激怒されてしまいそうなコードが Flet では書かれがちだと思います。

あとまったく枯れていないので、公式のドキュメントが貧弱であり、むつかしいことをしようとするとそれなりに調査をしながら開発することが必要です。こういったものは日本語の資料より英語の方が圧倒的に充実しています。そもそも日本語で記述された公式なドキュメントはおそらく存在しない。そのため、英語が苦手じゃあ、という方にはあんまりおすすめできない印象はあります。 Flet というフレームワークのロードマップを理解できることや、加えて、コミュニティに関与するぐらいの根性が必要かもしれません。こう書くとしんどいフレームワークのように思えてしまいますが……。

さらに言うと、あるクラスのプロパティとして何を有しているのだとか、公式の Flet のドキュメントでかゆいところに手が届かない点がよくあり、 dir() で対話プロンプトで調べたりすることがままあり、ちょっとむつかしいことをしようとし始めると妙な苦労があります。最近では Flet の DataTable クラスの挙動に苦しむなどしました。かなり直感的ではない挙動をする印象が個人的にはあります。 DataCell クラスに Text クラスを素直に入れると特定の状況において好ましくない描画がなされるため、いまのところ Flet では表は Column と Row と Divider で作った方がよさそうという気がしています。

本題

さて、わたしは Data AI Unit を率いております。私の専門は人工知能と呼ばれる技術分野です。しかし、わたし自身は AI という単語があまり好きではありません。これはこの単語の、ソシュールによる、 AI というシニフィアンに対するシニフィエが、社会においてバベル的に混乱しており、それだけではなく、意図的に混乱が巻き起こされている側面があるように見受けられるため、その混乱に巻き込まれることを避けたいためです。それはともかく、わたしの専門性を十全に活用するという観点からは、フロントエンドのことは気にせず、専門に集中した方がいいのではないか、という考え方があると思います。それは事実と思います。

ただ、さきほど、ダイクストラ先生にご登場いただきましたが、わたしは、かなり理論的な計算機科学、さらにいうと計算複雑性理論といった点を意識しながら仕事を出発して参りましたため、どうも、理論計算機科学の面白さにハマってしまいがちです。そのため、実際のお客様がお求めのものと離れたことを考えてしまう傾向がむかしのわたしにはありました。こういったときに UI まで作ると、地に足が付くと申しますか、はて、ちゃんと、自分が作っているものがお客様に提供できる価値というものはなんであろうか、ということに立ち返れるというところがあります。そのため、わたしにとっては UI まで作る、というのは深刻に意識している点です。

終わりに

Flet に関する詳しい話は検索していただいた方が本記事をお読みいただくよりよいと思いますので踏み込みません。そもそも Flet の公式ドキュメントを読みまくる方がよほど有益と思います。

やや散漫な記事になってしまいましたが、申し上げたいことは、 UI まで作るのは結構ためになるので、みんなで Flet を使ってしんどい思いをしていこうな、ということです。

なお、本記事を執筆中、表記揺れを解消するために、 Zenn の記事執筆画面で Safari で文字列検索をし、複数の文字列がヒットした際に2つめ以上の文字列のハイライト部分に遷移すると Safari の表示がおかしくなり編集できなくなることがわかりました。フロントエンドというのはむつかしいな、と日々思います。現場からは以上です。