正直なところを言えば
松本さんが推進しておられる、わさびーさん作のUbuntu Desktop Cleanerというツールのベータ版が出ているとのこと。
試そうと思いましたが、今のところ、ワタクシの環境では動作せず。orz
−−−−−−−−−− 追記 −−−−−−−−−−
動くようになりました。(笑)
対応速いですね。
−−−−−−−−−− 追記終わり −−−−−−−−−−
ま、それは開発途中のものに対して、人柱要請が出ていたので、協力しようと思っただけなので、構わないんですが。
実は、なんでもそうだと思いますが、ことプログラムとかツール提供って話だと、初心者相手が最も難易度が高いんです。
初心者には、ある意味、開発者の常識は通用しません。
普通、そんなことやるか?って操作を、さも当たり前のように行います。
ちょっとでも使い方が解らないと、敬遠します。
なので、対初心者用としては、以下のことを考える必要があったりします。
・それ以外できない。
・操作のガイドがある
ちょっと解説しますと。
・それ以外できない
これは、本当に、何かさせようとした場合、多機能である必要は全然なくて、「目的が簡単に達成できる」ことが必要ということです。
そして、それ以外の操作も機能も一切不要なんです。初心者には。
ついでに、「バカ避け」といわれる機能も必要です。
初心者は間違います。間違う前提で作る必要があり、必ず操作の最後には確認を求めて、かつ「キャンセル」がデフォルトになってる必要があります。
それでも間違います。間違うんです。(笑)
なので、削除系の操作の場合には、必ずバックアップを取り、別途操作が必要でも構いませんが、実行前の状態に戻せるようになってなければなりません。
#一見多機能に反しますが、単機能の中の「バカ避け」の機能に含まれるんです。
変に多機能にしてしまって、操作を迷わせるようだと、かえって使いにくいと感じるものです。
・操作のガイドがある
これも、初心者向けツールには必須の機能で、そのボタンを押すと何が起きるのか、いま選択している一覧は、なんのための一覧なのか、が一目で解る要になっている必要があります。
一番いいのは、ウィザード形式だったりするんですが、これは頻繁に使う機能だったりすると、慣れて来たときに面倒になります。
なので、画面に説明文をつける、ボタンやラジオボタン、選択ドロップダウンにツールチップとして、何をするためのボタンなのか、を説明する必要があるんです。
初心者の方が、ドキュメントなんて読みません。(笑)
操作は直感的に、そして簡潔にできないと、初心者は「難しい」とか言って使わないんですよ。(笑)
ある程度ITに通じている人の場合、過去の経験から、ヘルプというかガイドなんてちゃんとしてなくても想像して操作してくれますし、場合によってはきちんとドキュメントに目を通してから、ツールを使ってくれますが、初心者は、「まず結果を求める」ので、マニュアルなんて読みゃあしません。
とまあ、このように初心者相手の方が、実はモノの造り込みが丁寧じゃないとダメなんですよ。
考える必要があるし、「こんなもんだろ」なんて思ってると、全然足りない。(笑)
そりゃあもう、大変ですよ。(爆)
しかも、初心者は、そんな使い方をするくせに、ツールに対する信頼感は絶大です。プログラムにバグがある、なんてことは一切考えない。
操作すると、期待する結果になる、と思ってます。
なので、バグのせいで、思いも寄らない結果になると、そりゃあ怒るんですよ。
そして、「自分の使ってる環境」が「絶対」です。
他に似た環境とか、自分の使ってる環境とは異なる環境がある、なんてことは思いもしない。
なので、なんかがインストールされていない、とかそういう前提条件があるのに、動かないとすぐに「バグってて動かないんですよ」とかいうんです。(笑)
#ま、ある意味バグなんですがね。異常系のトラップが不足している。
ドキュメントに、これこれをインストールしてあること、とか書いてあってもダメなんですよねぇ、読まないから。(笑)
過去の経験から、初心者向けツールに関して、チラと書いてみました。
まあ、経験者向けのツールが、作りが甘くていいか、ってぇとそんなこともないんですが、経験者の方が、ある程度妥協することも知ってますし、自分の経験から、うまく動作しないのは、プログラムの問題というより、自分の環境の場合もある、ってことを知っています。
なので、多少はやりやすいんですよね。
#というか、説明を納得してもらいやすい。(笑)
なので、こと対初心者ってことを謳うツールである場合、それらの環境差異への考慮とか、まずはきちんと動作すること、ってところを大量にテストしないと、なかなか初心者には使ってもらえないかも知れません。
初心者であればあるほど、動かないツールに対してこだわりがないので、ちょっと触って動かない、もしくは使い方が難しいと感じたら、すぐにそんなツールは捨ててしまいますから。
余談ですが。
ワタクシの認識では、α版というのは「機能テスト版」という位置づけです。
バグは残っているかも知れないけど、機能は全て実装されていて、動作はする(はず)。
というものです。動作には条件があるかも知れませんし、ユーザーの期待する動作とは違うかも知れませんが、開発側としては「機能は全て作った」状態です。
β版というのは、「機能評価版」となります。
正常系のテストは全て完了し、ほぼ期待通りの動作をするようになったものです。
細々したテストが終わってないため、リリース版ではありませんが、「ほぼ」リリース版と同じ機能/動作になったものをβ版と呼びます。
なので、α版は、まだ使えないこともあるけど、我慢してね、ですが、β版になると、「ほぼ使えるはずだけど、予想外のバグが残ってるかも知れません」ってことになります。
まあ、実装予定の機能が全て明かになってないと、なかなかα版、β版って切り分けが難しいかも知れません。
ま、余談です。(笑)
| 固定リンク
「日記・コラム・つぶやき」カテゴリの記事
- 嗚呼素晴らしきかなMMD(MikuMikuDance)(2019.08.16)
- 洗濯機が壊れた。(2015.03.17)
- ブログエディタが悩ましい(2014.06.01)
- ま、がらじゃないんだけど。(2014.04.30)
- 残念なお知らせ。(2014.04.28)
「Ubuntu」カテゴリの記事
- 萌え時計をGitHubに作成(2019.08.09)
- 萌え時計にスリムフレームテーマを追加(2019.08.08)
- 萌え時計(まだ続く(2019.08.08)
- 萌え時計のdebファイル作成(2019.08.02)
- KDENLIVEを使ってみた(2015.09.22)
この記事へのコメントは終了しました。


コメント
>本当に、何かさせようとした場合、多機能である必要は全然なくて、「目的が簡単に達成できる」ことが必要ということです。
>そして、それ以外の操作も機能も一切不要なんです。初心者には。
いや、これって初心者向けの話じゃないですよ。
元々、UNIXのプログラミングの方法論ってのは
「一つのプログラムには一つの機能を」
だったと思いますよ。色々やらせたければパイプで繋げてくれ、と(笑)。
多機能主義はむしろWindows文化とかそっちですよね。
Linuxプログラマも「Windowsスタイル」の人が増えてきた、と(笑)。
投稿: cametan | 2009年7月19日 (日) 00時30分
根本的にはそのネタ元の記事がつまんねえんだよな(笑)。
どーしてこーゆーカラーなのか(笑)。
投稿: cametan | 2009年7月19日 (日) 00時33分
↑あ、これ誤爆です。
こっち
Ubuntuって難しいんですか?
に対するレスですね。
投稿: cametan | 2009年7月19日 (日) 00時35分
>元々、UNIXのプログラミングの方法論ってのは
>「一つのプログラムには一つの機能を」
>だったと思いますよ。色々やらせたければパイプで繋げてくれ、と(笑)。
あ〜、それUnix文化だったのか。(笑)
ワタクシとしては、そっちの方が好みなんですけどね。
今はパイプの代わりにGUIのフロントエンドでつないでくれ、ですかねぇ。
ま、色々機能持たせたがるのがWindowsの文化ってのは間違いなさそうですが。
投稿: かおりん | 2009年7月19日 (日) 00時47分
んじゃ、誤爆了解で。(笑)
>どーしてこーゆーカラーなのか(笑)。
まあ、正直な話、あの対談形式は如何なものか、ってのは思ったところですが、中身はそれなりにマジメな話もあったので、それはそれで。
「楽しそう」ってよりも「ふざけてそう」に見えるのは、ちょっとね。
まあ、ムックでやってる分にはよかったのかな、と思ったけど。
って、別に雑誌の企画批判しても仕方ないので。(笑)
編集方針でしょうし。
投稿: かおりん | 2009年7月19日 (日) 00時50分
>あ〜、それUnix文化だったのか。(笑)
>ワタクシとしては、そっちの方が好みなんですけどね。
その模様ですね。
例えば、viなんかも元々vi「自体として」実装されてたんじゃなくって、ラインエディタのedとか組み合わせて作ってたと思います。
Windowsで言うAPIの塊がUNIXなんで、そう言う文化背景なんですよね、元々。
車輪の再発明はしない。実装する前に似たような機能が無いか/bin以下を探せ。パイプで組み合わせてシェルスクリプト化せよ。足りない部分をはじめてプログラミングせよ。みたいな。
この辺、絶版なっちゃったんですが、次の書籍が詳しいです。
UNIXという考え方—その設計思想と哲学:
http://www.amazon.co.jp/UNIX%E3%81%A8%E3%81%84%E3%81%86%E8%80%83%E3%81%88%E6%96%B9%E2%80%95%E3%81%9D%E3%81%AE%E8%A8%AD%E8%A8%88%E6%80%9D%E6%83%B3%E3%81%A8%E5%93%B2%E5%AD%A6-Mike-Gancarz/dp/4274064069
大変面白い本でした。
これに関連したエリック・レイモンドの本が以下の本です。
The Art of UNIX Programming:
http://www.amazon.co.jp/Art-UNIX-Programming-Eric-S-Raymond/dp/4756149480
バカ高いんで立ち読みしかしてないんですが(笑)、確か
「Cでプログラムを書く場合は100行程度で抑えろ」
とか書いてたように思います。多くても150行。それを越えると「危険信号」だそうです(笑)。
最近、また面白いエッセイ見つけて読んでたんですよ。以下のものです。
それじゃバージョン無限大だ。まずはバージョン0.1を立ち上げなよ。:
http://www.yamdas.org/column/technique/infinityj.html
こう言うのってUNIX文化に相通ずるものがありますね。最近やっとそう言う「重要性」が説かれるようになってきた、と言うか。
「多機能主義」って良くないんですよ。少なくともUNIXプラットフォームでは。
>ま、色々機能持たせたがるのがWindowsの文化ってのは間違いなさそうですが。
対するのが、まあ、Microsoftとは限らないんですが、MIT文化でしょうね。Emacsをはじめとする「キッチンシンクアプローチ」。とにかく何でもかんでもつっこもうとする、と言う。プログラミング言語としてはLispが最右翼でしょう。
X11とか、僕は中身見た事ないんですが、酷いそうですね(笑)。使わん引数とかダーッと並んでて(笑)。解読するのがシャレにならんそうです。X-WindowはMITの作品ですよね。
投稿: cametan | 2009年7月19日 (日) 01時20分
仕事の話でいいなら、よくするのが「理想は理想、現実は現実」って話をします。
それは自分の仕事のレベルであったり、これから設計するシステムであったり、実装するプログラムだったりします。
まずは理想型がないと、先が見えない、つまらないシステムになるので、理想は設計時に語るんですが、語るだけ語った後に、「じゃあ、今回はどれをやろうか」って話になるんですよね。
まずは、新システムなら、目玉は何か、ってことになります。
競合他社が作ってるシステムを再度作っても、あんまし意味ないので、ウチならではの部分を出していかないと、なかなかモノが売れません。(笑)
既存システムの場合には、どこに問題があるからエンハンスするのかを洗い出して、問題の重要度を決めた上で、今回エンハンスの目的は何か、から目玉を決めます。
理想を語らないと、次にどうして行くから、ここは拡張性を残しとこう、とか、今後捨てられるシステムなので、そんなに凝った実装は不要とか判断できないんですよね。
なので、常に「理想は理想、現実は現実」なんて話をしながら打ち合わせをします。(笑)
プログラム実装も、先に触れましたが、どこまでも綺麗で拡張性を持たせたエレガントなプログラムを書く「時間」があればいいんですが、大抵はないので、取るところと捨てるところを選んで実装します。まあ、これは機能は過不足なく実現するけど、先を見込んだ実装にするか、そこまでの捨て実装にするのか、ってことなんですけどね。
#捨て実装の方が簡単に済む。(笑)
まあ、バージョン無限大を読んで、そんなことやってるなあ、ってのを思い出しました。(笑)
#ま、ワタクシの場合、日常なんですけどね。
投稿: かおりん | 2009年7月19日 (日) 01時39分
捨て実装の方が意外と拡張性あったりしますしね(笑)。Perlなんかも元々「捨て実装」だったらしいですし。ただ、業務じゃそうはいかないのかな?
一つ、「UNIXの哲学」読んで良かったのは
「Cは大きなプログラムを書く言語じゃない」
ってのが分かった事ですかね。やっぱりシステム・プログラミング用であって、アプリケーション製作用じゃないんだ、と。どう考えても複雑なプログラムが書けるように出来てませんし。
可変長のリストが無いようなプログラミング言語、ってキツいですよ。そもそもUNIXでは「Cを直接使わなくても良いように」ユーティリティが装備されてんだな、ってのが良く分かりました。
そう言う意味ではCを「アプリケーション製作用」にしたWindowsの罪って大きいな、と(笑)。これで多くのプログラマがデスマにハマったのでは、と(笑)。
もっともコンピュータの能力が長い間貧弱だったんで、UNIX登場から30年以上も経ってから「はじめて」UNIX哲学が行使出来るような環境が整った、って事かもしれませんね。
投稿: cametan | 2009年7月19日 (日) 01時59分
捨て実装したとこは、たぶん、2度と使わないです。(^^;
まあ、たぶん想像以上に汚い実装だと思ってください。
#ビジネスロジック依存の場合多いし。
ん〜開発規模と言語って、それほど依存関係がないような気がしますけどね。
ようはライブラリが揃ってるか否か、だけだと思うんですよ。
言語仕様上は大差ないし。
まあ、オブジェクト指向化された言語の方が分割開発がラクってのはあるかも知れませんが、C言語だから隠蔽して抽象化出来ないか、というとそんなこともないので。
あんまし、言語仕様レベルで規模考えたことないですね。
せいぜいライブラリがこの辺は揃ってる、揃ってない、って程度で、自前で作る必要があるのが、どんくらいか、って程度で。
まあ、業務だと、どうしても工数削減が命題になるので、今時Cで開発なんてほとんどありませんけど。(笑)
#.NETかJavaかってところでしょうかねぇ。
投稿: かおりん | 2009年7月19日 (日) 02時25分
>まあ、たぶん想像以上に汚い実装だと思ってください。
あ、Perlのコアの部分っていまだ「汚い」模様ですよ(笑)。
プロトタイプ時代のものがいまだ残っているらしいです。
Rubyなんかもそうみたいですね。Matz氏がeval書き直したいんだけど、下手に直せば動かなくなる、とかどっかに書いてました(笑)。
>ん〜開発規模と言語って、それほど依存関係がないような気がしますけどね。
ええと、こう言う研究結果があるそうです。
http://web.archive.org/web/20070925010151/http://www.erlang.se/publications/Ulf_Wiger.pdf
これによると、
ソフトウェア開発の全ての段階において使用言語(Erlang, PLEX, C, C++, Java)の如何にかかわらず、時間当たりの開発行数は似たような数値となった。言語間の差が出たのはソースコードの量だった。
だそうです。
>ようはライブラリが揃ってるか否か、だけだと思うんですよ。
それは言えますよね。ライブラリさえあればかなり短縮出来ます。
>言語仕様上は大差ないし。
ちなみに、Common Lisp 第二版だと電話帳くらいの厚さがありますよ(笑)。
Common Lisp the Language, 2nd Edition:
http://www.supelec.fr/docs/cltl/cltl2.html
これ全部読まなければならないのなら泣きそうになります(爆)。
日本語版が共立出版の方から出ていて、買いたいんですが高い(笑)。1,000ページ近くあってどうしようか、って感じです。
COMMON LISP 第2版:
http://www.kyoritsu-pub.co.jp/bookhtml/0306/002437.html
逆に、Schemeの仕様書、R5RSなら50頁程、ですよね。
R5RS:
http://www.sci.u-toyama.ac.jp/~iwao/Scheme/r5rsj/html/r5rsj_toc.html
もっとも最新版のR6RSだと200頁近くに膨れ上がっています。
R6RS:
http://practical-scheme.net/wiliki/wiliki.cgi?R6RS:翻訳:R6RS
今、これでコミュニティが分裂してるんですよね(笑)。実装が分かれそうになっています。
>、業務だと、どうしても工数削減が命題になるので、今時Cで開発なんてほとんどありませんけど。(笑)
>#.NETかJavaかってところでしょうかねぇ。
でしょうねえ。
Java強いな、やっぱ(笑)。
投稿: cametan | 2009年7月19日 (日) 03時14分
言語仕様上大差ない、ってのは、言語が変わっても、言語レベルでできることには大差がないって意図でした。
例えば、ライブラリがほとんどない状態で実装しなければならないとすると、発生するソースコードの量には大差がなくなるはず、ってことです。
今、開発の現場で、ソースコードの量に差が出てくるのは、最初からどういうライブラリが揃ってるか、ってことに尽きると思います。
なので、開発工数も、ライブラリ依存かなぁ、と。
よく、Javaの方がCよりも開発工数が少ない、なんて話をされますが、それはJavaの方が便利なクラスライブラリが多いでしょ、という差でしかない、とワタクシは考えてますけどね。
あとは開発者の言語への習熟度ですが、それ言っちゃうと、個人のスキルレベルに落ちちゃうので。
投稿: かおりん | 2009年7月19日 (日) 04時59分
>言語仕様上大差ない、ってのは、言語が変わっても、言語レベルでできることには大差がないって意図でした。
ああ、チューリング完全、って意味ですね。
>例えば、ライブラリがほとんどない状態で実装しなければならないとすると、発生するソースコードの量には大差がなくなるはず、ってことです。
ちなみにCommon Lispの仕様書1,000頁近く、ってのはライブラリは含まれていません。
本当に「言語仕様」なんです。つまり、1,000ページ分実装しないと「Common Lisp」って呼べないんですよ(笑)。
つまり、ライブラリがほとんどない状態で、と言っても、極端な例ですが「差が出るだろう」と言う例ですね。
ちなみに、あれはPre-ANSIなんですが、ANSI Common Lispだとオブジェクト指向も含まれているんで、仕様書は1,000頁突破します。
まあ、そう言う極端言語もある、と言う例です(笑)。
>なので、開発工数も、ライブラリ依存かなぁ、と。
逆に言うと、現代で必要だ、って思われているライブラリなんてのはCommon Lispは欠けてますよね。
色々考えると賛成ですよね。
>よく、Javaの方がCよりも開発工数が少ない、なんて話をされますが、それはJavaの方が便利なクラスライブラリが多いでしょ、という差でしかない、とワタクシは考えてますけどね。
その辺、SUNが上手いんですよね(笑)。
ただ、素で比較すると、「書く量」はCの方が少ないんじゃないかなあ。
本当はJavaを比較すべき対象はC++なんでしょうけどね。Javaは「改良版C++」を狙ってたわけですから。
JavaがC++より「良く」なってないと、結果ハイプだけ、って事になっちゃうでしょうねえ。
投稿: cametan | 2009年7月19日 (日) 05時55分
結構、現場では、C++って嫌われてますね。(笑)
まだCの方がいい、なんて人もいます。
もちろん、そういうひとはJavaなんて知らん、と言い切る猛者だったりしますけど。(爆)
まあ、今のワタクシの業務だと、Java知らん、C#知らん、は通用しなかったりしますけど。
#それはそれとして、C/C++使いは貴重だったり。
投稿: かおりん | 2009年7月19日 (日) 12時48分
>結構、現場では、C++って嫌われてますね。(笑)
正直、あんまC++っていい話聞きませんよね。
次のような批判もあります。
バベル案内:
http://www.aoky.net/articles/steve_yegge/tour_de_babel.htm
また、C++ の作者、Bjarne Stroustrup氏自身が書いたジョークもある模様で。
Bjarne Stroustrup Interview about C++ :
http://hp.vector.co.jp/authors/VA000092/jokes/strup.html
これって冗談なんですけど、一方、純粋に「批判されている」事自体は用いてるんでしょうね。すごく正攻法の自虐ギャグと言うか(笑)。
投稿: cametan | 2009年7月19日 (日) 13時29分
ジョークとしての出来は判断しかねますが。(^^;
実際、CからC++へ移行しようとしていた時には、Cの方がC++よりも実行速度に優れていました。
今は大差ないです。CPUが速くなって、メモリも潤沢なので。
継承は使いたい、でも使うと遅くなる、というジレンマに悩まされたことがあります。(笑)
まあ、昔話ですけどね。今はコンパイラも進歩していますし。(多分)
そもそもC++で実行が遅いようなら、JavaやC#なんてまともに実行できるはずがありません。
んでもねぇ。
ジョークに書かれていますが、結構設計に時間がかかるのも事実で、途中の設計変更のダメージが大きいのがオブジェクト指向の欠点だったりするんですよね。
ま、ジョークなんでしょうけど、同じ意味の批判があるのは事実ですね、確かに。
嫌いじゃないんですが。(笑)
批判があることも承知していますが。
ワタクシは、一番使い易いですけどね。(^^;
投稿: かおりん | 2009年7月19日 (日) 13時57分
>今は大差ないです。CPUが速くなって、メモリも潤沢なので。
でしょうねえ。
アレだけ重い、遅い、って言われ続けたCommon Lispでさえ、コンパイル済みコードだとC++と遜色無いマシン語生成してるんだから。
何だかんだ言って、コンピュータの歴史で一番頑張ったのはインテルだよなあ(笑)。
>結構設計に時間がかかるのも事実で、途中の設計変更のダメージが大きいのがオブジェクト指向の欠点だったりするんですよね。
何となくそれは分かります。関数型言語の文脈にいるとオブジェクト指向ってやっぱ謎だらけですしね。
Javaのinterfaceって何なんだ、とかつまらんトコで引っかかっています(爆)。
次はアスペクト指向が来る、とか言ってますよね。改善されんのかなあ。
と言うか、それ以前に「アスペクト指向」って何なのか全然分かってないんですけど(笑)。
>嫌いじゃないんですが。(笑)
>批判があることも承知していますが。
>ワタクシは、一番使い易いですけどね。(^^;
まあ、手慣れたヤツ使うのが一番ですよね。
と言うか、Windowsだと「コレじゃなきゃいけない」って圧力大きいですが、Linuxだとヘンな言語拾えるんで、プレッシャーが無いですよ(笑)。「何でも動くやん」とかなっちゃって(笑)。
う~~ん。Linxuの普及で一番得するのって実はその辺かもしれませんね。制限無く色々試せるんで、外圧がかかりにくい、と言うか。オープンソース開発自体も比較的気軽ですしょうしね。
何か昨日、Ozって言語見つけたんですよ。マルチパラダイム言語ですって。僕の感覚で言うとヘンな言語なんですけど、暫くこれ弄ってみよう、とか思っています。
投稿: cametan | 2009年7月19日 (日) 14時21分
ん〜結局のところ、仮想化と言うか隠蔽する技術方向に行ってるのは、どの言語も変わってないみたいなので、アスペクト指向とやらも、オブジェクト指向の上に乗っかって、補足する関係になるのかな、という感じですが。
まあ、確かに今のオブジェクト指向では、表現できない現実の仕組みなんてのもあるので、そこを補完するんじゃないんですかね。
言語に関して言えば、Linuxの自由さって、ある意味そこにあるのは事実ですよね。
大抵の言語が揃っているし、それでアプリケーションも書ける。
まあ、GUIを使おうってことになると、使える言語は限られてくるかも知れませんが、ライブラリが極力隙間を埋めようとしてくれるので、わりと自由ですよね。
投稿: かおりん | 2009年7月19日 (日) 15時52分