New Quarter Technology Goals!

I had the enormous pleasure of spending the past week (i.e. my spring break) in San Diego and Los Angeles, taking plenty of time away from the computer and gazing at beaches (and even seals!)

Alas, a new quarter has begun and I’m back to reality and gazing instead at that familiar soft glow of the computer screen.

Each quarter, I like to take some time to reflect and consider what I could improve upon both as an instructor and as a student. To be honest, most of these goals have more to do with my personal development in the tech world than it does with my role as an instructor. This imbalance in goal-making is somewhat out of necessity; as a T.A., I don’t have a lot of flexibility about the use of learning management systems or implementing particular technological requirements. My role is primarily one of support. I don’t say this to devalue my role as a T.A.; rather, I have a feeling that I’ll be more interested in setting more pedagogically-based goals once I have full rein over my own classroom!

TL;DR? Mostly professional goals here, not pedagogical goals. Here we go:

1. Continue work with Code Year 

I know, I know. This blog was supposed to be a space to work through my programming lessons. It’s been about six weeks (!!) since I’ve even opened the page for Codeacademy. In order to make the coding work less onerous, I think I just need to set smaller goals for myself. Earlier this year, I intended to finish a lesson at a time and not take a break until I finished each lesson. Alas, each lesson probably takes anywhere between 3-4 hours to complete, which, as a graduate student, is a significant amount of time to be spending at the computer doing work that is not grading, reading, or writing. With that said, I need to assure myself that it’s OK if I only complete one activity in a lesson per day! As long as I’m DOING the work and maintaining the programming vocabulary, I’ll be in good shape. Besides, I’d like to take advantage of some of the social networking integration and share my progress on Facebook to receive some digital pats on the back. No shame.

2. Port this blog to my own domain 

For my UWP 270 class last quarter, our final assignment was to create a webtext. I purchased a domain name for that project, but would like to use it as my website for all of my professional work (including this blog!). I loved the flexibility of WordPress’s software (as opposed to what’s available for use as part of their free domain) and would appreciate the ability to edit the CSS on this blog and tweak the design more to my liking.

Therefore, I need to take the time to figure out how to move the content from my project to another space and link this blog to my own domain name. I’m sure I’ll just need to tinker around to figure this out, but if anyone has any advice on this, I’d greatly appreciate it!

3. Keep up with technology news 

Everyone has their regular rotation of web browsing, I believe. My “regular rotation” primarily includes e-mail, UC Davis’s learning management site, Facebook, Twitter, and a few choice blogs. I’d like to integrate more technology news sites into my rotation, however, to keep myself current on issues that may be relevant to my research and pedagogy later. My short list of sites to start browsing more regularly are the Huffington Post’s Technology page and TechCrunch. Any other suggestions?

4. Maintain theoretical/thematic connections between seemingly unrelated coursework and digital literacy concerns 

OK, this may sound like an obtuse goal, but hear me out. As an English student, it is occasionally difficult to explain the intersections between digital literacy education, educational technology, and the study of literature. The connections are clearly there; digital literacy is shaping the ways in which literature is read. How could it not? However, as much of my coursework will primarily include engagement in critical theory and – well – fiction, I’d like to work towards creating final projects that more closely link my interests, so that I continue to develop my interests in the lens that interests me. I feel pretty confident at this point that I want my research to be ultimately very engaged with digitality in some way; I just don’t know how exactly yet. This is my job as a student now!

5. Keep this blog current! 

Not to get super meta or anything, but I think it’s crucial that I maintain my presence here in order to continue engagement with current digital literacy concerns. I’m somewhat notorious for starting blogs and abandoning them, contributing to the Internet’s considerable amount of cyberjunk and noise. I’d rather not throw more garbage to the ether. It takes discipline to maintain a writing schedule every day, but I intend to post something at least once a week, even if it’s just a link to an article I find or a quick reflection on something I learned in class that’s relevant to the intersections between technology and the humanities.

Cheers! To a new quarter!

Code Year Lesson 2, Part 2

Yikes, I’ve been woefully negligent of my coding lately! Admittedly, it’s a task that I end up avoiding. For whatever reason, thinking about the coding often fills me with anxiety; I know that the work will be a little bit tedious and will often be difficult for me to process. I imagine it’s natural to avoid tasks that feel uncomfortable, but I think I have to do a better job of either a.) finding joy in the process or b.) becoming a little bit more disciplined. I’d like to rely on option a), but I have a feeling that the mean option b) may have to take the wheel.

Technically, I’m a week behind. I just finished up the “activity” for Lesson 2, which was about defining functions in Java.

Do you remember those word problems in math class? You know, the ones that were like:

“Jimmy drove 100 miles at sixty miles per hour to meet Carmen. Carmen is 500 miles away driving at 30 miles per hour. Calculate how long it will take Jimmy to meet Carmen. Throw in the number of corn nuts Jimmy will munch on as he drives to meet Carmen.”

I mean, I guess they weren’t exactly like that, but I remember walking away from each of those problems with an exasperated, “WHO CARES?” Plus, it was always so difficult for me to wrap my mind around the spatial-temporal connection.  What if Jimmy had to pull over for a flat tire? Why is Carmen such a slow driver?

In any case, the “functions” activity for Code Year initially terrified me as it reminded me of those old word problems…

My task was to create a program that calculated New York taxi cab fare. It started nicely enough:

Declare a variable! Yeah! I’ve done this before! For those of you who don’t remember, declaring a variable really just means saving it into the program. Sweet. Now the program knows the baseFare is $2.50.

Oh, and that little yellow “caution” sign at the start of line three of my code was to scold me for forgetting a semicolon. Unfortunately, I forgot to screencast my “good job!” when I fixed the syntax.

Then, we had to bring back our knowledge of functions. To refresh your memory, functions are those programs that you create so that you don’t have to repeat certain lines of script. A function is a program that you probably want to be running in the background or that you want to use multiple times.

So, here’s the function I defined to calculate the taxi fare. For whatever reason, it was really difficult for me to keep the variables straight initially. Somehow, defining the base fare BEFORE I established the function that finds the final taxi fare seemed confusing.

I mean, for someone used to thinking in a narrative form, this would be kind of like giving the cast of characters at the front of a book before the book even begins. I suppose that’s not so weird, but casts of characters typically only appear at the beginnings of plays. When I’m reading a novel, I somehow don’t expect this to happen. In the same way, I somehow didn’t expect this to happen in functions either.

Of course, in math, you must define your variables before you solve your problems, so I suppose if I was used to thinking in a “math-brained” way, this would have been more intuitive.

Now, the lesson grew increasingly tricky as we had to include a parameter in our function. This parameter allows the function to define more specific characteristics of the function. In this case:

I had to include the parameter for the miles traveled in the taxi to determine its total cost. Without defining that parameter, I would have been unable to execute the cost of the taxi ride. In the initial function, that total fare would have only been determined according to the base fare. That, of course, is incomplete since the rest of the fare is determined by the cost of additional miles and, of course, the number of miles traveled.

See how this is reminiscent of those old word problems?

But look! We had to deal with one more factor:

That’s right: the cost of the fare CHANGES during certain hours of the day. I guess it’s about time I start calculating those corn nut delays, right?

As you can see, I didn’t end up getting the final function right. Frankly, I’m still a little stumped on this one. I think I made a simple syntax error, but I’m pretty sure I set it up correctly. All I had to do was add in an “if/else” statement to determine that final fare. However, again, something went wrong…

This, of course, took me a while to figure out and, with the help of forums that are part of the Codeacademy lessons, I finally got to this point. However, it was that kind of “backwards” thinking that threw me off again. Why couldn’t the night surcharge declared at the beginning of the function just operate as the factor needed to do the calculation? Couldn’t the computer just “figure it out?”

Obviously, the answer to that is “no.” As a programmer, it is your job to define all the variables necessary to make sure the end result comes out accurately. If I think about it more, it’s somewhat similar to the process of writing a paper. A writer should not assume that the reader just “gets” his argument. He has to go through the pains of explicating it, justifying his point and showing evidence. Something similar is happening here: I have to explicate the problem and show all my tracks to guarantee that the computer “gets it.” Otherwise, he’s stumped!

I suppose he is a little stumped at present, considering the fact that my syntax is somehow wrong. At times like these, I want to apologize for any student’s English grammar that I’ve ever scoffed at. It’s incredibly difficult to remember these grammatical rules when learning a new language! I suppose I’ve always taken that for granted.

Next week, I’ll complete the work I was supposed to do this week on Conditionals in Java. Get stoked!

Code Year, Lesson 2 Part 1

I have a distinct memory of the first day of French 1 in college. I walked in confident that I would succeed. After all, I had been a successful Spanish student in high school; French was a romance language, ergo it wouldn’t be that different. Right?

Well, I quickly realized that in college language classes, you actually learn the language. My instructor, Alison, opened the first day of class speaking to us – a group that presumably had no prior French knowledge –  primarily in French. It was a clear dive into the deep end. My, how this was different than high school Spanish class!

(Side note: I had pretty strong Spanish education in high school, but we spent quite a bit of class time gathered in a circle singing songs by Juanes and Rebelde. So, you know. Not super rigorous.)

Anyway, this is perhaps a circuitous way of getting into my main point about programming, which is that I feel like with Code Year, I’ve similarly dived into the deep end. Unlike with French, however, I’m fighting not only the battle to learn quickly, but also the battle to overcome my anxieties about technology. I’ll admit that I’m a computer user more inclined to call tech support when something goes wrong than to take the time to trouble shoot myself. I figure that “an expert” must know more than me, right?

The glory of the digital age (And yes, I realize this is hyperbolic. Humor me) is that we CAN have control over our digital lives. I may not be “math-brained,” but I CAN learn to program. I have faith in this. It is just a doggone, difficult task.

Before I get into the nitty-gritty, I have to say that part of what inspired this “can-do” attitude was a short video I watched earlier today from educator Stephen Chew aimed towards helping undergraduate students develop better study habits (i.e. DON’T MULTITASK; NO ONE DOES IT WELL). The video itself is admittedly a little cheesy, but he stated something in his video that struck a chord with me: many students don’t succeed in his classes because they assert they’re “just not good” at something.

This is something I’ve told myself so many times over: “I’m just not good at math.” “I just can’t visualize [insert any image/shape here].”

“I just can’t do it.”

There is some truth to the concern that some students can’t learn as quickly as others can in different subjects. But I’m coming to believe (increasingly) that we really ARE capable of doing anything if we just take the time. It’s doing things that feel uncomfortable to us that is the real push. I don’t think it’s much of a generalization to say that we’re all predisposed to avoiding uncomfortable feelings; that feeling of failure and incompetence is perhaps one of the most uncomfortable for me (this is, unfortunately, a common syndrome of living a life primarily validated by academic achievement).

Phew, with ALL OF THAT SAID:

I’m pretty frustrated by the programming. I can’t give up now because I know how important it is for me to learn. But dang it. It’s really hard for me.

For those who care about the technical stuff:

I completed the lesson Functions in Javascript this week. From what I understand, functions are basically blocks of “reusable code.” It’s a code that you store that gives your program a certain command to repeat over and over again (so that you don’t have to write in the same commands repeatedly).

See, so far, so good. I’m all into this efficiency thing. I like to color coordinate files and write to-do lists, so the idea of something like a function very much speaks to my organizing soul.

As these Code Year lessons tend to go, it started quite well. I must say that I felt incredibly proud of myself when I created my very first function!

"You never forget your first function"

Simple, yes, but still mine all mine! I made the console spit out my name! Winning!

Of course, the lesson grew increasingly complicated. As with learning any foreign language, learning a programming language requires you to integrate what you learned from lessons prior (crazy, right?)

So, within functions you must also store variables. Defining and storing variables allows you to work with the numbers/words/items that will be important for your function (and therefore your program) to – well – function!

So, I didn’t capture an image that spit out the console log text, but basically this activity required me to run the code to see what the function “greet” spit into the console log. As you can see, because the variable “greeting” is was typed into the console log, the variable’s text (“Ahoy”) appeared in the console log.

So far, so good? Yep, so was I.

Here’s where things get tricky:

Inside a function, certain values can get “returned.” To clarify, in all of the examples I’ve shown, the functions are just outputting information without receiving any input. The return tool is necessary to use if a particular value is inputted into a function.

Here’s an example:

The value “x” has been inputted into the function and two different functions are created: one that simple returns the value inputted and another returns the value inputted, squared.

Again, I think we’re still following, right?

Remember those tricky if/while loops I discussed in Lesson 1? They’re baaaaack:

So, here, we’re basically just complicating the function further: this program will determine whether to spit out “The statement is true” or “isn’t true” based on the conditions established within the function.

What was tricky to me about this was figuring out how to define the conditions within the function. How do I use the correct syntax to break down the conditions? What’s the clearest/easiest way to do that?

Obviously, I’m still learning and I’m still working through a lesson on establishing parameters within functions, too. But… here’s where I left off!

I find myself reading and re-reading directions to make sure I understood, but now that I’m synthesizing what I’ve learned, it feels simpler than when I was learning it. I guess this shows I understand what I’m doing? Maybe?

Code Year: Lesson 1

I’ve made it through (most of) Lesson1 of my “Getting Started with Programming” Course on Codeacademy and I’m already running into trouble! Nooo!

Mind you, the first few exercises within the lesson felt like a breeze. Really, I figured I’d be making apps and creating programs in no time! I suppose when you have exercises like “type your name”…

…And “Copy these instructions so that you can create one of those awesome pop-up boxes!”

… you’re bound to feel like a programming champ.

Yet this were just the “feel good” exercises before tackling the real deal.

Before I get into the details, here are some new terms I learned:

string:  a unit of alphabetic characters that need to be identified as one. As a programmer, you need to identify “strings” in your programs in order for words to show up. If you don’t identify “strings,” the program won’t recognize those particular word units as important. You have to treat your program a little bit like your great aunt Ethel; assume that it will remember nothing. However, it’s easy enough to store strings so that the program will remember what you mean when you type in certain words.

variable:  a number that you store for the program to use as information later.

array: an index (typically of numbers) created so that the program can store multiple numbers at once in the same order/pattern each time.

I’m still not sure I completely understand the distinction between a “string” and a “variable” (aren’t they all simply units of different types to be stored?), but the above definitions are a simplification of how I’ve parsed this out in my mind.

In any case, as I moved along through the lessons, I discovered that programming language involves a lot of syntactical precision. After all, a program can only run if the writer is incredibly explicit in his/her directions. Let me try to provide an example:

The exercise wanted me to command the program to parse out two letters from the string “hello” (in this case, the letters in the first and second positions of the string). Alas, do you see what mistake I made the first time around?

That’s right: I put a period at the end of the command while I should have left it open. That one little dot messed up the entire operation! Isn’t that bananas?

Of course, syntactical accuracy is not the only thing I learned to be wary of. Logic is a hugely central to programming, something I had never realized before I began Code Year.

This makes complete sense, of course. How would a program know how to function if it did not account for all possible contingencies?

One concept I especially struggled with was that an “equal” sign does not always mean “equal.”

I mean, what? Equal is not equal? What are you trying to do to me, Javascript? Are you going to tell me next that people aren’t people?

So, as it turns out, one equals sign simply identifies a variable. It does not necessarily mean that the variable at the end of the “equal” sign is going to be the “answer” to the program (especially if it’s a mathematical program). Three equal signs together (===) is used to check if one variable’s value is equal to another variable’s value in the program.

Oof, yeah, I had to read that a few times over, too. My brain is not used to considering all of these different mathematical contingencies!

The primary circumstance in which a programmer may use the “=” and “===” signs is for “if” statements. Here’s an example:

Do you see what’s going on here? Basically, this is a program that will spit out one of the console logs (i.e. “Your name is Sam” or “Your name isn’t Sam”) depending on whether the user of the program answered the prompt (“what’s your name?”) with – well – Sam or not Sam. The “if” statement (with the three equals signs determines) what the response for the user will be if “Sam” is entered or not entered.

See, it really makes perfect sense. It’s just a matter of completely rethinking syntax.

In any case, I felt pretty confident in my understanding of how the “if” and “else” statements work in a program. What’s (still) tripping me up are the “while” statements.

A “while” statement should – in theory – set up a continual loop within the program. However, I seem unable to nail the syntax to create these while statements successfully and I don’t quite know what to do. Any thoughts, cyberspace? Here’s the problem I’m running into:

Perhaps it’s difficult to read the instructions (they are in tiny-ish script), but I’m supposed to create a program that prints the word “hello” twice using the “while” loop. However, I’m not sure where the variable “i” fits into that and how I help the program to understand that I’m not using any numbers here. I’m afraid I’m a bit stuck! Perhaps some future Googling will help me to solve this program.

In any case, I’m really trying not to let myself get frustrated. Even in this first lesson, I found myself reading and re-reading instructions for even the most basic of “activities.”

Perhaps I’m simply not acclimating to thinking from “the back end” like this. Indeed, I fancy myself somewhat creative, yet from what I can gather, successful programs are not merely creative: they are able to envision whole words and define the terms that creates those worlds.

That’s mind-blowing to me.

I suppose for now I’ll have to be content with the mere shrubs and brushes I’m starting to program before I can think about the tall buildings and – goodness knows – the people to populate this digital world.