Akka is a great tool for writing distributed applications. One thing that always surprised me though is that while being based on Scala, which is a very type-safe language, the … Continue Reading →
MacWire 0.2: Scopes are simple!
MacWire generates new instance creation code of given classes, using values in the enclosing type for constructor parameters, with the help of Scala Macros. DI container replacement. Version 0.2 has … Continue Reading →
Per-commit e-mail GitHub notifications
One thing that I miss in GitHub is the ability to get e-mail notifications on each push/commit. There is an option to set an e-mail notification address in the repository … Continue Reading →
MacWire 0.1: Framework-less Dependency Injection with Scala Macros
Using Dependency Injection is almost a standard when developing software. However, in many cases it may seem that using the pattern implicates using a DI container/framework. But is a framework … Continue Reading →
How to replace a build module with Veripacks
Compare the two trees below. In both cases the goal is to have an application with two independent modules (frontend and reporting), and one shared/common module (domain). The code in … Continue Reading →
Dependency injection with Scala macros: auto-wiring
You can look at dependency injection as a fancy name for passing parameters to a function (or constructor arguments to a constructor). However usually, DI containers do much more than … Continue Reading →
Veripacks 0.3: importing packages (transitively, of course)
Previous versions of Veripacks focused on defining what classes are visible outside of a package hierarchy (exporting). This release focuses on defining what classes can be used inside a package … Continue Reading →
xsbt-proguard-plugin – taking over, new release
I recently took over the maintenance of xsbt-proguard-plugin from siasia. The plugin lets you create single “fat” jars from your project, using the Proguard library. Some of the most important … Continue Reading →
Veripacks 0.2: exporting subpackages
Veripacks 0.1 allowed to specify which classes should be exported from a package hierarchy, by using a simple @Export annotation, and later verify that the specification is met. Version 0.2 … Continue Reading →
Dry parameter names
How often do you see code like this, especially when using dependency injection, single-responsibility principle, and other “good practices”? 1 2 3 4 5 class FriendsTimelineReader(userFinder: UserFinder, userStatusReader: UserStatusReader, statusSecurityFilter: … Continue Reading →