Backbone+Leaflet+Instagram = Instamapstagram

As part of a weekend-long “clear out the cobwebs” dive back into backbone, I threw together a little sample app to plot Instagram photos on a map. I also decided it should have the stupidest name possible - thus, Instamapstagram!

Drag the circle to kick off a search, click the little crosshairs to zoom to your location, drag the photo markers themselves to get a better view, etc etc. It’s missing some basic functionality, like popups for the photos, that I may or may not get around to adding. Uses Stamen’s beautiful toner tiles to a fairly nice effect - I like the counterpoint of the very minimal, black and white-ness of the basemap and interface with the colorful Instagram photos.

This has been done before, most recently by Instagram itself; all the same, it struck me as a fun little thing I could bang out in a weekend to reinvigorate the backbone portions of my brain.

It was quite a useful excercise - I went into it with the goal of shooting for reusable, modularized components, and ended up having to think very carefully about how that could be achieved using backbone against another library like Leaflet. By the end of the sprint, some concessions were being made in the interest of seeing every map maker’s most favorite thing - some points on a map - but I think with a little refactoring it could be a good jumping off point.

It’s also raised some questions on just how to stuff more functionality into a map driven application without going too crazy on the interface. I like the simplicity of the full screen map - and the fact that with Leaflet it works on mobile devices right out of the box - but that kind of puts an upper limit on just how intricate your interface can get, unless you start getting creative and hiding bits of it in a container. I guess sooner or later I’ll have to start experimenting with mixing in some other elements, especially since that kind of subview rendering in backbone is something I want to practice, but for now I’m kind of liking the minimal approach.

The whole excercise has led me to think that Instagram + maps is an interesting combo that would be fun to play around with some more. Off the top of my head, I can see that this app would be quite a bit more useful if it had some notion of time - some way to refine your media searches not just by location but date as well. Then you could do something like drop the circle on a festival you went to last week and see some other photos from it. It’d also be nice if I could just see all of my photos on a map, maybe with a nice density-visualizing heatmap or some clusters. And boy would I really like to play around with their realtime API… all in good time I suppose.

Anyway, the code is all on Github so if you’ve read this far, feel free to fork away should the spirit take you.

I answered a question on StackOverflow a few weeks back with a walkthrough showing how to implement the Where operator yourself, using the language features LINQ is built on.

I’m certain I stole this example from somewhere but nevertheless, I’ve used it a couple times to help reduce some of the magical aspects of LINQ for new developers and I like it quite a lot, so I thought I’d post it here for posterity/eventual cleanup and detail. I leave out quite a bit in this version that could be expanded on, like exactly what “yield return” is doing in the final implementation - I may come back and fill that in when I find the time.

Say we’ve got an array of Things, and we want to write a method to help us figure out which of those Things are awesome. Here’s one way we could do it:

1
2
3
4
5
6
7
8
9

static IEnumerable<Thing> ThingsThatAreAwesome(IEnumerable<Thing> things){
    List<Thing> ret;
    foreach (Thing thing in things) {
        if (thing.IsAwesome)
            ret.Add(thing);
    }

    return ret;
}

Which we would then call like this:

1
2

List<Thing> myThings;
List<Thing> myAwesomeThings = ThingsThatAreAwesome(myThings);

So that’s pretty keen. We’re just iterating over our list of things, seeing which of them are awesome, and then returning the ones that meet our awesome criteria. But semantically it doesn’t really do it for us - our awesome filter is so awesome that we want to be able to just walk up to a list of Things and call our operator on it, as if it were an instance method on IEnumerable itself.

And so that’s where extension methods come in. Through some compiler trickery, they give us the ability to “extend” types. So like you said, by putting “this” in front of the IEnumerable parameter of our method, we can now walk up to our list of things and ask it to filter itself like this:

1

List<Thing> myAwesomeThings = myThings.ThingsThatAreAwesome();

So - that’s where extension methods fit in. Next is the “predicate”.

So we’ve got our magnificent, awesome filter, and it’s great, but then we have a brain explosion: with a little bit of abstraction, that method we just wrote could be used to filter anything. Not just lists of Thing objects, and not just filtering on things that are awesome.

Making it work with any type is fairly easy, we just make it a generic operator with IEnumerable<T>, rather than IEnumerable<Thing> - but making it filter on any criteria is trickier. How is the method supposed to know how to filter any type? It obviously can’t - our calling code will have to tell it exactly what we mean by “filter” - what kind of filter we want. And so we give it a second parameter, a function pointer, that expresses just what we’re after. We’ll call that our “predicate”, which is just a way of saying a chunk of code that returns true or false. When all is said and done, it looks a little like this. We’ll rename the method to “Filter”, since that better expresses what we’re going for now:

1
2
3
4
5
6

static IEnumerable<T> Filter(this IEnumerable<T> list, Func<T,bool> predicate) {
    foreach (T item in list) {
        if (predicate(item))
            yield return item;
    }
}

You can see that we’re not really doing anything different from our Awesome filter method before - we’re still just iterating over a list, performing some kind of check, and returning the items that pass that check. But we’ve given ourselves a way for calling code to express exactly what that “check” should be.

We’re basically still only doing two things: iterating over a list, and running some kind of check over every item in that list - the items that pass the check get passed back. Except now the method doesn’t really know what the check it’s running looks like - we are telling it, passing that piece of code in as a parameter, our predicate, rather than hard coding it into the method itself. We leave it up to the caller to decide what they want their filtering criteria to be.

So at this point, we’ve basically got the LINQ Where operator - we can now run queries over any type of collection, all with the same method. If you’ve not messed around with lambdas yet, don’t worry about it - just know it’s a very succinct way of expressing a bit of code, which in this case is telling our filter method what we want to filter on:

1
2
3
4
5
6
7
8
9
10
11
12
13

List<Thing> myThings;
List<Cats>  myCats;

var myAwesomeThings = myThings.Filter(thing => thing.IsAwesome);
var myCrazyCats = myCats.Filter(cat => cat.IsCrazy);

foreach (var thing in myAwesomeThings){
    Console.WriteLine("This thing is awesome! {0}", thing);
}

foreach (var cat in myCrazyCats){
    Console.WriteLine("This cat is crazy! {0}", cat);
}

Octopress, YAY.

Keeping with the tradition of using one of your first posts on your new Octopress blog to blog about how you set up your new Octopress blog, here are some notes.

I’ve had to do this twice now, both times with some small amount of goofiness, but all in all quite an untroubled installation, considering I know nothing about Jekyll/Ruby and am not git’s most favorite person in the world. These were my general steps for getting things up and running on a span brankin’ new MacBook Air.

First, install git. Self explanatory, really. Although I did run into some funny business installing Git manually vs through Homebrew, vs some older version that was installed when I downloaded XCode - generally, I’d recommend just saving yourself some trouble and getting it from Homebrew to begin with.

As an aside: in switching to a new, more professionally aliased GitHub account, git had something of a tantrum and was having difficulty letting go of my old user name. I changed the global git config, which did absolutely nothing. Finally I deleted my old ssh keys, generated new ones, and ran ssh-add, and that seemed to do the trick, so git is off my shit list - for now.

Next was installing rbenv and ruby-build. Again, Homebrew to the rescue here. They both installed with pretty much no hassle.

Of note was that I went with rbenv instead of rvm because it seems the latter has fallen out of favor as of late, at least that’s what I inferred from this tweet.

Next is setting up your repo on GitHub. If you’re starting a user site, don’t do what I did and spend an hour trying to figure out why your repo called “username” isn’t building a proper Github page and is messing up all of Octopress’ rake tasks and generally nothing is working - make a repo named “username.github.com”, like you’re supposed to, otherwise, you’ll feel really dumb.

Now you’ll setup your local directory, ie, some folder on your machine called “MyAwesomeBlog” - then use rbenv to set the local ruby version to Octopress’ preferred flavor, the esoterically named “1.9.2-p290”:

1

rbenv local 1.9.2-p290

It’ll probably tell you that it’s not been installed yet, silly, which you can do with

1

rbenv install 1.9.2-p290 

You can check that all is well in ruby-land with

1

rbenv local

Okay, now comes the fun stuff. “Install” Octopress by cloning it into the local directory you’ll be using to house your blog, ie

1

git clone git://github.com/imathis/octopress.git MyAwesomeBlog/

All done? Get those delicious dependencies with bundler!

1
2

gem install bundler #if you've not installed it already
bundle install

From this point, it’s pretty much smooth sailing. Work your way through the documentation, use the super convenient rake tasks to install the default theme and setup github pages…

Then do a rake generate! Then a rake deploy! Then browse to username.github.com and gaze upon the splendidness of the base, unadorned octopress theme! Then do a happy dance, because everything is working splendidly, and you are obviously splendid, etc etc. (I recommend playing this song for this part).

Then install a new theme, because rolling with a basic, untouched octopress design is like, so 2011. Update your _config.yml with your name and super clever title and BOOM. You’re pretty much good to go.

Testing testing…

Is this thing on?