git pushしたらPermission denied (publickey)と出た際の原因と対策

こんにちは、カイノです。

 

今日(1/26)からRailsチュートリアルを学習開始しました。

1.4.4 ブランチ、編集、コミット、マージの章を進めていて、

 git push ができなかったため、これに対しての原因と対策+α行ったことを書きます。

2時間くらいメンターさんと一緒に悩んだ末に解決しました(泣)

 

f:id:kaifumi:20200126182929j:plain

 

さっそく結論から

原因

ssh-keygen」の2回目の実行後に公開鍵をBitbucket(もしくはGitHub)に登録しなかったから。

 

つまりどういうことか説明致します。

Gitリポジトリを扱うGitHubとBitbucketのどちらのサービスでも、ローカルとSSH接続する際に公開鍵が必要になります。

RailsチュートリアルではAWSのEC2上でBitbucketを使用しています。

ローカル(EC2)上で公開鍵を取得し、Bitbucket(or GitHub)に登録するやり方は下記リンクを参考にしてください。

https://qiita.com/konuma1022/items/986eb58d4b94bef0c0a5

https://qiita.com/ksugawara61/items/a4f34e5e120bea1732d5

 

ここまでは良かったのですが、問題はこのあとにあります。

一度公開鍵を作成した後、確認と練習を兼ねてもう一度公開鍵を作るコマンド「ssh-keygen」を行いました。

その後、作成した練習用鍵は削除しました。←これが根本原因です。

 

なぜこれが原因かと言いますと、

ssh-keygen」を2回行うと1回目に作成したkeyが上書きされるからです。同名ではないkey名を指定したはずですが、おそらくkey名を変えても上書きされる仕様なのかと思われます。

f:id:kaifumi:20200126185112p:plain

ssh配下に2つの公開鍵があります。

・1回目に作成した「ec2_bitbucket_key.pub」

・2回目に作成した「id_rsa.pub」

別名ですが、ここでは最後に作成した「id_rsa.pub」が有効なSSHアクセスキーになります。

 

不要と判断して削除してしまったので、このままgit pushをしても公開鍵を使う権限が無いですよ〜とメッセージが返ってきます。

 

f:id:kaifumi:20200126183055p:plain

 

つまり公開鍵が上書きされていますので、古い公開鍵を使ってgit pushしてもPermission denied (publickey)ということになります。

 

対策

新たに「ssh-keygen」を実行し、作成した公開鍵をBitbucketに登録。

以下のリンクを参考に行いました。

https://qiita.com/hikaru-light/items/be46dfab4e52ee55a134

すると問題なくgit pushできました。

 

f:id:kaifumi:20200126183245p:plain


 

行ったけど無駄だったこと

※大変勉強にはなりました。

それぞれの下記に貼ってあるリンクを参考に行いました。

①公開鍵の存在確認とBitbucket側の設定確認

インスタンス内のSSH設定を確認とvimで修正

https://qiita.com/katsukii/items/c3df0653ac07d41fe03f

③公開鍵をauthorized_keysに設置

https://qiita.com/youcune/items/2f427979403771f2e03a

④接続先のサーバで所有者とパーミッションが適切に設定されていることを確認

https://qiita.com/youcune/items/2f427979403771f2e03a

⑤known_hostsからエントリを消す

https://kiririmode.hatenablog.jp/entry/20171020/1508485674

Linuxの権限確認と変更(chmod)

https://qiita.com/shisama/items/5f4c4fa768642aad9e06

 

などなど行っていました。長いのでそれぞれの説明は割愛します。気になった方はリンク先をぜひ覗いてみてください。

色々と(自分から見て)高尚なことを行っていましたが、結局は超初歩的な公開鍵の更新忘れというものでした。

何事も基本が肝要ということでしょうか。。。

それにしてもまさか複数回別名で取得した鍵が更新されるとは驚きです。

 

今回のエラーを通して様々な対処を行うことができました。

おかげさまで少しだけエンジニア力高まった気がします。協力してくださったメンターさんには感謝の極みです。

MPはがっつり減って、

親切なメンターさんに「ちょっと休憩しますか」っていつ言おうか考えていたクズっぷりです。・・・汗

 

まとめ

公開鍵の取得を複数回行ったら最後に作った鍵を使ってGitHubなり、Bitbucketに登録する。

 

 

 

スクール課題アプリ完成後の振り返り

こんにちは、カイノです。

 

スクールが始まって6日経ちました。

毎日コードを書いて、本日スクールの最終課題アプリ開発が終わりました!

 

メンターさん曰く「いままでに無いくらい早い」と言っていただけました。事前学習をはりきって進めていたからではあります。

個人的にはとても難しかったですが、なんとか終わりました。

 

f:id:kaifumi:20200121191158p:plain

 

作ったアプリは基礎的な「本のレビューアプリ」で

内容としては

・本の投稿・一覧・詳細・編集・削除機能実装

・ユーザーの一覧・詳細・編集機能実装

・deviseの実装

・ログイン状態による見え方の調整

・画像投稿機能実装

・部分テンプレート実装

・Bootstrap仕様に変更

・テスト解析後のエラー対応

などです。

 

あっさりしているように見えるかもしれませんが、わからないことが沢山ありとても苦労しました。

その度に調べて、試して、それでもわからなければメンターさんに聞くを繰り返してました。

 

困った時に助けてくれる存在がいるって本当に助かります。

助かってはいますが、

わからないことがあってもすぐ聞くってことはしなかったですね。

自走力も鍛えなきゃいけないので、まずは自分で調べてからです。 

 

やっていくうちに気づいたのですが、

「あ〜難しい、なんだこれ〜」って感じたわからないことは一度でも分かってしまえば、

「なんだ簡単だな〜」ってあとからは思います。

 

つまりは難しいことが簡単なことに変わりました。

難しいこと→簡単なことに持っていくまでに時間をかけ過ぎてはいけないなと思いました。

 

技術的な点で

特に苦労したのでは以下の2点です。

 

・部分テンプレート実装後のビューとコントローラー調整

・devise.rbを不必要にいじったことによるエラー対応

 

1つ目は「部分テンプレート実装後のビューとコントローラー調整」です。

部分テンプレートの説明からしますと、

以下のサイト見てもらうと詳しく載ってますが、

https://qiita.com/okamoto_ryo/items/026b43e965a1180113ba)

通化しているHTML構造の部分を一括にまとめたものを部分テンプレートといいます。

メリットは

・繰り返し再利用できる
・繰り返し書くコードを一回で済ます
・修正するときに修正箇所が少なく済む

ですので、手間が減って便利ですが、表示するビューで求められるインスタンス変数などが定義されてない状態になりがちです。

そのためno methodエラーを吐き出しまくりました。

それぞれのコントローラー・アクション、ビューに条件定義などの設定を根気良くしていってなんとか実装できました。

 

メンターさんにアドバイスもらった内容で

部分テンプレートはアプリ開発ワイヤーフレームを作る段階で決めてしまえばスムーズに作れるそうです。次はそこを意識していきます。

 

 

2つ目の苦労した点が「devise.rbを不必要にいじったことによるエラー対応」です。

いじったことによるエラーの対応数自体は1つじゃなく何個もあるのですが、一番きつかったものをご紹介します。

 

初心者にありがちかと思いますが、変えちゃいけないところを変えちゃったんです。

何が良いか何が良くないか分別がつかない少年のように、あれこれいじっちゃいました。

そのおかげで勉強にはなりました。(笑) 

 

devise.rbとはログイン機能を司るdeviseというGemの設定事項が書かれているファイルです。

ざっくり言いますとここを下手にいじるとログイン機能などにおいてエラーになります。

 

#config.request_keys = [:name]

私はこのデフォルトでコメントアウトされている機能をなぜかハッシュタグを外して適用させていました。

そのためにdeviseでnameを求める機能ではことごとくエラーになりました。

 

何が原因かわからず、デフォルトを確認するとコメントアウトしといてよかったんだと気付きました。

詰まったら絶対リソースやデフォルトを確認しようと思いました。

 

他にもなんやかんやありまして、

あとはrspecというテスト解析Gemを使って、エラー箇所をつぶしていき、なんと完成しました。

テスト解析後、70個エラー出たので白目になってました。

 

 

今回の課題を通してアプリ開発の基礎を学習することができ、なんとなく要領を掴むことができました。

 

まだまだわからないことが多いので引き続き勉強していきます。

 

エラーメッセージを出したいときのコントローラー上でのrenderメソッドの使い方 [Rails]

こんにちは、カイノです。

 

投稿失敗時に出すエラーメッセージが出るように設定したにも関わらず出せなかったので、これは困ったとなっていました。

 

原因はrenderでした。

 

コントローラー上に書いたrenderによって画面遷移が他のアクションを介さずに行われるため、インスタンス変数の指定をしてあげる必要があります。

 

そもそも

renderメソッドとはレスポンスの出力をしてくれるメソッドです。
renderメソッドを使うことで、ユーザーへのレスポンスとして送信すべき内容を指定することができます。
コントローラー、ビューで使う事ができます。(下記参照)

忘れがちなrenderメソッドの使い方まとめ [Rails] - Qiita

 

ざっくりと説明しますと、指定したHTMLファイルに直接飛んでくれます。

処理が軽くなり、実用向けです。

 

こちらがbooksというコントローラーのcreateアクションの記述です。

 

f:id:kaifumi:20200116174438p:plain

@がついていないローカル変数を使っていることに注目してください。これにより、renderメソッドによる遷移先にもし@のついたインスタンス変数があった場合はビューファイルへの受け渡しができません

 

indexファイルを見てみると、

2箇所に@のついたインスタンス変数がありますので、先程のrender前に@の定義が必要になります。

f:id:kaifumi:20200116174954p:plain

f:id:kaifumi:20200116175016p:plain

 

アクションの修正後がこちら

f:id:kaifumi:20200116175200p:plain

@がついたことにより、ビューファイルへ受け渡し可能になります。

 

 

そしてエラーメッセージを表示させるeach文にも、下記のように@のついたインスタンス変数があります。

f:id:kaifumi:20200116175346p:plain

 

先程renderで@をつけて定義してあげたので、ちゃんとエラーメッセージも表示されるようになりました!

 

 

補足:renderの書き方

①render :アクション

②render("コントローラー/アクション")  ※コントローラーの前に/(スラッシュはいりません。) 

コピペする時は全角スペースを生みかねない

こんにちは、カイノです。

 

モデル作成後にマイグレーションをデータベースに反映するため

$ rails db:migrate(もしくはrake db:migrate)

をされると思いますが、

 

今回、全角スペースが原因でエラーになったので自戒オンリーでアウトプットします。

 

f:id:kaifumi:20200112171831p:plain

 

こちらが問題のマイグレーションファイルですが、

6行目データ名の「text」の後ろにスペースが大きく空いています。

空いている事自体に大きな問題はありませんが、ここが全角スペースになっています。

 

見た目じゃほとんどわかりません。教材のモデル作成コードをコピペしたのですが、

そのコードの後ろになぜか全角スペースが配置されていて(教材からの刺客??)

この全角スペースが原因でエラーになっていました。

 

後ろのスペースごとコピペしてしまった私はまんまと罠にハマってしまいました。

 

他の部分に原因があるかと思ってずっと探していたのですが、結局これでした・・・(泣)

 

ターミナルでエラー文を一部抜粋すると

undefined method `text  ' for #<ActiveRecord::ConnectionAdapters::SQLite3::TableDefinition:0x0000560b594a25a8>

 

上記のように出ていました。

ここでtextの後ろに余計に多いスペースがあることに気付きます。

エラー文ちゃんと読んで、もっと早く気づくべきでした。

 

全角スペースを消してもう一度実行すると問題なく動きました。

 

学習中のコードのコピペは理解できてればする派ですが、必ずしもそのコードがあってると限らないのでそこは自己責任ですね・・・

エンジニアキャリア論のイベントに参加してきました

こんにちは、カイノです。

 

エンジニアキャリア支援をされている渋谷にある企業の「20代エンジニアのキャリア論」というイベントに参加してきました。 

 

タイムスケジュールは以下のような流れでした。

19:30 ガイダンス (10分)

19:40 講義(45分)

20:25 質疑応答(10-20分)

20:40 懇親会

 

講義の内容はざっくりこんな内容です。

・エンジニアは貴重な存在ということ

・年収の目標はどこか

・同世代のキャリアパスイメージ

・3年目&30歳までになっていてほしい姿

・キャリアアップのためにやるべきこと

 

 

f:id:kaifumi:20200110112344j:plain

 

講義の詳細を備忘録的サムシングとして以下に記載します。

 

エンジニアは貴重な存在ということ

・全労働人口の中でITエンジニア割合は1%。

・転職求人倍率は10%前職中圧倒的TOP

・IT人材不足。このままでは日本が終わるレベル。

・プログラミング教育必修化でエンジニアは増えない。高まるのはITリテラシーのみで、英語の必修化によってみんなが英語を話せていないことが良い例。

 

年収の目標はどこか

・幸福度の臨界点は600万円らしい。

・日本人の平均年収は430万円くらい。

・まずは600万円を目指してほしい。

 

同世代のキャリアパスイメージ

・技術レベルが上位5%、10%のエリートになれなくても、上位20%に入らないとエンジニアとしてやりがいを持てない。

・上位20%とは

  • 3年目時点では、SIerをしていて同僚のレベル感に愕然として個人で技術力を上げる手段を勉強会などで模索し、Web系言語の自主学習を始めるぐらい。転職も模索しだす。年収300 ~ 400万円。
  • 30歳時点では、上位10%の3年目あたりと同じくらい。メガベンチャーの普通の人 or 中規模ベンチャーのエース。上がいることを痛感しつつ、より好待遇な職場を求めて同規模 or メガベンチャーに転職する人も。年収500 ~ 600万円。

・技術だけでなく、それを活用した別のスキルも磨くことが大事。

 

3年目&30歳までになっていてほしい姿

・3年目になるとポテンシャルではなくスキルで評価される。

・3年で1万時間=その道のプロになって「しまう」

・30歳でベテラン扱いになる

・何か(実績、スキル、人脈、地位)がないと対外的に相手にされない

・自分の時間が圧倒的に減る(部下の教育、結婚、出産)

・体力が明らかに落ちる(二日酔い、肉、徹夜)

・誰も怒ってくれなくなる、アドバイスくれなくなる

・少なくとも30歳までに20%に入ったほうが良い

 

キャリアアップのためにやるべきこと

・良い環境に転職

・転職は1つ上のレベルの会社を目指す、入社時はその会社の中間より下で良い

・自分でインプット・アウトプットをする

 

転職はそう簡単に出来ないよって方には以下がオススメされてました。

↓オススメ行動順

◎副業、アルバイト

◯勉強会講師

◯趣味で何か作る

◯ブログを書く

△勉強会参加

△プログラミングスクール

・上記の内容は3ヶ月でOK、その間はすべてプログラミング、受験と比べれば余裕

・コツは仲間をつくる、期限をつくる、転職活動をする

 

 

 

質疑応答

f:id:kaifumi:20200110131812p:plain

一番に質問しました。

Q.未経験かつ中途からエンジニアを目指す場合どういったキャリアを目指すと良いでしょうか?

A.プログラミングをしていってポートフォリオやサービスを作って経験を積んでから上位20%の会社を目指していくことが良い。

未経験ですぐ就職活動してブラックな会社に入ると良い経験ができない。

 

他の方の質問

Q.WEBエンジニア4年目からフリーランスへのキャリアチェンジはしないほうが良いでしょうか?

A.受注した案件をこなすのみでスキルの切り売りになってしまい、エンジニアとしてのキャリアアップは見込めない。収入や技術レベルを上げなくても良いのならフリーランスはオススメ。

↓以下の記事にも触れてました。

ブロガー界隈の有名フリーランスエンジニアを見てプログラミングを始めないでくれ - 渡るネットは嘘ばかり

 

Q.WEB自社開発のデメリットは?

A.スタートアップの会社だと仕様がコロコロ変わる可能性や深夜までやることも多い。没頭したものが価値貢献に至らないという可能性も。自社開発だからすべて良いわけではもちろん無い。大きいメーカー系SIerやユーザー系SIerの方が良かったりもする。

 

Q.未経験からVR人工知能、データサイエンティストを目指すことはどう思いますか?

・専門性が高くなればなるほどTOPにニーズが集中しやすい。

・汎用性も低く、市場の展望が読めないので先行きは怪しい。

・信じてやった人が栄光をつかむ可能性はある

・データサイエンティストは強い人が多すぎて(質問者:27歳未経験だと)辞めたほうが幸せ。

 

質問が終わり、その後は懇親会でした!

参加者同士で学んだことやキャリアについて話し合っていました。私もアドバイスをいただいたり、お話盛り上がった方とライン交換をさせていただいたりしました。

 

主観まとめ

エンジニアとして高いキャリアを歩む人たちに対して自分の立ち位置はどこなのか、自分はどうなりたいか、そしてどんな行動をしていくかを決めてコミットしていくことが大事。

WEBエンジニアにゼロから転職することは無理ではないが、相当な努力が求められる。

共同開発に参加することになりました

こんにちは、カイノです。

 

エンジニアへの転職を目指して勉強始めてからまだ2週間ぐらいのひよっこ中のひよっこですが、

WEBサービスの共同開発をメンバーになりました。

 

タカモリさん(@takamoriWebtube)という方が運営している「エンジニアステーション」という未経験者が集まるslackがあるのですが、

こちらに参加していまして、

 

とあるチャンネルで共同開発を練習するメンバーを募集している・・・・!とのことで

 

f:id:kaifumi:20200109192259j:plain

 

おお!やりたい!

これはせっかくの機会だ!参加してたくさん勉強しようと思い、参加希望のお願いをしたところ快諾してくださいました。

 

こうして、初心者であるものの共同開発するメンバーの一人になりました。

 

これからWEBCAMPというプログラミングスクールに入る予定で、そこの2ヶ月目のカリキュラムでチーム開発ができますので、後からでもチーム開発でできるはできます。

 

ですが、このようなネット上で知り合った方と共同で開発することは、いまのなんの経験もない状態でさせてもらえるというのは、本当に貴重ですので思い切って参加しました。

 

f:id:kaifumi:20200109192333j:plain

 

他のメンバーの方は自分よりITの世界に詳しい方のため、お話聞いているだけでもとても勉強になります。難しい言葉など出るたびに聞いてみたり、調べたりしています。

 

業務と違って、ちょっとしたフランクな関係ですので知らない用語はその場で質問できることがかなりのメリットだと思います。

 

もちろん、アプリ開発をしていくために必要な工程を参加者として見て触れてるとインプット量は非常に多くあると思います。とても楽しみです。

 

普段の勉強に加えて共同開発のこともやっていくとなると単純に分量が増えるため忙しくはなります。

けれどこちらの方が自分にとって大きなメリットがあるような気がしています。

エンジニアにとって勉強することももちろん大切ですが、勉強しながら制作していくことが最も大切だと思っています。

 

制作を通して多くを学んで行きたいと思います。

paramsはどのように管理されているか

こんにちは、カイノです。

突然ですけど、paramsって難しくないですか?( ;∀;)
Rails勉強している人なら確実に経験する項目だと思います。

なんとなく理解して通り過ぎようかとしてましたが、
よくよく考えてみると後ろでどうなっているか気になって調べてみました。

初心者の方だとわかってるようで意外とわかってない部分になりがちかと思います。
調べたり、人に質問してみてわかったことをアウトプットしていきます。


参考サイト
Rails入門説明書】paramsについて解説
web-camp.io

Rails入門】params使い方まとめ
www.sejuku.net



まずparamsとはparametersの略で直訳で媒介変数というものです。
【媒介変数】変数の間の関数関係を、間接に表すために用いる変数。 関数x=f(t)とy=g(t)とからxとyとの関数関係が定まるときのtのこと。※コトバンクから引用

で、なにをしてるかですが、
Railsで送られてきた値を受け取るためのメソッドです。

送られてくる情報(リクエストパラメータ)は主に、getのクエリパラメータとPostでformを使って送信されるデータの2つです。
特にRailsのページ遷移で情報をやりとりするときに使われていますね。

普通ですとこれを聞いて「あ、そうか、そうなんだ」で終わりだと思うのですが、これは後ろでどうなっているかとかこのままじゃわからないですよね。

これではparamsが結局何かを理解していきたいと思います。


f:id:kaifumi:20200105232022p:plain

これはURLにposts/1を末尾付けています。
postsがテーブル名で最後の数字が何番目のレコードかを表しています。

この時、実はすでに以下のように数字の1はparamsのハッシュとして渡されています。
Parameters: {"id"=>"1"}

これは以下のパスで確認できます。
/Users/ユーザー名/Desktop/アプリ名/log/development.log

これによって
アクションを使う時に入れるpamas[:id]の値が引き出されています。

f:id:kaifumi:20200105233547p:plain

上のようなアクションですね。


さらにですが、
どうしてもparamsの中に何が入っているか気になるときにはbainding.pryが便利みたいです。
binding.pryでデバッグする方法 - Qiita


Railsというフレームワークが用意してくれた便利なツールとしてparamsがありますが、他にもたくさんあって、それらの便利さだけに慣れてしまうと肝心の技術力が身につかないですね。

自分自身のparamsの理解がまだ浅い気がしますのでもっと注意深く勉強していきます。