ファイラのすすめ

ファイルをコピーしたり、移動したり、削除したりするときにどうするだろうか？　Windows ユーザーの多くは、「エクスプローラ」を使うだろう（※１）。

しかし、ファイルの操作をするためのソフトウェアは、エクスプローラだけではない。「ファイラ」と呼ばれるジャンルのソフトは、それ以上の操作性と機能を提供してくれるものである。

今週の「IT」のトラックバックテーマは「おすすめフリーソフト情報」である。この機会に、「ファイラ」というソフトを使ったことのない人に、おすすめしたいと思う。

★
パソコンを効率的に操作するコツは、「なるべくマウスではなくキーボードを使う」ということである。また、マウスによるドラッグ等の操作には、ミスが起こりやすいという問題もある。

しかし、キーボードを主体でパソコンを使う場合、エクスプローラは必ずしも使いやすいソフトではない。マウスでの操作性を重視した設計であるため、キーボードでは効率的な操作ができないのだ。

そこで、ファイラというソフトを使うわけである。日本のファイラには、キーボードでの使い勝手を重視した、伝統的な操作方法がある。

その方法を広めたのは、A.Idei 氏が作成した「FD 」という MS-DOS 用のファイラである。

FD は、画面に１つのフォルダ（ディレクトリ）の中にあるファイルの名前を一覧表示する。ユーザーは、その中からいくつかのファイルを選んで、１つのキーを押す。例えば、コピーしたければ「C」、移動したければ「M」、削除したければ「D」といったキーを押すことになる。コピー先や移動先のフォルダは、キーを押した後に開いたダイアログで入力する。

実際に使ってみると分かるが、このシンプルな操作方法は非常に効率的である（※２）。Windows 全盛期となった今では、特殊な操作方法のようになってしまったが、慣れてしまえば、手放せない魅力がある。

現在の Windows 用のファイラにも、この「FD 方式」の操作方法を採用しているものが幾つもあるので、そうしたものの中から選ぶことをおすすめする。

★
ファイラを使うメリットは、キーボードによる操作性の向上だけではない。

多くのファイラは、ファイル操作だけでなく、様々な付加的な機能を持つものが多い。例えば、テキストファイルの内容表示、バイナリファイルのダンプ、ファイルの圧縮や解凍、画像の表示、音楽の再生、FTP クライアント機能などである。

それぞれの機能だけ見れば、専用のソフトほど多機能というわけにはいかないが、平素の利用には十分である。

むしろ、いくつもソフトを立ち上げて、ウインドウを切り替えながら使うよりも、ひとつのファイラだけで処理できたほうが、効率的な場合が多い。特に、FD 系のファイラなら、こうした付加機能も、なるべく「１つのキー」で操作できるようになっているのである。

ファイラを選ぶ場合には、どのような付加的な機能があるかということも、考慮するといいだろう。

★
プログラマに限らず、パソコンを使って働く者は、ファイル操作のような頻繁に行う作業の効率化を考えるべきである。例えば、いくらタイピングが速くなっても、それはパソコン操作の中の一部でしかない。その他の操作が遅ければ、作業の効率化にも限界があるということだ。

良いファイラと出会うことができれば、そうした限界を飛び越えることが出来るだろう。

Vector などを探せば、無料で使えるものが沢山ある。なるべく多くのものを使ってみて、自分に合ったものを探すといいだろう（※３）。

クリックお願いします →

※１
例えば、「マイコンピュータから何かのフォルダを開き、アイコンをデスクトップにドラッグする」といった操作も、エクスプローラを使っていることになる。エクスプローラは、Windows という OS の目に見える部分を管理するソフト（ビジュアル・シェル）である。つまり、Windows の一部であり、あまりにも当たり前に存在している。このため、ファイルを操作しようとする場合に、他の手段を探そうという人も少ないのだろう。

※２
FD が生まれた頃のパソコンにはマウスが付属していないのが普通で、ほとんどのソフトがキーボードで操作するように出来ていた。キーボードによる操作が効率的なのは当然ではある。

※３
参考までに私のお奨めを書くならば、「だいなファイラー (DYNA) 」、「あふ (Afx) 」、「Double Window 」、「wiro the file manager 」といった「２画面ファイラ」である。

普通の「１画面」のファイラでは、ファイルのコピーや移動の際は、キーを押した後でコピー先や移動先のフォルダを指定する必要がある。しかし、２画面ファイラでは、「元」と「先」のフォルダを同時に開くことができ、キー押下１つでコピーや移動を行うことができ、更に効率的なのである。

■関連記事
・メモ帳でプログラミング？
・コマンドラインのすすめ

そんなパソコンファイルでは仕事ができない!

posted with amazlet on 06.05.04

鐸木能光
青春出版社 (2005/04)
売り上げランキング: 46,453

おすすめ度の平均:

良いですよ！

Amazon.co.jp で詳細を見る

パソコンは買ったまま使うな!―フリーソフトで作る快適環境―

posted with amazlet on 06.05.07

鐸木能光
岩波書店 (2003/10/08)
売り上げランキング: 25,359

おすすめ度の平均:

マイクロソフトの反乱の勧めか？！

パソコンの基礎を知るにもいい本です。

より良いフリーソフトが厳選

Amazon.co.jp で詳細を見る

直す不幸、直せない不幸

システム開発の工程中には、沢山の人手が必要になる時期と、そうでない時期がある。忙しいときには、多くのプログラマが動員される。しかし、ピークを過ぎれば、彼らは徐々に開放される。

このため、後からバグが見つかった場合、問題の箇所を作ったプログラマがプロジェクトに残っていない、ということがよくある。そんなときには、残っている他のメンバーが修正を行うことになる。

バグを生むプログラムには、作り方がマズいものが多い。そんなプログラムの修正を任せられたプログラマは不幸である。「なんでこんな作り方をしてるんだ！」などと、悪態をつきながら対応することになるだろう。

★
しかし、本当に不幸なのは、問題のプログラムを作った本人である。

彼は既にプロジェクトを抜けてしまっているので、自分の書いたプログラムに問題があったことすら知らない。つまり、反省の機会も改善の機会も与えられないのである。

人間は過ちをしながら成長していく。特に、プログラマという職業には、そういった側面が強い。自分の過ちを知ることができないということは、彼にとって、大きな損失である。

また、そのような「作り逃げ」のような仕事しか与えてもらえなければ、仕事に対する責任感も育たないだろう。

★
プロジェクトを去った人間に、不具合のひとつひとつを通知せよ、とまでは言わない。しかし、あまりにも問題が多く出るようであれば（そして、彼が自社の社員であるならば）、管理者は何か手を打ったほうがよいだろう。再教育するとか、サポートする人間を付けるといったことである。

さもなくば、彼の行くところ、延々とバグが発生し続けることになるだろう。

応援のクリックお願いします →

■関連記事
・プログラマの出向事情

課題・仕様・設計―不幸なシステム開発を救うシンプルな法則

posted with amazlet on 06.05.07

酒匂寛
インプレスネットビジネスカンパニー (2003/11)
売り上げランキング: 83,247

おすすめ度の平均:

課題・仕様・設計の３つの視点と成果物を解説

課題を正しく理解しないと

Amazon.co.jp で詳細を見る

プログラムの育てかた現場で使えるリファクタリング入門

posted with amazlet on 06.05.07

長谷川裕一斎川博史
ソフトバンククリエイティブ (2005/02/01)
売り上げランキング: 176,298

おすすめ度の平均:

リファクタリングについて楽しく学べる

入門書として最適

初心者向けなのに初心者には見せられない・・・

Amazon.co.jp で詳細を見る

真夜中のコード

真夜中に書いたラブレターを、翌朝自分で読み返すと、恥ずかしくて相手に渡せない、という話がある。

強い思い入れで書いた文章は、あらためて客観的に見ると、表現が行き過ぎていたり、非常識だったりするということだろう。

プログラミングでも同じことがいえる。

勢いに乗って書き上げたソースコードを後から読み返してみると、ケアレスミスが見つかったり、もっと良い書き方を思いついたりするものである。

プログラマも人間であるから、思い込みから間違った仕様で作ってしてしまうこともある。盲点、死角ができてしまって、矛盾が生じてしまうこともある。

★
プロジェクトによっては、こうしたミスを減らすために、出来上がったコードを他者が読んでチェック（レビュー）することがある。実際、レビューの中で、ちょっと読めば見つかるような単純なミスが見つかることも少なくない。

しかし、本来なら、そうした単純なミスは、プログラマが自分で見つけるべきものである。

そのためには、自分の書いたコードを客観的に読むための工夫が必要だろう。
例えば、「真夜中のラブレター」の話のように、コードを書いた後にある程度の時間をおけば、客観性を取り戻すことができる。毎朝、仕事を始める時に、前日書いたソースコードチェックする、といった方法もあるだろう。

あるいは、コードを印刷して読み返すのも有効だ（※１）。画面上で気がつかなかった問題点が、紙の上で発見されるということはよくある。一度に目に入るコードの範囲が広くなるからだろうか？　あるいは、やはり紙の方が落ち着いて読めるということかもしれない。

他には、編集前のコードと編集後のコードを比較して、修正内容を確認する、といった方法もお勧めである。ピンポイントでチェックできるため、全体を読み直すよりも効率的である。この場合、比較ツールを使って、差分を抽出することになる（※２）。

★
このように、「ソースコードを読み返す」というだけでも、色々な工夫ができる。

コードを書き終わり、コンパイルが通ったからといって、プログラミングが完了したわけではない。書いたものをどのようにチェックすればミスが少なくなるのか、ということを考えるのも、プログラマの大切な仕事のひとつである。

※１
印刷コストや森林資源についての心配もあるが、いわゆる「裏紙」を使ったり、FinePrint などの印刷ツールを使でば、少しは気が楽になるだろう。なお、ソースコード印刷の際には、行番号の出力をお忘れなく。

※２
例えば、VSS のようなものでソース管理を行っているのであれば、編集結果の登録（チェックイン）を行う前に、サーバー上のソースと差分を確認するような習慣をつけるとよいだろう。

■関連記事
・プログラムは二度書け

真夜中のパソコン相談室―いまさらこんなこと誰にも聞けない!

posted with amazlet on 06.05.07

唯野司
技術評論社 (2006/01)

Amazon.co.jp で詳細を見る

Code Reading―オープンソースから学ぶソフトウェア開発技法

posted with amazlet on 06.05.07

トップスタジオまつもとゆきひろ平林俊一鵜飼文敏
毎日コミュニケーションズ (2004/06/01)
売り上げランキング: 30,286

おすすめ度の平均:

ホップ・ステップ・ジャンプ

例題がわかりにくい

サブタイトルの方が適切？

Amazon.co.jp で詳細を見る

バグを求めるものたち　後編

テスト工程の品質を、テスト項目数やバグ件数のような「量的」な指標だけで把握することには限界がある。

プログラムの規模などから、どのくらいのテスト項目数が必要なのか、どのくらいバグが発見されるのか、といったことは、ある程度は想定できるかもしれない。

しかし、そうした量的な指標が有効なのは、開発するシステムの種類や特徴、プロジェクトチームのスキルなどが、安定している場合だけであろう。例えば、同じ開発メンバーが同じようなシステムを作る場合には、有効かもしれない。

逆に言えば、どんなプロジェクトにでも通用するような、量的基準を作ることは難しい。例えば、テスト項目数が基準値を満たしていても、テスト観点に抜け漏れがあれば、何の意味もない。

★
当たり前の話ではあるが、テスト工程の「品質」を正しく把握するためには「質的な」評価が必要である。

テストを行うに際に大切なのは、テスト項目の数ではない。テストの観点に偏りや抜け漏れがないか、ということである。それを確認するためには、テスト項目の内容を詳細にチェックしなければならない。

また、発生したバグについても、ただ件数を数えるだけではなく、内容まで分析しなければ意味がない。例えば、結合テストで10件のバグが見つかったとしよう。数字だけしか見なければ、ただそれだけの話である。しかし、内容まで調べれば、そのうち９件が「単体テストで見つけておくべきバグ」であることが分かったりする。このように、質的に意味のあるレベルまで分析しなければ、数値の意味はない。

★
量的な評価が、テスト項目の数を数えるだけでできるのに対し、質的な評価をするには、非常に多くの手間が掛かる。

しかし、だからといって、量的な指標を絶対視し、それだけでテストの品質を決めつけてよいというものではない。

管理者が恐れるべきは、「管理しているつもりになること」である。数値を測定し、表やグラフを作れば、なんとなく管理をしている気分になってしまう。しかし、質的に意味のない数値は、いくら集めても役に立たない。

そうした実のない管理方法が最悪の結果として現れるのは、抗いがたい権力をもって、開発者に「量的なノルマ」を課した時である。

前編、中編に書いたような弊害は、その例である。

ここで、「バグが出ないこと」に悩まされていたプロジェクトマネージャは、顧客に虚偽のバグ数を報告をすることもできたはずだ。それをさせなかったのは、彼の人としてのモラルである。

しかし、この顧客が必要以上に「バグ数の要求」を続けるならば、いつか誰かが虚偽の報告をしないともかぎらない。

バグ数を増やすために故意に品質を下げるくらいなら、嘘をついたほうがマシだと考える開発者は必ずいる。

開発者にとって、「品質を上げる」ということは、それほど重要なものなのである。

※単体テストはひとつの機能（部品）のみのテストで、結合テストは複数の機能を組み合わせたテスト。当然、それぞれのテストは「観点」が違う。結合テストは、単体テストの後に行う。

■関連記事
・バグを求めるものたち　前編
・バグを求めるものたち　中編

ソフトウェアテスト技法
―自動化、品質保証、そしてバグの未然防止のために

posted with amazlet on 06.05.06

ボーリスバイザー
日経BP出版センター (1994/02)
売り上げランキング: 27,689

おすすめ度の平均:

ソフトウェアテストの基本となる２冊の本のうちの１冊

もっとも引用される本の一つ

Amazon.co.jp で詳細を見る

実践的ソフトウェア測定

posted with amazlet on 06.05.06

John McGarry Cheryl Jones Elizabeth Clark David Card Beth Layman 古山恒夫富野寿
構造計画研究所 (2004/07)
売り上げランキング: 60,076

おすすめ度の平均:

メトリクスの教科書として最適

Amazon.co.jp で詳細を見る

バグを求めるものたち　中編

プログラムのテスト工程において、「○○ステップあたり○○件の不具合が出なければならない」といった基準が設けられることがある。

それだけの数の不具合（バグ）がみつからないということは、テストが十分でないのだ、というわけである。

確かに、テストという工程だけをみれば、そのような判断も正しいのかもしれない。しかし、システム開発全体としてみれば、弊害もある。

伝統的なシステム開発では、テストの工程はプログラミングの工程の後に行われる。つまり、その場合、プログラミングが完了した時点で、一定数以上のバグが残っていなければならないということになってしまうのだ。

★
プログラミング完了時点でのバグをゼロにすることは、プログラマの目標のひとつである。彼らは、その目標を目指し、工夫、努力を続けている。前編で述べたような「動作確認」もそのひとつである。

このようなプログラマの努力によって、プログラミング工程での品質が上がれば、テスト工程で見つかるバグは少なくなるのは当然である。

しかし、そのような場合でも、発見されたバグの数だけで、テストの精度が評価されるような状況では、「テストが十分に行われていない」と判断されてしまうのである。

前編で登場したプロジェクトマネージャの「プログラミング中にプログラムを動かすな」という指示は、こうした背景から出てきたものであった。彼は、顧客から、テスト工程の完了条件として、「最低バグ数」を提示されていたのである。

彼は過去にこの「最低バグ数」をなかなかクリアできずに困ったことがあるという。今回も、テスト工程でのバグが少なくなってしまうことを心配し、そのような指示を出したのである。

★
彼は、「動作確認」をプログラミング工程で行うか、テスト工程で行うか、という違いを、それほど重要視していないのかもしれない。

確かに、テスト工程で抜け漏れのない 100% 完璧なテストを行えるのであれば、彼のようなやり方でも、最終的に完成したプログラムの品質が下がることはないだろう。

しかし、現実には、よほど単純なシステムでない限り、「完璧なテスト」を行うことは困難である。「プログラミング中の動作確認」を禁止すれば、当然、バグが見逃される可能性は高くなり、品質は下がるだろう。実際、プログラミング中でなければ気がつかないような「テスト観点」というのもある。

また、仮に「完璧なテスト」が行えるとしても、バグというものは見つかるのが早ければ早いほどよいものである。後の工程になるほど、バグを修正することよる影響範囲が広くなるし、本来は必要なかったはずの「再テスト」の手間も増えるからだ。

プログラミング中にバグを見つけられるチャンスがあるのに、それをわざわざ禁止して手間を増やし、更には品質を下げてしまうというようなやり方が、果たして正しいといえるだろうか？

続く

■関連記事
・バグを求めるものたち　前編
・バグを求めるものたち　後編