Thursday, May 27, 2010

Chapter 8 and Chapter 9 - Plus A Solution!

So the Chapter 7 assignment was really vexing me. I could see what they wanted me to do (and could have done it easily in another language), but I wasn't getting my syntax right. My initial error (before I took the problem to class) was a typing problem. I was forgetting to force type to string. Then it was a syntax issue. I forgot the parenthesis in .toString();. Now I'm right as rain and making progress again. I'll knock that assignment out today, and then complete the test.


We worked on chapter 8 and chapter 9 in class. Those deal with branches (ifs and cases) and arrays. I felt very comfortable with those - they work like they do in C, except for the "for in" loop which is kind of a nifty idea. One of the things that I had a lot of fun with was that the guy who sat next to me wanted to experiment a little. One of the examples that we went over sets up an html table using a loop. He wanted to put a link in each td element, but wasn't quite sure how to handle that - so I showed him.


When we were going over branching, the instructor seemed to favor branching by Case as easier than using If statements. I'm not sure if I agree with that. I think it depends on what you're trying to accomplish. If I'm prompting the user to make an either/or choice - IE do you want this shirt in Blue or Green, I think an if statement is the way to go. I think Cases are better when you're giving the user a number of options - IE Do you want: A) A burger, B) A burger and fries, C) A burger, fries, and a soda, D) A burger, fries, soda, and an apple pie? Because cases can "fall through" they work really well for this, where using ifs would be possible but obnoxious to set up. In web terms, ifs are radio buttons, or selections (usually) whereas case branches are more suited to check boxes.


I'm really enjoying myself here. One thing I love about this instructor is his willingness to experiment. At one point, when we were covering associative arrays, someone asked if you could still access array elements by number. It didn't work (undefined), but it was fun to see what would happen. We had a similar situation with typing - where we observed the interpreter retyping a string as an int during a comparison. Very cool stuff.

Tuesday, May 25, 2010

Thoughts on the First Assignment

6-1 Future Value the First


I think I had difficulty with this simply because of the bad web design on the html portion. I really hate the way they abused that drop box. Drop boxes are for discrete values (IE you can get this car in Red, Blue, Green) - not numbers. Use a text box for numeric values (at least in the sense of the assignment - which was what amount was going to be invested.)

I got hung up a bit on typing. I'm used to languages (IE "C") that type at declaration. I'm not sure what the default typing is for Javascript (huh - apparently it's "dynamic") - but it really screwed me up in the first assignment. Not a big deal though.


7-2 Future Value the Second


This has been a cakewalk so far, but I'm still working on the difficult bit. It starts out letting the user input an initial investment, interest rate, and number of years. At first, the assignment calls for you to break the script by generating values too large for Javascript to deal with. Then it has you kill the loop (you switch the value for "i"), and return a message to the user via the alert method. Then it gets interesting.


We change the text boxes from user input to a random number generator (a function for this is provided in the example source), and then have to set up the calculate function to use it properly. After that, you have to format the output with a dollar sign, commas in the expected places and a decimal point. I think I see how this will be accomplished.


Okay, what I'm doing is this. Create variables for cents, hundreds (covers ones, tens, hundreds), thousands (thousands, ten thousands, hundred thousands), and millions. I'm also creating a variable to store the index - which is the decimal point. That will be decimalPoint = futureValue.indexOf("."). From there cents = futureValue.subscript(decimalPoint+1, decimalPoint+2). Where I'm dicey is whether you can use negative values in the attributes but if you can it'll go like this:

  • hundreds = futureValue.subscript(decimalPoint - 1, decimalPoint - 3)
  • thousands = futureValue.subscript(decimalPoint - 4, decimalPoint - 6)
  • millions = futureValue.subscript(decimalPoint - 7, decimalPoint - 9)

This should provide enough places, but then we have to test for millions and I think that's a place I may have difficulty. My thinking is that before the branch, use parseFloat on futureValue and test it to see if it contains a value greater than 999,999.99 - if so it'll output with the millions place, if not, we don't include it.


Okay, game on. I'll update this when I see how it works out.

Thursday, May 20, 2010

First Day - Wrap Up

All in all, the first class went well. We had to do a bit of backtracking for the people who didn't know HTML/CSS but even that was pretty cool. I like doing stuff "on the fly" that it isn't written up in the book. We had to do a good bit of debugging, but eventually our script worked.


It was a pizza delivery website, and we had to fix the usual syntax problems (parenthesis/braces, etc) - but the real problem was an ID we attached to the body tag on the html side which wasn't referenced in the script. I thought that would just show as a "warning" like an unused variable in C (at least in my IDE that's what happens) but that the script would still execute. I guess it was because the get.ElementById function wasn't addressed properly because of it? I guess with our body tag it would have been get.ElementByID(test.order) instead of just (order)? I should really ask about that.


I'm feeling a lot less stress about O. O. - it still seems weird compared to doing procedural, but it doesn't feel like reading Martian or anything. The way it was explained to us is that properties are parts of the object. For instance, the clock object has an hour, minute and second property. You'd use a method to change or modify each of those properties. In terms of html, things like text boxes, radio buttons, check boxes and whatnot are objects. Natch. I'm still a little worried about remembering all of it, but I suspect it's like anything else - you remember the stuff you use all the time, the rest you look up in the reference.


I'll jot more as I finish up the first two assignments.

Wednesday, May 19, 2010

Day the first - Ifs and numbers

First day of class, I'm here early thinking about our first assignments.
Chapter six deals with most of the normal programming stuff. Doing decision making with if/elseif/else, and loops. These aren't really anything new and the structure is c-like enough that I'm understanding it. My first real problem is actually just working with somebody elses's source. I'm used to being given a problem (say, calculating interest on a savings account)and being asked to write a script or program to solve it. Here, we're using examples from the book. I suppose it is also a case of first day jitters. <\p>

While I'm excited about class, I'm also looking forward to getting home and taking a good look at the Buzz API that Google announced - it looks like they're using Javascript to do calls to the API, so that might be good hands-on practice. I really only got to see a little bit of it before had to start getting ready. I'm also curious what you'd need to make widgets for Wave, I'd really like to play around with that more now that its public. I sent out a bunch of invites and . . . nobody every used wave - not even once. I guess that makes for a paucity of curiosity among my friends. Not a good sign. I just cannot understand the mindset where in which a person wouldn't want to tinker around with something new.


Well, about time for class to start and I'm all set up. I'll post more after class.