index.xml

<?xml version="1.0" encoding="utf-8" standalone="yes" ?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Eric Weise</title>
    <link>http://eweise.com/index.xml</link>
    <description>Recent content on Eric Weise</description>
    <generator>Hugo -- gohugo.io</generator>
    <language>US-EN</language>
    <copyright>All rights reserved - 2017</copyright>
    <lastBuildDate>Wed, 18 Sep 2019 22:00:06 -0800</lastBuildDate>
    <atom:link href="http://eweise.com/index.xml" rel="self" type="application/rss+xml" />
    
    <item>
      <title>Category Theory in Kotlin - Monoids</title>
      <link>http://eweise.com/post/category-into/</link>
      <pubDate>Wed, 18 Sep 2019 22:00:06 -0800</pubDate>
      
      <guid>http://eweise.com/post/category-into/</guid>
      <description>

&lt;h2 id=&#34;introduction&#34;&gt;Introduction&lt;/h2&gt;

&lt;p&gt;I am starting a series of blog posts pertaining to a book that I am reading called &lt;a href=&#34;https://github.com/hmemcpy/milewski-ctfp-pdf&#34;&gt;Category Theory for Programmers&lt;/a&gt; by Bartosz Milewski.
Bartosz has already done a series a &lt;a href=&#34;https://bartoszmilewski.com/2014/10/28/category-theory-for-programmers-the-preface&#34;&gt;posts&lt;/a&gt; on the topics in the book so instead of covering the same ground, my posts will be specifically about implementing the various category pattern in kotlin.
I will try to make them as easy to understand as possible and provide useful examples.
I won&amp;rsquo;t go into detail about actual category theory because the book does a much better job of that.
I will just take a look at the pattern itself and explain why its useful and show an example in Kotlin&lt;/p&gt;

&lt;h2 id=&#34;monoids&#34;&gt;Monoids&lt;/h2&gt;

&lt;p&gt;Monoid is our first pattern.  The name sounds like some disease you might catch or aliens from another planet.
But like most names from category theory, it might sound a bit intimidating but the actual pattern is simple to understand.
Let&amp;rsquo;s take a look at what a Monoid is&lt;/p&gt;

&lt;pre&gt;&lt;code class=&#34;language-java&#34;&gt;interface Monoid&amp;lt;T&amp;gt;{
    fun combine(t1:T, t2:T):T
    fun empty():T
}
&lt;/code&gt;&lt;/pre&gt;

&lt;p&gt;There are two methods. The first is &lt;em&gt;combine&lt;/em&gt; and it does pretty much what it says. It combines two values represented by &lt;em&gt;&amp;lt;T&amp;gt;&lt;/em&gt;.
The next function &lt;em&gt;empty&lt;/em&gt; is less obvious. It takes no parameters and just returns a &lt;em&gt;T&lt;/em&gt;.
The return value however, need to represent a value that when &lt;em&gt;combined&lt;/em&gt; with another &lt;em&gt;T&lt;/em&gt;, will not change the other value.
For example if I combine the value 3 with the value 0 then the result still 3.&lt;/p&gt;

&lt;p&gt;There is one more aspect to Monoid and category theory patterns in general. In addition to specifying an interface, they also have laws.
The law with Monoid is that the combine function must be associative, meaning that if I combine values A and B first and then combine that result with C,
it should be the same as combining values B and C first and then combining A with that result. The order of precedence can change without changing the result.
In math terms we say: (A + B) + C = A + (B + C). This law can&amp;rsquo;t be enforced by the compiler but users of your Monoid will expect it to be true.&lt;/p&gt;

&lt;p&gt;Let&amp;rsquo;s see the power of monoids by applying the pattern to a custom data type Money. Here is our simple Money type&lt;/p&gt;

&lt;pre&gt;&lt;code class=&#34;language-java&#34;&gt;data class Money(val value: BigDecimal) {
    constructor(strValue: String) : this(BigDecimal(strValue))
}
&lt;/code&gt;&lt;/pre&gt;

&lt;p&gt;It would be great if we could add our money so let&amp;rsquo;s create a Money Monoid.&lt;/p&gt;

&lt;pre&gt;&lt;code class=&#34;language-java&#34;&gt;object MoneyMonoid : Monoid&amp;lt;Money&amp;gt; {
    override fun combine(v1: Money, v2: Money): Money {
        return Money(v1.value.plus(v2.value))
    }

    override fun empty(): Money {
        return Money(BigDecimal.ZERO)
    }
}
&lt;/code&gt;&lt;/pre&gt;

&lt;p&gt;Notice that the empty() method is implemented by returning the value 0.&lt;/p&gt;

&lt;p&gt;Here is an example of our MoneyMonoid in action&lt;/p&gt;

&lt;pre&gt;&lt;code class=&#34;language-java&#34;&gt;assert(MoneyMonoid.combine(Money(&amp;quot;1&amp;quot;), Money(&amp;quot;2&amp;quot;)) == Money(&amp;quot;3&amp;quot;))
&lt;/code&gt;&lt;/pre&gt;

&lt;p&gt;The MoneyMonoid succesfully added 1 + 2 to equal 3.
OK that&amp;rsquo;s not so impressive since we could have just directly put an add function on the Money class.
The power of the abstraction however, can be demonstrated by building additional functionality on top of Monoid.
For instance, we can now create an extension method &lt;em&gt;fold&lt;/em&gt; that combines any number of Monoids.&lt;/p&gt;

&lt;pre&gt;&lt;code class=&#34;language-java&#34;&gt;fun &amp;lt;T&amp;gt; Monoid&amp;lt;T&amp;gt;.fold(ts:List&amp;lt;T&amp;gt;):T {
    return ts.foldRight(this.empty()) { t: T, accumulator: T -&amp;gt; this.combine(t, accumulator) }
}
&lt;/code&gt;&lt;/pre&gt;

&lt;p&gt;Notice that the &lt;em&gt;fold&lt;/em&gt; function could be used with any Monoid, not just MoneyMonoid.&lt;/p&gt;

&lt;p&gt;Now we can use this generic fold method to sum all our money&lt;/p&gt;

&lt;pre&gt;&lt;code class=&#34;language-java&#34;&gt;val listOfMoney = listOf( Money(&amp;quot;1&amp;quot;),Money(&amp;quot;2&amp;quot;),Money(&amp;quot;3&amp;quot;) )

assert(MoneyMonoid.fold(listOfMoney) == Money(&amp;quot;6&amp;quot;))

&lt;/code&gt;&lt;/pre&gt;

&lt;p&gt;We defined a very generic concept &lt;em&gt;combining&lt;/em&gt; and were able to build upon it to create additional functionality.
 category theory patterns are all very generic and sometimes very abstract.
 They are built using interfaces but also have laws that must be enforced by each implementation.&lt;/p&gt;
</description>
    </item>
    
    <item>
      <title>Pushing Side Effects to the Side</title>
      <link>http://eweise.com/post/sideeffects/</link>
      <pubDate>Mon, 12 Jun 2017 22:00:06 -0800</pubDate>
      
      <guid>http://eweise.com/post/sideeffects/</guid>
      <description>&lt;p&gt;Functional programming provides a treasure trove of useful patterns, one of which is pushing side effects to the edges of your application.  Side effects are functions that have non-deterministic behavior. Examples include making an Http call or persisting data to the database These calls can fail due to network issues or other outside influences. But side effects can also be functions that don&amp;rsquo;t fail such as retrieving the current time or a random number, since they don&amp;rsquo;t always give the same value back. By isolating these types of calls, we can more easily test our code.&lt;/p&gt;

&lt;p&gt;The following is an example loosely based on a refactoring I did at work. The use case is similar to Google Calendar where events re-occur over a period of time or for a number of iterations. An example code snippet from our implementation looked similar to the following;&lt;/p&gt;

&lt;pre&gt;&lt;code class=&#34;language-java&#34;&gt;class EventService {

  public List&amp;lt;RecurringEvent&amp;gt; generateEvents(RecurringEvent recurringEvent) {
    List&amp;lt;Event&amp;gt; generatedEvents = new ArrayList&amp;lt;&amp;gt;();
    LocalDate nextDate = recurringEvent.startDate;
    int generatedCount = 0;
    LocalDate maximumDate = Local.now().plusDays(180);

     while(generatedCount &amp;lt; recurringEvent.maxNumber
           &amp;amp;&amp;amp; !nextDate.isAfter(recurringEvent.endDate))
           &amp;amp;&amp;amp; !nextDate.isAfter maximumDate) {

        Event newEvent = createEvent(recurringEvent, nextDate);
        entityManager.persist(newEvent);
        generatedEvents.add(newEvent);
        generatedCount++;
        nextDate = Recurrence.nextDate(nextDate, recurringEvents.repeatPattern);
    }
    return generatedEvents;
  }
}
&lt;/code&gt;&lt;/pre&gt;

&lt;p&gt;This code has some non-trivial conditions that determines how many events to generate. Testing it would involve checking each of the conditions. At a minimum however, we can test that it generates some events.&lt;/p&gt;

&lt;pre&gt;&lt;code class=&#34;language-java&#34;&gt;
class EventServiceTest extends SpringyTest {

  @Autowired
  private EntityManager EntityManager;

  private EventService eventService = new EventService(entityManager);

  @test
  public void testgenerateEvents() {
    RecurringEvent recurringEvent = RecurringEventFixture.create();
    List&amp;lt;Event&amp;gt; generatedEvents = eventService.generateEvents(recurringEvents);

    // assert the correct number of events were generated
    Assert.assertEquals(4, generateEvents.size());
  }

}

&lt;/code&gt;&lt;/pre&gt;

&lt;p&gt;While the test looks fairly straightforward, it is actually complex because it needs to connect to a database in order to succeed. We need to ensure that the database starts and ends in a clean state and that no other tests interfere with the data while the test is running. Otherwise, we may get a different result or db related failure. The test also incurs a large performance penalty since it needs to wire up a connection pool and any other dependencies in the Spring configuration.&lt;/p&gt;

&lt;p&gt;In the refactored code, the EntityManager.persist call is removed from the business logic. Notice that the LocalDate.now call is also removed. Remember that we want to always get the same result given the same method argument. Having the current date directly in the business logic could cause the function to behave differently depending on what day it is. Have you ever had tests that worked fine most days but failed at the beginning or end of the month? Moving the dates outside of the business logic should help.&lt;/p&gt;

&lt;pre&gt;&lt;code class=&#34;language-java&#34;&gt;class EventService {

  public void generateAndPersistRecurringEvents(RecurringEvent recurringEvent) {
      List&amp;lt;RecurringEvent&amp;gt; newEvents = generateEvents(recurringEvent, LocalDate.now());
      newEvents.forEach(EntityManager::persist);
  }

  public List&amp;lt;RecurringEvent&amp;gt; generateEvents(RecurringEvent recurringEvent, LocalDate currentDate) {
    List&amp;lt;Event&amp;gt; generatedEvents = new ArrayList&amp;lt;&amp;gt;();
    LocalDate nextDate = recurringEvent.startDate;
    int generatedCount = 0;
    LocalDate maximumDate = currentDate.plusDays(180);

     while(generatedCount &amp;lt; recurringEvent.maxNumber
           &amp;amp;&amp;amp; !nextDate.isAfter(recurringEvent.endDate))
           &amp;amp;&amp;amp; !nextDate.isAfter maximumDate) {

        Event newEvent = createEvent(recurringEvent, nextDate);
        generatedEvents.add(newEvent);
        generatedCount++;
        nextDate = Recurrence.nextDate(nextDate, recurringEvents.repeatPattern);
    }
    return generatedEvents;
  }
}
&lt;/code&gt;&lt;/pre&gt;

&lt;p&gt;Our test now becomes a simple unit test instead of a Spring/database type integration test.&lt;/p&gt;

&lt;pre&gt;&lt;code class=&#34;language-java&#34;&gt;class EventServiceTest  {

  @test
  public void testGenerateEvents() {
    RecurringEvent recurringEvent = RecurringEventFixture.create();
    LocalDate today = LocalDate.of(2017, 1, 1);
    List&amp;lt;RecurringEvent&amp;gt; generatedEvents = EventService.generateEvents(recurringEvent, today);

    // assert the correct number of events were generated
    Assert.assertEquals(4, generateEvents.size());
  }

}
&lt;/code&gt;&lt;/pre&gt;

&lt;p&gt;How many methods could you turn into simple pure function calls simply by removing side effect calls such as repositories from your business logic? Most projects I have worked on just sprinkle database calls throughout service layer.&lt;/p&gt;

&lt;p&gt;In general the pattern I try to follow is;&lt;/p&gt;

&lt;ol&gt;
&lt;li&gt;Retrieve all the data necessary to perform the business logic (side effect code).&lt;/li&gt;
&lt;li&gt;Perform the business logic using in-memory data (pure functions).&lt;/li&gt;
&lt;li&gt;Persist changes to the database (side effect code).&lt;/li&gt;
&lt;/ol&gt;

&lt;p&gt;These three steps can&amp;rsquo;t be followed every time but when they can, the code will be much easier to test.&lt;/p&gt;
</description>
    </item>
    
    <item>
      <title>Akka Cluster Example</title>
      <link>http://eweise.com/post/akka-cluster-example/</link>
      <pubDate>Wed, 05 Feb 2014 22:00:06 -0800</pubDate>
      
      <guid>http://eweise.com/post/akka-cluster-example/</guid>
      <description>

&lt;p&gt;Akka provides powerful clustering capabilities but reading through the &lt;a href=&#39;http://doc.akka.io/docs/akka/2.3.2/scala/cluster-usage.html&#39;&gt;online docs&lt;/a&gt; it may not be obvious how to set it up for your particular needs. For my use case, I wanted to create multiple actors representing a particular service that would run on more that one machine. If one machine failed, actors on other machines could still handle the requests, as in a typical high availability scenario. In addition, I did not want the calling actor to have any knowledge of which machines could handle the request, only that one actor in the cluster would handle it. Akka&amp;rsquo;s provides exactly these capabilities using the DistributedPubSubExtension provided in Akka&amp;rsquo;s contrib module. This article will demonstrate how to create a clustered service using the DistributedPubSubExtension.
&lt;p&gt;In our example we have two types of actors; a BackendService actor which represents some arbitrary service running in the cluster and a WebService actor which handles http requests and in turn calls a BackendService to perform some work. The BackendService is stateless and there are many running in the cluster. The WebService just need to call any one BackendService to have the work performed.&lt;/p&gt;

&lt;h2 id=&#34;the-distributedpubsubmediator&#34;&gt;The DistributedPubSubMediator&lt;/h2&gt;

&lt;p&gt;Both the WebService and the BackEndService create a DistributedPubSubMediator. The DistributedPubSubMediator is an actor that maintains a registry of other ActorRefs and distributes them to peers around the network. This allows clients to refer actors by role instead of by a specific address. It also allows actors to join or leave the cluster and the mediator will track which actors are currently active.&lt;/p&gt;

&lt;pre&gt;&lt;code class=&#34;language-scala&#34;&gt;  val mediator = DistributedPubSubExtension(context.system).mediator
&lt;/code&gt;&lt;/pre&gt;

&lt;h2 id=&#34;backend-service-implementation&#34;&gt;Backend Service Implementation&lt;/h2&gt;

&lt;p&gt;In our BackendServiceActor constructor we simply need to create the mediator and register our actor with it. The mediator will in turn update all its peer mediators in the cluster informing them that our BackendServiceActor has joined the cluster&lt;/p&gt;

&lt;pre&gt;&lt;code class=&#34;language-scala&#34;&gt;  mediator ! Put(self)
&lt;/code&gt;&lt;/pre&gt;

&lt;p&gt;The rest of the BackendActor is a standard Actor implementation where we listen for messages in a receive method&lt;/p&gt;

&lt;pre&gt;&lt;code class=&#34;language-scala&#34;&gt;  def receive = {
    case PerformWork =&amp;gt;
      log.info(&amp;quot;Backend Service is performing some work&amp;quot;)
      sender() ! OK
  }
&lt;/code&gt;&lt;/pre&gt;

&lt;h2 id=&#34;the-web-service&#34;&gt;The Web Service&lt;/h2&gt;

&lt;p&gt;For our Web service we will use Spray.io which is a library built on top of Akka that provides all the functionality we need to process http requests. To use Spray we create an actor that inherits from the HttpService trait.&lt;/p&gt;

&lt;pre&gt;&lt;code class=&#34;language-scala&#34;&gt;   class WebServiceActor extends Actor with HttpService
&lt;/code&gt;&lt;/pre&gt;

&lt;p&gt;Like in the BackendService actor, we need to create a mediator in the HttpService constructor. Then we can send messages to the BackendService via the mediator&lt;/p&gt;

&lt;pre&gt;&lt;code class=&#34;language-scala&#34;&gt;mediator ? Send(&amp;quot;/user/backend-service&amp;quot;, PerformWork, false)
&lt;/code&gt;&lt;/pre&gt;

&lt;p&gt;As with all actors we need to implement a &amp;lsquo;receive&amp;rsquo; method. Our receive method will provide http routing information to Spray so it knows how to handle requests. Spray provides a DSL for doing this. In our example we implement just one route &amp;ldquo;dowork&amp;rdquo; in order to see our cluster in action&lt;/p&gt;

&lt;pre&gt;&lt;code class=&#34;language-scala&#34;&gt;def receive = runRoute {
    path(&amp;quot;dowork&amp;quot;) {
      onComplete(mediator ? Send(&amp;quot;/user/backend-service&amp;quot;, PerformWork, false)) {
        case Success(value) =&amp;gt; complete(&amp;quot;OK&amp;quot;)
        case Failure(e) =&amp;gt; complete(e.getMessage)
      }
    }
  }
&lt;/code&gt;&lt;/pre&gt;

&lt;p&gt;##Configuration
Both services need to provide configuration information to the ActorSystems. In the application.conf file we need to add the extension class&lt;/p&gt;

&lt;pre&gt;&lt;code&gt;  extensions = [
    &amp;quot;akka.contrib.pattern.DistributedPubSubExtension&amp;quot;
  ]
&lt;/code&gt;&lt;/pre&gt;

&lt;p&gt;You can also configure the PubSubExtension with the following properties&lt;/p&gt;

&lt;pre&gt;&lt;code&gt;akka.contrib.cluster.pub-sub {
  # Actor name of the mediator actor, /user/distributedPubSubMediator
  name = distributedPubSubMediator

  # Start the mediator on members tagged with this role.
  # All members are used if undefined or empty.
  role = &amp;quot;&amp;quot;

  # How often the DistributedPubSubMediator should send out gossip information
  gossip-interval = 1s

  # Removed entries are pruned after this duration
  removed-time-to-live = 120s
}
&lt;/code&gt;&lt;/pre&gt;

&lt;p&gt;##Conclusion
A complete example that can run is available  &lt;a href=&#34;https://github.com/eweise/akka-pubsub-cluster-example&#34;&gt;here&lt;/a&gt;. Try booting up multiple BackendService instances. You will notice that the router selects actors randomly which is the default but can be changed to other strategies including round-robin. One issue I see in the example is that a delay occurs handling requests when a BackendService leaves the cluster, potentially causing the WebService requests to timeout for a brief time. This could possibly be hardened by adding retry logic into the Webservice. Overall Akka provides an incredible amount of functionality and the contrib module builds on top of the core features to making implementing clustered services almost trivial.&lt;/p&gt;
</description>
    </item>
    
  </channel>
</rss>