Sean Michael seansean11
| /*! | |
| * gulp | |
| * $ npm install gulp-ruby-sass gulp-autoprefixer gulp-cssnano gulp-jshint gulp-concat gulp-uglify gulp-imagemin gulp-notify gulp-rename gulp-livereload gulp-cache del --save-dev | |
| */ | |
| // Load plugins | |
| var gulp = require('gulp'), | |
| sass = require('gulp-ruby-sass'), | |
| autoprefixer = require('gulp-autoprefixer'), | |
| cssnano = require('gulp-cssnano'), |
| " copy all this into a vim buffer, save it, then... | |
| " source the file by typing :so % | |
| " Now the vim buffer acts like a specialized application for mastering vim | |
| " There are two queues, Study and Known. Depending how confident you feel | |
| " about the item you are currently learning, you can move it down several | |
| " positions, all the way to the end of the Study queue, or to the Known | |
| " queue. | |
| " type ,, (that's comma comma) |
When you use $resource within a service, you don't need to impose mocking $httpBackend on your controller. If you want tests for the $resource, those should be in the unit tests for the service.
The controller should only test things directly under its control, which means testing the service directly.
The examples below show how to mock a $resource service factory, in the simplest way I could come up with.
TODO:
- These are real-world examples and it might be helpfule to visitors if I removed all the extra junk that isn't directly related to testing $resource.
- Should this be updated to be a better example of utilizing promises?
https://github.com/djvirgen/virgen-acl Simple and elegant, create your own checks. No middleware?
https://github.com/OptimalBits/node_acl Use as middleware, create your own roles and access. Great choice.
https://github.com/tschaub/authorized Similar to connect roles... but a bit more robust? you can create roles and action, and associate many roles with that action
- Avoid too many reflows (the browser to recalculate everything)
- Use advanced CSS3 for graphic card rendering
- Precalculate sizes and positions
The reflow appens as many times as there are frames per seconds. It recalculate all positions that change in order to diplay them. Basically, when you scroll you execute a function where you move things between two reflows. But there are functions that triggers reflows such as jQuery offset, scroll... So there are two things to take care about when you dynamically change objects in javascript to avoid too many reflows:
| /* @author 14islands.com | |
| * SASS mixins for future proof resolution media query | |
| */ | |
| @mixin if-min-resolution($dppx) { | |
| @include if-resolution(min, $dppx) { | |
| @content; | |
| } | |
| } |
Despite being derived from classical MVC pattern JavaScript and the environment it runs in makes Javascript MVC implementation have its own twists. Lets see how typical web MVC functions and then dive into simple, concrete JavaScript MVC implementation.
Typical server-side MVC implementation has one MVC stack layered behind the singe point of entry. This single point of entry means that all HTTP requests, e.g. http://www.example.com or http://www.example.com/whichever-page/ etc., are routed, by a server configuration, through one point or, to be bold, one file, e.g. index.php.
At that point, there would be an implementation of Front Controller pattern which analyzes HTTP request (URI at first place) and based on it decides which class (Controller) and its method (Action) are to be invoked as a response to the request (method is name for function and member is name for a variable when part of the class/object).
| <?php | |
| /** | |
| * Add parent category class to post_class() function | |
| * | |
| * @link http://wordpress.stackexchange.com/q/23259#23260 | |
| */ | |
| function mamaduka_add_parent_category_class( $classes, $class, $post_id ) { | |
| foreach ( (array) get_the_category( $post_id ) as $cat ) { | |
| if ( ! empty( $cat->parent ) ) { | |
| $parent_cat = &get_category( $cat->parent ); |