Speaker 1: Hey, folks, welcome back to another Ruby Rogues.
Speaker 2: This week on our panel we have a Yushinwatya Hello.
Speaker 3: Hello.
Speaker 1: We also have Valentino Stole and now I'm Charles Maxwood
Speaker 1: from Top Endevs. And this week we have a special
Speaker 1: guest and that's Emil.
Speaker 4: Come hey, everybuddy.
Speaker 1: So Emil, I'm just gonna clear my throat because wow, okay,
Speaker 1: let me.
Speaker 2: Try that again. So Emil, I found you.
Speaker 1: I've been corresponding with people some on the discord for Kamal,
Speaker 1: which is the deployment technology that DH put out. I
Speaker 1: think he made kind of a deal about it at
Speaker 1: Rails World last year, and then a whole bunch of
Speaker 1: exciting stuff this year with Kamal Proxy and stuff like that.
Speaker 1: I mean, I switched over to and I switched over
Speaker 1: from Mall to the Mall too, with all much of
Speaker 1: help from you and others on there. And I have
Speaker 1: to say switching over was a little rough. Having switched over,
Speaker 1: it's a lot nicer. So anyway, so beyond kind of
Speaker 1: what I know about you from that, what should people
Speaker 1: know about you?
Speaker 4: Well? So I think, first off, I am a mountaineer,
Speaker 4: and in order to facilitate that I live in a
Speaker 4: very flat country, so I do a lot of running,
Speaker 4: and then I need to pay for my travels, so
Speaker 4: I do also engineering. And I've made a career of
Speaker 4: doing sort of critical infrastructure or things that have real
Speaker 4: world impact and real world consequences if something goes wrong, right,
Speaker 4: So both in terms of security and robust list and
Speaker 4: things like that. And that's everything from the fintech or
Speaker 4: the payment industry, to civil engineering to online voting.
Speaker 2: Wow.
Speaker 1: Yeah, it sounds like kind of what our topic is here,
Speaker 1: which is building critical infrastructure. So you've done some stuff
Speaker 1: that I kind of need to work, I guess.
Speaker 4: I mean, so a banking obviously needs to work when
Speaker 4: people get sort of pissed if they don't get their money.
Speaker 4: And then for civil engineering, I worked on tools that
Speaker 4: the engineers would use to build the airplanes, which and
Speaker 4: run tests on them. Right, so both test benches and
Speaker 4: design benches for airplanes. And I mean that has a
Speaker 4: real world consequence because they fall out of the sky,
Speaker 4: right if you mess it up. Yeah. And then yeah,
Speaker 4: online voting, that's the whole thing. And you guys in
Speaker 4: the US just went through one one of these messy
Speaker 4: events and they're messy everywhere, right, And recently I moved
Speaker 4: to two compliance and sort of making trying to make it,
Speaker 4: trying to make that easier and a better experience to
Speaker 4: become compliant and to obtain certifications.
Speaker 2: Right, makes sense, So let's just dive in.
Speaker 1: I mean, I'm not I'm trying to think if I've
Speaker 1: ever worked on anything that was you know, kind of
Speaker 1: at the level of, hey, if this breaks.
Speaker 2: Then you know, really bad things happen.
Speaker 1: I mean, if it breaks, I've had them come to
Speaker 1: me and be upset, like really bad things happened. But right,
Speaker 1: it doesn't affect society at large. What's the difference between
Speaker 1: working on those apps and working on just kind of
Speaker 1: you'r you know you mentioned not e commerce or not
Speaker 1: you know, hey I've got to manage my social media
Speaker 1: or you know, get podcasts out on time.
Speaker 4: Yeah, I mean, there's nothing just to be here, There's
Speaker 4: absolutely nothing wrong with that, right, That's just I started
Speaker 4: out in that area, as many developers do, right, building
Speaker 4: like some ad system when I was very young, and
Speaker 4: then moved to some you know, sort of off a platform,
Speaker 4: and then I sort of realized that it was it
Speaker 4: was just inconsequential in a way, right, I looked at people,
Speaker 4: you know, I had people around me. My father was
Speaker 4: is a civil engineer, right, and so I have people
Speaker 4: in my sort of my family, my near family, that
Speaker 4: was building things in the real world. And I was like,
Speaker 4: I want to do that, but I do like this
Speaker 4: computer stuff, So can we sort of maybe find a
Speaker 4: way where I can build things in the real world
Speaker 4: just using my computer. And so I slowly started to
Speaker 4: shift over into something that was founded more in civil
Speaker 4: engineering and sort of industry rather than commerce mm hmm.
Speaker 4: And then I started in a fintech company where we
Speaker 4: were where I was part of building, building out and
Speaker 4: continuing to build on a on a system where you
Speaker 4: can basically it's like direct debit bank transfers, but worldwide, okay,
Speaker 4: so and and there. It doesn't necessarily mean a lot
Speaker 4: to you and me. And it's the same with there's
Speaker 4: a bunch of them now, right, like these send money
Speaker 4: home types of things. It doesn't mean a lot to
Speaker 4: you and me, but it does mean a ton to
Speaker 4: those who is on the receiving end of that, right,
Speaker 4: because that's like half a year's pay or something that
Speaker 4: comes in, right, So it does matter to those people
Speaker 4: so so yeah, that was sort of where I ended up.
Speaker 4: And we are moving a lot of money, like it
Speaker 4: it seems it's one of those where little like it's
Speaker 4: it's a lot of tiny things that add up. Right,
Speaker 4: There's like millions and millions and millions of dollars being
Speaker 4: moved around for that purpose, and you don't want to
Speaker 4: miss handle those money. Right. So you are hooking into
Speaker 4: the to the banking infrastructure, into Swift and into the
Speaker 4: IBAND network and the whole sort of PC compliance and
Speaker 4: everything with that, right, so you need to make sure
Speaker 4: that the software is robust well tap that testing has
Speaker 4: been a main thing of mind for a long time
Speaker 4: because of that, and also documented well. Right, So that's
Speaker 4: where I sort of started out with being required to
Speaker 4: document what I was doing and how it was supposed
Speaker 4: to work. Rather than just shipping fast and breaking things.
Speaker 4: I was required to test and document, then test, then
Speaker 4: stage it, then test some more, then ship and not
Speaker 4: break things. So that was a different paradigm. Yeah, so
Speaker 4: that's sort of where I first met that, right, And
Speaker 4: that was a pretty great experience, and so I was like, oh,
Speaker 4: can I have more of this? Can I maybe even
Speaker 4: get even closer? Right? Yeah? So that's uh, that's where
Speaker 4: all that started. And then I was hooked on the
Speaker 4: whole can we test it? Can we build something that
Speaker 4: runs Ruby on rails but make a difference to people's
Speaker 4: lives like in real world? Right, So this was basically
Speaker 4: a payment situation, just building Ruby and rails, and back
Speaker 4: then many of the banks didn't have a proper API,
Speaker 4: so we ended up scraping a lot and that's you know,
Speaker 4: against terms of policy, in terms of service and all
Speaker 4: of that, and they were really mad and we went
Speaker 4: through that whole spang of getting you know, sort of
Speaker 4: scolded for that for a while. Yeah, So that it
Speaker 4: was a bit the wild West back then, but it's
Speaker 4: definitely gotten better. And I think there's a lot of
Speaker 4: again sort of compliance work and lew work that went
Speaker 4: into the EU did a lot to make sure that
Speaker 4: banks would have not standardized, standardized APIs, but a minimum
Speaker 4: level of information that you could retrieve with an A,
Speaker 4: which made all of that a lot easier.
Speaker 5: Right.
Speaker 4: It also means that I can technically build my own
Speaker 4: banking app for my own bank account because I have
Speaker 4: API access to it. It may not be obvious, it
Speaker 4: may be poorly documented, but it is there, and so
Speaker 4: I think that's pretty cool.
Speaker 1: Yeah, I'm curious, Valentine or I usually have experienced doing
Speaker 1: this stuff.
Speaker 3: Nothing that critical.
Speaker 2: Now.
Speaker 3: The closest I kind of came to anyone near that
Speaker 3: world was when I worked for transfer Wise, But I
Speaker 3: was an iOS developer, so I didn't really have to
Speaker 3: do any of the hard stuff. I just made API calls.
Speaker 3: But I know they were also doing quite a lot
Speaker 3: of the scraping and stuff. There's a lot of selenium
Speaker 3: going on behind the head to get into different bank accounts.
Speaker 3: It's uh, yeah, it's it's all a bit scary when
Speaker 3: you think about it.
Speaker 4: Yeah, yeah, it really is, because it's like your whole
Speaker 4: banking experience is tied up on some scraper working correctly
Speaker 4: and not messing around with the the thousands delimiters and
Speaker 4: the the scent comments are different on different regions, right,
Speaker 4: so you don't want to mess around with that. I
Speaker 4: did transfer some money incorrectly. Luckily, the backbone banking system
Speaker 4: is pretty robust as well, so we were able to
Speaker 4: basically not move the money anyways, right, but it I
Speaker 4: did move far too many money the wrong place. Yeah,
Speaker 4: that was a back breaking day.
Speaker 2: I'll bet.
Speaker 1: So I'm a little curious as we get into this,
Speaker 1: Like you mentioned testing, what what is your what does
Speaker 1: your testing set up look like?
Speaker 2: Because I mean, I I'm sorry.
Speaker 1: When I write my test, it's like, okay, it's good
Speaker 1: at Like I'm I'm reasonably confident, right, but I'm not
Speaker 1: like iron clad confident, like baking level confident that my
Speaker 1: code works.
Speaker 2: Right.
Speaker 4: Yeah, yeah, that's a good question. I tend to not
Speaker 4: be too dogmatic. I know there's a lot of like
Speaker 4: do this or do that paradigm or do test first
Speaker 4: or whatever. I tend to just play around with it
Speaker 4: and make myself certain first that this is gonna work
Speaker 4: whatever I'm sitting with, and then when I know that
Speaker 4: it you know, sort if I can see like okay,
Speaker 4: it works, it does what I needed to do, then
Speaker 4: it is worth testing, right. And then it's I try
Speaker 4: and test on the lowest possible level first, which means
Speaker 4: I will start with something like unit tests, and for
Speaker 4: that I want to permute everything, right. You want to
Speaker 4: make sure that every argument, So you basically start with
Speaker 4: the least amount of arguments for a method, and then
Speaker 4: you add an argument slowly. In I use aspects, so
Speaker 4: it's in every context block or in every described block. Right,
Speaker 4: so you're you're certain that every version of every argument
Speaker 4: is is tested and has been permuted. Yeah, so that everything,
Speaker 4: like every variable has been tested on its own, so
Speaker 4: you know how it behaves both with and without that
Speaker 4: particular variable, and you also know how it behaves if
Speaker 4: the variable has the wrong type.
Speaker 2: Right.
Speaker 4: So because Ruby isn't quite where we have type safety yet.
Speaker 4: There's a lot of work going on with that, but
Speaker 4: we aren't there yet. So I, you know, you want
Speaker 4: to make sure that we can handle strings, numbers, not strings, truths, boollians, whatever.
Speaker 4: There's like I have a little thing that basically says,
Speaker 4: take this and just you know, cycle it through all
Speaker 4: of the different types it can be, and just put
Speaker 4: in garbage so that I know it can not it
Speaker 4: doesn't break when a number is presented rather than a
Speaker 4: string or something stupid like that. Right, And then you
Speaker 4: sort of you slowly move up so you're confident that
Speaker 4: this method works, and then you move up to have
Speaker 4: recalled it, and then you I what I do is
Speaker 4: I then I go through and test that. But I
Speaker 4: think opposed to what is DHH preaches or or at
Speaker 4: least sort of he he has this idea that you
Speaker 4: would go through the entire stack, and I believe that
Speaker 4: they had their tests to do that. I tend to
Speaker 4: not to sort of stop testing at each level, right,
Speaker 4: So model tests are their own thing. And then when
Speaker 4: you test the controller, you basically verify that the model
Speaker 4: is being called with the expected parameters, because you know
Speaker 4: you've already dealt with the parameters on a lower level.
Speaker 4: So it's not mocking per se. It's just that I
Speaker 4: only need to test that the model was created or
Speaker 4: was called. I don't really need to test that it
Speaker 4: was the correct arguments, right, because I'm certain about the
Speaker 4: correctness of the arguments on a lower level than that.
Speaker 4: And then you saw slowly move up, which means that
Speaker 4: I find that that means that the individual testing levels.
Speaker 4: It gives you a little bit more freedom to sort
Speaker 4: of move a model around because it's coupled somewhat on
Speaker 4: a test level, but not tremendously, right. I only coupled
Speaker 4: the controller the model in the sense that I checked
Speaker 4: that the model was called, not that it was called
Speaker 4: with a particular set of arguments. So it makes it
Speaker 4: a little bit easier to also restructure your tests when
Speaker 4: your code change. But it's just a lot of work
Speaker 4: on lower level things. I'm a big fan of Spey,
Speaker 4: but it's not it's not quite there yet. I think
Speaker 4: it works reasonably well, but it's very hard for developers
Speaker 4: to use, and so I think we need to do
Speaker 4: there needs to be a lot of work done in
Speaker 4: terms of making it nice and sexy to use so
Speaker 4: that we can get people to use it right.
Speaker 6: I'd love to dig in a little bit more on
Speaker 6: the aspect because one of the biggest things I see
Speaker 6: miss is maybe like skipping over like the maybe some
Speaker 6: lower level implementations and then like a system update break
Speaker 6: something and it just wasn't covered right, Like how do
Speaker 6: you go about, like you know, waiting whether or not
Speaker 6: that it's worth it to like actually run like a
Speaker 6: system command or an external API call or something like that.
Speaker 4: Yeah, So system commands, I usually check just that the
Speaker 4: signature of the call is correct and probably that it
Speaker 4: returned the right thing right, so that if I hit
Speaker 4: the OS, I'm basically testing that I gave it these
Speaker 4: parameters and I expected something back like a string or
Speaker 4: whatever it is right, because it's so hard to know
Speaker 4: what it was supposed to be because sometimes the system
Speaker 4: commands will change their signature but not necessarily return value
Speaker 4: or the return value, but not the signature. So that's
Speaker 4: that's very hard. I try to not go there. I
Speaker 4: tried really hard not to go there because it is
Speaker 4: it's out of my control. Right on the other end,
Speaker 4: when I called other APIs, I definitely test that I
Speaker 4: use something like me CR or something. I capture all
Speaker 4: the network traffic, and I make sure to do the
Speaker 4: same kind of sort of making sure that if I
Speaker 4: call it with these arguments that I have control over,
Speaker 4: I get this particular response, and if I do something
Speaker 4: else then then it breaks right or it gives me
Speaker 4: the incorrect response. And I also found that, for example,
Speaker 4: with with banking, that one of the cool things we
Speaker 4: did was that we basically took all of the historical
Speaker 4: records right that we had for all the bank accounts,
Speaker 4: and we basically used it as a test bed because
Speaker 4: then you can train on that. You can basically say,
Speaker 4: if I feeded all of this information that we know happened,
Speaker 4: and it happened correctly because it happened, you know, but
Speaker 4: a year ago or two or whatever, it should result
Speaker 4: in the in in a particular set of of like
Speaker 4: it should result in a particular value on the account. Right,
Speaker 4: So you can actually use historical data as a test
Speaker 4: that and that makes that means that you have a
Speaker 4: factual way to check if it's correct or not. So yeah,
Speaker 4: I tend to use that as well. I also used
Speaker 4: that when when I did software for the for the
Speaker 4: for the sort of civil engineering and building flights and
Speaker 4: testing that. Right, we also used a lot of existing
Speaker 4: information to make sure that we had input output, so
Speaker 4: we understood that given these inputs, this is the output
Speaker 4: that we would expect. Right, We could basically take old
Speaker 4: designs and try and run them through and you can
Speaker 4: see if does it break it down like you would expect,
Speaker 4: does it run the does it sort of fit to
Speaker 4: the engineering standard design standard that we were implementing against.
Speaker 4: They also have test and value that you can use, right,
Speaker 4: or test data. So it's also about going out and
Speaker 4: finding big test data sets that you can use to
Speaker 4: also make a statistical sort of approach. Right, I'm not
Speaker 4: making any statistical claims, but I am running a lot
Speaker 4: of tests on a lot of data that you know,
Speaker 4: you can be reasonably certain that that if there were
Speaker 4: errors in your system. It would have been caught by
Speaker 4: this because it's so much effective effective production data. Right.
Speaker 6: Yeah, I imagine that working with like the public sector,
Speaker 6: that you would have a lot of access to that data, right,
Speaker 6: I guess depending where you live.
Speaker 4: Yeah, I mean, I mean interesting enough. None of this
Speaker 4: is for the public sector, which is a little bit weird.
Speaker 4: You would think that it was, but it actually isn't.
Speaker 4: Like the regulation of the aerospace is public sector, right,
Speaker 4: but the actual building of airplanes is a private commerce,
Speaker 4: ran private industry. And likewise, with banking, the the regulation
Speaker 4: of it is public, but the actual banks are private entities,
Speaker 4: and likewise.
Speaker 6: We find it difficult for like the data access, like
Speaker 6: is that data proprietary then for like doing large swaths
Speaker 6: of tests or finding it.
Speaker 4: Yes, but most of the times the companies are interested
Speaker 4: in providing it, right, Like if you if you go
Speaker 4: out to big to big airplane or aerospace company and
Speaker 4: your unique to design a test system for them or
Speaker 4: something to help them build, right, they are interested in
Speaker 4: giving you that kinds of dace. So it wasn't that
Speaker 4: it was hard. It's just that it is also quite
Speaker 4: narrow in scope, Like it's it's more more or less
Speaker 4: only for that one.
Speaker 5: Right.
Speaker 4: So in banking, it would be a lot of records,
Speaker 4: but only for one bank, so you would only know
Speaker 4: how it looked in one type of account system, right,
Speaker 4: and then you would run over your tests and that
Speaker 4: and now two seconds all right, yeah, there we go. Hello.
Speaker 4: I So, so it's not that it's hard to get,
Speaker 4: it's that it is it's quite narrow in terms of
Speaker 4: sort of like what, Yeah, it doesn't have a lot
Speaker 4: of breadth. You get it for like one bank or
Speaker 4: one airplane company, or you get it for one company
Speaker 4: who runs elections. Right. Public elections is a bit different
Speaker 4: by definition. You don't have any test data because all
Speaker 4: of the records are sort of you don't know who
Speaker 4: who voted, so you can't know how to test that, right,
Speaker 4: So you have to do a different testing paradigm there.
Speaker 2: Yeah, that makes sense.
Speaker 1: I mean here in the US we have a anonymous
Speaker 1: ballot as well, right, yeah, And I don't know how
Speaker 1: they do it in other states.
Speaker 2: I mean I'm involved in the process here in Utah.
Speaker 1: And yeah, you send in your envelope and they with
Speaker 1: your ballot in it, and they validate that your like
Speaker 1: your signature matches and stuff.
Speaker 2: Off the envelope.
Speaker 1: But then they pull your ballot out of the envelope
Speaker 1: and put it in the pile to be counted, and right,
Speaker 1: they don't they track who you voted for in that case,
Speaker 1: at least they're not supposed to correct.
Speaker 4: And that is also the case for the digital solutions.
Speaker 4: A friend of a colleague of mine, Stefan, who is
Speaker 4: a cryptographer. He or previous colleague of mine, he did
Speaker 4: a lot of work of sort of gathering together a
Speaker 4: lot of the academic work so that we could exactly
Speaker 4: do that in a cryptographically safe way but online m
Speaker 4: and you could also do it in a way that
Speaker 4: it was you know, you could track it, and you
Speaker 4: could ensure that this was in fact the case, Like
Speaker 4: you could give the the lock data and the trace
Speaker 4: data to mathematicians and they could verify that mathematically. It
Speaker 4: could only ever have worked if these rules were followed,
Speaker 4: which was like you know, you anonymized, and you did
Speaker 4: you did mixing, and you did a.
Speaker 1: Lot of these things, right, right, So you protect the
Speaker 1: identity of the voter, but you also ensure that only
Speaker 1: people who are legally permitted to vote vote and that
Speaker 1: they're only cast one ballot and things like.
Speaker 4: That, Yeah, exactly, And the test, the test sort of
Speaker 4: the build idea for that and the testing regime for
Speaker 4: that is significantly different, right because this isn't sure the
Speaker 4: public space to your point earlier, Valentino, this is a
Speaker 4: public domain, right, so you you are a bit more scrutinized.
Speaker 4: You're also publicly scrutinized by everybody, right because we all
Speaker 4: know how it went with the dominion voting machine case, right,
Speaker 4: that went real fast, Will Downhill.
Speaker 1: Yeah, so yeah, well and you bring up the dominion
Speaker 1: voting machine case and whether you believe that they worked
Speaker 1: or didn't. There if there's enough population that doesn't trust it,
Speaker 1: then it causes problems, right, Yeah.
Speaker 4: And that's that's the same everywhere, right, And that's I
Speaker 4: found that sort of on a on a completely different
Speaker 4: but somehow related topic. I really found that the aerospace
Speaker 4: or the airplane industry was was really good because the
Speaker 4: what's the American one, the TSB Transportation Safety Board? Is
Speaker 4: that tis be right? Yeah, those are the ones that
Speaker 4: that they do crash audit that sort of like go
Speaker 4: through both them and the European counterparts have a really
Speaker 4: really cool way of going about it. They don't ever
Speaker 4: go and say, oh, it was that person's fault, right,
Speaker 4: if if the person hadn't slept enough, if the person
Speaker 4: couldn't read the dials, it is the fault of their
Speaker 4: plan that that made him not have enough hours to sleep,
Speaker 4: and it is the fault of the dial for not
Speaker 4: being visible enough. Right, So it's not They don't ever
Speaker 4: cast personal brain or they very rarely cast personal Blane.
Speaker 4: And I really thought that was a super cool way
Speaker 4: of going about it also just from a sort of
Speaker 4: like evaluating if something works well right, just like from
Speaker 4: a human perspective, and when you do leadership in tech
Speaker 4: or if you diet or lead others. That I found
Speaker 4: that really valuable sort of that whole way of thinking
Speaker 4: about it. And they also they collect a ton of evidence, right,
Speaker 4: They have a very structured way of collecting that before
Speaker 4: they then conclude that it works or didn't work, or
Speaker 4: that this was the fault of that was the fault.
Speaker 4: But they also I think I learned a lot also
Speaker 4: in terms of like having redundancy, Like what happens if
Speaker 4: this thing break, what happens if your job runner doss run,
Speaker 4: How are you alerted? What happens if your email doesn't send.
Speaker 4: How are you alerted? How do you have alternative options?
Speaker 4: Do you have an alternative email provider that you can
Speaker 4: switch to easily? Do you have alternate job runners that
Speaker 4: you can switch to easily? Do you have any of this? Right? So,
Speaker 4: that redundancy idea ideology was pretty cool, and I'm for
Speaker 4: like large scale systems. It pays off to have extras
Speaker 4: of these, even though you know, you use somebody like
Speaker 4: sent grid or use somebody like mail chimb or something,
Speaker 4: and you know, they say that they scale and they
Speaker 4: do right, but then ever so often it's down, and
Speaker 4: it's pretty nice to have a backup, even if it's
Speaker 4: a tiny backup, and even if it's just you know,
Speaker 4: up and coming fairly cheap one, it will do the
Speaker 4: job for like a day, right, and you will actually
Speaker 4: still send stuff out, or you will still process jobs,
Speaker 4: or you will steal whatever it is. Right. Also, running
Speaker 4: like on the big scale, running something like multi cloud,
Speaker 4: or running something I can open stack where you can
Speaker 4: actually move to somewhere else pretty fast. There was that
Speaker 4: case with that the Australian case where the where the
Speaker 4: bank got taken down because someone at Google decided to
Speaker 4: delete their account right, for like one hundred and sixty
Speaker 4: million US worth of servers just got mute. So for
Speaker 4: those cases, it's pretty nice to have a second provider
Speaker 4: back up and some way of getting there. Right. That
Speaker 4: is more a DevOps problem. It's not really a problem
Speaker 4: that I've ever solved. It's a problem that I have,
Speaker 4: you know, sort of like assisted with and talked about
Speaker 4: and verbalized a lot in companies. But it is to
Speaker 4: high degree of develops a solution that needs to go
Speaker 4: in there, and not one that I am gonna build.
Speaker 6: So you're talking a lot about like people's lives and
Speaker 6: you know, their livelihood, their money, like things that sustain life, right,
Speaker 6: and so like obviously these infrastructures are critical, like white
Speaker 6: tools using are critical. So I'm curious, like what about
Speaker 6: like Ruby and Rail's you know specifically feature wise, like
Speaker 6: do you see as being like, oh, this is like
Speaker 6: part of that critical process.
Speaker 4: I think the main part for me is that it
Speaker 4: can be built. You can write it so that it
Speaker 4: is absolutely readable and understandable what's going on, so you
Speaker 4: can reason about the what's going to happen, even without
Speaker 4: necessarily understanding the language fully or even without understanding what
Speaker 4: this active record method is going to do underneath. Because
Speaker 4: stuff is name WILL, and because it's ordered and organized will,
Speaker 4: you can reason about what's gonna happen, and you can
Speaker 4: have an expectation. And it makes it a lot easier
Speaker 4: to build complicated things, like you can go and test
Speaker 4: it afterwards, right, But just getting something that's complicated up,
Speaker 4: like just getting it up on its legs. It's really
Speaker 4: nice to have something that that is structured well and
Speaker 4: that you can reason about and that you talk about
Speaker 4: sort of what's the consequence of this method or that method?
Speaker 5: Right, yeah, yeah, yeah exactly.
Speaker 4: But I think and also I find that it's I mean,
Speaker 4: I've done a few frameworks throughout my career, right it,
Speaker 4: I've always come back to the rails and Ruby, and
Speaker 4: I also started there, so maybe i'm by it, but
Speaker 4: I haven't found any of the other frameworks that provides
Speaker 4: the same sort of consistent experience through every part of
Speaker 4: the application, whether or not you're doing low level active
Speaker 4: record stuff or you're doing high level system tests or
Speaker 4: whatever you're doing. It's consistently the same experience everywhere, which
Speaker 4: means that it's fairly easy for a developer to switch
Speaker 4: gears and do something else right in the stag. I mean,
Speaker 4: so like you can have a person who's sitting and
Speaker 4: doing the swift transfer one week, right, and then he
Speaker 4: can go and he can look at the webscraper the
Speaker 4: next because it's consistently the same experience, and you can
Speaker 4: write it in a way if you have a good
Speaker 4: sort of if you have a good style guide, and
Speaker 4: you have good code review, you can get it to
Speaker 4: a point where it's the same experience every time, and
Speaker 4: you can get abstraction levels and abstraction layers that feels
Speaker 4: the same, and that makes it easy to build something
Speaker 4: that where you can also easily plug out something and
Speaker 4: put something else in right that you can switch out
Speaker 4: one database provider for the other without much plot them right,
Speaker 4: or you can do whatever. Whatever it is that you
Speaker 4: feel like you need to change can be quite easy
Speaker 4: and quite straightforward if you've set it up to be.
Speaker 4: And I'm not necessarily talking about modularity in the sidewak
Speaker 4: level of aggressiveness that that the Shopify has, right, but
Speaker 4: you can you can definitely do something along those lines
Speaker 4: with just talking about it, organizing that, organizing the code well,
Speaker 4: and and just sort of thinking about how is this
Speaker 4: going to be tested. I find that that's also part
Speaker 4: of it. Right, It's like, how are we going to
Speaker 4: test this? Because if we are going to if we're
Speaker 4: going to test it in this particular way or that
Speaker 4: particular way, then that that informs the API and the
Speaker 4: sort of the interface for it. And a database you
Speaker 4: tend to test the same way. You know, if it's
Speaker 4: file uploading or downloading, you tend to test that the
Speaker 4: same way, which makes it easy to switch out one
Speaker 4: component for the other if your test paradigm is the
Speaker 4: same right for that component. So I feel that's that's
Speaker 4: some of the reasons that I've chosen this again and
Speaker 4: again right and also liked j said on his keynote,
Speaker 4: this is a one like it can be a one
Speaker 4: man army. Right. You can be pretty fast and pretty
Speaker 4: dangerous with it, which means you actually need fairly low
Speaker 4: hepcount to get somewhere really fast, and you can actually
Speaker 4: get something that's really secure, solid, safe, robust and easy
Speaker 4: on the eyes and nice to use with only a
Speaker 4: handful of people. Right, you can get somewhere with just
Speaker 4: one person, but you can definitely get a long way
Speaker 4: with a handful of people.
Speaker 2: You are so speaking my language, man, this is why.
Speaker 4: Yeah.
Speaker 1: So, one thing that I'm wondering about with all of
Speaker 1: this is, you know, it sounds like depending on what
Speaker 1: the concerns are in the app, right, So whether it's
Speaker 1: banking or voting or right, you may have different concerns
Speaker 1: about up time, verstability or you know, resumability, you know,
Speaker 1: if Google deletes all eighteen hundred year servers or you whatever. Right,
Speaker 1: So how do you begin to start looking at your
Speaker 1: application and saying, well, you know, for example, in banking, right,
Speaker 1: we have to make sure that we don't have any
Speaker 1: of these kinds of issues bugs show up, right, you know,
Speaker 1: make sure our accounting is super robust. But then you're
Speaker 1: talking about the voting, and it's hey, we've got to
Speaker 1: protect user data and make sure that you're right, so
Speaker 1: that the area is a concern or different.
Speaker 2: So how do you start to address that? And then
Speaker 2: from there, where.
Speaker 1: Do you start to dive in and make sure that
Speaker 1: you've got a sound strategy for making sure that you're
Speaker 1: meeting those requirements.
Speaker 4: Yeah, that's a good question. So, for let's just take voting,
Speaker 4: because it's up and hot and a topic these days, right,
Speaker 4: and so let's just start there. Oh so one of
Speaker 4: the one of the things there is that you definitely want,
Speaker 4: so I use them privacy. There's a few right there,
Speaker 4: like the whole user privacy, and then there's the vote secrecy,
Speaker 4: and then there is the it needs to be received free,
Speaker 4: and like there's a bunch of these academic properties of
Speaker 4: a vote and an election, right, and you go through
Speaker 4: each of those and you effect you just sort of
Speaker 4: sit down and you start at one and then you
Speaker 4: try and figure out how to do that. Right, This
Speaker 4: is really the job of the cryptographer, like how do
Speaker 4: we get this organized so that we match all of
Speaker 4: these and then once we have a viable protocol that
Speaker 4: will do this, then the developers come in and we
Speaker 4: look at the protocol and we go like, okay, this
Speaker 4: thing is about encrypting the vote. That needs to happen
Speaker 4: as early as we can possibly get it to happen,
Speaker 4: which means it needs to happen in the voter's device. Right,
Speaker 4: so we need to generate we need to pick a
Speaker 4: pick a curve cryptography curve, and then we need to
Speaker 4: basically generate key pass in the device, and we need
Speaker 4: to encrypt it as early as possible. And so you go,
Speaker 4: you go through sort of like rigorously and slowly and
Speaker 4: just sort of reason about when will this part of
Speaker 4: the process happen and where does it need to happen,
Speaker 4: sort of more on our timeline. Then we need to
Speaker 4: transmit the vote. We transmit the vote to the server,
Speaker 4: and then the server needs to basically allow if you
Speaker 4: need if you need to allow tracking, or if you
Speaker 4: need to allow receipts or whatever is the property you
Speaker 4: need to have, then you need to figure out a
Speaker 4: way to provide that at this point. And then you
Speaker 4: go on to something like anonymisation, which is effectively where
Speaker 4: you take one envelope out of the other envelope right
Speaker 4: to do the analogy that needs to happen in a
Speaker 4: way that you can prove that it happened. So you
Speaker 4: need to have a good trace here. You need to
Speaker 4: have good locks and traces that you can publicly show
Speaker 4: and then you know, so you sort of move through
Speaker 4: the chain sort of like the the event of an
Speaker 4: of a thing. Right, it's the same, and so you
Speaker 4: sort of need to reason about where is it going
Speaker 4: to happen. That gives you some ideas should we need
Speaker 4: do we need a web app? Do we need a
Speaker 4: mobile device, mobile app, do we need do we need
Speaker 4: to run cryptography, do we need to run something advanced
Speaker 4: on the user's device, or is the user's device just
Speaker 4: a portal? And and that gives you sort of ideas
Speaker 4: on or some insight into how this should be organized,
Speaker 4: how they should be tested, how they should be planned
Speaker 4: out right, But most importantly for for voting, is basically
Speaker 4: making sure that everything is tracked. And we grabbed part
Speaker 4: of the concept of blockchain, which is hash chain, right
Speaker 4: to basically hash everything together so you can't move stuff
Speaker 4: in the middle without everybody being able to know right,
Speaker 4: things like that. That's all yes, nice, that's nat w
Speaker 4: And for for like for banking, right, you want to
Speaker 4: you want to make sure that the point is to
Speaker 4: get money from A to B. So you want to
Speaker 4: reason about, well, first off, how am I going to
Speaker 4: get the number that they intend to send? Right, like,
Speaker 4: where does that come from? Where does the where does
Speaker 4: the sort of outgoing amount of money come from? This
Speaker 4: is the second one. It's it's hard to be home
Speaker 4: alone with with kids. But so you want to basically say, okay,
Speaker 4: so where does the money come from? And then you
Speaker 4: want to reason amount well, how can I prove that
Speaker 4: the money that came from there that I got it right? Like,
Speaker 4: how can I make sure that the intent was to
Speaker 4: send it to me? How can I make sure that
Speaker 4: the amount was correct? Right? Because like, like we talked
Speaker 4: about earlier with transfer wise, for example, there is a
Speaker 4: lot of web scraping. There's a lot of this sort
Speaker 4: of craziness going around less so now more so then right,
Speaker 4: And you want to make sure that you have I
Speaker 4: ever done it a few times that you were quite
Speaker 4: confident that you've run it on big data sets, Like
Speaker 4: you need to be certain that you can pass these
Speaker 4: things correctly, and then you want to sort of grab
Speaker 4: that information and then we get into the whole banging
Speaker 4: of how do you then move them? There's like swift
Speaker 4: and that's pretty taken care of. The only problem here
Speaker 4: was that it was slow. Right, So what we would
Speaker 4: do is that we would basically assume that if we
Speaker 4: could read the intended money here, we could effectively pay
Speaker 4: it out here immediately and then just do the in
Speaker 4: between transfer later. So we would basically have big stacks
Speaker 4: of money around the world and we could immediately pay
Speaker 4: out locally or take money in locally and then we
Speaker 4: would transfer later. So in that case, it was more
Speaker 4: question of can you verify the amount here, and can
Speaker 4: you verify that it's the sort of the correct amount
Speaker 4: and the correct intended amount, and can you then make
Speaker 4: that payout over here? Common as then can you do
Speaker 4: the payout here? Is there sufficient funds? And then after
Speaker 4: that you sort of say, okay, now we've we've effectively
Speaker 4: solved the user journey, right, we've taken money in, we've
Speaker 4: paid money out where effectively the user is happy or
Speaker 4: both users are happy. Right, nobody knows that we didn't
Speaker 4: actually move the money, and then we can take you know,
Speaker 4: take it slow, just do it properly, make sure that
Speaker 4: we interact with the Swift network. That's a bit slower.
Speaker 4: So you need to have a buffer in both ends
Speaker 4: to do it right and the things and the most
Speaker 4: important part here is the ability to scrape. Right. So
Speaker 4: when the critical points here was that you have to
Speaker 4: be able to always scrape these websites in some capacity,
Speaker 4: and you have to actually write your your code back
Speaker 4: then it was you know, scraping. You have to write
Speaker 4: it quite robustly and sort of reason about what happens
Speaker 4: if the layout changes, because banks change the layout surprisingly
Speaker 4: more than you would think because they don't care about
Speaker 4: your ability to scrape it. That's not their business, right,
Speaker 4: which is fair. It just means that you have to
Speaker 4: be you have to think about the robustness of a
Speaker 4: scraper like that, because what happens if the if the
Speaker 4: item is not classified the same, if the dumb element
Speaker 4: doesn't have the same class or the same idea as
Speaker 4: it used to have? Can we find it? By reasoning
Speaker 4: with words like can we figure out well, if it's
Speaker 4: like if it says some, can we maybe then figure
Speaker 4: out what's over here next to it? Because that might
Speaker 4: be then but I'm looking for, right, So there's sort
Speaker 4: of like reasoning like that that that goes on. That's yeah.
Speaker 4: And then there's accounting, like a lot of accounting, a
Speaker 4: lot of keeping tracks just for legal, legal in compliance
Speaker 4: reasons on where is the money going, who's it going
Speaker 4: to KYC, all of these. There's a bunch of tooling
Speaker 4: after that, right, which is sort of where I was
Speaker 4: introduced to this whole compliance thing, like how do you
Speaker 4: make sure that the people you're operating with I in
Speaker 4: fact the people that they say they are, and I
Speaker 4: in fact the right people that you're supposed to be
Speaker 4: operating with. Right, So that was also a journey like
Speaker 4: how do you even know that? How do you make
Speaker 4: tooling for them to identify themselves at the latest possible time.
Speaker 4: So it's the least amount of sort of burden or
Speaker 4: the least amount of friction and make it as easy
Speaker 4: as possible. Right, there's a bunch of proeters out there
Speaker 4: that that can help you do that. You can also
Speaker 4: do it yourself. It's not super complicated, but you are
Speaker 4: now dealing with people's private information because now you maybe
Speaker 4: have a copy of the passport. How do you deal
Speaker 4: with a copy of a passport? You have to be
Speaker 4: you have to sort of be like, Okay, where do
Speaker 4: I store this? How do I make sure that it's encrypted?
Speaker 4: How do I make sure that none of the none
Speaker 4: of the developers can access this? Right? Because you don't
Speaker 4: want developers to just as a sh onto the box
Speaker 4: and just be like, oh, let me just download all
Speaker 4: the attachments. So you need to be you need to
Speaker 4: make reasons, yes, or need to think about how do
Speaker 4: you then protect this data from yourself in some way? Right? Yes,
Speaker 4: that it goes deep and it goes far. Right, You
Speaker 4: can talk about this for a long time and about
Speaker 4: all the reasonings you have to make, but at some
Speaker 4: point you also have to protect your systems from other
Speaker 4: developers from other Also high level people in the organization
Speaker 4: needs to be kept out because the higher up you
Speaker 4: are the most the spear fishing you are or whaling
Speaker 4: you are effectively the subject of, and the greater the risk. Right,
Speaker 4: So you want people to not have access, maybe you
Speaker 4: even want the CTO to not have access. Like there's
Speaker 4: a bunch of considerations like this. In the banking one,
Speaker 4: I was a senior developer, I had access. Then we
Speaker 4: had the one of the compliance officers, she had access
Speaker 4: to the Swift network. And then but but the CTO
Speaker 4: and the head of sort of the COO type person
Speaker 4: didn't write because that would it post too much of
Speaker 4: a risk. So there's also like these human factors you
Speaker 4: have to think about when you reason about the security
Speaker 4: of a system that that actually impacts and it has
Speaker 4: something to do for real world people. That was a
Speaker 4: very long spiel.
Speaker 3: Sorry, It's fascinating when there's so much on the line,
Speaker 3: like most of the apps have worked on, like if
Speaker 3: it went down, it's like yeah, fine, o kay, it's
Speaker 3: not ideal, but it's not the end of the world.
Speaker 3: I kind of want to pick up on something you
Speaker 3: mentioned quite a while ago, actually on about type checking
Speaker 3: and sobay and stuff like that, Like, I'm very much
Speaker 3: a fan of the dynamic typing. I do have a
Speaker 3: background in static programming, like because I started as a
Speaker 3: mobile developers, so I spent a lot of time with
Speaker 3: objectivecy with Java and with Swift, So I do have
Speaker 3: that background. But ever since I kind of switched to Ruby,
Speaker 3: I just love that dynamic style and I just find
Speaker 3: it easier to work with. But I also get that
Speaker 3: when it's critical infrastructure that type checking it's just almost essential.
Speaker 3: So I'm curious, but why you went with Ruby and
Speaker 3: Rails when the infrastructure is so critical and type checking
Speaker 3: is scary something that's important to you, and that it's
Speaker 3: kind of bolted onto the language, So what motivated you
Speaker 3: to go with Ruby and Rails instead of something that
Speaker 3: has it natively?
Speaker 4: Yeah, So it is it is to high degree about
Speaker 4: the speed and the very well built testing frameworks that
Speaker 4: is around it. Right, So even if it's not statically typed,
Speaker 4: you can test a lot of things, and you can
Speaker 4: test it in a lot of ways. Typing is just
Speaker 4: or types. It's just one way of ensuring that the
Speaker 4: data is correct. That doesn't necessarily guarantee that the actual
Speaker 4: data you are trying to read in is of the
Speaker 4: correct format or whatever. It just means that once you
Speaker 4: read it in, it will fail because it's not the
Speaker 4: right time, So it depends a little on what you're
Speaker 4: trying to do. You can also, because it's dynamic, you
Speaker 4: can then sort of do things like, Okay, you gave
Speaker 4: you told me it was a CSV, and it's obviously
Speaker 4: not a CSV, and it obviously doesn't have a string
Speaker 4: where you told me a string was supposed to be.
Speaker 4: But I can see how this can look like a string.
Speaker 4: Maybe I can just make an interest string for you
Speaker 4: and move on right, Like, you have these options of
Speaker 4: making things go a little bit fast and a little
Speaker 4: bit smoother because you can sort of just fiddle a
Speaker 4: little around with it. What tends to happen in these
Speaker 4: systems as they grow older and as they mature is
Speaker 4: that part of the core of the system gets replaced
Speaker 4: with something like Java or Rust or something like that,
Speaker 4: so that once you have sort of you have a
Speaker 4: really solid part let's say the transfer engine, right that
Speaker 4: transfers from one account to the other, that hooks onto
Speaker 4: the Swift network. Maybe you want to move that into
Speaker 4: Genva or something that's more standing, more slow, but more
Speaker 4: type robust and more maybe even performance optimized for io
Speaker 4: or whatever it is that you need. Right, But then
Speaker 4: what tends to happen is that you still want the
Speaker 4: speed and ease of using Ruby on rails and having
Speaker 4: only a few developers do a lot of features so
Speaker 4: you can figure out what's good or bad, or what
Speaker 4: works or doesn't, or do a lot of development around
Speaker 4: trying out this new standard to verify with the engineers
Speaker 4: that it will in fact test correctly with this airplane,
Speaker 4: or you know, sort of having that capability to do
Speaker 4: feature spikes and to do tests or like mini projects.
Speaker 4: It seems to me that that is to some dey
Speaker 4: lost when you use a more as well some other language. Right,
Speaker 4: But but you are right, like, once you have it down,
Speaker 4: once you have it locked in, once you don't have
Speaker 4: any changes there, what tends to happen is it gets
Speaker 4: replaced with something that's fast or better for suited for
Speaker 4: the purpose. Yeah, I've seen that happen. So the reasoning
Speaker 4: is that you can go really fast with quite few people,
Speaker 4: and you can actually get something that's meaningful, that will
Speaker 4: affect people's lives, that will better somebody's life. You can
Speaker 4: get it done pretty quickly, right, Like you can get
Speaker 4: a a design system for to to basically do design
Speaker 4: some We're not talking like three D sketches of aeroplanes
Speaker 4: that that's not necessarily how you design all of it.
Speaker 4: That's just the building of it. But you also need
Speaker 4: to reason about the logic of who does who does,
Speaker 4: what are the processes, and you can get something like
Speaker 4: that build in seven eight months. Right, That's as far
Speaker 4: as I know. That's and what I could see in
Speaker 4: the market, right, And what happened was that we basically
Speaker 4: went a lot faster than everybody else, right, with this
Speaker 4: same amount of errors. Like it seemed that there was
Speaker 4: no real drawback to using Ruby in that case, right,
Speaker 4: And so it was a pure benefit to use the
Speaker 4: language in the framework.
Speaker 3: Nice you does. There's really nothing that can compare to
Speaker 3: the speed of development of rails. It's I think we
Speaker 3: kind of take it for advantage, like for granted, rather
Speaker 3: rails developers. It's when you go and look at the
Speaker 3: outside world is when you realize blood, yeah, this is
Speaker 3: a good tool.
Speaker 4: Yeah, yeah, it is quite insane.
Speaker 3: Hm.
Speaker 4: Like I had a colleague who did a you know,
Speaker 4: sort of an AI based a feature spike, you know, like, oh,
Speaker 4: can we just timebox this to like three days? And
Speaker 4: in three days we had a tool that seems to
Speaker 4: be working, did integrate with AI, had UI had tests,
Speaker 4: were behind the feature flag, and was effectively shippable. Right.
Speaker 4: It was not you know, it was not the best
Speaker 4: of the most robust or whatever. But like, in three days,
Speaker 4: a single person made a full featurespike that could technically
Speaker 4: be deployed and could work. Right, that's pretty amazing.
Speaker 6: I'm curious real quick, Like, uh, I'm in my experience
Speaker 6: working with like critical systems like this, Like once it's built,
Speaker 6: it's like it's hard to change, right, like and mostly
Speaker 6: because like to the requirements probably don't change very frequently either,
Speaker 6: But like, how how do you like approach in those
Speaker 6: cases like that change? Like is is it like build
Speaker 6: something new and cut one off and switched to the
Speaker 6: other or like what, I like, what kind of systematic
Speaker 6: approach do you take to that?
Speaker 4: I think so for me, it's certainly about you have
Speaker 4: to reason about the protocol and the process somewhere other
Speaker 4: than the application. So you have to diagram it or
Speaker 4: put it into dance or whatever you like to do.
Speaker 4: But we need to have a different place to talk
Speaker 4: about it than in code because we need to reason
Speaker 4: about when somebody has a change, we need to be
Speaker 4: able to reason about it before we spend time in code,
Speaker 4: and we need to figure out if the the sort
Speaker 4: of the signature of that particular change. Let's say you
Speaker 4: want to change one hashing algorithm with another hashing algorithm. Right,
Speaker 4: you need to be able to reason if that will
Speaker 4: break the system, just in principle, before you start to
Speaker 4: even try and implement it. Right, So I find that
Speaker 4: I it really benefits to have it in a big
Speaker 4: diagram or have it written out in long form in
Speaker 4: a document or like somewhere that you can reason with
Speaker 4: people who aren't developers on whether or not it will
Speaker 4: work or not before you even try to implement. Because
Speaker 4: if you can reason that it will in fact work,
Speaker 4: it will plug in, it will replace. If you can
Speaker 4: reason about that before you actually see the code when
Speaker 4: you come to the developers, it's a much smoother experience
Speaker 4: to say, okay, I need this piece replaced with that piece,
Speaker 4: And yes, the hashing algorithm is not the same, but
Speaker 4: it is whatever based on the same something something, so
Speaker 4: it will plug in, right, And then we can either
Speaker 4: have both if they plug well, we can replace one
Speaker 4: with the other and do and you can also then
Speaker 4: you need to trends or migrate the data.
Speaker 5: Right.
Speaker 4: But now that you're migrating the data, it's really nice
Speaker 4: to also have that conversation with beforehand and with others
Speaker 4: who are not developer. Well, we have existing data and
Speaker 4: you want me to plug this thing into this place
Speaker 4: in this big diagram. What happens to all the old
Speaker 4: data that went through that point beforehand? Like, what do
Speaker 4: we feel we need to do about that? Do we
Speaker 4: want to revision it and say that version less than
Speaker 4: something can never be opened again or can never be
Speaker 4: edited again, but can only be viewed? Like what's our
Speaker 4: reasoning on that? Right? So having somewhere else to talk
Speaker 4: about it then in code really helps to figure out
Speaker 4: if you should replace plug in or you know, make
Speaker 4: it as a different service that you called sometimes you know,
Speaker 4: whatever it is. I find that that having something other
Speaker 4: than code really helps. Yeah, so it really needs somewhere
Speaker 4: else to have that conversation.
Speaker 6: Right, Yeah, you know, it makes me think about the
Speaker 6: old days of Yahoo pipes, like where you could visualize
Speaker 6: and like in real time update the data flow of
Speaker 6: any particular aggregate thing you were trying to collect. Are
Speaker 6: there any tools like that that you use to like
Speaker 6: maybe automate this process or is it just a matter
Speaker 6: of getting documented?
Speaker 4: That's I mean, I've tried a bunch of them. I
Speaker 4: haven't found one that I really like. I haven't found
Speaker 4: one that really does it for me. I tend to
Speaker 4: try and make them diagrams as code because then they
Speaker 4: can at least get checked into get and we can
Speaker 4: have version control on top of it. But I haven't
Speaker 4: really found anything that really does it for me I've done.
Speaker 4: I tend to either do whimsical or draio or something
Speaker 4: like that, and then it is just a lot of
Speaker 4: work to keep it maintained. And that's that sucks a bit,
Speaker 4: But you know, it's it's hard to it's hard to
Speaker 4: do without right, without somewhere else to reason, and especially
Speaker 4: when you need to talk to because it's not only
Speaker 4: a technical problem, right, it is also a business problem,
Speaker 4: and it is a regulatory problem. If I'm going to
Speaker 4: change this piece of the testing bed for an airplane,
Speaker 4: or this piece of code for the design software for
Speaker 4: an airplane. I need to be able to have a
Speaker 4: conversation with somebody who's not a software engineer about the
Speaker 4: consequences of that, right, because I need to talk to
Speaker 4: the civil engineer, I need to talk to the test manager, youvely,
Speaker 4: and I need to talk to a lot of people
Speaker 4: about the consequence of doing it and the way to
Speaker 4: do it, and are there any consequences outside of my
Speaker 4: system that we need to have a conversation about it.
Speaker 4: It is just sort of like trying to get as
Speaker 4: many people joining that conversation as possible, And for that
Speaker 4: it seems to work better if it's not quite colde
Speaker 4: because then more people can participate in that conversation.
Speaker 6: Right, Yeah, I think that makes a lot of sense.
Speaker 6: I'm still personally trying to find the silver bullet, and
Speaker 6: the closest I've gotten is Mermaid.
Speaker 4: Yeah, and that also works quite well. Actually, it's just
Speaker 4: it works pretty It works pretty reasonable, and it is
Speaker 4: definitely a diagram as text. Right, So I've also used
Speaker 4: that a ton and it's decent enough. I find that
Speaker 4: it has some problems when you get up to really
Speaker 4: large size stuff like it's hard to get enough in
Speaker 4: there and still have it be viewable and understandable as
Speaker 4: a human. But I mean a lot of like building
Speaker 4: these systems and a lot of participating in building them
Speaker 4: is surprisingly not about code. It's about talking to a
Speaker 4: bunch of people who have nothing to do with software
Speaker 4: development and figuring out if you're going to break their lives, right, Like,
Speaker 4: are you going to break something completely insane that you
Speaker 4: had no idea that you ever were ever going to
Speaker 4: touch because you know, in the case of this, well,
Speaker 4: I'm going to change this thing in my design software,
Speaker 4: and then suddenly somebody in the factory somewhere is totally
Speaker 4: confused about how to build an airplane because I did
Speaker 4: something that you know. So it's really not that much
Speaker 4: of a software challenge. I mean it is, but it
Speaker 4: is to high degree a communication challenge and sort of like,
Speaker 4: how do we even communicate what this software does to
Speaker 4: people so that they can use it and so we
Speaker 4: can reason about the safety of it together the.
Speaker 1: Rine, Yeah, it makes sense in the I mean, I've
Speaker 1: worked on things at this level of complexity that you
Speaker 1: have to get right so I worked at Morgan Stanley,
Speaker 1: and I mean we weren't doing like banking level stuff,
Speaker 1: but we were doing like investment level and business information stuff, right,
Speaker 1: And so yeah, the world didn't end if we got
Speaker 1: it wrong, but we kind of needed it to get right.
Speaker 2: And a lot of it was just a matter of.
Speaker 1: Like you said, making sure that all the people who
Speaker 1: understand all of the concerns and all the things that
Speaker 1: it touched are able to weigh in and be part
Speaker 1: of the conversation and that way. Yeah, you don't do
Speaker 1: things without understanding the implications of how it's going to ripple.
Speaker 1: I'm working a contract now, and you know, I'm still
Speaker 1: trying to figure out the ins and outs of the system,
Speaker 1: and they're they're managing funds and stuff like that, right,
Speaker 1: and so yeah, I'm definitely feeling it here where I
Speaker 1: don't want to make any changes that ripple through the
Speaker 1: system and right. And so this is where you when
Speaker 1: you're talking about like testing and documentation and things like that,
Speaker 1: where the documentation really isn't around and there are a
Speaker 1: lot of other things. I wound up having to ask
Speaker 1: a lot of questions and I'm still not sure that
Speaker 1: all of my assumptions are correct. So yeah, a lot
Speaker 1: of this really helps in the sense of, oh okay,
Speaker 1: if if we're gonna nail down robust, you know, reliable things,
Speaker 1: then then yeah, you know, all of these things are important.
Speaker 1: And I think part of my issue with some of
Speaker 1: it is just that I like to just get in
Speaker 1: and solve problems. Right, I'm my mentality. I was talking
Speaker 1: to some other friends and the other day and my mentality.
Speaker 2: Is go go go, go, go, go go.
Speaker 1: And so I yeah, having to slow down and you know,
Speaker 1: dot all my I joke and say I dot all,
Speaker 1: my tea's across all my eyes.
Speaker 2: It just it's you know, it's it's not my natural state.
Speaker 1: And I think a lot of developers, yeah, they just
Speaker 1: they just want to write great code that solves problems.
Speaker 1: And so the meetings are tedious, the conversations are boring,
Speaker 1: you know, and you know, why can't I just go
Speaker 1: in and just.
Speaker 2: Make it work? And the reality is is, you know, yeah,
Speaker 2: what we're what we're talking about here?
Speaker 1: And so I think I think it's not just we
Speaker 1: have these specific concerns, whether the regulatory or something else.
Speaker 1: I think it's also that there's enough complexity to it
Speaker 1: to where you really do have to.
Speaker 2: Get in and understand the nuance of what you're doing.
Speaker 4: Yeah, and I think also the breadth of what you're doing, right,
Speaker 4: Like I know this for myself. Right when I was
Speaker 4: younger and started developing code, right, it was like, well,
Speaker 4: there's only one truth, right, Like either it's one plus
Speaker 4: one is two or it's wrong. Right, But that's just
Speaker 4: not the case when you have these really big connected systems,
Speaker 4: right where like, well, what happens if I change this protocol? Well,
Speaker 4: now it's right because it's a different protocol, But now
Speaker 4: it's wrong because it's a different protocol, So it can
Speaker 4: be both at the same time, right, because now you
Speaker 4: know all the other people who used it for one
Speaker 4: protocol can't use the other, and like it just gets
Speaker 4: really messy. I think at some point I realized that
Speaker 4: I like doing documentation, and that really helped to sort
Speaker 4: of make me be confident that this could be somewhere
Speaker 4: you can do a career, like you can do a
Speaker 4: career and something that's not obviously developer ish territory, right, Like,
Speaker 4: because I actually enjoyed doing like I could say to
Speaker 4: diagrams and reasoning outside of the code and all of
Speaker 4: these things I found was pretty interesting, and that makes
Speaker 4: it easier for to be me right, Like, it's more
Speaker 4: fun to have that conversation with everybody to figure out, well,
Speaker 4: if we do this thing over there in wherever we
Speaker 4: are operating in Australia, that's fine. But now we've done
Speaker 4: this change, so what happens to our operations in Austria,
Speaker 4: Like is that the same text system? Can we do both?
Speaker 4: Like it just it can become really complicated when you
Speaker 4: have when you're operating under multiple jurisdictions and multiple governances,
Speaker 4: right then that that can become complicated as well. And
Speaker 4: you know you're doing currency conversions, or you're doing unit conversions,
Speaker 4: or you're doing all of these things. Like it's so
Speaker 4: hard that I know that even the space agencies are
Speaker 4: getting it wrong. And sometimes there's stuff just won't work
Speaker 4: when you get it into space right because somebody miss
Speaker 4: uh converted interest to centimeters right, And so it is
Speaker 4: just and that should like to if you go to
Speaker 4: a a freak out of college developer and says to
Speaker 4: him that I need a unit unit conversion system, a
Speaker 4: unit conversion method that can go from interest to centimeters,
Speaker 4: that's pretty straightforward. That's a that's a pretty straightforward ask, right,
Speaker 4: and you can do that method pretty quickly. It's not
Speaker 4: really super hard. What is really super hard is getting
Speaker 4: people to use it right. So you need to build
Speaker 4: a unit conversion method that is easy to use, fun
Speaker 4: to use at hand when you need to use it,
Speaker 4: so that you will in fact use it because otherwise
Speaker 4: you're going to do it in your head. And then
Speaker 4: it doesn't really matter that you build a piece of software, right,
Speaker 4: So like it, there's a lot of other components to
Speaker 4: this than just the software, Like there's a lot of things,
Speaker 4: like you know, there's a lot of backup, a lot
Speaker 4: of everything. But it is also about making sure that
Speaker 4: the people who use it use it correctly. And the
Speaker 4: way to do that, like we talked about before, like
Speaker 4: with the TSB and everything, it's not to blame the
Speaker 4: person for not using the thing. It's to blame the
Speaker 4: thing for not being available when it was needed. Right,
Speaker 4: So you need to be like, if I have a
Speaker 4: unit conversion thing and it's hidden behind you know, a
Speaker 4: multiple three dot options that you need to figure out
Speaker 4: five levels in, that's the wrong place to have it, then, right,
Speaker 4: you don't blame the person for not using it. You
Speaker 4: blame the system for not putting it in his face
Speaker 4: when he needed to convert the measurement.
Speaker 2: Yeah, I like.
Speaker 1: I like that just from the standpoint of I mean,
Speaker 1: I guess, I guess where my brain goes is is
Speaker 1: everybody has the responsibility to understand the system and how
Speaker 1: it works, right, And so everybody has the responsibility then too,
Speaker 1: you know, to be aware that this method exists. But
Speaker 1: at the same time, if I create it, then it's
Speaker 1: also my responsibility to make sure everybody knows it's there
Speaker 1: and knows how to use it. And I also agree
Speaker 1: though that if you make it easy or natural to
Speaker 1: do the right thing, then people.
Speaker 2: Will generally do the right thing. Yeah, and so yeah.
Speaker 1: I think I agree with you, But I don't want
Speaker 1: to absolve anybody of the responsibility of learning to do
Speaker 1: the right thing either.
Speaker 4: No, No, I mean that's not what it. I mean.
Speaker 4: You can absolutely end up being blamed for crashing a
Speaker 4: flamee Like, it's not entirely out of the realms of
Speaker 4: like the pilot can be blamed, right, But it is
Speaker 4: also about looking at did we actually provide the correct
Speaker 4: tuning at the correct time, with the correct intensity and
Speaker 4: all of this, right, And it's the same here, like, well,
Speaker 4: the system didn't work well, did we provide enough, did
Speaker 4: we scale enough? Did we have enough compute resources? Did
Speaker 4: we have enough database storage? Was it just so slow
Speaker 4: that people couldn't use it and it crashed and somebody
Speaker 4: couldn't get their voting, Because if somebody couldn't get their voting,
Speaker 4: then you know, we sort of we get into the
Speaker 4: territory of oh, somebody prevented me from voting situation. Right,
Speaker 4: So it's like, yeah, they could have done it again,
Speaker 4: Like they could have just waited five minutes till the
Speaker 4: peak was down and voted again. But that's like it's
Speaker 4: also not really therefore, right, So it's there's a lot
Speaker 4: of there's a lot of sort of like ancillary non
Speaker 4: developer stuff to talk about when when designing. I'm pretty
Speaker 4: sure there is on old systems, right. But the fun
Speaker 4: thing here is just that this happens to include other engineers,
Speaker 4: which is very fun, And it happens to include things
Speaker 4: like cryptographers and people who actually like politicians or whatever
Speaker 4: it is. It's just I like the types of people
Speaker 4: that I get to talk and interact with, right in
Speaker 4: this rather than I get to talk less with marketing
Speaker 4: and social media and more with like people who build
Speaker 4: spaceships and aeroplanes, and I find that that's basically what
Speaker 4: drew me here, right, is this idea that I get
Speaker 4: to talk to other people who also have this engineering
Speaker 4: spirit and this idea to build something in the same
Speaker 4: mindset that I do.
Speaker 2: Awesome.
Speaker 1: All right, well, I think we're going to go to
Speaker 1: picks because we've been talking for an hour and fifteen minutes.
Speaker 1: This is cool, though, if people want to can act
Speaker 1: with you, or if they have questions about what you're doing,
Speaker 1: you know, maybe you want to pick your brain about
Speaker 1: some of this stuff.
Speaker 2: How they find you on the internet.
Speaker 4: I think go to LinkedIn. That's uh. I have more
Speaker 4: or less try to absolve myself of all social media,
Speaker 4: so LinkedIn is probably your best bet. It's my name,
Speaker 4: It's right there on the screeny thing there it is.
Speaker 4: And then also go go on Discorde. You can ping
Speaker 4: me there, PM me like you did. I'm both on
Speaker 4: the Camal, the rails and the Ruby servers, so you
Speaker 4: can just go find me there. It's E K A
Speaker 4: M P P. So just my initial letter and my
Speaker 4: last name.
Speaker 2: Nice I didn't know that there were Ruby and Rails discords.
Speaker 2: I'll have to go find.
Speaker 4: Those I can. I can send you invite links.
Speaker 2: That would be perfect cool.
Speaker 4: All right, there's someone for like rails developed. That's the
Speaker 4: Rails one, and then there's one for Ruby, which is
Speaker 4: more like application support and like, oh, I don't understand
Speaker 4: what this method does or I need to change this,
Speaker 4: whereas the Rails one is more for like, I need
Speaker 4: approvals or reviews of pians for the actual coal. So
Speaker 4: that's more about supporting of that. So it's less interesting
Speaker 4: if you're trying to solve a business problem, but it
Speaker 4: is kind of cool if you want to just peak
Speaker 4: at what the others are doing.
Speaker 1: Nice, okay, well let's go ahead and do some pics, Valentino,
Speaker 1: Do you want to start with picks?
Speaker 6: Sure, I've got nothing but AI picks. Today, there's been
Speaker 6: a lot of activity in the Ruby world. Andrew Kine
Speaker 6: has released yet another AI gem bless his heart. It's
Speaker 6: called Informers, and it basically lets you run inferants in
Speaker 6: Ruby on Onyx models. So lots of hugging face models
Speaker 6: are on supported and you can now just run inference
Speaker 6: with those. And he also has transformers are b if
Speaker 6: you are interested in running inference on non onyx models.
Speaker 6: So now we have like a complete picture hopefully those
Speaker 6: There are some some missing pieces still for larger models,
Speaker 6: but it has a ton of pipelines already built in,
Speaker 6: so I would suggest checking that out. The next pick,
Speaker 6: somebody built this awesome chat app where they've aggregated all
Speaker 6: of the rails and Ruby like articles and blogs and
Speaker 6: guides and everything like that, so you can basically rag
Speaker 6: the entire rails community ecosystem in a chat GPT style
Speaker 6: interface and it's it's remarkable and it does like citations
Speaker 6: and everything like that, so you can see the original
Speaker 6: article that reference whatever it was you're interested in. Uh,
Speaker 6: it's really awesome. It's called ship on Rails AH, and
Speaker 6: it's built with this really cool tool called Nausea, which
Speaker 6: provides basically like a rails app ready to go, so
Speaker 6: that you can ingest your own documents to rag against
Speaker 6: and do a very similar thing. It's really cool, so
Speaker 6: i'd recommend checking all those out.
Speaker 2: Nice. How about you are USh?
Speaker 3: I'm not sure what to take for picks this this week.
Speaker 3: I haven't really thought of anything. It's a it's a
Speaker 3: it's a cheap one, but I'm gonna go with Blue
Speaker 3: Sky because I'm quite enjoying blue Ska in the last
Speaker 3: week as I finally signed up for it, and a
Speaker 3: lot of Ruby folks have I have signed up recently.
Speaker 3: It's quite a lot of activity on there. I'm quite
Speaker 3: quite enjoying it as a social network. Hopefully it can
Speaker 3: stay the way it is. I'm active on both blue
Speaker 3: Sky and masterdon for But yeah, we'll see what happens
Speaker 3: because Blue Sky is still a VC fund that privately
Speaker 3: held the company, so we'd love to see how long
Speaker 3: things remain good. But for now, I'm quite quite happy
Speaker 3: with it. What else can I pick? I haven't really
Speaker 3: watched anything or anything new recently because I think I
Speaker 3: had picked a TV show called Shrinking, which I did
Speaker 3: the last time, so I don't want to pick that again.
Speaker 3: I'll go with the music pick because I always go
Speaker 3: with the music pick when I'm when I'm struggling. What's
Speaker 3: in fun of Me? The new Ts for Fears album?
Speaker 3: Check this one out. It's really good. It's a live
Speaker 3: album with a few new songs from eighties pop band
Speaker 3: Tis for Fears. So yeah, I think I'll go with those.
Speaker 2: Awesome.
Speaker 1: I've had a number of people tell me I need
Speaker 1: to join Blue Sky. So anyway, let's see, I'm gonna
Speaker 1: throw in some picks. So I played, I played a
Speaker 1: new game. I actually played a couple of new games
Speaker 1: this week because the game convention that I usually teach
Speaker 1: games at is UH is going to be on Saturday,
Speaker 1: and so I need to be able to teach these games.
Speaker 2: So I'm gonna pick one of those. It's called MOLEM
Speaker 2: l M L e.
Speaker 1: M, and essentially what it is is it's how do
Speaker 1: you describe it, It's it's cat astronauts, and the way
Speaker 1: that it works it's it's a relatively simple game. It
Speaker 1: was almost too simple for me, to be honest, But
Speaker 1: if you're kind of a casual board gamer, right, it's
Speaker 1: it's definitely approachable. So let me pull it up a
Speaker 1: board game geek. But yeah, so what the way that
Speaker 1: it works is you have astronaut cats that are going
Speaker 1: going into space and they're basically occupying planets and moons,
Speaker 1: and so you.
Speaker 2: Pick one of your.
Speaker 1: Your cats, put it on the rocket, and somebody's the
Speaker 1: captain and they roll the dice and if they're if
Speaker 1: the dice match what's on the space on the board
Speaker 1: that you're on. Then you can choose which dice to
Speaker 1: use in order to move up the board. Right, And
Speaker 1: so if you if you have boosters, boosters move you
Speaker 1: up for free. The other ones you have to give
Speaker 1: up the dice in order to move. And so if
Speaker 1: you ever get to the point where you roll the
Speaker 1: dice and you you can't use any of the numbers,
Speaker 1: then use the ship. And at any point people can
Speaker 1: get off the ships onto moons or planets, and you
Speaker 1: get points for having the most cats.
Speaker 2: On planets, you have points for every moon you occupy.
Speaker 1: If you go away to deep space, then you get
Speaker 1: bonuses for that. And then the different cats have different abilities, right,
Speaker 1: so one of the cats let you start further up
Speaker 1: the board. One of the cats let you you know,
Speaker 1: let you get off the ship after it crashes, right,
Speaker 1: so you can go to the planet it's next to
Speaker 1: or whatever. When it crashes. One of them gives you
Speaker 1: a bonus, doubles your points for the planet it's on.
Speaker 1: One of them doubles the points for the moon it's on. Anyway,
Speaker 1: you get the idea. One of them doubles the points
Speaker 1: if you're in deep space, but deep space is hard.
Speaker 1: I've played it once and we never made it to
Speaker 1: deep space. We got close a couple of times, but
Speaker 1: then I was talking to some other people a couple
Speaker 1: of other times, and one of the times they played,
Speaker 1: they made it deep space like three or four times.
Speaker 1: So anyway, so if you're the captain, you're rolling, and
Speaker 1: then you just rotate who the captain is. If the
Speaker 1: captain gets off the ship, then the next person in
Speaker 1: line just finishes out that round.
Speaker 2: Anyway, that's basically the game.
Speaker 1: Or game Geek has it as a at a one
Speaker 1: point six y eight weight.
Speaker 2: It says ages eight plus, and yeah, I have an
Speaker 2: eight year old.
Speaker 1: She could definitely play it. It says thirty to sixty minutes.
Speaker 1: That's probably about accurate play two to five players. I
Speaker 1: played it with four players and that felt pretty good.
Speaker 1: So it's mele M L E M Space Agency and yeah, anyway,
Speaker 1: check it out.
Speaker 2: And then I'll just put a link in the comments here.
Speaker 1: And then let's see. I'm not sure if I really
Speaker 1: have any other picks. I know, I've kind of been
Speaker 1: doing other things and getting involved in other things, but
Speaker 1: I guess the big thing that I went through this
Speaker 1: lately as I went up to retreat up in Sundance,
Speaker 1: which is actually like forty five minutes from here. If
Speaker 1: you heard of the Sundance Film Festival, they do actually
Speaker 1: do that in park City, not in Sundance, but.
Speaker 2: From here, it's about.
Speaker 1: Two thirds of the way to park City and anyway,
Speaker 1: it's up Provo Canyon. And these guys were running essentially
Speaker 1: a Mastermind for three days for Christian entrepreneurs, and so
Speaker 1: we did a lot of faith based stuff, we did
Speaker 1: a lot of business based stuff, and it was amazing
Speaker 1: because they just kind of helped me get clarity on
Speaker 1: what I want to do and who I want to
Speaker 1: be and what kind of difference I want to make.
Speaker 1: So just keep an eye out because I have stuff
Speaker 1: in the works. But it was terrific and I really
Speaker 1: want to just put forward. I guess that just connecting
Speaker 1: with other people who are doing what you're doing, or
Speaker 1: who are learning what you're learning, or who are maybe
Speaker 1: a little ahead of you want on the path you
Speaker 1: want to go down so helpful, So so helpful, you know,
Speaker 1: kind of like what we were talking about with like the
Speaker 1: Discord servers, right, So much help helpful stuff there. So Anyway,
Speaker 1: those are my picks, Emil, what are your picks?
Speaker 4: And so recently, I'm going to pick a book. I
Speaker 4: recently read a book called How Big Things Get Done
Speaker 4: and it's by a Danish guy called bat Flubia. So
Speaker 4: what he did was that he went I don't know
Speaker 4: if you guys know it, but he went through statistical
Speaker 4: data on overruns on big projects, like how far behind
Speaker 4: is an IT project in general? How much of an
Speaker 4: overrun on cost do you get? How much of an
Speaker 4: overrun on time do you get? And he goes through
Speaker 4: sort of like these different industries and different factors that
Speaker 4: play into to why why big things fail and why
Speaker 4: some big things get done right, like what are the
Speaker 4: ways to make sure that big things gets done and
Speaker 4: what are the pitfalls and everything, And he goes through
Speaker 4: everything from the Sydney House Sydney Opera House to like
Speaker 4: big government IT projects that fail. It's just super cool
Speaker 4: because it's very sort of data driven and he has
Speaker 4: spent his career collecting data on why big projects fail,
Speaker 4: why all kinds of projects fail. So it's a really
Speaker 4: interesting sort of window into do this if you really
Speaker 4: want to mess it up? So by inversion, if you
Speaker 4: don't want to mess it up. Don't do all of this,
Speaker 4: do do the other thing. Right, is that that's kind
Speaker 4: of an interesting statistics to have, and so yeah, how
Speaker 4: big things get done? I found that was really.
Speaker 2: Cool, awesome.
Speaker 1: All right, well, thanks for coming, Emil. We're gonna go
Speaker 1: ahead and wrap it here.
Speaker 4: Thank you for having me.
Speaker 2: It was a pleasure, and until next time, Max out