As a reminder, this is what it looked like before.

And now we have

Enjoy!

1) It is integrated with Untappd to leverage their beer and brewery database (thanks, guys!)

2) You can search Untappd’s beer database.

3) Create as many stashes as you want to add beer to! (Don’t know if it will always be unlimited, but for now it is).

4) Link publicly to your stash of choice!

This is about as long as my release announcement is going to be. Below are screen shots of the development process.

With any new development project, the framework is setup.

And we make sure we get something to the browser.

Since my idea relies heavily on Untappd’s search, I decided that would be the best starting point. No reason to continue if, for whatever reason, that didn’t work.

Next logical step? Let’s add beers to something!

With functionality checking out, I decided to start on some design work. I tend to work better when the site looks like a fancy site and not just plain text. WARNING I AM NOT A DESIGNER NOR DO I TRY TO BE as I’m sure you will notice using the app.

Working on the layout – notice the filler information on top. Got a basic search look and feel going.

My original Lean idea was to only have one default list that everything gets added to at first, then allow for more. For various reason, I decided it would be better to allow all users to start creating stashes from now.

Starting to get fancy!

And fancier still. More astute readers will notice the name “The Beer Stash.” I tried rebranding the site when I bought the domain thebeerstash.com, but really didn’t like how it looked, so I reverted.

Making sure that the ajax was all hooked up properly for adding beers.

Rendering all of a user’s beer stashes.

Consider this more of a prototype. I wanted to see what kind of usage it got. I want people to start adding beers to their stashes. I want people to use it. I am excited for this because I see a huge potential in this that will keep me interested in a very long time. I also like the idea of blogging updates (as previous project updates will show) so maybe I’ll be blogging a lot more.

I’ve just released version 18 of Taskie. Two updates:

1. Upgraded Twitter Bootstrap to 2.0.3
2. Implemented Archiving

This is how archiving works:

When you’ve promoted a Taskie up to Comleted, the hover-over menu has a new option, Archive.

There is no confirmation, so be careful. I thought a confirm popup would only get in the way of an otherwise quick experience. Once a Taskie is archived, you can’t see them anymore, for now. I’m sure I will have to do something about it but my “Complete” status was getting out of hand.

I wrote my own with my own needs in mind. This was perfect as it gave me another reason to work on my Python and Django skills and finally be able to have some way of managing tasks that I’d like. Other things – learning Twitter’s Bootstrap – also ranked highly.

I am proud to announce today the release of Taskie, for Me. It is basic for now, but I hope to give it more functionality over time. I have a list of new ideas that I’d like to implement (being managed by Taskie – HOW META!) that I hope to get to over the site’s life. So how’s it work?

What I was trying to solve is that my projects ultimately get broken up into sub projects. And sometimes those get broken down further. I like granularity. I wanted my task management system to reflect that. That’s how I came to the idea of Taskie – each task itself can be a bigger “project,” though there is no concept of “project” in the system, Just tasks that have tasks associated to it.

Step 1 Welcome to Taskie

You’re greeted with your Taskie status bar telling you how many Taskies you have in what status. The upper right has a + button. This takes you to

Step 2: Create a root Taskie

Simple. You are required to give a title and select a priority. The description is optional. More on this later. Let’s give this a high priority. Hitting save….

Step 3: Taskie Overview

This is your top-most view. This gives you a breakdown of your root Taskies, which each one being color coded. Red is high, yellow is medium and green is low. This is all you need if you just have a bunch of stuff to keep track of, but if you want to start breaking things up into logical groupings

Step 4: Creating sub-Taskies

Hovering over any Taskie in this view shows the Tasktie actions. Promote to move your Taskie from New to Complete statuses and an open option to take you into the Taskie. This is where the magic I think is

Step 5: Create sub-Taskies

This is what you see when you go into a Taskie – the same kind of view you are already familiar with. You can create a sub Taskie from here.

So why did I go this route? Well it goes without saying that I created this to manage my projects but it had always bugged me that task trackers were more or less “flat” meaning you have one project then a bunch of tasks associated on the first level. I didn’t want that. I wanted a top most project (or task, whatever) for this project let’s say:

Taskie

From there, you can add just a bunch of loosely associated Taskies (only having one level of Taskies) or break Taskies into ideas. Let’s say I want to implement search, file management and some api for it. Those are huge ideas. I’d like to take that one huge idea and break it down further into sub Taskies that I can consume. Here, imagine that each bunch of sub Taskies make up the whole of the parent Taskie.

Here we see a parent Taskie “Some new idea” with three sub Taskies, each with a different status and priority.

Going back to before, I don’t require a description because once you reach down to the parent of a child with no offspring (essentially what you see in the top last image), it’s just a bunch of things that need to get done. Mostly of the time, one or two lines is enough to convey what you need to have done. If more explanation is needed, then the description field can be used and further sub Taskies can be created.

This is still very much in development (I don’t even have a real main image yet), but I do plan on developing it. Since I will be using this to manage not only my projects but anything else I need to have with me, so I’m sure there will be a lot of new features that I’m going to want. I just liked the idea of a task management system’s tasks being managed by itself. HOW META! Also, it wasn’t until Microsoft started using their own developer tools that they realized their tools was rubbish. I could sit here and develop this thing but until it starts to see real usage, you’ll never know how it works out. I admit, there are a lot of rough edges.

Signing up on the home page puts you in queue to get an account if you’re interested in helping me test.

echo "mysql-server mysql-server/root_password select (YOUR PASSWORD)" | sudo debconf-set-selections
echo "mysql-server mysql-server/root_password_again select (YOUR PASSWORD)" | sudo debconf-set-selections

sudo apt-get install postfix

Under “General type of mail configuration” select Local only

System mail name: localhost (I will presume from here on out that you are sending email to <user>@localhost)

Once complete, issue this command to tell postfix where to deliver mail:

sudo postconf -e "home_mailbox = Maildir/"

Now we install mutt:

sudo apt-get install mutt

And then configure mutt to know where our email will be delivered to and what kind of mailbox it will be:

vim ~/.muttrc

Paste this into the file:

set mbox_type=Maildir
set folder="~/Maildir"
 
set mask="!^\\.[^.]"
set mbox="~/Maildir"
set record="+.Sent"
set postponed="+.Drafts"
set spoolfile="~/Maildir"

Then start mutt so that it can create our mailbox.

mutt

You will probably get a message that says:

/home/USER/Maildir is not a mailbox.

Don’t worry about it for now. Postfix will fix that for us on first delivery.

This part is optional – set where any mail sent to root is forwarded to.

sudo vim /root/.forward

and in it, type:

USER@localhost

If you want all mail for root to be sent to the user mike, you’d write
mike@localhost

Now you can test this out using python

import smtplib
import string
SUBJECT = "Test email"
TO = "root@localhost" # This is to test forwarding from root to another user. if you didn't set up forwarding, use your username
FROM = "python@localhost"
text = "blah blah blah"
BODY = string.join((
        "From: %s" % FROM,
        "To: %s" % TO,
        "Subject: %s" % SUBJECT,
        "",
        text
        ),
"\r\n")
server = smtplib.SMTP('localhost')
server.sendmail(FROM, TO,BODY)
server.quit()

Now you can send mail to any users on the system. If I ever want change the delivery from local to something that gets sent out, I can follow one of the many articles on the internet describing how to set up relaying through Gmail and set my local user’s .forward to an email (not verified, hypothesized).

There is a simple work around for this: shove the value for the “next” url paramter into the session of where ever your login page is. Upon return, check to see if a session value exists for url redirection and if so, use it. Here is the code I came up with:

    # If we have a redirect URL in our session, redirect to it.
    if request.session.has_key('redirect-url'):  
        redirect_url = request.session.get('redirect-url')
        del request.session['redirect-url']
        return HttpResponseRedirect(redirect_url)
 
    # if the url has a next paramter, save it in the session
    if request.GET.get('next', None):
        request.session['redirect-url'] = request.GET['next']

Note here that where the user is redirected to if not logged in and where the user is redirected to post-third party authentication is the same for me. If you have two separate views for this, you’d break the above code up and put them where they make sense.

I will try to update my blog whenever I update the app with what I changed, but we’ll see.

1. Create a meta class for the model with a field “app_label” being set to the name of your app
2. In your __init__.py file, import that model.

For example, if you started an app by typing out ‘python manage.py startapp foo’, you can delete your models.py file, replace it with a directory named models (what I do), and inside have an __init__.py and Bar.py files.
in Bar.py:

from django.db import models
 
class Bar(models.Model):
    bar    = models.TextField(blank=False)
 
    class Meta:
        app_label = "foo"

then in __init__.py:

from Bar import Bar

This also goes for other things specified outside of the Django “norm” I guess?
If I wanted to associate Bar with the admin, I create a subdirectory inside my app named admin, and inside it I have
BarAdmin.py

from foo.models import Bar
from django.contrib import admin
 
admin.site.register(Bar)

Inside the __init__.py for the admin subdirectory, you’d have:

import BarAdmin

Now I could be doing this all wrong but this is the only way I managed to get everything working. If there is a better way to do this, I am all ears. To you Django/Python professionals out there, this may be common knowledge but I am noobing it up right now trying to better learn Python and Django.