NOTE I now use the conventions detailed in the SUIT framework
Used to provide structural templates.
Pattern
t-template-name
NOTE I now use the conventions detailed in the SUIT framework
Used to provide structural templates.
Pattern
t-template-name
<!doctype html> | |
<!-- | |
WARNING! | |
You probably shouldn't use this technique since images never show up | |
if the script isn't loaded for one reason or another. Some reasons: | |
- The content is viewed using a RSS reader | |
- The content is viewed with a read-it-later service | |
- The user has a flaky connection (hotel wifi, Dutch train, etc) | |
--> |
/* | |
A (very) WIP collection of optimized/recommended jQuery plugin patterns | |
from @addyosmani, @cowboy, @ajpiano and others. | |
Disclaimer: | |
----------------------- | |
Whilst the end-goal of this gist is to provide a list of recommended patterns, this | |
is still very much a work-in-progress. I am not advocating the use of anything here | |
until we've had sufficient time to tweak and weed out what the most useful patterns |
@mixin border-radius($radius, $prefixes: -moz -webkit -o) { | |
@each $prefix in $prefixes { | |
#{$prefix}-border-radius:$radius; | |
} | |
border-radius:$radius; | |
} | |
#id { | |
@include border-radius(5px, -moz -webkit); |
#Lessons From A JavaScript Code Review
I was recently asked to review some code for a new JavaScript application and thought I might share some of the feedback I provided as it includes a mention of JavaScript fundamentals that are always useful to bear in mind. Code reviews are possibly the single biggest thing you can do to improve the overall quality of your solutions and if you're not actively taking advantage of them, you're possibly missing out on bugs you haven't noticed being found or suggestions for improvements that could make your code better.
##Challenges & Solutions
Code reviews go hand-in-hand with maintaining strong coding standards. That said, standards don't usually prevent logical errors or misunderstandings about the quirks of a programming language. Even the most experienced developers can make these kinds of mistakes and code reviews can greatly assist with catching them.
Often the most challenging part of code reviews is actually finding an experienced developer you trust to complete
app.get('/help', function(req, res){ | |
res.send('some help'); | |
}); | |
app.get('/search/:query/p:page', function(req, res){ | |
var query = req.params.query | |
, page = req.params.page; | |
res.send('search "' + query + '", page ' + (page || 1)); | |
}); |
See the official Susy site for 1.0 documentation.
For this tutorial I'm assuming you are already comfortable with CSS, Sass (I'll use the SCSS syntax) and Compass. Please get set up with each one of those before attempting to use Susy. Sass and Compass both have their own setup instructions and tutorials that you can use.
There is also reference documentation in the works.
.two-columns { | |
overflow: hidden; | |
*zoom: 1; | |
position: relative; | |
} | |
.two-columns .column-one, .two-columns .column-two { | |
-moz-box-sizing: border-box; | |
-webkit-box-sizing: border-box; | |
-ms-box-sizing: border-box; |
Who is to blame?
Do you want to know who broke you tests?
http://whoistoblame.heroku.com/
Type your github name and project name and you will see who is to blame for broken test! (your project must use travis-ci for continuous integration)
For example: http://whoistoblame.heroku.com/?user=travis-ci&project=travis-ci