I started DevFright towards the end of 2012 with the aim to document what I learn when practicing to code. I started off jumping in to a book called “Objective-C for Dummies” and although the instruction was quite clear, I quickly found that I lacked some understanding of how a few of the basics worked.
Apple Guide on How to Create Apps
Apple has created a handy guide on how to begin learning to create iOS apps. The new guide goes over what you need, where to begin and what documents you need to read to get going. Currently, I am working through the Apple documents and an Objective-C for dummies book found in Week 1 and to be blunt… it’s a lot of reading.
On your path of leaning, expect to be doing a lot of reading and a lot of coding to practice what you are learning. I have found that one of the keys to learning is trying to stop and understand the challenge that you just did. That could be creating a new struct, typedef or even something completely different. If you don’t understand why you are doing something the way you are being taught, then step back and try look at the bigger picture of what you are doing.
CS106A Lecture 3 Notes
Lecture 3 of CS106A covers the last 3 chapters of Karel the Robot. In particular, it covers stepwise refinement, algorithms as well as gives more details about SuperKarel and what extras he can do. Karel is coming to an end after this lecture, at which point you will move on to specific Java rather than being stuck at Java with the limitations of Karel.
Although all lectures are important to watch and take note, this one provides some good examples of the top-down design approach and how you break a program down/decompose it with stepwise refinement. It’s well worth watching and paying attention to this part. [Read more…]
What are Pre-conditions and Post-Conditions in Programming?
I briefly mentioned in my post titled What is Top-down Design and Stepwise Refinement? about pre-conditions and post-conditions. In this post I want to explain the two essential points in greater detail.
These two principles are one of the keys to being effective in programming.
What are Pre-conditions?
Lets start with the first of the two which is titled pre-conditions. A pre-condition in its most simple form is a condition that needs to be “true” for a method to be called. This means that the method you are calling is expecting something to be in place before or at the point of the method being called. [Read more…]
What is Top-down Design, Stepwise Refinement and Decomposition?
Near the beginning of learning Java, you will hear something about top-down design, stepwise refinement and decomposition. This post today will explain what those terms mean as well as provide the reason why you need to tackle programming design with this approach in mind.
Just for the sake of clarity, top-down design is the process of stepwise design and decomposition.
Before you start writing any code for a new program you want to create, you first need to design the program or at least have a specification so that you know exactly what you need to create. [Read more…]
What is a Method? – For Beginners
I just wrote about what a class is, in basic terms for those beginning on the CS106A course at Stanford on iTunes U. The next item I want to cover is what a method is.
What is a Method?>
Java allows you to create methods. In simple and beginner terms (meaning those working on programming with Karel), a method is a set of instructions that can be called on by name to execute. In a few of my previous posts I have already written about methods although I haven’t taken the time to explain exactly what a method is. [Read more…]
What is a Class? – For Beginners
A class in Java can be thought of as a blueprint. If using Karel the Robot as an example, each time we “extend Karel” we are getting a copy of Karel the robot to utilise. The blueprint specifies exactly what Karel can do out of the box. In terms of Karel, the blueprint is held at Stanford and we are not able to modify him. Every person who takes the iTunes U CS106A course takes a copy of Karel each time the program runs. The reason we cannot modify the blueprint is that changes we make would likely break everyone elses programs.
So what we do is become a subclass of Karel… ie, we “extend Karel” which means that our programs make an exact copy. When I use the word subclass, this is the opposite of superclass which is what Karel is to our own implementation. This doesn’t mean that ours is on a lower level… in fact, it could be said that we have more power being a sub-class because we get a copy of Karel and can enhance him with a turnRight() private method. So, our copy of Karel can do more than the blueprint specifies.
How to Create a Karel Subclass
Creating a class of Karel is quite simple. Our code needs a few things for it to work though. The first important line is the import which lets the program know where the blueprint is stored. In the case of Karel, this is held at Stanford at the location on line 1 of the code: [Read more…]
CS106A Lecture 2 Notes
Lecture 1 of CS106A was an introduction to the course which covered what things you will be learning over the next 10 or so weeks. It also included details which are needed to complete the course. You can find my notes over here and as well as my suggestions on how to work on iTunes U with no official dead lines and no one to report back to.
Lecture 2 is where the course starts to get interesting. In this lecture you get to see a program being written from scratch as well as successfully run. You also get to see how a basic program is designed as well as an explanation of why you need to write it with a specific style. After the simple program demonstration, the difficulty level gets notched up very slightly and a demonstration of a program with loops and control statements is used. [Read more…]
Why You Need to Indent Your Code
When programmers write code, they tend to stick to an indentation style which essentially makes the program easier to read. When programs get more complex, there are often a number of lines of code which contain loops within loops amongst other things. If all code was written starting at the left edge of the page for every line, it would quickly become unreadable. Take the following example:
import stanford.karel.*;
public class BeeperPickingKarel extends Karel {
public void run() {
move();
if (noBeepersPresent()) {
pickBeeper();
}
move();
}
{
Although this selection of code is relatively simple and with a bit of effort, is fairly readable, it is still recommended that you indent your code to make the blocks and other statements stand out. Indenting and adding more line breaks in the code above would produce the following:
[Read more…]
What are Control Statements?
In chapter 3 of Karel the Robot, I have learned that Karel uses Control Statements. In chapter 2, Karel simply followed commands in order. Some of these commands were separated in to methods so that a single command could be used to issue several commands from a block, but in essence, Karel would do in order what you told him to do.
Control Statements change things in that you can tell Karel to do something based on a condition of his surroundings or based on a loop so he can do something while something else is true… such as “move forwards if there is no wall ahead”.
Conditional Statements
Two types of control statements are introduced in chapter 3 of Karel the Robot. The first type are called Conditional Statements. These are coded by using what is called the if statement. What this means is that a certain part of the program will run “if” a condition holds true. That condition could be something like “if Karel has beepers in his bag, run this section of code”. When his beepers run out, the program will then stop or move on to the next part.
Example:
if (condition) {
statements put between the curly braces.
}