« 2005年6月 | トップページ | 2005年8月 »

2005/07/25

良い言語

突然だが今回は「良い」言語について考えてみようと思う。もちろん、ここでいう言語とは人間が普段使用しているものではなくプログラミング言語のことだ。

最初に言っておくとわたしは Java は良い言語だとは思っていない。友人は Java を賞賛しているが、実は普段は使っていなかったりするのだ。使いもしない言語を「良い言語」というかい?

閑話休題
個人的な事情は置いておこう。

確かに Java を使うことで生産性は高めることができる。ライブラリは優れたものがたくさんあるし、メモリ管理はプログラマが(それほど)気にしなくてもいいようになっている。言語の仕様により1クラスを1ファイルに書かなくてはならないのでよほど変なコーディングでもない限りはクラスの全体像をつかむのが楽だしUMLを使った全体像の理解の助けにもなるかもしれない。動作は JVM の上で走るので「安全」で、プラットフォーム依存のライブラリを使わなければ OSに関係なく、また機器に関係なく動作する。レベルもピンキリで、メンバーが開発工程の途中で入れ替わることもある企業では有効な選択肢だろう。

Java の生産性の高さは認めるが、それでもわたしは「Java が良い言語だ」とは思えないのだ。生産性の高さと、良い言語であることはまた別のものだと思っている。わたしは「良い言語」はプログラマを束縛するべきではないと思っている。自由度が高く、軽量で、簡潔な文法を持つこと。そして、(たとえ入門PGだったとしても)プログラマの創造力を刺激することが「良い言語」の絶対条件だ。このうちのどれかひとつでも欠けていたらそれは「良い言語」ではない。

Java は自由度が低く、また重い言語だ。
Eclipse の起動を見てみたまえ。重いと定評のある Adobe 社の Photoshop よりも時間がかかるではないか。あんなものは使う気にもならない。動作が鈍いプログラムはそれだけで、その存在そのものが大罪なのだ。メモリの消費量もプログラムの機能に対して多すぎる気がする。昨今のPCは確かにメモリの搭載量が増えているが、それでも普及価格帯のPCは256MB程度しかない。また、メモリの消費量は少ないほうがいいに決まっている。 10年前のように、goto文やらを駆使してスパゲティコードに仕立て上げてまでメモリを節約しろとはいわないが、消費量の少ない成果物を作成する言語があるならそちらを使うべきじゃないかい?

Java の自由度が低いと聞いて、首を傾げたかもしれない。しかし、ほかの言語と比べると Java の自由度が低いのは事実なのだ。 Java はプログラマが愚かな行いをしないように制限を加える。しかし、どんなコードが愚かでどんなコードが優れたものなのかそんなにはっきりとわかるものなのかい?確かに「とんでもない」動作をしてくれるコードは存在する。しかし、一見愚かに見えても動作させたら素晴らしい結果を見せてくれるものがあるのも事実である。そもそも、新しいモノを作り出そうとしているプログラマが必要とするであろうことと、彼がどんなことでミスを犯すのかをどうやって言語設計者が事前に知ることができようか。

いくら言語でミスを防ごうとしても、ミスを犯す者は侵すのだ。(マーフィーの法則を読んでみよう)参照先のミスを減らすことはできるかもしれないが、拙いプログラマが下手糞な設計をしてしまうことを修正することはできない。(これは言語の設計よりも、経験と技量が左右するものだろう?)ならばプログラマの動きを縛り付ける不要なルールなどないほうがいい。

セオリーどおりに作れだとか、Javaのルールではこうなのだとかそんなことを押し付けられて新しいアイディアが浮かぶとは思えない。新しいアイディア、素晴らしいコードは自由な発想から生み出されるのだ。言語はプログラマを束縛するべきではない。
わたしは Java のような B&D(bondage and discipline)言語がいい言語だとはおもえないのだ。良い言語はプログラマを縛り付けるものではなくて、粘土のように自由に形を変えてプログラマの創造力を刺激するものだと思う。

良い言語は、文法はシンプルで成果物の動作は軽快で何よりプログラマの創造力を邪魔しないものでなくてはならないのだ。 C言語がこれに当たる。恐らくLispやPerlもこちら側の言語だろう。いい言語は時に誰もが驚くようなコードを書けて、えらそうに講釈を垂れるスーツ族が頭を抱えるようなことができるくらいに柔軟性を持っていなければダメだ。この真逆に存在するのが Java などの言語で、これは初期教育や、多くのメンバーが集まった開発には向いているがあくまでも「生産性の高い言語」なのだ。プログラマの創造力を助け、成長させることは到底できない。

| | コメント (0) | トラックバック (0)

2005/07/18

Excel Hacks !

参照:http://www.oreilly.co.jp/books/4873112052/

MS-Excel 柔軟性が高い多機能なソフトウェアだ。 表計算はもちろん、表計算ソフトとは思えないこともできる。 恐らく、事務系に限らず、PCを使ったことがあるユーザなら 一度は使ったことがあるのではないだろうか?

Excelは多機能で、これは多くのユーザの要望に応えられるということだが 欠点もある。それは多機能すぎてどの機能を使ったらいいのかわかりにくい ことと、目的の機能を探すのが大変なことだ。また、Excelを使いこなすには VBAの知識が必須だ。たとえば、ファイルAとBの値を比較して条件によって 特定のセルの値を第3のファイルCに書き出すといった処理は、Excelの 標準関数だけでは実現できない。しかもそれぞれのファイルの Worksheetは2000行はあると仮定してほしい。 こういった処理は手動で行うとなると 単純作業の繰り返しで大抵はウンザリするものだ。 しかし、キチンと設計されたブックでVBAが組めるのであれば すぐに終わらせることができる。事実、わたしは上司から「1週間」といわれて アサインされた仕事を4時間で終わらせたことがある。

VBA は VisualBasic6をベースにしているので、その知識があれば 応用することで組み上げられるがない場合は自力で組み上げるのは いささか厳しい。また、あったとしても自分では思いつかないこともある。 「こんな使い方ができたらもっと便利なのに」とか 「冗長な処理をワンアクションでできないだろうか」と思ったことは 少なからずあるだろう。そんな助けになってくれるのが Oreillyから出版されている "Excel Hacks" だ。

右クリックメニューでシートを移動できるようにするには?
ピボットテーブルってどう使うの?
可変長のセル範囲ってどう作るの?
フィルタオプションの効果的な使い方は?
などなど、知っていると便利なさまざまな方法が紹介されている。
今すぐは使わないものでも知っていると役に立つ場面がくるかもしれない。
興味を持った方は是非読んでほしい。

最後に、いうまでもないことだが、書式の統一などの設計はとても大切なものだ。 「アルファベット・数字は必ず半角で入力する」だけでも統一されているのといないのでは 再利用性が大きく異なる。Excel でファイルを作るときは再利用性も考えた設計をしよう。

| | コメント (0) | トラックバック (0)

Skypeを導入してみよう(2)

Skypeを企業などで使用する場合、 ユーザの自由に任せるわけにも行かないのが現実である。 見知らぬ人からコールに応えてしまい、 そのまま業務時間中にチャットでお遊びとならないように Skype の導入に当たってはコンプライアンス教育と ポリシーを明確に定めておくことが必要だ。 例を挙げると下のようなものがある。

  1. 私用厳禁
  2. 使用してよい機能を明文化する
  3. ファイル送信機能は使用禁止
  4. リストは管理者が管理。個人で編集させない
  5. ログファイルは暗号化フォルダに保存する
  6. 違反者への罰則を明確にする
  7. 用途ごとのフォーマット(書式)を決めておく

7は前回のとおり。あらかじめメッセージ形式を決めておくことで記入漏れなどが防げる。1~4は Skype に対応した管理ツールが発売されているのでそれを利用するといいと思う。 どの機能をどの程度制限するのか判断するのは難しいことだ。 たとえば、ネットワークをどう構築するかについて話し合うときは ネットワーク図が必要になるがこれをAAで表現するのはかなり難しい。 このときファイル送信機能が使えるのであれば、 Visio などで作成したファイルを送信することで よりスムーズに話を進められるだろう。 どの機能を制限するかは十分に考慮するべきだ。

Skype の機能を制限して許可した機能のみ使用するように管理するソフトとしてはゼッタテクノロジーが販売する PCSK2 がある。このソフトでは上記項目の1,3,4 を実現できる。
参照:PCSK2 for Skype
企業で有用な機能としてコンタクトリストのインポートや追加、コンタクト送信、ユーザの検索の制限がある。管理者側でリストを作成してそれを部署のユーザに配布すれば業務に必要な相手には連絡が取れるがそうでない望まないユーザへの接続は禁止することができる。また、通話記録の削除も禁止できるので誰と通話を行ったのかがわかる。詳細は開発元の資料を参考にしてほしい。体験版も公開されているので参考になるだろう。

適切に運用すればリスクを抑えてメリットを享受することもできる。防げるリスクを過度に恐れて全てを禁止するのではなく適切に運用することを考えてはどうだろうか?少なくとも、Skypeによって得られる利益は大きいだろう。

| | コメント (0) | トラックバック (0)

2005/07/16

Skype を導入してみよう

企業では Skype の導入にあまり積極的ではないという話を聞いた。 Skype はファイル送信機能も備えるし、誰とでもメッセージをやり取りできるので 情報が簡単に漏洩してしまうといったことを理由に管理者がGOサインを出さないらしい。 これはおそらく事実だ。何も対策をしなければ悪意を持ったユーザや ホームユースと業務ユースの区別がつけられないKidding Workerから漏洩することもあるだろう。 しかし、何も対策をしなければ漏洩のリスクがあるということは、 裏を返せばきちんと管理すれば防げるということでもある。
加えて、Skypeを使うことで得られるメリットも大きい。

危険があると小耳に挟んだからといって即座に全否定するのではなく、 どのような危険があるのかを知り、どうしたらそれを回避できるか を考えた上で使用したと仮定してどれだけのメリットを得られるのか を考えて判断すればいいのではないだろうか?
実際、わたしたちは E-mail は容易に盗聴されることを知りながら 業務連絡やWebショッピング、オークションに利用している。 なかには、E-mail でパスワードを送りつけるツワモノもいるくらいだ。 (E-mailは通常平文のままネットワークを流れる。これはハブによる シェアードネットワークの場合プロミスキャスモードで 動作させれば同一リンク上のメールすべてを盗聴できることを意味する。 L2スイッチネットワークでもArpキャッシュを溢れさせることで盗聴できる。) パスワードを送りつけるのは論外として、 わたしたちが業務連絡などでE-mailを頻繁に使用しているのは リスク以上にメリットが大きいと考えているからではなかろうか?

Skype のメリットとはなんだろうか?
最初に挙げられるのは、導入が簡単だということだ。技術的に簡単だというだけでなく、 コストがほとんど必要ないという金銭面における簡便さもある。 必要なものといえばヘッドホンマイクくらいのものだが、 音声通話が不要だというのであればこれも必要ない。誤解されることが多いのだが PC-to-PC の通話であれば Skype は無料だ。日中だろうが夜間だろうが 何時間会話していても無料。別途サービス料金が必要なのは「一般電話」と通話するときである。
さらに、Skype の音声通話は5人まで同時参加が可能で、いわゆる 「電話会議(ボイスカンファレンス)」も行えるが PC-to-PC ならこれも無料だ。 今までも多人数参加の電話会議はできないこともなかったが、そのためには電話会社に 高い料金を支払う必要があり「試しに導入してみよう」という試験運用も気軽には行えなかった。 しかし、繰り返しになるが Skype は無料である。試しに導入してみて 効果的ではないと思ったらやめればいい。費用はほとんどかからない。

Skype では多人数同時参加の文字によるメッセージのやり取り、チャット会議もできる。 参加人数は最大で48人だから、1部署であれば全員が参加できるだろう。 ログも保存することができるので、誰が何を発言したかということもしっかりと記録される。 会議の内容はログを見ればわかるので、新人が議事録を取ることに追われて発言できない といった事態も防げる。

通信上のセキュリティも考慮されている。 Skype では通信内容は AES によって暗号化される。 このため、途中経路で盗聴されても内容を解読される危険性は低いと考えられる。 少なくとも、E-mail で業務連絡やパスワードを送りつけたり、 周りに人がいるにもかかわらず電話でパスワードを読み上げるよりも安全だろう。

Skype は会議などの特別な状況だけでなく日常の業務も改善してくれるだろう。 あなたは取引先に連絡をしたいとき、あるいは出張先などから上司に連絡を入れたいとき どうしているだろうか?
代表窓口に電話→内線で取り次いでもらう→でもいなかった→がっくり_| ̄|○il|!
という経験がないだろうか?あるいは
離籍中に電話が来たらしい→メモがある→汚くて字が読めない→ショボーン( ´・ω・`)
という経験がないだろうか? Skype はこんな苦労からも開放してくれる可能性を持っているのだ。 Skype は相手のオンライン状態を確認することができる。 また、表示名も変更することができる。これらから相手の状態を確認して 離籍中や会議中のときは簡単な「内容を確認しましたら折り返し連絡をください」 と一言添えてIMやメールを送っておくといった対応もできるだろう。 緊急のときは、大至急連絡を取りたい旨をを窓口に伝えて取り次いでもらうこともできる。 出張中となっていたときは携帯電話に繋げばいいとわかる。 相手の状態に合わせた適切な選択が行えるのだ。

また、IMと音声通話を合わせて迅速かつ正確な連絡ができることも魅力だ。 人間の記憶はいい加減なものだし、それゆえに間違いや錯覚を起こしてしまう。 電話ではその頻度が高くなる。特殊記号や聞き分けにくいアルファベット ( % とか ~(チルダ), D と T など)が入った URL や E-mail アドレスを音声のみでやりとりするのは骨が折れる作業だ。 掛け手受け手、双方にとって面倒な作業だろう。 このようなものは文字で伝えたほうが双方にとって遥かに楽だし、何より正確だ。
発注や障害報告などでも後述のような書式のIMを送り、 それとともに音声通信で相手に一言確認を入れる。 相手にはすでにメモ(送られてきたIM)があるのでそれを元に正確で迅速な処理ができる。 手続きが迅速に行われれば、当然人員や物資は すばやく発注側に届くわけで双方にとって大きなメリットだ。
つまり、電話は相手にすぐに繋がる(かもしれない)が聞き間違えがあるかもしれない。 メールは正確だがいつ確認してもらえるかわからないというデメリットがある。 Skype の IM と音声通信を併用することで双方のデメリットを解消し 両方のメリットを享受できることになるのだ。

業務にSkypeを組み込むに当たっては、 よく使う連絡文書の書式を決めて、テンプレートを作っておくと便利だ。 こうすることで情報が抜けていないか確認できるし、 メッセージを受け取った相手もその処理が楽になる。 例を挙げると次のようなものだ。

障害報告

  • 日付
  • 所属部署
  • 氏名
  • 障害が起きた機器の名前
  • 症状
  • 他のマシンでも起こるのか(再現性はあるか)
作業依頼書

  • 日付
  • 依頼者所属部署/氏名
  • 作業内容
  • 希望日時
作業完了報告書

  • 日時
  • 業務番号
  • 責任者所属部署/氏名
  • 連絡事項(トラブルなどの有無)
発注書

  • 日付
  • 所属部署/氏名
  • 注文品名
  • 個数
  • 使用目的
有給休暇願い

  • 提出日時
  • 所属部署
  • 氏名
  • 希望日・日数
  • 理由

いうまでもなく情報の伝達は早く正確なほうがいい。 この目的が達成できるツールがあるのなら(しかもコストは非常に低い) 試験運用をおこなってみるのもいいのではなかろうか? とはいえ、ユーザの自由にさせるわけにはいかないのが現実である。次はSkypeを導入した後の管理について書こうと思う。

| | コメント (0) | トラックバック (0)

2005/07/10

GUI の進化

MacユーザがWindowsのGUI を見てMacのパクリだとか言っているがそれは正しくないと思う。もしもそうならばLinuxの一部のディストリビューションはWindowsのパクリ、つまりMacの孫パクリということになってしまう。しかし、現実にLinuxのGUI はWindows なり Mac のパクリだという話は聞いたことがない。結局はマッカーの僻みなのだろう。
しかし、GUI が似ていると感じることは事実である。GUI の発展が遅れていた(6年前のことだ)Linux も今ではGUI が発展してWindows と似ているなと感じることがある。これは所謂パクリなのだろうか?いや、わたしは違うと思う。

たしかに、近年はOSのUI(User Interface)はどれもGUI を発展させてきたし、似たような雰囲気もある。しかし、「一見すると似ているように見える」だけで、本質は変わっていない。それぞれのOSは、それぞれが持っていた特徴を依然として残している。たとえばWindows2000とWindows98はとても似通ったGUIを備える(両者は全く異なるアーキテクチャだ)が、GUI 以外の部分は大きく異なる。

OSの GUI に共通性が見られるのは、生物学で言う収斂進化が OS というものについても起こっているからなのだろう。J.G.シンプソンの言葉を借りればこういうことだ。

生物の進化では新しい形態や器官を一から作り替えることはせず、あらゆる機会を捉えて手近にある材料に働きかけ、それを利用することで器官や形態を発展させてきた。便宜主義が働くと生物は速やかに形態や器官に関する問題を解決することができるであろうが、その反面機能的にはむしろ不完全なものになるのはやむを得ないことなのであろう。
 鳥の祖先は空を飛ぶという「問題」を解決するために、手近にある前肢を利用して翼を発達させたが、コウモリの祖先も同じ問題を同様の便宜主義で解決し、よく似た翼を獲得することに成功している。両者の共通の「問題」は飛ぶという点で、その解決にどちらもたまさか前肢を利用したことでよく似た形が進化したのであろう。似ているのはそこまでで、それ以外は爬虫類とほ乳類の特徴をいぜん残している。陸上を歩いていたクジラの祖先は、水中を泳ぐという「問題」を解決するために体全体を魚によく似た形に変えたが、ほ乳類としての特徴は決して変えていない。

 ぱっと身が似ていたとしても Windows はやはり Windows だし、Mac はやはり Mac なのだ。 実際、持っている機能や操作性はそれぞれのOSで大きく異なる。外見で評価するのではなく、一歩踏み込んだ部分を見抜くことこそが大切なのだろう。

| | コメント (1) | トラックバック (0)

2005/07/09

ノートPCと操作性

使ったのはThinkPadX31なのですがキー配置がまったく違う(>_< ;)
標準的な日本語kbdの配列じゃないのですよ。 [Win]キーがないし、[App]キーもない・・・
わたしは管理コンソールとか各種プロパティの呼び出しにこれらのキーを多用するのでかなり不便です。やっぱり省スペースkbdなんてろくなものじゃないですね。自分でノートを買うときはちゃんとキーの配列を確認することにしました。地味なことかもしれませんがブラインドタッチが当たり前で打鍵するときに手元を見ることがないわたしにとってはかなり大きな問題なのです。

ThinkPadX31はデータの保存性もかなり低いと思う。ノートPCなので当然HDDは1台しかついていないのです。これはいいとして問題はパーティションの構成。なんとパーティションが1つしか存在していないのです。メーカー製PCなので当然のようにOSのセットアップディスクなど存在せず、システムが飛んだときの復旧はリカバリディスクで行うことになります。一般にリカバリディスクによる復元では、その初期段階でシステムパーティションがフォーマットされます。つまり、システムが飛んでしまったらユーザードキュメントも一緒に吹っ飛ぶのだ。通常はこれを防ぐためにパーティションを複数作成し、システムパーティションとデータパーティションを分けるものだと思う。さらに悪いことに、このThinkPadX31にはFDDやCD-R/RW, 記録型DVDドライブもついていないのでデータのバックアップも取れなかったりする。困ったものです。

あとは、実装されているコマンドの差かなぁ
GUIの第一印象があり最初はXPは使いづらいと思っていました。初期のGUIは確かに使いにくいんだけどコマンドは強化されているんですよ。CUIの操作性はXPの方が上だと思います。 GUIはカスタマイズができますから今では特に問題があるとは思っていません。カスタマイズしにくいCUIは評価が分かれるところだと思います。自宅のマシンのようにコマンドで操作していて「**は内部コマンド、または外部コマンド・・・操作可能なファイルとして認識されていません」が表示されると困りますねぇこのあたりはXPとSrvEntの差でも戸惑ったことがありますが。(Srverシリーズのほうが細かい制御ができます。クライアントにはないオプションがあったりとか(^^;) ほかにもファイルの暗号化とかを設定する部分にも細かい改善がされていて上級者向けの機能についてはちゃんと進化が見られました。 2003トラックに移行したわたしは2つの環境を並べて使い比べることはなかったので細かいところの差がわからなかっただけなんだね(^_^;)
XPでは確かに操作性が大きく改善されていました。

操作性が悪いと感じてしまう一番の要因は自作PC以外は触ったことがないからかもしれません。自作PCは、当たり前のことですが自分でパーツを集めるところから始まります。自分の要求に合わせたものを選べるので(100%満足させることはできなかったけれども)大きく不満が出ることはまずないんです。メーカー製PCではコスト削減のため粗悪なものになりがちなデバイスでも自作PCなら納得のいくものが持てます。
そして、ソフトも自分の好きな構成にできるのです。ドライバもAppも自分で入れなくてはなりませんが、だからこそ自分にあったシステム構成にできます。何を入れたのか自分で理解しているので、よほど特殊なAppでもなければスタートアップや常駐の設定はもちろんできますし、スタートアップ時の起動順序も制御できます。セットアップには、メーカー製リカバリディスクよりもはるかに多くの時間がかかりますが、だからこそ安定した状態で自分にとってよりいい環境を作れるのです。
これに慣れてしまったわたしにとってはどんなタスクが走っているのか解らないし、システムの構成そのものが理解できないうえに(理不尽だったりして)、キーボードの配列が独自だったりするメーカー製マシンはかなりストレスが溜まる代物なのです。

| | コメント (0) | トラックバック (0)

2005/07/05

時間がない

7月に入って会社に勤めています。
片道1時間半なので電車の中で本が読めると思っていたら・・・
酔っ払ってしまうので無理でした_| ̄|○il|l

友達から Code Complete第2版がものすごくいいという話を聞いた。買ったものの時間がなくて未だ読めず。CPUの創りかたTHE CELLも積みあがったまま。 Hacking:美しき策謀も出版を待っていた本で、これも読みたい。読みたい本がどんどん溜まっていくなぁ・・・
まとまった時間をとって読みふけりたいものです。

一方で、上司の方から「IPv6ってどんなのかわかるか?」と訊かれてまともに答えられなかった。
マスタリングTCP/IP IPv6編が買ったまま積んであったのでこれを読んで基礎知識を身につけることにした。あとは失敗したMCP70-290の取得と、仕事の幅を広めるためにCCNAの取得も命じられているのでこちらの勉強もしなくては(>_<;)
いまは復習のためにマスタリングTCP/IP入門編を読んでいます。このあとはインターネットルーティング入門を読んで、その後でCCNAの本格的な勉強を始める予定。・・・なんだけど、どこまでうまくいくことやら(;´Д`)

学生時代は時間に恵まれていたんだなぁと実感することが多い。
もっとまじめにプログラミングの勉強をしておくべきだった_| ̄|○il|l

PS. 友人に同人に参加してみたら~みたいなことを言われたんだけどさてどうしようか。
わたしは価値観が変わっているというよりも頭が狂っているだけだし、プログラムも今流行(?)のエフェクトを活用したものは作れないとおもう。単純にテキストとBGA、BGMを流していくだけなら作れるけど・・・
でも、参加したい気持ちはあるよ。となるとシナリオか?う~~~~ん( ´・ω・`)

| | コメント (1) | トラックバック (0)

« 2005年6月 | トップページ | 2005年8月 »