Resolving ? Must load Linux kernel before initrd? Error Message in Linux Operating System

Boot loaders such as GRUB (Grand Unified Bootloader), LILO (Linux Loader) etc. enable you to select to boot a particular operating system in multiboot or dual boot systems. After selecting the operating system (for example Linux), the booting process initially starts with the booting of Linux Kernel program. A Linux Kernel program is the central component of a computer operating system. It requires the corresponding drivers to access the device on which the file system is based. To avoid any conflict due to all imaginable drivers in the kernel, it uses initial ramdisk (intrd). The intrd is the temporary file system, which is mostly used for preparations before the real root file system can be mounted. Problems might occur when intrd gets loaded before Linux Kernel program. In such situations, the hard drive volume becomes un-mountable and the data saved in the hard drive becomes inaccessible. In such situations, you need to recover your data from the latest backup. In case, no backup is available or the backup is corrupted, you need to use efficient Linux Data Recovery applications to recover your lost data files.
Consider a practical example, when you attempt to boot Linux operating system, you encounter the below error message:
“Must load Linux kernel before initrd”
The above error message occurs each time you try to boot the Linux operating system on your computer. After the above error message appears, the data saved in the Linux volume becomes inaccessible.

Cause:
The above error message mainly occurs when the intrd gets loaded before the Linux Kernel program.

Resolution:
To resolve the above error and access the data, you need to remove the intrd from your computer. However, if you still encounter an error, then only option left is to access the volume by reinstalling the Linux operating system. A clean reinstall of the operating system will erase all previously stored data in the hard drive. In such scenarios, you need to recover lost data by using effective Linux Data Recovery software. These advanced recovery applications incorporate high-end scanning methods to recover lost data from a logically corrupted hard drive.

Stellar Phoenix Linux Data Recovery serves the purpose of providing reliable and easy Linux Data Recovery. This read only Linux Recovery software supports Ext2, Ext3 and ReiserFS file systems. It gets installed on Windows (Vista, XP, 2003 and 2000) and the affected Linux drive should be connected as slave.

Robin Watson a student of Mass Communication doing research on linux data recovery software. He is also a freelancer for Windows data recovery software. Sphere: Related Content

Unbreakable Enterprise Kernel

Public Yum Server
Last updated: 21 September, 2010

Now Available: Unbreakable Enterprise Kernel

Oracle has released the Unbreakable Enterprise Kernel for x86_64 servers via the Oracle Public Yum Server. Please use the following steps to install the new kernel and any required dependencies.
1. Ensure that your system is running Oracle Linux 5 Update 5 (x86_64) before installing the Unbreakable Enterprise Kernel.
2. Download and install the Oracle Linux 5 repo file to your system.
# cd /etc/yum.repos.d
# wget http://public-yum.oracle.com/public-yum-el5.repo
3. Enable both the [el5_u5_base] and the [ol5_u5_base] repositories in the yum configuration file by changing enable=0 to enable=1 in those sections.
4. To update your system kernel to the Unbreakable Enterprise Kernel, use the following yum command:
# yum install kernel
OR To upgrade all recommended packages associated with the Unbreakable Enterprise Kernel, use the following yum command:
# yum install oracle-linux
5. Reboot your system to run the newly-installed Unbreakable Enterprise Kernel.

Introduction
The Oracle public yum server offers a free and convenient way to install packages from the Oracle Linux and Oracle VM installation media via a yum client.

You can download the full Oracle Linux and Oracle VM installation media via edelivery.oracle.com/linux. Note that errata are not available via this public yum server. To access errata (bug fixes, security fixes and enhancement), you must have a valid support contract to access Unbreakable Linux Network (ULN). For more information, see the FAQ below.

This yum server is offered without support of any kind. If you require support, please consider purchasing Unbreakable Linux support via the online store, or via your sales representative.

Getting Started
Download and Install Oracle Linux
Download and copy the appropriate yum configuration file in place, by running the following commands as root:
Oracle Linux 4, Update 6 or Newer
# cd /etc/yum.repos.d
# mv Oracle-Base.repo Oracle-Base.repo.disabled
# wget http://public-yum.oracle.com/public-yum-el4.repo
Oracle Linux 5
# cd /etc/yum.repos.d
# wget http://public-yum.oracle.com/public-yum-el5.repo
Oracle VM 2
# cd /etc/yum.repos.d
# wget http://public-yum.oracle.com/public-yum-ovm2.repo

Enable the appropriate repository by editing the yum configuration file

Open the yum configuration file in a text editor
Locate the section in the file for the repository you plan to update from, e.g. [el4_u6_base]
Change enabled=0 to enabled=1
Begin using yum, for example:
yum list
yum install firefox
You may be prompted to confirm the import of the Oracle OSS Group GPG key.

Frequently Asked Questions
1) Where are the security updates and other errata ?
2) Where can I learn more about Oracle Linux?
3) Where can I learn more about Unbreakable Linux support?
4) Where can I learn more about Oracle VM?
5) Where can I get help getting this yum repository to work?
6) Where can I learn more about yum?

Where are the security updates and other errata?
A: This yum server only offers the packages already provided on the Oracle Linux and Oracle installation media. To access security updates and other patches or enhancements, you should use Unbreakable Linux Network (ULN). Access to ULN requires a valid Oracle Linux or Oracle VM support contract and Customer Support Identifier (CSI). To obtain a support contract, please contact your sales representative or make your purchase via the Unbreakable Linux Store.
Where can I learn more about Oracle Linux?
A: You can read a summary of features and specifications here. Additional technical information about Oracle Linux is available on OTN's Linux Technology Center.
Where can I learn more about Unbreakable Linux support?
A: You can read more about Oracle Unbreakable Linux Support at oracle.com/linux, For white papers, data sheets, FAQs and other technical information, see the Linux Technology Center.
Where can I learn more about Oracle VM?
A: You can read more about Oracle VM here. For technical information about Oracle VM, see the Oracle VM product page on OTN.
Where can I get help getting this yum repository to work?
A: This yum server is provided for free and without support. You may use the Oracle Technology Network Linux Forum, where other users are ready and willing to help.
Where can I learn more about yum?
A: There are several resources available on the the Web. Here is an overview of basic yum commands

Browse the Repositories
Name Last modified Size
--------------------------------------------------------------------------------
repo/ 19-Sep-2010 20:27 -
public-yum-el4.repo 26-May-2009 11:08 692
public-yum-el5.repo 20-Sep-2010 15:59 2.0K
public-yum-ovm2.repo 22-Apr-2010 11:01 1.3K
RPM-GPG-KEY-oracle-el4 26-Oct-2006 18:50 1.7K
RPM-GPG-KEY-oracle-el5 11-Nov-2007 08:01 1.4K Sphere: Related Content

W3C: Hold off on deploying HTML5 in websites

Despite the hype, the HTML5 specification isn't yet ready due to interoperability issues, a W3C official says
By Paul Krill | InfoWorld

HTML5, which updates the HTML specification to accommodate modern Web applications, has gained a lot of adherents in vendors like Microsoft, Google, and Apple. But the specification is plain not ready yet for deployment to websites, an official with the World Wide Web Consortium (W3C), which oversees HTML5, stressed this week.

"The problem we're facing right now is there is already a lot of excitement for HTML5, but it's a little too early to deploy it because we're running into interoperability issues," including differences between video on devices, said the official, Philippe Le Hegaret, W3C interaction domain leader. He is responsible for specifications like HTML and SVG (Scalable Vector Graphics).

[ See InfoWorld's reports on how to use HTML5 on your website today, whether HTML5 will kill off Flash and Silverlight and how HTML5 will change the Web. | Keep up with app dev issues and trends with InfoWorld's Fatal Exception blog and Developer World newsletter. ]

"I don't think it's ready for production yet," especially since W3C still will make some changes on APIs, said Le Hegaret. "The real problem is can we make [HTML5] work across browsers and at the moment, that is not the case."

His advice on HTML5 was endorsed by industry analyst Al Hilwa of IDC.

"HTML 5 is at various stages of implementation right now through the Web browsers. If you look at the various browsers, most of the aggressive implementations are in the beta versions," Hilwa said. "IE9 (Internet Explorer 9), for example, is not expected to go production until close to mid-next year. That is the point when most enterprises will begin to consider adopting this new generation of browsers."

A vendor with an interest in the specification said some parts of HTML5 are ready and some are not.

"The point of HTML5 is this has been an ongoing effort for a while now and many parts of HTML5 are already in the wild," such as Canvas 2D capabilities and WebSockets, for communicating between browsers, said John Fallows, CTO of Kaazing, which makes a WebSockets gateway.

Le Hegaret acknowledged HTML5 is viewed as a "game changer." Companies now can deploy HTML5 in their applications or in intranets where a rendering engine can be controlled, said Le Hegaret. But it is a different story on the "open Web," where interoperability is an issue, he added.

"What's happening is the industry is realizing that HTML5 is going to be real," said Le Hegaret.

The HTML5 specification itself features support for video and Canvas 2D. But other technologies such as CSS (Cascading Style Sheets) and MathML are considered part of the "open Web platform" along with HTML5, even if they are not covered by the actual specification, Le Hegaret said. SVG is referenced by the HTML5 specification.

Apple has positioned HTML5 as a replacement for Adobe's Flash rich Internet technology. But Flash and similar technologies, such as Microsoft Silverlight, still have a place, Le Hegaret said.
"We're not going to retire Flash anytime soon," Le Hegaret said. It will take years before all Web clients support HTML5, he said. He cited Microsoft's IE6 browser as an example of popular client not supporting the standard. "IE6 is still being used on the Web today, and it is 10 years old."

Over time, however, HTML5 will become the standard for websites, he said. "You will see less and less websites using Flash," said Le Hegaret.

Meanwhile, HTML5 is headed toward final approval in two to three years. HTML5 development was begun in 2004 by the Web Hypertext Application Technology Working Group.

"We basically want to be feature-complete by mid-2011," Le Hegaret said. Once the specification reaches that stage, W3C will issue a last call for comments. The next stage would be the candidate recommendation stage and then a recommendation stage. "And then we're done," Le Hegaret said.

Le Hegaret also acknowledged some other shortcomings in HTML5. For example, HTML5 lacks a video codec, and Le Hegaret does not expect to have one in the upcoming specification. "It's a patent issue," he said. The MPEG-4 codec, for example, is covered by patents, Le Hegaret said.

Digital rights management also is not supported in HTML5, he said. This means some video producers will not deploy their videos in HTML5 without this type of protection, he said.

HTML5 is an open standard, presenting a problem for DRM. "If we are going to develop a solution for DRM which is open, it would be broken by a hacker within two days," he said. "There is no point of us doing that."

There is a possibility for DRM in HTML5 at some point, however, but it is not in the plan at the moment, said Le Hegaret.

HTML5 also lacks authoring tools at the moment, he said. Adobe does offer one that works with its Creative Suite package, however, said Le Hegaret.

This article, "W3C: Hold off on HTML5 in websites," was originally published at InfoWorld.com. Follow the latest developments in business technology news and get a digest of the key stories each day in the InfoWorld Daily newsletter.

Read more about software development in InfoWorld's Developer World Channel. Sphere: Related Content

JavaScript Programming Patterns

JavaScript is meant to be used to add behaviour to a website, might it be for form validation or for more complex operations like drag & drop functionality or performing asynchronous requests to the webserver (aka Ajax). During the past few years, JavaScript libraries became increasingly popular. One of the reasons is definitely that websites are getting more and more complex and reinventing the wheel each time is not acceptable if you are working on a tight schedule. But letting aside libraries and focusing on the “bare” syntax of JavaScript, it is very valuable to know what kind of options you have in terms of programming patterns when writing JavaScript.

In this article I am trying to present some of the techniques out there that I have discovered. The patterns I would like to mention are the following:
* The Old-School Way
* Singleton
* Module Pattern
* Revealing Module Pattern
* Custom Objects
* Lazy Function Definition
The way I decided to present and compare these different patterns is by solving the same given task with every pattern. The task is: You have three links on a page and when clicking the links, the background color of that link should change to a preconfigured value. The markup looks like this:
ul
li a href="http://news.bbc.co.uk/">News on BBC website /a /li
li a href="http://nytimes.com/">Frontpage of The New York Times /a /li
li a href="http://www.guardian.co.uk/">Guardian Unlimited /a /li
/ul
To complete the task given, you essentially would need to complete the following steps:
* Define the background colors in some kind of configuration variable
* Get all the anchors on the page and store them in a data structure (array)
* Loop through that array and attach an onclick event to them, pointing to a function that changes the background color
* If the link gets clicked that function gets executed and the background color of the link clicked gets changed

The Old-School Way
I would like to start off with demonstrating how this task would have been solved in the late 90′s, early 2000. At that time, JavaScript was purely used to do sequential programming, defining one function after the other. Nobody worried about namespace. Nobody worried about re-usability of code. Nobody worried in general, cause each script kiddie was paid a huge amount of money. They couldn’t be bothered with such things. To make everything at least a bit more neat, I decided to use function definitions, even if you could write some of that code straight into the bode of the page (to make things even worse). So you could have 2 functions:
anchorChange1: collects the links and attaches the event
changeColor1: executes the actual swap of the background color
Without further ado, your final code might look like this:
function changeColor1(linkObj, newColor) {
linkObj.style.backgroundColor = newColor;
}

function anchorChange1() {
// set configuration
var config = {
colors: [ "#F63", "#CC0", "#CFF" ]
};

// get all links on page
var anchors = document.getElementsByTagName("a");
var size = anchors.length;

// loop through anchors and attach events
for (var i = 0; i < size; i++) {
anchors[i].color = config.colors[i];

anchors[i].onclick = function () {
changeColor1(this, this.color);
return false;
};
}
}
In a JavaScript block on the page – after the anchor and preferably close to the closing body-tag – you then only need to call the main function:

Please proceed to the working example. It works fine, although it has the problem of cluttering up the global namespace. This means, in a much more complex situation with several developers working on the same project, you have a big problem if someone comes up with something like this:
function changeColor1() {
alert("oh noes, my code got overwritten!");
}
If that gets defined after your own definition of changeColor1, your code will get overwritten by that second definition of the function with the same name. As stated in the introduction, website projects are far more complex theses day (with possibly several frontend developers working on it) than they were 5 to 10 years ago. So there is a potential danger that someone overwrites somebody else’s code and tracking down that problem can become a pure nightmare. So these days, I believe this technique should be avoided altogether.

Singleton
The second solution is dealing with the creation of a singleton, which means creating an object and assigning values (e.g. functions) to its properties. This object is immediately available for use and can be created using the following syntax:
var testObject = {};
For a start, I created an empty singleton:
anchorChange2 = {};
I decided to create 3 different properties for this object:
* config: holds the different background colors
* alterColor: method which does the actual color change
* init: attaches the alterColor function to the link element
The config property holds the new background colors:
config: {
colors: [ "#F63", "#CC0", "#CFF" ]
}

alterColor changes the background color to the new color:
alterColor: function (linkObj, newColor) {
linkObj.style.backgroundColor = newColor;
}

init is responsible for linking the onclick event to the alterColor method:
init: function () {
var self = this; // assign reference to current object to "self"

var anchors = document.getElementsByTagName("a");
var size = anchors.length;

for (var i = 0; i < size; i++) {
anchors[i].color = self.config.colors[i];

anchors[i].onclick = function () {
self.alterColor(this, this.color); // this is bound to the anchor object
return false;
};
}
}

The final singleton looks like this:
// singleton syntax
// creates a class and immediately instantiates an object
var anchorChange2 = {
config: {
colors: [ "#F63", "#CC0", "#CFF" ]
},

// does the actual change of the background color
alterColor: function (linkObj, newColor) {
linkObj.style.backgroundColor = newColor;
},

init: function () {
var self = this; // assign reference to current object to "self"

// get all links on the page
var anchors = document.getElementsByTagName("a");
var size = anchors.length;

for (var i = 0; i < size; i++) {
anchors[i].color = self.config.colors[i];

anchors[i].onclick = function () {
self.alterColor(this, this.color); // this is bound to the anchor object
return false;
};
}
}
};
Please proceed to the working example, annotated with some comments.

Module Pattern
Taking the singleton pattern one step further leads us to what Douglas Crockford calls the “module pattern”. The idea is to have an encapsulated module, that cannot conflict with any other modules you or someone else has created. You can create public and private methods within that module.

First, lets create a function that gets executed immediately (which is caused by parens after the closing curly bracket):
anchorChange3 = function () {}();
As stated before, with this programming pattern, you can have public and private methods. Public methods can be accessed from outside, private methods only from within the object. I decided to have a private variable config, a private method alterColor, which does the actual color change, and 2 public methods, which are bound to the object itself. For this to happen, you return an object with the respective properties:
return {
// public method
// can be accessed from outside
changeColor: function (linkObj, newColor) {
alterColor(linkObj, newColor);
},

// public method
init: function () {
var self = this; // assign reference to current object to "self"

// get all links on the page
var anchors = document.getElementsByTagName("a");
var size = anchors.length;

for (var i = 0; i < size; i++) {
anchors[i].color = config.colors[i];

anchors[i].onclick = function () {
self.changeColor(this, this.color); // this is bound to the anchor object
return false;
};
}
}
};

The alterColor function, as well as the config variable, live within the parent function anchorChange3, but outside the returned object:
var config = {
colors: [ "#F63", "#CC0", "#CFF" ]
}

function alterColor(linkObj, color) {
linkObj.style.backgroundColor = color;
}
As alterColor is a private method, it cannot be accessed from outside. To be able to execute that function you either need to put it in the object (which will basically lead you to using the singleton pattern again), or create another property within the returned object that calls the method. I have done the latter by creating changeColor which then calls alterColor.

The final code for this pattern looks like this:
anchorChange3 = function () {

// private property
var config = {
colors: [ "#F63", "#CC0", "#CFF" ]
}

// this is a private method
// can be accessed within anchorChange3
// cannot be accessed from outside
function alterColor(linkObj, color) {
linkObj.style.backgroundColor = color;
}

return {
// public method
// can be accessed from outside
changeColor: function (linkObj, newColor) {
// calls private function to change color
alterColor(linkObj, newColor);
},

// public method
// can be accessed from outside
init: function () {
var self = this; // assign reference to current object to "self"

// get all links on the page
var anchors = document.getElementsByTagName("a");
var size = anchors.length;

for (var i = 0; i < size; i++) {
anchors[i].color = config.colors[i];

anchors[i].onclick = function () {
self.changeColor(this, this.color);//this is bound to the anchor
object
return false;
};
}
}
};
As with the general singleton example above, in the body of the HTML document you would then need to call the init method:

Please proceed to the working example. The source code is, again, annotated with comments to hopefully make clear what is happening.

Revealing Module Pattern
Based on some investigations on how he could overcome some things he did not like about the module pattern, Christian came up with something that he calls Revealing Module Pattern. As the name indicates, it is related to the Module Pattern, but might be a bit more structured and easier to understand, especially when it comes to handing over code to other developers in your team.

First, it starts again with a basic function, which gets defined and called immediately:
var anchorChange4 = function () {}();
After that, all the properties and methods get defined, without paying attention to whether they are actually private or public:
// this will be a private property
var config = {
colors: [ "#F63", "#CC0", "#CFF" ]
}

// this will be a public method
var init = function () {
var self = this; // assign reference to current object to "self"

// get all links on the page
var anchors = document.getElementsByTagName("a");
var size = anchors.length;

for (var i = 0; i < size; i++) {
anchors[i].color = config.colors[i];

anchors[i].onclick = function () {
self.changeColor(this, this.color); // this is bound to the anchor object
return false;
};
}
}

// this will be a public method
var changeColor = function (linkObj, newColor) {
linkObj.style.backgroundColor = newColor;
}
Now we are getting to the interesting part. Switching back to the original Module Pattern, I am sure you have noticed that it ends with the return statement which holds all the public properties and methods. In the Revealing Module Pattern, you only put references to those properties and methods in there that you want to have publicly available:
return {
// declare which properties and methods are supposed to be public
init: init,
changeColor: changeColor
}
The only two properties needed to be publicly available are init (which does all the preparation work) and changeColor (which gets called when an anchor gets clicked). Looking at the code makes it clear right away which properties and methods are publicly available. The final code looks like this:
// revealing module pattern
var anchorChange4 = function () {

// this will be a private property
var config = {
colors: [ "#F63", "#CC0", "#CFF" ]
}

// this will be a public method
var init = function () {
var self = this; // assign reference to current object to "self"

// get all links on the page
var anchors = document.getElementsByTagName("a");
var size = anchors.length;

for (var i = 0; i < size; i++) {
anchors[i].color = config.colors[i];

anchors[i].onclick = function () {
self.changeColor(this, this.color); // this is bound to the anchor object
return false;
};
}
}

// this will be a public method
var changeColor = function (linkObj, newColor) {
linkObj.style.backgroundColor = newColor;
}

return {
// declare which properties and methods are supposed to be public
init: init,
changeColor: changeColor
}
}();
As with all the other patterns, you need to call the respective function in a script block in your page:

And again, the working example for this pattern.

Custom Objects
The method of creating a new object of a class (instantiating it) is common in all object-oriented languages. But JavaScript is object-based rather than object-oriented. In JavaScript, you just need to call the constructor function of your (custom) object with respective parameters to create an object. You do not have any classes or subclasses as e.g. in Java.

First, we would need to create a constructor function for our object:
var anchorChanger = function () {};
We leave the constructor empty for now (which is totally fine), but later on we will add a call to the init method of that object.

Using prototype, we can now add additional properties to the object “blueprint” so that these items are available for every instance of that object right from the start. I ended up with having 3 properties, namely: config, changeColor and init.
anchorChanger.prototype.config = {
colors: [ "#F63", "#CC0", "#CFF" ]
}

anchorChanger.prototype.changeColor = function (linkObj, newColor) {
linkObj.style.backgroundColor = newColor;
};

anchorChanger.prototype.init = function () {
var self = this;

var anchors = document.getElementsByTagName("a");
var size = anchors.length;

for (var i = 0; i < size; i++) {
anchors[i].color = self.config.colors[i];

anchors[i].onclick = function () {
self.changeColor(this, this.color);
return false;
};
}
};

Module Pattern
Taking the singleton pattern one step further leads us to what Douglas Crockford calls the “module pattern”. The idea is to have an encapsulated module, that cannot conflict with any other modules you or someone else has created. You can create public and private methods within that module.

First, lets create a function that gets executed immediately (which is caused by parens after the closing curly bracket):
anchorChange3 = function () {}();
As stated before, with this programming pattern, you can have public and private methods. Public methods can be accessed from outside, private methods only from within the object. I decided to have a private variable config, a private method alterColor, which does the actual color change, and 2 public methods, which are bound to the object itself. For this to happen, you return an object with the respective properties:
return {
// public method
// can be accessed from outside
changeColor: function (linkObj, newColor) {
alterColor(linkObj, newColor);
},

// public method
init: function () {
var self = this; // assign reference to current object to "self"

// get all links on the page
var anchors = document.getElementsByTagName("a");
var size = anchors.length;

for (var i = 0; i < size; i++) {
anchors[i].color = config.colors[i];

anchors[i].onclick = function () {
self.changeColor(this, this.color); // this is bound to the anchor object
return false;
};
}
}
};
The alterColor function, as well as the config variable, live within the parent function anchorChange3, but outside the returned object:
var config = {
colors: [ "#F63", "#CC0", "#CFF" ]
}

function alterColor(linkObj, color) {
linkObj.style.backgroundColor = color;
}
As alterColor is a private method, it cannot be accessed from outside. To be able to execute that function you either need to put it in the object (which will basically lead you to using the singleton pattern again), or create another property within the returned object that calls the method. I have done the latter by creating changeColor which then calls alterColor.

The final code for this pattern looks like this:
var anchorChange3 = function () {

// private property
var config = {
colors: [ "#F63", "#CC0", "#CFF" ]
}

// this is a private method
// can be accessed within anchorChange3
// cannot be accessed from outside
function alterColor(linkObj, color) {
linkObj.style.backgroundColor = color;
}

return {
// public method
// can be accessed from outside
changeColor: function (linkObj, newColor) {
// calls private function to change color
alterColor(linkObj, newColor);
},

// public method
// can be accessed from outside
init: function () {
var self = this; // assign reference to current object to "self"

// get all links on the page
var anchors = document.getElementsByTagName("a");
var size = anchors.length;

for (var i = 0; i < size; i++) {
anchors[i].color = config.colors[i];

anchors[i].onclick = function () {
self.changeColor(this, this.color); // this is bound to the anchor object
return false;
};
}
}
};
}();
As with the general singleton example above, in the body of the HTML document you would then need to call the init method:

Please proceed to the working example. The source code is, again, annotated with comments to hopefully make clear what is happening.

Revealing Module Pattern
Based on some investigations on how he could overcome some things he did not like about the module pattern, Christian came up with something that he calls Revealing Module Pattern. As the name indicates, it is related to the Module Pattern, but might be a bit more structured and easier to understand, especially when it comes to handing over code to other developers in your team.

First, it starts again with a basic function, which gets defined and called immediately:
var anchorChange4 = function () {}();
After that, all the properties and methods get defined, without paying attention to whether they are actually private or public:
// this will be a private property
var config = {
colors: [ "#F63", "#CC0", "#CFF" ]
}

// this will be a public method
var init = function () {
var self = this; // assign reference to current object to "self"

// get all links on the page
var anchors = document.getElementsByTagName("a");
var size = anchors.length;

for (var i = 0; i < size; i++) {
anchors[i].color = config.colors[i];

anchors[i].onclick = function () {
self.changeColor(this, this.color); // this is bound to the anchor object
return false;
};
}
}

// this will be a public method
var changeColor = function (linkObj, newColor) {
linkObj.style.backgroundColor = newColor;
}
Now we are getting to the interesting part. Switching back to the original Module Pattern, I am sure you have noticed that it ends with the return statement which holds all the public properties and methods. In the Revealing Module Pattern, you only put references to those properties and methods in there that you want to have publicly available:
return {
// declare which properties and methods are supposed to be public
init: init,
changeColor: changeColor
}
The only two properties needed to be publicly available are init (which does all the preparation work) and changeColor (which gets called when an anchor gets clicked). Looking at the code makes it clear right away which properties and methods are publicly available. The final code looks like this:
// revealing module pattern
var anchorChange4 = function () {

// this will be a private property
var config = {
colors: [ "#F63", "#CC0", "#CFF" ]
}

// this will be a public method
var init = function () {
var self = this; // assign reference to current object to "self"

// get all links on the page
var anchors = document.getElementsByTagName("a");
var size = anchors.length;

for (var i = 0; i < size; i++) {
anchors[i].color = config.colors[i];

anchors[i].onclick = function () {
self.changeColor(this, this.color); // this is bound to the anchor object
return false;
};
}
}

// this will be a public method
var changeColor = function (linkObj, newColor) {
linkObj.style.backgroundColor = newColor;
}

return {
// declare which properties and methods are supposed to be public
init: init,
changeColor: changeColor
}
}();
As with all the other patterns, you need to call the respective function in a script block in your page:

And again, the working example for this pattern.

Custom Objects
The method of creating a new object of a class (instantiating it) is common in all object-oriented languages. But JavaScript is object-based rather than object-oriented. In JavaScript, you just need to call the constructor function of your (custom) object with respective parameters to create an object. You do not have any classes or subclasses as e.g. in Java.

First, we would need to create a constructor function for our object:
var anchorChanger = function () {};
We leave the constructor empty for now (which is totally fine), but later on we will add a call to the init method of that object.

Using prototype, we can now add additional properties to the object “blueprint” so that these items are available for every instance of that object right from the start. I ended up with having 3 properties, namely: config, changeColor and init.
anchorChanger.prototype.config = {
colors: [ "#F63", "#CC0", "#CFF" ]
}

anchorChanger.prototype.changeColor = function (linkObj, newColor) {
linkObj.style.backgroundColor = newColor;
};

anchorChanger.prototype.init = function () {
var self = this;

var anchors = document.getElementsByTagName("a");
var size = anchors.length;

for (var i = 0; i < size; i++) {
anchors[i].color = self.config.colors[i];

anchors[i].onclick = function () {
self.changeColor(this, this.color);
return false;
};
}
};
As pointed out by Mike West, using prototype is much more efficient than creating these methods “on the fly” every time a new object gets created. The final custom object looks like this:
// custom object constructor
var anchorChanger = function () {
this.init();
};

anchorChanger.prototype.config = {
colors: [ "#F63", "#CC0", "#CFF" ]
}

anchorChanger.prototype.changeColor = function (linkObj, newColor) {
linkObj.style.backgroundColor = newColor;
};

anchorChanger.prototype.init = function () {
var self = this;

// get all links on the page
var anchors = document.getElementsByTagName("a");
var size = anchors.length;

for (var i = 0; i < size; i++) {
anchors[i].color = self.config.colors[i];

anchors[i].onclick = function () {
self.changeColor(this, this.color);
return false;
};
}
};
In the body of the document, you just need to create a new instance of anchorChanger:

As with the examples before, you can check out a live demo together with comments.

Lazy Function Definition
Peter Michaux came up with a pattern that he calls Lazy Function Definition. This pattern is particularly useful when you need to do computations on the page once and then reuse the output multiple times. With this pattern, you ensure that stuff that should be done once, is indeed only done once. The example that Peter is giving deals with putting together a scrolling function based on different browser environments. Based on the browser model, the scrolling function is put together differently when the function gets called for the first time.

For my task, this pattern does not provide a real advantage, cause there is just no heavy or complex computation needed. But how does it work in general? You start with your basic function definition:
var anchorChange5 = function () {};
The I added the properties, much like I did with the other patterns above:
// define configuration
var config = {
colors: [ "#F63", "#CC0", "#CFF" ]
};

// get all links
var anchors = document.getElementsByTagName("a");
var size = anchors.length;

// loop through anchors and attach events
for (var i = 0; i < size; i++) {
anchors[i].color = config.colors[i];

anchors[i].onclick = function () {
anchorChange5().changeColor(this, this.color);
return false;
};
}
All the above should only be done once and there is no need to include these properties in subsequent calls to that function. To put the Lazy Function Definition in the game, you need to redeclare your function:
// redefine function so that it only holds the changeColor function
anchorChange5 = function () {
return {
changeColor: function (linkObj, newColor) {
linkObj.style.backgroundColor = newColor;
}
};
};
So the final code for the Lazy Function Definition Pattern looks like this:
// lazy function definition
var anchorChange5 = function () {
// define configuration
var config = {
colors: [ "#F63", "#CC0", "#CFF" ]
};

// get all links
var anchors = document.getElementsByTagName("a");
var size = anchors.length;

// loop through anchors and attach events
for (var i = 0; i < size; i++) {
anchors[i].color = config.colors[i];

anchors[i].onclick = function () {
anchorChange5().changeColor(this, this.color);
return false;
};
}

// redefine function so that it only holds the changeColor function
anchorChange5 = function () {
return {
changeColor: function (linkObj, newColor) {
linkObj.style.backgroundColor = newColor;
}
};
};
};
What happens is:
1. anchorChange5 gets called and defines the config variable and collects all the anchors on the page
2. An onclick event gets attached to every anchor, with a call to the changeColor method of the redeclared anchorChange5 function
3. After that, anchorChange5 gets redeclared and only holds the changeColor method, which can be accessed as a public method

And again, in the body of the page, you call the function:

There is, again, a working example with comments. As stated above, this pattern is not that handy here, but consider a situation when there is some heavy and complex computing involved. You certainly do not want to do that each time the function gets called. Peter calls this kind of function definition a “promise”, which means the outer declaration can be viewed as some kind of promise that later on this function will get redeclared to provide something more useful.

Appendix: Copy & Paste Example
The following code is an template/example you can copy & paste into your favourite editor and build up your module/feature from there. It is based on the Revealing Module Pattern and assumes you are using the Yahoo! User Interface Library (YUI). To get further filepaths of components to include for your module, visit Serving YUI Files from Yahoo! Servers.


Conclusion
As stated above, these are my assumptions on how this particularly simple task can be accomplished. I am sure that there are some other ways of approaching this problem, but my point in going through these exercises was to teach myself how these different methods work in general.

There is no general solution on how such problems should be approached. For a task like this, I believe that the singleton pattern is the most convenient way of doing it. Mostly because less lines of code are required. But for other, more complex problems, using the module pattern or creating custom objects or the lazy function definition might be more appropriate.

Thanks for reading and checking out the examples. I would be very happy if you could provide me with feedback.

Further reading
A JavaScript Module Pattern: explaining how all this is applied at Yahoo!
Christian Heilmann tells you how to Show love to the Module Pattern
Lazy Function Definition Pattern by Peter Michaux
Christian again, describing what he calls Revealing Module Pattern
Richard Cornford on JavaScript Closures
Douglas Crockford on Classical Inheritance in JavaScript
Kevin Lindsey’s approach to simulating object-oriented programming in JavaScript
Harry Fuecks from SitePoint on JavaScript inheritance Sphere: Related Content

How Good C# Habits can Encourage Bad JavaScript Habits: Part 1

This is the first post in a multi-part series covering common mistakes C# developers tend to make when they first start writing JavaScript.

Introduction
Many people come to jQuery and believe that their knowledge of a previous classical language (C#, Java, etc) will help them be successful at client-side scripting. You can use your classical language skills to accomplish a large amount of functionality with jQuery. However, the more client-side code you write you will find yourself uncovering strange bugs because you didn’t take adequate time to learn JavaScript properly.
“…it turns out that if you have absolutely no idea what you’re doing in the language you can still generally make things work.” –Douglas Crockford, Yahoo!’s JavaScript Architect, Douglas on JavaScript -- Chapter 2: And Then There Was JavaScript

This article is targeted for developers that use jQuery but haven’t invested the time necessary to learn JavaScript. The intent is to help you avoid some common mistakes when moving from a classical language (Java, C#, etc) to JavaScript.

jQuery is a library that is written in JavaScript. It is important to remember that you will always be writing in JavaScript when using jQuery. It is inevitable that you will run into native JavaScript concepts that are foreign to the classical language proficient developer. Taking the time now to be proficient in JavaScript will increase your client-side code quality, efficiency, and decrease code maintenance.

Bad Practices
1. Having Variables & Functions in Global Scope
A best practice in C# is to limit the use of global variables. This doesn’t necessarily translate into a bad practice in JavaScript, but most C# developers are not aware of how easily it is to pollute the global namespace with needless variables and functions.

One way you can pollute the global namespace is to not declare your variables. In JavaScript, if you don’t declare your variables then they become globally available to the rest of the program, which is probably not what you wanted and generally a bad idea.

Coming from a C# background, you are most likely used to the concept of namespacing your classes so they won’t clash with other libraries. In the same way you should be mindful to not declare variables or functions in the global namespace to prevent clashing with other libraries, browser extensions, and also your own code.

Bad Practice
The following code shows some bad examples of how to declare variables and functions.
var iAmGlobal = "Keep these to a minimum";

iAmGlobalToo = "Bad";

function oldSchoolWay() {
//Placed in global scope when executed
iAmGlobalNooo = "Really Bad";

console.log( "Bad oldSchoolWay Function" );
}

//Bad way to prevent namespace clashing
function namespace_oldSchoolWay() {
console.log( "Worse oldSchoolWay Function" );
}

//Functions
window.oldSchoolWay();
window.namespace_oldSchoolWay();

//Global variables are available off window object
console.log( window.iAmGlobal );
console.log( window.iAmGlobalToo );
console.log( window.iAmGlobalNooo );
You can execute and modify the above code from jsFiddle.

In the above code snippet you’ll see that the iAmGlobal, iAmGlobalToo, and iAmGlobalNooo are all global variables. You would expect iAmGlobal and probably iAmGlobalToo to be global variables, but the variable inside the oldSchoolWay function is also global because it was never declared! The best way to stay out of this trouble is to be disciplined and declare all of your variables and not let JavaScript do it for you.

Klaus Komenda actually refers to the function statement as the Old School Way of function declaration. I’ve even seen C# developers trying to prefix their function names (as shown above by namespace_oldSchoolWay) to minimize collisions with other libraries, but you should not do this. That technique still clutters the global namespace.

There are many options to fix this problem, but the simplest is to create a namespace object and then declare all your functions and properties within it. See the following code snippet for a slightly better approach.

Object Literal (All Public)
An Object Literal is a convenient way to create new objects. The syntax looks very similar to what you might expect to see in JSON (JavaScript Object Notation), but they are actually quite different. For more information about this you can check out an in-depth discussion on it by Ben Alman entitled There's no such thing as a "JSON Object".

When you create an Object Literal you can provide properties and methods and they can refer to each other. You can also add additional methods and properties to the object after it has been defined. All the properties and methods that you declare in the Object Literal are publicly accessible to the rest of your JavaScript code.
//Object Literal declaring properties and methods
var skillet = {
//public property
ingredient: "Bacon Strips",

//public method
fry: function() {
console.log( "Frying " + this.ingredient );
}
};
console.log( skillet.ingredient ); //Bacon Strips
skillet.fry(); //Frying Bacon Strips

//Adding a public property to an Object Literal
skillet.quantity = "12";
console.log( skillet.quantity ); //12

//Adding a public method to an Object Literal
skillet.toString = function() {
console.log( this.quantity + " " +
this.ingredient );
};
skillet.toString(); //12 Bacon Strips​
You can execute and modify the above code from jsFiddle.

The above code declares a skillet variable and sets it to an Object Literal with one property (ingredient) and one method (fry) that are both publicly accessible off of the object. You can also add additional public methods and properties to the object after the initial declaration as shown above when adding the quantity property and the toString method. The toString method is able to access the properties of the skillet object since all of it’s parts are public.

Pros
•Cleans up the global namespace by adding a namespace to your properties and methods
•You can add functionality to the object literal at a later point
•All the properties and methods are public

Cons
•Uses the Object Literal syntax to define your properties and methods that some may find cumbersome
•There isn’t the ability to have private properties or methods

Self-Executing Anonymous Function: Part 1 (All Private)
Another common technique that you can use to protect the global namespace is to use a Self-Executing Anonymous Function. This is just a fancy term to refer to a function with no name that is immediately executed after it’s defined. The value of this technique is that you can create a wrapper around your code that protects it from the global namespace. By using the most simple version of the Self-Executing Anonymous Function you can create code that is exclusively private.
//Self-Executing Anonymous Function: Part 1 (All Private)
(function() {
//private variable
var ingredient = "Bacon Strips";

//private function
function fry() {
console.log( "Frying " + ingredient );
}

fry();
}());

//Variables not accessible
console.log( window.ingredient ); //Undefined

//Functions not accessible
try {
window.fry(); //Throws Exception
} catch( e ) {
//Object [object DOMWindow] has no method 'fry'
console.log( e.message );
}

//Can't add additional functionality
You can execute and modify the above code from jsFiddle.

The above code snippet wraps the ingredient variable and fry function with a Self-Executing Anonymous Function and right before the function ends it executes the fry method. After the Self-Executing Anonymous Function finishes executing there is no way to run the function again or reference any of the internals of the wrapped code.

Pros
•Hides all your implementation from external code
•The function runs once and only once
•The code inside doesn’t use the Object Literal notation

Cons
•All information is hidden, which may not be what you want
•Slightly more complicated technique, but not really

Revealing Module Pattern (Public & Private)
The Revealing Module Pattern actually uses the concept of the Self-Executing Anonymous Function as well, but in this case we save the result into a variable. This pattern introduces the concept of a Closure. A closure is a way to keep variables alive after a function has returned. The Mozilla Developer Network has a great page explaining closures. In it they provide a core definition:
“A closure is a special kind of object that combines two things: a function, and the environment in which that function was created. The environment consists of any local variables that were in-scope at the time that the closure was created.”

In the following example we will declare private properties and methods as well as public properties and methods.
//Revealing Module Pattern (Public & Private)
var skillet = (function() {
var pub = {},
//Private property
amountOfGrease = "1 Cup";

//Public property
pub.ingredient = "Bacon Strips";

//Public method
pub.fry = function() {
console.log( "Frying " + pub.ingredient );
};

//Private method
function privateWay() {
//Do something...
}

//Return just the public parts
return pub;
}());

//Public Properties
console.log( skillet.ingredient ); //Bacon Strips

//Public Methods
skillet.fry();

//Adding a public property to a Module
skillet.quantity = 12;
console.log( skillet.quantity ); //12

//Adding a public method to a Module
skillet.toString = function() {
console.log( skillet.quantity + " " +
skillet.ingredient + " & " +
amountOfGrease + " of Grease" );
};

try {
//Would have been successful,
//but can't access private variable
skillet.toString();
} catch( e ) {
console.log( e.message ); //amountOfGrease is not defined
}
You can execute and modify the above code from jsFiddle.

Inside of the Revealing Module Pattern we declared a pub object that will keep all the public properties and methods that you want to be exposed. At the end of the Module the pub object is returned, which is what causes the them to be public outside of the Self-Executing Anonymous Function. All the parts that were not added to the pub object remain private to the outside world; however, the public methods that were exposed have access to the private parts because of the Closure that was created.

Pros
•Allows for public and private properties and methods
•The Technique is Easy to understand
•The code inside doesn’t use the Object Literal notation

Cons
•Doesn’t allow for a way to add private properties to be used in new public methods

Self-Executing Anonymous Function: Part 2 (Public & Private)
We looked at the Self-Executing Anonymous Function earlier as a pattern you could use to keep all your code private. As it turns out, you can actually modify the pattern somewhat so that you can achieve the same benefits of the Revealing Module Pattern. Not only can we achieve public and private properties and methods, but we can also provide an easy way to extend the namespace while keeping the content protected from the global namespace. In addition, the following pattern can protect the $ from conflicting with other JavaScript libraries and also protect undefined from being redefined.

Take a look at the following example, and we will walk through the code explaining the key changes to the pattern.
//Self-Executing Anonymous Func: Part 2 (Public & Private)
(function( skillet, $, undefined ) {
//Private Property
var isHot = true;

//Public Property
skillet.ingredient = "Bacon Strips";

//Public Method
skillet.fry = function() {
var oliveOil;

addItem( "\t\n Butter \n\t" );
addItem( oliveOil );
console.log( "Frying " + skillet.ingredient );
};

//Private Method
function addItem( item ) {
if ( item !== undefined ) {
console.log( "Adding " + $.trim(item) );
}
}
}( window.skillet = window.skillet || {}, jQuery ));

//Public Properties
console.log( skillet.ingredient ); //Bacon Strips

//Public Methods
skillet.fry(); //Adding Butter & Fraying Bacon Strips

//Adding a Public Property
skillet.quantity = "12";
console.log( skillet.quantity ); //12

//Adding New Functionality to the Skillet
(function( skillet, $, undefined ) {
//Private Property
var amountOfGrease = "1 Cup";

//Public Method
skillet.toString = function() {
console.log( skillet.quantity + " " +
skillet.ingredient + " & " +
amountOfGrease + " of Grease" );
console.log( isHot ? "Hot" : "Cold" );
};
}( window.skillet = window.skillet || {}, jQuery ));

try {
//12 Bacon Strips & 1 Cup of Grease
skillet.toString(); //Throws Exception
} catch( e ) {
console.log( e.message ); //isHot is not defined
}
You can execute and modify the above code from jsFiddle.

First, since we have a Self-Executing Anonymous Function, we can actually provide some parameters to pass to it when it executes. In this case we are passing 2 arguments to the anonymous function.

The first argument looks quite strange. What is window.skillet = window.skillet || {} doing? The code checks to see if skillet exists in the global namespace (window). If it does not exist, then window.skillet is assigned an empty object literal. Using this approach we can build a library across JavaScript files. If another script uses the same technique, then it will pass in the existing instance and append logic to it. Inside the Anonymous Function, if we want something to be public, then we append it to the skillet object. Any other properties or methods will be considered private.

The second argument passed in jQuery. The benefit of this is that the named parameter is referenced as $, which allows us to refer to jQuery as $ within the Anonymous Function without having to worry that it will conflict with the $ declared in other JavaScript libraries. This is a common practice that you will most likely run across when looking at well written jQuery code.

You might notice a 3rd parameter to the Anonymous Function called undefined. Why did we add that parameter and why didn’t we pass an argument to it? In JavaScript, you can unfortunately redefine what undefined means. Imagine that some code somewhere deep in one of your 3rd party libraries redefines undefined to something strange like true. If anywhere in your code you test against undefined, then you code will most likely not behave like you intended. In JavaScript, if you have a parameter that doesn’t have a matching argument, then it’s value is set as undefined. By using this trick, it can save us from the bad code someone wrote to redefine undefined.

Pros
•Gives you the ability to have public and private properties and methods
•The code inside doesn’t use the Object Literal notation
•Keeps undefined’s value as undefined in case someone overrode the value
•Allows you to use $ inside your code without worrying about clashing with other libraries
•Allows your library to grow across files using the “window.namespace = window.namespace || {}” technique
•A common pattern that you will see in many libraries, widgets, and plugins

Cons
•Slightly more complicated pattern, but not overly difficult to understand
If you are interested in digging deeper into some of the patterns I mentioned above then I encourage you to check out Klaus Komenda’s post entitled JavaScript Programming Patterns. The article provides an insightful view of how JavaScript patterns have changed over the years.

Best Practice
In JavaScript it is very important to declare all of your variables and it is considered a best practice to limit the number of objects in the global namespace. Depending on the situation you are developing you may need one or more of the concepts listed above to organize your code and keep it from colliding with other libraries. There is no pattern that is a Silver Bullet, but rather you should assess where you are at and examine the pros and cons of each pattern to address your situation.

2. Not Declaring Arrays & Objects Correctly
JavaScript is a prototypal language and not a classical language like C#. Although JavaScript does have a new operator which looks a lot like C#, you should not use it for creating new objects or arrays.

What Not To Do
You might be tempted to use the new keyword to create your objects in JavaScript.

//Bad way to declare objects and arrays
var person = new Object(),
keys = new Array();
The new keyword was added to the language partially to appease classical languages, but in reality it tends to confuse developers more than help them. Instead, there are native ways in JavaScript to declare objects and arrays and you should use those instead.

Preferred Way
Instead of using the previous syntax, you should instead declare your objects and arrays using their literal notation.

//Preferred way to declare objects and arrays
var person = {},
keys = [];
Using this pattern you actually have a lot of expressive power using Object Literals and array initializer syntax. As we mentioned earlier, you should be careful to know that Object Literals are not JSON.
//Preferred way to declare complex objects and arrays
var person = {
firstName: "Elijah",
lastName: "Manor",
sayFullName: function() {
console.log( this.firstName + " " +
this.lastName );
}
},
keys = ["123", "676", "242", "4e3"];

Best Practice
You should declare all of your variables using their literal notation instead of using the new operation. In a similar fashion you shouldn’t use the new keyword for Boolean, Number, String, or Function. All they do is add additional bloat and slow things down.

The only real reason why you would use the new keyword is if you are creating a new object and you want it to use a constructor that you defined. For more information on this topic you can check out Douglas Crockford's post entitled JavaScript, We Hardly new Ya.

Conclusion
This article has covered some of the common issues you might address coming from C# to JavaScript. I have committed just about everyone of the above Bad Practices myself when I starting to code in JavaScript heavily.

With the recent serge of jQuery hitting the market and other great JavaScript libraries, it is important that we as developers understand the language instead of just thinking that our previous language knowledge will get us by.

This article only covers some of the things you should know. The next post in the series will be published next week. In the meantime please feel free to add comments of any other gotchas that you’ve experience coming from a C# background. I would love to hear about it. Sphere: Related Content

An API for parsing JavaScript

In new builds of the SpiderMonkey shell we’re introducing an experimental API for parsing JavaScript source code, which landed this week. For now, you have to download and build SpiderMonkey from source to use it, but hopefully we’ll include it in future versions of Firefox.

The parser API provides a single function:
Reflect.parse(src[, filename=null[, lineno=1]])

Reflect.parse takes a source string (and optionally, a filename and starting line number for source location metadata), and produces a JavaScript object representing the abstract syntax tree of the parsed source code, using the built-in parser of SpiderMonkey itself. Straightforward enough, but behind this simple entry point is a thorough API that covers the entirety of SpiderMonkey’s abstract syntax. In short, anything that SpiderMonkey can parse, you can parse, too. Developer tools generally need a parse tree, and JavaScript isn’t an easy language to parse. With this API, it becomes much easier to write tools like syntax highlighters, static analyses, style checkers, etc. And because Reflect.parse uses the same parser that SpiderMonkey uses, it’s guaranteed to be compatible.

Here’s a simple example:
js> var ast = Reflect.parse("obj.foo + 42");
js> var expr = ast.body[0].expression;
js> expr.left.property
({loc:null, type:"Identifier", name:"foo"})
js> expr.right
({
loc: {
source: null,
start: {
line: 1,
column: 10
},
end: {
line: 1,
column: 12
}
},
type: "Literal",
value: 42
})
Try it out, and feel free to give me feedback!

This entry was posted on Wednesday, August 25th, 2010 at 11:00 am and is filed under Announcements, SpiderMonkey. You can follow any comments to this entry through the RSS 2.0 feed. Both comments and pings are currently closed.

PS: SpiderMonkey Build Documentation Sphere: Related Content

Dynamic favicons

Google Calendar released a new favicon which prompted a few mentions from friends on Twitter. The first, probably more important was from Cennydd:
New Google Calendar icon most un-Googley. I like it.

Then Danny pitched in with:
I see Google Calendar has a new icon. They could use the current date rather than "31" though

So let's fix that shall we?

How it's done
The trick here is to use a canvas element and export the image data as a png. Since favicons can be pngs then we know this can work. Note that this technique has been done before.

The setup is needing to create two calendar images: one with the date if this doesn't work (defaulting to something like 31) and the second without the date text. For whatever reason, I went and replicated the Google Calendar icon in Photoshop:


The plan now is to use the favicon template and lay the text over. Simple.
The minimum starting point

Start your document by including the favicon link element in the head:
link id="favicon" rel="icon" type="image/png" href="ical-icon-complete.png"
The "complete" version is the favicon with the 31 on it already. Next we'll use JavaScript to dynamically create the favicon.

Using a canvas for dynamic favicons
We need the following items to make this effect work:
1. A canvas that doesn't have to live in the DOM, that's 16x16 - our favicon size
2. The template favicon image
3. Once, and only once, the template image has loaded, we then go adding the text
4. The date in a two character format, i.e. 04 is the 4th
That's it. For connivence I've added an id to the link element so that I can just change the href when the image is ready. The following JavaScript can be included anywhere below the link element:
(function () {
var canvas = document.createElement('canvas'),
ctx,
img = document.createElement('img'),
link = document.getElementById('favicon').cloneNode(true),
day = (new Date).getDate() + '';

if (canvas.getContext) {
canvas.height = canvas.width = 16; // set the size
ctx = canvas.getContext('2d');
img.onload = function () { // once the image has loaded
ctx.drawImage(this, 0, 0);
ctx.font = 'bold 10px "helvetica", sans-serif';
ctx.fillStyle = '#F0EEDD';
if (day.length == 1) day = '0' + day;
ctx.fillText(day, 2, 12);
link.href = canvas.toDataURL('image/png');
document.body.appendChild(link);
};
img.src = 'ical-icon.png';
}

})();
The important part is the order in which the code runs. It creates an image element, and hooks an onload event handler. When this onload event runs, it draws the image on to the canvas using ctx.drawImage(this, 0, 0). this refers to the image the onload event acted upon, and 0, 0 is the top, left position to start drawing.

Next we style the text and draw it on.

Finally using canvas.toDataURL we set a new href to the link.

You should be able to see the code running on this blog post, if you look at the favicon associated with this page, it should be the calendar icon with the correct date if your browser supports the canvas API (IE8 and below don't, all other browsers do).
Try changing the date to test it out.

A few people having pointed out that in fact trying to change favicons in IE is not possible. I've read around this a bit now, and it looks like there isn't a way - good thing we're just adding a sprinkle of sexiness then, eh? Sphere: Related Content

Occam’s Razor: A Great Principle for Designers

Lex parsimoniae is the Latin expression of what is known in English as Occam’s Razor, a philosophical rule of thumb that has guided some of the world’s best and brightest minds (including Isaac Newton).
It is named after the 14th-century logician and theologian William of Ockham.
But what the heck does Occam’s Razor have to do with web design? I’m glad you asked. To put it plainly, Occam’s Razor states that the simplest explanation is usually true.
For our purposes, to use Occam’s Razor is to do something in the simplest manner possible because simpler is usually better.
In this article, we’ll show you how to use Occam’s Razor to create better websites and to enhance the user experience, both for yourself and your clients.
Before we dive into the details, let’s look at a real-world example of Occam’s Razor as used by a company whose simple and effective products you are certainly familiar with: 37signals.

A Real-World Example

37signals founders Jason Fried and David Heinemeier Hanson are the brains behind some of the web’s most interesting products and technologies. Among their small yet influential ranks, they practice and preach a simplicity akin to Occam’s Razor.

It has served them well over the past decade. What began as a three-person Web design consulting firm in 1999 now has three million worldwide users of its software products (which include Basecamp, Campfire and Highrise). Basecamp alone generates millions of dollars for the company, and the company employs just 16 people. Did I mention that they are responsible for developing the wildly popular open-source programming framework Ruby on Rails? Here’s a quote to drive it home (from Rework, the duo’s latest book):
Lots of people hate us because our products do less than the competition’s. They’re insulted when we refuse to include their pet feature. But we’re just as proud of what our products don’t do as we are of what they do. We design them to be simple because we believe most software is too complex: too many features, too many buttons, too much confusion.

This business case makes clear, and Jason Fried would probably tell you so himself: doing things the simple way makes perfect business sense. It’s more than logical: it’s smart. Here’s how to make simple work for you.

Simple Web Design

Designing simply for the web is about removing barriers. If a user wouldn’t know where to click, tell them. If there are too many navigational choices, eliminate some. If the background image distracts from the message, tone it down.

In architecture, a cool design should not compromise the strength of the structure or make it difficult to get from point A to point B. Similarly, a cool web design shouldn’t compromise the clarity of the message you are trying to convey or make it difficult for the user to navigate from page A to page B.

When your goals are specific—such as converting visitors into customers or getting users to initiate contact—anticipating and eliminating potential obstacles is crucial, especially during the design phase. Too often designers build something cool without first figuring out how to achieve their goals or anticipating how easy the design will be to navigate, which can lead to constant redesigns, perpetual tweaking, lost time and lost money.

Simple goes hand in hand with easy. The next time you open Photoshop to begin a new design, ask yourself questions like these:
* Would a non-designer or non-programmer find this interface confusing?
* Do I need all of this information along the top that pushes the newsletter sign-up form below the fold?
* How easy will users be able to access the information they want?
* Are there too many choices?
* Will this interface be usable for my target audience, a 70-year-old person or someone with partial blindness?

You get the point.
Simple designs are good for another reason: differentiation. If you want your website to survive in a niche dominated by over-the-top glitz and glam, create some contrast by building a simple layout.

Simple Coding

A buzzword floating around the web right now related to coding is “lightweight,” which is just another way of saying “simple.”

It’s common knowledge that simple code loads faster and generally encounters fewer problems. If you could implement a solution using lightweight code rather than a bloated alternative, the choice would be obvious. What keeps developers from doing it then?

Bloated code has two main causes. One is laziness. People love to copy and paste. Code libraries such as jQuery and frameworks such as the 960 Grid System are useful, but they have fostered a lazy mentality, which can lead to bloated code. How can you be sure your website is as simple as it can be if someone else has written the code?

Just as a mechanic should be familiar with what’s under the hood, so a developer should be familiar with the code running their website. What if something breaks? How would you fix it? Just because a solution works doesn’t mean that it is the simplest or best way to handle your case.

The other cause of bloated code is lack of knowledge. Many designers and developers—even some who claim to be advanced—have become stuck using programs like Dreamweaver to code their websites, and they sometimes rely on them to produce code for them.

Sure, these programs can produce code, but they don’t always do it efficiently; they simply execute a command based on what they were programmed to do. Instead, by using tricks such as CSS shorthand, you can optimize code for faster loading times, which will ultimately improve the user experience.

Simple E-Commerce

When it comes to selling online, simplicity should knock content right off the throne and assume its rightful place as king of the realm of e-commerce. Why? Because what you’re selling won’t matter if making a purchase is too difficult. If making purchases is easy, fewer shopping carts will be abandoned and more sales will be made.

So, what can you do to make online shopping simpler? While each experience should be unique and tailored to the needs of the company and its users, there are a few easy ways to boost the effectiveness of an online store:
* Make the search box prominent. Searching will probably be the preferred navigation method of many users, especially if you offer hundreds or thousands of products for sale.
* Don’t waste people’s time by making them duplicate information. For example, make it easy for users to indicate that their shipping address is the same as their billing address by adding a simple check box to the form.
* Don’t crowd products too closely together.
* Don’t annoy shoppers with unexpected pop-ups and hover tips. There’s a fine line between hand-holding users and trusting them to do things on their own.

Simple Web Copy

The majority of websites rely on text to share their services, products and ideas. Doesn’t it make sense to phrase things so that they’re easily understandable? Remember, simplicity appeals to everyone regardless of their sophistication or ability.

The familiar KISS acronym (keep it simple, stupid) should hang on a giant plaque above the desk of anyone responsible for web copy. Your website is accessible from just about every corner of the globe, which means that simple copy is the best way to target the widest possible audience.

Forget about dictionary-style definitions and cramming keywords down people’s throats (those taste good only to search engines). Say what needs to be said as briefly as you can. Trying to sound smart on the web is just plain stupid: you’ll leave readers confused, and a more interesting website is always just a few clicks away.

Simple Business Practices

Sometimes you can make things simpler and easier for you and your client; other times you can make things simpler and easier for just one of you. If you have to choose, favor your client.

Online shopping carts are abandoned when things get too complicated; so too do clients abandon working relationships that are too difficult to maintain.

Ask yourself questions like: How easy am I to contact? How easy would it be for me to pay my own invoice? (If you wouldn’t want to pay your own invoice, think how daunting it must be for your clients, who aren’t tech-savvy.) If your customers have to press three buttons and wait on hold before speaking with you, perhaps you should rethink your phone system.

Conclusion
I can’t write about simplicity without mentioning Apple. Simplicity has real value, and it can be measured in cold hard cash. That much is clear to Apple’s CEO, Steve Jobs, whose personal net worth now tops $5 billion. He has delivered some of the world’s coolest, most user-friendly gadgets.

Simplicity is built into the iPhone and iPad; each device features only one button on the front. The MacBook is made from a single piece of aluminum. And simplicity is why so many designers imitate Apple’s website (the white space, the navigation, the large photography).

Apple even extends simplicity to its packaging. When I recently replaced my Dell workstation with an iMac, my jaw dropped as I shifted my gaze between the single power cord coming out of the back of the Mac to the pile of cords snaking along the floor next to the old Dell. That’s the power of simplicity. The team in Cupertino, California, puts Occam’s Razor into action and reaps the benefits.

You might ask… why would an advanced designer or developer want to simplify? Isn’t that regressing? I would say that while beginners must use a simple product because that’s what they are capable of handling, this isn’t necessarily the best case for simplicity. Pros choose to impose constraints on their work so that they can create a better product.

It might be time to rethink the way you design for the Web. Experiencing a website shouldn’t just be easy: it should be painless. Make navigation effortless so that users focus more on the content than on how to access it.


Written exclusively for WDD by Chris McConnell. He is an entrepreneur, designer and author who co-founded the design firm Brandeluxe and writes regularly on his blog, Freelance Review. You can also connect with Chris on Twitter.

Do you apply the Occam’s Razor principle in your designs? Why or why not? Share your opinion below… Sphere: Related Content

Some lesser-known truths about programming

August 17th, 2010 David Veksler

My experience as a programmer has taught me a few things about writing software. Here are some things that people might find surprising about writing code:
* A programmer spends about 10-20% of his time writing code, and most programmers write about 10-12 lines of code per day that goes into the final product, regardless of their skill level. Good programmers spend much of the other 90% thinking, researching, and experimenting to find the best design. Bad programmers spend much of that 90% debugging code by randomly making changes and seeing if they work.
“A great lathe operator commands several times the wage of an average lathe operator, but a great writer of software code is worth 10,000 times the price of an average software writer.” –Bill Gates
* A good programmer is ten times more productive than an average programmer. A great programmer is 20-100 times more productive than the average. This is not an exaggeration – studies since the 1960′s have consistently shown this. A bad programmer is not just unproductive – he will not only not get any work done, but create a lot of work and headaches for others to fix.
* Great programmers spend little of their time writing code – at least code that ends up in the final product. Programmers who spend much of their time writing code are too lazy, too ignorant, or too arrogant to find existing solutions to old problems. Great programmers are masters at recognizing and reusing common patterns. Good programmers are not afraid to refactor (rewrite) their code constantly to reach the ideal design. Bad programmers write code which lacks conceptual integrity, non-redundancy, hierarchy, and patterns, and so is very difficult to refactor. It’s easier to throw away bad code and start over than to change it.
* Software obeys the laws of entropy, like everything else. Continuous change leads to software rot, which erodes the conceptual integrity of the original design. Software rot is unavoidable, but programmers who fail to take conceptual integrity into consideration create software that rots so so fast that it becomes worthless before it is even completed. Entropic failure of conceptual integrity is probably the most common reason for software project failure. (The second most common reason is delivering something other than what the customer wanted.) Software rot slows down progress exponentially, so many projects face exploding timelines and budgets before they are killed.
* A 2004 study found that most software projects (51%) will fail in a critical aspect, and 15% will fail totally. This is an improvement since 1994, when 31% failed.
* Although most software is made by teams, it is not a democratic activity. Usually, just one person is responsible for the design, and the rest of the team fills in the details.
* Programming is hard work. It’s an intense mental activity. Good programmers think about their work 24/7. They write their most important code in the shower and in their dreams. Because the most important work is done away from a keyboard, software projects cannot be accelerated by spending more time in the office or adding more people to a project. Sphere: Related Content