4月の振り返り

4月の振り返り

すっかり書くのを忘れていました。もう5月も終わりに近いですが、書いていこうと思います。色々あり過ぎた月で外では言えない内容が多数なので書こうか迷っていました。とりあえず、やったことだけ書いていきます。

1、概要

この月は先月の続きアプリのグロース(機能追加)をしたり、テスターをしたり、デバックしたり、自社開発のアプリに連動するアプリを一から作ったり、ローカルの環境構築手順、開発フローを書いたり、PRのレビューをしたりと、色々とあった1ヶ月でした。

2、4/2〜4/5

未読フラグの続きで、どこにコードを書くか問題から始まりました。

結論はDecoratorに書くということで解決しました。そもそも、Decorator何それ美味しいのみたいなところからのスタートでした。

簡単に説明すると、モデルに書くべきか、ヘルパーに書くべきか考え、どちらとも言えない場合に使うものらしいです。下記の記事を参考になんとか解決しました!

https://qiita.com/jonson29/items/00077b54bb91ed74fdb8

無事にメソッドも書き終え、終わりかと思ったが、今度はオブジェクト指向がなっていないコードだったのでその修正に励む。ただ動けば良いコードはプロとして許されないことを悟る…

とりあえず、困り果てたので、『オブジェクト指向設計実践ガイド』(技術評論社)を読んでみるがいまいち理解が乏しい。

この時のオブジェクト指向の理解は、関係のない部分に追記したメソッド、コードを反映させない様にすること、クラスメソッドとインスタンスメソッドを使い分けるということぐらいでした。

オブジェクト指向は一種の哲学でもあるとのことなので、深く考えるのを一度やめました!

とりあえず、テストコード(RSpec)も書き、PRも承認され、デプロイが完了したので、この機能は終了!

3、8〜12日(表示部分にURLがあれば、URL対応にする)

まぁ、この辺から、仕事以外の部分で色々あったのですが、この部分は割愛します。(知りたい人はリアルであった時にでも私にい聞いてください。笑)

この機能に関しては、Railsで一度やったことがあったので、楽勝だと思っていました。真面目にやるなら、正規表現、楽するなら、gemかなぐらいの検討がついたので、いけると思いました。

gemは勝手に入れれないので、早速、gemfileを確認すると、自分が使ったことのある`rails_autolink`は存在しない…、真面目に正規表現を使うのかなとも思ったのですが、確か、『現場で使えるRuby on Rails5速習実践ガイド』(マイナビ)に別のgemもある様なことが書いてあった(181頁)ので、そのgem`rinku`を探す。

見事、gemfileの中に`rinku`があった!(流石トップエンジニアの方々作るアプリ!)

使った事はなかったので、早速GithubとQittaで使い方を確認する。内容はrinkuとほぼ一緒だったので、実装自体は簡単でした。実装自体は…

実装したのに参考にした記事

これで機能自体は実装できたのですが、rinkuを使う部分が<a>タグ内にあるため、表示が崩れてしまう。

上記の様に<p>タグをobjectにする事で解決できました。

参考記事は以下のものです。

これで、機能も表示も完璧、終わりと思っていたが、ここからjenkins、Rubcopとの戦いが始まる…

ここからは、不毛な内容が続きの過程は省略し、結論だけ書くと、sanitizeなど色々と使ったが、Rubcopをスキップするコードを実装し、XSS問題は大丈夫だと結論づけて頂き、終了!

12日に普通にこのアプリを使っていたら、エラー画面になることを報告したところ、それは仕様だから良いと怒られたが、後々、これはバグとして、私が改修することになる(4月終わりの話)

4、15〜16日

別アプリのテスター業務に励む、2日かけて、一人でユーザー側の全機能、表示画面の崩れの確認をしなければならなかったので、大変でした。今回もテストの仕様書はないので、自分で場合分けし、同値クラステスト、境界値テストを行いつつ、全画面の表示崩れのテストをする(表示を崩す際は、膨大な文字数を入れたり、空欄したりするのが得意技です。)

以前も書いたきもしますが、テスト攻撃パターンで参考になるのは以下の記事です。

【テスト入力パターン集】Webフォームの単体テストでチェックすべき18のポイント

 

5、17〜26日(新規アプリ開発とデバック作業)

急に色々とあり、やる事が変更し、当初の予定とは大幅に変更が起こり、アプリのグロースは中断され、別タスクを振られることになる。

自社で開発中のサービスと連動したサービスを待機の人でも作れる簡単な技術を選定して作れとのお達しが来たので、作成に取りかかる…

  1. モックアップ
  2. ローカル環境での環境構築の仕方(現在不具合発生中)
  3. 開発フローのやり方(masterにpushしり、エラーが表示されるままpushする人がいたため、作る…)
  4. 実装する機能(一覧、詳細、検索機能のみなので3日で終了)
  5. 待機中の人にタスクを振り、PRのレビューをする
  6. もともとグロースしていたアプリのデバック作業
  7. わからない事をちょくちょく聞かれ、解説する

新しく作り始めたサービスは4でも書いた通り、一覧、詳細、検索機能のみだったので、簡単にできました。好きなgemを入れてもいいし、基礎的な内容しかなかったので…

ただ、デバック作業の方は、トップエンジニア達が作ったサービスなので、様々な制約のもと開発するので、なかなか苦戦します。そもそも、バグ原因を特定するところから、苦労するし、間に2つの別のサービスに関与するわで、色々忘れているしで、本当に大変でした…

・やったデバック作業

①ツイッター投稿をクリック後に、500エラーになる原因解決。

わかると、凄く簡単なのですが、全然わかっていなく苦労しました。

エラーになっていた原因は、投稿後のURLにidでなく、そのユーザー名をURLに渡したかったにもかかわらず、redirect_toに変数を設定していなかったのが原因でした。

参考にしたサイト

https://railsguides.jp/layouts_and_rendering.html

2.2.1 Action Viewを出力する

実装したコードは以下のみ

redirect_to topic_path(@topic.user, @topic)
結局、これに行き着きまでに半日かかってしまいました…(猛烈に反省しました…)
出来なかった原因を探ると、redirect_toに変数を設定できることを完全に失念していたのが原因でした。
一度、idでバグ出ないようにして、PRを求めたところ、本質的な問題が間違っているということで、やり直し回り道もしてしまいました。本当に申し訳ないなかったです。
まぁ、無事、解決もし、本番環境でも問題なく動いたので、よかった。
②Twitter APIの認証を一度だけにする
この画面を2度目以降のログインでは表示しないようにする。(これはバグという訳ではないですが…)
この原因を究明している最中で、TwitterAPIの記事を読み漁り、あたりがついた頃で4月は終了しました。

6、まとめ

この月もやる事は盛り沢山でしたが、先輩エンジニア達の協力もあり、何とか乗り切れました。3月からずっと本当に感謝しかないです。
リモートワークでのやり取りは本当に大変だが、先輩エンジニアはそれでもわかるように教えてくれるので、すごいなとつくづく思っている

コメントを残す

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

ABOUTこの記事をかいた人

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