| MongoDB upstart scripts for Ubuntu. | |
| Run following commands after installing upstart scripts: | |
| ln -s /lib/init/upstart-job /etc/init.d/mongoconf | |
| ln -s /lib/init/upstart-job /etc/init.d/mongodb | |
| ln -s /lib/init/upstart-job /etc/init.d/mongos | |
| To start services use: |
| master = true | |
| #vv = true | |
| port = 27017 | |
| bind_ip = 0.0.0.0 | |
| auth = false | |
| noauth = true | |
| jsonp = true | |
| rest = true | |
| fork = false | |
| #upgrade = true |
Leverages Angular UI Router instead of core ngRoute module. UI Router allows
us to organize our application interface into a state machine.
Unlike the $route service in the Angular ngRoute module, which is organized around URL routes, UI-Router
is organized around states, which may optionally have routes, as well as other behavior, attached.
LIFT* Organization principle:
| // this example shows how to write a helper to get something like bindToController | |
| // in angular 1.2.x | |
| // this example is incomplete and mostly meant to illustrate the technique | |
| angular.module('myModule', []).directive('myDir', function () { | |
| return bindToController({ | |
| scope: { | |
| foo: '=' | |
| }, | |
| controller: 'MyController', |
mathclub是最近做的一个个人项目，帮助考SAT的同学通过在线做题、回顾、问答提高成绩。用户功能有：计次/计时做题、成绩单、错题分布、错题回顾、提问、汇总以及注册登录。管理后台主要是题库管理、学员管理、成绩单管理、问题回复。怎么看都像学校里的课设，的确项目本身并不出奇，开发上选用的一些方案或许更有意思。
整个项目一个人从产品需求、原型设计、前后端开发到部署历时2周左右。可以从截图上感受一下：
技术选型上服务端是Node.js，应用框架选了老牌的Express（4.x变化挺大不少中间件都废了），数据服务用的是MongoLab（MongoDB的云服务平台），图片上传用的是又拍云，程序部署在Nodejitsu上。模板引擎没选主流的Jade或ejs，而是用Express React Views它实现了在服务端渲染React组件。前端框架是用React，这次有意想追求前后端全部组件化的组织。之前是用Webpack实现CommonJS模块打包，这次用Browserify配置更简单，它有丰富的transform很赞，其中的reactify转换React的JSX很完美。CSS用Sass＋autoprefixer让人省心。将这一切串起来的自动构建工具是Gulp。我其实崇尚用最精简的工具组合开发，上述组合在我看来比较精简了。（帖纸留念）
This should be one of the core features of Git, but for some reason it's impossible to figure out how to search for a string in your commit history and see the diffs that that string is in. Here's the best I've come up with:
To find which commits and which files a string was added or removed in:
git log -S'search string' --oneline --name-status
To see the diff of that
| %lex | |
| %{ | |
| var parser = yy.parser; | |
| %} | |
| %% | |
| \n return 'NEWLINE' | |
| \s+ /* skip whitespace */ |
⇐ back to the gist-blog at jrw.fi
First there was JSLint, and there was much rejoicing. The odd little language called JavaScript finally had some static code analysis tooling to go with its many quirks and surprising edge cases. But people gradually became annoyed with having to lint their code according to the rules dictated by Douglas Crockford, instead of their own.
So JSLint got forked into JSHint, and there was much rejoicing. You could set it up to only complain about the things you didn't want to allow in your project, and shut up about the rest. JSHint has been the de-facto standard JavaScript linter for a long while, and continues to do so. Yet there will always be things your linter could check for you, but doesn't: your team has agreed on some convention that makes sense for them, but JSHint doesn't have an option
| Reusing an AngularJS Directive core code. The idea is to: | |
| ** 1. conceal the actual directive behaviour in a separate JS "class", | |
| ** 2. store that in an Angular service, | |
| ** 3. inject that service into an Angular directive, | |
| ** 4. just have the directive factory function return the constructed instance of the "class". | |
| That is to separate the directive core code from the actual directive factory. | |
| Then one actually wants to inherit a directive core "class" from another. It's not really a matter of JS inheritance, but more on how to inject one into the other by means of Angular modules, without actually instantiating none of them until needed, |
