はじめに

こんにちは、ネクストビートでエンジニアをしている久保です。

Testcontainers は、テストコード中でDockerコンテナを使うためのライブラリです。
DBやファイルシステムの部分をクリーンな状態でテストすることができ、様々な言語に対応しています。
今回はそのTestcontainersを使って、ScalaTestでコンテナを使い回す方法を紹介します。
testcontainers-java のScalaラッパーであり公式でサポートされている testcontainers-scala を使います。

testcontainers-scalaはScalaTestをラップしたトレイトも提供しており使い勝手が良いです。基本的な使用方法は割愛します。

なぜコンテナを使い回すのか

Testcontainersは通常、テストケースやテストスイートごとにコンテナを起動します。
そうすることで、テストケース・スイート間で影響を及ぼさずに済むのが利点です。
しかしコンテナの起動には時間がかかるため、テストが増えるたびに実行時間が長くなってしまいます。 そのため、ライブラリのページでも「sbtのIntegrationTestでの実行を推奨する」と言及されています。

testcontainers-scala/docs/src/main/tut/setup.md at master · testcontainers/testcontainers-scala

Although Testcontainer tests are mere unit tests, it’s best (although not mandatory) to use them as sbt integration tests since they spawn a separate environment, can be slower and require specific configuration.

機械翻訳：
「Testcontainersのテストは単なるユニットテストですが、別の環境を起動するため、遅くなり、特定の設定が必要になるため、sbtの統合テストとして使用することが最適です。」

つまり頻繁に実行するユニットテストとしてではなく、例えばリリース前の検証の段階でCIで実行する等が推奨されています。
ただ、もし開発段階で気軽に実行してバグの混入を早期に検知できるのであればそれに越したことはないなと思いました。
同じニーズはやはりあるようで、実験的な機能としてですがコンテナを使い回す withReuse というオプションが提供されています。

Reusable Containers (Experimental)

しかしこの withReuse オプションは testcontainers-scala の ScalaTest ラッパーでは未対応です（ 2024/03/14 時点）

Is there a way to share the same single container instance between suites? · Issue #160 · testcontainers/testcontainers-scala

At the current moment, there is no supported way for doing this. It’s because scalatest doesn’t provide any functionality for sharing data like this between tests.

機械翻訳：
「現在のところ、これを行う方法はサポートされていません。ScalaTest はテスト間でこのようなデータを共有する機能を提供していないからです。」

そこで、今回は withReuse を使わずに、コンテナを使い回す方法を紹介します。

Singleton Container Pattern

本家のtestcontainersでも Javaでの実装例 が紹介されている方法です。
しかしScalaにstaticは無いのでそれに相当する シングルトンオブジェクト で実装する必要があります。

注：コード例はScala3で書かれていますが2.13でも適用できます

① シングルトンオブジェクトの定義

トップレベルにあるオブジェクト（＝シングルトンオブジェクト）として定義することでプロセス内で一つのコンテナを使い回すことができます。さらにこれを各テストスイートに提供するためのトレイトを定義します。

② 汎用テストトレイトの定義

このトレイトをテストスイートでextends、もしくはmixinすることで、テストケース間でコンテナを使い回すことができます。

③ テストスイートで利用する

これと同じようなテストスイートをもう一つ書いてみましたが、実際にDocker Desktopで起動しているコンテナを見ると一つになっていることがわかります。

注意点

この Singleton Container Pattern にはいくつか注意点があります。

① テストデータの初期化が必要
コンテナを使い回すことで他のテスト実行時のデータが残ってしまい、そのままだとクリーンな状態でテストが行えません。
そのため明示的にDBの初期化を行う必要があります。

今回の例では SingletonMySQLContainerSpec.scala の beforeAll で ScriptUtils.runInitScriptを使って下記のようなクエリを読み込んで実行しています。

DROP DATABASE IF EXISTS `test`;
CREATE DATABASE `test`;

② 複数のテストを並列実行できない
同じコンテナを使い回す都合上、各テストケースで行われたDBの変更がお互いに影響しあい、実質的に並列実行できなくなります。
限られた条件下では可能かもしれませんが、この方法を採用する場合は下記のオプションを指定してテストの並列実行を無効化する必要があります。

// build.sbt
Test / fork := true,

当初、並列の無効化なら Test / parallelExecution := falseなのでは？と思い設定したのですがこれだと同一プロジェクト内のテストは直列実行されるのですが、サブプロジェクト間のテストは並列実行されてしまいます。
今回のサンプルコードは単一プロジェクトですが現場ではマルチプロジェクトになることも多いかと思います。
そこで代わりに指定するのが Test / fork := true です。
このオプションは指定するとテスト時に新たなJVMプロセスを立ち上げて実行してくれるのですが、実はその中で実行されるテストは サブプロジェクトも含めた全てのテストにおいて直列で実行されます。
そのためこちらを指定することで全てのテスト間で意図しない干渉を防ぐことができました。
ここは私も完全に理解できていないのですがこちらの記事を参考にさせていただきました。

sbtにおけるテストの並列実行の設定詳細解説 - xuwei-k's blog

ただこの並列テストの問題は通常のTestcontainersの利用方法でも少なからず抱えている問題で、例えばテストスイートごとにコンテナを立ち上げる場合はテストスイート内のテストケース同士が干渉してしまうのでテストケースの並列実行には「レコードのIDを被らせない」等の工夫が必要になります。
テストケースごとにコンテナを立ち上げることもできますが、それこそコンテナの起動時間がさらに伸びてしまいます。

またこの Test / fork := trueの設定ではコンテナテスト的に嬉しい点もあり、 「testコマンド終了時に自動的にコンテナが終了」 してくれます。
これはforkを有効にすることでtest実行時に新たなJVMプロセスが作られ、テスト終了と共にそのJVMプロセスも終了するためです。
参考: https://www.scala-sbt.org/1.x/docs/Forking.html

これは 「開発時に繰り返しテストを実行したい」という要件ととても相性が良い です。
「全テストが終了したらコンテナを終了する」という処理を独自で書くのは難易度が高い気がするのでこれはありがたい副次的効果でした。

おわりに

本記事では Singleton Container Pattern を用いて Testcontainers のコンテナを使い回す方法を紹介しました。
本来の利用方法とは異なりますが、同じニーズを抱えていらっしゃる方の参考になれば幸いです。

今回用いたソースは実際に動くものをこちらに用意しています。https://github.com/katzkb/tc-scala-sample

We are hiring!

本記事をご覧いただき、ネクストビートの技術や組織についてもっと話を聞いてみたいと思われた方、カジュアルにお話しませんか？

・今後のキャリアについて悩んでいる
・記事だけでなく、より詳しい内容について知りたい
・実際に働いている人の声を聴いてみたい

など、まだ転職を決められていない方でも、ネクストビートに少しでもご興味をお持ちいただけましたら、ぜひカジュアルにお話しましょう！

🔽申し込みはこちら
https://hrmos.co/pages/nextbeat/jobs/1000008

また、ネクストビートについてはこちらもご覧ください。

🔽エントランスブック
https://note.nextbeat.co.jp/n/nd6f64ba9b8dc

ScalaTestでTestcontainersのコンテナを使い回してみた was originally published in nextbeat-engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.

はじめに

こんにちは。エンジニアの久保です。
最近は保育士バンク！というサービスを中心にプロダクト横断の基盤部分を開発しています。
今回は認証基盤であるAuth0を使ったProgressive Profilingについて記事を書かせていただきます。

本記事を読むことで分かること

• Auth0を用いた Progressive Profiling の概要
• 公式ドキュメントには無い具体的な実装例
• IDaaSの便利さ

免責事項

• 本記事では一部セキュリティに言及しますが、そこが本題ではないため割愛している部分があります。他文献も参考にしてください。
• サンプルコードで一部 Local Storage や cookie を用いていますが、あくまでサンプルコードですので利用するストレージは別途ご検討ください
• Auth0に関する仕様やUIは2023年4月10日時点のものです。最新の公式ドキュメントも併せてご参考ください。

概要

皆さんは Progressive Profiling についてご存知でしょうか。
簡単に言いますと「段階的なフォーム入力体験」のことを指します。
どんなサービスでもそうですが、コンバージョン率を上げるために登録フォームの入力項目はなるべく減らしたいのが常かと思います。
ですがIDとパスワード以外にも欲しいユーザーデータは多々あります。
そこで一度にすべての情報入力を求めるのではなく段階的に入力を求めれば、まずは登録だけはしてくれるかもしれません。
ということで今回は Auth0 の Actions という機能を用いてそれを実装してみます。
Auth0 はアカウントの認証・管理機能を提供しているいわゆる IDaaS です。
実装するフォームのステップとしては下記の通りです。

1. ID/Passwordを入力して登録（New Universal Login）
2. 氏名や住所などの追加情報を入力（独自実装）
3. 登録完了

基本的な認証処理の説明は省かせていただきます。
また実装は弊社サービスでも導入している SvelteKit で行います。

シーケンスの確認と解説

「追加情報入力フェーズ」以外の部分はありふれた認証フローです。
では9番から15番までを作っていきます。

Auth0 Actions を使用する

Auth0には様々なアクションをトリガーにして予め設定していた処理を実行させることができます。
ではさっそく作っていきましょう。
サイドメニューの 「Actions > Library」 から遷移し、画面上部のBuild Customを押します。
名前は任意で、トリガーには「Login / Post Login」を選びます。

今回は登録時に追加情報を入力してもらうのが目的です。
なので「Post User Registration」かと思われるかもしれないのですが、このトリガーは非同期で実行されるので今回の目的であるProgressive Profilingには使えません。
各Actionの概要はこちらからご確認いただけます。
また途中離脱などされて再開した場合もやはり入力してほしいはずです。
そうなると「Login」が最適です。 Login は登録したあとの初回ログイン、離脱・ログアウト後のログイン時にも処理が走るためです。
作成するとこのようなテンプレートが既に用意されています。

exports.onExecutePostLogin = async (event, api) => {
};
// exports.onContinuePostLogin = async (event, api) => {
// };

ログインをトリガーにしてこの 「onExecutePostLogin」が呼び出されます。シーケンス図でいうところの9番の処理です。
「onContinuePostLogin」の方は後ほど解説します。
まずは最初の関数を利用して追加情報画面にリダイレクトしてあげましょう。

onExecutePostLoginの実装 （シーケンス：⑨, ⑩）

const redirectToValidationPage = async (event, api) => {
  const YOUR_DOMAIN = event.secrets.YOUR_DOMAIN 
  const token = api.redirect.encodeToken({ // ①-1
    secret:           event.secrets.AUTH0_ACTIONS_SECRET, // ①-2
    payload: {
      continue_uri:   `https://${YOUR_DOMAIN}/continue`, // ②
      name:           event.user.name ?? '', // ③-1
      address:        event.user.user_metadata.address ?? '', // ③-2
    }
  })
}
exports.onExecutePostLogin = async (event, api) => {
  // 追加情報が未入力であれば追加情報入力画面へリダイレクトする
  if (!event.user.name || !event.user.user_metadata.address) { // ④
    await redirectToValidationPage(event, api)
  }
};

• まず引数の event と api ですが、こちらにはActions内で使える便利なメソッドやデータが用意されています（event, api）
• ①-1：リダイレクト時はGETアクセスですので、api.redirect.encodeToken を使うことでやり取りするデータを署名し正当性を担保します
• ①-2：この AUTH0_ACTIONS_SECRET が共通秘密鍵で、これで署名検証します。ハードコーディングは避けられるように、Actionsには環境変数を登録ことができます。Actionsのエディタ左側にある鍵マークから登録しましょう。もちろん名称は何でも良いです。ちなみに値も特段決まりはありませんが私はUUIDを生成して使いました
• ②：これが追加情報入力後の遷移先で、先程出てきた onContinuePostLogin を呼び出すエンドポイントです
• ③：この２つが今回の追加情報です。以前に片方だけ入力した場合を想定してこのような実装にしています
• ④：この関数はログインのたびに呼び出されますので、既に入力済みな場合を想定してガードを書きましょう

/auth/login/step/2 の実装 （シーケンス：⑪〜⑭）

このActionsからリダイレクトされた先の実装はサービスの仕様によって様々ですが、今回は追加情報入力フォームをあと１段階だけ挟みます。

+page.server.ts （シーケンス：⑪）

import { env } from '$env/dynamic/private'
import * as jwt from 'jsonwebtoken'
import { error } from '@sveltejs/kit'

/** @type {import('./$types').PageServerLoad} */
export async function load({ url }) {
  const query        = url.searchParams
  const sessionToken = query.get('sessionToken')
  const state        = query.get('state')

  if (!sessionToken || !state) {
    throw error(400, { message: 'Bad Request' })
  }

  let decodedToken: DecodedSessionToken
  try {
    decodedToken = jwt.verify(sessionToken, env.AUTH0_ACTIONS_SECRET, { // トークンの検証
      issuer:     env.AUTH0_DOMAIN,
      algorithms: ['HS256'],
    }) as DecodedSessionToken
  } catch {
    throw error(400, { message: 'Bad Request' })
  }
  // クライアントに値を返却
  return {
    userId:      decodedToken.sub,
    continueUri: decodedToken.continue_uri,
    name:        decodedToken.name,
    address:     decodedToken.address,
    state
  }
}

Actionsから返ってきたトークンはJWTなのでAuth0公式が公認しているJWTライブラリで検証してあげましょう。
シークレットなどは環境変数に保存して呼び出しています。
無事検証できればActionsから送られたpayloadが手に入ります。
continue_uri や state は後続処理を呼び出す際に必要なので手間ですが引き回しましょう。

+page.svelte（シーケンス：⑫）

<form method="POST" action="?/continue">
  <FormGroup floating label="氏名">
    <Input type="text" name="name" value="{$page.data.name}" required />
  </FormGroup>
  <FormGroup floating label="住所">
    <Input type="text" name="address" value="{$page.data.address}" required />
  </FormGroup>
  <input type="hidden" name="userId" value="{$page.data.userId}" />
  <input type="hidden" name="continueUri" value="{$page.data.continueUri}" />
  <input type="hidden" name="state" value="{$page.data.state}" />
  <Button>登録</Button>
</form>

レイアウトのためにBootstrapを使っていますが普通のタグに読み替えてもらって問題ありません。
SvelteのForm actionsを使って、先程の +page.server.ts に入力値を返却します。

+page.server.ts（シーケンス：⑬, ⑭）

先程の +page.server.ts に追加でフォームの受け口を作ります

/** @type {import('./$types').Actions} */
export const actions = {
  continue: async ({request}) => {
    const data        = await request.formData();
    const name        = data.get('name')
    const address     = data.get('address')
    const userId      = data.get('userId')
    const continueUri = data.get('continueUri')
    const state       = data.get('state')
    if (!name || !address || !userId || !continueUri || !state) {
      throw error(400, { message: 'Bad Request' })
    }
    const sessionToken =
      jwt.sign(
        { continue_uri: continueUri, name, address, state },
        env.AUTH0_ACTIONS_SECRET,
        {
          algorithm: 'HS256',
          subject:   userId,
          issuer:    env.APP_URL,
          expiresIn: 60,
        })

    throw redirect(302, `${continueUri}?state=${state}&sessionToken=${sessionToken}`)
  }
};

ポイントとしては jwt.sign の部分です。
ここで再度Actionsに返すのですが、やはり改ざんがあれば気付けるように署名する必要があります。
issuer（発行者）には自身のアプリケーションのURLを設定しましょう。

onContinuePostLoginの実装（シーケンス：⑮）

// ユーザーデータを更新するためのメソッドを用意
// https://community.auth0.com/t/updating-user-profile-from-actions/85206
const updateUser = async (event, data) => {
  const ManagementClient = require('auth0').ManagementClient
  
  const management = new ManagementClient({
    domain:       event.secrets.AUTH0_DOMAIN,
    clientId:     event.secrets.CLIENT_ID,
    clientSecret: event.secrets.CLIENT_SECRET
  })

  const params = { id: event.user.user_id }
  await management.updateUser(params, data, function (err) {
    if (err) {
      console.log(err)
    }
  })
}

exports.onContinuePostLogin = async (event, api) => {
  let payload
  // トークンを検証して取り出し
  try {
    payload = api.redirect.validateToken({
      secret:             event.secrets.AUTH0_ACTIONS_SECRET,
      tokenParameterName: 'sessionToken'
    })
  } catch (e) {
    console.log(e)
    api.access.deny('トークンの検証に失敗しました')
    return
  }
  // 追加情報が未入力であれば追加情報入力画面へリダイレクトする
  if (!payload.name || !payload.address) {
    await redirectToValidationPage(event, api)
    return
  }
  // 問題がなければデータを更新して完了
  api.user.setUserMetadata('address', payload.address)
  await updateUser(event, { name: payload.name })
};

以上のプロセスが完了するとシーケンス図の16番、 /api/auth/callback に返ってきます。
そこからの処理は他の方記事や公式ドキュメントが充実していますのでそちらをご確認ください。
ここまで完了したらActionsエディタの右上ので「Deploy」ボタンでデプロイしましょう。

フローに乗せる

作ったActionsはFlowに組み込むことで実際にトリガーされます。
Actions > Flows から 「Login」 を選択しましょう。

Flowの全体像が表示されます。右側の「Custom」を選ぶと先程デプロイした自作のActionsが出てきますので、ドラッグアンドドロップで組み込みましょう。
右上のApplyをして反映完了です。

最後に

Auth0はドキュメントが豊富ではあるのですがすべて英語で、またActions自体の記事もあるにはありますが具体的な事例もあると良いなと思い本記事を書かせていただきました。
データ保持部分等はかなり省略していますが、やはりユーザーの管理をここまで任せられ、かつ柔軟なビジネス要件にも対応しているAuth0は調査してみてとても勉強になりました。
今回利用したソースはこちらに上げてあります。
本記事が何かのお役に立てますと幸いです。
ありがとうございました。

We are hiring!

株式会社ネクストビートでは

「人口減少社会において必要とされるインターネット事業を創造し、ニッポンを元気にする。」
を理念に掲げ一緒に働く仲間を募集しております。

https://www.nextbeat.co.jp/recruit

Auth0 Actionsで Progressive Profiling を実装してみた was originally published in nextbeat-engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.

こんにちは。エンジニアの久保です。
普段は保育士バンク！コネクトというサービスを開発しています。
今回はScalaでコレクション操作する際のパフォーマンスに関する小ネタについてお話ししたいと思います。

概要

「ユーザーが複数のグループに所属する」という設計の場合。
こんなかんじのマッピングテーブルを使う実装ってよくあると思います。

で、このデータ構造から下記のような「ユーザとその所属グループ一覧」を複数取得したい場合のScalaでの良い書き方と悪い書き方を紹介していこうと思います。

言語やフレームワークによっては LEFT JOIN など使ってクエリの方で解決する手段もあると思いますが、今回はScalaの世界で実装する前提で書きます。
ちなみにバージョンは 2.13.1です。

■ 悪いパターン

実装確認

まず悪いパターンから。

1. userSeq を map で回して
2. userId で GroupMember を特定し
3. それに紐づく Group を取得する

といった流れですね。
仕様をそのまま素直に書くとこういう書き方になるかと思います。
どこがいけないのでしょうか？
では実行速度を見てみます。
まずは10件。

3回ほど実行。

$ scala testA.scala
3ミリ秒
$ scala testA.scala
2ミリ秒
$ scala testA.scala
3ミリ秒

問題なさそう。
では10,000件。

同じく3回実行。

$ scala testA.scala
5231ミリ秒
$ scala testA.scala
4681ミリ秒
$ scala testA.scala
5225ミリ秒

悲惨ですね。なぜこうなってしまうのでしょうか。

問題箇所

計算量を確認します。

filter はコレクションの先頭から末尾まで確認するので、計算時間は線形です。
なので計算量は

となり、ユーザー数、グループ数、マッピング数それぞれが10,000件(n=10,000)の場合
200,000,000 = 2*10,000*10,000

2億回。絶望的ですね。
O(n²) の部分をなんとかすれば速くなりそうです。

■ 良いパターン

要らないと思いますが10件で実行した結果。

$ scala testB.scala
4ミリ秒
$ scala testB.scala
4ミリ秒
$ scala testB.scala
2ミリ秒

大差無いですね。
では10,000件

$ scala testB.scala
472ミリ秒
$ scala testB.scala
420ミリ秒
$ scala testB.scala
470ミリ秒

うーん、爆速ってわけじゃないですが割とマシになりました。

工夫した点

• ①で最初に GroupMember を使って、ユーザーIdをキーにしたグループリストのマップを作ってしまいます。
• ②でマッピング数分回るので10,000回
• ③は今回の例では1回。ユーザーが10グループに所属してたら10回となりますがさほど影響しません
• ④はfindなので線形、Vectorを使えば実質定数です（性能特性)
• ⑤はユーザー数分

なので

となりn=10,000なら20,000。
2万回で済む、というわけですね。
全ユーザーが10グループに属しているとしても11万回で、悪いパターンの2億回よりはマシです。

まとめ

Scala勉強し始めたころは filter が便利すぎて多用してしまいがちですが、計算量はしっかり意識して実装したいですね。
find は定数なので、 groupBy でマップを作ってしまってキーで find する、というこの方法は割と色んな場面で使えるのではないかと思います。
また、データ量が少ないと問題が表面化しないのも罠ですね。

お読み頂きありがとうございました。
改善の余地はある気がするので、
間違っている点、改善できる点あればご指摘頂けますと幸いです🙇‍♂️

We are Hiring!

株式会社ネクストビートでは

「人口減少社会において必要とされるインターネット事業を創造し、ニッポンを元気にする。」

を理念に掲げ一緒に働く仲間を募集しております。

Scala: マッピングモデルを使う構造で表示用データを高速に組み立てる方法 was originally published in nextbeat-engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.

こんにちは。エンジニアの久保です。
普段はKIDSNAコネクトというサービスを開発しています。
自作キーボード制作が趣味なのですが、それが高じて今回IoT製品の開発をマネジメントすることになりました。
現在量産体制に移行しているのですが、今回はその手前であるプロトタイピングをどのようにして進めたのかについて書かせていただきます。
また、私自信プロジェクトマネジメント自体も初めての経験でしたのでその観点での気づきも併記させていただきます。

何を作ったのか

写真はプロトタイプのものです。
BluetoothでiPadとペアリングして利用できるFeliCaカードリーダーを開発しました。
といっても汎用的に利用できるわけではなく、弊社が提供している KIDSNAコネクトの打刻用のiPadアプリで使うためにカスタマイズして開発しました。
FeliCaのIDmの読み取りを行うだけなので、入退室管理などにもよく使われるMifareカードのUIDも読み取れるようにしました。

FeliCa、Mifareの違いを解説。ICカードの種類と特長を比較する：キヤノン

なぜ作ったのか

前述した KIDSNAコネクト では主に保育士さん向けに勤怠・労務管理機能を提供しており、これまでは市販のBluetooth対応FeliCaカードリーダーを利用して出勤・退勤の打刻を行えるようにしていました。
しかしこれが生産終了となり代替品も見つからないという事態が発生しました。

Sony Japan | FeliCa | 法人のお客様 | 製品情報 | PaSoRi（パソリ）製品比較表

もちろん打刻方法自体を変えることも検討しました。
web画面上で打刻する機能やQRコードで打刻、顔認証など様々検討しましたが、現状のFeliCaカードリーダーで使い慣れているお客様も多くいる中で代替手段を強いるのも忍びないという思いがありました。

そんな折に 「カードリーダー自体を作ってしまうのはどうか」 という案が上がり、自作キーボード好き・電子工作好きを公言していた私に声がかかりました。
無ければ作ればいい、という至極シンプルな発想です。
自社で作るメリットとして、他社製品に依存しない形で打刻機能を提供できるようになります。

協力会社の選定

まず弊社にはIoT製品開発に関するナレッジがありません。
そのためPoC・プロトタイピングはその知見のある会社の協力を仰ぐこととにしました。
今回は弊社CIO/VPoEである三井の紹介で もっけ技研 様にご協力いただきました。

Top | Mocke Tech. LLC. - 合同会社もっけ技研

またこの先、基板製造サービスや部品メーカー等様々な外部組織と連携して進めていきますが、選定基準としては下記の項目が上げられます。
どんなプロジェクトでも重視される項目ですが、IoTのプロジェクトにおいてはより強く影響する部分が多いかと思います。

①費用
やはり費用を如何に抑えるかというところはプロジェクトとして大事です。
仕事を依頼できそうな数社に目星をつけ、相見積もりを取りましょう。
「ここしかない！」というサービスを見つけても最低もう一社からは見積もりは取りましょう。
2社以上を比較することで、どのようなことをサービスとして提供してくれるのか？
どの辺りにコストがかかるのかなど正当性がわかります。

②納品速度
費用と同じくらい大切です。
同じ部品でもメーカーさんによって数週間〜数ヶ月単位で差があったりします。
「どこも同じだろう」と思い込んでいると、実はもっと短縮できたなんていうケースもあります。
見積もりを頂く段階で納期についてもざっくり聞いておくと良いです。

③レスポンスの早さ
プロジェクトにおいては返答一つの遅れがスケジュールに地味に響いてきます。遅いところは本当に遅く、見積もりを依頼した数社の中では一週間返事が返ってこないところもありました。
問い合わせへの返信の早さ・見積もり提出の早さ等で見てみると良いかもしれません。

スケジュールの策定

今回のプロジェクトのデッドラインは、既製品であるカードリーダーの保有在庫が尽きるまで です。
このプロジェクトは2020年4月に開始しましたが、その時点の試算では1年後である2021年3月までは保有在庫分で間に合うと判断しました。
ですので具体的なゴールとしては
「2021年3月末時点で自社製カードリーダーを500台納品すること」
と設定しました。
そこから逆算して「2020年9月末までにプロトタイピングを完了させる」というのを当面のゴールとして設定しました。
あとはそれに必要な部品の調達や実装など、作業をブレークダウンしてWBSツール（今回はInstagantt）を利用して可視化しました。
もちろんこの間に代替の打刻機能も平行して検討を進め、万が一に備えました。

Online Gantt Chart Software for Project Management | Instagantt

スケジュールを左右する要素

大まかなスケジュールを引くことはできましたが、実際に進めてみるとソフトウェア開発ではあまり無い要素でスケジュールを左右するものがありました。

①部品調達にかかる時間
プロトタイプを作るには各電子部品や外装の素材等の調達が必要です。
一般的なものであればECサイトでも購入できますが、モノによっては直接秋葉原に行って電子部品屋さんで調達したほうが早いモノもあります。
特にモジュール系は定常的に量産していないものだとストックが無いことも多く、余裕を持った調達スケジュールが必要です。

②基板製造にかかる時間
ソフトウェアの場合、失敗しても修正はすぐに行なえますがハードウェアはそうはいきません。
基板も最初こそブレッドボードなどで柔軟な形で検証しますが、いざ基板を作ってみると意外と部品配置を変えたいことも多く、2~3回は基板の作り直しが発生しました。
また、基板製造・部品実装には1回につき少なくとも約2週間ほどかかると見ておいたほうが良いです。

③プロトタイプ製品のやりとりにかかる時間
コロナ禍で製品開発をするにあたって障壁だったのがモノのやりとりです。IoT製品では不具合を確かめるにはやはり現物が必要になります。
今回は協力会社の他に社内のアプリエンジニアにも協力いただいていたので、そこに私を含めた3者間でプロトタイプ製品をやりとりしていました。
通常であれば弊社オフィスと協力会社オフィス間でやりとりできれば良かったのですが、緊急事態宣言で、フルリモート化したため、それぞれの自宅宛にモノを配送する、といった対応が必要になりました。
また、そのやりとりにも数日かかるため、わずかではありましたがスケジュールにも影響しました。

このようにIoT製品・ハードウェアはその性質から、物理的に時間が必要になることが多いです。ソフトウェアとは違い、工夫でどうにかできない部分もあるのでやはりプロジェクト全体として3ヶ月ほどのバッファは持っておくと良いと感じました。

見積原価計算書の作成

開発・製造にかかるコストも見積もらなければなりません。
書式や書き方については下記の書籍が参考になりました。
それ以外もIoTの製品開発・量産体制に関する有意義な情報が載っています。

メイカーとスタートアップのための量産入門

予想のつかない部分の方が多いですが、分かっているものからリストアップし管理するようにしました。
具体的にかかるコストとしては

• 協力会社への業務委託費
• 基板製造/実装費用
• 部品購入費
• 外装製造費
• 組立費

これらから、量産した際に1台あたりにかかる費用（原価）を試算します。
そのためにはまず各費用を固定費か変動費に分類する必要があります。
固定費とは生産台数によって左右されないものです。
今回でいえば 「協力会社への業務委託費」 が当てはまります。
他の費用は生産台数によって左右されるので変動費にあたります。

生産数５００台、卸率100%、各費用を100万円と仮定して表にしてみると下記のようになります。

当たり前ですが、価格は最低でも変動費単価より上に設定する必要があります。でないと作るたびに赤字になってしまいます。
また、卸率100%として考えると「固定費/生産台数」の分も足すことで1台目の販売から製造原単価を回収することができます。
しかし固定費は生産台数によって増えることが無いため、価格が変動費より高ければいつかは固定費分の原価も回収できます。

では、いくらに設定すれば、何台販売することで原価を回収できるのでしょうか。いわゆる損益分岐点ですが、それは下記のようにすると可視化できます。

各費用の見積もり

①基板にかかる費用
今回、基板製造/実装費用と部品費用は協力会社よりプロトタイプが上がってきた段階で見積れました。
今回は P版.com という基板製造・実装を行なっているサービスを利用し、web上で見積もりを取りました。

プリント基板の製造・設計・実装ならプリント基板ネット通販P板.com

②外装にかかる費用
外装に関しては大きく分けて3つの手段があります

• 3Dプリンター
• プラスチック射出成形金型
• 市販品のケース

プロトタイプでは3Dプリンターで作成しましたが、量産時はそれだとコスパが悪いので金型を作るか、既製品を使う必要があります。
500台程度では金型はコスパが悪いので既製品を使うことを想定しました。

タカチ電機工業 - 産業用・工業用のケース・ボックス・ラック・筐体の製造メーカー

法令の確認

利用する部品や技術が決まったら、それが国内で販売可能かどうか確認する必要があります（確認しながら部品・技術選定するというのが正しい手順ですが）。
具体的には

• 技術基準適合証明、技術基準適合認定（いわゆる技適）
• 電波法
• 特許/著作権

などです。
これらに抵触してしまうと量産しても販売できません。
量産フェーズに入った後で気づいた場合大きく手戻りするので、徹底的に確認しましょう。
弊社では法務担当を通し弁護士様に確認していただきました。
今回の製品では技適や電波法に関しては認証済みのモジュールをそのまま使っていたので問題ありませんでした。
しかし Bluetooth 技術を使っているので BluetoothSIG という団体に製品登録をする必要がありました。
登録料が必要なのですがなんとその額 $8,000 😱
Typoではありません。約80万円です。

このように法規制や特許利用額など、プロジェクト自体の続行可否を左右する要素が詰め込まれています。
なのでプロトタイピングの時点からこれらを考慮する必要があります。
実はこれに気づいたのは量産直前で、問題の解決に中々苦労しました……。

関連: ESP32を用いたBLE製品をBluetoothSIGに登録した話

量産に入る前に……

ここまで来ると現実的に量産して販売可能かどうか、費用面・スケジュール面・技術面で判断が付くようになるかと思います。
そうなるといよいよ量産です。
が、何事もぶっつけ本番では失敗します。やり直しの難しいハードウェアなら尚更ですので、やはりまだまだやることがあります。

これらも書いていきたいのですが少し長くなりそうなので、今回はプロトタイピング編として一旦ここまでとさせていただきます。
最後までお読みいただきありがとうございました。

株式会社ネクストビートでは
「人口減少社会において必要とされるインターネット事業を創造し、ニッポンを元気にする。」
を理念に掲げ一緒に働く仲間を募集しております。
ソフトウェアに限らず、必要であればIoT製品も作ってしまう。
無ければ作ればいい。
そんな永遠ベンチャーな会社です！

SaaS／エンジニアオープンポジション | 株式会社ネクストビート

Webサービス開発会社でIoT製品を開発した話（プロトタイピング編） was originally published in nextbeat-engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.

こんにちは。エンジニアの久保です。
普段はKIDSNAコネクトというサービスを開発しています。
自作キーボード制作が趣味なのですが、それが高じて今回IoT製品の開発をマネジメントすることになり、色々と躓いた部分がありました。
特に今回はBluetoothSIGへの製品登録について書きたいと思います。

ESP-WROOM-32

ESP32 Wi-Fi & Bluetooth Modules I Espressif

今回用いたのは、皆さんご存知の通称ESP32。
Espressif 社から提供されている、Wi-FiやBLEといったモジュールが搭載された便利マイコンです。
プロトタイピングにはもってこいです。
今回はそれを製品版にも使うことになりました。

BluetoothSIG

Bluetooth Technology Website | The official website of Bluetooth technology.

Bluetooth技術を用いた製品を製造・販売するにはBluetoothSIGに製品を登録する必要があります。
登録と言ってもその手段はいくつかあり、
①認証済み製品を指定して利用登録をするパターン
②認証済み製品を組み合わせて指定し、利用登録をするパターン
③適合試験を受けるパターン
があります。

最も簡単なのは①です。
認証済み製品を用いていなかったり、改変を加えた場合は③で対応する必要があり、費用も増えます。
①か②であれば必要な費用は登録料$8,000のみです（といっても高額ですが）。

今回は当初①で済むと思っていたのですが、最終的には②の方法で登録しました。
その経緯を後述します。

結論

先に結論だけ述べますと、今回は

• Controller Subsystem: ESP-WROOM-32
• Host Subsystem: ESP NimBLE Host

で登録しました。
実際に登録されたページはこちら: KIDSNA Connect IC Card Reader

当初、Host Subsystemには BR/EDR/LE Dual-mode Host Stack を用いようとしていたのですが、これが最新のBLE仕様では非推奨とのことで、「NimBLE」の方に量産直前に切り替えることになりました。
これからはESP32のBLE周りはNimBLEが標準になっていくそうなので、NimBLEを選んだ方が無難です。ちなみにHost Subsystem等、構成を後から変えようとすると別途登録料が$8,000必要です。

今回は回避方法があり、事なきを得ましたが、Bluetooth製品を開発するとなった段階でどのモジュールを使うのか、それがどのような手段で登録可能なのか、は調査必須であると学びました。

Product Typeについて

今回SIGへの登録に躓いた要因として「Product Type」の認識漏れがありました。
BluetoothSIG認証済みのモジュールには、それぞれProduct Typeという種別が付与されて登録されます。
この種別によって利用登録の仕方が変わるので利用するモジュールのProdcut Typeは確認必須です。
認証済みモジュールは下記から型番などで検索できます。
https://launchstudio.bluetooth.com/listings/search

詳細は省きますが、Product Typeが 「End Product」 であれば、前述した①の方法で対応可能です。
ですが ESP-WROOM-32 は 「Controller Subsystem」 で登録されていました。
Controller Subsystem は 「Host Subsystem」 と組み合わせなければ登録できません。
Controller Subsystem はざっくり言ってしまえばハードウェア部分を指し、Host Subsystem はアプリケーションを動かすソフトウェア部分を指します。
つまりソフトウェア部分でどのモジュールを使うのか決めてあげる必要があった、ということです。

BluetoothSIGへのアカウント登録（準備）

今回はBluetoothSIGへの登録も初めてでしたのでその手順も載せます。
本筋からは逸れますので、既にご存知の方は読み飛ばしてください。
注意点は下記の通りです。

1. BluetoothSIGのアカウントは基本的に１法人につき１アカウント
2. 登録者は会社役員、もしくはその役員から委任された人物である必要がある
3. 登記簿謄本（履歴事項全部証明書）が必要

1に関しては登録に用いるドメイン部で判断しているらしく、同じドメインのアドレスは基本的に１つしか登録できません。
なのでgmail.com等は利用不可です。会社ドメインのアドレスが必要です。
さらに1社1アカウントの制限があるので、社員の個人アドレスで登録すると何かと不便です。
今回私は社内で共有できるメーリングリストを新たに作成し、そのアドレスで登録するようにしました。
これで関係者はSIGからの連絡を受け取れますし、仮に私が担当を外れても何ら問題ありません。

2に関しては、社長に承認を得て社長名義で登録を行いました。
役員から委任された人物としての登録でも可能なのですが、その証明にも別途書類が必要です。
ですのでやはり役員に承認を得てその名義で登録するというのが一番シンプルかと思います。

BluetoothSIGへのアカウント登録（作業）

メンバーのタイプは「アダプター」と「アソシエイト」があります。
継続的に製品を開発していくならアソシエイトの方が割安らしいですが、弊社ではその予定はなかったので今回はアダプターメンバーとして登録しました。
https://www.bluetooth.com/ja-jp/develop-with-bluetooth/join/

1. 国を選んでメールアドレスを入力

2. 企業情報を登録（登記簿謄本をアップロード）

3. 登録者情報を入力

4. 住所を入力

5. 最終確認して確定

これでしばらくすると登録が完了します。
すべて英語ですがフォーム自体は至ってシンプルです。
臆せず登録しましょう。

製品の登録（準備）

製品の登録に必要な情報は下記の通りです。

• Product Full Name: 製品名
• Model Number： 型番
• Description: 製品説明
• Listing Date: 公開日（登録作業の翌日以降〜3ヵ月の範囲）
• Publish Date: 製品情報の公開日（Listing Date以降の日付、かつ登録作業お翌日以降で3ヵ月以内)
• Category: 製品カテゴリ（選択式）

弊社が登録した内容は先程も記載した登録ページと照らし合わせれば確認いただけます。
KIDSNA Connect IC Card Reader

製品の登録（作業）

1. https://www.bluetooth.com/ にアクセス
2. 左上のMyBlueを押し、サイドメニューのMyListingsを選択

3. Getting Started タブを選択し、No Required Testingの方のボタンを押します

4. プロジェクト名を入れ、Controller Subsystem(97618) と Host Subsystem(131934)のQDIDを入力し選択します

5. Add Productボタンを押下して用意した情報を入力します

6. Pay Declaration Feeボタンから登録料を支払いましょう

7. 内容を最終確認して完了です

最後に

以上の作業を行えば数日で登録完了のメールが送られてきます。
これでこの製品にBluetoothマークを利用したり、そもそもBluetooth製品として製造・販売することが許諾されます。
サイトは全部英語ですし、手順も煩雑で費用も高額と、初心者には優しくない設計でしたが、様々な方の助けをお借りし、なんとか登録することができました。
近々SIG登録に至った製品自体の開発経緯も記事にしたいと考えています。
最後までお読みいただきありがとうございました。

株式会社ネクストビートでは
「人口減少社会において必要とされるインターネット事業を創造し、ニッポンを元気にする。」
を理念に掲げ一緒に働く仲間を募集しております。
ソフトウェアに限らず、必要であればIoT製品も作ってしまう。
そんな永遠ベンチャーな会社です！

SaaS／エンジニアオープンポジション | 株式会社ネクストビート

ESP32を用いたBLE製品をBluetoothSIGに登録した話 was originally published in nextbeat-engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.

こんにちは。nextbeatのDevelopment Division に所属している 久保 です。

本日は弊社のキーボード事情について書かせて頂きます。

※「突撃！隣のキーボード」について
自社のキーボード事情についてまとめた記事によく使われるタイトルで、様々な企業様が毎年投稿されています。

突撃！隣のキーボード — Google 検索

ここ数年で自作キーボードなるものが流行りだし、割れたり光ったり多様化が進んでいるキーボード界隈ですが、弊社のキーボード事情はどうなっているのか。
それでは紹介してまいります。

キーボード種別の割合

はじめに弊社の開発グループではどのようなキーボードが多く使われているのかグラフにしてみました。

なんと同率１位でビルトイン(MacBookProのキーボード)と自作が並びました！
※自作は『現在制作中。完成したら業務で使う』という方も含んでいます。
全体的にみると7割以上の方が何かしら外付けキーボードを利用している、という結果になりました。
外付けキーボードを使用しているメンバーからは

• MacBookの位置が自由になるのでディスプレイとかぶらなくなる(40inchディスプレイユーザー)
• MacBookをスタンドに乗せて、ディスプレイとして見やすい位置に置ける
• 打鍵感にはこだわりたいので、お店で選びに選んで購入した

という声が上がっていました。

ビルトインキーボード

ビルトインユーザーの方からは

• Macひとつで済むし、コンパクト
• 家と職場で環境を揃えたい
• モノを増やしたくない

などの意見を頂きました。
確かにいつでもどこでも同じ環境で開発でき、しかもコンパクトというのはビルトインにしかない利点ですね！

自作キーボード

次に多かったのは自作キーボード。

少々割合の多さに驚いているのですが、種別でいうと

• Mint60
• Lily58 pro
• Corne Cherry
• Silver Bullet

の4種類でした。

自作キーボードユーザーからは

• 肩こり対策として分割キーボードを使ってみたかった
• 自作キーボードをやってみたかった
• 光らせたい
• 程よいキーの数、サイズ感

などのご意見を頂きました。また女性エンジニアからは『手の大きさ的に馴染むものが選べるので、個人的には女性ほど自作キーボード推奨したい』という意見も頂きました。
私はCorne Cherryを愛用しているのですが、男性でもやはり自分の手のサイズ感に合ったキーボードというのは使いやすいなと感じております。

ちなみに最近はオフィスでも自作キーボードを作っています。

Katz on Twitter

ついに社内でもキーボード作りを始めてしまった

次に割合が多かったのはメカニカルキーボード(HHKB以外)です。

メカニカルキーボード

こちらも種類は様々で

• Majestouch 2
• ProgresTouch RETRO
• Realforce for mac
• Das Keyboard
• HAVIT HV-KB390L (勝利キーボード)

などがありました。

中でも弊社CTOの衣笠は15年前からFilcoの Majestouch を愛用しているらしく、毎年同じものを購入しているとのこと(キートップの印字が無くなってしまうので)

また弊社内において勝利キーボードと呼ばれている少々変わった名前のキーボードを使っている方もおりました。
いわゆる日本語訳の誤訳結果なのですが名前以外もいろいろ誤訳がありSlackでも盛り上がっていました。

怖気づくことなく購入を決意した彼には賛辞を送りたいです。

HHKB

そして次に多かったのはHHKB！
あえてメカニカルキーボードと分けたのはその割合の多さゆえです。
なんとHHKBだけで18.5％!!

HHKBユーザの方々からは

• 打鍵感が心地よい
• 音がイイ！！
• Macに乗せられる(尊師スタイル)ほどよいサイズ感

とのお声が上がりました。私もその打鍵感に魅せられ愛用していた時期がありました。最新作が発表されたこともあり、HHKBの輪はまだまだ広がりそうです。

メンブレン

最後にご紹介するのは外付けのメンブレンキーボードです。

メンブレンユーザーの方々からは

• Macとの親和性
• かっこいいデザインのものが多い

とのご意見を頂きました。
たしかにMacBookProのメンブレンキーボードとの同じ使用感であった方が違和感なく使い分けられそうです！

その他のデータ

さて、ここからは他の統計データからも弊社のキーボード事情を読み解いてみます。

キー配列

まずはキー配列です。
こちらはUSが過半数を占めていますね。
ですがあえてUSを選んだ、というよりはJIS/USどちらでも対応できる、といった方も多く、その場その場の環境に合わせているようです。
ですがやはり記号の位置などが違うのでそれぞれこだわりが強い方もいらっしゃいました。

軸の種類

次に軸の種類です。
これはやはりビルトインであるMacBookのバタフライキーボードが最大勢力でした。次いで自作勢のタクタイル、HHKBの静電容量方式が並んでいます。ちなみに先述の勝利キーボードは『ロープロファイルのクリッキー』という珍しいタイプでした。

キーコンフィグ

また、キーボードにこだわる人はハードウェアやソフトウェアでの設定(キーコンフィグ)もこだわっているのでは？
と思い、何かしら制御している人とそうでない人で分類してみました。

約半数が何かしらの設定をしているということで詳しく聞いてみると、

• 特定のアプリを呼び出すホットキーを設定している
• CapsLockをEcsやCtrlにしている
• Ctrlを押しながらhjklを入力することでカーソルを上下左右に移動するよう設定している

などなど皆さんの独自のこだわりが垣間見えました。
私もQMKのマウスキー機能などを愛用しています。

以前使用していたキーボード

さらに以前使用していたキーボードを聞いてみたところ、ほとんどの方がビルトインのキーボードを使用していたことがわかりました。
ここ1年で外付けキーボードを購入したり、自作キーボードを作ってみた、という方が多いという結果になりました。

こうなってくると1年後の弊社のキーボード事情はどうなっているのだろう🤔と気になってしまい、『次に使ってみたいキーボードはありますか？』と聞いてみました。

次に使ってみたいキーボード

自作に興味がある方多め！
皆さん何かしら現状のキーボードに小さな不満はあるらしく、それを解決する策のひとつとして自作を候補に入れている方がいらっしゃいました。

そしてやはりHHKBが人気！！
周りで使っている方が多く、興味がそそられる方が多いようです。
私も新卒時代先輩に憧れて初めて購入した外付けキーボードがHHKBでした。不動の人気は衰えるどころか新作のおかげで勢いを増しているようです。

興味深かったのが『自作はハードルが高いけど、何かしらセパレートキーボードは使ってみたい』という声が少数ながらありました。
既製品でももちろん分離型キーボードはあるので試して頂きたいですね！

以上、弊社のキーボード事情に関する今年の調査結果でした！
思った以上に自作率が高かったり、HHKBの厚い層があったり、個人的にはとても興味深い内容でした。
1年後にこの割合がどうなっているか、またご報告できればと存じます。

この記事はCorne Cherryで書きました。

お知らせ

ネクストビートでは毎週木曜日に社内外の交流の場「Passenger’s Bar」を開放しています。もしこの記事を観て「ネクストビート気になる」「キーボード談義したい」「話聞いてみたい」という方がいらっしゃったら、気軽に遊びに来てください。

▼過去開催時の様子

バーテンダーが作るお酒飲みながら気軽に社内外交流ができる「夜活」の開催レポート（エンジニア・デザイナー編）

▼申込フォーム

突撃！隣のキーボード nextbeat 2019 was originally published in nextbeat-engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.

はじめに

こんにちは。nextbeat 開発グループに所属している 久保 です。
nextbeat では保育園向け業務支援サービス KIDSNAコネクト の開発を担当しています。

現在 KIDSNAコネクト では主に保育園の 経営業務 が楽になるような機能を開発しています。
具体的には 労務管理、保育料金管理 等 バックオフィス系 の機能強化です。

連続するデータを１つずつ前後処理する

バックオフィス系の機能はビジネスロジックが複雑になりがちです。
手続き型言語ばかりやってきた自分としては、複雑な処理を関数型ライクに書くことに苦労していました。
つい先日も 連続するデータの差分を１つずつ取得する 処理で「なんとか綺麗に書けないか」と悩んでいました。
その際、諸先輩方にアドバイスを頂きましたので共有しようと思います。

今回はもっと簡素化した、
１年間の月次平均気温データから各月の気温差を取得する処理
を例に見ていきたいと思います。

その１：再帰とmatch式を使う

再帰 と パターンマッチ を使った関数型言語らしい書き方かと思います。
１つ目のポイントとしては match式 の部分です。

case head +: second +: tail =>

SeqLike な値に対してこのようなパターンマッチを行うと、以下のように評価されます。

case １つ目の値 +: ２つ目の値 +: それ以降の残りの値 =>

今回の場合、一番最初のループでは以下のように評価されます。

Seq(4, 5, 11, 17, 19, 22, 28, 28, 22, 19, 14, 7) match {
  case 4 +: 5 +: (11, 17, 19, 22, 28, 28, 22, 19, 14, 7) =>
    f(Seq.empty :+ abs(4 - 5), 5 +: (11, 17, 19, 22, 28, 28, 22, 19, 14, 7))
  ……

head , second として取り出し、前後処理しています。
そして２つ目のポイントですが再帰関数(f)です。
第１引数は気温差のSeq、第２引数は残りの気温Seqを渡しています。
これを繰り返すと、tSeq の中身が１つになった時点で、match式１つ目のパターンにマッチしなくなります。
そして、最終的に今までの結果を集めた diffSeq を返すことで気温差Seqを取得しています。

ちなみに関数fの上にある

@scala.annotation.tailrec

はその下の再帰関数が末尾再帰に最適化されているかどうかを、コンパイル時にチェックするためのアノテーションです。
末尾再帰として最適化されていないとコンパイラがコンパイルエラーとして扱ってくれます。

再帰関数は階層が深くなるとスタックオーバーフローする可能性がありますが、末尾再帰最適になっているとコンパル時にループへ変換されるのでこれを回避する事ができます。なので特殊な理由がない限りアノテーションは付けて末尾再帰にすべきです。

その２：前後の値を１セットにしたコレクションを使う

個人的には再帰処理の方が書き始め易いのですが、やはり最終的に読みやすいのは foldLeft でしょうか。最初は再帰で書いてその後 fold に清書する、というのもアリかもしれません。

まず最初に sliding を使い、先頭から2つずつ要素を取得したコレクションを生成します。sliding の返り値は Iterator[Seq[Int]] です。実際にどんな値が返ってきているか確認するために toListしてみると下記のようになります。

tSeq.sliding(2).toList
// -> res0: List[Seq[Int]] = List(List(4, 5), List(5, 11), List(11, 17), List(17, 19), List(19, 22), List(22, 28), List(28, 28), List(28, 22), List(22, 19), List(19, 14), List(14, 7))

コード上ではSeqのままですが、これを foldLeft で回して、気温差を取得していきます。

まとめ

関数型言語に慣れた方々からすれば大した内容ではなかったかもしれませんが、PHPerだった自分としては目から鱗でした。
今回はその１とその２の違いについてまでは踏み込めませんでしたので、今後はそういったパフォーマンス等の違いも調べたいと思っています。

告知

隔週木曜日に恵比寿のオフィスで夜活（交流会）を実施しています。
転職希望ではなくても当社にご興味をお持ちの方は是非遊びに来てください！
綺麗なオフィスで軽食とお酒を楽しみましょう！

ネクストビートの「夜活」を紹介します！ | イベント

Scalaでコレクションを前後処理しつつ走査する was originally published in nextbeat-engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.