  |
はてなキーワード: Lotus 1-2-3とは
日本語ワープロソフトなら「松」、英文ワープロソフトならWordPerfect、表計算ソフトならVisiCalc… じゃなくてMultiPlan。後に Lotus 1-2-3
http://anond.hatelabo.jp/20151104181322
どうやら、あるようだぞ。再現性次第では MS Word viewer も要らなくなる？？
http://www.justsystems.com/jp/download/viewer/ichitaro/
一太郎ビューアで読み込めるファイル形式 ・一太郎Ver.2以上のファイル ・一太郎11以上の圧縮ファイル（jtdc,jttc） ・一太郎2004以上の電子署名セキュリティ文書（jtsd） ・Microsoft Word 2013～Ver5（doc/docx） ・Lotus 1-2-3（123/WK4/WK3/WJ3/WJ2、Ver98まで） ・リッチテキスト形式（rtf） ・テキスト形式（txt） ・XMLテンプレートクリエーターのファイル（jtdx） ・OpenDocument（odt）
訳してみた。あらためて、和訳はものすごく時間を要する作業だということがわかった。もうしないと思う。
注意：以下は意訳、適当訳、稚拙訳であり、誤訳を多々含んでいることは確実であり、Joel氏が本当に以下のように述べているとは限りません。
なぜMicrosoft Officeファイルフォーマットはこんなにもややこしいのか (そしてその対処法を幾つか)
Tuesday, February 19, 2008
先週、MicrosoftはOfficeのバイナリフォーマットを公開したが、このフォーマットは殆ど正気でないように見える。Excel 97-2003ファイルフォーマットは349ページのPDFファイルだ。でも待って、それで全部じゃない。このドキュメントには次の面白いコメントが書いてある。
それぞれのExcelワークブックは1つのcompound fileに収められている
つまり、Excel 97-2003ファイルはOLE coumpound documentで、それは結局、1つのファイル内にあるファイルシステムである。これは、理解するのにあと9ページはスペックを読まなくちゃならないぐらいには十分に複雑だ。そしてこれらの「スペック」は、普通我々が考えるようなスペックというよりは、Cデータ構造みたいに見える。これ全体が階層的ファイルシステムなのだ。
もしあなたが週末を、Wordドキュメントをブログにインポートしたり、あなたの個人的な財務データからExcelフォーマットのスプレッドシートを生成するような気の利いたコードを書くのに使おうと思ってこれらのドキュメントを読み始めたなら、このスペックのややこしさと長さがそんな気をあっという間に失せさせるだろう。普通のプログラマはこのOfficeバイナリファイルフォーマットについて次のような結論を下す:
この4つ全てについて、きみは間違っている。ちょっとだけ掘り下げて、これらのファイルフォーマットがどうしてこんなに信じがたいくらいに複雑なのか、なぜMicrosoftの悪いプログラミングを反映しているのではないのか、そしてそれを回避するためにあなたに何ができるか、を明らかにしよう。
理解すべき最初のことは、これらのバイナリファイルフォーマットはちょっと違ったデザインゴールを持って設計されたということだ。たとえばHTMLとは。
これらはすごく古いコンピュータで速く処理できるようにデザインされた。Excel for Windowsの初期のバージョンでは、1MBのRAM、20MHz動作の80386が Excelを快適に走らせることができるための妥当なものだった。このファイルフォーマット内には、ファイルを素早く開いたり閉じたりするための最適化が沢山仕込まれている:
これはライブラリを使うことを想定して設計されている。もしあなたがバイナリをインポートするものを1から書き上げたいと思ったら、Windows Metafile Format (何か図を描く場合) や OLE Counpound Storage みたいなものをサポートしなくてはいけなくなる。もしあなたが Windows上でやるのなら、そうしたことをたいしたことのない作業にするためのライブラリのサポートが存在する... そういったフィーチャーを使うことは(元々)マイクロソフトチームのためのショートカットだった。でもあなたが全部を自分でスクラッチから書くなら、全部の作業を自分自身でやらなくてはいけない。
オフィスはcompound documentsに対して広範囲のサポートを持っている。例えば、スプレッドシートをWord文書に埋め込んだりできる。完璧なWordファイルフォーマットのparserは、同じように、埋め込まれたスプレッドシートで何かインテリジェントなことが出来るべきだろう。
それは相互協調性(interoperability)を意識してデザインされてはいない。仮定されていたのは、WordファイルフォーマットはWordからのみ読み書きされなくてはいけない、ということで、それは当時においては十分に合理的なものだった。これは、Wordチームのプログラマがファイルフォーマットをどう変更するかについて決定を行う場合にはいつでも、彼らが気にするのは (a)何が高速か (b)Wordのコードベースにおいて最小の行数になるのは何か、だったことを意味する。SGMLやHTML-interchangeableといった標準ファイルフォーマットのようなアイデアは、最初にインターネットがドキュメントの相互交換を実現するまで現実のものにはならなかった。それはOfficeバイナリフォーマットが最初に考案されてから10年後のことだったのだ。ドキュメントを交換するのにインポーターとエクスポーターを使うことができるという仮定が常にあった。実際Wordは簡便な交換のために設計されたRTFと呼ばれるフォーマットを持っており、そのフォーマットは殆ど最初のころからあり、今も100%サポートされている。
それはアプリケーションの全ての複雑さを反映していなくてはいけない。 全部のチェックボックス、全部のフォーマッティングオプション、そして全部の、Microsoft Officeのフィーチャーは、ファイルフォーマットのどこかで叙述されていなくてはいけない。Wordのパラグラフメニューにある、"Keep With Next" と呼ばれるチェックボックス、これはパラグラフを、その後ろのパラグラフと同じページに置くのに必要な場合は、次のページに移動させるもの(?)だが、これもファイルフォーマットの中に無くてはいけない。そしてこれはつまり、あなたがWordドキュメントを正しく読み込める完璧なWordクローンを実装したいなら、そういったフィーチャーを実装しなくてはいけないということだ。Wordドキュメントをロードする競争力のあるワードプロセッサを作っているのなら、ファイルフォーマットからそのビットをロードするコードを書くのには1分しかかからないかもしれないが、ページのレイアウトアルゴリズムをそれに対応させるのに何週間もかかるかもしれない。もしあなたがそうしない場合、カスタマーがあなたのクローンでWordファイルを読み込んだら、全部のページがぐちゃぐちゃになってしまうだろう。
それはアプリケーションの歴史を反映していなくてはいけない。 このファイルフォーマットに見られる多くの複雑さは、古く、複雑で、愛されず、めったに使われないフィーチャーを反映している。それらはファイルフォーマットのなかに後方互換性のためにまだあり、そしてMicrosoftにとってその辺りのコードを残しておくことには何らコストはかからない。しかしあなたがこれらのファイルフォーマットをparseおよびwriteする一貫した完全な仕事をしたいと思うなら、Microsoftのインターンが15年前にやったのと同じことを全て、またやらなくてはいけない。要点は、何千人年の仕事が今のWordやExcelには費やされてきたのであり、これらのアプリケーションの完璧なクローンを作りたいと本当に欲するなら、あなたは何千人年を費やさなくてはならないことになる、ということだ。ファイルフォーマットは単に、アプリケーションがサポートする全てのフィーチャーの簡潔なサマリーなのだ。
手始めに、小さな例を一つ、深く見てみよう。Excelのワークシートは色々なタイプのBIFFレコードの集まったものだ。私はスペックの一番最初のBIFFを見てみたい。1904と呼ばれるレコードだ。
Excelファイルフォーマット仕様のこのレコードについての記述は非常に曖昧なものだ。そこでは単に、1904レコードが「1904日付システムが使われているかどうか」を示すレコードだ、と述べているだけだ。ああ、使えない仕様書の典型的な一例だ。あなたがExcelファイルフォーマットで何かしている開発者で、そしてファイルフォーマット仕様にこう書いてあるのを見つけたなら、あなたがMiocrosoftは何かを隠しているのだと結論付けたとしても無理はない。この情報の断片は十分な情報をあなたに与えはしない。あなたには幾ばくか外部の情報が必要で、私は今ここで、それを提供しよう。Excelワークシートには、2種類ある。日付のエポックが1900/1/1のもの(これには、Lotus 1-2-3 との互換性のために故意に入れられた閏年に関するバグがあるが、ここでそれについて述べるのは退屈すぎる)、および、1904/1/1のものだ。Excelは両方をサポートしているが、それはExcelの最初のバージョンはMac版であり、それは単に簡単だったという理由でOSのエポックを使っていて、しかしWindows版のExcelは1-2-3のファイルをインポートできなくてはならず、そしてそれは1900/1/1をエポックとして採用していたからだ。あなたが涙ぐむのも無理はない。歴史のどの時点においても、プログラマが正しいことをしなかった、という時はないのだが、しかし現実にあなたが手にしているものはこれなのだ。
1900と1904のファイルタイプは両方とも世の中には広く存在しており、それは通常、ファイルがWindowsとMacのどちらで作られたかによる。一方のタイプから他方のタイプへ黙って変換するのはIntegrity的に問題があるので、Excelはファイルタイプを変換することをしない。Excelファイルをparseするためには、あなたは両方を扱わなくてはならない。それはファイルからこのbitをロードするだけの問題ではなく、あなたが日付表示と両方のエポックを扱うparsingのコードまで書き直さなくてはいけないということを意味する。実装には何日かかかるだろうと私は思う。
実際、あなたがExcelクローンの作業をするなら、日付の扱いについて、あらゆる種類の微妙なディティールを発見することになるだろう。Excelは日付の値をいつ変換するのか? 表示の整形はどうやっているのか? なぜ1/31は今年の January 31と翻訳され、また一方で1/50はJanuary 1st, 1950と翻訳されるのか? Excelのソースコードと同じだけの量のドキュメントを書かないがぎり、振る舞いに関しての微妙なビットを全て完全に記述することはできない。
そしてこのレコードは、あなたが扱う何百もあるBIFFレコードの最初の1つに過ぎず、しかももっとも単純なものなのだ。他のレコードの殆どは、より多くのプログラマーを涙に暮れさせるぐらいには十分複雑だ。
唯一導き得る結論はこれだ。
MicrosoftがMicrosoftとOfficeのファイルフォーマットをリリースしたことは大変有用なことだが、しかしそれでOfficeファイルフォーマットをインポートしたり保存したりするのが楽になるということは全く無さそうだ。それらは狂気じみて複雑で、リッチなアプリケーションで、そしてあなたは人気のある20%の部分を実装して80%の人々を幸せにするというくらいのことしかできない。バイナリファイル仕様によってなされるのは、多く見積もっても、著しく複雑なシステムのリバースエンジニアリングにかかる時間を何分か削減するくらいだろう。
オーケー, 私はいくつか回避法を教えると約束した。良いニュースは、殆どの良く知られたアプリケーションにとって、Officeバイナリファイルフォーマットを読み書きしようと試みることは誤った決定だということだ。あなたが真剣に考えなくてはいけない代案が2つある。Officeそのものにそれをやらせるか、書き込むのが簡単なファイルフォーマットを使うかだ。
ヘビーな仕事はOfficeにやらせよう。WordとExcelは実に完全なオブジェクトモデルを持っており、COMオートメーションの手段が可能で、これであなたは何でもプログラムでやるようにできる。多くのシチュエーションでは、Office内のコードを再利用するほうがそれを実装しようとするよりも良い。ここにいくつか例がある。
この手のアプローチは、全ての種類の一般的なOfficeタイプについての、サーバ上であなたがやりたいと思うであろうアプリケーションで、うまくいくだろう。例えば:
これらのケースの全てにおいて、Officeオブジェクトにインタラクティブ動作でないことを教えてやる方法があり、だから表示をアップデートするのに煩わされたり、ユーザに入力を促す必要はない。ところで、このようなやりかたでいく場合には、gotchas(?)がいくつかあり、そしてそれはMicrosoftは公式にサポートしているものではない。だからあなたがそれを始める前にはKnowledge baseの記事を読むように。
書き込むファイルにはもっとシンプルなフォーマットを使いなさい。単にOfficeドキュメントをプログラムで生成したいなら、殆どいつでもOfficeバイナリフォーマットよりももっと良いフォーマット、WordやExcelでも問題なく開くことができるようなフォーマットが存在する。
いずれにせよ、全てのOfficeファイルを完全に読み書きできるような、文字通りのOffice競合製品を作ろうとする(その場合には、何千年もの作業があなたに予約される) のでない限り、Officeバイナリフォーマットの読み書きをするというのは、何であれあなたが解決しようとしている問題を解決するためのもっとも労働集約的な方法だ。
http://anond.hatelabo.jp/20080224122041
推薦図書については末尾に書くけど、その前にちょっとお話。うざいと思ったら読み飛ばして末尾に行ってね。
どの言語がよいか、というのは「ゴルフのクラブで一番よいクラブは何か」という問いと同じなので、正直意味のある問いとは思えないなあ。言っちゃ何だけど、言語を覚えて満足してる奴は、高いクラブを買って満足してるだけの奴と同じだよ。大事なのは「何をやりたいか」で、それさえ明確になれば後は単なる慣れの問題に過ぎないし。
一つや二つの言語を扱える以上になれない奴は、ごくごくごくごく少数の例外を除けば、所詮人に使われるだけのやつにしかなれんよ。そんなの、大学出てまでやる仕事じゃない。営業並みの対人能力があるとか半導体の回路を引けるならまた別だけど、それはもはやプログラマと呼べる仕事じゃないしね。
ゴルフだったら、ショートホールもあればロングホールもあるし、バンカーに落としてしまうこともグリーン上のヨセもある。プログラマも同じ。大事なのは、
「必要が来たとき最小限の勉強時間でどんな言語にも対応できる能力」
じゃないかなあ。これがあれば、その時点で知っている言語が一つだろうと十個だろうと大した問題にはならんよ。
世の中にある言語は、アセンブラとか C みたいに低水準（機械に近いところ）でやるのに適したものもあるし、C++ や Java みたいに大規模なビジネスアプリの開発に向いてるものもあるし、VB とか Perl みたいに細々とした作業を処理するためのお手軽ツールもあるし、Lisp とかみたいに、実用よりも理論的理解を指向したといえるようなものもある。だけど、アセンブラと Lisp みたいな特殊なものを除けば、どれも基本的な考え方は同じだ。確かに C++ や Java に出てくる「オブジェクト指向」は多少取っつきは悪いけど、きちんとした本を元にして勉強すれば一週間で理解できるよ。あとは処理速度と書きやすさ・手軽さを天秤に掛けての判断にすぎない。ゴルフでいうなら、パターを除けばどのクラブも基本的には原理が同じみたいなもんだ。ウッドとアイアンとウェッジという区別はあるけれど、基本的には飛距離とコントロールのバランスだろう？
どの言語を選ぶかなんてのは所詮は小手先のことなのさ。大事なのは、何をしたいか、何のためにプログラマになりたいかということだ。そのためには、いろんな素養が必要になってくる。
もし、半導体やコンピュータやOSみたいな低レベルな話に近いところ興味があるなら、電気工学とか形式言語理論とか数理論理学とかそういう知識が重要になってくる。ロボットを作ったり生体認証をしたり他の機械やシステムを制御したりというような高度な話に興味があるなら、数学とか統計とか信号処理とか制御工学をきっちり勉強した方がいい。業務で扱われる大規模なシステムを扱いたいのなら、理系の知識よりもむしろ世の中の仕組みを広く浅く知っといたほうがいいだろうね。
もはや、「プログラムが書ける」なんてのは、「ワープロや表計算ソフトが使える」というのに毛が生えた程度の技能でしかないんだ。十五年前なら、「一太郎や Lotus 1-2-3（当時は Word や Excel なんてのはあったのかどうかも微妙）が使える」といえば「即戦力」だったかもしれんが、今更そんなの当たり前の技能でしかないだろ？
大事なのは、「他の奴が簡単には追いつけないもの」を持つことだ。大学での数年間はそのために使うべきだよ。目標を持って真面目にかつ気楽に取り組むことだ。がんばりたまえ。
注意 この文章中でわからない言葉が出てきたらまずはぐぐってほしいが、わからなくても気にすることはない。それらの中身を知っていることは大した問題じゃない。大事なのは全体的な雰囲気だから。
まずは、この本をお薦めしたい。
プログラマ（というよりコンピュータ）が関わるあらゆる分野を、本質を押さえて入門程度に書いた本。「やさしい」という題名だけれど、高校生の基準で考えると「難しい」と思う。大学では、「やさしい」「難しい」の基準が何段階も格上げされるから気にしないように。これが「やさしい」と思えるようになったら大学卒業レベルと思っていい。だから余り気負わず、頭から読もうとせずに適当に面白そうなところを眺めて、興味が出たら他のところも拾い読みするという感じで十分。
その上で、興味を持った分野の本を探したいと思ったら次はこれがお勧めだ。
これを見て、適当にぱらぱらめくって、読みたいものから読めばいいよ。この辺の本なら大学の図書館にはあると思うし。ただし、ここに出ている本はどれも本格的だから、難しすぎると思ったら適当に放り投げていい。そうやって、いろんな分野をつまみ食いしていく間に全体像が見えてくるはずだ。
あと、それとは別に基本情報技術者試験を受けるのもいい。大学の授業についていくための基礎力としては十分なはず。これが易しすぎると思ったら、ソフトウェア開発技術者試験でもいい。もっとも、これに通るぐらいなら大学2年か3年ぐらいの力はあると思うけどね。
