That might have been true when it was launched in 2003, but WordPress has evolved far beyond its humble blogging origins. So much so, that when one of our larger clients wanted to completely redo their website, we recommended WordPress as the core platform. Yes, WordPress. This is a client that sells thousands of different products, has hundreds of customers, and even has an international presence. So why choose WordPress, when something like Drupal would seem to offer more functionality out-of-the-box?

The primary advantage is this: WordPress evolved from a tool for non-technical users. It started life as a blogging tool. WordPress does a great job of making the most common user-initiated tasks (updating pages, posting blog entries, etc.) simple and painless. The 22,000+ plugins gave us rapid access to great search-engine optimization features, calendar management, etc. We were also able to take a commercial WordPress theme and easily adapt it to suit our customer’s branding guidelines. Launching a full-featured corporate website couldn’t have been easier.

But the public-facing website isn’t the complete story. A $200+ million company needs to provide access to business information to its employees and customers. Authentication and authorization are critical areas of functionality that need to be addressed. Then the real power of WordPress as an enterprise platform became apparent. There are currently 1,600+ hooks built-in to WordPress, which means that developers are able to control virtually every aspect of site operation.

Rather than looking at WordPress as an anemic enterprise CMS platform, we chose to look at it as a remarkably lightweight and flexible launchpad for our own custom enterprise functionality. And out of our development work, we developed what we call the WordPress Enterprise Framework (the WEF). It currently consists of a plugin, some theme elements, and some auxiliary code that runs on our client’s public-facing IIS site.

Using the WEF, we’ve implemented a single sign-on function using Active Directory that synchronizes user information from the client’s corporate network into WordPress. We’ve also developed a native PHP IDE that lets us use WordPress post features (such as draft and versioning) to develop and deploy new enterprise functionality in a controlled manner in our actual production environment.

I’m sure everyone is tired of hearing the “less-is-more” aphorism, but when choosing a platform for a new enterprise-wide web portal it’s definitely something to keep in mind. Any non-trivial project will eventually require custom coding, so as a technical decision maker you just have to think: is it better to start out with a complex (but full-featured) system that will be difficult to extend later, or a simpler (but very easy to modify) system?

Digging thorough the development server documentation, I found two options that are making my life much easier:

–use_sqlite

Use sqlite for the local datastore.

–datastore_path=[path to datastore file]

Keep the datastore in the file specified.

By doing these two things, you can now see where GAE is keeping your datastore and you can make intermediate backups and restore them at will. You can also view your datastore using the command line sqlite client. Just add these two parameters to the Extra Flags box in your app’s info in the App Engine Launcher (or to the command line) and you’re good to go. Enjoy!

Originally submitted at O’Reilly

You can build a variety of amazing apps on the iOS platform—and every one of them presents a unique set of problems. With the recipes in this cookbook, you'll go beyond theory to solve the vexing, real-life issues you’re likely to face when creating apps for the iPhone, iPad, or …

iOS 4 Programming Cookbook

Chock full of code.

Pros: Helpful examples

Best Uses: Intermediate, Expert

Describe Yourself: Developer, Educator

Disclosure: I’m an O’Reilly Author and developer of the Great iPhone Development Video series. That being said, I’m not one for pulling punches when I see issues with with people’s code (ask anyone I’ve ever code reviewed .

This is the book I wish I’d had when I started developing for the iPhone. I started writing apps about two weeks after the infamous Apple Developer NDA was lifted and information started trickling out onto the Internet. If I’d have had a book like the iOS Cookbook I could have saved myself many hours of painful trial and error while learning Objective C and what is now the iOS API.

This is not really a book for a beginning iOS programmer. It’s a book for someone who’s done a couple of simple apps and has the basic idiom down. If you’re looking to learn Objective-C or the mechanics of writing an iPhone app, this book will not help you. But if you can already write a functional app, the code snippets in this book will trim lots of time off of your learning curve when it comes to implementing more sophisticated features like Core Data, gestures, etc.

There are a few areas where the examples could be clearer, and it’s clearly impossible to cover some of the more sophisticated functions of areas like Core Data in 620 pages. But overall this is an excellent REFERENCE for new and experienced app developers alike, and I’d recommend adding it to your library.

(legalese)

	[[theApp.managedObjectContext undoManager] disableUndoRegistration];
	detailItem.fieldImageFile = relativePath;
	[[theApp.managedObjectContext undoManager] enableUndoRegistration];

Seemed very clear, but it didn’t work! So, after much poking around on the Internet, I found a posting that alluded to the fact that changes to undo don’t occur until the run loop executes. So, to get the desired effect, I ended up with the following code:

	[[NSRunLoop currentRunLoop] runMode: NSDefaultRunLoopMode beforeDate:[NSDate date]];
	[[theApp.managedObjectContext undoManager] disableUndoRegistration];
	detailItem.fieldImageFile = relativePath;
	[[NSRunLoop currentRunLoop] runMode: NSDefaultRunLoopMode beforeDate:[NSDate date]];
	[[theApp.managedObjectContext undoManager] enableUndoRegistration];

Yet another head-scratching API decision from Apple.

What I wanted to do seemed simple: have a map view with a bunch of moving objects on it. Each object pulls its current position from an XML document on the web. I already had my XML-wrapper object written when I wanted to display it on the map, so I simply implemented the MKAnnotation protocol. All of my objects appeared, and all seemed to be right with the world.

Then, I started updating my objects and found that the annotations didn’t move. At all. I found a bunch of people on the web trying to solve the same problem, but I wasn’t very happy with the solutions I found. Most of them involved removing the annotations and adding them back into the map view. But, thankfully, I found one article that mentioned KVO on the iPhone. I was pretty familiar with KVO from my Flex projects, but didn’t even realize it was supported in Objective C.

To make a long story short, if you don’t use the willChangeValueForKey and didChangeValueForKey before and after updating your coordinate property on your annotation object, the MKMapView will not be aware that it has moved. After bracketing my XML update code with those two calls, all of a sudden my annotations started moving around.

-(void)xmlProperty:(NSString *)newXml
{
	[self willChangeValueForKey:@"coordinate"];
	[xml release];
	xml = [newXml retain];
	[self didChangeValueForKey:@"coordinate"];
}

I was able to extend the NSManagedObject class and add a new xmlString property. By using the entity property to do some simple introspection, I was able to write a serialization function in about 50 lines of code. Enjoy!

NSManagedObject+XMLSync.h

//
//  Created by Scott Means on 1/5/11.
//  Released into the public domain without warranty.
#import <CoreData/CoreData.h>
#import <Foundation/Foundation.h>

@interface NSManagedObject (XMLSync)

@property (nonatomic, readonly) NSString *xmlString;

@end

NSManagedObject+XMLSync.m

//
//  Created by Scott Means on 1/5/11.
//  Released into the public domain without warranty.

#import "NSManagedObject+XMLSync.h"

@implementation NSManagedObject (XMLSync)

- (NSString *)xmlString
{
	NSEntityDescription *ed = self.entity;
	NSURL *uri = self.objectID.URIRepresentation;
	NSMutableString *x = [NSMutableString stringWithFormat:@"<%@ id=\"/%@%@\"",
                ed.name, uri.host, uri.path];

	for (NSString *a in ed.attributesByName.allKeys) {
		id value = [self valueForKey:a];

		if (value) {
			if ([value isKindOfClass:[NSString class]]) {
				[x appendFormat:@" %@=\"%@\"", a, value];
			} else {
				if (![value respondsToSelector:@selector(stringValue)]) {
					NSLog(@"no stringValue");
				}
				[x appendFormat:@" %@=\"%@\"", a, [value stringValue]];
			}
		}
	}

	bool hasChildren = NO;

	for (NSString *r in ed.relationshipsByName) {
		if (!hasChildren) {
			[x appendString:@"/>"];
			hasChildren = YES;
		}

		NSRelationshipDescription *rd = [ed.relationshipsByName objectForKey:r];

		if (rd.isToMany) {
			hasChildren = YES;
			[x appendFormat:@"<%@>", r];

			for (NSManagedObject *c in [self valueForKey:r]) {
				[x appendString:c.xmlString];
			}

			[x appendFormat:@"", r];
		}
	}

	if (hasChildren) {
		[x appendFormat:@"", ed.name];
	}

	return x;
}

@end

Next project: figure out how to do better code formatting in WordPress!

So, wanting to do my bit, I created a new website called Native Code to try to make this easier. My goal is to create a database of common low-level coding idioms (micro-patterns, if you like) and then have them expressed in as many programming languages as possible. And not just expressed, but expressed well. So, please feel free to add your own contributions, create your own idioms, and otherwise capture your coding know-how for the ages. Enjoy!

http://www.meetbarb.com/2009/10/guest-blogger-scott-means.html