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.

Sketchy resume design

he most important thing to me right now is keeping my perspective. If my goals aren't in clear sight, I get massive scope creep and wind up trying to learn Unix instead of just working on my HTML project (see hereabouts). However, at this stage it's also important for me to be exploring, dabbling, learning everything I can, and even when projects don't work out or seem unreasonable in some way, I do still learn something from the experience.

Take the newfangled resume I created, for instance. It didn't come out quite as responsive as I hoped, largely because of some finicky elements and my avoidance of media breakpoints. What was interesting, however, was talking to a friend who is familiar with hiring processes at a very prominent tech company. He indicated that a good looking resume is nice and all, but what's most important is a) contact info and b) recent experience. The rest is just noise.

In all fairness, programmers are not necessarily interested in shmancy presentation and part of my goal was showing web design skills. However that was pretty irrelevant when I realized I didn't really want to host my resume publicly on my website.

The process was kind of interesting. I had a basic idea what I wanted to do, drew up some rough sketches (above) with actual pencil and paper (I can't handle initial sketching on a screen, sort of like how I just can't stand e-books. I'm a holdover, I know.) Then I entered my content in an HTML document, put it into sections and got the basic structure marked up. From there it was all about CSS, I barely touched the HTML document again except to add some id attributes. Below are some screencaps of the layout along the way, shown with boxes and dotted borders so I could keep track of what element was where. I admit I went a little crazy with the colors...

And yes, I blurred them, because the text isn't the point here. Some of my original ideas were even more abstract, but it became clear that I did need to say something about what skills came from which job. I considered doing this with some sort of clever mouseover thing, where a line from skill to experience would pop up, but decided that was definitely too fussy.

Anywho, one important question that came up in the process was how relative placement communicated relationship and meaning of each element. Elements next to each other would speak to each other in some way and have some relationship. I think I may just go back to my old, boring resume (though with less hideous layout, at least).

... After all that, I'm very done with this stage. Anyone have experience with designed v. functional resumes? Does a different layout affect your opinion of identical content?

EDIT: on structure, I leaned on the HTML outline concept, but didn't include this link here, I don't think.

Book review: Feynman's Rainbow

hen I started reading Feynman's Rainbow, all I knew about it was that it was on my to-read stack as a result of being a recent gift, and of course the title. I mean, heck, it includes "Feynman," what could go wrong? I had forgotten the other reference point that came with it: Leonard Mlodinow was also a writer for Star Trek. This finally occurred to me somewhere later in the book when he mentions his writing hobby and desire to become a screenwriter.

Most of the memoir/biography is about Mlodinow's time at Caltech in the 1980s, when he was unsure as to his worth as a physicist (and human being, since these things tend to devolve quickly into total failure of confidence). Supposedly, Rainbow is more about Feynman than Mlodinow, hence "biography," but I found it to be more focused on the author's soul-searching and interactions with many other characters at Caltech. Sure, there are big block quotes from his conversations with Feynman, but they're more anecdotal than anything else. That makes me think that the book rides on the famous physicist's name, but survives on the actual content.

Double rainbow over Marlboro College, 2006

And it was rather compelling content, too. Perhaps that's just because I feel like I'm in a similar, confusing, in-between place where I'm not terribly confident in my abilities. Still, Mlodinow's writing was engaging and he explained the related physics in straight-forward terms, just to fill the reader in on context.

While the book's title comes from a particular section on finding what is beautiful and amazing to you and then following that sense to your life's work, I particularly appreciated this quotation from Feynman:

I have to think I have a little bit better chance than the other guys, for some reason. I know in my heart that it is likely false, and likely the particular attitude I'm taking with it was thought of by others. I don't care; I fool myself into thinking I have an extra chance. That I have something to contribute. Otherwise I may as well wait for him to do it, whoever it is. 

What color is your flower?

few weeks ago a friend suggested that I fill out the "Flower exercise" from What Color Is Your Parachute? The exercise is designed to help you figure out what you're looking for in a career, and from what I can tell, it's also the core of Parachute (My copy is from something like 1980, and I haven't quite managed to read it). The book actually goes into quite a lot of detail on how to fill out the flower, but you can also just wing it based on the petal titles.

I know, it sounds a little hokey. I thought so too, especially since I thought I had a pretty good idea what I was looking for already, but I went with it. Turns out it's always helpful to get thoughts outside your head, whether to see all the facts in one place, leave reminders for yourself or generate new thoughts in the process. I don't want to make mine entirely public, but here are a few things I'm looking to do in my career:

• Make information widely available and easy to access. That could be something straightforward like library work, or structuring webpages so that users can find what they're looking for plus several things they weren't. It could even be backend support for projects with this as a goal, e.g. part of a multidisciplinary team.
• Help people become inspired to be self-motivated, informed learners who never just say "I don't know," but rather "Let's look it up."
• Provide information services through products that are viable, upgradeable, scaleable and generally future friendly. So, no silos, relative links, transferable data, that sort of thing. 

As for skills, I have profiles on Coursera and Codecademy that will give a bit of an idea what MOOCs I've been fiddling with, and this project should also make it pretty clear what I'm capable of (anything! mwahaha*ahem). Generally: HTML, CSS, JS, some SQL and PHP, WordPress, Photoshop, Lightroom, baking, gardening... 

The other petals include things like: I'd like to work in a sunny, friendly office, with bikeability, sensible benefits, and most importantly lots of opportunity for learning and inspiration from colleagues, classes, workshops, conferences. 

And continuing with the embedding problem, here are some snippets of Parachute from Google Books in an iframe:

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.

Orwellian syntax

he title of this post is a little iffy, but I think it works in a couple of ways. First, the content here is by George Orwell, therefore is by definition Orwellian, right? Secondly, his proposed overhaul of the English language (which we'll get to as soon as I'm done justifying and rationalising) is a bit on the totalitarian side, ergo, Orwellian. And uh, Thirdly... thirdly... oh yes, his criticism of the current state of prose essentially compares it to the sort of meaningless catchphrases found in 1984, where words cease to have any relation to their meaning and generally cause the downfall of civilisation as we know it.

That pretty much sums it up, actually, but a little context: I've just read George Orwell's essay on Politics and the English Language. The essay alternates between lambasting several samples of [truly lousy] writing and prescribing a few guidelines to avoid further transgressions. It was written in 1946, so we can only imagine how pained Orwell would be to see the current state of the written word (probably including my own. erk.). I bet he and Hemingway would've gotten along in some ways...

And now, for my own reference and for yours, George Orwell's basic rules for passable writing:

(i) Never use a metaphor, simile or other figure of speech which you are used to seeing in print.
(ii) Never use a long word where a short one will do.
(iii) If it is possible to cut a word out, always cut it out.
(iv) Never use the passive where you can use the active.
(v) Never use a foreign phrase, a scientific word or a jargon word if you can think of an everyday English equivalent.
(vi) Break any of these rules sooner than say anything outright barbarous.

Taken from the essay Politics and the English Language, 1946, page 156 of George Orwell, A Collection of Essays, Harcourt Brace, 1981. 

Mini reviews: Etiquette and conversation, or, "An echo is sufficient"

any of the books I looked through in search of advice on how to be a good conversationalist made the same points: remember that you are conversing with someone, not interrogating or soliloquizing.  What I'm looking for is how to ask good questions, what topics to bring up and just what to say in general. Many sources point out the usual topics: weather, travel, news, even the forbidden politics and religion, and strongly recommend against talking about yourself. The easiest way to remember this is to avoid using "I" and "Me" as much as possible. It can be tricky at first and often leads to getting even more tongue tied, but making conversation or writing without the dreaded personal pronouns is an entertaining challenge.

Emily Post's Etiquette- Etiquette focuses on how to be polite and interact appropriately in any situation. The seminal work on traditional etiquette is perhaps my favourite reference out of all that I read through because it takes a more conservative view of manners and proper conduct. Sadly, the young men whom I ran some of Post's points past were more of the opinion that the "liberated woman" doesn't need the door held, her dinner paid for, or any sort of special consideration. She is equal, therefore she is one of of the guys! Mais non, the liberated woman just doesn't want to do all the damn dishes herself. Again.

Grace Under Pressure- This is the book of tactics for those situations you'd never admit to being in. Pulling your reputation back together after a mishap at the company party, getting by at an ex's wedding, and generally how to be gracious and sensitive no matter what. On conversation: a good section on how to start conversations, balancing questions and responses, listening (which makes all the difference when it comes time to reply), getting out of bad small talk, insults, and introducing yourself to strangers. Comes with entertaining anecdotes and scandal (clearly the selling point: this would never be me!).

21st Century Etiquette- Frankly, don't bother with this one. Outdated references to electronic mail and chatrooms, "teens" as children, slightly condescending "quizzes" at the ends of chapters and generally a bit simplistic.  And there wasn't much on conversation.

What do you say when...- More quizzes. I suppose this is a style, as if it were a workbook, but I don't love it. Also a more traditional viewpoint with some good thoughts, and short, so a quick read. There's a good section on romantic meetings that also applies to platonic interactions and meeting new people. Worth it because the book is dedicated to conversation.

The Art of Mingling- Finally, we get past some of the more clichéd approaches (Haven't I seen you somewhere before?) to ideas on how to continue the conversation. Some of the ideas will sound pretty awkward ("This party is a virtual utopia" comes from the a-z list of words to build from when at a loss), but there are plenty such as watching from afar with another wall flower, asking a group a random question to poll responses and start a debate and so on. Kind of dorky to be seen with, but essentially quite useful.

Conversation: A History of a Declining Art- Certainly this is the most expansive and in-depth of all those I checked out... which unfortunately means I did not have time to read it in its entirety. However, I can say that having skimmed a bit, it looks to be perhaps more useful than any of the aforementioned because not only does it include methods from historical conversationalists (hello, Socrates?), but it's actually worth talking about the subject matter when you're done. Will take this one out later to read in full.

Then we come to The Art of Conversation and The Art of Civilized Conversation. Different authors and publishers, but you can just see the expression on the face of the former when she discovered the latter. These are both dense, full of lists, do's and dont's and bullets. The first, however, has the following passage:

"In the 1960s... computer pioneer Joseph Weizenbaum created Doctor, a software program that adapted a psychotherapy technique for bouncing back patients' statements as questions:

User: I have been rather depressed lately.
Computer: Are you depressed often?
User: Yes, almost all the time.
Computer: Why do you say yes almost all the time?
User: Right now I feel like I could cry.
Computer: Is it because right now you feel like you could cry that you came to me?

One morning he was appalled to discover his transfixed secretary at a computer, unspooling her sorrows into Doctor's clunky, copycat code. ...So the thought that an echo is sufficient to convince us we're being listened to, that the bogus Doctor could seduce the secretary, carries the degrading suggestion that much of human complexity—those worries and wonders we store up and long to share—may also be illusory, empty, and that we are mere bundles of reactions, mysterious and meaningful only to us."

Thanks to the Arlington VA public library for having all these books and putting them on hold for me.

Quotations, photos and ponderings, all. at. once.

    "You can live a lifetime and, at the end of it, know more about other people than you know about yourself. You learn to watch other people, but you never watch yourself because you strive against loneliness. If you read a book, or shuffle a deck of cards, or care for a dog, you are avoiding yourself. The abhorrence of loneliness is as natural as wanting to live at all. If it were otherwise, men would never have bothered to make an alphabet, nor to have fashioned words out of what were only animal sounds, nor to have crossed continents — each man to see what the other looked like. 

     Being alone in an aeroplane for even so short a time as a night and a day, irrevocably alone, with nothing to observe but your instruments and you own hands in semi-darkness, nothing to contemplate but the size of your small courage, nothing to wonder about but the beliefs, the faces and the hopes rooted in your mind — such an experience can be as startling as the first awareness of a stranger walking by your side at night. You are the stranger."

  Beryl Markham, West with the Night.

I already posted a passage from West with the Night, but since that was specifically relevant to the airplane post, here's a little more about the book itself: Generally, West with the Night is a ruminative, verbose, sweeping memoir that covers three notably distinct parts of Markham's life. After writing herself into the narrative, she takes the reader through her childhood, hunting lion with African locals, to leaving home and training race-horses, and finally to her career as a freelance pilot. 

So much of the book draws its strength from descriptions of people and places that the silence felt in the above passage is as startling to the reader as it is to Markham. The change from lengthy, illustrative passages about the African landscape and the characters who occupy it to the breathless and fleeting few paragraphs articulating her personal experience of flight parallels her assertion about loneliness. Most everything we do in our day-to-day lives is engineered to keep us from noticing that we are really very alone in the world, thus we keep self-awareness to a minimum in the interest of maintaining sanity. Even when physically alone, humans go to great lengths to avoid confronting themselves, whether by immersion in external stimuli, abuse of a substance, or simply by locking away their thoughts in a mental prison and living in denial of themselves. 

In conclusion, but not really to conclude this ongoing train of thought, West with the Night was an inspiring memoir not just in terms of tangible accomplishments and admirable writing, but in the additions Markham's personal philosophy made to my own modus operandi. Someday, I hope to meet myself.

Photo is of the Potomac River near Theodore Roosevelt Island, April 15, 2011.

Photos/Ponderings: Dichotomies

Perhaps, we like dissonance because it is so full of expectation for resolution.
Perhaps, we like observing other people's tribulations from within our own safe shells.

No matter how long difficult times last, there is always hope of conclusion and mending, even when it should be left behind.
No matter how implausible an ideal denouement may be, we cling to it rather than take the tougher, circuitous path forward to our eventual goal.

And when we do have to accept an undesirable outcome, when one occurs despite our efforts, we change our way of thinking so that we may say, Yes, this is what I meant to happen. It is good.

Photos are both mine from this Autumn; Top are sailboats in Annapolis Harbor during the Boat Show, the sunset is from Chincoteague Island, VA. Both will get bigger if you click on them, but please don't steal w/out credit and due publicity.

ps. It seems that my photo posts are package deals with ponderings. And alliteration.

Signs of weakness, or, On being vulnerable

Unsolicited signs of affection, thoughtful little gifts, unexpected phone calls, showing up at the door unannounced, expressing opinions that you're sure are wrong, or at least unusual, admitting when you hurt and when you love, pointing out mistakes, offering help to friends and strangers...

I know this has been said before, but what's the benefit in hiding yourself? By not expressing our unique opinions and acting as we feel, people stuff themselves into the shapes they think everyone else wants to see. Then we become predictable, at worst, uninteresting and monotonous.

But, in hiding our real feelings, intentions, inclinations and not acting spontaneously or ad-libbing it once in a while, we are also safe. If you don't go to her door at 10 o'clock at night to tell her how you feel, you certainly wont get shut down, but you might also be missing the love of your life. Or at least the love of the next year. If you present what you think is a harebrained idea at the morning meeting, maybe everyone will think you're crazy, but then again, maybe that's just what they need, and chances are more crazy ideas will advance your stagnant career.

So, speak out and risk something every day, perpetuate unexpected deeds, and for heaven's sake, quit stalling your life.

Photo is mine, 9/4/2010 on the drive to Chincoteague, VA.