The Python Podcast.__init__

Share on social media:

[00:00:14] Unknown:

Hello, and welcome to podcast dot in it, the podcast about Python and the people who make it great. When you're ready to launch your next app or want to try a project you hear about on the show, you'll need somewhere to deploy it. So take a look at our friends over at Linode.   With 200 gigabit private networking, scalable shared block storage, node balancers, and a 40 gigabit public network, all controlled by a brand new API, you get everything you need to scale up.   And for your tasks that need fast computations, such as training machine learning models or building your CI pipeline, they just launched dedicated   CPU instances.  

Go to python podcast.com/linode,   that's l I n o d e, today to get a $20 credit and launch a new server in under a minute. And don't forget to thank them for their continued support of this show.   And bots and automation are taking over whole categories of online interaction.   Discover.bot   is an online community designed to serve as a platform agnostic digital space for bot developers and enthusiasts of all skill levels to learn from 1 another, share their stories, and move the conversation forward together.   They regularly publish guides and resources to help you learn about topics such as bot development, using them for business, and the latest in chatbot news.  

For newcomers to the space, they have a beginner's guide that will teach you the basics of how bots work, what they can do, and where they are developed and published.   And to help you choose the right framework and avoid the confusion about which NLU features and platform APIs you will need, they have compiled a list of the major options and how they compare.   Go to python podcast.com/   discoverbot today to get started and thank them for their support of the show.   And you listen to this show to learn and stay up to date with the ways that Python is being used, including the latest in machine learning and data analysis. For even more opportunities to meet, listen, and learn from your peers, you don't want to miss out on this year's conference season.   We have partnered with organizations such as O'Reilly Media, DataVersity, and the Open Data Science Conference.  

Go to python podcast.com/conferences   to learn more and to take advantage of our partner discounts when you register.   And visit the site at pythonpodcast.com   to subscribe to the show, sign up for the newsletter, and read the show notes. And to help other people find the show, please leave a review on Itunes and tell your friends and coworkers.  

[00:02:24] Unknown:

Your host as usual is Tobias Macy. And today, I'm interviewing Adrian Munish about IndiCo, the effortless open source tool for event organization, archival, and collaboration.  

[00:02:34] Unknown:

So, Adrian, could you start by introducing yourself? Yes. Sure.  

[00:02:37] Unknown:

So like you already said, I'm Adrian. Well, Adrian actually since I'm German.   31 years old. Writing Python since   2010.   Been doing quite some programming before as a hobby as well. So useful things.   Started with visual basic.   Unfortunately,   lots of PHP as well back then.   Some c. And, yeah, eventually ended up with Python and kind of got stuck with it because it turned out to be my favorite language after I got used to it. And, yeah, still doing lots of Python, JavaScript, React, Useful things people like to work with nowadays, I would say. Do you remember how you first got introduced to Python? Yes. I actually do. That was early 2010.   I'm, in the network   game search with back then I'm in the network   game search, which back then was actually a bit bigger.  

And I'm was doing some developments there, and there was idea to rewrite the website, which was a very old PHP site back then. So, the guy who was using it,   really like Python.   So we actually use Python and Tornado for it, which, I mean, my opinion on Tornado nowadays is,   not so great. But, okay, it was a long time ago and   self touch with the Python back then like this. And yeah. You know? So I started learning Python, doing a bit with it, kind of like it well besides the framework and not being so used to it so far. Yeah. In the end, the timing with this was actually perfect   because I was about to finish my bachelor's degree back then and ended up, sending an application   to Sam for doing my bachelor project. And in the end, I was hired to join the Indigo team for a year in 2011,   which I think was actually because I had Python skills by then. And so   are you still working with that same team? Yes. I mean, there's lots of fluctuation in the team simply because most of the contracts that's on our short term.  

So I think yeah. Basically, me and   1 other person who's on long term contracts now   are still the same as initially, but everybody else changed since then. I mean, I also had a break when I was doing my master. Yeah. It's basically the only team I worked in so far. My only professional experience is actually working on IndiCo, but there's so much different things to do. So I wouldn't want it any way else, to be honest.  

[00:05:02] Unknown:

It's definitely a lucky break to be able to get involved. It's so early on with a project that's been able to turn out to be your career to date. So   congratulations on that front. And I'm wondering if you can talk a bit more about what the Indigo project is and how it got started and,   sort of what stage it was in when you first got involved with it? Yeah. Sure. Actually, Indigo project is,  

[00:05:24] Unknown:

start quite a bit earlier before I start the program well, started program professionally   because this project   started, let me check again, in 2002.   So back when I was 14,   I think it was around the time where I started doing some useful basic and PhD actually as a hobby. But the extensive project started as a European project. So there's a collaboration between CERN,   and NASA Research Institute and, some universities.   And and now I'm gonna quote from the old project description.   Its main objective was to create a web based multi platform platform conference storage and management system, which would allow storage of documents and metadata related to real events. Back then, it was acronym for integrated   digital conferencing.  

And, 2 years after that, 2004,   IndiCo actually,   went live for production usage at CERN   for,   conference in high energy physics called CHEP, which is computing in high energy physics. So back then, IndiCo was focused on actual organizing conferences.   But then over the next 3 years, the team added support for meeting and lecture type events, added room booking functionality,   then later some collaboration tools, like integration with video conferencing systems,   and the and the project was constantly growing   mostly because of the extensive use itself.  

And then the most interesting part,   2014,   because actually when I came back to the project after a break, when the development on version 2 started, which was basically under 98%   rewrite of the code base since it,   got kind of old by some, but more about that later. And, yeah, 2017,   then we finally released Indigo 2.0   based on modern technology.   So, yes, it's actually pretty much the whole history of Indicore.  

[00:07:20] Unknown:

Yeah. I was going to ask you about how you've managed to keep the code maintainable and up to date given the length of time that it's been around for. But if you did a major rewrite around the version 2 time frame, I can see how that would help with trying   to modernize it and bring it up to date with current paradigms and tooling. So I'm curious   if in that process, you brought it up to Python 3   compatibility   and some of the other major changes that were necessary in that process of upgrading it for the 2.0 release? So, indeed, 2.0 was was a major rewrite. Like I said, 98 or 99% of the code rewritten  

[00:07:57] Unknown:

as both back end and front end. Just a few things remaining,   which we hope to tackle soon. So for example,   in 2.0, we completely switched databases   because before it was using set ODB,   Python based object database.   And then we switched to using   SQLAlchemy,   2013, we switched to from an homemade WFGI   framework to Flask. We switched template engines twice. I think it was 2011 where we switched from something homemade to macro and send all during the rewrite from macro to ginger.   Python 3, unfortunately,   not yet. But it's certainly we want to do. I did listen with Indigo version 3 because it's a great opportunity to bounce the nature of Russian number   again. Also, it's hard to resist the temptation to have version 3 for Python 3.  

Fun fact, just a few weeks ago, I actually, tried, running in the core on the Python 3 locally,   not even using 2 to 3 or anything.   Just editing a few places where things failed   and at least getting to a where the basic thing running was pretty straightforward.   So I think we don't have any major hurdles going to Python 3 eventually.  

[00:09:10] Unknown:

And   so as you said, Indico is a tool for being able to manage events and   booking resources and being able to track various   assets that are associated with those events. So I'm curious,   what are some of the other projects that are operating in a similar space, and what the current state of the landscape was when Indigo is first being created that made it necessary to build it in house? When Indigo was being created, I have to admit that's a bit before my time. Back then, I had nothing to do with conference management.  

[00:09:44] Unknown:

Like I said, I was 14 back then.   I think there were no real good alternatives.   I mean, I know that, for example, for meetings at firms, there was another tool called CDS Agenda, which I've actually used, I think, since 1999.   But that was mostly for lectures and meetings with new PHP actually. It was kind of the ancestor of Indigo. But on the market, if there was anything commercial available back then, I don't think so. But I have to admit, I never researched,   things that much in the past. And so  

[00:10:18] Unknown:

for somebody who's looking to   manage an event even just as small as a meeting, but potentially as large as a conference, I'm wondering if you can just talk through the workflow of how they would go about setting it up and managing the event over its entire life cycle using Indico? So it actually depends on whether you already have an in the current instance where you have access or not. Because,  

[00:10:41] Unknown:

the most common use case of access to have it as a repository   of events. So it's not as much focused on organizing a single event like some of the other commercial tools available nowadays, where you really run 1 single conference with it. But, basically, repository where you can have 100, 1, 000, or even 100, 000 of events depending on how big you are. So assuming you already have Indigo installed,   it's literally just a few clicks.   Usually, you pick a category.   You click create event, enter a few basic information, like a title and the time and date  

[00:11:16] Unknown:

and set this. Then you actually have your event, which you can then configure our server. And so you're saying that it's primarily used as an archive of what happened during the event and some of the presentation materials,   but can it also be used as sort of the organizational platform for people who are collaborating to try and get everything set up? For instance, something like Picon or the high energy physics conference that you were mentioning. Yeah. And you could cover us basics the whole life cycle of the conference.  

[00:11:44] Unknown:

So it's I mean, it starts when you create event as a conference. You have, well, somewhat basic conference web site, which you could actually style with custom CFS to make it look prettier. For scientist especially for scientific conferences, you can set up, like,   scientific program of the conference with different tracks. You can run a call for abstracts,   which for those who don't know what that is because I don't organize conferences.   So it's basically when you are asking for ideas on talks and maybe posters,   but all kinds of contributions, basically.  

Then if you did this and people submitted their proposals, you can actually do a reviewing process on it, either with separate reviewers and charges or charge or only charges. Like this, you can have a group of people actually select which,   proposals they actually want in the conference and which they don't. Maybe changing the type, if you decide, for example,   hey. This sounds interesting, but maybe too much for a presentation.   We'll just, do it as a poster. Then when you have,   decided on which contributions you actually want, you can use IndiCo to organize   a timetable or agenda   of, event. We actually arrange everything, like, when it happens, maybe group it in sessions,   decide what's parallel or if you have a plan of recession.  

So that's the graphic viewer in Indigo where you can see what's happening when. Interesting fact, this is 1 of the few places where the front end is very much legacy.   Hopefully, we can provide that in React at some point. Then another   important feature for, I guess, many conferences is the registration.   So in the code, you can configure a registration form with custom fields and everything.   Hopefully, at some point, even with, like, conditional fields where you can select something. I have to select something depending on what else you selected. But right now, it's really only asking for users to enter data. But for most conferences, actually enough, at least in our case.   You can connect this to a payment system.  

For example, we have plug ins for PayPal,   and somebody   contributed the plug in to integrate with Stripe and 6 Pay. So if you install 1 of those plug ins, you can actually   quickly let people pay by credit card or PayPal   for the event. Then what you actually mentioned before,   uploading materials such as slides. That's something you can do as soon as you are,   an author or speaker for a given contribution. Then by default, you have access to upload materials for it. Can be any file. Usually, it's PDF or PowerPoint presentation.   Again, since we support plug ins, somebody could have a plug ins that automatically converts the PDF to PowerPoint.  

So it's something we do, for example, let's say, on the as a custom plug ins for us is that's interacting with another service we have here, where if you upload what   where Office files in general, by default, it will be converted to PDF. Then after the conference itself, at least for scientific conferences, it's somewhat common that people submit the paper and related to the talk. If you enable that feature, you can actually do another reviewing process for this 1. And at any time, it's a conference life cycle, you could run the survey   either anonymous   or requiring login and knowing who answered what. So, yeah, in the end, it covers really,   basically,   all conference features   that people in,   high energy physics community   considered useful enough  

[00:15:16] Unknown:

to ask for it, and we consider it useful enough to implement them. In particular, I really like the fact that it, that it offers a single repository for all of the different materials related to a given talk. Because there have been a number of times where I've gone to conferences, and there's just usually not any well thought out way of being able to collect all of the slides and other presentation materials for people to be able to refer to after the fact. And so, usually, it's maybe 1 person   sends it out on Twitter, 1 person has a link in their slides that you have to try and remember, and, you know, there might be an email that goes out afterwards, or somebody might collect everything after the fact. But having it be part of the overall planning process and something that's easily   centralized and easy for all the attendees to access definitely seems to make a lot of sense. Indeed. So it's actually 1 of the things you mentioned in,  

[00:16:07] Unknown:

introduction video we have on our website,   which is basically giving a very high level overview about why in the call is useful.   And as for example, we have said why it's useful if you come to a meeting room,   you figure out, oh, my laptop doesn't have the necessary connector to actually connect to the projector. So so 1 of the use cases is that if you have a computer in the meeting room and log in to Indigo,   you can access   anything, any slides, etcetera, where you need from there without having to connect your own laptop. Of course, reality is a bit different because then you might use   something fancy like for   your presentation   and end up with a conference room that only has Internet Explorer installed. So in the end, you connect your laptop anyway. But still, the uploading for presentation   or at least the PDF version of it to Indigo,   Like you said, it's being archived.  

So even if you don't use IndiGo to present it yourself,   anybody can still download it from IndiGo later.  

[00:17:08] Unknown:

And   so can you talk a bit through how Indigo itself is architected   and some of the ways that it has evolved since you first began working on it? I actually I just noticed  

[00:17:19] Unknown:

1 interesting fact from the previous 1 I forgot to mention.   So it actually,   1 of the sales conferences, I think it was ID 60 something that was organized with the Indigo instance at   with Europies in 2006,   which I think actually took place at CERN back then. So the in the course already kind of related to the Python community  

[00:17:44] Unknown:

set many years ago. That's cool. So yeah. And so can you talk through a bit about how Indigo itself is architected  

[00:17:52] Unknown:

and some of the ways that the architecture and design of the project has evolved since you first began working on it? Yes. So let me let me start with the architecture we had in legacy in the core 1. So back then, initially, we were actually using more Python.   So basically, Py files using various containing very short functions,   calling into different layer. So eventually, when we add the WFGI,   back then also using a homemade WFGI   layer because   you didn't have Flask or anything like this at this point. And I think not sure if Tango existed back then. I don't think so, to be honest. Maybe there was soap because had ODB existed obviously back then.   But but I don't think that was would have been a good choice since I from what I heard, the soap based frameworks were quiet everywhere.  

Anyway,   coming from the   like layer,   she's called into the next layer called the RH layer, sending for request handler.   This basically implemented   the business logic.   From there, we had 2 more layers.   The first 1 was called the w p layer, standing for web page.   And if I remember correctly,   if this was basically   converting whatever database objects we had, to   a new structure,   like a dictionary or some arguments to pass along,   used for displaying.   And then because this original architecture, we didn't have any nice template engine.   Initially, not even support to have any conditionals and templates. It was then calling, the w classes, which stood for,   I guess, for web,   which was basically send   converting whatever view data you had to actually data passed to the template. And let's,   forget also   stone age style structure and go to what we have nowadays.  

So now I mean, in terms of project structure, it's still a bit similar   because when we were writing it, we were actually doing it   part by part. So we didn't do any major changes   in, for example, replacing   everything with simple view function like you usually do in Flask.   So coming from the Flask app, we have lots of different blueprints as usual. Instead of registering normal functions, we will our IH classes, which we had before,   except now they're much more lightweight.   And so as functions, we still do pretty much all the business logic.   But from there, we directly call through a very thin wrapper from the old WPA system,   which only adds, for example, the HML structure around it because it would have been a bit,   too complex to actually replace everything with ginger inheritance during the rewrite. That's because it was partially initially. But, yeah, from the IH class, it's basically calling to something   roughly equivalent to Flask's render template,   and that's it, basically.  

1 of the things we do on the IH level as well is handling errors and doing automatically,   doing   something else to do inside sorry. Something else to do inside each class besides, things like our handling and some basic logging   is handling database   comments,   which was mostly,   because in the past, when we were using set ODB,   we had to somehow sometimes we try a request.   Maybe I can talk about this 1 a bit later when we come to   the interesting parts because LDB had a few particularities   that were well, not what you're used to if you do SQL, etcetera, now it is.  

[00:21:25] Unknown:

Yeah. I've,   had the dubious pleasure of dealing with the, ZODB system and some of the interesting ways that they have approached the entire idea of what a database is and could be. Sounds like you had about as much fun as it is as us.   Yeah. I'm actually still currently maintaining a project that relies on it. I mean, I'm sure ShadowDB has its flavors.  

[00:21:50] Unknown:

And I guess for prototyping, initially, it was very convenient.   But in the end, when you grow when you have a set of DB,   I think that, data f f file was around 40 gigabytes on disk eventually   for sound in the coincidence.  

[00:22:06] Unknown:

Yeah. I've got a project that I'm maintaining right now where I think we're running about a 60 gigabyte   0db   database, and it's,   it's fun when it gets corrupted. You have you have to try and figure out a way to repair it.  

[00:22:18] Unknown:

Luckily, I never had to do with it. I think there was maybe I think from I think I remember there was, like, 1 case   where something in the database got corrupted,   but I don't remember how exactly it was fixed because I think it was before I joined the team. But as far as I know, even with   a c l d b having sometimes some corruption,   In   also 17 years now of the project, we didn't have any single actual data loss   unless you count people accidentally deleting things they didn't intend to delete.   But, well, that's a layer 8 problem, so I wouldn't blame the product   for it or the database. And  

[00:22:57] Unknown:

so   can you talk about some of the more interesting or complex or challenging aspects of working on Indico, both from the point of view of the technical implementation as far as what was difficult to manage and also from the perspective of the,   business logic and the use case as far as just understanding   what is necessary to be able to manage some of these large events with all of these different   resource allocation problems and just trying to figure out how to represent that in code? Yes.  

[00:23:29] Unknown:

Actually,   in terms of,   nontechnical,   sometimes the biggest use as the biggest most   in terms of nontechnical   things, the most interesting   thing is probably   how people use the system in, let's say, unexpected ways.   For example,   let's take abstract reviewing. We have a very nice time line,   which totally doesn't look similar to the timeline of the GitHub pull request. And, of course, then you have people   who are asking,   how can I print the list of abstracts   with all the details?   Because, yes,   you have people who are used to taking the list of abstracts, printing it, getting a meeting room, hopefully, for in the call, then sitting   together using,   not a pen, maybe some papers, and doing the reviewing offline. Even so, we have a very pretty user interface where you can do the reviewing directly in INDiCO.  

So, of course and we had to ensure that all the PDF exports we had for this area well. So it looked nice. It was nice to print.   And then coming to more technical things, I would say, some 1 of the most complex   parts is actually protection.   Because, I mean, even so   for example, in case of firm, we are very open. So actually, many meetings and lectures   where the slides and details are completely public   even to people outside firm. But, of course, you have our also meetings, let's say, HR or even,   other internal things. I mean, even our team meetings. I mean,   they usually don't contain anything completely private,   but, I mean, it's a meeting amongst the team.  

You you don't want those fully public. So IndiCo provides,   nested,   protection schema.   Basically, each category can be either public, protect it, or inheriting unless it's a wood category,   which has nothing to inherit from, of course. So if you, let's say, go into a category a few,   few levels deep   and you have inheriting parents, you have to actually climb up the chain until you find the category   where you're not inheriting anymore and send you the excess checks there. Sounds easy?   Well, let's assume you are,   have 50 levels of category nesting,   which luckily we don't. But, yeah, you have to climb up 50 levels, up. And at least with standard SQLAlchemy,   that would usually mean 50 queries for every every time you load the page where this kind of access needs to be checked. So for this,   we actually had to do some f nice SQL   where we got lucky. You said quite early in the rewrite project, we decided to only support Postgres.  

And let me tell you 1 thing,   because CTEs are very, very amazing thing in Postgres.   Because that thing that way you can basically do all of the climbing up in a single SQL query. And in the end, for example, it returns this ID of the category   The first 1 is not inheriting,   or you could,   what else are we let me think. Yeah. I think that's the most interesting   part. Basically, I have a few more CTEs, for example, to get,   nested event counts for categories including subcategories.   I would call it dark SQL metric,   but I have to say, I had lots of fun implementing it. The other way, Raul, and something else, we did is, if you have an event that's, let's say, public or protected,   it might have parts inside that have a different protection level.  



[00:27:06] Unknown:

Yeah. It's always fun trying to figure your way through a naughty problem like that where you have to pick apart all of the different dependencies and figure out how to turn this complex   piece of business logic into something that's tractable and that you can actually implement in the code in a manner that's able to be reasoned about without turning it into   essentially a a mere image of the real world problem case.  

[00:27:31] Unknown:

Indeed. So it's actually also interesting since the last time we were writing the room booking system doing the 2.0   rewrite   because this 1, while the car was using said ODB,   at at least in theory support for different types of databases.   So, basically, there was not sub abstraction layer, which was then always calling a cedar d b layer again.   But see, with this abstraction layer and the ability to use separate cello d b foil, it was even more complexity.   So, yeah, when we're buying this 1, we also had to deal with getting rid of this extra obstruction.   And, yeah, actually, room booking is the 1 thing we actually wrote again with   the we're currently working on because that 1 is actually now, React application inside Indigo.  



[00:28:18] Unknown:

And so for things like the room booking or ensuring that there is access to the necessary resources for a given presentation   and also in terms of ensuring that all the different participants are able to be free within a particular time frame, I'm wondering how you approach the business logic of being able to manage all of those constraints and resolve them to a single time frame where everything is available and everything is accessible?  

[00:28:45] Unknown:

Actually, currently, the answer is we don't. Because the only part where we do is this kind something like resolving,   things using for the front end, in the timetable   to actually show a parallel session in a nice way. But I don't think that's,   exactly what you mean. I think what you meant is more something like like what you do with Doodle nowadays to find the time for your event. So currently in IndiCo, when you create an event, you already have to know a time and date. You can change it later, but we don't have any way right now to use in the code to find the time where people are available. Interesting fact, this might actually change,   in the medium term because at sound, we are currently looking into options to   find good alternative to things like Outlook or Doodle. So they're actually considering is to have Doodle like functionality,   like Doodle on steroids because it would be able to access, for example, the calendar of people. And then you could, do something where you select the list of people, usually, maybe from   database or whatever other database you have, then maybe provide some possible dates which you are a lot which you are available in   and immediately see,   how good sales options are for your participants. And then, eventually,   when you decide on a date based on set or got responses from people like Doodle, then you could decide on a date and actually create event from it. But to be honest, not completely sure if that would actually become a part of IndiCo,   maybe a plug in, maybe a stand alone application only using the INDiCO API.  

Because in the end, its functionality   is as great to organize an event, but not only for that. You could use the same thing completely without Indigo if you just want the sales host to doodle, for example. K. And another case,   is a new home booking system.   Because if that's if you have meeting rooms at your organization,   chances are good. It might be hard to find 1 at the particular slot you're interested in, especially if you have a building with lots of people and only 1 meeting room in that actual building. Because, of course, people like staying in their own building for a meeting. They were just going downstairs.   At least, our team really likes that. So you might notice oh, where do I do my meeting now? Usually, it's from 10 AM to 11 AM. So let's find a room for it. Ideally, this 1,   not available. But what we do is the new room booking, we actually look for alternative.  

So basically, we try, to see if we can shift the meeting a bit, start a bit earlier, make it a bit shorter,   offer a multi day meetings, maybe skip a day. And in that case, we offer the room you were really interested in with some minor changes.  

[00:31:30] Unknown:

And another area of complexity that often comes up, particularly when you're trying to deal with anything that has to do with time is the issue of time zones. So I'm wondering how you've approached that problem in Indigo given that 1 of the core pieces of functionalities around this scheduling component.  

[00:31:46] Unknown:

Yes. And other parts   that can be very fun from time to time to deal with, especially if you include daylight saving time. Well, luckily, apparently, we are getting rid of it in the European Union, but, well, still something you have to keep in mind because there will always be countries which with DST.   Anyway, so, basically, in the current default time zone, which in most cases, basically, the time zone of whoever's hosting it. So in each category, you can set a time zone and,   on event as well. So when you're viewing an event as a user for any of the public areas of the event, by default, you have the time zone of the event for everything to display, but you can change it to, for example, see everything in your own time zone. Then when managing event, we always show it in the time zone selected for the event   simply to avoid any confusions if you have multiple people   organizing the event, and then somebody would see a different time.  

That would be, basically,   chaos.   It's a really tricky part with time zones is displaying information.   Let's say you have a conference   that runs from   9 in the morning to 8 in the evening.   That's great. You see everything on 1 day.   Suddenly, you have somebody who's in a time zone,   let's say,   6 hours later.   So suddenly, this person looks at the timetable.   And   at least at some point during development,   what happened was   basically an error because suddenly   you had, things that used to be on the same day suddenly on a different day. So the tricky thing there is to really make sure the time zone is always converted properly.   Calculations are either done in the time zone or in UTC,   but never in a mix of both.  

So time zone handling is 1 of the things I personally   let's say, hey.   Because, I mean, I I consider myself smart, but imagine   time zones and so things,   I just don't like it.   Luckily, I think we got rid of most of the issues related  

[00:34:00] Unknown:

to it by now. I think if anybody says that they enjoy working with time zones, then they should probably have their head checked. Well, I think enjoying to work with time zones would be rule of certainty for material.   And another area that's often   challenging to work with is that given the level of flexibility and configurability   for Indigo, it's often   problematic   for users who are first getting started with it to be able to make sense of the system. And so it can often be something that will turn them away from trying to work with it. So I'm curious how you approach   managing sane defaults for the system to make it so that users who are first getting started   have an easy onboarding experience, and then just dig into the more complex aspects of it as they need to.  



[00:34:48] Unknown:

So if, you start with somebody who doesn't have an Inuco instance yet, we actually have a step by step setup guide for.   We wouldn't to,   send us both 1 for Ensigns and Apache.   So you   theoretically, somebody with almost no Linux knowledge could follow this 1 to have   a secure setup   of his own Indigo instance.   Of course, would have to take care about updates and the usual things.   So, personally, I don't think somebody   who,   doesn't know how to manage Linux should be running the server   himself with Indigo.   But if you have, for example, somebody doing IT, you can easily have somebody go through the install guide and set up an Indigo instance.   Anyway, I guess you mostly mentioned this question about actual users using Indigo.  

So feel free to skip the first part if you prefer to. So as a new user in Indigo,   it depends, of course, what you want to do. While Indigo does offer lots of functionality,   especially the basic things are pretty much self explaining.   And the advanced features like abstract or paper actually   disabled by default. Also, we have, user guide, which is nowadays linked in the footer of each page.   And this guide not only explains,   the basic concepts,   but also has a bunch of training videos,   explaining things more in-depth. And this guy is actually host on GitHub. So if anybody is trying out Indigo now and missing something,   pull request welcome.  

And then, of course, if you're using Indigo a big organization,   maybe, you have somebody providing training. For example, says what we do at CERN,   a few times per year,   1 or 2 of the developers actually do   a 2 half day training sessions,   showing,   the most important features to people who either never used IndiCore or never used it to organize conferences with us. But, of course, ideally, we want IndiCore to be   so straightforward.   So   there's,   much less need for this kind of training. But, of course, with something like in the core, of course, we have lots of different users.   You have technical people,   but organizing conferences is, of course, often done by the secretariat.  

So, of course, we have people who are not set much used to using   web apps that are not super   modern. I mean, pretty much everybody is using Facebook nowadays.   So, ideally, we have a UI that's as easy to use as any of,   big web apps nowadays. But I think, it's hard to compare something like Twitter or Facebook with something like Indigo simply because we provide so much more functionality   compared to something rather specific. So I guess it's always that there are some, things people need to get used to. And as far as ensuring that you are shipping usable  

[00:37:55] Unknown:

using   So I'm wondering if you can just talk a bit about the overall approach that you're using to make sure that you're testing   the, at least, critical pieces of Indico and some of the challenges that you faced on that front? So you already mentioned it, critical pieces. We actually try it at 1 point, which was,  

[00:38:14] Unknown:

room booking for 2.0   to basically cover every single assumption with the test. It it's ended turned out to be way too much work for   little benefit. So what we're doing now is, unit tests for critical parts. Our area, as we know, is that they're gonna have strange edge cases. So for this, we have tests   using Pytest. And for now, it's pretty much only unit test. In the past, at some point, we used to have some selenium tests as well, but we got rid of those since they aren't really maintainable.   And, I don't think we ever really found issues with those tests. But unit tests, at least the area where we have those, are quite helpful. I think, ideally, we would have more tests. But as you probably know, reality,   strikes,   and there's so many things that should need to be done. So then,   there's not really a time to write a test for everything. So, yeah, like I said, we focus on critical parts, on edge cases. And, yeah, so that's pretty much it in terms of testing, at least the technical kind of testing. I think, our in our in the coincidence is basically the biggest 1 I would say. We have 1 big advantage. We have users who are very good test runners   to say. So if we deploy a new version, nowadays, everything actually goes pretty well. Back in the cell DB error, of course, there was much more to fix usually after new release. But nowadays, of course, users find some issues, but usually only a few minor things. But it's still amazing to have set many users because like this, no matter how many unit tests you have, users are gonna find some bugs.  

Yeah. They're often quite good at that. I mean, companies like Facebook do it. They add new features. So maybe if okay. If they use to do AB testing, which is something we don't. But in in the end, the 1st company is, say, use users as testers even   more. Sometimes even with new UI,   which turns out to be awful in some cases. Mean, we don't do that because we like our users.   We sometimes do usability tests for some things. For example, for new home booking, we invited,   p various people,   some IT person, some power user, some secretaries.   So we actually let them do some steps with a new UI, send, had a look what they were doing, where else they got stuck, what they like, what they dislike.  

This was quite pretty helpful for doing the UI development.   So like this, we got feedback earlier, which, of course, has advantage that so if people send can't really complain if they decide they don't like UI in send because they had the chance to give feedback. But, set aside, of course, it's extremely valuable to get this kind of feedback early when it's really easy to change things and not shortly after I release. Because nothing more annoying that you release an amazing new awesome, and then your your users tell you, hey. But since, workflow, we use also time, doesn't work. So how can we do this now? And then you end up having to implement  

[00:41:07] Unknown:

things on very short notice. And you mentioned earlier too that IndiCo has a plug in system. So I'm curious if you can talk about some examples of plug ins that you have written or that you have used or some of the more interesting or unexpected ways that people have integrated with Indigo. Yes. Speaking of the plug in system, that's a fast extension we developed called fast plug in engine. Unfortunately, not too much documentation  

[00:41:33] Unknown:

yet, but, again, contribution is welcome. Feel free to try it out. And, plug ins. We actually have quite a few. Most of them actually developed by us. Interesting ones. Let's see.   I mean, we have a bunch of plug ins useful to the general public. I would say the most useful 1 nowadays would probably be the s 3 storage. In terms of,   really weird things or funny plug ins, there's nothing I can imagine in this area. I mean, it's mostly plug ins that are actually useful for certain cases. Like, we have a plug in integrating with PayPal,   1 to preview code with highlighting or even Supercell Notebook.  

And I would say in terms of interesting plug ins, it's actually the plug ins that I use for sound specific use cases. So plug ins are also public on GitHub simply to provide   examples   of more complex plug ins. So for example, we have 1 plug in   that's actually used to grant guests access to the site of our organization.   Or it's just 1 plug in that's actually used to grant visitors or site access to the sounds. There's 1 plug in we have that's actually used   to print visitor passes   so people can get on the site without being employees. So for this plug in, basically, we're hooking into the registration process of Indigo. And the event manager then has ability   to select, yes, I want to give these people access. Then it automatically calls an API,   of access control team. It generates a QR code, and and send people to print it and use this to get on-site. So and, actually,   I mean, it has not a plug in yet, but we have 1 as a big user of Indigo, and that's United Nations who actually using this as a primary way also to grant access to people   to get on-site for our conferences   organized. And there's 1 plug that I really have to mention   because that's actually our April Fools' shows we did this year. It's based on the new home booking system we did,   allowed people to reserve hours at turn. And since we are talking about testing before, it was a really great and fun way to actually get some real users using a new system   without,   any real value. And we had it running for 1 day, and we had around 1, 000 people who actually created an account in this new system. And quite a few were booking showers in the system, usually with a funny message. But in the end, it was, provided testers. It was a funny thing to do, and it didn't even take much time because of how flexible things are in Indico and others. And you mentioned that 1 of the notable users of Indico is the United Nations. I'm wondering if there are any other interesting or notable ways that Indigo has been used either for different organizations  

[00:44:19] Unknown:

or for specific  

[00:44:20] Unknown:

conferences or events that you're aware of? 1 interesting event, I think, is some Linux. I I think it's called Linux Plumbers Conference or something,   like that. And I think,   open shoes was using it at some point for a conference of organizing.   And what's quite interesting is that we've seen quite a few   religious groups from Africa using Indigo to organize,   some pastoral   congresses   or something like so, which is something at least I would have never expected   that you actually have somebody using Indigo to organize religious events. And that's a fun use case that was actually on the sound Indigo instance. Somebody was using an indigo event in our test category,   to invite people to his wedding.  

So, yeah, people find interesting use cases for us. Unfortunately,   said event was in the test category. Eventually, it got deleted when we started automatically   clearing it up, but it was still,  

[00:45:18] Unknown:

nice to see what people end up doing within the call. Yeah. As I was reading through the documentation and looking at the feature set, it definitely seems like it's flexible enough to be able to use for all kinds of different use cases.   I was even envisioning maybe using it for, like, family planning needs of figuring out, you know, if you have a 1 car household and you have 2 2 or 3 different kids, and they all need to be at different events at different times, trying to figure out how to book everything to make sure that you can get to the different places at the right times with the right people.  

[00:45:47] Unknown:

Ah, okay. Because I was actually thinking   with,   that we could actually integrate with the calendar,   which is something we do with a custom plugin as well,   to add events you're attending to people's Outlook calendar.   So, yeah, you could actually send, have a look at what events you're attending in through Indigo   and, maybe overlay it with your personal calendar if you have a calendaring tool supporting it. And this doodle like thing we might do at some point in the future   could also be something which is in somehow combined with your personal calendar to get an overview   of both personal and work related events.  

So I think there's lots of potential in this area.  

[00:46:31] Unknown:

Yeah. It's definitely a pretty interesting tool, and I know a couple of people who are involved in organizing different conferences or events. So it's something that I've been planning on,   mentioning to them as a potential way to simplify some of the overall process of trying to get things lined up.   And so what have been some of the most interesting or unexpected or challenging lessons that you've learned in the process of building and maintaining Indigo?  

[00:46:56] Unknown:

I think the main point is that dealing with legacy data really, really sucks,   especially if this data you have is actually inconsistent,   which unfortunately with the database like ShadowDB is very likely.   Because if you don't know ShadowDB,   it's,   I think, I'm not sure who started calling it like this.   But I remember seeing somewhere the term, a glorified tickle store. Because, yes, in the end, you have classes, dictionaries, and lists in it. So no schema or anything.   So you might end up having older things in the database using,   Sysprocture,   send something new. Suddenly, instead of a string somewhere, you have a dictionary or another class.  

So even if you just want to go over this data to import it to your Postgres database,   it's not fun dealing with all those cases,   especially if the database is big enough, so running the migration takes a few hours in total.   And,   but, this thing showed 1 thing, it's really important to,   be make sure your data is consistent.   For example, you really don't want, an event set of contributions that are starting after the event actually ended   Because imagine you're drawing the timetable based on the start and end time of the event,   and then you suddenly have a contribution outside. So as for this, we actually added some   constraints as trigger functions   in, in post QS SQL   to actually ensure that this never happens.  



[00:48:30] Unknown:

And   what are some of the   features or improvements or overall bug fixes that you have planned for the future of the project?  

[00:48:39] Unknown:

Well,   1 thing, of course, is Python 3 support.   Well, actually, it will probably be more switching to Python   3 since I think for a project like Indigo, there's no not set much value in supporting both Python 23 at the same time. Because with Indigo 3, that would be a nature release.   It would be a clean-cut   where we would tell people, okay. Time to delete your virtual ends. Time to upgrade your Linux distribution to the latest supported 1. Time to make sure you have Python 3.6   because I don't think we're gonna support anything   lower. Well, maybe 3.5.  

We have to see when we actually switch what's the right   mainstream support.   But, personally, I can say I really want the f strings in whatever Python 3 versions they're gonna support. That's 1 of the things I really like in Python 3 when using it for my own things. So I think it would be a shame to support an older Python 3 version   because I'm pretty sure whatever Python 3 version we pick for Indigo 3   is gonna stay supported for a very long time.   So besides Python 3 support,   of course, eradicating,   the remaining bits of legacy codes, like some parts in the front end, also a few bits of Python codes that are still legacy.   I think we even have some codes remaining that's using camel case. So it's something I really want,   to change.  

Not in not too far in the future.   Then,   front end wise,   having more reactive   stuff. Because we started using React, for things like home booking about a year ago,   and everyone in the team really likes it.   It's actually quite,   bad now for any of us if we have to go back maintaining the old check query based thing sometimes.   So especially for management   areas, we really want to do more, React,   which also means that things are gonna be more, which is great, for creating APIs.   And that's actually it's the last thing I got to mention here. It's actually a GitHub issue I created before we released 2.0   to improve the API a bit, also how authentication   is done. For example, I really like how GitHub is doing it, like being able to create   tokens or using OAuth   depending on your use cases.  

So that's something I really want to see happen at some point.   Not sure when we have the time for it. Hopefully,   we have it at some point.   And besides that,   it really depends on   use cases.   But at at Sun since I in in Sun is the main   developer of Indicore.   I mean, we, of course, have external contributors where most of development is happening at Sun. But I have to say, contributions are always very welcome.   And, yeah, if you have any great idea for things to improve in IndiCo,   let us  

[00:51:39] Unknown:

know. Well, for anybody who does want to get in touch with you either to add suggestions or provide feedback or to follow along with the work that you're doing. I'll have you add your preferred contact information to the show notes. And with that, I'll move us into the picks. And this week, I'm going to choose the movie Mortal Engines that I watched recently. It was very interesting, very,   visually appealing,   a lot of different actors than you're used to and sort of the big blockbuster movies. So it was a lot of fun to watch. Definitely recommend that for anybody who's   looking for something sort of, fantastical   and visually appealing. And so with that, I'll pass it to you, Adrian. Do you have any picks this week? That's actually a good question.  



[00:52:17] Unknown:

I have to admit when it comes to movies, it's usually,   the typical superhero   movie since it all usually fun to watch.   We very recently, I had the chance to try out the virtual reality headset   at a friend's   place, and I have to say   it's really fun. So if you have the opportunity,   try it out.   Portal is fun, but Portal VR, I would say, is even more fun.  

[00:52:43] Unknown:

Alright. Well, thank you very much for taking the time today to join me and discuss the work that you've been doing with Indico. It's definitely a very interesting platform and 1 that seems to have a lot of potential utility.   I'm definitely looking forward to seeing how you do with the 3 0 release. And so with that, I want to thank you again, and I hope you enjoy the rest of your day. Yeah. Thanks a lot for the interview. It was quite interesting to talk about, Indico.  

[00:53:06] Unknown:

And, 1 thing I have to say, if anybody's interested, feel free to pass by our IRC channel,   called Indigo on Freenode   Also, developers are there. I think it's the best place to reach us.