One of the things the team likes best about Redmine is that it’s open source, and that it’s written in Ruby on Rails. We try to share as much of our code as possible, and while Ruby on Rails isn’t the only language we work in, it does hold a special place in our hearts. All personal preferences aside, there are a ton of more practical things that make Redmine appealing to any type of team.

Redmine makes it easy for clients to track the progress of a project, allowing a single user to create an unlimited number of accounts. For those who prefer agile software planning tools, there’s Backlogs, a Redmine plug-in that simulates Pivotal Tracker. Redmine also has a great wiki feature, allowing you to keep all relevant project information in one easily accessible place. Our project managers love the excellent tags and categories features that help them keep things organized. Redmine also shines on the financial front, costing teams nothing to use.

General Things is currently in the process of upgrading from Redmine 1.2 to 1.4. Highlights of 1.4 include official support for Ruby 1.9 and JRuby, support for multiple SCM repositories per project, and multiselect custom fields. Redmine isn’t for everyone, but we believe that it’s the best option for agile teams that do a lot of work in Ruby on Rails. Redmine is the first tool we’ll be profiling in General Tools, a new series of blog posts covering the applications and tech that we can’t live without here at GT.

Harvard University recently announced that they were going to make their MARC21 metadata available to the public. Harvard Library’s MARC21 data is 10GB in size and is separated into 14 different files. There are 12 million total records spread across 73 libraries. Discovering different types of bibliographic content is something that has Carlo very intrigued. Carlo decided to use this resource to eventually create a front end searchable interface using REST to make it easier to search through the entire catalog of MARC21 data.

MARC is an international standard digital format that consists of a description for the storage of bibliographic content. MARC21 was created when the US, Canadian, and European standards merged together to provide a more unified system of cataloging. Content stored in MARC21 files include formats for authority records, holdings records, classification schedules, community information, and formats for bibliographic records.
MARC21 data is stored in binary linked lists. These linked lists use a sequential access data format which require a parsing script in order to insert the content into a database. Currently, Carlo is using a PHP MARC parser called file_MARC to comb through the MARC21 data from Harvard University’s library.

Bibliographic databases are an expensive and sought after service, but Carlo’s final goal isn’t to monetize his searchable Harvard Library MARC21 database; instead, he plans to release the source code for free on Github. Carlo recognizes this as an opportunity to provide a successful, useful service and to fuel his spirit to unravel some previously undiscovered material. We dream big at GT.

GT developer Ryan V took on the task of implementing Chef and faced a few issues along the way. GT developers are always enthusiastic to adopt new software, but we found that the currently available documentation on Chef was quite unorganized and all over the place. Diligent as ever, he outlined the steps he took to successfully set up Chef. We are now using those outlines to create a comprehensive process description that we hope will assist the other lost souls out there. We begin with:

Setting up an open source chef server

The instructions given in this guide were performed in a development environment with the following features:

Server: We used an Amazon EC2 instance of Ubuntu 12.04. Like most hosted servers, this is a paid service, however you may try a free version of the virtual server on the Amazon web services website.

Host Machine: The installation was performed using a MacBook Air running on the Mac OS X Lion v10.7.3

We started by launching a new EC2 micro instance of Ubuntu 12.04. (Note that you can also do this easily on 10.04, you just need to make the related changes as described below). We then created a new security group and enabled ports 4000, 4040 and 22.

Port 4000 needs to enabled because it’s the port that allows Chef to communicate with other nodes.

Port 4040 needs to be enabled because it communicates with the Chef web-ui.

Port 22 needs to be enabled because it is the standard TCP port for contacting SSH servers.

Follow the steps below to start installing your Chef server

1. Prepare the server to download from the opscode repositoryTo get started, first add the Opscode repository to the server’s apt sources using the code below. This code will only work on an Ubuntu 12.04 server

   echo "deb http://apt.opscode.com/ precise-0.10 main" | sudo tee /etc/apt/sources.list.d/opscode.list

   If you are still using Ubuntu 10.04, use the code shown below and continue to follow the remaining steps

   echo "deb http://apt.opscode.com/ lucid-0.10 main" | sudo tee /etc/apt/sources.list.d/opscode.list

   Now add the GPG key and update the apt index:

   sudo mkdir -p /etc/apt/trusted.gpg.d
   gpg --keyserver keys.gnupg.net --recv-keys 83EF826A
   gpg --export packages@opscode.com | sudo tee /etc/apt/trusted.gpg.d/opscode-keyring.gpg > /dev/null

2. Update Latest Packages on Amazon EC2 Instance
   

With the Opscode repository added, update the existing packages on the installation machine. This ensures that all the libraries that Chef depends on are running on the latest versions.

Run apt-get update to update and retrieve the latest package index

sudo apt-get update

Add in the Opscode keyring. This ensures that your Opscode key is always up to date.

sudo apt-get install opscode-keyring # permanent upgradeable keyring

Now run this to update all existing packages already present on the server

sudo apt-get upgrade

3. Install the Chef server packages Install chef server packages and step through the prompts. When you are prompted to the enter the URL of your Chef server, enter your EC2 public DNS. You will then be prompted to create a password for the Chef user and for the Chef web-ui admin user.

   sudo apt-get install chef chef-server

   
4. Create Chef repository and transfer Chef certificates

   Run this to setup the Chef directory and move validation certificates. The validation certificate is required to connect to the Chef Instance. These will be later copied to the local machine.

   mkdir -p ~/.chef
   sudo cp /etc/chef/validation.pem /etc/chef/webui.pem ~/.chef
   sudo chown -R $USER ~/.chef

5. Configure your knife client on the server

   Knife is the Chef command line management interface that allows users to interact with the Chef server API, local Chef repository interface and other Chef nodes.

   Run the knife configuration command shown below

   knife configure -i

   This command prepares the instance to start communicating with other Chef instances.

   Since the program is now creating a new account, it will prompt for various credentials. Continue to use the default settings for all credentials except for

   Server location: Enter the actual EC2 DNS with port 4000 so it points to Chef.
   Key Location: The program will request this information twice. This information will direct the Chef server to the necessary certification files.

   In the first instance it will request for the admin client’s private key. Point to the key location created in the above step as shown below. This points the Chef configuration file to the web-ui certificate

    [/etc/chef/webui.pem] .chef/webui.pem

   For the second instance, it will request for the validation key. Point to the validation.pem file created in the above step. This will direct the Chef configuration file to the validation certificate.

   [/etc/chef/validation.pem] .chef/validation.pem

6. Create the chef client account to use for your local workstation
   This step sets up a Knife client which allows the user to work from a local computer station

   knife client create my-username -n -a -f /tmp/my-username.pem

   Go to the Chef server that has just been installed by typing http://yourlocation.com:4040.
   Screenshot of Chef server Login Page
   

This tutorial gave you a step by step process description for installing a Chef server on an Ubuntu 12.04 server. We found that this series of steps is the most efficient and clutter-free approach. If you encounter any difficulties, leave a comment below and we’ll definitely get back to you.

The trip totaled 3,597 miles, with stops in Colorado, Arizona, Nevada, and California. Like any road trip, there were highlights and lowlights. Some of the lowlights included rain, snow, and a massive traffic jam at the Hoover Dam. The lowlights weren’t pretty, but the highlights more than made up for them. Scott and Jenny got to see the beauty that is the American Southwest and Pacific Northwest firsthand. French toast everyday of the trip and stops in Las Vegas and San Francisco were also nice.

Driving 3,597 miles is commendable, but it’s not enough to earn the nickname Mad Max. What put Scott’s road warrior resume over the top was that he made the trip two more times, driving back to Indiana to pick up his dog, Moose. Moose now joins Feynman, Madame Wu, and Kansas as the office dogs at GT!

Some of the interesting aspects of Dancing Rabbit include consensus decision-making where every community member must agree on a recommendation before it becomes a rule, “which means it takes forever for a decision to be made,” according to Dan. The ecovillage residents are responsible for building their own homes using organic materials like straw bales and used lumber. The village economy depends on the initiatives taken by members and volunteers with a strong focus on preserving and maintaining the ecological bio-diversity. Dancing Rabbit is home to people from all walks of life including Ruby programmers, earning it the General Things’ stamp of approval.

The site was Fred’s first foray into web development. It was created using Rails 3 and has since been updated to Rails 3.2. MerciboQ! is entirely open source, allowing anyone to contribute to the site’s growth. It is hosted on Heroku and takes advantage of a Heroku AddOn called Cloudmailin to process incoming emails. Sending a MerciboQ! is easy and can be done in three steps:

Step 1: Send an email to the person you wish to thank
Step 2: In the “To:” field of the same email, add “thanks@merciboq.com”
Step 3: Write your thankyou in the body of the email

Once you’ve sent your email, MerciboQ! will then publish your thankyou, create an account and a custom subdomain for you and the person you thanked, and send a confirmation with signup steps to each account. After you’ve setup your account, you can begin tracking the thankyou’s you’ve sent and received. The site is still in its infancy, but Fred has big plans for the future of MerciboQ!, including adding the ability for individuals to associate their thankyou’s with the business they are working at, as well as publishing their MerciboQ!’s to Twitter and Facebook. We’ll be sure to share more updates on Fred’s project as they come, and we’ll continue to spotlight the side projects of our developers as they share them with us!

When General Things (GT) developer Chris Hein isn’t jumping off airplanes or cliffs, he’s searching for new ways to make everyone’s job a tad simpler. His latest discovery is Grape, an API building framework. He shared the wonders of Grape with the GT team during a recent Friday BoF session.

Grape is syntactically based around Sinatra, a Domain Specific Language (DSL) that lets you effortlessly and quickly create web applications in Ruby. Grape and Sinatra share many features, with both being simple to write, and both being mountable rack applications. At this point, you may be wondering (as we all were) why you should use Grape over plain Sinatra.

For starters, Grape makes it easy to release multiple versions, cutting down on cluttered code and duplication. It also makes writing helpers a breeze. Another big reason to work with Grape is its ability to mount multiple files at once. This makes things structurally easier and allows for less duplication, prettier/cleaner code, and better separation. This feature is only available on Grape 0.2.0, but it can be used for any rack application. Grape also encourages you to create self-documenting APIs, letting you write out your methods and parameters so that it’s easier for others to use your APIs.

If you’re interested in using Grape, you can find it here. If you’re already using Grape, or Sinatra, let us know what you think! We also welcome any and all links to Grape tips and tutorials.

• It can mimic an entirely terminal-based IDE
• It can monitor sessions from a remote location
• It allows users to reconnect to terminal sessions if they are on flaky connections such as a mobile hotspot
• It can be used for local and remote pair programming, a working style that GT encourages
• It encourages customization of windows, panes, and colors

Pair programming is of specific interest at GT right now as we try to incorporate it into our workflow. Some GT developers prefer to practice pair programming by having one developer physically code while the other provides the critical headshot view. Pair programming generally results in a “1 + 1 = 3″ productivity gain, as code is cleaner, more thought-out, and has fewer bugs. With tmux, developers can also hold grouped sessions where users interact independently on the same session from remote locations. GT developers are encouraged to adopt a working style most productive for them and our clients, and tmux seems have struck a chord.

GoPro was very satisfied with the brilliant customer service and solutions that GT implemented for them. To learn more about the range of solutions and GoPro’s fantastic customer experience, read the GoPro case study