Holmes開発者ブログ

契約マネジメントシステム「ホームズクラウド」の開発者ブログです

社内2人目のコードレビュアーになるためにやってきたこと

こんにちは!株式会社Holmesでエンジニアをしている平田です。最近日本酒にはまり、ネット販売のない酒屋のHPをスクレイピングして入荷したらLINEに通知することで、入手困難と言われる日本酒を飲むことができてエンジニア冥利に尽きる日々を過ごしています。

私は2020年初ごろからHolmesでコードレビュアーを担当しています。現在(2021/03)では開発部28名の中でレビュアー4名体制となりましたが、当時はテックリード1人しかレビュアーがいない状態で、各チームにとってはコードレビューがボトルネックになることがありました。また、レビュアーにとっても負担が大きく、本人のやりたいことに注力できていませんでした。 実際には他にもレビュアーとなれる人はいましたが、エンジニアリングマネージャーであったりと、役割やスピード感、仕様把握の観点から開発者でレビュアーを増やしたいという状況でした。

その中で自分がレビュアーとなるためにしたことを残そうと思います。現状のリソースの中でレビュアーを増やそうとしている組織やレビュアーになろうとしている人の参考になればと思います。

当時のチーム状況

当時の開発の状況は以下の通りでした。本格的な2チーム体制で、各チームがそれぞれミッションを持って開発に取り組んでいます。そのためボトルネックになりそうだというのが容易に想像できるのではないでしょうか。参考:現在(2021/03)のチーム状況はこちら*1

  • スクラム2チーム体制
    • チーム1
      • PO:1
      • SM:1
      • バックエンド:2(うち1名が当時唯一のレビュアー
      • フロントエンド:2
    • チーム2
      • PO:1
      • SM:1
      • バックエンド:1(
      • フロントエンド:2
      • デザイナー:1
      • SRE:1

やったこと

ここから私がレビュアーを任せてもらうために、やってきたことを紹介します。

現在のレビュアーから学ぶ

過去の指摘を振り返り

まずは現在のレビュアーの指摘がどのようなものか過去に振り返って確認して行きました。中にはドキュメントに落としづらいような経験からくる観点もあったりするので、話を聞いたりドキュメントを見るだけではなく、実際に行われた実績をみたり、一緒にレビューに立ち会ったりするのをお勧めします。

率先したレビュー指摘修正

並行して、レビュー指摘の修正を率先してやりはじめました。過去レビューの確認だけだと、本を読むのと一緒で手を動かしていないので、実際に指摘された内容の修正をしていくことで、同じことを繰り返さないようにして行きました。最終的にはレビュー依頼を出す前に私の方で確認をしてから依頼を出すという形式にして、指摘数を減らしていくことで、任せてもらえるようになりました。

プロダクトを学ぶ

私は特にここを重視しました。なぜなら私は当時エンジニア4年目のペーペーであり、経験豊富でテックリードを担っているレビュアーと肩を並べようというのですから経験で勝負するものではありません。

仕様に詳しくなる

プロダクトの仕様に詳しくないと、他の機能への影響や他の機能が及ぼす影響に気づくことができません。また、コードレベルでプロダクトを知ることも重要です。物によっては、nullが意味を持っている場合もあるでしょう。そういった(負債のような)違いにも気付き、リファクタリング(適切なdocを書くことも含め)していくことも私たちの組織には求められていました。

役割だけではない、視野の拡大

また、私の場合、様々な側面からプロダクトを見ていました。チーム体制で私はバックエンドと書いていますが、この頃からフロントエンドも兼任しています。また、デザイナーがチームにいたこともあり、UIUXの観点やデザイナーが作成したガイドラインの観点をコードレビューに活かしていました。具体的には、リクエストとレスポンスで空を期待するのかnullを期待するのかということであったり、ボタンの活性制御やエラー後の挙動などが正しく実装されているかというところまで見ていました。

設計を学ぶ

コードレビューの勉強というとリーダブルコードなど、コード自体の改善プラクティスを想像される方も多いのではないでしょうか。それらももちろん大切ですが、私は設計を学ぶことが大切だと思っています。設計論には様々なプラクティスが詰まっていますし、歴史的に何か課題を解決してきた経緯があると思っています。

バックエンド

Holmesでは現在ドメイン駆動設計(以下DDD)を取り入れて開発をしていますが、DDDをしていなくても、DDDが解決したい観点をコードレビューに活かす事はできるということです。

フロントエンド

フロントエンドでも設計パターンなど、特にHolmesでは現在Vue.jsへの移行を行っていますが、例えばVuexやReactの場合Reduxなどを使っていなかったとしてもVuexやRedux、Fluxを学び、また、それが生まれた背景や、そこに起因してMVC、MVVMなど以前からあるパターンを学ぶ事はできます。例えプロダクトが同じ設計パターンを用いてなかったとしても、それぞれの良い点・悪い点を知ることで、汎化してコードレビューに活かしていくことができます。

まとめ

以上が私がコードレビュアーとなるためにやってきたことです。 私がコードレビュアーになったことで、開発完了の定義を満たすまでチーム内で完結できるようになりました。2チームそれぞれがミッションを持ってプロダクトのアップデートに取り組んでいる中で、各チームが高速に開発サイクルが回せる体制ができました。また、レビュアーの負担が分散できたことで、テックリード(当時唯一のレビュアー)にさらなるアップデートの技術検証など、未来にかける時間に注力してもらえるようになってきました。

私自身レビュアーになったこともそうですが、バックエンド・フロントエンド双方に対して強みが持てるようになったので、チームの中でフレキシブルに必要なタスクを取れるようになり、大きく組織に貢献できるようになったと思います。また、Holmesでは新卒採用も行っているので、新入社員の書いたコードのレビューも担当するようになりました。教えるような機会が増え、さらなる自分自身の成長と組織貢献ができるようになりました。

現在は4名体制のレビュアーですが、レビュアーがレビューを受ける機会が少なかったり、レビュアーによって独自の観点を持っている部分もあるので、それらを改善していくのが今後の課題となります。

余談ですが、先日初めてOSSにPull Requestを出してレビューで指摘を受けたのですが、普段仕事で書くのとは違うコードだったりするので、新鮮なレビューが受けられて新しい学びが得られました。

最後に

Holmesでは、スタートアップのスピード感をレビュープロセスなどの品質担保で支えたいエンジニアを募集しています。 共にプロダクト作りを通して、社会・組織を良くしていきましょう! 興味がある方はぜひこちらからご連絡ください!

lab.holmescloud.com

*1:2021/03:スクラム3チーム体制
・チーム1(PO:1、PM:1、SM:1、バックエンド:2、フロントエンド:3、SRE:1、デザイナー:1)
・チーム2(PO:1、PM:1、SM:1、バックエンド:2、フロントエンド:2、SRE:1、デザイナー:1)
・チーム3(PO:1、PM:1、SM:1、バックエンド:1、フロントエンド:1、SRE:1、デザイナー:1)

GitLabのIssueがリリースされると関連するSalesforceの要望リストをGASでSlackに通知させてみた

こんにちは。Holmesでプロダクトオーナーをしているid:w-miuchiです。

長々としたタイトルですが、3つのアプリケーションを連動させた例として紹介させてください。

背景

開発部以外の他部門から、リリースされる機能で解決する問題の把握が難しいという意見を頂きました。過去に投稿した要望が改善されたのかどうかがわからないとのことでした。

弊社では、プロダクトバックログ(以降PBI)をGitLabのIssueで管理しています。
また、内外問わずプロダクトに対する要望はSalesforceで管理しています。

リリース時に対象となるPBIを通知しているのですが、PBIを読み取るのが難しいという問題がありました。

改善案

PBIを作成する元となった要望を通知すれば把握が進むのではないかと考えました。
その際、PBIを一つ一つ開いて確認するのではなく、ある程度の一覧性は担保したいと思います。

Salesforceの要望にはIssueのURLが登録されています。
リリース時にはPBIとなるGitLabのIssueをCloseします。このタイミングで関連付いた要望を取得し通知することにしました。

構成

構成は下記通りです。

f:id:w-miuchi:20210313120400j:plain

当初Salesforceの要望リストはAPIで取得しようかと考えていましたが、Googleスプレッドシートに同期する方が早いことがわかりました。
こちらは後ほど記載します。

設定

1. GitLab -> Goole Apps Script

今回Goole Apps Script(以降GAS)に関しては、

github.com

を利用しました。 こちらに関しては本記事では省略させて頂きます。
自身のIDEを利用でき、コマンドラインでDeployまでできるのは非常に嬉しいです。

上記で発行したURLをGitLabのWebhookに設定するだけです。
今回はTriggerをIssues eventsのみ設定しました。

f:id:w-miuchi:20210313120801p:plain

2. SalesforceGoogle スプレッドシート

こちらはGoogleスプレッドシートのアドオンで可能です。 以下に沿って設定しました。

support.google.com

3. GAS -> Google スプレッドシート

Salesforceの要望を取得している関数が以下になります。
同期しているスプレッドシートのIDを指定して取得しています。
取得したスプレッドシートjsonに変換しています。

const getCustomerRequestList = (): object[] => {
  const sheet = SpreadsheetApp.openById('xxxxxxxxxxx');
  const rows = sheet.getDataRange().getValues() as object[];
  const keys = rows.splice(0, 1)[0] as any[];
  return rows.map(function(row) {
    const obj = {};
    row.map(function(item, index) {
      obj[String(keys[index])] = String(item);
    });
    return obj;
  });
}

4. GAS -> Slack

Slack APIを利用します。

tanuhack.com

こちら参考させていただきました。

ここでハマってしまったのがbotとしているためSlackチャンネルに登録したアプリケーションのインストールが必要なことでした。

1と3を含む全体の処理は以下のとおりです。
(中途半端なTypeScriptであることはご容赦くださいmm)

const doPost = (e: any) => {
  const postData = e?.postData ? JSON.parse(e.postData.getDataAsString()) : {} as object

  // issueの変更後ステータスを取得
  const currentLabels = postData.changes?.labels?.current || [] as object[]
  /// PB以外除外
  const pbLabel = getLabel(currentLabels, ['PB'])
  if (!pbLabel) return
  /// 開発開始、Sandboxリリース、本番リリースを対象
  const isClosed = postData.object_attributes?.state === 'closed'
  const statusLabel = getLabel(currentLabels, ['Doing', 'Sandbox'])
  if (!statusLabel && !isClosed) return

  // issueのIdを取得
  const issueId = postData.object_attributes?.iid as string
  /// 関連issueを取得
  const linkedIssueList = getLinkedIssueList(issueId)
  /// 対象issueIdを設定
  const issueIdList = [issueId].concat(linkedIssueList.map(linkedIssue => {
    return linkedIssue.iid
  }));

  // 要望一覧を取得
  const customerRequestList = getCustomerRequestList();
  // Issueに該当する要望を特定
  const issueCustomerRequestList = customerRequestList.filter(customerRequest => {
    return issueIdList.some(issueId => {
      return customerRequest.GitURL__c.match(new RegExp('/' + issueId + '$'))
    })
  })

  // Slackに要望のステータス変更を出力
  /// 出力テキストを作成
  const statusLabelText = isClosed ? 'Closed' : statusLabel?.title
  const noticeContent = createNoticeContent(postData.object_attributes?.title, statusLabelText, issueId, issueCustomerRequestList)
  /// Slack書き込み
  postSlack(noticeContent)
}

おまけ

コマンドやブラウザから実行した場合はログを出力してくれるのですが、 非同期で実行させた場合、ログを出力されません。 (方法があったかもしれませんが...) そのため以下ような処理でGoogle Drive上にログを出力しました。

const writeLogs = (content: string): void => {
  const folder = DriveApp.getFolderById('xxxxxxx')
  const contentType = 'text/plain' as string
  const charset = 'utf-8' as string
  const fileName = Utilities.formatDate(new Date(), 'JST', 'yyyyMMddHHmmss') as string

  const blob = Utilities.newBlob('', contentType, fileName + '.txt')
      .setDataFromString(content, charset)

  folder.createFile(blob)
}

f:id:w-miuchi:20210308085713p:plain

課題

実は大きな問題点があります。
Salesforceの要望にはIssueのURLが登録されている
と記載しましたが、そもそもこの運用が出来てないということです。。。
今回は技術検証を先に行いましたが、まだ本運用に至っておりません。。。

最後に

いかがだったでしょうか。
課題は残っておりますが、技術的に可能なことがわかりました。
複数のサービスをWebhook、Addon、APIを利用し連動させるのは楽しいですね。
部分的にでも参考になればなによりです。

頑張らずこだわるCSSアニメーション設定

こんにちは、株式会社Holmesでエンジニアをしている堀川です。

皆さんは普段フロントのインタラクションを作り込むときアニメーションにどのくらいこだわってますか?

アニメーション速度を操作するtransitionというプロパティは親の顔より見ていると思いますが、普段業務を行う中で細かいアニメーションの動作にコストをかけられない悩みがあるのではないかと思います。

そこで今回、なるべくコストをかけずにアニメーションにこだわれる animation-timing-function の使い方をご紹介させていただきます。

animation-timing-function

animation-timing-function プロパティは要素にキーフレームアニメーションを適用する場合のタイミングや進行を指定することが出来ます。

代表的な値

ease

アニメーションの中央に向けて変化量が増加し、最後に向けて減少します。

linear

等しい速度でアニメーションします。

ease-in

アニメーションの変化の速度はゆっくり始まり、終了まで加速します。

ease-out

アニメーションは速く始まり、速度を落としながら続きます。

ease-in-out

プロパティのアニメーションはゆっくり変化し、速度を上げ、また速度を落とします。

使用例

HTML

<body>
  <div class="animation ease">ease</div>
  <div class="animation linear">linear</div>
  <div class="animation ease-in">ease-in"</div>
  <div class="animation ease-out">ease-out</div>
  <div class="animation ease-in-out"> ease-in-out</div>
</body>

CSS

.animation {
  animation-name: anime;
  animation-duration: 3s;
  animation-iteration-count: infinite;
  background-color: gray;
  color: white;
}

.ease {
  animation-timing-function: ease;
}

.linear {
  animation-timing-function: linear;
}

.ease-in {
  animation-timing-function: ease-in;
}

.ease-out {
  animation-timing-function: ease-out;
}

.ease-in-out {
  animation-timing-function: ease-in-out ;
}

@keyframes anime {
  0% {
    width: 100px;
    height: 50px;
  }
  100% {
    width: 600px;
    height: 50px;
  }
}

実行結果

f:id:j-horikawa:20210217101535g:plain

アニメーションを楽に設定したい

f:id:j-horikawa:20210217095631p:plainまずイメージに近い animation-timing-function の値を予め設定してChrome DevToolsで要素を確認してください。

animation-timing-function の値にアイコンが付いています、そちらをクリックすると cubic bezier editor が開きます。

f:id:j-horikawa:20210217095737p:plain

左の3つはベジェ曲線の基本型を選択するもので、下はそこから複数のパターンを選択できるのでお気に入りのイージングが見つかるでしょう。

イージング関数のチートシートもあるのでこちらも参考にしてみてください https://easings.net/ja

アニメーションをもっと細く設定したい

そんな貪欲なあなたにはイージングを細かく設定できるcubic-bezierをおすすめします。

f:id:j-horikawa:20210217100324p:plain

cubic bezier editorでは紫色の丸を動かすことによってアニメーションの微調整が行えます。

調整を行うとイージング名が表示されていたところがcubic-bezier(?,?,?,?)形式に変わるはずです、その値をそのまま適用したい animation-timing-function に設定してみましょう。

.custom {
  animation-timing-function: cubic-bezier(0.9, 0.54, 0, 0.83)
}

いかがでしたでしょうか? 適用したいイージングをチートシートで見つけて、細かい調整をChrome DevTools上で行うことによってご機嫌なアニメーションライフがおくれることでしょう。

最後に

Holmesはエンジニア・デザイナーを募集しています。 共にプロダクト作りを通して、社会・組織を良くしていきましょう! 興味がある方はぜひこちらからご連絡ください!

lab.holmescloud.com

lab.holmescloud.com

RSGT2021参加後、早速実践してみた話

こんにちは。 Holmesでスクラムマスターをしている吾郷です。

先日行われたRSGT2021に参加してきました。
素晴らしい出会いと刺激に恵まれたイベントでした!
今回は参加したセッションの中から振り返りについて、参加後に実践した話と合わせて紹介できたらと思います。 

セッション内容

ふりかえりで参加したセッションは、森さんのふりかえり手法のおもちゃばこでした!
実は、これまで何度か森さんのふりかえり実践会には参加させていただいてます。

retrospective.connpass.com

興味ある方は是非参加してみてください!

スクラムにおけるイベントの一つであるレトロスペクティブは、アジャイルレトロスペクティブズなどの書籍では体系的に学ぶことができます。
今回はとにかく手法を紹介しまくる!というもので、ひたすらいろんな手法を知ることができました。
改めてふりかえりって本当にいろんな方法があって面白いな〜と思いましたね!
いろんな観点からふりかえりを通したチームビルディングができると思います。

簡単にセッション中で紹介されたふりかえり手法を紹介します。

  • 感謝
    • 日頃の感謝を伝える(他の手法と混ぜ合わせる)
  • kudo card
    • カードを用いて感謝を伝える
  • カラーコードドット
    • 感情や熱量が上下したものにドットをつける
  • 喜怒哀
    • 出来事からではなく、感情から思い出す
  • Good&New
    • 場作りで使う
  • フォースフィールドアナリシス
    • 問題分析手法
  • FMEA(Failure Mode and Effect Analysis)
    • Failure→Analysis→Evaluation→Actionの順で整理する
  • 5つのなぜ
    • なぜを5回繰り返す(「なぜ?」の質問だとつらいので、「何がおこったの?」にするとよい)
  • Six Thinking Hats
    • 思考法の一つ。それぞれ役割の異なる帽子を被り替えながら議論を進める
  • 闇鍋
    • テーマを書いた上を箱に集めて引いていく。
  • KPT as ART
    • KPTの色を使い分けて、まばらに貼っていく
  • Blokus
    • 内容を提起したり、リプライしながら自分の陣地を増やしていくゲーム
  • ポジティブふりかえりマッピング
    • 終始ポジティブにふりかえることができる
  • ありたい姿
    • 未来志向のふりかえり。チームの理想とのギャップを埋めていく

各ふりかえりの詳しい手法については、 ふりかえりを拡張する「ふりかえりカタログ」 - Qiita で確認できます。
資料自体もPDFで配布されていますので、ご活用ください。

実践

最近自身が所属するチームの振り返りで、ポジティブなふりかえりが少ないこと、楽しめる要素が少ないことを鑑みて、上記ふりかえり手法のうち早速実践してみたのは以下の手法になります。

ポジティブふりかえりマッピング

まず最初に実行したのは、ポジティブになれるポジティブ振り返りマッピングでした!
終始、全く暗い話が出ず確かにポジティブに振り返る事ができました。
また、実験回数を多くする為に、今回2チームに分けて最後実験アイデアを考えてもらいました!
普段よりもTRYの回数は多くはなりますが、その分たくさんのアイデアを小さく回すことで何か発見につながる可能性が大きいと感じます。

f:id:seiseiholmes:20210129153824j:plain

また、ふりかえりの冒頭で紹介した、NormKerthの言葉は振り返りのFBでも非常に好評でした。

どんな道をだどったにせよ、当時の知識・技術・能力・利用可能なリソース・状況の中で、みんなができる限り最高の仕事をしたはずです。それを心から信じます。

自身も実際に感じたのは、このポジティブふりかえりマッピングに限らず、様々な振り返りで有効だろうということです。
少しの時間でみんなで方向を一つにして振り返りできるので非常におすすめです!

Blokus + ドット投票

続いて試したのはゲーム感覚で楽しめるBlokusです。
はじめにトラブル*1が起きましたが、その後は基本的にスムーズに行けました。
とはいえこちらは、自分自身の振り返りの準備不足ですね・・・!新しい取り組みをする際には注意したいところです。

f:id:seiseiholmes:20210129153837j:plain

集計で思ったよりも差が開いたりと、個々のメンバーを新しい一面も見ることができ、新しい学びとなりました。
Blokus自体楽しい要素がいっぱいですが、これ一つだとTRYを考えるためのステップが足りません。
そのため今回はTRY出しの手法であるドット投票と組み合わせて振り返りを実施しました。

振り返りでは、やはりゲーム性がある振り返りは純粋に楽しいといった声が聞こえた一方で、時間が足らないと言った声もありました。
このあたりは、今後の振り返り開催で随時改善していければと思います。

今後の活動

まだまだ試してみたいふりかえりはたくさんあります。小さく実験して、チームで様々な発見に結び付けられたらと考えています。

実はRSGT2021参加者には録画が共有されており、社内への展開ができます。(※URLのみの共有はNG)

これはいい機会!と思い、自分が参加できなかったセッション含めて早速、社内で希望セッションのアンケートを取りました。 要望が多いものから順に視聴会+ワークの形から始めて行こうと計画しています。 自分の体験の共有からSECIモデルを実践し、社内の知識創造を実現していこうと思います。

また、セッションには学問的な問い・哲学的な話題も多くありましたが、馴染みのある話題は少なくこちらもちょっとずつではありますが、自分の中に取り込んでいけたらと感じました。

これからもScrumMastersWayは続いていきます!

最後に

Holmesはエンジニア・デザイナーを募集しています。 共にプロダクト作りを通して、社会・組織を良くしていきましょう! 興味がある方はぜひこちらからご連絡ください!

lab.holmescloud.com

lab.holmescloud.com

*1:MiroのGrid機能は同時編集ができない

DevRel活動始めます

こんにちは、id:c-terashimaです

2020年の3月にスタートしたHolmes開発者ブログですが、アピール活動をあまり行ってきておらず数件のアクセスのみという日もありほそぼそと活動してきました。
そんな開発者ブログですが、あることをきっかけに はてなブログランキング 入りします。
あることというのがDDDサポートをしていただいているDDD Community JP主催の松岡さんにご紹介いただいたことです。

blog.hatenablog.com

改めて「インフルエンサーの影響力すごい!」「今までアピール活動してなかったのはもったいなかった」と感じ、自分たちでも活動していくことで

  • より多くのエンジニアにHolmesを知ってもらいたい
  • Holmesの取り組みを知ってもらうことで
    • 同じ悩みを抱えている方の助けになりたい
    • 共感してもらえたエンジニアと繋がりたい

を目指し技術広報活動準備会を立ち上げました!
とはいえ右も左も分からない完全初心者 なので、先人の知恵を借りようと「DevRel/Beginners勉強会」に参加してきました 。

devrel.connpass.com

DevRelとは

Developer Relationsの略
Public RelationsのDeveloper版で開発者向けのマーケティング

DevRelは外部の開発者との相互コミュニケーションを通じて、自社や自社製品と開発者との継続的なつ良好な関係を築くためのマーケティング手法

参考: https://devrel.jp/about/

この勉強会ではDevRelの基本とマーケティング戦略を知ることができHolmes開発グループをより多くのエンジニアに知ってもらうための道が見えた気がします。
「技術より情熱、お金より行動」この言葉を個人スローガンにしていきたいと思います。

これから色々な活動を通じてエンジニアの皆様にお会いできることを楽しみにしております。
もし見かけた場合は優しく声を掛けていただけると幸いです🙇


Holmesはエンジニア・デザイナーを募集しています。 興味がある方はぜひこちらからご連絡ください!

lab.holmescloud.com

lab.holmescloud.com

SpringBoot + Intellij でホットスワップをする

この記事は Holmes Advent Calendar 2020 - Qiita 15 日目の記事です。


こんにちは。Holmesでエンジニアをしている毛見です。

最近SpringBootのBootRunに掛かる時間が長く、少しの修正でBootRunし直さなければならないので、それをせずに変更を反映できるホットスワップについて調べたのでまとめます。

環境

  • macOS 10.15.7
  • Java11
  • Intellij 2020.2.4
  • spring initializerによりプロジェクトを生成
    • Project : Gradle Project
    • SpringBoot : 2.4.1
    • Packaging : Jar
    • Dependencies : Spring Web, Thymeleaf

設定手順

HotSwapの設定

  • intellijのPreferencesでHotSwapの設定を行う。
    • Reload classes after compilationのAlwaysもしくはAskを選択する。

f:id:Shogo_Kemi:20201216100248p:plain
Preferences | Build, Execution, Deployment | Debugger | HotSwap

それぞれの設定値の内容は公式ドキュメントを参照

テンプレートの変更を常に反映する設定

この設定をしなくてもHotSwap自体は可能ですが、thymeleafテンプレートを変更を反映する際の一手間がなくなります。

  • application.ymlに cache: falseを追加
spring:
    thymeleaf:
        cache: false
  • build.gradleにsourceResources sourceSets.mainを追加
bootRun {
    sourceResources sourceSets.main
}

HotSwapをする

  1. BootRunをデバッグ実行
  2. コードの変更
  3. inttelijのメニュー/Build/Recompile '編集したファイル名' でコンパイル、もしくはショートカットコマンド ⇧+⌘+F9
  4. intellijのHotSwapの設定で、Askを選択している場合、intellijにクラスをリロードするか聞かれるのでYesを選択。

テンプレートの変更はthymeleafテンプレートの変更を常に反映する設定している場合、3と4の手順は不要です。ページリロードを行うことで変更したテンプレートが読み込まれます。

HotSwapできない変更

感想

少しコードを修正しただけでもBootRunに1〜2分掛かっていたものが10数秒程度で変更を反映出来るようになったのは良かった。HotSwapについて色々調べて様々な設定方法がありましたが、結果的に必要な設定は少なかったので、費用対効果は良いと思いました。


Holmesではエンジニアを募集しています。興味がある方はご連絡下さい。 lab.holmescloud.com

FirebaseのCloud Firestoreを試してみた

この記事は Holmes Advent Calendar 2020 - Qiita 23 日目の記事です。


こんにちは!株式会社Holmesでエンジニアをしている北原です。

私は、2020年の4月に新卒でエンジニアとしてjoinさせていただきました。当初はSpringFrameworkとThymeLeafで開発を行っておりましたが、現在は弊社で使用している技術であるVue.jsの業務にシフトしてきたので絶賛キャッチアップ中です!

その学習も兼ねて、趣味の範囲で小規模なWebアプリケーションの作成を考えているのですが、「storeのデータを永続化させたいけど、DBとかバックエンドの処理が動くサーバが必要だし、コストがかかるなぁ...」という課題が生まれてきました。

そこで目をつけたのがこのFirebaseです。

Firebaseとは

FirebaseはGoogle社が提供するmBaaS(mobile Backend as a Service)で、DBサーバの管理や保守なしでデータの永続化ができ、そのほかにも様々な機能が提供されています。

その中で今回使用するのはCloud Firestoreになります。

Cloud Firestoreについて

最大の特徴はリアルタイムでデータが同期される仕組みで、接続するクライアント全てにおいて同期を行っているので、変更が瞬時に各クライアントに適用されます。

また、オフライン上でも各クライアント上にデータがキャッシュされており、オンラインに戻ると瞬時に同期されます。

データの保存形態に関しては、ODBMS(Object DataBase Management System)となっています。
Cloud Firestoreの場合は、コレクション呼ばれるものの中にドキュメントが多数存在し、それぞれのドキュメントはデータを持っている。といった具合です。

例えば...

  • コレクション = ドキュメントを管理するフォルダ
  • ドキュメント = フォルダ中の書類
  • データ = 書類に書き込まれた文書

といったようなイメージをすると少しわかりやすいかなと思います。

検証環境

※ npmインストール済です

  • OS : macOS Mojave 10.14.6
  • editor : Visual Studio Code v1.52.1
  • npm : v6.14.8
  • project : Vue 3 ステート管理はVueX

VueにおけるFirebaseの設定

  1. Firebase Consoleにログインします
  2. プロジェクトを追加を選択します

    1. プロジェクト名を決めます f:id:k-kitahara:20201221203428p:plain
    2. Googleアナリティクスを利用するか決めます(利用するのであれば) f:id:k-kitahara:20201221203711p:plain 3.Googleアナリティクスのプロパティを作成するアカウントを選択します f:id:k-kitahara:20201221203812p:plain
  3. 作成したプロジェクトを選択して、トップのウェブをクリックします f:id:k-kitahara:20201221204130p:plain

    1. 利用するアプリ名を決めます f:id:k-kitahara:20201221204205p:plain
    2. Firebaseの設定をコピーします f:id:k-kitahara:20201221204230p:plain
  4. プロジェクトのルートで下記のコマンドを実行して、Firebaseのモジュールをインストールします
    $ npm install firebase

  5. src/main.jsに手順3-2でコピーした設定をペーストし、必要な部分のみ保存します f:id:k-kitahara:20201221205520p:plain

以上で、Firebase利用のための設定は完了です。

データベースの作成

  1. Firebase Consoleにログインします
  2. 作成したプロジェクトを選択して、左側のサイドメニューからCloud Firestoreを選択します f:id:k-kitahara:20201221205915p:plain
  3. データベースの作成を選択します f:id:k-kitahara:20201221205947p:plain
    1. セキュリティの保護ルール設定を選択します(テストモードにすると全ての操作を受け付けるので、初期設定では本番環境モードにしてから、適宜セキュリティルールを書き換えていく形が良いと思います) f:id:k-kitahara:20201221210119p:plain
    2. データ保存先のリージョンを選択します f:id:k-kitahara:20201221210255p:plain
  4. ルールのタブを選択します f:id:k-kitahara:20201221210313p:plain
  5. セキュリティルールをアプリケーションに合った形で書き換えます(アクセスするデータベースのパスに対して条件付きで権限を付与していきます。具体的な記法はこちら。)

コードの記述・画面からの操作

  1. VueXのアクションに、Cloud Firestoreにデータを追加する処理を記述します f:id:k-kitahara:20201221210755p:plain
  2. 画面から、処理を記述したアクションを呼び出すと追加されています!! f:id:k-kitahara:20201221210901p:plain

感想

無料版だと多少の制限はあるものの、DBの構成管理なしでデータの永続化が実現できるのは手軽で便利です!

ここの手順では記載しておりませんが、GoogleFacebookなどの認証も対応しており、それらを通じたアプリケーションのログイン/ログアウト機能を実装できたりするので、Webアプリケーションの構築がよりスムーズになるかと思います。

最後に

いかがでしたでしょうか。

私もまだまだ触り始めたばかりではありますが、今後も少しずつ理解を深めていきたいと思います!

Holmesではエンジニア・デザイナーを募集しております。ご興味がある方はこちらからご連絡ください。

lab.holmescloud.com

lab.holmescloud.com