I've had the opportunity to work with lots of teams on lots of different platforms in lots of different languages and frameworks. This has been great educationally for me, being able to see more than just two or three pictures. One thing that I have noticed regardless of project, platform or language is the idea of "refactor later."

I think that it's redundant to say that there is value in properly written code, but I'll say it anyway. There is value in properly written code. In an interview one time, I was asked the question "What if I [the project manager] asked you to implement a feature in a given time frame, and you could either do it the 'right' way and miss the deadline, or implement a hack to come back to when there was time and deliver it on time." My naivete got the better of me, and I answered the question the way I thought the interviewer wanted it. "Well, I'd write a test case, implement the hack, and then come back, and using the test case to make sure code didn't get broken, do it the right way." I got the job, and one month into it, I regretted it. The entire attitude of implementing the hack to get out the door was what the whole company was founded under. On the tail end of the job, I was blamed for IMPORTANT code being rolled to production commented out, functionality that only appeared to work being pushed to production, and spending too much time developing what was "simple functionality." Yea, if the code wasn't breaking every time I added a new line...

The "refactor later" pattern plagues so many projects for no reason. From my experience, it stems from a desire to design properly, only to have an issue come up that was unforeseen. The solution is throw something together that works, and "refactor later." I would say, though, that the "later" never comes, and the "refactor" never happens. This amounts to bad things like repeated code, inefficient code, and even unused code.

When I first started getting into electronics and gadgets, I learned a valuable lesson: "Buy cheap, buy twice." I would like to create a similar stigma to a similar situation of cutting corners to cut costs in software development. While I'm not good with the clever wording, it would be something to the effect of "every line of corner cutting code exponentially effects your ability to refactor later." By writing "refactor later" code, you're increasing the threshold on when that "later" happens from maybe a few minutes to days and weeks (and maybe months) refactoring code that, having been written cleaner before, would have been more maintainable, and easier to add functionality to later on.

I've released yet another iteration of The Iron Lion, with the key of this new release being my new knowledge of the newforms library. I've been thinking about adding the ability to comment for a while, and have even blogged about some of the ideas I've had/seen to reduce spam and the like. You'll find the new contact form to be my experiment with the newforms library (and also a solution to putting my email out on the web, even though I've gotten plenty of spam in the email address anyway).

After I pushed this new version, I decided that my naming scheme for my various apps was becoming cumbersome more than clever. I was naming the different apps after planets in our solar system. Cute naming convention, but since this is becoming more than just a few apps, I found it difficult to remember what neptune was, why I need the earth app in this situation, and what pluto was even created for. So I obviously needed to rename these apps.

I was expecting that the process was just a matter of renaming the folders. There were obvious dependencies to worry about, and import calls to fix. So I started by moving the folders around. I then did an fgrep for all the instances of the old names. Using sed, I did a search and replace of each name. For some reason after that, my Django dev server didn't much like the environment variables I had set, and so I had to work out some problems with my environment before I could test it...

One day later, and I was back to work. I browsed around the dev server, to make sure everything was working, and noticed only one thing broken: Tags. This was an opportunity I had been waiting for, actually, and I dove headfirst into the tag database schema. The tags for this site are generated with the django-tagging app, and so I didn't have much experience with generic relations and the like, and I wanted to. I found a table called 'tagged_item' which I invesitigated, and found a reference to a content type id. I figured it must be the django_content_type foreign key, and kept digging. Apparently, django keeps a database of all the installed models, and the apps they are connected to. A few updates later, and I had tags working!

So, in summary, if you want to rename a Django app that's deployed in the field:

1. Rename the folder found in your project root
2. Change any references to your app in their dependencies, i.e. the app's views, the urls.py and settings.py files.
3. Edit the database table django_content_type with the following command: UPDATE django_content_type SET app_label='<NewAppName>' WHERE app_label='<OldAppName>' (Note: for renaming models, you'll need to change django_content_type.name)