Finished blogpost on Future Trys

Author: dlouwers

_config.yml

@@ -1,6 +1,6 @@
 # Site settings
 title: Stormlantern Blog
-email: dirk,[email protected]
+email: dirk.[email protected]
 description: >
   Blogging home for Dirk Louwers
 baseurl: "" # the subpath of your site, e.g. /blog/

_drafts/usage-of-future-try.markdown

@@ -0,0 +1,30 @@
+---
+layout: post
+title: Musings on setting up a nice web application structure using Spray and ScalaJS
+date: '2014-07-15T14:33:00.002-07:00'
+author: Dirk Louwers
+tags:
+- spray
+- sbt
+- scalajs
+- scala
+modified_time: '2014-07-16T02:17:02.238-07:00'
+blogger_id: tag:blogger.com,1999:blog-1529483519632285628.post-2473681211825466512
+blogger_orig_url: http://dogtyped.blogspot.com/2014/07/musings-on-setting-up-nice-web.html
+---
+Today I have been experimenting with setting up a nice project structure for web
+applications using Spray and ScalaJS. First I considered the simplest option of
+combining them in a single SBT project but this seems to be a bad idea. ScalaJS
+generates class files and a jar. Mixing this with Scala backend code would
+result in a bloated jar full of unused code.
+
+So the next step is using two  sub projects inside of SBT. One for the frontend
+and one for the backend. However, in itself this is not enough. I would like my
+html to reside in the frontend resources. The Javascript will be generated in
+this project by fullOptJS and fastOptJS and end up in the project's target
+directory. I'd like the generated Javascript and mapping files to be available
+in resources. The backend project should have these resources available but NOT
+the classes.
+
+Next up I will be trying to see if this can be accomplished or if there is a
+better way to go about this.

_posts/2014-07-15-musings-on-setting-up-nice-web.html

@@ -1,24 +1,24 @@
 ---
 layout: post
-title: Peace of mind in a state of overload
+title: Try is free in the Future
 date: '2015-01-18T18:21:00.000+02:00'
 author: Dirk Louwers
 tags:
 - scala
 modified_time: '2015-01-18T18:21:00.000+02:00'
 ---
-# Try is free in the Future
 Lately I have seen a few developers consistently use a Try inside of a Future in
 order to make error handling easier. Here I will investigate if this has any
 merits or whether a Future on it's own offers enough error handle.
 
-If you look at the following code there is nothing that a `Future` can't supply
-but a `Try` can.
+If you look at the following code there is nothing that a Future can't supply
+but a Try can:
 
 {% highlight scala %}
 import scala.concurrent.ExecutionContext.Implicits.global
-import scala.concurrent.{Await, Future}
+import scala.concurrent.{Await, Future, Awaitable}
 import scala.concurrent.duration._
+import scala.util.{Try, Success, Failure}
 
 object Main extends App {
 
@@ -33,36 +33,43 @@ object Main extends App {
   }
 
   // We would want to wrap the result into a hypothetical http response
-  case class Response(code: Int, body: Array[Byte])
-
-  object Response {
-    def fromInt(int: Int): Response = {
-      val buffer = java.nio.ByteBuffer.allocate(4)
-      buffer.putInt(int)
-      Response(200, buffer.array())
-    }
-  }
+  case class Response(code: Int, body: String)
 
   // This is the handler we will use
   def handle[T](future: Future[T]): Future[Response] = {
     future.map {
-      case answer: Int => Response.fromInt(answer)
+      case answer: Int => Response(200, answer.toString)
     } recover {
-      case t: Throwable => Response(500, Array.empty[Byte])
+      case t: Throwable => Response(500, "Uh oh!")
     }
   }
 
   {
     val result = Await.result(handle(happyFuture), 1 second)
-    assert(result.code == 200)
-    val buffer = java.nio.ByteBuffer.wrap(result.body)
-    assert(buffer.getInt == 42)
+    println(result)
   }
 
   {
     val result = Await.result(handle(bleakFuture), 1 second)
-    assert(result.code == 500)
+    println(result)
   }
 }
+{% endhighlight %}
+
+After giving it some thought the only situation where I could imagine Try
+being useful in conjunction with Future is when awaiting a Future but not wanting
+to deal with error situations yet. The times I would be awaiting a future are
+very few in practice though. But when needed something like this migth do:
 
+{% highlight scala %}
+object TryAwait {
+  def ready[T](awaitable: Awaitable[T], atMost: Duration): Try[T] = {
+    Try {
+      Await.result(awaitable, atMost)
+    }
+  }
+}
 {% endhighlight %}
+
+If you do feel that using Trys inside of Futures adds value to your codebase
+please let me know.

_posts/2014-07-15-musings-on-setting-up-nice-web.markdown

@@ -4,8 +4,5 @@ title: About
 permalink: /about/
 ---
 
-This is the base Jekyll theme. You can find out more info about customizing your Jekyll theme, as well as basic Jekyll usage documentation at [jekyllrb.com](http://jekyllrb.com/)
-
-You can find the source code for the Jekyll new theme at: [github.com/jglovier/jekyll-new](https://github.com/jglovier/jekyll-new)
-
-You can find the source code for Jekyll at [github.com/jekyll/jekyll](https://github.com/jekyll/jekyll)
+This is my blog. My name is Dirk Louwers. I will write about anything that
+piques my interest. 

_posts/2015-01-18-usage-of-future-try.markdown

@@ -14,6 +14,9 @@ <h1 class="page-heading">Posts</h1>
         <h2>
           <a class="post-link" href="{{ post.url | prepend: site.baseurl }}">{{ post.title }}</a>
         </h2>
+        <p>
+          {{ post.excerpt }}
+        </p>
       </li>
     {% endfor %}
   </ul>