At SplashLab, our CMS application supports custom web forms. Each form has a different set of fields which hold different types of data. Email addresses, multi-select radio buttons, text areas, etc. Some forms only get submitted a couple of times. Some are submitted many thousands of times. The best way to store this data is something we are still working on, but I thought I would share how we are using MongoDb to solve this problem currently.

NOTE: This article was accidentally published before it was completed. It’s still not complete, but it’s close, so rather than take it down I’ll leave it up.

I do not practice Test Drive Design (TDD). I do try to fill in unit tests to code if I have time, for regression testing, but that is far from the ideals of TDD. I keep hearing great things about it though, and enjoyed a little crash course put on by the UtahJS user group. Part of a project I am working on at SplashLab is a standalone JS app for collecting web analytics. This seemed like a good time to try out some TDD.

Facebook is currently working on their new Graph Search product. It’s in invite-only Beta right now, but it will be rolled out to all users eventually. Facebook has a crack team of ex-Google employees working on it, and the demos are impressive.

Currently, Graph Search does not complete directly with Google and is not intended for general “informational”, keyword-based web searches. Rather, the idea is to tease interesting data out of social graph connections and relations, such as “who as likes to mountain bike where I work”, “what games do my friends play” and “best pizza place near me”. The Google+ “Search Plus Your World” product has a similar goal, enhancing search results with information from Google+, but it doesn’t support relational queries. The number of brands and restaurants on Facebook actually positions Graph Search more as a competitor to Yelp and Foursquare than Google.

Facebook has not announced a monetization strategy for Graph Search yet (to the disappointment of shareholders), but one obvious route looks to be selling search ads that are targeted by combining “search intent” - which is what Google has built it’s business on - with Facebook’s valuable social data.

Privacy is an immediate concern with Graph Search, so much so that Facebook tried to allay in their initial announcement. The effectiveness of social search relies of the amount of public data users share, putting it at odds with user’s privacy needs. It will be interesting to see how this plays out.

It is early days still and speculation about Graph Search is rampant. But it will be a valuable discovery tool for businesses with Facebook Pages and Applications, and because of that Facebook has already released a few resources that provide a basic outline of how the search will work, and how businesses can optimize for it.

The goal of this post if for me to synthesize the changes for my own understanding, but I thought I would share it with the world as well. I will hopefully update this page as more information becomes available and my understanding improves.

I am learning the Backbone.js JavaScript framework right now, and ran into a problem. Backbone Collections and Models can be set up to asynchronously load data from the server with the fetch() method, which fires off an Ajax sync call. You can bind a callback method to a Collection’s reset event, which Backbone provides. It was my impression that the change event on a Model would do the same thing. But when I bound to the Model’s change event in a View, it did not work as expected. Here is the code that was not working:

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

 var Model = Backbone.Model.extend({ url: '/my/url' });

 var View = Backbone.View.extend({
   initialize: function () {
     this.model.on('change', this.render); // attempt to bind to model change event
     this.model.fetch(); // fetching the model data from /my/url
   },
   render: function () {
     console.log(this.model); // this.model has not been populated!
   }
 });

 var myModel = new Model();
 var myView = new View({ model: myModel });

NOTE: the .on() method was formerly called .bind() apparently, so some older online examples use this.model.bind(), and this still works, presumably calling the underscore.js bind() method?

Well, it turns out I was making a simple mistake about one of JavaScript’s trickier points: this context in the callback function. A substantial amount of reading later (this article in particular was helpful) I realized I needed to pass in the this context as a third parameter to the on() method. There is actually a whole section on this in the Backbone documentation.

More research showed me that since Backbone version 0.9.9 a new method was added to make it more foolproof to bind callbacks with the right context: listenTo(). This method is on the object that has the callback, instead of on the object you are binding to. This way it assumes the correct context and you don’t need to worry about binding it correctly. Below is the working method of binding to a successful Model load, with the new listenTo() syntax.

This past year I finally committed (heh) to using Git. One of the reasons was using it’s distributed architecture for easy-peasy remote code deployment to multiple remote environments. It has been a wonderful change which has made my life much easier, so I thought I would write up a blog post about it.

First let me just say that deploying with any kind of version control system (VCS) is a nice step up from deploying with an old school file transfer (e.g. FTP). Here are couple of reasons why deploying with Git is nice:

1. Fast, differential file transfer (only updates modified files)
2. Easy to rollback to previous code
3. Git “hook” scripts can run additional deployment tasks (see last Pro-Tip below)

There are a couple drawbacks to using pure Git to deploy however:

1. Git does not track file permissions, which could cause problems if some files or directories need special permissions
2. Git does not track empty directories. If you want it to, you have to use the hacky trick of placing an empty .gitignore in any empty directories you want to deploy
3. No built in database deployment and migration tools

For many purposes however it is a nice, simple solution that falls between basic file transfers and more advanced deployment options (mentioned at the end).

I have not blogged very much the last couple of years, but I am feeling the itch again. I love how blogging makes you more closely research and examine your thoughts and your code. I have missed it. I also miss the positive feedback and ego-reinforcement of blog comments and Google Analytics stats. So for 2013 I am trying to get back on the horse.

It was 4 years ago that I first decided to blog about web design and development on my freelance web design site, Chili Pepper Design. I read some high praise for the Textpattern PHP content management system, and installed it. It worked well, but had started to feel dated of late. And besides, none of the cool kids on Hacker News ever talk about Textpattern any more. ;)

So what are the cool kids talking about now? What is the new hotness? Ruby-powered static Jekyll blogs of course! Thus you see before you the new Chili Pepper Design blog, powered by Octopress (a fork of Jekyll).

Actually it’s not that new or hot anymore, but here are a few reasons why I chose to go the Jekyll/Octopress route regardless:

• Short learning curve - I was also comtemplating setting up a custom Rails blog, but have not found the time
• Static - fast loading! and no database to set up, migrate or maintain
• Ruby - I am learning Ruby, so this is a good excuse to squint at some code.
• Easy hosting - can even be used on GitHub Pages for free
• Easy to theme - not only is the default Octopress rad, but you have total freedom when styling Jekyll blogs
• Hipster plugins - easily show off your Coderwall and StackOverflow bling, etc

Next up I’m going to stretch out my old blogging muscles with a post about how I migrated my blog from Textpattern to Octopress - on windows (dun dun dun).

Cheers!

So, this might be for kind of a narrow audience, but I’m pretty stoked on it so I wanted to share.

In the newest version of the Magento ecommerce platform, Magento 1.5, they have redone their update script. In Magento Connect 2.0, what was called “pear” is now “mage”.

Old and busted:

./pear mage-setup .

New Hotness:

./mage mage-setup .

They basically work the same, but the name has changed and – more importantly if you are reading this – there is no windows batch file to run. There is a Bash shell script, so you can download and update Magento and it’s many Extensions via the command line in Linux, but not Windows.

So, looking at the mage.sh script and working from the pear.bat script, I made mage.bat. It lets you do command line downloads and updates of Magento in Windows, just like you can on Linux.

Not that anyone is actually hosting Magento on a WAMP setup, but I find it useful to be able to download and install Extensions and modules on my Windows development box.

Update: SplashLab Social has been released! If you are looking for an easier way to set up Fans-only/Reveal tabs, look no further! My new service makes it easy to create custom fan-gate tabs, check it out!

FBML is going away. Is the popular (and effective) strategy of “fan-gating” content to encourage visitors to Like you page going away with the fb:visible-to-connection FBML tag?

No! Facebook has been kind enough to provide a new method for implementing “reveal tabs” on the new iframe tabs. Follow along in the tutorial below to learn how to do this.

(This tutorial assumes you are creating a PHP Facebook application, but you can follow the spirit of it in any language.)

The long awaited transition from FBML tabs to iframe tabs has finally happened. As of this writing on Feb 14th 2011 (Valentines Day!) you can choose the “iframe” option for Facebook application tabs. The official word from the Facebook developer roadmap is that as of March 11th developers will no longer be able to create FBML tabs (although existing FBML apps will be supported indefinitely – or at least until the end of 2011 I heard in the comments).

Update: The project is now live and ready for signups! Head over to SplashLab Social to learn more and get started. It’s the easiest way to create and manage content on your Facebook Page’s iframe tabs!

There’s something big in the works here at Chili Pepper Design I wanted to share on my blog quickly: