soareschen

'use strict'

var Nedb = require('nedb')
var urlLib = require('url')
var httpLib = require('http')
var express = require('express')
var MongoClient = require('mongodb').MongoClient

var useExpress = true
var useMongo = true

soareschen

/*
 * This is an experimentation example of 
 * the new component definition DSL for Quiver.
 * Here we will define a simple hello handler
 * with a few middleware to transform the 
 * input/output.
 *
 * - The base handler get the name as text from
 *   standard input stream and output the greeting
 *   with "hello" in front of the name.

soareschen

/*
 * This is a DSL experiment to build
 * abstract syntax trees (AST) in Javascript.
 * In this example we provide a simplified 
 * use case of building expression AST.
 *
 * The expression AST built here are
 * equivalent to the following mathematical
 * expressions:
 * 

soareschen

/*
 * Begin Define
 */
require('quiver-define')
  .namespace('my-namespace') // compulsory

// Using Directive
  .using('other-namespace::component-name')
  .using(require('other-module'))
  .using([

soareschen

'use strict'

var timeoutPromise = function(timeout, construct) {
  return new Promise(function(resolve, reject) {
    construct(resolve, reject)

    setTimeout(function() {
      reject(new Error('timeout error'))
    }, timeout)
  })

soareschen

package main
 
import (
  "fmt"
  "time"
  "net/http"
)
 
type handlerFunction func(
    res http.ResponseWriter, 

soareschen

Quiver Architecture For The Front End

Despite my lack of experience in HTML front end development, I am already itchy to step a foot in and try to create new front end architecture. Is my non-expertise a benefit or red flag? I really don't know.

I find the higher order constructs in Quiver - builder, filter, middleware, component - to be a very robust and general architecture that can be applied to wide range of applications, including GUI apps and perhaps even rendering engines. So let's see how a HTML app can can be defined based on Quiver:

Template

function template(model) => VirtualDOM

soareschen

Zsh scripts leave defunct processes when running under docker exec

This only happens when the script is running inside a shell spawned by docker exec. When running under bash or under docker run, there is no defunct process.

This bug is first discovered when I run nvm in docker (creationix/nvm#650). It was then discovered that Docker's nsenter did not properly handle the SIGCHLD signal raised from zsh. (docker/libcontainer#369) Even though it is now been fixed by Docker, I am not sure why zsh would cause this bug in the first place.

Steps to reproduce:

# terminal 1

soareschen

package main

import (
	"fmt"
	"strings"
)

type Base interface {
	Foo() string
	Bar() string

soareschen

Managing State in React

After digging more into React I get a better idea on how React states work. It looks like React still have a bit of magic happening behind the scene to make states work.

// 3 Elements mapping to the same real DOM
var element1 = <MyElement awesome=true>My Awesome Content</MyElement>

var element2 = <MyElement awesome=false>My Boring Content</MyElement>