.｡oO(此のblogは、主に音樂と考察と Programming に分類されますよ。ヾ(〃l _ l)ﾉﾞ♬♪♡)
音樂は SoundCloud に公開中です。
考察は現在は主に Scrapbox で公表中です。
Programming は GitHub で開發中です。
だいたいに於いてそんな方法は存在しない。
test するうまい方法が既に有れば人類は parallelism で苦勞しない。競合しないやうにする爲に施した對策が動いてゐる事は test できるが、その對策に依って競合が防がれる事はよく test できない。
たまたまうまくゆく特殊な場合以外は test は諦めるのがよい。
test 以外の手法がよく取られる。
Erlang や Redux-Saga のやうに競合が起きにくい構造を作ってその上で計算するか、Rust や Pony のやうに競合する pattern の一部が起きないやうな形式化を行ひその上で計算する手法が有名だと思ふ。他には paralell な計算の model を作ってその性質を証明する code を書き、その code から實用する code を生成する手法もよく知られる。
計算を實行する基盤であるネットワークやディスクは VM に障礙を注入し、そこに random な負荷を掛けて test する手法も有る。
去る九月七日にElixirConfJP 2019 小倉城が開かれ、公募 (審査無し) で五分間喋った。
過去 K8s 上で Elixir の Phoenix.Channel を運用してゐて、今は個人で、K8s 上で Elixir の bot とかを運用してゐる。運用するのに監視は必要なものであり、樂に充分な監視をするのに KomachiHeartbeat + mackerel-container-agent が好いのではないかと云ふ考へを喋った。
Monitoring Containerized Elixir
deadtrickster/beam-dashboards を Prometheus + Grafana で使ってゐた事も在ったが、Prometheus の運用自體が自明ではない。Prometheus はまた運用してみやうと思ふが、Mackerel だけで取り敢へず充分な狀態を作ってしまへる。
ne-sachirou/ex_komachi_heartbeat は私が作ってゐる Elixir の library で、名前は同名の Rubygems からとった。Rubygems のを作ったのは知り合ひで、同じ組織が同じ目的に使ふ爲に作ったのでそう成った。HTTP 接續を受け入れるか否かの死活監視が出來るのと、plugin を書けば繋がってゐる DB 等との接續監視や統計情報が見られる。K8s の readiness probe と組み合はせて、DB と接續したり Application の起動處理が終はる迄 /ops/heartbeat で OK を返さず load balancer に加へるのを待たせる事をしてゐた。今回喋った KomachiHeartbeat.BeamVital は恥ずかしながら開發中で pull request の狀態に在る。情報蒐集法が面倒なので、書き直すつもりだ。
Let's create stateful systems, by Elixir. Elixir で stateful なアプリケーションを作るのは簡單です。
Elixir の得意な事としてよく眞っ先に擧げられるのは竝列性 parallelism です。確かに、簡單で安全に或る程度效率好く parallel にできるのは Elixir の得意とするところです。しかし parallel である事が得意な言語/環境は他にも在ります。Go は人気で簡單に parallel に成り、そこまで安全ではありませんがそこまで危險でもなく、高速です。Clojure (core.async) は parallel な變換處理を簡單に構築し組織できます。Akka (Scala) は Erlang と殆ど同じ思想で作られ、殆ど同じ事を實現できます。また SIMD や GPU 等の parallelism を扱ふのは、Erlang VM は未だ苦手です (これも得意にしようと云ふ試みは在り、樂しみです)。
少なくとも今のところ、Elixir が他の言語/環境と比べて得意なのは、stateful なアプリケーションを作り運用する事です。stateful なアプリケーションを長期間運用するのには面倒な前提を色々と滿たさなければなりませんんが、Elixir と Erlang VM にはその仕組みが備はってゐるので簡單ですね、と云ふ話を以下でしました。GenStage や Phoenix.Channel は典型的な stateful アプリケーションです。
Let's create stateful systems, by Elixir
數年前に Elixir に關する記事を書く事が流行って以來、Elixir に入門する情報は充實してゐます。これは同じやうな內容でも場に細かく合はせて繼續して書かれる事の要る領野なので、今後も増えてゆく事が期待されますが、Elixir に入門し使へる段階から、Elixir で優れた機能を作る爲の、と云ふ中間的な段階の資料は全く不足してゐます。その資料の一つであるべく、Elixir の表面的な動作を説明するものが以下です。
實際の know how を開示したものが以下です。
一つ目は Elixir でのリアルタイム對戰システムの開發開始から運用迄で、困った事とその解決に就いて亂雜且つ網羅的に載せたものです。
ステートフルで大規模アクセスのある soft-realtime なゲームサーバーを easy につくる
二つ目以降は、上のそれぞれの topic を展開したものです。下は、Phoenix.Channel で二種類のアプリケーションを作った時に、どちらも scale in/out せず、それぞれ scale in/out させる手法が異なった事を説明したものです。
これには、process 間通信は μ sec の速度でしか動かないので、process を使はずに state を管理したりアプリケーションの構造を組み立てる中で、他の函數型言語と共通はするものの、Elixir 特有の困難を解く幾つかの方法を載せました。
Elixir を Docker container で開發し Kubernetes で運用する時の tips をあらんかぎり載せました。載せてゐないのは多分 CI/CD に就いてくらいだと思ひます。どこかで書けるとよいですね。
個人的には Elixir の商用運用からは離れてしまったので、個人的な研鑽のできるところを見附けつつ、何かします。
英語を書くのであれば Latin 文字とアラビア數字を使って左から右へ書く。日本語は長年の書き方の變化を結構保存してゐて、書字方向は上から下への縱書きと左から右への横書き、半世紀ほど前であれば又今でもトラックの側面等に右から左への横書きを使ふ。字の種類には先ず漢字が在り、漢字には略字を含め舊字體と新字体が在るし、慣れてゐない人間から見ると楷書體と草書體とが同じ字だと云ふ事は判りづらい。かな文字にひらがなとカタカナが在り、更に Latin 文字とアラビア數字も多用する。私は普段文を手書きしてゐ、先の內で日々使ってゐるのは、漢字 (新字体)、ひらがな、カタカナ、Latin 文字 + アラビア數字である。これに加えて私は「ヨコガナ」と「縦 Latin」と云ふ文字を使ってゐる。このヨコガナを紹介したい。
ヨコガナはかな文字であり、ひらがなやカタカナと同種のものだ。「ヨコガナ」と云ふ語をヨコガナで書くとかう成る。
ヨと書きコと書きカに濁點が附きナと書いてある。ヨコガナの字はひらがなやカタカナの字と一對一に對應する。
ヨコガナは私の知人が作った字で、私が使ってゐるものはそれとは幾つか字の形を變へてある。ひらがなの替はりに作られた文字だ。ひらがなは昔日本語を縦に連綿して書く樣に使はれ始め、縦に速く美しく書く事が出來る。ここ半世紀ほどで日本語が左から右へ橫に書かれるやうに成り、ひらがなも橫に書かれるやうになった。手書きでも橫である。この時迄にひらがなは活字體を基に作り直され、連綿せず一字づつ離して書く事が多く成った。かう成ったひらがなを速く且つ美しく書く方法は自明ではなく、各人が各人の工夫を凝らしてきた (丸文字はその工夫の一つであらう)。私の知人はそこにもう一つ、各人の工夫を編み出したのである。
ヨコガナはかなを連綿して書けるやう、Latin やキリルの筆記體を參考にしてかな文字を置き換へてある。對應表が有るから載せよう。
友人に依るもの。
私のもの。
一字づつ紹介するのも興味深いが、これはもう書けば覺えるのであるから、書例を載せる事で代へる。書例は Pinterest に集めてある。
ヨコガナは好く出來てあり、書く者毎に字の形をそれなりに自由に出來るやうに成ってゐる。アの高さを私はタの高さ迄上げて書くが、友人はイと同じ高さで書く。ケの第一畫を友人はアラビア數字の 2 のやうに丸めるが、私は鋭角に角ばらせる。ニに在る s のやうな形は上から下ろしても好いし、下から跳ね上げても好い。ルの第ニ畫も同じく言へる。等。これらで字の印象は可成り變はる。辨別が出來る限りは書き易い形を見附けて書くのが好いと思ふ。
雜と云ふ在り方の概念を重視出來るのではないかと云ふ考へを育ててゐる。はっきりと際立った概念ではないが、雜をどう定めるのが好いかと云ふ假説は持って有り、細分を續けても常に更に細分出來る狀態である在り方を雜と名附けやうとしてゐる。私は今 programmer として在り、いわく定め難い team と云ふ集まりで過ごしてゐる。此う云った生活に適合してゆく事と、私が古く育んだ考へとを繋げる事が出來ず、其の成り行きでどうしたら眞である事が出來るかを長く考へ、長く考へ過ぎてゐるが、其所で眞と主體は近い形をしてゐると考へるやうに成った (發言の超越論的な根拠)。其の反対側である、日々に適合すると云ふ側から雜と云ふ概念を考へればどこかで衝突するのではないかと思ってゐる。
假説としては二つが有る。
雜を上の樣に定める事は、言葉や認識や行為に依っては汲み尽くせない實在を考へる事に相當する。しかし體驗に依れば雜には過去に於ける蓄財が要り未來で蓄財を汲み出すと云ふ前提が要る。此れは雜が感覺に依って汲み尽くされないものではあるがしかし感覺されるものである、或いは感覺されるものでもあるからだと思ふ。蓄財が尽きれば雜は在り方から去って了ふ。
名實の組みを建てるならば、名を先に取り名 (普遍) が在れば對應する實が實在する、不當な名は名同士の關係で定まると云ふ考へ (礼) と、實を先に取り實 (個物) に適切な名を附ける、不當な名は實が無い事で定まると云ふ考へ (生得) が在る。雜はどちらでもない。雜は不當な名の不當さが一意である事を更に細分する。名が名である事と實が實である事は名實に於いては一意であり、雜は其の一意である事を更に細分する。此の細分は手續きであり終はらない手續きであるから過ぎゆくものとしての時間である。そこで雜は蓄財と汲み尽くしと云ふ形で瞬間であり、細分と云ふ形で時間である。
此の記事や考へそのものが、より基になる根拠が無いと云ふ事で雜であるが、日常の考へ方を素直に氣遣ひ延ばしてゆくと云ふ事ではストア派風ではある。此の素直と云ふ概念は、似てゐるものを似てゐるとし似てゐないものを似てゐないとすると云ふ風に定まると考へてゐた事が有った。今は好く解らない。
