December 18, 2024 • 51 mins
In this episode of Elixir Mix, Chris Dosé joins us to talk about some of the open source work that he has done at Peek. He also talks to us about his exciting Nerves projects Xebow and AFK.
Links
Picks
Become a supporter of this podcast: https://www.spreaker.com/podcast/elixir-mix--6102049/support.
Links
Picks
- Steven - The Art of Agile James Shore
- Steven - US History YouTube
- Lars - Hurry Slowly
- Lars - Peter van Roy - KEYTNOTE Why time is evil indistributed systems l Code BEAM STO 19
- Chris - ElixirConf 2018 - Picking Properties to Test in Property Based Testing - Michael Stalker
- Sophie - Anybody have any easy baking recipes?
Become a supporter of this podcast: https://www.spreaker.com/podcast/elixir-mix--6102049/support.
Mark as Played
Transcript
Episode Transcript
Available transcripts are automatically generated. Complete accuracy is not guaranteed.
Speaker 1 (00:09):
Hello, everybody, Welcome to today's episode of Alixer Mix. I
am Sophie de Benedetto, and I am joined by some
of our still relatively new panelists. We have Lars Wickman. Hey,
did I say our last name right? Clo?
Speaker 2 (00:26):
Close enough?
Speaker 1 (00:26):
Okay, cool?
Speaker 3 (00:27):
We have Alex Kutnos howdy.
Speaker 1 (00:30):
Hey Alex, and we have Steven Nunez. Hello, hey, and
we are very excited to welcome today's guest, Chris Dose.
Speaker 3 (00:40):
I said that right, right, Yes, that's correct. Hello, and
thanks for having me.
Speaker 1 (00:45):
Awesome welcome. So Chris, we're super happy to have you.
Do you want to kick us off by introducing yourself?
Speaker 3 (00:52):
Yeah, well, I've been a software engineer for a little
while now, I was. I had to, you know, check
back at my LinkedIn to see how far back it
actually goes. Looks like I've been doing this for about
thirteen years now. I started out down in Louisiana at LSU.
I did some I taught workshops there as a student
(01:12):
in software, primarily things like HTML and CSS and javascripts,
but you know a little bit of PHP as well.
That was my first language. And from there I got
some jobs in Louisiana, but decided that that wasn't the
place to really propel the career I wanted. So I
(01:35):
moved to San Francisco and got a job with Peak
as a software engineer there and have been with Peak
since then for about a little over six and a
half years. And at Peak is where I got into
Elixir and started learning that super cool.
Speaker 1 (01:54):
I hadn't heard of Peak just in terms of it
being a company that is using alex or so I
was always exciting to add a new entry to like
my mental list of companies that are using Elixir and production.
Were they working with Alixer before you got there?
Speaker 3 (02:10):
Noe. We we were using Ruby primarily before before I
got there and when I got there, So for the
first two years while I was there, we were primarily
writing in Ruby, kind of going into service oriented architecture direction.
And then and I wasn't aware of Elixer actually, and
(02:34):
we we hired a new engineer who was a big
proponent of Elixer, you know, like an evangelist, and said, hey,
you should really check this out, and I did, and
he completely converted me. So I became an evangelist for
Elixer as well. And I suggested that we start exploring
it for future services. Since we were going in a
(02:54):
service oriented architecture direction, we could you know, experiment with
smaller services and say, hey does work. And thankfully it
did and we kind of got everybody on board with that.
And uh and we use Elixir now primarily, even though
we've got plenty of legacy systems around that are still
in Ruby. We don't tend to build new things in Ruby.
(03:18):
We we build all of our new stuff in Elixir.
Speaker 2 (03:20):
How did you find the process of either hiring Elixa
engineers or ramping up you know, Ruby developers and getting
them familiar with Elixa and the beam How did that
process kind of go?
Speaker 3 (03:34):
Uh? Well, thankfully, I guess we're we're a pretty small
engineering team. So the ramp up process for the existing
engineers on Ruby was was pretty pretty easy. For the
For the engineers that we had, we you know, like
we've got some smart people. They just kind of got it,
you know, and we we all kind of learned together,
you know, I mean, we were all new to it,
(03:56):
and uh, and yeah, that that worked out pretty well.
As far as hiring hiring new Elixir engineers, it definitely
is harder. The pool is is much smaller, but we
we've always been open to, you know, hiring anybody from
any programming background as long as they're interested and willing
to learn a elixer like we you know, we're we're
(04:17):
perfectly happy to have, you know, people that want to
learn a elixer but haven't had an opportunity yet, you know,
in a in a professional setting too, to use Alixer.
So you know, we were looking for people like that. Unfortunately,
of course, the the the recent pandemic and stuff has
drastically slowed us down, and we've been on a hiring
(04:38):
freeze ever since then. So that's kind of that's kind
of been on hold.
Speaker 4 (04:43):
And I'm always really curious about sort of teams that
transition into Elixer. So where I'm at now, we same
kind of story predominantly went from like Ruby Rail's background
to some psychopath came in and convinced everyone to go
and look at this elixer thing. It was, I don't
I forget it's a yeah. So we started building more
(05:04):
and more apps of it with it, and then it's
kind of like interesting because the journey is not just like.
Speaker 3 (05:09):
Hey, there's pipes here in gen servers.
Speaker 4 (05:11):
It's kind of like trying to figure out what are
the learning materials you need to get in front of
the team, how do you sort of organize it? Like,
we have smart people too, but we also realize that
if you don't, if you're not careful about like how
to convert an O mindset to a functional mindset, you
wind it was a really gnarly looking code. Did you
guys run into that at all? And if so, what
(05:31):
resources did you sort of use to books, guidance, any
sort of like uh, general tips.
Speaker 3 (05:38):
Well, yes, definitely. The early experiments and Elixer were definitely
a little weird, especially since we tried to kind of
out the gate, try some try some funny business that
like would have been a lot harder to do in
a Ruby, but we're like, but we're using alixter, now
we can do this. And those kinds of things turn
out to be bad ideas in the long run. But
(06:00):
you know, just like as an example, we had we
had one of these integrations that we were building where
we needed to like the the external API we were
integrating with was asynchronous in some places, but our API
is synchronous, so you know, okay, fine, so why don't
we just have you know a little layer here where
the internal synchronous requests HTTP request comes in. We spawn
(06:24):
up a gen server that holds on to that HTTP
request and then does the async actions with the external API,
and then whenever that a sync action is done, then
we can release the response uh to the you know,
to the HDTV client there, and uh yeah, it's it's funky,
and you know, ended up just being really hard to debug,
(06:44):
and I wouldn't necessarily recommend it.
Speaker 1 (06:48):
I feel like, are you me?
Speaker 5 (06:49):
I think we did that same thing in one of
our earlier I'm maybe not exactly saying, but very much
a situation where you have like an incoming web request
and then you're just doing something kind of overly complex
with gen servers and you know, your blocking response until
fifteen different things resolve.
Speaker 1 (07:05):
And yeah, I think the idea of it being extremely
hard to be bug with absolutely yeah, resonates.
Speaker 4 (07:12):
That is sort of interesting that because Elixir gives you
those tools to do it, like like, oh, I can
kind of imagine how like a set of persistence servers
running in like the background and hit this is perfect,
and then then.
Speaker 3 (07:23):
It hurts, hurts, hurts so bad. But then that's that's
part of learning. But I think.
Speaker 4 (07:29):
I think worth exploring because I think it helps you
understand sort of like the edges of you know, what
these tools can do for you.
Speaker 1 (07:37):
One thing that I know I was excited to ask
you about, Chris, is it looks like Peak at Peak,
you guys have one or two or a couple of
different Elixir open source libraries that you maintain, And I
think it's really exciting not only to see another company
using Elixir and production, but actually supporting and giving back
to the Electric community in that way. So I would
(07:57):
love to hear a little bit about the open source
libraries that guys developed. What did they do, why did
you build them, what's it like to maintain them, you know,
as you use them in production.
Speaker 3 (08:08):
Yeah, I am also excited about being given the opportunity
to develop and maintain these open source libraries. Thankfully, like
Peak is very open to that idea of you know,
giving back to the community, and so it was it
was largely my initiative to to carve out some of
the important bits or you know, some of the things
(08:30):
that we thought could make good libraries and uh and
put them up on this on this GitHub organization page. Here,
and uh, you know, it might not be a surprise
that a lot of the libraries that we do have
available are specific to what we do at PEAK, which
is building software for the tours and activities industry. Uh
(08:54):
And naturally that involves scheduling availability on calendars. So I've
got two libraries. The first that I developed is the
one that we are actually using in production. It's it's
lib a library around uh generating date recurrence date date
instances based off of date recurrence rules so that you can,
(09:15):
you know, schedule things on your calendar in complex weird
ways that you know people have, and we just needed,
you know, we needed a way to go from some like,
you know, small set of rules that like define a
schedule and be able to expand that out into concrete
instances of time. Right. Uh. So that's that's one of
the libraries that I wrote there. It's called Cocktail. I
(09:40):
have a similar one called xcal which uh, which is
another interesting thing to talk about.
Speaker 1 (09:47):
Uh.
Speaker 3 (09:47):
And then and then we've got a couple of other
little small libraries that were just kind of like little
tools that we needed for various things. The most notable
is probably ecto diff that that gives us a way
of getting a getting like a data structure that describes
(10:08):
the changes that you performed after the fact to an
ECDO schema, especially in the context of deeply nested ectoschemas
using associations like as many and belongs to associations, and
that's and that's been very helpful for us. We definitely
do use it in production, and it is useful.
Speaker 1 (10:30):
How have you found participating in the open source community
and Elixer compared to I don't know if you did
any open source let's say, in Ruby, which it sounds
like you had a background in, or if anyone else
has comparison open source contributions to share.
Speaker 3 (10:47):
Well, me personally, I didn't really contribute much to open
source other than my own libraries even before Elixir, and
and these libraries that I've got here, uh for Peak
are not you know, not exactly super popular, so I
don't get a lot of the you know, like I
(11:07):
don't there's not a lot of like, you know, action
going on there, so I don't. I don't have a
lot of experience with that yet, but I would I
would like to have it. That is changing a little
bit with a side project that I'm working on where
I've actually do have you know, multiple people from the
community involved now and that's just starting out, so we'll
(11:27):
see how that goes.
Speaker 6 (11:30):
And that would be the work with the what's it
called keyboard kit.
Speaker 3 (11:39):
Yes, that's the uh, the our our our initiative to
build Elixir powered mechanical keyboard firmware.
Speaker 6 (11:50):
Yeah, so could you dive into a bit what you've
been doing there and what you're and the goal would
be because the keybot Kit, as far as I understand
it is a mechanical keypad powered by rasper Pie and
for people who aren't familiar with nerves, Nerves runs on
Linux devices such as the respir Pie, so that's a
(12:15):
good target for nerves, and the keybo kit is fairly
let's call it a constraint space. It's a small keypad
rather than a full keyboard. So I'm very curious what
the what the both, what the project is right now
and where you hope to be headed with it.
Speaker 3 (12:34):
Yeah. Yeah, Like like you said, it's it's a it's
a small keypad. People also call them macropads because the
intent is that you you know, it's it's like a
little additional pad next to your keyboard in addition to
your primary keyboard that you can assign various macros to
and like, you know, have various little functions that you
have on your keys that you perform, you know, daily,
(12:57):
and you want to automate. That's kind of the purpose
of macropads. But we're using this Raspberry Pie powered keybo
as kind of like a prototyping are a prototyping device
for us to see how you know how to develop
a nerves based firmware for for what could eventually be
(13:18):
a full a full sized keyboard. As far as I know, though,
there are no full sized keyboards that are powered by
something like a Raspberry Pie. It has to nerves only
targets Linux machines like embedded devices that run embedded Linux.
(13:38):
You can't go all the way down to something like
an ard. We know a micro controller, and most mechanical keyboards, unsurprisingly,
I think, are powered by very small micro controllers that
are very very definitely not powerful enough to run Linux
and the beam. So this is definitely an experiment. Uh
it's it's going really well. I think we've we've got
(14:00):
a lot of really great libraries and development and and
it's fun to just play with this thing and see
what we can do. Uh, it's got you know, it's
got a grade of twelve r g B l eds
on it. We've been playing around a lot with building
out fun animations and stuff. You know, if you've seen
if you've seen some of the fancy mechanical keyboards that
(14:20):
you can that you can buy out there, they've got
you know, full full back light r g B l
eds that you know, animate in all sorts of fancy
ways and stuff like that. So that's kind of what
we're shooting for. The the the end goal being that
we want to actually design uh, you know, the keyboard itself.
You know, we we need to design the the PCB itself.
(14:44):
Uh and and get that get that printed and uh
and actually you know, design a case around it, and
you know, hopefully have that available at some point.
Speaker 6 (14:57):
This is a super interesting project. I'm also I'm also
very interested to see where it goes. But as of today,
what could people that are interested do with the keybo
kit and the things you've been working on. From what
I see, you have separate libraries for like the x
(15:19):
E bow feel free to correct the pronunciation there, and
then the AFK library, which seems a little bit more
general and for the for the wider mechanical keyboard idea,
is that about right?
Speaker 3 (15:33):
Yeah, that's that's correct. The idea is to use the
keybo as our staging ground for the libraries that we're developing.
So one of those libraries is called AFK. That is,
it's the Keyboard State Management Library, because it can actually
get kind of complex if you actually take a minute
(15:55):
to think about how keyboards work, and you know how
you have to manage like which keys are being held
down at which times and which ones get released at
which times, and and then when you throw in the
fancier features that we want, like for example, layer layer keys,
you hold down a key and it switches the entire
(16:15):
keyboard to a different layer, and things like macros and
and other other fancy features like UH like this feature
that we call tap keys, where you can actually have
a key, a physical key, act differently depending on whether
or not you tapped it versus whether or not you
held it. These are all features that come from the
(16:37):
Wider Mechanical Keyboarding community, but the by far the most
popular UH firmware out there, open source firmware for mechanical keyboards,
is called q and K and it's all written in C,
and I'm not a C programmer, but and and and therefore, uh,
(16:59):
it's very difficult for me to understand what's going on
in there. And to me, it kind of looks like
it's it's like a it's a it's a big, you know,
very large project with many many contributors that has has
kind of like gone and sprawled, so it's very hard
to contribute to it and understand it. And so my
goal was, well, I'm not a C programmer, but I'm
(17:21):
an Elixir programmer. I can I can do this in
a elixer and maybe in the process also make it
a little simpler and easier to contribute and and be
able to build higher level features, you know, in a
higher level language without having to drop down into C
to to do that kind of stuff.
Speaker 2 (17:39):
In that same spirit, is is this something that like
a Nerves you know, someone new to Nerves could jump
into and start contributing, you know, If not, maybe what
are some some starter projects that really help kind of
get you ramped up with what Nerves is, what the
development process looks like, and you know, how to get
familiar with all that.
Speaker 3 (17:58):
Yeah, Well, there are definitely things that you can jump
in on on the z BO firmware, which is what
we've been developing. There's there are things that you know,
someone who's not familiar with nerves can jump in and
start contributing with. I wanted to, you know, mention a
couple of other features that are actually on the in
(18:19):
the ZBO firmware that I that I forgot to mention earlier,
which is that it it runs Phoenix from the device itself,
and the USB cable that you use to plug it
into your computer with actually you know, opens up a
virtual Ethernet device, so you know, the device is actually
connected to your computer as a USB hid gadget, you know,
(18:42):
like as keyboards present themselves, but it also presents itself
as an Ethernet device, so you can SSH to it,
you can get into a shell that's running directly on it.
You can run a Phoenix web server from it, which
we are doing, and so you can use your browser
to visit the Phoenix Live view interface that we're building
for it, and you can you know, change various settings
(19:04):
about about your your keybo keypad. You can you can
configure the animations, you can you can even preview the
animations uh, in the browser itself, and we've got this
we just uh, we just finished this last week. It's
it's very interesting. It was a very fun project doing this.
Where we have the animation engine running on the device itself,
(19:26):
that's you know, painting the keys various colors and and
but the but the actual physical LEDs are just an
abstraction to that. And we have the Phoenix Live View interface,
which is also just an abstraction on top of that.
So really like we have a common engine that's performing
the animations, but it draws both to the physical keyboard
(19:46):
and to the live view page at the same time,
and it's and the events are synchronized.
Speaker 6 (19:51):
That's nice.
Speaker 2 (19:52):
That's pretty cool.
Speaker 6 (19:53):
Yeah.
Speaker 2 (19:54):
I would have never thought about having an Ethernet device
over USP. So now the next question is when when
is the kickstart going up? And how can I sign
up for one of these custom PCBs? Iily print think, Yeah,
good question. We are definitely still in very early days here.
We're still prototyping the software to make sure it makes sense.
(20:14):
And of course the PCB is completely not designed yet.
I have not I do not have a background in electronics.
I don't know how to design PCBs. So there are
many tutorials in my future on learning this stuff and
figuring out how to design it right. And you know,
we're gonna need to go through several rounds of prototypes.
(20:35):
That's not to say that I'm not, you know, completely
new to this scene.
Speaker 1 (20:39):
I have.
Speaker 3 (20:40):
You know, I did kind of jump headfirst into the
mechanical keyboard rabbit hole a little while ago before trying
it with Elixir, So I have built several keyboard kits myself.
But but the actual step of designing your own PCB
from scratch, that's that's the next hurdle that I don't
really know how to get over.
Speaker 2 (21:01):
Defnet let us know, because I'll give you my money.
Speaker 6 (21:06):
Yeah, it seems like there would be a lot of
interesting things to product like this. Even looking at if
you're using a Raspberry Pie for a keyboard, you actually
have a computer in the keyboard, a full computer in
the keyboard, which sort of makes me think of the
(21:27):
some Amiga computers I've seen, which are a computer and
a keyboard. But also I started wondering, could you use
an existing keyboard design and mostly hook up the correct
electronics to actually drive an existing design? How feasible would
(21:47):
that be? Have you looked into it?
Speaker 3 (21:49):
Yes? Actually, the keyboard is actually not my first attempt
at this. I did actually build old an existing PCB
design that I found online and got. I sent off
the the designs over to a lab in China and
(22:10):
got five of them printed because that was the minimum
number that you can print, uh. And I put together
this keyboard kit like completely from scratch myself. I like
got all the you know, the metal plates, laser cut
and and soldered the PCB together and soldered all the
switches on it. But I was originally following a guide
(22:32):
that used an Arduino micro controller. So that was my
first keyboard. I put it together with the Arduino micro
controller and it's running the QMK firm where it written
in C. The second time I had and of course
I had a couple of extra PCBs lying around, so
I took the I took the existing PCB and I
(22:52):
did connect a I originally connected a pocket beagle to
it from from beagle Bone, so that's another that's another
development board that I would also highly recommend, beagle Bone
Black and Pocket Beagley. They also run nerves, so I
used one of those with the existing PCV of course,
(23:13):
you know, like the pcvs were designed for the Argumento,
so the pinholes didn't line up, so I you know,
I I hacked it together and and that is also
that was my first first ever prototype. That one is
also running Elixir and nerves. It's not running the z
Bo firm where it's running a different one, and it's
a little older now, but a lot of the learnings
(23:35):
that I did from that one went into the Zebo firmware.
Speaker 6 (23:41):
So what you're saying is you have a you have
a full working mechanical keyboard with nerves on it.
Speaker 3 (23:48):
Yes, I do, but it doesn't have the full RGB
LED backlight. So I'm sad that's no good.
Speaker 2 (23:56):
But you're only half as productive without the LED is going.
So that's why I got That's why I got to
take it to the next level with the LEDs.
Speaker 6 (24:06):
It seems like you might have a lot of options
down the road as well. Have you looked at the
GRISP two board. I don't think that's done entirely yet.
And then there's also of course Luhman, which I tend
to mention on every episode, which will build to web assembly.
And as far as I know web assembly does run
(24:28):
on the ESP thirty two, which is a micro controller.
Speaker 3 (24:32):
That is very interesting. I will definitely keep my eyes
on that. I was not aware that Luhman was targeting
targeting embedded hardware, so that's that's very interesting to hear.
I As far as the GRISP too, yeah, we've we've
been aware of it for a while. I actually have
one of the other community members who's part of this
(24:54):
keyboard project pre ordered two of the GRISP two boards,
and they were supposed to have been here, you know,
six months ago, but they've been severely delayed. So we're
still we're still waiting on those to see, you know what,
the viability of those boards are.
Speaker 6 (25:14):
Maybe better to build with something something that actually exists
for now, And.
Speaker 3 (25:20):
In the case of.
Speaker 6 (25:20):
LOOM and the target, the first priority is basically web
web assembly for web. But I don't see any reason
why the end web assimply product wouldn't work on micro controllers.
So changing gears. Back to the calendar library you were
talking about, I've always looked into like Google Calendar and
(25:45):
seeing that you can set a calendar and to repeat
according to a rule set that can be pretty intricate,
and it just figures out when it should place these
events on your timeline and in your calendar. And the
thing I've always thought about a little bit and wondered
(26:06):
how do they do that effectively and efficiently, is when
you remove or change singular events in a repeating one
or move one of them, it seems like a terrible headache.
Can I imagine this is what you've been getting familiar with?
Can you speak to that?
Speaker 3 (26:25):
Yeah, definitely. Like I said, I've built two of these
libraries now, although one of them maybe doesn't count as much,
but we'll get back to that. This this concept of
calendars and date recurrence rules and things like that has
been around for quite a while now, and it's it's
(26:48):
an official I E. T F proposal. I've pulled it
up here so that I get the numbers right. This
is actually RFC five five four five. It's called the
I Calendar spec right. Uh, it's it's it's like, you know,
a lot of a lot of smart people and a
lot of smart companies have come together to kind of
say this is how you do it, right, This is
(27:09):
the spec. This is how you do calendars with recurring,
recurring events. So this spec is huge it's a very
very large spec and you know, like reading through hundreds
of pages of specs is not, you know, not anybody's
idea of a fun time. I don't think. And uh,
but but I did, you know, spend a good amount
(27:31):
of time reading the sections on how they define recurrence
rules and how they're meant to be interpreted. So the
basic idea behind this is that you've got a concept
of an event, and that event can have any number
of recurrence rules in it, and the the recurrence rules
act as like a set union and and then within
(27:56):
that event, you can also have any number of exception dates,
and those exception dates, just like set minus, they just
remove that occurrence from the set. Right, So if you've
got a simple event that's like every Wednesday often too infinity,
but then you want to cancel this one on this
one specific Wednesday, you just put that specific date time
(28:17):
recurrence into your exception set. And then you can also
of course add arbitrary dates into the set as well.
So that's the basic mechanics that you got there. And
but like all the complication really lies in the recurrence
rule construct.
Speaker 6 (28:37):
Thanks, I figured it had to be something like that,
but I've always wondered.
Speaker 1 (28:44):
One of the few things that I have not enjoyed
about working with Alixir is working with dates and date time.
I don't think that's unique to Alexir. I think that
could be one of the biggest headaches really of programming
in general, but in particular, I feel like it always
takes me longer than I want it to to do
anything which date or day time. So I'm curious if
you ran into like any headaches or gotcha's when deving
(29:05):
on used calendar libraries.
Speaker 3 (29:08):
Yes, Uh, it is generally a universal uh thought that
date and date time is hard in most programming languages.
And uh and you know, we at Peak of course
deal with it a lot. So anytime a bug comes
up around dates or time zones specifically, we know that
(29:30):
it is gonna be a hard bug. Right. Time zones
are one of the hardest things to get right and
to and to figure out right. But uh, that being said,
I honestly think that elix Or may not have gotten
it completely right. But Elixer is one of the languages
that has you know, in my opinion, some of the bait,
(29:52):
some of the best date and date time handling out there.
They they approach that you know, they didn't they didn't
appro which it like all at once. Uh. Like some
languages like have to have like a fully fledged date
time implementation all up front. It looks a like backed
off and said, no, we're gonna give you some like
basic building blocks. And it really doesn't do much, you know,
(30:14):
So if you need to do something fancier with like
time zones and date math and date edition, then you
got to go to another library that handles it like
and and you know, and for the longest time we
had time X, which you know is a is a
good library. I dealt with it a lot while building
my library Cocktail, and I dealt with the performance problems
(30:34):
of it a lot. I opened several issues with the
maintainer of time x, uh, wondering, you know, what's going
on with all of this, with all of this slowdown,
and and really, you know, the ultimate answer is just
that this is hard and and uh and dealing with
time zones is hard and and like, uh, you know,
adding to date or you know, like adding time to
(30:54):
one date time is a very hard question to answer,
especially if it's like in an in a specific zone,
because in specific time zone sometimes don't exist, sometimes exists twice. Uh,
it gets it gets very complicated and hairy. But but
the library that I've I've written for the recurrence rules,
(31:17):
it's called Cocktail, and it's open source on our on
the Peak Travel GitHub organization. It it uh as far
as I know, works pretty well, has good test coverage
and and I'm not sure if there I mean, actually okay,
there is. There is a couple. There are a couple
of fild bugs, but I'll take care of those at
(31:38):
some point. But the way it works internally is that
you you build up your recurrence rule sets that I
described earlier, and you you put them together into into
a into an event, and then from that you can
generate an elixir stream, a lazy stream.
Speaker 1 (31:56):
Right.
Speaker 3 (31:56):
That's that's what it all comes down to. You you
want you want to set your rules, you put it
together into a data structure and you put that into
a lazy stream, and then from that stream you can
you can take right, you can take as many instances
as you want, and you can you can you know,
if you want to say, like give me the next
thirty occurrences, you just m take thirty out of that
(32:17):
stream and it gives them to you, that's pretty cool.
Speaker 2 (32:20):
I can definitely relate to the date time problem. I
was working at a logistics company a few years ago,
and we had, like we're tracking drivers and there were
some cases where like a driver on daylight's savings time
like that that time would drive across the time zone,
and so like we would, for whatever reason, you know,
(32:40):
super edge case, we would negate their time. And it's
like implementing the fix for that particular case was just
like if statement after if statement after if statement to
try to make sure like their time bookkeeping was totally
right for that you know, block of six hours that
was just ridiculous, and I could totally feel that pain.
Speaker 3 (32:59):
Yeah, I actually have some advice, I think to anybody
who runs into these kinds of problems. What we ended
up doing, you know, as like our you know, I
don't know, third approach to this problem was just to
remove time zones completely out of the mix. Like originally,
(33:19):
like some of our legacy systems, right every daytime instance
in the system was a zoned time. It was like
this time in Pacific time or this time in Central time,
and you run into all sorts of issues like exactly
what you described right, you run into daylight savings times issues.
You know, like this time was valid, you know, you know,
(33:40):
like this time that was you know, persistent in the
database is a daylight savings time, but you know it's
no longer daylight savings time. You got to take that
into account. It gets really hairy and really confusing very fast.
So our last approach, when we switched to Elixir, and
you know, rewrote a large chunk of our system in Elixir,
we said we're taking time zones completely out of the mix.
(34:03):
Every single time in our system is a naive daytime
until you need the zone. So you what you want
to do is you want to apply the time zone
to your naive time as late in the process as possible,
like right when it goes out the API to be
displayed to the user, or you know, right when you
(34:24):
need it to know whether or not you have to
like enforce booking cutoff rules, you know, or something like that.
So but throughout the entire rest of the system, we
just store naive day times and that has drastically simplified
the working with dates and times for us.
Speaker 2 (34:41):
Yeah, I'll definitely plus one. That's that's kind of the
route we went down everything was being after the fact.
We started everything as UTC and then it was just
presentation layer. How do you convert to the time zone
that makes sense for the viewer of that of that data.
So yeah, definitely definitely a good way.
Speaker 3 (34:55):
To go, right, And actually just a small detail there.
That's one of the things that I think, you know,
Elixer did so well. Elixer has a naive daytime construct,
and that is not the same as a UTC daytime, right.
A naive daytime is you know, like five o'clock on Wednesday.
(35:18):
It's not five o'clock on Wednesday in UTC. It's it's
just an abstract concept of a time anywhere, and that's
that's what we deal with. Rather than like having actual
like UTC daytimes everywhere and then converting, it's more of
it's more of having a naive construct of a daytime
and applying a time zone to it after the fact.
Speaker 6 (35:41):
I definitely know I've seen my fair share of time
based bugs, the most traditional probably being a chron job
that was running nightly and at a certain point the
client I gets in touch and like, yeah, the SYNK
didn't go the same thing.
Speaker 3 (35:59):
Something's wrong.
Speaker 6 (36:00):
Did you check? No, the time just never occurred. The
actual hour did not exist because it was set to
go maybe two in the morning.
Speaker 3 (36:11):
Yeah, that's true. Two am sometimes doesn't exist.
Speaker 6 (36:17):
Perfect.
Speaker 4 (36:17):
All this talk about time is giving me a thousand
yards stare definitely like a little PTSD from all the
bugs and stuff introduced that I don't know. Elikser one
dot eleven is introducing even more things to the calendar class.
At daytime class, it finally gets strift time.
Speaker 3 (36:34):
So that's pretty cool.
Speaker 4 (36:36):
But there's something interesting about, sort of, like you said, Chris,
delaying building out the full library, sort of like giving
it time to breathe.
Speaker 3 (36:43):
What does the community? What does it?
Speaker 4 (36:44):
What does it actually mean to be part of the
I guess the standard library, which has been pretty cool.
Speaker 6 (36:52):
I just want to punctuate this conversation about time with
one of the keynotes. I saw a code beam Stockholm
in twenty nineteen, which was why time is evil and
distributed systems, which I found enlightening at the time, and
it seems appropriate for now we'll link that into show notes.
Speaker 1 (37:14):
It's funny because the conclusion, like Chris, that you're recommending
in alex that you're saying you've also come to right,
which is that you know, daytime is naive and you
can apply time zone as you didly there is exactly
the conversation that my team on at GitHub is having
about you know, time zones being applied to a product
that we're deving on. And like, the very last thing
(37:35):
I did work wise before joining this call was like
thumbs up the resolve discussion thread that came to this
exact conclusion. So yeah, definitely with.
Speaker 2 (37:44):
You rewinding a bit to running elixirn production at peak,
how have your experience has been with running elixirn production.
Do you guys do like hot cotigrades, do you target
the vms, do you target containers? What does that story
look like if you can divulge detail there.
Speaker 3 (38:03):
Yeah, all in all, our our move to Elixir in
production was was pretty successful, especially from like a performance perspective.
We definitely got to massively cut down on the number
of you know, instant application instances we had to run
(38:25):
in Ruby compared to Elixir, and Elixer is just you
know a lot more efficient. So from yeah, so from
performance perspective, it's been really great. We do have we
we are targeting containers, we're running in Kubernetes, we are
not doing hot code uh up updating and running Elixir
(38:50):
applications inside of containers inside of like a container orchestration
system like that does you know sometimes you know, people
feel that kind of goes against uh, the the the
ideas behind the beam. It goes against some of the
concepts and and we felt that, and we've we felt that,
you know, that kind of like push and pull and
had to kind of work through that, like getting getting
(39:12):
all of our Elixoria application instances talking to each other,
you know, clustering them together so that they form a
form a node cluster is kind of annoying and difficult
and making sure making sure that that cluster is stable.
We've had problems in the past where we we wanted
to rely on we wanted to rely on uh, you
(39:32):
know cluster global U states, cluster global processes for for
the purposes of you know, global locking and things like that,
and and it works like you know, most of the time.
But then we get like a bad deploy and the
cluster never reforms correctly, and now there's two schedulers running
instead of one across the whole cluster, and and that
(39:56):
causes disasters. So it has been a bit of a struggle,
you know, getting getting that stuff worked out. But in
the end we just kind of we we just reach
for some of the more standard tools, like if you
need something that's you know, like a like you know,
a singleton, like a global something or other than okay,
(40:17):
we can just use reddis or we can use post
grist or something like that, and that works for us.
Speaker 1 (40:23):
You know.
Speaker 3 (40:23):
So maybe that's sad that we're not, you know, leveraging
some of the you know, fun capabilities of the beam,
but but it definitely is a lot more reliable going
this direction. But other than that, you know, one of
the things that I think just like is one of
the best properties of the beam itself is just the
(40:44):
way the scheduling works, the internal scheduling, right, you know,
it can we can have in our Ruby applications if
we had you know, somebody triggers something in our system
that was just a little too much for it. You know,
We've got a lot of issues where like people will
try to like massively reschedule a three year long calendar
(41:06):
or something like that, and then it takes our system down, right,
you know, because because Ruby, when when one piece of
Ruby gets overloaded. It kind of like affects the entire
system it, you know, like you start dropping all other
requests and there's too much garbage collection going on and
things like that. Elixra just has been able to handle
things like that so much better. And that's because of
(41:27):
the you know, the property of the being that everything
it's it's the fair scheduler that allows all processes a
fair amount of time, so you don't you can't have
one request or one part of the system, you know,
go completely haywire and take down the rest of it.
It's like, you know, if if the systems overloaded, then
(41:48):
the entire systems overloaded, which which is which is really nice.
Speaker 2 (41:52):
A quick followup to that, for for the tools for
creating the cluster, and kuminators are using swarm and lib
cluster and gusting or hord, we're.
Speaker 3 (42:03):
Using Yeah, we're using lib cluster for the clustering aspect
of it. I I was we we are in Kubernetes,
but we we didn't decide to use the Kubernetes lib
cluster behavior. We wanted to do it through DNS and
at the time, the DNS behavior, the DNS implementation didn't exist,
So I was actually the one that wrote the DNS
(42:26):
lib cluster behavior and contributed that it's changed a lot
since the last time I looked at it, but that
was that was what we wanted and needed at the
time because we were not exclusively in Kubernetes, or rather,
I mean we are in production, but we also run
the entire stack like locally on dev machines, and that's
using doctor compose, so we needed we needed a mechanism
(42:48):
that works in both places. So the lib cluster DNS
mechanism is is pretty good for that. We were using
swarm at one time too on top of that, but
I don't we're not using it anymore. We don't really
have a need for it. We we just needed the
nodes to cluster together so that a couple of a
couple of things throughout the system, you know, had access
(43:11):
to the cluster.
Speaker 6 (43:12):
When it comes to when it comes to things like
the hot code loading or hot updates. I seem to
find that most people aren't using it because it does significant,
significant overhead for just making sure that you're doing perfect
well behaving updates. I haven't tried it, I've never heard
(43:36):
of I haven't spoken to many people that have tried it,
so I think the normal case and like the ninety
percent case, the ninety nine percent case is that people
can just use Elixir and Phoenix and all that just
as normal, a pretty normal run time running into doctors. Fine,
(43:58):
there's nothing particular range about it. But you can do
a bunch of interesting things. And as you say, there
are some advantages you can have from clustering up and
letting things talk to one another. But you don't even
have to.
Speaker 3 (44:13):
Yeah, just we should chat some time.
Speaker 4 (44:15):
I have a system that runs with hot code upgrades
and production, and we started deploying some with like regular
blue green start stop. It is so less, you know,
the stress level is like on a different level having
to manage you know, the state the shape of my
data when upgrading a genser that has like clients interfacing
(44:37):
with it is the different set of problems. It is
cool and I think we get a lot of value
out of it. I think for the system that we
use it for when you sort of need it to
never go down.
Speaker 3 (44:49):
But it is it comes with a different set of problems.
Speaker 6 (44:53):
Yeah, it's a unique feature which doesn't thinks that most
systems languages can or couldn't really do safely and Elixir
and the Beam and neerline allow us us to do it,
but it comes with us out of problems. I can
imagine we should have you on the show sometimes.
Speaker 3 (45:13):
I'd love to be on.
Speaker 1 (45:15):
I think that would make a great blog post actually,
kind of like a hot take. You know what I
hate about hot code upgrades because definitely on the list
of like shiny Elixir features that people just kind of
rattle off when they're talking about how great it is.
But yeah, I feel like it kind of falls into
one of two cancel ours. Like you said, do you
really need it? And then Steven, like you said, if
you do need it, it introduces a whole host of
considerations that you know you're going to have to deal with.
(45:37):
And I think it's a topic that doesn't really get
talked about a lot beyond the like, oh cool thing
that Electa can do. So someone should totally write that
and then we could maybe have them on the show
and talk all about it.
Speaker 2 (45:49):
I'm doing this at work right now, so I'll let
you guys in a few weeks how miserable that failed
or how awesomely I've succeeded.
Speaker 5 (45:56):
That I'm sure to succeed awesomely, but have so many
learnings for us for sure.
Speaker 1 (46:02):
All right, so we are coming to the end of
our time together, so why don't we move it over
to picks If anyone has any recommendations fun things to share.
Could be a looks related, could be programming related, could
be something totally else, And we'll go down the list. Terre,
We'll start with Stephen.
Speaker 4 (46:19):
So I have a coding one and then a non
coding one.
Speaker 3 (46:22):
So I've sort of.
Speaker 4 (46:23):
Been having a bit of an existential crisis. Do I
hate mocking? Am I like an anti mock person? I
just sort of feel like maybe the way that I'm
doing it is not right.
Speaker 3 (46:32):
I know.
Speaker 4 (46:32):
Alex wrote a really great blog post about database lists,
you know, repos or integrating integrating without actually hating the database,
which is kind of interesting and made me think a
lot about some things. Uh. Blog posts by James Shore
testing without mocks was really good, sort of a cross
between a blog post and a wiki, very beefy if
you know his writing. Yeah, I'm sort of like having that, uh,
(46:58):
that discussion in my head. So that's that's my pick.
Go check that out and then tweet at me. Let
me know what you think. Underscore, Stephen Uniez, let me
know if I'm a total idiot for not liking mocks,
or if I'm right and you want to take up
arms against the mockists. My other pick this gonna be
kind of basic, but Hamilton. So I watched Hamilton, uh
(47:19):
and I really really enjoyed it.
Speaker 3 (47:20):
It's very cool.
Speaker 4 (47:22):
I then realized that I went to a terrible school
and know nothing about American history or you know.
Speaker 3 (47:27):
Other reasons. Uh.
Speaker 4 (47:29):
So my subsequent follow up was a combination of watching
Crash Course US History on YouTube, which is amazing, and
then the John Adams HBO series which is also really good.
Speaker 3 (47:39):
America.
Speaker 1 (47:41):
Thanks for those, how about you? Lars? So?
Speaker 6 (47:44):
I want to recommend a podcast that mostly helped me
when I was starting my own business, but I think
it is very relevant to people right now because it's
about slowing down. At the start, it claimed to be
productivity podcast, and to some extent that is. It's gone
a little wider in later seasons, but it's very much
(48:09):
about intentional work and slowing down to make sure your
ideas are have room to breathe and that you actually
think through what you're doing doing the right things, rather
than all the things that sort of thing, So I think, yeah,
I really recommend that. Joslyn link Caglie is the creator
(48:33):
so her Slowly podcast strong recommend.
Speaker 1 (48:35):
Thank you for those I'm excited to check that out.
How about you Cross, you have any picks for us?
Speaker 3 (48:41):
Yeah, So we didn't touch on this topic during this session,
but one thing that I'm still very interested in in
Elixir is property testing. I find the concept very interesting
and I have done some property testing both in you know,
my library is and in you know, for Peak. And
(49:03):
what really got me started on it was this talk
at Elixir conf twenty eighteen about how to pick properties
for property based testing. And I really recommend that talk.
It was it was very it was a very fun
talk to watch, and and it got me thinking about
(49:27):
how to do property testing well and has let me,
you know, experiment with that kind of stuff.
Speaker 1 (49:34):
Yeah, I'll actually plus one year pick. Michael Stalker, who
gave that talk is awesome, super smart guy, I think,
great speaker, great teacher. He's also one of the contributors
to alexer School, which is a free, open source online
alexri curriculum, and he and I teamed up last year
to do some workshops at alexri comp and he built,
of course all this excellent property based testing content and
(49:56):
lessons and I hadn't done anything with property based testing
before make a chance to work with him, and I
learned a ton from him. So if you haven't seen
this talk, definitely check it out. See do I have
any picks? I have the opposite of picks, which is
a request for picks. I received a birthday present recently
that I have no idea what to do with. It
is from my dad. It is a stand mixer, so
(50:17):
like big mixing you know for baking, attached to a bowl,
but it's like an industrial grade, like this thing belongs
to like a commercial bakery. It has horse power, it's
like refurbished. I don't know where he got into his
head that this is something that I would actually need
to use. So I would like to receive if anyone
(50:37):
you know is into this kind of thing, easy baking
recipes that somebody that isn't necessarily making a wedding gey
could do with their enormous stand mixer that they could
also use to I don't know power a small car,
perhaps a golf cart. So hit me up on Twitter
with your easy baking recipes, s M underscore to bendedetto.
Speaker 6 (50:59):
Well, come on your software developer, sour dough bread.
Speaker 1 (51:03):
I don't know. That seems like a lot. You can't
find yeast anywhere too, because everyone's doing their quarantine baking,
so that's.
Speaker 6 (51:10):
The point of yeast. It's wild. You don't need you can.
Speaker 3 (51:14):
Just make it.
Speaker 1 (51:14):
Yeah, that's true. I have heard that. Thank you so much, FIRS.
Speaker 3 (51:17):
That was awesome.
Speaker 1 (51:18):
I actually can't believe this is You mentioned this was
the first time you had done maybe a programming podcast,
and yeah that was great.
Speaker 3 (51:25):
Yeah, well thanks a lot, Yeah, thanks a lot for
the in right, thanks a lot for having me. It's
it was a very good experience.
Hello, everybody, Welcome to today's episode of Alixer Mix. I
am Sophie de Benedetto, and I am joined by some
of our still relatively new panelists. We have Lars Wickman. Hey,
did I say our last name right? Clo?
Speaker 2 (00:26):
Close enough?
Speaker 1 (00:26):
Okay, cool?
Speaker 3 (00:27):
We have Alex Kutnos howdy.
Speaker 1 (00:30):
Hey Alex, and we have Steven Nunez. Hello, hey, and
we are very excited to welcome today's guest, Chris Dose.
Speaker 3 (00:40):
I said that right, right, Yes, that's correct. Hello, and
thanks for having me.
Speaker 1 (00:45):
Awesome welcome. So Chris, we're super happy to have you.
Do you want to kick us off by introducing yourself?
Speaker 3 (00:52):
Yeah, well, I've been a software engineer for a little
while now, I was. I had to, you know, check
back at my LinkedIn to see how far back it
actually goes. Looks like I've been doing this for about
thirteen years now. I started out down in Louisiana at LSU.
I did some I taught workshops there as a student
(01:12):
in software, primarily things like HTML and CSS and javascripts,
but you know a little bit of PHP as well.
That was my first language. And from there I got
some jobs in Louisiana, but decided that that wasn't the
place to really propel the career I wanted. So I
(01:35):
moved to San Francisco and got a job with Peak
as a software engineer there and have been with Peak
since then for about a little over six and a
half years. And at Peak is where I got into
Elixir and started learning that super cool.
Speaker 1 (01:54):
I hadn't heard of Peak just in terms of it
being a company that is using alex or so I
was always exciting to add a new entry to like
my mental list of companies that are using Elixir and production.
Were they working with Alixer before you got there?
Speaker 3 (02:10):
Noe. We we were using Ruby primarily before before I
got there and when I got there, So for the
first two years while I was there, we were primarily
writing in Ruby, kind of going into service oriented architecture direction.
And then and I wasn't aware of Elixer actually, and
(02:34):
we we hired a new engineer who was a big
proponent of Elixer, you know, like an evangelist, and said, hey,
you should really check this out, and I did, and
he completely converted me. So I became an evangelist for
Elixer as well. And I suggested that we start exploring
it for future services. Since we were going in a
(02:54):
service oriented architecture direction, we could you know, experiment with
smaller services and say, hey does work. And thankfully it
did and we kind of got everybody on board with that.
And uh and we use Elixir now primarily, even though
we've got plenty of legacy systems around that are still
in Ruby. We don't tend to build new things in Ruby.
(03:18):
We we build all of our new stuff in Elixir.
Speaker 2 (03:20):
How did you find the process of either hiring Elixa
engineers or ramping up you know, Ruby developers and getting
them familiar with Elixa and the beam How did that
process kind of go?
Speaker 3 (03:34):
Uh? Well, thankfully, I guess we're we're a pretty small
engineering team. So the ramp up process for the existing
engineers on Ruby was was pretty pretty easy. For the
For the engineers that we had, we you know, like
we've got some smart people. They just kind of got it,
you know, and we we all kind of learned together,
you know, I mean, we were all new to it,
(03:56):
and uh, and yeah, that that worked out pretty well.
As far as hiring hiring new Elixir engineers, it definitely
is harder. The pool is is much smaller, but we
we've always been open to, you know, hiring anybody from
any programming background as long as they're interested and willing
to learn a elixer like we you know, we're we're
(04:17):
perfectly happy to have, you know, people that want to
learn a elixer but haven't had an opportunity yet, you know,
in a in a professional setting too, to use Alixer.
So you know, we were looking for people like that. Unfortunately,
of course, the the the recent pandemic and stuff has
drastically slowed us down, and we've been on a hiring
(04:38):
freeze ever since then. So that's kind of that's kind
of been on hold.
Speaker 4 (04:43):
And I'm always really curious about sort of teams that
transition into Elixer. So where I'm at now, we same
kind of story predominantly went from like Ruby Rail's background
to some psychopath came in and convinced everyone to go
and look at this elixer thing. It was, I don't
I forget it's a yeah. So we started building more
(05:04):
and more apps of it with it, and then it's
kind of like interesting because the journey is not just like.
Speaker 3 (05:09):
Hey, there's pipes here in gen servers.
Speaker 4 (05:11):
It's kind of like trying to figure out what are
the learning materials you need to get in front of
the team, how do you sort of organize it? Like,
we have smart people too, but we also realize that
if you don't, if you're not careful about like how
to convert an O mindset to a functional mindset, you
wind it was a really gnarly looking code. Did you
guys run into that at all? And if so, what
(05:31):
resources did you sort of use to books, guidance, any
sort of like uh, general tips.
Speaker 3 (05:38):
Well, yes, definitely. The early experiments and Elixer were definitely
a little weird, especially since we tried to kind of
out the gate, try some try some funny business that
like would have been a lot harder to do in
a Ruby, but we're like, but we're using alixter, now
we can do this. And those kinds of things turn
out to be bad ideas in the long run. But
(06:00):
you know, just like as an example, we had we
had one of these integrations that we were building where
we needed to like the the external API we were
integrating with was asynchronous in some places, but our API
is synchronous, so you know, okay, fine, so why don't
we just have you know a little layer here where
the internal synchronous requests HTTP request comes in. We spawn
(06:24):
up a gen server that holds on to that HTTP
request and then does the async actions with the external API,
and then whenever that a sync action is done, then
we can release the response uh to the you know,
to the HDTV client there, and uh yeah, it's it's funky,
and you know, ended up just being really hard to debug,
(06:44):
and I wouldn't necessarily recommend it.
Speaker 1 (06:48):
I feel like, are you me?
Speaker 5 (06:49):
I think we did that same thing in one of
our earlier I'm maybe not exactly saying, but very much
a situation where you have like an incoming web request
and then you're just doing something kind of overly complex
with gen servers and you know, your blocking response until
fifteen different things resolve.
Speaker 1 (07:05):
And yeah, I think the idea of it being extremely
hard to be bug with absolutely yeah, resonates.
Speaker 4 (07:12):
That is sort of interesting that because Elixir gives you
those tools to do it, like like, oh, I can
kind of imagine how like a set of persistence servers
running in like the background and hit this is perfect,
and then then.
Speaker 3 (07:23):
It hurts, hurts, hurts so bad. But then that's that's
part of learning. But I think.
Speaker 4 (07:29):
I think worth exploring because I think it helps you
understand sort of like the edges of you know, what
these tools can do for you.
Speaker 1 (07:37):
One thing that I know I was excited to ask
you about, Chris, is it looks like Peak at Peak,
you guys have one or two or a couple of
different Elixir open source libraries that you maintain, And I
think it's really exciting not only to see another company
using Elixir and production, but actually supporting and giving back
to the Electric community in that way. So I would
(07:57):
love to hear a little bit about the open source
libraries that guys developed. What did they do, why did
you build them, what's it like to maintain them, you know,
as you use them in production.
Speaker 3 (08:08):
Yeah, I am also excited about being given the opportunity
to develop and maintain these open source libraries. Thankfully, like
Peak is very open to that idea of you know,
giving back to the community, and so it was it
was largely my initiative to to carve out some of
the important bits or you know, some of the things
(08:30):
that we thought could make good libraries and uh and
put them up on this on this GitHub organization page. Here,
and uh, you know, it might not be a surprise
that a lot of the libraries that we do have
available are specific to what we do at PEAK, which
is building software for the tours and activities industry. Uh
(08:54):
And naturally that involves scheduling availability on calendars. So I've
got two libraries. The first that I developed is the
one that we are actually using in production. It's it's
lib a library around uh generating date recurrence date date
instances based off of date recurrence rules so that you can,
(09:15):
you know, schedule things on your calendar in complex weird
ways that you know people have, and we just needed,
you know, we needed a way to go from some like,
you know, small set of rules that like define a
schedule and be able to expand that out into concrete
instances of time. Right. Uh. So that's that's one of
the libraries that I wrote there. It's called Cocktail. I
(09:40):
have a similar one called xcal which uh, which is
another interesting thing to talk about.
Speaker 1 (09:47):
Uh.
Speaker 3 (09:47):
And then and then we've got a couple of other
little small libraries that were just kind of like little
tools that we needed for various things. The most notable
is probably ecto diff that that gives us a way
of getting a getting like a data structure that describes
(10:08):
the changes that you performed after the fact to an
ECDO schema, especially in the context of deeply nested ectoschemas
using associations like as many and belongs to associations, and
that's and that's been very helpful for us. We definitely
do use it in production, and it is useful.
Speaker 1 (10:30):
How have you found participating in the open source community
and Elixer compared to I don't know if you did
any open source let's say, in Ruby, which it sounds
like you had a background in, or if anyone else
has comparison open source contributions to share.
Speaker 3 (10:47):
Well, me personally, I didn't really contribute much to open
source other than my own libraries even before Elixir, and
and these libraries that I've got here, uh for Peak
are not you know, not exactly super popular, so I
don't get a lot of the you know, like I
(11:07):
don't there's not a lot of like, you know, action
going on there, so I don't. I don't have a
lot of experience with that yet, but I would I
would like to have it. That is changing a little
bit with a side project that I'm working on where
I've actually do have you know, multiple people from the
community involved now and that's just starting out, so we'll
(11:27):
see how that goes.
Speaker 6 (11:30):
And that would be the work with the what's it
called keyboard kit.
Speaker 3 (11:39):
Yes, that's the uh, the our our our initiative to
build Elixir powered mechanical keyboard firmware.
Speaker 6 (11:50):
Yeah, so could you dive into a bit what you've
been doing there and what you're and the goal would
be because the keybot Kit, as far as I understand
it is a mechanical keypad powered by rasper Pie and
for people who aren't familiar with nerves, Nerves runs on
Linux devices such as the respir Pie, so that's a
(12:15):
good target for nerves, and the keybo kit is fairly
let's call it a constraint space. It's a small keypad
rather than a full keyboard. So I'm very curious what
the what the both, what the project is right now
and where you hope to be headed with it.
Speaker 3 (12:34):
Yeah. Yeah, Like like you said, it's it's a it's
a small keypad. People also call them macropads because the
intent is that you you know, it's it's like a
little additional pad next to your keyboard in addition to
your primary keyboard that you can assign various macros to
and like, you know, have various little functions that you
have on your keys that you perform, you know, daily,
(12:57):
and you want to automate. That's kind of the purpose
of macropads. But we're using this Raspberry Pie powered keybo
as kind of like a prototyping are a prototyping device
for us to see how you know how to develop
a nerves based firmware for for what could eventually be
(13:18):
a full a full sized keyboard. As far as I know, though,
there are no full sized keyboards that are powered by
something like a Raspberry Pie. It has to nerves only
targets Linux machines like embedded devices that run embedded Linux.
(13:38):
You can't go all the way down to something like
an ard. We know a micro controller, and most mechanical keyboards, unsurprisingly,
I think, are powered by very small micro controllers that
are very very definitely not powerful enough to run Linux
and the beam. So this is definitely an experiment. Uh
it's it's going really well. I think we've we've got
(14:00):
a lot of really great libraries and development and and
it's fun to just play with this thing and see
what we can do. Uh, it's got you know, it's
got a grade of twelve r g B l eds
on it. We've been playing around a lot with building
out fun animations and stuff. You know, if you've seen
if you've seen some of the fancy mechanical keyboards that
(14:20):
you can that you can buy out there, they've got
you know, full full back light r g B l
eds that you know, animate in all sorts of fancy
ways and stuff like that. So that's kind of what
we're shooting for. The the the end goal being that
we want to actually design uh, you know, the keyboard itself.
You know, we we need to design the the PCB itself.
(14:44):
Uh and and get that get that printed and uh
and actually you know, design a case around it, and
you know, hopefully have that available at some point.
Speaker 6 (14:57):
This is a super interesting project. I'm also I'm also
very interested to see where it goes. But as of today,
what could people that are interested do with the keybo
kit and the things you've been working on. From what
I see, you have separate libraries for like the x
(15:19):
E bow feel free to correct the pronunciation there, and
then the AFK library, which seems a little bit more
general and for the for the wider mechanical keyboard idea,
is that about right?
Speaker 3 (15:33):
Yeah, that's that's correct. The idea is to use the
keybo as our staging ground for the libraries that we're developing.
So one of those libraries is called AFK. That is,
it's the Keyboard State Management Library, because it can actually
get kind of complex if you actually take a minute
(15:55):
to think about how keyboards work, and you know how
you have to manage like which keys are being held
down at which times and which ones get released at
which times, and and then when you throw in the
fancier features that we want, like for example, layer layer keys,
you hold down a key and it switches the entire
(16:15):
keyboard to a different layer, and things like macros and
and other other fancy features like UH like this feature
that we call tap keys, where you can actually have
a key, a physical key, act differently depending on whether
or not you tapped it versus whether or not you
held it. These are all features that come from the
(16:37):
Wider Mechanical Keyboarding community, but the by far the most
popular UH firmware out there, open source firmware for mechanical keyboards,
is called q and K and it's all written in C,
and I'm not a C programmer, but and and and therefore, uh,
(16:59):
it's very difficult for me to understand what's going on
in there. And to me, it kind of looks like
it's it's like a it's a it's a big, you know,
very large project with many many contributors that has has
kind of like gone and sprawled, so it's very hard
to contribute to it and understand it. And so my
goal was, well, I'm not a C programmer, but I'm
(17:21):
an Elixir programmer. I can I can do this in
a elixer and maybe in the process also make it
a little simpler and easier to contribute and and be
able to build higher level features, you know, in a
higher level language without having to drop down into C
to to do that kind of stuff.
Speaker 2 (17:39):
In that same spirit, is is this something that like
a Nerves you know, someone new to Nerves could jump
into and start contributing, you know, If not, maybe what
are some some starter projects that really help kind of
get you ramped up with what Nerves is, what the
development process looks like, and you know, how to get
familiar with all that.
Speaker 3 (17:58):
Yeah, Well, there are definitely things that you can jump
in on on the z BO firmware, which is what
we've been developing. There's there are things that you know,
someone who's not familiar with nerves can jump in and
start contributing with. I wanted to, you know, mention a
couple of other features that are actually on the in
(18:19):
the ZBO firmware that I that I forgot to mention earlier,
which is that it it runs Phoenix from the device itself,
and the USB cable that you use to plug it
into your computer with actually you know, opens up a
virtual Ethernet device, so you know, the device is actually
connected to your computer as a USB hid gadget, you know,
(18:42):
like as keyboards present themselves, but it also presents itself
as an Ethernet device, so you can SSH to it,
you can get into a shell that's running directly on it.
You can run a Phoenix web server from it, which
we are doing, and so you can use your browser
to visit the Phoenix Live view interface that we're building
for it, and you can you know, change various settings
(19:04):
about about your your keybo keypad. You can you can
configure the animations, you can you can even preview the
animations uh, in the browser itself, and we've got this
we just uh, we just finished this last week. It's
it's very interesting. It was a very fun project doing this.
Where we have the animation engine running on the device itself,
(19:26):
that's you know, painting the keys various colors and and
but the but the actual physical LEDs are just an
abstraction to that. And we have the Phoenix Live View interface,
which is also just an abstraction on top of that.
So really like we have a common engine that's performing
the animations, but it draws both to the physical keyboard
(19:46):
and to the live view page at the same time,
and it's and the events are synchronized.
Speaker 6 (19:51):
That's nice.
Speaker 2 (19:52):
That's pretty cool.
Speaker 6 (19:53):
Yeah.
Speaker 2 (19:54):
I would have never thought about having an Ethernet device
over USP. So now the next question is when when
is the kickstart going up? And how can I sign
up for one of these custom PCBs? Iily print think, Yeah,
good question. We are definitely still in very early days here.
We're still prototyping the software to make sure it makes sense.
(20:14):
And of course the PCB is completely not designed yet.
I have not I do not have a background in electronics.
I don't know how to design PCBs. So there are
many tutorials in my future on learning this stuff and
figuring out how to design it right. And you know,
we're gonna need to go through several rounds of prototypes.
(20:35):
That's not to say that I'm not, you know, completely
new to this scene.
Speaker 1 (20:39):
I have.
Speaker 3 (20:40):
You know, I did kind of jump headfirst into the
mechanical keyboard rabbit hole a little while ago before trying
it with Elixir, So I have built several keyboard kits myself.
But but the actual step of designing your own PCB
from scratch, that's that's the next hurdle that I don't
really know how to get over.
Speaker 2 (21:01):
Defnet let us know, because I'll give you my money.
Speaker 6 (21:06):
Yeah, it seems like there would be a lot of
interesting things to product like this. Even looking at if
you're using a Raspberry Pie for a keyboard, you actually
have a computer in the keyboard, a full computer in
the keyboard, which sort of makes me think of the
(21:27):
some Amiga computers I've seen, which are a computer and
a keyboard. But also I started wondering, could you use
an existing keyboard design and mostly hook up the correct
electronics to actually drive an existing design? How feasible would
(21:47):
that be? Have you looked into it?
Speaker 3 (21:49):
Yes? Actually, the keyboard is actually not my first attempt
at this. I did actually build old an existing PCB
design that I found online and got. I sent off
the the designs over to a lab in China and
(22:10):
got five of them printed because that was the minimum
number that you can print, uh. And I put together
this keyboard kit like completely from scratch myself. I like
got all the you know, the metal plates, laser cut
and and soldered the PCB together and soldered all the
switches on it. But I was originally following a guide
(22:32):
that used an Arduino micro controller. So that was my
first keyboard. I put it together with the Arduino micro
controller and it's running the QMK firm where it written
in C. The second time I had and of course
I had a couple of extra PCBs lying around, so
I took the I took the existing PCB and I
(22:52):
did connect a I originally connected a pocket beagle to
it from from beagle Bone, so that's another that's another
development board that I would also highly recommend, beagle Bone
Black and Pocket Beagley. They also run nerves, so I
used one of those with the existing PCV of course,
(23:13):
you know, like the pcvs were designed for the Argumento,
so the pinholes didn't line up, so I you know,
I I hacked it together and and that is also
that was my first first ever prototype. That one is
also running Elixir and nerves. It's not running the z
Bo firm where it's running a different one, and it's
a little older now, but a lot of the learnings
(23:35):
that I did from that one went into the Zebo firmware.
Speaker 6 (23:41):
So what you're saying is you have a you have
a full working mechanical keyboard with nerves on it.
Speaker 3 (23:48):
Yes, I do, but it doesn't have the full RGB
LED backlight. So I'm sad that's no good.
Speaker 2 (23:56):
But you're only half as productive without the LED is going.
So that's why I got That's why I got to
take it to the next level with the LEDs.
Speaker 6 (24:06):
It seems like you might have a lot of options
down the road as well. Have you looked at the
GRISP two board. I don't think that's done entirely yet.
And then there's also of course Luhman, which I tend
to mention on every episode, which will build to web assembly.
And as far as I know web assembly does run
(24:28):
on the ESP thirty two, which is a micro controller.
Speaker 3 (24:32):
That is very interesting. I will definitely keep my eyes
on that. I was not aware that Luhman was targeting
targeting embedded hardware, so that's that's very interesting to hear.
I As far as the GRISP too, yeah, we've we've
been aware of it for a while. I actually have
one of the other community members who's part of this
(24:54):
keyboard project pre ordered two of the GRISP two boards,
and they were supposed to have been here, you know,
six months ago, but they've been severely delayed. So we're
still we're still waiting on those to see, you know what,
the viability of those boards are.
Speaker 6 (25:14):
Maybe better to build with something something that actually exists
for now, And.
Speaker 3 (25:20):
In the case of.
Speaker 6 (25:20):
LOOM and the target, the first priority is basically web
web assembly for web. But I don't see any reason
why the end web assimply product wouldn't work on micro controllers.
So changing gears. Back to the calendar library you were
talking about, I've always looked into like Google Calendar and
(25:45):
seeing that you can set a calendar and to repeat
according to a rule set that can be pretty intricate,
and it just figures out when it should place these
events on your timeline and in your calendar. And the
thing I've always thought about a little bit and wondered
(26:06):
how do they do that effectively and efficiently, is when
you remove or change singular events in a repeating one
or move one of them, it seems like a terrible headache.
Can I imagine this is what you've been getting familiar with?
Can you speak to that?
Speaker 3 (26:25):
Yeah, definitely. Like I said, I've built two of these
libraries now, although one of them maybe doesn't count as much,
but we'll get back to that. This this concept of
calendars and date recurrence rules and things like that has
been around for quite a while now, and it's it's
(26:48):
an official I E. T F proposal. I've pulled it
up here so that I get the numbers right. This
is actually RFC five five four five. It's called the
I Calendar spec right. Uh, it's it's it's like, you know,
a lot of a lot of smart people and a
lot of smart companies have come together to kind of
say this is how you do it, right, This is
(27:09):
the spec. This is how you do calendars with recurring,
recurring events. So this spec is huge it's a very
very large spec and you know, like reading through hundreds
of pages of specs is not, you know, not anybody's
idea of a fun time. I don't think. And uh,
but but I did, you know, spend a good amount
(27:31):
of time reading the sections on how they define recurrence
rules and how they're meant to be interpreted. So the
basic idea behind this is that you've got a concept
of an event, and that event can have any number
of recurrence rules in it, and the the recurrence rules
act as like a set union and and then within
(27:56):
that event, you can also have any number of exception dates,
and those exception dates, just like set minus, they just
remove that occurrence from the set. Right, So if you've
got a simple event that's like every Wednesday often too infinity,
but then you want to cancel this one on this
one specific Wednesday, you just put that specific date time
(28:17):
recurrence into your exception set. And then you can also
of course add arbitrary dates into the set as well.
So that's the basic mechanics that you got there. And
but like all the complication really lies in the recurrence
rule construct.
Speaker 6 (28:37):
Thanks, I figured it had to be something like that,
but I've always wondered.
Speaker 1 (28:44):
One of the few things that I have not enjoyed
about working with Alixir is working with dates and date time.
I don't think that's unique to Alexir. I think that
could be one of the biggest headaches really of programming
in general, but in particular, I feel like it always
takes me longer than I want it to to do
anything which date or day time. So I'm curious if
you ran into like any headaches or gotcha's when deving
(29:05):
on used calendar libraries.
Speaker 3 (29:08):
Yes, Uh, it is generally a universal uh thought that
date and date time is hard in most programming languages.
And uh and you know, we at Peak of course
deal with it a lot. So anytime a bug comes
up around dates or time zones specifically, we know that
(29:30):
it is gonna be a hard bug. Right. Time zones
are one of the hardest things to get right and
to and to figure out right. But uh, that being said,
I honestly think that elix Or may not have gotten
it completely right. But Elixer is one of the languages
that has you know, in my opinion, some of the bait,
(29:52):
some of the best date and date time handling out there.
They they approach that you know, they didn't they didn't
appro which it like all at once. Uh. Like some
languages like have to have like a fully fledged date
time implementation all up front. It looks a like backed
off and said, no, we're gonna give you some like
basic building blocks. And it really doesn't do much, you know,
(30:14):
So if you need to do something fancier with like
time zones and date math and date edition, then you
got to go to another library that handles it like
and and you know, and for the longest time we
had time X, which you know is a is a
good library. I dealt with it a lot while building
my library Cocktail, and I dealt with the performance problems
(30:34):
of it a lot. I opened several issues with the
maintainer of time x, uh, wondering, you know, what's going
on with all of this, with all of this slowdown,
and and really, you know, the ultimate answer is just
that this is hard and and uh and dealing with
time zones is hard and and like, uh, you know,
adding to date or you know, like adding time to
(30:54):
one date time is a very hard question to answer,
especially if it's like in an in a specific zone,
because in specific time zone sometimes don't exist, sometimes exists twice. Uh,
it gets it gets very complicated and hairy. But but
the library that I've I've written for the recurrence rules,
(31:17):
it's called Cocktail, and it's open source on our on
the Peak Travel GitHub organization. It it uh as far
as I know, works pretty well, has good test coverage
and and I'm not sure if there I mean, actually okay,
there is. There is a couple. There are a couple
of fild bugs, but I'll take care of those at
(31:38):
some point. But the way it works internally is that
you you build up your recurrence rule sets that I
described earlier, and you you put them together into into
a into an event, and then from that you can
generate an elixir stream, a lazy stream.
Speaker 1 (31:56):
Right.
Speaker 3 (31:56):
That's that's what it all comes down to. You you
want you want to set your rules, you put it
together into a data structure and you put that into
a lazy stream, and then from that stream you can
you can take right, you can take as many instances
as you want, and you can you can you know,
if you want to say, like give me the next
thirty occurrences, you just m take thirty out of that
(32:17):
stream and it gives them to you, that's pretty cool.
Speaker 2 (32:20):
I can definitely relate to the date time problem. I
was working at a logistics company a few years ago,
and we had, like we're tracking drivers and there were
some cases where like a driver on daylight's savings time
like that that time would drive across the time zone,
and so like we would, for whatever reason, you know,
(32:40):
super edge case, we would negate their time. And it's
like implementing the fix for that particular case was just
like if statement after if statement after if statement to
try to make sure like their time bookkeeping was totally
right for that you know, block of six hours that
was just ridiculous, and I could totally feel that pain.
Speaker 3 (32:59):
Yeah, I actually have some advice, I think to anybody
who runs into these kinds of problems. What we ended
up doing, you know, as like our you know, I
don't know, third approach to this problem was just to
remove time zones completely out of the mix. Like originally,
(33:19):
like some of our legacy systems, right every daytime instance
in the system was a zoned time. It was like
this time in Pacific time or this time in Central time,
and you run into all sorts of issues like exactly
what you described right, you run into daylight savings times issues.
You know, like this time was valid, you know, you know,
(33:40):
like this time that was you know, persistent in the
database is a daylight savings time, but you know it's
no longer daylight savings time. You got to take that
into account. It gets really hairy and really confusing very fast.
So our last approach, when we switched to Elixir, and
you know, rewrote a large chunk of our system in Elixir,
we said we're taking time zones completely out of the mix.
(34:03):
Every single time in our system is a naive daytime
until you need the zone. So you what you want
to do is you want to apply the time zone
to your naive time as late in the process as possible,
like right when it goes out the API to be
displayed to the user, or you know, right when you
(34:24):
need it to know whether or not you have to
like enforce booking cutoff rules, you know, or something like that.
So but throughout the entire rest of the system, we
just store naive day times and that has drastically simplified
the working with dates and times for us.
Speaker 2 (34:41):
Yeah, I'll definitely plus one. That's that's kind of the
route we went down everything was being after the fact.
We started everything as UTC and then it was just
presentation layer. How do you convert to the time zone
that makes sense for the viewer of that of that data.
So yeah, definitely definitely a good way.
Speaker 3 (34:55):
To go, right, And actually just a small detail there.
That's one of the things that I think, you know,
Elixer did so well. Elixer has a naive daytime construct,
and that is not the same as a UTC daytime, right.
A naive daytime is you know, like five o'clock on Wednesday.
(35:18):
It's not five o'clock on Wednesday in UTC. It's it's
just an abstract concept of a time anywhere, and that's
that's what we deal with. Rather than like having actual
like UTC daytimes everywhere and then converting, it's more of
it's more of having a naive construct of a daytime
and applying a time zone to it after the fact.
Speaker 6 (35:41):
I definitely know I've seen my fair share of time
based bugs, the most traditional probably being a chron job
that was running nightly and at a certain point the
client I gets in touch and like, yeah, the SYNK
didn't go the same thing.
Speaker 3 (35:59):
Something's wrong.
Speaker 6 (36:00):
Did you check? No, the time just never occurred. The
actual hour did not exist because it was set to
go maybe two in the morning.
Speaker 3 (36:11):
Yeah, that's true. Two am sometimes doesn't exist.
Speaker 6 (36:17):
Perfect.
Speaker 4 (36:17):
All this talk about time is giving me a thousand
yards stare definitely like a little PTSD from all the
bugs and stuff introduced that I don't know. Elikser one
dot eleven is introducing even more things to the calendar class.
At daytime class, it finally gets strift time.
Speaker 3 (36:34):
So that's pretty cool.
Speaker 4 (36:36):
But there's something interesting about, sort of, like you said, Chris,
delaying building out the full library, sort of like giving
it time to breathe.
Speaker 3 (36:43):
What does the community? What does it?
Speaker 4 (36:44):
What does it actually mean to be part of the
I guess the standard library, which has been pretty cool.
Speaker 6 (36:52):
I just want to punctuate this conversation about time with
one of the keynotes. I saw a code beam Stockholm
in twenty nineteen, which was why time is evil and
distributed systems, which I found enlightening at the time, and
it seems appropriate for now we'll link that into show notes.
Speaker 1 (37:14):
It's funny because the conclusion, like Chris, that you're recommending
in alex that you're saying you've also come to right,
which is that you know, daytime is naive and you
can apply time zone as you didly there is exactly
the conversation that my team on at GitHub is having
about you know, time zones being applied to a product
that we're deving on. And like, the very last thing
(37:35):
I did work wise before joining this call was like
thumbs up the resolve discussion thread that came to this
exact conclusion. So yeah, definitely with.
Speaker 2 (37:44):
You rewinding a bit to running elixirn production at peak,
how have your experience has been with running elixirn production.
Do you guys do like hot cotigrades, do you target
the vms, do you target containers? What does that story
look like if you can divulge detail there.
Speaker 3 (38:03):
Yeah, all in all, our our move to Elixir in
production was was pretty successful, especially from like a performance perspective.
We definitely got to massively cut down on the number
of you know, instant application instances we had to run
(38:25):
in Ruby compared to Elixir, and Elixer is just you
know a lot more efficient. So from yeah, so from
performance perspective, it's been really great. We do have we
we are targeting containers, we're running in Kubernetes, we are
not doing hot code uh up updating and running Elixir
(38:50):
applications inside of containers inside of like a container orchestration
system like that does you know sometimes you know, people
feel that kind of goes against uh, the the the
ideas behind the beam. It goes against some of the
concepts and and we felt that, and we've we felt that,
you know, that kind of like push and pull and
had to kind of work through that, like getting getting
(39:12):
all of our Elixoria application instances talking to each other,
you know, clustering them together so that they form a
form a node cluster is kind of annoying and difficult
and making sure making sure that that cluster is stable.
We've had problems in the past where we we wanted
to rely on we wanted to rely on uh, you
(39:32):
know cluster global U states, cluster global processes for for
the purposes of you know, global locking and things like that,
and and it works like you know, most of the time.
But then we get like a bad deploy and the
cluster never reforms correctly, and now there's two schedulers running
instead of one across the whole cluster, and and that
(39:56):
causes disasters. So it has been a bit of a struggle,
you know, getting getting that stuff worked out. But in
the end we just kind of we we just reach
for some of the more standard tools, like if you
need something that's you know, like a like you know,
a singleton, like a global something or other than okay,
(40:17):
we can just use reddis or we can use post
grist or something like that, and that works for us.
Speaker 1 (40:23):
You know.
Speaker 3 (40:23):
So maybe that's sad that we're not, you know, leveraging
some of the you know, fun capabilities of the beam,
but but it definitely is a lot more reliable going
this direction. But other than that, you know, one of
the things that I think just like is one of
the best properties of the beam itself is just the
(40:44):
way the scheduling works, the internal scheduling, right, you know,
it can we can have in our Ruby applications if
we had you know, somebody triggers something in our system
that was just a little too much for it. You know,
We've got a lot of issues where like people will
try to like massively reschedule a three year long calendar
(41:06):
or something like that, and then it takes our system down, right,
you know, because because Ruby, when when one piece of
Ruby gets overloaded. It kind of like affects the entire
system it, you know, like you start dropping all other
requests and there's too much garbage collection going on and
things like that. Elixra just has been able to handle
things like that so much better. And that's because of
(41:27):
the you know, the property of the being that everything
it's it's the fair scheduler that allows all processes a
fair amount of time, so you don't you can't have
one request or one part of the system, you know,
go completely haywire and take down the rest of it.
It's like, you know, if if the systems overloaded, then
(41:48):
the entire systems overloaded, which which is which is really nice.
Speaker 2 (41:52):
A quick followup to that, for for the tools for
creating the cluster, and kuminators are using swarm and lib
cluster and gusting or hord, we're.
Speaker 3 (42:03):
Using Yeah, we're using lib cluster for the clustering aspect
of it. I I was we we are in Kubernetes,
but we we didn't decide to use the Kubernetes lib
cluster behavior. We wanted to do it through DNS and
at the time, the DNS behavior, the DNS implementation didn't exist,
So I was actually the one that wrote the DNS
(42:26):
lib cluster behavior and contributed that it's changed a lot
since the last time I looked at it, but that
was that was what we wanted and needed at the
time because we were not exclusively in Kubernetes, or rather,
I mean we are in production, but we also run
the entire stack like locally on dev machines, and that's
using doctor compose, so we needed we needed a mechanism
(42:48):
that works in both places. So the lib cluster DNS
mechanism is is pretty good for that. We were using
swarm at one time too on top of that, but
I don't we're not using it anymore. We don't really
have a need for it. We we just needed the
nodes to cluster together so that a couple of a
couple of things throughout the system, you know, had access
(43:11):
to the cluster.
Speaker 6 (43:12):
When it comes to when it comes to things like
the hot code loading or hot updates. I seem to
find that most people aren't using it because it does significant,
significant overhead for just making sure that you're doing perfect
well behaving updates. I haven't tried it, I've never heard
(43:36):
of I haven't spoken to many people that have tried it,
so I think the normal case and like the ninety
percent case, the ninety nine percent case is that people
can just use Elixir and Phoenix and all that just
as normal, a pretty normal run time running into doctors. Fine,
(43:58):
there's nothing particular range about it. But you can do
a bunch of interesting things. And as you say, there
are some advantages you can have from clustering up and
letting things talk to one another. But you don't even
have to.
Speaker 3 (44:13):
Yeah, just we should chat some time.
Speaker 4 (44:15):
I have a system that runs with hot code upgrades
and production, and we started deploying some with like regular
blue green start stop. It is so less, you know,
the stress level is like on a different level having
to manage you know, the state the shape of my
data when upgrading a genser that has like clients interfacing
(44:37):
with it is the different set of problems. It is
cool and I think we get a lot of value
out of it. I think for the system that we
use it for when you sort of need it to
never go down.
Speaker 3 (44:49):
But it is it comes with a different set of problems.
Speaker 6 (44:53):
Yeah, it's a unique feature which doesn't thinks that most
systems languages can or couldn't really do safely and Elixir
and the Beam and neerline allow us us to do it,
but it comes with us out of problems. I can
imagine we should have you on the show sometimes.
Speaker 3 (45:13):
I'd love to be on.
Speaker 1 (45:15):
I think that would make a great blog post actually,
kind of like a hot take. You know what I
hate about hot code upgrades because definitely on the list
of like shiny Elixir features that people just kind of
rattle off when they're talking about how great it is.
But yeah, I feel like it kind of falls into
one of two cancel ours. Like you said, do you
really need it? And then Steven, like you said, if
you do need it, it introduces a whole host of
considerations that you know you're going to have to deal with.
(45:37):
And I think it's a topic that doesn't really get
talked about a lot beyond the like, oh cool thing
that Electa can do. So someone should totally write that
and then we could maybe have them on the show
and talk all about it.
Speaker 2 (45:49):
I'm doing this at work right now, so I'll let
you guys in a few weeks how miserable that failed
or how awesomely I've succeeded.
Speaker 5 (45:56):
That I'm sure to succeed awesomely, but have so many
learnings for us for sure.
Speaker 1 (46:02):
All right, so we are coming to the end of
our time together, so why don't we move it over
to picks If anyone has any recommendations fun things to share.
Could be a looks related, could be programming related, could
be something totally else, And we'll go down the list. Terre,
We'll start with Stephen.
Speaker 4 (46:19):
So I have a coding one and then a non
coding one.
Speaker 3 (46:22):
So I've sort of.
Speaker 4 (46:23):
Been having a bit of an existential crisis. Do I
hate mocking? Am I like an anti mock person? I
just sort of feel like maybe the way that I'm
doing it is not right.
Speaker 3 (46:32):
I know.
Speaker 4 (46:32):
Alex wrote a really great blog post about database lists,
you know, repos or integrating integrating without actually hating the database,
which is kind of interesting and made me think a
lot about some things. Uh. Blog posts by James Shore
testing without mocks was really good, sort of a cross
between a blog post and a wiki, very beefy if
you know his writing. Yeah, I'm sort of like having that, uh,
(46:58):
that discussion in my head. So that's that's my pick.
Go check that out and then tweet at me. Let
me know what you think. Underscore, Stephen Uniez, let me
know if I'm a total idiot for not liking mocks,
or if I'm right and you want to take up
arms against the mockists. My other pick this gonna be
kind of basic, but Hamilton. So I watched Hamilton, uh
(47:19):
and I really really enjoyed it.
Speaker 3 (47:20):
It's very cool.
Speaker 4 (47:22):
I then realized that I went to a terrible school
and know nothing about American history or you know.
Speaker 3 (47:27):
Other reasons. Uh.
Speaker 4 (47:29):
So my subsequent follow up was a combination of watching
Crash Course US History on YouTube, which is amazing, and
then the John Adams HBO series which is also really good.
Speaker 3 (47:39):
America.
Speaker 1 (47:41):
Thanks for those, how about you? Lars? So?
Speaker 6 (47:44):
I want to recommend a podcast that mostly helped me
when I was starting my own business, but I think
it is very relevant to people right now because it's
about slowing down. At the start, it claimed to be
productivity podcast, and to some extent that is. It's gone
a little wider in later seasons, but it's very much
(48:09):
about intentional work and slowing down to make sure your
ideas are have room to breathe and that you actually
think through what you're doing doing the right things, rather
than all the things that sort of thing, So I think, yeah,
I really recommend that. Joslyn link Caglie is the creator
(48:33):
so her Slowly podcast strong recommend.
Speaker 1 (48:35):
Thank you for those I'm excited to check that out.
How about you Cross, you have any picks for us?
Speaker 3 (48:41):
Yeah, So we didn't touch on this topic during this session,
but one thing that I'm still very interested in in
Elixir is property testing. I find the concept very interesting
and I have done some property testing both in you know,
my library is and in you know, for Peak. And
(49:03):
what really got me started on it was this talk
at Elixir conf twenty eighteen about how to pick properties
for property based testing. And I really recommend that talk.
It was it was very it was a very fun
talk to watch, and and it got me thinking about
(49:27):
how to do property testing well and has let me,
you know, experiment with that kind of stuff.
Speaker 1 (49:34):
Yeah, I'll actually plus one year pick. Michael Stalker, who
gave that talk is awesome, super smart guy, I think,
great speaker, great teacher. He's also one of the contributors
to alexer School, which is a free, open source online
alexri curriculum, and he and I teamed up last year
to do some workshops at alexri comp and he built,
of course all this excellent property based testing content and
(49:56):
lessons and I hadn't done anything with property based testing
before make a chance to work with him, and I
learned a ton from him. So if you haven't seen
this talk, definitely check it out. See do I have
any picks? I have the opposite of picks, which is
a request for picks. I received a birthday present recently
that I have no idea what to do with. It
is from my dad. It is a stand mixer, so
(50:17):
like big mixing you know for baking, attached to a bowl,
but it's like an industrial grade, like this thing belongs
to like a commercial bakery. It has horse power, it's
like refurbished. I don't know where he got into his
head that this is something that I would actually need
to use. So I would like to receive if anyone
(50:37):
you know is into this kind of thing, easy baking
recipes that somebody that isn't necessarily making a wedding gey
could do with their enormous stand mixer that they could
also use to I don't know power a small car,
perhaps a golf cart. So hit me up on Twitter
with your easy baking recipes, s M underscore to bendedetto.
Speaker 6 (50:59):
Well, come on your software developer, sour dough bread.
Speaker 1 (51:03):
I don't know. That seems like a lot. You can't
find yeast anywhere too, because everyone's doing their quarantine baking,
so that's.
Speaker 6 (51:10):
The point of yeast. It's wild. You don't need you can.
Speaker 3 (51:14):
Just make it.
Speaker 1 (51:14):
Yeah, that's true. I have heard that. Thank you so much, FIRS.
Speaker 3 (51:17):
That was awesome.
Speaker 1 (51:18):
I actually can't believe this is You mentioned this was
the first time you had done maybe a programming podcast,
and yeah that was great.
Speaker 3 (51:25):
Yeah, well thanks a lot, Yeah, thanks a lot for
the in right, thanks a lot for having me. It's
it was a very good experience.
Popular Podcasts
Stuff You Should Know
If you've ever wanted to know about champagne, satanism, the Stonewall Uprising, chaos theory, LSD, El Nino, true crime and Rosa Parks, then look no further. Josh and Chuck have you covered.
Dateline NBC
Current and classic episodes, featuring compelling true-crime mysteries, powerful documentaries and in-depth investigations. Follow now to get the latest episodes of Dateline NBC completely free, or subscribe to Dateline Premium for ad-free listening and exclusive bonus content: DatelinePremium.com
CrimeLess: Hillbilly Heist
It’s 1996 in rural North Carolina, and an oddball crew makes history when they pull off America’s third largest cash heist. But it’s all downhill from there. Join host Johnny Knoxville as he unspools a wild and woolly tale about a group of regular ‘ol folks who risked it all for a chance at a better life. CrimeLess: Hillbilly Heist answers the question: what would you do with 17.3 million dollars? The answer includes diamond rings, mansions, velvet Elvis paintings, plus a run for the border, murder-for-hire-plots, and FBI busts.