jhorneman

character_replacements = [
    ( u'\u2018', u"'"),   # LEFT SINGLE QUOTATION MARK
    ( u'\u2019', u"'"),   # RIGHT SINGLE QUOTATION MARK
    ( u'\u201c', u'"'),   # LEFT DOUBLE QUOTATION MARK
    ( u'\u201d', u'"'),   # RIGHT DOUBLE QUOTATION MARK
    ( u'\u201e', u'"'),   # DOUBLE LOW-9 QUOTATION MARK
    ( u'\u2013', u'-'),   # EN DASH
    ( u'\u2026', u'...'), # HORIZONTAL ELLIPSIS
    ( u'\u0152', u'OE'),  # LATIN CAPITAL LIGATURE OE
    ( u'\u0153', u'oe')   # LATIN SMALL LIGATURE OE

jhorneman

# web_page_logger.py

import logging

class WebPageHandler(logging.Handler):
    def __init__(self):
        logging.Handler.__init__(self)
        self.messages = []

    def emit(self, record):

jhorneman

# -*- coding: utf-8 -*-

import sys

# Based on http://stackoverflow.com/a/4896288 - modified to use Gevent

ON_POSIX = 'posix' in sys.builtin_module_names


def enqueue_output(_output_stream, _queue):

jhorneman

float rawBytesToFloat(char* _buffer)
{
	unsigned int rawValue = asio::detail::socket_ops::network_to_host_long(*((unsigned int*) (_buffer)));
	return *(reinterpret_cast<float*>(&rawValue));
}

jhorneman

//  main.cpp
//  timestamp_test
//  Created by Jurie Horneman on 29/06/14.

#include <assert.h>
#include <iostream>


// Adapted from "A portable high-resolution timestamp in C++" by Edouard Alligand
// https://blogea.bureau14.fr/index.php/2014/06/a-portable-high-resolution-timestamp-in-c/

jhorneman

import requests

def check_link(_url):
    _url = _url.strip()
    if not _url:
        return

    if not _url.startswith('http://'):
        _url = 'http://' + _url

jhorneman

Async data loading in Flux

I've been working with Flux a lot recently, and one of the questions I've been struggling with is in which part of the Flux cycle to put my asynchronous data requests.

Here are some different opinions:

The diagram

The famous Flux diagram puts them in the action creators.

The chat example

jhorneman

How to combine the Flux pattern with large hierarchical data

I've been converting the web client part of an application I'm developing for a client from plain old JavaScript to React and Flux. (Because this is closed-source client work, I will be a bit vague about what the application is and does.)

Something about my data, my use case, and how I've implemented things, or some combination of those three, doesn't fit the Flux pattern well. So I am writing this to explain my problem and hopefully get some interesting feedback on it. (If you're reading this: thanks.)

The application

I have a Python server which talks to a PostgreSQL database and provides data in JSON format over a REST-ish API (not pure REST, more RPC-style).

jhorneman

// The Q 'coming from jQuery' wiki page (https://github.com/kriskowal/q/wiki/Coming-from-jQuery) says the following:
//
//     "So if you are used to writing code like
//      $.ajax(...).then(function (data, status, xhr) {
//          console.log(data, status, xhr);
//      });
//      when transitioning to Q [...] you should assume they only return a single object"
//
// That is all well and good, but doesn't address how to access the multiple parameters jQuery sends, and which
// can be important.