Please create an Issue in the transport-apis
repo instead. 🙏
#!/usr/bin/env ruby | |
# | |
# Mac fix 1 - Install the Nokogiri gem on Mac OS 10.9 Mavericks | |
# | |
# Usage: to configure and install using Bundler, pass in 'bundle' as an argument to the script. | |
# | |
# Nokogiri works at a very low level, so it has many issues on various platforms. | |
# As a result, the command `install gem nokogiri` often will fail. This fix is for | |
# errors involving 'libiconv', such as the following one I encountered: | |
# |
#!/usr/bin/bash | |
# You might want to note your old MAC address here. Use this to get it: | |
# ifconfig en0 | grep ether | |
MAC_ADDRESS=`openssl rand -hex 6 | sed 's/\(..\)/\1:/g; s/.$//'` | |
echo "Setting MAC address..." | |
sudo ifconfig en0 ether $MAC_ADDRESS | |
ifconfig en0 | grep ether |
gifify() { | |
if [[ -n "$1" ]]; then | |
if [[ $2 == '--good' ]]; then | |
ffmpeg -i $1 -r 10 -vcodec png out-static-%05d.png | |
time convert -verbose +dither -layers Optimize -resize 600x600\> out-static*.png GIF:- | gifsicle --colors 128 --delay=5 --loop --optimize=3 --multifile - > $1.gif | |
rm out-static*.png | |
else | |
ffmpeg -i $1 -s 600x400 -pix_fmt rgb24 -r 10 -f gif - | gifsicle --optimize=3 --delay=3 > $1.gif | |
fi | |
else |
Locate the section for your github remote in the .git/config
file. It looks like this:
[remote "origin"]
fetch = +refs/heads/*:refs/remotes/origin/*
url = git@github.com:joyent/node.git
Now add the line fetch = +refs/pull/*/head:refs/remotes/origin/pr/*
to this section. Obviously, change the github url to match your project's URL. It ends up looking like this:
/ A simplistic way of loading and rendering HAML partials (header.haml, footer.haml, nav.haml... you name it) without Rails | |
/ Useful when using tools like LiveReload http://livereload.com/ | |
/ but don't want to configure a web server just to use PHP include/require constructs (discussion http://help.livereload.com/discussions/questions/22-haml-partials) | |
/ It could be improved/simplified using a helper http://stackoverflow.com/questions/5436769/partial-haml-templating-in-ruby-without-rails/5436973#5436973 | |
/ Check out the Jade version https://gist.github.com/2593727 | |
%html | |
%body | |
%header | |
= Haml::Engine.new(File.read('/path/to/your/partial.haml')).render |
class ActionDispatch::Routing::Mapper | |
def draw(routes_name) | |
instance_eval(File.read(Rails.root.join("config/routes", "#{@scope[:shallow_prefix]}", "#{routes_name}.rb"))) | |
end | |
end | |
BCX::Application.routes.draw do | |
draw :projects # => config/routes/projects.rb | |
namespace :admin do |
class ActionDispatch::Routing::Mapper | |
def draw(routes_name) | |
instance_eval(File.read(Rails.root.join("config/routes/#{routes_name}.rb"))) | |
end | |
end | |
BCX::Application.routes.draw do | |
draw :api | |
draw :account | |
draw :session |
Performance is often ignored in Rails development until it becomes a problem. If ignored too long, though, it can get very tricky to improve. It's valuable to regularly audit performance and look for hotspots or design choices that are slowing things down.
Inspecting the log will help identify the source of several performance issues the application may have.
The Rails application log outputs the time spent processing each request. It breakdowns the time spent at the database level as well processing the view code. In development mode, the logs are displayed on STDOUT where the server is being run. In a production setting the logs will be in log/production.log
within the application's root directory.
# WAIT! Do consider that `wait` may not be needed. This article describes | |
# that reasoning. Please read it and make informed decisions. | |
# https://www.varvet.com/blog/why-wait_until-was-removed-from-capybara/ | |
# Have you ever had to sleep() in Capybara-WebKit to wait for AJAX and/or CSS animations? | |
describe 'Modal' do | |
should 'display login errors' do | |
visit root_path |