scriptorium 0.0.3 → 0.7.2

data/doc/myuserdoc/tweak.rb

@@ -0,0 +1,18 @@
+text = File.read("userdoc-toc.txt")
+
+pieces = text.split("\n\n")
+
+pieces.each.with_index do |txt, i| 
+  f = File.new("ch-#{'%0d' % i}.lt3", "w")
+  lines = txt.split("\n").map {|x| "  " + x }
+  f.puts ".comment"
+  f.puts lines
+  f.puts ".end\n "
+
+  f.puts lines[0].sub!("  xx.", ".chapter")
+  f.puts "\n "
+  lines[1..-1].map! {|x| x.sub!(/^/, ".sec ") }
+  lines[1..-1].each {|line| f.puts line + "\n " }
+  f.close
+end
+

data/doc/myuserdoc/userdoc-toc.txt

@@ -0,0 +1,88 @@
+xx. Core Concepts
+    What is Scriptorium?
+      - Static files
+      - What are views? and why?
+      - What is a repository?
+      - How does deployment work?
+    What is Livetext?
+      - Why Livetext?
+      - Syntax in brief (1-2 paragraphs)
+
+xx. Getting Started
+    Quick installation (gem install)
+    Interactive setup
+      - create repo
+      - create first view
+      - other commands
+      - the sample view
+      - first blog post
+    Basic Configuration
+    Checking dependencies
+    The "standard" theme (only one for now)
+
+xx. The Front Page
+      - containers and their uses
+      - configuring header
+         - banner
+         - navbar
+      - configuring a sidebar
+      - the main container: post index
+    Widgets
+      - Links
+      - Pages
+      - Featured Posts
+
+xx. Deployment & Hosting
+    Local Development
+    Server Deployment
+    Domain Configuration
+    SSL Setup
+
+xx. LiveText Basics
+    What is LiveText?
+    Basic Syntax
+      - inline formatting: boldface, italics, etc.
+      - simple dot commands (with/without parameters)
+      - comments
+      - dot commands taking a body and .end
+      - predefined variables
+      - predefined functions
+      - user variables
+      - writing your own dot commands and functions in Ruby
+    The Plugin for Scriptorium
+    Writing Posts
+
+xx. Managing posts
+      - create 
+      - delete
+      - link
+      - unlink
+      - featured
+
+xx. Managing Pages
+      - Used in navbar
+      - Used in Pages widget
+      - Internal links
+      - Subdirectories under pages/
+
+xx. Customization
+      - Themes and Styling (cloning)
+      - Templates
+      - Widgets and Features
+
+xx. Advanced Features
+    Reddit Integration
+    Social Media Features
+
+xx. Troubleshooting
+    Common Issues
+    Dependency Management
+    Error Messages
+    Getting Help
+
+xx. Reference
+    Command Reference
+    Configuration Files
+    LiveText Reference
+    API Reference
+    View Tree Structure

data/doc/old-posts/0001-elixir-conf-2014.lt3

@@ -0,0 +1,24 @@
+.mixin liveblog
+
+.post 1
+
+.title Elixir Conf 2014
+.pubdate 2014-07-29
+.views computing austin
+.tags 
+
+.teaser
+Last week in Austin, I attended the world's first Elixir conference. It was very
+energizing!
+.end
+
+With only 105 people attending, the vibe was that of a Ruby conference 10 or more
+years ago. Jose Valim, the language creator, was there; two Erlang heavyweights
+were also in attendance -- Robert Virding and Francesco Cesarini.
+
+There were many Rubyists there, of course, but I will only mention myself, Dave
+Thomas, and Jim Freeze. The three of us were also at the first Ruby conference
+in 2001.
+
+This will be an exciting ride. I'll keep you informed.
+ 

data/doc/old-posts/0002-programmers-and-word-processing.lt3

@@ -0,0 +1,150 @@
+.mixin liveblog
+
+.post 2
+
+.title Programmers and word processing
+.pubdate 2014-09-17
+.views computing writing
+.tags 
+
+.teaser
+The other day, I was thinking about the mechanics of writing. Not grammar, spelling, and punctuation,
+but the actual work flow involved.
+.end
+
+.pin computing
+
+Specifically, I was trying to gather my thoughts on why writing a software book using Microsoft Word
+is so incredibly painful. (Granted, I have used Word or similar tools to write fiction and shorter pieces.)
+
+It wouldn't seem so at first, would it? Isn't word processing software the savior of the writer? Wouldn't
+we be using typewriters without it?
+
+Well, yes and no. Several facts have to be considered here: 1. I'm a programmer (and a somewhat old-fashioned
+one, who almost always goes straight to the command line). 2. When you write a programming book, there is 
+often a need to manipulate the text in various ways you otherwise wouldn't. This is even more true for a 
+"larger" document like a book of a few hundred pages. 3. Programmers by nature want the computer to do things
+for them. It's natural to want to write code to manipulate your text.
+
+the typewriter and the modern word processing suites. It's a forgotten generation of software -- forgotten
+partly because computer guys were mostly the only ones who ever used it, and today even the younger software
+professionals don't remember it.
+
+I'm talking, of course, about what we commonly call a _text formatter_. Many of you who read this will have
+much more experience here than I do, but I'll share from my own limited knowledge and experience.
+
+I'll assume some of my readers have no idea what I'm talking about. A text formatter is just a piece of software
+that takes plain text (mixed with some metadata relating to formatting) and produces a formatted document. Think
+of it as a little like HTML, but usually without nesting. Typically if a line of text started with a dot, it 
+would be interpreted as a formatting instruction rather than as raw text.
+
+This was before there were laser printers (or at least I had never heard of them). Although I don't go back to
+the early days of Unix utilities like troff and nroff, I did know about them and have touched them (in the early
+to mid-1980s). I've even used a similar tool on an IBM mainframe (called Scripsit, as I recall). I'm certain 
+there were similar things on the DEC-10 and many other forgotten platforms. Even in the late 80s, when word
+processing was coming into its own, many of the tools still were not fully "WYSIWYG." 
+
+Remember that term? "What You See Is What You Get"? It was coined because this was rather a new concept. With
+text formatters, what you saw was _not what you got.
+
+Even back then, there were more sophisticated tools. TeX was around, though I didn't know it and never really
+saw it. LaTeX I suppose came later. At that time, dot matrix printers were not uncommon -- and on the mainframes,
+even line printers were still common (typically without even lowercase letters). 
+
+As for "really fancy" output such as TeX could produce, I don't know that our comp sci department _or our 
+computer center could really print such material. If I used a printer that could print italics and boldface text,
+I was ecstatic.
+
+This is starting to sound like the stories about walking to school in the snow, right? And it was uphill both
+ways? That's not my point. The hardware was primitive, yes, and the software was primitive, too.
+
+When WYSIWYG came along, suddenly armies of "ordinary people" escaped their typewriters and learned the joys of 
+backspace and delete. Programmers benefited, too. And yet... 
+
+I won't even go into the disadvantages of the GUI in general. That could be a controversy in itself. Suffice to
+say that I earned two degrees in computer science and hardly even _touched a mouse. In fact, I don't think I 
+actually owned a mouse until four or five years later. I remember with fondness the online signature of one
+Arno Schaefer: *(How do I type) `("for i in \*.dvi do xdvi i done") *(in a GUI?) But that is a little outside our
+discussion here.
+
+From a programmer's perspective, a primary failing of the word processor in general is that it stores documents
+in a binary format rather than text. It is difficult or impossible to peer into those files from the outside.
+
+That means that all of the traditional Unix utilities, so useful for text files, are useless for Word documents
+and similar file types. Which utilities? That depends on how well you know Unix and how much time you have 
+spent at the command line.
+
+The first utility, of course, is the text editor itself. If you want fancy formatting and WYSIWYG, the traditional
+editors like vim and emacs won't seem that great to you. But if you want something "lean, mean, and easy" -- 
+maybe these are pretty great after all. (Granted, nothing ever seems "cool" until you learn to use it effectively.)
+
+Personally I use vim (although I freely admit that emacs is more powerful, just as I admit LISP is more powerful
+than any of my favorite languages). It loads into memory very quickly, it loads files quickly, it saves them
+quickly, and it never crashes. Navigation is fast and simple (again, if you know what you're doing). I've never
+done real scripting in vim, but I have sometimes used macros and such.
+
+But the editor is only the beginning. Some of the utilities I have used are: grep, wc, fold, cut, colrm, 
+diff, sdiff, csplit, expand, head, tail, less, more, cut, sort, split, strings, tee, tr, and uniq. Sometimes I have
+even used awk, sed, and m4. I can combine files, split them, search them, and manipulate their contents at will.
+
+I can redirect standard input, standard output, and standard error for these utilities. I can use pipes with them.
+Many of these tools understand regular expressions. I can build scripts that perform multiple commands, even with 
+some simple branching and looping logic involved.
+
+None of these things are possible in general with Word documents. None of these tools or techniques will work well
+with such a file format.
+
+But let's go a step farther... I'm a programmer, after all. I principally work in Ruby, which is good for text
+processing (far more powerful and friendly than bash or awk, for instance).
+
+I have written programs that could search and/or replace only in the body of the text, only in the source code,
+or in both. I have written programs to extract code fragments from the text, to insert them, to syntax-check them,
+and to format them.  I've written programs to create test cases, to syntax-check code, and to reorder (and renumber)
+sections and other items. I've written code that will honor the file format (and code fragments) and spell-check 
+the document, naturally honoring all the technical terms and abbreviations unique to my topic. I've written code 
+to extract a table of contents, lists of figures, and lists of code listings. I've written code to compare the 
+sizes of different sections, code to check cross-references, and code to suggest keywords for the index.
+
+Is all this overkill? You could argue that. Some of these things are doable in MS Word, after all. But you have to
+do everything _their_ way; you can't tweak or customize the functions; and you can't turn off all the features you
+don't need or want. Furthermore, you can't automate it, you have to use the mouse, and sometimes it just crashes or
+malfunctions for a reason you may or may not figure out.
+
+There are many solutions, of course. If you know TeX, that is probably the ultimate tool; and there are add-ons 
+such as LaTeX and Lyx to make it easier. I've never learned any of this; for most of my purposes, it would be a 
+case of killing a mosquito with a hand grenade. On the other hand... if I were writing a calculus textbook, as I 
+never will, I would want something like that to handle all the mathematical notation.
+
+As a side note, I've never used Lyx. But I've heard it is a nice compromise between the two paradigms -- a WYSIWYG
+editor that also offers low-level access to the raw markup.
+
+What's interesting is that people often "roll their own" solutions. I have done it myself (although I principally
+worked with plain HTML), and I have seen it done by others more than once. It's natural, as programmers are always 
+looking for an easier or better way to do things.
+
+Once in a while, a programmer will build a solution that is also intended to benefit others who think the same way.
+An excellent example is the relatively new _Softcover_, created by Michael Hartl (https://www.softcover.io/).
+I've only begun to learn it myself, but my initial impression is that what troff was in the 70s, softcover will be
+in only a year or two. It looks to me like a powerful text formatter for the 21st century -- a tool that will let
+the author/programmer do what he wants without getting too much in the way.
+
+Softcover was designed (in my opinion) the "right way" -- that is, it was first built for a specific purpose, and
+during that process, ideas were generated, and lessons were learned. This enables the developer to avoid false moves,
+design flaws, and "dead ends." Remember that, in the same way, Ruby on Rails was first an application (Basecamp, as 
+I recall) before it was abstracted and generalized into a framework.
+
+Softcover does other things right as well. It isn't just a tool or framework, but also a publishing platform for
+ebooks. There is at least one print book published this way as well, and I expect more.
+
+When programmers write, the readers are often programmers as well. And we are certainly (on the whole) heavy 
+consumers of electronic reading material. Only one American in four uses any kind of ebook reader; but do you know
+of even a single software person who doesn't use one?
+
+So it's a tool, and it's a publishing platform. The business model permits the author to keep a high percentage of 
+the sale price of the book. All this assumes, of course, that the author is actually capable of producing quality
+material without the help of the host of individuals at a traditional publishing house. But I've noticed that this
+often can be done, especially if the author seeks a little outside help now and then.
+
+So I see Softcover as a tool, a platform, and community that connects writers to readers (and to each other). You
+might consider checking it out.
+

data/doc/old-posts/0003-how-to-turn-your-brain-sideways.lt3

@@ -0,0 +1,43 @@
+.mixin liveblog
+
+.post 3
+
+.title How to turn your brain sideways
+.pubdate 2015-07-17
+.views computing
+.tags 
+
+.teaser
+If you think in OOP, as I do, then functional programming is a great way to
+shake your neurons out of their complacency. 
+.end
+
+If you already know FP, you may be smiling a little. Maybe you learned it a
+long time ago. Maybe it's natural to you. To me, it isn't.
+
+The three basic stumbling blocks for me are:
+
+.list
+The concept that all data are immutable
+The concept of tail recursion as opposed to looping
+The concept of pattern matching as opposed to traditional assignment
+.end
+
+Yet, of course, those are perhaps the very foundations of functional programming.
+In theory, it all makes sense to me; but it doesn't yet stick to my brain. 
+
+In many ways, it is literally like learning a foreign language. Not just varying
+syntax and slightly different semantics. If you know C++, Java, Object Pascal, or
+any host of other languages, then you know that these feel "similar" in some ways.
+
+Here's an analogy for you. If you have studied French, Spanish, and Italian, you
+have noticed they are of the same "family." They're not identical by any means, 
+but you can often transfer knowledge from one area to another. That's how OOP
+languages feel to me.
+
+On the other hand, functional languages feel to me as if I were trying to learn
+an Asian tongue like Japanese or Korean. The differences are not just fairly minor
+differences in syntax and semantics, but a difference in paradigm.
+
+Learning Elixir is making me feel young and incompetent again. This is a nice break
+from feeling old and incompetent.

data/doc/old-posts/0004-upcoming-lone-star-ruby-conference.lt3

@@ -0,0 +1,26 @@
+.mixin liveblog
+
+.post 4
+
+.title Upcoming Lone Star Ruby Conference...
+.pubdate 2015-07-20
+.views computing austin
+.tags 
+
+.teaser
+After a short hiatus, LSRC is back! Join us in Austin next month. Speakers have 
+just been announced. 
+.end
+
+I submitted a proposal, but it wasn't accepted this time. But many other fine people
+will be presenting there -- see http://LoneStarRuby.org
+
+As a bonus, there is a Phoenix training session on the day before. Wait, what? Phoenix
+isn't Ruby. It's Elixir.
+
+That's true. But Phoenix and Elixir are cool, too. And Jim Freeze who organizes LSRC
+also put together the first Elixir Conference last year (and the upcoming one in 2015).
+So we're keeping it in the family.
+
+I hope to see you at *[all three] of these events.
+

data/doc/old-posts/0005-elixir-conf-2015-announced.lt3

@@ -0,0 +1,17 @@
+.mixin liveblog
+
+.post 5
+
+.title Elixir Conf 2015 announced
+.pubdate 2015-07-22
+.views computing
+.tags 
+
+.teaser
+Elixir Conference 2015 will be in early October in Austin, Texas! 
+.end
+
+It's sure to be a great time. The CFP will be open until mid-August. You're
+encouraged to submit.
+
+Really looking forward to this one.

data/doc/old-posts/0006-ruby-for-dinosaurs.lt3

@@ -0,0 +1,30 @@
+.mixin liveblog
+
+.post 6
+
+.title Ruby for Dinosaurs...
+.pubdate 2015-07-23
+.views computing
+.tags
+
+.pin computing
+
+.teaser
+I have a good friend I've known since college. He was much older than I was (though
+now somehow we are much closer together in age). He was a mentor to me with regard 
+to computers and other things. 
+.end
+
+He was a brilliant programmer and actually wrote a C compiler in the days before the
+IBM PC. He's now past 70 if I am not mistaken. Lately, he says technical things make 
+him tired.
+
+But as a Ruby enthusiast, I felt obligated to pass on some of the insights I had in
+the last 16 years. Will it bring him out of retirement and get him to write code
+again? Maybe not. But I had been meaning for years to write this little intro, and so
+I finally did.
+
+Here's the PDF of $$link["Ruby for the Old-Time C Programmer"|assets/rubydino.pdf]
+
+If you know someone who thinks in C and never learned OOP, you might share it with 
+that person as well. If you have comments, feel free to email me.

data/doc/old-posts/0007-phoenix-isnt-rails.lt3

@@ -0,0 +1,90 @@
+.mixin liveblog
+
+.post 7
+
+.title Phoenix isn't Rails
+.pubdate 2015-07-27
+.views computing 
+.tags
+
+.teaser
+I don't know Elixir very well at all. But I've started to learn Phoenix now. The
+first thing to know: Phoenix is <i>not</i> Ruby on Rails (nor is it "Elixir on Rails").
+.end
+
+I began my learning experience by dutifully crunching through the tutorial and
+making my share (at least) of newbie mistakes. (Disclaimer: I'm not a web guy. I 
+don't natively "think" in those terms and perhaps never will.)
+
+At some point in the hello-world example, I stopped and did a count of the files
+under my tree. It will become clear in a moment why this was a little naive and 
+careless.
+
+At any rate, I think <tt>find . | wc -l</tt>reported 11,648 files to me. I found this
+a bit confusing and puzzling, and I didn't think it through.
+
+I chatted with Chris McCord and another guy I don't think I've met. This is a summary:
+
+<pre>
+    hal_9000: chrismccord: I have a question about the philosophy/design 
+              of phoenix - if you have time/inclination and the answer is not too involved
+    
+    chrismccord: hal_9000: shoot
+    
+    hal_9000: first of all, i’m not a web guy - i’ve played with rails and several 
+              other things - wrote a few small apps.  One thing that appealed to me 
+              about Sinatra was how “lightweight” it was compared to Rails — you can 
+              write a primitive Sinatra app in a single file.
+    hal_9000: i “sort of” expected that Phoenix might be that way — but a find piped 
+              to wc showed me that a hello-world app has more than 11,000 files in it. 
+              why in general is that?
+    
+    chrismccord: hal_9000: remove the node_modules folder and re-run ws
+    chrismccord: it's all nodejs for the asset building
+    chrismccord: hal_9000: we are lightweight. It's a misconception I have to keep correcting. 
+                 We are much closer to sinatra than rails
+
+    hal_9000: hmm, i don’t even know nodejs of course
+    hal_9000: chrismccord: thanks, i had a feeling i was missing something for sure
+
+    chrismccord: hal_9000: you could write an app in a single file, but no-one does that, 
+                 because we don't write production software in a single file
+    chrismccord: hal_9000: It is also worth mentioning there is also nothing global in 
+                 phoenix. We are not a monolith like rails
+    
+    jeregrine: hal_9000: something to keep in mind here is that phoenix assumes you are 
+               writing production software. Eventually you will need to touch every file, otherwise 
+               it wouldn't generate the file 
+    
+    hal_9000: chrismccord: ok, thanks, i will look more closely. i’m impressed with what i see
+    
+    jeregrine: hal_9000: if you are like me and have used sinatra for production software you 
+               probably discovered you ended up writing a slightly smaller version of rails 
+
+    hal_9000: jeregrine: that makes perfect sense
+    
+    jeregrine: hal_9000: if you only need a single route/api call, and are certain it will never grow, 
+               you could VERY easily get away with just plug and it's router
+    jeregrine: hal_9000: http://hexdocs.pm/plug/Plug.Router.html for reference.
+    
+    hal_9000: chrismccord: i grasp it now, sorry for the noise  
+
+    jeregrine: hal_9000: lemme know if you have any questions, this is something we need to be better at 
+               communicating. We are not rails
+
+    chrismccord: hal_9000: no worries. Sorry if my response was rash too. I just have to fight a lot of 
+                 "phoenix is bloated" comments because people assume it is given my Rails background and 
+                 the comparisons with rails
+
+    hal_9000: chrismccord: no, your response was not rash at all
+</pre>
+
+So first of all: I didn't pay attention to what I was doing when I did my file count.
+
+But the real takeaway here is: Phoenix isn't bloated, and more importantly, <i>Phoenix isn't Rails</i>.
+The philosophy seems to be more "minimalistic" as I had hoped.
+
+And of course, we all know that Elixir isn't Ruby. I won't belabor that point.
+
+On the other hand, I do find (so far) that Plug is a lot like Rack. That's a good thing, because I
+always thought Rack was sheer genius. More on that as I learn.

data/doc/old-posts/0008-concerning-the-term-monkeypatching.lt3

@@ -0,0 +1,105 @@
+.mixin liveblog
+
+.post 8
+
+.title Concerning the term "monkeypatching"
+.pubdate 2015-08-10
+.views computing 
+.tags
+
+.pin computing
+
+.teaser
+There have been many "dark days" in the Ruby community, some much darker than others.
+.end
+
+Guy Decoux died, \_why the lucky stiff\_ left us (without dying), Jim Weirich died. (Yes, I count
+actual deaths as the darkest moments of all.)
+
+But I count another dark moment that many of you will not. When I had been using Ruby a
+little more than six years, in December 2005, the term "monkeypatching" was introduced
+into our circle.
+
+It was a post by Drew Mills, quoting a blog from a Python person who apparently hated Ruby.
+I don't blame Drew. I don't suppose I "blame" anyone. But I regret that this slang has entered
+our culture.
+
+The post Drew quoted was this:
+
+.quote
+  It's the second generation that's going to be less enthused,
+  that's going to stare in bafflement at these classes that
+  mysteriously spawn methods, and trying to figure out what's
+  going when there's an exception in dynamically generated
+  code. You can monkeypatch code in Python pretty easily, but we
+  look down on it enough that we call it "monkeypatching". In
+  Ruby they call it "opening a class" and think it's a cool
+  feature. I will assert: we are right, they are wrong.
+.end
+
+Before I go on to my main point, I'll make an observation that is arguably much more interesting.
+If you read again, it sounds like the Python person (Ian Bicking) was talking about dynamic method
+dispatch (the use or abuse of method_missing) rather than actual open classes.
+
+Someone later in that thread decried the "ignorance" of Bicking with regard to this -- that he didn't
+even know enough Ruby to know the difference between dynamic dispatch and open classes. I
+wonder if the original pythonism meant something different? Since I never completed my Python
+studies, I can't comment.
+
+At any rate: Back to my story.
+
+I still recall the revulsion I felt, almost physical nausea, when I read this the first time. That's probably
+a somewhat extreme response on my part.
+
+I regarded open classes as a programming technique that is potentially very powerful but easy to misuse.
+This sounds like a "good and yet bad" argument. But let me rephrase that sentence.
+
+Open classes are a technique that is potentially very powerful _(and therefore) easy to misuse. That is
+the point. Any tool that is powerful enough is prone to misuse by people who are unskilled.
+
+The term "monkeypatching" is obviously a pejorative term. Upon seeing it, my first thought was, "I am
+not a monkey, and I am not 'patching' anything."
+
+After all, that is the implication. The term implies that the developer is a monkey, and that the work he is
+doing is sloppy or shoddy. It is an insult both to the quality of the developer's work and to the developer
+himself.
+
+So it bothered me because it was a pejorative and it was insulting to us as programmers. It was also
+(arguably) an insult to Ruby itself and therefore by extension an insult to Matz.
+
+I dislike being clannish, though perhaps sometimes I am. After all, Ruby is not (supposed to be) anyone's
+religion or cultural heritage. It's only a programming language, and I think it's very much like Python. But it
+also bothered me that this neologism originated _outside our community, in particular with the Python
+community.
+
+Generalizations are always wrong. (Yes, that's a joke.) And stereotypes as such are at least useless if not
+actually hurtful. And yet I always heard about the arrogance and rudeness of Python programmers, and I
+occasionally saw real evidence of it. And though I dislike the word "nice" in general, I always found it interesting
+that Ruby coders were labeled as "nice" (as in the abbreviation MINASWAN, "Matz is nice, and so we are nice").
+
+So when this usage was introduced, I felt rather as though someone had opened my front door and dumped a
+large piece of dog manure onto my carpet. What is worse, it has wormed its way into common usage in our
+community, even in documentation. A lot of this happened in the early days of Rails, when fate dumped a huge
+influx of newbies onto the Ruby community. Not to disparage the Rails people in general, but at the time this
+felt much the same as it did back when AOL (America Online) made its debut and dumped millions of (insert
+noun here) into the Internet and Usenet communities.
+
+It's impossible to stop this usage now (like so many other usages in the English language having nothing to do
+with computing). But I still protest, and I still stand against it.
+
+The term "monkeypatching" appears only once in more than 800 pages of _[The Ruby Way]. It occurs when  I
+say I don't condone this term, and it won't be used further in the book.
+
+As an aside: The "refinements" which exist in recent versions of Ruby make open classes stricter and safer. I'll blog
+about that later. But this isn't much of a technical post. It's just a reminiscence and a rant.
+
+So basically I hate the term "monkeypatching." I am polite to people who say it to me (e.g., in asking a question), but
+secretly I want to just ignore them.
+
+The last time I saw Jim Weirich, in New Orleans, he and I talked about this. He agreed it was a pejorative term,
+and it was a shame it had entered the common dialect, though there was really nothing to do about it. But being
+much more level-headed and good-natured than I am, he wasn't bothered much by it.
+
+I really miss Jim, by the way. He was a truly brilliant developer and an amiable and wonderful person in general.
+If it would bring him back, I would gladly change the book's name to _[The Art of Monkeypatching].
+

data/doc/old-posts/0009-announcement-coming-soon.lt3

@@ -0,0 +1,20 @@
+.mixin liveblog
+
+.post 9
+
+.title Announcement coming soon...
+.pubdate 2015-08-11
+.views computing
+.tags
+
+.teaser
+Maybe this will stir your curiosity a little. I hope it does.
+I've started working on a project with someone else, and I 
+think it will be really worthwhile.
+.end
+
+This will be launched within 48 hours and announced at the
+Lone Star Ruby Conference in Austin, Texas (October 15).
+Maybe it will be leaked a little before then, too.
+
+Sit tight 48 hours or so...