カレンダー型ファイルマネージャNemo 99
ストーリー by morihide
CUIシェルで十分という人も多そうですが 部門より
CUIシェルで十分という人も多そうですが 部門より
Open Tech Pressでカレンダー型ファイルマネージャのNemoが紹介されています。Nemoは「初心者にとって階層フォルダ構造の概念は理解しにくい」という前提に立って開発されており、フォルダ分けせずに一カ所にまとめておいたファイルに対し、タイムスタンプ、ファイルタイプ、ラベルなどの属性を使ってアクセスするという方法を提案しているようです。記事にはスクリーンショットが貼ってないので、Nemoの見た目は公式ブログのこちらをぞうぞ。
つづく…
つづく…
Nemoで既存のファイルマネージャを置き換えるのは難しそうですが(記事では大量のファイルを扱うときにNemoのUIが破綻することが指摘されています)、従来型のファイルマネージャにカレンダービューがあると結構便利なような気がします(Time Machineのようなバックアップ機能と連係できるとなおよい)。皆さんはファイルマネージャにどんな機能がほしいですか?
mono + Gtk# ここまでできるのか (スコア:4, 興味深い)
自分も数年前に Visual Studio .NET 2003 を使っていたのと同じ時期にいじってみて,情報収集のために 2ch の「消しゴムじゃないMONOを使ってみるスレ [2ch.net]」あたりで ncurses を呼び出して遊んでいたりしたのですが(だれかしらん兄弟がいるようだが),いまやこんなアプリケーションまで作れるようになっているとは.ASP.NET のほうが先行して mono 環境で実装されていたようですが,デスクトップアプリケーションも作れるようになってたんですね.Windows Forms はどうすんの?Wine つかうの?Novell がなんとかしてくれないかなぁ?Gtk ベースでいくべ,とかいろいろあったようですが,結局 Gtk# が「キター!!!」なんですかね?
mono とか SharpDevelop とかまたいじってみようかなぁ.
屍体メモ [windy.cx]
Re:mono + Gtk# ここまでできるのか (スコア:1, 興味深い)
個人的にはこれらのいわばアーキテクチャの基盤とでも言える部分に
monoやらjavaやらの(超)高級言語を使うのは, パフォーマンスや安
定性の点でも, 将来の互換性の点でもちょっとどうかと思う.
頭が古いんだろうけど.
基盤をC/C++で書いて, UIやラッパをmonoやらruby,pythonやらで
書くというのが一番精神が安定します.
肝は。 (スコア:2, すばらしい洞察)
完全に整理されたログファイルはまだしも、乱雑に取得してきた情報などはワークフォルダの中でカオスを生み出している事も多々。
今でも、一々findしたりAdobeReaderでマイコンピュータから全文検索で検索することもあります。
そういう意味では便利そう。
……googleデスクトップなんて物も思い出しますがソレはそれで。
連想したもの (スコア:2, 参考になる)
画像ファイルだと、こんなのもありますね。
属性DBによる画像管理テストプログラム配布所 [infoseek.co.jp]
槍玉に挙がっている階層フォルダ構造ですが、階層構造による分類そのものは悪くないと思うのですが、木構造で1連の祖先にしか属することができない、というのが制約になっているような気がします。これを打破するにはタグ、属性による管理になるのかもしれませんが、折衷案的にタグ、属性自身にもある種の階層構造があっても良さそうな気はします。
Re:連想したもの (スコア:4, 興味深い)
*物理的なノート(A4大学ノート→後にルーズリーフで書いた後ジャンル分け:入力の煩雑さで破綻)
*テキストファイル(電子ファイル化で入出力簡素化:相互関係の把握の難しさで破綻)
*HTMLで管理(テキストファイル同士のリンクで相互関係制御:タグの入力の煩雑さで破綻)
*tDiary(日記形式で思ったことをそのまま記述+リンクで相互関係制御:時系列入力から論理的構造を再構築する難しさで破綻)
*howmを一瞬ためしてみたり(求めているものと何か違った)
*MediaWikiで進捗状況把握
で、現状最後の「MediaWiki」でメモで不満はないです。
MediaWikiを選んだ理由は「数式が綺麗に書ける」ことと「履歴が継承される」ことだけです。
>槍玉に挙がっている階層フォルダ構造ですが、階層構造による分類そのものは悪くないと思うのですが、
>木構造で1連の祖先にしか属することができない、というのが制約になっているような気がします。
>これを打破するにはタグ、属性による管理になるのかもしれませんが、折衷案的にタグ、
>属性自身にもある種の階層構造があっても良さそうな気はします。
MediaWikiで「カテゴリ」「サブカテゴリ」「サブサブ…」を指定でき、階層化は可能です。
あるメモに対して「カテゴリ」は複数指定可能ですので「木構造で1連の祖先にしか属することができない」は回避できます。
ただ、個人のメモという運用で数ヶ月動かしただけでも、階層化って硬直化してしまいがちな考え方なのかもしれないなと…
カテゴリを作るときに自覚したのですが、やはり「階層化」って難しい概念ですね。
木構造で複数のカテゴライズを許しても、どう木構造を作るか、という設計の概念を最初に明確に立てないと運用が難しい。
懐かしいなあ (スコア:3, 参考になる)
BTRONならタグすら貼らなくていいのに。orz
テキストどころか標準で付いてくるアプリなら仮身張り放題なのに。il||li _| ̄|○ il||li
#元ネタに関しては基本表計算で作ったカレンダにその日の日記と、
#その日作った仮身を貼ってたのを思い出した。
Re:連想したもの (スコア:1, おもしろおかしい)
てっきり「ロリ」とか「猫耳」とか「縞パン」とかの属性を集めた DB があるのかと思って喜び勇んでいた俺の甘さに絶望。そうかそうか、世の中での画像管理というと、EXIF 情報とかで事足りるんだな・・・。
#角煮で自動ダウンロードスクリプト動かしてると、とても手動では整理しきれないんじゃよ。
Re:ファイラ?(オフトピ) (スコア:2, おもしろおかしい)
ブリザラ(ブリーフケースブラウザライク)やサンダラ(三ペイン型ダウンフローランチャー)ならいいのかね?
Re:ファイラ?(オフトピ) (スコア:2, 参考になる)
Re:ファイラ?(オフトピ) (スコア:1)
いまだにWinFDとか使ってFDに触れてて、これが無いと仕事が出来ない状態の自分にはファイラという表現は違和感まったく無いんですが、違和感ありますか・・・。
自分はファイルブラウザという表現の方があまりなじみがないので違和感が・・・。
ファイルマネージャはいまだにキーボードショートカットとか覚えてるけど固有名詞なんでジャンル一般を指すのに使うのはちょっと抵抗が・・。
他にも、いまだについつい「そこのディレクトリを・・」とかいっちゃうんだよな。今はフォルダって呼ぶのが主流なのに・・。
◆IZUMI162i6 [mailto]
いかに分類するか (スコア:2, すばらしい洞察)
(1)「自分のファイルをどのようなくくりで分類すれば便利か」を自分で考えることが難しさのひとつであり、その上で
(2)「各ファイルがどのくくりの中に入るか」を自分で判断して自分で整理する、
ということが難しいのかな、とも思います。
#初心者か否かというよりは、整理が上手か下手か、なのかな。
例えばiPodは、曲の選択時に、ミュージック→アーティスト→アルバム→曲という階層で選択できるようにもなっているわけですが、
(1)アルバム、アーティスト等の分類方法はあらかじめ決められていて、
(2)自動的に分類される(ように見える)
から簡単なのでしょうかね。
例に上げられているiPhotoも、
(1)「イベント」というくくりが自動的に作成され、
(2)そこに自動的に分類される。
だし。
で、カレンダー型というのも、
(1)「日付」というくくりに分類方法を固定し、
(2)その中に自動的に分類される(ように見せる)
という事で簡単なのでしょうか。
超整理法 (スコア:1)
#Windowsの「最近使ったファイル」とかは時々便利だったりするし使ってみると意外といいのかも。
使わず言うけど (スコア:1)
何かと相性が悪いと思われるけど。。。
プログラムのmakeとかどうするかな、とか。
いずれにせよ新しい概念(?)が出てくるのはいいことだと思う。
Re:使わず言うけど (スコア:1)
要するに (スコア:1)
データベース的アプローチを取るというわけですよねぇ。
それをファイルシステム全体で取るのではなく、もうちょっと上の
レイヤーで行うと。
新奇性はあまりないような気がしますけどね。
そして、いざ使ってみると、というか使う前から予測できるのですが、
たとえばファイル名が重複できなさそうとか、カテゴリーごとに
ディレクトリを分けるみたいなことすらできなさげとか、
マイナス要素がいろいろありそうですね。
一応初心者向けをうたっている?ようですが、階層フォルダ構造と
毛色の違う操作体系を初心者に教えても、どの道いずれは
階層フォルダ構造を覚えなければいけないわけで、そうなると
無駄でしかないし。
Re:要するに (スコア:3, すばらしい洞察)
あれは管理してなかったから破綻したのです.
実際日付で管理してますけど (スコア:1)
自宅PCのデータを同じように管理しようとは思いません。
どんな整理法はいいかというのはデータの質にも依ると思います。
ファイル名は日時で自動的に決定して、ハードリンクを階層管理ってのが良いのではないかと
個人的に妄想したりしてますけどね。ハードリンクが全部削除されたら元ファイルは自動的にゴミ箱行きで。
別の媒体へのコピーは実体もコピーで。
・・・気のせいじゃないと思うけど、どっかで見たような気がするんだよな。こんな説明。
# なんにしてもWindowsのショートカットは使えなさ過ぎます。
Re:実際日付で管理してますけど (スコア:1)
もっともあっちは16bitの一意なファイル名ですけど。
樹状構造どころかTADってデータフォーマットのお陰でデータの中にハードリンク(仮身と呼びますあっちでは)を埋め込めて、ハイパーテキスト風にユーザが管理できますけど。
#HTML5のトピック見て「今更TADでも作りたいのか?」とか思った。
んー。カレンダーである必要性が今一つ感じられないな。 (スコア:1)
# メールもRSSもみんなそこに入れるのは...やりすぎ?
Gmail (スコア:1)
代りにラベルとキーワード等の検索で目的のメッセージに到達する
仕組になっていますが、似たような思想があるんでしょうかね。
gmail のインターフェイスそのままでファイル保存・管理するのに
なれた人(いるんでしょうか)には親和性が高いかも。
Re:Gmail (スコア:2, 参考になる)
Gmail を IMAP 使って Thunderbird から操作すると
階層構造は作れますよ。
Thunderbird 上でディレクトリを作ると
Gmail 上ではラベルができる感じで。
まぁでも20000通もメールがあると、
検索効率とか表示の速さとかいろいろ含めて
Gmail を Web ブラウザで使うのが
いちばん便利です。。
# メールデータのインポートとエクスポートに
# Thunderbird を使いました。
Re:Gmail (スコア:2, 参考になる)
オンにすると擬似的に実現してくれると思います。
ただし階層化されたフォルダというのがそれほど便利に思ったことがないので、
今まで試したことはありません。
Re:Gmail (スコア:1)
受信フォルダを/にしてディレクトリツリーを形成するんだと思って、ワクワクしながらアップロードしましたよ。
見当違いな期待をしてしまった自分が恥ずかしい…
ファイルとフォルダの何が難しいのか? (スコア:1)
机の上(デスクトップ)がきれいに片づいていて、書類もきれいにファイルしてある人なのに、どういうわけか、コンピュータのファイルはきちんと整理できてなくてデスクトップに散らばっている人って多いんですよね。
まぁ、ワタシだって、コンピュータのファイルやフォルダは整理できても、物理的なデスクトップは整理できない人なんだから似たようなもんなんだけど ;_;)。
月曜始まり、日曜始まり (スコア:1)
海外では月曜始まりが一般的なの?
日曜は週末、週始まりでもめそうだな、と関係ないことを書いてみる。
# 意識の中では週末だなぁ。
2007-2010年分をA4横1枚に書いたカレンダー,1ページ目が日曜始まり、2ページ目が月曜始まり
http://moura.jp/lifeculture/datebook/pdf/j02.pdf [moura.jp]
Re:月曜始まり、日曜始まり (スコア:2, 興味深い)
> 「月火水木金土日のうた」(作詞:谷川俊太郎)なんてのもあるし。
とりあえず、軍歌の月月火水木金金 [wikipedia.org]を挙げておきます。
UNIX 使いなら、struct tm の tm_wday が、0:日曜~6:土曜 なことを理由に、日曜スタートを使うべきだと主張しておきましょう。
って、crontab(5)の曜日指定は、0でも7でも日曜なんですよね…
こんな syntax sugar を用意する程度には、月曜スタートを使いたがる人は結構多いのか?
Re:悪いけど (スコア:4, おもしろおかしい)
日常的にも階層型で机の上の書類を整理しているのですが、
この書類の下に、あの書類を置いてたはずなのに無いなあ、
あのファイルは最近使ったから比較的上の階層にあるはずなのに何故か見つからない、
ということがよくあり、階層型整理の限界を感じております。
#季節によっては紙雪崩も起きます
Re:悪いけど (スコア:4, すばらしい洞察)
しかも、Webブラウジング以外に利用する時間はもっと少ないのです。
当然、ファイルを作成するような作業はたまにしかありません。
例えば、年賀状ソフトの住所録を更新するとき、趣味の写真の会の会員名簿を更新するとき、
町内会費の明細を作成するときなど。
そうなってくると、ファイルの数も少ないのでフォルダで分類しようとはしません。
そもそも分類するにも分類数とファイル数の差があまりないわけで、無理して分類して
町内会\回避明細.doc
写真の会\会員名簿.doc
というように1フォルダに1ファイルなんて無意味なことをやったりします。
それでも積もり積もると、そのうち数十個のファイルができてきます。
そうなってくると、やっぱりファイルを探しにくくなります。
特に使う頻度が少ないわけだから、そもそもファイル名もフォルダ名も覚えていません。
去年もこの次期に年賀状を書いたはず‥‥とか、
一昨年、町内会の役員をしてたからその頃に明細を作ったはず‥‥とか。
そういう人にとってはカレンダーの方がよっぽど分かりやすいと思います。
Re:悪いけど (スコア:4, すばらしい洞察)
初心者←→くろうとというより、獲得・利用する認知フレームワークの違いなんでしょう。
> 人間が物を整理する時、日常的にも階層型の考え方をベースにしてる
という枠組で世界を認知している人には一般的なコンピュータの構造が理解しやすく、
「今日やったこと」「何日前からやっていること」という時間ベースの枠組で認知している人には
カレンダー型のほうがわかりやすいのだと思います。また、私のまわりのMacユーザは、デスクトップに
さまざまなデータが、内容(論文とか課題とかお遊びとか)に基づいてクラスター化して配置されています。
これは、「机の右側は論文用のデータ置き場」といった空間ベースの枠組でデータを整理しているからでしょう。
こういった違いはたぶん、コンピュータを使うことだけでない、もっと一般的な外界の認知に関するスタイルの違いなのだと思います。
みんながみんな、階層型の枠組でものごとを“見て”いるのではないから、今回のカレンダー型にせよ他のなにかにせよ、
さまざまな枠組に合ったインターフェースが存在するのはよいことだと思います。そうすれば、無理に普段と違う(階層型の)枠組で
理解しなくても、自分に合った枠組でデータ・ファイルを整理できるので、コンピュータが使いやすくなるのではないでしょうか。
あとは、それらの間をうまく橋渡しできる(時間ベースの人のファイル配置を空間ベースの人にわかりやすい表示に置き換えるような)仕組みが必要なのかなぁ。
Your 金銭的 potential. Our passion - Micro$oft
Tsukitomo(月友)
Re:悪いけど (スコア:3, 興味深い)
Re:悪いけど (スコア:1, おもしろおかしい)
初級シスアドに出題されるくらいの難問なんです。
世の中にはあなたの想像を超えるバカがたくさんいるんですよ。
だから恋空とか売れちゃうんです。
Re:悪いけど (スコア:1, 興味深い)
Compositeパターンでツリー構造を実装するクラス図書いてえらい人に見せたら、第1階層用のクラス・第2階層用のクラス・第3階層用のクラス・末端ノードのクラスに分割されちゃった。
# まあ最後にRDBに落すこと考えたらアホアホでも平べったい構造にしたいというのは分からんでもない。
Re:悪いけど (スコア:1)
デスクトップまたはマイドキュメントに
置いてるひとを見たことないですか?
#うちの家族ですorz
Re:悪いけど (スコア:1, 興味深い)
小さなファイルを一気たくさんに作って
整理やファイルを使いたくなった時にいちいちフォルダを行き来するのが面倒だから
放置するような使い方をしている人や
インターネットからダウンロードしておいて
あとでじっくり見ようと思ったファイルの所在を探すときに便利だと思います。
実際、いまメッセンジャーのファイル受信用フォルダは日付順でソートしてます。
なので、いいものかどうかは
個人的な感覚、好き嫌いもしくは使い方の問題ではないでしょうか?
階層で考えるというのはファイルシステムの中にも
仮想的な「位置」が存在するというのをイメージするまでは難しいですし
あくまでひとつのあり方を示す1ツールとしてあったら面白いと思いますよ。
出来れば標準のファイルシステムもフォルダとか関係なくディスク内のデータを
作成日順で見やすく表示できるようにしてくれてもいいと思うんですけどね
Re:悪いけど (スコア:1)
よくある、「あれあれ、昨日見ていたあれが欲しいんだけど」ってのがさくっと見つかると便利
絶望した! (スコア:2, 参考になる)
XP以降のエクスプローラの検索コンパニオンなら、アクセス日付で検索なんかも、当たり前に出来る事なんだぞぅ?
検索条件を絞らないと、要らないものしか出て来ないけどorz
Re:絶望した! (スコア:1)
ファイル名で整列 & グループで表示したときのやる気のなさは UTF-8 が natural enemy な蟲みたいですが。
Re:絶望した! (スコア:1)
HDDを買って最初にやることは、インデックス作成機能をオフにする人なので
そもそも検索機能なんてVisual Studioからしか使ってませんでした。
どもども
Re:絶望した! (スコア:1, 参考になる)
とりあえず個人的にはこれがあるのでXPの検索は使えませんね・・・
・すぐ再検索を始める、検索終了を押してもディスクアクセスか何かがトリガーでやっぱり再検索が始まる
→終了を押したら開始を押すまで再検索しないで欲しい
・アーカイブ内(Zipなど)のファイルを同列に表示するくせに、同列で扱えない
→せめてアーカイバ内ファイルは色を変えるなり種類順ソートの時に別なファイルとして表示して欲しい
・初期設定の犬が簡単に即時offにできない(いやまぁ大した手間でもないですが)
→検索のトップにoffのボタンを付けて欲しい
2番目はアーカイブをフォルダとして扱わないようにするなり、3番目も大した手間なく変更できるので良いですが
1番目が致命的です、数千ファイルとか扱う時に耐えられないです
Re:絶望した! (スコア:1)
Re:悪いけど (スコア:2, 参考になる)
それで合ってるんだったら、エクスプローラのカラムにも表示できますが。
#ウチは切ってるんで試せません。
Re:悪いけど (スコア:1)
ちょっと極端な気もします。
分類のキーを項目にするか、時間にするかってだけの
問題なような。
#カレンダーも年→月→日の階層といえなくもないし。
まぁ、自分は最終変更日でファイル検索することが
多いので、階層型を使いこなしているとはいえませんが。
Re:悪いけど (スコア:1, 興味深い)
# 私はそうだし、たぶんあなたもそう
音楽の例 (スコア:1)
例えばクラシック音楽のmp3ファイルを保存するとします。ショパンのピアノ協奏曲で、指揮者がDmitri Kitaenko、ピアニストがEvgeny Kissin、オーケストラがモスクワフィルだとします(いま聴いている曲を選びました)。
私はピアニストのKissinが好きなのでフォルダはKissinで分けたいけど、ショパンも好きなので「ショパンフォルダ」かも知れません。でもショパンフォルダには他のピアニストもたくさん入ります。作曲者で分類したとき、Kissinだけ聴きたいとしたらどうしようか。一つの答えがiTunesみたいなソフトにあります。
このような卑近な例でも階層型は問題があります。他の方が超整理法の例を挙げていますが、日常生活でも階層型ではない分類をする人はたくさんいます。
なのに階層型がこれほど多いのは一つには先入観があると思います。ファイルシステム等の設計をする人はコンピュータに強く、ファイルシステムは階層型なのが当たり前と思っていることが多いのではないでしょうか。UNIXにしてもWindows/MS-DOSにしても階層型なので、それで育ってしまうとそういうもんだと考えてしまうのも無理はありません。
Re:音楽の例 (スコア:1, すばらしい洞察)
あなたは、自分の脳の処理を言語化するときに、自分自身を騙していないと言えますか?
# ニューロンの原理を考えると、絞り込みは連想同時多発的なのが効率がいいと思うな
Re:悪いけど (スコア:3, すばらしい洞察)
「何も無い」から「何も無い」が取り出せて
「何か」を「何も無い」に送り込むと「何も無い」になる。
それは不思議な「何も無い」…
Re:悪いけど (スコア:2, おもしろおかしい)
「何か」を「何も無い」に置き換えると世界がおわるんですね。
mv /tmp/hoge /dev/null
# 確認してないけど ID
コズミック・ジョーカー
補足というか本文というか (スコア:1, 参考になる)
年単位、年月、年月日と「階層的」に分別できます。
意味付けしたいなら新たに「アルバム」というフォルダのようなものを作って関連付けできます。
例によって「スマートアルバム」という動的なものも作れます。
UIはカレンダっぽくないけど、日付で管理することもかなり有効なケースがあることが実感できます。
写真で撮影日付という条件だからかもしれませんが。
#プレビューして再編集してる途中で投稿してしまった
Re:補足というか本文というか (スコア:1, 参考になる)
日付で階層的に表示させる機能は無くなりました。
Re:1フォルダのファイル数 (スコア:2, 興味深い)
FAT32の場合は、ルートディレクトリも可変長(サブディレクトリと同じように連結リストで拡張できる)のですが、
FAT12/FAT16では、ルートのディレクトリエントリは固定長で確保されているため、ルートのファイル数上限が発生します。
そこまではいいのですが、そのディレクトリエントリ数はフォーマットによって決まるものであり、ファイルシステムドライバ上は、リンク先に書かれてるような「512エントリ」なんて制限はありません。
まあルートエントリ数はBPB上で2バイトで指定されてるので最大でも65535ファイルまでですが、そこまで使えるようにしたら、それだけでルートディレクトリエントリに固定長で64k×32バイト=2MBもの容量を取ることになります。
って、2MBぐらいたいしたことないやん…
この程度なら、ルートディレクトリのエントリ数は多めにフォーマットしてもいいような気がする…
ちなみに、フロッピーディスクの場合、伝統的に192エントリですね。
コピーって?ゼロックスですか [amazon.co.jp]って本では、
一太郎ファイルがフロッピーに64文書しか保存できない(一太郎はVer.3の頃、一文書につき3ファイル(*.jxw/*.atr/*.ctl)を必要としていた)とか、
いや、32文書しか保存できない(バックアップファイルを作成する設定だと、一文書で6ファイルになる)
なんて症例が報告されてました…