Posts Tagged ‘abook’

My software stack revisited – Summary and Future

Wednesday, December 29th, 2010

This is the last post in the series. It has taken me a while to write, edit, and then rewrite because I didn’t like the first outline (which I didn’t realize until I got to the end).

The software I have listed in these posts are there for a reason. While they work well in their own right, when put together, the whole forms something greater than the individual pieces.

Lightweight

Most of the software on the list is lightweight, almost a requirement as one of my systems is a netbook, and although the resources on my desktop seem almost infinite in comparison, I want to be able to work with my things on the netbook as well.

CLI

I go for CLI-apps rather than GUIs because that, more often than not, keep my fingers planted on the home row, instead of the right hand scurrying off to the mouse ever so often. Because, more often than not, the CLI-apps are more lightweight than the lightest of GUIs. And because more often than not, a CLI takes up less screen space to convey the same amount of information, as a GUI does.

CLI-based programs will also work when the X-server has broken down, and your stuck in a TTY, or you have your software on a server and are accessing it over SSH from a computer where either you or the system is unable to install the software.

Plaintext

I prefer plaintext over binary storage formats because it leaves me in control. If the worst comes to the worst, I can retrieve the data I need from a simple text-editor.

Not to mention that plaintext is easier to diff, which is good when you check it into version control and run into a conflict.

In the case of LaTeX, one of the best practices I picked up was to let each chapter be its own file, and then have a master-file which includes the chapters.

What this means is that when you want feedback on a specific chapter, you only need to send that, and not the entire project, which is bandwidth friendly.

And please, no comments about fancy gigabit infrastructure all over. You try sending an email or surfing on a long train ride when there are 10+ douche bags hogging all the bandwidth listening to Spotify…

Plaintext is also rather easy to parse. Combine this with a shell script, and your imagination is your only limit to the stuff you could do.

The future

There are definitely more uses for the server, such as VPN and perhaps a mumble server. Time will tell. I do know that I will spend the next couple of days trying to configure nginx and uwsgi so I could start doing some Python web-stuff.

I have been considering dropping Pidgin and instead give bitlbee a try. This would mean that all communication (with the exception of email and microblogging) would instead go through irssi. That would mean one less GUI-app, and also that all the logs would be gathered in one place (on the server) instead of the current situation where Pidgin logs are interspersed between the desktop and the netbook.

I have in a similar fashion thought about replacing Thunderbird with mutt. It would mean that I would replace one software (Thunderbird) with five (mutt, msmtp, offlineimap, abook and mairix).

Edit: Something very similar to this. (Thank you Thomas)

Well, four anyway, abook is already installed and operational.

msmtp is used to send emails (and thusly communicates with an smtp server.

offlineimap is used to sync an IMAP mailbox (fetch new mails, mark mails as read or deleted on the server, etc)

mairix is a full text search engine for Maildirs.

One of these days, I will also try to become better friends with zsh. It has many nice features which I think could increase my efficiency at least somewhat.

That’s all folks, I hope you have enjoyed reading the series as much as I enjoyed writing it. Comments are enabled in all the post, feel free to add questions or suggestions.

:wq

My software stack revisited – Organizing

Monday, December 27th, 2010

Back in the original post, I don’t think I actually had this category at all. In fact, I do believe all the applications I am about to list in this post are additions to my stack.

Knowledge management

Knowledge is power. But only if you have that knowledge accessible and stored in a fashion which makes the retrieval of the relevant parts of it both simple and timely.

This is more true the more knowledge you accumulate.

For storing growing amounts of knowledge, I have come to find a wiki the best alternative. It does require some initial thinking, about how to structure the information being saved within it, but in my experience the benefits outweigh the work. Simply think of it as an investment.

Some of the knowledge I collect is pure information which no one but me should have access to, so I didn’t especially like the idea of putting the stuff into a web-based wiki. And that’s where desktop wikis comes into relevancy.

I tried out Zim, a GUI-centric desktop wiki. It works great, and I do recommend it. And it is as lightweight as they come. But… that was before I realized there is a Vim plugin: VimWiki.

Outlining

For some reason I find it much easier to break down problems into smaller pieces if I use software (or hardware, pen and paper FTW), than if I do it in my head.

Whatever the reason for this is, I have found a friend in another Vim plugin: VimOutliner. One of the tasks that VimOutliner helped me split into smaller pieces, and organize? This series of posts.

Calendar

Like with the knowledge management (and Zim), I have already managed to iterate through a solution, which consisted of the CLI-based cal, which just prints out a simple three month view (previous, current, next) and should be included by default in most if not all GNU/Linux distributions, when which is a script that parse a file filled with rule-based constraints, all detailing dates, or ranges of dates, when things happen.

when is an excellent piece of software, and if you can take the syntax (me, being a programmer, found it quite straightforward) but I began feeling a lack of putting it all in context easily when adding new dates (specifically if I already had appointments on a specific date, and what dates would possibly be better).

Which made me try out calcurse. Not to replace when, but to complement it. Sadly neither when, nor calcurse, saves date/appointment data in a format which the other recognize. In fact, both save in a format only they themselves understand. This made synchronizing between the two inefficient.

I said that when is excellent. I also said that I’d iterated through a solution, which means I am no longer using when. And I wouldn’t replace an excellent piece of software with a mediocre one, so whatever I replaced when with, would need to be at least as good as when, but without the drawbacks.

Enter bumby who came along and urged me to try remind which does the exact same thing as when, but with a different syntax. But remind has one big advantage. There is another program, wyrd, which is to remind what calcurse was to when, with one difference: wyrd doesn’t save appointments in a format of its own. It is just a wrapper around reminds appointment files.

All these files, whether from when, calcurse or remind, are of course all plaintext.

Contacts

Finally, comes an address book, simply named abook. It is an ncurses-based lightweight little application for storing and viewing contact information about people.

Thunderbird provides the same thing, so some duplication of effort / breaking of DRY is occurring here, but I feel it justified as I could fetch relevant information from abook, and be on my way contacting the person, before Thunderbird has loaded and come into a usable state.

The next post will be focusing on the largest single change to have been implemented since the original post: the addition of a server.

:wq