Late last month there was a post on Meta Stack Overflow wondering why SO is “so negative of late.” Reading through the extensive list of answers, and all the comments that quickly adhered to them like barnacles on a becalmed schooner, it was hard not to extrapolate to the experiences of online communities elsewhere, especially in the free and open software world. Stack Overflow is going on six years old now and has grown to be a truly formidable¹ resource for programmers, dilettantes—the category to which I clearly belong—and, apparently, people wanting their homework done for them. This isn’t the first time this question has been raised there, and I am sure it won’t be the last.

I don’t spend much time on SO, mostly because I am not a programmer and so I don’t have much to contribute there, but also because I am active on Unix & Linux², one of the clones that has emerged out of the metastasizing StackExchange empire. I do, however, subscribe to quite a few of the RSS feeds for question tags on SO: things like #awk, #bash, and other topics that are of interest to me. Given the amount of noise in these feeds; in the form of redundancy (ie., questions that have been asked in one form or another many times before) or just a signal failure to read any documentation, it is not surprising that the people responsible for this degradation see the site as negative, or unfriendly, or elitist. This is perfectly natural: it is the community attempting to defend itself from help vampires.

What was also quite predictable, given StackExchange’s response to this “problem” which was the 2012 Summer of Love campaign where they wanted to make SO a more friendly place, was that this would only exacerbate the issue. My experience of the site over that time is that the signal to noise has not improved at all, quite the contrary. I think that setting an expectation that the site would be more welcoming has two perverse consequences: first, it validates the perceptions of the newcomers about purported hostility, and in doing so signals to the existing community that built the value of the site that their culture needs remediation. Secondly, it signals more tolerance for behaviours that add no value to the community; so it is hardly surprising to see those behaviours proliferate.

From time to time the Arch community faces exactly the same criticisms: we are unfriendly, or elitist. I neither agree with these types of comments, nor am I particularly perturbed by them. Arch is a small community of volunteers, in order to create an environment where people who are willing and able to actively contribute, I think is important to ensure that there are clearly articulated standards³ and that they are maintained by the community at large.

I don’t see any scope for increasing the community’s tolerance for vampirism or the sort of self-entitlement that has a sad habit of appearing from time-to-time:

As for the Arch team and their lacking resources, let's take your point at face value. Now, we've known what the problem is for almost four hours and no fix has been issued.

There is some sort of “problem” that “we” have known about for four hours and yet, inconceivably⁴, nothing has been done about it?

There is no bug report on the Arch tracker so I am not sure why the collective pronoun is warranted here, that quibble aside; in what universe is this sort of petulance considered acceptable? The only reasonable response to this sort of whining is to close the thread and ban the infractor and their progeny, who will no doubt suffer from the same sort of genetic deficiencies, in perpetuam…

Clearly articulating, and enforcing, minimum standards of behaviour doesn’t make your community hostile or unfriendly; it establishes boundaries for people that supports respectful collaboration and the effective ability of that community to self-moderate. People new to the community who take the time to read the guidelines and observe how things work will have no problem adapting⁵. It may not make you popular, but it will make a significant contribution to the sustainability of the community and the levels of engagement of those that do contribute and wish to continue doing so.

Notes

1. “Fear” and it’s synonyms appear with remarkable frequency in that thread and the accompanying one on Hacker News.
2. I have written about U&L previously.
3. The Forum Etiquette, for example.
4. With apologies to Wallace Shawn…
5. I have written about this in the past.

Creative Commons photo on Flickr by Chris Lester

Following up on my post from last week, about using khal and mutt, where I covered off a couple of simple hacks to integrate command line calendaring with Mutt, I had been using the main development branch of khal which includes syncing capability. However, as I was conversing with the developer, Christian, around a bug report, he indicated that this functionality would be superseded by development in a separate branch that uses vdirsyncer to synchronise calendars.

As Christian intimated that this change would happen in the very near future, and “js” had commented on my last post to the effect that it was working well, I thought I should take a look for myself.

There are packages in the AUR for vdirsyncer-git and python2-argvard so you will just need to grab the khal branch that uses vdirsyncer as it’s syncing engine. I have thrown up a PKGBUILD gist, or—as we are only talking about a couple of simple scripts—you could install the complete set using pip, the Python package manager; in which case it would be a straightforward:

1
2
3

sudo pacman -S python2-pip
pip2 install --user git+https://github.com/geier/khal.git@vdir
pip2 install --user vdirsyncer

…and then remember to make sure that $HOME/.local/bin is included in your $PATH.

I wanted to have vdirsyncer manage two of my calendars, my CalDav work calendar and a simple iCalendar with all of the New Zealand public holidays. Configuring vdirsyncer to successfully do this took me a lot longer than I would like to admit: a combination of my ineptitude, a bug and a broken schema in the original holidays.ics that I wanted to use.

The collections variable in the config file merits a mention in this regard. If you choose to use it, be aware that your URL will have this value appended to it, which may throw a 404. Using the DEBUG verbosity level will identify this issue if you are struck by it.

Eventually, with the help of both Christian and Markus, the vdirsyncer developer, I got it set up and running smoothly. I then just had to create a cron job to sync my work calendar every two hours and it was done.

As you would expect with such a simple tool, there is not a lot to say, or do, with vdirsycner. It runs on a similar model to OfflineIMAP, in that it synchronises a remote and local repository. There are a couple of nice touches: it will read your credentials from $HOME/.netrc so you don’t have to worry about sensitive information in plain text in yet another file, and there is a VDIRSYNCER_CONFIG variable, so you can place the config file wherever it suits.

Notes

Elevator, a Creative Commons image on Flickr by Mykl Roventine.

I have posted a few times now about how I use Mutt¹, that most superlative of email clients. Using a variety of different tools, I have settled on an effective and satisfying workflow for managing both my personal and professional email, with one glaring exception: calendaring. This, I should stress, is not for want of trying. It is not necessarily a nagging concern in terms of my personal use of email, but professionally it is a daily frustration.

Day after day, I receive a lot of meeting invitations and, when these show up in my inbox they are, for all intents and purposes, unintelligble. Yes, with careful scrutiny you can decypher the iCalendar files, but doing so is more likely to induce a seizure than a punctual appearance at an important meeting. To get around this, I had been using a basic Awk script that would parse the most important parts of the message and print them out. This was working well enough until I started to receive invitations from people using OSX. For some god-unknown reason, Apple’s “interpretation” of the standard² is different enough to those sent from Evolution and Thunderbird that my script wouldn’t successfully print some of the data (just the start and end times of the meeting, nothing too important).

I started to try and expand the capability of the script and then realized that I would be much better off seeing if someone else had solved this problem; satisfactorily, that is. And they had. In a further delightful coincidence, the original author of the script, Martyn Smith is an ex-colleague who, in 2004, first got me interested in Linux (thank you, Martyn). Armed with this script and entries in $HOME/.mutt/{mailcap,muttrc} now, whenever I open a calendar invitation, the pertinent details are printed out perfectly legibly. It’s a small step, but an important one.

Next I started playing around with khal, a command line calendaring application that uses CalDav to sync to calendar servers. It is described as being in “the early stages of development” and that certainly is the case. Nonetheless, it is incredibly promising as—even in this rudimentary form—it performs well and offers most of the basics that I require. khal is simple to setup, does not have too many (python2) dependencies and handles multiple calendars³. Yes, there are bugs, but nothing grievous and the developer, Christian Geier, is very responsive and helpful⁴.

The khal documentation gives you a pretty good idea of the current feature set. Set up your khal.conf with the calendars you want synched and then you have two modes of interaction: directly via the command line or an interactive mode invoked with ikhal. Both modes allow you to perform the basic functions of adding, editing or deleting events.

While the interactive mode is very simple and straightforward, what I am most excited about is the ability to add events from the command line, as per the example in the documentation:

1

khal --new 25.10. 16:00 18:00 Another Event :: with Alice and Bob

I just needed to figure out a way to extract the relevant fields from the iCal file and pass them to khal. My first attempt is unashamedly ugly, both in conception and execution. However, I don’t know Perl (and at this stage of my life I have run out of time to learn it), and it actually works. I modified Martyn’s script to write to a temp file and then, for iCal events I want to import to khal, I bound a key sequence in Mutt to a simple Awk script⁵:

1
2
3
4
5
6
7
8
9
10

#!/usr/bin/awk -f
# read from ical_filter.pl and then send ical invitation details 
# in mutt to khal

/^Summary/   { for (i=1; i<=NF-2; i++) $i = $(i+2); NF-=2; summ = $0 }
/^Location/  { for (i=1; i<=NF-2; i++) $i = $(i+2); NF-=2; meet = $0 }
/^Dtstart/   { date_st = $3; time_st = $4 }
/^Dtend/     { time_nd = $4 }

END          { print  date_st" "time_st" "time_nd" "summ }

In $HOME/.mutt/muttrc, I have Ctrlk in pager view trigger the script like so:

1
2

# save iCal to khal
macro pager \Ck  "!/usr/bin/khal --new $(~/Scripts/mutt2khal ~/.mutt/temp/caldata)" "Saving Calendar event"

Neither elegant nor imaginative, I know; but for a first attempt, it gets the job done. If I did know any Perl, I am sure I would be able to avoid the additional temp file and the need to reread the information before handing it off to khal, but you work with the skills (or lack thereof) that you have. Needless to say, patches are welcomed.

Notes

1. See all my mutt posts:
   • Using Mutt, LDAP and SSL
   • Mutt and HTML Email
   • Using Notmuch with Mutt
   • Encrypting Mutt
2. Yes, I understand how special Apple is but this is particularly annoying…
3. There is a package in AUR.
4. I logged a bug and it was fixed in a matter of hours.
5. The script is in my bitbucket repo.

Creative Commons image, Calendar by Angela Mabray.