Following up from our previous interview with Drupal Connect we check in with Vice President of Engineering and Lead Developer, Tim Loudon, to find out about their latest Drupal product for education called Trekk!
1) First up, a lots gone on at Drupal Connect since our previous interview, can you give us a quick update!
Sure, busy as always. We recently launched sites for the Stanford School of Engineering, Stevens Institute of Technology, and have a few really cool international sites for a pair of Fortune 500 clients and a top tier apparel and accessories brand that are just about to wrap up. We should have updates on our website about these projects in the next month. There are probably dozens of other cool sites that we are working on, but those come to mind. Outside of that, our Support business continues to grow by leaps and bounds. It’s a great compliment to Acquia’s Enterprise Support that meets the needs of SMB’s.
2) Next up, Tim tell us who you are & your role in Trekk
Well, I manage large projects and do custom and complex back-end coding for Drupal Connect. I frequently get the edge-case problems, so my unofficial title is “The Cleaner”. I’ve been working with Drupal Connect for a little over two years now and have spent the majority of the past twelve months working with some fantastic universities. A good deal of that work has focused on legacy content migration. I am the project lead for Trekk and my primary contributions have concerned legacy content migration. Trekk has a great team of developers supporting it though, Chris Jones, Mike Crittenden, Kim Murphy, and Jonathon Whitener have all made commits and really brought this idea to life.
3) What is Trekk & why was it built?
Trekk is a Drupal Distribution for universities. It’s aimed at universities that have made or are looking to make a large investment into Drupal. Trekk provides an easy way to share content across Drupal sites. Say you wanted to cross-list courses or bios on multiple department/school sites, courses and bios are complex entities that have multiple fields, so flattening these out in some kind of XML RSS feed (Views + Feeds) is easy to do in Drupal but problematic from a maintenance/update perspective. In a Views + Feeds approach, it would be difficult to maintain relationships between say a professor and her publications. Trekk simplifies this process and provides tools to share custom content across sites in a way that’s robust, flexible, and easy to maintain. So our professor could update their bio and list of publications on one site and see this content updated across one or more sites in a matter of minutes.
Back in March, after six months of being heavily involved in university projects, I started to see some patterns. The initial release of Trekk is our first attempt at capturing those patterns in a reusable fashion. We know lots of universities need to share content across sites, and we also believe a distribution will be the best way for us to promote and share our work. We hope that others can leverage our efforts and push the state of the art.
4) What are the stand out features of Trekk?
As I alluded to before, the primary purpose of Trekk is to share content across sites. However, every university I’ve worked with has also had an amazing amount of legacy content that they wanted to port into Drupal. In fact, one of the main drivers of adoption we’ve seen has been Drupal’s strength as a flexible yet robust content management system. University administrators are unbelievably excited to start editing their content in Drupal and finally be able to get their hands around it, but all of the legacy content has been a bit of a barrier for that. So we built-in support for easy migrations. This should enable universities to get the their content into Drupal and be 90% production-ready in maybe half the time it would have otherwise taken. This is all done via the web, so there’s no hold up on VPN access, proprietary database systems, or any of that either. A developer could literally start migrating their university’s legacy content right now.
5) I noticed a spot of Ruby in there, how & why is it being used?
Yeah, that’s Flatfish, a Ruby gem I wrote that we’ve been using for about a year now at Drupal Connect. It’s a very flexible web scraper. It takes a CSV of URLs, meta data, and CSS selectors and saves the resulting XHTML to a database. There’s a bit of housecleaning with links and it tokenizes images and files for later use in Drupal too. I’m pretty happy with it, I think it’s saved us a ton of work and provided a huge amount of value to our clients.
I chose to use Ruby for maximum flexibility and power. I wanted each CSV file to roughly map to a Drupal Content Type. That is a legacy page might have three distinct pieces of information we want which would correspond to the node body and two custom fields in Drupal. Another legacy page (represented as a different Drupal Content Type) might have two pieces of information, a node body and one custom field. You get the idea. One of the core Ruby on Rails libraries provides this kind of data structure elasticity, so I was able to write code without needing to worry about the underlying database table structure for each potential Content Type or use case. Secondly, there’s an awesome Ruby gem called Nokogiri that parses XML and XHTML with CSS selectors. Almost everybody who develops on Drupal knows a bit of the ubiquitous jQuery, so the tools to find and inspect XHTML via CSS selectors are in every web browser and most devs can quickly understand and start using Flatfish. It certainly helps to know Ruby, but a majority of the tasks involved with the migrations can be done with just a solid knowledge of CSS, XHMTL, and Drupal.
I should point out that there’s a Drupal module also called Flatfish that takes the scraped XHTML out of the database and imports it into Drupal. It’s also designed to be flexible if your Content Types match the CSVs you provided the Ruby gem, you should be good to go. It uses Migrate under the hood, so there’s update support too.
6) Can you share some examples of Trekk in action?
Unfortunately not. We have used the same techniques but different code for other clients. We did use Flatfish during the development of both the Stanford School of Engineering and Stevens Institute of Technology projects though, so you can see the results.
7) What are the plans for Trekk going forward?
First and foremost, we’d like to get universities using it and taking advantage of our work! There are also the typical design and architectural concerns, we want to refine and improve things according to usage. In terms of additional features, we don’t have any major ones on our radar, but users are encouraged to suggest them on our Issues page or better yet code them.
8) Are Drupal Connect planning anymore Drupal distributions in the future?
We’ll see how this one goes! If it’s successful, then I think there’s a good chance you’ll see more.
9) And finally, where can users find out more about Trekk?
We are speaking at most major Drupal camps and of course, there’s our website http://drupalconnect.com/trekk. We have an IRC channel, #trekk. And you can also email us at trekk [at] drupalconnect [dot] com.
Commenting on this Feature Article is closed.
