James Pittendreigh jaymoid

Dependency Injection in Functional Programming

There exist several DI frameworks / libraries in the Scala ecosystem. But the more functional code you write the more you'll realize there's no need to use any of them.

A few of the most claimed benefits are the following:

Dependency Injection.
Life cycle management.
Dependency graph rewriting.

Quick Tips for Fast Code on the JVM

I was talking to a coworker recently about general techniques that almost always form the core of any effort to write very fast, down-to-the-metal hot path code on the JVM, and they pointed out that there really isn't a particularly good place to go for this information. It occurred to me that, really, I had more or less picked up all of it by word of mouth and experience, and there just aren't any good reference sources on the topic. So… here's my word of mouth.

This is by no means a comprehensive gist. It's also important to understand that the techniques that I outline in here are not 100% absolute either. Performance on the JVM is an incredibly complicated subject, and while there are rules that almost always hold true, the "almost" remains very salient. Also, for many or even most applications, there will be other techniques that I'm not mentioning which will have a greater impact. JMH, Java Flight Recorder, and a good profiler are your very best friend! Mea

This cheat sheet originated from the forum, credits to Laurent Poulain. We copied it and changed or added a few things.

Evaluation Rules

Call by value: evaluates the function arguments before calling the function
Call by name: evaluates the function first, and then evaluates the arguments if need be

    def example = 2      // evaluated when called
    val example = 2      // evaluated immediately

#Create bitbucket branch

##Create local branch

$ git checkout -b sync
Switched to a new branch 'sync'
$ git branch
  master
* sync

I've been hacking away recently at a JVM framework for doing asynchronous, non-blocking applications using a variation of the venerable Reactor pattern. The core of the framework is currently in Java. I started with Scala then went with Java and am now considering Scala again for the core. What can I say: I'm a grass-is-greener waffler! :) But it understands how to invoke Groovy Closures, Scala anonymous functions, and Clojure functions, so you can use the framework directly without needing wrappers.

I've been continually micro-benchmarking this framework because I feel that the JVM is a better foundation on which to build highly-concurrent, highly-scalable, C100K applications than V8 or Ruby. The problem has been, so far, no good tools exist for JVM developers to leverage the excellent performance and manageability of the JVM. This yet-to-be-publicly-released framework is an effort to give Java, Groovy, Scala, [X JVM language] developers access to an easy-to-use programming model that removes the necessity

	{-# LANGUAGE DerivingStrategies #-}
	{-# LANGUAGE DerivingVia #-}
	{-# LANGUAGE GeneralizedNewtypeDeriving #-}

	module Aoc1 where

	import Data.Foldable
	import Data.Monoid (Sum(..))
	import Data.Ratio

	@Bean
	public KStream<?, ?> kstreamProcessorApi(StreamsBuilder streamsBuilder) {
	StoreBuilder<KeyValueStore<String, IotEvent>> eventStoreBuilder =
	Stores.keyValueStoreBuilder(Stores.persistentKeyValueStore("eventstore"),
	Serdes.String(), iotEventSerde());
	// register store
	streamsBuilder.addStateStore(eventStoreBuilder);
	KStream<String, IotEvent> stream = streamsBuilder.stream(inputTopic, Consumed.with(Serdes.String(), iotEventSerde()));
	stream
	.process(() -> new Processor<String, IotEvent>() {

	import android.os.Parcel;
	import java.util.ArrayList;
	import java.util.List;
	import org.mockito.invocation.InvocationOnMock;
	import org.mockito.stubbing.Answer;

	import static org.mockito.Matchers.anyInt;
	import static org.mockito.Matchers.anyLong;
	import static org.mockito.Matchers.anyString;
	import static org.mockito.Mockito.doAnswer;

	Go to Bitbucket and create a new repository (its better to have an empty repo)
	git clone git@bitbucket.org:abc/myforkedrepo.git
	cd myforkedrepo

	Now add Github repo as a new remote in Bitbucket called "sync"
	git remote add sync git@github.com:def/originalrepo.git

	Verify what are the remotes currently being setup for "myforkedrepo". This following command should show "fetch" and "push" for two remotes i.e. "origin" and "sync"
	git remote -v