Topics Covered: Creating, assigning, reassigning variables; creating and running scripts; console input and output
Go back and review on Treehouse if any topic was unclear.
Now that you can get some input and output, let's do some actual computing. For the first exercise, create a new file in d1/survey called survey_average_age.rb. In this one, we'll also ask for the user's mom's age, a dad's age, and compute the average age of the family (you don't have to ask for the name). As usual, please do not copy paste, but try to write out the code, referencing survey.rb only if you really need to.
$ ruby survey_average_age.rb
Hello!
How old are you?
29
How old is your mom?
45
How old is your dad?
49
Thanks for answering my creepy questions! The average age of your family is 41 years old!
Goodbye!Hint: To convert a string to an integer, call .to_i on a string variable, just like we used .strip. To convert it to a decimal (called a floating point number, or float, in programming) use .to_f.
Now that you have a program that knows a lot about your family, do some stress testing. That means to try different inputs to see how your program responds. What happens if your output isn't a whole number? What if you input a negative number? A decimal? A fraction? Anything else you can think of?
This is actually a pretty important part of programming: making sure your program handles errors well. When you make a website, you can't always guarantee that the user will type in a number in an input field that asks for their age. To make great apps, you have to be dilligent!
Write down the answers to these questions before trying them in irb. Once you're done, show your answers to a TA. Consider the code below:
>> x = 5
>> y = 10
>> x = y + 5
>> y = y + 10
x?y?x being reassigned?y being reassigned?>> y = "hi!"
>> x + y
x?y?>> name = gets
joe
>> hi_name = y + name
name?hi_name now?>> puts hi_name
>> puts hi_name.strip
>> puts "#{hi_name.strip}"
>> puts "#{hi_name}.strip"
Average is a pretty weak form of computation. For the heavy lifting, let's take it back to middle school and the days of the quadratic formula. If your memory serves you well, in an equation of the form
ax^2 + bx + c = 0:
x = (-b + squareroot(b*b - 4*a*c))/2*aand
x = (-b - squareroot(b*b - 4*a*c))/2*aRemember, your a, b, and c values need to be logical. For reference, look up a sample quadratic equation online. Let's write some ruby code to find the two roots of the quadratic equation- or xs. Note, the Ruby method Math.sqrt is helpful for this exercise. Please read up on its usage. :) Next, create a new file named
quadform.rb and make it do as follows:
$ ruby quadform.rb
Hey bru (South African for "bro"). Let's compute some quadform.
Give me an A:
1
Give me a B:
-3
Give me a C:
2
beep computing boop boop...
x is either
1.0
or
2.0
Goodbye!As with before, stress test. Try decimal (float) inputs. Try equations where there is only one real solution, or no real solutions. What should your program do in each case?
Like most things in life, coding requires planning. From movies and pop culture, it seems like young hackers just sit down in their dorm rooms and churn out social networks by the dozens. In reality, a significant portion of programming is planning. For example, before anything can be built at Google, engineers write what's called a Design Document, which outlines all the features, potential pitfalls, and detailed design decisions. Only after all the team members have weighed in and dissected the whole thing can code be written. Similar practices abound at all serious tech companies. In fact, rumor has it that Facebook has had to write thousands of lines of code to work around an early, not-so-well-though-out design decision made by Mark Zuckerberg himself. Facebook may well be millions of dollars richer, had he planned before his coding frenzy. Gosh darn it.
So your next billions-dollar company doesn't fall victim to the same issues, we're going to get in the habit of planning our projects before we start coding. Your personal page is no exception. Create a file called README.md in your personal folder and answer the following questions. (Refresher: to create the file, right-click on the folder in the Sublime sidebar, then choose "New File". Make sure to save, and call it README.md.) No need to write an essay, but a couple of words or sentences about each will really clear up your thinking. You can structure your plans however makes sense to you, but we advise you to follow the following syntax. It's called Markdown (hence the .md in the filename), and it's very handy to know.
## The bru's personal page
#### May 27, 2014
## Overview
#### Motivation
- What do I want to say with this page? What's its purpose?
- What's the target audience? Friends/family? Employers? Groupies?
- Is this a professional page, a portfolio? Just for fun, a design playground?
#### Content
- What do I want to actually put on it? Suggestions:
- Links to things you've made (photos, videos, class projects)
- Yet another blog
- A self intro, with links to how to contact you (FB, Github, etc.)
- Be as specific as you can here
## Design
- What's the look and feel of it? Minimalist? Intricate? Goth?
- You'll do a lot more of this when we start thinking about CSS.
- Will you use images? Icons? From where?
- Do some research! Look at other sites for inspiration.
- http://onepagelove.com/gallery/personal
- Check out the resources page for more.
## Code
You'll be using HTML and CSS, but as you think about your layout,
you might want to start thinking about logical sections of the page
(header, footer, sidebar—if you want any of these things),
and how you might structure those with HTML.
We're encouraging you to use Markdown because it's easy—but if you have another way you want to do it, that's fine! The priority is to get your ideas down, not to learn a whole other thing. If you're curious, though, more info about Markdown can be found here.
The next good coding practice we'll learn is code review. This means looking at someone else's code and reading it line by line to understand it: NOT just casually glancing over it. For this part, pick someone near you and go through each other's code together. You're looking for several things, in both your and your partner's code:
div have a purpose? Could there be a better structure for what their page is trying to look like? Would more or less commenting help people understand what's going on?
Try to give constructive criticism and be open to suggestions about your own code. Borrow each other's ideas and discoveries—coding is meant to be a collaborative process!
There are many ways to add styling to your HTML pages, i.e. style tags and CSS. However, good practice dictates that we should include all our style choices in a seperate CSS file. This way we can clearly differentiate between content and design, keep track of all our style decisions in one place, and easily change them when we need to.
The first thing we need to do is link our HTML page with a CSS stylsheet. We do this by adding a <link> to the CSS stylesheet inside our <head> at the top of our HTML page. This lets our HTML page know where to look for the CSS stylesheet.
...
<head>
<title>The Bru</title>
<link rel="stylesheet" href="./stylesheets/style.css">
</head>
<body>
...
We can now use classes and IDs to link our HTML and CSS files. Classes can be used multiple times to apply styling to numerous HTML items. IDs can only be used once! Remember that classes are referenced in your CSS file using a period, e.g. .class-name, and IDs are referenced using the hash symbol, e.g. #ID-name. Check out Treehouse if you need to refresh yourself on how to implement CSS.
Pat yourself on the back for a great first day—you're well on your the way to becoming an excellent programmer. Make sure to get a good night's rest, overcome any jetlag, and catch up on any Treehouse pre-work.
