Imagine that you are a junior developer working on this project and Dr. Moore is the software architect. He will be checking on your work as you complete each phase. Here is your first task: Create a Web Application in Microsoft Visual Studio named “your name’s items” (example: “David Moore’s Coins”). Do not create a “Web Site.” You must create a Web Application. You may use VisualBasic or C#. Create a page called “Insert[item].aspx” (example: “InsertCoin.aspx”). Select two attributes of this item (example: for a coin, its name and weight). Create two text boxes (one for each attribute), each with a label describing the information to be typed in the box. Add a button with appropriate text inside (example: “Insert Coin”). Using codebehind code, program the page to display a message when the user clicks the button describing what was entered in the text boxes (example: “You entered a 2015 Silver American Eagle weighing 1 troy ounce(s).”). Display this information in a Label or Literal control. Modify the project’s settings so that the page you just created will display first when the project runs. Copy the page and rename the copy as “InsertItem_inline.aspx” (example: “InsertCoin_inline.aspx”). Modify this page to use inline code in your ASPX file (using a script runat=”server” tag) instead of codebehind code. Remove the codebehind file and any references to it entirely in the inline version. Things to Remember: You are making a Web Application. Not a Web Site. ZIP and submit all files necessary to run the project. Your project architect should be able to unzip your solution, double-click on the SLN file, press F5, and run your solution. All file paths and file references should be relative to the solution’s location. Do not use absolute file paths. These won’t be portable from machine to machine. All items such as controls, pages, and methods should have meaningful names. Be as efficient as possible in your code and in anticipation of code maintenance. Be modular. Use existing .NET libraries and features to your advantage. If small changes in requirements will result in big coding changes, try to figure out how to consolidate and modularize things to make maintenance easier. If you find yourself copying and pasting code, stop and refactor. Create a method that will help modularize your code. Don’t use inline CSS, JavaScript, etc. These slow things down and make project maintenance more difficult. Use themes, CSS files, JS files, etc. wherever possible. All non-obvious code should be accompanied by comments telling what the code does. Submission Instructions: Compress the entire solution with all the files and submit it as “Yourname’s items – wk1.zip” (example: “David Moore’s Coins – wk1.zip”). Grading Rubric: Points Description 100 The submission is flawless and accomplishes all required functionality. All possible code efficiencies are used. All items have meaningful names. Code is well documented. Industry best practices are followed. [90, 99] The submission runs and accomplishes most or all of required functionality. Some code might not be as efficient as it could be. Some documentation missing. Some items not named properly. [75, 89] There is minor lacking functionality. There are significant efficiency issues in operation or anticipated code maintenance. Little or no documentation. Very poor naming on code elements. [1,74] Significant functionality is lacking. Deduction is proportional to the percentage of lacking missing functionality. Major efficiency, documentation, or coding practice issues. Deduction is proportionate to the severity of the issues. 0 The solution does not compile. The solution does not do any of the required functionality.