More and more of our clients are moving to the Common Application— in most cases that’s because homegrown applications tend to be unwieldy and hard to manage, and it’s easy to see how tempting it’d be to outsource that whole process— information gathering, account creation, payment collection, reporting, security, etc.— to a third party.  I don’t know if the Common App is a publicly held company, but I wouldn’t say no to a gift of stock options if they were.

However.  Although the Common App is certainly a convenient way to manage the process of college admission, doesn’t it feel like a missed opportunity?

The process of applying to college is an anxious, scary time, as anyone who’s ever done it can attest.  With a very few exceptions, nobody’s going to be accepted everywhere they apply.  So in applying, you know you’ll be rejected somewhere, and the kind of self-revelation required in a good college application adds a fear of exposure to the process.   (At least that’s what it was like for me.)

If that’s the case, it seems that a college or university could do a great deal to alleviate this anxiety— and build a relationship with the prospective student— by presenting her with a thoughtful, friendly, easy to use, customized, streamlined and responsive, online application.

The first step in applying using the Common App looks like this:

Wouldn’t it be better if the first page started like this?

Hi.

It’s great that you’re applying to Middlebury.  Our applicant pool always includes an incredibly diverse group of interesting and thoughtful young people from around the country and around the world.  The students that join Middlebury next fall will become part of a close-knit academic community; we expect a lot from our students, and we give a lot in return.  In other words, we aren’t just looking for the best students, we’re looking for the best neighbors.

We’re looking forward to reading your application. If you have any questions at all about the process, e-mail John Doe, our online application support counselor, at JohnDoe@middlebury.edu.

To get started, enter your first and last name below.

We know from experience that students choose colleges based on direct connections.  Sometimes it’s a friend they made touring campus; sometimes it’s a favorite book by an alumni author; sometimes it’s a discussion on Facebook.  Sometimes university Web sites include tools that encourage connections as well— for example, Haverford will occasionally let a select group of admits or top prospects create student profiles, and we’re working on a project for Lewis & Clark that will let prospective students create customized portal pages just like faculty, staff and current students.

The question is, why can’t that sense of personal contact extend to the application itself? I’ve suggested some of the most typical reasons why colleges go to the Common App— convenience, security, stability, etc.  These are all fine reasons to outsource the application; there are other reasons too.  It is undeniably more convenient for the *applicant* to only enter their information one time and apply to multiple colleges at once.  Web database development projects done in-house are notoriously hard to maintain over time; this is one reason why schools’ own online applications are often a little clunky.  And there aren’t many companies that offer customized application development.

(The reason for this last case are clear.  The perfect online application would be the better mousetrap, and it’s hard to even think about how you’d build a college application without seeing visions of how the world of higher ed would beat a path to your door.)

But it’s my belief that when the right school— unsatisfied with the Common App, wanting to create personal contact with applicants, and without the staff or the time to develop an application in house— meets the right Web development vendor, a few steps might be taken toward an online application that will itself do some of the work of recruiting great applicants.

Consider this blog post a want ad; I think we’re the right company for that job, and if anybody’s interested in talking about it, let me know.  Over the next several days I’ll be posting a few more thoughts on this topic— how an application might reach out and speak directly to students, building connections in the process.  If anyone else has any ideas about what the ideal application might do, please drop me a line.

At the code level, LiveWhale is a framework, which means the same codebase is hit for many different types of requests. The question is then: how to achieve high performance with a codebase that has to perform so many tasks and is therefore code heavy. It makes sense to divide code across a handful of files. The objective here is to only load libraries when you need them. A typical request will only use a tiny percentage of the entire codebase, so there’s no need to read a great deal of code from the filesystem and eat up RAM per PHP request. Also, with a modular system like LiveWhale, it is not explicitly known what modules exist that will need to be loaded. An important optimization is one where only the first request to the server has to perform logic to determine what to load. The results of this expensive operation are cached, and all subsequent LiveWhale requests enjoy dramatic savings in the module loader.

A common problem with application frameworks is that they perform two very expensive tasks with every single page load: 1) initializing a session and 2) connecting to a database. Neither of these two should be assumed. In LiveWhale, a session is started only when a component requires it. A database connection only occurs when/if the first query to it is performed. Making your application sufficiently “smart” about if and when these initializations take place will also lead to dramatic speed improvements.

Less is more. That means you should optimize out any hit to the file system that you can, or remove extraneous database queries. Also, be wary of OO (object oriented) slowdowns. If something doesn’t need to be a class, don’t use one. Remember that calls to an object’s method are more expensive than global function calls. The same holds true for accessing an object’s properties. An obvious optimization is done when dealing with data from a foreign server. Such content should be cached as much as possible, so that rapid hits to your site don’t rely on the performance (or availability) or an external data source. Another tip would be to use error suppression (@) sparingly. This is a known performance hit. There are a number of similar, simple tips available via a quick Google search for “php optimizations”, and there are slideshows available from PHP developers on the subject.

Analyze how your code operates. If you have a function that uses a lot of logic (if/then, switch), make sure you understand what the “common case” is. In other words, what’s the most likely condition that function will come across? Then determine if the function’s logic is conducive to the fastest possible result under the most common case. For example, I had a function that has to intercept a variety of XML structures and handle them in different ways. One particular XML structure (the simplest possible one) was far and away the most common case. Rather than parsing the XML with simplexml_load_string() as I do with all the chunks of XML I receive, I first do a preg_match() to determine if I have the common case. In this situation, I can immediately return a simple result and skip both the parsing of the XML and the lengthy logic that goes with performing operations with it.

Identify “hot” functions. Functions that are called many times, often within a loop, should get the most attention in terms of optimization. First, make sure the function should be called at all, as opposed to using inline code, otherwise you needlessly acquire function overhead. Second, move any redundant logic outside of the hot function. Perhaps the check can be performed just once before the hot code is executed. There are also situations where a function can potentially be called repeatedly and end up with the same result. It might make sense to declare a static variable inside the function, to locally cache content generated by the function. On a subsequent call, it can first check the static array to see if a result already exists, and simply return that if so. This sort of fine-grained optimization will only help when there is a significant bottleneck with a particular function, but it can make a huge difference if done wisely.

Lastly, use XDebug! XDebug is your friend. Among the many things it can do, it will let you profile your PHP code and generate a report about how much time your script is taking overall and within particular functions. Here’s a mockup of the type of information it provides:

In this example, the function LiveWhale->foo() clearly takes the majority of the time for this request. At 38.3% of request time for a single call, it is a good candidate for serious analysis. LiveWhale->bar() is also expensive compared to other operations, and there may be ways to make this function perform better too. The function do_something() takes 6.3% for a single call, on line 41. Another function, do_something_else(), takes nearly the same amount of time but due to the fact that it was called 15 times (at 17 CPU cycles each, so 252 cycles total). Knowing why each function takes the time that it does, and why it might be called so many times, will help you maximize the performance of your application.

Familiarity with what makes PHP code perform well will only lead to the best decisions being made early on, so that XDebug reveals fewer inefficiencies. In the long run, many of these tips become automatic and part of your coding style, but for the best quality, production ready code, a little bit of analysis and thought goes a long way.