tag:blogger.com,1999:blog-89825098367068334172024-02-02T10:50:13.386+01:00Chris Wewerka's BlogBlog of Chris Wewerka from <a href="http://chris-wewerka.de">chris-wewerka.de</a>Anonymoushttp://www.blogger.com/profile/18421656826760002588noreply@blogger.comBlogger7125tag:blogger.com,1999:blog-8982509836706833417.post-60082276075936441162014-08-28T00:16:00.000+02:002014-08-28T10:28:55.327+02:00Five reasons why you should use Scala on Android<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgKo2BJ_5qr9jXpa0qehlMkOYdmz6fiQCEIWDhcZzt5iRmm39F-WMyk7BqV6AUfBLv7T8jasQPiVF6UkFILLDNp63yWCzpItuifKT8VTrs-WpAyPaIMPg8UScqkJvGeEmCNq_jVNFt9CikE/s1600/Screenshot+from+2014-08-27+22:30:52.png" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgKo2BJ_5qr9jXpa0qehlMkOYdmz6fiQCEIWDhcZzt5iRmm39F-WMyk7BqV6AUfBLv7T8jasQPiVF6UkFILLDNp63yWCzpItuifKT8VTrs-WpAyPaIMPg8UScqkJvGeEmCNq_jVNFt9CikE/s1600/Screenshot+from+2014-08-27+22:30:52.png" height="93" width="320" /></a></div>
<a href="http://threedimensionsblog.blogspot.de/2014/08/scala-on-android-motivation-building.html">Last week</a> I've introduced the basic building blocks of a Scala Android App and talked only very short about the motivation. This time I will give you five catchy reasons why you should not go mainstream and use plain old boring Java but give Scala a favour on Android. <br />
<div class="separator" style="clear: both; text-align: center;">
</div>
<br />
<br />
<h2>
1. Escape the callback hell with Future's</h2>
On Android you have to spin off a thread for everything that needs some time until it's finished. You can't do this on the main thread, because then you would block the responsiveness of your app. This work could be e.g. a call to a REST server to fetch or post some data.<br />
<a href="http://developer.android.com/reference/android/os/AsyncTask.html">AsyncTask</a> from the Android library helps Android Java developers with this problem. But it uses callbacks as soon as the task completes. This doesn't sound so bad if you only do one thing, but just think about dependent async calls: First fetch user data, then fetch the avatar whose link has been contained in the returned user data. Now you have to nest callback handlers which really leads to ugly code. If you're not convinced read <a href="http://elm-lang.org/learn/Escape-from-Callback-Hell.elm">"Callbacks are the modern gotos"</a>.<br />
<br />
Fortunately functional languages like Scala have a very nice solution for this problem and they are called <a href="http://en.wikipedia.org/wiki/Monad_%28functional_programming%29">Monad</a>'s. In our concrete case of async execution the Monad to use is <a href="http://www.scala-lang.org/api/current/index.html#scala.concurrent.Future">Future</a>. You just have to return a Future of your return type instead of returning it directly. The nice thing is now that you can combine Future's very easily using a for comprehension:<br />
<script src="https://gist.github.com/breadfan/92974f9aefa801b0810a.js"></script>
With that mechanism you may combine several inter dependent async calls and they nearly look as simple as synchronous code.<br />
<br />
<h2>
2. Use concise functions instead of verbose anonymous listener classes</h2>
Android's UI code makes heavy use of the Listener concept like several other Java based UI frameworks like Swing. Every java developer knows the extreme amount of boilerplate code that is needed to write an anonymous listener class:<br />
<script src="https://gist.github.com/breadfan/321a932a750213e5cdbd.js"></script>
(Yes I know, this is already Scala, but it still uses the standard android listener)
<br />
<br />
You may now simply define a function that wraps the ugly listener concept or simply use <a href="https://github.com/pocorall/scaloid">Scaloid</a> which already supplies you with one:
<br />
<script src="https://gist.github.com/breadfan/3c9a7a4a25f8222c802b.js"></script>
If you prefer not to use Scaloid you just have to use the <a href="http://www.artima.com/weblogs/viewpost.jsp?thread=179766">"Pimp my library" Pattern of Scala</a> and enrich every Android View with a method that accepts an "on click" handler function:
<br />
<script src="https://gist.github.com/breadfan/6fd1a1109f1e3d946231.js"></script>
Now you simply import the implicit class and you may use e.g. button.onClick() like shown above.
<br />
<br />
<h2>3. Concise Scala code vs verbose Java boilerplate</h2>
Java is still ultra verbose and you as a developer need powerful IDE's to generate hundreds of boring code lines like this:<br />
<script src="https://gist.github.com/breadfan/46fe58e8f865d4951521.js"></script>
In Scala the above is simply done with:<br />
<script src="https://gist.github.com/breadfan/a703a8dfbaae1c4dedc1.js"></script>
Case classes generate everything for you: equals, hashCode, getter's, toString. No setter's since Scala case classes teach you to favour immutability. But Case class have clever <a href="http://stackoverflow.com/questions/7249396/how-to-clone-a-case-class-instance-and-change-just-one-field-in-scala">copy methods</a> if you need to create an altered version of an object.<br />
<br />
<h2>4. Use compile time checked dependency injection with the cake pattern</h2>
You don't need Spring's Dependency Injection facilities or Guice with Scala. You'll have something more powerful without the need to use an external library. Just learn and use the <a href="http://jonasboner.com/2008/10/06/real-world-scala-dependency-injection-di/">Cake pattern</a> and you are able to use Dependency injection in your Android code. And the best: It's statically checked by the compiler and not at runtime like in Spring or Guice. <br />
<br />
<h2>5. Get rid of if-cascades with Pattern matching</h2>
Checking conditions of an object in Java often leads to several if-cascades. And if you also want to extract some data out of the object you'll have to write a lot of code. Scala has it's swiss army knife for that: Pattern Matching. Here's an example:<br />
<script src="https://gist.github.com/breadfan/9e4d644ab1404eb188b2.js"></script>
<br />
With pattern matching you have the possibility to decompose an object into it's parts.<br />
Case classes already provide automatic support for pattern matching, but you may use pattern matching even for java classes or classes for which you don't have the source code by using <a href="http://danielwestheide.com/blog/2012/11/21/the-neophytes-guide-to-scala-part-1-extractors.html">Scala's extractor's</a>.Anonymoushttp://www.blogger.com/profile/18421656826760002588noreply@blogger.com0tag:blogger.com,1999:blog-8982509836706833417.post-16470370528436356402014-08-17T23:22:00.000+02:002014-08-28T00:21:27.399+02:00Scala on Android: Motivation, Building and useful libraries<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiwx5EMIOYPVugfXmY_qitWoKq8-p2ADVUfnSKK7o4g5jutCBpkIlqy8aM-lsDOVjHKxsxgg_qanaWFRPGIYITwZ7rg12UwqM_GjhBNyApyi5p70XkC4iEO7UyZH_jK0c-kV1NbblzTBJEU/s1600/via_della_scala.png" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiwx5EMIOYPVugfXmY_qitWoKq8-p2ADVUfnSKK7o4g5jutCBpkIlqy8aM-lsDOVjHKxsxgg_qanaWFRPGIYITwZ7rg12UwqM_GjhBNyApyi5p70XkC4iEO7UyZH_jK0c-kV1NbblzTBJEU/s1600/via_della_scala.png" height="286" width="320" /></a></div>
Today I'll start a Scala on Android blog series.<br />
<br />
This knowledge is mainly taken from the research and the work I've done for my current project. At the beginning there were big discussions if we should do plain old Java or use Scala for the app. Fortunately we decided together to go down the Scala road. See this <a href="http://erika23.gutefrage.net/2014/05/22/java-oder-scala-wie-man-sich-fur-eine-sprache-entscheidet/">Interview</a> for more insight on the decision (not very technical and in german)<br />
<br />
Here's the upcoming (it's Beta at the time of this writing) Play Store listing for the <a href="https://play.google.com/store/apps/details?id=net.gutefrage.android">App</a>.<br />
We develop this app with Scala 2.11 for Android 4.0.3 and above.<br />
<div class="separator" style="clear: both; text-align: center;">
</div>
<h2>
Main Motivation</h2>
Scala is a beautiful language. I come from Java land, and it was a real eye opener to work with Scala and learn day by day more of the beauty of functional programming. So I definitely wanted to write as much Scala code and as less Java code as possible, even on Android.<br />
<br />
But there's one really convincing feature in Scala that makes your life on Android so much easier and less painful: Futures instead of AsyncTask's Callback Handler approach.<br />
<br />
With callback handler's you'll get soon in a spaghetti code situation. If you use Scala Future's you may easily combine them with their combinators, for-comprehensions or the new <a href="https://github.com/scala/async">async/await</a> macros. Just write some code with both concepts and you will see the difference.<br />
<br />
For a more detailed view on the motivation, see my <a href="http://threedimensionsblog.blogspot.de/2014/08/five-reasons-why-you-should-use-scala.html">follow up post.</a><br />
<br />
I'll now start with the basic building blocks of the App.<br />
<br />
<h2>
Build system</h2>
One of the biggest questions when you start is: "Which build system should I use?" As I'm not a big fan of SBT I tried to look around and found one for my favourite build system gradle: <a href="https://github.com/saturday06/gradle-android-scala-plugin">gradle-android-scala-plugin</a>. But unfortunately the author doesn't recommend it to use it in production yet.<br />
<br />
So I tried out the <a href="https://github.com/pfn/android-sdk-plugin">Android SDK Plugin for SBT</a> and it turned out to be very well. It is actively developed, the author is very responsive and helpful, and the Intellij integration via the <a href="https://github.com/mpeltonen/sbt-idea">SBT-Idea </a>plugin is working well enough.<br />
<br />
<h3>
Scala and the Dexer limit</h3>
Compiled Java code for android is not shipped as .class files but in a format called dex. The problem is that currently one dex file allows only 65k method entries, and there are some big java android apps out there that already hit this limit. (e.g. <a href="https://www.facebook.com/notes/facebook-engineering/under-the-hood-dalvik-patch-for-facebook-for-android/10151345597798920">the facebook app</a>).<br />
<br />
So even if you have a normal sized app, if you write it in Scala the scala library itself will reach this limit. But every Android developer knows ProGuard: A tool which inspects java bytecode and removes unused code and optionally obfuscates it. <br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjQ6NGS4K0A3E5GXcRjVTuyJBTAmYUCCLnmQv70obAHVC_ltXfYcq1HRBsiSfaZF8XkokY66jgcxu6Czdxj50Bd8yXvIJqsgvfLNASuAPEdEoxn3NAiwUEmxDWJcYbwYsALnPOuzQu_VLvl/s1600/android_build.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjQ6NGS4K0A3E5GXcRjVTuyJBTAmYUCCLnmQv70obAHVC_ltXfYcq1HRBsiSfaZF8XkokY66jgcxu6Czdxj50Bd8yXvIJqsgvfLNASuAPEdEoxn3NAiwUEmxDWJcYbwYsALnPOuzQu_VLvl/s1600/android_build.png" height="219" width="640" /></a></div>
So if you use Scala for your app, using ProGuard is mandatory, even in the development stage, because it strips away a lot of the unused methods and fields from the Scala library.<br />
These tools are very well integrated in the Android SDK Plugin for SBT, where you also have the possibility to customize a Proguard cache to save a lot of time during your development build cycles.<br />
<br />
<h2>
Libraries</h2>
<h2>
</h2>
<h3>
REST client </h3>
As a rest client we use the Spring Android REST Template from <a href="http://projects.spring.io/spring-android/">Spring Android</a>. Not much to say here, it just works well. (In my Java days I was a big Spring fan.) We don't use the standard spring json parsing message converters. See next chapter.<br />
<br />
<h3>
Json Parsing</h3>
For my own (and first) Android app in Java I had used GSon for Json Parsing. It's very small and easy to use but unfortunately (and not surprisingly) it does not well support the Scala types we all love to use: Options, Lists etc.<br />
So my next evaluation was to use Jackson together with the Jackson Scala Module. At <a href="http://gutefrage.net/">Gutefrage.net</a> we use it on the Scala server side, but it showed up that it is very cumbersome to use on Android. The main reason is that it heavily relies on reflection and if you look at how Proguard works, you'll get a feeling why this will cause trouble. You'll have to add several "-keep" rules to tell Proguard not to remove code that Jackson needs later on to build up your object graph from json, and a lot of more stuff. I would not recommend it.<br />
So the final library in my journey was <a href="https://github.com/spray/spray-json">spray-json</a>. It is a native Scala library and you define your json mapping as an external protocol (in Scala).<br />
<br />
This has several advantages:<br />
<ul>
<li>No annotation and no reflection magic, all compile time, so no need to configure Proguard in any special way<br />Type-class based (de)serialization of custom objects (no reflection, no intrusion)</li>
<li>Annotations (e.g. used in Jackson) allow one representation, external protocol allows multiple</li>
<li>Define a protocol for classes w/o source</li>
<li>Simple and lightweight (Jar Size compared to Jackson)</li>
<li>Plugging in of fast low level parsers simple</li>
</ul>
As it turned out the standard json parser of spray-json isn't the fastest, but it's very easy to plug in a really fast one. We use <a href="https://github.com/non/jawn">Jawn</a>.<br />
<br />
<h3>
Libraries for making Android less painful</h3>
We use <a href="https://github.com/pocorall/scaloid">Scaloid</a>, it has several nice features e.g.<br />
<ul>
<li>turning the usual android callback handlers (e.g. onClickListener) into a functional equivalent</li>
<li>a Scala DSL for building and reusing layouts</li>
<li>a lot of Rich* classes for the Android functionality and implicit parameters reducing a lot of boilerplate code </li>
<li>and a lot more</li>
</ul>
At some early point of the app we decided however not to use the Scala DSL as an alternative for the android layout xml's, but Scaloid allows you to make your choice. <br />
<br />
Another UI DSL Library which might be worth to have a look at is <a href="https://github.com/macroid/macroid">Macroid</a>.<br />
<br />
<br />
The next upcoming post will talk about generalizing the error handling while talking to API servers.Anonymoushttp://www.blogger.com/profile/18421656826760002588noreply@blogger.com0tag:blogger.com,1999:blog-8982509836706833417.post-67722462603114527542014-07-04T09:08:00.000+02:002014-07-04T09:08:08.164+02:00Keep your clients simple with real REST and HATEOASThe last months we were moving some backend services from an old legacy architecture to a new scala based service architecture, already having an iPhone app that uses the old services.<br />
<br />
The legacy services exposed their API via HTTP and JSON in a format that has been copied from Facebook (and Google). For example look at the URL for getting questions with user information who created the questions:<br />
<br />
<span style="font-family: "Courier New",Courier,monospace;">/question?fields=question.title,user,user.nickname,....</span><br />
<br />
The facebook idea is highly flexible, no doubt. Allowing you to tailor down the response the exact way you want it. You get exactly what you want and you're able to build clients that use the API to get new relations without the need to change the server side.<br />
<br />
As we tried to re-write these services in Scala but staying backward compatible, we ran into the downsides of this approach:<br />
<br />
<h4>
Downside 1: Infinite number of URL query parameter variations</h4>
It was quite a hard job to find out which URL variations our current sole and own (!) client (iPhone App) uses from this API, because the above approach allowed so many possible variations of the URL. And sure, as we finally switched we broke the App because we've missed one call.<br />
<br />
<h4>
Downside 2: The client has to have explicit knowledge how to build URL's</h4>
The facebook approach builds an implicit contract between clients and the API for how to use the API. If the API URL format changes you'll now have to worry about supporting old clients using the old URL format.<br />
<br />
<h4>
Downside 3: Infinite number of response formats </h4>
The flexible URL format as proposed by Facebook leads to responses being as dynamic as the URL parameters, so it was hard to find out which sets of responses are used by the client and have to be re-implemented to keep backward compatibility.<br />
<br />
<h3>
Alternative solution</h3>
We're currently writing a brand new <a href="http://erika23.gutefrage.net/2014/05/22/java-oder-scala-wie-man-sich-fur-eine-sprache-entscheidet/">Android App in Scala for sure</a>, stay tuned for upcoming infos) and we don't want to go down the same error prone way as the months before. So for the new services (as a replacement for the old legacy one) we try to learn from the above problems.<br />
<br />
<h4>
Use fixed set of responses</h4>
We've introduced shapes for resources (like /users or /questions). These shapes are T-Shirt sizes: S, M, L, XL. The different shapes return you a different amount of associated data for your resource. For example M for a question would return a question with some inlined user information. We're thinking about allowing shapes for associated resources as well. E.g.<br />
<br />
<span style="font-family: "Courier New",Courier,monospace;">/questions?shape=M&user.shape=S</span><br />
<br />
(To be honest, I'm not really a fan of inlining associated resources (even with the above shape way) because it contradicts the REST principles, but we want to reduce the amount of requests for the mobile clients here.)<br />
<br />
With the introduction of shapes you have a reasonable amount of flexibility to customize the amount of data in your response and the query costs on the server side but you now have a stable set of response formats you have to support in the future.<br />
<br />
This shape idea adresses downside 1 and 3 from the above list, but what about clients having to know how to build URL's?<br />
<br />
<h4>
Use resource links</h4>
Our current task was to implement paging for a specific resource stream. Up to now the old and also the new services used an approach also inspired by Facebook (and a lot more):<br />
<br />
/questions?limit20&offset=100<br />
<br />
We encountered problems when paging here, because a lot of new questions are created every second, so using limit and offset is no fixed but a moving window and the paged responses are eventually including already returned questions in another page. With this approach the client has to filter the paged responses for already returned responses. This is a really heavy burden for a client as you can imagine.<br />
<br />
Also the client again has to know the logic how to build the paging URL as seen above. If you want to change that format in the future, you'll have big problems, because there are a lot of clients out there that use your old format. <br />
<br />
So we decided to move on to an alternate solution:<br />
<br />
We move the logic how to get the previous or next paged response from the client back to the server. The server as he returns paged responses now simply returns two resource links with the relation name 'previous' and 'next'. All the client has to do to get a new paged response before or after the current one is: Follow one of the links! This is just the same idea as a human uses the WWW. You don't worry about how the URL looks like on a page that you read, you just click the link and your browser follows...<br />
<br />
<script src="https://gist.github.com/breadfan/ef5f24a6503dd971e1a7.js"></script>
The benefits of using resource links here are:<br />
<br />
The server encodes the state for the paging inside the relation links, so this is what the <a href="http://en.wikipedia.org/wiki/HATEOAS">HATEOAS</a> (Hypermedia As The Enginge Of Application State) principle of REST is all about: The state for paging is now encoded in the returned links.<br />
<br />
Now that the state is inside the links you have more advantages:<br />
<ul>
<li>If you decide to use timestamps for paging instead of Id's (as above), you simply change it on the server side. You don't brake your clients because your clients just follow the links</li>
<li>The client doesn't anymore need to know how to build paging URL's, you can eliminate that logic from your client</li>
<li>As you can see we also changed to now use beforeId or afterId params together with limit to eliminate duplicates in different pages (which happened as we use the offset param). But as we moved the pagination links generation to the server, the client doesn't have to have the logic for finding the last or first id of a page to get a new one</li>
</ul>
<br />
<br />
<br />Anonymoushttp://www.blogger.com/profile/18421656826760002588noreply@blogger.com0tag:blogger.com,1999:blog-8982509836706833417.post-69786230570541179762014-01-03T17:05:00.000+01:002014-01-04T18:13:31.153+01:00Validation in Scala Part 1: The return type candidates<h3>
Introduction </h3>
In every project you need validation of user input, scala projects are no exception. In Java some people use Bean Validation to annotate their objects and have them validated by a validator instance.<br />
So some months ago we also used Java Bean Validation in our Finagle based Scala project.<br />
Unfortunately this wasn't a good choice for our distributed service architecture. We're using several services to do validations and we had to wrap these calls in Futures and had to "await" them inside our custom BeanValidations which causes threads to be blocked. Not a very reactive way for today!<br />
<br />
Also the BeanValidation API is somehow not so nice to use, e.g. it forces you to annotate classes and we needed more flexibility than we expected, so to make a long story short: We moved away from it.<br />
<br />
Now I've tried to move to a more functional and flexible solution, inspired by excellent posts like <a href="http://blog.lunatech.com/2012/03/02/validation-scala">http://blog.lunatech.com/2012/03/02/validation-scala</a><br />
<br />
<h3>
What to use?</h3>
<h4>
Keep it simple, use simple validation methods</h4>
We're back using simple validation methods like<br />
<br />
<span style="font-family: "Courier New",Courier,monospace;"> <b> def validateUserRegistration(request: UserRegistration)</b></span><br />
<br />
So the interesting part here is the return type to be used for returning either a success or a failure(s). <br />
<br />
Here's my current choice list<br />
<ul>
<li>Option</li>
<li>\/ (Scalaz Either)</li>
<li>Validation (also from Scalaz)</li>
<li>ValidationNel (a specialized Validation)<br /> </li>
</ul>
We will now look into them in a little bit more detail.<br />
<br />
<h4>
Option</h4>
Option is the simplest solution, it may contain either a None (representing e.g. something like "NotFound) or a Some(x) for the Success case. You may be tempted to use a Some(error) and a None for expressing "No failure" but I always regard this a little bit of irritating. Later in the conversion section we'll see that I'm not alone with this.<br />
The nice thing is that Option is a Monad, you may use it in a for comprehensions like this:
<script src="https://gist.github.com/breadfan/8239567.js"></script>
<br />
You'll get either a Some if every step contains a Some or a None if any of the Options used in the for comprehensions are a None.
<br />
<h4>
</h4>
<h4>
<span style="font-family: "Courier New",Courier,monospace;">\/</span> (Scalaz's Either implementation)</h4>
As I already explained in another <a href="http://threedimensionsblog.blogspot.de/2013/09/using-futures-together-with-either-or.html">post</a>
we make use of Scalaz Either (written as \/ ), instead of the plain
Scala Either, because you can combine them with other Monads (like
Twitter futures) using Monad Transformers.<br />
<br />
Besides that an \/ instance is either a Left (per convention) the bad case or a Right (per convention) the good case.<br />
You create them like this:<br />
<script src="https://gist.github.com/breadfan/8239718.js"></script>
Little bit funny at first that with ".left" and ".right" you'll specify the other type (right type for a ".left", left type for a ".right"), but it makes sense because you have to help the compiler with the non-present type, doesn't it?<br />
<br />
<h4>
Validation </h4>
Validation is pretty much like EitherZ but Success and Failure is not a convention any more but is expressed in the subtypes: Failure and Success.<br />
Here's an example creating them:
<script src="https://gist.github.com/breadfan/8239836.js"></script>
<br />
<h4>
ValidationNel </h4>
"Nel" stands for NonEmptyList, as the scaladoc says: A singly-linked list that is guaranteed to be non-empty. Why is this important?<br />
Imagine the following:<br />
<br />
<span style="font-family: "Courier New",Courier,monospace;"> <b>def registerUser(name: String,...): Validation[List[RegisterUserFailures], User]</b></span><br />
<br />
The returned “List” of failures may be possibly empty with this signature. This is irritating, because what does this mean?
So Scalaz helps us with a simple but nice trick:
<br />
<script src="https://gist.github.com/breadfan/8240006.js"></script>
<br />
<br />
<h4>
Conversions between the above types</h4>
The nice thing that you may choose whatever best fitting type of the above for you validation method. If you later on compose several validation methods which use different return types of the above you may easily convert between them and use the best fitting type in your aggregation method: <br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiVTqdBw7cBfzDsNkh3fYogSUSRznSHYyKhmilAvcUrtMCcW-3WE7CTiT5PrEsunrdUCWtwYdj3sOJyeqKeJDrPL1T00LRglWk2IUpP_DaqwwbDBe7LTZsOcCderp37C6xShrs9faudvZ38/s1600/conversions.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="360" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiVTqdBw7cBfzDsNkh3fYogSUSRznSHYyKhmilAvcUrtMCcW-3WE7CTiT5PrEsunrdUCWtwYdj3sOJyeqKeJDrPL1T00LRglWk2IUpP_DaqwwbDBe7LTZsOcCderp37C6xShrs9faudvZ38/s640/conversions.png" width="640" /></a></div>
<br />
The "fold" from Option to \/ is one of several ways to "enrich" the missing Left information in an Option. If you go back from \/ to Option with "toOption" the Left information from a -\/ is simply dropped and "mapped" to a None. So like I said above: "None" of an Option is usually considered an error case (without detailed information). The toOption method of \/ has the same viewpoint here.<br />
<br />
In Part 2 of this blog we'll have a look at fail-fast strategy for validation or aggregating several validation failures.Anonymoushttp://www.blogger.com/profile/18421656826760002588noreply@blogger.com0tag:blogger.com,1999:blog-8982509836706833417.post-3332418314419819222013-11-13T17:05:00.001+01:002013-11-13T17:05:27.566+01:00Using Functors or How to use implicit conversions inside containersSince I work with Scala in my current project, using implicit conversions is quite nice to do the usual mapping stuff 'behind the scenes', for example to map between the external representation of a time value (in thrift) and the internal one using Joda DateTime<br />
<br />
<script src="https://gist.github.com/breadfan/7450825.js"></script>
Using this just requires it to bring it in scope, e.g. with an import:
<br /><br/>
<script src="https://gist.github.com/breadfan/7450881.js"></script>
Some weeks ago a colleague asked me why the Scala compiler is so stupid not to apply a implicit conversion in the following case:<br />
<br/>
<script src="https://gist.github.com/breadfan/7450933.js"></script>
But how should the compiler now how to convert an Option[JodaDateTime] to Option[ThriftDateTime]? Yes, there is a map() method in Option, but this is just some kind of usual convention, and it would be really dangerous if the scala compiler would automatically use a method map() if present.<br />
<br />
At this time I just suggested to explicitly map or use an implicit conversion on Option:
<br />
<script src="https://gist.github.com/breadfan/7451074.js"></script>
But this is really cumbersome and you have to do it also for lists or any other container type, even if they all have a common map method with the same semantic.<br />
<br />
<h3>
Functors</h3>
It turns out that there is a functional class which describes the above situation, they are called functors.<br />
A functor is simply a trait which specifies to supply a map() method with adheres to the functor laws.<br /><br/>
<script src="https://gist.github.com/breadfan/7451240.js"></script>
The above functor definition is directly taken from Scalaz 7.
<br />
Using it for an implicit "container" conversion of our two classes means:
<br/><br/>
<script src="https://gist.github.com/breadfan/7451382.js"></script>
<br/>
With that the conversions work in all "containers" for which scalaz defines functors:
<br/><br/>
<script src="https://gist.github.com/breadfan/7451466.js"></script>
..and if you want you can write your own functors for your classes.
Anonymoushttp://www.blogger.com/profile/18421656826760002588noreply@blogger.com0tag:blogger.com,1999:blog-8982509836706833417.post-73282983155028775122013-09-27T17:47:00.000+02:002013-09-27T17:48:19.226+02:00Using Futures together with Either or My way to scalaz<h3>
Intro</h3>
We're using Twitter's Finagle stack in my current scala project. Finagle is <a href="http://twitter.github.io/scala_school/finagle.html">Future</a> based and the Future concept makes usage of exceptions easy.
Using Exceptions for "infrastructural" problems (like when the network or the database is down) is perfectly ok, in Java you would use RuntimeExceptions for this which don't have to show up in the method signature. In Scala there's no difference any more between checked exceptions and runtime exceptions.
In Java checked exceptions are often used for "business" exceptions, i.e. exceptions that steer the way your business logic works. For example, some months ago in Java projects I've often written API methods like this:<br />
<script src="https://gist.github.com/breadfan/6726694.js"></script>
<br />
So the possible return types of this method is either a <span style="font-family: "Courier New",Courier,monospace;">ArticleDetails</span> object containing the information about the article or an Exception saying that the article could not be found.<br />
<h4>
Pros</h4>
<ul>
<li>Method signature tells you everything about the return types</li>
</ul>
<h4>
Cons</h4>
<ul>
<li>Two different ways of returning information</li>
<ul>
<li><span style="font-family: "Courier New",Courier,monospace;">return new ArticleDetails(...)</span></li>
<li><span style="font-family: "Courier New",Courier,monospace;">throw new ArticleNotFoundException(...) </span></li>
</ul>
<li><span style="font-family: "Courier New",Courier,monospace;"><span style="font-family: Arial,Helvetica,sans-serif;">This also means two different styles of handling this information at the caller side</span></span></li>
</ul>
<br />
<ul>
</ul>
<h3>
Scala</h3>
In Scala there are no checked exceptions any more, so migrating the above java interface to Scala and still use an exception for the failure case would result in the following:
<script src="https://gist.github.com/breadfan/6727147.js"></script><br />
The method signature doesn't tell you anymore that the method could produce a separate exception output. You could use scaladoc or <span style="font-family: "Courier New",Courier,monospace;">@throws</span> to document this, but the compiler doesn't check this and this probably leads (after some evolution cycles of your class) to a method signature that doesn't document anymore what it is returning in case of expected business flow failures.<br />
<br />
<h3>
Either to the rescue</h3>
In Scala there's a more functional way to say what the method is returning: <a href="http://www.scala-lang.org/api/current/#scala.util.Either">Either</a><br />
<script src="https://gist.github.com/breadfan/6727342.js"></script>
<br />
The above method either returns an ArticleNotFound or an ArticleDetails object.<br />
An Either has a left side, which is used per convention for the failure case or a right side, which represents the "right", the success case.<br />
<br />
<h3>
Using Futures </h3>
As I said we're using Twitter Futures for our code, so if we're doing some blocking method call, we do it async and return a <span style="font-family: "Courier New",Courier,monospace;">Future[RETURN_OBJECT]</span> instead of the simple method return object to keep the current thread from being blocked. So the above method blocks because of a call to MySQL and would therefore look like this: <br />
<script src="https://gist.github.com/breadfan/6727466.js"></script>
<br />
<h3>
For Comprehensions</h3>
So far everything looks good, and it seems pretty easy to get away from business exceptions. But imagine now a second method which returns an articleId for an unique article name:<br />
<br />
<script src="https://gist.github.com/breadfan/6729852.js"></script> If someone has only the unique name and wants to retrieve the article details I would naively use the following for comprehension and would expect Left's (Failures) to fail fast and "bubble" out of the for comprehension:<br />
<br />
<script src="https://gist.github.com/breadfan/6729942.js"></script>
Unfortunately the above doesn't compile. What we need is a way to compose the Future with Either. At this point I was very lost and asked for help in this <a href="http://stackoverflow.com/questions/18828067/combining-futures-twitter-and-either-in-scala">stackoverflow question</a>. Fortunately the help came at the <a href="http://www.meetup.com/ScalaMuc/">Scala User Group Munich</a> where Lars Hupel helped me a lot with this.<br />
<br />
<h3>
Monad Transformers or "My way to scalaz"</h3>
The way out of this problem is a Monad transformer. A simple mental model for a Monad in Scala is a class which implements map, flatMap and withFilter and can therefore be used in a for comprehension.<br />
Either and Futures are Monads and Monads don't compose out of the box together. There's even not a guarentee that mondas can be <a href="http://precog.com/blog/Precog-Copointed-Monad-Transformers/">combined</a>. <br />
<br />
My first problem was now that scala.util.Either is not even a Monad. Only it's right or left protection is a Monad! Which makes it a little bit <a href="http://danielwestheide.com/blog/2013/01/02/the-neophytes-guide-to-scala-part-7-the-either-type.html">cumbersome to use</a>. You'll have to say always <span style="font-family: "Courier New",Courier,monospace;">.right</span> in for comprehensions.<br />
<br />
As I found out that scalaz has also an Either called<span style="font-family: "Courier New",Courier,monospace;"> \/ </span>which is right biased and not neutral like <span style="font-family: "Courier New",Courier,monospace;">scala.util.Either</span>. The best: It has a transformer class <span style="font-family: "Courier New",Courier,monospace;">EitherT</span> to combine it with other Monads.<br />
<br />
Converting the above example to \/ leads us to:<br />
<br />
<script src="https://gist.github.com/breadfan/6730290.js"></script>
Pretty similar to the solution with Scala's Either, but without <span style="font-family: "Courier New",Courier,monospace;">.right</span>'s, because of it's right biasing like in Haskell.
To use EitherT with Twitter Futures we now only need to define the following implicit vals:
<br />
<script src="https://gist.github.com/breadfan/6730323.js"></script>
<br />
Then we can use EitherT together with Twitter Futures in our for comprehension:
<br />
<script src="https://gist.github.com/breadfan/6730573.js"></script>
The run method turns the resulting <span style="font-family: "Courier New",Courier,monospace;">EitherT</span> back to a<span style="font-family: "Courier New",Courier,monospace;"> Future[\/]</span>. A <span style="font-family: "Courier New",Courier,monospace;">EitherT</span> in this case is an <span style="font-family: "Courier New",Courier,monospace;">EitherT[Future, ArticleNotFound.type, ArticleDetails]</span>, so this could be used as alternate return type. Then you can omit the <span style="font-family: "Courier New",Courier,monospace;">run</span> call.<br />
<br />
Here's the final complete example:<br />
<br />
<script src="https://gist.github.com/breadfan/6730677.js"></script>
If a left happens on one of the calls in the for comprehension, it bubbles out in fail fast strategy. If there are only Right's than the article is yielded.Anonymoushttp://www.blogger.com/profile/18421656826760002588noreply@blogger.com0tag:blogger.com,1999:blog-8982509836706833417.post-20959742773664179732013-09-13T09:38:00.000+02:002013-09-27T09:42:09.118+02:00Slick in Scala: Combining multiple fields in one mapping case class fieldYesterday I've had a problem with an existing database schema. In one table there were several Boolean columns each expressing the existence of an user role.<br />
<br />
Since we use <a href="http://slick.typesafe.com/">Slick</a> for MySQL access in our services, I wanted to combine these several columns in one single (enumeration) field of the mapping case class:<br />
<script src="https://gist.github.com/anonymous/6725306.js"></script>
This can be achieved by providing your own constructor and extractor functions for User objects
to Slick using the <> function on the * projection. Something like
this:<br />
<script src="https://gist.github.com/anonymous/6725330.js"></script>
Be sure that your own constructor and extractor functions have the apply/unapply style, e.g. extractUser should return an Option of a tuple, if it does not (extractUser returns a tuple instead of an option of a tuple) you get a hard-to-read error message from the compiler:<br />
<blockquote class="tr_bq">
<span style="font-family: "Courier New",Courier,monospace;">overloaded method value <> with alternatives:<br /> [R(in method <>)...<br /> userModeratorMajor ~ partner ~ premiumPartner ~ corporatePaid <> (constructUser _, extractUser _)</span></blockquote>
Thanks Mr. Vogt from Typesafe for the <a href="http://stackoverflow.com/questions/18572084/how-to-combine-multiple-columns-in-one-case-class-field-when-using-lifted-embedd">hint</a>. <br />
<br />
Anonymoushttp://www.blogger.com/profile/18421656826760002588noreply@blogger.com0