Saturday, April 16, 2016

Quickfix all the things with Sarsi

Here is a new project which got released recently on github and hackage, it is named Sarsi and it aim at being a sort of pandoc for quick fixing.

Quick fixing

It's basically fixing inside your text editor/IDE the warnings or errors returned by the compiler/build tool.

A sample session using sarsi-hs and sarsi-nvim.


I do use nvim with stack, and even though I really appreciate all the features provided by the neomake integration. I really like also to have my build tool running continuously and fix from the output of it, especially when hacking on source dependencies.

Doing some coding with sbt as well, it always felt wrong I had to use two completely different setups to solve the same problem.


Sarsi decouple this problem using a simple protocol which is implemented using msgpack and unix pipes. This should make it easily to embed a client directly into a text editor or a build tool.

The current implementation is written in Haskell, the library provide the main abstractions to write consumers/producers.

Where the terminology might ring a bell to those familiar with message brokers, we can basically say that a consumer is a text editor and a producer a build tool. This can slightly vary depending of integration needs.


There is currently two producers, one for Haskell, sarsi-hs (which should work with cabal and stack, but only tested with the later) and an other one for SBT, sarsi-sbt.

They do work slightly differently as you'll see in the documentation, but those details are abstracted away by the protocol.

It is then possible to consume those fixes using one of the two consumers.

The first, sarsi-nvim works exclusively for Neovim and gives the best experience and the easiest integration path.

If you prefer to keep your good old vim/vi, there is an other consumer,
sarsi-vi which will have to be started independently of your text editor.
It will then maintain in real time a file containing the fixes which you can load/reload using :cfile `sarsi`.vi .

Get started

If you would like to give Sarsi a try, checkout the README at:

You'll find there installation instruction, but if you have issues or would like to contribute a consumer/producer just join for a discussion.

Monday, December 22, 2014

The Cake Is a Lie

In case you don't know yet, the cake pattern is a terrible idea.

I often hear people advising to use the Reader Monad as an alternative, but even if I find the solution conceptually elegant (and I use it often in Haskell), I'm skeptical about it being practical in Scala.
Instead, I was -in my previous company- using mainly implicits with a bunch of ugly Guice refection at the top layer (an artifact from the past more than a principled technological choice).

Having the chance to start a greenfield project recently, I decided to find an alternative to the solutions I did know about... as none of them were really satisfactory.

Talks is cheap, show me the code.

Basically I use implicits until the application layer were I just have one layer of stacked trait... let's see it in action, in this gist we have:
  • common.Module
    • A basic trait to describe modules (set of components)
  • persistence.PersistenceModule
    • A module with two components
  • persistence.postgresql.Database
    • A component
  • web.controllers.Foo
    • A Play! controller
  • web.Global
    • Integration with Play! dependency injection
  • tools.InitializePlatform
    • Integration with a main application

This approach seems to work great so far! Let me know if you give it a try.

Saturday, February 2, 2013

Quick bug fixing in Scala with SBT and Vim

UPDATE: Dave Cleaver created a SBT plugin do generate quickfix!

Until now if you wanted to have vim quickfix integration with SBT, you had two solution:
Unfortunately none of them are in my opinion usable for day to day development:
  • Launching SBT from Vim create a new instance of SBT at each call, and starting SBT takes time... lot of time.
  • VimSIDE is still very experimental (wasn't able to make it work outside of the demo project) and heavy, too heavy for me... one of the reason I love using Vim it's because it's light, fast and he don't try to change the code I write because he pretend to be smarter than me (like IntelliJ).
So, I like to use SBT in his own shell, running in interactive mode and enjoying the power of '~' for continuous compilation/testing.
The only thing is that each time I'm fixing compilation errors/warnings I have to navigate manually to the file and enter the line number to jump in the right place.

This time is over!
The solution is very simple (but very hacky!), just a single bash script which:
  • Append warn/error SBT messages into a temporary file
  • Monitor certain action done in the interactive session and delete the file when necessary
Let's see how the script looks like:
That's all! if you want to use it:
  • Download and make it executable
  • Add it to your path with a fancy name (hint: qsbt)
  • Edit your .vimrc to add the SBT error format pattern and a key-binding (check comments in the script for an example).
And now enjoy continuous quick-fixing by starting sbt with the qsbt script!

Monday, May 16, 2011

A simple (REST) web service client in Scala

For the purpose of creating a nice API for my new project Caligo (more on this in a future blog post), I was looking for a simple solution to access REST web service in Scala.

My requirement was simple: access an HTTP web service, and exchange data with him using the JSON format.

During my experiment I came across theses two nice Scala libraries:

Dispatch seems to be the only available HTTP client for Scala today, and since it's based on the Apache's one no need to worry about his reliability or compatibility.

SJSON was choose against Lift-JSON due to it's better handling of reflection on beans, both of them did a great job on case classes, but only SJSON was effective on beans (was mandatory for me since I must do polymorphism on my model and case classes do not support this).

Lift-JSON support of beans (thru reflection) must be improved on the version targeting Scala 2.9

Here is a sample usage of the frameworks, both of them are easily integrated, and using the power of the Scala syntax a full client request doesn't take that much code to be implemented (in this case 4 lines of code, model included):

Tuesday, June 22, 2010

Vim is everywhere

I'm now sure that vim is the perfect tool to write *clean* code !

And for vim fanatics, you can even get vim inside NetBeans (integration work much better than in Eclipse):

Friday, April 30, 2010

Spring Batch integration module for GridGain

For the purpose of using Spring Batch in a scalable and distributed manner to process huge amount of data, I am actually developing some components to make integration of Spring Batch with compute/data grid easier.

Different solutions is offered by Spring Batch to provide scalability, the one that best suit my needs is remote chunking.

As I already done some investigation before using GridGain I chose this framework to implement a distributed remote chunking system that can be easily integrated into any existing Spring Batch systems.

Using GridGain is really straightforward, and setting up a grid on a development machine doesn't need so much configuration.

The only issue I faced is due to the fact that GridGain use serialization to deploy tasks on nodes, in order to be able to deploy a remote ChunkProcessor, it must contains serializable ItemProcessor and ItemWriter, which unfortunately is not the case by default.

So instead of creating new interfaces, I made a SerializableChunkProcessor which only accept serializable ItemProcessor and ItemWriter. It's surely not the smarter solution, but since I can't modify default interfaces in Spring Batch and I don't want to create my own interfaces, this workaround will suffice.

Here is the job application context used for the integration test, as you can see the 'real' ItemProcessor / ItemWriter are injected into the GridGain chunk writer:

You can download the spring-batch-integration-gridgain module here:

If you want to see a full working sample, take a look at the integration test. The full project sources can be downloaded here:

Thursday, March 25, 2010

Integrating failover strategy for Spring Security NTLM

During implementation of the NTLM authentication into our application, I wanted to achieve failover to standard login page (html form) if NTLM authentication fail.

In order to obtain the wanted behavior I extended some Spring Security classes and hack them a little bit, so I created:
  • An AuthenticationEntryPoint strategy to switch between NTLM or standard login
  • A custom AuthenticationProvider to prevent password checking when user authenticate with NTLM
  • A custom NtlmProcessingFilter to disable NTLM authentication if a remember-me cookie is present
The thing I was unable to do is detecting if the user client is NTLM compliant before starting the NTLM challenge. Due to the way the protocol is build (and certainly for security reasons) it's impossible to know if the client is NTLM compliant before launching the challenge.

So let's took the scenario of a Google Chrome user:
  1. A popup (HTTP realm) authentication window is shown to the user
  2. He hit enter with invalid credentials (i.e. empty username/password)
  3. The browser is redirected to the standard html login form
By using 'remember me' the NTLM authentication won't be shown next time the user access the site due to the presence of the cookie.

If the user client is Internet Explorer no authentication window is shown because the navigator use directly the information of the logged user. If the authentication fail, then the standard html login form is displayed letting him login with other credentials.

This implementation was made using Spring Security 2.0.5, but can be easly converted to Spring Security 3.0 using the Spring Security NTLM 3 module I recently created. Don't hesitate to ask me if you want that I publish an updated version.

You can download a sample application including hacked class here: