Drafts

@cm3 の草稿置場 / 少々Wikiっぽく使っているので中身は適宜追記修正されます。

語り得ぬことの輪郭

昼食でハーバードの目の前の「山頭火」でラーメンを食べた。東アジア研究者Pさんが「こっちのラーメンはまずい」と言ったので、検証してみようと思い立ったのだ。

  • スープの旨味が少ないこと
  • 添えられた野菜が薄めの葉物野菜であり苦みが際立ってしまうこと
  • 油っぽさが強く感じられること

が悪い部分で、

  • 分厚いがとろけるようなチャーシュー

は日本より良かった。総評としてそんなに批判するほどではなかったと感じた。同僚が「そんなに悪くなかったよ」とPさんに伝えたところ、「(日本人の)妻がこっちのラーメンは不味いと言っているので、それに同調してる部分もあるかも」とのこと。まあそれも Yet another 同調かもしれないけどね。


その昼食の時に、中国を対象とした研究について博士号を取得したばかりの学生に対して、同僚がアドバイスをしていて、なるほどと思ったのが、自由に写真が撮れずや文章が書けない国についての語りの偏りについて。

それはつまり、社会主義的な規制による部分や、識字率についての部分など、つまり表現の背景にある広義の資本がその偏りを生み出し、歴史研究をするときにはその偏りが語りの限界を生むということ。

そこで思い出したのが冒頭に張ったウィトゲンシュタインネタ。どうやったら、なんのために、語り得ぬことの輪郭を得ることができるだろうか。

そもそもこの論題は、語り得る/語り得ぬのバイナリ―ではない。何かを「語る」ということは、(誤解を含めた)コミュニケーションのなかで相互理解のメタ認知が得られることを指す。その相互理解のメタ認知はコミュニケーションの参加者それぞれで共有される部分が微妙に異なり、ぼやっとした相互理解の全体像が生まれる。正確性についても、事実性への信頼基盤=Plausibilityの認知基盤が社会で均一に保持されているわけではないため、ぼやっとした事実性評価の全体像が生まれる。輪郭は線ではなくグラデーションである。

三宅教授をはじめとして、「間」を研究している人たちのその「間」という概念にも通じるところがある。このグラデーションを描くことというのが、輪郭を得ることになるのではないかという直観を得た。

では何のために描くのだろうか。それは全体像をつかみたいという飽くなき研究者的探求心から来ており、「全体像」をつかむことが事実性への信頼基盤の醸成にもつながるだろう。でも一方でこれは矛盾していて、全体像など常につかみ得ないのだ。画一的な全体像などない。それがグラデーションを生み、輪郭を描き出す方法を支えるのだから。その描き出す活動自体が相互理解を作り、そこにすでにある相互理解が語り得る「全体像」なのだ。

この直観とウィトゲンシュタインの言ったこととの間の距離は近いと思うけれども、表面的には逆のことと言っている。つまり、間を語らないことによってはっきりと輪郭が見えると、上の漫画はそう言っている。そこはまあ、後期ウィトゲンシュタインをちゃんと読んでから考える。


追記:ちょうどたまたま(?)「社会調査とか歴史的資料を読むことですら根元的解釈から大きくかけ離れた(すでに非常に多くの事柄がお互いにわかっている上で可能となるやりとり)営みだ」という記述をけんさんのブログで見かけたので、上の文脈で考えると、

  • 多くの事柄がお互いにわかっている
  • 「多くの事柄がお互いにわかっている」とわかっている

は別で、後者は特に前提とされないし、それを先行させることはできないことが多い。で、「多くの事柄がお互いにわかっている」ことはコミュニケーションが成功裏に繰り返されて初めて明らかになる(=「多くの事柄がお互いにわかっている」とわかる)。でも、後者がすでに満たされているならば、コミュニケーションは円滑に行く(デイヴィッドソンの信念と意味とコミュニケーションの3項補完の話)。

ここでの信念のコミュニケーション前存在をあまりに重視することが、3項のうち1項を固定しているような印象をうける。もちろん、個々のコミュニケーションよりそれを可能にするシステムの方が相対的に Static なんだけれど、コミュニケーションの中で訂正・再構築されるべき部分もけっこうある。

デイヴィッドソンの言う「寛容の原理」というのは僕の理解では、コミュニケーションの成立が危ぶまれる場合、信念と意味の2項について肯定的な前提を一旦持ち込むことで(See: デフォルト推論@非単調論理 - Wikipedia)、コミュニケーションが成立し、信念と意味も確定しうるということを言っている。事実として信念が事前に共有されているなどということは言っていない。

ここでいう信念と、規範の関係について私見を述べると、信念のうち、中程度に Static なものが規範とされる。存在概念の存在などは重度に Static な信念であり、○○人が○○という特徴を持つことは軽度に Static な信念である(いまさらだが、ここでの「信念」は術語です。cf. 信念更新)。

そして、僕が毎回繰り返し言っているのは、規範の役割を(寛容の原理のようなメタな方法さえ持ち込まずに具体的に何か世界で単一で画一的な規範があるというかのように)拡大運用することで、コミュニケーションは失敗し、信念の更新も滞り、ただ規範を元から共有している人たちだけにコミュニティが縮小していく一方で、世界に断絶を生むと言っている。

ちなみに、デイヴィッドソンについては清塚邦彦、柏端達也、篠原成彦訳『主観的、間主観的、客観的』を昔流し読んだだけなので誤解があるかもしれない。

Shallow survey

is not shallowsurvey2015.org

浅瀬の調査のことじゃなくて僕の造語です。浅いサーベイ

What is it?

基本アブストと結論だけ読むタイプの浅いサーベイです。

What for?

自分のトピックに関係のある論文集合が見つかればそれをちゃんと読んで、まとめて、論文執筆につなげます。

そのひとつ前の段階に、自分の論文をいくつかの研究の流れに位置づけるためのその「研究の流れ」をサーベイします。それはAnnotated Bibliographyみたいな形から、場合によってはサーベイ論文のようにまとめられるようなもので、ある細かめの研究分野のまとまりに対して行われるものです。

さらにその一つ前の段階に、国際会議に参加したりして、なんとなく研究動向を把握したり面白い研究を発掘したりする段階がありますが、その、ザッと目を通す段階について、ただだらだら論文を眺めて読むだけじゃなくて、そのあとに繋がるようにちゃんと文献管理とかと結び付けた自分流の方法を確立していこうと思いました。

  • 本格的なサーベイに繋げたい
  • なるべくカンタンに楽しくやりたい

How to do it?

公開しない

「ポエム論文」「新規性0」みたいなコメントで済ませることもあるし、しかもそれを浅い読みで行うわけなので全然責任もって行えないわけです。気軽にやるにはローカルで済ませる。

いきなり文献管理ソフトに全件突っ込まない

価値のない論文もある状態で、まだ早い。ゴミを突っ込む手間が無駄。

余計なソフト使わずテキストで書く。1ファイル1テーマ。フォルダに全部雑多にまとめる。

その方が気軽。(僕が学際研究多いってのはあるけど)どうせ使うときにはテーマ横断的に使ったりするし、カテゴリーはそんなに明確なものではないので、各論文についてタグをテキストで書いておいて、フォルダ内を全文検索で見つける。そのために単一のフォルダに全部入れておく。

僕の基本的なフォーマット↓

# テーマ名(会議名、ある気になる研究者名…などなど)

説明

## サブテーマ名(年度やワークショップなど)

説明

### 各論文

- tag: [作業に関するタグ(例: wanna-read, finished-reading, not-found, ...)]
- subject: [カテゴリ的なタグ]
- uri: PDF の URLなど

#### 概要

概要

#### コメント

- コメント1
- コメント2

5/4 朝

  • 小学校の先生になってる夢を見た。一応名前は今のままで呼ばれているけれど年齢はもう少し上だったようだ。昨日読んだ本と対応しているのだけれど、その子の職業適性がすべて分布として見通せているときに、教育過程でどう対応するかみたいなことに悩んでいた。実際は、ある女の先生に惚れて構ってほしかったために仮病を使って、僕が無粋に本気で心配して困らせてしまったというイベントもあった。(Sさんに「夢日記つけてみたら?」と言われたので書いてみる)
  • 毎度のことだが合宿とかに来ると仕事がとても捗る。そして人生が幸せになる。一年中合宿していたい。メンバーが良いのかもしれない。
  • 風呂が2階についていて、Aさんが建築における風呂2階の合理性について説いていたのを思い出した。彼女は小学校の時に惚れて以来、今でもずっと素敵なのだが、その素敵さを支えているのにとてつもない自己肯定感があるのではないかと思った。
  • ここ一週間ほど、弱者に自信を与えるのは世の中を平和にするなぁと思っているのだが、テロリストに自信を与えるとヤバいので、難しいところである。

Atom の Markdown preview の色とかが気に食わないとき

Ctrl + , で表示される Settings > Themes > Your stylesheet へのリンク > css 編集

h2 と h3 の見分けがつかないなどなどデフォルトのは使いにくすぎる

とりあえずAtomエディタのMarkdown PreviewのCSSを実務書類的に調整する | 大石制作ブログを導入しておく

pre ブロックの中の文字色と背景色が一緒で文字が見えない

.markdown-preview:not([data-use-github-style]) atom-text-editor{
    color:black;
}

を追加した。

And more

Ctrl + Alt + iデバッグパネルが開くのでそれを見ながら任意の場所の css を上書き。

概念分析の社会学 ─ 社会的経験と人間の科学

1章30分でまず流し読む(そういう粗いことすると警察が来るかもね)

なお、章名は元の章名じゃないっす。俺が覚えやすいように書いてるだけ。

前書きなど

専門的概念も常識的概念と接続しないと我々は認知できない。そこの齟齬が現実と概念の間の相互作用を生み出す(ループ効果)

1章 人種

所謂リジッドな人種の科学的な裏付けは失敗しているが、遺伝座の遺伝子頻度相関は地理的にもクラスターが存在するので、連続性をもった新しい「人種」概念を持ち込んでルロワは人種があるという。それが理解できない(と僕は感じたので中指たてて読んでた)グッドマンがクソリプ返してるんだけど、まあ確かにこういう理論は悪用されやすいという問題意識は分かる。

種の概念については自然を名づける―なぜ生物分類では直感と科学が衝突するのかが超面白いよ、問題意識も本書と似てるし。

あと、「集団の生物学的特性を確率という形で個人に帰属することによっても人種主義は成立しうるからである(Gannett 2001)」ってのはそりゃそうなんだけど、信頼(もしくは信頼/安心)の議論と接続しないと、それが不適切であり得るだけでしょってことで、そういう不適切な概念活用が行われる過程の研究(冒頭 p.11 の「もう一つ」)に吸収されるだけな気がする。

2章 遺伝知識と疾患

出生前診断ルーマンのリスク/危険の区別で、技術によって後者が前者に移行した好例だね。

細かく具体的な記述はわかりやすく読みやすかった。

偶発性をどう捉えるかってところに大きな論点があって、そこに対して当事者同士の繋がりを持ち出すのははぐらかされた感もある(ロールズ的な正義論を期待していた)が、むしろそれが、どんな正義のもとでも疎外される人たちをどう救うかという点において示唆を得られてよかった。

ナビゲーション2

こういうのイイね(本の構成というメタな点で)。前にシンポジウムでも企画者が各講演のつながりについてナビしなきゃいけないって書いたけど、こういう多様な話をまとめて見せる場合も同じだな。

Electron アプリ開発メモ

Electron で ディレクトリ監視ツールを作ってる。その際に躓いた基本的なことをメモしておく。

Electron でアプリを作る基本

30分で出来る、JavaScript (Electron) でデスクトップアプリを作って配布するまで - Qiita

こちらをどうぞ。このひな形をどんどん書き換えていきました。

html / css / js は普通に書き換えられる

こういうウェブの技術で構築できるのが electron のいいところですし。

プロセス間通信

js を書いていると、main.js と html 側の js でやりとりしたいことが出てくるはず。ローカルでの計算結果を表示したりね。そういう時に、Electronでipcを使ってプロセス間通信を行う - Qiitaが参考になると思いきやこれはもう使えなくなっていて、

の2つを使う。前者は ipc と同じくプロセス間通信で、後者は main プロセスから html 側のイベントを取得したり、js を実行したりにも使える。

例:

main.js

mainWindow.webContents.on('did-finish-load',function(){
   mainWindow.setTitle("sample");
   mainWindow.webContents.send('message', 'Hello World!');
});

view.js(html側)

  const ipcRenderer = require('electron').ipcRenderer;
  ipcRenderer.on('message', function(event, message){
      var date_obj = new Date();
      var li = document.createElement("li");
      var span1 = document.createElement("span");
      span1.appendChild(document.createTextNode(zfill(date_obj.getHours(),2) + ":" + zfill(date_obj.getMinutes(),2)));
      var span2 = document.createElement("span");
      span2.appendChild(document.createTextNode(message));
      li.appendChild(span1);
      li.appendChild(span2);
      document.getElementById("message").appendChild(li);
  })

今回はシンプルなものを作っているので、jquery も react もなんも使ってない。生 javascript

BrowserWindow のタイトルを動的に書き換える

既に上の例に示しているが、'did-finish-load' イベントを受け取ってからタイトルを書き換えないと、非同期の問題で html に書き込まれた title タグを上書きできない。

参考:

BrowserWindow のメニューを入れ替える

Menu APIを参考に書く。こちらは右クリックメニューを作るサンプルがドキュメントに書かれているが、最後の Menu.setApplicationMenu(menu); を BrowserWindow インスタンスの mainWindow に対して、 mainWindow.setMenu(menu); と書き換えるだけで、上のメニューバーの入れ替えが実現できる。

例:

const Menu = require('menu');

var template = [
    {
        label: 'Test',
        submenu: [
            {
                label: 'console',
                accelerator: 'CmdOrCtrl+M',
                click: function(item, focusedWindow) {console.log("selected.");}
            }
        ]
    }
]

//mainWindow の定義はすでにコードに書かれている想定
//mainWindow = new BrowserWindow({width: 800, height: 400});
var menu = Menu.buildFromTemplate(template);
mainWindow.setMenu(menu);

参考:

引数のパージング

process.argv で引数を受け取れる。Python の sys.argv みたいなもん。でも注意しなければいけないのは、electron コマンドで起動してるときは、

electron [main.jsのあるディレクトリ] [引数]

となっているので、2以降を使うのだが、コンパイルして exe とかにすると、

hogehoge.exe [引数]

となるので、インデックスがズレるのだ。ちゃんと、commandernomnomあたりを使って、引数のパージングは実装したほうがいい。

参考:

配布

Windows 用にコンパイルするとこんなシンプルなプログラムでも 100MB を超えてしまう。それなら node.js や electron をインストールさせるインストーラを作って、メインはバッチファイルで作ってBat To Exe Converterみたいなので体裁整えた方が良い気がするかもしれないが、上記に書いたように、electron や nodejs がまだ進化中なので、その方法では electron のバージョン違いなどですぐ使えなくなる。諦めてコンパイルしよう。

GitHub 上でバイナリのリリースは Release Your Software を参考に。

Mac 用のコンパイルでエラー

Windowsmac 用のバイナリを作るときに Cannot create symlinks; skipping darwin platform というエラーが出るが、これはコマンドを管理者権限で実行する必要があるらしいです。

参考:

electron モジュールに組み込まれているモジュールの利用

Qiita に投稿したのでそちらを見てください→electron v0.35.0 以降は、electron モジュールを使いましょう -Qiita。要は

  • × const app = require('app');
  • const app = require('electron').app;

ってことです。

その他参考:

何を作ってるのか

Current Jazz の Danny Green の音がFFっぽいなぁと思って、そういやFFの決戦ってシマノフスキ交響曲にヒントを得ていると聞いたことあると思って、以下の3つをヘビロテしている

Szymanowski: Sonata No.2 Mov.2(Fuga)


Karol Szymanowski ‒ Piano Sonata No.2, Op.21

Danny Green: Thirty Springrolls Please


After The Calm - EPK

浜渦正志: FINAL FANTASY X 決戦


FINAL FANTASY X 決戦