Recently I’ve started using an awesome library - scalacache. It is a functional facade for an underlying cache library of your choice. That way you can fully harness the power of Scala while caching your data. It works great both if you need to cache something manually and if all you need is method call memoization.

My personal case was a tad more complicated, though. What I needed to do was to cache authentication tokens with a time to live (TTL) corresponding to the token’s expiration time. Unfortunately, scalacache API forces you to define the TTL upfront. Fear not, for this is a highly extensible library. It let me define a generic method to do just that, and yet still allowed for flexibility provided by its modes.

1
2
3
4
5
6
7
8
9
10
11
12

def cachingWithTTL[T, M[_]](keyParts: Any*)(value: => M[(T, Duration)])
                           (implicit cache: Cache[T], mode: Mode[M], flags: Flags): M[T] = {
    import mode._
    M.flatMap(get(keyParts:_*)) {
      case Some(found) => M.pure(found)
      case None =>
        M.flatMap(value) {
          case (v, ttl) =>
            M.map(put(keyParts:_*)(v, Some(ttl)))(_ => v)
        }
    }
  }

In the previous post I’ve shown you how to integrate front-end part of our application with Keycloak as a Single Sign-on server. That is really important, but almost no real application can work without a back-end. That’s why today we’ll delve into the problem of authorizing requests in the server application. If we’re using an application container this job will probably be much easier. Keycloak provides some out of the box adapters for most mainstream servers, so the only thing you have to do is to download them and add a little bit of configuration. That’s a piece of cake. That’s why we’ll look into something different: adding OAuth2 and in particular Keycloak support for Akka HTTP.

Basically every application needs some kind of authorization mechanism. That’s obvious. If we have some container at our disposal which serves HTML for every requested website, we can probably just enrich it with some library, change some XMLs and we’re basically done. Unfortunately that’s not the case with single page applications. Yes, we can still have a container, that will handle things on the backend (which we won’t in this tutorial, but let’s not jump to it yet), but there’s no such magic wand for the frontend. There are some libraries, that will help you in some particular cases, but when I was looking at the authorization needed for my current project, none of them were good enough, and I didn’t want to configure some big library just to do something that can be done in less then 50 lines of code. With that in mind, let me take you on a short journey of implementing SSO for the front-end written in AngularJS with the help of great SSO server called Keycloak.

In one of my last posts I wrote about the cost of garbage collection. Inspired by the talk of Nikita Salnikov-Tarnovski at Warsaw JUG titled Heap, off you go I’ve decided to compare C++ and Java performance based on the code written by Nikita and my C++ port. In the second and last part of the series on performance, I will tackle the issue of highly optimized code.

Java code for this blog post uses almost no garbage collection due to the use of the Unsafe class which helped to allocate memory off the heap without the use of type and boundary checking. C++ code also uses native-allocated buffer of bytes to store all data. This is the clash of the titans. How much CPU time do we loose every day by choosing byte code over assembly code? Can JIT compiler make Java comparable to C++? Let’s find out!

Last Saturday I was a part of Scalar conference in Warsaw. Softwaremill, the main organizer of the event, prepared a really cool contest - everybody at the conference got a piece of paper with a code printed on it. There were three different pieces of code, so you had to find two other people with different pieces (socialization, yay!). When you did it, they gave you the fourth, remaining piece of code. The task was to find a mistake in a code. Here is the original code:

1
2
3
4
5
6
7
8
9
10
11
12

object ScalarPuzzle extends App {

  implicit class TernaryOps(cond: => Boolean) {
    def ??(thenBlock: => Unit) = new {
      def ::(elseBlock: => Unit): Unit =
        if(cond) thenBlock else elseBlock
    }
  }

  (1 + 1 == 2) ?? println("True") :: println("False")

}

Have you ever wondered what is the cost that you’re paying when using a garbage collector for cleaning up your mess? How less performant will your app be, if you choose to let virtual machine manage the memory? This month I’ve attended a presentation at Warsaw JUG by Nikita Salnikov-Tarnovski titled Heap, off you go which touched the issue of Java code optimization in the context of excessive garbage collection. The talk showed how garbage collector can “collect” almost 100% of your application execution time. That’s a big deal. Although the example used during the talk was quite specific - allocating 50M objects and then iterating over them - it still makes you think. What inspired me the most, was one of the questions from the audience, that the speaker didn’t know the answer to:

How does it compare to C++?

This blog post is the first of two-part summary of what I’ve learned during my journey through the benchmark land. Here I’ll touch the differences between C++ and Java in case of heap allocation using new operator. The next part, that I’ll publish somewhere next week, will touch the issue of optimized code performance.

This is a response to the article I’ve read this morning: Why Scala? by @clintmiller1

TL;DR version

I’ve created this blog some time ago, but couldn’t find a topic good enough for a first post, plus my free time is very limited right now. When I’ve read Why Scala? I knew, that I have to respond. It’s not like I don’t like Scala. I think it’s an awesome language with a huge potential. It could even be The next big thing. This post is not about how Scala sucks, because it doesn’t. It’s about a dishonest comparison.

Two thing that irritated me the most while reading Clint’s article were:

• Disservice made to Java by ignoring good practices like switching from nulls to Optional (either from Guava or better from Java 8) or Null objects and ignoring the advantages of good language verbosity,
• Ignoring the subject of source code maintainability which is kinda crucial to the applications that are going to be used and changed for more than just few months.