Adventures in code and computation.



What Problems Aim I to Solve With Taskelot?

30 Jun 2015

I haven’t been working much on Taskelot lately; I got side-tracked with forking the scripts and configs from the old Crunchbang Linux project for my own use (see them here if you wish: github.com/bayprogrammer/granola). With that out of the way I am ready to approach Taskelot with some fresh thinking, and reflect a bit on where I’m at with the project, and how I need to change things to move forward.

Thinking in terms of problems and solutions

One thing my tech mentor has been teaching me is that, “in order to become a better programmer, one must become good at solving problems”. I am taking this to heart. I must consider what problems precisely I’m attempting to solve with Taskelot, and let that drive my thinking on how to develop it.

First of all, the very basic problem I’m trying to solve is this: I want to keep track of my tasks and group, sort, and filter them by project, tag, and category. I want something I can access from any device, and something that can work even when offline.

A second, indirect, problem I aim to solve is that I want some more code on my github profile that demonstrates that I know how to write programs (better yet, solve stated problems). Taskelot is the first of several planned projects I aim to build to this end. I am not just writing random code to add to my profile, but rather solving little problems I myself have, and Taskelot is my answer to one such problem.

Finally, I also wouldn’t mind being able to host this as a Software as a Service offering, for those who don’t want to worry about self-hosting but do still want to use something they can easily study and perhaps later self-host. I want to be able to earn some money from my efforts, after all. :)

Why not org-mode, or some other pre-existing solution?

I like org-mode, and it satisfies some of my needs out of the box. But I don’t think it looks pretty (oops, better add that to my problem statement), and accessing from a mobile device is somewhat involved. Furthermore, it depends on EMACS, and while I think EMACS is a sweet editor, I would like to have my todo list editor agnostic if possible.

There are several commercial apps that look nice for OS X, but I use Linux, and prefer to use tools and apps I have the source to study and modify, so those are not real options for me. (In the past I used the excellent OmniFocus and Things for Mac, check them out if you are looking for a native Mac solution!)

Also, when it comes to CLI-based todo apps, the market is already full of good solutions. I don’t want a CLI-centered solution, at least not as my primary mode of interaction, so I also rule out many other available such options. You might say, they aren’t meeting my “pretty” requirements, and some of them can be cumbersome to use (even if I generally like using the command line).

Why a web app?

I mentioned this is a prior post, but I am building Taskelot as a web application, rather than a native app (for Linux, a native app might mean one using Qt or GTK+). This is still my approach, as it meets my needs, is the technology stack I’m still most focused on working with, and the area in particular I want to show demonstrated ability with on my public portfolio of code. I believe the web also satisfies my desire to have a multi-device and multi-platform application, and with careful design and coding, it can work both online and off.

But what may change is the emphasis on it being a strictly local web app. For now I’m going to focus on making an app I can use, and not restrict myself to the vague notion I have of what a local web app might look like. Certainly one can use it locally, but I’m going to make it more a traditional web app, which can have local clients, with the default client being a rich web-based front end. This allows me to think about using a wider variety of tooling, frees me from worrying about “syncable” plain-text formats (also a former goal that no longer necessarily helps me solve my stated problems), and allows me to break things down in a more web-oriented way.

Also, as a web app, any SaaS-oriented offering I may provide in the future will automatically be positioned well for users who may use OS X or some other operating system besides Linux or BSD on a daily basis. Those other OSes aren’t my own personal priority, but for a SaaS solution the web is the clear winner to provide them with easy and first-tier application support.

Settling Some Technology Stack Decisions

It’s also time to settle on a technology stack. I am comfortable using Python with Flask and Jinja2 for this project, with Backbone and Bootstrap for the front-end app. I am not fully decided on whether to keep CherryPy, for Tornado is a very tempting alternative I am itching to try; however, whether CherryPy or Tornado, Taskelot must also be deployable behind Apache or nginx or any other reasonable web server choice.

This means I’m not going to further evaluate Bottle or Aspen for the back-end development of this project; I think both are worthy frameworks, but I must focus on just one for this project, and continuing to fiddle around with evaluating the others doesn’t really help me advance a solution to my current problem set.

In Summary

Taskelot must solve the following problems:

Continuing to build Taskelot as a web app with a back end written in Python/Flask/Jinja (plus some kind of database) and rich and responsive front end written in JavaScript/Backbone/Bootstrap (with offline access in mind from the start) continues to be a great way to solve all these problems.


1-July-2015 edit: minor grammar correction