Latest blog posts

The main goal of this release is to make BeanConverter more intelligent. Previously, it required you to have the same type for the corresponding fields in a bean and a product. If there are Java number classes in your beans, it’s possible you don’t want to use it in your Scala code. Instead, you would like to use Options, or you may know that these values are never null.

Now BeanConverter can do these kinds of transformations for you.

JavaTypeMapper type class was introduced to acheive that. It provides two-way conversions for the following cases:

Java number class to Scala type. E.g. Integer to Int, or java.math.BigDecimal to scala.math.BigDecimal. If Java value is null it throws NullPointerException.

A class T to an Option[T]. Wraps nullable to Option.

A class T for which an instance of JavaTypeMapper to class U is available to an Option[U]. For example it is used to convert Integer to Option[Int].

HList of the elements which can be mapped with JavaTypeMappers, to HList of mapped values.

If you want to have a previous behavior from BeanConverter use StrictBeanConverter class.

As a Scala developer I prefer to use Scala libraries rather than Java ones for my code. However, it is not always possible. Sometimes I might not find a required library, or I just have to use some legacy code I already have. Even though Scala runs on a JVM and is fully compatible with Java, the languages have different ideologies, different code styles and sometimes different API’s. Thus, in Scala it is preferable to use immutable case classes for the data modeling. However, in Java the common building blocks are JavaBeans, which are mutable. Another problem is that a lot of Scala libraries expect case classes. Even if they work with JavaBeans, usually you have to write some boilerplate code.

So, quite often it is easier to have a separate model in your Scala code, and converters between Java model classes and Scala ones.

BeanPurée is a library that helps you to automate this process. And it helps you to do even more, because it’s a bridge from JavaBeans to shapeless.

In the previousposts we created the SqlSaver class which can set values into the prepared statement. It assumes that the SQL request is correct and the parameters are in the required order (in the order they are defined in the model). What if the model class is changed? If the query is not updated we’ll get a runtime error, since the fields order in the query and the order of calls performed by SqlSaver are not the same anymore. So, it would be nice to generate SQL queries as well. Something like:

If you are XMonad and Firefox ESR user, just like me, you might know that there is a problem with full screen videos playback. A video hangs and you cannot close it. All you can do is just to kill Firefox. It’s already fixed in the main line, but it looks like they don’t want to port the patch to ESR version.

Fortunately the patch is not too big and I adopted it for the ESR version. Here is it:

Yesterday I realized that there are more than ten posts in my blog. Not so many for more than a year, but quite a lot for the index page. The simplest solution is to just limit amount of posts with take function, and write something like “more posts in the archives”. But I prefer to have pagination for the index page. Hakyll has built-in support for pagination in the module Hakyll.Web.Paginate. There is a very nice manual about how to use it in this blog post.

Unfortunately, Paginate provides only first/previous/current/next/last functionality. It’s quite common to have only “Older posts” and “Newer posts” buttons for blogs, but I’d like to have a list of all pages in the Bootstrap pagination component. So, it’s time to write some Haskell code (of course you need to write code to add the standard Paginate, but I’m going to write a little bit more).

Sooner or later, every Scala programmer tries to study shapeless, Scalaz, Cats and other libraries, which are not designed to solve one small problem, but were created to explode your brain change the way you are writing your code, make it safer and at the same time more generic. I’ve tried to study shapeless several times, but the main problem is that there are no entry point. There are a lot of things and all of them are quite difficult.

Finally I decided to solve some small problems with shapeless to find some patterns and scenarios of how to use it. So, what kind of problems can I use? Shapeless is really useful when you want to process your data in a type safe generic way.

The problem I’d like to solve in this post is type safe saving arbitrary case class into an SQL statement. E.g:

Converting Scala collections to Java and backward

It’s quite often that we need to use a Java API from Scala. And these usages occurs even more often when you have modules written in Java in your Scala project. The most common problem is to pass Java collections to Scala API and Scala collections to Java. Fortunately, Scala library provides bidirectional implicit converters between Scala and Java collections. There are two classes JavaConverters and JavaConversions which provide the same functionality but in a different way.