require 'legacy_migrations'

#Assuming you've already created classes for source and destination tables
transfer_from Person, :to => Animal do
  match_same_name_attributes :only => [:sex, :age]
  from :name, :to => :pet_name
  from :from_record, :to => :species do |from_record|
    "Homo Sapien"
  end
end

Here’s the full list of options you can pass to ‘transfer_from’ (at the time of writing, of course):

• :limit – Set a limit to the number of rows to transfer. This is useful when you’re trying to find faulty data in the source table, and don’t want to run the entire dataset.
• :validate – Default = true. Use ActiveRecord validations when saving destination data. Reports errors in the StatusReport (a singleton object)
• :source_type – Default = :active_record. Sets the source destination type. Options: :active_record: Assumes the From option is a class that inherits from ActiveRecord::Base, then iterates through each record of From table by using From.all.each… :other: Assumes the From option is an iterable ‘collection’ whose elements/items can respond to all columns speficied in the given block.
• :store_as – Store the resulting generated record to be used in a future transfer_from or update_from operation. You can access this object like so:

  transfer_from Person, :to => Species, :store_as => 'new_species' do
    from :name, :to => :species_name
      "Homo Sapien"
    end
  end
  
  transfer_from Person, :to => Animal do
    from :pet_name, :to => > :name
    stored :new_species, :to => :species  # Uses the species that we
                                          # created in the previous
                                          #  transfer_from
  end
  

Aside from those helpers, you also get the ‘match_same_name_attributes’ helper that…wait for it…matches same-name columns between the source and destination tables. Here’s a quicky:

transfer_from Person, :to => Species, :store_as => 'new_species' do
  match_same_name_attributes :only => [:name, :age, :date_of_birth]
  # There's also an 'except' option, and if
  # you don't use either, then the script
  # just transfers all same-name columns.
end

You can also use the gem to update data periodically using the ‘update_from’ operation. The
update_from operation uses the well-known squirrel plugin syntax to match records from the source database, to records in the destination database. If the source record doesn’t exist in the destination, then it gets automatically created. Think of this as ‘find_or_create_by’ on steroids. For example, let’s say you want to update first names in the Animal model, from the latest data in the People model, and the identifying and matching features between the source and destination tables are the date_of_birth and last_name columns:

update_from Person, :to => Animal do
  based_on do |from_record|
    date_of_birth == from_record.dob
    last_name ==  from_record.last_name
  end

  from :first_name, :to => :first_name
end

Here’s the git repo:

http://github.com/btelles/legacy_migrations

To install it just use:

gem install legacy_migrations

If you have any suggestions, please let me know!

Update:

By the way, this gem is considered beta software and to get a better idea for how to use it, you may want to look at the rspec files. They’re the most comprehensive documentation.

Here are the slides to a quick presentation I gave at our local Ruby Brigade, in case anyone’s interested.

Talking about references, I found Quince on Ajaxian.com, an excellent resource for web development goodies.

The basic idea is that you can classify almost all types of interactions that users can experience that are not WIMP (window, icon, mouse)-based with this framework, and by doing so, you’ll have an easier time conducting studies. It’s an interesting idea, but will it hold up to scrutiny?

Like any well-meaning scientist’s blog, the next few posts will try to challenge this framework not because I think it is not useful, or because I have an  itch for knocking down big ideas, but because this is how science works. We challenge each other’s ideas in a spirit of arriving at a more accurate or helpful presentation of the world we live in. In the mean time, you may want to take a look at their article from the proceedings (you’ll need to contact them to get a copy if you don’t have access to the ACM Digital Library):

Reality-based interaction: a framework for post-WIMP interfaces
Full text	Pdf (528 KB)
Source	Conference on Human Factors in Computing Systems archive Proceeding of the twenty-sixth annual SIGCHI conference on Human factors in computing systems table of contents Florence, Italy SESSION: Post-WIMP table of contents Pages 201-210 Year of Publication: 2008 ISBN:978-1-60558-011-1

It works like this. You log on to Facebook or HeyCosmo.com, select or create a question that you want to investigate (questions range from finding reservations for a type of restaurant to asking a bunch of friends which movie they want to watch). Then HeyCosmo calls all the relevant parties (your friends, the restaurant to reserve seats, etc.), makes them push 1 for The Hulk or 2 for Spiderman then sends you the response. WELL done guys!

One thing that the Facebook version lacks is the ability to pick up your friends’ phone numbers automatically. But I think that’s a Facebook API problem, not a HeyCosmo problem. Of course, if there were an application that merged contact phone numbers from another service (e.g. Yahoo, GMail or Outlook) and made it available to the Facebook HeyCosmo application, then that’s technically your information, thus giving HeyCosmo the right to use it.

Good job gentlemen! Keep up the awesome work!

If you look at the online demo you can see that the architects came up with some very interesting ways of displaying relationships. It looks similar to Digg’s Swarm, but instead of displaying votes, it displays relationships between people. So if two of your clients happen to work at the same company, a line is drawn between their two nodes on a chart area. If two clients are family members, then a very strong line is displayed between them.

Since the product just launched in September 9, though, there’s not a lot to find out from the website. For example, the site says that “Accordia can connect to most CRM systems” but it doesn’t mention exactly which ones. Nonetheless it’s an interesting way to look at relationships between people. If you’re a sales person who thrives on making those faint connections between your clients to get the extra credibility, Accordia’s for you.

In their analysis, Sohn et al dissected 421 information needs and analyzed the heck out of them. But the most interesting findings are probably just the information needs themselves. They placed each need into one of 16 categories. The following categories occurred most frequently:

1. Trivia (e.g. How did Bob Marley die?) : 18.5%
2. Directions to a known destination: 13.3%
3. Directions to a Point of Interest (destination unknown): 12.4%
4. Friend information: 7.6%
5. Shopping: 7.1%

Of course, you can make the common academic comment that people would make about these types of studies, which is:

“But people only think of these information needs because it’s the type of information that’s actually available on the web…if their minds were open to reporting any information need, we’d probably see a lot more variation or a lot more needs over a period of two weeks from 20 people.”

After reading the article, though, I can tell you that these researchers did a lot to try and not bias the results. I’ll let you read about their methods in the article though (linked below).

At any rate, the raw categorical data does shed some light on how you can design a site’s mobile profile to better address mobile users. For example, if you’re designing a site for a floral shop, you may want to make directions and pricing information more prominent in the mobile profile than in the large screen profile. The directions section would ideally ask someone to type in their “from” address, and submit the form to take them to a mapping service with directions to your store. The pricing section might have three elements:

• a search box at the top for quick flower or arrangement lookups,
• a list of 3 to 5 of the most popular flower arrangements or flowers,
• and perhaps a one-click reservation button that allows users to reserve a flower by entering their name and date. (I can think of several friends whose anniversaries would be saved by such a feature)

Their study goes into a lot more detail about the reasons people do or don’t address their information needs while mobile, but I found those conclusions didn’t help as much as understanding the type of information users need in the first place. If you want to read more about the study, you can download it at Tim Sohn’s page at the University of California, San Diego.

P.S. I orginally posted this article at RefreshTallahassee.org, but figured I’d add it to my own blog since, well, right now it’s not much of a blog.

References

Sohn, T. et al (2008).A diary study of mobile information needs. Conference on Human Factors in Computing Systems, 433-442.

This blog is geared at the design of software interfaces. Hopefully over the coming months you’ll see analyzes of various peer-reviewed and sometimes even non-peer-reviewed journal articles that address frontend design. Some common terms that you might think of when you think of frontend design include interaction design, usability, user experience and information architecture. If you’re into that kind of stuff, you and I will get along just fine.

For those of you not terribly familiar with these terms, just send me an email and I’ll be glad to help you get a feel for the field. I’ve only been working in it for about 3 years, but have absolutely fallen in love with the field and its potential to improve the quality of life of end users all over the globe.
Until later!
Hope you enjoy this!
Bernie