Week 2 – Report writing sucks for teachers

My parents are teachers, and while they enjoy their jobs, there are aspects that just suck. And not sucks in the same way that going to the gym does, where it sucks now but makes you better in the future, but sucks just as something that is boring and pretty much unnecessary.

To expand, my ideal report card for a child would contain a paragraph or two along the lines of: “Daniel has above average ability level, but his success in class is hampered by some negative behaviours. He has also not completed all homework tasks this semester. In most subjects he has learned the core curriculum to a satisfactory extent. In Maths and English his work has been excellent, and in P.E. he has been less engaged.” Following this would be a list of grades (with some sort of meaning behind them, rather than just letters/number without explanation), and a list of the topics and skills that the student learned in each subject.

Instead, however, teachers (in the Australian public system, at least) are obliged to write a comment for each individual subject, and sometimes sub-topics of subjects. So, for example, something as banal as handwriting would get the same treatment as something as important as science or history. Kinda silly.

Problem definition

So the problem here is that teachers find themselves obliged to devote excessive time to writing comments for subjects about which there is just nothing interesting to say. As such, we want to reduce that, to give teachers more time to spend on more important aspects of their jobs.

Objective: Reduce time spent on writing report comments

Restrictions: Needs to provide enough flexibility that when actual variation between students exists, this is reflected in the report. Also needs to adapt to different situations (different subjects, different student genders).

Optional bonuses: Easy enough to use that I could send it to my parents and they could use it straight out of the box.

Potential solutions

This problem has already been tackled (see here, here and here, for example), but I want to approach it from tabula rasa rather than copying an existing solution.

  • A script for MS Word that fills in predefined text if a shortcode is typed (this functionality already exists, I’m pretty sure)
  • A program that bases comments on the student’s grade for each subject
  • A program that creates a new report for each student with template comments prefilled, including the correct pronouns and the student’s name
  • A program that suggests template comments from a database based on the student’s grade
  • A program that duplicates the first report written and then changes the name and pronouns

Week 1 – Choosing meals

Solution choice

A bunch of the solutions I brainstormed revolved around querying a database, although I also liked the thought of paring down the options based on the user’s preferences. So that’s what we’ve ended up with: take a huge database, pare it down based on my preferences, then return a random selection of the remaining recipes.

The best part about this process was finding an amazing recipe database: https://github.com/fictivekin/openrecipes. These guys did exactly what I would have done, which is to scrape existing cooking websites to acquire the key details about their recipes. That said, creating a web scraper would have been a huge challenge, so I’m glad that I could stand on the shoulders of giants! (Note to self: put ‘build a web scraper’ on list of potential projects.)

The solution

The code is on Github here: https://github.com/dtsmash/recipe-selector. If you want to run it yourself, you’ll also need to download the recipe database from the link above – the file is too large to include in the project folder.

In a nutshell, the program:

  1. Reads the database (stored as a json file) into Python as an array of dictionaries – each recipe is a dictionary with attributes like ‘name’, ‘ingredients’, etc.
  2. Asks the user their preferences (currently I’m asking about maximum preparation time and required ingredients, but lots more could be added – see below)
  3. Pares the total database down to only the recipes that match the user’s preferences
  4. Selects a number (default five) of recipes and provides the user with their names
  5. Opens the URL of the recipe the user selects

Pretty basic, but works quite nicely. Some improvements I’d like to make in the future:

  • The program’s ability to understand what ingredient is wanted is limited. I’ve fixed case sensitivity and built in a check for whether the ingredient even exists in the database, but it still doesn’t understand that, for example, potatoes ≠ sweet potatoes, or that potatoes = potato. The latter issue would be fairly easy to fix, come to think of it, by prompting the user to supply the ingredient as a singular noun (will work for most English nouns, at least).
  • A nicer UI than just typing in the Terminal window would be pretty nice, and improve usability.
  • More ways to thin down the recipe list, e.g. ingredients to avoid
  • Creation of a shopping list after recipe selection (someone from the NY Times did something similar and theirs has a shopping list creator at the end, jealous)

Learnings

I want to use this blog to also be reflective about the problem solving process each week – deliberate learning and all that.

So this week, what did I learn?

  • Although I also like Ruby from what I’ve seen so far (I’m picking it up as part of a front-end dev learning track), I still have a much better grasp of Python.
    • Moreover, my main (huge) advantage in Python is that I know how to search for knowledge I lack. Inevitably, and especially for a simple project like this, the fix for whatever difficulty I’m having has been outlined beautifully in some Stack Exchange thread. But to get there, I need to know enough of the lingo and the fundamentals of the language to formulate my question well. That’s a fairly useful realisation for my future programming language learning: first priority, learn enough to be able to find the answers yourself.
  • Good gracious is it nice to be able to stand on the shoulders of giants. My end of the solution was pretty simple, but entirely prefaced on the existence of a good database.
  • Àpropos, I am now ever more of a proponent of open, accessible data. The world would be enriched to an unbelievable extent by data being made more freely and easily available. Governments of the world, I’m looking at you – democratic accountability and transparency requires this!
  • I super love problem solving and coding – that was a fun task!

Week 1 – Choosing meals

For my first problem of 2017, I wanted to tackle something that had been a recurring issue in our household for a while: knowing what to cook for dinner/lunch. Lena and I have favourite fallback options that are safe and delicious (e.g. dahl, roast vegetables, spaghetti), but we like cooking and eating new things.

Our trouble stems from the over-abundance of options combined with a lack of a starting point. Whenever we’ve hit a situation in which something needs to be eaten quickly before it goes bad, the problem goes away – five minutes’ searching “recipes with partially-mouldy bok choi” yields a few good options.

So, I want good recipe options at my fingertips, and I don’t want so many that I’m overwhelmed, but I want them all to be pretty good.

Problem definition

Step one to solving a problem is to understand what the problem really is. No point building a bridge across the river when the customer only wanted to visit the burrito store on the opposite side – much easier to open a new burrito store on this side instead!

So what is our problem here? This one is a pretty gentle pitch, since the problem is mine, but it’s still good practice.

Objective: Obtain meal recommendations on demand

Restrictions: Should be tailored to my preferences, should only provide a small list of options.

Optional bonuses: Filter by what is already in the pantry, update search based on past success.

Potential solutions

Bearing in mind the wisdom that the first solution may not be the best solution, I’m going to push myself to come up with at least five options before choosing one to tackle.

  • Use an existing database of recipes and write a program to query it
  • Build a database of recipes by scraping the web and query it
  • Search a subreddit or similar for posts with certain keywords and serve up the results
  • Take a list of what is in the pantry and randomly select a focal ingredient, iron chef-style, then possibly also provide some recipes from a Google search
  • Create an algorithm that incorporates a bunch of different factors to spit out an answer, probably with a random element thrown in to keep it from becoming stale

OK, good list. Worthwhile exercise, too, because a few of those did not occur to me until I’d spent half a day with the idea marinating in the back of my mind.

Next up, deciding and implementing – stay tuned!