Blog

I recently upgraded my main Windows Vista desktop to Windows 7 RTM. I chose to upgrade instead of doing a clean install because I had a lot of programs installed that I did not want to reinstall (too time consuming). The whole upgrade process wasn’t too bad, I had to uninstall a few programs and reinstall them after the upgrade. In addition to the uninstall/install, I encountered a few odd problems after the upgrade.

One of these problems was that my DVD drive disappeared. It wasn’t just the DVD drive, Daemon Tools’ virtual drive also wasn’t showing up. Looking at the devices in device manager I saw the following error.

Windows cannot verify the digital signature for the drivers required for this device. A recent hardware or software change might have installed a file that is signed incorrectly or damaged, or that might be malicious software from an unknown source. (Code 52)

After searching online I found out that this had to do with some drivers that iTunes, Zune (!) and a few other programs had installed. Most of these programs are compatible with Windows 7, but the upgrade process didn’t deal with this case very well.

Anyways, if you search online you will find several solutions that require you to play around with the registry or have you install some random driver. Some even suggest disabling driver signing check. I didn’t prefer doing any of these.

After a little more search I ended up on this Microsoft Help and Support article. It described the exact problem that I was having and it had an automated fix. When I downloaded and ran the fix, it complained that it doesn’t work with my version of Windows. Knowing that the fix was compatible with Windows Vista, the workaround was simple:

1. Right click on the MSI that you downloaded.
2. Go to the Compatibility tab.
3. Check “Run this program in compatibility mode for:”
4. Verify that the drop down says “Previous version of Windows”
5. Click OK to complete.

Now you should be able run the fix. Restart after the fix has installed and your drives should be back. Have fun!

Here is a very technical entry. Are you getting syntax error when using prototype with IE to load HTML? In prototype 1.6.0.3 the error happens on line 604.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

var Enumerable = {
  each: function(iterator, context) {
    var index = 0;
    try {
      this._each(function(value) {
        iterator.call(context, value, index++);
      });
    } catch (e) {         /////// <---- IE complains of syntax error on this line
      if (e != $break) throw e;
    }
    return this;
  },

The error is misleading and it took me a little time to figure this one out. Basically, this happens when you load HTML from server using AJAX and have prototype evalScripts, and the content being loaded has javascript encapsulated in an HTML comment.

1
2
3
4
5

<script type="text/javascript">
<!--
alert("The comment tags are the problem.");
// -->
</script>

Removing the HTML comment tags should resolve this syntax error. You can read more in this ticket.

Yesterday I upgraded to Firefox 3.5 and noticed that my saved passwords didn’t show up. Instead it had a new “password store,” i.e. the ones that I was saving now were working fine, but the ones from 3.0 were lost. After some research I ended up on this post. So, Firefox 3.5 uses an sqlite database (signons.sqlite) to save passwords while 3.0 used a plain text file (signons3.txt). The normal upgrade process would have migrated your passwords correctly, but in my case I had Minefield (Firefox’s dev version) installed before the developers got around to creating the migration script. So, I had signons.sqlite by the time I upgraded to the official release, which ended up leaving that as-is. Anyways to fix this…

1. Go to your profile folder %APPDATA%/Mozilla/Firefox/Profiles/xxxxxxxx.default/
2. Make sure there is signons3.txt in this folder. This is your passwords files from Firefox 3.0.
3. Close any open Firefox windows.
4. Backup signons.sqlite somewhere and remove it from this folder.
5. Restart Firefox.

This should recreate signons.sqlite and your passwords should be recovered. Have fun.

Earlier today I went to the Pearl Market in Beijing to check out what kind of stuff they had. Being a geek, electronics really got my attention, especially the prices. I knew most of the stuff was fake and I had heard about USB drive capacity issues, but I wanted to experience it first hand 🙂 So, I went a head and bought a 16GB flash drive. I had them plug it in and Windows reported 16GB. I also had them copy some data, but it was interesting because as more and more files were being copied the seller was getting nervous. I knew something was wrong. I was still curious so I went ahead and purchased it anyways. Once I got back to my room I decided to run a few tests and below are the results for your amusement. Remember that this is supposed to be a 16GB drive 🙂

Warning: Only 16138 of 16140 MByte tested.
The media is likely to be defective.
446.7 MByte OK (914944 sectors)
15.3 GByte DATA LOST (32135680 sectors)
Details:0 KByte overwritten (0 sectors)
0 KByte slightly changed (< 8 bit/sector, 0 sectors)
15.3 GByte corrupted (32135680 sectors)
0 KByte aliased memory (0 sectors)
First error at offset: 0x0000000000000008
Expected: 0x0000000000000011
Found: 0x0000000000000000
H2testw version 1.3
Writing speed: 19.0 MByte/s
Reading speed: 7.39 MByte/s
H2testw v1.4

Also, on the right side is a picture of a fake 8GB iPhone.

My main browser is Firefox, but I like Chrome’s short startup time and general javascript speed. Here is a useful tip if you use Chrome. Chrome doesn’t ask for confirmation if you close a window with multiple tabs. Don’t worry, it is very easy to bring those back. To bring the last session press CTRL+SHIFT+T simultaneously and your last window will popup.

This is also true across sessions, i.e. if you completely close Chrome or after you restart. In these cases open a new Chrome window, then press this combination and you will get another window with your last set of tabs.

I am one of the people that does read the documentation. My business partner, Jake, asked why use varchar with an artificial limit for fields that don’t really have a limit. My initial thought was because of performance benefits, but I had never verified this. So, I spent a few minutes to verify this and guess what I find in the PostgreSQL documentation.

… If you desire to store long strings with no specific upper limit, use text or character varying without a length specifier, rather than making up an arbitrary length limit.)

It continues on and says…

Tip: There are no performance differences between these three types, apart from increased storage size when using the blank-padded type, and a few extra cycles to check the length when storing into a length-constrained column. While character(n) has performance advantages in some other database systems, it has no such advantages in PostgreSQL. In most situations text or character varying should be used instead.

Exactly what I was looking for! This is what I call great documentation.

I have used MySQL in the past, but my experience with PostgreSQL has been awesome. Great database that scales relatively well (we will find that out soon :)), supports most of what you expect from a db, and has good documentation!

I love firefox, but everything has its bad sides, and this is one bad side of Firefox that I don’t like.

I generally do my development on a dedicated development server running Linux with a fairly good amount of RAM (2GB) and a fast processor (the server does a lot more than just server django :)). Even when I am out of office I SSH to the development server. A few weeks ago I was on a trip where I wasn’t going to have good internet access for a lot of time. So, I decided to setup django on my tablet (Windows) to work locally. Everything was great until I had to access the site.

http://localhost:8000

waiting…

waiting…

Finally, after a few seconds the main page showed up. Then I clicked on a link.

waiting…

waiting…

Once again the page showed up after a few seconds. I was surprised how slow this was behaving. I booted to Linux and there it was very snappy. Unsatisfied with this performance issue, I did some searching and debugging and finally found out that the ‘localhost’ is what was causing the problem. As soon as I switched to the local IP address (127.0.0.1), the server came back to life!

If you are developing on Windows and the server seems to be a little slow then make sure to use ’127.0.0.1:8000’ instead of ‘localhost:8000’. If you are curious about the cause then search on google for complete explanation. Apparently this has to do with IPv6 and might a be non-IE issue.

Django’s forms (previously knows as newforms) framework has a lot cool functionality including the ability to output label tags. So, instead of typing the complete label and setting the correct for, you can just do form.field_name.label_tag and everything else is taken care of for you. The only problem is that there is no easy, documented way of adding an indicator (e.g. *) for required fields. One way would be to do if’s on each field and manually add an asterisk in the template, but that’s not DRY. After some search a few weeks ago I found an interesting post by Adil Saleem that showed one way of easily accomplishing this without changing all of your templates.

I really liked Adil’s solution, but I also wanted to change the class on the label so I could make those fields stand out (through CSS), and I also realized that he was really creating a python decorator, but in a weird way. So, here is a revised version of his solution with a slightly different approach (overriding label_tag instead of __init__) that adds the required field indicator and specifies a special CSS class (“required”) through a python decorator.

First we define two functions.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17

from django.utils.html import escape

def add_required_label_tag(original_function):
  """Adds the 'required' CSS class and an asterisks to required field labels."""
  def required_label_tag(self, contents=None, attrs=None):
    contents = contents or escape(self.label)
    if self.field.required:
      if not self.label.endswith(" *"):
        self.label += " *"
        contents += " *"
      attrs = {'class': 'required'}
    return original_function(self, contents, attrs)
  return required_label_tag

def decorate_bound_field():
  from django.forms.forms import BoundField
  BoundField.label_tag = add_required_label_tag(BoundField.label_tag)

The first function is a decorator that provides the functionality and the second function assigns this decorator to BoundField.label_tag. The second function is really a helper function that allows you to easily add this to all your form modules.

Add the above code to one of your library files (maybe project.forms.__init__.py) and then in the module that defines your forms add the following code.

1
2

from project.forms import decorate_bound_field
decorate_bound_field()

Other than this you need to define the “required” CSS class.

1

label.required { font-weight: bold; }

Refresh your page with the form and all of your required fields will have an asterisk and the labels will be bold. Credit goes to Adil Saleem for coming up with the initial version, this is just a refinement 🙂