stephen.news

hypertext, words and more

Tutorial

  • I always look forward to Sohla El-Waylly’s tips on cooking. She is a master in culinary arts. She’s got legendary wit and has great perspectives on cooking. Sohla studied at CIA, previously had a show on Bon Appetite, went solo with her own show and now has a show on NYTimes Cooking.

    To be brief, she’s incredible. Buy her books.

    This all brings me to her Cooking 101 segment on NYTimes Cooking, on how to make perfect eggs every time. Eggs are the building block for so many recipes. It’s a unique protein that has been used in cooking for a millennia. To achieve perfection here requires some knowledge of chemistry, tame temperature on the skillet and understanding timing. All of these skills can inform your cooking in other recipes since eggs are such a crucial component in many dishes.

  • In September of 1982, David Ogilvy shared the following:

    1. Read the Roman-Raphaelson book on writing.* Read it three times.
    2. Write the way you talk. Naturally.
    3. Use short words, short sentences and short paragraphs.
    4. Never use jargon words like reconceptualize, demassification, attitudinally, judgmentally. They are hallmarks of a pretentious ass.
    5. Never write more than two pages on any subject.
    6. Check your quotations.
    7. Never send a letter or a memo on the day you write it. Read it aloud the next morning —and then edit it.
    8. If it is something important, get a colleague to improve it.
    9. Before you send your letter or memo, make sure it is crystal clear what you want the recipient to do.
    10. If you want ACTION, don’t write. Go and tell the guy what you want.

    *Writing That Works., HARPER & ROW,

  • This is one of those git config things you set once and forget years later when you setup a new machine. How did we get here? You can git push expecting to fly up to the remote repository right?

    fatal: The current branch feature-1234 has no upstream branch.
    To push the current branch and set the remote as upstream, use
    
        git push --set-upstream origin feature-1234
    
    To have this happen automatically for branches without a tracking
    upstream, see 'push.autoSetupRemote' in 'git help config'.

    To get rid of this message forever and prevent git from gatekeeping you just run this:

    git config --global push.default current

    This will set your git config to only push your current branch when running git push. Enjoy never having to worry about this again!

  • The other day, a friend of mine asked me if I could help design a fun little website that emulate's macOS. I thought it would be a fun project, and looked around for some design resources to get a head start. Low-and-behold, I came across this amazing gem (get it?! 🤣):

    If you're not familiar with Sketch, it's a design and prototyping tool. Totally worth checking out their free trial. Sketch makes a good habit of releasing these, but for some reason the macOS UI Library didn't get any notoriety on their blog.

    At any rate, it's a badass resource for rapid prototyping. You can install the maOS UI Library here or click on the image below.

    A screenshot of the Sketch website showcasing the macOS UI Library

    If you don't have Sketch installed, clicking on the big orange button to install won't do anything. If you do have it installed, it will open Sketch and prompt you for installation. At which it will be available in your Sketch Preferences.

    Sketch app preferences on the library tab

    Once it's here, you're done! The biggest upside to this Library is it works with Sketch Runner out of the box (a must have for you Sketch users out there). You can quickly plop any macOS component by pressing command-apostrophe (⌘ ') at any time and it should bring up the Sketch runner dialog. Search for a component and:

    Sketch Runner dialog search query

    Press enter, and drop the component onto your artboard.

    Sketch App running with a macOS window component

    Congratulations! You’ve're ready to start prototyping! Enjoy! 🎉

  • We’re going to setup a remote server (say hosted on DigitalOcean), with Trellis’ automated deployments. It’s magical. Oddly enough, as of 2018, this guide is still pretty much up date and relatively unchanged.

    We started by getting our local environment setup but now we need to get our production environment setup so we can get deploys going from our local machine. With Trellis, provisioning and deploying occurs from the trellis directory.

    Remember our structure?

    example.com/      # → Root folder for your project
    ├── trellis/      # → You'ver clone of Trellis
    └── site/         # → A Bedrock-based WordPress site
        └── web/
            ├── app/  # → WordPress content directory (themes, plugins, etc.)
            └── wp/   # → WordPress core (don't touch!)
    

    1. Copy group_vars

    Copy your wordpress_sites from your working development site in group_vars/development/wordpress_sites.yml to the production environment group_vars/production/wordpress_sites.yml.

    Modify your site and add the necessary settings for remote servers:

    • repo – URL of the Git repo of your Bedrock project (required)
    • repo_subtree_path – relative path to your Bedrock/WP directory in your repo (above) if its not the root (like site/ in roots-example-project)
    • branch – the branch name, tag name, or commit SHA1 you want to deploy (default: master)
    • env – environment variables (very important)
      • auth_key – Generate (required in vault.yml)
      • secure_auth_key – Generate (required in vault.yml)
      • logged_in_key – Generate (required in vault.yml)
      • nonce_key – Generate (required in vault.yml)
      • auth_salt – Generate (required in vault.yml)
      • secure_auth_salt – Generate (required in vault.yml)
      • logged_in_salt – Generate (required in vault.yml)
      • nonce_salt – Generate (required in vault.yml)

    You’ve’ll want to make sure that you change all instances of example.local (in your production vars) and switch it to example.com Otherwise you may get some errors.

    2. Setup Hosts and Users

    Create a Digitalocean droplet configured for Ubuntu 16.04.1 in whatever size you may need.

    screen-shot-2016-10-09-at-4-55-18-pm

    Once you get your droplet setup, you’ll need to SSH into the server to change the default password DigitalOcean emails you.

    Next, add your server IP (from the droplet) to your hosts/<environment>. Specify public SSH keys for users in group_vars/all/users.yml so Trellis can access your droplet. See the Trellis’ SSH Keys docs for more information.

    3. Provision

    Run ansible-playbook server.yml -e env=<environment>. and Hopefully you get a green light and no errors. If you do get errors, troubleshoot and try again. Trellis has verbose warnings and errors so they don’t leave you high and dry.

    4. Deploying

    To deploy, ensure that your site folder is in a public repository on Github.

    Next, run ssh-add -K, this will add you SSH key to your shh-agent (if you’ve created one, also it’s good practice to add your keys to your Github account). Then, from the Trellis directory, run ./bin/deploy.sh production example.com and watch as your terminal deploys your most recent commit.

    Previous: The WordPress Roots Stack
  • This post was previously updated on November 01, 2018.

    We all have to deal with it at some point.

    The Flash Of Unstyled Content. Yuck. What a name. According to TechRepublic it has its origins documented as far back as 2001. There are a wide range of fixes. This fix however is super duper easy to implement and it’s a vanilla solution.

    First, add a class to your html document

    <html class="no-js">...

    Then put this little guy at the very-bottom of your scripts file:

    (function(H){H.className=H.className.replace(/\bno-js\b/,'js')})(document.documentElement)

    And finally add this to your CSS, render content invisible until it loads:

    visibility: hidden;
     opacity: 0;
    }
    
    .js {
     visibility: visible;
     opacity: 1;
    }

    The obvious downside to this is pretty awful. If a user comes along that doesn’t have JS enabled, your page loads but it isn’t visible. It really comes down to a pros and cons list for your users. If you’re Facebook or Google, you probably have this baked into every single product because every single product uses JS in some small or large way.

    I’m not saying this is the best solution ever — I’m just saying it’s the most effective solution we have right now. This method is a Frankenstein version of Paul Irish’s approach. Which if you’re going to use this FOUC solution you better be using Irish’s DOM Based JS Routing. Then you can really iron down when and where you want JS to fire.

    UPDATE: Thanks to Bert, who reminded me that I haven’t written about FOUC solutions in some time, and happy to revisit the subject.

    I do have a newly updated solution. It’s not much different than above but it’s more performant.

    We continue to re-use Paul Irish’s famous markup from 2009, with only marginal updates. Such as, the no-js class on the document, and script in the <head> (not in the body, nor in the footer, this needs to be parsed right-away):

    <html class="no-js">
    <head>
      <script>(function(H){H.className=H.className.replace(/\bno-js\b/,'js')})(document.documentElement)</script>
    ...

    Next, we write CSS for the no-js state:

    .no-js {
     visibility: hidden;
     opacity: 0;
    }
    
    .js {
     visibility: visible;
     opacity: 1;
    }

    And Bob’s your uncle! Same as before, but only slightly revised for performance. Enjoy!

    UPDATE: There’s more than one way to skin a cat as they say. Many thanks to elektrotype, who came up with this brilliant solution, which works great for no-js users. In-short, they won’t see a white-screen if they don’t have JS enabled: