Why don't my views update? - ruby-on-rails

I'm new to Ruby on Rails and am creating a test application. So far, it's working, but when I make some minor changes to my views, the page doesn't change.
My problem may be related to this question, but I'm not sure what is meant by setting the date and time in the VM. My code is on a remotely hosted server, so I assume it would use the system time of that machine.
Is there a caching issue here? What can I do about it?

If you don't have control over the server environment yourself (no shell access, etc.), you can set the following at the top of config/environment.rb:
ENV['RAILS_ENV'] = 'development'
Development doesn't cache much, so while it's slower it's much nicer to develop in.
You'll still need to restart your app after making changes to anything outside the app/ folder though (configs, plugins, etc.).

You need to restart your Rails app (or Apache if you are using Passenger) if you are in production mode!

Related

Is it possible to reload production Rails 3 app with Thin?

I would like to reload production application running with Thin. I know there is development mode, but our app is so complicated it simply cannot run in the development mode (it is very slow and unusable as we are more-or-less enterprise integration app). And we are not able to upgrade to Rails 3.2 which improved development mode.
Is there any way of reloading configuration with Thin or do I need to restart everytime? If not, I will keep restarting everytime I need to change something on a production setup in our testing environment.
In your config/environments/production.rb file you could turn the caching settings to false in order to have it behave more like development. This will allow you to update models etc.. without needing to restart the server. You won't want to check that into source control though. This may negate your entire reason for using production environment to speed things up though.
For reloading environment or initializer configurations you must always restart the server whether in development mode or not.
I personally would just be running the development environment as thats the intent. I've work on a couple large enterprise apps, and not had development environment unable to run...
If performance is the issue there are a couple things you could try to speed things up:
1) try using active_reload which was the precursor for much of the Rails 3.2 performance improvements https://github.com/paneq/active_reload
2) you can look into precompiling your development assets if its the asset pipeline slowing things down

Deploy Rails App

I have been asked to make a few cosmetic changes to our production deployment. I have access to our linux box where I can see the files I need to change. I only need to change html.erb files, but when I add, for instance a simple <p> tag, it does not show up live.
I know I probably have to reset the server or redeploy the code, but I have no idea what to do.
Our production deployment is not fully live, so I am making changes on the fly (I know that this is not the best practice). Our app is running in a shared hosting environment for the moment.
I have seen threads where people use Capistrano to deploy but how? We do not currently use it.
Can anyone help?
Whenever you make changes in production files, you have to restart the server to see the changes.
In production environment cache_classes is set to true. One can disable it and changes will be reflected without restarting the server.
So to reflect the change restart the server.
thanks......
I found a good guide on the Capistrano github wiki and also used this guide # kris.me.uk about a complete rails setup, including the Capistrano deployment aspect. I used them when learning how to deploy rails apps effectively. They should tell you what you need to know to get a basic deployment setup up and running.
Just incase someone is looking for the answer:
When rails is in development mode it will automatically reload changed files. When in production I need to restart it.
I eventually found out that we use God (A proces monitoring framework for rails - link here).
I had to restart our app with the following command: 'god restart APP_NAME'
Hope that helps someone :)
I wrote a Capistrano // NGINX guide and posted it on my blog. It's 85% correct, and should help you understand the big picture of the server/Rails/SSH configurations.
http://westonplatter.com/blog/2012/08/19/rails-slash-nginx-rackspace-deployment/

How do I deploy my Rails Application

I've been spending the last few months on developing a (my first) Rails application all by my self, just me and my Linux box, all in my development RAILS_ENV, no SCM ("for shame!") or anything. It has become quite the beast now and I am getting ready to release it onto the world. My question is: how am I ever going to make this work?
I installed gems, plugins, servers (MySQL, node.js, nginx, sphinx, juggernaut), photo compression apps that I call, video compression tools (FFMPEG) etc, I also obviously have a DB and a (lot of) seed data. I can't even remember all the things I did to my system to make it all work, but it does.
So now, when I deploy this on some stranger's server, how do I make sure that all those things get installed and configured correctly? How is e.g. FFMPEG ever going to get installed on this server when I deploy my application. How will the seed data get uploaded, how will the servers get started, with the right parameters etc.
I have read (a little bit) about Capistrano which seems to be the deployment tool of choice in the Rails community, but I am not sure if that will cover all my needs. For example, how do I figure out all the gems I used or the plugins (do I even need to know?). Is there any way I can test the deployment on my own linux box,the same I am developing on, i.e. pretend that I am hosting my own production server/rails_env and "deploy" it there?
Any help will be much appreciated.
Cheers.
There a lot of standards to follow that make life easier...
As far as figuring out which gems you need, you could try and use RVM and make a local config that you keep adding gems to until your app works. This will be kind of like starting from scratch so that you are sure to know precisely what configuration you need to run. (And it should make it easy to stand up a new, identical environment each time.)
The RVM route will allow you to test in a specific environment, which should help.
You can list the required gems in your environment.rb file so that the server demands them on start-up.
Good Luck, Cowboy .

How did this Ruby on Rails app get deployed?

I have a Ruby on Rails app running on my server, and I can't figure out how it was deployed (someone else set it up).
The app is located in /var/www/myapp. Before it was deployed, I had been able to go in there and make minor edits to the app. The person helping me out with RoR then "deployed" it. It was unclear what deploying actually did, since it points to the same database and is on the same server. However, I can no longer edit it (or at least, the files I am editing are not being pointed to by the server).
Any way to figure out how this thing was deployed so I can take it down to edit it? Or should I basically just start over?
Was it maybe running in development mode before, and now it's in production? When it's in development mode, all of the files are loaded on each request, so your changes show up immediately. In production mode, you have to restart the server to see your changes.

(Rails, Warbler) Deploying and initializing Rails applications in Glassfish…?

I posted this very same item on SERVERFAULT, but got no reply. So here goes:
I'm currently in the process of finishing up a Rails application. I am using Warbler to package it up as a ".war" file and am using GlassFish to deploy it. I do this because the application is to be distributed to companies for in-house use. Arguably i could/should have used another framework to develop an application of this nature, however, I chose ease/speed of development over deployment hassle.
That said, I've got the setup working reasonably well on my development machine. However, I'm curious as to how to go about automating environment initialization. In other words, I need to figure out how to ensure that all DBs, files,etc. are configured upon deployment.
All of the examples I've seen thus far assume you're running your IDE on the system to which you wish to deploy and they have you run your rake tasks manually before deployment. However I need to simply give the end user the ".war" and be able to run all rake tasks upon application deployment/launch.
Can someone point me in the right direction regarding this? FWIW there is nothing in the Glassfish manual about environment initialization etc. -- then again, I don't suppose I should expect them to cover every single aspect of deployment.
Best.
Depending on your database requirements you can embed Derby within the Glassfish environment. You can easily create a blank/default database and then put that clean version in each Glassfish environment you have to set up.
I'm not sure what else you need to configure and initialize, but I'd say that if you can, script it up, either with some rake tasks. Embedding Derby takes care of database startup and initialization. Remember that a war file is just a zip file, so adding config files via a script shouldn't be so hard. You can use rails initializers (/config/initializers/) to load up yml files for configuration or whatever you need to do as the app starts up.
You won't be able to have the intializers create the schema in the database, but you could have them check for default seed data and put it in if it isn't there.
You should be able to access any part of the file system that Glassfish and the JVM can access. I don't know much about Glassfish but the only problems I've had with jruby rails apps on Tomcat were related to relative paths being relative to where the startup script was called from, and not always relative to the installation root. This could probably be solved with the right startup scripts in Tomcat or setting the appropriate start-in folder, I just haven't had a need to dive in to that very much.

Resources