GSoC：开源活动管理器组织者仪表板

在今年的谷歌夏季代码项目 (GSoC) 的过去 4 个月里，这是一个为开源软件项目编写代码而向学生开发者提供津贴的全球项目，克里斯蒂安·布鲁克迈尔与其他学生和导师合作，为开源活动管理器 (OSEM) 编写了一个仪表盘。在这个由三篇文章组成的系列中，克里斯蒂安将向您讲述他的项目以及他从这次经历中学到的东西。

大家好，我叫克里斯蒂安，目前是德国纽伦堡信息系统和管理专业的三年级本科生。在大学期间，我对开发 Web 应用程序已经很感兴趣，并获得了初步经验。在 openSUSE 参加谷歌夏季代码项目对我来说是一个提高我的知识并与其他优秀的开发者合作的好机会。现在只剩下两周时间了，现在是总结我迄今为止的成就和收获的绝佳时机。

关于开源活动管理器 (OSEM)

使用 OSEM，可以轻松设置和管理所有组织一次成功的开源会议的任务。作为会议组织者，您可以让人们注册您的活动，发起论文征集，并从用户的提案中创建一个有趣的日程安排。作为参与者，您可以在一个中心位置获取有关活动的所有信息。

OSEM 被 openSUSE、owncloud 和其他自由和开源项目用于举办他们的活动，它是用 Ruby on Rails 编写的，这是一个开源 Web 应用程序框架。openSUSE 已将 OSEM 作为免费软件发布，采用 MIT 许可。您可以运行、复制、分发、研究、更改和改进它。源代码和开发者在 github 上。

我的项目：组织者仪表盘

我的 OSEM GSoC 项目是关于实现一个组织者仪表盘，其目标是让会议组织者能够一览有关其会议的所有相关信息。简单地说，就是让组织者了解他们的会议进展如何。

仪表盘上应该显示什么？

对我和我的导师来说，首先要做的是确定哪些信息对会议组织者最重要，因此应该在新的仪表盘上显示。我研究了哪些数据可用，哪些竞争应用程序显示了什么，最终与我的导师一起决定了

• 注册 - 将参加我的会议的人员

• 提交 - 提交到我的论文征集的内容

• 程序 - 我从提交中接受的内容。

选择图表库

正如您所能想象的，为了很好地展示这些信息，我们需要一个图表库！所以我的第一个任务是评估各种图表库，并决定哪一个最适合我们的目的。最终，我们决定使用 Chart.js，因为它既简单又强大。

收集相关数据并展示

有多少人将参加？

要显示的最重要信息是注册人数随时间的变化。我们决定一周的粒度就足够了。为了获取此数据，我在会议模型中实现了一个方法。

def get_registrations_per_week
  result = []
  reg = registrations.group(:week).count
  result = calculate_items_per_week(21, 6, reg)
  result
end

我们查询数据库中的所有注册信息，按周分组，然后计数。正如您所看到的：week 是一个数据库列，这对于使此查询与数据库无关是必要的。然后我们继续累加每周的注册人数，并在左侧填充（以防您在第一周没有注册信息）。

def calculate_items_per_week(start_week, weeks, hash)
  # Insert zero if key not in hash
  (start_week..(start_week + weeks)).each do |key|
    if !hash[key]
      hash[key] = 0
    end
  end
  result = hash.sort.to_h
  result = hash.values

  # Cumulate the values
  sum = 0
  result.map { |x| sum += x }
end

所以最后，如果在第 23 周有 4 个注册信息，在第 25 周有 6 个注册信息，在第 26 周有 2 个注册信息，而我的注册周期从第 21 周开始，结果将是

[0, 0, 4, 4, 10, 13]

这是一个很好的数据集，可以在折线图中显示！

人们提交了什么内容到我的论文征集？

对于论文征集提交，我们不仅想显示进度，还想显示不同状态的进度（例如，已提交、已接受、已确认）。结果，这并不像最初想象的那么容易！原因是，正如您所能想象的，事件状态会发生变化，因此我们不能在渲染时只进行简单的数据库查询。相反，我们必须每周拍摄一次事件状态分布的快照，并将其保存到我们的数据库中（就像“历史数据”一样）。幸运的是，我们使用 papertrail gem 来跟踪对象更改。因此，我能够计算过去会议的事件状态分布。:) 为了获得某种状态的提案数量，我实现了以下方法..

def get_submissions_data
  result = {}
  result = get_events_per_week_by_state

  start_week = call_for_papers.start_week
  end_week = end_date.strftime('%W').to_i
  weeks = weeks(start_week, end_week)

  result.each do |state, values|
    if state == 'Submitted'
      result['Submitted'] = pad_array_left_cumulative(start_week, values)
    else
      result[state] = pad_array_left_not_cumulative(start_week, values)
    end
  end
  result['Weeks'] =  weeks > 0 ? (1..weeks).to_a : 0
  result
end

首先，我获取一个包含每周每个状态的提交信息的哈希值。为此，我实现了辅助方法

get_events_per_week_by_state

它从数据库中选择值并返回如下所示的结果

{ 'Submitted' => {22 => 1, 24 => 2}, 'Confirmed' => {23 => 1, 25 => 2}, 'Unconfirmed' => {22 => 1, 24 => 2} }

我们只考虑在论文征集开始和会议结束之间提交的提案！下一步与注册人数随时间的变化类似，但有一个区别：我们只想累加已提交提案的值，而不需要累加其他状态的值。让我解释一下。要获得已提交的提案，我们可以进行一个简单的数据库查询（它与注册人数随时间的变化非常相似），但对于其他状态，我们必须在每周结束时拍摄一个快照！因此，没有必要累加这些值！最后，我将周数（x 轴）添加到结果哈希中。上述示例的结果将如下所示

{ 'Submitted' => [0, 1, 1, 3, 3], 'Confirmed' => [0, 0. 1, 0, 2], 'Unconfirmed' => [0, 1, 0, 2, 0], 'Weeks' => [1, 2, 3, 4, 5] }

我的程序会是什么样子？

另一个对会议组织者来说非常重要的信息是程序会是什么样子。这包括例如，我为某个轨道（例如，最终用户、业务）有多少个活动，难度级别或特殊类型（例如，简短演讲、研讨会）。这些信息对组织者至关重要，因为这样他们才能看到他们是否为某个轨道有太少或太多的活动。幸运的是，Chart.js 不仅支持折线图，还支持饼图，这是显示这些信息的首选模式。下图显示了此功能的显示效果

为了获得轨道分布，我实现了例如以下方法

def tracks_distribution(state = nil)
  if state
    tracks_grouped = events.where('state = ?', state).group(:track_id)
  else
    tracks_grouped = events.group(:track_id)
  end
  calculate_track_distribution_hash(tracks_grouped, tracks_counted)
end

正如上图所示，此功能有两个不同的选项卡。第一个选项卡显示所有提交的提案的会议程序，无论它们处于什么状态（例如，已提交或已拒绝），第二个选项卡显示程序仅针对已确认的提案会是什么样子！为了满足此要求，我们的函数是通用的：如果您只是调用

tracks_distribution

您将获得所有提案的信息，如果您调用

tracks_distribution(:confirmed)

（或任何其他状态），您将仅获得此状态的信息。

def calculate_track_distribution_hash(tracks_grouped, tracks_counter)
  result = {}
  tracks_grouped.each do |event|
    if event.track
      result[event.track.name] = {
        'value' => tracks_counter[event.track_id],
        'color' => event.track.color
      }
    end
  end
 result
end

该函数

calculate_track_distribution_hash

然后简单地将每个轨道分配给提案数量和相关的十六进制颜色。结果将如下所示

{ 'Workshop' => { 'value' => 10, 'color' => '#00FF00'}

展示，而不是讲述

最后，如果您将所有这些结合在一起，我们最终为会议组织者提供了一个不错的仪表盘。

剩余的 GSoC 时间还有什么？

由于我的 GSoC 同事们在过去几周里实现的新功能，管理界面变得非常复杂和混乱。正如您所能想象的，这非常糟糕，因为界面应该简单、易于理解。否则，组织者将不会使用我们出色的新功能。重新考虑和重构管理界面和菜单将是我在剩余的几周里的任务。

我希望您喜欢这篇文章，期待您在下方发表评论。别忘了查看我系列中的其他文章

• OSEM：会议仪表盘

• OSEM：目标与活动

• GSoC：我学到的东西