type below:
brew update
brew install redis
To have launchd start redis now and restart at login:
brew services start redis
{ | |
"extends": ["react-app", "plugin:prettier/recommended"] | |
} | |
// UPDATE: In 2023, you should probably stop using this! The narrow version of Safari that | |
// does not support `nomodule` is probably not being used anywhere. The code below is left | |
// for posterity. | |
/** | |
* Safari 10.1 supports modules, but does not support the `nomodule` attribute - it will | |
* load <script nomodule> anyway. This snippet solve this problem, but only for script | |
* tags that load external code, e.g.: <script nomodule src="nomodule.js"></script> | |
* | |
* Again: this will **not** prevent inline script, e.g.: |
type below:
brew update
brew install redis
To have launchd start redis now and restart at login:
brew services start redis
Picking the right architecture = Picking the right battles + Managing trade-offs
Use a git hook to match a Jira issue ID from the current branch, and prepend it to every commit message
Assuming the current branch contains a Jira issue ID, you can use a git hook script to prepend it to every commit message.
Create an empty commit-msg git hook file, and make it executable. From your project's root directory:
install -b -m 755 /dev/null .git/hooks/commit-msg
Save the following script to the newly-created .git/hooks/commit-msg file:
This is the follow up to a post I wrote recently called From Require.js to Webpack - Party 1 (the why) which was published in my personal blog.
In that post I talked about 3 main reasons for moving from require.js to webpack:
Here I'll instead talk about some of the technical challenges that we faced during the migration. Despite the clear benefits in developer experience (DX) the setup was fairly difficult and I'd like to cover some of the challanges we faced to make the transition a bit easier.
Hi Nicholas,
I saw you tweet about JSX yesterday. It seemed like the discussion devolved pretty quickly but I wanted to share our experience over the last year. I understand your concerns. I've made similar remarks about JSX. When we started using it Planning Center, I led the charge to write React without it. I don't imagine I'd have much to say that you haven't considered but, if it's helpful, here's a pattern that changed my opinion:
The idea that "React is the V in MVC" is disingenuous. It's a good pitch but, for many of us, it feels like in invitation to repeat our history of coupled views. In practice, React is the V and the C. Dan Abramov describes the division as Smart and Dumb Components. At our office, we call them stateless and container components (view-controllers if we're Flux). The idea is pretty simple: components can't
var AWS = require('aws-sdk'), | |
fs = require('fs'); | |
// http://docs.aws.amazon.com/AWSJavaScriptSDK/guide/node-configuring.html#Credentials_from_Disk | |
AWS.config.loadFromPath('./aws-config.json'); | |
// assume you already have the S3 Bucket created, and it is called ierg4210-shopxx-photos | |
var photoBucket = new AWS.S3({params: {Bucket: 'ierg4210-shopxx-photos'}}); | |
function uploadToS3(file, destFileName, callback) { |
<?php | |
// include required files form Facebook SDK | |
require_once( 'Facebook/HttpClients/FacebookHttpable.php' ); | |
require_once( 'Facebook/HttpClients/FacebookCurl.php' ); | |
require_once( 'Facebook/HttpClients/FacebookCurlHttpClient.php' ); | |
require_once( 'Facebook/Entities/AccessToken.php' ); | |
require_once( 'Facebook/Entities/SignedRequest.php' ); |