分類作業は木構造になりがち。そもそもシステム的に木構造しかサポートされてないこともよくあるけど、それってデータの分類が完全にMECEでないといけなくて、人間に完全にMECEな分類を作ることを要求するので破綻する。理想は、例えば循環構造や重複を許した緩い木構造的なものだと思ってる。
— きいあむ / IKEDA K. (@key_amb) 2017年3月1日

階層的な分類が発生するのは、群を全体として把握したい時だろう、たぶん。人のチャンクは7か8程度だから、要素が多いときパッと把握できない。階層化されていれば、あるノードの子要素のみに着目できる。
この仮定だと、「近しい要素がたくさんある」領域では階層は深くなる。
— きいあむ / IKEDA K. (@key_amb) 2017年3月1日

それってすごく恣意的で、人が人の都合でやるだけだから、分類がMECEかどうかって関係なくて、だからMECEを前提にした木構造による分類機能は要求を満足できてないことが多いんじゃないかなぁ、と思った。https://t.co/lE44BV6dwH
— きいあむ / IKEDA K. (@key_amb) 2017年3月1日

補足

分類作業しんどい。
これに尽きます。

適切な分類を考えるのも面倒だし、要素が増えた時に再分類するのも面倒。
で、データノードが属するカテゴリが1つに制約されているケースだと、あるデータノードを探すときに分類された位置を正しく覚えてないといけない。
検索機能があれば救われることもありますが。（検索機能がゴミだと救えない。）

まとめると、ユーザに与える負担が大きすぎるんじゃないか、と思うのです。

もっといい感じのソリューションあるんじゃないかなぁと思う次第です。
雑ですが。

じゃあどういう分類がいいの？

マシなやり方の候補として、既に世にある例で思いつくものをいくつか挙げてみます:

Googleフォト
- 機械が勝手に分類してくれる
Gmail
- ラベルを階層化できる
- メールに複数のラベルを付けることができる

ラベル方式については、融通の効かないプリミティブな木構造よりは、マシかなぁと思いますが、ラベルが増えた時の解決策が木構造による階層化というのは、なんか少し残念な気がしないでもないです。
結局、適切な階層化について人が悩む必要がある、という点において。

じゃあ、自動分類でいいの？というと、上のツイートに書いたように、分類作業を人が人のために行う場合なら、まあ、人がやるのが自然で理に適っているような気もしないでもないです。

データの性質なりなんなりで自動分類が可能なら、機械化もアリかもですね。
Googleフォトの分類はあまり活用していないので、なんとも評価できませんが。

結びに

「そこまで言うなら自分で作ったら？」と思う人もいそうです。
…はい。すいません。

まだ、要求も要件もふわふわしている感じですね。
手始めとしては、特定のケースについて考えてみるのがいいかもしれません。
例えば、Wikiをいい感じに整理するとか。

機会（と時間）があれば、よりよい仕組みについて考えてみたいと思っています。

2017-02-28

メモ：ソフトウェアにキラキラネームを付けることの功罪について

ソフトウェア開発

あるソフトウェア・プロダクトを開発するにあたって、名前を決めたい。
次の2つの選択肢を考える。

キラキラネームを付ける。
- 神様の名前とか、古語とか、プロダクトの機能と紐付かない固有名詞っぽい名前
機能に即した名前を付ける。

…で、前者の後者に対する Pros/Cons を考える。

Pros

ネームスペースを作ることができる
（覚えれば）誤解が起こりにくそう
- ググラビリティが上がる可能性が有る
秘密の案件とかだったら、コードネームとしても使えそう
開発者のモチベーションになる(？)
- 「キラキラネームかっこいい！」と思う人もいるかも

Cons

実際の機能とキラキラネームとの対応を覚えなければならない => 学習コスト、コミュニケーションコストが発生し得る
- 数が増えると大変そう

その他の声

キラキラネームは、機能が明確でないモノに付けるのはよいのではないか。
- Microservices の文脈でそれは起こり得ないはずなので、 Microservices の各サービスにキラキラネームを使うのは不適当ではないか。

雑感

キラキラしたやつ、数が多いとつらい
ググラビリティはちょっとした工夫で担保できそう（単語を組み合わせるとか、一部スペルを変えるとか）で、キラキラした名前をつける必要は必ずしもなさそう
わかりやすいのが一番。適度な長さの、実体に即した名前が無難ではないか。短すぎると、ググラビリティとか、困ることもありそう。

2017-01-08

bashrc 内で bind を使うとリモートからコマンド実行時に警告が出る

シェル

peco などを快適に使うために ~/.bashrc 内で bind コマンド*1を使って、キーバインドをカスタマイズしています。

このとき ssh $host "コマンド" のようにリモートからコマンドを実行すると、 ~/.bashrc から bind を実行する行で、下のような警告が出ます:

/home/key-amb/.bashrc: line 30: bind: warning: line editing not enabled

解決策

この警告は TTY が有効でないことに由来するようです。
例えば、下のスレッドに回答があります:

http://superuser.com/questions/892658/remote-ssh-commands-bash-bind-warning-line-editing-not-enabled?answertab=votes#tab-top

自分の ~/.bashrc で peco の設定をロードしている箇所では、次のようにしました:

if which peco >& /dev/null && [[ -t 1 ]]; then
  # setup functions and key binds for peco
  # :
fi

test -t 1 で、標準出力が端末でオープンされているかチェックできます。

参考: https://www.gnu.org/software/bash/manual/html_node/Bash-Conditional-Expressions.html

脚注

*1:https://www.gnu.org/software/bash/manual/html_node/Bash-Builtins.html

weblog of key_amb

主にIT関連の技術メモ

GitHubリポジトリを @progrhyme に移行していきます。

Hugoのドキュメント用テーマ「bootie-docs」v1.3までの更新について

サイト独自のカスタムCSSを設置可能にしました

メニューバーにHugoのMenu機能を使うようにしました

サポートするHugoのバージョンがv0.14→v0.15に

結びに

MECEな木構造による分類方法の提供は要求定義を間違えているのではないか

タイトルについて

思ったこと

補足