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

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

コメントを残す

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

本来であれば、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/パスワードに対する考え方と、同システムとして実装するのかの２つを考える必要があります。

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

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

  • 知識情報：パスワード、秘密の質問
  • 所持情報：セキュリティーキー、キーデバイス、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。順調に月１くらいのペースでリリースがされているので今後の動向には注意しておきたい。

目標はサブ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”一つに対して２つの引数を期待していると言われています。

というわけで確認するべきは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関係のエンジニアリングでいうと、今回の対談の中でも出てきていますが、大きく３つの工程があります。

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

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

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

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

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

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

チーム開発と個人開発

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

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

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

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

これから

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

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

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

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

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

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

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

walkenで垢バン食らった件とwalk to earnに関して

コメントを残す

タイトルどおりですが、walkenという walk to earn のアプリ。
平たく言うと、歩くことで稼ぐことができるという類のアプリをしばらく使っていたのですが、チート認定されて使えなくなりました。

というわけで、経緯とその考察。更に他の walk to earn アプリに関して書いてみようと思います。

walken で垢バン食らった経緯と対応

どこでこのアプリの存在を知ったのかはうろ覚えですが、すでにいくつか walk to earn を試していたので軽い気持ちでインストールしました。

walkenでは、比較的可愛らしいキャラクターを歩くことで育てていき、育てたキャラクターをユーザー同士でバトルすることができます。

先週から、急にそれまででは考えられないような強キャラクターが毎回対戦相手として出てくるようになり、何が起きているのかさっぱり。。。

そしたら、どうやらこれはチート扱いされているという言及を頂きました

むぅ。。。って完全にタイミング的にもアクアラインマラソン走ったことがきっかけか。。。確かにその日の歩数は5万は超えている。

と言うか、walk to earn なのに、マラソンで垢BANとか。ぐぬぬ

サポートへ連絡

サポートへ連絡という話だったので、walkenのDiscordに入って確認するとメールで問い合わせろと返事が帰ってきたのでメールで問い合わせ。

言われた通り、ヘルスケアアプリとかのスクリーンショットを送った結果

見事に玉砕しました。

なんやねん

考察

例えば、フルマラソンとか極端な例ではあるんだけど、walkenの場合はAppleのヘルスケアデータへアクセスして歩数を持ってきてしまうので、ユーザ側でその情報をアプリ側に渡さないということができません。

歩数がアプリを起動している間だけカウントされるとかであればユーザー側でやりようがあると思うのですが、これはどうしようもないです。

つまり、walkenはマラソンランナーが使うべきではないアプリとなります。
なぜなら、それまで育てていたキャラクターなどが無駄になるのではっきり言って時間の無駄です。

ただ、開発者の立場で考えると、仮想通貨というお金が絡む以上、何かしらのチート対策が必要となるのはわかります。
ヘルスケアアプリでは、歩数以外にもワークアウトの実績や距離に関する情報も取れると思うので、それらを踏まえて判断する形が良いのではないかと思います。

また、これらの長距離を走る人は、大抵ワークアウト用のアプリを入れています。
私であれば、Nike Run Club ですね。
これらのアプリと連携させることができれば、チート判別の精度は増すのではないでしょうか？

walk to earn で考えると、ランニングやマラソンを趣味としている人が、その趣味を活かせると考えて始めることにもなると思うと、現在の作りは残念で仕方がありません。

その他のアプリに関して

歩数をカウントする系統では、それ以外には、SweatCoinやMiles。DQウォークがを使っています。

SweatCoin

フルマラソン前後からちょっと歩数のカウント。特にBoostの動きが怪しいと思うようになりましたが、問題なく使えています。

こちらは今のところフルマラソンに耐えられるようですね。

Miles

そもそも距離の計測が最近まともにできていません。
以前は、それなりの精度でランニングなどを記録してくれていたのですが、ここ最近はそもそもランニングしても走ったと認知してくれなくなっています。

なんだか最近、やたらと広告も多くなってきたのと、使っていてもそれほどいいMileの利用先が無いのでそろそろ削除を検討し始めてます。

BitWalk、トリマ

この2つは一時期いれていましたが、広告の閲覧が前提となっていて、アプリで定められた出金の条件を満たす前に消耗するな、と考えてすでに削除済みです。

あくまで、ついでにコインを貯めることができたらいいよね！って程度の気持ちなので、これに必死になってしまうのは本末転倒ですし。

最後に

なんというか、ものすごっく気分悪いですが、エンジニアとして似たような人を産まないようなものづくりをしていかないといけないな、と考えました。

Goerli テストネットワークでテストする準備

1件のフィードバック

以前、cryptozombies でNFTやSolidityに関してのチュートリアル的な事をしたものの、それ以来全く触っていなかったNFT周りを改めて触ってみています。

今回は、その中で開発したコントラクトをテストするテストネットワークの一つ、Goerliテストネットを使ってみた話です。

テストネットワーク

今年の９月に実施された、 Ethereum 上の　The Merge。
これ以降、それまで使えていたKiln、Ropsten、Rinkebyは廃止され、現状でテストネットワークとしてはGoerliとSepoliaが用意されている形となります。

The Merge以前の学習コンテンツやチュートリアルでは、Rinkebyなどのテストネットワークを採用されているものが多いので、注意が必要となります。

といっても、基本的な扱いが変わるわけではないので簡単に説明します。

Alchemyの登録

テストネットワークでコントラクトを動かすために必要となるGoerliETHを手に入れるために、事前にAlchemyというサービスのアカウントを作成しておきます。

Alchemy
https://www.alchemy.com/

「Get started for free」から、適当に入力をしていくことでアカウントを作成可能です。

途中で、支払い情報などを入力する項目が出てきますが、特に入力せずとも問題ありません。

faucetでGoerliETHをリクエストする

GoerliETHのリクエストは下記サイトにて行います

GOERLI FAUCET
https://goerlifaucet.com/

右上にある「Alchemy Login」から、先程作成したAlchemyアカウントでログインを行うと

アドレスの入力とボタンが活性化されるので、ウォレットのアドレスを入力して「Send Me ETH」ボタンを押下します。

押した瞬間、私の場合はこんな趣味の悪いページが出てきました。。。

ほんと、なんというか変な罠を踏んでしまったかと思いました。。左上にバツボタンがあるので閉じれば問題ありません。

ウォレットで確認

無事にウォレットにGoerliETHが届いていました。

ETHの送金は、24時間に1度可能な形で、送金金額も特に変更はできませんでした。
それくらいのボリュームでテストをしなさいということなんでしょうか？
フリープランだからかな？

ガス代高すぎ？

ちなみに、試しにデプロイしてみようとしたら。。。

まさかの資金不足。

なんか随分とガス代が高い気がする？
そもそもテストネットのガス代って何で決まるんだろうか？
メインネットと同様に、テストネットワークの混雑度によって決まるのだとすると、GoerliとSepoliaでどちらが空いているかとか、考えたほうがいいのかな？

fnm install で os error 5 になる

コメントを残す

ちょっと試してみたいことがあって、node.jsの古いバージョンを入れることに。

あまりバージョンをいじることがないんだけど、ローカル環境のバージョンマネージャ何を使っていたんだっけ。。。と考えてfnmを使っていることを思い出した。

fnm
https://github.com/Schniz/fnm

fnmを選んだ当初はそれほど意識はしていなかったんだけど、考えてみるとこれ、RUSTで書かれているんだよな、と。
RUSTはRUSTで元C++エンジニアとしてはいじってみたくなるんだけど、どこで使ったものかということで二の足を踏んでいるんだよな。

閑話休題

さて、目的のfnmを使ってinstallを試みたのだが

> fnm install 14.18.2
Installing Node v14.18.2 (x64)
error: Can't download the requested binary: アクセスが拒否されました。 (os error 5)

あれ？エラーになった

管理者権限はついているので問題はないはずなんだけど？ということで調べてみると、fnmではないけど似た事例が

Thank you for generating this report. It does look to me like a probable anti-virus problem.

fresh install fails on Windows: “error: could not rename component file from ‘… \rust-docs\share/doc/rust/html’ …” #1912
https://github.com/rust-lang/rustup/issues/1912

んー。AntiVirus？

ということで、手元のカスペルスキーを一時停止してみると

>fnm install 14.18.2
Installing Node v14.18.2 (x64)

>node -v
v18.1.0

>fnm use 14.18.2
Using Node v14.18.2

>node -v
v14.18.2

ということで問題なくインストールできました。

参照した先もRustのページだったので、Windows+Rust+ダウンロード処理でアンチウィルスのリアルタイムスキャンが影響を受けているということなんだろうか？

ぐぬぬ。先が思いやられる

アクアラインマラソンをデータで振り返る

コメントを残す

2年に1度の大会であるアクアラインマラソン。
前回はコロナで中止となったということもあって4年ぶりの開催となりました。
ここいらで、大会全体の振り返りと、個人としての振り返りをしてみたいと思います

大会概要

コース

コースに関しては大会HPに記載されています

コース紹介
https://chiba-aqualine-marathon.com/2022/info/course/

見ての通り、大会名でもあるアクアラインをフル/ハーフともに走るために前半戦で走ることになります。

逆に言うと、後半戦は市街地を走ることになり、なんというか、風景的な目玉は殆どない状態になってモチベーション的には結構厳しいコースとなっています。

特に、後半34km、38kmで訪れる上り坂は、満身創痍の体と心を平気でへし折ってきます。。。
特に最後の上りは、ほとんどのランナーは歩いてましたね

応援

それでも、市街地を走るということの利点として、街路の応援が結構あります。
特に地元の小学生や幼稚園・保育所の子供たちが応援してくれるのは、「ちょっと無様な姿を見せられないな！」って気持ちにさせてくれます。

いや、結局のところ後半は無様な姿を晒したんですけどね・・・。

そして、前半戦で調子に乗って「応援ありがとう！」って手を振って走ったりして余計に体力を使ってしまったような気がしないでも。。。

記録

個人の記録

開催結果の概要が公開されていました

https://chiba-aqualine-marathon.com/2022/img/news/221111.pdf

こちらを見ると、フルマラソンは完走率90.40%ということもあって、思ったより高いです。
そして、私がリタイアした初回大会の記録も書かれていましたが73.8%となっています。

他のマラソン大会の完走率はどうなんだろう・・・？と調べてみると、大会によってまちまちですが85%～95%くらいが多いようですね。

そう考えると、私がリタイアした初回大会は、やはり過酷な大会だったと言うことなんでしょう。
当日は11月の割に暑く、更に給食所には栄養ドリンク以外、食料が残っていないような形で運営側も対応が充分でなかった印象ですし。

個人の記録

大会として計測タグで測ってくれていたのがグロスタイムとネットタイムということで、キロ毎のラップタイムは手元のスマホ頼みになります。
ちょっとこの点は改善して欲しいですね。。。。
せめて関門ごとには出してもイイのでは。。。

1～10km平均5分39秒
11～20km平均5分25秒
21～30km平均5分16秒
31～41km平均6分38秒

見てわかる通り、前半はそれなりにいいペースで進んでいます。
今回、ペースを考える上で一つの目安にしたのは5:20/kmのペースです。

アクアライン高速道路や、ハーフマラソンコースまではとても気持ちよく走ることが出来、本番はやっぱり違うぜ！マラソン最高だぜ！って思いながら走っていました

右腿に違和感

27kmあたりを過ぎた頃、右腿が少し張ってくるのを感じました。

タイムを見てみると、22kmを過ぎたあたりから、気持ちよくなってペースが格段に上がってしまっています。22km～28kmまでの平均は5分10秒前後。それまでペースをいい感じに調整していたのですが、ハーフマラソンの選手と分かれてから急にペースを上げてしまったようです。

これまでのランニングでの経験で考えると、足がつるのはどちらかといえば左のふくらはぎが最初という認識でいました。次に右のふくらはぎですね。

そういう意味では、腿が最初に来るというのはちょっと以外。
しかし、まだ27km。足攣り対策用に持っているコムレケアゼリーは30kmあたりを目安にしていたのでちょっと早くて最後まで持つのか不安が残りますが、ここで使うことに。

そして、若干ペースを落とします。

両足攣りかける

34km前後になると、両足ともに張りが感じられ、38kmすぎにはついに歩くという選択をしてしまいます。
このあたり、張りを感じたら一度止まって屈伸等をするべきかどうか悩んだのですが、完全に止まってしまうと動き出すのに、精神的にきつくなりそうと感じたので歩くことに。

この判断が正しかったかどうかはわからないですが、歩くことで張りも収まってきてまた走る。そして歩くということを繰り返すようになります。

このあたりになると、完全に市街地なので沿道には応援の人々がいっぱいいて、正直無様な姿を晒すのが辛いのですが、それよりも足が攣りかけている方がきついのでどうしようもないです。

逆に言うと、体力的な面では若干の余裕がありました。
これはひとえに、事前の準備でしっかりと携行食を持っていた事と、各所にある給水所で必ず一口はスポーツドリンクを飲むなどの対応をしていたことが功を奏しているのだと思います。

今後の対策

体力的な面で考えれば、比較的なんとかなりそうな自信は持つことが出来ました。
もちろん、今回は歩いたりしている面もあるので、実際に走り切る体力があるのか？は不安は残りますが、まず対策をしなければならないのは走り切る肉体を作ることが第一ですね。

足を攣りづらくするようなトレーニングはどういうことをするべきなのか。

2時間29分のランニングドクターが教える「足つり」撃退のための4つのポイント
https://runnet.jp/project/comurecare201609/

こちらを見ると、対策としては以下が挙げられています

  1. トレーニングにLSDを組み込む
  2. お尻やハムストリングスを使ったランニングフォーム
  3. レース前・中は、水分＋電解質をしっかり補給
  4. レースには芍薬甘草湯しゃくやくかんぞうとうを持って走る

って、よく見ると、今回持っていったコムレケアの広告じゃないか！って気もしますが。

対策の3,4は出来ていたのではないかと。4に関しては、1個ではなく2個持っていっておけばよかったという反省はありますが、そもそもの土台としてはやはり1,2のトレーニングですね。

トレーニングとして紹介されているLSDはちょっと苦手です。
と言うのは、走り始めるとどうしてもペースを上げてしまうからなんですよね。

ここで書いてある「目安は”不快”に感じるくらいゆっくり、最低でも90分以上走り続ける」というのはなかなか難しいです。

“ゆっくり”と言うのは、絶対的な指標ではなく相対的な指標となるので、90分以上走り続けるというトレーニングを考えるのであればそれなりに早いペースでも90分以上走り続ければイイのではないか？と思ってしまいます。

ただ、実はこの”ゆっくり走る”ということ自体が重要であるならば、しっかりとそれに取り組まないと行けないですね。

LSDや、その他トレーニングに関してはもうちょっとしっかりと研究せねば・・・。

最後に

こうやって色々と振り返ってみると、まだまだ良いタイムを残すことができそうです。
それは、やはり成長を実感することができるということですし、マラソンは年をとっても長く楽しめる趣味として良いように感じます。

次にどの大会に出場するのかは未定ですが、今回完走することが出来たことで一つ自信をつけることが出来たので、挑戦を続けていきたいと考えています。