The Masonite Web Framework With Joe Mancuso

WEBVTT
NOTE
Transcription provided by Podhome.fm
Created: 7/6/2024 4:17:31 PM
Duration: 2600.135
Channels: 1
1
00:00:13.505 --> 00:00:18.165
Hello, and welcome to podcast dot in it, the podcast about Python and the people who make it great.
2
00:00:18.619 --> 00:00:30.285
When you're ready to launch your next app, you'll need somewhere to deploy it, so check out Linode. With private networking, shared block storage, node balancers, and a 200 gigabit network, all controlled by a brand new API, you've got everything you need to scale.
3
00:00:30.745 --> 00:00:31.565
Go to podcastinit.com/linode
4
00:00:33.145 --> 00:00:36.285
to get a $20 credit and launch a new server in under a minute.
5
00:00:36.650 --> 00:00:38.110
And visit the site at podcastinit.com
6
00:00:38.810 --> 00:01:06.715
to subscribe to the show, sign up for the newsletter, and read the show notes. Your host as usual is Tobias Macy. And today, I'm interviewing Joe Mancuso about Masonite, the modern and developer centric Python web framework. So, Joe, could you start by introducing yourself? Yeah. My name is Jo Mancuson, like you just said. I'm a developer for about 10 years now. I started out as a kid when I was 14 years old. 24 now. And, yeah, I just have a love and a passion for developing software and
7
00:01:07.095 --> 00:01:07.550
projects.
8
00:01:07.950 --> 00:01:17.595
And do you remember how you first got introduced to Python? So I started out when I was 14 with the normal HTML, CSS, you know, the whole front end stuff. And then I got I introduced myself
9
00:01:18.295 --> 00:01:18.875
to PHP,
10
00:01:19.415 --> 00:01:21.575
and I've been into that for,
11
00:01:22.135 --> 00:01:27.149
pretty much until I was I joined the military and all that at 18 to 22. And
12
00:01:27.450 --> 00:01:29.549
when I was 22, I got introduced to
13
00:01:29.850 --> 00:01:31.229
Python and Django.
14
00:01:31.689 --> 00:01:38.955
Python, I just wanted to learn Python just to learn Python, so I went to the whole Codecademy thing and kind of introduced myself. And then I've learned I knew,
15
00:01:39.595 --> 00:01:42.495
PHP so well at the time that learning a new
16
00:01:43.420 --> 00:01:45.359
language was just became natural.
17
00:01:45.820 --> 00:01:55.375
So and Python is so beginner friendly and and intuitive that it only took me like a month to sort of master it, and then, I got into Django. I did that for about a year,
18
00:01:55.914 --> 00:02:00.420
and that's how I got introduced to the Python world. And you recently
19
00:02:01.040 --> 00:02:03.140
started the Masonite project.
20
00:02:03.680 --> 00:02:10.555
So I'm wondering if you can talk a bit about what it is and what was your motivation for creating it in the first place.
21
00:02:10.855 --> 00:02:11.595
So what
22
00:02:11.895 --> 00:02:13.355
Masonite is, it's
23
00:02:13.735 --> 00:02:18.690
a batteries included Python web framework that's going to rival Django. So
24
00:02:19.230 --> 00:02:23.525
a lot of the time they kind of compare Mesa and Django and how Masonite might fit in, but
25
00:02:24.084 --> 00:02:28.825
I'm kind of designing it to compete directly with it. So I mean eventually hopefully there'll be
26
00:02:29.125 --> 00:02:33.070
maybe Flask and Masonite and Django could can be 3rd. We'll see. But,
27
00:02:33.530 --> 00:02:35.070
That that's an ambitious goal.
28
00:02:35.530 --> 00:02:38.110
Yeah. It has to be. I mean, when you when you're trying to
29
00:02:38.730 --> 00:02:44.325
to overtake the unmoved movers in the Python community, it's you you you gotta put Masonite
30
00:02:44.945 --> 00:02:46.885
somewhere and then just try to achieve,
31
00:02:47.540 --> 00:02:49.080
and try to get it to that place.
32
00:02:50.020 --> 00:02:52.520
So but but the thing is that it's
33
00:02:53.060 --> 00:02:58.855
it's kind of redefining what batteries included is. It's more of a batteries included, like, Laravel is a batteries included.
34
00:02:59.235 --> 00:03:02.775
So Django might not have things that you might need, so you might not have,
35
00:03:03.280 --> 00:03:06.340
for example, s 3 might not be built in.
36
00:03:06.640 --> 00:03:07.620
You might not have,
37
00:03:08.160 --> 00:03:08.660
notifications
38
00:03:08.960 --> 00:03:11.485
built in like text message notifications
39
00:03:11.944 --> 00:03:14.204
or email notifications or database notifications.
40
00:03:14.504 --> 00:03:17.885
So all that sort of being built into the Masonite framework.
41
00:03:18.659 --> 00:03:19.719
So you really just
42
00:03:20.099 --> 00:03:24.519
do what you need to do and use the semantics of Masonite itself.
43
00:03:25.060 --> 00:03:28.094
So for and that's something else I want to explain about Masonite
44
00:03:29.034 --> 00:03:35.300
is sort of where I see Masonite fitting in. Like I said before, where I'm sort of putting it in a place and trying to get it there.
45
00:03:35.780 --> 00:03:37.480
I'm sort of picturing how
46
00:03:37.860 --> 00:03:39.320
Django is like an IBM
47
00:03:39.860 --> 00:03:53.670
and then Flask is like an HP, right, in like in the seventies and eighties, and Masonite is like an apple. So you're trying to move these unmoved movers and trying to liven up the community at the same time. So that's that's sort of where I see it. So Masonite
48
00:03:54.450 --> 00:03:57.910
the reason why I compare Masonite to Apple is because
49
00:03:58.530 --> 00:04:08.415
the word Masonite comes from masonite board, which Masonite board is what artists use to put their artwork on, so it sort of like flattens it to create like a hardboard.
50
00:04:09.260 --> 00:04:14.800
And so that's where I want to think of masonite framework is that the framework is
51
00:04:15.500 --> 00:04:18.640
a place where you could put your artwork on and sort of
52
00:04:19.085 --> 00:04:23.985
just like a normal framework, right? We're building this art and we're using these tools to build this art, and
53
00:04:25.324 --> 00:04:26.305
so with that
54
00:04:26.710 --> 00:04:27.610
kind of artsy
55
00:04:28.630 --> 00:04:31.610
and creative feel it has things like craft commands
56
00:04:32.230 --> 00:04:32.730
which
57
00:04:33.270 --> 00:04:36.615
are used to basically scaffold the application for you,
58
00:04:38.535 --> 00:04:40.235
And with the craft command actually
59
00:04:40.854 --> 00:04:42.474
when I originally started Masonite,
60
00:04:42.854 --> 00:04:43.354
we
61
00:04:43.655 --> 00:04:45.354
found or I found this
62
00:04:45.880 --> 00:04:53.100
or this developer found me, who is like an artist, I think. I don't even think he was a developer. I think he's an artist, and he wanted to develop a logo for it.
63
00:04:53.585 --> 00:04:57.605
So I was like, great. So we did a call, and he showed me, like, these concepts,
64
00:04:57.985 --> 00:05:00.245
and they're all, like, of cauldrons
65
00:05:00.625 --> 00:05:03.045
and, like, brooms and, like, witchcraft.
66
00:05:03.409 --> 00:05:15.275
That's what he thought when he thought of craft commands whereas these, like, witchcraft commands, like, you're you're crafting something. So but the way I want it to for people to look at Masonite and using these craft commands is that you're crafting
67
00:05:16.695 --> 00:05:19.995
a controller, you're crafting a class the same way like
68
00:05:20.710 --> 00:05:22.490
a blacksmith might craft a sword
69
00:05:22.870 --> 00:05:24.890
or a chainmail or something. So
70
00:05:25.430 --> 00:05:27.850
that's sort of where masonite is and
71
00:05:28.230 --> 00:05:29.085
sort of where it
72
00:05:29.805 --> 00:05:33.425
should fit into the ecosystem and and what I'm trying to achieve
73
00:05:34.125 --> 00:05:40.260
by creating it. And when reading through the documentation, it's clear that you put a lot of thought into
74
00:05:40.720 --> 00:05:42.660
the architectural principles
75
00:05:43.200 --> 00:05:46.419
and software design with things like the
76
00:05:47.325 --> 00:05:53.025
inversion of control containers and dependency injection built into the core of the framework. So I'm curious
77
00:05:53.565 --> 00:05:54.545
what your
78
00:05:54.925 --> 00:05:55.425
inspirations
79
00:05:55.979 --> 00:05:57.039
were for,
80
00:05:57.979 --> 00:06:00.080
other projects or frameworks
81
00:06:00.460 --> 00:06:06.055
that you were looking to for trying to see what would make for a,
82
00:06:06.915 --> 00:06:07.415
reasonable
83
00:06:07.875 --> 00:06:08.375
and,
84
00:06:08.915 --> 00:06:11.495
robust target for being able to
85
00:06:12.035 --> 00:06:14.135
use as a foundation for your new project?
86
00:06:14.740 --> 00:06:15.320
So the
87
00:06:15.860 --> 00:06:16.360
architectural
88
00:06:17.140 --> 00:06:20.040
design principles that I I sort of took
89
00:06:20.420 --> 00:06:21.880
from other projects was
90
00:06:22.420 --> 00:06:22.920
Laravel.
91
00:06:23.224 --> 00:06:25.004
So Laravel obviously has the,
92
00:06:26.185 --> 00:06:26.845
IOC container,
93
00:06:27.224 --> 00:06:34.289
and the entire framework is kind of built around this IOC container, and they have this, like, auto resolving dependency injections.
94
00:06:34.990 --> 00:06:38.449
They have all these, like, design principles and and the manager,
95
00:06:39.229 --> 00:06:40.565
pattern and stuff like that.
96
00:06:41.605 --> 00:06:42.645
So when I originally
97
00:06:43.765 --> 00:06:46.025
the original foundation of the project was
98
00:06:46.405 --> 00:06:51.389
I just wanted to learn what the heck a whiskey was, so I basically started
99
00:06:52.569 --> 00:06:57.465
going way back to the beginning and the build up to the architecture was I built everything
100
00:06:58.005 --> 00:06:59.044
let's go back a little bit more
101
00:07:00.085 --> 00:07:01.945
so the way WSGI works is
102
00:07:02.405 --> 00:07:03.385
you have this
103
00:07:04.085 --> 00:07:09.490
entry point So it could be gun of corn, it could be waitress, so you have this entry point where it
104
00:07:10.510 --> 00:07:12.530
passes basically a dictionary into
105
00:07:12.830 --> 00:07:17.015
whatever function that you want. So inside this function to be called the app function
106
00:07:18.355 --> 00:07:30.355
is all the kind of all the logic for it. So it could have the route parameters and it could have the cookies and all this stuff, and inside that function is where you put all your magic or not your magic, your your framework stuff or
107
00:07:30.815 --> 00:07:31.475
your guts
108
00:07:32.255 --> 00:07:32.755
and
109
00:07:33.455 --> 00:07:39.540
you can sort of abstract it away, you can import classes into this, and do whatever you want there. So what I did was
110
00:07:39.840 --> 00:07:42.980
to learn all of this, I put every single thing
111
00:07:43.280 --> 00:07:46.180
inside this function. So this function was like maybe
112
00:07:46.545 --> 00:07:47.685
500 lines long
113
00:07:48.145 --> 00:07:49.365
and that was the framework,
114
00:07:49.745 --> 00:07:53.605
and to make modifications, you had to make modifications to this giant function.
115
00:07:54.230 --> 00:07:58.970
And I thought it was cool. I mean, it was doing cool things. It was just completely unmaintainable, and
116
00:07:59.910 --> 00:08:06.225
it was actually inside the project itself. So if I needed to, like, upgrade the application, you had to make a whole new application.
117
00:08:06.925 --> 00:08:11.264
So there were sort of these learning principles, but I thought it was cool. So I put it on Reddit,
118
00:08:11.720 --> 00:08:13.260
and it was called, like, version
119
00:08:13.639 --> 00:08:14.139
0.3,
120
00:08:15.080 --> 00:08:33.500
and it got completely demolished. Alright. Everybody hated it because it was sort of cool. I got some cool feedback, but everybody said like it's completely broken and it's it's it's never going to be a thing, which stuff like that drives me, So what I did and 1 of the 1 of the recommendations and feedback I got was that it wasn't modular at all,
121
00:08:33.960 --> 00:08:36.300
and I really didn't understand the concept of modular.
122
00:08:37.464 --> 00:08:38.765
So I went to
123
00:08:39.305 --> 00:08:43.245
other frameworks for inspiration, so I went to Laravel, Django,
124
00:08:44.185 --> 00:08:44.685
Rails,
125
00:08:45.010 --> 00:08:49.750
and I just previously came from the Laravel world. So I had that mindset of
126
00:08:50.370 --> 00:08:56.084
service providers and IOC container and a provider's list or an array, right, from Laravel.
127
00:08:57.745 --> 00:09:02.165
And so I sort of built like these principles and it was actually turning out into something cool.
128
00:09:03.030 --> 00:09:17.010
So that went up to like a 1.3 release was the first time it actually had like an IOC container. And the reason why I wanted to do that and put it there was I saw as I'm developing something, right, the best way to learn something, I think, is to actually develop it from scratch.
129
00:09:17.410 --> 00:09:23.670
So then you know exactly how it works and you know exactly where things will break and where's the strength and what the weakness is.
130
00:09:23.970 --> 00:09:24.470
So,
131
00:09:24.850 --> 00:09:25.830
as I'm developing
132
00:09:26.865 --> 00:09:35.605
all this stuff, it's like slowly turning out to be awesome, and I'm starting to see the power of it, and I'm starting to take little pieces of the application and test it.
133
00:09:35.940 --> 00:09:40.840
So that's why it went from like 20% testability to like now I think we're at like 92%.
134
00:09:41.860 --> 00:09:45.000
So the framework is really really well tested it's actually really really stable,
135
00:09:45.935 --> 00:09:55.330
and it's at the 2.0 release, which is really good. And so yeah, so I learned that like the IOC container is extremely testable because you could load things into this container.
136
00:09:55.870 --> 00:10:12.639
And for these those of you that don't know what an IOC container is, should I go in to detail on that? I can add links in the show notes for people who wanna dive deeper on it, but, if you wanna just give a quick overview of sort of the principle. Okay. Sure. So a brief overview and and how at least it works in Masonite is
137
00:10:13.100 --> 00:10:19.495
there's a class called it's called the app actually, but it's actually a container. That's what it's called, but it is a container. So
138
00:10:20.035 --> 00:10:21.654
you have this dictionary
139
00:10:21.955 --> 00:10:26.310
inside this class that has every single class that you need inside a dictionary.
140
00:10:26.850 --> 00:10:28.470
So now you could use this container
141
00:10:28.850 --> 00:10:32.695
to fetch things out of. So say you want to you loaded
142
00:10:33.235 --> 00:10:36.375
an upload driver for loading things onto the file system,
143
00:10:36.755 --> 00:10:37.895
so you have your
144
00:10:38.520 --> 00:10:41.740
sort of your API that you use for that, but if you wanted
145
00:10:42.280 --> 00:10:44.940
to do maybe Amazon s 3,
146
00:10:45.320 --> 00:10:53.225
you simply just take it out and put in an s 3 driver and you just swapped out the whole functionality of your of your code. That simple.
147
00:10:54.540 --> 00:10:59.280
So, yeah, just a container is you just load things into it and then you fetch things out of it when you need it. Now
148
00:10:59.660 --> 00:11:17.020
what's even more powerful was what I saw was the dependency injection, which is doing the exact same thing, but all it's doing is before it calls your controller method, it's just reading your parameter list and then just fetching things for you. So you basically load it into your parameter list, so you might like in django, you have a request.
149
00:11:17.560 --> 00:11:18.060
Right?
150
00:11:18.464 --> 00:11:21.125
So with Masonite, you would put the request there,
151
00:11:21.584 --> 00:11:35.570
but Masonite is actually injecting it for you into that. So you could put anything you want there. So you could put an upload driver there, you can do whatever you want, and it'll inject it for you, and it knows exactly what you need. It's more powerful than just simply importing classes because it's swappable now.
152
00:11:36.035 --> 00:11:40.055
So you could add a service a service provider from a third party package
153
00:11:40.435 --> 00:11:45.079
that kind of adds functionality to your framework or swaps it out or adds methods
154
00:11:45.860 --> 00:11:47.399
to a driver that's already there.
155
00:11:47.940 --> 00:11:48.440
So,
156
00:11:48.980 --> 00:11:53.475
it's 2 really, really powerful concepts, and and I really think it's a superior architecture
157
00:11:54.415 --> 00:11:55.235
for frameworks
158
00:11:55.855 --> 00:12:02.420
just because there's such a reliance on testability, and and it's almost harder not to test Masonite than it is
159
00:12:02.720 --> 00:12:04.100
to test it. So,
160
00:12:04.800 --> 00:12:23.080
like, it's it's just so easy that you have to do it. Django, it's a little bit harder. It's it's not built in a way that's testable, right? It's like it was built in 2, 000 what, 6 I think or 2003 or I think 2006 and, it just kind of evolved and it uses some strange principles. So it's just kind of evolved over time into this
161
00:12:23.460 --> 00:12:25.320
thing that I don't think is
162
00:12:25.915 --> 00:12:39.910
good. I mean, it's great. I mean, Django is really good, but I think Masonite has the potential to overtake that spot. And people that use it have nothing but good things to say about it. Like, so once you use Masonite, you you're kinda hooked into it. Everything sort of makes sense. And so
163
00:12:40.290 --> 00:12:42.470
as you mentioned, 1 of the aspects
164
00:12:42.825 --> 00:12:46.205
of Masonite that makes it appealing is this,
165
00:12:46.825 --> 00:12:47.965
easy pluggability
166
00:12:48.425 --> 00:12:49.405
and extensibility.
167
00:12:50.425 --> 00:12:50.925
And
168
00:12:51.589 --> 00:12:52.250
in general,
169
00:12:52.630 --> 00:12:58.185
1 of the things that has helped Django maintain its momentum and its,
170
00:12:58.665 --> 00:13:00.125
relative lead in the,
171
00:13:00.585 --> 00:13:02.765
web framework space for Python is
172
00:13:03.145 --> 00:13:05.645
the community contributions and community modules.
173
00:13:06.130 --> 00:13:06.950
So I'm wondering
174
00:13:07.410 --> 00:13:16.875
how much engagement you've seen from the general community as far as creating new plug ins or some of the interesting uses that people have put Masonite to?
175
00:13:17.334 --> 00:13:18.615
So I've been,
176
00:13:19.254 --> 00:13:21.675
so I I fully understand that, and I know
177
00:13:22.214 --> 00:13:42.395
that a framework is really only as good. There's 2 things that make it make a framework good, I think. 1 is the community around it. Absolutely. So someone who has a really good community for someone who has a really bad community, the project that has a really good community always wins no matter what. And the second thing that makes a framework good or a package good, in my opinion, is
178
00:13:42.990 --> 00:13:44.290
that nobody cares
179
00:13:45.230 --> 00:13:49.410
how many features are in your framework. Nobody cares what your framework can do.
180
00:13:49.790 --> 00:13:50.770
Nobody cares.
181
00:13:51.835 --> 00:13:55.375
The only thing that people care is how they're how are they gonna interact with that framework.
182
00:13:55.995 --> 00:13:58.815
So if they get to a certain part on the framework
183
00:13:59.195 --> 00:13:59.695
where
184
00:14:00.519 --> 00:14:15.735
it's too hard or it doesn't make sense, they're just gonna revert back to, like, what they know, and it's it's almost harder to learn something new than it is to not learn something new. Masonite has a really, really simple API. So once you're going through each step, everything just feels natural
185
00:14:16.050 --> 00:14:21.589
and it just falls into place and you you're knowing how things interact with other things and you're abstracting things
186
00:14:22.050 --> 00:14:23.190
by its very nature,
187
00:14:23.795 --> 00:14:27.015
just because it's very, very easy to do to abstract things in Masonite.
188
00:14:27.955 --> 00:14:35.410
So yeah. So the the pluggability of the framework is actually really big. When I develop a new package, it really only takes me, like, a day
189
00:14:35.870 --> 00:14:38.290
to do what I have to do just because I could literally
190
00:14:39.070 --> 00:14:47.545
basically code a project and then create a a single entry point for that project calls called the service provider, and then anybody can plug that into their application.
191
00:14:48.360 --> 00:14:54.139
And all it's doing is all you have to do to develop a package for Masonite is load classes into the container.
192
00:14:54.839 --> 00:14:58.654
Like, that's it. That's all you have to do to connect a project to mace or a package to Masonite.
193
00:14:59.675 --> 00:15:04.654
Everything else, like the user in your documentation, you could tell the user, okay. You have to take this out of the container,
194
00:15:05.090 --> 00:15:07.190
use it to interact like this, and
195
00:15:07.650 --> 00:15:09.110
so on and so forth. So,
196
00:15:09.730 --> 00:15:12.385
like, recently I just created a a notifications package,
197
00:15:13.665 --> 00:15:17.045
and I just implemented a Nexmo, which is a text message
198
00:15:17.505 --> 00:15:18.005
service.
199
00:15:18.545 --> 00:15:21.205
So now I can send texts right from my project,
200
00:15:22.100 --> 00:15:22.600
And
201
00:15:23.779 --> 00:15:28.635
it took me like a day to implement the entire thing for text messaging, for
202
00:15:29.515 --> 00:15:32.815
and I only code at night too, so it really only took me like maybe 4 hours
203
00:15:33.515 --> 00:15:36.175
to code these packages. So it's really simple. The documentation
204
00:15:36.635 --> 00:15:37.135
is
205
00:15:37.810 --> 00:15:38.310
super
206
00:15:38.770 --> 00:15:42.630
super extensible from the beginning of the project from, like, 0.03.
207
00:15:43.650 --> 00:15:45.270
I knew I knew I knew that
208
00:15:45.730 --> 00:15:50.175
documentation was huge. Like I needed to have a really really well documented package.
209
00:15:51.595 --> 00:15:55.215
And so if you need any like questions or how to implement things,
210
00:15:56.080 --> 00:16:00.980
you can just read the documentation. If you have any questions I'm super super active in the community
211
00:16:01.440 --> 00:16:02.900
you can join the slack channel
212
00:16:03.265 --> 00:16:04.405
which is a slack.masoniproject.com
213
00:16:06.865 --> 00:16:13.690
and you can join there and you can ask any questions. The community is pretty active when it's active, right, so when everybody's sort of on.
214
00:16:14.470 --> 00:16:16.570
We have 2 maintainers, me and
215
00:16:16.950 --> 00:16:28.765
this developer named Abram, and we answer pretty much any questions that that come in. And that's 1 thing that I definitely noted as I was researching for this interview is that, as you mentioned, the documentation is
216
00:16:29.280 --> 00:16:30.500
very complete
217
00:16:31.360 --> 00:16:38.100
and reading through it was very well put together so it was easy to try and see how you might use different aspects of the project.
218
00:16:38.485 --> 00:16:40.345
And some of the features
219
00:16:40.725 --> 00:16:44.505
that stood out as being somewhat unique, at least within the Python landscape,
220
00:16:44.884 --> 00:16:45.865
is the
221
00:16:46.360 --> 00:16:48.060
built in support for
222
00:16:48.440 --> 00:16:48.940
the,
223
00:16:49.800 --> 00:16:50.300
asynchronous
224
00:16:50.680 --> 00:16:52.860
tasks for 1, but also for,
225
00:16:53.800 --> 00:16:54.300
WebSocket
226
00:16:54.985 --> 00:16:56.765
support using things like Pusher.
227
00:16:57.145 --> 00:17:00.685
Whereas for a lot of the other web frameworks, there is additional
228
00:17:01.145 --> 00:17:05.769
dependencies required for being able to have some of that dynamic
229
00:17:06.230 --> 00:17:08.570
bidirectional communication within the framework.
230
00:17:09.029 --> 00:17:13.850
Right. And I think that's why Mason and I I kind of coined the, the term of the modern developer
231
00:17:14.215 --> 00:17:18.795
Python web framework and developer centric because, I mean, things like that. I have a principle that
232
00:17:19.255 --> 00:17:21.515
things should be taken out of a framework
233
00:17:22.080 --> 00:17:23.620
rather than put into a framework.
234
00:17:24.080 --> 00:17:31.815
So if you don't use something since Masonite is so extendable, all you have to do is remove the import of the provider and you don't have it in your package in your project.
235
00:17:32.434 --> 00:17:47.515
So I'd much rather take things out than sort of take maybe an hour to implement things, and and I'd rather have it there and then be able to add more to it than for it to not be there and you have to implement it in the first place. As for the documentation, I have this
236
00:17:48.155 --> 00:17:51.935
concept early on that there's a developer on YouTube named
237
00:17:53.035 --> 00:17:55.010
Matthias Petersen, I think it is,
238
00:17:55.890 --> 00:17:58.950
and he's the fun fun function guy he just took over
239
00:17:59.250 --> 00:18:04.630
dev tips, I think, and he has this concept of no commits without tests.
240
00:18:05.575 --> 00:18:08.475
So if you're trying to implement tests in your project and your team,
241
00:18:08.855 --> 00:18:10.555
the best way to do that is
242
00:18:10.855 --> 00:18:16.269
to say don't commit this code until you have a test for it. So what my ideology is
243
00:18:17.289 --> 00:18:19.149
is that you no pull requests
244
00:18:19.529 --> 00:18:20.429
without documentation.
245
00:18:21.745 --> 00:18:26.645
So I try to make it extremely extensible. So I have, like, a basically a staging branch
246
00:18:27.105 --> 00:18:34.640
where I list all the features as, like, what I call a running change log. And right next to each feature, I have a little checkbox that says documentation.
247
00:18:35.500 --> 00:18:40.960
And once I document something, I'll check it, and once everything has checks, then I'll merge it in. So that makes things
248
00:18:41.765 --> 00:18:44.985
super easy and everything is there. Like, every single part of the framework,
249
00:18:45.925 --> 00:18:48.105
should be documented just by that very
250
00:18:48.410 --> 00:18:56.830
nature. And I also noticed that Masonite only supports Python 3. So I'm curious if there are any particular features
251
00:18:57.394 --> 00:19:18.415
of the 3 dot x releases that you're leveraging in Masonite that you found particularly useful as you were developing and evolving it. So Mason originally started out trying to support as many things as possible, and I realized that it was actually really hard to do to do that and because if I tried to support 2.7
252
00:19:19.515 --> 00:19:23.019
and 3.3 plus, let's say, once 4 comes
253
00:19:23.320 --> 00:19:29.100
out, then I'm in, like, a predicament. Like, the peep the projects that started out, you know, a decade ago
254
00:19:29.534 --> 00:19:34.115
are facing those problems today because now you have 3.7 coming out, you have
255
00:19:34.495 --> 00:19:38.920
all these new Python versions coming out. Mostly most of them are pretty
256
00:19:39.220 --> 00:19:41.400
backwards compatible, but trying to support,
257
00:19:42.420 --> 00:19:50.465
2 completely different major versions was going to be too much. I figured if anybody's going to use this project today, might as well start out with the best technology.
258
00:19:51.405 --> 00:19:53.740
So I started out with 3.3 plus
259
00:19:54.140 --> 00:19:57.360
just because the packages I was using those were supported.
260
00:19:57.740 --> 00:20:00.480
Those are the minimum supported versions. So as I'm adding
261
00:20:00.940 --> 00:20:02.480
packages, I have to ensure
262
00:20:03.035 --> 00:20:09.775
that it also supports the minimum of Python versions I'm doing. So it started out with 3.3 and then I added, I think, a cryptography
263
00:20:10.235 --> 00:20:12.335
package, which only supported 3.4.
264
00:20:13.100 --> 00:20:16.080
So the sort of ideology we're coming from is
265
00:20:16.460 --> 00:20:28.275
support at least 4 packages in a row. So when 3.8 comes out, we're going to drop support for 3.4. Not saying that the code will break on 3.4, but we're not gonna intentionally we're gonna remove it from the Travis tests essentially
266
00:20:28.655 --> 00:20:30.275
and just do 5678.
267
00:20:30.980 --> 00:20:31.960
So there's nothing
268
00:20:32.420 --> 00:20:34.360
as for what it's using in 3,
269
00:20:34.980 --> 00:20:36.360
it's just using the normal
270
00:20:37.059 --> 00:20:38.040
standard packages
271
00:20:39.005 --> 00:20:41.184
in 3. I mean nothing crazy that
272
00:20:41.644 --> 00:20:47.170
might break in 2. I mean the major difference between 23 is really renaming of various built in packages and
273
00:20:47.570 --> 00:20:51.590
and package support external package support. What it is using
274
00:20:52.210 --> 00:20:53.410
what it is using is,
275
00:20:54.290 --> 00:20:54.790
annotations
276
00:20:55.685 --> 00:20:57.865
that's actually a huge, huge part
277
00:20:58.325 --> 00:21:01.145
of Masonite is not a huge part, but it has
278
00:21:01.525 --> 00:21:11.955
so basically what you for automatic dependency injection going back a little bit you can put so say you have your method class, right, which is starts with self and then you have comma,
279
00:21:12.335 --> 00:21:21.200
and then whatever you put there needs to correspond to a key of the dictionary in the container. So if you have request, it looks for the request key
280
00:21:21.580 --> 00:21:35.715
in the dictionary in the container and injects that class that's attached to it. For so basically right? So let's look up by key. To look up by value, what if I don't know the key? I could look up by the class itself. So if I want to get a an upload driver,
281
00:21:36.320 --> 00:21:42.580
I can use an annotation where I have request colon and then normally you have like a string annotation.
282
00:21:43.120 --> 00:21:58.710
What you could do is you could just put a class there so it'll look up that class. So that's actually a huge part of Python 3. I think that was introduced in annotations, I think, was introduced in 3 0. So we're using that and that's huge. But what's also huge for dependency injection is that it seems a little bit weird
283
00:21:59.170 --> 00:22:00.710
to me at least to
284
00:22:01.034 --> 00:22:07.534
to fetch by class or by key. So what's even more powerful is what is she what if you fetch by, like, a base class?
285
00:22:08.770 --> 00:22:11.270
So all upload drivers inherit from
286
00:22:11.809 --> 00:22:14.710
a upload contract, which is just a class really,
287
00:22:15.169 --> 00:22:17.190
like an interface almost if you're coming from
288
00:22:18.135 --> 00:22:18.635
PHP.
289
00:22:19.975 --> 00:22:21.915
I don't know if Ruby has it or not, but
290
00:22:22.615 --> 00:22:24.635
an interface. So you're inheriting
291
00:22:25.495 --> 00:22:27.275
from that class. So if we
292
00:22:27.659 --> 00:22:28.640
basically annotate
293
00:22:29.179 --> 00:22:33.679
a upload drive or upload contract, it'll give me the upload driver.
294
00:22:33.980 --> 00:22:34.480
So
295
00:22:34.895 --> 00:22:43.555
I could basically take out all drivers from the framework, replace it with any class I want, and as long as I'm uploading from or inheriting from the upload contract,
296
00:22:43.880 --> 00:22:48.300
it'll give me a class that can upload. So we're using, we're leveraging,
297
00:22:49.080 --> 00:22:55.245
Python annotations a lot, but you don't have to use it. It's just a feature. And for somebody who is
298
00:22:55.705 --> 00:22:56.925
starting a new project,
299
00:22:57.465 --> 00:22:59.005
if they don't necessarily
300
00:22:59.465 --> 00:23:00.445
have Python
301
00:23:00.825 --> 00:23:01.885
as their
302
00:23:02.265 --> 00:23:10.455
sort of decided language implementation if they're just shopping around for a given framework? What are some of the features of Masonite that might make it,
303
00:23:11.095 --> 00:23:14.715
stand out and help drive somebody to use Masonite as a framework
304
00:23:15.015 --> 00:23:19.515
and Python as a language versus some of the other available options that they might be considering?
305
00:23:20.100 --> 00:23:22.600
So the major difference between
306
00:23:22.900 --> 00:23:23.720
a Django
307
00:23:24.420 --> 00:23:28.520
selection and a Masonite selection is that they're really coming from
308
00:23:28.914 --> 00:23:33.095
2 completely different worlds, which is weird to say because they're they're basically implementing
309
00:23:33.715 --> 00:23:37.654
the same thing, right? They're basically django is to build, you know, software applications
310
00:23:38.034 --> 00:23:41.470
on the web and Masonite is to build software applications on the web
311
00:23:41.770 --> 00:23:44.590
and but they're coming from 2 different paradigms where
312
00:23:45.210 --> 00:23:46.429
you should really pick
313
00:23:46.809 --> 00:23:58.015
the 1 that makes sense for you and not necessarily the 1 that's that's better or it just if you're building an application, it needs to make sense what the heck you're doing. If you've ever used Django and you're
314
00:23:58.539 --> 00:24:07.440
sort of like it seems like a little too magical for you, it's your you ever ask yourself why are we doing it this way? This seems weird to me. Then you should definitely try out Masonite.
315
00:24:07.865 --> 00:24:10.045
If you're coming from a different language, like,
316
00:24:10.505 --> 00:24:12.445
I get a lot of developers from
317
00:24:13.385 --> 00:24:14.925
Ruby and Laravel,
318
00:24:15.670 --> 00:24:17.210
And if you're coming from those languages,
319
00:24:17.670 --> 00:24:23.130
everything sort of just makes sense to you because it uses a similar architecture. The ORM,
320
00:24:23.875 --> 00:24:25.495
every other Python web framework,
321
00:24:26.355 --> 00:24:28.135
uses a data mapper ORM,
322
00:24:29.075 --> 00:24:30.455
which basically means
323
00:24:31.370 --> 00:24:32.429
you're going to specify
324
00:24:33.130 --> 00:24:34.990
your attributes or your columns
325
00:24:35.690 --> 00:24:43.055
on your table as attributes on your class. So you're basically the way I look at it is you're mapping a data mapper ORM is mapping from
326
00:24:43.435 --> 00:24:47.215
the model to the table, so you make the model look like the table essentially.
327
00:24:47.915 --> 00:24:50.420
And with Mason, I kind of went on a limb here
328
00:24:51.620 --> 00:24:59.080
and I'm using a active record style ORM, which in active record style makes the the method or the sorry, the model
329
00:24:59.775 --> 00:25:01.715
sort of replicate the class of the table.
330
00:25:02.255 --> 00:25:04.115
So because of that, we can separate
331
00:25:05.295 --> 00:25:05.795
the
332
00:25:06.255 --> 00:25:08.895
model from the migrations completely, so
333
00:25:09.490 --> 00:25:13.430
which which we do. So you could basically remove the ORM if you want to
334
00:25:13.970 --> 00:25:15.910
and sort of replace it with your own ORM.
335
00:25:16.615 --> 00:25:20.155
There's no reason to do that. I think Python developers, once they get a taste of
336
00:25:20.855 --> 00:25:21.675
active record,
337
00:25:22.375 --> 00:25:28.590
they're gonna love it, and then I think they're gonna like it a lot more. As with migrations and stuff, migrations are completely separated.
338
00:25:29.530 --> 00:25:30.590
Django uses
339
00:25:30.970 --> 00:25:31.790
the MTV
340
00:25:32.570 --> 00:25:37.925
structure for MVC, their their own interpretation of it. Masonite maintains the traditional
341
00:25:39.025 --> 00:25:39.525
MVC,
342
00:25:40.305 --> 00:25:42.085
so maybe a quick
343
00:25:42.390 --> 00:25:43.770
sort of similarity would
344
00:25:44.150 --> 00:25:48.090
be Masonite has what's called controllers, right, in the c and MVC,
345
00:25:48.710 --> 00:25:49.210
and
346
00:25:49.725 --> 00:25:50.705
Django has
347
00:25:51.005 --> 00:25:52.945
function based views and class based views.
348
00:25:53.565 --> 00:25:55.665
That would sort of be the C, right, so
349
00:25:56.285 --> 00:25:56.785
there's
350
00:25:57.900 --> 00:26:03.200
for those listeners that are sort of getting into it, there's 4 if you've learned this in college there's 4,
351
00:26:03.980 --> 00:26:06.080
architectural concepts of any application.
352
00:26:06.539 --> 00:26:07.039
There's
353
00:26:07.595 --> 00:26:09.695
business logic, presentation logic,
354
00:26:10.075 --> 00:26:12.335
data accession logic, and data storage.
355
00:26:12.955 --> 00:26:13.455
So
356
00:26:14.235 --> 00:26:20.880
the developer community sort of took those data session business and presentation logic, and they sort of created this MVC structure
357
00:26:21.500 --> 00:26:22.320
and various
358
00:26:23.260 --> 00:26:27.745
libraries and frameworks and and you got Vue and Node and all that. They sort of
359
00:26:28.685 --> 00:26:33.985
took it and Swift. They sort of took it and they they kind of ran with it. So now you have things like MVVM,
360
00:26:35.030 --> 00:26:35.530
MVT,
361
00:26:36.870 --> 00:26:37.370
MVVC,
362
00:26:38.150 --> 00:26:41.450
like all this kind of crazy stuff. So it's really just a different
363
00:26:41.990 --> 00:26:44.845
paradigm. And to give a little bit of a better example
364
00:26:45.385 --> 00:26:49.720
for those of you I'm sure a lot of listeners are familiar with Django, so I keep on going back to Django.
365
00:26:50.120 --> 00:26:51.500
So with Django, you
366
00:26:51.960 --> 00:26:54.140
have function based views and class based views.
367
00:26:54.520 --> 00:26:55.900
So a class based view
368
00:26:56.840 --> 00:26:58.705
is basically like an abstraction
369
00:26:59.485 --> 00:27:13.630
of a function based view. So a function based view is just a function. It takes a request to return the response and a class based view has does sort of the same thing, but it has like a lot of framework hooks you could tie into it and inherit from and different template views and all that stuff and mix ins.
370
00:27:14.195 --> 00:27:19.015
So with Masonite, it's actually a lot simpler than that. It's really just a class.
371
00:27:19.315 --> 00:27:24.770
That's it. Just a controller. A controller is just a class, and inside this class there are these methods
372
00:27:25.310 --> 00:27:30.530
and these methods return various views. So a class based view might work on a single template
373
00:27:31.525 --> 00:27:33.065
where a controller
374
00:27:33.845 --> 00:27:45.679
itself works on an entire feature. So you might have like a setting controller, which works on all your your settings and your various methods and a class based view might be like get and post, but in
375
00:27:46.755 --> 00:27:48.934
Masonite your methods will be
376
00:27:49.395 --> 00:27:50.455
show store
377
00:27:51.235 --> 00:27:51.735
delete.
378
00:27:52.115 --> 00:27:53.975
Right? On these settings it might be
379
00:27:54.620 --> 00:27:56.640
show profile, it might be show
380
00:27:57.180 --> 00:28:01.840
show leagues if you're creating like a some sort of like a sports based thing,
381
00:28:02.534 --> 00:28:04.794
show teens, and you're sort of encapsulating
382
00:28:05.654 --> 00:28:10.635
all your feature logic into this 1 class and you could abstract out as many classes as you want.
383
00:28:11.049 --> 00:28:12.830
Django sort of does a
384
00:28:13.530 --> 00:28:19.150
higher level where they have like apps you can abstract out entire apps which have their own models and stuff like that,
385
00:28:19.485 --> 00:28:23.425
And if that, like, makes sense to you, I mean, more power to you, it's
386
00:28:24.005 --> 00:28:24.505
it's
387
00:28:25.085 --> 00:28:28.785
it's weird to me and a lot of other developers, so a lot of people that use Masonite,
388
00:28:29.360 --> 00:28:32.559
everything just clicks to them. So if you're coming from
389
00:28:34.080 --> 00:28:35.380
if you want something different,
390
00:28:35.840 --> 00:28:37.620
then you should definitely try out Masonite,
391
00:28:37.985 --> 00:28:40.325
essentially. Yeah. When I was looking through
392
00:28:40.785 --> 00:28:46.885
how the applications were architected, it reminded me a lot of Rails because that's what I have experience with.
393
00:28:47.265 --> 00:28:53.750
I haven't used Laravel to be able to have that comparison in mind, but the whole idea of
394
00:28:54.210 --> 00:28:55.270
the conventions
395
00:28:56.325 --> 00:28:56.825
being,
396
00:28:57.125 --> 00:29:02.985
very strong for being able to structure your application, rather than having to define a lot of configuration
397
00:29:03.285 --> 00:29:04.505
to tie things together,
398
00:29:05.130 --> 00:29:09.470
and having the easy scaffolding commands for being able to create different
399
00:29:10.010 --> 00:29:11.390
portions of your application,
400
00:29:12.010 --> 00:29:17.835
to help get things moving quickly. And then also the active record style ORM to make it very,
401
00:29:18.215 --> 00:29:24.870
sort of, literate style in terms of when you're interacting with your model objects and the traditional MVC structure. So,
402
00:29:25.570 --> 00:29:35.465
anybody who's coming from that type of application environment and wants to experience it in Python, it definitely seems like it would feel very natural and familiar.
403
00:29:35.925 --> 00:29:36.425
And
404
00:29:36.805 --> 00:29:42.230
for somebody who has decided that they want to use Masonite for a new project,
405
00:29:42.610 --> 00:29:45.990
what does their workflow look like for getting it started
406
00:29:46.530 --> 00:29:47.510
and iterating
407
00:29:47.810 --> 00:29:48.710
on the development?
408
00:29:49.330 --> 00:29:55.145
And how does that differ if they're coming into an existing project and want to add new features to Masonite?
409
00:29:55.685 --> 00:29:58.985
So from the beginning so the installation is
410
00:29:59.649 --> 00:30:03.429
fairly straightforward. I mean, you're the the workflow is a little strange, so,
411
00:30:04.450 --> 00:30:10.645
not strange, but it's, it's different than probably what a lot of Python developers using Django or Flask are familiar with.
412
00:30:11.025 --> 00:30:14.645
So you're basically installing a command line tool to your computer,
413
00:30:15.350 --> 00:30:19.769
which has like 3 commands, which has like a new command, an install command,
414
00:30:20.549 --> 00:30:22.809
and a package command, I think. So
415
00:30:23.554 --> 00:30:26.294
once you have this tool it's going to be your best friend.
416
00:30:26.995 --> 00:30:29.414
So I'm sure those of you that are coming from
417
00:30:29.955 --> 00:30:31.495
Laravel or Ruby or
418
00:30:31.955 --> 00:30:35.840
Rails is probably a little bit different because the command line I believe is attached
419
00:30:36.299 --> 00:30:37.520
to your actual application.
420
00:30:38.539 --> 00:30:39.039
So
421
00:30:39.340 --> 00:30:45.265
like in Laravel has like an artisan command, right, and that's in like an artisan dot PHP file or or something like that
422
00:30:45.565 --> 00:30:46.785
in the base of your directory.
423
00:30:47.245 --> 00:30:47.745
So
424
00:30:48.240 --> 00:30:50.419
can you can kind of execute it using a PHP
425
00:30:50.960 --> 00:30:52.340
command, so PHP artisan.
426
00:30:53.519 --> 00:30:54.260
With craft,
427
00:30:54.880 --> 00:30:59.785
you're installing the command line to your computer, so you could do craft new in any directory,
428
00:31:00.405 --> 00:31:01.145
right? And
429
00:31:01.765 --> 00:31:04.265
you're installing it there. I think I
430
00:31:04.760 --> 00:31:07.660
think Laravel actually even has their own command line application,
431
00:31:08.280 --> 00:31:17.075
but you're always going to be using it. So you're never going to do like so if you're using like a Laravel new and then you go into your application, you do like a PHP artisan,
432
00:31:17.615 --> 00:31:22.434
you're always going to be using craft with Masonite. So you do a craft new, and then when you're inside an application
433
00:31:23.600 --> 00:31:27.540
directory it's actually going to pull in commands from that application itself,
434
00:31:30.720 --> 00:31:33.285
so so it might be different depending on what
435
00:31:34.465 --> 00:31:39.925
application you're using and the commands might be different depending on if the developer who built the package
436
00:31:40.419 --> 00:31:49.240
added those commands to begin with. I mean, you have all your basic applications, right? All right, you have your all your basic commands and then so that's a little bit different.
437
00:31:49.765 --> 00:31:52.025
As for an existing project,
438
00:31:52.485 --> 00:31:57.385
I've actually a developer in the community built a what he called Masonite forums,
439
00:31:57.700 --> 00:31:59.559
and it was basically a Quora
440
00:32:00.020 --> 00:32:06.440
type q and a and so I was like, you know what? I'm gonna build some some features onto this
441
00:32:07.115 --> 00:32:09.295
application that he built because it's super cool.
442
00:32:09.835 --> 00:32:12.415
So I, you know, git cloned everything and
443
00:32:12.795 --> 00:32:13.455
and I
444
00:32:14.210 --> 00:32:20.630
did like a it comes with a craft install command, so I craft installed, which installs all the dependencies and generates a secret key, and
445
00:32:21.225 --> 00:32:23.805
I got his project up and running in
446
00:32:24.185 --> 00:32:29.005
maybe a minute to 2 minutes. So when you're coming from an existing application, it's actually
447
00:32:29.340 --> 00:32:32.640
super it's the exact same thing, right? You just have your application there
448
00:32:32.940 --> 00:32:34.960
and you could switch between them easily.
449
00:32:35.500 --> 00:32:40.174
I always do it inside a virtual environment, which makes things a little more simple. So as for the
450
00:32:40.955 --> 00:32:41.855
the actual workflow,
451
00:32:42.715 --> 00:32:46.975
normally if you're coming from, again, from Django, you might create
452
00:32:47.679 --> 00:32:56.419
a class that you inherit from a class based view. You might create an actual function. You might go in and create a route, and then once you do that, you'll create a template.
453
00:32:56.845 --> 00:32:57.345
So
454
00:32:57.805 --> 00:33:00.145
for the workflow when starting a project and
455
00:33:00.685 --> 00:33:01.185
for
456
00:33:01.885 --> 00:33:03.985
sort of developing the project, you're
457
00:33:04.285 --> 00:33:05.745
using this craft command
458
00:33:06.270 --> 00:33:07.970
to actually scaffold your application.
459
00:33:08.430 --> 00:33:15.715
So you're probably really annoyed at, okay, now I have to go create a class based view. So let's create a class, name this, let's inherit, let's import this.
460
00:33:16.034 --> 00:33:18.934
So with Masonite, you're just doing crafts controller
461
00:33:19.235 --> 00:33:22.534
and then you give your controller name. So crafts controller dashboard controller
462
00:33:23.040 --> 00:33:28.740
and it'll create a class for you and put it in the correct folder and you can move it wherever you want after if you need to.
463
00:33:29.120 --> 00:33:29.620
But,
464
00:33:30.755 --> 00:33:32.055
so it sort of
465
00:33:32.355 --> 00:33:32.855
makes
466
00:33:33.235 --> 00:33:34.375
developing applications
467
00:33:34.835 --> 00:33:35.335
quick
468
00:33:35.715 --> 00:33:44.720
and things start happening quickly, and and that's actually the feedback I got a lot was, wow. This this makes things happen fast. That's sort of the feedback I get.
469
00:33:45.500 --> 00:33:55.005
So if you need to create a so in any route, right, you create a route, you create a controller, you create a view or a template if you're coming from Django. You create a view, and
470
00:33:56.070 --> 00:33:57.770
you kind of sort of connect those 3.
471
00:33:58.390 --> 00:34:00.090
So with craft you can create a template
472
00:34:00.630 --> 00:34:02.490
super easy create a view
473
00:34:02.870 --> 00:34:03.610
same thing.
474
00:34:03.995 --> 00:34:08.415
You can create your controller, which adds a little method for you that you could start developing.
475
00:34:08.955 --> 00:34:10.335
And as for your route,
476
00:34:10.714 --> 00:34:15.070
all you have to do is really just create that route or connect that route to the controller.
477
00:34:15.370 --> 00:34:17.550
That's it. That's all you got to do. So it makes
478
00:34:17.850 --> 00:34:24.005
things happen quickly so you don't have to be like, I don't know, where was I again now that I have everything set up? Oh, right. I wanted to create a dashboard.
479
00:34:24.465 --> 00:34:27.205
So it's not, so it's really, really easy
480
00:34:27.744 --> 00:34:30.085
to get started. And also Masonite has
481
00:34:31.170 --> 00:34:34.710
which this is really subjective. I know a lot of Python developers
482
00:34:35.250 --> 00:34:40.230
might not like it, but they don't have to use it, so they can remove it from the application if they want to. But
483
00:34:40.535 --> 00:34:44.474
there is a service provider that ships with Masonite called a helpers provider.
484
00:34:44.934 --> 00:34:45.835
And what these helpers
485
00:34:46.535 --> 00:34:47.674
actually connects
486
00:34:47.974 --> 00:34:48.474
with
487
00:34:48.855 --> 00:34:50.280
the Python built ins
488
00:34:50.840 --> 00:34:52.780
and actually adds built ins to your application.
489
00:34:53.320 --> 00:34:53.820
So
490
00:34:54.120 --> 00:34:57.260
just like you do a print statement, right, print parentheses,
491
00:34:58.155 --> 00:34:59.775
you would do a view parentheses.
492
00:35:00.234 --> 00:35:04.415
You don't have to import. It's sort of coming from a little bit of a magical place,
493
00:35:04.954 --> 00:35:10.840
but it's super fast to like scaffold something. So if you just wanna just do view and then you return a view and just make sure it works,
494
00:35:11.300 --> 00:35:17.375
then you're good. And you create all the logic around it and it works, and then you can sort of, you know, a minute after, you can go back and
495
00:35:17.675 --> 00:35:18.255
and restructure
496
00:35:18.955 --> 00:35:20.415
and rescaffold it or
497
00:35:20.795 --> 00:35:23.615
refactor it and all that stuff. So it makes things
498
00:35:24.190 --> 00:35:28.210
happen really, really quick, and that's a lot of the feedback I got. And
499
00:35:28.750 --> 00:35:33.010
as you continue to work on the Masonite framework,
500
00:35:33.535 --> 00:35:52.895
what are some of the plans that you have for it in going into the future, both for the core project itself and for any additional plug ins that you plan to incorporate into it or provide sort of, in addition to it. So the future of the framework, like I said, I I see it at the top right next to Django
501
00:35:53.275 --> 00:35:59.855
or before Django, actually. Right? Django would be after. And Flask, I don't care where Flask is since it's sort of a microframework. So to compare
502
00:36:00.569 --> 00:36:03.309
Masonite to a microframework is a little unfair,
503
00:36:03.849 --> 00:36:09.150
but, they're both batteries included framework. So once I see it there and I'm working on it every day,
504
00:36:10.625 --> 00:36:12.964
I add issues to the GitHub
505
00:36:13.505 --> 00:36:21.240
repository, I create articles for it constantly, right? I'm huge into the documentation part, and the future for it is
506
00:36:21.780 --> 00:36:25.560
creating various applications with it. So I'm only creating packages
507
00:36:26.505 --> 00:36:50.505
when I need them. So, like, the notifications package, like, I needed that in my application, and it's super, super simple. It's like to send an email or a text is, like, 5 lines of code, and it's only 1 line of code in your controller. So, especially with the craft command, I can, you know, craft that notification, and it'll create the class for me and I just add my logic and then that's it, and then I resolve it from the container.
508
00:36:51.205 --> 00:36:52.025
So for
509
00:36:53.210 --> 00:37:01.390
packages like I built an API package, but I am not a big fan of it just because I haven't actually used it yet so it's never ever good to create a package when
510
00:37:01.994 --> 00:37:11.849
you're not personally invested in or you're not personally using it. But when I put it on Reddit a while ago, like, that was huge. Like, everybody needed an API package, but what I was working on at the time
511
00:37:12.549 --> 00:37:13.609
didn't need 1.
512
00:37:14.069 --> 00:37:26.005
So so if anybody is huge into APIs, there's a couple people in the community that are and they're they're going to, you know, work on developing it. And once I start building a package that requires an API, it'll be
513
00:37:26.625 --> 00:37:27.845
much better. So
514
00:37:28.710 --> 00:37:30.970
So I'm very so anytime I come across
515
00:37:31.270 --> 00:37:34.570
my code where I'm like, man this is super bulky, this is
516
00:37:34.950 --> 00:37:36.570
not good, this is ugly,
517
00:37:36.950 --> 00:37:37.450
I
518
00:37:37.875 --> 00:37:41.255
try to abstract it into a package. That's all it is. So maybe
519
00:37:41.555 --> 00:37:51.190
it was just like the notifications. Like the email class, I'll admit, is a little bookie, so I abstracted that email class into a notification class, sort of transformed it, and now it's super awesome.
520
00:37:51.569 --> 00:37:55.030
So anybody coming in that sees like man this is weird,
521
00:37:55.855 --> 00:37:57.395
The API is a little off
522
00:37:57.775 --> 00:37:59.075
definitely needs to
523
00:37:59.615 --> 00:38:01.955
let me know and we can definitely work on it, like,
524
00:38:02.420 --> 00:38:09.160
for hours, I will just stare at a single line of code and work on refactoring out and making it smaller and more intuitive.
525
00:38:09.695 --> 00:38:13.075
And I have this since we're I'm trying to picture
526
00:38:13.695 --> 00:38:20.990
Masonite as, like, an apple, I'm I'm huge into I've always actually been huge into Steve Jobs and how he does things. In 1 of his talks, he says
527
00:38:21.690 --> 00:38:24.110
that you can't take a technology
528
00:38:24.650 --> 00:38:26.030
and give it to a customer,
529
00:38:26.645 --> 00:38:30.025
right, and make them use it. You have to start at the customer
530
00:38:30.485 --> 00:38:32.585
and work your way backwards to the technology.
531
00:38:32.965 --> 00:38:34.345
So all features
532
00:38:35.045 --> 00:38:49.755
that I write start inside the controller. So I create exactly what I want it to look like, and then I work backwards to the implementation because, like I said before, nobody cares what features you have in your framework. The only thing that people care about is how they're interacting with your user experience
533
00:38:50.615 --> 00:38:54.990
and your UI, and that comes with anything. I mean, Trello is
534
00:38:55.290 --> 00:39:08.869
is I mean, there's a 1, 000 things that do Trello, but Trello is so simple. Like, it's just it's the user experience of you interacting with it. Things that should be clickable are clickable, and and it sort of also works with packages. Like, sort of things that should work
535
00:39:09.330 --> 00:39:15.935
should work, and you have to kind of work your way backwards to that. So so that's been my my lead thing, and it's sort of always weird to
536
00:39:16.475 --> 00:39:18.655
like, do I spend my time working on
537
00:39:19.275 --> 00:39:20.815
a service for me
538
00:39:21.250 --> 00:39:24.630
or do I work or do I spend my time working on Masonite itself?
539
00:39:25.170 --> 00:39:32.285
So it's all it's sort of like a sort of weird battle where, man, I could be building this, but I could also be building more features onto core.
540
00:39:33.545 --> 00:39:34.605
And as for,
541
00:39:35.065 --> 00:39:39.890
I mean, as for any ideas, like, I'm I'm completely up I'm completely open to what Masonite can be,
542
00:39:40.270 --> 00:39:46.265
and I love the feedback that I'm getting from the community so far and the Slack channel that we run. And, yeah,
543
00:39:46.825 --> 00:39:48.505
that's sort of the future of it. It should be,
544
00:39:49.704 --> 00:39:52.444
in December. We're gonna really every 6 months, we do a release.
545
00:39:52.825 --> 00:39:53.565
It uses
546
00:39:54.105 --> 00:39:54.845
instead of.
547
00:39:55.160 --> 00:39:58.540
So romver right now it's at 2.0, December will be 2.1,
548
00:39:59.320 --> 00:40:04.060
and then June well, I'm looking to shoot for a 2.2 release that's a LTS.
549
00:40:05.224 --> 00:40:06.525
We're gonna try that out,
550
00:40:06.905 --> 00:40:16.480
so hopefully it'll sort of force a lot of businesses to sort of my or, sort of get into Masonite. Because once developers start using it, they they love it. So I just need to
551
00:40:17.100 --> 00:40:23.615
get them to use it, and then that's it. I I have them hooked. Alright. And are there any other aspects of Masonite
552
00:40:24.235 --> 00:40:30.610
or any of the related work that you're doing with it that we didn't discuss, which we should cover before we close out the show?
553
00:40:31.630 --> 00:40:45.405
No. I think I think we covered everything. So with that, I'll have you add your preferred contact information to the show notes for anybody who wants to follow-up with you or get involved with Masonite. And so with that, I'll move us into the picks. And this week, I'm going to choose the,
554
00:40:46.250 --> 00:40:48.109
YETI brand coffee mugs
555
00:40:48.410 --> 00:40:48.910
because
556
00:40:49.210 --> 00:40:49.950
I was
557
00:40:50.329 --> 00:40:58.405
searching for 1 for a while and found those, and it does a phenomenal job of keeping things nice and hot for quite a long time. So,
558
00:40:59.345 --> 00:41:01.825
been taking advantage of that daily, and,
559
00:41:02.320 --> 00:41:02.980
if anybody's
560
00:41:03.360 --> 00:41:11.185
on the lookout for a quality mug, it's definitely worth checking those out. So with that, I'll pass it to you, Jo. Do you have any picks this week? So there's
561
00:41:11.565 --> 00:41:14.625
2 picks that I'd like, and the first 1 is,
562
00:41:15.485 --> 00:41:15.985
gitbook.io.
563
00:41:16.925 --> 00:41:21.150
So what gitbook is is a it's what Masonite uses to to host documentation,
564
00:41:21.930 --> 00:41:29.150
and it's actually a really, really awesome service. It makes documentation simple. They actually just reversed the, released the version 2,
565
00:41:29.795 --> 00:41:30.295
which
566
00:41:30.595 --> 00:41:32.454
is buggy, I'll admit.
567
00:41:32.755 --> 00:41:34.694
I think they prematurely released it,
568
00:41:35.395 --> 00:41:36.934
a little too soon, but
569
00:41:37.270 --> 00:41:43.770
I'm a I mean, I'm a huge fan of just releasing things. Like, I I released version 0.3 on Reddit, and it got destroyed.
570
00:41:44.150 --> 00:41:49.484
So, but it's a really awesome service. They're coming out with new features all the time and it it's like
571
00:41:50.105 --> 00:41:52.445
a a really good user experience of building documentation.
572
00:41:52.905 --> 00:41:54.365
My second pick would be
573
00:41:55.010 --> 00:41:55.510
dev.2.
574
00:41:55.890 --> 00:41:59.270
I'm sure a lot of your listeners are familiar with that but I actually recently got into that,
575
00:41:59.730 --> 00:42:00.790
like a month ago
576
00:42:01.250 --> 00:42:01.990
and dev.2
577
00:42:02.530 --> 00:42:03.030
is
578
00:42:03.714 --> 00:42:09.015
a it's like a medium and you but it's for developers, so everything is developer oriented.
579
00:42:09.395 --> 00:42:09.895
You
580
00:42:10.515 --> 00:42:11.895
write articles in markdown
581
00:42:12.240 --> 00:42:14.579
and their syntax highlighting is just phenomenal,
582
00:42:15.119 --> 00:42:16.500
and that's where I'm
583
00:42:16.960 --> 00:42:18.180
sort of putting all the
584
00:42:18.520 --> 00:42:19.020
the
585
00:42:19.359 --> 00:42:19.859
additional
586
00:42:20.160 --> 00:42:24.645
documentation for Masonite where I basically take a section of the documentation
587
00:42:25.265 --> 00:42:27.285
and I extend it out into a more
588
00:42:27.745 --> 00:42:30.005
me talking to you type of experience.
589
00:42:30.430 --> 00:42:31.810
So if you wanna check out,
590
00:42:32.110 --> 00:42:40.130
dev.2, that's that's really awesome. Those are my 2 picks. Alright. Well, thank you for taking the time to talk to me about your work on Masonite
591
00:42:40.494 --> 00:42:44.734
and for your efforts to build a viable competitor to the,
592
00:42:45.295 --> 00:42:46.515
long standing Django
593
00:42:47.134 --> 00:42:47.634
supremacy.
594
00:42:47.980 --> 00:42:52.000
So good luck with that. Yeah. And, I hope you enjoy the rest of your day. Thank you for having me.