Skip to main content

Command line issue tracking

Issue tracking is needed even for smaller projects or personal ones, but frequently the effort of setting up a complex issue tracking system for a small project is too much. A typical bug tracking system might requires a database server and a web server. Administering those is too much of a PITA.

Another severe problem lies with the portability of the bug database. For my hobby or consulting projects I like to keep the bugs close to the source - I might happen to work om my desktop, on a laptop, etc. They should be easy to move around and archive. By comparison, moving or backing up a Bugzilla installation involves unspeakable complexities that my mind simply refuses to do.  (I do realize that it is not technically complex to move a Bugzilla installation, in fact it is a relatively easy as these things go,  but it is not something that one would undertake casually - it takes preparation, time and care).

Yes, one could maintain a running publicly accessible (even only via SSh/OpenVPN) web server, and always use it, but that is a whole lot of work, not to mention the security implications and the real added expense. Plus, one is not always online.

So, until recently my bug tracking for these kinds of projects has been restricted to keeping a couple of text files called BUGS.TXT and TODO.TXT. Not very high-tech, but hey, they do the job.

That is until I found Ditz. It is a command line bug tracking tool, and it keeps all its data, including all configuration files under one neat sub-directory, plus everything is in plain text format! I absolutely love it and highly recommend it.

With Ditz the entire bug database even can be a part of the source tree, which automatically makes it distributed if one uses Git for example. (I am not sure that is such a great idea by the way - polluting the source history with bug reports - but I am still thinking about it). Moving it between computers is just a copy, and so is backup. It literally requires no thinking or effort.

While I am on this subject, todotxt  also deserves a honorable mention, although it is not suitable for issue tracking.

Bottom line, Git and Ditz provide a full featured and yet very simple infrastructure for small projects. Now all I have to do is finally start using a good command line email client.

Comments

Post a Comment

Popular posts from this blog

You Don't Like Google's Go Because You Are Small

When you look at Google's presentations about Go, they are not shy about it. Go is about very smart people at Google solving very BIG problems. They know best. If you don't like Go, then you are small and are solving small problems. If you were big (or smart), you would surely like it. For example, you might naively think that printing the greater of two numbers should be as simple as std::cout << max(b(),c()) That is because you think small. What you really should want is: t1 := b() if t2 := c(); t1 < t2 { t1 = t2 } fmt.Print( t1 ) Isn't it much better? We didn't have to type all those extra semicolons that were killing productivity before. If you don't like it, you are small. If you wanted to extract an attribute of an optional parameter, you may be used to typing something like: a = p ? p->a : 0; or even: a = p && p->a You just make me sad because obviously what you really want is: a = 0 if p != nil { a = p-...
103 comments
Read more

How to speed up a micro-benchmark 300x

How to speed up a ubenchmark 300x Static Hermes: How to Speed Up a Micro-benchmark by 300x Without Cheating This is the first of a series of light blog posts about Static Hermes, covering topics that I find interesting or amusing. It is not intended to be a systematic introduction to Static Hermes design.Consider it more like a backstage pass to the quirks, features, and “aha!” moments that make Static Hermes unique. If you’re not familiar with Static Hermes, it’s an evolving project we’re working on to explore the confluence of static typing and JavaScript. It is work in progress, but we’re excited about the possibilities it opens up for performance improvements and more. For more background: Tweet with the slide deck of the Static Hermes announcement Previous talk about Hermes Contents: Meet interp-dispatch.js Let’s Run It! Static Hermes with Untyped Code Helping the Compiler Other Ways to Help the Compiler Some Observations Revisiting The Origina...
5 comments
Read more

WebAssembly Comes to Hermes

WebAssembly Comes to Hermes Hermes can now compile and run WebAssembly modules. A standard .wasm binary - the same one that runs in a browser or Node.js - can be loaded into Hermes at runtime, or compiled ahead of time into Hermes bytecode ( .hbc ) for zero startup cost. The result is the same fast, compact bytecode format that Hermes already uses for JavaScript, executed by the same interpreter. Why does this matter? WebAssembly opens the door to reusing existing C, C++, and Rust libraries without writing native modules. Image processing, physics engines, crypto routines - anything compiled to Wasm can now run directly in the JS engine, using the standard WebAssembly API familiar from the browser. This post walks through the full pipeline - from C source code to running Wasm inside Hermes - and looks at what happens under the hood. The Simplest Example Let’s start with a function so small there’s nowhere to hide: computing the average of two integers. The C Source int avg ( ...
Post a Comment
Read more