theme | transition |
---|---|
League |
slide |
Some thoughts and tools
by Joel "Jaykul" Bennett
- Hacker and Programmer
- Social Science Major
- Automation Specialist
- Software Engineer
- DevOps Consultant
- Microsoft PowerShell MVP
--
So in other words
I'm software engineer with a sociology background,
doing #DevOps in the Windows (and .NET) world,
wishing we'd stop taking the learning curve for granted.
A 1984 book by Donald Knuth
Goal: significantly better documentation
- Explain to humans what we want the computer to do
- Write as an essayist, carefully naming and explaining
- Order the program for human comprehension
note:
I believe that the time is ripe for significantly better documentation of programs, and that we can best achieve this by considering programs to be works of literature. Hence, my title: "Literate Programming."
Let us change our traditional attitude to the construction of programs: Instead of imagining that our main task is to instruct a computer what to do, let us concentrate rather on explaining to human beings what we want a computer to do.
The practitioner of literate programming can be regarded as an essayist, whose main concern is with exposition and excellence of style. Such an author, with thesaurus in hand, chooses the names of variables carefully and explains what each variable means. He or she strives for a program that is comprehensible because its concepts have been introduced in an order that is best for human understanding, using a mixture of formal and informal methods that reinforce each other.
--
Tools (tangle and weave) were written...
But the examples you'll find today are all demos, parts of a book or article on the topic.
Needless to say, it never really took off.
note:
Writing a literate program is a lot more work than writing a normal program. After all, who ever documents their programs in the first place!? Moreover, who documents them in a pedagogical style that is easy to understand? And finally, who ever provides commentary on the theory and design issues behind the code as they write the documentation?
--
I believe that the time is ripe for significantly better documentation
There are new tools, new audiences
- Emacs Org Mode
- IPython => Jupyter
- nteract, Spyder IDE, Atom Hydrogen
- Apache Zeppelin
- Jupyter Labs
Howard Abrams and Marc Hoffman
like to talk about DevOps as bi-modal:
- Bang head until server works
- Capture effort into automation
We want to make 1. more like 2.
--
We want to capture the process of investigating and learning so that:
- Others can learn from our bruises
- We can export it to the automation
Since the goal is to capture the investigation,
I basically have to do one of two things:
- Take copious notes
- Enable transcription
For now, let's talk about taking notes
(but don't forget to ask me about transcription later)
--
Remember this is not for application code, it's
- Infrastructure
- Deployments
I'm not writting an essay about my grandiose plans (yet), but I am simply taking notes during my investigation. I need a tool that's good for that.
- I need a notebook
- I like markdown
- I want code inline
- But I
--
Allow me to introduce Jupyter