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

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.

Learning is easy, doing is difficult

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!

An Introduction to jQuery [notes]

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.

JavaScript Hoisting

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 expression: var myCode = function(a, b) {stuff;};
• A JS function declaration: function 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...

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: 

JQuery Fundamentals: JS Basics

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

An attempted re-roll and several more hurdles

ssignment the second! With the help of Git Tower to tidy up my git messes, it's time to try out a re-roll. Or at least, futzing around with a patch until it works. This one was assigned to me during the core mentoring office hours, which meant it was already rather late at night. I couldn't work on it for at least 10 hours, so inevitably someone else had a whack at it first. Not a problem, always good to get things done, and I kind of like the competitive aspect there.

However, the posted reroll failed the automated tests, and a subsequent comment indicated that a single element was missing from that reroll that had (presumably) been in the previous version. Hokay. So where does that leave me? If it's missing just one thing, that one thing can be inserted and then tested again, yes?

Problems: I need to make sure I'm testing accurately, refreshing my entire local repo every time. I need to figure out exactly what is missing and where it goes. Update patch file. Test again. Upload. That seems easy, right? It's the technical details of how to do all that correctly and the first time that I get hung up on and unsure about. I need a lot of practice.

1. Actually, on this one, I'm going to take a close, side-by-side look at the two versions of the patch and see if I can isolate the missing bits, drop them in, and call it a day. This should also clue me a little more regarding patch structure. I get the concept and the diff and the +/-, but parsing all that together on read through will take some practice. Doing this manually seems to have worked, my patch applies.
2. Also going to try doing it this way, per berdir on IRC: "one trick would be to apply the previous patch over the current one with --reject, then the file should be added but all other changes would conflict and you can ignore them" 

And said patch passed tests and was reviewed affirmatively, so I guess it's ok. Frankly I'm amazed that things don't get broken more and that so many contributors are also patient mentors. Or my sample from the IRC is skewed, but I'm definitely grateful for that patience. 

Or rather, I'll try that second option as soon as I seriously sort out how to get my branches to work. Seems like changes I make on a checked out branch are still affecting my local head? That doesn't seem quite right. And meanwhile, 8.x doesn't seem to be working with MAMP anymore and I think that's enough for one night. Really looking forward to getting more experienced with all this.

Optional HTML, good idea?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Moving on, letting go

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

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

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

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

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

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

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

OWW: Tidying up

o, how about that acronym? It is sort of descriptive of how my brain gets to feeling after too many hours staring at the screen. Here's a post on some trouble-shooting of the last two posts, and tidying up any loose ends that I can.

First, the original list post was confused about what element tags to use for embedding HTML content. I started with embed because it sounded like what I wanted to do, but it's actually "for an external (typically non-HTML) application or interactive content." Then I found object, which "will either be treated as an image, as a nested browsing context, or as an external resource to be processed by a plugin." And finally iframe which I had really thought went the way of the dodo for some reason, and which "represents a nested browsing context." Sooo...

Second, hopefully related, the embedded HTML doesn't show up in Google Reader. By switching to object tags, I did get it to at least display alt text. Turns out this is indeed a security problem with RSS feeds.

However, problem B is that the entire embed shows up as an empty frame for at least one reader using (you guessed it) Internet Explorer (IE. Abbreviations will carry into future posts). I suspect this has something to do with cross-site restrictions/same origin policies, or possibly just content blocking. Looked up user agent switching and (yay) Chrome has a built in feature to switch user agents from the developer console. However, everything displayed just fine when I checked the blog through the IE emulators, so I dunno.

The original list has now been tidied up, streamlined, and the stray notes I had in there for my own benefit have been relegated to drafted blog posts. I probably shouldn't blow any time styling it, but it's tempting. I would at least like to standardise some nice classy, plain styling for future documentation purposes.

Also, since this entire blog ought to be transferred to my domain in the near future, I'm not sure how much will be lost in the translation, so I'm not futzing about style too much right now. I did settle on using courier bold to highlight code terms, but then discovered that the code element does the same thing, so will use that henceforth.

Oh yes, and I had intended to use some pre and code elements in my TodoList file, but they didn't display properly on the first two tries. Turns out the < and > are still interpreted as HTML, so substituting in "&lt" and "&gt" respectively was necessary. It's worth noting that all of my HTML/CSS coding is happening using only TextWrangler, having upgraded from TextEdit. Someday fancy software (especially for previewing work) would be nice, but right now I like this basic approach.

Phew. I like fixing all the little problems, but it can certainly get a bit tedious. All my librarian research skills sure are coming in handy!

Gitifying the OneWeekWebsiteList

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

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

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

Essential breakdown of Gitification of The List:

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

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

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

One Week Website

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

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

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

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

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

Technical Testing Tribulations

ay back in November I finally staked my claim on a corner of the internet by registering and hosting a website under my name. I had stalled for almost a full year, thinking there was too much I would want to research before pinning down a registrar/host. Turns out that was the easy part (once I realised I didn't need a slew of dedicated servers in the former Soviet Bloc).

After choosing DreamHost at the recommendation of a friend and a popular website (Lifehacker, who recently re-affirmed DreamHost's dominance), all I had to do was learn how to code an entire website. And not just any website, one that would display a photographic portfolio dynamically and interactively and [buzzword] and [so on]. Ok, so I haven't quite gotten to that part yet, but the site exists and is a decent placeholder.

The holdup is that I'm the sort of person who can't just throw up something pre-fabricated and call it a day, I have to learn how to code the entire thing myself, learn databases and cascading stylesheets, from scratch. Maybe once I've done that I could take an easier route, but without understanding the background it seems too much like cheating. Besides, most of the point was giving myself opportunity to learn, given that my photos probably aren't going to start flying off the shelves (there are some up, but they, too, are placeholders).

So in the meantime I've just been using the web export feature in Adobe Lightroom (a god-send for those of us who like cataloging, integration with other applications and services and powerful but simple tools). The problem I'm leading up to is that I'd like to stop hosting the photos I use in blog posts on Picasa and move them all over to a dedicated storage folder on my website. Heck, someday I should move this blog there, too.

The problem is that to use a photo in a post, I need to have a link to the .jpg file that will never change, or at least use a relative link to just "/kitten.jpg" rather than "http:// blah/folderA/section56/kitten.jpg" and so on. So that's one solution. But I also need the photo to link to a gallery view on my website, so that the clicker can browse through other photos from my blog, and also use spiffy navigation controls to browse by keyword or just mosey back through other parts of my portfolio.

I'm not going to list how much of that I have no idea how to accomplish, because it's too overwhelming. But, I've written an entire blogpost about it now, so that will hopefully motivate me.

Oh, and the reason there are random photos of pie here is because they're hosted on my website, just... not very sophisticatedly.