create-react-appコマンドで作ったリポジトリをGitHubに上げる方法

ReactやVueなどのフレームワークをcliから使う時、プロジェクトごと作ってくれる。

create-react-app my-app
create-react-native-app AwesomeProject
vue init webpack my-project

これをGitHub上にアップロードする方法をメモしておく。

1. New repositoryでリポジトリを作る
2. この時Initialize this repository with a READMEをチェックしない
3. するとリポジトリを作った後に次に実行すべきコマンドが表示される
   …or push an existing repository from the command line にしたがいコマンドを実行する。 ローカルリポジトリを作ってリモートリポジトリを登録してからプッシュするという流れになる。

ローカルリポジトリで以下の手順を実行する。

createt-react-app my-app
cd my-app
git init
git remote add origin git@github.com:YOUR_USER_NAME/YOUR_REPOSITORY_NAME.git
git push -u origin master

コードを理解するときに個人的に気をつけているポイント

コードを読む時に気をつけているポイントの自分用メモ。(Githubを使っていることを想定)

ディレクトリ構成を理解する

ディレクトリ構成とファイル名を理解することでどんなプログラムか読み取ることができる。

フレームワークを使用している場合は、公式リファレンスにディレクトリの説明が書いてあるのでそれを読んで、ディレクトリの役割を理解する。

テストを読む

テストを読むことでインプットとアウトプットを理解する。

テストの文言からどのような事をおこなうプログラムなのか理解する。

コードを読む

ざっと関数だけを眺める。細かい実装は必要になったときに読む。

commitメッセージを読む

git blameを実行することで行毎のcommitメッセージを読むことができる。

git logを実行することでcommitログを新しい日付順に表示できる(デフォルトの場合)。

commitログからどのような変更か理解する。(Howの理解)

プルリクエストを読む

プルリクエストからどういった意図でプログラムが実装されているか理解する。(Whyの理解)

ログインをともなうE2Eテストのコツ

ここ数週間ログインをともなうE2Eテストを実装していたので、 そこで得られた学びをロギングしておく。

環境

Node.js v6.11.0
Nightmare v2.10.0
Mocha v3.4.0

コツ

1. テストはリトライさせる
   E2Eテストは、ネットワークやディスクIOなど外部要因が絡んでくる。 ユニットテストと比較し、実行時間もかかるし、外部要因によってテストが失敗したりと、テスト結果が安定しない。そのため、テストに失敗したらリトライするような仕組みを用意する。mochaの場合はretryオプションがあるのでそれを使った。E2Eのためのオプションらしい。
   RETRY TESTS

   This feature is designed to handle end-to-end tests (functional tests/Selenium…) where resources cannot be easily mocked/stubbed.

2. beforEachはリトライ対象にならない
   上記リトライオプションだが、mochaのbeforEachには適用されない。 参考issue
   beforeEachなどはあくまでsetup/teardownに使ってくれ。フックで安定しないロジック使ってるなら、それを関数化してくれ。ってことらしい。
   今回、ログインをともなうE2Eだったので、beforEachでログイン処理をしていたが、関数化して、ログイン処理をリトライに対応させた。
   最初、beforEachもリトライ対象になると思い込んでいて時間のロスをしてしまった。

3. テストシナリオの各工程にはフィードバックを
   たとえば、「ログアウトできること」というテストシナリオの場合、ログイン＞ログアウトという工程を経ることになる。ログインにはフォーム入力、ボタンクリックなど、ログアウトにはログアウトのボタンクリックなど、各工程にも作業がある。つまり、一つのテストシナリオは複数の工程から構成される。今回の案件の場合は10~20程度の工程があった。その各工程で、フィードバックがないとテストでコケたときに、原因特定に時間がかかってしまう。
   実際にあったのは、「ログアウトできること」というテストシナリオで、アサーションが「ログイン時に付与されるクッキーが削除されていること」だったのだが、自分の書いたテストは、ログインできていないのに、次の工程に進んでしまっていた。当然ログインしていないので、ログイン時に付与されるクッキーは無い。そのため、アサーションも通ってしまっていた。
   結局、別のテストが落ちることで、ログインできていないことが判明したが、テストが落ちる原因特定にかなり時間をロスしてしまった。（そして、そもそもログインできていない原因は、上記にあげた外部要因によるものだった。）

まとめ

ブラウザオートメーションはphantom.jsとかでやったことがあったし、ユニットテストも書いたことがあったが、E2Eテストは初めてだった。
感想としては、自動化はできるが、ユニットテストと違って時間もかかるので、安定させるのが難しく、テクニックを要するなぁという感じ。
しかし、E2Eテストで事前に検知できたバグもあるので、書いたかいがあった。手動で検証するよりは、繰り返し実行できるし、時間もかからないので書く価値は有ると思う。ただ、安定稼働にコストも割くので、テストを書くのはコアな機能に限定するなど、見極めが必要だとも感じた。

forEachのネストが深くなって困った話

テストケースの組み合わせ

mochaで単体テストを書いていて、テストケースの組み合わせが増えて困った。
webシステムの単体テストだと、ドメインが異なるケース、クッキーの値が異なるケースなど、同じ機能を、異なるテストデータでテストすることがあると思う。
その時、テストケースを配列として扱って、forEachを用いてテストケース毎にテストを実行していた。 実際はループ毎にもう少し複雑な処理をしている。

describe('test', function () {
  Hoge.forEach((hoge) => {
    Fuga.forEach((fuga) => {
      Foo.forEach((ooo) => {
        it(`Hogeが${hoge},Fugaが${fuga},Fooが${foo}の時`, function () {

        });
      });
    });
  });
});

問題点

上のように書くと、ネストが深くなってコードが読みづらい。

解決策

そこで、 https://github.com/dankogai/js-combinatorics
を使う。 これを使って配列になっているテストデータの直積を取得すると、

const Combinatorics = require('js-combinatorics');
const cp = Combinatorics.cartesianProduct(Hoge, Fuga, Foo);
describe('test', function () {
  cp.toArray().forEach((element) => {
    it(`Hogeが${element[0]},Fugaが${element[1]},Fooが${element[2]}の時`, function () {

    });
  });
});

のように書ける。
テストデータの組み合わせでforEachのネストが深くなっている方は、使ってみてはどうだろうか。

転職して1ヶ月たった

1ヶ月で出てきたやつら

• JavaScript(ES2015以上)
• Node.js
• React
• PHP
• CodeCeption
• Apache
• MySQL
• CentOS
• Docker
• Vagrant
• AWS

とくにJSとAWSの技術がうちのチームでは必要とされているみたい。支給PCはMacBookProの2016年モデル(メモリ16GB、HDD256GB)

変わったこと

• 予定管理

Excelファイルをファイルサーバで共有　＞　グループウェア

「〇〇が編集中のため編集できません」ってよく表示されたのが懐かしい。

• コミュニケーション

口頭、電話　＞　口頭、Slack

客先からの電話にでることはなくなった。

• 進捗管理

上記Excelシートや、Redmineに入力するためのExcelシート　＞　Googleスプレッドシート、Drow.ioを共有

• 前職と比較してミーティングが多い(特にストレスはない)
• Slackとの付き合い方を考えねば(仕事があるのに関係ないやりとりも見てしまう)
• ヤクルトのお姉さんまたいた
• ExcelやWordを記入することがほとんどなくなった

転職した人がするべきこと・考えるべきこと

• 前職で感じたことは記録して残しておく

文化が違う場所に行くと、なれることに必死であっという間に前職のことを忘れてしまう。（自分もだいぶ忘れた。）自分が経験してきたこと・感じたことは、将来の意思決定でも非常に重要な要素の一つなので、同じ轍を踏まないように、記録しておくと良いと感じた。日常的、あるいは転職先の内定が出たときに、まとめて整理しておくのがベスト。

• 転職活動を振り返る時間を確保する

転職先では「入ってみてどうか」という質問は何度か受けることになると思う。しかしそれはあくまで、現職側のことだけなので、自分の中で前職と比較してみて、自分はどういうことを仕事にしたいか、どういう環境で働くと楽しいか、ということを確認してみるのが良いと思う。

あとは生き残る。以上。

転職した

転職した

思ったことをつらつらとメモってゆく。

 転職活動における成功を定義する 

転職を成功させる秘訣は目的を明確に定義すること、これに尽きると思う。

仕事の軸は、

• 内容
• 給料
• 人間関係

だと考えている。

これをどう変えるかを明確に定義する。

自分の場合は内容を第一に考え、目標通りの会社に転職できた。

ほかは、給料をX万まで上げる。〇〇さんや〇〇な人たちと一緒に働くなど。

転職の目的やゴールを決めず、なんとなく転職したり、嫌なことから逃げることだけにとらわれて転職しても、次の転職先でも結局同じことで失敗するだろう。

また、設定目標のすべてを満たすことは難しいという心構えを持つ。目的に優先順位をつけ、それを満たすような会社に転職する。

使った転職サイト

• リクルートエージェント
• レバテックキャリア
• Green
• FindJob
• Paiza

エンジニア向けの転職サイト・エージェントがあるのでそれを使ったほうが良いと感じた。営業色が強く「とりあえず応募しましょう！」みたいなノリや、技術のことをあまり理解していない業者がいるのも事実。

あとは噂に聞いていた全く転職者のプロフィールを見ていない、一方通行のスカウトメールもあった。会社の評判を下げるだけなのでやめたほうが良いと思う。

市場価値

VisualBasic.NETの市場価値ェ。。。

転職エージェントからは「Web業界だとJava、PHPですよ！」（サーバサイド志望した時の反応）と散々言われた。
市場感(市場で求められるスキル、出ている求人数)に関してはエージェントが言うことは間違いないだろう。

ネット上で盛り上がっている、流行りの技術を使うのは一部ということであり、現実として2017年現在では上記に価値があるということか。

面談のむずかしさ

自分が思った以上に面接官に自分のことが伝わらない。

書類で説明したつもりでも、うまく伝わっていなかったり(忙しくて職務経歴書を読み込む暇もないのかも)、 自分がアピールしたい部分と違う部分を拾われたりして、なかなか言いたいことが伝えきれなかったように思う。

あとはSkype面談なるものを初めて経験した。面談前に音声やカメラのチェックは必須。自分の場合、普段Skypeを使わないので事前に友人と練習した。

じつりき

実力をつけるしかない。技術力、思考力、筋力を身つけてタフに生き残ってゆくしかない。やらなければやられる。これからもやっていく。

以上です。

TDDBC Toyama #1 ２日目

いってきた

tddbc.connpass.com

メモ

リファクタリング

• 課題として出されたライフゲームをリファクタリングしていく

レガシーコードのジレンマ コードを変更するためには、テストを整備する必要がある。多くの場合、テストを整備するためには、コードを変更する必要がある。

レガシーコード改善ガイド読書メモ - Anger Driven Development

まさにこれが出た。

方法としては２つあって

1. テストが無いままで安全に変更できる状況を考える
2. 振る舞いを変えること無くテストできるか検討する

バグを直すということ

バグを直す===振る舞いが変わる
また自分がバグと思っているものは実は仕様かもしれない(途中からプロジェクトに参画して、ドキュメントなどが無い状況など)
動いているコードがすべての事実。コードの振る舞いを保つことを考える。変わりそうだったら上長に相談。

KPT

Keep

• テストに保護されるの最高。これで変更のたびに「どうか壊れていませんように」と祈らなくてすむ。
• リファクタリングの実践的な手法を学べた
  　動いているコードをリファクタする時はまず振る舞いを保つように保護する。その時も、
  • 手で行わずIDEのリファクタ機能を使う
  • Lintをかける
  • 静的解析ツールを使って複雑度などを調べる
    などなるべく機械的に変更できる手段から実践していく。
• ペアプロの楽しさを体験できた
  他人のコーディングを間近で見れる(IDEやエディタのホットキーなどのこだわりが垣間見れる、優秀なプログラマのコードの書き方、思考ステップなどの知見が得られる)

Problem

• ペアプロの難しさを体験できた
  • 役割分担(ドライバー、ナビゲーターがなかなか交代できない)
  • 意識合わせ(今回だと、どういう思考でリファクタしていくかというのを逐一確認し、二人がその思考に合わせて行くのが難しかった。一人だと思考を柔軟に変更できる。)
• コードを壊したくなる
  • 破壊衝動に駆られる。
    すぐにコードの振る舞いを変えるような変更を加えたくなったが、ナビゲータの方が制止してくれた。まだTDDが体に染み付いていない。
    対策：既存のコードの振る舞いを保証することを念頭に置く。焦らずTODOリストに落とし込む。現在動いているコードが絶対。２年前の先輩*1に敬意を表する。
• TODOの粒度
  要件定義===テスト設計だと思うのだけど、その落とし込みが難しく感じた。どの程度の粒度で考えるか。粒度が細かすぎるとテストがやりづらいという話も上がった。

Try

• 写経(TDDはセンスではなくスキルなので高めることができる)
• TDDBCの途中になっている課題を終わらせる
• テストファーストで作ってみる

雑感

１日目の深夜まで語り合ったり遊んでたりしたみたいで、早く寝ずに参加すればよかったと少し後悔。。。
朝１からクソコードレビューしたり、夜にこだわりのホットキーの話したり、エンジニアが集まってワイワイ話すのはほんとに楽しい。
是非また行きたいと感じた。

*1:動くクソコードを残して去った先輩のこと、合宿の会話中に何度も出てきた