Project task list

Make sure you unzip the files into a directory that is in a suitable place and you'll be able to find.

It's important that you extract the files from the zip — do not start working, or editing, the files while they are still inside the archive. Be careful!

If you're not comfortable finding your way around the file system yet, see the CompSci superbasics.

Implement this by adding a new template (templates/info.html) which your app will render when /info is requested.

Your webserver uses the route to choose which function to run to generate the response: in app.py this usually renders a template, which results in the HTML that is sent back to the client (browser). In this case you want a route that matches /info to render the template info.html.

You can copy the information you need from the race server and put it into the template. It's fine to do it by hand (although there are other approaches too).

Maybe you should include the date you did this too. Why?

It's up to you What data from the specs do want to display. Maybe you can copy the whole page. Or maybe you can be selective. Do you think you should include a link to the specs page on the race server?

Putting data (for example, the cost values for different fuel types) directly into the HTML template is called hard coding it. What are the disadvantages of hard coding data like this?

You might choose not to hard code the values in your template: another place you could put them is inside app.py and then pass them into the template. What advantages does this approach have?

You could put the data in a data file and have your server read it, and pass the data to the template when it renders it. This is probably a better solution to hard coding values in Python or the template — why? If you do it this way, you need to decide when to read the file; your decision will depend on how efficient you need your program to be.

This task is good preparation for adding your poster.

You need to read the values for the existing buggy record out of the database with SQL SELECT.

Use the value attribute of the HTML's input tag.

You'll need to handle select tags' option values differently: you'll need to use the selected attribute too.

Be careful about values that might contain characters that break your HTML when you put them inside attributes in your template. How can you protect against problems?

There are two meanings of "environment" being used here: the general environment ("development" where you are making changes to your program, and "production" where you are using it), and the technical environment in which the program runs... but they are related.

In practice the main advantage of switching between development and production environments in Flask is that in the development environment the webserver should "notice" (and reload) changes to the files, so you don't need to stop-and-start the webserver every time you make an edit. But it also affects the way errors are displayed in the browser — Flask's debug mode will show a stack trace and detailed diagnostic information, instead of a bare status-code 500 error page.

This task is really introducing you to the important concept of environment variables — these are settings that are part of the environment in which the program runs instead of being inside the program. All general programming languages provide a mechanism for accessing these from within the program's source code. In Python, you should import the os module and use its environ methods: see the Python environ docs.

The environment variables are effectively presented to your program as a dictionary of string values (be careful: even the ones that look like numbers or Booleans are really strings, so you might need to cast them). Although you can access environment variables directly by keys in environ (such as os.environ['FLASK_DEBUG'] for the environment variable FLASK_DEBUG) it's usually better to use os.getenv('FLASK_DEBUG'). Why?

Environment variables are managed differently on different operating systems (which makes sense, since it's those systems which control the environment in which your program is running). So Windows and Unix/Mac set them differently (see below).

You can also choose to have different databases depending on the environment — this means you can test your code in development without risking damaging your best buggy data in the production database. That is: you do your coding and hacking in your dev environment, but switch to run in production environment when you just want to edit your buggy.

If you want to implement switching between different databases, you'll need to change how the constant DATABASE_FILE is set in init_db.py and app.py (it can't simply be the same filename — instead you'll need to use a conditional). You don't need to do this database-switching for 3-ENV, but it's great if you do (because it's a very handy technique to know when you are a developer!).

You probably need to use set (Windows) or export (Unix/Mac) — although on Unix/Mac you can also declare environment variables when you run the command: FLASK_DEBUG=True python3 app.py (but... be careful about how you use that value inside your program — is it a string or a Boolean value?)

Another way is to make a .env file and pip install python-dotenv. What does that do?

The three classic environments are development, staging, and production (you can think of staging as testing).

Setting debug=True in the source code is just one example of how some settings should not be hard-coded. Other classic examples, for programs in general, are configuration settings and passwords. This is really about understanding what is the same and what is different when you run different instances of your program. This is especially important when you think about how source code is shared, and what should (and should not) go into version control.

It's a good idea to document how the environment can be used to control the behaviour of your program in the README.md

This can be quite a complicated topic, because configuration is a big deal when you're writing programs for other people to run. See the Flask docs about configuring from environment variables to see what's possible.

This task might not result in much new Python, because it's really about how you manage your development environment. Make a note of what you did, because you can describe this in your in editor. In fact it's possible that the only change you make to app.py is to delete some code...

The API isn't published: we'll provide it when you need it.

You'll need some way of storing information about the server (including authorisation criteria) — maybe where/how to set config is related to the way you managed the email settings needed for resetting passwords (5-RESET)?

This is presumably client-side using JavaScript. You can draw shapes natively, but it's a lot of work: there are a number of drawing libraries so we recommend you use one of those.

Although it's presumably client-side... could you do this server-side, with Python? How might that work? What are the pros and cons of this approach?

The two common ways of drawing in the browser are canvas or SVG.

This is potentially — by far — the most complex of the tasks. What are the limits? A 2D rendering of a 3D model? Downloadable files for 3D printing?