LA 6-3 Weekly Coding Activity

This week we added a switch to our coding repertoire.  A switch is just another variable the code must account for, and it gives us an opportunity to control when one (or more) components of our physical object is receiving instructions from the computer.

I kept mine pretty simple.  The physical "switch" I used was just a piece of wire connected to my A5 pin with an alligator clip.  When I pressed that wire to my negative bus, the circuit was closed (completed) and my LED's came on.  When I removed the switch wire from the negative bus, the circuit was opened (not connected) and my LED's stayed off.



Here is what my code looked like:

int BlueLED  = 11;  
int RedLED = 3;  
int switchPin = A5;  
int switchValue;    


void setup()

{
      pinMode(BlueLED, OUTPUT);      
      pinMode(RedLED, OUTPUT);        
      pinMode(switchPin, INPUT);        
      digitalWrite(switchPin, HIGH);    
 }


 void loop()                                      
{                                                  

      switchValue = digitalRead(switchPin);        




      if (switchValue == LOW) {                    
          digitalWrite(BlueLED, HIGH);              
          digitalWrite(RedLED, HIGH);
      }                                              

      else {                                        
          digitalWrite(BlueLED, LOW);                
          digitalWrite(RedLED, LOW);
      }                                              

}

This was really the first time we were introducing input into our code (with the Arduino, anyway.)  I had to physically do something in order for my code to work.  That will open up a world of possibilities for coding in the future.

The computational thinking I am practicing when I code a switch would be: algorithms and procedures, because my switch has to have closed the circuit before any other functions of the code will work; automation, because I want the computer to always be checking the switch pin to see if the circuit is closed, I don't want to have to tell the computer to look each time I complete the circuit, I want it always looking; and it got me thinking a little about parallelization, because I wonder if there's a way to combine my LED's on different pins into one variable, so that if my circuit is closed, the code will illuminate all pins.  Hmmm....

L.A. 5-3

This week in Creating with Code, we used language-based coding and physical objects to create something that would fit in our community garden.  Our professor provided all of us newbies with a Lilypad Arduino, an introductory Arduino board which allows you to learn to program with relatively accessible hardware and software.  It took me a few long hours to get my Arduino set up, but if you stick with it you will learn a lot about your computer and your new board, and you'll be able to really dig into the world of coding!

Once I had installed all the drivers I needed to run the Arduino software (misery, but rewarding misery,) setting up the hardware was a cinch.  The Lilypad model my instructor provided was just a USB cable away from transferring the code I wrote on my computer to the physical objects on my coffee table (LED's, alligator clips, some regular wires, and a bamboo plant.)  Away I went.

It was neat to be able to grow from looking at the code like a foreign language, to changing a few things as instructed by sewelectric's tutorials, to recognizing a few commands that I could modify and see the immediate result.  When you change something with Arduino, you can test your code by hitting the Compile button; if there's an error, you've just got to go back to your lines of code and see if you forgot some punctuation that exists in other, provided lines of code.  It's challenging, but not really frustrating, because you know exactly where to look, and the beginner "Blink" code doesn't contain that many lines.

For our weekly activity, we used what coding we had learned and connected it to physical objects. We used that same "Blink" code on an LED that we wired to our board.  We added more LED's.  We changed the code so they all blinked at once.  So they all blinked at different times. I changed my code so that they blinked in sequence, up my plant.  

Check it out!

Here's what my code looked like:

LA 4-2 Introduction to Text- Based Coding

Dinosaur

Coding with Java is different than coding with blocks (even if you're introduced to Java by dragging and dropping blocks!)  What was cool about Vidcode was the way it let you drag blocks to keep it simple, but shoed you what those blocks meant.  Later, it let you just type the code to get a feel for the necessary attention to detail on punctuation, spacing, ordering.  You learned the language in baby steps.

I have some experience with text based coding from designing websites with HTML.  I took a class in a summer camp in middle school where we learned HTML, both the concept and the language, and used it to put together a functioning, multi-page website.  I designed a forum in high school on s3.invisionfree.com, and most recently last month we did some basic site design in my Digital Production class.  I've never played around with Java, but I can almost relate it to knowing Spanish, and then trying to learn French.  You know the basic format.  You know how sentences go together.  You just have to learn the right words.

Vidcode did a great job of showing me the ropes, and then letting me run around with them.  It reminded me of the quote I've been working with from our reading, Mindstorms: "when a child learns to program, the process of learning is transformed. It becomes more active and self-directed. In particular, the knowledge is acquired for a recognizable personal purpose."  There was an immediate correlation between me understanding how to write and modify a line of code to the dinosaur getting more or less blurry.  I knew what I wanted to do with the image, and I got to watch how what I changed in the code changed the picture.  Before moving on to the next step of what I was going to learn in the lesson, I started messing with other variables to see what kind of effect they would have.  I wanted to do something, so I learned how to do it, either by reading the instructions, or taking what I had learned from one instruction and applying it to something I had written earlier.  

When we were designing sites in my graduate-level course, the teacher had to tell us four or five times to come out of our code and listen to what he had to say.  People were hooked!  On learning.

L.A. 4.1 A Serious Look at Visual Coding

This week I expanded my understanding of coding with blocks by learning a few new commands, and the idea of stringing several commands together. You can really do some neat stuff by organizing and arranging some pretty basic commands in different ways.

This SNAP activity has you building what could be a mobile app. You create the basics, having Alonzo move when you click him, and you build and build until you're scoring points if you click him fast enough, losing points and jumping him around if you miss, he gets faster and faster and you can even challenge yourself with a high score.

The activity's great because they give you all the commands you need to complete each step (they even highlight the new ones you'll use in that step) but you have to come up with how you can use those, where you can put them, to achieve the goal.
The first step that stumped me was #4; the introduction of the forever command, which acted basically as a loop. I wanted Alonzo to move if I clicked him, but I also wanted him to move if I didn't click him fast enough.

Here you can see that I told Alonzo to talk and turn every time I clicked him.  However, I also wanted him to move around if one of two conditions were met; if I clicked him, or if a certain amount of time had passed.  (This screen shot is from a few steps later and you can see the score coming into play as well.)  This is a great command for putting some autonomy into a sprite.  

I also worked more in depth with variables than in my Scratch game.  I had a few modifiers for my score: increase with clicks, decrease with failed clicks, and don't go below 0.  This is an important feature for designing a game, and could be used in other applications:  If there's nothing to do this with, then don't do that.  This seems obvious, but programs don't do obvious, they do what you design, and they might find an interesting way of doing that thing anyway and really messing up your program.