davidallsopp

import org.scalatest._
import prop._
import org.scalacheck.Arbitrary._
import org.scalacheck.Gen

/**
 * Solutions to the ScalaCheck problem that shrinking failing values may generate 
 * invalid values, because the constraints of the generator are not respected.
 *
 * See also http://stackoverflow.com/questions/20037900/scalacheck-wont-properly-report-the-failing-case

brianc

Some thoughts on using node-postgres in a web application

This is the approach I've been using for the past year or so. I'm sure I'll change and it will change as I grow & am exposed to more ideas, but it's worked alright for me so far.

Pooling:

I would definitely use a single pool of clients throughout the application. node-postgres ships with a pool implementation that has always met my needs, but it's also fine to just use the require('pg').Client prototype and implement your own pool if you know what you're doing & have some custom requirements on the pool.

jaceklaskowski

Rough Notes about CQRS and ES

Once upon a time…

I once took notes (almost sentence by sentence with not much editing) about the architectural design concepts - Command and Query Responsibility Segregation (CQRS) and Event Sourcing (ES) - from a presentation of Greg Young and published it as a gist (with the times when a given sentence was heard).

I then found other summaries of the talk and the gist has since been growing up. See the revisions to know the changes and where they came from (aka the sources).

It seems inevitable to throw Domain Driven Design (DDD) in to the mix.

maji-KY

package com.neco_labo.db

import com.zaxxer.hikari.{HikariDataSource, HikariConfig}
import org.skife.jdbi.v2.{DefaultMapper, DBI}

import scala.collection.JavaConverters._

object JDBI extends App {

  val config = new HikariConfig()

djspiewak

Introduction to scalaz-stream

Every application ever written can be viewed as some sort of transformation on data. Data can come from different sources, such as a network or a file or user input or the Large Hadron Collider. It can come from many sources all at once to be merged and aggregated in interesting ways, and it can be produced into many different output sinks, such as a network or files or graphical user interfaces. You might produce your output all at once, as a big data dump at the end of the world (right before your program shuts down), or you might produce it more incrementally. Every application fits into this model.

The scalaz-stream project is an attempt to make it easy to construct, test and scale programs that fit within this model (which is to say, everything). It does this by providing an abstraction around a "stream" of data, which is really just this notion of some number of data being sequentially pulled out of some unspecified data source. On top of this abstraction, sca

montanaflynn

To reproduce Kong's benchmark please follow these instructions.

Create AWS Instances

Spin up three m3.medium EC2 ubuntu 14.04 instances with public DNS enabled and configure them for high network traffic by increasing these limits:

Added fs.file-max=80000 to /etc/sysctl.conf

Added the following lines to /etc/security/limits.conf

adamw

  val rejectionHandler = RejectionHandler.default
  def logDuration(inner: Route): Route = { ctx =>
    val start = System.currentTimeMillis()
    // handling rejections here so that we get proper status codes
    val innerRejectionsHandled = handleRejections(rejectionHandler)(inner)
    mapResponse { resp =>
      val d = System.currentTimeMillis() - start
      logger.info(s"[${resp.status.intValue()}] ${ctx.request.method.name} ${ctx.request.uri} took: ${d}ms")
      resp
    }(innerRejectionsHandled)(ctx)

joewiz

On Tue Oct 27, 2015, history.state.gov began buckling under load, intermittently issuing 500 errors. Nginx's error log was sprinkled with the following errors:

2015/10/27 21:48:36 [crit] 2475#0: accept4() failed (24: Too many open files)

2015/10/27 21:48:36 [alert] 2475#0: *7163915 socket() failed (24: Too many open files) while connecting to upstream...

An article at http://www.cyberciti.biz/faq/linux-unix-nginx-too-many-open-files/ provided directions that mostly worked. Below are the steps we followed. The steps that diverged from the article's directions are marked with an *.

1. * Instead of using su to run ulimit on the nginx account, use ps aux | grep nginx to locate nginx's process IDs. Then query each process's file handle limits using cat /proc/pid/limits (where pid is the process id retrieved from ps). (Note: sudo may be necessary on your system for the cat command here, depending on your system.)
2. Added fs.file-max = 70000 to /etc/sysctl.conf

fancellu

object MergeSort {

		// recursive merge of 2 sorted lists
	def merge(left: List[Int], right: List[Int]): List[Int] =
        (left, right) match {
	        case(left, Nil) => left
	        case(Nil, right) => right
	        case(leftHead :: leftTail, rightHead :: rightTail) =>
	          if (leftHead < rightHead) leftHead::merge(leftTail, right)
	          else rightHead :: merge(left, rightTail)

DrBoolean

const daggy = require('daggy')
const compose = (f, g) => x => f(g(x))
const id = x => x

//===============Define Coyoneda=========
const Coyoneda = daggy.tagged('x', 'f')

Coyoneda.prototype.map = function(f) {
  return Coyoneda(this.x, compose(f, this.f))
}