Seems to me there are two varieties of procedural parameters out there: "leases" and "consequences".
{ | |
"binary_file_patterns": | |
[ | |
"*.jpg", | |
"*.jpeg", | |
"*.png", | |
"*.gif", | |
"*.ttf", | |
"*.tga", | |
"*.dds", |
So I really don't like most new things. The only reason I even got involved with Node.js early on was because of its sweeping promise: "One language, spoken by developers across the world." By consolidating parallel efforts, it would accelerate the pace of innovation, and quickly lead to more transformative and disruptive developer tools. It would create tremendous value for software businesses by unlocking efficiencies in the hiring and implementation process. And best of all everyone would waste less time on boring stuff.
Still, there was a problem. While it's true most developers have touched some JavaScript callbacks up there in browserland, in the bowels of the application server, there tends to be a lot more asynchronous things going on. And that causes all sorts of issues. All those callbacks also make for a way steeper
// - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - | |
// UPDATE: | |
// | |
// If you're using a Sails app, and you need to do this on the backend, then instead of the code below, | |
// consider just using `sails.helpers.flow.pause()` from sails-hook-organics. | |
// (Now available by default in the "Web App" template.) | |
// | |
// | |
// - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - |
#!/bin/bash | |
# smry | |
# | |
# Copyright Nov 4, 2017, Mike McNeil | |
# MIT License | |
# | |
# Adapted from https://gist.github.com/lmj0011/1a8dd1e376234ac7bf0fba2748ecdd0f | |
# and https://gist.github.com/mzabriskie/6631607#gistcomment-1738920 | |
# which was originally adapted from https://gist.github.com/mzabriskie/6631607 |
If you have a question, need commercial support from the engineers who build Sails, or you just want to talk Sails/Node.js with other folks in the community, click here.
To report a bug, click here.
For future reference: When attempting to set up cloudflare and heroku properly, here's how you do it: | |
1. Just buy the dingdang SSL cert through Cloudflare. | |
2. Enable Cloudflare's built-in https:// redirect functionality. | |
3. Use the "Full" SSL setting in Cloudflare | |
4. In Cloudflare, have your DNS set up to point at the normal/default DNS setting (not the special SSL one!) | |
5. Don't do anything related to SSL in heroku (or in your app logic) | |
> If you choose "Partial" SSL in Cloudflare or start monkeying around with SSL in Heroku, things get kind of weird. |
echoSinceTagInfo() | |
{ | |
if git describe --abbrev=0 --tags 1>/dev/null 2>/dev/null; | |
then | |
local LAST_TAG=`git describe --abbrev=0 --tags`; | |
local CHANGED_SINCE_LAST_TAG=`git diff ${LAST_TAG} --shortstat`; | |
if [ -z "${CHANGED_SINCE_LAST_TAG}" ] | |
then |
// This gist is just to keep track of this somewhere for posterity. | |
// In the future, we might look into adding support for something like the following... | |
// –– | |
// Parse and validate the provided data to ensure it's valid for this | |
// cloud action. (This also provides a basic level of client-side validation.) | |
argins = Cloud.login.parse(argins) | |
.tolerate('E_INVALID_ARGINS', (err)=>{ | |
// Upon noticing any validation error, set error states in the form | |
// accordingly and send back argins as `undefined`. |
await User.create({ | |
emailAddress: 'asdf@asdf.com' | |
}) | |
.unless('E_UNIQUE', ()=>{ | |
return exits.conflict() | |
}); | |
return exits.success(); | |