Our applications have grown organically and our current collection of actions, reducers and selectors are due for an upgrade. This document is an attempt to outline an better way to organize our redux code.
The biggest changes here are the introduction of "modules" and redux-sagas.
| " when triggering this command, vim will grab your path and line location and pass it along | |
| map <Leader>el :call RemoteSendCommand(TestLineCommand(expand("%:p"), line(".")))<CR> | |
| " because I'm mostly writing Elixir and making heavy use of the REPL while writing my tests, | |
| " I made a specific command to user with Mix, the Elixir task utility | |
| " But I'm sure you could get this to work with vim-test or something like that | |
| function! TestLineCommand(path, line_number) | |
| let cmd = join(["mix test --only", " line:", a:line_number, " ", a:path], "") | |
| return cmd | |
| endfunction |
| require "net/http" | |
| def start_server | |
| # Remove the X to enable the parameters for tuning. | |
| # These are the default values as of Ruby 2.2.0. | |
| @child = spawn(<<-EOC.split.join(" ")) | |
| XRUBY_GC_HEAP_FREE_SLOTS=4096 | |
| XRUBY_GC_HEAP_INIT_SLOTS=10000 | |
| XRUBY_GC_HEAP_GROWTH_FACTOR=1.8 | |
| XRUBY_GC_HEAP_GROWTH_MAX_SLOTS=0 |
Important: At the time of writing (2019-11-11) Immutable.js is effectively abandonware, so I can no longer recommend anyone to follow the advice given here. I'll leave the article here for posterity, since it's still getting some traffic.
Functional programming principles and with it immutable data are changing the way we write frontend applications. If the recent de-facto frontend stack of React and Redux feels like it goes perfectly together with immutable data, that's because it's specifically designed for that.
There's several interesting implementations of immutable data for JavaScript, but here I'll be focusing on Facebook's own Immutable.js, and specifically on one of i
| // # Mocha Guide to Testing | |
| // Objective is to explain describe(), it(), and before()/etc hooks | |
| // 1. `describe()` is merely for grouping, which you can nest as deep | |
| // 2. `it()` is a test case | |
| // 3. `before()`, `beforeEach()`, `after()`, `afterEach()` are hooks to run | |
| // before/after first/each it() or describe(). | |
| // | |
| // Which means, `before()` is run before first it()/describe() |
This document details some tips and tricks for creating redux containers. Specifically, this document is looking at the mapDispatchToProps argument of the connect function from [react-redux][react-redux]. There are many ways to write the same thing in redux. This gist covers the various forms that mapDispatchToProps can take.
| # To Setup: | |
| # 1) Save the .git-completion.bash file found here: | |
| # https://github.com/git/git/blob/master/contrib/completion/git-completion.bash | |
| # 2) Add the following lines to your .bash_profile, be sure to reload (for example: source ~/.bash_profile) for the changes to take effect: | |
| # Git branch bash completion | |
| if [ -f ~/.git-completion.bash ]; then | |
| . ~/.git-completion.bash | |
| # Add git completion to aliases |
This was useful for me when we created a new branch for a new major release, but were still working on our current version as well. I cloned our repo again and kept the new project on our new branch, but also wanted to get my stashes there.
git stash show -p > patch
You'll have to specify your stash and name your file whatevery you want. Do this for as all your stashes, and you'll have patch files in your pwd.