Have you noticed that web development's kind of hard?
If you've been doing it for a long time,
this is actually easy to forget.
It probably sounds simple enough to
pick a server-side framework, Pyramid or Django,
create a new project.
Oh, do I use pcreate?
Is that cookie cutter?
Is that manage.py?
Install some client-side dependencies with NPM.
Install some server-side dependencies with pip.
Create a database.
Well, first choose a database server,
then create a database,
maybe even set up and install the server,
the process and maybe even another machine to do this.
Connect the app to the database securely.
Pick a front-end framework.
Is that bootstrap or foundation?
Integrate the front-end framework into it.
Pick a theme.
Now, finally, you get to write some code.
Oh, now it's time to deploy.
Wait, that doesn't sound that easy.
Actually, even to me.
What if the web were as easy as old-school VV6?
You just open a UI,
you drag and drop some widgets,
you double-click on the things like buttons for events,
but with Python code, of course.
With Anvil, you'll see that it really is
that quick and easy to get started.
Meet Meredith Loof, who's here to tell us about Anvil.
This is Talk Python to Me,
episode 138, recorded November 6, 2017.
Welcome to Talk Python to Me,
a weekly podcast on Python,
the language, the libraries, the ecosystem,
and the personalities.
This is your host, Michael Kennedy.
Follow me on Twitter, where I'm @mkennedy.
Keep up with the show and listen to past episodes
at talkpython.fm,
and follow the show on Twitter via at Talk Python.
This episode is brought to you by Datadog
and GoCD from ThoughtWorks.
Please check out what they're offering during their segments.
It really helps support the show.
Meredith, welcome to Talk Python.
Thank you very much.
Thank you very much for having me.
Yeah, you had some pretty interesting stuff going on
at PyCon UK,
and yeah, I'm super happy to bring it to a wider audience.
Cool, thanks.
Yeah, it was really great.
That's actually been our first time sponsoring that conference,
and it was really quite fun being deluged in people.
Yeah, a whole bunch of stuff we weren't expecting.
We went through a lot of throat sweeps
in the evening after the conference,
but it was really great to see the reaction out there,
and I'm really pleased to be talking to you
and your listeners, too.
Yeah, that's awesome.
So I'm super excited to talk about your project called Anvil,
which is kind of trying to democratize the web again
in like a really interesting and powerful way
and using Python to do it,
but before we get to that, let's just hear your story.
How did you get into programming in Python?
So programming, I started, I was very privileged.
I started around the age of seven.
I was introduced to QBasic,
and for me, it was just this piece of magic
because here I was sitting at this blue screen,
and I could type something in,
and it was nothing the seven-year-old's brain
couldn't comprehend,
and here was this program.
It was drawing pictures on the screen.
It was interacting with me,
and I could make it do what I wanted,
and this was magic made real sitting in front of me,
and it was several years before that
that I worked out that you could actually make a career
doing this amazing thing that I discovered
was the best hobby in the world.
Actually, literally the reason we started Anvil
was that that experience isn't there
in much of the web these days,
and as far as I'm concerned,
that's borderline criminal negligence
from our whole profession
because that kind of magic that can capture a kid's eye
is what we should be delivering.
You're right.
It absolutely is missing,
and so I think you guys are going to bring some of that back.
Yeah, that's awesome.
So that's how you got into programming.
How about Python?
So Python itself actually,
I mean, I've like dabbled, dipped into it bits and pieces,
but honestly, like we started on Anvil first.
It was very much, you know,
we want to bring back this sort of instant access magic.
We want to bring back what you had
with like Visual Basic 6, these tools in the 1990s,
and we were like, okay, but it's got to be modern.
It's got to be an easy-to-use, accessible language.
It's got to, you know, it's got to feel
that kind of easy workability in your hands,
and we like looked at it,
and Python was so the obvious candidate.
And so like I was, you know,
I spoke Python as like, you know,
fourth language up till then,
and then I went, right, okay,
this is clearly the right thing,
and jumped into it, and I've been loving it.
Yeah, that's awesome.
And so you guys sponsored PyCon UK.
It sounds like Anvil is something
that you're focused on pretty much day-to-day.
Is that right?
Absolutely.
So we originally started this a couple of years back now.
It was like an evening and weekends project.
It was, you know, we were on our way to a wedding,
sitting there in the airport,
Departures Lounge going, you know,
why don't we have Visual Basic 6 for the web anymore?
And that kind of turned into, you know,
some evenings working on it,
which eventually turned into like taking one day off a week
to work on it.
And then last summer, we just, honestly,
we just stuck it on Reddit,
and we saw the reaction, went,
oh, okay, this is really a thing now.
Okay, we could afford to go full-time on it.
And so we worked our way up to it,
but now, yeah, this is our thing.
Yeah, that's a really great story,
and I think a lot of people feel like the way
you get to somewhere where you have, like,
your own business or your own sort of thing
that you can go do that's not part of your job,
it's kind of like diving off a high diving board
with your eyes closed,
whereas I think in practice,
a lot of these things, like you described,
start as like, let's test the waters,
let's do some proof of concept,
let's slowly build up,
and then once you see that it's like gaining traction,
like, all right, if I could go
and do eight or nine hours a day instead of one,
think what would happen.
Yeah, absolutely.
It's very much sort of wading in from the shoreline
rather than jumping up a diving board.
That's great.
All right, so we're definitely going to get into
the details of what Anvil is,
but maybe just give us a really,
really high-level picture of what you built,
and then let's talk about your thought
that the web is not as accessible as it should be.
Well, what we built was a tool
for building full-stack web apps
with nothing but Python.
So you can design what your page is going to look like
in a kind of drag-and-drop visual editor,
but everything you place,
every button, every checkbox,
every piece of text is actually a Python object.
And so even your client-side code
that's running in the browser
is actually just Python.
We compile this JavaScript.
We run it there.
Your server-side code is just Python.
We even have a built-in database
that you can access with pure Python,
no SQL,
although obviously if you want to,
you know,
go and pull in a MySQL database,
you know,
we support everything that Python supports.
But the idea is really
that you should be able to build
a fully functional web application
and publish it
knowing nothing but Python.
I think you could build a fully functional web application
with hardly knowing any programming.
I mean,
this could easily be built like a really functional web application
for your first computer science or programming course
in high school or something, right?
We have people who've done that, right?
You know,
we've had schools
who've just taught their computing curriculum
with Anvil
precisely because of that
because, you know,
for the kids,
it comes back to what I was saying
at the beginning.
You know,
you want that instant feedback.
You want to have this feeling
that I just learned this abstract concept
of the if statement
and now here it is
in buttons of colors
and images in front of me
right away.
Yeah.
So let me see if I can just describe
the experience of using this
which, granted,
my experience is like
I've only built like one little test app
and played with it for an hour or something
but still,
the idea is you go to your website,
you create an account,
you launch a cloud browser-based IDE
which is really focused on
the sort of UI design layer of,
UI and data layer of your app.
You have a design view and a code view.
In the design view,
you have a bunch of components and widgets
that you can drag over,
images, links, buttons,
repeaters, columns,
all sorts of stuff.
You can give them names
and then you access them in Python
in the code side of your page, right?
Yeah, that's exactly right.
But look,
it's not just on the code side of a page
because you can also then
pull up a server module
and then you're writing,
again,
it's just a Python module
but now it's running on our servers
and you can just make function calls
as just a decorator for,
this is something that
you should be able to call
from your client code
and so you can make Python calls
straight from the Python code
that runs when,
say,
when you click a button
in that code view
through to server module.
Right.
And I think one of the
sort of making this
more accessible aspects of it
is like,
I've been doing a lot of JavaScript lately
and JavaScript is like
an intense place these days, man.
And it didn't used to be.
even in the early days,
though,
like with things like Ajax and stuff,
you still have this sort of callback
indirect seesaw type of programming.
So like with what you just described,
like you write a function on the server
and then you write some literally Python code
that runs in the browser
and then you just say,
call that function on the server
by saying something like
anvil.server.name of thing you wrote,
pass the parameters,
and it's even a synchronous call.
Like it blocks and then continues, right?
That's something we really wanted to do
because,
I don't know,
I mean,
I'm going to confess some bias here.
There's a talk I gave at PyCon US.
If you Google it,
you can find it,
anvil PyCon Portland talk,
which I entitled like,
you want to make the world better,
put a little bit less JavaScript in it,
which is,
you know,
it's like the inflammatory title,
but fundamentally,
when you're doing stuff like that
in JavaScript,
even like the hello world,
you have to understand
asynchronous callbacks,
which means you have to understand
like closures
and anonymous functions
and even promises.
Well,
that's just an abstraction
on top of them
and you've got to understand
that as well.
And like the minimal set
of what you need to do
for,
hey,
what's your name?
Let me stick that in a database
and read it back to you
is like a huge amount
of computer science.
And we really wanted to take that back
to what you had,
you know,
what you get in a REPL
or what you had with QBasic
or what you had with Visual Basic
or Delphi,
where you could just go,
well,
okay,
you click the button,
what's the first thing I do?
Well,
I call this function
that puts it in a database,
what's the second thing I do?
Well,
I do something else
with the value it's returned
and you can reason about it
in a very straightforward manner.
And so we've put a lot of effort
and a lot of like compiler hacking
in the background
to make that happen
so that the user model
is as simple as it can get.
Yeah,
and I think it's super,
super approachable.
So,
you know,
I sort of touched on it,
you did as well,
like working with JavaScript,
working on the web these days,
it's really tricky.
if you're not going to use JavaScript
and you want something interesting,
you're probably talking Django,
Flask,
or something else,
Ruby on Rails,
ASP.NET,
but none of those are super like
walk up and just,
oh yeah,
I just push the button
and go, right?
There's actually quite a bit of work
to make those things
all fit together.
and kind of the worst of it
is you need to do
all of the above,
right?
Because if you're building
a web application today,
you're going to need
at least five different
programming languages.
You need to write the HTML,
you need to write the CSS
to make it look
how you want it,
you need to write the JavaScript
for it to behave
in the browser,
you need a server-side language
like Python
on,
running on the server
for the browser
to talk to,
you need to be talking SQL
to your database
and then you need
a framework for the JavaScript,
a framework for your CSS
like Bootstrap,
another framework
for the JavaScript
if you're doing this
React plus Redux thing,
a framework for the server-side
language like Django,
probably a framework
for the database
like SQLAlchemy.
I mean,
I count these on my fingers,
I've literally just run out
and that is a completely
unfair bar
to set for,
you know,
you must be this tall
to ride this ride.
This ride is the web,
it's the greatest
application delivery platform
that humanity has invented
and we make you learn
all this stuff
before you can basically
do hello world
and it's kind of interesting
how that happened as well
because...
How do you think
we got here?
The web as a platform
is this kind of
Frankensteinian creation.
It grew up in the 1990s
and there were people
who could see
the, you know,
the potential for this.
You know,
JavaScript itself
was kind of dashed off
extra famously
constructed by Brendan Eich
in two weeks
but as the web
sort of grew
and it could be seen
as a platform,
Microsoft,
who are then
the dominant incumbent,
put a lot of effort
into kind of
corralling that power.
You know,
you had the Internet Explorer
Netscape,
Monopoly Wars of the 1990s
and you had this kind of
semi-deliberate crippling
of the platform.
You know,
how,
if people remember,
gosh,
I mean,
I realize that this makes me
old for some people.
if you remember
the pain
of trying to make
something work
at Internet Explorer 4
or 5
as a web application,
it was really hard work
and that was not accidental.
Yeah,
and then they kind of
fixed it in Internet Explorer 6
and then the web
kind of suffered
from a couple years
of stagnation.
It was years of stagnation.
I think that the couple
of years of stagnation
is,
that was actually
arguably
one of the periods
of greatest innovation
where it just became
obvious how tight
the constraints
and limits
that had been put
on it were.
because what actually
happened is this wonderful,
it's almost a Greek tragedy.
You get Microsoft
trying desperately
to hold back
this tide of web innovation
so it doesn't become
the platform of the future
and then this,
you know,
around the turn
of the millennium
and this is like famously
product groups
in Microsoft
not very well connected,
the Outlook
web access team,
they go,
well,
wouldn't it be great
if you could have
like Outlook,
an email client
in a web browser
and they kind of
put enough pressure on
to make the Internet Explorer
team implement
this weird,
janky interface
for doing like
real-time calls
to the server
called XMLRPC request
and then that
gets released
in like what,
2002,
2003
and within a year
you've got Gmail
and Google Maps.
Yeah,
that just totally
broke the dam free,
right?
That was when
the whole Web2O
sort of thing
kicked in,
right?
Yeah.
Thing happened,
yeah,
and so the Internet Explorer
stick-6 stagnation
was a bunch of people
kind of,
it was a belated
putting on of the brakes
when the dam
had already broken.
but the fun thing
about this is
what it means is
the whole Web platform,
the whole structure
of the Web platform
is built on the rubble
of a platform war
of the early 2000s
and so that's why
the ground underneath
your feet
is so rough,
I would argue,
because we're still
trying to build
a functional application
platform on top
of a system
that was originally
documents
and then evolved
against really
like active opposition
into an application
platform
and what's left
is this Frankensteinian
monster
of so many
different languages
and frameworks
having to work together
to make something
happen
that you end up
with this huge barrier
to entry.
Yeah, you do
and I feel like
a lot of the Web
is like,
well,
we could probably
do this better
but this is working
everywhere
and that's more
important than anything
else.
It's the ultimate
path dependence.
It's how we,
you know,
we got here this way
and that's,
so that determines
the way things are.
Well,
so that probably means
writing Python
in the browser
is not really
going to be a thing,
right?
It's all JavaScript.
Absolutely.
Also,
and this is,
this is one of the
things we set out
to tackle.
We actually use
an open source
Python to JavaScript
compiler called Sculpt
and so that's
what enables us
to take your Python
code that you've
written in this,
you know,
design code,
your view thing
and run it right
there in the browser.
that project
already existed
and there are a
couple other
kind of like it
but there was a lot
that of work
that needed doing
to it.
I jumped in,
I'm now one of
the maintainers,
I did the big change
that enabled that
blocking code you
were talking about
earlier,
that was,
that was a big
change.
But yeah,
it's really quite fun
because not often
you get to do like
deep compiler hacking
and then say,
actually,
this is,
you know,
you can draw a
direct line from
this weird piece
of object code
transformation I'm
doing to like
I'm improving
usability for
seven-year-olds.
And I mean,
and indeed,
I should say this,
for developers
of all strikes,
right,
for your data scientist
who knows how to
draw a graph
and needs to do
a web map.
what I think is
really interesting
there is like
you open that
statement with
we're improving
sort of the
accessibility of the
web for seven-year-olds,
which I think,
as you pointed out,
kind of downplays
the significance of it.
But when you get
something that kids
like that can start
to use,
what that really
means is
non-programmer,
you like crack open
like a whole new
aspect of the web
for non-programmers.
People who like,
hey,
I could totally
program Excel
and I could like
set up these functions
and maybe an if statement
that'll make
like this Excel go,
but I'm not a programmer,
right?
All of a sudden
that person can become
like they could build
a web app
totally with those skills.
So this is something
that's quite interesting
and it's a philosophical thing.
A lot of people
are interested in making
tools for non-programmers
and actually,
if you want tools
for building a web app
for non-programmers,
there's actually
quite a lot out there
and it's probably
better optimized
for non-programmers
than Anvil is.
We actually take
a different approach.
We say,
programming's not
actually that hard,
right?
increasingly,
people teach themselves
to code from websites.
They get taught in school.
It is something
that people think
it's reasonable
to teach middle schoolers
and a whole bunch
of people
have learned themselves
and I would argue
kind of one of the
big reasons
we have this big
mental block
around,
oh,
programming's so hard,
we have to make it
accessible to non-programmers
is that when we think
of programming,
we think of
the modern
10-layer
web application
stack.
Whereas,
actually,
writing code
is the best way
to tell a computer
how to do something
and Python
is one of the best
ways to get from
I'm learning
these concepts
to cool,
I can write some
code that gets
some stuff done
and that should
be all you need.
So,
we're kind of
not aiming
at non-programmers,
we're aiming at
I can do a little
bit of code
and that should
be enough.
Yeah,
I guess that's what
I was thinking of
as well.
It's like people
who are like,
I'll take a
two-hour or
five-hour course
on Python
and put a little
effort into learning
to code,
but I'm not going
to take computer
science four-year
program, right?
Like that kind of
group.
And you shouldn't
need it, right?
It's when people
talk about coding
as digital literacy,
this is what
they're talking
about.
You shouldn't
actually need
to be that
kind of expert
before you can
at least participate
in this world.
So, funny story,
I'm actually
taking this
interview from
borrowed offices
of a customer
who started
with a single
data scientist
and, you know,
she had the
stats knowledge,
the marketing
understanding
for an ad tech
product she wanted
to build.
As far as she
was concerned,
she was, you know,
she was not a
developer.
She couldn't
build the web
app that this
so clearly needed
and was, you know,
talking to agencies
and so on.
And then she
found Anvil
and suddenly
actually she
realized she was
a developer.
It's just that
what she could do
was, you know,
the Python she'd
learned in the
course of data
science.
And that's kind
of moving the
goalposts that
actually a lot
more people can
and do know
how to code.
They just don't
think of themselves
as being able
to build stuff
primarily because
of the quality
of today's tools
rather than
because they
actually don't
know how to
program.
And the world's
full of people
like that, right?
People who can
write a little
bit of code,
as you said,
like people
who'd in
previous decades
would have
graduated from
Excel to
Visual Basic
are now like
they're the
people who are
writing Python
analysis,
you're doing a
little bit of
Python notebooking
and we're trying
to graduate them
onto, you know,
you can take that
and you can build
something real
that in this case
handles, you know,
terrifying amounts
of advertising money.
That's awesome.
I do feel like
that people are
expected to
start software
as they're
compared to
places like,
well, this is
how Instagram
works with Django
and this is how
they use
microservices
and this is how
they've written
it to be testable
and scalable.
People look at
that and they go,
well, I can't do
that, so I can't
start, right?
And I feel like
sometimes the most
important thing is
just to get started.
like, I think
Microsoft Access
was like one of
the most used
small business
sort of things
for basically
forms over data,
build something to
work to make my
dentistry run
or make my little
business run.
I'm not a programmer
but I can like drag
this stuff around
until I can get
what I need
and that's kind
of gone away,
right?
I'm not a programmer
but I can use
Access to put this
together.
I'm not a programmer
but I can create
a visual basic form
to do this one
thing that's
application specific.
I'm not a programmer
but I've now
created this line
of business
application that
runs my business
and Microsoft
have basically
taken one look
at this and
realized that they
had to guarantee
support for
applications written
in Visual Basic 6
out to like the
2030s or something
because you give
people this ability
to like slide
into building code
and you know
you give people
this power and
amazing things
happen.
Although, yeah,
something we've
been working on
quite a lot with
Anvil is to
support that whole
journey because I
don't want to
like pretend
that good
architecture and
testing and all
these things aren't
important and so
a real, the big
design goal for us
with Anvil is to
have something you
can get started
with without this
huge barrier to
entry but is not
going to stop you
achieving mastery
and proper design
and scaling your
app and scaling
your code.
Right.
You don't want to
set a really low
ceiling.
Yes, exactly.
don't want to
set a really high
barrier to entry.
Yeah, and we're
convinced that this
is possible and we
think that, you
know, we are well
on the way if not
already there for
most people's use
cases and I think
that there's a bit
of a sense that
the floor is so
high on the
traditional tools
anything with a
lower floor must
have a much lower
ceiling and I just
don't think that's
true.
I think that's
awesome.
So maybe now is a
good time to like
start actually getting
into the details of
Anvil.
People can check it
out at
Anvil.works,
right?
You can go there.
There's some actually
really nice videos and
some really intriguing
things but it
basically starts, you
say, create a new
project.
It happens on your
web IDE and it
drops you basically,
well, why don't you
walk us through it?
So it doesn't just
drop you into a blank
page necessarily,
right?
if you sign up at
Anvil.works, it is
free to sign up.
You end up in this
IDE and you can choose
some of our sample
apps and see what
we've done before but
if you just create a
new app, you start
with selecting a
visual theme and you
create a new form
which is like a page
in your site.
You've then got this
form.
It's not fully blank.
It's already got like
the visual structure in
there and for this
point you have a
toolbox of stuff on the
right that you can
just drag on and
visually create your
page and everything
you drag on is a
Python object and if
you sort of scroll
down on the right you
can have, you can see
its properties like for
example if you put some
text on there's, you
know, the font size of
the text, there's the
string that's what the
text actually is, there
is, you know, there's
which font, there's
which color, all that
kind of stuff and you
may or may not realize
it at this point but
you're actually just
editing attributes of a
Python object that is
going to be created at
runtime.
Hey everyone, this is
Michael.
Let me tell you about
Datadog.
They're sponsoring this
episode.
Performance and
bottlenecks don't exist
just in your application
code.
Modern applications are
systems built upon
systems and Datadog
lets you view the
system as a whole.
Let's say you have a
Python web app running
Flask.
It's built upon MongoDB
and hosted and scaled
out on a set of Ubuntu
servers running Nginx and
MicroWisgee.
Add Datadog and you can
view and monitor and
even get alerts across
all of these systems.
Datadog has a great
getting started tutorial
that takes just a few
moments and if you
complete it, they'll send
you a sweet Datadog t-shirt
for free.
Don't hesitate.
Visit talkpython.fm
slash Datadog and see
what you've been missing.
That's talkpython.fm
slash Datadog.
Yeah, like you said, you
may or may not know, but
it has this very Visual
Basic 6 designer feel,
right?
Like you see it, you drag
the stuff on there, you
have a properties pane, you
change the name, and then
maybe if there's like a
button, you have these
events, right?
So there's various things
that might have events.
Like if you double click a
button, it drops you into
like this code behind type
thing, which is a Python.
Yeah, tell us about that
back there.
If you double click a
button, you're immediately
dumped into a function that
runs and that button gets
clicked, and it's actually
a method of a class that
represents the whole page.
All of this is Python,
right?
Absolutely, all Python.
And all those things you
dragged onto the page are
in fact accessible as
instance variables, so
you know, self.label1 or
whatever, in that Python
code.
So it's a very natural
thing.
I mean, you said Visual
Basic 6 and Delphi, and
no two ways about it.
Anvil owes a huge debt to
those rapid application
tools of the 1990s, because
that was a really good way
to work.
They were hugely successful
in building quick little
applications rather than
hiring like a big dev team,
but they ran on Windows
95, not on the internet.
You'll spend most of your
time, if you're editing an
Anvil app, switching between
the visual design to put
some visual component on and
the code that runs when you
interact with these
components.
everything there will be
compiled to JavaScript and
will run in the user's
browser.
You'll then, of course, if
you're writing most non-trivial
web apps are going to
require a server component, so
you can add a server module to
your app.
And that's a Python module that
runs on our servers, original
naming, right?
And you can put whatever you
like into that module.
It's just a Python module.
But any functions that you
annotate with at
anvil.server.callable,
just a decorator, those
functions you can then call
from your client code.
Right.
Much like writing like a
Pyramid or Flask web method.
You just put a decorator on it
and then it's accessible.
But somehow there's a kind of
a really nice link both through
the autocomplete
IntelliSense side of things as
well as the calling side with
the Python that is the code
behind for your page that
actually runs in the browser
and the Python that you write
that actually lives in the
server, right?
Not knocking Flask because
Flask is excellent for
building REST APIs, but
having to squeeze all of
your app state through this
choke point of it must be
representable as a REST API
and as JSON is one of those
things that makes the web
unnecessarily difficult and
we explicitly avoid that.
So when you mark a
function as callable in a
server module in Anvil and
then you call it from your
client code, as well as being
autocompleted right through
and, you know, if you get an
exception, there'll be a
stack trace that shows the
call going from the service
of the client exactly where
it blew up, which is very
hard to do over something
like REST.
You can also pass in or
return much richer data
structures.
I mean, you can pass in or
return anything that could be
JSONs, so, you know, lists,
dictionaries, strings, numbers,
none, etc.
But you can also do things like
returning a row from a
database.
Actually, I'll just explain
what that is.
So a lot of apps will
require some app-specific
storage.
And because it's just Python,
if you already have a
database, you can just, you
know, import PyMySQL, import
Psycopegee, connect to a
database and go on.
You know, many people do.
But a lot of the time you'll
require something apps, some
app-specific storage.
And Anvil has a built-in
database we call the data
tables for that.
That's based on Postgres,
right?
Yes.
So it's backed by Postgres
and the tables themselves
have a directly Pythonic API.
So you don't actually write
SQL to interact with them.
You can if you've got a
dedicated instance and you
have your own database and
we don't mind you writing
Towers of Hanoi in SQL.
But this means that the data
table itself is a Python
object.
So if I create a data table
to store all the visitors to
my form, I entitle it
visitors.
I've then got app tables
dot visitors accessible as
an identifier in my code,
just like those components
are accessible as Python
objects in my code.
And I could return that.
I could search for a set of
rows and those rows will
become live objects.
You can access them like
dictionaries to, you know,
get the column values out
or you can update them by
going, you know, row,
bracket quote, name,
bracket is Meredith.
Okay.
So I think there's some
really interesting stuff
happening here in that you
have Python that looks like
it's just regular Python,
but actually runs and
sculpt in the browser and
you've got Python that runs
on the server.
Where can I access this
database?
Because it could be like,
do I have to do it only on
the server or can I put it
in my like button click?
Not necessarily should,
but that I could.
Absolutely.
So the thing I was leading
up to, we were talking
about the client server
calls.
The reason that we benefit
from not squeezing
everything through this
choke point of a REST API
is you can return a row
from a database as a
Python object.
from this server code
and it will pop out of
your, the call as a
return value in the
client code.
And this means you can
absolutely just directly
access this in client
code.
I mean, in fact, for any
data table, you can set
its permissions.
You can say, actually,
this table should be
completely readable from
client code.
And then in your form
code, in the stuff that
gets compiled to JavaScript,
you can go iterate through
all the rows of the table
if it's readable from the
client.
Why shouldn't you be able
to?
Yeah, that's cool.
And you also get like a
visual designer type thing
for the databases and the
relationships and stuff.
Yeah.
So yeah, if you're, you can
say, oh, there's, here's a
bunch of components.
I'm repeating it for every
element of list.
And again, like this is
something we gain from
everything being Python
because that list is just a
list of Python objects and
you can give it a hint or the
autocompleter can work out
what type the Python objects
were.
And if, for example, it
knows that you've given it a
list of rows from such and
such a database, then when
you, when you were in the
visual designer and you pull
up the data bindings and you
say, I want the text on this
label to be the name column
from this row in the
database, it could
autocomplete that for you
because it's all using the
same object model.
It's all using the same
language and it knows, for
example, what options are
available for column lookup
on that row.
And that I think is a really
powerful thing for making
this stuff a lot faster.
I think also that that's a
super important component for
people who are getting
started.
They, they look at code and
they're like, I don't know
what to type.
Right.
But if you type dot and
like, here's a list, like,
oh, it says text.
Okay, cool.
That must mean like that's the
value that's in the input
box or I type dot customer
dot name.
Oh, that's the name of the
customer, right?
That's super helpful.
So there's a talk that I, a
lightning talk I just gave at
Python UK.
So last Sunday, that will be
going up on our website soon,
possibly by the time this
podcast gets published,
where I talk about the
autocompleter and how we
built it.
But actually I spent about
half the talk talking about
how no really autocomplete is
just terribly important.
And seriously, listeners out
there, if you spend all your
days in Vim or Emacs and you
don't use an autocompleter, I
would just recommend just try
for a week, install the Jedi
plugin for Vim or Emacs and
experience what using autocomplete
is like for your code creation
because you're faster, you know
what you're doing, you can
eliminate whole classes of bugs
without ever even hitting the
run button.
And you get this, you know, you
get to stay in flow rather than
going out to check the document,
documentation every five
seconds.
Yeah, I use PyCharm a lot and
that's one of the main things
that I find it super helpful
for.
You do the editor question at
the end, but yes, absolutely.
And I have to say we spent a
while thinking that we could do
without autocompletion and
create a application development
environment that was fun to use
and we were just wrong.
You need it.
You need that reassurance.
Yeah, what I think is really
interesting is you actually span
like client server with
autocomplete and stuff as well.
Yeah, well, no, this is
honestly the biggest thing.
It's when one of the reasons
that a lot of people, again,
when back in the 1990s, your
standard tools all had
autocomplete, why people have
kind of lost it now is because
the tools don't know about, oh,
well, what's on the other end of
this rest call I'm making?
What options will be available on
the thing that comes back?
And actually, because it's all in
the same system, it's all in the
same language, the autocomplete
goes, well, you know, I passed the
return statement that will give me
this value five seconds ago.
I know exactly what it's
returning and I'm going to
autocomplete the columns available
on this database, right?
That's actually really, really
nice.
And we preserve that.
And again, because we have this
rich interface that's not
squeezed over a rest connection,
we can do things like we have a
built-in capability security
model, which is a fancy word for
a thing that you most of the
time just don't need to think
about, which is if you've got
one of these rich objects and you
return it from a server function,
that was you giving the client
access to that object.
So if there's a data table that
the server can access and the
client can't, but there's some
server function that says, well,
okay, I will give you the rows
that belong to your user.
As it's returned to those, you've
now got read access to those rows
that belong to your user.
And so you can use them directly
in client code.
That's cool.
How much ability do you have to
structure things other than this
like page code behind thing in
Python?
Like, can I create like classes and
helper modules and stuff in Python
that actually run and sculpt?
So we've got server side modules
that run purely on the server and
that's code that the client never
sees and is trustworthy.
And then we've also got like
utility modules, which can be
imported from client and server.
And again, they're just Python
modules you can import.
So, you know, common code that'll
be between lots of your pages.
We've also got a system where you
can take your whole app and kind of
package that up as well as a Python
package that other apps can depend
on.
So you could say, you know, oh, I've
built a form for, I don't know, for
displaying a progress bar.
This is something that actually one of
our users did in the forum recently.
I built a progress bar form and I'm
going to export this as a package that
somebody else can import.
So you can also structure your code in
that kind of reusable libraries way.
Right.
That's a really cool bit.
Like, I can't remember the last time
in the web that I had like a sort of a
drag and drop reusable visual component
that had both a visual aspect and a
functional aspect.
But you guys have that, right?
You can create these like sub element
controls and like drop them.
I mean, it's been probably 10 years
since I've worked in a web framework
that had that.
Yes.
This is the thing, right?
People say, oh, it's been 10 years.
What happened to progress?
Why did we go backwards in those 10
years?
Yes, absolutely.
So when you import one of these, if
you, when you import a dependency
that's got some of this stuff in, as
well as being able to like import the
utility modules, you know, just like
you'd import Python modules.
And of course they ought to complete
and blah, blah, blah.
You've also got this server side code
you can bring in.
So you can make, you've brought in the
client side code, you've brought in the
server side behavior and you've brought
in the visual design all at once.
So you can create these reusable
components that will abstract away a
lot of the fuss people.
people currently have to re-implement
10 times.
There could be actually almost a
marketplace for people to create
really powerful little controls.
Tell me about it.
That's definitely on our radar.
I don't have anything to talk about
yet, but yes, you would not be the
first person to ask for that.
Yeah.
I mean, definitely in like the Windows
forums, VB space, there were companies
that like just, they built these
components that you could buy.
Like I need a really cool graphing
component or I need like a, I don't
know, like a login component or
something and you just drop them in
there.
Yeah.
And I feel like we've already kind of
proved out that model with the
components and services we already
provide within Anvil.
So as well as like forms and modules
and server modules, in an Anvil app, you
just hit a plus button next to the word
services and you get the option of
adding a bunch of pre-built
interfaces to various external services.
So, I mean, the data tables is one I've
already talked about, but you could, for
example, you know, add the Google API
service and that's just a bunch of
packaged up functions for dealing with
files in Google Drive, accessing Google
Sheets documents, authenticating people
with their Google accounts.
So maybe some company that runs on Excel
could take all of their Excel documents,
drop them into Google Docs, and then you
could access them and convert them, access
them as Google Sheets and use them as
companies that do that have done that
with Anvil.
Okay.
Yeah, for exactly that reason.
And that's enabled by the fact that there
is this drop-in, you know, client and
server and UI service that provides the
things you will need if you want to
interact with the Google API.
And similarly, you know, we have something
equivalent for Facebook and a couple of
other things.
Yeah, you guys have Stripe, like a super
simple integration with Stripe.
Oh, yes, absolutely.
So if you want to get money, again, just a
Stripe integration just off the shelf.
Yeah, that's awesome.
You have email, you have user management.
Those are both pretty impressive.
Yes.
Well, user management was what I really
wanted to talk about.
It's the perfect example.
The user management service is implemented.
I don't think there's any, no, there is no
JavaScript in the entire thing.
It's all implemented using the standard
API.
So user service is a perfect example of
something that you could have written
yourself.
In fact, people, of course, people did.
People did before we had it implemented.
But it's just a data table with, you know,
a column for email, a column for your
bcrypt hash password.
Oh, you guys are using bcrypt?
That's awesome.
You know, a server function that you pass
in a username and password and it looks up
the user and says, does it match?
And if so, it stores something into the
session.
And, you know, you can use the Google API
service to say, oh, who's, you know, log this
user in with Google, who's logged in.
Right.
You got the OAuth 2 stuff.
It's all something you could build, but you
don't want to have to every time you want to
build a web application.
I'm working on a project right now and I spent
like literally a full day just working on
user management.
And I'm like, yep, this is just like the
stuff I wrote six months ago.
And it's also going to be probably what I
write six months from now.
So I feel like I'm always reinventing user
management.
So that's cool that that's kind of a plug
and play thing.
We've tried to pick off some like low hanging
fruit, the things that people reinvent a lot.
And user management was, I mean, pretty much
top of that list.
Yeah.
How many times have you written an email
validation link processor thing?
Too many.
I want my life back.
Exactly.
But really, that's just the low hanging fruit
because there's tons of stuff out there that
people implement every day and shouldn't have
to, they should, they should be able to
create reusable libraries.
And we're really excited to have that kind
of ease of use come to other domains in
that.
So if you're Esri and you're like a company
that creates the company that creates ArcGIS,
you wanted people to access your stuff.
Maybe you could just drop in like, here's
how you just plug into our web service and
just get to your like cloud GIS stuff.
Right.
Or things like this.
Yeah.
That's beautiful.
This portion of Talk Python to Me was brought
to you by GoCD.
GoCD is an on-premise, open source, continuous
delivery tool to help you get better visibility
into and control of your team's deployments.
With GoCD's comprehensive pipeline modeling,
you can model complex workflows for multiple teams
with ease.
And GoCD's value stream map lets you track changes
from commit to deploy at a glance.
Say goodbye to deployment panic and hello to
consistent, predictable deliveries.
We all know that continuous integration is super
important to the code quality of your applications.
Choose the open source local CI server, GoCD.
Learn more at talkpython.fm/gocd.
That's talkpython.fm/gocd.
And I mean, Anvil already, again, all of this stuff is stuff you could do yourself.
We have a bunch of really cool stuff for interacting with web services.
I mean, if you're a client of a web service, you probably just want the requests library
and then you're off.
But making that easy and simple and tab completing their whole API is a kind of thing that companies will want.
And it's something we've talked to with companies before.
And we're really excited about bringing that kind of,
oh, OK, I want to do telephony.
Fine.
Yeah, that's one import and autocomplete.
Exactly.
Drop in the Twilio module or whatever, whoever it is, right?
So this is all super interesting.
And these component type things are super cool.
But one, I guess the thing that probably was most impressive to me that showed like,
OK, you have this thing that runs in your environment and is hosted.
And I want to talk about like what that means.
Before we talk about that, though, let's talk about Uplink, your final service.
Oh, yeah.
Well, so Uplink isn't really service.
The Uplink is yet another example of a pattern that we do right the way throughout Ambil.
Everything's built in abstractions, right?
You know, you can solve every problem in computer science with another layer of abstraction,
except the problem with too many layers.
Right.
If it doesn't work, you add one more, yeah.
Yeah.
And Ambil is an abstraction over the web.
And of course, every abstraction has its limits.
Every abstraction leaks, to quote that famous essay.
And the question is, how does your abstraction handle it when you hit the edge?
And I mean, JavaScript frameworks basically handle it by letting it all hang out.
But, you know, you can't use these JavaScript frameworks without understanding quite a lot
about how they work underneath anyway.
So you can just, you know, pull away bits of the foundation and edit it yourself if you need to.
Some abstractions, like if you're writing a Windows desktop application and you need it to run on the web,
you're kind of stuck.
You know, you're going to have to do some serious rewriting or interfacing.
But the pattern I most like is kind of, I should say, there's also this kind of ejection pattern.
There's a tool called Create React App, if you're familiar with it.
I forgive you if you're not.
But the idea is it simplifies a bunch of the creation of, you know, the front-end build process.
So I want to take my source code and compile it to another form of JavaScript,
compile it to another form of JavaScript, minify it and deliver it as one asset.
And it takes a lot of that kind of pain away from you.
But of course, it's going to be limited and it's going to be an abstraction that won't let you do absolutely everything your platform requires.
And if you hit this limit, there's a handle you can pull like eject.
And then it will say, well, you're done here.
I will dump out all like the high complexity stuff for you and say, well, right, you can edit it.
You know, you can edit a webpack configuration now.
Oh, goody.
And like if Anvil had something similar, it would be like, oh, this thing is now a horrendously complicated JavaScript app using this Python JavaScript compiler you have no familiarity with.
Have fun.
And that's actually slightly, I mean, it's more user-friendly than like making the user go down with a ship.
But it's still quite high complexity.
And what we try to do is instead of an ejector seat, we've got escape hatches.
So you want to do some specific visual design on your web page.
Well, that's fine.
If you want to, you can drop down and edit the HTML and CSS that makes up the template into which these Anvil components are dropped.
And you can create your own house style and, you know, bring in assets from a professional designer and use that.
If you have some, you know, you want to build something like WebRTC was a request I got recently.
You know, we don't support that yet.
We will one day.
We don't yet.
I want to use this advanced feature of the browser platform.
Well, that's okay.
I can write some JavaScript.
Some JavaScript.
And then I can call it from Python.
It can call into my Python.
And then I can package all of that up as one of these custom components.
Make a library so other people can just say import my code.
And now you have WebRTC support.
It's all auto-completed.
It's all nice.
It's all in Python.
You don't have to worry about it.
And the server-side version of this is the uplink.
So the uplink, it's a library you can pip install from anywhere in the world.
And when you enable it for your app, you get an authentication key.
And you do anvil.server.connect and you give it this authentication key.
And now your Python code, wherever it's running in the world, is connected to your Anvil app.
It makes a secure WebSocket connection in.
It's really quite impressive.
I think maybe give us the example that you have on your website with the Raspberry Pi.
Because I think that really highlights how flexible this is.
So if you've got a Python code, if you've got Python code running somewhere in the world,
and you Anvil server-connect in, all those things you can do on the server module,
you can do from your Python code, wherever it is.
And there's an example tutorial video on our site of me doing this with a Raspberry Pi.
So I take a Raspberry Pi.
I write, like, with two lines of code.
If you've ever used a Raspberry Pi, you can get something called a SenseHat for it,
which is an LED array.
And it's, like, really super simple to display some text scrolling across that LED array.
It's very nice.
And I write a function that takes a piece of text, displays it on that.
Because I've got the uplink, all I do is I mark that at Anvil.server.callable,
just like I would in a server module.
And all of a sudden, I can call it from my web app.
Just to be clear, this is a function running on the Raspberry Pi.
It's being called by your Anvil app.
Absolutely.
There's a function running on the Raspberry Pi.
It's crazy.
Called from a web browser.
Why shouldn't you be able to do that, right?
Yeah, it's beautiful.
It's one call.
We don't even use a server module.
We call it straight from the browser.
Yeah, that's really incredible.
And it even goes straight through firewalls and stuff.
You don't even have to open a port because it's an outbound connection to establish that socket, right?
And so you can drive code.
I mean, obviously, the Raspberry Pi is a slightly educational, possibly slightly facetious example.
But, you know, we've got people driving big, like, machine learning jobs that need to run on some dedicated server somewhere with, like, 20 GPUs in.
And, like, you know, if they tried to do that inside our server modules, they'd hit their CPU quota pretty quickly.
And that would be the end of that.
But because there's a route to plug your code into Android wherever it is, they just import the uplink module, you know, mark some control functions callable.
And they can drive this big GPU rig from our hosted web stuff just as easily as you could drive this Raspberry Pi on your desk to display something just as easily as you could be driving a server function.
This is a really cool feature.
I really like it.
So maybe this is a good time to talk about, like, what it means to publish your code, where is it hosted, things like that.
So tell me about where I can put this code.
When I hit publish on your site, what does that mean?
It's hosted on our infrastructure.
We were talking earlier about this hugely deep web stack you need to understand all of.
And you need to understand all of before you can do, like, even Hello World on the web.
And we didn't talk about the layers lower on the stack, right?
Also, if I want to deploy a Hello World on the web, I'm going to need to understand, like, you know, AWS, spin up a server.
I'm going to have to understand how to administer a Linux computer usually.
I'm going to have to publish that.
I'm going to have to keep it up to date with security updates because I don't want to be the next Equifax being popped by, you know, months old known vulnerability.
And that, too, is a barrier to entry.
And tools like Heroku can help.
But what Anvil does is we do the whole package.
So you write your code in Anvil, and it's hosted on our platform as well.
So you hit the publish button from the Anvil editor, even if you, you know, just signed up 30 seconds ago.
You hit the publish button, and you've got a URL that is your app on the web already.
By default, obviously, it's a private URL.
It's like one of those Google Apps sharing links.
So, you know, Google Docs, if I send you this link, you can open it.
But if you don't have it, you can't get it.
And this is really powerful because it means that your turnaround time is really low.
You can get something onto the web very quickly.
And you're not worrying about all that ongoing maintenance burden of, ooh, have I updated the server this week?
Yeah, I think that's really cool.
And where's your infrastructure actually running?
Is it AWS or somewhere else?
We run in AWS.
Okay.
But, I mean, we also run on-site stuff.
Go on.
Sure.
And you guys have an option to let it, to basically have an on-prem version, right?
Absolutely, yeah.
And, of course, that is just, you know, a few Docker containers, one Docker-compose command,
and you've got a local version of Anvil running on your own machine.
Yeah, that's cool.
So our code runs in Docker on some Linux machine in AWS, basically, when we run it, the server code?
Absolutely, yes.
Okay.
It's a little bit more tightly locked down than that, but yes.
Yeah, sure.
And do I get to pick the data center?
Not at the moment.
You will want one of, there's a business-dedicated hosting plan that says, essentially, we will put the VM wherever you like, and you can have it to yourselves.
Okay.
Yeah, that's pretty cool.
So I think what you guys have built really is quite interesting, and definitely for proof-of-concept apps, for people who don't really consider themselves web developers, but they feel like they can learn enough to solve their problem.
Like, this is awesome.
Yeah, I think it's not just for those people.
I mean, it is for those people.
It's not just for those people.
Something that we do observe quite a bit, for example, is people going, oh, well, I'll just use this to throw together like a visual mock-up.
Oh, wait.
Well, I can add a little bit of behavior to it.
Oh, well, I can add a bit more behavior to it.
Oh, okay.
Well, I've got this first version of my app.
I might as well launch it as a prototype, right?
Oh, well, it's in production.
It's scaling.
Okay, then.
Yeah, exactly.
So the point is that we should be able to grow with you from that proof-of-concept prototype up to a deployed application, and we have many people who've done that with us.
It sounds definitely doable looking at what you guys have built there.
So one thing I do want to sort of touch on with you is what about the escape patches?
Like, so if I want to use a different editor that's external, if I want to do, like, unit testing, if I decide I actually want to take that code and put it somewhere else, is there a way to, like, move out?
I've talked to you before about, like, the server hosting environment and some of the really quite critical usability stuff we can do because we're not squeezing everything through this REST API checkpoint.
A corollary of that is it kind of needs to be hosted on our platform to work because standardized platforms that let you just return a database row from the server to the client and have that give you implicit permissions are kind of thin on the ground.
So if you want to run an Anvil app on-premises on your own hardware, you are going to need an on-premises license.
If you do want to migrate out, obviously, you know, we'd be sad to see you go.
But because of these escape patches I talked about earlier, it's actually a fairly straightforward process, right?
You could change your server modules into REST endpoints.
So, I mean, even if you're not moving out, right, you have, for example, a native iOS app that wants to talk to the same backend as the web app you've already created.
Well, that's fine because although by default we don't go through this REST API layer, you can decorate functions in your server modules to make them REST endpoints.
And say, this is very Flask-like.
Oh, well, this function is available at this URL.
And that lets you expand outside the Anvil hosted web client.
And equally, you can use different backends from an Anvil hosted client.
So, yeah, we don't think that you're kind of stuck there.
But there are tools of our platform that you kind of need the whole thing to use.
Yeah, that makes sense.
I do understand.
Like, you guys are doing a lot of magic to wire this stuff together.
And without the sort of orchestration behind the scenes, then I can see how that's not so easy to do.
I have a love-hate relationship with the word magic.
I mean, obviously, magic is a word that people use when they see, you know, something like Anvil working.
Oh, my goodness, that's magic.
And it's the word I used earlier to describe my first experiences with something like QBasic.
Oh, my goodness, this is magic.
But there's good magic and bad magic, right?
There is bad magic as in this is an Angular app and I'm not really sure what it does underneath to make this lever I pull over here connect to that thing over there that just wiggled.
And then there's kind of good magic which is comprehensible.
You could see exactly how it worked.
It just saved you some work.
Like, for example, the client server calls in Anvil.
There are an example of what I would argue good magic.
You can see, you know, it's just a function call.
You can see how it worked.
You see how you could implement it with REST endpoints if you wanted to.
But you're kind of glad you don't have to.
I mostly meant that in the positive sense, the magic you guys are doing.
But just that it's hard to replicate outside the environment, right?
So you have a business model for this that is more or less like a freemium.
Like there's a basic version.
But if you want your own domain, then you've got to pay some amount.
It seems pretty reasonable to me.
But one of the things that came up is like, what if I'm working on an open source project and I'd like to have like some kind of open web app hosted with you guys that a bunch of people can come and contribute to?
Like, what would that look like?
Or is that possible?
It totally would.
I mean, even if you have an open source web app, you know, somebody's usually paying for hosting somewhere.
But the good news about, the good thing about Anvil is that all of your apps are in fact Git repositories.
So it is totally a thing you can do to pull your apps Git repository out of Anvil.
You could stick it on GitHub.
You could collaborate.
If you asked earlier about, oh, I want to use my own editor.
Oh, I'm an Emacs fiend.
I absolutely must edit this module in Emacs.
That's fine.
Get checkout.
Get pulled.
Have fun.
Get pushed when you're done.
But also that means that you're open to collaboration tools like GitHub.
So you could totally run an open source app that's based on Anvil.
You could have multiple instances that people pay to host or host on our free version.
Yeah, that sounds good.
The Git integration is pretty nice.
And I guess you can create multiple upstreams in Git and make one of those be your GitHub repo, right?
That's something that we do all the time.
I mean, you can even do like a continuous integration, continuous deployment, because everything you can do in the Anvil editor is reflected in this Git repository, obviously.
So you could do things like, oh, well, this is my staging deployment and it's got access to some staging data.
And then I pull that Git commit and I push it up to somewhere else.
And that's my deployed app.
Indeed, we actually have a miniature version of this within Anvil itself.
So you can choose a version of your app.
If you go into view history, you can see like the full Git history of your app.
And you can select a version that's the published version.
And so if somebody comes to your shared URL externally, that's what they get.
And so you can carry on hacking and you've got this dev versus production thing already kind of built in.
But the thing about Git is that, of course, you can extend that.
I think that's really nice.
And so basically of this UI that says, here's your Git history.
That means like you went and pressed save, like save a state here.
But you can actually mark like this one right here right now is production and continue working on it and then push production on down the line once you have it sort of tested.
Also kind of in production.
And I think that's pretty powerful.
Yeah.
And actually, if you use that Git interface, you'll discover that's just a branching Git.
And this is kind of what I mean about good magic versus bad magic.
That's kind of magical.
But how we do it is very much open and you can play with it, too, if you want to do something more advanced.
But yeah, the normal user experience is like one click.
Okay, that's production now.
Done.
All right.
So we don't have much time left.
This is so much cool stuff to talk about.
I guess one last question is like you have your data tables as a service there.
How do I back up my data?
So if you're using the data tables within Anvil, the first thing to say is we do take regular and properly encrypted and stored backups of those.
So you should not have to worry about the data loss.
But if you want to copy on your own system, then there's a ton of ways to get it out.
I mean, every data table in the editor, there's like a download a CSV button, which is the very straightforward way of getting this stuff out.
But earlier we talked about the uplink.
And, of course, from the uplink, you can do anything you could do in those server modules.
It's not just a matter of saying, oh, well, here's a function that displays some text on my Raspberry Pi and it's callable from the web.
That script can also reach in and say, oh, I would like to iterate over all the rows in this table.
And that's totally legit from an uplink.
Sync that with some local DB, something like that.
Yes.
So if you had your own representation of data you wanted to synchronize with or import, export, that is really straightforward to do.
And again, if what you actually want is something in Amazon Redshift, if that's where you want to sync your data to and that's where you want all your data to live,
you could just access it there from Anvil as well because we've got all those Python modules ready for you to use.
There's nothing forcing you to use the data table service.
It's just something that makes your life more convenient in a lot of cases.
Right.
Knowing the Docker containers are running AWS, you can basically crack out and get to most of the other AWS stuff, right?
That would be accessible.
That would be possible even if we weren't running in AWS, right?
Right.
Lower latency inside AWS.
Yeah.
Does run quite well.
Nice.
All right.
Well, I think, you know, there's a bunch of other stuff we could dig into.
I think we should probably leave it here just for time's sake.
So let me ask you the two questions.
We talked a lot about editors, actually.
So let's start with your favorite editor.
Favorite because it's my baby and also I spend a lot of time in it is, of course, the Anvil editor.
It's got a full autocomplete.
It can do full stack development and it's plugged into full version control on the backend.
So I spend a lot of my time obviously working in that.
For building the Anvil backend itself, I actually use IntelliJ and I really love the JetBrains tools.
IntelliJ, PyCharm are fantastic.
Again, the autocompletion is top notch.
Cool.
All right.
That sounds awesome.
Yeah.
The editor you built is really, really nice.
I definitely like it.
Yeah.
Check out our PyCon UK lightning talk.
Yeah.
You send me the link.
I'll put it in the show notes.
And notable PyPI package.
The selfish answer here is the Anvil uplink because it is on PyPI and it is remarkably cool
in its ability to plug your own code into the cloud.
If I weren't counting that, then it's got to be Pandas.
The things you can do in like three lines of code that I recall using janky libraries to
pull that data out of Excel files and process it or worse using R.
Yeah.
Incredible.
So yeah, Pandas wins.
Cool.
Yeah, that's definitely a big one.
All right.
Final call to action.
People want to check out Anvil.
What do they do?
Oh, they go to anvil.works and they sign up for a free account.
We've got tons of walkthrough videos and tutorials.
There's a user forum that's really quite active and friendly.
And you can sign up for an account for free and start building.
And I would really encourage you to do so.
And I would look forward to seeing you there.
Awesome.
Well, congrats on building this.
It's definitely pushing Python in a direction that I haven't really seen it pushed successfully
in quite a while.
So it's awesome.
Nice work.
Thank you very much.
It's been great talking to you.
This has been another episode of Talk Python to Me.
Today's guest was Meredith Loof.
And this episode has been brought to you by Datadog and ThoughtWorks.
Datadog gives you visibility into the whole system running your code.
Visit talkpython.fm/datadog and see what you've been missing.
Don't even throw in a free t-shirt for doing the tutorial.
GoCD is the on-premise, open-source, continuous delivery server.
Want to improve your deployment workflow but keep your code and builds in-house?
Check out GoCD at talkpython.fm/gocd and take control over your process.
Are you or a colleague trying to learn Python?
Have you tried books and videos that just left you bored by covering topics point by point?
Well, check out my online course, Python Jumpstart, by building 10 apps at talkpython.fm/course
to experience a more engaging way to learn Python.
And if you're looking for something a little more advanced,
try my Write Pythonic Code course at talkpython.fm/pythonic.
Be sure to subscribe to the show.
Open your favorite podcatcher and search for Python.
We should be right at the top.
You can also find the iTunes feed at /itunes,
Google Play feed at /play,
and direct RSS feed at /rss.
on talkpython.fm.
This is your host, Michael Kennedy.
Thanks so much for listening.
I really appreciate it.
Now get out there and write some Python code.
I'll see you next time.
Bye.
you
Thank you.