| Please read original blog post for reference: | |
| http://blog.process-one.net/embedding-ejabberd-into-an-elixir-phoenix-web-application/ |
From Out of the Tar Pit:
The key problem with testing is that a test (of any kind) that uses one particular set of inputs tells you nothing at all about the behaviour of the system or component when it is given a different set of inputs. The huge number of different possible inputs usually rules out the possibility of testing them all, hence the unavoidable concern with testing will always be — have you performed the right tests?. The only certain answer you will ever get to this question is an answer in the negative — when the system breaks.
This is a strong argument for some form of generative, simulation, or property-based testing.
| { | |
| "\UF729" = moveToBeginningOfParagraph:; // home | |
| "\UF72B" = moveToEndOfParagraph:; // end | |
| "$\UF729" = moveToBeginningOfParagraphAndModifySelection:; // shift-home | |
| "$\UF72B" = moveToEndOfParagraphAndModifySelection:; // shift-end | |
| // Emacs keybindings | |
| "^ " = "setMark:"; | |
| "~d" = "deleteWordForward:"; | |
| "~w" = "copy:"; /* M-w */ | |
| "^w" = "deleteWordBackward:"; |
| // Use Gists to store code you would like to remember later on | |
| console.log(window); // log the "window" object to the console |
Inspired by Trulia Trends - but with code and using SVG.
Example data shows concurrent user sessions over time, taken from a development environment.
(by @andrestaltz)
So you're curious in learning this new thing called (Functional) Reactive Programming (FRP).
Learning it is hard, even harder by the lack of good material. When I started, I tried looking for tutorials. I found only a handful of practical guides, but they just scratched the surface and never tackled the challenge of building the whole architecture around it. Library documentations often don't help when you're trying to understand some function. I mean, honestly, look at this:
Rx.Observable.prototype.flatMapLatest(selector, [thisArg])
Projects each element of an observable sequence into a new sequence of observable sequences by incorporating the element's index and then transforms an observable sequence of observable sequences into an observable sequence producing values only from the most recent observable sequence.
@tenderlove asked "Is it good to teach RSpec (vs t/u) to people who are totally new to Ruby?" I have experience suggesting that it is a good thing; after a short back and forth, it seemed useful to write it up in detail.
This goes back several years, to when I was the primary Ruby/Rails trainer for Relevance from 2006-2009. I'm guessing that worked out to probably 6-8 classes a year during those years. Since then, RSpec has changed a fair amount (with the addition of expect) and test/unit has changed radically (it has an entirely new implementation, minitest, that avoids some of the inconsistencies that made test/unit a bit confusing during the time I'm writing about here).
I started out as an RSpec skeptic. I've never been afraid of what a lot of people denigrate as "magic" in Ruby libraries … to me, if you take the trouble to understand it, that stuff's just pr
| echo 'export PATH=$HOME/local/bin:$PATH' >> ~/.bashrc | |
| . ~/.bashrc | |
| mkdir ~/local | |
| mkdir ~/node-latest-install | |
| cd ~/node-latest-install | |
| curl http://nodejs.org/dist/node-latest.tar.gz | tar xz --strip-components=1 | |
| ./configure --prefix=~/local | |
| make install # ok, fine, this step probably takes more than 30 seconds... | |
| curl https://npmjs.org/install.sh | sh |
