Listは使わずにSeqにしなさいとよく言われるけど、何故そうなのかはいまいちよくわかってなかったので、調べました。基本的な内容です。 そもそもSeqとは Seq(scala.collection.Seq)は、Iterableのうち順序を持つものを指します。 全てのcollectionはIterableであるので、順序がある(要素にindexでアクセスできる)コレクションは全てSeqです。(SeqでないコレクションにはMapやSetがあります) Seqはscala.collection下にあるので、VectorだろうとMutableListだろうとSeqです。メソッドや関数の引数の型には、特別な理由がない限り、取りうる型の範囲を狭めてしまうListなどよりSeqを指定したほうが良さそうです。 scala> Seq res0: scala.collection.Seq.type = scal
はじめに 本記事は連載形式で執筆しています。ここまでの記事は以下の通り。 ①の記事 ~howとwhatの分離~ トランザクションとは よくリレーショナル・データベースで使われる言葉で、「データベースにアクセスする一連の処理のひとまとまり」を指します。 詳しくはこちら 前回の記事の最後で、 trait Transaction[A] trait UserRepository { def find(id: Long): Transaction[Option[User]] } このようなコードを書きました。 この記事では上記の通り、idでユーザーのデータを検索して、ユーザーを探してくる一連の処理をトランザクションとみなしています。 コミットとロールバック リレーショナルデータベースではコミットとロールバックという考えがあります。 ここでは読者の皆さんは上記概念を知っているものとして話を進めます。
追記 (2020-12-27) より基礎的な説明を Minimal Cake Pattern 再考 にまとめました。Minimal Cake Pattern という言葉を初めて聞く人は、こちらの記事を先に読むことをおすすめします。 Scalaにおける最適なDependency Injectionの方法を考察する 〜なぜドワンゴアカウントシステムの生産性は高いのか〜 で紹介されている Minimal Cake Pattern をもう少し詳しく解説します。 Minimal Cake Pattern それ自体は自明なものですが、いくつかの規約に従わないと混乱を招きます。以下の事柄を覚えておくと良いでしょう。 MixIn に extends はいらない trait UsesSomething { def something: Something } trait MixInSomething ext
DIを使わない状態ではUserRepositoryというインターフェースが定義されているのにもかかわらず、UserServiceはUserRepositoryImplの参照も持っていました。 これではせっかくインターフェースを分離した意味がありません。 UserServiceがUserRepositoryインターフェースだけを参照(依存)するようにすれば、具体的な実装であるUserRepositoryImplの変更に影響されることはありません。 この問題を解決するのがDIの目的です。 それではDIのインジェクタを加えて、上記のクラス図を修正しましょう。 謎のインジェクタの登場によりUserServiceからUserRepositoryImplへの参照がなくなりました。 おそらくインジェクタは何らかの手段でサービスであるUserRepositoryImpl(Dependency)をクライアン
2011-04-23 Akka の作者として益々注目を集めている Jonas Bonér が 2008年に書いた “Real-World Scala: Dependency Injection (DI)” を翻訳しました。翻訳の公開は本人より許諾済みです。翻訳の間違い等があれば遠慮なくご指摘ください。 2008年10月6日 Jonas Bonér 著 2011年4月22日 eed3si9n 訳 さて、実戦での Scala シリーズ第二弾の今回は、Scala を用いた Depenency Injection (DI) の実装をみていきたい。Scala は、備わっている言語機構だけを用いても何通りかの DI を実現できる非常に豊かでディープな言語だが、必要に応じて既存の Java DI フレームワークを使うこともできる。 Triental では、一つの戦略に落ち着くまで三つの異なる方法を試した
ScalaでDIします。Google GuiceというDIコンテナを用いて,Play Framework上で,またより一般的なScalaアプリケーション上でDIを行う方法について説明します。 Dependency Injection ナイーブなDI (コンストラクタ・インジェクション) DIコンテナ,DI手法 GuiceでDI trait インフラ層の1クラス コントローラ Guiceモジュール 実行時設定 テスト時 Playの機構によらない,Guiceだけ使った注入 まとめ 参考文献 Dependency Injection DIの概要は様々な良いエントリがたくさんあるのでさっと流します。 DIとはDependency Injectionの略語で,依存性注入と訳します。依存性というのはどういうことかというと,あるモジュールが別のモジュールを呼び出すとき,「呼び出す側のモジュールが」「呼び
DI(Dependency Injection)関連のお話です。以前以下の記事を書いたように、C#ならある程度理解できていました。 hiroronn.hatenablog.jp Scalaだとよくわからなくて…試したらだいぶすっきりした、という記事です。 いきさつ 最近Scalaで業務やっていて、テストするために依存性を解除しなきゃならないソースがありました。 とはいえ業務中にいろいろ試す時間はなく、また規模も小さかったため、手動テストで乗り切りました。 また、Scalaをやっていてずっと思っていたのが、 C#だとDIはコンストラクタ注入が主流*1だけど、C#のinterfaceとScalaのtraitは内容が違いすぎて、Scalaではコンストラクタ注入が使いやすいようには思えない というものです。なんとなく、そう思っていました。 そこで見つけた記事が、この記事のタイトルにもなっている以下
前書き Airframe Meetup #1 - connpassへ参加せてもらってなかなか良い刺激になったので、一念発起してScala用のDIライブラリの比較記事を書くことにしました。 が、ぶっちゃけるとAirframe: DI Framework Comparisonの記事のほうが100倍ぐらいDI真面目に使っている人がこの記事の10倍くらい時間かけて書いているに違いないのでそっち読んだほうがよいです。 この記事は多様かつ様々な視点からの意見があったほうがよいという背景から書いています。 ※注意: この記事を書いている人間はGuice, Airframe, MacWireそれぞれの使用時間が3時間未満なのでその程度の知識の人間が書いている前提で読んでください ドキュメント(仕様)を読んで比較して気づくこと Airframe: DI Framework Comparisonを参考にしつつ
これは何? Ruby畑での仕事が中心で他の言語/フレームワークを使った経験は皆無だったのですが、転職してScalaを使ったアプリケーション開発に携わることになりました。Scala全く分からん状態から仕事で使っていくために参考にさせて頂いた情報を軽くまとめました。これからScalaへ入門する方への助けとなれば幸いです。 ポイント Rubyとかの動的型付け言語から来た人は特に以下の理解が重要(かつ骨が折れる..)かなと思います。 Either,Optionなどの文脈付き型の理解 for内包式の理解 Generics/型パラメータの理解 ザッとScalaの全体について理解して、そこからはコードを書きつつ分からないことは適宜調べていくのが良いのかなと思います(理解し切るまで次に進まないスタイルだと、永久に仕事に進めないくらいボリュームある&難しいので...)。 書籍 実践Scala入門 薄いことも
この記事は、 FOLIO Advent calendar 2020 の22日目の記事です。 これは何? 「Scala3の予習したいけど時間がない!」「まだM3だしガチでキャッチアップするのはちょっと…」という人のために、公式ドキュメントを斜め読みした自分が仕事で影響が大きそうなScala3の変更点をまとめたものです。 ほとんどのサンプルコードは、Dottyの公式ドキュメントから引用しております。 val,def,型エイリアスがトップレベルに書けるようになった Scala2では、全てのval,def,型エイリアスは何かしらのclass,trait,objectなどの中に書かなければエラーになりましたが、Scala3では(まるでREPLのように)class外にdefやvalを定義することができるようになりました。package objectが要らなくなりますね。
SoRの性質が強いBtoBアプリケーションでは、「堅く」作ることを求められる箇所がしばしばあります。 Scalaの型安全性が頼もしく感じられるのは、まさにこのような箇所においてです。 「堅く」作るために、私たちがいま注目しているのが refined と newtype というライブラリです。 この記事では、refinedとnewtypeを使ってScalaの型安全性をさらに引き出すテクニックを紹介します。 Value Class / Tagged Type refined + newtypeの話題に入る前に、これまでにどのようなテクニックが使われてきたかを簡単に振り返りましょう。 ここに、SNSのユーザーアカウントを表現するクラスがあります。 case class User(id: String, email: String, age: Int) val user1 = User("@tod
import scala.concurrent.Future import scala.concurrent.ExecutionContext.Implicits.global val start = System.currentTimeMillis for{ _ <- Future(Thread.sleep(3000)) _ <- Future(Thread.sleep(3000)) } yield println("the process time is " + (System.currentTimeMillis - start) + " msec.") // the process time is 6141 msec. import scala.concurrent.Future import scala.concurrent.ExecutionContext.Implicits.g
コードを読み込みScalaの関数型パラダイムを学ぶ - xuwei-kがScalaを学ぶために読んだOSS 数多くのScala関連OSSにコミットを続ける吉田憲治(xuwei-k)さん。その精力的な活動を支える、関数型の知見の源をうかがいました。 オブジェクト指向言語と関数型言語の特徴を併せもつマルチパラダイム言語・Scala。この言語に関連するOSSのコミット履歴には「 xuwei-k」というアカウントが頻繁に登場します。今回お話を聞いた吉田憲治(よしだ・けんじ/ @xuwei_k )さん、その人です。 吉田さんはScalaのスペシャリストとして、数多くのScala関連OSSにコミットを続け、2018年、Scalaコミュニティに対する貢献者に贈られる「Phil Bagwell Award」を受賞しています。界隈屈指のコントリビューターとして知られる吉田さんに、Scalaのスキルを研鑽して
Scalazはscala上で関数型プログラミングをすることを支援するライブラリです。 2008/11/30にリポジトリが作られました。 各種モナドや便利な型クラスを導入してくれます1。 Catsもまたscala上で関数型プログラミングをすることを支援するライブラリです。 2015/01/25にリポジトリが作られました。 こちらもScalazとほぼ同じ概念を導入してくれます。 Catsが生まれた背景(ScalazのCoC問題) この2つは非常によく似ています。 以下のscaladocを見ればわかりますがクラスでも同名同機能のものや異名同機能のものが多数あります。 ScalazのScaladoc CatsのScaladoc ではなぜCatsが生まれたかというと、Scalazで過去ある騒乱があったためです。 OSSコミュニティがある日突然壊れたときにどうすればいいか - xuwei-k こちらが
scala> :paste // Entering paste mode (ctrl-D to finish) trait SuperMain extends App { def printClassName(): Unit println("Start") printClassName() println("Finish") } object Main1 extends SuperMain { def printClassName(): Unit = println("Main1") } object Main2 extends SuperMain { def printClassName(): Unit = println("Main2") } // Exiting paste mode, now interpreting. defined trait SuperMain define
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く