Don't Forget to Plant It! » ruby on rails

Running FiveRuns TuneUp in a Separate Environment

Calvin — Mon, 06 Oct 2008 01:23:24 +0000

FiveRuns’ TuneUp is a great tool for profiling your Rails app, but by default it is always running in development. This causes two issues 1) every request is slower in development as it is always collecting profiling data, and 2) the TuneUp bar can mess with the layout of your application, especially if you’re rendering content in iframes like we do with Skribit. So instead of having TuneUp always run in development mode, I’ve changed it to run only when the server is started in a new environment called ‘profiler’. Here’s how I did it.

First, you need to tell TuneUp to only run in the profiler environment. You do this by modifying config/tuneup.rb (create this file if it doesn’t already exist):

Fiveruns::Tuneup.config do |config|
  config.environments.delete('development')
  config.environments << 'profiler'
end

Next, copy the development configuration block in config/database.yml and create a new block called profiler:

profiler:
  adapter: mysql
  encoding: utf8
  database: YOUR_DATABASE
  username: YOUR_USERNAME
  password: YOUR_PASSWORD
  socket: /tmp/mysql.sock

Finally, create your profiler environment configs by copying your development configs:

cp config/environments/development.rb config/environments/profiler.rb

You’re all set! Now, to run the server with TuneUp on, just run the server in the profiler environment:

script/server -e profiler
Now, I have TuneUp available to me only when I'm looking to optimize performance.



Aptana Goes into the Clouds
Calvin — Sun, 07 Sep 2008 13:53:35 +0000
I use Aptana for RoR development.  Not because it’s a good Ruby or Rails IDE, but because I do so much Java at my paying job and switching between Java development on Eclipse to RoR development on Aptana is a breeze.  Today, I was checking out Aptana’s website for updates when I noticed that they now have a product called Aptana Cloud.
Aptana Cloud appears to be a integrated deployment/hosting platform for Aptana.  You can write applications in PHP, Jaxer (Aptana’s AJAX framework), and Ruby on Rails (coming soon), and deploy them to a cloud with a push of a button.  Right now, it deploys to Joyent’s Cloud, but it appears that the intention is to be provider agnostic, which would be key for adoption.
I’m very interested in trying this out, though I’m going to wait until RoR support is ready.  Hopefully, this will lead to some standards to cloud computing, making it easier to switch from one provider to another.  No doubt this is where lightweight development frameworks should be going (looking at you Appcelerator).



Taming Beast: How to Extend Beast using Plugins
Calvin — Wed, 05 Sep 2007 03:10:44 +0000
If you’re building a Ruby on Rails application and are in need of some forums functionality, you’ve most likely have looked into Beast.  However, Beast is very limited in functionality (which I actually think is a good thing), so you might find yourself needing to extend Beast to do the things you want.
Fortunately, Beast has a plugin feature that will easily allow you to do this.  In this post, I’ll cover how you would do this, using my StyleEditor plugin as an example.
The Plugin File Structure
First, let’s cover plugin file structure.  This is what my StyleEditor plugin looks like:

Here are the important points to note:

app: The directory structure of this directory should follow the same conventions as the main Rails app/ directory.  Code located in this directory follow the same class loading (and reloading) rules as the main app/ directory.
lib/beast/plugins/style_editor.rb: This is the plugin class, where all the magic happens.  The name of the file should be the tableized version of the plugin’s actual class name.  The plugin class file must be located in beast/plugins, or else Rails will not be able to find it.

The Plugin Class
Here’s what’s the plugin class should look like:
module Beast
  module Plugins
    class StyleEditor < Beast::Plugin
      author 'Calvin Yu - boardista.com'
      version '0001'
      homepage 'http://boardista.com'
      notes 'Style Editing Support'

      %w( controllers helpers models ).each do |dir|
        path = File.join(plugin_path, 'app', dir)
        Dependencies.load_paths << File.expand_path(path) if File.exist?(path)
      end

      def initialize
        super
        ApplicationController.prepend_view_path File.join(StyleEditor::plugin_path, 'app', 'views')
        # Patch Beast code here.
      end

      def install
        super
        # Run any install processes here.
      end
    end # end StyleEditor class
  end # end Plugins module
end # end Beast module
You can see what the final source looks like here.  Here are some things to note about this class:

The author, version, homepage, and notes methods provide some meta information for the plugin.
The Dependencies.load_paths call will configure the sub-directories under app/ so that they’ll be dynamically loaded by Rail’s dependency resolution process.
The ApplicationController.prepend_view_path call will prepend this plugin’s view path ahead of the normal Rails view path and any other view paths configured by other plugins loaded before it.  This is important to remember if views aren’t being rendered like you’re expecting them to.
Any changes to existing Rails or Beast controllers, models, etc. should go into initialize, in the form of monkey patches and mixins.
Any installation tasks, such as file copy, should go into the install method.

Adding New Routes
I needed to create some new routes for my StylesController, so I used the route method of the Beast::Plugin class to install them:
# add this within the class scope of the StyleEditorroute :resources, 'styles'
I’m using the RESTful syntax to creating routes here, but you can also use :connect and named routes as well.
Updating the Beast Schema
To update the Beast Schema, all I needed to do is to create a Schema class within the scope of your plugin class:

 
class Schema < ActiveRecord::Migration
  def self.install
    create_table :style_options do |t|
      t.string :name
      t.string :value
      t.integer :style_id
    end

    create_table :styles do |t|
      t.string :name
      t.string :template_name
      t.boolean :active
      t.timestamps
    end
  end

  def self.uninstall
    drop_table :styles
    drop_table :style_options
  end
end # end Schema class
The code in install/uninstall methods will work just like the up/down methods in a typical migration class.  There is an issue where there’s no support for handling db changes overtime — hopefully someone will find a nice way to handle this (any takers?).
Using the Rails Console
At some point, you’ll want to do some quick tests to make sure your plugin changes are working as you expect them to, and try to test them from the console.  If you have tried to this already, you’ll quickly find that your changes for some reason won’t work.  Don’t fret, the reason why it doesn’t work is because the plugins aren’t initialize until the Dispatcher receives its first request.  So, if you do want to test your changes in the console, you’ll need to run this command first:
Dispatcher.send :prepare_application
Installing a Plugin
Once you’re done with your plugin, you’ll need to install it.  This step is pretty easy.  First, install your beast plugins into vendor/beast, then run the plugin install method:
script/runner 'Beast::Plugins::StyleEditor.install'
Some plugins might have some additional installation instructions, so I would suggest looking at the README file (and if you’re developing on a plugin, make sure to put your install instructions in the README).
That’s It!
It’s important to note that Beast plugin system is an evolving system, and the steps I laid out here are what worked best for me through the process of trial an error.  I’d love to hear what conclusions others have come to in their plugin development exploits.  If you want to get a better feel of what an actual Beast plugin looks like, you can check out the plugins that I’ve developed at http://svn.codeeg.com/beast.  If you want to see what those plugins look like in action, you can check them out on Boardista.com.
Powered by ScribeFire.



Which web framework is right for your business?
Calvin — Sat, 19 May 2007 03:34:54 +0000
Jeff’s follow up answers for Thursday’s Web Entrepreneurs meetup was good idea, so I’d thought I lay out some of my answers from a Java perspective.  I think Jeff is spot on when he talks about how someone should choose a web framework for their business — rely on your technology team to chose the right one.  There isn’t one great framework out there that, by itself, will give you any significant business advantage (however, having a great technology team with a framework that’s right for them will).
What kind of websites is your technology best suited for?  Which is it not so well suited for?
Java is best suited for enterprise-level websites, which includes websites that are highly transactional and requires integration to legacy systems or multiple data sources.  That isn’t to say that you can’t built small websites with it (although its rather uncommon).  One of Java’s advantages to building a website is that there is a Java library for just about everything you can ever imagine doing on a website, and a you’ll find that a good number of them are free.
I don’t think that there’s any kind of websites Java is not well suited for (hold on… let me finish), but I do think there are other web frameworks that are much better suited for simple, database-driven websites.  The reason is that Java is traditionally used to serve a diverse set of enterprise needs, its can be very cumbersome to setup and maintain, as there are lots of pieces to put together and configuration that has to take place.
What famous web2.0 sites are using your technology?
This was a tricky one.  The only one I found was Zillow.  eBay is another website that uses Java, and has web2.0-ish features.
What does it cost to use your technology (e.g. hardware, software and support)?
The Java platform is (just recently) open source and free.  There are production-ready, free versions of server software as well as commercial versions if you need support.  As for people cost, the Java talent pool is probably the largest of any of the other technologies, especially in Atlanta.   Having said that, traditional Java setups can run you quite a bit of money, and you would be competing with enterprises for top Java talent.  There is also more overhead when dealing with Java as oppose to more streamlined alternatives like the other technologies.
How steep is the learning curve for newcomers?
In retrospect, and after some discussion with the panelists, I’ll concede that Java has a steeper learning curve than many of the other platforms on the panel, especially when you include the server setup, configuration and other aspects of putting together a Java website.
How easy have you found it to find skilled people?  How about in Atlanta?
Since Atlanta is the home of so many large enterprises, the demand for Java talent (as shown here) is great, therefore there is large pool of Java talent of varying skill ranges to pull from.  Of course, the demand also means that the best Java talents get top dollar salaries.
How much support is there for your technology? Who have you found to be reliable?
Support is great for Java — you have options that are free (in forums, blogs), as well as commercial server products with support.  Also, you’ll often find that you can buy support for a good number of open sourced Java products.What issues (if any) did you encounter being an evangelist for your technology in your organization?  How did you overcome them?
Since Java is often considered a standard in the enterprise, I’ve never had a problem evangelizing Java in organizations.
What add-ons, plug-ins, tools, etc. would you recommend using?

Ant 
Tomcat
Lucene
DWR

With the recent popularity of Ruby on Rails, there’s been many efforts in the Java community in adopting the parts of that framework into Java.  Here are a couple of those frameworks.

Trails
Grails

What are some sites youâ€™d recommend?

Javadocs: http://java.sun.com/javase/6/docs/api/
Java.Net: http://www.java.net/
Java Ranch: http://www.javaranch.com/

During the Q&A session, Alan asked which language I felt learning would make a better programmer.  My answer was Ruby, and in fact, while I do work on Java during the day, I work with Ruby on Rails on nights and weekends.  IMO, the speed of development trumps all other concerns during the early stages of the game.  And while performance concerns with RoR are valid ones, having to scale is usually a good problem to have, and I’m confident on my ability to work them out.



MyPlaces Update and Self-consuming Microformats
Calvin — Thu, 02 Feb 2006 04:03:05 +0000
I took the effort and modified the MyPlaces script to support both the Yahoo! and Google Maps APIs.  I also fixed a problem with the generator application not working in IE.
I like the idea of having a webpage consume its own microformat – whereas common usage of microformats indirectly benefit the author (through aggregation), with this script I was able to provide immediate benefit to the author for using microformats.  Maybe the key to more widespread adoption is to provide more apparent benefit for authors.



Using Microformats to Plot My Favorite Places
Calvin — Sat, 28 Jan 2006 19:04:33 +0000
Currently, the most popular use of microformats is to export them to their native formats, (hCards -> vCards and hCalendar -> iCal), but there’s really should be more utility for microformats than that.
Here’s one neat thing you can do – I created a little application that will allow you plot and describe places on a Yahoo Map easily using the hreview and geo microformats. Generate the HTML from the application, slap it on your own blog (with your own Yahoo! Application ID of course), and away you go.  To modify the web plots, just revise your HTML and reload.
Check it out and let me know what you think.  I used it to plot some places around my neighborhood where I like to eat.



The Fight for Rails for Java is a Good One.
Calvin — Sat, 21 Jan 2006 16:51:52 +0000
I couldn’t agree more with Chris on the reasons for a Rails-like framework for Java.
In many ways, I see a lot of similarities between this struggle and the one between POJO’s vs. EJB:  a struggle between robustness vs. simplicity.  This has been a hard realisation for me because whereas I was a big opponent of EJB’s, I’ve always been (and still is) a huge supporter of Struts.  However, when you see how easy it is to build applications on frameworks such Ruby on Rails, it becomes pretty clear that the cost of innovating in Java is currently way too high.  Nowadays, whenever I want to build up a new application to test out ideas, I’m not doing it in Java anymore – it just doesn’t get me to where I want fast enough.  For the most part, web application frameworks are just a means to an end; if you’re spending too much time there you’re just jerking off.
And the unfortunate thing about not using Java is that as you build up your application, you find yourself missing the vast array of Java libraries and tools out there today.  On the flipside, Java misses out on the new ideas garnered from a developer’s late night binges of inspiration.  We need to be removing the obstacles and making sure that we developers get access to the heart or the Java platform quicker and easier.
In a lot of ways, I see Ruby on Rails  and its like as a disruptive technology, and applaud those in the Java arena looking to embrace it.  It is pretty chaotic right now, with a new framework popping up every few weeks or so, but eventually there will be one or two that will rise to the top.