For excessively paranoid client authentication.
Updated Apr 5 2019:
because this is a gist from 2011 that people stumble into and maybe you should AES instead of 3DES in the year of our lord 2019.
some other notes:
scala> trait Forall[F[_]]{ def apply[A]: F[A] } | |
defined trait Forall | |
scala> type ListFun[A] = List[A] => List[A] | |
defined type alias ListFun | |
scala> object Reverse extends Forall[ListFun] { def apply[A] = _.reverse} | |
defined module Reverse | |
scala> Reverse[String](List("1", "2")) |
RDBMS-based job queues have been criticized recently for being unable to handle heavy loads. And they deserve it, to some extent, because the queries used to safely lock a job have been pretty hairy. SELECT FOR UPDATE followed by an UPDATE works fine at first, but then you add more workers, and each is trying to SELECT FOR UPDATE the same row (and maybe throwing NOWAIT in there, then catching the errors and retrying), and things slow down.
On top of that, they have to actually update the row to mark it as locked, so the rest of your workers are sitting there waiting while one of them propagates its lock to disk (and the disks of however many servers you're replicating to). QueueClassic got some mileage out of the novel idea of randomly picking a row near the front of the queue to lock, but I can't still seem to get more than an an extra few hundred jobs per second out of it under heavy load.
So, many developers have started going straight t
Standard design patterns in scala recommend the cake pattern to help compose larger programs from smaller ones. Generally, for simple cake layers, this works okay. Boner's article suggests using it to compose repository and service layers and his focus is on DI-type composition. As you abstract more of your IO layers however, you realize that you the cake pattern as described does not abstract easily and usage becomes challenging. As the dependencies mount, you create mixin traits that express those dependence and perhaps they use self-types to ensure they are mixed in correctly.
Then at the end of the world, you have to mix in many different traits to get all the components. In addition, perhaps you have used existential types and now you must have a val/object somewhere (i.e. a well defined path) in order to import the types within the service so you can write your program. Existential
import cats.effect.ExitCase._ | |
import cats.effect.Sync | |
import cats.effect.concurrent.Ref | |
import cats.syntax.flatMap._ | |
import cats.syntax.functor._ | |
trait Tap[F[_]] { | |
def apply[A](effect: F[A]): F[A] | |
} |
import cats.implicits._ | |
import cats.effect.ExitCase.{Completed, Error} | |
import cats.effect.{ExitCode, IO, IOApp} | |
import cats.effect.concurrent.Ref | |
import eu.timepit.refined.api.{Refined, RefinedTypeOps} | |
import eu.timepit.refined.numeric.Interval | |
import eu.timepit.refined.W | |
import eu.timepit.refined.types.numeric.PosInt | |
import fs2.concurrent.Queue |
import cats.Applicative | |
import cats.data.NonEmptyList | |
import cats.effect.Concurrent | |
import cats.effect.concurrent.{Deferred, Ref} | |
import cats.implicits._ | |
import fs2.concurrent.{InspectableQueue, SignallingRef} | |
import fs2.{Chunk, CompositeFailure, Scope, Stream} | |
object StreamPriorityUtils { |