右手にペンタブ持っている人向けの左手用 #自作キーボード を作っています #builderscon
こんばんわ。今日から30歳です。祝ってくれ。
pulsarっていう左手キーボード作っているって話
これです
スペック
- 9キー + 親指ダイヤル + 親指が届くところに左右のレバースイッチ
- 小型OLED
- キー配列（これ押したらこれが入力されるとか）を自由に設定可能 - ダイヤルやレバースイッチも設定可能
- microUSB接続 - ゆくゆくはType-C化や無線化もしたいが
- キーごとにフルカラーLEDを搭載
- 配色も設定可能
- 上記動画はダイヤルで色変え、レバースイッチで点灯パターン切り替えを割り当てたデモ
- キースイッチはメカニカルキースイッチ - ソケット接続なので自由に違うキースイッチに差し替えることができる - LEDの形状の関係でkailh BOXやkailh Speedしか使えるのを確認できてない。Gateronは浮くのでダメだった
- 商品として売るならユーザが半田付けする箇所をなくした状態で売ろうとしている
進捗
- 自宅での小ロット量産は出来た
- 身近な人にユーザーテストしてもらうところ
- 基板の量産は見積もりお願いする段階
- アクリル製ケースは試作中
- プログラマ以外の人が使う自作キーボードなので、配列のリプログラミングをGUIで出来ないか模索中
販売の予定
- 面白半分で50枚ぐらいの量産をするので、そのままboothとかで売ります。早ければいいですね - いきなり売れるとは思ってはいない。同人ハードだし
というわけで上の作る過程の話とか作るのに必要な知識の話をするから来てくれ！！！
buildersconっていうカンファレンスでそういう話をします。
聞きたい人は来てくれ！！ ところでこの記事を書いている時間の2時間後にチケット販売締切です。
[https://twitter.com/builderscon/status/1153190436359397376:embed##builderscon tokyo 2019 チケット販売終了まであと数時間です！ 当日券はありません！迷う時間もありません！是非おはやめに！
YAPC::Tokyo 2019で静的解析の話をしてきました #yapcjapan
こんにちはこんばんわ、トーカナイザの守護霊ことmacopyです。
YAPC::Tokyo 2019に参加してきたので、そのご報告です。
喋ったトークについて
「Perl5の静的解析入門 機械と人間双方の歩み寄りによる平和編 」と題して発表しました。喋ったこととしては
- 一般的に静的解析とは
- Perl5における静的解析ソリューション
- PPRというモジュールの使い方の例
- 静的解析がしやすいコードを書こう
という感じです。スライド的にはこの後に
- PPR.pmの巨大正規表現を読み解くために、PPRと正規表現をAST化するPPIx::Regexpを使って可視化する
- Function::ParametersとFunction::Returnを使って引数の型を書いたメソッドを静的解析して型情報を取り出す
ということが書かれています。事前の練習通りのところで終わったので、想定どおりですが、やはり不完全燃焼ですね。静的解析自体がマニアックな課題なのでなぜそれが必要なのか、それをやりたいのかの説明が必要です。でないと聴衆側は置いてけぼりになってしまう。これは僕のどのトークでもそうなんですが、扱うことがマニアックで前提の話が長くなる。
YAPC::OkinawaのWebSocketの話も同じことになったので前半部分をあらかじめスライドとして公開したのですが、それでも当日の反応を見ると観衆を置いていってしまったような印象を受けたので、今回はスライドは2時間前に全部公開しつつ前半しかやらないということにしました。が、それが誠実なのかどうか、、というのは、、、すみませんです。。。
どこかでフルで話すか、もっと深掘りするかなどしたいですね。ここで話してよという方がいれば日本各地どこでも向かいます。
聞いたトークについて
- 2019年冬のPerl
- 5.30の開発についての話があったが、盛り込まれるコミットが少なくなり、CPANでも開発者がいなくなっているという話が寂しく思えた。一方Perl6は6.dの仕様が出て盛り上がっているように見えて対照的な印象を受けたが、あとからどっちもどっちではという感じのことを言われてまあなるほどだなと思った
- 言語コミュニティというのは多かれ少なかれ人が作るものであり、他人が作らなくなったからと言って、自分が作れなくなるというのは違うと思う。Perlの開発者はマイノリティになりつつあるも、使っている人はたくさんいてナレッジはいて活躍する場もまだ残っているので、ここに参入すればブルーオーシャンである。みなさんどうですか
Perl衰退、危機と捉えるかチャンスと捉えるか。確実にブルーオーシャンになっている #yapcjapan
— トーカナイザの守護霊 (@mackee_w) 2019年1月26日
- Perl to Go
Goのパッケージ名地味にかぶらなくてかつ短くtypoしにくい名前をつけるセンスが要求される #yapcjapan #yapcjapanHall
— トーカナイザの守護霊 (@mackee_w) 2019年1月26日
レガシーPerlビルド 〜現代に蘇るPerl[1..5].0とPerl6〜
- アナグラくんの発表だけれど、完全に面白い
- 考古学と銘打っているけれど、こういうの僕は大好きです。地元の郷土研究しているおじいさんが本を書いて図書館に寄贈みたいなパターンあるけれど、あれをPerlでやっているみたいな
- プログラムをビルドすること一つとっても、研究対象になりうることがわかるし、現代ではPerl5を用いて実現していることがPerl5より前には存在しないので、どうしていたのか、鶏卵問題！！！ってなるので面白いですね
WebVRで作品を作って展示しよう
ISUCON8予選問題作成の裏側
- 僕も決勝問題作成の裏側にいたので苦労が忍ばれます
- 過去のISUCONのアンサーというのがコンテキストがあっていいなと思った。若干ウェットだし、嫌われる人には嫌われるかもしれないけれど、隠し味として歴史を使うのは良いと思うんですよ
- 解ける問題にする と 解き方はいろいろあるようにする というのが結構相反する性質を持っていて、当日は解ける問題だよね、大丈夫だよね！？ってなるし、実際決勝はそんなことが話されていたりしました。しかし決勝で優勝した解かれ方は想定と違うアプローチだし、エンジニアリングって楽しいなってなる
LT
tokuhiromさんのキーノート
- Okinawaのyappoさんに引き続き、どのようにコミュニティとやってきたかという話だった
- 意識的にやっていったわけではないかもしれないが、コミュニティはやはり人が作るものであって天から降ってくるものではないなと思った。コミュニティ作りやっていくぞと決意した
そんな感じで、様々なトークに様々な示唆を得て大変価値のある時間でした。
次は未定とのことですが、次も是非参加したいですね。よろしくおねがいします
トランスヒューマンガンマ線バースト童話集 を読んだ
- 作者: 三方行成,シライシユウコ
- 出版社/メーカー: 早川書房
- 発売日: 2018/11/21
- メディア: 単行本（ソフトカバー）
- この商品を含むブログ (1件) を見る
これです。ネタバレ？あったらごめんなさい。これは書評ではなく読んで思ったこと考えたことです。
概要
「トランスヒューマンガンマ線バースト童話集」は第6回ハヤカワSFコンテスト優秀賞受賞作の作品が単行本化したものとのこと。そもそも僕がこの本を知ったのはこの書評を見てから
僕はこの本と同じような「童話の下書きにしたSFショートショート」を同人誌でやっていて、一緒にサークルやっている人との会話で「おいガチ勢がいるぞ」という流れで見つけて買ったのがきっかけ。
SFリテラシの話
この本はタイトルにもあるように、
- トランスヒューマン
- ガンマ線バースト
がガジェット、あるいは話の骨子となる道具として使われている小説である。
この2つのワードがある小説といえば、イーガン先生のディアスポラなんですけれど、
- 作者: グレッグ・イーガン,山岸真
- 出版社/メーカー: 早川書房
- 発売日: 2005/09/22
- メディア: 文庫
- 購入: 11人 クリック: 360回
- この商品を含むブログ (327件) を見る
ディアスポラはなんか最終的に地球なんて言う一箇所に固まっているとガンマ線バーストとかいうイベントに耐えられないから散り散りになろうぜとか、その過程でファーストコンタクトものになっていくんですけれど、トランスヒューマンガンマ線バースト童話集にもガンマ線バースト後に地球の外に出る力学が働く描写らしきものはある気はする。
けれどもディアスポラのやりたいことは地球外生命体を探すきっかけとしてガンマ線バーストを使うことだったり、トランスヒューマンの「発生」ついての描写とかをやりたかったのかなと思う。
それに比べてトランスヒューマンガンマ線バースト童話集は、銀河ヒッチハイクガイドのような雰囲気だった。モンティ・ホール問題のくだりとかね。MPSのくだりとか絶対作者ニヤニヤして書くなこれってなる。僕もなると思う。
つまりこの2つは道具は同じであれど、描く枠が全然違っていて、ディアスポラは道具の前後をやりたいわけだし、トランスヒューマンガンマ線バースト童話集は道具を使って笑かしにきているわけだ。
ただ、この笑いを楽しむにはどれだけのコンテキスト、リテラシが必要なのだろうかと思った。
まず、童話の知識が必要である。シンデレラを知ってないとシンデレラが脱出するところで警備ロボに具体の足首を撃たれて、足ごと王子様のところに残してくところで笑うことは出来ないだろう。僕はここでこの話、大好きってなるんですけれど。
そしてトランスヒューマンに関する知識であったり、現代SFを覆う機械知性だとかそういうのがあんまり説明なしに出てくるので、知らないと少しのけぞるかもしれない。というかイーガン先生の話が読めたらこの本はすごく楽しめると思います。めんどくさいオタクの言説になってきた。
とはいえ、もしかしたら知識がなくても面白いかもしれない。「みらいみらい」から始まるシンデレラの話はすごく期待を膨らませ、謎の魔女のツンデレなところとか、実はアツいところとかあるし、おそらく読者の期待するであろうSFシンデレラがそのまま出てくるので、軽い筆致も相まってグッと引き寄せられる。
一方、竹取物語となるとノリが変わってくる。読者の取り分がほとんどだったシンデレラから、作者の取り分が徐々に上昇していくような。まず竹が簡単な知性を持っていて、竹取の翁とかに電子戦を仕掛けてくる。かぐや姫は半ばトロイの木馬的な感じで竹に規制して生まれるわけだけど、そこからは攻殻機動隊の少佐バリの高性能っぷりを発揮する。面白い。ちょっとデカイ設定が入ってくるのがうーむとなったけれど。
白雪姫はちょっと悲しい。仮想現実の話が社会問題になって、オオゥそうかとなる。ここから雲行きが変わっていく。4つ目の話の下敷きはさるかに合戦なんですかね？ ちょっと自信がない。カニが主人公なのと蜂が出てくることからそういうふうに思った。なんでわからんのかというと、前半3つとは違って、話の流れを原作どおりに踏襲していないからだ。あと主人公がトランスヒューマンじゃなくてカニだしね。あとテナガエビとシャコとタダタダタダヨウガニが仲間。タダタダタダヨウガニに至っては劇中ではTTCと言って、群体が1つの知性を持つみたいな感じの描かれ方をしている。うぉー、ハードSFだぜ。ただ笑かしにきてるけれど。そもそも甲殻機動隊っていうタイトルだしね。ただ、カニ部隊視点でアクションやってるもんだからだいぶ読み進めにくい。後半になってくると慣れてくるんだけれど慣れてきたところで終わるみたいな。スラスラ読めるアクションものを書くのは難しい。自分で書く時はもはや戦闘描写は諦めて、データとそれを見つめる戦術AIとの対話みたいなののほうがまだ読みやすいのが書けるんじゃないのとは思うことがある。ただ、これが行き着くと富野アニメの口喧嘩になるのかもしれない。
モンティ・ホールころりん、もといおむすびころりんはとにかくウィットだらけで面白い。ここで出てくる特異点コンピュータっていうアイディアは好き。しかしこれを叩き割るんだよな。ちょっとだけ人間やっててトランスヒューマンもかわいいところあるなってなった。アリとキリギリスは完全に人間っぽい話で、とにかくウェットなんだけれど最終的に今までの話を折りたたんで、なるほどこういうふうにつなげるかとなった。竹取物語のところのデカイ話は全く触れられてないけれど。
そういうわけで、キーワードをググりながら読むともしかしたらSF入門になるかもしれない……どうなんだろう？
ですます調の功罪
昨今、僕の話でも結構な割合で「ですます調」を採用することが多くて、まあこれなんでだろうなと思うんですけれど、話がやりやすいからですね。ですます調の時点でほとんどのケースで地の文は三人称になると思うんですけれど。いや、丁寧なおじいさんが一人称でやってるとか日記とかね、あと過去のインタビュー形式とかそれでですます調を三人称以外でやることもできるとは思うんですけれど。それはもっと技巧的というか。
ここでいう話がやりやすいって、話を聞いてもらいやすいってことなんですけれど、別の「だである調」だとなんかドギツイ。「ええ、そうなの！？」ってなる。ですます調だといきなり不思議な事が起こっても「ふむー物語だからそういうもんか」ってなる。童話は「ですます調」で読み聞かせてもらっていますからね。物語を物語であると認識できるから、その分受け入れられる器が広いわけで。
ただ、感情移入という点では劣る。三人称という時点で劣ると思うけれど。三人称にも神視点と個人視点？があるけれど、個人視点ではない三人称はどうしても感情移入がしにくい。SFってそもそもが説明になりがちなもんだから、「この話って小説なんだっけ、未来技術の解説書だっけ？」の狭間で揺れ動く。いいエンタメやってるSFは物語がちゃんとある。ガジェットがバキーンバキーンぶつかっているものにはならない。だけど物語に感情移入って必要だっけってなると必ずしもそうではなくて、感情移入ってたぶん読みやすさパラメータが上昇する変数なんじゃないかと思って。読みやすさは面白さにつながると思うんだけれど、面白いってその軸だけじゃないし、必ずしも「面白い小説」に必要なものではないかもしれない。
ここまで書いてきて思ったけれど、三人称神視点だと感情移入できませーんってのは、もしかして読解力が低いから！？とおもったけれど。
「ですます調」は便利だし、それなりにテクい事ができるので最近のマイブームだし、そもそも童話集という体のこの本では必須の要素だと思う。
巻末の講評
ただ巻末の講評で審査員の方が「普通のSFが読みたい」と言っていて、テクに走るなと解釈した。そもそも普通の書き方でちゃんと書けないと、テクい書き方でもうまく話を書けないよねっていう。別の作品に対する感想で「斜に構えすぎ」もあった。面白い。サプライズな面白さが講評にあってずっと笑ってた。
まあ明るいSFも読みたいよね！ってのがある。なんかデカイ根底のテーマがあって、話の始まり、つまり問題提起からやってガジェットやらなんやらでオチまでつなげるのもあれば、このオチやりたいから逆算で組み立てるのもあるとは思うんだけれど、アイディア一発勝負だと、伸びが無いと言うか、そういう感じなのかなと思った。あと書くときの技量もいるしね。僕も同人で戦闘機アクションとか書いてましたけれど、「お前にはまだ早い」って言われたことありましたね。やりたいことに技量がおっつかないというか。身の丈にあったことを書いて鍛えるのが大事なんだなって。SF書くのはこう思うとフルスタックだわ。
というわけで皆さんも読んでみてください。
2018年の振り返りと2019年の抱負
あけましておめでごうとございます。
最近自宅Macの環境をデュアルディスプレイにしたんですが、スリープ後に認識しなくなるなど、調子が悪かったのです。調べたらMojaveにアップデートすると治るらしいので、Fateの番組見ながらアップデート待って、ロード・エルメロイII世の事件簿が始まるぐらいに終わって、再起動したら以前真っ暗。。。ドライバインストールし直したりしてて、最終的にディスプレイ側のケーブルを抜き直したら直った。。。なんなんや。。。
もうすぐ2018年も終わりますが、モハーベアップデートしたら外部モニタが復活しません。良いお年を〜
— トーカナイザの守護霊 (@mackee_w) December 31, 2018
デバッグで2018年が終わり、デバッグで始まった2019年ですが、年中デバッグしている予感がします。
2017年はこちら 2017年の個人的なまとめ - ぱいぱいにっき
登壇
2018年はそこそこ登壇しました、と思ったら残っているスライドは2つだけだった。しかしこの2つがデカかった。
YAPC::Okinawa ONNASON 2018
WebSocketミドルウェア、kuiperbeltの話です。この時点では、この後に直接関わるプロジェクトでは導入されておらず、社内の関わってないプロジェクトに導入されている状態。
ちなみにこの時は2泊3日で沖縄に行ったのですが、9月にも沖縄に行ってて、これはOkinawa.pm #7でした。このときは箱庭諸島CGIの話をしました。あと、5日ぐらいいて、レンタカーも借りてあちこち回ったので満足満足という感じです。どこかで写真をあげよう。
CEDEC2018
こっちもkuiperbeltの話。このときには導入されている関わっていたプロジェクトがリリースされた直後でした。来年早々にクローズしちゃうけれど。。。まあそれは仕事のところに書こう。
CEDECは、聴講者がアンケートを書くのですが、その集計結果はスピーカーにも来ました。概ね好評だったようで良かったです。ただ、コンシューマの人には物足りなかったかもしれないと思ったし、そこまで厳しい仕事はやってないので、機会があればそういうリアルタイム通信もやっていきたいですね。
その他
Okinawa.pmで沖縄行ったのと、その流れで城でLTしたり。LTもCGIの話ですが。あと、Gotanda.pmでpostderefの話したり。他にもなんか忘れてたら教えてくれ！
仕事
- 1月: 後述する理由でほぼ休み
- 2月: 去年ずっといたチームに復帰 (Perl5)
- 3月〜9月: 今いるチームで負荷試験やらリリースとかをやってた (Perl5, 負荷試験でGo)
- 10月: 社内向けシステム作ってた (Go, Vue.js)
- 11月, 12月: 9月までいたチームに復帰した (Perl5)
だいたい、Perl5書ける人がなかなか少なくなってきているというもあって特定プロジェクトに張り付いているみたいなのもあったかなあと。
2018年の仕事の仕方を考えると「今までの貯金を使いつつ、やってたことから少しはみ出すことを身につける」みたいな感じでした。あとコミュニケーションで失敗を繰り返したり、ああしてればみたいなことは今でも考えるけれど、反省できるだけ幸せでは？ という気持ちですね。
私生活
身体
1月にまた骨を折るというのがハイライトでしょうか。今回は結構ひどくて、今でもリハビリに通っています。普段生活する分には問題ないし、体力も回復しているとは思うんですが、右肘の可動域が戻ってないという感じ。2019年こそ骨を折らない、むしろ一生骨を折らないのが人生の目標です。
同人誌
5月と11月と12月に出しましたが、5月,11月はフリーペーパーしか書けないぐらいに落ちぶれたのですが、12月はなんとか新刊を書きまして、フリーペーパーも調子が良かったので「小説の書き方思い出したのでは？」というのが本音です。なんかやり方分かってきた。
ゲーム
2018年にやったゲームってMHWとCities Skylinesとイカ2(継続)とDQビルダーズ2(今やってる)ぐらい？ あ、AssetoCorsaやる環境も整えたんだった。
電子工作
3Dプリンタはちょいちょいやってますが、ハンダとかはやってなかったような。あ、キーボード作ったんでした。
今でも自宅で使っています。今打っているのがこれ。会社ではkeyboardio使ってます。
あと、ハードといえば、buildersconのノベルティとして電子名札を配りました。
板をFusion360でモデリングして、レーザーカッターでMDFを切るみたいな担当をやりました。実際皆さんが持っているやつは業者さんに切るのをお願いしたやつですが。こういうプロダクトデザインも面白いなあと思いました。
カンファレンス
builderscon::tokyo 2018ではコアスタッフとしてやってました。名札の板を切る人担当です。コアスタッフやってたらいろいろ思うことがあり、会社でも勉強会おじさんをやり始めました。自称社内勉強会オーガナイザー。
2019年の抱負
仕事は、軸はバリュー出せる今持てるものを使いつつ、全く新しいことにチャレンジしてみたい気持ちもします。C#/Unityはさすがにやらないといけないかなあ。あと、去年はAIとかそういう引き出しがなくてつらくなったこともあったので、ゲームAI、機械学習問わずそういうことを身につけるのも全く新しいチャレンジになりそうです。
身体は骨を折らない。骨折らないアクティビティはやっていきたい。
文は書く。ブログも他愛もない日常をやったり適当なショートショートをやるやつも書いて良いのではないか、もっとハードルを下げてやるのが良い気がする。
電子工作はドローン再開かなあ。アンダー199gクラスをやりたい。
ゲームは2019年はACE COMBATはじめいろいろ出るのでやらねばという感じ。いろんなアーマードコアも出ると思いますし。
登壇は来年はYAPC::Tokyo 2019がまず来ますが、その後もコンスタントにやっていく。Web以外、例えばハードウェアの勉強会とかにもお邪魔したいですね。
まとめ
したいことがいっぱいある、というのは引き続きですが、どうせやれるのは2割ぐらいでしょう。それぐらいに人生や自分の力を見積もっている。ただ、例年より穏やかな年末年始を過ごしているので、2019年はもっと大人になりつつアクティブさは維持するみたいなのがエモなところです。以上。
GitHubにメール書いて放置アカウントを消してもらってkuiperbelt organizationを作った
要約
- そろそろ合ったほうがいいなと思ったので、kuiperbeltのGitHub Organizationを作ろうと思ったら、もう既にそういうユーザがいた
- 見てみると最近活動していなさそうだったので、GitHubにメールを送って名前空間を開放してもらった
- すぐにkuiperbelt organizationを取ってmackee/kuiperbeltをtransferしました
経緯
- DockerHubのautomated buildでimageを作ってもらう関係上、kuiperbeltリポジトリに同居していたサンプルアプリを別リポジトリに追い出そうと思った
- mackee/kuiperbelt-sample-appだとしまりがないので、kuiperbelt organaizationを取ろうと思った
- 今後作る予定の周辺ミドルウェアなんかも入れる予定です
- でも https://github.com/kuiperbelt は誰かのアカウントとして取られていた
- 最近使われている形跡がない……2013年に作られてリポジトリはなくどこかのリポジトリに何回かコミットした程度
- ここで以下の記事を思い出した
- 某Slackで上記ブログのlestrratさんに聞いてみたら「突撃あるのみ！」と背中を押してもらったのでメールすることにしてみた
GitHubにメール
- 上記azuさんのブログに「問い合わせフォームよりはメールのほうが速い」とあり、まあそりゃそうだよなと思って直接メールした
- 文面は自分で書いてみようと思ったが、だいたい参考にしたazuさんのものと同じような感じだった
- で、送ったら20分で返ってきた
Hi Taniwaki, You are in luck — we have classified the kuiperbelt account as inactive and released the username for you to claim, as per our Name Squatting Policy: https://help.github.com/articles/name-squatting-policy Be quick, as the username is now publicly available. Have a great day!
- このName Squatting Policyの存在は知っていたが（というか知ってたから問い合わせたんだけれど）、あまりにも早すぎてびっくりした
- 返信来てからメールを確認するまで1時間ほどたっていたので急いでkuiperbelt organizationを取った
ogranaizationへの移管でやること
- Goはcodeに自分へのインポートパスがgithubのフルパスで書かれていることが多く、置換が必要
- また、ドキュメントにもコードへのリンクやインストール方法などで入っていることがあるので置換する必要がある
- やった
- 見落としていたのは
.travis.ymlでタグ切った時にリリースバイナリを作るところでリポジトリ名を指定していたのでここもやらないといけなかった - DockerHubも同じようにOrganizationを作って
docker pull kuiperbelt/kuiperbeltで利用できるようにした
まあいろいろやった。あとこのブログ書く時に確認したらhttpsに出来ててめでたい。
そろそろ正式サービスが始まる#arukas でkuiperbeltを動かしてみる
これで
を動かす話
要約と言うか感想
- Arukasは簡単だけれど、その裏返しで制限が厳しい
- private registryにはまだ対応予定状態だとか
- VPNっぽい仕組みがないとか
- kuiperbeltが想定している環境ではない
- データストアとArukasは非常に相性が悪い
- kuiperbelt instance 1台構成なら出来たのでやり方を晒してみる
何を構築した？
- かんたんなWebSocketを使ったチャットアプリ
- kuiperbeltを使えばWebSocketとか何も考えずに作った普通のWeb Applicationでも簡単にWebSocketを扱えるようになりますというのを示したい
構成
- Perl/PSGI Application x N
- Redis x 1
- 高可用性取るならレプリケーションしたほうが良い
- というかコンテナでデータストア運用するのが（ｒｙ
- ここもRedisじゃなくてもKVS的な機能を持っていれば良くて、pub/subとかは使ってない。SET型使ってるけれどmemcachedであれば、カンマ区切りで複数個入れるのでも良くて、と思ったけれどアトミックに要素を出し入れするのは考えないといけ無さそう
- ぶっちゃけRDBMSでも良い
- というか認証も暗号化もかかってない。ノーガード戦法で平文をインターネットが漂っている
- ホストとポートを推測しにくいものを使って、パケットがArukas内部で収まっていることを祈りながら使っているけれど、みなさんは真似しないように
- ローカルの
redis-cliから繋げられてデバッグに便利
- kuiperbelt x 1
- アイコンはWebSocketのロゴらしいです
- ここが現状1台なんだなぁ
- いや、今回はAppのほうでkuiperbeltのエンドポイントを返すようにしたのでそこを複数個にしてクライアントがランダムで何処かに繋げば複数台が可能
- ここには課題があります
kuiperbeltがのびのびと動くための条件
- のびのび=クライアントからのWebSocketを扱うkuiperbeltが複数台でロードバランサー配下に収まって機能する
- Web Application側がメッセージをクライアントに送る時に対象のクライアントがどのkuiperbeltにつながっているかを知る必要がある
- この情報は接続時コールバックで渡ってきてWeb Application側がKVSとかに保存する
- 接続時コールバックでWeb Applicationに通知するための「外からつながる自分のホスト名/IPアドレスとポート」をコンテナ自身が知る必要がある
Arukasでは
- アプリケーションは単一のエンドポイントを持つ
- これが曲者でアプリケーション起動時に設定したポートに飛んでいくが、httpsしか対応していないっぽい？
- コンテナ一個一個にホスト名とポートが割り当てられる
- これらはガチャ
- コンテナごとに割り当てられるホスト名とポートをコンテナ自身が知ることができれば勝つる
- 現在は敗北してます
- しょうがないので1アプリケーション1コンテナ、増やしたいならアプリケーションを増やす、この辺のリストはWeb Application側に環境変数で渡せるようにした
- このやり方でも無停止でkuiperbelt側を増やすことが出来る
- 1コンテナでも512MBもメモリがあれば2500接続ぐらいは余裕で持つ事ができるわけで、全然問題無さそう。メッセージ数はちょっとあれだけれど
- 今のやつはつながっている全員にブロードキャストしているので危ない
設定例
kuiperbelt
webapp
redis
- redis:latest指定して立ててるだけ
展望
- 前述のhyper.shでも試してみる
- つながるIPをコンテナにアタッチできるみたい
- ドキュメント見る限りはそれでもやはりよしなスケールは出来無さそう？
- GKEもといkubernetes...
- もっとちゃんとしたアプリケーションを作る
- このサンプルアプリだと見た目で夢が広がりにくいかなあ
- あとコンテナで監視ってどうやるんだろう。。。
追記:2018-03-22
Twitter眺めてたら、 pottavaというイメージをArukasで立てている人がいて、そのコンテナのURLを叩いてみると、渡ってきた環境変数やらがババっとJSON APIで取得できるという代物だった。
その中にMARATHON_HOST と MARATHON_PORT という環境変数があり、値の方はコントロールパネルで見たことのあるようなものが。。。。
早速自分も同じイメージで立ててみて検証してみた。
2台で立てるとガチャでこんな感じで取れた〜ワンチャンあるで〜〜〜 pic.twitter.com/OJb0ApaCzq
— トーカナイザの守護霊 (@mackee_w) 2018年3月21日
である。つまりこれは望んでいたものではーーー？？？？？
今のkuiperbeltの公式イメージにそのまま適用することは出来ないが、arukas用の設定ファイルを作ればいけるのでそういうDockerfileを書いてみようと思う。