This past year working on Holo-REA has been a fascinating, exciting and occasionally overwhelming foray into the evolution of distributed systems. In that time, a small group of contributors has managed to prototype a robust economic ledger which not only manages supply chain tracking, but also facilitates complex operational planning and business process management.

It is truly a simple and elegant solution to numerous economic and resource coordination activities. But, that was already known— this is the second (some would say third) generation of an existing system that has been proven in multiple real-life case studies.

(more)

(A report from the first Holochain intensive / unofficial ValueFlows festival.)

Last weekend the first ever Holochain intensive was held on the Sunshine Coast in Australia. You'd be forgiven for wondering why that location was chosen - we don't usually get much attention from the tech industry down here compared to places like California - but for whatever reason there's a significant number of Aussies interested and involved in the Holochain ecosystem. Basically it happened here because enough of us came together to make it happen.

I'm dubbing it the "unofficial ValueFlows festival" because REA accounting was particularly dominant over the weekend, front and center in a lot of sessions and the thing that most people there seemed to be focused on. As the resident "expert" I wasn't really prepared for how many of the presentations and workshops I would be facilitating or how many conversations I would be having about it. This is largely due to Holochain's founder Art having been turned on to REA by Bob and Lynn of Mikorizal and championing those concepts to groups interested in building on the platform. (more)

With development of blockchain applications now booming there are many interesting things happening and a lot of reasons to be excited for 2018. Unfortunately, there are a lot of reasons to be pessimistic too. Many are approaching application development in the same ways they always have, which in an open global system runs at odds with the design and ethos of the very ground they're walking on.

Creating an open-source platform designed to work as part of a globally integrated system is a very different process than building a product or enterprise platform to be monetized through licensing and sales. In this article, I'll attempt to explain why this is the case and give some tangible rules to guide you on your journey to creating the next killer blockchain app. I'll focus on Ethereum, but the same ideas apply to any public global system. (more)

A couple of months ago I gave a technical talk about blockchains at a local Ethereum meetup. The presentation is essentially a knowledge remix of all the publicly available Solidity reference material with some software engineering concepts, architectural suggestions, challenges and detailed breakdown of the DAO hack thrown in for good measure.

You can view slides from the talk here or over on github. If you've ever wanted to get started writing software for Ethereum - or blockchains in general - then I highly recommend you take a look and save yourself some research!

(more)

Lately I've been rebuilding a lot of servers and workstations, and so one of the many things I've been trying to find the time to work on is basket.

Originally started as one of those random in-office projects, my coworkers and I have taken it upon ourselves to extend that flaky set of bash methods and maybe turn it into a useful set of low-level server administration utilities. It's difficult to say yet how much functionality we'll provide - the project is very much in its infancy - but it's starting to look like a sensible and robust enough idea that I'm posting about it here. From the readme:

It's a bash thoole ket, or bash toolkit if you're sober. Yeah, we tried. It's also a basket of bash functions so that kinda works.

Basket is like a basket because you can dump little scripts into it with no overhead other than storage. When sourced, only the main (small) basket of bash helper methods is loaded - special-purpose modules are brought in on demand and have a simple dependency management system. (So if basket ever gets too big, you can just blindly delete stuff you don't need out of the lib folder). (more)

Recently I've been doing a lot of responsive sites for clients. They're fun and often challenging things to work with; opinions and solutions from various developers and designers scattered liberally throughout the internet. So I suppose it's about my turn to chime in on it all. (more)

JSON schema is the modern equivalent to XSchema/DDML or the good old ancient DTDs. It provides a lightweight, self-describing and abstract protocol for describing and validating data formats and models. There are validator implementations in many languages, but the most obvious use is in pre-send validation for frontend JavaScript applications. A good validator and some simple wrappers or data binding (like say, this...) and you can code up a complex and powerful new application in days.

Its simple JSON structure and savviness of the community has thus far kept any kind of introductory documentation from cropping up, instead one must simply read through the spec and digest it for themselves. Since this is a time-consuming process, I did up a quick cheatsheet of the properties involved in schema declarations so that once one understands the basic principle you don't have to go back and check for what the name of something was repeatedly. (more)

Generally, I take it upon myself to push git onto other developers wherever I go. It is a wonderous, joyful world where your work is never impeded by a network connection and everything is far more powerful and flexible. Often you hear "why would I ever want to move away from Subversion?", which is a bit like saying "why would I ever want to stop riding a horse to work", but that's a topic for another post. This page is a first-stop manual for those new to working in teams or working with git, and lays out some good practises you'll probably want to follow early on until you become a more advanced user. (more)

Sometime recently I wanted to make some sweet-ass parallax stuff. Fun times would be had, but what a lot of effort it was going to be.

There were several great solutions out there, and I eventually decided upon jparallax as being the most complete. However, that still didn't allow me the flexibility I wanted - I needed to be able to do more than just move elements, I wanted to stretch parts of my parallax to achieve faux-sideon perspective. And then I started thinking about other things you could do, and decided the best way to approach such an engine would be to allow modification to any css property and decide what effects were workable later.

The other thing I generally have a problem with in JavaScript animation in general is 'the stutter'. You don't get it constantly, and on modern browsers / faster machines not at all, but for those of us on laptops and phones the stutter in our animation ruins the fuildity of the experience we're trying to create. CSS transitions are there and are supported by all the major browsers now (except, of course, IE (edit: IE10 does support them now)) so there's no reason not to be using them. Transitions run on the GPU in most cases, freeing up CPU resources being used to control the animation in JavaScript for other purposes and smoothing out animation by using framesyncing and other techniques only available on hardware.

Provided keyframe positions were known ahead of time or it didn't matter if there was a slight lag to the animation (indeed in many cases this can be appealing), there didn't seem to be any reason one couldn't leverage CSS transitions and the GPU to add fluidity to JavaScript animations updated at a low sampling rate. So that's exactly what I did with JCAnim and the parallax effect I implemented with it. (more)