⌘T | go to file |
⌘⌃P | go to project |
⌘R | go to methods |
⌃G | go to line |
⌘KB | toggle side bar |
⌘⇧P | command prompt |
</php | |
/** | |
* Facebook Page Feed Parser | |
* | |
* @using cURL | |
*/ | |
function fb_parse_feed( $page_id, $no = 5 ) { | |
// URL to the Facebook page's RSS feed. |
https://github.com/rspec/rspec | |
http://www.codeschool.com/courses/testing-with-rspec | |
http://en.wikipedia.org/wiki/RSpec | |
http://rspec.info/ | |
https://relishapp.com/rspec/rspec-core/docs | |
http://betterspecs.org/ |
These are all the JSConf 2014 slides, codes, and notes I was able to cull together from twitter. Thanks to the speakers who posted them and thanks to @chantastic for posting his wonderful notes.
(by @andrestaltz)
If you prefer to watch video tutorials with live-coding, then check out this series I recorded with the same contents as in this article: Egghead.io - Introduction to Reactive Programming.
It took me a long time to warm up to pull requests. My early experiences with code review were all a tremendous waste of time: they were a bottleneck to getting things done, a forum for people to conduct their ongoing feuds or both. After years of being staunchly against pull requests, I've come around on them in the last year at Terrible Labs.
Start with cthe big picture and get more detailed from there.
My pull request should be trying to accomplish only one thing and that should be explained in enough detail in the commit message for you to understand, did I succeed? If something is confusing: you're not sure how this system works, or how this new piece of code fits in with other parts of the system, let me know and we can clarify it together.
// Promise.all is good for executing many promises at once | |
Promise.all([ | |
promise1, | |
promise2 | |
]); | |
// Promise.resolve is good for wrapping synchronous code | |
Promise.resolve().then(function () { | |
if (somethingIsNotRight()) { | |
throw new Error("I will be rejected asynchronously!"); |