Inevitably as you start into a project you realize the full scope of what you’re trying to do, and as you do the finish line moves farther and farther towards the horizon. Most of the changes made were in respect to that.

js-maven-plugin is now js-maven

I renamed and moved the project because it was rapidly growing beyond the scope of a single maven plugin to include core libraries, tooling, archetypes and reports. Rather than try to hammer all these into one single java project I felt that switching over to a multi-module layout would give me the room I needed to grow. So far this seems to have been a good decision, as I now have the sense that I can (mentally) stretch my arms a little.

No more specific version commitments.

I’m making a concession to my own prioritization style here, which is very much a “Hey, this sounds like an interesting problem to solve” method. Needless to say, this doesn’t really work well with preplanned version releases, as there are some projects that are more fun and some that are less fun, and it resulted in me skipping around a lot. Instead, until I’ve got a few more contributors on the project, I’m simply going to outline a feature set for the various point versions and go after features as they strike me.

I understand that for an enterprise this is not the most optimal approach, so I will make this suggestion: If a particular feature is business critical enough for you to write your own solution, why not contribute it while you’re at it?

Documentation!

I’ve finally gotten around to setting up all the maven:site documentation for the project, and it’s now hosted on github’s pages for the project http://krotscheck.github.com/js-maven/ . Similarly, the README.md on github has been reduced to a quick start (since we know we all prefer copy/paste), as I don’t feel that much more was necessary.

Version Dependencies

We now support Maven 3 and Java 1.7 only. Annoying for some of you, yes, however in keeping with my philosophy of using the latest-and-greatest whenever possible we’re just going to put a line in the sand. That’s not to say we won’t ever support other versions, however those ports will have to come from the community (such as it is).

Licensing

I’m still debating licenses. Right now the project is under the MIT license, though I might move it over to New BSD. This project will never be licensed under the GPL or any similar viral/copyleft license, as those tend to greatly inhibit adoption.

Roadmap Commitments for v0.2.0

If you’ll take a look at the roadmap, you’ll see the list of features which I want to have ready for the next minor version release. Notable additions were the reporting plugins for JSLint and JSDoc, as it didn’t make much sense to me to include those without making them accessible either. Here’s a list of where we stand right now, with some details:

Plugin Documentation [branch- jsdoc-improvments]

Now that I’ve got the maven site reports running, they decided to get all unruly and hurt my feelings by insulting my coding style. The inevitable cleanup phase is in progress, which also includes a bit of judicious refactoring as the actual usability of the plugin gets a little focus.

Cleanup

As this is my first large maven plugin project, I’m still learning my way around. Refactoring and cleanup is necessary – for example, sourceEncoding should be handled via the global parameter and not individually per Mojo.

Maven Reports: JSLint and JSDoc

These are two new features I realized would be necessary as I got the site up and running. I’m not at all familiar how plugins like this get wired into maven as a whole, so they might go fast or they might not.

Common JS Libraries in a repository [branch- jslib-redeploy-plugin]

Having a javascript maven framework isn’t much use if you don’t have any libraries that you can depend on, so I’m writing a plugin that’ll take a URI-styled token string and will redeploy any artifacts found into a maven repository. This is proving tricky as I cannot resolve their own version dependencies easily (jqueryUI -> jquery for instance), however it’s coming along nicely. Once this is complete I’ll be able to provide a few more archetypes for other projects. jQuery, JavascriptMVC, you name it.

Unit Testing

I’m still evaluating the best javascript unit testing framework out there. There are many solutions for “How to test a javascript library in different javascript engines and/or browsers, but nobody seems to have figured out the holy grail yet. This feature might get punted into its own release, if it turns out that the scope is too big.

Our documentation generator will be JSDoc, chosen because it’s fairly mature, has a strong following, and its markup is broadly supported across IDE’s. In fact JSDoc seems to be one of the few broadly adopted standards out there, though to speculate why is beyond the scope of this post. What matters is that it’s a documentation writer written in Javascript that is run via Mozilla’s Rhino runtime. To properly run it we’ll have to resolve the dependency, unpack it into a temporary directory, and then spin up Rhino to execute the code.

I encountered a problem in the way JSDoc 2.4.0 interacts with Rhino 1.7RC3, a bug introduced by two inline function declarations without semicolons in TokenParser.js. While on one side one might argue that this is a bug in Rhino, declaring functions inside of other functions is a big no-no in the javascript world. As a result I’ve had to generate and deploy my own patched version of JSDoc.

Resolving JSDoc

All of the plugin artifacts for a given mojo are easily available as a parameter, thus locating the proper version of JSDoc is fairly simple.

/**
 * @parameter default-value="${plugin.artifacts}"
 */
private List<Artifact> pluginArtifacts;

public Artifact locate(String groupId, String artifactId) {

	getLog().info("Resolving " + groupId + ":" + artifactId);

	for (Iterator<Artifact> iterator = pluginArtifacts.iterator(); iterator.hasNext();) {
		Artifact artifact = (Artifact) iterator.next();

		if (artifact.getGroupId().equals(groupId) && artifact.getArtifactId().equals(artifactId)) {
			return artifact;
		}
	}

	getLog().error(String.format("Failed to locate %s:%s", groupId, artifactId));
	getLog().error("This probably means that you didn't specify it as a dependency in the pom.xml file");

	throw new RuntimeException(String.format("Failed to locate %s:%s", groupId, artifactId));
}

Unpacking JSDoc

As all jar files are zip files, we can simply write a zip extraction routine to unpack it.

ZipFile zipFile = new ZipFile(artifact.getFile(), ZipFile.OPEN_READ);
Enumeration zipFileEntries = zipFile.entries();

while (zipFileEntries.hasMoreElements()) {
	ZipEntry entry = (ZipEntry) zipFileEntries.nextElement();

	// Construct the new name
	String currentName = entry.getName();
	File destFile = new File(destinationDirectory, currentName);

	if (entry.isDirectory()) {
		// If we are a directory, create it.
		destFile.mkdirs();
	} else {
		// If we're a file, unzip it.
		BufferedInputStream is = new BufferedInputStream(zipFile.getInputStream(entry));
		int currentByte;

		// establish buffer for writing file
		byte data[] = new byte[BUFFER];

		// write the current file to disk
		FileOutputStream fos = new FileOutputStream(destFile);
		BufferedOutputStream dest = new BufferedOutputStream(fos, BUFFER);

		// read and write until last byte is encountered
		while ((currentByte = is.read(data, 0, BUFFER)) != -1) {
			dest.write(data, 0, currentByte);
		}
		dest.flush();
		dest.close();
		is.close();
	}
}

Configure JSDoc

At this point we’re back in the drudgery of maven configuration. Since we’d like to keep our configurations relatively separate (in a <jsdoc> sub tag in the mojo configuration), I’ve created a separate JSDocOptions class that can accept all of our options. I’m not going to bother copying it all here as there’s quite a bit of code, but you can see the full source code here.

Running JSDoc via Rhino

Lastly, we have to execute JSDoc, which is done via Rhino. This, again, is fairly straightforward.

public void run(File inputDirectory, File outputDirectory, JSDocOptions options)
	throws JSDocRunnerException
{
	// Build the string arguments.
	String[] args = options.buildArguments(jsDocRoot, inputDirectory, outputDirectory);

	// Run the javascript engine.
	getLog().info("Building JSDoc...");

	// Create our logging streams
	MojoLoggerOutputStream errorStream = new MojoLoggerOutputStream(LogLevel.ERR);
	Main.setErr(new PrintStream(errorStream));

	MojoLoggerOutputStream outputStream = new MojoLoggerOutputStream(LogLevel.WARN);
	Main.setOut(new PrintStream(outputStream));

	Main.main(args);
	getLog().info("Complete");

}

In the enterprise, however, different concerns start to take over. The project you’re working on might be dependent on an internal library built by another team, which is subsequently dependent on yet another library, and so on and so forth. As those libraries are incrementally updated, managing dependencies becomes a headache. Furthermore, the true power of javascript compilers like Google Closure are realized when all of the code is available at compile time. In fact, both the Simple and Advanced optimization modes require it, as it teaches Closure which code isn’t used and may thus be discarded.

Maven already has a very mature dependency resolution mechanism built into it, which is backed by a large public repository of common libraries. Javascript is still underrepresented in this arena, true, yet hopefully this plugin will eventually remedy that situation.

Choosing Scope

The maven dependency system requires a scope for each individual dependency to determine when it is needed in the build cycle. This is quite handy- you don’t for instance, want to have all the JUnit libraries be part of your final project compile, but you do want them available during the testing phase.

Similarly, Google’s closure compiler can process an external file (dependency) in two ways: Directly, immediately compiled into the final delivery source, and externally, files which are assumed to be self-contained and included in the final product via a different script tag. These two types of dependencies map rather nicely to Maven’s “compile” and “runtime” scope, however compiling a javascript file into a library causes complexity: If two libraries have the same compiled-in dependency, with different versions, perhaps even with different optimization levels, I run the risk of version and feature conflicts.

As a result, all of our dependencies will be treated as externals.

Resolving a dependency graph

The first step to building dependency resolution into my plugin requires constructing the dependency graph. Maven makes this (relatively) easy.

private DependencyNode getDependencyGraph(Artifact rootArtifact)
        throws DependencyResolverException {
        try {
                Dependency rootDependency = new Dependency(rootArtifact, "compile");
                CollectRequest collectRequest = new CollectRequest(rootDependency,projectRepos);

                // Collect all the nodes
                CollectResult collectResult = repoSystem.collectDependencies(repoSession, collectRequest);
                return collectResult.getRoot();
        } catch (DependencyCollectionException e) {
                throw new DependencyResolverException("Cannot build project dependency graph", e);
        }
}

Filtering dependencies by scope and extension

Now that I have a graph of dependency relationships, I should now visit each node and only collect those nodes that match our required scopes. Since I’ll also use this extension for resolving jsunit, envjs or others, it behooves me to abstract it.

public List<Artifact> resolve(String scope, String extension)
                throws DependencyResolverException {

        getLog().debug("Resolving dependencies: [scope:" + scope + "] [extension:"  + extension + "]");
        // Construct the dependency tree of our project.
        Artifact rootArtifact = new DefaultArtifact(project.getGroupId(),
                project.getArtifactId(), project.getPackaging(),
                project.getVersion());
        DependencyNode rootNode = this.getDependencyGraph(rootArtifact);

        // Gather dependency nodes in post order
        PostorderNodeListGenerator postOrderVisitor = new PostorderNodeListGenerator();

        // Filter out the root node.
        DependencyVisitor visitor = new FilteringDependencyVisitor(
                postOrderVisitor, new PatternExclusionsDependencyFilter(
                        rootArtifact.toString()));

        // If a scope is configured, add a scope filter.
        if (null != scope) {
                visitor = new FilteringDependencyVisitor(visitor,
                                new ScopeDependencyFilter(scope));
        }

        // If a type is configured, add a pattern exclusion filter
        if (null != extension) {
                String patternFilter = "*:*:" + extension + ":*";
                visitor = new FilteringDependencyVisitor(visitor,
                                new PatternInclusionsDependencyFilter(patternFilter));
        }

        // Run the collection.
        rootNode.accept(visitor);
        return postOrderVisitor.getArtifacts(true);
}

Resolving dependencies

As it turns out, maven dependencies may, or may not, be resolved. In practice this means that the system won’t bother to download the file until it’s actually needed, so we have to do it manually. The new Aether Dependency API in Maven3 means that artifacts are immutable, so we have to make a copy of each.

        List<Artifact> unresolvedArtifacts = postOrderVisitor.getArtifacts(true);
        List<Artifact> resolvedArtifacts = new ArrayList<Artifact>();

        for (Iterator<Artifact> iterator = unresolvedArtifacts.iterator(); iterator.hasNext();) {
                Artifact artifact = iterator.next();
                ArtifactRequest artifactRequest = new ArtifactRequest(artifact,projectRepos, null);
                ArtifactResult artifactResult = repoSystem.resolveArtifact(repoSession, artifactRequest);
                getLog().debug(" + " + artifactResult.getArtifact().toString());
                resolvedArtifacts.add(artifactResult.getArtifact());
        }
        return resolvedArtifacts;

Including dependencies in our compiler

With a list of resolved dependency artifacts in hand, I can now include them in the compile method from the last post.

        // Generate any externals that we need.
        List<JSSourceFile> externs = new ArrayList<JSSourceFile>();
        getLog().info("Resolving External Includes...");
        externs.addAll(resolveDependencies("compile","js"));

        // Generate the list of source files to include.
        List<JSSourceFile> source = new ArrayList<JSSourceFile>();
        getLog().info("Resolving Compile Includes...");
        source.addAll(generateJavascriptSourceList());

And there we are! We are now resolving dependencies from other javascript libraries that live in your, or someone else’s, maven repository.

This post is one in a series where I slowly assemble a Maven workflow for large javascript projects. If you came here via google, I recommend starting at the beginning: Designing a Javascript Maven Plugin. Alternatively, you can just go directly to the js-maven project on github.

Since there’s no sense in rebuilding something that already exists, I decided to start with google’s excellent closure compiler as a baseline, and simply write a maven wrapper around it. There’s nothing inherently wrong with the YUI Compressor; It’s quite a nice compressor. In the light of supporting more use cases, however, I feel that a compiler with more optimization options would be a better choice, especially since all of those options are individually configurable.

However before I wrote the plugin, there are a few things I had to take into consideration:

1. Developers should be able to debug while developing. This means that the compiled code needs to be human readable.
2. Optimization may impact code function, so the compiled code should be optimized.
3. Once packaged, the code should be minified.

In practice, this means two compiler passes over the source code. The first is to perform code optimizations, yet provide a human readable source file for debugging (in jetty, for instance). The second is to minify, but not optimize, shortly before the asset is packaged. This suggests the following steps for my Javascript Library lifecycle.

compile

net.krotscheck:js-maven-plugin:optimize-js-lib

prepare-package

net.krotscheck:js-maven-plugin:minify-js-lib

Given that with Google Closure two steps are practically identical, most of the functionality will be abstracted. This means I’ll effectively be running the compiler twice, not a problem unless a browser decides to throw errors on whitespace usage.

The Compiler Plugin

There are three steps to compiling using Closure. First we need to gather all of our source files, then we need to configure the compiler, and then we’ll run the compiler and output our source. There is a fourth step- gathering dependencies, which I’ll cover in a subsequent post. None of these steps are especially difficult. Here’s step one, finding all of our source code.

/**
 * Location of the source directory.
 * 
 * @parameter expression="${project.build.sourceDirectory}"
 * @required
 */
protected File sourceDirectory;

/**
 * This method scans the configured source directory of the Mojo and returns all
 * javascript documents, filtering by extension.
 */
protected List<JSSourceFile> generateJavascriptSourceList() {
    ArrayList<JSSourceFile> sourceList = new ArrayList<JSSourceFile>();

    String[] extensions = { "js" };
    getLog().debug("Discovering Source Files");

    Collection<File> sourceFiles = FileUtils.listFiles(sourceDirectory, extensions, true);

    for (Iterator<File> iterator = sourceFiles.iterator(); iterator.hasNext();) {
         File file = (File) iterator.next();

        sourceList.add(JSSourceFile.fromFile(file));

        getLog().debug(" + " + file.getAbsolutePath());
    }

    return sourceList;
}

Here’s step two, writing our compiler configuration. Note that I consciously made the choice to reduce the complexity of what my users can alter for the sake of illustration; This is primarily done

Overall Philosophy

First and foremost, the toolset must be independent of the code that is written. We simply cannot have a compiler that will only work for JQuery, or a testing harness that will only work if the test artifacts are composited via Rake.

Furthermore, I would like to adhere to Java conventions as much as possible, by which I mean JSDoc, JUnit-style unit tests and so forth. Java is syntactically very close to Javascript and Java’s strong prevalence in the enterprise space will reduce engineer friction.

The project artifacts will be packaged in as close to a native file type as possible. This becomes tricky: For something like a Javascript Library, a simple minified .js file will do. For a full web application with images, media, html and more this will be trickier as the nature of the server will define one packaging type over another: Jetty/Tomcat will prefer a .jar file, Apache will serve up an uncompressed archive, and so forth.

When possible, we’re going to take advantage of the latest and greatest: CSS compilers, for instance.

Why choose maven?

Maven is an obvious choice for various reasons. Firstly, it enjoys broad IDE integration. Secondly, it has an extremely powerful plugin framework that allows a user to use entire groups of plugins or focus on only the ones they really need. Thirdly, its dependency resolution mechanism is very powerful and very portable, which makes your builds extremely easy to bring to other platforms. Fourthly, it is open source and well supported by the community. Lastly, it enjoys broad support among continuous integration frameworks. All of these together make it a no-brainer to use as the core engine for our javascript toolset.

What workflow steps are needed?

Since maven defines a specific artifact lifecycle, we should start there and decide what we need our plugin to do. After starting to write this for a little bit however I realized that trying to declare it all up front is a significant undertaking, and should be split up by broader concepts:

1. Compilation
2. Optimization
3. Unit Testing
4. Functional Testing
5. Packaging and Publishing
6. Dependency Resolution
7. Debug Runtime
8. Headless Runtime
9. PMD/Linting
10. Documentation
11. Reporting

Should we create an Archetype?

The short answer: Yes. The long answer: Archetypes are absolutely critical to drive adoption, examples and acceptance, and are a very useful speed-of-workflow tool. Given the many different potential framework projects out there however, we’re going to have to create many of these; One for JQuery, one for Mootools, one for Backbone… you get the idea. So how about we worry about that once we get more pieces of the compiler in place.

Where will the source live?

I’m glad you asked! I’ll be hosting the project on GitHub. Please feel free to contribute!

Where will the maven repository be?

This is as yet undecided. For now I recommend you clone the project and install it locally. Once there’s enough functionality on the project to warrant a full point release, we’ll revisit this.

Speed and Scalability

If you’re working on smaller projects with no notable load, “popular” languages such as Ruby, PHP and Python are great; After all, they are optimized for developer productivity rather than runtime performance, and in 99% of all cases this is fine. This is the main reason they’re so popular in the startup scene, as they enable extremely rapid feature development as a business evolves to find its place in the world.

At some point, however, a designed system must perform at scale, and as most detailed examinations such as this one show, not all languages are created equal. Delivering software at that level in a language that has a poor performance profile changes the discussion entirely: If your system chokes, you lose business transactions, customer confidence, and reporting data, all of which translates into money. In short, the argument stops being about the salary of one or two additional engineers, and more about the reliability and maintainability of your codebase.

Not only have years of optimization made it a very reliable and performant platform, the religious arguments about What Is The Best Tooling™ out there have been had and are mostly over, with configuration winning out over convention every time. The IDE’s support it, Continuous Integration Environments support it, Unit Testing frameworks exist and are very mature, and even though the code itself is extremely verbose, shitty Java will still run faster than shitty Ruby. Mind you, the study in the post linked above was done several years ago, and I’m quite certain that the various languages have improved since, however given the lack of community trumpeting about oh-look-we-finally-beat-Java, I’m going to take that post as mostly-still-accurate.

B2C vs. B2B

The second big shift that happens at scale is a shift from a consumer-based business to a service-based business. Don’t get me wrong: Consumers are important, however onboarding more consumers is a linear function, and usually not a very steep one. Onboarding businesses to your platform, however, is an entirely different beast, as each new partnership could bring orders of magnitude of extra load to your system. Is this a provisioning problem? Yes, yet with it come a whole new set of problems: Will you need to provide authentication integration with their corporate LDAP system? Will you have to Whitelabel your service? Will you need to provide API support? A dedicated and/or isolated data cluster?

To be fair, these are language-agnostic architectural problems, ones which encourage a clear separation of UI and API layer, forcing all business logic into the latter. Websites in this system are simply UI clients and serve no purpose other than making the API human-friendly (not to be discounted- UX is super important).

Now that the UI is simply a facade, does it really make sense to render it on a server before sending it back to a client? Let me illustrate with an example:

Consider a website written in PHP that consumes an API.

1. I visit this website
2. The Application Server makes an API call
3. The API returns the data
4. Application Server Renders the data.
5. Browser renders the HTML
6. I get my html

Now consider a website written mostly in Javascript that consumes an API:

1. I visit this website
2. Browser calls the API
3. The API returns the data
4. Browser renders the HTML

See the difference? In the former case, you’ve got two times as many network transactions (added points of failure), and the additional cost of maintaining an application server. In the latter case, you can host the files on a glorified hard drive (S3 for instance) and are talking to the API directly.

But Javascript Sucks!

It really doesn’t: Javascript is an amazing, powerful language that is hamstrung by browsers, an outdated standards body, and a lack of a unified toolset.

Thankfully, browsers are starting to come around (Chrome at the lead) and implementation difference are starting to be eroded. Most of the javascript libraries out there (such as JQuery) don’t seem to have caught up to this fact yet, and are still rooted in the philosophy that they can only work for what works everywhere – no worries, they’ll evolve soon enough if their communities will let them.

The current arguments between the WhatWG and the W3C are obvious to anyone in our industry, and different business philosophies between browser vendors make sites like caniuse.com an unfortunate necessity. Add to that the never-ending political maneuvering in the ECMAScript standardization process, and javascript will forever be a bastard child of 5 different parents each telling it to follow a different career. Having said that, Google has successfully used Chrome as a strategic tool that established a de-facto standard, forcing other vendors to catch up.

Javascript tooling is still in its infancy, and many tools out there have not yet grown beyond themselves. Take, for instance, a unit testing framework like QUnit that is sadly dependent on JQuery, or a functional testing framework like Lebowski which is inexorably tied to Ruby and Sproutcore. Furthermore, many frameworks are differentiated by philosophical differences (take QUnit vs Jasmine for instance) which muddies the water even more. Lastly, even with a plethora of tools, nobody has managed to wrap it all into one single, cohesive whole that combines Formatting, PMD/Linting, Unit Testing, Functional Testing, Documentation and Optimization.

However… the tools are (mostly) all there, individually. JSDoc has become a de-facto standard. Google’s Closure compiler is mostly platform agnostic, drawing most of its cues from JSDoc. Jasmine could be your one-size-fits-all Unit Testing framework (assuming you like behavioral testing), and JSTD is a powerful testing framework that can be used for either unit or functional testing (It’d be even more powerful if the various browser runtime engines could be run headlessly like Mozilla’s Rhino). All it takes is for some enterprising individual to put them all together.

When releasing a new version of an AIR application that makes use of SQLite, it’s often necessary to upgrade the schema for that database as well. While taking a Hail Mary approach to the problem and just deleting the old database may work for some, it’s not an elegant option and will ensure that you can never persist data between versions. Instead, creating a way for your application to gracefully migrate its own database to the most recent version will ensure that your local data is not compromised, providing a smooth and seamless experience for the end user.

The Concept

We know that a database is the accumulation of all the CREATE, UPDATE and DELETE statements that have come before it. This means it may be easily represented and reconstructed by an ordered sequence of SQL files. It then becomes our task to manage which SQL files have already been executed in a given application version, and to execute (in order) those files which have not.

To accomplish this, we do the following:

1. We create a migration table within your database in which we store which scripts have been executed.
2. We check each script against this table before we run it.

There are other optimizations we can perform, however for this case we’re going to keep the idea simple.

Part 1: The Migration Class

The Migration class is a simple value container that contains your SQL Script as well as a Unique ID. Both of these are derivatives, since we want to give options on how to include the SQL file, and we don’t want to make our users have to think too much about how to set up a migration.

package com.fancybrandname.core.db
{
        import com.adobe.crypto.MD5;
        import com.fancybrandname.core.utils.LogUtil;

        import flash.data.SQLConnection;
        import flash.data.SQLStatement;
        import flash.errors.IllegalOperationError;

        import mx.logging.ILogger;

        /**
         * A specific database migration instance. It should contain both a version
         * and an embedded SQL source file that will be executed against the database.
         *
         * @author Michael Krotscheck
         */
        public class Migration
        {
                /**
                 * Logger
                 */
                private static const LOG : ILogger = LogUtil.getLogger( Migration );

                /**
                 * The SQL Source to use for this migration.
                 */
                private var _source : *;

                /**
                 * The SQL Statement extracted from the SQL Source object.
                 */
                private var _sqlStatement : String;

                /**
                 * This is the unique version key we use to identify this particular migration.
                 */
                private var _versionKey : String;

                /**
                 * The SQL Source to use for this migration.
                 */
                public function get source () : *
                {
                        return _source;
                }

                /**
                 * @private
                 */
                public function set source ( value : * ) : void
                {
                        _source = value;

                        // Here we attempt to extract the SQL statement from the passed object. If 
                        // the object is a Class (as with the @Embed directive), we instantiate and convert it.
                        // If it's anything else we try to invoke the toString method, and throw an error if we
                        // can't find it.
                        if ( _source is Class )
                        {
                                _sqlStatement = ( new _source() ).toString();
                        }
                        else
                        {
                                try
                                {
                                        _sqlStatement = _source.toString();
                                }
                                catch ( e : Error )
                                {
                                        throw new IllegalOperationError( 'Unrecognized type for SQL Migration. Please use Embeds or Strings' );
                                }
                        }

                        // Now we generate a unique ID from this string.
                        // You could request this key manually so that you don't have a dependency
                        // on the adobe crypto library, but I prefer doing it this way.
                        _versionKey = MD5.hash( sqlStatement );
                }

                /**
                 * This is the unique version key we use to identify this particular migration.
                 *
                 * @read-only
                 */
                public function get versionKey () : String
                {
                        return _versionKey;
                }

                /**
                 * This is the unique version key we use to identify this particular migration.
                 *
                 * @read-only
                 */
                public function get sqlStatement () : String
                {
                        return _sqlStatement;
                }

                /**
                 * Constructor.
                 */
                public function Migration ()
                {
                }
        }
}

Step 2: The Migration Manager

Our migration manager does the heavy lifting for this class, by checking the database for the last applied migration key and only applying those keys that come after it. It assumes several things. Firstly, that the migrations are in order of execution. Secondly, that the SqlConnection instance passed to it is a synchronous, not asynchronous connection. This method would definitely work for asynchronous connections, however you’d have to adjust the class to iterate using eventListeners. I leave this as an exercise to the reader.

package com.fancybrandname.core.db
{
	import flash.data.SQLConnection;
	import flash.data.SQLResult;
	import flash.data.SQLStatement;
	import flash.errors.IllegalOperationError;
	import flash.errors.SQLError;
	
	/**
	 * This metadata sets the default property for child nodes used in MXML. This
	 * makes MXML markup a lot easier to understand.
	 */
	[DefaultProperty( "migrations" )]
	/**
	 * A simple class that assists in managing multiple SQL files that may need
	 * to be run against a locally stored database. It makes the assumption
	 * that the migrations must be executed in the order in which they are provided,
	 * and that the database starts "clean" and untouched.
	 *
	 * @author Michael Krotscheck
	 */
	public class MigrationManager
	{
		
		/**
		 * The SQL Connection to use to connect to the database and check for migration.
		 */
		public var sqlConnection : SQLConnection;
		
		/**
		 * The migrations to run against the database. These must be in order of execution.
		 */
		public var migrations : Vector.<Migration> = new Vector.<Migration>();
		
		/**
		 * The name of the table within the database to store the migrations in.
		 */
		public var tableName : String = 'migration';
		
		/**
		 * Constructor
		 */
		public function MigrationManager ( sqlConnection : SQLConnection = null )
		{
			this.sqlConnection = sqlConnection;
		}
		
		/**
		 * This method runs the database migrations.
		 */
		public function migrate () : void
		{
			// Can we migrate?
			if ( !sqlConnection )
			{
				throw new IllegalOperationError( 'No SQLConnection provided' );
				return;
			}
			
			try
			{
				// Make sure the migration table exists.
				createMigrationTable();
				
				// Get the last version key applied to the database.
				var lastVersionKey : String = getLastVersionKey();
				
				// Iterate through our collection and execute every script AFTER the version key we found.
				var len : int = migrations.length;
				
				// Switch to let us know whether the last version key was found.
				// If the last version key is empty, apply all of them.
				var lastKeyFound : Boolean = lastVersionKey == '' ? true : false;
				
				for ( var i : int = 0; i < len; i++ )
				{
					var currentMigration : Migration = migrations[ i ];
					
					if ( lastKeyFound )
					{
						apply( currentMigration );
					}
					else if ( currentMigration.versionKey == lastVersionKey )
					{
						lastKeyFound = true;
					}
				}
			}
			catch ( e : SQLError )
			{
				throw( e );
			}
		}
		
		/**
		 * This method creates the migration table if it doesn't exist yet.
		 */
		private function createMigrationTable () : void
		{
			var sql : String = 'CREATE TABLE IF NOT EXISTS ' + tableName + ' (version varchar(32) NOT NULL PRIMARY KEY, applied_on timestamp NOT NULL);';
			
			var statement : SQLStatement = new SQLStatement();
			statement.sqlConnection = sqlConnection;
			statement.text = sql;
			statement.execute();
		}
		
		/**
		 * This method gets the last version key recorded in the database.
		 */
		private function getLastVersionKey () : String
		{
			var statement : SQLStatement = new SQLStatement();
			statement.text = 'SELECT version FROM ' + tableName + ' ORDER BY applied_on DESC LIMIT 0,1';
			statement.sqlConnection = sqlConnection;
			statement.execute();
			
			var sqlResult : SQLResult = statement.getResult();
			
			if ( sqlResult == null || !sqlResult.data || sqlResult.data.length == 0 )
			{
				// No migrations found.
				return '';
			}
			else
			{
				// We found one, return it.
				return sqlResult.data[ 0 ].version;
			}
		}
		
		/**
		 * This method applies the database migration to the database passed to this function.
		 * Please note that this version of the class only works with Synchronous SQLConnections.
		 */
		private function apply ( migration : Migration ) : void
		{
			// Apply the migration
			var updateStatement : SQLStatement = new SQLStatement();
			updateStatement.text = migration.sqlStatement;
			updateStatement.sqlConnection = sqlConnection;
			updateStatement.execute();
			
			// Update the version key
			var versionStatement : SQLStatement = new SQLStatement();
			versionStatement.text = 'INSERT INTO ' + tableName + ' (version, applied_on) VALUES ( :version , :timestamp )';
			versionStatement.parameters[ ':version' ] = migration.versionKey;
			versionStatement.parameters[ ':timestamp' ] = ( new Date() ).getTime();
			versionStatement.sqlConnection = sqlConnection;
			versionStatement.execute();
		}
	}
}

Step 3: Usage

Finally it’s time to use our class. As you can see the MXML markup is pretty straightforwar, and usage in ActionScript is similarly easy. Note that I’m using both @Embed directives and raw text, and pay particular attention to the embed mime-type. Without it, this doesn’t really work.

<s:Application 
	xmlns:fx="http://ns.adobe.com/mxml/2009"
	xmlns:parsley="http://www.spicefactory.org/parsley"
	xmlns:s="library://ns.adobe.com/flex/spark"
	xmlns:db="com.fancybrandname.core.db.*"
	>
	<fx:Script>
		<![CDATA[
			override protected function initializationComplete():void
			{
				super.initializationComplete();
				
				var dbFile :File = File.applicationStorageDirectory.resolvePath('myDb.db');
				var connection :SQLConnection = new SQLConnection();
				connection.open( dbFile );
				
				migrationManager.sqlConnection = connection;
				migrationManager.migrate();
			}
		]]>
	</fx:Script>

	<fx:Declarations>
		<db:MigrationManager id="migrationManager" tableName="migrations">
			<db:Migration source="@Embed(source='/sql/CreateSomeTable.sql',mimeType='application/octet-stream')"/>
			<db:Migration source="DROP TABLE IF EXISTS someTable;"/>
			<db:Migration source="@Embed(source='/sql/CreateSomeOtherTable.sql',mimeType='application/octet-stream')"/>
		</db:MigrationManager>
	</fx:Declarations>
</s:Application>

A discussion about OAuth and OpenID

Strictly speaking, Facebook supports OAuth, not OpenID. OAuth is a way for your application to act on behalf of someone else on another side, while OpenId exists solely for you to use the other website as an authorization authority. The difference is subtle, however telling that Facebook has explicitly stated that it does not want to be an authorization authority. In practice, however, the two standards are interchangeable, and OAuth works pretty well as a way to authenticate a user.

How Facebook Auth Actually Works

Here’s the flow in four easy steps:

1. The user clicks on a “Login to Facebook” link on your server, which redirects them to another page on your server that handles the authentication.
2. Your Facebook Auth page puts all the parameters for your authentication, such as your app ID and scope, into a URL and sends the user to Facebook via that URL.
3. Once Facebook returns the user (presumably authenticated) to your server, you can use the parameters sent via the URL to request an authentication token from Facebook. This is done via curl or some other server-to-server communication by calling the graph API.
4. You use this authentication token to access the user’s information on Facebook.

Step 1: Get all the data you need

To properly authenticate with Facebook, you need four pieces of data. The first two are your application id and your application secret, both of which are available on your developer application page.

A sample Facebook application page

The second two pieces of data are specific to your implementation. These are the redirect URI, which is used to tell Facebook where to send the user once they are done authorizing your application, and the permission scope, which you use to tell Facebook what permissions you want to request from the user. This latter one actually warrants some more documentation, which Facebook has graciously provided here. Be careful: Users can get really suspicious if you ask for too much data.

Step 2: Redirect your user to Facebook.

With this data, you can redirect your user to Facebook. Facebook will then work some magic and ask the user whether they want to grant your application access to their profile. Don’t forget to urlencode that Redirect URI.

$loginUri = "https://graph.facebook.com/oauth/authorize?client_id={$appId}&redirect_uri={$redirectUri}&scope={$scope}";
header('Location: ' . $loginUri);

Step 3: Request an Auth Token

Assuming that the user authorizes your application, Facebook will return them to your redirect URI with the “code” parameter in the URL. You can use this parameter to request an authorization token from Facebook. In this case I’m using the Zend Request handler to simplify things a little.

$client = new Zend_Http_Client( "https://graph.facebook.com/oauth/access_token" );
$client->setParameterGet('client_id', $appId);
$client->setParameterGet('client_secret', $secret);
$client->setParameterGet('code', $code);
$client->setParameterGet('redirect_uri', $redirectUri);

$result = $client->request('GET');
$params = array();
parse_str($result->getBody(), $params);
$token = $params['access_token'];

Step 4: Read the user’s profile

At this point, you have an auth token that grants you access to read the user’s profile information in accordance to the permissions they have granted you. These permissions are completely blind- you don’t have to additionally specify what you want to access – the requests will simply return the information to which you have access.

$client = new Zend_Http_Client( "https://graph.facebook.com/me" );
$client->setParameterGet('client_id', $appId);
$client->setParameterGet('access_token', $token);
$result = $client->request('GET');
$user = json_decode($result->getBody());

Zend_Auth_Adapter_Facebook

For those of you who would rather not take the above code and wrap it into your own Auth Adapter, I’ve gone ahead and done all that work for you. Below you will find a sample Zend Controller, as well as a pre-baked Auth Adapter. If you come across any major security problems in it, I’d love to know, since I use this adapter myself .

class Zend_Auth_Adapter_Facebook implements Zend_Auth_Adapter_Interface
{
    /**
     * The Authentication URI, used to bounce the user to the facebook redirect uri.
     * 
     * @var string
     */
    const AUTH_URI = 'https://graph.facebook.com/oauth/authorize?client_id=%s&redirect_uri=%s';
    
    /**
     * The token URI, used to retrieve the OAuth Token.
     * 
     * @var string
     */
    const TOKEN_URI = 'https://graph.facebook.com/oauth/access_token';
    
    
    /**
     * The user URI, used to retrieve information about the user.
     * 
     * @var string
     */
    const USER_URI = 'https://graph.facebook.com/me';
    
    /**
     * The application ID
     *
     * @var string
     */
    private $_appId = null;

    /**
     * The application secret
     *
     * @var string
     */
    private $_secret = null;

    /**
     * The authentication scope (advanced options) requested
     *
     * @var string
     */
    private $_scope = null;

    /**
     * The redirect uri
     *
     * @var string
     */
    private $_redirectUri = null;

    /**
     * Constructor
     *
     * @param string $appId the application ID
     * @param string $secret the application secret
     * @param string $scope the application scope
     * @param string $redirectUri the URI to redirect the user to after successful authentication
     */
    public function __construct($appId, $secret, $redirectUri, $scope)
    {
        $this->_appId = $appId;
        $this->_secret = $secret;
        $this->_scope = $scope;
        $this->_redirectUri   = $redirectUri;
    }

    /**
     * Sets the value to be used as the application ID
     *
     * @param  string $appId The application ID
     * @return Zend_Auth_Adapter_Facebook Provides a fluent interface
     */
    public function setAppId($appId)
    {
        $this->_appId = $id;
        return $this;
    }

    /**
     * Sets the value to be used as the application secret
     *
     * @param  string $secret The application secret
     * @return Zend_Auth_Adapter_Facebook Provides a fluent interface
     */
    public function setSecret($secret)
    {
        $this->_secret = $secret;
        return $this;
    }

    /**
     * Sets the value to be used as the application scope (array())
     *
     * @param  string $scope The application scope
     * @return Zend_Auth_Adapter_Facebook Provides a fluent interface
     */
    public function setApplicationScope($scope)
    {
        $this->_scope = $scope;
        return $this;
    }

    /**
     * Sets the redirect uri after successful authentication
     *
     * @param  string $redirectUri The redirect URI
     * @return Zend_Auth_Adapter_Facebook Provides a fluent interface
     */
    public function setRedirectUri($redirectUri)
    {
        $this->_redirectUri = $redirectUri;
        return $this;
    }


    /**
     * Authenticates the user against facebook
     * Defined by Zend_Auth_Adapter_Interface.
     *
     * @throws Zend_Auth_Adapter_Exception If answering the authentication query is impossible
     * @return Zend_Auth_Result
     */
    public function authenticate()
    {
    	// Get the request object.
    	$frontController = Zend_Controller_Front::getInstance();
    	$request = $frontController->getRequest();
    	
    	// First check to see wether we're processing a redirect response.
    	$code = $request->getParam('code');
    	
    	if ( empty ($code ) )
    	{
	    	// Create the initial redirect
	    	$loginUri = sprintf(Zend_Auth_Adapter_Facebook::AUTH_URI , $this->_appId, $this->_redirectUri);
	 		
	    	if ( !empty($this->_scope) )
	    	{
	    		$loginUri .= "&scope=" . $this->_scope;
	    	}
	    	
	    	header('Location: ' . $loginUri );
    	}
    	else
    	{
    		// Looks like we have a code. Let's get ourselves an access token
	    	$client = new Zend_Http_Client( Zend_Auth_Adapter_Facebook::TOKEN_URI );
	    	$client->setParameterGet('client_id', $this->_appId);
	    	$client->setParameterGet('client_secret', $this->_secret);
	    	$client->setParameterGet('code', $code);
	    	$client->setParameterGet('redirect_uri', $this->_redirectUri);
	    	
	    	$result = $client->request('GET');
	    	$params = array();
	    	parse_str($result->getBody(), $params);
	    	
	    	// REtrieve the user info
	    	$client = new Zend_Http_Client(Zend_Auth_Adapter_Facebook::USER_URI );
	    	$client->setParameterGet('client_id', $this->_appId);
	    	$client->setParameterGet('access_token', $params['access_token']);
	    	$result = $client->request('GET');
	    	$user = json_decode($result->getBody());
	    	
            return new Zend_Auth_Result( Zend_Auth_Result::SUCCESS, $user->id, array('user'=>$user, 'token'=>$params['access_token']) );
    	}
    	
        return new Zend_Auth_Result( Zend_Auth_Result::FAILURE, null, 'Error while attempting to redirect.' );
    }
}

/**
 * Sample Facebook Auth Controller.
 * 
 * @author Michael Krotscheck
 */
class FacebookauthController extends Zend_Controller_Action
{
	/**
	 * Application default action
	 */
	public function indexAction ()
	{
		$appId = 'YOUR_APP_ID';
		$secret = 'YOUR_APP_SECRET';
		$redirectUri = 'http://path-to-this-controller-and-action';
		$scope = 'YOUR_COMMA_SEPARATED_APPLICATION_SCOPE';
		
		// Create the authentication adapter.
		$adapter = new Zend_Auth_Adapter_Facebook( $appId, $secret, $redirectUri, $scope );
		
		// Get an authenticator instance
		$auth = Zend_Auth::getInstance();
		
		// This call will automatically redirect to facebook with the passed parameters.
		$result = $auth->authenticate($adapter);
		
		if ( $result->isValid() )
		{
			// Get the messages
			$messages = $result->getMessages();
			
			// Get the user object from the returned messages.
			$fbUser = $messages['user'];
			
			var_dump($fbUser);
		}
	}
}

This particular email was written to demystify the difference (as far as I’m concerned) of all the different parts of a client application. However rather than a heavy discussion on methods and algorithms, what I present here are actually the higher level concepts that govern the structure of an application. I tried to order them in a fairly logical fashion, starting at the “front” of the application (what you see) and moving towards the “back” (the bits that the user should never see).

But first, I feel it is important to understand the difference between business logic and view logic:

• Business logic manages data and enforces business rules. It cleans, saves, reads, compares, and makes sure that the data models are properly updated. It is also important to make the distinction between server-side business logic and client business logic. That which lives on the server is usually focused more on business rules, while that which lives in the client usually cares more about server interaction and data manipulation.
• View logic manages how data is displayed. It manages state, formatters, strings and view indexes, and doesn’t really care about how that data got to where it is, it only cares about how it should be displayed within this particular view.

Having said that, here are the major components of a client application. Caveat, this might not mean much to you Javascript guys.

Skin

A skin acts to describe the containers, colors and graphics that a control or view use. It can change its appearance based on a skin state (not to be confused with view state), and can refer to styles set by the component which it is skinning. It should not have any business or data logic whatsoever.

Control

A Control is the lowest level of functional components which comprise an application. These are our buttons, labels, data grids, view containers and so forth, and they are characterized by the fact that the data they display is not specialized, nor do they contain any real internal business logic at all. They know how to interact with a generic type and dispatch events when a particular action occurs.

View

A view is a collection of controls, containers, formatters, skins and subviews, all connected via a presentation model. It acts to collect and arrange elements rather than figuring out what each piece is supposed to do. As such, Views should contain little to no code at all, and should be managed by states and properties.

Item Renderer

An Item renderer is a very specialized kind of view, which deals with the display of a single piece of data in a collection. As a result, it is the only view which should be dependent on an external piece of data – one that is injected into a property of that ItemRenderer from a parent (the data property). Item renderers may contain Presentation MOdels to help them manage user gestures, but rarely make use of a data model as this is already provided.

Presentation Model

It is the job of the presentation model to act as a mediator between the view and the rest of the application. This does not mean that it should manage data, nor necessarily contain it. Instead, its job is to expose all the methods and data which are being used by the View, which includes models (bindable), states, actions which describe user methods and (in some cases) validators.

Data Model

The data model is a dumb data container. It should contain little-to-no logic on its own, and instead allow the tasks to clean, sort and manipulate anything that is assigned to the model. Thinking of it differently: The Data Model is the authoritative source of any data used in the application. All data starts here and ends here. Views get their data from the Data Model via binding. Tasks retrieve model instances. Presentation models make data available by exposing a public instance of a data model.

Task

Tasks are where our “business” logic resides, in the most generic and granular way possible. As an example, the act of loading a user might require reading the user object, retrieving their preferences, and initializing the application locale. Rather than try to handle this all in one task, it is better to use a SequenceTask or ParalellTask to collect the three different actions. Why? Because your preferences screen might need to reload user preferences after they’ve been saved, but you don’t want to refresh the entire user.

Tasks, much like presentation models, are able to collect any data and utilities they need to achieve what they need to achieve, however when they are done they need to let go of those items and dispose of themselves properly. The important thing to note here is that any business logic that can be put into the service layer should live in the service layer; We don’t want to expose the guts of our business rules to the world, and servers are much easier to protect from questionable data manipulation.

Delegate

A delegate is our service proxy, and acts as a channel back and forth from the database. It allows us access to the business logic that lives on the server in a reliable and consistent way. In most cases, each delegate method will have one task that wraps it and makes sure that the data is properly cleaned and presented.

Utility

Utilities are classes that provide common data manipulation routines that are global to all aspects of the application. A good utility, for instance, would be a method that handles date conversions from GMT to Local and back. A less desirable utility method would be one that formats a piece of data for a specific view, as this should be handled within the view itself.

Libraries

Libraries are the catchall for everything that was left out, and it includes pieces of highly specialized logic that don’t really fit neatly elsewhere. Good examples of this are video encoding libraries, classes that manage encryption, filesystem manipulation and other tasks like that.

VO

A VO, or Value Object (also known as DO/Data Object) is the raw data which we manipulate. It describes a particular Domain Object and acts as a package that we pass from method to model to view. They only contain data related to that same object, and should not contain any formatting logic and only limited validation logic (is-not-zero checks and so forth). Formatting should be handled by the view, validation should be handled by tasks or utilities.

How about this: Am I less of a person because I work in Flash?

I haven’t really (well, sortof) weighted in on the Flash vs. HTML5 debate yet, mostly because the main posters pro and con are both more technically qualified, have a stronger social following, and/or have more backing from marketers. It is the futility of the debate itself that interests me, both from a very personal perspective and from the perspective of an internet veteran.

The nature of the debate that I observe from the comfort of my Laptop is the following:

• Camp A: Here’s a bunch of reasons why Flash sucks!
• Camp B: Nuh-uh! Here’s a list of reasons why that’s not the case!

As you probably realize yourself, this argument structure is essentially religious, and can be replayed whenever two people have different opinions and are not willing to reconcile. It’s certainly not restricted to the technology space (Choice vs. Life anyone?), and the futility of entering into such an argument is well known to anyone who’s ever been involved in a flame war.

Now take this Adobe/Apple debate and pose it to our society (full of technology-advocates, evangelists and gurus), and you’ll soon come to realize that Adobe cannot win this argument, not given its current strategy. This is for two reasons:

1. You cannot win a flamewar from a defensive position.
2. You cannot win a flamewar with reason.

Adobe’s Flash Team are doing an admirable job at defending against everything that’s coming out of Apple, the Javascript community, and the standards purists. Unfortunately by the time they get to debunking these statements the damage has been done, and no matter how quickly they respond they will never get the same media penetration that Apple will. Why? Because people don’t like to be told they’re wrong, and anyone who listens to a flamewar long enough will start to tune out. Just ask Fox News- they make a living on this – and there’s no way you can reach an unreceptive audience no matter how good your arguments are.

Secondly, any aggressor can very easily cherry-pick its arguments to attack the defender on weak points, and thus invalidate their entire argument simply because one point wasn’t well researched. While the overall flash platform is a strong contender on the web, you’ll notice that the argument is focused on a few key shortcomings – performance, accessibility, ‘open-ness’ and the like – in which HTML5 has strength. By defending specifically against these weak points, Adobe is then empowering critics to further choose sub-points where they have strength, and through this cycle the argument is diminished and diminished until at the end all we remember is that Adobe was trying to defend itself and their critics never ran out of anything to point to and say: “Hey you suck”.

Lastly, as I have seen in several cases, arguments have started go get personal, and as soon as you enter that arena you can invalidate someone’s argument simply by pointing out their own shortcomings. To use myself as an example, you can invalidate anything I have to say about Flash and HTML5 by pointing out that I’m not a real CS major, that I haven’t remained at a job for more than 4 years, or that I go so far as to claim that there are people more qualified to talk about this than I in the very first paragraph in this post. My experience and job title doesn’t matter – as soon as you say “Oh, you don’t know what you’re talking about, you’re not a CS Major” you’ve got me completely discredited.

But what bothers me the most is the first concession which the Adobe Community had to make, and that is that their pool of developers draws from the design community and are subsequently not the best. Now, every technology has a wide range of developer competence, yet with Flash it’s becoming a banner cry: “Flash Developers suck”. Your technology choice does not define how skilled you are, and yet it’s becoming pretty clear that those of us who choose Actionscript and Flash are seen as incompetent, less than human, and not worth listening to because we’re blind and ignorant fanboys who don’t understand what they’re missing with [Insert Language Here].

This last point is perhaps the most damaging, because it’s eroding Adobe’s hard-won community. Do you like feeling like a shitty developer? Do you want to be the pariah of the web? Do you like being told that you are the scum of the earth? No, and I don’t either, and if like myself you’re simply trying to make a living, chances are you’re seriously considering learning something else to make sure you remain employable.

So the real question is: Will rational minds prevail? I doubt it.

1- They don’t think of themselves as rock stars.

Arrogance is perhaps a key requirement in being an entrepreneur, but overconfidence will drain your cash pool faster than hookers and blow.

2- They have a proven track record of multiple shipped products.

You don’t want a hotshot kid out of school, you want a seasoned professional, preferably one who knows how to write applications for the industry you’re trying to reach.

3- They care more about frameworks than plumbing.

Unless you’re trying to design a complex new mathematical algorithm (in which case you should probably be partnering with a university research lab), you want someone who can grasp a system rather than a method. If this guy ends up in deep technical discussions about the optimal way of implementing a sort, you’ve got the wrong guy.

4- They’re not willing to work for free

Risk management and strategic thinking is key to long-term project viability. If you have someone willing to work for equity, they’re willing to take risks with your payment processing gateway just as easily as they’re taking a risk on you.

5- They believe in development process and best practices to speed up their work.

The last thing you want is someone who’s trying to reinvent the wheel. Mind you, this also likely means that the first two weeks or so of development you’ll see a lot of development support tools get set up and used before code actually starts, but that’ll give you time to get your documentation in order.

6- They have a positive attitude.

If someone bitches, they’re looking to blame themselves. Instead, you want them to identify their concern as a problem they can solve.

7- They get uncomfortable when you ask about their social life.

’cause, well, currently it’s still socially odd to prefer coding on a saturday night.

8- You don’t want Alphabet/Acronym soup in their technical skills.

Lots of languages means little depth in each, and depth = speed. Pick a serverside language (PHP, .Net, Ruby, etc), pick a database (MySQL, SQLServer, Postgres, etc), and pick a frontend (Flex, Mootools, JQuery, etc). Focus on that. If a dev has only a few languages this does not mean they’re stupid- it means they know how to focus.

9- They’re involved in the community.

Speaking, attending, whatever, you need to make sure their technical skills don’t stagnate, and that they’re willing to accept ideas from outside.

10- You respect them

Respect means you are willing to listen when they tell you you’re full of it, and that’s key in a partnership. You’re not looking for a monkey you can put in a corner who can bang out some code- you’re looking for a partner who’ll act as a technical sounding board.

So now I have this question: What makes for a rockstar business partner?

Cool, huhn? Security concerns aside (Believe me, I am never giving anything on facebook my credit card information), this isn’t exactly new- pushing product information into the Facebook stream was what the original Facebook Beacon was all about, and that was shut down via a class action lawsuit because it published user sales data without user approval. Additionally, pushing rich media applications into the Facebook stream is not new- anyone who’s viewed a youtube video in their Facebook stream knows how seamless that can be. What’s interesting though is that Resource has overcome the legal concerns with two changes: First, by giving users control of what to share when, and secondly by actually launching a full commerce application into something that people check every day.

If your initial reaction is disgust (“What? Another way for people to sell us their stuff? Blegh”) then you and I are pretty much on the same page, however don’t be blinded by other creative uses of this. For instance, if you want to buy someone a Christmas present, wouldn’t it be nice if you saw their wishlist items in the stream? What about gaming- if a friend of yours is playing some kind of a live flash mini game… wouldn’t you want to join them immediately? There are legitimate uses for this that don’t turn your stomach, so I figured I’d write a quick overview on how to put it together.

So how did they do that?

If you already have an application you want to run inside the Facebook news stream, then the process of getting it shareable is extremely simple, and is easily accessible to anyone who knows a little bit about flash, HTML metadata and the facebook platform. You have to perform the following tasks, most of which are trivial unless you are trying to do anything covered by a regulatory body (like accepting credit card information). For that you have to have a secure and federally accredited server, and that’s way outside of the scope of this article.

Step 1: Add the “Share on Facebook” link on the page in question.

The first thing you need to do is give your users the ability to actually share your page. This can be as easy as including a particularly formatted link in your product page or as complicated as including FBML in your site’s header and namespace. Note that the share URL can include URL parameters that will customize the content of the page, and should be pointed at the hosted URL of your flash application- this is crucial for step 2.

<a name="fb_share" type="button_count" href="http://www.facebook.com/sharer.php?u=[url to share]&t=[title of content]">Share</a><script src="http://static.ak.fbcdn.net/connect.php/js/FB.Share" type="text/javascript"></script>

Step 2: Add the correct meta tags to the page you want to share.

When a user clicks on the above link, it actually triggers the Facebook Sharer script to scrape the provided URL for metadata that tells it how to share this page. All of this data is contained in the metadata tags of a page, and you can read the extensive documentation here, however the important piece you’re looking for is how to share multimedia content. If you’ll read the documentation carefully, you’ll notice that while all references talk about video, in reality this share functionality allows you to display any flash content in the Facebook stream simply by replacing video_url with the URL to your flash SWF. This is still restricted to user action of course- nobody will see a flash app launched immediately, they’ll still see the icon and title as with any Youtube Video, and the application won’t launch until the user actually clicks on the icon.

<meta name="title" content="video_title" />
<meta name="description" content="video_description" />
<link rel="image_src" href="video_screenshot_image_src url" />
<link rel="video_src" href="video_src url"/>
<meta name="video_height" content="video_height" />
<meta name="video_width" content="video_width" />
<meta name="video_type" content="application/x-shockwave-flash" />

EDITORIALIZING: What worries me on this is that Facebook’s documentation is very clearly targeted at video sharing, and that this may be a violation of their intent of the sharer script. In short, what Resource is publishing as an innovation to social commerce is little more than a hack bolted into a loophole. Even so, I don’t believe Facebook will try to blacklist retailer sites to put this genie back in its bottle, because it both encourages use of their platform while also opening the gates to more legitimate uses. The ability to see that someone is, say, playing a game right now and your ability to join them is only a single click away puts an entire new spin on live online gaming, especially with the recent release of Adobe Collaboration Services, but I digress…

Step 3: Get your domain whitelisted by Facebook

If you paid especially close attention to the documentation linked above, you’ll also note that multimedia sharing won’t work if your domain is not whitelisted by Facebook. This is to protect Facebook from people who might want to distribute illegal content that would get them in trouble (licensed movies for instance), but also gives Facebook ultimate white and blacklist control over any activity they don’t want subverting their functionality. The process is actually extremely simple: Click this link, fill out the form, and wait for them to get back to you. Last time I did it it took less than 24 hours, but that was for a major retail site; your experience might vary.

That’s it. Enjoy!

We all know that students have no money- many of us have been there and scraped by on ramen and coffee often for weeks on end, and now we are all, to a greater or lesser extent, burdened by the cost of our education as we have leveraged part of our future to gain the success we have now. It’s part of our environment. It’s who we are, it’s what we expect, it’s part of our lives, and it will be part of our childs’ lives as they grow up. We don’t think much about it- it’s simply there.

If you’ve watched this video from TED on how schools kill creativity, you know that there are some salient points to be made about how our primary and secondary educational system encourages a certain type of talent – science and maths – while actively discouraging the humanities and arts. While I would love to see more study on the topic, I want to extrapolate on Sir Ken Robinson’s argument and apply it to the space of postsecondary education.

Consider: If you were a student entering college today, and you were told that you’re going to walk out with an average of $23,000 in debt ($33,000 for private schools, according to this study [PDF] ), would you choose a career in engineering or in the fine arts? To quote one student, borrowing so much only makes sense “as long as you’re going to the school for a career that will pay enough”, so it certainly seems like we are actively discouraging pursuit of “cultural” careers in the arts and humanities.

Is this a problem? Good question, but it certainly shapes our national identity. If we want to be known as a country of technical innovators, then this system is perfectly fine as it fills our homes with highly technical thinkers. If in contrast we want to be known as a cultural mecca, it’s the worst thing ever as we are actively discouraging our students from pursuing fields that contribute to that.

But that’s not the point I’m trying to make here, it is simply the path to how I got to this blog post. See, I see this as a problem, and problems need solutions, so I want to take a business-side approach to this issue and ponder on any market opportunities that might exist. After all, if federal programs are unable to meet this country’s educational needs, then private business will have to pick up the slack, and they’re only going to do it if there’s money to be made.

Some Numbers

To take some numbers from this study [PDF], I’ve extracted the following table:

Table 1: Total Student Aid and Nonfederal Loans Used to Finance Postsecondary Education Expenses in Constant (2008) Dollars (in Millions), 1998-99 to 2008-09

What we can easily extract from this is the individual line items which add load to students. The loans are easy, and I am also including Work Study and Institutional Grants. The former, because it’s activity that actively detracts from a student’s attention to their studies (by having a job) and the latter for reasons I discuss below. Given that, I’ve generated the following table:

Table 2: Total unmet need covered by students in Constant (2008) Dollars (in Millions), 1998-99 to 2008-09

Do you see what I see? I see a $128 billion dollar demand for a solution, but demand is only useful if a supply may be found that may be profitably offered to that market. Thankfully, the actual act of marketing any solution you can come up with is easy- between high school career counselors and college students’ naturally viral nature you effectively have a captive audience, assuming your solution is a good one. But unless you’re the treasury or the federal bank you can’t exactly pull $128 billion dollars and slap it on the table, and even if you were I doubt the taxpayers would be willing to pay for that (though we do love our bombers).

Universities as Contributors to the Problem

On of the real culprits in this whole situation is Universities themselves. College Tuition has been increasing at an average rate of 8% a year, while the median household income is hardly keeping up, especially if you take inflation into account. My own Alma Mater for instance (Carnegie Mellon) posted an annual tuition rate of $40,000 dollars this year, which from what I can tell is the highest in the nation and a significant uptick from the $18,000 I was paying in 2000. So how exactly can universities justify this increase?

Fact is, those tuition numbers are simply not real, because universities are skimming the market. Simply put, all the financial data a student is asked to report when they apply for financial aid year after year is used to calculate exactly how much the student and their family can afford. Once they have this number, they will add as many student loans as the student is eligible for (maxxed out of course), and might even add some private loans to it as well. Once they have that number, they will add something called a “Need based grant”, “Merit based grant” or “institutional grant” (or something similar) as a line item to make up the difference because they can’t charge you any more.

This makes identifying a good solution to student debt a far more difficult problem, because as soon as you find a business solution to meet the above noted demand, universities can simply respond by adding another line item to their financial aid calculations and the problem is right back where it started.

Or… is it?

Here’s where things get a little devious, and I apologize for suspending my personal ethics to even suggest this. Consider: If you provide a method for students to raise money against their debt, and universities in response raise their tuition to capture that value so that the debt doesn’t actually go away… then they are increasing the size of the market. That’s right, simply by helping students find a way to meet their debt obligations, the behavior of the other actors in the market environment will ensure that your market size grows. And while this certainly doesn’t provide a real solution to the actual problem, it should have any finance guy’s salivary glands working in overtime.

If, of course, you can meet the demand. In a new and successful way.

Let me explain: I have an Idea- and I think it’s a pretty big idea- but as I’ve moved forward with the tech implementation I’m starting to realize that my biggest hurdle is that I’m not a designer (no matter how much I might think I am). It’s not a question of skill- well, ok, in some cases it is – but more a question of speed: I can sling code with the best of them, but I can’t for the sake of me figure out how to make something easy use and/or pretty without beating my head against the wall for days on end. I don’t have the practice, skills or experience to do that quickly, so I end up finding more and more excuses to refine the technology than really focusing on what matters: the User experience.

As such, the skill set should complement my own- I can handle the implementation, you should be able to handle the look, feel, and experience. This goes beyond simple design, too- we’re going to have to collaborate on feature priorities, but as for the how to and now what that would be left largely in your hands. This means you’ll have to have a strong work ethic, and be willing and able to receive and reciprocate mutual encouragement- if one of us slips, we both fall, so in the truest sense of the word I’m looking for a Partner.

I don’t care about location- we can do meetings by Skype, phone or whatever as long as you are recommended and vetted by someone I know and trust. In fact, if you’re located in Pittsburgh that would be pretty awesome, as the startup community there with InnovationWorks and the Alpha Lab are incredibly supportive of getting endeavors of the ground. That’s hardly a requirement though, so don’t let that turn you off.

There are two real requirements though: 1- You’re a seasoned professional (feel free to define that as you see fit), and 2- You have a highly developed sense of ethics. You’ll understand why that second one is important as soon as you get a whiff of the idea.

What do you get? Well, first of all you get to work with a seasoned code nerd who appreciates (as you saw above) good UI and UX, and really wants to make it part of the core of the team. I can’t exactly pay you- No startup at this stage of the game can, but you’ll be happy to know that I’m not getting paid either (In fact, I’m currently paying for the servers). As for equity- well, partner is partner, and I’m willing to go even-split, but that might include more people down the road as the business side of the idea starts to become more prominent.

So… uh… what’s the idea? There are a lot of people out there who know what it is already- I’m certainly not unwilling to share, but I’m not about to blog about it. I firmly believe that there’s no such thing as a new idea on the internet, and the only way you can differentiate yourself is to do it better. Having said that, a current google search doesn’t turn up with much, so I figure it’s worth a shot.

Interested? Know someone who might be interested? Well then drop me a line, send me some visual samples, get a mutual friend to introduce you and I’ll fill you in on the actual scope of the idea.

Personally, I find this ironically appropriate because I recently left an employer whom I absolutely loved in favor of a new opportunity, but I digress…

Now that we’ve been chosen (muchas gracias), we’ve entered into a tacit agreement with the organizers that we will help them make this years’ SxSW as awesome as humanly possible. No pressure, right? Well, they’ve also thrown us a bit of a curve ball in that we’ve been asked to lead a discussion (Known as a Core Conversation) rather than holding a joint presentation. This means no A/V equipment, and the content coming from the discourse rather than the presentation.

After thinking about it for a bit, I really feel this is a much better format for the topic. Consider: Careers are very personal things, and for either of us to claim that we have all the answers is just a mite bit arrogant. So rather than proclaim to be career management experts (which we’re not), we’re just two people with applicable history who are willing to seek out guidance from others with similar experiences.

Yet it’s also extremely important to frame what the topic is NOT. This is not a way for you to get out of a stifling company, nor a way for you to get your unappreciative boss fired. This is especially not a forum where you can bitch about lazy coworkers who are holding you back. This is a forum where we discuss how to frame your career goals, evaluate your current situation for opportunities, and move from there.

Which brings me to you, our readers, as we’re looking for feedback and information to help us lay the foundations. We’re looking for any kind of feedback- experiences, questions, data- everything from real experiences about why you made a career based move to silly topics about your lucky teddy bear. Spit it out, we’d love to know it.

Flash to iPhone!

Yes, you’ve probably heard it everywhere- the next version of Flash will be able to compile for the iPhone. Chances are you’ve already learned all the details, so here’s a recap:

1. Flash will be able to compile natively to the iPhone. This is a bytecode compiler, not a version of the AIR runtime or anything like that (Well, it might be, but Adobe’s not telling us what’s up).
2. Right Now the support for mobile features is limited. For instance you can write to the camera, but you can’t read from the camera. So AR isn’t an option… yet.
3. Since it’s pretty limited from a hardware standpoint, it will require mastery of a new application and component framework called “Slider” (Introduced today).
4. As Adobe works on a roughly 18 month release cycle, you can expect the new version of Flash CS5 to be out around April/May, with betas available in the next month or three (Though they might accelerate it to coincide with the Catalyst/Builder release slated for Q1).

Editorializing

The interesting thing to note here isn’t that it’s “ooh ooh, iPhone”, but that it’s “ooh ooh, native bits!”. Adobe’s shown that Actionscript isn’t restricted to the flash player anymore, which could mean one of two things: 1- It’s Saberrattling directed at Microsoft and Sun to take their hands off the web space, else they’ll have competition in the Desktop space, 2- They’re trying to push AS as a legitimate development environment, or 3- Nothing, really, it’s just cool tech.

Flash Player 10.1

Secondly, Adobe announced a new point release of the Flash Player this morning. There are lots of features, but perhaps the largest is that this player has been designed to work on 29 out of 30 mobile platforms (guess which one’s not in the list). Yes- that’s the full flash player available to smartphones. Additionally, here are some more takeaways:

Resource Usage

Mobile devices simply don’t have the computing power of desktop or laptop computers, so one of the major hurdles (and criticisms, if you listen to Apple and Google) is that the Flash Player puts a pretty significant strain on your system. While no amount of player improvement will save you from badly written software, it’s nice to see Adobe put some money into improving their own platform, and we’ll see exactly what the actual impact is.

Multitouch Support

Multitouch screens are everywhere now, mostly thanks to Apple, and for the Flash player to be competitive on a mobile platform it must accept input from a multitouch screen. This now opens the door to multitouch web experiences, which also makes Flash a competitive development platform for interactive walls and the such.

Streaming Enhancements

I doubt you’ll notice the actual impact of this, other than you won’t see as many interruptions while watching youtube… on your phone… while driving. No, really- the streaming enhancements are there to smooth out video playback in an environment where the video player is rapidly moving across different network access points (like cellular towers). You as a mobile user probably don’t realize how often your phone switches from one tower to the next because it’s handled so seamlessly, however it really did become obvious while watching video. If this enhancement really does what Adobe says it will, then live television on mobile devices will actually become technically feasible… while moving.

Editorializing

Personally I’m going to take all the marketing promises with a grain of salt, however whether or not these features perform is secondary to the nature of the features themeselves: This is probably the first time I’ve seen such an obvious example of how the desktop environment is no longer the feature driver, but is rather subject to how mobile devices are evolving. In order to bring Flash to the mobile platform, Adobe had to make some significant updates to the Flash Player, and desktop users stand to benefit greatly from them.

Mosaic

I highly suspect that this is the rebranding of the Adobe Genesis project which I blogged about some time ago. In short, it’s a way to create a series of interactive pods that can intercommunicate, but which in and of themselves have their own independent functionality. These pods can then be arranged on a page as you see fit (to, say, build out an HR application) and these pages can be managed (either at the page or pod level) by a workflow.

This is probably one of the strongest moves I’ve seen recently into the Enterprise software space (Well, other than the Oracle-Sun acquisition), and means that we might finally see a crack in the armor of monolithic ERP systems.

Editorializing

99.9% of you won’t care about this. To the remaining .1% who are operating with enterprise-scale budgets and are sick of hiring arrogant SAP consultants, this is a watershed product. Also, go follow Dan McWeeney- he’s one of the Devs on the project.

AIR 2.0

The announcement of AIR 2.0 addresses most of the major complaints people have had with the AIR platform. These are as follows:

1. Native Installer support
   This sounds like you can create an installer which is not dependent on having the AIR runtime installed. There wasn’t too much detail on this, but I’m hopeful.
2. Memory Improvements
   Tweetdeck won’t kill your machine anymore (Well, it still will, but it’ll do less of that- expect a 50% improvement).
3. Launching Native Applications
   It will be possible to launch already installed applications from your AIR application, so if, for instance, you’re building some kind of a file browser, you can now open those files in the application they were meant to be opened in.
4. USB Recognition
   We saw a demo of reading files from a USB drive. While this may mean that only device recognition is possible (hey, there’s some kind of new USB device, but I don’t know what it does), if this is fully built out we can see hardware device UI’s managed completely via the flash platform.

Editorializing

Honestly, this (plus the snippets pane in Flash which I don’t cover here) pretty much spell the end of Director. Good riddance.

Flash CS5

There are a ton of new features available in the upcoming Flash CS5, and as I’ve talked about the iPhone above, I’ll highlight the other ones here.

• Real Text Support
  This version of “Real Text Support” (Wasn’t there a buzzword like this a few years back?) means left to right, ligatures, underline, strikethrough, paragraph flow and the consolidation of all text embedding.
• XFL as the base file format
  The base file format of a Flash file is moving to XML, so anyone can create/author flash files, and we won’t step on each other’s toes when they’re committed to a versioning system. Personally, I wonder how long it’s going to take Microsoft to write a XAML conversion script.

Editorializing

About bloody time. Also, I should note that we just upgraded to CS4 two weeks ago, so I don’t expect to have official corporate blessing to use any of this stuff for another two years.

LiveCycle Collaboration Services

This is what I spent most of my day on yesterday, and will be spending most of my day on on Wednesday as well. In short, it is a way to create live multiuser experiences easily on the flash platform. If that doesn’t make sense to you, think of your favorite webconferencing solution (WebEx, Acrobat Connect, etc) and realize that now you can put this into your branded flash application. Oh yeah, and that works on mobile, too.

To be honest, this is really hard to describe unless you have a working sample, but imagine for a moment that you’re on the ESPN site doing your draft picks for fantasy football. Normally, you’d have to take turns, and it would take forever for emails to work their way around and so fort. Well, if this site was LCCS enabled you would see all the other players in your league interacting real time (no really, you’ll see their mice moving around), and could hand the baton around as to who gets to pick next.

Now, this has been around for a while known first as Cocomo and AFCS- but the big change now is that they’ve announced pricing. The best place to look is here, though I expect it’ll be officially posted somewhere else as well. Something to note- their blog doesn’t appear to be linked from the labs site, so here’s the link to the LCCS Blog.

Editorializing

It’s going to take a while to figure out what neat things people will do with this. I already have a few ideas, but I’m hardly the only mensa-grade genius thinking of these things, so we’re bound to see some really cool stuff.

That’s about it for now. Today is going to be a really long day, so I doubt I’ll be able to post again, but you’ll definitely get an update from me on Wednesday-ish. If I missed anything, don’t hesitate to comment.

There are, in essence, three different ways to consume media on the internet. This is regardless of what kind it is- a solution that would work for sound will also work for video and vice-versa. While technical implementation may limit the formats you can broadcast, those choices are usually made well after the project requirements have been set.

Progressive Download

The first is Progressive Download. This is the easiest and the one you’re most likely to encounter in your day to day life, and will also be the cheapest for you to implement. In essence, you copy a video file and a player out onto a normal web server, and when a user loads the page with the player, that player will start to download the video and begin playing it as soon as it has enough to ensure a continuous stream.

The advantages are many. First, it’s easy to do- dozens of prepackaged players exist, and encoders are pretty easy to find as well. In some cases, you don’t even need a player- quicktime will play directly in your browser as long as you have the plugin. The downside is that your video is available for anyone and everyone to download and, presumably, rebroadcast on their own servers.

If you’re working on a viral campaign this is actually an advantage, but in most cases it’s probably not- who knows how some enterprising individual will mashup your video, right?

Server Based Streaming

The second method is server-based streaming. Rather than using a single web server, you’re now using two: A web server for your player, and a streaming server for your media. The user experience is practically identical- all changes happen under the hood as the user is only receiving the part of the media they’re currently watching. Once a particular second has been consumed, it’s discarded.

The advantages of this method are several: First, it’s a lot easier to detect how fast your client’s connection is, so you can provide them a smaller file that will still give them a good user experience. Secondly it is more secure- your user can’t really save the media without a third-party program, and those fail if you encrypt your stream. Thirdly, you can publish live media streams with this method- concerts, conventions, presentations and the like are now all accessible in real time.

Unfortunately this method isn’t exactly cheap… if done in house. It usually means a new server, server software that will cost thousands, and a developer who knows how to set up and maintain your server. To keep costs low you can contract with a media hosting company that already has the hardware and software set up. The free ones include Vimeo and Youtube, though they limit you to certain players and encryption is usually not available.

Peer to Peer Streaming

This method is (surprise surprise) very popular in the adult industry, but is also used for more common applications like Skype. The role of the server is cut out almost completely in this, as we instead broadcast media directly from one user to another.

The nice thing about this is that you can have a high-quality person-to-person interaction without paying an arm and a leg for bandwidth.

The disadvantages are largely experience related, since one of your users must act as the media publisher via a camera, microphone, or pre-downloaded file. That user will then be limited to how many people they can broadcast to simultaneously by how fast their internet connection is.

Strategies for Selection

Given the above, choosing a media streaming approach is relatively easy. The default is progressive download- if you don’t have a lot of media and don’t need anything encrypted or fancy, just go with that. If that’s not enough for you, decide whether you need a live feed: If not, use a streaming server.

After this things get a little trickier, because live media may be broadcast in many forms. The rule of thumb I use is as follows: If the number of consumers of a single media stream exceed the number of streams that can be provided at the highest bitrate given the internet connection, use a streaming server.

Some examples:

• The Democratic National Convention
  Single source of video, many users: Server Based Streaming
• YouTube
  Many sources of video, many users: Progressive download or Server Based Streaming (I recommend the latter based on scale).
• Pandora
  Many individual audio files, must be secured from copying: Streaming server
• Amazon.com Album Previews
  Many individual audio clips: Progressive download
• Customer service training video (internal)
  Lives on internal network, not live, single video: Progressive download.
• Internet Phone
  Thousands of sources, thousands of consumers: Peer to Peer.

I hope this guide was helpful. If you have any additional questions, don’t hesitate to put them in the comments.

The real challenge, however, is “Getting Something Out There” that you can build on. I don’t mean setting up a blog or a couple of static pages, I mean putting in place a scaffolding that you don’t have to replace in its entirety as your business concept matures. The optimal solution then seems to be to use an established software package that can be extended to suit your needs.

Easier said than done. Every CMS out there claims to be extendable, yet not all are created equal. Furthermore extensibility usually requires that you build within their own framework, which then locks you into a third party whom you don’t have control over.

This can be overcome by developing your business services independently, and create a loose integration between your application and your CMS. By doing this you’re suddenly free to proceed with your own plans without the added worry of being locked into a platform.

So why did I choose WordPress and Zend? Well, WordPress has an easily understood plugin structure as well as an active developer community, plus its plugins allow you to do pretty much anything your heart desires. Zend was chosen because it’s a professionally supported application framework with quite a few corporate backers, and it’s written in the same language as WordPress- PHP (Plus, it’s what I know- Added Bonus).

The rest of this post is going to get technical, so I hope those of you who aren’t as geeky as I don’t mind. In essence I describe how to accomplish a loose WordPress-to-Zend integration with all the benefits I described above.

Step 0: Assumptions

Before I begin, there are some assumptions I’m going to make.

1. You know how a Zend MVC application is structured.
2. Your Zend code base will be hosted on the same server as your WordPress install.
3. You are running application stacks on the same primary domain. (blog.fancybrandname.com and www.fancybrandname.com works)
4. Your Zend application will handle user authentication records. This is because you don’t necessarily want to be restricted to WordPress’ table structure.
5. Your application uses the MVC Templating System that comes with Zend.
6. The WordPress integration code will live in the plugins directory on the WordPress side and (with one notable exception) in the ~library/ directory on the Zend side.

Most importantly, please understand that this implementation is NOT for the faint of heart, and requires additional code on your part. I cannot easily make any assumptions about how user authentication is handled within your Zend application, nor what models or methods you have built to simplify object retrieval.

Step 1, Database: Create a linking table

The first fundamental requirement is that we need some way of linking the WordPress user table (usually named wp_users) to the user table in the zend application. Usually this is done via a linking table, that might look something like this:

CREATE TABLE `user_id_link_table` (
  `id_zend` bigint(20) unsigned NOT NULL,
  `id_wordpress` bigint(20) unsigned NOT NULL,
  KEY `id_zend ` (`id_zend `),
  KEY `id_wordpress ` (`id_wordpress `)
);

Step 2, Zend and WordPress: Configure the Cookie Domain

To make sure your authentication cookies are available across your two domains, you’ll need to make sure both WordPress and Zend are looking for the same cookie. The way to do this is to set a wildcard Cookie domain so it transfers from one domain to another. If you look through the various configuration files and session initialization methods, you might see entries like “www.yourdomain.com” or “blog.yourdomain.com” near a reference to a cookie domain. To make sure they transfer, replace all instances with “.yourdomain.com” (the period at the beginning is important). That should ensure that your cookies are portable.

Step 3, Zend: Setting up an integration controller

The first thing we need to do is make sure that your Zend Application is fully loaded. Since you might want to use view helpers in your page templates, this means that we actually have to set up a ‘dummy’ controller that is used for integration purposes only, but which doesn’t try to output anything. This is easily done:

<?php
/**
 * The Integration Controller.
 */
class IntegrationController extends Zend_Controller_Action
{
    /**
     * Index action. Sets up the entire framework but disables output.
     */
    public function indexAction()
    {
        $this->_helper->viewRenderer->setNoRender();
    }
}

Step 4, Zend: Extending the AutoLoader

The fourth step is that we need to extend the Zend AutoLoader, because otherwise it will get confused when WordPress tries to load its plugins. Since we don’t really know which plugins will be loaded ( and thus we can’t explicitly include them in our $PATH ), we’re simply going to restrict the Zend Autoloader to restrict its activities to certain namespaces.

This file is called ~library/Wordpress/Loader.php

<?php
require_once('Zend/Loader.php');

/**
 * The WordPress loader class is a quick filter that ensures only specific application
 * libraries are passed through to load handling.
 */
class WordPress_Loader extends Zend_Loader
{
    /**
     * Override of the loadClass method.
     *
     * @param string $class
     * @param string|array $dirs
     */
    public static function loadClass($class, $dirs = null)
    {
        $parts = split("_", $class );

        switch ( $parts[0] )
        {
            case 'Zend':
            case 'Wordpress':
            case 'YourNamespace':
                parent::loadClass($class, $dirs);
        }
    }

    /**
     * This handler has to be here for Zend_Loader invocation purposes
     *
     * @param class $class
     * @return string|boolean
     */
    public static function autoload($class)
    {
        try {
            self::loadClass($class);
            return $class;
        } catch (Exception $e) {
            return false;
        }
    }
}
?>

Once we’ve extended our AutoLoader, we now have to properly invoke it in our Zend Bootstrapper.

NOTE: You may have to adjust the following code somewhat so it fits in with your application. My own application has a Bootstrap Class within which this is a private method.

/**
 * Application Bootstrapper.
 */
class Bootstrap
{
    private function setAutoLoad()
    {
        require_once ( 'Zend/Loader.php' );
        // Notice that I'm still calling Zend_Loader, but I'm passing the new Classname.
        Zend_Loader::registerAutoload('Wordpress_Loader');
    }
} 

Step 5, Zend: Creating a Session Model

This fifth step is necessary if you’re going to delegate all authentication tasks to the Zend application rather than to WordPress itself. By treating our user sessions like a CRUD-based application, we can abstract it entirely into a Model rather than keeping the code within a Controller. By doing this we can invoke the method from anywhere, including a WordPress plugin.

NOTE: I’m putting this session class into the WordPress namespace, while it really should go into a namespace appropriate to your application.

<?php
/**
 * The session model wraps basic session creation and destruction methods
 * into one single interface. 
 */
class WordPress_Model_Session extends WordPress_Model_Abstract
{
    /**
     * Creates a new session (aka logs in a user)
     *
     * @param string $user
     * @param string $password
     * @return 
     */
    public function create ( $user, $password )
    {   
        // Get our authentication adapter and check credentials
        $adapter    =   $this->_getAuthAdapter( $user, $password );
        $auth       =   Zend_Auth::getInstance();
        $result     =   $auth->authenticate($adapter);

        if ( !$result->isValid() )
        {
            return false;
        }
        else
        {
            // We're authenticated! Add your own logic here.


            return true;
        }
    }

    /**
     * Destroys a session (aka logs out a user)
     */
    public function destroy ( )
    {
        Zend_Session::forgetMe();
        Zend_Auth::getInstance()->clearIdentity();
    }

    /**
     * Constructs an instance of the auth adapter for this model.
     *
     * @return Zend_Auth_Adapter_DbTable
     */
    protected function _getAuthAdapter( $login, $password )
    {
        // Put your authentication plugin loader code here.

        return $adapter;
    }
}

Step 4, Zend: Add an integration method to your Zend Bootstrapper

The last thing we need to do is create a method in our bootstrapper that lets us load the entire application without Zend trying to parse the URL into which it was loaded. To do this, we create our own HTTP Request instance with a URL that invokes the Controller and Action we created in step 3, thus effectively ‘fooling’ the FrontController into thinking it was invoked from somewhere else.

/**
 * Application Bootstrapper.
 */
class Bootstrap
{
    /**
     * Executes the application in a bootstrapped integration state.
     */
    public function integrate()
    {
        // Construct a 'Dummy' Url to use for our Request.
        $uri = sprintf ( 'http://%s/integration/index',$_SERVER['HTTP_HOST'] );
        // Create a new request object
        $request = new Zend_Controller_Request_Http( $uri );
        // Dispatch our FrontController
        $this->_frontController->dispatch( $request );
    }
}

At this point, we’re done with all the work we need to do on the Zend side of things. On to the WordPress Plugin!

Step 6, WordPress: Create a plugin

The sixth step is to make sure that your entire Zend Application is available to WordPress. This is a security risk- the instant someone discovers a vulnerability in WordPress they’ve got access to everything, so make sure you have a competent PHP developer who knows how to secure an application.

<?php
/*
Plugin Name: Zend Integration Plugin
Version: 1.0.0
Description: Allows WordPress to authenticate users against the a Zend Session Model
Author: Michael Krotscheck
Author URI: http://www.krotscheck.net/
*/

class ZendIntegrationPlugin
{
    /**
     * Constructor. Initializes this class.
     */
    function __construct()
    {

    }
}

// Load the plugin hooks, etc.
$zend_integration_plugin = new ZendIntegrationPlugin();

Step 7, WordPress: Load the Zend Framework

The next step is to load your Zend application. By creating a method that explicitly loads our Bootstrapper and then invoking the integration method we created in Step 3 above, we load all necessary classes and dependencies without them interfering with WordPress.

class ZendIntegrationPlugin
{
    function __construct()
    {
        // .... previous code ....
        $this->Wordpress_framework_init();
    }

    /**
     * Initialize the Zend framework for inclusion.
     */
    public function WordPress_framework_init()
    {
        // Import the Zend Bootstrapper. This path needs to be absolute.
        require_once ( '@APPLICATIONROOT@/bootstrap.php' );

        // Create a new Bootstrapper instance and invoke the integration method.
        $bootstrap = new Bootstrap ( );
        $bootstrap->integrate();
    }
}

Step 8, WordPress: Disable Unnecessary Functions

Since we’re delegating all session authentication tasks to your Zend application, we need to explicitly disable many of WordPress’ default functionality related to password and account management. We do this by using the application hooks created explicitly for that purpose.

<?php

class ZendIntegrationPlugin
{
    function __construct()
    {
        // ... previous code ...

        // Disable Lost Password, Retrieve Password, and Password Reset
        add_action('lost_password', array(&$this, 'disable_function'));
        add_action('retrieve_password', array(&$this, 'disable_function'));
        add_action('password_reset', array(&$this, 'disable_function'));

        // Remove Password Fields from the wordpress user profile.
        add_filter('show_password_fields', array(&$this, 'disable_password_fields'));
    }

    /**
     * Used to disable certain display elements, e.g. password
     * fields on profile screen.
     */ 
    function disable_password_fields($show_password_fields)
    {
        return false;
    }

    /*
     * Used to disable certain login functions, e.g. retrieving a
     * user's password.
     */
    function disable_function()
    {
        die('Disabled');
    }
}

Step 9, WordPress: Autoload the session

This is perhaps the most complex piece of the plugin, because we have to do three things: First, we have to detect whether the authentication states between your Zend application and WordPress match. If they don’t, we have to either create a wordpress session or destroy it. The tricky bit here is that WordPress requires use of its own user database, so we have to retrieve basic information from the Zend User tables and construct a WordPress user should it not already exit.

Unfortunately, I cannot say how your Zend application is built nor what models exist that would allow you to retrieve a user record. As such I’ve inserted pseudocode in the method below that describes what needs to happen rather than make guesses about your implementation.

<?php

class WordPressAuthenticationPlugin
{
    function __construct()
    {
        // ... previous code ...

        add_filter('plugins_loaded', array(&$this, 'auto_login'));
    }

    /**
     * This method runs after the plugins is loaded, and attempts to detect
     * an out-of-sync session.
     */
    public function auto_login()
    {
        $isZendAuthenticated = Zend_Auth::getInstance()->hasIdentity();
        $isWordpressAuthenticated = is_user_logged_in();

        // Check to see if we're logged out of Zend but still logged in to WordPress
        if ( !$isZendAuthenticated && $isWordpressAuthenticated )
        {
            // Log out of WordPress.
            wp_logout();
            wp_clearcookie();
            set_current_user(null);
        }

        // Check to see if we're logged in to Zend but not WordPress
        if ( $isZendAuthenticated && !$isWordpressAuthenticated )
        {
            // Retrieve the user record from Zend
            $yourUserObject = yourUserRetrievalMethod();
            $wordpress_user_id = yourWordpressIdRetrievalMethod($user);

            // Check for the wordpress user ID, create a new user if necessary.
            if ( $wordpress_user_id == NULL )
            {
                // Retrieve the user creation scripts.
                require_once(ABSPATH . WPINC . DIRECTORY_SEPARATOR . 'registration.php');

                // Create a user object, using the hashed password value (It matter doesn't what you use as long as it's unique)
                wp_create_user($yourUserObject->login, $yourUserObject->password, $yourUserObject->email);

                // Check for a successful insert
                $wordpress_user_id = username_exists($login);
                if ( !$user_id )
                {
                    die("Error creating user!");
                }
                else
                {
                    yourWordpressIdUpdateMethod($user, $user_id);
                }
            }

            // Now that we know we have an existing wordpress user record that matches our Zend Table,
            // try to create a wordpress session
            $wpUser = new WP_User($wordpress_user_id, $yourUserObject->login);
            $wpPassword = md5($yourUserObject->password);
            wp_login($yourUserObject->login, $wpPassword, true);
            wp_setcookie($yourUserObject->login, $wpPassword, true);
            wp_set_current_user($wpUser->ID, $yourUserObject->login);
            return;
        }
    }
}

Step 10, WordPress: Enable Login via WordPress

At this point we are maintaining the authenticated session across our applications, but we don’t yet have WordPress authenticating users against our Zend user table. As above, I can’t make assumptions about how your authentication is set up, but I can show you which application hooks to set up, leaving the rest of the logic for you to fill in.

<?php

class WordPressAuthenticationPlugin
{
    function __construct()
    {
        // ... previous code ...

        add_filter('check_password', array(&$this, 'check_password'), 10, 4);
    }

    /**
     * Override Check Password
     */
    public function check_password($check, $password, $hash, $user_id)
    {
        // Retrieve a user by the WordPress User ID. You can use any class in your Zend application.
        $user = findZendUserByWordpressId ( $user_id );

        // Check for a valid return data.
        if ( $user )
        {
            // Try to log in.
            $sessionModel = new WordPress_Model_Session();
            return $sessionModel->create( $user->login, $password );
        }

        return false;
    }
}

Step 11, WordPress: Enable Logout via WordPress

The very last vanity task to perform is to enable logging out via the WordPress buttons. Again we use an action handler, and in this case we explicitly call the Session destroy method we created in Step 5.

<?php

class WordPressAuthenticationPlugin
{
    function __construct()
    {
        // ... previous code ...

        add_action('wp_logout', array(&$this, 'logout'));
    }

    /**
     * Runs Logout routines against the Zend controller.
     */
    public function logout ()
    {
        $sessionModel = new WordPress_Model_Session();
        $sessionModel->destroy();
    }
}

And that’s it. With all these pieces in place your Zend application should now be integrated with your WordPress intall. Congratulations! Now your startup has a fully functional, plugin ready CMS without being tied to a commercial solution for the long term.

To begin with, this session starts where the 5 minute install stops. There are plenty of tutorials out there that will help you set up your own WordPress blog, so I’m not going to bother repeating them. Instead I’m going to start covering topics that you’ll run into when you want to have your WordPress install do more than what it was originally designed to do.

Since the topics covered are very technical in nature, I will also take the time to demystify some of them. In other words, if you’re already a developer in your own right you might not get much out of this presentation, as I will be covering some basic PHP syntax, server redirects as well as an overview of modifying DNS records.

On the other hand, if you are a blogger who’d like to have a good introduction, or are curious about how WordPress might fit into your corporate environment, this will be an excellent overview.

Section 1: One Install, Many Blogs

11:00AM-11:20AM

If you’re an avid blogger and/or maintain more than one WordPress blog, consolidating all of your blogs onto one single WordPress install can help with everything from plugin management to upgrades. Most plugins, however, naturally assume that they exist on a solitary install, so if you want to use something like Google XML Sitemaps there are some additional steps you need to take. As such, this first part will cover the following topics:

1. Writing a Dynamic Configuration File (PHP)
2. Request Redirects with mod_rewrite
3. Configuring plugins for multi-site use

Section 2: WordPress^μ

11:20AM-11:40AM

In many corporate environments it’s often optimal to manage multiple blogs through one single administrative interface, which is where WordPress^μ (Multi-User) comes into play. Installs such as these are often tricky, because they require a bit more technical expertise to get them set up properly. As such, I will be covering the following:

1. A brief feature overview of WordPress^μ
2. Installing WordPress^μ.
3. Redirecting for subfolders (http://www.yourdomain.com/blogname).
4. Redirecting for subdomains (http://blogname.yourdomain.com/ ).
5. Updating CNAME DNS records for subdomains.

If we have time at the end of the session I will open the floor for any additional questions you might have about installation challenges you might have faced. I can’t promise a comprehensive answer to all of them, but between myself and the rest of the room we should be able to get you pointed in the right direction.

Everyone on that list gets followed. Everyone else gets dropped.

Yes, there are caveats. If I’ve never met you before in my life there’s a good chance I’m not going to follow you anyway, for reasons you’ll see below. Also if we’ve had more than a cursory set of @changes, have emailed each other regularly or (even better) have hung out in person you’re automatically on the list.

The true power of human communication is interaction, discussion and argument. It is not doe eyed consumption of what the latest celebrity has said, nor is it short-burst updates in the hope of being profound. It’s not link propagation, marketing, spin, advertising, or a long list of messages that boil down to “OMG I’m # away from ### Followers, Pay Attention to MEE!”. Human communication and true discussion requires time, effort, and thought, and cannot be acquired via txt messages or 140 character snippets. Think paragraphs. Think books. Think libraries.

Yes, it requires effort. It requires we meet, or have an email exchange, or talk on the phone, or have some kind of meaningful exchange other than “@krotscheck omg that picture is so cute”. Once that social vibe and comfort is established then yes, casual methods of communication (like twitter) are great ways to maintain it over distance, but you can’t do that just because you listened to their presentation at some conference.

If you want me to follow you, you have to convince me to care, and no small “follow” button or automated bot is going to do that. If you want me to treat you like a human being, to really listen to what you have to say, then you really should reciprocate.

Hypocrite? Not really. Listen, I give people day-to-day updates because I assume that they’re interested in what’s going on in my life. I use twitter for banter, not for a meaningful conversation or professional exchanges. Banter, by its very nature, assumes a level of familiarity you can’t just get from a website, and if I don’t feel comfortable bantering with you then yes, you’re not going to get followed.