| # Copyright 2018 Google LLC | |
| # | |
| # Licensed under the Apache License, Version 2.0 (the "License"); | |
| # you may not use this file except in compliance with the License. | |
| # You may obtain a copy of the License at | |
| # | |
| # https://www.apache.org/licenses/LICENSE-2.0 | |
| # | |
| # Unless required by applicable law or agreed to in writing, software | |
| # distributed under the License is distributed on an "AS IS" BASIS, |
Here, there are some configs to use Elasticsearch as a Docker container and Logstash + Kibana as well.
You will see that Elasticsearch config is separated from Logstash and Kibana because I'm assuming that you want to use the ES container to other things rather than only log analyses.
Go to https://docs.docker.com/install/ and open the "Docker CE" menu, choose you OS and follow their instructions.
After install, open your terminal and type:
Slides : https://speakerdeck.com/derekprior/in-relentless-pursuit-of-rest Talk : https://www.youtube.com/watch?v=HctYHe-YjnE
REST help rails growing
More small things (small models, controllers, services, views...)
[Anti-pattern] Custom actions
noun#verb_noun (users#edit_password, users#update_password) = Missing resource| { | |
| "registry": "https://registry.bower.io" | |
| } |
So far in this book we've talked about how to sell products once. A customer selects a product, puts their information in, and hits the "buy now" button, and that's end of our interaction with them.
I screwed up using git ("git checkout --" on the wrong file) and managed to delete the code I had just written... but it was still running in a process in a docker container. Here's how I got it back, using https://pypi.python.org/pypi/pyrasite/ and https://pypi.python.org/pypi/uncompyle6
apt-get update && apt-get install gdb
| $ rails c | |
| Running via Spring preloader in process 7916 | |
| /Users/edmac/.rvm/gems/ruby-2.3.1/gems/activesupport-5.0.0.1/lib/active_support/dependencies.rb:293:in `require': dlopen(/Users/edmac/.rvm/rubies/ruby-2.3.1/lib/ruby/2.3.0/x86_64-darwin14/readline.bundle, 9): Library not loaded: /usr/local/opt/readline/lib/libreadline.6.dylib (LoadError) | |
| Referenced from: /Users/edmac/.rvm/rubies/ruby-2.3.1/lib/ruby/2.3.0/x86_64-darwin14/readline.bundle | |
| Reason: image not found - /Users/edmac/.rvm/rubies/ruby-2.3.1/lib/ruby/2.3.0/x86_64-darwin14/readline.bundle | |
| Fixed with: | |
| ln -s /usr/local/opt/readline/lib/libreadline.7.0.dylib /usr/local/opt/readline/lib/libreadline.6.dylib |
Used properly, the waiting strategy that certain Capybara matchers employ can solve most of those pesky intermittently failing full-stack/browser tests. Pretty much all of them† are due to race conditions between the processes running your tests, the app you're testing, and the browser (which includes both the rendering of the dom, your javascript running there, and if you're calling outside services, The Internet.) The race condition may resolve with 100% consistency on your local dev machine, but when your CI server runs the code, sometimes one process wins, sometimes another. The result is an intermittently failing test that you can only repro on a remote CI machine.
If your developent environment is significantly different than the CI environment, the barriers to effectively troubleshooting the problem may be too high. What I've seen a lot of developers do is just "punt" and insert a sleep(2) in their tests to increase the probabilty that the other processes finish first. And then write the test assumi
It's now here, in The Programmer's Compendium. The content is the same as before, but being part of the compendium means that it's actively maintained.
An experimental change for fast Clojure REPL startup:
java -jar clojure-1.8.0-fast.jarThe code used to create this JAR is on GitHub.
What's it doing?
It is: