Onehub blog

Using Onehub as a Virtual Data Room

cmount@onehub.com (Charles Mount) — Mon, 13 Jul 2009 02:30:00 GMT

One of the most powerful things about Onehub is its flexibility. You can modify almost all aspects of a Hub including the appearance, number of Pages and Widgets, permission settings and Hub Notifications. This flexibility allows Onehub to be used in a variety of business to business scenarios such as Virtual Data Rooms. Several Investment Banks have adopted Onehub as a Virtual Data Room for M&A transactions.

If you are not in the banking or legal industry you may not be familiar with the term. Below is a short definition from Wikipedia.

A virtual data room (VDR) is essentially an Internet site with limited controlled access (using a secure log-on supplied by the vendor/authority which can be disabled at any time by the vendor/authority if a bidder withdraws) to which the bidders and their advisers are given access. Much of the information released will be confidential and restrictions should be applied to the viewers' ability to release this to third parties by forwarding, copying or printing.

Onehub provides an easy-to-use, affordable alternative to traditional Virtual Data Room Providers

Here are a few tips for setting up a Virtual Data Room using Onehub.

1. Configure Notifications and History. You can configure Hub Notifications and History so users cannot see what other users are doing. Why? If you invite three potential buyers to the same Hub you don't want them to see who the other buyers are and what files they are downloading.

To set notification and history, click Manage from the Administrator bar at the top of the Hub and then choose Notifications/History. Uncheck the options for Author, Contributor, and Reader.

2. Remove Activity Widgets. An Activity Widget in a Hub shows all the events by default. You can remove Widgets from a Hub by clicking on Design & Add Widgets from the Administrator bar. You can remove any widget by clicking the Red Close Icon in the top right corner.

3. Use History and Activity to Track Usage. Using File History, the Hub Administrators can view all activity for an individual file. This provides a quick way to audit when users have downloaded a document. With Activity filters, you can easily track all activity in the Hub included when users accessed the Hub, downloaded files, or made changes.

To setup a Hub filter, click on the Activity tab from the User Home. Select the Hub name from the drop down. Type a name for the filter and click save. You can simplify the view by hiding your own activity from the report.

For more information about using Onehub as a Virtual Data Room, please fee free to contact us at support@onehub.com.

Handling multiple pollers and multiple process groups when using Activemessaging and ActiveMQ

bmoran@onehub.com (Brian Moran) — Tue, 07 Jul 2009 02:03:00 GMT

Eventually, your web application is going to need to do work asynchronously to web requests- tasks like transcoding videos, generating notifications or newsfeeds, performing 'slow' file operations. You'll likely need a message queueing system such as ActiveMQ, Amazon SQS, RabbitMQ, or commercial products from IBM or Tibco. For a variety of reasons, we are using ActiveMQ as our message broker, and Activemessaging is how our rails application talks to it. We've developed some techniques to divide our message processing between a number of process groups so that long-running tasks don't get in the way of shorter-duration ones, yet can be monitored and managed effectively in the activemessaging context. We've also learned of some tweaks that might help others.

A typical infrastructure requiring asynchronous processing may have one or more web servers fronted by a load balancer; one or more database servers, a 'services' server (where the message broker runs), a 'work' server that actually handles the deferred jobs from the various queues. In our example, content can be uploaded to the individual web servers, but this content must eventually get put into secondary storage (SAN, Amazon S3, etc.) Some jobs, such as generating previews, or video transcoding, are not performed on the web servers; it's better practice to have a pool or processors that can perform this work, so over time the number of processors can be scaled.

Our asynchronous workload mix spans a wide range: from cpu-engrossing operations (video transcoding) to 'lighter' tasks such as email sending. Using activemessaging, processors are assigned to different process-groups in the config/messaging.rb file. An example config/messaging.rb file (similar in concept to what we actually use) is:

ActiveMessaging::Gateway.define do |s|
   # /script/poller start—process-group=notifier_group
   # /script/poller start—process-group=asset_group
   # /script/poller start—process-group=media_group
   # service server runs all groups.
   # web servers run asset_groups.

   s.processor_groups = {
      :notifier_group => [:email_sender_processor,:feed_builder_processor, :job_finished_processor],
      :media_group => [:preview_builder_processor, :video_transcoder_processor],
      :asset_group => [:move_to_secondary_storage_processor]
    }

   s.destination :feed_builder,        '/queue/FeedBuilder'
   s.destination :email_sender,        '/queue/EmailSender'
   s.destination :q_job_reply,         '/queue/QJobReply'
   s.destination :preview_builder,     '/queue/ContentItemPreviewBuilder'
   s.destination :asset_mover,         '/queue/AssetMover_' + MY_HOSTNAME
   s.destination :video_transcoder,    '/queue/VideoTranscoder'
 end

Use the same `messaging.rb` everywhere, run different mixes of process-groups

We use the SAME messaging.rb on all of our servers—we vary the pollers that we run based on the server type. Web servers only run the asset_group. Service servers run media, notifier, and asset groups. For operations that need to happen on particular machines (e.g. moving particular assets from one machine to another), we've added the hostname (MY_HOSTNAME is set in config/environment.rb with MY_HOSTNAME = `hostname`.chomp) to the queue designation—on each machine that is running a processor, it listens on it's particular queue for those messages.

On a webserver, where assets are uploaded by customers before being moved to secondary storage, a poller is started with: /script/poller start—process-group=asset_group

On a services server, run /script/poller start—process-group=asset_group, /script/poller start—process-group=notifier_group, /script/poller start—process-group=media_group.

Modify the poller to include the process group in the process name and PID file name

With the stock script/poller, there is no differentiation of process name (poller) or PID file (/tmp/pids/poller<N>). Running the above commands on a service server would show three 'pollers', and there would be poller0.pid, poller1.pid, poller2.pid files. If one wanted to kill or restart a particular poller related to a particular process group, it's difficult to do. Using an external monitoring solution such as monit to supervise your pollers, to make sure you have one of each? You can't with the stock poller.

Solution? Modify your poller.rb to include the name of the process group in the process name and PID file:

#!/usr/bin/env ruby
require 'rubygems'
require 'daemons'
require    File.join(File.expand_path(File.dirname(__FILE__) + '/..'), 'lib', 'daemons_extension')

APP_ROOT = File.expand_path(File.dirname(__FILE__) + '/..')
script_file = File.join(File.expand_path(APP_ROOT),'vendor','plugins','activemessaging','poller.rb')
tmp_dir = File.join(File.expand_path(APP_ROOT), 'tmp/pids')

# find the process group name by looking at the command line prompt for the process group.
process_group_name=''
if (argidx = $*.index('—'))
  # look for process group
  $*[argidx..-1].each{|rrg|
    if (m = rrg.match(/process-group=(.*)/))
       process_group_name = "_#{m[1]}"
       break
    end
  }
end

options = {
  :app_name   => "poller#{process_group_name}",
  :dir_mode   => :normal,
  :dir        => tmp_dir,
  :multiple   => true,
  :ontop      => false,
  :mode       => :load,
  :backtrace  => true,
  :monitor    => false,
  :log_output => false,
  :force_kill_wait => 30
}

Daemons.run(script_file, options)

Now you'll see poller_asset_group, poller_notifier_group, poller_media_group in the process list, and /tmp/pids will have poller_asset_group0.pid, poller_media_group0.pid, poller_notifier_group0.pid. You can set up monit or your favorite watcher on the PID file particular to the type of process group.

Whats more, if you need to scale across the enterprise and add more work processors, you'll always be able to tell how many of each kind you have by the name.

Rails Processors - Take One Bite At A Time

By default, each activemessaging poller will pull a number of messages from ActiveMQ, then work on them from it's own queue. If for some reason 'bad things happen to good pollers' and it must be killed, those messages disappear. It's better to have your processors only accept one message at a time. Add :ack=>'client' to your subscribes_to :

class MoveToSecondaryStorageProcessor < ApplicationProcessor

  subscribes_to :asset_mover, {:ack => 'client'}

  def on_message(message)
    #do something with the message
  end
end

(yes, 'client' is a quoted string. Don't use a symbol.)

Rails Processors - Chew, don't gobble

Activemessaging will attempt to prefetch a number of messages from your broker so that network traffic overhead is minimized, which is a generally a good thing if your intent is to process many small messages very quickly.

However, the messages that A13g has pre-fetched are unavailable to any other additional processors that you may add in response to increased message traffic.

It can be a little confusing—An example might help. You see that your existing queue length is large (say, 100 messages), and your single processor (processor #1) is working away at the messages. You don't expect more messages for a while, but you want those 100 to get handled faster. Starting another processor (processor #2) for that queue, you watch as it starts up, but it never receives any messages! It's precisely because those 100 messages have been prefetched by the original processor. If 50 more messages are sent to the broker, you'd find that about 25 messages go to processor #1, and 25 go to processor #2—processor #2. Processor #2 might even finish processing ALL of it's 25 (or so) messages before Processor #1 gets to ANY of the message in the second batch.

The solution is to only prefetch one messsage at a time—Add 'activemq.prefetchSize' => 1 to your subscribes_to :

  subscribes_to :asset_mover, {:ack => 'client',
                               'activemq.prefetchSize' => 1}

Conversations with Customers: Jen Francis Design

kricketts@onehub.com (Kurt Ricketts) — Mon, 06 Jul 2009 02:49:00 GMT

We’re excited to announce a new blog series called “Conversations with Customers” . Every few weeks we will feature a new customer and share with you their successes while using Onehub. We hope that each interview opens up new ways to use the service and even unlock some new ways of thinking about your current business processes. We will feature companies from all industry types and sizes, each who are using Onehub in their own unique way. This week I had the privilege of interviewing Jen Francis of Jen Francis Design, a graphic design firm located in Warwick, New York. Read more about how Jen is utilizing Onehub as a client extranet.

Kurt Ricketts (Onehub): Tell me about what you do? What is your specialty?

Jen Francis: We do everything from print to web, logos, brochures, annual reports, ads, trade show booths, websites with content management systems, and our clients range from everything from pharmaceuticals to food service.

Kurt Ricketts (Onehub): How are you using Onehub today?

Jen Francis: We use Onehub as a client extranet solution to share files and collaborate with our clients.

Kurt Ricketts (Onehub): Can you give me an example of a client that you work with and how you’re using Onehub with them?

Jen Francis: We’re doing a pro-bono project for the library in our town here, and they ran a photo contest for their annual calendar, we had over 200 entries and needed to pick 13 winners for the calendar. Everybody was flooding my inbox with these large images, since we needed high res images for the calendar. So we sent out a Hub invitation for each person that won and they were able to go in and just upload their images to the Hub so they weren’t bogging me down.

We use it a lot, say we’re building a website for a client, we set up a hub and everyone on the project can upload their content to it – from the sitemap to the images. It allows us to better collaborate with the developers, we can upload the hi-res images for them to download.

Kurt Ricketts (Onehub): Based on your evaluation of other solutions, what led you to choose Onehub?

Jen Francis: It was a variety of things, the price for what you get… a lot of other solutions either didn’t give you enough storage space, workspaces, or were difficult to manage. We looked at some solutions that were way too costly.

Kurt Ricketts (Onehub): What are your clients, partners, and colleagues saying about the Onehub service?

Jen Francis: Well I personally think it’s very intuitive, the people that know their way around the internet are instantly comfortable with it, or those who have the basic knowledge of how an ftp site would work.

You really don’t need instructions, you just go on and immediately know what to do and it’s not hard to find your way around, everybody seems to be very pleased with it.

And it’s great for our printers too, instead of having to upload to all our different printers’ FTP sites, and trying to figure out all the different ways to send files through their sites, we just upload everything to Onehub and they can grab what they need. It is also great for when I want to work from home for a day, I have all my files on Onehub.

Kurt Ricketts (Onehub): Would you say you’ve been able to save time or money with Onehub?

Jen Francis: Definitely, instead of building a custom extranet, or having someone build a custom ftp site for us, Onehub is much more robust compared to the amount of money we would have to have paid to develop one. It just didn’t make any sense to reinvent the wheel.

Kurt Ricketts (Onehub): Jen, Thank you for your time.

Jen Francis: Thank you very much.

Overhauling the Onehub Email Newsletter

mtierney@onehub.com (Michael Tierney) — Thu, 02 Jul 2009 01:59:00 GMT

One of the easiest ways for us to keep our users in the loop about what's going on here at Onehub is through our monthly email newsletter. When I built the first version of the email, it was designed to look like an extension of our main website. However, due to a recent design update to the site, the newsletter was now out of date and no longer met that goal. This meant it was time for a redesign of the newsletter.

Newsletter Redesign Objectives

Add in a new sidebar with content about the weekly product demonstrations
Develop an easy-to-maintain, well tested, template
Create a template that would promote a consistent layout from issue to issue

Pushing Pixels

The fundamental flaw of the old newsletter was that every issue required more customization than was really necessary. To offset this, I developed a new layout. This new layout has two persistent columns, a header, and a footer. The columns house the content of the newsletter (one column for the main content, and one for the sidebar).

I chose to set my content width to 600px to ensure that all email clients will be able to view the newsletter without having to scroll horizontally. It also allows the content enough room to breathe.

Beware the Fold

In addition to addressing the width of the columns, I also wanted to make sure that I was using my vertical space more effectively. In email design, the concept of the "fold" is still relevant. This concept comes from print design (specifically from newspapers), and it refers to putting the most important information on the top half of the front page - which would be face up on newsstands, for anyone passing by to see.

For a long time this way adopted by web designers as well, with the "fold" being the bottom of the browser viewpane (basically, whatever was viewable without scrolling). This is really not a valid concept in web design any longer, for a wide variety of reasons, but it's still applicable in email design.

Primarily because of the reduced viewpane space in email, as well as the sheer volume of email that has to be dealt with, users are much more critical of email. While most users will at least scan a webpage, if something vital doesn't pop out in an email right away, chances are that user will move on to the next one. Because of this, it's absolutely critical to make sure that your most important information is as visible as possible to the user.

The old version of the newsletter followed the website very closely in that it had a horizontal band that housed the logo (and some information specific to that issue) as well as a strip for the navigation. So in order to make more room for the increase in content, I removed the navigation strip (which didn't have any real function anyway, there were no links) and reduced the height of the band that held the logo just a little bit. This ensured that more of our content would be visible "above the fold."

Template Building

With my design mocked up, I started to prototype the new version of the newsletter. To get this done quickly, I built up a straight-forward HTML document. I also set up an external stylesheet, rather than trying to write my CSS in-line right off the bat, which can be time-consuming and error prone (think about adjusting the margin on multiple different links several times).

Part of my template structure allowed me to isolate where the content would live. The design dictated a smaller area for the content, so content could just be inserted and it would flow properly. This also means that maintaining the template would become simplified, since the editable area was similarly reduced. Basically, there is only one td that ever substantially changes.

Test, Test, Test

The more times you can run your code through the wringer, the better. Anyone who has browser tested a website will understand the basics of this. Like a website, email will render different in every email client.

The biggest issue in email testing is the sheer volumes of clients that you have to test against. To offset this, I use a web app called Litmus; it's not unlike Browsershots except that it also offers up the ability to test email. This is a HUGE benefit for the wayward HTML Email Developer, since they cover all of the major email clients as well as many of the more obscure ones (if you really want to see what your email looks like in Lotus Notes, you're more than welcome to do so).

The End Result

After all of that hard work, here is the final product:

Reinventing the Onehub Editing Interface

manderson@onehub.com (Matthew Anderson) — Wed, 01 Jul 2009 02:00:00 GMT

Evolution is one of the most important and interesting challenges of designing interfaces. As your application matures your user base grows, the number of features increases, and new use cases are discovered. Because of this, it is vital that you continue to revisit your original design decisions often. Otherwise, your simple and straightforward experiences can easily turn in to splintered, confusing processes.

A good interface is only ever as complicated as it needs to be

Recently, we redesigned the Onehub editing interface for this exact reason. When we launched Onehub last year, we started with 5 widgets. Now we have 11 (with more in the pipe). We had already begun to run out of space in our editing pop-ups (modals) when we added recurring events to our Calendar Widget. This change resulted in a modal that was simply too big and too complicated. In order to make the feature work, we had to break our own rules and give Calendar Events a much larger editing space.

Consistency is everything

The instant that we decided to move Calendar Events outside our modal framework, I started working on a new editing interface. Why? Because once you figure out how a process works, any part of it that works differently sticks out. Inconsistency breaks workflow. The interface had lost the consistency it once had and it was important that we get it back as soon as possible.

Making changes work for your existing users

Major interface changes can be difficult on existing users. Adding features is one thing, but you can't just change everything overnight. Sometimes, abrupt changes can be just as disappointing to existing users as subtracting features. The only way to minimize frustration is with usability testing - so we did a lot of it. With usability tests, we ensured that the new interface worked for both new and existing users while delivering on our design requirements.

Design challenges

Ensure that every widget can be edited in the same manner
Ensure that the interface is just as easy for new users as it is for existing users
Keep the interface flexible to changes in the future
Add in two highly requested features (comments and tags)
Add in our own new features (next/previous navigation and edit-in-place)
Maintain all existing features

The concept

Architecture

A. Navigation

This area provides navigation that allows the user to return to where they were and cycle between items in their widgets.

B. Banner

This area contains the most important information for each item. When glancing at an item, you will spend the majority of your time in this area. This always includes Title and Description along with a piece of primary meta information (e.g. Completed, Location). The banner also contains a breadcrumb trail to keep you abreast of where you are at all times. Last but not least, the banner is host to the action buttons (e.g. Edit and Delete).

The action buttons are at the top of the page, while the submit buttons (E) are at the bottom. This was intentionally done to mimic the following workflow:

Click in or navigate to the desired item
Click Edit
Make any necessary changes from top to bottom
Click Save

C. Tabs

A row of tabs for showing/hiding additional information without losing the primary information from the banner. By default, each item contains a Details tab containing all of the meta information for that item. Once created, a Comments tab is also added to the view.

This area is flexible horizontally. For example, Files contain a Versions tabs which displays version control information. This will give us the ability to add more information without requiring us to change the interface again.

D. Content

This area contains less important information for each item (e.g. Priority, All Day Event) and additional features (e.g. Comments). When working on an item, you will spend the majority of your time in this area.

E. Submit Buttons

This area is where you finalize your interaction with each item. Depending on what you're doing, the submit buttons will change. For example, when creating new items you will see a Save and Add Another button.

F. Sidebar

This area contains related information for each item. For every item in Onehub that now means Tags; we have some cool ideas for future additions as well. This area is flexible vertically. For example, Files contain a Preview that shows a thumbnail of what the file looks like.

The end result

Measuring success

Another difficult aspect of interface design is measuring success. If you've done a horrible job, people will certainly let you know. If you've done an awesome job, you most likely won't hear about it - users will be off using your new interface. It never hurts to be sure though. So, please play around with the new editing interface. If you've got any feedback, please let us know. Leave a comment below or ping us at feedback@onehub.com.

Coordinating The Onehub Cloud

loe@onehub.com (W. Andrew Loe III) — Mon, 29 Jun 2009 16:44:00 GMT

Onehub is built on the Amazon Web Services Platform, and as a result we are able to quickly and easily provision new servers to meet demand. We have servers for load distribution, web serving, queue processing, transcoding, administration, and other tasks. Consequently, every new server we launch needs a specific configuration in order to fulfill its functional role in our infrastructure. After careful consideration, we settled on Puppet to manage the configuration of our servers. Puppet does the majority of the heavy lifting—installing packages, writing out configuration files, etc—but, we still needed something to group and instruct these Puppet instances. Combining a number of open source tools, we were able to vastly simplify the management of our cloud, and bring the familiar cap deploy to our infrastructure.

Assembling The Pieces

At the center of our mash-up is iClassify, a small Rails application that registers Puppet instances as nodes in a database. iClassify provides a YAML description of an individual server to the Puppetmaster, the central Puppet server that compiles the configuration for individual nodes. In order to facilitate registering these nodes, we extracted the icagent tool from iClassify and made it available as both a gem and RPM. Using Facter, new nodes come with a host of attributes that describe the server which enables configurations to be specifically tailored. Finally, we use Capistrano to glue everything together.

Setting The Stage

Before any servers can be launched, iClassify and Puppetmaster must be up and running on servers that will be available to all other machines that will register with it; it is handy if both of these services are on the same machine. For simplicity, in our Puppetmaster configuration, we enable autosigning of certificates for all machines with *.internal addresses, but beware, this setting can be dangerous if your machines need to communicate over the internet as opposed to a private LAN.

The Puppetmaster needs to be configured to use iClassify as its external node terminus. Once setup, Puppetmaster will query iClassify for the classes and variables (tags and attributes respectively) to compile as the configuration (catalog) for each individual node:

Starting The Show

At the base of all new servers is our 'Stem Cell' image. This Amazon Machine Image has only two packages beyond a basic Linux Distribution: Puppet and icagent, at boot it is configured to run both of these.

First, icagent: $ /usr/share/icagent/bin/icagent -d /usr/share/icagent/recipes/

This command run icagent's recipes against the server and then submit all of the gathered information to the iClassify server along with a UUID.

Second, Puppet:

$ /etc/init.d/puppet start

The newly registered node will default to receiving the base Puppet configuration which includes a few handy packages and Puppet modules we use on all of our machines:

Issuing Orders

With our new machine up and running, we need to assign it a role. On the iClassify server the newly registered node will show up at the top of the server listing. It is a good idea to edit it to have a more descriptive name, and then add the tags (that will map to puppet classes) that define its role. In addition to the standard attributes, we will add a custom puppet_env to each node that enables us to correlate servers with our application's environments (i.e. master, staging, or production). This is critically important as it lets us selectively disable cron tasks and other jobs that we would not want run against test data (like billing!).

Now that the machine is tagged it will eventually run all of the specified Puppet recipes and be ready to receive the 'live' tag. However we're going to take this a bit further with some nifty Capistrano scripting.

Stringing Up The Puppets

Using the iclassify-interface gem we can take a simple Capistrano deploy script and adapt it to coordinate our Puppet instances.

This example uses a standard Capistrano deploy scheme. Please note that the deploy path from Capistrano should match the module location for the different Puppet environments, our Puppet instances run in the same categories as our application (i.e. puppetenv == railsenv).

Now, deploying new puppet recipes is as simple as $ cap staging deploy, the code will be checked out of version control and Puppet will be restarted on all the servers in that environment. We can also use this same trick in our application's deploy script.

When it comes time to deploy the application the list of servers is dynamically generated, saving us from having to tediously edit the deploy.rb file.

The Final Act

While the simplified deployment of our configurations is a huge feature in itself, the true beauty comes in making 'smart' Puppet recipes. For example, we have an instance of nginx that functions as a load-balancer: it proxies to our web servers. Nginx needs to know which 'webservers' are available for it to proxy to at any given time. Inside our nginx manifest we can define a search for the Puppetmaster to perform against iClassify to populate this list:

$nginx_lb_search = "puppet_env:${puppet_env} tag:webserver tag:live"

We simply (1) start a new server, (2) tag it, (3) deploy our application, (4) tag it live, (5) then deploy Puppet. The first few times there were a few kinks (hey that's what staging environments are for!), but with all of the pieces strung together, we have automated an amazing amount of tedious and error-prone work. A new webserver will boot, install all of our base packages, receive the application and start its processes, then get automatically included in to the load-balancers round-robin list.

Tips & Tricks: Subscribing to a Onehub Calendar Widget

bcaplan@onehub.com (Brandon Caplan) — Mon, 29 Jun 2009 01:00:00 GMT

Did you know that you can subscribe to a Onehub calendar widget? This works with software that supports internet calendars in the iCalendar format. It's a great way to keep up to date with events stored in your Hub, along side calendars you have outside of Onehub.

Enabling Calendar Subscriptions

While in Design Mode, click the orange icon that appears in the upper right of the calendar widget you are enabling subscriptions for.

Copy the ics URL, then check the box to publish the iCal feed and save.

Subscribing to an Internet Calendar

Check out this screencast that guides you through the entire process: How to Subscribe to a Onehub Calendar »

Note that not all calendaring applications support internet calendar subscriptions. We will be covering two of the more popular ones that do, Apple iCal and Microsoft Outlook 2007.

Apple iCal

Select "Subscribe..." from the "Calendar" menu. Paste the calendar URL and click "Subscribe".

Now choose a name (enter a description if you would like.) You should also select an auto-refresh interval so the calendar will self-update. Just hit *OK* and you're done.

Microsoft Outlook 2007

Select "Account Settings..." from the "Tools" menu. From here click the "Internet Calendars" tab and click "New...".

Now paste the calendar URL and click "Add".

Next choose a name, enter a description if you would like, and hit "OK".

The calendar will be listed under the Other Calendars section on the left sidebar. Check the box to show the calendar.

Decorating ActiveRecord Accessor Methods

lcaplan@onehub.com (Leigh Caplan) — Thu, 25 Jun 2009 09:05:00 GMT

Recently, I was faced with a quandary. I needed to impart some of our ActiveRecord accessor methods with special functionality, but I also needed to maintain the default behavior for those fields. This was done to support a new input type which we added to the venerable CalendarDateSelect plugin which allows a user to enter a date, time, and meridian, all in separate fields.

Though I could parse each of the fields in the controller and pass the resulting time to the model, this is messy, error-prone, and unnecessary.

What I really want to be able to do is something like this:

My first thought was to simply override the accessor methods like so:

However, as I alluded to before, there's a problem with this approach. Rails already does some magic behind the scenes to ensure that time values stored to your ActiveRecord objects are automatically cast to and from UTC. The code above will completely overwrite these default accessors, and time zone casting will cease to function for those fields. What I really want to do is decorate these accessor methods, so that I can add to the existing functionality without completely circumventing it.

One way we might think about accomplishing this would be to redefine our accessor method and add behavior to it using alias_method_chain.

Try that, though, and you'll get this fun little error

`alias_method':NameError: undefined method `start_time=' for class `CalendarEvent'

It doesn't work because there is no original start_time= method to alias; ActiveRecord creates those methods only when the class is loaded, because it has to read the columns from the database at runtime. So, how do you decorate methods which haven't even been created yet? Well, it turns out you have to decorate ActiveRecord::Base.define_attribute_methods, which is responsible for creating accessor methods for each model.

There are a couple of ways you can go about doing this, depending on your goals. I wanted to be able to use these enhanced date/time inputs with any model in our application and trigger it from an initializer, so my approach uses alias_method_chain to modify ActiveRecord::Base directly.

Ok, so what exactly does that code do? First, we call the original version of define_attribute_methods. If that returns true, then we know that the attribute accessor methods have been generated. We loop over each column in the model, checking to see whether it stores either a datetime or a timestamp. If so, this is an accessor we're interested in decorating. We do a quick check to make sure we haven't already decorated the accessor (which can bite us in development mode), then we redefine the accessor with time parsing, and use the magic of alias_method_chain to alias our original method but still maintain a reference to it.

At the bottom, we use the Module#included callback to add the methods contained in our module, and we once again use alias_method_chain to redefine our version of define_attribute_methods.

Then, in the initializer, you would write something like

At this point, any time-based field in any of your models will be able to accept a hash as a value, and properly parse it.

This works well, but one thing I don't like about this solution is its rampant use of alias_method_chain. There has been some debate in the Rails community over its validity as a design choice, though there really are no other options if you need to modify all subclasses of ActiveRecord::Base (as you would to support a plugin like CalendarDateSelect).

Another Approach

If modifying every subclass isn't a design requirement, you can clean up the code significantly:

Notice here we're just defining define_attribute_methods and calling super when we want access to the previous implementation. The same goes for decorating the actual accessor methods.

The downside of this approach is that you have to explicitly include the module in your ActiveRecord models:

As with any decision, the approach you take will depend on your requirements, and tradeoffs you're willing to make between explicitness and ease of use.

Sharing and controlling access to business videos

lmoudy@onehub.com (Laurel Moudy) — Tue, 23 Jun 2009 09:03:00 GMT

Businesses need to securely share video files for many reasons. For sales purposes, for presentations to customers or clients, or for educational or training purposes.

The hard part comes when you need to share the video outside your corporate firewall and still control who has access to the videos. Let’s face it, not all video belongs on YouTube. For companies like marketing agencies that share draft commercials with their clients, retailers that share instructional videos with distribution partners, manufacturers that share sales videos with potential customers, and non-profits that share educational videos with large private audiences — providing the ability to securely share videos has been a burden on IT resources until now.

How Onehub helps you securely share video outside your firewall

Onehub makes it easy to create customized Hubs for securely viewing videos. Simply add a video widget to your Hub and upload your video. You choose who has access by inviting them to be a member of your Hub. Onehub allows you to upload source video files directly to Onehub or embed videos from popular video sharing websites. Onehub accepts videos in all major formats including .WMV, .AVI, .MOV, MPEG, .MP4, DivX, .FLV, and .OGG as well as embed code from YouTube, Vimeo, or Viddler.

Do you need to train a team distributed around country or globe? Do you need a customized solution for presenting work to your clients? Take a look at this sample Hub to find out how you might share your videos on Onehub.

Sending Large Files with Onehub

cmount@onehub.com (Charles Mount) — Wed, 17 Jun 2009 07:20:00 GMT

QuickHubs provide a simple way to send or receive files from other people and are now one of our most popular features. You can send or receive multiple files at once and setting up a QuickHub is done through a simple, one step wizard.

There are many benefits to transferring files with Onehub instead of email attachments or physical media.

Send really big files. You can send or receive files up to 2 GB in size and can send multiple files at once.
Save Money. Using Onehub is much cheaper than burning a DVD to deliver via FedEx or a local courier.
Track what is happening. With Onehub, you receive notifications via email when files are uploaded or downloaded.
Make Your Customers Happy. Files can be sent in minutes instead of waiting for a DVD via mail.

Click Send Files from the User Home to Start

The next step is a short wizard to select recipients and the files to send.

Personal Information. Enter the email addresses of one or more people and a short description of the files. The description will be sent in the notification email and will be shown on the download page.
Optional Information. Set a Hub expiration date, choose to subscribe to activity for the Hub or to make the Hub public.
Files to Send. Select files from your computer or network. You can send hundreds of files at once and each individual file can be up to 2 GB in size.

Hub Automatically Expires (optional) - If set, the Hub will no longer be available after the Expiration date. You can disable the expiration and the Hub will remain active until you manually deactivate it.

Notify Me of Activity (optional) - If set, you will receive notification emails of activity in the Hub including when users download the files you are sending them.

Make this Hub Public (optional) - If set, users are not required to setup a Onehub password and login to download the files. This is not recommended for sensitive or confidential information.

Your Customer's Experience

The recipients receive an email from you with a link to download the files from Onehub. Take a look at a sample SendHub to see what your clients will experience.