Please mark Assignment 2 stage 2 from the last commit of Thursday 25th May
🚢💯✔️
- Student email: psha67@student.monash.edu
- Student ID: 26898187
- Student email: dlei7@student.monash.edu
- Student ID: 26029391
- Node.js ~v6.9.1: A JavaScript runtime. The code base should be relatively independant of the Node.js version being run.
- Yarn (Optional but highly recommended): Depedency management software that typically outperforms npm at installation speed.
- Windows 10 Home (OS Build 14393.1066)
- OS X El Captain 10.11.6
We used the assignment to try out new features of JavaScript and CSS such as promises and CSS Grid. This limits the compatibility of the app to modern browsers only. Our Webpack transpiler loaders should provide extended compatibility, however, for the sake of marking, the app works correctly on the following browsers:
- Google Chrome +58.0.3029.110 (64-bit)
- Firefox +53.0.3
- Make sure Node.js is installed.
- Open up a terminal.
cdto desired folder.git clone https://github.com/Monash-University-FIT3077/fulllambda-Assignments.gitcd fulllambda-Assignments/Assignment_2- Run
npm install. If you have yarn installed you can useyarn install. Wait for all the node packages to finish downloading. - Run
npm run backend-start. Wait for the the 'Webpack configuration complete' message to be printed to the console. - Open up another terminal.
- Run
npm run frontend-start. Wait for Webpack to finish again. - Open a browser.
- Type into the URL bar: 'localhost:3000'.
Note: You MUST wait for the backend's compilation to finish before running npm run frontend-start. This is an issue with having two Webpack builds running at the same time in the same folder with similar configurations. It is assumed that a solution to this problem is out of scope for this assignment.
The report resides in the repository with the file name: FIT3077_Assignment2_Stage2_Report_26029391_26898187_FullLambda.
We use Node.js to provide our own API to frontend applications, as opposed to the frontend application communicating with the SOAP client directly. Despite the added latency, there are a plethora of reasons for doing this:
- Removes frontend polling all-together: Polling is inefficient and poorly scales with high frequency polling (a potential change to the requirements in stage 2). By rolling our own API, we are able to leverage WebSocket which removes the need for frontend clients to poll all together. This is far more efficient compared to high frequency polling.
- Minimizes traffic directed at the SOAP service: One of the objectives of assignment was to "minimize the network traffic generated by your system: don't access the web service more than is absolutely necessary". Our server acts as a cache for the SOAP service's data, allowing users of frontend clients to retrieve data witout the need to retrieve data from the SOAP service at all. This means that the amount of traffic directed at the SOAP service is independent of the number of frontend cleints. Real world APIs also often have a limit on the number of requests that can be made to their service per hour. Our implementation circumnavigates this issue.
- Changes are invisible to the client: Changes in the
WeatherClientare transparent to frontend clients. This is particularly useful when constantly switching betweenMelbourneWeatherClientandTestWeatherClient. - Potentially less computationally intensive for poor-performing devices: Less logic on the frontend means that simpler devices can use the application without lag.
- The observer pattern: The observer pattern was used for on click events and in the
LocationMonitoringManager&SessionMonitoringManager. Our observer pattern mimics the Android SDK's implementation of the observer pattern. - Factory pattern: We use the factory pattern to allow the
FullLambdaWeatherServiceto create aWeatherClientfrom aWeatherClientFactoryso that the service does not need to know the underlying steps to create the client. Retry-client-creation functionality will be written into theFullLambdaWeatherServiceas an example of using the pre-existing factory code to potentially build multiplePromise<WeatherClient>s. - Seperate GUI and logic: We almost totally avoid any logic on the frontend of our project. This allows us to provide functionality that is independant of the user's interface. In fact, the only frontend class that performs limited controller functionality is the
WeatherPageContainerwhich links the view to the socket.io API. All other frontend classes concern themselves with rendering the DOM in a particular way. - MVC (Model, view, controller): The model, view and controller (as previously discussed) are seperated. The
WeatherPageContainerdetermines how inputs are interpreted, all otherReact.Components serve as view type classes. All business type logic is handled by the backend server. - Use dependency injection: Gregory Kick's Java Dagger 2 video explains dependency injection quite well. As an example of the benefits of dependency injection in our own code;
WeatherClientis passed into theFullLambdaWeatherService's constructor. This allows us to swap out theMelbourneWeatherClientwith aTestWeatherClientwhich allows for easier debugging. - Composition over inheritance: Self explanatory. This mentality is typically considered to enable more flexibility in code. An example of this was our choice to compose the
LocationItemof aGenericListItemrather than inheriting from it.
- JavaScript guidelines: Air BnB's JavaScript Style guide.
- Design guidelines: Material Design
- Linters: TSLint
- Git patterns: See Git guidelines
- Language: American English
- Sequence diagram guidelines: IBM Sequence diagram
- Green text: successful
- Red text: error information
- Cyan text: important information
- Purple text: parameterized information
- White text: General/other
The development-master pattern is used in conjuction with feature branches. Code is merged (usually) via pull requests.
master: The development branch should be merged into this branch whenever a new version/set of features, ideally bug free, have been completed.
development: Features should be merged into this branch once implemented. This branch should maintain transpilability and compilability. Known bugs are allowed to be merged into this branch. Developers can work on the development branch for minor changes to the codebase.
Feature branches: Feature branches contain major refactored code or implementations of new functionality. Code from feature branches should be merged into the development via pull requests.
Our product can handle multiple sessions from different browsers/tabs. Each will have it's own set of clickable buttons to add and remove rainfall and temperature data. We also cache the weather data so new sessions can be served ASAP.
It also has a google map which can be used to toggle location pins for a weather service.
Location pins represent the intensity of rainfall, with greater rainfall resulting in a deep blue and less rainfall in a light blue pin. If rainfall is not selected it defaults to red. If rainfall in not a valid number it defaults to grey.
Around each marker is a circle representing the intensity of temperature, the hotter it is the more red the circle. Likewise if temperature is not selected it defaults to a greyish-blue and if temperature is not a valid number it defaults to grey.
Hovering over the pins displays more information about the area.
- Interfaces can have variables. These variables are passed onto the implementer of the interface.
- Variables do not necessarily have to be typed. This allows compatibility with JavaScript packages that do not provide types.
- Optional parameters are supported in TypeScript. This renders the Builder pattern somewhat redundent and is thus not used in our code base.
readonlyis supported in TypeScript. We use thispublic readonlyover accessor methods, in all 'model data' type objects.
JSX harmony is a language primarily built for React. The language was primarily used to make React components easier to read and faster to write.
