ヌンタコのプログラミング学習ブログ

フィヨルドブートキャンプ37期生

1月振り返りと2月以降の学習の動き

1月の振り返り

ポートフォリオマークアップで作ってました。レスポンシブスタイルもある程度つけてきた。 あとは微調整も必要だし都度修正→追加でgithubにプッシュしていく。

マークアップは変化が目に見えるので楽しいな〜と思いながら、 まだsassやらjQueryやらは手付かずだし、 FlexBoxはシンプルで考えやすいけれどレスポンシブデザイン考えたら、 Bootstrapの方が良かったのかな?

なんて揺れたり。

表現の仕方によってどっち使うのか決めた方がいいかもしれない。

でもそれなりに作れたのでちょっと嬉しいというのが本音です。

いつも計画なしで作っていくのでデザインカンプは今後作ろうと思った。 Figmaを使う予定。来月からはちゃんとします。

2月にやること

もう2月ですがとりあえずお問い合わせページの設定であるとか細かい点を修正しつつ、 サイトデザインの制作物を作っていこうと思う。

1ヶ月ひとつ作れたら良いけれども、そこは計画立ててやってみよう。

そもそもマークアップに戻ったのはsinatraのデザインを整えるためだったのを忘れてはいけない・・・

年間での計画

デザインが一番とっつきやすいので、ひとまず年間計画としてはこう。

  • 1月:ポートフォリオデザイン作成
  • 2月:Webサイト制作① 
  • 3月:Webサイト制作②
  • 4月:WordPressテーマ作成
  • 5月:一人反省会 Ruby
  • 6月:Rubyの学習 思い出すところから・・・
  • 7月:データベース ←試験対策期間なのでできないかも
  • 8月:データベース
  • 9月:Sinatra
  • 10月:Rails
  • 11月:またまたアプリを作る
  • 12月:がっつりアプリを作る💪

めちゃくちゃやりたいことある・・・ ダメダメ。 ちゃんと完結させてから中休み的にちょっと触る程度にしよう・・・。

先が長い

できたら今年の秋ごろにFBC復活したいけど、まだまだどうなっているかわからない状況。 やっと補助金の申請書を書き終えたけれども審査に通すので採択するまで時間もかかる。

あと事業が上手く乗るかもわからないし1年で全くダメなら資金が底をつくので ポシャったということで撤退して転職活動でもしなきゃな〜と思ってる。

しかも今年厄年・・・

今月もやれることを進めていく💪

本屋は楽しい

技術書とか買おうかな〜って迷ったら本屋行くし、 ネットですぐに買わない、電子書籍も自分には合わなかったので紙がデフォルト

なんとなく知りたいな〜というレベルのものは立ち読みで吸収できるのでとてもありがたい存在

ただ田舎のよくない点はちょっとでもニッチ寄りなものになると扱ってない。

田舎と都会の大きな差を感じるのは本屋です。 いつも旅行先で思います。

本屋の数は少なくていいので種類は豊富に取り扱ってほしい〜

愛媛のジュンク堂三越の最上階に移転してから かなり小さくなってしまって、悲しい。

「ちょっと読みたいだけなのに」が叶いにくいのが田舎ストレスかな。

今年の予定はこんな感じ💡

自分のポートフォリオを作ってみる①

遅ればせながら明けましておめでとうございます。

sinatraアプリ制作をしていくと、「あれ?かなりCSS 忘れてる・・・」と思ったので html/cssの勉強がてらドットインストールをずっとやってました。 jsで動きを追加するところまで進んだけれど、まだまだ理解しきれてないところも多いので、 一度自分で制作物を作ってみることにする。

制作の流れ

sinatraでの制作物

ひとまずsinatraの制作物もこのポートフォリオにリンク付けして表示できればなあと思う。

FBCを9回してから来月で半年になります。まだまだ再開の目処は立たないけれど、 ひとまずできることを継続するつもりです。

ラクティスがデータベース設計で止まっているので、その辺りの学習も含めてsinatraでデータベースの動きを見たかったのだけど、 そもそもリレーショナルを組んでいない。一気にやると絶対わからなくなるので・・・

なのでsinatraでの流れとしてはこうだった↓ 1. sinatraでアプリをつくる 2. 利用者管理アプリなのでデータベースを使う 3. データベースの挙動がわかる 4. もう一度ER図を考える

という当初の予定から 3.にいく手前で、「デザインがよろしくないな・・・」となりだす。

そしてhtml/cssに至る。

なのでプログラミングらしいことが全然できてない。 デザインがある程度できるようになったらまたrubyとデータベースの学習に戻りたいと思う。

というわけで学習の流れが、

  1. sinatraでアプリをつくる
  2. 利用者管理アプリなのでデータベースを使う
  3. html/cssの学習
  4. html/cssでのポートフォリオの作成
  5. jsをつけるならつける
  6. データベースの学習に進む
  7. rubyの学習に進む
  8. もう一度sinatraでアプリを作る

毎日草チャレンジしてるので小さな動きでもこの流れで学習進めていきます。

最近の動き

  • 2022/12ごろ sinatraで利用者登録アプリを作ってみる

    • メインの動きはできたけど細かな点 編集後確認アラートなどがまだまだ
    • ここでデザインスキルが全然ダメだとなり、html/cssの方の学習に戻る
  • 2023/1から html/cssを学習

    • 一通りの動きを確認する flexboxのルールがまだいまいちついていけてない
    • bootstrapはノータッチ

ポートフォリオにサイドバーつけたいのだけれどうまくかかってくれない。親要素とか子要素など区分けが曖昧なのでその辺り復習しないといけない。

365草CHALLENGE

そしてにしめさんから頂いたハッシュタグ365草CHALLENGE」を継続する。 iPhoneに人工芝を作るぞ💪

github.com

制作物を載せてないのでこれだと履歴書・・・ まだまだ載せてないことたくさんあるけれど、人まずこのポートフォリオを充実させていこう。

2022年のふりかえりとFBC参加&復帰できない

もう12月31日ということに驚きを隠せない・・・汗

プログラミング学習もやってたけど他にも同時にやってた学習やボケーっとしてたところあったので反省もしていこうと思う💪

フィヨルドに3月から参加

今年の3月からフィヨルドブートキャンプに参加した。

初めのうちはサクサク進んだし、詰まったSSH接続も深く調べるきっかけになったのでよかった。 いまだに通信できなくて設定し直す時もあるけど。。。

一番詰まったのはlsコマンドの4,5とかwcコマンドだった。

挙動がそれらしくなれば・・・がなんとか自分が構える低ハードルのゴールで、リファクタリングをやれるほど余裕がない感じ。 後で正解見て「こう書けばいいのか〜」ともなるんだけどリーダブルコードが一朝一夕で身につくわけもなく、ひとまず出して指摘もらってから考えるぐらいのスタンスでいってた。ただwcでは本当に苦戦しまくってた。

とりあえず動くがギリギリのゴールラインの状態だったので、指摘事項についても文面からどんな感じに受け取れば良いのかわからない・・・コミュニケーション下手がもろに出る。

学生の時からそうである一定の文面は本当に汲み取れないというのが自分でもわかってる💦

相性もあると思う。

でも指摘の内容からしたら、リファレンスを浅くしか読んでいなかったことが弱点として出てきたのだけど、メソッドの挙動が掴みにくいものも多々あるわけで。 オブジェクト指向のフェーズは絶対これ以上に苦戦する・・・と感じていた。

ちなみにwcだけで嫌になったのもあり、このプラクティスだけに1.5ヶ月か2ヶ月ぐらい費やしていた。

そして次のプラクティスのデータベースについてはER図がうまく書けない。

データベースというもののコード上での使い方もいまいちイメージできなかったので、どうしていいのか困った。 大きな収穫としては9月ごろにリレーショナルデータベースとしての考え方、多対多(N対N)の関係なら中間テーブルを設ける。というのがなるほど!となった。 このわかった!感覚を得るまでに1ヶ月かかる。

文字ではわかったつもりでも、作ってみるとどうしてもカラムに何個もデータが入るという錯覚が抜けない。妙なバイアスがついちゃってる自分に驚く。

ツイッターのフォローフォロワーの関係もどちらかのプライマリーキーを参照してアカウントを見つけるというのもどういう構造になってるんだ?という感覚だった。中間テーブルも要らなかったわけだけど、休会してからわかったことが色々ある。

フィヨルドブートキャンプではプラクティス進捗が自分のも人のもアイコンで簡単に終えるデザインになっているので、序盤はそれが自分の学習ペースの基準やモチベーションにもつながってたのだけど、詰まったプラクティスがあって同時期か自分より後に入会した人がサクッと次に進んでいると正直凹んだ。しょうがないのだけど焦る→凹むの繰り返しが多い。進捗見える化はメリットデメリットあるので使い分けた方が良いと思う。見えないようにするボタンもしっかり実装されていた。

比べてもしょうがないのだけれどこればっかりはしょうがない。さらにほぼ伴奏状態で並走していた人がフッといなくなったりストップしてるとあれ?ってなる。休会や退会はしょうがないのだけれど寂しさはあったりする。コミュニティ感強いところのデメリットサイドかもしれない。仕方ないけどね。

こんな感じで目的がブレている時期だと思うので立ち止まっても良いと思う。 そして3月から8月まで続けたけど9月に休会申請を出す。プラクティスはデータベースのところで止まってる。

そして休会したまま今に至る。

休会して復帰してない理由

シンプルに学習費が捻出できない💦

あまり稼いでいない個人事業主ですが来年事務所を構えたいと思って試算したり物件を見てて、どうしてもプログラミング学習費用は無理だな・・・と判断した。

フィヨルドブートキャンプの学習費用は確かに安いけれど、ある程度のベースがある人からすると安いという状態になると思う。

ということで、

  • 事務所の家賃や経費の捻出
  • 学習費用支出のストップ

が一番大きい。

収入増やせば良い話では?ともなるのだけど、時間切り売りしていることに嫌気がさしてきたのもある。 贅沢な悩みなのだけど。

あとここでの目標が就職ではなかったのでそれもお休みしようと思ったきっかけになる。

2022年に終わった学び

実は8月ごろにそれまで続けていた通信制大学を卒業した。

厳密には大学には学生の頃通っていたのだけれど、その時に教員免許は取ってなくて。開業するにあたって、やっぱり教員免許あった方が箔がつくというか自信がなかったので取っておこうと思った。また数学メインで教えているけれど、数学が好きで数学の免許とった先生は「いい先生・残念な先生」と分かれるなという印象もあって、あえて自分の苦手な社会の中高の教員免許を取った。

数学は自分が解いて楽しい、というのが一番あるけれど、社会系は自分が語って楽しい。というのがある。ただ日本史(平安とか戦国までの時代)は本当に嫌いで免許とったにも関わらず覚えられない。自分でもあんぐりしてる・・・

理由はわかっているけれど、本当に興味ないんだなあと自分のことを思った笑

「大学通っていた頃に取っておけばよかったのに(経費的に)」と母にも言われたのだけど、そうだよな〜と思いながら思い出してみると・・・

そもそも実習に行く3回生ごろから4回生が学生生活でピークに忙しいタイミングだった。

  • 研究室での実験
  • 就活
  • 日商簿記の勉強
  • バイト
  • 仕送りストップ

同時並行で全部やってたので擦り切れてたのでここに「就活 NEW! ⇦」みたいにタスクをプラスすることはできなかったなと。

私の大学通っている時期はトリドール丸亀製麺が本格的に四国進出する頃だったので年末に丸亀製麺が釜揚げ(並)を100円で出すというかなり攻めのプロモーションをしていた。

仕送りなくて擦り切れてた頃は一日おにぎり一個でなるべく動かないように(とは言っても大学とバイトと行くのですが)して100円握りしめてうどん食べに行ってた。

日商簿記の2級まではストレートで取れたからその後は精神的にかなり楽だったなあ。

実は仕送り止まったのでこっちも苦労してたけど実家もかなり苦労していた。母と妹はお粥の時もあったそうなのでリーマンショックの余波が遅れてやってきた年だった。

このままじゃダメだな

話は戻るけども、FBCで「就職」を目標にしていないのであれば本気度も他の参加者と雲泥の差があるので、自分のペースで好きなようにやろうと思った。

ダラダラ続けてもサブスクなので支出がダラダラ流れてしまうなあと。

金銭的にと精神的に余裕ができたらまた復帰したいかなと思う。

今から参加しようかなと思う人に(ガチ回答する)

お正月にフィヨルドブートキャンプは体験が1週間あるので利用すると良いと思います。

そしてこれは言っていいのかわからないけれど、活用の仕方として色々書いておきます。

  1. FBC1週間無料体験に参加
  2. ラクティスは順番通りやらない
  3. 全体の内容を把握する
  4. ドットインストール・progateなどを網羅しておく
  5. FBCに入会

この流れが一番効率良い気がしてならない。(ソースは私!🌱) あとやっておくと良いと思うのはsshとかgitあたり。 そしてlsコマンドあたりを触れておくといいと思った。

この順番の理由

正直この順番にした理由としては、全く触れたこともない人がここに入ると、

  • 一人暮らしで仕事と並行してやっている人:3年以上 
  • 実家暮らしで仕事やってない人:2年

就職を目標とするとこのくらいは最低かかると考えても良い気がする。ソースは私だ!ごめんなさい🙇‍♀️

そして程度問題でもあるけどプログラミングに触れたことがある人がやると

php,javascript,rubyあたりをやってた人 仕事しているしていないでどのくらいの影響度か測れないけど1~1.5年イメージ

Java,C#,C++とか高等言語いじってた人 1年以内卒業もあり得るかも?チーム開発と卒業制作の進捗によりけり

こんな雰囲気で捉えています。何度も言いますがソースは私なので確信はもてない🙇‍♀️

全く触れてこずに入るとなると手取り足取りなところではないので「自分の足でやりなさい、ちゃんとヘルプ出したら対応しましょう」という印象なので、高い評価を得ている。

そして全く触れてない→要はマークアップjavascriptとかフロントサイドも全くという場合は、3年は見た方が良いということなので結局100万以上かかる計算になる。

2年で72万くらいかな。

確かに安いし融通が利きやすいところだけれど、自分にとっても無理ない範囲かは検討しておいた方が良いと思う。多少の知見があってから入会した方が疑問が出た時の検索力も上がるし、一つの知識から数珠繋ぎであれもこれもと連想してわかることもあるから。

なので全く触れてない人はweb制作全般をドットインストールとかプロゲートで模写・オリジナル作ってgitに草生やしてから入会すると一番出費が少なくなるかも?と思ってる。

ある程度全体の流れがわからないと動けないというのが私なので、同じタイプの人ならこんな感じで進めても良いのでは?と考える。

多分ワードプレスのテンプレ作った経験無かったら私もこの期間でデータベースまではいけてなかっただろうな・・・と感じている。苦戦したプラクティスはいくつかあるのでなるべく最初の段階では達成感が得やすいペースが維持されるといいなと思う。

作り続けることはやめたくない

休会してしまったけど、作ることはやめたくないわけで。自分で考えたサービスを自分で作るという活動は楽しいわけで。 今も正直データベースのプラクティスに飽きてしまって(ごめんなさぁああぁい💦)sinatraで自分が考えたアプリをいそいそ作っているわけです。

挙動もぎこちないし、まだまだ改良点がいるけれどそれでもデータベースを組み込んで自分で作っているものができてちょっと達成感。

楽しいなと思う。

そしてgitでサイト公開する方法を発見したのでなるべくちょこちょこ草を早していく予定。

休会した人向け(?) になるのかわからないけれど、にしめさんが運営するRESTUDY cafeには長くお世話になりそうな。

プログラミング興味がある人は行動力ある人も多いので、こういったコミュニティ運営してくれる人もいてホントに助かる〜

就職を目標にしなかった理由

  • 個人事業主で教育から離れたくない
  • 二足のわらじスタイルの働き方が奨励されない
  • そもそも愛媛に求人ほぼない

シンプルに求人格差は地域でかなり色濃く出るわけでして。

就職を目標にしても結婚してて県外に出られないのでNGとなる。 ruby求人がないこともないけれど、100あるものから1選ぶのと、ギリギリ10あるものから1選ぶのは違う。

あと通うとなってもかなり遠方にしかない求人ばかりで断念。

在宅の働き方が可能なのは現場力ある人だけなので、そうした経験はどこかに出勤スタイルで勤めてからじゃないと難しいわけで。

あと田舎のいいところばっかりメディアでは出るから住んでるものからネガキャンすると四国で一番閉鎖的なのが愛媛だからね! なるべくそうじゃないコミュニティに所属したりノット愛媛感な人とお付き合いするのが移住者の鉄則です! 移住者同士のマウント合戦は聞かないのでそれはあまりないと思う。

ソースは私のプログラマーの友達だ!こっちに数年移住してました。 旅行ならいいけど深く考えず移住してきたら傷をおうので、こんなタコでよければいつでもメッセージください。 移住したい人に全力で寄り添うよ💪

移住ダメージ負わせたくないもの。

来年の目標

無計画性と自分のハードル上げに行ってますが、失敗は毎年やっとかないと歳とって保守的頑固お化けになっちゃうのでやることはやってみよう💪

今私をヨイショしてくれる人がいるコミュニティで温室育ちなアラサーになってるので、バランス取っとかないと裸の王様になると思ってやってる。

生涯学習がもっと浸透してくれればいいなと思ってる。

来年は不格好でも頑張る💪

webアプリ作りがちょっと煮詰まる

ちょっと煮詰まってるけども、頑張ろう💪

煮詰まっている内容

  • 検索フォームの処理をどうつけるか?
  • 削除の確認ウィンドウのjavascript分岐

主にこんなところ

進めていくTODO

前のブログの内容は書いただけになってしまっているけれど、 何回も同じこと書いていたらすみません・・・。

  • 個人情報:住所、メールアドレス、備考欄の登録
  • デザイン修正
  • githubに草立てる
  • 検索フォームの設定
  • 削除の確認ウィンドウ分岐
  • ユーザー一覧をidの番号順に並べる

流れをまとめておく

検索フォームの流れ

ユーザー側の見かけ上の流れ 1.検索idを入力して検索ボタンを押すと 2.内容に合った個人情報が表示される

制作側での流れ 1.入力フォームと検索ボタン:デザイン 2.入力されたidをinputタグのnameとかに格納 3.id番号のデータをデータベースと照合させる処理:ruby 4.登録なかったらnot foundページ、あったら一覧に表示させるページ

かなりざっくり。 データを渡して処理するところが大変。

削除の流れ

  1. 削除confirmはjsで作ってある 2.削除するかの確認ではい・いいえを選択 3.「はい」なら削除してトップページへ 4.「いいえ」なら何もせずにトップページへ

この条件分岐はjavascriptでやりたいのだけれど、 /delというルーティングをrubyでやってて→削除する作業 htmlタグで<form action="/del">→ボタン押したらrubyのdelete作業実行

という流れをすでに組んでしまっているので、 /delの作業をするかどうかをjsの中に入れたい。

これが結構詰まってる。

前回詰まってたcssがかからない問題について

階層が問題だったみたい。 paramsでidを押すと個別ページが表示されるようにしていたので、 /mypage/:idでerbファイルが表示されるようにしていた。

cssファイルのある階層は/public/style.cssに対して、 mypage.erbならhref="style.css"でよかったけども階層が/mypage/:idでは もう一つ下のイメージになるので、相対パスで指定してあげることで解消した。

このサイトが参考になった。

teratail.com

他にもあったのだけれど間違えて消してしまってどこのサイトかわからなくなった💦

課題は細分化して考えることにする💪

今作ってるアプリの概要_自分用まとめ

結局sinatraの前回のエラーは原因がわからないままで放置してます・・・。 厳密にはどうすればエラー解消されるかはプログラマーの友達が見つけてくれたけれど、

  • デコードして取得できたパターン
  • できなかったパターン

の違いがわからず放置してる。 というかここのメソッドだけの知識じゃ足りないので、 ちょっと気分が乗らないので放置してる・・・

ということでひとまずデータベースを使ったアプリを見様見真似で自分用に作ってみることにした。

sinatraの著書に沿って模写してみる

ルーティング 簡単な掲示

この二つがあったのでどんな感じでリンクしているか動かしながらみてみる。

ふむふむ。

wordpressphpみたいにerbはパーツ分けできるんだな、と納得。

layout.erbは全ページに使えるところまでのフレームにすれば良いな。 データベースのデータを扱えるようにしないとなあ・・・

とか色々課題が見つかりまして、ひとまず自分のアプリの設計図をアナログで作ってみる。

作りたいもの

作りたいものはベースはとてもシンプル。

来年以降で塾開業する予定(あんまり塾っぽくないのだけれど) なので、そのサービスの中で利用者登録システムを作ろうとしている。

不登校の生徒や高齢の方など孤独問題に対応したサービスをやりたいのでそういった人たちのデータベース。

とはいえデプロイするつもりではないので、毎回立ち上げて登録して、ローカルでのみ動かす予定。

ということでつけたい機能は以下のような感じ

  1. 登録者情報の登録→できてる
  2. その情報の削除と削除確認ウィンドウ→できてる
  3. 登録者の個別ページの表示とその情報の編集→できてる
  4. 登録者一覧ページ→できてる
  5. IDの設定(自動がよい)→まだ

自動のID設定ってなかなか考えること多くて難しいなあと・・・ 順番に登録順に番号が付与されるだけならなんとかなるけれど、 例えば順番に1~10登録して6番の人が退会した場合、次に登録される人の番号を11番とするか、歯抜けになった人のにするか・・・。

過去データとの整合性を取りたい場合は歯抜けはスキップして最新の番号を付与していった方がいい気がするね。

となると現在の全体の登録者数も必要になるなあ。

とか色々考える。

まだまだ課題はある

  • さっきの利用者登録の通し番号の扱い方を検討する
  • デザインが汚いのでCSSで手直し
  • 登録者の情報をどこまでつけるか
  • 念の為ログイン機能をつけておきたい
  • IDや名字での検索機能

正直自分しか使わないけれどそれなりに使えるものを作っておきたいので、検討する。

データベースの情報を指定したページに表示させること、 個別のIDを入力して個別ページとして登録者の詳細情報を開示できる。

せっかくベースができてきたのでもっと作り込もう〜

Base64.decode64がMarshal.loadできないと怒られている

ここまでやったこと

sinatraの練習だと思って、こちらの書籍に沿ってwebアプリの作成をもくもく進めた。

で、この書籍の7章、cookieの使い方でつまづく。

何をした?

人とおりやっていることと詰まっていることはteratailに書いてみた。 解釈が合っているのかは自信がないけれど、 なんせ自分でできる範囲のことは調べたけれどお手上げ状態。

teratail.com

そもそもMarshalやencode とdecodeについて

エンコード・デコード

クライアントとサーバーのHTTP通信のやり取りで、1回のみのやりとりをセッションという。 そのセッションを継続して行いたい場合というのは例えばネットショッピングをしたときなどである。

ログイン情報を保持しつつ、色々な商品のページにアクセスする。 商品を購入するときはさまざまな商品ページの情報を一つのアカウントに紐づけて通信履歴を保持しておく必要がある。 それをセッション継続という。

このセッションを継続する際にはセキュリティ面を考慮する必要がある。

すごく色々端折るけど、通信やり取りを安全に暗号化させてしたいよね、ということで本番ではSSL環境を構築する。

けれども。SSLの概念理解として暗号と暗号解読キーのセットで情報を読み取れるような通信環境にしたいですね、試しにやってみましょうか。 という流れからエンコード・デコードの話に進む。

tech-unlimited.com

読むより実際に使ってみたほうが早い。

Marshalデータとは?

docs.ruby-lang.org

考えられる問題・・・

多分ASCII文字じゃなくてUTF-8になってるのが問題かなと思っている。 ただASCIIに変換する方法を模索中。

しかもこれが解決策にならないなら「詰んだ・・・」ってなってしまうかもしれない。

もしくはsessiontest.rbcookie値がうまく引き継げていないかとも思い出した・・・。

ほんと詰まるとずっと詰まる

これは長期戦だなと感じている。 早く脱出したいな^^;

Web3とNFTの仕組みと何が流行ってるのか?

最近よくWeb3とNFTという言葉を聞きます。

 

 

そもそもわかってないので、しかも横文字なので、わけわかめでした。
が、なんとなく仕組みと繋がりが見えたのでメモっておく。

 

まずWeb3とは?


これまでWeb2とか出てきてその流れで3がでた。スプラトゥーンみたいな、アップデート的な感じで捉えて良さげ。ただWebは中身が色々違う。

 

これまで情報がYやGのサーチエンジンの最適化▶︎ターゲット層にフィットした広告・マーケティング▶︎それって情報が一箇所に搾取されて独占状態かつ中央集権的じゃないっすか? と技術高い系の人不満。

 

とまあこんな感じで、政治云々で例えると、
🐙:「地方分権がデジタルというかネット社会でもおきつつあるってイメージ?」
友達:「うーん、そもそもそれでも県とか市による中央集権になるよね?」
🐙:「なるほど・・・じゃあもっと末端にも参画できる機会を?的な」
友達:「そんなイメージでとりあえず大丈夫🙆‍♀️」

 

Web3の背景はこんな感じで、情報の一極集中搾取を避けたいし、全てがそこに集約されてしまうとコントロールされてるよね?という問題から。


情報操作により傀儡化されるのを個人レベル・コミュニティレベル・国家レベルでも避けていきたい。ということから。

ふんふんなるほど。すっごい共感。

 

じゃあ仕組みは?

 

基本的には2点。

 

大量のデータを複数個のパッケージングして個人なりコミュニティなり起業単位でもつ。その大元の大量データのまたパッケージングしたものを他の人も持ってる。


そのパッケージ内部で他の人と重なる部分ができる。要は鎖のごとく共有している情報をそれぞれが持つことと外部に見える化、開示していることで改竄されないデータになっているというイメージ。

 

DBのリレーショナルが効かない状態のデータと言えば良いのか、誰かがとあるデータに変更を加えた(仮に改竄としよう)としても、他の人のデータに影響を与えない。

 

なのでやろうとすれば他の人の同じデータベースと整合性取れないのですぐに、「オタク、なんかいじりました?」ってなる。

 

ブロックチェーンと名前がついているので鎖のブレスレットのイメージでしたが実際はマインドマップのような状態で繋がってるイメージ。

 

そしてNFTとの関係性は?


ほんとね、ピンと来なかったのがここなんだよね。

インスタグラムで出てくるNFTは投資や株、仮想通貨の類で儲かるよ〜なイメージで投稿が流れてくるから、他のネット記事を見てもピンと来てなかった。

 

ここで自分の中でバイアスがかかってましたね。
インスタ見た直後、
・NFT▶︎投資系の新しいやつ?
ネット記事見て
・NFT▶︎なんかWeb3をつかってうんたらかんたら・・・

 

????ってなった笑 あまりにも先行イメージと乖離があってリンクしなかった。

 

友達に聞いてみた


上記のことを友達に聞いてみた。聞いたことはあるけどわからないって言ってて、取り合えずネット記事読んでもらったらすぐにわかったぽい。IT知識あるのと変なバイアスかかってないのですぐに噛み砕いて教えてくれた。

 

NFTが注目された背景として


これまでツイ民などの絵描きさんはデジタルコンテンツだとパクリ・コピーされまくる。損をしていたと。まあ著作権がガバガバで保護されてねーやん!という電子データには問題があった。魂を込めた創作物を、金儲けのために努力もなしにコピーして販売する輩がいてなんだか虚しく悲しく憤る。というのをネット絵師さんは感じていたそうな。

 

じゃあこれがオリジナルでコピー品ではない証明をネット上でできれば良いのでは?
ということからWeb3の技術が注目された。

 

唯一無二を証明するNFT
デジタルな創作物に対して、
・この人が
・この日に
作ったことを
・第3者が
・その事実を
・証明するよ〜

 

ということがWeb 3のブロックチェーン技術で可能なんだそう。

それはいいね!👍

要はこの証明書が発行できることで、アートとしての取引が可能ともなる。
この絵は一枚しかないんだよ、やっと落札したんだよ。という絵画オークションがデジタルアートに対しても可能となる。という素晴らしい技術であると。

 

そういったことが転じて投資対象になってることもこの流れからインスタでNFTを投資対象として紹介している投稿が流れている。
というかんじ。

 

この中間付近の流れがすっ飛ばされてたので繋がりにくかったけど、よくわかった。
なので、NFTによってデジタルアートの購入ができることは、大富豪が金やアートに資産を変えることにデジタルアートも加わる
持っているデジタルアートをオークションに出すこともあるだろうって考えるとメルカリの逆が起きるのではないかな?

 

メルカリの逆っていうのは勝手に考えたのですが、新品で買ったものをAさんがメルカリで売る。それをBさんが安く買う。さらにBさんはいらなくなって中古の中古としてさらに安くCさんに売る。これを繰り返すことで価格の下り坂になる。ただNFTはその逆で、取引を繰り返すことで利鞘を得るんだろうな。と。売って買ってを繰り返す。

 

でも作品がでたタイミングでその将来性なりニーズなり、熟知した上で参入しないと逆に損をするだろう。アートとしてではなく投資対象として考えるのみであるならば。


そんな考えです。

 

やってみなよの一言

友達は「なんかあれも描いて出してみたら?」ということで、一つ試しに出してみようかなとも思う。

OpenSeeってとことかNFTの取引できるプラットフォームは色々ある。個人でも全然参入できるし、ブランド価値が認められ出したら徐々に値を上げていくことで副業なり専業になったりする。

 

とのことで、アウトプットは些細なことでもいいからしたほうが良いですね。

 

参考:

https://www.ecbeing.net/contents/detail/318

 

URIの設計を考える

丁寧に学習しようと決めたのでかなりスローペース。

とりあえず基本ルールなどを学ぶ

https://qiita.com/NagaokaKenichi/items/6298eb8960570c7ad2e9

たちまちはこんな設計のサイトに遭遇。

そしてHTTPメソッドに関してはこれらのどれに当たるか、リソースがわかりやすく明示されているURIを設計する必要があると。

httpメソッド 何をするの?
POST 対応するURIをリクエストし、リソースを作成する
GET リソースを照会して、当該ドキュメントの詳細情報を取得する
PUT 当該リソースを変更する
DELETE リソースを削除する

そして基本ルールとして、

  • アンダーバーは使わない
  • 小文字でお願い
  • ファイル拡張子は含めない

などがある。

インターネット層

階層 どんなのがある?
アプリケーション層 HTTP,NTP,SSH,SMTP,DNS
トランスポート層 UDP,TCP
インターネット層 IP
ネットワークインタフェース層 イーサネット

ステートフルサーバーとステートレスサーバー

ステートフルサーバーな状態

この前こんなことがあった。ランチを食べにちょっとおしゃれな注文式バイキングのところに入ったら60代ほどの女性2人がオーダーしていた。

ディスプレイに20種近く並ぶおかずを自分で5つ選びワンプレートに盛り付ける。

A:「私これとこれと・・・。」 B:「私はこれとこのカボチャのやつと」 A:「それからこれも!」 B:「やっぱりさっきのカボチやめて,こっちに」 A:「それからこれと・・・アイスコーヒーと,あと何品だっけ?」

・・・

いっぺんに言え!

てなる。

これがステートフルです。

途中の状態をサーバが常に覚えてないといけない。

ステートレスサーバーな状態

同様の状態で奥様方をステートレスにしましたら,

A:「私はこれとこれとこれ,あとこれとこれ。そしてカフェラテでお願い。」 B:「私はね、これとこれ、あとこれ。そしてこれとれ。アイスコーヒーをお願いします。」

一つの会話ですみますね。

提携文に沿って1クライアントから注文を全て受けるイメージ。 一発で言ってくれるのでサーバはアプリケーション状態を保持しておく必要がない。 便利!

ただ欠点もある

ステートレスの欠点はパフォーマンス低下が挙げられる。 理由としては、 - 送信するデータ量が多くなる - 認証など、サーバに負荷がかかる処理を繰り返す

アプリケーション状態を保持しないということは全てきっちり承るよ、だからその分は一回の送受信が大きくなるから、クライアント数が多いとしんどいな〜という印象。

HTTPって何?

HTTPメソッドではクライアントが行いたい処理をサーバーに伝える任務がある。

8つあるけど前に主要な4つは書いたので省略。

前回の記事の続きで細かいところを見ていくと、

POST

GETに次いで利用頻度が高いメソッド。 代表的な機能は、子リソースの作成。

#リクエスト
POST /URIの直下のディレクトリとしてこの名前で作成してね HTTP/1.1
HOST: ホスト名.com とか
Contents-Type : テスキトなのか画像なのかなんなのか

内容物をここに書くよ

こんな感じで子リソースを作ります。

あああ、ツイート作成ってこんな感じなのかーとなった。

またデータの追加や他のメソッドでは対応できない処理もできるのでPOSTは結構使うみたい。