Affiliations

» See a train - click here

We are happy to release: Django-Extensions Version 1.3.9

This brings the usual tons of fixes and improvements

Get it at: https://pypi.python.org/pypi/django-extensions/1.3.9

Changes:
  • Feature: shell_plus, add --kernel option to start as standalone IPython kernel
  • Feature: reset_db, Programatically determine PostGIS template
  • Feature: sqldiff, add support for PointField and MultiPolygonField
  • Test: renamed test app
  • Fix: runserver_plus, --print-sql for Django 1.7
  • Fix: shell_plus, --print-sql for Django 1.7
  • Fix: show_urls, add support for functions that use functools.partial
  • Fix: show_urls, add formatter for aligned output (will most likely become future default)
  • Fix: shell_plus / notebook, support for Django 1.7
  • Docs: various fixes and improvements
  • Cleanup: Remove work arounds for Django 0.96 and earlier

Posted on July 30, 2014 With tags: 1.3.9, django, extensions

Add to:  

0 Comments

We are happy to release: Django-Extensions Version 1.3.8

This brings the usual tons of fixes and improvements

Get it at: https://pypi.python.org/pypi/django-extensions/1.3.8

Changes:
  • Feature: show_urls, add option to specify dense or verbose output format
  • Improvement: better support for django 1.7 migrations
  • Improvement: better support for django's admin docs
  • BugFix: runjob, job_name and app_name was swapped in error message
  • Docs: Update link to chinese docs
  • Python3: unreferenced_files, fix python3 compatibility
  • Python3: pipchecker, fix python3 compatibility

Posted on June 12, 2014 With tags: 1.3.8, django, extensions

Add to:  

0 Comments

We are happy to release: Django-Extensions Version 1.3.4

This brings the usual tons of fixes and improvements

Get it at: https://pypi.python.org/pypi/django-extensions/1.3.4

Changelog:
  • Feature: Start maintaining a CHANGELOG file in the repository
  • Feature: ActivatorModelManager now has an ActivatorQuerySet
  • Feature: Add a deconstruct() method for future Django 1.7 migration compatibility
  • Feature: show_urls, now support --language for i18n_patterns
  • Feature: show_urls, now shows the decoraters set on a view function
  • Feature: graph_models, now support --include-models to restrict the graph to specified models
  • Feature: print_settings, allow to specify the settings you want to see
  • Improvement: graph_models, use '//' instead of '#' as comment character in dot files
  • Improvement: graph_models, added error message for abstract models without explicit relations
  • Improvement: JSONField, use python's buildin json support by default with fallback on django.utils.simplejson
  • Improvement: PostgreSQLUUIDField, parse value into UUID type before sending it to the database
  • Improvement: Use django.JQuery in autocomplete.js if available
  • Improvement: use "a not in b" instead of "not a in b" in the entire codebase
  • Removed: clean_pyc command since it does not work correctly in many cases
  • Removed: sync_media_s3 command in favor of sync_s3
  • BugFix: syncdata, use pk instead of id for identifying primary key of objects
  • BugFix: sync_s3, use safer content type per default
  • BugFix: export_emails, filtering on groups
  • BugFix: print_user_for_session, use USERNAME_FIELD if defined
  • BugFix: update_permission, fixed TypeError issue
  • BugFix: JSONField, do not coerse a json string into a python list
  • BugFix: import json issue by using absolute imports
  • BugFix: add minimal version number to six (>=1.2)
  • Docs: graph_models, Added some documentation about using dot templates
  • Docs: reset_db, short description on SQL DDL used
  • Docs: Added specific list of supported Python and Django versions
  • Docs: Add link to GoDjango screencast
  • Docs: Add ShortUUIDField to docs
  • Python3: fixes to graph_models and export_emails for Python3 compatibility

Posted on May 1, 2014 With tags: 1.3.4, django, extensions

Add to:  

0 Comments

We are proud to release: Django-Extensions Version 1.3.3

This brings the usual tons of fixes and improvements

Get it now: https://pypi.python.org/pypi/django-extensions/1.3.3

Changelog:

  • Docs: Made it clearer that Django Extensions requires Django 1.4 or higher
  • Translations: FR Updated
  • Python3: Fix for shell_plus

Posted on January 21, 2014 With tags: 1.3.3, django, extensions

Add to:  

0 Comments

We are proud to release: Django-Extensions Version 1.3.0

This brings official Django 1.6 support and the usual tons of fixes and improvements

Get it now: https://pypi.python.org/pypi/django-extensions/1.3.0

Changelog:

  • Feature: SQLDiff much better notnull detection
  • Feature: reset_db add option to explicit set the PostGreSQL owner of the newly created DB
  • Feature: shell_plus added support for MongoEngine
  • Feature: sync_s3 enable syncing to other cloud providers compatible with s3
  • Improvement: ForeignKeyAutocompleteAdmin add option to limit queryset
  • Bugfix: graph_models fix issue with models without primary key
  • Bugfix: graph_models fix UnicodeDecodeError using --verbose-names
  • Bugfix: dumpscript fix problems with date/datetimes by saving them now as ISO8601
  • Docs: many improvements
  • Docs: Chinese translation !!!
  • Python3: various improvements
  • Tests: add Django 1.6

Posted on January 7, 2014 With tags: 1.3.0, django, extensions

Add to:  

0 Comments

Django Extensions SQLDiff command is looking for somebody with MySQL skills to help out.

In the GIT version of Django-Extensions we improved support for detecting NOT NULL changes in database. However this is currently only implemented for SQLite and PostgreSQL. We would like for the MySQL support to not lag behind the other backends.

So are you using MySQL and have 30 mins to an hour to spare ? Then consider helping out and add notnull_differ support for MySQL to SQLDiff :)

Link to get started: https://github.com/django-extensions/django-extensions/blob/master/django_extensions/management/commands/sqldiff.py#L506

Posted on October 28, 2013 With tags: django, extensions, notnull_differ

Add to:  

0 Comments

Django-Extensions version 1.2.5 is as a bug fix release for 1.2.4.

Fixes two bugs in admin extensions:

  • Fix autocomplete image pixel
  • Fix ForeignKeySearchInput Javascript

Posted on October 22, 2013 With tags: 1.2.5, django, extensions

Add to:  

0 Comments

Django-Extensions version 1.2.4 got released as a bug fix release for 1.2.3.

Turns out I made a small packaging mistake and the new templates for graph_models where not included in the release.

Posted on October 19, 2013 With tags: 1.2.4, django, extensions

Add to:  

0 Comments

Django-Extensions version 1.2.3 is out :)

Bringing the usual bug fixes, improvements, etc.

Special this time is that a bunch of extensions that had not seen changes in a long time got some new love. A special thanks for the contributions to SQLDiff and graph_models this time around.

A new version of SYNC_MEDIA_S3 was also merged, now simply called sync_s3. The old version sync_media_s3 still exists but will be deleted around march 2014. Please give the new version a try if your using this ! :)

ChangeLog:
  • sqldiff support for doing diffs involving many-to-many relations
  • sqldiff support finding missing foreignkey relations
  • sqldiff now supports Table Inheritance
  • graph_models now supports both pygraphviz and pydot
  • graph_models refactored use of django templates so it's easier to change and extend
  • graph_models sort items and make sure primary_key and foreignkeys are always on top
  • graph_models (hopefully) make database relations (primary key and foreignkey) more clear
  • graph_models do not hide foreign keys from attribute list (added option for if you want to hide this)
  • graph_models allow to specify default values in settings file for graph_models command
  • graph_models show inheritance arrows per default
  • shell_plus Added SHELL_PLUS_PRE_IMPORTS and SHELL_PLUS_POST_IMPORTS which allow for including additional import directives before the shell starts.
  • pipchecker now uses more colors if shell supports it
  • runserver_plus add color support to werkzeug server logs
  • jobs add minutely for completeness sake
  • NEW: added indentby templatetag. Useful for text template where indentation matters.
  • BACKWARDS COMPATIBILITY: removed old hacks to be compatible with Django <r9110
  • BACKWARDS COMPATIBILITY: reset_db remove support for Django <1.2
  • FIX: upgraded javascript libraries, mainly jquery and dependencies
  • FIX: runprofileserver support Python 3.3 and Django 1.6
  • FIX: jobs raise JobError when job does not exist
  • FIX: reset_db set default router
  • FIX: autocomplete field Fix unicode error in admin autocomplete field
  • FIX: runscript now uses INSTALLED_APPS instead of get_apps() to discover scripts so it does not depend on apps having a models.py file.
  • FIX: print_user_for_session to support Django 1.5.4 and up
  • FIX: pipchecker handle tar and zip files a bit more gracefully

Posted on October 17, 2013 With tags: 1.2.3, django, extensions

Add to:  

0 Comments

Django-Extensions version 1.2.0 is out now ! :)

ChangeLog:

  • More Python 3 support
  • BACKWARDS COMPATIBILITY: Fixes to the UUID field might break backwards compatibility
  • FEATURE: hook in dumpscript to control execution during run_import
  • FEATURE: add --prof-file option to runprofileserver
  • FEATURE: provide configurable way to obtain Keyczar class
  • FEATURE: IPv6 and FQDN address support in runserver_plus
  • FEATURE: runserver_plus setting for default address/port in settings.py
  • FEATURE: added trvis status image
  • FIX: JSONField did not allow empty list as default value
  • FIX: support Django 1.5 swappable User model
  • FIX: runserver_plus to serve static files correctly
  • FIX: make spatialite work with reset_db
  • FIX: sqldiff missing varchar size under PostGreSQL
  • FIX: removed fallback uuid module
  • FIX: sqlcreate use client hostname not database server hostname for grant
  • FIX: graphmodels version comparison for 0.36 work around

Posted on August 25, 2013 With tags: 1.2.0, django, extensions

Add to:  

0 Comments

Another bugfix release of Django-Extensions hits the deck.

ChangeLog:

  • FIX: pipchecker, fix typos
  • FIX: pipchecker, improve message when installed version is newer then on pypi
  • FIX: pipchecker, use urllib2 instead of requests
  • FIX: sqldiff, fix for bigserial support

Posted on March 8, 2013 With tags: 1.1.1, django, extensions

Add to:  

0 Comments

We just released version 1.1.0 of Django-Extensions.

This version brings initial support for both Django 1.5 and Python 3.3 !

Thanks to fhahn and Mikolaj Romel for their help on this.

ChangeLog:

  • Python 3.3 support
  • Django 1.5 support
  • PACKAGING: Added license file to source distribution
  • FEATURE: Add pipchecker command for reporting out-of-date requirements
  • FEATURE: Allow to set uuidfield max_length
  • FEATURE: dumpscript got hooks to override save and locate calls
  • FEATURE: notes command now also support WARNING and NOTE annotations
  • FEATURE: shell_plus command now support settings SHELL_PLUS variable in settings file which indicated with interactive python shell to use.
  • DOCS: Fixed documentation which was messing up the table of content.
  • FIX: Added empty migration to make south happy :)
  • FIX: UUID never appears on admin form
  • FIX: reset_db would set OWNER = None when executed without db user
  • FIX: shell_plus disabled using pythonrc per default.

Posted on March 2, 2013 With tags: 1.1.0, django, extensions

Add to:  

0 Comments

A new version of Django-Extensions just hit PyPi :)

We call it: 1.0.3

ChangeLog:

  • FEATURE: notes command now shows BUG tags
  • FEATURE: support SSL in runserver_plus
  • DOCS: Better documentation for runserver plus
  • DOCS: Better documentation for runscript command
  • FIX: truncation on admin widgets
  • FIX: allow AutoSlugField to work with inherited models.
  • FIX: show_templatetags command
  • FIX: RSA public key check for keyzcar encrypted fields
  • FIX: graph_models command for Django 1.5

Posted on January 27, 2013 With tags: 1.0.3, django, extensions

Add to:  

0 Comments

Minor version update Django-Extensions 1.0.2 is out.

This release fixes the following problems:

  • tests: fix keyzcar test failure:

    ImproperlyConfigured: You must set the ENCRYPTED_FIELD_KEYS_DIR setting to your Keyczar keys directory.
    
  • fields: fix docstring for UUID

  • docs: Make README links clickable and organized.

  • show_urls: Revive --unsorted option

  • Added LoggingBaseCommand that logs run time errors to Python logger django.commands

Posted on December 16, 2012 With tags: 1.0.2, django, extensions

Add to:  

0 Comments

Minor version update Django-Extensions 1.0.1 is out.

This release fixes the following problems:

  • spelling typo in README
  • tests: shebang line in run_tests.py
  • logging: Fix compatibility with python 2.6
  • media: Fix media directory in packaging
  • admin extensions: Do not $ in javascript to avoid conflicts and redefines.

Posted on November 8, 2012 With tags: 1.0.1, django, extensions

Add to:  

0 Comments

So it finally happened, Django-Extensions 1.0 is out.

After getting a lot of feedback from the community, I decided to call it 1.0.

Discussions about going fully on-par with Django on version numbering was very interesting and the nice thing about a 1.0 release is that we can always do that later. For now having 1.0 is good enough and besides if we would have called it 1.4 now we never would have been able to celebrate the 1.0 release ;)

Please all start testing this release so we can iron out any small issues left as soon as possible.

Some highlights of the changes in this release are:

  • new validate_templates, Checks templates for errors.
  • sqldiff: PostgreSQL HStore support
  • runserver_plus: Django 1.4 WSGI_APPLICATION support
  • runserver_plus: add --print-sql option
  • dumpscript; several improvements
  • shell_plus: added support for ipython notebook
  • shell_plus: added --print-sql option
  • mail_debug: several improvments
  • Using Travis-CI now in combination with GitHub
  • Several fixed for Django 1.4

Posted on October 22, 2012 With tags: 1.0, django, extensions

Add to:  

0 Comments

After my previous post http://trbs.net/blog/2012/09/19/django-extensions-version-010-or-10/ and the many positive reactions I would like to suggest a third option.

I didn't include this before because I wasn't yet sure if it would be a good option. But after some more thinking and reading Christophe31's suggestion which is very similar I think we should look seriously at the option :-)

The idea is that we make Django Extensions follow the Django version numbers closely. This would mean bumping the version number to 1.4.

With this scheme we would commit to the following in Django Extensions:

* Django-Extensions 1.4 is compatible with Django 1.4 and it's deprecation timeline.
* Django-Extensions will deprecate and update code on par with Django.
 (This would help us fix aka remove the tons of legacy/backwards compatibility hacks in the codebase)
* A new version with bumped version number is released as soon as possible after a Django release.

For a user it should be intuitive and clear that you should match the major version numbers of Django-Extensions to whatever version of Django you are using. This also solves questions like what version will support Python-3 or PyPy or deprecates using feature X.

Some details would still need to be worked out... like either use our own patch versions or add a different indicator for differentiating between updates to Django Extensions. For example both of these version numbers could indicate the first update to a Django 1.4 compatible extensions release:

* Django-Extensions 1.4.1
* Django-Extensions 1.4p1

As always leave your votes, thoughts, comments, rants (really, please don't :-) ) or pony's at:

https://github.com/django-extensions/django-extensions/issues/241

Posted on September 20, 2012 With tags: django, extensions, versioning

Add to:  

0 Comments

We are getting close to releasing a new version of Django Extensions to PyPi which means it's about time to bump the version number once again.

Right now our version number is at 0.9 so the question becomes what do we use next ? We can go and continue to increment with +0.1 which will make this the 1.0 release.

The thing for me with Django Extensions is that it's more a continuous process then something with 'stable' releases.

What I mean is that as a collection of extensions there is really no such thing as a 'stable api/abi' as there is in a framework codebase like Django itself.

So I don't mind either way. We can call it 1.0 and just increment that as long as we don't make any radical or major changes to the code base. Or just continue with the 0.x numbering for the time being.

Please put your vote and/or thoughts about this in a comment at:

https://github.com/django-extensions/django-extensions/issues/241

Posted on September 19, 2012 With tags: django, extensions

Add to:  

0 Comments

I've uploaded a new version of django-history-tables [1] to the mercurial repository. It now should run on Django 1.0 + 1.1 and finally supports (although basically) the Admin interface.

For those that don't know django-history-tables (guessing that's 99.9% of everybody reading this), it is a pluggable Django application to create addition tables inside the database recording the history of changes and deletion of Django models.

This in itself is not unique there are many more project out there doing basically the same but most implement this by serializing data (such as pickling, json, xml, etc). Big drawback of this approach is that when schema changes your serialized history does not change with it. Somewhere down the line when you have forgotten all the schema changes it will be most difficult to use this history data.

django-history-tables works by using one additional 'normal' database table to store history information; major benefit of this approach is that there's no pickling, no serializing, and it should be able to support anything that your database supports as well.

Schema changes in this approach needs to be applied to both tables. When you change your model, you will need to change the schema of the history table as well. <shameless-plug>By using my sqldiff extensions in django-extensions this process can be made pretty easy.</shameless-plug>

In the future I hope to support the major schema migration tools for Django so that we can make schema changes in the history models even less painful.

It has been a while since I've worked on django-history-tables and truth be told I kinda forgot about it :-) It's been lingering in a corner for a while now and I've been busy doing other things like maintaining django-extensions and writing news sites in Django.

But then something really cool happened, something which is really telling for Open Source projects and the Open Source community as a hole. Somebody contacted me, out of the blue, an email from a stranger with the message that they had updated my old proof-of-concept code to run on new versions of Django with the patch attached.

We started talking and found that other people had written patches for it as well and put them up on the issue tracker at Google code. A project which was, for all intents and purposes dead to me, suddenly sparked back to live.

This inspired me to get to work again and to try to get the project back into some kind of shape.

Now it's not perfect yet, it will have bugs and needs more work. I can also do with some help improving it, making it better and reviewing that the implementation works as expected.

So please try it, play with it, have fun with it. And if you like it leave a message :)

[1]Django History Tables: http://code.google.com/p/django-history-tables/

Posted on January 23, 2010 With tags: django, history, models, tables, unpickled

Add to:  

4 Comments

The Django Social Bookmarks app does what you might expect this application to do.

It provides an easy and reusable way to get those pesky add to this social network site on a Django site.

It currently supports 34 different sites, ranging from the big ones like; twitter, facebook, slashdot, delicious, digg, technorati, strumble to local networks like nujij (Dutch), ekudos and tagmos or netjes (Belgium).

All texts in the app use Django i18n so people should have no trouble contributing both links and translations to make it truly comprehensive.

After adding social_bookmarks to INSTALLED_APPS and making sure the images are reachable you can use the provided inclusion-tag to add the links in a template.

Template example:

{% load social_bookmarks_tags %}
<div class="content">
    {{ content }}
    {% show_social_bookmarks object.title object.get_absolute_url %}
</div>

The default inclusion-tag template specifies some simple css classes so you can theme the links without having to write you own template.

CSS:

/* div around the entire block of links ^/
.socialbookmarks {
    display: block;
}
.socialbookmarks strong {
    font-weight: bold;
    color: black;
}
/* individual links */
.socialbookmarks .social {
    color: #ccc;
}
/* no borders on images */
.socialbookmarks .social a img {
    border: 0px;
}
Code is maintained in a mercurial repository and can be found here:
http://bitbucket.org/trbs/django-social-bookmarks/
Some points on the todo list for the future are:
  • Some more tags and/or api functions, for people that don't want to use the inclusion tag.
  • Putting the links in database so that they can be added, changed, enabled and disabled in the admin.
  • Add caching to the template tags

Hopefully it is useful for other people and project as well. If you want to use this in your own project, contribute with links, translations or idea please drop me a line at bitbucket or #django irc.

Posted on July 11, 2009 With tags: app, bookmarks, code, django, hg, network, reusable, social

Add to:  

4 Comments

Since I'm redoing my media center setup at home, i came across the lirc config file for my Philips remote control. Which has been happily running as a lirc master server on my OpenBSD firewall for 3 years now.

After remembering how much trouble/work it was pressing every keys for several seconds and checking them and how I never want to that again for this remote I am posting the file here now.

So for future reference; this is the lirc configuration file for a Philips SBCRP520 remote control:

http://trbs.net/media/lirc/lircd-Philips-SBCRP520.conf

Having IR'ing :)

Posted on June 27, 2009 With tags: control, ir, lirc, Philips, remote, SBCRP520

Add to:  

0 Comments

Finally got around to creating a repository for the source code of ExtPaste a ExtJS [1] / Django [2] powered pastebin [3].

People where asking me about the source code for http://extpaste.com on the ExtJS forums for some time now. So here it is: http://hg.trbs.net/extpaste/

The project was development and currently runs on a Django version before 1.0 :( But i'm working at this moment to get the repository up to date with Django 1.0. I've already ported it to NewForms-Admin so the biggest thing left is to port to newforms.

If everything goes fine the code in the repository should be on Django 1.0 before the end of the day.

Updated 15-Nov-2008: Extpaste now runs on Django 1.0 and higher

[1]ExtJS JavaScript Framework: http://www.extjs.com
[2]Django Web Framework: http://www.djangoproject.com
[3]Modeled closely to the excellent dpaste Django pastebin: http://dpaste.com

Posted on November 14, 2008 With tags: code, django, extjs, source

Add to:  

2 Comments

Today i've added a new option to Django-Extension's runprofileserver to make like a bit easier for people who want to use KCacheGrind to profile Django.

This was sparked by profiling one of the scientific Python scripts i wrote for my research project. I wanted to see where (or at least if) i could squeeze a bit more performance out of it without resorting to ctypes/c-modules or weave. For more information about the latter see: http://www.scipy.org/PerformancePython

So i disabled Psyco [1] which confuses the profiler and started my program with the cProfiler enabled and started analyzing it's output.

you can do this easily by executing:

  $ python -m cProfiler ./my_application.py

From earlier encounters with profiling i found that KCacheGrind is a really awesome application for viewing and analyzing profile data. However Python's profiler module cannot directly save it's data in a format which is compatible with KCacheGrind. There are a few ways around this and one of them is a script called: lsprofcalltree.py [2].

It converts the profile information from cProfiler to something which is readable by KCacheGrind. Best of all you can use it as an in-place replacement for the Python interpreter so it's just as easy to use as the "$ python -m cProfiler" line.

Coming back to the runprofileserver I implemented lsprofcalltree directly into the extension command so you do not have to convert the output data by hand later. All you need to do now is enable the --kcachegrind option and all the profiler data is automatically saved in the KCacheGrind compatible format.

Example:

$ mkdir /tmp/my-profile-data
$ ./manage.py runprofileserver --kcachegrind --prof-path=/tmp/my-profile-data
Validating models...
0 errors found

Django version 1.0-post-release-SVN-SVN-unknown, using settings 'complete_project.settings'
Development server is running at http://127.0.0.1:8000/
Quit the server with CONTROL-C.
[13/Nov/2008 06:29:38] "GET / HTTP/1.1" 200 41107
[13/Nov/2008 06:29:39] "GET /site_media/base.css?743 HTTP/1.1" 200 17227
[13/Nov/2008 06:29:39] "GET /site_media/logo.png HTTP/1.1" 200 3474
[13/Nov/2008 06:29:39] "GET /site_media/jquery.js HTTP/1.1" 200 31033
[13/Nov/2008 06:29:39] "GET /site_media/heading.png HTTP/1.1" 200 247
[13/Nov/2008 06:29:39] "GET /site_media/base.js HTTP/1.1" 200 751
<ctrl-c>
$ kcachegrind /tmp/my-profile-data/root.12574391.592.prof

Here is a screenshot of how the above commands might look in KCacheGrind:

Screenshot

More information can be found at http://code.google.com/p/django-command-extensions/wiki/RunProfileServer

Have fun profiling :)

P.S. Having fancy tools is never a replacement for learning and knowing about what code actually does and what profile data represents !

[1]The Python Dynamic/JIT compiler - http://psyco.sf.net/
[2]http://codespeak.net/pypy/dist/pypy/tool/lsprofcalltree.py

Posted on November 13, 2008 With tags: django, kcachegrind, lsprof, runprofileserver

Add to:  

3 Comments

After working for several months here in Japan i finally get the change to go on a vacation. I've planned a short-stay in Nikko where i will stay in a Zen-buddhist's lodge/monastery and see all the different temples and nature around there. Specially in Autumn time it is rumored to be very very beautifully.

When i return from Nikko the plan is to go on to Kyoto / Mt. Fuji area and maybe something south of Tokyo like Kamukara.

In a couple of weeks i hope to be able to put up lots of pictures for you all to say :)

Enjoy your Autumn!!

trbs

Posted on October 15, 2008 With tags: japan, kyoto, nikko, vacation

Add to:  

0 Comments

A while ago i was playing with the excellent pinax (django-hotclub) project and i felt like the admin index page was kind-of overwhelming due to all the different apps listed in it.

So i put a simple app together that has one template tag and a slight modification of the "admin/index.html" template to create simple tabs in the django admin interface.

To minimize my effort ;-) i used jquery and ui.tabs.js to create the tabs at runtime. With one mandatory tab called "main" (changeable in settings.py), which contains all apps not mapped to a specific tab, and an attribute in settings called "ADMIN_TABS" that maps different apps to different tabs.

It's still more-or-less a proof-of-concept applicatio, but it shows how easy these kinds of modifications can be in the django admin interface.

Screenshots

Mercurial repository

Afterthoughts:

I would like to extend this to something like shown in the Gondola screencast by Peter Baumgartner at a later time where a specific tab can also short-cut to common usage patterns.

Posted on September 19, 2008 With tags: admin, django, tabbed, tabs

Add to:  

2 Comments

Japanese Django book

When looking for English books in a bookstore i came across the programming section of the 8 story book store and i could not resist to take a look and see if i could find any Python or Django books there.

Look at my picture from what i've found here: http://trbs.net/photos/python-django-books-in-japanese/

Regretfully these where only about two bookshelves worth of Python books. Compare that too one full cabinet of Ruby and Rails books, one cabinet for Perl, a hole alley of Java books, an alley for c and c++ and lastly an alley for php/asp/vb/c# and other some other languages. *I'd even found some scheme, lisp and cobolt books in there :) *

Worthy to note was that the Microsoft languages section was far less in total then i'd expected. While on the other hand a relatively minor language like Ruby had far more. Ofcourse japan is the homeland of Ruby so that might explain it's high number of books ;) (On a site note; probably the only people that could have invented such a syntax horrible language are the Japanese. Of-course I'm purposely forgetting about Perl here)

Anyways i did not want to withhold u guys of these pictures, specially the one from the Django book that has a lovely cover, good layout and lots of examples, i even found a lot of debugging instructions and examples in there.

P.S. The pictures where taking with the build-in camera of the N810 so quality is very poor.

Posted on September 13, 2008 With tags: books, django, japanese, python

Add to:  

0 Comments

Geneva, 10 September 2008. The first beam in the Large Hadron Collider at CERN was successfully steered around the full 27 kilometres of the world’s most powerful particle accelerator at 10h28 this morning. This historic event marks a key moment in the transition from over two decades of preparation to a new era of scientific discovery.

A great moment for science and the world !

Posted on September 11, 2008 With tags: accelerator, cern, particle

Add to:  

1 Comments

Nothing beats your first official Japanese lesson they must have thought ;-)

Well it was very amusing to say the least. I just started practicing Hiragana less then a week ago and my self-study-lessons date back from before 2004. The fun things is that i clearly remember some things from the self-study i did way back, specially in the form of a passive (very incomplete) mind-dictionary. I remember a lot of the simple words and it all came back to me fairly quickly during this first lesson.

However that's not to say that this is going to be easy :( Now i have a big text and workbook on my desk which i have to study in besides working in the lab if i want to have any change of learning some basic Japanese.

So which me luck guys and girls :)

One thing is for sure, if the rest of the lessons will be this amusing i will have a great time studying Japanese :)

Posted on September 9, 2008 With tags: beginners, japanese, study

Add to:  

1 Comments

I recently added two new commands to the django-extensions project.

  • clean_pyc, removes all compiled python bytecode files from your project directory
  • compile_pyc, compiles all python files to bytecode files in your project directory

These are handy shortcuts to what you would normally do with something like "$ find -name "*.py[co]" -delete" or python's compileall import. The main added advantage is a little piece of code that checks the correct working directory. So it will only compile or delete files in your project root, even if you call manage.py from somewhere else.

One other thing to note is that you will always see files being deleted when you call "$ ./manage.py clean_pyc -v" this is because when manage.py gets loaded python will compile files in your project root which are then in turn deleted by the command ;-)

Check it out at: http://code.google.com/p/django-command-extensions/

Posted on September 8, 2008 With tags: django, extensions

Add to:  

0 Comments

Originally the plan was to go and climb Mt. Fuji, but after getting on the train i was swept into this outdoors Electro/House party. I just love how Tokyo does this to you. Regretfully no pictures because it was very dark, so my compact didn't work so well.

This turned out very very well, specially because the weather was terrible and climbing without good gear in this weather would have been terrible. Hopefully i will still get the change somewhere in the coming weeks.

In good Japanese fashion the party was spread out over couple of fields, some with live acts (mostly young espirering artists) and other with DJ's. And lots of little stalls with foods and drinks in between.

Needless to say i really enjoyed myself :-)

Already wondering what the next week will bring...

Posted on September 6, 2008 With tags: japan

Add to:  

0 Comments

Congratulations everybody Django 1.0 has landed

Thanks for all the hard work of the Django core team !!!

Posted on September 5, 2008 With tags: django

Add to:  

0 Comments

Always a very important moment in history, when the first post happens :)

Posted on September 5, 2008 With tags: blog, first, post

Add to:  

0 Comments