Olark is absolutely simple to integrate: a single snippet of JavaScript. But it offers a great deal of power: you can push a logged in user’s name and email address through the chat, and set their IP address, browser build, and other details as that user’s “status” when chatting. (You can even have the chat bot message you that information at the beginning of the session.)

The fun doesn’t end there: Olark allows you to actually redirect a user to a different URL, including external addresses, all while maintaining persistent chat. This is absolutely fantastic, as you can literally direct a user to the page they need while still helping them out. Olark reports what page they’re currently looking at, and their new co-browsing feature allows you to literally see what your users see, scroll the page for them, and circle certain elements.

This level of interaction is fantastic: it can help clinch a waffling pre-sale customer who has a small question but isn’t able to find an answer and doesn’t want to go through the trouble of filling out a contact form. Or it can assist with the on-boarding process: new users are the most likely to encounter experience-ruining burrs, problems, small barriers to entry that can be resolved with a simple chat.

The ability to transfer conversations, native Jabber/XMPP utilization (such that I can use Trillian for managing my chats), and a robust API round out the core features of a very compelling product. Olark is free for up to 20 conversations a month and one operator, but the clients we’ve signed up on Olark needed the Gold plan, since it’s the lowest plan that supports SSL.

Check out Olark for pre-sale potential customer engagement, and post-sale onboarding/getting started assistance. Reducing friction for new and potential users is the surest way to build a loyal following or make a sale.

Olark

Off and Away is a neat travel bidding site that lets you bid on travel deals for pennies. (The bids cost roughly a buck, though.) Curious at how their timer was put together, biz-partner Bob took a peek at their JavaScript. Somewhat surprised to find that they hadn’t minified it, he was even more amused by their credit card function, aptly named $.fn.creditcard_shizzle.

When writing and testing code, it’s really tempting to put in junk data or in-jokes or other fun bits. As a development company, we’ve banned that outright, even in development environments, because we’ve discovered that somehow, some way, our little joke will end up live, released to clients or their customers, or even worse, appear in big bold letters in the middle of a demo. Nothing quite matches the sheer terror and stomach-pit feeling as having “stupid mcassface” show up during a demo.

Clearly, Off and Away’s devs/founders have a sense of humor and since this is source code and not customer-facing, this isn’t really a big deal. It’s not even vulgar. But it’s amusing to stumble across these sort of gems, as long as they’re not in the middle of a demo. For more fun, search swear words on Google’s Code Search. You’ll find some exasperated comments, angry rants, and outright bitterness, to be sure. (Hell, even Microsoft’s done it.)

Off and Away

Google’s Plus release represents their first legitimate effort at a coherent social experience. Right out of the gate, they’ve got a few things incredibly right: amazing notifications unified throughout all Google products, good integration with Picasa and Android, Circles, Hangouts, data portability, and a feeling like this might be around for some time.

Now they need to focus on what’s necessary to make this a second nature, everyday product for people, like Facebook is now for most people.

Open Registrations/Invitations

If anyone can get scale right, it should be Google. Admittedly, scaling instantly in to the millions is a challenge for even the largest companies, and there’s surely a method to their madness here, but they need to be doing whatever they can to get this thing open to as many people as possible. They’re framing the current experience as a “Field Test”, but it’s difficult to test a social networking product if you can’t get your friends onto it. Early adopters are the type of user who will shift their more reluctant friends to a new system. They’re kneecapping their momentum with their limited invitations.

Figure Out Sparks

By far, the most confusing element of Plus is Sparks. It’s an interesting hodgepodge auto-aggregator of news and blog posts on individual topics (or “eccentric hobbies” as their video goes), but it’s presented in a bit of a sloppy way. Since it’s curated automatically, it’s not terribly great at it, which is a bit disappointing as well. Fortunately, Sparks is a nice-to-have within the Plus experience. Perhaps some integration with Reader would help make Sparks shine.

Make Huddles Amazing (Read: Copy Beluga)

I’ve got basically every single friend I speak with regularly on Beluga now. We use it to plan events, see what’s happening for the evening, and coordinate shared rides and the like. It’s a great tool. We also have fun with it. We share photos and links and such. And we can access it from our desktop if necessary. Huddles don’t currently let you access them from the Plus site itself, only from the mobile app. Since Plus isn’t available in the iPhone App Store yet, I can’t try to convert my friends to Huddles yet. And since Huddles don’t let us share photos or set Huddle photos, I don’t know if I’d want to yet. Location sharing is really useful too, and here Google has a definite leg up: it already shares location on posts… why not on huddle updates? Moreover, why not tie directly in to Latitude? Let me navigate right to a real-time-updating friend if I’m picking them up from someone, right from within our Huddle!

Import Profile Pics from… Somewhere!

Most of my connections/friends on Plus are faceless. Make adding a profile picture a required first step. It’s important to associate faces with names, but moreover, it’s WAY less usable to see a bunch of placeholder graphics throughout the product. Import from Gravatar, or, if you won’t violate TOS (heh), from Facebook directly. Either way, make it required, or constantly nag until it gets done.

Release a Stream Notifier or API

If you want us to engage, we need to know things are happening. Right now, it appears the only way to see new posts is to load up the Plus site or app and look at the Streams. Facebook and Twitter have apps or APIs that allow us to get pinged with updates as they happen. You’ll lose momentum and people will stop coming back to Plus if we can’t see what’s happening without having to call up the site manually every time.

Let Me Cross-Post Content Easily

Since Plus isn’t going to overtake Facebook, Twitter, or Linked In overnight, let me cross-post to those places with a click of a button. Better yet, blow everyone away and make it as easy as choosing a “Circle”. Add the Facebook “Circle” and the post auto-cross-posts there. Add the Twitter “Circle” and the shortened form is available for preview before it ends up there. By keeping up the walled garden, Google may be intentionally discouraging this sort of behavior, but this is what will trigger buy-in immediately and ease the transition. Social networks aren’t necessarily a zero-sum game, but two is likely very close to the limit for most.

What’s Next for Plus

Plus is off to a great start. Better than Buzz or Google Wave could ever hope for. It’s exciting, clean, original, and well-executed, with a lot of great features available right out of the gate, and some really innovative concepts. With a bit of polish and a bit more hand-holding, I think Google can convince people to begin using Plus as part of their daily interaction. But the elements needed to keep us checking in and coming back every day aren’t quite there yet. The notifications are a great start, but they only tell part of the story, keeping me informed only after I’ve already engaged. I need a reminder to check in on Plus and see that my friends are using it, and that’s sorely lacking right now.

Google also needs to integrate single-sign-on/Google Authentication with Plus, the way Facebook Connect can be used to allow people to log in or register on a site. It’s not necessary to have a complete app platform available right out of the gate, but Facebook is definitely on to something with Facebook Connect and it’s an important element for any social networking site to drive engagement.

Hopefully we’ll see swift continued development on Plus. It’s a great product out of the gate, but building the product isn’t the hard part in social networking: that’s left to getting users to buy in and keep coming back for more. Plus solves a lot of the qualms people have with Facebook on the privacy, data portability, account deletion, and sharing side of things, and that’s amazing. But it’s not an instant win, and they’ve got a long way to go. Making Huddles indispensible (and consider integrating them with group gTalk) would help, but I’m hoping they’ve got some other unique features up their sleeves to introduce into the Plus fold. I’m disappointed that the Slide-inside-Google-developed Pool Party and Prizes products weren’t built with Plus in mind. It might be time for the left hand to clue the right hand into what’s going on, and to get everyone on the same page.

HTMList primarily focuses on the technical side of the web development work we do here at Synapse Studios. We’re mixing things up a bit with the announcement of the launch of Nestablish.com, a comprehensive loan officer workflow management system, built as a startup for a few loan officers who wanted to make life easier for their fellow loan officers.

Loan officers frequently have to generate and sign pre-qualification forms and other specialty forms (such as Arizona’s Loan Status Update form) for each and every offer a real estate agent makes on a house. This can often come at inconvenient times, such as nights and weekends, when loan officers are typically off-the-clock. Nestablish allows loan officers to configure a maximum value for the pre-qualification documentation. The real estate agent is then granted the ability to generate the forms at the value they require, automatically limited to the maximum allowed by the loan officer.

This project presented a few interesting challenges for us, including working with the Fannie Mae 3.2 file specification to allow for the easy import of loan information into the system, and some complex PDF generation. Since each loan flows through a complex process with a lot of steps and required documents, we built Nestablish to allow the loan officer, real estate agent, and home buyer alike to track the progress on the loan approval and see exactly where they are in the process. This ensures faster closings with fewer back-and-forth during the typically-stressful home buying process.

We’re incredibly proud of our team here at Synapse who helped make Nestablish a reality, including Jeremy Lindblom, Andrew Reida, and Bob Eagan. We’ll be working with the fantastic team at Nestablish to deliver a whole new suite of features to the site very soon, but loan officers can get started today by registering for a free 60-day trial. (Nestablish is free for real estate agents and home buyers, and only $29.95 for loan officers after the free trial.)

Nestablish — Loan Workflow Management & Form Generation

We needed a password system that was secure but which would allow us to share client passwords across our team, while ensuring limited access within the organization, and unique, complex passwords every single time. We ended up making use of the wonderful KeePass tool, synced through Dropbox.

KeePass is a wonderful password manager (though not as much for Mac or Linux users, for reasons I’ll get to) in general. And it has some pretty great features, some unique to KeePass, others relatively standard fare:

Strong Security
Clearly, any good password manager needs to be secure itself. KeePass supports AES and TwoFish, amongst other encryption standards that are very difficult to crack. Your password database is duly encrypted thusly. Further, you can expand your security by requiring the use of a unique key file in addition to (or instead of, though this isn’t recommended) the password you use to unlock the database. This adds an additional layer of security against things like keyloggers, in that the hacker must have access to and identify the key file to use, in addition to knowing or cracking your password. (A strong password is still important, since simple passwords will fall to dictionary attacks relative quickly.) You can also use your Windows login to unlock your database, but again, this shouldn’t be your only method to unlock, and this doesn’t work when sharing a password database as we do.

KeePass also goes to some length to keep your passwords completely out of process memory. This keeps malicious software from identifying passwords in the memory stream of the process while it’s running. It also can be configured to automatically purge the computer’s clipboard after a set period of time, to prevent a user from walking up to your computer and hitting paste and hoping for the best.

Workspace Locking
Workspace locking goes hand-in-hand with strong security, itself being a subset of the program’s security. You can easily configure KeePass to automatically re-lock your database after a period of system OR KeePass inactivity, when the software is minimized, or when your workstation itself is locked. (I’ve noticed that it can sometimes pause the locking process when the database has changed, though this might have been resolved in recent updates.)

Intelligent Sync Management
KeePass surprised me with its intelligent management of file changes. If a user on my team alters the KeePass file (which is stored to a Dropbox folder we all have access to) while I’m using the file, it prompts that it can merge the changes with any changes you may have made. Unless both of us happened to be editing the same record, the merge typically works perfectly, ensuring that all of our changes are current.

Our Process
We store our KeePass file on our team’s Dropbox folder. We have a very strong password applied to that file, which we change frequently. We also require the use of a key file to unlock the database, which is NOT stored in our Dropbox. This file is distributed manually and only on a few systems. We also maintain several different databases, based on what access a user needs. Unfortunately, there isn’t a way to share a record amongst databases in order to keep it current, so this sort of functionality only goes so far, but if necessary, we’re able to quickly change all of the passwords we need to in the event of a personnel change or other problem.

Dropbox syncs the file as I described above, ensuring we’re all working off of the same copy of the file. If we wanted to, we could enforce a read-only rule that would have one member of the team making all password changes and entries, but this wouldn’t be very efficient for our team, and we trust our team members.

Potential Issues
Unfortunately, KeePass isn’t built to play terribly kindly with OS X or Linux. KeePass is kept in two development variants: 1.x and 2.x, with 1.x being Windows- and WINE-compatible, but missing some great features, and 2.x only working in Mono, to varying degrees of success (as far as those in our organization were concerned.) A solution to this is KeePassX, which works natively in OS X/Linux, but which doesn’t support the kdbx file format used by 2.x. The KeePassX developer is looking to rebuild it to support kdbx, so hopefully we’ll see that problem reconciled in time, but for now, Mono may be your best bet, if you can get it to cooperate.

Neat Bonuses
KeePass has a pretty great Android app that can work together with the Dropbox app to load your database, even if it requires both the password AND key file. I haven’t had a chance to use the iOS apps, but apparently they’re pretty nice as well. I generally use this in read-only mode exclusively, but it’s convenient nonetheless when you absolutely *need* a password. There’s also a plugin system that allows for some cool extensibility, and it’s actively being developed, so you’ll see updates hit on a regular basis. It’s also entirely free.

You can easily sort passwords into folders and sub-folders, assign icons to them, search through records, attach other encrypted data to each record, store record histories, and even have it perform a macro of keystrokes when “auto-typing” your password in. (This is useful if you need to select a database, for instance, from a dropdown. You can even have it launch a new browser tab, browse to the page in question, and go from there, though this requires a bit of configuration to get working.)

Conclusion
Overall, we’ve been very happy with KeePass. We weren’t willing to take the plunge and use an online, hosted solution to store our passwords, if we could avoid it. Because we control the encryption and access requirements, and because Dropbox is pretty secure in and of itself, I feel comfortable keeping our password database on Dropbox, encrypted with AES-256 bit on a strong password, and backed by a non-Dropboxed encryption key.

This is a somewhat unique configuration for our smaller group, and you’ll likely need to modify it accordingly, but hopefully this can give you a great starting place for good password management with your team.

KeePass Password Manager (free!)

Dropbox (free!)

I’ll keep this simple:

1. Your full address, hours, and phone number should appear on EVERY SINGLE PAGE, please. Don’t make me hunt for this information, since this is what at least 90% of your visitors are hunting for. Jam it into a sidebar or footer, but do NOT make me click a separate link or search like a truffle pig for something so very basic.
2. Put a map on your contact page. Don’t just link to it, put the damn map there. This is extraordinarily simple, and full instructions are here, but suffice to say, enter your address on Google maps, click the Link option in the upper right corner, and copy and paste the embed code that appears. Don’t make me click through to see the map.
3. Stop using Flash. Just stop. Resist the urge. It doesn’t make you edgy. It annoys the hell out of me. And any of your users who are trying to pull your site up on their phones. You can accomplish cool image changing effects in other ways, and if you’re playing music, that needs to stop too. Save the ambiance for your restaurant. Flash is also exquisitely bad for search engine optimization; people searching for a specific dish or words and phrases that would otherwise appear on your site may not find them if the search engines have trouble grabbing them. They’ve gotten better at searching Flash, but it’s still nearly impossible to drop someone accurately to the right spot in your Flash movie, so it just frustrates people.
4. Make your full menu available. With prices. And incredibly prominently. The 10% of users who already know where you are and when you’re open are coming to check your menu. If you have several menus, list each of them. If they change often, that’s fine, but keep it seasonally representative at the very least.
5. Make your menu available in a manner other than PDF. I know this one is a toughy and it’s unlikely to be a change anyone adopts in the near future. Restaurant owners are busy people who barely have the time to update the menu in PDF form, which is how they get it printed, to worry about converting it to HTML or making it otherwise available on the site in a way that looks half decent. But doing this the right way is better for search engines, mobile users, and people who know that opening a PDF is a sometimes-Sisyphean ordeal that causes you to curse the gods. Don’t put us through that. We want to plan our meals or see if you have something we like. Make it easier on us.
6. Only show fantastic food photos. Pay a photographer to get it right if you must, but do NOT post cell phone pictures from your Blackberry that you took on the patio at 11pm. This reflects poorly on your presentation even if the dish looks fantastic in person, and there’s no need to give people a specific reason NOT to show up. Also, you need not over-emphasize photos. While fantastic photos can really help push someone the right direction, you don’t need to overwhelm them. This isn’t McDonalds. In any event, make sure they’re great quality photos: well-lit, not overly compressed, and of something appetizing and plated well.
7. Make sure you list things that set you apart. If you offer dietary considerations for diabetic, gluten-free, kosher, vegetarians, or vegan dieters, mention that. It’ll help in search engine results, and it’s invaluable for people who are looking specifically for that information and are unsure if you have anything that works for them. Consider whipping up an online menu that showcases some of those dishes; people in those communities will be extremely appreciative.
8. Give us a little personality. Clearly state your purpose, your passion, and what you do to deliver and set yourself apart. A simple explanation with a few well-written bits about how much you love making great food for people can get your visitors energized and ready to make a reservation.

These are pretty universal, simple to apply tips that can enhance the experience for visitors who need a very specific piece of information typically very quickly: don’t frustrate us by burying it, forgetting to supply it entirely, or by designing the site so horribly that it’s nearly closing time when we finally track down your hours.

I get emailed sometimes as much as three times per week by Crate and Barrel. This is simply too much. The problem is, it’s all or nothing. While I may want to see when they announce new seasonal items or great upcoming sales, I can either turn it all off, or get barraged with an absurd amount of mail that drives me nuts.

The solution to this is to allow users to choose their newsletter frequency. Harry & David, another frequent emailer, wised up to this and offers four options:

• “Keep my emails coming, I want to make sure I receive your best offers”
• “Send me an email once a week”
• “Send me an email once every two weeks, plus holiday reminders”
• “Send me an email once each month, plus holiday reminders”

Brilliant. Since I’m not dying to be tempted by fresh and delicious pears four times a week, I chose the “once a month, plus holidays” option. I still see when new products are in season, and they warn me of upcoming sales, but I’m not driven to insanity, nor do I start to get frustrated with the brand because our email relationship is now on my terms.

Implementing variable frequency email newsletters, while sounding pretty simple, can be a bit complicated. An organization needs to determine if they want to tailor the less frequent emails differently so that users who are on the frequent list don’t receive the same email as users on the monthly list, or if they simply want to ratchet down the frequency. Typically, one would apply a simple hierarchy: the monthly email is the same for everyone, the bi-weekly is likewise, and people see the emails they’ve requested. If a weekly lines up with that month’s monthly, they’ll get that message, instead of a separate double.

I know that interactions and brand engagements like this rely on lots of “touches” to keep people thinking of you and to encourage repeat sales, but I really wonder about diminishing marginal returns. At the point that I’m receiving 10 emails from a company a month, how many more purchases can I reasonably be expected to make, versus sending me 5 emails a month? My personal feeling is that you seriously risk annoying your subscribers without making it back in increased purchases by polluting their inboxes and worse, conscribing yourself into “automatically delete” mode for the customer—since all they see is noise, they don’t even take the time to look inside anymore. When your emails are farther and fewer in between, and a good deal more substantial, your open rates increase and your conversion rates are likely to do the same… but even if they don’t, you won’t be risking damaging your brand, even on a subconscious level, with your best customers.

And your newsletter subscribers ARE some of your best customers—they’ve volunteered to allow you to spam them on a regular basis, for heaven’s sake. They trust that you’ll deliver value and deals and reasons to keep opening their messages. Don’t abuse that trust, and instead, let them set the boundaries so that you don’t unwittingly do more harm than good.

How S3 Versioning Works
Versioning is a critical feature many developers had requested as data stored on S3, while maintained in triplicate across the S3 file-system automatically, is still vulnerable to sweeping delete operations by developers, errant scripts, or other causes. Moreover, developers had to manually version changing files if they wanted to preserve the ability to roll-back to an earlier revision or undo a “delete”. In any event, a lot of custom code had to be created to replicate these behaviors, and most solutions weren’t particularly graceful.

Versioning is easy to enable and brilliant for Amazon: make a simple API call to enable versioning for an entire bucket and all changes to the files within that bucket will preserve versions. Moreover, deletions of files through the typical DELETE API call will simply create a delete marker, making the file unavailable for all intents and purposes, but preserving its presence and all of its versions in the S3 filesystem, until its permanent deletion is called for. It’s brilliant for Amazon because you pay the additional storage fees for each version and for each “deleted” file that hasn’t been permanently destroyed.

This means that versioning can be easily enabled on any existing S3 implementation with out breaking compatibility with existing code. Naturally, developers will need to rewrite their delete calls to make use of the version delete options, but for an application with little-to-no deletions, this is a feature implemented with a single API call.

Amazon also introduced Multi-Factor Authentication. MFA works with security code-generating key fobs that act as a physical token one must have in order to perform an action. In this case, if you enable MFA, you need the token to log in and manage your AWS account, and you can also optionally require the token to commit a permanent deletion of a file version. For the uninitiated, it’s considered multi-factor as you need two types of authentication to login or make deletes on your account. (Your AWS username and password for account management and your AWS public/private key for API calls each make up the other half of the multi-factor equation with the MFA code.)

The S3 Trash Bin
Using MFA, it becomes possible to create a highly robust and secure safety net that prevents the wholesale deletion of an S3 account’s contents without first enforcing an additional review step. After enabling versioning and MFA-Delete mode for a bucket, a developer’s application will continue to function to the end-user as expected. This means very little rewriting of code needs to be performed to get these features up and running. A simple trash bin script could then be created which would identify all files whose current version is a delete marker, and present them to an admin. Since permanent deletions require the MFA code to be appended to the API call, only the individual with physical access to the code (which recycles every 30 seconds) would be able to commit the delete operations necessary. After reviewing the files queued for permanent deletion, they’d enter the code and the script would be sent off to the races.

Naturally, this still leaves some room for error: the script that commits the permanent deletes would need to be scrutinized to ensure that it itself is bulletproof, but beyond that, this should protect against nearly all accidental deletions, and establish a command and control hierarchy for an organization. It’s important to reduce the sheer number of individuals who have complete deletion privileges for myriad reasons, and this helps accomplish that. The MFA key fob is available for all of $13 and you’re off to the races. You simply input your serial number on the AWS site, and Amazon’s servers knows what the code it’s generated should be based on the time and a seed that’s private to them.

More on Amazon AWS Multi-Factor Authentication
S3 Versioning | Amazon Developer’s Guide

Anonymous functions, also known as closures, allow the creation of functions which have no specified name. They are most useful as the value of callback parameters, but they have many other uses. Closures can also be used as the values of variables; PHP automatically converts such expressions into instances of the Closure internal class.

PHP has very few predefined classes that are part of the core language, so naturally I was intrigued by the Closure class. The PHP Manual has this to say about the class:

The predefined final class Closure was introduced in PHP 5.3.0. It is used for internal implementation of anonymous functions. The class has a constructor forbidding the manual creation of the object (issues E_RECOVERABLE_ERROR) and the __invoke() method with the calling magic.

The invoke magic method is also a new feature in PHP 5.3. It is called when an object is used in the context of a function (e.g. $object($parameter);). Since Closure objects will be used like functions, this is a critical feature of the Closure object. The Closure class may be perfectly equipped to act like an anonymous function, but it does not provide any extra utility beyond that. A var_dump() of a closure will reveal the functions parameters, but there is no way to get any other information about the Closure (like the actual code of the function). Trying to serialize the Closure throws an Exception and json_encode() just returns an empty JSON string. To make matters worse, the Closure class is final, so there is no way to extend it.

That simply wasn’t going to cut it for me. I wanted to make my own Closure class that was at least able to do the following:

1. Invoke the Closure (with __invoke()) just like the PHP Closure class
2. Retrieve the actual code of the Closure
3. Retrieve detailed data about the Closure’s parameters
4. Retrieve the names and values of any variables inherited from the Closure’s parent’s scope (with the use construct)
5. Serialize and unserialize the Closure

I decided to play around with the Reflection API to see what kind of information I could get from the Closure. A Closure is a function, so using the ReflectionFunction class provides the same information about Closures as it does about any other functions. PHP 5.3 also added the isClosure() method to the ReflectionFunction (in case you weren’t convinced that reflection would be helpful). After some tinkering, it became apparent that I would be able to accomplish all of my desires. I will walk you through the construction of my “SuperClosure” class and explain how the creative use of Reflection allows us to find ways around the problems normally blocking the ability to have my desired features.

1. Grant the ability to invoke the Closure

The first goal was to create the basic SuperClosure class that both encapsulates and allows invocation of the Closure. To do this I wrote a simple class with a constructor and the magic __invoke() method. I also included an accessor method (getter) for the actual Closure. In the constructor I created an instance of the ReflectionFunction class and stored it as a class member that helped allow invocation of the closure with a variable number of arguments. It also helped me accomplish other things later. The following code shows the basic class upon which I will be building. The complete will be shown at the end of the article.

class SuperClosure {

	protected $closure = NULL;
	protected $reflection = NULL;

	public function __construct($function)
	{
		if ( ! $function instanceOf Closure)
			throw new InvalidArgumentException();

		$this->closure = $function;
		$this->reflection = new ReflectionFunction($function);
	}

	public function __invoke()
	{
		$args = func_get_args();
		return $this->reflection->invokeArgs($args);
	}

	public function getClosure()
	{
		return $this->closure;
	}
}

The __invoke() method allows the SuperClosure object to be used exactly as if it was a Closure object. I had to recreate this functionality for the SuperClosure class since I was not able to extend the Closure to begin with. In order to pass arguments through to the real Closure, I used a combination of the func_get_args() function and the invokeArgs() method of ReflectionFunction to ensure that any variable number of arguments could be used. I could have also used call_user_func_array() function, but I prefer Reflection, and since I already had an instance of the ReflectionFunction, the invokeArgs() method seemed like a better choice.

2. Retrieve the actual code of the function

Secondly, I added code that allowed the SuperClosure class to find and store the actual code defining the closure. This feature is actually the key to doing the serialization later and is the most complicated part of the program. To accomplish this portion of the program, I used the instance of ReflectionFunction from Step 1 and the SplFileObject class, an SPL class which provides a nice object-oriented interface for dealing with files. The getFileName(), getStartLine(), and getEndLine() methods of the ReflectionFunction class allowed me to retrieve all the information I needed to find the source code of the Closure function. Using the SplFileObject to open and read from the source file and in combination with some string manipulation, I was able to obtain the closure’s source code. The following code shows the protected _fetchCode() method used to parse the closure’s code out of its source file:

protected function _fetchCode()
{
	// Open file and seek to the first line of the closure
	$file = new SplFileObject($this->reflection->getFileName());
	$file->seek($this->reflection->getStartLine()-1);

	// Retrieve all of the lines that contain code for the closure
	$code = '';
	while ($file->key() < $this->reflection->getEndLine())
	{
		$code .= $file->current();
		$file->next();
	}

	// Only keep the code defining that closure
	$begin = strpos($code, 'function');
	$end = strrpos($code, '}');
	$code = substr($code, $begin, $end - $begin + 1);

	return $code;
}

The only limitations with the current version of this function are that you cannot have multiple closures on a single line and you cannot use the word “function” anywhere besides the actual closure’s declaration.

3. Retrieve detailed data about the Closure’s parameters

Retrieving information about the closure’s parameters was as simple as adding a method that simply returns the result of the getParameters() method the SuperClosure’s instance of ReflectionFunction. That’s all. The getParameters() method returns ReflectionParameter objects which have several methods for getting information about the parameters including their names, values, default values, and more.

4. Retrieve the names and values of any variables inherited from the Closure’s parent’s scope

One of the biggest problems I had was retrieving the names and values of the variables added to the Closure’s scope with the use construct. There isn’t a documented way of doing this as far as I know, but I was able to figure out a way to do it after playing around some more with the ReflectionFunction class (it is just so helpful). These variables are actually included in the results of the getStaticVariables() method. If the closure declares any variables with the static keyword, these will also be included in the results. To get around this I added the _fetchUsedVariables() method that uses a combination of the getStaticVariables() method and some string manipulation of the Closure’s code (from Step 2) to find only the variables that were inherited from the parent’s scope. The following code shows the _fetchUsedVariables() method:

protected function _fetchUsedVariables()
{
	// Make sure the use construct is actually used
	$use_index = stripos($this->code, 'use');
	if ( ! $use_index)
		return array();

	// Get the names of the variables inside the use statement
	$begin = strpos($this->code, '(', $use_index) + 1;
	$end = strpos($this->code, ')', $begin);
	$vars = explode(',', substr($this->code, $begin, $end - $begin));

	// Get the static variables of the function via reflection
	$static_vars = $this->reflection->getStaticVariables();

	// Only keep the variables that appeared in both sets
	$used_vars = array();
	foreach ($vars as $var)
	{
		$var = trim($var, ' $&');
		$used_vars[$var] = $static_vars[$var];
	}

	return $used_vars;
}

5. Grant the ability to serialize and unserialize the Closure

Finally, I implemented the serialization capabilities. Since an actual closure object cannot be serialized (it gives a fatal error), I had to be creative to come up with a way to do my own serialization. The code I wrote for Step 2 and Step 4 made this possible. The sleep magic method allows you to hook into the serialization process, so I used this method to prepare my SuperClosure class for serialization. In order for my class to be serialized, I needed to first stop the Closure object and the ReflectionFunction object representing the Closure from being serialized. The __sleep() method should return an array of the class members you are serializing, so I simply left those variables out of the list. Because I was serializing the Closure’s code and static variables, it made possible in the __wakeup() magic method to recreate the Closure object using the code. To do this I had to use the extract() function on my array of used variables to import them back into the scope. Then I performed an eval() operation on the Closure’s code in order to recreate the Closure. eval() is always a risky operation, but in this case it makes sense. If you are planning to use this code for any of your own projects, I urge you to take precautions. The following code shows the complete SuperClosure class with the additions of the __sleep() and __wakeup() methods.

class SuperClosure {

	protected $closure = NULL;
	protected $reflection = NULL;
	protected $code = NULL;
	protected $used_variables = array();

	public function __construct($function)
	{
		if ( ! $function instanceOf Closure)
			throw new InvalidArgumentException();

		$this->closure = $function;
		$this->reflection = new ReflectionFunction($function);
		$this->code = $this->_fetchCode();
		$this->used_variables = $this->_fetchUsedVariables();
	}

	public function __invoke()
	{
		$args = func_get_args();
		return $this->reflection->invokeArgs($args);
	}

	public function getClosure()
	{
		return $this->closure;
	}

	protected function _fetchCode()
	{
		// Open file and seek to the first line of the closure
		$file = new SplFileObject($this->reflection->getFileName());
		$file->seek($this->reflection->getStartLine()-1);

		// Retrieve all of the lines that contain code for the closure
		$code = '';
		while ($file->key() < $this->reflection->getEndLine())
		{
			$code .= $file->current();
			$file->next();
		}

		// Only keep the code defining that closure
		$begin = strpos($code, 'function');
		$end = strrpos($code, '}');
		$code = substr($code, $begin, $end - $begin + 1);

		return $code;
	}

	public function getCode()
	{
		return $this->code;
	}

	public function getParameters()
	{
		return $this->reflection->getParameters();
	}

	protected function _fetchUsedVariables()
	{
		// Make sure the use construct is actually used
		$use_index = stripos($this->code, 'use');
		if ( ! $use_index)
			return array();

		// Get the names of the variables inside the use statement
		$begin = strpos($this->code, '(', $use_index) + 1;
		$end = strpos($this->code, ')', $begin);
		$vars = explode(',', substr($this->code, $begin, $end - $begin));

		// Get the static variables of the function via reflection
		$static_vars = $this->reflection->getStaticVariables();

		// Only keep the variables that appeared in both sets
		$used_vars = array();
		foreach ($vars as $var)
		{
			$var = trim($var, ' $&amp;');
			$used_vars[$var] = $static_vars[$var];
		}

		return $used_vars;
	}

	public function getUsedVariables()
	{
		return $this->used_variables;
	}

	public function __sleep()
	{
		return array('code', 'used_variables');
	}

	public function __wakeup()
	{
		extract($this->used_variables);

		eval('$_function = '.$this->code.';');
		if (isset($_function) AND $_function instanceOf Closure)
		{
			$this->closure = $_function;
			$this->reflection = new ReflectionFunction($_function);
		}
		else
			throw new Exception();
	}
}

Conclusion

With some cleverness and reflection, I was able to create the SuperClosure class and extend the Closure’s normal capabilities. Although my class does not enhance the typical use of a PHP Closure it does make it possible to serialize and transport a closure and provides an interface for examining the parameters and inherited variables. This means that we can do:

$closure = new SuperClosure(
	function($num1, $num2) {return $num1 + $num2;}
);
$serialized_closure = serialize($closure);
$unserialized_closure = unserialize($serialized_closure);
echo $unserialized_closure(1, 5);

without worrying about errors. Also, it would technically be possible to send closures through a remote service.

From what I have read in the PHP Manual, this class may have to be changed in the future. The Manual states this regarding anonymous functions:

Anonymous functions are currently implemented using the Closure class. This is an implementation detail and should not be relied upon.

So according to this, future versions of PHP might implement closures differently, and my class would have to be rewritten.

If you would like a copy of the code from this article (and an example of its use) you can find it on my Github account.