Local/Drupal: complete!

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

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

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

.ignore: Setting Up Local Drupal

y blog here is just going to be very dry for a little while as personal notes/documentation, apologies for that. Once I get some things set up I can filter tags/categories and have sections for tailored subscription... but right now I just need to set up a local install of Drupal 8.x (d8). There are instructions here on Drupal.org on setting up a developer environment (dev env), but I needed a few more steps along the way.

I would have very little idea what I was doing, even with all the documentation, if not for the Drupal Core Mentoring Office Hours, and particularly the very patient help of YesCT on the #Drupal IRC. I will definitely be back for the next office hours session I can get to. And... thank goodness "there are no stupid questions," 'cause boy are some of mine... non-stupid.

1. The above link includes some requirements for the dev env, but I needed to check a few background items, like PHP, to make sure they also fit the requirements for a Drupal install. Step one, actually, was making sure I had accounts set up on Drupal.org and DrupalCoreMentoring.org. I was also pointed at issues for the d8 dev env here, just in case anything listed there would trip me up along the way. 
2. • The one thing from the dev env list I was obviously missing was Drush, which isn't immediately necessary, but I figured I'd get it out of the way. The best way to install for d8 seems to be a git clone from the Drush project page, then following the instructions in the ReadMe to check that it's "using the same PHP as the web user." Question: Is that PHP version, settings, .ini file? 
   • It looks like typing "php -v" in the shell gives me info on whether it's the CLI variety or not (I'm not going to fuss about understanding that completely right now). 
   • Finally found more explicit instructions on command line install of Drush here. The video is the ultimate answer. 
   • However, got this error: The following restricted PHP modes have non-empty values: [error] magic_quotes_gpc. This configuration is incompatible with drush. Please check your configuration settings in or in your drush.ini file; see examples/example.drush.ini for details. Argh. [turns out there's an easy way to turn magic quotes off. oh well]
   • Ok, so then I go to example.drush.ini in the drush install directory and follow those instructions... Turns out my local PHP is out of date, hence magic quotes (deprecated a while ago). Installing new PHP and god-help-me configuring it. 
   • And back to the Drush ReadMe, I added an export PATH to my bash_profile specifying PHP 5.4, although MAMP is on 5.4.10 and command line PHP is 5.4.12... CL PHP ini file is at /usr/local/php5/lib/php.ini, MAMP file is at /Applications/MAMP/bin/php/php5.4.10/conf/php.ini
   • I want matching memory_limit 512M and time limit 120 seconds in both files, I think. Not sure about what this step is referring to, so hoping it's these two files, not that I should have just one .ini file. Changed memory limits to match. Question: where is the time limit? script execution or input?
3. Not a clue where I left off... I think the next step is getting my Drupal from version control via git clone.  This really ought to be easy... downloaded just fine.
4. Then adding the Git Deploy module. hm. Doesn't appear to be released for 8.x. Question: Do I need Git Deploy for patch work? 
5. Checking back on the dev env page for configuration and other steps... Just need to install? Will have to do that tomorrow.
6. Then that should probably do it, and I'll leave the rest for tomorrow. I think the next steps are finding a project, and I shouldn't need to mess much with this install until I have something to test. 

Overloaded - Journaling some progress

his will be a less coherent post than usual, just because I'm in process a lot sooner than I thought I'd be. Going back to my Grand List, the intent was that I would research several different CMS platforms (Drupal, WordPress, Joomla etc) before choosing one, or even deciding that a full fledged CMS was too heavy for my purposes. In an ideal world (I've been using "ideal" more lately. hm. Self-awareness?), I'd probably design my own database and create the whole thing from scratch. Since that would require being a db architect, it would take quite a lot longer than winging it in a CMS.

More recently, I had decided to go with WordPress, simply because I have some experience with it already and would be building on that, rather than learning yet another new skill set. I had been thinking that Drupal was the more sophisticated option, and that I could learn yet more awesome new things by installing it, but second-guessed myself into a corner. Really, WordPress has given me some pretty big headaches over the last couple of years.

This past weekend was the National Day of Civic Hacking. Within a span of four days, my whole outlook and project list merged onto a gigantic, fast-moving highway of projects, people, inspiration and busy, busy schedules. Now I find myself wrapped up in Code for DC, a project to map migration and DC school boundaries, hopefully getting further involved with Girl Develop It, and throwing myself at Drupal Core.

The big problem here is that every single thing I just listed has not just a physical group and projects, but Hackpads, Trello boards, Google Groups, Meetups, Twitter accounts, GitHub accounts, CKAN site, IRC channels, calendars, forums, websites and good lord do I have a lot of tabs open. I think I linked up with everyone from the weekend, signed up for everything I needed to... at this point I'm just hoping that anything important will ping a notification to my email, otherwise it'll be lost in the aether.

But back to Drupal. Let's just take a look at where I'm at, mostly for personal reference. I signed onto Drupal.org, and to DrupalMentoring.org. Joined the DC Drupalers meetup. Have [just] four IRC channels up in preparation for the Office Hours later tonight from the mentoring people (who I hope will be able to give me dummy points on installation and patches and link me up with an appropriately straightforward project [open issue]).

Some questions, having just read the Drupal overview here (front-end installation stuff) and nearly every other page I could find after that:

• Why XHTML?
• What exactly happens in terms of nodes, paths, blocks, users when a page is requested? How does the request play out?
• Wait, so bootstrap, which isn't bootstrapping, or Bootstrap? argh. But sort of like the WordPress Loop, yes?
• I've really got to learn PHP/more PHP. What are alternatives to PHP? How else can web pages be dynamic?
• So there are issues listed on Drupal.org and DrupalMentoring.org... how are they related? Same thing, different interface? (oh, I see, they're linked and the Drupal.org is the main page for info comments etc)

... a bit brain-dead right now, which is unhelpful given that the mentoring office hours are in... an hour!

How My Time Vanishes

t's not that I'm unaware there are other things I should be doing, it's just that I'd rather be doing something with immediate, tangible results. Presumably this has been part of the appeal of manual labor for this generation that feels stuck and, well, flail-y. So instead of working toward long-term goals, I often find myself taking solace in some small projects around the house and yard.

You're familiar by now with my gardening tribulations, and some of my more notable baking incidents. I also sew, knit, crochet, and macrame, not to mention bind custom books, rewire light fixtures, weave beadwork, and probably a bunch of other stuff I'm forgetting right now. Sometime last year (!) I picked up a pile of various twines from the hardware store to make a few more plant hangers with. After staring at my old project-to-do list for all that time I finally got fed up with myself and have started crossing things off. (First to be crossed-off was the dress I bought at the vintage shop and modified to fit and bit a little more modern (ruffles had to go)).

The next easiest project was the following collection of macrame plant hangers. When my apartments in Vermont and Arlandria lacked window ledges or sufficient sunlight, I started hanging plants in front of every decent sun-source I could. Phototropic, indeed. Some of these are from years ago when I made my first batch. The more recent ones are more awesome, I think. They're labelled on mouseover...

	Next on my macrame list is a hammock. Anyone have a pattern for a two person cotton twine hammock? I only have a single person sized pattern, not confident about load-bearing capabilities if I double it...

ps. Don't question the table I used to lay these out. It was fast. ish.

The Art of French Baking: Strawberry Frangipane

he Art of French Baking, published by Phaidon, is a beautiful book. The covers are padded and sparkling white, the pages thick and smooth, the photographs well shot and printed, and any cookbook with bookmark ribbons gets a lot of points from me. However, the recipes seem to leave a little something to be desired.

I am an experienced baker. Not an expert, not experimental, and not a chemist, but my pie crusts are tender and flaky, my bread rises and my batters are light and fluffy. Therefore I was somewhat surprised when several recipes from this book did not come together or bake in the way I expected. The instructions are quite brief, which is fine if one already has some technique, but I repeatedly found myself with a dough that didn't hold together despite extra liquid, or choux puffs that simply wouldn't rise (I tried twice in one day), or worse, cookies that burned but didn't bake through.

So now I've determined that I'll just need to reinterpret and double check the recipe for logic before I start anything. Make sure the oven temperature doesn't seem oddly high, that the wet and dry proportions make sense and that I can adjust here and there. Or at least I can make the recipes with frosting and cover up all the little problems!

Today I needed to use up the last of a flat of strawberries from market, and the Strawberry Frangipane looked pretty easy. It's just egg yolks, sugar, ground almonds and strawberries. Nothing can go wrong! Well, nothing except my being short an egg. Sigh. So I just eased back on the other ingredients. The batter was thicker than I was expected and didn't exactly pour between the strawberries, but it did melt around them once in the oven. Then it was just a matter of keeping an eye on it until the top was the perfect shade of done... except when I cut into it, the inside was not at all done. Not even a little. Back into the oven it goes.

I'm fairly fed up at this point, having never had so much trouble with recipes before. Perhaps it's partially my fault, but with every recipe coming from the same book it seems unlikely that this is entirely on me. I really want to love The Art of French Baking, but it's not living up to my expectations. You all know what the lesson is here, right?

Here's a quick list of the things I've made from this book:

• Sweet orange croquettes- excellent
• Babas au rhum- pretty good, not as fluffy as I'd like.
• Pate a choux puffs with pastry creme- total fail, no puff to be had, more like cookies. I have done these successfully in the past with a Martha Stewart recipe!
• Petit fours with chocolate ganache and sprinkles- worked well in mini muffin tins
• Duchesse petits fours- Dough didn't even slightly hold together and overcooked too quickly
• Orange gateau, I think- I have a vague memory of using a pineapple, too. dunno.
• Sweet slices- basically sugar cookies, oven temp was also too high
• Strawberry Frangipane- Ha. Maybe once it's baked for three times the suggested time!

Book review: Gaining Ground by Forrest Pritchard

efore I begin my review of Gaining Ground, allow to me to make a quick disclaimer: I am not an objective reader. In fact, I have worked for Forrest at farm markets every weekend for over a year now, in rain, snow, wind, thunder and tourist season. Before Smith Meadows came into my life I was largely vegetarian in order to avoid sponsoring the horror stories I read about the papers and books like Omnivore's Dilemma and Deep Economy. Then, through a boyfriend's friend's sister's best friend I found Smith Meadows, the perfect local farm with all the practices and principles an idealist could hope for.

Forrest Pritchard is Smith Meadows' farmer, its steward and practically a part of the soil he has worked so hard to nourish from the sad state it was in after years of overuse. As it turns out, lush pasture is easily achieved through a combination of patience and well planned herd rotation, switching between cattle, pigs, chickens and sheep, letting each fertilize and refresh the soil in turn. "Easily," of course, is a relative term when one is reading about it all from a comfy chair with a nice cup of tea.

In truth, it took not only years of hard work but decades of failure for the Pritchard family farm to turn around and produce a profit (as well as valuable land, animals and a sterling example of good farming practices). Gaining Ground recounts the journey Forrest took his entire family on when he realized that farming might be more of a calling for him than teaching (though writing is clearly still in his repertoire). As a bit of a book connoisseur, I did note that the book itself has a good looking, glossy cover, the text is printed clearly on nice feeling paper and the photos are incredibly helpful in placing the reader right there on the farm.

Gaining Ground has a good flow that kept me impatient to turn the page for the next adventure or roadblock, even though I knew exactly how it turned out. Forrest's anecdotes are sometimes touching, often hilarious, and range from rampant hogs to very confused market customers to a couple of completely baffling exchanges with a butcher. Pedro the goat, for instance, accompanied by Travis the humming farmhand, has a highly amusing adventure with some marigolds, in true goat-style.

As somewhat of an insider, I also know that there is a lot left out of this 317 page book. There were more adventures with goats, some ducks, more about Nancy's pasta business, a food truck and many more humorous stories from market and the farm. One hopes there will be a second book in the works... I, for one, would have enjoyed the inclusion of Forrest's other writing, perhaps the poetry he mentions sending off to literary magazines early on. The book stands at the right length and breadth to be a reasonable and fun read (One of Publishers Weekly's top 10 summer reads in nonfiction), though the prose could have dug a little deeper into the emotional underpinnings here and there.

The other members of the family receive occasional mentions, but the elder Mr. Pritchard has a fair share of the spotlight as he does his best to support his harebrained son through the snafus and disappointments of starting his free-range, grass-fed meat business. Mr. Pritchard's declining health provides a backdrop that Forrest puts to use in framing the problems with the commercial food industry and how we think about food in terms of cost, taste and enjoyment. On the whole, Gaining Ground is a good story, not an essay on farming practices, and it is this difference that will help readers to understand on a personal level what it means to buy local and why they too should work to save the family farm.

I did have one customer at market ask if Gaining Ground was a collection of recipes from Smith Meadows Kitchen, and when I passed this along to Forrest he said, "Sure, it's a recipe book. There's a real important recipe in there, they'll just have to read all the way to the end."

Gaining Ground is available on Amazon.com, in hardcopy and Kindle editions, and on IndieBound, as well as at your friendly local DC farm markets listed here. If you bring your copy to Smith Meadows farm day on June 1, Forrest will be happy to sign it for you. He may even sign copies brought to the Arlington and Takoma Park markets where he usually can be found on weekends. I will be putting my signed review copy in the Little Free Library for which I am co-steward. Pass it on!

Web Design Process: Yet More Lists

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

Things I'd like from my site:

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

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

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

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

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

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

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

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

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

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

Sketchy resume design

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

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

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

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

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

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

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

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

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.