February 10th, 2010
Sometimes you have a Rails app, the core functionality is not a CMS, and you need to add some static pages to your app that don’t get changed often, eg, an about us page, privacy policy, etc.
This post shows you a quick and easy way to do that in about 60 seconds, without using a database model or having to write any sort of CMS.
1) First off, add some routes for your static pages. Here I want an FAQ page, About page, Privacy page, and Terms and Conditions pages.
map.with_options :controller => 'static_pages', :action => 'show' do |static_page|
static_page.faq 'faq', :id => 'faq'
static_page.about 'about', :id => 'about'
static_page.privacy 'privacy', :id => 'privacy'
static_page.terms_and_conditions 'terms_and_conditions', :id => 'terms_and_conditions'
end
2) Add a functional test so we know it works now, and we can check we don’t retrospectively break it later. Create a new file in test/functionals/static_pages_controller_test.rb:
require File.dirname(__FILE__) + '/../test_helper'
class StaticPagesControllerTest < ActionController::TestCase
should_route :get, '/privacy', :action => 'show', :id => 'privacy'
should_route :get, '/terms_and_conditions', :action => 'show', :id => 'terms_and_conditions'
should_route :get, '/faq', :action => 'show', :id => 'faq'
should_route :get, '/about', :action => 'show', :id => 'about'
%w(privacy about terms_and_conditions faq).each do |static_page_template|
context "Accessing the #{static_page_template} page" do
setup do
get :show, :id => static_page_template
end
should_respond_with :success
should_render_template static_page_template
end
end
end
This is fairly simple but covers everything we need it to. It just checks your routing is setup and the pages render from the static template files correctly.
3) Create your controller, app/controllers/static_pages_controller.rb:
class StaticPagesController < ApplicationController
def show
page = params[:id]
render :template => "static_pages/#{params[:id]}"
end
end
Again, really simple. Use a RESTful ’show’ method to select a template to render, then render it.
4) from a shell, make a directory for your pages to live in, and create the empty files:
$ mkdir app/views/static_pages
$ touch app/views/static_pages/about.html.erb
$ touch app/views/static_pages/faq.html.erb
$ touch app/views/static_pages/privacy.html.erb
$ touch app/views/static_pages/terms_and_conditions.html.erb
5) Check it works:
$ ruby test/functional/static_pages_controller_test.rb
Loaded suite test/functional/static_pages_controller_test
Started
............
Finished in 0.156958 seconds.
12 tests, 24 assertions, 0 failures, 0 errors
Done! Now put the content in your pages, test, check in and deploy.
Categories: Rails
Tags: development, Rails, Testing
February 7th, 2010
In case you haven’t heard, Rails 3 is now in Beta.
Just a quick post to say, if you haven’t already, check out the Rails upgrade plugin, this will quickly show you what bits of your code need to be updated to work with Rails 3.
Also, check out the full release notes, lots of juicy stuff in there.
Categories: Rails
Tags: Rails 3
February 6th, 2010
Over the life cycle of a project many features may be developed, sometimes just to account for one variation or tiny use case, get used once, and are then not used again for the next 5 years (if ever).
One of my personal pet peeves is overly complicated software with too many redundant, old, unused features. This sort of redundant complexity increases the learning curve for new developers coming into the software project and creates extra work in maintaining the software,
I often think the best way to create and maintain software, is to periodically remove all the old crap not being used any more. Some people do not like the idea of losing a feature in their application, as in “OMG, you can’t take that away, I was planning to use that one day”, and maybe they were. But often, you have to look at what they say they are going to do, and compare that with what they actually do.
I am sure this is some sort of psychological effect where the fear of losing a feature has more of an emotional impact on the end user / client than the prospect of faster software development and the addition of new features, as well as cheaper maintenance.
If the feature works, can’t it just stay?
Hypothetically yes, but sometimes the part the end user sees is that the old features only continue to work because when adding new features we are able to test we have not broken the old features, and in some cases that means a ton of work when a big structural change is occurring.
Also consider the development of a new software project, or a big addition to an existing project. The number of proposed features grows exponentially with the number of people involved. In reality, only 20% of the features will make 80% of the software, but you may end up coding 80% of the features to make up 90% of the functionality, just because people don’t get agile, or the business structure around you does not allow for it to happen so easily (extensive budgeting approvals, waterfall methodology), or of the HiPPO effect (Highest paid person’s opinion).
This post has been a bit of a rant, but the points are these:
* Don’t develop crap you don’t need
* Remove old crap you don’t use any more
Do points 1 & 2 and you will get:
* Faster software development
* Software that is easier to maintain
* Easier to bring in new developers to a project
* Happier developers
* Reduced costs all round
Categories: Productivity
Tags: agile, development, philosophy
January 15th, 2010
There is a nice little tool over on tmto.org that allows you to decrypt (or should I say, reverse) MD5 or SHA1 hashes. Essentially, someone has forward hash’ed all a-z letters, put them in a database, then matches your hash against what is in the DB to find what the original string was. This is somewhat limited, it only currently does a-z by the looks of things, but a very nice idea. Should also re-enforce the benefits of double-salting your passwords with a per-size and per-user based salt as well.
Categories: Uncategorized
August 6th, 2009
I think autotest is one of the best things about developing in Rails. If you don’t know, autotest runs in the background watching all of your application files. When you edit any of them, it automatically runs the sections of your test suite that apply to the modified file, and can then give you feedback as to if your tests are passing or failing. This means more time developing, less time switching windows to run rake test!
I thought I would post a note about how to correctly install autotest, as some of the other documentation is out of date.
sudo gem uninstall ZenTest
sudo gem install ZenTest
sudo gem install autotest-rails
Something that is missing in a lot of other online documentation is the fact that you have to install the autotest-rails gem as well, if you don’t do this, you will get an error any time you try to run autotest:
Autotest style autotest/rails doesn't seem to exist. Aborting.
Another note, if you want to get desktop notifications working, this page has details of how to achieve that using Mac OSX, KDE, Gnome, etc.
Categories: Productivity, Rails, Testing
Tags: autotest, Testing
