Beginning 4A

[Renn Maas]

Do I write methods in 4A. It says that the instructors code uses 4 methods but it isn't until 4B that it talks about writing your own methods. Thanks for any information

[Pauline McNamara]

Hi Renn, welcome to the bump in the trail known as Say!

The instructor's solution to 4A actually has 2 methods. You can create a method for 4A if you want to (and it makes sense ), but it's not required until 4B, where reading up on creating methods is part of the assignment.

Hang on to your saddle, the 4A/B ride can be a bumpy one!

Enjoy,
Pauline

[Renn Maas]

Thanks for the quick response! I will give it a try! Thanks for the heads up on the bumpy trail ahead. I don't know if I am ready but jumping into the saddle and moving forward.

[John Abong]

java4A/B(Say) makes me feel very scatter-brained. I don't know whether to treat the user input as a string (to work with the string length) or a number (and calculate each column). Since the class' purpose is to parse a number between 0 and 100 I want to assume that I don't have to be concerned with anything but those numbers. Kind'a makes it a little easier.

I suppose that each lesson has it's roots in previous lessons, so I'm inclined to reuse that code. Either way, the effort won't soon be forgotten. I'm still grateful for the interaction.

John A

[Marilyn de Queiroz]

It can be done either with Strings or with numbers. It depends on your code. Your best bet is to choose one course of action and send it to your nitpicker. Remember to test whether the number is in the range you want.

[John Abong]

I believe that a silly question is one that is never asked. Most times I need a subtle nudge to get past the minutia. That's probably why I get hung up in self-study via books and why this interaction is far superior. I can't ask a book about minutia.

giddyup

[Carol Murphy]

The minutia gets me, too. It's like standing in front of something that fills my entire field of vision, and it never occurs to me to try and walk around...........

[John Abong]

I "fear" walking around because I might be wanlking around the "first brick" in the foundation. Mistakes are a good learning tool but if you don't know what is a mistake and what is not then you might miss the lesson.

I once saw a woman perplexed by a broken piece of metal sticking out of an electrical socket in a restaraunt wall. I watched her move in to deal with it, stop and then move back, never sure what to do. I knew that it was the ground pin from an electrical cord that had broken off and that if she touched it she would not be injured.

So after watching her move back and forth in hesitation a few times I confidently strutted over and pulled it out for her. She looked at me as if I was insane. Like, "you nut, there's voltage in there!" I wanted to explain to her why I couldn't have gotten injured, but I had to get back to the buffet

My knowledge of electrical circuitry let me act without "rethinking" about it. I am the perplexed one now; the student waiting for the teacher...

[Carol Murphy]

Good story!
I guess what I meant to say is that sometimes I get stuck on something that is really a small piece of the whole picture, and it fills my entire field of vision because I've become fixated on it. If I walk around it, then most times I see something that puts things into proper perspective and I get a better idea of how the piece fits into the whole picture.
But the minutiae still gets me!

[John Abong]

Yes, Carol, I see now that fixating on the (java) minutae can only be helpful in understanding the tokens' functional spec outlined in the "whole" API.

Learning how to create the class structure by sorting out the tradeoffs amongst token choices means "getting to know" the whole picture; the API.

Which, of course, means (to me):
1. AFTER DEFINING THE PROBLEM.
2. Pick the best tokens (from the API) to "solve" the problem.
3. Build the class structure (syntacticaly correctly).
4. Refine the structure.
5. Test and retest the class.

I think I'm starting to see the big picture, too??? I also understand classical guitar, to a degree, and putting that knowledge to "good" use can also be quite painful.

[Marilyn de Queiroz]

Originally posted by john abong:
Learning how to create the class structure by sorting out the tradeoffs amongst token choices means "getting to know" the whole picture; the API.

Which, of course, means (to me):
1. AFTER DEFINING THE PROBLEM.
2. Pick the best tokens (from the API) to "solve" the problem.
3. Build the class structure (syntacticaly correctly).
4. Refine the structure.
5. Test and retest the class.

I think you might have your order wrong. I would say ...
1. AFTER DEFINING THE PROBLEM as best I can
2. Pick the best tokens (from the API) to "solve" the problem.
3. Build the class structure (syntactically correctly).
4. Test the app
5. Refine the structure based on feedback from the user (in this case, the nitpicker) which may clarify the problem
6. refactor the class
7. Test the app
(repeat 5, 6 and 7 x number of times)
8. Present the user (in this case, the nitpicker) with the "perfected" app.

This is the iterative way to develop software as opposed to the waterfall way which is to get ALL the requirements up front, then develop everything, then test everything, and then present it to the user.

As far as this particular assignment is concerned, I have seen hundreds of solutions and I would venture to say that no two are alike. So don't worry that your solution must exactly match the instructor's solution, because it probably won't.

[John Abong]

I'm still chuggin' along with java4b(say). I'm sorting through many of my own "refactorings". I have a concept down and I'm just tailoring it in cattle-drive fashion.

It's a real eye openner! To be continued...

John Abong