本書ではチームの税は、下記の様に定義する。
会社のための仕事や必須の要求事項であり、チームやグループに重荷となる義務、任務、請求など
スクラムのオーバーヘッドについても、税としてまとめて考えている。
計画、ふりかえり、レビューはスクラムの税である。
スクラム現場ガイド -スクラムを始めてみたけどうまくいかない時に読む本-
## テスト計画
## テスト設計
- どの仕様が不明確なかを書き出しながら書き進める
- 仕様が決まったタイミングで更新しやすい様に工夫は行うこと
## テスト実行
- 抱え込まずに一旦計上して、バグ/非バグの判定をチームでハンドリング
- 10分はあくまでも目安
- 振り返りなどの際に同じ質問が出たことなかったかを確認する(ex. テスト環境、テストに付随する作業)
- 振り返りの場だけでなく、朝会や夕会の場でも共有すると良いhttps://tech.nikkeibp.co.jp/atcl/nxt/mag/sys/18/SYS_backnumber/201909/
【ユースケース】
ある時期にコミットされたファイルに対して、そのファイルの調査したい箇所が最後に誰が更新したコードなのかを調べたい時
【Forkを用いた調査方法】
調べたいタイミングのコミット箇所をまずは選択する。
その後、Changesタブ or FileTreeを選択し、調べたい対象のファイルを見つける。
調べたい対象のファイルを選択した状態で右クリックを行い、Blameをクリックする。
すると、モーダルウインドウが表示され、対象ファイルの左側に、どのタイミングでコミットされたものかが表示される。
わかばちゃんと学ぶ Git使い方入門〈GitHub、Bitbucket、SourceTree〉
Gitが、おもしろいほどわかる基本の使い方33 改訂新版〈バージョン管理、GUI、Sourcetree、Bitbucket〉
[やりたいこと]
リポジトリに対して修正を行っていたが、一時的に同じブランチに対して先行して変更したい内容が現れた。
今直している内容のままではテストが動かせなく、ブランチを新しく作成するなどごにょごにょすると時間かかるので、手軽にブランチの元の状態で修正を行いたい。
[対応方法]
Stash機能を用いれば良い。
[ForkでのStash保管方法]
修正を行ている状態で、Stashアイコンをクリックする。
この際、どのブランチか？という情報は補間してくれるので、どの様な内容かということを記載したら良い。
また、チェックボックスは新しく作成したファイルはStash対象として退避させるか？という事なので、基本的にはチェック付けとけばよいと思う。OKボタンを押すと、修正したファイルなどは、一度ブランチの元の状態に戻される。
その後、同じブランチに対して、一時的に行いたい内容を操作すれば良い。
[ForkでのStash復元方法]
Forkの左端のペインに表示されている欄で、Stashesから戻に戻したい内容をフォーカスしたのち右クリックする。 Apply 'On ブランチ名 コメント'という部分を選択する。
Stashに成功した場合、Stashファイルを削除するか？というチェックボックスがあるので、それらを選択した後にOKとすればよい。
GitHub実践入門 ~Pull Requestによる開発の変革 (WEB+DB PRESS plus)
GitLab実践ガイド impress top gearシリーズ
ファイルの修正が行われているコミットを選択する。
下のペインにFile Treeというタブが表示されるので、それを選択する。
そうするとファイルツリーが表示されるので、対象のファイルをフォーカスさせた状態で右クリック後Show File Historyを選択する。
結果、File Historyというモーダルウインドウが表示され、そこに対象ファイルのコミット履歴が表示される。
なお、任意のコミットを二つ選択を行った後に右クリック後External Diffを選択する事で、変更箇所比較を行う事が可能である。(※1)
※1 事前に[file] - [preferences]を選択した後、Integrationタブ内のExternal Diff Tool欄に比較ツールを設定しておく必要がある。当方は、今までWin Mergeを用いていたが、最近はMS VSCodeを設定して利用している。
GitHub実践入門 ~Pull Requestによる開発の変革 (WEB+DB PRESS plus)
はじめてのVisual Studio Code (I・O BOOKS)
MySQL Workbenchでデータをエクスポートし、Structure & Dataモードで新規作成したスキーマに対してデータをインポートを行った。
しかし、「Access denied; you need (at least one of) the SUPER privilege(s) for this operation」というエラーが発生して、データをインポートが行えない。
エクスポートした状態でそのままインポートしようとすると、権限を操作する様なSQLがいくつか出力されてしまっている。
そこで、MySQL Workbenchでインポートを行う前にSQLを編集すれば、インポートが行える。
MySQL5.7においては、(多分)以下をSQL文中から削除することで、インポートが行える様になる。
SET @@SESSION.SQL_LOG_BIN=0 SET @@GLOBAL.GTID_PURGED=''; DEFINER=`hogehoge`.@`hogehoge2` SET @@SESSION.SQL_LOG_BIN=@@MYSQLDUMP_TEMP_LOG_BIN;
MySQL Workbenchでインポートを行おうとすると、実行したSQLがコンソールに表示される。
そのSQLをコマンドプロンプトにて実行を行う。
その際、-fオプションを付与して実行を行う。(※1)
そうすることで、対応方法1でエラーになっていた箇所はエラーメッセージは発生するものの、スキップしながら実行を行える。
但し、DEFINER～のところは編集していた方が好ましい(※2)。
※1 コンソールに表示されているSQLのオプションは、"-host"などの記載になっている場合があるので、その際には"--host"と編集して貼り付ける。
※2 前提条件に記載している権限の状態が誤っていないという部分に反しやすいので。自身では合っていると思っていても、実際には設定が足りていない、別の設定が効いてきてしまうという状態に陥りやすい(自身がそうなので…)。
