This article is about the annoyance of programming language tutorials. First, I will argue why learning new programming languages always feels a bit like a pain to me. And then I will tell you why learning Rust was different.

I know a few programming languages. I've done things in C, Ruby, Java, Python, PHP, C++, Bash, Lisp (Racket, actually), Haskell, LaTeX, Nix, Make, Lua* and JavaScript*.

*: Only a bit, but still enough to say “I've done things in this language”

When I started learning programming, I learned Java and shortly after that Ruby. Both languages have their oddities, but besides their overall concept (imperative programming and object orientated programming) they are both rather easy to learn. After that I learned C. Learning C was a new world for me back then, as I only knew object orientation. I cannot remember which resources I've been using learning C, though I remember it was a pain. I had a good friend helping me, which was awesome, though I struggled a lot with the new concept.

After learning C, I did a fair amount of PHP. Learning PHP was simple (I actually did it in one weekend and a few thousand lines), though it again was a pain. It was a pain because of the tutorials and resources. And that's the point I want to discuss here.

All other programming languages I've been learning so far were painful to learn. Not because of their concepts (see Haskell, functional programming at all), but because of the resources. Haskell is a really good example here. There is exactly one resource I enjoyed while learning Haskell, and that's “Learn you a Haskell for great good”. And why? Because it takes your hand and shows you the new world. It is good because the concept of functional programming is new for most people reading this resource. Learning JavaScript, Bash, Lua or Python sucks because you already know what an object is. You know what a function or method is and you know that the basic syntax for arithmetic is the very same as in the languages you've been using by now. But all tutorials expect you start from zero – which is fine if you're actually starting from zero, but most of the time you're not. After learning Java and Ruby I understood what OOP is (actually not after learning Java, but after learning Ruby, because Java isn't a fully object oriented language in my opinion).

So, learning Haskell was kinda amazing. Learn you a Haskell is a really great book and if you want to learn Haskell, you really should read it. But what was even a better experience was learning Rust.

So why is that? It is because Rust is a new concept and the old concept (imperative programming). Learning Rust is not like learning Python after learning Ruby. It is like Learning Haskell after learning Racket. The concept behind the language is kinda the same, though it is different in most details.

Plus, the Rust tutorials and resources are freakin' awesome. Let me repeat that. The tutorials and documentation of the tools, libraries and everything, the resources on how to do things, are awesome!

Every documentation for each library looks exactly the same, which is a huge advantage over other languages library documentations. cargo, the Rust build-tool builds the documentation locally for you, if you want that. So working offline after you fetched the dependencies or your project (also via cargo) is no hassle. Building a new project with cargo is absolutely painless, its literally just executing a command, editing a textfile and executing another command (setting up the project, writing down dependencies and meta information about the project and building the project, which fetches the dependencies).

So really, if you want to learn a new programming language, check out Rust. I haven't even talked about its language features, and I will not, as this is not the goal of this article. This article is about resources and tutorials. And my conclusion is:

All programming language tutorials suck. Except the Rust language tutorial. tags: #programming #open source #bash #c #c++ #haskell #nix #racket #rust #shell

I did it! Just hours ago I released imag in version 0.2.0.

Read here why I did that, despite there are few things working and I do not even consider this stable or even stableish.

First of all: This is not production-ready software. Use at your own risk! This is a release for people to notice that some things work and one could start to play around with it. Do not trust imag with your personal data if you do not have backups. There are bugs. This is not perfect. This is alpha quality or pre-alpha quality software!

imag is a personal information management suite for the commandline. Its target audience are commandline- and power-users. It does not reimplement personal information management (PIM) aspects, but re-uses existing tools and standards to be an addition to an existing workflow, so one does not have to learn a new tool before beeing productive again. Some simple PIM aspects are implemented as imag modules, though. It gives the user the power to connect data from different existing tools and add meta-information to these connections, so one can do data-mining on PIM data.

How the release was done

What did I do to get to the release? Well, not that much. I checked out the master branch and created a v0.2.0 branch on it, then started to fix things up for the release. That included:

• Moving the dependencies for all crates to “0.2.0”. That means that all crates in the imag code repository do not depend on other crates from the imag repository by their path but via crates.io and the “0.2.0” version of the crate. I had to do that to be able to publish these crates. This change wasn't done in master, so we can continue to work on multiple crates at the same time and do not have to cargo publish each crate independendently before beeing able to use it in other imag crates.
• I fixed the dependency markup in imag-store (actually two times) and the version information in libimagbookmark and imag-bookmark (in two seperate commits). Why is that? Well... because nobody is perfect. I simply missed them when updating the version strings from “0.1.0” (which is generated by cargo new) to “0.2.0”.

Then I manually published libimagutil and libimagerror because they do not depend on other imag crates themselves. After that I cargo published all crates in a loop until all of them were published. In the end I cargo published bin (the imag crate itself) and .imag-documentation (the documentation crate which does nothing by itself and just depends on all other crates for building the documentation).

I removed the v0.2.0 branch and created an annotated tag for the release.

Why now

I released imag 0.2.0 today because there are only few things left in the milestone for the 0.2.0 release and all whats left is tagged with release/optional, saying that these things are optional for the release (the issues will move to the next milestone, so they might not be there anymore when you click on this link).

The commit I based the release branch on was more-or-less random. It does not mark any special point in time or something, I just started to branch off of it.

Why releasing if not ready?

Why did I do the release if the software is not ready and nowhere from stable or even stableish?

That answer is pretty easy: To have a point to refer to and to get into a cycle (a release cycle). I'm pretty confident that this version is a point where interested people (read: interested developers and possible contributors) could start playing around with the software. Clearly, bugs are there and things will break. But, as imag is a rather complex piece of software and a large project, I wanted to have a point where people can be notified “Hey, this is working(ish) and you could try it out” so they can jump on the train.

And that's really what I want. I do not want to develop this monstrous project alone. I want the collaborate on this and hear what people want and need. This project solves my personal problems with PIM, but I'm sure that others will benefit from it as well and therefor community efforts are deeply encouraged by me. Or at least I hope that I do communicate this clear enough.

What's in there

Do not use imag if you do not have backups. See above for more detailed warning note.

What we have by now:

• imag-bookmark – A tool to keep and organize your bookmarks
• imag-counter – A simple counter tool. Create, delete, increment and decrement counters
• imag-diary – A diary
• imag-link – Link imag entries with other imag entries
• imag-notes – Create notes
• imag-ref – Reference files on your Filesystem with imag
• imag-store – Core plumbing tool. Do not use at all if you do not know what this is for.
• imag-tag – Tag imag entries
• imag-todo – Todo management with imag, using taskwarrior as backend. This is not a replacement for taskwarrior, but can be used to create entries in the imag store for each taskwarrior task and then these entries can be linked with imag-link.
• imag-view – View entries from the imag store
• imag – The imag binary itself. The purpose of this is to be able to call imag view instead of imag-view.

Clearly this is not everything. We have a huge number of libraries which work under the hood of these executables, but users might not care about this.

What's coming

Well, what's coming for the next release? The 0.3.0 milestone already exists and there are a lot of things already registered in it.

When will I be there? Well, my initial goal was to release 0.2.0 before 01-01-2017, so I clearly managed to get it out in time. I also announced that I want to do 3-month release cycles, so the next release would be due by March 31, 2017. I will keep that goal as I'm really not sure how fast I will be. Maybe we can release 0.3.0 early, but as normal in open source: The next version will be there if its ready.

I hope to land a imag-mail module in the next few weeks, so one can start tracking email with imag. I also hope to land imag-annotation to be able to annotate other entries with notes. imag mv will also be a thing that should go into 0.3.0 as well as more imag-view functionality.

And, of course, there will be a ton of enhancements to the libraries in imag.

Can I use imag libraries in my project?

No.

Well, you can, but I do not guarantee any stability or API consistency or something. But if you want, you clearly can use one of the imag libraries (they are on crates.io, so why not). Just keep in mind that interfaces will change and things will break and bugs will happen. We are 0.2.0 here, not 1.x.y. Keep that in mind.

For the curious, non-developers: imag consists not of one command/binary but of many. Each of those has a library accociated with it: libimagdiary and imag-diary where the imag-diary project is only a commandline interface to libimagdiary. There are some general purpose libraries in the imag codebase – for example libimagerror which are used by all other crates for a certain thing, error handling in this case. These libraries can be used independendently of imag itself. As said above, I do not guarantee anything in regard of API stability or such, so one could use them outside of imag, but I do not encourage it.

What now?

Well, I won't change my day-to-day rhythm when developing imag. As said, the 0.2.0 release was done to get some attention on imag and to people notice that some things might work, to play around and to report issues. 0.3.0 will be the same kind of release, but with more features. I don't know when I will be confident and say “Yep, one could now start to actually use this”, but I guess that it won't be 0.5.0 or 0.6.0 (which are not even planned by now). Maybe it will be 0.10.0 – who knows.

It also really depends on whether there will be (long term) contributors or not. If some people start working on imag more frequently and I can get a small community build up around the project, imag might be in a usable state “pretty soon” (read: within 2017 or 2018).

If not, ... I don't know. It's really that kind of project that runs forever. Does that bother me? A bit, ... but working on imag is fun and a pretty nice hobby... so I don't care that much.

That beeing said... feel free to play around by installing the imag crates (and having backups) and maybe you will be in the git log of the next release?

tags: #linux #open source #programming #rust #software #tools #imag

I wrote about imag before. I wrote about the problems I see with PIM on the commandline and how I want to solve them.

Well, it happens that some of my friends stepped up and reviewed the implementation (in manner of Software architecture) and suggested a design-overhaul. So this is what is happening right now.

As I stated before, I wanted the whole project to be a bit like git: each subcommand is an own executable, you can easily re-use parts of the code in your own projects as library and so on. This was one major point why we removed the whole codebase and started from scratch. Well not really from scratch, as the history is preserved and we can re-use parts of it by digging into the git-history. And, of course, the experience is not lost at all.

But before we did that, I set up a document where we can specify and document what we do. The major point of the paper is to define how the modules should work and what kind of interface they should export.

Some of these things are work in progress, some other things are already defined.

The roadmap changed a lot, of course. As we have now several libraries to implement and later glue together, we have a lot work to do on defining interfaces and (re-)implementing functionality.

I consider this as great opportunity to learn a whole bunch about software architecture.

We also applied some tweaks to the repository. We have now homu for merging and editorconfig so we are all in the same coding style.

The paper is written in pandoc-Markdown, so the paper can be read in either Markdown with your favourite text editor, PDF or as web-page (HTML). Both of the latter have to be compiled first, of course.

I hope enough people care about this project, so we can make it happen as fast as possible. I really want this to succeed, as I would personally benefit a lot from it.

More posts on this topic will follow, of course.

tags: #linux #open source #rust #software #tools #imag

In my blog article On the sad state of PIM for nerds I ranted over the lack of a PIM (Personal Information Management) suite for the terminal (and therefor for nerds like me).

I said that such a suite would be awesome to have and I listed some core features such a suite should have. I also said that I might not have the time for this. I was wrong. I just released version 0.0.1 of “imag” today.

“imag” stands for “Information ManaGement”. Not that creative, though I like this name. I just released version 0.0.1, which is in pre-alpha shape. I also only contains one “module” of the whole idea – a bookmarking module, where you can store your bookmarks and add tags to each of them.

The roadmap

There is a roadmap on github, this is the idea:

• Release v0.0.2 : Notes Module.
• Release v0.0.3 : BM + Notes combination, where one can link to bookmarks from a note
• Release v0.0.4 : Show meta-module for showing content of arbitrary modules
• Release v0.0.5 : Todo Module. Might wrap taskwarrior here. Not decided yet.
• Release v0.0.6 : Calendar Module, using icalendar standard
• Release v0.0.7 : Contacts Module, using vcard files

These are the releases planned so far, more planned Modules are (in alphabetical order):

• (Shopping)Lists Module
• Bibliography-Management Module
• Diary
• Ledger – to track personal finance
• Mail Module – to index email and link to from other content
• Movie library tracker – to index movies and link to from other content.
• Music library tracker – to index music and link to from other content.
• News Module – RSS/Atom, maybe using external tools like newsbeuter, undecided.
• Podcast module – implementation details completely undecided here
• Project planner – implementation details completely undecided here
• Wiki Module – expansion of the notes module with subpages and so on

Other things to do

There are more things planned in the github issues, like output formatter, where we can print all things with JSON (for example) so one can include “imag” in scripts. Also, an integrated webserver where one can view content as website would be nice (though I don't like the idea of editing content via a web page). Basically I'm open to all ideas.

Also one major paint point right now is the following: I have not yet integrated git support. So the file store is not yet version controlled, and I really have to do this soon, so I'm save.

I also did not think about encryption yet. I am thinking about encrypting the store and decrypting it on every call to “imag”, but I'm not sure whether this is the right way, as some application might call “imag” in background later (see next chapter). I'm not even sure whether I should encrypt the store at all, as the user should encrypt his or her device anyways.

Implementation, License, call for contributors

Well, as I want to be safe, I implement “imag” in Rust, my new favourite programming language. If you want to learn Rust, you are welcome to join me, as I'm also still learning things.

“imag” is licensed under the terms of LGPL v2. This is because “imag” might be used to be integrated into other software, maybe someone wants to write a curses frontend for “imag” at some point? Maybe vim plugins? Or something similar? I'd welcome it!

That said, I have to implement the core features first. Linking between content is one of my desired core features and will follow as soon as the notes module is implemented. As the readme file also says, there is a lot to implement, but not that much modules with actual user input. Only four modules: Notes, Shoppinglist, though I guess I will implement this one without user-input support as it only holds a list, then the wiki module and the Bibliography module, whereas I'm not sure whether this one has user input as well. So basically two modules have actual user generated input (speaking of text a user is supposed to edit with an text editor). All other modules contain structured data (JSON) the user can edit via the commandline.

All this is not carved in stone yet and I'm happy to argue about the points I just mentioned. Also I'm happy to argue about more modules and of course I'd love to see pull requests on github!

So feel free to contribute!

tags: #linux #open source #rust #software #tools #imag

Almost all issues for the 0.2.0 release of imag are done.

Here are some notes how I want to do releases before the 1.0.0 version of imag, which, of course, is really not there yet. But I had to think about a decent release strategy for the 0.x.y releases, so here the notes.

imag is a personal information management suite for the commandline. Its target audience are commandline- and power-users. It does not reimplement personal information management (PIM) aspects, but re-uses existing tools and standards to be an addition to an existing workflow, so one does not have to learn a new tool before beeing productive again. Some simple PIM aspects are implemented as imag modules, though. It gives the user the power to connect data from existing tools and add meta-information to these connections, so one can do data-mining on PIM data.

First, all the things I note here apply to releases before 1.x.y, so basically all 0.x.y releases.

I want to do 0.x.0 releases with a bunch of new features every 3 months or something like this. This time range is not fixed, and releases will happen if they are ready, but 3 month is a good first idea, in my opinion.

I won't declare a fixed set of features for every new version, but move around some features as I like, but I try to keep the number of changes decent. For example, the 0.2.0 release has 49 closed and 13 open issues/prs at the time of writing. As I sometimes do more PRs per issue and sometimes just one PR for one issue, or even file PRs without an existing issue in the first place, this number might vary, but I guess about 100 issues/PRs per release should be a maximum.

What I want to do, and what I already do: I mark issues as

• optional if they are optional for the release they are attached to
• soft-required if I would like to get them into the release but wouldn't mind moving them to the next release
• hard-required if they have to be in the release.

I also set a release date. hard-required issues will get my attention first, I try to implement them as soon as possible and get them ready. After that I focus on soft-required things and after that on optional things.

hard-required issues might postpone a release date. soft-required and optional issues do not. But if an issue has to move to the next release, because the release-date is near and the issues are not solved by then, they will automatically advance.

That means, if an issue is optional in 0.2.0, it will get soft-required if it has to move to 0.3.0 and hard-required if it has to move to 0.4.0.

This way, one can easily calculate when a feature will definitively be implemented in the imag codebase.

---

Another thing I try to do: Plan ahead a bit. At the time of writing, the milestones for 0.2.0, 0.3.0 and 0.4.0 exist. I won't create a 0.5.0 milestone before 0.2.0 is done, so I try to plan ahead about two releases, which equals about six months.

---

I will do y-releases (as in 0.x.y) if I encounter a really serious bug. But as we do not guarantee anything right now (see below), I doubt that will ever happen.

---

All the things I wrote above are ideas how I want to do it. I will see how things work out and we'll see whether this is doable for me or not. As I already said somewhere, I'm starting my masters degree this week and I don't know how the workload will be. I really hope I can get things implemented as planned, but I might have to move issues to future milestones if I notice that things are not doable for me in the planned time.

Also, as we are in the 0.x.y release phase, I won't give any guarantees on stability and interfaces an so on.

tags: #linux #open source #programming #rust #software #tools #imag

I recently started to learn a new programming language: Rust. And I really have to say: This is the kind of language I always wanted. Some parts are not as nice as I'd like them, though most of the language, the tooling, the compiler and everything else is just so damn cool.

But first, for the new readers of my blog:

Where I came from

I learned Java as first programming language when I entered 11th grade. I learned the stuff really fast and I started to learn Ruby right after. This was about the time of Ruby 1.9.2 and 1.9.3 – and it really was an awesome time.

Later I learned C, all the way down from “Oh my gosh, why am I getting this segfault – oh, I didn't allocate properly” to linux kernel patches. I really have to say it was fun and I enjoyed learning it, though I really don't want to implement a larger project in C. C is for systems programming deep down directly at the hardware.

On my way from 11th grade until today, I learned a fair amount of languages, some of them just really briefly, others more closely: Ruby, PHP, Bash, Java, Haskell, C, C++, Scheme/Racket, Nix, Python, Lua, SQL, HTML/CSS, SASS, HAML, Latex, JavaScript, vimscript and, of course, lately Rust.

Where I don't want to go to

I have three languages I want to write in future. Maybe four. Let me elaborate:

Haskell

Nice language, though for academic use only IMHO. I really don't want to write Haskell for production systems, if possible. I still can understand why people do this and even when people start new projects with Haskell as programming language, though I wouldn't do that myself.

PHP

Do I really have to explain this? I mean, PHP was great in the '90s and maybe early 2000s. But today, there are much better alternatives available.

HTML/CSS

Yes, you kind of have to write these languages in web development, but I'd opt for SASS and Haml. They are both nice preprocessor languages which are much simpler to use.

JavaScript

I didn't learn much about JavaScript by now, though I don't think it is a language I would want to use except for website animations.

Scheme/Racket

Nice languages! I really enjoy reading them, though I don't see any value in them for large production systems. Their tooling just looks to bad (from the outside) and while I'd love to see better tooling here, I don't really care about these languages.

Java

Nope.

Python

I see a lot of value in Python for small scripts, but not for large production software like web frameworks or similar. Yes, this was a hint in direction of Django!

Lua

Nice language for embedded stuff and so on, though I don't really care too much about Lua either.

SQL

The standard when it comes to database querying. Though I really don't want to write these things by hand and I really would love to have ORMs widely available (and yes, every major language has an ORM, I know that and I like it).

Latex

Can we please just have pandoc succeed and write our stuff in Markdown? I mean, yes, Latex kindof works, but when it doesn't it just sucks as hard as hell!

vimscript

Another thing I don't want to have to touch.

C++

There are better alternatives available... this is why I'm writing this post!

Where I want to go to

Yes, there are languages I like. It's really just three/four, but they clearly exist: Ruby, C, (Bash) and Rust. Each of them with another purpose. Bash is in parentheses here because I kindof have to use Bash, let me explain this first:

(Bash)

Bash is syntactically just disturbing. I mean, its syntax just sucks, right? But it is the default on all Unix systems and that won't change, so for scripts, I just adapt to this default and keep my things in Bash.

I know there are alternatives like fish, zsh and whatever. I cannot use them because of two reasons: If I change my shell, I want to change it everywhere, means I would need to convert all my scripts. This is a huge amount of work. And, I'd still have to write bash when contributing to nixpkgs, and not contributing to nixpkgs is just no option for me.

So, for the sake of uniformity, I just keep everything in bash.

Ruby

Ruby is awesome. I love its syntax, I love its tooling (though I don't have to mess that much with it).

I just don't want to implement complex things in it. I started to learn rails and I really like rails, despite it is a monster from my perspective. There are other web frameworks for Ruby available which are much less complicated. I speak partly of Sinatra, but also of Lotus which seems quite nice to me (again, from the outside).

Of course there are others.

C

C is,... well C. It is awesome for small bit-fiddeling work and OS kernels. It is great for microcontrollers. It is just as simple as possible a high-level-assembler language can be.

I really love writing C, though I also think one has to avoid it whenever possible.

Rust

Now I finally hit the chapter this whole blog post is about.

Rust. Is. Awesome.

I mean, really. It comes with the tooling of Ruby, cargo the package manager/build tool/test runner/everything just works out of the box and as good as one can imagine. Working with dependencies just works (if you get your types right). The language itself is really nice. I mean, I worked with for about one month by now and I really enjoy every problem I encounter in manner of a learning experience. I learn with every problem and I also learn to avoid problems really quickly.

Rust gives me power to my hands I couldn't even imagine when I was in 11th grade. I can write high level code like in Ruby, but I can also go into detail and fiddle around with bits and everything, without having to worry about References and pointers, data races, bla bla bla (take that, C++)! If the compiler tells me that I've done everything right and it compiles my code, I can be sure that the program won't eat my head while running. It might not do what I want, but it does what is written down without crashing in random places!

So, with Rust you get:

• If it compiles, it works (Haskell)
• It is fast ©
• You can build complex applications with type safety (C++ (though “type safety” is a stretchable term in C++))
• You can write high-level code (Ruby)
• Easy syntax (Ruby)

Summary

So, to summarize: Bash for system scripting, Ruby for more complex scripting tasks, C for embedded/system programming, Rust for everything else from systems programming to building space rockets.

If you haven't learned Rust yet, go and give it a try! You will be amazed!

tags: #programming #open source #rust

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 have a problem. I want to write a small application. It should be a commandline application, but maybe I want to extend it later with a GUI or even a web interface. But I don't know what language to write it in.

This article could also be named “Which is the right tool for the job?”

The idea is simple: I want to write a journal-application, where one can take notes, tag them, query the journal for entries, optionally provide filters before printing them to print only some of them and so on.

I want to be able to encrypt them with gpg and I want to write posts to the journal with vim. I want to be able to configure these steps, of course, so I can use a certain key for encrypting the journal or maybe another editor (for these emacs lovers out there).

It should be designed to be extensible, so I can add a GUI or web interface later on. Or maybe a tex output, so I can compile a PDF out of it or something. Posts should be written in standard markdown, so this wouldn't be a big deal.

But I don't know what language to write it in. The languages which I can or would choose from are:

• C
• C++
• Haskell
• Rust
• Java (not really...)
• Scala (not really either, it's still JVM)
• Ruby
• Python (by extending jrnl)
• Racket
• Lua
• Bash (I really don't want to write it in bash, but it's still a possibility)

As you can see, the first four languages are compiled languages, then Java and Scala are (lets call it) Semi-Compiled languages and the others are scripting languages. All of these languages have certain advantages over others.

The compiled languages

... have the advantages that they are fast. Haskell and Rust also have the advantages that if the compiler does not fail compiling the sources, the program just works ™.

Also, learning C++, Haskell or Rust would be a really great experience and may be beneficial later in a job or something.

The semi-compiled languages are also (kind of) fast, but they are JVM-languages, so I won't look into them here...

The scripting languages

Writing the application in a scripting language would have some other advantages: They would be much more flexible and I'd be faster writing the application (compared to Rust or Haskell, which I would need to learn with the application). I don't need to learn Ruby, I know a fair bit of Racket and I guess I can get productive with Python or Lua really fast.

Bash is another option and I'm actually an bash script for an almost similar job right now. I could simply extend this script, that would be an option, of course.

So which is the right tool for the job?

Can you tell me? I don't know which tool is the right tool for the job. After all, I don't think I should write such an application from scratch. So, for me, there are two options left: Extending jrnl, which is an Python script, or extending diary (I do not even find a link for this anymore), which is a bash script. Extending the bash script would be an easy job, I guess. But it wouldn't be as flexible as the Python tool is already. tags: #bash #c #c++ #haskell #programming #racket #rust #shell #tools

I already wrote about the project me and some friends at my university are currently doing. One of my team mates came up with the idea of porting the codebase from C to C++, yesterday the appropriate issue was opened Yesterday, to discuss it. I'm not sure what to think.

The idea is to port the codebase as soon as possible to C++. I do not like this idea entirely, as I think the port should be done after the project phase, but not within. I consider myself at a newbie-like level when it comes to C++ and I think other project members feel almost the same, maybe better, but not on an expert level or whatsoever. Given the fact that we're already running out of time, I think a port of the (30K LOC) codebase would quite take some time and would cause the project to be delayed even more.

So I'm trying to push back on that part. A port after the project phase would be another question, which I want to talk about here.

First of all: I don't think a port to another language is required, as I consider the codebase as very clean and carefully designed. The architecture is good, the code is well documented, the abstractions are clearly defined. A port to another programming language would have a certain level of impact on this, but I think we are able to handle that. I see the improvements which could be made by a port to a OOP(-like) language, though.

Having inheritance build into the language, having a template-like system in the language and having methods, virtual functions and the like would cause some redesign but also some improvements.

My project mate suggested C++ as language. Now, the careful reader knows that I don't like C++ that much. Some of my points are maybe valid, some not. But well, this is a very opinion-based topic, and I won't go into further detail or discussion about that topic here. What I think, though, is that it would be nice to port to a language which gives us more power (simplifying to the terminus “power” here to refer to possibilities to do abstractions, building complexity and the like) and security. I think C++ gives us more power about the code, which is very good. I don't think C++ gives us more security, meaning secure code. I think one can very simply do the same mistakes in C++ as in C, speaking of semantics of the code. For example you can create data races, thread related problems or memory corruption in C++ as well as in C.

That given, I consider C++ as an improvement to the code, but not the best possibility. My opinion is currently that a port to Rust would be a much better option, as Rust gives us memory safety, prevents us from doing nasty things with memory, including all the thread stuff. Given the fact that none of us is able to write Rust on an expert level by now, the question of doing the port within the project phase or after is answered automatically. Also, Rust is not stable yet. I would at least wait for version 1.0 of the Rust language before doing the port, possibly saving some time of Rust-to-Rust porting.

I still don't think a port is necessary and I really like the code we produce. I can see the advantages over staying in C, but for me personally, the disadvantages overweight by now. This may change in future, but for now and for the rest of the project phase, this is my opinion on the topic.

The discussion on github is not done yet, of course. I will carefully propose my opinion there, as this has become a very explosive topic by now. This article was just written to be a short overview over the topic and also to be a summary of my thoughts.

tags: #programming #c #rust #c++ #software

This is the 24th iteration on what happened in the last four weeks in the imag project, the text based personal information management suite for the commandline.

imag is a personal information management suite for the commandline. Its target audience are commandline- and power-users. It does not reimplement personal information management (PIM) aspects, but re-uses existing tools and standards to be an addition to an existing workflow, so one does not have to learn a new tool before beeing productive again. Some simple PIM aspects are implemented as imag modules, though. It gives the user the power to connect data from different existing tools and add meta-information to these connections, so one can do data-mining on PIM data.

What happened?

In the last four weeks, not that much happened. Mainly, because I was on vacation. Semester ended on Feb 21st, so from there on I did exactly one thing: Enjoy my free time.

Nevertheless, we got some things done in the imag codebase:

• #801 merged the initial support for annotations.
• #897 merged a new feature which gives us the possibility to build imag with the early-panic flag, which causes the store to panic on a failure rather than to throw errors. This is mainly for debugging, not for production use.
• #900 merged improvements for the libimagstore documentation.
• #901 merged some notes on long-term todos which would perish in the github issue tracker.
• #902 merged some improvements on the Ruby API.
• #903 improved the libimagrt documentation.
• #907 updated clap.

Four PRs are not in this list because they are too trivial.

What about Ruby? Well, because of the little progress, nothing happened in regards of the Ruby bindings. But we get there, I promise.

What's coming?

I don't know yet. My 2nd semester for the masters course just began and I really don't know what the workload will be. So... this is all in all a rather sad update, I guess. Progress slowed down a lot, I don't know what will be there in the next four weeks...

We'll see...

tags: #programming #rust #software #tools #imag