RIT Tech Blog

株式会社RITのエンジニアが知見を共有する技術ブログです。

getStaticPathsやgetStaticProps、getServerSidePropsなどが突然消える

こんにちは!エンジニアの川野です。

台風が過ぎ去って夏本番の暑さですね。怖い話でも聞いて涼みたいたいということで、 今回はVSCodeで表題の関数が突然消えるという恐怖体験について書きました。

心霊現象

Next.jsで開発をしているとき、下の画像のようなエラーに度々遭遇しました。

度々遭遇するエラー
度々遭遇するエラー

Server Error
Error: getStaticPaths was added without a getStaticProps in /posts/[id]. Without getStaticProps, getStaticPaths does nothing

This error happened while generating the page. Any console logs will be displayed in the terminal window.

直接の原因はエラーメッセージのとおり、getStaticPathsが書かれているのにgetStaticPropsが書かれていないというものでした。

ただ、実装し忘れてそうなったのではなく、実装してあったgetStaticPropsが突然、何者かによってファイルから消されてしまったのです。getServerSidePropsについても同様に消されてしまうことがありました。

消えたコードを履歴から戻せばエラー自体は解決するのですが、毎回30秒ほど時間を奪われるので原因をしっかり調査しました。

環境情報

  • VSCode: 1.58.2
  • TypeScript: 4.2.3
  • ESLint: 7.23.0

原因

その何者かは、VSCodeの到達できないコードの削除機能とsettings.jsonの設定値でした。

VSCodeにはreturnthrowの後方の、プログラム的に到達不可能なコードを削除する機能があります。

たとえば、以下のようにコードを書き、returnの後方のコードで cmd + .を押すと、Remove unreachable code とコマンドが出てきます。

到達不可能なコード
到達不可能なコード

実行すればもちろん消えてしまいます。

Remove unreachable code 実行後
Remove unreachable code 実行後

そしてこの機能はsettings.jsonで下記の設定をしていると、save時に発動するようになってしまいます。

settings.json

{
    "editor.codeActionsOnSave": {
        "source.fixAll": true
    }
}

解決策

もちろんsource.fixAllfalseにすれば突然消えるということはなくなるのですが、それではESLintのフォーマットが動作しなくなってしまいます。

以下の設定にすればESLintのフォーマットだけ動作するようになりました。

settings.json

{
    "editor.codeActionsOnSave": {
        "source.fixAll.eslint": true
    }
}

参考:Valid "unreachable" code is being aggressively removed as a result of syntax errors when allowUnreachableCode: false #109530

フォーマットされなくても、到達不可能コードはESLintが検知してくれます。
disallow unreachable code after return, throw, continue, and break statements (no-unreachable)

到達不可能コードはESLintが検知
到達不可能コードはESLintが検知

無事、解決できました!

Next.jsでブラウザの「戻る」を検知して確認ダイアログを表示する

こんにちは!エンジニアの川野です。 歓喜に湧いた東京オリンピックが終わり、寂しさを覚えます。

最近はBtoCのサービスを開発していて、ブラウザの「戻る」で編集中のデータが消えないようにする機能を開発したのですが、その際の課題と解決策をお話したいと思います。

はじめに

本記事では、Next.jsにおいてユーザがブログなどの投稿画面からブラウザバックするときに確認ダイアログを表示する方法を説明していきます。

完成イメージ
完成イメージ

上記の機能は、ユーザの誤操作によって編集中の投稿が消えてしまうのを防ぐことで、UXの向上を目的としています。

実現したいこと

  • 投稿画面からブラウザバックするときに「保存されていないデータは削除されますが、よろしいですか?」と表示する
  • 前回保存時から投稿に変更があった場合のみ、ダイアログを表示する (未編集時にダイアログが表示されるのは煩わしいため)
  • 「保存する」を押して保存された状態であれば、ダイアログを表示しない

環境情報

  • Next.js: 11.0.1
  • TypeScript: 4.3.5
  • Bootstrap: 5.0.2

実装上の課題

上記を実現するにあたり、2つ課題がありました。

  1. Next.jsではbeforeunloadイベントでブラウザバックを検知できない
    beforeunloadイベントは、画面遷移が要求されページがアンロードされるときに発動されますが、Next.jsでのページ遷移はURLに対応したコンポーネントに差し替えているだけですので、ページがunloadされません。
    したがって、今回はこちらのイベントは使いません。 SPAでなければ、以下のサイトの方法で実現できます。
    フォームの2大誤操作「閉じる・戻る」での離脱を減らす確認ダイアログを実装しよう/15か条の10

  2. ブラウザバック(「戻る」)による遷移を止めるのに工夫が必要 ※後述します

実装方法

結論、以下の2つの方法で、実装することができました。

方法1: addEventListenerでpopstateイベントを追加する

以下の引用した説明では分かりづらいのですが、要するにpopstateイベントはブラウザの「戻る」や「進む」を押下した際にもトリガーされます。

popstate イベントは、同じ文書の2つの履歴項目の間で、アクティブな履歴項目が変わるたびにウィンドウに発行されます。
WindowEventHandlers.onpopstate

コード例

pages/posts/new.tsx

import React, { useState, useEffect } from 'react';
import { NextPage } from 'next';

export const NewPost: NextPage = () => {
  const [text, setText] = useState('');
  // 編集中かどうかをstateで管理
  const [isEdited, setIsEdited] = useState(false);

  const handlePopstate = () => {
    const isDiscardedOK = confirm(
      '保存されていないデータは削除されますが、よろしいですか?',
    );
    if (isDiscardedOK) {
      // OKの場合、historyAPIで戻るを実行します。
      window.history.back();
      setIsEdited(false);
    }
    // キャンセルの場合、 ダミー履歴を挿入して「戻る」を1回分吸収できる状態にする
    history.pushState(null, '', null);
  };

  useEffect(() => {
    // 編集中になったとき、現在のページを履歴に挿入し、handlePopstateをイベント登録
    if (isEdited) {
      // ダミー履歴を挿入して「戻る」を1回分吸収できる状態にする
      history.pushState(null, '', null);
      window.addEventListener('popstate', handlePopstate, false);
    }
    // 他のページに影響しないようclear
    return () => {
      window.removeEventListener('popstate', handlePopstate, false);
    };
  }, [isEdited]);

  return (
    <div
      className='d-flex justify-content-center'
      style={{ marginTop: '15vh' }}
    >
      <div>
        <h1>投稿画面</h1>
        <form>
          <textarea
            rows={10}
            cols={60}
            value={text}
            onChange={e => {
              setText(e.target.value);
              setIsEdited(true);
            }}
          ></textarea>
        </form>
        <div className='d-flex justify-content-end'>
          <button
            className='btn btn-primary mt-3 me-3'
            // 保存したときは、編集中フラグをfalseにする
            onClick={() => setIsEdited(false)}
          >
            保存する
          </button>
          <button className='btn btn-primary mt-3'>投稿する</button>
        </div>
      </div>
    </div>
  );
};

export default NewPost;

実際に入力欄に文字を打った後に「戻る」を押してみてください。確認ダイアログが表示されるはずです。 入力前と保存をした後であれば確認ダイアログは表示されません。

捕捉説明
history.pushState(null, '', null);で現在のページと同じ履歴を挿入することができます。パラメータは前から、state(状態オブジェクト), title, url になっており、urlにnullを指定することで現在のページの履歴が挿入されます。参考: History.pushState()

現在のページと同じ履歴、いわばダミーの履歴を挿入する理由は、「戻る」によるURLの変更を制御できないためです。

たとえば、以下のようにコメントアウトしておきます。

    ...
    if (isEdited) {
      // history.pushState(null, '', null);
      window.addEventListener('popstate', handlePopstate, false);
    }
    ...

投稿画面のURLは/posts/newなのですが、戻り先が/postsだとします。

投稿画面のURL
投稿画面のURL

入力した後に「戻る」を押すと、確認ダイアログが出ますが、URLが/postsに戻ってしまいます。

「戻る」を押した後
「戻る」を押した後

このように、「戻る」によるURLの変更を制御できないことがわかります。

そこで、ダミーの履歴を挿入することで
posts/posts/new
となっていた履歴の間にダミー履歴を挿入して、
posts/posts/newposts/new
にしているのです。

この状態であれば「戻る」を一度押しても、posts/newにいる状態を維持できます。

実は編集後に保存を押すと、確認ダイアログは出なくなるのですが、「戻る」を二度押さないと戻ることができません。これは上記のダミー履歴が蓄積されていることによるものです。

ユーザが編集中のデータを失わないという本質的な要件は満たしており、実装コストが見合わなそうだったので、ダミー履歴の蓄積されてしまう事象は今回は解消しませんでした。

方法2: Router.beforePopStateを使う

Router.beforePopStateは、Routerのメソッドで以下の説明にあるようにpopstateイベントを捕捉してイベントを発動するために利用しています。

Router.beforePopState 場合によっては(例えば、カスタムサーバーを使用する場合)、popstate をリッスンして、ルーターが動作する前に何かしたいということがあります。
next/router

コード例

pages/posts/new.tsx

import React, { useState, useEffect } from 'react';
import { NextPage } from 'next';
import { useRouter } from 'next/router';

export const NewPost: NextPage = () => {
  const [text, setText] = useState('');
  // 編集中かどうかをstateで管理
  const [isEdited, setIsEdited] = useState(false);

  const router = useRouter();

  const setHandlePopstate = () => {
    // ダミーの履歴を挿入し、ブラウザバックを1回分吸収する
    history.pushState(null, '', null);
    router.beforePopState(() => {
      const isDiscardedOK = confirm(
        '保存されていないデータは削除されますが、よろしいですか?',
      );
      // OKの場合、historyAPIで戻るを実行します。
      if (isDiscardedOK) {
        setIsEdited(false);
        router.back();
        return true;
      }
      // キャンセルの場合、 ダミー履歴を挿入して「戻る」を1回分吸収できる状態にする
      history.pushState(null, '', null);
      return false;
    });
  };

  // trueをreturnしてページ遷移が正常に動作すうように戻す
  const clearHandlePopstate = () => {
    router.beforePopState(() => true);
  };

  useEffect(() => {
    // 編集中になったとき、現在のページを履歴に挿入し、handlePopstateをイベント登録
    if (isEdited) {
      setHandlePopstate();
    } else {
      clearHandlePopstate();
    }
    // 他のページに影響しないようclear
    return () => clearHandlePopstate();
  }, [isEdited]);

  // 以下は方法1と同じ
  return (
    <div
      className='d-flex justify-content-center'
      style={{ marginTop: '15vh' }}
    >
      <div>
        <h1>投稿画面</h1>
        <form>
          <textarea
            rows={10}
            cols={60}
            value={text}
            onChange={e => {
              setText(e.target.value);
              setIsEdited(true);
            }}
          ></textarea>
        </form>
        <div className='d-flex justify-content-end'>
          <button
            className='btn btn-primary mt-3 me-3'
            // 保存したときは、編集中フラグをfalseにする
            onClick={() => setIsEdited(false)}
          >
            保存する
          </button>
          <button className='btn btn-primary mt-3'>投稿する</button>
        </div>
      </div>
    </div>
  );
};

export default NewPost;

挙動は方法1と同じです。

捕捉説明
useEffect内で、return () => clearHandlePopstate();してあげることが大切です。Routerに紐づけるイベントなのでclearしないと関係のないページで確認ダイアログが表示される可能性があります。

また、確認ダイアログを無効化するために保存によってisEditedfalseになったときもclearHandlePopstateを実行しています。

おわりに

方法1は主にブラウザの機能で実現していて、方法2は主にNext.jsの機能で実現しています。

ブラウザ機能の「戻る」が絡む実装なので、ブラウザ機能に寄せたいという方は方法1を、Next.js上で実装しているのでNext.jsに寄せたいという方は方法2を使うと良いと思います。

やや強引に実装しましたが、ブラウザバックの制御については社内のエンジニアも毎回面倒くさいと嘆いていました。

簡単に実装できるブラウザAPIが提供されていればよいのですが、「戻る」が効かないサイトも作ることができるため、UXの観点から提供されていないのだと推測します。

この記事を読んで、ブラウザバックを制御しようとしている方の時間が節約できれば幸いです。

RIT卒業します

初めまして。2020/11からRITでインターンとして参画させていただいた千葉と申します。 今回はRIT卒業にあたり、振り返りの記事を書かせていただきます。

インターン参画前

僕がRITにインターンとして参画する前は、実務経験がなくほぼ未経験者といった状態でした。一応プログラミングスクールで勤務していたので最低限の基礎は習得していましたが、実際のサービス開発は経験したことはありません。(社内のみで使用する小さなアプリケーションは開発したことはありますが)

インターンへの応募理由

プログラミングスクールで実務を学べる機会(開発に進む機会)もありましたが、会社の開発人数や予算の都合といった理由から、その道に進むことが難しい状況でした。そこでインターンとして実務経験を積み、リアルな開発現場というものを味わってみたかったというのがインターンへの応募理由です。そこで偶然、Wantedly経由でRITに出会い参画させていただくことになりました。

インターンの良かった点

未経験の言語に携われたこと

これまで触ったことのなかったフロントエンドの言語に携わらせていただきました。具体的にはReactとTypeScriptで、この開発を機にフロント周りの学習を始め、徐々に知識も身に付いてきたのかなと思います。

実際の案件に携われたこと

始めの1~2ヶ月は自社サービスの改修に携わりましたが、その後は実際の案件に携わらせていただきました。自身の転職事情でリリースまで携わることができなかったことに申し訳なさと後悔がありますが、1つのサービスを1から携われたことは自分にとって大きな成長機会になりました。

好きな時間で開発ができる

案件の納期等はありますが、基本的には自分の都合で開発を進めることができました。僕の場合は本業もあったので、平日夜や土日にメインで作業を進めていました。

インターン生でも気軽に発言できる

僕含め他のインターン生を見ていても、上下関係があまりなく、誰でも気軽に発言できる雰囲気があると感じました。インターン生と正社員の間には壁ができがちですが(少なくとも本業で働いていた会社ではありました)、交流会を開いていただいたり、MTGに参加させていただいたりと、できるだけこういった壁をなくす工夫がされていてとてもありがたかったです。

後悔していること

  • 携わっているプロジェクトを完遂できなかったこと
  • ReactとTypeScriptの案件に携わる期間が短かったこと

僕が原因で出来なかったことなのですが、後悔している点を挙げるとすると上記2つになります。携わっているプロジェクトがなくならない限り、おそらくは基本的に最後まで携わることができると思います、多分。

今後の進路

今後はヘルステックの企業でRailsエンジニアとして勤務予定です。転職活動の際にReactとTypeScriptを用いたポートフォリオを作成しましたが、これはRITで開発業務に携わらせていただく機会がなければ作成できなかったと思います。今後も引き続きサーバーサイドだけでなくフロントのスキルも高めていきたいと考えています。

最後に

RITではエンジニアを募集しています。 興味のある方はぜひ覗いてみてください。 https://www.wantedly.com/companies/rit-inc/projects

GCPでドメイン買えるようになってた(まだプレビュー)

GCPでサービスを構築するときにドメイン(Google Domains)とメール(SendGrid)周りだけ外部サービス使うのが面倒でなかなかクライアントに提案しづらかった福田です。

いつもの外部サービスの設定面倒だなーと思ってなんとなくdomainで検索してたら謎のCloud Domainsというサービスがあったので試してみました。

f:id:rit-inc:20201122171341p:plain

結論から言うと、AWSのRoute 53みたいにドメインの購入からDNSへの紐付けまでGCP上で一気通貫で完結するサービスでした。すごい嬉しい。

2020/11/25 追記

Cloud Runからでも買えるようになってたみたい

f:id:rit-inc:20201125230524j:plain

作業ログ

f:id:rit-inc:20201122171433p:plain

ドメインを登録ってリンクが気になる

まさかRoute53みたいにGCPだけでドメインの購入からDNSの設定まで完結するようになる?

もしそうなら超嬉しい

f:id:rit-inc:20201122171458p:plain

買えそうなのでカートに入れて続行

f:id:rit-inc:20201122171521p:plain

そのままCloud DNSまでつながってくれるっぽい

別のラジオボタンクリックしたら"Cloud DNSを使用する"に戻せなくなるので注意(1敗)

DNS APIを有効にしてから公開DNSゾーンを作れって書いてあるのに作らずに進むと最後に登録に失敗するので注意(1敗)

f:id:rit-inc:20201122171539p:plain

Cloud DNSにゾーン作ってから続行

f:id:rit-inc:20201122171638p:plain

whoisは保護しとく

f:id:rit-inc:20201122171707p:plain

情報を登録

f:id:rit-inc:20201122171600p:plain

できた!

さいごに

新規サービス立ち上げのためにAWSGCPでインフラを構築することが多いんですが、これでGCPで構築するのが更に楽になりますね。

特にクライアントによっては契約が一本増えるだけで手続きが複雑になったりもするので、その点でも嬉しいです。

RITでは、新しいサービスを活用した効率的なプロダクト開発でサービスの0~1をリードするエンジニアを募集しています!

herp.careers

コーポレートサイトのNext.js 10対応ついでにパフォーマンス改善してみた

f:id:rit-inc:20201107133327p:plain

最近京都に引っ越した福田です。 全然更新できてないですがエンジニアも増えてきたので頻度上げたいとは思ってます。

Next.js 10リリースされましたね

next/imageが出てきたりhrefasが要らなくなったりi18n系の新機能だったり、すぐにでも使ってみたい機能が色々ありましたね。 RITのコーポレートサイトではNext.js使ってるんですが、特に画像の最適化をサボってたせいでLighthouseのスコアがよろしくなくて、丁度いい機会だったので主にnext/image使うためにバージョンアップしてみました。

変更点

インフラ構成の変更

旧構成

github actions + firebase
旧構成

図にするほどのものでもないですがGitHub Actionsでbuildとexportしたファイルをfirebase hostingにデプロイしてます。

新構成

github actions + firebase + cloud run
新構成

Cloud Runが追加されてますね。 これは微妙にハマったポイントでもあるんですが、現状next/imageSSR必須っぽいのでnextを動かすサーバが必要になります(違ったらごめんなさい)。 なので、firebaseでキャッシュされてるリソースはfirebaseから返しつつ、キャッシュされてないリソースは裏のCloud Runにリクエスト投げてビルドしてもらうような構成に変更しました。 実際のfirebase.jsonは↓みたいな感じ(rewritesのところがCloud Runにリクエスト投げる設定)。

{
  "hosting": {
    "public": "public",
    "ignore": [
      "firebase.json",
      "**/.*",
      "**/node_modules/**"
    ],
    "rewrites": [
        {
            "source": "**",
            "run": {
                "serviceId": "<Cloud Runのサービス名>",
                "region": "asia-northeast1"
            }
        }
    ]
  }
}

Cloud Runはリクエストがなければ0までスケールダウンしてくれるので、適切にキャッシュしておけばCloud Runの費用はほぼかからないはず。 この"適切にキャッシュ"というのが厄介なんですが、firebaseはCloud RunからのレスポンスのpublicなCache-Controlヘッダを見てfirebaseへのキャッシュを行う(参考)ので、next.jsのレスポンスでCache-Controlヘッダを返してやる必要があります。 特にキャッシュしちゃいけないリソースもないので、ここでは適当にすべてのパスへのリクエストで1日キャッシュするように設定しておきました。 nextのheader周りあんまりちゃんと理解してないのでもっといい設定方法があるかも。

module.exports = {
    async headers() {
        return [
            {
                source: '/',
                headers: [
                    {
                        key: 'Cache-Control',
                        value: 'public, max-age=86400',
                    },
                ],
            },
            {
                source: '/:path*',
                headers: [
                    {
                        key: 'Cache-Control',
                        value: 'public, max-age=86400',
                    },
                ],
            },
        ];
    },
};

next/imageの導入

一番面倒だったのはlayout指定しないと必須になるwidthとheightの指定です。 ただ、これはそもそもnext/image使わずただのimgタグだったとしてもUX的にちゃんとしといたほうがいいので頑張って指定しましょう。 他はimgタグと同じ感覚で大丈夫でした。

<Image
    src='/static/img/top/service.jpg'
    alt='service'
    width={612}
    height={510}
/>

レスポンスの画像がwebpになってる
webp確認

ちゃんとwebpになってますね。

結果

(Next.js関係なくページ遷移時のアニメーション消したのも影響してますが許してください)

変更前

Performanceが低い
Lighthouse結果

よろしくない数字ですね。

変更後

Performanceが91に改善
Lighthouse結果

だいぶ改善しました。 画像の最適化という面倒な問題をnext/image使うだけでいい感じにやってくれるのは便利ですね。

さいごに

最初はnext/image使って高速化するだけのつもりだったんですが、Lighthouseちゃんと見てみたらNext関係ない部分で最適化できる箇所とかも割とあったので、適宜パフォーマンスチェックするのは大事ですね。

RITでは、新しい技術をキャッチアップしてユーザに最適なパフォーマンスで価値を提供できるエンジニアを募集しています!

herp.careers

RITのインターンを卒業します

はじめまして.RITでエンジニアのインターンとして働いている石川です. ちょうど参画してから2年目 & 就職でRITとお別れなので,感謝の意を込めて振り返り記事を書かせていただきます.

要約

  • 入る前
    • 自分は知識だけで経験不足の役に立たない人間
    • ITベンチャーでレベルアップしたい
  • 予想通り
    • 大きい裁量
    • メンバーの距離が近い
  • ギャップ
    • 賑やか
    • ギスギスしてない
  • 経験したプロジェクト
    • JWBF:顧客と開発のバランス
    • VOV:ログ
    • その他:いろいろ
  • これから

入る前

RITで働き始める前は,知識だけで経験不足の役に立たない人間でした.

情報系の大学に所属してたり,応用情報技術者の資格を所持してたりと,最低限のITやプログラミングの知識・能力はありました. 一方で,自分で何かちゃんとしたサービスを作ったこともなく,得た知識が業務でどのように役立つのか分かりませんでした.

このままでは社会の役に立てないので自分の経験を積みたいと思い,以前のバイトをやめてITベンチャーのRITに入りました.

予想通りだったこと

裁量が大きい

メンバーが少ないので一人ひとりに大きい裁量が与えられます.(僕がベンチャーを選んだ理由) インターンの身分でもクラウドサービスのかなり重要な権限も付与してもらったりしました. また,企画やミーティングなどでも自分の意見を尊重してもらい,方針を左右したりも. 裁量が大きいと色んなことができて楽しいです.

メンバーの距離が近い

また,メンバー間の距離が近いです. 新年会や忘年会だけでなくBBQしたりしますし,プライベートで遊んだりしています.

人生ゲームの極辛を遊んだのはいい思い出です. 救済システム(不運からプレイヤーを守ってくれる)を認識しておらず,負債者続出. 30万くらい借金抱えた人もいたり.

ギャップ

賑やか

10人近くのメンバーがオフィスにいてわいわいしてます. また,コンサルタントの多くは他の場所にいるのですが,その方々がオフィスに来たときは更に賑やかで楽しいです.

とか思って書いてたら,新型コロナで安全をとってみんなリモートに🙄(2020年2月時点)

ギスギスしてない

スタートアップと聞くと,ありがちなのが距離が近いゆえにギスギスした関係. ドラマだとメンバー間で問題発生してチーム決裂みたいなことがよくあります.

RITでは,メンバー皆がより良いサービスを提供しようと従事していますが,居心地が悪いと感じたことや悪そうな人はいないです. プロジェクトに問題は付き物ですが,発生しても人ではなく仕組みに原因があると考え,問題の発生しない仕組みを議論して構築・改善しているからだと思います.

あと,地味ですが労働環境が整っていることがこれを支えているのかなと思ったり. オフィスは広く,大きいモニターや人間工学に基づいた座り心地の良いイスが配備されてますし,コーヒーメーカーや軽食も置いてあります. さらにスタートアップにありがちなブラックに深夜遅くまで仕事して体を壊すなんてことはないです(多分?).

これまで

二年間で様々なプロジェクトに携わってきました. 紹介するには多すぎるので2つだけ取り上げます.

JWBF

jwbf.gr.jp

一つ目は日本車いすバスケットボール連盟のホームページです.主に,フロントエンドとWebサーバーの開発に携わらせていただきました.

主に用いた技術は次の通りです.

他の記事でも言っている通り,RITではフロントエンドはReactを用いることが多いです.ただ,このプロジェクトではVueにチャレンジしています.書き方などを覚えれば特に問題ありませんでした.ただ,VSCodeのVueのショートカットが一部非対応なため少し煩わしかったです.それ以外ではVSCode最高!!

このプロジェクトではモデルの持つ情報量が大きく,モデル間の依存関係が複雑でした. また,顧客(サイト管理者)視点では一つの画面に関連する項目を表示・編集できた方が嬉しいので,複数のモデルを管理できるようにしていました. この状態管理がハードで, Aの更新画面でBを更新→Bの更新が完了したら→Cを選択してもらい→Aの情報を入力して→Aの更新を完了する みたいな処理がたくさん存在していました.

顧客としては一つの画面に色々な機能があったほうが使いやすいことも多いですが,開発側としては一つひとつがシンプルな方が楽だと実感しました.(そもそもそんなに大変だと予測できてなかった😵)

顧客と開発のバランスは大事.このバランス調整こそSEの力の見せ所だと思うので,次の職場で経験していきたいポイントです.

vov

2つ目は,ビンテージアイテムのWikiプラットフォームのvovです.ユーザは読者と編集者がいて,主に読者側の開発を行いました.また,ログの設計と基盤の構築も行いました.

vov-vintage.com

主に用いた技術は次の通りです.

Webアプリ自体はいつもの構成(Next.jsだけ未経験)で大きな支障はありませんでした.

一方,ログ関連はほぼ未経験で,BigQueryは少し触ったこと有るけど…というレベル.

Analytics,DataPortalの使い方を学ぶところから始め,KGIツリーやログの完成予想図を顧客に見てもらったり,AnalyticsやFluentd,BigQueryによりログを蓄積させDataPortalで可視化したりと いろいろやることがありました.

知らないことばかりで大変でした. しかし,改めて振り返ってみると構築や思考手順などが残っているので,再現性のある貴重な経験だったと思います.

その他

JWBFとVOV以外のプロジェクトでもWebアプリを中心に開発していました. ReactやRailsなどのいつものWeb系のフレームワークはもちろんのこと,AWSのBeanstalkやECS を用いたインフラ構築も経験させていただきました.(おかげさまでAWSのSAAに合格したり) それ以外にも,案件・顧客に合わせて担当領域を変えていたので,それ以外にも全文検索エンジン,CI・CD,などなど,挙げればキリが無く,本当に色んな分野のスキルを身につけることができました.

また,技術以外にも,チーム開発における流れや大切なことを学ぶことができましたし,企画や立案に携わることもできました.

これから

目標としていたITの業務経験を積むことができました. 中でも,一つの技術領域にとらわれず幅広い体験をできたことは本当に感謝しています.

次の職場ではSEとして働きます.部署やプロジェクトは未定ですが,RITでの経験を活かせばどんなプロジェクトでも活躍できると信じてます.特に,調整力に集中して会得しつつ,技術面で力を発揮していきたいと思います.

AWS SSAを取得しました !

こんにちは!
株式会社RITの前田です。

今回はアマゾンウェブサービスのベンダー資格である、AWS 認定ソリューションアーキテクトアソシエイト(以下、SSA)を取得したので、体験記のようなものを書こうと思います。

なぜAWS SSAを取得しようと思ったか

弊社(RIT)では、一人のエンジニアがフロント側(React)からサーバーアプリケーション(Rails)、インフラ(GCPAWS・Azure)までwebアプリケーションの全てを対応できるようになっているので
業務でクラウドを触る機会が多く、一度網羅的に学習しておかなきゃなと思ったことがきっかけでした。
弊社(RIT)は学習するための書籍代や試験代は会社負担なので、比較的資格などの学習サポートが充実していると思います。

勉強方法

本とwebの問題集で勉強しました。

赤本*1
f:id:keimaeda0817:20200207134327j:plain ↑3回読みました

各種サービス(ストレージ、データレイク、コンピューティング)の概要を掴むにはオススメです。

黒本*2 f:id:keimaeda0817:20200207134348j:plain ↑3回読みました
各種サービスの詳細(CPU,メモリなど)をしっかり学びたい人にオススメです

紹介した2冊の本を中心に勉強しました。
この2冊で勉強する場合、赤本をまず初めに読むことをお勧めします。
AWSのサービス概要についてざっくりと学ぶことができるので、
まず赤本を読み、
その後に黒本を読むと、
AWSのサービスについて全体的なイメージから、個々のサービスの一つ一つの違いが理解できるようになるはずです。

後は、web問題集です。

aws.koiwaclub.com

3ヶ月3000円くらいと、割といいお値段はしますが、
問題数が多く、実際に出てくる問題と近いので、
この問題集で落としたところを、本で重点的に勉強すると効率よく勉強できます。

また、パブリックサブネットやプライベートサブネットの構築など、
実務で触れたところも多く出題されたので、やはり実際にAWSでサーバーなどを構築した方が理解しやすいです。

試験を受けました

平日に業務の合間を縫って試験を受けに行きました。
試験時間は130分、会場にあるパソコンにSSA試験用のアプリケーションがインストールしてあるので、画面を見ながら出題された問題を答えていくといった方法でした。
試験といえば、センター試験のようなみんなでせーので紙に回答を書いていくようなイメージがあったのですが、それとはだいぶ違うので、ギャップで驚きました。

問題は65問あり、しっかり学習していけば、試験時間はだいぶ余ると思います。
僕は70分以上余りました。

試験問題も上で紹介したWEB問題集と比べたら簡単に感じました。
最後の問題を解くと、回答を終了するというボタンが出てきたのでそれを押したら試験終了です。
ボタンを押したら、「おめでとうございます。 試験に合格しました」のような画面が出てきたので、「あっ、合格したんだな」と思いました。
当時は、すごいあっさりと表示するので、本当に合格したんだろうかと思いながら会社に帰ったことを覚えています笑

数日後、AWSのアカウントにSSAの資格を取得したことが反映されていました。
自分が何点取ったのか見ることができます。
合格ラインが720点で、僕の点数が740点くらい結構ギリギリでした。
90%くらいは取った気でいたので、冷や汗をかきました笑

最後に

株式会社RITでは、エンジニア、デザイナーを募集中です。

  • 新しい技術に触れたい人
  • フロントからサーバー、インフラなどフルスタックに開発したい人
  • 新規事業が好きな人

オススメです。

学習サポートとして、書籍代のサポートや資格の試験代のサポートも行っています。

rit-inc.co.jp

*1:AWS認定資格試験テキスト AWS認定 ソリューションアーキテクト-アソシエイト

*2:徹底攻略 AWS認定 ソリューションアーキテクト – アソシエイト教科書