François Pinard's site

Powered by

1 Summary

This site is maintained by François Pinard. It is currently served by Express. Genuine sources for pages are often reST files or Org notes. Page generation is driven by site.mk files, relying mainly on GNU Make, Docutils, XSL, and Python scripts.

The following sections quickly state the steps which yielded me to the present solution.

2 Web servers

Along the years, the site pages have been served successively by Apache, my own Webert server (in Python), CherryPy (in Python), Yaws (in Erlang), antinode (in JavaScript) and finally Express (in JavaScript). The last two are based on Node, of course. Web servers are always a nice way to explore new programming languages or avenues!

3 Document formats

I usually avoid the direct writing of HTML, the documents are kept in more efficient editing formats. Allout has long been my favorite, to the point I later re-implemented the tool for Vim when I got away from Emacs.

David Goodger's excellent Docutils project seduced me enough that I replaced many Allout files with reST files, and tried to prefer it for my sources, whenever possible.

At some later time, the Tomboy note taker happily replaced Yaws wiki pages for me. It was so efficient at editing time that I learned to keep reST only for bigger or more formal documents. I converted the remaining Allout files.

Then, I used the marvelous WorkFlowy Web folding editor to host a great deal of my notes on the cloud. It allowed a fruitful consolidation of all this information. Yet, the notes were mostly private, I had difficulty really integrating it into my publication habits.

While Tomboy and WorkFlowy are really excellent and very polished tools, which I much liked, the impressive Org tool (an Emacs mode) displaced both in my personal work habits. Among many other virtues, Org's format is much simpler and easier to manage than Tomboy's XML, and it gives me the fine grain control I need over the publishable and private parts of my notes.

4 Page generation

I swung between static generation of Web pages, with bits of dynamism here and there, and full dynamic on the fly generation by the server.

The technique used for generating static HTML pages, as well as the overall aspect of the site, has been initially stolen and adapted from René Seindal's old GNU m4 site. It was rather heavy on Makefiles however. The marvelous Python language later reduced and simplified it all. The Browse and Folders buttons, once found in the menu section of most projects, were fully served by Python scripts.

I then went a bit overboard with dynamic generation at Webert and CherryPy times, as both used the Traiter tool, a powerful and efficient templating system of mine. reST documents, which are heavier to turn into HTML, later brought me back to reason, and to Makefiles!

Adopting Tomboy, and its XML, I grew a rather complex tboy tool able, among other things, to statically convert a public subset of my notes to HTML. Moreover, once swimming in XML, the dynamic Traiter processing has been mostly replaced by static XSL style sheets. The few remaining cases of dynamism may be addressed by JavaScript code on the server.

On the Org file side, Org's HTML converter and Web site publisher well replace leveraging tools I wrote around Tomboy and WorkFlowy.

5 Blogs and wikis

Wikis are collaborative devices in which pages are easily modified. Blogs receive chronologically sorted documents on possibly random subjects, relieving the writer from formally inserting information into a sounded, structured tree. I wanted to make a few tries in that direction.

For a while, I linked PyBlosXom to CherryPy. Later going to Yaws (From CherryPy to Yaws), I activated Yaws' Wiki. The above Wiki has not been so productive in practice, most contributions were spam or defacing. So, I abandoned it all, and returned to read-only mode, not allowing comments. For my little blog needs, a tiny Python script replaced the PyBlosXom machine.

Blogger solved many of these problems; it also opened the door to completely different styling. Yet, I discovered I'm not so tempted to use blogs unless I can integrate them intimately with the remainder of my overall documentation setup, and handling Blogger internal formats through automatic processes proved to be too much of a hurdle.

So, I moved the information contents of my blogs from cloud applications, back to my machines (see Icule, Arts and Ordi), and now intend to drive them from Org, would it mean read-only mode. Who knows, I may feel like progressively improving on presentation and adding features while experimenting around…