(4/13) There was an email request from a phantom student who needs to complete the assignment but hasn't attended class where verbal specs are provided and questions are freely answered. Will this help?
Is this helpful? PLMK any questions it leaves unanswered...
(3/19) Project #2 is assigned with a due date of May April 2nd, for the Evening class, or 3rd for the Afternoon. Make sure to comply with all specs for Project #1 and #2. Graphics requirements for product images were waived for project #1 but will apply for project #2: all products should be depicted about the same size with either a transparent background or the same dimensions on the images. Images should be sized the largest they'll be displayed in your css/layout.
The project adds a few new php scripts to handle authentication using 2017Winter credentials, require authentication to access protected content. SiteSetting.php in your home directory gets code added to connect to your database and handle authentication.
Take care not to blow away your code from Project #1! Do some 'program analysis' first on the script in /home/tinstructor/web and find the few lines of code that need to be put in your script to make it require authentication and update your database.
As you work, take care to protect against SQL and HTML injections! The sample code is vulnerable to both...
(2/26, 27) A 5-Point Team project is afoot, due by the end of class next week, 5th or 6th. Set up accounts at 2017Winter, one at a time, and make a UML State Transition Diagram for Accounts as new accounts are enrolled.
(2/15) Project #1 Dlv #2 Customized Form is due Monday the 26th for the evening section and Thursday the 1st for the afternoon. Please read and heed the specs for Dlv #2 as the instructor will have them in mind when scoring it. Take care to make a consistent look between home page and the form, styling with the same css is a good idea. Project #1 Dlv #2 doesn't update the database and requires no authentication so that it's easy to run W3C Validators and Google Mobile Friendly tests on it. Project #2 requires authentication to access the form and updates your database with form data...
(2/15) Tutorials: I'm delighted to announce Silma Hossein has been on-boarded as a teaching assistant for INFO300 and INFO465. The INFO300 dept doesn't have a lab, but last semester's assistant set up for consulting in the atrium and it worked fine, so we'll try that.
Hours are: 3-7 Mondays and 12-4 Wednesdays. She'll be located near the bistro. If these hours don't suit, Silma's offered to meet via Google+ Hangouts or use my GoToMeeting. She's available on vcu mail, is the only silma h that pops up.
Many/most of y'all have little or no experience debugging in a web environment and these projects are trying for that Experiential factor in EPIC to get you some experience. Please keep at it and you'll figure it out. I believe rebranding and adding code that works OK is the best way to learn a language, leads to more success than giving a noob an empty directory and asking them to design a complex script.
Those of y'all who have advanced yourselves past noobish to novice or adept are welcome to design away...
(1/28) VCUNet Caches Static Content!, sometimes dynamic, too! This may be my most-given advice in lab and email: If you're working on-campus, in VCUNet, debugging has the added challenge of requiring explicit reference to refresh graphics, css, fonts, and other linked elements while you're debugging your projects. Sometimes, oftentimes, or usually the border at VCUNet doesn't recognize changes and serves up its cached version of a resource instead of what you so carefully copied to your web directory @info465.us. If this happens to you, try another browser, preferably on your smartphone, to help diagnose what's going on. VCUNet aggressively caches resources to faciliate the load across the border when, for example, a lecture hall of 120 students has just been directed to the same off-campus resource. When debugging, it may be necessary to run another browser, or the web console in Developer's Tools, and explicitly refresh any changed script or graphic before refreshing the web page being debugged...
Prior notes have been moved to: PriorNotes
Most specs and advice are given in class, verbally, some are here...
Click Logging in and working at info465.us for references about working at the command line at info465.us. User ids and passwords were shown in class, expecting that the first command on-line will be passwd...
Demo'd SeSDoC forms: Mobile first, responsive, valid html5 and css.
These links were visited and examined in class. They are all dead-simple HTML and CSS, just enough to clearly demonstrate semantic markup of content and forms.
This 20-point project is to put up a demo site that gets all the specs below and will launch from your link at info465.us.
Dlv #1 is 5 points: demo a valid, mobile friendly, responsive site that launches from your link at info465.us, identifies your fictitious organization and shows off three items for sale. Get your SiteThumb image or animation in place and set the name of your fictitious hussle into your settings. Use similarly-sized product images with transparent backgrounds, or use identically sized product images. Size images no larger than the largest they'll be displayed on the page, no distortion or pixelation. Copy/tweak class samples is fine, learning a framework or using it again is better. The class' coding samples are easy to stick into most any template...
Gain familiarity with the Linux command line at info465.us and use it to copy text files, scripts, css, and html from /home/SeSDoC and /home/SeSDoC/web or your framework to your home directory and web directory and tweak them into webpage that shows up from your link at info465.us.
Decide whether you'll adapt the sample code at SeSDoC or Resp for your project, or start from scratch, or use a lightweight CSS framework like W3Schools RWD, W3CSS, Bootstrap, or something heavier with more pizzazz. Exploring AJAX and jQuery are also worthwhile while you've got a server at your fingertips if web designer is something you'd like to be.
The sample code at SeSDoC uses 'html templates' and is very easy to fit SeSDoCForm.php and other reports into an html template made from a css3 framework like W3CSS, Skeleton, BootStrap...
Make the html and css suit the fictitious organization, business, or hustle you confabulate for your case study. The index page will become a store-front that earns commissions on sales of at least three products or services. Choose a thumbnail image to represent your site at info465.us and make the site comply with the SiteThumb spec (at the bottom of the Thumbnail page at info465.us) so your site appears in the gallery at info465.us. Transparent backgrounds are attractive, animated gifs of a few dozen frames are fun to see.
If you're working from the samples provided, consider the acronymns SeSDoC and SeSPoP as the property of these ficititious organizations and they should not appear in the file or variable names involved in your website. The info465.us enforces these and other specs.
No embedded or in-line Styles! This is what 'separate style from content' means! All CSS must be 'external', in a local file linked in the head of the document! If there is an exception, add a style for it in the external style sheet. If there is some reason you must embed or use in-line styles to achieve some effect, please discuss it with the instructor.
All pages must be consistently styled with the same or similar external css3.
If a semantic element exists, use it. Do not use plain divs with ids or classes named like header, footer, menu, aside, or any other CSS3 semantic selector. Don't use frames or iframes, named or otherwise. Make your page a very clear demo of the best markup for semantics and style!
Use CSS3's semantic elements for page layout to best advantage: As a minimum, structure your page layout using: header, main, aside, and footer.
Use CSS3's semantic elements to mark up content: p, h1-6, ul, ol, li, strong, and em, table, td, tr...
Use CSS3's form elements to mark up forms: fieldset, legend, and label.
The elements in the sample form at SeSDoC define an html form in a standards-compliant way so that is usable in a mobile device without any stretching or tapping and is also accessible for handicapped persons and search engines.
Use a grid scheme for responsive design. The samples use the '12 grid' scheme from W3School's RWD tute with Row and Col defined in CSS, amenable to folding for tablets and phones. This also appears in W3CSS and the equivalent is in BootStrap and Skeleton.
Optionally, semantic elements article and section may be used to organize featured products or items, newsletters, blogs, and other complex web documents. Styling an article is a good way to implement material web design features like cards.
Wildcard classes of CSS3 make it easy to adapt a multi-Column grid system to any kind of device by being clever with object names like 'Col-' or 'Card' to adapt seamlessly with any sized viewport. W3Schools RWD and W3CSS show how to use these wildcard features. These features are well used in most CSS3 Frameworks!
CSS styles make it easy to make accordion or drop-down interfaces for the user, or change from a hamburger to a menu when the window gets big enough. Many CSS3 transitions are now supported by current versions of all common browsers and most vendor-specific styles may be retired. There's a lot of value in learning how to do these with native jQuery or one of the frameworks that uses jQuery -- these are the slickest and doing them the way Google does it is a good thing!
Serve all graphics, fonts, libraries, frameworks, and styles directly from your web directory at info465.us and be ready to report on their bulk. Quick loading speed on a slow network is of the essence. Google guidelines favor lightweight pages that load fast even on a 3G network. Limit the size of graphics for products on the home page to something less than half a megabyte. Size all images for their max dimension as used on your site. (If it's 300px wide on the page don't link to an image that is 2000px wide in the img tag, and don't use dimensions in css or html to make large images fit.) Use a photo-editor on your desktop or online to size images. Make sure all re-sizing results in sharp images and doesn't result in unsightly artifacts...
Set the permissions for your web and any of its sub-directories to 705. Set the permissions for all files in your home and web directories to 604. The intent here is that the web server can read these files but others in the info465 group can't.
Project #1's 1st deliverable was a single page, mobile-friendly at google and valid at w3c, website for some fictitious shop or organization allied under 2016Winter's umbrella.
The 2nd deliverable is a two-page site that launches from the link at info465.us, showcases at least three products on the home page, and has a form on the second page that has been customized to suit membership or other relationship with your ficititious organization. All css is external, html5 and css3 validates at W3C validators, and all pages score Awesome on Google's mobile friendly test.
Project #2 will be to add user authentication and update the database using the form built in Project #1 Dlv #2.
The PHP or Python-generated form must work at least as well as the sample code provided at SeSDoC, meeting these finer specs:
Tech support for learning the command line and vi and Project #1, Dlv #2...
Things not looking right in the browser? Maybe getting an empty page back or missing an img? Tailing the log might help: Open a new ssh window and log in to info465.us. Use this to show the tail of the log and follow it, replacing 'yourlogin' with your login id at info465.us.
tail -f /var/log/httpd/error_log | grep yourlogin
This will show errors produced by html or scripts from your directory when you load or refresh a page so keep it visible while you work. Use ctrl-c to stop tailing the log.
If you're programming without the developer and debugging tools running, you're just guessing and frustrating yourself and ticking off the intructor in lab, and will likely inject numerous errors in the code while blindly trying stuff.
Keep the debuggers visible at all times even if everything appears OK since they may be showing warnings that detract from a professional result.
Here is a screenshot suggesting a juxtaposition of putty or Mac terminals and a browser while debugging. A quick mouse-click or Alt-Tab moves among browser and code windows. The tail of the log is always visible so it's easy to see it jump if/when there is an error in a script...
Developer's Tools vary a lot from browser to browser! Some even takes lotsa seconds to load and cause the fans to come on just to show all the charts and graphs! The instructor usually debugs with FireFox Developer Tools, W3C, and Google, then Chrome on an Android, then Safari on a tablet, then with FireFox Developer Tools, then Chrome on a notebook, then Edge. Make sure you know how to refresh components in whatever Developer's Tools you use since many ISPs cache static content and don't recognize file changes on the server! Firefox and Chrome's source views flag some HTML and CSS errors, are quicker than the W3C Validators. FireFox and Chrome both allow Ctrl-u to get to source code, others substitute their own overblown developer's tools.
Keep the tail of the error log visible at all times as you code! If you're getting an empty page back or unexpected results from a PHP script, or missing an image /var/log/httpd/error_log will likely show the error.
Open a new ssh window and log in to info465.us. Use a command like this to show the tail of the log and follow it, replacing 'yourlogin' with your login id at info465.us.
tail -f /var/log/httpd/error_log | grep yourlogin
This will show errors produced by html or by PHP or other web scripting languages from your directory when you load or refresh a page so keep it visible while you work.
Use ctrl-c to stop tailing the log.
If you haven't been tailing the log and wonder about recent errors, you can grep them out of the error log like this, replacing yourlogin with your login id:
grep yourlogin /var/log/httpd/error_log
If there are no errors in httpd/error_log but the script isn't producing the correct web page, place echo statements followed by exit at strategic points in the PHP code so you can _see_ what's going on before the HTML is pitched.
Something like this might be helpful:
echo $View; exit;Or, use print_r to show superglobals or arrays:
print_r($_POST,false); exit;at the top of a script would show the POST data submitted from an HTML form to remove any doubts what's in the POST data...
Use the W3C HTML and CSS validators early and often and don't continue debugging until they are valid. Design for mobile first with viewport set, then tweak @media queries for larger displays. Use Google's mobile friendly test, try W3C mobile validator for more of a challenge.
Use info465.us/2017Winter's Log In or Get An Account dialog, at the upper right where 'Web 2' says it should be, for each team member. Do it one at a time while Rowdy Chihuahua or Rhue Pinscher are available to authorize accounts. Watch the process carefully so the team can get an accurate state transition diagram together for the project's deliverable.
If anything's unclear in the process or some non-fluency is discovered please document it so we can get it to the attention of the developers next time we can catch them.
Errata: info465.us is not set up to get email to you @vcu.edu, but works almost everywhere else. Using a gmail or other email account where you can click on a link to validate your email is easiest. If you don't want to use a real email address, use your firstname.lastname@example.org and the command line's mail to read the email validation code.The 2017Winter database is available so you can closely track the value of AcctStatus to get the state chart accurate. A select-only connection string is:
mysql -u2017Winter -pWinter2018 2017Winter
PHP code is available read-only in /home/2017Winter/Web.
Demo in class showed PHP's session_name, session_start, session_destroy and also looked at a session cookie under the i-spot in the browser and session data kept in /var/lib/php/session on the server. LogIn.php authenticates via web-service at 2016Winter by opening a pipe to handle a request with userid and password and response with not-valid or user's name. LogOut.php uses session_destroy to clear all the data from the session on the server. Every 'protected' php script requires SiteSettings.php which blocks access to pages if a browser's not logged in and redirects the browser to LogIn.php or index.html. Find these features in the code and be prepared to explain them.
Modify your site at info465.us to work similar as the example at info465.us/tinstructor, making a link like 'Members' prominent on your existing page. The project is to make your site authenticate users with 2016Winter credentials and provide forms and content to logged-in users only. If somebody tries to access a 'protected' url, they should be directed to the LogIn script for authentication, then to the url they attempted to reach.
The specs for the behavior of the form are the same as Project #1, all input elements should be returned with text, checks, and selections the same as the user entered. And the user should be able to re-submit a form if they notice an error. The specs for Project #1 were intended to make a form that can easily be secured and used to update a database.
The sample scripts are available from the command line in /home/tinstructor/ and /home/tinstructor/web/.
/home/tinstructor/SiteSettingsSample.php is available to copy and modify to suit your Site. Leave the functions intact. Edit at the top and bottom to supply _your_ SessionName and database credentials. Take care not to clobber your existing SiteSettings.php when fitting the new script in your account.
Copy these scripts to your web directory: TemplateSeSDoCForm.html, SeSDoCLogIn.php, SeSDoCController.php, SeSDoCLogOut.php, and SeSDoCApplicants.php. SeSDoCCommissions.php is not available to copy. After you've made them run, edit them to suit your site and database.
SeSDoCForm.php differs from the earlier example. Don't copy it over your existing form's script. Copy the changed parts to your script:
require(dirname(pathinfo(__FILE__, PATHINFO_DIRNAME)) . "/SiteSettings.php" ); AllowLoggedIn();require SiteSettings.php from your home directory and call its function AllowLoggedIn() to protect the page from those not logged in.
Here's a class diagram of a project similar to your Project #2:
Notes about SQL scripting at the command line are at MySQL/MariaDB Scripting and were demo'd in class.
The user id for your individual MySQL/MariaDB database is the same as your id at info465.us and passwords are the upper-case 1st letter from your first name and the last 4 lower-case letters from your last name. Rowdy Chihuahua's connect string would be: mysql -urchihuahua -pRahua rchihuahua
Please take care not to destroy your working php script as you add code to support database update! Make local backup copies so it's easy to revert to working code if you hose up the script while adding database update. HTML form handling, securing web pages, and updating a database in a structured environment are inherently complex tasks. Make sure you're keeping copies of your working scripts before each session so you've got something recent to roll back to.
Assignment: Teams of three or four confabulate a shop to operate under the umbrella of 2016 Winter. Get three products or services ready with graphics to upload and show at the shop...
A sample accounting for startup and a day of operations for a ficitious hussle similar to the case studies teams are confabulating. This is to review double-entry accounting concepts.
Each team please provide on paper:
After a demo of the PAYGO Unbrella 2016 Winter accounts will be set up.
Projects and a quiz use the database at 2017Winter. Please gain familiarity with it. Here's a connection string with select authority that will work from the command line at info465.us:
mysql -u2017Winter -pWinter2018 2017Winter
Use W3School's SQL Tute for an introduction to SQL. The database server at info465.us is MariaDB which at this point is a direct drop-in replacement for MySQL which most Linux distros avoid because it's Oracle's property...
Here is a sketched Database ERD of a database similar to 2017Winter showing the tables that have to do with accounting. Table names and PK/FK relationships are accurate, some column names are not quite. Use SQL's DESCRIBE command to get the exact column names at 2017Winter.
Here's a sketch of the whole database and file system for a system similar to 2017Winter. Tables with dashed lines around them might show up in some other season to help with distribution functions.
This is 10 points for individual effort and 10 points for teams. Teams setup Items in their shop at 2016Winter to be sold under the PAYGO commission agreement by each of the associates. This is demonstrated in the 'Click to Buy' links for Pacioli's books at info465.us/tinstructor.
Each student's shop at 2016 Fall has a link added to report commissions earned on the three items offered.
Teams contrive several purchases at their shops and the shops of other teams using the fake accounts with credit acconts issued by an ELand ACH.
Shops need a good-looking trial balance put together with at least a dozen orders and journals showing startup and a couple day's operations. QOH for items in the store should be reasonable to support on-line sales.
Teams thoroughly document the 2016 Winter PAYGO Umbrella's system as built. Team members note which portions they authored, and all team members should be involved enough with the project so they can claim it as an exhibit in their professional portfolio. Individuals, or those fired from a team, may negotiate a subset of the UML Diagrams and other documents. All documents must use recognized shapes from the UML suite of diagrams. Project #4 must be submitted in printed form and also in a single pdf submitted through BlackBoard.
Bring work to class for feedback early. None will be offered between the last class and the exam. The exam time is to collect projects not help debug them or tweak them to specs after critique...
This a rough Class Diagram for the MVC-Model View Controller scheme similar to 2016Spring. The UML doesn't have a MVC in its set of diagrams quite yet, but the Class Diagram is easilty adapted to reflect the popular design pattern. The blocks in a UML Class Diagram typically show Name of the class, its methods, and its properties. Here, to make it fit a MVC, the block represents a model (aka script) instead of a class. 'View' is substituted for method, where the models consistently use HTML GET or POST data in $_REQUEST['View'] to control their output.
The biggest block in the diagram is Controller.php, 'the controller', which surveys the environment for a logged in user and provides a menu of the models and views appropriate for their authority and roles. Please, improve on the diagram if you choose to use it as a model for your Class diagram, and make it a tighter fit to 2016Winter.
Its important for somebody wanting work in app dev to have a ready reference to a Model View Controller and be able to talk about it, sketch it, or sit down and develop with it. The MVC is a popular and powerful design pattern implemented in many development environments in many ways. Visual Studio's MVC is highly abstract with a steep learning curve, which it's well worth climbing since it takes best advantage of the .NET Framework. Django is in many ways a MVC, as are other frameworks for application development.
This is a rough UML State Chart, or state transition diagram, for Orders OStatus from check-out through fulfillment in an application similar to 2016Winter. It's reflects changes from 2016Winter that involve a shipping desk after the ACH authorizes the credit card.