When it’s going well, software development can be as enjoyable and straightforward as building a model from LEGO bricks: you have an idea or a goal in mind, and you begin to scour through the available components to put together the intended result. If you’re lucky, you find detailed instructions – requirements and documentation – to help you along your way. Meanwhile, one of the reasons that open source software has become so successful over the past few decades is that different software developers are frequently looking for components that match similar requirements when they’re building systems.
This is the second post in a series that explores the technology that RecipeRadar uses to process and store recipe ingredients In part one, we introduced a simplified version of the data model and XML format that RecipeRadar uses to represent ingredient information. In this post, we’ll explain how we handle singular and plural ingredient names for English-language ingredient text. Let’s begin by presenting two of RecipeRadar’s ingredient search use cases.
The team learned of some existing issues in the black Python code formatter that we use to format some of our published code, and is providing time to help. The team has also been working on maintenance and bugfixes since the last fortnightly update: Preparations have been put in place to update RecipeRadar when the release of SQLAlchemy v1.4 lands, which is anticipated within the next few weeks A serious user-facing bug that prevent recipe scaling was identified and fixed - we believe that this affected users who retrieved the application between 2021-01-06 and 2021-02-08
This week’s update includes a video feature-preview of the (oft-touted, rarely progressed) multi-device collaboration feature. The user interface is intended to be as straightforward as possible. You’ll pick a username and a ‘room name’ - a shared name for the place you’d like your meal plan and shopping list to be available - and by providing that room name to your friends or other devices, they’ll be able to participate equally in the session.
Nutritional Information The main item of news today is that we’ve launched display of nutritional information in the application. Not all – and in fact, not many – recipes that we’ve collected so far have nutritional information included alongside them, but when present that information will now be displayed in the search results. We’re currently refreshing (or ‘reindexing’ as we call it within the team) the recipe data on RecipeRadar, and more nutritional information will appear as this process continues.
During the last two weeks, we had a relatively radical idea for a way to explore recipes on RecipeRadar. Rather than prompting people to enter the ingredients they have (requiring a modest but noticeable amount of data entry), we can present a list of common recipe ingredients to the user, and allow them to use swipe gestures to say yes/no to the ingredients that they have, saving on typing. As they swipe to indicate whether each ingredient is available, the list of subsequent ingredient choices updates dynamically based on the recipes that match the ingredient selections made so far.
Welcome to another almost-fortnightly RecipeRadar update. There have been a few developments since the last update: Our first feature-related blog post, “An introduction to ingredient parsing” went live in early November - part of a series with follow-up posts coming soon We’ve completed a large-scale refactoring (re-organization of code and data) to make it easier to manage and correct the information that we store about ingredients. As a side-effect, this has further improved our recipe indexing performance.
This is the first post in a series that explores the technology that RecipeRadar uses to process and store recipe ingredients As a recipe search engine, RecipeRadar aims to collect and understand recipe content from around the web. We’re able to crawl recipes from any website supported by the recipe-scrapers Python library, and the results of each crawl include – among other details – a list of the recipe’s ingredients and a list of the preparation step involved.
At RecipeRadar engineering HQ, feature development has been continuing - at a slightly unpredictable pace - in a few parallel areas. Collaboration (unblocked) As mentioned during the previous update, we had been blocked on multi-device collaboration work due to an issue affecting database unit tests. The good news is that the issue has since been fixed! Work on multi-device sessions should recommence shortly. Surfacing nutritional information (blocked) Display of nutritional information within the application is in progress, but we’ve hit some snags estimating aggregate nutritional information for recipes.
Well, it’s been a little over a fortnight since the last update; despite that, progress continues on RecipeRadar. Multi-device Collaboration After some deep thought regarding a technical design for multi-user collaboration on RecipeRadar, we now have a specification written up. The engineering team is working towards implementing this. Most good software includes tests to ensure that the code does what it intends to and that it doesn’t break during future changes.