musicmatzes blog

programming

This post is about how to setup vim (vim_configurable) on NixOS with reusable parts and the possibility to replace vim with neovim without rewriting the whole setup.

configuration.nix

What we have in the configuration.nix file is simple:

environment.systemPackages = let
    vimPackages = import ./some/directory/vimPackages.nix pkgs;
    # neovimPackages = import ./some/directory/neovimPackages.nix pkgs;
in
    vimPackages ++ with pkgs; [ some other packages ];

You can see that we simply import some nix expressions and pass them the pkgs of from our configuration.nix file. Everything else is done in this file and some sub-files.

vimPackages.nix

So here starts the fun. We define a function which gets the pkgs variable and the lib variable from the outside scope (we don't pass the lib variable, though nix is smart enough to figure out what we mean). We already know that we need to return an array of packages, so we can return vim and some things we use in our vim scripts, like so:

# ...
[ vim pkgs.ctags ]

vim is not prefixed with a pkgs. here because we define it in the file itself. But first, we need to know what we want to override. vim_customize allows us to compile vim without GUI support, for example (there are a lot more options). We also want to build our vimrc and we want to put plugins into our vim setup, because this is the NixOS way of life.

customization = {
    vimrcConfig = (import ./customization.nix { pkgs = pkgs; });
} // { name = "vim"; };

Here we import our customization (vimrc, plugins, etc) and ensure that the executable is named "vim". We can now use this customization to customize vim_configurable:

custom_vim = pkgs.vim_configurable.customize customization;

and afterwards we override this derivation and set variables, what features should be compiled into vim:

vim = lib.overrideDerivation custom_vim (o: {
    ftNixSupport = true;
    gui          = false;
    luaSupport   = true;
    # some more
});

Now we put these parts together and into a function, so the whole file looks like this:

{ pkgs, lib, ... }:

let
  customization = {
    vimrcConfig = (import ./vim/customization.nix { pkgs = pkgs; });
  } // { name = "vim"; };

  custom_vim = pkgs.vim_configurable.customize customization;

  vim = lib.overrideDerivation custom_vim (o: {
    aclSupport              = false;
    cscopeSupport           = true;
    darwinSupport           = false;
    fontsetSupport          = true;
    ftNixSupport            = true;
    gpmSupport              = true;
    gui                     = false;
    hangulinputSupport      = false;
    luaSupport              = true;
    multibyteSupport        = true;
    mzschemeSupport         = true;
    netbeansSupport         = false;
    nlsSupport              = false;
    perlSupport             = false;
    pythonSupport           = true;
    rubySupport             = true;
    sniffSupport            = false;
    tclSupport              = false;
    ximSupport              = false;
    xsmpSupport             = false;
    xsmp_interactSupport    = false;
  });

in [
  vim
  pkgs.python
  pkgs.ctags
]

But that's not all to it. The customization.nix is where the real fun begins.

customization.nix

So this is the file where we define which plugins we want to use. There are some plugins which are not yet included in the nixpkgs repository, so we have to build these packages ourselves to be able to install them. Luckily, the nixpkgs provide some helper functions to build vim plugin packages rather easily.

Also, we build our vimrc file here, which consists of another bunch of script files.

vimrc.nix

The vimrc itself is written in viml of course. If you have a lot of vimrc configuration, you can split this file into several smaller ones. For example, I have split these files into the following structure:

./
├── colorschemes
│   ├── mm_neverness_share.vim
│   └── razorlight.vim
├── filetypes.vim
├── folding.vim
├── general.vim
├── gui.vim
├── insertmode.vim
├── mappings.vim
├── menuconf.vim
├── plugins
│   ├── # ... some things
│   └── ycm.vim
├── pluginconfigurations.nix
├── scripts.vim
├── searchnreplace.vim
├── statusline.vim
└── textediting.vim

So what we do in our vimrc.nix file (which later gets included in our customization.nix file) is: We include all these .vim files and put them into one giant string, which is then our vimrc file:

{ stdenv, writeText }:

let
    generic     = builtins.readFile ./vimrc/general.vim;
    textediting = builtins.readFile ./vimrc/textediting.vim;
    # ... more here

    plug = import ./vimrc/pluginconfigurations.nix;
in

''
    ${generic}

    ${textediting}

    # ... more here

    ${plug}
''

You might noticed the vimrc/pluginconfigurations.nix file. This one is just another layer of abstraction here and is basically the same as the vimrc.nix file:

let
    # some files
    ycm = builtins.readFile ./plugins/ycm.vim;
in

''
    # some variables
    ${ycm}
''

plugins.nix

Another file we need is the plugins.nix file. As said, not all vim plugins are in nixpkgs (yet). So we have to build some vim plugins ourselves (don't get scared here. This does not mean you have to run compilejobs yourself, most plugins don't contain any binaries so rebuilding the system with vim plugins installed is normally a matter of seconds).

So this one is also rather simple in the end. In the example below you can see how I build the vim-trailing-whitespace plugin. The version might be outdated, though.

{ pkgs, fetchgit }:

let
  buildVimPlugin = pkgs.vimUtils.buildVimPluginFrom2Nix;
in {

  "vim-trailing-whitespace" = buildVimPlugin {
    name = "vim-trailing-whitespace";
    src = fetchgit {
      url = "https://github.com/bronson/vim-trailing-whitespace";
      rev = "d4ad27de051848e544e360482bdf076b154de0c1";
      sha256 = "594769a6f901407609b635a5041966456bfd91b13437169a4562857544e1dca3";
    };
    dependencies = [];
  };

  # more?
}

Finally... put the parts together.

Now we can write down our customization.nix file, which imports the plugins.nix and vimrc.nix files and puts them in the right context, so the nixpkgs infrastructure understands how we want to have our vim package build:

{ pkgs }:

let
  # this is the vimrc.nix from above
  vimrc   = pkgs.callPackage ./vimrc.nix {};

  # and the plugins.nix from above
  plugins = pkgs.callPackage ./plugins.nix {};
in
{
  customRC = vimrc;
  vam = {
    knownPlugins = pkgs.vimPlugins // plugins;

    pluginDictionaries = [
      # from pkgs.vimPlugins
      { name = "youcompleteme"; }

      # from our own plugin package set
      { name = "vim-trailing-whitespace"; }
    ];
  };
}

Building

After putting these things together you can rebuild your system. The vim binary might be compiled from source, though this isn't that much of a problem because there are only few vim updates, so rebuilding vim will happen every four weeks or something, not on every system rebuild.

nixos-rebuild switch

neovim

As said, you can now use the infrastructure we just wrote to compile the very same configuration into neovim, including your vimrc, plugins and everything.

{ pkgs, lib, ... }:

let
  nvim = pkgs.neovim.override {
    # don't alias neovim to vim, yet.
    vimAlias = false;

    configure = (import ./vim/customization.nix { pkgs = pkgs; });
  };

in [
  nvim
  pkgs.python
  pkgs.ctags
]

Just make sure your vimrc settings don't mess with neovim. Some things are not supported by neovim, so you have to put them into if-else conditions like so:

if has("nvim")
  " we don't need this in nvim
else
  set clipboard=exclude:.*
endif

And that's it. tags: #nix #nixos #vim #neovim #programming

Everyone starts using shell environments, where custom variables are available, custom bash functions are enabled, special commands are available, maybe even some additional programs are installed.

Projects on github pop up for handling these things, installing bash “environments” and so on. And I have to ask: Why?

Why would you do that?

I tell you, there's a solution to all of your problems. It is called “nix”. It is a package manager which provides you opportunities, you've never dreamed of!

Yes, you could hack the functionality of these project-environment-manager things yourself (that's what people did, then they put it on github and now you see it and decide to write your own becaues you can do it better). You could use this piece of clusterbash and suffer from impurities you'd never expect. Or, you could just use the purity of the nix package manager to deploy the world in a shell.

With the nix package manager, you can use custom project-based environments to install packages neither globally nor in your user package environment:

nix-shell -p haskellPackages.pandoc

for example installs “Pandoc” and starts a shell where it is available. The executable is not available anymore after you type exit. It is not installed in your system, it is not even installed in you user package set. It was available in this shell and only will be available again after you entered this shell via nix-shell.

I have a lot of packages...

... so have I. Normally, I install one or two packages via commandline in my nix-shell environment. If there are more packages or I need the packages on multiple systems (when developing something, for example), I add a default.nix file to the repository:

{ stdenv, pkgs ? (import <nixpkgs> {}) }:

let
  env = with pkgs; [ racket ];
in

stdenv.mkDerivation rec {
    name        = "blog";
    src         = ./.;
    version     = "0.0.0";
    buildInputs = [ env ];
}

The I only have to type nix-shell to enter the environment.

Another idea would be to install the packages “persistent”, so after a call to nix-collect-garbage won't remove the packages from the ominous store where the packages live:

nix-instantiate . --indirect --add-root $PWD/shell.drv
nix-shell $PWD/shell.drv

(copy-pasted from the nixos-wiki)

tags: #bash #nix #nixos #programming #software

How do you do your Personal Information Management? Or, more specific: How do you organize your contacts over multiple devices, how do you organize your calendar, todo lists, notes, wiki, diary, browser bookmarks, shopping list, mails, news feeds,...

Do you use Google for all this? Maybe you do. Don't you want to uncouple from Google? Well, then... I have to tell you about the sad state of PIM for nerds.

If you want to organize your personal information without google and host everything on your own, you will soon meet tools like owncloud, emacs orgmode or similar tools. Sadly, all these things are not what I want. OwnCloud is getting more buggy with every release and it is already slow as hell. orgmode needs emacs, which is a huge tool itself and you have to learn a whole new ecosystem. If you are a vim user like me, you don't want to use emacs.

But I'm not talking about editors here. I'm talking about PIM tools. What I do right now: Owncloud with khard, khal, vdirsyncer for contacts and calendar organization. As said, OwnCloud is buggy and sometimes calendar entries cannot be synced to all my devices. On Android, I use Apps to sync my contacts and calendar as well, and they fail as well, sometimes.

I use taskwarrior, which has a sync server available. Sadly, it doesn't work yet on NixOS, but well, that's my issue and I'm working on a solution. Nevertheless, the Android client (Mirakel) is badly supported and does not work that good as well.

For news, I use ttrss, which works fine and the appropriate Android App works good, too, so no issue here. For a Wiki, I use Gollum, which works but is a bit annoying to use because it is not that customizable. I do not use note-taking tools at all, because they simply suck. There's no good note-taking tool available for commandline use which integrates with the other tools. Mails work fine with mutt, of course, but they cannot be integrated in the wiki, todolist tools or the other tools I just mentioned. I do not use browser bookmarks at all, because there is no CLI tool available for them. Same goes for shopping lists.

What I want

What I want is simple: One tool, which integrates

  • Personal wiki
  • Personal todolist
  • Personal notes
  • Personal mail indexing
  • Personal Calendars
  • Personal Contact management
  • Personal News Feeds (RSS/Atom mostly)
  • Personal Bookmarks
  • Personal Shopping list
  • Personal Diary

in the following ways:

  • I can use whatever
    • text editor
    • mail reader, sender, receiver
    • rss reader I want to use
  • I can synchronize everything to all devices, including Android smartphones or my Toaster
  • Everything is done with open standards. Means
    • vcard for contacts
    • ical for calendar
    • markdown for
    • wiki
    • notes
    • diary
    • shopping list
    • maybe YAML for todolist
    • mbox or Maildir for mails
    • normal Atom/RSS for news stuff
    • for bookmarks, YAML or JSON would be appropriate, I guess.
  • I can access all my data in the system with a text editor, if I have to
  • a clean and polished (+fast) Android Application to access and modify this data.
  • I can move/link data from one system to another. For example:
    • I can link an Email from my notes
    • I can link a entry from my RSS, notes, calendars to (for example) my Wiki
    • I can send a shopping list from my mail client to a contact and attach a calendar entry which links to the shopping list
    • ... and so on
  • All the things are encrypted (optionally)

As everything should be plain text, git would be fine for synchronization. The sync should be decentralized at least, so I don't have to host a server at home and cannot sync if I'm on the go. A web-hosted entity should be optional and so should be a web interface. Having a web-UI like owncloud has is nice, but not that critical for me. A full encryption of the content would be nice as well, but would be kinda hard for the Android devices, at least if the device gets lost. Anyways, my drives are encrypted and that should be enough for the first step.

It is, for me, really important that these tools interact well with eachother. The feature that I can send a mail to a contact and attach for example a shopping list, which itself has a calendar entry (which gets attached as well, if I want to), is a real point for me. Same goes for attaching a RSS entry to a wiki article or todo item.

Another requirement would be that the tool is fast and stable, of course. Open Source (and at best also free software) would be a crucial point to me as well. GPLv2 would be the thing.

Do it yourself, then!

Well, developing such a tool would be a monstrous huge amount of work. I'd love to have time for all this, especially as student. But I think I have not. I have a lot of opinions how such a tool should work and also a lot of ideas how to solve a certain problem which may arise, though I absolutely have no time to do this.

I, personally, would develop such a tool in Rust. Simply because it gives you so much power to your hands while remaining a really fast language in manner of execution speed (speaking of zero-cost abstractions here). Though, there would be the need for a lot of external libraries, for example for git, vcard, ical, yaml, json, markdown, configuration parsing, etc etc. While some of these things might be available already, others are clearly not.

Sadly, such a tool is not available. Maybe I can find time until I'm 35 years old to develop such a thing. Maybe someone else has done so until then. Maybe I just inspired you to develop it? Would be neat!

tags: #life #linux #mail #media #open source #programming #software #rust #tools #vim #wiki

I started a project some time ago, where I develop a template for a wiki which is statically compiled into a html page. As the template is more mature now, I want to introduce you wiki.template and explain why I wrote it.

Once upon a time...

If you read this blog you know that I'm a member of the NixOS community. The NixOS community has, of course, a wiki. And the quality of this wiki is bad. No really, it is just one large page (the landing page) linking to sub-pages which are more or less maintained and contain only snippets of information. Sure – there's a lot of content in there, but (especially beginners) one has to search for it. You can't simply find it.

That's why I wanted to have a new wiki for the NixOS community. And because I like git, I wanted the content to be stored in a git repository.

So I came up with the idea to recreate the NixOS wiki and start it from scratch. Of course, the content of the original wiki has to be migrated to the new wiki then, but this has to be done carefully and by hand to ensure that things are ordered and easy to find afterwards.

The requirements

The requirements where rather simple, but nevertheless important to me. As already said, I wanted to have the content version controlled with git. The templates and markups for other data should be version controlled as well, if possible. This way, the content (or whole wiki) can be distributed with git, hosted on github or similar hosting platforms and so on.

I wanted to be able to customize the style of the wiki completely and I wanted to be able to write snippets of markup which can be reused, such as a warning-alert template where you can pass custom text and get a red alert box in your wiki page. Pretty normal stuff for a wiki.

Syntax highlighting, TOC-generating, all these things should be integrated or available through plugins (or there should be the possibility to write such plugins).

So I searched for wiki software with git backends...

The state of git-backend-driven wiki software

The state of wiki software with git backend is bad. No, it is even worse. There are actually two projects I had a look at and one which is written in Perl (and I didn't have a look on this one, because Perl).

gitit

First of all, there is gitit. Gitit is a wonderful piece of Haskell software. It works great and is fast. But it has its issues:

  1. No Templates. Period.
  2. Content is checked in, but neither templates nor style information
  3. Haskell. So writing plugins – nah, not really.
  4. Just few plugins available

So it was pretty clear that gitit is not an option for me.

gollum

Gollum was the other alternative. Developed by github, ruby thing, sounds well, right?

But. There's a big but.

  1. No templates
  2. No plugins
  3. No custom styling or at least no documentation about it

It was clear to me: No option!

The solution

Well, the solution? Just write it yourself! And that's what I did. I started to work on a template for a wiki which is statically compiled with nanoc. Later I switched to jekyll.

Compiling the wiki to a static site has several advantages. First of all, hosting the site is cheap. A common web server can host thousands of pages without even noticing. Of course, you are also protected against hacking and all this stuff, as you do not have the problems dynamic websites have.

But these are common advantages of static compiled sites. An even bigger advantage is, that contributions to the wiki must pass a review-process of some kind. Of course, I will not grant push access to the repository to anyone and of course nobody gets access to merge pull requests, besides myself. I will protect myself against pushes to master as well, so each change to the wiki has to be reviewed. And that's what matters when it comes to quality: Changes must be reviewed.

Besides this big advantage, I do not have to care about updates (of the compilersoftware). I can do them locally and roll back if they fail. I do not have to keep track of spam bots, security updates, user account data, etc. etc. etc.

So here's the story how I wrote the template:

wiki.template

I started the project with nanoc, the static site compiler I love. The project is at version 4 these days and the compiler is really really good. It is flexible, scales well, fast and a joy to work with.

I just failed integrating foundation, the CSS framework I wanted to use. I played around with Jekyll a bit, but wasn't able to get Haml working. But at some point, foundation seemd to be more important than Haml, so I switched to Jekyll.

I also thought of the option to build the site with Jekyll directly from the github repository and build a github page with it, just because this way I can save money for hosting. I still think of that option, but as I use Jekyll with plugins I cannot build it on github directly. So I searched for tutorials on how to build it with travis and deploy my github page from travis. This is documented and a known as working.

Current state of wiki.template

To get my stuff working, I had to use some plugins. And these plugins basically work for me, but the code was either a mess or lacked features I wanted to have. So what did I do? Right, I forked them and send pull requests to the maintainers.

At this very point in time, I have three pending pull requests to these plugins, two of them just normal “cleanup codebase” PRs, one feature. I also opened issues for other features I do not necessarily need but would like to see implemented. I would implement them myself, but well... not enough time.

So what is the current state? Well, wiki.template is basically usable. I want to integrate some more features and it completely lacks of documentation on how to use it.

But these things will be done soon and I hope I can then create a fork of it to start my NixOS Wiki.

The NixOS Wiki

I already announced the NixOS Wiki fork (semi) officially on the NixOS mailinglist. Of course, as always in such communities, a discussion started on whether to do such a thing or not, which software to use and whatever. I don't care about this, I will simply do this and we will see whether it succeeds or not. Discussion all over the place helps nobody.

tags: #git #linux #nix #nixos #open source #programming #software #wiki

Imagine you have an idea for an awesome web application. Or an desktop program or even a library in your favourite programming language do make complicated things easy. You really want to implement it, maybe you already know that it will work really well, maybe you don't and you want to try whether you can make it work or not.

But how to start?

The first steps are easy. You make a new directory, maybe a directory structure. You create some files, such as a README.md or a LICENSE file. You create a MyGreatSoftware.MyFavouriteLanguage file and you open it in your favourite text editor or IDE.

But then you struggle and you don't know what to do first. Let's imagine you want to write a commandline application – do you start with the argument parsing part or do you add some backend abstraction in the first step? Do you build up a great framework around some functionality so you can use it more easily later on or do you implement functionality directly?

I had such problems, too. I started a project for a rather simple commandline application and I really didn't know where to start. It was a ruby project, so Imy initial steps where rather clear: I installed some dependencies I wanted to use, such as an option parsing library and a commandline output helper for pretty formatted output (colored things and so on). I created the directories lib and bin – and then the file lib/app.rb (where “app” is the name of the program.

And then I failed to continue because I didn't know what to implement first. So I ended up implementing the commandline parsing part and the backend abstractions at the same time (on different branches, of course) and it resulted in me deleting the project because things got complicated.

Then, I restarted the project and did something I've never done before: I started to do TDD and I started with the very first line of code.

Disclaimer: I'm not a TDD professionalist. I never had any training in TDD and I don't even know whether I did it right. But it's not the point whether you do TDD right or not here. The point is, you think about simple, neat pieces of code with a lot more focus. You try to imaging what explicit feature you want to have. For example your test says something like this:

If I pass an argument --update a File ~/.app_timestamp gets the current time is appended.

That's a really really compact thing and you can implement this in one single line of Ruby. And that's exactly my point. You start implementing things without building layers and layers of abstraction and losing yourself in the codebase you created yourself for not losing track of things.

I learned that writing tests and implementing just the very functionality that makes the test succeed helps me a damn lot to focus on the functionality I want to build rather than building layers and layers and afterwards having a kind of framework which does nothing (and is mostly even too complicated to use).

Of course, after implementing things you can clean up your codebase and refactor things, so the abstraction layers will be created at some point. But that's after the features have been implemented. And a damn great bonus: You have tests which are there to ensure you don't break your functionality by refactoring and making yourself happier with the codebase.

So that's what I call Test-Driven Project Initialization. You don't need to perform perfect TDD and stick to it all the time. You don't need to test every aspect of your functionality. The tests are there to keep you focused on the functionality, not to ensure there are no bugs. Of course, that's a neat side effect and you can continue and extend your test cases later on to find bugs. But for Test-Driven Project Initialization it is not the point to find bugs.

tags: #programming #software #testing

I just wrote my very first bit of racket code which actually runs somewhere. Want to find out what it is?

Well, it is a rather simple piece of code, and it helps me generating this very blog. If you visit this blog frequently, you may have noticed that the layout changed a bit. Chaning the layout was a thing I wanted to do for months and the adaptions I just did are exactly what I wanted to do all the time: Move the content in the center of the page, the lines are now shorter as the div in which the content lives got reduced in its width.

I also moved the tags and dates on the left of the articles, both on the index page and on the article pages. I really like that style. It wasn't that easy (for me as racket-newbie), because the blog engine I use (frog) has no method to insert a html-list of tags somewhere. So I coded it myself, right in the templates for the article and index pages.

Here's how I did that:

  1. First, I put everything into a subcontainer of the bootstrap layout. The date and tags (lets call it metadata) lives in a two-column-container to the left of the ten-column-container which holds the content
  2. I wrote a bit of racket code to generate a html-bullet-list out of the comma seperated list of tags frog gives me:
@(string-join
  (map (lambda (str)
        (string-append "<li>" str "</li>"))
       (string-split tags ",")))

What it does is simple: It splits the string in tags, which holds a list of tag-links by the seperator, the comma. Then it maps a lambda over the list of strings, which appends the string to "<li>" and "</li>" to that. Afterwards, the whole list gets joined together, so we have one big string left.

The template itself contains the <ul> and </ul> tags around the list. This way, I generate a nice bullet list for both the index pages and the article pages.

Unfortunately, the solution is not very DRY, as both templates contain the same code. There is no possibility to pass custom code to frog, yet. But I opened a feature request on github to include such an option (providing a pull request would be much nicer, I know – but as you already know, I'm a racket newbie and I'm not sure I can figure out such a thing myself).

tags: #blog #racket #programming

This semester is at its end in about one and a half week. It was a good semester, even if mine is not over yet (I'm in my praxis semester right now and I have to work four weeks longer than the other students – but they have exams)! Since one year I'm the leader of the local LUG (Linux User Group) and I really like beeing it.

As far as I can tell I will be the leader for the next semester as well, but I guess one year is a great point to reflect and look back what I've done and what was awesome and maybe even what was not so good.

What was

So, in the last year, we had (during the semester) one talk each week (in alphabetical order here):

  • 31C3-Review
  • C++ – Arcane and rusty (2 parts)
  • Docker
  • Email (In)Security
  • FTP-Searchengine
  • Fish
  • Git-Intro
  • Go
  • Nix(OS) (my talk, actually)
  • Pimp my x86 (2x)
  • Presentation of a Bachelors Thesis
  • Presentation of a semester project (2x)
  • Racket
  • Regex Workshop
  • Reverse-engineering Workshop (2 parts)
  • Ruby on Rails 1
  • Ruby on Rails 2
  • Rust

Almost all talks were held by students, only one was help by an ex-student, who does one talk each semester for us. And they were awesome.

We also managed to go to the 31C3 as a group, which was an awesome experience and I'd really love it if we manage to go there this year as well. I also started a rewrite of our website, hopefully I will finish it this weekend, so I can do a talk about it next week, which is the last week where a talk is held in this semester (traditionally we do a “Pimp my x86” talk at the very end of the semester, where each student is allowed to talk for about 10 minutes, so it is lightning-talk-ish).

Plans

So next semester I really want to start organizing for the next Unix Friends and User Campus Kamp (Yes, the shortcut for this is UnFUCK). I really hope we can manage to get this event in the following semester, in the early months of 2016. It would be awesome to have a full weekend of nerdish talks and awesome people hanging around in our university, talking about Linux, programming languages and other foo which scratches my fields of interest.

And, of course, I hope we have some more awesome talks.

tags: #linux #open source #programming #social #software #tools

So I'm in my praxis semester at the moment, and I have to work with fastcgi++, a C++ library for fastcgi. And it is a nightmare! Here comes why...

So first, the codebase of fastcgi++ is a mess. Code snippets like

bool foo = someFunction();
if (foo) return true;
else return false;

are everywhere. You really don't want to read that kind of code. And yes, you have to actually read this code because there is no documentation on how to use the library! There is a wonderful doxygen-generated API documentation, but that does not help you because, yeah, you know the types and the interfaces now – lucky you! How to build a fastcgi module with them – figure it out by reading through the codebase!

Secondly, you are not allowed to define your custom accept() handler. You have to inherit from a Request class template and you have to implement the virtual bool response(void) = 0; method. Okay, no problem, I can do this! But then, you want to start accepting requests. You do this by creating an instance of a class called Manager:

Fastcgipp::Manager<MyRequestInheritedClass> man();
man.handler();

or something like this (this is no real code, I just want to demonstrate how it looks like). The manager accepts one connection (through many layers of abstraction, actually), creates an instance of your request class and calls response() on it.

Well, that's not a problem, is it? Well, it gets to a big problem if you want to be able to handle multiple requests at once, speaking of multithreading/concurrency here. It is a huge mess! My codebase exists of three classes, actually. A ThreadedRequest class, a BlockingQueue where requests get stored thread-safe and a RequestDispatcher which is a singleton which runs several worker threads. These worker threads take the requests out of the queue and process them if they can.

The ThreadedRequest class puts itself into the queue, which is a member of the RequestDispatcher singleton instance. The problem is not that it is unnecessarily complicated to build these 1-N multiplexing thing, but that the library provides an interface which enforces you to couple your classes realy tightly. And this is freaking bullshit.

So, finally: I'm building a wrapper lib around fastcgi++ to be able to handle requests in a concurrent way. And it sucks. But it works.

So, my conclusion is: Stay away from this bullshit library. And even from fastcgi if you can. Apache for example offers a way to write modules, so you can simply write your own module for apache if you need to – which is faster anyways!

If you have to use fastcgi, consider writing your own library!

tags: #c++ #linux #server #open source #programming #software

I just discovered that the a.vim plugin almost breaks my vim flow.

Here's why.

You might know the a.vim plugin. It was made to switch between source file and header file, including split-opening it and so on. It is really neat and I really like the idea. So I installed it. But unfortunately, it uses some insert-mode mappings which are mapped on <Leader> ... something. And as my Leader is space, it completely broke my vim flow, as everytime when I hit space, vim waits to complete my mapping... but I wasn't actually using a mapping, I was just typing.

This little offset broke everything for me... I could barely use vim. You might now say that I could set the timeout for vim to something small, like 300 or something. I tell you: No! It's just not the same.

So, I removed the a.vim plugin again. Sadly. Maybe there is an option to configure on what it is mapped, but I really don't care this much anymore!

tags: #programming #vim

Some of you might know my little project rate. It is a bash script to collect a database of things you want to rate.

What this means and why I started to reimplement in C++ – read it here!

So I started to write this application because I wanted to keep track of animes I already watched, Bands I like but do not listen to that often and so on and so forth. What the application does is really simple: You can enter notes about a certain thing (in your favourite text editor, which is vim for me) and attach tags to it and put it into a category. Then you can give it a rating. The rating can be everything, from simply numbers to text to whatever you like. But it is supposed to be a number between 1 and 10, of course. That's also the way I use it.

So how does it work? Well, that's really simple: The “rate” script creates a directory structure in ~/.rate/collections/, whereas a folder is a “collection” of things and a file is a rating. So, I have something like “movies/animes/” as collections (they are nested, of course) and then a file for each anime I watched. The filename is generated from the title I passed “rate” when creating the entry. The file also contains a “header”, which includes a unique ID (which you really should not change), a list of tags, the title (the filename is the title, too, but as on linux you shouldn't include whitespace in file names, it is not the title as you typed it) and a rating of course. Custom fields could be added to the header, but this feature is not implemented yet. After the header, you can put your description.

That's basically it. “rate” provides some features to search this database, for example you can grep for text in your entries, you can view your entries, you can list your entries and you can attach more text to your entries or edit them. As everything is git controlled in the ~/.rate directory, you can reset if you (or the script,...) messed up somehow.

There's no release by now, as it lacks of some features by now. For example I want to be able to search for entries with a certain rating or within a certain range of ratings. I also want to be able to search for entries with aspecial set of tags or within a certain collection (I can do this, though) special set of tags or within a certain collection (I can do this, already)! After these things are implemented, I will release my first version, which would be 1.0 then. And, of course, I will package it for NixOS!

So why C++

Well, I have to learn C++ for my praxis semester. That's basically it. I wanted to learn a new programming language for a relatively long time, and that's my approach on learning C++. I was able to implement some things, but not yet to run an application. My first step would be to parse my already existing entries. Hope that works. As I stated in the github repos README.md file, I do not want to use any frameworks for this. No Boost, no Qt, no other libraries. I just want to use plain C++11 (or maybe 14 in future, not sure about this, though).

Also, C++ gives me way more posibilities when it comes to features. I can refactor things really easy and maybe the C++ implementation will continue to live whereas the bash implementation will die at some point. Who knows? The point is, the bash implementation implements a file format which is

  1. really simple
  2. forward compatible

The file actually looks like this:

key = value
other = value
another = another
---

<text>

and that's basically it. The three dashes mark the end of the header and everything before the header is a <key> = <value> list, whereas each line is only allowed to contain one key-value-pair. The value can be a list of values, for example a list of Tags whereas tags are seperated by a whitespace character (space) or a string, such as the title is. The bash implementation “knows” which key has to be which value and the C++ implementation has to know this, too, of course. But that's it.

The commandline interface of the application needs some work, though. Maybe it will get some REPL-like interface later on, or maybe something more interactive. By now, it is simply an interface where you can do one thing per call. I have no problem with that and I'm planning to keep backward compatibility with the bash implementation even if this one is not even released! It is fun to write such a tool and I really like doing it.


Also, it is not a that complex thing to implement and that's a huge point to me. I don't want to spend months and months in implementing a thing which only one or two people on this planet actually use. For bigger projects, I contribute to open source projects. That's a better way to produce large-scale software, IMHO.

tags: #bash #programming #c++ #linux #shell #vim