matthiasg

version: '2'

volumes:
    node_modules:

services:
  base:
    image: node:10
    volumes:
      - .:/usr/src/service

matthiasg

#Mobile Device Detection via User Agent RegEx

Yes, it is nearly 2012 and this exercise has been done to death in every imaginable language. For my own purposes I needed to get the majority of non-desktop devices on to a trimmed down, mobile optimized version of a site. I decided to try and chase down an up-to-date RegEx of the simplest thing that could possibly work.

I arrived at my current solution after analyzing 12 months of traffic over 30+ US based entertainment properties (5.8M+ visitors) from Jan - Dec 2011.

The numbers solidified my thoughts on the irrelevancy of including browsers/OSes such as Nokia, Samsung, Maemo, Symbian, Ipaq, Avant, Zino, Bolt, Iris, etc. The brass tacks of the matter is that you certainly could support these obscure beasts, but are you really going to test your site on them? Heck, could you even find one?! Unless the folks that pay you are die hard Treo users my guess is "No".

Interestingly enough my research shows that /Mobile/ is more efficient than **/iP(

matthiasg

{
  "main": "dist/allServicesWrappedByOneService.umd.min.js",
  "exports": "service"
}

matthiasg

#include <cmath>
#include <assert.h>
#include <core/TestPattern.h>


TestPattern::TestPattern() 
  :w(0)
  ,h(0)
  ,frame_num(0)
  ,duration(0)

matthiasg

matthiasg

// _decimal.scss | MIT License | gist.github.com/terkel/4373420

// Round a number to specified digits.
//
// @param  {Number} $number A number to round
// @param  {Number} [$digits:0] Digits to output
// @param  {String} [$mode:round] (round|ceil|floor) How to round a number
// @return {Number} A rounded number
// @example
//     decimal-round(0.333)    => 0

matthiasg

Given a schema with three entities cases,products,noxe where cases and products link to noxe via field data__noxe and where the type noxe is a union of two major versions Noxe_v1 and Noxe_v2.

If the noxe should be filtered (by parent AND other properties) then the code to filter might be duplicated if put into the resolvers naively. The code can be easily be factored out but the duplication in the arguments remains AND is complicated by the fact that different filters might be needed for different versions of Noxe.

Looking at the line 4: data__noxe(match:"some n2") { we can see an argument data__value which is supposed to define a filter on field data__value. When adding another filter only present in one of the versions data__noxe(data__value:"eq:some n2" data__sometext:"contains:some") {

matthiasg

var pg = require('pg');
var faker = require('faker');
var Promise = require('bluebird');
var uuid = require('node-uuid');

// create a config to configure both pooling behavior
// and client options
// note: all config is optional and the environment variables
// will be read if the config is not present
var config = {

matthiasg

frontend https-in
    mode tcp
    bind *:443 ssl crt /etc/ssl/dummy.pem alpn h2,http/1.1
    use_backend nodes-http2 if { ssl_fc_alpn -i h2 }
    default_backend nodes-http

backend nodes-http
    server node1 web.server:80 check

backend nodes-http2

matthiasg

{  
  "query":{  
    "has_child":{  
      "query":{  
        "function_score":{  
          "functions":[  
            {  
              "field_value_factor":{  
                "factor":1,
                "field":"count"