What is the difference between forEach
and map
in JS?
forEach:
const arr = [1, 2, 3];
const eachExample = () => arr.forEach(e => e);
This gist outlines the change in the depth and breadth of the tasks and responsibilities of a software engineer as she continuously improves herself.
I created this to supplement a discussion in an internal slack group; then I though the rest of the world might benefit from this too.
Contributions are always welcome.
I recently had several days of extremely frustrating experiences with service workers. Here are a few things I've since learned which would have made my life much easier but which isn't particularly obvious from most of the blog posts and videos I've seen.
I'll add to this list over time – suggested additions welcome in the comments or via twitter.com/rich_harris.
Chrome 51 has some pretty wild behaviour related to console.log
in service workers. Canary doesn't, and it has a load of really good service worker related stuff in devtools.
var fs = require('fs'), | |
os = require('os'), | |
lineReader = require('line-reader'); | |
function help(){ | |
console.log('Usage: node coffee-asset-pipeline-comments.js file1.coffee'); | |
} | |
function compilefile(pathname, outdir){ | |
var src = ''; |
{ | |
"close_windows_when_empty": false, | |
"color_scheme": "Packages/One Dark Color Scheme/One Dark.tmTheme", | |
"detect_indentation": false, | |
"enable_tab_scrolling": false, | |
"ensure_newline_at_eof_on_save": true, | |
"env": | |
{ | |
"PATH": "/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/X11/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/X11/bin:/usr/local/share/npm/bin/" | |
}, |
//import the selenium web driver | |
var webdriver = require('selenium-webdriver'); | |
var chromeCapabilities = webdriver.Capabilities.chrome(); | |
//setting chrome options to start the browser fully maximized | |
var chromeOptions = { | |
'args': ['--test-type', '--start-maximized'] | |
}; | |
chromeCapabilities.set('chromeOptions', chromeOptions); | |
var driver = new webdriver.Builder().withCapabilities(chromeCapabilities).build(); |
This document is a collection of concepts and strategies to make large Elm projects modular and extensible.
We will start by thinking about the structure of signals in our program. Broadly speaking, your application state should live in one big foldp
. You will probably merge
a bunch of input signals into a single stream of updates. This sounds a bit crazy at first, but it is in the same ballpark as Om or Facebook's Flux. There are a couple major benefits to having a centralized home for your application state: