Using Django to Design Your Database Schema

Last night I had a buddy of mine ask me how I would approach a particular database design problem. I get similar questions quite often from my peers--suggests there is something important lacking from the database classes out there. Instead of answering him directly, I decided to come up with this tutorial for using Django to design your database schema.

For those of you new to Django, this article might seem a bit advanced. In time I will have more introductory-level Django tutorials, but I hope this one is easy enough.

Create a Django Project

The first step is to create a Django project. If you already have a project that you can play with, you can skip this step. To create a project, go to a place where you want to keep your code (like C:\projects or /home/me/projects) in a command prompt/terminal and run the following command:

django-admin.py startproject myproject

This will create a new directory in your current location called myproject (you can replace myproject with whatever you'd like so long as you're consistent). This new directory will contain a few files:

  • __init__.py
  • manage.py
  • settings.py
  • urls.py

If you get an error message when running the above command, you might not have Django installed properly. See Step-by-Step: Installing Django for details on installing Django.

Create An Application

Once you have a Django project setup, you should create a new application.

Note: If you're using Windows, you will probably need to omit the ./ on the ./manage.py commands. I will include them here for everyone else who's using Linux or a Mac.

cd myproject
./manage.py startapp specialapp

This will create a new directory in your myproject directory. This new directory will contain three files: __init__.py, models.py, and views.py. We are only concerned with the models.py file in this article.

Create Your Models

Models are usually a direct representation of what your database will be. Django makes creating these models extremely easy, and Python's syntax makes them quite readable. The Django framework asks for models to be defined in the models.py file that was created in the last step. Here's an example (for my buddy who prompted the creation of this article):

from django.db import models

class Component(models.Model):
    item_number = models.CharField(max_length=20)
    name = models.CharField(max_length=50)
    size = models.CharField(max_length=10)
    quantity = models.IntegerField(default=1)
    price = models.DecimalField(max_digits=8, decimal_places=2)

class Project(models.Model):
    name = models.CharField(max_length=50)
    components = models.ManyToManyField(Component)
    instructions = models.TextField()

(for more information about models, see the Django Model API Reference)

I don't know about you, but that code seems pretty straightforward to me. I'll spare you all the details about what's going on (that can be a future article).

Install Your New Application

Once you have your models setup, we need to add our specialapp to our list of INSTALLED_APPS in order for Django to register these models. To do that, open up settings.py in your myproject directory, go to the bottom of the file, until you see something like

1
2
3
4
5
6
INSTALLED_APPS = (
    'django.contrib.auth',
    'django.contrib.contenttypes',
    'django.contrib.sessions',
    'django.contrib.sites',
)

When you find that, add your specialapp to the list

1
2
3
4
5
6
7
INSTALLED_APPS = (
    'django.contrib.auth',
    'django.contrib.contenttypes',
    'django.contrib.sessions',
    'django.contrib.sites',
    'specialapp'
)

Setup Your Database

Now you need to let Django know what kind of database you're using. Django currently supports MySQL, SQLite3, PostgreSQL, and Oracle natively, but you can get third-party tools that allow you to use other database (like SQL Server).

Still in your settings.py, go to the top until you see DATABASE_ENGINE and DATABASE_NAME. Set that to whatever type of database you are using:

DATABASE_ENGINE = 'sqlite3'
DATABASE_NAME = 'myproject.db'

Save your settings.py and go back to your command prompt/terminal.

Get Django's Opinion For Your Schema

Make sure you're in your myproject directory and run the following command:

./manage.py sqlall specialapp

This command will examine the models that we created previously and will generate the appropriate SQL to create the tables for your particular database. For SQLite, we get something like this for output:

BEGIN;
CREATE TABLE "specialapp_component" (
      "id" integer NOT NULL PRIMARY KEY,
      "item_number" varchar(20) NOT NULL,
      "name" varchar(50) NOT NULL,
      "size" varchar(10) NOT NULL,
      "quantity" integer NOT NULL,
      "price" decimal NOT NULL
)
;
CREATE TABLE "specialapp_project" (
      "id" integer NOT NULL PRIMARY KEY,
      "name" varchar(50) NOT NULL,
      "instructions" text NOT NULL
)
;
CREATE TABLE "specialapp_project_components" (
      "id" integer NOT NULL PRIMARY KEY,
      "project_id" integer NOT NULL REFERENCES "specialapp_project" ("id"),
      "component_id" integer NOT NULL REFERENCES "specialapp_component" ("id"),
      UNIQUE ("project_id", "component_id")
)
;
COMMIT;

Notice how Django does all sorts of nifty things, like wrapping the table creation queries in a transaction, setting up indexes, unique keys, and defining relationships between tables. The output also offers a solution to the original problem my buddy had: an intermediate table that just keeps track of relationships between projects and components (the specialapp_project_components table).

Notice that the SQL above may not work with database servers other than SQLite.

Enhancing The Intermediate Table

After my buddy reviewed this article, he asked a very interesting and valid question: What if a project needs 3 of one component? In response, I offer the following models (this requires a modern version of Django--it doesn't work on Django 0.96.1 or earlier):

from django.db import models

class Component(models.Model):
    item_number = models.CharField(max_length=20)
    name = models.CharField(max_length=50)
    size = models.CharField(max_length=10)
    quantity = models.IntegerField(default=1)
    price = models.DecimalField(max_digits=8, decimal_places=2)

class Project(models.Model):
    name = models.CharField(max_length=50)
    components = models.ManyToManyField(Component, through='ProjectComponent')
    instructions = models.TextField()

class ProjectComponent(models.Model):
    project = models.ForeignKey(Project)
    component = models.ForeignKey(Component)
    quantity = models.PositiveIntegerField()

    class Meta:
        unique_together = ['project', 'component']

Running ./manage.py sqlall specialapp now generates the following SQL:

BEGIN;
CREATE TABLE "specialapp_component" (
    "id" integer NOT NULL PRIMARY KEY,
    "item_number" varchar(20) NOT NULL,
    "name" varchar(50) NOT NULL,
    "size" varchar(10) NOT NULL,
    "quantity" integer NOT NULL,
    "price" decimal NOT NULL
)
;
CREATE TABLE "specialapp_project" (
    "id" integer NOT NULL PRIMARY KEY,
    "name" varchar(50) NOT NULL,
    "instructions" text NOT NULL
)
;
CREATE TABLE "specialapp_projectcomponent" (
    "id" integer NOT NULL PRIMARY KEY,
    "project_id" integer NOT NULL REFERENCES "specialapp_project" ("id"),
    "component_id" integer NOT NULL REFERENCES "specialapp_component" ("id"),
    "quantity" integer unsigned NOT NULL,
    UNIQUE ("project_id", "component_id")
)
;
CREATE INDEX "specialapp_projectcomponent_project_id" ON "specialapp_projectcomponent" ("project_id");
CREATE INDEX "specialapp_projectcomponent_component_id" ON "specialapp_projectcomponent" ("component_id");
COMMIT;

As you can see, most of the SQL is the same. The main difference is that the specialapp_project_components table has become specialapp_projectcomponent and it now has a quantity column. This can be used to keep track of the quantity of each component that a project requires. You can add however many fields you want to this new intermediate table's model.

Using This SQL

There are several ways you can use the SQL generated by Django. If you want to make your life really easy, you can have Django create the tables for you directly. Assuming that you have specified all of the appropriate database information in your settings.py file, you can simply run the following command:

./manage.py syncdb

This will execute the queries generated earlier directly on your database, creating the tables (if they don't already exist). Please note that this command currently will not update your schema if the table exists but is missing a column or two. You must either do that manually or drop the table in question and then execute the syncdb command.

Another option, if you want to keep your DDL(Data Definition Language) in a separate script (maybe if you want to keep it in some sort of version control) is something like:

./manage.py sqlall specialapp > specialapp-ddl-080813.sql

This just puts the output of the sqlall command into a file called specialapp-ddl-080813.sql for later use.

Benefits of Using Django To Create Your Schema

  • Simple: I personally find the syntax of Django models to be very simple and direct. There is a comprehensive API that explains and demonstrates what Django models are capable of.
  • Fast: Being that the syntax is so simple, I find that it makes designing and defining your schema much faster than trying to do it with raw SQL or using a database administration GUI.
  • Understandable: Looking at the model code in Django is not nearly as intimidating as similar solutions in other frameworks (think about Java Persistence API models).
  • Intelligent: Using the same model code, Django can generate proper Data Definition Language SQL for several popular database servers. It handles indexes, keys, relationships, transactions, etc. and can tell the difference between server types.

Downfalls of Using Django To Create Your Schema

  • The Table Prefix: Notice how all of the tables in the SQL above were prefixed with specialapp_. That's Django's safe way of making sure models from different applications in the same Django project do not interfere with each other. However, if you don't plan on using Django for your end project, the prefix could be a major annoyance. There are a couple solutions:
    • A simple "search and replace" before executing the SQL in your database
    • Define the db_table option in your models
  • Another Technology: Django (or even Python) may or may not be in your organization's current development stack. If it's not, using the methods described in this article would just become one more thing to support.

Other Thoughts

I first thought about doing the things mentioned in this application when I was working on a personal Java application. I like to use JPA when developing database-backed applications in Java because it abstracts away a lot of the database operations. However, I don't like coming up with the model classes directly, so I usually reverse engineer them from existing database tables.

Before thinking about the things discussed in this article, I created the tables by hand, making several modifications to the schema before I was satisfied with my JPA models. This proved to be quite bothersome and time-consuming.

After using Django to develop my tables, the JPA models turned out to be a lot more reliable, and they were usually designed properly from the get-go. I haven't created tables manually ever since.

If you find yourself designing database schemas often, and you find that you have to make several changes to your tables before you/the project requirements are satisfied, you might consider using Django to do the grunt work. It's worked for me, and I'm sure it will work for you too.

Good luck!

django-clevercss v0.1

Today I launched another little side project. I call it django-clevercss. Really it's just a simple way to use CleverCSS-formatted stylesheets in Django sites.

At first glance, CleverCSS might not seem like the most useful thing ever, but I personally think it has potential. It is a more concise way to write CSS, and it also allows the use of variables (so you don't have to change 50 of the same hex color codes each time someone wants something a different shade of blue) and simple calculations within the stylesheet. You can also have a sort of "hierarchy" of elements so you don't have to repeat the same element name 30 times for simple styling.

Anyway, since I thought CleverCSS was so clever, I decided that I would make an effort to make the project more accessible for Django developers who agree with me.

This project gives you a way to create CleverCSS stylesheets in your database using the Django administration utility. Then you use a simple template tag to bring the CSS file into your Django templates. Put something like {% get_clever_css "Testing" %} in the href of a regular link tag and that's about it!

Assuming that you have a CleverCSS stylesheet in your database with the title "Testing", the project will do several things. First, it will see if the stylesheet has been parsed and saved to the filesystem. If it has, it will compare the last time the stylesheet on the filesystem was modified with the last modification time of the stylesheet in the database. If the stylesheet in the database is newer than the one on the filesystem, or the stylesheet has not yet been saved to the filesystem, the project will parse the CleverCSS into real, valid CSS and store it in a file on the filesystem. Then you end up with something like this in your template after Django is done with it:

<link rel="stylesheet" type="text/css" media="all" href="/media/clevercss/testing.css" />

For more information and installation instructions, check out the project homepage. Have fun!

openSUSE 11.0: Round 2

Ok, ok... I decided to give openSUSE 11.0 another shot. Since my last blog post, I have read some reviews posted by some other people who encountered similar problems when attempting to actually use KDE4. Some of these people opted to install the KDE 3.5.9 remix after that and had more promising result. So, instead of letting my bias get the best of me, I am going to try openSUSE 11.0 one more time using KDE3. The following are the steps I took while going through this process:

  1. Booted from DVD (openSUSE 11.0 x86_64)

  2. Chose "Installation" from the boot menu

  3. After the installer is completely loaded, I selected "English (US)" for both the language and the keyboard layout, read the license agreement, checked the "I Agree to the License Terms" box, and clicked Next.

  4. I waited for a few seconds while the installer probed my hardware and updated some package lists, then I chose "New Installation" and clicked Next.

  5. The next step was to choose my timezone. They have a very simple interface for this--much less frustrating than the counterpart in the most recent release of Ubuntu (8.04 LTS). My system clock is set to Mountain time, so I left that stuff alone and clicked Next.

  6. This step is probably where I screwed up the most last time. It's where you choose which desktop environment you want. You can choose from GNOME 2.22, KDE 4.0, KDE 3.5, and XFCE Deskop. Last time I chose KDE 4.0. This time I chose KDE 3.5 and clicked Next.

  7. After choosing the desktop environment, the installer took me to the disk partition section of the installation. This should be pretty easy for most people, but I changed a few things. Namely, I put the root and home partitions together, and I deleted one of my Windows partitions because Windows is stupid and bloated. Once I verified the disk partition settings, I clicked Next.

  8. This part is where you get to enter the primary system user's information. You can specify the user's name, login, and password. You may also specify a few options including whether or not the root user will have the same password, whether that user will receive system mail, and whether or not that user will be logged in automatically. If you need to, you may change the authentication settings here too. I just entered the information and got on with it. (If you uncheck the box for the root user having the same password, you're prompted for the root password after this screen)

  9. Finally, we get to the step where you get to verify all of the installation settings. I think I'll just go with the configuration for now. When you click Install, you're prompted to verify that you really want to install. Use your head on this one.

  10. After all of that, it began to format my partitions. One neat thing that I noticed while it was installing was the fact that they rolled commonly-installed packages into what they call "images." This seems to increase installation speed considerably. In the past, I've had most RPM-based distribution installations take as long as (or longer than) Windows takes to install. Granted, the difference there is that you actually get useful stuff once Linux is installed, whereas with Windows, you're stuck with something barely usable and you still have to install drivers for every piece of hardware except your monitor.

    Anyway... the openSUSE folks seem to have addressed that problem recently (maybe just in this release). This went a LOT faster than I've ever seen (on any computer). Despite the use of those images, though, there were still nearly 500 packages that needed to be installed. It seems to be quite evident that the packages are working faster than ever before. It's refreshing (though it did still take quite a bit longer to install than most Debian-based distributions I've tried).

  11. After all of the packages are installed, the system does some configuration and then reboots itself. When it comes back up, the installer will appear, do some more hardware detection and configuration, and then go straight into your desktop.

openSUSE actually didn't detect my 1680x1050 resolution (I didn't know any modern distribution wouldn't anymore), so I just went into YaST and set the resolution to what it should be. And then it locked up, and I had to do a hard reboot. Let's hope I can stop that from happening again. I suppose so long as I can still see things other than my mouse, I should be good.

Upon rebooting into my desktop, the resolution was still crappy. When I went to change it this time, though, I noticed that dual-head mode was enabled. That's stupid. I never plug a second monitor into my laptop. I disabled that, then tried to change the resolution. After logging out and back in, it seems to have changed the resolution properly. While I realize that I do have an extremely crappy video card, Ubuntu and others have been able to offer me 3D acceleration. This option is currently unavailable with openSUSE. Perhaps a little research will solve that problem.

After a few minutes of configuration and preference setting, my system locked up yet again. And another hard reset did the trick of getting it operational again. One more and it's outta here!! I do have to say... Minus the quirks with the resolution and drivers, the distribution does not seem bad at all. It might be worth trying out on a different computer--maybe I'd have better luck.

Alright, now I'm going to check the software management tool for a real driver for my video card. Looks like I may have found some. I hope they work. I'm using a "1-click installer" that I found from a Google search. The installation went fine, but after logging out and back in (to have the drivers take effect), it locked up again.

So, round two folks. Again, it might just be user error. It might just be my computer. Or openSUSE really might just suck. I don't think I'll be trying it on my computer again for a while. I might try on a different system altogether, but not on my main laptop.

Sad Day for Religious Nerds

I recently decided it would be prudent for me to request permission from the Church of Jesus Christ of Latter-day Saints to redistribute a copy of the scriptures with the PyScriptures program that I have been working on recently. I didn't want to be held liable for any copyright infringement or other legal violations. So I decided to contact them a couple of weeks ago. Here is my message requesting permission:

To whom it may concern:

I would like to request permission to redistribute and use a database which contains the LDS standard works (scriptures only, not the bible dictionary, topical guide, or even footnotes). One of my personal projects relies upon a local copy of the scriptures in order to be useful at all, and I would like people to be able to use this program without fear of any sort of copyright infringement charges to any party. The goal of the program is to offer users of platforms other than Microsoft Windows a way to peruse and study the scriptures without requiring an Internet connection. I have tested it on Windows XP, Linux, and MacOS X and it works great. There are still some parts that need some work, and things could probably be optimized a bit, but works well enough considering that I've only been working on it for about a week and a half.

To learn more about this project, please go to http://code.google.com/p/pyscriptures/ where you can even browse the Python source code for my application (though you might want to do so on an empty stomach). The database is called 'scriptures.db' (http://code.google.com/p/pyscriptures/source/browse/trunk/pyscriptures/scriptures.db) and was created using SQLite in case you are interested in examining and verifying its contents. One of my main reasons for creating this database is that I noticed the database that The Mormon Documentation Project offers is missing some things, particularly all of the answers in Section 77 of the Doctrine and Covenants. I didn't want to find out what else was missing or modified. Perhaps the reason those answers are missing is because that's part of the conditions of redistributing the scriptures?

Please notify me as soon as possible if there are any objections to the use and redistribution of this database. If that is the case, I will delete this project immediately. However, if I may be granted permission to redistribute the database containing the unmodified scriptures, I would greatly appreciate a response which states what my rights are in this matter.

Thank you for your time! Have a wonderful day.

Sincerely,

Josh VanderLinden

Developer

I got my reply today:

Dear Josh VanderLinden:

Thank you for your email dated 9 June 2008 requesting permission to use a database containing the LDS Standard works to redistribute.

After reviewing your request we have determined that we must deny your request for the use of this material. Church policy does not allow its intellectual properties to be used as you are requesting.

We appreciate your intentions, but trust you will understand and support the decision of the Church in this matter.

Thank you for checking with us.

Bobbie Reynolds, Paralegal

Intellectual Property Office

Somehow I could see this coming. I was curious, however, to determine if there was a way I could avoid litigation by modifying the way the program operates. So I responded with this message:

Hello Bobbie,

Thank you for your reply. I'm sorry that the verdict was not in my favor, but I do understand completely. Otherwise, I wouldn't have asked in the first place. Before I remove the project from the Internet, I would like to ask one more question. Is there a way I could somehow make the program legal? I've noticed that other some programs for the scriptures don't exactly redistribute the scriptures with the program itself. Instead they seem to download the scriptures from scriptures.lds.org (or elsewhere?) on an individual level, and the individual who runs the program has to specifically tell the program to do so. Would that be a more appropriate route for my project to take? Or would that also violate the rules?

Thanks again,

Josh VanderLinden

After only a few hours, I received the following reply:

If I understand you correctly, this also sounds like a reformatting project, which is restricted. Thank you for requesting further clarification and for your compliance to Church policy.

Bobbie

So it looks like I will have to discontinue this project, or at least not allow other people to use my work and keep it all to myself. In compliance with the message communicated to me by the legal representatives of the Church, I have removed the project from Google Code, and it shall remain a project for my own purposes. My apologies go out to everyone who actually found this program useful and promising. I can't blame the Church for being strict in its policies--neither should you.

Introducing PyScriptures 0.3a

So I worked on my scripture program a bit more this past week. I've added a lot of the features I originally planned to implement. There are still some other things I plan to implement (such as the advanced search), but I think it's looking pretty good right now as far as features are concerned.

I do realize that there are some parts of the program that are still shabby. A lot of the code could be optimized quite a bit, and the code really needs more refactoring (though I did a considerable amount of that already).

This release would have happened a day or two ago, but my parents were in town and we were having a good old time together. I also ran into some problems that were only present on MacOS, so I had to track those down before I felt comfortable releasing a new version.

Anyway, it's here! Go ahead and download it from http://code.google.com/p/pyscriptures/

PyScriptures 0.2a Is Here!

So, for those of you who aren't in my immediate vicinity or who aren't on Google Talk all the time, this might well be your first exposure to my latest project. I'm calling it PyScriptures. Py because I wrote it all in Python. Scriptures because it is a program that provides the entire LDS standard works (as far as the actual scriptures are concerned, anyway).

Some History

(feel free to skip to the good stuff if you don't care about history, or skip to the downloads)

I have been working on this sort of program for a very long time. My first attempt was way back in probably 2001, using PHP. I wanted to have a way to easily read the scriptures on my computer without requiring an Internet connection. To go along with this, I wanted to be able to highlight text, mark verses, and easily navigate the scriptures. Obviously, I never quite got it right--that's why I'm still working on new versions all the time.

After a while, I learned that I would be getting a nifty Sharp Zaurus SL-5500 as a graduation present. It's a Linux-based PDA (one of the first, actually), and it's still pretty powerful considering that it's 6 years old now. Anyway, once I got that little gadget, I wanted to get the scriptures on there, too. I didn't have any of the MarkMyScriptures software that other PDA users enjoyed, because of the different operating system. Not to mention how cheap I am (I hate buying software). I ended up porting my PHP/MySQL version of the scriptures to my PDA and using it that way for a little while, but that proved to be very inefficient. The project went on hold for a while, during my time as a missionary in Romania.

When I returned home from my mission, I picked up the scriptures project again. I think my next stab was a Swing-based Java application. It worked well enough, but it never really got too far beyond, "Oh look! The scriptures!"

It was also during the time I was working on the Java version that I realized that the database I was relying upon for my scriptures was incomplete. I'm not sure what the extent of the missing information was, but I remember specifically looking up Doctrine & Covenants 77 only to find questions with no answers. The database was also not very "normalized" but that's more of a nerdy topic, so I will spare you the details. I attempted to contact the bloke in responsible for maintaining that database to let him know of the problems, but it seems like he died or something. Absolutely no response from him, and no activity on his website for two years.

After discovering the lack of complete scripture in that database, I made a promise to myself that I would make my own version of the database so I wouldn't have to stumble upon more incomplete or inaccurate scriptures. This became a reality early in May, as I wrote a program (in Python) that actually downloaded (I call it "harvesting") all of the scriptures directly from the Church's website. It took quite a bit of time to perfect, but as far as I can tell, it works great now. It puts all of the scriptures in a nice, normalized database. So far I know it works with SQLite and MySQL, but it should work just dandy with others as well.

Once I had that fresh database, I began working on a graphical interface for the scriptures. I had been tinkering with something called wxPython for a little while, but I'd never really built anything useful with it. I could never get used to laying things out after using the amazing GUI builder in NetBeans.

This past weekend I've been hacking nearly non-stop to get a nice, functional interface for my scripture program. I'm very satisfied with it, and I have to admit that it performs far better than any previous iteration of this project. There's still a lot to be done to make it work the way I want it to, but here's a brief list of features in this version 0.2a release:

Features Include:

  1. Cross-Platform Compatible: This program works exactly the same on Windows, Linux, and Mac. I've tested it on Windows XP, Vista, Ubuntu Linux, Slackware Linux, and MacOS X (leopard) and have only found minor differences that don't really matter anyway. The program itself does work though.
  2. Fast: Python does a good job at working quickly, even with my crummy code. It boasts incredible speed when retrieving and rendering the entire canon of scripture.
  3. Simple searching: You can type in a word, part of a word, or a whole phrase, and it will find any and all matches (case-insensitively) in the entire standard works.
  4. Quick Jump: Know the exact reference to the scripture you want? Type it in and you're immediately taken to that verse. I never understood why other programs don't have this feature. My implementation is not perfect, but it sure as heck didn't take much to get it where it is.
  5. Adjustable font sizes: You can easily adjust the size of the scripture text (within reasonable limits). That way you can make it easier to read if you're not sitting right in front of your computer.
  6. Easy navigation: You can quickly and easily jump to the next or previous chapter or book. I realize that this might not be very useful to a lot of people, but I love this sort of functionality.
  7. Random verse: Click one button to jump to some random verse anywhere in the scriptures. This is mostly a database deal, and it seems to prefer the Old Testament in my experience. Maybe that's just because the Old Testament probably has more verses than the rest of the volumes put together?
  8. Good memory: Prefer to have your window maximized? Don't like seeing the toolbar? The program will remember things like that, as well as the size and position of the window on your screen (if it's not maximized) and what verse you had selected immediately before closing down the program.
  9. Keyboard shortcuts: For those of us who hate to use mice, there are keyboard shortcuts to do most things in the program.

There's still more fun stuff to come, but I had to get something out the door. I spent most of today just trying to get the program to behave well on other platforms (mostly Windows), because I develop on Linux. If you're interested in trying out what I have now, feel free to download whatever suits you best:

Downloads

Windows Installer (32-bit) (9.0MB)

Debian Linux (including Ubuntu) (2.9MB)

Launch pyscriptures after installing and it should work.

MacOS X (11.3MB)

Man... Gotta love the size differences.

Requirements

This program requires Python 2.4+, pysqlite2 (or sqlite3 if you have Python 2.5), and wxPython 2.8+. These may be different, but that's what I used to develop with, so I know it works with them. The Windows installer should include everything you need to get started, as should the Mac installer.

Note: The .dmg is very, very shabby right now. I plan on making it prettier as time goes on, but this _is_ an alpha release, after all. You can't expect too much.

I should stop here. Enjoy!

Super Computer

Ported From Blogger

The following post was ported from my old blogger account.

One of my good friends recently purchased a super nice computer system which should last him quite some time. He and I go back a couple years, and we devised a plan as to how I would set up his supercomputer when he got it a year and a half or so ago. This past weekend we carried out our plans. Saturday morning I woke up early and took my road trip up to Montana to take care of business.

I arrived at my friend's house around 10AM and work immediately commenced. Before I get too far into the details of the weekend, let me share a few of the vital specs of his computer:

  • Processor: AMD Athlon64 x2 4200+ (2.2Ghz) with liquid cooling
  • System Memory: 2GB DDR
  • Video: nVidia GeForce 7600 GS (512MB RAM)
  • Hard Drive: 2x 160GB SATA-II (320GB total)
  • Optical Media: 2x DVD+/-RW drives
  • Network: Wireless RaLink 2500 series
  • Monitor: 2x 19" Viewsonic LCD
  • Speakers: 5.1 Creative Surround Sound

Yeah, it's pretty sweet. I thoroughly enjoyed being able to work on it. I'll have to post some pictures of my friend's computer sometime. Ok, now on to the details of setting up his system.

My friend wanted to have both Windows and Linux on his system. We spent quite a bit of time around each other. Being the Linux nut that I am, he heard so much about Linux and wanted to get his fix. But he also wanted Windows for games and whatnot. Understandable. So we began the day trying to install Windows XP SP2 on his box. That was thoroughly painful, as usual. Installing a single driver, rebooting, installing another driver, rebooting, installing yet another driver, and once again rebooting. You'd think that the actual installation of Windows XP on a system such as his would be quite speedy. No, no... Microsoft never ceases to amaze me with the speed of Windows--or the lack thereof. It took at least an hour to get through all of the initial booting, setting up the partitions in a fashion that Windows could handle, installing drivers, and finally minimal essential software. Very rediculous. One of the best parts was that Windows somehow installed itself on the second hard drive...because of this (or some other unknown cause) Windows could not boot itself up. We had to use another bootCD in order to boot Windows. I assumed that GRUB (a Linux bootloader) would be able to circumvent this problem.

Once the first installation of Windows was complete and we had a backup of the installation, we proceeded to install SuSE 10.1 x86_64. This installation was painless. Everything worked extremely well. The hardest part about getting Linux to function properly was figuring out why his wireless adapter wouldn't connect to his router. It took a bit of time, but eventually we found the solution online (this solution also applied to my laptop, so I have great wireless in Linux now). As I was getting certain multimedia applications installed on Linux (since they're not included with SuSE for copyright reasons), we watched Hitch on the second monitor. It was great. Eventually Linux appeared to be set up and running perfectly. That was about the time we reboot Linux for the second time (once during installation, if I remember correctly).

Come to find out that not even GRUB could boot Windows. We were greatly frustrated, and my friend began to understand slightly more why I like Linux more than Windows. We decided to swap the hard drives around so that the drive with Windows already on it would be the primary master. I warned him that it would mean reinstalling Windows because it wouldn't know where to find itself after swapping the drives around. He was down with that, so that's what we did. We ran through the whole bloody process again. At least this time we knew what to expect when Windows complained about drivers--we'd already experienced it only hours before.

This installation of Windows went a bit more smoothly, but it also meant that we'd have to do something to get Linux back to an operational stage (firstly, get the GRUB boot menu back). I believe it was the first time I rebooted the computer after the second Windows installation that we got a "NTLDR is missing" error. Blasted Windows. I solved that problem, but then it started complaining about an invalid boot.ini file. Rubbish.

All we needed to do for Linux was pop the first install CD back in and run a rescue utility. It examined the existing installation and modified configuration files according to the drive swap. Linux was back up and running within 5 or 10 minutes. Windows, on the other hand, continues to complain at boot about the invalid boot.ini file.

And once again, my contempt for Windows has been reaffirmed. The only reasons I keep Windows around is for Adobe Creative Suite 2 and a game here or there. Even Google Earth runs natively on Linux (as of yesterday).

Google AdSense

Ported From Blogger

The following post was ported from my old blogger account.

So, I recently started this blog thing, right? To my surprise, the "dashboard" or control panel has a special spot for one to add Google Ads to their blog with great ease! I, after having heard of others' successes with Google Ads, decided to give it a go. My very first post (which has been removed already) mentioned how I would be joining the c h a o s of bloggerdom. Google Ads saw the 'C' word in the previous sentence and put ads about hurricanes and natural disasters all over my page!! It wasn't until I removed that post that the ads changed to something about blogs.

Over in my links you'll notice that I have one to a blog called "Rug Burns." All of the Google Ads on his page are about burns and first aid. It doesn't matter what he posts on his blog--the ads always seem to talk about the title of his blog.

Very strange. Let's see if my ads change now that I've mentioned his title in this post. :D