Solve the right problems

By Serdar Yegulalp | 2016/06/11 12:00


I'm back with some notes about the knotty problem I was having in the last post. Short answer: I gave up.

If you want to do tag and category archives, you will have to use a format like this for the template mapping:

[((x,y),'/{}/{}'.format(x.tag,y.title)) for x in page.tags for y in page.categories]

... or for a simple tag archive ...

[(x,'/{}/index.html'.format(x.tag)) for x in page.tags_public]

The idea here is that the first element in the tuple is a list of the actual context objects themselves. I suspect I will use this by default for any situation where the item in question returns an iterable for a single page object.

I was originally doinking around with a bunch of other high-flown ideas -- disassembling the bytecode generated by the iterable, or creating wacky proxy objects for pages, all kinds of nutty stuff. Then I calmed down and realized this solution would in fact solve more than one problem, and not be unduly difficult for either me or a prospective template designer.

Now, this format imposes a minor burden on the designer, in the form of a mild inconsistency. This format for a mapping doesn't look like the other formats. That said, it's a one-time burden, and the format of the example can be readily re-used wherever it's needed. On the plus side, this means I'm still adhering to my rule about using a Python expression for the syntax; just a slightly modified one from the original "return only a string" concept.

"Special cases aren't special enough to break the rules, although practicality beats purity."

This led me to think there are four components to solving a technical problem:

  1. Solve the right problem.
  2. Solve it at the right level.
  3. Solve it for the people that matter the most.
  4. Nobody cares how clever the solution is.

The first two are self-evident. Don't solve half the problem or only the surface of the problem; go as far down into it as you can without getting totally sidetracked. Find out where the heart of the problem really is -- not so far that you come out the other side in the Indian Ocean, though.

The third problem is also tough, but for a different reason: it requires some thought about the target audience for the solution. I don't mind making things incrementally tougher for designers in a way that is easily ameliorated anyway. I do mind making things tougher for users, if it means they can't have archives for pages and tags.

This last one is hardest when you're a programmer, because techno-weenies have this bad habit of sustaining praise for clever, elegant, beautiful solutions to problems. They hate praising solid, unremarkable solutions because there doesn't seem anything to praise there. But good, competent engineering (of which I am no font of, believe me) is always in short supply. There will never be an end of demand for doing the right thing quietly.


Tags: Python problem-solving programming tagging


comments powered by Disqus