Mar 08

staticfiles: Keeping Media Files Up-to-date

A simple trick to keep using staticfiles while still having up-to-date media files.

While working on the next iteration of www.zukx.de I discovered a simple trick to keep my sanity while working with the staticfiles app.

As jezdez pointed out in the comments, that's actually a long solved problem. One can simply use the built in views to serve static files which uses the same traversal logic as the management command.

Thank you, jezdez.

I guess I'll keep using the trick, as a status console with information about the used media is still quite nice.

Simply put this neat little app adds a management command build_static which gathers all media/ files from all those reusable apps you should be using and puts them under a (configurable) target directory.

However when developing this lead to quite a few lost nerves as changes to specific css or javascript files had to be activated by issueing said command.

The trick in the end is quite simple, open a konsole and type in:

trillian$ watch python manage.py build_static --noinput

The watch command will execute the given command every 2 seconds, leading to near instant updating of your media files - while still keeping your directories symlink free.

Feb 25

Quick update: Benkyou started

I just started the benkyou module. Actually I have been thinking about it a lot recently, and I do yearn to use it ... So this is just a quick update on my progress.

A very rough first version of the benkyou module is now available on the server. Mind you, there's nothing to do just yet. At least not in the actual learning sense.

The plan I have is simple for now:

  1. Create levels to add to your learning profile, such as - obviously - the different JLPT levels and the grades.
  2. Once added you can see your status in these, and add / remove kanji from them to your learning profile. Depending on your - not yet existing - settings you kanji are added automatically.
  3. Finally there'll be a start session button which will take a quick test.

That's it for now :-), got to go to work.

Feb 17

Dev Blog For www.OpenKanjiDic.com started

In which I talk about my ideas on discovering Kanji, start my development blog and give one-third-way up in my endeavour to finish a design document at 8 am.

So for documenting the process of implementing www.openkanjidic.com, here's the new and shiny development blog. I guess there's actually a lot to be said about my plans for the page and how it should work, or not work.

The reason there's already an online version, with the ability to sign up, log in and browse the kanji database is, that i firmly believe in always having a running version of your project. Sadly this means that some poor souls will be subjected to the unfinished site.

So to get started somewhere, here's a bit of an overview what's to be expected under those tabs.

The Kanji Tab

I like Kanji, and I like browsing through them. That's what can be done right now. But that's not really useful. What I like to do is having an interface similar to jlex.org, however I am thinking that it should be possible to reduce the initial selection from the overwhelming matrix seen on their search to 5 to 7 options at a time.

The information given by the grapheme database (kradfile) certainly makes this possible, though it's one of the more interesting problems to approach. The idea behind this is to reduce the number of choices one has to make to at each step. The human mind has problems handling more than 5 to 7 pieces of information at the same time. On the other hand the number of steps to actually find the kanji should still be as minimal as possible.

In the end it might turn out to not be a good idea, but finding out mistakes is half the fun.

Similar Approaches

Of course I'm not the first one to think of this. For example the quite interesting tatoeba.org project offers this search: Hanzis - Kanjis search. It seems to be similar in spirit, let me quote:

This tool allows you to find information about kanjis/hanzis, especially when you don't know how to input them directly with IMEs. The main way to use this is by submitting subglyph of the character.

They are using data compiled on a the Commons: Chinese characters decomposition page over at wikimedia.org. I think it will be interesting to see, whether this can be improved. (Of course, I do think so.)

Dictionary Cross Reference

The list of dictionary entries available under the page for each kanji is mildly useful at most. Already the results are sorted in the order of complexity of the kanji element of the entry, thus at least delivering a few of the more important entries directly at the top. However no ones going to read through those lists at all, and honestly why?

Once you have understood the way certain grammatical constructs work, e.g. languages are composed by the country with the kanji 語 for language those entries aren't that interesting at all ... what can be done about that?

  1. Nothing at all Maybe it's just a nice to have feature, listing those dictionary entries there, but I should invest time in other things first.

  2. Add filters for grammatical constructs. E.g. find all transitive (vt) or intransitive (vti) verbs with this. 入る and 入れる come to mind. With complexity filters this might be interesting.

I guess for now, I'll not pour too much thought into this, as there other tabs to fill, the kanji selector to write ... and so on.

Feb 16

Zukx Compus2Company

Bewerbung, Lebenslauf und Anschreiben - Tipps und Tricks. Firmendatenbank - Neuen Arbeitgeber finden. Gehaltsrechner, Messekalender und andere Goodies. Zukx - Campus2Company

Visit: http://www.zukx.de/

Feb 16

Getting Pinax 0.7.1 Tests To Succeed

In which I talk about my problems to get Pinax 0.7.1 to run it's tests without failing.

So I started using pinax, mostly just bootstrapping my project and for getting invitations and such running. However a bit of a problem is that with an out-of-the-box install of pinax there are lots of unit test failures.

Here's a run down of what I did with my social_project setup to clean that one up.

threadedcomments

I didn't bother to get the version included by pinax to succeed but used the new threadedcomments.

It's tests have a dependancy on Django==1.1, so at least for that you'll need that.

Otherwise install latest version from github, Tests will still fail, but after checking out the documentation we see how to fix that.

  1. Add django.contrib.comments to installed apps.
  2. Move comments/ in urlconf back from threadedcomments to contrib comments.
  3. Add COMMENTS_APP="threadedcomments" to your settings.

django_openid

Looks like the account.context_processor accesses the request.openid attribute which isn't set by the Mock consumers the openid tests use.

So remove the 'account.context_processor.openid' and add the following context processor:

def openid(request): return {'openid': getattr(request, "openid", None) }

Don't try this ...

if TEST_ENVIRONMENT: TEMPLATE_CONTEXT_PROCESSORS = () else: TEMPLATE_CONTEXT_PROCESSORS = ( ... your stuff ...)

Bite into the apple, upgrade django_openid and rewrite all context_processors that barf. That's the least hacky solution I came up with.

django-messages

This one is a bit funky, the tests can't never have worked as they I got them with Pinax 0.7.1.

Solution is easy peasy.

pip install -U django-messages

tribes, oembed

I just removed them ... tribes is easy to replace and not what I want anyway, OEmbed will need another look.

Finally it works...

Well mostly. There's a test in Django 1.1 which will fail with newer textile versions.
The failure itself isn't really a problem, as the difference in the tested output is added whitespace, which for HTML isn't an issue.

What bugged me about my approach is rewriting those context processors,
maybe, hopefully, there exists an approach that doesn't need this duplication.