This is Derek.
Derek is our Department of Education's Educational Technologist, responsible for creating outstanding curriculum and materials for electronics education. He has spent the last 16 months writing a thorough guidebook to getting started with Processing, and we're excited to share that it will be published by No Starch Press in June!
Processing is a free, beginner-friendly programming language designed to help non-programmers create interactive art with code. Over the course of the book, readers learn the basics by drawing simple shapes, move on to photo editing and video manipulation, and ultimately affect the physical world by using Processing with an Arduino.
Even though he just spent 16 months immersed in the land of Processing and book-authoring, he was nice enough to talk about the process with us before he takes a very long nap.
What was it like writing a book for the first time?
In a lot of ways it's similar to your first international flight. About 80 percent of it you have done before, but it’s the 20 percent that's new to you that really gets you. In the past I have written papers, blog posts and content for the classroom. For much of that it was just me; writing a book has been eye opening and I never really realized how many people it takes to pull it off.
To be honest, it has been the most fun and frustrating project I have worked on in my professional life. When I was a teacher my content was mine; I delivered it to students and my students could ask me to clarify something or ask questions. With a book we want a reader to get it, crystal clear. They don’t really have the option of raising their hand and asking what a word means or why they are having trouble. I think that is the one thing that I had to get used to in the writing & editing process – a reader that I will never meet, and who will never be learning this stuff from me in the classroom.
What was the hardest part?
There were a number of things that were difficult with the process of writing the book. Most of them were self inflicted, so I can’t really blame the process. I enjoy being on the edge of my knowledge. I thrive when I am learning and being challenged in that way. In essence, writing a book was the opposite of that. It was documenting the stuff that was core knowledge to me while I wanted to go off and chase the new squirrels every day.
The editing process for the book has also been hard for me. It is really humbling to get a chapter back from my editor and there is more red than black on the page. This rapidly made me a better writer and editor.
What was the motivation for writing about Processing?
This is a good question, especially since we work for a hardware company. The motivation stems from my experience teaching middle school students how to use Arduino. I was frustrated with the number of errors students were getting. I ended up being a stop for the SparkFun west coast tour, Jeff Branson ran a simple Processing workshop for my classes, and I was hooked.
I saw Processing as a way to start students down the road of Arduino without having to deal with hardware and wiring right away. The goal was to teach just enough in Processing to make my students comfortable with programming and the syntax of Processing (which is the same as Arduino), so that they would be “skilled” programmers, and I could then focus on the circuit and hardware side of things when they picked up Arduino.
The unintended side effect of this was that students would naturally gravitate towards Processing for projects. Once they learned that an Arduino could talk to Processing through serial, all bets were off. I changed my class curriculum to reflect that interactive creative side of this technology, and I started to document my work through a site called Processing and Interactivity for Educators.
To make a long story a little longer, I was offered a job here at SparkFun in the Department of Education, and was given the freedom to expand my collection of content around Processing, which in the end has turned into a book. We now use Processing as an introduction to programming tool to build interactive displays, data dashboards and a whole slew of other widgets and tools. We see it as computational duct tape.
What was the most fun?
The most fun was getting see my content go into book form. I am really proud of the work that not only I put into building a progression of learning around Processing, but also the content and code snippets from my co-workers. During the writing process there were a number of times where I really liked something I saw someone else teach or create and said to myself, “That’s going in the book!”
I also took great pleasure in writing the chapter about using images in Processing. I have been torturing my co workers by using their pictures for examples and modifying and contorting them, knowing full well that they would end up in a book. There is a specific image that I am especially proud of; you will know it when you see it!
What was the least fun?
You would think technical editing would be easy for me to go through since I work here at SparkFun – it wasn’t. With no formal background in computer science or programming, I have found that how I describe what is going on, the terms I use, and sometimes my complete understanding of things is, well...wrong. But I think there is a need for a book and content that is somewhere in between oversimplification and a stuffy textbook; I hope this book is it.
I am working with technical editing to compromise on some of the things that turn many people off to programming and programming books in general. I usually take the stance that as long as I get people in the right frame of mind or understanding using metaphors, I can be close to correct but not technically correct. Technically correct doesn’t condone play; I prefer to make someone comfortable with what they are learning, to get the big picture and then act on it. I don't know how many technical books I have read that caused me to lock up mentally and not know how to put any of it into practice. I want to make sure that this book is not one of those books. The professors can deal with technical and theoretical, I am concerned with the reader diving in and doing.
**What advice would you give someone considering writing a book? **
There is a lot of advice I could give, but even I wouldn’t follow it. Take it with a grain of salt.
Thanks Derek - great job and we can't wait to see the book when it comes out!
Derek, I am about to start writing a technical book - in the naval architecture space (highly technical topic). My question is what software did you use? Would you use that same software again? - if not, what would you recommend?
For my everyday writing I use Google Docs which allows me to freely share and collaborate without the added cost of buying software and it is OS agnostic. For the book I am using MS word which for the most part is dictated by the publisher/ editor. No Starch has a standardized style template they use and applying that to a google doc is pretty much impossible.
Depending on your publisher there will be a designer assigned to your book to do layout, so do not worry about inDesign or layout, though your vision is important since it is your content but every publisher is different.
I would also really love to know the answer to this. I'm considering writing a lab manual for a class I teach and I have no idea what software to use. Should I go with simple Microsoft Word or the really advanced inDesign. Or should I do without wysiwyg and use Tex and just deal with having less control on images? Would love to know what you used Derek.
Most SF products are open source. Will the same be true of a this book, or is it only available in print?
The book itself is not open source, Though it is based off of our instructional materials called Hot Sheets around Processing.
You can find them here
The book will be in ebook format as well.
Derek, Thank you for your reply. I probably should have added the following; 1) I intend to publish the book myself. I expect the book to be 300 - 400 pages long. 2) The book is highly technical (lots of formulas etc). 3) Having investigated several publishers, I have discovered that an author only gets about 5 - 7 % (of sale price) in royalties.
This makes the effort to write such a large and technical book not worthwhile. If I self-publish I can distribute the book through many different channels and also I can determine my own price - with close to a 100% of the profits being returned to me, (depending who and how I get others involved in the distribution process).
There are several different DTP application available, I have considered Adobe InCopy and InDesign but they are very expensive. There are some very cheap options such as Scrivener (approx. USD$40) which I am still investigating. If any one has any comments on Scrivener I'd be very keen to hear of their experiences.
Thank you again for your input - any further comments would be welcomed.
Outstanding! Looking forward to it.
achivement get - published author!
Actually I've been working in processing alot myself lately, though more for software than hardware use. Recently moved into IntelliJ to better export finished applications, and top of my list is importing the Processing core into my programs :) processing is a very simple beginner language, but when you really work with it, it's quite powerful.
Congratulations, Derek. When is the sequel due?
Thank you and keep your eyes open...
Trilogies are all the rage these days!