EmpowerApps Show 215: Then 20 Years Later with Georg Tuparev

---
From Punch Cards to NeXT
---

[00:00:00] Welcome to another episode of Empower Apps. I'm your host, Leo Dion. Today I'm joined by Georg Tuparev. Georg, thank you so much for coming on the show. Thank you for the invitation. you have extensive amount of experience and we're gonna be talking about some exciting stuff today. But before we begin I'll let you go ahead and introduce yourself. Unfortunately I have also an extensive amount of years behind myself. So yeah I started hacking with computers when I was teenager, started with punch cards and then programming satellites, telescopes, the then I went to I I was born in Bulgaria behind the Iron Curtain.

[00:00:50] Then I escaped to West Germany where I finished my studies and then during the studies I also worked at the European Molecular Biology Lab where I start to understand what is a big computer like big SGI computers and parallel computing and vector processors and so on. And then sorry, what? What? decade was that when you were starting the is that is something about say from the early nineties. I I bought my first NeXTcube, NeXTstation and nineteen at the end of 1990. Nights. So and then I went to work for a American consulting company. And I I didn't like very much working for a consulting company, so I started my own consulting company and then we sold it and then this is my second one and here we are.

[00:01:49] Awesome. So we met at ServerSide.swift I can't see my shirt, I'm wearing the shirt today, but the ServerSide.swift conference back in 24. you talked about large scale data, which we'll talk about later.

---
Twenty-Year Projects with a Small Team
---

[00:02:02] But kind of let's let's just start talking about you've worked on some pretty big projects, and a lot of them are in the science and research space. Kinda give a few examples of some of the large projects you've worked on. Yeah, I will just give two past and two current projects. One of the past projects is called Monet, like the the painter, the French painter. Okay. And it was probably the first fully robotic observatory control system in the world. we had large we controlled a large telescope in US, in South Africa, and Germany. by the way, all the projects that I'm talking about are using Apple technologies.

[00:02:48] So the other one is still ongoing. It is a very large transaction handling project that sits between the large Dutch companies, the Dutch government and the Dutch banks. and basically handles gazillions of transactions and so on, obvious stuff. Then we were called to help with archiving of the NASA Mars mission images So there is a huge archive, multiple, building full of our with archive with disks and archives and so on. And we had to do a the UI for administrators. And the one that you mentioned, the that I talked about in the last server-side Swift conferen conference, and something that we're we started just a few months ago.

[00:03:45] It's called Sky Observer, and it is a portal for astronomers and space scientists where we keep information about space junk, about astronomical catalogues and observatories. There will be also a community for astronomers and space researchers and so on. So these are types of projects that we're we're talking. We had also projects like in the for the German police, for German education Ministry of Education, for Henkel the the the the chemical giant Henkel in Germany and so on. But they're more in the past. This is I'm just going on Sky Observer. This is really cool. this is your this is your cause it says it's it's your company's project, right?

[00:04:35] Okay. baby. that's beautiful. Okay, yeah, I'll definitely put a link to that. it is bet b better and behind the scene there are many things already working but the UI is very, very primitive and mostly hard kind of car almost c hard coded, just for people to to get some feedback. Yeah, very cool. We'll put a link to that in the show notes. So based on some of the projects that you've done, what are you you run a very small team? I don't how many folks are on your team? maximum at ma maximum about twelve, fifteen people, at the time about ten people. Okay. What are like what are some things that you find helpful when you're taking on these large projects with such a small team?

[00:05:25] Well the first thing is that these type of projects never start complex. They start small and the complexity comes later. So for instance the banking project that we are talking about that I mentioned, I mean started more than twenty years ago and started just as an archive for a bank bank statement of a Dutch credit card company. then slowly grown to this huge project that basically connects all the government and bank and large corporation sites. And you cannot plant this one. The other thing is that at least as important as know knowing or understanding the software development, you have to understand the domain of the project.

[00:06:10] Is it an astronomy? Is it a finance, government, medicine, and so on, healthcare? And this is a very, very important point. if you look at our team, I think there is only one person that were that is a software engineer. We have physicists, mathematician, engine astronomer, all kinds of people, even a drummer. but not really not the software engineers. And this is very, very important skill that we bring together. When we start such projects, we almost never plan to have the project to be multi-year project. We always think that is a half a year, a couple of months, we'll finish. And then 20 years later we are still doing development.

[00:07:01] And the other thing is that during these development times, the technology also evolves. if you if you're talking about Monet, for instance, where we started about 2005. We started with Objective-C. And some of the frameworks then we used WebObjects at the time. WebObjects we still use for many of the projects. unfortunately, because there is no better replacement of EOF, not because of the WebObjects itself, the web part of the WebObjects, but EOF. But now you you started with a technology that is 25 years old. Actually, Marie Huclaud, I don't know if you know him, he was the CTO of NeXT. he sent me a ver he sent me the source code of WebObjects 0.51 to check it.

[00:07:49] That was in 95. Okay. And still working. I mean it's a very solid technology, but now we have AI and all these new babies in the gar kindergarten. so the technology evolves also within the project. So you have to be flexible to evolve this per technology and to focus on the such architecture that can take both evolutions of complexity and evolution of technologies, and of course hardware. so sorry, business talk. how do you like do you do like fixed price or do you do like fixed price with maintenance or hourly or if you mind me asking? 'Cause especially if these are multi year projects I'm imagining.

[00:08:33] You you cannot make a fixed price for a 20 years project, no way. exactly. So our preferred stuff is I mean we we got some suggestion for a new functionality and we give a we give a rough price estimate and this changes also. It is clear, I mean from the side of the client they add to the scope because we are using semi XP pro type of development with relatively short cycles, we can say at the end of the cycle, okay, you have the right to the client have the right to add to the scope or removed from the scope, and we can say, okay, when you do this one, we can also evaluate the price, or say it will cost you so much more or so much less.

[00:09:21] Right, right. That makes total sense. I was you you say fixed price multi year project. I I I would assume the government would be the only example where you'd have something fixed price. yeah, even the government, I mean as I told you we w were yeah. No no we we we were we worked with government projects, I mean especially in Germany, police and Ministry of Education. And they understood that it is in their interest to to have a s some flexibility in the projects. So we di di we decided that we will split it in smaller parts and they will put a maximum budget for the project. After that they will say stop, this is good enough.

[00:10:08] And this is how we work. Or the other thing with government. The other thing with government is this that from year to year they have different budget. So if you start in this yeah, so you can switch to the next year's budget. Do they insist on any methodologies like waterfall for your work or are they pretty hands off or? At the beginning they ask questions normally. we explain away how we worked and they normally say okay because they don't don't understand what we are telling them. then yeah. yeah, I was just say gosh, what was her name? Who's who just recently passed away who did the Apollo code?

[00:11:00] yeah, the lady. yeah, yeah. I've I'm very bad with names, sorry. Yeah. Yeah, yeah. yeah, she recently passed away. She was like 80 or something. Yeah. But I I was like I could see why they did Waterfall because their programming was all hardware based, essentially. So like they had to like build out it wasn't like s they call it software, but I wouldn't even call it software because it's all built into like the hardware itself, it sounded like. but if you I don't know y have you been in Goddard Space Flight Center? okay, if you look at the manuals, I I've seen the the real manuals from Apollo. And they you see that even they did not work really waterfall.

[00:11:52] They they made each requirement in a waterfall way. But the requirement after requirements they were quite actually flexible. And ~ this is why actually we brought people on the moon. If they were i doing real waterfall, I think we were still I guess I guess I meant you can't change the code once you send it into space. Like I'm I'm sure now you c go ahead. Apollo 13. They changed the the code on the way. really? Okay. That's how they got away with thr with okay. it. Yeah, yeah, yeah. Yeah, that's fair. So

---
Custom Build Systems & Workflows
---

[00:12:36] yeah, let's talk about with your small team how what kind of tools have you picked up or used to help like automate a lot of what you're working on? well besides the obvious stuff like Xcode and Swift and so on for the for the modern development and unfortunately Eclipse for still for the Java development. many of the tools we wrote ourselves, for instance, our build system is completely custom-built. It's based on Git. But we started using Git the time when the submodules were crap. So we decided okay, yeah, but not so I mean less crap now. Okay, let's crap. So yeah, so we we started we we we basically made our custom build system.

[00:13:29] And Custom build system or custom version control? No, build system. It's based on it's based on Git, but we have I mean 100 repositories or something like this. And our build system basically picks up what you need and the version you need and so on from for the for different projects. And also make also makes the package installation packages everything. So it's I know that sounds primitive. But actually it works very, very well because we can run also the tests there and all kinds of stuff with this build system. And it runs all automatically all the night when when you have some changes and so on.

[00:14:14] So it's quite flexible. we we love workflows and workflows are both types. I mean we have work custom workflows for for things like the build system, of course. But also most of our projects are workflow-oriented. And we are thinking a lot about the APIs. And we're trying to make the APIs as independent as possible. First of all, I mean, for instance, if you take if if you take, for instance, the the Dutch project, the banking project, I mean, the we cannot control the external APIs. So what we're what we are doing is many years ago we just Just an example, many years ago we enhanced the plist format, Apple plist format.

[00:14:59] we call it PixML, and I have no idea why we called it PixML. And we have a workflow that basically takes any any type of entry in the system, convert it converts it into PixML. We if the If the information has to be persistent, we store it in a database. And we have a mapping file that says, okay, this PixML have to go to the database that and that way. And then if we have to export it, we get the same way. I mean, convert from out of the persistent storage to into the PixML and then again to whatever format we have to proceed. And we we are doing these workflows basically completely independent.

[00:15:43] not one program directly takes from the other and so on. There is a workflow controller that makes this work after kick kicks different independent project after each other. And the reason is this makes also the the entire system extremely debuggable. You can run run just one module without having to test the other modules and so on. That's Yeah, that's pretty amazing. just an example for this PixML, for instance, the for the Monet project, the Monet is the the the robotic observatory. I mean we use the same format, the same PixML for logging. Like every event, I mean the telescope moved, the dome opened, the camera made shot and so on.

[00:16:27] All the events were we are logging, but also we had a very good debugger where you send we see Graphically, something like the old Core Data editor. We see graphically how packages come from one application to another where they're bottlenecks and so on. We can measure the queues and all kinds of stuff graphically. And this is actually we there was another project, two other projects trying to make the same stuff, one in Berlin and one in MIT. And we We were the first one to finish it because actually they didn't have the graphical debugger. And this is a very complex system and it was for them a nightmare to debug the system.

[00:17:11] But if you have such a if you have such a flexible workflow and you see what you're doing, you see immediately also your problems. Yeah, yeah. That's pretty cool. so I am legally obligated to ask, because it's twenty twenty six, how has AI changed the tools you use or any of your development process? we do not use AI for core development. We use the AI for writing documentation. Okay. And when I say documentation, first of all we are documenting our source code for ourselves. not not for clients, for ourselves. So basically when after two years I have to make a fix, I understand what I've done.

[00:18:00] Yeah. And we we discovered that if you make this thing, then the AI can produce also very decent documentation that is also for the public. We use AI for simple things. I mean, if you want to make a button from red, to switch the button from red to green, obviously AI does a very, very good job. But for instance, we are working now one of the our projects is an open source standard for describing observatories that we just announced last week in a conference in Armenia. And when I started or when we started working in this project, I mean we we asked the AI well can you help us? And produce complete crap because there is no example from where the AI can learn about it.

[00:18:52] You wanna I wanna deep dive into that 'cause I'm really interested. So what what was special about what you were doing the AI was not trained on it? As a technology, nothing special, but as a as a idea to have a single system, single standard that describes any possible observatory, astronomical observatory, it doesn't matter on Earth, around Earth, on the moon, Mars, and so on. this was a new idea, basically to use a single standard. And if you go to say to astronomy portals and so on, there are hundreds of different API standards, discussions, papers, textbooks and so on, and the AI was not able to extract a single simple solution.

[00:19:41] So you were basically saying, Hey, you you were using this to build this standard. Is that correct? You were using AI to build the standard and you told it here are some observatories and here's some here's some ways that it's currently described. Like across the board, and you said, Hey, take these and build the standard based on what people are currently doing. Ex exactly. Also papers mean describing what is a astronomical photograph formats and all the stuff. Okay. So there is a lot of information that you can feed, but if the AI does not have a example of how to build exact concrete this concrete system, it does not do a good job.

[00:20:31] The where the AI helped us is for instance testing. Yeah, right. make test examples and so on. For this one, it's very, very okay. Another thing that we are trying to avoid in many cases AI is actually by for thinking about the next generations. I'm afraid that you have to be able to ask the AI good questions to get good results. One hundred percent. Yeah. We just talked about this, I just talked about this with Stewart Lynch, just like Yeah. and Anthropic even has a p paper on it, like the more you're an expert in a subject, the more you're gonna get out of it. Yeah. will get the students from today experts without they have no experience?

[00:21:21] So I was I was watching just a couple of months ago, I was watching the I forgot his name, the guy who d developed main developer of the SQLite. Okay. And no no sorry, I I'm thinking for Bob Ma Bob Bob Martin, Uncle Bob. I was watching an interview with him. tweet? No interview on YouTube. Well there was a tweet he said and I don't know if this is what you're talking about where he's like I'm not gonna look at code anymore and I'm just gonna have AI write it and merge it. Is that what you're talking about? no, no, no, no. He was basically talking how how when he's teaching y he was asked how he teaches young people.

[00:22:04] And he his answer was I teach them like I'm teaching Canadians. So basically I give him a concrete job and ki they have to learn how to do this job and then the next time it's a little bit more complicated job, but they ha do not have to touch AI. then somewhere in the middle of their education they can already start using a little bit AI and so on. And I think this is a very good idea if we if we want to have, I mean if the company have to continue further and have good developers, this is a very important thing. I have so many thoughts about that. What if the company doesn't care about good developers?

[00:22:46] That's unfortunately gonna be a big part of it because it's just push, push, push, right? Can you have a twenty years project without good developers? yeah, I mean it'll never succeed. It'll never succeed. Right? Right. Yeah, yeah. Successful, well that's you know Yeah. we don't always want a successful project and software, so Okay, yes. if you want to waste money you can of course. Right, there you go. what was I gonna say? Well the other the other thing too is I I I'd love your input on this, but one thing I've thought of is how there's like levels of abstraction with programming and there's certain

---
AI Without Losing the Expertise
---

[00:23:30] levels of like how close you are to the hardware. So for instance you have like electrical engineering, right, which is very into the wiring. You have computer engineering. Which builds on top of that. You have computer science, which is where I'm at, for programmers, right? And then it almost seems like now, the agentic stuff is a layer on top of that. you'll always need people to build the code. And then you'll have people who'll just use agents and depending on your level of expertise and interest, it seems like that's the way it's gonna go, is we'll have to have another degree or something on how to use these injected tools.

[00:24:09] But we still need computer science people for building the original code that doesn't already exist in a way. again, it is very important that the people continue learning not only programming but also their domains. For instance, for this for this project that is the the exabyte project, we had to understand how how the a disk is damaged and how to pre prevent a file to be corrupted. we had to understand what happens if somebody just kicks the power cable and the the the in the middle of write operation goes down and so on. So these are these are things that It is very important even on the software level to to continue understanding.

[00:24:58] But also percent. also thinks for instance, many people are making I don't know if if you have you worked with MongoDB. I mean MongoDB works for yeah, MongoDB for 90% of the time works okay, and then it starts replicating or what whatever, and you can forget it for six hours. And one and one of our intelligence. is always we don't have to be the fastest in the but we have to be the most predictable and how and how and how to explain this type exactly exactly these are th these are yeah right? yeah these are these are exactly things that you have the core it is very important the core to to really to put your thoughts and your dive into the source code.

[00:25:47] And then the periphery, the APIs, the stuff and so on that is not so important. Then you can let the AI help. Yeah. we're not like I am less and less convinced we're ever gonna hit AGI to where you have AI that understands deep knowledge of astronomy while at the same time being an excellent Swift developer. I think it's just really hard to do that. So yeah, you need like you almost need to use separate agents and they need to be really well trained on on the data to to understand what's going on. Yeah, totally one hundred percent. I I mean an another thing is for instance we're trying I mean the pip my colleagues, we're not we're trying not to work eight hours a day, although sometimes you have to, but we're trying to spend at least hours a day.

[00:26:38] Is that what you're trying to say? Less than eight hours and spend the rest of the time in reading. For instance, early in the morning, I'm well, in the morning, not early, when I wake up, the first thing I do is I just open a Nature journal or Scientific American, read it from the first to the last pages just to see what's going on in the world. And d this helps a lot. This helps more than actually reading the f Swift four point one version and see what are the differences. Yeah, right, right, right, right. Yeah. that's that's the thing I'm afraid of most with AI is that since there's less financial incentive to be intelligent and smart because we can outsource it to these tools, that there's gonna be less of a drive for like education and expertise.

[00:27:34] because it's not financially necessary anymore, right? So it's like, yeah, that's kind of what I'm worried about. as well. we've already seen issues with literacy going down and stuff like that. So yeah, it's not great in that aspect. yeah, was there anything else you wanted to mention about AI before we get into Swift stuff? Well, I think that I mean it will evolve and it evolves very fast and we have to another thing that it's very important is I mean we are kind of We claim at least that we're smart people. So we should at least understand how AI works. We should have a basic understanding behind the maths.

[00:28:18] I mean you have to know what is a matrix operation, how the Markov chain are working, and so on. To understand why to understand the behavior of the AI. So like we we understand how the computer works, we understand how this memory and CPU and GPU and all this stuff. The same is true also for AI and and unfortunately this is because the math is, especially if you go in deeper in the field, is quite complicated. very few people actually go that deep and they do not have explanations why something works or does not work. Yeah. Yeah, I think that's totally correct. Is understanding the technology.

[00:29:02] I I think that helps using it the tool as well. yeah, totally.

---
SwiftNIO, WebObjects & Missing Plugins
---

[00:29:08] okay, let's talk about Swift. So you mentioned Java and WebObjects, but you also have some server side Swift stuff as well as client side Swift stuff. Is that correct? yes. So how does that how does that set up work? First of all, for the server side Swift, we're using SwiftNIO. And we start building on top of SwiftNIO, we start building some extra functionality that makes it a little bit more robust and more easy to use for everyone. And we're going also to make it open source when it's good enough. it is very different from what is Vapor or Kitura and all these existing projects because because of our way of thinking that we inherited from the WebObjects.

[00:30:01] So we always try to think very deeply about two things. The first thing is the monitoring, the predictability that I mentioned before. So before writing any any line of Swift, we start thinking okay, how many transactions this has to be, how does it have to be a 24-7 and so on, and all these questions that you have to answer. And then you choose the technology or choose how you're going to do. For instance, if you if if you're working in a batch data, which is quite often in the industry, batch files, you don't have to Make the the trouble to have the trouble to use SwiftNIO. You can do just very simple Swift tool that eats something and produces something in a classical Unix way, pipeline way.

[00:30:56] Of course, if you have to answer HTTP requests, then we use SwiftNIO for these type of things. for there are many cases where we have to talk to different interfaces. We don't have to talk we don't have persistent data but we have to talk to different interfaces ours or or for third parties In this case with SwiftNIO is extremely good. I mean the the application the applications are very sm very small. For instance for the telescop server we have just launched one news provider service and the it is Basically, it's like a real-time blogging system. And the the memory footprint is about 60 megabytes.

[00:31:47] Where if you write the same stuff in the in a Java, it will be probably one gigabyte. So yeah, and all the stuff with the garbage collection and all the problems there. So for this type of thing, Swift is extremely good and extremely fast predictable. What we are missing with Swift unfortunately is the dynamic loading that we had in Objective-C. Loadable bundles. Yeah, so how do you get around that? Well, with ugly tricks. Depends on the pro- I mean how first of all we are controlling our stuff, so we don't really need to have for our own systems to have loadable bundles. Right. just compile them.

[00:32:30] But I'm I was talking to to engineers at Apple about this problem, and they told me that they know about it, and they will actually probably allow something like this if you give them a good reason for. For instance, we're working on a astronomical image processing application. And we we understand very well 2D 3D images from telescopes, but we have no idea about image processing of say gamma ray bursts and I mean gamma-ray satellites. So there are a couple of folks at Caltech and MIT that are gurus in this subject. So for them, will be the best if they wrote write their own plugin. And Apple say that In this case they will discuss with us and probably they will give special enhancements but case by case.

[00:33:27] Yeah. Have you looked at so this is macOS, correct? Are these apps in macOS? macOS, yeah. Have you looked like ExtensionKit or anything like that Yeah yeah it it solves many of the problems. not all. Okay. Yeah. Yeah, that totally is something that's that's missing. It's just being able to create a plugin system or something like that. Yeah. yeah, I I totally get it. what do you write in your new so your all your new projects are Swift only, pure Swift? No, we are using, as I said, for persistent for persistent data, say writing to Postgres and so on, we are using still WebObjects because of the EOF.

[00:34:21] Okay. also we we prototyped from time to time when we have to just understand the pro problem. We might have also a prototype in Python or we have a lot of shell scripts. Some of them are already written in Swift, but most of them are still real shell scripts, old shell script bash scripts. Remind again why are you using WebObjects? EOF, this is the processor of the Core Data. Okay. And it is works with any database with any I mean it's extremely sizable. I mean our database is you you the first time that we've seen how a long integer got suddenly negative in a database by the the prime key. It was already 15 years ago, so we really use huge databases that Core Data and so on cannot manage.

[00:35:18] Got it. Okay. Okay. so what parts of your code do you share between the server and the client? for instance I'll give you an example for instance for this exabyte. For exabyte we started writing some examples. for instance photo archive. It's first for us, but also we want to use it also for our astronomy imaging. So the the access to the files Basically the library that accesses the files on the server and the client site is the same, virtually the same. Mm. Because the models, the models, I mean the model part of the data is very sim either the same or very similar.

---
Exabyte Storage & Sneakernet
---

[00:36:06] well, since you brought it up, let's talk a little bit about the exabyte stuff. you did a really great talk. That's where we met at ServerSide.swift a couple of years ago. I'll post a link to the YouTube video. But the primary purpose of that top talk is explaining large storage. Now what what are we when we're talking about large storage, what exactly are we talking about? well we never we never had the the financing for such a large storage to be developed, but we made basically prototypes and expi ex experiments that should in theory and we're quite convinced actually in practice too will scale scale up until say fifty hundred exabyte.

[00:36:52] So really large yeah, yeah. exabytes. How many terabytes is that? fifty or hundred. Yeah, one exabyte so one exabyte is thousand terabytes. Wow. Okay. And these are all photos. no, it could be for many for instance the these type of projects they have to sell solve in say NASA in CERN in government and so on. There are many places, I mean obviously Apple have to solve also these type of projects and so on. the the the other things that we were thinking at the time because we we start developing this one. We we started this is the third version of our data archive. I mean the first version we started already 25 years ago.

[00:37:40] And then we are using currently we are using the second version and now we are slowly migrating to the third version. And each time it gets 10 times or 100 times larger and faster. so The the the reason that we started this is actually we would like we w we would like to collect the information about space junk. And there are observatories that are somewhere in say in Namibia or somewhere in the mountain mountains of Chile or so on and so on, where they don't have a lot good connection, internet connection. So even we designed and tested small basically hardware pack that will c harbor about half or one exabyte of data that we can just put close to the observatory and then we thought okay probably they will not have also continuous power supply because of weather and so on and so on.

[00:38:34] So we have we have to feed this in this with electricity also with solar panels and batteries so it has to be extremely well done for power supply and so basically this means also that we we the disk that we are not using it's turned turned off the computer that is not used is turned off and then turned on and so on and so on so just to yeah yeah yeah So and of course when you think about now for these gigantic data centers where ever everything works at the same time and no one thinks about the power supply, actually these type of thoughts are actually very could be very useful for them too. Yeah, right.

[00:39:19] one of the other things you mentioned was like data transfer. So it's a real is it like some satellite system that's really slow or It's too s anything is too slow. I mean, for instance w for one of the telescopes that we were modeling, it is from a Fren Austrian company, Assel, they have like a four four 60 centimeter telescopes and on the same mount and make at the same time for 25 six megabyte images and each image takes three seconds so you you can imagine what output this this machine gives so there is no there is no no cable that can transfer so much data. So what we were thinking so so sneaker what do they call it?

[00:40:06] Sneaker transfer. Gosh, what is that called? Is essentially how you're transferring data. Is that basic basically w when when we thought when w when the the storage is full we replace it. We bring the storage back home and transfer the store the that data at home and then put a new storage there. Yes. Okay. Sneaker net, where it's like physically physically you have to take the hard drive. Is there I this okay, this is like a stupid question, but I'm gonna answer ask it anyways. Is there like an API for something like that where you can be like here, we need to transfer this hard drive and it just basically like s sends a message to somebody to pick it up?

[00:40:52] Well there the we have a monitoring KPIs obviously and we can see okay when it's eighty percent full we have to start planning the transfer. Okay, that's how it works. Yeah. Okay. Yeah. APIs. for instance there are already established APIs for the for the UPS systems for all kinds of stuff. There are many, many already existing APIs. Got it. Okay. wow, we talked a lot a lot. This was great. Was there anything else you want to talk about before we close out? Yeah, I mean at the moment because we're finishing several large projects and we were we kind of would like also to work again with other clients and because we have expertise in that we never tapped on for instance in the in healthcare in in satellite say remote sensing, agriculture and so on, we're at the moment looking also for new new partners and clients so that we can learn something and they can have a solid system too.

[00:42:01] So you I I gave you I will give give you a URL to our website where yeah, yeah. So cool. and and pe and people just can drop me an email and so on and if they have questions Yeah. Georg, thank you so much for coming on. This was fantastic. you can check out his website, tuparev dot com. and we'll have links to all your socials and stuff. but this was really great. I enjoyed this. thank you for the invitation. People can find me online at brightdigit.com. if you're not, consider joining our Patreon to get early access to episodes like this. and if you enjoyed this episode, please like and subscribe on YouTube or give us a review on whatever podcast player you're using.

[00:42:48] Thank you so much, and I look forward to talking to you again. Bye everybody.