Ctrl - Shift - E- Split verticallyCtrl - Shift - O- Split horizontallyCtrl - Shift - P- Focus next viewCtrl - Shift - N- Focus previous viewCtrl - Shift - W- Close focused viewCtrl - Shift - Q- Exit terminatorCtrl - Shift - X- Enlarge active view
| <!doctype html> | |
| <html ng-app="ctz"> | |
| <head> | |
| <title>CategoryTree</title> | |
| <script src="https://ajax.googleapis.com/ajax/libs/angularjs/1.3.14/angular.min.js"></script> | |
| <script> | |
| angular.module('treeApp', []); | |
| angular.module('treeApp').controller('treeCtrl', treeCtrl); | |
| treeCtrl.$inject = ['$scope', '$http']; |
| array_diff = lambda y,x: [i for i in y if i not in x] |
| server { | |
| index index.html index.htm index.php; | |
| set $basepath "/var/www"; | |
| set $domain $host; | |
| if ($domain ~ "^(.[^.]*)\.dev$") { | |
| set $domain $1; | |
| set $rootpath "${domain}"; | |
| set $servername "${domain}.dev"; | |
| } |
| #Newbie programmer | |
| def factorial(x): | |
| if x == 0: | |
| return 1 | |
| else: | |
| return x * factorial(x - 1) | |
| print factorial(6) | |
| #First year programmer, studied Pascal |
| <?php | |
| class FileUpload | |
| { | |
| private $from; | |
| private $destination; | |
| public function __construct($file, $id, $destination = '/tmp', $validExtensions = array()) | |
| { | |
| if (!is_array($file) || empty($file['tmp_name']) || !$file['tmp_name']) { |
using mocha/chai/sinon for node.js unit-tests? check out my utility: mocha-stirrer to easily reuse test components and mock require dependencies
| for (var i = 0; i < 1024 * 1024; i++) { | |
| process.nextTick(function () { Math.sqrt(i) } ) | |
| } |
When the directory structure of your Node.js application (not library!) has some depth, you end up with a lot of annoying relative paths in your require calls like:
var Article = require('../../../models/article');Those suck for maintenance and they're ugly.
Did you ever happen to disagree with a colleague on the single responsibility principle and its application? Let's try to understand why that could be the case.
I once worked with a colleague, whom we shall call Stan, who had a very different understanding of the single responsibility principle than I had. During code reviews, his feedback would often be that my classes "tried to do too much" and broke the single responsibility principle. My feedback to his patches was often the opposite, that his classed did too little and lacked cohesion.
How can we explain this disagreement? Let's assume that we both know the SRP and try to apply it at the best of our abilities: I can only see two alternatives.
The first possibility is that the classes are actually the wrong size. People are wrong all the time: maybe I was wrong and he was right or vice versa. While this sometimes happens, I would expect any reasonably competent developer who is aware of the SRP to onl