xxxさんの備忘録

xxさんのブログです.xxさんはネカマです.

AWSのクラウドプラクティショナーを取ったという話

クラウドラクティショナー取りました。
AWSの試験の中でも最弱ではあるんですけど、取れてよかったなぁと思います。 点数は760点なのでギリギリ寄りではあるんですが。

受験モチベーションとしては

合格の特典の模擬試験と自社が受験費を持ってくれるくれるところが大きかったです

勉強方法としては

Udemyとkindleの模擬テスト集(unlimitedでタダだった)をやりました

www.udemy.com

amzn.to

良かった点としては

  • 網羅的にAWSの機能が学べた
    AWSなんもわからん太郎から、AWSの機能の名前ならなんとなく知ってるものもあるくらいにレベルが上がった気がします。

  • 家でテストが受験できた (PSI)
    英語のチャットで応対するんですが、私は悲しくなるくらい英語が読めないのであたふたしながら受けました。試験監督の人がいい人で良かったなぁという感じです。(あとでしっかり見たらピアソンでも家で受験できる上に日本語で応対してくれるらしい。今度はそっちにします)

  • 合格すると特典が付く
    模擬試験
    無料で模擬試験が受験できるらしい(一段階上のSAAあたりになるとは思いますが)

という感じです。
とりあえず、備忘まで。

【第七章~第九章】失敗から学ぶRDBの正しい歩き方

7.1意味を含んだID(cf:論理ID,スマートカラム)

cf.

7.2類似

「EAV」、「Polymorphic Associations」->『SQLアンチパターン

会員table

id name
1 neko

会員情報テーブル

会員id 属性名
1 age 24
1 hobby game
1 business CRE

このような二つのtableが設計されている場合、

  • どのような属性・値の組み合わせのデータでも保存できる という利点がある

  • その属性名に対する値があるのか

  • その属性名があるのか

  • 属性名と値の組み合わせは正しいのか

  • 属性名の一覧

などは実際に取り出すまでわからない。

また、

  • 必須属性やデータ型が指定できない

  • 正規化されていないために外部キー制約を強制できない

(ex:属性名「都道府県」には「東京」と「東京都」が入る可能性がある。)

  • 属性名を補う必要がある

メモ:

EAVの代価案になりうるjson

Mysql5.7 PostgreSQL9.3以降ではjson型を保存できる という問題が生じる。 ->

  • 汎用性を高めた結果、RDBが本来持っているメリット失っている状態といえる

propertiesテーブル(子)

id name adress 参照先
1 株式会社neko 東京都 shop
2 tako 東京都 user

shopテーブル(親)

shop_id properties_id 従業員
1 1 2

Userテーブル(親)

user_id properties_id 年齢
1 2 25
  • 外部制約キー制約が使えないため、参照整合性は担保できない

7.3仕様変更の際に明らかになる隠された状態について

  • アプリ側では一見して状態を判断できず、仕様変更の際に手間取る

  • バグが起きて不正なデータが生まれた場合には整理が難しい

  • アプリ側で防げないため、DBが無防備(check項目などの制約が入れられない)

  • ドキュメントがない場合は、どのような法則があるのかをコードを追うしかなくなる

  • idの制約を変える場合には大規模なアプリ側の改修を入れる必要が出て来る

7.4RDBには事実のみを保存する->責務が複数ある場合は保存先を分けていく

-> 交差テーブルを用意するのが妥当

propertiesテーブル

id name adress 参照先
1 株式会社neko 東京都 shop
2 tako 東京都 user

(properties->shop)中間テーブル

shop_id properties_id
1 1

shopテーブル

shop_id 従業員
1 2
2 500

(properties->user)中間テーブル

user_id properties_id
2 2

Userテーブル

user_id properties_id 年齢
2 2 32

7.5アンチパターンのポイント

  • 今回のアンチパターンの状態は隠された状態であることが問題だった

  • 中間テーブルを用意することは作ることが億劫なため忌避する人も多いが、「外部キー制約、トランザクションのパフォーマンスの問題」などが顕在化して対策では遅く、元のテーブル設計の際に解決できることが多い(かつ良い)

アンチパターンを防ぐコツ

  • データに複数の意味を持たせない

  • 1つのデータの責務を小さくする

  • 常に状態が見れるように、事実のみを記載する

隠された状態が存在することは、アプリ側にとっても影響があるアンチパターンのため、問題として大きくなりやすい。

早めのリファクタリングを心がける。

メモ: 問題が顕在化してリファクタリングするやつに多い問題のように感じた。

現場で知っていること(設計時に気が付けるか)、(例示リファクタのようなきれいな案を提案)できるようになっていることが

鍵のように思えた。

  • トリガー

隠された状態に近い機能が用意されておりそれがトリガーである。

  • デメリット

  • アプリ設計者や運用者から見えず、振る舞いが予想できない。(永続的に影響を与える場所でトリガーを使う->隠された状態同等の問題を発生させる)

  • メリット(使ってもいい場面)

  • パフォーマンス的メリット

  • アプリ側の実装が大幅に削減できる

  • 既存のアプリの振る舞いを維持したまま、仕様を変更できる

メリットと隠された状態を生むデメリットがある場合は、採用を見送る。

8.1jsonデータ型のアンチパターン

  • 全ての値をjsonデータ型で保存したこと

メモ: 「一番ミニマムな形からできるサービス展開をしたい時」(https://qiita.com/yuno_miyako/items/fad33456d9c32d8f4483)でのコメント欄で目立ったように感じたのが確か「nosqlを学ぶコストが高い」で同じような問題に感じる。 mysqlにも5.7.8以降(?)json型が加えられたそうだが、indexできないなどやはり難しいように思える。

8.2「なんでもjson」の危険性

  • ORMが使えない(jsonを取り出すためのSQLを手書きする必要があり、難しい)

  • データの整合性が取れない(EAVの代案でありながら、問題点がある)

  • 必須属性の指定が難しい

  • データの中身を指定できない

  • ex>yyyy/mm/dd と yyyy-mm-ddは何もしないと取り込まれてしまう。(型を揃えてくれない。)

  • ex>"123456"(文字列)と 123456 は、型違いでエラーが出る。

->データ型で守られていたことが失われる

  • 参照整合性制約を強制できない。上の「データの中身を指定できない」と似ているが、外部キー制約を使うことができない

  • 都道府県というkeyに対して東京と東京都が入る可能性がある

8.3 RDBの責務を失わないためには

  • json型は汎用性を高められる一方でデータを守るができなくなる

それらを踏まえたうえでjson型のメリットを見る

  • jsonそのものに対応している

->「web apiの戻り値」「phpのcomposer(設定ファイルが.json)」の場合など

->データ構造を無視して保存できること

(※RDBではできない設計ではあるが、この条件が必要な場合はRDBMS以外の選択肢も考える。

パフォーマンスやスケーリングに課題が残ってしまいがちなため。->無視できるデータサイズ場合は問題ない)

webapiの戻り値

twitter_account

id screen_name token account
1 akino hoge fallakiakino

twitter_account_detail

twitter_account_id setteings created_at
1 {protected:false,.......} 2021-3-15
  • twitter側は予告なくapiの変更をする可能性があるため戻り値がerrorにならずに保存されている時も対応できるように

  • 必要なデータは正規化し、その他も含まれるjsonは別テーブルに分けることでパフォーマンスの向上と、必要なデータが取れない際にerrorで気が付ける

メモ: webapiの返した値をログのようにjson型で持っておくことで、障害時などに見返せる利便性があるとういう理解でいいのだろうか?

  • os情報
host_id host_name ip os detail
1 host1 192.168.0.1 CentOS {...}
  • 補足

  • os情報にはディストリビューションによって特有のものがあり、detailカラムをjsonすることでディストリビューションごとの違いを吸収している

  • この設計にした理由

  • レコード数が少なく数千程度だった

  • 一度保存したレコードに対してupdateをすることはほとんどない

  • 取り出すときはjsonを丸ごと取得

8.4アンチパターンのポイント

EAVの代替案として出されることが多い(EAVの代替案として優秀である一方でEAVと同じような問題を解決できていない)

EAVからjsonデータ型に置き換えるときはどのような点に気を付けるべきか

  • 正規化することはできないか

  • jsonに対して頻繁に更新を行いたいか

  • 検索情報としてjson内の属性が固定できないか

->1つでも該当する場合はjsonデータ型を採用すべきではない

(jsonデータ型はRDBMSの機能と引き換えに柔軟性を与える切り札のように思うべきである)

  • jsonデータ型の他の使い道

  • レコード->json

アプリ側でループを回すことなく、テーブルの情報を取り出せる

  1. json->レコード

アプリ側から渡されたjsonをストアドなしに適切に扱うことができるようになる

なんとなくだけども2の方法は一度jsonを取得してキレイなテーブルをサクッと作りたい時には便利そうな気がする (1は使いどころがパフォーマンス向上なのでいまいちわかってない。)

9.1 制約に関して

  • ex: email を保存する型にdomainで生成した(email_address型)を使用した ->RFCに準拠してないアドレス(ex:test.@example.com)を弾いてしまった

  • リファクタリングの例  alter文を流して、email_address型からtext型に変更する。  (仮にこの場合のテーブルのindexがemail_addressに貼られていた場合、再構築が実施される。  -> ロックがかかり、長時間メンテナンスになってしまう恐れがある)

9.2似たアンチパターン

  • 外部キー制約(mysql)

    • 子テーブルの更新すると、親テーブルの共有ロックを自動的にとる
    • 対策 排他ロックを取る (排他ロックは正しく順番を待たせるため、パフォーマンスのボトルネックになる)
    • cf>ギャップロック
      • index値を持つ行と行の間にあるギャップ
      • 先頭のindex値を持つ行の前のギャップ
      • 末尾のindex値を持つ行の後のギャップ にもロックをかけることがある(アプリが正しく更新していない時に起きる。パフォーマンスが落ちる)
  • domainに似たenum型(mysql) -> 

    • メリット 表記の揺れを防ぐ
    • デメリット データ型の変更にはalter文が必要 仕様変更に弱い 制約されいる文字列を知る方法が限られている。
  • 状態を持つcheck制約

    alter table emails add column update at timestamp with out time zone check(update >=now());

    • テストデータ作成時 テスト用のデータは常に「update_atが最新日付・時刻のもの」になってしまう。 そのため、update_at を利用した where 句のテストなどに使うテストデータを定期的に作り直す、 が難しくなる

    • 論理バックアップからデータをリストアするとき 元々入っていたデータは更新日が突然過去の状態でdumpされる。 そのため、insertで失敗する。 バックアップからデータを戻す際には緊急事態で理由がわからず慌ててしまうため、弊害といえる。

9.3過剰に制約を掛けないためには

  • 制約と規約

    • 規約 ->バリデーションやFWの機能など

      • デメリット
        • アプリのバグとヒューマンエラーに弱い(->ここを補うのがRDBMSの制約)
    • 制約 ->RDBMSのもの これら二つをうまく使うことが大事

  • データは成長する生き物なので変化に対応する必要があり、製薬は枷になりやすい。 (規約は変化には強いのでアプリ側に持たせる)

  • 制約の段階 |段階 | 説明| |-------------|------| |制約なし | 何でも自由にデータが入れられる状態 |弱い制約 | not null、unique制約、外部キー制約などデータ構造を守るための最低限の規約 |強い制約 | check制約、exclude制約などRDBMSの機能に依存するが、適切に使えばデータを的確に守ることができる  強すぎる制約 | 制約の内容が「システムの仕様」や「ビジネスルール」に基づいて記述されている状態

  • 表の「強すぎる制約」になっていないかを今一度確認する必要がある。

    • DBの設計にビジネスロジックやシステム仕様を混ぜると、アプリケーション改修時に影響が出る。

9.4 制約を「正しく扱う」とは

  • 強すぎる制約はRDBMSの問題点であり、安易に避けると大きな問題を起こす。この制約のバランスについて日々考えていくことが必要

  • postgreSQLの遅延制約

    • postgreSQLには少しだけ楽をするための方法として、外部キーの制約を遅延して評価させる仕組みがある。

    • 外部キーをチェックしない

      set constraints all deffrred;

    • 外部キーをチェックする

       set constraints all immediate;

    tabel作成時等に

    1. DEFERRABLE INITIALLY DEFERRED (-トランザクション開始時からDEFERRABLEモードになる)
    2. DEFERRABLE INITIALLY IMMEDIATE (-set constraintsを使用すると振る舞いを変更できる )
    3. NOT DEFERRABLE (-set コマンドの影響を受けない)
        を宣言する必要がある(宣言しない場合はデフォルトで「NOT DEFERRABLE」になる)

 * 遅延制約を使いたい場合は(1),(2)をあらかじめ指定しておく必要がある。

 * mysql 外部キー制約のみ > set foreign_key_checks=0;

【第四章~第六章】失敗から学ぶRDBの正しい歩き方

4.1INDEXの仕組み

4.2INDEXの役割

  • indexはテーブルからデータを高速で取り出すためのRDBMSの仕組み

  • BTreeINDEX ex:二分探索木やAVL木を元にしたBTree構造に基づくインデックスは「ルートノードと子ノード、リーフノード」から のような形で検索している(検索の仕方はAVL木とめちゃめちゃ似てる)

4.3アンチパターンを生まないために

INDEXを適切に利用する為には -> * INDEXの仕組み・RDBMSがどのように利用するかを知る * INDEXを利用するためのテーブル設計

ex: * 検索結果がテーブル全体の20%未満 検索対象のテーブルが十分に大きい ->場合にはINDEXは使われやすい。

  • 条件にその列を使う

4.4INDEXの使い方まとめ

  • INDEXの特性をしっかり把握して適切なINDEXを設定する
  • INDEXを利用できるクエリを実行する
  • INDEXを活用できるテーブル設計をする
  • スロークエリログやデータの状態をしっかりモニタリングする

cf:『SQLアンチパターン』 「インデックスショットガン(闇雲にINDEXを設定しまくることを指す)」 INDEXを設定することで INSERT/UPDATE/DELETE が遅くなる問題がある。 複雑な複数列に対するINDEXを設定しすぎると オプティマイザが不適切なINDEXを選ぶことがあるためです。

*MENTORの原則に基づいて対応することが必要 Mesure(計測) Explain(解析) Nominate(指名) Test(試験) Optimize(最適化) Rebuild(再構築)

  • またINDEXは一般的に追加よりも削除の方が難しい。
  • INDEXまた実体のあるデータであるがためにディスク容量も増えるために、 作りすぎないようにする必要がある

-> 1. このテーブルは1、3,5年後どのくらいの大きさになるか 1. このINDEXは複合INDEXでまとめる、または単一のINDEXで十分絞り込めるのではないだろうか 1. 今このINDEXを貼るべきか

cf:『SQLパフォーマンス詳解』

5.1 削除フラグの危険性について

5.2 とりあえず削除フラグ

-> テーブルに削除の「状態」を持たせている点(問題点)

  • クエリの複雑化
  • UNIQUE制約が使えない
  • カーディナリティが低くなる

5.3 アンチパターンを生まないためには

  • 事実のみを保存する(これを大原則とする)
    • 「削除済」のためのテーブルを作成する(->トリガーで削除済のデータをアプリから 意識させず移すなどがある)
    • viewを使う(viewを活用して有効なデータだけの表を作る)  ->viewのデメリット高速化にはつながらない  (postgreならばマテリアライズド・ビュー、MySQLならばサマリーテーブルを生成するなどで高速化できる)  (※postgre では差分更新にならないため、更新がボトルネックになる)

*テーブルに「状態」を持たせるのはダメか * 対象のテーブルが小さく、INDEXが不要 * そのテーブルが関連するテーブルの親になることがなく、  データを取得する際に頻繁にJOINの対象になることがない * UNIQUE制約が不要で、外部キーでデータの整合性を担保する必要がない

->以上は、リファクタリングの際に困難が生じるのは前提として使用する

5.4 フラグのまとめ

https://www.slideshare.net/yoku0825/mysql-52276506?next_slideshow=1 https://www.slideshare.net/t_wada/ronsakucasual?next_slideshow=1 https://www.slideshare.net/yoku0825/mysql-52276506?next_slideshow=1

など本以外の資料もある。

  • statusカラム ->このケースを取り出すために、 where句を利用する・view側でのバグを防ぐためにif文でチェックを入れる必要が発生する。

  • 送信ステータス(ex:メルマガ) ->

  • 配信済みのメールもテーブルに残るためテーブルの肥大化につながる
  • トランザクションの問題 (メール送信中は配信が重複しないようにメールの送信者リストに対して排他的ロックをとって管理する必要がある)

6.1ソートの依存性(order by)

6.2リレーショナルモデルとソートの仕組み

  • リレーショナルモデル
    • 重複がない
    • 実在する要素しかない(nullがない)
    • 要素に順序がない

ソフトウェアとしてのRDBMSは上記を拡張して作成された。 cf:『理論から学ぶデータベース実践入門』

  • ORDER BY のしくみ from on join where group by having select distinct order by limit

の順で評価する。 ->このように、order by はデータが大きければ大きいほど重い処理をする。

  • where 句狙いのindex 事前にwhere 句を使うことで対象を絞りこむことができる。

  • order by句狙いの index BTreeINDEXはデータを「ソート済」の状態   ソート処理が不要になる   評価数がLIMITに達した段階で結果を返せる。  

    6.3 order byを早くするには

  • データを小さくする

  • INDEXを活用する

ページャーとしての活用 created_atなどが順番通りに並んでいることを期待し、idをwhereで指定して取得 * データ量が増えてもINDEXを活用できるため高速 * ページ数が深くなってもoffsetを利用しないために取得業が深くならない。

ページャの難しさ * 途中のデータが削除された場合の表示方法(ズレる、表示されずに飛ばされる行が発生する)

大きなデータをソートしたい場合 1. アプリ側でソート (RDBの負荷を下げることができる。データサイズが大きい場合通信がボトルネックになる)

  1. ソート済みの結果をキャッシュして利用 (ソートの処理が決まっていて、結果が変更されにくいデータの場合キャッシュが有効、 表示結果が同じ場合はhtml自体をvarnishなどのHTTPアクセラレータでキャッシュする・ CDNを使ってJSONをキャッシュするなどの手法がある)

1.NoSQLなどを利用してソート

6.4order byと where句狙いについて

*改善する際には実行計画を見る

改善するためにはアプリへの影響が大きく、後から修正するのが難しい。 ソートに関する検討・実装は必要

cf:redis 高速に動作するインメモリ型キー値データ構造ストア * 永続的にデータを扱うことは苦手 * 保存できる容量が制限されている

=>キャッシュ・セッション管理・キュー・ソートなどでよく利用される

【第一章~第三章】失敗から学ぶRDBの正しい歩き方

1-1アンチパターン

  • 不適切な名前(テーブルの意味・カラムの意味が分からないなど)
  • リレーションモデルに基づかない設計(pk,not null,チェック制約)

->保存されたデータがどれがどう正しいかが分からない (≒バグと仕様が分からない)

1.2アンチパターンを生まないために

  • 命名ミスは初期に対応 ->技術負債になってしまうため

  • 対応例

  • 変更後の名前カラムを追加
  • 変更前のものと変更後が同じになるようにトリガーで定義するなどをする
  • サービス単位やモデル単位で参考や更新を追加したカラムに設定し直す
  • 切り替え完了で動確が問題なければトリガーと古いカラムをdrop

cf:『データベースリファクタリング

1.3わかりずらい設計や名前はDB破局の始まり

メモ * 対応例でカラムを追加の際にpostgresは位置での追加ができないため、間違ったカラム名(綴りミス)で pushしたものを結局修正せずに直さずスルーしたことを思い出した (ポスグレ様々な気持ちはあるが、ともかくそこは変わってほしい気持ちがある)

  • 1.3の「わかりずらい設計や名前は~」に関して 一般的に一人で作っている際には、「わかりずらい」が分からなくなる傾向があると思っていて (作っている間は分かっているため)、問題だとは感じる。 (やはりDB設計などでレビューをもらっておくのが、正しいのかもしれない。)

2-1過去の履歴を持っていないテーブルは危険

ex)消費税5%->8%の切り替え対応

2-3対応について

  • 対応について
  • 消費税率に履歴を持たせる
  • 購入時の消費税率を持たせる

  • 別対応方法

  • 配送状況テーブルの作成 ->配送状態をinsert し、最新日時のレコードを現在の状況として扱う ex 配送状態テーブル
id 配送状態 作成日時
1 発注 2020/12/22
1 発送 2020/12/23
1 納品 2021/1/7
1 返品 2021/1/8

など

  • 「履歴の保存」について ->レコードの保存量が増えるため、テーブルが肥大化する。 ->主キーでの検索でなくなるため、肥大化した場合検索速度が劣化する

2.4「後からデータを遡りたい時に消えている設計」の危険性

  • 敢えて履歴を保存しない設計を取るケース

->RDBの責務で履歴を持たない場合 * 遅延レプリケーションを使う * アプリケーションログとしてelasticsearchなどの分析ツールに保存する

cf 『理論から学ぶデータベース実践入門』

  • 遅延レプリケーションについて ->一日遅れのスレーブDBを作るなどができる (マスタDB上で行った誤った作業から保護する & システムのデバック時の再現手法として使う) 行っていることはDBの複製なので物理的コストがかかる。

3.1アンチパターンの解説(1つのクエリにまとめた結果の多数のjoin)

3.2JOINの特性(問題点)

  • ex)3つの重なりの場合 AとB/ BとC / AとC ->指数関数的に増加する。(joinの回数が増えると急激に重くなる)

このように、joinはSQLで重い処理に入る。

  • 対応->indexを貼るなどで計算コストが減ることもある。

  • joinのアルゴリズムの特徴

  • NLJ ・内部表の結合キーの列に利用できるindexがある場合、 ループ数を省略できるため外部表が小さいほど高速になる

  • Hash Join ・「外部表が大きい場合、または内部表の対象件数が多い場合」と 「結合条件の検索がなく、テーブルのフルスキャンが必要な場合」ではNLJ より有利 ・Hash表を作成さえすれば結合は非常に高速だが、Hash表の作成と保存が できるだけの十分のメモリが必要

  • Sort Merge Join ・ソートに用いる索引が作成されていると高速化できる ・Hash Join と同様に表の大部分を結合する場合に有効 (Hash Joinと違い等値結合だけでなく不等号(<,>,<=,>=)を使った結合も可能) ・Indexが活用できる場合はHash Joinより早い場合がある。

※ * postgresは3種類のjoinをサポートしている * Mysql はNLJしかサポートしていない(内部に適切なindexを貼る必要がある)

3.3アンチパターンを生まないためには

  • joinの特性を知り、生かす(SQL文の修正)。
  • viewを作成する。 cf:マテリアルズド・ビュー->再作成の時テーブルの作り直しが不要(postgre)

3.4アンチパターンのポイント

  • joinは必要最低限
  • indexを適切に利用する
  • joinするテーブルは小さくしてからjoinする
  • 複雑なクエリになった場合はviewを利用する

『正しいものを正しくつくる プロダクトをつくるとはどういうことなのか、あるいはアジャイルのその先について』を読んだ

私はアジャイルを「ろくろを回して楽しい人」がやるものだと思っていたのですが、

この本で「良いもの(この本でいう正しいもの)」をお客さんに渡して尚且つ(無駄な)会議をなくしたいだけだったのかもなぁと思えました。

知らなかった言葉、内容のメモ

 

・SOR
->
動作に信頼性が求められるもの(要件定義が重い)
etc>社内システム、基幹システムなど

SOE
->「こうあるといいのではないか」という機能の実装(誰も正解をもってない可能性がある)
etc>ECサイトなど

 

●不確実性との戦い方
(これまで)
・要求定義によって確実性を上げる
・合意を重視する
・合意形成を遵守する

これらの戦い方をしても開発に付随する不確実性には勝ち続けることはできなかった
(要求定義時点に戻るような手戻り、技術的な難しさなど)
->この点を解消するのがアジャイル開発としている
「あたりをつけながら開発する、関係者内で合意形成しながら進める」
(スプリントごとに開発するような形になるため、ユーザーに試してもらいやすいなど)

 

スクラムの難点
->経験主義(実践知)

「対話、動くソフトウェア、(顧客側などとの)協調、(計画の)変化への対応」に重きをおいている
(『アジャイルマニフェスト』)

ここの対話の部分に「心理的安全」などがかかってきている気はする。


2-4スクラムイベント 辺りを読んでいると「無」の会議をしたくないんだろうなというのは伝わってくる。

 

早く(少しだけ)形にできることで得られる良さとは何か?」内の④チームの学習効果が高いはSESでチームが変わる自分からすると魅力的に思えた。

 

3-4 スプリントの強度を高める技術
->やり抜く力(リモートワークでの開発中のコミュニケーション不足からさらに求められるようになった)

 

・小さくとも成果を認める必要がある(これが自分は下手)
->表面的にではなくチーム内のお互いの信頼感を醸成するには、「このチームはやれる」という期待が必要

 

他の参考本

・『カイゼン・ジャーニー たった1人からはじめて、「越境」するチームをつくるまで』は「主人公がいて...」という物語の形式になってしまっている部分が強く
(このことはあんまり言い出したらキリがないため、言ってもしょうがないのだが)
「こうしてみんなアジャイルによって幸せに暮らしましたとさ」というオチにつながりすぎているように感じた。
(本当にそれでみんなが幸せな開発が可能なのかという疑問がぬぐい切れなかった)

・『正しいものを正しくつくる』とプロフィールで同じ人だったことに気が付くなど

 

 

laravel(2)-CRUD

#環境
windows10 64bit
Vagrant

 

#参考にしたページなど

https://qiita.com/apricotcomic/items/07f172a957c1f342fd91

・全部書いてある。

・その前の”LaravelでDBにテストデータを仕込む(

https://qiita.com/apricotcomic/items/ee09850ab2b7447a2cfc

)から読んだ。

・データに関しては必ずしもこの方法でやる必要はない気がする。(DBサーバーがある場合など環境によりけりだと思うので、その都度調べるほうが安心かもしれない)

今回は参考にしたページと合わせるために比較的沿ってやった。

 

その他 

・blade(のテンプレート)がいまいち理解してないため、少しダサいが画面が表示されることのみを手掛けた。

 

 

#やったこと(1~3はテーブル作成)

1,マイグレーションファイルの作成

   $php artisan migrate

 

2,modelクラスの作成

    $php artisan make:model Book

 

3,seederの作成

 $php artisan make:seeder BookTableSeeder

 

4,controllerの作成、ルートの追加

 $php artisan make:controller BookController --resource

 

(5~9は

・blade.phpで画面を作る。

・controllerに処理を追加する

が大まかにやっていることです。

)

5,一覧画面

6,create画面

7,show画面

8,edit,update画面

9,del画面

 

#words

・seeder=>デモデータを流し込む(ためのファイル)

・store=>formで入力されたデータを保存しているメソッド

 

#修正点など

・手を付けたのが日曜日からだったので遅すぎる気がした。

=>一度にやってしまう癖がついているので、もう少しもらった作業分を自分で分割してみる必要があるかもしれない(cf:想定作業時間*3をすると大体ぴったりに終わるので、週3日やるとしての目標などを立てるべきかもしれない。)

 

 

git 

github.com

 

画面

f:id:fallakiakino_793:20200914225536j:plain

=>delじゃなくて writerとかの方がそれっぽかったな...。

 

gitプルリク、エビデンス

f:id:fallakiakino_793:20200914225431j:plain

laravel(1)-環境構築

laravelの環境を作ってphpに入門してみたらとアドバイスされたので、
環境を作ってみました。

#環境
windows10 64bit
Vagrant

 

#参考にしたページなど
https://qiita.com/7968/items/97dd634608f37892b18a#%E7%AC%AC6%E7%AB%A0-%E9%96%8B%E7%99%BA%E7%92%B0%E5%A2%83%E3%81%AE%E6%A7%8B%E7%AF%89

・めちゃめちゃ丁寧に書いてあるので、入門者向け。
大体全部書いてある。(分量があるので上の環境を作ったことのある人は読まなくていいかもしれないです。)

・若干難点は少し記事が古めなこと(version違いなどがあったら適宜ググってほしい形式)

 

#やったこと
細かいことは上のURLに書いてあるので、備忘録的に何をやったかだけ

(・git hubにリポジトリー作成)
(・virtualbox/Vagrantをダウンロード)
ssh鍵ファイル作成
・Homestead.yamlを修正
vagrant up =>仮想マシンの起動

(・仮想環境につなげるフォルダーが日本語名だったので、移動してやり直し

・Homestead.yamlの修正↓


folders
: - map: C:\app\code to: /home/vagrant/code

sites
: -

-map: homestead.test
to: /home/vagrant/code/Laravel/public

・.yamlを修正しなおしたため、

vagrant reload --provision で再起動。(たぶんvagrant reloadでも読みこめる気がする)

)

 

#words
VirtualBox
=>自分のpc(ホストos)に仮想環境(ゲストos)を作成するソフトウェア

 

Vagrant
=>仮想環境を構築するオープンソフトウェア
(visialBoxと)Vagrantboxを使用することで仮想マシンのインポートができる

 

・Homestead
=>laravelが動作する環境を構築できるツール
 Homestead.yamlの記述をする
 
・Composer
 ライブラリの依存関係管理ツール

 

#修正点など
・コマンドを打つのや覚え間違えが多すぎるので何とかしっかり覚えるか、
入力補完の使い方などを覚えたい。

 ・windowsでやってるので、フォルダー名を日本語にしてたので詰まった

 

git 

github.com

f:id:fallakiakino_793:20200905154516p:plain

とりあえずエビデンス(お気に入りが見えて気持ち悪かったので黒つぶし)