イーサの基礎
イーサの単位
Etereumの通貨はイーサ(Ether)と呼ばれ、単位もetherです。最小単位はweiだそうで1ether=1,000,000,000,000,000,000だそうです。すごい単位っすね。
1 wei = 1 wei
1,000 wei = 1 babbage ( kilowei )
1,000,000 wei = 1 lovelace ( megawei )
...
うーん、これ使いこなすのでしょうか？無駄な知識でなければいいですが...
私は省略しますね。必要な場合はネット検索で。国際単位と先輩たちの言ってた単位があって、それぞれ使うみたいです。うーんパブリックカオス。
ウォレットについて
ウォレットは他の仮想通貨と同じようなものです。モバイル、デスクトップWebベースなどあるようです。有名どころ
- MetaMask
- Jaxx
- MyEtherWallet
- Emerald Wallet
今も存在しているのか、どれが人口多いとかは分かりません。開発学習できればどれでもいいかな。
ウェイだけ覚えておけばOK
送金時のeth,gasの単位はeth,etherとgasのweiです。なのでこれだけ一旦頭にいれるとうぇーぃ。
イーサリアムでは
web3.js
three.js思い出しました。イーサはWEB3.0だ！ってことでjsライブラリをweb3.jsとしているそうです。
なるほど。なんとなくBSVでいうところのマネボ(ライアン)が作っているbsv.jsですね。
これをさらに使いやすくするラッピングライブラリとかあるならETHの方が作りやすいのかもしれません。
Webフロントのインタフェースってライブラリを提供するだけですかね？それならBSVと現状は変わらなくなっちゃいます。
嫌いじゃないカルチャー
BTCは保守的で互換性重視に対して、ETHは未来を重要視して、よりいいものの為には過去をぶっ壊していく方針だそうです。
Apple的な。古いデバイスはぶった切っていくスタイルですね。そのうちETH自体エンジニアは捨ててもおかしくない。
BTCの保守的な面はセカンドレイヤーとかリキッドとかそういったところで開発遅延を慢性化させそうですね。
ちなみに互換性のないDAppを作るという事はユーザの移行などにコストを割かないといけないということです。
BSVの件でも触れましたが、パブリックブロックチェーン上でビジネスしている人は少し頭が逝っちゃってます。
ビジネスになるか起業して成り立つかを考えると勉強はしてもサービスを展開するフェーズに到底到達しておりません。
当然投資してそれに合わせて開発研究している部門はあるでしょうが、B2Cはどどーんとするメリットがありません。
なんちゃってはできるかも。
イーサの評価は開発が早い点と思われているようです。BTCと比較しているのでしょうか。ETHも開発は混乱と鈍化のイメージを持たれています。この点が支持者とどう出ない人の乖離店その１かもしれませんね。
javascriptが出来ればよい。敷居は低い。
最も低いかは分かりませんが、jsさえ知っていれば裏が複雑でも簡単なコードで実行できる。それがイーサで、ブロックチェーンを学習するための最初のプラットフォームとして適しているそうです。それはそんな気がしますね。楽しみです。
イーサリアムとは
イーサリアムとは
イーサリアムはwww、インターネットに近い新しい概念のものです。インクトミみたいな財閥特許のインターネットと違い、BTC同様にOSSなのがより注目を浴びる点です。とはいえOSSって必ずどっかの大手の管理下に収まるのが相場なので、だからすごいみたいのは特にない、あってもなくなると思います。
グローバルなパブリックブロックチェーンであり、誰でも参加することは自由なのがPoW全体に言えますが良いところです。プライベートブロックチェーンは開発運用されている会社と契約(選定される)しないと使えないです。イーサがPoWで居続けるかは不明です。予定ではPoSになりたいそうです。
PoS目指しのPoW
EOSなんかは少数選挙制で、初期に権利を得て手放さない様であれば君臨しつづけたり、財力で投票権を買っちゃうなんてもできます。まぁそれを含めてうまくやれるという算段でEOSは設計されていると思います。PoWも一応競争で50%以上とれるようであれば破壊したければ破壊することもできます。破壊するくらいなら恨みないなら関わる意味ないですが。EOSの選挙制は覇権を握ることができますがこれも結局利用者がそれで逃げるようであれば元も子もないので、なんだかんだで国と同じで強いものがうまくやるのかもしれません。
ETHの問題とそれでも学ぶ価値
ETH界隈でよく言われているのは、そんな仕組みの前に性善説で利用したとしても利用することすら難しい状況に定期的になることです。BTCでもそうですが、gas、手数料が跳ね上がります。でもだから勉強しないとはなりません。高かったら使わなければいいし、価値が上がっても下がっても学ぶ価値はあります。ここがエンジニアの視点の違いかもしれません。
一緒に勉強しとく？
ETHはデジタル通貨を目指していません。そのためお金になりたいxrpやbchと競合しません。bchは通貨目的以外の人も存在しているのでキッチリとは分けられないですが...。
BTC,BCH,BSVよりETHはリッチなプログラミング言語が使えるそうです。そのため入門としてもってこいなのかも？
イーサの誕生理由
BTCは非常に使いづらい制約を載せられてしまいました。送金が遅く、データをほとんど載せられないというものです。そのメリットとしては当時の貧弱なインフラでお金として多少は使えるようにしたいためと思います。そのような背景からLTCなども生まれ一定のニーズを獲得したのかと思います。
そこでBTCでできるはずだったスマコンができなくなったのでETHをつくることになりました。
急遽若いビタリックさんが草案を出して巻き込んでいったようです。BTCの捨てた機能を拾ったとは厳密には違い、参考にしつつ考案したといったニュアンスかなと受け取りました。
さっさと技術的な所に行きたいが
書籍をさらっと読みながらなので序章はこんなことばかりになる。知っていた方がETHな人と話が噛み合うだろうから一応。
フェーズ
フロンティア、ホームテッド、メトロポリス、セレニティと開発フェーズが分かれていて、結構互換性なしのアップデートをしてきたようです。
なんか他にもあるようだけど、そんな感じです。
そう聞くとプロトコルロックをすべきと主張して順当にやってきたBSVは課題に対して有効な対処をしたんだなと感じる。
ちょっとした技術話
ポートは30303でEVMという仮想マシンで処理するそうです。
チューリング完全性
イーサリアムはビットコインと異なりチューリング完全らしいです。要は止まらずに計算し続けられるよってことですかね。ビットコインはだめなんですかね？ちょっと調べたところ、永遠に動けば必ずしも良い訳でもないようです。よほどの処理をするコンテンツを作れる日がくるまで気にしなくてもよさそう。チューリング完全は凄い訳ではなくて、そういう仕組みにすること自体は別にやろうと思えば他のブロックチェーンでもできるみたい。
またパブリックなブロックチェーンでは危険性も伴うとの事。うーん、ではなぜチューリング完全にしてるのでしょう。
無限ループを防ぐためにある
チューリング完全のせいで高度な計算を永遠にできてしまう。すると非常にノードに負荷が掛かる。みんなでこれをやったら成立しない。そこでgasがあるそうです。ガス代は多めに払っておけば、残りは払い戻されるそうです。ただ価格が固定ではないので相場を適当に算出するんでしょうかね。
スマコンより広いDApp
知りませんでした。スマコンは契約なんで、スマコンで作りたいものあるかなーと思っていましたがDAppはWebアプリみたいなものも含むと。そうですねDApp作りたいです。
本日はこの辺で。追記か新規投稿を行います。
BTC,BCH,ETH,EOSはすべて学ぶ価値がある
仮想通貨として価値があるないは、首を突っ込んでいるエンジニアには最重要事項ではない。なぜならEOSがダメになったとしよう。そしたら生き残っている別のスマコンを触ればいいのです。Win派だからWinがなくなりMacしかなくなったらパソコンは使わない！なんてエンジニアはほぼいない訳です。
BTC,BCHの作り上げてきたサービス、エンジニアの事は知っていて損はない。BTCの時からずっとブロックチェーンを利用したサービスを構築する人は、私にとって先輩にあたる。実際現在BSV上に構築している古株は当然BSVが誕生する前から携わっている。
この点、BTCの汚点だが早々にETHにスマコンエンジニアを流出させてしまった。現在BSVはジェネシスからそこそこ順調に成長しているが、ETHに流れたエンジニアや、そこで培ってきたノウハウは流用すべき点がある。
この点は待てばいいかと避けていたが決定的だったのがsCryptとETHエンジニアの記事を見た時です。まず「ETHのようなことがBSVでもすでにできるんだ！」と言われる訳です。いやETH勉強してないしなーみたいな。業界の先輩はBSV以前からブロックチェーンエンジニアな訳です。BSVもコミュニティはBTC->BCHと来ていて、その中で構築したり、EOS触ってる人だったり、ETH,LTC触ってる人もいます。そもそもBSVしか触ったことないエンジニアは入学したての新入生状態です。
長くなりましたがsCryptの決定打がSolidityです。では以下のサイトを閲覧してみてください。
日本語で冒頭になんて書いてあるでしょう。またフレームワーク（デザイン）はどうでしょう。これsCryptがやろうとしてることよねって。
そうなんです。sCryptにはETHをディスるよりも敬い参考にすべき先輩がいます。いずれ追い越すにしても先駆けて着手している方です。
だからエンジニアほどあまりプロレスをしないのです。畑が違ってもべつに移動できます。いずれその優秀な先輩がウチの畑にくるとしたら、
ディスってるよりテメーの成長を急がないといけません。
そして逆にいうとチャンスでもあります。BSVは根幹の悪い部分を排除して仕切りなおしています。いまブロックチェーンで飯を食っている人は、あまりBSVの仕事はありません。でも仕事が増えたら当然移ってきます。それまでのこの時間は勉強させていただきましょう。
BSVが順調なのは仕切り直しで他所の良いもの悪いものを判断できたからで、道なき道をすすむこれからはこれから参加するエンジニアにかかっています。動画、音声、画像、長文。これらをオンチェーンにまともに安く速く上げられるブロックチェーンはこの世に現存しません。これからBSVが時間と共に目指していく世界なんす。
ちなみにEOSの日本語の(電子)書籍は見当たりませんでした。ネットで探せばあるかもしれません。日本語で優しいブロックチェーン技術を定期的に購読して日記を記す??ノルマにチャレンジします。急がば回れ、KotlinもやりたいがsCryptを最高に使える状態でアプリを作りたいから一旦止めています。
reactは良かった。でもアプリがいい。
たとえばbit.svの人は一旦ブロックチェーンとは違う仕事を受注したようだ。これは開発者からすればそれが普通だ。
現在ブロックチェーンはただただ収益はなく投資されている状態。これはしばらく続く。youtubeやtwitterが最近まで黒字化できないのと同じ。だから投資なくずっと時間を割くことはできない。
ジョンはBSVの予測が早すぎることに注意を払っています。
要点は、人々が考えるよりもずっと長くかかることです。
今回のハッカソンでは現実的なアプローチをした企画がラインナップした。しかしどれもどこまでブロックチェーンするのか？マデブロをエンジニアたちは注目する。フルは夢があるし試したいが、正直とうぶん作っても使えない。未来はそうなるかもしれないから勉強にはいいかもしれないが、今すぐは使われないし、使い物にならない。
さて、ハッカソンは上位者は出資される可能性がある。これを参加者はどうとらえているのだろう。出資が滞るとしりつぼまりでフェードアウトすることになる。こうなると次のチャンスは当然つかみにくい。果たしてブロックチェーン事業で収益がない状態で、経費掛かりまくりの状態で、起業する算段はどこにあるのか？
カルビンの出資を終えたトニックポウはどこまで持ちこたえられるのか。私はそういう目で見ている。今投資を受けるには、長期的に増資をしてもらえる前提でなくてはいけない。テレビ広告からネット広告に企業が移るまでにどれほどに時間が掛かったか中年ならわかるだろう。10年くらいほそぼそともしっかり経営し続けていく事業計画が必要になる。
_unwriter氏はコミュニティの前半を無料にした。チップとか、チェーンに残したいものは有料になる。ビジネスライクではない路線を模索している。この手法は企画次第で投資なくスタートできる。powpingの登場でこれまでの何に付けても金のかかるブロックチェーンサービスはユーザに敬遠されるようになる。しかし_unwriter氏も投資を請けた身。模索も褒めてばかりではさきはいずれなくなる。ソーシャル系はポコポコ作られていますが、まー正直利用はイマイチどころか全然です。twetchもpowpingもそれいがいにもtocialとかあとインスタっぽいオシャレな奴もありますよね。でも使わないですよね。なぜかって人が少ないからですかね？ひとが少なくてもつかわれるような閉鎖コミュニティでワンチャンありますが、それもブロックチェーンだから..で度々お金を請求されたら、無料のでいいやってなります。slackやlineやdiscordでいい訳です。ほかにもたくさんあります。
まとめると、当たるときはいつか来る、投資なんて今受けるのはリスクじゃないの？って話です。当たった瞬間にね、これまでにないくらい投資資金はあつまりますよ。比じゃないくらいに。投資させてくれと。いやいらんと。
で、『タイトルのreactは良かった。でもアプリがいい。』ですが..これはwebにおいてreactっていいなぁ勉強になったなぁと大きく感じつつも、どっちもサービスがあったらアプリを使うよなぁって話です。twitterもyoutubeも...食べログはそんなに開かないのでwebでいいかな。メルカリも同じ感じ。まぁみなさんも使う時間が長ければアプリになるはずです。webはあまり使わない人向けの窓口で、結局コアユーザはアプリを使う。それとアプリだけならAPIサーバだけあればいい。そのAPIサーバを簡素化にひたすら集中できる。だからアプリで作ってAPIとブロックチェーンを時代に合わせてすりあわせていけばいい。だからアプリでKOTLINとswiftを勉強するのです。
またbitcoin scriptを学ぶ日が延びました。でも1言語3か月くらいでさらっとはいけるんじゃないでしょうか...とりあえずmac miniをぽちりました。
reactPJTハッカソン中いじってはいけないらしいので、Kotlinやるお(`･ω･´)
reactいじってたらnpm追加したくなって、追加したら本チャンがおかしくなったので、ビルドしなおした。でもこれやるとdevが反映されてしまう。個人的には反映されてもいいんだけど、ハッカソン中はルール上ダメだ。
と、いうことで裏でそんなことを気にして開発したくないので、とりあえず次のネタにいこうと思ってペラページ作ったところで、これ別にreact, nextjsじゃなくてもいいなと。まぁAPIはreact使うとして、それでiphoneアプリはObjective-Cじゃなくてswiftになったから、androidはどうなんだろうと調べたらあった訳ですよ。これから始めるならKotlinが一番デメリットないですよって。
briarpatch.co.jp
エンジニアさんがいってるなら間違いない(`･ω･´)
iphoneは持ってないからandroidでいこう。そのうち買おうかな。いやipad proあるわ。いける。
そんな感じで開会宣言でした。10月中まではこれかな。
追記
android studio重くて、説明が分かりやすいサイト見つからないからipad proでswiftからはじめるかも。初日だから分からないのは平気なんだが、重いってのはPC替えないと永遠だからな。
実運用経験のない2か月程度のreact勉強中が恐らく本番開発運用こうだろうと推察するブログ
意外と実運用の記事とか、本ってないのではないでしょうか。nodejsも自由にやろうと思えばできますし、reactもそうなのかな？nextjsに勝手についてくるのかwebpackなるものがあります。これがそもそも一番普及しているLAMP的なノリではないところがありますね。
LAMPですと、バーチャルホストで分けて本番環境、テスト環境をディレクトリでキッチリ分けたりします。でもreactなのかwebpackなのかは分かりませんが、こんな感じでなっています。
"scripts": { "test": "echo \"Error: no test specified\" && exit 1", "dev": "開発環境用コマンド", "build": "ビルド用コマンド", "start": "本チャン用コマンド", "install": "rm -rf node_modules/ && rm -rf package-lock.json && rm -rf .next/ && npm install && npm run dev" },
testとinstallは海外とか色んな所でいいなと思ったもの、無意識に記述していたものです。実運用でもこれくらいは記載していそう。食べログとか、DMMとかリクルートに聞きたいわ。testは本当はいらんけど、Hello world的な「npm run test」を実行してみるテスツみたいなもの。このように何でも追加できて、それに記述されたコマンドが実行される。そう、開発なのか、本チャンなのかで、コマンドが変わるんですね！これがLAMP的にいうと何故？気持ちわるぅってなります。
installはcleanと書いても良くて、適当にnpmをインストールしていると順番なのかなんなのか壊れる時があるから。node_modules消して、package-lock.json消して、.nextっていうビルド後のファイル消して、npm installで、package.jsonにあわせてインストールしなおす。そしてnpm run devは「開発環境用コマンド」ですね！
この時におかしなことになっていると、あのモジュールがないぞとか、いろいろ分かります。
まぁちょっと怖いのが同じディレクトリで開発と本番があることですよね。一応切り分けられてはいるんですが、距離が近すぎます。キッチリ分けられていたLAMPと比べると、別にかっこよくもありません。
で、開発本番で渡す値を変えたり、ポート変えたりできる訳です。私は開発でゴリゴリしてポートそのままにビルド後に本番として「npm run start」しました。すると同じポートを使用できないので、別のポートを開放してそっちのポートでリッスンして「npm run dev」とした感じです。これで同時に同じPJTディレクトリで開発と、本番が出来上がりました。
あとはこの趣味レベルで開発ゴリゴリからの本番適応を繰り返して、本当に問題ないのかですね。一応一度実行したnodeはその時のファイルを参照し続けているので、開発のビルドがコケて、やべーーーってなっていても、旧来の状態でサービスし続けてはくれているはずではあります。そうはいってもドキドキですね。慣れかもしれません。LAMP歴長い人多いでしょうから同じ気持ちになると思うんですが、ディレクトリキッチリ分けて、ビルドが問題ない状態になったらcpとかsync的に本番用の別ディレクトリに反映させて「npm run start」をstop,startさせたいものです。まぁ面倒なんで問題なければこのwebpack?に従いますが。
そうそうちょっとしたミスとかすぐ直る軽微なバグとか、これっていちいちビルドするってことですね。この辺がWeb感薄くて、スマホアプリ感ありますね。どっちもアプリなんですけどね。
具体的に書きますと、本番は3000ポート、開発は3001ポートにする場合、
"dev": "next -p 3001", "start": "next start -p 3000",
こうですね。これで参照するディレクトリも違います。nextjsを触っている方なら分かると思います。開発環境は少し処理が重くなるが、エラーとか出して開発しやすくなっています。逆に実運用には邪魔なのでビルドで軽快なエラーも見せないバージョンになります。
試しに「# npm run start」中に「# npm run build」したら反映されるか見たが、反映されず、restartしたらコケて、再buildしたらstartできた。
おいおい、これじゃリリースする度にbuild中止まるよね？サーバ複数で運用ですか？必ずメンテページですか？ちょっと未来と引き換えに、まだ不安定な部分しか見えない。ワシが知らないだけなんだろうか。
追記
dev -> build -> startでdev,startは両立できるが壊れるケースがあって、それがnpmなどでnode_moduleを追加するときだ。このときに.nextディレクトリがない！みたいなエラーがでてstartに影響が出る。つまり安全に行くならディレクトリは分けなくてはダメ。一旦npm installしてbuildしてstartといった一瞬サイトがおかしくなる。それあかんよね...。やっぱりメンテ画面だしたり2台構成で交互にスイッチさせてみたいなことを大規模なサイトだとやらないといけなそう。それかテストディレクトリをrsyncかなぁ。にしてもおやっぱおかしくなるな。ノンビジネスサイトならえいやー！でいいけどね。
