Discourse Themes

Discourse Forum Themes are going to be a thing the way WordPress Themes are a thing (I'm betting). Themeforest sells WordPress themes, and you can make a very comfortable living if you've got a premium WordPress Theme for sale on ThemeForest. If you want to buy a premium discourse theme, I'm betting eventually you'll be able to do that there as well.
After a cursory look at Discourse, I realized that you don't need to learn Ember and write an Ember theme. Theoretically you could write a custom CSS theme for Discourse, but, I don't think that's where the real money will lie. Since Discourse is really split into two separate parts (an app and a back-end) that talk to each-other via a REST api, it's like a theme developers dream come true. You can write the front end app in anything you want, as long as it talks to the RESTful back-end. This means, if you wanted, you could create a PHP driven Discourse theme. More likely, you will probably want to create some sort of Backbone Marionette driven Discourse theme that interfaces with the JSON REST api (which is written in Ruby). Out of the gate, their themes are Ember js and CoffeeScript; but since that isn't quite as ubiquitous (and hopefully never will be) as just plain old javascript or PHP or something, I don't think themes written in that standard will take off.
JavaScript based Discourse Theme templates written with a common library (like Backbone with Twitter Bootstrap) are going to be a potential candidate for some good money. If you can create a good boilerplate discourse theme template that discourse theme authors can purchase and build on top of, that could be a valid business model as well. If I do any Discourse theming, this is most likely what I would do. A boilerplate Discourse theme template, with one reference implementation theme, written in JavaScript with Backbone, Marionette, Underscore, jQuery, and Bootstrap and available for Discourse theme authors to purchase and get up and running with (especially if they want more than just a CSS theme, but don't want to learn EmberJS and CoffeeScript).
Sublime Text 2 Grunt Build
Kick off a grunt build from within Sublime Text 2:
{
"cmd": ["grunt"],
"working_dir": "/Users/[your username]/[your project path]",
"shell": true
}
It took me a bit to figure out how to actually make a grunt build run from within SublimeText 2, so I wanted to capture it here for anyone else trying to figure it out. Google really didn't help me at all...
The key is the working directory thing. You can't use "~/", you have to actually use the full path to your directory that you normally kick your grunt builds off from. I found one place on stackoverflow where it recommended adding this after "grunt":
, "--no-color"
but it didn't change the output for me at all.
You put this code in a file you create by clicking "tools" > "build system" > "new build system". Then whatever you name the file when you save it will be the name of the "build system". You can hit "cmd B" to build it or select "tools" > "build system" > "whatever you named it"
dynode Batch Get Item

Working a lot with node.js, dynode and dynamoDB recently. Still trying to wrap my head around it all. Had a horrible time getting dynode.batchGetItem to work. Here is the error I was getting:
{ name: 'AmazonError',
type: 'ValidationException',
serviceName: 'com.amazon.coral.validate',
message: 'One or more parameter values were invalid: Mismatching attribute types between location and schema',
statusCode: 400,
retry: [Getter] }
Basically it came down to that the range selector I was using was being passed through as a string instead of a number. This is *even though* I am chaining queries, having just gotten the range selector out of another table and am immediately using it in the query that is failing. The way I was able to fix it was by casting it from a string into a number (the way Amazon expects it to come across):
results.Items.forEach(function(element, index, array){
console.log(element);
element.events.SS.forEach(function(ielement, iindex, iarray){
var batchVars = {"events": {keys:[ {hash: ielement, range: parseInt(element.timestamp.N)} ]}};
dynode.batchGetItem(batchVars, events.debugOutput);
}, query);
}, query);
The crucial part here being this line:
{keys:[ {hash: ielement, range: parseInt(element.timestamp.N)} ]}
Note the "parseInt" function there that gets run on the timestamp that was pulled out of the previous query results. That's the key to getting this to work.
UPDATE:
The dynode author asked me to submit an issue, so, I did!
https://github.com/Wantworthy/dynode/issues/18
I had just assumed this was a quirk of the library. I feel way too new to all of this to know what is a bug and what is just me doing something stupidly...
Updates – Tab Edit 1.4, Abandoning JS Console, Limeberry news

It's apparently Code Blitz week here at Chomperstomp.com HQ. We've seen 5 blog posts in the last week, and code commits to no less than 4 open source projects (plus tons behind the scenes that I won't talk about just yet, but some neat stuff is coming...)
I finally fixed the Tab Edit Chrome Extension. Update and click "Restore Defaults" and it will work again. Still working on the problem of it not persisting the favicon selection though.
I have officially abandoned work on the JS Console Chrome Extension. It's absolutely pointless. Just hold shift when you hit enter while using the native JS Console and you can get multi-line functionality. That was the whole point of JS Console, so once I discovered this, I abandoned the project. I forgot to ever let anyone know though, so this is me making it official. I've made notes in all other relevant places as well.
Limeberry is coming along just swell. I've made some major improvements today. Gradient history swatches that when you hover over you can retrieve previous gradient code. Ditched all the PHP based code in favor of JS. Gave ability to change the number of gradient stops on the fly without a page reload (still doesn't preserve your previous stops/colors). LOTS more work to come on this. The more observant of you may notice that I'm updating the URL on the fly as you make changes. Yes, that's right, very very soon you will be able to bookmark swatches you create (or email/IM links) so you can save/load swatches. This is the project I'm most excited about right now, so this will be getting some love over the next few weeks. I'm hoping to turn this into a really nifty tool and even plop down the $10 I need to get it it's own domain. I've possibly even got another dev on board to design the page (rather than it just being ugly as hell the way it is now). Much much more to come...
Updates – BASIC jquery ui tabs rotate documentation, a note on nodejs hosting, and a note on the re-design

nodejs, jquery ui tab rotate, and re-design. Just a few quick notes...
-
I'm actively working on documentation for the jquery ui tab rotation plugin. I've (finally) got a very basic working example up.
The plugin is stupidly easy to use:
$("#tabbedElement").tabs().tabs("rotate", 4000, true);
Note that you MUST first call tabs() before you can add the rotation with .tabs("rotate", [ms], [rotate]). Also note that as of right now none of those params are optional! You can also call .tabs("pause") and .tabs("unpause") to start and stop the rotation. You can instantiate a rotating element that starts as "paused" by passing in false for the [rotate] param.We use this plugin at FinishLine.com, and we are always on the most recent stable release of both jquery and jquery UI, which means that this plugin is nearly always guaranteed to work with the newest version of both. I'll be posting updates to this blog whenever there is anything to report. The plugin's official "homepage" is right here.
-
Node.JS is a server side implementation of JavaScript. It is basically PHP or ASP or [name your server side language of choice here] but with JavaScript. This fulfills Knuth's 3rd law, which states that any code that can be written will eventually be written in JavaScript, which fulfills Knuth's 4th law which states that Knuth's 3rd law will change languages every 10 years. In case you were wondering, Knuth's 2nd law is that a 12% improvement is easily obtainable and should not be marginalized, which compliments while nearly contradicting Knuth's 1st law, which states that premature optimization is the root of all evil.
ANYWAYS, I'm working on something FUN in node.js. If it works out, it's gonna be BIG. If not, you'll never hear about it again, lol. But that's not what I want to talk about. This is a quick note to make mention of the fact that if you are looking for a node.js server, they are out there. You don't have to roll your own. Check out no.de, or this stackoverflow question or this page on the project's wiki for hosting options.
-
And last but not least, you may notice that I have re-designed the blog. I'm now using a PREMIUM wordpress theme created by my good friends over at outerspiceweb.com. It's called Continuum, and it is spectacular. It is their newest offering.
I'm doing some work with it, so I installed it here to help me figure out how it works and debug and develop on it, but I like it so much I think I'll just leave it up. You too can have this rad-tacular theme by heading over to its page on themeforest.
- Oh, and one final thing. I am actually working on upgrading status-bar calculator for Firefox 4.0. I'm having trouble, I have no idea why it's not working, but when I figure it out there will be a write-up here.
Yet Another Reason to Namespace your JavaScript Variables

If you aren't namespacing your JS variables, you should be.
There are a plethora of great reasons to do so, which I won't go into here, but I just stumbled upon another great reason today.
It makes your code faster.
What? Yeah. According to my preliminary tests...
You can see here that we are running through three while loops two million times.
The first time we are creating a variable local to the while loop each time and incrementing it by 1 each time.
The second time we are referencing a global namespaced (namespaced to the random characters "GL" for absolutely no reason) variable and incrementing it by 1 each time.
The third time we are referencing a global variable (not namespaced) and incrementing it by 1 each time.
You'd think that the second and third times would be nearly identical. They aren't. Check out the results:

That's right, the local variables loop took 1584ms, the namespaced one took 1180ms and the global one took 1219ms. The namespaced one is consistently faster.
Now, think about an E-Commerce website with 50,000+ lines of JavaScript code. If these results mean what they seem to mean, imagine the performance improvements to be gained simply by namespacing your functions, variables, etc. Potentially huge? Maybe, this bears some looking into.
EDIT: These results were just bothering me. A lot. It didn't make any sense. So I Made a JSLitmus test to see if it was maybe just a firebug thing. Nope. Same results, actually even more disparate results in some browsers:
Try it for yourself (doesn't work in IE 9 for some reason).
Feel free to comment with any more tests/data you know of on this subject, I'd love to hear.
jQuery UI Patch Landed!
I'm now an official contributer to the jQuery codebase (well, jQuery UI).
This is my first real code contribution to a major open source project. Kind of exciting.
Granted it was only one line of code (started as around 15 lines, but we got it narrowed down to just the one) but it was a big problem for my website (and several other sites) and it took some detective work to track down what the actual issue was.
Flurl – Part 5: The Unicorn/Panda Rainbow Connection

Wait, where's parts 2 through 4? Not done yet, but I'm done with the project and I may never get around to posting those other parts and wanted to post the finished product.
Again, Flurl is a little practice exercise I did. A mashup of Flickr and Qurl and no external JS libraries used (so I wrote my own).
I'm taking this photo stream (Be careful, since the photos are completely random "popular" flickr photos, even though they purport to be "safe" there are definitely some NSFW photos now and then) and sending the URLs to Qurl for shortening (using their API). This is the end result (best experienced in Chrome): The Unicorn/Panda Rainbow Connection UPDATE: LOST FOREVER (maybe... When my site got hacked I deleted a whole bunch of stuff trying to flush out the bad code. Apparently this got whacked in the process. I *might* have a copy somewhere, but, can't find it right now).
Some thoughts: Qurl sucks as far as response time. I had to limit my photos to five because Qurl was so darn slow responding to my requests and there is no way to do a batch request. BAD. What would I do to fix this? How about dump Qurl entirely. Flickr has their own shortening algorithm that doesn't even require an API call. If I had to keep using Qurl? I'd go ahead and load the photos to the page for the user with the long links, then I'd make a button on the photo (or link or something) that allowed them to request a shortened URL from Qurl. They click the button/link and an AJAX request fires off grabbing the URL and giving it to them.
I couldn't get the Flickr API to return only a certain number of Photos. I did everything I could find that it said I should do to get it to only return five or ten photos, but alas, it didn't work. So I had to make a loop that just used the first five/ten photos and ignore the rest. If it weren't for Qurl, which takes over 30 seconds most times to shorten 5 urls, I wouldn't care how many Flickr sent back. Still weird and wasteful and if I had more time I'd look into it until I got it working.
When I removed Qurl from the loop, the photos returned in less than five seconds flat (awesome!). However, with Qurl the response time ranges from 30s to 90s. So AS SOON AS I get the response back I fire off another request. If the response only took 5s total, I'd put a timeout or interval or something that queried only once a minute or so. Or, better yet, I'd make it fire off the request 10 seconds before my photo scroll ended and just put the new photos above my current scroll and make the scroll seem endless (like the pandas).
I spent far too much time on the library. I had big plans and it turned out I wrote way more code than I ended up needing because I was doing VERY LITTLE DOM manipulation. Of course if I worked on this for another forty hours or so the library really would have paid off because it would have saved me time as my interactions got more and more complex. If I had come up with the full design before I started writing the code I would have known I wasn't going to need much DOM interaction, but as it stands I didn't have any idea what the page was going to look like until I was almost completely finished with the cQuery JS library.
Queue. Something interesting I came up with was a way of handling mutliple simultaneous AJAX requests and multiple simultaneous animations. A queue.
For the AJAX requests I had an AJAX queue that just held all of my requests (didn't end up needing this, but it is there if I decide to do the Qurl thing separate from the photo retrieval). I hope to go into the AJAX queue in more detail in another post, but the reason I needed it was the callback function. I needed somewhere to put it until the request completed.
For the animation queue, I didn't want to set up a whole bunch of different "set intervals" or "set timeouts" so instead I made an "animations" array and then made ONE setInterval that called a function that looped through the animation array. Each spot in the array held an "animation" Object, which had an "animate()" function. The animate function would get called on the object and be allowed to run in the proper context (with "this" functioning as expected). This ended up saving me a lot of code and headaches and made my JS run way faster than it otherwise would have. Of course I ended up only having one animation run at a time and I have no standard way of removing from the queue, but I could add that to the library and there is definitely room for more animations.
One last thing, the song is from Jonathan Neal (who is hilarious). I converted it to .ogg format because Firefox didn't allow anything else, however it appears that Safari doesn't accept .ogg format, so if I had more time I'd make something to detect with browser I'm in and respond with the .mp3 format instead...
TOTW: Modernizr
Modernizr is a JavaScript library that you include on your page that executes itself and adds a series of classes to your HTML tag. This allows to implement modern CSS functionality without worrying about writing conditionals in JavaScript or anything complicated like that. You simply write one (or at most two) style definitions around the functionality you want, like this:
.functionalityYouWant #myElement{
css3thing: blah;
}
.no-functionalityYouWant #myElement{
oldSchoolWay: blah;
}
So, real world example:
.cssgradients .sideNavTitleBox{
background: -moz-linear-gradient(center bottom, #000 13%, #353535 84%);
background: -webkit-gradient(linear, center bottom, center top, color-stop(0.13, #000), color-stop(0.84, #353535));
}
.no-cssgradients .sideNavTitleBox{
background-color: #000;
background-image: url(/media/images/backgrounds/left_nav_box_header.gif);
background-repeat: repeat-x;
background-position: left top;
}
Again, you don't have to write any javascript at all, you just include the library on the page and it runs all on it's own and enables this awesomeness!
EDIT: Oh look, ALA just posted a great article on modernizr.
Flurl – Part 1.a: Rolling your own JavaScript library, setting up the core
Flurl is a mashup I did recently as a practice exercise.
It takes a flickr panda photo-stream, displays a photo, and uses qurl to make a shortened URL link to the photo.
These are the notes I took while I was doing it.
The project can be found on GitHub at http://github.com/cmcculloh/Flurl
For this exercise I didn't want to use any JavaScript library. Normally I'd use jQuery (naturally) but I wanted to feel the pain of plain jane JavaScript again since it had been well over a year since I had done any AJAX without a library.
I decided I'd roll my own library that I could use to encapsulate the AJAX and DOM selection framework to keep it seperate from the actual app and to simplify my life in actually writing the app.
Since I wanted my library to feel a little jQuerish I decided as an homage I'd name it cQuery and use the _ instead of the $.
Step 1, the ubiquitous self executing anonymous function:
(function(window, document, undefined){})(this, document);
I'll break it down. The starting paren "(" and it's mate are just a "cool guy" coding convention to let people know, "this is weird! This is a library! This ain't yo mama's JavaScript!". It's the same as this:
function(window, document, undefined){}(this, document);
Which is simply just a function that immediately calls itself. The main reason to do this is to prepare our code for minification. When we minify, it will end up something like this:
(function(A,B,C){})(this, document);
So anywhere in our library where we had "window" or "document" or "undefined" it will not be the much shorter "A", "B" or "C", much smaller!
Paul Irish explains this in a *little* more detail in his 10 Things I Learned From the jQuery Source video.
Next we build the core function of our library, add it to the namespace and give it it's "_" shortcut:
var cQuery = function(elm){
};
window.cQuery = window._ = cQuery;
Note that if we didn't do that last line 'cQuery' would not be available in the rest of our JavaScript since it is hidden away inside of the closure we talked about above.
I really like the way jQuery works, and I want my library to mimic this. So calling:
cQuery("#domElementById").someMethod().anotherMethod();
ought to work.
Functions in JavaScript are just Objects that you can invoke. Functions can have their own methods, properties, etc. So basically cQuery is just an object that can DO something on it's own so we can say cQuery() instead of cQuery.doThing(). Much more convenient. So basically our var cQuery = function(elm){} code is just setting up my cQuery library object in a way that it can be called and passed the dom element we are working with.
Since I want to be able to "chain" things in my library, I'll need to add the methods in there that enable my chaining. I do this by ending my cQuery function with a return statement that returns an object containing the methods I wish to be available for chaining, each of these methods in turn returning an instance of the cQuery object (unless the method is specifically supposed to return something else, which makes it a destructive method because it ends my chaining), like in this example:
(function(){
var c = function(){
return{
blah:function(){
alert("blah");
return c();
},
blah2:function(){
alert("blah2");
return c();
}
};
};
window.c = c;
})();
c().blah().blah2();
That's it! Now I've got the core of my JavaScript library all set up, chaining enabled, library closed in but available on the namespace, all ready to be made useful! Here's the code we've got so far:
(function(window, document, undefined) {
var cQuery = function(elm){
//DOM selection and storage will go here
return {
//chain-able library methods go here
};
};
//make sure our library is exposed to the global namespace and make a shortcut "_" so we don't have to type cQuery every time.
window.cQuery = window._ = cQuery;
})(this, document);






