Setting up a Shopify dev environment

I’ve recently taken over maintaining a Shopify store, and it’s been a pain. They seem to expect you to edit your theme files from their web editor, directly into your production store. I searched around for a way to set up a dev environment in Shopify, but the best solutions offered very little improvement over editing in the browser. So I’ve stitched together something that works well enough. It took me longer than it should have to figure out what to do, mostly because I just couldn’t believe there wasn’t some other way.

(more…)

Rendering Backbone collections in a view

Best practices in Backbone.js seem to come up a lot. If you do much searching for how to do something using Backbone, you’ll quickly come to someone on StackOverflow asking “what are the best practices for” doing whatever you’re trying to figure out how to do. That’s because Backbone, in spite of being billed in some circles as an MVC framework, is really just a library. It’s a powerful library, but it holds almost no opinions about how you should structure your application, or what the relationship between the various prototypes it provides (That’s Model, Collection, View, and Router, plus a few supporting mixins) should be. You’re not writing a Backbone app, you’re writing JavaScript with a few helpful abstractions.

So in the absence of opinionated software, developers come up with lots of rules for themselves, and then other developers try to find out what they are by asking about best practices. It’s the circle of life. And Backbone, after a few years on the scene, has accumulated a fair amount of wisdom in the form of best practices. The problem is that we still seem to be in that awkward time when there are lots of things we’re supposed to be doing, but not much in the way of automating those things.

Take, for example, rendering a view that has a collection attached to it. Here’s an article that sums up the process pretty well (look under “Views should keep track of the sub views”). The issue that the article addresses is that when a view’s data source is a collection, each model within the collection should have its own view, and that the collection’s view should know about the models’ views. The author keeps track of the sub-views in a pseudo-private property, and adds and removes them with view callbacks when the collection’s add and remove events fire.

As a side note, be careful about using the example code as-is. It contains some bugs. Most notably, his “removeOne” method:


removeOne: function(ticket) {
	this._viewPointers[ticket.cid].remove();
}

See the problem? He calls the view’s remove method, but when the collection’s view is re-rendered, the deleted view will be right back there again, since it’s still in the array of cached views. Presumably the app he copied the code out of handled this differently, but for our purposes we can just add another line that deletes the reference:


removeOne: function(ticket) {
	this._viewPointers[ticket.cid].remove();
	delete this._viewPointer[model.cid];
}

Anyway, the author of the article, who is listed as “Prateek,” starts off by saying “The most common backbone pattern is to have a model and a collection of models and initialize a view that initializes this collection.” My response is, if it’s so common, why do I have to write so much code to make it happen?

(more…)

Switching the WordPress database between local and remote

I use MAMP to develop and test PHP applications, including WordPress. It’s a great tool, and it definitely solves more problems than it creates, but developing locally does have a few drawbacks when it comes to WordPress.

To start with, the database in production changes all the time. So when you need to add a feature, you’re probably starting with old content. Sometimes that doesn’t matter, but sometimes you’re trying to fix a bug that has to do with how current data is being displayed, or you need to fix the particular custom field that being used. It’s a problem often enough that it can be a point of pain.

So you go into phpMyAdmin, do a backup of the database, import it into your local database, and then you have to go into your local phpMyAdmin panel and manually change two options that contain the url of the site to your local url (http://localhost:8888 or something like that).

Once you’re done, you might have made changes to the database that need to be copied to the remote version. Maybe you’re using the advanced custom fields plugin, and you’ve added a new field for your “Events” custom post type. Now you have to go back to the remote version of WordPress and do exactly the same thing you just did locally, or you need to do the reverse of what you did before, changing the options back to the remote url, exporting the local version of the site, and importing it in production.

If this happens often, which I’ve found to be the case, it can become a huge waste of time. Enter the command line!

(more…)

Hello World?

The first “Hello World!” you write in any programming language is a thrilling thing, if you’re disposed to think of it that way. You’ve given birth to something. I always imagine the little script blinking in the sunlight, marveling at everything there is to see, and printing that string to the console exuberantly.

It makes sense that WordPress would name its default first post Hello World, but the truth is that that newborn blog usually lingers, neglected, before finally dying. Most blogs are never read, and most bloggers abandon them before they’ve written much, because writing is hard. So with that in mind, I’d like to address for myself what the purpose of this blog is.

(more…)

More

Browse the archive