【Github】push時に "! [remote rejected] master -> master (shallow update not allowed) " と出た時の対応
背景
portfolioでも作ろうと思って、昔mkdirしてgit init して放置していたportfolioと言う名前のディレクトリの中身を消去して、 Githubに作成した空のリポジトリにpushしようとしたら、こんなエラーが出た。
! [remote rejected] master -> master (shallow update not allowed
原因
古い.gitが残っているのが原因らしいので、portfolioディレクトリから削除してみる。
$rm -rf .git
削除後、適当にgit initしたりgit remote add origin hoge.gitして、もう一度pushしてみると無事成功した。
フロントエンド未経験のバックエンドマンがReact・Reduxの学習に利用したもの(1週目)
はじめに
バックエンド(RoR)からフロントエンドに転向してReact書くことになった自分が、ここ1週間で利用した学習リソースをまとめておきます。
React.jsそのもの
React Tutorial
React.js公式のチュートリアル。 三目並べを実装しながら、Reactの基本的な機能を学習できる。
一通りの機能をさらえるので、やっておいて損はないと思う。ただし、このチュートリアルで書くコードはあまり直感的ではないので、
プログラミング初心者だと少し手が動かなくなる場面があるかも。( もう少し親切なチュートリアルにすればいいのに )
Redux
Redux Tutorial for Beginners
https://www.valentinog.com/blog/react-redux-tutorial-beginners/
Reduxは、Reactと併せてよく使われる、state管理に使われるライブラリ。React自体の状態管理とかなり思想が違うので、初めは戸惑うが慣れてしまえば大丈夫。このチュートリアルでは、簡単な記事投稿アプリを実際に使いながら、Reduxとは何かを学べる。また、Webpack・babeあたりの知識が浅くても、チュートリアル作者がボイラープレートを用意してくれているので、環境構築の心配をする必要はない。結構分かりやすかったので個人的にはおすすめしたい。
Getting Started With Redux
Redux: The Single Immutable State Tree from @dan_abramov on @eggheadio
英語の動画シリーズだが、実際にコードを入力しながら、Reduxとは何か、丁寧に説明してくれる。公式ドキュメントを読む前に見ておくと理解しやすくなるかも。
強い先輩にコードレビューで指摘された「命名」のまとめ
はじめに
このエントリーでは、たまたま自分より圧倒的に強い先輩エンジニアの方にコードを読んでもらう機会があり、 その時に指摘されたポイント・自分で考えたことについて記述します。
※Ruby on Railsのコードについてレビューを受けていたので、その体で説明していきます。
指摘されたこと
自分が先輩に指摘されたのは、実装そのものというよりは、 命名 に関するものが中心でした。
1.命名は仕様と一致させる
例えば、 omniauth + devise を使った外部SNS認証を実装しようとしている際に、自分はSNSの uid provider をUserモデルにAuthentication(認証) という名前でモデルを作成して保存しようとしていました。そこで先輩エンジニアに、「omniauthによって認可された情報を扱うモデルになるので、Authenticationではなく Authorization(認可) が適当ではないか」という指摘をいただきました。
認証と認可、言葉の響きは似ていますが、実際に意味するところは異なっています。 適当に命名した結果「モデルの名前とモデルのやっていること」が一致していない実装 を行ってしまいました。
もしも、自分が英語の意味を間違えたままクラス・メソッドの命名を行ってしまった場合、後から他の開発者がそのコードを利用する際に混乱することは必至です。 なんとなくで命名していくのではなく、「 この処理・仕様を表すのに、自分の命名は適切か？ 」を考えるようにしなければいけないと感じさせられました。
2.命名規則を揃える
自分はあるモデルに、クラスメソッドとして、 create_from_hoge create_by_fuga のようなメソッドを定義していました。 これら二つのメソッドは、fromとbyという命名上の違いはあるものの、動作上は同一の実装になっていました。その実装を見た先輩から、「 *似た動作を行うメソッドなのに、命名規則が異なるのは違和感がある 」と指摘をいただき、両方とも create_from... に命名を揃える修正を行いました。
似ている動作を行うメソッドの命名を揃えることによって、「 実装を読まなくてもメソッド名だけである程度同じ動作をするメソッドであることが推測できる 」というメリットがあります。逆に、似ている動作をするメソッド同士なのに命名がバラバラになっている場合、命名から動作を予測しにくくなるため、コードを読む必要が出てきてしまい、可読性が悪くなってしまいます。
特に命名を分けたい理由がない場合には、なるべく命名規則を揃えていきたいと感じる出来事でした(大規模プロジェクトだと崩壊する気もする)。
気づいたこと
Lintを入れて、テストを書いて、フレームワークに則って行った実装については、そこまで酷くなることは少ないように感じています。 フレームワークに沿わないことをビジネス上多くあるから酷くなるじゃないかとかそういうことは置いておいて、何より自分に欠けていたのは 「 他の開発者に優しい命名 」という考え方です。 正確には気をつけていたものの、他の人から客観的にコードを見ていただくことで、まだまだ足りていないということが意識できてよかったです。
この「命名」というテーマ以外にも、自分一人でコードを書いていたら、きっと気づけないバッドプラクティスとか修正点とかがまだまだある気がしているので、 仕事でもプライベートでも書いたコードはガンガン人に読んでもらうようにしたいと感じました。
おまけ
命名補助サービスなんてものもあるらしい codic - プログラマーのためのネーミング辞書
それよりは英語でググって「自分が今からしようとしている実装の命名を、英語圏の人はどうしているか」を調べたほうが力がつくかもしれません。
Heroku Review Apps + Railsの環境構築
今日初めてHeroku Review Appsを弄ったので設定のメモ。
Heroku Review Appsとは
Review Apps | Heroku Dev Center
Herokuが提供している、プルリクエスト毎にステージング環境を作成してくれる機能です。 勝手にデプロイまでやってくれるので、実装者はアプリ側のコードを書くことに集中できます。 また、コードのレビュアーは気になる箇所の挙動について実際に動作を確かめることができるので、レビューがしやすくなります。
本当はこんな感じ 「ECS を使って PR ごとに検証環境を用意した話」というテーマで登壇しました！ - SmartHR Tech Blog でやるのがいいんだろうなぁと思いつつ、 Herokuで十分な時はReview Apps良さそうという所感です。
Review Appsの導入
*Herokuへのデプロイ、Githubへの連携は既にできている前提で書きます。
1.リポジトリの設定
ブラウザ上でHerokuにログインし、Review Appsを導入したいアプリケーションを開きます。
アプリケーションを開いたら、deployタブをクリックしてください。
その後、Deployment methodを Github に変更します。
Connect to Githubの列で、検索フォームからReview Appsを使いたいリポジトリの名前を検索し、Connectボタンをクリックしてください。
次のような表示になったら、リポジトリの設定に成功しています。
2.パイプラインの設定
リポジトリの連携が終わったら、続いてパイプラインの設定に移ります。
Add this app to a pipelineにある、Choose a pipelineをクリックし、Create a new pipelineを選択して下さい。
すると、パイプラインの名前と、パイプラインをどのステージに追加するかを入力するフォームが表示されるので、好きなように入力して下さい。
パイプラインの作成に成功すると、パイプラインの管理画面にリダイレクトされます。
一番左にあるブロック内の、"Enable Review Apps" をクリックして Review Appsの設定を行います。
Review Appsを利用するためには、リポジトリ内にapp.jsonという設定ファイルを作成する必要があります。
もしもリポジトリにこのファイルがない場合、app.jsonを作るよう促すモーダルが表示されるので、 "Create an app.json File" ボタンをクリックします。
すると、作成するapp.jsonの内容をGUIで決められるページに遷移します。Railsアプリの場合、ScriptsのPost deploy script (optional)に、"rails db:schema:load db:seed"など、デプロイ完了後に初期化するためのコマンドを入力しておきます。
また、環境変数を、親となるHerokuアプリケーションからコピーしたい場合、Environmentの項目を追記する必要があります。
やり方は、環境変数の名前を入力して、Copy at Build Timeを選ぶだけです。(選ぶだけなのに認証で使っている環境変数を渡していないことに気づかず小一時間ハマった)
設定が完了したら、ページ末尾の "Commit to Repo"ボタンを押すと、Github上のリポジトリの、masterブランチにapp.jsonが作成されます。 後からこのjsonファイルを編集して設定を変更することもできるので、気になる方はHerokuのドキュメントをご確認ください。
Review Apps | Heroku Dev Center
3.プルリクエストを作成する
ここまで来たら後はプルリクエストを作成するだけです。masterブランチから適当なブランチを切り、変更をプッシュしてプルリクエストを作成すると、 プルリクエスト毎に環境を作成してデプロイを行ってくれるようになります。
特に変更がなくてもデプロイしたい場合は、Create Review Appボタンを押すことで手動で実行できます。 また、デプロイまで完了するとプルリクエスト上に完成した環境へのリンクが投稿されます。
その他 デバッグ用
「通常のHerokuへのdeployは上手くいくのに、Review Appsが建てる方は上手くいかない」時は、heroku log -t --app ReviewAppの建てた環境の名前をターミナルから実行すると、どんなリクエストが行われているか、どんなエラーを吐いているかを確認できるのでオススメです。
感想
結構楽にステージング環境を作れるReview Appですが、もしも実運用されてるアプリに導入したい場合、アクセスできるIPとかを絞るのが面倒臭いな〜〜とか思いました(Heroku全体そうだけど)。
個人開発とかではガンガン使っていきたい。
技術ブログ始めた
始めまして。yujima(https://twitter.com/yrljm)と申します。 2017年の8月からプログラミングを始め、現在は都内のベンチャーでRuby, Rails, JS各種(ES6, Node, React, Vue)などを触っています。
毎日いろんなことを勉強しているはずなのに、気が付いたら忘れてしまうようなことも多々あり、 技術ブログを作成してまとめておくことにしました。
あまり畏まった内容ではなく、ちょっとしたメモとして量を書けたらと考えています。 よろしくお願いいたします💪🐱
