Workflow for the Wary – UXD 2014 – 1999

View Github Repository Open presentation in a new window

lyzadanger

See all presentation from lyzadanger

Workflow for the Wary – UXD 2014 – 1999

0 0

workflow-2014

Your Workflow, Sigh, Matters

On Github lyzadanger / workflow-2014

Workflow for the Wary

UXD 2014

Made by Lyza Danger Gardner / @lyzadanger

Hi

Lyza Danger Gardner (@lyzadanger)

Co-founder, CTO, Cloud Four

https://github.com/lyzadanger/workflow-2014

1999

I remember 1999.

I Broke up with Javascript

(We've since made up)
That year...
I committed a directory called
HTDOGS
to our CVS repository at work
That year, I also...

HTDOGS

A directory called HTDOGS. Why?

HTTP +

Dogs?
Whut?

HTDOGS

HTDOCS

(HTTP + DOCUMENTS)
What I was meant to name the directory...

Major screwup

Whoops.

This is not how I felt

The way I felt was the opposite of this

This is how I felt

Yes, more like this

CVS: Weird, brittle, Byzantine

CVS is weird and brittle enough on its own, and renaming committed directories infuriating and Byzantine.

But our workflow was confounding

But this was even further complicated by elements of our workflow that I didn't understand, and which scared me.

the mysterious temple of the sysadmin

I approached the desk of our arch-sysadmin, which was pretty much like approaching a mysterious temple.
"Excuse me...um?"
It was pretty much like this, from my perspective. Not a world I understood.

The frenzy that ensued felt about like DEFCON 2

And the frenzy that ensued was something like DEFCON 2

The experience left me wary

The experience left me scarred and timid, wary of what seemed like arcane rocket science.
My late-90s perspective on workflow was that it was for a rarified breed of super experts, completely out of my reach.

Time Passed

Back then

  • We, the engineers
  • Wrote code and markup
  • Carefully committed to CVS
  • Using commands from the sysadmins
  • And then...we were done?
We handed off our work and ran away.

We're on a web journey

Lots has happened since
Our roles evolved

The word developer entered our lexicon

Suddenly we had a new term to describe the breath of what we did. This feels so much more natural than "engineer", and it implies a subtly different and broader scope.

Functionality pushed toward the front end

Less separation of concerns

Web development has democratized. There are still large teams that have such clear distinctions, but, for the most part, there isn't such clear separation of concerns. We've become a tribe of generalists, responsible for ever-larger swaths of what we're building.

No longer can we throw everything over the wall

We're not able to throw everything over the wall or into the temple and forget about it.

Instead, we are increasingly expected to take charge

...of our workflow destiny

But...the wariness...the vagueness

There's still a residual wariness—in me, in the people around me—an awe or concern about the technical aspects, as well as a confusion about the high-level, abstract concepts involved, the vagueness of orchestrating workflows.

What is a "workflow" and why do I need one?

What kind of workflow am I talking about here?

A workflow involves components and processes

You Likely already have Existing Elements

  • Reusable structures and configuration
  • Consistent processes
  • Individual tools

Ideal Workflow

The orchestration of processes and tools that make things more consistent and less sucky —me

Consistent

Tasks and processes happen the same way. Across your team, across multiple teams, across environments. Less human error and more project stability.

Less Sucky

We get our jobs done quicker, more elegantly and without as much drudgery.

Orchestration and Coordination

It is a challenge of pulling things together, orchestrating and coordinating. And there are tools designed to help do just that.
The ideas and terminology can seem vague and abstract at first...
Because these tools coordinate other components, they may seem vague or abstract at first, and you may seem some vague and abstract terminology.

Orchestrating Components

  • Package management
  • Scaffold
  • Task runner, build
Each of these types of tools help you build a workflow.

Task Runner

Weird and Hard

"Weird and hard"

Grunt for People Who Think Things Like Grunt are Weird and Hard

by Chris Coyier

The Weird

What does it do?

The hard

Grunt is node!

Node is weird!

SASS is ruby!

That sounds hard!

Solving the "Hard"

The technical requirements may seem hazy

But you don't have to know the underlying technologies

Do you have five minutes?

Install Node!

Install the Node Package Manager (npm)

Install NPM!

Psych! NPM is already installed; it comes with node!

Install Grunt...well, sorta

This actually installs the grunt CLI, not grunt itself.

$ npm install -g grunt-cli

Bonus Distraction Slide!

Install Ruby and a Ruby Version Manager?

Possibly not...

$ \curl -sSL https://get.rvm.io | bash -s stable —ruby

One liner: Installs RVM, installs stable ruby

A recap: Once more, with feeling

Install node by clicking on a button Install the grunt cli: 
$ npm install -g grunt-cli
Install ruby via a ruby version manager if you need to: 
$ \curl -sSL https://get.rvm.io | bash -s stable —ruby

Once node and the grunt CLI are installed, you're already set up to consume many workflows.

That's super and all

But what does it do?

...Let's look at an example

It's great that we're set up to run tasks, but what can we do with this setup? We're technically set, but still in the abstract as far as what an orchestrated workflow can do for us.

Reveal.js

The example in front of us

The workflow for reveal.js

reveal.js / README.md

As an example, the grunt-based workflow for reveal.js

Working with reveal.js

  • Compile SASS for themes
  • Minify CSS
  • Clean up/check JavaScript (linting)
  • Build and package presentation as an archive
  • Run the presentation on a local web server
  • Run automated tests

The contributors to reveal.js defined grunt tasksto take care of all of these workflow components.

  • Saves us time and headache—easy to get up and running (less suck)
  • Ensures the building, packaging, testing and optimizing code happens in the same way (more consistency)

Less suck, drudgery and sadness

More consistency

A good workflow brings joy to your team by emphasizing the "yay" moments and de-emphasizing the misery

We're ready to go

Using defined grunt workflows

Clone Install Run

Using reveal.js' grunt workflow

$ git clone git@github.com:hakimel/reveal.js.git

Using reveal.js' grunt workflow

$ git clone git@github.com:hakimel/reveal.js.git
$ cd reveal.js

Using reveal.js' grunt workflow

$ git clone git@github.com:hakimel/reveal.js.git
$ cd reveal.js
$ npm install

Using reveal.js' grunt workflow

$ git clone git@github.com:hakimel/reveal.js.git
$ cd reveal.js
$ npm install
$ grunt [task]
$ grunt serve
  • Runs a simple, static web server
  • Watches SCSS source files; compiles them when changed
  • Watches JS source files; runs the 
    default
    task on change

How?

So that's how you use a pre-defined grunt workflow. But you may be wondering how the grunt tasks are set up in the first place.

How do we get to here?

$ grunt [task]
What did the creators of the grunt workflow for reveal.js do to get to the point where `$grunt [task]` executed tasks relevant to the project?

Grunt =

Gruntfile + package.json + grunt-cli

Use photo of distilled oil, like a formula

1. Gruntfile

Define ("register") grunt tasks Configure tasks Load the needed grunt plugins for your tasks

1. Gruntfile

Define ("register") grunt tasks
// Default task
grunt.registerTask('default', ['jshint', 'cssmin', 'uglify', 'qunit']);

// Theme task
grunt.registerTask('themes', ['sass']);

// Package presentation to archive
grunt.registerTask('package', [ 'default', 'zip']);

// Serve presentation locally
grunt.registerTask('serve', ['connect', 'watch'] );

// Run tests
grunt.registerTask('test',[ 'jshint', 'qunit']);

gruntfile.js

1. Gruntfile

Configure grunt tasks
watch: {
  main: {
    files: [ 'Gruntfile.js', 'js/reveal.js', 'css/reveal.css' ],
    tasks: 'default'
	},
  theme: {
    files: [ 'css/theme/source/*.scss', 'css/theme/template/*.scss' ],
    tasks: 'themes'
  }
}

gruntfile.jsSee grunt-contrib-watch documentation

1. Gruntfile

Load grunt plugins/dependencies
grunt.loadNpmTasks( 'grunt-contrib-qunit' );
grunt.loadNpmTasks( 'grunt-contrib-jshint' );
grunt.loadNpmTasks( 'grunt-contrib-cssmin' );
grunt.loadNpmTasks( 'grunt-contrib-uglify' );
grunt.loadNpmTasks( 'grunt-contrib-watch' );
grunt.loadNpmTasks( 'grunt-contrib-sass' );
grunt.loadNpmTasks( 'grunt-contrib-connect' );
grunt.loadNpmTasks( 'grunt-zip' );

gruntfile.js

2. package.json

  • JSON data of project module metadata
  • Includes 
    devDependencies
    for grunt
  • Those dependencies get installed when you run 
    $ npm install

2. package.json

{
  "name": "reveal.js",
  "version": "2.6.1",
  "description": "The HTML Presentation Framework",
  "homepage": "http://lab.hakim.se/reveal-js",
  "subdomain": "revealjs",
  "devDependencies": {
    "grunt-contrib-qunit": "~0.2.2",
    "grunt-contrib-jshint": "~0.6.4",
    "grunt-contrib-cssmin": "~0.4.1",
    "grunt-contrib-uglify": "~0.2.4",
    "grunt-contrib-watch": "~0.5.3",
    "grunt-contrib-sass": "~0.5.0",
    "grunt-contrib-connect": "~0.4.1",
    "grunt-zip": "~0.7.0",
    "grunt": "~0.4.0"
  }
}

package.json

Using grunt workflows

Clone repository npm install (package.json) $ grunt [task] (gruntfile.js)

More consistency

Less suck

How we ended up here

People

In vast part it is because of the human beings making software.

Collaboration

Common workflow approaches create a common vernacular that aids in collaboration.

Social coding

An emphasis on working together as peers.

Distributed teams

Even more need for simple, standard processes.

Development methodologies

The way we work now

How we're building.

Continuous integration

Respect and reverence for the build

Agility

Modular, independent approaches.

More complexity to corral

What we're using to build. We have more tools, need more transformation, and development onus has moved toward the front end.

Workflow orchestration processes have evolved, standardized, simplified

Less Wary, More Confident

I'm a n00b, too

In fact, that's why I'm here
I am in no way an expert at the things I'm talking about today.

Here's why you can do this

  • There are different levels of involvement
  • It's easier now
  • A lot of people like you are doing it, too
Getting easier all the time, e.g. npm comes with node.

Facing the challenges

Yikes: Abstract Concepts

Calm: Some Tips

  • Get your hands all dirty
  • Set aside time
  • Talk to someone who knows more

Yikes: New ("Hard") Technologies

Calm: Some Tips

  • Learn the vital nuggets: version control, JSON
  • Don't panic about the rest

But... There's so much to learn :*(

Calm: Some Tips

  • Engage in just-in-time learning
  • What you need to know versus what you can reference

Hmmmm... Where do I start? What if I get stuck?

Calm: Some Tips

  • Lean on documentation
  • Lean on examples
  • Lean on those who have gone before
  • Start simple

Gulp. What if everything goes terribly wrong?

Calm: Some Tips

  • The risks are probably less than you think
  • Continue building a technical safety net
  • Rely on your team

Remember

Less Suck

More Consistency

You can do it

 

Lyza Danger Gardner / @lyzadanger

Designed with Reveal.js with lovely help from @tylersticka on the Cloud Four theme. Most photos are my own, with the exceptions of photos of me (taken by immediate family or friends) and photos of Cloud Four staff, taken by Lisa Teso.

Read the A List Apart column that inspired this talk at http://alistapart.com/column/workflow-orchestration-for-the-wary