Retired Colourman

何度も朝がやってくる

脳内の文章が実際に伝わる文章と乖離している話

自分の言語特性は割と歪というか問題があって、簡単に言えば脳内で正しい文章が出力されていない。 脳で考えてるときは問題なく言葉になっている(と思っている)が、実際にそれを書き表そうとすると出力にムラがあったりそもそも繋ぎが存在しなかったりする。短い言葉(Twitterで雑に書けるようなもの)は意識なく出力できるが、それ以上になると何処かで詰まる感覚がある。書くべき文章がわからない、というよりは、自分の頭に確かに存在しているはずの文章が実際には書き表せない、という感じ。なので文章を書くという作業が結構苦痛である。 では喋るときはどうなのかというと、多分これは僕の普段の話を聞いている人のほうが分かると思うが、話のつなぎ目で話が分断されていると思う。なので、最初から最後まで繋がりが正しく自分で認識できている場合を除いて、割と迷子な話し方をしているはず。酔っているときはそれが顕著で、3つぐらい違う話をごちゃまぜにしながら話したりする。

脳内で言語化以外の思考手段がないので、それが上手に伝えられないというのはかなり苦痛になってる。例えば僕が頭の中である図形や形状を真剣に考えようとすると、その図形や形状は回転したりぼやけたりして一点に留まらない。そのため、なにか一つの面だけを注意してみる、というようなことができない。 要は僕の頭の中で何かを真剣に考えるための唯一の手段は言語なわけだが、それが実際には正しいフォーマットではないというのはそれなりの絶望がある。

23歳になった。なってしまったという方が感覚的には正しいのだけれど、そういうことをいつまでも言っているわけにはいかないという気持ちにさせられるような年齢でである。あらゆることを跳ね除けて進めることのできる若さはすでに失われつつあり、慎重に次の一手を選びながら生活していく必要があると、強く感じさせられる。そういう年である。 しかし結局のところ、無限のエネルギーのようなものは自分にはなく、ただ体力の消費に気づかないだけで無理矢理どうにかしていたという方が正しい。少しずつ「生活」の枠組みを捉えていくうちに、自分の取り落してきたものが見えてくるようになる。 そうやって無くしたかもしれない物たちに囲まれた中で、いつまでも虚勢を保ち続けることなどできない。生きていくうちに世界は加速的にシビアになっていく。いつまでもこのままで息ができると思っていたのに、このままでは保てないことばかりわかる。変わっていく必要がある。生き延びるために。

悲しい言葉ばかりで始まってしまったが、自分自身が悲嘆に暮れているかと言われれば、実はそうでもない。割合覚悟していたことである。去年のこの時期から、この一年間はそういう一年になるであろうという予感はあった。 去年は大学の間に得たものを非常にいい形で出力できた年だった。自分の中で考えていることの半分以上で「やりきった」といえるほどの感触があった。そうなれば、その次は作り出したものに対する反省の一年になるだろうと、そう思っていた。 この一年間はそういう、貯めの時期だろうと考えていたので、そこまでのショックはなかった。思ったよりも根本的な部分の問いかけが多くなってしまったり、思ったよりも立ち止まる時間が長くなってしまったというのはあるが。

そういうわけで、長いこと座り込んでいたけれど、ようやく立ち上がった。一度立ち上がると最後、周りが勝手に走り出してしまうので、否応無しに自分も走り出さないといけない。そういう状態で、ようやく走ることに慣れてきた、今の自分はそういう状態だ。 限界は見えていても、できることも増えている。今までとは別のやり方で、生き延びる自分を見つめながら、この一年間は走り抜けて行けたら良いと思う。

MacでM570の戻る/進むボタンをChromeとFirefoxで両立して使いたい

MacでM570(トラックボールマウス)の戻る/進むを使う場合はLogicoolのサイトからソフトをダウンロードする必要がある。

support.logi.com

んで、インストールして設定からLogicool Control Centerをクリックして設定してあげれば使える。

f:id:sh4869:20200601224453p:plain

なんだけど、このときにどうやら実質的に《⌘+→》《⌘+←》を押したのと同じことになるらしい。

そのため、Firefoxはページ戻る/進むのショートカットが同じだからいいのだけど、Chromeのショートカットは 《⌘+「》,《⌘+」》なので*1このボタンが効かない。

のでMac側で書き換える必要があるというお話。

f:id:sh4869:20200601224243p:plain
Mac側のキーボードショートカットに追加

他にいい方法があったら教えて下さい。


余談だけど最初「⌘+→」をミッションコントロールのスペース切り替えに使っていたので、進む/戻る押した途端スペースの切り替えが発生してめっちゃ驚いた。

*1:なんだこの最悪のショートカット

プログラミング言語のパッケージシステムとそれを中心にしたコミュニティについての研究がしたい

Scrapboxをprivateにしたのであった文章を一応持ってきた。書いたのが2017年とかなので微妙に今と違う部分があるが適当に読み替えてください。

概要

  • プログラミング言語におけるパッケージマネージャと,そのコミュニティについて
    • 適切に分類し
    • どのようなパッケージマネージャ,コミュニティが発達していくのかといったことを調べ
    • 最終的には実際にその研究の理論を実際に運用し測定する
  • といったことをしたい.

動機

  • 僕の好きな言語にDartというものがある.Googleによって開発された所謂AltJSだが,その他のAltJSとは違い,DartVMというVMをブラウザに搭載最終的にはJavaScriptを置き換えるという目標によって作られた.しかし,VMをブラウザに搭載するという目標を諦めReadableなJSにトランスパイルするdev_compilerを作り,所謂他のAltJSと同じように使っていくことを目標に切り替わっていった.現在でも開発が続けられている.
  • 有り体に言ってしまえばDartは流行らなかった.反対に,Node.jsのパッケージマネージャであるnpmはどんどん発展していったように思う.そこでどのようなパッケージマネージャが発達するのか,ということをぼんやりと考えるうちに「発達するパッケージマネージャにはどのような要素があるのか」「そのコミュニティに何か特徴はあるのか」ということを実際に調査していきたいと考えるようになった.

今まで考えたこと・調査したことなどのメモ

  • パッケージマネージャシステムは図書館のような知識情報システムであるといえるのではないかということ
  • Image
     *  Pはパッケージ
     *  Hubはシステム
    
  • 細かな部分を全てふっ飛ばしてざっくりと書くとパッケージマネージャはこのような図で表せると考える事ができる.
     *  パッケージがHubに集められてきて,それがユーザーによって使われていく.
     *  もちろんどのように使うのかなどの方法はそれぞれ異なってくる.
    
  • このシステムにおけるHubを図書館に,Pを本に置き換えると図書館のシステムを表していると考えることもできる.こちらももちろん細部は違うが.このようにパッケージマネージャは知識情報としてのパッケージをあつかうシステムであるとみなせるのではないかと考えている.
  • 上の図はプログラミング言語のパッケージマネージャにかぎらず,apt,Homebrew,chocolateyといったソフトウェアパッケージマネージャや,UnityのAsset Storeなどに適用できるのではないかと考えている.

  • 図書館などの情報システムとの差異

    • パッケージマネージャと図書館を情報システムとして比較していく.
    • パッケージマネージャ全体と図書館などの比較
      • 扱っているものが情報であるか物理であるか
        • 本は物理的に存在するが,パッケージマネージャが扱うパッケージは多くの場合データである.データはコピーが可能であり,またパッケージマネージャで扱われるデータはコピーされることが妥当であるためこれは大きな差異であると考える事ができる.電子書籍を扱う図書館の場合は除く.
        • この差異によって生まれる違いとしては次のようなものがあげられると考えられる.
          • 貸出か取得か
            • 図書館を運用する上では,誰が本を借りているか,いつまで借りているかなどの情報はシステムを運営する上で重要であると考えられる.一方でデータある場合コピーが可能なため,貸出ではなくそれぞれユーザが取得(多くの場合はダウンロード)し利用することができる.一方で,そのデータが有料で扱われている場合コピー可能なデータをどのように守るかなどの問題が発生する.
              • パッケージを登録するのがパッケージ作者であるかそうでないか
          • 図書館はそれぞれの本を図書館の本として登録するために司書が活動している(はず).一方でパッケージマネージャーでは多くの場合パブリッシュ時にユーザーが登録情報について記載する
            • たとえばpackage.jsonみたいなファイルにメタデータを書いてそれがvalidかどうかを判断する,みたいな仕組みが多い
              • つまりここがユーザーの手に渡ると中央にスタッフが必要なくなる
              • 一方で質が保てるかみたいな問題もある
              • データフィールドの設定
                • パッケージマネージャシステムの多くはパッケージの作成者(公開者)に対しそのパッケージに関する情報を公開時に求めることができる(例:パッケージ名,パッケージの説明,パッケージの作者情報(メールアドレス,名前,その他サービスのアカウント名),依存関係,変更記録など).これはシステムを作成する上でどのようにそのパッケージの情報を扱うかということを設計しやすいという利点がある

研究の流れ

- 基礎知識の補充
  • 現状情報科学に関するある程度の知識はあるため,必要なものを考える
    • 図書館情報学
    • 社会学
      • もともとどういう分野か理解できていない部分があるのでそこを埋めてからじゃないとなんともいえない
      • 社会学ではなさそう
    • 社会心理学らしい
    • パッケージマネージャー関連の調査
    • 評価方法の確立
    • 実装

相互理解の前提、本当の相互理解、消耗

いくらでも話されていることだと思うんだけど自分自身が結構前に実際に体験してから言語化していなかったのでメモ程度に。

相互理解、という言葉を僕が使うとき、それは相手の意見に納得する・賛成するという意味ではなく「存在する『事実』とその『解釈』によって『意見』が出てくる」ということを理解する、ということになる。おそらくインターネットで議論をやりなれている多くの人はこういう考えになっていると勝手に思っていて、言葉こそ違えどこういうゴールライン*1がある、という認識はある程度一緒であろう。

この場合、問題になるのは『意見』が『事実』と一体化してしまうことだ。その意見は一度『解釈』を通していて『解釈』を通している時点でそれは『事実』ではない、ということが(なんらかの形で)崩れてしまっている。僕らが他人の『意見』を理解する場合、相手がその『意見』を作るために当てている『解釈』をずらしてみたり変えてみたりすることでその差分等から理解していく、という方法が一般的だと思うので、相手が意見を事実としてしまうと、解釈をずらす試みができない。さらに言えばなぜその『解釈』を選択したのかということを理解するためには、他の『解釈』を採用しなかった理由を知る必要がある。*2*3ので、相互理解のメソッドが*4使えないので、相互理解ができない、となる。

ここまでの話はまあよくある話であってこんな中学生みたいなことを、と思うと思うんだけど、話の主題はどちらかというとここから。なぜ『意見』を『事実』としてしまうのか、ということについてで。これはまあいろんな理由があって、単に訓練されてないという話に全て落ち着く気もするんだけど。そもそも上の解釈事実に関する話も僕が『事実』として捉えているだけで本当は『意見』なのかもしれないとか。いやまあ実際『意見』なんですが、これを否定すると流石に日頃の議論が成り立たなくなってしまう、こういうふうに、『事実』としなければやっていられない『意見』というのが人それぞれ存在している。多分気が付かぬうちに生存本能的に『事実』としてしまっているものもあるだろう。そうなったときに、そのことを否定できるだろうか、ということを考えてしまって。当然誤った『解釈』によってできた『意見』で大きな被害が出ているといった場合、その『解釈』が誤っているということを『意見』を『事実』と認識するのをやめさせるかはともかくとして何かしらの手は打たないといけないが。*5

本当の相互理解というのは恐らくこういう自分が持っている相互理解のメソッドが使えないものも許容するものなのだろうな、と考えたら、非常に気が滅入ってしまった。別に興味ない話ならいいんだけど、自分が興味を持っていてかつそれなりにその意見を確信的に持っているとき、相互理解をしたいと感じている分野で相互理解のメソッドを扱えない対象と出会い、またその対象の持つ意見*6を許容しづらい場合、存在を受け入れるしか術がない。他者と自分の間で十分な議論が行われていない状態で、自分の意見から見て解釈が歪んでいると思われるものも、存在するということは受け入れないといけない、ということを改めて感じてなんだか疲れてしまったという話。


andymori 「シンガー」

全然関係ないけどandymoriのシンガーの「なんだか疲れてしまったね 参ってしまったね」という始まりめっちゃいい。なんだか疲れて参ってないことそんなにないからな。

*1:スタートラインでもある

*2:当然意見から解釈を読み取ることもできるが、これはあくまで推論的でしかない。解釈をずらして比べてみるのもなにか確証があるわけではないが

*3:ここで重要なのはなぜその解釈を選んだのかであって解釈そのものではない(僕の場合だが

*4:全然関係ないけど相互理解のメソッドってめっちゃ百合漫画のタイトルっぽいな……

*5:『』つけるのめんどいでここでやめます

*6:対象の中では事実の場合が多いが