Posts for: #2022/11

ふりかえりの目的とワークショップ

#life  #postmortem  #workshop  #community 

早めに帰ってきて晩ご飯を食べてからまたオフィスに戻って作業して2時に寝て7時半に起きた。

ストレッチ

今日の開脚幅は開始前153cmで、ストレッチ後155cmだった。先週よりは体力的に回復しているものの、今週も多忙で椅子に座っている時間が長かったので数値が悪くなっているのかもしれない。基本的には、お仕事が忙しい = 座っている時間が長い = 同じ姿勢の状態を維持する = 筋肉が固まったり運動不足に陥るという理屈で体調が悪化する。今週はなぜか右太ももの前あたりの張りが強かった。逆に腰や全身の負担は軽減したように感じた。開脚幅の数値はよくないものの、先週よりは復調しているような感触。実際のところはまだよくわからない。

ふりかえりとワークショップの定義からコミュニティ作りのなにか

書籍同様、タイムラインなどでみかけた記事を後で読もうと積ん読しておくときがある。次の記事もおそらく公開時期にみかけて気付いたら積ん読のまま1ヶ月が経過していたのを精読してみた。

読み始めて、いくつかもの思いにふけりつつ、そこから派生して他の作業もしながら戻ってまた読み進めて、この記事を読むのに5時間かかった。そのぐらい私にとっては示唆のある読み応えのある記事だった。書いてあることのいくつかの点が他の事柄に繋がっていて、その点と線を確認しながら読み進めたので時間がかかってしまった。よくぞこの記事をブックマークしただけで流さなかったと過去の自分に感心したぐらいにはよい記事だった。ワークショップという言葉はよく聞く言葉ではないし、グループワークをする小さいセミナーのイメージを私はもっていた。教育学の分野の研究者によると次のような定義があるらしい。

ワークショップとは

  • 講義など一方的な知識伝達のスタイルではなく、参加者が自ら参加・体験して共同で何かを学びあったり創り出したりする学びと創造のスタイル (中野民夫, 2001)
  • コミュニティ形成 (仲間づくり) のための他者理解と合意形成のエクササイズ (練習) (仮宿俊文, 2017)

ちょうど課題管理の文脈でふりかえりをどう設計しようかを考えていたときにこの記事を読んだ。ふりかえりの目的を多義的に捉えるという発想そのものが私にはなかったのでそういった目的も含め、ふりかえりを実践していければよいのではないかと、自分の中にももともと燻っていた火種を見事に言語化してくれて示唆に富む記事だと感じた。

  • 既存の業務に対する課題や改善の洗い出し (一般的なふりかえりの目的)
  • チームのメンバーとコラボレーションする上で他者の考え方や意見を理解するきっかけの1つにする
  • エージェンシーは自分一人では育まれず、同僚や上司、チームや組織との関係性の中で育まれる

新しいお仕事で3週間

#event  #go 

2時に寝て4時に起きて仮眠して6時半に起きた。たぶん寝たんだろうぐらいの感覚。10月まで対外的には週4日で働いていたのを、11月から週5日フルタイムの働き方に移行して、やっぱりしんどいという実感がある。対外的に週4日でも10月もオフィスに来て自社のお仕事をしていたり、半日ぐらいは社外のお仕事をしたりはしていた。それでも働く義務の有無によって、意識の違いか、プレッシャーやストレスの面からなにか働き方が違うように思える。生活も働き方もまったく同じなのに。

盛り上がってないイベント

ハッシュタグ をみてもほとんど関係者や発表者しかコメントしていないようにみえた。過去に新規事業の立ち上げに協力したプロジェクトの発表があると元同僚のタイムラインで知ったのでその発表だけみてみた。私が辞めてから3年ほど経つので新規サービスも追加されていてその内容がメインだったように思う。

あまり技術的な内容ではなく、ビジネス向けでもなく、どういった属性の聴衆向けの発表なのか、私にはあまりピンとこなかった。発表の準備不足な印象を受けた。発表を無理やり押し付けられたのかもしれない。

go の Time 型とタイムゾーン

go の Time 型は Location をもっていて、タイムゾーンも一緒に扱える。モダンな言語なら時刻を扱うときにタイムゾーンをセットで扱うのでよいと私も思う。タイムゾーンをもっていない時刻型とタイムゾーンを設定するための余分なコードのことを考えずに済む。

package main

import (
	"fmt"
	"time"
)

func mustGetJST() *time.Location {
	jst, err := time.LoadLocation("Asia/Tokyo")
	if err != nil {
		panic(err)
	}
	return jst
}

func main() {
	now := time.Now()
	fmt.Println("now:", now)
	fmt.Println("jst:", now.In(mustGetJST()))
	fmt.Println("utc:", now.UTC())
}

実行結果。

$ export TZ="CET"
$ go run test_time_now.go
now: 2022-11-18 17:00:30.08305121 +0100 CET m=+0.000011788
jst: 2022-11-19 01:00:30.08305121 +0900 JST
utc: 2022-11-18 16:00:30.08305121 +0000 UTC

技術選定の根拠

#go  #programming 

0時に寝て5時に起きた。夜中に目覚めたかどうかはわからないぐらいにはたぶん寝てたと思う。

go の http フレームワークの選定

net/http で実装していた web api サーバーにフレームワーク導入しようかと考えている。いままでは認証・認可を外部で行う想定だったが、やっぱり api サーバーに実装した方がよいだろうと要件を再確認したので routing と middleware を再利用できるフレームワークを使うメリットが出てくる。net/http 上で直接 routing, middleware を実装するのは別に難しくないから自分で実装すればよいという考え方がある。一方で誰が実装しても大して変わらないものを車輪の再発明する必要があるのかというところに私は懸念に感じる。また context があとから標準ライブラリに追加されたため、net/http の HandlerFunc は context をシグネチャにもっていない。リクエストコンテキストをもっていないのが net/http の欠点だと私は考えていた。しかし、調べてたら NewRequestWithContext が追加されていてハンドラーではなくリクエストからリクエストコンテキストを扱えるようになっていた。これは私の勘違いだった。

フレームワークを使おうと決めて難しいのはなにを選ぶか。最近の流行り廃りや動向を私は知らないので基準がない。たまたましぶかわさんの記事をみつけて読んでいた。

この中で紹介されている chi か echo のどちらかにしようと直観で決めた。echo は以前 go の勉強会をしたときにいけうちさんが採用していたのでよく覚えている。そのときの話しを聞いていてもよさそうにみえた。たまたま echo のサイトをみたら Shiguredo さんのロゴがあって驚いた。スポンサーをされているらしい。chi はまったく知らない。どちらも十分によく使われていて middleware も揃っているフレームワークにみえる。本質的にはどちらを選んでも構わない。一方でマネージャーとしてどういう調査をして、どういう根拠で、どの技術を選定するのか。メンバーに対して説明責任を果たすためにこの2つのフレームワークの調査をすることに決めた。私自身がどちらもフレームワークも使ったことがないので軽くコードも書いてみてどんな雰囲気なのか感触を掴みつつ、フレームワークのソースコードも読んでみようと思う。

デジタルノマドへの関心

#mermaid  #coworking  #community  #event 

0時に寝て2時に起きて6時に起きた。いまは眠れる状態に落ち着きつつある。

pandoc と mermaid charts の扱い

markdown のドキュメントに mermaid で図を描く機会が増えてきた。markdown を pdf に変換するツールがあって内部的に pandoc を使っている。そのツールで pdf 変換してみたら mermaid 記法がそのままテキストで出力されたので変換するときに図に置き換えられないかを調べてみた。例えば、次のようにして markdown から html に変換できる。

$ pandoc mydoc.md -f gfm -o mydoc.html

次のように mermaid 記法がそのまま出力される。

<pre class="mermaid"><code>flowchart TB

subgraph cr [Container Registry]
  repo[repository]
end
...

mermaid を cli ツールとして mermaid-cli がある。markdown を直接渡しても mermaid のコードブロックを検出して画像変換してくれる。複数あってもよい。これはちょっと驚いた。

$ git clone git@github.com:mermaid-js/mermaid-cli.git
$ cd mermaid-cli
$ yarn add @mermaid-js/mermaid-cli
$ npx mmdc --version
9.1.7
$ npx mmdc -i mydoc.md -o mydiagram.png
Found 2 mermaid charts in Markdown input
 ✅ ./mydiagram-1.png
 ✅ ./mydiagram-2.png

cli でできるなら何とでもなるんじゃないかともう少し調べていたら次の gist をみつけた。

pandoc filters という仕組みがあって、pandoc の ast を操作するためのインターフェースを提供している。その仕組みを使って mermaid の変換を行う mermaid-filter を誰かが作ってくれていた。このツールをインストールして次のように pandoc を実行すると base64 でエンコードした画像を使って html に変換できた。

$ npm i -g mermaid-filter
$ pandoc mydoc.md -F mermaid-filter -f gfm -o mydoc.html
$ vi mydoc.html
<p>システム構成図</p>
<p><img src="data:image/png;base64,iVBORw0KGgoAAAANSU...EnAAAAAElFTkSuQmCC" alt="" /></p>

mermaid-cli を使うか mermaid-filter を使うかは要件や好みにもよるけど、すでにツールがあるので組み合わせれば何とかできそうというところまで確認した。

コワーキングのオンラインイベント

月例のカフーツさんのオンラインイベントに参加した。先月の所感はここ 。いとうさんが岩手県普代村のコワーキングスペースに行ってきてそのお話しから始まった。私はまだ岩手県に行ったことすらないんやけど、めっちゃ田舎の、断崖絶壁の眺めのよい高台にある国民宿舎にコワーキングスペースがあるらしい。

研修の講師として、いとうさんは呼ばれてワークショップをしたらしい。参加者が付箋に課題を書き出してグループワークするといった作業に不慣れで、グループ内で話しはしているものの、あまり付箋に書いてくれなかったとかぼやいていた。地域おこし協力隊 として19歳の隊員が参加者にいたらしい。19歳で地域おこし協力隊になれるの？といとうさんが驚いていた。どうやら年齢は自治体の募集要項次第らしく、たまたま普代村の要項が18歳以上で自治体もまさかそんな若い人がくるとは思ってなかったと19歳の隊員が活躍していたという。若いから頭の回転も速いし活発でワークショップもてきぱきとこなしていたらしい。

先月のお仕事探しでマネージャー実績のない私を雇う会社はほぼないという現実に直面した。いまのお仕事を終えた後で、地域おこし協力隊の要件を私が満たすなら課題管理を実践する場として行ってみてもいいかもしれないなと話しを聞いていて少し思った。ソフトウェア開発に特化した課題管理しかできないというスコープの狭さが私のスキルの欠点でもある。仮に地域おこし協力隊としてなにかに役立てられるなら、そのスコープをさらに広げられる可能性も出てくる。

それから次の記事の話題に移っていった。Nomad List というデジタルノマド向けポータル兼 sns のようなサイトを紹介してくれた。

試しに kobe のスコアをみてみる。現時点のランキングは1182位と低い。日本はこの2年ほどコロナ禍で鎖国していたからノマドを受け入れてないのでどの都市もランキングは下がっているらしい。ざっとみてスコアがよくないのは次の項目。神戸に住んでいる私の感覚とも合致しているのでこのスコアは一定の信頼ができると思う。神戸の大半のお店は21時までには閉まるし、スタートアップ企業なんか数えるほどしかいない。とはいえ、全体としてはスコアは良好だし世界に誇れる都市の1つとしてデジタルノマドを受け入れる器はあると思う。

  • Cost
  • Vulnerability to climate change
  • English speaking
  • Nightlife
  • Free WiFi in city
  • Startup Score

あと 徳島県美馬市脇町 の町興しのようなコワーキングやデジタルノマド向けの取り組みの話しがあって関心をもって聞いていた。徳島県なら実家から近い。こんな場所あったんやと聞いていた。このサイトで紹介されているのどけやさんというゲストハウスはいつ行っても外国人がいるといとうさんが話されていた。そう言われると本当なんやろか？と確かめに行きたくなる。たぶん実家から車で1時間もあれば行けそうな気がする。

課題の洗い出し

#issue tracking system  #management 

20時に寝て0時に起きて、3時に起きて6時に起きた。春先のような、なぜかたくさん眠れる状態になった。

ソースコードを読むマネージャー

アリエルをやめてから複数の組織で働いてきたけれど、以降ソースコードを読むマネージャーを1人もみたことがない。アリエルなんか cto が日々の開発のソースコードを読んでいたぐらいなのに。もしかしたらテックリードというマネジメントはしないが、開発のリーダー役のポジションができたせいかもしれない。そしてエンジニアリングマネージャーがソースコードを読んでいるのも見たことがない。いま私はプロダクト開発のマネージャーとしてお手伝いしているわけだけど、毎日変わるソースコードを読みながら、私が懸念に思ったコードについて issue 登録したり、技術的な課題であれば改善提案したりしている。もし開発リソースが足りそうになければ、私も開発に参戦しようと虎視眈々と狙っているのもある。

まだ初期開発フェーズなので粗いところが多々あるから読みがいがある (提案しやすい) というのもあるかもしれない。ソースコードも読めない (読まない) マネージャーが開発の進捗を正しく検査できると私は考えていない。その姿勢でプロジェクトマネジメントがどのように進捗して、どのような結果になるのか、これから私が実践して自分なりの考えをまとめたい。

久しぶりに go のテストコードを書いた

#go  #testing 

0時に寝て3時と5時に起きて7時に起きた。まぁまぁ眠れたと思う。

go のテストコードのサンプル

先日 Logger のコード を書いて、テストコードのサンプルも書いてみた。いま微妙に TableDrivenTests が書けてないので参照実装として Logger のデータ駆動テストを書いてチームに共有した。私も future さんのテストのチュートリアル記事を読みながら復習してた。

昔、私が go 開発していた頃にはなかった新機能としてサブテストを並列に実行できる。

uuid ライブラリの歴史的経緯

たまたま Version 1 UUID を返す NewUUID のコードをみていて、err を返しているけど、現時点の実装では err が返ることはなく、これは歴史的経緯でシグネチャを変える方が影響が大きいだろうという意図でそうなっているらしい。

ここでは New を使えとも書いてあるけれど、これはエラーが発生したときに panic が発生するのでこれはこれでいいんやろか？という疑問も出てくる。

ftx 事件

#cryptocurrency  #economy  #web3 

眠くて19時には帰ってきて、20時ぐらいには寝て、夜に何度か起きても寝て、9時まで寝ていた。疲労過多でなんもやる気しない。

ftx 破産事件

金曜日ぐらいから大きな事件のようにタイムラインで話題になっていたので経済や金融の勉強の1つとして事件の成り行きを調べていた。いくつかニュース記事を読んだ。直近の数日間の時系列をまとめたものが次の記事になる。

過去の経緯や人間関係がわりと複雑らしいので時間がない人は次のフィクションを読んで雰囲気を理解するとよさそう。あくまでフィクション。

twitter のタイムラインでもいろいろみつかる。数億円もの暗号資産をすべて ftx に置いていて資産を失った人。

今後の暗号資産や web3 界隈の資金繰りを心配する人。

破産申請された内容から負債総額は100億ドルから500億ドル (1.4超円から7超円) の間とされていて、リーマンショックの負債総額は約6,000億ドル（約64兆円）だったことから規模はその10分の1ぐらい。また取引所にある顧客資産を流用していたことが発覚していることから、これはポンジ・スキームに近いものらしく、会社ぐるみで不正をしていたエンロンショックに近い詐欺事件として当局の調査もこれから行われていくらしい。今後、不正の手口なども明らかになっていくのだろうから経営や財務の勉強材料にする。

現時点で私が ftx 破産事件から学んだことはこれら。どのぐらい経済の影響を与えるのか、まだよくわからないのでしばらく注視していく。

  • 姉妹会社であるアラメダリサーチ社の資産の大半が ftx トレーディング社が発行するトークン (ftx token) で構成 (25%) されていた
    • 他の資産も流動性の低いトークンで構成されていて売却時のコストを考慮すると資産の評価は適切ではない懸念が指摘された暴露記事が騒動の発端
    • 現金及び現金等価物は20億ドルしかなかった
  • 取引所が発行するトークンを、取引所同士で大量に持ち合いして価値の下支えをしている
    • こういったトークンは流動性がないことから、大量保有者が売ると大幅に価値が下落する
    • ftx トレーディング社は自分たちで発行したトークンでグループ企業の資産価値を過剰に高くみせていた
  • ftx トレーディング社の社長 (Sam Bankman-Fried) は経理システムにバックドアを作っていて顧客資産を流用していた
    • 破産申請の前夜にそのバックドアが使われて100億ドルの顧客資金が社長の投資会社に移され、そのうちの10億ドルから20億ドルの行方が分からなくなっている
      • 誰が何のためにバックドアを利用して資金移動したのかはまだ調査中
  • 1つの取引所にすべての暗号資産を置かないこと
  • 取引所に暗号資産をずっと置きっぱなしにしないこと
  • 暗号資産はまったく安全ではないこと
    • 取引所という脆弱性、普通に盗難されるし、不正されるし、破産したら資産を失う

go の nil を学び直し

#life  #book 

3時半から起きていたせいか夕方に眠くなって19時過ぎから23時まで寝て、それからまたオフィス行って4時ぐらいまで作業してから戻って寝て8時半に起きた。生活がめちゃくちゃ。

ストレッチ

今日の開脚幅は開始前154cmで、ストレッチ後158cmだった。生活が不規則になって体力的にバテているのもあって右股関節、右腰の張りが強かった。さらに加えてふくらはぎ、腕と全身的にいつもより張りがあるように感じた。トレーナーさんが言うには座っている時間がいつもの週より多かったならその分だけ筋肉が固まってしまう可能性はあるとのこと。先週の東京出張から帰ってきて、リモート環境の構築、macbook 環境でメモをとった内容の見直し、リモートワークでマネージャー業をやるための準備や足りない知識の習得とか、さらに2つの社外イベントにも参加していたので普段の週よりも長い時間を机に向かって作業していたのは正しい。新しいお仕事を受けると一時的に仕事量の負荷が増える。それ自体は悪いことではないけれど、2-3ヶ月は余裕のない生活になりそうな気がする。毎週ストレッチがあるとそういった過労の疲労軽減に役立ってくれているので助かっている。

オンライン読書会

ずっと参加しようと思いつつ、都合があわなくて参加できていなかった 第4回『Go言語による分散サービス』オンライン読書会 に4回目にして初参加した。7.4 発見されたサービスにリクエストし、ログをレプリケーションする (130ページ) から 8.2.3 有限ステートマシーン (163ページ) まで読んだ。途中からなので過去の経緯はわからないものの、柴田さんが詳しく解説してくれるのでまったくついていけないということはならなかった。出てくるサンプルコードのスニペットからでも学ぶことは多々ある。effective java 読書会に参加してた人だと柴田さんに覚えていてもらっていて嬉しかった。おそらく参加者の記録を自前で管理されているようにみえた。

go でインターフェースを実装しているかを確認するイディオムとして次のような宣言がある。nil を任意の struct のポインタにキャストするのを試す。変数は _ を宣言しているので実際にはこのコードはなにも定義しない。

var _ mypkg.MyInterface = (*MyImplements)(nil)

なぜこんなことができるのかは nil は nil という記事で解説されている。interface 型は型への参照と値への参照を属性にもつオブジェクトであり、そのゼロ値は nil である。interface 型の nil は型への参照をもっているから nil をキャストするといったコードを書ける。python や java のような言語で nil に相当する None や null といった primitive はキャストするといった概念はない。事実上のシングルトンと言ってよいはず。一方で go の nil は原則として型への参照 nil 且つ、値への参照も nil なものではあるが、interface 型のゼロ値を表すため、この例で言えば、型への参照として mypkg.MyInterface 且つ、値への参照が nil のオブジェクトを生成できる。シングルトンではない。つまり (*MyImplements)(nil) != nil となる。go の nil は他言語からみて特殊ということを知ってはいたんだけど、読書会に出てそのことを確認するサンプルコードをみつけたことで私の学び直しになった。感謝。

ソースコードはここに置いた。

ログおじさん

#infrastructure  #mermaid  #go  #logging 

23時に寝て3時半に起きて眠れそうになかったからそのまま5時からオフィスで作業してた。

システム構成の検討

コンサルタントから顧客要件のヒアリングを行い、プロダクトを提供するインフラのシステム概要を mermaid で書いた。オンプレとクラウド環境のそれぞれを同じコンテナアプリケーションで動かすための構成を検討した。クラウド環境の一例として aws の構成を考えていて、https と http のプロトコル変換のようなことをするには api gateway を経由しないといけないと考えていたら、alb に証明書を設定して api gateway なくてもいけるとはらさんに教えてもらった。昔からできたそうで、なぜか私が長い間ずっと勘違いしていた。また時間があるときに自分でもやってみようと思う。

Logger の再実装

プロダクトのコアな部分の実装は私がみた方がよいだろうと考えていて、そのうちの1つ Logger の設計がよくなかったので私が作り直した。といっても cybozu-go/log を使った薄いラッパーを設けただけ。チームメンバーからどこでエラーが起きているか追跡しにくいという声があったのでログ出力したところのソースコードの情報を出力しようと考えた。ググればたくさん出てくる。スタックフレームにアクセスする標準パッケージとして runtime を使うとできる。runtime.Caller と runtime.Callers は似て非なる関数のようでファイル名と行番号だけでよければ Caller を使った方がシンプルになると思う。関数名もほしかったら Callers を使ったスタックフレーム自体から取得する必要がある。

func Trace(skip int) (file string, funcName string) {
  pc := make([]uintptr, 15)
  n := runtime.Callers(skip, pc)
  frames := runtime.CallersFrames(pc[:n])
  frame, _ := frames.Next()
  _file := frame.File[strings.Index(frame.File, sourceRepositoryPath)+8:]
  file = fmt.Sprintf("%s:%d", _file, frame.Line)
  return file, frame.Function
}

この情報を cybozu-go/log の map に追加するようなログ関数を提供するようにした。cybozu-go/log は標準の log パッケージに足りないところだけを追加していて、そのシンプルさと拡張性の高さを私は気に入ってよく使っている。私が気に入っているのでもっと有名になってほしい。

前のお手伝いでもログ基盤を含めて Logger を作っていて、またいまも Logger を作り直していて、気付いたら私は Logger やログ出力に一家言あるような、ログおじさんになりつつある。

よい go コードを書くためのガイド

#go  #programming 

2時に寝て6時に起きて2度寝したら8時だった。生活リズムがおかしい。

Go Code Review Comments の学び直し

私の周りでは Go Code Review Comments というドキュメントが引用されているのをよくみかける。google 社での go のコードレビューのときによくある指摘をまとめたものである。pr/mr を送る前にこれぐらいは自分でチェックしようといったガイドになる。私自身、過去に何度か読んでいるとは思うが、久しぶりに go 開発をするので学び直しも兼ねて読み直すことにした。うちのチームは java 開発者が多いせいか、go のコードで go っぽくないところがいくつか散見されていた。チームメンバーにも共有する意図も含めて2回にわけて勉強会をしてみんなで読み合わせをする。その下調べとして既存のコードでこのガイドに準拠していないコードがあればそれはわかりやすい事例になるので探したりしていた。

軽量のコンテナオーケストレーションツールは存在しない

#docker  #kubernetes  #event 

0時に寝て6時に起きた。冷蔵庫に飲みものなくて不安。

docker の swarm mode

昨日から docker の swarm mode について調べていた。

オンプレにコンテナのアプリケーションをデプロイするにあたり、軽量のコンテナオーケストレーションツールはないかと調べ始めた。Kubernetes vs Docker Swarm vs Nomad - the orchestrator wars continue? を記事を読むと、軽量のオーケストレーションツールと言えるのは swarm mode か Nomad ぐらいしかない。docker に付属しているならまずはそれを調べるべきだろうと調査した。そして swarm mode の採用は見送った。現時点でこの機能が廃止されるというアナウンスはないが、あまり保守されておらず、docker 社も積極的に推進していない。近い将来、機能が廃止される可能性が高いと私は判断した。

docker のドキュメントをみながら3台の ec2 インスタンスでクラスターを構築してみて簡単であることは間違いない。コマンド2つで swarm クラスターを構築できる。一通り触ってみて数台のマシンを管理する軽量のコンテナオーケストレーションツールとしては十分だと私は思うけれど、残念ながらこのツールが求められる業務やビジネスは少ないのだろうと思う。みんな k8s に持ってかれたという感じかな。調べていて読んだ記事など。

hannali dao 雑談

Hannali DAO #02 に参加した。

最初は dao とは何かをみんなで雑談してた。私はお仕事しながら軽く聞いているつもりだったのが、議論に口出しして熱中してた。技術的に私が理解できないことが出てくると、私の認識が誤っていたり新しい気付きがあったりする可能性があるので、ついつい詳細を聞いてみたくなる。hannali dao でトークンをばら撒く戦略をみんなで考えていて dao の宣伝をしたら貢献の1つとみなしてトークンをもらえる。私は twitter でいくつか hannali dao のツィートをしていて、1ツィートが 300 PROG とかで、合計で 1250 PROG のトークンをもらった。PROG というのは hannali dao でのみ使えるトークンね。

その後、ウォレットに名前を付けられる ENS (Ethereum Name Service) というサービスがあるのを教えてもらった。ちょうどいくらか ethereum をもってたので metamask に送金して、metamask で ens の登録 (購入) をやってみた。初めて ethereum を使ってサービスの支払いをやってみた。これで私も web3 を完全に理解したよ。ens で名前を登録 (購入) するのに $22.58 、ドメイン名みたいなものでサブドメインも登録できる。サブドメインを付けるのに $2.96 かかり、その ens を metamask に紐付けるのに $7.49 がかかった。metamask に紐付けると https://etherscan.io/ などで検索したときにウォレットのアドレスではなく、ens で購入した名前が表示されるようになる。トランザクションの履歴に名前が付いてそれが誰なのかが他人にもわかってしまうことがどういった影響を及ぼすのか、プライバシー云々の他に私はまだわかっていない。web3 なので購入した名前は一般公開されているものだけど、その名前は知り合いにしかまだ教えていない。暗号資産のウォレットに名前を付けることの意味や体験などをこれから経験してみる。