DaveDeCaprio

import java.net.URI
import java.util.Locale

import akka.NotUsed
import akka.actor.ActorSystem
import akka.http.scaladsl.Http
import akka.http.scaladsl.model.headers.RawHeader
import akka.http.scaladsl.model.ws._
import akka.http.scaladsl.model.{HttpHeader, Uri}
import akka.stream.ActorMaterializer

OlegIlyenko

In this gist I would like to describe an idea for GraphQL subscriptions. It was inspired by conversations about subscriptions in the GraphQL slack channel and different GH issues, like #89 and #411.

Conceptual Model

At the moment GraphQL allows 2 types of queries:

• query
• mutation

Reference implementation also adds the third type: subscription. It does not have any semantics yet, so here I would like to propose one possible semantics interpretation and the reasoning behind it.

turtlemonvh

from django.conf import settings


class MultiPortMiddleware(object):
    """
    Middleware changes the SESSION_COOKIE_NAME to use the current port in the name
    """

    def process_request(self, request):
        settings.SESSION_COOKIE_NAME = 'sessionid' + request.META['SERVER_PORT']

momer

package main

import (
    "myapp/webserver/app/common"
    "github.com/golang/glog"
    "github.com/gorilla/mux"
    "encoding/json"
    "strconv"
    "flag"
    "fmt"

staltz

The introduction to Reactive Programming you've been missing

(by @andrestaltz)

---

This tutorial as a series of videos

If you prefer to watch video tutorials with live-coding, then check out this series I recorded with the same contents as in this article: Egghead.io - Introduction to Reactive Programming.

---

rponte

package rponte.report;

import java.io.FileNotFoundException;
import java.io.FileOutputStream;
import java.sql.Connection;
import java.sql.SQLException;
import java.util.HashMap;
import java.util.Map;

import net.sf.jasperreports.engine.JRException;

nf

var cluster = require('cluster');
var http = require('http');
var numCPUs = require('os').cpus().length;

if (cluster.isMaster) {
  // Fork workers.
  for (var i = 0; i < numCPUs; i++) {
    cluster.fork();
  }
  cluster.on('exit', function(worker, code, signal) {

szinck

from sqlalchemy import create_engine
from sqlalchemy.ext.declarative import declarative_base
        
engine = create_engine("postgresql://user:@host/schema")
Base = declarative_base()
Base.metadata.reflect(engine)

fernandoaleman

## Configure eth0
#
# vi /etc/sysconfig/network-scripts/ifcfg-eth0

DEVICE="eth0"
NM_CONTROLLED="yes"
ONBOOT=yes
HWADDR=A4:BA:DB:37:F1:04
TYPE=Ethernet
BOOTPROTO=static

jboner

Transactors: Actors + STM

Actors are excellent for solving of problems where you have many independent processes 
that can work in isolation and only interact with other Actors through message passing. 
This model fits many problems. But the actor model is unfortunately a terrible model for 
implementing truly shared state. E.g. when you need to have consensus and a stable view of 
state across many components. The classic example is the bank account to clients to 
deposits and withdrawals in which each operation needs to be atomic. For detailed 
discussion on the topic see this JavaOne presentation: 
http://www.slideshare.net/jboner/state-youre-doing-it-wrong-javaone-2009.