Wednesday, 16 July 2008
This cartoon wrote a sweary word on your toilet wall
I don't normally blog cartoons but this one made me pause for thought and laugh.
Saturday, 5 July 2008
Django - Named URLS Gotcha
A post in two parts.
First of all - thanks to Magus on #django for pointing out one of my errors to me. I've been working through Practical Django Projects over the last couple of days and it talks about having named urls. Take a look at these three one liners:
We give our view a name (coltrane_link_archive_index), then we call that view with urls.py so it's context will be /weblog/links - and then in our template we can just use the url tag to call that named url. If the url gets moved, your templates will still work - and of course it saves a lot of tedious typing. Great.
So working through the book, the blog application requires a lot of templates and views and stuff. So I thought I'd just do the main one and get the minor ones working later. But I did check to make sure that links to those views were working and they were not.
Written like this, the problem is obvious, a named view won't work if the view it's pointing to doesn't work. So if your url tag's don't function - make sure what they should be taking you to are ok.
But there's more. Because when I wrote the underlying views it still wasn't working. And I discovered something interesting. I had a problem last night after restarting the web server - The first time I'd go to a page I'd get
For some reason I couldn't work out why that was happening last night. I have no idea why I could not - it's blatantly obvious. I wasn't doing an import of the Link model for my tags url file. But I was ignoring it yesterday because I found that if you just asked for the page again it then displays (not the tags page, I hadn't written that, but the rest of the site seemed to be working. I put it down to some strange 'glitch'. It wasn't.
I'm guessing here somewhat but I think what happens is the first time you load your site up, Django precompiles the regular expressions used for your urls. During that compile if it hits an error you'll have some urls working (up to where it failed) and some not. The second time you hit the site that doesn't happen (it thinks the regular expression compilation has completed) and doesn't raise the error again. But of course all the urls that failed won't be working (hence why url tag wasn't working).
On a final note, you'd think by now that I would have learnt that when you have a 'strange glitch' there's something bigger lurking there that you really need to understand.
First of all - thanks to Magus on #django for pointing out one of my errors to me. I've been working through Practical Django Projects over the last couple of days and it talks about having named urls. Take a look at these three one liners:
# from urls.links.py
(r'^$', 'archive_index',link_info_dict, 'coltrane_link_archive_index'),
# from urls.py
(r'^weblog/links/', include('coltrane.urls.links')),
# In my template I get the url using
{% url coltrane_link_archive_index %}
We give our view a name (coltrane_link_archive_index), then we call that view with urls.py so it's context will be /weblog/links - and then in our template we can just use the url tag to call that named url. If the url gets moved, your templates will still work - and of course it saves a lot of tedious typing. Great.
So working through the book, the blog application requires a lot of templates and views and stuff. So I thought I'd just do the main one and get the minor ones working later. But I did check to make sure that links to those views were working and they were not.
Written like this, the problem is obvious, a named view won't work if the view it's pointing to doesn't work. So if your url tag's don't function - make sure what they should be taking you to are ok.
But there's more. Because when I wrote the underlying views it still wasn't working. And I discovered something interesting. I had a problem last night after restarting the web server - The first time I'd go to a page I'd get
ImproperlyConfigured: Error while importing URLconf 'coltrane.urls.tags': name 'Link' is not defined
For some reason I couldn't work out why that was happening last night. I have no idea why I could not - it's blatantly obvious. I wasn't doing an import of the Link model for my tags url file. But I was ignoring it yesterday because I found that if you just asked for the page again it then displays (not the tags page, I hadn't written that, but the rest of the site seemed to be working. I put it down to some strange 'glitch'. It wasn't.
I'm guessing here somewhat but I think what happens is the first time you load your site up, Django precompiles the regular expressions used for your urls. During that compile if it hits an error you'll have some urls working (up to where it failed) and some not. The second time you hit the site that doesn't happen (it thinks the regular expression compilation has completed) and doesn't raise the error again. But of course all the urls that failed won't be working (hence why url tag wasn't working).
On a final note, you'd think by now that I would have learnt that when you have a 'strange glitch' there's something bigger lurking there that you really need to understand.
Labels:
development,
django
Thursday, 3 July 2008
NewForms Admin - Flatpages
Practical Django Projects (Chapter three), talks about defining an admin interface which is all well and good unless you're using the NewForms Admin branch (which is intended to become part of Release 1.0). So if you're an early adopter or reading this after the big change, you'll be needing to do the following.
The reason I bothered writing this was I couldn't work out how to override the fact that FlatPage had already registered a ModelAdmin (try to register yours throws an error). A pointer from #django on irc and a look at the source code revealed that unregister was the baby you wanted.
The reason I bothered writing this was I couldn't work out how to override the fact that FlatPage had already registered a ModelAdmin (try to register yours throws an error). A pointer from #django on irc and a look at the source code revealed that unregister was the baby you wanted.
from django.contrib import admin
from search.models import SearchKeyword
from django.contrib.flatpages.models import FlatPage
class SearchKeywordInline(admin.TabularInline):
model = SearchKeyword
class FlatPageAdmin(admin.ModelAdmin):
inlines = [
SearchKeywordInline,
]
# We have to unregister it, and then reregister
admin.site.unregister(FlatPage)
admin.site.register(FlatPage, FlatPageAdmin)
Labels:
django
Wednesday, 18 June 2008
Postgres - Converting Encodings
I've run into a number of problems recently with dealing with old databases of ours which are encoded with LATIN1. Now, with postgres 8.3 (maybe before) you'll get a message if you try to create LATIN1 saying something like
I got bored trying to work out why - it seems to be that postgres now prevents what it shouldn't have allowed in the past but did. But if you do want to convert from the old to the new locale - how do you do it? Remarkably simple it turns out.
Do a pg_dump of your existing database. Then take the dump file and run it through iconv - something like this.
It's pretty obvious what the options mean (-f = from, -t = to). iconv comes as standard on Mac and should be available for most linux distos (seems to be installed on ubuntu server by default).
However, before you get too excited - you should ensure that whatever apps are using that database will cope with the new encoding for input and output. That may be 'non-trivial' ;)
createdb: database creation failed: ERROR: encoding LATIN1 does not match server's locale en_US.UTF-8
DETAIL: The server's LC_CTYPE setting requires encoding UTF8.
I got bored trying to work out why - it seems to be that postgres now prevents what it shouldn't have allowed in the past but did. But if you do want to convert from the old to the new locale - how do you do it? Remarkably simple it turns out.
Do a pg_dump of your existing database. Then take the dump file and run it through iconv - something like this.
iconv -f latin1 -t utf8 original.sql > converted.sql
It's pretty obvious what the options mean (-f = from, -t = to). iconv comes as standard on Mac and should be available for most linux distos (seems to be installed on ubuntu server by default).
However, before you get too excited - you should ensure that whatever apps are using that database will cope with the new encoding for input and output. That may be 'non-trivial' ;)
Labels:
postgres
Sunday, 15 June 2008
Fuel strike: 100 petrol stations reported to have run dry
The Guardian reports "Fuel strike: 100 petrol stations reported to have run dry". I'm not sure if that is supposed to make us worried. Doesn't sound very high to me.
According to Wikipedia we have 9,271 petrol stations in the UK. So that's ... er ... just over 1%.
Come on - we need HEADLINES!
According to Wikipedia we have 9,271 petrol stations in the UK. So that's ... er ... just over 1%.
Come on - we need HEADLINES!
Rhino on OS X Leopard
When I was using Ubuntu as my main development environment I used rhino to try and learn Javascript in a bit more detail.
Coming back to OS X means that I wanted rhino but had no idea how to install. This is how I did it. If you come across this page and it's wrong please let me know. I just wanted to get something running.
1. Get the source file and extract it. I used ftp://ftp.mozilla.org:21/pub/mozilla.org/js/rhino1_7R1.zip. Use unzip rhino_7R1.zip if it doesn't extract.
2. In the top level you'll see a js.jar file - copy that to /usr/share/java (sudo cp js.jar /usr/share/java)
3. Create the following script in /usr/local/bin/rhino (this is copied from the rhino install on Ubuntu Hardy)
4. Make it executable (chmod +x /usr/local/bin/rhino)
Now if you type rhino you can do the following
Truely you are a javascript god.
Coming back to OS X means that I wanted rhino but had no idea how to install. This is how I did it. If you come across this page and it's wrong please let me know. I just wanted to get something running.
1. Get the source file and extract it. I used ftp://ftp.mozilla.org:21/pub/mozilla.org/js/rhino1_7R1.zip. Use unzip rhino_7R1.zip if it doesn't extract.
2. In the top level you'll see a js.jar file - copy that to /usr/share/java (sudo cp js.jar /usr/share/java)
3. Create the following script in /usr/local/bin/rhino (this is copied from the rhino install on Ubuntu Hardy)
#!/bin/sh
/usr/bin/java -jar /usr/share/java/js.jar $@
4. Make it executable (chmod +x /usr/local/bin/rhino)
Now if you type rhino you can do the following
mbp:java icottee$ rhino
Rhino 1.7 release 1 2008 03 06
js> x = 23 * 44
1012
js> y = 'fish'
fish
js> x
1012
js> y
fish
js>
Truely you are a javascript god.
Labels:
javascript,
osx
Thursday, 5 June 2008
8 Things We Hate About IT
I just read this and noticed one of the comments at the end of it.
I head back to the UK tomorrow morning and of the books I brought here to read I've managed to complete about 0.25% (if I'm feeling generous).
Did you write the first draft of this article in crayon? The only point made here that even approaches a fundamental understanding with the current reality of actual IT experience is the fact that 75% of the guys are approaching 40 years of age and haven't the slightest bit of motivation to learn new things.I find the idea that as you approach 40 you lose motivation to learn new things to be boggling. My big problem at the moment is my motivation to learn new things is stronger than ever but the time I have to sit and focus on such things is pretty minimal.
I head back to the UK tomorrow morning and of the books I brought here to read I've managed to complete about 0.25% (if I'm feeling generous).
Labels:
witterings
Subscribe to:
Posts (Atom)