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....
I occasionally use GitHub gists to display blocks of code in some blog posts. Recently, I found out that the normal way of embedding a gists in a page doesn't work for HTML5 applications like this blog's [former] small Backbone client application. I found a few different ways to handle this, and put together bits & pieces of different solutions to come up with something that is both simple & works well. I made a small jQuery plugin named jquery.ajax-gist (GitHub) so I could use the code in different applications.
In [object Object], we looked at how to attach a Marionette view to the existing HTML for a navigation bar. There, we didn't need to replace the HTML; we just needed to augment it to handle click events.
This post will consider the case where we want to be able to replace the existing HTML at a later point in time. This blog page itself is an example use case: the blog is a small Marionette application, and it's View class attaches to the existing server-rendered content on startup. If you clicked a link to another blog page, another View class would take over and replace the server-rendered text with text for the new page.
HTML5 web applications frequently need to attach a view class to existing HTML. For example, the server-side piece of the application often renders a navigation bar and some other basic page elements. Some applications even render the first page's content so the Marionette application won't have to make a separate request for its initial content.
In this situation we'll usually want to attach a Marionette or plain Backbone view class to some of the existing HTML. The view is a convenient high-level mechanism for handling events and performing other UI-related tasks. That's enough of a reason to create a view even if we don't need the view to render new HTML. A navigation bar view class, for example, might handle click events, dynamically update the navbar's menu items, and maybe set up a handler for a search box.
With Backbone & Marionette, it's easy to accomplish this.
This workflow is the core of my daily work in git.
- There's more here than the bare minimum needed to work in git, but...
- This workflow enables us to do more later, and to work more productively.
We'll look at what this enables in later posts; for now, here's the workflow itself....