spec
|--- apis #do not put into controllers folder.
|--- your_api_test_spec.rb
|--- controllers
|--- models
|--- factories
|--- views
# This is a skeleton for testing models including examples of validations, callbacks, | |
# scopes, instance & class methods, associations, and more. | |
# Pick and choose what you want, as all models don't NEED to be tested at this depth. | |
# | |
# I'm always eager to hear new tips & suggestions as I'm still new to testing, | |
# so if you have any, please share! | |
# | |
# This skeleton also assumes you're using the following gems: | |
# | |
# rspec-rails: https://github.com/rspec/rspec-rails |
Reposted from Qiita
For almost a year now, I've been using this "flux" architecture to organize my React applications and to work on other people's projects, and its popularity has grown quite a lot, to the point where it shows up on job listings for React and a lot of people get confused about what it is.
There are a billion explainations on the internet, so I'll skip explaining the parts. Instead, let's cut to the chase -- the main parts I hate about flux are the Dispatcher and the Store's own updating mechanism.
If you use a setup similar to the examples in facebook/flux, and you use flux.Dispatcher, you probably have this kind of flow:
Vue.js is an amazing framework, which can be as powerful as Angular or React, the two big heavy hitters in the world of front-end frameworks.
However, most of Vue's ease-of-use is due to the use of Observables - a pattern that triggers re-renders and other function calls with the reassignment of a variable.
function av-exec | |
aws-vault exec $argv[1] -- $argv[2..-1] | |
end | |
function av-shell | |
av-exec $argv[1] fish | |
end | |
alias kexec-dev="kubectl-exec firma-dev" | |
alias kexec-stage="kubectl-exec firma-stage" |