Kickoff: Development updates from the product development team
You might have wondered why we’ve never really written any development blogs, and the only honest answer is: time (or more accurately, the lack of it). The still growing development team of now 8 people have their hands full with adding features, improvements and maintaining any of our 9 projects.
Wait what? 9 projects? I thought you where just selling tickets on the blockchain?
There is way more to it than you think! It’s one of the reasons why we think it’s time we start with recurring development updates, but more importantly: we just owe you these. In this first development blog we’ll kick-off with a short summary of our current state and projects, our workflow, and why there is so much more to building a ticketing service & protocol than you might expect.
Note: these development blogs only includes the work the development team is focussing on, which is not a complete representation of the whole company’s focus. They will feature development on GUTS Tickets as well as the GET Protocol.
Our current active development projects, apps, tooling & contracts
Here’s an overview of our currently active projects, their internal names and the codebase used to develop them. This list does not include tooling, deployment scripts, deprecated projects and internally used projects:
- Entrails: Our global API (Python & Django).
- Shrooms: Contracts for GET Protocol (Solidity & Truffle, soon to be open-source).
- Viscera: Consumer events & tickets frontend (Ember JS).
- Vuejones: Event organiser dashboard app (Vue JS).
- Couché: Our (new) native ticket-wallet app (React Native).
- Sphincter: Our (new) high-performance queue API (Go).
- Vuescera: Our (new) high-performance queue frontend (Vue JS).
- Derrière: Main website www.guts.tickets (Vue JS, Nuxt & Node).
- Guts Scanner: Our badly named native app to scan tickets at events (a loose combination of React Native and HTML & JS, soon to be completely rewritten in React Native).
Do not ask us the secret formula that names our projects: it’s a secret!
Even without having a lot of technical knowledge, you’ll hopefully now already have a better understanding of the complexity and the amount of projects the development team is working on every day. But since this is just our first development blog, let’s start with a short recap of how we ended up here.
Development in 2017 in 3 minutes
Last year we mostly worked on Viscera, Entrails, Cojones (Event dashboard which is now deprecated and rewritten to Vuejones) and a ‘simple’ version of our Solidity contracts to make it possible to actually set-up events and sell our smart-tickets (called Shrooms in case you’re wondering). If you know what GUTS Tickets is currently doing, you’ve already used the front-end parts of these apps. If not, take a look at our sandbox.
The basics of these apps works perfectly for ‘small’ events, but for our first three big pilots for Jochem Myjer, we needed something that could remain stable and enjoyable while tens of thousands of ticket-hungry fans try to actually get their hands on a ticket: behold Constipation (currently being redesigned/written into Vuescera & Sphincter). We developed a queue-app which hands out invites to buy a ticket in an honest and easy way, while making sure our Entrails API doesn’t get flooded by too many requests.
We also developed a prototype of the scanning-app, GUTS Scanner, used by event organisers to check the validity of the tickets at the entrance, simply by scanning the tickets with a phone. The prototype worked so well, we (or rather the organisers) are still using it today. It has a few quirks in usage though, and in the near future we’re redesigning this app to be a completely native mobile app, optimised for check-in speed and low-battery usage.
Alongside we ran our ICO using a fork of Constipation (‘cleverly’ called ICOnstipation), completely redesigned for the purpose of getting whitelisted and obtaining GET through our ICO contracts.
Okay, those were actually just the bigger projects we delivered last year and most of them are still being improving everyday. It’s only a part of what we’ve been working on overall, but for the sake of clarity, this should give you a global sense of the use-cases each of these projects is designed for. You’ll get more “behind the scenes” information of each app & projects in upcoming blogposts.
Going full agile with SCRUM
Our development team has doubled at the beginning of this year, and we are still hiring. Growing also means optimising your workflows, streamlining communication and channels, and making sure everyone finds a fitting spot in the team with suitable responsibilities.
That’s the sole reason we started applying a full SCRUM workflow. It keeps the whole team as productive as can be. I won’t dive into the nitty gritty of SCRUM in this particular blog though, since there is plenty of really good material on that to be found by simply Googling it. Just know that we commit to a certain set of features for a period of 2 or 3 weeks (known as a sprint), to have complete focus on our deliverables for that sprint: actual working software that can be directly deployed and used once the sprint ends.
This way we stay agile so we can easily adapt to changing specifications, wishes, new events that need particular features, etcetera. We maintain focus on what’s important NOW (in the current sprint) and commit to delivering the features we said we would in a short amount of time. Then (and only then) we start a new sprint with a new focus. Build, learn, change, repeat.
These sprints are also specific enough to use as input for our development blogs. So starting today, we’re going to publish a new development blog after finishing a sprint. For that to happen though, we do need to backtrack a little and catch up.
Our first two sprints of 2018: floorplans & seating
We kicked off the year with an epic (a bunch of small features) that we totally underestimated in terms of size, features and complexity: floorplans & seating. Last year we already laid the groundwork of our seating-algorithm, which places people on the best seats available and always together (even if they bought more tickets at a later moment, or bought tickets from someone who offered them for sale). However, this algorithm lived hidden in the depths of its own code, and could only be commanded by our CTO to fill the venues with fans. Although his visual terminal-output looked impressive, there was no way an event organiser would be able to have any control over it.
In this first sprint of the year we’ve made that algorithm visual and tangible by implementing a view for any kind of venue-floorplan in our event organisers dashboard Vuejones. Here you can run the algorithm at any time during sales, seeing instantly how it’s filling the venue with ticket-holders. It’ll always place friends & family in a group next to each other, and at any point during sales it will adjust and improve the assignments of seats to pack the venue to its fullest possible capacity. It feels pretty magical… and it is!
It ensures no single empty seats will ever exist (unless seats are unsold or blocked for this reason) and it makes it possible for ticket-holders to buy more tickets later, and still be grouped together. Even more importantly: it makes it possible to sell your ticket(s) and whoever bought several tickets from different people will still be seated next to each other! It has a few downsides as well: mostly the luxurious feeling of picking your own seat (although that comes with a few problems of its own, especially with high demanding events).
Besides visualising our seating-algorithm, we also added more specific features to control seats. Here’s a few of them:
- The ability to block seats (for employee and guest-list purposes)
- Easily assign or move specific ticket-holders to specific seats
- Automated e-mails and text-messages that inform ticket-holders of their seat numbers, including which entrance to use at the venue
- The base for roles & permissions, meaning multiple accounts can see multiple events in the dashboard, with limited or unlimited rights to edit, view and/or remove certain information.
Phew, that was a big one. I did tell you we kinda underestimated this epic right? While we did do a lot in this first sprint of the year, we also learned a lot more about how complicated this big use-case is and found that there are a lot of edge-cases which we didn’t fully cover in this first version. We’ve done some iterations in the meantime and created tasks for edge-cases and new user-stories along the way, to be picked up in the near future.
More to come from both GET Protocol & GUTS Tickets!
That wraps up the kickoff of our development blogs. I hope you now have a better understanding of how we work, what we work on and how we decide what to work on next. With all our projects in mind and a short summary of our work from last year, we can now dive a little bit deeper into one of our newest projects in the next development blogpost, Couché: our (native) mobile wallet app for ticket-holders!
Decentralization? Blockchain? Tokens?
As we have stated before, we are taking a hybrid approach to revolutionizing ticketing. In this blog we elaborated on our centralized stack and frond-end. In next interations of these development updates we’ll open up the blockchain hood of this innovating rocket. So more to come.
But for now, somewhat enjoy the sun, sell some more smart tickets and rock on coding!
More about the GET Protocol
If you want know more about the GET Protocol read our whitepaper, visit the website, join our Telegram community or get yourself a smart event ticket in our sandbox environment.
