scriptorium 0.0.3 → 0.7.2

data/doc/imported/0002-programmers-and-word-processing/source.lt3

@@ -0,0 +1,146 @@
+.h1 Programmers and word processing
+
+.set post.num = 0002
+.set post.slug = programmers-and-word-processing
+.set post.date = 2014-09-17
+.set post.title = Programmers and word processing
+.set post.tags = 
+.set post.views = computing writing
+.set post.published = yes
+.set post.deployed = no
+
+The other day, I was thinking about the mechanics of writing. Not grammar, spelling, and punctuation,
+but the actual work flow involved.
+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/imported/0003-how-to-turn-your-brain-sideways/metadata.txt

@@ -0,0 +1,7 @@
+    num  0003
+  title  How to turn your brain sideways
+   date  2015-07-17
+pubdate  2015-07-17
+  views  computing
+   tags  
+ pinned  

data/doc/imported/0003-how-to-turn-your-brain-sideways/post.html

@@ -0,0 +1,60 @@
+<!DOCTYPE html>
+<html>
+<head>
+  <meta charset="utf-8">
+  <title>How to turn your brain sideways</title>
+  <meta name="generator" content="Scriptorium Import">
+  <meta property="og:title" content="How to turn your brain sideways">
+  <meta property="og:locale" content="en_US">
+  <meta property="og:type" content="article">
+  <meta property="article:published_time" content="2015-07-17">
+</head>
+<body>
+  <article>
+    <header>
+      <h1>How to turn your brain sideways</h1>
+      <time datetime="2015-07-17">July 17, 2015</time>
+    </header>
+    
+    <div class="content">
+      <p>
+If you think in OOP, as I do, then functional programming is a great way to
+shake your neurons out of their complacency. 
+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.
+
+<p>
+The three basic stumbling blocks for me are:
+
+<p>
+<ul>
+<li>The concept that all data are immutable</li>
+<li>The concept of tail recursion as opposed to looping</li>
+<li>The concept of pattern matching as opposed to traditional assignment</li>
+</ul>
+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. 
+
+<p>
+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.
+
+<p>
+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.
+
+<p>
+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.
+
+<p>
+Learning Elixir is making me feel young and incompetent again. This is a nice break
+from feeling old and incompetent.
+    </div>
+  </article>
+</body>
+</html>

data/doc/imported/0003-how-to-turn-your-brain-sideways/source.lt3

@@ -0,0 +1,40 @@
+.h1 How to turn your brain sideways
+
+.set post.num = 0003
+.set post.slug = how-to-turn-your-brain-sideways
+.set post.date = 2015-07-17
+.set post.title = How to turn your brain sideways
+.set post.tags = 
+.set post.views = computing
+.set post.published = yes
+.set post.deployed = no
+
+If you think in OOP, as I do, then functional programming is a great way to
+shake your neurons out of their complacency. 
+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:
+
+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
+
+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/imported/0004-upcoming-lone-star-ruby-conference/metadata.txt

@@ -0,0 +1,7 @@
+    num  0004
+  title  Upcoming Lone Star Ruby Conference...
+   date  2015-07-20
+pubdate  2015-07-20
+  views  computing austin
+   tags  
+ pinned  

data/doc/imported/0004-upcoming-lone-star-ruby-conference/post.html

@@ -0,0 +1,42 @@
+<!DOCTYPE html>
+<html>
+<head>
+  <meta charset="utf-8">
+  <title>Upcoming Lone Star Ruby Conference...</title>
+  <meta name="generator" content="Scriptorium Import">
+  <meta property="og:title" content="Upcoming Lone Star Ruby Conference...">
+  <meta property="og:locale" content="en_US">
+  <meta property="og:type" content="article">
+  <meta property="article:published_time" content="2015-07-20">
+</head>
+<body>
+  <article>
+    <header>
+      <h1>Upcoming Lone Star Ruby Conference...</h1>
+      <time datetime="2015-07-20">July 20, 2015</time>
+    </header>
+    
+    <div class="content">
+      <p>
+After a short hiatus, LSRC is back! Join us in Austin next month. Speakers have 
+just been announced. 
+I submitted a proposal, but it wasn't accepted this time. But many other fine people
+will be presenting there -- see http://LoneStarRuby.org
+
+<p>
+As a bonus, there is a Phoenix training session on the day before. Wait, what? Phoenix
+isn't Ruby. It's Elixir.
+
+<p>
+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.
+
+<p>
+I hope to see you at <b>all three</b> of these events.
+
+<p>
+    </div>
+  </article>
+</body>
+</html>

data/doc/imported/0004-upcoming-lone-star-ruby-conference/source.lt3

@@ -0,0 +1,24 @@
+.h1 Upcoming Lone Star Ruby Conference...
+
+.set post.num = 0004
+.set post.slug = upcoming-lone-star-ruby-conference
+.set post.date = 2015-07-20
+.set post.title = Upcoming Lone Star Ruby Conference...
+.set post.tags = 
+.set post.views = computing austin
+.set post.published = yes
+.set post.deployed = no
+
+After a short hiatus, LSRC is back! Join us in Austin next month. Speakers have 
+just been announced. 
+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/imported/0005-elixir-conf-2015-announced/metadata.txt

@@ -0,0 +1,7 @@
+    num  0005
+  title  Elixir Conf 2015 announced
+   date  2015-07-22
+pubdate  2015-07-22
+  views  computing
+   tags  
+ pinned  

data/doc/imported/0005-elixir-conf-2015-announced/post.html

@@ -0,0 +1,30 @@
+<!DOCTYPE html>
+<html>
+<head>
+  <meta charset="utf-8">
+  <title>Elixir Conf 2015 announced</title>
+  <meta name="generator" content="Scriptorium Import">
+  <meta property="og:title" content="Elixir Conf 2015 announced">
+  <meta property="og:locale" content="en_US">
+  <meta property="og:type" content="article">
+  <meta property="article:published_time" content="2015-07-22">
+</head>
+<body>
+  <article>
+    <header>
+      <h1>Elixir Conf 2015 announced</h1>
+      <time datetime="2015-07-22">July 22, 2015</time>
+    </header>
+    
+    <div class="content">
+      <p>
+Elixir Conference 2015 will be in early October in Austin, Texas! 
+It's sure to be a great time. The CFP will be open until mid-August. You're
+encouraged to submit.
+
+<p>
+Really looking forward to this one.
+    </div>
+  </article>
+</body>
+</html>

data/doc/imported/0005-elixir-conf-2015-announced/source.lt3

@@ -0,0 +1,16 @@
+.h1 Elixir Conf 2015 announced
+
+.set post.num = 0005
+.set post.slug = elixir-conf-2015-announced
+.set post.date = 2015-07-22
+.set post.title = Elixir Conf 2015 announced
+.set post.tags = 
+.set post.views = computing
+.set post.published = yes
+.set post.deployed = no
+
+Elixir Conference 2015 will be in early October in Austin, Texas! 
+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/imported/0006-ruby-for-dinosaurs/metadata.txt

@@ -0,0 +1,7 @@
+    num  0006
+  title  Ruby for Dinosaurs...
+   date  2015-07-23
+pubdate  2015-07-23
+  views  computing
+   tags  
+ pinned  

data/doc/imported/0006-ruby-for-dinosaurs/post.html

@@ -0,0 +1,43 @@
+<!DOCTYPE html>
+<html>
+<head>
+  <meta charset="utf-8">
+  <title>Ruby for Dinosaurs...</title>
+  <meta name="generator" content="Scriptorium Import">
+  <meta property="og:title" content="Ruby for Dinosaurs...">
+  <meta property="og:locale" content="en_US">
+  <meta property="og:type" content="article">
+  <meta property="article:published_time" content="2015-07-23">
+</head>
+<body>
+  <article>
+    <header>
+      <h1>Ruby for Dinosaurs...</h1>
+      <time datetime="2015-07-23">July 23, 2015</time>
+    </header>
+    
+    <div class="content">
+      <p>
+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. 
+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.
+
+<p>
+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.
+
+<p>
+Here's the PDF of <a style='text-decoration: none' href='assets/rubydino.pdf'>"Ruby for the Old-Time C Programmer"</a>
+
+<p>
+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.
+    </div>
+  </article>
+</body>
+</html>

data/doc/imported/0006-ruby-for-dinosaurs/source.lt3

@@ -0,0 +1,27 @@
+.h1 Ruby for Dinosaurs...
+
+.set post.num = 0006
+.set post.slug = ruby-for-dinosaurs
+.set post.date = 2015-07-23
+.set post.title = Ruby for Dinosaurs...
+.set post.tags = 
+.set post.views = computing
+.set post.published = yes
+.set post.deployed = no
+
+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. 
+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 "Ruby for the Old-Time C Programmer"
+
+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/imported/0007-phoenix-isnt-rails/metadata.txt

@@ -0,0 +1,7 @@
+    num  0007
+  title  Phoenix isn't Rails
+   date  2015-07-27
+pubdate  2015-07-27
+  views  computing
+   tags  
+ pinned  

data/doc/imported/0007-phoenix-isnt-rails/post.html

@@ -0,0 +1,116 @@
+<!DOCTYPE html>
+<html>
+<head>
+  <meta charset="utf-8">
+  <title>Phoenix isn't Rails</title>
+  <meta name="generator" content="Scriptorium Import">
+  <meta property="og:title" content="Phoenix isn't Rails">
+  <meta property="og:locale" content="en_US">
+  <meta property="og:type" content="article">
+  <meta property="article:published_time" content="2015-07-27">
+</head>
+<body>
+  <article>
+    <header>
+      <h1>Phoenix isn't Rails</h1>
+      <time datetime="2015-07-27">July 27, 2015</time>
+    </header>
+    
+    <div class="content">
+      <p>
+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").
+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.)
+
+<p>
+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.
+
+<p>
+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.
+
+<p>
+I chatted with Chris McCord and another guy I don't think I've met. This is a summary:
+
+<p>
+<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
+
+<p>
+    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
+
+<p>
+    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 
+
+<p>
+    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  
+
+<p>
+    jeregrine: hal_9000: lemme know if you have any questions, this is something we need to be better at 
+               communicating. We are not rails
+
+<p>
+    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
+
+<p>
+    hal_9000: chrismccord: no, your response was not rash at all
+</pre>
+
+<p>
+So first of all: I didn't pay attention to what I was doing when I did my file count.
+
+<p>
+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.
+
+<p>
+And of course, we all know that Elixir isn't Ruby. I won't belabor that point.
+
+<p>
+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.
+    </div>
+  </article>
+</body>
+</html>