Where Is My Global Warming?

Sitting here in lovely Dodgeville, WI with the temperature at 2 degrees Fahrenheit and a windchill of -10 degrees Fahrenheit, what else could my thoughts turn to than global warming? As I am sure is true of many of us in the Upper Midwest, I am quite keen on the idea of global warming. I want some global warming. The problem is that I’m not seeing any. None, nada, zip.

And it would seem that I am not imagining this lack of blazingly warm temperatures. Here are a few headlines that I saw linked from the Drudge Report today and an extra one for good measure.

“Global Sea Ice Breaks Record High For The Day”

“Dueling Datasets: Satellite Temperatures Reveal the ‘Global Warming Pause’ Lengthens to 18 years 2 months – (218 Months)”

“Carbon dioxide emissions help tropical rainforests grow faster: Study shows trees absorb more greenhouse gas than expected”

Mechanics Of Writing A Book

I have always loved books, so the thought of writing one (or more) has never really been far from my mind. I have been fortunate to have been on the side-lines of the publishing business for a few books, so that whet my appetite even more. I have been a pre-press technical reviewer for a handful of technical programming books from publishers that there’s a good chance you’ve heard of. I have also been a book reviewer for the Slashdot website, where you can find at least two dozen reviews written by yours truly. These activities were a source of encouragement to learn more about books.

Fiction Or Non-Fiction?

I suspect that fiction is the hardest kind of book to write because you not only need to know how to write, but you also need an imagination that will provide you with what to write. As a computer programmer, my imagination is pretty limited, so that leaves non-fiction. Then there is the choice of topic. As a computer programmer and a pastor, I could write about a number of geeky or theological areas. In the end, for my first book, I went with theology and Apostolic Baptism was the result.

Publisher Or Self-Publishing?

The next decision was whether to self-publish or to seek a publishing house to accept a book proposal. Working with a publishing house brings certain benefits and while many of those are attractive, the chances of most authors being accepted is pitifully small, especially if you are not a known name in the writing world. Further, most publishing houses look for more than just an intended outline of a book, they ideally want to see several chapters, at least three, completed to proof-reading condition, before they will commit to your book. As my intended book was not likely to be that large (it came in just under 100 pages in the end) those three chapters would be a reasonable portion of the finished work, so I might as well just keep going by myself after the first three chapters and do it all myself.

Interestingly, I have seen a number of authors start with self-publishing and then get recruited by a publisher when they see the quality of the finished work. In many ways this seems to be the best of both worlds. The publisher gets a book that they can see is a quality work before they pay the author anything. The author gets to deal with a publisher from a position of influence that most new authors do not have and this often results in a better deal for the author, especially in the area of retaining the electronic publishing rights to their work.

Choosing LeanPub

As a geeky kind of fellow and a computer programmer, I have always liked the idea of ebooks. I’ve also got quite an enthusiastic inner-typographer. So whatever solution I went with was going to have to try to satisfy both of these needs. One of the natural tools for producing high-quality printed output is LaTeX. Sadly, it doesn’t work so well with most ereaders. I needed something that could produce ebooks and LaTeX quality printed material. And if it could handle Markdown as well, that would be perfect. I was already using a tool called Pandoc for my sermons, so I wondered if I could use that to create my book. The answer was yes, but there would be a lot of configuration required to get everything looking high-quality. Somewhere around this time, I came across LeanPub and my problems were solved.

LeanPub is an online service for authors where you create books using Markdown, or more specifically Markua, which is a superset of Markdown designed for book publishing. The output from LeanPub is produced in three formats: PDF, EPUB and MOBI. Their book templates are gorgeous and look like they’ve come straight from a high-end book publisher. Even better, they also have the option to produce a high-quality final print PDF that can be directly uploaded to any number of printing services to produce the finished paper book. I was ready to pull out my credit card, but their price is free for the services, only taking a slim commission if you sell through their website.

I am very pleased with the results that I received through LeanPub for my first book and am now in the process of creating more books through them. Understand that I have no business relationship with them, beyond being a satisfied customer, so please take my strong recommendation to look at their services as an honest attempt to steer you right and not to make money off of you.

Organizing Your Book

There are traditional ways of organizing a book that very few people could articulate, but that they would notice immediately if not followed. I found a lot of this information during my initial search for LaTeX stylesheets that would help me with my initial thoughts of self-publishing. While I did not ultimately use those style sheets, the information provided about book layouts and structure were invaluable.

I recall that the most useful LaTeX stylesheet was Memoir. It came with a 600 page user guide, beautifully typeset using Memoir and the guide contains a significant amount of information on how to layout and organize a book. Only after this was explained does the guide proceed to explain how to use Memoir to achieve said layouts.

Content

For a non-fiction book, it’s important to plan your content and ensure that your approach to the subject makes sense. I worked with my Presbyter (a pastor over pastors) to ensure that my approach was solid. I also had a safety net, because one of my proofreaders was also a Presbyter (for a different section of the state) and he verified that I had not made any mistakes with my doctrine. Knowing that I’d verified these points with knowledgeable men was a great relief for me.

The Actual Writing

Writing is hard. And good writing is very hard. And Jerry Pournelle says that if you want to be a real writer you must write and throw away a million words. A book is not the best first writing project for most people. My preparation for writing a book was to have blogged for several years and having written an average of 40 sermons a year for seven years. That amounts to a good number of words of practice.

Proofreaders and Copy Editors

I cheaped out here and skipped retaining a copy editor. I think I got away with it for two reasons. The first reason is that I am pretty picky with my own writing and will re-write a sentence if I don’t like it. And I re-read everything the next time or two I come back to it. I write with my spell checker on and as part of getting ready to send copies out to my proofreaders I ran the entire text through the Hemmingway App. I didn’t follow all of its advice, but it did cause me to consider every sentence in every paragraph to ensure that they worked well together.

Having skimped on the copy editor function, I opted for plenty of proofreaders. I had five proofreaders lined up and got two and a half out of five worth of proofreading. Life happens, so with more proofreaders, I still received a good quantity of proofreading with two of the folks needing to bow out. My two primary proofreaders were published authors and one of them was also a school teacher. One of my proudest moments was when the school teacher handed me back a marked-up copy of the manuscript and told me that there weren’t as many errors as she had expected.

Printed Proof Book

The next step was to create an account at CreateSpace and upload my manuscript. I selected a free cover layout and uploaded my own photographs for the front cover and author picture. Then it was a very simple affair to order a couple of print proofs. Even with postage, this step cost me less than $10, so my financial investment so far is still minimal. The proof books arrived in less than a week and I was greatly impressed by the quality. I had expected there to be an obvious indicator of the proof status of the book, but the only indicator was the word “proof” on the last page before the back cover. The cover print quality was excellent, the binding was solid and the inner manuscript looked just exactly like the high-quality PDF that I had generated from LeanPub.

I took the inexpensive road on the matter of an ISBN. International Standard Book Numbers are expensive in small quantities, so I took advantage of the offer from CreateSpace to assign me one of their ISBNs for free. If I were to ever sell this book through another publisher, I would need to get a new ISBN myself or through the other publisher. At this time, as I still retain all copyrights to the book, I’m not overly worried about this and will revisit the decision should the day come when I sign up with another publisher.

Publishing

The act of publishing your book after you have reviewed the proof version is very straight forward. You just press a button to assert that you accept the proof version. Congratulations, you have published a book. There were more questions after that, but these are all to do with sales channels. At this point, you may now purchase completed copies of your book directly from CreateSpace. After carefully working through the sales channels questions, I just needed to wait a few days (turned out to be closer to a week) for my book to be available through Amazon.com in print or electronic versions.

Conclusion

My conclusion is that self-publishing a book is within the grasp of almost anyone with a computer, an Internet connection and the willingness to learn a few simple new skills. The process was greatly simpler than I had feared it would be after reading up on how to use LaTeX to create your own books. LaTeX is great, but for books that will also be targeted as ebooks, it is less helpful.

I am very pleased with the tools available online for either free or an inexpensive amount. LeanPub is a great service and I recommend them heartily for creating the book and selling electronic versions. CreateSpace printed excellent quality books in a Print On Demand fashion and I am very pleased with my resulting product.

If you feel that you have a book within you that is just itching to be written, now is the best time there has ever been to bring it to fruition.

Wash Your Hands

I mentioned recently that I was back working in corporate America, earning my living as a Java programmer. Part of the experience of returning is seeing what has changed and what hasn’t. Today’s topic is one of the unchanged things.

We have some fairly simple hand-washing guidelines in our home. You wash your hands after using the bathroom, before preparing food, before eating and anytime they get genuinely dirty for some other reason. Not too draconian. I think this shows I’m not some kind of helicopter parent who rushes in with the medicated wipes every few minutes.

It still amazes me that grown men can use the bathroom and then not wash their hands! (I don’t use the ladies bathroom, so I have no data on how that demographic behave in the same circumstance.) Now, I’m not for paranoid levels of hand washing, but I am in favor of some, especially when you are interacting with so many co-workers.

The craziest though are the ones who run some water on their hands and then dry them. This is really bizarre. If they’re going to the effort to be right by the soap dispenser, how do they think it’s a good idea to save ten seconds by ignoring the soap? This is one of the aspects of working in an office building that I did not miss.

Back To Work

After a financial challenge at the church this summer, I am now back to work. No details, sorry. There are some parts of pastoring that are not unlike the making of sausage or the passing of laws, in that you really don’t want to watch what happens during the process.

The good folks at TeamSoft, Inc., here in the Madison area, found me a programming contract and I am now gainfully employed and have been for coming up on three months now. This is my third contract through TeamSoft and I continue to be very happy with them as a contracting agency. It doesn’t hurt that they found me a programming opportunity even after I’d not written a line of Java code for exactly two years! That was impressive. The client, who shall remain nameless to protect the innocent, is actually one that I have worked at before. The Java programming community in this area is very small. There is a non-trivial chance that you’ll either go back to a place or that you will work with former co-workers.

Converting back to being bi-vocational has been challenging. Especially doing so in the fourth quarter of the year when everything gets crazy busy in life, school and church. Sleep and family time have been the worst casualties. I typically leave a little after 6:00am and return by about 5:30pm, later if there are errands assigned to me by The Queen Of All She Surveys. Getting up early has never been my strong suite, so I’m really not on speaking terms with my alarm clock right now.

The contract seems to be going well and certainly I have remembered all of the Java that I thought I had forgotten. Thankfully I was still regularly tinkering with scripting and trying out new esoteric programming languages, so my programming instinct was still strong. The client is still using Java 6, which is the version I was using two years ago. This time the tendency of large corporations to lag behind on their Java versions has worked in my favor. I will learn the new features in Java 7 and 8, but, for this client at least, there is no screaming hurry.

The most interesting thing about this current contract is the number of people who remember me either from previous employers or from my one year here at the client eight years ago. My hiring manager remembered me and so that helped smooth the flow of the interview. I have bumped into former co-workers from four different places. Walking around at work is almost a trip down memory lane every day.

Being out of corporate life for two years gives me an interesting perspective now that I’m back. I see quite a few things with fresh eyes. I’ll write about these as I think of them.

Psalm 150:6 – David’s Last Scripture

Let every thing that hath breath praise the LORD. Praise ye the LORD.
Psalm 150:6

King David had much to say on the subject of the Lord, as the known author of over half of the book of Psalms. The Lord had some important things to say about David. He was described by the Lord as “a man after mine own heart” (Acts 13:22), so it seems clear that David had either an acute understanding of, or a natural affinity with the Lord. Understanding this, when David speaks of the Lord, we would do well to listen carefully.

Our verse here is the final psalm and thus the last recorded verse of scripture brought to us by David. While the entire body of scripture by or about David is interesting, there is always something extra interesting about final words. It seems reasonable to expect the final scripture of David to be an important observation about God and I believe that David comes through for us powerfully here.

Like many biblical final words, David’s were words of encouragement. Encouragement to praise and worship the Lord. Perhaps this is surprising to some. After all, David wrote often of the attributes of the Lord. He wrote about his love and his mercy and his protection. He wrote about his majesty and even prophesied of his crucifixion. These are all weighty matters that would have been worthy of being David’s final words. Instead, David reverts to type and his worshippers heart rises up and he tells us that the most important thing we can do is praise the Lord.

David leaves no wriggle-room for those looking to avoid this responsibility. He qualifies his directive by including all who have breath. That’s a solidly inclusive call to action. If you’re breathing, you should be praising the Lord. Because, according to David, that’s the most important thing for us to do. And a great way to round out the book whose name, in Hebrew, means “praises”.

Chappell’s Fifth Law of Programming

(One from the archives. I wrote this ten years ago. I think it still stands.)

After quarter of a century of tinkering with computers and 15 years of programming them to earn my living, I would have to say that some observations are so obvious that I almost feel it’s redundant to speak them. This law would certainly fall within that realm. But, repeated observation of real life in the I.S. industry, on both sides of the Atlantic, has given me cause to believe it necessary to share it.

Simple is good.

As a rule of thumb, when considering designs or development approaches, always err on the side of simplicity whenever possible. Naturally, there are a few things in this life that are blisteringly complicated, but unless you really are a rocket scientist, it’s unlikely that what you do is one of them.

I have seen far too many designs ruined for the lack of simplicity. I have witnessed far too much code that spends more time trying to be clever rather than getting the job done. This law pretty much goes hand in hand with my second law of programming. In order to write code that you can read at 2 a.m. you need to write in a straight-forward fashion. To be able to write straight-forward code, you need a simple design. You need a design that solves the problem at hand and doesn’t play the “how many patterns can I squeeze in one UML diagram” game.

Simplicity also has the added benefit of producing systems that work better and are ready sooner. Simpler systems have less components, less relationships between the components to manage and a much lower chance of adverse behaviour between components. If programmers produced physical items, we’d describe them as streamlined and with less moving parts!

Learning Projects

When learning a new programming language, and I’ve done this more than once, there are certain steps that I typically take in the process. I like to poke around the language web site and then read the getting started tutorials. If I like what I see and it fits my definition of an esoteric programming language, I’ll install it and try my hand at some examples from the tutorials and the classic hello, world program.

These steps seem to be fairly normal for geeks like me and certainly the writing of a hello, world program is enshrined in programming lore and tradition. What is less clear is the recommended path to take after that. Some people complete tutorials, others buy books and work through them and then some dive in and work on a project so they can learn as they go. None of these are bad approaches, but I think that there needs to be something between working through tutorials or books and the big project for learning.

To this end, may I suggest the concept of Learning Projects? This involves writing a series of programs of increasing complexity that incrementally explore the capabilities of the language. I’m looking at replicating a select number of the traditional Unix tools, starting with the simpler ones and expanding from there.

In some ways this is an expanded view of the concept of Learning Tests. Learning tests are tests written by a programmer learning a specific language to help them understand the language they are learning. (I don’t know who first coined the term, but I first heard it from Mike Clark.) There is nothing wrong with learning tests, but when approaching a wide number of languages, not all will have testing frameworks available and, most importantly in my view, the end result is not anything you can use or recycle components of after the learning effort.

Each of the programs in the Learning Projects are sequenced so that the programmer is learning at least one new capability of the language. These capabilities include writing to the standard output, return values, file handling, calculations, directory operations and system calls.

Now, allow me to present my suggested list of Learning Projects:

  • Hello World – This ensures that you can compile and run a program in the language and get standard output somewhere that you can find it.
  • true & false – Ensures that you can pass return values to the operating system.
  • echo – Requires you to process command-line arguments.
  • cat – Requires you to be able to read files and standard input.
  • wc – This requires handling multiple files, loops and arithmetic.
  • touch – Requires you to be able to create a file or update its timestamp.
  • cp – Ensures that you can read from and then write to files.
  • head & tail – Shows the ability to selectively read lines from files.
  • grep – Apply regular expressions to file contents.
  • strings – Shows the ability to selective read bytes from files.
  • od – Read from a file and apply fancy output formatting.
  • rm & rmdir – Be able to delete files and apply recursive deletion.
  • find – Recursive directory descent.

I believe that by the time a programmer has worked their way through this list of Learning Projects, they will be ready and well prepared to take on an interesting project for the purpose of more fully learning their programming language of choice.

Chappell’s Fourth Law of Programming

(One from the archives. I wrote this ten years ago. I think it still stands.)

Software quality, that marvelous thing that every programmer seeks for, as I explain in my third law of programming is all about caring. The only problem is that while “quality is caring”, there have to be actions that this caring drives you to. The first and most important of these actions is unit testing.

Unit testing is the first tollbooth on the road to software quality.

I like to describe unit testing as a toll booth because there is a price to pay for quality. This price is typically non-monetary, but nevertheless very real. The analogy of a road seems to fit software quality very well. Software quality is not a one time thing, it is a journey to a destination. The toll booths on the road to software quality are the price that we must pay, the efforts that we must make, to complete that journey.

Journeys have three phases, the beginning, the travelling and the arriving. Unit testing is the beginning, the price of admission, that first tollbooth which permits you to drive on the road. With toll roads there is no free travel. You pay the toll to get on the road, you pay regularly as you travel along the road and then you pay again to exit the road.

There is no free lunch, or TANSTAAFL as the Perl guys like to say. If you want to do anything well, it’s going to cost you time, effort, money or all three. Software quality follows this fundamental law of life.

Chappell’s Third Law of Programming

(One from the archives. I wrote this ten years ago. I think it still stands.)

During a conversation the other day with a friend of mine (name withheld to protect the innocent) the subject of software quality came up. My friend was very concerned that raising software quality would be an expensive endeavor. They were quite surprised when I told them that quality does not have to be expensive and that it can be close to free.

“How is this?” you ask. Simple, the truth is that:

Quality is caring.

Software quality is like security, you have to build it in from the initial design. Retrofitting is not an option. The way that you build quality into a system is by caring from day one.

When you care, you consider matters more deeply. Your requirements gathering will be a little more careful. Your system design will be a little more thought through and better researched. Your code will be cleaner. Your testing will be more consistent. Your release process will be followed closely. Everything will be better.

There are some things that you cannot measure objectively and there are many aspects of quality that are subjective. This does not mean that they aren’t important and it certainly does not mean that your customers won’t notice. Quality is something that shines through and is visible, even when it’s not measurable. Delivering a quality system shows that you care, because quality is caring.

Chappell’s Second Law of Programming

(One from the archives. I wrote this ten years ago. I think it still stands.)

With all of the benefits of modern computer science research, I find that many programmers still omit one basic thing from their programs. No, I’m not talking about patterns, or POJO’s or any of the other trendy buzzwords that a modern programmer is expected to be knowledgeable of, rather I’m talking about something more basic than that.

I’m talking here about the ability to:

Write code that you can read at 2 a.m.

As any programmer that has taken a support call in the middle of the night will tell you, supporting other people’s code is the worst. At least with your own programs you know why you wrote them and what they’re supposed to be doing, but with someone else’s, you usually don’t have that luxury.

This will usually result in frantically looking at any available code for the program to see if it offers any clues about it’s purpose for existence. Naturally, this is where you discover that the author had the bizarre habit of using single letter variable names for everything and you can’t understand a thing. And not a comment in sight, of course.

The answer, of course, is to assume that someone might need to understand your code in a hurry and that you should write it clearly and concisely, so that it can be read even at 2 a.m. by someone in a frantic hurry, that is still trying to rub all the sleep out of their eyes and who is unlikely to have a copy of the specification around to read.