Question on Assingment0: I forgot where we should ask questions about assignments, so I put it here. Following AWDR for Mac OS (Leopard), I got Mongrel 1.1.4 instead of 1.1.5. Instruction did not mention update of Mongrel to 1.1.5. Should this be done. I don't know how to downgrade. So, I am trying to be cautious here.
vaughanatworld
· 1 year ago
Where is the Assignment1 zip file? I am not seeing a link to the right of the Assignment 1 bullet. I do not see it on the downloads page and I do not see it on the Assignment 1 page. I am going in circles
vaughanatworld
· 1 year ago
Also I am not seeing the lecture 2 notes. In fact, I am not seeing anything to download on the downloads page.
jgn
· 1 year ago
Please send an e-mail to me at john at 7fff dot com, and/or to your section leader. Make sure to include your full name as registered for the course.
sconnall
· 1 year ago
The test framework has a method for retrieving our student id and I'm unsure whether this is our ID Number (starting with '@') or the HUID?. Or does it really matter?
jgn
· 1 year ago
Use the one starting with @.
DanielS
· 1 year ago
Did we need to provide comments for Assignment 1? Also what do you consider to be sufficient comments in general? Are there any specific requirements?
jgn
· 1 year ago
No comments are required for Assignment 1.
For Assignment 2: Review what we say in instructions/rdoc/index.html -- We have tried to be clear. Did you read it?
Here's what we say for Assignment 2.
Along the way, add whatever documentation is appropriate internally. Internal documentation should note concisely anything fancy, clever, interesting, or hard to understand.
Before submitting, you will write a file called readme.txt for the root of the project. It must describe what you did, in particular how you tackled the hand evaluation methods in the Hand class. We have put a very short readme.txt in place to get you started. More on the readme.txt below.
Internal documentation and writeup (the readme.txt). Is the internal documentation concise but clarifying? Does the readme.txt explain to me, in sentences and paragraphs, how your code works?
NOTE: There is no need to write things like "The Card class represents a playing card." Please, do not state the obvious. If you feel that you need to address this briefly, you may, but do not repeat the assignment or the requirements for your implementation.
NOTE: There is no need to write RDoc (public comments before "class" and public methods) for the tested methods in Card, Deck, and Hand. Why? Because the documentation we hand out is what you must code to. If you ADD public methods, provide RDoc comments for them.
You must specifically address your strategy for evaluating hands. Not doing so will render the 15% portion of the grade devoted to documentation very close to 0.
You must discuss any additional files, classes, or methods that result in additional functionality or convenience for you as the implementer.
It is hard to imagine a readme.txt that is fewer than 350 words. Please make an ordinary text file. No Word, PDF, etc.
What should the readme.txt look like?
Put your name, the course name, and the assignment number at the top of the readme.txt.
The audience of the readme.txt is yourself or another technical staff member such as yourself. The reader knows Ruby and Rails, but may not currently be coding in it. This reader will be responsible for maintaining your code in the future. The reader may be your technical manager. Therefore:
1. Your writeup must be clear. 2. Your writeup must explain where everything is. If you introduce new files, classes, or public methods, say where they are, and what they do, and why they‘re important. A good way convey this kind of information is in the form of a list. 3. If you do anything fancy, you have to explain yourself. 4. The fact that the audience is also yourself is important. Think of what you are doing as a letter to yourself, which you will read in a year long after you‘ve forgotten the code. You will kick yourself if you find your own writing unclear or confusing.
Morris
· 1 year ago
When can we expect to be seeing our grades for assignment 1?
jgn
· 1 year ago
Soon.
Ana
· 1 year ago
Did the grades get sent out yesterday? I haven't gotten mine.
jgn
· 1 year ago
I asked the TAs to send them out last night, but it was pretty late . . .
zubair
· 1 year ago
hi
Is there draft copy of Assignment 3 has been posted. I am having a hard time to find it.
Thank you
jgn
· 1 year ago
I'm not quite done with the Rake task -- soon.
Ana
· 1 year ago
When do you think we might see grades for assignment 2?
sa
· 1 year ago
I cannot find the rest of the assignment 3? Where is the instructions for that? I've downloaded the zip with migration one, but the doc-file is empty of instructions.
jgn
· 1 year ago
That download shows only the mgrations and associations for the first milestone -- it is, effectively, the "solution" for the first (optional) milestone -- I am still working on getting the list of "finds" for milestone II and the final version of Assignment 3 to you.
sa
· 11 months ago
Will there be a solution posted for project 3? Also I am having problem with this. I have a table - users, which has email column. Now i want to enable all users to search the user table with the query 'email'. <%= form_tag( { :action => :find, }, { :method => :post }) %> <%= text_field "user", "email", "size" => 20 %> Search with the email
<%= submit_tag( "Search" ) %> Well, the controller that handles is 'search' controller. I have tried getting the email and print it out on the screen, but it always prints nil. How do I get this attribute?
Keith
· 11 months ago
How are you trying to access the email field? params[:user][:email] should work.
sa
· 11 months ago
that does work in my console window, but it does not return anything in the controller. e.g. if i say email=params[:user][:email], and then used it like this: User.find(:first, :conditions => "email = email"), it does not return anything. The only way it works if I hardcode that email in the query.
In both cases, the last "email" in the state is a variable for the e-mail address you want.
For both of these constructs: Review AWDR!! The first is about using parameters for a SQL query. The 2nd is about using a Hash for the conditions. I like the latter for simple finds.
I forgot where we should ask questions about assignments, so I put it here. Following AWDR for Mac OS (Leopard), I got Mongrel 1.1.4 instead of 1.1.5. Instruction did not mention update of Mongrel to 1.1.5. Should this be done. I don't know how to downgrade. So, I am trying to be cautious here.
For Assignment 2: Review what we say in instructions/rdoc/index.html -- We have tried to be clear. Did you read it?
Here's what we say for Assignment 2.
Along the way, add whatever documentation is appropriate internally. Internal documentation should note concisely anything fancy, clever, interesting, or hard to understand.
Before submitting, you will write a file called readme.txt for the root of the project. It must describe what you did, in particular how you tackled the hand evaluation methods in the Hand class. We have put a very short readme.txt in place to get you started. More on the readme.txt below.
Internal documentation and writeup (the readme.txt). Is the internal documentation concise but clarifying? Does the readme.txt explain to me, in sentences and paragraphs, how your code works?
NOTE: There is no need to write things like "The Card class represents a playing card." Please, do not state the obvious. If you feel that you need to address this briefly, you may, but do not repeat the assignment or the requirements for your implementation.
NOTE: There is no need to write RDoc (public comments before "class" and public methods) for the tested methods in Card, Deck, and Hand. Why? Because the documentation we hand out is what you must code to. If you ADD public methods, provide RDoc comments for them.
You must specifically address your strategy for evaluating hands. Not doing so will render the 15% portion of the grade devoted to documentation very close to 0.
You must discuss any additional files, classes, or methods that result in additional functionality or convenience for you as the implementer.
It is hard to imagine a readme.txt that is fewer than 350 words. Please make an ordinary text file. No Word, PDF, etc.
What should the readme.txt look like?
Put your name, the course name, and the assignment number at the top of the readme.txt.
The audience of the readme.txt is yourself or another technical staff member such as yourself. The reader knows Ruby and Rails, but may not currently be coding in it. This reader will be responsible for maintaining your code in the future. The reader may be your technical manager. Therefore:
1. Your writeup must be clear.
2. Your writeup must explain where everything is. If you introduce new files, classes, or public methods, say where they are, and what they do, and why they‘re important. A good way convey this kind of information is in the form of a list.
3. If you do anything fancy, you have to explain yourself.
4. The fact that the audience is also yourself is important. Think of what you are doing as a letter to yourself, which you will read in a year long after you‘ve forgotten the code. You will kick yourself if you find your own writing unclear or confusing.
Is there draft copy of Assignment 3 has been posted. I am having a hard time to find it.
Thank you
Also I am having problem with this. I have a table - users, which has email column. Now i want to enable all users to search the user table with the query 'email'.
<%= form_tag( { :action => :find, }, { :method => :post }) %>
<%= text_field "user", "email", "size" => 20 %>
Search with the email
<%= submit_tag( "Search" ) %>
Well, the controller that handles is 'search' controller.
I have tried getting the email and print it out on the screen, but it always prints nil. How do I get this attribute?
e.g. if i say email=params[:user][:email], and then used it like this: User.find(:first, :conditions => "email = email"), it does not return anything. The only way it works if I hardcode that email in the query.
or
User.find( :first, :conditions = { :email => email } )
In both cases, the last "email" in the state is a variable for the e-mail address you want.
For both of these constructs: Review AWDR!! The first is about using parameters for a SQL query. The 2nd is about using a Hash for the conditions. I like the latter for simple finds.