Cosmos Japan #2に参加してきました

cosmos-jp.connpass.com

2回目ですが、満員にならず、Cosmosあんまり流行ってない感が...

韓国だとそれなりに流行ってるらしいと聞きました。
今回は下記のようなことが話されました。

  • Cosmos SDKにNFTモジュールが入ったという話
  • P2PレイヤーではAminoを使っている話
  • IBCの進捗
  • icsというSpecベースで開発が進んでいるという話

Cosmos SDKにNFTモジュールが入ったという話

FTはBankモジュールという名前でこれまであったのがNFTのモジュールも先週辺りに追加されたとのこと、transferやburnができるとのこと。
ただ、Bankモジュールを使っていないっぽい? Cosmos SDKのモジュール設計は結構微妙というかわかりにくい...

P2PレイヤーではAminoを使っている話

protobufの拡張として定義されているAminoをつかってP2Pレイヤーのメッセージをやり取りしているという話がちょっと出ました。前からTCP周りを調べているときにAminoってなんなんだろうなと思っていたのが、調査するのが面倒だったので、少しでも話しが聞けてよかったです。

IBCの進捗

どうやら予定では今年中にでる事になっているが来年になりそうとのこと、結局みんなIBCローンチ後の全体像がわかってない感じが...んーこういうところが、流行らなそうなんだよなーと思いました。

icsというSpecベースで開発が進んでいるという話

github.com

Interchain StandardsというSpec策定ベースで進んでいるとのこと、Web3とかISOみたいな感じですが、 Interchain Standards という名前はすごいですね。
ics26として、Relayer Moduleが提案されていて、これがHubらしい?

日本だとEthereum系が人気だったり、他の新興Blockchainも常に出てきているので、Cosmosには厳しいですが、Interchain Standardsとなったらいいのですが...

もうちょっとAminoを探ろうかなー

「対話」で駆動する組織開発とアジャイル開発に参加してきた

guildworks.doorkeeper.jp

INSIDESというプロダクトをリクルートさんとギルドワークスさんでどうやって作っていたのか?という勉強会でした。 リクルートマネジメントソリューションズが何やっている会社で、もともとどういう体制で開発が始まったのかという前提があまり無かったので「?(はてな)」な部分が多かったです...

前半はリクルートマネジメントソリューションズの方によるINSIDESのプロダクト紹介でした。やっぱり、HR Techって激戦だけど、価格帯と普及率的に考えるとまだ行けそうかもしれない?大手に集約するのか、乱立するのか?どっちだろう?OSSにして、コンサル料だけでとるってビジネスもありかも?なんてことを考えました。

後半はギルドワークスの方によるINSIDESの開発の話でした。「余白」、「雁行陣型開発」、「背骨駆動開発」というのがキーワードだったような気がします。 「余白」とは開発の余裕をとるというのことで3つくらいあった気がしたのですが、、、忘れてしまいました。余白のある開発、羨ましい... 「雁行陣型開発」はテニスのフォーメーション?から来ているようです。先行して作る人がいる開発のようでした。まー、大体はライブラリ開発とか土台を作る人がいるもんだとは思いますが、ここを失敗すると結構辛いですね。 とはいえ、経験ある人でも大概、最初作ったものはいまいちだったりするので、素早く作り直せるようにできる判断というのも大事な気がします。 「背骨駆動開発」はプロダクトのコアバリューを作って行ってから肉付けしていくというような話でした。これも、当たり前な気がしますが、たしかに開発していると脱線してしまうことがよくあるので、意識したほうがいいですね。

最後は対談でしたが、前提知識がないのでちょっとよく分からなかったです。。。 質問で心的安全の話が出ててましたが、やっぱり心的安全がバズワードになって解釈が、んーってなってきているような気がしました。

とりあえず、「正しいものを正しくつくる」をよんで見ないとなーと思いました。

effect system勉強会に参加してきた

algebraic effectsやextensible effectsについての勉強会
正直全然わからずに書いているので以下おおよそ適当です...
本当は、勉強会当日に公開しようと思ったのですが、内容が難しすぎて消化してたら時間がたってしまいました...

algebraic effectsやextensible effects、それぞれの出目は違う?けど似ているところもある。というか両方共抽象化だから、広い意味で似ている?なんてことを思っています。

個人的にはalgebraic effectsってfreer monadに似ているような気がして、algebraic effectsもロジックとエフェクトを分離している感じで、extensible effectsもそういうことが出来るけど、こっちの方はモナドの合成はスタックになるのを直和で表現することで扱いやすくしている意味合いが強め?
雑な理解だとモナドを特定のエフェクトをするものと捉えるとextensible effectsもalgebraic effectsみたいなもんなのかな?
algebraic effectsの方はモナドが出てこないから合成は自分で実装する感じなのかな?
というようなことを考えつつ...

Extensible Eff Applicative

Monadに比べたApplicativeの良いところは、状態をもたない(もてない)ので並列処理ができたり、エラーチェック結果を複数持てたりする
そんなApplicativeをextensible effectsにした話 Free Applicativeの話をちゃんと聞いたのは初めてだったので勉強になりました。

www.slideshare.net

名前付きeffects

extensible effectsってそもそもHaskell出身でいいのかな?他の言語ではScalaでしか聞いたこと無いし...?
Haskellのパッケージ的にはextensible effectsがでてfreer effectsやextensibleがでた感じで、今は発表者のfumieval さんのextensibleだけがメンテされている感じ?もともとfreer effectsは配列でMonadを持っていたのをdictとして名前付きで持てるようにすることで同じMonadインスタンスが持てるようにしているという話。この後algebraic effectsでも配列の話でeffectsを持っている話が出てきて似ているなーと思ったけど、そうなのかな?
名前付きeffects

Effect{ive,ful} Cycle.js

freer monads more extensible effectsで同じような図が出てくるんですよねー。副作用をエフェクトって捉えるとやっぱり同じもんなのか... f:id:t10471:20190527233403p:plain

qiita.com

Effective Rust

ここに来てコルーチンの話が...以降の発表者のなかにも継続の話が出てきて、そっちの文脈も関係しているのか...ここで言うコルーチンは非対称コルーチン?

Asymmetric CoroutinesによるOneshot Algebraic Effectsの実装 - lilyum ensembleに下記のように書いてあるし、そうなんだろうなー...

Algebraic effects and handlers(以降 “algebraic effects” と省略)は、いわば限定継続を取れる例外である。

docs.google.com

Monads and Effects

effectをモナドのパラメーターとして表現して、effect付きのパラメトリックモナドは合成出来てeffectルールを持って作用していくような体系を作ったという感じなのでしょうかね...? speakerdeck.com

How do you implement Algebraic Effects?

コルーチンやFreeモナドとAlgebraic Effectsの比較、Algebraic Effectsはそれらの一般化と捉えることが出来るのかな?
そう捉えると面白いということっぽいのかな? nymphium.github.io

Effective Idris: Effects

IdrisにEffects あったんだなー。
HaskellMonad前提の言語だけど、そういうのが弱い?からeffectを導入しやすいのかな? keens.github.io

Row-based type systems for algebraic effect handlers

Parametric effects by row polymorphismということで、Algebraic Effectsの説明なんかもありしました。
effectを型に入れたり、列多相的にeffectを入れた感じなんですかね?

www.slideshare.net

全体的に勉強が足りないな...
だんだん最後の方が適当に...

『n月刊ラムダノート』創刊記念パーティー創刊記念パーティーに参加してきました

先週のefects勉強会の参加記事を書いている中でコルーチンの話が出て来て、ちょうど復習しているところだったので参加してきました。

connpass.com

実に濃い内容で、あんまりちゃんと消化していないのですが、コルーチンの記事以外のコルーチンの話であるPythonの非同期処理の歴史を聞くことが出来て非常にためになりました。 また、座談会は興味深く聞かせてもらいました。
結局、言語が他の言語の概念を取り入れる中で他の概念とミックスされてきたことによる単語の進化みたいなものが起きたんだろうなーというのが、個人的な感想です。
確かに日本語だけでも少しづつ変化しているし、日本語が英語に取り入れられる中で少し変わるというのはオタク用語などでも見受けられる訳で、割と自然な出来事なのかもしれないですね。
generator、future、fiber辺りががいろんな言語で混ざっていって今のようなことになっているんだろうとは思いますね。futureも最初のJavaのFutureとScalaのFutureも違ったし、Rustはコルーチンなのかgeneratorなのか...?
んー難しい...

話は変わりますが、ラムダノートさんは本当に尖った面白い本を出していて最高の出版社ですよね!

www.lambdanote.com

あと、会場の料理がめちゃくちゃ美味しかったです。を提供してくださったTreasure Dataさんありがとうございます。

RustのLT会 Shinjuku.rs #4 @FORCIAに参加してきた

forcia.connpass.com

Rustの勉強会に参加してきました。Shinjuku.rsは初参加でした。

RustでWebSocketな自社APIを使う

www.slideshare.net

@emergentさんの発表、Tokioをやると、非同期処理のプログラミングパターンの理解とSend,Sync, Arc, BoxなどのRustの型が出てきて初心者殺しですよね。。。
自分はプログラミングRustに型の説明が網羅的にあるので、そこで勉強しました。Rustの非同期系の日本語記事でわかりやすかったのは下記のスライドです。

speakerdeck.com

Rust でもモナドは実装できるのか?

@helloyuk13さんの発表、高階カインド型がない言語でモナドってどうなんだろう?TypeScriptとかでも実装している人はいるけど、嬉しいのだろうか? 作ってみるのは楽しそうだけど。
個人的にはモナドにはメソッドチェインとして記述出来ることと(本質ではない...)、強力な型システムによる安全なプログラムを書くことが目的な気がするので関連型にすることによってちゃんと出来るのかな?と帰りながら考えました。(この部分はかなり正しくない...)

speakerdeck.com

RustでService Mesh

@11Takanoriさんの発表、Linkerd2のはなし。Conduitって名前から変わった?Linkerd-proxyがConduitだったもの?
確かConduitはKubernetes用に作ったことがenvoyとの差別化だったような気がする。LinkderdはScalaだったんでkubernetes界隈からは評判が良くなかったのかな?Linkerd2はcontrol planeはgoでproxyがRustっぽい。
発表内容的に興味深かったのはArcのupgrade,downgradeなんてのがあるのを初めて知りました。ただ、あんまり使い方はよくわかってないです。

hackmd.io

medium.com

他の方もありましたが、すみません。
ちゃんと聞いてたのはここまででした...

関係無いけど、今更ながら、佐藤千亜妃を知った。今ん所好き。 安直だけど、PrologueがFishmansっぽい。

EventStormingワークショップ 〜かつてない図書館をモデリングしてみよう〜 に参加してきた

最初、EventStormingはDDDの文脈かなんかで知ったんだと思います。
一度やってみたいと思いつつ、やるタイミングがこれまでありませんでした。
今回、「Introducing EventStorming」の読書会のスピンアウト企画として、ワークショップがあるということで参加させてもらいました。

やったことはこのスライド通りとなります。

www.slideshare.net

今回は本に則ってやるということでした。

成果は下記の感じです。

本当は1回2時間区切りでやるのを5時間でやったこともあり、とても疲れました。
やってみた感想は、EventStormingを体験できたことはすごい良かったです。また何回かワークショップに参加したいと感じました。
ただ、みんなが思っている問題がビジネスモデルが謎ということになってしまったのが若干残念でした。
ビジネスモデルを考える目的か、ワークフローを考える目的かが曖昧だったのが原因だったのでしょうか?

良かったと思ったのは、特に決まってないことはとりあえずホットスポットに記載しておき、議論が発散するのを防げるのが良いと思いました。

難しそうだと感じたのは

  1. ファシリテーション力が高くないとうまくいきにくいかも
  2. 会計とか幅広い人にも参加してほしいけど、面倒臭がられそう

あたりです。

慣れていくとEventStormingは有効だと思うのですが、慣れるまでにどのくらいかかるのか気になるところです。

主催者の方ありがとうございます!

Plasma × Substrate 勉強会 #1に参加してきた

neutrino.connpass.com

Substrateという文字が目についたので参加してみました。

感想

Plasmaはそんなに興味がなかったので追っていなかったんですが、結構進化していPlasma Cashflowとか知らなかった。 個人的にはPlasmaのExit Gameは実用的なのか疑問ではあるけど、Fast Finalityのために担保が出てくるとか興味深いです。 スマートコントラクト(Solidity)が好きじゃなくてPolkadotみたいなインターチェーンの方が好きというのもありますが、 正直セカンドレイヤーとかじゃなくてファーストレイヤーのアトミックスワップ(DEX?)として考えたほうが有用なんじゃないかと感じました。

Plasma 及び Plasma Chamber の説明とデモ

Daiでの実装もあることに驚きました。実用的になってきてるのかな?

Substrate を用いた Plasma チェーン、Plasm のデモと解説

SubstrateでPlasmaを実装するためUTXOを実装しているとのこと。 OnFinalizeでSubstrateのブロック生成タイミングでメインチェーンに書き込みアクションができるとのこと。