Retired Colourman

何度も朝がやってくる

川 on Google Photos

これは川見てるアドベントカレンダー11日目の記事。

adventar.org

これまで見てきた川をGoogle Photoから取ってくるかと漁っていて気づいたのだが、Google Photoには「川」という分類項目がない。ではどうなっているかと、「湖」と「橋」になっている。

f:id:sh4869:20201210171041p:plain
湖(宇治川

f:id:sh4869:20201210171253p:plain
橋(宇治川

デカければ湖だと思っているのかもしれない。しかし湖は川ではないので流れないということをもっと真剣に考えてほしい。水があればいいというものではない。いや水があればいいという部分もあるが。

気を取り直して画像を貼っていく。

まず宇治川

f:id:sh4869:20201210225148j:plainf:id:sh4869:20201210225201j:plainf:id:sh4869:20201210225216j:plain

これは一年前夜行バスで京都に行ったときの写真。朝5時半とかに京都駅についてそのまますごい勢いで宇治への始発に乗り朝六時ぐらいに見た、はず。非常に美しくて声が出なかった。本当に美しかったのだが、上手に写真に撮れなかった部分もある。

f:id:sh4869:20201104102521j:plainf:id:sh4869:20201104102806j:plainf:id:sh4869:20201104103259j:plainf:id:sh4869:20201104103839j:plainf:id:sh4869:20201104103950j:plain

残りは今年行った時の写真。秋の京都は非常に過ごしやすくて、川の音聞いて30分ぐらいぼんやりしていた記憶がある。宇治川は川幅が広く、シンプルに美しい。鴨川の面白さが都市的な構造に現れるように感じられるのに対して、宇治川は見ているだけで面白い。

f:id:sh4869:20180918112554j:plainf:id:sh4869:20180918112557j:plainf:id:sh4869:20180918112602j:plain

これも宇治川という扱いのはず。流石に宇治駅周辺を外れると大きな川という印象に収まってしまう部分がある。それでもやはり良いが。

次は鴨川。

f:id:sh4869:20201103093938j:plainf:id:sh4869:20201103182158j:plainf:id:sh4869:20201104114016j:plain

やはり何度見ても川幅が素晴らしい。どこまでも街の中の川である。他人と暮らすための程よい断絶をもたらしているように感じる。都市という多くの他人がいて、その他人達との境界のようなものを川は見せてくれていると感じている。東京にも川はあるが、どうしても低いところに流れていることが多く、そこに断絶という感覚はない。

京都には横浜や福岡のような海への開放感はないので、断絶かつ囲まれているという独特の雰囲気があるように感じる。これを上手に説明することができなくて、その言葉を探すためにいつも京都に行くと街を歩き続けてしまう。

f:id:sh4869:20201103110904j:plain

これは桂川桂川桂川の良さがあるとは思うのだが、一方で少々川幅が広すぎる。川岸が生活にそのまま結びつくような力はない。やはり鴨川の川幅は素晴らしいと思う。

f:id:sh4869:20201104114113j:plain

京都には世界のすべてがあったと語っていた人がいるけれど、それを理解できるように個人的に思えるいう写真が撮れた。

これはあまりにも良くて撮ってしまった写真。

f:id:sh4869:20190801153839j:plain

豊洲

f:id:sh4869:20181024145209j:plainf:id:sh4869:20181024150901j:plain

豊洲はシンプルに計画都市としての面が強く、道路の広さや上品すぎる道はどこか人工的な匂いがあるが、運河がそれをある程度和らげている部分はあると思う。

最後に地元。

f:id:sh4869:20201210232228p:plain

桜が垂れているのが結構好きで、春になるといくつか電車のルートを変えてよく歩いてこの川に沿って帰る。それほど特別な川ではなくても、やはり川を見て歩くのは精神にいい。


ちなみにネタバレ(?)だが、「川」と検索すれば川は見れる。

f:id:sh4869:20201210172124p:plain

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

自分の言語特性は割と歪というか問題があって、簡単に言えば脳内で正しい文章が出力されていない。 脳で考えてるときは問題なく言葉になっている(と思っている)が、実際にそれを書き表そうとすると出力にムラがあったりそもそも繋ぎが存在しなかったりする。短い言葉(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かどうかを判断する,みたいな仕組みが多い
              • つまりここがユーザーの手に渡ると中央にスタッフが必要なくなる
              • 一方で質が保てるかみたいな問題もある
              • データフィールドの設定
                • パッケージマネージャシステムの多くはパッケージの作成者(公開者)に対しそのパッケージに関する情報を公開時に求めることができる(例:パッケージ名,パッケージの説明,パッケージの作者情報(メールアドレス,名前,その他サービスのアカウント名),依存関係,変更記録など).これはシステムを作成する上でどのようにそのパッケージの情報を扱うかということを設計しやすいという利点がある

研究の流れ

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