Code. Design. Explore.

I’m going to keep this short because I’ve been extremely productive today and want to continue this trend for a couple more hours.

I would like to start by saying that I heart Firefox. And probably Joe Hewitt as well, but for developing Firebug.

I love JavaScript development. Although JavaScript may seem very ‘laxed, its prototypically inheritance and DOM manipulation is fantastic! But this post isn’t about that. It’s about what to do when you switch browsers, hold your breath, and try to see what IE spits out.

If you have Office 2003 then you have the Microsoft Script Editor. I read that all over the web, but I tried searching for “mse.exe” and nada. After losing some hair I found it!

You can install it through MS Word. So open it up and follow the image below. Just click on the Script Editor and it will begin installing.

Then, you’ll want to un-disable script debugging. The option is found here: Tools > Internet Options > Advanced > Disable script debugging (Internet Explorer).

A lightweight debugger

Before making this find I took a few minutes to write a quick logger/debugger that works in both FireFox and IE (not tested elsewhere, but *should* work). =)

There are some powerful loggers out there, like YUI Logger, but it was easier for me to crank this out than spend some time reading APIs and other doc.

Here’s my lightweight, ~4K debugger. Debug.js. Just include the file above where you call the debugger. The call looks like this:

DEBUG.debug('a debug message');
DEBUG.warn('a warn message');
DEBUG.error('an error message');

Quick review of other IE debuggers

Added: May 12, 2008

DebugBar

Pros:
• Can view DOM
• Displays more information during script error than IE w/o toolbar
• Built-in HTML validator
• Built-in JavaScript console

Cons:

• DOM changes in toolbar do not refresh in IE7
• Cannot set breakpoints and step through code
• Debug errors have correct line number, but URL is not always accurate (if I have a page, index.html, and include a script, test.js, with errors the error message says index.html has an error)

IE Developer Toolbar

Pros:
• Can view DOM
• Can view all HTML properties (like the random ‘htmlFor’ which is IE’s label property for the ‘for’ attribute)

Cons:

• Not a debugger (so it won’t display scripting errors)
• DOM changes in toolbar do not refresh in IE7
• Cannot set breakpoints and step through code

My vote is for the DebugBar, although it would be great to have the ability to step through code and have more accurate scripting error messages in the future.

It’s not everyone’s job to know the complexities of the world’s creations. In fact I would say that someone trained in a specific field finds that field more complex than someone untrained. That is the point of abstraction though isn’t it?

The average person probably doesn’t care what goes on under the hood of their car, or should they have to. They simply turn the key and the engine starts. Abstraction. The same can be said about computers.

Not everyone majors in CS or CE, and probably for good reasons, but their perspective of computers is so different from mine it sometimes amazes me. For example, I remember in college I would be asked to fix computers, printers, and any other device that has a power cord. I would take a look at it, but wouldn’t guarantee anything. I tried to explain my domain knowledge and that I was a software guy, but for some reason they bucketed software and hardware together. This was interesting because it got me thinking of how many similarities I must make everyday with things I don’t have a deep understanding about.

Another example is a computer screen message. I find it interesting that computer users believe the computer screen as if it was as credible as The New York Times. If the computer program says that it’s saving your document, it has to be saving your document. I would say that the majority of the time this statement is true. But, what about malicious software? I could easily write a problem that tells its users that it is saving a document when in fact it is deleting all the files off your computer.

Ethan Vizitei wrote a great post the other day on a similar subject. He talks about how he was approached by some friends with an idea for a startup. They had this great idea and all they needed was a programmer to throw it together. His friends seemed to think they had figured everything out, and just needed Ethan to bang on his computer to generate a product. And they wanted him to do it for free!

I don’t think his friends are solely to blame, after all how do you know what you don’t know? I think that concept itself is something to be learned though. And it always seems to remind me of a great quote that one of my math professors said (which happens to be Sergey Brin’s Father, Sergey Brin being one of the Google founders) — “The more you know, the less you know.”

This is multi-part series on how to getting running with Pylons, a MVC framework for Python. In Part 1 I discussed how to set up your project, modify the configuration environment and base files. Here I will show you how to set up your model to use SQLAlchemy 0.4.4 and tie it together nicely with Pylons 0.9.6. Some of the code was used straight from the Pylons Official Docs, while other parts were modified to get all my middleware functioning properly. If something is confusing or I didn’t do a good job of explaining, please see that reference. If you are still confused post a comment, and I’ll try to help you out. Thanks!

Building the model

There are 4 main parts to setting up the model.

1. initializing the model
2. creating the SQLAlchemy object and mapper
3. mapping the relations themselves
4. seeding the database

Read the rest of this entry »