kiritterのブログ

IT業種。好きなもの 音楽(Rock,House,Trance,etc) 読書(実用書) 歩くこと 日本史 スノボー など。現代社会がこの先どう進んでいくのか興味津々の今日この頃。(Twitter : kiritter)

Leafletで地図サイトを作りました

昨年、下記の本と出会い、シンプルなサイトであれば自分にも作れることを知り、
初めてWeb地図サイトを作りました。(フロントエンド実装のみの閲覧専用地図)


元々、GoogleMapを頻繁に利用し、知らない場所があればその位置を調べ、
行ったことのない場所は距離を測って移動時間を把握したりすることが日常茶飯事だったため、
自分の手元で地図を好きなように表示できることに大変興味を惹かれ、
まずはちょっと試してみたい、表示だけでもさせてみたい、というのが発端でした。


いざ始めると、アレを実現してみたい、コレを実現してみたいと徐々に実装していく形となり、結果として、

  1. ベースとなった1サイト
  2. それを元にした具体テーマの3サイト
  3. 変化球的な1サイト

の合計5サイトを形にすることとなりました。


①『時期と距離の比較地図』
kiritter.github.io
最初にアタマにあったのは、真ん中の線を左右にドラッグするとその場所の変更前後の姿が見える、
というものを自分でも作ってみたいと、まずはそれを実現しようとしたものです。

当初は、高度成長期を念頭に、地理院地図の年代別空中写真(航空写真)の60年代と70年代だけを左右に固定表示するものでしたが、
せっかくなら公開されているすべての年代を載せたい、
さらにはもっと古い時代とも比較したいと、日本版 Map Warper の「五万分一地形圖」(旧版地図)(戦前期の地図)も表示できるようにしました。
個人的には大阪北部の丘陵地帯がニュータウンとして開発された姿が見えて、地理面と現代史面で理解が深まり役立ちました。


その後、地図上で大きさや距離がつかみやすいよう、目安となる距離の同心円を表示するようにし、
それを利用して、異なる2つの場所の大きさを比較できるようにしました。
住んでいる町と旅先の町を比較して、巡る所要時間をざっくり推し量ったり、
阿蘇山の中心に新宿駅を置いたらどの程度の広さになるだろうかといった好奇心による確認に利用。


最後に、覗くだけでも楽しめるよう、
いくつかピックアップした事例をすぐ閲覧できるよう「事例一覧」を用意しました。

事例内の番外編として下記も掲載。
ダム湖百選」(ダムができる前と後の姿が見られる)
日本百名山」(陰影起伏図を重ねて見ると場所もはっきり)


なお、比較というテーマとは無関係ですが、通っていた小学校の当時の姿が見えて、非常に懐かしかったです。


②『陰影起伏図で見る古墳マップ』
kiritter.github.io
陰影起伏図を半透明にして航空写真に重ねると、前方後円墳の姿が浮かび上がることから、比較地図の事例一覧として「番外編:前方後円墳」を載せていました。
しかし、自分で見たり、データ追加するのに不便だったため、分割して独立したサイトにしたものです。
専用化したことで、大きさランキングといった一覧も載せられるようになりました

また、古代の時期を模した海面上昇イメージも付けることで、
古墳がかつてのラグーン(潟湖(せきこ))沿いの高台にあることが見えたりと理解が深まりました。

今後新しく学んで得た知識を随時メモできる場所が作れたという思いです。


③『街道浮世絵マップ』
kiritter.github.io
中山道はどこを通っているのだろう、ルートの中間の大半を把握していないと気づいたことをきっかけに、『東海道五十三次』『木曽海道六十九次』の浮世絵を見るたび、どの絵がどの場所のものかパッとアタマに浮かばず、毎回ストレスを感じていたことを思い出し、その2点を解決しようと、
ざっくりとルートがわかるよう、宿場を線で結びつつ、宿場の位置に浮世絵を表示するようにしたものです。

陰影起伏図や旧版地図(戦前期の地図)で表示できるようにすることで、
よりはっきりとルートが見えるようになり、役立ちました。


④『おくのほそ道:芭蕉行きて帰りし物語マップ』
kiritter.github.io
奥の細道」が見事な構成をもった文芸作品、かつ、芭蕉の「行きて帰りし物語」であることを知って大変感動したことが大元の発端で、
その構成を可視化したい、
またそもそも、私自身が東北や北陸の土地勘がないことから、ルートをアタマに思い浮かべることができなかったため、
より実感を持って芭蕉の旅を辿りたいという思いで作りました。

こちらも陰影起伏図や旧版地図(戦前期の地図)のおかげで、
特に後者では当時の町の姿や主要な道の姿が雰囲気的に伺えて、ルート確認に大変役立ちました。


⑤『歴史年表地図:地図で表現するタイムライン』
kiritter.github.io
歴史そのものをテーマにした、変化球的な地図サイトです。
大元の発端は、十数年前にExcelで年表を作り、縄文時代の圧倒的な長さと遠さを実感したことです。
縄文土偶が信じられないくらい遠い過去に作られ、それが今に残って目にすることができている奇跡さに感動しました。

当時感じた問題点などが、Web地図の仕組みを利用すればある程度解決できることに気づいたことから、
新幹線の鹿児島中央新青森間の実キョリを年に換算し、それを時間軸とみなすことで、年表として表現したものです。


当初は発端となった縄文時代以降を見せる年表でしたが、

  1. 有史に着目した直近2000年間を見たい
  2. 縄文時代に先行する、日本列島の現生人類の歴史の出発点となる後期旧石器時代以降でも見たい
  3. そもそも地球誕生からの全体を見てみたい

という思いから、割り当てる時間範囲を上記の種類で切り替えて表示できるようにしました。


当初は主な出来事をいくつかだけ目安に載せるつもりが、それだけでは全然不足感を覚え、特に有史は改めて通して復習しながら、主な出来事をピックアップして載せました。
この作業によって、これまで出来事としては知っていたものの、時間軸上のどの辺りの話なのかよくわからず、アタマの中にバラバラに入っていた情報が1つの時間軸上で整理され、とてもはっきり理解することができ、古墳マップ同様、今後新しく学んだ知識を随時メモできる場所が作れたという思いです。

個人的には、これまで見聞きする一方で何もアウトプットにつながることのなかった歴史趣味を、サイトとしてカタチにすることができたことが大変嬉しい思いです。


以上、昨年着想着手した地図サイト5つを一旦作ることができたという区切りとして、本記事として記しました。
(久しぶりにシゴトではなく自分自身の興味のために実装作業したことは、苦しいながらも、楽しい時間となりました)


以下、今回の地図サイト作りにあたり、新規で読んだり、改めて手に取ったりした参考文献です。


①『時期と距離の比較地図』

↑自分なりの地図を作りたいという後押しとなりました。
また、距離の同心円を表示するきっかけにもなりました。


②『陰影起伏図で見る古墳マップ』


④『おくのほそ道:芭蕉行きて帰りし物語マップ』

↑2015年に上記の本を読み、おくのほそ道に抱いていた旅日記という印象がまったくの見当違いだったことを知り、文芸作品としての構成の巧妙さ、美しさに大変感動したことが、おくのほそ道の地図サイトを作ったおおもとのきっかけです。↑上記の最後の1冊は、おくのほそ道の旅のエピローグ、大垣から伊勢神宮へ向かったその経路を載せるために読みました。
過去、紀伊半島にたくさんの街道と賑わいがあったことを改めて実感する機会となり、時代の移り変わりにしばし思いを馳せました。


⑤『歴史年表地図:地図で表現するタイムライン』
■先史時代

個人的に日本の先史時代が最も興味深いテーマですが、今回作った年表地図では、具体的な年指定を要するため、年をはっきりさせることがしにくい先史時代の出来事はなかなか時間軸上に載せにくい面があり、載せる位置に悩みましたが、載せないことには何の参考にもできないため、割り切って、目安となるよう区間の先頭だったり中間だったり見栄えのバランスも踏まえて載せました。


■日本史全般や特化テーマ

↑伏見が港町であることを知り、なぜ京都南部郊外の伏見という場所が栄えたのだろうと気になっていた点が解消された一冊です。↑自分が日本の歴史を全然わかってなかったことに気づかされ、歴史に目を向けるようになった思い出の本です。↑読了後、春はあけぼのという冒頭を目にするだけで涙が浮かぶ状態になりました。


■地球史

↑2015年の夏、若狭三方(みかた)縄文博物館を訪ね、現地で初めて水月湖のことを知り、直後に出版された上記の本で詳細内容を知りました。
縄文時代をはるかにさかのぼる5~7万年という時間軸に気が遠くなると共に、初めて縄文時代より前の時代に目が向く機会ともなりました。

リズム譜を書くことで、音楽とざっくり同期を取って何かするためのJavaScriptライブラリ(の暫定版のExample)

久しぶりにポストします。
時間が過ぎるのはあっという間で、朝夕はもうすっかり秋の気配。

前回に引き続き、JavaScriptの話題で、個人的欲求から作った遊び道具に関する話です。


作ったのは今年の2~3月で、もろもろ落ち着いたら全般的に見直そうと思っていたものの、諸事情によりできないので、一旦、Exampleのカタチで上げて一区切りという感じです。


作ったもの (※Google Chromeでのみ動作確認済み)
KiRhythmbox v0.8 - Simple Example - JavaScript Library


音楽が好きで、かつ、FlashやProcessingといったプログラミングによるアニメーションに興味があったりすると、一度は、音楽と同期を取って動かしたい(音楽に合わせて動かしたい)と思うんじゃないかなとか思ったりしますが、とりあえず私がそうだったのですが、ともかく、Chromeという爆速ブラウザが作られたり、HTML5でaudio/video要素が新設されたりで、ブラウザ上でJavaScriptだけでそういうのができる感じになってきてワクワクしつつも、とりあえず過去やってみたのは、setIntervalによる、ざっくり4つ打ち同期程度。


もっと複雑なリズムに、簡単に合わせることはできないだろうか?
音ゲーとかは厳密に微調整できる仕組みを作っているのだろうけど、
ざっくりで良いので、(ブラウザとJavaScriptで)簡単に音楽に合わせて遊びたい。

どうすればそれができるかよくわからないまま(考えないまま)月日が過ぎ、
で、今年の2月のある金曜夜、ふとYouTubeで、上述のExampleで使っているPVを見たのがきっかけで、改めて音楽同期描画の件を思い出し、挑戦してみたくなり、そのまま徹夜で書いたのが原型です。


当日たどり着いたアイデアは、

  • やりたいこと(描画処理)をfunctionとして書く
  • 耳コピしたリズムを元に、小節に見立てた配列に、それらを配置する
  • BPMから求めた間隔で、配列内のfunctionを、setIntervalで順番に呼んでいく

これにより、BPMを調べて、描画処理とリズム譜さえ書けば、あとはうまいこと描画してくれる感じになると。


具体的には、以下のような感じです。

  • やりたいこと(描画処理)をfunctionとして書く
  var k1 = function() {
    var el = document.getElementById("k");
    el.style.opacity = 1;
    var timerId = setInterval(function() {
      el.style.opacity -= 0.03;

      if (el.style.opacity <= 0.1) {
        clearInterval(timerId);
        timerId = null;
        el.style.opacity = 0;
      }
    }, 10);
  };
  • 耳コピしたリズムを元に、小節に見立てた配列に、それらを配置する

以下は、キック4つ打ち、2拍4拍でスネア、というイメージ。
シンセサイザーやDTMで「打ち込み」の経験のある人には見覚えのある見た目かなと。。

  var bar1 = {
    tr1  : [k1, __, __, __,  k1, __, __, __,  k1, __, __, __,  k1, __, __, __]
    , tr2: [__, __, __, __,  s1, __, __, __,  __, __, __, __,  s1, __, __, __]
  };

ポイントは、

  var __ = function(){};

という空っぽのfunctionを用意して、上記のように埋めることで、
setInterval側では、ひたすら16分音符の間隔で呼ぶようにしている点。

  • 最後に小節を並べてリズム譜は完成
  var score = [
    bar1, bar2, bar1, bar3
    , bar4, bar5, bar4, bar6
    , bar7, bar8, bar7, bar9
    , bar7, bar8, bar7, bar9
  ];


音楽側は、audio/video要素なり、YouTubePlayerAPIなりで、音楽を再生し、
それと同時に、本ライブラリのplay()を呼ぶ、というカタチです。
残念ながら、音楽と描画の開始タイミングを、プログラミングで厳密には合わせられそうにないので手動のもろもろが入りますが・・・。(audio要素だったらそこそこ大丈夫だったかも?失念)


Chromeのタイマーは精度が高いらしく、今回のExample程度の短時間ではほとんど問題なく動いてくれます。
(※Google Chromeでのみ動作確認済み)

経過時間の概念を組み込みたいとか、今見直したら妙な箇所もいろいろありそうとか、いろいろ思うところありますが、諸事情につき、しばらくはできないので、その他もろもろ含めて全般見直しは、いつかの楽しみに取っておこうと。(^_^)

そんな感じで、久しぶりのポストまで。

JavaScriptでバイナリデータ(MP3のID3タグ)を読んでみる

大変ごぶさたしています。
気づけば、最後にブログを書いてから、1年近く経ちました。
この間、たくさんの出来事があり、
ともかく、十数年暮らした東京を離れ、Uターン直前の時期だったりします。

その話はまた別の機会として、本題です。


超久しぶりにブログを書こうという気持ちが生まれたところで、
今まで本や音楽の記事しか書いていませんでしたが、初めてJavaScriptの内容にしてみました。

さて、今さらなのですが・・・
数ヶ月前、JavaScriptで、Javaのbyte[]とほぼ同じカタチで、
バイナリデータを操作できることを知りました。(^^;)

とうとうJavaScriptでそこまでできるようになったか~と感慨に耽りつつ、
ぜひ何か読み取ってみたいと思い、そこで思い当たったのが、MP3。
MP3に埋め込んだID3タグのデータ(楽曲名やジャケット写真)が抜き出せるなあ、と。
(ただ単純に自分の楽しみとして書いてみたいと)

その後もいろいろそれどころじゃない状態が続いていましたが、
先日ようやくちょっと時間ができ、気分転換にJavaScript書きたい!と、
ID3仕様を拾い読みしながら、もろもろ決め打ちしながら書いた次第です。


動かせる状態で公開してみました。
(装飾していないので、見栄え良くないですが・・・>< )

http://kiritter.github.io/jsID3/


四角の枠内に、MP3ファイルをドラッグ&ドロップすると、
画面下部に、楽曲名やジャケット写真が表示される、というものです。
(そのMP3に、ID3v2.3で、それらのデータが埋め込まれていたら)

JavaScriptで処理しているだけなので、
つまりサーバーに送信したりはなく、ブラウザ上での処理なので、
また、MP3を更新したりもないので、
手元にMP3があったら気軽にドロップしてみて下さい。

制約がもろもろあったり、Chromeでしか動作確認していなかったり、なので、
うまくいかない場合も多々あると思いますが・・・m(__)m
(特に、邦楽曲はShift_JISで書かれていたりして、文字化けします)
(あと、少なくとも IE9以下では動かないです。。(^^;) )


以下のような流れで、ドロップしたMP3ファイルのバイナリデータを、bytesから読みました。

    (略)
  var reader = new FileReader();
    (略)
  reader.readAsArrayBuffer(file);
    (略)
  var bytes = new Uint8Array(arrayBuffer);


とりあえず、決め打ちながらも読めたぞ、というところで書くのをやめました。。


<今回の話に関係する本>

オブジェクト指向JavaScript

オブジェクト指向JavaScript

読みたいなあと横目で見つつ、読めずにいたこの本、数ヶ月前にようやく読みました。
とても読み易い内容で、楽しみながら読みました。
JavaScriptパターンの著者だと後から気づきました。
最近、JavaScriptの本が多く出ているので、それらも全部読みたいのですが・・・。


プログラマのための文字コード技術入門 (WEB+DB PRESS plus) (WEB+DB PRESS plusシリーズ)

プログラマのための文字コード技術入門 (WEB+DB PRESS plus) (WEB+DB PRESS plusシリーズ)

こちらも、各種の情報が1冊に凝集されていて、とても楽しく拝見し、大変ためになりました。


<最近のお気に入り楽曲>

Dinka - Constant Sorrow (original mix) - YouTube

ただただ沁みます。


というわけで、ブログを日常的に再開できるのはまだ先になりそうですが、
ひとまずは約1年ぶりの投稿まで。

「ボタンを押して下さい」という表現の曖昧さの話

 

「合図があったら、このボタンを押して下さい。」

 

この指示内容に何か曖昧なところがあるだろうか。

無さそうに見えて、あった。

 

とある開通式的なイベントで、偉い方が現場の装置のボタンを押すという演出があり、その際に冒頭の指示の曖昧さが顕在化した。 

何が起きたか。

そのボタンは、ぐうぅぅぅぅぅと長押しされたのだった!!

 

その操作はあまり望ましくはないものだったようで、現場ではちょっとした騒ぎになったとのことだったけど、実害は何もなく、まあ、ある種の笑い話としてお聞きしたお話。

 

なるほど、ちょっとした緊張感や、確実に押そうという意識から、そのような長押しになったのかもしれませんねとそのときは言ったけど、先日、身近なところで同じような状況に出くわした。

 

それは、両親と携帯電話にまつわる話。 

「○○ボタンを押しても、(説明書の内容とは)違う画面が出てくる」

 

いやーそんなことは無いだろうと思ったけど、
原因は、そう、「長押し」していたのだった。

 

そんな出来事から、冒頭の話を思い出し、
なぜ長押しするという行動になるんだろう??と思った。

 

 

最初は、安直に、世代(年齢)によるものかな、と思った。

しかし、よくよく考えてみると、両親だって、テレビのリモコンは使うし、電子レンジも使うわけで、「ボタンをプチッと押す」という感覚は知っているはず。

 

で、思い至ったのが、
「押す」という表現にはそもそも、「ぐうぅぅぅと長押しする」イメージが含まれているんじゃないかということ。

 

雪道でクルマを押す。

朱肉をつけてハンコを押す。

日常生活で何かを押すときは、大抵「押し続ける」ような気がする、と。

 

というわけで、
日常生活で「ボタンをプチッと押す」という感覚は知っているはずだけど、
いざ、「普段は見ることもない仰々しい装置のボタンを押す」とか、
「携帯電話という比較的最近の、自分には馴染みのない機械のボタンを押す」ということになったときには無意識に、
「いつもの『押す』」=「ぐうぅぅぅと長押しする」の行動になるんじゃないだろうか、
それは確実に押そうという意図も込みで、と思った。

 

 

というわけで、

「長押し」というUIは、あまり良いアイデアじゃないぞ、
「通常の押す」操作を上書きするという面で、とか思った。

ポンッと押しても、長押ししても、同一の挙動をするのが望ましいなと。

さらに、これ以上押し続ける必要は無いですよと分からせるためにも、
押されたら何かしらすぐに反応を示すのが良いと。

 

そんなことを思いながら、今夜は久しぶりに、すき家でカレーを食べました。。

 

あのよく分からないモノたち - 書籍紹介 - 現代アート、超入門!

先日の哲学入門と状況が少し似ているけど、

関心はあるのだけど、どこから入って良いやらよく分からない、

そんな世界へ道筋をつけてくれる本というのはとても有難い。

 

そういう本って、

その世界に通じた人じゃないとなかなか書けないものだし、

分かっている人により詳しく解説するのではなく、

よく分からないと思っている人を導くのだから、

その辺りの機微にも通じていないといけないし。

 

そんなわけで、とてもおもしろく読めたのがこの本。

 

『現代アート、超入門!』 (藤田令伊、集英社、2009)

現代アート、超入門! (集英社新書 484F)

現代アート、超入門! (集英社新書 484F)

 

現代アートの源をどこに置くかについては、必ずしも統一見解はないが、

このフォーヴィスムあたりを一つの源とする意見が比較的多い。

という「フォーヴィスム(野獣派)」のマティスを起点に、

1章につき1つの作品紹介という形で、

作者の考えや作品の位置づけ、その時代の背景等を、

現代に向かって時代を下りながら、現代アートの大枠の流れが解説される。

 

解説している現代アートの流れはきわめて大ざっぱなもので、

かつ、私の独断的視点によるので必ずしもバランスがよいとはいえないかもしれない。

と前置きされているが、

「わかったつもり」にはぜひなっていただきたいと願っている。

とのことで、確かにそんなつもりになれた気がする。

 

個人的に、一番おもしろかったのが、デュシャンの『泉』の章。

なるほど、そういうことだったのか。

目の前の物理的なモノの外観をいくらつぶさに観察したところで何も見えてはこない。

 

というわけで、具体的な内容紹介は省略するけど、

アートというものに向き合うスベを何も持っていなかった私には、

シンプルで骨太のガイドになってくれた気がする有意義な本だった。

(この本のテンションで、もう少し深く広くだったらもっと良かった!)

 

というわけで、自分の視野を広げる類の読書。

 

仏教的なものに対するモヤモヤ感への丁寧な説明 - 書籍紹介 - 史上最強の哲学入門 東洋の哲人たち

今まで熱心に追い求めたことがないから当然のことではあるけど、それはともかくとして、
「仏教的な話って、字面上分かったようになるけどその実、全然よく分からん」
と、長年モヤモヤのまま放置していた内容に対して、
この本以上に親切に丁寧に説明してくれた本に今まで出合ったことが無かった。

 

もちろん、この本の表現を借りるなら、
だけどそれは「ホントウはわかってないだろ」の状態であるのは間違いない。
それは確実。
何故なら、何ら「体験」できていないため。

 

そして、そうやって字面上わかった気になることこそ「ホントウにわかる」から遠ざかる道、
というのも字面上分かるのだけど、
それでも、現代に生きる市井の人間のひとりとして、字面上分かるだけでも随分助かる。
入り口のモヤモヤが晴れたというだけでも。
いや、まあ、字面上も、分かったかどうか怪しいものだが・・・。

 

というわけで、この本の存在をここに紹介だけでもしておきたい。

 

『史上最強の哲学入門 東洋の哲人たち』 (飲茶、マガジン・マガジン、2012)

史上最強の哲学入門 東洋の哲人たち (SUN MAGAZINE MOOK)

史上最強の哲学入門 東洋の哲人たち (SUN MAGAZINE MOOK)

 

いや、表紙がちょっとすごいですよね・・・。
最初、店頭でこの本を見たときは、「うわー、また新手の本が出てきた」と思った。
完全にネガティブな意味で。
だからその日は完全にスルーだった。
で、後日、各種の縁で、後述の西洋哲学の本を手に取るに至り、
そこから、本書も手に取った次第。 

 

最初からもう率直に伝えてくれる。
この本を読んでもきっと「理解」できないよ、と。
西洋哲学は「理解することが難しい」けど、「不可能」という意味ではない。
しかし、東洋哲学は少なくとも読書することで理解に達するのはまず「不可能」なんだ、と。
そこから長い長い話が始まる。

 

が、この厚い本、ぶっちゃけ最初に出たひとつのことを繰り返し手を変え品を変え説明し続けているようなものだ。
それは他でもない東洋哲学がそういうものだからだ。
何しろ東洋哲学では最初にもう「答え」が出ているようなものなのだ!
後は如何にしてその境地に皆を連れて行けるか、同じ体験をしてもらうか、それに尽きるという話になる。
いやはや、後述の西洋哲学の本を読んだ後では、これはもう確かに「何とも不遜な」という表現が分かる気がする。。
じゃあ、全然適当なことを言っているのかというと、それがまた驚くべきことに、そうじゃない。
西洋哲学が論理に論理を重ねてたどり着いたような場所にいきなり立っていたりする。 

 

個人的な趣味で、ピンポイントでひとつだけ内容に触れると、
臨済宗の栄西の章の「公案」での「隻手の音」のやり取り。
現代人にとってこれほど分かり易い説明もないんじゃないかと思った。
「弟子は真っ青になる。」
何だかその気持ちが分かった気がした。そりゃ真っ青になるよね・・・。
まさに、方法論の体系なのだということが簡潔に分かるやり取りだった。

 

 

この本を読む前に、以下の本を読んでおくと、
一見つかみどころのない東洋哲学を、
つかみどころのある西洋哲学に照らし合わせることができるような感じになるので、
というか、以下の本で説明された話も出てくるので、
併せておすすめしたい。

 

『史上最強の哲学入門』(飲茶、マガジン・マガジン、2010)

史上最強の哲学入門 (SUN MAGAZINE MOOK)

史上最強の哲学入門 (SUN MAGAZINE MOOK)

 

 

さて、西洋哲学にしろ東洋哲学にしろ、
そういうことを考えて一体何になるのよ、という問いかけに対しては、
とりあえず、ストレートにいえば、人類にとって不要なことだとはまったく思えない、
という感じでしょうか。 
何しろ、人類がより良い状態になるために、
(それがその人個人の問題から出発していたとしても、)
考えている、考えてきた、その結果、蓄積だと思うため。
直接的にしろ、間接的にしろ、その恩恵は巡り巡って受けていると思うため。

まあ、何事も適材適所の役割分担だという気持ち。
とりあえず、○○原理主義、というのが一番厄介。 

 

というところで、おわり。

 

しかし、こうして、各時代のいろんな人の話を聞くと(説明されると)、
ある種のスッキリ感が出てきた。 
いや、すべて解決してスッキリ、というスッキリ感ではなくて、
(何しろ、何も解決はしていない、) 
こういうところにたどり着いているんだなあということを知ったスッキリ感というか。 
このスッキリ感を礎にして、先に進みたい。 

キリがないので、おわり。

 

もろもろの話題 - アブダクション

ひょんなことから、アブダクションという思考法の話を思い出したので、書き留めておく。

システム開発・運用保守に携わる人には、馴染み深い思考法ではないかと思う。
その名前は知らなくても。 

 

自分の好きな古代史の、ひとつのキーワードである「たたり」を例に記してみる。
(例としてあまり気持ちの良い話ではないけど・・・ひとつの話題でつながったので・・・)

 

悪事を働いたA氏は大切な息子を失った。
悪事を働いたB氏は重い病気を患った。
悪事を働いたC氏は急死した。
ゆえに、悪事を働いた者には災いが降りかかる(だろう)。

 

  • 演繹

悪事を働いた者には災いが降りかかる。
D氏は悪事を働いた。
ゆえに、D氏には災いが降りかかる。

 

ライバルをだまして殺害したというE氏が急死するという事態が起こった。
もし、非業の死を遂げた者はその恨みを晴らすべく仕返しにやってくるのだと考えると、今回の出来事は当然の帰結だ。
ゆえに、そういうことがあるのだ、と考える理由がある。
(信じられるので、それを「祟り」と呼ぼう) 

 

 

アブダクションの有名な例としては、大陸移動説の話。

大西洋を挟んだ両大陸の海岸線が似ているという事実が浮かび上がった。
もし、元々ひとつの大陸だったものが分離したのだと考えると、今回の事実は当然の帰結だ。
ゆえに、大陸が分離するという考えが真であると考える理由がある。

 

 

さて、なぜ、システム開発・運用保守に携わる方に馴染み深いかといえば、
バグ修正・トラブル解決で、無意識にこの思考法を使っていると思うため。

 

あるデータが更新されていないという障害が発生した。
もし、○○をしたときに△△していないならば、これは当然の帰結だ。
(ゆえに、○○のときに△△していないのが原因だと考える理由がある)
よし、○○のときに△△しているかどうか調べよう。
あっ、していない! これが原因だ。 修正!

 

一応、そのつづきの話として、

○○のときにしていないなら、●●のときでもしていないんじゃないか、
このようなことが起きるなら、□□ということも起きるんじゃないか、
今回のようなことを防ぐには、こういうことをすればいいんじゃないか、
そんな風に連鎖していったりなど。

 

おわり。