Brainstorming: Can Google Trends Data Help Predict the Stock Market? Maybe…maybe not

According to a study by researchers at the University of Warwick Business School, using publicly available data on financial related search terms from Google Trends may help predict what the stock market will do.

In the study titled “Quantifying Trading Behavior in Financial Markets Using Google Trends” researchers tracked about 100 financially related terms such as “debt,” “crisis” and “derivatives” from 2004 to 2011.

In order to test their theory, the researchers created an investing “game” to see if the terms searched in the previous week to any given closing day could predict the Dow Jones Industrial Average (DIJA).  If searches for financial terms went down, they opted to buy and hold stocks.  Conversely, search term volumes went up, the researchers would sell assuming that the stocks were going to fall in value.

The game follows the logic that if people get anxious about the stock market, they will likely seek out information on financial issues before trying to get rid of their stock.  It almost goes without saying, the first place people go when seeking information on just about anything is Google.   So then, the idea was that finance-related searches on Google should spike before a stock market decline and vice versa.   Thanks to Google Trends, the public now has access to aggregated information on the volume of queries for different search terms and how these volumes change over time.

The researchers further found that “debt” was the most reliable term for predicting market fluctuations.  By buying when “debt” search volumes dropped and selling when the volumes rose, the researchers were able to increase their hypothetical portfolio by 326%.  The chart below from the research report illustrates these results:

rpt-strategies

 

 

 

 

 

 

 

The second chart, also from the report, shows the relative search volume change for the term “debt”  vs. time series of closing prices for the DIJA on the first day of trading each week.   If you look closely, immediately after every bright red spike in volume change, the index values drop and vice versa.

rpt-index

 

 

 

 

 

 

 

 

 

 

If you are like me, the results from the study immediately brought out my skeptical side so I figured I’d play around with Google Trends myself.   I compared the Google Trends volume reports for “debt” vs the DIJA for the month of January and April 2013.  As you see below, there is an inverse correlation:

trends

I’m still not completely sold, however, since it’s always easy to look back at data and make obvious correlations. It’s another thing to predict future movements of the market.  Obviously, there are many factors that influence a market participant’s decisions other than information obtained through Google searches and an unlimited number of factors that affect stock prices.

There will never be a “silver bullet” for predicting the market but the idea behind this study is certainly intriguing and could potentially be used to create another tool to be used by investors in making informed decisions about the market.  For example, this study was done at the “macro” level focusing on vague terms such as “debt” and analyzing an index that represents the broad market.   What if the same concept could be applied to market segments or even down to individual stocks whose prices are particularly affected by investor sentiment such as Apple.   Is it possible that analyzing a certain set of Apple related search terms could provide similar results as the original study at the individual company level?

Maybe or maybe not… but who wants to give me some money to play with to find out?  :)

 

Symfony2: Using kernel events like preExecute to log requests

A couple of days ago, one of our developers mentioned wanting to log all the requests that hit a specific Symfony2 controller. Back in Symfony 1.2, you’d be able to easily accomplish this with a “preExecute” function in the specific controller that you want to log. We’d actually set something similar to this up and the code would end up looking like:


Symfony2 doesn’t have a “preExecute” hook in the same fashion as 1.2 but using the event system you can accomplish the same thing. What you’ll basically end up doing is configuring an event listener for the “kernel.controller” event, inject the EntityManager (or kernel) and then log the request.

The pertinent service configuration in YAML looks like:

And then the corresponding class looks something like:

And thats about it.

Symfony2 forms without an entity and with a conditional validator

Recently on a project I had a situation where I was using the Symfony2 forms component without an entity. In addition to each field’s constraints, I needed to something similar to symfony 1.4’s conditional validator so that I could make sure that the form on the whole was valid. There are a bunch of docs out there on how to use callback functions on an entity to do this, however I didn’t see much on how to get the entire form that has no entity to do a callback. After reading some of the source code, found that you can set up some ‘form level’ constraints in the setDefaultOptions method. So it will look something like this:

You pass the Callback constraint an array methods which it can call. If you pass one of those methods is an array it is parsed as class::method. In my case by passing $this it uses the currently instantiated form, rather than trying to call the method statically.

From there you can do something like this:

The first parameter is the form’s data fields. From there you can add global level errors to the form, such as if a combination of fields are not valid.

Good luck out there.

PHP: How do you evaluate PHP skill?

We’re always on the hunt for talented LAMP developers and as a consequence we end up evaluating a decent amount of fairly diverse PHP code. We always ask potential employees for a code sample so that we can get a sense of their style and generally make sure they have their heads screwed on right. Because of this, we’ve been evaluating PHP samples from everything from Drupal modules, to batch processing scripts, and even “hardware hacks”.

During this process, one of the issues we’ve had is coming up with an objective rubric to evaluate the relative skill of a PHP developer. Although there are several broad criteria for evaluating code, I’ve been interested in coming up with PHP-centric benchmarks since they’re more directly applicable. Here’s a list of criteria that we’ve been working on to help us identify how familiar an engineer is with PHP.

Negative Signals

Unfortunately, it’s sometimes easier to spot negative signals so here are a few PHP specific “code smells” we’ve identified.

Re-inventing standard library functions

Often, inexperienced engineers won’t search for standard functions that’ll do exactly what they’re looking for. Not always a bad thing but it’s a sign of inexperience. An example would be:

Not really understanding the ORM (or SQL)

This one isn’t really PHP specific but we’ve noticed it a couple of times anyway. We’ll often see code that looks something like:

As you can see, the code returns all the results and then evaluates the criteria as opposed to passing the selection criteria to the ORM or SQL.

Everything is a global

Due to PHP’s global keyword it’s unfortunately really easy to throw encapsulation to the wind and just make everything a global. Because of that, we’ve seen code that looks like:

Positive Signals

What we look for next is usually positive signals that an engineer is generally familiar with PHP. These are generally things you’d pick up after you’ve written a fair amount of PHP.

Has implemented __toString() somewhere

I know this one will be controversial, but my sense is that if an engineer implements __toString() somewhere in PHP they probably have a decent familiarity with the language since its something you have to “seek out”. A canonical example would be something like:

Uses output buffering

Output buffering is a bit exotic but it’s indispensable when building web apps without a framework. It also certainly demonstrates a level of familiarity with PHP. A good example would be capturing output from a template and returning it inside some JSON:

Voodoo Positive Signals

Finally, the last couple of things we’ve been looking for are “exotic” techniques that really demonstrate that someone “gets” PHP. Granted, some (most?) of these are bad ideas in production they do convey a certain level of understanding.

Classes that implement the ArrayAccess interface

Since PHP relies so heavily on arrays, building classes that implement the ArrayAccess interface makes them work more naturally in PHP and definitely demonstrates a strong level of familiarity with the language. An example would be:

Using __set, __get, or __call

Although, using any of these in production is questionable at best, they undeniably do convey a sense that whoever used them knows their way around PHP. An example (from the documentation) would be:

Anyway, like everything I’d take this list with a big grain of salt. We’d also love any input or feedback.