ginkgo、gingko、ginkyo

少し前、3月の話になるが、公立高校の入学試験で出題ミスがあったそうな。

英語の試験で、設問文中で、「銀杏」に ginkgo gingko の二様の綴りが混在していたそうだ。
報告してくれた人(英語の先生)によれば、念のために辞書を調べると ginkgo gingko も載っているのがあったそうだ。
話を聞いて、すぐに、もともと ginkgo と綴ること自体が ginkyo の誤植だろう、何を今さら。100416_04.jpg

ginkgo の綴りについては思い出がある。
昔、世話になった通訳さんが「銀杏はなぜ ginkgo と綴るのか、 gingko なら分かるが…」と仰っていたのが記憶に残っていて、それから何年も経ってからだが、IBMのCI誌「無限大」を読んでいたら、ケンペルの「日本誌」のことが書かれていて、ケンペルは ginkyo と書いたのだが、 y g と紛らわしくて、 ginkgo と誤植したのが印刷されて広まったという解説があり、そういうことだったのか、と合点し、昔から気にかかっていたことをあらためて思い出し、かつ解決したということがあった。
(今だったらインターネットで調べるとすぐに答えが見つかるような話だが、すぐ見つけて、すぐ忘れるような気もする。長い間ひっかかってるからこそ忘れないのかも)

こういう過去の経緯があったので、入試のミスの話を聞いて、直ちに、そもそも ginkgo ginkyo の誤植でしょう、と返したわけだ。
(結局、間違いとは言えないが、受験生を混乱させたかもしれないとして採点対象外になったそうだ。スペルの違いに気づいた人もほとんどいないらしいが、この問題を一所懸命やった子には不利になったのでは。だいたいこの手のスペル違いは実社会でしょっちゅう遭遇するはず。それで混乱してては英語力はありません。)

英語の綴りというのは例外が多くて、有名なジョーク(?)で、 fish はこれからは ghoti と綴ろうというのがある。 gh enough とか tough とかの gh で音 f を、 o women o で音 i を、 ti nation とかの ti で音 sh 、結局、 fish となるという話である。
例外的な綴りを改めようという話もあるようだが、なかなかそうはならないようだ。一方で、 you u through thru to 2 (例えば、com to exe を com2exe)としたりするのも良く見かける。(英語失敗小噺で、日本人がアメリカで電車の切符を買おうと思って、"to New York" と言ったらチケットが2枚出てきた、これはいかんと思って、"for New York" と言ったら今度は4枚出てきた、これは困った「エーと、エーと」と考えていると8枚出てきた、という噺があった)

ところで ginkyo が載っている英語辞書はないらしい。英米ではいまだに誤植を修正する気はないようだ。

関連記事
スポンサーサイト

「に・へ・を」

先日、COBOL、FORTRAN、LISPと、コンピュータ言語のことを続けて書いたので、今日は日本語の話。

田中章夫「日本語スケッチ帳」(岩波新書)にはいろいろおもしろい話が載っている。ブログネタにもなりそうだが、そのまま紹介してもつまらない、針小棒大・牽強付会の謗りを覚悟して。
NihongoSketchbook.jpg

本稿タイトルの「に・へ・を」だが、同書で紹介されていた話は、

    米洗う前 蛍の二つ三つ
    米洗う前 蛍の二つ三つ
    米洗う前 蛍の二つ三つ

の違い。
 は動きがない、 で動きが出た、そして で眼前を蛍が飛び違う様子が見える、もっともすぐれた句という説明である。納得である。

同書は文法解説書ではないからそれ以上の説明はないが、愚考するに、…… 飛んでくる、…… 飛び違う、というように助詞に動詞を引き出す効果があって、かつ、それぞれ結びつく動詞のファミリーが違っているからだと思う。
 は動作の終始点を表す助詞だから、もし「飛び違う」を続けるなら、蛍ニ、三匹が遠くから目の前へ飛んでくる感じになるが、蛍が寄ってくるというのはちょっと不自然。 は動作の場所を表すと思うから、「横切る」「飛ぶ」という動詞と密接で、かつ状況も自然。 は動作とは結びつかない助詞(「京 筑紫 坂東 」という言葉があるように、 は動作の方向を示すこともあるかもしれないが)。

とこう考えてきて、これが蛍だからそうなのであって、他のものならどうだろう。

    もし 蝶々 だったら。
    もし ゴキブリ だったら。
    もし  だったら。
    もし  :

 だったら、 が一番おもしろい、米を洗う人と雀との親しみを感じるのではないだろうか。

    米洗う前 雀の二つ三つ


関連記事

やってもた

月曜日、久しぶりに遅くまで飲んだ。電車があるうちに帰路についた。スマーフォンで調べると乗り替え待ちも短くて良いタイミングで最終快速に乗れるようだった。
なのだが、乗り替え駅に着いたら駅員が、到着が遅れましたので乗り替えの方はお急ぎください、という。
3、4人が猛ダッシュしている。こちらは乗った車両が悪く出口に遠いので、慌てて追いかけたが、雨が降って滑りやすくなっている上に、アルコールが結構入っている。
猛然と走ったつもりだが、足元がふらつく。乗り替え駅方面への通り道は、自転車の侵入防止柵が設置してある。
柵に左足太腿をしたたか打ちつけ、バランスを失った体は右方向へ。胸の脇を柵にぶつけながら、歩道縁石に腰から落ちた。
乗り替えの電車は既にホームに入っていたが、待ってくれたようで乗ることは乗れた。
guard.jpg

翌火曜日はもともと予定があったので仕事は休むことにしていたが、朝起きると胸が痛く、息苦しい。どうしても出かける予定があったので、とにかく火曜日は体をかばいながら過ごしたが、水曜日の朝、少しは改善しているかと期待したが、どうも痛みはむしろ増したようで、仕事を休んで整形外科へ。

右第6肋骨の骨折。
あ~ぁ、やってもた。
関連記事

LISP礼賛

COBOL批判、FORTRAN贔屓ときたが、今日はLISPをとりあげる。
私が一番好きなプログラミング言語はLISPである。LISPでシステムを開発したこともある。
パソコンで、各種の生活習慣や身体データから余命を計算し、煙草をやめると何年寿命が伸びるかなどの生活改善指導情報を与えるもの。もちろん疑似的なGUIも持っている。

開発言語にLISPを選んだ理由だが、この仕事は、既存の計算手法をプログラミングするのではなく、的確な計算ロジックを開発・テストすることが目的なので、作りながら考えるインクリメンタルなアプローチが必要で、開発している「世界」(=LISP空間)に、機能・データを次々に導入・拡張できるLISP処理系が最も適していると考えたからである。(しかもその拡張すらマクロを使って自動化=プログラムの自動生成すらできてしまう。)
プログラムを書くというより、世界を創るという感じがうれしい。
LISP世界

LISPのエレガントさは後にして、実用上で強力だと思うのは、前述のように世界を拡張できることであり、それを支えている特徴が、関数型言語であり、かつ関数の戻り値がリスト(なんでもあり)であるということ、シンボルにいろんな属性をくっつけておけることなどがある。

LISPを知らない人(いくつかのプログラム言語を知っていても、LISPは知らない人が多いと思う)のために、例えば宛名を印字するプログラム(宛名印刷 住所 名前)を考えよう。このときプログラムは住所、名前は印字すべき文字列として記述されるわけだが、住所録が別に存在していてこれを参照するとしたらプログラムの呼び出しは(宛名印刷 (住所録住所 キー) (住所録名前 キー))というように記述できる。
あるいは、効率の観点から住所と名前をリストで扱いたいとしたら、それを返す関数(住所録参照 キー)を作って、(apply ‘宛名印刷 (住所録参照 キー))とすることもできる。夫婦など宛名を連名にする必要があれば、もちろんプログラム宛名印刷は名前がリストの場合、リスト要素を並べて印字するように改造し、住所録名前関数が、必要なときは連名のリストを返すというようにしてやれば良い。MAP関数群を使えばループ構文など使わずにループと同様の動作をさせることができる。

LISPのエレガントさといえば文法がない(括弧のバランスが唯一のルール)ことだろうが、LISPに惚れるのはやはり再帰プログラミングだと思う。LISPを勉強しはじめたとき、再帰をうまく使う発想がなかなかできなかったが、LISPを通じて再帰プログラミングに慣れるということは、新しい思考パターンが自分に加わる快感を覚える。インタープリター系言語だと再帰呼び出しは普通に行えるが、それを使う人はおそらく稀だと思う。
LISP入門者が最初にやるだろう階乗を計算する関数の再帰的な定義
(defun factorial (n) (if (<= n 1) 1 (* n (factorial (- n 1)))))

LISPの世界をのぞいてみたいという気になった人は次の本がおすすめ(著者は本書の中で「LISPは学ぶに値する言語」と書いている)。
WinstonLISP.jpg
関連記事

FORTRAN贔屓

昨日COBOL批判をしたが、今日はFORTRANのここが好き、ということで。
私がFORTRANを覚えたのは大学の3年のとき。講義は、たしか「計算法」という授業のなかで数時間だけ、教材はJISの文法書だけ。それだけでプログラムが書けるようになるわけではないので、講師は、できるだけ安くて、薄っぺらい本を読んでください、という素晴らしいアドバイスをしてくれた。
続けて「計算法演習」という授業があって、はじめて実際に電卓以外のコンピュータに触れた。まさに「触れた」。大学にはいくつか利用できるコンピュータがあったが、演習では数学教室のコンピュータを使った。紙テープを作って読ませていた。当時でも紙カードが普及していて大型機などはカードだった。
コンピュータにやらせるのは主に微分方程式の数値解法、オセロ・ゲームなども遊びで作った。

FORTRANの良いところというと、覚えることが少なく、すぐに使い慣れた道具になるということだと思う。新しい言語のように理論的に良く考えられたものでもなく、特にとりたてて言うことはないだろう。
実はFORTRANの真価はコンパイラをはじめとする処理系にある。私は本格的な科学技術計算にはあまり縁がないが、FORTRANコンパイラはプログラマが書いたものに徹底的な最適化(同じ演算は二度やらないとか、ループでのパイプライン制御や、ベクトル・プロセッサ付処理系ではベクトル演算にするなど)を行う。

FORTRAN文法はシンプルで、データにも構造というものがないからこうしたことがしやすい。さらにこれは、デバッグのしやすさにも貢献する。
たとえば、私が使っていたFORTRANコンパイラは、次のような警告メッセージを出してくれていた。
・演算の型が不一致(整数+実数などは本来許されない。コンパイラは整数を実数化して演算する措置をとる)
・値があたえられずに演算に使用されている
・宣言された変数が一度も使用されていない

こういう警告が何故ありがたいかというと、変数のスペルミスなどを冒すとそれはこのようなエラーとして検出されるからだ。構造体をあつかうCOBOLなどでは変数が使われているかどうかなどは原理的に判定のしようもなく、マネできない。C言語でもある程度FORTRANのようなエラー検出はできそうだが、アドレスを直接操作したりするところはどうしようもないだろう。(Cは書き間違いをしても動いてしまうようなところがある。)

FORTRANはCOBOLと違って文書性などどうでも良いわけだが、それではプログラマ自身が困る。私はFORTRANプログラムでは必ず最初に一通りのコメントを置くことにしていた―モジュール名、機能、引数(サブプログラムの場合)、入出力ファイル、外部参照、特記事項など。プログラム途中でも適宜コメントを入れたり、見易さのために空白行を置いていた。1つのプログラムは最長でもコメントを入れて2ページ(100行)以内にしていた。なお、FORTRANで処理すると面倒とか効率を落としそうなケース(10進演算とか)はアセンブラでサブルーチンを書いてリンクしていた。
こうした言語やコンパイラの特性をプログラマが理解し、自分の書法を確立していれば、FORTRANでのプログラム開発効率はとても高いと思う。
FORTRANプログラムの私流冒頭コメント
CMODULE NAME:test
CDESCRIPTIVE:覚えやすい説明を1行で記入
C NOTE:モジュールの機能詳細
C
CCALLING SEQUENCE: test(arg1,arg2,arg3)
C ARGUMENTS:
C arg1: I*4:out:結果
C arg2: R*4:i/o:呼び出し元作業域
C arg3: C*8:i :○○の文字列
CEXTERNAL DATASETS:
C
CEXTERNAL REFFERENCE:
C
C CREATED:
C UPDATED:
C--------------------------------------------
SUBROUTINE test(arg1,arg2,arg3)
INTEGER*4 arg1
REAL*4 arg2
CHARACTER*8 arg3
C
 ※先頭のCはFORTRANでコメントを示す

昔、コンピュータ関係の雑誌に「○○年後のプログラム言語がどのようなものかはわからない。わかっているのはその名前だけである――FORTRAN」というヨタ話が載っていたが、歴史上最初の高級言語は、きっといつまでも使われることになるだろう。
関連記事

COBOL批判

昨日稿の最後に「COBOLで育った技術者は大抵、システム・センスが悪いと感じたものだ」と書いたのでその理由を書こうと思う。
それでCOBOLのプログラム例とかのネタを探そうとググったら、WikipediaのCOBOLの項目に次の記述があった。
構造化プログラミングを提唱した計算機科学者エドガー・ダイクストラは、各種言語の欠点を挙げた中でCOBOLについて
COBOLを使っていると人は無能になってしまう。COBOLの教育は犯罪とみなすべきである。」と述べた。
まさに私が感じていたことそのままである。この言葉の出所や内容は知らないので、ダイクストラ先生が何をもってこれほど辛辣な評価をしたのかは想像するしかないが、多く見られるCOBOL批判としては次のようなものがある。
・無理に英語的表現を取り入れたために冗長
・論理制御機能が貧弱
・そもそもID、ENVIRONMENTのDIVISIONがムダ
・局所変数がなく、一時的変数も無駄にDATA DIVISIONに記述が必要

いずれももっともである。で、私がCOBOLの最悪の欠点と考えているのは、モジュールを書きにくいという点である。そしてモジュールを書きにくいということは、それだけでデバッグを困難にし、さらにシステム設計の基本であるモジュール分割のセンスが鍛えられないという結果につながる。
モジュール(サブプログラム)が書けないわけではない。しかし、モジュールを書くには、ID、ENVIRONMENT DIVISIONの決まりきった記述に十数行を当てなければならず、それだけでソースリストの1ページの半分が埋まってしまう。そして、続くのがDATA DIVISIONで、ここに局所変数も何もかも書かなければならない。それも1変数1行!、これだけ書かされるとなるとモジュール分割などしようという気にならない。
COBOLにもサブルーチン的なものはある、SECTION単位に実行するというもの。しかしこれはモジュールではない。なぜならSECTION単位でのデータ(局所変数)ができないからだ。

FORTRANプログラムの場合、何かややこしい計算が必要になったら、プログラマーは次のように書く:
      CALL nanika(kotae,youso1,...,youson)
COBOLプログラムの場合は、そこでややこしい計算をコーディングしようとし、DATA DIVISIONと行ったり来たりして書いていく。

COBOLの良いところとして、データの構造体が書けると弁護する声がある。しかし、FORTRANユーザーから見ると、これがさらに状況を悪くする原因にもなる。構造体は真の意味で構造を表しているわけではなく、単に連続するメモリー領域の部分部分に名前を付けるだけだからだ。機能的には何も便利な拡張が行えるものではない。誤解を起こすもとになるのではないか。

「文書性」を良くしようとして、良くできたコメントを書けば済むところを、文法にしてしまったところがCOBOLの悲劇だと思う。

いらないことをたくさん書かなければならないCOBOL

IDENTIFICATION DIVISION.
PROGRAM-ID sample.

ENVIRONMENT DIVISION.
CONFIGURATION SECTION.
SOURCE-COMPUTER xxxxx.
OBJECT-COMPUTER xxxxx.
INPUT-OUTPUT SECTION.
FILE-CONTROL.
SELECT fff ASSIGN TO dddd.

DATA DIVISION.
FILE SECTION.
FD fff BLOCK CONTAINS n RECORDS.
01 rec.


WORKING-STORAGE SECTION.
77 workarea1 PIC 9(8).

01 area.


LINKAGE SECTION.
77 parm1 PIC 9(8).
77 parm2 PIC 9(8).

PROCEDURE DIVISION USING parm1 parm2.
main SECTION.


sub1 SECTION.


関連記事

モジュール(サブシステム)の適正評価

今まで、モジュール(サブシステム)をとりあげ、大きなシステムを設計するときには、適切にモジュール(サブシステム)に分割することの重要性を説いたつもりである。
今日は、分割が適切かどうか判断するポイントとなるモジュール(サブシステム)が持つべき性質について考察する。

ところで、モジュールとサブシステムの用語だが、これらは情報システムの設計においては、用語の使い方には微妙なニュアンスの差があるが、本質的には同じ概念を指し示すものだと思っている。
モジュールという語は、それ以上分割して考える必要がない(⇔分割できないわけではない)、単位的な要素である、というニュアンスがある。これに対し、サブシステムは上位システムの目的と同じぐらいのレベルの部分目的を持ち、それ自身単独でも意味がるようなイメージがある。
2014-05-19_102558.png
Wikipediaなどを見るとモジュールの望ましい性質がいくつかあげられている。詳細はWikipediaを見てもらうとして、私なりの理解を()内に付した。
    ・結合度が低い(1つのモジュールの変更が他のモジュールの変更を要求することが少ない)
    ・凝集度が高い(そのモジュールの機能と関連のない動作はしない)
    ・粒度が高い(分担している機能が直感に一致している)

なお、私は「結合度が低い」の裏返しで、「独立性が高い」という言い方を好む。独立性が高いとは、他のモジュールの内部状態に影響されないという意味で、モジュール間の関係は呼び出し時のインターフェイスで規定される。呼ばれる側のモジュールは、機能を実現するために内部状態を保持する必要がある場合があるが、その管理は当該モジュールが行うという意味である。なお、大域的メモリを複数モジュールが共用するシステムの作り方もあるが、大域的メモリを1つのモジュールと考えて管理することで、独立性を確保する。
情報処理技術者試験でもモジュールの意義や望ましい性質が出題されている。システム開発におけるモジュールの意義は強調しすぎることはないから、これは良い傾向だと思う。

私は学生時代にコンピュータを道具としてプログラムを書いたことはあるが、コンピュータそのものを専門として学んだことはないので、就職してコンピュータの仕事をするときに先輩に教えてもらったのが、モジュールという概念、そしてモジュールの独立性という考え方だった。

プログラム言語の世界では、コンパイルの最小単位がモジュールで、これはサブプログラムと一致する。この意味で、プログラマが書いたものをソース・モジュールと言い、コンパイラがそれを機械語に翻訳したものをオブジェクト・モジュールという。サブプログラムの呼び出しは引数の並びというインターフェイスで完全に規定される。たったこれだけの単純な考え方とプログラミング書法を守るだけで、大きなプログラムを開発する効率は劇的に上がる。

FORTRANは、このような書法をとりやすい。私は特に言語を指定されない限りFORTRANユーザーだった。当時、世間ではなんとなく事務処理用言語はCOBOLという風潮だったが、COBOLは、モジュールの重要性を無視したとまでは言わないが、モジュールを基本にプログラムを書くことには向いていない言語である。COBOLで育った技術者は大抵、システム・センスが悪いと感じたものだ。
関連記事

ブラックボックス

昨日は「頭のよい人はカッコをつける」と題したが、カッコをつけられるようになれば頭が良くなったように見える。
括弧に括る操作は、とりあえずその中身を見ないようにして、括ったものをまとまった1つのものとして扱う、という操作である。人は同時にいくつものことはできないが、括弧に括ることで注目する対象の数を減らすことができる。これが見通しを良くする極意というわけである。
(括弧に括らなくても理解できるのは超人技で、普通は括弧で括らないと理解できないというのが真実だろう)

昨日は、そこからルールの再帰的適用の話をしたので、括弧に括るという操作が強力だということは説明できたかもしれないが、イメージがとりにくかったかもしれない。

そこで今日はモジュールをブラックボックスとして考えることにする。
ブラックボックスというのは、入力が決まれば出力が確定する機能(function)をもつものを抽象化した概念であり、その中で実際に何が行われているかは捨象(隠蔽)される。
blackbox1.png

ブラックボックスという考え方は遠山啓先生の高校数学の参考書で知ったもので、関数(function)を説明するものとして使われていた(ちなみに関数は昔は函数と書き、函は箱のことである)。このブラックボックスの絵も遠山著書にあったものをマネてみた。

例えば、自動販売機をブラックボックスとみると、コインを入力としてジュースが出力となる(商品選択はないものとすると)。
数学の関数というのは、たとえば、 f(x)=x+3  という風に数式で書くことが多いわけだが、この例だと 0を入れると3が出てくるというわけ。

同様に入力が2つある場合、もっとたくさんある場合も考えることができる。
blackbox2.png


何ということもないわけだが、ブラックボックスの考え方を取り入れるだけで、システムの見通しが良くなる。

次に、f  と  g  の2つのブラックボックスをつないで作用させることを考える。
blackbox3.png
このとき、g・f という新しいブラックボックス(数学では合成関数)が1つと考えることができる。その中身である  f  や  g のことは「忘れる」。つまり簡素化される。
blackbox4.png


こうして大きなブラックボックス、小さなブラックボックスが組み合わされて、設計者やその指示を受ける人にわかりやすいものにすることが、システム設計の要諦である。

日常用語としては「ブラックボックス」はわけのわからないものという否定的なニュアンスでとらえられているようだが、本来のブラックボックスは入力が決まれば出力が確定するものを指す。何が出てくるのかわからないのはグレーボックスと呼ぶべきでは。

同じように日常用語が変なのは「抽象的」も。わけのわからないものを抽象的と呼んだりするが、本来抽象とは、対象から本質的なものを取り出すことであるはず。
関連記事

頭の良い人はカッコをつける

前にシステムを考えるときにモジュール概念の重要性について書いた。
モジュール概念がどれほど強力なのかを説明しようと思う。

本稿の表題「頭の良い人はカッコを付ける」というのは、次のようなことである。

中学校の数学では、数を抽象化してその操作(演算)について教える。
    結合法則 (a×b)×c=a×(b×c)
    交換法則 a×b=b×a
    結合法則 (a+b)×c=a×b+b×c
である。

この三法則から、たとえば (a+b)×(a+b)=a×a+2×a×b+b×b という展開公式を導く。
(抽象化以前では、普通は書かれた順に計算する。(2+3)×(2+3)=5×5=25 というふうに。これで実生活は事足りる)

頭の良い子は、これを直ちに理解する。
    (a+b)×(a+b)
        =(a+b)×S        (ここで S=a+b とする)
        = a×S+b×S
        = a×(a+b)+b×(a+b)
        = a×a+a×b+b×a+b×b
        = a×a+2×a×b+b×b

ここに働いているのが a+b を括弧に括る(括弧に括ってそれをSとする)という操作である。

括弧に括るという操作を覚えるだけで、そして繰り返しそれを適用する(再帰的に適用する)ことができることを理解するだけで、文字式の展開という操作はできるわけで、こういう子供たちは展開することが目的ではなく、次の単元である因数分解(展開の逆操作)のパターンを覚えることを目的として練習する。

このように括弧で括るという操作は大変強力であり、抽象的操作では必須のものである。

システムを考える上でモジュールを設定することは、この括弧で括る操作と同等だと私は思う。
それによってシステム全体の見通しが大変良くなるはずだ。

もう一つ、括弧で括る例。
……「「「鏡に映る様子」が鏡に映る様子」が鏡に映る様子」が鏡に映る様子……
blackswan.jpg


関連記事

素人プログラマーは「動いた・動かなかった」、プロは?

今まで、javascriptのサンプルをいくつかアップしたけれど、javascriptもプログラム言語の一つではある。これらのプログラムを書くときは、ネットで同様の機能の使用例を調べて、見よう見まねで書いている。素人プログラマーというわけである。
一般に、プログラム言語そのものは単純なもので、何か一つの言語を習得していれば、他の言語の使用は類推でどうにかなる(手続型でないLISPはちょっと違うけど)。

難しいのは、言語そのものでなくその環境。javascriptを使う場所はHTMLなわけで、HTMLの仕様(DOM=Document object modelや、audioタグなどの機能)を理解していないと凝ったものは書けない。そして、そういう知識が絶対的に不足している私は、ネットで事例を集めて、試行錯誤を繰り返し、動いた・動かなかったと一喜一憂するわけである。
とても効率的とは言えないが、プログラミングを仕事にしているわけではないし、そもそも実現したいニーズがたくさんあるわけではないから、きちんと系統的に知識を得る努力をしていないわけである。

DOM.gif

昔、IBM370アーキテクチャーの上でFORTRANを使っていた頃は、そうではなかった。
プログラムというのは決定論的に動くもので、動いた・動かなかった、という感覚ではなく、正しい・間違っている、だった。FORTRAN言語に内装されていないもの―たとえばディスプレイやプロッターなどのコントロールは、ライブラリーとして提供されていて、そのインターフェイスは極めてクリアだった。私でも完璧にコントロールしているという自信があったものだ。

それに比べ、昨今は、私の不勉強は暫く措くとして、なんだか「動いた・動かなかった」の結果論が横行しているように思える。
プログラムをドライブする側が分散し、非同期的に動いているようで、これがそう感じる原因になっているかもしれない。昔から非同期プログラムを書く方法は存在しているのだが、その場合は、並行処理しているモジュールの完了を、積極的にチェックしたり、OSに依頼してソフトウェア割り込みを起こしてもらうという方法を、「意識的に」プログラムしたものだ。

素人プログラマーは動いた・動かなかったで一喜一憂していても害はないが、現在、プロと言われる人達は、どこまで意識してプログラムを書いているのだろうか。プロが作るものは動作保証が必要で、外部要因で不具合が出るなら、その責任の所在を特定しなければならないと思うのだが。(そこまでの品質を求めたら高くなると言われるかもしれないが、求めないなら素人に頼む値段で十分では)
関連記事

一本の停止線

昨日、「いじわるな信号」を書いたけれど、道路交通に関わる話で思い出したことがある。
随分前になるが、システム工学についての初心者用の読み物に、面白い話が載っていた。書名も著者名もはっきりしないし、細かい点は怪しいけれど、だいたいこんな話だった。

ある交差点では頻繁に渋滞が起こる。この対策のために、道路や交通の専門家が集まって、道路の拡幅が必要とか、信号の知的制御が必要とか、侃侃諤々の議論が続いた。いずれも費用のかかる話でまとまらない。そうしたときに、システム工学の先生に(多分信号システムとかの)相談に行ったところ、先生は暫く考えて、「停止線の位置を4m下げればよろしい」という知恵を授けたそうな。

絵で描くとこういう状態。
bus1.png
で、停止線を下げた状態がこれ。
bus2.png









見てわかるとおり、この交差点を左折するバス路線があって、左折先の道路に車が停車していると、大型バスが曲がりきれず、バスの後ろの車が詰めていると切り返しも難しい、というようなことで渋滞が起こっていたのだそうだ。



システムというのは何もコンピュータや難しい仕掛けを考えて解決を図るのではなくて、何が起こっているのかトータルの視点で見るものだというお話。

そうそう、狭い道から広い通りに出るところの停止線がやけに手前に引かれていると思ったら、バスが来るかもしれないと考えて、ちゃんと停止線を守りましょう。
関連記事

いじわるな信号

家から駅(目的地)まで歩く途中、やや交通量の多い道路があり、下の図のように信号が2か所、約200mの間隔で設置されている。
signal2.png
以前は、信号A、Bの両方が赤になるタイミングがあって、比較的長い時間、車の流れが途切れて、図の青の網掛けのところあたりを「安全に」渡れることが多かった。
ところが、近頃、そういうタイミングがなくなって、確実に車の流れが途切れるということがなくなり、網掛けゾーンを渡れるのは僥倖ということになった。結局、信号の場所でないと「安全に」渡れなくなったわけだが、信号の青の時間は幹線優先で設定されるから、ここもその例に漏れず、幹線を渡る方向の信号は赤の時間が長く(1分半以上)、「待たされ感」が強い。

青の網掛けゾーンを渡ることは、もちろん道路交通法違反である。そして、以前は、多くの歩行者がこの渡り方をしていた。
これはうがった見方かもしれないが、警察としては(ちなみに信号Bのやや右に交番がある)、道路交通法違反を見逃していてはいけないから、そういう渡り方をさせないために信号のタイミングを変えたのではないだろうか。(ただし、これらの信号が系統制御されているのか、たまたまそういう動作をしているのかはわからない。) 

信号に従って整然と渡る姿をよしとする立場なら、この変更は当然・適切のことなのかもしれないが、駅へ急ぐ人々としては、以前の信号のタイミングがありがたかった。そして数は減ったかもしれないが、相変わらずリスクを冒して網掛けゾーンを渡る人は後を絶たず、これらの歩行者にとっては、事実上、危険度が高くなっていると言える。
New YorkerとOsakanは信号に従わない、渡れるときは渡る、「なんであかんの、車来てへんやないの」。

遵法精神あふれるブログ主が考えた解決策: 信号A, Bの中間に横断用信号を1つ新設し、信号A, Bとタイミングを調整すれば、事実上車の流れを妨げず、かつ、安全に網掛けゾーンを渡らせることができるのでは。(コストかかるけど)



関連記事

集団的自衛権と集団安全保障

政治ネタは書きたくないのだけど、と前置きして。
この頃、憲法解釈をめぐる議論が盛んに報道されている。
論点としては、解釈「改憲」が認められるかどうかという手続き論と、何のために集団的自衛権が必要かという議論の2つのレベルの違うものがあるようだ。

手続き論の方、解釈「改憲」については、この言葉自体が形容矛盾なので、これを是とする側は「正しい憲法解釈」という言葉を使うべき。(憲法とは、政府を縛るものというのが通常の理解だから、政府解釈による「改憲」はありえない。もしこれを認めると、政府は憲法で縛られないというのが論理的帰結(=対偶命題)になる。)
また、改憲が党のマニフェストに書いてあり、その党が支持されているから、改憲は支持されているというのも暴論。こういう主張をすると反発されるからやめたほうが良いだろう。(だいたいマニフェストに書いても、実現できなかったときの責任は問われていないでしょう。)
いずれにせよ、手続き論を繰り返しても、問題の解決にはならないと思う。

焦点の集団的自衛権の問題だが、私も集団的自衛権を日本が持ってはならないとは思わないのだが、その行使についての枠組みを決めるべきで、憲法にはその役割が期待されるのだと思う。
反対意見を聴いていると、他国の戦争に日本が巻き込まれるおそれがあるというものが多いのに対し、首相の説明は「そんなことはしない」という。それなら「そんなことはしない」ではなく「そんなことはできない」という法的枠組みを用意する責任があるのではないか。
必要性を主張する側が例に出しているケースは、たとえばNPO活動中に友軍が攻撃を受けた時に日本が反撃できるようにするなど、集団安全保障を前提とするものではないだろうか。同盟国が他国を侵略(防衛戦争という名のもとに攻撃)する場合にも、日本がそれに付き合わなければならない、それができるようにするとは、逆立ちしても言えないだろう。

※ネットに集団的自衛権と集団安全保障についてのわかりやすい説明を見つけた。
  ⇒「集団的自衛権」と「集団安全保障」の違い2014-05-18_075201.jpg

賛成論者の論点を整理すると、集団的自衛権を否定することは、集団安全保障体制に参加している日本がその役割・責任を果たす上で障害になる(武力行使ができない)というものではないだろうか。だとすると、基本的に集団的自衛権は保有しており、その行使は集団安全保障体制の枠組みにおいて行う、というあたりが、そしてそれを法制化することが、現実的な落としどころのように思う。

国際連合と訳されるUnited Nationsは戦争中は連合軍のことだった。当然、日本もドイツも敵国だったからUnited Nationsには入れなかったわけだ。しかし、日本もドイツも(そして焦眉の課題である中国も)入っているUnited Nationsは、剥き出しの集団的自衛権行使(連合軍)から、集団安全保障体制になったものである。かつて「国連軍という名のアメリカ軍」という批判もあったし、国連軍が組織できずに多国籍軍になったこともあるように、いつでも野合組織に変質する可能性はあるけれど。

仮に同盟するとしても、無限定に同盟国と共同して武力行使をするものとは限らない。日英同盟では、日露戦争時、イギリスはバルチック艦隊に対し、スエズ運河を通さないとか、良質の石炭を供給しないなどの妨害はしたが、近海を通過しても攻撃はしなかった。日英同盟はイギリス近海での軍事行動を要求するものではなかったからである。現在の日米同盟(安保条約)でも、アメリカが攻撃されても日本がそれに付き合う必要はない。
首相の説明では同盟していても「助けてくれと言ってこなければ日本が出ていくことはない」。だが、助けてくれと言わせてきた歴史も忘れられない。反対論者が心配していることは、他国の戦争に巻き込まれることもだが、戦前の日本のようになることではないだろうか。

それにしても、冷静で建設的な議論がのぞまれる。原理主義的反対論者の態度は頑なだし、賛成論者には反対者を馬鹿よばわりする態度が感じられる。成熟した民主国家の態様だろうか。そんな冷静さを欠く国には武力を持たせちゃいけません。
関連記事

Javascript小技集

これまで、Javascriptを使った遊びを3つ――「自分用のリンク集」「百人一首」「音楽のさいころ遊び」――紹介してきた。これらはいずれも結構凝ったページだったが、今回はもっとシンプルなものをアップする。
ガラケーで使えると便利かも、と思って作ったわけだが、実際に使うことはあまりなかったし、ましてスマホ時代だと便利なアプリがたくさんあるから、どれもガラクタになった。
我ながら恥ずかしい初歩的習作だが、javascriptを勉強しようという人には、初歩的ゆえに役にたつかも。

○楽音と周波数
 名前のとおり楽音と周波数を相互変換するスクリプト。
   周波数⇒楽音の場合、[周波数]の下の欄に周波数(Hz)を入れて、[周波数]ボタンをクリック
     *周波数欄は評価される。数式も可。
   楽音⇒周波数の場合、[楽音]の下の欄に楽音の文字表記を入れて、[楽音]ボタンをクリック
     *楽音の文字表記は、Cn, C#n, Dn, D#n,・・・、#のみ対応。nは数字(マイナス可)。
   [keys/C0]とあるのは、C0から数えて何番目のキーかを示す。
   また、基準音A4の欄は、デフォルトはA4=440Hzだが、変更することができる。

楽音と周波数
次の度量衡とは違って、スマホのアプリではあまり見かけない計算だが、それにしても、楽音と周波数の変換が必要な時って、どんな時だ?

○度量衡
 各種の単位間の変換を行うスクリプト。

度量衡
スマホの電卓アプリなんかは、単位変換・通貨換算なども組み込んだものがあって便利。

○素数
 素数表、素因数分解、素数とは関係ないが乱数生成のスクリプトを収めている。
 バッテリーを一気に消費したいなら、大きな数の素因数分解とかやれば、CPUが分回るでしょう。

素数
乱数のレンジのデフォルトは190になっているが、191あるものから1つをランダムに選びたいということがあったため。

○Javascript計算機
 最後にもっともくだらないサンプル。(Javascriptの評価関数(eval)を呼び出すだけ)

  ⇒Javascript計算機

  (あまりに恥ずかしいので、画面イメージは控える)


関連記事

音楽のさいころ遊び

システム科はちょっと息抜きして、今日は、Javascriptで遊ぶ3つ目、「音楽のさいころ遊び」。
K.516fという番号がついていることでわかるように、これはモーツァルトのお遊び。
16の小節のそれぞれに11種類(さいころの目2~12)の楽譜が用意されている。各小節毎にさいころを振って、11用意されている楽譜のうち1つを選ぶことを繰り返し、全体で16小節の曲を作るというもの。

K516fSample.jpg



この遊びのためにjavascriptで記述したページを作成した(上のサンプル画像をクリック)

残念なことに再生がぎごちない。HTML5以降のaudio機能を使っているのだが、音源は小節単位の細切れのmp3ファイルであり、これを連続再生するとファイルの切れ目切れ目で問題が起こる。ネットでいろいろ調べて試してみたが、完全に切れ目なく再生する方法がわからない。抜本的に修正するとしたら、生成された16小節のオーディオ・ファイルを連結してから再生することが考えられ、外部プログラムを利用すればできそうだが、javascriptでの外部プログラム実行は仕様にない。WSH(Windows Scripting Host)を介してできるが、それではスマートフォンやタブレットでは動作しないだろう。
あと考えられるのはmp3ファイルでなく、midiデータにしてHTML内にデータを持ってこれを連結することなど。しかし、これをやり切るのには相当勉強が必要だ。

当分の間、このぎごちない再生でご勘弁を。
関連記事

システム開発における分業、システム私論2

昨日は、システム開発は一人でやるのが理想、と書いた。しかし、現実には一人でできることは限られているから、複数人で分業することが多いだろう。昨日と内容的には同様だが、今日は分業に注目してみる。

分業には、大きく分けて2つのタイプがある。
一つはシステムを構成するサブシステムごとに分業するもの。一回り小さくなるが仕事の質は同様、同質分業
もう一つは、開発に必要な技術や外部資源の利用などの専門性に応じて分業するもの。専門性分業
bungyo3.png

同質分業は、サブシステムへの分割が前提になる。
前にも書いたが、多くの人からの情報収集や意見交換を行う必要があっても、1人の中心人物がすべてに参加し、企画をかためなければならない。その過程の中でサブシステムが見いだされてくる。私の経験では「あ~でもない、こ~でもない」と悶々とし、さまざまな情報を脳にぶち込んでいく中で、あるとき「あ、ここで線を引こう」というようにひらめくように思う。(こういうと「ひらめき」次第のようだが、システムの中心となるデータベースを措定して、それとの関連を整理するやりかたが基本。)
そしてこうして抽出されたサブシステムが大きければ、それはサブプロジェクトとして他の担当者をリーダーとして充てがうことになる。

専門性分業は、調達する技術・資源の専門性や、比較優位原理に基づいて効率性を追求するもの。
実際にものを作るという段階になると、適用する技術や外部から調達する資源により、それぞれ得意な専門スタッフを割り当てることになる。
一昔前の汎用計算機によるシステム開発では、適用する技術・言語は与えられた環境に制約された特定のものが使われ、SEとプログラマーの区分も曖昧で、能力の優劣はあっても、質の違いはないスタッフでチームを構成することも結構あったが、近年はさまざまな部品やミドルウェアを組み合わせることになるから、「異能の士」を集めることになる。データベース屋、ネットワーク屋、プログラマーといった具合。

また、プロジェクトによっては、こういう技術が必要になる、という予測があり、その技術がプロジェクトの成否を決める(プロジェクトのキー・テクノロジー)。未だインターネットもブラウザも出始めの頃、ブラウザを使った画面制御をやろうとしたシステムでは、その可能性・限界の確認に努めていた。
なお、専門性分業の考え方は開発チームとその環境に広げて考えるのも有効だ。私には、システム運用時に使用する印刷物等の手配や初期データの入力作業を、開発チームではなく営業の担当者がとりまとめてくれて、すごく助けられた経験がある。
【専門性分業のイメージを持つための簡単な例】
件数不明の複数ファイルが収録されている磁気テープについて、その各ファイル(の先頭数ブロック)をスキャンしてレポートを出すというプログラムが必要になったことがある。
テープマーク(テープに記録されている特殊な磁気パターン、ファイルの切れ目などに記録)への位置づけ・読み飛ばしを行いながら、データ部分を読むことが必要だが、高級言語ではこうした処理はできないから、アセンブラで磁気テープ装置(実際にはチャネル・プロセッサー経由)にこれらのコマンドを送るモジュールを作成する(設計者にアセンブラの技量がないなら、それを持つ人に頼む)。
このモジュールの動作確認ができなければ、全体のプログラム作成に着手することはできない(動作不良なら別の戦略が必要となる)。

システム開発体制の提案や説明を求めると、このような分業体制が示される。多くのプロジェクトでは、過去の経験や同種事例から、ある程度事前に分業の方法やサブシステムの設定がイメージされており、最初からそれに基づいてプロジェクトが組まれるだろう。それはそれで良いのかもしれないが、忘れてならないことは、

どのように仕事を分けて、誰に担当させるか、分業について、きちんと考えたのか、根拠があるのか、
「一人ではできない(のは当然)、だから分業する(のも当然)」という安直な考え方で分業と言っていないか。


分業するということは、それ自身、既に設計が始まっているということなのだ。

関連記事

開発は一人でやるのが理想、システム私論1

現代のシステム開発では、大規模なものは言うまでもなく、小さなシステムでも、それを動かすためにはさまざまなモジュールが関わっている。
それだからこそ、一人の人間がシステムの端から端まで見渡せ、どこで何をやっているのか、どことどこがどういう関係でつながっているのかをすべて把握できるシステムが望ましい。一人の人間が見渡せる=適当なサイズにシステム規模を抑えることはきわめて重要な課題である。

開発段階のことを考えよう。一人の人間の知的能力はとても大きくて、システムを構成する個々の要素が未分別な混沌とした状態から、要素を分別・抽出し、それらの相互関係を決定するという難問をひらめき一つで解決することもしばしばある。(そうした課題の解決方法は昔から業務分析とか、もっと一般に発想法とかたくさんの本が出ていると思う。ここではどうしたら課題解決ができるかには触れない。これが一人でやらなければならない作業だということを主張したいのである。)
しかし、やみくもに人員を投入し、分担させると、混沌状態から要素を分別・抽出する作用は働かない。裏返して言えばあたりまえのことである。すなわち、要素の分別が終わってからでなければ要素単位に分担することはできない、ということである。
一人で見渡せる範囲
システム規模を一人の人間が見渡せるサイズに抑えると、大規模プロジェクトができないという声がありそうだが、人間の認知能力はシステムを入れ子にすることでいくらでも拡大される。どんなに大規模なシステムでもそれを分解すれば数個のサブシステムになる。一人がシステム全体、すなわちシステムを構成するサブシステムを分別・抽出し、その相互関係を十分に理解しており、別の人間が、一つのサブシステムを自分が担当するシステムとして同様の認知能力を発揮すれば良い。
実際には一人の人間でもこうした深い階層の認知を相当程度やれるのだから、複数人が分担することでシステムの規模はいくらでも拡大できるのである。それが表現されているものが人間の文化、法律や各種制度、インターネットなどの社会システムということになるのだろう。

ところで、こういう入れ子的発想で、ものごとを簡素化することには役人の方が長けているかもしれない。たいていの場合、役人は担当業務の専門家ではない。彼らは担当業務に必要な、資源、知識、コストを綜合化して施策にすることが仕事である。そこに求められるのは、事業を大括りに見通し良くする技術であり、1ページで事業全体を説明するような作文・作画が必要である。

話は少し違うかもしれないが、一般の商品開発でも一人でやることが重要という場合があるそうだ。三宅秀道「新しい市場のつくりかた」(書評は別の機会にしたい)では、ニーズがおぼろげに見えたとき、それを商品にする段階においては、一人の担当者が携わるのが良いということを、例を引いて説明している。商品を一人で作ることはできないかもしれないが、企画は一人(議論をし情報交換する相手はいるが、そのすべてに参加する一人)がやるのが良いのである。


関連記事

システム私論、その序

昨日、ブログを一貫するテーマを用意しないとネタに困ると書いたわけだが、テーマを設定してお持ちネタがなければ続けられない。ということで、情報システムはどうあるべきかについての私流に考察したところをテーマにしようと思う。

私はシステム開発の経験はそれほど多くはない。それも基本的には発注者という立場であり、自分で設計開発した経験は、そうとう前で、それも小規模なものに限られる。経験ということであれば、メーカーやソフトハウスの人たちの方がはるかに多いに違いない。
それでも、こうしたことを書く気になったのは、発注者として関わったいくつかのシステム開発プロジェクトにおいて、委託先の作業が不透明で、ただ忙しがっている、結論を急ぎすぎる、発注者に理解できるドキュメントが出てこない、などなど不満がいっぱいで、発注者側の責任者として大変居心地が悪い思いをしてきたからであり、そうした開発プロジェクトで、私がいつも繰り返して委託先に求めてきたこと、提案してきたことをまとめてみようと思う。また、その前段階であり、発注者最大の関心事である委託先選定・調達方法、仕様書についても言及していきたい。
logo_iso9000.jpg
ここで書くことは、私にとってはアタリマエのこと、素朴な疑問なのだけれど、なぜか日本のメーカー、ソフトハウスというところはちゃんとしたポリシーを持って開発プロジェクトを進めているとは思えない。
たとえば、品質管理の国際基準ISO9000というのがあり、多くの企業がこれを名刺に刷り込んで宣伝している。しかし、システム開発プロジェクトにおいて、ISO9000のありがたみを感じたことはあるだろうか。私は無い、というかそのためにやたらドキュメントが増える弊害を蒙る。
何故そう思うのか?
答えはシンプルである、品質管理の技術は持っているのかもしれないが、肝心の成果物の品質が伴わないからだ。ISO9000以前の問題なのに、ISO9000だからOKと考えているのではないか。

私は、委託契約の締結後は、発注者、受託者は運命共同体だと思っている。
発注者が無理な注文をつければつけるほど成果物の品質は落ち、受託者は経費が嵩む。無理な注文はしないに越したことはない。システムはシンプルなほうがエンドユーザーにも良く(と私は信じている)、それは開発者にとってもコスト削減になると信じている。

ユーザーと開発者が、良いものを作ろうという思いを共有することが幸せでしょう。
関連記事

ものぐさの1ヶ月

このブログを始めて1ヶ月が経過。以前ブログをやってみたときは、3回ぐらい書いたところで中断。文字通り三日坊主。
始めてから、毎日1稿を目標に続けてきた。一日も休まず、と言いたいところだが、実際はまとめて数日分を書いて、公開日時を指定する予約投稿をしているものが多い。もし予約投稿機能がなかったら、毎日1稿は無理だろう。

原稿を書くことはそんなに苦痛ではないのだが、文章だけだと見た目が淋しいから、何か絵を入れたいと思うのだが、これが結構悩ましい。
兄弟ブログの「語り得ぬ世界」は写真が多く使われているが、それだけの素材を集められるブログ主のバイタリティ溢れる生活に感心する。出不精でものぐさの私には、日常、絵となるものがない。

そこで過去に作ったガラクタのjavascriptを引っ張り出したり、安直にネットで拾った絵でごまかしたり。

それにしても、振り返ると一貫したテーマがない。何かテーマを見つけないとネタ切れは必至(無制約だと何をして良いかわからないのが人間、制約あってこそ知恵が出る)。「困ったときの大河ドラマ」に続くシリーズを開発しなければ。

ということで、明日から「システム私論」というテーマに取り組む予定。不定期掲載になると思うが、乞御愛読。

monogusa.jpg
ものぐさ太郎は御伽草子に収録されている。子供向けの話のようにおもわれがちで、実際、絵本も多い。
しかし御伽草子では、太郎は村人の犠牲となって長夫(長日人夫)のため都に上るが、清水で女を物色し、辻取り=拉致するというとんでもない話である(結果的には、仕合せになってめでたしめでたしだが)。


関連記事

2016年の大河ドラマは真田丸

NHK大河ドラマ:真田幸村の生涯描く「真田丸」に
「NHKは12日、2016年放送の大河ドラマが、戦国時代の武将真田幸村の生涯を描く「真田丸」に決まったと発表した。脚本は三谷幸喜さんが担当する。キャストは後日発表される。」(毎日新聞)

今日、2本目の投稿(といっても、先のは予約投稿)だが、大河ドラマをネタにする本ブログでは、即刻、これを取り上げないわけにはゆかない。

脚本家として三谷幸喜が悪いとは思わないけれど、史実に基づいて綿密なストーリーを展開するという感じはしないなぁ。大河では前に「新撰組!」をやってたが、大河ドラマとしては? ただ、このドラマで、山本耕史(土方歳三)、堺雅人(山南敬助)がメジャーになったという記憶はある。
また、真田信繁(幸村)というと「天地人」のときに千姫を逃がすという荒唐無稽な話が入ってた。

重厚なドラマは期待薄、開き直って、立川文庫・講談調で真田十勇士をやったらいいんじゃなかろうか。
そういえば、NHKが誇る人形劇で、猿飛佐助が武田勝頼の忘れ形見という設定のがあったように記憶している。

o0433030811788109947.jpg img_0.jpg
(私の幼い・微かな記憶にある真田十勇士)
関連記事

百人一首(javascriptで遊ぶ)

昨日稿の「自分用のリンク集」では凝ったjavascriptをお見せしたが、javascriptでは結構遊ばせてもらった。
今日ご紹介するのは「百人一首」。

tennji.jpg

近頃はスマホ・アプリなどでも百人一首が何種類もでているが、私が作ったのはもう7、8年前のことで、スマホはまだ世になく、ガラケー(当時はこの言葉もなかった)のブラウザで動作させることを条件にしていた。
それに機器の環境にあわせて開発テクニックを習得するにはちょっと歳をとりすぎた。javascriptなら開発環境もライブラリも特別なものは要らないから遊びやすい。
(Androidの開発環境もセットアップして、テストプログラムぐらいは作ったが、動いた、動いたでおしまい)

何はともあれ、遊んでいただこう。  ⇒百人一首で遊ぶ

2014-05-09_134334.png



関連記事

自分用のリンク集

インターネットをやり始めると良く見るサイトを「お気に入り」に登録したり、良いリンク集があればそれを登録したり、ホームページに設定したりする。
それでもだんだん不満が出てくる。
「お気に入り」にたくさん登録すると、そこから探すのが煩わしくなる。階層管理もできるがなかなかしっくりしたものにならない。

他人が作ったリンク集は自分には合わないと思い、また画像をいっぱい貼り込んであって重たかったりする。
そこで一念発起して、自分用のリンク集をつくることを考える。

始めはローカル・ファイルとして作成したのだが、家と職場、その他の場所でも同じリンク集を使いたくなるので、無料ホームページを使って、自分用のリンク集をネット上に置くことにした。

・画像を貼り込んで重たくしない。
・「お気に入り」のような線形でなく二次元的に配置して見やすくする。
・PCだけでなく、スマートフォン、タブレットでも使えるように、小さい画面に合わせたデザインにしよう。
・一番良く使うのはGoogleだから、自家製リンク集にGoogle検索を加えよう。
・1ページでは全部入れられないから、サブページを作ってリンクすることにしよう。
・一時的に覚えておきたいサイトを簡単に登録できるようにしよう。

というわけで作ったのがこれ「自分用のリンク集」(サンプル。実際に使ってるのはもっとエントリが多い)。
top1.jpg 自作リンク集「自分用のリンク集」の構造

ブラウザからソースを確認しても良いが、テキストで示すと次のとおり。 ⇒indexのHTMLソース

ソースを見てもらうと分かるように、3ヶ所 javascriptの記述がある。
最初に現れる script type="text/javascript" src="lnkfn.js"は、リンク集用に用意した関数群のライブラリで、リンク集を読み込むときに同時にプレロードされる。
次にある GgSearch("http://www.google.co.jp/search"); は、Googleなどの検索窓を埋め込む関数の実行、三番目の WREntry(); は、一時的なリンク先を覚えておく機能を埋め込む関数の実行(どちらもdocumentへの書き込みを行う)。

リンク集はトップに置く1つだけでなく、分野別のリンク集をいろいろ用意して(サンプルでは「ポータル」や「地図」)indexからリンクを張るわけだが、そのそれぞれのリンク集も同じ構造にし、上記3つのjavascriptを書き込めば、Google検索窓や、一時リンクの記憶機能を設置できる。そのためライブラリlnkfn.jsを別ファイルにして共用するようにした。
lnkfn.jsのソースは次のとおり。 ⇒lnkfn.jsのソース(言い訳だが、テストや機能追加を繰り返しているため見苦しいソースになっている)

ちょっと凝ったスクリプトになっているが、IE、Chrome、Firefoxで一応は動作確認している。ただしChromeでは、このHTMLをローカル実行したときには一時リンク記憶機能がうまく動かない(cookieの扱いの違いだと思われる)。

実は、このリンク集の前にはもっと凝ったものを作った。マウス・オーバーを検出して下位リンク集が展開されるものだったが、マウス・オーバーはIEでないと動作しなかったし、下位のリンク集のデータも全部読み込むので、動作が重くなり、実用性が乏しいので放棄した。

このごろはChromeなどは同じGoogleアカウントで使うと「お気に入り」も同期するのだが、IEを使ったり、職場ではFirefoxが標準だったりするし、何よりこれに慣れているので、「自分用のリンク集」はやっぱり手放せない。

もし「自分用のリンク集」を使ってみたいなら、勝手にコピーして利用していただいて結構です。
関連記事

大河ドラマの時代

大河ドラマがとりあげる時代・人物は戦国時代に偏っていることは周知のとおり。で、どのぐらい偏っているのか、とりあげられていない時代はどのあたりか、整理してみた。

taiga6.jpg

だいたいは主人公の生没年をドラマが扱う時代としたが、「草燃える」は頼朝の少年時代はドラマでは扱われないので頼朝挙兵の年からのドラマとした。また、「炎立つ」は藤原基衡の時代はドラマでは扱われないが、そのことはグラフには表現できていない。

これで見ると、平将門以前でドラマになりそうなのは、まず持統天皇。里中満智子「天上の虹」という長大なマンガが、十分下敷になるのでは。壬申の乱という大きな戦もある。奈良時代も取り上げられていない。血なまぐさいが。
将門と奥州藤原氏までの空白期間の重要人物は藤原道長・紫式部。戦いのシーンがないのがドラマになりにくいか。紫式部だと史実がわからないからさらに難しいかもしれない。
次の空白期間は、鎌倉幕府が確立してから元寇までだが、期間が短く、重要人物は日蓮ぐらいしか思い当たらない。
その次は、室町幕府成立から応仁の乱までの間。重要人物は足利義満が浮かぶ。マンガだと一休さんとのからみがあるけれど、大河っぽくない。ここも戦のシーンがないのがドラマ化には不利。
あとは江戸の文化文政。田沼意次はいかがだろう。みなもと太郎「風雲児たち」では平賀源内とともに結構活躍するが。

さて空白を埋める人物は出てくるだろうか。

続きを読む

関連記事

「真珠の耳飾りの少女

あんまり絵の良し悪しはわからないのだが、たまには美術展には行く。たいていは、まぁ良かったのかな、ということで終わる。

そんな私でも、マウリッツハイス美術館展で「真珠の耳飾りの少女」を見たときはふるえた。

134656955066413110987.jpg

この絵はあまりに有名で、印刷物やネットで写真を目にすることは何度もあったはずだが、今までは特に気に留めていなかった。しかし、本物を見ると印刷物などでは感じなかったものがこみ上げてくる。
たくさんの絵が展示されていたのだが、順路の中ほどに展示されている「真珠の耳飾りの少女」を見たら、その後のものは見ようという気がしなくなるほど。

展覧会を出ると、よくコピーやはがき、複製画を売っているが、どれを見ても、これは違うと感じてしまう。その後、フェルメールの複製ばかりを集めた「フェルメール光の王国展」というのも見にいったが、やはり本物とは違うと感じてしまう。
山口晃画伯が「ヘンな日本美術史」で、画伯も―「すゞしろ日記」を読むと画伯とは呼びにくくなるが―それまで何とも思っていなかった絵の本物を見てすごいと感じた経験を語っている。画伯と私を比べてもしようがないわけだが、親切にも画伯は本物というものを分析的に説明してくれているので、なるほどと思う。

さて、フェルメールだが、この絵は、比較的最近に、徹底的に修復されたということで、ニスの除去などを丁寧に行ってもとの色が甦ったといわれている。修復の大きなポイントは、耳飾りや唇のハイライトで、特に唇のハイライトは修復前にはなかった(と見えた)部分にももともとはハイライトがあったことがわかったので加えられたのだそうだ。
ただ、フェルメールの他の作品を修復されている岩井希久子氏によれば、ちょっとハイライトの白が大きいかな、もう少し微妙でよかったのではないか、とのこと。氏によればフェルメールのハイライトは1ミリにも満たないごく微量の白い点だそうである。

4568221366.jpg

このことは、岩井希久子「モネ、ゴッホ、ピカソも治療した絵のお医者さん」に書いてあったのだが、そのほか、モネの絵の具のとがり具合のこととか、本物に触れる(文字通り手で)修復家の眼など、とても興味深い。
また、この本で著者は、日本の多くの美術館には修復家がいないこと、保存にも理解がない(信じられない!)ことなど、繰り返し日本の美術の底辺の貧弱さを嘆かれている。たとえば、欧米の美術館では絵一枚一枚にコンディション・カルテなるものがあり、常に絵の状態がチェックされているが、日本ではそういうものをちゃんと用意しているところはあまりなく、とても恥ずかしいとのことである。

高い金を出して海外の名品を買い集めることに顰蹙する向きもあると思うが、さらにその保存・修復が酷い状態だとしたら。
公立の美術館には充実した修復部を設置することはできないのだろうか。集客だけで施設を評価するような人なら、そんな儲からないものに金を出すなというかもしれないが、岩井さんは前述の本で、修復現場を見せられる修復センターができたらいい、入場料をとって修復代に充てたらよい、ということを書いておられる。

それにしても、「真珠の耳飾りの少女」が、本物そっくりの複製でいいから、手に入れたいものだ。
関連記事

読書通帳

先週、職場の近所に図書館が開設されたことを書いた。この図書館では「読書通帳」というサービスがある。読書通帳機というのが設置されていて、通帳の形をした冊子(読書通帳)に、借り出した資料が記録できるという。対象は小中学生だけとなっている。これは子供に読書習慣を身に付けさせるという教育効果を狙ったものだと思うが、大人でもいつ、なにを借りたか記録しておきたいときがある。

図書館では、借り出し記録は、返却と同時に消去するルールが厳格に守られているという。
随分以前の話だが、テレビの刑事ドラマで、犯人を割り出すために、図書館に行って借り出し記録を調べるという設定のものがあり、図書館の団体からの厳重抗議により、既に収録が終わっていたと思われるドラマ1本が破棄されたという新聞記事を読んだことがある。

ではあるが、自分の読書記録というのは、何だか人生の記録のような思いがして悪いものではない。それに、前に借りた本をそうと思わずに借りて、「あれ、これ読んだ」と情けない思いがすることがある。もっと酷いのは、同じ本を2度買ってしまうことである。

スマートフォンには、いろいろな蔵書管理アプリ(もちろん借り出し管理にも使える)があって、この頃は、購入した本、図書館で借りた本、これから読みたい本、というものをアプリに登録するようにしている。

share_2014-05-04-19-32-26.jpg share_2014-05-04-19-35-15.jpg
「蔵書管理」で検索するといろんなアプリがヒットするが、私が使っているのは、上の画像にあるEiBookshelfという無料アプリ。このアプリはデザインがゴテゴテしておらず好感がもてる。最近は知らないが、私がこのアプリを入れたときは、他のアプリは見た目の装飾的デザインに凝ったものが多く、一覧性や操作性が悪いものが多かったように思う。
―私はデザインというのは飾り的な見た目とは思っていない。
 機能性、操作性、構造の簡素さ、そういったものがデザインの本質と考えている。
 以前、スタンフォード大工学部のデザイン研究センターを見学したことがあるが、
 そこでもシステム・デザイン=システム設計である。
 ところでファッション(fashion)は、作る(faire)の名詞形だったと思う(フランス語)。

同種アプリならたいていのものに付いているが、バーコードを読ませたら書籍をネットから検索してくれるから、読みたい本をチェックしておくのに便利である。
本棚をいくつか用意でき、購入した本、借りた本、読みたい本、そして読み終わった本、という棚を設定して使っている。借りた本は、メモ欄に日付を入れるようにしている。また、1種だけだがタグ付けができる。今は、このタグに所蔵館を示すマークを入れるようにしているが、使いやすさを考えると、読み終わった本は棚に分けず、「読了」を表すようにタグを付けるほうが使いやすいかもしれない。

書籍のデータベースは、スマホアプリにありがちな、ローカルの特定フォルダ内の特定ファイルとして記録されるタイプで、ファイル位置が固定されている。この位置が任意に設定できるならDropboxなどの同期できるオンライン・ストレージに置いておけば、任意の端末でデータを同期・共有できて良いのだが、そういう設計ではない。ファイルを開くときにはパス名を指定するはずで、設定でパスを指定できれば簡単にできそうに思うのだが。
それでタブレットを持っていても、同じ状態を保つのが面倒で、このアプリはスマホだけで使っていたのだが、最近、Dropsyncというアプリを使うと、指定したローカルフォルダをDropbox内のフォルダに自動的(定期的)にコピー・同期することがわかったので、それを使ってスマホとタブレットのデータを同期するようにした。具体的には、
データを変更したら、
⇒バックアップ(バックアップ先はアプリが決めたファイル、変更できない)をとる
 →そのデータがDropsyncにより自動的にDropbox内にコピーされる
 →Dropboxの同期機能により他の端末のDropboxにも同じデータが入る
 →他の端末では、Dropsyncにより自動的に指定ファイル(EiBookshelfのバックアップ・ファイル)が更新される
⇒他の端末でアプリを使うときにリストアを行う、
という手順(→は自動、⇒が手作業)。

SQLiteView.jpg
EiBookshelfは内部的にSQLiteをデータベースソフトとして使っているようで、バックアップデータはSQLiteのバックアップデータ形式となっている。したがって、WindowsPCで、SQLiteSpyのようなソフトを使うと、Dropbox内のバックアップデータの読み込み、更新、CSVへの変換ができるから、EiBookshelfを使わなくなってもデータは活用できるだろう。
関連記事

MIDIでマイナス1

小学生のとき、家にテープレコーダーが2台あった。まず第1リコーダーを演奏してテープレコーダーAに録音、次にこの録音を再生しながら第2リコーダーを演奏し、テープレコーダーBで録音する。次にこのBを再生しながら、打楽器パート(ちゃんとした太鼓はなかったのでプラスティックのボウルを箸で叩いた)を演奏してAで録音する。こうやって、リコーダー二重奏+打楽器の一人合奏をした。当然だが、録音・再生を繰り返すから音はどんどん悪くなって、聴くに堪えないものができあがったと記憶している。
13991930142380.jpg 13991930861301.jpg

さて、マイナス1というのは、合奏曲でソロ楽器を抜いて録音された音源を言う。何のことはない、抜くのがボーカルならカラオケだが、楽器の場合は(クラシックの世界では?)マイナス1と言うようだ(単純に伴奏CDとも。日本でカラオケがはやる前からマイナス1という言い方はあったと思う)。

マイナス1音源の作成は小学生のときにやったのと同様だが、小学校の音楽の教科書に載るようなリコーダー二重奏曲ぐらいならともかく、ちゃんとした楽曲で伴奏ピアノを録音するのは、相当のピアノの腕が必要。どうしてもテンポが揺れて後から合わせるのが難しくなる。(生きた人間同士だと、ゆれたテンポを感じながら曲にしていけるけど。)

13991943049890.jpg
今、持っているマイナス1のCDは、初心者フルート用小品、リコーダー用のヘンデルのソナタ、同じくバッハのソナタ、それとモーツァルトのト長調のフルート協奏曲 KV313(上の写真。去年、ウィーン観光に行ったとき、有名な楽譜店 Doblinger で購入したもの)。

当然だが、マイナス1のニーズは楽器練習という限定的なものだから、そんなに多くの曲や演奏があるわけではない。
しかし、ありがたい世の中になったものだ、MIDIエディタを使うと伴奏音源を簡単に(といっても面倒だが)作れる。伴奏ピアノ譜をMIDIで打ち込んで、それをMIDIエディタに付いている再生機能を使ってオーディオ・データにすればできあがりというわけ。

2014-05-04_175238.jpg
私は、この画面に示した MuseScore というフリーソフトを使っている。不満な点も多々ある。たとえばスタッカートが楽譜上は付けられるのだが、再生してもスタッカートにならない―符を細かくきざんで休符を入れないといけない。それでも比較的打ち込みやすいソフトだと思う。


荒城の月1 荒城の月2


ここに示したのは実際の作例。フルート・パートも入れてあるが、伴奏音源にするときはこのパートを削除する。なお、フルートにもピアノにもカデンツァがありルバートするので、入りを合わせるために拍子をとる余計な音を入れざるを得ない。また譜面には示されないが、速度記号にはテンポの絶対数値を属性として持たせることができ、これによってテンポを変更している。

それにしてもMIDIの打ち込みは、前述のエディタを使っても大変面倒。だが、世の中には奇特な人がいるもので、いろんな楽曲をMIDI化してネットにアップしている。これをダウンロードして、MIDIエディタに読み込ませるとスコアが復元できる。ここから自分が独奏するパートを削除すれば良い。ただし、MIDIの再生音はあまり良いものではない。フルオーケストラだと音のゴミ箱状態になってしまう。せいぜい四重奏程度が限界だし、それでも弦楽器はかなり酷い音でしか鳴らない。練習にはなるかもしれないが、とても聴けるしろものではない。まだ聴けそうなのは、伴奏楽器が1つだけで、それもピアノ、ハープシコード、ハープ、筝などの打弦・撥弦楽器に限ると思う。⇒実際の演奏例(荒城の月)でご判断を。

前に、このブログで無料楽譜のことを書いたが、無料楽譜を使ってMIDIを打ち込む、あるいは無料楽譜とMIDIデータの両方をネットで拾うと、素人が費用をかけずに楽しめる(周りの人には苦痛を与える)こと請け合い。
関連記事

アナログ・レコードのディジタル化

一昨日稿でミレイユ・マチューの歌をYoutubeにリンクしている。
私が聴くのはYoutubeのビットレートの低いものではなくて、持っているアナログ・レコードからディジタル化したもの。
家に1000枚ぐらいのアナログ・レコードがあるが、これらを再生するのはやっぱり面倒なので、愛聴盤のいくつかはディジタル化している。CD化されているものもあるが、買い直すのも勿体ない。

ご参考までに、うちのディジタル化作業環境を紹介する。
○ハードウェア
 ・アナログ・プレイヤー Pioneer PL-30LⅡ
 ・カートリッジ DENON DL-110
 ・プリメイン・アンプ ONKYO A-5VL
 ・サウンド・プロセッサー Creative USB Sound Blaster Digital Music Premium HD
 ・パーソナル・コンピュータ ASUS Eee PC 1015PX
 ・モニター・スピーカー TANNOY Autograph mini
○ソフトウェア
 サウンド・プロセッサー付属のCREATIVE製の一連のソフトウェア
13991685582951.jpg 13991685033860.jpg
          ノートPCの右にある黒い箱がサウンド・プロセッサー

アナログ・レコードからのディジタル化は、24bit/96kHzでwaveフォーマットで取る。
(PCが非力のため、圧縮フォーマットだと音を取り損ねる)
アナログからの録音なので、曲のスタート/エンドにどうしても無音部分が出るので、編集ソフトでカットする。
waveのままだとディスクを圧迫するので、WMA losslessに圧縮(mp3は今のところ24bit/96kHzに対応していない)してディスクに保存する。

ディジタル化したデータはPCで再生するわけだが、当然、サウンド・プロセッサーを介してアンプに入れる。PC(特にノートPC)は内部に強いディジタル・ノイズ源があり、どうしても音が濁るから、USB接続のサウンド・プロセッサー(ディジタル化に使用したもの)が良い。

PC以外の音響機器で再生する場合、このディジタル・データを元にしてCDを作成(Windows media playerでできる。品質は16bit/44.1kHzに落ちる)したり、カーステレオ用にmp3にしたりする(WMA対応という機器は多いが、24bit/96kHzはおろか、通常のWMA losslessすら対応していないものが多い)。

ところで、DVDのオーディオ規格(廃れてしまったDVD-Audioではなく、普通の動画DVDのオーディオ部分)は24bit/96kHzも標準対応となっており、動画DVDに収録すれば、普通のDVDプレイヤーでも24bit/96kHzの品位で再生できる。なお、この場合、音だけというわけにはゆかないから、静止画を付加してスライド・ショー形式にする。
実際にこういうDVDを作ってみたこともあるが、ネットで24bit/96kHzの音源を提供しているONKYOなんかが、この方式でDVDで発売したら良いと思うがどうだろう。スライド・ショーで楽譜を同期表示するなど、付加価値もつけられるし。ONKYOはN市に本社があったと思うが、N市の産業振興室あたりから提案されたらどうだろう。

貴重なアナログ・レコードをお持ちで、ディジタル化希望の方があれば請け負います。
関連記事

ドーキンスのパラドックス

日曜日の19:30からは、NHKの「ダーウィンが来た」を見ることが多い。
先日は、マダガスカルのテンレックの話。
細かいことはともかく、気になったことがあった。
テンレックの子供には個性があるという。マイペース、大胆、甘えん坊、しっかりもの・・・
解説の先生は、こうした個性があるということは、生存に有利だと言う。
天候によって、食べ物が少ないときは大喰らいが生き残り、外敵が増えるときは甘えん坊が有利になるという。
―ん、そうかもしれない。

しかし、食べ物が少ない時は小食のほうが有利かもしれない、外敵が増えるときはしっかりものが有利かもしれない。
言葉で説明されると、そういうものかと思いがちだが、本当にそうだろうか。
よくある手法として、個性を持つ個体、環境を数値化してシミュレーションを行うというのがあるが、そういう裏づけが(シミュレーションも絶対では決してない。モデルの妥当性が何より重要だが)あるのだろうか。

そう考えていると、ドーキンスのパラドックスが思い出された。
これはドーキンスの本(「進化の存在証明」だったと思う)に載ってた話だが、次のような論理だったと思う。
進化の存在証明
ヒトの手の指の数は遺伝的に決定されているとは考えられない。
なぜなら、指の数が違うヒトを調査したところ、指の数が少ない個体が散見されるが、DNAを調べたところ、指の数と関連しそうな遺伝子の差異は見当たらなかった。
よって指の数が遺伝的に決定されているとは考えられない。

この論理的欠陥を指摘せよ。

この結論がおかしいということは、結論の異様さから誰にでもわかると思うが、同様の論理的欠陥を内包する論理が巷に横行していないだろうか。
関連記事

ミレイユ・マチュー

学生のとき第二外国語はフランス語を選択していた。学部学生の2/3はドイツ語、1/6がフランス語、残り1/6はその他というような割合だったと思う。フランス語選択の学生は数学志望が多かったと思う。その頃は数学の世界では、ブルバキズムが大きな影響を与えていて、何となくブルバキの本国であるフランスへの憧れみたいなものがあったと思う。

結局、数学もフランス語もモノにはならなかったわけだが、フランス語の勉強として、NHKの「たのしいフランス語」という語学講座を見ていた。同じ時間帯でドイツ語とフランス語を交互に放送していて、それぞれ週3回の放送だったと思う。私が見ていたころの講師は丸山圭三郎という著名な学者だった。
番組は、スケッチ(寸劇、英語ならスキット、コント)、文型・文法解説、会話練習で、中休みでフランス語の歌が流されるという構成。

ミレイユ・マチュー(Mireille Mathieu)との出会いはこの番組。それまで、まったく存在も知らなかった歌手なのだが、番組中で彼女が歌う "Les château de sable" (砂の城)という歌がはじめて。動かされた。

それからしばらくして、マチューのレコードを買った。

13991587394450.jpg
左上の写真が最初に買ったレコード。第1曲は、"Tu riais"(あなたは笑っている)。アルバムの冒頭を飾るにふさわしい華やかなオープニング。

 13991588015661.jpg


テレビで聴いたときはマチューの声は透明感のある声と感じたのだが、レコードをちゃんとしたオーディオ・セットで聴くと大変強い声である。またフランス語の発音も、南仏系というのか、普通のフランス語では、rの発音は破擦音だが、ドイツ語的な音(ノドチンコを震わせる?)になる。マチューは今はドイツで活動しているらしいが、納得してしまう。

もう、あまりマチューという歌手を知る人はいないかもしれない。CDショップの店頭でマチューを見かけることはまずないだろう。ネットで見ても輸入版ばかりではないだろうか。

「ミレイユ・マチューってどんな歌手?」と訊かれたら、フランスの都はるみと表現することにしている。もちろんシャンソンと演歌では和声もリズムも違うわけだが、国民への受け入れられ方がなんとなくそんな感じがする。エディット・ピアフが美空ひばり、ミレイユ・マチューが都はるみ、という感じなのだ。

13991588318402.jpg
下のCDは "Chante Piaf"。Piafの有名曲をカバーしている。マチューの歌う"L'Hymne a l'amour"(愛の讃歌)をどうぞ。

関連記事

大河ドラマ2―ベストは?

珍之助さまから「困ったときの大河ドラマ」というコメントをいただいたので、再び大河ドラマの話。

今までの大河ドラマで何が一番良かったか。
3年前だったと思うが、NHKが大河ドラマ50年でいろんな企画をしたが、「あなたの好きな大河ドラマ」というのもあった。
1位は「義経」(勘九郎じゃなくて滝沢の方)、2位「新撰組!」、3位「龍馬伝」(北大路欣也でなく福山のほう)、と比較的新しく、ミーハー好みのものが並んだ。
10位内に入ったもののなかで私も同意できるのは7位の「太平記」(1991年)。尊氏はとにかく天皇に叛いた大罪人ということでドラマの主人公になることなど考えられなかった、というのが制作決定時にも言われていた。原作は吉川栄治。特に印象的だったのは高師直の悪人ぶり。
vlcsnap-2014-05-02-09h18m19s156.png vlcsnap-2014-05-02-09h18m58s241.png


私のイチオシは「草燃える」(1979年)。永井路子による数編の小説をもとにしている。
vlcsnap-2014-05-02-09h04m37s52.png vlcsnap-2014-05-02-09h05m59s173.png

本邦三大悪女にかならず入る北条政子はちょっと嫉妬深い程度であまり悪女の印象はないが、源頼朝、北条義時という武士の面々がいずれも悪人というところがいかにもと思わせて良かった。
頼朝は義経を滅ぼした後、イヤラシク哀しんで見せる。
義時は謀をめぐらし、ライバルを罠にかけ次々に潰していく。やられる側も謀に謀をもって対抗、悪人同士が謀りあい、嵌め合う姿が面白くないはずがない。
ちなみに、実朝暗殺については、公暁単独説、義時陰謀説などがあるなか、永井路子は三浦義村説を出して学界の注目を浴びている。私も中央公論社「日本の歴史」の執筆者が永井路子説を紹介、評価していたことを覚えている。

この頃は、受けや脚本家の思い込みだけで人物像を造形するようなものが目につくが、いささか薄っぺらい。
歴史というのは人智を超えて動くところが面白く、ドラマ構成の悩みどころ・肝どころ、「事実」をゆるがせにせず、ストーリーを組み立ててもらいたい。歴史に忠実ということではなく、歴史にはそれだけの面白さがあるという意味で。
関連記事

ミリオタ、鉄っちゃんへのプレゼント

「兄弟ブログ」のほうは、呉の大和ミュージアムで盛り上がっているので、援護射撃になるかと思い、古い写真を引っ張り出した。

CIMG0387R.jpg
7年前にミラノのレオナルド・ダ・ビンチ博物館で撮った写真。
写真をよく見ればわかるように、国立科学技術博物館“レオナルド・ダ・ビンチ”と表示されている。
“レオナルド・ダ・ビンチ”は博物館の愛称のようなものだろう。

CIMG0415.jpg CIMG0411.jpg
博物館の建物(古い修道院を再利用だったか)・中庭、建物内の様子

CIMG0390.jpg CIMG0393.jpg CIMG0394.jpg CIMG0414.jpg
この博物館は、名前を冠しているとおり、レオナルドの芸術・科学に関する解説や模型、復元展示がある。レオナルドの図面をもとに作ったと思われる模型―左上から、ヘリコプター、高速船、潜水艦(手前)、最後は飛行機の復元プロジェクトのようだ。

さすが万能の天才、なんでもレオナルドに結び付けることができるということなのか、扱っている分野はかなり広い。

CIMG0420.jpg CIMG0426R.jpg
交通展示のスペースは広い。うろ覚えだが十数台の機関車が並んで展示されていた。珍之助さま、形式わかりますか?

CIMG0427.jpg CIMG0428.jpg
CIMG0434.jpg
ダ・ビンチは潜水艦も飛行機械も考えていた。この博物館では、兵器も交通の一部の扱いのようだ。(敗戦国ですから大したものではないのでしょう。塩野七生によれば、ベニスの海軍資料館は良いらしい)
潜水艦には入らせてもらえるらしい。潜水艦は日本のイ号に比べればずいぶん小さい。イ号には飛行機も積んでたと少年雑誌で読んだ覚えがあるが、違いますか珍之助さま?

そのほか、子供たちへの科学教育活動も充実しているようだ。残念ながら写真はないが、鉱山での仕事と技術といった歴史的な解説展示もあった。また、最先端(そのものというより、教育目的だと思うが)ロボット工学も扱っている。
関連記事

新しい図書館が開館

職場の近くに新しい図書館が開館した。綺麗。
地域所縁の作家の記念館が併設されている。立派。
映画上映会などもできるという集会室がある。広い。

月曜は休館だが、火~土曜は19:00まで開いているので、仕事帰りに寄るのに良い。

13988276533171.jpg 13988277538361.jpg

13988277031903.jpg 13988275913020.jpg

この頃、図書館に変化が起きているそうだ。(猪谷千香「つながる図書館」ちくま新書)
 24時間貸出、自動貸出機設置、正月も開館・・・
 レファレンス・サービスの充実、喫茶の併設・・・
 直営、指定管理・・・
 
佐賀県武雄市図書館は、ツタヤが指定管理者となり、ツタヤの営業もし、スターバックスが併設され、全国的に話題となった。とりわけツタヤのカードで図書館の本を借りてポイントがたまることについては議論が分かれた記憶がある(ポイントは選択制となった)。
このような経営方法や利便性重視という動きと並んで、図書館を情報拠点として充実・活用する取り組みも目立つ。特に後者については、サービス内容に応じた専門的な知識と人脈を持つ必要があり、従前のレファレンス・サービスとも違うらしい。

新しい図書館はどんなサービスに重点を置いてくれるだろうか。
関連記事
Gallery
検索フォーム

⇒記事一覧

プロフィール

六二郎。六二郎。


定年退職
苦しい家計の足しに再就職
=いつクビになってもええねん
 言うたもん勝ちや!のブログ
リンク
最新記事
最新コメント
最新トラックバック
アーカイブ
カテゴリ
タグ

書評 ITガジェット マイナンバー Audio/Visual 

現在の閲覧者数
聞いたもん