アマゾンのレビューに想うこと

10数年前にエーアンドエーの新庄さんと著した『CADリテラシー演習』は初めてVECTORWORKSに触れる人向けであり、当時からその続編あるいは補足版を作りたいと思っていました。それがこのブログを立ち上げたひとつの理由でしたが、『CADリテラシー演習』を発表したエーアンドエーのシンポジウムでお会いした編集者さんのおかげで二年半前に『VECTORWORKS ベストテクニック 100』（エクスナレッジ）を発刊し、このブログを作った目的をほとんど果たせた気がしています。そのこともあって更新は２年以上前で止まってしまっていますが、未だに少なくないアクセスがあって嬉しいです。

一方で、今でもこのブログに記したような情報が求められるのは、ソフトが表面的に進化しても根本は変化していないと好意的に受け取ってもよいのでしょうが、情報発信を続けてきた者としては、このブログにあるような情報はもっと公式の立場から発信されなければならないものだから、ある種の絶望感もあります。

私がずっと理想だと考えているのは「ソフトがユーザーを育て、ユーザーがソフトを育てる環境」ですが、実現はなかなか難しいのでしょう。現実的にはソフトの枠内でしか作れないクリエイター志望者が増えているような気がしています。ソフトの枠からの逸脱は、ソフトとユーザーの両方を育ててくれるのですが、、、、。

*

さて、『VECTORWORKS ベストテクニック 100』についてアマゾンで不思議なレビューが書かれていたので、ここで一言述べようと思います。（アマゾンのレビューに対して著者自らが他の場所で見解を述べるのは江戸の敵を長崎で討つような印象をもたれるかもしれませんが、そうではなく単にアマゾンのような場のレビューに対して著者が直接返答するのは不謹慎だと思うので、こちらに記す次第です。）

そのレビューをかいつまんで言えば「教材データが無い→実際に演習できない→駄本」という話の展開であり、最低評価（★１つ）が付けられていました。

アマゾンで閲覧できる目次で分かると思いますが、この本はページをめくりながら順に進めても良いのですが、むしろ自分で好きな項目を読んで方法を知り、読者自身のスキルやアイディアを高めるような使い方が向いています。極端な言い方をすれば、逆引きマニュアルあるいはFAQ集です。

このレビューの最初の部分「教材データが無い」は事実です。しかし、本のコンセプトから言えば教材データを付けたら「駄本」になります。というのは、課題となる状況を著者が教材データとして読者に与えるのではなく、読者自身がその状況を作り出すこと、あるいは、自分が陥っている状況がこの本に記されていることを発見することが重要な学習であるからで、

課題となる状況を自分で作り出せる

　→そこに存在する課題の意味合いが分かる

　　→作業中に行き当たった課題とこの本の項目の関係を把握できる

と考えます。

そもそもこの本は入門用ではなく、一定のスキルを獲得している人向けなので、「読者は本で説明した状況を意図的に作り出せるだけのスキルを有している」という前提です。だから、申し訳ない言い方だけれど「教材なし＝駄本」という判断は、レビュー者のスキルがこの本のレベルに達していないことを示していると推察できます。ピアノで言えばバイエルを終えてハノンやブルグミューラーやツェルニーに入ってしばらく経った人レベルに向けた本です（逆に言えばショパンやリストを軽々と弾ける人には無用の本です）。数か月～数年、VECTORWORKSを真っ当な方法で学べば、この本には教材が不要であることが理解されるでしょう。

*

なお、アマゾンには「あなたはこの本の関係者ですか？」と尋ねたくなるほど、コンセプトをしっかりと理解してもらえたと感じるレビューがあり著者としてとても嬉しく思いました。

*

ところでアマゾンのレビューといえば、私が関わった『図説年表 西洋建築の様式』に★１つと★４つがついています。★１つの方にはレビューが書かれていますが、低評価の理由は「発注した業者の対応」に対するもので「本の内容とは無関係」です。私はたまたま出版に多くかかわってきているし、『建築文化』誌に書評（＝レビュー）を継続的に書いたり、学会誌の書評を書いたことがあり、その経験から読者が読みたいことを想定しながら書く習慣が身についていますが、世の大半の人はそういう経験を持たないので自分の言いたいことを書きがちです。だから読者アマゾンなどショッピングサイトのレビューにおいて、客観的であるべきレビューと主観だけで許される感想文が混然一体となっている状況は受け入れざるを得ないと思っていますが、上記のようなことで評価の平均値が下がるのは困ったことです。

正当な理由による低評価なら受け入れて次の機会に反映させられますが、上記の2つの事例は誰にとっても何のプラスにもなりません。たとえば『VECTORWORKS ベストテクニック 100』では「私は教材データ付きだと勘違いして買った。教材データが必要な人は注意せよ」のように書けば世のため人のためになったでしょう。

*

これがこのブログの最後の投稿になる可能性が高いのに、VECTORWORKSの知恵とは無関係な内容で失礼しました。

【レンダリング】レンダリング時間の短縮

Cinema4Dを出しているMAXONJapanのサイトで、レンダリング時間短縮についての、とても分かりやすい説明を見つけました。

レンダリング時間の短縮Tips

レンダリング時間に悩む人は必読。

 

【VectorScript】初心者さんが特に気をつけると良いこと

うまく動かない場合、以下のようなところを見直すとよいと思います。

• 括弧、カンマ、セミコロンの数と位置が正しいか？
• 変数の過不足や型が正しいか？

 

 

【VectorScript】作業ウィンドウの背景を白黒切り替える１行スクリプト

画面の背景色が黒のCADで作られたデータをDXFなどの形でもらってVectorworksで開いたとき、Vectorworks標準の白い背景では、たいへんに見づらい配色になっていることがあります。そのようなときは背景を黒に切り替えればよいのですが、いったん黒に設定すると、次に起動したときも背景が黒のままになります。私は日常的にはほとんどやらない操作ですが、先日、たまたま頻繁にやらなければならない仕事が湧いてきたので、一行スクリプトを作ってみました。

SetPref(16,NOT(GetPref(16)));

【解説】

背景色の設定は「16」です。

デフォルト設定でインストールすると “C:/Program 0Files/VW20xx/VWHelp/Script Reference”（Windowsの場合、Macでも似たような場所にあるはず）に入っている ScriptFunctionReference.html を開いて当該機能を探すと、Appendix F – Preference Selectors の中に見つかります。

“SetPref(16,TRUE);”で黒い背景、”SetPref(16,FALSE);”で白い背景になるから、当初はそれぞれを別々に作ってパレットに２つ並べていましたが、美しくないので１つにまとめることにしました。

そのためには、スクリプト内で白黒切り替える必要があります。具体的には、スクリプト実行前後でTRUE / FALSEが逆になるように “TRUE”あるいは” FALSE” の部分をところを書き換えればOKです。

まず現在の状態を”GetPref(16)”で取得し、それと反対の状態にするために頭に”NOT”を付けた “NOT(GetPref(16))”を”TRUE/FALSE”の代わりに書けばOKだということになります。

なお、一行スクリプトの動かし方は、『VECTORWORKS ベストテクニック 100』でご覧ください。

 

 

 

 

 

【VectorScript】 私のプログラミング言語体験

VectorScriptについていくつか書いたついでに、私のプログラミング言語体験を思い出しながら書いてみます。誰の役にも立たない内容かも知れませんが、私が現在VectorScriptを使う上で、あるいは、いろいろなソフトをトラブルを最小にしながら使う上で、以下の経験がとても役に立っています。プログラミング言語学習としていきなりVectorScriptを始めるのはハードルが高い気がする場合は、現時点では手始めに Squeak に触ってみるといいと思います。

*

以下、体験した順に思い出しながら記すので、時系列は多少あっちこっちすると思います。

APL

大学１年のとき渡辺仁史先生の研究室でデータ入力の手伝いをしました。このときのプログラムがAPLで書かれていました。IBMのAPL専用マシンでAPL独特の記号がキーボードに並んでいました。APLを使ったプログラムは自分自身では書いたことがありませんが、プログラムの中身をちょこちょこ見たりしていました。私がAPLとApple IIの違いすら知らなかった頃のお話です。

プログラミング電卓のBASIC

友人がSHARPの関数＆プログラミング電卓を持っていました。これには階乗計算が標準搭載されていなかったので、説明書と首っ引きで内蔵BASICで作ってみました。たぶんこれが最初のプログラミング体験です。変数やループについて知る良い経験になりました。ディスプレイに一行しか表示できなかったのでプログラムを書くのは大変で、実行速度もとんでもなく遅かったことが、マイコンが欲しいという気持ちに繋がりました。

F-BASIC

新宿の西口界隈をぶらついていたら、ある店の前で高校の同期に呼び止められました。その店はCSK、当時はマイコンの小売りもやっていました。友人はそこでアルバイトしていたそうでMZ-2000の中古を買わないかと持ちかけられ、すっかり買う気になっていたのに元所有者の都合でドタキャン。そして、その勢いのまま発売されたばかりのFM-7をローンで買いました。当時は電源を入れるとROM-BASICが立ち上がりプロンプトがピコピコするタイプのものが普通で、FM-7に搭載されていたのはF-BASICです。当時主流であったNECのPC-8001や8801のN-BASICとはちょこちょこ違いがありましたが、便利になる側に働く相違でした。当時はプログラムが掲載された月刊誌が複数発売されていたので、それらを買って書いてある通りに打ち込みながら学習しましたが、大したものは作りませんでした。雑誌に掲載されるのはN-BASIC用のプログラムが大半だったので、それらをF-BASICに移すのは良い学習になりました。月刊誌Oh!FMの発刊は、ちょうどそのころだったと思います。

Fortran

FM-7はモトローラの6809という8ビットCPUを積んでいましたが、当時の8ビットCPUはZ-80が主流でした。FM-7には別売でZ-80カードが存在し、それを入れるとCP/M-80というOSを動かせました。CP/M-80はOSなので、その上でいろいろな言語を動かせました。そのひとつがFortranです。当時のパソコン雑誌にFortranを使った3Dパッケージが掲載されていて、それを使ってパース作成プログラム（今で言う3D-CAD）を作りたくてFortranをかじりました。

FortranはBASICのベースであったと思うので、BASICの知識をベースにわりとすんなり入れましたが、入出力の面倒くささには辟易しました。パース作成プログラムもデータの格納方法（データベース構築）で行き詰まって挫折しました。あらかじめ定まったポイントをつなぐだけなら何とかなりましたが、どんなパースでも描けるようにするためには不特定多数の３次元座標を扱う必要があります。またそれを間違いなく入力する手法も要求されます。汎用性を持たせることの重要さと大変さ、インタフェース設計の重要性を痛いほど理解できました。

BASIC-09

FM-7（モトローラ6809）で動いたOS-9上で動く構造化BASICです。「OS-9はMacintoshだ、おまえは間違えている」と主張する変なアップルユーザがいて困ったことがありますが、そっちはMac OS 9、由緒正しいOS-9と別物です（OS-9はMac OS 9よりずっと前に登場したものです）。

BASIC-09は強いて言えば、通常のBASICとPascalの間にあるような言語でした。構造化されているからF-Basicで書くものより美しく分かりやすいプログラムを書けました。

OS-9がマルチタスクだったので、640×480の画面を田の字に４分割して、それぞれで異なるリサジュー図形を描かせたりして遊んでいました。8ビットCPUでのマルチタスクだから、田の字に分割した画面すべてに線画のリサジュー図形を描くのに丸１日かかったりしていました。

LISP, Prolog

これらはCP/M-80、OS-9、MS-DOSなどでやったと思います。概念的な側面に対しては興味を引かれていましたが、Prologでとても小規模な、いまで言えばSiriやAlexaとの会話っぽいプログラムを作って終わりました。

LISPはAutoCADに搭載されたAutoLISPへの興味が大きかったのですが、AutoLISP自体を使う機会がありませんでした。

LOGO

亀さんを動かして遊んだ程度です。私には、何の役に立つのか全く分かりませんでした。

Turbo Pascal

記憶が定かではありませんが、PC-9801でやったと思います。Pascalの特徴は構造化されていて、BASICみたいなスパゲッティにならない（というよりスパゲッティを作りにくい）点が大きな特色です。しかし、私は構造化できるBASIC-09を知っていたので、Pascalは非常に面倒くさい言語だという印象しかもちませんでした。私のPascal嫌いはここに始まります。その後、Turbo Pascal以外のPascalに触ったこともありますが、入り口を入ってすぐに逃走しました。ところが今もっとも使う言語がPascalライクなVectorScriptであるのは、何という皮肉なのでしょうか、、。

dBASE

初めて触ったのはCP/M-80版です。本格的に使ったのはPC-9801のMS-DOS版でした。これを言語と言ってよいのがどうか分かりませんが、dBASEは素のままでは大変に素っ気ないデータベースプログラムで、搭載されているdBASE言語で実用的なものを作る必要がありました。ほとんど個人的な趣味としてやっていましたが、『図説年表 西洋建築の様式』の年表を複数人で執筆するときに、データ入力と整理のためプログラムを書きました。他のメンバーはデータベースソフトに触るのが初めてだったので、インタフェースを親切に作ったら200行を超えました。不親切なインタフェースならば半分以下の行数で済んだと思います。

dBASE言語は目的がはっきりした言語だったので、使いやすく、実用性の高いプログラムが容易に書けました。私が最ものめりこんだ言語です。一方で、プログラミング言語でアプリケーションソフトウェアを作ることのハードルの高さを思い知らせてくれたのもdBASE言語でした。データベース用に特化されたdBASE言語と、汎用の言語では必要なリソースもエネルギーも桁違いだということ、まともなアプリケーションソフトウェアを作るためにはその筋のプロになる必要があることをdBASE言語が気付かせてくれたのです。この経験から私は本格的なプログラミングを作ることを断念し、ユーザに徹することにしました。

MILC

MS-DOS時代に愛用していたMIFESに内蔵されていた言語です。Cベースだったので、MILCはCへの入り口となってくれました。たとえば、当時最も優れたファイラーであったFDを呼び出すとか、テキストをメール送信するために一定文字数ごとに改行を入れるとか、あるいはそれを復元するとか、かゆいところに手を届かせるための数行から数十行程度のマクロをあれこれ作っていて、それらをNifty-ServeのMIFESのフォーラムにアップしていたら、月刊誌 Oh!PC となんとかムックに掲載されました。原稿料は一方が現金5000円、もう一方が図書券5000円分でした。当時は貧乏学生だったので大いに助かりました。

自分にとって「実用的な」プログラムはMILCで作ったものが多かったです。

Turbo-C

Cについてはポインタというものがなかなか理解できずに手間取りました。どんなものを作っていたかは忘れましたが、数十行程度のものは書けるようになっていました。関数自体に返値があることをしっかりと把握できたことが自分にとって画期的で、これがVectorScriptのハンドル理解に役立ちました。Cはその後はMS-Cなどにちょこちょこっと触ったくらいで、そのうちにC++がでてきましたが、プログラミングをやめてアプリケーションユーザに徹すると決めた後だったのでC++の経験はありません。

FORTH

スタック指向とか逆ポーランド記法という言葉に興味を引かれてかじってみましたが、使う目的が見つからなかったので、学習本を少し勉強しただけでやめました。FORTHと言えば、日本語Mindもかじって関西弁で書いてみたりしていました。（逆ポーランド記法的入力はArchiCADで使われていますね。）

QBASIC

構造化BASICで、BASIC-09に似ていてとっつきやすかったこともあり、趣味的に数百行くらいの図形を扱うプログラムをいくつか書いて遊んだ記憶があります。

N-BASIC

NECのBASICです。イスタンブールの、とある歴史的建造物の調査に参加したとき、極地研さんから光波測距機を借りられることになりました。そこで当時はまだ無名だった友人＝ロボット専門家の山海君に頼んで一定のピッチで光波測距機を動かすロボットを作ってもらって、それの制御と計測値取得のためにN-BASICでプログラムを書きました。このとき、なぜN-BASICを使ったかというと、調査に持っていくラップトップPCがNEC製だったからです。測距機とPCはRS-232Cで繋げました。

調査後は、距離と角度から空間座標を算出し、メッシュで表現するプログラムを書きました（記憶が曖昧ですが、たぶんQBASIC利用）。これにはけっこう骨が折れました。今だったらExcelに座標を取りこんで3Dグラフで表現したか、あるいは、VectorScriptで書いたでしょう。いま書きながら思い出しましたが、当時、すでにLotus 1-2-3があったのだから、それでやればよかったかもしれません。

DesignCAD内蔵のBASIC？？

1990年代前半ごろ（？）に存在していたDesignCADという3D-CADに、カスタマイズのためのBASICが内蔵されていました。当時のPCのパフォーマンスでは3Dはまともに動かなかったので、エッシャー風の2D図形を描かせて、それを立体化して遊んでいました。（これを利用して当時の勤務先にあったNCルーターで置物でも作ろうかと思っていましたが、実現しませんでした。）

Squeak, Scratch

Squeakは、長い間、SmallTalkというものに興味があったので使ってみましたが、プログラムを書くのをやめて久しかったので雰囲気を味わって終わりです。Scratchは子供にプログラミング言語を体験させるために使ってみただけです。プログラミング入門には適していると思います。

SED

プログラミング言語と言えるのかどうか知りませんが、MS-DOS時代、テキスト処理によく使っていました。その後、同様のことができるプログラミング言語としてAWKが広まったようですが、必要なかったので使っていません。

MS-DOSバッチファイル

これもプログラミング言語とは言いきれませんが、かゆいところに手を届かせるため／処理の簡便化のために今でもよく使います。ほとんどが大量のファイルの一括処理なので、エディタではなくExcelで書くことが多いです。

VectorScript

Pascalベースだから読んだときに内容を掴みやすい点は良いのですが、大嫌いなPascalベースだから敬遠していました。しかし20年ほど前、授業で教科書に採用した本の特定操作のマクロを作る箇所で本の記述通りに進まず授業が止まってしまいました。そこでやむなく避けていたVectorScriptに触りました。当該マクロのVectorScriptを見たら、表面的なマクロ作成では予期できないパラメータが勝手に入っていことが原因であると直ちに分かったので、それを削除することで解決しました。この問題発見には様々な言語をかじってきたことが大いに役立ったと思います。それ以来、ちょこちょことVectorScriptを使うようになりました。私にとっては、MIFESでMILCを使うのと同様かゆいところに手を届かせるためなので、大きくても数十行程度です。一度だけVectorworksにない機能を補完する必要に迫られて数百行ものに挑戦したことがありました。手作業で発生しがちなヒューマンエラーを回避するためでもあったので、なんとか8割方完成するところまでこぎつけましたが、結局時間不足のため断念しました。未完成で放置したものの、VectorScript学習として得たものは大きかったです。

*

他にもかじった言語があったかもしれませんが、思い出せません。

ほとんどが興味本位の遊びの範疇でしたが、プログラミング言語学習を通して自分の瞬間的思考の解析や何かの手順を人に説明することもうまくなりました。また、いろいろなソフトが内部でどのような処理を行っているかの見当が付くようになったので、より効率的な手順を見つけたり、バグを回避する手法を見つけたりできるようになっています。私にとっては、そのことがプログラミング言語そのものを修得することより飛躍的に大きな意味があったと思います。近いうちに小学校教育にプログラミングが導入されるようですが、上記のことからは歓迎すべきことでしょう。しかし、まともにプログラミングを教えられる指導者を育てることが至難の業だと思います。英語も同様で、子供が和英辞典の丸写しの英単語羅列文（すなわち英語ではない）を教わってきたときに愕然としましたが、プログラミング学習がそのようにならないことを祈るばかりです。

ところで、プログラミング言語で遊んでいたころの私は西洋建築史の研究者でした。今はCADとか情報リテラシーの専門家として扱われることが多いです。全く畑違いのように見えますが、物事を客観的に突き放して観察する姿勢が必須である点では共通しています。