This week we will be exploring GreenFoot -- an alternative IDE which focuses on 2D graphics for Java applications.
GreenFoot can be found here: http://www.greenfoot.org/door
We will be exploring the Joy of Code video series here: http://blogs.kent.ac.uk/mik/category/joy-of-code/page/2/
We used the Hedgehog program here: http://www.greenfoot.org/static/joc/material/hedgehogs.zip
And Trick the Turtle here: http://www.greenfoot.org/static/joc/material/trick-the-turtle.zip
Thursday, October 30, 2014
Thursday, October 23, 2014
Computer Logic
Artificial intelligence isn't true intelligence. Computers do not yet have the ability to think; to learn. A computer is only able to do what it is told. If you're playing a game, the character in the game basically follows a flow chart to know what to do. If you walk into the virtual room, the character you encounter will react in certain ways -- if you have already found the magic sword the guard may attack... or if you are a magician the guard may run afraid... or if you have joined a guild the guard may welcome you in and show you the attack plans. The guard will only follow the instructions given. The guard will never think of something on his own... or be in a bad mood and act a certain way... or decide to take the treasure for himself.
As a programmer, you have to think of all of the possibilities and program for those choices. We aren't [yet] making a cool video game where characters are interacting with each other, but we will be creating programs with logic problems. Flowcharting helps, but we have to remember to be specific. If you have ever used Siri on an iPhone or iPad, you're probably encountered this.
You may have also played with "bots" in "shooter games" (like Counter Strike or Team Fortress) where the bots get confused over simple situations. Sometimes you'll find them running at full speed, but they are stuck in a corner or behind a box. The programmer neglected to write a "what if" scenario for whatever got them stuck. Computers (and "artificial thinkers") can only do what you tell them to do.
Here's an example [from a JAVA for Dummies book] illustrating this principle:
Just yesterday, I was chatting with my servant, RoboJeeves. (RoboJeeves is an upscale model in the RJ-3000 line of personal robotic life-forms.) Here’s how the discussion went:
As a programmer, you have to think of all of the possibilities and program for those choices. We aren't [yet] making a cool video game where characters are interacting with each other, but we will be creating programs with logic problems. Flowcharting helps, but we have to remember to be specific. If you have ever used Siri on an iPhone or iPad, you're probably encountered this.
You may have also played with "bots" in "shooter games" (like Counter Strike or Team Fortress) where the bots get confused over simple situations. Sometimes you'll find them running at full speed, but they are stuck in a corner or behind a box. The programmer neglected to write a "what if" scenario for whatever got them stuck. Computers (and "artificial thinkers") can only do what you tell them to do.
Here's an example [from a JAVA for Dummies book] illustrating this principle:
Just yesterday, I was chatting with my servant, RoboJeeves. (RoboJeeves is an upscale model in the RJ-3000 line of personal robotic life-forms.) Here’s how the discussion went:
Me: RoboJeeves, tell me the velocity of an object after it’s been falling for three seconds in a vacuum.
RoboJeeves: All right, I will. “The velocity of an object after it’s been falling for three seconds in a vacuum.” There, I told it to you.
Me: RoboJeeves, don’t give me that smart-alecky answer. I want a number. I want the actual velocity.
RoboJeeves: Okay! “A number; the actual velocity.”
Me: RJ, these cheap jokes are beneath your dignity. Can you or can’t you tell me the answer to my question?
RoboJeeves: Yes.
Me: “Yes,” what?
RoboJeeves: Yes, I either can or can’t tell you the answer to your question.
Me: Well, which is it? Can you?
RoboJeeves: Yes, I can.
Me: Then do it. Tell me the answer.
RoboJeeves: The velocity is 153,984,792 miles per hour.
Me: (After pausing to think . . .) RJ, I know you never make a mistake, but that number, 153,984,792, is much too high.
RoboJeeves: Too high? That’s impossible. Things fall very quickly on the giant planet Mangorrrrkthongo. Now, if you wanted to know about objects falling on Earth, you should have said so in the first place.
Here's an interesting video from a game developer doing "AI":
Flow Charting
The first example is lengthy, but the first 6+ minutes are the part I want you to focus on -- unless of course you want to learn C++ programming. The professor does a great job of demonstrating a basic problem that we need to solve, lays it out in steps, and then applies to steps to a flow chart.
This is a flow chart of making decisions in your life:
Here's a funny flow chart in action: http://www.youtube.com/watch?v=k0xgjUhEG3U
And lastly... this little gem. :)
Programming is about solving problems. The entire purpose of writing a program is to solve a problem which, in general, consists of multiple steps:
After we understand a given problem, we can break the problem into manageable pieces and design a solution. For example, if we wanted a program to figure out the least possible number of coins to give a customer as change, we might want to first subtract the amount owed from the amount paid, then figure out how many quarters would go into that, take the remainder and figure out how many dimes would go into that, and then move on to nickels and then pennies. For more complex problems, making a flow chart can help to organize your thoughts and identify potential issues before you begin programming.
Below are some potential "problems" for you to solve using flow charts.
Flow Chart Practice:
This is a flow chart of making decisions in your life:
Here's a funny flow chart in action: http://www.youtube.com/watch?v=k0xgjUhEG3U
And lastly... this little gem. :)
- Understanding the problem.
- Breaking the problem into manageable pieces.
- Designing a solution.
- Considering alternatives to the solution and refining the solution.
- Implementing the solution.
- Testing the solution and fixing any problems.
Below are some potential "problems" for you to solve using flow charts.
Flow Chart Practice:
- A movie theater wants a program that will show admission price based on age. They want to charge children (under 12) and seniors (65 and older) $5.25. Everybody else will pay $9.25. They want to ask "How old are you?", let the person put in their age (in years), tell them the price, then tell them to "Enjoy the show!".
- A daycare provider wants to give gumballs to their kids, but they want a program that will ask the worker, "How many gumballs?" and then "How many kids?". Then it should divide the gumballs per kid (gumballs/kids). Finally it should say, "Each kid gets X gumballs."
- You decide to write an app for a SmartPhone. You want to do a Magic 8 Ball app where you ask a question and it gives you a "Yes" or "No" answer.
- You want to write a program that will pick a random number between 1 and 1000. Ask the player to guess a number and tell them if they are too high, too low, or if they get the number correct. The program should keep running until they guess the number correctly.
Getting Started
Your homework is to install the JAVA software [on your home computer] as follows:
And demonstrating some of the JAVA epicness... hardcore.
- Install JDK on your home computer and/or laptop (wherever you plan to work on Java programming)
- Install the Java API (Docs)
- Install BlueJ on your computer/device.
- Install GreenFoot on your computer/device.
Wednesday, October 22, 2014
About Programming
Why Is Computer Programming Important:
The Early Days of Programming
During the early 1980s, Chris worked for a computer software firm. The firm wrote code for word processing machines. (At the time, if you wanted to compose documents without a typewriter, you bought a “computer” that did nothing but word processing.) Chris complained about being asked to write the same old code over and over again. “First, I write a search-and-replace program. Then I write a spell checker. Then I write another search-and-replace program. Then, a different kind of spell checker. And then, a better search-and-replace.”
How did Chris manage to stay interested in his work? And how did Chris’s employer manage to stay in business? Every few months, Chris had to reinvent the wheel. Toss out the old search-and-replace program, and write a new program from scratch. That’s inefficient. What’s worse, it’s boring.
For years, computer professionals were seeking the Holy Grail — a way to write software so that it’s easy to reuse. Don’t write and rewrite your search-and replace code. Just break the task into tiny pieces. One piece searches for a single character, another piece looks for blank spaces, a third piece substitutes one letter for another. When you have all the pieces, just assemble these pieces to form a search-and-replace program. Later on, when you think of a new feature for your word processing software, you reassemble the pieces in a slightly different way. It’s sensible, it’s cost efficient, and it’s much more fun.
The late 1980s saw several advances in software development, and by the early 1990s, many large programming projects were being written from prefab components. Java came along in 1995, so it was natural for the language’s founders to create a library of reusable code. The library included about 250 programs, including code for dealing with disk files, code for creating windows, and code for passing information over the Internet. Since 1995, this library has grown to include more than 3,000 programs. This library is called the API — the Application Programming Interface.
Every Java program, even the simplest one, calls on code in the Java API. This Java API is both useful and formidable. It’s useful because of all the things you can do with the API’s programs. It’s formidable because the API is so extensive. No one memorizes all the features made available by the Java API. Programmers remember the features that they use often, and look up the features that they need in a pinch. They look up these features in an online document called the API Specification (known affectionately to most Java programmers as the API documentation, or the Javadocs).
The API documentation describes the thousands of features in the Java API. As a Java programmer, you consult this API documentation on a daily basis. You can bookmark the documentation at the Sun Microsystems Web site and revisit the site whenever you need to look up something. But in the long run (and in the not-so-long run), you can save time by downloading your own copy of the API docs.
Subscribe to:
Posts (Atom)