gitでfetchした後に差分確認
pushしようとしてrejectが発生したときに差分を確認する方法
fetchしてからdiffする。
git fetch origin master git diff HEAD...[リポジトリ/ブランチ名]
Gitで1ファイルだけをPullしたいときの手順
何回も使いそうなので自分用メモ
githubを使っていて、README.mdだけを後からgithub側で作った。 そのREADME.mdをローカルで編集したいので、このファイルだけローカルにPullしてきたい。
以下のやり方でできた
git fetch git checkout -m <ブランチ名> <ファイルパス> git add <ファイルパス> git commit
実際に叩いたコマンド
git fetch git checkout -m origin/master Readme.md git add Readme.md git commit -m "Readme"
- 最初に追跡リポジトリを最新にするためにfetchする
- 対象のブランチのファイルをチェックアウト
- addしてcommitする
参考
「ゆるWeb札幌 x TEF道 探索的テスト勉強会」に参加してきました
探索的テストの勉強会に参加してきました。
当日の様子はこちらのTogetterにまとめられています。
探索的テスト
探索は、「未知の事柄などをさぐり調べること」。
探索的テストは、テスト設計とテストの実行、システムについての学習を、対象を動かしながら並行して行うテスト手法。
- 頭の中で仮説をたて結果を予測し（テスト設計）
- テストを実行
- フィードバック（システムについての学習）
を行う方法で、テスト設計についてはあらかじめドキュメント化しておくことはしない。
お医者さんが患者さんに問診を繰り返しながら病気を見つけていくやりかたににている。
探索的テストとスクリプトテスト
探索的テストのメリット
- 軽快。テスト仕様書を書くコストを削減し必要なところだけピンポイントに確認する。短納期でバグを見つけたい時に良い。
- 柔軟性が高い。実物に合わせてテストの重み付けをその場で変えることができる。
- 暗黙知を活用しやすい。
探索的テストのデメリット
- 属人性が高い。実施する人のバックグラウンドやコンテキストにも影響される。
- 記録が残りにくい、再現させづらい。
探索的テストとスクリプトテストの併用
スクリプトテストと探索的テストは目的が違う。
スクリプトテストはバグがでないことを確認するのが目的だが、探索的テストはバグを出すのが目的。 なので、目的の違う2つのテストをうまく併用すると良い。
ワーク
テストチャーターを使う
簡単に言うと探索的テストの『道しるべ』となる。抽象度の高いテストケースや、機能リスト、リスクリストなど。テスト手順ではないということに注意。
お題：かんばんりすと
@volpe_hd28vさん作「かんばんりすと」を使って探索的テストを行ってみる。
テストには以下のチャーターを使用。
(対象) かんばんりすと を
(資源) マニュアル を用いて探索し
(情報) マニュアルとの不一致 を発見する
やってみた
自分は@volpe_hd28vさんを知っているので、最初に思ったのが「きっとClomeでしか動作確認してないだろうからブラウザを変えたらバグが出る気がする」ということでした。*1
あとポモドーロタイマーあたりが怪しいかなと。
このように、例えば実装者のクセとか、開発の経緯を知っている／知らないで予測すべきポイントが変わってくる。これが「バックグラウンドやコンテキストによる違い」というやつですな。
で、Safariで起動してテストを行っていたのでですが予想に反してブラウザ違いによる不具合は見つけられませんでした。
結局自分が見つけたのは2つだけ。
ディスプレイのサイズ（横幅）によってヘッダ部分の表示が崩れてしまう
BookのFilter機能が、特定の操作手順で正しくフィルタリングされないときがある
やってみてどうだったか
気を抜くとチャーターをガン無視していた
チャーターには「マニュアルとの違いを探す」と書かれていたのに、気がつけば自分の勘にたよってテストしてました。
スクリプトテストではテスト仕様書に書かれている通りに実施すればいいので、よく書かれたテスト仕様書であればあるほど考える能力を必要としません。
一方、探索的テストでは仮説と検証を繰り返す、すなわち想像するということが随所に求められるのですが、そういうやり方に慣れていないので気の赴くままに没頭しがちでした。。
時々モンキーテスト化していた
探索（仮説と検証）するということを意識しないと、手当り次第のただのモンキーテストになります。
考えることをやめると、人はサルになる…！
ピンポイントを攻めがちになった
「ポモドーロタイマーがあやしい」と思っていたのですが、実際にみんなで答え合わせしてみたら、バグが多かったところはもっと違うところでした。
「よく使うところのバグを潰す」「バグがでたら影響が大きい機能のバグを潰す」というのが効果の高いテストだと思うので、そうじゃない機能を局所的に攻めても、良いテストとはいえないですね。
まとめ
「探索的テストのほうが優れているから、みんなこれからは探索的テストの時代だよ！」というわけではなく、スクリプトテスト＋必要に応じて探索的テストを取り入れることによって、相乗効果が期待できる気がします。
ただ、説明でもありましたが属人性が高いと思うので、システムやテストの暗黙知部分を共有していくことが重要だなと思いました。*2
おまけ
余談ですが、かんばんりすとが昔使っていたときより進化していて、ちゃんとメンテナンスされ続けていることに感動しました。
JavaScript勉強会「js workshop sapporo vol4」に行ってきた
JavaScript1行も書けないので、ぐっちーさん、ナガさんが主催しているJavaScript勉強会に行ってきました。
js-workshop-sapporo.connpass.com
4回目となる今回は関数を学ぶ回でした。
初心者も対象にしているとのことですが、課題は初心者向け～なかなかレベルが高いものまでバランスよく用意してくれています。
基本はもくもく会なのですが、講師もたくさんいますし近くにいる人同士で聞きあったりしながら進めるのでわからなくて終わることはなかったです。
で、私の出来高はというと、びっくりするくらい全然書けませんでした（泣）。 9個あるお題のうち2つ目も完成しない有り様です。うう…。
最近コード書くたびにもうプログラマーと名乗れないレベルまで書けなくなっている事実を突きつけられて凹みます。。。
ということで初心に返るべく、参加していなかった1～3回目をきちんとやってから4回目の課題に臨むことにしました。
以下は1～3回目の課題を勉強していて気になったことの自分メモです。
vol.1
__proto__
課題やっていたらでてきた。
obj.__proto__はObject.prototypeのことらしい。
図で理解するJavaScriptのプロトタイプチェーン - Qiitaがわかりやすかった。
typeof演算子を使ってArrayの型を判断しようとするとobjectっていわれる
qiita.comを見てみると、厳密な型判定はできないらしく、Object.prototype.toString.call()などで判断するやり方のほうがよいことがわかる。
つまり、typeofで判定しても支障ないものがなにかをわかった上で使わないといけない。
vol.2
falsyな値
JavaScriptでは暗黙的にfalseとみなされるものたちがある
- 空文字（””）
- 数値の0
- NaN（Not a Number）
- null
- undefined
等価演算子（==）と同値演算子（===）の違い
等価演算子（==）は左右の値が同じ場合にtrueを返す。 型変換はJavaScript側で勝手にやってくれる。
同値演算子（===）は厳密な比較をして、型がも値も同じ場合にtrueを返す。厳密等価演算子ともいう。自分は「厳密等価演算子」という表現のほうがしっくりくる派。
===は最初見たとき、普通にタイポかと思った。
進捗
課題をやったソースはGitにあげた。今はvol2の課題3までやったのでvol2が終わるまであと6個。
2020/1/24 ：課題4まで終わった。
2020/1/26：課題10まで終わったのでvol.2は完了。
2020/2/1：vol.3の課題7まで完了。やっぱり手を動かすとわからないことがだんだんわかるようになるのを実感。
2020/2/3：vol.3の課題を全て完了。vol4の課題4まで完了。まだまだ配列を使いこなせてない感じある。クロージャーがわかりかけてきた（わかったとは言っていない）
2020/2/4：vol.4の課題を全て完了。4回目までを通してJavaScriptってかなりいろんな書き方ができるんだなと思った。
まとめ
5回目までに、4回目までの課題を終わらせるぞ。
学生と社会人のライトニングトーク大会でLTしました
今日はこれに参加してきました。
学生と社会人合わせて60人近く集まっていて、そのうち半分くらいの人がLT発表者。
千歳科技大の学生を筆頭に学生達のLTは研究開発の成果発表が多く、
- ホントは今日までに完成させたかったけど間に合わなかった
- ○○をやろうと思ったけど自分たちのスキルではわからなくてできなかった
- 途中でデータ飛んだ
などなど試行錯誤してやってきた様子がリアルでした。
わずか5分でドッカンドッカン笑いをとっている学生もいて、社会人自分よりトークスキル全然高かった！
今の世の中「学生だから」「社会人だから」っていう固定概念は捨てないとなーと思ったのでした。
スポンサーセッション
千歳科技大の学生によるスポンサーセッションはLINEのCloverを使って学校生活をよくする取り組みについて。
完成したら自分たちの生活が実際に便利になることをテーマにするのっていいね。
実際のデモ動画でCloverに冷たく「キキトレマセンデシタ」を連呼されているのも愛嬌。
非常なまでの「聞き取れませんでした」 #北海道LT大会
— kazuhiro1982 (@kappe1982) 2020年1月18日
私のお気に入りセッション
1. 自作ストレージエンジンから見るMySQLの内部実装
室工大のけんつさんの発表。 さらっと言ってるけど「MySQLのストレージエンジンを自作」ってすごくない？っていうかそれより
トークが面白すぎて中身がぜんぜん頭に入ってこないwww
前日に「LTは10分じゃなくて5分」という事実を知り、軌道修正したらなぜか24枚のスライドが36枚になったという謎。
明日の LT って 5 分なのか
— けんつ (@lrf141) 2020年1月17日
10 分の気分で作ってた
10分24枚のつもりが5分36枚わろた#北海道LT大会
— らびさん(ravicot) (@ravicot) 2020年1月18日
「説明書いたんで頑張ってください」わろたww#北海道LT大会
— 佐藤 葦汰 (@ashita_93) 2020年1月18日
「こうなります」（1秒）#北海道LT大会
— YAMAKAWA, Hiroto (@gishi_yama) 2020年1月18日
話が面白すぎて内容が入ってこないww#北海道LT大会
— 佐藤 葦汰 (@ashita_93) 2020年1月18日
彼の今後の活躍が楽しみ。
2. Chrome拡張機能の作成と公開方法
DE-TEIUさんの発表。
JavaScriptでChrome拡張機能が作れること自体発見だったんだけど、DE-TEIUさんのセンスがマジでツボるwww
外覇(ワイパァー)使ってみたけどほんとジャマなだけでしたw
ほんとﾃﾞｯﾃﾕｰさんのクソアプリ大好きw#北海道LT大会
— 佐藤 葦汰 (@ashita_93) 2020年1月18日
なにこれブラウザにワイパーいるの？速度が10段階www#北海道LT大会
— らびさん(ravicot) (@ravicot) 2020年1月18日
自分の発表
「ここが楽しい！ Scrum Fest Sapporo 2020」というタイトルでスクフェス札幌の魅力についてお話しました。
スライドはこちら。
実行委員が頑張っていいイベントにしようとしている気持ちを少しでもたくさん伝えたくて、
結果、詰め込みすぎました。
もっと情報量減らしてポイントに集約するようにしたほうがよかったなー。ちょっとLTナメてたよね昨日の自分、反省だな。。。
それでも興味をもってくれた方がたくさんいたのでよかったです。
いきてええよおお#北海道LT大会
— Yoshiki-Yamada (@yohseekey) 2020年1月18日
Scrum Fest Sapporo行きたいんだけど調整できるかなぁ #北海道LT大会
— kazuhiro1982 (@kappe1982) 2020年1月18日
Scrum Fest Sapporo 2020か。
— 水脈の底 (@suimyakunosoko) 2020年1月18日
金曜分の有給とるかも #北海道LT大会
スクフェス札幌2020のプロポーザル、モブプログラミングの話題でチャレンジしてみたいな #北海道LT大会
— YAMAKAWA, Hiroto (@gishi_yama) 2020年1月18日
まだEarlyBirdあります！
まとめ
来年もこのイベントでLTやりたいなー。そのときには自分の成果が発表できるように頑張ろう。
社会人になると学生との接点が極端に減るので、こういうイベントは私達にとっても新鮮だし、学生にとっても実際IT業界で働いている人達を相手に発表する機会があるっていいことだと思う。
楽しい1日でした。
スタッフのみなさんありがとうございました。
初心者向け勉強会「やさしいスクラム」に参加してきました
アジャイル札幌主催の「やさしいスクラム」に参加したので自分向けメモ。
自分のコミュニティ主催のイベントですが、@YasKamitoさんが講師をするということで、自分も人にScrumを教えるとしたらどうやって教えたらいいだろうと思い、講師側の観点を学ぶつもりで参加しました。
導入
- アジャイルソフトウェア開発宣言の背景
- 宣言では左よりも右に重きをおくことを説明
- ウォータフォールとの違い
- アジャイル開発の比率（世界・日本）
- Scrumbanとかハイブリッドもいれると開発にスクラム要素を取り入れているところは多い
スクラムガイド（全体像）
一枚絵
- 全体像
- INVEST*1
- 「成果物」ではなく「作成物」
- プロダクトバックログは価値ベースで書く。例えばショッピングサイトだったら「○○で検索することができる」のような。検索して商品にたどり着くことがお客様にとっての価値。
- 50%のスプリントは失敗するのが普通
- タスクは1日1つ以内で終わるボリューム。大きければ分割する。
質問
参加者のみなさんはわからないことをどんどん質問してくれる。こんなに質問でる勉強会久しぶりかもしれない。
たぶん「初心者」×「対話形式でやりましょう」×「やさしいかみとさん」の相乗効果。やさしさ大事だな。
- POとSMの兼任はOK？
→NG。POとSMは責務が相反するので１人が兼任するとどっちかに（ほぼPOより）に傾いてしまう。
- 軽量とは？
→Scrumとして定義しているのは「3本柱」「5つの価値基準」「3つの役割」だけ。そしてScrumガイドは20ページもありません。フレームワークのみを定義しているのでコンパクト（軽量）なのです。
- スプリントを2wにするか4wにするかどうやってきめる？
→ポイントの１つとして透明性、検査、適用をどのサイクルで行いたいかで決めたりとか。
- そのスプリントで終わらなかったタスクはどうするの？
→終わらなかったタスクと「このやりかたでは終わらなかった」ということを学んだ経験値が残る。ただそれだけ。
リリース日までの日数を考慮しつつその経験を元に「この先どうやるか」ということを考えることにシフトしていけばいい。
学び
- 一枚絵を説明するときに「自社開発製品を作っているチーム」とか具体的はイメージがあったほうがわかりやすいのかな
- 1時間半は少なかった。時間配分を考えなくちゃ。
- 1日目：やさしいスクラム、2日：紙粘土スクラムの2daysでBootCamp的なことをやると学びが深いかも。
- スクラムは「鏡」や「体重計」。今あるものを映してくれる。ただそれだけ。
わたしにとってのScrum
Scrumはドラクエ。
一人でできることはたかが知れている。
でも仲間が増えたりそれぞれが役割をもってトライ＆エラーを繰り返すことで経験値をがあがりレベルアップできる。
レベルアップして新しい技が使えるようになると、オートバトルをやっても一辺倒な戦い方ではなく相手に合わせて戦術をかえることができる強く多様なパーティに成長しておく。
でもその裏側では死んでしまって教会のお世話になったり、全滅してやりなおしたりと様々な失敗があるんだよね。
そして戦士が4人いるよりもバランスのとれた編成のほうが結果強かったりする。おもしろい。
おまけ
諸事情によりだいぶ久しぶりに勉強会へ参加しましたが、率直に楽しいしテンションあがりました。
一方で、こんなにも長く学びを止めていた自分と「初心者向け」って言ったのに全然初心者じゃないレベルの人達を比べて「これはやばいぞ」と思いました。完全に成長止まってることを痛感…。
スクラムマスターが5人も講師として参加している贅沢な勉強会「やさしいスクラム」、また開催すると思うので是非お越しください。
堀江さんの「捨て本」は名書だということを伝えたい
堀江貴文さん（以降親しみを込めてホリエモンと呼びます。）の「時間革命」を買おうと思って寄った本屋さんで、なぜか買って帰ってきたのがこの「捨て本」。
本屋でパラパラとめくった時に、なんとなくこっちのほうが今の心理にあっているような気がしたからです。
でもこの行動はあながち間違っていないようで、心が欲している時に欲している内容の本を読むことは吸収がとてもよい気がします。
私はこの「捨て本」を読んで、ヘドロまみれの自分の思考がまるでTVショッピングで販売されている強力クリーナーによってぐんぐんと汚れが溶けていく換気扇の羽みたいにクリアになっていきました。
大切なモノを捨てていくことが、本当に大切なモノにアクセスする手段となる
この本の冒頭にかかれている一文です。
最初に出てくる"大切なモノ"というのは「大切だと思っていたけど実は必要なかったモノ、昔は大切だったけど今は必要ないモノ」のことです。*1
大切だと思いこんでいるだけで本当は必要のないものを手放すことで今よりももっと身軽になり、豊かな人生、つまり自分のやりたいことで満ち溢れている人生を送ろうといっています。
なぜなら時間は有限だからです。
なのに多くの人は自分のやりたいことよりも「やりたくないけどやらないといけないこと」に時間を費やしています。
ここで大事なのは以下のようなことを自分自身に問いかけること。
やりたくないけどやらないといけないと思っていることは本当にやらないといけないのか？ やらないといけないって思い込んでいるだけなんじゃない？
それをやらないと何が困るの？困る"かもしれない"という可能性があるだけで、結局未来のことはわからない。
起こるかどうかわからない未来や過去の経験や失敗を気にして、今起こす行動を自ら制限しちゃってない？未来はわからないし過去は変えられないし、人は今にしか関わることができない。だから今やりたいことをやろう。
こう考えると、行きたくないと思いながら働くことや付き合いたくないと思いながら遮断できない人間関係など、なんやかんや理由をつけて自分自身の行動を正当化しているだけで、本当はいらないんじゃないかと思います。
こういう考えは私自身以前から持ってたのですが、捨て本を読んでからは強い確信になりました。
うん、必要ない。
すべてのものは移り変わっていくのだから、得ることと捨てることを繰り返すのは自然な行為
世の中は移り変わっていきます。 だからいつまでも同じモノを持ち続ける必要性というのがそもそもないのです。
むしろ移り変わる世の中での生き方としては必要じゃなくなったモノは捨て、今必要なモノをを持つという取捨選択を繰り返すことのほうがごく自然ではないでしょうか。
獲得と所有は違う。所有は必ずしも必要ではない
獲得は喜びを生みます。喜びという経験は原動力となり行動に大きく関わるので必要。だけど獲得の喜びを感じたモノを所有しておく必要はある？
むしろモノ所有することによって失うことへの不安、管理コスト、執着心などネガティブ要素が増えるだけでは？
所有欲にかられると、あれがほしい、これを手に入れたいという所有のための行動を取るようになり、これが執着を生み、執着は自分が本当にやりたいことへの行動を阻害します。
獲得の喜びを得たあとにそのモノが必要でなければ捨てたほうが次の獲得へ向けて身軽に動けるのです。
本音で生きよう
気配りや空気を読まないといけない関係でストレスを感じるような人間関係にガマンしているあなた。その関係は本当に必要？
人は本音で生きればよいのです。
本音を言った結果嫌われたらどうしよう？とか会社で居場所がなくなったらどうしよう？という不安からストレスフルな人間関係を捨てられないのだと思いますが、今の世の中は理不尽な言動や行動はあっという間に拡散されて社会的制裁を受けたり間違ったことはまかり通らない世の中になってきました。
結局は本音で生きる人のほうが強いのです。
そもそも価値観や意見はバラバラであるのが普通でそれを同じじゃないとおかしいという空気をつくっていることが異常なのです。
世の中は1か0かで区切られるのではなく様々な色のグラデーションでできているのです。
とはいってもここは実践するのにはなかなか勇気がいりますね。自分にとっても課題ポイントです。
まとめ
自分が心では思っているけど文字や言葉にできていなかったふわっとした思考がこの本では明確に文章になっていました。
彼のこれまでの経験があるからこんなにしっかりと伝わる文章にして表現できるのだと思います。本当に素晴らしい人だと思います。
中には「これは極端だな」とか「これは私とは考えが違うな」という点もいくつかありましたが、あくまでも「オレはオレの経験からこう思う。そしてその思考の通り実践してきらこういう結果を生んだ。」と書いてあるだけで強要するものではありません。
自分もそう思うところは取り入れれば良いし、そうじゃないところはスルーすればいいんだと思います。
この行為自体も「必要のないものは捨て、必要なものだけを選ぶ」ということですね。
もしこのブログを読んでみて興味があればぜひご覧になってみてください。
*1:この"モノ"というのは、物理的な物以外にも、人間関係や経験、思考などあらゆるものを指します。私は、実際には"思考"の断捨離が一番大切で、これができればモノも経験も、不要なモノはあっさりと捨てることができるようになると思います。
