さて、LEARNの第1回！
まずは、Ethereumのスマートコントラクトの実装とそれを呼び出すアプリケーションの実装。
Section 0
- Terminal操作
- Javascript
- React.js
の技術が前提とのこと。
これなら楽勝そう。
ブロックチェーンの前提知識はあるのでとりあえずサラッと。
WavePortalと呼ばれるdApp（Decentralized Application）を作るとのこと。
WavePortalって何？
って思って、軽く調べたけど、、、そんなすぐに出て来なそう。
const waveContractFactory = await hre.ethers.getContractFactory("WavePortal");
というFactoryメソッドの引数として書いてる感じ。
・・・・・・・と思ったら、wave（?）を送るオリジナルのポータルサイトを作りましょうというだけの話。
身構えすぎたよう・・・
とりあえず、
Solidityでバックエンドを実装
Reactでフロントエンドを実装
して、構築するとのこと。
ブロックチェーンのコードはOSSが多そうだから、ライセンスもしっかりしないとダメそう。
今回のコンテンツにおいては、以下二つのもとで運用されているとのこと。
GitHubのフォークページから色々追っていったら、GitHubSkillsというサイトに辿り着いた。
How to use GitHubなので、「GitHub」の使い方だと思うけど、Gitを知っている人でもGitHubの使い方を知らない人がいると思うので良さそうだ。
InnerSource
InnserSourceが重要ということでリンクがあったので見てみた。
Innersource is a development methodology where engineers build proprietary software using best practices from large-scale open source projects, like Kubernetes or Microsoft’s Visual Studio Code.
Innersourceとは、大規模なオープンソースプロジェクトで使われているベストプラクティスを利用して商用ソフトウェアをビルドする開発手法。
Open Source Guidesなるものも紹介している。
5つの教訓
- Open collaboration encourages more contributions: オープンなコラボレーションはより多くの貢献を促進する。
- Developers don’t always have to start from scratch: 開発者はスクラッチ開発する必要はない
- Transparent decision-making builds process, trust, and alignment: 透明性のある決断によって、プロセスと信頼と連携を築く
- Participation is critical: 参加が重要
- Core development teams strengthen a project’s process: コアデベロップメントチームがプロジェクトのプロセスを強化する
最後の「Core Development Teams」というのはDAOにおいても非常に重要な教訓な気がする。
Creating a small, cross-functional team of decision makers can also help teams stick to quality standards and gain executive support.
小さな機能横断的な意思決定者のチームを作ることがチームを良くしていく、と言っている。
DAOで、分散、分散と言っているけど、コミュニティをうまく回すにはここが重要なんだなと思う。
企業をより効率的にするための方法
- Making it easy to find and reuse code on a broad scale, avoiding wasted resources and duplication: コードを見つけやすく再利用しやすくすることで、無駄なリソースや重複を回避できる
- Driving rapid development, regardless of company size: 企業規模に関わらず、迅速な開発をする
- Reducing silos and simplifying collaboration throughout the entire organization—inside and between teams and functions, as well as across teams and business lines: サイロを減らして、組織全体の協力をシンプルにする
- Increasing clarity between engineers and management, as well as anyone else who’s interested: エンジニアとマネジメント間の透明性を上げる
- Creating a culture of openness, a precursor to open source participation: オープンな文化（オープンソース参加の先駆者？）を作る
- Reinforcing the pride, growth, and job satisfaction felt by team members who help wherever there is a need: プライドと成長とやりがいを強化する
体制
- Maintainers: 責任を持ってやっているContributors。必ずしもプロジェクトオーナーでなくても良い。
- Contributors: 貢献をするすべての人。
- Community members: プロジェクトを利用する人。
ツール
- Issues: イシュー（バグや新機能のアイデアなど）管理。
- Pull Requests: プルリク（実装したい機能のやり取り）機能。
- Synchronous chat channels: チャット（Slackのようにリアルタイムでチャットできるようなもの）機能。
チェックシート
- Does our organization have an open and transparent culture?: オープンで透明性のある文化を持ってるか？
- Do we develop software on a single, open platform?: 一つのオープンなプラットフォームでソフトウェア開発をしているか？
- Are our engineering initiatives well resourced and supported by leadership teams?: エンジニアリングイニシアチブがリーダーシップチームによってリソースが提供され支援されているか？
- Do developers at our organization have enough autonomy to contribute to projects outside their immediate teams?: 開発者が自律的にチーム外のプロジェクトに貢献できるようになっているか？
- Does our company participate in the open source community?: オープンソースコミュニティに参加しているか？
- Does our engineering team use continuous integration tools?: エンジニアリングチームがCIツールを使っているか？
- Are there pre-existing, cross-functional communities that work across teams at our company?: すでに機能横断的なコミュニティーがあるか？
- If yes, do these communities have built-in leadership?: もしある場合に、そのコミュニティはリーダーシップを発揮しているか？
まとめ
Section 0は・・・Terminal操作とJavascriptとReactができれば良いということだったので、一旦安心。
で、BackendはSolidityで作って、FrontendはReactで作るということで理解。
分量が少なかったので、Innersourceについての記事を見たけど、Goeswell 3.0、DAOを推進していくにあたっても非常に良い記事だった。
