Word2VecWord2Vecは結構応用できるみたいな話。DockerDockerについてぼんやりとした知識しか持っていなかったのでkuyさんに教えてもらった。KubernetesKubernetesで実際にサーバーの再起動とかが行われる様子を見せてもらったりした。標準ライブラリ標準ライブラリが洗練されていない言語は辛い、みたいな話。Yayaka.netYayaka.netのソースコードはElixirの学習に使えるか?みたいな話になり、一部に役立つコードもあるかもしれないが、ほとんどのコードは雑に書かれていることを説明した。Yayakaプロトコル話した合計時間的にはこの話題が一番長い。Yayakaプロトコルはマイクロサービス的で、さらにマイクロフロントエンド的な面も持つみたいな話。マイクロフロントエンドについては初めて聞いたのでkuyさんに教えてもらった。時代は脱モノリシック。ものすごく雑な概要としては、私がフリフラの布教活動をした。Phoenixはじめにタイトルは釣り。s/対抗/便乗あと、「作った」という表現は厳密には正しくなくて、以前作ったYayaka19サイトを”分散化した”というほうが近い。記事の目的いろいろと忘れてしまう前に記録しておくアナウンスメント連邦全体のユーザー数を5人くらい増やすサーバーが1つくらい増えたらすごい目的に記録が含まれているというのもあって結構余計なこととか書く。経緯Yayaka19もともと(Share)という名前で作り始めた。機能を足したり引いたりしているうちに今のような形に。Yayaka19という名前に変えることになったのは、利用者から「Shareという名前はググラビリティが悪いのでKOKOMINECOCONAみたいな感じのエントロピー高い名前にしてほしい」と言われたため。Socialのアカウントを持っていたため、OStatusについても知っていた。周りは「自分ならOStatusは実装したくない」という反応で、自分も実装したくなかった。時間をかける気は起きなかった。そんなところに、あの日本でのマストドン流行が起こった。少なくとも私の観測範囲では流行っていることを確認できた。Socialと違っていろんな界隈でたくさんのアカウントが作られていたし、Twitterでの投稿数が減少した人も見た。独自プロトコル(Yayakaプロトコル)を用いてYayaka19を分散SNS化することを思い立った。設計と実装とりあえず方針としてはサーバー同士をWebSocketで接続して、なにかあるたびにメッセージを送受信する。あるユーザーが外部サーバーのユーザーをフォローしていたら、タイムラインをロードする度に外部サーバーから投稿を取得する。他には、新しい投稿があったときに投稿者のフォロワーに外部サーバーのユーザーがいれば、新しい投稿を外部サーバーに送る。一応Yayakaプロトコルにする予定があるので、ある程度留意して設計した。実装するには、まず、WebSocketのサーバー側とクライアント側を作る必要がある。クライアント側だけ自作した。それはライブラリとして別に公開している(phoenixchannelclient)。SocketRegistryにはElixirのRegistryという比較的新しいモジュールを利用した。全体的に実装していて楽しかった。面白がってもらえている気がする。私以外が運営するサーバー(19.fubaiundo.org)が立ったので良かった。VMのプロセスの関係図を出した。真ん中の花火みたいなやつが多分HTTPのコネクションプール、左下のはRDBのコネクションプール、右側はフレームワークのやつ、という感じなので左上が実装した部分。タイムライン読み込みの状態errorとかtimeoutとかloadingとかになる。この表からRetryもできる。写真が暗いのはブラウザの拡張機能でページが黒くなってるから。Pluginsが流石にゴミ置き場すぎる最後に特になし。01:48マストドンに対抗して分散SNSを作ったTweet広告を非表示にするコメントを書くもっと読む2017-02-19ReduxでのRoutingはこれでやっていこうと思います。Reduxでの理想のRoutingライブラリを求めて作ったredux-pagesの紹介記事です。ryo33/Yayaka19以前の方法での不満redux-pagesを作るに当たって、まず、前にSPAサイトを作っていて不満に感じたことをまとめました。その中で、特に解決したかったものが以下の4つです。表示されているページによってMiddlewareでの処理内容を変えたいときにも必要だということです。anywhereは、このことを言っています。(2)は、Pathと画面表示は常に一致しているわけではないということです。閲覧権限の無いページのPathにアクセスして、エラーページのPathにリダイレクトされるまでの間は何を描画するべきでしょうか。Webサイトの中にはページ移動後にコンテンツのダウンロードが終わるまでは前のページが表示されたままのものがあります。このように、Pathと画面表示は常に一致するわけではありません。現在のページが常に分かるようになっている必要があります。(3)は、Pathを手書きすると、間違っていても発見しづらく、またPath形式の変更が容易でなくなってしまうためです。(4)は個人的な好みです。redux-pagesの基本的なアイデア以上で述べた不満を元にした基本的な考えは以下の3つです。Stateには現在どのページを表示すべきなのかが保持されるページオブジェクトを定義して、ページ遷移Actionや、そのページへのPathはメソッドで生成するページ遷移は単一のActionをdispatchすることで行う不満1を解消するのは(1)(2)、不満2を解消するのは(1)、不満3を解消するのは(2)、不満4を解消するのは(3)です。(3)で単一のActionになっているのはMiddlewareでのページ遷移処理を単純なコードで書くためです。ページ遷移を遅らせるときも単にnextDispatchを呼ぶのを遅らせるだけです。基本的な動作イメージredux-pagesを使ってページ遷移を行うときの基本的な動きを説明します。Actionをdispatchしてページ遷移redux-pagesのMiddlewareにActionが到達したときにPathが変更されるMiddlewareで様々な処理が行われるStateが変更されViewもそれに応じて変更されるこれが、基本的なページ遷移時の処理の流れです。ユーザー認証やリダイレクトなどは(2)のMiddlewareの中で行います。locationの変化によるページ遷移こちらは、ブラウザの戻るボタンなどが押されたときに使われます。Pathのパース結果でActionが投げられるMiddlewareで様々な処理が行われるStateが変更されViewもそれに応じて変更される実用redux-pagesはYayaka19というSPAアプリケーションで実際に使用しました。今のところは大きな問題など無く運用できてます。前述の不満の解消以外の利点としては複数のページに適用したい処理をまとめて書けることが挙げられます。allowedPageNames.includes(action.payload.name)というような条件文に応じてリダイレクトを行うだけです。あと、使ってから気づいたのですが、nextDispatchを遅らせることによりページ遷移を遅らせる技は滅多に使わないと思います。ロードが終了するまで前ページを表示するよりは、ページ遷移時のHookでisLoading状態にして、あのグルグルを表示したほうがSPAぽくなります。ちなみにページ遷移時のMiddlewareの処理にはredux-middlewaresを用いています。ログイン確認とそれによるリダイレクトにはcreateReplacerを、ページ遷移時のHookにはcreateAsyncHookを使います。個人的に直感的にMiddlewareを書くことができるので気に入っています。redux-logicなどを導入している場合はそちらを使ったほうがいいです。エラー処理も含めるとMiddlewareでActionを変換する必要があります。これをどうにかページ定義時に書くことができるようにしたいと考えています。あとは、導入時の雛形が比較的多いのもどうにかして減らしたいです。さいごに割とまともに使えて、辛いポイントもそんなにないので、とりあえずしばらくはこれを使っていこうと思います。20:04ReduxでのRoutingはこれでやっていこうと思います。入れた10万のラップトップに乗りかえたけど快適すぎる。一時停止リマインダーをやるためにグッズを作った。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。