bgror

Construct »

Created at: 30.09.2009 23:16, source: The Life Of A Radar, tagged: Uncategorized

Over the past month or so I’ve learned to dislike Integrity for all it’s quirks. Whilst it’s a fabulous piece of software in theory the bugs (”notifyofbuild” fails, attempting to press “rebuild” attempts to go to a page that doesn’t exist, etc.) and it’s single threadedness has driven myself (and others) up the wall.

Last Tuesday I was in The Zone, and coded Construct effectively that night. It was as functional as integrity and didn’t hang when there was a build in progress! It works by running on port 80 and uses Github’s & Codebase’s post-receive hooks (you’ll have to set them up yourself I’m afraid).

So go try it out for yourself! Interested in your feedback for it.

Driver: Now In All New “Linux” Flavour »

Created at: 02.09.2009 23:52, source: The Life Of A Radar, tagged: Uncategorized

That’s right, Driver (everyone’s favourite Passenger setup tool) is now able to run on Linux! I’ve only thus far tested it on Ubuntu, but there’s nothing foreseeable that would stop this running on any other distro. Let me know!

Resource Controller for “Skinny” Rails Controllers »

Created at: 24.07.2009 16:46, source: Rails Dog, tagged: Uncategorized resource_controller

These days it seems to be conventional wisdom to build “skinny” controllers in your Rails app. Skinny controllers help you to consolidate your business logic into one place (the model) which allows for easier maintenance and testing. If you’re still not convinced, perhaps you should watch this informative public service announcement.

I’ve been using the excellent resource_controller plugin by James Golick for well over a year now. Its an excellent tool for handling the standard RESTful controller actions that one normally codes by hand (or generator.) We currently use it in the Spree project and yesterday I was curious to compare the size of these controllers to those of a project that does not use resource_controller. First lets look at the results of running rake stats on the Spree project.

As you can see, there are 44 controllers in this project. Yeah, that’s a lot of controllers but Spree is a pretty huge project (its a full featured e-commerce platform.) Now notice that out of 44 classes we only have 111 methods. That’s an average (rounding down) of only 2 methods per class! The methods themselves are also pretty skinny with an average of 8 lines of code per method.

Now lets take a look at Fat Free CRM. I chose this project because it is similar to Spree in that its a full featured platform (not just a little plugin.) DISCLAIMER: I’ve never used this application but I’ve heard good things about it. I’m in no way trying to disparage another person’s work here - I just need a point of comparison.

You can see that this project’s controllers are pretty fat. There are only 12 of them but they have more lines of code then in the 44 controllers of Spree. There are 11 methods per controller (compared to 2 in Spree), with the typical method size being the same as Spree. Don’t let the equivalent method size fool you. For instance, take a look at this typical 4 line method in a Spree controller.

create do
  flash nil 
  wants.html {redirect_to edit_order_url(@order)}
end

This is an example of how we override the default resource_controller behavior. In this specific case we did not want to include anything in the flash, nor redirect to show after object creation. If you’re happy with the resource_controller defaults, this method is not even needed.

If you’re interested in a thorough overview of resource_controller, Fabio Akita has produced a very detailed screencast on how it works. Its one of the longest screencasts I’ve ever seen (about 1 hr) but its well worth the time if you’re struggling to wrap your head around how REST works in Rails (both with and without resource_controller.)

Using Rack to Combine Sinatra and Word Press »

Created at: 02.06.2009 18:44, source: Rails Dog, tagged: Uncategorized ruby sinatra wordpress php rack

There’s been a lot of buzz recently around the lightweight Ruby framework known as Sinatra. It seems ideally suited for simple web applications that require a little sprinkle of Ruby and using the entire Ruby on Rails stack might be overkill. You’ve probably also heard of Rack (unless you’ve been without Internet access for the past six months.) If you’re new to Rack and would like to learn more, you can check out this excellent presentation from RailsConf. I recently had the need to build a website that featured a blog along with some minimal dynamic content so I thought I would try hooking up Sinatra together with the Word Press blog engine.

WordPress(WP) is an excellent blogging platform. Its the consensus tool of choice for professional bloggers (those who blog for a living as opposed to people like me who occassionally blog about technology.) Since I was really happy with WP and I believe in using the best technology for the job, I wanted to see if I could get it working alongside Sinatra which I planned to use for the rest of the site. Why not just do the whole thing in PHP? Well the answer is that I hate programming in PHP. I didn’t mind using an excellent tool like WP but I didn’t want to get carried away with the PHP when it came to my own coding.

First, you need to get WP up and running with Apache HTTP Server. You can use any server really but I would recommend Apache since its widely used and well documented when it comes to PHP applications. There is no shortage of WP setup documentation so I’m not going to cover it here. Just be sure to setup WP in its own directory (/blog) instead of the top level root directory. Once you can reach your WP blog via http://example.com/blog then you’re ready to proceed.

You’re also going to need to install Phusion Passenger. I’m not going to cover installation of Passenger either since most Rails developers are already familiar with it. If you’re not, I suggest you read some of the excellent documentation on the subject. What you may not know, however, is that Passenger also supports arbitrary Ruby web appications that follow the Rack interface (like say … Sinatra.) So lets get started with a simple Rack app and then move onto Sinatra.

Install the Rack Gem

Lets make sure the rack gem is installed on our server.

gem install rack

Create the Directories Required by Rack

Suppose we are creating an application called example which is located in the /webapps directory

mkdir /webapps/example/public
mkdir /webapps/example/tmp

Create a Basic Rackup File

We also need to create a /webapps/example/config.ru for starting the Rack application

app = proc do |env|
    return [200, { "Content-Type" => "text/html" }, "hello world"]
end
run app

Change the Document Root

In the Apache config you will want to configure the DocumentRoot to point to the public directory in your Rack app (/webapps/example/public). Leave your WP blog directory where it is for now. Restart Apache.

If you navigate to your application in a web browser you should see the familiar “hello world” greeting. This means Phusion and Rack are now working together without a problem. Lets add Sinatra to the mix.

Setup Sinatra

Install the Sinatra gem if you haven’t done so already.

gem install sinatra

Replace your config.ru with one that will setup Sinatra

require 'rubygems'
require 'sinatra'

Sinatra::Application.default_options.merge!(
  :run => false,
  :env => :production,
  :views => '/webapps/example'
)

require 'app.rb'
run Sinatra.application

Now create an app.rb which will be the basis for your Sinatra app

get '/' do
  'Hello Sinatra!'
end

Restart Apache and navigate to your local application using your web browser you should now see the Sinatra greeting that we just added.

Add the WP Blog

Move your entire blog dir into your Sinatra public directory. So you will now have /webapps/example/public/blog along with the original .htacess file used by WP. Your blog won’t work yet, there’s an important tweak to be made to your httpd.conf

<Location /blog>
  PassengerEnabled off
</Location>

This tells Passenger not to bother with files in the blog directory. This is key to getting the PHP-based WP blog to run inside of a directory where everything else is Sinatra. If you test your application inside of a web browser the blog should be working!

Build Out Your Sinatra Application

Go ahead and build out the rest of your Sinatra application now. Most likely you’re going to want to share a common layout, header and footer between your Sinatra application and your WP blog. You can add “partial” support in Sinatra using a helper (Sinatra does not explicitly support partials.)

Modify your app.rb as follows:

get '/' do
  @section = 'overview'
  erb :overview, :layout => :default
end

helpers do
  # Usage: partial :foo
  def partial(page, options={})
    erb page, options.merge!(:layout => false)
  end
end

Then you can create a default.erb to serve as the default layout.

<html xmlns="http://www.w3.org/1999/xhtml" dir="ltr" lang="en-US">
<head profile="http://gmpg.org/xfn/11">
  <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
  <link rel="Shortcut Icon" type="image/ico" href="/blog/wp-content/themes/spree/favicon.ico" />
  <title>Spree</title>
  <link rel="stylesheet" href="/blog/wp-content/themes/spree/style.css" type="text/css" media="screen" />
</head>
<body>
  <div id="page">
    <!-- BEGIN: Header -->
    <%= partial :header %>
    <!-- END: Header -->
    <div id="main">
      <div class="content">  
        <p>
          <%= yield %>
        </p>
      </div>
    </div>
    <!-- BEGIN: Footer -->
    <%= partial :footer %>
    <!-- END: Footer -->
  </div>                 
</body>
</html>

Notice how I am using the favicon and stylesheets right from the WP blog theme. From this point on we’re just writing a nice Sinatra application and sharing styles and images with our WP blog.

Final Thoughts

This is an excellent way to build a simple Ruby based website that requires a blog. I started off by having my artist just work up a design for the WP blog since she could do that on her own without any Ruby. I then copied the header and footer into my Sinatra app and created some stub ERB files for her to edit. Sinatra worked out well for my very simple needs. I basically needed a simple way to share layouts and to highlight the current navigation tab in my header.

My artist was able to edit these ERB files in place because they were basically straight HTML. All of the dynamic stuff was contained in the layout itself. The end result is a seamless integration of Ruby + PHP where each technology is being used for what it does best.

A Public “Thank You” »

Created at: 06.05.2009 09:04, source: Rails Dog, tagged: Uncategorized github phusion railsconf resource_controller

@GreggPollack put together an excellent RubyHeroes presentation before the keynote.  In addition to recognizing some of the great contributions these individuals made, Gregg suggested that we all take a moment to thank at least three people whose work has made our lives that much easier.  So instead of getting caught up in minor complaints about the accomodations or speeches, I decided to throw out some more positive energy.

1. GitHub - I’m not going to waste a lot of space talking about how much of an impact GitHub has made on the Rails community.   Its not like these guys are toiling away in anonymity but their contribution has been so important that I’m just going to go on record as saying “Thanks.”

2. Phusion - Again, everyone knows what these guys have done for simplifying Rails deployment.  Just because they get plenty of “Thank Yous” doesn’t mean I can’t throw my own two cents in here.  I also had the opportunity to thank one of the Phusion guys in person at dinner this evening.

3. ResourceController - James Golick’s plugin finally convinced me to embrace REST.  If you’re not familiar with it, its a great way to simplify the implementation of your standard RESTful controller.  My controllers became way more DRY as a result.  Again, saw James at dinner and shook his hand in person but it doesn’t hurt to say it here.

Honorary Mentions:

• DHH and RailsCore for Rails (DUH)
• Chad Fowler and company for organizing RailsConf
• Gregg Pollack for the Ruby Heroes presentation, conference videos and the entertaining RailsEnvy podcasts (along with Jason Seifer.)