Content & Technology Crossroads

New Blog

nospam@example.com (Nick Mudge) — Mon, 07 May 2007 01:02:48 -0400

I have a new blog I'm using. Check it out: www.nickmudge.info

Blogging Makes You Think

nospam@example.com (Nick Mudge) — Sun, 07 May 2006 23:11:26 -0400

Paul Graham has an interesting perspective on a reason why bloggers may like to blog:

I think what most bloggers are doing is thinking out loud. It's a little misleading to talk of "putting things into words," because that implies the ideas come first. In fact, expressing thoughts creates them. And especially expressing thoughts to other people, even people you don't know. So I think the reason many people like blogging is that they like the thinking it causes.

Paul Graham: What Drives Bloggers?

Lessons for Startups by Paul Graham

nospam@example.com (Nick Mudge) — Sun, 07 May 2006 22:59:33 -0400

I recently read and liked Paul Graham's essay, The Hardest Lessons for Startups to Learn.

Changing State in Memory

nospam@example.com (Nick Mudge) — Mon, 01 May 2006 20:32:49 -0400

I enjoyed Damien Katz' awesome post about error handling.

On Asking Questions and Getting Help

nospam@example.com (Nick Mudge) — Sat, 29 Apr 2006 13:12:46 -0400

Last night and today I read Eric Raymond's How To Ask Questions The Smart Way. I really really like it and learned a lot.

There's some great information in there. Here is just a little bit:

In the world of hackers, the kind of answers you get to your technical questions depends as much on the way you ask the questions as on the difficulty of developing the answer.

Before asking a technical question by e-mail, or in a newsgroup, or on a website chat board, do the following:
1. Try to find an answer by searching the Web.
2. Try to find an answer by reading the manual.
3. Try to find an answer by reading a FAQ.
4. Try to find an answer by inspection or experimentation.
5. Try to find an answer by asking a skilled friend.
6. If you're a programmer, try to find an answer by reading the source code.

Use tactics like doing a Google search on the text of whatever error message you get (searching Google groups as well as Web pages). This might well take you straight to fix documentation or a mailing list thread answering your question. Even if it doesn't, saying I googled on the following phrase but didn't get anything that looked promising is a good thing to include in e-mail or news postings requesting help.

I love this one:

Much of what looks like rudeness in hacker circles is not intended to give offence. Rather, it's the product of the direct, cut-through-the-bullshit communications style that is natural to people who are more concerned about solving problems than making others feel warm and fuzzy.

I love this one too:

If you did research to answer the question, demonstrate your skills rather than writing as though you pulled the answer out of your butt. Answering one good question is like feeding a hungry person one meal, but teaching them research skills by example is teaching them to grow food for a lifetime.

Internet Explorer Caching AJAX Calls

nospam@example.com (Nick Mudge) — Mon, 24 Apr 2006 20:50:32 -0400

Yesterday I found out that after executing an AJAX call Internet Explorer will cache the results of future repetitive calls if they are the same -- and serve the cache results, not actually repeate the calls.

Let's say the AJAX call is to this this url: (http://www.somehost.com/people.php?age=3). And people.php echos the text "This has been done." and the javascript that receives this text uses the alert() function to pop it up on the screen.

The first time IE runs this javascript the AJAX call will work fine, and a pop up will show saying, "This has been done." The second and subsequent times IE runs this javascript the call will not be made -- people.php will not be run. Instead you will get the cached result, which is the pop up "This has been done."

Firefox doesn't work like this. Firefox works as should, will actually repeatedly make the calls and not cache the results.

What if you want to make multiple AJAX calls that are the same and not be fed cache?

I learned a cool hack from Lonnie Lee Best to solve the problem. She wrote about it here, which is where I found out how to solve it.

The key is that IE will feed you cache if the url is the same. So you just need to have a different url everytime you make an AJAX call.

This will solve it:

url = "http://www.somehost.com/people.php?age=3" + "&ms=" + new Date().getTime();

Date().getTime(); gives you the number of milliseconds since the first day in 1970. That will ensure that your url is always different. people.php will just ignore ms.

The Little Bug

nospam@example.com (Nick Mudge) — Sun, 23 Apr 2006 21:07:50 -0400

Earlier today I had an application I'm building working beautifully. I was a little surprise that I'd finished it already and that it was working so well. I left it for a few hours to do some other things. Before I left I changed the name of the application and changed the directory of the application to reflect the application's new name.

I come back and it isn't working. I look into my code, see nothing wrong. I think oh no, I must have some fundamental flaw that is throwing it off. I was scared of finding the bug because it would probably take many hours of programming to fix. I can't even find the bug.

I found the bug. I'd changed the directory name the application resides in. A url in the program was mapped to the old directory name. Fixed one line of code and everything works again. Man, those little intimidating bugs -- which are really nothing at all -- are annoying.

Cost of AJAX

nospam@example.com (Nick Mudge) — Thu, 20 Apr 2006 09:47:35 -0400

I absolutely love Tim Bray's writing. Here he writes about whether AJAX is less or more expensive resource-wize.

Tools Used by a Web Designer

nospam@example.com (Nick Mudge) — Sun, 16 Apr 2006 00:44:17 -0400

Tim Bednar wrote a post about the tools he uses in web design.

Here's a part I liked:

I am self taught. I learn everything by searching Google, using free tutorials or simply hacking code I find. For instance, I plan to learn Ruby on Rails this year through tutorials and resources I find online.

Book Review: The JavaScript Anthology

nospam@example.com (Nick Mudge) — Sat, 15 Apr 2006 22:42:14 -0400

Stuart Halloway wrote a book review of The JavaScript Anthology. It's about AJAX and Javascript.

Here's a summary:

To sum up, this is a well-organized, solid book. It will be most useful for people writing and supporting "raw" JavaScript. Most Ajax developers should be using libraries to handle much of this low-level detail. That said, you always need solid knowledge of at least one level of abstraction beneath the one where you are working. Read the JavaScript Anthology to learn that next level down, and stay tuned for future reviews where I'll cover some books that target Ajax more directly.

"...you always need solid knowledge of at least one level of abstraction beneath the one where you are working." That's something I think about.

Four other AJAX book reviews over there as well.

Programming API Site

nospam@example.com (Nick Mudge) — Sat, 15 Apr 2006 22:16:16 -0400

This AJAX programming API site is cool.

SQL, Programming Articles

nospam@example.com (Nick Mudge) — Sat, 15 Apr 2006 22:02:48 -0400

Adam Plocher recently wrote some nice programming articles, such as SQL Injections in PHP with MySQL, Stored Procedures in MySQL 5.0, Triggers in MySQL 5.0, and more.

Hacker HOW-TO

nospam@example.com (Nick Mudge) — Sat, 15 Apr 2006 21:56:00 -0400

I read How To Become A Hacker, by Eric Raymond. I really like it.

Graphic

nospam@example.com (Nick Mudge) — Sat, 15 Apr 2006 21:41:44 -0400

Tim Bray links to this interesting dialog and to David Heinemeier Hanssons graphic.

HTTP Basic Authentication in Python

nospam@example.com (Nick Mudge) — Sat, 15 Apr 2006 21:03:14 -0400

Recently I found out how to write a script in python that accesses a webpage that requires basic http authentication. You know, when you try to go to a webpage with your browser and a username and password screen pops up. Well to download one of these webpages with a script you have to provide the username and password in the http headers of the request.

Here's how I did it in Python:

import urllib2
auth_handler = urllib2.HTTPBasicAuthHandler()
auth_handler.add_password("Realm here", "host", "username", "password")
opener = urllib2.build_opener(auth_handler)
handle = opener.open("URL you want to download")
file = handle.read()

This is very similar to the authentication example using urllib2 given in the Python Library Reference.

Here's code in PHP that seems to do this.

Here's a description of how urllib2 works. This is taken out of the urllib2._doc_ variable:

urllib2
An extensible library for opening URLs using a variety of protocols.

The simplest way to use this module is to call the urlopen function, which accepts a string containing a URL or a Request object (described below). It opens the URL and returns the results as file-like object; the returned object has some extra methods described below.

The OpenerDirector manages a collection of Handler objects that do all the actual work. Each Handler implements a particular protocol or option. The OpenerDirector is a composite object that invokes the Handlers needed to open the requested URL. For example, the HTTPHandler performs HTTP GET and POST requests and deals with non-error returns. The HTTPRedirectHandler automatically deals with HTTP 301, 302, 303 and 307 redirect errors, and the HTTPDigestAuthHandler deals with digest authentication.

urlopen(url, data=None) -- basic usage is that same as original urllib. pass the url and optionally data to post to an HTTP URL, and get a file-like object back. One difference is that you can also pass a Request instance instead of URL. Raises a URLError (subclass of IOError); for HTTP errors, raises an HTTPError, which can also be treated as a valid response.

build_opener -- function that creates a new OpenerDirector instance. will install the default handlers. accepts one or more Handlers as arguments, either instances or Handler classes that it will instantiate. if one of the argument is a subclass of the default handler, the argument will be installed instead of the default.

install_opener -- installs a new opener as the default opener.

objects of interest:
OpenerDirector --

Request -- an object that encapsulates the state of a request. the state can be a simple as the URL. it can also include extra HTTP headers, e.g. a User-Agent.

BaseHandler --

exceptions:
URLError-- a subclass of IOError, individual protocols have their own specific subclass

HTTPError-- also a valid HTTP response, so you can treat an HTTP error as an exceptional event or valid response

internals:
BaseHandler and parent
_call_chain conventions

Example usage:

import urllib2

# set up authentication info
authinfo = urllib2.HTTPBasicAuthHandler()
authinfo.add_password('realm', 'host', 'username', 'password')

proxy_support = urllib2.ProxyHandler({"http" : "http://ahad-haam:3128"})

# build a new opener that adds authentication and caching FTP handlers
opener = urllib2.build_opener(proxy_support, authinfo, urllib2.CacheFTPHandler)

# install it
urllib2.install_opener(opener)

f = urllib2.urlopen('http://www.python.org/')