DDD in Scala に関するメモ

マイクロサービス化するならScalaでなくてもよい
  • 型を共有できない、共有するのが大変なのでScalaのメリットがあまりない
  • Scalaやるならモジュラーモノリス
    • sbtのサブプロジェクト機能が便利

    TDDに関する所感

    静的型付け言語との相性について
    • そこまでではない
    • 解決しようとしている問題領域が多少重なっている気がする
      • 特定の時点における整合性(コミット時点の整合性)
        • 静的型はこちらに強い
        • テストはこちらに弱い
      • 変化に対する整合性(コミット前後の整合性)
        • 静的型はこちらに弱い
        • テストはこちらに強い
    • 思考・開発フローとの折り合いがそれほど良くない
      • 差分ごとに型を変えるのが手間
  • 最小手数で書いて通すので局所最適に陥りそう
    • bad practiceルートに入りそう
  • 時間不足や割り込み作業などでblush upが足りないままマージされる恐れ
  • 手作業が多い
  • 先に要求に関するテストを書き、実装に関しては静的型で検査するのがよさそう

  • org.scalatest.concurrent.ScalaFutures について

    ScalaFuturesとは
    • お手軽にAwaitしてくれるやつ
      • Await.ready(scalaFuture, Duration.fromNanos(config.timeout.totalNanos)).eitherValue.get
    • implicit conversion用メソッド

    AsyncTestSuite とは
    • Future.map 内での評価も有効にしてくれるやつ
    • executionContextを提供してくれるやつ

    AsyncTestSuiteとScalaFuturesとの関係
    • AsyncTestSuiteを使っている限りはScalaFuturesに頼る必要はない
    • AsyncTestSuiteを使っている場合にScalaFuturesを併用するべきでないか?
      • 一般的には問題ない

    CircleCIからHerokuにデプロイできない

    CircleCIからHerokuへのデプロイが失敗してしまう。
    • "Invalid credentials provided." と言われる

    エラーメッセージは以下。

    (Compile / deployHeroku) com.heroku.api.exception.RequestFailedException: Unable to list config failed. statuscode:401 responseBody:{"id":"unauthorized","message":"Invalid credentials provided."}

    原因は Credentials、つまりHerokuから取得したAPI Keyが古かった。おそらくはHeroku側の都合でパスワードがリセットされたのか、一旦ログインできなくなっていたのでその影響か。

    アカウント設定ページ(https://dashboard.heroku.com/account)からAPI Keyを再取得し、CircleCIの環境変数に設定して完了。デプロイできるようになりました。

    ScalaTestのAsyncTestSuiteとAkkaのTestKitとの相性が悪い

    要旨
    • ScalaTestは非同期でのテスト用にExecutionContextを提供するAsyncTestSuiteが用意されている
      • AsyncFunSpecなど
      • org.scalatest.concurrent.SerialExecutionContext
    • Akka TestKitにはテスト用のExecutionContextが供給されている
      • akka.testkit.CallingThreadDispatcher
    • SerialExecutionContextからCallingThreadDispatcherを呼ぶとデッドロックする(逆も然り)

    IntelliJ IDEAのScalaプラグインのsbtシェルのヒープサイズを設定する

    sbtシェルは便利ですが、ヒープサイズが小さくてOutOfMemoryErrorが出てしまう場合があります。

    そのようなときはIntelliJの設定画面からsbtの設定を開き、最大ヒープサイズを適切な値に設定します。

    これによってsbtの起動時に-Xmxが指定した値に設定されるので、メモリ不足が解消します。


    Lightsail インスタンスにSSHで接続する

    キーを取得する


    デフォルトキーで作成している場合には以下のページからダウンロードできます。


    キーをダウンロードして ~/.ssh ディレクトリに保存します。

    キーのアクセス権限を変更する


    chmod 600 ~/.ssh/LightsailDefaultKey-ap-northeast-1.pem

    インスタンスに接続する


    ssh -i ~/.ssh/LightsailDefaultKey-ap-northeast-1.pem bitnami@<hostname>

    macOSにおけるnode.js環境構築手順 2020

    2020年11月12日時点での、macOSにおけるnode.js環境の構築方法について記録しておきます。

    インストールするもの

    homebrew、nodenvはわかりますがanyenvというのは見慣れないですね。

    どうやら *env といった環境管理ツールを管理してくれるというメタなツールのようです。

    言語やツールごとに増えがちで管理も難しいので嬉しいです。

    実はjenvとかも管理できるようなので、Java/Scala使いにも嬉しい可能性があります(未検証)。

    Homebrew

    Homebrewをインストールする方法はScalapediaにて解説済みなのでそちらをご覧ください

    macOSにsbtをインストールする方法|Scalapedia

    anyenv

    brew install anyenv
    

    nodenv

    anyenv install nodenv
    nodenv init
    

    以下のようなコマンドをどこかに記述する必要があります。

    eval "$(nodenv init -)"
    

    nodenv initの実行時の出力に、どこに記述すればよいのかが明らかにされます。
    これを参考に追記しましょう。

    今は一般的には ~/.zshrc に追記することになるんですかね。

    node.js

    nodeの一覧を最新に更新します(インストールしたては不要)

    brew upgrade nodenv node-build
    

    一覧を表示します。

    nodenv install --list
    

    表示した中で必要なnodeをインストールします。

    nodenv install 14.15.0
    nodenv global 14.15.0
    

    installだけではまだ全体に反映されません。
    global コマンドを使用すると、バージョンが固定されます。

    特定のディレクトリのnodeを固定するには local コマンドを使用します。

    nodenv local 14.15.0