coltfred

import org.apache.hadoop.fs.Path
import org.apache.hadoop.hbase.io.hfile.{ HFile, HFileScanner }
import org.apache.hadoop.hbase.io.hfile.HFile.Reader
import org.apache.hadoop.hbase.io.ImmutableBytesWritable
import org.apache.hadoop.hbase.KeyValue
import org.apache.hadoop.mapreduce.{ JobContext, InputSplit, TaskAttemptContext, RecordReader }
import org.apache.hadoop.mapreduce.lib.input.{ FileInputFormat, FileSplit }

/**
 * A MapReduce InputFormat for HBase's HFile.

coltfred

object RefactorPuzzle {
  import scala.language.higherKinds
  trait Monad[F[_]] {
    def point[A](a: => A): F[A]
    def flatMap[A, B](ma: F[A])(f: A => F[B]): F[B]
    def map[A, B](ma: F[A])(f: A => B): F[B]
  }

  implicit def optionMonad = new Monad[Option] {
    def point[A](a: => A): Option[A] = Some(a)

coltfred

module Window where

import Data.Monoid

data Window a = Window [a] a [a] deriving (Show,Read)

null :: Window a -> Bool
null (Window [] _ []) = True
null _ = False

coltfred

// Implementing functor manually

import scalaz._, Scalaz._, Free.liftF

sealed trait TestF[+A]
case class Foo[A](o: A) extends TestF[A]
case class Bar[A](h: (Int => A)) extends TestF[A]
case class Baz[A](h: (Int => A)) extends TestF[A]

implicit def testFFunctor[B]: Functor[TestF] = new Functor[TestF] {

coltfred

Git DMZ Flow

I've been asked a few times over the last few months to put together a full write-up of the Git workflow we use at RichRelevance (and at Precog before), since I have referenced it in passing quite a few times in tweets and in person. The workflow is appreciably different from GitFlow and its derivatives, and thus it brings with it a different set of tradeoffs and optimizations. To that end, it would probably be helpful to go over exactly what workflow benefits I find to be beneficial or even necessary.

• Two developers working on independent features must never be blocked by each other
  • No code freeze! Ever! For any reason!
• A developer must be able to base derivative work on another developer's work, without waiting for any third party
• Two developers working on inter-dependent features (or even the same feature) must be able to do so without interference from (or interfering with) any other parties
• Developers must be able to work on multiple features simultaneously, or at lea

coltfred

#!/bin/sh
git log --numstat | awk '/^Author: /{author=$0} /^[0-9]+\t[0-9]+/{n = $1 + $2; d[author] += n; t += n} END { for(a in d) { printf("%6d  %6.3f%%  %s\n", d[a], d[a] * 100 / t, a)}}' | sort -rn

# written less illegibly, it is:
#
# git log --numstat | \
#   awk '
#     /^Author: /{author=$0}
#     /^[0-9]+\t[0-9]+/{n = $1 + $2; d[author] += n; t += n}
#     END { for(a in d) { printf("%6d  %6.3f%%  %s\n", d[a], d[a] * 100 / t, a)}}

coltfred

package freedom

import scala.collection.JavaConverters._

import java.awt.{ Color, Graphics2D }
import java.awt.image.BufferedImage

import cats.data.{ Coproduct, Xor }
import cats.free.{ Free, Inject }

coltfred

// Given an interface like

sealed trait Mult 
sealed trait One extends Mult
sealed trait ZeroOrOne extends Mult
sealed trait Many extends Mult

case class NoParam()

coltfred

-- The meta-circular interpreter from section 5 of Reynolds's Definitional
-- Interpreters for Higher Order Programming Languages
-- (http://www.cs.uml.edu/~giam/91.531/Textbooks/definterp.pdf)

data EXP
  = CONST Const
  | VAR Var
  | APPL Appl
  | LAMBDA Lambda
  | COND Cond

coltfred

Revisiting Tagless Final Interpreters

Tageless Final interpreters are an alternative to the traditional Algebraic Data Type (and generalized ADT) based implementation of the interpreter pattern. This document presents the Tageless Final approach with Scala, and shows how Dotty with it's recently added implicits functions makes the approach even more appealing. All examples are direct translations of their Haskell version presented in the Typed Tagless Final Interpreters: Lecture Notes (section 2).

The interpreter pattern has recently received a lot of attention in the Scala community. A lot of efforts have been invested in trying to address the biggest shortcomings of ADT/GADT based solutions: extensibility. One can first look at cats' Inject typeclass for an implementation of [Data Type à la Carte](http://www.cs.ru.nl/~W.Swierstra/Publications/DataTypesA