ふわふわにっき

日々の学習記録などを書いていきます

2024年の抱負

こんにちは〜ふわです。

2024年もよろしくお願いいたします。

去年に引き続き、今年も今年の抱負を書いていこうと思います！

エンジニアとしての抱負

1. 技術力を高める

めちゃくちゃざっくりしていますが、これが一番の目標です。

年明けから現場に入ることになり、わからないことだらけの毎日になると思います。わからないことをわからないままにせず、 少しずつでも知識を増やしていきたいです。

あとは純粋に勉強時間を増やすことが必要だと思うので、意識して学習時間を確保したいですね。勉強するときは集中して、休むときはしっかり休んで、メリハリをつけたいです。

2. 自分なりのスタイルを早く見つける

自分に合った業務の進め方や学習方法を見つけることが目標です。

FBCで学習していた頃は気が向いたら学習するというテキトースタイルだったので、もう少しルールを決めて効率的にやりたいです。

試行錯誤したり、他の人にやり方を聞いてみたりして早く見つけたいですね。

3. アウトプットを増やす

今まであまり技術的なアウトプットをしたことがないので、今年は挑戦したいと思います。

業務中に出てきた疑問をブログにまとめたら勉強にもなるしアウトプットにもなるし一石二鳥！がんばっていこうと思います〜

プライベートな抱負

1. 減量する

腹の肉がやばい。

自炊を増やしたり、キックボクシングで脂肪燃焼したりしてどうにかしたいです！

-5kg、あわよくば-10kgを目指していきたい…！一度でいいから腹筋割ってみたいんですよね〜

2. お金について詳しくなる

お恥ずかしながらお金の知識が全然ないのです…

去年末にNISA口座を開設したので少しずつ投資を始めていこうと思います。

3. 楽器の練習をがんばる

これは毎年恒例の目標ですね。

ギターは何かしら曲を弾けるようになること。

ピアノは指の独立性など基礎力を高めること、調の切り替えをスムーズにできるようになること。

地道にがんばります〜

まとめ

今年は去年よりも目標の具体性が増した気がします。それは未来が前よりも見えるようになったというか、今までが五里霧中だったというか…

目標を達成できるよう、意識して今年は生きていきたいと思います！がんばるぞ〜

2023年を振り返る

こんにちは〜ふわです。

もうすぐ2023年も終わりますね。年々1年が過ぎるのが早くなっている気がします。

個人的にいろんなことがあった2023年ですが、振り返ってみようと思います。

ちょうど去年の今頃こんな記事を書いていたので、どのくらい達成できたのか検証してみます！

去年の抱負たちを振り返る

1. エンジニアとして就職する

達成！

これは達成できました！これが達成できただけでも合格点では？

ただ就職できたのが10月だったので、欲を言えばもう少し早く就職したかったですね…

2. 筋トレをがんばる

それなりに達成？

良くも悪くも普段通りの頑張りだったなーという感じでした。

重量がかなり増えたとかは特にないのですが、フォームを見直したら前より膝や腰の痛みは減った気がしますね。

仕事を始めてからは頻度が落ちてしまったので両立が課題ですね。

(後述しますが)来年からはキックボクシングを始めるつもりなので、しばらく筋トレはお休みしようと思います。早く復帰したい。

3. 減量する

達成できず

むしろ太りました。

仕事を始めてから外食の機会が増えてしまい、明らかに太りました。あかん。

来年は自炊を増やして健康になろうと思います。

4. ギターを買う

達成！

無事に購入できました。

ちょうど中古でいい感じのギターが出てきたので思わずポチってしまいました〜

全然弾けないのですが、ほぼ毎日練習を続けることはできています。来年は何かしらの曲を弾きたいですね。できれば人前で。

5. DTM復帰する

達成できず

ちょっと余裕がないですね…

来年のどこかで復帰できたらいいな〜ってくらいです。(しばらく無理そうかな…)

6. 引越しする

達成できず

お金がありませんでした。無念。

今の家から会社が少し遠いので引っ越したいですが、リモート勤務の割合が高いことと今住んでいる街を結構気に入っていることからもう少し先延ばしにしようかなぁとも…悩ましい。

7. キックボクシング復帰する

達成できず

これもお金がありませんでした。あと時間も。

ただ、来年からは復帰しようかなと考えているのでがんばろうと思います〜

まとめ

去年の抱負で完全に達成できたのは就職とギター購入だけでした！

ただ実質的な目標はほぼ就職だけ！あとはおまけ！という気持ちだったので、それが達成できたのはよかったです。

来年はいよいよエンジニア人生本番開始なので、どうにか食らいついていきたいと思います。

フィヨルドブートキャンプを卒業して、エンジニアになりました

これはフィヨルドブートキャンプAdvent Calendar 2023(Part 2)、13日目の記事です。

こんにちは、フィヨルドブートキャンプ(以下FBC)卒業生のふわです。

FBCを卒業してWebエンジニアになったので、ゆるっと振り返りと近況報告をしようと思います。

FBCを卒業してからの振り返り

FBCを6月に仮卒業

入会が2021/05/03、卒業が2023/06/07、合計学習時間は2056.5時間でした！

2年以上在籍していました。

最初の1年弱は前職をやりながら、最後の半年間は慣れないバイトと並行してということもありますが、もう少し早く卒業したかったですね…

ダラダラとあまり集中しないで学習を続けてしまい、メリハリをつけられなかったのが反省点です。

自作サービスのリリース

7月に自作サービス「CreditsSpot」をリリースしました！

気になる曲の情報を調べられたり、すぐにSpotifyで聴けたりするサービスです。

もし興味がございましたらリリースブログを読んでいただけると幸いです〜

就活開始

リリースが終わってから本格的に就活をしました。

ざっくり以下のような流れでした。

5月末: 受けたい会社を探し始める

6月上旬: FBC仮卒業

6月下旬: Ruby Silverを取得

7月上旬: 自作サービスをリリース、FBCを本卒業

7~9月: カジュアル面談を受けたり選考を受けたり…

9月下旬: 内定をいただく

10月中旬: 入社

ほとんどの卒業生は1~3社の選考で内定をいただいているそうなのですが、私もその例に漏れず幸い内定をいただくことができました。

就活についてはFBCの10月の卒業式動画でも話しているので、FBC生で興味のある方はぜひご覧ください。

就活でやってよかったこと

Ruby Silverの取得

私の場合は自作サービスでRubyを使わなかったため、技術力の証明が欲しいなということで受けました。

取得のためにやったことや、受験してよかったことはこちらにまとめてあります。

面接の際には資格の話題になり、多少はアピールできたかと思います。

チーム開発おかわり

FBCにはチーム開発1のプラクティスがあるのですが、希望者は卒業後でもチーム開発を続けられるのです…！

こちらも同じく技術力の不安解消のためと、実際の業務に近いことをやって慣れておきたいという理由で行いました。

現役生の頃と違って、卒業のためのカリキュラムの一環としてやるのではなく、純粋に技術を学ぶため&業務だったとしたらどうやるか想像しながらやるというチーム開発はより面白かったです。

あと、卒業生という立場だからかはわかりませんが、他の受講生から結構ポイント高めのissueのレビューをお願いされることもあり、いろいろと勉強になって楽しかったです！

もし自作サービスで、受けたい企業で使われている技術を使っていなかったら、チーム開発おかわりはオススメです。

(あと、面接で話すと興味を持ってもらえるかも…)

近況報告

今なにしてるの？

今は自社プロダクトに関する改善作業を行っています。

特に研修といったものはなく、入社初日からコード書けるんだ！とテンションが上がった記憶があります。

エンジニア歴2ヶ月の人の感想

ひとこと感想

入社1週間後の私「プログラミングしてお金もらえるなんてすごい！」

入社2ヶ月後の私「プログラミングしてお金もらえるなんてすごい！！」

だいたいこんな感じです。

が、真面目な感想も書きます…

設計の難しさ＆名前重要を思い知る

今は自社プロダクトに関する改善作業を行っていますが、既存のコードを改善していくのではなく、一から私がコードを書いて進めています。

最初はまだマシだったのですが、機能を追加するたびにパッと見て何をしているのかわからなくなっているように思います。

加えて、担当の先輩にコードレビューをしていただいていますが、特に多い指摘が命名に関することでした。

わかりやすい名前をつけるべき、という意識はあるのですが良い名前が思い浮かばない…！ということがしばしばあります。

こちらでMatzが、 名前重要について言及しています。

適切な名前をつけられると言うことは、その機能が正しく理解されて、設計されているということで、逆にふさわしい名前がつけられないということは、その機能が果たすべき役割を設計者自身も十分理解できていないということなのではないでしょうか。個人的には適切な名前をつけることができた機能については、その設計の8割が完成したと考えても言い過ぎでないことが多いように思います。

私が良い名前をつけられていないのは良い設計ができていないから、ということなのかなと思います。やたら長くて何を示しているのかよくわからない変数をたくさん作ってしまったのは、きっと私もその変数が果たすべき役割を理解できていないということだろうなと思います。難しいです！

今後の目標

年内の目標はRuby Goldの取得です。(現状だいぶ黄色信号ですが…！)

年明けから案件に配属される予定なので、早く戦力になれるよう食らいついていきたいと思います。ここからが本番ですね。

あと、名前重要を意識して業務をしたいです！

おわりに

FBC卒業から現在まで、およそ半年間を振り返りました。

FBC生だった頃に感じていた面白さや大変さと、今感じているそれらは少し質が違うように感じています。

まだ働き始めて2ヶ月なのでエンジニアと胸を張って名乗れるかも怪しいところですが、プロとして求められる水準はFBCの頃とはやはり違います。 他の人が読んで理解できるようにという意識を常に持ってコードを書く必要があるので、そこが大変なところです。(自分ですら理解できているか自信のないところがあるのに…)

FBCを卒業することはゴールではなく、スタートラインに立ったばかりなんだということを実感しています。

ですが、実際にプログラミングを仕事にできるということは本当に嬉しいですね！

FBC生だった頃は「プログラミング向いていないんじゃないか？」という気持ちと闘いながらだったり、自作サービス終盤で作り直しになりかけたりと、楽しいことばかりではなかったのですが、今は卒業してエンジニアになれて本当によかったと思っています。

良いエンジニアになれるよう、精進を続けていきたいと思います。

  1. FBCで使っているWebアプリケーションを実際に受講生が開発するプラクティスのこと。issueを割り振られる→実装する→PRを作る→レビューしてもらう(自分が他の受講生のPRをレビューすることもある)→マージする、という一連の流れが学べる。↩

Vue router + TypeScript環境にて、Cypressでコンポーネントテストを書く ~自作サービスで大変だったところその3~

こんにちは。フィヨルドブートキャンプ(以下FBC)卒業生のふわ(@fuwa-syugyo)です。

先日リリースさせていただいた自作サービスで、大変だったところを振り返るシリーズ第3弾です。

前回はE2Eテストについての記事でしたが、今回はCypressでのコンポーネントテストについてです。

環境

Cypress 12.11.0

TypeScript 4.9.5

Vue 3.2.47 (Composition API)

Vue-router 4.1.6

Vite 4.1.2

リポジトリはこちら

コンポーネントテストにCypressを選定した理由

当初はViteとの相性が良いVitestや、一般的なJavaScriptのテストフレームワークであるJest、Vue向けの公式単体テストライブラリであるvue-test-utilsも候補に入れていました。

しかし、自作サービスではVue router及びTypeScriptを使用していました。これらといずれも相性が悪く、Cypress以外は難しそうという理由で選びました。

例をいくつか挙げると、vue-test-utilsではvue-test-utilsをTypeScriptで使う際のコード例で使われているcreateLocalVue()がVue3では使われなくなっているようで、設定方法がわからなくなってしまいました。

Vitestについてはvue routerを使用する際のドキュメントを発見することができず、マウントができずに断念しました。

大変だったところ

コンポーネントのマウント

コンポーネントのマウントができず、Cypressのコンポーネントテスト画面に何も表示されない状態が続いていました。

結論から述べると、routerの設定が間違っていたことが原因でした。(またしても凡ミスです…)

  • src/router/index.ts
export const routeSettings: RouteRecordRaw[] = [
  {
    path: '/',
    name: 'home',
    component: HomeView
  },
//略
]

const router = createRouter({
  history: createWebHistory(import.meta.env.BASE_URL),
  routes: routeSettings
})

export default router
  • cypress/support/component.ts(該当箇所は3行目)
import { mount } from 'cypress/vue'
import { createMemoryHistory, createRouter, createWebHistory } from 'vue-router'
import { routeSettings as routes }  from '../../src/router' // ここがimport { router } になっていた

Cypress.Commands.add('mount', (component, options = {}) => {
  // Setup options object
  options.global = options.global || {}
  options.global.plugins = options.global.plugins || []

  // create router if one is not provided
  if (!options.router) {
    options.router = createRouter({
      routes: routes,
      history: createMemoryHistory(),
    })
  }
//以下略

cypress/support/component.tsの

  if (!options.router) {
    options.router = createRouter({
      routes: routes,
      history: createMemoryHistory(),
    })
  }

にて、routes:にrouteSettingsを指定する必要がありましたが、routerを指定してしまっていました。

(わかりにくくなってしまっていますが、3行目でroutesという名前としてrouteSettingsをimportしています)

それぞれの変数の型を調べてみればわかることだったので反省しました。

また余談になりますが、routerのhistoryの違いについて学びました。(こちらに記載があります)

  • createMemoryHistory

Node環境とサーバーサイドレンダリングに適している。(本アプリケーションはSPAだが、テストではこちらが適していると考えた)

  • createWebHistory

ブラウザ環境に適している。こちらが一般的なモード。

ページネーション用CSSライブラリが表示されなかった

ページネーション用CSSライブラリとしてvue-awesome-paginateを使用していましたが、Cypressのコンポーネントテスト時にのみページネーション部分がマウントされず、表示されないという問題が発生していました。

Cypressの楽曲検索画面のコンポーネントテスト。赤枠部分に通常はページネーションが表示されている

コンソールに [Vue warn]: Failed to resolve component: vue-awesome-paginate If this is a native custom element, make sure to exclude it from component resolution via compilerOptions.isCustomElement. at <RecordingSearch ref="VTU_COMPONENT" > at <VTUROOT> という警告が出ていたため、当初はvue-awesome-paginateをカスタム要素として扱えば解決するかもしれないと考えました。

しかし、こちらを試みましたが解決しませんでした。

どうすれば良いのかわからなくなってしまったのでメンターの方に伺ったところ、「Vueのmain.ts にプラグインとしてvue-awesome-paginate を追加しているので、Cypress 側の component.ts でも同じようにプラグインとして追加する必要があります」という返答をいただきました。

こちらのドキュメントに従いcypress/support/component.tsにoptions.global.plugins.push(VueAwesomePaginate) を追加し、無事にコンポーネントテストでページネーションが表示されるようになりました。

今回の件について、そもそもvue-awesome-paginateはカスタム要素ではないというところには早く気づくべきでした。エラーメッセージを読むことは大切だと思いますが、そのエラーがなぜ起きているのか？というのをもう少し視野を広くして考えられたら良かったのかなと思います。

まとめ

E2Eテストは比較的スムーズに書くことができましたが、コンポーネントテストでは苦戦しました。

今回のテストの件に限らず、自作サービスでは凡ミスや少し考えればわかることが原因ということも多かったです。これらに早く気がつくには使っている技術の知識量や慣れが必要なのかなと実感しました。

自作サービスではTypeScriptやCypressなど、初めて使う技術をいくつか選定しました。いずれもキャッチアップに苦労しましたが、新しいことを学ぶのは面白かったですし、これから実務となればこういったことはたくさんあるとあるでしょうし良い経験になりました。

これにてCypress編は終了です。もし機会がありましたら次回は使用したAPIについて書こうかなと思います。

お読みいただきありがとうございました！

Vue router + TypeScript環境にて、CypressでE2Eテストを書く ~自作サービスで大変だったところその2~

こんにちは。フィヨルドブートキャンプ(以下FBC)卒業生のふわ(@fuwa-syugyo)です。

先日リリースさせていただいた自作サービスで、大変だったところを振り返るシリーズ第2弾です。

CypressでE2Eテストを書いたので、振り返ろうと思います。(Cypress自体については解説が豊富にありそうなので、ここでは説明を省きます)

第1弾の記事はこちら

環境

  • Cypress 12.11.0
  • TypeScript 4.9.5
  • Vue 3.2.47 (Composition API)
  • Vue-router 4.1.6
  • Vite 4.1.2

リポジトリはこちら

Cypress選定の理由

主に以下の理由になります。

  • FBC生の自作サービスで比較的使われていたフレームワークだった
  • 情報が豊富そうな印象だった
  • 試してみて、書きやすそうだと感じた

「Vue E2E test」で検索するとCypressに関するページが多く出てきましたし、Vueとしても推奨しているため問題なさそうと判断しました。

どんなテストを作成したか

主に以下のテストを作成しました。

  • 楽曲or人物の検索結果と情報が正しく表示されているか
  • 楽曲情報画面で、Spotifyへのリンクが正しいか
  • 楽曲検索結果のフィルターが正しく動作するか

MusicBrainz APIとSpotify Web APIのレスポンスが正しいかどうかが主なテストですね。

モックの使用

上記の通り、主なテストは外部APIのレスポンスが想定通りかという内容です。

テストのたびに外部APIを叩くというのは時間がかかりますし不安定です。特に、検索結果は時間経過で変わっていくので今は良くてもいつかは落ちてしまいます。そのため、テストダブルを使うことにしました。

テストダブルの選定

今回はモックを使うことにしました。入力を考慮する必要はなく、出力が正しいかどうかだけを見れば良かったのでスタブやスパイは使わなくて良いと判断しました。

今までリクエストをモック化したことがなく、イメージを掴むのに少し苦戦しました。こちらの動画で学習しました。

Cypressで外部APIへのリクエストをモック化する

公式ドキュメントを参考に、テストコード内のMusicBrainz APIとSpotify Web APIへのリクエストをモック化しました。

以下は実際のE2Eテストの一部です。楽曲検索結果が想定通りかというテストです。

describe('Recording search and lookup artist', () => {
  it('Search recording', () => {
    cy.visit('http://127.0.0.1:5173/')
    cy.intercept(
      'GET',
      'https://musicbrainz.org/ws/2/recording/?query=recording:%E9%9D%92%E6%98%A5%E3%82%B3%E3%83%B3%E3%83%97%E3%83%AC%E3%83%83%E3%82%AF%E3%82%B9&offset=0&limit=100&fmt=json',
      { fixture: 'mock_seisyun_page1.json' }
    ).as('seisyun1PageRequest')
    cy.get('input[type="search"]')
      .should('be.visible')
      .type('青春コンプレックス', { force: true })
    cy.get('.search-button').click()
    cy.wait('@seisyun1PageRequest')
    cy.get('.recording-search-table > tbody').contains('青春コンプレックス')
    cy.get('.recording-search-table > tbody').contains('結束バンド')
  })
 cy.get('input[type="search"]')
      .should('be.visible')
      .type('青春コンプレックス', { force: true })
    cy.get('.search-button').click()

で検索フォームに「青春コンプレックス」と入力し、検索するという操作を行なっています。そしてhttps://musicbrainz.org/ws/2/recording/?query=recording:%E9%9D%92%E6%98%A5%E3%82%B3%E3%83%B3%E3%83%97%E3%83%AC%E3%83%83%E3%82%AF%E3%82%B9&offset=0&limit=100&fmt=jsonに遷移します。

「青春コンプレックス」と入力して検索

モック化している部分は以下です。

cy.intercept( 'GET', 'https://musicbrainz.org/ws/2/recording/?query=recording:%E9%9D%92%E6%98%A5%E3%82%B3%E3%83%B3%E3%83%97%E3%83%AC%E3%83%83%E3%82%AF%E3%82%B9&offset=0&limit=100&fmt=json', { fixture: 'mock_seisyun_page1.json' } ).as('seisyun1PageRequest')

  • HTTPリクエストでGETを指定
  • https://musicbrainz.org/~ のアクセスが対象
  • レスポンスはmock_seisyun_page1.json の内容
  • このリクエストの名前はseisyun1PageRequest

という意味です。

cy.wait('@seisyun1PageRequest')と書き、レスポンスが返ってくるまで待ってから、以降のテストに進みます。

これで検索結果の表示が想定通りかというテストが書けました！

実際にAPIを叩いてテストを行なっていたときは時間がかかりすぎてタイムアウトになってしまうことがしばしばあったのですが、モック化してからは爆速でテストが終わるようになって感動しました〜

おまけ Cypress Studioについて

Cypress Studioはブラウザを操作すると、その操作のシナリオを自動的にテストコードに落とし込んでくれます。まだ実験的な機能だそうです。

使ってみての感想ですが、そこまで実用的ではないかなという印象でした。

  • そのままだとエラーが発生してしまい、結局書き直す羽目になった
  • 指定されたセレクタがわかりにくい

セレクタについて、例えばページネーションボタンを押すという操作については自分で書いたものとCypress Studioで書いたもので以下のような違いがありました。後者では子要素の番号で指定してしまい、パッと見てどこを選んでいるのかわかりにくいと思いますね。

自分

cy.get('.pagination').contains('>').click()

Cypress Studio

cy.get(':nth-child(9) > .paginate-buttons').click();

ただし、Cypressにあまり触れたことがない場合どんな書き方をすれば良いのかざっくり掴めますし、どのようなクエリ(getやcontainsといったもの)があるのかを知ることができるので学習目的では結構役に立ったと思います。

まとめ

CypressでE2Eテストを書くにあたって、一番大変だったのはモックの部分でした。初めて触れる部分だったので少々取っ付きにくかったのですが、テストが安定化＆高速化したので私のサービスでは必須だったと思います。

Cypress自体はドキュメントが豊富だったためE2Eテストにおいては大きく苦戦することはありませんでした。強いて言うなら比較的新しいツールなのでChatGPT3.5に聞いても参考になる答えが返ってこなかったことくらいでしょうか。ただしそれはE2Eテストについてのみの話です。

次回はCypressでのコンポーネントテストのお話を書こうと思います。

Vue Routerを使用時に、queryを変更しても反映されなかった問題の解決 ~自作サービスで大変だったところその1~

こんにちは。フィヨルドブートキャンプ卒業生のふわ(@fuwa-syugyo)です。

先日リリースさせていただいた自作サービスで、大変だったところを振り返るシリーズを始めようと思います。記念すべき1記事目です！

環境

  • TypeScript 4.9.5
  • Vue 3.2.47 (Composition API)
  • Vue-router 4.1.6
  • Vite 4.1.2

リポジトリはこちら

概要

自作サービス(CreditsSpot)にて、検索結果画面からページを切り替えずに連続して検索するとページが更新されないという不具合が発生していました。

例: 「ミックスナッツ」の楽曲検索結果画面

例えば「ミックスナッツ」と検索した後に、続けて同じ画面で「アイドル」と検索すると検索結果画面が「ミックスナッツ」のままで更新されないという状態になっていました。

やったこと

原因の究明

Vue Routerにおいてはクエリのみが異なり、パスが同じ場合は同じコンポーネントが再利用されてしまうため、変更が反映されないということが原因だと考えました。

Vue Routerのドキュメントに記載がありました。

ルートのパラメーターを使う際に特筆すべき点は、ユーザーが /user/foo から /user/bar へ遷移するときに同じコンポーネントインスタンスが再利用されるということです。 両方のルートが同じコンポーネントを描画するため、古いインスタンスを破棄して新しいものを生成するよりも効率的です。しかしながら、これはコンポーネントのライフサイクルフックが呼ばれないことを意味しています。

検索ではtermというqueryに検索ワードを入れて検索結果を表示するという処理にしてあります。

今回の例だと、https://credits-spot.vercel.app/recordings?term=ミックスナッツ → https://credits-spot.vercel.app/recordings?term=アイドル とURLを変更しても同じコンポーネントが使われてしまうということですね。

ナビゲーションガードを使う

こちらに以下の記載がありました。

パラメータまたはクエリの変更は enter/leave ナビゲーションガードをトリガーしない ということを覚えておいてください。それらの変更に対応するために $route オブジェクトを監視する、またはコンポーネント内ガード beforeRouteUpdate を使用するかの、どちらかができます。

今回はbeforeRouteUpdateを使用することにしました。

onBeforeRouteUpdate((to, from, next) => {
  recordingTerm= (to.query.term as string) || '' # recordingTermは検索ワード
  currentPage.value = 1
  onClickHandler(currentPage.value, recordingTerm).then(() => { # onClickHandlerは検索結果を1ページ分に表示する関数
    next()
  })
})

recordingTerm= (to.query.term as string) || ''でqueryの値(=検索ワード)を取得してrecordingTermに代入し、onClickHandler(検索結果を表示する関数)を呼び出しています。

しかし、検索結果画面は更新されませんでした。

検索ワードをリアクティブにする

検索ワードであるrecordingTermがリアクティブ変数になっていなかったことが原因でした。以下のように修正したら無事画面が更新されるようになりました！

const recordingTerm = ref((route.query.term as string) || '')
recordingTerm.value = (to.query.term as string) || ''`

リアクティブにしないとDOMが自動的に更新されない、というのがすっかり抜けていました…

まとめ

Vue Router使用時に、queryが変更されたらページが更新されるようにしたい場合は以下の対応を行えば良いかと思います。

  • beforeRouteUpdateを使用する
  • 更新したいものをリアクティブにする

自作サービスで初めてComposition APIに触れたのですが、リアクティブについて理解を深めることができて良い経験になりました。

Ruby技術者認定試験Silverに合格しました

こんにちは。フィヨルドブートキャンプ卒業生のふわ(@fuwa-syugyo)です。

先日、Ruby技術者認定試験Silverに合格したので勉強法や受験してよかったこと等を書きます。

合格ラインは75点で私は86点でした。

なぜ受験したのか？

一番大きな理由はRubyの復習がしたかったからです。

フィヨルドブートキャンプ(以下、FBC)の最終課題である自作サービスではRubyやRailsを使っておらず、かなり忘れてしまっていると感じていました。

就活に備えて復習するのにうってつけだと思い、受験することにしました。

勉強について

勉強期間

約3週間でした。

一日の平均学習時間は2,3時間程度だったと思います。全く勉強できなかった日や7時間程度勉強できた日もあり、日によってまちまちです。

勉強方法

以下ものを使用して学習を進めました。

  1. REX

  2. 模擬問題

  3. Ruby技術者認定試験合格教本(以下、公式教本)

  4. プロを目指す人のためのRuby入門(以下、チェリー本)

1.と2.

問題の雰囲気を掴んだり、自分がどの程度知識があるかの確認を行ったりしました(ちなみに最初にREXを解いたときは34点でした！自信を持って正解だと答えられる問題が何一つなかったことを覚えています…)。

加えて、知らないメソッドが出てきたらRubyの公式ドキュメントで調べることも行なっていました。

3.

基礎力確認問題を解く→解説を読む→教科書部分を読む→模擬問題を解く→解説を読む　という流れで勉強しました。

4.

模擬問題を解いた後に、わからなかったところや自信のないところの復習として使用しました。

私個人の感想ですが、優先度的には公式教本の問題>チェリー本>>>模擬問題 かなと感じました。公式教本の模擬問題に近いものは本番で多少(3割くらい？)出題されていたと思いますが、他の模擬問題はあんまり出題されていなかったと思います。 ただ、公式教本以外の模擬問題は問題の雰囲気を掴んだりとか、自分がどこがわかっていないかを把握したりとかという点ではそれなりに有用だと思います。何回か解いたら公式教本に進んで良さそうです。

受験してよかったこと

Rubyの知識が増えた

もちろん純粋に勉強になりました。 新しくメソッドを知ることができたり、文法を学べたり、などですね。

特にメソッドの優先順位は興味深かったです。例えば、クラスメソッドが特異メソッドの一種であるというのは知りませんでした。

公式ドキュメントを読みやすくなった？

以前からもできるだけ公式ドキュメントを調べるようにしていましたが、前よりとっつきにくいと感じることは減りました。まずは公式ドキュメントから！と調べるようになったのは良かったです。

書籍をきっちり読むことが大事とわかった

今回の学習で、最も役に立ったと感じたのはチェリー本でした。

教本以外の模擬問題で合格ライン以上を取れている状態にしてから教本の模擬問題を解いてみたのですが、結果は42点と全然理解できていなかったのです。

教本の模擬問題の回答の解説があまり詳しく書かれていないこともあって不安で、基礎からしっかり理解した方が良いかも…と思っていました。そこで登場したのがチェリー本です！

FBCのプラクティスの段階でチェリー本を読んでいたときは「なるほど、こんなことができるんだ〜へぇ〜」くらいの解像度で理解していたのですが、Ruby Silverの模擬問題を体験してからだと「このメソッドは!がついていないけれど破壊的メソッドなのか、気をつけないといけないな」とか「◯◯メソッドと△△メソッドはほぼ同じことをするけれどここが違うのか」とか「演算子の優先順位は…」等と、以前よりも「どこに気をつけて読むべきか」がわかって理解の解像度が上がったと感じました。

基本的には何回かREXを解いて雰囲気を掴む→公式教本の模擬問題を解く→公式教本で間違ったところの解説を読む→それでもわからなかったところ＆不安なところについてチェリー本を読む で合格できるかなと思います。(私は不安なところが多過ぎたのでほぼチェリー本をまるっと読み返すことになりました。)

ちょっとポジティブになった

最近以前より勉強することが楽しいと感じるようになりました。(FBCを卒業して心にゆとりができたというのもあるかもしれませんが、)おそらくRuby Silverの学習が原因だと思います。

チェリー本を読み返してわからなかったところを見つけたとき、「私はこんなことも覚えていなかったのか」ではなく「まだ勉強できることがある！」と思ったことに我ながらびっくりしました。

資格に合格するというわかりやすい形で成長を実感できたのでポジティブになれたのかなと思います。

どのタイミングで受験すべきか？

以下、主にFBC生に向けた話となります。

身も蓋もない話ですが、何を目的にするかによると思います。 私の場合はRubyの復習と就活に備えてという理由だったので、卒業後でちょうど良かったと思います。 もしRubyのプラクティスを終えて、まだ理解が足りていないと感じて受けたいというのならそのタイミングでも良いと思います。

ただ、Rubyのプラクティスを終えたばかりなら受かりやすいか？と言われるとそうではないかなと思います。プラクティスで求められるものと、Ruby Silverで求められるものは結構違う印象を受けました。プラクティスでは調べつつ使えるようになれば良いのに対して、Ruby Silverでは正確な知識が求められます。前者ではエイリアスメソッドとか知らなくても全く問題ないですし。就活がメインの目的であればプラクティスを進めるのを優先した方が良いかもしれません。

しかしながら、早い段階で公式ドキュメントや書籍をきっちり読む習慣をつけられるというのは大きなメリットだと思います。少し寄り道をするのも良い選択だと思いますね。(逆に言えば、すでにできている人にはあんまりメリットがないかも…)

まとめ

ざっくり言うと、Ruby技術者認定試験Silverを受験してよかったと思います！

資格を取るということだけでも有益だと思いますが、私の場合はそれに付随して書籍や公式ドキュメントをしっかり読む習慣ができたり学習が楽しくなったりと良い変化を迎えられたと思います。

興味があればぜひ受験してみてください〜