3月底，在新西伯利亚，
CodeFest成立10周年了。 就像在任何会议上一样，CodeFestX给与会者留下了很多不同的印象，从“我的腿不再在这里”到“如何购买终身订阅？”。 我不会描述它的状态，
已经有评论了，我认为仍然会出现。 我想分享一下我们如何
为Codefest时间表推出
替代版本 （
从 手机 观看效果更好 ）的故事：从构思到结果。
主意
自2010年以来，我一直参加Codefest，而今年是我的第9次会议。 对我而言，Codefest是一种传统，这次我想做些有用的事情。 活动开始前，阅读会议聊天记录，我意识到日程安排肯定可以改进。 Codefest是一个举足轻重的活动，每个人都希望从中得到最大的收获，因此我决定帮助构建替代的自定义时间表。
目标如下：
- 对于访客 -提供机会获取有关时事的更多相关信息并形成自己的兴趣源。 此外，所有会议访问者都有机会来我们的展位并提出任何缺失的功能或修复错误；
- 对于Codefest而言 ，这是分发“流行”程序的附加渠道。
- 对于我们公司而言 ，这当然是Employer品牌的附加优势。
Codefest的组织者想到了“抽空”时间表的概念。 我在Wrike上分享了这个想法，并很快找到志趣相投的人愿意联系。 我们从研究开始，着眼于会议现场和移动应用程序。 总的来说，我们在Wrike启动了通常的
杂货流程 。
作为解决积压的结果，我们确定需要必要的功能，如下所示：
- 具有过滤报告和搜索功能的主要会议时间表；
- 有关选定事件方法的收藏夹和通知；
- 一种流行的程序，具有与主要程序相同的功能，并且为合作伙伴和活动家提供向该程序添加事件的机会。
有较低优先级的任务：
- 讨论报告，以便授权用户可以交换意见和讨论；
- 喜欢和受欢迎的评级报告；
- 地图，为 CodeFest很棒，导航非常重要。
仍然有第三优先任务，我们仍然埋有一堆宇宙飞船，但我相信他们的时代将会到来。
实作
我们决定将在产品开发中使用的产品作为项目的堆栈，以便有机会了解如何在Wrike中构建前端。 我们在
Dart上进行了编写（
并且已经告诉了原因： 在这里和这里 ），目前对于像我们这样的大型Web项目，只有Angular（
这是从bunopus那里得到5分钟的启发 ）。 我们项目的存储库可以在
github.com/wrike/codefestx中找到。
在我们的Angular应用中，我们添加了
Redux 。 Dart有几种实现方式：我们使用
Redux.dart和
Redux Epics作为效果。 在我们的项目中，与Redux相关的代码位于
github.com/wrike/codefestx/tree/master/lib/src/redux 。
为了处理
不可变状态，我们采用了
built_value和
built_collection包 ，它们简化了工作。 例如，我们为应用程序的状态
CodefestState创建一个类，然后这些包生成一个
builder 。
一个简单的技巧用于传达Angular和Redux（
在主要组件中-github.com/wrike/codefestx/blob/master/lib/app_component.dart ）：
我们通过标准gart
Stream将它们绑定在一起：
_dispatcher.onAction.listen((action) => _store.dispatch(action)),
_store.onChange.listen((_) => _zone.run(_cdr.markForCheck)),
也就是说，当您在管理器中创建操作时（
它们都在此处 ），该操作将进入Redux存储库。 它正在被处理并且状态正在改变，这导致“角度变化检测”的周期。
我们制定了两种发送通知的机制：用于事件发生的通知，因为 这很重要，与
PushWoosh集成并收到系统推送（
不幸的是，不支持iOS上的浏览器 ）。 对于不太重要的事件，例如，发布了新版本，提出了一个套接字，并在客户端上使用了
socket_io_client 。
总的来说，应用程序的结构很简单，我认为是可以理解的。 如果您有任何疑问，我们可以在评论中或在github上讨论特定的解决方案。
基础设施
在现代世界中，要上传通用的JS文件，
k8s是必不可少的。 但是，很重要的是，我们服务的功能之一是在会议本身上进行了修订（
几个Dartizans在参观者中利用了这个机会，不，他们不是来自Wrike的：） 。
因此，我们决定制作一个诚实的CI。 我们查看了
GitHub所具有的集成机会，并在
那里找到了
Google Cloud Build ：由于我们使用Google产品，因此我们不应该离开这个轨道。 集成的工作方式如下：对存储库的任何提交都将调用
cloudbuild.yaml程序集。 我们沿着将Docker容器与现成的应用程序组装在一起的道路（
有一个用于dart的集线器模板-hub.docker.com/r/google/dart ），然后我们在k8s中启动它，以便可以回滚发布，扩展并提供其他假设情况。 开箱即用的不足之处在于，它能够根据我们提交的分支做出不同的行为，即对于主控人员而言，它可以构建并部署到战斗中，而对于其余的分支，应该在没有k8的情况下执行最少的步骤。 这里对此主题进行了积极的讨论，而我们利用了此讨论中的解决方案。 CI运行完美，从未失败。
美中不足
当然，除了我们的成功之外，还有一些事情可以做的不同。 例如，在对报告进行投票时，不要强迫人们登录-有些人不喜欢这样做（
尤其是在短期服务中 ）。 结果，我们的报告没有得到很多“赞”，但是，尽管如此，演讲嘉宾还是获得了祝贺。
我们还以勇于进行Web开发的方式忘记了iOS的严格限制，并且
没有办法进行Web推送 。 事实证明，我们服务的几乎一半用户都使用iPhone。 很遗憾，我们无法向他们发送通知。
正如我已经提到的，还有什么使团队感到不安-我们没有设法完成所有计划。 一些功能已在会议上推出，而某些功能仍存在于积压中。
结果
感谢组织者，会议日程的链接已添加到会议参与者的备忘录中。 会议期间，有1100多名用户使用了该服务。 在约120个事件的主程序中，我们添加了另外约50个“民间”。 大约75％的会议是在移动设备上进行的，我们在会议期间发送了500多个推送通知，发布了3个版本，并从过程和结果中获得了很多乐趣。
这是一次很棒的经历，我们将继续开发该项目，至少在内部活动和Wrike会议上。 如果您去过Codefest并使用了我们的日程安排，我们欢迎您在评论中提供反馈。