Add post: Whats coming up in imag (29)

1 files changed, 86 insertions, 0 deletions

diff --git a/content/blog/2017-10-08-what-s-coming-up-in-imag-29.md b/content/blog/2017-10-08-what-s-coming-up-in-imag-29.md
new file mode 100644
index 0000000..8d9fcef
--- /dev/null
+++ b/content/blog/2017-10-08-what-s-coming-up-in-imag-29.md
@@ -0,0 +1,86 @@
+---
+title: "What's coming up in imag (29)"
+date: "2017-10-08T17:59:40"
+tags: [ "linux", " open source", " programming", " rust", " software", " tools", " imag" ]
+---
+
+This is the
+29th
+iteration on what happened in the last four weeks in the
+[imag project, the text based personal information management suite for the commandline](http://imag-pim.org).
+
+<!-- more -->
+
+<small>
+	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 <i>addition</i> 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 <i>connect</i> data from different existing
+	tools and <i>add meta-information</i> to these connections, so one can do
+	data-mining on PIM data.
+</small>
+
+# What happenend?
+
+Because we had approximately 40 merges
+(as of [19b5b53b2a](http://git.imag-pim.org/imag/commit/?id=19b5b53b2add5a2a123f4737aeab24be7922e8e8))
+since the last blog post, here only the most relevant ones.
+
+* [05c7467866](http://git.imag-pim.org/imag/commit/?id=05c7467866b680865ca7549cac1ed70e3c0a1849)
+  This pull request added `imag-diary`-functionality, so one can configure which
+  diary uses what kind of entry-creation (either minutely, hourly or daily).
+* [b4e6200eab](http://git.imag-pim.org/imag/commit/?id=b4e6200eab8e50ec4447e2a677d4a1876938cb17)
+  Added helper iterators for the `libimagstore`.
+* [a5951e6951](http://git.imag-pim.org/imag/commit/?id=a5951e6951cf8b079c18f0e33b7a3d87ef08e2cc)
+  changed `imag-notes` to use positional arguments.
+* [b853e35a05](http://git.imag-pim.org/imag/commit/?id=b853e35a05ac230e433c547e060c7460bb2ab07d)
+  introduced `imag-grep`. Have a look at this crate to see how easy the imag
+  ecosystem can be used to write basic tools and functionality.
+* [d97b77c30c](http://git.imag-pim.org/imag/commit/?id=d97b77c30ccddbb4b3e74b4a4962fbbe216b2192)
+  changed `imag-tag` to use positional arguments.
+* [4b906f27b1](http://git.imag-pim.org/imag/commit/?id=4b906f27b1e11f2fec64b06dae5f4a258976da68)
+  fixed the header location in `libimagentrytag`, which did not follow our
+  conventions.
+* [e7ec39bdcc](http://git.imag-pim.org/imag/commit/?id=e7ec39bdcc7b9e0b372efcc17ec19d977bd73921)
+  fixed the `imag` binary to pass arguments which are auto-generated by
+  `libimagrt` for all binaries.
+* [1e7e6ab601](http://git.imag-pim.org/imag/commit/?id=1e7e6ab601ccd36275106e53488d20c551678bdb)
+  changed `imag-ref` to use positional args.
+* [f8d6789dd9](http://git.imag-pim.org/imag/commit/?id=f8d6789dd9c762680b8fdd09ec8ceb43cacc1e8b)
+  added `imag-gps`.
+* [d8055b4553](http://git.imag-pim.org/imag/commit/?id=d8055b45538bd28f10e230e0ccf3c11fe5b64b3d)
+  removed `imag-counter` as well as `libimagcounter`, which are not that
+  usable after all.
+* [ecc8cc4567](http://git.imag-pim.org/imag/commit/?id=ecc8cc4567bd2f0522cb32b00c36e7b7ae14c37d)
+  removed the `FoldResult` helper type, because these things can be done with
+  `FromIterator` from the standard library.
+* [19b5b53b2a](http://git.imag-pim.org/imag/commit/?id=19b5b53b2add5a2a123f4737aeab24be7922e8e8)
+  added `imag-mv`.
+
+So, to recap, we introduced three new tools in the imag codebase in the last
+weeks: `imag-grep`, `imag-gps` and `imag-mv`. Though these are rather simple
+tools (all of them are "plumbing"), we were able to fix a lot of bugs when
+implementing these tools.
+
+# What will happen
+
+Right now I'm working on `libimagcontact` and `imag-contact`. I hope to get
+this done in the next four weeks, although I have to implement a `rust-vobject`
+high-level interface for it, which is work-in-progress at best.
+
+I'm also playing around with `cursive` to implement a _really_ basic terminal
+user interface for viewing imag entries. But that is highly experimental and I
+don't think I can come up with something which can be tried out in the next
+four weeks... I would even be surprised if I can come with something basic
+until christmas.
+
+As soon as the `libimagcontact` things basically work, I would love to start
+implementing `libimagcalendar`, which also requires me to get `rust-vobject`
+"ready-ish".
+
+So, still a lot to do.
+