The Art of Unix Programming

## Rule of Modularity Write simple parts connected by clean interfaces.
## Rule of Parsimony Write a big program only when it is clear **by demonstration** that nothing else will do.
## Correctness and Collaboration When you can't reason correctly about the guts of a program, you can't be sure it's correct and you can't fix it if it's broken.
## Prototyping Prototype then polish. Get it working before you optimize it.
## Summary The **only** way to write complex software that won't fall on its face is build it out of simple modules connected by well-defined interfaces, so that most problems are local and you have some hope of fixing or optimizing a part without breaking the whole.

What constitutes a module

rayons1 raynos2

Example from Haskell

hoogle

String -> String

Easier said than done

worth it

ease or reuse

test and extend in isolation

forced to write readme

small learning curve

Challenges

spotting potential standalone functions

decoupling them from other parts of code

Patterns

separate code into small functions in separate files

decouple, decouple, decouple

continuously refactor out functions into separate files

continuously pull out non app specific modules

Pull out process

separate repo and init package

move or create tests

travis / testling

LICENSE

write GOOD readme

provide examples

npm pub

full view

trap

ansi1 ansi2

fs.readFile

curl http://nodejs.org/api/assert.html | hermit

scriptie-talkie

hypernal

hyperwatch

How to Become Module Driven

Phase One

any standalone function belongs in its own lib/module

pull them out into separate packages whenever you can

How to Become Module Driven

Phase Two

substitute "npm" for "lib" in previous statement

any standalone function belongs in its own npm/module

hold your horses

find module that does what you need or fork one that's close

npm install thlorenz/foo

How to Become Module Driven

Tools

npm init or pkginit

travisify

npm link