//tips
//基本情報理解
スクラムは開発フレームワークであり、スプリントと呼ばれる単位をベースに漸進的な開発とレビューを行う。スプリントと混同しないようにする。
プロダクトオーナーの役割、スプリントレビューなどのイベント、プロダクトバッグログなどの作成物、及びルールからなるソフトウェア開発フレームワーク。
特許が出願される前に、その実施または準備をしているものには先使用権による実施権が認められる。
PMBOK Project Management Body of Knowledgeのプロジェクトスコープ記述書は、プロジェクトが生み出す主要な成果物とそれを生み出すための前提条件及び制約条件を記述したもの。成果物の受入基準やプロジェクトから除外する事項を明示してステークホルダーの期待を管理するのに役立てる。
//pitch
タスク管理アプリであるWunderlistのpitchを見つけたので、そちらを確認した。１０ページとシンプルにまとめられており、ビジュアル的にも内容がわかりやすかった。
Todoリストであるせいか、製品説明がなかったが、その代わりに、現在どれだけの人に使われているかの強調や、使われる理由としてクロスプラットフォームへの対応などが説明されていた。
確かにどのプラットフォームでも自分のタスクを管理できることは役に立ちそうと感じたのでユーザーの増加も納得できた。手帳よりもこちらの方が管理しやすそうである。
https://www.pitchdeckhunt.com/pitch-decks/wunderlist
//smartcontract
ベースのGas価格は実装される演算によって決められているのは知らなかった。需給だけではなかったよう。
また、早くトランザクションを実行したいときにはgas代を高く設定する必要がある。
別途gas limitもあるが、こちらはマイナー側の事情に関わることが多く、ユーザーが決められて、使わなかった分も戻ってくるのでネットワークの最大値を気兼ねなく設定できるよう。基本は21000以上となる。
逆にgas limitを低くしすぎると失敗し、ガス代も戻ってこないので注意が必要。
gasprice*gaslimitがガス代として支払う代金となるのでその認識はしておく。
開発者としては、使用されるgasをなるべく小さくする設計を行い、同じstorageを何度もアクセスするのではなく、memoryに保存してから計算するようにしたり、ループを多用しない、関数を分割するなどの工夫が必要になる。
pragma solidity 0.8.4;
contract GasTest1 {
function compute(uint x,uint y)external returns(uint){
uint result;
//ループはgas代が非常にかかる
for(uint i=0;i<y;i++){
result +=x;
}
return result;
}
function computeFree(uint x,uint y)pure external returns(uint){
uint result;
//pureなので無料
for(uint i=0;i<y;i++){
result +=x;
}
return result;
}
}
また、変数のnullのものに値を新たに入れるよりも先に値を入れておおき、更新する方が安くなるので意識して初期値を入れるようにする。
pragma solidity 0.8.4;
contract GasTest2 {
uint a=1;
uint b=2;
uint c;
uint d=1;
function getA() view external returns(uint){
return a;
}
function changeC() external returns(uint){
//cはnull状態から新たに値を入れるとガス代が多めにかかる
c=a+b;
return c;
}
function changeD() external returns(uint){
//dは値を更新するのでガス代がかかるがnullのものよりはマシ
d=a+b;
return d;
}
}
また、transferではなくcall関数が使われなくなった背景をコードで確認。ガスの使用量制限が大きなポイントになっていた。
contract Bank {
event balanceUpdate(string indexed _txType, address indexed _owner, uint _amount);
mapping(address => uint) public balance;
…
function withdraw(uint _amount) external {
require(balance[msg.sender] >= _amount, "Insufficient balance");
balance[msg.sender] -= _amount;
//payable(msd.sender).transfer(_amount);
//transfer関数からcall関数への再移行
//call関数はgasが指定できる。transferは2300ガスで固定
//指定しない場合はgaslimit maxで送られる。{value: _amount,gas: }
//("")で関数を呼ぶなどできる
//(bool success, bytes memory data) はうまくいったか、いかなかったかの判別
//bytes memory dataは関数を呼ぶときのみにかえってくるので今回はなし
(bool success, ) = payable(msg.sender).call{value: _amount}("");
//うまくいかなかった場合のためにrequireで制約
require(success, "Transfer unsuccessful");
//transferが使われなくなってきたのは2300でできることが少なすぎるから
//逆にtrandferが使われるようになったのはDAOでの半無限引き出し事件があったから
//callを使う際には送る前にbalance[msg.sender] -= _amount;を必ず行う
//check effect interactionのコードパターンを遵守する
emit balanceUpdate("Withdraw", msg.sender, balance[msg.sender]);
}
…
コード設計をミスるとDAO事件のようなことが起こるので注意が必要。
参考にしていたyoutubeの方がdApp開発編をやっていたので、api接続などのjs関係も、そちらを通して学んでいくことにする。coingekkkoのapiからリアルタイムの価格を引っ張れるようなのでかなり楽しみ。
https://youtu.be/4qvh9NWOOhE
