YC PROTOTYPES #2: BUILDING MAGIC IN 2.5 HOURS 23rd of March 2018
(/blog/yc-mvp-magic)
Day 2: Let’s make Magic (YC W15) It’s Y Combinator’s week of Demo Days, and we’re prototyping one YC startup each day. (If you missed it, check out the first in this series (one-yc-startup-a-day), where we prototyped an e-parking service in an hour and a half.) Magic (https://getmagic.com) (YC W15) is an SMS concierge that can do anything. Text them a request, however outlandish, and they will make it happen. Let’s put ourselves into the founders’ shoes, when they were just starting out. We don’t know if anyone wants this service, so we need a working product they can use. What do we need to build? We need to see and respond to texts from our customers. We need to charge customers for the things we provide (with a commission, of course). They shouldn’t need to enter their credit card every time. We need to share this work between several people. With Anvil (https://anvil.works), it turns out we can build this all in a couple of hours. Watch me build a fully working product in this time-lapse video, then scroll down for the play-by-play:
1. TWO-WAY CONVERSATION (45 MINS) We use Anvil’s built-in data tables (/doc#data_tables) to store customers and events (messages, notes, etc), and build pages to display them. We use the Users service (/doc#users) to authenticate operators (ie us). Within half an hour, we’ve got the basics: We can receive SMS using an HTTP endpoint (/blog/http-apiendpoints) from a service like Twilio, display the conversation, and send replies. (img/yc-mvps/magic/first-conversation.png)
2. TAKE PAYMENT (45 MINS) Now a customer can ask for something, we need them to pay for it! To make purchases truly frictionless, we’ll take their credit card once, then keep it on file for anything they need in the future. Anvil’s Stripe support (/blog/stripe) makes this simple. We make an app to collect the customer’s card details, and then we send them a link to open that app on their phone:
(img/yc-mvps/magic/charge-btn.png) (img/yc-
mvps/magic/request-payment-details.png)
After that, the card is on file, and we can charge them at the click of a button. (We also note our profit margin for future reference.) (img/yc-mvps/magic/charge-dialog.png)
3. COORDINATE MANY OPERATORS (50 MINS) If this app takes off, we’ll need help. We don’t want any messages to fall through the cracks, so we text all our operators when a new customer arrives. But we don’t want to notify every operator about every message – they’ll get drowned! Instead, let’s track which customers need attention, and let operators “claim” customers. (We make sure two operators can’t claim the same customer by accident.)
(img/yc-mvps/magic/claim-customer.png)
(img/yc-mvps/magic/claimed-customer.png)
The operator can mark a customer as Done (request resolved, no longer needs attention), or Can’t handle (still needs attention – “un-claim” the customer and text other operators for help). If we need more information from the customer, the operator can select “Tell me when they reply”. The operator can go do something else: when the customer replies, we send an SMS to this operator only.
PROTOTYPE COMPLETE (2 HOURS 20 MINUTES) We’ve built the infrastructure for an SMS concierge in just a couple of hours. We can help people by text, take payment, and even coordinate a large team of operators if it suddenly gets popular (https://www.wired.com/2015/02/magic-the-startup/). It’s a fully-working product that can take revenue right away, and scale as we grow. Here’s how our final app works:
You can grab the source code yourself – click below to open the apps in the Anvil editor:
Want to dig into how these apps work? Our tutorials (/learn) show you all the pieces these apps are made from, and more.
HOW WE'RE BUILDING ONE Y COMBINATOR STARTUP A DAY 20th of March 2018
(/blog/one-yc-startup-a-day)
Prototyping a YC Startup Each Day Check out Part 2 of this series > (yc-mvp-magic) It’s Y Combinator’s Demo Day this week, when the startup incubator’s graduates show their products to the world. To mark the occasion, we decided to try a challenge: How much time does it take to prototype a startup? For each Demo Day this week, we’ll build a working prototype of a startup from a recent YC batch. “Working” means more than a landing page – we want enough technology to provide the core service to the customer, and to get paid for it. Our secret weapon is Anvil (https://anvil.works/). It’s a platform for building web apps without the fuss: it’s got a visual interface designer, client- and server-side code is all in Python, and it deploys to the cloud with one click. We’ll walk you through the design process, show you some screenshots, and give a breakdown of how long each stage took. Today, we start with:
1. METER FEEDER (YC WINTER 16) Build time: 1 hour, 30 minutes. We’re moving to a cashless world, but urban infrastructure is slow to change. Meter Feeder (https://meterfeeder.com) lets you pay for parking with your smartphone, without costly new infrastructure. Imagine we’re the Meeter Feeder founders: We need to build a working prototype that we can demonstrate to a city government, and deploy as a proof of concept. This means: The public (customers) need to be able to pay for their parking. Traffic wardens on patrol need to know whether a car’s parking has expired. Let’s fire up Anvil, and see what we can do.
DESIGN THE DATA MODEL (10 MINS) We’re going to break up parking into “locations”. We’ll identify a location with a number, which can be entered easily on a phone keypad, and displayed on legacy parking infrastructure (translation: put a sticker on the physical parking meter). Each location has a cost for a given unit of time, and a maximum stay (eg “$0.50 per 15 minutes; max stay 2 hours”). We then create a table of “bookings”, which represent payment for a car to park in a location. Finally, we add user records (with Anvil’s built-in user authentication (/blog/multi-user-apps)), and link each booking to the user who made it. This is all pretty quick to set up with Anvil’s Data Tables (/doc#data_tables):
(img/yc-mvps/tables-locations.png)
(img/yc-mvps/tables-bookings.png)
DESIGN THE PUBLIC INTERFACE (30 MINS) Collecting payment is pretty straightforward with Anvil’s Stripe integration (/blog/stripe). Collecting the registration plate number and parking duration is even simpler. But parking your car is a frequent event, and we don’t want to make the customer re-enter this information every time. What’s more, after a user has paid for parking, they’ll want to check back and see how much time they have left. So the first thing we do on app load is trigger the login/signup screen. (We use the “Remember me” option, so regular users never have to see it again.) Once we’re logged in, we can find and display your recent bookings. We also offer a quick “park here again” button to repeat an expired booking. If you choose “New Booking”, we prompt you to enter a location code, or pick from a list of locations you’ve booked recently. The next screen has big touch-friendly buttons for choosing your time and entering your registration. If there is a Stripe record associated with your account, we show a “pay with the same card as last time” button. Thanks to the “Park here again” button on the first screen, a returning user can park somewhere they’ve used before with only two touches. (img/yc-mvps/design-ShowBookings.png)
mvps/design-ChooseLocation.png)
(img/yc-
(img/yc-mvps/design-ChooseTime.png)
BACK-END LOGIC (25 MINS) This is the back-end to make all those buttons work. This ends up being a 60-line server module, exposing four functions - “get my recent bookings”, “get a location record for this number”, “get the last licence plate I parked with”, and “pay for parking”. Wiring these up to the front end didn’t take long, because Anvil lets you return live database rows into client code, and then use data bindings (/blog/announcing-data-bindings) to display them in the UI.
ENFORCEMENT APP (15 MINUTES) (img/yc-mvps/enforcement.png) After all that, the enforcement app came together pretty quickly. It’s a private app, so we can skip the user authentication and make the Locations and Bookings tables readable directly by client code. When a parking warden arrives at a new location, they can enter the location code to display all valid bookings for that location. We also support as-you-type searching by licence plate number, so they can query a single plate in a busy location.
THAT’S ALL, FOLKS! (1 HOUR 30 MINUTES) We’ve built a working, deployable prototype of the MeterFeeder service, in an hour and a half. If we were the MeterFeeder founders, we’d be feeling pretty good by now - we’ve got a compelling demo, without spending weeks or months getting this far. This means we can move straight on to the hard part: selling the concept to local government. You can see the source to these apps yourself – click to open them in the Anvil editor:
PUBLIC APP (HTTPS://ANVIL.WORKS/IDE#CLONE:3QKBUMRUUJUYY23Z=GNBGQIVMOFI3B32TJ676SAT5) ENFORCEMENT APP (HTTPS://ANVIL.WORKS/IDE#CLONE:SJRB765XJGJNBOZ2=XSKDEMAEKGR6ZYNB2XARRSSP)
Want to dig into how these apps work? Our tutorials (/learn) show you all the pieces these apps are made from, and more.
LIVE CODING A STOCK PORTFOLIO APP 31st of January
(/blog/live-coding-stock-portfolio)
OVERVIEW In this live-coding video, you will watch me prototype a financial "Software as a Service" (SaaS) application in under an hour. At the end of this video, we will have an application for tracking stock prices. It has user accounts, per-user portfolios, and a monthly credit-card charge for using the service. Follow along as we start from a single stock chart and build up to a full subscription service. You can also copy the source code and explore it yourself:
Encrypted Storage, Made Easy. When your web app is handling sensitive information — be it API credentials, database passwords, or sensitive personal data — it’s important to keep it protected. It certainly shouldn’t be sitting in your source code, for anyone to see. It should be kept encrypted, until the time it’s needed. This is called encryption at rest. With Anvil, you can store password or API keys encrypted in your app, with a name – for example, I could store my GitHub password in a secret called github_password . Then I can use it in my app, like this: username = "meredydd" password = anvil.secrets.get_secret("github_password") r = anvil.http.request("https://api.github.com/user/repos", json=True, username=username, password=password)
I can also create and store an encryption key, and use it to encrypt and decrypt data. Encrypted-at-rest data storage is this simple: # This app has an encryption key named 'my_key': @anvil.server.callable def save_secret_data(new_text): encrypted_text = anvil.secrets.encrypt_with_key('my_key', new_text) app_tables.secret_data.add_row(text=encrypted_text)
Watch our video tutorial here, or read our API documentation
(/doc#secrets):
TRY IT YOURSELF (/IDE)
HOW IT WORKS App Secrets are encrypted, and stored with the source code for your Anvil app. Secrets and keys are encrypted with a key unique to that application – making the encrypted value useless outside that app.
All encryption is performed with high quality, industry-standard encryption schemes that avoid the pitfalls of using low-level cryptographic libraries. For more details, see our documentation . (/doc#secrets) We believe security and privacy are important, and we are proud to empower our users to use cryptography easily and safely. We are grateful to the security and privacy researchers who have helped us develop and validate this feature, and we welcome contact from the security community at [email protected] (mailto:[email protected]).
BUILDING A PYTHON AUTOCOMPLETER 8th of November, 2017
(/blog/python-autocompleter-pycon17)
Auto-completing Python on the Web Why do you need autocompletion, and how does it work? My talk at PyCon UK 2017 (http://2017.pyconuk.org/) explains how – and why – we built an in-browser autocompleter for Anvil. Watch it below, or scroll down for a transcript:
(/)
(http://skulpt.org)
For more information about Anvil, check out anvil.works (/).
For more information about Skulpt, check out skulpt.org (http://skulpt.org).
Transcript: I'd like to start by taking some time to thank the PyCon UK organising committee. This has been our first time sponsoring PyCon UK, and we've been made to feel very welcome.
We make Anvil (https://anvil.works/) – it's a tool for building full-stack web apps with nothing but Python. We did this because we think we can make a better developer experience using full Python than using the traditional tools. And autocompletion is part of that.
Having proper code completion gives you discoverability. It lets you explore the APIs, without having to tab to the documentation all the time. It gives you speed, because you go a lot faster when you can hit the Tab key every few characters. It gives you confidence that what you're doing is right, because there are whole classes of bugs you can fix without even hitting the Run button. And it just feels good to use. We started out thinking we could make a good developer experience without autocomplete. I'm here to tell you that we were wrong.
If you don't use autocomplete yourself, you might not know what you're missing. I really encourage you to try it out. Even if you spend all your days in a terminal with vim or emacs, you can get Jedi as a plugin. Really, just try it for a week. See what happens. You'll be amazed.
Unfortunately, Jedi wasn't quite what we needed. Earlier I said Anvil was "full stack", and that means that it knows about everything from your database tables...
...to your server-side code...
...to your client-side code. And it's got to autocomplete all of them. What's more, Anvil is web-based, and Jedi is expecting a filesystem. And when you're hitting the Tab key, there's just not enough time to go back to the server to fetch your completions. So we had to write it ourselves, in Javascript. Which means that, yes, here I am, talking about my Javascript project at a Python conference. (Please save the rotten fruit until after the photos at the end.)
So, what do we do? Conveniently, because Anvil runs all your client-side Python code in the browser, we have a Javascript parser for Python just lying around the place. (We use the open-source Skulpt (http://skulpt.org) project.)
So we can take your code, insert a random symbol at your cursor position, and then feed it to the Skulpt parser. The parser then produces an abstract syntax tree that represents your module. We can then recursively walk this tree, and build up a representation of what's in scope at any given point in the code. We actually use Javascript's prototypical inheritance for this: Inside scopes (like inside a function) prototypically inherit all the names that are in scope from outside scopes (like the module globals).
And when we hit a Name node that contains the magic cursor symbol, we can just suggest all the things that are currently in scope.
That's not the only thing we want to autocomplete. For example, you can access Anvil's database rows like dictionaries, using square brackets (aka __getitem__ ). So we have to store which items are available on each type. We also compute and store what you get if you iterate over an object, what its attributes are, what you get if you call it as a function, and so on.
Speaking of function calls, we also need to infer between modules. For example, in Anvil you write your server code in Python, and you call it from the client with a Python function call. And if you pass something into that server code, you want to be able to autocomplete it inside that server function. So, as well as saving the top-level scope of every module (so it can be used in import statements from other modules), we also store every outbound call from a module – including calls to the server. So when we parse this client code, we store this outbound call, along with the types of its arguments. And then when we're parsing the server code for autocomplete, we can just pull out the type information for those arguments, and stick it into the local scope, where it autocompletes.
We can store a lot of information about types. This leads to a rather philosophical discussion about what, exactly, a type is. You might say, "that's easy, the type of an object is its Python class". But of course, in Python, you can dynamically add attributes to individual object instances. And, arguably, even two dicts aren't really the same type. So what we actually do is mostly forget the Python class – our autocompleter is ducktyped. As far as we're concerned, these two dictionaries are two separate types, with separate item mappings, and should be treated as such.
There's so much more I could talk about, but this is a short talk. And so, if you remember only one thing, make it this: Ladies and gentlemen of Pycon UK 2017, use autocomplete! Thank you very much.
SMS SURVEYS IN PURE PYTHON 10th October 2017
(/blog/sms)
Telephony integration, deployed in minutes There are some great telephony services for developers out there these days. A simple HTTP call or webhook is all it takes to send and receive messages, but building and hosting a webapp to do this is still far harder than it should be. Enter Anvil, a platform for full-stack web development in nothing but Python. An SMS survey is a great example of something that should be really simple to build, so I’ll show you how I did it in just a few minutes with Anvil. First, head over to https://sms-poll.anvilapp.net (https://sms-poll.anvilapp.net) to see the finished app. You can also take a look at the source code (https://anvil.works/ide#clone:V5BISSGQWT3KHIYW=CVJFELGUV6WPIE7RTFP5HOBM) and try it out yourself.
Let’s take a quick tour through the code to see the highlights. There are two main parts: The main form, displaying voting instructions and current live survey results. The Webhook Server Module where you’ll find the HTTP endpoint that can be called for each incoming SMS. I used the excellent Nexmo API (https://developer.nexmo.com/), which makes it really simple to receive SMS messages to a custom webhook.
Receiving SMS Messages Take a look at the Webhook Server Module. You’ll see that it only took one function to handle incoming messages: @anvil.server.http_endpoint("/sms") @tables.in_transaction def incoming_sms(msisdn, text, **kw): ...
The incoming_sms function is decorated with @anvil.server.http_endpoint , which means external services can make HTTP requests that trigger the function call. After signing up with Nexmo (https://nexmo.com), I simply set the incoming webhook address to the URL of my HTTP endpoint. In my case, that URL is “ https://sms-poll.anvilapp.net/_/api/sms ” – your copy of the app will have its own URL, which you can find displayed at the bottom of the Server Module. HTTP form parameters are passed as keyword arguments to this function. We have explicitly captured the sender ( msisdn ) and contents ( text ) of the message, and used **kw to receive the other paramaters. In fact, form parameters, query string parameters and path parameters are all provided as keyword arguments – see the documentation (https://anvil.works/doc#http_apis) for more information. Inside the incoming_sms function we add a row to our data table with the details of the incoming message: app_tables.messages.add_row(sender=msisdn, time=datetime.now(), message=text)
Next we decide whether the incoming message contains a valid vote, and if so increment the appropriate total in the Results table. colours = { "A": "Red", "B": "Green", "C": "Blue", "D": "Yellow", } colour = colours.get(text.upper(), None) if colour is not None: app_tables.results.get(colour=colour)['votes'] += 1
Readers of a nervous disposition should note that the entire incoming_sms function is decorated with @tables.in_transaction , so operations like incrementing values in the database are perfectly safe. If two requests arrive simultaneously, and they try to edit the same table row, one of them will be automatically rolled back and retried. See the Data Tables documentation (https://anvil.works/doc#data_tables_api) for more details, and the Data Tables tutorial (https://anvil.works/blog/storing-data) for examples.
Displaying poll results Laying out the UI for our web application takes no code at all – Anvil’s visual designer lets you drag and drop components into place until your page looks the way you want it to look. For this app, we’ll add a few containers and labels, and a Plot component for displaying the chart.
Once we’ve created the Plot component, we have the full Plotly API (https://plot.ly/python/) at our fingertips. Drawing a bar chart couldn’t be easier. Back in the main form, we query for the latest results: results = list(app_tables.results.search())
Then it’s just a matter of creating a Plotly Bar Chart object, and populating it with our results. Notice that we use list comprehensions to assemble the necessary data for each axis: # Create a Plotly Bar chart with colours along the x-axis # and number of votes on the y-axis. self.results_plot.data = go.Bar( x=[v['colour'] for v in results], y=[v['votes'] for v in results], width=0.5, opacity=0.6, marker=go.Marker( # Set the colour of the bar to the colour being voted for color=[v['colour'].lower() for v in results], line=go.Line( color="#888", width=1 ) ) ) # Set the axis and plot labels self.results_plot.layout = go.Layout( yaxis=go.YAxis( title="Votes", # Start y-axis ticks at 0 and increment by 1. tick0=0, dtick=1 ), xaxis=go.YAxis( title="Colour" ), title="Live Poll Results (%s votes)" % sum([v['votes'] for v in results]) )
The final piece of the puzzle is to make the chart update live. For this we use a Timer component on the form, and set its interval to 1 second. In the tick event handler, we simply call the method to redraw the plot.
Ready to go And there you have it. A complete SMS polling app, built and deployed in no time. Anvil lets you build great apps on top of great APIs (like Nexmo) without any of the hassle traditionally required for web development.
SEE THE CODE (HTTPS://ANVIL.WORKS/IDE#CLONE:V5BISSGQWT3KHIYW=CVJFELGUV6WPIE7RTFP5HOBM)
NEW: MEDIA IN DATA TABLES 5th of October 2017
(/blog/announcing-table-media)
Store files in Data Tables. Why not? We’re used to storing text and numbers in databases, so why not binary media? Whether it’s images, PDF files or whole spreadsheets, now you can store your files directly in Anvil Data Tables like any other data type. Just create a Media column in your table:
Create rows in your table by uploading files:
And view or download the media objects directly from the database:
A Media object from a table row behaves just like any other Media object in Anvil - you can assign it to the source property of an Image component, get its URL, or even get its contents as a binary string with the get_bytes() method. See the reference documentation (/doc#media) for more details.
TRY IT YOURSELF (/LOGIN)
NEW: DATA BINDINGS 21st of September 2017
(/blog/announcing-data-bindings)
Design your data right onto the page Let’s say you’re writing a web app, and you need to display and edit some data. Wouldn’t it be great if you could drag and drop to design how your page looks, and where the data goes? Especially if we kept the power and flexibility of writing real code? We thought so too, and today we’re proud to announce Anvil Data Bindings:
Loading video...
WATCH THE TUTORIAL (/BLOG/STORING-AND-DISPLAYING-DATA)
Data bindings extend Anvil’s visual designer. As well as positioning your components on the page with drag and drop, you can now set component properties to any Python expression. You can even assign updated values to this expression when you change your component. Finally, today we are also introducing the RepeatingPanel. This makes it easy to repeat components for every element in a list - now, displaying items in a table or list is a snap! You can find out more about data bindings with the tutorial (/blog/storing-and-displaying-data). You can also read the reference documentation (/doc#data_bindings).
BUILD A BUSINESS DASHBOARD WITH PYTHON 22nd of August 2017
(/blog/dashboard)
You make what you measure. — Joe Kraus
Dashboards in Python: Visualise Your Performance Business is like driving - what you’re looking at is what you steer towards. A dashboard is a way to make sure you’re looking at the most important parts of your business. The good news is that they’re quite straightforward to build – especially if you have Python to help you. I’m going to put the goodies up front, for the geeky and impatient. This is a video of me building a dashboard that pulls data from a business database, and displays it on the web. Watch it now, or read on as we take a step-by-step guide to creating your own business dashboard.
SEE THE CODE (HTTPS://ANVIL.WORKS/IDE#CLONE:VCXTXA4LJBGZX6HB=PQLVYFBS5TBWWNFPRGGH7O7N)
SO, HOW DO I DO IT?
Step 1: Ask the right question This is the most important part of measuring your business. You have to ask yourself what information is so important, you should see it every morning. When you’re building a business, the most important questions aren’t always obvious. There are some great guides out there. I’d recommend Startup Metrics for Pirates (https://www.slideshare.net/dmc500hats/startup-metrics-for-pirates-long-version) (not just for start-ups!), and Adam D’Angelo’s talk on measurement (https://youtu.be/zsBjAuexPq4?t=24m10s) from Y Combinator’s Startup School. Broadly, though, there are two sorts of questions: Strategic metrics that show you where you want to go, like user acquisition rate, retention, or revenue growth; and tactical metrics that monitor how you’re getting there, such as A/B tests and short-lived marketing initiatives. At very least, you should have a dashboard that shows you your strategic metrics, and how they compare to historical performance.
Don't be afraid of hard questions. Sometimes, the answer you need is right there in your database, and all you need is to query it. It's great when that happens, and we'll cover this simple case in our walkthrough. But it's often more complicated than that: Perhaps you'll need data from your application database, your CRM system and an external analytics provider. Because we're using Python to compile the data for our dashboard, we have the flexibility to do that. So you have no excuse: Don't measure the wrong thing, just because it's easier.
Step 2: Get the answer from your database Let’s imagine we’ve thought about it, and decided that our primary business concern is acquisition: How many new users are we signing up, and how is that changing from week to week? For 99% of online businesses, this information will be in an SQL database somewhere. Connect with your command-line tool of choice, and write your query. Our example table looks like this, using Postgres: myapp=> \d users Table "public.users" Column | Type | Modifiers -------------+-----------------------------+---------- id | integer | email | text | signup_date | timestamp without time zone |
A little trial and error, and we have a query that gives us the number of user sign-ups by week, for the last three months: myapp=> SELECT COUNT(*), DATE_TRUNC('week', signup_date) AS d FROM users WHERE signup_date > NOW() - INTERVAL '3 months' GROUP BY DATE_TRUNC('week', signup_date) ORDER BY d;
Step 3: Put it online We want to make this data visible on a web page. Anvil (https://anvil.works/) lets us create web apps with nothing but Python. We’re going to create an Anvil app: It will have a server module that uses the standard Python tools to extract the data from our database, and a client-side page to display it on the web (also in pure Python). To connect to a Postgres database, we use the standard Psycopg2 (http://initd.org/psycopg/) library. We create a server module and write: import psycopg2 conn = psycopg2.connect("host=db.myapp.com dbname=my_app user=postgres password=secret")
Now, we want to run that SQL query on demand. We’ll define a function that gets our data and returns it as a list: @anvil.server.callable def get_user_signups(): cur = conn.cursor() cur.execute(""" SELECT COUNT(*), DATE_TRUNC('week', signup_date) AS d FROM users WHERE signup_date > NOW() - INTERVAL '3 months' GROUP BY DATE_TRUNC('week', signup_date) ORDER BY d; """) return list(cur)
We’ve marked the function @anvil.server.callable . That’s all we need to make it accessible from clientside code when we build our web page. (No web server required!)
Calculating complex metrics Remember earlier, when we said you probably want more than just a user count? This is where Python shines. Cross-reference with a NoSQL database. Query your CRM via its API. Run statistical models with NumPy. Python is the swiss army knife of data analysis – why wouldn't you use it for your dashboard?
Step 4: Draw the plot All that’s left is to display this data as a graph in our web app. We open Anvil’s visual designer and add a Plot component (/blog/plots) to our app’s main page. When the app opens, we call the query function we’ve just defined, and construct a line graph with the data: signups = anvil.server.call('get_user_signups') # Anvil plots use the Plot.ly API: https://plot.ly/python/#basic-charts scatter = go.Scatter(x = [signup_time for (count,signup_time) in signups], y = [count for (count,signup_time) in signups], fill = 'tozeroy')
We want that code to run when the page first opens, so we put it in the __init__ method of our form. (We also import the plot API.) Here’s the entire page source code, including the parts Anvil provides for you: from plotly import graph_objs as go class Form1(Form1): def __init__(self, **properties): self.init_components(**properties) # This code will run when the form opens. signups = anvil.server.call('get_user_signups') # Make a line plot of this data scatter = go.Scatter(x = [signup_time for (count,signup_time) in signups], y = [count for (count,signup_time) in signups], fill = 'tozeroy') # Display that plot on our page self.plot_1.data = scatter
That’s it! Here’s what it looks like, now we’re finished:
See source code in the Anvil editor (https://anvil.works/ide#clone:VCXTXA4LJBGZX6HB=PQLVYFBS5TBWWNFPRGGH7O7N)
Step 5: Actually watch it It feels silly to say it, but I know from personal experience: A dashboard you don’t look at is as bad as no dashboard at all. It’s actually worse, because knowing it’s there gives you a false sense of security. Set your dashboard as your home page - or if you have a spare screen, display it in the corner of your office. And then, when it tells you something interesting, you might actually react!
I hope you’ve found this guide helpful. You can follow us on Twitter (https://twitter.com/anvil_works), or email me any questions or comments at [email protected] (mailto:[email protected]). Finally, you can see the full source code for this example here:
SEE THE CODE (HTTPS://ANVIL.WORKS/IDE#CLONE:VCXTXA4LJBGZX6HB=PQLVYFBS5TBWWNFPRGGH7O7N)
INTERACTIVE PLOTS FOR YOUR APPS 26th of July 2017
(/blog/plots)
New: Graphs and charts for your Anvil app Python is the world’s favourite language for data processing and visualisation – and when you use Anvil (https://anvil.works/), Python is all you need to build web apps. Today, we’re making it even easier to present your data on the web. You can now offer interactive charts right inside your Anvil apps, built and customised in just a few lines of code. The new Plot component is powered by the Plotly Python API, so you have a wealth of examples already online to get you started. Plots like this are simple to create, and simple to customise:
(https://anvil.works/ide#clone:BGKCEXCMQATZDP24=NZ7L635BYGIEP5SY7HJUQSO2) You can open this example in Anvil (https://anvil.works/ide#clone:BGKCEXCMQATZDP24=NZ7L635BYGIEP5SY7HJUQSO2) right now, or read the docs (https://anvil.works/doc#plot) to learn more. You can also find more examples in the Plotly library docs
(https://plot.ly/python/#basic-charts).
TRY THIS DEMO NOW (HTTPS://ANVIL.WORKS/IDE#CLONE:BGKCEXCMQATZDP24=NZ7L635BYGIEP5SY7HJUQSO2)
HTTP ENDPOINTS FOR YOUR APPS 17th of July 2017
(/blog/http-api-endpoints)
New: Make an API for your Anvil app Sometimes we want to connect other programs with our Anvil apps. Whether it’s a native mobile app, a shell script, or a web service like Twilio, most things expect to make REST or plain HTTP requests. As of today, this is all it takes to publish an HTTP API that returns some JSON: @anvil.server.http_endpoint("/greet/:name") def greet(name, **qs): return {'message': 'Hello, ' + name + '!'}
We can demonstrate it with the curl command-line program: $ curl https://http-endpoint-demo.anvilapp.net/_/api/greet/Joanne {"message":"Hello, Joanne!"}
You can open this example in Anvil (https://anvil.works/ide#clone:QFNEHKNZK2HXDBNS=3TGUZRUNGRTO6BWX2HSUK4BQ) right now, or read the docs (https://anvil.works/doc#http_apis) to learn more.
TRY THIS DEMO NOW (HTTPS://ANVIL.WORKS/IDE#CLONE:QFNEHKNZK2HXDBNS=3TGUZRUNGRTO6BWX2HSUK4BQ)
MAKE THE WORLD BETTER? REMOVE SOME JAVASCRIPT. 27th June 2017
(/blog/pycon-talk)
Compiling Python to Javascript To write full-stack web apps in nothing but Python, you need to run Python code in the browser. Watch my talk at PyCon 2017 (https://us.pycon.org/2017), or scroll down for a transcript:
For more information about Skulpt, check out skulpt.org (http://skulpt.org). Or you can check out the pull request (https://github.com/skulpt/skulpt/pull/286) that implemented these changes.
(http://skulpt.org)
Transcript: Back when my friend Ian and I were idealistic students, we sat down and decided to make the world a better place, as you do. And we decided that the best way two developers could make the world a better place was to remove some Javascript from it. The web is the greatest application delivery platform on Earth, and frankly it’s a stain on our profession that you need to know five different programming languages and three different frameworks if you want to make it do anything. Really, all you should need is to be able to code - ideally, in a friendly, readable language that’s easy to learn and isn’t full of unpleasant surprises.
There was an obvious candidate. So, we built a tool for building full-stack web applications with nothing but Python.
We built a graphical interface builder for designing your pages, and let you write your client-side code in Python - so all the buttons, text fields etc you put on your page are just Python objects. We built a back-end server environment, also in Python, and a database with a pure Python API, all deployed in the cloud in one click. But today I want to talk about this front-end code. If you want to drive the items on your web page as pure Python objects, you’re going to need to run Python in the browser. If you’re going to run something in the browser, it’s going to have to be in Javascript.
Thankfully, there’s a great open-source project called Skulpt, that compiles Python to Javascript. So you can write Python to drive your app, and we can compile it to Javascript so that when you publish it online, your code actually runs in a user’s browser. We give Skulpt Python objects, it represents them as Javascript objects. We give it a Python function, and it produces a Javascript function for the browser to run. There is a problem, though. Javascript, in its infinite wisdom, is 100% non-blocking. If you kick off a process that finishes later, you’d better provide a callback.
Here’s some code you might write in Python. Go get a record from the database, and if it’s not there, throw an error. And here’s how you’d do it in Javascript. I count three separate callbacks here. I’m not exaggerating - this is an example straight from the documentation of the postgres library! OK, so we have a Python-to-Javascript compiler, and it’s open source. What if we could turn this into this, automatically?
So, we go "git clone", and start exploring. It turns out that Skulpt has a classic compiler architecture, modeled quite closely on CPython: There’s a parser that turns Python code into a parse tree (these are all the files in the Skulpt source tree, by the way, if you want to follow along).
Then it walks over this parse tree and makes an abstract syntax tree, which is made of elements you might recognise - like variable assignments, function definitions, function calls, and so on. Then there’s a compiler that then walks this syntax tree and spits out Javascript.
So, this is what we need to modify to implement blocking code. We invent a new Javascript class that a function can return, to say “hey, I’m returning, but I’m not done yet; I’ve just blocked”. We call this a suspension. So, when we’re compiling the AST, wherever we’re compiling a function call, we generate Javascript code that calls the function, and looks at the return value, and says, "is it a Suspension?". Because if it returned a Suspension, we’re blocking - and I'm going to have to suspend myself. We save all our variables and temporary values, our exception state, and where we are in the function, and then we return our own suspension with all that information in it.
And so our caller will recognise that we have suspended, and so it's going to have to suspend as well, and so on all the way back to the Javascript runtime.
When that operation completes - say the database gives us a response - we resume the Suspension. We call our function with the suspension, which then restores all our variables, jumps to the right place and resumes the original suspension, which restores all of its variables, and so on, until we can resume execution as normal. So, that’s how we take simple blocking Python, and compile it into non-blocking Javascript so you don’t have to.
This has been a quick overview; if you’re interested you can check out Skulpt at skulpt.org (http://skulpt.org) - I’m one of the maintainers now, and we’re always looking for new contributors. And if you're fed up to the back teeth with all this Javascript, and you want to forget it all and write full-stack web apps with nothing but Python, please check us out at www.anvil.works (https://anvil.works). Thank you very much!
SMART PYTHON CODE COMPLETION 15th of February 2017
(/blog/autocomplete)
That's right. It's here.
Every coder knows the pain: You know what you need to do, but you can’t remember the name of that function, or what order it takes its parameters. It’s time to fix that problem. We are excited to announce that from today, the Anvil web IDE includes smart code completion. Anvil knows about your forms, your components, your variables - even your data tables. Now we’re giving that information to you in real-time, as you type. Our API documentation (https://anvil.works/doc) is great, but the best docs are the ones you never have to look at. Code completion means the options are always at your fingertips. Smart code completion is available right now - just log in and start creating!
START NOW (/SIGN-UP)
PYTHON WIDGETS IN HTML LAYOUTS 5th October 2016
(/blog/drag-drop-templates)
Speed, meet beauty. Building a web page with drag and drop is much faster than fighting with HTML, CSS and Javascript. When we set out to build Anvil (https://anvil.works), we wanted to make it as easy to design a web app as it is to lay out a Powerpoint slide. We’ve combined drag-and-drop design with a library of prebuilt components, a built-in database and a simple Python programming environment. So far, we’re making web app development quicker and easier for people all over the world, from entrepreneurs to doctors. (Want to know more about Anvil? Read our introduction here. (/blog/introducing-anvil)) But sometimes, you need to put your best foot forward. You want to re-use your existing page design and brand assets. Or if you’re building those assets from scratch, you want pixel-perfect control over your page header. In short, you want the flexibility of traditional web design. So, we asked: What if you could have both?
Introducing HTML templates We’re excited to announce support for HTML templates in Anvil. You can choose from our menu of readyto-go templates, or use your existing web design assets. Once you’ve loaded your template, development is as easy as ever: just drag and drop Anvil components into the page, and arrange them how you like. And you can drive all these components with Anvil’s straightforward Python APIs. (No Javascriptframework-of-the-week necessary.)
TRY IT OUT (/SIGN-UP)
Custom HTML Anvil’s built-in templates make it easier than ever to produce a beautiful web app in record time. But if you know HTML, or have existing web assets, you can go beyond our built-in templates. If you’re an Anvil Pro user, you can control your page down to the pixel, with any HTML or CSS you like. All you need is a couple of special attributes to tell Anvil where you can drag and drop components.
I can code my web app in Python, and employ a web designer to help me with “the HTML/CSS. Anvil is without a doubt the easiest and fastest way to bring my app to life! ”
— Peter, Startup founder (Yes, he actually said this)
Here’s all you need to build a drag-and-drop layout. You just need to specify where each group of components goes, and where to drag-and-drop them:
(Want to know how that works? Check out our documentation (/doc#html_templating).) And here’s how it looks in action:
Available now To build an app with Anvil templates, sign up (/sign-up) and try some of our examples, or start from scratch. We’ve got lots of video tutorials (/learn) to help you out. If you’re into DIY, our reference documentation (/doc#html_templating) describes how to use your own HTML and CSS with Anvil.
The configuration dilemma As developers, almost every app we write has configuration. Often, that configuration should really be accessible to our less technical colleagues: feature flags, rate limits, deployment signoffs, and so forth. However, these changes also need to be tracked and audited. “The app just broke. Did someone change the config?” “Quick, revert it to last week’s settings!” As programmers, we know exactly the right tool for this: Text files in version control. They’re diffable, trackable and comprehensible, and if anything goes badly wrong we can dive in with a text editor. The problem comes when we present this solution to our non-technical colleagues. “So, I open the terminal? And then I type git clone and a string of gibberish you made me memorise?”
(https://xkcd.com/1597/)
It’s tempting to give up and say, “I’ll do it for you”. Developers end up as gatekeepers, with every change coming through us. This isn’t great either. Years ago, I used to develop SMS-based services for a mobile carrier in south-east Asia. This was the bad old days, before Twilio and friends, and the carrier had to sign off on every minor UI change – often at the very last minute. I spent many late nights waiting for a meeting on the other side of the world to finish, just so I could change one line in a config file.
GitHub API to the rescue We can fix this. With the GitHub API (https://developer.github.com/v3/), we can build an app in minutes that empowers our colleagues to change configuration on their own – with all the power of Git’s versioning and auditing. Here’s a simple app, hosted on Heroku (source at github.com/anvil-ph-test/edit-demo (https://github.com/anvil-ph-test/edit-demo)). It has a configuration file (called config.json ) that determines vital parameters such as the font and background colour.
Refresh
Please enter your name: Say Hello
Open in new tab
(https://morning-headland-63089.herokuapp.com/)
Here’s how I built an Anvil app to edit that configuration, with less than a dozen lines of code:
Getting the config First, we need to grab the latest version of our config file: self.gh_record = anvil.http.request("https://api.github.com/repos/anvil-ph-test/edit-demo/c ontents/config.json", json=True, username="abc", password="123")
Github returns some information about this file, and its content in base64: { "name": "config.json", "encoding": "base64", "size": 67 ...several other bits omitted... "content": "eyJ1cHBlcmNhc2UiOnRydWUsImZvbnQiOiJIZWx2ZXRpY2EiLCJiYWNrZ3Jv\ndW5kIjoiYmxhbmN oZWRhbG1vbmQifQ==\n", "sha": "bfb17ee5edf43a54f6756f032603872ca7dce320", }
The content is what we care about: self.item = json.loads(base64.b64decode(self.gh_record["content"]))
The decoded data looks like this: { "background": "blanchedalmond", "font": "Helvetica", "uppercase": true }
All we need now is to design our configuration interface. With Anvil’s data bindings (https://anvil.works/doc#data_bindings), it’s all drag-and-drop - we can just specify which JSON key (in self.item ) each text-box or check-box corresponds to. That’s all we need for a read-only interface:
See source code for this app (https://anvil.works/ide#clone:VQCJ2FA53XBJAHQQ=QOC34HWBQ73FL4M34GVY6YTK)
Committing our config Now we have read-only access to our configuration, the next step is to save our changes. As we interact with the text-boxes and check-box, self.item is automatically updated. Now we just push this data back to the server, with an HTTP PUT request to the same URL. All GitHub needs is the new content for the file, a commit message, and the previous SHA hash of this file: new_record = {'content', base64.b64encode(json.dumps(self.item)), 'message', 'Edit from the web'} 'sha': self.gh_record["sha"]} anvil.http.request("https://api.github.com/repos/anvil-ph-test/edit-demo/contents/config.js on", method="PUT", data=new_record, json=True, username="abc", password="123")
And here’s the working app. Why not try changing some settings?
See source code for this app (https://anvil.works/ide#clone:HWXTRQXTLJMXJEM2=S7KOIA2QBEJB4LTCNCS2A24Y)
Once you’ve saved your changes, scroll up and refresh the example app. Be patient - it may take a few seconds to re-deploy with the new config.
Increased security OK, we’re not quite done. So far, we’re doing everything on the client side, which means everyone with the URL can access our authentication information! Even if we only give that URL out to people we (mostly) trust, it’s far too easy for it to end up in the wrong hands. Instead, we’ll do our GitHub API calls on the server side, and expose only two functions to the client: save_config and load_config . All the rest is safely on the server, where the user can’t see it: # This code runs on the server @anvil.server.callable def load_config(): gh_record = anvil.http.request("https://api.github.com/repos/anvil-ph-test/edit-demo/cont ents/config.json", json=True, username="abc", password="123") return (gh_record['sha'], json.loads(base64.b64decode(gh_record['content'])))
@anvil.server.callable def save_config(data, last_sha): new_record = {'content': base64.b64encode(json.dumps(data)), 'message': 'Edit from the web', 'sha': last_sha} r = anvil.http.request("https://api.github.com/repos/anvil-ph-test/edit-demo/contents/con fig.json", method="PUT", data=new_record, json=True, username="abc", password="123") return r['content']['sha']
Copy the final app to see its full source code (https://anvil.works/ide#clone:HWXTRQXTLJMXJEM2=S7KOIA2QBEJB4LTCNCS2A24Y)
(In fact, I’ve been using this version of the code for all the example apps embedded in this blog post. I’m afraid wasn’t feeling generous enough to share my GitHub authentication tokens with anyone who can View Source. Sorry to disappoint anyone who tried.)
Job done. There you have it - a secure, functional configuration editor, ready for our non-technical colleagues to use. You don’t need to know Git to use it, but it does have full tracing and history of every change.
Conclusions #1: We don’t have to sacrifice the benefits of Git for our configuration, just in order to get a user-friendly admin interface. We can have both! #2: The GitHub API (https://developer.github.com/v3/) is awesome. #3: Anvil (https://anvil.works) lets you build useful web apps very, very quickly.
Why not clone this example app (https://anvil.works/ide#clone:HWXTRQXTLJMXJEM2=S7KOIA2QBEJB4LTCNCS2A24Y), read its source code, and try it out yourself?
VERSION CONTROL AND ANVIL 11th July 2016
(/blog/git-beta-announce)
Beta: Git access for your apps Rapid development is great, and Anvil lets you build web apps amazingly fast. But sometimes you need more. You need tracking, collaboration, code review, versioning. In short, you need source control. Today, we’re announcing beta availability of Git access for your Anvil apps. It’s simple: each Anvil app is its own Git repository. Just clone the repository, and you can pull, push, edit and merge Anvil apps right from your workstation.
Now you can collaborate on multi-person teams, manage deployment and staging environments, and integrate Anvil into your code review process. You can sign up for the beta program from the Anvil app editor. Just select Git Access from the drop-down menu, and click the button to request access.
To learn more about Anvil, watch our video tutorial series. (Or, you can sign up (/sign-up) and start building right away!)
WATCH A TUTORIAL (/LEARN)
ANVIL ON-SITE INSTALLATION 12th April 2016
(/blog/anvil-on-site)
Using Anvil behind your firewall Anvil is, by default, a cloud-hosted service. This makes it incredibly easy to create web-apps that are live in the cloud, accessible from anywhere, and integrate with other cloud services. If you’re in a corporate environment, your web app may need to access local resources. For example, you might want to use Anvil to query a database on your corporate network. For this, you will normally use the Anvil Uplink (/blog/uplink). This lets you securely give your Anvil app access to the relevant parts of your database:
The Anvil Uplink is available to all users, and does not store any data in the Anvil cloud. To learn more, watch our 4-minute video (/blog/uplink) or read our documentation (/doc/#uplink).
Sometimes, that's not enough. Certain enterprise users, however, require more assurance. For example, organisations dealing with healthcare data may not transfer patient records to third-party services without special agreements. For these users, we offer Anvil On-Site Installation. This allows you to develop and run your app entirely behind your corporate firewall, on servers you control:
An on-site Anvil installation requires no connection to the outside internet, giving you maximum assurance that your data is under your control. Anvil On-Site Installation runs as a Docker container. It typically takes less than five minutes to get Anvil On-Site working on your network - and Anvil staff will be there to help you every step of the way. If you want to run Anvil apps on your own network, please get in touch to find out more or arrange a free trial:
It's 2016. Making an interactive website should be easy, right? Not so much. Let’s say you want a site to take orders for your new widget, or keep track of your customers, or schedule your local football league. Traditionally, you’ll need to know an alphabet soup of languages and technologies: HTML, CSS, JS, PHP, SQL - the list goes on. And that’s before we start on the complex frameworks required to make them usable. This makes web development slow and complicated for professionals, difficult for other engineers, and entirely inaccessible for beginners. We need to do better than this. So we built Anvil.
Web apps made simple Anvil is a tool for making interactive websites in Python. Build your site with drag and drop, placing text, buttons, input boxes, images and more. Then double-click a button and write the Python that executes when that button is clicked. You can make something really quick this way. Watch us build a page that greets you by name, in 45 seconds flat:
Want to try this yourself? Check out our tutorials
(/learn)
Simple built-in database Anvil’s built-in database has a simple, spreadsheet-like interface for editing your data. Searching or editing it from your code is a no-nonsense Python statement. You can build a working database-backed to-do list app in five minutes - watch us do it! (/blog/storing-data) If you already have a database, no problem - Anvil can connect to that too. (For those with special requirements, we even offer an on-site solution (/blog/anvil-on-site))
Use the rest of the web No app is an island, and you shouldn’t have to build things from scratch. Anvil makes it easy for your apps to use services from the rest of the web:
Authenticate with Google login Video
(/blog/google-
Accept credit cards with Stripe
Store files in Google Drive
Video
Video
(/blog/stripe)
auth)
(/blog/photogallery)
Store data in Google Sheets Tutorial (/doc/getting_started.html)
Use local resources You might want to use something that’s only available on your network, or your computer. Perhaps you want to use your company database, or special hardware, or files stored on your computer. With Anvil, that’s a snap. Just import a library, mark the functions you want to call from Anvil, and away you go. Watch us control a Raspberry Pi from the web in three minutes
(/blog/uplink).
Try it out Anvil is free for personal use, and we can’t wait to see what you will build with it. Why not sign up for free and try it out?
BUILD AN APP (/SIGN-UP)
LEARN MORE Get the best out of Anvil with our free email course. Email address
