go podcast()

Dominic: 00:02

Hello there. I'm Dominic Senth Pierre and you're listening to Go podcast. Today I'm joined by Lee Antony. And guess what? We are talking about whales.

Dominic: 00:17

Before we dive in into the interview, I'd like to remember, people that there is a channel for the Go podcast, on Slack. So if you are, you know, member of the Slack community, you can join. It's Go Podcast in one word directly like that. So, yeah, not much there. I'm not really good at maintaining, that kind of community and whatnot.

Dominic: 00:42

But I mean, yes, maybe, maybe some people will will will do the the talking, I guess, or I don't know. I'm looking at, at guest as well. So if you, you know, if you have a nice story to, to to talk about related to Go and things like that, you know, just reach out. I'm, I'm always looking for that. You know, that this is, the interview with Lee.

Dominic: 01:07

Hello there. So I have a guest today. I'm with Lee Anthony from the Wells project, actually. Thank you very much for joining me, Lee, today.

Lea: 01:16

Yeah. Thanks, Dominik. It's really good to be here. How are you today?

Dominic: 01:19

Very good. Very good. We have a crazy, hour, difference. So I mean, it will be it will be interesting. My English might be bad at at those hours.

Dominic: 01:28

I I'm in 4 PM for me. So, yeah, we will see how it goes, but hopefully you will you will talk most of the time.

Lea: 01:35

Well, my brain is generally bad at this summer day, so I think we're probably equal.

Dominic: 01:39

Nice. So I I you know, I would, I would guess, you know, most of the golfers already heard your name or at least they heard the project well. But I'm I'm interested a little bit about yourself. You know, what, what is your background? How did you, came across Go and things like that?

Dominic: 01:57

You know, what what can you tell us about yourself a little bit?

Lea: 02:01

Yeah. So I'm originally from a a country called Wales. Complete coincidence. I was exposed to technology fairly early. My father was a electrical engineer.

Lea: 02:13

So I grew up in a house with, you know, PCB, etching tanks, transistors, components, and this stuff was like alien technology to me growing up. I was so fascinated by it all. A bit later on, we had our first computer, which is a Mattel Aquarius. So you know Mattel, the the toy manufacturer?

Dominic: 02:34

Yeah.

Lea: 02:34

Yeah. They actually created a computer early on. I think it was like 32 ks or something. Maybe it wasn't even that grand. So yeah, that was my first exposure to BASIC and to programming.

Lea: 02:48

Around that time home computing was just starting and so you'd get TV programs, where you know you were introduced to basic and, you know, made blocks move around the screen and stuff. And honestly it was just it was just so fascinating to me. A bit later on, in my early teens, I got a Natario ST. I became interested in, 68 ks assembly for some reason. So I started learning that and I got sort of dipped my toes into the demo scene a little bit.

Lea: 03:16

So, yeah, that's kinda like my my programming background, where it all started. Beyond then, when I got into sort of career, I was introduced to, you know, object oriented programming, c plus plus Java, Python, all of this sort of stuff. And it's interesting that during that time, to see how software engineering has evolved. Like, object oriented programming back then was the, you know, the silver bullet of of software engineering. I'm not so sure these days, you know, I think things evolve.

Lea: 03:50

Yeah. So being introduced to sort of concepts, programming techniques, all that sort of stuff. It was interesting to find what I what what I found really frustrating about that stuff. Give me an example. So c plus plus, you know, really powerful, really good.

Lea: 04:07

But the tooling around it was incredibly frustrating. You know, having to decide which header file to to bring in based on, you know, which operating system you were compiling for. Yeah. All of that kind of stuff. I found that very frustrating.

Lea: 04:23

Same with Java. Although, I found sort of like the the layers and layers of abstractions extremely frustrating too. So, anyway, this is relevant. I will eventually, I managed to find Go, basically. And all of the frustrations that I found in all of the other languages and even in kinda like the way you approach software development, I felt like Go had really good answers to all of those things.

Lea: 04:48

And so yeah. So I think it was about 2016 I started becoming, more interested in the language and getting to know how that works. Yeah. I I thought it was just this amazing cross point between, you know, the job that you need to do as a as a software developer, and, like, how much you're willing to invest in the time in doing it. I just thought it solved so many problems.

Lea: 05:12

So I'm a I'm a huge fan.

Dominic: 05:15

Yeah. Pretty cool. So what what was, the the electric electric, engineering part of your decision at some point? Because, I mean, before you started programming, was was that was that on the table for you? Did you, did you add any interest in in that at all?

Lea: 05:34

Yeah. I did. Yeah. So when I went to college so in in Wales, you have, like, school up to 16, and then you can choose to go to college for a couple of years. And then I guess what you'd call college, in the States and maybe in Canada, we call university.

Lea: 05:48

So in that 2 year gap, I did a course, called soft engineering, micro electronic engineering. There's some really cool things there to do with, like, building hardware and interacting with that using computers. So, yeah, I think I think it was one of those things where I I could've, but I was way more into the software. So that's kind of like what I did.

Dominic: 06:11

Nice. So is is that is that still part of your interest these days? Because I you know, with with Raspberry Pi and whatnot. I mean, the the hardware things, the Arduinos of of and the kind of that. Do you do you play with that, at the moment?

Lea: 06:25

Do you know what? I'm one of those people who are very guilty of having a graveyard of Raspberry Pis in the, I've got I think I've got every model, and I think I've probably used one of them once.

Dominic: 06:34

Yeah. Yeah. Yeah. Same. Unfortunately, yeah.

Dominic: 06:38

I don't know why, but but they are so cheap then. It might be the reason.

Lea: 06:41

I know. It's one of those things you think, well, it's, you know, it doesn't cost you much, and it would be really cool if I did all this stuff. And then you realize that the one thing you don't have is time.

Dominic: 06:49

I know. I've, I've been, I've been, telling, my, my young, younger kids, you know, we, we will be a build at some point a kind of a, an old, arcade, you know, machine or whatever, whatever you want to call that. And, Yeah. Unfortunately, it's still it's still there. The the components are there, but I like you said.

Lea: 07:12

Yeah. I hear you. I I actually did build a I did get an old arcade machine, case. Sorry. Cabinet.

Lea: 07:18

And built yeah. Built out a a a a Raspberry Pi based arcade. And then, you know, just like there was an update. Something went wrong. Eventually, I just went on to AliExpress and found a a box that I could just connect a a monitor to and and controls to, and it all worked.

Lea: 07:34

So Yeah. You know.

Dominic: 07:37

Oh, yeah. Totally. So so you you dabble a little bit in in Java and Python and things like that, and you found Go. That that's interesting. So are we talking career at this time?

Dominic: 07:48

So were you were you working in, in a company that that that were using Go?

Lea: 07:55

So no. At at the time so when I first started with C plus plus that was, yeah, that was for a company that worked with the oil and gas industry. And my first project there was to take a standard, which was released by a company sorry, an organization called POSC. And this was like the world's largest data model at the time. The what that involved is reading the standard generating code, to create an application that would do automatic DB migrations.

Lea: 08:24

So that was a really interesting experience in in learning all of the weirdness of c plus plus and also software engineering as well. Applying OOP principles to to that was kind of interesting, and opened my eyes a little bit to to what's good and what's not about it. Java, professionally, Python, sort of used that in my own business, and I also used it for the time when I was a system administrator for about 7 years. So using it for tooling, automation. Yeah.

Lea: 08:57

So that's pretty cool. My my next job involving a programming language, let's just say was Node, actually. So yeah. Understanding the intricacies of using what I would consider a reasonably bad language for back end, and all of the problems that come with everything being async, yeah, that was difficult. So, yeah, it was actually because of that I looked for a different language, and that's how I ended up in Go.

Dominic: 09:29

Nice. Yeah. Yeah. I, I I lived the, the back end. The it was it was like the the callback hell back back then.

Dominic: 09:38

When I discovered Go as well, it was, it was from Node myself. And, I I I woke up at some point. I I was working in a in a in a startup, a small a small SaaS. And I woke up at at some point, and I said, you know, I'm rewriting that in in Go right away.

Lea: 09:53

Yeah. I think I think Go really lends itself to to to that kind of scenario, you know, where no developers can kind of get get it quite quickly. For me, I think I was building an application for, one of the US government departments, and they reported a bug and I just couldn't reproduce this bug. Every time I step through it to make sure everything was good, everything was good. I just couldn't work it out.

Lea: 10:18

Turns out it was a race condition because of the asynchronous nature, it was a race condition. And the debugger just was masking this, because of the timings. And, yeah, that was something that really, really stuck out to me. Like, yeah, this isn't great.

Dominic: 10:34

Interesting. Yeah. Never never really really thought about race condition and error like that in Node.

Lea: 10:40

But

Dominic: 10:40

yeah, now now that you are open opening this, that that's pretty interesting. So no no desktop application so far if I'm understanding that correctly. Right?

Lea: 10:54

Correct. Correct. Interesting. So how do yep. So how do we get there?

Lea: 10:57

So, my interest in Go, had started, and I was really keen to learn it. I was really keen to understand it and how it worked, in a really deep dive. And at the time, I'd just taken a new job, and it was basically an hour and a half commute each way. I spent time on the train and trying to understand Go, deep diving it, understanding it more, really getting into it. And around that time, I got interested in, like, offline backups.

Lea: 11:28

And I discovered a program called Rustic, which was written which was written in Go. I think, yeah, most people are fairly familiar with that. The thing that frustrated me was there was no decent UI for it. So, really all I wanted to do is just build a UI for Rustic. And because I'd done a lot of front end stuff, in startups, in the node startup, I kind of want to use that technology.

Lea: 11:51

It seems sort of like, you know, best fitting for for my skill set at the time. And I just couldn't figure out a way of doing it. Monday, I stumbled across a library called WebView. And what that is is a it's a c wrapper that wraps the native HTML WebView renderers, on Mac, Linux, and Windows. And I thought, oh, this is good.

Lea: 12:17

I wonder if I can interface this with with Go. I wonder if I can use it from Go. And they did have a, I think a Go library, like, to be able to use it. Like, what do you call it?

Dominic: 12:28

Binding?

Lea: 12:29

Binding. That's it. It's too early. It's too early for me to do it. Oh, yeah.

Lea: 12:34

They they have a good binding frame. So I started looking into that, and it it it worked reasonably well. There were some bugs. But one of the things that I found quite quickly was that, you know, it's very low level. There isn't a good way to communicate between the front and the back.

Lea: 12:51

You know, setting up a project is, you know, cumbersome. You know, I'm basically copy and pasting my my my code. And I started, for some reason, kind of thinking about developer experience. And this wasn't with the intent of releasing it. This, you know, wasn't with the intent of creating an open source project.

Lea: 13:10

It really was just, that theme that I guess I've had throughout my life in software engineering, which is just kind of trying to address frustrations. Go Go itself addresses a lot of the sort of build frustrations that I had. But when it comes to actually doing something, you know, actually creating a piece of software, I really wanted to address the frustration of all of that boilerplate stuff that you needed to do. I was quite envious of the, the Ruby on Rails project. I I thought that was really good, not necessarily technology wise.

Lea: 13:47

I mean, maybe it is. I I just don't know. But I think in terms of the developer experience, I thought it was I thought it was really good. So I kind of wanted to emulate that, for this little, you know, side project that I started. And, yeah, that's where the name comes from.

Lea: 14:04

So it was kinda like web view on on Rails. Nice.

Dominic: 14:10

So yeah. Okay. So that that that's cool. So what was what was that actually? So when you say you you wanted to to redo this a little bit.

Dominic: 14:21

So were you looking at a new library instead, instead of the, of the web use? What, what, what were your plan at that time to, to output some kind of, of, you know, front end web application from from a go back end point of view?

Lea: 14:36

Yes. There's a couple of problems that I need to to to address. One was, like, how do I get assets? You know, HTML, JavaScript. How do I get those files into the into the thread?

Lea: 14:46

Because we're not we're not talking about a server. We're talking about just a straight Go program with no with no, like, network, stack connectivity. So that was the first thing I had to try and work out. And the interface between the web views and, the host, we'll call it the host, at that time is well actually and still is to to a lot of degree mainly just passing strings. So the idea is that you can, you know, you could run, you know, window dot print or you could run, you know, console dot log from the host to the web view.

Lea: 15:21

And the web view has the capability of posting strings back to to the host. And so I found that to be so so so really the first problem there is, like, how do I make this, easy? How do I have some sort of protocol built on top of this that makes my life easier so that I'm able to have that two way communication? And I think another key thing to to talk about here is that that communication is asynchronous. So there is at that time anyway, I think maybe WebView 2 has some synchronous calls now.

Lea: 15:56

I think that technology space has has developed quite a lot. But at that time, it was all asynchronous. So, like, how do you call something and then wait for a response? You know? How do you make that a bit easier for the developer?

Lea: 16:09

Because I've already been in Node Hell already. I don't wanna have to reproduce that in in Go. So, yeah, so that was the first thing, that I did. And so to to solve that, I really basically developed a protocol which was, in JSON. So when you send a message to the to the back end, it would have, you know, like a method name, and arguments.

Lea: 16:34

And then I utilized, JavaScript's promises, to to kinda reflect what was happening on the back end. So if you wanted a synchronous call, you could call I don't know. Let's say, a classic one would be greet. So So I wanna I wanna call a greet function in go from from the front end. You'd you'd pass a message with, you know, the function name is greet.

Lea: 16:56

I'm passing the name, Dominic. And then go would return a string, and that method would also return an error, in the signature. But that would obviously return, you know, hello Dominic as a string and a nil error. And what I did then was map that to a JavaScript promise. So it was kinda like, yeah, kinda like utilizing JavaScript's promises to to be able to understand whether the back end was was erroring, whether that function was erroring or returning you a value.

Lea: 17:28

That was the first major major well, that was the second major thing I had to address after the assets. Yeah. So and once I got there, it was, a case of releasing kinda like the the first version. I decided to open source it. I still don't know whether that was a good idea.

Lea: 17:42

I'll be honest. It's it's it's it's taken an awful lot of my time, this project. But, but I I think it's good. I think it's good. I think I've seen some amazing things, you know, happen with it and people pick it up and run with it.

Lea: 17:56

And I don't know. It's I think it's one of those things you look back on and go, you know what? It it was worth it. It was worth it. It's good.

Dominic: 18:05

Well, yeah. It is. I I I suppose you can you say that you don't have a choice today because there seems to be a lot of people. But let's unpack a little bit of what you just said. I'm not sure I'm fully understanding.

Dominic: 18:18

So are you saying that at this moment with with the current version of Wells, you are still using promises to kind of handle errors that are returned from the go function? But so, so from, from the JavaScript point of view, it's, it's, you know, it looks like an async call, but even though it it's just to, to have a good way to handle the value returned from the go function and the error returned from the go function?

Lea: 18:49

That's correct. Yep.

Dominic: 18:51

Interesting. Okay. So, so, so it's completely async. So you can, you can call both ways, I guess. So can you call also a function from the Go code?

Dominic: 19:03

Can you I don't know. Can you broadcast some kind of message to your your your JavaScript front end and say, you know, do x, for example, and that function reside in the JavaScript world?

Lea: 19:16

Yeah. Correct. You can you can call anything on on the Java on the JavaScript side as if you were typing in on the on the console in a browser. So it's probably worth unpacking what is what is Wales, I guess, like, because it's not, I guess, it's not just, you know, a a web for an end, and the ability to send messages because that's I mean, that's basically we're talking about version 1. It also comes with, a runtime library, which has a whole bunch of different things that provide, functionality.

Lea: 19:47

So one of those things, which you touched on there was events. So you have the ability to in Go or JavaScript to emit an event, give it a name, a string, which is the name, and any kind of data you want with it, and both sides will be able to pick up that event. So it's kind of like a unified event system.

Dominic: 20:09

Interesting.

Lea: 20:11

So you can call JavaScript from from Go using that. It's it's less so what I would say is that events are more kind of fire and forget. They're sort of like status updates. Like, if you're downloading a file, and you need to know you know, you need to to to be pinged what percentage it is. You know, events are really good for that.

Lea: 20:32

Where you want a more where you want to handle a value and and perhaps an error scenario, then calling functions is a is a much better better approach. And you can do that from JavaScript to Go. You can't so much do it from Go to JavaScript.

Dominic: 20:48

Okay. So so we have we have event. That that that's pretty interesting. So let me let

Lea: 20:52

me try to see if I

Dominic: 20:53

because I I've never built anything in Wells. So I'm I'm, you know, I'm I'm kind of a a newbie in in there. So so are you saying that, from a an application developer point of view. So there there's no there's no HTTP involved whatsoever in typical Wells application. Right?

Dominic: 21:16

I'm building a front end. I'm building the code in the back end, but it will not be called from an HTTP request. It will it will be called, you know, either from an events or from calling a function itself.

Lea: 21:30

Correct. Correct. There is no there is no HTTP involved. There's no network stack involved.

Dominic: 21:36

Interesting. Okay. So, so, okay. So this is, this is the, the, the, you know, the primary building block that we have when we are going to use well. So are you still using this, this web view component today?

Lea: 21:50

Correct. Yep. Okay.

Dominic: 21:52

Okay. Okay. So you you've built on the on top of that, you've built some kind of, you know, message messaging protocol that we are able to call go from Java, JavaScript and and vice versa. So what about, you know, what you you were mentioning that it's it's it's way more than that. And I I I I can, I can understand that?

Dominic: 22:13

So I understand that there's a couple of widget, or maybe it's not the right word, but let's say let's say there there is UI component that a an application developer can use. For example, I would I would guess the system tray maybe or the the the menu bar in in Mac and things like that. So do we have access to those things? And are are they are they native from, you know, from the OS point of view?

Lea: 22:40

Yeah. Yeah. Correct. So I think where we've got to in our journey on on what Wales is is kind of like version 1. Very basic.

Lea: 22:48

Didn't have any of that stuff. Just gave you a a standard window. Version 2 was released, in 2022, and that gave you the ability to control the window, a lot more. So like native menus, being able to resize the window, being able to understand when it's moving, you know, full screen, center, all all of that sort of stuff to control the the data window. That was all made available, yeah, in version 2.

Lea: 23:18

Inversion sorry. Go on.

Dominic: 23:21

Yeah. I was going to say that this so this code is cross platform, I would assume, and it's not coming from this, this WebView library. So you you you you wrote all of this. It it this is Wales.

Lea: 23:33

Yeah. Correct. Correct. Yeah. So one of the yeah.

Lea: 23:36

So one of the things that we found, with WebView is that there was there was a couple of bugs that weren't getting addressed, and I found that the speed of the project was quite slow, which is fine. I don't like you know, I completely get it these days. Yeah. But I think one of the things that I really wanted to do is to make sure that I was able to move as fast as possible and be able to implement things, you know, as quickly as I could. And so what I decided to do, and this really is like the the nerd part of my brain.

Lea: 24:09

I think, you know, I think I could I think I'd really enjoy doing that. I think I'd really enjoy, being able to write all of the c, objective c code, to be able to interact with the native, APIs to be able to do all of this stuff. Yeah. That was that was hard. Like, that was so hard.

Lea: 24:27

Yeah. But it was I think it was worth it. Like, you know, we we now have everything, you know, within the whales project. And yeah. So if if any of the, you know, new APIs come along, you know, we can we can try and add them in as as fast as we can.

Dominic: 24:44

Yeah. That that that's interesting. So okay. Let let's let's go back a little bit. So we were we were at version 1.

Dominic: 24:50

So version 1, it was, you know, fairly simple. We could call both side and things like that. So what what happened at this time? What were you were you sensing any any kind of pressure from the community? What what was what was the popularity of of the library or or the, the project at at that time exactly?

Lea: 25:11

Yeah. So I think I think the thing about version 1 was that it was kind of popular to a degree because it was so simple, and it was more of a library. I mean, unfortunately, for desktop application, you always need to have it own the main loop, because a lot of UI operations have to happen on the the main thread. So it can't just be a library in the in the traditional sense. So I think, yeah, I think a lot of the Go community kind of weren't really sure about it.

Lea: 25:42

You know, desktop applications, Go, really? I think that's changed a lot over the over the years. But for version 2, what I wanted to do was to increase the you know, improve the developer experience. And so a lot of yeah. So I think I don't know.

Lea: 25:58

I think at that point, I've I was just really driven by that rather than any pressure. I've I've never really felt pressured to do anything within the project. I think unnecessary pressure harms the project. Mhmm. So I think you just have to do with what you what you've got.

Lea: 26:15

And if that aligns with everybody else's, you know, requirements, then that's great. And if it doesn't, then, you know, everybody's free to free to contribute. It's a it's an open source project.

Dominic: 26:24

Yeah. Yeah. Totally. Were were you using, the project in in a commercial way or or it's it it always has been a, you know, kind of a side project for you?

Lea: 26:36

Yeah. So yeah. It's been a it's been a side project for me and my family. Yeah. Pretty much.

Dominic: 26:41

Yeah. Yeah. That's that's that's great. Okay. So so so we are we are on version 2.

Dominic: 26:49

We you know, you've you've added some, some some c call and things like that. So I would I would imagine that now that you rely on some c library, it means that we we need c go to compile the output of what Wales is is going to create.

Lea: 27:08

Yes. Yes. And one of the that is a challenge. But I think I think Seagull is I mean, it's I think it's a little bit better than than people think, and it's definitely a lot worse than it could be. I think the really cool thing and I I can't believe I'm saying this after kind of like my my background in and my background is like Linux and and Unix.

Lea: 27:31

But I have to say developing this for Windows is the easiest, you know, it's the easiest platform. Oh, yeah. I can't believe I'm saying this. And the the the main reason is because, for whatever reason, the the Go developers created a Cisco interface, which means that you don't need to use cgo. You can actually call all of the DLLs, which you know exist on the machine already Yeah.

Lea: 27:57

Directly. So for the Windows part, SQL's, you know, not really been a problem apart from, like, version 1. I've gotta give a big shout out to John Chadwick who created a library called the GoWebv2, and that really allowed us to use the webview 2 component, which had subsequently been released after version 1, was released. And that allowed us to, yeah, that allowed us to very easily integrate with with webview 2. It was kind of a bit of a proof of concept for him, so we helped develop that, some capabilities for that early on.

Lea: 28:33

Yeah. So on the Windows side, not no problem with the CECO. But, yeah, like, from for Mac and Linux, Yeah. Yeah. Very much so.

Lea: 28:41

We have the CECO.

Dominic: 28:42

Interesting. So is the when when you say that the let's say kernel 32 or user 32, what whatever the DLL that you are using, when you say it's it's already there, is it is it it's not part of the of the the standard library? I I mean

Lea: 29:01

Yeah. So Windows, for for better or worse, Windows has this huge long history of having these Win 32 DLLs, as part of the operating system. And so what it means is that you you can confidently call certain system, operations because you know those DLLs are preinstalled on the operating system. Whereas, let's say, Linux, you may have one version of a library, you may have another version of a library, the library may not even be there. And so it's much harder to to kinda handle those edge cases, because your target platform is so variable.

Dominic: 29:41

Yeah. Totally. So so I guess on on Linux you need to do some statically linking probably and include some more library yourself, or or it's during the build depending on what is on the developer system?

Lea: 29:55

Yeah. Yeah. There's no there's no easy answer to this. I mean, it's partly it's partly a distribution problem. So if you you could develop with the the library.

Lea: 30:10

You could install the libraries locally. You know, you can you can link against them and stuff. But but how do you know that those libraries are gonna exist on the target platform? And the answer is you don't. So, yeah, it's a distribution problem.

Lea: 30:21

Either you're gonna have to, like, create dev, you know, dev files or, dev packages or RPM packages or even something like app image, that allows you to kinda ship the DLLs with it or, you know, shared libraries with it.

Dominic: 30:36

Yep. Interesting. Okay. So so as a as a developer myself, do do do I need to do extra steps when when when it comes time to package my, you know, my my Wells application for multiplatform? Because I I I, you know, I I see that you you have you have a CLI and things like that, and it seems to be able to build.

Dominic: 31:00

Is it able to build cross platform, you know, from anywhere?

Lea: 31:08

Yes and no. So Apple have this wonderful legal clause where you can't use their SDKs on other platforms, and you can't redistribute them. So yeah. So there are so other projects have this limitation as well, and there are ways around it. Like, you can build your own Docker image using your own version of Xcode.

Lea: 31:31

But, yeah, for for the other platforms, you can compile to Windows from from either Mac or Linux, and obviously Windows. We do have a system to be able to compile Linux from Windows to Mac, which uses a Docker image. But, yeah, compiling to Mac is a problem. Yeah. I don't think there's a good solution for that yet, which doesn't involve a lot of stuff for the developer.

Dominic: 31:58

Okay. So if if I want to distribute my application on on Mac, I need to to have a Mac and and build there?

Lea: 32:06

So fortunately, GitHub Actions allows you to to build Mac apps. So you could do it through

Dominic: 32:11

through the app. Oh, yeah. I did not knew that. Wow. Mhmm.

Lea: 32:16

That's,

Dominic: 32:16

that's interesting. Okay. There there are so many things. Okay. So so where are we today?

Dominic: 32:23

So you, you were mentioning you, you know, you have integrated yourself with some, some C, library and UI component. Is there anything missing from from your point of view? You know, are are you using whales yourself to build any kind of application?

Lea: 32:45

Yeah. I normally use I normally use whales to to build applications to to, to trigger bugs, whilst I'm triaging bugs. That's my that's my main use of Wales these days. We do use so the company I work for actually uses Wales, internally for a couple of projects. And and so I I have done a bit of work with them on there.

Lea: 33:08

Where are we today? So version version 2 of the of the project, which is the the the current stable version, that provides a lot of, functionality as we've spoken about with terms of the window, in terms of the CLI tooling. In terms of kind of like hiding the build process, the complexities of the build process, which we've also touched on, it makes it very, opaque to the developer. So you you can just type in Wales build and and it will sort it all out. If you type in Wales package, it will create, you know, native, packages for for your for your system.

Lea: 33:43

So on a Mac, it will be a a dot app bundle. And for Windows, it will compile all the resources into an XE. So you just have this single binary that will that will run on these on these platforms. When when we got to a a particular point, with version 2, it it became clear that some of those benefits, some of those things that that kind of like the where we hide the complexity from the developer, they were kind of working against us. So

Dominic: 34:13

one

Lea: 34:13

of the things was, if we first talk about the the API. So so in version 2, it's very simple. Your your main program is very very simple. You you create an application. You give it some config.

Lea: 34:23

And in that config, you can you can say, you know, where you want your window to be, how big you want it to be,

Dominic: 34:30

what

Lea: 34:33

bundle where where your files are. You can, you know, configure some platform specific stuff, like on on Mac, you'll you'll have some options. On Windows, you'll have some options. And and then you run it, and that's it. That's that's kind of how it works.

Lea: 34:49

And one of the things we found was people kinda wanna be able to do things more programmatically, because that that kind of setup is it's really cool for a single window application, but it's a little bit fire and forget. For instance, you don't have a handle to that window because there's there's there's no concept of the window within the library. It it's kinda hidden away for you. So one of the things we wanted to address in version 3 was, like, how can we change this API so that make it more programmatic? So when we talk about a a window, you know, we need to be able to kind of address that as a separate thing to the application.

Lea: 35:29

And and really like a a system tray too. You know, if I wanna create a new system tray, it seems reasonable for me to say, you know, create a new system tray. You know, attach a window to it, attach a menu to it. Here are the callbacks. And to do that programmatically, config gets you so far.

Lea: 35:45

But, yeah, really, what we the feedback we got was that people wanted the the power and the control over how these things interacted. And, you know, good example is, you know, can we get a native window handle because we wanna add our own native widget on top of it like an overlay. Yeah. So that's really what we've been steering towards. Unfortunately, it kinda it kinda means that you're rebuilding it, like, honestly.

Lea: 36:17

Because you're yeah. Because you're you're taking the guts of what you've got and, you know, works, and you're kinda refactoring it and reframing it in a, you know, to a to a different API. Yeah. That's it's been incredibly hard work. We're getting there.

Lea: 36:33

So, yeah, that's that's kind of the direction in terms of the API we're headed.

Dominic: 36:38

Wow. Yeah. Okay. That's a major overall or at least a huge update. So so this this concept of Windows handle is common to Mac and Linux as well.

Dominic: 36:48

Because if I recall, I I did some, you know, desktop window development, in in another other other life. And, I remember that. But, but yes. Is is this concept also the the same on Linux and Mac?

Lea: 37:03

Sorry. Could you re rephrase

Dominic: 37:05

the question? The window you you were talking about the the window and all. I guess it's the the the kind of the ID that the OS knows that, you know, this this is a window that we are talking about. Maybe I understood the incorrectly. Or

Lea: 37:19

No. That's correct. Yeah. Yeah. It's completely cross cross platform.

Lea: 37:22

Yeah. So the same API will work, for for Windows, Linux, and Mac. Yeah.

Dominic: 37:28

Okay. That's interesting. So what about let's, you know, let's dive in a little bit inside the typical application for instance. So I would imagine that do do I have a a structure already where I can put some I don't know, you know, CSS and JavaScript file and things like that? Or, or it's more flexible than that?

Dominic: 37:55

You know, do, do you, do I have some standard already or when I, when I start an application or, you know, it's, it's mainly flexible?

Lea: 38:04

Yeah. So let's let's talk about that. Let's talk about what it you know, when you first create an application. So, as part of Wales, you get a CLI. And so the CLI, you know, you can you can create a, you can scaffold out a basic project.

Lea: 38:19

And there's a number of templates that we have, you know, with different front end libraries. So, you know, there's a React template, a vanilla JS template, you know, Vue. And when you build that out, you kinda have, 2 parts to your project. 1 is kinda like your front end, and that lives in a in a front end directory, and the rest is kind of outside of that. And that's just a standard Go project.

Lea: 38:43

The way that you can provide that those front end resources. So if you imagine like that front end directory, it's almost like you've done like a, you know, created a front end project using, you know, React, create, or whatever tooling you use. So if you imagine that as part of a normal front end build system, you would, you know, you'd compile it, you'd bundle it, and and you'd kind of end up with a bunch of assets. So you'd have, you know, JavaScript, HTML, CSS, and you'd, you know, you'd end up with those files. One of the early challenges in in Wels is how do I get that to the front end?

Lea: 39:19

And initially, that was just sending it by strings. What we've managed to do is reuse the concept of embed in in Go. So now you can embed, are you familiar with embed? Yeah. We yeah.

Lea: 39:34

Yeah. So one of the things that embed does is it gives you, it gives you an FS object. So what what we've done is we've been able to use, an FS object as the source for your assets. So it's entirely up to you how you create that. By default, you know, we we have it integrated as, as an embed line in in the code.

Lea: 40:00

So you have, like, you know, var assets is, as an embed.fs. And then, you know, you include in the in the comment above, you include the the distribution directory of the front end. And so basically that will just take all of your front end files, bundle it all up into an into an asset f s. And Wales will accept the the FS And then anytime it requests, a file, it looks for inside that, FS bundle. So by default, like, it's kind of set up for you, but it's flexible enough that, you know, if you wanna use something else, you can.

Lea: 40:35

I do know one commercial, one commercial project. They use I think it's SquashFS. So they actually, you know, download the SquashFS remotely, and use that as the assets. And that's how they do updates.

Dominic: 40:50

Nice. Yeah. Interesting. Okay. Okay.

Dominic: 40:53

So so we have that. So so from there, it's, you know, we we can do we can do whatever we want from from the front end point of view. So it's not it's not involved at all in the build process of the front end project.

Lea: 41:09

Yeah. Correct. Yep.

Dominic: 41:11

Great. Okay. That's good. So so from there so you you have, so I've I've read somewhere that there were some, some automatic, typing from, for TypeScript for the function that that can be called from JavaScript?

Lea: 41:29

I'm so glad you brought that up, Dominic. It's, this is one of the one of the big things about the project. One of the major things I'm probably, most proud of. We we discussed earlier about sending that those strings as protocols between the front and the back end and having to do that. One of the things that obviously I'm I'm majored on is developer experience.

Lea: 41:49

And, honestly, that's just no good. No good for me. So what I wanted to do is to be able to indicate in a Wales project that, you know, here is a struct. It has some information. It has some methods.

Lea: 42:01

I wanna be able to interact with that from the front end just like I wanna do that from the back end. So for version 2, what we did was we built a mechanism that when you compile your project, the first thing it does is it compiles it with a with a bindings tag, a build tag. Mhmm. And what that does is it kind of layers it sort of patches your application so that when you when it runs it initially, it uses reflection to determine which Go structs are bound to the to the application. Sorry, to the to the front end, and then generate JavaScript wrappers or, you know, bindings for those calls.

Lea: 42:45

So we use reflection to discover which methods are bound to the front end, and it generates JavaScript files, which contain wrappers. And so what you can do from the front end is you can just import the file, and you can import the the functions as if they were like just JavaScript functions, but they mirror the go ons, 1 for 1. And so you can call those from the front end, and and and receive, you know, either a value or an error back. So none of that kind of plumbing you you need to do. It's done automatically for you.

Lea: 43:21

That method of using reflection was, pretty good. It's okay. You miss a few things, like you don't get the comments from the code. You don't get the argument names in the in the signatures. You just get the method names and the number of of, you know, arguments that there are and their types.

Lea: 43:44

So it was a little bit limited, but it was very powerful. And, you know, it does allow you to move quickly. If you add a function in the back end, you you just recompile and then, you know, your JavaScript's updated. You you now have, like, new JavaScript functions that you can import and call straight away. So, yeah, that actually leads me on to, like, where we're going with that with version 3.

Lea: 44:05

So the I've already spoken about the problems with that in terms of using reflection. It does add to the build time. We're very fortunate to have a a community, member who contributed a static, sorry, a a new parser and and cogenerator, which is a static analysis. So so with version 3, yeah, you can you can basically bind, the structs to to your, to your application, and then it will search through work out exactly what they are, ahead of time and and be able to generate those files for you. So, yeah, it's it's much more powerful than than the version 2, bindings generator.

Lea: 44:51

It does keep your comments. It automatically creates JS doc types, comments so that you're able to get your ID to, you know, pick that up. Yeah. Argument names, everything. It's it's just like Go code, but now it's in now it's in the front end.

Dominic: 45:07

Yeah. That's that's interesting. So so it basically creates a JavaScript module from, you know, mimicking what what's in there. Right? Yep.

Dominic: 45:16

Correct. So and and the only thing that we need to do is to is to apply a build tag on on that Go file.

Lea: 45:24

No. You don't need to do that. It does so I I guess that that was version 2. Version 2 kind of did that behind behind the scenes. So that was kinda like just the mechanism it used to be able to kinda patch it to to read to to read the, the bound strokes via reflection.

Lea: 45:41

For version 3, I I guess it's worth talking about the the build system. Because, yeah, generating bindings was kind of automatic as part of the build in version 2. A lot of the feedback we got from that was it was far too opaque. Like people just didn't know what it was doing. There may have been certain flags which we weren't passing through to the to the Go compiler.

Lea: 46:03

And so you kind of end up, you know, you know, pat basically recreating all of the all of the flags and everything for the Go compiler, within your tooling. That led to a lot of bugs, you know, a lot of tickets. So what we decided to do was, listen to the community, and talk about, you know, using an external build system. And I guess it's highly contentious. Some people love Make.

Lea: 46:29

Some people hate Make. So we looked around for a go a go based project that that kind of solved that problem. 1 the one that we kind of settled on was Task. I don't know if you're familiar with it.

Dominic: 46:43

Task Yeah. I've seen it. Yeah.

Lea: 46:44

Yeah. Yeah. So the developers there, they're really, really great. I had a conversation with them about being able to use it as a library, so that we could incorporate it as part of the the WEL CLI. And they were very open.

Lea: 46:57

They were very happy to to help with that. You know, we we we support them. We sponsor them, like we do most projects that we rely on. And yeah. So with the Wales 3 CLI now, you you actually have the the the build system as part of the CLI.

Lea: 47:17

And when you generate a project, you have default task files for the different platforms, and you've got common tasks. And so everything is completely exposed. You know, how how you're calling the Go compiler, which order you're doing these things in, what what are the tags that you're passing in. So we provide that as a default. So you can just basically run, you know, Wells rebuild, and it's gonna do exactly what versions you did.

Lea: 47:42

Except now it's using task under the hood, and it's using the task files on how, you know, to to execute those commands and and and build it. And it gives us a whole bunch of stuff. There's a whole bunch of optimizations it does. It fingerprints files. Yeah.

Lea: 47:58

It it it coaches a lot of stuff. It's it's really fantastic. But, you know, to be clear, you're not limited to using tasks. You don't have to use that build system. You can use a completely different build system.

Lea: 48:08

That's absolutely fine. Yeah. So as part of those files that you get as a as a well c project, the bindings generator is called in that. And so then you're able to customize that as much as you want as well. You can call it when you want.

Lea: 48:22

You know, it doesn't have to be part of build. It can just be part of development.

Dominic: 48:26

And how this this binding generator knows what struct and what function, to to output into JavaScript?

Lea: 48:34

Yep. That's a good question. Yeah. So as part of the application configuration, you're able to define those structs, and it uses the so it uses that to discover, yeah, what what those things are. One of the key things as well that we've moved to in in version 3 is we've moved away from this concept of, like, they're just structs.

Lea: 48:58

We're we're calling them services. And the difference between structs and services is when you when you bind a service, there are certain, functions that it would kind of look for. So if it conforms to a particular, interface, then it will call those, functions. So there's like application life cycle functions. So at the start, you know, you may wanna call some initialization functions as part of your part of your service.

Lea: 49:25

That will happen automatically. Same for shutdown. But one of the key one of the key new things as part of it is we recognize the serve HTTP function. Do you know the it's kind of standard serve HTTP function? Yeah.

Lea: 49:39

If if your service has that method, then given a particular path as part of the config to the service, it will it will mount it in your front end. So it's it becomes accessible on a on a path in your front end. And what this means is that you can develop essentially plug ins where you can provide functionality, to the front end with very, very little, you know, what's the word, effort. You can provide functionality to the front end with very, very little effort. So let's say as an example, you've got a QR code generator.

Lea: 50:19

You may release a service that that that does that. And when you consume the service as a Go module, you can say, right, as part of my services in my application, I wanna use this QR code generator, and I want the path accessible path from the front end to be, you know, slash QR. And then in your front end code, you can call slash qr, and and, you know, whatever paths that the the QR code generator provides you. Maybe it's just, you know, maybe it just accepts the path parameters, the URL parameters. You know, the ones with the the question mark and and whatever.

Dominic: 50:58

Yeah. Query string?

Lea: 50:59

Yeah. The query string. That's the word. See, it's too it's too early, Dominic. It can read the query string, that's provided, you know, for you, and then it can return an image.

Lea: 51:10

And so now you can, you know, you can use in your front end, you could use, like, an image tag and just point it

Dominic: 51:16

Oh, yeah. Okay. Straight

Lea: 51:17

to it?

Dominic: 51:17

Yeah. Yeah. Yeah. Yeah. Now I get you.

Dominic: 51:19

Okay. So and and there's there's no HTTP involved at all? No way. Okay. Okay.

Dominic: 51:24

Okay. That's interesting.

Lea: 51:28

Mhmm.

Dominic: 51:29

So that that is coming, with with the v three version that you are working on.

Lea: 51:34

Yes. Correct.

Dominic: 51:35

Nice.

Lea: 51:36

Yeah. We're hoping that will help people with things like OAuth for instance where, you know, you need callbacks. So you can yeah. You can do a whole bunch of stuff. We're we're pro okay.

Lea: 51:49

This isn't like this is an exclusive for for you, but we're probably Nice. Nice. Yeah. We're we're we're probably gonna do a competition during the the beta phase, for, like, yeah, who can come up with the best services for v 3. And there'll be some pretty good prizes.

Dominic: 52:07

Nice. Nice. So where where are people, can can know about that? You know? Do do you, where where where where is the community hanging out?

Lea: 52:19

Yeah. So we've we've got it, we've got a Discord server. We used to have a Slack server, and I found that the interaction there was actually quite slow and and muted. Since moving to Discord, it's just absolutely thrived, for whatever reason. Yeah.

Lea: 52:36

So we do have a a Discord community that you can you can join. It's at the bottom of the whales.io webpage. If you're interested in v 3 specifically, there is a v3alpha.wales.io website, and and you can use that to to get a bit of information about v 3. It's it is alpha. It is constantly evolving.

Lea: 52:58

The docs may be wrong. But, yeah, if you just hop on to, hop on to Discord, the we're all we're all pretty friendly. We can chat about things.

Dominic: 53:07

Very cool. Well, yeah, it's it sound it sounds pretty interesting. Yeah. Yeah. I I I was I wasn't sure I was understanding, the the service part, but, you know, you know, with with the QR code example, it it it makes sense.

Dominic: 53:23

Seems to be great. So anything, any anything, you want to add at this at this point? Can we expect I don't know, a Hurley next year release? When do do you have any kind of ballpark idea for the v three release?

Lea: 53:43

Yeah. That's the $1,000,000 question. Right?

Dominic: 53:45

Yeah. Right.

Lea: 53:46

Uh-huh. The official answer is it'll be it'll be released when it's ready.

Dominic: 53:50

Nice.

Lea: 53:51

There's yeah. It's there there's a few things, like, coming coming from v 2 to v 3, there are certain things that people need. And so there is kinda like there is a porting effort, you know, involved. There's there's certain things which, you know, we've had to think long and hard about. I I really don't ever wanna have to go through this again.

Lea: 54:13

So I need to make sure that we we we make as as many right decisions as possible. So yeah. I think we're getting really close. Like, it it seems to be that there's just some there's just some minor features and incompatibilities that that we're struggling with. Partly kind of like the the parity between the offices.

Lea: 54:37

So for instance, the tray the system tray menu, which we we're supporting. Like, on Linux, you can't tell which which button you've pressed on it. So so then you don't know whether it's left click or right click. And, like, how do you how do you manage that? There's yeah.

Lea: 54:53

There's a few little things that we need to to figure out, and there's some features that need to be ported. But yeah. Like, we we're getting close. We're getting close. I'm hoping hoping hoping very early next year.

Lea: 55:05

It should be at the beta release phase. Yep.

Dominic: 55:08

How how does it work when when it's a call from a you know, you were mentioning the the tray, and I I guess the the the menu bar is the same, you know, who's got call exactly? Is is it is it a Go function or or is the, you know, it's it's somewhere in JavaScript that gets called when those things happen?

Lea: 55:26

No. So so it's all in Go. It's all in Go. I and I think as a general rule, the the way that we, the way that we suggest that you build Wells applications is that the the UI is just UI. Like, you probably shouldn't be keeping state there.

Lea: 55:41

There's enough mechanisms to move state from from Go into JavaScript, to not keep it in JavaScript. So anything to do with the window, the and all of the native components, like the menus, the the trays. It's all in Go. So you can just create 1, you know, as part of your menu. You can, have a callback back into Go.

Lea: 56:04

Yeah. Like, it's it's all in Go, basically. The the thing that you use the JavaScript, there's just the UI.

Dominic: 56:10

Yeah. Totally. Yeah. That's great. That's great.

Dominic: 56:13

And, you know, what what what about, comparing that to, to Tori maybe and and and I I don't know if there's anything else other than, what's the name? I'm forgetting about the name, the the you know, Electron. Right? So I I I I would assume that it's extremely, more lightweight than than Electron, for example.

Lea: 56:37

It is. It generally is. Yeah. It depends on what you do. I mean, you know, you can definitely make a heavyweight program in any technology.

Lea: 56:45

But, yeah, it's it doesn't come bundled with a browser. And I think that's some of the misconceptions of of the stack. You know, it it doesn't open an HTTP server, and it doesn't come with a browser. And one of the one of the difficulties we had early on, because Wells comes with a development mode. I don't even think we we we spoke about that.

Lea: 57:04

But, basically, when you run it in development mode, it will hot reload your your front end, and it will recompile your back end if you change your code code. So you have this kind of fast, development iteration. And, yeah, one of the one of the things that we we found was or one of the things we're able to offer was being able to call your back end from a browser. So you could connect to a port and and with a browser and develop that way. So then you could use your, you know, your React plugins or whatever.

Lea: 57:33

The big problem we found with that was that the browser APIs are not the same as WebView APIs. WebViews generally lag behind a little bit. Mhmm. And so we found that there was a lot of tickets getting raised for, you know, why does my local storage, you know, work in development mode and not in production, you know, when I when I do a build in production mode. So for v three, we're kind of trying to steer away from that a little bit and saying, you know, when you develop, you you have the application there.

Lea: 58:05

You do have developer tools there. But, yeah, like, I think it's probably more trouble than it's worth to be able to I mean, it's cool. It's I can't tell you how cool it is that you just connect to a port and see your desktop application in Chrome and then go in your dev tools and start calling Go code from it. Like, it's supremely cool. But at the end of the day, it gives you a kind of a false sense of of what what your application can do.

Lea: 58:33

Yeah. But yeah.

Dominic: 58:35

Oh, yeah. Interesting. Okay. So so you are kind of moving away from from that in in v three, if I understood?

Lea: 58:43

Yeah. So the thing about using the extensions in Chrome I mean, really what you're using that for is front end. And so as part of the development, as part of the the development, mode, it actually opens up, a Vite, development development mode. Okay? And And so you're able to connect to that using a browser, and still use your extensions to do the UI work.

Lea: 59:07

The thing that we are recommending is that you you only you know, you can still do that, but we we recommend that you do it through the through the application to make sure that it is actually working. So doing the UI stuff, that's fine. But anything anything that sort of starts using, you know, JavaScript APIs and stuff, kinda like we we're throwing caution at that.

Dominic: 59:31

Right. Yeah. Sounds pretty interesting. Very exciting. I would, I would even say, you know, of course, one, one thing that I do appreciate about, about whales is, is all the accessibility that that comes with, with the brow you know, the application UI being from the browser.

Dominic: 59:49

So, I mean, we're it's it's very nice because I, you know, I I received, Andy from, from Fein a couple of weeks ago. And and, yes, the, you know, the issue with with desktop sometimes is that our native desktop UI is that they they are not accessible. So I it it it's nice. It's nice to have that.

Lea: 01:00:12

Yeah. It is. Yeah. Yeah. It absolutely is.

Lea: 01:00:14

I mean, you know, everything has their their pros and cons. And, yeah, I get on get on with Andy really well. I think I think he's got a great project there. But, yeah, I'm sure he's he suffers, like, different problems coming from from from that angle as well. But I think, yeah, you know, people have different needs and and there's different technologies for those solutions.

Lea: 01:00:35

So yeah.

Dominic: 01:00:38

Yeah. Oh, yeah. Totally. I mean, it's, it's great. It's great.

Dominic: 01:00:42

I would assume. Do you do you have any, any, you know, example that that, that when you saw that that being released, you said, wow, they they are using Wells and I'm kind of proud of what I built because you you you did build something extremely, extremely great. I mean, there there's a lot of love around Wells. There's a lot of you know, it's always positive when when I when I see, someone, you know, talking about that. So do do you have do you have an example?

Lea: 01:01:12

There's there's been a few. I mean, I think it was about 4 weeks after I released the the v one alpha or beta. A guy, Alex, I can't remember his surname, unfortunately, but he's have you heard of package mate?

Dominic: 01:01:28

Oh, yeah.

Lea: 01:01:29

He's a yeah. Yeah. So he he did a video on on the first version when it was first released, and it was so positive. And and, honestly, I just came back from work, and I saw it pop up on YouTube. And I was like, what the hell?

Lea: 01:01:41

Like, what is this? You know? And and I was just blown away. I was like, wow. That's that's just incredible.

Lea: 01:01:48

And Alex has reached out recently to to kind of do an update, which I'm really looking forward to. But but, yeah, he really, you know, he really instilled that thing in me of of like, oh my god. Like, this is this is happening. This is like this is going somewhere. But there's also been like a few blog posts as well that I've just stumbled upon.

Lea: 01:02:07

There was one by Twilio. There was one on IBM. Wow. Yeah. Like, it's yeah.

Lea: 01:02:12

It's just like it's it's crazy. And there are like some commercial applications as well, you know, which has also kind of contributed to that, that feeling of, oh, you know, maybe this is good. So there's a company, a keyboard company, which you may be familiar with, ZSA. They do, they do, the, you know, EZDox keyboards, the split key. Is it Moonlander, I think

Dominic: 01:02:38

it's called? Oh, yeah.

Lea: 01:02:39

Yeah. Yeah. Yeah. Yeah. Yeah.

Lea: 01:02:39

Yeah. Yeah. Yeah. So they they used version 1 to create a firmware flasher, and it was a little bit limited back in the day.

Dominic: 01:02:48

Really? Wow.

Lea: 01:02:49

Yeah. Yeah. Yeah. Yeah. It was it was called Wall E, and it was really good.

Lea: 01:02:53

And when I saw that, I was like, this is exactly what this is exactly what it's for. You know, back end, you know, low level Go

Dominic: 01:02:59

Right.

Lea: 01:03:00

Applications, but but with a with a really nice UI. They since have developed a commercial version of the of the firmware flashes called KeyMapper. And they ship that with every every ZSA keyboard. Yeah. It comes with KeyMapper.

Lea: 01:03:15

They're huge supporters of the project. Wow. Yeah. And I can't I can't thank them enough for for their contributions to the project. It's that that's just been absolutely amazing.

Lea: 01:03:25

Another one was, there was a blog post that somebody pointed me to, and there was a company. They built a, I think it was a Laravel debugger, or PHP debugger.

Dominic: 01:03:36

Okay.

Lea: 01:03:36

It was super Laravel. I think it's called Crater. And they'd they ported their application from, Tory to to Wales, and they did it in a weekend. When when I read that, I was like, this is incredible. Yeah.

Lea: 01:03:50

Yeah. Yeah. Yeah. It it was, you know, it was just a really incredible thing to read, because not only did it kind of like, you know, validate the the use case for for for whales, but also the developer experience as well. And, honestly, that's that's really been a major thing, in in the project.

Lea: 01:04:08

There's one open source project as well I've gotta I've gotta mention. It's tiny RDM. It's actually a Redis manager. They have so many stars. Like, it's it's crazy.

Lea: 01:04:18

They they're doing such an amazing job. It looks good. It it works really well. So, yeah, anybody using Redis, check out tiny RDM.

Dominic: 01:04:27

It's like it's like a UI for your Redis database?

Lea: 01:04:30

Yeah. Correct. Yeah. It's really good.

Dominic: 01:04:32

Interesting. Oh, wow. Yeah. This, this this sounds this sounds great. Congratulation to you.

Dominic: 01:04:38

I mean, this is, you know, this is very hard to to reach, what what what you have you have done and and where you are going as well. I mean, yeah. Be be proud of that. It's, it it's not easy to do.

Lea: 01:04:52

I appreciate that. Dominic, yeah, it's it definitely is not easy. There is so much time and effort spent in things that people don't see

Dominic: 01:05:01

Yeah.

Lea: 01:05:02

Just to make sure that, you know, things work well, you know, for the project. So yeah. Thank you.

Dominic: 01:05:08

Very cool. Very cool. So thank you thank you for your time. We will have, all all of that, you know, the links in the show notes and whatnot. But, but, yeah, thank you very much for your time.

Dominic: 01:05:17

It was it was great.

Lea: 01:05:18

I really appreciate it, Dominic. It's been fun. Alright. Take care.

Dominic: 01:05:26

Alright. That's it for this week. I would really appreciate if you can talk or share about this podcast. It's always helpful. Also, another way to support this show is by purchasing my course.

Dominic: 01:05:38

There is always a link in the show notes. So on that, see you next week.