PIPPIN

Revenge of the deepfake detectives

Wed, 25 Sep 2019 00:00:00 +0000

Full post on medium | Axios write up | Code on github

A few of my Dessa colleagues and I released a fake voice detection model. Kaveh wrote about it in this weekend’s Axios’ Future. One of the primary questions throughout this project was asking can “can detectors keep up with new fake voice models?”

The short answer is that it’s going to be an uphill battle. To help with this we’re sharing our code to encourage the ML community that this type of work is necessary.

One optimistic idea from this experience: the effort needed to build detector models is much less than creating them. If we motivate developers of generators (good actors) to build detectors as well, the additional time cost is minimal!

One pessimistic idea: any good detector model can be used to make an opposing generator model better. This cat and mouse game will continue.

Detecting supernova with deep learning

Fri, 08 Feb 2019 00:00:00 +0000

An overview of our supernova classification system that we built using data from the Dark Energy Survey.

Betakit write up | Full post on medium | Code on github

Combining their interest in space with an exploration of deep learning’s potential applications for astronomy, 3 of Dessa’s engineers have collaborated on a project called space2vec since summer 2017.

Recently, the team built a deep learning system that identifies supernovas from telescope images with record-breaking speed: cutting the time it would take astronomers to identify supernovas almost in half! Here’s the team’s personal account of how they did it.

Will the future of books be more like Git?

Tue, 05 Jul 2016 00:00:00 +0000

When we think about languages and how they evolve, it’s usually at the needs of the people that use them. If we want to share a bit of information, whether that be an emotion, or description — we can create a new collection of letters to form a new word. As long as another person has a common understanding of this combination of letters, we can now use our new word in sharing information from one mind to another. Languages can be pretty neat this way, and can get even more descriptive if we talk about emojis.

Software, on the other hand, has overhead and accessibility issues. Sure, it also allows you to invent new meanings, and even create new languages — but currently it only evolves when you tell the machine to do something specific, and with correct details. This makes it tough for most to get involved and interested in seeing how the web, and computers will shape publishing going forward.

Max Bittker and I were lucky enough to spend the last weekend in June on the West Coast working along side folks who also care about a number of these issues at CODEX Hackathon. CODEX billed itself as an event to play with the future of publishing, but was really just a good excuse for smart designers, developers, and publishers to come together to build things that asked an important question of the direction of reading.

So over that very frenetic weekend, we built forkpad.me — a service that allows the remixing of stories on the popular writing site Wattpad — to help their community become better writers, and keep the web weird. Along the way we realized that the process of writing could take inspiration from the open source software development process. This idea lead us to asking these three questions, which helped shape the tool we wanted to build:

What happens when writers are able to remix and reuse each others work?
What happens when a story is never “finished”?
What happens when a story can have multiple authors?

Intrigued by this, Max and I asked ourselves how we could make a tool that could bring key aspects of Open Source Software (OSS) development to the writing and publishing process.

Informality Will Rule Publishing

One of the things Max and I love about the web is its ability to share information easily. Thanks to all the underlying technical protocols, we’re now able to build tools to reach many. When we showed up to Code for America’s San Francisco office Saturday morning, we knew the community on Wattpad was something we could have a lot of fun with.

We were given early access to the API for Wattpad, a massive serial writing community with over 40 million users who collectively spend more than 900 million years on the Wattpad site each month (85% of it on mobile).

In the time you’ll spend reading this article, Wattpad will receive enough werewolf fan fiction to last the rest of your life, in addition to other fan fiction of all niches and all personalities. I personally recommend checking out the entire 50 Shades of Drake volume, fan fiction about the rapper, if you’re curious.

As we explored the number of story categories and forums within Wattpad we found prolific communities sharing the wildest parts of their minds through stories. By far the biggest success within fan fiction (and informal publishing) is 50 Shades of Grey, which started as Twilight fan fiction.

So we began thinking about the web and its impact on publishing. Traditionally, the final product would be a book in the local store, but what is the “final product” when the process to publishing is just a ≤button/> on a page?

The End of a Story is No Longer Static

Traditionally a book would go through a publisher’s Book Product™ machine — but the web now allows the final product to be something different. The final product for an online book is no longer a function of traditional publishing’s Book Product™ formula, but something much less refined. A novella can be quickly written and published, and then evolve with reader interest to spawn a whole series of stories.

As we began to work with Wattpad’s API, we took a closer look at the niches that existed within the story comments and forums on Wattpad. We saw authors discussing ideas, and adding thoughts in hopes of pushing each other to create new narratives. This public process means that the end product isn’t static thing — and because the web allows a story to be edited and rewritten, every story has the ability to be dynamic and changing. Stories may end, but the process for many books is always evolving — which is especially true on Wattpad.

Ambient lighting. Gives @pippinlee a nice glow. He worked on Forkpad with Max. pic.twitter.com/ODK8B9ntdo
— CODEX Hackathon (@codexhackathon) July 1, 2015

Hard at work at the CODEX Hackathon with a Canadian contingent.

Can Remixing Help the Writing Process?

From our quick study of Wattpad, Max and I realized that this community could likely use a tool to help create a better feedback loop for authors working through story ideas. The idea of the “remix loop”, where creators spin off each others work can be incredible powerful tools within the writing process. Forkpad allows writers to take a part (“chapter”) from a Wattpad story and adapt it to their own liking.

When developing Forkpad, we found the concept of being able to change an ending or adapt characters to follow our own ideas a fun and important tool in the writing process. The ability to “fork” a Wattpad story means that others can post a link to their Forkpad version back on Wattpad to better share their thoughts on a story, as well as build off of each others’ work.

This idea of “forking” code is now common in software development. When computers were giant room-sized machines, the people who operated them (usually academics) would use tape as a medium to “write” their programs on. They would then feed these lengths of tape into a reader which would interpret their programs and run them on the computer. The programs were usually relatively small because computers could only process small bits of information. The idea of open source can be traced back to these early computer users, who stored their tapes in a drawer so that anyone using the computer could use their completed code. This saved colleagues from having to write a similar program from scratch, because they could share their completed tape programs.

Despite a period of highly commercialized and proprietary software during the 1980s and 1990s (a shift catalyzed, in part, by Microsoft), developers’ natural desire to share their code has roared back to life in the last twenty years (embodied by Linus Torvalds and his software versioning system Git).

Early computers would run programs that were created by punching holes in tape. Photo: wikimedia

Building off each other’s work is common in the open source world of software, where a team may spend a year solving a specific problem, and then they’ll share the code with other developers so that others don’t have to waste their time solving a problem that’s already been solved. Starting with an empty text box is a barrier to writing — so we wanted Forkpad to help get writers writing more. The process of consuming other’s work, and building off of it is one way that we can learn to be better writers, and Forkpad aims to make that easier.

As Saturday ended and Sunday began, we’d already built the main functionality of the Forkpad app — so we spent the last few hours before demo time getting our app up and running with a database so that writers could get a link that they could share. The ability to easily share their remixes means writers will hopefully be encouraged to build off each others work.

The process for using and publishing with Forkpad is much less formal than a traditional publishing process, but we think giving writers the ability to get writing will always trump a process that start with big end goals in mind. Writing is a process, so hopefully Forkpad can ask how that process can evolve for writers with the help of the machine. Much like the atmosphere at CODEX, it’s not a zero-sum game between the machine and publisher, but finding situations that allow both to be part of the creative process.

We’re not sure what writers will make, and we definitely don’t know what the end products will be, but we think it will be something fun.

Forkpad.me is live. Send us some Drake fanfic?

Thoughts from making tools for literature

The Elements of Programming Style (1978)

Tue, 16 Feb 2016 00:00:00 +0000

How do principles become timeless?

When I discovered Strunk and White’s (1920) famous The Element of Style in school, it provided one of the best lessons in brevity I’ve experienced. I still keep it in mind whenever I’m asked to write, because its concise points are timeless––timeless in the sense that while it is about style, it is not binded to style. Strunk and White’s style guide is still incredibly in-touch with writers almost 100 years later.

So I was happy to find this book, a derivative of the famous Strunk and White book, The Elements of Programming Style by Kernighan and Plauger, written in 1978, close to 40 years ago.

TEPS uses Fortran as its example language, but much like the book that inspired it, the lessons it teaches are timeless and still hold up today. When you can distill rule and opinion to good practice, you can advice that lasts a longtime.

I don’t think it’s quite right to call either the English, or programming style guide timeless, but it’s still evidence that core principles can last many decades, even if the software world feels like it’s evolving every hour.

I took some time to summarize each chapter’s points, and as you can see most still apply to modern software development.

Introduction

Write clearly- don’t be too clever.

Expression

Say what you mean, simply and directly.
Use library functions.
Avoid temporary variable
Write clearly – don’t sacrifice clarity for “efficiency”
Let the machine do the directly work
Replace repetitive expressions by calls to ca common function
Parenthesize to avoid ambiguity
Choose variable names that won’t be confused
Avoid the Fortran arithmetic IF
Use the good features of a language; avoid the bad ones
Use the “telephone test” for readability

Control Structure

Follow each decision as closely as possible with its associated action
Don’t stop with your first draft

Program Structure

Modularize
Make the coupling between modules visible
Each module should do one thing well
Make sure every module hides something
Let the data structure the program
Don’t patch bad code – rewrite it

Input and Output

Test input for validity and plausibility
Make sure input cannot violate the limits of the program
Identify bad input; recover if possible
Make input easy to prepare and output self-explanatory
Make input easy to proofread

Common Blunders

Don’t stop at one bug
Watch out for off-by-one errors
Avoid multiple exits from loops
Make sure your code “does nothing” gracefully
Test programs at their boundary values
Program defensively
10.0 times 0.1 is hardly ever 1.0

Efficiency and Instrumentation

Make it right before you make it faster
Keep it right when you make it faster
Make it clear before you make it faster
Don’t sacrifice clarity for small gains in “efficiency”
Let your compiler do the simple optimizations
Don’t strain to re-use code; reorganize instead
Keep it simple to make it faster
Don’t diddle code to make it faster – find a better algorithm
Instrument your programs. Measure before making “efficiency” changes

Documentation and readability

Make sure comments and code agree
Don’t just echo the code with comments – make every comment count
Don’t comment bad code – rewrite it
Use variable names that mean something
Format a program to help the reader understand it
Document your data layouts
Don’t over-comment

Additional reading

http://pu.inf.uni-tuebingen.de/users/klaeren/epigrams.html

https://en.wikipedia.org/wiki/Turing_tarpit

Harmonographs

Wed, 10 Feb 2016 00:00:00 +0000

One of wonderful things about the Internet is the deep dives you can do on things you didn’t know existed only a few minutes earlier.

I found the below video when researching the overlapping worlds of math, art, and computers. I was looking into motorized pen draings when I found the world of the harmonograph. Traditionally haramonographs are mechanical devices that power a drawing tool. Using a repetitive drawing motion on a surface that changes position creates some incredible results.

Tools that allow anyone to create, and get results that spark intrigue are my favourite type. They’re accessible, but bring people into both the art and math world.

It reminded me of Turtle Programming (Logo), where the user is given immediate visual feedback to their input. I recommend reading Turtle Geometry by Abelson, and Papert’s Mindstorms to understand the care put into Logo that allows for sufficently complex drawings and logic, while balancing accessibility.

As I dived further into the world of harmonographs I found that motors aren’t completely necessary. As slow, and methodic motion of the platform is the key to outputing good drawings, I found it possible to build a platform that moves with its four corners being the pivot points.

My setup was rough, but simple.

1) Find a sturdy platform and attach all four corners to the ceiling.

2) Create a “boom-like” arm that will hold the drawing tool. It’s important that this boom be strong as it will need to hold decent pressure and contact as the platform below it moves.

3) Adding some weights to the platform allows the motion to be smoother.

4) Once you’ve got everything setup you can start playing with different degrees of twist and sway when rocking the platform. This ultimately defines the output, the drawing design. I used a rectangular platform, but if you used a square platform it would also change the motion output in the drawings.

Here’s a video of my harmonograph in motion:

And a photo of one of the designs I was able to acheive:

Announcing the Open Journalism fellowship

Sun, 01 Nov 2015 00:00:00 +0000

Shipping a Fellow

Good news — today the Open Journalism Project is announcing the start of a Fellowship program.

A few months ago when Asad and I wrote about the experience and research we’d done in understanding problems that student newsrooms are facing — we got many thoughtful responses. We were able to talk to students quite literally scattered across the globe, from Pakistan and India, to small-town USA, and big cities in Europe. These were students that shared our frustration with the lack of opportunities at their universities to tinker at the intersection of code and journalism.

While we’ve written, talked, and advised students newsrooms — we’ve been lacking in our methodology. At best we’re able to recommend similar setups we’ve seen at professional newsrooms. We haven’t been able to clearly point to what has (and hasn’t) worked. We can’t share how we got a student newsroom curious about programming or obsessing over data. In part this is because nothing like this exists in Canada — we’re carving out a new and important path in journalism education. Today we’re announcing our fellowship program, something that is very much an experiment — but we believe if we do it in an open way, it will help show us and everyone what student newsrooms can be.

From our research:

We don’t know what we don’t know

“We spent much of the rest of the school year asking “what should we be doing in the newsroom?”, which mainly led us to ask “how do we use digital platforms to tell stories?” It was a straightforward question that led to many more questions. Out in the real world, traditional journalists were struggling to keep their jobs in a dying print world. They wore the same design of shoes that we were supposed to fill. Being pushed to repeat old, failing strategies and blocked from trying something new scared us.”

Why?

We’re kickstarting the process of getting Canadian student newsrooms thinking about the web. The Open Journalism Fellowships will seek students with strong computer science, web, data, or interactive skills by funding them as fellows to work at their campus student newsroom. We’re asking fellows to play a critical role as a colleague, mentor, and coder — but we know they’re up to the challenge. Our model is heavily inspired by our friends at the Knight Lab at Northwestern University, as well as the Knight Mozilla OpenNews Fellowship.

We’re focused on student newsrooms because that’s the part of the ecosystem we know best, and also the part where we can have the most influence. We believe student newsrooms are the perfect place to experiment because of how much flexibility and control over the process students have. That said, for this project to be successful we realized we’d also need to have the perspective of the professional newsroom, so we’ve brought on Julia Wolfe, news developer and designer for the Globe and Mail, and Tim Alamenciak, from TVO, to keep fellowships in line with what professional newsrooms are doing.

Who’s involved For this first year we’ve partnered with the Queen’s Journal, at Queen’s University, which is being helmed by editors-in-chief Anisa Rawhani and Sebastian Leck. Our first Open Journalism fellow will be Max Bittker.

Max Bittker (photo: Megan Gamble)

Max is a developer interested in digital empowerment and delight, Twitter bots, generative worlds, roasted vegetables, and neural networks. He’s a fourth-year computer engineering student at Queen’s University hailing from Rochester, New York. He looks forward to being the first Open Journalism Fellow and building skills, bridges, and weird stuff with the Queen’s Journal. You can find him here: maxbittker.github.io.

In addition to The Journal, we’ve brought together UBC’s Ubyssey, the McGill Tribune, uOttawa’s The Fulcrum, and UofT’s The Varsity to help build a strong community of students experimenting with telling stories on the web.

Our decision to make our first year of the fellowship program small is with the understanding that if we can work towards a model that fits student newsrooms, we’d be happy to expand in future years to more Canadian campuses.

Collaborators

Aniqah Mair (photo: Khalil Mair)

We’re also fortunate to have Aniqah Mair and Jake Pittis, both second year Computer Science students who will be collaborators with the project at Queen’s.

Jake Pittis (photo: Hack Western)

Both Aniqah and Jake have backgrounds in creating friendly environments for learning and programming — key pieces to the workshops, events, and mentorship we’re planning for the Queen’s Journal for the upcoming school year.

Goals and requirements

We understand that as the Fellowships progress we’ll learn how to make the experience for both the student newsrooms and fellows better, so there may be adjustments to our requirements.

Requirements for the fellow:

10 hours per week in the newsroom
Plan in collaboration with the newsroom + community for media week
Stipend + additional support around hardware, software, and mentoring
Running workshops locally to increase computer literacy
Helping us design and build curriculum as open-sourced manuals, which includes documenting process of “going-digital” in blog posts
Run for a full year with the last month budgeted for transition and reflection

What daily life looks like for fellows:

Treated as journalists
Have access to meetings involving story planning
Work with section heads/digital-editor to develop and showcase web-worthy stories
Commit/publish/document code to Github weekly

We’ll have frequent updates here at The Open Journalism Project publication https://medium.com/the-open-journalism-project to publicly discuss what works and doesn’t.

If you’d like to be part of the conversation, or talk, drop me a note at pippin@pippinlee.com or ping us on Twitter @OpenJo

Shipping a Fellow

How to convert your Gruntfile to npm scripts

Mon, 05 Oct 2015 00:00:00 +0000

In this post we’re going to take a quick look at npm scripts, and the thought process behind writing them. We’ll do this by taking Mozilla’s Makerstrap project and its Gruntfile and convert it to npm scripts to show us the benefits of npm scripts as a frontend build tool.

I should note before starting that there are many use cases for Grunt or Gulp, and npm scripts may not cover all of them. While it’s likely npm scripts can reduce your Grunt or Gulp files greatly, this post’s goal isn’t to diminish the usefulness of those task running services.

The goal of this post is to introduce another way that arguably has some simplification benefits. I ❤️ what Gulp and Grunt have done for frontend workflows—npm scripts is simply another option that we should consider.

Quick overview

If you already have a good understanding of npm scripts you can skip this overview.

If you’re less confident with npm scripts, all you really need to know is that it allows you to add tasks to your package.json’s scripts object. These tasks are run pretty much exactly like how you would run them through the command line.

What does a npm script look like? start: node server.js is a example of a simple script that allows a node server to start when you type npm start.

There are 3 main things you should know about npm script naming:

1) built-in script naming

npm has a list of ready-to-use npm script property names such as start, run, and test. In fact the command you likely use daily, npm install, is an npm script! You can run a script by running $ npm <name of script>.

2) pre and post script naming

When naming your scripts, you can add pre or post to tell npm to run them before or after. So if you have a start script, you could also write a prestart script that will run something before the start script runs.

3) custom script naming

If you’re like me, and want to be more 🐠expressive🐠, you can use your own script names. If for example we wanted to re-write that start command we could do so with getTheFluxCapacitorFluxingDoc: node server.js.

To run our custom named script we’d then run $ npm run getTheFluxCapacitorFluxingDoc, with run telling npm to run a non-standard named script.

Running multiple scripts

To run multiple scripts we can use syntax like npm run watch:* which looks for any watch:<asubtask> and runs them. This allows us to break use a script strucutre that represent smaller individual tasks, and then run them altogether.

Another popular way of running scripts is with npm-run-all module which allows us to use its --parallel argument to run scripts in parallel.

Just like on the command line, npm scripts also allows us to use && syntax to add additional commands to a script.

TLDR: Why do I use npm scripts?

if you’re already using npm, you don’t need to install anything. No extra task runner to install
no added abstraction of learning the ins and outs of Gulp and Grunt (that isn’t to say there aren’t some benefits to their abstraction too)
in my experience the code and time spent writing npm scripts is considerably less!
no more plugins

Let’s begin

We’re going to work through converting Makerstrap’s Gruntfile into npm scripts that will live in package.json. This should hopefully show that simplifying your build process isn’t too painful. Let’s take quick look at the Gruntfile:

module.exports = function(grunt) {
  require('time-grunt')(grunt);
  require('jit-grunt')(grunt, {
    shell: 'grunt-shell-spawn'
  });

  grunt.initConfig({
    pkg: grunt.file.readJSON('package.json'),
    less: {
      development: {
        files: {
          'demo/compiled/demo.dev.css': 'demo/less/demo.less'
        },
        options: {
          sourceMap: true
        }
      },
      build: {
        files: {
          'dist/makerstrap.min.css': 'less/build/makerstrap.less',
          'dist/makerstrap.complete.min.css':
          'less/build/makerstrap.complete.less',
          'demo/compiled/demo.css': 'demo/less/demo.less'
        },
        options: {
          compress: true
        }
      }
    },
    shell: {
      runServer: {
        options: {
          async: true
        },
        command: 'node demo/server.js'
      }
    },
    watch: {
      less: {
        files: ['less/**/*.less', 'demo/less/**/*.less'],
        tasks: ['less:development'],
        options: {
          spawn: false
        }
      }
    },
    copy: {
      latest: {
        expand: true,
        cwd: 'dist/',
        src: '**/*',
        dest: 'deploy/latest/'
      },
      version: {
        expand: true,
        cwd: 'dist/',
        src: '**/*',
        dest: 'deploy/v<%= pkg.version %>/'
      }
    },
    filesize: {
      base: {
        files: [
          {
            expand: true,
            cwd: 'dist/',
            src: ['*.css']
          }
        ]
      }
    }
  });

  grunt.registerTask('default', ['less:development', 'shell:runServer',
  'watch' ]);
  grunt.registerTask('stats', ['less:development', 'filesize']);
  grunt.registerTask('build', ['less:build', 'filesize']);
  grunt.registerTask('deploy', ['copy']);
};

So what’s under there anyways? Under wear?

To start our process of writing npm scripts, let’s start by breaking the Gruntfile into it’s different pieces. There are 4 registered tasks at the bottom of the Gruntfile:

default (works with just running grunt)
stats
build
deploy

We’ll use this structure for writing our npm scripts.

1) `default` task

These tasks would be typically run by running grunt, and were used as a way to get the necessary server and files going for development. The task is made up of three pieces that are wrapped together in a registerTask called default.

grunt.registerTask('default', ['less:development', 'shell:runServer', 'watch' ]);

a) `less:development`

Let’s first look at trying to rewrite the less:development part of the task as an npm script.

less: {
  development: {
    files: {
      'demo/compiled/demo.dev.css': 'demo/less/demo.less'
    },
    options: {
      sourceMap: true
    }
  },
},

In the Gruntfile we used 'demo/compiled/demo.dev.css': 'demo/less/demo.less' to compile demo.less to demo.dev.css and place it in a compiled directory.

We can use the great autoless module to help us compile our .less file. While autoless does have a watch feature we don’t need that here because we just want the compile feature.

autoless doesn’t let’s you specify a specific file, so we can just give it the demo/less/ directory as a source, and demo/compiled/ as the output point for the compiled .css file.

Here’s what the above Gruntfile code looks like as an npm script:

"less-dev": "autoless --source-map --no-watch demo/less/ demo/compiled/"

b) `watch`

Our next ~task~ to recreate as a script is a watch task:

watch: {
  less: {
    files: ['less/**/*.less', 'demo/less/**/*.less'],
    tasks: ['less:development'],
    options: {
      spawn: false
    }
  }
},

The above code watches a set of .less files and runs the less:development compile task when it sees a change.

We can use autoless here again. We’ll also give it the general directory name:

"watch:demo": "autoless --source-map demo/less/ && npm run less-dev",
"watch:base": "autoless --source-map less/ && npm run less-dev"

c) `shell:runServer`

Finally, we need to look at adding a short script to replace this command.

shell: {
  runServer: {
    options: {
      async: true
    },
    command: 'node demo/server.js'
  }
},

This Grunt task can be summed up very nicely like so:

"server": "node demo/server.js"

Note: server is one of npm’s reserved properties.

2) `stats` task

For the stats task we’ll need to write a script that checks the filesize. We already have the less:dev task completed above.

grunt.registerTask('stats', ['less:development', 'filesize']);

a) `filesize`

filesize: {
  base: {
    files: [
      {
        expand: true,
        cwd: 'dist/',
        src: ['*.css']
      }
    ]
  }
}

The above code outputs the following when $ grunt stats is run:

It returns the size makerstrap.complete.min.css and makerstrap.min.css, it also tells us how long it took for the task to run.

For the purpose of this post, we’ll skip trying to output nice charts, and focus just on returning the file sizes.

I couldn’t find an alternative to the Grunt filesize plugin, but it’s a very simple feature to recreate. Just create a tiny filesize.js module and use fs.stat to return the filesize values.

var fs = require('fs');
var path = process.argv[2];
var cli = require('cli-color');

fs.stat(path, function(error, stats) {
  console.log(path + ': ' + cli.green(Math.floor(stats.size/1024) + 'kb'));
});

Because npm scripts allows us to run a node command from the script, we can use filesize.js like so to return the filesizes:

stats: node filesize.js makerstrap.complete.min.js && node filesize.js makerstrap.min.js

which outputs something very similar to the grunt plug-in.

3) `build` task

We’ve already written a filesize script, so we’ll just focus on less:build.

grunt.registerTask('build', ['less:build', 'filesize']);

a) `less:build`

build: {
  files: {
    'dist/makerstrap.min.css': 'less/build/makerstrap.less',
    'dist/makerstrap.complete.min.css': 'less/build/makerstrap.complete.less',
      'demo/compiled/demo.css': 'demo/less/demo.less'
  },
  options: {
    compress: true
  }
}

The above code builds our Makerstrap app readying it for deployment.

It creates dist/makerstrap.min.css, dist/makerstrap.complete.min.css, and demo/compiled/demo.css from their respective .less files.

less/build/makerstrap.less -> dist/makerstrap.min.css
less/build/makerstrap.complete.less -> dist/makerstrap.complete.min.css
demo/less/demo.less -> demo/compiled/demo.css

To accomplish this, we can re-use our less-dev task and combine it with another autoless command to handle the two build/ files. Altogether our npm script for the build task would look something like this:

npm run less-dev && autoless --source-map --no-watch less/build/ dist/

4) `deploy`

Now, we can write the script for the final Grunt task:

grunt.registerTask('deploy', ['copy']);

a) `copy`

copy: {
  latest: {
    expand: true,
    cwd: 'dist/',
    src: '**/*',
    dest: 'deploy/latest/'
  },
  version: {
    expand: true,
    cwd: 'dist/',
    src: '**/*',
    dest: 'deploy/v<%= pkg.version %>/'
  }
},

copy:latest creates a directory called latest in /dist and adds a build version of your app.

copy:version creates a directory called version in /dist and adds a build version of Makerstrap’s css files.

We can use the great cpx module to copy files to /dist like so:

"build:deploy": "npm run build:copy && build:version",
"build:copy": "cpx \"**/*\" deploy/latest/",
"build:version": "cpx \"dist/**/*\" deploy/pkg-version/",

Wrap up

So if we take all of our newly written npm scripts, we should have something that looks like this:

"scripts": {
  "start": "npm-run-all --parallel server watch:*",
  "less-dev": "autoless --source-map --no-watch demo/less/ demo/compiled/",
  "watch:demo": "autoless --source-map demo/less/ && npm run less-dev",
  "watch:base": "autoless --source-map less/ && npm run less-dev",
  "build": "npm run less-dev && autoless --source-map --no-watch less/build dist/",
  "build:deploy": "npm run build:copy && build:version",
  "build:copy": "cpx \"**/*\" deploy/latest/",
  "build:version": "cpx \"dist/**/*\" deploy/pkg-version/",
  "server": "node demo/server.js",
  "postinstall": "bower install"
}

For ease I’ve used the npm-run-all module to be able to run the server and watch tasks in parallel when I run npm start.

All told, that wasn’t too painless, and should hopefully be easier to handle as your app and frontend pieces evolve.

I’d love to know about any errors or clarifications needed in this post, so please do tweet me, or email me: pippin@pippinlee.com.

Here’ the final version of Makerstrap done using npm scripts: github.com/pippinlee/makerstrap

Additional information

Substack on “npm run”
Kate Hudson’s “advanced front-end automation with npm” talk
npm’s great docs on “run-script”
Please do be careful if you include the getTheFluxCapacitorFluxingDoc command in your npm script, I can’t tell you how often I’ve forgotten to include an end script to cool and shut it down and then ended up back at Alamos with Feynman.

Announcing the Open Journalism fellowship

Tue, 25 Aug 2015 00:00:00 +0000

Shipping a Fellow

Good news — today the Open Journalism Project is announcing the start of a Fellowship program.

From our research:

We don’t know what we don’t know

Why?

Max Bittker (photo: Megan Gamble)

Collaborators

Aniqah Mair (photo: Khalil Mair)

We’re also fortunate to have Aniqah Mair and Jake Pittis, both second year Computer Science students who will be collaborators with the project at Queen’s.

Jake Pittis (photo: Hack Western)

Goals and requirements

We understand that as the Fellowships progress we’ll learn how to make the experience for both the student newsrooms and fellows better, so there may be adjustments to our requirements.

Requirements for the fellow:

10 hours per week in the newsroom
Plan in collaboration with the newsroom + community for media week
Stipend + additional support around hardware, software, and mentoring
Running workshops locally to increase computer literacy
Helping us design and build curriculum as open-sourced manuals, which includes documenting process of “going-digital” in blog posts
Run for a full year with the last month budgeted for transition and reflection

What daily life looks like for fellows:

Treated as journalists
Have access to meetings involving story planning
Work with section heads/digital-editor to develop and showcase web-worthy stories
Commit/publish/document code to Github weekly

We’ll have frequent updates here at The Open Journalism Project publication https://medium.com/the-open-journalism-project to publicly discuss what works and doesn’t.

If you’d like to be part of the conversation, or talk, drop me a note at pippin@pippinlee.com or ping us on Twitter @OpenJo

Shipping a Fellow

Open Journalism Project

Tue, 17 Mar 2015 00:00:00 +0000

We pushed out the first version of the Open Journalism site in January. Our goal is for the site to be a place to teach students what they should know about journalism on the web. It should be fun too.

Topics like mapping, security, command line tools, and open source are all concepts that should be made more accessible, and should be easily understood at a basic level by all journalists. We’re focusing on students because we know student journalism well, and we believe that teaching maturing journalists about the web will provide them with an important lens to view the world with. This is how we got to where we are now.

Circa 2011

In late 2011 I sat in the design room of our university’s student newsroom with some of the other editors: Kate Hudson, Brent Rose, and Nicholas Maronese. I was working as the photo editor then—something I loved doing. I was very happy travelling and photographing people while listening to their stories.

Photography was my lucky way of experiencing the many types of people my generation seemed to avoid, as well as many the public spends too much time discussing. One of my habits as a photographer was scouring sites like Flickr to see how others could frame the world in ways I hadn’t previously considered.

http://www.topleftpixel.com

I started discovering beautiful things the web could do with images: things not possible with print. Just as every generation revolts against walking in the previous generations shoes, I found myself questioning the expectations that I came up against as a photo editor. In our newsroom the expectations were built from an outdated information world. We were expected to fill old shoes.

So we sat in our student newsroom—not very happy with what we were doing. Our weekly newspaper had remained essentially unchanged for 40+ years. Each editorial position had the same requirement every year. The big change happened in the 80s when the paper started using colour. We’d also stumbled into having a website, but it was updated just once a week with the release of the newspaper.

Information had changed form, but the student newsroom hadn’t, and it was becoming harder to romanticize the dusty newsprint smell coming from the shoes we were handed down from previous generations of editors. It was, we were told, all part of “becoming a journalist.”

We don’t know what we don’t know

We spent much of the rest of the school year asking “what should we be doing in the newsroom?”, which mainly led us to ask “how do we use the web to tell stories?” It was a straightforward question that led to many more questions about the web: something we knew little about. Out in the real world, traditional journalists were struggling to keep their jobs in a dying print world. They wore the same design of shoes that we were supposed to fill. Being pushed to repeat old, failing strategies and blocked from trying something new scared us.

We had questions, so we started doing some research. We talked with student newsrooms in Canada and the United States, and filled too many Google Doc files with notes. Looking at the notes now, they scream of fear. We annotated our notes with naive solutions, often involving scrambled and immature odysseys into the future of online journalism.

There was a lot we didn’t know. We didn’t know how to build a mobile app. We didn’t know if we should build a mobile app. We didn’t know how to run a server. We didn’t know where to go to find a server. We didn’t know how the web worked. We didn’t know how people used the web to read news. We didn’t know what news should be on the web. If news is just information, what does that even look like?

We asked these questions to many students at other papers to get a consensus of what had worked and what hadn’t. They reported similar questions and fears about the web but followed with “print advertising is keeping us afloat so we can’t abandon it”.

In other words, we knew that we should be building a newer pair of shoes, but we didn’t know what the function of the shoes should be.

Common problems in student newsrooms (2011)

Our questioning of other student journalists in 15 student newsrooms brought up a few repeating issues.

Lack of mentorship
A news process that lacked consideration of the web
No editor/position specific to the web
Little exposure to many of the cool projects being put together by professional newsrooms
Lack of diverse skills within the newsroom. Writers made up 95% of the personnel. Students with other skills were not sought because journalism was seen as “a career with words.” The other 5% were designers, designing words on computers, for print.
Not enough discussion between the business side and web efforts

From our 2011 research

Common problems in student newsrooms (2013) Two years later, we went back and looked at what had changed. We talked to a dozen more newsrooms and weren’t surprised by our findings.

Still no mentorship or link to professional newsrooms building stories for the web
Very little control of website and technology
The lack of exposure that student journalists have to interactive storytelling. While some newsrooms are in touch with what’s happening with the web and journalism, there still exists a huge gap between the student newsroom and its professional counterpart
No time in the current news development cycle for student newsrooms to experiment with the web
Lack of skill diversity (specifically coding, interaction design, and statistics)
Overly restricted access to student website technology. Changes are primarily visual rather than functional.
Significantly reduced print production of many papers
Computers aren’t set up for experimenting with software and code, and often locked down

Newsrooms have traditionally been covered in copies of The New York Times or Globe and Mail. Instead newsrooms should try spend at 20 minutes each week going over the coolest/weirdest online storytelling in an effort to expose each other to what is possible. “Hey, what has the New York Times R&D lab been up to this week?”

Instead of having computers that are locked down, try setting aside a few office computers that allow students to play and “break”, or encourage editors to buy their own Macbooks so they’re always able to practice with code and new tools on their own.

From all this we realized that changing a student newsroom is difficult. It takes patience. It requires that the business and editorial departments of the student newsroom be on the same (web)page. The shoes of the future must be different from the shoes we were given.

We need to rethink how long the new shoe design will be valid. It’s more important that we focus on the process behind making footwear than on actually creating a specific shoe. We shouldn’t be building a shoe to last 40 years. Our footwear design process will allow us to change and adapt as technology evolves. The media landscape will change, so having a newsroom that can change with it will be critical.

We are building a shoe machine, not a shoe.

A train or light at the end of the tunnel: are student newsrooms changing for the better?

In our 2013 research we found that almost 50% of student newsrooms had created roles specifically for the web. This sounds great, but is still problematic in its current state.

We designed many of these slides to help explain to ourselves what we were doing When a newsroom decides to create a position for the web, it’s often with the intent of having content flow steadily from writers onto the web. This is a big improvement from just uploading stories to the web whenever there is a print issue. However…

1. The handoff

Problems arise because web editors are given roles that absolve the rest of the editors from thinking about the web. All editors should be involved in the process of story development for the web. While it’s a good idea to have one specific editor manage the website, contributors and editors should all play with and learn about the web. Instead of “can you make a computer do XYZ for me?”, we should be saying “can you show me how to make a computer do XYZ?”

2. Not just social media

A web editor could do much more than simply being in charge of the social media accounts for the student paper. Their responsibility could include teaching all other editors to be listening to what’s happening online. The web editor can take advantage of live information to change how the student newsroom reports news in real time.

3. Web (interactive) editor

The goal of having a web editor should be for someone to build and tell stories that take full advantage of the web as their medium. Too often the web’s interactivity is not considered when developing the story. The web then ends up as a resting place for print words.

Editors at newsrooms are still figuring out how to convince writers of the benefit to having their content online. There’s still a stronger draw to writers seeing their name in print than on the web. Showing writers that their stories can be told in new ways to larger audiences is a convincing argument that the web is a starting point for telling a story, not its graveyard.

When everyone in the newsroom approaches their website with the intention of using it to explore the web as a medium, they all start to ask “what is possible?” and “what can be done?” You can’t expect students to think in terms of the web if it’s treated as a place for print words to hang out on a web page.

We’re OK with this problem, if we see newsrooms continue to take small steps towards having all their editors involved in the stories for the web.

The current Open Journalism site was a few years in the making. This was an original launch page we use in 2012

What we know

New process

Our rough research has told us newsrooms need to be reorganized. This includes every part of the newsroom’s workflow: from where a story and its information comes from, to thinking of every word, pixel, and interaction the reader will have with your stories. If I was a photo editor that wanted to re-think my process with digital tools in mind, I’d start by asking “how are photo assignments processed and sent out?”, “how do we receive images?”, “what formats do images need to be exported in?”, “what type of screens will the images be viewed on?”, and “how are the designers getting these images?” Making a student newsroom digital isn’t about producing “digital manifestos”, it’s about being curious enough that you’ll want to to continue experimenting with your process until you’ve found one that fits your newsroom’s needs.

More (remote) mentorship

Lack of mentorship is still a big problem. Google’s fellowship program is great. The fact that it only caters to United States students isn’t. There are only a handful of internships in Canada where students interested in journalism can get experience writing code and building interactive stories. We’re OK with this for now, as we expect internships and mentorship over the next 5 years between professional newsrooms and student newsrooms will only increase. It’s worth noting that some of that mentorship will likely be done remotely.

Changing a newsroom culture

Skill diversity needs to change. We encourage every student newsroom we talk to, to start building a partnership with their school’s Computer Science department. It will take some work, but you’ll find there are many CS undergrads that love playing with web technologies, and using data to tell stories. Changing who is in the newsroom should be one of the first steps newsrooms take to changing how they tell stories. The same goes with getting designers who understand the wonderful interactive elements of the web and students who love statistics and exploring data. Getting students who are amazing at design, data, code, words, and images into one room is one of the coolest experience I’ve had. Everyone benefits from a more diverse newsroom.

What we don’t know

*Sharing curiosity for the web

We don’t know how to best teach students about the web. It’s not efficient for us to teach coding classes. We do go into newsrooms and get them running their first code exercises, but if someone wants to learn to program, we can only provide the initial push and curiosity. We will be trying out “labs” with a few schools next school year to hopefully get a better idea of how to teach students about the web.

Business

We don’t know how to convince the business side of student papers that they should invest in the web. At the very least we’re able to explain that having students graduate with their current skill set is painful in the current job market.

The future

We don’t know what journalism or the web will be like in 10 years, but we can start encouraging students to keep an open mind about the skills they’ll need. We’re less interested in preparing students for the current newsroom climate, than we are in teaching students to have the ability to learn new tools quickly as they come and go.

Another slide from 2012 website

A concise guide to building stories for the web There are too many options to get started. We hope to provide an opinionated guide that follows both our experiences, research, and observations from trying to teach our peers. Student newsrooms don’t have investors to please. Student newsrooms can change their website every week if they want to try a new design or interaction. As long as students start treating the web as a different medium, and start building stories around that idea, then we’ll know we’re moving forward.

A note to professional news orgs

We’re also asking professional newsrooms to be more open about their process of developing stories for the web. You play a big part in this. This means writing about it, and sharing code. We need to start building a bridge between student journalism and professional newsrooms.

2012

This is a start

We going to continue slowly growing the content on Open Journalism. We still consider this the beta version, but expect to polish it, and beef up the content for a real launch at the beginning of the summer.

We expect to have more original tutorials as well as the beginnings of what a curriculum may look like that a student newsroom can adopt to start guiding their transition to become a web first newsroom. We’re also going to be working with the Queen’s Journal and The Ubyssey next school year to better understand how to make the student newsroom a place for experimenting with telling stories on the web. If this sound like a good idea in your newsroom, we’re still looking to add 1 more school.

We’re trying out some new shoes. And while they’re not self-lacing, and smell a bit different, we feel lacing up a new pair of kicks can change a lot.

Let’s talk. Let’s listen.

We’re still in the early stages of what this project will look like, so if you want to help or have thoughts, let’s talk.

pippin@pippinlee.com

This isn’t supposed to be a manifesto™© we just think it’s pretty cool to share what we’ve learned so far, and hope you’ll do the same. We’re all in this together.

The Open Journalism Project: Better Student Journalism

Command line news headlines

Sun, 14 Dec 2014 00:00:00 +0000

github.com/pippinlee/news-cli

Try it: npm install get-headlines -g (or without -g global flag)

Most projects I build come from a question, or a few. While part of the excuse of doing this project was to get more familiar with working with node and scraping data, I also wanted to help answer these questions:

What tools can we build to make people more aware of the world around them?
What info would be helpful to give a reader to fill in their gaps of awareness?
What info exists already that we can use?

Ask, then build

I ended up focusing on local news for the following reasons: If an individual is to look at major news sites, for example BBC or the Globe and Mail, their top headlines are usually the same major international stories. There is little to glean about an actual geographical region and it’s pulse unless we start to look at what’s being written in subsets (local) news headlines.

While building this tool I also became aware of how information (stories) trickle up to bigger publications. Watching stories pick up steam attention-wise was a good part of the fun.

The command line tool in this project is part of a larger project I’m working on to take the pain out of accessing a wide variety of news headlines from around the world. The biggest pain if someone were to try do this now is figure out the DOM’s scraping path of each local news site. You can see I’ve had to manually find the best scraping path for each headline, which wasn’t too much fun.

Building a database for scraping

Design-wise, I’ve made it so that users can add additional arguments to specify if they want news from a specific city, province, state, or country. When you type in get-headlines canada, the scraper runs and grabs all the headlines I’ve specified it to get. For now I have it set to purposefully only grab the most recent headline of each website.

In their newer versions, Firefox does make it much easier to find the correct DOM path to get to an element. Once your FF inspector is open you can right click on an element in the inspector window and copy its path.

Anecdotally, there’s a wide range of ways we could get headlines outside of scraping. Many sites do have half-decent RSS feeds, and some (too few), have public API’s for their stories.

You can download the get-headlines command line tool with npm install get-headlines -g, or without -g if you don’t want it installed globally.

Right now there are 25 different local news sites that can be queried via command line. One difficulty going forward will be monitoring for when websites change their URL paths or site design, so the current scraper paths I have will no longer work. Adding a testing system would be a good way to get my attention that I need to update a site’s URL path or query path. [Since this post has been written Firefox has a much better built-in DOM path selector built into its developer tools. This saves a lot of time when updating broken DOM paths.]

What will the information be good for?

With all this local data you could…

Interactive map to help people get a sense of what’s happening elsewhere
Use it as a starting point for headline archival

Driving dashboard

Thu, 04 Dec 2014 00:00:00 +0000

https://github.com/pippinlee/drive-dashboard

You can see a live version of this project here: pippinlee.com/drive-dashboard

This project started with a friend sending me ~51,000 points of data. He’d just bought an adapter that allowed him to start collecting the driving data his car’s computer was producing. Car’s have had computers built into them for quite a while, but only recently has their data become more thorough. The third-party market for accessories for accessing this information has also exploded.

There are also a growing number of products, like Eric Evenchick’s CANtact, that give car owner’s more control over their car’s internal computers.

@pippinlee @zmanji http://t.co/Nh0IQYd0px bluetooth OBDII port adapter -> Android Torque app -> MySQL in real time (local logs are in .csv)
— Stephen Vescio (@stephenvescio) December 1, 2014

Most of the work of making data useful is asking the right questions, which leads to being able to build a helpful interface. Along with avoiding chartjunk, filtering out many of the data points was helpful while building this dashboard.

Finally, it was a good excuse to work with d3.js and leaflet.

Zoomed out view of of the .csv

Joining educreations

Tue, 09 Oct 2012 00:00:00 +0000

One, to many

“You know I never finished university. I’d even tell you, you don’t need university.”

These are the few words I remember from a chance encounter with the critically-minded Cory Doctorow last year while attending a discussion on media at UofT. I don’t remember the actual discussion too much but those words seem to have stuck in my head. It’s been over a year since the event but as the humour in fate would have it, I have decided to take a year off. Not as Cory suggested, leave, but take a year off.

Why

Let’s pause for a second to mention my honest excitement towards academia. This statement isn’t a play to my brave parents or the faculty I’ve had the chance to work with. I honestly believe there’s huge value placed in the research and findings done at the academic level. In fact the small outside of school research project I co-founded, Open Journalism, hinted to me the power of understanding complex problems that meet at the intersection of social, and technological change. We need these places of discussion and research, greatly.

With that said, I’m really excited to working with the Educreations team in Palo Alto, California for the next 9 months. I will miss Canada.

It’s likely not a coincidence that I chose to work with a team of people that care deeply about democratizing the tools to teach.

Imagine for a second if Newton, Feynman, or Einstein had the ability to share their knowledge to anyone with a computer. It’s with that hope, knowing that the next Newtons are being born and giving them the right tools to share what they know. That excites me.

The Educreations iPad app and website take a step forward from the giant whose shoulders many of us stand on, Sal Khan, to give anyone who wants to teach the tools to do so.

It’s apparent that as our ability to reach everyone around the world increases, it’s important to build things that allow distribution of knowledge in really easy to use ways. Tim O’Reilly has done a really good job with this idea in his creation of O’Reilly publishing, with the ethos that it was important to build things that allowed the sharing of information from one to many.

Tool Maker

I’ll be spending the next 10 months better understanding how to make tools that are joy to use. That means a focus on building a tool that both understands and experiments with the future of technology and the classroom.

If you know me well, you know that I spend most nights working on small code/design projects. I’m excited to see what my full focus and working closely with some brilliant engineers can do to help build a really important technology.

We have big expectations to fill if the next Newton is just being born and grabbing for that iPad, after all.

If dots are minds, and minds are full of knowledge, surely connecting the dots will make humankind a bit more humble, and a lot more educated.

I can’t take all the credit for making working in education cool again. Apparently GZA was on board before me.

Globe and Mail: whiteboard alternative

Fri, 05 Oct 2012 00:00:00 +0000

I was interviewed by the Globe and Mail about “hacks” for student living. In this case I’ve done a bunch of work to find out cheaper alternatives to whiteboards.

I was originally inspired to start looking for cheaper versions of whiteboards after spending a weekend at Stanford’s D.School working on Ben Huh’s Moby Dick project.

The space is opinionated only in the sense of allowing space to be extemely flexible. Everything object within the building can be moved around to accomadate to the “space” a team needs. If you’re curious, the below video explains it well.

I got mine from this Toronto home depot.

Lexan is the company that makes the highest quality boards. It is important to note that as the price goes down, so does the grade (quality) of plastic.

If you’re interested here are a few other resources I found helpful along the way:

Someone also just sent me their (much bigger than mine) DIY whiteboard:

Let me know if you have any other questions or if you try anything different I’d love to know if it works better?

Building a GIF site for Martha

Mon, 28 May 2012 00:00:00 +0000

Christmas is coming! http://t.co/tbmRuV4gbD pic.twitter.com/6tyiTdxAGK
— Martha Stewart (@MarthaStewart) December 17, 2013

A few months ago just before heading to bed I got a text from Stephen with a “stupid idea”.

The idea centered around being able to save any GIF to Gifpost that catches your eye online. This would save you from having to download the GIF to be able to find it next time you want to use it.

A couple weeks later and gifpost.me was born. Full credit to Stephen for doing all the heavy lifting on the backend.

A few months after releasing the site online, it started getting used by people that weren’t just our friends.

Rapper Mac Miller used it to announce his new album:

30 minutes til #SDS http://t.co/EfMsXnJODs
— Mac (@MacMiller) April 23, 2013

So, it turns out building a tool with a very specific focus–however trivial–can be helpful to a certain audience. Maybe everyone that needs your tool won’t find it right away.

July 2015 update: site was shut down as traffic had slowed and finding time to do maintenance was tricky.

Where are the Lee's?

Sun, 13 May 2012 00:00:00 +0000

[Google killed this API feature in 2013 so the site no longer exists]

wherearethelees.com was a creation for Mother’s Day between Ted and I. So where did the idea come from?

Harry Potter, of course. The Weasley’s had a clock (Whereabouts Clock) that told them where everyone in the family was at all times.

Short of being magical, we created this because my Mom doesn’t yet own a cell phone.

Right now it’s a mash-up of Google’s Map API and Twitter’s API.

A “DINNER!” button that allows my Mom to press a button that sends a text to all our phones may be in the pipes for the near future.

PIPPIN

Revenge of the deepfake detectives

Detecting supernova with deep learning

Will the future of books be more like Git?

Informality Will Rule Publishing

The End of a Story is No Longer Static

Can Remixing Help the Writing Process?

The Elements of Programming Style (1978)

Introduction

Expression

Control Structure

Program Structure

Input and Output

Common Blunders

Efficiency and Instrumentation

Documentation and readability

Additional reading

Harmonographs

Announcing the Open Journalism fellowship

Shipping a Fellow

We don’t know what we don’t know

Why?

Collaborators

Goals and requirements

How to convert your Gruntfile to npm scripts

Quick overview

1) built-in script naming

2) pre and post script naming

3) custom script naming

Let’s begin

So what’s under there anyways? Under wear?

1) default task

a) less:development

b) watch

c) shell:runServer

2) stats task

a) filesize

3) build task

a) less:build

4) deploy

a) copy

Wrap up

Additional information

Announcing the Open Journalism fellowship

Shipping a Fellow

We don’t know what we don’t know

Why?

Collaborators

Goals and requirements

Open Journalism Project

Circa 2011

We don’t know what we don’t know

Common problems in student newsrooms (2011)

A train or light at the end of the tunnel: are student newsrooms changing for the better?

What we know

What we don’t know

What we’re trying to share with others

A note to professional news orgs

This is a start

Command line news headlines

Ask, then build

Building a database for scraping

What will the information be good for?

Driving dashboard

Joining educreations

One, to many

Why

Tool Maker

Globe and Mail: whiteboard alternative

Building a GIF site for Martha

Where are the Lee's?

1) `default` task

a) `less:development`

b) `watch`

c) `shell:runServer`

2) `stats` task

a) `filesize`

3) `build` task

a) `less:build`

4) `deploy`

a) `copy`