I’m dreaming of a white… June?
It may seem fairly random at this time of year (or for the northern hemisphere any who), but I wrote a snow script yesterday. I made it because I wanted it, but mainly because I wanted to sub class it. The original snowmaker script was written by Peter Gehrig (in 2003 I think), and most of the credit still has to go to him for this script. I am only rewriting it (better hopefully) in an object orientated fashion, and making it more flexible for users.
The script is wrapped up into one class. It uses the Prototype JavaScript library, as a prerequisite, so please include it before the script or it will not work. (The TMC.widget.Snow() class is shown at the button of the page). All that you have to do to initialise the script is create a new instance of it on the page, for example….
var snow = new TMC.widget.Snow();
This is all that is really needed if you just want to create a snow script, however you mgiht use it for something else you it can be easily customised. It takes in certain options that you can adjust on each instance if you wish, for example… (a full list of options is in the source with explanations and recommended value ranges).
var options = {
flakes: 39, // number of snowflakes (more than 30 - 40 not recommended)
speed: 0.8, // speed of sinking (recommended values range from 0.3 to 2)
font: ['Arial Black',Comic Sans MS'], // fonts that create the snowflakes. Add as many fonts as you like
};
var snow = new TMC.widget.Snow(options);
There are also some convenience methods provided for greater control over the script once it has been instantiated. The method names are self explanatory.
var snow = new TMC.widget.Snow();
snow.stop(); // stops the snow falling/moving
snow.start(); // starts the snow falling/moving
snow.hide(); // hides the snow from view (will continue to move, even though not visible)
snow.show(); // brings the snow into view
This is everything you should need to know about the script to really take advantage of all its goodness. Here is the class itself… Pastie Link. I posted it on Pastie as wordpress didn’t like me trying to post the code.
Pre – Pro JavaScript Design Patterns
I just bought Pro JavaScript Design Patterns from Amazon for my birthday and it arrived today. Recently I have really got into JavaScript and decided on getting this book mostly because I enjoyed reading Dustin Diaz’s blog so much. The blog itself hasn’t had much recent content but it delivers a lot of very educational and enjoyable reads that are as validate as the day they were posted. I have never purchased a book about coding or even computing really, so this is a prototype to evaluate there benefits. I figured I would land some JavaScript design patterns that I like to use, very personally, so that after I finish the book I can compare how I code then. For the most part the techniques will be very basic but hopefully they benefit some web wonders.
Defining Functions
Usually you learn to define functions like so…
function doSomething() {
(...)
}
However, I like to define functions like so…
var doSomething = function() {
(...)
}
Semantically they are identical, but it’s just taken a preference recently. It keeps my code looking more consistent with the way I define objects (see literals below).
Literals
Sometimes it just seems ridiculous to define a new object (I don’t like using new to much (when you can use a literal)) …
var myString = new String('foo')
var myArray = new Array('foo','bar')
var myObject = new Object()
You probably already use some literals…
var myString = 'foo' //creates a string literal value
I like to additionally use these literals…
var myArray = ['foo','bar'] //creates an array literal, with values
var myObject = {} //creates an object literal
Object Initialisers
More commonly referred to as JavaScript Object Notation (JSON). Nearly all the JavaScript I write uses JSON. It’s a much better way of writing your code. It is a collection of name/value pairs usually stored in objects and arrays.
var ourObject = {
doSomething: function() {
(...)
},
'myString': 'foo',
myArray: ['foo','bar'],
myObject: {}
}
I have stored similar objects as before, however, even though I have stored them with the same names they will not over write the previous objects because they are stored with ourObject. They will render exactly the same results but will be called like so…
ourObject.doSomething()
ourObject.myArray(0)
// etc ...
Using this type of coding is much more efficient, and it’s considerably easier to read and understand because code is grouped into objects. It also allows you to use the same names for functions, for example ‘init’, which I use a lot.
