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.

CSS layouts are tough...I don't care who you are!

Floats and clearfixing are just hard concepts to grasp, and building layouts in CSS the proper way is no small feat. Come to this evening workshop and learn to create your own responsive layouts. Where and when, you ask?

August 21, 7-9pm at New Work City

Use the code "salmon" for $25 off.

Register here

Let’s appreciate how great Find My iPhone and NYC cabbies are – phone returned within a day or so. And this was a successful reddit post! Fun stuff.

That’s right, WordCamps…plural! I will be presenting at both the New York City and Montreal WordCamps in August. And what will I talking about? Read on, my friend.

Freelancing: Real Talk (NYC, August 2-3)

Description:

How much do you charge? How do you price? How long does it take you to make a custom site? What do your proposals look like? And the impostor syndrome… you too?! These topics have been in a black box for too long – let’s open it up and share what we do. This session is a panel of 3-4 full time freelancers who will be completely transparent about their businesses. We’ll hit on a few topics, then open it up for Q&A.

My motive:

Freelancing is friggin’ hard. Recently there has been a wonderful trend in transparency around freelance practices, and I want to contribute! I was thinking about just presenting my own practice, but I’ve realized how important it is to not be glued to any specific process – it varies so much from client to client, and freelancer to freelancer (even though I don’t like that word). So, why not get a few other voices in there? My fellow panelists will be Tricia Okin, Melissa Hsiung, and Ben Freda.
 

Sassy WordPress (Montreal, August 16-17)

Description:

You’ve been meaning to start using Sass in your projects, right? But it looks hard…is it really worth figuring out? Yes, yes it is! In this talk, we will cover Sass basics like structuring projects, mixins, variables, and using extensions like Bourbon and Compass. We will then go over how to start using Sass in your own themes as well as touch on a few Sass-ready starter themes.

My motive:

I wanted to present a more technical topic for this one. And Sass is the bee’s knee’s. But…even though there is such a great community around Sass, there is a pretty high barrier to entry with its command line-y nature. I’ve talked to a few fellow WordPress developers who haven’t made the jump yet – and I say, why the hell not?! This talk is aimed at convincing those folks to spend a weekend and change their ways.

Anyhow, if you are at one or both of the above, come say hi! And Montreal lodging and meal recommendations welcome.