Attention: the list was moved to
https://github.com/dypsilon/frontend-dev-bookmarks
This page is not maintained anymore, please update your bookmarks.
var monkeyPatches = { | |
'_livedata_data': 'DATA', | |
'_livedata_error': 'ERROR', | |
'_livedata_nosub': 'NOSUB', | |
'_livedata_connected': 'CONNECTED', | |
'_livedata_result': 'RESULT', | |
}; | |
_.each(_.keys(monkeyPatches),function(funcName){ | |
var modifiedFunctionName = funcName+'_original'; | |
var extension = {}; |
Attention: the list was moved to
https://github.com/dypsilon/frontend-dev-bookmarks
This page is not maintained anymore, please update your bookmarks.
require "active_record" | |
namespace :db do | |
db_config = YAML::load(File.open('config/database.yml')) | |
db_config_admin = db_config.merge({'database' => 'postgres', 'schema_search_path' => 'public'}) | |
desc "Create the database" | |
task :create do | |
ActiveRecord::Base.establish_connection(db_config_admin) |
When hosting our web applications, we often have one public IP
address (i.e., an IP address visible to the outside world)
using which we want to host multiple web apps. For example, one
may wants to host three different web apps respectively for
example1.com
, example2.com
, and example1.com/images
on
the same machine using a single IP address.
How can we do that? Well, the good news is Internet browsers
# Hello, and welcome to makefile basics. | |
# | |
# You will learn why `make` is so great, and why, despite its "weird" syntax, | |
# it is actually a highly expressive, efficient, and powerful way to build | |
# programs. | |
# | |
# Once you're done here, go to | |
# http://www.gnu.org/software/make/manual/make.html | |
# to learn SOOOO much more. |
While this gist has been shared and followed for years, I regret not giving more background. It was originally a gist for the engineering org I was in, not a "general suggestion" for any React app.
Typically I avoid folders altogether. Heck, I even avoid new files. If I can build an app with one 2000 line file I will. New files and folders are a pain.
I've written this code to test what happens once a Stripe card token has been passed through to the server. This code does not do any browser testing (because JS-friendly headless testing is painful at best, and impossible if you want VCR in the mix). VCR is being used here to capture interactions with a test Stripe account, to ensure the tests are fast on future runs. That said, it's structured so that nothing is expected to be present in the Stripe account. If you delete all the stored VCR cassettes, the specs will safely re-record them.
Instead of using VCR.use_cassette
directly, instead you use stripe_cassette
in your specs, passing in the current spec example object. This will automatically generate a cassette name based on the spec's file name and the example's description (limitations of this are noted in the code comments). Within the cassette's recording block, Stripe data is cleared out before yielding back to the spec, with a context object. The context object provides access to helper methods