Color = function() {
};

Color.hexdec = function(hex_string) {
    hex_string = (hex_string + '').replace(/[^a-f0-9]/gi, '');
    return parseInt(hex_string, 16);
}

Color.dechex = function(number) {
    if (number < 0) {
        number = 0xFFFFFFFF + number + 1;
    }
    return parseInt(number, 10).toString(16);
}

Color.pad = function(number, length) {
    var str = '' + number;
    while (str.length < length) {
        str = '0' + str;
    }
    return str;
}

Color.calcgrad = function(val, color1, color2) {

    if(!color1.match(/^#[0-9a-f]{6}/) || !color2.match(/^#[0-9a-f]{6}/)) return 'match err!';

    if (val > 1) {
        val = 1;
    }
    if (val < 0) {
        val = 0;
    }
    val = parseFloat(val);

    c1 = [Color.hexdec(color1.substr(1,2)), Color.hexdec(color1.substr(3,2)), Color.hexdec(color1.substr(5,2))]; //b
    c2 = [Color.hexdec(color2.substr(1,2)), Color.hexdec(color2.substr(3,2)), Color.hexdec(color2.substr(5,2))]; //r

    if (val < .5) {
        delta = [(c2[0] - c1[0]), (c2[1] - c1[1]), (c1[2] - c2[2])];
        arrColor = [c1[0] + * 2), c1[1] - * 2), c1[2] - * 2)];
    }
    return '#'+Color.pad(Color.dechex(arrColor[0]),2)+Color.pad(Color.dechex(arrColor[1]),2)+Color.pad(Color.dechex(arrColor[2]),2);
}

1. delta[0] * val) * 2), c1[1] + ((delta[1] * val) * 2), c1[2] - ((delta[2] * val) * 2)]; } else { delta = [(c1[0] - c2[0]), (c1[1] - c2[1]), (c1[2] - c2[2])]; arrColor = [c1[0] - ((delta[0] * (val - .5
2. delta[1] * (val - .5
3. delta[2] * (val - .5

Share/Save

High-level language. The chief reasons for using a high-level language are productivity and debugging speed. We have discussed productivity earlier (Chapter 8). There is not a lot of numerical evidence, but what there is suggests improvement by integral factors, not just incremental percentages.

The debugging improvement comes from the fact that there are fewer bugs, and they are easier to find. There are fewer because one avoids an entire level of exposure to error, a level on which one makes not only syntactic errors but semantic ones, such as misusing registers. The bugs are easier to find because the compiler diagnostics help find them and, more important, because it is very easy to insert debugging snapshots.

For me, these productivity and debugging reasons are overwhelming. I cannot easily conceive of a programming system I would build in assembly language.

Well, what about the classical objections to such a tool? There are three: It doesn’t let me do what I want. The object code is too big. The object code is too slow.

As to function, I believe the objection is no longer valid. All testimony indicates that one can do what he needs to do, but that it takes work to find out how, and one may occasionally need unlovely artifices.

As to space, the new optimizing compilers are beginning to be very satisfactory, and this improvement will continue.

As to speed, optimizing compilers now produce some code that is faster than most programmer’s handwritten code, Furthermore, one can usually solve speed problems by replacing from one to five percent of a compiler-generated program by handwritten substitute after the former is fully debugged.

Fred Brooks, The Mythical Man-Month, pg. 135

Share/Save

Dorothy Sayers, in her excellent book, The Mind of the Maker, divides creative activity into three stages: the idea, the implementation, and the interaction. A book, then, or a computer, or a program comes into existence first as an ideal construct, built outside time and space, but complete in the mind of the author. It is realized in time and space, by pen, ink, and paper, or by wire, silicon, and ferrite. The creation is complete when someone reads the book, uses the computer, or runs the program, thereby interacting with the mind of the maker.

This description, which Miss Sayers uses to illuminate not only human creative activity but also the Christian doctrine of the Trinity, will help us in our present task. For the human makers of things, the incompletenesses and inconsistencies of our ideas become clear only during implementation. Thus it is that writing, experimentation, “working out” are essential disciplines for the theoretician.

In many creative activities the medium of execution is intractable. Lumber splits; paints smear; electrical circuits ring. These physical limitations of the medium constrain the ideas that may be expressed, and they also create unexpected difficulties in the implementation.

Implementation, then, takes time and sweat both because of the physical media and because of the inadequacies of the underlying ideas. We tend to blame the physical media for most of our implementation difficulties; for the media are not “ours” in the way the ideas are, and our pride colors our judgment.

Computer programming, however, creates with an exceedingly tractable medium. The programmer builds from pure thought-stuff: concepts and very flexible representations thereof. Because the medium is tractable, we expect few difficulties in implementation; hence our pervasive optimism. Because our ideas are faulty, we have bugs; hence our optimism is unjustified.

Fred Brooks, The Mythical Man-Month, pg. 15

Share/Save

First, here is a pretty good and in-depth video on HTML and CSS basics:

Next we have several handy beginner’s tutorial sites:

• HTML Dog’s CSS Beginner
• Friendly Bit’s Beginner’s Guide to CSS and Standards
• Your HTML Sourse’s Introduction to CSS
• W3 Schools CSS Tutorial (also an excellent reference site)

Finally, here are a few CSS frameworks designed to help make CSS a lot easier by providing a standard system that takes care of much of the common ugly quirks found in CSS:

• Blueprint
• 960 Grid System
• ElastiCSS

As a bonus, here are a few inspirational sites to help give you an idea of what CSS can do if applied properly:

• CSS zen garden
• CSS Magnifying glass
• 3D Coke can in CSS

Share/Save