Tuesday, September 8, 2009
linux
My boyfriend is IM'ing me through installing linux because he says I should use Linux, not Mac, if I want to even think of learning to program. Since all my nerd friends use Linux I am going to trust him on this one. Downloading via Ubuntu. Installation will be... interesting.
Trying to figure out the basics
Perhaps I should be tweeting my trials and tribulations instead of blogging. At the moment I've downloaded the MAMP software and can't figure out how to install it. I'm a total noob. Hopefully once I get going, as in, have all the stuff I need installed properly, these posts will be longer and more insightful.
I hate being a noob. It hurts my brain. But then again, learning is fun.
Getting back into this, for real this time...
Ok, ok. So I'm super ADD and I get massively distracted by life every time I sit down to teach myself how to program. I didn't even get past chapter 3 in my JavaScript book. I'm ashamed.
The good news is, I signed myself up for two computer sci classes at the community college for the fall. The professors are supposed to be awful (thanks ratemyprofessors.com for getting me real excited about these classes, not) BUT I'm hoping that a structured into to programming will, at the least, get me on the right track.
At the moment I'm signed up for Intro to C++ and Intro to Data Management Systems. The names of both those classes alone scare me to bits. But if programming is a language, it should be learnable, at least to the point where I can not be so deathly afraid of it and look at programmers as if they are gods with minds far beyond the intellect of normal folk like myself. Or, I'll be able to understand exactly WHY they are gods and I have a feeling it has nothing to do with knowing "how" to program, more like "how" to organize things with a language that anyone can learn.
Tonight, however, I'm staring at my Beginning PHP5, Apache, MySQL Web Development book and considering trying to get through a chapter or two. I'm under the weather and have the night to my lonesome, so might as well start learning something... even though PHP is going to be very different from C++, which I'll begin tackling in a few weeks.
I'm not even sure PHP5 is current anymore, but hopefully the book is still good. I have a bagillion random programming books that I've bought over the last 3 years or so. Time to put them to use. Really. I mean it this time.
Saturday, April 4, 2009
Getting Back into This
I'm back. And hoping to move on to the next lesson this weekend. I finally have some time to focus on learning to code. It's important to do, so I'm going to try to hold myself accountable for staying on top of studying.
Sunday, January 4, 2009
Interaction Design and Theatre
Although this blog is primarily dedicated to my technical trials and tribulations in all their dramatic and/or not-so-dramatic glory, on occasion I've decided to start blogging on related topics, such as tech news, business, and interactive design.
One of these topics, which I hope to learn a lot more about, is user interaction design. Coming from a background in theater, I always felt that my undergraduate training somehow indirectly prepared me for further study in HCI, but also thought I was likely imagining things (I do that often.)
Turns out I'm not the only one who has made the connection. In this really interesting discussion thread on IxDA, a few interaction designers chime in on the relationship between theatre and UI.
Seamus Bryne, a Senior User Experience Designer from Ireland writes:
One thing that drives me nuts about directing theater is that as the director, you only have so much control over the actor and design, which are your page elements leading your audience through the script. As a director, I want ultimate control. Maybe in film direction I would get that, but in theater direction that control is lacking.
In programming, you do have control, at least, to set the page elements and adjust as needed based on research, in order to guide your audience through a psychological and physical process.
The most important part of the entire puzzle is the feedback from that audience, so you can make the appropriate changes to your educated guesses of what takes your audience from your point A to point B. In theater, design needs to be holistic - you can't design one scene or interaction without thinking of the rest of the play. You also need to consider your audience (will they be fidgety children, affluent seniors, teens who'd rather be texting on their iPhones, or all of the above?), where your audience will be sitting and how that will effect the audience/user experience, your budget, your "talent" (which in the case of programming is both the power/flexibility of the chosen language and the actual talent/ability of your development team), the physical design elements, and every last variable which contributes to the experience of a performance.
A visit to an interactive website is a performance. With the thrill of discovery (the same thrill that you have as an audience member in a play or film when something is revealed or things "click"), your audience members get excited and want to delve further into the product/story.
There are plenty of differences between theater and interactive design, of course, but I am fascinated by the similarities.
I do feel like I've finally found a place where I can both excel and grow, and my current position in community management is a great spot to start out and get to know how users interact, what they expect, and what they want out of their experiences interacting with a product.
Ultimately, I may want to pursue an MBA and focus more on overall product development (which honestly seems closer to the "theater director" role, with a crossover into stage management), but learning about user experience and programming is one of the many things I must do to begin my journey to wherever it is I may end up.
One of these topics, which I hope to learn a lot more about, is user interaction design. Coming from a background in theater, I always felt that my undergraduate training somehow indirectly prepared me for further study in HCI, but also thought I was likely imagining things (I do that often.)
Turns out I'm not the only one who has made the connection. In this really interesting discussion thread on IxDA, a few interaction designers chime in on the relationship between theatre and UI.
Seamus Bryne, a Senior User Experience Designer from Ireland writes:
"I find that some principles from stage direction to be very relevant and applicable to interface visual design. Concepts such as "selection" and "emphasis" and "levels" help me understand designing within space and therefore lend themselves very well to the informed placement of UI elements. After all, a screen has similar characteristics to the traditional proscenium stage."My (hobby) work as a theater director definitely has employed elements of interactive design. Where the audience is looking at, and what of the script they are processing at any given time based on focus is a key element in any directorial project I take on. Sure, I don't have to get my audience to click a button, but if they aren't mentally clicking buttons as the show progresses, I haven't done my job as a director.
One thing that drives me nuts about directing theater is that as the director, you only have so much control over the actor and design, which are your page elements leading your audience through the script. As a director, I want ultimate control. Maybe in film direction I would get that, but in theater direction that control is lacking.
In programming, you do have control, at least, to set the page elements and adjust as needed based on research, in order to guide your audience through a psychological and physical process.
The most important part of the entire puzzle is the feedback from that audience, so you can make the appropriate changes to your educated guesses of what takes your audience from your point A to point B. In theater, design needs to be holistic - you can't design one scene or interaction without thinking of the rest of the play. You also need to consider your audience (will they be fidgety children, affluent seniors, teens who'd rather be texting on their iPhones, or all of the above?), where your audience will be sitting and how that will effect the audience/user experience, your budget, your "talent" (which in the case of programming is both the power/flexibility of the chosen language and the actual talent/ability of your development team), the physical design elements, and every last variable which contributes to the experience of a performance.
A visit to an interactive website is a performance. With the thrill of discovery (the same thrill that you have as an audience member in a play or film when something is revealed or things "click"), your audience members get excited and want to delve further into the product/story.
There are plenty of differences between theater and interactive design, of course, but I am fascinated by the similarities.
I do feel like I've finally found a place where I can both excel and grow, and my current position in community management is a great spot to start out and get to know how users interact, what they expect, and what they want out of their experiences interacting with a product.
Ultimately, I may want to pursue an MBA and focus more on overall product development (which honestly seems closer to the "theater director" role, with a crossover into stage management), but learning about user experience and programming is one of the many things I must do to begin my journey to wherever it is I may end up.
Constants: Beyond Stubborn
Think back to 8th or 9th grade Algebra I, and you'll remember that in addition to "variables" there are "constants." The constants always bored me, they made it impossible to be creative in math class. But in programming (and heck, in normal math too) they're important. Some things don't change, and it's easier to set a constant and reuse it over and over again.
If you ever want to change the value of that constant, you can do it in one place, instead of all throughout your code. The textbook example, which seems like a good one to use and remember, is a constant tax rate in the equation of figuring out how much tax is owed on a purchase. The tax rate doesn't change, so it's a constant, not a variable.
Constant's JavaScript keyword is longer than the one for variable (var)...
const: the JS keyword for constant
const CONSTANTNAME = CONSTANTVALUE;
***like variables, constants can be named just about anything, but their name must start with a letter, $, or _
If you ever want to change the value of that constant, you can do it in one place, instead of all throughout your code. The textbook example, which seems like a good one to use and remember, is a constant tax rate in the equation of figuring out how much tax is owed on a purchase. The tax rate doesn't change, so it's a constant, not a variable.
Constant's JavaScript keyword is longer than the one for variable (var)...
const: the JS keyword for constant
const CONSTANTNAME = CONSTANTVALUE;
Formatting Note:If your constant changes at some point down the road, you can always go back and change it in your script. It just can't change while the script is running.
Constants are written in ALL CAPS and Variables are written in MixedCase.
***like variables, constants can be named just about anything, but their name must start with a letter, $, or _
Variables are Fun!
So the book finally got around explaining variables and "var" on page 44.
variable: a storage location in memory with a unique name.
var: the JavaScript keyword used to create a variable.
It looks like the way to create a variable is to write
... so you want your variable to have an initial value? Yea, me too. Good thing the next page tells me how to do this. Apparently that's called initializing a variable. (Creative lingo here, huh?) The good news is that the code to do this is fairly obvious. You just add a = initial value and viola, you're set.
variable: a storage location in memory with a unique name.
var: the JavaScript keyword used to create a variable.
It looks like the way to create a variable is to write
var variablename ;* every variable must be unique and meaningful, says the book. Unique, obviously, because if you have two different variables named the same thing that will cause an error. Meaningful, because, let's face it, you're not going to remember what xijoije means. Programming is very organized - you don't have the luxury of letting your code get messy before taking a day to clean it up. Practically any programming book will beat you over the head about formatting and naming standards, and for good reason.
... so you want your variable to have an initial value? Yea, me too. Good thing the next page tells me how to do this. Apparently that's called initializing a variable. (Creative lingo here, huh?) The good news is that the code to do this is fairly obvious. You just add a = initial value and viola, you're set.
var variableName = Initial value;JavaScript makes some things easy for us programming noobs. I just found out that it will assign a value for your variable automatically based on what initial value you give it. So if you say it's initial value is 300, for instance, it will know that it's a number. Sometimes JavaScript can't guess or guesses wrong and you have to go in and tweak it... but they don't want to tell me how to do that yet.
Subscribe to:
Posts (Atom)
