aappddeevv

Working on data streaming (many problems can be cast as data streams) is hard. Controlling synchronous and asynchronous behaviors easily and simply requires frameworks and code that is often is uncommon to most programmers, and hence, its hard to write the code while still retaining simplicity.

Scalaz Streams (labelled sstreams in this article) help you manage complexity by providing a few fundamental abstractions. But I found the abstractions hard to use at first because I was not use to thinking in a model that sstreams uses.

sstreams casts the problem as a state machine. There are 3 states and a "driver" that iterates through the states. Each state carries with it enough information to move to the next state. Each state is a "one step process" and so all states derive from the Process trait.

The level of abstraction is pretty high which means that the framework should be able to applied to a highly diverse set of issues. I have used spring integration. I found that framework hard to use as well because

aappddeevv

Web Application Workflow and Toolchains

Creating a front-end client application based on html5 technology will require a few toolchains working together to develop, assemble and deploy the application. Each part of the toolchain will perform a fairly small function. Each layer is decoupled from each other so you can swap out your own toolchain or augment it as needed. Standards are still evolving around html5 client application toolchains and workflow.

Since scalajs is a new technology, take a web-app first style approach to the build environment using toolchains that evolved with the html5 development technologies versus a java or jvm centric approach. The following tools are fairly standard although others exist:

• bower: Management js dependencies
• grunt: A very simple task runner. Most of what grunt does could be performed by sbt if sbt had a set of plugins that cover the same functionality. In some cases, you can decide whether to use a grunt task or a sbt task. *For example, you can use a grunt ta

aappddeevv

It is difficult to create a truly asynchronous http client. Generally, programmers will use an async client library like asynchttpclient to help them create their client. If the server requires authentication, it most likely has a method to avoid reauthentication using credentials because reauthentication with each request is costly. However, the presence of "state" like information in a stateless protocol introduces substantial complexity especially when the workload cannot be anticipated. A server may also create a reauthentication mechanism to help control the exposure of authentication credentials with each http request.

If authentication workload reduction methods are used by the server, they most likely require the use of state that must be maintained by the client, often sometype of time-limited token. If the token has time limits, it must be renewed periodically. A renewal request takes time and may introduce request failure because the renewal has not completed prior to other requests being issued.

aappddeevv

(* ::Package:: *)

(* :Title: Import Delimited *)

(* :Summary: Containts declarations for importing a delimited text file into a session. *)

BeginPackage["ImportUtilities`"]


(* Canned functions that can be used as arguments. *)

aappddeevv

package org.im
package output
package prettyprinter

import scala.language._

import java.io.Writer
import java.time._

/**

aappddeevv

package tutorial.webapp

import language._
import scala.scalajs.js
import scala.scalajs.js.JSApp
import scala.scalajs.js.annotation.JSName
import org.scalajs.dom
import org.scalajs.jquery.jQuery
import dom.document
import scala.scalajs.js.timers._

aappddeevv

// Requires scalaz to be on the classpath

import scalaz._
import scalaz.State._

// The State monad was hard for me to understand because it
// seems as if you never actually store a value in the state and
// manipulate it inside of a method like you would in java.

// There are really two types of methods in the scalaz library

aappddeevv

import scalaz._
import scalaz.State._

case class Session(version: Int = 0)

// Create a new output string and increment session version.
def func1(arg: String) = State((x: Session) => (x.copy(version = x.version + 1), arg + "-" + x.version))

val composedFunction1: State[Session, String] = for { 
  // Because we gave this val an explicit type, init does not need the type specification

aappddeevv

As a follow up to my last post about no free lunch I wanted to show more state monad usage and recognize that you can change function return types in the middle of a for-comprehension. This allows each function to return different types of values from the computation along the way.

In the code below, you compose a function by using the for-comprehension. The yield part of the for-comprehension is a State object. When that state object is called, it returns a tuple of (state, value). You can use ._1 or ._2 to obtain the value of interest.

The last composed function shows an example of changing the state type (instead of changing the returned value type mentioned above) in the middle of the for-comprehension using scalaz IndexedState's iPut and iModify. This allows you to change the type of state as you go to adapt to different function's API needs.

import scalaz._
import scalaz.State._

aappddeevv

##The Reader and State Monad The Reader and State monads are very similar in that they both wrap a function.

As we have seen in past posts, the State monad allows you to define a wrapper around a function that takes a current state and produces a tuple of the new state and a value. Returning a new state allows you to modify the state object for the next function that gets called. The state object used is immutable so when you return a new state object it is typically a copy of the incoming state with some type of adjustment e.g. increment a counter.

The Reader monad also wraps a function. However, it is designed to be a read-only mechanism in that the return value of the function it wraps is just a value. The reader uses a "context" concept instead of a "state" concept but they are essentially the same thing--an object of some type. However, since you only return a value from the wrapped reader function, the Reader communicates the concept that the context is immutable and not be changed. That's why its ter