This contract is not meant to trick or deceive you; the intention is purely to protect both parties. I have tried to keep the wording as plain as possible, but if anything is unclear, please let me know and I will be more than happy to clarify it with you. Also, until you sign it, please feel free to request to change bits of it to suit your requirements.
In short, [client name] is contracting me, [my name], to [description of my role] between [start date and finish date].
By signing this, you are confirming that you have the power and ability to enter into this contract on behalf of [client's company].
| General | |
| 1. Site uses a cache buster for expiring .js, .css, and images | |
| 2. JavaScript and CSS is minified and concatenated into logical groupings | |
| 3. Images have been optimized by ImageOptim (http://imageoptim.com/) | |
| Markup | |
| 1. Code does not contain inline JavaScript event listeners |
⇐ back to the gist-blog at jrw.fi
Or, 16 cool things you may not have known your stylesheets could do. I'd rather have kept it to a nice round number like 10, but they just kept coming. Sorry.
I've been using SCSS/SASS for most of my styling work since 2009, and I'm a huge fan of Compass (by the great @chriseppstein). It really helped many of us through the darkest cross-browser crap. Even though browsers are increasingly playing nice with CSS, another problem has become very topical: managing the complexity in stylesheets as our in-browser apps get larger and larger. SCSS is an indispensable tool for dealing with this.
This isn't an introduction to the language by a long shot; many things probably won't make sense unless you have some SCSS under your belt already. That said, if you're not yet comfy with the basics, check out the aweso
The following document is a written account of the Code School screencasting framework. It should be used as a reference of the accompanying screencast on the topic.
You're probably aren't going to take the time to read this document if you're not interested, but there are a lot of nice side effects caused by learning how to create quality screencasts.
| DO WHAT THE FUCK YOU WANT TO PUBLIC LICENSE | |
| Version 2, December 2004 | |
| Copyright (C) 2011 YOUR_NAME_HERE <YOUR_URL_HERE> | |
| Everyone is permitted to copy and distribute verbatim or modified | |
| copies of this license document, and changing it is allowed as long | |
| as the name is changed. | |
| DO WHAT THE FUCK YOU WANT TO PUBLIC LICENSE |
| #!/usr/bin/env ruby | |
| #/ Usage: <progname> [options]... | |
| #/ How does this script make my life easier? | |
| # ** Tip: use #/ lines to define the --help usage message. | |
| $stderr.sync = true | |
| require 'optparse' | |
| # default options | |
| flag = false | |
| option = "default value" |
The following document is a written account of the Code School screencasting framework. It should be used as a reference of the accompanying screencast on the topic.
You're probably aren't going to take the time to read this document if you're not interested, but there are a lot of nice side effects caused by learning how to create quality screencasts.
