If you’re not already in the loop, Slogger is a “Social Logger” that pulls in feeds from a wide range of social services and creates entries for them in a Day One journal. It can run itself each day and create an automated collection of everything you’re already putting out there on the Internet, including photos (Instagram, Flickr, Twitter, etc.), Tweets, music you listen to, miles you run, blog posts you share and more.

I just bumped Slogger up to version 2.0.18.1. Refer to the “Updating Slogger” info in the documentation for instructions on updating. This is a fairly small version bump, but I figured it was as good a time as any to offer an update on the project. The most interesting new feature in this version is that the BlogLogger plugin can now gather the number of times any of your recent posts have been tweeted and generate a “Top 5” most popular posts entry for each blog in your config.

The feature is disabled by default, so if you don’t want to see these you don’t have to do anything. To enable the feature, run Slogger once (or use the new ./slogger --update-config command) to update the configuration file, then edit the get_most_popular line under the BlogLogger section to be “true.”

get_most_popular: true

You can also just add that line, indented by two spaces under the BlogLogger: header and not have to run Slogger the first time.

With the latest version, it’s now possible to run ./slogger --update-config to add new options from updated/new plugins without running them. This also works for new installations to generate the initial config file without running Slogger a dozen times. The README has been updated to reflect this.

This version also includes a fix for the Gauges plugin to make sure that it’s fetching the correct date and not creating double entries on the current day.

Download the latest version from the Slogger project page on Github, or clone it using git for easy updates. Forks and pull requests are, as always, welcome. There have been a lot of great contributions already, so thanks to everyone who’s pitched in!

Some Slogger usage reminders

Because the documentation has been a little scattered, I want to point out a few command line options to help you get the most out of your Slogging.

Back in time

First, the -t option lets you specify a number of days to traverse back in time. You can run ./slogger -t 7 to get all the entries for the last week instead of just the current day. Most of the plugins are pretty good about putting the entries in the right day in your journal, but a couple of them will lump the whole week into the current day. Your mileage may vary depending on what plugins you’re running. The number can be as high as you like, but most feeds only go back a certain period of time. Thus, running ./slogger -t 365 will go back a year but will only capture what’s still available in the feed for the service.

There’s also a -s option. It doesn’t require any parameters, it just runs with a date set to the last time that Slogger ran (the s stands for “since”). This is handy if you don’t run Slogger daily with some form of automation. You can just run it with ./slogger -s and get everything that’s happened since the last time it was able to run.

Testing and cleanup

When testing, you can also use the -o option, which runs only the plugin specified. It will run the first plugin that matches the string you pass it, so in most cases you only need the first three or four letters of the plugin’s filename. For example, running ./slogger -o blog will run only the BlogLogger plugin. This isn’t persistent; next time you run Slogger, it will run all of the plugins in the plugins folder.

This brings me to the -u option. It’s designed to “undo” any number of recent Slogger runs, removing the entries and cleaning up your journal. Warning: this feature uses the Unix find command to delete everything newer than the date of the run it’s rolling back to. Do not run it if you’ve made manual entries since the last Slogger run. It’s designed for development and testing plugins and configurations without polluting your Journal.

To use the undo, you pass it a number which represents the number of Slogger executions to undo. Running ./slogger -u 2 will undo the last two times Slogger has run, deleting any entries that were created[^delete]. This is great for running tests and not making a mess of your Journal. Note that the number passed always counts from the end, so running -u 3 after running -u 2 just deletes one more entry back in time, not a total of five entries.1

You can see all of the available command-line options by running ./slogger -h. Most of the other ones are development-specific and not of use to most users.

[Slogger on GitHub]

  1. As a technical detail, the dates and options of your Slogger runs are stored in a file called “runlog.txt” in your Slogger folder. If needed, you can find the run you want to roll back to and count the number of lines between it and the end. Say there are 15 lines after it, just run ./slogger -u 15. ↩