Several groups asked for the capability to collect information specific to their group on users’ profiles. Some wanted to record big sisters, initiation scroll numbers, or just general hobbies and interests. Alumni asked if we could include information about their spouses and/or children on the site. Since this data varies from group to group, we wanted to allow organizations to pick what sorts of additional questions would be added.

Group administrators now have an additional link on the admin screen for the site. Click on “Custom Profile Questions” to edit the questions asked of your members. If you’ve used the Respondable feature you’ll be right at home here, as the question types and formatting options are the same.

Once you’ve added additional questions, direct your users to their profile page at https://profile.gozuus.com/me and tell them to click on the menu link for your group’s site. (Send out an e-mail to your GoZuus list!) They’ll now see the additional questions and can respond to them there.

As members fill in this information, it will begin to appear on their individual profile pages. All members of your group will be able to look up this additional information about other users. (Don’t worry: if a member belongs to multiple groups, members of those other groups can’t see profile information that is specific to your organization.)

We’ll be adding options for private questions, as well as allowing administrators to export this data very soon. If you have ideas or questions, or want to vote to bump either of these ideas up on the priority list, please let us know in the comments!

I started off by making a list of what we didn’t like:

1. Profile editor was under the shell of a group site
   When a member belongs to more than one site, their profile is actually shared. Having the editor under the shell of any one group site make this unclear.
2. Cumbersome to edit data
   Each line of information required a click to edit, a click to save, and two server requests. This could be much simpler.
3. No good place for group-specific profile info
   We’d like to allow each group to add their own additional profile questions, but there was no good place to add these questions.
4. Parent contact information was buried
   Many users didn’t know this existed, and therefore didn’t fill it out.
5. Illogical parent contact separation
   Parent e-mail addresses had their own separate page, but parent mailing addresses were supposed to be entered on your profile. Many users also only provided a home address, assuming we would know this was their parent’s address too.
6. Inconvenient e-mail update flow
   To prevent users from missing messages, we needed to ensure that you could never remove a verified primary e-mail address without providing a new one in its place.

Many of these were minor issues, but we knew we could do better. We started off with a brand new profile editing site at https://profile.gozuus.com. We gave it a different look, so that users would know it was external to their GoZuus group site. We made it faster to edit, cleanly separated parent contact information onto a new page, and provided a separate profile page for each group to which you belong. Here’s what it looks like now:

Watch for more enhancements to this feature and the user directory in coming months! As always, if you have suggestions please let us know!

This didn’t sound too difficult, so I decided to tackle the idea one afternoon last week. You’ll now see two new options: “anonymous and hidden” and “anonymous, but publish the answers”. Choosing either option will remove names from all responses, and the second choice will allow all members to see what others have said. Careful though – once you mark a respondable as anonymous, you cannot change it back!

While I was making updates, I also added an option to reassign the owner of a respondable. This brings the permissions system more in line with that of e-mail lists and statistics. By reassigning a respondable, you give access to a different member for viewing responses. You can even reassign a respondable to a member who would otherwise not have permission to create one.

Now that GoZuus is launched, we hope to make small improvements like this on a weekly basis. If you’ve got an idea for a quick change that would make your life easier, please let us know! Tweet your idea to @gozuus, or post it on our Facebook page!

I took Bryan’s rake task and built upon it to help prevent this sort of issue. Here’s the goals:

• All code deployed to either the staging or production environments must be in GitHub. Using Capistrano for deployment helps enforce this, in that no code from a local repository can ever get deployed to the server.
• All changes start by branching off the current production head. This ensures we always have a stable place to start working, regardless of whether its for a quick bugfix or a month-long feature update.
• Any developer can deploy their current development branch to staging at any time. Remember, their development branch is based off of something that was a stable production release at one time. However, updates may have been made to production since then that are not included in their development branch. We consider this to be okay.
• Any developer can merge their current development branch back into production. However, their merge must be a direct fast-forward (which guarantees no conflicts). If changes have been committed to production since their branch was created, they must first rebase their branch to start from the current production head.
• All code merged into production is ready to be deployed at any time. Sounds obvious, but our first strategy failed on this because commits made to staging weren’t always ready to go to production in that order.
• Lastly, all this needs to be automatic, safe, and simple.

In our solution, we treat production as a real branch and merge code into it. This prevents commits from being lost by rewriting history. However, we borrowed the idea of creating staging as a branch, but treating it like a tag. I like this because it lets any developer tear down staging to use themselves at any time. By not making commits to staging, I never have to worry about my buggy code affecting someone else’s testing. (Or more realistically, someone else’s buggy code screwing up my testing.)

So, without further ado, here’s the rake tasks:

class GitCommands

  # Shows a diff of the current production and staging branches
  # (ie, what would change if staging was deployed to production)
  def self.diff_staging
    `git fetch`
    puts `git diff origin/production origin/staging`
  end

  # Pushes the specified branch to the remote origin, then
  # resets the staging branch to be a copy of that branch.
  def self.push_staging(branch_name)
    verify_working_directory_clean
    `git push origin #{branch_name}`
    `git fetch`
    `git branch -f staging origin/staging`
    `git checkout staging`
    `git reset --hard origin/#{branch_name}`
    `git push -f origin staging`
    `git checkout #{branch_name}`
    `git branch -D staging`

    `cap deploy`

    unless is_fast_forward_of_production(branch_name)
      puts("nnWARNING: NON-FAST-FORWARD!n"+
        "The production branch has been updated since this branchn"+
        "was created (or you've made more than 100 commits). Stagingn"+
        "has been updated, but you'll need to run the followingn"+
        "before attempting to push to production.nn"+
        "  git rebase -i origin/productionn"+
        "  git push -f origin #{branch_name}nn"+
        "You may want to do this now before testing on staging.nn"
      )
    end
  end

  # Pushes the specified branch to the remote origin, then
  # merges its changes into the production branch.
  def self.push_production(branch_name)
    verify_working_directory_clean
    `git push origin #{branch_name}`
    `git fetch`

    verify_fast_forward_of_production(branch_name)

    # Update master to be the previous production
    `git checkout master`
    `git reset --hard origin/production`
    `git push origin master`

    # Merge the current branch into production
    `git branch -f production origin/production`
    `git checkout production`
    `git merge #{branch_name}`
    `git push origin production`
    `git checkout #{branch_name}`
    `git branch -D production`

    puts("nnYour branch has been merged into production, but hasn"+
      "NOT YET been deployed.  Call the appropriate capistranon"+
      "tasks to deploy code, migrate the database, then restartn"+
      "passenger to make your changes live.nn"+
      "  cap production deploy:updaten"+
      "  cap production deploy:migraten"+
      "  cap production deploy:restartnn"
    )
  end

  # Creates a new branch using the current production branch
  # as a base.
  def self.create_branch(branch_name)
    verify_working_directory_clean

    `git fetch`
    `git branch -f production origin/production`
    `git checkout production`
    `git branch #{branch_name}`
    `git checkout #{branch_name}`
    `git push origin #{branch_name}`
  end

  # Creates a new local branch tracking a remote branch
  def self.track_branch(branch_name)
    verify_working_directory_clean

    `git fetch`
    `git branch -f #{branch_name} origin/#{branch_name}`
    `git checkout #{branch_name}`
  end

  # Creates a new branch using the current production branch
  # as a base.
  def self.destroy_branch(branch_name)
    verify_working_directory_clean

    `git fetch`
    `git checkout master`
    `git branch -D #{branch_name}`
    `git push origin :#{branch_name}`
  end

  # Determines the name of the current working branch.
  def self.get_branch_name
    branch = `git status`.scan(/A# On branch (.+)$/)
    raise "Could not determine which branch to use.  Perhaps use BRANCH=?" if branch.blank? || branch.first.blank? || branch.first.first.blank?
    return branch.first.first
  end

protected

  # Ensures that there are no pending changes in the working directory.
  # This was edited to allow untracked (and unignored) files, but that
  # may need to be removed for 100% functionality.
  def self.verify_working_directory_clean
    output = `git status`
    return if output =~ /working directory clean/ || output =~ /nothing added to commit but untracked files present/
    raise "Must have clean working directory"
  end

  # Verifies that the specified branch is a direct fast-forward of
  # the production branch.  This ensures that merges will be smooth
  # and conflict-free when running the git:push:production task.
  def self.verify_fast_forward_of_production(branch_name)
    unless is_fast_forward_of_production(branch_name)
      raise(
        "Branch #{branch_name} is not a fast-forward of the production branchn"+
        "(or there's more than 100 commits since the branch).n"+
        "Run:   "git rebase -i origin/production" and resolve all conflicts,n"+
        "then:  "git push -f origin #{branch_name}" to fix this."
      )
    end
    return
  end

  # Determines if the specified branch is a direct fast-forward of
  # the production branch.
  def self.is_fast_forward_of_production(branch_name)
    production_last_hex = `git log -1 origin/production`.scan(/Acommit ([da-f]{40})$/).first.first
    branch_log = `git log -100 --pretty=oneline #{branch_name}`.scan(/^[da-f]{40}/)
    return branch_log.include?(production_last_hex)
  end

end

namespace :git do

  namespace :push do

    desc "Push the current branch to origin/staging for testing"
    task :staging do
      branch_name = ENV['BRANCH'] || GitCommands.get_branch_name
      GitCommands.push_staging(branch_name)
    end

    desc "Safely merge the current branch back into origin/production"
    task :production do # => ['diff:staging'] do
      branch_name = ENV['BRANCH'] || GitCommands.get_branch_name
      GitCommands.push_production(branch_name)
    end

  end

  desc "Show the differences between the origin/staging branch and the origin/production branch"
  task :diff do
    GitCommands.diff_staging
  end

  namespace :branch do

    desc "Create a branch for a feature or bug fix. Specify BRANCH=name"
    task :create do
      branch_name = ENV['BRANCH']
      raise "You must specify a branch name using BRANCH=name" if branch_name.blank?
      GitCommands.create_branch(branch_name)
    end

    desc "Creates a local branch tracking an already-created remote branch.  Specify BRANCH=name"
    task :track do
      branch_name = ENV['BRANCH']
      raise "You must specify a branch name using BRANCH=name" if branch_name.blank?
      GitCommands.track_branch(branch_name)
    end

    desc "Removes a remote branch from the origin.  Specify BRANCH=name"
    task :destroy do
      branch_name = ENV['BRANCH']
      raise "You must specify a branch name using BRANCH=name" if branch_name.blank?
      GitCommands.destroy_branch(branch_name)
    end

  end

end

We’ve been using this for the past several weeks and it’s been working great. So, did we do any better? Anyone see any flaws or have any other ideas?

The first thing you’ll notice is that we’re now including Attendance, Balance, and Work Hour tracking by default. Limitations in the Points system prevented it from being used for such a wide array of purposes, but now you can access everything from one standardized interface. We made several changes to make this possible.

Easier Updates
With the original system, entries could only be made by typing in values for each individual. If you needed to assign one work hour to each member in the chapter, the ‘1′ key on your keyboard was bound to wear out quickly. The new assignment page provides options to streamline this data entry process.

First, you can choose to either update (add/subtract) or replace (overwrite) values. Then, select which members are visible and enter a default value for each new record.

If your data is already in a spreadsheet, updates are even faster. You can now upload a CSV file, or even paste data from Microsoft® Excel® into the site. GoZuus will automatically identify which columns contain a name or e-mail address, and will prompt you to confirm the data before saving. Header and summary rows are automatically ignored, and you can even export from QuickBooks® and paste directly into GoZuus!

Currency and Decimal Support
One frequent request was to provide an interface for listing account balances. We’ve added support for currency symbols and decimal points to make this possible. All records are now stored with decimal information, so you can also assign 1.5 hours for tasks.

It is worth mentioning that each statistic now has detailed permissions as well. You can choose which groups of members can assign updates as well as who can see reports for other members. For example, work hour reports might be visible to everyone in the group, while each member can only see their own account balance.

Attendance and Tags
Several groups expressed interest in tracking attendance on the site, and we’re pleased to now support that as well. The default Attendance statistic has tags for “Present”, “Excused” and “Unexcused” absences, and “Tardy” records. We’re planning to integrate excuses into the calendar shortly, but for now it should be plenty easy to call roll right from the assignment page on your GoZuus site.

Better Reports
Lastly, what good is all this data if you can’t generate meaningful reports? Administrators (or all members if permission is granted) can view reports by user, or by update or event. You can use this to print a list of all current account balances, or see the attendance records from any given meeting. Reports can be reset at the beginning of each semester if desired, or can track a running lifetime total.

We’re thrilled to be offering this new functionality, and would like to thank our beta groups for providing great feedback to help drive this development. We hope you enjoy these new features, and can’t want to see what other great uses you come up with for them!

There’s plenty of resources online discussing how easy it is to use the Ruby Icalendar library.  However, just following those directions didn’t produce quite the results I was looking for when exporting multi-day events.  Using the directions from the previous links, Apple’s iCal app displayed every event as ending one day early.  And Google Calendar put “(12:00am?)” in front of the titles.  Not exactly seamless integration.  A quick Google search didn’t turn up anything useful, so hopefully this solution will save someone else some time.

The first one is easy.  If you dive into RFC2445, section 4.8.2.2 states that the DTEND parameter “defines the date and time by which the event ends.”  That’s an up-to-but-not-including statement.  If an event starts Feb 2 and ends Feb 5, then that means the event is over by Feb 5, and it displays as occupying only Feb 2, 3, and 4.  This is different than our model, where we define the end date to be included.  (That made more sense to me – most users who enter “Feb 2-5″ are describing a four day event.)  The solution here is just to use event.end_on.advance(:days => 1) to push it one day forward.

The second one is a little more difficult.  Google’s iCal parser interprets all DTSTART and DTEND values as times unless specifically told otherwise.  If you look at the output from the Icalendar library, it lists dates and date/times as:

    DTSTART:20090205
    DTSTART:20090205T083000

That’s valid, but according to the RFC you can add an additional parameter in there to specify what type of value you’re providing.  This looks like:

    DTSTART;VALUE=DATE:20090205
    DTSTART;VALUE=DATE-TIME:20090205T083000

I couldn’t find any documentation for how to do this with the Icalendar library, so I began digging into the source for Icalendar’s component.rb.  Turns out there’s a function called print_parameters(val) that is called during generation, and that it prints these pairs from hash called val.ical_params.  So if you assign event.start.ical_params = {'VALUE' => 'DATE'}, the Icalendar library will add in these additional descriptors.  Seems to be undocumented, but it works for me.

Note that since ical_params is a parameter of the object itself, you can only assign this hash after you’ve assigned the object itself.  Also, it didn’t seem to work for me when the value I had assigned was a String.  It did work when I assigned a Date or DateTime object directly.

All in all, our Event#to_ical looks like this:

def to_ical
  ical = Icalendar::Event.new
  if self.multi_day? || self.all_day?
    ical.start = self.start_on
    ical.start.ical_params = {'VALUE' => 'DATE'}
  else
    ical.start = self.start_at
    ical.start.ical_params = {'VALUE' => 'DATE-TIME'}
  end
  if self.multi_day?
    ical.end = self.end_on.advance(:days => 1)
    ical.end.ical_params = {'VALUE' => 'DATE'}
  end
  ical.summary = self.name
  ical.description = self.details
  ical.uid = "#{self.id}@gozuus"
  ical.created = self.created_at.utc
  ical.last_modified = self.updated_at.utc
  return ical
end

For completeness, here’s the output portion of our controller action:

format.ics do
  @ical = Icalendar::Calendar.new
  @events.each { |event| @ical.add event.to_ical }
  @ical.publish
  render :text => @ical.to_ical, :layout => false
end