A funny thing happened on the way to site-building

It all started when I tried to sql-sync my database from my local setup to my remote test server.

drush sql-sync @dev @test
ssh: Could not resolve hostname @dev: Name or service not known

hm. So I google my error and find an issue on the Drush Github project for the exact same problem. Awesome! it's already been fixed. So I just need to update drush.

Having previously installed drush as a git repository, I cd over to that dir and and do a git pull. yes? Well along the way I notice that the drush github page now suggests installing with Composer instead, so I decide to update to that process. Probably I could've just stuck with my previous method, but in the interest of doing things "the right way"... this is where I keep getting myself in trouble. Ok:

composer global update
#tried composer -V and global update just to see where I stood...
Warning: This development build of composer is over 30 days old. It is recommended to update it by running "/usr/local/bin/composer self-update" to get the latest version.
...
Composer could not find a composer.json file in /Users/E/.composer
...
drush (master)$ /usr/local/bin/composer self-update                                                             [Composer\Downloader\TransportException]                                  
  The "https://getcomposer.org/version" file could not be downloaded: allow_u
  rl_fopen must be enabled in php.ini...

Sigh. So I fix allow_url_fopen. I run composer self-update. I try to install drush again... composer.json?? It took a bit more research to get this right, and I honestly don't remember what I did now. But here's what it wound up as:

{
    "require": {
        "drush/drush": "dev-master"
    }
}


Swell. I think at this point I managed to run the command to get drush re-installed. Now I've got the version of drush with the fix for my original issue! or so I thought... I took a closer look at the code fix for the ssh problem, found that file in my install and compared. The code didn't match, but the hash when I had updated with composer showed it was the most recent version! I had the new updates, but I also had the old git clone of drush. Guess which one my shell was pointing at?

Eventually. Eventually I check which drush, where drush, what drush?? and find my bash_profile export PATH pointing in too many directions (wrong!: /Applications/drush/drush:/.composer/vendor/bin:), which if I'd been paying slightly more attention I might've noticed in step one of installing with Composer. Removed the old path, kept the .composer path and I think that's when it finally worked.

At least I'm pretty sure that's what happened. By the time I was done with this I had completely forgotten that I was trying to sql-sync. So I finally, finally got back to that and it actually just worked. So now I need to figure out pushing the rest of my initial local dev stuff up and after that it'll all be pushing code up and pulling data down.

It's going to be really weird doing front-end work after spending so much time on configuring and getting things to just function... one day at a time.

Getting up to speed on CSS tools

I did this backwards. It should have been mixins, Sass, Smacss, Compass, Singularity. Then again, sometimes starting and the end and working your way back lets you see the bigger picture and understand how it all fits together. Says the girl who started Drupal with core contributions.

Singularity (compass extension)- ratio-based grids (quick walkthrough video here), very easy to make different widths $grids: 1 2 3 2; Also can use px, pt. Integrates with breakpoint- add an @include breakpoint(30em){@include grid-span(2, 3);}. Very cool, super easy way to get responsive design out fast.

Mixins-  A mixin is an at-rule used to define a ruleset than can then be *reused* in other rulesets. Yay reusable code. I think mostly as a n00b I'm always surprised when things like this aren't a given- it makes perfect sense to be able to define a thing and then plug it in wherever you need that thing. But is this the same thing as the mixins Compass is using?

/* define a mixin */
@mixin .muffinstyle {
display: inline-block;
background-color: blue;
}
/* use a mixin */

p .bakery {
include: .muffinstyle;
border: 1px solid red;
}


ok, Stackoverflow question on the CSS at-rule here. So basically anything preceded by an @ is an instruction for the user agent, rather than styling rulesets. I've been using @media, @font-face and so on, but hadn't really thought about the construct itself. Here's MDN on at-rules and W3C on CSS syntax (this one's really helpful). There's a very handy graphic and description here on CSS statements and their subsets, at-rules and rulesets.

Compass- Ok, so there are CSS mixins, then there are Compass mixins... which are just a predefined set of CSS mixins? oh. And then Singularity pairs with Compass. I get it. /several hours of digging and reading later.

Sass- This also makes all kinds of sense. Things like variables to hold info in a more logical spot while you're writing, then output a fully fleshed out CSS file at the end. Saves on typing, mistakes, and again with the reusable code. Compass is for writing Sass. Got it. Wow, nesting. So logical, so tidy. Ah, and we're on the new version that uses curly braces, which seems a lot better than just indenting anyway. I do not generally approve of dropping semi-colons and such even if it *is* more minimalist.

Smacss- I really appreciate this- organizing, categorizing, approaching css in a logical fashion rather than throwing properties left and right and hoping it all works out. See my next post on approaching a problem, too. I might disagree with a couple things Snook says (and this book is a little old already), but his general point is spot on. I think this will fit into my brain even better after my next two or three tabs, too... Things start getting interesting once we drill down to the "module" level. Goals: increase semantics and decrease reliance on specific HTML

Next: More depth from Legacy CSS with Sass and SMACSS and modular SASS development using SMACSS and BEM.

In other predictable news, something here needed homebrew to install... I think it was a Ruby update. I have Ruby 1.8.7, but would like to have the current. Probably doesn't matter. But I think to update I need homebrew and homebrew last I checked needed xcode and 10.6.8 does not the xcode have. BUT. I think I can install the sass/singularity/compass package with just ruby. I hope. Later. Not now. Because this is always ridiculous, and generally why I'd rather stick with simple, low-level stuff.

Next: Creating a Drupal 8 Theme with Sass, Singularity & Breakpoint

In which I talk to myself a lot

More on setting up my first Drupal/Git/Drush site...

I've opted to ignore the multitudinous potential php settings for now, and am hoping things just work for the moment. Otherwise I'll keep procrastinating by fussing with server settings forever. I did find that my php version is easily changed by clicking edit on a domain in the dreamhost panel. And then my Drupal install moseys along much better.

If someone wanted to drop me a lecture/note about how I shouldn't be toying with D8 on a live server because [security] I'd actually be curious to know more.

Oh here we are, the php.ini wiki page for dreamhost: "We seriously aren't kidding about this" edition. Okay, yeah, still going to try not to mess with it for now. SO, moving along. Complete install using appropriate database. tum tetum.

Got hostname right, port default appears ok. Dreamhost phpmyadmin seems to have organized my dbs using the underscore I dropped in to differentiate test and production dbs. Hoping that's not a problem. Totally writing things to db now! whee. This is so nerve wracking, given how frequently things seem to break. Then I'll have to go back and clone to my root directory for my site, too, but not until I have something worth having up front.

meh, nuts. Admin menu doesn't display, just shows "array." Works fine on local. Maybe I'm not doing this quite right if things are that different. Also the whole thing is slow as all get out. oh, I needed to clear my cache. When did drush cc all go the way of the dodo? It's hard to keep up with a learning curve that keeps doing loop-the-loops.

ehhh I got distracted working frontend site building and haven't been keeping notes! I still can't get my search block to display, not sure why. Finally got my blog view to display the grid first by disabling the contextual filter (tho I'm still not sure why it was showing "3 2014" instead of "May 2014").

Now need to get my drush site aliases up and working so I can push the db up and see what happens. I suppose I might as well be doing my dev on my /test directory, since I'm not really doing dev so much as design. Heaven help me if I ever get to the theming part of the program here. At least my concept is super simple and minimalist. For now. Now where did I put my sketches?

Or I could just export the dang db and import it to the remote and deal with it later when I have slightly more time. It bothers me to do this the "wrong" way, though. Ok, export, import check. Then I just need to... definitely not the most elegant way to do this. Kinda broke things. Totally lost track of my git system. Maybe I should just get my site-aliases to work.

Note to self: fix things with chmod u+w. Finally got back to close to where I started by copying settings.php over. Somewhat easier to follow instructions for site aliases here. That plus the instructions in example.aliases.drushrc.php. 

Dreamhost specific Drush install instructions!? yes! ... no. That installs the old Drush, I need Drush 7, which requires composer, which requires that the php phar extension be enabled, which it isn't. Seriously, you've got to be kidding me. I just want to sync my database! Ok, got the phar extension working, though I *really* don't understand why it wasn't. See also (again) Dreamhost's wiki here on php settings.

Finally got Drush on the remote, more or less. So now running drush @test status locally at least comes up with a different result... "Drush 7.0-dev does not support Drupal" and "Fatal error: Call to undefined function conf_path() in /home/[me]/.composer/vendor/drush/drush/includes/bootstrap.inc on line 783" ...what? ok, maybe I need to do my alias a little different, can't get that until I run the install script again on the remote? Do I even remember how to do this part anymore?? ok, got drush site-alias @self copied, added to my drushrc.php locally, eventually got rid of a stray paren that was really messing things up, and finally drush @test status works!

... now I can try syncing my dbs. Which fails on the first try with "Error: no database record could be found for source @dev." erm. Ok, so both @dev and @test pass drush sql-conf. That's good. ...I'm completely at my wits end here. HELP.

And then I can set up an alias for my production site, which I haven't even provisioned or whatever yet- need to clone to site root, install, set up alias, and sync. Right? That should be easy at this point. ...right?

Eventually I will get to theming!

Useful things I just did

Environment setup for ssh stuff on my server. Eventually found and edited my bash_profile. Remembered how to vi and unix properly. Can't remember what I was originally trying to do.

Setting up SSH. Basic stuff. Understanding SSH.

Oh yeah, here's where I started, Drupal on Dreamhost.

/me clambers back out of rabbit hole to find a new one to explore...

oh, and adding an alias to my bash_profile alias ll='ls -la' for more verbose file listings. Cause otherwise I can't *see* .bashrc, say, without at least ls -a.

Crash course: clone local, push to server, bam, test site.

More or less. Reminder: Installing Drupal. Includes db setup.

Page two of install gives me "no data from server." ... what? the first page is fine, but I click "english" and it gives up? It's not even a WSOD!

Sweet bunnies. Upgraded MAMP, again, broke things. Eventually remembered to change my mysql password in /Applications/MAMP/bin/phpMyAdmin/config.inc.php (I had changed it away from 'root' at some point, for obvious reasons).

wooo finally got through the install script. Since I've only done core stuff before I don't really know what all I should use for a production site- username, site name, that sort of stuff. Just going to wing it.

So this is probably one of those stupid questions, but do I have to go through the install script every time I push up from dev to stage and prod?

So trying to push from my local dev environment to my test directory on my dreamhost server: fails, gives me a fatal, no directory, not a git repo message. I think I just had my ssh url written wrong, so switched from ssh://user@server/files/stuff.git to user@server:files/stuff.git and that seems to work. But now I'm not quite sure what that did for me- "This directory is not the working tree, where you edit and commit code. Rather, it is simply the central location for the git objects and history..." ok, so I still need to clone from there to test site. hm.

ok, so now that I'm drawn myself a nice diagram of where my branches and repos and whatnot are, plus associated dbs, I think I can keep moving along... somewhere I had a thing for using drush to keep sites synched... Can't handle adding that into the mix right now, just going to try getting my site up and running first.

With a little help from the git pages, cloning into mysite/test so I can try just a plain install on a live site with a real db. Then I just need to figure out how to pull the db back to local (I think an export will have to do for now, lest I find myself in hours of drush trouble).

... I should really probably be doing this with D7, not a totally random variety of D8. I'll just hit mysite/test and run through the install script real quick... My php installation is too old??? you can't be serious. *checks dreamhost info* ... php 5.2.17.

*Head-desk*

Nobody say anything. TBC after some coffee, methinks.

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]

Becoming a Drupal Core Mentor

t's finally time to start doing something I should have done long ago: mentoring new core contributors! I've spent a small chunk of time as a mentee, setting up my own development environment (dev env), finding issues in the mentoring queue and on Drupal.org (d.o), and interacting with other core contributors. While writing documentation and doing rerolls has been a great way to learn Drupal, the real rewards have come from working with other contributors. It's been a great comfort to know that I can ask for help on IRC, and can always find a mentor online during the core mentoring office hours.

And the bonus is that teaching others is the best way (for me) to learn things! So I went to YesCT for some advice on where to start. Here are a few resources she pointed me to (in addition to this big page o' mentor resources):

First of all, the most important thing to remember for everyone in the Drupal community is that "we are all mentors." This blog post from YesCT is pretty much what I was trying to say in para #1, but she says it better. Being friendly is the best way to encourage new contributors to come back! See also: WebChick's comic about her first encounter on IRC with "the Drupal Community on a Bad Day."

Next we have a key component of being a mentor: reviewing new contributor's work. This requires knowing how to review the contributor's work, and how to review a patch itself (to check that it was done correctly). Sticking with the theme of constructive criticism, gentle reminders, helpful pointers and other supportive input here. Teaching contributors how to interact and communicate with others is a great way to keep everyone positive and engaged.

As a side project, I'd like to help update dm.o and d.o to merge issue task instructions with the regular issue queue, essentially add functionality to the d.o issue queue. Todo for me: read through these related core mentoring on d.o issues. I had just recently noted that having contributor task instructions linked on d.o as they are on dm.o would be much easier than googling them every time I start work on a new issue. Turns out there's an issue for that! (there's also a google doc I won't link to here, but, note to self...)

Then we've got resources for planning a sprint, which I'd really like to do at a Drupalcon in the near future, but am currently lacking a topic to sprint on. If anyone needs a sprint co-leader, I'm happy to help!

Part of sprinting of contributing is going to be getting everyone set up with a local environment to work with. At an event like Drupalcon, or even something on a smaller scale, this can become problematic if everyone is downloading new software etc at the same time. So here are the Drupal Community Tools Download Instructions (dctdi. Tech is almost as bad as gov't with the acronyms). We've also got an Austin specific Core Mentoring page here and of course the perennial dev env setup page here.

Phew. So far I've had a look at most of those pages, but I need to go back and read the issues for dm.o->d.o as well as go through the mentor resources links thoroughly. It's just really great to have a specific goal and project to work on! I enjoy contributing on issues, but with the current D8 beta push it's been hard to find anywhere I fit in lately. Tallyho.

Drupalcon Prague notes

s one might expect, my lofty goal of watching the 20 or so DrupalCon Prague sessions I would have attended in person didn't quite work out... But here are some brief notes on the sessions I've looked at so far:


Frontend development; dancing on the tip of a hurtling rocket

This is almost verbatim why I wanted to be a librarian, and how I came to web development: "What we do as developers is provide content and provide access to that content. That is essentially the value we provide as professionals: There's information out there; we're making it possible for individuals out in the world to get to that content." -Jesse Beach

It's fascinating to think about how accessibility goals can be translated into more general applications later on. With proper DOM semantics and metadata the entire web could be twice as useful and useable.

From Not-Invented-Here to Proudly-Found-Elsewhere: A Drupal 8 Story
Alex Pott- This was marked beginner! I get the general gist, but the code examples were a bit over my head. Recommended reading on PHP- good, something helpful, recommended, up to date.

Drush Optimizations for Your Development Workflow & Drush- Do I Really Have To Use It?
Two sessions on Drush from Prague- One was all about convincing people to use Drush (already there, though not entirely clear on how it actually works with a drupal site... should, again, read the basic docs), and the other was adding Drush functionality to your contrib modules (so too advanced). Had I been in Prague, the "Getting Drush Installed" BOF would have been perfect.

Lisa Welchman Keynote: The Paradox of Open Growth
"Governance is about stewardship. It's about taking care of something." "It seems like it's really just for people who are developers. You could be more inclusive and welcoming" (slight paraphrase). Given that I know people try really hard with mentoring and so on, that seems unfortunate.

And then she brings up shape-note music as a standards practice! Crazy cross-over with my singing experience and hearing from my friend Lynn recently that she had just adapted (with her group) a traditional Chinese piece into shape note.

TBC...

My Dad Thinks Git is Just an Expletive

irst, reviewing some of the Git documentation. The Git book is probably my favorite piece of instructional material available on the interwebs today [that I use/have encountered so far]. Now that I've been doing some branching, checkouts, commits, etc, I'm feeling a lot more confident about this, but wanted to just skim back over things anyway. Also this Git cheatsheet is too pretty.

Some things to clear up:
: The R words: Rebase, Revert, Rollback.
: The difference between Fetch, Pull and Rebase.

• Rebase is actually a merge, I just happen to use it to integrate the newest origin/8.x into my local branch. Merge is a three way merge, rebase pulls in commits from another branch, rewinds your current branch and replays all the changes sequentially to get you back to your current commit with the other branch merged in. Mostly this makes things neater and erases the history of the working branch, making it look like you've been on the master branch the whole time. Easier to merge into the remote later, too.  
• Revert means to undo a specific commit without deleting it from the commit history.
• Roll back, on the other hand, is resetting HEAD to the commit you've chosen to roll back to. This deletes any newer commits entirely, taking you back in time permanently. I think what Git Tower calls Roll Back is git reset <commit>?
• Git Fetch only fetches an update from your designated remote. 
• Git Pull pulls that update down and merges it into your current branch. 

My previous questions about Git were things like: how do I use it to track a site in production? I was thinking I would install it remotely on my host and update there.  I think I should work on the site locally and then push up to my server. Haven't actually looked into that yet. This handy dandy bit of documentation on d.o (Drupal.org, I have gathered) should have plenty of info on Drupal web dev with Git. The most difficult things there will be handling the databases and figuring out why I need development, staging and production sites all up at once. I don't think I'm understanding the latter properly.

Now, all I have to do is get a super good grasp of PHP and JavaScript. Right. Starting with the JS and JQuery fundamentals here.

Then later, for fun, I'll poke around a local install of D8! whee! If I could figure out local hosting well enough I'd broadcast my experiments publicly using my handy-dandy built-in Apache server... but that honestly is a total side-trip that I shouldn't take right this moment.

TDL! Finish configuring local hosting capabilities outside of MAMP and figuring out site-serving capabilities. Also read more "history of the internet/web" books, because it fascinates me. Also find those studies referenced in Tim Berners-Lee's book regarding emergent properties of the www.

Drupal dev env sans MAMP... almost

nother day, another blip on the learning curve. Today I attempt to set up a local hosting environment without using MAMP. Unfortunately, it looks like the doc regarding this manual set up is from 2008, five years and several OS updates out of date, which means I'm winging it, finding new directory paths, etc. At some point later on I may spend some time updating the documentation for all this, but not until I have a full grasp myself.

I'm going to start back here with requirements again, while looking at the manual setup of MySQL and PHP mentioned above. So I'm also looking at this manual setup blog post over here, which should at least point me in the right directions. Managing databases from cli (command line) is not really what I wanted to be doing here.

1. Apache server. Got it, version 2.2.22. Comes with OS X, all I have to do is turn on web sharing... which I seem to have left running and should probably turn off more often. Configuration is in httpd.conf. It's apparently very debatable just which httpd.conf file I should be working on, or whether I should use a separate file like username.conf. Either way, they are here: /etc/apache2/httpd.conf or /etc/apache2/users/username.conf This part I did previously with /Applications/MAMP/conf/apache/original.
• Question: what exactly is this /etc/ directory? Heck, what are all these invisible directories? I really don't know how the system works that well, and Mac OS obscures all the useful things from the average user (eg not me, who somehow permanently turned on "show invisibles." Wish I remembered how...)
2. MySQL: downloaded, install... fix socket? can't find mysql.sock? Oh, initialize grant tables, maybe that's what I'm missing. Need mysql user? Checking that with dscl. Find proper PATH for bash profile, think I got that. Also checking info on MySQL site here for security and initial setup. And here to get mysql OS user account set up? But then that's outdated too, and the data directory is actually /usr/local/mysql/data. And I can't get mysqld_safe to work either. Ok, permissions are wrong on my error log? checked using shell> ls -la /usr/local/mysql/var, but it still says permission denied. And I need a mysql connection extension thing? mysqli? GAH. Alright, I give up. I can connect via cli to MySQL if I turn it on in the prefpane. Not a clue about that extension though. 
3. Attempted to use Homebrew, but it turns out that it needs XCode, which is only OS X 10.7.4+ and I'm on 10.6 something. At this point, I would like to upgrade, but, more software costs...

Then checked back on the original issue I was following that was messing up MAMP, and it seems there's a patch that fixes the issue, so provided that works, I'm back to figuring out more of Git, rerolling, and possibly creating patches. All of which is really not that difficult, but these background headaches are pretty killer.

And I got my Drupal install page back up, just had to reset my MAMP port to 80. And thank goodness, configuration goes smoothly, no more errors. So the lesson here is that I need a backup server/db environment and more knowledge of how to configure the whole shebang. I'll work on finishing that setup some time when it will be a challenge and not a headache. 

Now on to more patches! yay!

Drupal: Re-checking that last patch?

oday I went back to take a look at the patch I reviewed yesterday, and it looks like it needs a little more review. Unfortunately, by the time I got to it, I think the patch was behind HEAD again, despite a rerolling earlier in the day, but on my second attempt after re-cloning, it seemed to apply ok.

While I'm here, some notes on my updating procedure. I'd love to find some more streamlined notes on this, will have a look in a sec.

• The method I've been using is just to git pull (super minimal instructions) changes down without examining and merging (slightly more detailed, includes "what if patch doesn't apply") as individual steps. Git pull usually resets the install... I think. Or it did every other time I used it, but not this last time. Question: what's the best way to test that I've got the latest and greatest down properly?
• So since that usually requires a reinstall, I also have to wipe the db from phpMyAdmin in MAMP. 
• Apply patch using curl, check with git diff
• That seems to be it, then I just reconnect to the now empty db during the install process. Usually. I guess this update didn't change anything in that vicinity?

Supposing that I have the newest HEAD (I have gathered this is what the latest version is called) down, let me just make sure I have everything clean and fresh and double check that the patch isn't applying... wipe db, pull, patch. Nope-ity no. 

Time to learn something new! Or just muddle around and feel silly about things, we'll see. What to do if a patch doesn't apply: Applying a patch manually, copy error msg into issue, "re-rolling" and adding to issue queue. 

First I want to test if I get that error I found in my last post without the patch applied. Nice fresh copy, connect db, test. Error is still there. Question: Should I create a new issue for it, if I can't find it elsewhere? 

hm. Ok, now the patch is applying again. Maybe that was just me? And just pulling doesn't reset everything, so how do I uninstall in order to start over? Seems silly to wipe the whole thing and re-clone each time. Grah, ok, wiped sites/default/files/php and /config_*, ditched settings.php and replaced it with a fresh copy, reloaded. 

Retesting patch... only partially works. Noted as best I could on the issue, but am so uncertain about the quality of my testing environment that I don't trust my reviewing capabilities. There's got to be a better way to set up and test without having to completely wipe and re-clone, but just pulling doesn't always reset? Rather confused and going to bed. 

First Patch for Drupal 8.x

hew! Now that everything is set up, I'm back to the dev env page to get my first patch down, in, tested and confirmed. Hopefully I can get this done before someone else jumps on it. I kind of wish there was a check-out system for issues– oh I see, they're assigned, got it. So, here's my first issue for patch review: Remove drupal_add_css() from book.module.

Actually, step one: blink, get glass of water. Thanks to Jesse for plucking out a nice easy issue for me to start with and being so encouraging about my progress. 

1. Apply the patch: 
   • First, git pull in Drupal directory. Sigh, right, of course. Configure again. Argh, so now my settings.php file wont write itself. Whelp, no idea what that was about, but I fixed it by creating a new default folder. I think the permissions had gotten screwed up on the previous, probably my own doing? Ok, wiped the entire thing, re-installed, re-db'd, reconnected. 
   • Pull down latest version of the patch. Finally found more detailed instructions on where to download the patch to here, 'cause I wanted to be sure. Went for "curl http://drupal.org/files/[patch-name].patch | git apply -" Didn't get any errors, so that seems to have worked. 
   • Run git diff to see changes... shiny, looks just like the view from the issue tracker. Will have to figure out how to use git diff a bit later. Note to self: make list of things to do "a bit later."
   • hm, but if I look at the module code, I'm not seeing the second addition from the patch. ohoh, duh, because that's a deletion, not an addition. Right!
2. Enable the book module: Well that was easy, yay. This is, I'm a little sheepish to admit, my first time looking at the inside of a Drupal install. But look, the extend tab, logically, is modules, right? And then I just click this handy checkbox... The super easy, obvious UI is making me so happy. 
3. Put some articles into a book: Articles, or book pages? I'll do some of both. 
4. Verify that book.theme.css is still loading: tested by a) inspecting elements with Chrome dev tools, and b) using jQuery to find specific selectors in the dev tools console. Seems to work fine. Yay!
5. Set the issue to "Reviewed and Tested by the Community" or "RTBC": Done. Wrote a nice, hopefully brief enough comment detailing my steps and mentioning the error I got for an unrelated (I think) issue. [Any issues I work will be recorded on my Drupal.org profile (you have to have an account to see my profile, but this issue is here).]

That should be it for now. I'll have to go find another issue to work on next! Well, right after I know that last one went ok. And maybe do a little more reading on patches and contributions and things. 

Local/Drupal: complete!

k, picking up from where I left off yesterday - configuring and finishing the local install of Drupal. References: dev env set up page and installation/configuration instructions. Instructions focus on command line tools, so that's good. Thank goodness I had already installed Git and know a few Unix commands or I'd really be behind the curve on this.

1. Neat, here's a handy list of best practices for CMS usage. Completely agree about backups, and definitely need to test mine for the WordPress site I'm maintaining. ...Documentation can be such a rabbit hole; if I don't stop myself I'll just keep reading for hours.
2. First we check system requirements, which I already looked at yesterday. Double checking in more detail now. I will want to enable clean URLs on my own site later on.
   • Web Server: Apache, check. Apache Virtualhost configuration file would be httpd.conf, I think, so I change the AllowOverride to "All" there.
   • DB server: MySQL is what MAMP uses, with PHPMyAdmin, so I should be set there. Not sure how to check what rights my account has or how to change max_allowed_packet, so I'm hoping everything just works. And my PHP is obviously already connected to MySQL. 
   • Good lord I wish I knew what I was doing.
   • Might need to up my memory for my own photography site later on. Maybe by the time I do that, I'll have plenty of experience and it'll be straightforward.
   • My favorite words today: "Enabled by default." 
   • On the bright side, I feel pretty confident about my skills once I have things installed. It's just finding all the configuration files and prying out info about new systems that's challenging.
3. 
   Download instructions not relevant, already have the local directory and Dreamhost has its own instructions that I'll use for my site later. oop, actually I do need to drop the Drupal folder contents into my specified web root, or just redirect the web root. I "woohoo'd" when I saw this in my browser. A little soon for the woohoos, perhaps.
   
   
4. Oh hey, Mac specific install notes regarding PHP, MAMP and other things from my last post. Whoops. Also this note on CVS repository... Question: is this relevant, and wouldn't the Git functionality supersede it? I should figure out how to keep my local version up to date. I bet that's later in the instructions... 
5. Looks like Drupal will create its own DB, so I'm off the hook for that... Might have to adjust settings.php, but I know where to find it, so I'll come back to this step if the install script throws an error. 
6. Checking my MAMP install against the instructions here. Hm. Well this is saying I DO need to create my DB (and here are those pesky user rights from above). hm! all these instructions overlap, so I'm just going to stick with this one, then check back on the INSTALL.txt instructions, and really everything should work fine anyway. Really appreciating the detailed instructions on this link for db creation (necessary or not). Found max_allowed_packet here, too. 
7. Annd filling out the db info on the install page... looks like I wont need much more from the help docs at this point, though I do wonder if I should do "minimal" or "standard." Standard makes sense for testing, rather than custom, right? right.
8. Ok, I think... I think that's done. I get the site login page, changed some settings as in the MAMP local instructions above, db works, only thing I feel stupid about is not installing in the directory I should have. Question: how could I move the entire shebang? What's connected? MAMP needs the location, but the installation script wrote a whole bunch of db links I'm not sure about. Not critical, just irritating to my file system.

And with that, I move on to the rest of the dev env instructions and start my first patch/module/test!

Web Design Process: Yet More Lists

ll right, first things first. Before I go trying to put my website together willy nilly, I need a plan, a master list of desired components and functionality, and a general idea of how to get from here to there. Disclaimer: I have not actually done this before! I've worked on sites designed by someone else, I've done some super basic HTML/CSS work (like my pesky resume and my placeholder website), and I've certainly spent plenty of time thinking about it and reading and researching. So here goes:

Things I'd like from my site:

• A Gallery of photos: no commenting, prints for sale, easily populated (Lightroom export?), cataloged by keyword, location, highly searchable, and someday I'd like it to include interactive collaging
• About/info page: bio 
• Contact: email, links to me elsewhere like twitter etc, RSS for photos and blog?
• Blog: old posts from blogger + new posts, shiny layout, browseable, comments, share buttons
• Portfolio: other design work, samples, articles, projects, certificates, whatever else
• Someday: a sandbox area near the portfolio for projects in progress, something to do with Github? 
• Aesthetic: simple, lots of white space (or black space), nice OFL (Open Font License) fonts and thin lines, simple image display, good navigation, one animation/movement/interactive element on top page. 

The basic steps outlined below are a combination of my notes from several sources. I learned most of the prototyping and user-testing steps from a class called Human Computer Interaction taught online by Scott Klemmer from Stanford. Not my favorite class on Coursera due to some frustration with the peer-grading setup, but nonetheless informative.

I also discovered that a local web design etc firm called Clikzy Creative posted their entire design process to their site so that clients will know what they're getting into. My process will be a bit different, of course, but it's good to know how a more formal environment would handle the same task.

• Essentially: "Discovery, Site Map, Content, Wireframe, Mockup, Revise, Develop, SEO, Launch."

The Moxie Design Studio also has their process up on their website. They do a bunch of websites for local Alexandria businesses, so I had seen their work quite a few places already. They also list a general set of project prices on their site, which is somewhat unusual, but very helpful since I had no idea what I should be charging for my work.

• So again, an essential process looks like: "Discussion, Goals, Mockups, Revisions, Development and Programming, Soft Launch and Client Training, Full Launch and two weeks included Support." 

It's really hard being independent and not letting clients take advantage of you by asking "just a quick question" that actually takes half an hour and is billable. And that's just one reason I'd rather not work for myself!

Back to my own website. A few basic steps to get there:

1. Define required elements - site map (above)
2. Find appropriate platform
3. Wireframing, prototypes, mockups - grids?
4. Testing it on unsuspecting potential users - feedback and revision
5. Build, develop, whatever you want to call it
6. Design details/ illustrations? Finishing touches
7. Later additions: animation, better databases? E-commerce... 

Each step along the way will probably be a bit more involved, but that should give me a good starting framework to go on. Don't mind me if both my website and blog suddenly disappear while I'm shuffling things around...

Optional HTML, good idea?

ack along the trail I was following in my post on carousels and web design firms I stumbled across Google's HTML and CSS Style Guide. This is, of course, just one resource in a sea of options, and as the name suggests, "more like guidelines, anyway." I found it useful to glance over to get an idea of what to do with my code once I had grasped some of the basic stuff.

The Style Guide has some helpful reminders about indentation (don't mix spaces and tabs, indent child elements), plus general etiquette (stick with the previous author's style, be consistent). The whole thing can be summed up as: optimize as much as possible, made code easy for collaborators to scan through. Somewhere halfway down the page, though, I found a section on optional HTML tags.

In all fairness, both Google and the WhatWG HTML5 spec frame this concept with "you may" and "consider" and other non-mandatory type phrasing. But I thought, hey, here's another way to be kind of minimalist, keep things tidy, not have more clutter than is really needed. And indeed, I could simply be rid of the <html>, <head>, <body> and a whole pile of closing tags. But! the traditionalist and skeptic in me took a pause and said, "Should I really mess with this right now? I haven't noticed this implemented anywhere, and my classes/research have all indicated that closing tags are the basis of a well-formed markup language. Maybe this is best left for another day."

Well ok, inner-skeptic, but I still want to learn a little more. So, some questions:

• What exactly constitutes a valid, well-formed markup language?

A markup language (ML just for now, though not to be confused with ML, the functional programming language I just couldn't deal with) is used to annotate and describe a document. I'm not going to go into the history and fascinating variety of MLs here, so suffice to say that in this case, for HTML or XML, the markup is intended to indicate what each tagged element contains. In HTML this could be a <header> or a <section>, which provide the browser with standard elements to display and style accordingly. XML uses tags to describe content, too, but is best suited to databases (DB). Since it is used in DBs, it is particularly necessary to have both starting and ending tags and to completely conform with the DB definition or else any references to each element would just fail. Not going into that here.

So a well-formed and valid bunch of whicheverML follows all the rules in the relevant specification and passes tests like the W3C validator. Well-formed generally refers to syntax, so elements that are arranged according the rules are syntactically correct. The traditional definition of well-formed includes closing anything that has an opening tag and properly nesting elements. A valid ML also follows its Document Type Definition (DTD), a sort of grammar dictionary for how to apply the language (here's the HTML4 DTD, for example). See the W3C validator's info here.

• How much of a difference in speed does tag omission really confer? 

There's not a ton of this out there on the surface, but again, Google has been implementing, or rather, omitting, the optional tags to decrease file size. When every bit counts, taking out even just a few characters here and there can add up to a big difference. According to the Google Developers article and video on reducing HTML document file size, this can actually result in "5-20% savings" in load time.

There's a conversation on StackOverflow from 2010 about how much of a difference this could actually make. It's hypothesized that especially at Google's size, "</body></html> is 14 characters and at 3 billion searches per day, it amounts to approximately39.12 GB of data per day ignoring compressions, or around 26 GB if we take gzipping into account." And another discussion from about the same time that goes more in depth on the whole issue. 

• Are there any arguments against tag omission on the whole?

Some people argue for tag omission for readability, others argue against tag omission for readability. So either way, people will eventually stumble through your code. The best reason not to omit is probably compatibility. Some browsers might not recognize an unclosed element properly, some scripts may get confused, it really depends what the content is expected to do. It winds up being a personal choice: you can include the superfluous, or you can be hyper meticulous and make sure you are only omitting tags that can be omitted and not getting confused in the process.

• Is this just one of those crazy, Google-is-way-ahead-of-everyone-else-again things?

Hard to say. Tag omission is out there, but most people don't need the speed that badly. The implementation status on the HTML5 spec only suggests that tag omission hasn't been tested on the latest browser builds.

Moving on, letting go

he hardest part of a project for me is deciding that it's finished. Usually it takes getting distracted by something new for me to really move on (this probably goes for some other stuff, too...) because otherwise I just can't let myself stop futzing, adjusting and perfecting. Translation: beating my head against something that just isn't making any more progress. So I have to learn to let it go, move forward.

In case you haven't been following along, in this case I'm referring to my "One Week Website" series of posts (clearly the timing didn't quite work out, but I never really expected it to). I started designing a new resume, and made great leaps of progress... until I ran into a wall attempting to make it perfectly responsive. This actually would have worked fine except that in keeping it super simple I was avoiding @media queries and pretty much everything except some basic CSS (see below).

And it was all going pretty well until I went to make a PDF. I have no idea how print formatting works, from web page to print dialog to PDF, but the margins didn't behave properly, it didn't fit on one page, and the white space looked weird instead of stylish (at least I hope the HTML version looks decent). So I reformatted a bit with those 800px min-widths on the #page-wrap and #content sections. Of course, now the #web and #general skills lists don't float and switch from side-by-side layout to being a single column, which means the 50% layout looks darn silly on mobile.

I tried using sections and header and h1-h6 instead of a flock of divs, and since this is a one use document, I just went with ids rather than classes. Feels wrong, though. At the very least, I have a resume that looks a little better than an old Word document, even if it isn't actually responsive. And! I did finally stop poking at it and just hit print.

body {font: normal 1em Times, serif;}
#page-wrap {width: 75%; margin: 5% auto; min-width: 800px;}
#me {display: inline-block; width: 100%; position: relative;}
#logoname {float: left; width: 25%; min-width: 165px;}
#logoname span span:first-of-type {color: #6C8771;}
#logoname span {color: #4D4D4D}
#contact {text-align: right; position: absolute; right: 0; bottom: 0;}
#content {width: 75%; float: right; min-width: 800px;}
#skills li {text-indent: -0.5em; padding-left: .5em;}
#web {float: left; width: 50%; clear: both;}
#general {float: left; width: 50%;}
#experience {clear: both;}
#learning li {display: inline; padding: 0 0.5em; border-left: 1px solid black;}
#learning li:last-child {border-right: 1px solid black;}

section {border-top: 1px solid black; padding-bottom: 20px;}
h1, h2, h3, h4, h5 {font-family: Baskerville, Palantino, serif; border-top: 1px solid black; margin: 0; padding: 0; display: inline-block; margin-bottom: 2%;}
h1 {font-size: 2em;}
h4 {float: left; font-size: 1.17em;}
h5 {padding-top: 3px;}
a {text-decoration: none; color: black;}
a:hover {color: gray;}
ul {list-style: none; padding:0; margin: 0;}
li {margin-bottom: 1%;}
dl {padding: 0; margin: 0;}
dt {padding-bottom: 1px;}
dd {padding-bottom: 1%;}

Now I just need to figure out if I really want to make my entire resume public on the internet. My feeling is no, not one bit, but then part of the point of doing it in HTML is lost. Still, it was fun to put together, and that's more important anyway.

Gitifying the OneWeekWebsiteList

ote to self: document as I go, not after the fact. It felt a lot like I was running in circles trying to find documentation and n00b help as I was working on this, so I didn't take notes along the way. A lot of the point of this first step was to familiarise myself with a few new systems (Git, GitHub, Terminal, Unix command line, Vim), as well as just publishing my strategy for creating a bigger, better website for myself. The entire project is more about learning than having a finished product (although it would be nice to sell a photo again, someday), so each post is intended as a reference for myself, as you'll note from the links peppered throughout the text below.

I apologise in advance, too, for these posts likely being very dry, incoherent and plentiful. I'm often writing from the top of my head and focusing on developing and documenting rather than fine literary prose. Coincidentally, my horoscope for today:

Once you break down a task into manageable chunks, you'll discover that your challenges are not really that hard. You are absolutely capable of meeting the goal you projected at the beginning.

Essential breakdown of Gitification of The List:

• Wrote project todo list.
• Thought about purpose and use of list- dynamic, changing, updating steps as I go to keep track of overall process.
• Translated list into HTML 
• Created GitHub repository (repo) for new project, cloned repo onto local drive
• Updated and committed ReadMe file on GitHub
• Discovered that this threw my local clone out of sync, figured out basics of git pull.
• Finally figured out how to control the vim editor in Terminal (thanks largely to the patient human who helped me with basic commands) to add messages to merges and commits when I forget to use the -m option .
• At this point, the list was basically done, and pushed to GitHub. 
• Researched how to publish a repo to the web so that it looks like an actual page. I had seen a friend do this with a basic design portfolio, but couldn't find a simple button to push in order to see repo files in anything other than raw code. 
• Turns out I had to create an entire new branch in my repo, move everything, and when it still didn't seem to be working, realised I had left off the obvious !DOCTYPE declaration.  Actually, I could have just left it and popped in a reference or something. oh well.
• Had also found this Google Style Guide, which mentioned that some element tags are optional in HTML5. So I guess my dunderheadedness over formatting my initial list file wasn't actually critical, but I haven't implemented the recommendations yet. Also ran it past a W3C validator. 
• Meanwhile, I just need to get the published OneWeekWebsiteList.html into my blogpost, somehow, in a way that would save me from updating said blogpost every time I modified the original file. I found the embed element in the HTML5 spec to be a simple solution. Presumably there's some way I should have done this with PHP or scripting or one of those things I don't know how to do yet.
• So, one properly sized embed element and a div element with simple border later, the list mostly worked as dynamic content. 

Unfortunately, I couldn't discover until after publishing that the embedded HTML file doesn't display in Google Reader. It's visible in the RSS feed itself, so the problem comes somewhere in the aggregator?

I would love to hear about better solutions to this problem, as I just went for the first option I could find in the interest of moving forward. I've also just now switched to an object element, since embed seems to be intended for non-HTML content. Any thoughts?

One Week Website

ow, in all fairness, this was a very optimistic concept on my part. I can put together a decent looking personal website in a week, no problem. Getting through the entire process I've outlined below, blogging and documenting each step, including research, references, background, backend, comparison shopping, self-analysis and content transfer? Not so easy.

The idea, however, in documenting the entire process is that I, and anyone else who cares to poke around, can review my notes and see the progress I've made and the time/effort I put in to doing a relatively thorough job. Thoroughness might actually be a fault of mine. I have a need to understand everything about a topic, to understand how the wheel works before I drive the car, etc. I can't just install WordPress (WP) and go with it, I need to understand how the backend works, how my data and files are structured, how I can query that database, and why that form is the right choice for me.

This means my initial process is slower than would be ideal, but I think the payoff in the long run will be greater. I have learned to let some things slide for the time being, marking them to revisit later when I have enough background to understand them better.

First, I need to figure out how to track this list. Do I want to Gitify (version track) it? repost at the end of each sub-post? certainly link back to the original list with each execution of a list item. It seems like a version-tracked version I can update and reference would be best... without having to republish every time I make a change. So I'll have to embed the list (published github page) itself:

ps. Yes, this looks ghastly. I need to publish and then iterate. I hear this is a thing you do.
pps. I see the embed doesn't work in Google Reader. Will have to figure that out, too.