Sunday, May 27, 2012

Org-Mode + t Makes Tweeting Easy



Update 2012-06-04 Mon 00:57


You can download the code from its Github repository.



Motivation


After yesterday's ranting about Octopress, it occurred to me that while I now own the content of my blog postings, I don't own the content of my tweets. I'm sure that there's some way to convince Twitter to give me my tweets, but why should I rely on them to store my tweets.

The obvious answer is that my tweets should be created on my computer and then sent to Twitter.

It should be noted that I'm not interested in implementing a full Twitter client. There are more than enough of those. I'm interested in having my tweets, or at least the bulk of my tweets, in a simple and easily accessible format.



The Answer Must Be Cheap


While I want to author and store my tweets locally, it is not a high priority task for me. Whatever solution I come up with must add little or no overhead to my tweeting workflow, must be simple to implement, and cannot require ongoing tinkering to keep working.

Being that my relationship with Org Mode is rather simple: The more I learn about it the more of my life I want to be based on Org Mode. Org Mode just seems to make everything easier. So I decided to use Org Mode for the author, publication, and storage of my tweets. The system I'm describing has these properties:

  • It took me just a few hours to design, implement, test, and begin using it for tweeting.
  • Besides not adding overhead to my tweeting, it has made tweeting dramatically simpler.
  • The entire implementation is a single file of elisp that is 120 lines long. 50 of those lines are standard Emacs header comments that are automatically created. The implementation, along with its documentation, is only 70 lines long. While a small code base isn't one of my goals, not needing ongoing tinkering is. It is hard to imagine that 70 lines of code will require too much tinkering.


Saturday, March 31, 2012

Automatefd Gvoice And Gmail To Gcal

I seem able to hold incredibly large amounts of technical details in my head. In contrast to this, I'm excited when I can remember what year my kids were born in. From my viewpoint, this is just the way I have always been. From the viewpoint of people in my personal life, it can be frustrating.

Being the technophile that I am, I've incorporated many electronic assistive technologies into my life. In 1989 I got my first PDA. It was about the size and weight of a half-brick. But I could carry it wherever I went and it would ring to remind me to do things. What a deal!

My newest electronic assistive technology is a rather complete phone and SMS management system. Its features are:

  • I have a permanent record of every incoming or outgoing call or SMS.
  • My mobile phone rings whenever I get an incoming call or SMS.
  • My home phone rings whenever I get a call.
  • My mobile rings and gives me a notification whenever I get a call or SMS.
  • My computer rings and gives me a pop-up whenever I get a call or SMS.


This blog entry is unfinished. It will be updated or followed up with a second blog entry shortly.

Wednesday, February 15, 2012

Blog In A Box (actually, a repo)


As I have been developing my blog's technology, I have been surprised at the lack of a pre-packaged blogging solution for Emacs' Org Mode. Org Mode is simply a wonderful tool for organizing thoughts, ideas, text, links, etc… While Org Mode has a rather difficult learning curve, its motto, Your life in plain text., seems to be accurate.

Spurred by ideas from 0xDECAFBAD.com and code from NanoBlogger (NB), I've gone about creating an Org Mode-based blogging system. And, if you are reading this, it is actually working. While NB and Org Mode do all the heavy lifting, I've simply added some glue to hook them together. What I have is far from a perfect solution, but it seems to work pretty well.

There is a bit of a UI problem in that the Org Mode editing has a general look-and-feel like that seems like a typical Org Mode editor with a NanoBlogger posting jammed in. That's not surprising as, to save development time, I've basically just jammed a NanoBlogger posting into an Org Mode buffer.

The other problem that I have with the system is that there is no way to automatically detect the difference between postings that have been published and those that have not published (ie: drafts). Unless you take extra care when publishing your blog, all postings, whether or not they are drafts, will be posted.

Once I've fixed these two problems I will have a simple but reasonably functional blog system. By "simple" I mean that it is based off of NanoBlogger, a minimal blogging platform. That being said, the goals of NB are simple goals compared to most blogging systems. If you want a richer blogging system then NB isn't for you.

The glue that I've written to connect NB with Org Mode is a shell script and some elisp code. Combined they are only a few hundred lines of extensively-commented code. The entire NanoBlogger installation, living up to its name, is only 844K.

Being that NB is so very compact, my shell scripts and elisp code are small, everything is in plain text files, and that Github provides simple and free hosting of both the blogging system and the blog, I'm going to merge my entire blogging system, minus Emacs, with my blog and put it into a single Github repository.

Once that is done, anyone who wants to try my blogging technology should only have to do a few simple steps:
# Fork my blog to their own Github repository.
# Clone their copy of my blog to their computer.
# Delete my blog postings (I'm assuming people will want to create their own postings and not republish mine).
# Run emacs and load the single elisp glue file I've created.
# Start blogging.

I believe that it will take less than 10 minutes to get a blog up-and-running. That is longer than it takes to get a hosted blog on Blogger but much, much faster than most self-hosted mechanisms such as MovableType. The only prerequisites for this blogging system are

  • Bash and the other common shell script utilities that are required by NanoBlogger such as sed and awk.
  • A reasonably modern GNU Emacs. It comes with Org Mode pre-installed.
  • The git command-line program.


Being that this blogging system is only aimed at Emacs users, it is certain that they'll have Emacs already installed on their machine. It is also very likely that they'll have bash and the shell script utilities. Maybe they'll have git or maybe they'll need to install it. It is a simple installation.

There is no need to install a local web server for staging. Provided you have versions from this decade, there is no need to ensure you have the right version of any of this software. Managing versions of installed software can be a major pain for many systems (eg: Python based-apps). You also have full access to your blog's data without having to export anything (everything is already in plain text files) or provide a credit card (Github is free).

Tuesday, February 14, 2012

My New Blogging Technology

As I've discussed in previous postings about this blog's technology, this is a static blog written with NanoBlogger. NanoBlogger is a CLI driven blogging system. Alas, I have found the NanoBlogger manual to be difficult to follow and the syntax of the CLI to be non-intuitive. (See the footnote here regarding the existing CLI.) On the upside, NanoBlogger is a CLI system which makes it easy to modify.

I started out with a few small helper scripts, eventually merging them into a single helper script. As I was using that script and learning more about NanoBlogger, I found myself writing smaller helper scripts for my big helper script. Eventually, I was never calling my original, large helper script directly.

At this point it became clear that some refactoring was needed. So I refactored. I came up with a single shell script call nbc.sh that does all the work and a series of shell scripts that simply call nbc.sh.

The key idea behind nbc.sh, or simply nbc, is that the scripts that call it are trivial. By "trivial" I mean that each script is only a few lines long, all the side scripts have identical content, and, if not for the semantics of Git, would simply be multiple symbolic links to the same program.

As you can see below, the code for the side scripts simply stores the command name, $0, of the side script that was called and then calls the nbc.sh script that is in the same directory as the side script.



#!/bin/sh

# Code to load include file.
ORIG_ARG_0="$0"
NBDIR=${0%/*}
. ${NBDIR}/nbc.sh

This means that as I continue to add functionality to nbc, all I need to do is copy one of the side scripts to the filename of the new command I added.

While I won't discuss the exact naming scheme used for these side scripts in detail in this posting, I will say that I have tried to systematic in how the scripts are named. Once you learn a few abbreviations (eg: "e" for "Entry" or "Entries", "u" for "Update") and the rules for combining those abbreviations (standard RPN), you will know the names of all the commands, what each command does, and the type and order of arguments each command takes.

I still need to write richer documentation for nbc and its side scripts, but I can finish this posting off with some concrete examples.

NB supports an "update" command that essentially tells NB to rebuild the blog from scratch. The syntax of this command is:



nb update

My nbc version of this command is:



nbu

All of the commands for nbc start with the letters "nb". The letter "U" is the abbreviation for "Update". So "nbu" tells nb to run the update command. As I said, the code for nbu and the other side scripts are trivial and given above. As far as examples go, nbu is not very exciting. But the nbc's CLI for creating tags is a bit more exciting.

NB's syntax for creating tags, as documented in its manual, is:



nb --title <tag-name> add tag

Gosh! That's both tough to remember and tough to type. In nbc, the command for adding a tag is nbga. All commands start with "nb". After that, the "g" means that we are talking about "taGs". The "a" stands for "Add". The syntax for the command is



nbga <tag list>


Besides being much easier to type and remember, it allows a tag list as compared to a single tag name. That is, you can create multiple tags in a single command rather than needing to call nb once for each new tag.

In NBC, a tag list is a comma-separated list of one or more tag names. So "tag1" is a tag list and "tag1,tag2,tag3" is also a tag list. If you prefer you can space-separate the tag list but you need to ensure that you pass the entire tag list as the first argument to nbga.

As the operations become more complex, NBC's simplifications become greater and more obvious. My next posting about NBC will discuss some of these simplifications.

If you wish to use NBC, look at the source code, or tell me why NBC sucks, you can get the scripts at https://github.com/Neil-Smithline/nbc.