Group members: this is the place for your learning diary. Use this to post your zipped-up site at least once each unit, and your reflections as often as you wish (at least once per unit). Please write your reflections directly in the post, not as attached files. Where you do need to attach documents, such as for unit 1 designs, use PDF, PNG or JPG formats. You can attach files using the 'Embed content' link in the editor.
QUICK COURSE LINKS: Add blog post - Read latest group posts - FAQs: Course process : Site design : HTML : CSS : JavaScript : JQuery : AJAX : Misc : Podcasts for each unit
Updated resource pages: Unit 1 - Unit 2 - Unit 3 - Units 4 & 5 - Unit 6 - Unit 7
mportant notice: the student web server is unavailable. Until this is fixed, we do not require you to upload your site to the student server. See Running a web server on your local machine for details of how to meet the requirements for the final unit
Work Competed and Learning Outcomes:
Having already been fairly acquainted with JavaScript, what I found most challenging was to find a usable piece of code. After searching far too long, I finally decided to use code that dealt with email validation (the original code as well as the edited code are at the bottom of this document). In my opinion it was poorly written. I edited the code dramatically; it hardly resembles its initial structure. I am quite certain that efficiency was not a priority. It did “work,” however I found that there were some functions with some odd behaviour (or what Kent Beck calls “bad smells”).
My Critique of formValidation.js by Francis Cocharrua:
Rationale for What Has Been Done:
Honestly, I decided it was necessary to complete this unit eventually. Instead of trying to find the perfect code to apply, I would edit said code to my hearts content. And that I did. I am quite pleased with the result as well. I am in no way disappointed with my experience. I found the ordeal to be invaluable; the lessons were worthwhile.
I am curious to see my feedback about commenting on this piece of code. There are actually very few comments in total, however I believe that the result is actually very readable to a somewhat experienced programmer. For example:
if(!vaildCharacters(emailAddress) ||
!vaildDomain(emailAddress))
return false;
This statement is fundamental to the functionality of the program and there are no comments. However, the code itself explains the functionality. It is read:
If not valid characters email address, or not valid domain email address, return false.
Which would essentially be the result of writing pseudocode. I was thinking about creating a function called “not” which would simply be
function not(arg){return !arg;}
So that this type of code would be even more clear:
If(not(validCharacters(emailAddress)))…
I’ve adopted this style from Martin Fowler and Kent Beck in the book Refactoring: Improving the Design of Existing Code, theysay:
“The real key to making it easy to understand small methods is good naming. If you have a good name for a method you don't need to look at the body. The net effect is that you should be much more aggressive about decomposing methods. A heuristic we follow is that whenever we feel the need to comment something, we write a method instead. Such a method contains the code that was commented but is named after the intention of the code rather than how it does it.”
The Good and The Bad:
I really cannot say anything negative about this experience. Yes, the code was below par (in my opinion), but no one has the same coding style. It can often be difficult to judge different styles as better or worse. This assignment really allowed me to look at the fundamentals of programming; one of my heroes Jim Rohn says:
“Little mistakes repeated over time lead to disaster. Should change, could change, don’t change. I’m telling you it will lead to disaster.”
And it applies to a whole lot more than just programming. Make no mistake, little inefficiencies scattered throughout a program may seem insignificant now, but who knows one hundred lines from now, or ten thousand lines from now. I implore you to think of the final product, what will ten bytes here, three bytes there lead to? That lag could lead to a visitor leaving before they have a chance to see the material.
What I Would Have Done Differently:
In retrospect, I spent a lot of time looking for the perfect piece of code. I realize now, that I must write such a piece. Who in the World besides me is going to write the code for my site (well unless I pay or inspire them to). There’s a good chance that I could have saved about an hour if I had a slightly different perspective on the subject.
JavaScript Files and Description:
The code is very straight forward. It checks whether the characters of an email address (given by the input field "mail") are valid, and that the at sign and period are used conventionally. It verifies that:
An event listener is then created for when the input field "mail" loses focus. If these conditions are not met, the elements border color shifts to red. If the conditions are met then the border color changes (or remains) blue.
Zipped Web Directory:
Live Site @ http://student.athabascau.ca/~jessemc11/index.html
The Landing is a social site for Athabasca University staff, students and invited guests. It is a space where they can share, communicate and connect with anyone or everyone.
Unless you are logged in, you will only be able to see the fraction of posts on the site that have been made public. Right now you are not logged in.
If you have an Athabasca University login ID, use your standard username and password to access this site.
We welcome comments on public posts from members of the public. Please note, however, that all comments made on public posts must be moderated by their owners before they become visible on the site. The owner of the post (and no one else) has to do that.
If you want the full range of features and you have a login ID, log in using the links at the top of the page or at https://landing.athabascau.ca/login (logins are secure and encrypted)
Posts made here are the responsibility of their owners and may not reflect the views of Athabasca University.