DIY: How We Made a Live Schedule for Codefest X

    At the end of March in Novosibirsk, the 10th anniversary CodeFest died . Like, probably, any conference, CodeFestX left a lot of different impressions for the participants from “my legs will no longer be here” to “how to buy a lifetime subscription?”. I will not describe how it was, there are already reviews and, I think, will still appear. I want to share the story of how we launched an alternative version for the Codefest schedule ( watch better from a mobile phone ): from the idea to the result.



    Idea


    I have been attending Codefest since 2010, and this year was my 9th conference. For me, Codefest is a tradition, and this time I wanted to do something useful. Before the event, reading the conference chat, I realized that the schedule is something that can definitely be improved. Codefest is an eventful event that everyone would like to get the most out of, so I decided to help build an alternative custom schedule.

    The objectives were as follows:

    • For visitors - to give the opportunity to get more relevant information about current events and form their own feed of interests. Plus, all conference visitors had the opportunity to come to our booth and file down any missing feature or fix a bug;
    • For Codefest , this is an additional channel for distributing a “popular” program;
    • For us, as a company , this, of course, is an additional plus in the Employer brand.




    The concept of a “pumped-over” schedule came to the organizers of Codefest. I shared the idea at Wrike and quickly found like-minded people willing to connect. We started with research, looked at conference sites and mobile applications. In general, we launched the usual grocery process at Wrike.

    As a result of working out the backlog, we determined that the necessary functionality is needed like this:

    • The main conference schedule with the ability to filter reports and search;
    • Favorites and notifications about the approach of selected events;
    • A popular program with the same functionality as the main one, as well as the opportunity for partners and activists to add events to this program.

    There were lower priority tasks:

    • Discussions on the report so that authorized users can exchange opinions and discuss;
    • Likes and popular rating reports;
    • Map, as CodeFest is great and navigation is very important.

    There were still tasks with the third priority, where we still have a bunch of spaceships buried, but I believe that their time will come.

    Implementation


    We decided to take what we use in the development of our product as a stack for the project, to give an opportunity to see how the frontend is built in Wrike. We are writing to Dart ( and have already told why: here and here ) and FAR for big web-projects, such as ours, there is only Angular ( that's 5 minutes of inspiration from bunopus ). The repository of our project can be found here github.com/wrike/codefestx .

    In our Angular app, we added Redux . There are several implementations for Dart: we took Redux.dart and Redux Epicsfor effects. In our project, the code related to Redux is located here github.com/wrike/codefestx/tree/master/lib/src/redux .

    To work with immutable state, we took the built_value and built_collection packages , which simplify the work well. For example, we create a class for the state of our application - CodefestState , and the packages generate a builder .
    A simple trick is used to communicate Angular and Redux ( in the main component - github.com/wrike/codefestx/blob/master/lib/app_component.dart ):


    And we bind them together through the standard dart Stream : That is, when you create an action in the manager ( they are all here ), it gets into the Redux repository. It is being processed and the state is changing, which causes a cycle of the Angular Change Detection. We made 2 mechanisms for sending notifications: for notifications of the occurrence of events, because this is important, integrated with PushWoosh and received a system push ( unfortunately without support for browsers on iOS ). For less critical events, for example, the release of a new version, a socket was raised, and socket_io_client was used on the client .

    _dispatcher.onAction.listen((action) => _store.dispatch(action)),
    _store.onChange.listen((_) => _zone.run(_cdr.markForCheck)),






    In general, the structure of the application is simple and, in my opinion, understandable. If you have questions, we can discuss specific solutions in the comments or on github.

    Infrastructure


    In the modern world, to upload a JS file for general use, k8s is indispensable. But seriously, one of the features of our service is its revision right at the conference itself ( which several Dartizans took advantage of among visitors and no, they are not from Wrike :) ).



    Therefore, we decided to make an honest CI. We looked at the integration opportunities that GitHub has and found Google Cloud Build there : since we use Google products, then we should not leave this track. Integration works like this: any commit to the repository calls the cloudbuild.yaml assembly . We went along the path that we are collecting a Docker container with a ready-made application ( there is a template for a dart -hub.docker.com/r/google/dart ), and then we launch it in k8s so that we can roll back releases, scale and provide for other hypothetical situations. From what was not enough out of the box, it was the ability to do different behavior depending on the branch where we are committing, that is, for the master to build and deploy to the battle, and for the remaining branches, the minimum steps should be performed without k8s. There is an active discussion of this topic here , and we took advantage of the solution from this discussion. CI worked perfectly and never failed.

    A spoon of tar


    In addition to our successes, of course, there is something that could be done differently. For example, do not force people to log in when voting for reports - some do not like this ( especially in short-term services ). As a result, we didn’t get very many “likes” for the reports, but, nevertheless, congratulated the speaker champions.



    We also in the courage of web development forgot about the strict limitations of iOS, and that there is no way to do push for web . It turned out that almost half of the users of our service were with the iPhone. Unfortunately, we were not able to send them a notice.
    And what else upset the team, as I already mentioned, - we did not manage to do all our plans. Some of the functionality was rolled out right at the conference, and some still live in the backlog.

    results


    Thanks to the organizers that the link to the schedule was added to the memo of the conference participant. During the conference, more than 1100 users used the service. To the main program of ~ 120 events, we added another ~ 50 "folk". Approximately 75% of the sessions were on mobile devices, we sent more than 500 push notifications, issued 3 releases during the conference itself, and received a lot of pleasure from the process and the result.



    It was a great experience, and we will continue to develop the project, at least for internal events and Wrike conferences. If you have been to Codefest and used our schedule, we welcome your feedback in the comments.

    Also popular now: