reactは良かった。でもアプリがいい。

たとえばbit.svの人は一旦ブロックチェーンとは違う仕事を受注したようだ。これは開発者からすればそれが普通だ。

現在ブロックチェーンはただただ収益はなく投資されている状態。これはしばらく続く。youtubeやtwitterが最近まで黒字化できないのと同じ。だから投資なくずっと時間を割くことはできない。

coingeek.com

ジョンは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やるお(`･ω･´)

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勉強中が恐らく本番開発運用こうだろうと推察するブログ

nextjs reactjs nodejs

意外と実運用の記事とか、本ってないのではないでしょうか。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かなぁ。にしてもおやっぱおかしくなるな。ノンビジネスサイトならえいやー！でいいけどね。

toychainではじめるsqlite メモ書き

sqlite toychain

DBは三つで構成されている。

.schemaでテーブル構成が分かる。wallet, chain, txかな。

sqlite> .schema wallet
CREATE TABLE wallet (id INTEGER, xpriv, xpub, priv, pub, address, PRIMARY KEY (id));

sqlite> .schema chain
CREATE TABLE chain (id INTEGER, tx TEXT, parent JSON, edge JSON, spent INTEGER, PRIMARY KEY (id));

sqlite> .schema tx
CREATE TABLE tx (id TEXT, tx TEXT, genesis INTEGER, sent INTEGER, PRIMARY KEY (id));

はじめtxやろ！って見てみたが、見てもよく分からず、txとブロキャス前のtxだなぁ。これだけみてどうするんだろって思ってchainみた。

id: 62
tx: toyなtx
parent: [30]
edge: {
	"address":"発行したアドレス",
	"txId":"toyなtx",
	"outputIndex":1,
	"script":"76a9149ee03f3135f0b7b9ecabab953c3087a165b7764d88ac",
	"satoshis":1192
}
spent: 0

サンプルに1行抜いてきた。spentってのはutxo的なものだろうか。まぁ勝手に処理してくれるところはあとでしればいい。toychainの欠点はGETにあり、条件検索とかで引っ張ってきにくい。なので、もはやdb直で検索した方がいいと思っている。その際、chain.edgeがそれだなと分かる。因みにこのレコードは、公式のサンプルスクリプトを叩くと生成されるレコードです。内容はただの連番記述してtoyにブロードキャストしているだけです。つまり、公式にもほぼ同じものが記載されています(笑)。

と、眺めていたんですが、これはどうもあれらしい。ブロードキャスト前のbsv.Transactionでできるtxが、txTBLにあって、chainTBLもOP_RETURN的なものは格納していない。...なるほどどうりでpowpingでtoychainを使ってない訳です。あくまでtoychainはブロードキャスト前まで処理して、任意のタイミングでpushしてねってとこまでのものらしい。なので、OP_RETURNにいれるべきデータは別で自分で持っておいた方がいいっぽい。うーん、セカンドレイヤーはこの時は意識してなかったってことになるな...推理してもしょうがないけど。

どうりでGETが弱い訳だ。アップする前に参照して使うとかそんな想定してないと...。と、いうことでsqlite toychainはあくまでBCに上げるためのDB達でaddして、アップしないならaddのデータは自前で保管しておきなさいと。これだと、DBにぶっこんどいて、お好きにmbでアップしなさいとかわらなくね？どうする？

ちなみにtxTBL

id: toyのtx|
tx: ブロキャス前のhex(tx)|
genesis: 0|
sent: 0

genesisってのが上げたか、上げてないかみたいな。結局実行して試した人しか伝わらない書き方になったな。

DBを作る
# sqlite3 project.db
テーブルを作る
> create table user(id integer primary key autoincrement, type text, type_id integer, name text, mail text, avater text);
テーブルを確認する
> .table
> .schema
sqliteを抜ける
> .exit

エンジニアも触らない toy chain の世界

toychain
まえがき

sqliteなんて触る機会すくねーんだよ。使ったらまず「なんでsqliteで実装したんですか？」って言われるんだよ。

ほんだい

toy chainっていうものがあります。使用意図がまったくエンジニアをひきつけませんでした。
「自前でテストネット構築できるよ！」
「運営のタイミングでメインネットに上げられるよ！」
その手間、メインネットで直に実装するわ。
テストネットで動いてメインで動かなかったらどうすんだよ。
マニュアルあるけど、これメインでやってた方法まんまつかえるわけでもねーじゃねーか。

かだい

そうなんです。toyはtoyのまま使い道あるの？っていう臭いがプンプンしててほぼ誰も触ってない。
スラックでも一人だけ質問していました。それだけです。4か月前にね。

さいき

powpingが誕生しまして、セカンドレイヤーみたいなもんですよ。なんだこれはと。
世界にただ一つのパブリックブロックチェーンじゃねーのかよと。即座に絶賛してるやつ意味わかってるのかよと。
でもね、つくったことあるエンジニアなら分かるんです、直ちにビジネスしたいならこれは光であると。
bitcoin scriptも序章を執筆し始めたくらい。学んでもおっしゃこれじゃほれみろやーみたいのはできません！
話を戻します。

そうはいってもですね...
「セカンドレイヤーは運営が無料で提供できます。で、メインに上げたい時だけ個人に請求できます。」
これよ、なぜこれをライトニングでやらねーんだと。ここが天才な点です。

まぁもっというと、セカンドレイヤーである必要がない。なんでもかんでもBCだと、なんにするにしても金が掛かる。
これだと無理だから間口広めましょうと。

ちなみにpowpingはtoychainではなく、新たにビルドしているそうです。でもこれtoychainの派生というか上位互換でできています。
これがあの人の頭にあったのか、資本が入って入れ知恵されたのか分かりませんが、非常にいい所をついてきました。

もともといきなりフルは受け入れられない。これは私にも結構皆さんの頭にもあったはずです。
ハーフとか、ハイブリッドなサービスからでないといけないと。

一つにですね。ログインがmbアカウントってパンピーにはもう敷居高いですよ。この辺は頭ブロックチェーンな人は無視しがちです。
無視しているというか最初の作品は極力完全体で作りたいってのもあります。no dbで行きたい。実際できます。

わかりますよね。極力なんでも乗せたいのです。だって、ブロックチェーンのwikipediaです！ってPJTがあったとしましょう。
そこで大事な解説部分は、PJTのサーバのDBにしかありませんって、それワイブロですよね。そこはチェーンに上げろよと。
そして編集出来ろよ、削除出来ろよと...そこまでできてブロックチェーンサービス作ったと言えるエンジニアだろと。

ただこれ、やるとめっちゃレスポンス遅いんです、手数料もわりと高いんです。なので勉強はするけど、時間がワイに追いついてからだなと。
いつものように最先端ひた走っちゃう悪い癖だなと思ってた訳ですよ。

でもtoychainならBCに触れながら、ある程度考えれば無料でサービスを提供できます。課金部分は別に考えることができます。
それじゃこれまでのサービスと変わらないじゃないかと言えますが、コロナくらい大きな動機がないと人って舵取らないんで、その日まではこれ何だと思います。

あとがき

toychainまわりの覚えるためのメモ書きのつもりで雑談で終わってしまった。

なんとなく、ここらへん入れてる。 react歴 2ヶ月

nextjs reactjs nodejs

npm install -g npm
npm init -y
npm install --save react react-dom next
npm install

npm i next-compose-plugins
npm i eventsource
npm i next-iron-session
npm i isomorphic-unfetch
npm i router
npm install @material-ui/core --save
npm i @material-ui/lab
npm i material-ui-popup-state

npm install --save @tinymce/tinymce-react
npm i react-device-detect
npm i -S sqlite3
npm install react-hammerjs --save
npm i sse
npm i -g pm2
npm i react-copy-to-clipboard

こうメモ書きするより、package.json保管してnpm installすればいいんだなと思った2か月目。

なぜ AUTHOR IDENTITY PROTOCOL (AIP)が本人である証明になるか

moneybutton AIP

他所のこの人だなーこのコンテンツだなーっていうAIPをコピってですね。まるまるOP_RETURNにぶっこんでもそれ本人と言えるの？？って単純な話です。AIPぶっこむ分データ量かかるわけですよ。

もちろんそんな誰でも思いつく偽装で問題でるはずないんですが、だと思うという理解で実装してもあたまおかしいので勉強することに。

AIPはルールで、肝はここ

[Signing Algorithm]
何のアルゴリズム使うの？

[Signing Address]
どのアドレスでそれしてんの？

[Signature]
その結果の著名はこれ

です。

アルゴリズム BITCOIN_ECDSA とは

BITCOIN_ECDSAでやる。それはマネボのbsv.jsでできる。
docs.moneybutton.com

privateKeyとpublicKeyがあります。秘密鍵と、公開鍵。sshと同じですね。

何らかのデータを秘密鍵を用いてECDSAで暗号化します。で、公開鍵で検証するとこれは正しいと判定できます。

どうやって判定するなどの理論はすっとばして、それを検証するプログラムがあるんです。

  • bsvには、bsv.crypto.ECDSAの署名と検証を含む、ECDSA と呼ばれるオブジェクトがあります。
  • 最も重要な2つの方法は sign、およびverifyです。
  • 署名を生成するには、秘密鍵とデータが必要です。
  • 署名を検証するには、公開鍵、署名、および検証するデータが必要です。

AIPのルールに従う必要があるのか？

暗号化と復号化以外にアドレスがあると、復号が万が一解かれてもそれがネックになる？...のであればまぁ分かる。でも出どころの保証ができてなくね？つまりAIPの形式が必要最低限って訳ではなさそう。

まるコピして本人になりすまして偽装txしたらをどうすんの？っていう問題はこの投稿内容をキーにしていればほぼ偽装防止できる。やっと合点いった。ずっと後回しにしていた。逆にそれをキーにして、ECDSAを発行することは最低必須条件になる。

あとは検証してみれば分かるけど、データ量に応じてECDSAも長くなるのかなぁ？ってこと。普通に考えるとそうなる。となるとデカい画像や動画にはまだコスト面で厳しそうだなぁ。

ちなみにほぼ偽装防止と言ったのは、発言内容を偽装してなりすますケースは防止できるけど、発言まで同じにしたら本人の発言として別のところに生むことができてしまう。これで困る事ってあまりないけど...だからSigning Addressをキッカケにするのかな？これがあるとどこの誰が著名の仕組みりようしているかアドレスで追いかけれて、「いや、それうちだけど、こんなところにtx残さないよー」「だったらこのtxと同じ著名を作ってみせてよ、あなたが本物ならね？」って確認取れるって話？それならすごいな。結局AIPのカタチがベストかも(笑)