React.jsを始めてみる(creat-react-appの導入)

React.jsアプリを簡単に作成するコマンドツール、create-react-appを触ったメモ。

わかりやすいQiita記事: Facebook公式のcreate-react-appコマンドを使ってReact.jsアプリを爆速で作成する

導入方法(公式より引用)

npx

npx create-react-app my-app

npm

npm init react-app my-app

Yarn

yarn create react-app my-app

アウトプット

my-app
├── README.md
├── node_modules
├── package.json
├── .gitignore
├── public
│   ├── favicon.ico
│   ├── index.html
│   └── manifest.json
└── src
    ├── App.css
    ├── App.js
    ├── App.test.js
    ├── index.css
    ├── index.js
    ├── logo.svg
    └── serviceWorker.js

開始/テスト/ビルド

my-appディレクトリにて

  • npm start or yarn start
  • npm test or yarn test
  • npm run build or yarn build

参考:CreateReactApp公式 他の参考記事

とりあえずReactのプロジェクトを始めてみる、というのに良さそうでした。


【追記:2019/06/04】

TypeScriptの導入

まだcreate-react-appをインストールしてない場合

npx create-react-app my-app --typescript

# or

yarn create react-app my-app --typescript

既にcreate-react-appをインストールしていた場合

npm install --save typescript @types/node @types/react @types/react-dom @types/jest

# or

yarn add typescript @types/node @types/react @types/react-dom @types/jest

実行後、既存のjsファイルの拡張子を.jsから.tsxに変更する。 (例:src/index.js → src/index.tsx) ローカルサーバーを再度開始(npm start / yarn start)して完了。

参考)

facebook.github.io

Scssの導入

cd my-project #プロジェクトフォルダに移動
yarn add -D node-sass 

既存のcssファイルをリネーム

  • ./src/App.cssを./src/App.scssにリネーム
  • ./src/App.jsの3行目にあるimport './App.css'の拡張子をimport './App.scss'に変更

参考:create-react-appでSassやCSS-moduleを使う方法

Git管理あれこれメモ

Gitの基本操作

気が向いたら適宜このページに追記していく予定。 ほぼ自分用メモ。

ローカルのプロジェクトをgit init してGitHubにプッシュする

流れを忘れてたのでメモ。

前提

以下が完了していること

  • gitのインストールと設定
  • GitHubのアカウント登録

手順

1. GitHubリポジトリを作る
2. Git管理したいディレクトリでgit init

~/hoge(該当ディレクトリ)
$git init
$git add .
$git commit -m "first commit"

3. GitHubリポジトリを登録

$git remote add origin git@github.com:user/repo.git

fatal: remote origin already exists.と出てきた場合
既にremote originの設定がされてるので、一旦削除する。

$git remote rm origin
$git remote add origin git@github.com:user/repo.git

参考:Gitで fatal: remote origin already exists. というメッセージが出る場合

4. GitHubにプッシュ

$git push origin master

ブランチ全部pushする場合

$git push -u origin --all

Git管理したくないディレクトリで設定してしまった場合

~/該当ディレクトリ
$rm -rf .git/

※Git何もわかってない頃にホームディレクトリでgit initしてた🤗

そのうち書くやつ

便利なものたち。よく使う。ググったら出てくる。

退避しとく

git stash

コミットをまとめる

  1. git rebase -i HEAD~n (n個分のコミットを表示)

  2. rebase -iでpickをsquashに変更して、コミットをまとめる(下のものを上に結合)

  3. git push -f する(コミットハッシュが変わるため)

他ブランチの特定のコミットだけ取ってくる

git cherry-pick コミットID

おわり

便利コマンドあればコメントいただけると嬉しいです〜

2〜4月半ば(新規案件リリース)まで振り返り

はじめに

ご無沙汰しております。nskijです。うすいと呼ばれております。
2019年は月報を書くという目標を立てておりましたが、プロジェクトが燃え盛っていたため書けませんでした。(1月振り返りでちらっと書いてましたね)

4月半ばに無事リリースできまして🎉🎉
営業さんにもお客様にも好評で本当に頑張ってよかったです。
月報を書けなかった期間にいろんなことをやらせていただいたので、その辺を残しておきたいと思います。

2月振り返り

モック作成を一人に任される

Webエンジニアとして経験がほぼない状態(当時3ヶ月)で「画面をいい感じに作って」と依頼される。

この時はリリース日だけ決まっていて仕様がほぼできておらず、画面を見ながら仕様を決めたいと企画部に依頼されたため、とにかくそれっぽい画面を作ることになった。

デザイナーはおらず、朝に3画面ほど依頼されて夕方ごろには「明後日の会議で使います」みたいな連絡も来てとんでもなかった。画面数は毎日増えていった(そりゃそうなんだけど)

とにかくCoreUI(VueとBootstrapで作られた管理画面UIのフレームワーク)で画面を作成して、仕様決定会議に使えるものを駆け足で作った。2月中旬にはサーバーサイドエンジニアが書いたPHPに埋め込んで動くものになっていった。

経験できたこと

  • CoreUIを用いたモック作成
  • UI/UXの考慮(知識ある人に相談しながら)
  • 仕様相談と提案(企画部に見せる前に開発部である程度決めたかった)
  • PHP(ほぼ読むだけ)

残業時間は45時間だった。休日出勤が1日。

3月振り返り

1週目

1ヶ月半で作ったものを全て捨てられる

別チームのプロジェクトが終了し、PLがフロントに詳しい人なので見てもらうことになった。(突然PJ入りすることになり、私への共有はなかった)

システムを組み込むことが考えられてないから使い物にならない、自分が2週間で作り直す。とのことで、3日ほど社内ニートになった。
人のコードを読んだり、Web開発の基本を勉強したりしていた。

反省

もちろんここは私にも悪かった点があり、フロント側での制御を全く考えず、見た目だけできれば良いという状態で作ったのが間違いだった。

  • 自分はWeb開発における基本がわかっていない
  • 時間がなかったとはいえ、考慮すべき点は自分で洗い出して知識あるメンバに相談すべきだった
  • 相談していたのはあくまでも「見た目の問題」と「一人では絶対無理だから助けてほしい」ということだけだった
  • 人がいないから無理という回答しかなかった...
  • 上記理由で誰もコードレビューしてくれなかった(※あくまでモックだからだと思いますが)

KARTEの導入

KARTEをプロジェクトに導入したいという話があり、KARTE担当のエンジニアさんに基本的なことを教えてもらった。
(ちょうど仕事がなくなった時だったのでありがたかった😢)

配信メールに使いたいとのことだったので、KARTEの設定とスタイル設定(HTML, CSS, Nunjucks)をやらせていただいた。KARTEというものをここで初めて知ったが、ここまでデータ分析できるのはすごいとちょっとワクワクした。

また、KARTEにおけるカスタマイズが非エンジニアでもできるくらい簡単で驚いた。細かい設定はエンジニアがすることになるが、そこも設定次第で見た目の修正はHTML, CSSの知識がなくてもできる作りになってる。 はてなブログのカスタマイズに近い感覚かな。

KARTEのドキュメント読めば仕組みとか見えるはず。
開発者向けドキュメントはこちらに。

テキストメール配信サービスの(KARTE側の)リリースが遅れたらしく、今回のこちらのサービスでも最初のリリースでは使わないことになった。残念。

3日後に作業がほぼ返ってきた

開発環境は整えられてHaml, Sassが導入された。いくつか画面は作られていたが、自分が過去に作った画面をもう一度作り直すことになった。

2週目

プロジェクト参加者が増えた

仕様が7割ほど決まり、フロント側に人が3人増えたのもあって、なんとか間に合うかもしれないくらいの進捗になった。

バックエンド側は強いエンジニアがいるので、仕様が曖昧でもモノができてきていた(すごい...)。設計段階でしっかり考えられていたんだなと。

モックの時のように工数を捨てるようなことはしたくなかったので、周りの人にとにかく相談した。新しく入ってきた人がタスク振り分けをしてくれるようになり、少し背伸びする程度の課題を与えてもらえるようになった。PHPも書かせてもらったし、CakePHPでの書き方も学べた。

3, 4週目

サービスがだいたい形になってテストが始まり、バグや課題をひたすら修正する作業に入った。1日で50~80個の課題が追加される日々が続いてなかなか厳しかった。

Backlogに上がった課題でできそうなものを見つけては修正していった。手をつけたものの厳しいと感じたら先輩に相談したり、バトンタッチして解説してもらったりした。

この辺で一回倒れてしまった。自分の限界がわかってなかったと反省。

経験できたこと

  • KARTE
  • PHPでの簡単な制御(たまにロジックで考えるとこあった程度)
  • バリデーション周りの修正
  • Controller周りの調査
  • JSでの制御
  • CakePHPでよしなにされるスタイルの修正
  • バッチ配信メールのデータ受け取り設定(インフラの人に教えてもらった)

残業時間は70時間ちょい。12連勤、6連勤とあって厳しかった。

4月振り返り(リリースまで)

本当に間に合うのかかなり不安だったが、1週目には課題がかなり減っていた。常に100以上あったのが50切ってたくらいになってた記憶。

休日が2日取れるようになったが、またもや息切れしたのか39℃超えの熱を出してしまった😇

4月は微修正をしつつテストをしつつ、という感じで穏やかに終わった。 そして無事にリリースが間に合いました🎉🎉🎉
苦労はしましたが、他ではなかなかできない経験になったと思います。

ちなみに私が解決した課題の数は79個だったそうです。頑張ったね💯

その後

リリースの2営業日後が最終出社日となりました。
今回は退職エントリという名のお気持ちを書くつもりはないですが、自身の反省や学んだことくらいは書きたいかなと思います。

この案件を通して「もう少し居てもよかったかもな...」と思うこともありましたが、迷うくらいの時期がいいんじゃないかと思っていたりもします。「こんな会社辞めたるわ!!」みたいな心境ではないのも、支えてくれたエンジニアのみなさんのおかげです🙏

現在

次は関東に引っ越すことだけ決めており、転職活動中です。

なかなか博打打ちな選択になりましたが、これもまた人生。
良い選択だったと言えるように動いていきたいと思います。