SzymonPobiega

If you have two days to learn the very basics of modelling, Domain-Driven Design, CQRS and Event Sourcing, here's what you should do:

In the evenings read the [Domain-Driven Design Quickly Minibook]{http://www.infoq.com/minibooks/domain-driven-design-quickly}. During the day watch following great videos (in this order):

1. Eric Evans' [What I've learned about DDD since the book]{http://www.infoq.com/presentations/ddd-eric-evans}
2. Eric Evans' [Strategic Design - Responsibility Traps]{http://www.infoq.com/presentations/design-strategic-eric-evans}
3. Udi Dahan's [Avoid a Failed SOA: Business & Autonomous Components to the Rescue]{http://www.infoq.com/presentations/SOA-Business-Autonomous-Components}
4. Udi Dahan's [Command-Query Responsibility Segregation]{http://www.infoq.com/presentations/Command-Query-Responsibility-Segregation}
5. Greg Young's [Unshackle Your Domain]{http://www.infoq.com/presentations/greg-young-unshackle-qcon08}
6. Eric Evans' [Acknowledging CAP at the Root -- in the Domain Model]{ht

ceharris

I think that Thread.interrupt() sounds more intrusive than it really is. Thread interruption in Java is entirely advisory. Generally a task does not need to go to any effort to avoid being interrupted. Rather, it usually takes some real effort to properly observe the interrupt status in order to exit when interrupted, if such is desired. Short of putting in the effort to observe the thread's interrupt status, I think you'll find that arbitrary tasks are quite resilient in the face of interrupts.

A task can check the thread's interrupt status at any time by calling Thread.isInterrupted(). If you wish to make a runnable task interruptible, your code must occasionally check the interrupt status and exit the run() method if the task has been interrupted. If you don't want your task to be interrupted, simply ignore the thread's interrupt status.

JDK methods that examine the thread's interrupt status are consistently declared to throw InterruptedException, so they are easily identified. I/O calls w

dodyg

#Intro

Kotlin is a new programming language for the JVM. It produces Java bytecode, supports Android and generates JavaScript. The latest version of the language is Kotlin M5.3

Kotlin project website is at kotlin.jetbrains.org.

All the codes here can be copied and run on Kotlin online editor.

Let's get started.

mychaelstyle

apply plugin: "java"
apply plugin: "eclipse"
apply plugin: "maven"
apply plugin: "findbugs"
apply plugin: "pmd"

def defaultEncoding = 'UTF-8'
[compileJava, compileTestJava]*.options*.encoding = defaultEncoding

sourceCompatibility = 1.7

staltz

The introduction to Reactive Programming you've been missing

(by @andrestaltz)

---

This tutorial as a series of videos

If you prefer to watch video tutorials with live-coding, then check out this series I recorded with the same contents as in this article: Egghead.io - Introduction to Reactive Programming.

---

dmarcato

def toCamelCase(String string) {
    String result = ""
    string.findAll("[^\\W]+") { String word ->
        result += word.capitalize()
    }
    return result
}

afterEvaluate { project ->
    Configuration runtimeConfiguration = project.configurations.getByName('compile')

artem-zinnatullin

// add this to the general build.gradle, not in the subproject's build.gradle
// improved version of Xavier's tip http://tools.android.com/tech-docs/new-build-system/tips#TOC-Improving-Build-Server-performance.

// usage example default, preDex will be enabled: gradle clean build
// usage example disabling preDex: gradle clean build -PpreDexEnable=false
// preDexEnable parameter's value can be set as property of Continuous Integration build config
// this is the main difference from Xavier's workaround where he doing only hasProperty check

project.ext {
    if (project.hasProperty('preDexEnable')) {

bkase

Production-Ready(?) Native Single-Atom-State Purely Functional Reactive Composable UI Components, or PRNSAASPFRUICC

The native UI toolkits on Android and iOS are frustratingly imperative. Unfortunately, there has been little architecture evolution (unlike the web). However, nothing(ish) is stopping us from bolting something "nice" on top. By nice I mean single-atom-state purely functional reactive composable UI components. In this post, I'll explain what this title means, the inspiration behind the design of the framework, an example component, and dive a little into the framework's implementation.

Right now, there only exists a Kotlin (Android) implementation, but a Swift port will be relatively straightforward and will happen soon.

Let's break down the title:

• "Production-Ready"

andymatuschak

A composable pattern for pure state machines with effects

State machines are everywhere in interactive systems, but they're rarely defined clearly and explicitly. Given some big blob of code including implicit state machines, which transitions are possible and under what conditions? What effects take place on what transitions?

There are existing design patterns for state machines, but all the patterns I've seen complect side effects with the structure of the state machine itself. Instances of these patterns are difficult to test without mocking, and they end up with more dependencies. Worse, the classic patterns compose poorly: hierarchical state machines are typically not straightforward extensions. The functional programming world has solutions, but they don't transpose neatly enough to be broadly usable in mainstream languages.

Here I present a composable pattern for pure state machiness with effects,

sockeqwe

import kotlinx.coroutines.FlowPreview
import kotlinx.coroutines.Job
import kotlinx.coroutines.cancelAndJoin
import kotlinx.coroutines.coroutineScope
import kotlinx.coroutines.flow.Flow
import kotlinx.coroutines.flow.collect
import kotlinx.coroutines.flow.flow
import kotlinx.coroutines.launch

/**