I'm intrigued by services like forestry.io and netlify that put a browser-based editor in front of a static site generator like hugo. Seems like that's what is needed to make static sites a compelling alternative to the traditional CMS.
I keep thinking of John Gordon's "How to build a safe and sane social network" this weekend. "Essentially it’s the public radio model." Intriguing.
Unlike the raw indieweb -- interesting ideas, but a science project -- Gordon's is a model that could actually be workable. It's a federation of nodes, where each node is used by multiple people. The tech people (let's call them "tinkerers") can run the nodes, while the non-tinkerers can participate either for free or for for a small donation.
The critical part is that it allows for easy use by non-tinkerers, aka "normal people."
Indieweb's weakest spots are exactly where the big silos add most value: effortless social connection, simple UX, and hiding the complex infrastructure.
One strong aspect of our React/Redux-based architecture has been the separation of concerns. When some code turns ugly, the damage is often contained in one small area.
Trying out the Hugo static site generator. So far I'm loving it. Wicked fast, easier to work with than everything else I've used.
I've found Amazon Echo "skills" SDK far too complex for simple IoT / smart home devices, and the resulting UX is awkward and poor. Built-in echo support for wemo switches is better -- and can be emulated for arduino devices. +1
The Amazon Echo = game changer for my Arduino projects: a voice interface for wifi-enabled ESP8266 devices. Fits the command-based devices best.
I've been using a small board called the Oak from digistump for deploying arduino home-automation devices around the house. The Oak is a great board with good wifi, but the Particle firmware has always been trouble: difficult to set up, random flaky behavior, etc.
At heart the Oak is an ESP8266 chip, and these days there's a lot of independent support for ESP8266. So when I found some notes in the Oak forum about removing the Particle firmware and using the ESP8266 core directly, I jumped at the chance to try it out.
I'm restarting this blog after a long period of inactivity.
I'm hoping that the IndieWeb ability to post here & syndicate on Twitter will make this blog more useful as the main place where I write.
I'm also going to post some more less-polished notes to significantly reduce the time it takes to create & edit posts.
When building a large-scale Backbone.js Single-Page Application (SPA), it's easy to make a mess.
If you don't take pains to avoid some common pitfalls, you'll likely end up with a codebase that's buggy, poorly structured, and hard to maintain.
Don't do that. :-)
Here are a handful of tips I've used when working on large-scale Backbone applications. They're simple principles that I use as basic architectural rules, and they've served me well on the Insight team at NetApp and elsewhere.
There are other important principles, too, but these are the ones that I use the most when figuring out new parts of an application, talking to team members, or reviewing code....