0xf

日記だよ

neo4j 4.2.3 メモ

マネージドなグラフDBとしては Amazon Neptune があるが、こいつは Cypher をサポートしないのでいったん除外した。おれは Cypher の書き味がなんとなく好きなんです。

動作環境としては適当に debian 系のVMクラウド上に立てた。ドキュメントを参照しつつそのままインストールしていく。特に困ることはない。

VM側では0.0.0.0を待ち受けてファイアウォールで自宅のIPアドレスのみを許可して全開放。人にはよると思うけどローカル docker より状態を持つミドルは外にあった方が好みで、neo4j 4.3 からは M1 も公式サポートするはずですが、ローカルに立てるかなぁというとけっこう微妙に思ってます。でもなー自宅ネットワークの外部IP変わったタイミングで設定し直すとかやってると、また「いやローカルに欲しい」ってなるんだよなぁ。

CLIcypher-shell を利用する。

$ cypher-shell -a <リモートホスト> -u neo4j -p

ブラウザコンソールでもほぼ同じことができるのでブラウザで参照できる状態を作れるならそっちが便利かもしれない。

インストール直後は neo4j ユーザしかいない。パスワードは初期設定で neo4j になってて変更が求められる。パスワードジェネレートボタンがあるのが親切。neo4jユーザは管理ユーザとして扱っておけばよくて、接続したら新しくユーザを作成していくとよいと思う。

メモ (neo4j)

  • 脳内モデルとしては、
    • スキーマレスにプロパティを持てるデータストアで、要素間にリレーションを作れる
    • スキーマレスではあるけどプロパティに対してユニーク制約や検索のためのインデックスを貼れる。マルチカラムインデックスはエンタープライズ版のみ。
    • クエリはリレーションを利用した異様に強力なパターンマッチが使えて便利
  • コミュニティ版は複数DB作れない。エンタープライズ版だと増やせます。
  • コミュニティ版はHA構成作れない。まあ個人で手元ツール作る分には困らないでしょう。
  • 全文検索系には Lucene が組み込まれているので十分高速。日本語周り設定するならトークナイザーの設定とかはしたほうが良いけど最初から考えなくてもいいでしょう。
  • リレーションシップはタイプ(単一)、ノードはラベル(複数可)を持つ。
  • Cypher は neo4jで採用されているクエリ言語。RDBMSSQLみたいなもんです。
  • 式をいろいろ書いていって最後に return で値を返すクエリ式は独特の書き味がある。
    • 手続きをパイプするスタイル。Cloud Watch Logs Insight のクエリ構文に慣れてたりすると違和感薄いかもしれない。
    • 最近手続きについてはこういうスタイルでいいんじゃないかと思うようになってきた。
    • RDBMS側で手続きを実行できるみたいな書き味なので大規模システムの本番系の中央DBにこれを使うことを想像するとドキドキする。これは「DBに仕事をさせたら負け」的な感覚が人生のどこかでインストールされているからだなとわかる。
  • 便利な Web コンソールがビルトインされているので布教用にはまずそっちを見せる。

メモ (Google Cloud)

  • Cloud Run から Compute Engine に接続するには サーバーレス VPC アクセスの構成  |  Google Cloud を利用する。インスタンス数2がミニマムなので最低月 $13 くらい。
    • VPCコネクタでは /28 でサブネットを設定する必要がある。default VPCを使ってる場合、 10.128.0.0/9 とかが使われているので、10.127.255.240/28 を突っ込んでおいた。
    • デフォルトのファイアウォールルールでは新しく追加したサブネットの範囲は接続元として許可されていないので必要に応じて新しく許可ルールを増やす。
  • Cloud Shell Editor から Cloud Run のデプロイをする場合、VPCコネクタの設定ができないぽいので Cloud Run コンソールからやった。一度設定しておけば再度デプロイする時は設定が引き継がれてそう。
    • Cloud Run 側の yaml 定義では spec / template / metadata / annotations / run.googleapis.com/vpc-access-connector に定義されていた。

プログラミングを学べばプログラミングができるようになると思うけど平凡に求められているのはプログラミングができる人ではなくコンピュータを使って有益なものを自ら生み出す人か、その仕事の役に立つ人ですよね。非凡なプログラマになるために学ぶ道は相応に長いと思われる。人はプログラミングを学んで何をしたいのか。「ゲームを作りたい」などは自分自身の衝動と紐付いてそうだけど、どちらかというと英語学習と同じような位置付けなのかもしれないなぁ。仕事の道具としてプログラミングを学ぼうと意欲を持つ人に対して、自然な成り行きとして没頭してきた人のやり方をオールオアナッシングで提案するのは大間違いぽい。

Twitterでたまに面白いやりとりを見かける。「GWに読みたいビジネス書100選!」「すごい!これをGWで全部読んだらめっちゃ成長できそう!参考になります!ありがとうございます!」これは強い皮肉な返しだなと感心してしまった。やり取りの面白さに演出的になることの功罪はあるよなぁ。オープンな場所での私的とされる会話形式のやつ。

 

「邪神ちゃんはオリンピックを開催したい」という電波を受信しました。

将太の寿司で、「こんなにいっぱい寿司を作ってるんだから一つや二つだめなものがあったっていいだろ」という若手に親方が「バカヤロウお前にとってはごく一部に過ぎないかもしれないけど、食べる人にとっては唯一の寿司なんだぞ」とどやすシーンがあって、この論理、どこかで・・・と考えていたけど「1行のログの向こうには1人のユーザー」に感触が近い話なのだった。

自分は記憶と思い出しがかなり弱いんだけど、引越しや転職するの、「同じ場所の似たような記憶が積み重なると時系列的に混乱する(ある場所の記憶が増えると最近の記憶かどうかわからなくなる・古い記憶と混じる)ので定期的にリセットをしたくなる」ってことな気がしてきた。

功績と能力

功績が実際に上がった成果、結果を表すのに対して能力は功績につながる力を保有していることを表す。

我慢や努力は評価対象ではないみたいなことがあるけど、これは功績評価の文脈であると思う。それに対して、実績は偶然かもしれないというのは能力評価の目線から来る疑いなんだろう。何を軸にしているかで見方が変わってきそう。ということをつらつらと考えていた。まぜるな危険のやつっぽい。ちゃんと区別して位置付けを整理する必要がある。

爵位と冠位の話にもつながっている。

ただの不幸

病気とかを、何かの証であると掲げたい人はなんなんだろ。「鬱は甘え」と「真面目すぎるので病む」は全く同じ構造だと思う。「先祖の悪行の祟り」と違いがない。

そこにあるのはただの不幸であるだろう。個々に原因はあるだろうけど。原因の内容にかかわらず、それは不幸なことなんだよ。自業自得となることを恐れる、恐れざるを得ない環境における、当然の予防規制なのかもしれない。辛い話。