In a previous article, I talked about using subdomains in Rails 3. Since then, many people have elaborated on the topic. There's even been a great Railscast.
I've found Tim Pope's post particularly useful. Basically, he has set up a domain name that resolves to locahost/127.0.0.1. This save you from having to specify subdomains in you /etc/hosts file - which is a hassle!
I'd like to offer another alternative using Dnsmasq. With Dnsmasq, you can set up a simple DNS server locally, then you can use an apache virtual host to deal with wildcard domains.
First, install Dnsmasq - I'm using Ubuntu (sorry for those who aren't).
Now, edit the /etc/dnsmasq.conf file:
The listen-address basically defines what IP address Dnsmasq will listen on. In our case this is your local machine.
The address line specifies a lookup for the name blah.localhost. As you can see, this is mapped to your local machine also.
Believe it or not, that's pretty much it! And if you've tried to use Bind for a similar job, you'll be very happy right now.
One more thing though! You need to add 127.0.0.1 as DNS server in your network settings. If you're using linux, edit /etc/resolv.conf and add a new nameserver line to the top:
Finally, restart Dnsmasq:-
sudo /etc/init.d/dnsmasq restart
Now all you need to do is set up a virtual host:
Restart apache and you're done.
If you're using Rails, you won't need to set up a virtual host in Apache. Just start your server:
rails s
Then browse to the domain you set up, like so:
http://mysubdomain.blah.localhost:3000
Also, on a seperate note... You may notice internet pages are loading faster. This is because you now have a local DNS server cache. Therefore, resolving domains is a lot faster. You get this as a free side effect.
Sometimes it's useful to interact with your controllers via the console. This, as you may know, can be achieved with the app object. You can perform GET, POST, PUT and DELETE requests by doing the following:-
If you need to login to your Rails app first, you will need to send a post request to the controller that creates the user session. Most likely, the "sessions" controller - "create" action. First, you'll need to take a note of the fields that are used for the user name and password on the login form. In my case, this is username and password. Now you're ready to send your post request:
Notice, on the first line, that you need to disable forgery protection. I found that I couldn't log in unless I did this. Another thing that I needed to do, was deal with subdomains. For instance, the user (in my app) should only be allowed to log in when a subdomain is specified. You can do this by setting the "host", as seen on the second line on the code snippet above. If all goes well, you should get a 302 response and you can start interacting with the rest of your applications actions:-
Very handy indeed. Also, getting familiar with these commands is useful for when you're writing functional tests.
I was getting a ActionController::InvalidAuthenticityToken destroy error when using the Destroy method in my Rails 3 app. Turns out, when I was migrating to Rails 3, I forgot to include this in the html header:-
I couldn't find a solution anywhere, so hopefully this helps you out!
This one confused the hell out of me. Suddenly, my css styling of the fieldWithErrors div stopped working. Turns out this has been changed to field_with_errors. Check it out here.
The change seems to have taken place between beta 3 and beta 4.
Typing long-winded scripts into the irb prompt can be a pain in the ass! It's been annoying me for a while now, so I decided enough was enough.
I found a way to run a ruby script (the one which is currently open in vim) through irb, then leave you at a irb prompt to execute further commands.
Say you're editing a ruby script in vim...
In vim you can run external commands by using ":!". Also you can use "%" to specify the current file. So with this in mind you can run the above script through irb and use the -r argument to leave you at the irb prompt. Here is what you need to type in vim:
This will leave you at an irb prompt where you can perform actions on "Book"...
Then when you're finished, exiting the irb prompt will bring you back to the file you were editing :)
Also, to make your life even easier, you can use a short-hand vim command to execute the last command. This saves you from typing ":! irb -r %" everytime...
This has made my life so much easier when testing a piece of code in isolation.
UPDATE: A few people have pointed out the interactive_editor gem. Both methods work, choose whichever suits you best.