aappddeevv

If you need a redux reducer that adds some "injectables" as the third argument to the reducers normally combined in redux's combineReducers, try this one:

/** 
 * A combineReducers replacement that adds additional arguments
 * to the reduction call to inject different values a reducer
 * might need, read-only, from other parts of the tree. Reducer
 * order calling is not specified. If no injectables are provided
 * the overall state is included under the key "_root_".
 *
 * @param {Object} reducers Reducer object. Each key with a function is included in a final reducer.

aappddeevv

// Define functions that return an Option
def f1(x: Int): Option[Int] = Some(x*30)
def f2(x: Int): Option[Int] = Some(x+3)
def f3(x: Int): Option[Int] = Some(x*2)

// Sequence the computation, it will be successful
var answer = for {
  x <- f1(30)
  y <- f2(x)

aappddeevv

A relatively simple akka server with a few bells and whistes.

package example

import scala.language._
import akka.actor._
import akka.http.scaladsl
import scaladsl._

aappddeevv

##Cake Pattern and Why Cake Patterns Sometimes Look Different The cake pattern is typically described as a way to use small layers of functionality to create a larger, more complex program. This area of application design is typically designed with application scalability not in the pure performance sense, but in the sense of scaling the application up to more complex functionality and maintainability over time.

There have been many papers and blogs on this aspect, but a few especially helpful blogs include:

• http://debasishg.blogspot.com/2010/02/scala-self-type-annotations-for.html
• http://jonasboner.com/2008/10/06/real-world-scala-dependency-injection-di
• https://www.precog.com/blog-precog-2/entry/existential-types-ftw
• https://coderwall.com/p/t_rapw

aappddeevv

I forgot to add a full version of the NotesService that was discussed in a previous blog.

Let's revisit the NotesService interface:

/**
 * Primarily for larger notes/docs storage.
 * The API allows the note content to be retrieved
 * separately. Sometimes, we want to separate
 * out the larger, less changing content from

aappddeevv

If you use "readers" similar to play's json reader framework, you know that its a nice framework to compose your json converters. There is a similar framework for reading XML from lucidchart called xtract.

xtract only provides XML reading. Its very similar to play json. Many of the examples that demonstrate the play json or xtract library are fairly simple and did not help me understand how to compose readers that need to have alternatives. For example, an XML fragment may have an element called Fault or an element called Data and you want to compose a reader that automatically handles both in one reader instance. How do you do that?

Here's some scalatest examples that show one way to do that. You have some choices about how to navigate and how to compose so pay special attention to the details in the tests. I prefer to compose by using readers at the top element and use and/or on the builders, but you can choose to do it anyway you wish.

import org.scalatest._

class readerspecs extends FlatSp

aappddeevv

Web App Development Issues

Web app development and workflow is pretty much a messy exercise that has few standards. I am trying to document the messiness and suggest one way around it that smoothly scales from a small project to a large project without using yet another workflow layer (YAWL).

I am assuming that you are using tools such as node, grunt and bower. While it is possible to use other tools such as makefiles or generators such as lineman or brunch, the issues that bring such complexity to the workflow process are built into the very nature of web protocols and application deployment model. Unlike java, which has standardized packaging and deployment models, web apps can take on a wide variety of packaging and deployment models based on several factors such as organizational process ("this is the way we do it"), bandwidth/latency constraints, dev debugging needs as well as application model (client heavy, SPA or server heavy).

There is a lively ecosystems to help manage this complexity as ment

aappddeevv

This is a URL handler I needed for my javafx application in order to allow WebView (WebEngine) find my classpath resources and use relative resources for images, scripts, etc. If you only use WebEngine.loadContent, you cannot use relative resources and your web pages become much less flexible when changing later.

/**
 * Handler factory different types of URL handling.
 */
class ConfigurableStreamHandlerFactory extends URLStreamHandlerFactory {

  private var handlers = Map[String, URLStreamHandler]()

aappddeevv

###The Problem I have an app that uses neo4j as the underlying database. Similar to all database applications, I also have a data access layer that helps abstract out the use of neo4j.

The data access layer takes in string parameters, mostly, finds the neo4j nodes or relationships then manipulates the those objects to create a new object.

In this access layer, I must gather several different objects together to process. For example, the start node, the end node, another node that holds my dynamic type system, and various other objects.

When assembling these nodes, I typically find the pattern to go something like this:

• Check the input parameters

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