github.com scalafmtはscalametaを利用したscalaのコードフォーマッタです。intellij plugin・sbt plugin・cli・mavenやgradle plugin といった様々な形で提供されており vim-autoformatなどを用いてvimからフォーマットを実行したり https://scalameta.org/scalafmt/docs/installation.html#vim git hook を設定したり Code formatting: scalafmt and the git pre-commit hook と様々な方法で利用することができます。 scalafmtの課題の一つはscalafmtの実行にかかる時間です。機能が豊富で複雑なため、ただでさえそれなりに実行に時間がかかってしまうのですが、さらに悪いことにscalafmtの実行
Performance comparison between different kinds of string concatenation/formatting in Java/Scala UPD: Here is the Pull Request to scala-compiler with changes inspired by this post. String concatenation is a basic building block in every modern programming language. Many different projects, especially in Web, produce a lot of strings. And it’s interesting, how this problem is solved in different lan
class: center, middle # Readable Scala Scala Matsuri 2017/02/25 --- class: left, middle ## Who am I * Manabu Nakamura * [@gakuzzzz](https://twitter.com/gakuzzzz) * Tech to Value Co.,Ltd. * Japan Scala Association ![t2v](http://www.t2v.jp/images/logo.png) --- class: left, middle ## Is Scala "Unreadable"? It often sees the claim that scala codes are unreadable. Because there are Implicit, there are
この記事は CAMPHOR- Advent Calendar 2016 7日目の記事です。 WartRemover は Scala のASTレベルの静的解析ツールで、WartRemover に組み込まれているパターンに加えて、自分で定義したパターンをビルド時に検出することができます。 これを使えばscalacはエラーや警告を出さないけど検出してほしいコーディング規約などをビルド時に検出することができるようになって便利。 github.com もとから組み込まれてるパターンはGitHubのREADMEに詳しく書かれています。 使ってみる 詳しくは GitHub の README を参照。 project/plugins.sbt に以下を追記 addSbtPlugin("org.wartremover" % "sbt-wartremover" % wartremoverVersion) bui
github にあるライブラリを使うのにローカルにインストールして云々しようとして色々試していたら id:xuwei と id:j5ik2o に github にあるライブラリ、直接使えるよ m9(^Д^)プギャー と言われて涙目でした。 んで、 あんまり知られてないし、教えてやったんだからブログに書け!! と、id:j5ik2o に脅されたので涙目で書いているところです。 import sbt._ import sbt.Keys._ object ProjectBuild extends Build { lazy val root = Project( id = "root", base = file("."), settings = Project.defaultSettings ++ Seq( name := "coderwall-bot", organization := "o
Scala Nativeはscalaのコードを(LLVMのIRを経由して)ネイティブコードにコンパイルするAOTコンパイラ(Ahead Of Time Compiler)です。その存在については、少し前にサイトができていたことで一部で話題になっていましたが、Scala Days 2016 NYCにて正式に公開されました。現在はPre-Release段階ですが、既にサンプルコードを試せるようになっていたので、環境を構築してみました(on Mac OS)。 scala-nativeのリポジトリをcloneする $ git clone git@github.com:scala-native/scala-native.git --recursive git submoduleとしてscala/scalaを持っているので、--recursiveを付けるのを忘れないようにしましょう。 llvm(cla
この記事の結論 globalなExecutionContextではブロックする処理をblockingで包むとスレッド数が勝手に増えるから空きスレッドが無くて実行できないといったことを防げる。 ExecutionContext.fromExecutorService(new ForkJoinPool(100)) で生成されるThreadはBlockContextトレイトを継承してないのでblockingを使ってもスレッド数を増やした方が良いという情報がスケジューラに伝わらない。 akkaのdispatcherをExecutionContextとして使うとBlockContext付きのForkJoinPoolを簡単に作れる。 ExecutionContext.fromExecutorServiceでもForkJoinPoolのコンストラクタに自前定義したThreadFactoryを渡すようにす
タイトルは煽りではありません。もちろん、Scalaを実用的に使う上では「直接」Genericsを扱えないのは困ります。しかし、記述の冗長ささえ我慢すればGenericsのほぼ全ての機能をAbstract Type Membersによって表現できます。このことを指して、GenericsはAbstract Type Membersでエンコードできると言ったりします。とりあえずコード出せやといわれそうなので、実際のコードを貼りつけてみます。 gist.github.com このコードでは、不変Listと、その上の高階関数mapとforeachをGenericsなしで構築しています。 ポイント: Genericな型 => Abstract Type Memberを持った型 Genericなメソッド => Abstract Type Memberとメソッドを持った型 関数 => Abstract T
On type safety for core Scala: "From F to DOT: Type Soundness Proofs with Definitional Interpreters" From F to DOT: Type Soundness Proofs with Definitional Interpreters by Tiark Rompf and Nada Amin: Scala's type system unifies aspects of ML-style module systems, object-oriented, and functional programming paradigms. The DOT (Dependent Object Types) family of calculi has been proposed as a new theo
⚠️ Beware of Scams: since Feb 2024, scammers are using fake Scala websites to sell courses, please check you are using an official source. For most of us, the change of the year is an occasion for thinking about what we missed doing last year and where we want to improve. I decided there are a couple of things where I would like to do better in 2016 than in 2015. The first is that I would like to
何はともあれ以下のコードを見てください(ちなみに複素数クラスの実装は、 d.hatena.ne.jp を参考にさせていただきました): trait Complex { type T def re(a: T): Double def im(a: T): Double def make(re: Double): T def plus(a: T, b: T): T def minus(a: T, b: T): T def multiply(a: T, b: T): T def divide(a: T, b: T): T } object Complex extends Complex { case class C(re: Double, im: Double) type T = C def re(a: T): Double = a.re def im(a: T): Double = a.im d
DIを使わない状態ではUserRepositoryというインターフェースが定義されているのにもかかわらず、UserServiceはUserRepositoryImplの参照も持っていました。 これではせっかくインターフェースを分離した意味がありません。 UserServiceがUserRepositoryインターフェースだけを参照(依存)するようにすれば、具体的な実装であるUserRepositoryImplの変更に影響されることはありません。 この問題を解決するのがDIの目的です。 それではDIのインジェクタを加えて、上記のクラス図を修正しましょう。 謎のインジェクタの登場によりUserServiceからUserRepositoryImplへの参照がなくなりました。 おそらくインジェクタは何らかの手段でサービスであるUserRepositoryImpl(Dependency)をクライアン
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く