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 part one 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.
We’ll look at what this enables in later posts; for now, here’s the workflow itself….
This is the obligatory first post on my tech blog.
I’ll blog mainly about Web UI development, and will also cover other tech topics as they arise.
I’ve been meaning to start a blog for years. Hopefully I’ll get this off the ground & keep it aloft.