We can create a div, or really any element you want, to hold our templates. What does this gain us? Well if we are using a design tool, we can see what the template will look like before we have to render it. That may make it easier for a designer on your project. We don't have to make an AJAX call out to retrieve the external template, although Dave talks about how this really isn't an issue if you have caching set up correctly on your server. And frankly, for the amount of bytes that are in a typical template I can't imagine any successful AJAX request taking very long.

To use them, you simply grab the templates div and detach it from the DOM. If you assign the detached elements to a var, you can just use jQuery selectors to find the one you want to use. Because, remember most of the jQuery methods return the jQuery object itself.

Why do you want to use the detach method rather than the remove method? The detach method removes the elements from the DOM but keeps any jQuery data associated with them intact. Meaning you can use the $.data() method to add data to your templates and access the data before you compile your templates.
Dave Ward points out that I need to use "tempates.find()" rather than the default selector method on the jQuery object. Noted and updated

Powered by Twitter Tools

Powered by Twitter Tools

I'm not registering for PDC10, but I will register for PDC10 afterparties. #

“@dorianmuthig: Lala ” got me on my knees #

Powered by Twitter Tools

Powered by Twitter Tools

The main work in any software development project is FIGURING OUT WHAT TO BUILD. How you build it is trivial compared to the amount of time and effort you SHOULD put into discovering the users needs and working with them to solve their problems and make their life better.

Remember, that's the number one purpose for any piece of computer hardware or software. This cannot be stressed and repeated enough.

COMPUTERS SHOULD MAKE OUR LIVES BETTER!

How do we write programs that make lives better? By writing programs that fulfill their needs and ease the pain of their work. We still aren't at a point where we have a common, easy to understand vocabulary when it comes to build software. We often get it wrong the first, second, and third times. That's where the discipline and engineering comes into play.

Step 1 – Download and install VirtualBox orVMWare Player. I chose VirtualBox. It’s free, and supports 64-bit guests.

Step 2 – Download The Turnkey Linux core appliance and unzip it somewhere. This handy little virtual machine is based on Ubuntu and give you a basic command line environment with networking.

Step 3 - Import the Turnkey core appliance into VirtualBox.

Choose the .ovf file in the Turnkey directory you unzipped earlier.

Click next and review the settings, making any changes as you see fit. The defaults should work fine. Then click import.

Once Virtualbox finishes importing the virtual machine, you can start it up.

Assuming your network is configured correctly, the virtual machine will grab an IP from your DHCP server and be ready to go.

Step 4 – At this point you can either SSH into the virtual machine or you can connect using the web shell at the address indicated in the startup screen. Initially you can connect using as the root account with no password. You are almost ready to start installing node.js. First type "apt-get update" at the command line to make sure you have all the latest package information.

Step 5 – Install the developer tools you need to get and build node.js. Node.js isn’t packaged as a binary, you have to build it from source. Luckily it includes it’s dependencies and is pretty easy to build. But first we need to get a compiler. Type “apt-get install build-essential” and hit return. A lot of text will fly past, if it asks you if you want to go ahead press “y”.

Step 6 – Install Git. Now you’ve got a compiler installed, we have to install git so we can fetch node.js from the repository. At the command prompt type “apt-get install git”. Once that is complete, type “apt-get install git-core”.

Step 7 – Clone the node.js Git repository. If you want to put node.js is a specific directory, go ahead and make it then “cd” into the new directory. At the command prompt, type “git clone git://github.com/joyent/node.git“.

Step 8 – configure the source for building. type “cd node” and change into the node directory that Git created. Type “./configure”. You may see a few “fail” messages. Don’t worry about them.

Step 9 – Build node.js. Type" “make” at the command prompt. Get a sandwich or a nice cool drink. It doesn’t take very long, but it’s not very exciting unless the Matrix screensaver is your favorite screen saver.

Step 10 – Install node.js and start build applications. Type “make install” once the build is complete. Once that is complete,you can type “node” at the command prompt and you should see the standard help information fly by.

Building a node module or application is beyond the scope of this short tutorial. I suggest reading up at the Node.js site.

1. Help out with the MVC Turbine docs
2. Finish my Ringbinder project and release it
3. Write a simple little app for use at home in either Clojure or Smalltalk
4. Continue to learn Python
5. Write a small app that runs on the Google App Engine
6. Write a blog post, either here or on my work blog, at least once a week
7. Redesign this blog
8. Work on and launch the coderdads.info site I've had in mind for a while

I'm sure I'll come up with more as the year progresses and I, hopefully, finish up these tasks.

I have a small battery powered Dremel rotary tool. It works for very small jobs. There have been a couple of times when I’ve had to push it way beyond it’s limit, including once when I needed to make the opening on a door jam for a strike plate a little wider. It took me forever. I had to charge the battery twice and broke a bit before I finally had enough room, but just barely enough room. Contrast that with the locksmith who had to do the exact same thing. He pulled out a much larger Dremel that plugged into the wall. Where it took me almost 45 minutes to rout out the door jam, he took about 2 minutes with his much more powerful tool. I could have stopped, went to the store, and bought a more powerful tool and gotten the job done much faster. But I thought that this tool would do the trick and going to the store would have cost me some resources, it might have taken a little longer. I’d have to learn how to use the new tool. Get a new bit. But overall, it probably would have saved me some time in the future and probably would have saved me some time on that project. I could definitely find other uses for the new tool.

Think about that the next time you reject a new programming tool because you think it might take too long to learn or it’s different. Instead of doing the hacky way you KNOW will work, check to see if there is a more elegant or permanent solution.  Because if you aren’t careful, your cheap and easy workaround might end up sticking around in the project long enough for it to become a problem to you.

And so for 20 years now these folks ---
*the* shining lights, in many ways, of "practical" programming
language, operating systems, and general systems research --- have
continued to fail to "get" the fundamental practical needs of everyday
programmers working in The Real World. "Go" is just another language
written first for the compiler and only secondarily for the programmer
--- and stuck in a 70s mindset* about the relationship of that
programmer to the (digital) world within which they live and work!
(But hey, it compiles fast! Which is, of course, THE problem that
really needs addressing.)

He then goes on to talk about some aspects of languages that frustrate him.

J.H.C, folks, it's nearly 2010. Let's get a few things straight:

- most programming involves schlepping a few but complex data types
between different string representations
- programmers have become plumbers and documentation-archaeologists
mostly, which is sad and uninteresting
- programming languages are for *programmers* --- not compilers and
compiler-writers
- until you make the everyday, "simple" things simple, it will
continue to be a dark art practiced by fewer and fewer
- any language that makes you explicitly import an IO module to
read a file or stdin is fucked
- declarations are a pointless anachronism (same for explicit
memory management)
- if I have to understand category theory to write a program that
does IO, IT IS A NON STARTER!
- less stupid line-noise syntax and punctuation, people

I don't understand why the need to compile fast is such a big deal. If your programming language makes you write so much code that it takes more than a few seconds to compile, you should probably look at using a different language. Here are some things that I'd like to see in a programming language that is designed for programmers rather than compilers or computers.

1) No typing - That's not to say that I can't declare my own types, classes, objects, etc... But that calls to objects should be type independent. (e.g. messaging and dynamic dispatch)

2) Built in unit testing - I should be able to declare contracts on the methods and pass/fail criteria. The tests should be run as part of the compile step or interpretation (if the language is compiled or interpreted)

3) Jellybeans

4) Automatic inclusion of libraries based on path and usage. - I don't mind having to pull in a library to do file I/O or consume some other kind of data like ATOM or JSON. But at compile time, if I have referenced any of the objects contained in the library, all of the references to the library should be handled for me automatically. Any name collisions should be compiler warnings so I can specify which library to use by in my code or make the reference explicit in some other way. I like Pythons path based module convention, the language should just search the child directories for a library if the library isn't already included in the base language pack.

5) Anytime a design pattern emerges, it should be re-factored into the language itself.

6) It should be a pocket language, have a set of keywords and syntax that is small and compact but still understandable. JavaScript and C are good examples of pocket languages. It's easy to pick up the syntax.

I'm sure there's more that I would add. What kinds of features would you like to see in a language oriented towards programmers rather than compilers?