Monday, June 23, 2014

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

Saturday, June 14, 2014

That avocado-quinoa thing

Last week in Austin I had the pleasure of dining at Lambert's BBQ with a couple of fellow Drupalists. We ordered a fleet of tasty dishes, but made particular note of an avocado/quinoa confabulation that lay beneath a trout: Cold Smoked Rainbow Trout, Avocado Quinoa, Bella Verde Cilantro, Tomato & Serrano Vinaigrette. The quinoa adhered to the little blocks of avocado and added subtle crunch to each bite, while also imparting significant flavor for two typically understated ingredients. Must've been _some_ vinaigrette. So, I decided to try to create something similar. And got a little distracted, so it's completely different, but not bad.

Avocado and Quinoa salad-thing

1 cup quinoa, any variety (the restaurant used plain, I used tricolor)
1 tbl olive oil, salt
~2 cups water

Toast the quinoa in the olive oil and salt until it begins to smell nutty. Add the water, bring to a boil, then simmer until the water is absorbed and the quinoa is the desired texture. Let cool.

1 small cucumber
1 small onion (red)

Meanwhile, dice cucumber and onion (I had a spring onion, but red would probably be better). Toss together in a bowl.

2 limes
2 avocados

Squeeze a couple of limes and reserve the juice (debatably, lemon might've been better). Dice two avocados (peel then slice) and toss with lime juice.

handful of cilantro
couple sprigs dill
salt and pepper

Chop herbs, add to cucumber and onion along with avocado and lime juice. Salt and pepper to taste and careful fold everything together with the quinoa. Let sit in the fridge for a bit for the flavors to relax, then serve at room temperature or chilled.

Suggestions welcome!

Wednesday, June 11, 2014

The Joy of "The Joy"


This article originally appeared in the Mountain Courier in March 2013, and I completely forgot to post it to my blog! My friend Suzanne, who edits and writes for the paper, suggested I write the article after seeing my collection of Joys in my kitchen pantry.

The sun slowly rises over a small sea of pop-up tents, my coffee and my breath adding to the quietly dissipating morning fog. A lone jogger pads by, the only traffic at this early hour. Piles of neatly stacked root vegetables, compulsively organized by a sleep-deprived farmer, wait patiently for the 10 am rush. My numbing fingers flick through the pages of a cookbook I’m perusing, looking for recipes to recommend with today’s cuts of grass-fed beef, pork, lamb and chicken that I’m here to peddle.

I was a vegetarian for the first 20 or so years of my life and have since been playing catch-up on how to cook things like pork belly and beef tongue. My customers and I, the adult novice, have found this particular cookbook quite handy for basic information and creative uses for a wide range of ingredients, both familiar and novel. The book is the Joy of Cooking, my ultimate guide on all things food.

Farm markets vary greatly across the region and the seasons, which translates into a certain amount of uncertainty as to what will be available at any given time. Seasonal produce is preferable for freshness, nutrition and the local economy, but sometimes one just doesn’t know what to do with a pile of kale and turnips, much less the wealth of parsnips or variety meats. It is here, in the unexpected and unexplored, that a good reference on cooking becomes invaluable.

It was not my intention to collect multiple editions of the Joy of Cooking. When my first copy came to me, I was more interested in it as a book—an antique livre to add to my library—than as a cookbook. A quick read-through, however, inspired me to assemble an unnecessarily complex cake using separate recipes for the batter, frosting, filling, and probably cake syrup as well, not to mention decoration. My notes on the subject are still tucked into the pages of this 1943 edition (1946 printing).

This first Joy was a gift from my mother, purchased in an antiquarian bookshop in Vermont on the advent of my first apartment, and thereby my first kitchen. Before this, my cooking skills had approximately encompassed rice, eggs, and—thanks to a summer in a friend’s well-appointed kitchen—homemade pizza and cinnamon rolls. As a vegetarian still working on my thesis, my most elaborate dish was stir-fried vegetables with tofu. The Joy was essential to me for basic instructions, factual lookups, information on the latest new ingredient from the food co-op and rules for baking. It was indeed the ideal first cookbook.

As things progressed I acquired two more editions: a brand new 75th anniversary revision bought as retail therapy, and my grandmother’s own 1952 edition complete with her notes and clippings. My three copies currently reside with a 1972 revision owned by a roommate; four Joys in total.

Irma Rombauer’s first edition came into being in 1931 as a collection of personal recipes from her “Victorian roots” to pass on to her children as they left the nest. It was also intended as a helpful guide to the newly minted housewife, alone and bewildered in her kitchen, written to be “so clear that a child can follow it.”

The early editions were a very personal affair for Irma and her daughter, Marion Rombauer Becker, who provided the first illustrations as well as helping her mother test recipes and organize the book. Irma’s wit and familiar tone lend themselves to a very friendly text in which the cook can feel as if she has a personal relationship with her cookbook and its writer. My 1943 Joy includes advice on war rationing, as well as bunches of recipes for aspics, gelatine salads, timbales and soufflés, all in the interest of disguising an array of leftovers. My recipe of choice, however, is for Crepes Suzette (essentially flaming French pancakes), which comes with an amusing anecdote about the dish’s origins with Chef Henri Charpentier and the Prince of Wales.

Both the 1943 and 1952 editions contain extensive advice on entertaining, how to execute full dinner service and from which direction the servants should serve the fish course. There is a handy chart on various fish and how to cook them, quite a lot on baking and confections, nutrition charts, wine charts, herb charts, leftovers charts and a glossary. Irma also took care to “give this book the impression of sobriety and stability it deserves [such that] the alcoholic cocktails have been relegated to the chapter on Beverages.” On the other hand, she also acknowledged that while smoking at the dinner table was très gauche (it destroys the palate), the hostess must provide cigarettes and an ash tray to make her guests as comfortable as possible.

My grandmother’s Joy, the 1952 revision, continues largely along the same track as the 1943 with general rules aimed at gaining an understanding and then a variety of applications. There are some exciting additions such as more pasta, which “takes a good deal of doctoring to make palatable,” a more organized list of household hints and with the new illustrator, Ginnie Hoffman, diagrams for everything. Irma and Marion can be seen slightly at odds in the introduction, where Irma insists that no cook will read anything but the recipe and information that he or she is looking for, while Marion believes that explaining how the book works is worth a page or two.

These earlier versions also include a fairly extensive section on game lumped in with poultry. Terrapin, of course, is now protected under the Endangered Species Act, and not many would consider squirrel a viable food source, never mind bear. While the inclusion of frog legs, aspics and the use of the singular “cooky” may give these editions a dated appearance, even the very earliest Joy in my collection emphasizes nutrition, taking note of Americans’ tendency toward overeating and not balancing caloric intake with nutritional needs.

As time and culture have progressed through the last 75 years, the target audience shifted away from the blushing bride and housewife toward an independent new cook. In the middle years, many sections bit the dust, including “Know Your Ingredients,” much of the entertaining instruction, and the gelatine concoctions. The 1970s were a time when horizons and palates were broadening, food was being shipped greater distances and people were eating tofu, of all things. Marion Rombauer Becker reorganized the book into sections on The Foods We Eat, Heat and Keep, which meant that absolutely everything was shuffled and, I found, rearranged in illogical order. The 1975 edition was the most popular Joy ever, so it must have made sense to most readers and cooks.

Which brings us to the 75th anniversary Joy, published in 2006, thanks to Ethan Becker, Marion’s son. As a Rombauer broodling and graduate of Le Cordon Bleu, Ethan brought respect for heritage and tradition while being open to change. The revision he put together organizes the recipes once again by their place in a meal, beginning with drinks, then hors d’oeuvres, vegetables, meats, desserts, and finishing with methods for preserving. The glory of this edition is the encyclopedic appendix that brings back “Know Your Ingredients,” a plethora of substitution, conversion and other charts, and information on every method you might need to know. Contrary to my assumption, this edition actually contains an expanded section on game, although the handy diagram on squirrel is omitted.

So here we are, back from market with an armload of food, ready to experiment, to learn a new way of preparing a favorite squash and what exactly to do with a bundle of fiddleheads. Any bride, bachelor, or impulse shopper will find his or her way with Joy, branching out into ethnic cuisines, more modern dishes and favorite personal recipes from Ethan, Marion and Irma herself.

Epilogue: I have since also acquired a mint condition, dust jacket-intact 1964 edition of Joy. It is happily nested with the others and gets regular attention from the chef.

The original version of this article in the print edition is here as a PDF. It includes tidibits from other contributors in a four page layout extravaganza.

Friday, May 30, 2014

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!

Tuesday, May 27, 2014

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.

Tuesday, April 22, 2014

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.

Monday, April 21, 2014

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]

Friday, March 7, 2014

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.

Monday, December 30, 2013

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...

Monday, October 14, 2013

In which I stumble over PHP

his post was originally just called "learning by doing," but then I was feeling so embarrassed about not recognizing PHP when I fell over it that I renamed it. This post is also on understanding the elements of hook_help() in general in order to write views_help(). Warning: contains questions that are not-stupid!

1. What does $output = ''; do, exactly?
This is most likely a PHP thing, which I have absolutely zero experience with. I know $ as jQuery, but now I'm not even sure that's what it's doing here. Yeah, that would be PHP- the $ indicates a variable. I've been avoiding learning PHP for the timebeing in the interest of focusing elsewhere without distraction, but a quick look through the PHP online documentation will help me with the syntax here. This explains why no one answered my pathetic pleas for explanation on this previously. I feel pretty dumb for not recognizing/thinking of this right off. The functions look enough like functions that I wasn't paying much attention to details, but... yeah.

So, question part B: why so many lines for defining $output? Why not in one big block? Is that just for readability, using a new line of PHP for what would be a new line of HTML? The first line $output = ''; is just initializing the output variable, or rather, defining it. Subsequent lines $output .= ''; are concatenating, or adding, those strings onto the previous definitions. Now I'm looking at coding best practices for Drupal and for PHP. This also spills over into question 2, below.

2. $output .= '<h3>' . t('About') . '</h3>'; What are the periods doing in there? 

The separation of html elements and the string to be translated makes sense, no reason to include code in translatable strings. The periods seem to be for concatenation of strings/elements in the $output variable, since otherwise just using = would reassign the entire variable.

In alexpott's Drupalcon Prague session From Not-Invented-Here to Proudly-Found-Elsewhere: A Drupal 8 Story, he recommends PHP The Right Way, which just happens to have a few more opinions on things than the standard PHP docs (new version in beta!).

In PHP The Right Way, we find a note on concatenation recommending that strings be kept under 120 characters, and that if they should be longer, to use concatenation operators (eg a period, . ) combined with indented newlines for readability. This method is recommended over using concatenating assignment operators (eg period equals, .= ). The example of what not to do looks exactly like our $output variable here.

... which means I found the right bit of doc! and that it's usually impossible to keep up with standards, best practices and the latest in code. Plus, I'm sure I'm still missing some reasoning and background here.

3. More on the translate function t():

In views_help() the translate function is part of the concatenated string assigned to $output. In point two, above, it marks the string "About" as translatable: t('About'). Whatever is inside the translate function is added to the database of strings to be translated into the current language from English, which is the standard. The translate function works with the Localization API to pick out which bits of text are translatable.

The Localization API seems to mostly do the work of targeting strings for translation either through a translate function or "known locations." The translate function identifies strings, and the Localization Server extracts them. You know, I'm a somewhat visual person, I just keep wanting maps for all these things.

EDIT: This bit from the Drupal JS API docs finally explains how the translate function works:
The Drupal.locale property works in conjunction with Drupal.t(), the JavaScript equivalent of the server-side t() function. It holds a collection of string translations so that Drupal.t() can then access the required string from Drupal.locale in order to translate what was passed into it.

4. What are these link tokens? ! is preferable to @?

After my preliminary expectations of easiness on this one were doused, I think I at least determined that this is not the same sort of token as the generic placeholder substitution token. It seems that instead of just using <a> tags, links are created using link tokens and an array. Previously, the links were marked with @, but from a comment on the views_help issue I've gathered that ! is the new @. Perhaps this is another PHP thing. Perhaps I will just go read my PHP books now and call it quits on this blogpost.


Read next: Working with JS in Drupal

And in the meantime: watch session slideshows from DrupalCon Prague! I'm so happy these are available.

And also, finally went to do something with Drush and found it not cooperating, so now I need to backtrack on that, put it back together, and hope that the latest version is really the right thing for D8. Oh, now I really feel dumb. Should have watched this session from Prague first, too. Somewhere in the process of downloading the latest, adjusting .bash_profile and connecting to the example aliases file, I broke it even worse. And creating a mysql file somewhere to cooperate with MAMP.

All this is in the notes on the Drush github page, of course, but after a while I just started feeling like a complete moron. Finally figured out that drush self-update is no longer included (I must've had a much older version installed earlier, not sure how/why), found a drush cheatsheet, and managed to uninstall my modules, check my modules, reinstall... I think I've got it now, but jeez. I keep getting stuck between versions, missing important documentation and feeling really lost, which is incredibly discouraging because then I can't even begin to do simple tasks. Hopefully if I just keep chugging along it'll all work eventually.