視覚的に人の注意を引きつける資料は、心理学や神経科学の研究においてよく用いられるそうです。こうした研究において、回転させることで別の絵に見える「だまし絵」が利用できないかと考えたジョンズ・ホプキンズ大学の研究者らが、こうした絵をAIで生成して実験を行いました。
今回の研究で、ただのだまし絵でも知覚研究には大いに役立つということが分かったため、ボガー氏らはさらなる研究を望んでいます。ボガー氏らは「これらの画像は、大きさ、生命の有無、感情に至るまで、あらゆる種類の効果を研究するために使用することができます。これまで不可能だった方法で、人が絵をどのように認識しているかを研究できるのです。加えて、見ていて楽しいのは言うまでもありません」と述べました。
⇧ 検証データを「AI」で生成できたという話っぽいのだが、
隠し絵（かくしえ）/ダブルイメージ（英: Double Image）とは、絵の中に、よく注意して見なければわからないように工夫して、他の絵を描き込んであるもの。さがし絵ともいう。有名な絵に『嫁と義母』や『ルビンの壺』がある。
⇧ 上記の「隠し絵」にも応用して欲しいところですな。
その前に、研究の領域の分類をしっかりとして欲しいのだが...
PythonのWebフレームワークFastAPIで複数Controllerクラスの設計ってどうするのか
「Java」の「Spring framework」とかだと、割かしフレームワーク側で良しなにしてくれるのだが、「Python」の「FastAPI」は利用者側で頑張る必要があるらしく、
⇧ stackoverflowによると、「Controller」クラスを用意するだけでは駄目らしい...
「ChatGPT」氏に質問してみたところ、以下のような回答が返ってきた。
3️⃣ 注意点
-
Controllerクラスは 必ず
router属性を持つ こと -
Controllerクラスのコンストラクタは 引数なし or デフォルト値あり にする
-
Routerの
prefixやtagsはクラス内で設定しておく
💡 まとめ：
-
手動で
app.include_router()を100回書く必要はない -
「ディレクトリスキャン＋動的登録」でスッキリ管理可能
-
将来的にControllerが増減しても
main.pyは変更不要
■Pythonのプロジェクト構成
app/ ├─ controllers/ │ ├─ download_controller.py │ ├─ user_controller.py │ ├─ order_controller.py │ └─ ... # 100個あってもOK ├─ services/ ├─ progress_store.py └─ main.py
■app/main.py
# app/main.py
import importlib
import pkgutil
from fastapi import FastAPI
app = FastAPI()
# controllersパッケージを動的にスキャン
import app.controllers as controllers_pkg
for _, module_name, _ in pkgutil.iter_modules(controllers_pkg.__path__):
module = importlib.import_module(f"app.controllers.{module_name}")
# module内のクラスを探す
for attr_name in dir(module):
attr = getattr(module, attr_name)
# router属性を持つクラスを自動登録
if hasattr(attr, "router"):
controller_instance = attr()
app.include_router(controller_instance.router)
⇧ というような感じで、「Java」で言うところの「リフレクション（java.lang.reflect）」っぽいことを自前で実装する必要があるっぽい...
とは言え、「Java」で言うところの「リフレクション（java.lang.reflect）」は利用が推奨されないって話をよく聞きますが...
まぁ、「ChatGPT」氏の回答が「幻覚（ハルシネーション）」という可能性もあるので、何とも言えないのだが...
と言うか、ディレクトリ構成に依存してしまっているのよな...
う～む…、「Python」のフレームワークが微妙過ぎるのか、「Python」のフレームワークの中でも「FastAPI」が微妙過ぎるのか分からないが、フレームワーク側のアーキテクチャで頑張って欲しい気はする...
「Java」の「Spring framework」と「Spring Boot」で「Spring Web MVC」とか利用していると、このあたりの実装を隠蔽してくれるので、「Controller」クラスのメソッドの「エンドポイント」の設計さえ、適切にしておけば、フレームワーク側で良しなにしてくれるので、「Python」のフレームワークが煩わしく感じてしまうんよね...
まぁ、
Don't repeat yourself（ドント・リピート・ユアセルフ、DRY）は、特にコンピューティングの領域で、重複を防ぐ考え方である。この哲学は、情報の重複は変更の困難さを増大し透明性を減少させ、不一致を生じる可能性につながるため、重複するべきでないことを強調する。
DRY は、Andy Hunt と Dave Thomas の著書 The Pragmatic Programmer (邦題:達人プログラマー) において中心となる原則である。 彼らはこの原則を、データベーススキーマ、テスト計画、ビルドシステムや、ドキュメンテーションにいたるまで非常に幅広く適用している。
Once and Only Once 原則との対比
DRY はアプリケーションに必要な情報（通例は設定情報）に対して言及しているという点で Once and Only Once (OAOO) 原則とは区別される。比較すると OAOO はコードの機能的な振る舞いについて言及しており、構造体やオブジェクト指向言語における継承の実現が必要な理由となっている。
⇧ 上記にあるように、同じ構造の記述は繰り返したくないですからな...
所謂、
ボイラープレートコード (英: boilerplate code、または単にボイラープレート) は、コンピュータプログラミングでは、殆ど、または全く変化することなく、複数の場所で繰り返される定型コードのセクションのこと。冗長な言語を使用する場合、プログラマーはコードを少しだけ書くだけでも多くのコードを作成する必要がある。このような定型コードはボイラープレートと呼ばれる。
⇧ 上記のような「ボイラープレート」と言っても過言ではないソースコードについては、
のいずれかで隠蔽して、ソースコードの実装者が考慮する必要のないようにして欲しいのよね...
毎度モヤモヤ感が半端ない…
今回はこのへんで。
