Python Weather app - current conditions from the national weather service

 So, I was reading through a course on XML from W3 schools and in there, it mentioned that current conditions are available as an XML file for various locations.  So I investigated it.  After a bit, I thought I should make a Python program to pull the information from the National Weather Service in XML format and then display this information to the user.

It took some time to refamiliarize myself on the use of the urllib functions in Python to make an http request and download the text of the response.  Then, I needed to learn how to use the XML functions to parse the XML to retrieve the values for each of the tags.  My solution is quite fragile in that any changes to the file format by the National Weather Service will break the code.  Nonetheless, I was quite pleased with myself when I had finally got this working!  So I thought I would share it with the world.

While I don't think that this is going to revolutionize anything, maybe you can re-use some of the code.  Probably the list of the different Oregon locations is the most useful thing.

Here's what the user sees after hitting Fetch:

Shopping list and recipe app development plan

 So this is going to be the first of a series of posts that are going to follow along developing a desktop application (mostly cause I don't have an IDE in which I can create a mobile app) that will store recipes, allow the user to make meal plans, and then based on those meal plans create shopping lists for all the ingredients.

The overall plan is going to include:'

• Defining the requirements that the software has to fulfill from a user perspective.  This would be the functionality that the user expects the software to perform.
• Defining the technical approach that is going to be used to fulfill the user's requirements defined in the previous bullet.
• Create a test script to be used to ensure that the software is functioning adequately.  Each of the tests will check that one or more of the requirements have been fulfilled.
• Perform the testing and then do any required remediation to correct any discovered test failures.
• At this point, I may end up discussing what additional or changed user requirements could be used for the next version of the software.  But let's not get ahead of myself.

So what are the user requirements?  While I'd like to use a table here, I'd have to create it by writing raw HTML as the blog's UI isn't accommodating of tables so you will have to bear with me as I present it as a numbered list.  While the numbered list will not allow me to, within the list, add a prefix, for any cross-references, pretend that Recipe requirements are prefixed with an R, Ingredient requirements are prefixed with an I, Meal Plan requirements are prefixed with an M, Shopping list requirements are prefixed with an S, and general requirements with a G.

Recipe module

1. The user will enter for each recipe:
1. A title
2. A category for the recipe
3. The number of servings the recipe makes
4. One or more ingredients
5. One or more cooking steps
2. Recipe categories can be created, edited, and deleted.
3. Recipe categories will be pre-populated with:
1. Entrée
2. Side
3. Appetizer
4. Dessert
5. Snack
4. Do not allow Recipe Category to be deleted if it is used in an existing dish.  Advise the user of at least one recipe title that they need to address if they try to delete in this case.
5. For each ingredient, the user will specify:
1. Quantity to be used
2. Unit of Measurement of consumption quantity
6. For each cooking step, the user will specify:
1. Step number
2. Text of the step instructions
7. Recipes can be exported.
8. Recipes can be imported.

Ingredient Module

1. For each ingredient, the user will enter:
1. Ingredient name
2. Purchase Quantity
3. Purchase Unit of measurement
4. Zero or more unit of measurement conversions
2. Ingredients can be exported.
3. Ingredients can be imported.
4. Ingredients can be created, edited, and deleted.
5. Ingredients cannot be deleted if they are used in a Recipe.

Meal Plan Module

1. The user can populate the meal plan module with a meal record consisting of:
1. A Recipe
2. The number of people dining
3. The date of the planned meal
2. An export can be created for a date range showing all the meals planned within that date range.  The export will be a table modeled to simulate a calendar.  Also a multi-level list format will be available.
3. Meal records can be created, edited, and deleted.

Shopping list Module

1. The user can create a shopping list for a user-selected date range.  This will produce a shopping list for all the ingredients that will be consumed in the preparation of all the meals in the selected date range for the indicated number of diners and indicate to the next whole purchase Unit of measurement.

General requirements

1. The user can create different databases.
2. The user can open a specific database.
3. There are no security requirements.

In writing this, I've had some thoughts already about other behaviours I'd like the program to have, but I think this is already enough to get on with.  The next post, hopefully within the coming week will discuss the technical approach I will take to providing the functionality defined above.