Chomper Stomping jQuery/JavaScript/CSS 3/HTML 5, Java/PHP/Python/ActionScript, Git, Chrome/Firefox Extensions, Wordpress/Game/iPhone App Development and other random techie tidbits I've collected

26Sep/13Off

Proxying a request through nodeJS from front end to different server

I was quickly copying/pasting some code around in a project and screwed it up and started getting a 404 response to an AJAX request (using backbone.js). I realized I was getting the 404 to the OPTIONS request backbone was making because I was accidentally not using my NodeJS router. So, for future reference (mostly to myself, but, maybe this will help others), here is my basic implementation.

12Feb/130

Discourse Themes

logo

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).

26Apr/120

dynode Batch Get Item

logo

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...

23May/112

Updates – BASIC jquery ui tabs rotate documentation, a note on nodejs hosting, and a note on the re-design

logo

nodejs, jquery ui tab rotate, and re-design. Just a few quick notes...

  1. 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.

  2. 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.

  3. 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.

  4. 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.
14Jan/110

Yet Another Reason to Namespace your JavaScript Variables

1306092411709_a923d

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.

20Apr/102

Using jQuery to bind a function to a select box change and retrieve the selected value

jquery-logo

If you need to bind a function to be called when a user selects an option from a select box using jQuery, you've come to the right place.

There are several different ways to skin this cat, but basically here is what we are going to do:

1. Bind a change event listener to the select box itself
2. When the box is changed, call a function that detects and retrieves the selected value

Here's the code:

$("#selectBoxId").change(function(){
var selectedValue = $(this).find(":selected").val();
console.log("the value you selected: " + selectedValue);
});

Let's break it down line by line.

Line 1:
$("#selectBoxId").change(function(){

$("#selectBoxId") grabs the DOM element out of the html and makes a jQuery object.
.change(function(){}); binds a function to the change event of the select box. Any time anyone changes the selection in the select box this function will fire off

Line 2:
var selectedValue = $(this).find(":selected").val();

var selectedValue creates a new variable that the selected value will be stored in.
$(this) creates a jQuery object based on the select box that triggered the function.
.find(":selected") looks a the select box that triggered the function and finds the option that got selected.
.val() gets the "value" of the selected option.

Line 3:
console.log("the value you selected: " + selectedValue);

this just calls the firebug console in firefox and tells it you want to print something out to it. You don't need this line, but this line shows you that the above code did indeed grab the selected value out of the select box.

Line 4:
});
This just closes the open change function started on line 1.

This code assumes that you have an HTML select box with an id of "selectBoxId". If you have a series of select boxes that all need the same function bound to them for some reason you can give them all the same class name (say "selectBoxesClass") and select them like so: $(".selectBoxesClass").

<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8" />
<title>Conforming XHTML 1.0 Strict Template</title>
<script src="http://ajax.googleapis.com/ajax/libs/jquery/1.3.2/jquery.js"></script>
<script type="text/javascript">
$(function(){
$("#selectBoxId").change(function(){
var selectedValue = $(this).find(":selected").val();
console.log("the value you selected: " + selectedValue);
});
});
</script>
</head>

<body>
<select id="selectBoxId">
<option>Foo</option>
<option>Bar</option>
<option selected="selected">Beh</option>
</select>
</body>
</html>

Here is the example

Here are some resources for further reading:
jQuery
jQuery change
jQuery find
jQuery val
jQuery :selected selector
jQuery Element selector
jQuery id selector
jQuery class selector
Firefox
Firebug
Firebug Console

10Feb/101

JavaScript Arrays – new Array() vs array literal

1306092411709_a923d

Do not every say new Array() when creating a new JavaScript Array(). There are differences between creating an array in Javascript using the array literal, or the fully qualified "object" name (Array() vs []), and the bottom line is that the "right" way to do it is "[]" (array literal) instead of "new Array()". Here is why: