When you’re marketing to developers, you go where the developers are. We make a platform for building full-stack web apps with nothing but Python, so we go to developer conferences – particularly Python ones.
Like many sponsors, we give out nifty Anvil-branded T-shirts. But there’s a twist: in order to earn a T-shirt, you’ve got to build something with Anvil. So far, it’s gone pretty well - here’s what it looked like at EuroPython last week:
Now we’re home, and preparing for PyCon UK in September, it’s time to order more shirts. The trouble is, developers come in all shapes and sizes, and the first time we ordered we were way off the mark. (Apologies to the huge number of people who wanted a Women’s Small!)
This time, we can be smarter. We’re a bootstrapped company, so we can’t just blow VC cash on unnecessary mountains of shirts – but we do want every Anvil user to go home with a T-shirt.
How can we use this data to work out how many shirts we need?
Option 1: Exact numbers.
“If last conference used 13 Men’s Medium shirts, we should bring exactly 13 to the next conference.”
This is obviously a bad idea. If even one more medium-sized man writes an app with Anvil, we’re going to run out of shirts. And feel pretty stupid about it, too.
Option 2: Double up
OK, fine, so let’s order 200% of what we expect to need. This will cause us to order 4 rather than 2 Women’s XS (probably sensible)…and 54 rather than 27 Men’s Large (not so much!). That 54th Men’s Large shirt is much less likely to be claimed than the 4th Women’s XS shirt is. It’s the law of large numbers: Larger samples average out more reliably.
Wait. I’m sure there’s a more helpful way of thinking about this than waving my hands and saying “law of large numbers”. Can we capture this insight in a statistical model?
Option 3: Be a bit smarter
Let’s imagine that every person who comes to the conference is a dice-roll. Some percentage of the time, they build an Anvil app and claim their T-shirt. What size they want is also a dice-roll: X% of the time they want a women’s Medium; Y% of the time they want a men’s Small; and so on. We can estimate how big X and Y are, because we know how many shirts we gave out at PyCon US and EuroPython, and we know how many attendees were at those conferences.
Next month, we’re sponsoring PyCon UK, with 700 attendees. How many men’s Medium-size shirts will we need? We can simulate it by rolling that die 700 times, and counting how many times it comes up “men’s Medium”.
Of course, each time we do that “roll 700 dice” procedure, we could get a different total count. This total follows a binomial distribution:
Here I’ve plotted two binomial distributions, using Anvil’s plotting tools. On the left, we’re expecting to give away about 2 shirts, but we could easily need twice that number. On the right, we’re expecting 35, but we’re unlikely to need more than 40 – we’re much more certain with larger numbers. This is the insight we had before – but now we’ve got a model, we can quantify it!
We can wrangle binomial distributions easily with SciPy. We’ll use SciPy’s
ppf function to get the 95th centile of this distribution: If our model is correct, there’s a 95% probability we won’t need more shirts than this.
Let’s compute that number:
from scipy.stats import binom # From 1500 attendees, we gave away 13 men’s Medium shirts p_mens_medium = 13 / 1500 # For 700 attendees, there’s a 95% chance we will need no # more than this many men's Medium shirts: n_shirts_p95 = binom.ppf(0.95, 700, p_mens_medium) print(n_shirts_p95)
So we need to take 10 men’s Medium-size shirts to Cardiff!
Now we have some Python code, we can put a web interface on it really quickly with Anvil. I built a T-shirt calculator that can do this calculation for many sizes of shirt at once. You can use it below, or open the source code in Anvil to see how it works:
Feel free to use and share this app. And if you’re going to a developer conference soon, perhaps we’ll see you there!
It was great meeting everyone at EuroPython! Next up: PyCon UK in Cardiff. Join us there, where we’ll be showing everyone how to build full-stack web apps with nothing but Python!
Meanwhile, here’s what’s new this month:
1. Single Sign-On with Microsoft
Does your organisation use Office 365? Now your users can log into your apps with their Microsoft accounts! Microsoft login (or, to give it its official name, Azure Active Directory) is available for all our Business plan customers.
2. Building Email-Driven Apps with Anvil
We’ve already made it easy to build web-based apps. Now it’s just as easy to send and receive email from your code, with our new Email Service.
3. New Documentation Search
We’ve made it easier than ever to search the Anvil documentation. Next time you’re in the Anvil editor, check out the search box in the toolbar. You can search our tutorials, reference documentation, and selected posts from the Community Forum.
(Speaking of the Community Forum, we’d love to hear your feedback. Come join us there!)
4. Other updates
As always, we’re improving Anvil all the time. Here are a few highlights:
Validating user input just got a lot easier, with our new form validation library. Check it out!
We’ve introduced a new domain for your apps: Now, by default, your apps
are available at
<something>.anvil.app. (Don’t worry, the old
<something>.anvilapp.net links still work!)
We had an idea for improving the saving mechanism, so if you’re on a flaky internet connection saving should feel instant.
Email is the most popular messaging platform on Earth. We use email to arrange events, to exchange files, and to notify each other when something happens.
You should be able to email your applications too. But to receive email, you need to set up a server somewhere, run an SMTP daemon, and somehow connect that to your code.
We’re here to fix that. Today, we’re delighted to show you the easiest way to build email-driven apps. All you need to do is write a Python function. For example, here’s all the code you need to receive emails and store them in a database:
@anvil.email.handle_message def incoming_email(msg): app_tables.incoming_messages.add_row( from_addr=msg.envelope.from_address, text=msg.text ) msg.reply(text="Thank you for your message.")
Sending is just as simple:
anvil.email.send( to="email@example.com", subject="New message", text="This is awesome", html="This is <b>awesome</b>" )
Despite its simplicity, it’s also fully featured - you can handle attachments, recipients, and even use DKIM to check that a message is genuine before trusting what it says.
You can scroll down for a cookbook of common examples, or watch as I build a full disposable-email-address service, and publish it on the web, in four minutes:
Here are a few things you might want to do with email. You can follow along from these code snippets, or view them all in the Anvil editor:
@anvil.email.handle_message def incoming_email(msg): app_tables.incoming_messages.add_row( from_addr=msg.envelope.sender, text=msg.text )
@anvil.email.handle_message def incoming_email(msg): msg.reply(text="Thank you for your message.")
@anvil.server.callable def send_a_message(txt): anvil.email.send( to=["firstname.lastname@example.org"], cc=["Someone Else <email@example.com>"], subject="Hello World", text="Hi there!" )
All attachments are Anvil Media objects. This means you can upload them from web browsers, store them in databases, make them downloadable, and more.
@anvil.server.callable def send_by_email(file): anvil.email.send( to="firstname.lastname@example.org", subject="New upload", attachments=[file] )
Incoming attachments are just as straightforward. Here’s how to save all attachments in a database:
@anvil.email.handle_message def incoming_email(msg): for f in msg.attachments: app_tables.files.add_row(file=f)
Email has historically been easy to spoof. Helpfully, many providers now support DKIM, which lets you verify that the email actually came from the domain it says it did.
dkim property of the message contains details about all that message’s valid DKIM signatures, and a shortcut to check whether it’s signed by the address in
@anvil.email.handle_message def incoming_email(msg): if msg.envelope.from_address == 'email@example.com' and msg.dkim.valid_from_sender: msg.reply(text="You're the real deal!")
There’s a shorthand, if you only want to accept DKIM-authenticated messages (and reject all others):
@anvil.email.handle_message(require_dkim=True) def incoming_email(msg): if msg.envelope.from_address == 'firstname.lastname@example.org': msg.reply(text="You're the real deal!")
@anvil.email.handle_message def incoming_email(msg): raise anvil.email.DeliveryFailure("Nope")
Start writing email-driven apps for free with Anvil:
You can also read more about the Email service in the Anvil reference docs.
It’s been another monster month for us.
It was great meeting everyone at PyCon, and the crowds around our table were awesome! Check out my 5-minute talk from the conference: Making the Web More Pythonic
As always, we’re improving Anvil all the time. Here are a few things you might have missed:
1. Beautiful apps: New Material Design theme
We’ve published a new Material Design theme! We’ve given our components a facelift and added swappable colour schemes, so it’s now even easier to build beautiful apps.
(Don’t worry, the old theme is still there - it’s now called “Classic”.)
2. Simple objects in Data Tables
If you want to store richer data, you can now add “Simple Object” columns to your Data Tables. These can store strings, numbers, lists, or dicts - that’s any JSON object. And you can search inside them with a powerful query system.
Find out more on our blog: https://anvil.works/blog/simple-object-storage
3. Looking after the details
Here are some things we’ve done this month to make Anvil even more pleasing to use:
Easier code navigation - you can hold down the Ctrl key and click on a function or variable to jump to its definition.
The new FlowPanel lets you lay out components side-to-side. It’s great for grouping buttons, links or labels right next to each other.
We’ve made it easier to drag and drop Link components, so it’s clearer whether you’re dropping something next to a Link or inside it. (I love this when I’m building sidebars for navigation!)
More options for displaying images in Image components: Shrink to fit, zoom to fill, or display your image at its original size no matter how big your page is.
Want your components closer together, or further apart? Now you can control the spacing in a ColumnPanel with the
We’ve made the Toolbox easier to navigate by highlighting the most commonly used components.
Fixed-width layouts are easier now too, with the XYPanel. Most of the time, you won’t be needing a fixed-width layout, but when you do, it’s right there.
The Web is traditionally a pain to program. It's also seriously un-Pythonic.
At PyCon 2018, I asked: Can we make Web programming easier, by making it more Python-shaped?Scroll down for transcript
Well, to start with, what do I mean by "the web is un-Pythonic"?
Think about a typical web app. You're going to have to turn your data into a bunch of different shapes along the way:
At each of these boundaries, a bunch of boring and repetitive translation work happens. And that is an invitation to exactly the wrong sort of magic.
Let's take an entirely unfair pot-shot at SQLAlchemy, which is a library that manages the transformation of an SQL database into Python objects (and back). It's actually really good at it. You can even write neat query expressions like this:
Of course, the process of turning that Python expression into SQL is black magic. It involves metaclasses, and overloading standard Python operators to do something completely different to what they normally do.
And that's cool, if you do it once. But if you have this amount of magic at every boundary in this stack, you're setting yourself up for a bad time.
But of course, that's exactly what we do:
And they're all extremely leaky abstractions! To be a reasonably advanced user of any of these frameworks, you need to understand everything they do, on both sides of the transformation.
Aside: This is a leading cause of the "Framework of the Week" anti-pattern. You have a tool which is inherently unsatisfactory, because it's spanning one or more of these transitions and suffers from all these impedance mismatches. And just in order to use this tool, you need to know more or less everything you need to build one yourself. This presents an irresistible temptation. But of course the new one still isn't quite right...and around and around we go.
So, how does this situation stack up against The Zen of Python?
"There should be one obvious way to do it"?
Hoo, boy. Look at all these frameworks!
"If you can't explain the implementation, it's a bad idea"?
Again, look at the sheer amount of magic in every level of this stack!
OK, so if we're in Python, and making an HTTP request to a Python server, what happens?
Well, we make a function call into the
requests library, and then some time later it emerges as a function call to a Flask endpoint.
Wait a second. If a function call was all we wanted, why not explicitly turn the whole thing into function calls?
So that's what we do. Have a function on the server, decorate it with
@anvil.server.callable, and call it from the client with a function call.
Now we can pass arguments (even keyword arguments), and return values from the function. We don't have to marshal everything into an HTTP request any more — it's just a Python function call.
(The data still passes over HTTP, of course. Actually, we use an encrypted WebSocket.)
OK, so the next question is, "What sorts of data should you be able to pass into, or return out of, these functions?"
Well, strings, numbers, dicts, and lists are easy. That's just JSON. But we want to avoid translations, so we want to pass proper objects from the server to the client.
Unfortunately, this is a web server, serving lots of clients, so it has to be stateless: the server just can't afford to keep these objects in RAM.
So we support passing a special sort of object: a stateless server object.
What's in a stateless object? Well, it has an immutable ID, some method names, and some permissions. That's all. (So there's nothing else the server has to remember.)
We can call methods on this object from the client: it's just a server function call, like we saw on the last slide. We make sure the client can't call methods on arbitrary objects by signing the ID and permissions, and requiring that signature to call a method on an object. So the client can only call methods on an object that has been returned from a server function.
An excellent use case for this is...database rows! The object's ID is the unique ID of that row in the database; the methods are things like
delete(). And by implementing
__setitem__(), we can even use square-bracket lookup to get and set column values.
If we put this together, we can:
We've skipped a whole bunch of these translation steps! We've got one object, passed all the way from the database to client code.
And that's a little contribution to making the Web more Pythonic.
For more about Anvil, check out https://anvil.works.
Thank you very much.