vkostyukov

API	Status Codes
[Twitter][tw]	200, 304, 400, 401, 403, 404, 406, 410, 420, 422, 429, 500, 502, 503, 504
[Stripe][stripe]	200, 400, 401, 402, 404, 429, 500, 502, 503, 504
[Github][gh]	200, 400, 422, 301, 302, 304, 307, 401, 403
[Pagerduty][pd]	200, 201, 204, 400, 401, 403, 404, 408, 500
[NewRelic Plugins][nr]	200, 400, 403, 404, 405, 413, 500, 502, 503, 503
[Etsy][etsy]	200, 201, 400, 403, 404, 500, 503
[Dropbox][db]	200, 400, 401, 403, 404, 405, 429, 503, 507

vkostyukov

  test("requestLog never completed with empty streaming response") {
    import scala.concurrent.ExecutionContext.Implicits.global
    val closed = new AtomicBoolean(false)
    val service = new HttpService {
      override def serve(ctx: ServiceRequestContext, req: HttpRequest): HttpResponse = {
        val rep = HttpResponse.streaming()
        rep.close()
        rep
      }
    }

vkostyukov

import com.twitter.finagle.builder.ServerBuilder
import com.twitter.finagle.http.path._
import com.twitter.finagle.http.service.RoutingService
import com.twitter.finagle.Service
import com.twitter.finagle.http._
import com.twitter.util.Future
import java.net.InetSocketAddress
import scala.util.parsing.json.JSONObject

object Main extends App {

vkostyukov

/**
 * http://www.geeksforgeeks.org/backtracking-set-7-suduku/
 */
public class Sudoku {

    public static void main(String args[]) {
        new Sudoku(new int[][] {
            {3, 0, 6, 5, 0, 8, 4, 0, 0},
            {5, 2, 0, 0, 0, 0, 0, 0, 0},
            {0, 8, 7, 0, 0, 0, 0, 3, 1},

vkostyukov

import cats.effect.{ContextShift, IO, Resource, Timer}
import com.twitter.finagle.{Http, ListeningServer, Service}
import com.twitter.finagle.http.{Request, Response}
import com.twitter.server.TwitterServer
import com.twitter.util.Future
import io.finch.Endpoint
import io.finch.internal.ToEffect
import java.util.concurrent.CountDownLatch
import scala.concurrent.ExecutionContext

vkostyukov

/**
 * A tiny class that extends a list with four combinatorial operations:
 * ''combinations'', ''subsets'', ''permutations'', ''variations''.
 *
 * You can find all the ideas behind this code at blog-post:
 *
 *   http://vkostyukov.ru/posts/combinatorial-algorithms-in-scala/
 *
 * How to use this class.
 *

vkostyukov

# Migrate to Finagle 6.30 https://groups.google.com/forum/#!topic/finaglers/skmdgDhcP0c
git grep -lz 'finagle.httpx' | xargs -0 sed -i '' -e 's/finagle.httpx/finagle.http/g'
git grep -lz 'Httpx' | xargs -0 sed -i '' -e 's/Httpx/Http/g'

vkostyukov

The [Future Finch][1] writeup defines a vector in which Finch 1.0 should be developed. The goal for 1.0 is to build very clean, simple, well-tested and composable core based on purely functional constructs and immutable data. The core will provide a solid ground for the micro-frameworks, which should land in Finch 2.0.

This document consists of two parts. The first part presents a high-level picture of Finch 1.0. The second part describes required steps we, Finch contributors and maintainers, have to make in order to bring the library to its first stable version.

One Abstraction to Rule Them All

Looking at the current API, one can find a slight correlation between Routers and RequestReaders. They both take a request and produces a value of type A from it. They both functions: HttpRequest => A. Keeping that in mind, [the idea of composing them ][2] into a single thing (perhaps Router) has found its supporters. The next reasonable step would be to completely merge those abstractions into a sing

vkostyukov

Finch: A Life Without Exceptions

Historically, Finch's error handling machinery was built on a very simple yet silly idea that an Endpoint may return a failed Future (i.e., Future.exception). While that doesn't really promote a purely functional approach to error handling (i.e., treat errors as values), it enables quite a few handy setups, including:

• embedding 3rd-party Finagle clients (that may fail) within endpoints w/o extra boilerplate
• simple/minimal required endpoints (i.e., body, param, etc) that return A, not Try[A] nor Either[Error, A]

However this part of Finch's design was heavily influenced by Finagle itself (w.r.t. embedding all of its failures in Future.exception), nothing stops us from revisiting this trade-off and possibly discussing paths forward more idiomatic error handling.

Implicit Errors vs. Explicit Errors

vkostyukov

public interface com.twitter.finagle.stats.StatsReceiver {
  public static com.twitter.finagle.stats.Counter counter$(com.twitter.finagle.stats.StatsReceiver, java.lang.String...);
  public com.twitter.finagle.stats.Counter counter(java.lang.String...);
  public static com.twitter.finagle.stats.Counter counter$(com.twitter.finagle.stats.StatsReceiver, com.twitter.finagle.stats.Verbosity, java.lang.String...);
  public com.twitter.finagle.stats.Counter counter(com.twitter.finagle.stats.Verbosity, java.lang.String...);
  public static com.twitter.finagle.stats.Stat stat$(com.twitter.finagle.stats.StatsReceiver, java.lang.String...);
  public com.twitter.finagle.stats.Stat stat(java.lang.String...);
  public static com.twitter.finagle.stats.Stat stat$(com.twitter.finagle.stats.StatsReceiver, com.twitter.finagle.stats.Verbosity, java.lang.String...);
  public com.twitter.finagle.stats.Stat stat(com.twitter.finagle.stats.Verbosity, java.lang.String...);
  public static com.twitter.finagle.stats.Gauge addGauge$(com