ECE 2524

Introduction to Unix for Engineers

Review of API_fiddler

Usage

Even with the requirements to install pyyam if your OS didn’t have them already, APT_fiddler was easy to set up and use. The readme provided clear instructions on how to use the project. I only had to excecute the command “./server.py” to set up the entire project, which creates a simple localhost https server on the user’s local machine. After that, I went to localhost:8080/weather and localhost:8080/stocks the program was immediately able to display randomized json results as expected. Usig the program was predictable, and therefore can be easily used.

Style

The code is organized into logical and understandable groups and files. server.py seemed to be the corefile of the program which organizes all the programs and modules, set up the HTTPS server, and ran the server until the user cancels its process. The parser.py file had a class which produced and stored the json and yaml information as well as the class which takes in yaml data and creates “Object” classes that hold the converted json data. Therefore, both classes seem to be cohesive with each other. Randomgen.py contains a single RandomGen class which generates random words or numbers for creating random data for the Object_parser class to parse and Object to store. All the classes have distinctive “purposes” for the program and do not overextend their purposes nor contain miscellanious/irrelevant functions. The webpages displayed where minimal, which is helpful since it enables users to directly retrieve the data. The webpages contained all the user needed and no unnessecary decorations and filler.

Philosophy

The program seems to fit the Model/View/Controller interface pattern, which divides the program into groups which communicate with each other rather than one giant “monolith”. The Object_parse and Object classes are the models which are data structures that parse/contain the randomized data from RandomGen, and server.py is the view and controller which processes user requests (refreshing the webpage for new data) and also renders the data to be displayed. Although the controller and view are in the same file, they are usually closely bound in practice. The program itself doesn’t require any input from the user on the command line, since all the data is randomly generated after each refresh from the web browser. The modularity of the program is well designed, like how the RandomGen class and the Object_Parse/Object class pair can work on their own. There no no elements of surprise either. Simply execute the command “./server.py” and everything comes out fine.

–Rooms for Improvement– There could be an option that can store the generated random so the user has a “history” of all the random generated data in case he/she needs to see if all outputs of their site process their inputs correctly. There could also be an inline option when executing server.py that allows the user to choose which kind of data format it wants generated, like json or yaml instead of only json. The output of any GET actions from the HTTPS server probably doesn’t follow the “silence is golden” rule. This is the same behavior as starting a Django server from its manage.py program, but I guess it would be more “unixy” if the program only outputted errors or 404s from the HTTPS server. The json files are found on localhost:8080/weather and localhost:8080/stocks, but index localhost:8080/ leads to a 404 error. The index could redirect to either stocks or weather, or lead to a webpage which redirect to /weather or /stocks to prevent any surprise and to streamline the program.