Tech | koshilife's blog

株式会社PitPaさんよりVC&NFTを頂きました

株式会社PitPaさんよりVC&NFTを頂きました。良いプロジェクトに携われたこと誇りに思います。感謝申し上げます。 PitPaさんからプロジェクト貢献者としてVC(Verifiable Credentials)&NFTをいただきました🙏光栄です🤩https://t.co/2IT64lRZ1C pic.twitter.com/rFvYpgObey — Kenji Koshikawa (@koshi_life) November 13, 2022 NFT: https://opensea.io/assets/matic/0x9021e4ed95ea2157595c261c3da318b75a6dc156/1 VC: https://vcs.pitpa.jp/certificate/QmPbWgxaMcpC1xxgfXaBt6eseR45ffAGb1rY14K6ZRt24n ▼プロジェクト概要千葉工業大学と共同で開発した学修歴証明書におけるエンジニアリングを担当し、プロジェクトの達成に大きく貢献した。千葉工業大学の公式リリース: https://www.it-chiba.ac.jp/topics/pr20220818/ ▼優れていたところ・事業要件に対して、実績あるライブラリを複数選定し、それぞれのメリット・デメリットを洗い出し最終的にBlockcertsを選定した。・Blockcertsで足りない機能をメインコントリビュータとディスカッションの後、実装することでOSSの貢献をおこなった。・ https://github.com/blockchain-certificates/cert-issuer/pull/234 ・ https://github.com/blockchain-certificates/cert-issuer/pull/237 ・業務フロー図を作成し、社外含めた全体の共通認識を図り、プロジェクト遅延を未然に防ぐことができた。

(ブログ寄稿) NFTチェーン、EthereumかPolygonどっちにする? 真面目にガス手数料を見積った話

ブログ寄稿のお知らせ株式会社PitPaさんの技術ブログに寄稿しました。こんな記事を寄稿しました。是非読んでやってください🙏https://t.co/UgkTWHrmF5 — Kenji Koshikawa (@koshi_life) September 6, 2022 NFTチェーン、EthereumかPolygonどっちにする? 真面目にガス手数料を見積った話 https://zenn.dev/pitpa/articles/about-estimating-gas 後日このPRJについて、テレ朝ｎｅｗｓでも取り上げていただき、日の目を見てとても嬉しい気持ちになりました。

(読書メモ) メタバースとWeb3

Amazonリンク https://www.amazon.co.jp/dp/B09W9B5Q6H/ 読んだ理由支援先企業にてWeb3系の案件に携われそうな機会があり、3-4ヶ月前にも「NFTの教科書」を一度読んだ際にわかった気になっていたが、知識が曖昧な認識だったので別の本を用いて知識の埋め合わせをしたかった獲得したい知識・読後イメージ Web3を構成する重要な要素技術の洗い出し、概要を掴みたいブロックチェーン技術の進化の簡易的な歴史がわかっている簡易的な用語集がインストールされている業界の主要プレイヤーもしくは主要サービスを把握できている読んだ感想目次 - INTRO メタバースやWeb3がバズった本当の理由 - Chapter1 これまでの流れを知ると、Webが行き着くゴールが見えてくる - Chapter2 メタバースとは何か? - Chapter3 次世代インターネットWeb3を徹底解説 - Chapter4 メタバースとWeb3が辿り着く未来の姿 - LAST CHAPTER メタバース、Web3の事例から見るビジネスチャンス - 用語集 Chapter3までで読書の目的だった要素技術の概念と生まれた背景を把握できた。Chapter4以降は流し読み。2時間弱で読了。 Web3要素技術、進化の歴史や特徴、どういうイノベーションなのか解説がありわかりやすかった。これから先のメタバース・Web3の著者の展望の他、著者のビジネスでの必勝法が紹介などもあり興味深かった。モバイルゲーム、モバイル動画、VR/AR、ブロックチェーン。新しい事業をつくる際には、私なりの必勝法というものがあります。まず３年から５年後に来る市場はどこかというのを見定めて、次に市場が立ち上がってきたらそこで成功する会社はこういう会社だという仮説を立てて、最後にファンドを設立してさまざまな会社に投資をしながら、投資先間で情報共有を徹底して、仮説検証を高速に回していくという戦略です。國光宏尚. メタバースとWeb3 (pp. 75-76). Kindle Edition. ↑この必勝法を知れただけでも買って満足。（本書のスコープ外）これらの関連技術を使って、具体的に実現する方法(Engineering)は全くイメージが湧いていないので別途キャッチアップする予定。メモ・引用ブロックチェーンの過去の変遷を振り返ると、いまのブロックチェーンは「第4世代」にあたります。第1世代というのは、ビットコインとそのコピペです。第2世代はイーサリアムとそのコピペ。第3世代はイーサリアム上で動くアプリケーションたち。そして第4世代が、イーサリアムのガチライバルたちです。國光宏尚. メタバースとWeb3 (p. 73). Kindle Edition. ↑ざっくりのブロックチェーン技術の潮流がまとまめてくれていて有難い。この用語集は捗りました。（以下抜粋）・CeFi（CentralizedFinance）ある特定の企業や組織への信用を介して行われる従来型の金融サービスの中で暗号資産を取り扱うもののことを指す。・DAO（DecentralizedAutonomousOrganization）ブロックチェーン上で世界中の人々が協力して管理・運営される組織のこと。中央管理者はおらず、参加者同士で管理していく。また、透明性が高く、誰でもソースを閲覧できることや、誰でも組織に参加できるという特徴がある。・DApps（DecentralizedApplications）ブロックチェーン上でソフトウェアを動作させる仕組み「スマートコントラクト」を利用することで実現できるアプリケーション。・DeFi（DecentralizedFinance）日本語では「分散型金融」といい、銀行や証券、保険、取引所など旧来の金融機関が担ってきたサービスをブロックチェーンを通じて提供するシステム。・GameFi GameとFinanceを合わせた造語。NFTで用いられるブロックチェーン技術を利用して作られたゲームで、NFTゲームと呼ばれることもある。・NFT（Non-Fungible Token）ブロックチェーン技術を活用することで、コピーが容易なデジタルデータに対し、唯一無二な資産価値を付与し、新たな売買市場を生み出す技術・Uniswap（ユニスワップ）イーサリアムのブロックチェーン上に存在する、人気の分散型取引所（DEX）。非営利目的であるため手数料がほとんど発生しない。という特徴がある。・Web3 國光流シンプルな定義として仮想通貨、暗号資産、ブロックチェーン、クリプトのリブランディング。・クリプト P2Pの金融取引とインターネット上のスマートコントラクトを分散化された（非集権的な）方法で容易に行えるように設計されたデジタル資産國光宏尚....

(読書メモ) ソフトウェアアーキテクチャの基礎

Amazonリンク https://www.amazon.co.jp/dp/4873119820/ 読んだ理由ソフトウェアアーキテクトという役割・キャリアについて興味があった。良いソフトスキル・習慣・思考などがあれば自身をアップデートしたい。主要なソフトウェアアーキテクチャパターンの知識の獲得および再確認を通じて、日々の設計業務の生産性を高めたい。読んだ感想上記理由を満たせたので大変満足。読む前の自分の抱いていたアーキテクチャに求められるスキルは技術面に優れているイメージが強かったが、読んでみて交渉力やコミュニケーション力などのヒューマンスキルの求められるレベルの高さは、確かにな〜と盲点だった。紹介されていたアーキテクチャパターンの特性を抑えられて、引き出しが増えた気がする。スペースベースアーキテクチャなどの高度なアーキテクチャパターンを使う機会は転職以外に思いつかないが、引き出しに閉まっておこう。必要な技術知識の表現として、開発者は深さ、アーキテクトは幅が大事という表現は秀逸だった。読んで見て、アーキテクトの行う仕事とは？こんな感じか。１．ドメイン理解と組織状況をインプットして、必要なアーキテクチャ特性(illy)を導く２．上記で導いたアーキテクチャ特性を満たせる最良のアーキテクチャ案を導く。各案の良し悪し(トレード・オフ)を整理。３．関係者と認識合わせし、アーキテクチャ案の決定までを主導。決定プロセスにおける根拠を共有することで無駄な再検討を防げるのと納得感の醸成に大事。４．開発チームと協調してアーキテクチャ案を具現化。５．（初期構築はもちろん完璧じゃないので）開発イテレーションを通して継続的にアーキテクチャを磨く。各章のメモ ## 1章: イントロダクション - システム構造、イリティ特性、アーキテクチャ決定、設計指針を考える必要がある - イリティ特性 (-ility) - 可用性 Availability - 信頼性 Reliability - テスト容易性 Testability - スケーラビリティ Scalability - セキュリティ Security - アジリティ Agility - 耐障害性 Fault Tolerance - 弾力性 Elasticity - 回復性 Recoverability - パフォーマンス Performance - デプロイ容易性 Deployability - 学習容易性 Learnability - アーキテクトへの期待 - アーキテクチャ決定を下す - アーキテクチャを継続的に分析する - 最新のトレンドを把握し続ける - 決定の遵守を徹底する - 多様なものに触れ、経験している - 事業ドメインの知識を持っている - 対人スキルを持っている - 政治を理解し、舵取りする - リーダシップスキル - エンジニアリングプラクティス再現性のある効果を示すプロセスに依存しない手法を意味する。e....

(読書メモ) モノリスからマイクロサービスへ

Amazonリンク https://www.amazon.co.jp/dp/4873119316/ 読んだ理由モノリス、マイクロサービスの各アーキテクチャ特性の違いを知りたかったので積んでいた本。ここ約3年、前職でRoRのモノリスのサービス開発をしていて、直近３ヶ月くらいはマイクロサービス的なサービスに携わり２人月程度のシステムを要件定義〜設計〜リリースまで主導した後、１日1章くらいのペースで読んでいった。きっと自分の設計思想が正しいものであったのか、もっとよい方法がないのか、ある種の答え合わせをしたかったのだろう。読んだ感想大変満足。設計の引き出しが増えた感と選定根拠を示す上での言語化する機会に役に立つ知識をインストールできた気がしている。今までやってきたアーキテクトパターンや思考に名前が付いていたりと他の開発者とコミュニケーションをする上で共通認識の専門用語を使ってコミュニケーション/議論の効率化に繋がるイメージを持てた。モノリスとマイクロサービスどちら側でもないフラットな視点で全体的に解説されていたが印象的。それぞれにメリット・デメリットがあるのでトレードオフを理解しバランスを取る必要があるとのこと。サーガという分散トランザクションの紹介は、まさに最近の設計で少し悩ましかったところで、補償トランザクション (Compensating Transaction)っぽいことは考えていたので、思考方針としては正しかったことがわかって安心できた。各章のメモ (一部) ### 5章 - 所有権のスコープ - 各マイクロサービスに対する所有権の扱い。組織が大所帯で自由に各マイクロサービス修正できてしまうとコードに統一感がなくなり質が悪くなりがちなので、チームで変更管理をして、他チームからはPullRequestで受ける形をとったりする - 破壊的変更 - マイクロサービス間のIFに変更があり、本番リリース後に影響が出る問題 - ロックステップリリース - 監視とトラブルシューティング - マイクロサービスの監視はモノリスと比べて複雑になりがち - まずやるべきはログ集約であり、ROIが高い。 - 本番環境でのテストとても価値があるが、顧客に影響がないようにしよう - マイクロサービスはモノリスに加えてe2eテストを整えるのにコストがかかる自動テストは各マイクロサービスの役割に留めるのがベストプラクティス - 技術選定時の考え方 (5.9.3) - 可逆的な変更か不可逆的な変更か? - 横断チームに各チームの技術リーダーを入れて組織全体のアーキクチャを共有できるような仕組みがベストプラクティスとしてあるよ - 孤児サービス - サービス概要が時間経過に伴い不明になること。メタデータなどでサービス管理をすることで、サービスの役割、どのチームが作ったのか管理すべきか？などを管理しておくと、長期間運用しやすくなるだろう。そういった課題を解決するサービスも出てきている (biz ops ツール)