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.


Thursday, September 19, 2013

Learning is easy, doing is difficult

E
veryone knows this - the potential for failure increases with the amount of work you're doing. What I need to keep in mind is that it will also plateau and decrease as I gain experience and skills over time, and that it will take time to get there. Patience is not always easy.

I learn by winging it, charging into a project and trying to do everything right away. Once I figure out that I can't bulldoze my way through, I start getting a sense for what I need to know, then I can backtrack and fill in the gaps before going forward or finishing up. It's not necessarily a great strategy, and sometimes leads to excessive frustration and going in circles, so I try to recognize when I'm just wasting time beating my head against something.

One of the things I thought I should do before I get too much further is just to go through some of the basic and general documentation for Drupal, so I have a better sense of how it works on both the front and back end. Sometimes when I start thinking I've got a hold on things I just glance over at the #drupal-contribute channel on IRC and feel humbled. Anyway, some disjointed notes:

Understanding Drupal- the basic stuff, explaining the system from the front.
Drupal 8.x API reference- all the stuff I've felt clueless about; hooks, menus, useful things when you're poking at core.

I had a poke around DrupalSites.net to see if anyone had something like what I want to do... no luck. Mostly I need to be able to use taxonomy terms on photos and blog posts (and whatever else I may add) and be able to search, sort, combine, filter etc for browsing (hello Views, my new best friend). And I'd like to be able to upload and update directly from Lightroom. I have a Lightroom plugin that lets me upload to Picasaweb and update files remotely without having to touch the site itself. So that's most of my needs, apart from some static pages for "About" and whatnot (see previous post): Taxonomy and ease of upload/modification.

...And someday, e-commerce. At that point, possibly authenticated users who can create little albums of my photos, save and share combinations that explore how each photo speaks to another through composition, color, subject, mood. I'm seeing this with draggable stuff, a large "desktop" where "prints" can be moved around freely, just as you would when laying out a gallery show using contact prints. But that's all someday. Maybe not even until after the D8 release, so going backwards to a D7 site would just flatten my little brain.

Cron jobs- at last I know how this works in the filesystem. (I'm less sure why I kept the bit below:)
  • status: A bitmapped field indicating the status of the file. The first 8 bits are reserved for Drupal core. The least significant bit indicates temporary (0) or permanent (1). Temporary files older than DRUPAL_MAXIMUM_TEMP_FILE_AGE will be removed during cron runs.
All caps is a constant?


I plucked out a new task from the queue for myself, since it looked pretty easy and writing documentation is always a good way to learn more. While I'm in the API docs, I thought to check out how hook_help() works (keep in mind here that I know zero PHP, only some jQuery, and a bit of JS generally). Now I not only have a better idea what I'm trying to write for views_help(), but I have context for understand how hooks work. whee! I've only drafted some text so far, but might go ahead and make the patch so it can keep moving forward. 

There's a doc for writing the help text itself, but I still need to figure out/understand what exactly output=. does and if there's a more sensible way to deal with the translation bits t() than adding them in by hand, not that that would be super difficult in this case. Maybe somewhere in the Multilingual Support docs... Localization API? ah-ha. Well again, at least now I sort of understand all that. 

I think that's enough for one post, more later!


Friday, August 23, 2013

Afternoon coffee (at 7 pm)

T
hese things always begin with the best of intentions, not to mention quite innocently. I had two objectives this afternoon (oh dear, and I see it's now 7pm. oops):
• Have a cup of coffee and plow through some documentation. And, I prefer having a small snack with my coffee, a croissant, a cookie, a slice of cake...
• Use up the heavy cream I accidentally bought to go in said coffee because I hadn't had coffee yet (the lack of a dilutionary dairy substance being the issue) and so instead of the milk I usually get I got a half litre of very thick, organic cream.

So what did I do? well I tweeted of course, asking for recipes. @HarlanH (data scientist extraordinaire) thoughtfully replied and reminded me of the existence of recipes that aren't for baked goods. Crazy, right? In retrospect, I ought to have just gone with his first thought and done a cream sauce for pasta. Instead, I followed his other recommendation to check out something called Eat Your Books.

As it turns out, Eat Your Books is a handy dandy, plug your cookbooks/magazines/blogs into it-search engine for physical collections. I faintly heard choirs of angels as I poked through the homepage: finally, I can search my cookbooks without pulling each one off the (rather precarious) shelf and flicking through the index, then a handful of recipes trying to find a use for my one stray ingredient! That method works ok for main ingredients, like zucchini, or pork chops, or even chocolate, but not for say, whole vanilla beans, cracked wheat, or, in this case, heavy cream.

I added my top cookbooks with haste. A free subscription only allows 5 resources on your e-shelf: Mastering the Art of French Cooking, The Art of French Baking, The Essentials of Baking, The Joy of Cooking and The Pie and Pastry Bible. That covers everything I usually look through, anyway. And lo, five hundred and forty four recipes appeared!

It being me, I didn't really have many other ingredients on hand apart from the standard baking arsenal, so I used the filters to narrow things down to "cakes." The filters are actually quite useful. Frankly, a paid subscription would be worth it, only $25 a year, I think. I would prefer some integration with other services, maybe add things I bought on Amazon, or pull in my "cookbooks" tag from LibraryThing. More so, I would like to be able to search all my physical books digitally. I can always use Google Books, but I don't think I've seen a service that will let me save my books and then search them. I'd love to be wrong about this, so please correct me if that's the case.

Right, so anyway, I wound up with a recipe from the 75th Anniversary Joy for Black Forest Cake. I made it a little easier, just two layers instead of three, and amusingly enough, I had half as much heavy cream as it called for (still plenty). I also had some sweet cherries I preserved in brandy back in cherry season, so that covered cherries and kirsch, and I had the cream, chocolate, just enough eggs (market tomorrow!). So here it is, the result of two hours, a lot of flipping back and forth in the Joy for base recipes, and some impatient refrigeration time.

The grand irony here, of course, is that I just used up all the cream in the cake, and now have nothing to put in my coffee.

Thursday, July 18, 2013

An Introduction to jQuery [notes]

F
inally getting on to actual jQuery! This about sums it up: "...we can use jQuery to perform its core functionality: getting some elements and doing something with them." All this reading is well and good, but I need to actually be querying and scripting in order to really understand. Therefore, I think it's time to go back to Codecademy for the jQuery lessons as soon as I read through jqfundmentatals.

The jQuery Fundamentals page links to the CSS2 spec on CSS Selectors, but there are some changes in the CSS3 spec. Memorizing the spec details isn't the most critical thing for me right now, and I have a pretty good grasp of combinators and pseudo-elements, IDs and classes.

The trouble with W3C specs, of course, is that user agent (UA, aka browsers) implementations may vary. Pseudo elements: I should try out :first-letter for drop-caps (though it wont help with my image drop-caps).

Q: So what exactly is a jQuery object? What does one do with it once it's created? Where is it stored and what is its lifespan? Backing up slightly, what does a regular old JS object look like?

A: As usual, I'm complicating things. Your generic JS object looks about like the code below, using literal notation to make the comparison easier. "All objects in JavaScript are descended from Object; all objects inherit methods and properties from Object.prototype, although they may be overridden" (MDN reference) "Objects are a collection of properties, and properties are associations between a name and a value"(more MDN). If a property is a function, then it is a method for that object. Pretty much everything in JS is actually an object. (see also: prototypes and classes)

var Bunny = {
ears : "long",
tail : "puffy",
hop : function (height) {
console.log("Hopped "+ height);
}};


The jQuery object is a JS object in that it stores elements and has methods, but it is an array-like object that just lists the DOM elements from the query. An array-like object has key:value pairs, but the key in this case seems to just be the index.

var a = $('div');
console.log(a);
/*returns from my blog homepage, more or less:
{
0: div#navbar.navbar section,
1: div#Navbar1.widget Navbar,
2: div#navbar-iframe-container,
3: div.body-fauxcolumns...}
*/


The jQuery object can be stored as a variable, or just called once and used, otherwise it disappears after use (?). I'd like to better understand memory and troubleshooting leaks (StackOverflow discussion). Basically, it looks like as long as there's a reference to an object, that object has memory allocated to it.

"Truthy" and "falsy" are a little ridiculous sounding... what's the difference between those and just true/false? Anything that evaluates to True is truthy, to False is falsy, but there are other possible evaluation results as well, like NaN, undefined, null, and any number of things – these are not specifically True or False, but they have trueness or falseness ascribed to them. It's descriptive instead of referring to the specific True/False booleans that you might return. This short article from 2011 explains it much better than I am (and I like his zebra).

Helpful tidbits:
  • $() is a function. Functions in JS are objects and have methods and properties. $() always returns an object, and objects are always truthy.
  • $( 'li' ).eq( 0 ).is( '.special' ); to find whether the selection using .eq() to select a specific single{ element matches the parameter in the .is() method (selector, DOM element, jQuery object, function); returns boolean.
  • Use getters and setters (methods) to do things with jQuery objects. Iteration over elements can be explicit (.each();)or implicit (.html();), and you can chain methods together on a single selection. 
  • Then we also have filtering.not(); .filter(); .has(); on selections, which are more or less "without," "within previous selection," and "contains," respectively. ...many more methods here in the top hit on Google for "jQuery cheatsheet" (includes CSS selectors!). I'm a visual person.
  • Plus, find other items/make other selections relative to a previous selection with things like .children();, .next();, .parent(); etc and add to existing selection with, by george, .add();
  • More on how to use jQuery in the context of your basic HTML page here from the jQuery folks.
That's probably enough for now. I have a bit more of the jqfundamentals page to read through, then back over to Codecademy, then moving on to "JavaScript: The Good Parts." Please comment if you notice something I've got wrong or that could use clarification.

Thursday, July 11, 2013

JavaScript Hoisting

J
ust in case there weren't enough clueless people on the web trying to figure this out, I thought I'd add a bit here in the interest of my figuring it out. In the process of processing JavaScript (Note to Self: see "JavaScript Interpreter"), things are sometimes executed in ways you might not be expecting. This can change the scope of some variables and functions and confuse the bejeezus out of anyone who isn't paying enough attention. Including me.

Some definitions:
  • A JS function expressionvar myCode = function(a, b) {stuff;};
  • A JS function declarationfunction myCode (a, b) {stuff;};
  • Hoisting: Pretty much what it sounds like, some things are lifted upwards and therefore are executed sooner in the script than where they were originally written. So, something that was written like so:
    function bunny (){
      rabbit();
      var carrot= 2;
    }

    Is actually executed like so:
    function bunny (){
      var carrot;  //declaration gets hoisted
      rabbit();
      carrot= 2;  //assignment stays put
    }
So, what does this have to do with scope? JS has function level scope. Blocks do not create a new scope (eg if statements do not create a new scope, only functions can. Compare/contrast with a C-based language). This is actually the most helpful block of text (from Ben Cherry) that I've read while pondering all this:
In JS, a name enters a scope in in one of four ways:
  1. Language-defined: All scopes are, by default, given the names this and arguments.
  2. Formal parameters: Functions can have named formal parameters, which are scoped to the body of that function.
  3. Function declarations: These are of the form function foo() {}.
  4. Variable declarations: These take the form var foo;.
Function declarations and variable declarations are always moved (“hoisted”) invisibly to the top of their containing scope by the JavaScript interpreter. Function parameters and language-defined names are, obviously, already there. [names are also resolved in this order] [emphasis mine]

When to use what: If you're aware of hoisting and how things will execute, then use whatever floats your boat, even intentionally use hoisting to get your function declaration moved up. Because a function declaration is all declaration, not declaration plus assignment as in a function expression, the entire function gets hoisted at once. A function expression only has the "var blah;" hoisted, leaving the actual function body (assignment expression) behind. (see also Angus Croll on function declarations/expressions. The fifth time I came back to that page I got the right quiz answers (and not just from memorizing them)).

How functions execute with hoisting when a script runs (examples taken from my hangout on air with JBeach):
Written like so:
(function () {
  a = grapefruit;
  b = applesauce;

  function grapefruit () {  //function declaration
  return 'citrus in your eye';
  };
  var applesauce = function () {  //function expression
  return 'goodness';
  };
}());

Executed like so:
(function () {
  function grapefruit () {  //function declaration hoisted
  return 'citrus in your eye';
  };
  var applesauce; //function expression declaration (?) hoisted
  a = grapefruit;
  b = applesauce;

  applesauce = function () {  //function expression
  return 'goodness';
  };
}()); // returns "citrus in your eye" for a and "undefined" for b.


I think I've got the concept, even if I haven't quite got the details of how it runs (slight lack of applied JS knowledge here, but working on that).

There was also mention of NFEs and IIFEs somewhere along the way here. NFEs are nicer than anonymous functions should you need to track one through a tangle of code. IIFEs are somewhat also known as Self-Executing Anonymous Functions, but with some nuance. An IIFE does invoke itself, can be anonymous or named, and can be self-executing.
  • Named Function Expression (NFE): var myFunc = function myFunc (){code here}
  • Immediately Invoked Function Expression (IIFE): (function myFunc (){code here}());

Disclaimer: For goodness' sake don't take my word for any/all of this if you've just stumbled across my blog. I'm just learning and these posts are essentially my notes. Please do read the articles I've linked to, read as much as you can, experiment, and figure it all out for yourself, too.

And if I've got something not quite right or downright wrong, please leave a comment. Thank you...

Wednesday, July 3, 2013

Basic notes on JavaScript

bout a year ago I spent a good chunk of time obsessing over Codecademy lessons and my "streak." Despite the headache I got from figuring out the math on a couple of loops, I really enjoyed JS as a language and am pleased to say I can still just write out a loop (at least for something simple) on demand. I stopped poking at their lessons just because I wanted to move on to some other subjects and work on live projects, but I would still like to finish up at some point. I've certainly learned that everyone has a different style and that syntax/best practices change and vary continuously.

Just did a little brushing up on JavaScript generally going through this JS basics page, then moseying over the Mozilla Developer Network (MDN) pages for further reading. I also have JavaScript: The Good Parts on hand to chug my way through, though I think that may be ongoing and involve more practice/ trying things out, too.
  • Use a function expression (var myCode = function(a, b) {stuff;};) rather than a function declaration (function myCode (a, b) {stuff;};). Finally got a good explanation for this here: "To quote Ben Cherry’s excellent article: 'Function declarations and function variables are always moved ("hoisted") to the top of their JavaScript scope by the JavaScript interpreter.'"
  • Consider scope! Variables declared without var are global, so (almost) always use var.
  • Hooray for OOP. I do like putting things in boxes and generally tidying up.
  • Object literal syntax: var thingy = {property1: 'value', property2: 'value';};  Point: if value is a function (rather than a primitive?), then the property is a method
  • Dot notation: objectname.propertyname
  • Bracket notation: objectname['propertyname']
  • While I can handle this, I don't particularly like this.
  • Ternary operators, shorthand for if/else: var status = ( a === 'aaaa' ) ? 'Panic' : 'Calm'; (had a hard time coming up with a neutral for this one. Essentially: For status, if value of a is panicked screaming, assign value of "Panic" to status. Otherwise, assign value "Calm.")(Personally I much prefer "Don't Panic" to "Keep Calm and Carry On," particular since the latter has been so overused lately)
  • Further reading on JS overview here was very helpful for just clarifying where it stands in relation to Java and ECMAScript, plus some basic properties. Once I found MDN, I abandoned old W3Schools. 
  • I need a better understanding of how code executes. Closures? Hoisting? ack.
  • So, scope? 
Things read: 
& all the links at the bottom of the JS Basics page.
This bit on JS closures (still not sure I understand).
And "If Hemingway Wrote JavaScript," which is amusing even if you don't know anything about code.

Thursday, June 20, 2013

My Dad Thinks Git is Just an Expletive

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

Wednesday, June 19, 2013

Drupal 8: Some things learned

J
ust a quick recap on my last reroll. A wonderfully patient mentor and I spent far too many hours poking at the comments and working back through the entire reroll to figure out exactly what was up. In the end, my original question got answered and some further clues were found in the issue comments. And, I think I finally got the hang of Git/Git Tower (thanks to the commenter on my last post, too)! It felt really good to be flicking between branches and understanding what was where. I need to further define all the "R" things for myself, Rebase, Revert, Roll-back... Just to get things clear.
  • The first helpful thing was the discovery that I was rerolling from the wrong patch. #64 was the actual last successful patch, and #65 (which I had been working with) was just to correct a typo, but also introduced an unintentional error, which no one noticed until #81 posted an interdiff. Note to self: also be sure to add an interdiff when needed and other helpful things as YesCT suggested like links to instructions and better notes on exactly what I did. 
  • One helpful mentor also pointed out that patches/interdiffs could be applied in reverse with curl https://...blah.patch | git apply -R
  • It's also worth remembering to diff a rebased branch against your HEAD branch so you don't wind up with a diff file that includes all the commits between when you started your working branch and the current update of origin/8.x. If that makes sense. I wound up with a very clogged diff by leaving a branch a little too long.
  • Glancing through the interdiff between #64 and #65 added in #81 helped me find the typo in question and then simply modify that file and run the diff. 
  • The biggest problem, and my original question for office hours, was where to put the contents of a test file that had been wiped from 8.x in the intervening year. Eventually we wound up putting that chunk of the patch in a deeper testing directory, but I never would have known where to add it on my own. 
  • The method my mentor used to find that test file I think involved searching for other pieces of the previous, now absent test file, where I had just been searching for the parts of the test file affected by this patch. Still not super confident about this grepping business and I feel like I've heard it belittled somewhere as one of those things newbies abuse/misuse. Could be wrong.
  • Apart from that, the rerolling instructions were pretty spot on. There was a question of branching, and I think everyone just has different styles with regard to pulling down the most recent commits of 8.x and then creating a new branch for the issue you're working on, plus then a temporary testbranch to test the new patch on. 
I'm mostly not tagging mentors here so as not to be a bother/presumptuous/something, but I continue to be grateful for their patience and helpfulness and willingness to spend time bringing new people into the fold. ... resisting the urge to start singing Guys and Dolls here, though I once played one of the Mission Band members on stage.

Now moving on to a JS issue, and first spending some time brushing up my skills there thanks to some prescribed reading. I'm always torn about whether I'd prefer to read tech books on the computer or in print. Staring at the screen for ages gets to me, but a print book is too disconnected from the associated topics (and less searchable). I'll just have to take regular breaks to stare at my blooming sugar snap peas instead!