As many of you know, I’ve been working on a personal wiki for some time now. (See the CWiki repository.) In fact, I’m using it to write this post. It’s very comfortable for me. One of the things I have been trying to get absolutely right (for me at least) is the layout. There are really only two layouts; one is for the “reading” view, the other for the “editing” view.
Writing wiki pages using Markdown is a great way to do things because it is simple, well-known, and capable. One of the annoyances of using Markdown is that it has no default syntax to create wikilinks, a type of hyperlink that links one page in a wiki to another. I’ve been working on a home-grown, personal wiki, CWiki, for almost a year now off and on. It’s written in the Clojure programming language, which is a pleasure to use.
Starting the implementation of user options (preferences) in CWiki (a personal wiki program) got me thinking about refactoring the project into a shape that is more compatible with Stuart Sierras reloaded workflow. Naturally, that led to thinking about his component architecture. Here are some more resources related to the component architecture. Stuart has a blog post about his reloaded workflow, linked above. The component code repository is on Github here.
There is probably no more boring task in programming than processing a file to replace tabs with spaces or doing the reverse and replacing spaces with tabs. And yet it has started religious wars that have raged for years in various programming communities. This “tabifying” or “de-tabifying” is not something I have to do frequently, but every once in a while, I need to convert tabs to spaces in some text.
Most programs provide an “Autosave” feature these days. The feature gives the user a chance to minimize the amount of work lost due to some unforeseen mishap, like a sudden power outage. When I write a program in Clojure that requires such a feature, I have the entire Java library at my disposal. I usually create something based on a ScheduledExecutorService – something that watches for a change in the document then allows a certain amount of user inactivity to pass before automatically saving the document.
Changing jobs in 2005 caused me to switch from taking notes on paper to doing it electronically. My new employer provided a tablet PC with a stylus running Windows and OneNote. Taking notes on that system with excellent handwriting recognition was a revelation. The tablet was pretty clunky by today’s standards, but it worked well. It was particularly useful for generating meeting notes in real time and projecting them during meetings.
Collate Notes has received my praise in the past. I even paid for it. Shortly after that unusual event, development seems to have stopped. And it still has numerous shortcomings. The most annoying problem is that periodically, it says my trial period has run out, and I need to enter the activation code (again). And since it’s closed-source, I have no recourse but to submit bugs and make feature requests to a developer who seems to have gone silent.
There was an article that I came across recently that listed the 25 “best” coffee roasters in America. The report included lots of companies I had never heard of and only a few of the ones I believe rank up there with the best. As you may know, I have some opinions about coffee, mostly that it is about flavor, not caffeine. Also, I strongly prefer specific methods of preparation to others.
I created a simple web app, called clajistan. Purpose The purpose of creating the app was two-fold. I wanted to have a little app to act as a “placeholder” on a very lightly used virtual server. To learn how to use WebSockets (sente) behind a proxy server (Caddy). Desired Performance The program displays a simple web page, written in ClojureScript, with a few statistics about the server, written in Clojure:
As a lone developer, I have a workflow that I believe is pretty typical. Most of my development work happens on the “tip” of the “default” branch. It’s just easier to do work on fixing small bugs or adding minor features there. For more significant, more difficult pieces of work, I usually create a “feature branch.” I do this with the expectation that if things get messed up too badly, I can delete the branch and start over without affecting the readiness of the default branch.