5月の振り返り

5月の振り返り

 

今月も充実はしていのですが、本格的に月後半からはめちゃくちゃな状態になってきた感がすごかったです。

 

1、5月7、8(TwitterAPI編)

ゴールデンウィーク明けは、「TwitterAPIの承認を一度だけにする」問題を修正するところからスタートしました。ついでに、新しく入った方の環境構築の手伝い。

まず、TwitterAPIを使うために実装したgemを確認すると、下記の通り

  • oauth
  • twitter

これらを元に、調べていくと、TwitterAPIのデフォルト設定では、承認が毎回行われるようになっているらしい。

・参考内容

これらを元に調べた結論はURLによって毎回承認が出るか、出ないかをが決まっていることがわかる。

  1. 毎回でるパターン   :  Get  oauth/authorize  (デフォルト)
  2. 毎回出ないパターン:  Get  oauth/authenticate

以上の様に設定されていることがわかる。ここまで分かれば、あとは、必要な所のコードを修正すれば、終了。

・適用したコード

以上で終わりです。わかっていれば、本当に簡単でしたが、そもそも何が原因で認証が毎回起こっているのかを調べるまでが時間がかかりました。ついでに、何回かjenkinsおじさんに怒られましたが、無事修正も完了し、レビューも受け、タスクが完了。

2、5月9日(デプロイと簡単な修正編)

この日は、修正したコードをdev環境と本番環境に反映させて、自分で問題ないか確認する作業が始まる。通称デプロイ作業、すごい簡単にいうとAWSにあげる。

デプロイというと凄そうですが、ただ決まった手順に従って、コマンドを実行し、テストし、報告すればいいだけなのです。

・必要なもの

  1. sshキー
  2. 接続情報

・手順

  1. ~/.ssh/にキーを登録
  2. ~/.ssh/configに情報を追加(Host、Hostname、user、IndentityFile)を設定
  3. sshの該当キーでAWSに接続する

あとは、ローカル環境でコマンドを実行する。

ローカル環境のアプリのルートディレクトリに移動する。

開発環境と本番環境へのコード反映のコマンドをそれぞれ、実行する。

・基本的な反映作業フローまとめ

  1. レビューが通ったPRをmasterにmergeする/してもらう
  2. masterブランチのテストが通ったら、開発環境にデプロイ(テストとはjenkins)
  3. 開発環境で対応箇所の動作をチェックする
  4. 開発環境での動作チェックに問題がなければ、上司等に本番反映の確認と了承をとり、本番反映ができたら、上司等に報告
  5. 本番環境でも念の為テストをする。

こんな感じでデプロイ方法を学んだので、先週までに修正したコードを本番環境にデプロイするところまで自分にやる様になる。

ただ、このアプリに関しては、もう修正もグロースもしないとのことなので、ここで終了する。

もう一つの開発中のアプリは実装の指示だけ出して、PRをレビューする流れで行く予定だったのですが、上手くいかず、あまり相談もされず頓挫する…(4月までは、上手くいっていたので、今月から入ってくる人もそれでいけると思っていたのですが、そうはいかず、自分の想定力の無さを反省していました。)

ついでに、AWSも自分でこれらの環境を作れる様にならないと、いけないのだが…

3、5月10(新しいアプリの引き継ぎ)

勤務時間外の朝突然、今日から新しいアプリの引き継ぎをやってもうらうと言う指示がくる。前任者は全くそんなことを聞いていないという感じで、いきなり気まづい空気になるが、なんとか了承頂く。(本当に有難い、上司でした。)

この日は、残りのデプロイ作業とアプリ引き継ぎのための準備で終わる。

ここら辺から、SESとしての面談に行くことになるが、来る案件で面接に行くのがほとんどテスター(ブラックボックステストメイン)、言語はjavaで全く開発はできない感じの案件ばかりくる…

そして、自社開発の手伝いは市場的に価値は無いので、なんでもいいからきた案件に行くとのがいいと言われる始末…個人的には、たまにオフィスに来る経験者の待機の人の話を聞いている限りだと、自社開発の手伝いの方が遥かに高度な事をやっていると思い、外部の情報を集める事にもする。

4、5月13〜17(アプリ引き継ぎ編)

本格的に引き継ぎ開始とりあえず、環境構築、gitlabの設定、必要となるfacebookの設定などを済ませ、とりあえず、アプリを触ってみる事にする。

どんなアプリであるのか、どういう機能があるのか、環境構築の手順などをまとめる作業を始める、ついでに、コードを読みつつ、スペースやインデントも修正する。もちろん色々な部分を修正するのでコンフリクトも起こすので、マージを使ってコンフリクトも解決する。ここで、なぜか、社長にコードの1行1行に意味を書いていくのが良いのではと言われ、受託で受けているコードであるにと思い困惑し、結局、独自メソッドとかにはコメントをつけてあったのでスルーする。

この辺からコロコロアプリが変わり把握するも直ぐに別のアプリに変わり、把握できなくなるので、とりあえず、ER図を書いてすぐに理解できる様に工夫する。

大人の都合で公開できないので、別アプリのER図ですがいつも以下の様に書いています。

 

17日に突然、先輩エンジニアのコードをレビューする事になり、焦る…

急ぎではないという事なので、月曜日にレビューするでも良いという事なので、土日で、必死にコードレビューの仕方を勉強する。内容はググって調べた内容と『リーダブルコード』を必死に読み込み、Githubの先輩エンジニア達がどのようにレビューしているのかをCommitから必死に追うがイマイチこれだというものが解らず、絶望する。(そもそもどうレビューしているのか実際に見た事も聞いた事もないので、わかるか!と開き直りたい気持ちもあったが…)

こんな時、Twitterでレビューについて投げたら、親切にもご助言を頂ける方がおり、「コードを読んで疑問に思ったことを聞けば良い」ということを教わり、これだと勝手に確信する。

このお方の@work_haru_0628 ご助言でした。Twitterで私が死にそうにしてると、いつもサッと助けて頂いてます。本当にありがたいことです。

5、5月20(コードレビュー本番)

もう小手先の技術は辞め、しっかりコードを読み込み、疑問に思った事を聞く戦術でいく事にした。

結果:大成功だった!(いい指摘だと、褒められ浮かれる!、褒められた記憶は片手で収まるほどの数しかないが、その1つでした。)

 

6、5月21〜28(自社開発アプリ編)

引き継ぎの方がひと段落したので、別アプリの開発へ…

やる内容はカラムを1つ足し、新規登録と編集ができれば良いだけなので、秒で出来ると最初は勘違いする…

実装内容:新しい項目の登録、編集、表示

・実装方法は以下の通り

  1. string型のカラムを追加
  2. 入力フォームを作成し、プレイスフォルダを表示する
  3. コントローラにストロングパラメーターを追記
  4. バリデーションをlimit:25で設定する
  5. ymlファイルを使って、日本語表記にする
  6. Reactを使っているため、jsonを追記
  7. Reactの表示画面のコードを修正する
  8. 実装部分の単体テストをする
  9. RSpecを記述する(複数のモデルに関与しているため、様々な部分にコードを書く)
  10. CI(jenkins)を通す
  11. デプロイして頂き、dev環境と本番環境で単体テストを行い、終了!

1〜5まではマイグレーションファイルを使わない方法もしっかり抑えており、楽勝でした。入力、編集、表示する部分が結構あったので、全部に反映させるのが大変だったぐらいでした。

6、7、9までで問題発生…

Reactが関連しているのはわかるが、React自体が全く分からず、どうして良いのやら…

とりあえず、ググってみるも全く分からず、表示するためのコードを書かれているコードを元にコピペして、表示しようとしても、何故かDBからのデータが表示されない。SQLproでもデータは確認出来ているし、Reactを使っていない部分では、登録も編集も表示も出来ているのにと詰まる…。

分からなすぎて、金曜日にPRだけ出すも、土日でReactを勉強(Progate、本屋で立ち読み)し、20日にレビューして頂く前に、原因に気づく!(結論:Reactを使っているため、jsonを追記することでした。)、自力で解決し、褒められ、再び浮れる!

自分の思考過程は、React以外では、問題なく機能が使え、Reactの部分でのみ、データが表示されないことから、Reactでもデータを作るんじゃないみたいな発想になり、ググり無事答えに行き着きました。表現が正確でないのはまだ、Reactがしっかり理解出来ていないのでご了承ください。

9に関しても一箇所複雑過ぎて、どうしてもjenkinsが通らないテストコードがあったのだが、この部分(1行だけ)はレビューを頂き、先輩エンジニアに修正して頂いた。

27日にようやくJenkinsまで通し、デプロイ手前までいく。この日はSESの案件面談(ソースコードjavaで、ブラックボックステストメインの案件)もあり、デプロイとデプロイ後の単体テストは次の日にして頂く事になる。結果:数人での面談だったが、粒が揃っていないという事を理由に落ち、後日資格も取っていない奴がいると遠回しにディスられる…

28日、マスターにマージするもjenkinsが動かずトラブル、その後、鍵を持っていないので、デプロイして頂き、dev環境と本番環境で単体テストをする。軽微なバグではあったが、バグが発生し、急いで修正し、当日に無事解決!

7、5月29〜31(再び引き継ぎのアプリ)

昨日直したアプリに再びバグがあったということで、 早急に問題箇所を確認しに行くも本番環境にコードが反映されていなかっただけなので一安心する。

実装内容:削除したデータを復活させる実装でした。

論理削除と物理削除の違いと用意されているフラグの値を変えるだけだったので、割と簡単に出来ました。

・実装方法

  1. deleted_atカラムがあったので、値のあるものをスコープで絞る
  2. その他必要なフラグをアクションの時に変更する
  3. フラッシュメッセージを修正する

この実装は見積もりをゆっくり見過ぎていたとの事で、見積もりが甘いと指摘される。(29日の午後からのだったので、31日と見積もるも、実際は実装自体は30日の午前で終了する。)レビュー、デプロイの都合から完全に終了したのは31日になったが…

5月はちょこちょこ面談練習やら、社員登録をやったり、待機の方にDMで他のアプリについて聞かれたりで、なかなか落ちつかない感じでした。マルチタスクが本当苦手…

8、まとめ

仕事の勝手はだいぶ分かってきたが、色々と崩壊してきた事は先輩エンジニアの動向から何分かっており(先輩エンジニア達はリモートだけど笑)、また案件もとにかく経験を積むためにテスターでも何でもいいから行けと言われるし(入社するときはこれだけコード書けたら、開発から入れると言われたのに…)、また、遠回しに自社でどんなに出来ても市場的には無価値だと言われるわ、最近は頑張っていないと言われるわで、自分の場合はここではもうロクなキャリアを築く事は出来ないと思い、転職活動も同時並行でやっており、正直過労気味でした。定時に帰って、転職活動や業務で分からない事を本屋で調べたり、勉強会に参加していたので、会社内では頑張っていないように一部の人からは見えたのかもしれませんが…

チームメンバーの先輩エンジニアからは、頑張っていると一定の評価は常に得ていた気がするのだが、内情を知らない人からの評価は低い感じだった。その先輩エンジニアも次々に辞めていくが…

色々あり過ぎ、充実もしていましたが、精神は磨耗していた感じでした…(無料のslackでそれぞれのアプリの開発チャンネルがあるのにいちいち一部の人だけで、DMのグループ作って連絡取り合うのは本当辛かった、誰が何知ってて知らないのかがさっぱり分からないし、情報が全く整理出来ず、発狂していました家で…)、開発するアプリもコロコロ変わってこの状況は困り果てました。

こんな感じの1ヶ月でした。良くも悪くも大変でした。6月の振り返りも早めに書きます。

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

ABOUTこの記事をかいた人

29歳のWebエンジニア/中央法→大手証券会社→プログラミングスクール→Webエンジニア(2年目)/現在は神奈川に住みながらプログラミングをメインにTwitterやブログで発信してます!