In order to reduce the frustration that I’ve encountered while installing oh-my-zsh on my new MacBook, I decided to write down this post to remind me of some steps that I need to beware.
Install ZSH from Homebrew
1
$ brew install zsh
Make sure the ZSH is running the Homebrew version, not the built-in one
1
$ which zsh
Should return the path /usr/local/bin/zsh not /bin/zsh
$ curl -L https://raw.github.com/robbyrussell/oh-my-zsh/master/tools/install.sh | sh
Under /.zshrc file, we should add few more lines that include the following
.zshrc
1 2
[[ -s "$HOME/.profile" ]] && source"$HOME/.profile"# Load the default .profile export PATH="/usr/local/bin:$PATH"# Load the Homebrew version of commands
Run brew doctor if encounter any further problems, it will tell us what to do.
When deploying on Amazon EC2, we have to be careful about the instances we choose. RailsCasts has provided a screencast on how to deploy Rails application on EC2, but the default values are quite a mess.
First of all, default Instance is m1.medium for VM Image type, which is not free, so we have to set the YAML file to t1.micro according to Amazon Free Tier description.
1 2
image_type:t1.micro image_id:'ami-5e215b0c'
Besides, newly created account has only 5 limited Security Groups for us to set up, so we have to make sure the Rubber does not generate more than that number.
1
auto_security_groups:false
Somehow the multiple intances have trouble connecting to each other, we might want to config the pg_hba.conf file to allow IP connection.
1 2
host all all 172.XX.XX.XX/24 trust host all all 172.XX.XX.XX/24 trust
Playing around with this, knowing without the line cards.to_enum, I could actually input a new item in the array with ease, but sometimes we don’t want that. Therefore, given the enumerator like to_enum will allow for iterations through the array without absorbing changes.
Sometimes I get a little confused about the difference between accessing an instance attribute via self.attribute and by @attribute, so one day I look up the stackoverflow to clear up my thoughts. The answers below are some good tips on the subject based on the site.
Here’s What the Best Answer Would Suggest
self.attribute calls the method attribute. self.attribute = value calls the method attribute= with the argument value. @attribute and @attribute = value get/set the value of the instance variable @attribute.
So basically they’re two entirely different things.
However if you call attr_accessor :attribute it defines the method attribute to return @attribute and the method attribute=(value) to set @attribute = value. So in that case, there is no difference.
The Comment is also Helpful
Note that it is generally recommended to use self. (unless you’re writing the getter/setter method) even if you currently have attr_accessor. This protects you from additional refactor work and bugs if you later change the accessor method(s) to do more than just get/set the instance variable. (Or if someone else patches or subclasses your work.)
Sometimes it’s really neat to customize or fork some Gems from GitHub, and this is how I install my modified version of a Gem locally and install it at will.
If anyone wants to set up a few testing sites on only one IP server, we could modify the Nginx config file to open different port for servers deployment.
server { listen 180; server_name localhost; root /home/ruling/orbit_1/public; # <--- be sure to point to 'public'! passenger_enabled on; rails_env production;
server { listen 280; server_name localhost; root /home/ruling/orbit_2/public; # <--- be sure to point to 'public'! passenger_enabled on; rails_env production;