Skip to content

Instantly share code, notes, and snippets.

View eboto's full-sized avatar

Erem Boto eboto

14 followers · 0 following
  • San Francisco Bay Area
View GitHub Profile
@eboto
eboto / play_modular_development_with_routes.md
Created November 26, 2012 19:58
Play 2.1 reverse route behavior with a module and an application that depends on it

Sample directory structure and file-contents for a one-module, one-app play build. It illustrates how routes compilation and resolution might work in a way that avoids namespace collision on the controllers.routes symbol (a bug in Play 2.0.x).

The initial version of this gist demonstrates the behavior of the pull request that solves that bug, authored by @jroper:

Though this solves a pretty huge problem in our company, the reverse router
syntax is a bit unsatisfying due to the awkward syntax of module reverse routes: controllers.module.module.routes.Module

@eboto
eboto / blah.scala
Created October 17, 2013 04:54
Some Either and Option fun
case class User(id: Long, name: String)
case class ZipCode(userId: Long, zipCode: String)
trait Error {
def message: String
}
case class UserError(message: String) extends Error
case class ZipError(message: String) extends Error
/*
@eboto
eboto / gist:d1c77f9d7b45ccaf4bd40fece609eae5
Created April 4, 2016 16:39
IPFS pub/sub proposal using object blocking
# Proposed poor-man's IPFS/IPNS pubsub
A rough proposal to implement the widely desired [pub/sub feature on ipfs](https://github.com/ipfs/notes/issues/64)
without requiring additional capabilities or message-passing behavior from the network or the clients. It could be
implemented as an IPFS application right now and in fact I've got sample JS that uses the js-http-api to do so
on the publish side. Hopefully building out the subscribe side this week.
I've just started diving into IPFS so this could be a super naïve approach.
The proposal's core concepts:
@eboto
eboto / ipfs-pubsub-object-blocking.md
Last active August 21, 2017 12:06

Proposed low-perf IPFS/IPNS pubsub

A rough proposal to implement the widely desired pub/sub feature on ipfs without requiring additional capabilities or message-passing behavior from the network or the clients. It could be implemented as an IPFS application right now.

I've just started diving into IPFS so this could be a super naïve approach.

The proposal's core concepts:

  • subscription is modeled as querying a non-existent block whose future multihash is known, but has not been added to the DAG.
@eboto
eboto / keybase.md
Created June 9, 2016 21:43

Keybase proof

I hereby claim:

  • I am eboto on github.
  • I am eremboto (https://keybase.io/eremboto) on keybase.
  • I have a public key ASBkbr-l6twgzlKwkAlYx38wSQsEy-Dn_t0qAL1w7UPaXQo

To claim this, I am signing this object:

@eboto
eboto / inner-future-exception.scala
Last active September 28, 2016 20:08
// If you create a Future inside another Future, the inner one
// will not log exceptions thrown in its body to the console.
//
// Why not?
//
// Example:
import scala.concurrent.ExecutionContext.Implicits.global
import scala.concurrent.Future
val fut = Future {