I recently had to password-protect a subdirectory of my site and found existing documentation on this to be wholly inadequate -- at least applied to sites utilizing Apache and Django. The problem is that to password-protect a subdirectory, one must write rules in an .htaccess file residing in the parent directory. Since Django projects use a hand-written URL dispatcher, the directory structure of the resulting Web site doesn't reflect the structure of the internal storage system.

Fortunately, the solution is simple. Instead of writing your Apache directives in an .htaccess site, write them where your Django configuration resides. This will typically be your httpd.conf or site-specific configuration files you've created in your Apache sites-available/ directory.

I made a copy of my existing configuration under the location "/subdirectory," and added the following directives.

 <Location "/subdirectory">
    AuthType Basic
    AuthName "My Secret Site"
    AuthUserFile "/path/to/.htpasswd"
    Require user username
    ... 
</Location>

Be sure to use the "htpasswd" command on Unix to make an .htpasswd file in a directory on your server. Change the path in my sample above to where you store the file. Be sure that "username" matches the username you create using htpasswd.

That's it. If you know how to do this without duplicating my existing configuration, please post how to do so in the comments. That would be much appreciated.

(This is the third in a three-part series for programmers with tips on making the leap from Web to the iPhone)

Your interface and business logic need to be connected manually

Experienced Web developers can traverse up and down the DOM tree like wild monkeys. The iPhone SDK utilizes .xib files that are XML-based as well for the UI, but the Web model doesn't quite carry over. Imagine, instead, that for each DOM element that you access in your JavaScript code, you have to write special instructions indicating you want to access them. There are two steps for writing these instructions:

1. Define a property in your header file that serves as an "outlet." Here is an example:

   @property (nonatomic, retain) IBOutlet TextField *myTextField;
   

   (be sure to define this property under @interface in the header and file and to @synthesize it in your implementation file)

2. Open up your .xib file in Interface Builder, and make the connection. You can right-click on the view you want to become an outlet or on the File's Owner to accomplish this.

   Carefully remembering to do this will save you a lot of grief.

Do you have other relevant tips? Please post them!

(This is the second in a three-part series for programmers with tips on making the leap from Web to the iPhone)

As Web developers move from building static pages to rich Web apps, our browsers begin to buckle under the weight of heavy JavaScript. There's not a lot we can do about this beyond high-level optimizations aside from praying that V8 gains more market share rapidly. For those that haven't written production code in C, it can seem quite daunting. It shouldn't be. There's a fundamental rule that iPhone owners can follow from the time they write their first app (from the Apple Objective-C Memory Management Rules):

You take ownership of an object if you create it using a method whose name begins with “alloc” or “new” or contains “copy” (for example, alloc, newObject, or mutableCopy), or if you send it a retain message. You are responsible for relinquishing ownership of objects you own using release or autorelease. Any other time you receive an object, you must not release it.

This explains why many constructors for Foundation classes have a class method "counterpart." One example is NSString:

+ string
– init
+ stringWithCharacters:length:
– initWithCharacters:length:
+ stringWithString:
– initWithString:
+ stringWithCString:encoding:
– initWithCString:encoding:

The difference between the class methods and the traditional constructors is how memory is managed. For all classes prefixed with init, the caller is the owner. For all class methods, the callee determines ownership. This materializes like so in your code for the two types of constructors:

- (void)manipulateString:(NSString *)_string {
    NSString *newString = [[NSString alloc] 
        initWithString:@"Sample String"];
    // do stuff...
    [newString release];
 }
 

- (void)manipulateString:(NSString *)_string {
    NSString *newString = [NSString 
        stringWithString:@"Sample String"];
    // do stuff...
}
 

Additionally, if you are creating objects and returning them, use "autorelease":

- (NSString *)returnString {
    NSString *newString = [[[NSString alloc] 
        initWithString:@"Sample String"] autorelease];
    // can't release the string before returning it!
    return newString;
 }
 

I recommend reading the Memory Management Rules before beginning your first serious project. It will most certainly be a problem for amateur Objective-C developers. Practice makes perfect.

(Continue to part III...)

Having recently forayed into the world of iPhone development, I've had to adjust to the unique software stack that comprises the iPhone SDK. My first love is and always will be Web development, but the Apple platform is well-architected and produces beautiful software quite easily. Here are a few tips for new developers that come from the Web world. The followings tips should help guide you over the bumps of jumping from the world of Javascript and CSS to Objective-C and Cocoa.

Good Web developers and designers advocate flexibility above all else. Flexibility can be a blessing and a curse. HTML and CSS provide an inherently restricted toolset, intended to accommodate a widespread number of unknown use cases, giving the user maximum control. While Web designers become increasingly sophisticated and can build designs that are both aesthetically and flexible (see the CSS Zen Garden* for examples), it is a rare gift. Fortunately, for the rest of us, the iPhone/iPod is a single interface, with the iPad coming to stores soon. Having a limited number of devices on which our iPhone app can be viewed means that we know exactly how the app is being visualizing. 

The limitation materializes into more feedback about the visual attributes of Strings, for instance. One of my favorite code snippets is the ability to check the text size:

 // Calculate the expected size based on the font and
 // linebreak mode of your label
 
 CGSize maximumLabelSize = CGSizeMake(280, 9999);

// Use default system font (Helvetica) at size 16 for
 //     programmatically created label
 CGSize expectedLabelSize = [((UILabel *)instruction).text
                 sizeWithFont:[UIFont systemFontOfSize:16.0]
                 constrainedToSize:maximumLabelSize
                 lineBreakMode:UILineBreakModeWordWrap];

 // Create my label programmatically...

CGRect newFrame = myLabel.frame;
newFrame.size.height = expectedLabelSize.height;
myLabel.frame = newFrame;

(originally pulled from Stack Overflow)

(Continue to part II...)