30代後半未経験からのエンジニア挑戦!!
ゆーわけで、システム開発系企業様に正社員として入社させていただく運びとなりました。やったー。
11月にTechCampを受講した時は、正直自分がエンジニアとして転職できるか、というのは半信半疑でした。調べれば調べるほど、30代後半未経験での就職がいかに厳しいか、という情報はゴロゴロ出てきますから。
ま、就職できなくても教養になれば良いか、という軽い気持ちでの受講でした。お金返ってくるしね笑
まあよしんば入れたとしても卒業から最低3ヶ月の転職活動は覚悟しとこうかなあとかは想定してました。まさか半月で入れるとは。しかもTechCamp紹介企業。すげえな。
学習の所感としては、まあ随分と贅沢な使い方をしちゃったかなあ、と。悪く言えば勿体無い使い方。
というのもエンジニア、ゆーか社会人として必須のスキルとして「質問力」が挙げられます。で、TechCampではこれをゴリゴリに推奨してきます。分からない事があれば聞く、担当コーチとの定期面談でも必ず「ここまでで分からない事がありますか？」と聞いてくれます。まー、いつでも質問できる環境、て事ですね。で、私はこの環境をほとんど利用しませんでした。
なぜなら私には質問力が決定的に欠落しているからです。説明だけ聞かされて何質問していいか分かりません。学習はもっぱら、実際に試してみて詰まったらカリキュラムや外部サイト見て攻略する、という方法を用いていたので質問して解決してる人たちよりは進むのは遅かったのではないかと思います。
んー、分からないことって何なんだろ笑 何が分からないかがまず分かっていないからなあ。定期面談や企業との面談でもどんな質問をしようか、事前に考えるようにはなったのだけれど、めちゃんこ時間かかる。最低30分。まるで無くなりかけた歯磨き粉のように捻り出した質問をぶつけてみても、キョトン顔されちゃうことも結構ありました。才能が無いなりにもう少しまともな質問をして行けるようになれれば良いと思います。
ですのでTechCampで得たものはプログラマーとしてのスキルを手に入れた、エンジニアとして転がり込む事ができた、この2点がほとんどですね。使おうと思えばもっと色々できた超高級車に乗り込んで、ひたすらアクセルベタ踏みして直線道路を全力で走っていっただけ、といった感じで、側から見ると勿体無い使い方だったのかもしれないけれど、自分の中ではまあいいや、と思ってます。エンジニアとしてのキャリアをスタートさせるための切符を手に入れる、という唯一の目標を達成する事ができたので。
しかし面白すぎるわプログラミング。これから実際に働いてみてどーなるかは分からんけれど、新しいものを取り入れる事が楽しいと思う気持ちは失わずにいられたらと思います。
纏まりの無い文章ですんません。かしこ。
JavaScriptの学習（触りだけ）
rubyの学習と並行して、JavaScriptを触ってみました。
あっ、ここrubyと一緒じゃんってところも幾つかあって、学習は捗ったと思います。rubyでの記述と比較しながら、学習した事をつらつらと書いてみようかと。
記述はテキストエディタではなく、直接記述して結果が見れるデベロッパーツール使いました。ツールの場所ですが、ブラウザでF12押すとページのHTMLとかが書かれた検証ツールっていうのが出てきます。HTMLの上に表示窓があって、現在「Elements」になってます。
その隣の「Console」をクリックすると出てきます。ターミナルみたいな画面ですね。rubyの学習ではターミナルでirb起動させて色々やってましたが、Javaはこっちで色々やると思います。
・console.log()
カッコの中にテキストを入れてエンターを押すと、次の行にテキストが出力されます。rubyでいうputs です。
・const/ let/ var
const 変数名 = 変数に入れる値
let 変数名 = 変数に入れる値
var 変数名 = 変数に入れる値
という感じで、変数定義ができます。rubyでは変数名 = 変数に入れる値でしたが、Javaは3種類あるんですね。constは再定義および再代入しようとするとエラーになります。1度定義したらずっとそのままな変数というわけですね。
letは再定義のみエラーになります。再代入は可能なので、値は変わる可能性があります。
varは再定義も再代入も可能です。一見使い勝手良さそうですが、どういう類の変数なのかが見た目で分かりづらいので、開発ではほとんど使われないそうです。制約ある方がかえってスムーズに開発できるって考え方はruby on railsに似てますね。
rubyでいう「文字列#{変数}文字列」みたいなこともできます。
Javaの場合は
「"文字列" + 変数 + "文字列"」
もしくは
「`文字列 ${変数}文字列`」
下の例の「`」はバッククォートっていうrubyではあんまり馴染みのない記号です。シフトキー押しながら@マーク押すと出てきます。こっちの方がメジャーな記述方法だそうです。ちなみにテンプレートリテラルって言います。
・if
rubyでもお馴染みの条件分岐です。
if (条件式) {
trueの時どうするか
} else if (条件式がfalseの時の条件式) {
trueの時どうするか
} else {
falseの時どうするか
}
rubyとは同じようでいて微妙に違います。条件式にカッコついてるし。elsifじゃなくてelse ifだし。あと書き方がなんとなくCSSっぽい。もしくはエクスペクテーションか。あ、でも演算子(+ - * / % == != || &&とか)はrubyと全く一緒です。
・配列
変数名 = [値1, 値2, 値3, ....]
というように、こちらもrubyと変わりません。0から始まる添字を利用して値を指定できるのも一緒です。
・for文
繰り返し処理にはJavaではこのfor文を使います。
for (最初の値; いつまで繰り返すの?; 繰り返すと値は変化するの?) {
何を繰り返すの?
}
rubyでは、
いつまで繰り返すの? times do |繰り返すと1ずつ上がる変数|
何を繰り返すの?
end
だったから、かなり違う印象です。なんとなくヘルパーメソッド見たいな書き方。eachメソッドのJavaバージョンとも言えるforEach関数なんてのもあります。
テストコード書きました
今日は一日中RailsのRSpecを使って結合テストコードの学習を進めていました。覚える量、記述する量ともに膨大で、なかなかボリュームのある学習内容だったと思います。本番のプログラミングでエラー出さない以前に、このテストコードでエラー出さないようにしないといけませんね^^;
以下、私が今日学習したメソッド等を書き出してみました。
①Visit
Visit (パス名)と記述することで、任意のパスに飛ぶためのメソッドです。
テストに直接使うメソッドではないですが、テストの開催場所に行くためのチケットといったところでしょうか。大抵最初に使います。
パス名ってどこで確認すればいいんだろって思ったんですが、ターミナルでrails routesかけると出てくるルーティングのPrefixがそれなんですね。でも、GETメソッドの中から該当のアクションを目を皿のようにして探し出すのって、なんとなくプログラミングっぽくないというか、もっと楽して探したいなと思ってます。いいやり方あるのかな。
②have
想定通りの動作をするのかを確認する「エクスペクテーション」という構文で使います。haveは何を確認するのかというと「存在」です。ちなみにこの「何を」を指定する記述を「マッチャ」と呼びます。だからhaveもマッチャです。
haveの右にアンダーバーを引き、もう一個ワードを付け足して、「何の」存在かを指定します。具体例を挙げると
・have_content => テキストの存在
・have_selector => フォームやボタンといった「セレクタ」の存在
・have_link => リンクの存在
等等。記述方法は
expect('[存在する場所等]').to have_●●('[存在するものの名前]')
場所以外に動作も指定できます。（指定の場所をクリックすれば存在するとか、ポインタを合わせれば存在するとか）
haveと●●の間にnoを記述して[have_no_●●]とすることで、「存在しないこと」を確認できます。
③fill_in
フォームに記述をするメソッドです。visit同様にテストのための予備動作ですね。
fill_in '(記述する場所)', with: (何を記述するか)
と記述します。記述する場所の名前はF12を押すと出てくる検証ツールで探し出します。
心憎いのが'(記述する場所)'の右下に設置されているカンマ(,)。これ忘れて20回くらいエラー出しました。
④find
これも同じく予備動作で、行動を指定してコンピューターを動かします。
find('場所').click
と記述すれば指定した場所をクリックしてくれるし、
find('場所').hover
と記述すれば指定した場所にポインタを合わせてくれます。
⑤change
haveと同じくマッチャの一つです。こちらは「変動したこと」を確認します。
expect{'変動する場所等'}.to change { '変動するものの名前' }.by(変動する数)
と記述します。場所や名前の指定について、haveが()で囲むのに対してchengeは{}で囲むのが特徴的です。また変動する場所等のところにfind記述をぶち込んで「このボタンをクリックすると1変動する」かどうかの確認もできます。findも()使う構文なので、左側が()だらけになります。で、「'」を一個つけ忘れたりしてエラーが起きます。
そして極め付けがchange { '変動する物の名前' }。「{」の両サイドと「}」の左サイドは半角スペース一個入ります。詰めるとエラーになります。{'変動する場所等'}は詰めてもエラーにならなかったのに。変なの。
話は横道にそれますが、私コードが上手くかけてるかどうかの検証のため、VSCに直接書き込まず、コンソールで一個一個検証しながらVSCにコピペしてたんですが、時々横着して、5,6個まとめて検証して一気にVSCに持って行ったりとかしてました。で、そのやり方で
expect{'変動する場所等'}.to change { '変動するものの名前' }.by(変動する数)
を打ち込むと、記述は正しい筈なのにエラーになっちゃうんですよね。で、一回コンソール終わらせて再起動して打ち込むとエラーにならないんです。もちろん、最初から１回ずつやってもエラーにならない。
(変動する数)は1でやってたんですが、確認した結果は0だったみたいなので、コンソールでのテスト中に { '変動するものの名前' }の中に何か違う値が入っちゃって、それで今回記述した{ '変動するものの名前' }を認識してくれなかったんじゃないか、それでコンソール閉じたら{ '変動するものの名前' }の値がリセットされて、再起動した時点で認識してくれるようになったんじゃないかと思ってるんですが…
う〜、頭がくるくるぱーしてきた〜、でも気になる〜
GitHubでの作業の流れを勉強しました
今日はそのGitHubをインストールして、使ってみました。
入れてみて特徴的だな、と思ったのが、アプリとブラウザに分かれている点。
そういうツール、最近結構多いですよね。そういうのって大抵「アプリ版」「ブラウザ版」のどっちかしか使わないですが、GitHubは両方使います。
アプリ版は自分のPCの中に格納しておくGitHubで、ローカルリポジトリと言います。
ブラウザ版はクラウドみたくチームで共有するGitHubで、リモートリポジトリと言います。
だからネット環境使えるブラウザで表示させるんですね。
まずローカルリポジトリで「Current Branch」っていうタブをクリックすると「New」ってボタンがあります。最初は「Master」だけだったのを「New」で任意の名前をつけて増やす事ができます。
彼等の事を「ブランチ」と呼びます。
さらに「Master」は「Masterブランチ」、後から自分達で作ったブランチは「トピックブランチ」と言います。
ブランチは枝という意味ですから、Masterブランチは枝の中心、トピックブランチはそこから派生していく細かい枝、といったところでしょうか。
本物の枝と異なる点は、派生して一旦は違う方へと伸びていきますが、仕様を変更した後は、再びMasterブランチへと合流するところでしょうか。変更したらちゃんと「本体」に返してあげないと意味ないですもんね(^_^)
「Publish brunch」っていうタブをクリックするとリモートリポジトリに反映できます。
で、コードをガリガリ書いた後、またローカルリポジトリに戻ってきてみると、なんかリアルタイムで反映されてるみたいです。
左側の「Current Repository」っていうタブの右側を下三角にして「History」ってタブをクリックすると、私のコード記述の歴史が綴られています。大袈裟ですね。すいません。
この歴史書（引っ張るなあ）、名前をつける事ができます。「History」タブの隣にある「Changes」タブをクリックすると、下の方に投稿フォームみたいなのがあります。この投稿フォームのタイトル欄に名前を入れて、送信ボタン（みたいなの）を押すと、名前が付きます。
この一連の流れを「Commit」と言います。
Commitして、右の方にある「Push origin」というボタンを押せば、晴れて仕様の変更がリモートリポジトリにも反映される……訳ではありません。審査が入ります。
「Push origin」ボタンが「Create Pull Request」というボタンに変わりました。クリックするとブラウザが起動します。掲示板みたいなページになっています。このページを「プルリクエスト」って言います。このプルリクエストに「コードを書いたので審査お願いします！」って皆に伝えるんですが、書き方にルールがあります。
一行目に「# What」と書いて、二行目に何をやらかしたのか書きます。
三行目に「# Why」と書いて、四行目に何故そんな事をしてしまったのか書きます。
反省文みたいですね。すいません。因みに文字列の前に「# 」（#の隣は半角スペース一個）と記述すると、その文字列が大きくなります。マークダウン記法って言います。
そのコードをチームの人たちが確認します。この人達のことを「レビュアー」って言います。変なコードが入っているとダメ出しされます。
以前YouTubeで、このダメ出しが100以上あって絶望したって人の動画を見ました。
100を切ったら一人前という事でしょうか。ゴルファーみたいですね。
話を戻して、修正点が無くなると、レビュアーから「LGTM」というコメントをくれます。「Look Good To Me（良いと思う）」だそうです。なんか良い。
かくして無事審査が通ったので、プルリクエストの一番下にある投稿フォームの上に「Merge pull request 」っていうボタンをクリックします。すると「Confirm Merge」にボタンが変わります。「本当に良いの？」っていう意味合いだそうです。仕様を変えるって私が考えている以上に大事件なんですね。
連打すると今度はようやっと、コードがリモートリポジトリに反映されます。これを「マージ」と言います。
作業終了！ めでたしめでたし。
と言いたいところですが、一つ忘れている点があります。反映されたのはリモートリポジトリだけで、ローカルリポジトリは以前のままという事です。みんなで食べる料理を一生懸命作ったのに、自分の分をよそい忘れたというのも間の抜けた話ですので、自分の家に帰ってきたら（GitHubアプリ版を開いたら）、「Current Branch」タブを「master」にして「Fetch origin」タブをクリックします。そして下の方の「Pull origin」っていうボタンを押せば、作った料理を自分の家にも取り寄せる事ができます。これを「プル」と言います。
色々と覚える事が多くて疲れました。
これから超使いまくるって脅されてるので、何度も繰り返し弄り倒して慣れていきたいです。
devise弄りました！
railsの課題でユーザー登録システムを実装しました！ が、それに伴って導入した「devise」覚える事めちゃんこ多くて、思いの外時間かかっちゃいました。。。
model生成するにしてもviewファイル記述するにしても、そんでcontrollerに定義増やすにしても、今までのやり方と微妙に違う！
とくにcontrollerはdevise用のがこっちからは弄れないみたいなので、全てのcontrollerに影響を及ぼすapplication_controllerから干渉、そのうちdevise以外のcontrollerは対象から外すっていう処理をしないといけない、という。まどろっこしい〜( ´△｀)
