Embracing Human Factors and Rapid Development in Ruby on Rails Systems - RUBY 661 - Ruby Rogues

Episode Transcript
Available transcripts are automatically generated. Complete accuracy is not guaranteed.
Speaker 1 (00:04):
Hey, folks, welcome back to another Ruby Rogues.

Speaker 2 (00:08):
This week on our panel we have a Yushinwatya Hello.

Speaker 3 (00:11):
Hello.

Speaker 1 (00:13):
We also have Valentino Stole and now I'm Charles Maxwood
from Top Endevs. And this week we have a special
guest and that's Emil.

Speaker 4 (00:22):
Come hey, everybuddy.

Speaker 1 (00:25):
So Emil, I'm just gonna clear my throat because wow, okay,
let me.

Speaker 2 (00:31):
Try that again. So Emil, I found you.

Speaker 1 (00:34):
I've been corresponding with people some on the discord for Kamal,
which is the deployment technology that DH put out. I
think he made kind of a deal about it at
Rails World last year, and then a whole bunch of
exciting stuff this year with Kamal Proxy and stuff like that.

(00:56):
I mean, I switched over to and I switched over
from Mall to the Mall too, with all much of
help from you and others on there. And I have
to say switching over was a little rough. Having switched over,
it's a lot nicer. So anyway, so beyond kind of

(01:18):
what I know about you from that, what should people
know about you?

Speaker 4 (01:23):
Well? So I think, first off, I am a mountaineer,
and in order to facilitate that I live in a
very flat country, so I do a lot of running,
and then I need to pay for my travels, so
I do also engineering. And I've made a career of

(01:44):
doing sort of critical infrastructure or things that have real
world impact and real world consequences if something goes wrong, right,
So both in terms of security and robust list and
things like that. And that's everything from the fintech or

(02:06):
the payment industry, to civil engineering to online voting.

Speaker 2 (02:15):
Wow.

Speaker 1 (02:16):
Yeah, it sounds like kind of what our topic is here,
which is building critical infrastructure. So you've done some stuff
that I kind of need to work, I guess.

Speaker 4 (02:28):
I mean, so a banking obviously needs to work when
people get sort of pissed if they don't get their money.
And then for civil engineering, I worked on tools that
the engineers would use to build the airplanes, which and

(02:49):
run tests on them. Right, so both test benches and
design benches for airplanes. And I mean that has a
real world consequence because they fall out of the sky,
right if you mess it up. Yeah. And then yeah,
online voting, that's the whole thing. And you guys in
the US just went through one one of these messy

(03:13):
events and they're messy everywhere, right, And recently I moved
to two compliance and sort of making trying to make it,
trying to make that easier and a better experience to
become compliant and to obtain certifications.

Speaker 2 (03:36):
Right, makes sense, So let's just dive in.

Speaker 1 (03:40):
I mean, I'm not I'm trying to think if I've
ever worked on anything that was you know, kind of
at the level of, hey, if this breaks.

Speaker 2 (03:49):
Then you know, really bad things happen.

Speaker 1 (03:54):
I mean, if it breaks, I've had them come to
me and be upset, like really bad things happened. But right,
it doesn't affect society at large. What's the difference between
working on those apps and working on just kind of
you'r you know you mentioned not e commerce or not
you know, hey I've got to manage my social media

(04:15):
or you know, get podcasts out on time.

Speaker 4 (04:18):
Yeah, I mean, there's nothing just to be here, There's
absolutely nothing wrong with that, right, That's just I started
out in that area, as many developers do, right, building
like some ad system when I was very young, and
then moved to some you know, sort of off a platform,

(04:39):
and then I sort of realized that it was it
was just inconsequential in a way, right, I looked at people,
you know, I had people around me. My father was
is a civil engineer, right, and so I have people
in my sort of my family, my near family, that
was building things in the real world. And I was like,

(04:59):
I want to do that, but I do like this
computer stuff, So can we sort of maybe find a
way where I can build things in the real world
just using my computer. And so I slowly started to
shift over into something that was founded more in civil
engineering and sort of industry rather than commerce mm hmm.

(05:23):
And then I started in a fintech company where we
were where I was part of building, building out and
continuing to build on a on a system where you
can basically it's like direct debit bank transfers, but worldwide, okay,

(05:48):
so and and there. It doesn't necessarily mean a lot
to you and me. And it's the same with there's
a bunch of them now, right, like these send money
home types of things. It doesn't mean a lot to
you and me, but it does mean a ton to
those who is on the receiving end of that, right,
because that's like half a year's pay or something that

(06:10):
comes in, right, So it does matter to those people
so so yeah, that was sort of where I ended up.
And we are moving a lot of money, like it
it seems it's one of those where little like it's
it's a lot of tiny things that add up. Right,
There's like millions and millions and millions of dollars being

(06:31):
moved around for that purpose, and you don't want to
miss handle those money. Right. So you are hooking into
the to the banking infrastructure, into Swift and into the
IBAND network and the whole sort of PC compliance and

(06:52):
everything with that, right, so you need to make sure
that the software is robust well tap that testing has
been a main thing of mind for a long time
because of that, and also documented well. Right, So that's
where I sort of started out with being required to

(07:13):
document what I was doing and how it was supposed
to work. Rather than just shipping fast and breaking things.
I was required to test and document, then test, then
stage it, then test some more, then ship and not
break things. So that was a different paradigm. Yeah, so

(07:35):
that's sort of where I first met that, right, And
that was a pretty great experience, and so I was like, oh,
can I have more of this? Can I maybe even
get even closer? Right? Yeah? So that's uh, that's where
all that started. And then I was hooked on the
whole can we test it? Can we build something that

(07:58):
runs Ruby on rails but make a difference to people's
lives like in real world? Right, So this was basically
a payment situation, just building Ruby and rails, and back
then many of the banks didn't have a proper API,
so we ended up scraping a lot and that's you know,

(08:20):
against terms of policy, in terms of service and all
of that, and they were really mad and we went
through that whole spang of getting you know, sort of
scolded for that for a while. Yeah, So that it
was a bit the wild West back then, but it's
definitely gotten better. And I think there's a lot of

(08:42):
again sort of compliance work and lew work that went
into the EU did a lot to make sure that
banks would have not standardized, standardized APIs, but a minimum
level of information that you could retrieve with an A,
which made all of that a lot easier.

Speaker 5 (09:03):
Right.

Speaker 4 (09:04):
It also means that I can technically build my own
banking app for my own bank account because I have
API access to it. It may not be obvious, it
may be poorly documented, but it is there, and so
I think that's pretty cool.

Speaker 1 (09:19):
Yeah, I'm curious, Valentine or I usually have experienced doing
this stuff.

Speaker 3 (09:28):
Nothing that critical.

Speaker 2 (09:30):
Now.

Speaker 3 (09:30):
The closest I kind of came to anyone near that
world was when I worked for transfer Wise, But I
was an iOS developer, so I didn't really have to
do any of the hard stuff. I just made API calls.
But I know they were also doing quite a lot
of the scraping and stuff. There's a lot of selenium
going on behind the head to get into different bank accounts.
It's uh, yeah, it's it's all a bit scary when

(09:54):
you think about it.

Speaker 4 (09:58):
Yeah, yeah, it really is, because it's like your whole
banking experience is tied up on some scraper working correctly
and not messing around with the the thousands delimiters and
the the scent comments are different on different regions, right,
so you don't want to mess around with that. I
did transfer some money incorrectly. Luckily, the backbone banking system

(10:21):
is pretty robust as well, so we were able to
basically not move the money anyways, right, but it I
did move far too many money the wrong place. Yeah,
that was a back breaking day.

Speaker 2 (10:41):
I'll bet.

Speaker 1 (10:42):
So I'm a little curious as we get into this,
Like you mentioned testing, what what is your what does
your testing set up look like?

Speaker 2 (10:52):
Because I mean, I I'm sorry.

Speaker 1 (10:55):
When I write my test, it's like, okay, it's good
at Like I'm I'm reasonably confident, right, but I'm not
like iron clad confident, like baking level confident that my
code works.

Speaker 2 (11:05):
Right.

Speaker 4 (11:07):
Yeah, yeah, that's a good question. I tend to not
be too dogmatic. I know there's a lot of like
do this or do that paradigm or do test first
or whatever. I tend to just play around with it
and make myself certain first that this is gonna work

(11:31):
whatever I'm sitting with, and then when I know that
it you know, sort if I can see like okay,
it works, it does what I needed to do, then
it is worth testing, right. And then it's I try
and test on the lowest possible level first, which means
I will start with something like unit tests, and for

(11:55):
that I want to permute everything, right. You want to
make sure that every argument, So you basically start with
the least amount of arguments for a method, and then
you add an argument slowly. In I use aspects, so
it's in every context block or in every described block. Right,
so you're you're certain that every version of every argument

(12:18):
is is tested and has been permuted. Yeah, so that everything,
like every variable has been tested on its own, so
you know how it behaves both with and without that
particular variable, and you also know how it behaves if

(12:38):
the variable has the wrong type.

Speaker 2 (12:41):
Right.

Speaker 4 (12:44):
So because Ruby isn't quite where we have type safety yet.
There's a lot of work going on with that, but
we aren't there yet. So I, you know, you want
to make sure that we can handle strings, numbers, not strings, truths, boollians, whatever.

(13:06):
There's like I have a little thing that basically says,
take this and just you know, cycle it through all
of the different types it can be, and just put
in garbage so that I know it can not it
doesn't break when a number is presented rather than a
string or something stupid like that. Right, And then you

(13:29):
sort of you slowly move up so you're confident that
this method works, and then you move up to have
recalled it, and then you I what I do is
I then I go through and test that. But I
think opposed to what is DHH preaches or or at
least sort of he he has this idea that you

(13:52):
would go through the entire stack, and I believe that
they had their tests to do that. I tend to
not to sort of stop testing at each level, right,
So model tests are their own thing. And then when
you test the controller, you basically verify that the model

(14:12):
is being called with the expected parameters, because you know
you've already dealt with the parameters on a lower level.
So it's not mocking per se. It's just that I
only need to test that the model was created or
was called. I don't really need to test that it
was the correct arguments, right, because I'm certain about the

(14:35):
correctness of the arguments on a lower level than that.
And then you saw slowly move up, which means that
I find that that means that the individual testing levels.
It gives you a little bit more freedom to sort
of move a model around because it's coupled somewhat on
a test level, but not tremendously, right. I only coupled

(14:59):
the controller the model in the sense that I checked
that the model was called, not that it was called
with a particular set of arguments. So it makes it
a little bit easier to also restructure your tests when
your code change. But it's just a lot of work
on lower level things. I'm a big fan of Spey,

(15:19):
but it's not it's not quite there yet. I think
it works reasonably well, but it's very hard for developers
to use, and so I think we need to do
there needs to be a lot of work done in
terms of making it nice and sexy to use so
that we can get people to use it right.

Speaker 6 (15:41):
I'd love to dig in a little bit more on
the aspect because one of the biggest things I see
miss is maybe like skipping over like the maybe some
lower level implementations and then like a system update break
something and it just wasn't covered right, Like how do

(16:01):
you go about, like you know, waiting whether or not
that it's worth it to like actually run like a
system command or an external API call or something like that.

Speaker 4 (16:13):
Yeah, So system commands, I usually check just that the
signature of the call is correct and probably that it
returned the right thing right, so that if I hit
the OS, I'm basically testing that I gave it these
parameters and I expected something back like a string or

(16:36):
whatever it is right, because it's so hard to know
what it was supposed to be because sometimes the system
commands will change their signature but not necessarily return value
or the return value, but not the signature. So that's
that's very hard. I try to not go there. I

(17:00):
tried really hard not to go there because it is
it's out of my control. Right on the other end,
when I called other APIs, I definitely test that I
use something like me CR or something. I capture all
the network traffic, and I make sure to do the
same kind of sort of making sure that if I

(17:22):
call it with these arguments that I have control over,
I get this particular response, and if I do something
else then then it breaks right or it gives me
the incorrect response. And I also found that, for example,
with with banking, that one of the cool things we

(17:43):
did was that we basically took all of the historical
records right that we had for all the bank accounts,
and we basically used it as a test bed because
then you can train on that. You can basically say,
if I feeded all of this information that we know happened,

(18:03):
and it happened correctly because it happened, you know, but
a year ago or two or whatever, it should result
in the in in a particular set of of like
it should result in a particular value on the account. Right,
So you can actually use historical data as a test

(18:24):
that and that makes that means that you have a
factual way to check if it's correct or not. So yeah,
I tend to use that as well. I also used
that when when I did software for the for the
for the sort of civil engineering and building flights and

(18:45):
testing that. Right, we also used a lot of existing
information to make sure that we had input output, so
we understood that given these inputs, this is the output
that we would expect. Right, We could basically take old
designs and try and run them through and you can
see if does it break it down like you would expect,

(19:08):
does it run the does it sort of fit to
the engineering standard design standard that we were implementing against.
They also have test and value that you can use, right,
or test data. So it's also about going out and
finding big test data sets that you can use to

(19:30):
also make a statistical sort of approach. Right, I'm not
making any statistical claims, but I am running a lot
of tests on a lot of data that you know,
you can be reasonably certain that that if there were
errors in your system. It would have been caught by
this because it's so much effective effective production data. Right.

Speaker 6 (19:55):
Yeah, I imagine that working with like the public sector,
that you would have a lot of access to that data, right,
I guess depending where you live.

Speaker 4 (20:05):
Yeah, I mean, I mean interesting enough. None of this
is for the public sector, which is a little bit weird.
You would think that it was, but it actually isn't.
Like the regulation of the aerospace is public sector, right,
but the actual building of airplanes is a private commerce,
ran private industry. And likewise, with banking, the the regulation

(20:28):
of it is public, but the actual banks are private entities,
and likewise.

Speaker 6 (20:35):
We find it difficult for like the data access, like
is that data proprietary then for like doing large swaths
of tests or finding it.

Speaker 4 (20:47):
Yes, but most of the times the companies are interested
in providing it, right, Like if you if you go
out to big to big airplane or aerospace company and
your unique to design a test system for them or
something to help them build, right, they are interested in
giving you that kinds of dace. So it wasn't that

(21:08):
it was hard. It's just that it is also quite
narrow in scope, Like it's it's more more or less
only for that one.

Speaker 5 (21:16):
Right.

Speaker 4 (21:17):
So in banking, it would be a lot of records,
but only for one bank, so you would only know
how it looked in one type of account system, right,
and then you would run over your tests and that
and now two seconds all right, yeah, there we go. Hello.

(21:48):
I So, so it's not that it's hard to get,
it's that it is it's quite narrow in terms of
sort of like what, Yeah, it doesn't have a lot
of breadth. You get it for like one bank or
one airplane company, or you get it for one company
who runs elections. Right. Public elections is a bit different

(22:13):
by definition. You don't have any test data because all
of the records are sort of you don't know who
who voted, so you can't know how to test that, right,
So you have to do a different testing paradigm there.

Speaker 2 (22:30):
Yeah, that makes sense.

Speaker 1 (22:30):
I mean here in the US we have a anonymous
ballot as well, right, yeah, And I don't know how
they do it in other states.

Speaker 2 (22:38):
I mean I'm involved in the process here in Utah.

Speaker 1 (22:41):
And yeah, you send in your envelope and they with
your ballot in it, and they validate that your like
your signature matches and stuff.

Speaker 2 (22:49):
Off the envelope.

Speaker 1 (22:51):
But then they pull your ballot out of the envelope
and put it in the pile to be counted, and right,
they don't they track who you voted for in that case,
at least they're not supposed to correct.

Speaker 4 (23:04):
And that is also the case for the digital solutions.
A friend of a colleague of mine, Stefan, who is
a cryptographer. He or previous colleague of mine, he did
a lot of work of sort of gathering together a
lot of the academic work so that we could exactly
do that in a cryptographically safe way but online m

(23:31):
and you could also do it in a way that
it was you know, you could track it, and you
could ensure that this was in fact the case, Like
you could give the the lock data and the trace
data to mathematicians and they could verify that mathematically. It
could only ever have worked if these rules were followed,
which was like you know, you anonymized, and you did

(23:54):
you did mixing, and you did a.

Speaker 1 (23:55):
Lot of these things, right, right, So you protect the
identity of the voter, but you also ensure that only
people who are legally permitted to vote vote and that
they're only cast one ballot and things like.

Speaker 4 (24:08):
That, Yeah, exactly, And the test, the test sort of
the build idea for that and the testing regime for
that is significantly different, right because this isn't sure the
public space to your point earlier, Valentino, this is a
public domain, right, so you you are a bit more scrutinized.

(24:28):
You're also publicly scrutinized by everybody, right because we all
know how it went with the dominion voting machine case, right,
that went real fast, Will Downhill.

Speaker 1 (24:42):
Yeah, so yeah, well and you bring up the dominion
voting machine case and whether you believe that they worked
or didn't. There if there's enough population that doesn't trust it,
then it causes problems, right, Yeah.

Speaker 4 (25:00):
And that's that's the same everywhere, right, And that's I
found that sort of on a on a completely different
but somehow related topic. I really found that the aerospace
or the airplane industry was was really good because the
what's the American one, the TSB Transportation Safety Board? Is

(25:24):
that tis be right? Yeah, those are the ones that
that they do crash audit that sort of like go
through both them and the European counterparts have a really
really cool way of going about it. They don't ever
go and say, oh, it was that person's fault, right,

(25:49):
if if the person hadn't slept enough, if the person
couldn't read the dials, it is the fault of their
plan that that made him not have enough hours to sleep,
and it is the fault of the dial for not
being visible enough. Right, So it's not They don't ever

(26:09):
cast personal brain or they very rarely cast personal Blane.
And I really thought that was a super cool way
of going about it also just from a sort of
like evaluating if something works well right, just like from
a human perspective, and when you do leadership in tech
or if you diet or lead others. That I found

(26:31):
that really valuable sort of that whole way of thinking
about it. And they also they collect a ton of evidence, right,
They have a very structured way of collecting that before
they then conclude that it works or didn't work, or
that this was the fault of that was the fault.
But they also I think I learned a lot also

(26:54):
in terms of like having redundancy, Like what happens if
this thing break, what happens if your job runner doss run,
How are you alerted? What happens if your email doesn't send.
How are you alerted? How do you have alternative options?
Do you have an alternative email provider that you can
switch to easily? Do you have alternate job runners that

(27:14):
you can switch to easily? Do you have any of this? Right? So,
that redundancy idea ideology was pretty cool, and I'm for
like large scale systems. It pays off to have extras
of these, even though you know, you use somebody like
sent grid or use somebody like mail chimb or something,

(27:36):
and you know, they say that they scale and they
do right, but then ever so often it's down, and
it's pretty nice to have a backup, even if it's
a tiny backup, and even if it's just you know,
up and coming fairly cheap one, it will do the
job for like a day, right, and you will actually
still send stuff out, or you will still process jobs,
or you will steal whatever it is. Right. Also, running

(28:00):
like on the big scale, running something like multi cloud,
or running something I can open stack where you can
actually move to somewhere else pretty fast. There was that
case with that the Australian case where the where the
bank got taken down because someone at Google decided to

(28:22):
delete their account right, for like one hundred and sixty
million US worth of servers just got mute. So for
those cases, it's pretty nice to have a second provider
back up and some way of getting there. Right. That
is more a DevOps problem. It's not really a problem

(28:44):
that I've ever solved. It's a problem that I have,
you know, sort of like assisted with and talked about
and verbalized a lot in companies. But it is to
high degree of develops a solution that needs to go
in there, and not one that I am gonna build.

Speaker 6 (29:01):
So you're talking a lot about like people's lives and
you know, their livelihood, their money, like things that sustain life, right,
and so like obviously these infrastructures are critical, like white
tools using are critical. So I'm curious, like what about
like Ruby and Rail's you know specifically feature wise, like

(29:24):
do you see as being like, oh, this is like
part of that critical process.

Speaker 4 (29:31):
I think the main part for me is that it
can be built. You can write it so that it
is absolutely readable and understandable what's going on, so you
can reason about the what's going to happen, even without
necessarily understanding the language fully or even without understanding what

(29:54):
this active record method is going to do underneath. Because
stuff is name WILL, and because it's ordered and organized will,
you can reason about what's gonna happen, and you can
have an expectation. And it makes it a lot easier
to build complicated things, like you can go and test
it afterwards, right, But just getting something that's complicated up,

(30:18):
like just getting it up on its legs. It's really
nice to have something that that is structured well and
that you can reason about and that you talk about
sort of what's the consequence of this method or that method?

Speaker 5 (30:32):
Right, yeah, yeah, yeah exactly.

Speaker 4 (30:47):
But I think and also I find that it's I mean,
I've done a few frameworks throughout my career, right it,
I've always come back to the rails and Ruby, and
I also started there, so maybe i'm by it, but
I haven't found any of the other frameworks that provides
the same sort of consistent experience through every part of

(31:11):
the application, whether or not you're doing low level active
record stuff or you're doing high level system tests or
whatever you're doing. It's consistently the same experience everywhere, which
means that it's fairly easy for a developer to switch
gears and do something else right in the stag. I mean,

(31:34):
so like you can have a person who's sitting and
doing the swift transfer one week, right, and then he
can go and he can look at the webscraper the
next because it's consistently the same experience, and you can
write it in a way if you have a good
sort of if you have a good style guide, and
you have good code review, you can get it to

(31:56):
a point where it's the same experience every time, and
you can get abstraction levels and abstraction layers that feels
the same, and that makes it easy to build something
that where you can also easily plug out something and
put something else in right that you can switch out

(32:17):
one database provider for the other without much plot them right,
or you can do whatever. Whatever it is that you
feel like you need to change can be quite easy
and quite straightforward if you've set it up to be.
And I'm not necessarily talking about modularity in the sidewak

(32:39):
level of aggressiveness that that the Shopify has, right, but
you can you can definitely do something along those lines
with just talking about it, organizing that, organizing the code well,
and and just sort of thinking about how is this

(33:02):
going to be tested. I find that that's also part
of it. Right, It's like, how are we going to
test this? Because if we are going to if we're
going to test it in this particular way or that
particular way, then that that informs the API and the
sort of the interface for it. And a database you

(33:24):
tend to test the same way. You know, if it's
file uploading or downloading, you tend to test that the
same way, which makes it easy to switch out one
component for the other if your test paradigm is the
same right for that component. So I feel that's that's

(33:45):
some of the reasons that I've chosen this again and
again right and also liked j said on his keynote,
this is a one like it can be a one
man army. Right. You can be pretty fast and pretty
dangerous with it, which means you actually need fairly low

(34:07):
hepcount to get somewhere really fast, and you can actually
get something that's really secure, solid, safe, robust and easy
on the eyes and nice to use with only a
handful of people. Right, you can get somewhere with just
one person, but you can definitely get a long way

(34:29):
with a handful of people.

Speaker 2 (34:32):
You are so speaking my language, man, this is why.

Speaker 4 (34:37):
Yeah.

Speaker 1 (34:37):
So, one thing that I'm wondering about with all of
this is, you know, it sounds like depending on what
the concerns are in the app, right, So whether it's
banking or voting or right, you may have different concerns
about up time, verstability or you know, resumability, you know,
if Google deletes all eighteen hundred year servers or you whatever. Right,

(35:03):
So how do you begin to start looking at your
application and saying, well, you know, for example, in banking, right,
we have to make sure that we don't have any
of these kinds of issues bugs show up, right, you know,
make sure our accounting is super robust. But then you're
talking about the voting, and it's hey, we've got to
protect user data and make sure that you're right, so

(35:25):
that the area is a concern or different.

Speaker 2 (35:27):
So how do you start to address that? And then
from there, where.

Speaker 1 (35:31):
Do you start to dive in and make sure that
you've got a sound strategy for making sure that you're
meeting those requirements.

Speaker 4 (35:38):
Yeah, that's a good question. So, for let's just take voting,
because it's up and hot and a topic these days, right,
and so let's just start there. Oh so one of
the one of the things there is that you definitely want,
so I use them privacy. There's a few right there,

(36:00):
like the whole user privacy, and then there's the vote secrecy,
and then there is the it needs to be received free,
and like there's a bunch of these academic properties of
a vote and an election, right, and you go through

(36:21):
each of those and you effect you just sort of
sit down and you start at one and then you
try and figure out how to do that. Right, This
is really the job of the cryptographer, like how do
we get this organized so that we match all of
these and then once we have a viable protocol that
will do this, then the developers come in and we

(36:44):
look at the protocol and we go like, okay, this
thing is about encrypting the vote. That needs to happen
as early as we can possibly get it to happen,
which means it needs to happen in the voter's device. Right,
so we need to generate we need to pick a
pick a curve cryptography curve, and then we need to

(37:06):
basically generate key pass in the device, and we need
to encrypt it as early as possible. And so you go,
you go through sort of like rigorously and slowly and
just sort of reason about when will this part of
the process happen and where does it need to happen,
sort of more on our timeline. Then we need to

(37:29):
transmit the vote. We transmit the vote to the server,
and then the server needs to basically allow if you
need if you need to allow tracking, or if you
need to allow receipts or whatever is the property you
need to have, then you need to figure out a
way to provide that at this point. And then you

(37:49):
go on to something like anonymisation, which is effectively where
you take one envelope out of the other envelope right
to do the analogy that needs to happen in a
way that you can prove that it happened. So you
need to have a good trace here. You need to

(38:11):
have good locks and traces that you can publicly show
and then you know, so you sort of move through
the chain sort of like the the event of an
of a thing. Right, it's the same, and so you
sort of need to reason about where is it going
to happen. That gives you some ideas should we need

(38:32):
do we need a web app? Do we need a
mobile device, mobile app, do we need do we need
to run cryptography, do we need to run something advanced
on the user's device, or is the user's device just
a portal? And and that gives you sort of ideas
on or some insight into how this should be organized,

(38:53):
how they should be tested, how they should be planned
out right, But most importantly for for voting, is basically
making sure that everything is tracked. And we grabbed part
of the concept of blockchain, which is hash chain, right
to basically hash everything together so you can't move stuff

(39:14):
in the middle without everybody being able to know right,
things like that. That's all yes, nice, that's nat w

(39:45):
And for for like for banking, right, you want to
you want to make sure that the point is to
get money from A to B. So you want to
reason about, well, first off, how am I going to
get the number that they intend to send? Right, like,
where does that come from? Where does the where does

(40:07):
the sort of outgoing amount of money come from? This
is the second one. It's it's hard to be home
alone with with kids. But so you want to basically say, okay,
so where does the money come from? And then you
want to reason amount well, how can I prove that

(40:30):
the money that came from there that I got it right? Like,
how can I make sure that the intent was to
send it to me? How can I make sure that
the amount was correct? Right? Because like, like we talked
about earlier with transfer wise, for example, there is a
lot of web scraping. There's a lot of this sort

(40:51):
of craziness going around less so now more so then right,
And you want to make sure that you have I
ever done it a few times that you were quite
confident that you've run it on big data sets, Like
you need to be certain that you can pass these
things correctly, and then you want to sort of grab

(41:13):
that information and then we get into the whole banging
of how do you then move them? There's like swift
and that's pretty taken care of. The only problem here
was that it was slow. Right, So what we would
do is that we would basically assume that if we
could read the intended money here, we could effectively pay

(41:33):
it out here immediately and then just do the in
between transfer later. So we would basically have big stacks
of money around the world and we could immediately pay
out locally or take money in locally and then we
would transfer later. So in that case, it was more

(41:53):
question of can you verify the amount here, and can
you verify that it's the sort of the correct amount
and the correct intended amount, and can you then make
that payout over here? Common as then can you do
the payout here? Is there sufficient funds? And then after

(42:17):
that you sort of say, okay, now we've we've effectively
solved the user journey, right, we've taken money in, we've
paid money out where effectively the user is happy or
both users are happy. Right, nobody knows that we didn't
actually move the money, and then we can take you know,
take it slow, just do it properly, make sure that
we interact with the Swift network. That's a bit slower.

(42:41):
So you need to have a buffer in both ends
to do it right and the things and the most
important part here is the ability to scrape. Right. So
when the critical points here was that you have to

(43:02):
be able to always scrape these websites in some capacity,
and you have to actually write your your code back
then it was you know, scraping. You have to write
it quite robustly and sort of reason about what happens
if the layout changes, because banks change the layout surprisingly

(43:24):
more than you would think because they don't care about
your ability to scrape it. That's not their business, right,
which is fair. It just means that you have to
be you have to think about the robustness of a
scraper like that, because what happens if the if the
item is not classified the same, if the dumb element
doesn't have the same class or the same idea as

(43:45):
it used to have? Can we find it? By reasoning
with words like can we figure out well, if it's
like if it says some, can we maybe then figure
out what's over here next to it? Because that might
be then but I'm looking for, right, So there's sort
of like reasoning like that that that goes on. That's yeah.

(44:07):
And then there's accounting, like a lot of accounting, a
lot of keeping tracks just for legal, legal in compliance
reasons on where is the money going, who's it going
to KYC, all of these. There's a bunch of tooling
after that, right, which is sort of where I was
introduced to this whole compliance thing, like how do you

(44:29):
make sure that the people you're operating with I in
fact the people that they say they are, and I
in fact the right people that you're supposed to be
operating with. Right, So that was also a journey like
how do you even know that? How do you make
tooling for them to identify themselves at the latest possible time.

(44:49):
So it's the least amount of sort of burden or
the least amount of friction and make it as easy
as possible. Right, there's a bunch of proeters out there
that that can help you do that. You can also
do it yourself. It's not super complicated, but you are
now dealing with people's private information because now you maybe
have a copy of the passport. How do you deal

(45:11):
with a copy of a passport? You have to be
you have to sort of be like, Okay, where do
I store this? How do I make sure that it's encrypted?
How do I make sure that none of the none
of the developers can access this? Right? Because you don't
want developers to just as a sh onto the box
and just be like, oh, let me just download all
the attachments. So you need to be you need to
make reasons, yes, or need to think about how do

(45:33):
you then protect this data from yourself in some way? Right? Yes,
that it goes deep and it goes far. Right, You
can talk about this for a long time and about
all the reasonings you have to make, but at some
point you also have to protect your systems from other
developers from other Also high level people in the organization

(45:59):
needs to be kept out because the higher up you
are the most the spear fishing you are or whaling
you are effectively the subject of, and the greater the risk. Right,
So you want people to not have access, maybe you
even want the CTO to not have access. Like there's

(46:21):
a bunch of considerations like this. In the banking one,
I was a senior developer, I had access. Then we
had the one of the compliance officers, she had access
to the Swift network. And then but but the CTO
and the head of sort of the COO type person

(46:46):
didn't write because that would it post too much of
a risk. So there's also like these human factors you
have to think about when you reason about the security
of a system that that actually impacts and it has
something to do for real world people. That was a
very long spiel.

Speaker 3 (47:06):
Sorry, It's fascinating when there's so much on the line,
like most of the apps have worked on, like if
it went down, it's like yeah, fine, o kay, it's
not ideal, but it's not the end of the world.
I kind of want to pick up on something you
mentioned quite a while ago, actually on about type checking
and sobay and stuff like that, Like, I'm very much

(47:30):
a fan of the dynamic typing. I do have a
background in static programming, like because I started as a
mobile developers, so I spent a lot of time with
objectivecy with Java and with Swift, So I do have
that background. But ever since I kind of switched to Ruby,
I just love that dynamic style and I just find

(47:53):
it easier to work with. But I also get that
when it's critical infrastructure that type checking it's just almost essential.
So I'm curious, but why you went with Ruby and
Rails when the infrastructure is so critical and type checking
is scary something that's important to you, and that it's

(48:15):
kind of bolted onto the language, So what motivated you
to go with Ruby and Rails instead of something that
has it natively?

Speaker 4 (48:22):
Yeah, So it is it is to high degree about
the speed and the very well built testing frameworks that
is around it. Right, So even if it's not statically typed,
you can test a lot of things, and you can
test it in a lot of ways. Typing is just

(48:45):
or types. It's just one way of ensuring that the
data is correct. That doesn't necessarily guarantee that the actual
data you are trying to read in is of the
correct format or whatever. It just means that once you
read it in, it will fail because it's not the
right time, So it depends a little on what you're
trying to do. You can also, because it's dynamic, you

(49:05):
can then sort of do things like, Okay, you gave
you told me it was a CSV, and it's obviously
not a CSV, and it obviously doesn't have a string
where you told me a string was supposed to be.
But I can see how this can look like a string.
Maybe I can just make an interest string for you
and move on right, Like, you have these options of

(49:26):
making things go a little bit fast and a little
bit smoother because you can sort of just fiddle a
little around with it. What tends to happen in these
systems as they grow older and as they mature is
that part of the core of the system gets replaced
with something like Java or Rust or something like that,

(49:49):
so that once you have sort of you have a
really solid part let's say the transfer engine, right that
transfers from one account to the other, that hooks onto
the Swift network. Maybe you want to move that into
Genva or something that's more standing, more slow, but more
type robust and more maybe even performance optimized for io

(50:12):
or whatever it is that you need. Right, But then
what tends to happen is that you still want the
speed and ease of using Ruby on rails and having
only a few developers do a lot of features so
you can figure out what's good or bad, or what
works or doesn't, or do a lot of development around

(50:33):
trying out this new standard to verify with the engineers
that it will in fact test correctly with this airplane,
or you know, sort of having that capability to do
feature spikes and to do tests or like mini projects.

(50:55):
It seems to me that that is to some dey
lost when you use a more as well some other language. Right,
But but you are right, like, once you have it down,
once you have it locked in, once you don't have
any changes there, what tends to happen is it gets
replaced with something that's fast or better for suited for

(51:17):
the purpose. Yeah, I've seen that happen. So the reasoning
is that you can go really fast with quite few people,
and you can actually get something that's meaningful, that will
affect people's lives, that will better somebody's life. You can
get it done pretty quickly, right, Like you can get

(51:38):
a a design system for to to basically do design
some We're not talking like three D sketches of aeroplanes
that that's not necessarily how you design all of it.
That's just the building of it. But you also need
to reason about the logic of who does who does,
what are the processes, and you can get something like

(51:59):
that build in seven eight months. Right, That's as far
as I know. That's and what I could see in
the market, right, And what happened was that we basically
went a lot faster than everybody else, right, with this
same amount of errors. Like it seemed that there was

(52:21):
no real drawback to using Ruby in that case, right,
And so it was a pure benefit to use the
language in the framework.

Speaker 3 (52:32):
Nice you does. There's really nothing that can compare to
the speed of development of rails. It's I think we
kind of take it for advantage, like for granted, rather
rails developers. It's when you go and look at the
outside world is when you realize blood, yeah, this is
a good tool.

Speaker 4 (52:49):
Yeah, yeah, it is quite insane.

Speaker 3 (52:51):
Hm.

Speaker 4 (52:52):
Like I had a colleague who did a you know,
sort of an AI based a feature spike, you know, like, oh,
can we just timebox this to like three days? And
in three days we had a tool that seems to
be working, did integrate with AI, had UI had tests,
were behind the feature flag, and was effectively shippable. Right.

(53:14):
It was not you know, it was not the best
of the most robust or whatever. But like, in three days,
a single person made a full featurespike that could technically
be deployed and could work. Right, that's pretty amazing.

Speaker 6 (53:27):
I'm curious real quick, Like, uh, I'm in my experience
working with like critical systems like this, Like once it's built,
it's like it's hard to change, right, like and mostly
because like to the requirements probably don't change very frequently either,
But like, how how do you like approach in those

(53:49):
cases like that change? Like is is it like build
something new and cut one off and switched to the
other or like what, I like, what kind of systematic
approach do you take to that?

Speaker 4 (54:06):
I think so for me, it's certainly about you have
to reason about the protocol and the process somewhere other
than the application. So you have to diagram it or
put it into dance or whatever you like to do.
But we need to have a different place to talk
about it than in code because we need to reason

(54:28):
about when somebody has a change, we need to be
able to reason about it before we spend time in code,
and we need to figure out if the the sort
of the signature of that particular change. Let's say you
want to change one hashing algorithm with another hashing algorithm. Right,
you need to be able to reason if that will

(54:50):
break the system, just in principle, before you start to
even try and implement it. Right, So I find that
I it really benefits to have it in a big
diagram or have it written out in long form in
a document or like somewhere that you can reason with

(55:11):
people who aren't developers on whether or not it will
work or not before you even try to implement. Because
if you can reason that it will in fact work,
it will plug in, it will replace. If you can
reason about that before you actually see the code when
you come to the developers, it's a much smoother experience

(55:33):
to say, okay, I need this piece replaced with that piece,
And yes, the hashing algorithm is not the same, but
it is whatever based on the same something something, so
it will plug in, right, And then we can either
have both if they plug well, we can replace one

(55:54):
with the other and do and you can also then
you need to trends or migrate the data.

Speaker 5 (55:59):
Right.

Speaker 4 (56:00):
But now that you're migrating the data, it's really nice
to also have that conversation with beforehand and with others
who are not developer. Well, we have existing data and
you want me to plug this thing into this place
in this big diagram. What happens to all the old
data that went through that point beforehand? Like, what do

(56:21):
we feel we need to do about that? Do we
want to revision it and say that version less than
something can never be opened again or can never be
edited again, but can only be viewed? Like what's our
reasoning on that? Right? So having somewhere else to talk
about it then in code really helps to figure out
if you should replace plug in or you know, make

(56:46):
it as a different service that you called sometimes you know,
whatever it is. I find that that having something other
than code really helps. Yeah, so it really needs somewhere
else to have that conversation.

Speaker 6 (57:05):
Right, Yeah, you know, it makes me think about the
old days of Yahoo pipes, like where you could visualize
and like in real time update the data flow of
any particular aggregate thing you were trying to collect. Are
there any tools like that that you use to like

(57:26):
maybe automate this process or is it just a matter
of getting documented?

Speaker 4 (57:31):
That's I mean, I've tried a bunch of them. I
haven't found one that I really like. I haven't found
one that really does it for me. I tend to
try and make them diagrams as code because then they
can at least get checked into get and we can
have version control on top of it. But I haven't

(57:53):
really found anything that really does it for me I've done.
I tend to either do whimsical or draio or something
like that, and then it is just a lot of
work to keep it maintained. And that's that sucks a bit,
But you know, it's it's hard to it's hard to
do without right, without somewhere else to reason, and especially

(58:16):
when you need to talk to because it's not only
a technical problem, right, it is also a business problem,
and it is a regulatory problem. If I'm going to
change this piece of the testing bed for an airplane,
or this piece of code for the design software for
an airplane. I need to be able to have a

(58:39):
conversation with somebody who's not a software engineer about the
consequences of that, right, because I need to talk to
the civil engineer, I need to talk to the test manager, youvely,
and I need to talk to a lot of people
about the consequence of doing it and the way to
do it, and are there any consequences outside of my
system that we need to have a conversation about it.

(59:01):
It is just sort of like trying to get as
many people joining that conversation as possible, And for that
it seems to work better if it's not quite colde
because then more people can participate in that conversation.

Speaker 6 (59:16):
Right, Yeah, I think that makes a lot of sense.
I'm still personally trying to find the silver bullet, and
the closest I've gotten is Mermaid.

Speaker 4 (59:26):
Yeah, and that also works quite well. Actually, it's just
it works pretty It works pretty reasonable, and it is
definitely a diagram as text. Right, So I've also used
that a ton and it's decent enough. I find that

(59:48):
it has some problems when you get up to really
large size stuff like it's hard to get enough in
there and still have it be viewable and understandable as
a human. But I mean a lot of like building
these systems and a lot of participating in building them
is surprisingly not about code. It's about talking to a

(01:00:10):
bunch of people who have nothing to do with software
development and figuring out if you're going to break their lives, right, Like,
are you going to break something completely insane that you
had no idea that you ever were ever going to
touch because you know, in the case of this, well,
I'm going to change this thing in my design software,

(01:00:32):
and then suddenly somebody in the factory somewhere is totally
confused about how to build an airplane because I did
something that you know. So it's really not that much
of a software challenge. I mean it is, but it
is to high degree a communication challenge and sort of like,
how do we even communicate what this software does to

(01:00:55):
people so that they can use it and so we
can reason about the safety of it together the.

Speaker 1 (01:01:00):
Rine, Yeah, it makes sense in the I mean, I've
worked on things at this level of complexity that you
have to get right so I worked at Morgan Stanley,
and I mean we weren't doing like banking level stuff,
but we were doing like investment level and business information stuff, right,

(01:01:23):
And so yeah, the world didn't end if we got
it wrong, but we kind of needed it to get right.

Speaker 2 (01:01:29):
And a lot of it was just a matter of.

Speaker 1 (01:01:32):
Like you said, making sure that all the people who
understand all of the concerns and all the things that
it touched are able to weigh in and be part
of the conversation and that way. Yeah, you don't do
things without understanding the implications of how it's going to ripple.
I'm working a contract now, and you know, I'm still

(01:01:54):
trying to figure out the ins and outs of the system,
and they're they're managing funds and stuff like that, right,
and so yeah, I'm definitely feeling it here where I
don't want to make any changes that ripple through the
system and right. And so this is where you when
you're talking about like testing and documentation and things like that,

(01:02:15):
where the documentation really isn't around and there are a
lot of other things. I wound up having to ask
a lot of questions and I'm still not sure that
all of my assumptions are correct. So yeah, a lot
of this really helps in the sense of, oh okay,
if if we're gonna nail down robust, you know, reliable things,

(01:02:37):
then then yeah, you know, all of these things are important.
And I think part of my issue with some of
it is just that I like to just get in
and solve problems. Right, I'm my mentality. I was talking
to some other friends and the other day and my mentality.

Speaker 2 (01:02:52):
Is go go go, go, go, go go.

Speaker 1 (01:02:54):
And so I yeah, having to slow down and you know,
dot all my I joke and say I dot all,
my tea's across all my eyes.

Speaker 2 (01:03:05):
It just it's you know, it's it's not my natural state.

Speaker 1 (01:03:13):
And I think a lot of developers, yeah, they just
they just want to write great code that solves problems.
And so the meetings are tedious, the conversations are boring,
you know, and you know, why can't I just go
in and just.

Speaker 2 (01:03:29):
Make it work? And the reality is is, you know, yeah,
what we're what we're talking about here?

Speaker 1 (01:03:35):
And so I think I think it's not just we
have these specific concerns, whether the regulatory or something else.
I think it's also that there's enough complexity to it
to where you really do have to.

Speaker 2 (01:03:46):
Get in and understand the nuance of what you're doing.

Speaker 4 (01:03:49):
Yeah, and I think also the breadth of what you're doing, right,
Like I know this for myself. Right when I was
younger and started developing code, right, it was like, well,
there's only one truth, right, Like either it's one plus
one is two or it's wrong. Right, But that's just
not the case when you have these really big connected systems,

(01:04:13):
right where like, well, what happens if I change this protocol? Well,
now it's right because it's a different protocol, But now
it's wrong because it's a different protocol, So it can
be both at the same time, right, because now you
know all the other people who used it for one
protocol can't use the other, and like it just gets
really messy. I think at some point I realized that

(01:04:37):
I like doing documentation, and that really helped to sort
of make me be confident that this could be somewhere
you can do a career, like you can do a
career and something that's not obviously developer ish territory, right, Like,
because I actually enjoyed doing like I could say to

(01:05:00):
diagrams and reasoning outside of the code and all of
these things I found was pretty interesting, and that makes
it easier for to be me right, Like, it's more
fun to have that conversation with everybody to figure out, well,
if we do this thing over there in wherever we
are operating in Australia, that's fine. But now we've done

(01:05:22):
this change, so what happens to our operations in Austria,
Like is that the same text system? Can we do both?
Like it just it can become really complicated when you
have when you're operating under multiple jurisdictions and multiple governances,
right then that that can become complicated as well. And

(01:05:46):
you know you're doing currency conversions, or you're doing unit conversions,
or you're doing all of these things. Like it's so
hard that I know that even the space agencies are
getting it wrong. And sometimes there's stuff just won't work
when you get it into space right because somebody miss
uh converted interest to centimeters right, And so it is

(01:06:10):
just and that should like to if you go to
a a freak out of college developer and says to
him that I need a unit unit conversion system, a
unit conversion method that can go from interest to centimeters,
that's pretty straightforward. That's a that's a pretty straightforward ask, right,

(01:06:32):
and you can do that method pretty quickly. It's not
really super hard. What is really super hard is getting
people to use it right. So you need to build
a unit conversion method that is easy to use, fun
to use at hand when you need to use it,

(01:06:53):
so that you will in fact use it because otherwise
you're going to do it in your head. And then
it doesn't really matter that you build a piece of software, right,
So like it, there's a lot of other components to
this than just the software, Like there's a lot of things,
like you know, there's a lot of backup, a lot
of everything. But it is also about making sure that
the people who use it use it correctly. And the

(01:07:15):
way to do that, like we talked about before, like
with the TSB and everything, it's not to blame the
person for not using the thing. It's to blame the
thing for not being available when it was needed. Right,
So you need to be like, if I have a
unit conversion thing and it's hidden behind you know, a
multiple three dot options that you need to figure out

(01:07:35):
five levels in, that's the wrong place to have it, then, right,
you don't blame the person for not using it. You
blame the system for not putting it in his face
when he needed to convert the measurement.

Speaker 2 (01:07:49):
Yeah, I like.

Speaker 1 (01:07:51):
I like that just from the standpoint of I mean,
I guess, I guess where my brain goes is is
everybody has the responsibility to understand the system and how
it works, right, And so everybody has the responsibility then too,
you know, to be aware that this method exists. But

(01:08:15):
at the same time, if I create it, then it's
also my responsibility to make sure everybody knows it's there
and knows how to use it. And I also agree
though that if you make it easy or natural to
do the right thing, then people.

Speaker 2 (01:08:29):
Will generally do the right thing. Yeah, and so yeah.

Speaker 1 (01:08:34):
I think I agree with you, But I don't want
to absolve anybody of the responsibility of learning to do
the right thing either.

Speaker 4 (01:08:42):
No, No, I mean that's not what it. I mean.
You can absolutely end up being blamed for crashing a
flamee Like, it's not entirely out of the realms of
like the pilot can be blamed, right, But it is
also about looking at did we actually provide the correct
tuning at the correct time, with the correct intensity and

(01:09:02):
all of this, right, And it's the same here, like, well,
the system didn't work well, did we provide enough, did
we scale enough? Did we have enough compute resources? Did
we have enough database storage? Was it just so slow
that people couldn't use it and it crashed and somebody

(01:09:24):
couldn't get their voting, Because if somebody couldn't get their voting,
then you know, we sort of we get into the
territory of oh, somebody prevented me from voting situation. Right,
So it's like, yeah, they could have done it again,
Like they could have just waited five minutes till the
peak was down and voted again. But that's like it's

(01:09:44):
also not really therefore, right, So it's there's a lot
of there's a lot of sort of like ancillary non
developer stuff to talk about when when designing. I'm pretty
sure there is on old systems, right. But the fun
thing here is just that this happens to include other engineers,

(01:10:05):
which is very fun, And it happens to include things
like cryptographers and people who actually like politicians or whatever
it is. It's just I like the types of people
that I get to talk and interact with, right in
this rather than I get to talk less with marketing

(01:10:27):
and social media and more with like people who build
spaceships and aeroplanes, and I find that that's basically what
drew me here, right, is this idea that I get
to talk to other people who also have this engineering
spirit and this idea to build something in the same

(01:10:47):
mindset that I do.

Speaker 2 (01:10:48):
Awesome.

Speaker 1 (01:10:49):
All right, well, I think we're going to go to
picks because we've been talking for an hour and fifteen minutes.
This is cool, though, if people want to can act
with you, or if they have questions about what you're doing,
you know, maybe you want to pick your brain about
some of this stuff.

Speaker 2 (01:11:06):
How they find you on the internet.

Speaker 4 (01:11:08):
I think go to LinkedIn. That's uh. I have more
or less try to absolve myself of all social media,
so LinkedIn is probably your best bet. It's my name,
It's right there on the screeny thing there it is.
And then also go go on Discorde. You can ping
me there, PM me like you did. I'm both on

(01:11:33):
the Camal, the rails and the Ruby servers, so you
can just go find me there. It's E K A
M P P. So just my initial letter and my
last name.

Speaker 2 (01:11:46):
Nice I didn't know that there were Ruby and Rails discords.
I'll have to go find.

Speaker 4 (01:11:50):
Those I can. I can send you invite links.

Speaker 2 (01:11:55):
That would be perfect cool.

Speaker 4 (01:11:57):
All right, there's someone for like rails developed. That's the
Rails one, and then there's one for Ruby, which is
more like application support and like, oh, I don't understand
what this method does or I need to change this,
whereas the Rails one is more for like, I need
approvals or reviews of pians for the actual coal. So

(01:12:18):
that's more about supporting of that. So it's less interesting
if you're trying to solve a business problem, but it
is kind of cool if you want to just peak
at what the others are doing.

Speaker 1 (01:12:29):
Nice, okay, well let's go ahead and do some pics, Valentino,
Do you want to start with picks?

Speaker 6 (01:12:37):
Sure, I've got nothing but AI picks. Today, there's been
a lot of activity in the Ruby world. Andrew Kine
has released yet another AI gem bless his heart. It's
called Informers, and it basically lets you run inferants in
Ruby on Onyx models. So lots of hugging face models

(01:13:04):
are on supported and you can now just run inference
with those. And he also has transformers are b if
you are interested in running inference on non onyx models.
So now we have like a complete picture hopefully those
There are some some missing pieces still for larger models,
but it has a ton of pipelines already built in,

(01:13:25):
so I would suggest checking that out. The next pick,
somebody built this awesome chat app where they've aggregated all
of the rails and Ruby like articles and blogs and
guides and everything like that, so you can basically rag
the entire rails community ecosystem in a chat GPT style

(01:13:51):
interface and it's it's remarkable and it does like citations
and everything like that, so you can see the original
article that reference whatever it was you're interested in. Uh,
it's really awesome. It's called ship on Rails AH, and
it's built with this really cool tool called Nausea, which
provides basically like a rails app ready to go, so

(01:14:15):
that you can ingest your own documents to rag against
and do a very similar thing. It's really cool, so
i'd recommend checking all those out.

Speaker 2 (01:14:25):
Nice. How about you are USh?

Speaker 3 (01:14:29):
I'm not sure what to take for picks this this week.
I haven't really thought of anything. It's a it's a
it's a cheap one, but I'm gonna go with Blue
Sky because I'm quite enjoying blue Ska in the last
week as I finally signed up for it, and a
lot of Ruby folks have I have signed up recently.

(01:14:49):
It's quite a lot of activity on there. I'm quite
quite enjoying it as a social network. Hopefully it can
stay the way it is. I'm active on both blue
Sky and masterdon for But yeah, we'll see what happens
because Blue Sky is still a VC fund that privately
held the company, so we'd love to see how long
things remain good. But for now, I'm quite quite happy

(01:15:13):
with it. What else can I pick? I haven't really
watched anything or anything new recently because I think I
had picked a TV show called Shrinking, which I did
the last time, so I don't want to pick that again.
I'll go with the music pick because I always go
with the music pick when I'm when I'm struggling. What's
in fun of Me? The new Ts for Fears album?

(01:15:34):
Check this one out. It's really good. It's a live
album with a few new songs from eighties pop band
Tis for Fears. So yeah, I think I'll go with those.

Speaker 2 (01:15:48):
Awesome.

Speaker 1 (01:15:49):
I've had a number of people tell me I need
to join Blue Sky. So anyway, let's see, I'm gonna
throw in some picks. So I played, I played a
new game. I actually played a couple of new games

(01:16:10):
this week because the game convention that I usually teach
games at is UH is going to be on Saturday,
and so I need to be able to teach these games.

Speaker 2 (01:16:23):
So I'm gonna pick one of those. It's called MOLEM
l M L e.

Speaker 1 (01:16:28):
M, and essentially what it is is it's how do
you describe it, It's it's cat astronauts, and the way
that it works it's it's a relatively simple game. It
was almost too simple for me, to be honest, But

(01:16:50):
if you're kind of a casual board gamer, right, it's
it's definitely approachable. So let me pull it up a
board game geek. But yeah, so what the way that
it works is you have astronaut cats that are going

(01:17:13):
going into space and they're basically occupying planets and moons,
and so you.

Speaker 2 (01:17:19):
Pick one of your.

Speaker 1 (01:17:22):
Your cats, put it on the rocket, and somebody's the
captain and they roll the dice and if they're if
the dice match what's on the space on the board
that you're on. Then you can choose which dice to
use in order to move up the board. Right, And
so if you if you have boosters, boosters move you

(01:17:44):
up for free. The other ones you have to give
up the dice in order to move. And so if
you ever get to the point where you roll the
dice and you you can't use any of the numbers,
then use the ship. And at any point people can

(01:18:04):
get off the ships onto moons or planets, and you
get points for having the most cats.

Speaker 2 (01:18:12):
On planets, you have points for every moon you occupy.

Speaker 1 (01:18:16):
If you go away to deep space, then you get
bonuses for that. And then the different cats have different abilities, right,
so one of the cats let you start further up
the board. One of the cats let you you know,
let you get off the ship after it crashes, right,
so you can go to the planet it's next to

(01:18:37):
or whatever. When it crashes. One of them gives you
a bonus, doubles your points for the planet it's on.
One of them doubles the points for the moon it's on. Anyway,
you get the idea. One of them doubles the points
if you're in deep space, but deep space is hard.
I've played it once and we never made it to
deep space. We got close a couple of times, but

(01:18:57):
then I was talking to some other people a couple
of other times, and one of the times they played,
they made it deep space like three or four times.
So anyway, so if you're the captain, you're rolling, and
then you just rotate who the captain is. If the
captain gets off the ship, then the next person in
line just finishes out that round.

Speaker 2 (01:19:17):
Anyway, that's basically the game.

Speaker 1 (01:19:19):
Or game Geek has it as a at a one
point six y eight weight.

Speaker 2 (01:19:24):
It says ages eight plus, and yeah, I have an
eight year old.

Speaker 1 (01:19:29):
She could definitely play it. It says thirty to sixty minutes.
That's probably about accurate play two to five players. I
played it with four players and that felt pretty good.
So it's mele M L E M Space Agency and yeah, anyway,
check it out.

Speaker 2 (01:19:49):
And then I'll just put a link in the comments here.

Speaker 1 (01:19:59):
And then let's see. I'm not sure if I really
have any other picks. I know, I've kind of been
doing other things and getting involved in other things, but
I guess the big thing that I went through this

(01:20:19):
lately as I went up to retreat up in Sundance,
which is actually like forty five minutes from here. If
you heard of the Sundance Film Festival, they do actually
do that in park City, not in Sundance, but.

Speaker 2 (01:20:33):
From here, it's about.

Speaker 1 (01:20:35):
Two thirds of the way to park City and anyway,
it's up Provo Canyon. And these guys were running essentially
a Mastermind for three days for Christian entrepreneurs, and so
we did a lot of faith based stuff, we did
a lot of business based stuff, and it was amazing

(01:20:57):
because they just kind of helped me get clarity on
what I want to do and who I want to
be and what kind of difference I want to make.
So just keep an eye out because I have stuff
in the works. But it was terrific and I really

(01:21:17):
want to just put forward. I guess that just connecting
with other people who are doing what you're doing, or
who are learning what you're learning, or who are maybe
a little ahead of you want on the path you
want to go down so helpful, So so helpful, you know,
kind of like what we were talking about with like the
Discord servers, right, So much help helpful stuff there. So Anyway,

(01:21:39):
those are my picks, Emil, what are your picks?

Speaker 4 (01:21:43):
And so recently, I'm going to pick a book. I
recently read a book called How Big Things Get Done
and it's by a Danish guy called bat Flubia. So
what he did was that he went I don't know
if you guys know it, but he went through statistical
data on overruns on big projects, like how far behind

(01:22:08):
is an IT project in general? How much of an
overrun on cost do you get? How much of an
overrun on time do you get? And he goes through
sort of like these different industries and different factors that
play into to why why big things fail and why
some big things get done right, like what are the

(01:22:30):
ways to make sure that big things gets done and
what are the pitfalls and everything, And he goes through
everything from the Sydney House Sydney Opera House to like
big government IT projects that fail. It's just super cool
because it's very sort of data driven and he has
spent his career collecting data on why big projects fail,

(01:22:52):
why all kinds of projects fail. So it's a really
interesting sort of window into do this if you really
want to mess it up? So by inversion, if you
don't want to mess it up. Don't do all of this,
do do the other thing. Right, is that that's kind
of an interesting statistics to have, and so yeah, how

(01:23:13):
big things get done? I found that was really.

Speaker 2 (01:23:16):
Cool, awesome.

Speaker 1 (01:23:20):
All right, well, thanks for coming, Emil. We're gonna go
ahead and wrap it here.

Speaker 4 (01:23:25):
Thank you for having me.

Speaker 2 (01:23:26):
It was a pleasure, and until next time, Max out

All Episodes

Embracing Human Factors and Rapid Development in Ruby on Rails Systems - RUBY 661

Episode Transcript

Popular Podcasts

Stuff You Should Know

My Favorite Murder with Karen Kilgariff and Georgia Hardstark

The Joe Rogan Experience

.css-15opob5{left:0;position:absolute;top:0.8rem;} All Episodes

.css-14f5ked{margin:0;word-break:break-word;display:-webkit-box;-webkit-box-orient:vertical;box-orient:vertical;-webkit-line-clamp:2;overflow:hidden;}Embracing Human Factors and Rapid Development in Ruby on Rails Systems - RUBY 661