I gave a talk at WordCamp Montreal last fall called "Sassy WordPress":

I'd explain a few things differently now (which I will be June 16th at the NYC WordPress Meetup, actually). Everything goes from "do this" to "don't do this" pretty quickly, and you learn a lot in six months. Anyhow, here are some updates and an opinionated take on the word "module".

For those unfamiliar, the Pastry Box Project is a curated collection of thoughts and articles from anyone who works with the web. I wrote an article about cocktails and websites, i.e. my two favorite things, and it was published!

Take a read, then go get yourself a tasty beverage.

At An Event Apart last week, one speaker asked, “How many of you refer to yourselves as designers? … Developers? … Or maybe you design and develop…so…unicorn?”. The latter had the most hands, along with a few modest chuckles.

Let’s take a step back here. Because there is no better way to describe our set of skills, we have a roomful of people (myself included) identifying with a mythical beast that does not exist.

In early 2012, Sacha Greif wrote about unicorns. He described them as:

… a designer who can come up with your identity, design your site, create UIs with great user experience for your web and mobile apps, and on top of that code his or her work in HTML/CSS (and why not throw JavaScript in the mix!).

This skill set is not so uncommon anymore. Sure, in all likelihood these individuals are happily employed or working for themselves, but they certainly exist, and the “unicorn” metaphor no longer applies (and arguably didn't before, I think bluefin tuna is more accurate).

This week, I had a guest post published on CSS-Tricks. You should read it.

It kinda blew up. Well, definitely blew up. What started as legitimate comment thread on the post turned quite sour when the article was shared on r/programming:

Yes, that would be me. I failed FizzBuzz in a job interview and I wrote about it. Whoever he is, “jm_” got a lot of karma for that one. To clarify, that’s Reddit karma, not the nice kind of karma. There’s nothing nice in that thread, and most of that crowd completely missed the point of the article anyway.

But hey, these are bullies*! And a response that huge is actually awesome – there’s a conversation to be had, and the feedback from the audience I care about has been fantastic. Stay tuned.

* The article was also posted on r/webdev and r/web_design – much better conversations over there, and good (I think heavily moderated) discussion on Hacker News.

Two CSS properties walk into a bar. A barstool in a completely different bar falls over.

— Thomas Fuchs (@thomasfuchs) July 28, 2014

I mention this tweet at least three times a week (both while teaching CSS and in general conversation). Now you will too!

I found the Twig documentation for using key value pairs from PHP arrays a little sparse, so thought I'd elaborate.

The Scenario

I'm working on a Timber site (redoing this one, actually!) and had a bunch of redundant markup for a list of social links in the footer. Here's the markup for one list item (I'm using grunt-svgstore for svg sprites - it's fun, more here):

<!-- In footer.twig -->

<li>
    <a href="http://twitter.com/laras126" target="blank">
        <svg viewBox="0 0 100 100" class="icon icon-twitter">
            <use xlink:href="#icon-twitter"></use>
        </svg>
    </a>
</li>

That's pretty gross to write four or five times when you are only changing the URL and part of the class names. So, in the spirit of DRY and making my life more difficult, I wanted to figure out abstracting those values into a PHP array to pass to the Twig file instead of writing everything over and over.

The Solution

In the add_to_context() function in your theme's functions.php (and equivalent in other Twig projects), I created a simple array of strings to pass into the site-wide $context variable:

// In functions.php

function add_to_context($context) {
    
    // My array
    $social = array(
            'twitter' => 'http://twitter.com/laras126',
            'linkedin' => 'http://www.linkedin.com/in/notlaura/',
            'github' => 'http://github.com/laras126'
        );
    
    // Add social array to site context
    $context['social'] = $social;
        
    // ... probably more $context here (e.g. sidebars, menus, etc)

    // Essential (and included in Timber starter theme)
    $context['site'] = $this;
    return $context;
}

Now that content is available on any page in the site, and I'll have that in the footer is on every page so it's okay. If I only had this on pages for example, I would add the context within the page.php template. You want to only use global context when something really is on every view of the site.

I'm excited to officially announce the launch of MTNmeister.com. It was really fun to build, thanks to my new favorite pair of things in the world: Timber with Advanced Custom Fields. I'd like to share some highlights of my process, and maybe even convince you to try out Timber on your next project.

Timber: Twig + WordPress

Timber is a library for WordPress that allows you to separate template logic from presentation with object-oriented templates with the Twig PHP template engine (very similar to Django templating). A quick example from Timber's docs:

// Ew PHP

$thumb_id = get_post_thumbnail_id($post->ID); 
$url = wp_get_attachment_url($thumb_id); 
<img src="<?php echo $url; ?>" alt="Thumbnail for <?php echo $post->post_title; ?>" />

// Wow, wow, Timber

<img src="{{post.thumbnail.src}}" alt="Thumbnail for Timber" />

I can't speak for everyone, but the WordPress loop drives me a little crazy sometimes. Mixing PHP logic and variable definitions with my template markup is really distracting, and I hate worrying about opening, closing, and resetting the loop. I've had some experience working in Django and Rails projects where templating was a breeze: I didn't have to worry about getting or defining data within my markup, all of that happens in a separate part of the application. The data is managed and passed to the template (a.k.a. the view) from a different part of the application (a.k.a. controller), so that in my HTML I can focus on just that, my HTML. In Timber, the data management happens in the regular WordPress PHP theme files, and the markup in a corresponding Twig template.

I’m into skiing, and it’s time for a gear upgrade. Courtesy my brother at MTNmeister, I’m getting custom skis from Parlor Skis in Boston, and got to design the graphics myself – how cute are these?

And here they are in Alta (took a very nice, unplugged vacation for myself):

I’ve been working my tail off:

• Simple Sassy Starter
• MTNmeister WP site (created with Timber)
• DiJiFi site redesign (also with Timber)
• Angular Wireframing Kit

Many a blog posts about these in the icebox – coming soon-ish!

The words were all there when you talked about the topic in conversation yesterday, but when it comes to actually writing the post…impossible.

But wait, that’s just it! Record yourself talking about it.

I spend roughly 23% of my life walking (that’s an exaggeration, but I do walk a lot). Why not write a blog post while walking? Everyone is talking to themselves on headphones anyway, so for all intents and purposes I am having a phone conversation, not talking to myself about WordPress development.

Phones are perfect for this – good ‘ol Siri becomes useful at long last! Open up Evernote or the Notes app, click the microphone on the keyboard, start talking, and watch as your blog post magically writes itself. This not only gets over the blank screen phenomenon, it keeps the tone natural and conversational. And when you sit down to actually write the post, you have a bunch of transcribed content to work from.

This brilliance comes from the book Nicely Said: Writing for the Web with Style and Purpose by Kate Keifer Lee and Nicole Fenton. I definitely recommend grabbing a copy – they break down the writing process in very plain language, and touch on lots of nuances specific to the web.

So, if you see me walking and talking…now you know my secret.

This post was originally going to be a summary of themes from Artifact Conf but, inspired by Jeremy Keith's presentation, I got preoccupied with progressive enhancement. I also wanted to make this picture of cookies:

Progressive...what?

Pre-Artifact Conf, I was under the impression that progressive enhancement was something very JavaScript engineer-y, and not so relevant to my work. Not the case, it's much more a mindset than a particular development technique.

In a nutshell, progressive enhancement is building "content out", separating the structure of a website (HTML) from it's presentation and behavior (CSS and JS). Content should be available regardless of the capabilities of the device, and should not rely on styling or scripting to function at a base level.

"CSS with Superpowers"

Imagine not having to write .main-nav ul li 25 times when styling your WordPress menu, and no more copy/pasting hex codes just to get a slightly darker color. The things on your CSS wishlist, Sass actually does. Need more convincing? Read this.

But maybe you don't feel like spending an entire weekend pounding your head against your laptop, figuring out how to get set up. Come to this evening workshop and we'll walk through it all, step by step. You'll have Sass up and running in your projects by the end of the night!

All too often, someone new to the tech world sees coding as some kind of magic language we coders are born with. When you see a programmer slapping away at the keyboard, it’s no wonder!

But it’s not magic. Really.

Coding is not like this (full gif here).

This morning I read a great article, What “coder” means and why it’s bad, by Dave Winer. He says:

If you watched a programmer doing his or her work, you might not see much happening. Most of what we do is intellectual, and isn’t visible. It’s thinking work. Reading. Learning. Listening.

Coding is about having moments on your own, incredibly frustrated, making mistakes. You’ll spend three hours on one problem, then finally figure it out and either feel like a genius for a few seconds, or realize you were working in the wrong file. But those are not wasted hours. Throughout that problem solving process, you’ve learned 18 other things that will help you solve another problem in future.

Some advice

My advice to newbies is that, when you hear scary jargon, go into sponge mode and inventory it for later. As a teacher I’ve been successful when, three months after we’ve worked together, you encounter a problem and think:

“Oh yeah, that girl, Lara, mentioned something that helps minify CSS. I had no idea what she was talking about, but I think it started with a G.”

So you do this:

And if you keep at it, you get this crazy faith that you can do anything, you just have to figure it out.

Ah, this morning has been one of those “refine your build process and not actually work on anything” mornings. One important improvement, however, was excluding those .sass-cache files from the Sublime search.

Isn’t it the worst when you Cmd+T to search for _base.scss and get a million .sass-cache/12783uqhwlkaksjd/_base.scssc‘s? Yes, it is!

Add this to Sublime > Preferences > Settings – User to get rid of those and some others:

"folder_exclude_patterns": [".svn", ".git", ".hg", "CVS", ".sass-cache", "node_modules"]

Done! Don’t your eyes feel better now?

Thanks to Eric Binnion for the tip.

“Just update your ruby gems, generate a new SSH key, and run a git rebase…”

…

I don’t envy those just entering the field of web development. In addition to learning the fundamentals, there’s an expectation to be proficient in an increasingly exhausting laundry list of buzzwords and technologies.

So think twice before suggesting someone “just” [insert any task here]. You just might make them feel like an idiot.

From the ever-wise Brad Frost on the Pastry Box.