2022年2月11日金曜日

節分の日の出来事




── 毎年、節分の日に起こること


▼節分の日の出来事
 2/3日、今年も節分の豆まきをした。
 この日の前後には、私のホームページの“とあるページ”に多数の読者が訪れる日でもある。これは毎年のことだから次第に慣れてしまって、節分の豆まきはしていてもその日に起こる出来事の方は忘れてしまうこともある。特に今年は歓迎したくない出来事がいろいろとあり、それにかまけて居る間に気が付いたら節分が過ぎた後になっていた。

 翌日の朝、私はコンピュータの前に座って毎朝の仕事であるメールチェックを始めようとしていた。しかしその前にホームページ上のアクセス情報の一覧を更新しておこうと考え直したのである。最近そのためのソフトウェアを作り直したばかりだったから、メールよりも先に前日のアクセス情報の方を確認してみたくなっていたのである。

 先ず、前日のログファイルの記録をアプリを使ってダウンロードする。その後は自動的にログを解析してホームページのアクセス情報一覧が作成されるようになっている。作成すると言っても、ある種のプログラムを動作させれば一瞬のうちに作り出せるので、それを直ちにホームページ上にアップして公開すればよい。ログファイルをダウンロードしたアプリが、まだ閉じられていない状態のままなので、できあがったばかりの一覧表を時を置かずに即座にアップすることもできる。そのように設計したのである。

 しかしここは、一応 内容を確認してからアップすることにしよう。
 一覧表をざっと見て問題は無さそうである。しかし一か所だけ私の注意を引き付けた部分があった(以下の図参照)。


( カウンター値一覧の一部 )

 【続・素朴な疑問】(22)「鬼と福はどちらが先なのだろう?」という欄のカウント数が、毎年この日だけは跳ね上がる日だったのである。ざっと見て、今年は60回以上読まれている計算になる。節分で豆まきをするとき「鬼は外‥‥」と「福は内‥‥」をどの順に叫べばよいのか分からない人たちがインターネット上で確認しようとしているのである。

 「60回程度では騒ぐことはない! 」と思っている人は多かろうが、私のホームページでは画期的なことなのだ。普段は全体で10人から20人程度の人しか訪れない辺鄙な(?)場所にあるホームページなんです。個々のページで見ると1人か2人しか読者は来ない。その他は訪問者なしが普通なのです。

 したがって、この特異日に起こっていることを知っている人は少ないと思う。私が作ったカウンター値の一覧を見ても気が付かないだろうと思う。最初の“3758”が2/3日の値、次の“3696”が前日の値である。差を表示しない限り気が付かないのが普通である。

 実は、私はこの二つの数値の差を表示することを以前から考えていた。しかしそれは単に自己満足のためであることが分かっていたから実現させる積りはなかった。ホームページの移動とカウンター管理プログラムの開発だけで手一杯だったこともある。しかしカウンター管理プログラムでは処理の途中でデバッグ情報を出力する機能が用意されていた。私は何気なく、それを取り出して対応する部分の情報を詳細に調べてみようと思い立った(以下に示す赤字部分は説明のため書き加えたものです)。

ログ・アナライザーが出力したデバッグ情報の例
(*)【5】
(*)$n = 62 (参照回数)
(*)$DTname = cg22.dat (データ名)
(*)$STvalue = 3676 (スタート値)
(*)$Url = http://home.s05.itscom.net/knuhs/gimon22.htm (参照場所)
(*)$DTtime = 2022/02/03:05:57:58 +0900 (以下、参照日時)
(*)$DTtime = 2022/02/03:07:16:06 +0900
(*)$DTtime = 2022/02/03:07:43:44 +0900
(*)$DTtime = 2022/02/03:09:09:19 +0900
(*)$DTtime = 2022/02/03:09:49:10 +0900
(*)$DTtime = 2022/02/03:10:12:32 +0900
(*)$DTtime = 2022/02/03:10:12:50 +0900
(*)$DTtime = 2022/02/03:11:31:25 +0900
(*)$DTtime = 2022/02/03:11:54:36 +0900
(*)$DTtime = 2022/02/03:12:05:06 +0900
(*)$DTtime = 2022/02/03:12:28:27 +0900
(*)$DTtime = 2022/02/03:13:14:34 +0900
(*)$DTtime = 2022/02/03:13:15:50 +0900
(*)$DTtime = 2022/02/03:13:36:01 +0900
(*)$DTtime = 2022/02/03:13:40:50 +0900
(*)$DTtime = 2022/02/03:13:43:32 +0900
(*)$DTtime = 2022/02/03:13:48:57 +0900
(*)$DTtime = 2022/02/03:13:59:35 +0900
(*)$DTtime = 2022/02/03:14:39:28 +0900
(*)$DTtime = 2022/02/03:15:06:06 +0900
(*)$DTtime = 2022/02/03:15:37:20 +0900 (62名の方々が参照している)
(*)$DTtime = 2022/02/03:16:12:40 +0900
(*)$DTtime = 2022/02/03:16:33:00 +0900
(*)$DTtime = 2022/02/03:17:02:10 +0900
(*)$DTtime = 2022/02/03:17:09:40 +0900
(*)$DTtime = 2022/02/03:17:31:54 +0900
(*)$DTtime = 2022/02/03:17:34:54 +0900
(*)$DTtime = 2022/02/03:17:44:21 +0900
(*)$DTtime = 2022/02/03:17:45:09 +0900
(*)$DTtime = 2022/02/03:17:50:57 +0900
(*)$DTtime = 2022/02/03:18:19:40 +0900
(*)$DTtime = 2022/02/03:18:23:35 +0900
(*)$DTtime = 2022/02/03:18:26:25 +0900
(*)$DTtime = 2022/02/03:18:28:25 +0900
(*)$DTtime = 2022/02/03:18:29:33 +0900
(*)$DTtime = 2022/02/03:18:33:55 +0900
(*)$DTtime = 2022/02/03:18:35:42 +0900
(*)$DTtime = 2022/02/03:18:42:10 +0900
(*)$DTtime = 2022/02/03:18:53:23 +0900
(*)$DTtime = 2022/02/03:19:14:58 +0900
(*)$DTtime = 2022/02/03:19:22:42 +0900
(*)$DTtime = 2022/02/03:19:25:04 +0900
(*)$DTtime = 2022/02/03:19:32:48 +0900
(*)$DTtime = 2022/02/03:19:35:09 +0900
(*)$DTtime = 2022/02/03:19:36:22 +0900
(*)$DTtime = 2022/02/03:19:45:27 +0900
(*)$DTtime = 2022/02/03:19:47:12 +0900
(*)$DTtime = 2022/02/03:20:01:10 +0900
(*)$DTtime = 2022/02/03:20:27:14 +0900
(*)$DTtime = 2022/02/03:20:30:30 +0900
(*)$DTtime = 2022/02/03:20:30:38 +0900
(*)$DTtime = 2022/02/03:20:38:28 +0900
(*)$DTtime = 2022/02/03:21:03:40 +0900
(*)$DTtime = 2022/02/03:21:11:27 +0900
(*)$DTtime = 2022/02/03:21:26:15 +0900
(*)$DTtime = 2022/02/03:21:41:45 +0900
(*)$DTtime = 2022/02/03:21:43:49 +0900
(*)$DTtime = 2022/02/03:21:54:00 +0900
(*)$DTtime = 2022/02/03:22:26:23 +0900
(*)$DTtime = 2022/02/03:22:40:52 +0900
(*)$DTtime = 2022/02/03:22:54:48 +0900
(*)$DTtime = 2022/02/03:23:34:54 +0900
(*)カウンター値 = 3696$2022/02/02:20:37:42 +0900 (前回の値)
(*)加算後の値 = 3758$2022/02/03:23:34:54 +0900 (今回の値)

(*)【6】
(*)$n = 1
(*)$DTname = ct31.dat
(*)$STvalue = 2562
(*)$Url = http://home.s05.itscom.net/knuhs/sture31.htm
(*)$DTtime = 2022/02/03:00:03:46 +0900
(*)カウンター値 = 2575$2022/02/02:03:57:13 +0900
(*)加算後の値 = 2576$2022/02/03:00:03:46 +0900

 ログファイルの解析を行うプログラムでは、この参照部分を見つけると hash領域に記録します。そういう参照記録が62個も現れる訳ですが、それを一つにまとめたものが hash領域に作られます。それを目に見える形にしたのがこの出力部分です。62個の参照が行われた日時もそのまま残されています。この情報から新しいカウンター値が求められる訳です。

 この一覧表を見ながら考えました。これは矢張り差分を求めて一覧表に表示しておくべきだったと。そこで早速手直しをすることにしました。2/5日の一覧表の一部を以下に示します。


( 新しいカウンター値一覧の一部 )

 残念ながら“+62”という表示は見ることができませんでしたが、来年の2/3日には見られると思います。楽しみにして待つことにしよう。

2022年2月1日火曜日

「素歩人徒然」欄の最近の掲示です





【ホームページの移動】

 ホームページを以下の場所に移動しました


http://home.s05.itscom.net/knuhs/index.htm

「素歩人徒然」欄の最近の掲示です

アクセスカウンター(その1)「カウンターが使えなくなりました」 
アクセスカウンター(その2)「ホームページの移動」       
アクセスカウンター(その3)「カウンター機能を自作する」    





2022年1月3日月曜日

明けましておめでとうございます




── ホームページを引っ越しました


 コロナ禍も3年目に入りました。その中でどのように生きていくかが今や最大の問題となっています。私めは家にこもってプログラム作りに没頭するのを最大の楽しみ(*1)としております。それに疲れると2時間ほどウオーキングをする毎日です。

 昨年末、私めのホームページ「Knuhsの書斎」の引っ越しをしました。以前から3箇所に分かれてホームページを構築していたのですが、主として利用していたホームページの環境が極端に悪化(*2)してしまい、ホームページ向きではなくなってしまったのです。そこで居場所を変えることにしました。住みにくい環境はどこも変わりませんが、その中でやりくりをして少しでも使いやすい場所へと移動したくなったのです。引っ越しと呼ぶほど大げさなものではありません。3箇所にある別宅の一つに主たる居場所を変えたという風に理解してください。

 しかし居場所を変えるのに2か月程掛かってしまいました。検索エンジンも含めて読者の皆さんに「引っ越しました」と挨拶をしなくても済むようにしたかったのです(今までと同様のアクセス方法で自然と別宅の方へ移ります)。新しい環境でも使えない機能が色々あったので、久しぶりにPerl言語(*3)でプログラム作りをして自作の機能に置き換えました。それに熱中する余り、ホームページの更新の方が疎かになっているようです。不具合等があればご指摘ください。

 本年もよろしくお願いします。

【注】(*1)会社時代にいろいろなプログラム言語を使ってきましたが、定年後は自分の好きな言語を選ぶことにしました。今はPerlというプログラム言語が一番のお気に入りとなっています。この言語に巡り合えたことは幸運だったと思います。大学で学生たちに教えていた時期に作ったテキストが、今私自身のために役に立っています。
【注】(*2)SNSの時代となり誰でも簡単に情報発信ができ仲間を作ることができる時代となりました。今や従来のホームページ形式の世界は見向きもされなくなり、レンタルウェッブはもはや商売にならなくなったようです。利用者へのサービス機能も縮小されつつあります。まさにホームページ氷河期ですね。そんな事情もありホームページ「Knuhsの書斎」も引っ越しました。
【注】(*3)Perlというプログラム言語は、コンピュータ黎明期の頃に開発された言語ですが、その後の時代の変化に合わせて発展してきました。今やインターネットの時代に最も相応しい言語に成長したという点で極めて稀なプログラム言語です。




2021年12月7日火曜日

アクセスカウンター(その1)


・Knuhsの書斎 から転載

── カウンターが使えなくなりました

 SNSの利用者は年々増加している。2020年代の調査では全インターネット利用者の6割以上が利用しているそうである。現在では7割を超えているかもしれない。
 その反動からか、従来からある個人ホームページの利用者の割合は激減しているのではないかと思う。レンタルWebは商売にならなくなっている。そのためサービスを止めたり、各種の機能を絞ったりしている。私のようなホームページ利用者にとっては残念な事態であると言えよう。以下、それにまつわる話題を何回かに分けて報告したいと思う。
▼アクセスカウンターとは
 ここで話題にする“アクセスカウンター”とは、ホームページ上のページにあらかじめ設定しておいて、そのページが参照された回数を記録する機能のことである。ここでは単に“カウンター”と呼ぶことにしよう。

カウンターの例

 個人でホームページを作成する時代が訪れたとき、私も自分のホームページを作成してその先頭(トップページ)にカウンターを設置したものである。インターネットの黎明期の頃ならそれで十分だったかもしれないが、やがて検索エンジンが登場すると様子が変わってきた。ホームページの利用者(お客様)は必ずしもトップページ(正面玄関)から入ってくるとは限らなくなったのである。検索して得られた情報を使って直接アクセスしてくるのが普通のスタイルとなった。窓から覗き込むようにして突然客が現れるようになったのである。

 こうなるとトップページにカウンターを設置しておいてもそこを通らないのだから記録が残らない。そこで私は、個々のページの中から適当に選んで主だった場所にカウンターを設置することにした。長年ホームページを運用し続けている間(約25年)に、この種のカウンターの数が500個ほどになってしまった。

▼カウンターを利用して‥‥
 カウンター値を利用して何をするかと言うと、その値をまとめて一つの表にし日々ホームページ上の記事がどの程度読まれているかを正確に把握することができる。慣れてくるとざっと眺めただけで自分の書いた文章がどの程度“読まれたか”が分かるようになる。それだけでなく、何よりも自分の励みとなり勉強にもなるのである。以下に例を示す。

例:
10+26=36か所参照された例」
(10箇所)の表記は当日参照、 
 (26箇所)の表記は前日参照を示す

特異な例:
「アクセスが多くて驚いた例」
 (157箇所)、(217箇所)
【注】参照時間がほぼ同じなので一人の人が参照しているように見える。何が目的なのかは分からないが。
 その大切なカウンター機能が、あろうことか10月28日(木)の朝から突然使えなくなってしまった。最初は私のホームページも時代遅れとなり関心を持って読んでくれる利用者がいなくなったのだと理解し衝撃を受けてしまった。それまで訪問者が皆無(全くのゼロ!)という日は1日としてなかったからである。とうとうその日が来たかと私は覚悟を決めたのであった。

衝撃の例:
「参照者ゼロの衝撃の日の例」
 (0箇所)、(4箇所)

 しかしどうもおかしい。そう言えば、以前も同じようなことがあったのを思い出した。それまで使っていたカウンターが使えなくなりプロバイダーにメールで問い合わせたことがあった。その結果分かったことは、プロバイダー側が私の使っているカウンターの存在そのものを認めないという事実だった。この間、プロバイダー側の運営会社が何度か変わっているので前の会社のものは認めないことにしたらしい。電話でのやりとりでも埒があかず、結局強引に決着させられてしまった。それを思い出し少し不安になってメールで質問することにした。

 その結果「レンタルWebで提供していた“CGI・SSI”機能は 2021年9月30日をもってサービスを終了しました」との返信が届いたのである。しかもその会社のホームページ上で告知していると言う。何と、2021年9月30日に既に終了していたのである。それに気づかず、私は1か月も経過した後になって初めて気が付き一人で騒いでいるという失態を演じてしまったのだ。
 どうやら、9月30日で終了したが、その後も1か月間はそのままにしてあったものを10月末を迎えて最後の断を下したものと思われる。何ともはや‥‥。

過去の痕跡が残る例:

最近のカウンター表示です
【注】諦めの悪い私めは、使えなくなったカウンターを機能しないままその場所に残しておくことにした。もしかしたら再び使えるようになるかもしれないと思ったのである。新しいカウンターは、過去のカウンターの上に設定することにした。
 今回は2度目なので二つの痕跡が残っています。下から順に、最初のカウンター、2度目のカウンターの痕跡。最後に最近(他の環境に移して)設定した最新のカウンターが表示されています。
 しかし今回の件は、かなり前から利用者の意見も聞かずにサービス終了を決めてしまったのだから、かなりの覚悟をもって決定したことなのであろう。いまさら議論を蒸し返しても成果は得られそうにない。私は諦めることにした。

▼CGI機能とは
 CGIとは、Common Gateway Interface の略である。あらかじめ用意されたHTML言語で記述されたものだけが実行できるのではなく、アクセス制御されたCGI環境下で、CGI機能を用いることができるようになる。

 これらの機能を提供するのは、プロバイダ側とホームページの管理者(つまり私)とが協力して作成する立場で、ホームページの利用者がそれを享受するという関係になる。例えば、CGIで実行できる主な機能としては以下のものがある。

・アクセスカウンター
・訪問者名簿の作成
・Web検索
・パスワードによるアクセス制御
・Webチャット
・BBS掲示板
・注文書の作成
・その他、各種のスクリプト言語を指定できる


 私が利用していたのは「アクセスカウンター」と「パスワードによるアクセス制御」だけでなので、CGI機能のサポートを止めることで会社がどれだけ省力化できたのかは分からない。

 会社のホームページ上を確認しなかったのは私のミスかもしれないが、レンタル契約をしている有料会員には直接伝えるのが礼儀ではないかと思う。Yahoo!が無料のWebサービスを止めたときは、無料会員に対しても個々にメールで伝えて、かなりの猶予期間を取ってくれたのと比べると雲泥の差があると思うのである。

▼対策(1) カウンター機能への対策
 カウンター機能だけなら無料で作れるサービスがある。しかし500個以上も一度に作るのは難しい。それなら自分で作ればよいではないか。
 私は早速作ることにしたが、CGI環境が残されるのかが心配になった。プロバイダーの告知を読むと「2021年12月31日をもって、対象ディレクトリ「cgi-bin」以下のファイルを削除する」とある。これはディレクトリ自体が削除されると解釈するのが普通だろう。もしそうなら、ソフトウェアを自作しても無駄である。悩んだ末に私はホームページを別の環境に移すことにした。

 思えば、ホームページ作成でこのプロバイダーを選んだのは、利用者レベルでの「パスワードによるアクセス制御」の機能が使えると知ったからである。中学生時代の同期会名簿を作ってインターネット上に安全に保存し、同期の仲間だけが自由に見ることができるようにして管理するのが目的であった。幸いにも、ホームページ作成の第一号として向かい入れて貰えたのである。使用料も安くて(当時は普通だったが今の金銭感覚では安いと言える)同じ条件で長期間利用させてもらった。大変感謝している。CGI機能がなくても利用するところはまだまだ沢山ある。今後も使い続ける積りである。

 次回は、ホームページの移動で体験したことを報告したいと思う。

▼対策(2) ホームページの移動

 ・・・ 続きは次回へ ・・・



2021年11月1日月曜日

名前は短めに




── 眞鍋博士の名前について考えた


▼眞鍋博士の名前
 今年のノーベル物理学賞は、日本人の眞鍋淑郎(まなべ・しゅくろう)博士が受賞することになった。1969年、気候モデルに関する研究で世界で初めて大気循環と海洋循環とを組み合わせた「大気海洋結合モデル」を発表した業績に対するものである。大変嬉しいニュースであった。

 テレビニュースで眞鍋博士のインタビューを見ていたら、アメリカでは名前の「しゅくろう」が発音しにくいので“スキ”(suki?)と呼ばれている、という意味のことを話しておられた

 それを聞いた私は“しゅくろう”がアメリカ人にとって発音しにくいとは到底思えなかったので、おそらく他国の人の耳慣れない名前が覚え難いから単に短くしただけのことだろうと考えた。それにしても、短くしたら“suki”になったというのはどういうことだろうか、と益々納得がいかなくなってしまったのである。

 そんな疑問をいだきながら数日が経過したのち、私は或る事にハタと気が付いたのである。もしかしたら‥‥、そうだ(!)調べてみよう。私は眞鍋博士の英字の名前表記を確かめることにした。インターネット上で検索するとノーベル物理学賞のページ(https://www.nobelprize.org/prizes/physics/2021/manabe/facts/)では“Syukuro Manabe”となっているではないか。

 なるほど、眞鍋博士は自分の名前を“Shukuro Manabe”ではなく“Syukuro Manabe”と表記していたのだ。これでは欧米人には読めない(!)だろう。“Syu”をどう読んだら良いのか、あるいはどう発音したら良いのかと迷うことになってしまう。“y”を無視して“Su”とすれば“sukuro”,“suku”あるいは“suki”などと短くすることができるであろう。私は他人の名前の読み方について勝手に推測し、勝手に納得しようとしていた。

 私は小学校の時代に、日本語の発音をローマ字表記する方法を学んだ。後年、その表記法を「ヘボン式」と呼ぶことを知った。「ヘボン式」では「しゅ」のような拗音(ようおん)は“shu”と表記することになっている。一方、「訓令式」と呼ばれる表記法もあり、この方式にしたがえば「しゅ」は“syu”と表記する。眞鍋博士は、どうやらこの方式のローマ字表記法で育った世代だったのではなかろうか。

 なお、訓令式とヘボン式の主な違いは次の表のようになる。

 
訓令式
ヘボン式
si
shi
zi
ji
ti
chi
tu
tsu
hu
fu
しゃ
sya
sha
じゃ
zya
ja
ちゃ
tya
cha
しゅ
syu
shu
じゅ
zyu
ju
ちゅ
tyu
chu
しょ
syo
sho
じょ
zyo
jo
ちょ
tyo
cho
表:訓令式とヘボン式の主な違い

 眞鍋博士も小学校時代にヘボン式を身に付けていたら、アメリカでは“shuku !”とか“shukuro !”などと呼ばれていたに違いない。

▼私の名前
 私が眞鍋博士の名前に拘った理由は、その発音が私の名前と似ていたからである。実は私の名前は“恂”と書き“しゅん”と読む。私はこの名前で呼ばれるのが嫌いだった。後ろに“君”を付けて“しゅんくん”などと呼ばれると、何か中国人の名前のようで気に入らなかったのである。

 小学校の時代には自分の名前をローマ字で表記する機会があると“syun”と書いていたこともあった。しかし中学生となり英語を勉強するようになってからは、しっかりとヘボン式表記法を身に付けて“Shun”と表記するようになっていた。

 企業人になってからは、仕事の上で外国人に会う機会が出てくると会社では名刺の裏面が英語表記で印刷されたものを作ってくれる。そこでは常に“Shun Kinoshita”(*1)というつづりを使うようになった。これは今に至るまで変わることはない。
【注】(*1)最近日本では自分の名前をローマ字表記するとき <姓> , <名> の順に書くことが推奨されているらしいが、私は first name を last name の位置に書くのは不自然な気がするので実践する気にはなれないでいる。
 ・姓名(full name)       例:Shun Kinoshita
 ・名(first Name)        例:Shun
 ・姓(family Name or last name) 例:Kinoshita

 初めて海外出張でアメリカに住むようになったとき、仕事場では仲間から“Shun”という名前で呼ばれるようになった。日本人は自分の名前はこう呼んでほしいなどと厚かましく他人に注文を付けたりはしない。大抵はアメリカ人の方が勝手に呼び易いニックネームを付けてくれるので、それに任せるのが普通である。私の場合は、名前が発音し易かったからであろうか、私の名(first name)がそのまま使われていた。アメリカの何処へ行ってもそれは変わらなかった。

 私の友人たちで長くアメリカに滞在している連中は、自分のアメリカ製ニックネームをミドルネームとして名刺に印刷している者もいた。私も素敵なニックネームを付けられたらそれをミドルネーム風に使いたいと思ったのだが、願いは叶わなかったようである。

 アメリカ人のニックネームの付け方は、単に first name の先頭文字を採用してアメリカでよく使われるニックネームで代用することが多い。日本名が“K”で始まると“Ken”あるいは“T”で始まると“Tom”という具合である。これではびっくりするような命名は期待できないようである。私は“Shun”で良かったと思ったものだ。

 ニックネームの付け方は、総じて短い名前にすると便利であるらしい。3~4音程度の方が呼び易いからである。先頭にアクセントを置き、遠くから声をかけるときは大きな声で一部長音を交えて少し長くすると呼び易くなることを学んだ。“Shu...n !”という具合である。

 私は毎日のように“Shu...n”と呼び掛けられていると、やっと自分の名前にも慣れてきたような気がした。オフィスの長い廊下の先にコーヒーメーカーが置いてあるコーナーがあるのだが、その場所に居た仕事仲間のアメリカ人が遠くから私を見つけて「シューン !(Shu...n !)」と尻上りの大声で呼び掛けられたことがあった。そのとき、自分の名前も結構良いものだなと感じたことを今でもときどき思い出す。

▼ポーランド人の名前
 話は大きく飛ぶが、コンピュータのソフトウェア開発に詳しい人なら「逆ポーランド記法」というのをご存じかと思う。特にプログラム言語のコンパイラ開発に携わった人なら必ず知っておく必要のある記法である。

 ポーランド記法(Polish Notation)というのは、数式やプログラムを記述する方法の一種で、演算子(オペレータ)を被演算子(オペランド)の前に記述することによって括弧( )を用いなくても演算の優先順位を表記できるようにした記法である。コンパイラ開発で必要となるのは演算子を後に置く「逆ポーランド記法(Reverse Polish Notation)」の方であるが、これを考案したのは、ポーランド人の論理学者 Jan Lukasiewicz である。この英字表現では本来のつづりを正確に表すことができないので1字間違っている(正確には以下を参照されたい)。発音の方も難しくて、日本語のカナ表現で書くと“ヤン・ウカシェヴィチ”がそれに近いと思われる。

 本来であれば、彼の名前を冠した
ウカシェヴィチ記法(Lukasiewicz Notation)
と命名される名誉に浴したはずなのだが、そんな難しい名前では誰も読めない(!)として、生みの親がたまたまポーランド人だったことから“ポーランド記法(Polish Notation)”とされてしまったのである。

 業績として名前を後世に残したければ、自分の名前が容易に読めて かつ誰でも簡単に表記できるつづりであることが望ましい。それだけでも、かなり有利となることが分かる。
 しかし自分の名前というものは、大抵は自分一人では決められないものである。私は兼ねがね親から一言事前に相談があって然るべきだと思っていたのだが‥‥。

 業績が名前の如何で決まるのは困るが、本当に必要とされるのは専門分野の研究に向いている若干の才能と、長い長ぁ~…ぃ努力の時間とが必要であることは言うまでもないことであろう。

2021年10月4日月曜日

最後のコンピュータ




── 愛用のパソコンが壊れました


▼コンピュータの暴走
・2021年8月27日
 私の愛用しているパソコンに異常が生じたようである。最初の兆候は、使用中のアプリ(エディター)で画面スクロールが突然繰り返されるようになってしまったことである。キーやマウスに何かが触れているのではないかと確認してみたがどこにも異常はない。プログラムが暴走しているのだ。これはまずいと思って私はコンピュータの使用を一時止めることにした。

 コンピュータの本体が異常に熱を帯びている。一晩休ませて明日の朝もう一度確認してみることにした。長く使ってきたコンピュータだったからそろそろ寿命が尽きる頃だとある程度の覚悟はできていたので、私は早くも保存しなければならないファイルは何か と考え始めていた。

・2021年8月28日
 翌朝、コンピュータ本体に電源を入れる前に私は大型の扇風機を持ってきてノートパソコンの右側部分(一番熱を発しやすい場所)に強い風が当たるようにして本体の熱を逃がす工夫をした。(つづく)

続きを読みたい方は、ここをクリック



2021年8月31日火曜日

今だから話そう カナ表記過敏症




── ソフトウェアの表記について考える

男ありけり

   昔 男ありけり
   コンピュータ業界で、
    外来用語の日本語化に注目しながらも、
    男 それを実践することなく過ごせり
   インターネットの時代、
    男 用語のカタカナ表記にどっぷりと浸かりけり
   その後遺症か、カナ表記法に過度の関心を持つに至れり

コンピュータ用語の日本語化
 コンピュータ開発の初期の頃の話である。初期と言っても黎明期のことではなくプログラム言語の標準化が求められるようになった頃(1974年?)のことと記憶している。
 新しい技術の導入に当たって海外の文献を参考にしていると、当然のことながらたくさんの見慣れない外来用語の氾濫となる。それらを日本語化するに当たり適当な日本語訳がないと、取りあえずカタカナ表記にして済ませてしまうことが多くなっていた。しかし、意味不明のカタカナ用語ばかりでは一般の利用者に理解してもらえないだろうという反省も生まれてきた。

 歴史のある学問分野、たとえば数学などでは立派な日本語の用語が存在し広く使われてきている。コンピュータ用語もそれを見習ってそれ相応の日本語を作らねば、という機運になったのは当然の成り行きであった。

 最初に問題になったのは“software”の日本語表記である。“柔物(やわもの)とか“紙物(かみもの)とかが提案されていた。“hardware”が“金物(かなもの)として既に使われていたから、・・・・・・・(つづく)


続きを読みたい方は、ここをクリック