Pages

26 February, 2012

CSS 3D Text-Shadow Magic with Less.js

I just found Mark Ottos CSS-based 3D-Text. His CSS class is fixed to a certain font-size, and I decided to create a Less-class for this. Here it is:
.shadow-3d (@color#fff, @size: 20px) {
    @o: @size/80;
    @c: @color - 48;
    color: @color;
    font-size: @size;
    text-shadow:
        0 @o    0 @c - 8,
        0 @o*2  0 @c - 16,
        0 @o*3  0 @c - 24,
        0 @o*4  0 @c - 32,
        0 @o*5  0 @c - 48,
        0 @o*6  @o    rgba(0,0,0,.1),
        0 0     @o*5  rgba(0,0,0,.1),
        0 @o*1  @o*3  rgba(0,0,0,.3),
        0 @o*3  @o*5  rgba(0,0,0,.2),
        0 @o*5  @o*10 rgba(0,0,0,.25),
        0 @o*10 @o*10 rgba(0,0,0,.2),
        0 @o*20 @o*20 rgba(0,0,0,.15);
}

And here you can see it in action (via Less-compiled CSS-classes):

Big Text

Small Text


Now isn't that fancy?
Stay tuned for more magic with modern web-technologies!

-- Juve

23 February, 2012

I just can't remember bash/batch Syntax - CoffeeScript to the rescue!

I regularly need some scripts for copying files to folders or remote servers, for creating folders, checking file existence, etc. The scripts should also be able to accept parameters. Often I try to write a bash script for these tasks, but it always takes much longer than expected. Similarly, on Windows, I do the same with batch/cmd-files, whose syntax is not much better to remember than bash.

I will not do this anymore, it is too cumbersome for me!

From now on, I will use a language I know very well: JavaScript!. Might sound strange but it is actually quite easy. I use node.js as "interpreter" and call the OS functions via the child_process or fs modules.  Esp. error checking is much more versatile now!
Combine that with CoffeeScript, and take shell/batch-scripting tasks to the next level, including easy async. task execution with callbacks! Thanks to CoffeeScript, I get rid of the bad parts of JavaScript. Here is a simple copy script as example (replace the echo cmd with a copy command of your choice)
fs     = require("fs")
exec   = require("child_process").exec
files  = process.argv.slice 2
target = files.pop()     #last arg is target dir/name

stop_onerror = true
error_count  = 0

copy_next = ->
    if files.length == 0 then stop()
    else
        file = files.pop()
        exec "echo copying #{file} to #{target}", (error, out) ->
            console.log out.trim()
            if error?
                console.error "ERROR(#{error_count++})! copy of #{file} failed"
            if error? && stop_onerror then stop() else copy_next()

stop = ->
    if error_count > 0
        console.log "Files copied (with #{error_count} errors)."
    else
        console.log "All files copied successfully."

usage = -> console.log '''
    Usage (with node)
        node   script.js     file1 file2 file3 ... target

    Usage (with coffee)
        coffee script.coffee file1 file2 file3 ... target
    '''

if files.length > 0 && target? then fs.stat target, (error, fstat) ->
    if error? then console.log "#{target} not found!"
    else console.log "copying #{files} to #{target}"; copy_next()
else usage()
This basic script just mimics a normal copy command and is therefore rather useless. But it shows that you can easily combine node.js' file-system functions with operating system calls via exec, and that it is really easy to add more features, such as automatic target-dir creation, file-renames, error logging, etc. Esp. such error checking and other conditional stuff is really cumbersome in plain bash/batch scripting.

Ciao, Juve

Edit: Using bash a lot in the past years, I am now happy with it and actually like it. I also do not have a Windows PC/Laptop anymore and can often safely rely on the *nix commands: cp, mv, rmdir, mkdir to deal with files. However, For real software development, you should better conduct file-related tasks using build and deployment scripts, e.g., using Grunt.

19 February, 2012

To prototype or not to prototype?

I am using jsperf a lot lately. Here is another interesting result:

Prototype-based object creation is lightning fast, compared to returning plain objects from simple functions. (see my test on jsperf)



But using prototype-based stuff usually forces you to access properties via this
which is an additional lookup in the prototype chain, that will add some overhead when accessing these object a lot. (see my other test on jsperf)



For you as a JavaScript developer, this means you have to consider the following.

  • Is my code creating a lot of (similar) objects? Then you should setup some reusable types by using prototypes.
  • Is my code accessing properties of some of my objects a lot? Then you should get rid of the access via this and add some for form of property caching in local variables.
Ciao,
Juve