Lately I wanted to collect my django feeds into a single web-viewable channel.

There’s more than a single solution to do this. Being django fellow, I’ve decided to utilize FeedJack.

So… Well, I guess, it might work flawlessly for other people, but in my cause it failed miserably after adding two feeds:

• official django blog http://www.djangoproject.com/weblog/ and
• djangosnippets http://www.djangosnippets.org/

Just after adding djangosnippets, it messed up the order of posts terribly.

What’s going on? The code shows.

FeedJack urls.py says:

urlpatterns = patterns('',
    [...]
    (r'^$', views.mainview),
)

That, after couple hops, translates to the fjlib.get_paginator:

def get_paginator(site, sfeeds_ids, page=0, tag=None, user=None):
    """ Returns a paginator object and a requested page from it.
    """

    if tag:
        try:
            localposts = models.Tag.objects.get(name=tag).post_set.filter(\
              feed__in=sfeeds_ids)
        except:
            raise Http404
    else:
        localposts = models.Post.objects.filter(feed__in=sfeeds_ids)

    if user:
        try:
            localposts = localposts.filter(feed=user)
        except:
            raise Http404
    if site.order_posts_by == 2:
        localposts = localposts.order_by('-date_created', '-date_modified')
    else:
        localposts = localposts.order_by('-date_modified')

    paginator = ObjectPaginator(localposts.select_related(), 
                                site.posts_per_page)
    try:
        object_list = paginator.get_page(page)
    except InvalidPage:
        if page == 0:
            object_list = []
        else:
            raise Http404
    return (paginator, object_list)

Quick introspection reveals that localpost order isn’t broken just until the FeedJack creates the paginator with:

    paginator = ObjectPaginator(localposts.select_related(), 
                                site.posts_per_page)

After that, the post order is messed up and the cause is optimizing call to select_related.

I’m not yet sure if it’s a feature or a bug, but certainly, the premature optimization is the root of all evils.

• Django - unicode branch
• python 2.4
• FeedJack 0.9.9

Good luck!

PS. Finally it was solved by leaving select_related in and adding sorting by id to preserve the original order.

No Comments »

FRIM: Another Way to Gather Data

In FRIM, the team writes 3×3 sticky notes about the events, impediments, and boons* of the iteration. (If you want to get fancy, you could use different color sticky notes for events, impediments, and boons.) Team members write sticky notes to include as many events, impediments and boons as they can remember. They may work individually or in pairs or triads if you have a larger team.

The retrospective leader draws a large 6×6 grid on the whiteboard or a flip chart-papered wall. Team members post their sticky notes on the grid according to the frequency of the event and its impact on the team.

Impact (vertical dimension)
5 = Maximum Impact
4 = Significant Impact
3 = Moderate Impact
2 = Some Impact
1 = Little Impact
0 = No Impact

Let each team member devise his or her own concept of relative impact, or, if time allows, hold a brief team discussion to define “maximum impact” vs. “moderate” or “little”.

Frequency (horizontal dimension)
5 = More than daily
4 = Daily
3 = Every 2-3 days
2 = 1 or 2 times in a Iteration
1 = Once or fewer times in a Iteration
0 = 2 or 3 times a Release/Rarely

When all the notes have been posted, review the overall story. Start by reading the notes in the top, right-hand cell first (5I-5F), then work across and down, focusing on impact first (5I-4F, 5I-3F, 5I-2F…) and frequency second (4I-5F. 4I-4F, 4I-3F…). As a group, discuss commonalities or patterns. Refer to the grid as you shift into a discussion of the insights gained by telling the story of the iteration.

How pity that some teams decide that even simplistic “what are the causes? what should be done differently?” is too difficult for them.

No Comments »

Effects of Defects: Grey Scope Creep (Agile Advice)

Fresh features are marked done, and then disappear somewhere in QA to eventually fire back at unknown time with unknown bugs. Grey scope creep. Stop it. Instead, insist on taking less but making it “done” within an iteration. Done reads fully developed, thoroughly tested, debugged, fixed including regression, and accepted by product owner.

That’s it. No comments necessary.

No Comments »