Comparison of Arrays, briefly

So. Everything is an object. That was js, right? An object can be an association between a key (name) and a value. Which makes an object sort of an array, right? Because an array is a collection of key:value pairs. If key is a name, that's an object, if it's an index value, that's an array. Key:value pairs. Yep.

Examples from things I have some familiarity with:

JavaScript array creation:
var myArray = ["element1", "element2", "bunnies"];
console.log(myArray[2]);  
//prints "bunnies"

jQuery object (more than just an array):
var divs = $("div");
console.log(divs);  
//prints "[0: div.container, 1: div.logo, 2: div.content...]"

PHP:
$animals = array("dragon", "giraffe", "hedgehog");
echo $animals[2];
//displays "giraffe"

Python Lists (mutable, homogenous):
>>> colors = [['blue', 'red'], ['sage', 'vermillion']]
>>> colors[-1][0]
'sage'

And Python Dictionaries (essentially objects/associative arrays):
>>>dict = {'nonfiction': ['Pollan', 'Berners-Lee'], 'fiction': ['Tolkien', 'Asimov']}
>>> dict['nonfiction'][1]
'Berners-Lee'

And Python Tuples (immutable, heterogenous):
>>>tup = ('a', 3, -0.2)
>>>tup[1]
3

Java (fixed length):
String[] rabbits = {"fuzzy", "hoppy", "ears"};
System.out.println(rabbits[1]);
//prints "hoppy"

C (Closest to Java. Info from Learn C the Hard Way. I hadn't touched C before today, forgive me.):
main(){
char name[] = "Petunia"; 
//creates array of chars {'p', 'e', 't'...etc}
printf("name is %s.\n", name);
printf("or also %c %c %c.", name[0], name[1], name[2]);
}
//prints
name is Petunia.
or also P e t.

Useful bits of Drupal doc + site building init

Warning: contents are entirely stream of conscious/notes.

The best practices guide for Drupal has a lot of very important points to consider, but for my own technical edification, I'm focusing on just a few aspects. Handy list of core modules to become familiar with if not fully memorize, just so I grasp the breadth of Drupal functionality a little better. Right now I only know a few nooks and crannies! I'd love to do a big long workshop just to be taught, start to finish, how to build a basic site.

Read this next: Using test sites has some good starting points for setting up test environments, multiple servers, the sorts of things I need to be doing below (keeping test sites sych'd. synced? argh). I'll have a local install, then push to a test server (how to keep it private while being up with the same db/etc as my live site?), then from test to live. So the only problem is that my local dev env will be somewhat different from production. Forthcoming: post on Dreamhost's setup in relation to Drupal's needs. I've only posted my placeholder site up there with FTP and plain HTML files! No idea about dbs.

Ok, so. (don't even ask about that link, I don't know.) I want to actually develop my website. I want to do this with Drupal. Obviously.

Erm, or I could update my drush setup, instead. Went for a git repo this time, for my own sanity, but now apparently it needs something called Composer, too (Almost typed "composter." Guess where my mind is). I think it might be working now, hoping I don't really need to update all those php settings again. It's a wonder anything works, given how many configuration files I need to keep track of...

-Problem the first: Which version of Drupal? Do I go with D7 and have the benefit of contrib modules, established practices, lots of support? Or do I go with D8, which I'm at least as familiar with, probably more so, and get ahead of the curve and become more adept with what's to come? Keeping in mind that D8 actually incorporates bunches of modules that used to be in contrib, probably covering most of my immediate needs, but also keeping in mind that some things might still be broken, regular updates will be necessary, and the whole thing could break at any minute?

In my experience, breaking things is the best way I learn how systems work. Even though I know I'll have to rebuild bunches of times to compensate for my own learning and updates to core while it's in development, that will help solidify any new things I learn along the way. Too often I find myself figuring something out once, but then I don't run into the same situation again in my tiny bubble, so I forget it. Database setup, for instance. I need to get my head wrapped around how the DB works.

-Databases and test sites: Keeping local and test sites synchronized... using drush.
What is stored in the db? How does Drupal use its db? how is it accessed? Can I easily switch dbs? What would that be useful for? How do I move the live db back to stage and dev sites for testing? download a backup and connect? is there a faster way to get it re-connected, too? (drush!) Looks like I definitely don't want to use the same database for more than one instance of the site or I'll risk contaminating it with screwed up code. Probably reading the drush instructions for drush sql-sync will clear a bunch of this up.

What's a session variable, exactly? cookies?

Acquia cloud does this very nicely on its own with the drag and drop setup. Do I need a paid subscription to push to production? can I host my site somewhere that isn't Acquia and still use Acquia cloud? How much time should I spend playing with Dev Desktop?

What do I do on the backend v. the frontend? what will I use the CMS interface for, just content creation? Adding modules? Theming (this is a knowledge void for me right now)? Develop on a test, test the new thing, then install on the live site? What do I do frontend and what backend and then push? how much pulling should I do? I need to separate my creation phases (site building/dev and site maintenance/content updates)...

[TODOs are bold]