Peer Review - Linux

[jj-zhang]

Peer Review: review to be done by a peer member.

• [x] Check that the guide has working instructions and sample code
• [x] Check the quality of code according to the best coding practices
• [x] Check the quality and presentation of guide according to Structure and Style Guideline
• [x] Check the consistency of guide with template and other guides
• [x] Examples with the right outcomes are provided
• [x] Example with the wrong outcomes, if any, are provided
• [x] Check that all licensing statements are properly stated in all files
• [x] Check that the pom.xml, server.xml, etc files are clean
• [x] Check that the directories are properly structured
• [ ] Test the guide on 3 platforms: Mac, Win, Linux
• [x] If any URL visits, try them on different browsers: Firefox, Chrome, Safari
• [x] If any URL visits, try curl command where applicable
• [x] Ensure that the guide is using the latest version of the liberty-maven-plugin or liberty-gradle-plugin where applicable
• [x] Check that some of these page-tags are used in a guide: MicroProfile, Maven, Docker, Kubernetes, Gradle, Java EE, Security, Cloud. Only these tags are visible on the website. Latest list here.
• [x] Check the attribution statement is accurate for the guide
• [x] Verify the travisTest.sh script, if any, is accurate and consistent with other guides

Peer Testing: tests to be done by a peer member.

Guide’s contributor’s (if available, otherwise peer tester’s) responsibility:

• [x] Additional tests where applicable:
  • [x] Define test coverage and review with team (including guide contributor, if available)
  • [x] Define detail test cases
  • [x] Consider corner cases targeting the specific guide
  • [ ] Consider different platform tests, ie, Mac, Windows, Linux
  • [x] Consider corner cases UI tests
  • [x] Consider testing URL on all browsers, ie, FF, Chrome, Safari
  • [x] Consider testing the curl command for URL visits
• [x] Consider building with both Maven and Gradle build tools
• [ ] Testing with different IDEs, ie, Atom, Eclipse (Optional: VS.code, IntelliJ, Microclimate)
• [ ] Run Acrolinx Checker on draft (above 70 score approximately)
• [x] Consider SEO title and description for the guides
• [x] Ensure automated test is enable, set up with Travis CI, and able to schedule tests
• [x] Run diff -r start/ finish/ and there's no differences
• [x] Ensure that the automation tests are able to run when PR is created

Peer Tester’s responsibility:

• [x] Check the appearance of the guide on test site for the following items:
  • [x] Table of contents
  • [x] Headings
  • [x] Paragraphs
  • [x] code snippets
  • [x] outputs
  • [x] links
  • [x] hotspots
• [x] Test the guide end-to-end with working instruction and sample code
• [x] Perform all the defined test cases

[jj-zhang]

Project Configuration

• [x] It’s convenient package manager, npm. Here it's should be replaced with its.
• [x] The frontend-maven-plugin is used to install Node.js. For the hotspot install, I don't think npm install is used to install the node.js.

Creating the default page

• [x] The ReactDOM package provides DOM-specific methods should be replaced with react-dom as ReactDOM is the method in react-dom package.

Importing The HTTP client

• [x] You may not use hyperlink for the second axios as it's a little redundant.

Building and packaging the front end

• [x] Run the following command in another shell. Add session after the word shell
• [ ] Suggest to indicate which directory is running mvn process-resources command.

[salmad3]

Thank you for the feedback, @jj-zhang.

• For "Suggest to indicate which directory is running mvn process-resources command", the user is already in the start directory when they are creating their application.

[jj-zhang]

Sounds good to me. Then we don't need to indicate the directory here.