投稿者「krote」のアーカイブ

手持ちNFTの現状整理(CNP関係)

2021年末から仮想通貨市場に対してちょっかいを掛け始め、2022年はNFT市場にも参加しました。
ただ、お祭り相場に踊らされたり遊びでミントしたりと、ちゃんとした資産としての管理をこれまでやってこなかったので、正直、手持ちがどういう状況なのか?に関してはぼんやりとしか認識していないのが現状です。

これではだめだろうということで、一旦整理を行います

CyrptoNinjaPartners

https://opensea.io/ja/collection/cryptoninjapartners

TimeEvent TypeTitle個数価格(ETH)手数料(ETH)合計金額(ETH)合計金額(JPY)
2022/10/21 22:46:59BuyLuna-Pipe #235322.12000.004832.1248408,939
2022/6/18 5:45:44BuyOrochi-Gold(scroll) #166620.48000.007580.487669,004
2022/6/18 5:25:03BuyMitama-Transparent(scroll) #078630.48000.005650.485768,731
2022/5/30 10:29:21BuyLeelee-Scroll #199590.30000.005340.305369,824
2022/5/29 18:17:40BuyLeelee-Polar bear(dango) #221400.28000.002590.282661,968
2022/5/15 10:19:58BuyNarukami-Light brown(pipe) #205350.00480.006550.01142,947

合計取得金額(JPY): 681,413
平均取得単価(JPY):113,568.8333

現在フロア単価(ETH):2.7
現在フロア単価(JPY):452,033.919
推定保有金額:2,712,203.514

収支:2,030,790.514

CNPは初期Mintには参戦したのですが、そもそもどうして良いのかもわからず右往左往して買えず。Openseaにてすべて2次流通を拾っています。

購入したタイミングと金額を大体ですがプロットしてみました。

タイミングとしてはセール直後だったりしますが、見てわかる通り、すべからくそのタイミングでの高値づかみをしています。
特に、10月のルナ公開タイミングでは大きく平均フロアから逸脱した価格で手に入れています。。。
これは、平均がCNP全体のフロアであって、ルナのフロアではないことも一因ですが、高値づかみには違いないですね。

実際のところは、これにヤーマの形代とかバーニンとかしているのでもうちょっと費用がかかる計算ですが、それらを合わせても200万近くプラスになっていそうです。

この糞下手くそなトレードでも利益が出ているのは、ひとえに持ち続けていることと、しっかりと価格が上昇していってくれているからなので、頭が上がらないですね。

ファウンダーのRoadさんが積極的にビジネス展開をされているので、価格が上がるかどうかは市場次第なところはありますが、イベント毎には事欠かなそう。
特に、先日発表されたSoftbankとの協業はどういう形になっていくのかは楽しみです

Bucket、NFT発のIP「CNP」を活用したデジタルマーケティング支援についてソフトバンクと基本合意を締結
https://prtimes.jp/main/html/rd/p/000000057.000012092.html

ただ、CNPは価格が上がっていておいそれと買いましすることが難しくなっているのも現状。
しかし、現状はさらなる値上がりの途中段階とも見れなくはなく、私が買うと価格が下がるという市場原理(?)と言うか呪いが発動しそうで怖くてしょうがないです。

一方で、売り時は悩みそう。
基本的にNFTを購入し続けていて、出費しかないお財布事情なので、どこかで資金が尽きる前に調整売をかけないといけなくなるかもしれない。

このあたり、株であれば持ち続けることで配当を得られるので、同様の仕組みがNFTでもセキュリティをちゃんと担保してくれればいいですね。
まだ、ちょっとレンディングに預けるのはためらわれるところ。ぐぬう

CNP Jobs

https://opensea.io/ja/collection/cnp-jobs

TimeEvent TypeTitle個数価格(ETH)手数料(ETH)合計金額(ETH)合計金額(JPY)
2022/10/16 12:29:35BurnMintNarukami-NEET-Black eagle #117730.00000.001600.0016308.8456
2022/7/17 9:17:49MintOrochi-Teacher-Glow stick #108702.00000.00200.003120.0051875.870208

合計取得金額(JPY):1184.715808
平均取得単価(JPY):592.357904

現在フロア単価(ETH):0.425
現在フロア単価(JPY):70,618.20825
推定保有金額:141,236.42

収支:140,644.06

CNP Jobsは初期MintのALをいただけたので費用はほぼかかっていませんので当然黒字です。単価よりもむしろ手数料のほうがかかってますね。。。

CNP Jobs はMint時に応援的に購入したものの、ほぼほぼ放置状態です。

実際問題、それほど情報を追いかけていないということもありますが、何かしらの今後の展開があまり想像できていないので、CNPと比較すると価格的に買えないこともないですが、この先の値動きがわかりません。

11/11にファウンダーであるうじゅうなさんが本を出版されました

そのあたりで、値動きがあるかな?と見てましたが、一瞬上がって同じところにまで戻ってきています。

とは言え、初期で頂いたものなので、積極的に売る理由はあまりないかな?というところが正直なところです。

KunoichiGakuen-Origin

TimeEvent TypeTitle個数価格(ETH)手数料(ETH)合計金額(ETH)合計金額(JPY)
2022/12/13 22:01:11MintKunoichiGakuen#297310.00000.30000.00289
2022/12/13 21:05:23MintKunoichiGakuen#10882.00000.06000.00213

合計取得金額(JPY):60,651.90206
平均取得単価(JPY):5,054.325172

現在フロア単価(ETH):0.027
現在フロア単価(JPY):4486.33323
推定保有金額:53,836.00

収支:-6,815.90

ブロックチェーンゲームを作るプロジェクトで販売されたNFTです。
ALを頂いてミントしたものの、そもそものミント価格が0.03ETHということもあって、残念ながら現状は赤字です。
格安ミントに慣れていたので、ミント時に思った以上に金額が高くてびっくりした事を覚えています。

とは言っても、単価で考えれば数百円。
そもそもまだゲーム出ていないということもあるので、まだ慌てる段階でもないのかな、と。

ゲームがちゃんと出て、それが面白いかどうか?ですかね。
デザイナーの方が体調を崩されたりしてリビールが遅れていましたが、無事にそちらも完了しています。
あとはゲームそのものですね。

予定では2023年の1Qには!ってところですが、このあたりは長い目で見守ったほうが良い気もしています

その他

忍者関連はその他にメタバッチとかお遊びNFTがあったりしますが、いずれも格安ミントなので一旦ここでは除外。

思った以上に整理するのに時間かかっているので続きはまた今度。。。

成長と成功

いつも楽しく聞かせていただいている、Voicyの「10分で決算が分かるラジオ」。
決算に関しての解説ももちろんのこと、雑談回がかなりお気に入りです。
一昨日の放送が、考えさせられました

【雑談回】成長より成功する意思が改めて大切だと思った話
https://voicy.jp/channel/1358/443994

是非聞いてみてください。

会社でも評価を考える時に、よく「この一年なり半年で何ができるようになったのか?」という視点で見ることが多いです。
もちろん、成果として「何を成し遂げたのか?」という視点は大事なのですが、半年なり一年というスパンで複数人で行っているプロジェクトの中で個人がなし得る成果は、誰もが高いとは限らない

そんなことで成長に目線が行ってしまったようにも感じます。

でも結局のところ、振り返ってみた時に「結局ここで何も成し遂げてないな」感が出てしまうんですよね。

確かに、色々な経験をして、幾ばくかの技術なりスキルなりを身に着けた。
でも、だから何かをやったかといえばそうではない。

逆に言うと、スキルを身に着けたわけでもなく成功を意識することで何かを成し遂げる人もいるわけです。
そして、結果から言うとその過程で成長もするんですよね。

成功するために成長したのか。
それとも成長した結果たまたま成功したのか

すごい当たり前の話なはずなのに、なんでそれをやるのか?という事を漠然とさせたまま日々を送っているなぁと、すごい思わされた。

じゃぁ、どうするんだ?に関しては明確なものはないけれど、成果を出すために動くというごくごく当たり前のことをもう一度しっかりと考えるべき時なんだろうな、と思った。

おしまい。

魅惑のスムージー生活

ふるさと納税で何を頼もうかな?とあれこれ見ていたのですが、あまりいいものがない。そんな中、見つけたのがこちら、ドクタースムージー

https://www.satofull.jp/products/detail.php?product_id=3064802

スムージーに対する偏見

スムージーって皆さんどんなイメージをお持ちですか?

なんとなく、美容健康に気を使っていてヨガとかやっている20代女性が、朝の優雅な朝食にこんがりと焼けたトーストと一緒に並んでいるようなイメージですね。間違いない

ショッピングモールなどにジューススタンドみたいなところでスムージーが売っていたりしますが、結構いいお値段するんですよね。

私自身、健康に気を使っているというほどではないですが、野菜や果物、ヨーグルトなどは積極的に取るようにしているので、もはや健康志向といっても過言ではないのではないかと日々思っています。

というわけで、頼んでいたドクタースムージーが届いたので早速作ってみました。
これで私も20代健康意識系女子の一員として輝けるハズ

レシピ

まずは付属レシピの最初に載っていたものを試す

  • りんご
  • 人参
  • 生姜
  • はちみつ
  • レモン汁

それぞれをセットします。

容器自体がそれほど大きくないので、りんごや人参は予めそれなりに小さくしておいたほうが分量入ります。

そして真空にしてミキシング!

無事にスムージーっぽく(?)なりました。

スムージーづくりですが、思っていた以上に音が大きいので、子供が寝静まってからやるのは若干ためらわれます。
また、ちょっと焦げたような匂いがします。
どこかでモーターがいかれてしまわないかが若干不安になる匂いですね。
あまり長時間は連続使用は避けたほうが良さそう

いくつか試してみて思ったこと

先に掲載したレシピ以外にもバナナやほうれん草などいくつか試してみました。
バナナとりんごが入ると、見た目的に緑黄色野菜が入って緑色だったとしても味としてはバナナ・りんご味が強くなるので気にせずに野菜を取れそう。

ただ、入れられる野菜の量がそもそも多くは無いので、これを持って野菜バッチリ!とはいかないでしょう。

一回で作ることができる分量としては、コップ1~2杯くらい。
付属の保存容器で一度に飲むことも十分できる量です。

小さいりんごを半分ずつ使って2回連続でスムージーを制作。
一つはそのまま飲んで残りは保存容器で別タイミングで飲む、みたいな運用をとりあえずしてみています。

作ってみて思うのは、結局のところ主成分としてはりんごやバナナと言ったもので、野菜要素はそれほど多くは入れられないのかな?というところですね。
変に砂糖たっぷりのジュースを飲むよりは良いとは思うので、ちょっとした手作りジュースと言うレベル感で楽しむのが良さそうと感じました。

まぁ、あまり健康とかに対して、これだけでOK!なんてものは無いということですね。
当たり前といえば当たり前ですが。

Amazon初売り物色

Amazonの初売り、なにか無いかなーって見ていて

https://amzn.to/3Im7k5M

骨伝導イヤホン!!

普段ランニングをしている最中はPodcastを聞いたり、Voicyを聞いたりしているのですが、長時間走っているとどうしても耳汗をかいてしまって不快です。

汗を書いてくると、イヤホンが汗で滑って落ちそうになるし、耳の中はベタベタするし。

更に、基本的には歩道を走って入るものの車道を走る機会がないわけでもない。そんな時に耳がふさがっているのは正直言って危ないですね。

これまで骨伝導イヤホンというものは使用したことはないのですが、これを機会に、試してみようと思ってポチってしまいました。

届くのが楽しみだー!

あけましておめでとうございます

タイトルのとおりですね。
あけましておめでとうございます。

本来であれば、2022年の振り返りをしたかったところなのですが、なんだかんだサボってしまっているうちに年が明けてしまいました。
皆さんは年末年始どうお過ごしでしたでしょうか

実家での過ごし方

私は年末年始は毎年、愛知の実家に帰って母に孫を見せるというよくありがちな親孝行をしています。
今年は、年末年始もランニングしようと思って走る準備はしていたものの、初詣をしたり

子供たちと凧揚げをしたりと、家族サービスに終始していました。

実家に帰ると、動かずとも、これでもか!というくらいご飯が出てくるのでどうしても体重が増えてしまいます。
そして、夜も早く寝ることになり、睡眠時間が普段の1.5倍位伸びてます
そういう意味では、よく食べ、よく寝るという普段はおざなりにしている本来の健康的生活を営めているということで、いい休日を過ごすことができたと言えるでしょう。

2023年抱負

新年ということで、新年の抱負をぶちあげることができればカッコいいところです。

昨年からランニングに本格的に取り組み始めています。
こちらに関しては、すでにいくつかの大会にエントリーしていることもあり、長く続けていきたい趣味として確立しつつあると思います。
一方で、1月から仕事の現場が客先常駐となるので、平日のトレーニングが厳しくなります。この状況下でどういう形で走る時間を作っていくのか。
いくつかのチャレンジが待っていそうです。

仕事に関しては、新しい現場での新しいチャレンジとなります。
新しいことに取り組むということは刺激になって本来良いこと。結果としていい結果を残すことができるかは自分の動き次第なところではあるのでその点に関してはよく考えて動いて行きたい。

一方で、今の仕事の形というものをこの先もずっと続けていくことに関しては疑問を感じているのも事実。
何かしら、次の柱を考えていかなければ行けないと考えています。
昨年、NFTやDe-Fiを含めたWeb3周りの技術に関してもいくつか手を出した。
Pythonを中心としたAI周り。
Rustを用いたバックエンドの潮流などなど、少しずつ触って入るものの身になったり何かを作り上げたりということはできていません。

今年はそれらに対して何かしらの答えを出すことができないだろうか?と考えています。
将来的な話で考えるのであれば、先に上げた3本はどれも可能性が広がっていると考えています。

どれも単独なものではなく、関係しあっている領域もあり、また新しい技術も出てくる可能性があるでしょう。

アウトプット量を増やしていく

どれにも共通することとしては、アウトプットの量を増やしていく必要性です。

ほんと、いい加減な性格なのでどうしても面倒くさがって毎日更新とかは流石に現実的ではないかな?と思いますが、しっかりアウトプットをしていく。
そして、しっかりアウトプットするためにもしっかりとしたインプットをしていくことを心がけていく必要があります。

では、これまでなんでそれができてこなかったのか?ということなんですが、結局は時間の使い方なんでしょうね。

何に自分がどれくらい時間を使っているのか

その時間をそこに費やすということは、自分自身としてどうなのか?

しっかりと考えて行動していきたいところです。

力を抜くところは抜き、力を入れるところは入れていく。
もういい加減、いい大人なんだからしっかりと生きていかないと。

そんなこんなで、今年一年、改めてよろしくお願いします

passkeyに関しての整理

先日、Chroniumチームが passkey に関してのアナウンスを出しました

Introducing passkeys in Chrome

Appleはと言うと、昨年のうちにpasskeyに対しての対応を表明しており、この分野に関して大きく進展し始める機運が出てきました。

ちょうど、来年からID管理周りのシステムにかかわる可能性が出てきたこともあって、自分の知識の整理も兼ねてまとめておこうと。

ID/パスワードが抱える問題

ID/パスワードが抱える問題を考える上で、そもそものID/パスワードに対する考え方と、同システムとして実装するのかの2つを考える必要があります。

ID/パスワードをすることで何を実現するのか?と言うと、ログインしようとしている人間がIDの所有者。つまり本人であることの認証のためです。

この認証するための技術として今主流なのは多要素認証という手法で、これは下記の要素のうち2つ以上の異なる認証要素を用いて認証する方法となります

  • 知識情報:パスワード、秘密の質問
  • 所持情報:セキュリティーキー、キーデバイス、Authenticator
  • 生体情報:指紋情報、顔、虹彩、静脈など

Googleなどが提供するAuthenticatorによるワンタイムパスワードであれば所持になるものの、メールなどで届く場合は、メールの情報を知識として持っているということで知識になるのか?など、ちょっと気になるところはありますが、これらの組み合わせでセキュリティを担保していることになります。

ここで所持情報にあるようなデバイス。つまりはスマホのようなものを考えた場合、スマホのアンロックに生体情報を用いれば、その状態は所持情報と生体情報を兼ね備えた状態と言えます。

passkeyはこの仕組を利用して、認証されたデバイスによる生体情報認証を行うことで、一つの操作で多要素認証を実現するものです

passkey による認証

パスキーの認証の流れとしては下記の図のような形となる

まず最初にパスキーの登録行為。生成行為が開始されると、ローカルでの生体認証などを利用した情報を元に公開鍵ペアが作成される。

秘密鍵はデバイス側で管理され、サーバー側に公開鍵を送る形。

パスキーを使ったログイン時には、まずローカルで生体認証などを用いた認証が走り、それを経て秘密鍵を用いた署名を生成。サーバー側で検証され認証される。

このパスキーは、サイト毎に作成されるため、フィッシングサイトのように異なるサイトでは本物のサイトで利用していた認証情報が使われることがない。
つまりは、仕組みとしてフィッシングを防止することができる

また、生体情報を用いた認証はデバイスのローカルで行われるため、指紋情報などの生体情報がネットワークに流れることがない。

課題

この仕組の課題は、デバイスに過度に依存してしまう点にある。

認証を行った情報がローカルに保存されることになるので、例えばそれらデバイスが物理的に壊れてしまったりすると、対象のサイトに対してログインができなくなってしまう。

その点の解決策としては、デバイス間でパスキーを同期させるという案になるのだが、それって結局のところ認証情報をコピーしているわけなので若干モヤっとする。

モヤっとするのだが、現実問題としてスマホを落としたり水没させてしまったりと、割りとそういう自体は起こりうるもので、それに対しての対応も考えて置かなければならないのも事実。
妥当なところなんだろう。

現状の実装としては、AppleはApple。GoogleはGoogleデバイス間での同期にとどまってしまう点も使いづらさを感じる点になると思う。

PCでパスキーを使用する際に、パスキーの認証方式として認証済みデバイスに対してQRコードを読み込ませるという方法も用意されているが、面倒臭さは拭えない。

実装

OSS の passkey 実装としては hanko がある

https://www.hanko.io/

まさかのハンコである。
手軽にローカルで実装を確認できるサンプルもあるので動かしてみる。Githubはこちら

https://github.com/teamhanko/hanko

ReadMeに動かし方が書いてあるが、コマンド一発で起動することができる

docker-compose -f deploy/docker-compose/quickstart.yaml -p "hanko-quickstart" up --build

localhostの8888ポートへアクセスするとExample Appのログイン画面へ行く事ができる

テストサイトなので、メールアドレスは何でもいい。

Sign Upを押すと、メールに飛んできたパスコードの入力画面に行く

メールは実際に入力したアドレスに飛ぶのではなく、このExampleに組み込まれたメールサーバーへ届けられる
http://localhost:8080 へアクセスする

入力すると、パスキーをセットアップするかを確認する

ここでパスキーをセットアップすることでログイン時に用いることができるようになる。。。。はず。

というのも、私のPCでは正常に顔認証が行われないのでこの部分は試すことができなかった。

実際のところ、hankoはまだ開発中でベータという扱いで、現在のバージョンはv0.3.1。順調に月1くらいのペースでリリースがされているので今後の動向には注意しておきたい。

目標はサブ3.5 ? それともサブスリー?

先日のアクアラインマラソンで惜しくもサブフォーを逃してしまったわけですが、なんとかフルマラソンを完走することはできたということで、次なる目標を考えたくなります。

タイムアタック?

前回、かなりの時間を歩いてしまったにも関わらず4時間5分とかなので、ちゃんと走りきれればサブフォーは達成できそう。

という訳で思いはサブ3.5。更にはサブスリーとなるわけですが、単純なイメージとして考えると

サブ3.5 = 1km/約5分
サブ3 = 1km/約4分12秒

うーん。4分12秒か・・・

先日2時間走った際のペースが4分52秒。これで24.7km走っているのでこれからしっかりトレーニングを積んでいけば、3.5はいけないだろうか?というところ。

ただ、サブ3はもうひと工夫が必要そうに感じる。
もう、単純にスピードが足りない領域だ。

とは言っても、やることといえばスピードRUNとロングRUNの繰り返しになるのではないだろうか。
それをよりハイレベルに実施していく形なんだろう。

この先の大会参加予定

年内には特に予定は入れてないけれど、年明けからは調子に乗ってエントリーを始めている。

  • 1/8 : ハイテクハーフマラソン
  • 3/26 : 佐倉マラソン
  • 4/23 : 長野マラソン

2月にまだエントリーできるな・・・なんて思わなくもないけれど、あまり無理してもね。と言うところ。

佐倉マラソンから長野マラソンまで1ヶ月しか間がないのが若干心配ではあるけど、行ってしまえとエントリーしてしまった。

夏の間はなかなか大会が少なくなってしまうけど、練習方法など見直しながら、より良い方向に持っていくことができれば、と思う。

来年は色々なところに行って走ることができればいいな。

Invalid number of parameters for “mint”. Got 1 expected 2

ジェネラティブNFTの画像生成、スマートコントラクト、Mintサイト作成をする上で、HashLipsが提供しているコードは最初の題材、テンプレートとしてよく出てくる。

HashLips
https://github.com/HashLips

エンジニアのむなかたさんが提供している、「誰でもできる!ジェネラティブNFT開発」を見ながら進めていたのですが、Mintサイトでmint実行時に表題のエラーが出てしまいました

誰でもできる!ジェネラティブNFT開発
https://crypto-code.jp/materials/create-generative-nft

エラー詳細

Error: Invalid number of parameters for "mint". Got 1 expected 2!
▼ 2 stack frames were expanded.
InvalidNumberOfParams
c:/Dev/darejene/hashlips_nft_minting_dapp/node_modules/web3-core-helpers/lib/errors.js:33
_createTxObject
c:/Dev/darejene/hashlips_nft_minting_dapp/node_modules/web3-eth-contract/lib/index.js:669
▲ 2 stack frames were expanded.
claimNFTs
c:/Dev/darejene/hashlips_nft_minting_dapp/src/App.js:132
  129 | console.log("Gas limit: ", totalGasLimit);
  130 | setFeedback(`Minting your ${CONFIG.NFT_NAME}...`);
  131 | setClaimingNft(true);
> 132 | blockchain.smartContract.methods
      | ^  133 |   .mint(mintAmount)
  134 |   .send({
  135 |     gasLimit: String(totalGasLimit),
View compiled
onClick
c:/Dev/darejene/hashlips_nft_minting_dapp/src/App.js:360
  357 |   disabled={claimingNft ? 1 : 0}
  358 |   onClick={(e) => {
  359 |     e.preventDefault();
> 360 |     claimNFTs();
      | ^  361 |     getData();
  362 |   }}
  363 | >

この手のチュートリアルでエラーの原因はチュートリアル上の工程をすっ飛ばしてしまったり、誤字脱字によるタイポなわけです。

ただ、問題なのは、言われるがままにコードを修正する形になるので、そのあたりがつけづらいという点ですね。
特に今回のように、ゼロからコードを書くのではなく、テンプレートから作る場合はそもそも書いていないコードが多いので余計に原因にたどり着きづらいことが多いです。

質問しても良いのですが、それでは理解の助けにならないので自力で解決することを考えます。

mint関数の定義

コード内容としては、Reactで書かれたフロントエンドからスマートコントラクトの呼び出し時にエラー。
エラーメッセージからは「mint」関数の引数が、コード中では “mintAmount”一つに対して2つの引数を期待していると言われています。

というわけで確認するべきはmint関数の定義です。

mint関数の呼び出しとしては

blockchain.smartContract.methods.mint(mintAmount)

という呼び出しになっています。

スマートコントラクト上のコードとしては

// public
  function mint(uint256 _mintAmount) public payable {
    uint256 supply = totalSupply();
    require(!paused);
    require(_mintAmount > 0);
    require(_mintAmount <= maxMintAmount);
    require(supply + _mintAmount <= maxSupply);

    if (msg.sender != owner()) {
      require(msg.value >= cost * _mintAmount);
    }

    for (uint256 i = 1; i <= _mintAmount; i++) {
      _safeMint(msg.sender, supply + i);
    }

と、引数を一つで定義されているので、呼び出しの仕方が問題というよりも、Mintサイトから見たスマートコントラクト上の定義では引数は2つと判断されている、ということなのでは。

という訳で、そのあたりを参照していけば良いはずですが。。。
少なくとも blockchain や smartContract をimport してはいないので、探します。
バックエンド主体で動いてきた私にはなかなか興味深いです

追っかける

blockchain 変数は App.js 内で useSelector によって値が入っています。

function App() {
  const dispatch = useDispatch();
  const blockchain = useSelector((state) => state.blockchain);

useSelectorに関してはこちらを参照

Reac初心者でも読めば必ずわかるReactのRedux講座
https://reffect.co.jp/react/react-redux-for-beginner#useSelector_Hooks

なるほど、さっぱりわからん。

わからんが、スマートコントラクトの定義っぽいところを探すと、bockchainActions.jsに

          const SmartContractObj = new Web3EthContract(
            abi,
            CONFIG.CONTRACT_ADDRESS
          );

という記述がある。

引数として渡しているabiは誰ジェネでも説明されている

ABIとは「Application Binary Interface」の略で、Webアプリからコントラクトへアクセスするために必要な設定となり、HashLipsのWebアプリではabi.jsonというファイルで管理しています

https://crypto-code.jp/chapters/create-mint-dapp/update-setting#index_0-3-0

ん。これが原因っぽい気がする

abi.jsonを見ると、HashLipsデフォルトの記述が書かれていて、更新し忘れていることがわかった。やはりこれが原因だった

という訳で、ここを正しく更新することで問題なくMintできるところまで行けた

最後に

ABIに関しては、公式に仕様が書かれていた

Contract ABI Specification
https://solidity-jp.readthedocs.io/ja/latest/abi-spec.html

とりあえず、なんとなく進め方はわかったけど、実際のところ各工程で行っている作業に対して正しく理解できている場所は少ない気がする。

数こなしていけば自然と覚えるものもあれば、調べて納得して覚えるものもある。

これなんだっけ?となる部分を少しでも減らしていければと思う。

Cloud Native Days Tokyo 2022 にオンライン参加

11/21-22と、オフラインでは有明セントラルタワー。同時にオンラインでも開催された、Cloud NativeにフォーカスしたCloud Native Days Tokyo 2022 にオンラインで参加しました。

といっても、普通に平日の日中帯なので、リモートで業務をしながら流していた形にはなりますが。(流石にMTG中はミュート)

業務中ということもあるし、セッションも同時並行で行われていたこともあるので全然見れていません。
ありがたいことにセッション動画は残されているし、一部は資料も提供されているのでのんびりと見ていきたいところです。

その中でもちょっと気になるセッションを抜粋

エンジニア育成

クラウドネイティブ関連の技術はどんどん増えていくし、新しい考え方や考慮しないといけないことは日に日に増していく一方。
それに対して、そういった業務に巡り合う機会というのは必ずしも多いとは限らず、増えていく技術量・スピードに対して実戦経験を積むスピードは間に合わない。

また、それらの役割を担うエンジニアの裾野が広がらないので、一部のリードエンジニアに集中してしまうことも、更に裾野が広がらない状況を生んでしまい負のスパイラルが起きている。

これらに関するセッションがいくつかあった

クラウドネイティブエンジニアの育成について実践していること
https://event.cloudnativedays.jp/cndt2022/talks/1540
株式会社カサレアル 伊藤さん

SIerで実践!クラウドネイティブを普及させる取り組み
https://event.cloudnativedays.jp/cndt2022/talks/1527
TDCソフト株式会社 島田さん

カサレアルの伊藤さんのセッションは途中まで聞くことはできたのだが、すごい賛同したくなるような内容だったので、見返したい。

今後、技術を学ぶ上でどういう形で向き合っていく上で、一つの参考としたい。
もちろん、正解はそれぞれの場面によって異なるとしても。

Observability

Cloud Native。特にKubernetesやMicroServiceを考える上ではObservabilityは切り離せない考えと思う。
それはわかるが、そんなにこのあたりの案件をこなした経験があるわけではないので、ぶっちゃけ「ふーん」というところではあるんだけど、いざとなったときに「何も知りません」とは、流石に言えなくなってきている昨今。

何も知りません

ということで、このあたりは言葉の意味から把握しておきたいところ

実践!OpenTelemetry と OSS を使った Observability 基盤の構築
https://event.cloudnativedays.jp/cndt2022/talks/1571
逆井さん

しきい値監視からの卒業! Prometheus による機械学習を用いた異常検知アラートの実装
https://event.cloudnativedays.jp/cndt2022/talks/1558
GMO ペパボ株式会社 高橋さん

特に逆井さんの話は途中まで聞いていて、結構気になる単語が目白押しだったので再確認しておきたい。
このあたりは、Kubernetes関連だとどうしてもPrometheusが出てくる印象だなぁ

クラウドリフト

現実問題、一番ありがちな話としては既存システムのクラウドリフトだとは思う。その中でどうしていくのかを取り上げていたいくつかセッションがあった。

なぜ貴方のモダナイゼーションは評価されないのか ~傾向と対策~
https://event.cloudnativedays.jp/cndt2022/talks/1574
株式会社NTTデータ 菅原さん

【既存アプリをコンテナ化したいのじゃが】-Kubernetesへリフトする開発者が乗り越える壁-
https://event.cloudnativedays.jp/cndt2022/talks/1565
RedHat K.K. 北山さん

どれもろくに聞くことができなかったので、見ておかないと。。。

最後に

これ以外にも気になるセッションが目白押しだったのでなかなか面白かった。実際問題、これらを活用する案件がものすごい多いのか?という話になると、所属企業の方向性やらなんやらによって大きく変わるんだろう。

ただ、このあたりの知識や技術を追いかけておくということは、エンジニアにとっては当然のことになっていくと考えているし、そう考えるとやっぱり自分はまだまだだなと、日々痛感してしまう。

だからといって腐らず、前に進むには何をしていくか。

水星ちゃんを見習って前に進むしかないのか。

NFT Startup Conference by #NMO へ参加

最近の興味関心事の一つとして、Web3やNFTに関することがあります。
私自身の現在のスタンスとして、どっぷり使っているわけではありませんが、エンジニアとしての技術的側面や、投資対象。単純にコミュニティ活動と、複数の切り口で面白い可能性があるかな、と考えています。

今回の投稿では、11/19に行われた NFT Marketing Orchestra というコミュニティが主催したカンファレンスのご紹介です

NFT Startup Conference

カンファレンス自体はオンラインで開催され、事前登録者はZoomのウェビナー。当日参加はTwitterスペースで聞くことができ、Twitterのスペースはアーカイブも残されていますので、興味がある方は是非。

NFT Startup Conference by #NMO
https://twitter.com/i/spaces/1zqKVPgnLkVJB

プログラムとしては以下の内容です

13:00 ~ 14:00 エンジニア対談 syou ✕ むなかた ✕ けいすけ
14:00 ~ 15:00 対談① わふくジェネ SOLOさん
15:00 ~ 16:00 対談② しきぶちゃん BUSONさん
16:00 ~ 17:00 対談③ CryptoNinja ikehayaさん
17:00     終了

私はというと、事前登録をしておいたのでZoomで参加しましたが、ランニングしながら聞いていたのでほとんど画面は見ていません。が、多分音声のみだったのではないかと。
セミナーじゃなくて、基本的に対談でしたしね。

それぞれの対談で思うこと、考えさせられることはありましたが、せっかくなのでエンジニア対談で思うところを。

エンジニア対談で思うこと

私自身、Solidityのコードを対価を頂く形で書いたことはなく、あくまでチュートリアルレベルなので、このお三方のような界隈で活躍されている人と比較はできないので、あくまで個人的な感想となります。

NFT。特にジェネラティブNFT関係のエンジニアリングでいうと、今回の対談の中でも出てきていますが、大きく3つの工程があります。

  • 画像生成
  • スマートコントラクト
  • Mintサイトの制作

CryptoZombieをやっているときはそれほど意識しませんでしたが、HashLipsを使うと上記3つが用意されているのでこの点はすごい認識・イメージはしやすかったです。

ただ、基本的にどれもベースとなるものは存在していて、結局のところどういう「画像を生成したいのか?」と、「どういう条件で販売したいのか」が決まれば結構なんとかなりそうな印象です。

あー、でもどこに画像を置くのかとか選択肢がいくつかあって、それらの選択肢の中から何を選んでもらうのか?とか考え始めると大変なのかな。

と言うかもっと言ってしまうと、大抵はエンジニアリングが大変というよりもコミュニケーションが大変なんでしょうね。

いずれにしても、作るものとしてのサイズ感は、凝ったことをしなければ、比較的ボイラープレートがある以上はそこまで大きくならない印象です。

チーム開発と個人開発

昨今のサービスやアプリケーションはどうしてもサイズが大きくなってしまうのでチーム開発が基本だと考えています。

チーム開発では、昔ながらのウォーターフォールで進めていったり、アジャイル的にスクラムを組んでみたりと色々な試行錯誤が繰り返されてきています。

できるエンジニアが一人で組んでしまったほうが、品質的にも安定するというのはあるのでしょうが、作るものの仕様の整理だったり業務知識。また、純粋な作業ボリュームと市場に投入したいスピード感から考えるとチーム開発になる認識です。

現在のNFTのように、比較的個人やコミュニティ手動で動いている場合は、そのWeb3的な考え方からコントラクトは共有ではなく独自が思想的にも好まれます。
そして、多くのギミックを入れられるほど資金が潤沢ではないので、ちょうど個人エンジニアで受けられるサイズ感に収まるのではないかと。

これから

ただし、多くのエンジニアがこれらの技術を習得し、ジェネレラクティブNFTの構築を行うことができたとしても、それを専業でやっていくほどのNFT発行プロジェクト量やエンジニアの需要を賄えるだけの金銭的な余裕も厳しいのでは。

そう考えると、今の私のように趣味で触っているのではなく、これだけでご飯を食べていこうとする道は結構厳しそう。

あるとすれば、自分自身がプロジェクトを立ち上げることによって、エンジニアと言うよりはファウンダーとして成り立たせるのが一番可能性としては高いかもしれない、と感じた。

実際のところ、NFTと言う単独な使い道以外にもスマートコントラクトの活用幅はこれから増えていく可能性がある。
NFTはブロックチェーンやSolidityという枠組みの中のあくまで一つの活用事例として考えて、他の分野も含めた形での目線を持っていたほうがいいかな、と考えている。

もちろん、NFTの活用方法が現在主力のPFPから大きく変わることも考えられ、その際にはNFT関連だけで充分な数のエンジニアを賄える分量が出てくるかもしれない。

いずれにしても、どうなっていくか、楽しみな分野ですね。

まー、そんなこと考えているよりも、手を動かせよって意見には頭が上がらないところではあるけれど。